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

Archive for 5月, 2010

Adobe CS5のバージョンアップ版が届きました。
Adobe CS4 Web Standard からのバージョンアップで、Web Premiumになりました。
StandardからPremiumになったことで、イラストレータと、Photoshopがつきました。

また、FLASH CATALYSTなるものがあるのですが、これが実はまったくその効果がわかっていません。

ということで、週末にでもインストールして、ときどき遊んでみようかな－と思っています。

あるソース、ソフトウェア商品の管理をしていると、プロパティという解決方法がよく出てくる。
「ここのプロパティを設定に２すると、今回上がった要望に応える事ができますが、１を設定すると既存には影響がありません。」

たいていの場合には、こんな解決方法で話し合いをしても異論がでない。

なぜなら、プロパティにより新たに状態を作成し、その状態のみに影響範囲を押さえることにより、
新規に追加したソースや、変更したソースの影響範囲を小さくするのだ。

しかし、これは非常に麻薬的効果だ。

麻薬だって適正に使う前提であれば、それが医学を大きく進歩させることもできたが、
使い方を間違えば、おかしな状態になる。

しかも、麻薬と同じく、１回の利用では問題が無くても、いつの間にか中毒になってしまうのだ。
そして、その麻薬の悪効果を抜き出すのに非常に多くの時間とコストがかかってしまう。

皆さんの周りにもそのようなシステムはないだろうか？

プロパティという麻薬の中毒度は以下のような感じで見れる。

１）プロパティにデフォルト値がない。（つまり、設定なしでは動かない）
２）カスタマイズではなく、プロパティの設定で対応可能です。の営業トークが多すぎる。
３）ユーザの為にマニュアルが書けない！と声を大きくしてアピールしている
４）関係者が、「プロパティ対応というすばらしくいい方法を見つけた！」と心酔している
５）エンジニア達がまた「それはプロパティ設定の問題だ！俺たちのバグじゃない！」などとお客からのクレームに反応している。
６）エンジニアが運用業務の情報や規模はソフトウェア構築後でも対応可能だ！と言っている。
７）高い技術の人材を投入してもあまり効果がでない。
８）妙に意味のわからない設定のドキュメントがあり、それと常ににらめっこしている気がする。
９）設定の達人なる人がいる。

こんな感じの項目に２，３当てはまりだしたら、危険になりつつある。
早急に方針の再確認をしたほうがいいだろう。

今回は前回のFlashのオブジェクトをJavaのオブジェクトに変換するの逆です。
Javaから、Flashにデータを変換します。

Date date = new Date();

Amf3Output output = new Amf3Output(new SerializationContext());
output.reset();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
output.setOutputStream(baos);
output.writeObject(date);

output.flush();
byte[] data = baos.toByteArray();

Base64 base64 = new Base64();
String base64str = base64.encodeToString(data);

//  ここでBASE64のデータをXMLSocketを通じてFlash側に渡してあげます。
e.getChannel().write(base64str);

//  これを忘れてはいけません。これがないと、XMLSocketは終わりを認識できません。
e.getChannel().write("\0");

前回、Base64の処理はBlazeDSについていたjarを利用しましたが、
Jakartaのcommons-codecに変更しました。

こんどはFlash側ですが、こちらは、

var str:String = event.data as String;
var bytes:ByteArray;
var b64:Base64Decoder = new Base64Decoder();
b64.decode(str);
bytes = b64.flush();

var obj:Object = bytes.readObject();

とこんな感じになります。

非常に簡単にできました。

要するにAMFのデータをJava側で処理する方法です。
しかし、httpのプロトコルを使っての話ではないです。

たとえば、AMF3のデータをBase64してそれを、再度Javaで復元するという感じです。
具体的には、XMLSocketを通じてやりとりをしてみます。
XMLSocketのサーバについてはこちらにて多少説明してあります。
httpプロトコルを使わないのは、Flash側に簡単にpush配信ができるからです。
まあ、ずーとコネクションを張っていますから、そりゃできますよね。

