5 posts tagged “actionscript”

AS3.0-to-OSP

昨年11月6日に、Adobe Systemsが、オープンソースソフトウェアプロジェクトを支援するMozilla Foundationに、ActionScript3.0の実行環境「AVM（ActionScript Virtual Machine）」を寄贈したことで、ActionScript3.0の実行環境は既にオープンソース化されていたわけですが。。。

Adobe Lab ActionScript 3:resources:apis:libraries

で公開されていたActionScript3.0用のライブラリがオープンソースプロジェクトとしてGoogle codeへ移管されたと、Adobe Senior Product Manager for Developer Relations（元Macromedia Senior Product Manager）のMike Chambers氏のblogで公表されています。

【Open Source ActionScript 3 Libraries moved to Google Code】
http://weblogs.macromedia.com/mesh/archives/2007/01/open_source_act_2.html

移管されたのはこれら

・corelib - 統合ユーティリティ・クラスやAPI
・FlexUnit - FlexとActionScript 3のユニットテストフレームワーク
・Flickr- 写真共有サイトFlickr用 API
・RSS and Atom Libraries - RSS とAtomをパース（構文解釈）するAPI
・Odeo - Odeo Podcast API
・YouTube - YouTube Video API
・Mappr - Mappr API

これでAS3.0の実行環境のAVM、そしてAS3.0の標準ライブラリやAPIの双方がオープンソース化されたことで、国内外の優秀なプログラマによってどんどん派生クラスやAPIなどの公開、様々なデバイスへの実装が行われていけばいいですね。

一応、Mikeさん曰く。

Note, the original Labs page still exists, although it now points to the individual projects on Google code. The old subversion repository on labs still exists, but is no longer being updated for these projects. We are keeping it around to provide revision history for the projects.

ただし現時点を持ってGoogle codeで個々のプロジェクトが移管しましたが、これまでの改変履歴を確認するためのSuversionリポジトリを参照できるように、既存のAdobe LabのAdobe Lab ActionScript 3:resources:apis:librariesページは残します。
ただし、Adobe Labの方のリポジトリは今後一切アップデートされません。
我々はこれらプロジェクトの改変履歴を提供できるようにこちらのページを保守します。

とのこと。

もし興味がおアリの方は

All of the projects contain complete access to source code, documentation, unit tests, wiki, bug base, and mailing list. If you are interested in contributing to any of the projects (code, testing,
documentation), sign up to the appropriate project mailing list, and offer to help.

プロジェクトの全ては、ソースコード、ドキュメンテーション、単位テスト、wiki、バグベースとメーリングリストへの完全なアクセスを含みます。あなたがプロジェクト（コード、テスト、ドキュメンテーション）のいずれかに貢献することに興味があるならば、適当なプロジェクトメーリングリストに登録して、「お手伝いしましょうか？」と申し出てください。

とありますのでいかがですか？＾＾

個人的には中期的視野の中で確実にくるであろう「一発逆転を狙ってAS3.0を頑張る！」というより、短期的な視野の中で「AS2.0の完全理解」を進め「国内外問わずある有益なライブラリを使えるようにして制作の効率化」を行うことが、目下のマイルストーンですかね。

にしてもコンテンツとしての「Flash」の生き残りを賭けて

再生環境：FlashPlayer→Apollo
制作環境：Flash→Flex
制作者の囲い込み：デザイナー→開発者

のために諸々のオープンソース化を行っているようにも見え、現状ライバルはやはり月末に日本でも発売される「Microsoft Windows Vista」であり、Vistaの中の「WPF（Windows Presentation Foundation）」であり、VistaのコアAPI、WPFにネイティブ対応したコンテンツを制作できる「Microsoft Expression Interactive Designer」あたりだったりするんだろうと思うとともに、「Flash制作者」として「クロスプラットホーム／マルチデバイスでのRIA制作」というスタンスであれば、これからもFlashだろうなぁ。。。と思うけど。。。これはある意味「理想論」で、やはり「Windows」のシェアはとんでもないもので。。。「Windowsで動くコンテンツを！」という要望がクライアントから増えれば、あながち「WPFやExpression」も決して無視はできないんだろうなぁ。。。と少々憂鬱になったりします。

【動作を分解して考える。】

頭にあることを「紙」に出し、誰にでも（後々の自分にも＾＾；）わかるように「母国語で書く」必要性について書いてきました。

