つれずれなるままの開発日記(最近はFlexばかり..)

Archive for 5月, 2011

IMAPでは、共有のメールボックスを作れる。
つまり、これで複数の人でメールボックスを共有できるので、同じメールを複数のメールボックスにコピーして送信する必要はないので、ディスクの容量も少なくすむし、
それに、新しくプロジェクトに参加した人も、メールボックスの共有だったら、
今までのメールを見たい！となっても、見ればいいだけ。
（過去のメールを関係者から転送してもらう必要はない。）

そこで、dovecotとpostfixを使って、IMAPの共有メールボックスを作ってみることにした。

参考にしたサイトは
Dovecot shared mailboxes (the correct way)
です。

こちらを参考に、共有メールボックスを作成してみることにした。

/etc/dovecot.conf

namespace private {
   separator = /
   prefix =
   inbox = yes
   hidden = no
}
namespace public {
   separator = /
   prefix = Public/
   location = maildir:/var/mail/public
   hidden = no
}

設定ファイルを上記のように変更。
ここで１つもnamespaceの設定がなければ、privateの設定がなくても問題ないのだが、
共有メールボックスを追加する場合には、デフォルトのnamespaceも追加しなくてはならない。
私はちょっとここで、はまってしまった。
確かに設定ファイルを見れば、以下のように書いてある。

# REMEMBER: If you add any namespaces, the default namespace must be added explicitly

後は、設定したディレクトリをテストユーザが見えるようにすればよい。
このあたりの設定などは上で紹介したサイトを見ればわかりやすい。

で次に、ためしにこの設定がきちんと動いているのかを確認する。

telnet localhost 143
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
0001 LOGIN username password
0001 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in
0002 NAMESPACE
* NAMESPACE (("" "/")) NIL (("Public/" "/"))
0002 OK Namespace completed.

きちんと、NAMESPACEで、Public/と表示された。

どうやらうまくいったようだ。
細かいところで、まだまだ、不明な点があるが、今日のところはここまで。

ちょっと、おもしろい記事(ブログ?)を見つけた。といっても、その記事も本の紹介だ。
http://papativa.jp/archives/658

早速、Amazonから買って読んでみようと思う。
それで、また、自分なりの解釈を書ければと思うが・・・・

それはさておき、前述した記事を読んだという前提で、続きをすすめると・・・

「自分たちの身近なところの例でいくと、」
のくだりからが気になってしまった。
というのも、ちょうど2000年くらいのあるときまで、
その「メールマーケティング」の「ボリューム・オペレーション」の作成と普及に夜も寝ないでせっせと汗を流していた側だったからだ。

世界の一流ＩＴ企業が次から次へと大量のメール配信で誤配信というトラブルを起こしていた。
そして、自分たちも同様にやってしまった。
そういう意味で、社会が失敗を許してくれて、ある意味、おもしろく、そしていい加減だった。
だから周りの会社もみんなおそれをしらずに20代が流れを作っていけたのだろう。

その時の20代の現在はもう夜を寝ないなんてできないのですが・・・

それはさておき、次に私が進んだ道は「ボリューム・オペレーション」から、
「コンプレックス・システム」へのサービスの転換を試みていったが、
そこで、驚愕の経済構造（大げさですが・・・）に悩んでしまった。

それは、「コンプレックス・システム」の中に「ボリューム・オペレーション」を組み込んだら、
「ボリューム・オペレーション」より単価が下がってしまったということだ。
抱き込み販売したら、１こ１この値段の単価が下がるのはわかる。
でも、全体の総額が、１こ１この値段よりも低いとなってしまったのだ。
これでは、付加価値をつけたんじゃなく、負債をつけたことになってしまうではないか・・・

ブランド力の違いとか、専門力とか、購買する市場が違ったとかいろいろ他人には説明ができるのだが、
実は自分に対しては、今でもどうしてそうなってしまったのか、
よく説明（納得）ができないでいる。

まあ、本を買ってみてちょっとこの謎が自分なりにもう少し、すっきりしたいなーと思うのです。