でも、http通信を使ってもクライアント側にpush配信できるソリューションがあるので、
どうやっているのかなーと思ったら、keep-aliveでずーとコネクションを張りっぱなしにしてトンネルするのですね。知りませんでした。
（この方法、XMPPを見ていて知りました。）
そんなことをやろうとも思いもしませんでしたが、確かに、httpサーバを作る側になったときに、
keep-aliveでセッションを張られたときにいったいいつコネクションを切ればいいのかというのが悩みの種という思いをいただいた記憶がありました。
idleタイムとかでやるしかないのでしょうが・・・・めんどくさいです。でもサーバですからね。。。。

それと、PHPなんかには、AMF3のデータを処理するライブラリがたくさんあるのに、Javaにはないのかなーと思っていたら、
本家(Adobe)から出しているので、ないのですね。

さて、それではJavaのライブラリの取得方法は
本家から、BlazeDSのBinaryをダウンロードしてきます。
次に、blazeds.warがありますから、これがZIP圧縮されていますので解凍して、
\blazeds\WEB-INF\lib
にある
flex-messaging-common.jar
flex-messaging-core.jar
を取得して、これをJavaのクラスパスに設定できるようにしておいてください。

さて、AS3側の処理です。簡単なのでかなりはしょっていますが、流れを見ていただければ・・・

var sock:XMLSocket = new XMLSocket();
sock.connect(HOST,PORT);
:
public function send(data:*):void{
	var bytes:ByteArray = new ByteArray();
	bytes.writeObject(data);
	var b64:Base64Encoder = new Base64Encoder();
	b64.encodeBytes(bytes);
	sock.send(b64.toString());
}

のように、どんなオブジェクトでもByteArrayからBase64してXMLSocketへ投げます。これで、as3側はOKです。

次にJava側ですが・・・
再度、XMLSocketのサーバについてはこちらにて多少説明しています、そして、そのソースを再利用しています。

//  ここで送られたBase64の文字列をどうにかして取得する。
String request = (String) e.getMessage();

Decoder base64 = new Base64.Decoder();
base64.decode(request);
byte[] data = base64.flush();
ByteArrayInputStream bais = new ByteArrayInputStream(data);
Amf3Input input = new Amf3Input(new SerializationContext());
input.setInputStream(bais);

log.debug("request object:" + input.readObject().getClass());

と、Amf3Inputというオブジェクトを使ってあげればよくて、そこで、readObject()を使えば、オブジェクトが取得できます。
たとえば、AS3のDate型のオブジェクトを渡せば、Javaでは、java.util.Dateの型になるという感じです。

次は、JavaのオブジェクトをAS3側で扱えるようにしてみたいと思います。

gitの環境のほうにmod_chxjの変更分を取り込んでもらいました。
こちらから参照することができます。

今回の変更は、ずいぶん前になるのですが、端末情報をTSVから読むがメインです。

この機能は、mod_chxj特有の端末情報をXMLで管理するものからtsvファイルで管理できるようになっているので、
XMLがちょっとという方でも端末情報が簡単に管理できるようになります。

また、mod_chxjが定義した変数以外でも自動的にリクエストヘッダに値を加えるので、
mod_chxjが端末情報を識別した結果が、プログラムなどでも使えるのでかなり便利になると思っています。

gitからチェックアウトしなければ使えませんが、簡単にXHTMLの携帯サイトを作りたい方などはこちらを是非お試ししてください。

と使い方をきちんと説明する予定でしたが、この説明は次回にさせてください。

はじめに

今はまさに、クラウドの時代が到達しつつある。
メールなどは私もgmailを使っているように、コンシューマレベルではある意味クラウドを利用している。
そして、今後その流れはより加速されていくだろう。
この流れは、ビジネスの領域、つまり会社内にも少なからず影響が出てくることは間違いない。

クラウド導入での問題点

