• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
20100416 devlove(flex) final
 

20100416 devlove(flex) final

on

  • 3,159 views

Apr/16/2010 DevLove RIA

Apr/16/2010 DevLove RIA
Presentation slide

Statistics

Views

Total Views
3,159
Views on SlideShare
3,134
Embed Views
25

Actions

Likes
3
Downloads
2
Comments
1

2 Embeds 25

http://www.slideshare.net 24
http://s.deeeki.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Flexでの開発プロセスをイメージするにはこれ!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    20100416 devlove(flex) final 20100416 devlove(flex) final Presentation Transcript

    • DevLOVE RIA 「キャズムを超えるのは俺たちだ。」 Flexの開発は意外と フレキシブルじゃない!?件(仮) 日時:2010/04/16 1
    • スピーカー紹介 所属:クラスメソッド株式会社 • 事業内容 –リッチインターネットアプリケーション開発 –システム開発に関するコンサルティング、トレーニング • 強み –60件以上の RIA 開発実績とノウハウ –ワンストップソリューション提案 –機能と UI を共に重視するアプリケーション –社内受託システムでの強固なチーム体制 2
    • スピーカー紹介 • 篠崎 大地(しのざき だいち) –Flex歴4年 –@IT, AdobeDevConnection等にFlex記事を執筆 –9割、 業務アプリ開発 – 実装 > 設計 3
    • スピーカー紹介 • 大橋 力丈(おおはし りきたけ) –システム開発12年 RIA 1年 –マネジメント担当 –BtoBが多い – 雑務 > 設計 > 実装 4
    • 今日お伝えしたいこと • Flex開発の実際 –ポイント –落とし穴 • 今からでも遅くない • Flex開発の楽しさ 5
    • アジェンダ • オーバービュー 20分 –RIAとは –なぜRIA –Flash、Flexってどんなもん? • Flex開発のポイント 25分 –設計 –開発TIPS紹介 –テスト全般 • まとめ 3分 • 質疑応答 6
    • RIAとは • 従来のアプリケーションでは実現できなかった操作 性や視認性の実現に加え、表現力やレスポンスの 向上を目指したアプリケーション。 • 同時にサーバ負担・ネットワーク負担の 削減を実現するアプリケーション。 • アプリケーション技術(Flexなど)の事を言うわけで はなく、それによって実現されたアプリケーション。 7
    • RIAとは • 例えば –使いやすい –理解しやすい –マウスの移動量が少ない –エラーが視認しやすい –レイアウトが統一されている –使っていて楽しい アプリケーションに期待する当たり前のこと 8
    • なぜRIA? 9
    • なぜRIA 10
    • 高級箸の世界 • 黒檀の箸 –日本では古来からの最高級品 • 漆塗りの箸 –最近はほとんど中国製 • チタン(削りだし)の箸 11
    • Flash、Flexってどんなもん? 12
    • Flash Playerとは? 99.0% 1996 非常に高い普及率 2010 http://www.adobe.com/products/player_census/flashplayer/ 13
    • Flexとは? Flash Player上で動くRIAを作成するための 「開発環境」と「フレームワーク」 37万行 出典: アドビシステムズ 轟啓介氏の「Flex開発を加速するFlashBuilder4の新機能紹介」 14
    • Flashとは? 元々アニメーションを作成するツール 15
    • Flexの歴史 Just Macromedia時代 Adobeへ Released! Flash Player 7 Flash Player 9 Flex Builderに ActionScript ActionScript プロファイラ搭載 2.0 3.0 Flex Flex 4.0 Flex 1.5 Flex 3.0 Flex 1.0 2.0 Air 1.0 2004 2005 2006 2007 2008 2009 2010 Flash Player 9 登場 Flex SDK オープンソース化 16
    • Flash Playerの歴史 Macromedia時代 Adobeへ 高速化 携帯端末対応 Flash MX 2004 Future ActionScript ActionScript Flash Flash Player Splash 1.0搭載 3.0搭載 Player 10.1(予定) 10.1(予定 Player FP3 3 5 7 9 ) 1996 199 1998 199 2000 200 2003 200 2006 200 2010 201 6 8 0 3 6 0 1997 199 1999 199 2002 200 2005 200 2008 200 7 9 2 5 8 Flash 4 6 8 Flash Player 6 Player ActionScript 2 2.0搭載 10 3D 3D変換 Adobe AIRとの連携 新フォーマットXFLのサポート 17
    • 開発環境  Flex Builder (現: Flash Builder)  EclipseベースのIDE  MXMLというマークアップ言語によって画面をデザイン  ActionScript 3.0というオブジェクト指向言語で開発 18
    • Flash Builder (MXML デザインビュー) 19
    • Flexのコンポーネント 20
    • 高いカスタマイズ性 右図、 印の付いているところが ・CSS ・Flashでの部品作成 でカスタマイズ可能 Flexのコンポーネントは全て ActionScriptで出来ている ので、 ブラックボックスではない。 (ネイティブアプリとの違い) ※Addison-Wesley "Creating Visual Experiences with Flex 3.0"より引用 21
    • FlexのUI カスタマイズが容易 Flex Style Explorer http://examples.adobe.com/flex3/consulting/styleexplorer/Flex3StyleExplorer.html Flex Filter Explorer http://merhl.com/flex2_samples/filterExplorer/ 22
    • FlexとFlashの違い  IDEの違い  Flash IDE  デザイナ向け  Flex Builder  開発者向け  (Eclipseベース)  Flexフレームワークの 有無  MXML 出典: RIAコンソーシアム 主要RIA技術構造比較概要 http://www.ria-jp.org/download/tech_comp200909_.pdf 23
    • Flexの特徴  生産性が高い MXMLの記  簡単な画面を、手早く簡単に作れる 述力  複雑な画面でも、それなりに作れる  ただし、細かい動きにまでこだわり始めると、大変にな る  コンポーネントのカスタマイズ、想像以上に難しいことが多い  カスタマイズ性が高い  糊代が広い …やろうと思えばどこまでも凝れる  Flashとの組み合わせ技。アニメーションやスキン等 24
    • ラーニングカーブ ※効果には個人差があります 25
    • Flexで嬉しいこと  クロスプラットフォーム  クロスOS/クロスブラウザ (例:IE6でも動く)  横展開できる  ブラウザアプリ ->デスクトップアプリ(AIR) ->(Flash Player 10.1リリース以降は)携帯アプリの目も  成熟してきている  4年間分の開発実績・ノウハウ蓄積がある  開発環境が整っている 26
    • 4年前と今の違い  4年間に各所で蓄積された経験値  ぐぐれば解決策が出てくる状況になってきた  ML (flexcodersなど)  ユーザーグループのフォーラム・ブログ  つまらない問題で悩まなくてすむのは大きい  足がかりになるコード例があるのは大きい  4年間での進歩  Flash Builder 4 (2010/3/22にリリース!)  ワークフロー改善。Flash Catalyst等 27
    • 4年前と今の違い part2  周辺  ユニットテスト - Flex Unit 4(後述)  ソースコード美化 - Flex Formatter  ソースコード検査 - Flex PMD  ソースコードを解析して潜在的なバグを見つけるツール  カバレッジ取得 - FlexCover  各種フレームワーク 28
    • 事例紹介 その1 トレーディングシステム 画面占有型, 子画面切替高速 複合コンポーネント 29
    • 事例紹介 その1 トレーディングシステム  リリース日  2006/10  採用の動機づけ  動作環境のサポートが容易  開発の規模  (2人)  メモ  デザイナーなし、 CSSだけでも  標準コンポーネント+CSS調整 かなりできる 30
    • 事例紹介 その2 チャート 31
    • 事例紹介 その2 チャート  リリース日 Flexの特徴:  2008/1 チャート系が豊富  開発の動機付け  見やすさ・使い勝手の改善  サポートコストとランニングコストの削減  開発の規模  (1人) 32
    • Flex開発の流れ 33
    • ■開発フロー • 「理想」は XP 型 –要件定義時から動くものでコミュニケーション –小さいイテレーションを繰り返す • デザインやインタラクション関連設計は 上流段階から検討 –画面レイアウト設計 –画面インタラクション設計 –画面コンポーネント設計 –画面遷移 デザインが重要 34
    • ■外部設計の進め方 開発目的、利用者の特性、利用 レビューで決定したワイアーフ 環境、機能的要求、コンセプトな レームを元に、コンセプトに沿っ ど材料となる情報を確認する たビジュアルデザインを制作 ヒアリング ワイヤー ビジュアル プロトタイ フレーム デザイン ピング ビジュアルデザインが確定した ヒアリングを元に、ユーザーイン ら、実際に動くモデルを作成し、 ターフェイスの骨組みを設計レ 操作感を確認しながら手直しす ビューを行う る 35
    • ■ヒアリング • アプリケーションの利用目的 • 想定ユーザー • 想定利用環境 • 業務プロセス • 既知の課題や問題点 • ビジュアルテイスト/コンセプト “誰”が“何”を目的として使うかを確認 36
    • ■ワイヤーフレーム ヒアリングした内容を元に、UIの骨子となるワイアーフレームを 制作。ここではアプリケーションの使い勝手だけにフォーカスをし、 利用者視点での適切な情報設計を行う必要があるため、あえて 凝った装飾は施さずに制作する。 37
    • ■ビジュアルデザイン ワイアーフレームが固まったら、次はコンセプトにマッチ するビジュアルデザインの制作を行う。ビジュアルデザイ ンを施すことによって、アプリケーションをより視覚的に 理解してもらう 38
    • ■プロトタイピング ワイアーフレームとビジュアルデザインが固まったら、実 際に動くモデル(プロトタイプ)を制作。プロトタイピン グは幾つかのフェーズに分け、実際のユーザーにテストし てもらいながら問題点などを探り、ブラッシュアップを繰 り返す。 ユーザーによる テスト 修正適用 課題抽出 設計見直し 39
    • Flex開発のデザイン • インフォメーションデザイン –画面遷移 –画面構成 • グラフィカルデザイン –テーマ –視覚的な分かりやすさ • インタラクションデザイン –操作性 –誰が使うか “誰”が“何”を目的として使うかを確認 40
    • 開発要素と開発ツール インフォメーション グラフィカル インタラクション ツール Photoshop Photoshop FlexBuilder Illustrator Illustrator (Excel) (FlexBuilder) 担当 デザイナ デザイナ エンジニア エンジニア (エンジニア) (デザイナ) 成果物 .ai、.psd .ai、.psd .mxml (.xls) (.mxml) .as デザイナとエンジニアの協業! 41
    • ■設計について • 設計手法 –初期段階ではモックを作成し確認 –インタラクションは動くモノが無いと理解しにくい • 設計書 –画面項目書などはWord、Excelなどの設計書で問題ない –インタラクションなどは膨大な量になるので作成しない モック&設計書で確認すること 42
    • 開発Tips 43
    • ソース管理 • Eclipseで使えるもの、なんでもOK –CVS, SVN, Git etc • バグ管理 – Trac, RedMine etc 44
    • プロジェクト構成 SWC/RSL ・中~大規模 分割必頇 ビルド時間がばかにならない • SWC –スタティックリンクライブラリ • RSL (Runtime Shared Library) –DLLみたいなもの –実行時にないとエラーになる • モジュール –実行時になくてもエラーにならない –データやスタイルの動的な追加に使う 45
    • ビューとロジックは分離しよう  MXMLファイルにスクリプトを書かない  MVCを守る  ViewとViewHelper  コードビハインドパターンも有効  実現できるのはビューとロジックの分離ではなく、ビュー とロジックの実装ファイルの分割程度だが、有効 46
    • フレームワークはどうするの?  これを使えば盤石、というものはない  Flex Frameworkで既にかなりの事がカバーされる  各プロジェクトごとに案件に即した薄いフレーム ワークを構築するのがお勧め  エラー処理  サーバとのデータのやり取り  ダイアログ系  ユーティリティ類 47
    • カスタムコンポーネント作成が難関  一気に難しくなる  Flex Frameworkの内部構造に踏み込まないといけな いため 48
    • 地雷、その傾向と対策  APIの森に迷い込む  本質的な複雑さ  イベント絡み(実行時でしかバグを追えない)  メモ  カスタムコンポーネント開発で起きやすい。。  どこかで切らないとトライアンドエラーの消耗戦 49
    • 地雷、その傾向と対策 part2  非同期処理で「つまづく」  プロジェクトが肥大化し、ビルドがものすごく重くなる  ライブラリ分割を最初から考慮する  顧客の要求がふくらみすぎる ・「良いもの」が出来つつある ー> 「もっとよくしましょう…」  いつの間にか「仕様の後付け」が発生 後から容易に付け足せれば良いが、そうでない仕様もある (例:「やっぱり」主要な操作に キーボードショートカットを割り当てたいんだけど) 50
    • 地雷を避けるために  リスクを洗い出すための工程を取る  実現可否調査が重要  小さくても良いのでサンプルをしっかり作る 51
    • Adobeのバグデータベースを確認  http://bugs.adobe.com  バグの修正予定の有無・時期がわかる  対処策(Workaround)が投稿されている場合も チェック必頇! 52
    • 地雷を避けるために  無理な機能を実装しない  簡単そうに見えても油断できない  見た目では判断できない 53
    • 工数はどれぐらい? Flexの標準カレンダー カスタムカレンダー 54
    • 工数はどれぐらい? • 4人日 (当社比) • 標準のカレンダーコンポーネントでは、このレベルのカスタマイズは考 慮されていない • 背景グリッド描画、星アイコン、土日の色付けなどが結構な力技に Flexの標準カレンダー カスタムカレンダー 55
    • 工数はどれぐらい? • ある順番以降の項目を選択できないComboBox 56
    • 工数はどれぐらい? • ある順番以降の項目を選択できないComboBox 1人日弱(当社比) ・一つのコンポーネントに見えても、複数のコン ポーネントの複合体 ・それぞれに、すこしずつカスタマイズを追加 ・直感的ではないAPIを使う必要がある。 内部詳細を理解しないとわからない。 理解するには、時間が必要 57
    • 地雷を避けるために  仕様詰めに実装者が積極的に関わることが重要  顧客もUIに関して良くわかっていない事が多い  もっと使いやすくて工数が掛らない実現方法があるのなら、 提案すればまず受け入れられるはず  実現したい事、その重要性と、それを実現するための 難易度・リスクのバランス  膨らむ夢への対処 *少し*しぼませる事も現実問題と して重要  RIAはネイティブアプリとは違う、の前提を崩さない(理 解して頂く) 58
    • Flex でのテスト 59
    • テスト • 単体テスト –動的テスト –静的テスト • 結合テスト • ○○テスト • □□テスト 単体テスト=コーディングフェーズでの 品質を向上 後続フェーズでのトラブル軽減=コスト削減 60
    • Flex でのテスト:動的テスト • クライアントテスト –人手によるテスト –[New]FlexUnit 4による自動クラス単体テスト –[New]FlexMonkeyによる自動UI動作テスト • サーバーテスト –テストドライバによるサービス呼び出しテスト AMF、REST AIRベースのドライバアプリケーション自作がお勧め –(サービスの単体テスト) –DAO層の単体テスト 61
    • Flex でのテスト:静的テスト • クライアント静的テスト –[New]FlexPMDによる静的テスト –[Beta]FlexMetricsによるメトリクステスト 現在GUI、及び標準的な結果解析ツール未提供 • サーバー静的テスト(Javaの場合) –Checkstyle –FindBugs または PMD –Eclipse Metrics Plugin または EclipseMetrics 他言語は上記に相当する同様のツールを活用 62
    • Flex でのテスト:テスト管理 • テストケース管理 –Excel –Trac • テスト実行 –人手 –Maven、HudsonなどのCIツール CI:Continuous Integration • 結果の精査 –Excel –Trac バーンダウンチャート 63
    • Flex でのテスト:静的テスト 静的テストの成績が悪い= 動的テスト合格でも結合テストや メンテナンスフェーズで大きな問題に 発展する可能性が高い 64
    • Flex での自動単体テスト適用シーン • ライブラリ全般:FlexUnit 4 –ヴィジュアル要素の無いもの • ロジッククラス:FlexUnit 4 –ある程度設計が必要 • 画面の動作テスト:FlexMonkey –特に大規模プロジェクト • サーバーアプリケーションに対する 「ドライバー」:FlexUnit 4 65
    • FlexUnit 4 • Flex、AS3向け単体テストフレームワーク • JUnit の機能を移植したもの • グラフィカルテストランナー • FlexUnitのバージョン –FlexUnit 4、FlexUnit 0.9 • Flash Builder 4からは最初からツールに 統合されている 今後のFlash、Flex開発で 大きく威力を発揮するツールの一つ 66
    • FlexUnit 4 67
    • FlexUnit 4 FlexUnit 結果 ビュー 68
    • テストケースの作成 • TestCaseクラスなどの継承丌要 • JUnit関連のノウハウはすべて流用可能 /** * テストケース02:1+2 */ [Test] public function testAdd02():void { // テストケースと期待値の準備 a = 1; b = 2; expected = 3; // テストシナリオの実行 public function doTestScenario():void { doTestScenario(); actual = target.add(a, b); } // アサーション assertEquals(expected, actual); } 69
    • テストスイートの作成 • 定型のテストスイートクラスを作成 package jp.bizria.flex4.flexunit4.hello { import jp.bizria.flex4.flexunit4.hello.HelloUtilTest; /** * HelloUtilのテストスイートです。 */ [Suite] [RunWith("org.flexunit.runners.Suite")] public class HelloUtilTestSuite { //-------------------------------------- // Test Cases //-------------------------------------- public var test1:HelloUtilTest; } } 70
    • FlexMonkey • 「Flex Automation API」を用いたオープンソースのイ ンタラクティブテストツール。 • GUIのテストができる • AIRアプリケーション Seleniumみたいなもん 71
    • FlexMonkey Flash Builder 4の機能ではありません 外部AIRアプリにより実現 72
    • 品質管理 • コーディング規約 • コーディング規約を守らせる手段 –Flash Builder 4の設定 –FlexFormatter –FlexPMD • コードレビュー FlexFormatter http://flexformatter.sf.net/ 73
    • FlexPMD • バグチェック、品質チェックツール • JavaではPMDとFindBugsの二つが有名 • 以下をチェック: –潜在的なバグ –非推奨なコーディング –パフォーマンスに影響のあるコード –低メンテナンス性のコード Flash Builder 4の機能ではありません プラグインにより実現 74
    • FlexPMD Eclipse plugin • 手順 1. アップデートサイトでプラグインをインストール  http://opensource.adobe.com/svn/opensource/flexp md/plugin/trunk/flex-pmd-eclipse-plugin-site 2. FlexPMD本体のダウンロード 3. FlexPMDの設定  PMDとCPDのcommand-line-1.0.jarを登録  パスに半角スペースが入っていると動かない  ワークスペースのに半角スペースが入っていると動かない 75
    • FlexPMD Eclipse plugin 設定画面 ダウンロードしたPMD本体の コマンドラインツールのJARを参照 ルールセットファイルは 空だとデフォルトルール 76
    • FlexPMD ルール設定サイト http://opensource.adobe.com/svn/opensource/flexpmd/bin/flex-pmd- ruleset-creator.html ここのデフォルト設定を 保存しておいた方が良い 77
    • FlexPMD の実行 ・プロジェクト全体実行 ・個別のファイルでの実行 78
    • まとめ • 最初にデザインのゴールを決める –誰が何で使うか –ブレちゃだめ • できないこともある –ネイティブアプリではない –実現するための難易度とリスクのバランス –APIの森に迷い込まない • 基盤は整ってきた –ネット上の情報 –開発ツール類 79
    • まとめ • Flex開発は(まだまだ)フレキシブルじゃない –から、力を入れるところとそうじゃないところを仕訳する • やりきれば、 高い顧客満足度が得られる –リピート率高い!(※当社比) • 作っていて 楽しい! 80
    • ご静聴ありがとうございま した 81
    • 82