私は大学を卒業して、すぐに金融会社のシステム会社としてそのシステムの仕事をしました。どことはいいませんが、システム自体は決して新しいものではなく、大学でJavaをやってから入ったので、そこには見るもの聞くもの古臭いものばかりでした。

ですが、いざ、ITベンチャーに入ってみて、いろいろと役にたったなーと思ったことがあるものでした。そこには、あのみずほ銀障害の新聞で「システム担当者はそもそも処理能力に限界があること自体を知らなかった。」とありましたが、会社が違えど、今ではベンチャーと大企業のシステムが逆転してしまうほどになってしまったのかなと思うような内容があるので、COBOL時代にまなんだことを書いてみることにしました。

システムの処理がコストとして部門に知らされる

実際にお金として計算されているかは知りませんが、各部署ごとのCPUの使用率の連絡が来ていました。そして、うちのチームはちょっと使いすぎとかの連絡がきました。
今のクラウドをつかっていると課金されるのと同じような感覚です。
私はここで、いろいろなことを知り、サーバを運用する際にはCPUとかメモリなどはあたりまえですが、Javaで言えばスレッド数や、同時接続数、SQLのクエリー数などもやるようにしています。第三者にサービスを提供している場合にはコンピュータ全体の使用率だけでは十分ではないからです。

障害がわざと作られ、訓練が行われる

私が、ちょうど１年目の冬ごろにちょっとした障害を起こしてしまいました。
当時はみんながなんとなく残業していたころで、早く帰ることすら罪悪感があった時代です。おかげで夜遅くまでいると、自然と他人の障害のヘルプとしてやっていたこともあり、多少はなれてきて、高をくくっていた時期です。
そんなときに、自分で障害を起こしてしまいました。
さすがに、他人の障害と自分が起こしたものでは冷静度が違います。
まあ、先輩方のサポートもあり問題がなくすんだということですが、
それから、大体１年後、新人を教育してきてだいぶ仕事ができるようになってきた時期に、上司からこんな命令が・・・
「新人にどんな障害をさせるか、考えておいて」

ソース管理

１つのチームが管理するソースがどれほどあったのかは覚えていませんが、４段のキャビネットが３ブロックくらいはあったと思います。（紙に印刷されています。）
COBOLのソースは、Javaとかとは違ってCOPY区という定義部分が大量にあるので一概にその他の言語とは比べられないのですが、とにかく大量にあります。
行単位で修正をするときには、一番左（右だったかな）に案件IDを記入して変更します。
そして、印刷したソースには、注意事項などの付箋とそれに連動したドキュメントを挟んでおいたりしていました。
ソース自体の世代管理はライブラリアンという方がいてそこで管理されていました。
今で言えば、案件ID部分のリビジョンであり、付箋はTracなどの事案管理でありと手法などは違えど本質的にはかぶっている部分が多々あります。
ただ決定的に違うのが２つ。
すべてのソースがIDです。ProductList.javaみたいなソース名ではなく、PL0001みたいになっているということです。まあ、プログラムの単位が違うので一概にいいところばかりでもないのですが、IDというのはそこに責任境界線もあったりするので、管理としては進んでいると思います。
そして、プログラムが紙に印刷され保存される場所が物理的あるので、担当者として「あー、２段目の真ん中あたりだ」と感覚的に仕事が進みます。付箋などの量も変わってくるので問題があるあたりが目と感覚でわかるので、誰の目にも見えやすいです。

システムの分離性

とにかく、システムのデータが重複しており無駄が多いのです。
１つの情報を修正したくても、あそこもここも修正しなければなりません。
DBの正規化などをやろうしている人が見たら、だめだめといわれるかも知れません。
しかし、私もシステムが何を守りたいのかを知るまではそのように思っていました。
そして、それはそれから数年後、ASPを運用するときになってようやく意味がわかりました。
ただ、そのときには大学で勉強してきた情報管理の基礎もできていないのだと・・・