しかしながら、クラウド導入でいいことばかりだろうか？
特に、コンシューマレベルと同じように企業内の業務も浸透するにはちょっと無理を感じる。

そもそも、なぜクラウドは安いのか？
それは、基本的にはあいている共用リソースを足りない部分に補えるからだ。
そして、ある使い方（時間）では、余ることが想定されているからだ。
また、同じ事を同じレベルで提供するために、規模のビジネスが通用する。

ここで、もっとも恩恵を受けるのは、CPUという計算コストだ。
これについては、全く異論はない。

しかし、データという事であればどうであろうか？

いやいや、データはgmailは8Gなのに、会社は1Gもないよ！
という事もあるのはあるが、そもそもデータがハードディスクだと言い切れば、同じようにクラウドは安い。でも本当にそれだけだろうか？

つまり、データのコストはハードディスクの容量だけではないのだ。
企業では、データを持つことで同時に以下のようなコストも負担している。
 セキュリティコスト
 他システム、サービスとの連携
 回線料（ローカルにないということはそれだけ、回線も太くなくてはならなくなる。）

という具合だ。
まあ、回線はどうなるかはわからないが、現在企業が支払っているコストでセキュリティはものすごーく高い。
インターネットを見せるメリットよりも、見せないメリットの方が大きいと判断している企業だって多々ように、誰もがデータをいつでも見えるという事に価値があるとは思っているわけではなく、いつでも見えるという問題から、見えなくするというコストを支払ってる金額も相当なものなのだ。ただ、便利なサービスになれてしまったコンシューマが、いざ、会社の中の企業人になったときのギャップは相当なものになるだろう。

ぐちぐち言っていても仕方がない。
エコポイントの情報だってクラウドなんだぜ！
今更なにいってんだ！どんどん情報も海外にながしちまえ！

というのは、受け入れてもらえるだろうか？
また、みんながそれでいいのだろうか？

３層構造という思い込み

でも、それって、こういう技術構造を思い描いているからではないだろうか？

だから、データも一緒にクラウドに・・・という発想になる。
でも、ロジック(CPU)処理が激安になるのだったら、この構造変えてもいいんじゃないでしょうか？

３相構造

私が思うのは、部分的（同じネットワーク空間の制限内のもの）には３層構造であることは変える必要が無いと思う。
がしかし、

こんな３相（同じ立ち位置という意味で「相」）構造がいいのではないだろうか？
なんじゃこりゃ？と思った方もいるかもしれないが、実はこのような実装はあながちあり得ない話でもなく、ある場所では結構増えてきている。
その場所とは大規模サイトのようなところだ。
ただし、表示・ロジック・データすべてが純粋ではいない。（かなり汚れている！？）

データは計算に必要な部分だけに分解され計算されている。
そして、表示の時に、その計算結果とデータをつきあわせて表示を行っているのだ。

このような実装を見ると、「基本がなっていない」という思う方もいるかもしれないが、いろいろな事情でそうなのだ。基本は基本だ。目的と前提が変われば、それを応用していかなければならない。
たとえば、データを守るDBはOracleであっても、計算上必要なデータを一時的に保持するサーバはMySQL(PostgreSQL)とような感じだ。
これは、クラウドの問題を見据えてそうなったわけでもないが、DBという値段を考えると必要な場所に必要なだけのコストしかかけられないという経済力が加われば自然とそうなる。そして、必要なデータ以外はいらないと・・・
これを研ぎ澄ましていけばいくほど、「３相構造」に近くなる。

それにオブジェクト指向って、必要なデータと必要な処理の固まりなわけで、オブジェクトとして自立して機能してほしいと考えたら自然な流れともいえなくもないだろうか？

クラウドにおける「３相構造」

この大規模サイトのテクニックの「３相構造」は、クラウドによって社内サーバが縮小していくなかで、より広い範囲で重要性を増すと私は思っている。
クラウドにより、最小限までデータ保存の責任は小さくできる。極端な話、クライアントの端末にあればそれでいいという事だっておかしくない。
（PtoPで、みんなで持ってしまえばバックアップだって万全だ。）

