#devsumi2010 の参加者アンケートに記入中。過去のどの回に参加したかなんて、もう分からなくなってるので答えようがない。スキップ。

posted at 14:32:39

なぜか、#devsumi2010 とかに C++er という立場で参加する人は少ないような印象を持ってるのに気付いた。勝手な思いこみだとは思うけれど。

posted at 02:43:44

#devsumi2010 でお会いした方などを分かる範囲でふぉろってみた

posted at 20:54:37

#devsumi2010 の懇親会楽しかった。全く席を移動しない程度に話し込んだのは、良かったのかどうかというのはあるけれど。もうちょっといろいろな人とも話をしたかったかも。

posted at 00:44:42

今日も #devsumi2010 の日。今日は朝から行くよ。というわけで、そろそろ出かける準備。

posted at 08:10:39

@nsiena 同感。単にソフトウェアの機能、その裏に存在するデータ、それを扱う業務という深さで見るだけでは十分ではなくなっている。 #devsumi2010

posted at 08:31:14

@nsiena それを動かす人、人々の社会的関係や属するコミュニティの性質、それらが構成する社会全体との相互影響まで深め、考慮の対象に含めて行く必要があると思っている。 #devsumi2010

posted at 08:31:40

@nsiena そうして深く深く捉えて行くと。他のソフトウェア、データ、ユーザ、コミュニティとの関わりも考慮の対象に含まれてくる。それを包含しうる懐の深いアーキテクチャと、その上で形成されるエコシステムが求められるはず。 #devsumi2010

posted at 08:32:09

[19-C-1] 「これからのアーキテクチャを見直す」(10:00-10:50) : 途中から #devsumi2010 19C1

posted at 10:12:38

「関わった業務反意で、リーマンショック後に正社員が何%か、一時雇用が数%も減少している事実。SW蚕業は労働集約的で人件費の割合がおおきい。「顧客のために」は手工業的で、蚕業としてはより原始的という側面も。 #devsumi2010 19C1

posted at 10:16:58

「いかに早く作るか、から、いかに長く使うか、への転換。Force.com の開発効率は Java, .NET の 5倍。「開発生産性 (速度)」がではない! #devsumi2010 19C1

posted at 10:18:44

「クラウドへの移行。但し制約もある。転送量/速度, API, セキュリティなど。『何かを得れば、何かを失う』。発現場のに産業革命が起きる。新たな価値観は新たなアーキテクチャによってもたらされる。 #devsumi2010 19C1

posted at 10:23:01

「これからのアーキテクチャは。いかに長く使うか → 変化に適応する。本当に我々は適応できるか? これまでの変化への適応例: OO。変化しないモノ = 構造要素と、変化するコト = サービス/機能の組合せ。 #devsumi2010 19C1

posted at 10:27:38

「→クラス×ユースケースの組合せ。散乱ともつれ合いが発生。一箇所の変更が、複数箇所に横断的に影響。解決方法としての DI。構造要素間の関係の外挿。が、I/F変更に滞欧できない、複雑な依存性があると管理が繁雑になる。 #devsumi2010 19C1

posted at 10:31:14

「アスペクト指向。横断的関心事を扱え、クラスの変更なく後から処理を追加できる。明日ぺ句と感の依存に影響し、クラスの変更から影響を受ける。 #devsumi2010 19C1

posted at 10:32:34

「OO の限界。予見できる変化にしか最適変化できない。柔軟性を上げるには DI やアスペクトなど複雑にせざるをえない。経験や認識力に大きく依存。 #devsumi2010 19C1

posted at 10:34:36

「アジャイルプロセス。デザインパターン (構造設計→変化しにくく長く残る) から XP (プロセス→変化しやすく後に残らない) への移行。が、動的平衡にはエネルギーが必要。プロセスの安定を継続する熱意の維持は難しい。スケールもしない。 #devsumi2010 19C1

posted at 10:39:55

「OO にせよ、アジャイルにせよ、以前に対する改善にはなっているが、まだ不十分。構造の不変性を利用して変化の影響を管理する →モジュール。変化の方向を管理する →プラットホーム #devsumi2010 19C1

posted at 10:42:28