今回は「動作を分解して考える。」です。

前回晒した「画面遷移書」のように、作ろうとするものの動作や機能については一通り「紙」に「母国語」で書き出すことができたわけです。

しかしこの資料は「制作者以外の方でも読める」ということを念頭に置いていますので、「当たり前のことを当たり前」に書いています。
例えば、「ドラッグ&ドロップ」や「拡大／縮小」「ポップアップメニュー」などなど。。。

「専門用語は使わない」と前回に書きましたが「わかるだろう。＾＾；」と思われる専門用語はそれなりに使っています。そうしないと読み手に苦痛を与える冗長な文章になってしまい

「読みにくい」→「読まない」→「認識を共有できない」

という大変なことになるので、そこはバランスをとりながら書いています。

しかし、少しでもプログラムに挑戦したことがある方なら察しが付くと思いますが、

「実際の動作は細かい動作の積み上げの上に成り立っている」

ということに。。。

つまり、文章では一言で表現した「ドラッグ」や「ポップアップメニュー」「拡大／縮小」などというものは、細かな動作の集合の上に成り立っている動作であるということです。

そのため、本当に必要なベースとなる動作（＝処理）を見極める必要がでてきます。

たとえば、一言で済むように

「珈琲を淹れてください。」

といったお願いだって。。。言われた人は「珈琲を淹れる」という認識でも。。。

「湯をわかす」
「カップ&ソーサーを用意する」
「インスタント珈琲の粉をカップへ入れる。」
「やかんの水は沸騰したかどうか？」
「沸騰したらカップにお湯を注ぐ」
「角砂糖の器とフレッシュとカップ&ソーサーをトレイに」
「依頼者へサーブ」

といった細かくわかれた処理を一つずつ積み上げながら「珈琲を淹れる」という動作を実現していますよね。＾＾

これが「動作を分解する」ということ。

もちろん書面や口頭で「珈琲淹れて＾＾」って一言で済むことを、ここまで「動作を分解」して伝える必要はないと思います。お互い人間同士なら。

それは前述したように「珈琲を淹れる」という大きな動作が「湯を沸かす」「入れ物を用意する」「珈琲豆を用意する」といった大きな動作を実現するための小さな動作を持っていて、その小さな動作を再構築することで大きな動作である「珈琲を淹れる」が実現できることを知っているから。

但し。。。「珈琲を淹れる」ために何の準備が必要で、どういう作業が必要で、そもそも珈琲が何かわからない人にお願いする場合はどうしますか？

そうですよね。
「珈琲を淹れる」という動作を事細かく説明しますよね。
説明するために「珈琲を淹れる」という動作を細かい動作に分割する筈です。

そうした行為がプログラミングには必要になります。

そうしたことが、#01で引用させてもらった

「プログラムとは、コンピュータへの命令ではなく、
コンピュータに何をしてほしいか、人に説明することだ」

Donald E. Knuth, “Literate Programming”
（ドナルド E. クヌース 『文芸的プログラミング』）

ということだと自身では理解しています。

だって、コンピュータはあなたが依頼したい事柄の何一つも知らないんですから。
あなたが親切丁寧に細かい動作に分割して一つ一つ教えてあげる必要があるんです。
「コンピュータに何をしてほしいか、人に説明すること」のように。

そのために「動作を分解して考える」んです。

【まずは母国語で考える】

さて。。。大分「間」が空いてしまいましたが３回目です。

タイトルにある「プログラム／コーディングのその前に。。。」どんなことを考え、どんなことをしているか？ということを、まぁ何かの参考、何か「足がかり」にくらいはなるだろうと思い晒しているものです。＾＾；

• 前々回は「書こうと思った理由など諸々←継続予定^^;」
• 　前回は「まずは紙にでも書くということ。」

ということで、一旦、自分の頭の中にあることを勘違いを防ぐために、忘れ物をしない（減らす＾＾；）ために、「外部装置」である「紙」に出してしまえ！という話をしました。

今回は「まずは母国語で考える」というタイトルです。

なんだか当たり前っちゃぁ当たり前の話なんですが。。。
要は「専門用語」を多用しないということです。

自分で仕様切って、設計して、プログラミング／コーディングまでやっていると。。。
「仕様書」や「画面遷移書」を書いている時点で

    「○○_mcをon(press)で.startDrag(枠_mcの範囲内)」
    「○○_mc.onLoad = function(){初期化};」

