ちょっと必要があって作ったメール送信用バッチファイル。
以下のユーティリティを取ってきてどっかのディレクトリにがさっと入れ、yyyymmddhhmm.Mail.txtとMaillist.txtを突っ込むとどかっとメールを送ってくれるという代物。
Cron的なもので自動実行させるために、Mail.txtで指定した年月日、時分でしか動いてくれない。
Pycronとかを使えばWindowsでも分単位の自動実行ができる。

■必要なもの
Smail　：　コマンドラインメール送信プログラム
Unix Utilities : Windowsで動くUnixのユーティリティ群
Base64エンコーダ　：　やすあきさん作のフリーウェア。
csconv　：Unibirth Software作フリーウェア。文字コード変換ユーティリティ。あて先のニックネームをISO-2022-JPにするの使用。
Mfc42.dll　：　なんかのランタイムライブラリ。

これらをがさっとバッチファイルと同じディレクトリに突っ込んでおく。
Unix UtilitiesはWCとHEADしか使っていないので、これだけでも良い。

バッチ本体は以下の通り。
時分チェックとかを外しておけばローカルで簡単に実行できる。
「共有ファイルに突っ込んで使う」ために作ってあるので、あて先ファイルとかデリケートなものは実行後に削除している。

@echo off

cd C:Mailbat
::年月日時分.Mail.txtがあったときに、本文ファイルを送信して結果をレポートする。
::情報保護の観点から、送信先リストは実行の都度消去する。
::つまり、送信するときには本文ファイルと送信リストの両方を投入しておく必要がある。

::現在日時、時分をセット
SET DATESTR=%date:~0,4%%date:~5,2%%date:~8,2%
SET TIMESTR=%time:~0,2%%time:~3,2%
SET TIMESTR=%TIMESTR: =0%

::Windowsのバッチファイルでは、実行前に全ての式を評価する。
::なので、入れ子のFor文は評価しない。
::従って、後続するメール送信部分でのIf判定に以下の部分を入れてしまうと
::変数にNullが入って「構文エラー」が出ることになる。
::実行時に評価するオプションもあるようだが、うまく動かなかった。
::なので、外だしで。

::メールファイルを読んで、1行目をあて先にセット
for /f %%A in (‘head -n 1 %DATESTR%%TIMESTR%.Mail.txt’) do set SUBJECT=”%%A”

::メールファイルは3行以上無ければ、エラー
SET LINENUM=000
for /f %%A in (‘wc -l %DATESTR%%TIMESTR%.Mail.txt’) do set LINENUM=%%A
if exist %DATESTR%%TIMESTR%.Mail.txt (
if %LINENUM% LSS 3 goto NOMAILTXT
)

::対象にするファイル名を確認し、あれば実施。
::あて先リストが無ければ、警告メールを送信
::あて先リストは「お名前」の形式。
::お名前部分をISO-2022-JP変換後、BASE64して送信する。
::メールファイルは3行以上無ければ、エラー
::メールファイルの1行目を取り出して件名とし、
::残りをbody.txtへ吐き出して本文ファイルにする。
::Body.txtは処理が終わったら消去する。

if exist %DATESTR%%TIMESTR%.Mail.txt (

if not exist Maillist.txt goto NOMAILLIST

csconv MailList.txt -FWORK.Maillist2022.txt -OISO-2022-JP -Auto -ROFF

CALL :CODECONVERT

more +1 %DATESTR%%TIMESTR%.Mail.txt > body.txt

for /f “delims=” %%i in (encoded.MailList.txt) do smail.exe -i -h192.168.0.1 -f”=?ISO-2022-JP?B?GyRCJTUlcyVXJWslYSE8JWsbKEI=?= ” -s”%SUBJECT%” -Fbody.txt %%i >> log.txt

smail.exe -i -h192.168.0.1 -f”MailReport ” -sメール送信結果 -alog.txt,MailList.txt,%DATESTR%%TIMESTR%.Mail.txt hogehoge@hage.com

DEL encoded.MailList.txt
DEL MailList.txt
DEL log.txt
DEL body.txt

)

goto :EXT

:NOMAILLIST
smail.exe -i -h192.168.0.1 -f”MailReport ” -s送信先リストがありません hogehoge@hage.com

exit

:NOMAILTXT
smail.exe -i -h192.168.0.1 -f”MailReport ” -sメールファイルが3行以下です hogehoge@hage.com

