kagamihogeの日記

kagamihogeの日記です。

Developers Summit 2009 - 1 日目

つなぐ、つながる、そして未来へ Developers Summit 2009 の 1 日目。


開催挨拶。

今回のデブサミのスローガンは、つなぐ・つながる・そして未来へ。

今日、ここで聞いたことを誰かに話したり、blog に書いたりして、誰かに伝えてほしい。誰かと繋がることをしてほしい。人と人とのつながりを大事にしてほしい、というメッセージを発していた。

技術のつながり。各要素技術には何かしらのつながりがある。Web もあってテストもあってマネージメントもあり…… デブサミでは多種多様な技術のセッションがあるので、普段あまり目にしないセッションを見にいっているのもいい刺激になるのでは、と。

そして未来へ。時間と意思と世代のつながり。今日、開催挨拶をされた方は代理でここに立っているとのこと。代理として立つ際、託されたのは、若い世代にバトンを渡す、ということを意識してほしい、と言われたのだとか。たとえば、クラウドが代表的なんだけど技術というのは流行り廃りみたいなライフサイクルがある。だから、そういう分野で最先端を言ってる人の話を聞くことで得られるものはあるんじゃなかろうか、とかそういう話をしていた。

クラウドによるソフトウェア開発パラダイムの進化

クラウドの最新技術の動向について。ビジネス的な問題でなく技術的な話題を取り扱う……とのことで、セッションの内容に激しくついていくことが出来ませんでした。クラウドの考え方でソフトウェア作るならクラウドなりの考え方で組まないとダメですよーって言ってるのはわかったんだけど、個々の要素技術の議論になるとやっぱキツかったです。ので、このセッションについてのレポートはかなーり断片的になってます。

ソフトウェア開発パラダイムの変遷の話。構造化、オブジェクト指向コンポーネント指向、サービス指向、Web 指向へ。抽象化の発展の歴史。パラダイムの進化の歴史ってのは、従来の技術の積み重ねで発展してきている。

ただし、一度始めてしまったソフトウェア開発において、大きなレベルでのパラダイムの途中変更は困難。たとえばスケールアップとスケールアウト、データモデル(RDB,OODB,XMLなど)の変更、同期vs非同期、などなど。

で、どうするかというと。クラウドを念頭に置く場合は、マルチパラダイムを意識したアーキテクチャ選定を行う。パラダイムの選択はドメイン単位で行う。ここでいうドメインは、ワークフローとかサービスとかそういうレベルの単位。それぞれのドメインにおいてパラダイムを適応する。ただし、時代によって最適なパラダイムは常に変化するので、中々適切なパラダイムを選ぶのは難しいところがある。

SOA の問題はどこにあるのか? 再利用性の限界。再利用できてもスケーラブルではない。ただ、それでも、サービスという機能分割単位は有効。あと、最近 SOAP はイントラ利用が中心になってきて、Web 全体では REST な方向に流れつつあるらしい。

N-tier モデルの問題は? クラウドではこの N-tier の考え方は時代遅れなんだとか。なんでかっていうと、ACID トランザクションのスケーラビリティが確保するのが難しい(ロックスコープや分散トランザクションの文脈での話。2フェーズコミットが現実的でない、とかなんとか)、RPC の脆弱性(同期ロックなんて持っての他だから)。まぁぶっちゃけ RDB とのやり取りんとこがボトルネックになっちゃうから、Web サーバやビジネスロジックはスケールアウトできてもアンマリ意味が無い。

……って、段々このあたりから俺自身が理解できてないまま文章書いてるんで、変なこと書いてる可能性が高いので注意してください。

んでどうするか。Azure(あずーる、と読むらしい) クラウド OS の考え方。サービスのリクエストをルーティングする。故障検知は、p2pの考え方、お隣同士が見張りっこをしている。

