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

Archive for the ‘開発’ Category

Javaを使ってAMFからJavaのオブジェクトにするときに、Classがみつからないとはまった。

というのも、今まではAMF3Inputも、見つけたいクラスも同じクラスローダー上であったので、

SerializationContext ctx = SerializationContext.getSerializationContext();
Amf3Input input = new Amf3Input(ctx);
input.setInputStream(bais);
Object ret = input.readObject();

とすれば、なんの問題もなかった。

しかし、readObjectをする前にどうしてもオブジェクトのクラスローダーを指定する必要がでてきたのだ。
これは、たとえばユーザが作ったjarを個別に読込（別のClassLoaderで）、
そのjarの中からオブジェクトを作成するときなんかには必要になるのだが。。

でもって、Amf3InputでClassLoaderを指定するには・・・・
以下の方法でできた。（これで正しいのはわからない。。。）

//  現在動いているスレッドのClassLoaderを取得
//  ここで目的のClassLoaderを作れば、それで自分好みのClassLoaderを指定できる。
ClassLoader loader = Thread.currentThread().getContextClassLoader();

SerializationContext ctx = SerializationContext.getSerializationContext();

//  ここでClassLoaderを指定する。
//  ただし、次のおまじないも必要
TypeMarshallingContext.getTypeMarshallingContext().setClassLoader(loader);

//  ここで、Message.classのインスタンスは別の方法を使って作ってね。という指示。
//  こうすることで、どうやら上で指定したClassLoaderを使う。
//  この指定が無いと、ClassLoaderを使ってくれない。
//  ここではまった！？
//  ただ、BeanProxyで本当にいいかわからないが・・今のところ問題はない。
PropertyProxyRegistry.getRegistry().register(Message.class, new BeanProxy());

Amf3Input input = new Amf3Input(ctx);
input.setInputStream(bais);
Object ret = input.readObject();

とこのようになるらしい。
AMF3Inputのソースを調べていったらそうだった。というメモ書き。

なんの事かと言えば、FlexというかAIRというか・・・・
これに対してローカル上でJavaのプログラムと連携したいということだ。

http://code.google.com/p/flerry

というプロジェクトをひょんなことから見つけた。
こういうのが、誰から教えてもらうわけもなく、調べるわけでもないのにわかるのが、自分で情報を作ってわざわざ公開することの利点だろう。
さすがに、仕事としてプログラムから離れていくと、こういう感覚からは遠のいていく・・・