こんな感じだ

つまり・・・

だからクライアント型RIAに価値がある。と思っている。
この表示の為の合成と、計算の為の分解を行う為にはクライアント上でアプリケーションが動く方が都合がいい。
入力されたときと、出力されたときを制御するのは人だ。それを検知できるのはやはり、そのツールだ。そして、データを見るときに正しければそれでいい。
それが管理を安くするためにも必要なのだ。
（だれも見ていない深夜のデータまでも、正しいのかを確認するのはかなり高いコストがかかる。）

計算はクラウドによって安くなった。バッチ処理なんていう概念は必要ない。
いつだって、差分を計算していけばいい。間違いに気づけば、その間違った時点から計算し直せればいい。

従って、クラウドがある程度浸透したら、こんなクラウドのサービスとクライアント型RIAがセットになったサービスが出てくるだろう・・・と思っている。

と、数年前から何となく思っていたことが、もう少し表現できるようになってきたので私のイメージを書いてみました。
具体的には、AIRだけでは足りない気がしてきたので、前回と前々回の
Flashとローカルマシンとの共存
Flashとローカルマシンとの共存 ( XMLSocketを使ってみる)
なんかのような感じでAIRを補完していければ私のイメージに近づけるかも・・・という気がしてきた。

昨日の続きであるが、ローカルマシンとの接続はXMLSocketを使うことにしてみた。
とりあえず、これで思うようにできるのか、試してみることにした。

XMLSocketは、AIR以外でも使えるSocket通信だ。
いろいろ、セキュリティ関係はみれていないので、まだまだよくわからないところもあるが・・・

XMLというとなんか、定義されたルールがあるのかと思ったら、
要するに、テキストしか送受信できないSocket通信のようだ。

また、サーバのフレームワークにはnettyを使うことにした。
どうやら、MINAとnettyを作った（ている）人は同じ人らしいが、現在はnettyの方をやっているらしい

ここでは、nettyについて詳しく述べないが、夜にちょっと調べたレベルでも、簡単なサーバが作れる。
実際の受信して、返信するレベルの実装は、こんな感じだ。
（ただ、まだまだ意味がわからず書いているところも多少あるが、どれだけ簡単なイメージかはつかめるかと思う）

package com.coltware.airboost.netty.flash;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.jboss.netty.channel.ChannelFuture;
import org.jboss.netty.channel.ChannelHandlerContext;
import org.jboss.netty.channel.ChannelPipelineCoverage;
import org.jboss.netty.channel.ChannelStateEvent;
import org.jboss.netty.channel.ExceptionEvent;
import org.jboss.netty.channel.MessageEvent;
import org.jboss.netty.channel.SimpleChannelUpstreamHandler;

@ChannelPipelineCoverage("all")
public class FlashXMLSocketServerHandler extends SimpleChannelUpstreamHandler {

	private static Log log = LogFactory
			.getLog(FlashXMLSocketServerHandler.class);

	@Override
	public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e)
			throws Exception {
		log.debug("channelConnected ... " + e.toString());
		e.getChannel().write("hello\0");
		super.channelConnected(ctx, e);
	}

	@Override
	public void messageReceived(ChannelHandlerContext ctx, MessageEvent e)
			throws Exception {
		log.debug(e.getMessage().getClass());

		String request = (String) e.getMessage();

		log.debug("request: " + request);

		String response = "say what!?\0";

		ChannelFuture future = e.getChannel().write(response);
	}

	@Override
	public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) {
		log.warn("Unexpected exception from downstream.", e.getCause());
		e.getChannel().close();
	}

}

これは、Flashの方から、接続すると、「hello」が返され、何かメッセージを送ると、「say what!?」と返すだけのサーバだ。
少なくとも、これで、merapiのサンプルで書かれていたレベルの基盤はほとんどできてしまっている。