それは、私が午前４時ごろに社宅の管理者から起こされたときでした。
障害がおきたので対応してほしいと。
でも、私は初心者で業務全体を理解できていません。
そして、残念ながら私のチームのリーダと先輩には一切連絡がつきません。
多少は業務はしっているが、チームとはまったく関係がない先輩と二人で約３時間でシステムを復旧させないと全国のオンラインシステムのサービスが間に合わないこととなります。

当然、問題を解決し復旧させるには時間もなく、私自身の知識も足りません。
そこで、問題の先延ばしをオンラインシステムの立ち上げだけは問題がないようにすることにします。
ここで、データが重複している無駄が非常に役立ちます。
問題がおきているシステムに関連するデータだけを修正して、あたかも問題がないようにデータを直接、手で直してしまいます。
つまり、問題の場所しか見えていないような人でも問題に対応できるようにしておくことがシステムの重要性から必要だということです。
あの人しかしりません。そして、できません。そして、顧客の資産が減ります。それではサービスとしてありえませんから。

これだけではありませんが、こんな感じに今思ってもいろいろとよく考えられているなーと思うことばかりです。
でも、その中にいて、その中のルールで動いているうちはまったく気がつきませんでした。

まあ、ルールは作る側に立ったときに本当に他人のが作ったルールの意味がよく見えてくるものです。
しかし、今では銀行などでも小規模システムのルーズさと流行言葉に悪い影響をうけているように見えることが非常に残念です。

さて、今回はairxmailを使って受信したメールを文字化けなく見る方法です。

問題の原因としては、airxmailでは文字コードの変換にByteArrayのreadMultiByte関数を使っていました。
そのために、受信したメールの文字コードがその関数ないでサポートされている場合には問題ないのですが、
Android上ではiso-2022-jpは処理ができないようです。

なので、airxmailではこのエンコード部分を外だしできるようにしました。
ただし、注意点が2つほどあります。

１）0.7には含まれていないので、Subversionのr110以降を取得してくる必要があります。
2) iso-2022-jp からUTF-8（内部処理コード)への変換は自前でする必要があります。

さて、それで対応の方法は以下のようにします。

AirxMailConfig.setDecodeCharetFunction(decodeJIS,'iso-2022-jp');

private function decodeJIS(bytes:ByteArray,charset:String):String{
   //  charsetの引数には、iso-2022-jp がきます。
   //  デフォルトでは以下のような処理が動きます。
   //  なんらかの方法で、自前で処理をしてください。
   //  return bytes.readMultiByte(bytes.bytesAvailable,charset);
   return "";
}

とこんな感じです。