クラウドにおけるパラダイム。レスポンシビリティや即時一貫性はあんまり求めない。なので銀行のピーキーな処理とかには適さない。やれないことはないけど、クラウドの得意とするスケーラビリティや可溶性が犠牲になる。

スケーラビリティで使われる技術は、データ分割やトランザクション分割。非同期処理。DDR(Data Dependent Routing) 可用性で使われる技術は、DHT(分散ハッシュてーぶる)とか。

クラウド OS の上でどうやってアプリ作っていくの? 流れとしては 2 つ。OO と Functional な考え方。うおーよくわかんねw 以下略。

あと、こういう分野ちゃんと煮詰めたい人は「アーキテクトの審美眼」買ってくださいねーって、宣伝も兼ねて言ってました。

SEC流品質作りこみESQR 組込みソフトウェア開発向け品質作り込みガイドの紹介

ソフトウェアの品質というものを計測し、評価し、改善するためにはどうすればいいのか、という話。お隣でやってた WPF のセッションはゲロ込みなのにこっちの入りはマバラなあたりみんな素直だよなぁ……w ソフトウェアの品質測定とか定量評価うんぬんって地味だし面倒だし鬱陶しいし何かと押し付けがましい側面があるけど、無視して良い代物だとも思えないんでこっちのセッション聞きにいきました。。

品質評価指標とは。有形、無形にかかわらず対象(モノ、作業、サービス)の特質を表現するための科学的な根拠をもったモノサシのこと。誰が計測しても同じように値を計測できるようにすることが重要。測り方・制度・単位。また、計ろうとしているものに意味があるのかどうかの検証も必要。品質というものを評価するには、指標が必要であり、その指標が妥当かどうかの根拠もまた必要。

組込みシステムの品質・信頼性向上のために、ESCR(コーディング作法ガイド)とかの定型化ガイドライン作りはだいぶ出来てきた。が、それらを使用して品質を向上するにはどういう取り組みをしたらいいのか、という部分はまだガイドライン化出来ていないのでは、との問題意識があったという。

そうした背景の下取り組まれているのが ESQR というもの。組込みシステム開発過程で客観的な品質指標を用いて品質要素の作りこみとコントロールを行うために体系的に整備された参照手法。5 つほど特徴をあげて解説していた。詳細については省略。

ESQR の想定利用者。工程管理を担当するマネージャ、それを実際に運用するメンバ、品質保証などを間接的に支える部門の人たち。

ESQR を使用して得られる効果。利用者側から見た品質確保のための作業の見直し、プロジェクトの特性の客観的に捉えて品質目標の設定に反映、目標値を設定して開発をすすめる。品質を満たすための必要十分な作業は何かを見出す。

ESQR を利用する場合に注意点。ESQR で提示した品質指標をぜんぶ利用する必要は無い、参考値はあくまで参考値なので自分たちの身の丈に見合った調整が必要、数値を達成することが目的化しないように注意しなければならない。

時を超えたプログラミングの道への道

おお、あれがうわさの角谷さんか……なんというか、独特のオーラがありますな。

とりあえずプレゼン資料はこちら。デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 - 角谷HTML化計画(2009-02-12)

