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

AIRのいいところは、標準にあるWindowをカスタマイズできるところです。
しかしながら、なかなか、手を出すのが面倒でやっていなかったのですが、ちょっと試してみました。

作ってみた画面は以下の通りです。
このような画面を作るのに、Javaなどで作るのは非常に面倒なのですが、AIRの場合には慣れてしまえば、HTMLを組んでいるように簡単に作れます。

このような画面も、なれないデザイン込みでまあ、一晩もあればなんとかなるというレベルです。

さて、まず、カスタマイズをするために、いくつかの準備が必要です。

1. アプリケーションのXMLでsystemChromeをnoneに設定します。
2. アプリケーションのXMLで同じくtransparentをtrueに設定します。
3. WindowedApplicaitonのshowFlexChromeをfalseに設定します。

これで、完全にデフォルトのコントロールが外れましたので、後は自分で部品を作っていきそれらを並べればいいというわけです。

でも、このようにカスタマイズすることで、自由に配置できるのはいいのですが、このために以下のようなことは自分で処理を書かなくてはいけません。

• ウィンドウの最小化・戻す・最大化・閉じる（右はじのボタンたち）
• ウィンドウの移動
• ウィンドウのリサイズ

ただ、メソッドを呼ぶだけでこれらの機能が実現できるので、あまり心配はいりません。
ウィンドウの最小化、戻す、最大化、閉じるは、
NativeWindowの

minimize();
restore();
maximize();
close();

で実現できますし、ウィンドウの移動は、startMove() でできますが、もともと、上部のバーを消してしまったので、私はロゴマークか、もしくは、濃い青い部分でmouseDownしたら移動ができるようにしてみました。

<mx :HBox top="10" left="15">
  <mx :Image source="@Embed('assets/logo.png')" mouseDown="nativeWindow.startMove()" useHandCursor="true" />
</mx>

あと、リサイズは小さくて見えずらいのですが、左下に△のしるしを置き、そこでmouseDownしたときにstartResize()が動かせばリサイズができるようになります。

startResize();

airのHTMLコンポーネント(mx.controls.HTML)で、ローカルにあるHTMLファイルを読みたい。

この場合、には、

var file:File = File.desktopDirectory.resolvePath("index.html");
var browser:HTML = new HTML();
browser.location = "file:///" + escapeMultiByte(file.nativePath);

のように、頭にfile:/// をつけるのと、パスに日本語が含まれることを考え、escapeMultibyte()関数を使ってあげればよい。

ただ、これを使うと、そこまでエンコードしなくてもというところまでエンコード（エスケープ）されるが、見えるので問題はない。

それと、ローカルにあるファイルゆえに発生する問題がある。
文字コードがHTTPのヘッダで指定できるわけではないので、HTMLファイル自体にキチンと文字コードをmetaタグに書いてあれば問題ないが、
記述がない場合にはたいていの場合には文字化けを起こすだろう。

この場合には、ブラウザ側で文字コードを指定しなければならないが、残念ながらHTMLのクラスを見ていても直接の設定はない。
この場合には、内部のプロパティである、htmlLoaderオブジェクトを通して設定する必要がある。

browser.htmlLoader.textEncodingOverride = "Shift_JIS";

とこんな感じだ。

今回は、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で管理していない端末情報をリクエストヘッダに設定するようにしましたので、
使い方によっては、もっと応用できると思います。

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