どうやら、Shift_JISは扱えるようです。
K-9 Mail( Andoridのメールアプリ）のソースを見たら
JISからShift_JISへの変換プログラムだけが特別に登録してありましたので、
どうやら、それで同じようにいけるのかなと思ってちょっと試してみたらいけるようでした。
AU IS03でのみの確認ですが、上の理由から他でも同じようにいけるのだと思っています。

今度、同じような方法で解決するようにしてみようかなと思っています。

あと、送信は現在このような自前エンコード処理はできません。
まあ、とりあえずはUTF-8で送信すればいいかなと思ったからです。

ソーシャルビジネスの歩き方――あなたのビジネスにソーシャルを活用して、新しいワークスタイルを：誠 Biz.ID
というサイトから私のブログに来る人がいるので、なぜなのだろう？

と思っていたら、
「ソーシャルビジネス・トピックス」
というリストの中に私のブログのリンクがあるようです。

それは別にいいのだが、私がびっくりしたのは、
「どうやってこのリンク集をつくっているのだろうか？」
ということです。
（このあたりが技術者の職業病が出てしまいます。）

どこにびっくりしているかと言えば、
たいていこのようなリンクは、何らかの自動収集によって作られていると思うのです。

そして、私がそのようなリンクをどうしてつけないかと言えば、
あまり、精度がよいリンク集が自動では作れないのではないかと思っているからです。

でも、このリストの題名と多少サンプル的に中身を見ると、
SEOをばりばりやった、検索に引っかかる為だけが目的のようなサイトがキチンと取り除かれているように感じます。

有名なサイトのみを対象にそこで出ている記事だけを見ていけば、
それなりに精度が高そうなリストは作れると思います。
でも、私のサイトも含めて、ちらほらとそうではなさそうなものも含まれています。

だったら、人力でつくっているのでしょうか？
それだったら、相当大変な気もします。いったい、どれだけ広い範囲で記事を探しているというのでしょう？
そして、その労力に見合うだけのコンテンツ領域とも思えません。

それとも、見た人がそれっぽく勘違いするように、
自動収集＋適当ルールによってそれなりに演じているのでしょうか？

さらに関係がない話ですが、適当ルールはまっとうな技術者からは提案しにくく、
そして受け入れるのも難しいようで、たびたび顧客ともめていたことを思い出します。
私も初めはびっくりしましたが、まあ、受け入れられるようにもなりました。
ただ、それが有料コンテンツだったりした場合には、それなりに後ろめたさもありました。

そんなこんなで、昔を思い出し、
何となくそれっぽい一覧にして出しておいてくれないかな？という要望に対し、
何かよい案があるのだろうか？と思っていたので、
改めてそれを思い出し、そして、再度疑問に思いました。

AIR on Android上でairxmailを使ってメールを送信する場合には、
文字コードをJISでのエンコードから、Android上で使える文字コードへの指定が必要です。

AirxMailConfig.setDefaultBodyCharset("UTF-8");
AirxMailConfig.setDefaultHeaderCharset("UTF-8");

のように指定することで、デフォルトがJISからUTF-8へ変更されます。
各個別で指定することも可能ですが、上記のようにやってしまった方が面倒がなくていいでしょう。

受信したメールを文字化けなく受信するためには、現在Subversionにあるコードを使わなくてはなりません。
また、その説明は次回にしたいと思います。

なんで、そんなに電子メールばっかりやってるの？
とある方に聞かれた。
（もちろん、メールを書いているということではなく、技術として電子メールに関わってきているということです。）

なので、ちょっと書いてみることにしました。
私の中での結論は、表題のように「結局、企業のコミュニケーションは電子メールなのだ！」ということです。

いろいろなIT企業が、電子メールに置き換わるソリューションを世の中にアピールしていますが、
今のところ、私の認識では、それを実現できたソリューションはないと思っています。

いろいろな情報がWEB化（httpのプロトコルを使って転送される）される中、
電子メールでの情報やりとりは、古くさく、そして、管理もコントロールもしづらいというのが、
WEBサービスをやっていると思うのもです。
ちゃっちゃと、情報の共有掲示板ならwikiなり、chatなり、グループウェアなりでできるじゃないか？
そして、それを共有していく方法性が今後の流れなのではないのか？
そして、その便利さと、効率の良さをみんなわかってほしい。

そんなことを感じる一方、ITの世界から一歩抜けてみると、世界が異なることを感じます。

まず、WEB上で情報を運用することは普通の人の感覚からみれば、「恐怖」だったり、「想定外」なのです。
理由は
１）情報をグローバルにして、そこに制約をかけるという概念の意味が理解できない。
　ログインで情報を制御できるっていうが、そのログイン情報を安全に運用することはWEBはやってくれない。
２）自分たちだけのWEBサーバっていっても誰がそれをやるの？誰がそれをしてくれるの？エンジニアなんていないよ。
３）外部に安いサービスがあるよというが、手元のPCで多少不満はあるものの事足りている情報を、どうしてお金を払ってまでする必要があるの？
　そのお金を払ってまで使う方向に持って行く手間のほうが面倒だ。
４）無料のサービスで自由に使ってみたらというが、社外に持ち出してはいけない情報をそこに載せるわけにはいかないでしょ。
５）すべて、乗り越えたとしてもお客さんとの連絡はメールでしょ！
６）それでも、私は、いつだって、PCの画面や携帯の画面がみれるわけではないのですよ。

やらない理由の連発ですが、それでもこれらのやらない理由に対してそれを覆せるだけの根拠があるサービスがないのも現実だと思います。

それに、企業の社内コミュニケーションも結局は、お客様によりよいサービスを提供するためにやっているわけで、
その最後が電子メールで、それさえみればまあ何とかなるというものが電子メールだったら、
中心は電子メールになってしまうのは仕方がないことです。
そして、６）の用件がいつもあるので、WEB化してもすぐに望まれる機能が、
「通知をメールで関係者にしてほしい」という機能でほぼ、この機能は必須で望まれます。
企業間や内のやりとりでは、相手がみるみない、みたいみたくないに関わらず、情報をPUSHする機能が求められるのです。

だったら、WEBサービスでやりたかったことを電子メールプロトコル上に乗せた方がよっぽどいいのではないのか？
というのが私の考えです。
それで、使う、使わないを取捨選択できる環境がほしいなと。
（グループウェアで使っている主な用途は、SMTPとIMAPで構築できるのですが・・・）

また、WEBサーバがない会社も電子メールのサーバだけはあります。
そして、電子メールという機密情報を管理することだけは、必須の管理業務として企業は管理しているわけです。

また、WEBサーバで情報の公開を気にする必要がありますが、それに比べれば、電子メールでは遙かに制限は緩いです。

ということで、個人情報やらセキュリティやらがうるさい昨今の中で、
安全にコミュニケーションをするためには、個人情報であるメールアドレスをもらった上でする方が、安心できるものです。

なので、私は電子メールプロトコルがおもしろいのではないかと思っているわけです。

後は、最近、WEB化、WEB化に疲れて逆に情報がコントロールできなくなったと嘆いている人をよく見かけるようにもなってきましたし・・・・

airxmailがAndroid AIR上で動くか確認してみました。
特に、IMAPの機能を試しています。

そこで、現時点で結論を言えば、うごくもののいくつか不具合や不都合があります。

１）文字化け
これは、ByteArrayのreadMultiByteや、writeMultiByteで不備が起きているようです。
どうやら、文字コードのiso-2022-jpが実機ではうまく機能していません。
このあたりは、airxmailで使っているこれらのメソッドの外だしをして対応する予定です。
まあ、すべてUTF-8ならば問題はないのですが、さすがにそうも行かないですので・・・

２）その他・・
今まで、SMTPや、POP3は処理をしたら切断するということを考えていたが、
やはり、IMAPとなると接続を持続することも意識しなければならないのですが、
このあたりがちょっと貧弱というか、ちらほらとバグもあり・・・
という状態です。

ちなみに、こんな感じのアプリを作って確認してみました。

こちらが、gmailのフォルダ一覧を出してみたところと、

そして、こちらが、メール一覧を表示した部分です。

airxmailの部分より、Android AIRのいろいろな部分ではまってしまいました。
画面周りはPCよりは楽ですが、
携帯となると、あまりネットワークを使いたくないので、
ＤＢキャッシュを使って表示をさせるようにしているのですが、
こちらが多少面倒ですね。

mod_chxjでXHTMLとそのCSS対応版の0.13がリリースされました。
今まで、gitからチェックアウトする必要がありましたが、
RPM版も用意されているようです。

さらに、
http://sourceforge.jp/projects/modchxj/wiki/FrontPage
を見ると、

Android/iPhoneの対応もするようです。

個人的には、mobile jqueryなどもやりたいところです。

まあ、スマートフォンを使ってわかったことが、
やはりサイトとして、ＰＣでも、携帯でもないということで、
リソースを１つというときに、何を中心にするかでその志向も変わってくると思います。

タッチが前提のスマートフォンと、数字ボタンと数個のボタンが前提の携帯と、キーボードとマウスが前提のＰＣサイトでは、画面のサイズ以上の違いが出るのだと思いました。

かといって、すべて別に作るのは非常に面倒なので、
結局は、WordPressなどのようなテンプレートツール（ＣＭＳ）と連携すれば、
非常に使いやすくなると思います。