がしかし、blog 書き泣かせに色々と話が飛ぶ構成でぶっちゃけレポートが非常に書きにくいセッションでした……w 内容はすごいおもしろいものだったんで、なんとか工夫できんもんかと思いましたが諦め。箇条書きのテキトーなメモ構成にしときます。

  • XP とは「社会」の変化のことである。
    • ここでいう「社会」とは、個人の世界認識、人と人との関係、チームや組織のあり方…そういうものから経済や社会につながっていく。
    • 「Head First ソフトウェア開発」はオススメらしい。中身はアジャイル開発のことが書いてあるんだとか。
  • XPは、誠実なプロフェッショナルであるふつうの人たち用。
  • 竹内預言。
  • 「時を超えたプログラミングの道」ってのは XPエクストリーム・プログラミング入門―変化を受け入れる の 23 章の章タイトルのこと。この章を抜粋と解説。
  • 道が持つ意味。road, way, tao
  • ビジネスとテクノロジの調和。別々のものではあるんだけど、切り離せないものでもある。エンジニアリングとアート、コードとドキュメントなども同様に。
    • 二元論でカンタンに片付けていいものではないよね。
  • 時を越えた建設の道
  • XP はアレキザンダーの建設への道に基礎を置いてるけど、角谷さん曰く、色々通読してみたところ、基礎どころか XP そのまんまやん、といった感があるらしい。XPは、アレキザンダーのやろうとしたことをソフトウェアでやろうとしているのではないか、と。
  • パターンランゲージの話。概念や系に対して名前を付ける、って感じかなぁ。砂漠の風紋の引き合いとか。一つの生態系を作るもんだよなぁ、ここまでくると。
    • 逆説的な言い回しだよね。全体ー分化とか。
  • でもアンマリみんなこういうプロセスに食いついてこないけど、パターンランゲージが一過性のものだったのか、道が誤っているのか、違う道にいっているだけなのか。
  • アレクザンダーの建築の道は建築の世界では失敗したことになってるけど、ソフトウェアの世界ではまだどうなのかよくわかっていない。
  • その後のアレクザンダーの仕事。
  • ソフトウェア開発はまだまだ幼年期だよね。

問い続けよう。
開発者として。
滅びを免れていき続けるために。

Sorcial change start with you.(「社会」の変化はあなたから)

並列処理開発を支援するコンパイラの機能

並列化とマルチコア。

なぜ並列化なのか? 並列化は最適化テクニックの一つ。実行速度の向上が目的。
並列化可能な部分とは? 処理の順序に依存性が無いこと。つまり、各処理の実行順序に意味が無い。粒度は機械語レベルからアルゴリズム、解決しようとしている問題まで色々。

並列プログラミングモデル。色々なやり方がある。メジャーなものはクラスターシステム - 分散メモリ MPI 分散メモリモデル。単一システムでは共有メモリ方式、たとえば POSIX スレッドとか。

スレッドモデル。アプリケーションを並列化するための明確でキホン的なスレッドモデル。java とか POSIX スレッドとか Solaris スレッドとか。

自動並列化(-xautopar) コンパイラが並列化(ループ処理が対象)元ソースいじらずにコンパイラオプションで並列化に対応したバイナリを吐いてくれる。