exit

:EXT
exit

:CODECONVERT
for /f “tokens=1-2 delims=<>” %%A in (WORK.MailList2022.txt) do (
SET MAILTO=%%B
echo %%A > WORK.ISO-2022.txt
Base64c WORK.ISO-2022.txt WORK.ISO-2022enc.txt
for /f %%C in (WORK.ISO-2022enc.txt) do SET ENCSTR=%%C
CALL :MAILLISTWRITE
)

DEL WORK*.txt

GOTO :EOF

:MAILLISTWRITE
echo =?iso-2022-jp?B?%ENCSTR%?=^<%MAILTO%^> >> encoded.Maillist.txt

find ./ -name *.jpg -or -name *.JPG -exec convert -size 250 {} {} 　;

拡張子がjpgもしくはJPGのファイルを拾ってきて、Convertコマンドに渡して横幅２５０ピクセル見当へリサイズし、同じ名前で保存する、と言うワンラインコマンド。
単純に備忘録。

AppleとGoogleとARMがネットブックだとか。
これの製造にあたって東芝とかシャープあたりにがんばってもらうと日本も素敵です。凸版とか大日本印刷でも素敵です。現実的には実装技術が高い台湾企業が生産をやって、国内企業でチャンスがあるのはAccessぐらいかな？AppleとGoogleがはずれて「ARMでネットブック」だけの絵柄にならないと国内勢は難しいかもしれないですね。

そのようになってしまって、そのネットブックが日本でバカ売れしたりなんかすると…

まずは日本のホモジニアス/均一的な国民性の根っこであったマスメディアによる日常的な世論作りのところの壊滅が決定的になるわけです。「ARMでネットブック」というのは「携帯電話にもっと大きな画面と強力な電池とキーボードをつける」っていうのと等価なわけで、あんなに操作性が悪くて視認性の無い2インチ画面の機械でもこれだけの利便性が出せているのであれば、そんな機械が普通になったらだれがもうテレビなんか見るか、と。
ほしいときにほしい情報にアクセスできて、購入や利用はその場でオンラインだぜ！と。食材や日用品もネットスーパーで購入して、引渡しだけ店舗だぜ、と。
全てがそちらへ極端に移行することはもちろんないけれど、無視できない量がそのようになるのは、もはや堅いところだろう。「もうそういう生活で〜す」っていう引きこもりピーポーも多いし。外にいても引きこもりピーポーと同じようなネットへのアクセシビリティが出来上がるとすると、そりゃすげぇわけだ。

今でもできてんじゃないの、って言う人はiPhone信者かケータイ小説読者だと思う。主婦が肉買うのにあの画面じゃ無理だよ。

そういう世界がそのうちやってくるのであれば、お客さんがほしいと思える商品を探したり作ったりして商流に載せ、お客さんをPOS／販売拠点へと導き、買ってくれた後にはリピートを促すというのをきちんとやらなきゃいけなくなってくる。マスでどかんとブランドや商品名を刷り込んでおいて、棚シェアを確保しておけば売れるという絵柄じゃないのだ。
かといって口コミなんてのは胡散臭くて企業側からのアプローチとしては下策だろうし。
ターゲットを絞り込み、必要とされる訴求価値に沿った商品作りとバランスの取れた価格設定を行い、販路と重ね合わせの取れたアプローチのパスを設定し、ブランドの体感ポイントと広告露出の整合性を取った上で生産量と流通在庫を見ながら現場のキャンペーンを適宜打つというマーケティング本来の現場仕事がものすごく大事になる。これまで以上に、どんどん大事になる。

デジタルが行き着くとヒューマンが登場するのは予定調和だけど、やっぱりそのようであるのだろう。

このサイトのショップはXoopsのモジュールで簡単に組み込めることもあってZenCartで作っているのだが、友人のEC/ブログサイトを作るのにSorceForge.net の２００８年度ベスト・プロジェクトに選ばれたMagentoを使ってみた。

成果は近日公開できると思うけれど、まずは簡単に印象を述べてみる。

多層構造による圧倒的な自由度でページ構築が可能