さて、私もAIRをやっていてちょっと、ActionScriptだけでアプリケーションを作るのはやっぱり限界があるな。と感じた。
やっぱり、ローカルのJava(でなくてもいいのだが）と連携したくなるよな。と。

でも、上のソースはNativeProcessで連携するらしい。
それはそれで、安直だが、すごい割り切っている。

私が、AIRだけでは・・・と思うようになったのは、
パブリックサーバと連携するようないわゆる一般消費者向けRIAというものならいいのかもしれない。
やはり、AIRだけではないし・・・・、サーバはより一般向けにメンテされるし・・・

でも、今までExcelとAccessなんかでなんとかごりごりやってきた業務も含めてWEB化したいといったときに、
本当にWEB化でどうにかなるのだろうか？それに、WEBサーバ（アプリも含めて）なんて運用したい、もしくはできると思うのだろうか？
開発者はどうにかなるかと思うかもしれないが、申し訳ないが、現場の作業者には迷惑な話だろう。
何で、自分の手元のデータをサーバにアップし、サーバ上で加工し、ローカルに落としてこなくてはいけないだ。
何で、自分が使うときだけ動いてりゃいいものなのに、自分たちの管理の外の承認と許しをこわなけりゃならんのだ。
まあ、そう言っても、WEBサーバを運用してなんて言われても、「冗談でしょ！やだね。」
という感じが本音だろう。

でも、ASPやら、SaaSなんかの言葉に乗せられてしまって現場は火の車。
もしくは、売り上げ部門から、ASPやらSaaSを使ってコストを圧縮だ。とうるさい。

と、こんなケースにAIRは当てはまるかな。と思い、

メール配信がAIRからできるようにしたり、Zip（というかOffice Open XML形式）を読めるようにしたりしてみたが、
どうもしっくりいかない。

いざ、ソケット通信やら、DBアクセスやら・・・と非同期なのは、あまりにもやはりやっかいだ。
（んー、スレッドがほしい。せめて、３つだけスレッドが持てますって固定でもいいのだが・・・・）

あとは、Javaでたまりにたまった、ノウハウやら、ライブラリをまたAS3上に再構築するのだろうか？

と考えたら、AIRに限らず、Flashしかり、HTML5しかり、上のような業務RIAを考えたらローカルでJavaと連携することが、
開発者の調達の意味も含めてしっくりする気がする。

じゃ、すべてJavaってのはJavaの開発者の視点からすれば、AIRやらFlexやらのプレゼンテーションノウハウはさすがだよ。と思わざる得ない。
逆に、このプレゼンテーションノウハウを再度Java上で構築するのはJavaFXが広まっていないことからもわかるだろう。

あとはHTML5だよね。実際HTML5があればFlashのプレゼンテーションほどはいらないという場合もあるだろうし・・・

そうなると、やっぱり、ロジックはロジック、プレゼンテーションはプレゼンテーションと得意な言語を組み合わせて使えるようにすることが望ましい。

とこのように考える人が増えたかどうかはしらないが、
AIRとJavaを連携したいとおもう人は増えているようだ。

私は、XMLSocketを使って連携することがベストな気がしている。
HTML5には、WebSocketっていう同じ様なものがあるし。
(トリッキーなことをしなくても、全２重ってとこがGood、つまりポーリングなしでPush配信ができるんだよね)

でも、FlashだったらAMF、それが、たぶん、WebSocketになればJSONとかになるのかな。

というようなことを考えながら、構築中。
んー、でもJavaのモジュール管理をまじめにやろうとするなら・・・・OSGIがベター？

OSGIって、実際の開発現場では使えるのかな。わからん。

前回、Http proxyサーバの実装に挑戦してみたにて、

proxyサーバの作成が失敗したが、よい例を見つけたのでそれを参考に、週末に実装してみました。

そして、まあまあ形になってきました。
もちろん、単純にプロキシサーバを作っているのではなく、

出先でネットにつなげない、もしくは、ネットにつなげても非常に遅い、もしくはパケット代で課金されるから・・
という場合に、できるだけコンテンツをキャッシュしてしまおうという事です。
それと、ADサーバなんかにも、こちから余分にお金を払ってまで接続したくはないので、
ある特定のドメインにも、パケット代が課金される場合には接続しないようにするとか・・・・

というような感じです。

現在はまだ、
・SSL通信の時に、proxyができない。
　（SSLのコンテンツはキャッシュするつもりはありません。）
・コンテンツがgzipやdeflate圧縮されているときに、圧縮されたままブラウザに表示されてしまう。

なんかの問題があって、ちょっと、実用レベルにはまだまだですが、
自分自身で使ってみて、そこそこ動くようになれば公開します。

昨日の続きです。

さて、今回は「問題・障害・要望」の管理です。

少ない人数(3,4名程度)でASPを管理しなければならない関係上、思いきって諦める部分は諦めて、
締切、品質を妥当なレベルを維持していくということに関してはそれなりに経験し、苦悩してきたことなので、
多くの方の参考になれば幸いです。

そして、お客さんのところに行って、
「個人でやっているレベルかと思いましたが、だいぶ大人数でやっているのですねー」
と成果物を見て言ってくださった大手企業の担当者さんがいましたが・・・

このときは「してやったり」と思ったものです。

紙を使え・色を使え

１対１でサービスを提供しているケースでない場合、問題・障害・要望は、ぐちゃぐちゃで上がってきます。

「あーそれはバグだな」というケースも、お客さんは要望としてあげてくださるケースもあれば、
「使い方を間違えている」というケースも、「障害だー」と声を大きくしてくるケースもあります。

しかし、これらは調査の結果として「そうであった」ということなのですが、
「如何に顧客の意図を間違いなく早くつかむか？」
が、その後のスピードに大きく影響を与えます。
そして、それはお客様の満足度（心象も含めて）向上にも貢献していくのですから、重要です。

記入には紙を使うのが早いし、汎用的だ

お客さんから報告が上がったら、それを既定フォーマットの紙に記入します。
エクセルファイルや、システムだったりすると、ディスプレイが１つしかないのに、
お客さんと一緒に画面を見ながら、記入していくのに面倒です。

また、お客さんのところに行った時に渡される資料は紙しかもらえないかもしれません。

PC上のデータを紙にするのは簡単ですが、その逆は大変です。
まずは、紙でさばけるだけ、さばきましょう。

そして、それらのセットを２つ用意します。
１つは、種別管理（問題・障害・要望）毎と、もうひとつはお客さん毎です。

これで、お客さん対応の人も、問題解決部隊も、自分たちの軸で見ることができます。
あの情報はどこのフォルダだ！なんて、探す手間が省けます。
立場が違えば、視点も違います。営業中心だ、運用中心だと言わず、
双方で管理するにはコピーが簡単です。

そして、紙のいいところは、量があるということです。

このあと、それらをファイリングしていった時にも、
「結構問題があるなー」とか、このお客さんからは、意見がおおいなーなんてのも直観的にわかるので、

急に過去を引っ張り出したいときにも、データ検索に紙では問題（欠点）があるというかもしれませんが、
データ検索にはない様々なインデックが頭にあるという利点も考慮に入れる必要があります。
人間の記憶容量は意外に大きい物です。ただ、インデックス（思い出すきっかけ）がないので、小さいと思ってしまうだけです。

どんなお客さんなのかを、直観的に判断するには見た目感覚が重要

さて、紙で報告が上がってきても、言われていることが、「問題」なのか？「障害」なのか？「要望」なのか？
を判断する必要があります。

すぐにわからないような問題でも、言われている内容をよーく吟味しないとわからないかといえば、そうでもありません。
たいていは、今までの報告内容が重要なヒントをくれます。
しかし、お客さんにとっては１対１でも、こちらにとっては１対（大勢）です。
１つ１つの会社について機械のように覚えきれていることを求めるのは酷というものです。

ここでSI企業ならば、過去のお問合わせをDBから引っ張りだし、そこで画面に出すなんてことを言うでしょう。
でも、そもそも運用がこれで固まっているわけでもありませんし、
せっかく（？）少ない人数なのですから、「つーかー」で済ませられる部分に新たな負荷を設けたくありません。

と、ここで、「色」の登場です。
お客さん毎にバインダーファイル（コクヨとかの）があり、そこに「色」があります。
この色でなんとなく、お客さんの性質を管理します。

当然「赤」は要注意です。それは、重要顧客かもしれませんし、こちらのミスで非常にケアしなければならない顧客かもしれません。
また、「黄色」「青」とか、数色で管理します。
エクセルとかだと、自分たちで管理したい項目をたくさん作り、結局は管理する工数が大きくなってしまいがちですが、
もともと、曖昧で境界線がないものを、無理に境界線をつくるより、曖昧なままで管理する方が、
根拠のない数値の羅列よりは伝わる情報は多く、そして早いです。

状況が変わったと誰かが判断すれば、色紙を張るなり、差し替えるなりしましょう。
部分的にステータスが異なる事項ならば、付箋の色で管理しましょう。
付箋の色がたくさんつき始めたら、誰かがファイルの色を変えるでしょう。

枚数で、過去と現在の雰囲気を把握

紙でやっていれば、当然、古ければ古いほど、または、報告が多ければ多いほど枚数が増えてきます。
また、終了済みとそれ以外でバインダーを分ければ、

これで、「あー、結構この会社にはやっちまってるなー、まだまだ、完結していない報告があるのかー」とか、
「おいおい、最近障害が増えてきてるが、さばくのがおそいなー」とかもわかります。

よくつかわれるバインダーはそれだけ汚れるし、あんまり使われないのはきれいだし、
そして、何よりバインダーの場所からも各担当者がどのように考えているかも見えたります。
（資料のしたーの方にあるとか、いつもすぐ使えるところにあるとか・・・）

正しい数より、傾向や雰囲気がわかればいいのが管理者です。
ただでさえ少ない作業者の手間を割いて、報告を待つなんてことはあってはいけません。

それを意識して数と組織レベルにそってバインダーを作っていけば、
管理者が知りたい情報がおのずと整理されていくでしょうし、作業者は判断が単純明快になるのです。

こうして管理するだけでも数百クライアントは少人数でいけるので、それを達成してからでもIT化は遅くはないでしょう。
そのときには、管理もかなり洗練されているはずです。

それを根拠に管理ツールを作れば、製品化して売れるレベルだと思いますよ。

ITベンチャーと言っても私が知っている数社とそこで聞いた話ですが、
聞いていいなーと思った話は結構実践してきましたので、まあ、内容についてあーだこーだといえるぐらいは知っています。

実は運用面で意外とITではなく、ローテクを使って大量の情報を素早く判断しているのです。

ただし、ここで言っている大量の情報とは、言い換えると、「文字」や「数値」に表せきれないような情報と言ってもいいかもしれません。

ここでは、その一部をちょっと紹介したいと思います。

１：障害を「音」と「光」で知らせる。

具体的には、パトランプと、サイレンで知らせます。
これでの効果は、多くの人に直感的に通知できることと、雰囲気を経験的に提供できる点です。

誰でも仕事中に、サイレンが鳴れば「うるさいなー！」とわかります。
従って、たとえほかの仕事途中であっても周りの人の依頼を断って、障害に対応できます。
また、関連部署の巻き込みも根回しなしにできます。というか、勝手に集まってきます。

そして、最近「静かだなー」、とか、逆に「うるさいなー」が関係ない人にもわかるので、様々な情報が経験となって伝わるのです。
たとえば、「そろそろハードウェアも買い換え時期かな－」とか、「監視に予算をつぎ込んだ方がいいなー」とか、とか。

このような、職人だけが関知できる経験的勘所も、「音」と「光」にしてあげる事でなんとなく伝わる事が多々あります。

で、このようなノウハウ、実は結構使われている気がします。
USBで接続するこのようなツールも売られているので、一定の需要はあるのでしょう。

２：感情で品質を管理する。

現在のシステム管理では非常にスピードも速く、そして、要件もすぐに変わっていきます。
ただし、問題がいざ発生すると、「テストは十分なのか？」などの議論が巻き起こり、重厚な「テスト仕様書・報告書」ができあがることがあります。

でも、そもそも自分たちで感知できなかった問題なので、他にこの「テスト仕様書・報告書」を承認する人が必要になります。
しかし、これを承認できるような技術者なんてほとんどいません。
従って、ここでできたルールは、ほとんど形骸化し、そしてまた、何もない状態に戻っていきます。
そして、あり得ない障害が多々ある状態に戻ってしまうのです。

そこで感情の登場です。
ここで「テストレポート書」を作りますが、詳細な仕様書や結果は一切求めません。
ただし「私は正しく動くことに自信があります。」と言う項目を設け、その欄にサインしてもらうのです。
（決して、保証を求めてはいけません。求めるのは根拠が無かろうが、「自信」だけです。保証を求めたら決して同意しません。）

そもそも、要求もめちゃくちゃ、動きだって詳細は決まっていないのだから、詳細を求める方が間違っています。
でも、エンジニアというのは基本的に正直者ですから、結構うまくいきます。
そして、自信があるといった以上、責任も持ってくれるのです。

これで、おおかた双方が求める物は満たせているはずです。

自信がないと言ってきたら、上位技術者をつけるなり、結果を用意することでOKとすればいいのです。
これで、ほとんどわかりきった事に対する情報については、細かい情報を求めず、込み入って問題になりそうな事だけが、文書化されていきます。

しかも、組織レベルが上がれば、上がるほど、文書化は必要がなくなってくるのです。

と、２つを紹介しました。
たまーに、これ以外も紹介していければと思います。