第4回(2008/10/04)
Basic(仮称)について

- イベント、プラグインのロードまで完了。
- プラグイン更新通知イベントを作る準備まで出来た。
- 更新を知る手段はアセンブリから取るか?タイムスタンプから取るか?タイムスタンプならロード不要。
- DIのような部分は保留する。現行はサービスロケータを持つ設計にする。
- Basicも幾つかの機能の集合体
- プラグインの動的なアンロードはどうするか?
- 関連する外部ライブラリの置き場所は?
- とりあえずプラグイン自身の側。重複については別途考える。
- ドメインを利用すると一緒に扱われる?(要調査)
- 今後のタスク
- 外部DLLを読める仕組みを付ける
- 動的なプラグインの導入の仕組みを付ける(WEB→Basic→アプリへ通知まで)
- ドメインについて調査する
※ DLLのメタ情報とDLLのロードについて考える必要がある。プログラムを作成する際はアトリビュート等を利用してメタ情報をソースコードに埋め込んだ方が判りやすいが、ソースコードに情報が埋まっているとロードしなければメタ情報を取得できない。これをある程度の利点を持ちつつ解消するには、例えば初回ロードした際に取り出したメタデータを永続化しておき、二度目以降は永続化データから読み込みを行うような手がある。永続化データと実データの食い違いを是正する為にDLLのタイムスタンプを利用するような形も考えられる。
次回作品について

- 既にms2によって叩き台がある。まずはBasic上への移植。
- 移植以上の魅力的な機能はあるか
- 乗り換えや宿泊、チケット予約を組み込んでライブに行くまでを誘導
- スキンのような機能(スタイル&Viewを作成可能&共有可能)→サービス化
すんごいスケジューラ
- Thunderbirdのプラグインにしたら良さそうだと皆の心を刺激
- 良くも悪くもフルスクラッチ
まとめ
既存のアプリのプラグインを作成するという配布に有利な形を取るよりも、自分達で作成するBasicのような部分を大事にしたいとの意見からとりあえずMusicJack。乗り換えや路線等を組み合わせた部分はシステムとして切り出して、スケジューラに生かす。
第3回(2008/03/29)

Basic(仮称)について
- プラグインロードシステムとしての実装まで。
- DLLの持つメタデータを初回ロード時に取り出してしまう仕組み(オプショナル)。
- イベントを通知する仕組みを次回導入する。まずFlexのような軽い仕組みで下記のようにする。
- 送信側 eventDispatcher.dispatch("イベント名", 通知オブジェクト)
- 受信側 eventDispatcher.register("イベント名", デリゲート)
- 型安全は失われるが、型が存在しないためのエラーは回避できる。コンポーネント間の強い依存性の回避。
- アプリケーションを作成するうちに明らかになる条件を元に将来的に良い方法へ変更する。
- そろそろ確定名を決める(ML)
- 確定名決定後、コミットする
- WPFサンプルをsandboxへコミットする
Antenna on IdbAについて
- Classifierを利用した利用者の好き嫌いを判断するコンポーネントが思想に強く合致。面白い。
- 上記のため、まだ開発凍結をせずに一ヶ月続行する。
- ページの好き嫌いを予測するViewのブラッシュアップ
- 興味があるという事実をソフトウェアとして抽出できないか?
- 長く見ていれば(放置されているかもしれない)
- スクロールバーの動き(多分興味ある)
- 文章を選択した、コピーした(強い興味)
- 蓄積データのUpdateInfoTableへの反映
ブレインストーミング
- OSは将来ウェブOSが主導になる?
- ウェブOSについての感覚を共有するに留まる。
- どこでネットワークに繋いでもいつもの環境が利用できるのはメリット。
- セキュリティさえ解決できれば?(コンシューマなら良いか?)
- 今使っているアプリが向こうへインストールできれば可能か。今のままでは乗り換えのモチベーションが低い。
- Browserでこのまま行く?
- 世間的にはそうなっている。
- 基本的に進む、戻るしかないUIがコンシューマにはわかりやすい。
- ローカルでやれることだったとしても、よりコーディングが簡単に済むのならブラウザのネット経由でも良いだろう。
- 住み分けの問題。
- 生き方
- 新しい技術を追いかけるのが楽しい。ずっとやっていたい。
- 新しいものを生み出したと思うのは自分の身の回りと比較して起こること。広げると世界で初めてにはまずならない。
第2回(2008/05/31)