Magentoで特徴的なのは、やはりデザイン・処理・コンテンツがそれぞれ独立して管理出きることだ。
これを実現するためにテーマ、テンプレート、CSSという3層構造でサイトを組み上げていける。
さらにサイト、ストア、ストアビューと3つの概念を持つことで例えば複数言語への対応が簡単に出来る。
これはいわゆる企業サイトではそれほど有利性は無いのだけれど、ショップサイトを作るとなったときは非常に大きなアドバンテージをもたらす。

ひとつには、商品の特性に合わせてカテゴリごとにページの構成を自由に変更することが出来る。
例えばラクシャリーブランドものであれば大きなウォールペーパーでブランド想起を補完しながら、商品それぞれの表示には仕様情報のようなものはそれほど不要だろう。が、同じブランドであっても小物系であれば品数を多く見せたいかも知れない。さらには言語によってレイアウトを変えたいかも知れない。Magentoでは、先に上げた３×３の層概念でほぼ完全にこうした要素を管理することが出来る。作成することが出来る、と言う観点では他のECソフトでも十分できるが、管理できるというのはすごい。デザインの仕込みが良ければ、ショップの店長さんが他のソフトを使っているショップに比べて圧倒的に柔軟で自由にショップを管理していけるだろう。

また、構成の自由度はコンバージョンレートを上げていくための試行錯誤にも有効だ。
きちんとレイヤリングされているので、ページ内でのコンテンツ配置をそれぞれ試して最適解を見つけていくようなオペレーションにも適している。

最新のECソフト

特別価格の期間付き適用、商品画像のクロースアップ、特別組み合わせ価格の適用、ページデザイン適用期日の指定など今時のECサイトが欲しいだろう機能があらかじめ一通り揃っている。
先に上げたデザインの自由度と合わせて、価格や商品構成その物の自由度も非常に高いことになる。
言うまでもないことだがこれはショップの戦闘力を大幅に引きあげる。
ZenCartでもこうしたことは出来るが、デフォルトではない。(不勉強かも。間違ってたら指摘して。)

でもちょっと敷居が高い

SQLにしてもPHPにしても要求する要件がちょっと、高い。それはまぁ何とかなるとしても、デザインをきちんと作りこもうとすると、かなり大変。テンプレート、CSS、PHP処理を行ったり来たりしなきゃいけない。
静的ページの造り込み画面では素っ気ないテキスト入力画面でちまちまとHTMLを打たなきゃいけない。
WYGIWYSなエディタがついていないことで導入をためらうショップ店長もいるかもしれない。

総合的に見れば、今触っておくべきオープンソースのNo.1だろう。
友人のサイトでは、これにWordpressを組み合わせて情報ページの入力エディタとして使用するつもりでいる。個人商店向けショップサイトとしてはかなり良い具合にまとまりそうな気がしている。

うちの会社の社長が交代して、給料が5%下がるそうだ。
社内で唯一利益を上げているはず、な俺のモチベーションも下がってるので、いろんなお話はどんどん受け付けますよ。

さて、前回の続き。

導入を契機として事業運用の一部を担うことでカネを儲けるという絵柄はコンピュータ業界が50年前からやってきたことでもある。20年ほど前にこの業界に入ったとき、何にもしなくても月々もらえる「保守費」というやつにあごが外れるほど驚いた覚えがある。
が、この稿で言っているのは「機械を動かすこと」の対価ではなく、お客さんを集めてきたりするような部分への対価だ。
機械を動かし、そこでのお客様の行動を見て（おそらくほぼ自発的に）ページ構成を切り換えたり、価格キャンペーンの提案を行ったり、メールマーケティングのタイミングを計ったりするところまでやっちまえ、という話だ。

この絵柄はSME(Small/Medium Enterprise)やSOHO／個人商店の時にはものすごくフィットするのはお分かりいただけると思う。人員も予算も限られている中でネットショップやWEBマーケティングやグループウェアの世話とか従業員のITリテラシー強化とかやってらんねーとか、日常的ですよね?

大企業はほっとけ、みたいな言い方を前稿ではしたのだけれど…なぜってだいたい、既にマーケティング部とかがあって広告代理店とかに予算振り向けてて、そっちでやってることになってるしね。うちの奥さんも広告代理店勤務だしね。
ただ、現状のしがらみみたいな部分でデータ活用ができてないとか、少なくともスピードが落ちているような部分もありそうな気がしている。

