「Flashが今後なくなることはないけれども、モバイル機器用のは開発しない」というアドビの発表。

さて、それに代わるのがHTML5だというのですが、これは話を少々単純にしすぎです。
「一部ではそう」ですが、ほんの一部です。もっというとHTML5で新しくできることって厳密に言うとそんなにないのではないかと思います。

ビデオが見れる。絵が描ける。などの実現はFlashではなくてもQuickTimeやJavaアプレットなどでできました。HTML5の厳密な見方はこのような「プラグインに任せていた部分をブラウザがやりますということになった」ということだと思います。
実際HTML5として紹介されている多くの部分をAjaxが担っています。
Ajaxが登場したときも同じでした。Ajaxは通信する方法の名前でしかなく、開発はほぼjavascriptです。

カートにドラッグできるショッピングサイトなんかをFlashで作るようなことは
ずいぶん前からなくなっていて、Ajaxで作ります。
その時点でFlashの役割のかなりの部分はAjaxに取って代わっていました。

CSS3もそうですね。

このように、Flashは急に役割を取られたのではなく、徐々にそうなっていったのです。

それなのに突然な印象を与えたのは、Apple社のモバイル製品がフラッシュを非対応にしたときです。
正直「えぇ?」と思いました。それは二つの理由からです。
ひとつはまだまだFlashで作られたサイトやサービスがたくさんある状況でお客さんがどのように反応するだろうという不安。
二つ目はFlashが（Flasherという職が）なくなってしまうのではないかという危惧。

一つ目の理由については、本当に驚きました。一流の先導者の凄み、出てました。
二つ目の理由についてはそれほど意外なことではなかったです。

さて、HTML5の時代にこれから入ります。
今後Flasherは普通にやっていたら食べれないと思います。

進路のパターンとしては、
１：他の技術も習得してポリバレントな技術者になる。
２：さらに進化していくだろうFlashの最先端をひたすら追い続け、職人として生きる。

どちらかというと私は１のパターンです。デザインやアニメーションが強い人は２のパターンになるのかな。

媒体で言うと、１のほうが圧倒的に舞台が多い。

そういうわけで就職も1の人材のほうが就職しやすいでしょうね。
２は会社を選びます。故に狭き門。職人の淘汰がされるでしょうね。

HTMLコーダーと呼ばれている職業の人がHTML５という名前だけを理由に、それをやらされているとも聞きます。
FlashでActionScript書いてた人のほうが簡単に習得できる技術だと思うので、
HTML5の表面の部分（マークアップとCSS）と動作部分（Javascript）で職種名を分けて、
Javascript側をやる人として再就職とかお勧めです。Javascripterとか、Ajaxianとか。

現在の教育の現場でもいまだにHTMLとかFlashとか分けて教えられていますが、
それらの境目を作るのは早くやめてほしいと思います。
まずウェブサービスが動いている全体を感じられる指導をしてほしい。

１：ネットワークを組む。（プラモデル方式に）
２：サーバーを立ち上げる。（ざっと）
３：データベースを作成（いわれたとおりに）
４：サーバー側の簡単なプログラム（一応内容を把握）
５：クライアント側の簡単なプログラム（アレンジしてみる）
６：それらを動かす。

これを一度体験しておくことで、その後どんな専門を持ったとしても、
技術革新が早いこの業界においても自分を変えながら生きていける絶滅しない人材になれると思います。

DeAGOSTINIさんあたりで出ないかな。ニッチすぎるか。。

その場合、分けてしまうことでデバッグがしにくかったり、深度管理が大変だったりというデメリットが生じてしまいます。

その解決方はいくつかあるとおもいます。たとえば、
・getDefinitionByName
や
・getDefinition
を使う方法です。

以前にも同じような問題にその時々で解決してきたのですが、ちょっとしっくりした方法が見つかったのでメモします。

※途中割愛、はい、親ムービーで子ムービーを読み込みました。親ムービーにはchildMovieというMovieClip型のインスタンス(子ムービー)があります。

