mochikoAsTech

AppFuseで生成されたクラスたちの中でも、Modelにあたるクラスは、大体が「implements Serializable」している。
改めて「うーん」と考えた（いや考えてない、調べて理解するのに頭を使っただけ）、java.io.Serializableインタフェースってなんだ？

先ずはリファレンスを参照してみた。

クラスの直列化可能性は、java.io.Serializable インタフェースを実装したクラスによって有効になります。このインタフェースを実装していないクラスでは、その状態が直列化または直列化復元されることはありません。直列化可能クラスのサブタイプは、すべてそれ自体が直列化可能です。直列化インタフェースにはメソッドやフィールドはなく、直列化可能であることを識別するためだけに機能します。
Serializable (Java 2 Platform SE 5.0)より引用

「直列化可能」にしてくれるインタフェースらしい。
でも「直列化可能」って何だ！電池でもないのにクラスが直列になるの？

そういえば理科の時間にやった電池の直列、並列も苦手だったな。
長持ちする方を選べとか、豆電球が明るく光る方を選べとか・・・電池を大量に買えばいいから、この問題は解けなくても構わないや、と投げた気がする。
走馬灯のように駆け巡る電池の思い出はさておいて、母語とは思えないほど「直列化可能」という言葉の意味が分からないので、検索、ITアーキテクトで解説を発見。

インタフェースSerializableは、メソッドやフィールドを1つも持たない空のインタフェース（マーカ・インタフェース）です。このインタフェースは、それをimplementsするオブジェクトがシリアライズ可能であることを示すためだけに機能します。
Javaの“常識”、“非常識”　第3回 - ITアーキテクト [IT Architect]より引用

しまった、「直列化可能」が分からないから検索してたのに、もうひとつ「分からない新しい言葉」が出てきた。
シリアライズ可能？これって「直列化可能」と同じ意味？

分からないので訳してみた。

　* serializable
　　 【名】
　　　　《コ》直列化可能
“Serializable”の検索結果（1 件）：英辞郎 on the Web：スペースアルクより引用

全く同じだ。
「Serializable＝直列化可能」、ここまでは分かった。

Serializableインタフェースは、名前のとおり「Serializableインタフェースをimplementsしたクラス」が、直列化可能であることを示すためだけに機能する、ということのようです。

でも「Serializable」という言葉の意味も、「直列化可能」という言葉の意味もまだ分からない。
英英辞書か国語辞典かで迷いながら再度検索、よくお世話になるTECHSCOREが引っかかった。

任意のクラスのデータをファイルに保存したり、ファイルから復元したりする事が考えられます。独自に保存・復元のプログラムを記述する事も可能ですが、 Javaでは簡単にこの仕組みを実現できる機能が提供されています。（中略）あるクラスのオブジェクトが保存・復元できる事を、「直列化可能である」と言います。また保存・復元できるかどうかを「直列化可能性」と呼びます。
オブジェクトのシリアライズ入出力-TECHSCORE-より引用

「生成されたオブジェクトのデータを、ファイルやDBに対して保存・復元出来る」
そういうクラスのことを「Serializable（直列化可能）なクラス」と呼ぶらしい。

じゃあAppFuseで自動生成されたModelのクラスたちは、みんな「Serializable（直列化可能）なクラス」だったのか、確かにデータ出し入れしてたものね。
納得しかけたら稚内北星学園大学のJavaBeansに関する資料を見つけた。

Bean は、必要に応じてオブジェクトの状態を保存したり、復元したりすることができなければいけません。このことを、Beanを「永続化」する、といいます。このためには、Beanにjava.io.Serializableインタフェースを実装する必要があります。このインタフェースにはメソッドは定義されていないので、次のように定義するだけで構いません。
2003年度　ソフトウェア特論より引用

「直列化可能」、「Serializable」ときて今度は「永続化」ですか、そうですか、多分同じ意味だよね？
不安になったのでもう少し調べる。

もうひとつ、JavaBeansの仕様では、Java Beanクラスは「直列化可能」である必要がある。
Java Beanクラスは、プロパティに格納した情報を保存できる必要があるため、Serializableインターフェイスの実装クラスとする必要がある。（中略）これは絶対必要な条件ではない。実際、通常のサーブレットとJSPで使用する場合には直列化可能である必要はない。ただし、システムによっては必要不可欠であるため、Serializableインターフェイスの実装クラスとしておいた方が安全だろう。
JavaA2Z【JavaBeansとは】より引用

Modelのクラスたちは、プロパティに格納した情報をDBに渡したり、DBから受け取ったりするための部品（JavaBeans）なので、「Serializable（直列化可能）」でなければいけない、と。