技術の少しわかるマーケターがクイックに対応を行っていくことのほうが、クリエイティブやメッセージを作りこんでいくよりも効果が高いケースというのがある。これは商流の短縮と最終消費者側の情報入手コスト低下がインターネットによって加速度的に進んでいることによるのだけれど、特に小売では顕著だ。チラシの代わりにメールマーケティングを考えていないスーパーの店長さんがいたらお目にかかりたい。
製造業にしても、購入リピートをどうやって獲得するかを考えると…ね？ネットコミュニティとまではいわないけど、最終消費者とのインタラクションをリアルタイムにキープしなきゃいけないとなったときに、高品質なクリエイティブよりはクイックな対応のほうが価値があるでしょう。コミュニティで話題になっている”何か”について差し支えの無いところで社内情報をオープンにしてあげるとかさ。

で、そういうことをやろうとするときにやっぱりオープンソースなものの方が機動力がある。
ベンダーに縛られないこと、世界中で利用されていること、自由に改変できることがもたらす機動力が、運用に金がかかることよりも価値を生むのだ!

こういう絵であるならばキーはオープンソースじゃなくて機動力のあるマーケティング・セールスチームじゃないの?という疑問はもっともかつ正当です。その通りです。そういうチームが既にあるのならば、より「機動力を発揮」するためにオープンソースがクイックにテクノロジーを底上げしてくれます。まだ無いのならば、オープンソースが持つ豊富な活用事例が、そういうチームの整備に役に立ちますよ、ということです。
今日やりたいことが明日できて、明後日にはその改善に入れる…とイメージしてくれればおそらく正解。

一応、私はソフトウェア開発企業に所属していて、事業のひとつをまかされて展開している。が、正直やっている商売に継続性がある気がしない。モバイルに焦点をおいた、なおかつキャリアや通信機器ベンダー向けではない開発企業であるのは、最終消費者からのマネタイズラインが現状1兆円程度とそれほど太くなく、またそのほとんどがコンテンツ販売であることから開発ニーズというモノもあんまり、浮かんでこないのだ。

とはいえ世の中不景気だし、このまま何にもしなけりゃジリ貧だし、ということでオープンソースを使って技術資産を底上げした上で携帯関連の開発で食う、という図柄の勉強を始めている。

このブログやC-NETでもたびたび同じことに触れているが「開発」という作業そのものに対価を請求できた時代はとっくの昔に終了している。一定の瞬間から、開発は製品のサブセットになり、どちらかといえば「機能実装」というより細分化された作業になっている。例えばSAPのカスタマイズであるとか、ExchangeサーバーをCRMスキームに組み込んでいくであるとか、ATM機器と広域イーサの接続をチューニングするとか。
こうした開発作業の基盤になっているテクノロジーが国内製のものであることは非常に少なくて、役所の人が憂えてしまうのももっともなのである。こうした部分での国際競争力は実際問題、ない。さらにいえば、製品もほとんど無い。

オープンソースソフトウェアは、国内製でもないが海外製でもない。”コミュニティ”という得体の知れない主体／基本的に何らかの”善意”で成り立っていて、存続の基盤を利益においていない。多くの場合、GPLライセンスであり開発の成果を知的所有権として囲い込んでしまうことが非常にやりにくい。やってもいいんだけど、ケツの穴の小さい奴ということで”コミュニティ”から嫌われたりする。

オープンソースは「既存製品の代用」、「安価」という語り口で紹介されることが多いが、実際にはそんなに安くもない。実際の業務に利用しようと思ったら、

• 英語ができて
• 人の書いたコードを読むのが苦にならなくて
• 「今回の案件にはDB構造が合わないからスクラッチしましょう」とか言い出さなくて
• それでもなんとか使えるものをひねり出してくれて
• 壊れちゃったときにはすぐに直してくれて
• セキュリティ問題があったらすぐに対応してくれる

そういうエンジニアがいなきゃいけないが、この人は「高い」。能力も、モチベーションも高いからね。
じゃぁ、外注先にそういう人がいてくれればコストがヘッジされるじゃん、という話になるけれども基本的なデマンドは上に掲げた条件と変わらないので、リスクのありかが変わってはいるけれどコストも、そしてリスクもヘッジされてはいない。その辺を考えていくと以前Microsoftが盛んに主張していたように、かえって高くつく。まず間違いなく。

じゃぁそれが致命的な問題なのかというと、そんなことは全然ない。

