2009-10-08
JJUG CCC 2009 fall に行ってきました
スーパー台風が直撃し、山手線をはじめ主要交通機関が全面的にストップするなか、CCC は午前中 30 分遅れになったものの、基本的につつがなく進行。すごいよ。
頓知・の井口さんの基調講演に何とか滑り込み、セカイカメラの野望を聞きながら、会場にペタっとエアタグを貼ったりしていました。 :-p
午後のセッション最初の、日経BP社 / 日経コンピュータの中田敦さんのお話が個人的にはとても楽しかったので、少し詳しめにメモを残しておきます。
# 聞き間違いや勘違いがあるかもしれないので、ご容赦ください。
データセンター視点で比較したクラウドの内側
- 中田さん
- 問題意識
- サーバ生産台数
- Google の先進性
- 電力利用効率
- 影響を受けているのはマイクロソフト
- ATOM とか ARM とか
- The Data Center as a Computer
- 作者: Luiz Andre Barroso,Urs Holzle
- 出版社/メーカー: Morgan and Claypool Publishers
- 発売日: 2009/08/15
- メディア: ペーパーバック
- クリック: 17回
- この商品を含むブログ (2件) を見る
- チラーレス
- 逆に、冷やす必要はない!?
- サーバの管理
- 自前主義
- Google にとっての障害 (上から順に重い)
- 喪失、データが再生成できない
- 未到達、サービスがダウン
- 劣化、サービスは使えているが劣化している状態
- 隠蔽、S/W H/W で問題をカバーできてる状態
From SQL way to Bigtable way by ひがやすをさん
クラウドにおけるスケールアウト設計を掘り下げる by 萩原正義さん
クラウドアプリケーションのつくり方
- edge2.cc の浅海智晴さん
- モデル駆動開発×クラウドコンピューティングの実証プロジェクト
- GAEJ
- GAEJ で開発してみた経験から
- SimpleModeler の話
- TwitterRecommender の話
最後はライブコーディングを少し覗きつつ、引きあげてきましたー。slim3 や wicket のライブコーディングが見れたのは面白かったです。
スタッフの皆様、講演者の皆様、おつかれさまでした。
Permalink | コメント(0) | トラックバック(0) | 21:09 
グレードアップ No.387 GP.387大径ワンウェイホ...購入: 3人 クリック: 9回
DBPro Standard V4.52009-08-25
9arrows を (MySQLで) 試してみました
本家から 9arrows の最新版を落とし、対応するバージョンの Rails も入れておきます。データベースには PostgreSQL を使用するみたいですが、今回は MySQL で強引に動かしてみます。
% svn co http://9arrows.googlecode.com/svn/trunk/ 9arrows
% gem install rails -v 2.1.0
早速、database.yml を書き替えて、rake コマンドをたたきます。あ、その前に MySQL にデータベースも用意しないといけないですね。
development: adapter: mysql database: 9arrows_development username: root password: host: 127.0.0.1 (snip)
% mysql -u root -p mysql> create database 9arrows_development; mysql> create database 9arrows_production; mysql> create database 9arrows_test; mysql> exit; % cd 9arrows % rake db:schema:load
rake コマンドの結果を見るに、テーブルの作成はうまくいってますが、初期データの登録で失敗しているっぽいです。そこで、schema.rb の中で execute で呼ばれている中身を手動インサートすることにします。ちなみに、datetime のフォーマットが PostgreSQL と微妙に違うのか、そのままだとインサートできなかったで、ちょこっとだけ手を加えてました。
-INSERT INTO mst_messages VALUES (2, 'project_name', 1, 'プロジェクト名', 'プロジェクト名', 'プロジェクト名', 'プロジェクト名', 1, NULL, '2007-07-08 19:32:00+09', NULL, '2007-07-08 19:39:20.984+09'); +INSERT INTO mst_messages VALUES (2, 'project_name', 1, 'プロジェクト名', 'プロジェクト名', 'プロジェクト名', 'プロジェクト名', 1, NULL, '2007-07-08 19:32:00', NULL, '2007-07-08 19:39:20.984');
作成したデータベースに流し込みます。
% rake db:schema:load > insert.sql (上述のようにちょっといじって...) % mysql -u root -p mysql> use 9arrows_developemt; mysql> charset utf8; mysql> source insert.sql; mysql> exit;
"ERROR 1366 (HY000): Incorrect string value" あたりのエラーがでて、うまく行かなにようなら文字コードの確認を。
mysql> show variables like 'character%'; +--------------------------+-------------------- | Variable_name | Value +--------------------------+-------------------- | character_set_client | utf8 | character_set_connection | utf8 | character_set_database | utf8 | character_set_filesystem | binary | character_set_results | utf8 | character_set_server | utf8 | character_set_system | utf8
さて、このままだと auto increment な id が増えていないと思うので、sequence の current 値を変更しようと setval あたりを呼びたいなぁと思ったのですが、そんな関数はないと怒られます。
mysql> SELECT setval('mst_messages_id_seq', max(id)) FROM mst_messages;
ERROR 1305 (42000): FUNCTION 9arrows_development.setval does not exist
あれれっ？と思い、ひとしきり調べてみましたが、どうやら MySQL では扱えないようです。どうしようかなぁ..と思うものの、show table status で確認してみると、ちゃんと auto increment されているではないですか!？
MySQL では、あえて弄らんでもよかったらしいです。 (^^;
mysql> show table status; +-------------------+------+----------------+-------------+----------------+ | Name | Rows | Avg_row_length | Data_length | Auto_increment | +-------------------+------+----------------+-------------+----------------+ | dat_calls | 0 | 0 | 16384 | 1 | | dat_callusers | 0 | 0 | 16384 | 1 | | dat_eventfiles | 0 | 0 | 16384 | 1 | | dat_events | 0 | 0 | 16384 | 1 | | dat_eventusers | 0 | 0 | 16384 | 1 | | dat_milestones | 0 | 0 | 16384 | 1 | | dat_mylogcmts | 0 | 0 | 16384 | 1 | | dat_mylogs | 0 | 0 | 16384 | 1 | | dat_projectcomps | 0 | 0 | 16384 | 1 | | dat_projectlogs | 0 | 0 | 16384 | 1 | | dat_projects | 0 | 0 | 16384 | 1 | | dat_projectusers | 0 | 0 | 16384 | 1 | | dat_taskcmts | 0 | 0 | 16384 | 1 | | dat_taskfiles | 0 | 0 | 16384 | 1 | | dat_taskhistories | 0 | 0 | 16384 | 1 | | dat_tasks | 0 | 0 | 16384 | 1 | | dat_taskusers | 0 | 0 | 16384 | 1 | | mst_compositions | 29 | 564 | 16384 | 30 | | mst_messages | 175 | 374 | 65536 | 198 | | mst_templates | 2 | 8192 | 16384 | 3 | | mst_tpevents | 3 | 5461 | 16384 | 4 | | mst_tpmilestones | 4 | 4096 | 16384 | 5 | | mst_tptasks | 22 | 744 | 16384 | 23 | | mst_users | 1 | 16384 | 16384 | 2 | +-------------------+------+----------------+-------------+----------------+ 24 rows in set (0.02 sec)
ということで、問題ないようなので気を取り直して起動してみます。
# 必要があれば、test、production 環境も同様に設定を。今回は development だけで進めます。
% ruby script/server => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails 2.1.0 application starting on http://0.0.0.0:3000 ... DEPRECATION WARNING: config.action_view.cache_template_extensions option has been deprecated and has no affect. Please remove it from your config files. See http://www.rubyonrails.org/deprecation for details. (called from send at c:/ruby/ruby-186-25/lib/ruby/gems/1.8/gems/rails-2.1.0/lib/initialize r.rb:455)
なんてログが出てきますが、とりあえず無事起動したようです。
http://localhost:3000/ にアクセスすると、ログインID/パスワードを指定してログインするか、新規ユーザーを登録することになります。新規にユーザーを登録するにはメールサーバの設定とかもしておかないといけなさそうなので、ひとまず初期設定されているログインID で逃げます。
# mst_users テーブルの login_id を見て、パスワードは勘で。
ninearrows/ninearrows
ログインするとプロジェクト作成画面になります。まぁ、プロジェクト管理アプリでプロジェクトがなかったら意味がないのでそりゃそうかって感じです。プロジェクトのテンプレートは「システム開発系」と「WEB製作系」の2つから選べます。前者を選んでおきます。
プロジェクトを作成すると、Todo、Event、Information、Member で 4分割された画面が開きます。これが DashBoard のようですね。同列のメニューには、WBS、Gantt、Calendar、File が並びます。それらの上でプロジェクトがタブ形式で複数並べられるようになっているので、マルチプロジェクト管理ができるんでしょう。(完全に見た目だけから機能を追っています)
DashBoard の画面は参照オンリー。
WBS 画面には先ほど選択したテンプレートで WBS がすでに描かれています。項目は、タスク、担当者、期限、状況、依頼者。ドラッグ & ドロップで列の並びは入れ替えられます。タスクの項目には、マイルストーンとイベント、そしてただのタスクが追加できます。また親タスクをクリックすることで子タスクがトグルできます。
Gantt の画面は、WBS の画面と同じ縦軸で横軸が時間になります。Gantt からでも WBS からでも同様に担当者や期限の編集はできそう。逆に両方を並べて見たいとなるとつらいのかな。
Calendar はそのまんま。タスクやマイルストーンの追加はここからでもできます。ただし、Google Calendar ほどの操作性はないみたい。
Files の画面では、ファイルを管理できます。フォルダ構造もとれるのはいいが、SCM と連携しているわけではないです。ちなみにフォルダはつくれましたが、なぜかアップロードはうまくいきませんでした。アップロードしたファイルは 9arrows_home/public/files にはいるはず。素直に SCM と連携してリポジトリブラウザみたいな画面にしちゃえばよかったのにと思うのですが..。
ざっとこんなところだと思うので、最後に ERD も眺めてみます。
- 9arrows's ERD
テーブル数はそれほど多くないですね。ひとまず今日はここまで。
# 9arrows は GPLv3 なんだよなぁ... (^^;
参考
- ベーシスト兼ソフトウェアエンジニアのブログ 9arrowsを使ってみる。。。あれ？うむむ。
- 改善したらよいポイントの提示
- 9arrowsをさっそく改造 | nautilus note the Room
- コメントもよい
- 9ArrowsをMySQLで入れるのと便利な改造 | nautilus note the Room
- 記事内容が消えているので Google キャッシュから
- タスク共有やプロジェクト管理が可能でガントチャート表示もできる国産オープンソースツール「9Arrows」を使ってみた - GIGAZINE
- screenshot が充実
Permalink | コメント(0) | トラックバック(0) | 23:46
2009-07-22
実践的オブジェクト指向分析・設計と実装
ラーニング・ツリー・インターナショナルの講座を受けています。
カンサス州立大学のコンピュータサイエンス学科の教授、水野 匡章先生が講師をされている講座です。
別件ではありますが、先生の講演資料として下記のものが Web で参照できます。米国での仕事経験に基づいたものですが、こちらも興味深い内容でした。
- ヒューマンキャピタル 2008
先生のお話のなかでもよく登場するのが、「Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている」の記事。あまりに納得のいく内容なので全文引用したいくらいですが、少しだけ... (それでも多いですが)。
先生も同じ想いを持っていて、強くアーキテクトの必要性を説いています。上の資料もその流れですね。
自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。
実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。
世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。
(中略)
「自分でプログラムを書かない上流のエンジニアが詳細設計書を作り、下流のエンジニアがコーディングをする」という工程そのものが、根本的に間違っているとしか思えないのだ。
シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。
さて、講座のタイトルは、実践的オブジェクト指向分析・設計と実装というものですが、一連のプロセスを座学的に学ぶのではなく、かなり実装イメージが膨らむところまで分析/設計し、そして実装まで落とすのが特徴的だと思います。(この手の講座を受けたことはないので、これまでに読んできた書籍からの印象ですが。)
で、そのために講義開始の 1時間後くらいには、メモリ上のスタック、ヒープ領域の話になり、スタックフレームやオブジェクトの参照状況などの「基本」をたたきこまれます。ひさしぶりに Visual Studio の画面を見ましたが、ヒープメモリの中身や、スタックフレームが詰まれている状態がデバッグトレースでかなり見やすく可視化されるのはすごいですね。それにしても、この講座のタイトルでヒープやスタックの話が最初に登場するとは思わなかったです..。
クラス図での関連も、オブジェクトレベルでの参照を強く意識しながら描くように教えられるので、クラス図上での何気ない一本の線が実装上かなり大きな意味をもつことが理解しやすいです。間違った線 (関連) のせいで実装が複雑になり、メンテナンス性にも乏しく、パフォーマンスもよくないものになるのはままあることだと思います。
間違った線はよく設計されていないため (場合によってはいきなり実装から入ってしまったがため) に起きることが多く、UML レベルでは線一本の付け替えで済むものが、実装に入ってしまっているとなかなか付け替えに等価な変更はできません。だからこそ、オブジェクトレベルまで意識しつつ、しっかり分析/設計をし、多重度を含めたクラス間の関連を最初にしっかり決めるのが大事という話です。多重度を意識しないと、オブジェクト同士が m 対 n で関連をもつなんていう悲惨な事態が生まれやすいんでしょうね。
演習が多いのも特徴で、初日は自動販売機を分析/設計し、実装に落としました。バウンダリー (コイン投入口や選択ボタン、購入可能ランプや売り切れランプ、釣り銭切れランプなど) まで含めると 10 以上のクラスが登場してくるのでさすがにいきなりの実装は大変です。ちょっとずつ実装しながらってのもありでしょうが、やはり問題にぶちあたったときの設計の変更コストは大きく、下手をするとデバッグ地獄にはまってきそうな気配もあります。
演習を通じ、オブジェクトレベルを意識してクラス図を描き、クラス間 (オブジェクト間) の関連と、ファンクション名だけしっかり設計すると、たしかに手戻り少なく実装に落とし込めるように感じました。ファンクションの中身の詳細までは分析/設計の対象ではなく、あくまでオブジェクト間がどんなシーケンスでつながっていくかを把握するのに注力します。そして、それができたあとでファンクションの中身を含めて、機械的に実装に落とし込んでいきます。
もちろん、実装に落とし込みながら、再度設計を見直すことはあるでしょうし、一緒に開発するメンバーの経験や知識の度合いによっても、どこまで詳細に分析/設計するかは変わるでしょう。バランスは都度調整する必要がありますが、設計をあらわす共有ドキュメントが必要なのであれば (プロダクトレベルで不要なことはないと思いますが)、それを無駄にせず、手戻りを少なくできる武器にするのがいいというのは納得です。やはり関連構造の見直しはコードだけからだと大変ですし、可視化されていると見直しがしやすい上に、全体構造を踏まえてよい設計になっているのが "分かる" という安心感もあると思いました。
端的な表現にしてしまうと以下に尽きるのすが、手を動かす & 失敗経験がともなわないといまいちピンとこないですね。
- 1. オブジェクトレベルで考える
- 2. ユースケース実現の詳細度をあげる
うーん、なかなか言葉だけで表現するのは難しい..。だから数多あるこの手の書籍も苦しんでいるのでしょうか?
個人的にはかなりヒットな内容なので、そのよさをうまく伝えられるようがんばってはみたのですが... (講座の一部でいいんで youtube とかに流してほしいですね.. 広告費ゼロの宣伝なんだけどなぁ)
まだまだメモしたことはいろいろあるのですが、ひとまず明日もあるのでこのあたりで。 (^^;
Permalink | コメント(0) | トラックバック(2) | 02:15
2008-11-11
Google Reader の翻訳機能を試してみました
- Google Readerに自動翻訳機能が加わる–もう何語のサイトでもOKだ
という記事が目にとまったので、そりゃすごいと思って試してみました。
とりあえず、ポール・グレアムのエッセイをひっかけてみました。Google Reader で見ると、エッセイのタイトルがざーっと並び、右上の「フィードの設定」->「設定言語に翻訳」を選択するとみるみるタイトルが翻訳されていきます。
エッセイ本体がフィードされてないのでしまったなぁと思いましたが、とりあえずタイトルをクリックしてみたら、翻訳されて表示されました。これは楽ですね。
以下は、翻訳結果と原文の引用です。
- Why to Start a Startup in a Bad Economy
- 翻訳結果
なぜバート経済のスタートアップを起動する
2008年10月
どうやらこれは、経済情勢は、一部の専門家は、 1970年代半ば70として悪いとしてストレッチをされることがあります恐怖厳しいです。
マイクロソフト社とアップル社が設立された。
することをお勧めても、これらの例は、不況のスタートアップを開始するような悪い時間できない場合があります。それは特に良い時間のいずれかの主張ではない。真実をより退屈です：経済の状態のいずれかの方法が問題ではない。
資金調達から多くのスタートアップすれば、一つのことを学んだので、それが成功または失敗の創設者の資質に基づいている。経済が 、 いくつかの効果は、確かに成功しているのは、創業者に比べて誤差丸めのを予測した。
- 原文
Why to Start a Startup in a Bad Economy
October 2008
The economic situation is apparently so grim that some experts fear we may be in for a stretch as bad as the mid seventies.
When Microsoft and Apple were founded.
As those examples suggest, a recession may not be such a bad time to start a startup. I'm not claiming it's a particularly good time either. The truth is more boring: the state of the economy doesn't matter much either way.
If we've learned one thing from funding so many startups, it's that they succeed or fail based on the qualities of the founders. The economy has some effect, certainly, but as a predictor of success it's rounding error compared to the founders.
まーだちょっとこのまま使えるといった感じではないですね... (^^;
センテンスごとにマウスオーバーすると原文が表示されるので、照らしあわせながらは見れます。あと、よりよい翻訳結果を送信することもできるので、皆が使えばだんだんと精度もよくなっていくのかもしれません。うーん。
ちなみにコードはどうなるのかなぁと思って、そちらも試してみました。
- 翻訳結果
クラス HomeController < ApplicationController before_filter ： set_site デフ 指数 終わり プライベート デフ set_site @サイト = サイト 。 find_by_subdomain （ request.subdomains.first ） サイト @場合 。レイアウトですか？ 自己 。 class.layout （ @サイト 。 layout_name ） その他の 自己 。 class.layout （ ' default_lay ' ） 終わり 終わり 終わり
- 原文
class HomeController < ApplicationController before_filter :set_site def index end private def set_site @site = Site.find_by_subdomain(request.subdomains.first) if @site.layout? self.class.layout(@site.layout_name) else self.class.layout('default_lay') end end end
これはさすがに偲びない... orz
Permalink | コメント(0) | トラックバック(0) | 20:59
2008-11-07
RubyConf2008 2日目
今日は最後に Dave Thomas からの Keynote がありますが、午前中にはとくに全体会はないので昨日よりは遅い立ちあがりです。ひとまず、日本の仕事もしつつ、いろいろチェック。
そういえば、昨日 irc でレオさんの言ってた「日本の Rubyist と仲良くなろうの会」の企画はどうなったんだろう?
今日もまたフロリダらしい日射しのなか朝御飯。直射日光にさらされてると、この時期なのにけっこう日焼けしそうです...。
昨日の分散の話が、分散処理方式の種類みたいなものに焦点をあってるとするなら、今日のは分散環境化での協調動作の一般論みたいなとこですね。
cron で実行するような繰り返しタスクをどのマシンにおくか... Single Point of Failure (SPoF) になってしまうのは嫌ですね。そこで、複数マシンで信頼性を高めることを目指します。
よくやるのは複数 mongrel プロセスですが、問題があります。
- asynchrony (プロセス間の同期をどうするか)
- locality (局所性)
- failure (異常系)
- byzantine (セキュリティのこと?)
どうやって相手の存在を知ったらよいのか? Truely anonymous には対応できないが、プロセスの数などがあらかじめわかっていれば解決できそう。というわけで、グループが把握できたとします。
次の問題は「同意」。どうやってリーダーを選ぶのか。乱数を利用したりして、リーダーを選ぶ。「同意」には時間がかかるので、パフォーマンスと信頼性のトレードオフ。
でも予期しにくく、テストもできない、そんなひどい状況があります。そのときどうするのか? 完全に信頼できるコードとまずいコードの間の現実的な解。よく使うのは memcached?
SPoF をつくらずに、これらを解決できる自作ライブラリをつくってみましたってことらしい。
いくつかのリアルな問題の解決策を実演。
- TokenWorker
リーダーの選び方。memcached::add API を使って、最初にはいってきたプロセスがリーダー。
デモはよく見えず... (文字の色とサイズが微妙すぎる)
- StaticQueueWorker
リーダーがキューをもち、他のワーカーに振り分ける。たぶんリーダーが落ちたら、残りから選ぶっぽい。
# やっぱりデモ見えない...
ここで、Paxos ("poxos made live" でぐぐれ) の話。
Paxos algorithm - Wikipedia, the free encyclopedia
分散アルゴリズムのひとつで、Google がたくさんの人と金をかけて実装しようとしてきたとか?
2フェーズコミットに似たようなものか...。異常系のリカバリが大変。
politics でも paxos の実装を試みたが、あきらめた。将来もっかい試してみたいそう。
毎年の名物になりつつあるタルボット。初回の RubyConf 以来 8回目だと思います。Ruby の話しないのに会場はきっちり埋まってました(笑)。
全員たたせて、RubyConf参加回数の少ない順に座らせていって...最後に残ったのは、ポールブレナン。高橋さんは残念ながら隣の部屋でした。
で、とうとうと話はじめます。今年はスライドもないみたい... orz
レオさん++。 <(_ _)>
ソフトウェアは art であり、人の営みだからこそ、感情と向きあわねばならない。
恐怖という感情について考えてみよう。
「なにもない」という怖さ
既存のコードの怖さ
美しいコードをこわしてしまう怖さ
はずかしいものをつくってしまう怖さ
時間がかかりすぎてプロジェクトを完成できない怖さ
はじまることの怖さ、完成することの怖さ
...
「怖さ」をインタビューして部屋中をかけまわるタルボット。このあたりの一体感のつくりかたはほんとうまいなと思う。
怖さはワーニングシステムであり、判断材料にはならない。してはいけない。そこだけは注意しよう。
冷静に判断して、決めなければいけない。
怖さを解消するには学習とテスト。
未知のものへの恐怖は本性だが、自覚があるのとないのでは違う。
テストで問題を分割してけば小さくできれば怖くなくなる。
プロトタイプをつくってみるのがいい。最初から捨てるつもり。
最悪の場合を想定しよう。
"The War of Art" って本がお薦めらしい。"The Fear of Art" も。
なにかを創造するときのヒントが書かれている。ここで再び会場にヒントを求めてタルボットが部屋中をかけまわりました。
これもおすすめ。
怖さを乗り越えるもっといい方法は、愛、情熱。
好きなことをやっていれば、怖さがあってもだいじょうぶ。そもそも情熱がなければ、怖さに耐える理由もない。
# irc から抜粋。
01:13 shyouhei_: 毎年思うんだけどRubyistは最低でも一生に一度以上はRubyConfを経験しておくべき。
01:14 kakutani: RubyKaigiに呼んでもこうはいかないだろうなあ、と思う。タルボっちゃんの話は。
01:14 takahashim: まあ、そうかも＞talbott
01:16 takahashim: RubyConfは人生を変えるよなあ
なんかふつうに関数型プログラミングの紹介でおわってしまいました。
関数型プログラミングのポイントは状態を持たないこと、関数が一級市民。状態が不変であれば、同期の必要なく並列化できる。でも、一般的に関数型プログラミングの欠点はオブジェクトをたくさん作りすぎること。
Ruby における不変性は? attr_reader なら read only、副作用のない関数の紹介。Ruby における一級市民の関数は、メソッドではなくブロック。メソッドは微妙に違います。
関数型プログラミングでありがちなのが再帰ということで、ここでフィボナッチ数列の例。ほか重要な関数として、map, filter, fold/reduce などを紹介。(Ruby だと、map、select、inject?)
あとは、関数型プログライングは宣言的という話から、ActiveRecord の DSL もまさに宣言的だよね、とか...だんだん雲行きがあやしい。
そして突然、Actor model of concurrency
関数型プログラミングのパターンマッチングは OO のポリモーフィズムと似ているとか...
で、最後にまとめです。
不変がいい、副作用のない関数がいい、...
- what functions go inside a type vs outside
- watch for overhead for copies and recursion
- mix pattern matching and polymorphism
うーん。
- ランチタイム。
メニューは昨日とほぼ同じですね。
それにしても暑い。となりのホールで日焼けマシンの展示会の準備が行われているのもうなずけます。
Jim Weirich のお話です。
これまではムーアの法則の恩恵を受けることができたが、今後クロックスピードが頭打ちに。今年はこの前フリではじまるセッション多いですね。
従来のパフォーマンスは、クロックスピード、最適化、キャッシュがポイントでしたが、今や Mac のハイエンドマシンもたったの 3.2 GHz... (8GHz のマシンを誰かもってないのか?って聞いてましたww)
で、これからのパフォーマンスは、HyperThreding、マルチコア、キャッシュがポイントとのこと。
(参考)
- Herb Sutter
- Charles Miller
- Java Concurrency in Practice
でも、マルチスレッドは扱いがむずかしい、Rails がスレッドセーフになるのはうれしいけど、マルチスレッドアプリをつくりたいとは思わない、というわでお馴染みの銀行口座の例を粛々とデモしました。
まずは、10スレッドで、口座に $1ずつ入金するのを 100,000回繰り返し。当然結果がまちまち。race condition。スレッドによる値のコピーと ++ をアトミックにする必要があるということで mutex。mutex を使ってクリティカルセクションを守れば成功。
次は、口座A からは debit して、口座B に credit する例。口座が負にならない条件をどこにつけるかがポイントです。ループごと mutex にいれてしまうとクリティカルセクションがでかすぎるので、while の条件を mutex のなかで再度確認するようにします。
こういうマルチスレッドなプログラムをテストするのは大変です。とっても大変です。
次の例は、5つの口座で順番にお金を transfer していきます。5つのスレッドで実行すると...見事にデッドロック。解決するために、スレッドに優先度をつけてみるとかですかね。
- 1) protect every shared memory access with a synchronizing lock
- 2) beware of extended situations that need to be atomic
- 3) have a strategy in place to avoid a deadlock in the presence of multiple locks
- 4) evaluate every single library used by your program to see if they also follow rules 1-3
というわけで、使ってるライブラリをちゃんと確認しないといけないということです。大変です。 orz
ここでどう展開するのかなぁと思っていたら、並列プログラミングではデータの共有が問題の元凶ということで、Ruby 以外の言語を紹介。Paul Graham の Blub 言語の話とかも。
no variables, no assignment, no explicit loops
constants only, pattern matching, recusrsion (tail recursion)
- Clojure
Lisp っぽい構文の説明。基本的に状態を変更できないが例外はあるそうです。
Vars - thread local variables (impossible to share)
Refs - STM (shareable, but only in a transaction)
そして、来年本がでるそうです。
The Pragmatic Bookshelf | Programming Clojure
最後に、並列プログラミングは難しいので、従来の手続き型言語だとつらい。Ruby でマルチスレッドプログラミングするのは大変。関数型言語がよいよ、とまとめていました。 (^^;
資料はここらしいです。
優秀なひとが集っても、いいコードになるとはかぎらない..
ひどいコードをどう減らすか? ペアプロ、メンテナを意識、レビュー、...でもやっぱりダメなコードになることもあります。
great code + time = trouble (いいコードも時間をかけるとおかしくなります)
というわけで、メトリクスを活用しましょう。
とはいっても、カバレッジも100%あればいいというわけではないです。(30%はひどいけど)テストもあればいいというものではない。C1、C2のカバレッジがあるなら cool かもね (rcov は C0)
- zenspider のFlog の話。
Flog のスコアは 10 を中心に正規分布するよう計算されうようです? (0-10, 10-20 あたりをよいと言ってたけど、よくわからないです...)
- Saikuro の話。
cyclomatic complexity を計測します。これで、複雑なメソッドを把握して、リファクタリング。
例にあげていたのは、damerau levenshtein distance example。googleの「もしかして」機能っぽい。
複雑なメソッドをリファクタリングすることで、理解しやすいコードになるとともに、潜在的なバグもみつけられます。過去の精神状態もわかりますww
でも、やりすぎはよくないです。単純に Flog のポイントをさげるために inject とか使うとわからなくなりがちです。複雑なコードを残すときには、ちゃんと説明も残しておきましょう。
- Source Control Churn。
ファイルの修正回数で降順にソートすることで、変更回数の多い(問題のありそうな)ファイルがわかります。とか言ってました。
メトリクスの注意点。数字はうそをつくこともあります。なので、意味のわからないひとにはみせないように。まとめ。メトリクスで対応の優先順位がつけられ、バグや隠れた複雑性を発見できます。
- Metric Fu
rcov, flog, saikuro, code churn, rails statsを包含してます
Fibonacci Software Development。
最初 hustle して、次に refactor して、そのあと Optimizetion、..ということで、だんだん時間軸が長くなり最適化とか大事になってくるよね、という話。
結論としては、以下でしょうか。
スループットを最大化するのに、CPU を激しく食ってるとこを別メソッドに切りだして、メッセージングキュー経由で非同期化するなんてことをしてました。最近は Starling があちこちででてきますね...うぅ。
RubyForge: Starling: Project Info
Starling is a light-weight persistent queue server that speaks the MemCache protocol. It was built to drive Twitter's backend, and is in production across Twitter's cluster.
About This Blog: Beanstalk Messaging Queue | Ruby on Rails for Newbies
Fast, simple, designed to mirror the style of memcached. Rails plugin available, or usable with a simple Ruby-based API. Server written in C, but is very easy to install.
http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue
そんなこんなで、
job queue + 50EC2 instances 使ったら、50,000,000GETs/day トランザクションさばけたよ、とか事例の話も少ししてました。
- Defer Blocking IO
- EM-HTTP-Request (EventMachine でリクエストを非同期化)
- Curl::Multi
Ruby は遅いので、最適化重要。
- GC
- その他の最適化
- バイトコード最適化
- JITコンパイル
- インラインキャッシュの話
- フィードバックベースの最適化
orz..
なんだかネタ的なセッション。
格闘技とコーディングの共通点から、Code Kata を Dave Thomas や Uncle Bob が提唱。
CodeKata
演舞のヒデオ...ながっ。演舞すればフィードバック得られる。
というわけで、これからやってみせるから採点してね、ということで黙々と発表者がコーディング開始www
ぼくらはそれをじっと眺めてます。 (^^;
(よくは見えませんでしたが、IntelliJ IDEA 使ってましたね)
ひまだったので、ぐぐってみたら、こんなものが↓。同じひとですね。
effective software development
At the recent Ágiles2008 conference in Buenos Aires, Micah Martin gave a demo of test-driven development with ruby. You always need some sort of application to write in presentations like this, and it's not always easy to find one that's simple enough to serve the purpose of a demo and yet interesting enough to hold people's attention. Micah based the demo on Langston's Ant, which I think meets both those criteria.
http://dnicolet1.tripod.com/agile/index.blog?start=1225810027
もひとつ、スパーリングについて。
Java の ロボコード みたいな感じで、潜水艦ゲームの戦術を競いあわせましょうって話。で、互いに学びあいましょうってことか。
夕飯。Dave Thomasu の Keynote まで時間が多少あるので、みなでホテルの外のレストランへ。はじめて歩いてホテルの外に出ました。しかし、お店が遠いです...。
結局、時間もないのでマックやスーパーで夕飯をテイクアウトして帰途につきました。
戻ってきたら、恒例の書籍の抽選会。
...
Permalink | コメント(0) | トラックバック(1) | 06:30