でも、さっき「Serializable（直列化可能）なクラス」というのは、「生成されたオブジェクトのデータを、ファイルやDBに対して保存・復元出来るクラス」ということで一旦納得したんだけど、「ファイルやDBに対して保存・復元出来る」って具体的にどういうことなんだろう？

Java のオブジェクトを、後で復元できるような1次元のデータ列に変換することを「シリアライズ（Serialize）」、あるいは「シリアライゼーション（Serialization）」、「直列化」と呼びます。逆に、シリアライズしたデータ列をオブジェクトに変換（復元）することを、「デシリアライズ（Deserialize）」、「デシリアライゼーション（Deserialization）」と呼びます。
インスタンスの状態をファイルに保存したり、ネットワークを介してインスタンスの転送を行ったりする場合は、このシリアライズを利用します。そのとき対象となるオブジェクトには、インタフェースSerializableをimplementsすることとなります。
Javaの“常識”、“非常識”　第3回 - ITアーキテクト [IT Architect]より引用

「Serializable（直列化可能）なクラス」というのは、「オブジェクトのデータをファイルやDBに保存・復元できるようにしてあるクラス」のことで、実際には「オブジェクトを1次元のデータ列に変換（シリアライズ）出来たり、そこからオブジェクトを復元（デシリアライズ）出来るクラス」のことだったんだ。

そして、「Serializable（直列化可能）なクラス」には「serialVersionUID」を書かないといけないらしい、こんな感じで。

private static final long serialVersionUID = 3690197650326049858L;

なんで？なんだこのランダムな数字、どこから来たの？
もう一度リファレンスを参照してみた。

直列化ランタイムは、直列化可能クラスとバージョン番号 (serialVersionUID) を関連付けます。バージョン番号は、直列化復元時に、直列化オブジェクトの送信側と受信側が直列化互換性のあるこのオブジェクトのクラスをロードしたかどうかを検証するために使用されます。受信側が送信側のクラスと serialVersionUID の異なるオブジェクトのクラスをロードした場合、直列化復元の結果は InvalidClassException になります。直列化可能クラスは、独自の serialVersionUID を明示的に宣言できます。このためには、static かつ final の long 型フィールド「serialVersionUID」を宣言します。
Serializable (Java 2 Platform SE 5.0)より引用

同じクラス名なのにserialVersionUIDが違うと、復元（デシリアライズ）した時にInvalidClassExceptionを投げるようだ。
でも「同じクラス名でserialVersionUIDが異なる」というシチュエーションがあんまり思い浮かばない、他の人が同じクラス名で他のクラスを作ってたとか？じゃあ一人で開発してる限りは必要ない？書かなくても良いのか？と思ったら親切な名無しさんが答えてくれてた。

シリアライズしたクラスと、それを復元するクラスで serialVersionUID が違うと復元時に InvalidClassException食らう。
んで、serialVersionUID は設定しないとコンパイラがクラス定義から自動的にデフォルト値を計算するけど、これはコンパイラが違うだけで値が変わる可能性があるので推奨されないって事らしい。
http://mobile.seisyun.net/cgi/read.cgi/pc11/pc11_tech_1135634403/844より引用

なんと簡潔で分かりやすい。
同じ内容がリファレンスにも書いてあるんだけど、こっちの方が分かりやすい。

しかし、デフォルトの serialVersionUID の計算は、クラスの詳細情報に大きく左右され、このクラスの詳細情報はさらに、コンパイラの実装状況に依存しているので、直列化復元時に予期しない InvalidClassException が発生する可能性があります。
このような問題を防ぐためにも、すべての直列化可能クラスがserialVersionUID 値を明示的に宣言するように設定することを強くお勧めします。
Serializable (Java 2 Platform SE 5.0)より引用

なるほど、やっと分かった気がする。
Serializableについて語っていた皆さん、どうもありがとう、助かりました。

テーマ : Java
ジャンル : コンピュータ

先日書いた「[event][Flex][AIR]Adobe RIA Evolution Seminar in Tokyoに行ってきた」というエントリの文章が、株式会社フィードテイラーの大石さんの「RIA Evolution Seminar でのプレゼンに皆様からのコメント」（関西のRSSフィード屋 feedtailor Inc. 大石裕一 社長ブログ）というエントリで触れられていた。
こういったイベントリポートは、イベントの情報を必要とする人のことやエゴサーチで引っかかる可能性を考えて、出来るだけイベント名や社名を正しく書いていたのが役に立ったかな。

ブログや検索がなければ生成されなかったはずの繋がり、私の言葉も誰かに届いたり、それでちょっとでも嬉しいと思ってもらえたりするんだな、と思えてなんだか嬉しかった。（そして勿論その逆もあるだろう、けどそこを恐れて何も発言しないよりは、発言して叱られて反省して謝って、そうして少しずつ賢くなりたい）
大石さん、改めて素晴らしいプレゼンテーションをありがとうございました。

