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

Archive for 2月, 2010

今回は、airxmailのちょっと変わった使い方とでもいうのでしょうか？
（airxmailの説明はこちらをご覧ください。）

まあ、技術的にはSMTPでメールを送っているだけですが、こんなこともできますよーという一例の紹介です。

最近、Google バズというものがあるらしく、そこにAirxmailを使ってバズって（っていうの？）見ました。

と実は、これ簡単。
前回、「airxmailでGmailを使ってメールを送信する」の応用です。

といってもほとんど同じ、変わるところは以下の２つ。

１）宛先を buzz@gmail.comにすること。
２）メールのヘッダの文字コードをUTF-8にすること。

さて、

sender = new SMTPSender();
sender.setParameter(SMTPSender.HOST,"smtp.gmail.com");
sender.setParameter(SMTPSender.PORT,465);

//  SMTP-AUTHの使用
sender.setParameter(SMTPSender.AUTH,true);
sender.setParameter(SMTPSender.USERNAME,username);
sender.setParameter(SMTPSender.PASSWORD,password);

// STARTTLSの使用
sender.setParameter(SMTPSender.SOCKET_OBJECT,new com.hurlant.crypto.tls.TLSSocket());

は前回と一緒。
ここからが、ちょっと違う。

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

var mimeMsg:MimeMessage = new MimeMessage();

var from:INetAddress = new INetAddress();
from.personal = "おれじゃ";  //  特に何も反映されないようですが・・・
from.address = this.fromEmail;

mimeMsg.setFrom(from);
var toAddr:INetAddress = new INetAddress("buzz@gmail.com","buzz");
mimeMsg.addRcpt(RecipientType.TO,toAddr);
// set mail subject
mimeMsg.setSubject("初めてのBuzzzzzzz! From airxmail");
mimeMsg.setTextBody("");  //  ここで、本文はなくても、空で設定が必要。現在、airxmailのバグ

sender.send(mimeMsg);
sender.close();

ということです。

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

の２つで、本文とヘッダのデフォルトの文字コードを変えることができます。

もしくは、サブジェクトだけの文字コードを変えるのであれば、

mimeMsg.setSubject("これでもだいじょうぶだよー。Buzzzzzzz! From airxmail","UTF-8");

でも、問題ありません。

今日は、クラウドの構成、事例を聞いてきた。

そこで、あれ、ちょっと待てよ、「そもそもクラウドになったらロードバランサーって必要か？」
ということを思った。
っていうか、必要になるようにしか構成を結局組めないのか？というのが本音だ。

ただ、WEBのコンテンツを提供しているようなメディアは除外していただきたい。
対象は、いわゆるSIerにハード構築を依頼するようなレベルの話だ。

（ただ、自社ですべてやっている場合なら、必要であれば、自分たちでロードバランサーもどきなんて作ってしまえとも思ったりもする。それで充分なのだから。）

あくまでもこれからの前提は私が見てきたサーバ構成ですが、たいていはネットワーク構成の教科書にあるような構成なので、
多くのケースが当てはまるのではと思う。

さて本題にもどり、なぜ私たちのサービスにはロードバランサーが必要なのだろうか？
冗長性を・・・・２重化を・・・・

と、こんな感じの答えが聞こえやしないだろうか？

じゃ、クラウドでハードが壊れることをあまり考慮しなくても？やっぱり？いる？

ロードバランサーがあれば、高負荷にも耐えられるじゃないか？

でも、じゃ、高負荷でボトルネックになるDBは、それ以上にロードバランスができるようなDB設計になってるの？
っていうか、DBは１つしかないですよ。
あっても、故障時に切り替えられるようになっているだけじゃないですか。
（わたしは、サービスをやるときにはテーブルを移動できるようにするため、基本的にリレーションははらないが・・・・、
昔、遊びで、１つのシステムのコンテンツのDBがDB2と、MySQLとPostgreSQLに分割してって遊んだことがあるなー。
いや、遊びといってもテストですよ。テスト。）

じゃ、WEBも故障時に切り替えられればいいんじゃないの？そのレベルでいいのでは？
これは思えば、「TOC：チェンジ・ザ・ルール」で言っていたケースだ。

クラウドにより制約がなくなった。もしくは、無視してもいいようになってきた。
にも関わらず、相変わらず、構成は昔のままなので、その対策であったポリシー自体が今度はボトルネックになってしまうのだ。

（というか、個人的には、ロードバランサがあり、また、WEBの多段層化のおかげで、
その後工程でとまどっているにも関わらず、次から次へとリクエストを受け付けて中間層でパンクしてどうにもならない。というケースをよく見た。
まあ、要するにアプリがバグっているのだが・・・ApacheやDBにほぼバグは発生しないことを考えればしょうがないが・・・
ただ、だったら、WEBでリクエストを絞って受け付けないほうがまだ顧客のためだ！という思いもある・・・）

私の今のクラウドの理解が正しければの話ですが・・・・・
いやー、このあたりが本当かどうかを実際にためしてみたいものですが・・・・

mod_chxjは、現在、端末の識別設定をXMLで行います。

補足）mod_chxjとは、ドコモ向けにに書かれたhtmlをサーバ側で自動的に各キャリアごとにhtmlの変換やら、画像サイズの変換やらをやってくれるApacheのモジュールです。

まあ、XMLというフォーマット自体もちょっと面倒といえば面倒なのだが、
それ以上に、端末の識別が正規表現というのが非常にめんどくさい。

かといって、CSVやTSVから端末IDからすべて設定というのも、オープンソースという性質から考えてちょっと不親切ですよね。
（だって、端末情報を含めてきちんと提供できるわけでもないわけですから・・・）