無責任に聞こえるかもしれないが、きちんと運用を完結させようとするから高くつくのだ。
壊れたときや、セキュリティ問題が起こったときにどうする、ということさえ決めておけば、オープンソースはその多様性と世界中での利用者が多いが故に　−　安いから、じゃないぜ。繰り返すけど。　−　非常に魅力的な選択肢だ。CMSやECショップシステムなどのオープンソースを利用して行く際にも、既存のノウハウが世界中にある。”実装”作業であればコピペでこなせるといってもいいだろう。中小企業や個人商店などでキックスタートさせる際には、実装期間の短さとコストの低さは魅力だろう。

が、エンジニアリングコストは総体的には高額になるし、データ入力や編集、顧客対応などの運用そのもののコストは下がらない。中小企業や個人商店などであるならば、これらのコストは丸々追加コストだ。
SEM／SEOやメールマーケティングなどのリアル店舗とは違うマーケティング手法を展開しなければならないことも考えると、もう現実性がどんどん無くなる。「ティッシュ配ったほうが即効性もあるし…」となるのは非常に当たり前の論理である。

SMEとSOHO向けには、おそらくは以下2つのパッケージが現実的なビジネスプランだ。

1. マーケティング、データ入力、編集などをパッケージにした運用のアウトソースビジネス
2. インフラレベルから顧客対応までビジネスストリームを全てカバーしたコンサルビジネス。

「インフラレベルから顧客対応までをパッケージする」ってのは受けるほうがリスキーなので、なし。
実装をキックアップのタイミングとして、マネタイズは事業運用の一部を請け負っていくことで行うわけだ。

Enterpriseへの提案については、上に述べたコスト構造を飲み込めるだけのエコノミーを抱えているのならば、これまでどおりでよい。事業の細分化が進んで行って、オープンソースが持つ実装の多様性が重要になってきたら話が変わるだろうけれど。

DBMSをMySQLに、なんていう話をしてるんじゃないからね。間違えないように。

いろんなところに恥ずかしい匂いを残しつつ、ショップオープンとします。
これに伴ってサイドペインにつけていたPaypalボタンを廃止。

恥ずかしい匂いは順次消していきますが、それに伴ってショップの動作が不安定になることもあろうかと思われます。ご容赦ください。
売り物の中身は…何とかとハサミは使いよう、の「ハサミ」の方ですのでうまく使ってください。

要求要件定義書サンプルのダウンロードが8,000件を越えたので有料化することにしました。
というわけでメニューにショップが出てきてますが…作り込みにもう少しかかりそうです。
じゃぁ、閉じとけよってのは当たり前の話なんですが、まぁいいじゃないですか。

というわけで、出来上がったらみんな買ってください。要求要件定義書。マーケット狭いかなぁ。

このサイトはさくらインターネットを使っているが、何故だか本日いきなりWEBルート直下でPHPを使うとInternal Server Errorが出るようになった。.htaccessをいじったわけでもなく、ファイルパーミッションも大丈夫。PHP.iniもいじってない。

ふーん、ということでWEBルートの下にもう一個ディレクトリを作ってコンテンツを全部移してWEBルートを指定しなおすと…直った。

なんだろう?

— 追記
すいません。ディレクトリにchmod 666とか打ってたらしくて、実行権が消えてました。シロートかよと。
さくらのサポートの方、ご対応すいませんでした。

「お客様へ最高の便益を提供するのが企業の使命である」VS「企業の使命は利益の醸成にある」というテーマがあるとするならば、言うもおろかな選択である。

それは入力と出力のどちらが大事かという議論だが、もちろん両方なければ成り立たない。そのバランスをとってうまくいくようにしてやるのが経営とかプロダクトマネジメントと呼ばれる作業であるはずだ。
「利益第１、とするとコスト削減に意識が集中して企業体力が奪われる」とドラッカー先生やコトラー先生も言ってたりするけれど、かと言ってコストを適正に保たないのは放埒と言うべきだろう。便益提供のために行わなければならないR&Dを全く放棄しているとすれば、それは今日のために明日を放擲しているとしか言いようがない。
だから、この問いが出てきてしまった時点でもう、議論のための議論／イデオロギー論でしかなくなっている。
停止していたいがための現状否定テーゼに聞こえる。

聞いてる?　そこの君に言ってんだぜ。