最近は、春を迎えて人と人が離れ、繋がりが切れてしまうことばかりを感じていたのだけれど、繋がるかどうかは「繋がりたいかどうか」であって、距離だけが問題ではないな、と思えた。
遠くに行ってしまった人たちともし縁が切れたなら、それは私がきっと「切れてもいいや」と思ったから切れたのだ。

私が特定の街で暮らし、特定の場所で働き続けている間、サーバの中の私はもっとずっと遠くへ歩いていって、勝手に色んな人に色んなことを語って、また帰ってくる。
なんだか楽しそうだね、また明日の夜、遠くから帰ってきた自分に、今日はどんな出会いがあったのか聞いてみようと思う。

テーマ : 日記・日誌
ジャンル : コンピュータ

2008年2月28日(木)に「Adobe RIA Evolution Seminar in Tokyo＠大崎ゲートシティ ゲートシティホール」に行ってきた。
先日行ったコリンムックのActionScript3.0セミナーと同じ会場。

何度かお見かけしたアドビシステムズ社の小島さん、太田さん、海外からいらしたエバンジェリストの方や、クラスメソッドの横田さんなどが、「こんな可能性がある」「うちの開発の手順はこんな感じだ」「こんなもの作ってみた」という話を入れ替わり立ち代わりしてくれて、「AIRの凄さが今ひとつぴんとこない」「Flexで開発するイメージが湧かない」「ブラウザの中でなんでも済ませちゃ駄目なの？」という気持ちにうまーく応えてくれたような内容だった。

最初の「Adobe RIA Technology Overview」は、過去を振り返って「コンテンツのリッチさ」「リーチできる幅の広さ」で比較した時に、どちらも低いのがメインフレーム、「リッチさ」だけが高いのがウェブアプリケーション、「リーチの幅」だけが広いのが以前のデスクトップ、そしてどちらも高いのがリッチインターネットアプリケーションで、ここをAIRが担っていくという話。
このセミナの中で繰り返し出てきたのは「どうやって開発していくか」という話だったけど、一貫していたのは「AIRを始めとしたRIA（リッチインターネットアプリケーション）の開発には、デザイナーとデベロッパーが融合されたチームが必要」ということ。
実際、Flashで作ったものをそのままコンポーネント化できるエクステンションを使って、デザイナーがコンポーネントを作る、全体が出来上がってきたらデベロッパーが必要な箇所にそのコンポーネントを置く、という流れで作業をしている、という会社の話もあった。

面白かったのはSiTE4Dが「CS3とFlex3によるワークフローご紹介」と題して丁寧に説明してくれた「RIA開発の流れ」。
インフォメーションアーキテクチャ（情報の設計者）、デザイナ（ユーザインタフェース、絵を描く人）、デバロッパ（インタラクション、動きを作る人）の3名構成で、同時進行で開発をしていくそうだ。
実際出力するものはインフォメーションアーキテクチャがODF、デザイナがPNG、デベロッパがActionScript。
そしてMXMLやCSS、SWFについては「ワークフローを一定化しすぎると返って破綻し、お客様のためにならない」という考えから、境界線は敢えて曖昧にしているらしい。
確かに案件ごとや投入された人ごとで異なる点が多いんだから、全てを一定化しない方がいいというのは納得出来る。

その3名が決まったら、
インフォメーションアーキテクチャが1. 構造設計、2. 機能設計、3. 製品ガイド作成を行い、
デザイナが1. デッザン、2. デザインカンプ、3. パーツ作成を行い、
エンジニアが1. 調査・研究開発、2. プロトタイプ、3. プロダクト作成を行う、という形で同時進行でプロジェクトが進む。

で、お客様にはそれぞれ1が終わったらPDF、2が終わったらSWF、3が終わったらAIRファイルをお渡しするらしい。

実際に開発している「アスクルデスクトップベータ」の資料やら本体やらを見せながらの説明だったので、かなり「おおお」と思った。
やっぱりサンプルよりも、本当の開発で使ったものや、本当に顧客に提出しているものを見せてもらえる機会って貴重だなー。
点々と職を変えない限り、他の会社の「開発資料」や「顧客向け資料」なんて見られないし・・・。

あと、もうひとつ「おおお」と思ったのは、「仕様書になってしまうと、お客さんにとってイメージがつきにくいので、製品ガイドという形で見開きの資料を作成している」という話。
確かに、直感的に分かりにくくて読まない使わない見ない在ることすら知らないような仕様書よりも、製品ガイド（しかも仕様はちゃんと書いてある）の方がずっといいよね。
言葉の問題かもしれないけど、そっちを目指すべきだったのかも知れない、と個人的に反省。

