４つ目のセッション。
細川 宣啓氏の
「品質検査技術のトレンド–レビューと測定・欠陥工学を中心に-」。
多分QCon Tokyo2011で私が見たセッションの中で
一番上手かった＆見事だったと思う。
地震すらアイスブレークに利用する、テンポもいい、適度に刺激を入れる。
かつ内容としても非常に興味深いものでした。
総合的に見て、細川さん程プレゼンを上手い人はほとんど見たことが無い。
キーノート２の伊藤さんや、最後のクラウドパネルディスカッションは
胸が熱くなる方向性な関係上、軸が違うのであまり比較できませんが。。。。
とりあえず、Hemletの法則は再確認しておこう。
まずは冒頭のキーノートのまとめから。
Eric Evans氏の
「ドメイン駆動設計：複雑な問題群に対する有用なモデル達」。
ぶっちゃけると一番難解だった。
システムレベルのモデリングを行ったことが無いからある意味当然かな．
私は現状ベースのモデルは切られた上で、
その上でミクロな設計をしているにすぎないから。
とまぁ、まとめは下記の通りです。
QConTokyo2011 に参加してきました！
まともに参加した初めてのセミナーだったため、非常に新鮮でした。
まとめをしたい所なんですが、時間も時間で眠いため、
参加した各セッション毎の決め台詞というか、ポイント一覧だけまずは投稿します。
ドメイン駆動設計：複雑な問題群に対する有用なモデル達
現実/何にでも使える１つのモデルを追い求めるべきではない。
あくまで"何のために？"をベースに役に立つモデルを選択すべき。
設計時に役に立つモデルが見えていることはまず無い。
Webアプリケーションエンジニアがみてきたこの10年
エンジニアの誇りとは、高度な技術によって得るものではない。
自らが使命とする問題領域をより高度な技術基盤によって発展させることによって
得るものである。
＃微妙に違うかもしれません。
自律的な学びのデザインと誘発 ― 学びのパターン・ランゲージ
変化が激しい現代社会では、詰込み型ではなく、
新しい関係性を発見し、自ら意味を編集・構成していけるような「創造的な学び」が必要。
そして、デザインパターンだけでなく、「創造的な学び」にもパターンが存在する。
品質検査技術のトレンド–レビューと測定・欠陥工学を中心に-
品質とは，腕で作り出すものではなく， 科学の力と目で創出するものである
サービスのスケーラビリティと無停止のためのインメモリ技術
サービス無停止と将来の規模拡張に対応可能な仕組み、
“分散キャッシュ” という考え方
Performance Engineering at Twitter
Just do less
Focus on Memory
Access data explicitly and in bulk
let the code make informed decisions
形式手法の現在と実開発への適用可能性
形式手法はレビュー／テストの限界を超えて検証が可能
但し、万能ではない。銀の弾丸は存在しない。
他の手法と組み合わせることで大きな効果を発揮することが出来る。
クラウドパネルディスカッション
クラウドを通して日本をよりよくしたい想いは皆共通。
ただ、『今までと全く同じものを安く手に入れる』ことはクラウドでは出来ない。
それは忘れないでほしい。
Androidだったり、クラウドだったり、分散システムだったりするののメモ
Androidをデバッグし、メモリダンプからデータを復旧する
http://monoist.atmarkit.co.jp/fembedded/articles/filesys/10/filesys_10a.html
Androidを組み込みボードにインストールして、
Linuxのメモリ管理を見よう、という企画。
自分で何かハードを組むことは無いでしょうけど、こういうのは面白いなぁ。
Java ベースのNo SQL ミドル Apache Cassandra
http://gihyo.jp/dev/serial/01/cassandra/0001
分散ＤＢ／ＦＳがフルにJavaで構築されているのって珍しいなぁ。
Hadoop MapReduceプログラムを解剖する
http://codezine.jp/article/detail/5582
今更といえば今更ですが、Hadoopも。
このへんの概念一度きちんと学んでおく必要がありそう。
Thrift
http://blog.broomie.net/index.cgi?id=38
これも今更といえば今更ですが。
後は、Thrift、ProtocolBuffer、MessagePackって、性能に関しては下記ページみたいに
調査結果があるんだけど、開発コストとしてはどんなものなのかな？
パッと見た感じ、通信スケルトンまで自動生成してくれるThriftがいいように見えるんだけど。。。
http://d.hatena.ne.jp/shot6/20091112/1258002372
分散バージョン管理システム「Mercurial」
http://journal.mycom.co.jp/column/ide/093/index.html
GitでなくてMercurialかぁ。
Google Codeでも使われているし、情報はおっておくべきかな。
Htmlコーディング支援「Zen Coding」
http://journal.mycom.co.jp/column/ide/098/index.html
モック書く時には使えるのかなぁ。
気になったので残しておこう。
これまでERP/CRMとかのソフトウェアって、
商用なソフトウェアばかりかと思っていたんですが、
下記みたいにOSSのソフトウェアも存在するらしいです。これ結構意外。
Adempiere
Compiere
もしかすると、こういったOSSをベースに
後、AdempiereについてはリポジトリでJavaで書かれていることを確認。
これは普通に改造していろんなものに使えるんじゃないかな？
CompiereはCVSリポジトリは見つかったんだけど、
ソースはまだ見えない。。。とりあえず何の言語で書かれているか
どうか、くらいは確認しておこうっと。
追記：
CompiereはJavaベースのようなのですが、
なんか既にリポジトリはほぼ稼働していない状態？
ファイルが見つかりませんでした。
ただ、ソースコード一覧はダウンロードできて、きちんとJavaでした。
通信用のライブラリとして最も気になっているのが、MessagePack。
Google のProtocolBuffersと比べても4倍も高速という辺りが非常に興味深い。
シリアライズの負荷も小さく、サイズも小さいという理想的なライブラリに見えます。
ハード性能、ネットワーク帯域がどんどん大きくなるから
そういったものは必要ないじゃないか、という気もしますが、全然違う。
アプリケーションが通信を行う量の方が其れ以上の速度で増えていますし、
パブリッククラウド上に乗せる場合は計算量、ネットワーク流量が
まんま使用料として跳ね返ってくるわけですし。
なので、今でもこういうのは重要。
てなわけで、調べてみよう、っと。
そろそろ今年も終わり、ということで、来年に調べると面白そうな技術要素を
列挙していく方針で。
今回はSonar。（InfoQ）
何かというと、ソースコード品質管理ツール。
リポジトリに登録されたソースコードに対して解析を行い、
結果をレポート形式で出力するツールです。
ソースコードの量やら、コメント率やら、ソースコードの複雑度やら。
これだけだと他にもあるんですけど、面白そうなのは「アーキテクチャルール」。
＝＝＝
開発者は、異なったパッケージにあるクラス間での参照を認めないパターンベースのルールを
定義することができる。
パターンの例には、*.dao.* クラスから*.web.*へのアクセスを禁止したり、
どのクラスからも java.util.Vector, java.util.Hashtable や java.util.Enumeration へのアクセスを
禁止するものが含まれている。
ソースコードがアーキテクチャ制約のセットに忠実に守れば、
プロジェクトは、アーキテクチャ モデルを遵守することになる。
このルールを使うには、Javaのバイトコード 分析が必要である
＝＝＝
参照をルールとして定義して警告が出せるのは面白い。
これを利用すれば、下記みたいな解析が出来そう。
前回に続き、Androidのテストアプリ作成中。
。。。なんですが、なんか上手くいかない。
とりあえず、今困っているのはServiceにタイマーをセットしても、
定期的にタスクを実行してくれないこと。
下の【作っているコード】みたいに、Activityから呼び出しを行ったタイミングで
タイマーを生成しても動かないっぽい。
他のサイトを見てみると、下記２点のようになっていた。
１．タイマーをサービス生成（onCreate）時に生成する。
２．タイマー生成時に、定期的に、登録されたCallbackを実行するタスクをするよう設定
１、２共にユーザが使わないのに無駄に処理を行う必要はないだろうなぁ、
と思ってあえて省いていた部分。
なんだけど、実はAndroid的には重要だったりするのかな？
生成時にタイマーを保持していないServiceは
監視対象から外されて後からタイマーを追加してもタイマーが動作しない、とか。
それとも、デーモンタイマーにしてしまっているのがまずいのかなぁ。
はてさて。
次試すときに確認してみよう。
■作っているコード
/**
* 定期通知用のサービスクラス
*
* @author フクシ―
*/
public class TimerService extends Service
{
・・・略
/** 定期通知用のタイマ */
private Timer timer_;
・・・略
/**
* ITimerServiceの実装.
*/
private ITimerService.Stub timerServiceIf_ = new ITimerService.Stub(){
/**
* {@inheritDoc}
*/
@Override
public void registerRepeatTask(long delay, long period, ITimerAlarmServiceCallback callback)
throws RemoteException {
final ITimerServiceCallback targerCallback = callback;
TimerService.this.timer_ = new Timer(true);
TimerTask timerTask = new TimerTask() {
public void run()
{
try
{
Toast toast = Toast.makeText(getApplicationContext(), "Count Start",
Toast.LENGTH_SHORT);
toast.show();
targerCallback.updateTimerText();
}
catch (RemoteException e)
{
e.printStackTrace();
Toast toast = Toast.makeText(getApplicationContext(), "Count Failed",
Toast.LENGTH_SHORT);
toast.show();
}
}
};
TimerAlarmService.this.timer_.schedule(timerTask,delay,period);
Toast toast = Toast.makeText(getApplicationContext(), "Timer Started",
Toast.LENGTH_SHORT);
toast.show();
}
・・・略
}
Androidでテストアプリを作成中。
。。。なんですが、今悩んでいるのはServiceクラスから
下記の条件を持つCallbackを呼び出す際、Callbackを呼び出す側で
呼び出すキーを指定可能にすべきか否か、という点。
Callbackからキーを指定可能として作るか、
はたまたCallbackは単に叩かれるだけで、
以後の制御などはCallbackから呼び出されるタイミングに
よってキーを切り替えるか、という方式検討。
１．定期的に実行される。
２．種別としては同じだが、設定するオプションによって動作が異なる。
結局、イベントの制御を「Service」でやるか、「Activity」でやるか、
の違いなんでしょうけど。
つまりはこういうこと。
１．Callback側で呼び出すキーを指定可能にする
「Service」側で呼び出す際に、引数としてキーが指定する必要が出てくる。
かつ、呼び出すタイミングもService側で制御が必要となる。
→ Service側がドライブして動作を制御することとなる。
２．CallbackはActivityの通知メソッドを叩くだけにする。
Service側には毎秒カウントを行えるよう整備してもらうだけ。
→ Serviceは一定時間ごとタスクを起動するのみ。
制御的な面はActivityが全て統括して行うこととなる。
。。。②の方がいいのかな？
とりあえず、実際にコード書いてみて確認するしかないなぁ。