通常、サービスを止める場合には、シグナルを送る（Unix/Linux)とか、管理ポートを開いてそこで、管理コマンドを受けるとかあるが、
私は、JMXを利用した。

後は、送る文字列と送信する文字列をAMFベースにしてしまえばいいわけだ。
ただ、バイナリが送れるかわからないので、そのあたりはbase64してしまえばいい。

また、nettyのいいところは、httpの通信を標準でサポートしているので、httpベースのサーバも簡単に作れるので、
もし、XMLSocketがだめなら、別の通信と、通信プロトコルは好きに定義すればいい。

AIRでアプリを作っていて、いくつか悩みが出てきた。
バックグラウンドとして、安定して処理をするにはActionScriptで大丈夫なのだろうか？

ということだ。
これは、速度についてもあるし、たとえば、自分が端末の前に座っていない、深夜に処理をやってほしい。
などなど・・・・

具体的には、処理があいているときに全文検索の為のインデックスをつくれないかなーとか・・・・

でも、ActionScriptで、そもそも全文検索DBの構築をするための処理を書くのは、Javaなんかでさんざんいろいろなものがあるのに、
することじゃないだろうなー。と。

んー、やっぱり、100% AIRでクライアントツールを作るのにも、どこかで無理があるのかな。
でも、そのためにインターネット上にサーバを用意するのは、ちょっと考え物だし・・・・

つまり、ローカルでサーバが動いている必要がでてきてしまう。
まあ、Tomcatとかを動かしてしまえばいいのかもしれませんが、やっぱり、
ちょっと気分的にそれは重いかな・・・・

と、まずは探そうとおもったら、
Merapi
というものがありました。

AIRとJavaのブリッジだとあります。
ちょっと、ソースを見てみると、127.0.0.1のポート12345を使って、Socket通信している感じ。
（よくは調べていないので、そうでないかもしれませんが・・・）

んー、これだと、自分で作り込んじゃっても、それほどかわらないかなという感じです。

それに、これをソケット通信にしないで、127.0.0.1のサーバとHTTP通信すると、
AIRだけでなく、ブラウザ上のFlashからもアクセスできるのかな？

まあ、セキュリティも問題もあるが・・・・
でも、技術的なセキュリティ問題の回避の為に、根本的なセキュリティを許容するのも本末転倒だし。
（つまり、ネットワーク上に上げる必要も無いデータを、加工するためだけにネットワークに上げるという意味。）

ローカルホスト上に、基本的な機能（DB、File、ネットワーク）なんかの操作APIを提供するサーバがあれば、
配布はWEB（ブラウザ上のFlashという意味）で行って、ローカルアプリのような事ができる。
どうも、最初のAIRの配布方法と実行条件に難があるのですよね。
あと、あのアプリへの署名。
お手軽アプリを作りたいだけなのに、「危険です」みたいなものを表示し続けなければならないのは、ちょっと・・・・

特に最近のWindowsなどは、管理権限などもうるさく（？）なり、簡単にローカルアプリはインストール・アップデートできなくなったことを考えると、
AIRの位置づけが微妙だなという認識が消えないのです。

でも、やっぱり、ローカルで何でもできるようなサーバがたっていて、それにアクセスできるのは明らかにセキュリティ上の穴だし・・・・

まあ、とりあえずは、その何でもサーバを作ることを考えてみると、いいアイデアや、情報が見えるかもしれません。
そもそも、AIRでないFlashアプリが127.0.0.1にアクセスできるのかも今は知らないのですが・・・・

と、Javaでお手軽サーバを作ろう、せっかく作るのであれば、HTTP以外のプロトコルも簡単にあつかいたいなーという欲も出てくる。

ならばと、調べると、
Apache MINAとか、nettyのようなものをベースに作るのがらくかなーと。

と、Flex4もまだ浸透していないし、AIR2もまだリリースされていないし、
当分、Javaのほうに足をつっこもうかなと思う今日この頃です。