「モジュール: 実装の追加情報をメタデータとし、パラメータとして用いることで内部実装の切り替え。→ 例: モジュール管理基盤 OGSi によるバージョン違いのクラスのロードを解決可能に。 #devsumi2010 19C1

posted at 10:46:10

「内部実装は任意の開発手法で。部分単位の疎結合性を実現。→時間軸上での再利用。変化の影響の管理。[19-C-3] で OGSi の話があるよ。」 .o(まさに聴く予定 #devsumi2010 19C1

posted at 10:48:08

「プラットホーム(PF): ベース的PF (ガジェットやウィジット)。より上位の横断的PF。例えば Chatter (SFDC)。全データが喋り出す。データ中心コミュニケーションなので時間軸中心で変化するが、興味で選別するので軸がぶれない。 #devsumi2010 19C1

posted at 10:53:57

「プロセスとアーキテクチャの相補性。代表的なアジャイル者はアーキテクチャを作れ、アーキテクチャを前提としている人が多い。アーキテクチャを基本構造として、プロセスでハンドリングする関係。 #devsumi2010 19C1

posted at 10:56:04

「再: 『何かを得れば、何かを失う。そして何物をも失わずに次の者を手に入れることはできない』。自分がどこにいるのか、自覚的でなければいけない。アーキテクチャにも興味を持って欲しい! #devsumi2010 19C1

posted at 10:58:03

[19-B-2] 「Agility@Scale (アジャイル開発のスケールアップ) を実現する」(11:10-11:55) #devsumi2010 19B2

posted at 11:12:27

「アジリティが求められる理由: 経営戦略の寿命が短期化。競争力の持続のための変化への対応。アジャイル導入の効果は魅力的: 生産性, 品質, 顧客満足度, コスト。 #devsumi2010 19B2

posted at 11:15:59

「IBM。80s はウォーターフォールでメインフレーム用。90s は反復型開発 (RUP) で分散プラットホーム用。現在は完全にアジャイル開発に移行し、ウェブなどへ。 #devsumi2010 19B2

posted at 11:17:49

「トピック: アジャイル開発の 1) 本質. 2) 企業に導入する際の課題, 3) 規模に関係なく適用可能なプラクティス, 4) 大規模だからこそ考えるプラクティス。 #devsumi2010 19B2

posted at 11:20:45

「各アジャイル開発手法のベストプラクティスの共通点。反復・インクリメンタル・適応型, 短いタイムボックス内で動くコード, 小さな一口単位で開発。アジャイルとリーん開発手法の関係。 #devsumi2010 19B2

posted at 11:21:10

「ウォーターフォール: 要求をまず確定して、計画をリソースと期日で定める。計画重視。アジャイル: リソース・期日を固定して最善の要求を優先度に従って定める。価値重視。 #devsumi2010 19B2

posted at 11:29:59

「2) 導入の課題。企業レベルでは使えないと思われている? 小規模開発から発達してきたという経緯。大規模開発に不向きなプラクティスの存在。新しいものを導入する文化的困難さ。 #devsumi2010 19B2

posted at 11:32:21

「実際は。方法論、技術、ツールは発達した。不向きなプラクティスはある程度は工夫で対応できる。 #devsumi2010 19B2

posted at 11:34:18

「規模に関係なく適用できるプラクティス。Jazz プロジェクトの RTC (Rational Team Concert) の開発経験から。 #devsumi2010 19B2

posted at 11:36:09

「1. 定義構築テストのコンポーネント・チーム: 2段階のチーム校正。4～10人 x 20チーム + プロジェクト運営委員会 (PMC) #devsumi2010 19B2

posted at 11:37:33

「2. 反復型か遺髪、頻繁な小規模リリース: ウォームアップでリリース計画 → 4習慣ごとの計画・開発・安定化 の繰返し →エンドゲームで修正・洗練化・テスト #devsumi2010 19B2

posted at 11:39:33