1stリリースをいつにする?
- デブサミ(2月)を目標にしよう。発表をするかしないかは未定。
アプリケーションコンセプトをどうする?
コンセプトを決めると起こる事。
→嫌なこともあるかもよ?頑張る?
→次回の議題
俺らはどんな集団?それによって変わる
→コンセプトの例(叩き台)はkassy&ms2でちょっと考える(ms2イメージでは複数ある)
俺らはどんな集団?
→ターゲット
→選択技術
※まず一つ何か出せる流れを目指す方が良い。一歩目が重いのは勘弁。
イメージを語れるようになろう。
最近のアンテナ
- XMLコンソーシアムWeekに向けた拡張RSS検索画面
- ブラウザの表示部分をもっと弄りたい→今のJDICブラウザは不満
最近のこと
AIR
- 開発楽々。
- IDEでリファクタリングがまだ弱い→ローカルで動く小さいマルチプラットホームアプリなら良い。
Java
新規プラットホームについて
JDICでブラウザの表示を弄り続けるのに限界を感じるので
よりコンセプトを実現しやすいプラットホームについて考える。
プラットホームは大事
でも、アプリのレベルでまず一歩出そう。
プラットホームにかかり過ぎて見せられるものが無いのは辛い。
一般の人はブラウジングレベルまで?雑誌をぺらぺら捲る感覚。
一般人ターゲットなら、嫁さん連れてきて会議する?(笑)
UIをクールにするところだけでずっとやってける?
→世間のみんなと同じ事するよりも、別のこと。
→集合知ならぬ個人知などなど(ファイル検索じゃないよ。行動履歴だよ。)
行動履歴を蓄積される恐怖?
→みんなにちゃんと説明しよう。
→外には出さない。値の一致レベルしかやらない。など。
アンケートによるとSODECは技術よりの人が多いらしい。
→もっと技術寄りで話をして良かったのかもしれない。
→イベントそれぞれに対して対策をちゃんと考えよう。
http://www.afrous.com/
はちょっと面白いマッシュアップツール。
新プロジェクト
・JDICは扱いづらい
・今後どのようにやる?
・Antennna on IdbAは残す。Linuxコンソーシアムとの繋がり。
無料で楽々なIDEはなかなか無いぞ。
WindowsFormsがExpressでもRADっぽく使える.NETは良いね。
→とりあえずのViewはWindowsFormsで書いても良い。
UIマニアは直コード書きになる。
バックグラウンド中心の人はUIはサラッとできれば良い。
→分業してゆこう。
→全部一人でやらんでもええよ。
でも、サンプル的に人に出す時は?
WindowsFormsを使ってやろう(Expressでもできる)。
WPFはホストできるからどうにか接続できる。
Pluginシステムは大げさになる傾向がでかい。
依存性の解決とかいろいろ。
まず、懲りすぎずに適当なものを作成しよう。
「ちょっとしたBasic(仮称)をまず作ろう」
BasicはDLL
Registry
- 全てのDLLを知っている
- DLL追加、削除
- DLLロード、アンロード
成果物
備考
- モジュールがバージョンアップされた瞬間を知るイベントが欲しい
- コアな機能をBasic内に収めすぎず、公開する方向でやると良い
- 依存管理
IBMのEnterpriseMashupの概念は面白そう。
タブが増える。
続けてゆくと、意味がないペインが増える。
主体が移り変わるから困る。
マウスオーバーの時間。
過去見ていたデータが消えてゆく。
比較できるようにできないか?
履歴アクセス
レイアウト保存。一度ユーザに組んでもらって。
第1回(2008/03/29)

第1回会合のホワイトボード。
- 設定画面を呼び出すための標準的な仕組みを考える。
- IdbAドキュメントのリンクを記述する。
- Connector思想を取り込んだコンポーネント境界ゆるゆる計画について考える。
- Serialize機能を再確認。全ての場所で同じ仕組みを利用できるような標準化について今後考える。
- ainfoのUpdateKeyは削って良い。
- JavaDrive(http://www.javadrive.jp/)はJava初学者に有用。
- 使いやすいシステムは先読み検索がキー?
- 人間は自分に合った情報を探すのに多大な時間を費やしている。
- 集合知をP2Pで?
- ローカルにユーザの操作情報ログを蓄積して有効活用。
- Nodeを繋ぐ(似ている人が隣人)
- 情報を継続的に保存しているなら人間の成長の傾向が出せないか?