とか、普通に書いています。^^;
もちろん間違いではありません。
一応日本語で書くと、

    「○○_mcを押下しながら枠_mcの範囲内をドラッグする」
    「○○_mcがステージに読み込まれた時に値の初期化をする。」

というような感じでしょうか？

実際にとある案件で使った「画面遷移書」を晒すと。。。
こんな感じです。

実際の動き、つまり、

    どのボタンを押したら、何がどう表示されて、どう動くか？

といったことをまさに「母国語」で順を追って書いていきます。

どうですか？「めんどくさー！！」と思われますか？
僕は正直思います。＾＾；

じゃぁなんでこんな面倒臭いことをするのかというと。。。
そうです！

　「思い込みや勘違いを無くすため」

です。

そして、わざわざ面倒臭いことでも「意味／メリット」があるのであれば行う値打ちはありますよね。＾＾；

僕は何故こんなことを行うかというと。。。

　・お客様への資料となる。（やってますよ！感アピール）
　・内部の資料となる。（異なる職能の方々との意識合わせのため）
　・自分の資料となる。（いろいろ作業やったり、飛び込みが来て戻っても忘れない。）

というメリットを知っているから。
そして何より

「望まれているモノの整理と限られた予算の中でできうることを最大限投入するため」

だったりします。

何が言いたいかと言うと。。。

制作サイドの勝手な判断と思い込みで作りこみ過ぎない。そのパワーをお客さんが必要としているモノに注ぐということ。

よく制作の現場であると思うのですが。。。
実装まで行って。。。クライアントから「そんな機能いる？」とか、
実装も終盤に近づき「動くもの」が見えてからの「その機能あるんだったらこんな機能も入れてよ。」という追加仕様。。。

まぁ良くあることですが、結局これでは誰も幸せにはならないですよね。。。

なので。。。一番最初に「書き出す」ことを行い、
誰でも読めるように「母国語で書く」んです。重複しますが、

「望まれているモノの整理と限られた予算の中でできうることを最大限投入するため」

各々、職能やスキルには個人差があります。
ましてお客様は（特に最終決裁者に限って）IT系の知識が無い方だっています。
逆にお客様は自身の業務体系や、「何故作るのか？」という目的や目標を知っています。
お客様が遠い場合、制作者はこの当たり前の制作依頼者のニーズがぼやけていたりします。

だからこそ、きちんと見慣れた「紙」に出し、「母国語」で機能や動きをまとめた資料を渡すようにしています。

そこで、お互いの想いをすり合わせ、認識を共有することを行い、本当に必要な費用・機能・方法・期間などを出すようにしています。＾＾

僕自身は、このような資料を作成するときは、大抵「母親に画面を見ながら電話で説明している」シチュエーションを思い浮かべながら書いていたりします。＾＾；

そして、制作サイドとしては、急な仕様変更等を極力防ぎ、どうしようも無い仕様変更ならこうした「紙」と「共有した認識」を元に「追加費用」の請求、せめて「製作期間の追加」だけでも行えるように心がけて「面倒臭い」ことかもしれませんが、僕は「紙」に「母国語」で出すようにしています。＾＾

ActionScript1.0で書いていると。。。なんか本来の「オブジェクト指向」での

    「自分のことは自分でする。自分のモノは自分で持つ」

つまり、オブジェクト自身のメソッドやプロパティは自分でそのオブジェクト自身で管理しなさい。
ということなんだけど。。。

この基本から僕の書くソースは外れていることにいまごろ気付く。。。orz。

    getter/setterメソッドはそのプロパティを持っているオブジェクト（クラス）自身に用意する。

そうだよな。
当たり前だよな。。。

自身のプログラムが破綻する理由はこれな気がする。いやこれだけじゃないんだけど。。。

一先ず一個気付いたの一個直す方向で。

3.0は神や偉い人々に任せるとして。。。
いいかげん2.0で書けという話。

毎回忘れているのでメモφ(._.)

インスタンス自身のターゲットパスをスラッシュ・シンタックスでmyTargetへ

    myTarget = this._target;

インスタンス自身のターゲットパスをドット・シンタックスでmyTargetへ

    myTarget = eval(this._target);

うーん。忘れすぎ。
これで安心♪