後は、「デザインは概念によって分類している」という言葉。
これはすごい、実際にどうやってるのか見なかったら、血の通ってない言葉としてスルーしていたかも知れないけど、見て、聞くと、すごい。
デザインは「概念」に基づいて分類しているそうだ。
この「概念」っていうのは、例えば「前進」「後退」「入力」などのことで・・・「ログイン」や「＝」は前進に分類されるから、どちらも同じ「前進」のデザインを踏襲する。
ページごととか、機能ごとにデザインを考えるのが私にとっての「普通」だったので、これはびっくりした。
でもユーザにとっては絶対この方が使いやすいよね、ページが違っても根底にある「概念」が一緒なら戸惑わない。

このSiTE4Dの話の他にも、ある会社ではお客さんとのやり取りは全てPDFで行っているが、他の会社ではエクセルやパワーポイントでイメージを見せて、そこに意見を書き込んでもらってやり取りしている、というような開発の方法が聞けて楽しかった。

あと、開発の過程ではなく、使ってみたい！すごい！と思ったのがアドビシステムズ社で実際に使っているという社内向けAIRアプリケーション。
全世界に5000人居る中から社員を検索して写真やプロフィールが見られる、ここまではまあ良く聞く話かもしれないけれど、そこからメッセンジャーみたいに相手の状態が見られるし、その人が誰と一緒に仕事をしているのかというレポートラインも見られる、さらに座席がどこのオフィスのどこにあるのまで確認できる。
絶対便利だ、欲しい、派手じゃないけどこういうのが欲しいです。

最後に「国内デベロッパーによる、最新Enterpirse RIA開発事例ご紹介」で5社がそれぞれ開発事例を紹介して終了。

場内のネットワークが上手く繋がらず、楽天が必死に甘栗のサイトを開こうとするとカーネルパニックを起こしてMacごと落ちるというハプニングもあり、私の中ではすっかり「楽天＝カーネルパニック」・・・ではなく、良いユーザインタフェースについて自社の考えを述べていたのが印象深かった。

「ダサくてもいい、エッジでクールでなくても、ユーザが望むものを提供すべき。
　目的にあわせた適切な情報提供は見た目に勝る」

実際楽天のお客様の層を考えれば、縦に死ぬほど長くても、地方の商店街みたいな色合いでも、結果的に甘栗が大量に売れているということで「ユーザが望むものを提供できている」という裏づけになっているのかも、どの層に対しても「これがUI的にすぐれているんです！」って押し付けるのはおかしいよね。
紹介していたのはフォトアップローダー、知らなかったけど「着画」（買ったものを着ている画像）という言葉があるようだ。
しっかし「楽天　フォト　アップ」「楽天　AIR　フォト」あたりで検索しても何も出ないのは、ログインユーザ向けにしか案内ページがないからでしょうか・・・。

もうひとつ、自社で使っているツールを紹介していたのが大日本印刷。
ものすごく「大日本印刷」という言葉が似合わない（失礼！）な方が、「社内におけるプロジェクトや経営の判断のために手作業で行っていた集計を、AIRに任せられる部分はAIRに任せて、『判断』だけに注力できるようにした」というツールを紹介していた。
（それにしても楽天といい大日本印刷といい、ちょっと自虐的な自社紹介が流行っているんだろうか？）

これはー！
このアプリケーションは社内でプロトタイプまでを作って、実際の実装はクラスメソッドに頼んだそうな。
すごいなー、鳥肌が立った。

最後に株式会社フィードテイラーの「常駐型AIRアプリケーション」。
タスクトレイに常駐して、必要な銘柄のIR情報PDFを取ってくるAIRアプリ、「IRCastPro」

すっごくニッチだけど、特定の人にとっては便利なんだろうな。
しかしそれ以上に感じたのは、この人がすごくプレゼンテーションが上手かったこと。
今日は幾つに分けて何を話すよ、繰り返すけど大事なポイントはここだよ、最後に話したことをざっくり振り返るよ、大事なのはここね、という感じでポイントをきちんと伝えられるように話が構成されている。
ぼんやり聞いてると気付かないかも知れないけど、ああやって話すの難しいんだよね、素晴らしい。

と、いう感じで予定より4,50分遅れて終了。
AIRやFlexのことを知っている人が増えて、裾野が広がってきたと同時に、既にこんなすごい物を作っている会社があるんだ、と愕然。
喜びに満ちた驚きを与えられる機会って、こうして外に出て行かないとなかなか無いよな。

お土産にAdobe:Innovation これまでの25年、これからの25年という本を貰った、わーい。
会社の過去、現在、未来、そして扱っている商品についてのみ書かれた本を貰って、「嬉しい」と思ってもらえるような会社が世の中に幾つあるだろう。

Adobe:Innovation これまでの25年、これからの25年 (2008/02/01) アスキー書籍編集部 商品詳細を見る

テーマ : Flash
ジャンル : コンピュータ