特に最近は、「３Gの端末で、とりわけひどい状況にならなければいいんじゃないの！」

という感じで携帯サイトを運用したいと考えれば、１つ１つの端末に対する設定ということをしなくてもいいという判断もあり得ます。

であれば、正規表現でいいのだが、それだと、例外が面倒です。

もちろん正規表現は非常にパワフルなので、できることはできるのだが、例外くらい個別に指定できる方が直感的に理解しやすい。

たとえば、DoCoMo/2.0の端末はほぼ、XHTMLのフォーマットが使えるらしい。
ただしDoCoMo/2.0にも関わらず、D2101V、P2101V、SH2101V、T2101V、N2001、N2002、P2002の端末がXHTMLはだめらしい。

と、ここでふつうにやりたくなるのは、パターンでDoCoMo/2.0の端末はすべてXHTMLでフォーマット。
D210V、・・・・は、個別に例外で除外。つまり、ほかのフォーマットを適用。

ということをしようとすれば、何らかのパターン表現のフォーマット＋個別指定のフォーマットというのが理解しやすいいうことになる。

ということで、mod_chxjにTSVから端末情報を読み取り、上書きできるようなパッチを作成し、オリジナルに返しました。
（まだ、反映はされていませんが・・また、以前述べたよう（下記、関連する記事を参照）にこれ以外にも、XHTML関連のCSS対応も返しているので、こちらと合わせて、
だいたい私的に、XHTML端末のサイトを運用するのに、mod_chxjでカバーできるようになったとおもう。）

最近、端末性能が良くなって、以前ほど、画像サイズだ、なんだと気にしなくてもよくなってきたので、
ルーズな運用用途のニーズもあるのではないでしょうか？
まあ、そんな運用にも耐えやすいのは、オープンソースという特性ならではでないでしょうか。

でも、きちんとサービスを継続していくと、結局、個別の指定も必要になってしまうんだけどね。
そこまでの過程としても、いいだろうし・・・・

ということで、結局、個別の指定が必要なんだよねとなってしまったサイトにも、メリットがあるように、
さらに、ちょっとしたおまけとして、TSVでは任意の項目を定義できるようにしました。

mod_chxjで管理していない端末情報をリクエストヘッダに設定するようにしましたので、
使い方によっては、もっと応用できると思います。

オリジナルに反映される頃には、具体的な指定方法とか、使い方を記述できたらと思います。

ちょっと、たまたま、あるサイトのURLで検索をかけたら、以下のサイトの結果が検索対象になった。

http://bizinformation.org/jp/

まあ、ちょっと面白そうなので、自分でもやってみた。
ほー、金額はいざ知らず、PVやユーザ数がなかなか近いではないか。
少なくとも、オーダーはあっている。

ほかに、PVなどを知っているサイトをやってみたが、これもなかなか近いのである。
んー、どうやって、そのあたりを予測しているのか、それが興味がある。。。。。

あとは、どうして、こういうサイトの結果が検索エンジンに引っかかるのかなーと疑問に思ったが、
まあ、これは自分の行動で読めた。

まあ、こうやるからだ。
自分で原因つくってりゃ、そりゃそうだわな。

さて、今回は前回の宣言どおり、configure;make;などの流れです。
これらのツールを autoconf と automakeといいます。

といっても、私も意味がわからないので、とりあえずは、以下を参考にしました。
http://www.02.246.ne.jp/~torutk/cxx/automake/automake.html

autoconfや、automakeで検索すると参考になるようなサイトはそれほどないので、それぞれ見てみるのもいいと思います。
最初は意味を理解して処理をしているのではなく、手順として処理をしているので、
ディレクトリ構造のちょっとした違いだけでもはまってしまいます。（しまいました。）

これらを参考に私も、ほぼ同じように作ってみました。

用意したのは、
/Makefile.am
/src
+-- part1.c
+-- Makefile.am

par1.cの内容

#include <stdio .h>
#include <stdlib .h>

int main(int argc, char const *const *argv, char const *const *env)
{
  printf("Hello \n");
}

と例の単なるHelloを表示するだけのプログラムです。

しかし、処理のいたるところでワーニングが出まくります。
無視していいとは書いてありますが、記載ている内容と行っているないように違いがなければ無視していいかもしれませんが、
なんせ、ただ真似ているだけの身として、結果としてうまくいかなかったときに、ただやみくもに探しては時間がかかります。

そこで、もう一度、gccなどを使って、プログラム自体に間違うがないということを確認する上でも、コンパイルだけでもできるようにしておきましょう。

gcc -o part1 part1.c

と、実行してください。-o で出力するファイル名が指定できます。
いやー、恥ずかしながら、私はこのレベルから調べ始めなおしました。

さて、今回の復習。

１）プロジェクトのTOPディレクトリに Makefile.am を用意し、ソースのパスを指定する。
２）ソースディレクトリにMakefile.amを用意する。

３）autoscanを実施し、その結果(configure.scan)からconfigure.ac を作成する
　このファイルを編集し、utomakeを使うための記述を行う。

私の場合には、以下の２行を編集・追加を行いました。そのほかは、変わりありません。

AC_INIT(part1, 1.0,[coltware@localhost] )
AM_INIT_AUTOMAKE([foreign])

４）以下のように処理を行う。

aclocal
autoheader
automake -a -c
autoconf

の順に処理を行う。
これで、configureの作成完了。あとは、いつもの通り。

さて、ここまでは、ほぼ、このプロジェクトのみで依存関係が完結しているために、
簡単でしたが次回からは、ここに、aprというApacheで使われている基本的なライブラリを使うあたりまで説明したいと思います。
そして、libxml2とtidyなどを使っていきたいと思っています。