自動ベクトル化(-xvector=simdSIMD 命令を使用するようにコンパイル。

OpenMP とは? C/C++, Fortran で共有メモリ型並列処理を記述するためのデファクト
OpenMP の利点。ちゃんと使えば、優れたパフォーマンスと拡張性が得られる、デファクトなんで、多くのコンパイラがサポートしている、などなど。コンパイルオプションで、逐次版、並列版、と切り替えすることができる。マルチコアアーキテクチャと親和性が高い。

ただし、ループ処理が並列化した場合にどうなるか、ってとこは開発者がちゃんとメンドウみてあげないといけない。たとえば、前の計算結果に依存するような処理を書いていないかどうか、とか。

Sun Studio Express 11/08 のデモ。C/C++/Fortran統合開発環境。並列処理開発の支援。

自律型移動ロボットのソフトウェア技術

人間の関与なしに走る無人自動車のコンペティションについて。

DARPA Grand Challenge(DGC) の Team MIT の取り組みについてのセッション。DARPA は、5-10 年後を見据えた研究開発を行ってる軍の研究機関。その目標の一つに 2015 年までに戦場の車の 1/3 を無人化、というものを掲げている。DGC 1 2004/3, DGC 2 2005/10(ネバダ砂漠でやってた) が開かれている。2007/11 のレースは市街地・交通ありの条件での開催。今回は前回よりずっと難しい。狭い道幅、変動する要素が多い、などなど。

レース開始の 24 時間前に、RNDF という有向グラフのファイルとチェックポイントのリストが渡される。

道に沿って走る、とはどういうことか、とか。(日本でいうところの)右折・合流を 10 秒以内に行えないとペナルティがつくとか、考えなきゃならん問題は様々。

状況判断は知覚ベース。極力 RNDF に頼らない、ということを目指した、とのこと。

コンピューティング構成は、1 ブレードあたり 2 つの 2.33 GHz デアルプロセッサを 10 ブレード。大量のセンサ、GPS やら障害物やら地面との距離を見るのやら何やら色々。また、レーダー、カメラ類も色々。コンセプトは、そこにある情報はとりあえずすべて取る、という方針らしい。なんか、エリア 88 の地上空母の無人機の話思い出すねコレ……

システムダイアグラム。大まかには、物理的なセンサのサブシステム、そっから得た情報から道がどういう状況にあるかを判断するサブシステム、それらの情報から意思決定を行うサブシステム、実際の運転にフィードバックさせるサブシステム。

障害物・縁石の検知。レーダーで、得られた情報から一定以上の高さがあるものを障害物、高さや長さがスムーズになってる部分を縁石として判断する……などなど、様々な工夫についての解説はかなり熱かった(男の子のロマン的にも) アルゴリズム考えるのも大変だけど実装してテストして検証するのもすごい大変だろうなぁこれ。

LCM(Lightweight Communications and Marsharing) ブレード間のプロセス通信に作ったもの。今回のプロジェクトの副産物としていくつか googlecode に公開しているらしい。

サブシステムのテスト。ログを収集する機構を別途用意して、そこで得られたデータを各サブシステムに流し込み、ビューワーで見ることでテスト。

しかしまぁ国土が広大だとスケールもでかいねぇ。元は軍用の実験場を貸してもらったりとか。アメリカは軍主導で大規模に新しい技術の実験してる、って話は聞くけど、こんな感じのプロジェクトが幾つか走ってる感じなんだろうねぇ。

って Team MIT はコレだけやっても 4 位なのか…… 1-3 位はバケモンだなぁw

教訓 コレは興味深かったんで全文引用。

  • 難しいことは覚悟していたが、想像以上だった
  • とにかくテスト
    • シミュレーション、走行実験、ログ再生
    • 部分ごとにテストできる開発環境
    • そのコードの担当者以外の人によるテスト
      • 外からの目
      • 開発者は開発で精一杯
  • ソフトウェアの実装 vs. アルゴリズムの開発
    • どっちに偏ってもだめ
  • 時間との戦い
    • 完璧なシステムには仕上がらない
    • バグ・問題点には優先順位を
  • チームメンバー&チームワーク

オブジェクト指向エクササイズのススメ

「ThoutWorks アンソロジー」っていう本の一節の紹介。

オブジェクト指向エクササイズ。ってもしかしてアレのことかな? OOコード養成ギブス - rants かな? と思ったら元ネタ源が同じだったw オブジェクト指向エクササイズって何ぞ、と思った人はリンク先に書いてあるんで興味があったらどうぞ。

コミュニティから選出のLT大会

LT ってなかなかライブ感伝わんないよねーってとこがあるんで、テキトーにメモ書きしたのをそのまんまのっけてます。

コミュニティLT - 勉強会勉強会

IT 系勉強会の主催者になろう。IT 勉強会カレンダーを見よう。

勉強会勉強会は、勉強会そのものについて、ゆるゆる語るコミュニティ。空前の勉強会ブーム、勉強会のライフサイクル……勉強会の法則、動作原理の解剖。持続可能な勉強会とは何か? 勉強会やコミュニティ活動をもっともっと広めるのもまた理念。

DevLOVE! - DevLOVE

DevLOVE の発足経緯。RubyKaigi の帰り道、開発って楽しい? って即答できる 2 人で結成。

理念は、開発の楽しさを発見し、広げる。明日の現場で役に立つものを持ち帰れる勉強会を。開催してきた勉強会も、現場ベースで考えてイベントを考えている、とのこと。

現場を変えるためには、自分が変わる必要がある。自分たちの現場を変えられるのは自分だけ。でも険しい道だから、DevLOVE がいる。

OpenSolaris流AMP開発環境 ZFS, Zone を使いこなす! - 日本OpenSolarisユーザーグループ

AMP ってのは Apache, MySQL, PHP のこと。L を抜いてるのね。

Solaris コンテナ(Zone) - 仮想環境のようなもの。20 個とか作っても、ZFS のおかげでそんなにディスクスペースはくわない。

勉強会では、カーネルのコード読むとか、OpenSoralis のこと全般とか。月1 で 20 人ぐらいが標準的な規模。

Linuxコンソーシアム

漫才wwwwwwwww

激しくネタセッションw どちらも営業の方なのね。さすが流暢にこなすなぁw

沢マンに学ぶいきいき - オブジェクト倶楽部

くわしくは http://www.Objectclub.jp をどうぞ、らしい。オブジェクト倶楽部の話一秒もなかったw

沢マン(沢田マンション) セルフビルド建築で世界最大級。夫婦 2 人でクレーンやらなんやらからすべて自作しているすげーマンションらしい、の話で終わった。

要求開発2.0って何だ? - 要求開発アライアンス

要求開発ってのは、ビジネス的要求をシステム的要求に落とし込むための方法論。要求は開発するもの、ってのが根幹。

あと、キン肉マンスーパー・フェニックス - Wikipedia

2.0では 1.0 を見たりした人たちからのフィードバックを受けて、知識体系の整理とPMBOK 的なガイドラインの整備をする、とかなんとか。

PFP のご紹介 - プロジェクト・ファシリテーション・プロジェクト(PFP)

プロジェクト・ファシリテーションを推進する会。

プロジェクト・ファシリテーションとは、プロジェクトの成功と、プロジェクトに関わる人のやりがいの両立を目指す、チーム作りの活動のこと。

プロジェクト・ファシリテーションの体系は、価値・原則・実践。

例:バグレゴ。バグが出たらレゴのブロックを積んでいく。見える化、リズム(運用ルール)、名前付け(お手上げバグ)、問題 vs 私たち(バグの共有)、カイゼン(自分たちの仕事を進めやすくなるため)

あと、LT で懇親会来る人ーって募集してたのがユニークでした。

私の出身コミュニティ - 日本Rubyの会

おー「たのしい Ruby」書かれた人かー。

最初はアンマリなんとか勉強会って好きではなかった。なんとなく閉鎖的っぽいところが。ただ、振り返ると Ruby の ML と言う形でコミュニティに参加していた。

その辺を踏まえての、ネットのコミュニティ、リアルのコミュニティの利点・欠点の話でした。

Antenna Project のご紹介 - Antenna Project

さっきの Linux コンソーシアム部会から分化? した会。何するかというと、何かつくるプロジェクト。どっちかっていうとクライアント寄り。車輪の再発明とか気にせず何か作る。で、プラグイン形式で追加できるものならもっといいよね、とかそんな感じ。

データだけでなく設定も集めてしまおう。プラグインの組み合わせとか、DI の設定とか、スタイルシートとか。

わんくま同盟 - わんくま同盟

わんくまは、勉強会とか blog とかやっている。扱っている技術は基本的に色々。最近はなんか Twitter-er が多いらしい。なぜか Microsoft MVP の人が多い。

2008/11には、50人とかいう人数で LT 大会やったのだとか。毎週日本のどっかでやってるという中々頻度高い勉強会ですよね。

grails code reading

Grais って何? 完全 Java 互換の rails のようなもの? Groovy ベースとかなんとか。そのソースコードを読む会。grails code reading から、JGGUG として改組(でいいのかな?)したようです。