さて、４月もすぎ、なぜか今頃になって評価シートやら、目標設定などをすることもおおいのではないだろうか？
私は、２ヶ月に１冊くらいはプログラミングとは関係のない本を読むようにしている。

そこで、なんかしっくりくる言葉さがしをしているような気もする。
そして、今回は、「コラボレーション」という言葉をこの本から。

さて、読んだ本は、下の本だが・・・

そこで、「co(= together) + labor 」　つまり、「ともに生み出す」という意味だと紹介しており、今後、生産者と消費者がともに生み出す技術力が大切だと紹介している。

これを読んで、私は別のことを考えた。
はじめに戻るが、よく、「コミュニケーション能力の向上」などのような目標項目があるが、
多くの人は「コミュニケーション」とは何を指しているのだろうか？「分かち合うこと」、それは同情を求めているのだろうか？こちらの事情も理解してくれよ！と。
だったら、こちらの事情も理解できる「コミュニケーション能力」もほしいのだけど・・・と思ってしまう。

ある人は、「俺は部下と週末にゴルフに出かけて、コミュニケーションをとっているのに、君は休みの日に何をしているのだ！」と怒られたこともあったが、
コミュニケーションの意味をはき違えていると思うし、仮にはき違えていないと１００歩ゆずっても、休みの日の行動までとやかく言われたくはない。

このように、「コミュニケーション」とは何か？を共有するだけでも、難しい。
でも、これを「コラボレーション」に置き換えたらどうだろうか？

まさか、コラボレーションを週末の一緒のゴルフにはき違える人はまずいないだろう。
先ほどもcollaborationは、co + laborが語源だといったが、laborといったら、「労働」だ。まあ、この場合は「生み出す」という意味らしいが、それが転じて、「労働」になったわけだと書いてある。

つまり、仕事を通して必要なのは、「コラボレーション」だろうと。

そして、これは私のイメージでもあるが、コミュニケーションといえば、同じ価値、同じ力、同じ情報を共有する力。の意味合いが強いと思う。
でも、異なる人が同じ物とそのとらえ方を共有する必要が、それほど重要だろうか？

「コラボTシャツ」という言葉がある。
この言葉を見て、
アシックスとアディダスがコラボして、Tシャツを作ったんだよ。はあまりぴんとこないし、魅力もそれほど感じない。
（もし、本当にあったらすいません。）

でも、ガンダムとユニクロがコラボして、Tシャツを作ったんだよ。
は、やるなーと思ってしまう。
ガンダム好きには、「ガンダム」のTシャツ。ユニクロ好きにはガンダムがプリントされた「Tシャツ」だ。
価値観によって、主と従の関係が逆転する。

「ガンダム」と「ユニクロ」が同じ価値観を持っているとは思えないし、むしろ、全然関係ない気がする。
でも、「アシックス」と「アディダス」はそれに比べれば、かなり同じ価値観を持っているだろう。

つまり、「コラボレーション」とは、お互いに価値観を理解し合う必要はない。
むしろ、価値観が違う物どうしが同じものを共有するから、新たな価値が生まれる。

職場でも同じではないだろうか？

部長と、部下が価値観を共有できるだろうか？
経営者と従業員が同じ価値観を共有できるだろうか？
だいたい、同じ情報すら持っていないのに、ありえない。
そこで、同じ価値観の共有はあり得ない。

だったら、はじめから共有できない前提でも、ことが進む「コラボレーション能力」という言葉を使った方がよりいい気がする。

そして、この本でも言っていることだが、今までは、「作られた価値の提供」から、「未知の価値創造の共有」へと時代が移り変わっている。
だから、「コラボレーション」なのだと。

まあ、単に言葉を入れ替えただけととらえることもできるが、
そう入れ替えることで気づくこともあるのではないでしょうか？

それと、この本には「ロバストな技術」という言葉がある。
ロバストという言葉自体、私はよく使うが、周りには使っている人をみたことがないので、ちょっと、安心。