.o(速すぎてむりー #devsumi2010 19B2

posted at 11:43:25

「3. 2レベル計画づくりと追跡: 荒いリリース計画を PMC が。詳細な反復計画は各チームが実施。これを RTC で管理し、誰でも見えるように。 #devsumi2010 19B2

posted at 11:43:50

「4. コンカレントテスティング: 反復後とにチームレベルで、単体・機能・受入れテストを。 #devsumi2010 19B2

posted at 11:43:54

「(取りこぼし)。リーン要求開発: 構想書を定め、砕いて分割作業。高度に分散した開発の管理: 情報共有のためのコミュニケーションツールで。 #devsumi2010 19B2

posted at 11:48:05

アジャイル・リリーストレイン: リリースは遅らせられないスケジュール。チーム間で同期しないといけないから。機能を簡易化して対応。 #devsumi2010 19B2

posted at 11:48:34

「ビジネスパフォーマンスの計測: 複数プロジェクトを比較してポートフォリオを作成できなければ経営層に理解されない。RTC ではダッシュボードを提供。 #devsumi2010 19B2

posted at 11:52:39

「アジャイルは使える。大規模にスケールアップ可能。『アジャイル開発の本質とスケールアップ』も参照。RTC Express-C は無料なのでお試しを。 #devsumi2010 19B2

posted at 11:55:17

おひるたいむ。めんどい(← #devsumi2010

posted at 11:57:06

.o(後半が大規模開発に適用する際のポイントなのだから、こっちに焦点を当てて話して欲しかったな。前半は軽く復習する程度で。だいぶ消化不良。というか入力不足。 #devsumi2010 19B2

posted at 12:32:39

会場を締め出されて、難民状態。一つくらい部屋を開放して欲しかった ;_; #devsumi2010

posted at 12:34:36

[19-C-3] 「成長できるエンタープライズシステムを目指して - OGSi によるモジュール型アーキテクチャの提案」(13:10-14:00) #devsumi2010 19C3

posted at 13:10:58

.o(え。OSGi って、あまり知られていないの? 詳細は知らないまでも、存在の認知度はそれなりだと思ってた。 #devsumi2010 19C3

posted at 13:12:37

「システムはそもそも複雑なもの。『Think small』という考え方。複雑さを軽減する仕組みが必要あり。例えば、Eclipse や PC の成長の要因の一つはモジュール型アーキテクチャであったこと。 #devsumi2010 19C3

posted at 13:18:59

「Small is beautiful。『UNIX という考え方』。柔軟な構成、保守性、理解容易性、などの利点。 #devsumi2010 19C3

posted at 13:20:00

「Java では jar があるが、モジュール性の維持が難しい。例えば、ある jar が依存する jar の情報を持たない。 #devsumi2010 19C3

posted at 13:24:14

「再利用の軸: 空間, 時間。成長するシステムでは時間軸での再利用性が重要。システムの全更新では影響範囲が把握できない。→分割して影響範囲を限定。 #devsumi2010 19C3

posted at 13:27:22

「モジュール型システムの開発コストは、意識しない時の 3倍。独立性の担保と依存関係の整理が必要。小さい規模ではコストが合わないので使うべき場所は的確に。 #devsumi2010 19C3

posted at 13:30:41

[19-C-4] 「次世代型情報取得システムの構築技法 ～ CRUSE開発を通じて」(14:20-15:05) #devsumi2010 19C4

posted at 14:20:50

実世界文脈とマルチモーダルな話? すみません、CRUSE しらない >< #devsumi2010 19C4

posted at 14:22:35

「インフラの発達: 端末インフラ (モバイルPC, 携帯端末), 通信インフラ (高速通信), データインフラ (クラウド・企業内データ) → 移動時の情報活用。 #devsumi2010 19C4

posted at 14:28:24

「課題1: 情報取得・入力手段の不足。キーワード入力→結果一覧という PCスタイルの適用は無理。課題2: システム提供側の都合。既存アプリが PC 向け。ケータイ向けでも深いメニュー階層、構築ノウハウの不足。 #devsumi2010 19C4

posted at 14:29:01

「要素技術: RIA, マルチタッチI/F, 加速度センサ, 音声認識・合成, GPS, カメラ。しかし、根本的には人間の行動プロセスから見直すべき: 操作→認知→判断→操作のループ。これが滞りなく回るようにそれぞれを検証。 #devsumi2010 19C4

posted at 14:32:52

「操作: システムへの意図伝達方法。その場で使える複数の手段を自由に組み合わせる (音声, キー, タッチ)。なるべく少ない手数で操作する (それまでの操作過程, 環境情報)。原則としてシンプルに使えるもの。 #devsumi2010 19C4

posted at 14:35:02

「認知: データ表示方法。瞬時に全体把握を可能に (図形を効果的に利用, 詳細は必要になってから提示)。複数種類の出力を活用 (音声ガイダンス, 震動での通知)。危機逃しがあるので、重要な情報は画面に出すなどが必要。 #devsumi2010 19C4

posted at 14:37:36

# 「判断: データ参照視点の変更手段。システムがナビゲート (狭く絞り込む条件, 増やせる条件)。ユーザ嗜好の反映 (個人化により試行錯誤を削減, 過去の操作履歴からの嗜好抽出)。原則: 主導はユーザで、オプションという位置づけであるべき。 #devsumi2010 19C4

posted at 14:42:51

「→文脈志向マルチモーダルの提案。内部処理: 多種の入力を文字に一元化。概念定義メタデータによりデータ変更・拡張に対応。RDB/XML/ウェブに対応したデータ取得。個人プロファイルに基づく個人化。音声によるユーザ操作と図示による認知の支援。 #devsumi2010 19C4

posted at 14:45:36

「データ取得部: 対話・処理を実行するエンジンであるエージェントネットワーク (Answer Anywhere) を利用。特徴: 視覚的編集, 概念定義とデータの直接的な対応付け, コンパイル不要, ネットワーク表現による拡張性など。 #devsumi2010 19C4

posted at 15:00:32

「ネットワークは RDB と対応付けしやすい: フィールド (column) の組でオブジェクト (table), オブジェクト間の関係 (relation), オブジェクトに対してコマンド (operation)。 #devsumi2010 19C4

posted at 15:00:58

「適する領域: 属性の種類が多い構造化されたデータや、個体抽出を目的とした図示が有効なデータ。 #devsumi2010 19C4

posted at 15:04:12

「例: 営業印向け顧客情報検索, 社内文書検索, 多種コンテンツの串刺し検索, マイクロブログをトリガで動く情報端末(どゆこと?)」 .o(構造化された→半構造のこと? #devsumi2010 19C4

posted at 15:04:22

そろそろバッテリが干上がるよー。休憩時間までは持つかな。 #devsumi2010

posted at 15:05:51

2本め。最後まで持つかな、むりかな。がんばれバッテリ。 #devsumi2010

posted at 15:25:40

[19-B-5] 「出張! DDD難民救済キャンプ ～ドメイン駆動設計の使いどころ～」(15:25-16:15) : このセッションはメモ取るのはつらそうかも #devsumi2010 19B5

posted at 15:25:48

# [19-B-5] 「出張! DDD難民救済キャンプ ～ドメイン駆動設計をあきらめない～」(15:25-16:15) : タイトル変わってた #devsumi2010 19B5

posted at 15:26:16

和田「DDD = Domain Driven Design。厚さ 43mm! 読んだ人は会場の 3割くらい。読み切った人は……一人 ^^;? パネリストは読み切った方々!! ソフトウェアの内面の美しさがここにありそう。 #devsumi2010 19B5

posted at 15:29:23

角田「JaveEE 勉強会で DDD読書会をした。他の 3名に比べて、やや冷ややかな立場。 #devsumi2010 19B5

posted at 15:30:31

渡邉「大きなプロジェクトで残念な設計に度々出会う。DDD が参考になるのでは。大規模開発でどのように使えるか、という立場から。『実用Git』の共訳したよ。 #devsumi2010 19B5

posted at 15:32:24

和智「元は文系 (思想研究) 出身。DDD は概念的モデリングという点で興味深いと考えている。 #devsumi2010 19B5

posted at 15:33:34

佐藤「『ThoughWorksアンソロジ０』『ソースこーどりーでぃんぐからまなぶ Java の設計と実装』など。DDD はかなり肯定派。 #devsumi2010 19B5

posted at 15:34:54

角田「DDD は、日本ではまだ広まっていないが、海外ではかなり広まっている。Y! Groups の投稿数が急激に増加中。理由は? #devsumi2010 19B5

posted at 15:38:29

角田「Transacrion Script パターンが進み過ぎ、ドメインモデル貧血症に。NoSQL の流れで DBMS が担当していた処理をドメインオブジェクトなどで処理する必要が出てくるだろう。 #devsumi2010 19B5

posted at 15:40:06

角田「DDDの副題は The Heart of Software。ユーザドメインに関連した問題を解決する能力。言語等の実装技術だけでなく、ドメインモデルのような業務の問題解決の技術を身に付けていかねばならない。 #devsumi2010 19B5

posted at 15:41:26

佐藤「DDD の本質の本質とは。ドメイン = 知識・組織・活動の領域。これがアプリの中核。仮説: 複雑なドメインはモデルに基づいて設計すべき。→ 有能なドメインモデラは知識を噛み砕いている。 #devsumi2010 19B5

posted at 15:45:50

佐藤「ドメインモデルをユビキタス言語として用いて、ユーザとの対話、開発過程への展開。それがモデル駆動。実現できないところはモデルにフィードバック。モデル～実装の双方向性。 #devsumi2010 19B5

posted at 15:47:57

佐藤「ドメインモデルをインクリメンタルにリファクタリングして、業務を深く反映したモデルを作成していく。これはブレイクスルーを生み、新たな問題への解決が見出されやすくなる。 #devsumi2010 19B5

posted at 15:48:44

和田「読み切った感想」佐藤「DDD こそが SW の目指すべき最終形。技術はうつろう。ドメインのモデリングは息が長い。」 #devsumi2010 19B5

posted at 15:51:46

角田「よいものである。しかし、手放しで誉めるものでもない。開発の生産性を高めはしない。手間をかけて洗練させていくものだから。納期が割きに来てしまう。著者も 90% の案件は適用する意味がない、と述べている。 #devsumi2010 19B5

posted at 15:52:27

渡邉「意義は、短期的でなく長期的なもの。変更への対応を容易にする。1/10 の確率で適用すべき案件があるとも言える。このアプローチを見に付けた上でしまっておく。というところで良いのでは。 #devsumi2010 19B5

posted at 15:54:51

和智「具体的な実体があるものでなく、開発の中で徐々に効果を持つもの。『深いモデルは、新しい言葉を見つけることで見えていなかったものが見えてくる。』とも述べられている。 #devsumi2010 19B5

posted at 15:56:28

渡邉「『Domain-Driven Design Quickly 日本語版 (ダウンロード可)』『ドメイン駆動 (DDDの翻訳ではない)』 #devsumi2010 19B5

posted at 16:01:51

和田「実装者が見るべき情報は」和智「DBアクセスの DAO を Repository パターンにしてみる(笑)」渡邉・佐藤「データからでなく概念的観点から取り組むもの」佐藤「モデラは実装できねばならないし、実装者はモデルのことを考えるべき。 #devsumi2010 19B5

posted at 16:04:13

角田「SF に DDD のサンプルアプリが公開されている。コードレベルでどうするか見てみるといい。」「DDD サンプル でぐぐると見つかるはず。 #devsumi2010 19B5

posted at 16:05:51

和田「設計者向けには?」佐藤「実装をしてみたりしつつトライ」角田「プログラミングで着ないから設計者になろう→だめ。他の方法として、コードレビューのレベルでいいから十分に関わる。その際にユビキタス言語ができているか。」 #devsumi2010 19B5

posted at 16:07:53

和智「顧客と話しながらドメインモデルを考えていくはず。そこでユビキタス言語を作れるかという点に気をつける」和田「いろいろな役割の人を繋げる言語 #devsumi2010 19B5

posted at 16:10:13

和田「マネージャに対して」渡邉「業務の観点でチーム分けしたりしている。DDD 的には高次の設計判断として扱われている問題。チーム間/成果物の関係によって、調整方針が述べられていたりする。」 #devsumi2010 19B5

posted at 16:14:19

佐藤「共通基盤を優れた人が作ることが多いが、DDD はアプリエンジニアの復権とみなせる。業務モデルに力を注ぐ」角田「実装者以外にコードを見ること、設計者以外がモデルを意識すること。そういうコンセンサスが必要。 #devsumi2010 19B5

posted at 16:14:24

和田「締め」角田「JavaEE勉強会 (Google Groups javaee-study)。DDD-jp ML (同 ddd-jp)、できたばっかり!」「皆で議論して行こう #devsumi2010 19B5

posted at 16:16:03

.o(すばらしかった。これをきっかけに、ドメインモデルへの理解が広まるといいな。(ドメインモデルに限らず) 概念的な理解の下での問題解決は、要所要所で大切! #devsumi2010 19B5

posted at 16:18:48

いいかげん、くたびれてきた ^^; #devsumi2010

posted at 16:31:22

[19-C-6] 「クラウド時代のアプリケーション開発環境 ～Spring Framework、仮想化と企業クラウドの融合～」(16:35-17:20) #devsumi2010 19C6

posted at 16:35:35

「問題点: インフラの複雑性、非効率性、柔軟性の欠如。IT予算の 70% 近くが現状の維持費。ビジネスの俊敏性は IT の俊敏性で決まる → 仮想化によってワークロードを平滑化。 #devsumi2010 19C6

posted at 16:40:39

.o(ちなみに。DDD に対する立場は。実務での実用はかなり案件を選ぶだろう。それでも身に付けるべき。/ 問題の本質を見極めやすくなる。良い設計の勘所を掴みやすくなる。設計の意図を理解した/設計者の観点も持ちつつコード化できるようになる。 #devsumi2010 19B5

posted at 16:48:09

.o(ある意味で能力開発・向上という意味がある。実装技術だけを見ていては、本当の職人レベルにまで到達できていないならば歪なものを作りかねない。自分の解決すべき課題があった時、もう一段抽象的なレベルで捉えられるか否かは重要な違い。 #devsumi2010 19B5

posted at 16:48:38

.o(具体策・開発手段とかでなくても、全く構わないというか、抽象論ウェルカムだけど。このまま IaaS の話で最後まで行っちゃうのかしらん。それだと、さすがに聴き飽きてるのよねぇ。 #devsumi2010 19C6

posted at 16:50:36

いつものように、聴きながらメモを書き流す一方で、TL を全然読んでない。この間の議論は気になるけれど、メモ書いてなくても、きっと読む余力はないのだろな。近くにいる方、何人もいらっしゃるのだろな。 #devsumi2010

posted at 17:36:07

[19-B-7] 「次世代 Web 標準 HTML5 最新動向」(17:40-19:10) : そろそろ最後のセッション。ここしばらく集めてる情報と大きく差があることはないと思うけれど。それでも外せない。 #devsumi2010 19B7

posted at 17:40:48

[19-B-7] 「HTML5 と Web プラットフォーム」(17:40-19:10) : これもタイトルが変わっとる。 #devsumi2010 19B7

posted at 17:42:06

.o(いつもの不満は。プログラミングの観点からの話ばかりが、これぞ HTML5、と扱われているようなところ。確かに、大きな違いだし、分かりやすい観点ではあるけれど。ウェブって何よ、と感じなくもない。 #devsumi2010 19B7

posted at 17:42:43

.o(このタイトルは、HTML5 != アプリプラットフォームということかしらん。期待。まぁ、内容は切り分けたという位だと思うけれども。整理重要。 #devsumi2010 19B7

posted at 17:44:17

名倉「なぜ HTML5 か。ここ数年のウェブの使われ方の大きく変貌。静的コンテンツ →動的コンテンツ (ウェブアプリ)。更に、ページ繊維のない I/F。DnD 操作による対話的な地図。 #devsumi2010 19B7

posted at 17:48:27

「技術の変化は。HTML, CSS, JavaScript, DOM, ... → ウェブアプリの発展には不足。 #devsumi2010 19B7

posted at 17:51:00

XHTML 2.0, XForms, ... → XML はブラウザ環境ではどちらかというと冷遇。開発者は賛同せず、今使われているものを拡張して利用。だが、プラットフォームも安定していない。 #devsumi2010 19B7

posted at 17:51:04

「HTML5 の目的: 機能の拡張と安定性の向上。「HTML5」と呼ばれるが、HTML5 ではないもの (分離されたもの) もある。CSS3 に至っては、まるで関係ない。言葉を使い分けよう!! #devsumi2010 19B7

posted at 17:52:15

「HTML5 の新しい語彙。新要素や追加属性。良く使われる id/class をニーズとみなして、要素を導入: header, section など。定型句はより簡潔に: 文書型宣言, 文字コード指定など (古いブラウザでも機能する!)。 #devsumi2010 19B7

posted at 17:55:46

「自動記憶を無効化する autocomplete 属性。値必須化の required 属性。値検証の pattern 属性。但し、サーバ側での検証も必須。 #devsumi2010 19B7

posted at 18:00:28

「canvas 要素と 3D Context: JavaScript でコンテキストを取得して、Canvas API で描画。Immediate Mode なので、描画結果は操作できない。アニメーションは都度書き直し。描画は高速。 #devsumi2010 19B7

posted at 18:03:44

「Mozilla の Bespin: Canvas ベースのテキストエディタ。Sketchpad: SVG を併用したドローイングツール。結構軽い。 #devsumi2010 19B7

posted at 18:05:21

「audio, video 要素。画像と同じような使用感。プレイヤ UI も標準で提供。プラグイン実装でないので、CSS や Canvas と組み合わせ可能。コーデックの特許問題が残っている。YouTube (TestTube) などが利用。 #devsumi2010 19B7

posted at 18:09:02

「Web Storage: KVS 的。クライアント側に永続記憶される localStorage と、セッション間のみ有効な sessioStorage。他に、Web SQL Database, Web Indexed Database。 #devsumi2010 19B7

posted at 18:10:34

「Web Workers: 重い処理を別プロセスに。メッセージングによるワーカ間通信。Shared-nothing なので、ワーカ作成元の DOM 木にアクセス不可。 #devsumi2010 19B7

posted at 18:12:13

「Application Cache: クライアント側でキャッシュさせたいリソースを html/@manifest で指定したファイルに明示的に記述。 #devsumi2010 19B7

posted at 18:14:52

「Online/Offline events: vavigator.onLine でチェック、window.{online,offline} にイベントハンドラを設定。 #devsumi2010 19B7

posted at 18:15:04

「Web Socket: 接続を維持する双方向通信。複数人で編集できるアプリが増えていく? #devsumi2010 19B7

posted at 18:16:37

「プラットフォームの安定化: 相互運用性が必要。今まではクロスブラウザ対応に多大な労力。動作レベルの仕様が存在しない、または詳細が未定義 →独自補完・拡張。この反省の下、DOM を中心として再定義。DOM の一貫性: 構文解析やエラー処理。 #devsumi2010 19B7

posted at 18:19:51

#devsumi2010 19B7

posted at 18:21:35

「HTML5 は既に巨大で、4MB の HTML ファイル。勧告は当分先。しかし、実装は進んでいるから、既に部分的に使える状況。機能によって、仕様の安定度が異なる →よく練られたところから実装が進む。 #devsumi2010 19B7

posted at 18:23:56

「ブラウザごとに実装状況は異なる。使いものにならないわけではない。全てが一度に変わることはないのは従来通り。対処方法: A) サポートされない機能はフォールバック, B) プラットフォームを限定。 #devsumi2010 19B7

posted at 18:26:15

「考え方を変えて、付き合って行こう!」 .o(使える環境向けにはうまく活用して。機能しない環境では代替表現へのフォールバックでそれなりに。 #devsumi2010 19B7

posted at 18:27:37

白石「Web Messaging が変える Web アプリ開発 (ダイジェスト版)」「html5-developers-jp コミュニティをよろしく! Webを笑顔にする会社を近々立ち上げるよ! 『HTML5 & API』発売。 #devsumi2010 19B7

posted at 18:30:52

「Web Workers は革命。ユーザビリティに優れたアプリを、美しくて簡潔なプログラムを書ける。並列処理なのでマルチコアも有効活用」 .o(ブラウザの実装次第かな)。 #devsumi2010 19B7

posted at 18:33:43

「JavaScript プログラムは層化に向かうだろう: ブラウザ上で UI層 + ビジネスロジック層 (BL)。後者がサーバと通信。このアプローチで実装してみている。BL とサーバ間のメッセージプロトコルを決める必要あり。 #devsumi2010 19B7

posted at 18:36:50

「プロトコル設計がめんどう。クライアント/ワーカ双方で実装するのがめんどう。」.o(そりゃそうだ。ネットワークアプリを書くことそのものだもの。抽象化された TCP の応用を決めるようなもの。 #devsumi2010 19B7

posted at 18:38:18

.o(ウェブのリソースは HTTP で十分にアクセスできるように設計すべし。効率的にリソース状態を変更する裏口として Web Sockets を使うのが適切なのではないかしらん。 #devsumi2010 19B7

posted at 18:41:43

「デモとコードの簡単な解説。コミッタ募集中。やることたくさん。活躍するチャンス! #devsumi2010 19B7

posted at 18:42:18

漏れ「従来の仕様との互換性: 従来のコンテンツをそのまま利用。新しい機能が旧仕様を破壊しない。実装を通じて確認しつつ策定。一方で、悪しき部分にひきずられないように。 #devsumi2010 19B7

posted at 18:43:25

「1) HTML5 Canvas and Audio Experiment: 便利なライブラリが既に存在。Modernizr 使える機能を判別, Processing,js 描画・動きの API を提供, jQuery 定番。 #devsumi2010 19B7

posted at 18:48:59

波田野「HTML5 Show Case」「幾つかの作品を紹介。 #devsumi2010 19B7

posted at 18:50:40

「canvas の使用可否の確認。使えるエンコーディングタイプにあわせて音声ファイルを選択。粒子の描画と移動は本当に簡潔に書ける。 #devsumi2010 19B7

posted at 18:52:34

「2) Movement tracker: Web Workers を使ったおもしろいデモ。Fx でのみ動く。動画中の動きを JavaScript で計算して検出。 #devsumi2010 19B7

posted at 18:56:09

「実現方法: video, canvas x3 の構成。video は非表示にして、プログラムで画像として取得して、グレースケールにして、時間差の差分を計算して、canvas に描画。 #devsumi2010 19B7

posted at 18:57:11

「3) Sketchpad: ドローツール。内部にツールウィンドウを開ける。canvas 1 枚では扱いにくいので、7 枚の canvas を重ねて表示。#1 以外は作業用の canvas。 #devsumi2010 19B7

posted at 19:00:22

「4) Star Wars EpisodeIV: オープニングを audio 要素と CSS3 を使って再現。CSS3 Web Fonts, CSS3 Transision, CSS3 Animation。 #devsumi2010 19B7

posted at 19:03:14

小松「Web SQL Database を使った(略)」「チェックした店舗情報に応じて検索順位を入れ替えるアプリのデモ。MeCab サーバで分かち書きして Web Socket で呼出し。 #devsumi2010 19B7

posted at 19:09:30

竹迫「HTML5 最新動向 File API」「HTML5 ではない。ファイルの読み書き。複数ファイルの選択・送信。複数ファイルを zip にまとめて保存するデモ。巨大なファイルを処理すると CPU 100%! #devsumi2010 19B7

posted at 19:14:43

「JavaScript 1.7 の yield で generator を作ってループさせて、timeout を設定してみた。これで重たい処理も改善。→ yield + setTimeout イディオムの完成。でも Fx でしか動かないよ。 #devsumi2010 19B7

posted at 19:17:14

植山「Flash vs Canvas」「2D Context でザ表計算と画像変形で 3D 表示とか。ネギ振りミクとか。Google Box とか。作ってる。 #devsumi2010 19B7

posted at 19:20:31

「HTML5 → Canvas → Flash というよくある流れ。スプライトや 3D サポート、フィルタなど、画像描画は Flash が圧勝。某 3次元地理空間情報データベース登録ツールは Flash を使わざるをえなかった。 #devsumi2010 19B7

posted at 19:22:53

「裏は、A) HTML + JS, B) Flash, C) サーバ の三角関係の通信。Flash と HTML + JS の壁が原因。Canvas なら壁がない。 #devsumi2010 19B7

posted at 19:26:02

「Google Wave のウィジットであるルービックキューブのデモ。全部 JS で書いてある。ねるサービスでは、睡眠時間を記録して canvas を使って表示。きれいに表示できて、サーバに負荷がかからない。 #devsumi2010 19B7

posted at 19:30:00

「HTML ベースの開発者 →もっと気軽にグラフィックスを。Flash 開発者 →もっと気軽に HTML を。 #devsumi2010 19B7

posted at 19:31:09

本日はこれでおしまい。どれもおもしろかった! #devsumi2010

posted at 19:31:41

今日のデブサミのメモ <http://bit.ly/aH9veq >。同じく昨日の <http://bit.ly/anph4j >。 #devsumi2010

posted at 22:27:37

#devsumi2010 を遡るには膨大すぐる。もうだるいので諦めた。

posted at 22:41:35