package
{
import view.Sample;//子ムービーのライブラリにあるシンボル
import flash.system.ApplicationDomain;
public class Main extends MovieClip
{
/*割愛*/
function attachSample(childMovie:MovieClip):void{
var domain:ApplicationDomain = childMovie.loaderInfo.applicationDomain;
var Sample:Class = domain.getDefinition(“Sample”) as Class;
var sample = new Sample();
addChild(sample);
}

}
}

ポイントは３つ。
・子ムービーのシンボルは１フレのどっかに張っておくか、1フレーム目に書き出しチェックボックスにチェックを入れておく。
・親ムービーにimport文を入れていつでも使える準備をしておく。
・domain.getDefinition(“view.Sample”) じゃなくてdomain.getDefinition(“Sample”)

こうすることで、デバッグ時に親ムービーに子ムービーにあるクラスが存在するかのように開発を進めることができます。

参考ＵＲＬ(http://www.adobe.com/jp/newsletters/edge/october2009/articles/article2/)

というわけで、Flexをがりがりと勉強し始めると現在進行中のシステム案件も実はFlexの方が開発しやすいのではないかという結論に至ったわけです。

Flexを勉強していて一番ストレスに感じるのは、”絵がかけない”とか”動きのニュアンスちょっと違う”とかそういうところ。
美的感覚が悲鳴をあげます。でもシステムは外に見せるものではないし、そこまでビジュアル的にひどくもないし。生粋のデザイナーにはきついだろうけど、私は平気。許容範囲。
それに、慣れてくれば自由にグラフィックを調整できると思います。

そのシステム案件のスケジュールも伸びたことだし、ここはひとつFlexに舵をきってみようかと思います。

Flex勉強会もFlash勉強会もたまーに出席するけれど、出席する人がちがうんですよね。
親和性はあるはずだから、連携できればもっとすばらしい結果が出せるとおもうので残念だとは思ってました。
どちらも使える人がいれば状況は変わってくるはずなので橋渡しになれればーと思います。

まず断っておきますが、これは汎用的に使えるクラスではなくノウハウのようなものです。でも一部は汎用的に使えるコードですのでカスタマイズして使ってみると何かと重宝します。

ステータスを一括で管理するというケースではイベント処理とデータの保持の両方が必要になります。

例えば「本」のようなアプリケーションの場合、「いま何ページを表示している」といったデータはそのアプリケーションの中では一つなはずですね。でもそのデータを知りたい、もしくは変更したいオブジェクトはアプリケーションのなかで点在するものです。これをうまく解決するのにはオブザーバーパターンを使えばいいわけですが、それ自体はEventDispatcherクラスを使えば簡単に実現できます。

一方アプリケーションが中くらいの規模になってくると（例えばフルスクリーンのちょっとリッチなサイト）イベントごとにクラスを作っているとクラスだらけになってしまいます。またステータスが変わったらそれをみんなに知らせたいというケースが大半なはずですね。（ちなみにここでいうステータスとはステータスパターンとはなんの関係もありません。）

つまりオブザーバーパターンの実装とステータスの保持はセットだと話が早いというわけです。また、ステータスの種類はいくらでも増やせたほうがいいですね。

サンプルです。

使うほうは
まずMovieStatusをinit()します。（これはアプリケーション内で一回でよし。ドキュメントクラスのコンストラクタでやるとベター）
つぎにファンクション定義。function onPageChanged(e:MovieStatus){trace(e.status.current);}
最後にイベント登録。MovieStatus.addEventListener(MovieStatus.PAGE,onPageChanged);

あとはMovieStatus.page = 1;とかすると先ほどのonPageChangedが呼ばれます。

今回はpageというステータスを用意しましたが、サンプルの「カスタマイズ」の部分を増やしたり改造したりすることで、アプリケーションごとに設定することができます。

本当は最初にinitするという仕様が腑に落ちないのですが、staticなクラスにしたかったことと、一つのクラスにまとめたかったことと、singletonなんかつかっていちいちインスタンス化するのが面倒だったことがあってこうなりました。ベターな方法があれば教えてください。