【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」

ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。
CC Attribution ライセンスとします。

ETWest2009講演資料「TestLinkでアジャイルにテストする」

View more documents from akipii.

上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。

一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。
テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合～受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。

その問題の本質は、二つある。
一つは、受入テストの自動化は難しいこと。
もう一つは、手動の受入テストの生産性が悪いこと。

TestLinkの導入によって、手動の受入テストを効率化できると確信している。
だが最終的な目標である受入テストの自動化は、TestLinkだけでは足りない。

それを実現するには、テスト環境の仮想化と並行ビルドの技術が鍵を握ると思う。
そのアイデアは下記に書いた。

プロジェクト管理やテスト工程をクラウド化する: プログラマの思索

RedmineやTestLink、Hudsonなどのツールを駆使してソフトウェア開発していくに従って、問題の難易度が上がってきた気がしている。

ソフトウェア開発に銀の弾丸はないけれど、プロセスのレベルが上がるに従って、ソフトウェア開発の本来の問題点に少しずつ近づいてきたような気がしている。

ソフトウェア開発は、製造業や営業とは異なる本質的な特徴とそこから生じる根本問題がやっぱりあるのだ。

Redmine勉強会

IT 勉強会カレンダーに登録されている「Redmine勉強会＠東京」が気になっている。

【元ネタ】
6/12 Redmine勉強会は決行の方向で - yandodの日記

RedmineのCakePHP移植版「candycane」の話もあるらしい。
最近はRedmineのプラグインも充実して、チケットの一括インポートやチケット集計結果のグラフ表示、タスクかんばんなど色んな機能も追加できる。

でも一番知りたいのは、他の人がどのように運用しているのか？という実際の運用例だろう。

トラッカー(チケットの種類)はどれだけ作ってる？
ステータスとそのワークフローはどれだけ作っている？
インシデント管理や要件管理は、どのように運用すればいい？
チケットを放置したり、乱発しないように運用するための解決策は？

疑問はたくさんあるから、皆でノウハウを共有できれば、プロジェクト管理をもっと手軽にIT化できるようになるだろう。
その運用ノウハウに、従来のSW工学の知識を当てはめれば、もっとブラッシュアップできるに違いない。

【告知】TestLinkでアジャイルにテストする

ETWest2009のTEF関西のコミュニティセッションでTestLinkについて話します。
TestLink＋アジャイル開発の運用経験を熱く語る予定です。

【概要】
名　　称 Embedded Technology West 2009／組込み総合技術展　関西
会　　期 2009年6月4日(木)、5日(金)　10:00～17:00
会　　場 インテックス大阪　5号館
大阪市住之江区南港北1-5-102 　TEL: 06-6612-8800

【内容】
2009年6月4日 (木) 12:30～14:30 6号館2F 会議室F
TEF関西勉強会　てふかん in ETW2009

13:40～14:30
TestLinkでアジャイルにテストする

【講演概要】
近年、システム開発のプロジェクトマネジメントが重視されるが、要件定義、設計、プログラミングまでの工程に注力する一方、開発工数の半分以上を占めるテスト工程が軽視される傾向にある。
これに対し、XPを代表とするアジャイル開発手法は単体テスト工程にテスト駆動開発を導入したが、結合テスト工程以降には適用し辛く品質保証が難しい。
本セッションでは、これらの問題に対し、テスト管理ツールTestLinkを効果的に運用した実例を体験談を交えて解説する。

XP祭り関西２００９の講演資料リンク

XP祭り関西２００９の講演資料をリンクしておく。

XP祭り関西２００９詳細 - XpjugWestWiki

他にもありましたらご連絡下さい。

【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発！～チケットに分割して統治せよ」

XP祭り関西2009講演資料「チケットファーストでアジャイル開発！～チケットに分割して統治せよ」を公開します。
CC Attribution ライセンスとします。

チケットファーストでアジャイル開発！～チケットに分割して統治せよ

View more documents from Akipii .

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

プログラマの思索: 【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」

まちゅさんはTracのチケット管理を元に「チケット駆動開発(Ticket Driven Development)」を提唱された。
僕は、Redmineによるプロジェクト運営でプロジェクト管理が劇的に改善した経験を昨年のKOFで話してみた。

KOF講演後、興味を持ってくれた人達からのフィードバックを受けて、更にそのアイデアを用いて、アジャイル開発を補強する方向へ持っていけないか、自分なりに思索してきた。
XP祭り関西2009の講演資料は、KOF講演資料の内容と重複部分は多いですが、チケット駆動開発を定義してみる等ブラッシュアップした内容にしています。

XP祭り関西2009の講演後、初対面の人達からたくさんの質問やフィードバックをもらって刺激を受けました。
更にチケット駆動開発のアイデアを洗練させていきたい。

コメントがあれば嬉しいです。

【補足】
関西でTiDD勉強会を開催しています。
興味がある方はどうぞ。

TiDD勉強会 | Google グループ

【告知】XP祭り関西2009でチケット駆動開発を講演します

『ＸＰ祭り関西 ２００９』 の概要

■開催日時
　2009年１月24日（土曜日）
　10:00～17:00

■開催場所
　兵庫県伊丹市　生涯学習センター「ラスターホール」

　所在地 〒664-0865 兵庫県伊丹市南野2-3-25

　交通　　阪急伊丹駅より 伊丹市バス「稲野町8 丁目」
　　　　　　阪急神戸線塚口駅より 伊丹市バス「ラスタホール前」
　　　　　　阪急稲野駅より 西へ徒歩600 メートル

■内容
　▼ホール（２Ｆ多目的ホール）―先着１２０名

*※ 基調講演（10:30 - 12:00）
o 「Agile 2008　報告」 平鍋健児氏
o 株式会社 チェンジビジョン 代表取締役社長
o 株式会社 永和システムマネジメント 副社長
o オブジェクト倶楽部 主宰

* 講演①（13:00 - 13:15）
o 「ＸＰ寺子屋」 西　丈善氏
o 日本ＸＰユーザーグループ関西

* 講演②（13:15 - 13:45）
o 「マネジメントから自律へ」 土屋　秀光氏

* 講演③（13:45 - 14:15）
o 「名古屋アジャイル勉強会奮闘記～勉強会を立ち上げて楽しむ7の方法～」(仮)
　　　　 o 名古屋アジャイル勉強会

* 講演④（14:30 - 15:00）
o 「ゼロ機能リリースのもうひとつの側面
o ～ ワーキングスタイルを変える開発基盤をまず構築しよう ～」 中西　庸文氏

* 講演⑤（15:00 - 15:30）
o 「チケットファーストでアジャイル開発！～構成管理を見直そう」 あきぴー氏

　XPを代表とするアジャイル開発は広く知られてきましたが、実際の現場では運用のハードルが高いため普及しているとはいえません。
　しかしながら昨今、プロジェクト管理機能を持つBTS(バグ管理システム)をITS(課題管理システム)として運用してアジャイルに開発する手法が一部で注目されています。
　一部で提唱されている「チケット駆動開発(TiDD)」は、このBTSの運用フローをアジャイル開発の一プロセスとしてフレームワーク化を試みたものです。
　今回は、チケット駆動開発を実践して気付いたこと、考えたことについてお話します。

　▼会場１（２Ｆ視聴覚室）―先着３０名
* ワークショプ①（13:00 - 15:30）
o 「組込み開発におけるテスト駆動開発実践講座」 日本XP ユーザグループ関西

　▼会場２（１Ｆ学習室）―先着３０名
* ワークショプ②（13:00 - 15:30）
o 「プロジェクトファシリテーション入門」 Project Facilitation Project関西

　※　「基調講演」は、全員参加となっております。

=============================================================

詳しくは、ＸＰＪＵＧ関西のホームページをご覧下さい。

【感想】Kansai.pm第9回ミーティング

Kansai.pm第9回ミーティングに行ってきた。
その感想を書く。

【1】Naoyaさんの話～Hadoop Streaming で MapReduce

はてなのNaoyaさんの話。
一番興味があったが、期待通りすごく面白かった。

MapReduceとは、GoogleLabの論文に書かれた分散処理の高速アルゴリズムの一つ。
並列計算アルゴリズムの一種で、Googleが使っている。
Googleはこのアルゴリズムを使って、大規模データを多数のサーバーで並列処理させている。
つまり、バッチ処理を高速化したものと言える。

MapReduceのアルゴリズムのイメージは下記のようにすごく簡単。

入力ファイル→map()→シャッフル→reduce()→出力ファイル

つまり、計算モデルは、関数型言語の特徴である「map：写像」「reduce：畳込み」の2個の関数を組み合わせただけ。
これは、UnixのPipe and Filterと同じ発想だ。

但し、並列処理させるために、分散ファイルシステムが必要。
Googleは、独自の分散ファイルシステム(GFS)を持ち、これが強力。
特に、冗長性に特徴がある。

例えば、1テラバイトのバッチ処理のために、1テラバイトのデータをネットワーク転送するのは、非常に不安定。
ネットワーク転送するだけで1日以上かかるだろう。
GFSというGoogleの分散ファイルシステムは、1 TBを64Mbにchunkして、その単位でワーカーに処理させている。
また、壊れたノードは、別のノードが引き継ぐなど、フォールトレランス機能もあるらしい。

詳細は下記を見よ。

http://www.radiumsoftware.com/0608.html

ここに興味深い一文がある。

関数型プログラミングを会得しない限り， Google に強大なスケーラビリティをもたらしたアルゴリズム ― MapReduce を発明することはできないだろう。 -- Joel Spolsky [Joel]

MapReuceの利点は、計算アルゴリズムがmap, reduceだけでいいという簡単さ。
つまり、巨大なデータを細かい処理に分割し、透過的に処理させる。
その実装プログラムは、ストリーム的な処理で解けるため、関数型言語でなくとも、大抵のプログラミング言語で実装しやすい。

MapReduceで解ける問題としては、検索エンジンのインデックス作成、ソート、検索結果のPageRankの計算、ドキュメント内のリンク参照回数の計算からWebページの有用度計算、など非常に応用範囲が広い。

つまり、Googleは、このアルゴリズムを使って、検索エンジンのインデックス作成を高速化しているのだ！

例えば、MapReuceを使うと、DVD1枚をGrepするのにわずか0.2秒で処理できるらしい！！！
(ただしタスク分散のオーバーヘッド有り)

Naoyaさんは、MapReduceという分散処理の高速アルゴリズムを使って、Perlで実現したらしい。
話した内容の詳細は下記と殆ど同じ。

http://d.hatena.ne.jp/naoya/20080511/1210506301

※講演資料が下記で公開されています。

http://d.hatena.ne.jp/naoya/20080531/1212245982

Naoyaさんは、Googleの論文を読んで、Perlで独自実装したらしい。
使い道としては、巨大なApacheログ解析や検索インデックス作成など。
膨大なテキストファイルを1日ぐらいかけて読み込んでバッチ処理するのを高速化するのに向いている。

後で聞いたら、MapReduceには結構バッドノウハウがあるそうで、分散ファイルシステムだけでなく、シャッフルやReduceなどの処理で色々アレンジするらしい。

【2】バッチ処理の高速化が意味するもの

バッチ処理は業務システムの基本アーキテクチャだ。
特に金融系システムでは、毎日数万～数十万のトランザクションデータをバッチで一括処理するのも稀ではない。
この処理の実装は簡単であろうとも、テストして品質を確保するのは非常に難しい。

何故なら、高負荷な環境でしか再現できないバグは結構あるのに再現させにくい。
また、バッチ処理が異常終了した時、全件ロールバックさせると更に負荷がかかる。
だから、100件おきにチェックポイントを区切り、途中までCommitを実行し、途中から再開できるような仕組みを作る必要がある。

つまり、バッチ処理は、高負荷な環境のシステムテストや異常処理の設計がかなり難しいのだ。
しかし、Googleが適用しているMapReduceモデルでは、GFSというGoogle独自の分散ファイルシステムを使って、壊れたノードは別のノードが引き継ぐという冗長性を確保している。
並列処理なので、プロセスが死んでも他プロセスが引き継げばいい。

Naoyaさんも言っていたが、バッチ処理は冗長性が非常に大事。
いわゆるフォールトレランスが大事なのだ。

【3】日本のSIerの現状

上記の話を聞いて、非常に驚いた。
関数型言語の計算モデルがバッチ処理を抜本的に変えたとも言える。

日本の大手SIerのプログラマ、プロジェクトリーダーは、マンパワーでシステム開発し、マンパワーで品質を確保しようと懸命になっている。
Googleは、システム開発の前提条件そのものをひっくり返して、画期的アーキテクチャで作り直している。
当然、品質確保のやり方も日本のSIerと全く違う。

はてなのNaoyaさんは、少なくとも、Googleの論文を読んでいる。
日本の大手SIerにいるプログラマ、プロジェクトリーダーで、Googleの論文を読んでいる人はいるだろうか？
皆、残業に追われて、デスマーチに追われているうちに、Googleが生み出した技術などに取り残されている。
自分の技術が古くなっている事実にも気づかずに。

はてなは日本のGoogleみたいだ。

【告知】モデル検査

モデル検査の話がSEA関西プロセス分科会で出てくるので展開する。

Wikipediaによると、、

モデル検査（Model Checking）とは、形式システムをアルゴリズム的に検証する手法である。
ハードウェアやソフトウェアの設計から導出されたモデルが形式仕様を満足するかどうか検証する。

モデル検査を使う状況は、特に組み込み系プログラムの設計・テストフェーズが多い。
つまり、プログラムや設計図から状態遷移図を作り、状態遷移図からバグになりそうなアルゴリズムを探し出すというスタイル。
この手法は10年以上前から研究されており、最近のコンピュータ性能の向上から、一部で注目されているらしい。
とはいえ、モデル検査について知見のある技術者は数少ないだろう。

実は、4月のソフトウェア開発技術者試験の午後問題にも、モデル検査が出た。
正直びっくりした。

http://www.jitec.jp/1_04hanni_sukiru/mondai_kaitou_2008h20_1/2008h20h_sw_pm1_qs.pdf

～～　第34回　SEA関西プロセス分科会のご案内　～～

テーマ：動きの設計と検証、さらに自動化

講師　：藤倉 俊幸 （イーソル株式会社）

主催　：ソフトウェア技術者協会 関西支部 プロセス分科会
　　　　　
日時　：2008年05月30日(金) 18:30～21:00

会場　：大阪市立大学文化交流センター
　　　　〒530-0001　大阪市北区梅田1-2-2-600
　　　　大阪駅前第２ビル６階　ホール
　　　　Tel　06-6344-5425　/　Fax　06-6344-5524
　　　　http://www.ado.osaka-cu.ac.jp/BUNKO/　　　

周辺略地図 　　　　http://www.media.osaka-cu.ac.jp/Toshi/yoteiti.html

　　　　※会場の部屋が通常（大セミナー室）とは異なりますので、
　　　　　ご注意ください。（同じビルの同じフロアです。）

内容　：
　　ソフト開発においてはタスク設計が重要です。セミナーでは、
　　モデル検査ツールLTSAについて説明した後、動作要求の仕様化と
　　検証、タスク動作への変換について説明します。手順の概要は、
　　以下の様になりますが、基本的に小難しい話は無しで進めます。

　　1)　動作要求をマインドマップによって表現し、動作仕様を抽出します。
　　2)　各動作仕様をFSP式に変換しLTSAによって実現可能な動作要求セットを作成します。
　　3)　動作要求セットをタスクに分割し、同期構造の設計検証を実施し、タスク設計仕様を作成します。

　　UMLを使用している現場への適用では、動作要求表現として
　　シーケンス図や状態図を利用することで、これらの図からFSP式を
　　自動生成することが可能になります。UMLへの適用に関する詳細は
　　以下のURLを参照してください。

http://www.esol.co.jp/rcs/uml_tool.html

参加費用：
　　SEA正会員：1,000円，SEA賛助会員：1,000円，
　　学生：500円，一般：2,000円

　　定員　：120名

申込方法：
以下のペ‐ジからお申し込みの受付を行っております。
http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/application.html
### 05/28（水）までにお申し込みください ###

　ご注意）
　・受付は先着順で，定員になり次第〆切とさせていただきます．
　　申込受付後のキャンセルは原則としてお断りします．
　・メール，FAXなどWebページ以外からの申し込みは受け付けて
　　おりません．
　・お申し込みの受付け後，確認メールが自動的に返送されます．
　　確認メールを印刷し，当日受付時に持参ください．
　・申し込み手続きについて不明点などございましたら，下記まで
　　ご連絡ください．
　　seakansai-office2007＠media.osaka-cu.ac.jp
　・参加費は当日会場受付にて現金でお支払いください
　 領収書が必要な方は，申し込み時に「領収書要」にチェック
　　してください．

【感想】第25回Ruby勉強会

大阪国際大学で開かれた第25回Ruby勉強会の感想を書く。

【1】JavaEEでRailsを動かす

紅月さんの講演。
一番興味があった。

理由は、ファウラーの下記の記事「ファウラーがRubyに抱く感慨」が気になっていたから。

(前略)若いテクノロジーには新しくて重要な特筆すべき点がいくつもある。だが、私にとって最も重要なのは、JRubyだ。現在、JRubyは最終的なRCの段階だ。 Java VM上で動くスクリプティング言語を提供するだけでなく、 Rubyプラットフォームの完全な実装をJVM上で行おうとしている。 ThoughtWorksで我々が行っていること、そして、多くのRuby/Rails開発者たちにとって、（たとえ"include java"をしたことがなくても）これはかなり重要なことである。

我々のRubyチームが開発中に直面した最も大きな問題はデプロイだ。 Rubyのアプリケーションを実践投入するには、非常に多くの新しいテクノロジーが必要となる。それに、データセンターはこういったことに保守的だ。我々のRubyWorksもこの点をシンプルにしようと努力している。 JRubyはこの点について、Javaコンテナにデプロイすればよいので、 Railsアプリケーションもwarファイルとして簡単にデプロイできると主張している。これにより、Ruby on Railsが多くのエンタープライズ環境における選択肢となる得るのではないかと私は思っている。（後略）

Rubyはスクリプト言語なので、プログラムそのものがアプリケーション。

でも、本来、プログラムの目的は、実行可能なバイナリモジュールを作ることにある。
Cobol、C/C++からJava、C＃へ至るプログラミングの歴史と同じぐらい、ビルドの歴史も長い。

例えば、Windowsアプリは、小さな実行モジュールであるexeファイルと、複雑な業務ロジックや共通ライブラリを分離した複数のDLLから構成されるのが普通。
その思想は、プログラムを論理的に分割するだけでなく、物理的にも分割し、複雑性を制御しようとする所にある。

同様に、JavaのWebアプリも、war/earファイルという一つのWebアプリをAnt/Mavenでビルドして作る。
warファイルの構成は、JSPなどのViewがrootの直下に配置される。
Controllerが含まれるWEB-INF。
そして、複雑な業務ロジック、共通ライブラリは複数のjarファイルへ分離する。

Windowsアプリと同じく、この設計思想も、複雑なプログラムを物理的にjarファイルへ分割するやり方に受け継がれている。

だから、RubyやRailsの弱点はビルド＆デプロイにあるのではないか？というファウラーの指摘は的を得ている気がする。

紅月さんが紹介してくれたやり方の発想は、下記の仕組み。

Rails(warファイル)
↓
JRuby
↓
RailsServlet
↓
Servlet Container(Tomcat等)
↓
JVM

つまり、RailsServletがRailsをServletコンテナにラッパーして、Tomcat上で動かせるようにする。

RailsをTomcatで動かす利点は、JavaのWebアプリケーションサーバーは枯れた技術で性能もいいから。
Tomcat上でRailsが動けば、JBossを初めとして、WebSphere、WebLogicのような大規模なJavaのWebアプリケーションサーバーでも動作可能になるだろう。
そうなれば、より大規模で複雑なWebアプリをRailsで作ることが容易になるだろう。

紅月さんのデモはうまく動作しなくて残念だったけれど、この思想はファウラーの指摘以外にも、もう一つの重要な指摘を含む。

それは、JVMがインフラであること。
JDK6以降では、JRubyだけでなくJavaScriptのような殆どのスクリプト言語がJVMで動作可能になっている。
つまり、JVMさえあれば、RubyもPythonもJavaScriptも動いてしまうのだ。

最近は、Scalaのような関数型言語さえJVMがあれば動作する。
このScalaは、Liftという興味深いWebフレームワークもあるようだが。

実際はパフォーマンスもあろうが、特にWebシステムはスケールアップしやすいので、近い将来、JVM上でRailsを動かすのも実用的になるだろう。

まだ、Tomcatの上でRailsを動かすのは不安定だが、要注目の技術だと思う。

【2】角谷さんのRSpecライブコーディング

　角谷さんは本来、関西人だったそうで、ライブコーディングでは関西弁が随所に出て、聞いていて楽しかった。
　僕自身はJUnitに慣れているので、RSpecよりもRubyのTestUnitの方が理解しやすい。
　yu-yaさんに尋ねたら、TestUnitの方がassertEqualsだけで書けるので簡単ですから、と言っていたのが印象的だった。
　
　角谷さんが、ユニットテストのプログラミングの重要性を下記の図で説明した。
＃縦軸：ソースの綺麗・汚い
＃横軸：プログラムが動く・動かない

┌─────┬───┐
│　　　　　　　│　　　　　│
│　お花畑　　│理想　　│
│　　　　　　　│　　　　　│
├─────┼───┤
│　　　　　　　│　　　　　│
│　終了　　　│現実　　│
│　　　　　　　│　　　　　│
└─────┴───┘

　つまり、理想は、綺麗で動くプログラム。
　でも、現実は、動くけれど汚いプログラム。
　
　綺麗だけれど動かないプログラムは、お花畑。
　汚くて動かないプログラムは、既に終了している。

　角谷さんによると、リファクタリングとは、終了→現実→理想へのルート。
　
　池上さんは、終了→お花畑→理想　のルートもないだろうか？と質問していた。
　角谷さんによる明示的な回答はなかったけれど、数学者である池上さんらしい指摘。
　Haskellはまさに、コンパイルが通れば確実にバグなしで動く。
　Haskellは、終了→お花畑→理想　のルートなんだろうな。

　今日のRuby関西は、Flexユーザーグループ関西の夜桜と重なり、ちょっと人が少なかったのが残念。
　でも、懇親会、2次会も盛り上がって楽しかったです。

　ちなみに、角谷さんの本にサインしてもらいました。
　角谷さんの本は下記が有名かなぁ。

【感想】Kanasan.JS prototype.js CodeReading#4

Kanasan.JS prototype.js CodeReading#4へ行ってきた。
今日はわずか13人だけ。
歩く仕様書のnanto_vi先生もおらず、正直物足りない面もあったけれど、ソース解読そのものは結構面白かった。

今日コードリーディングしたprototype.jsのL1652～L2472 は、ブラウザ依存やCSS依存の部分を汎用的に使えるように苦労している所。

IEはバグそのものが多いのか、ラップしたり、苦労している部分が多い。
FireFoxもVer1.8.0のみ特別な処理がある。
Safariは、バグFixしたプログラマが丁寧なのか、コメントしてくれて親切。

それらのソースは、正直綺麗じゃない。
たくさんの人の手が入ったのだろう、コーディングルールが徹底されておらず、インデントや変数名に統一性がない。

okkezさん曰く「バグレポート駆動」なのでしょう、と。
つまり、 バグレポートが上がるたびに、各人が勝手にバグFixして積み重ねたソースなのだ、と。

この状態は、システム開発の結合テスト以降のフェーズに似ている。
仕様書に従ってプログラミングしても、結合テストやシステムテストで、たくさんのバグ修正や仕様変更に伴って、プログラムは本来のあるべき綺麗な構造から少しずつズレていく。
一度、バグ修正したソースへ再び手を入れるのは、誰もが嫌がる。

今日コードリーディングしたprototype.jsも同じように思える。
実際のソースはそんなに綺麗じゃない。
でも、ブラウザやCSSにも依存しないように汎用的なライブラリにしてくれているので、AjaxのようなリッチUIを実装できる。

以前、lapis25さんが、フレームワークの内部のプログラムは、どう書いてもやっぱり汚い部分が残るんですよ、と言っていたのを思い出す。

汎用的で使いやすいライブラリを作るための泥臭いプログラミング。
それも、プログラミングの一側面。

【感想】第24回Ruby/Rails勉強会@関西

第24回Ruby/Rails勉強会@関西へ行ってきた感想を書く。

【1】REST思想が解決しようとするもの

moriqさんの講演。
REST思想をアーキテクチャの観点から非常に丁寧に深く解説してくれて、かなり概念が整理された。

Webシステムの特徴のひとつは、デプロイが独立していること。
つまり、クライアントのVerUpは、サーバーは無関係であること。

Railsの弱点は、デプロイにあると思う。
おそらく、JRubyがそれを解決してくれるはず。

REST思想のモチベーションは、セッションを汚さないこと。
できるだけ、画面の状態は、URLが指し示すリソースで持つ。
GET、POSTだけでなく、HTTPメソッドにあるPUT、DELETEを使って、セッションで保持しなくてもいいようにする。

少なくとも、注文ボタンの2度押し問題は、POSTメソッドでなく、PUTメソッドを使えば解決できる。
PUTメソッドは冪等の性質を持つので、1回以上の操作後の結果は全て同じだから。

しかし、ストヤンが指摘したように、RESTで全ての問題が解決するわけではない。
戻るボタン対応は、RESTでは、戻る遷移専用のURLを作る必要がある。
それは面倒で根本的な解決ではない。

戻るボタン対応は、結局、Continuationつまり、継続サーバーを使わないと解決できないと思う。
継続の概念があれば、画面操作がログインチェックで中断されても、スタックに保持した操作で画面を復元できる。
正常処理ならいつでも操作の途中から開始できる。

REST思想と継続サーバーの概念は全く別だ、と帰路の電車でストヤンが力説してくれた。
ストヤンが言うには、TCP/IPプロトコルそのものが限界にあり、SCTPみたいなプロトコルが必要じゃないかと指摘した。

僕はその意見が絶対正しいと思っていない。
REST思想はまだ不十分だけれども、無駄なセッション管理をなくす方向でWebアプリを単純化しようとしている。
Webアプリがステートレスである限り、その方向性は性能も考えると正しいと思っている。

【2】Railsとアジャイル開発

かわばたさんの講演。
Railsで構築したSNSと、現場でのアジャイル開発のお話。

Tagawaさんが、Railsのテスト駆動開発では、フェイクしたモックオブジェクトを使って開発することはないのか？という質問をしていた。

Railsに限らず、最近のシステム開発は、モジュール単位にプログラマをアサインして分業化するやり方ではなく、機能単位でプログラマが担当する。
つまり、1機能に必要なモジュールをプログラマが全て作る。セル生産のイメージに近い。
その意味では、プログラマの責任が大きくなっている。

プログラマはアーキテクトでもある。

【3】FlexとRubyの意外と親しい関係

FlexUG大阪のhirossyさんの講演。
Ruby関西の人は殆ど、Flexを知らなかったらしい。

デモでは、Webカメラで写した画面を触るとポッと反応するアプリをする予定だった。

興味深かったのは、RubyAMF の話。
動画などの情報をAMF3（Action Message Format 3 ）という直列化されたバイナリ形式でサーバーとクライアントをやり取りする。
この時、クライアントはFlex、サーバーはRubyで、そのインターフェイスをAMF3であるアーキテクチャ。
この形式ならば、Flexクライアントは、サーバーのAPIをコールするだけで欲しい情報を取得できる。

ストヤンが話すには、FlexはAjaxよりも良い。
理由は、Flexの方がはるかにリッチなUIを作りやすく、更に、動画などのストリーム情報も加工や表示がやりやすいから。

更に帰路の電車でストヤンから、Flexは元々Flashから来たからデザイナーがプログラミングできる。
リッチなクライアントUIはデザイナーに任した方が、いいものが作れるよ、と。

確かに、Ajaxを使った場合、Viewをデザイナーもプログラマも触ることが多い。
だから、デザインをマージする時など、ソース管理がどうしても面倒になる時がある。

個人的には、ユーザ向けWebアプリはAjax、バックエンドの業務アプリはFlexかAirが現在はベストなWebシステムじゃないかと思う。

今回は色んな発表が聞けて楽しかった。

【告知】第 24 回 Ruby/Rails 勉強会＠関西

参加申し込みが近年になく芳しくないので再告知。

詳しくは
http://jp.rubyist.net/?KansaiWorkshop24をご覧ください。

【告知】第 24 回 Ruby/Rails 勉強会＠関西

日時:2008 年 03 月 15 日 (土) 13:00～17:30

場所:神戸大学
会場:学術情報基盤センター分館
アクセス:http://www.kobe-u.ac.jp/info/access/index.htm
費用:実費（講師の交通費、配布物の印刷代等）の人数割をご負担ください。前回（同じ会場）は500円でした。
定員:45名(注意!!)（今回は会場の都合で定員が設定されています）

セッション概要は随時Wikiの方で更新致しますので
宜しくお願い致します。

○ロガー
前回に引き続き、各セッションのロガーも募集しています。
ロガー志望の方は「このセッションのロガーやりま～す！」と書いてください。重複も歓迎。

○懇親会の参加・キャンセル
懇親会の受け付けは金曜17:00までです。

参加およびキャンセルは、
http://jp.rubyist.net/sns/?m=pc&a=page_c_event_detail&target_c_commu_topic_id=139
からお願いします。

○内容
◆NetBeans Ruby Pack / Rails 2.0 by moriqさん
概要 ：

最近 NetBeans 6.0 を触り始めたのですが Ruby support が素晴らしすぎるので NetBeans を触りつつ Rails 2.0 の話題を提供したいと思います。

ディレクターから推薦：
Rubyの統合開発環境を提供するNetBeansは、Rubyをコード補完できるだけでなく、リファクタリングもできる優れモノです。
Ruby初心者にとって、NetBeansは最も開発しやすい環境だと思います。
更に、Railsの中核思想であるRESTful Webサービスについても語って頂く予定です。
REST思想は、今後のWebフレームワークの設計において、MVC2モデルに次いで重要な概念になると思います。

◆Ruby1.9 の新しい仕様(Array の逆襲) by　こなみさん
概要 ：
前回不手際であまり紹介できなかった部分，特にHashとの絡みなどを含めて紹介します。

◆Ruby/Railsプロジェクトにおけるアジャイル開発(仮) by かわばたさん(XPJUG関西)

◆Flex3 / AIR デモ by やまもと（hirossy）さん(Flexユーザーグループ関西)
概要 ：
デモを含むFlex3/AIRのご紹介、RubyとAIR連携。

ディレクターから推薦：
今年初めにAdobeAirがついに正式リリースされました。
AdobeAirは今最も注目されるWebリッチクライアントです。
(M$もAirに刺激されて、.NETで動作するWebリッチクライアントSilverlightをベータリリースしています)
今回は、関西で活発に活動されているFlexユーザーグループの方に、AdobeAirとFlexを紹介して頂く予定です。

◆Ruby初級者向けレッスン第18回 by okkezさん

関西ライフハック研究会でファシグラ体験

関西ライフハック研究会Vol.5「ファシグラ体験講座」 に行ってきた。
一番の目的は、すだち師匠やなおまるさんが書いたファシグラ本の解説。
楽しかった～。

その時の感想をメモしてみる。

関西ライフハック研究会は初参加ですが、座長opakenさんがウケを取ったり、腰ビールのCMもやったり、リラックスした雰囲気。

今回のテーマであるファシグラことファシリテーショングラフィックは、会議で、議論を見える化し、問題vs私たちという構造に持ち込むひとつのテクニック。
実際に書いてみましょう、とプロッキー片手に講師のすだち師匠さん。

さっそく、30人ほどでプロッキーを持って、4人単位に座って、グループワークでファシグラ体験。

プログラマは字が汚い人が多いですが、丁寧に大きく書くとそれほど気になりません。
プロッキーは寝かせながら書くこと、縦は太く横は細くを意識すると、読みやすくなる。

プロッキーを使いながら、議論を見える化する手法についても、すだち師匠から聞く。
議論しながら、ゴールや問題点を書く時、下記をイメージすると分かりやすくなる。

・見出しを使う
・アイコンや絵を入れる
・マインドマップ、マトリックス、フローチャートなどの基本図形フレームワークを使う

さっそく、ワークショップでは、各グループで、好きな商品企画をテーマにワイワイ書いてみる。
僕のチームは、ノートPCをテーマにした。

皆さん色んな個性がある。
マインドマップで議論を発散させる時に、見出しに●をつけたり、黄色の下線を入れると分かりやすくなる。

アイコンは、携帯の絵文字を使うと分かりやすい。
例えば、「アイデア！」「大好き！」「注意！」など。

絵を描くのがうまい人もいる。特にWebデザイナーの人たち。
他チームでは「金太郎飴のようなポッキー」という絵をかなりリアルに描いていて、これならいきなり営業できるのでは？と思わせるぐらい。

プログラマは基本的に絵が下手。
でも、プロジェクトリーダーは、「絵を使って説明してくれ」という場面が結構多い。
例えば、開発者に、こういうアーキテクチャでクラス設計してくれ、とか、お客様へ、売上データはこういうフローで最後はバッチで送信されます、などのように説明する。

僕の場合、作業手順はアクティビティ図、Web画面遷移はステートチャート図、データの流れはロバストネス図やDFDを使う時が多い。

また、ビジネスモデリングでも、WBS、プロセス図やBSC、因果ループ図などを使って、実際の組織の作業フローを色んな角度から解明しようとする。

だから、ファシグラのような技術を意識して使えば、UMLやDFD、ビジネスモデリングツールをより強力に使えるようになる。

いつもながら、関西ライフハック研究会はお笑いを取るのがうまくて楽しめました。
スタッフの皆さん、ありがとうございました♪

Kanasan.JS JavaScript第5版読書会#3 行ってきた

Kanasan.JS JavaScript第5版読書会#3 があったので行ってきた。
前夜は大阪でも雪が積もり、この日も晴れたものの寒い(;_;

この寒い中、30人も集まりましたよ。
自己紹介を聞いていたら、東京から来た人3名、名古屋や三重県から来た人3名もいたよ！

今日も通称サイ本の輪読。
当日の勉強会の内容を書いてみる。

【1】applyとcallをどう覚えればいい？

applyもcallも、関数呼び出しをあるオブジェクトのメソッドのように扱うこと。

f.call(o, 1, 2)　は下記と同じ。

o.m = f;
o.m(1, 2);
delete o.m;

applyとcallの違いは、Ujihisa君がLispで書いた説明が分かりやすかった。

(apply f a b c '(d))
(call f '(a b c d))

つまり、applyは引数が配列、callは引数の羅列。

yharaさんのAnswerが端的ズバリ。

　Schemeを知っていればapplyは簡単．Rubyを知っていればcallは簡単．

applyもcallも、関数をオブジェクトと見なせる点がJavaと異なる。
また、カリー化の話もあった。

他にcalleeの話題もあった。

【2】関数の引数に関数をセットできること～スクリプト言語の最大の特徴

Array.sort()の話。
引数に、ソートしたいロジックを無名関数にして入れたら、ソートできる。

これは、元々Perlから派生した手法だと思う。
ブロックをうまく利用したやり方。
JavaScriptの場合、変数も関数もオブジェクトみたいなものだから、関数をプロパティへセットすることも可能。

Javaならば、無名関数ではなく、メソッドだけのクラスを作り、そのクラスを引数にセットするやり方しかない。
Javaの方が冗長。
RubyはPerl、JavaScriptと同じ。

あと驚いたのが、JavaScriptはオーバーロードできない。
たしかに、JavaScriptは、引数の型がないし、引数の数も見ないから、やりようがないのだが。

次回は、本命のプロトタイプベースのオブジェクト指向のお話。
面白くなってきた(^o^)丿

【告知】「ＸＰ寺子屋」第１回

「ＸＰ寺子屋」第１回
～ＸＰの価値について考えよう！

◆内容
■開催日時
日時　：２００８年０２月０１日（金）　19:00～21:00
場所　：大阪市中央公会堂　Ｂ１Ｆ第４会議室
住所　：大阪市北区中之島1丁目1番27号
参加料：無料

--------------------------------------------------------------------------------

■ＸＰの価値についてみんなで話し合う
ワールドカフェスタイルで、ＸＰの５つの価値（シンプル／コミュニケーション／フィードバック／勇気／尊敬）に沿ったテーブルを用意し、それぞれの価値について話し合います。

--------------------------------------------------------------------------------

■ご持参下さい。
「ワールドカフェ」にちなんで、皆さんのお気に入りの 【飲み物】 をご持参下さい。
お気に入りの飲み物を飲みながら、気軽にお話しましょう!!

!!注意!!
ソフトドリンクに限定します。
アルコールは禁止です。
※アルコールは、懇親会でお願い致します。m(_ _)m

■参加人数
３０名

■申し込み締め切り
08年1月29日

※締切日前に参加人数に達した場合、受付終了致します。あらかじめご了承願います。

■申し込み
こちらから申し込み願います。
折り返し、詳細案内を送付致します。

■主催
ＸＰＪＵＧ関西

【告知】フレームワーク勉強会 at kansai.pm

Kansai.pm フレームワーク勉強会

Kansai.pmでは、来る1月26日(土)にフレームワーク勉強会を開催します。

この勉強会は、言語を問わない（Perl PHP Ruby Python Java Javascript .NET Haskell Schema etc...）フレームワークに関する勉強会です。

詳細は

http://kansai.pm.org/cgi-bin/wiki.cgi?action=ID&b=ZLi4nlBxzTtZhqkoUVhTwA

をご参照ください。
時間などが変更になる可能性がありますので、参加をご検討の方は上記URLにて随時ご確認ください。

■日時

2008年1月26日(土)　13時10分～16時50分
開場時間：13時00分

■会場

大東市立生涯学習センター 特別会議室

JR学研都市線 住道駅下車 徒歩3分（住道駅と直結）

ALPSLAB baseでの地図

■定員

54名

■参加費

発表者の交通費などの実費として、500円程度のご負担をお願いし
ます。
学割を用意する予定です。

■名札について

他の参加者との交流を図るため、用意できる方は名札をご持参くだ
さい。首から提げるタイプの名刺フォルダの貸し出しと、名刺サイ
ズの用紙を準備していますのでそちらもご利用ください。

■電源タップについて

ノートPCを持参される方は、なるべく電源タップもご用意ください。
会場ではコンセントが部屋の隅にしかなく、参加者で協力しないと
電源が確保できない可能性があります。

■内容 (順不同)

はしもと
「共用サーバーでも使える軽量フレームワーク CGI::Application」

あきぴー
「DIコンテナとAOP～Seasarの基本思想について」

AzureStone
「国産ウェブアプリケーションフレームワーク TripletaiL - 日本
の文化 -」

ku-suke
「乱立するPHPのフレームワーク比べ2008/1」

Simon Cozens
「難しいものはMaypoleで簡単」

LT

lapis25
「JavascriptフレームワークExtJS」

なみかわ
「Kansai.pm2007年活動報告」

■ 懇親会

場所
「偶」住道北口店

時間
17時30分～19時00分
(少し早く始めるかも知れません)

参加費
女性2,625円、男性3,150円(飲み放題付き)

学生割引
割引額は未定です。社会人の方々には申し訳ございませんが、
学生割引分の追加出費にご協力よろしくお願いいたします。

■参加方法

参加登録フォームから、ミーティングの参加と懇親会の参加の両方を受け付けております。

ミーティングは飛び入り歓迎ですが、懇親会は店の予約の都合上、原則として事前登録をお願いいたします。

事前登録なしでの懇親会飛び入りはできない可能性がありますことをご了承ください。

懇親会事前登録は1月25日(金)正午を締め切りとします
(前倒しになる可能性があります。なるべく早めの登録をお願いいたします)。

【感想】JavaScript読書会#2

JavaScript読書会#2へ行ってきた。
48人も集まったよ(~o~)
はるばる東京や三重から来た人もいるし!(^^)!

今日も通称サイ本の輪読。
中身の濃かった勉強会の内容を整理するために書いてみる。

【1】関数型言語HaskellをJavaScriptで書き換えてみる

ライトニングトークスでUjihisa君の話「JavaScriptとHaskell」が興味深かった。
Haskell読書会に出たものの、どうしてもHaskellのソースは読めなかったけれど、JavaScriptで置き換えてくれてようやく、Haskellが分かった気がした。

詳細は発表資料を見ればよいが、JavaScriptの無名関数やブロックを巧みに使うと、Haskellのソースを基本的に全て翻訳できる。
但し、Haskellの遅延評価や無限配列はJavaScriptでは書けないらしい。

JavaScriptを関数型言語で置き換えると、どんな利点があるのか？

僕はまだ分からないけれど、少なくとも、prototype.jsの中身のソースにcuury関数が定義されているように、Ajaxのような非同期処理を読みやすくする技術に使われているようだ。

【2】マルチスレッドプログラミングに弱いJavaScriptを補強するライブラリ群

JavaScriptのマルチスレッド関係のお話も興味深かった。

そのライブラリは、わずか40行のソースで、sleep()やwait()、setTimeOut()をJavaScriptで実現する。
そのライブラリを使ったJavaScriptソースを見ると、try{}catch{}構文ではなく、「.」で繋がったメソッドチェーン形式のソース。
＃つまり、5.times.(...)みたいなソースのこと。

そのソースは、初めて見る人はビックリすると思う。

JavaフレームワークよりもRailsが優れている点の一つに、メソッドチェーン形式のソースのため、英語の文章を読んでいるかのような雰囲気になる所があること。
JavaScriptでは、非同期処理をメソッドチェーンで書くという斬新さがある。

【3】プロトタイプチェーンという発想がプロトタイプベースのオブジェクト指向を規定している

サイ本を議論した内容は「ステートメントと式の違いは？」「.(ドット)は演算子なのか？」などのような、まるでJavaScriptの仕様を最初から勉強し直すような高度なもの＼(^o^)／

nanya_tさんの下記の質問から、全員を巻き込んだ「プロトタイプチェーン」の熱い議論が始まった。
Lingrから抜粋した一部の会話を見よ。
＃以下、Lingrから抜粋したので敬称略。

◆nanya_tさん
//falseは何故？
A=function(){}
A.prototype = {
get: function() {return this.x*2;}
}
a=new A();
alert(a.constructor==A);

//trueは何故？
A=function(){}
a=new A();
alert(a.constructor==A);

◆amachang
A.prototype = {} とすると、もともとの prototype プロパティの中身が破壊されるので constructor がおかしくなる（Object で上書きされる）

よって、さっきの例では、(new A).constructor が Object

◆deq
aはAのインスタンスで，Aはconstructorをもってるけどaはもっていない

a.prototype は A で a.prototype.constructor ってこと，でいいのかな？

◆cuzic
個人的にはメソッド探索のチェインが重要だと思うんだけどな。

◆Tagawa
あかん・・amachang先生とnanto先生の議論に付いていけない。

◆kanasan
多分、かなりの人間がついていってない。

◆nitoyon
amachang先生とnanto先生の議論はあとで配布します（別売）

deqさんのログが、本質的な回答になると思う。

【4】Lingrというチャットを使った議論が新鮮

サイ本を読んでいるバックグラウンドでは、Lingrというチャットルームで、参加者全員が質問や突っ込み、告知を行うというスタイル。
＃LingrはRuby on Rails で作られているらしい。
＃ちなみに「36 chatters and 10 observers」でした。凄すぎ。。

誰も喋らない間でも、Lingrではすごく熱い。
参考URLを貼ってくれたり、サンプルソースを貼り付けてくれるので、非常に分かりやすい。

僕も突っ込んだり、質問すると、必ず誰かがフォローしたり、答えてくれる。
話すよりも書く方が楽な時もあるので、自分の考えをまとめたり、他人のソースコードを読む時に非常に役立つし楽しい。

一昨日のRuby関西でも、Lingrを使った。
こなみ先生のソースインスペクションのレッスンでも、勉強会の議論は少ないけれど、Lingrでは、お題に上がったソースを皆が色んな観点から批評して、逆に勉強になった。

今や関西の勉強会では、Lingrは必須だ!(^^)!

【感想】
関西のコミュニティの中でkanasan.jsは、最も集客力を誇るRuby関西よりも、参加人数も議論のレベルも上回るかもしれない。

48人もの参加者へ細やかな気配りをして頂いたkanasan、そしてスタッフの方々に本当に感謝です。

【Ruby関西】自分のプログラミングスタイルを持とう

Ruby勉強会に行ってきた。
何故か今日も雨でした。
＃Ruby関西が開かれる日は雨が多い(^^♪

目玉はCuzicさん著作「Ruby on Windows」の基調講演。
講演は「Ruby on Windows」の内容紹介と思ったら、Cuzicさんが貯めてきたノウハウをメッセージとしてプログラマへ贈る内容だった。

1・プログラミングを始めたばかりの人へ
2・プログラミングに慣れてきて人へ
3・プロのプログラマへ

詳細はWikiを見てもらって、感想を書いてみる。

【1】プログラマの美徳は怠惰さ

手作業やルーチンはできるだけ自動化する。
そのためにプログラムがある。
「プログラマの美徳は怠惰さ」はPerlの偉い人の言葉、と彼は引用した。

　「Ruby on Windows」の目的も「RubyでCOM、RubyCLR、Rjbなどを使って、Windows/.NET/Javaを快適に操作しよう」というもの。
　Rubyistは基本的にUnixの世界で生きているが、Windowsの世界で生きている人も使えるし、強力なツールになりうる。

【2】自分の興味・情熱の方向を知ろう

初心者PGへの彼のアドバイスに「学習できない時にその理由を感じ取ろう」というものがあった。
できない言い訳にその人の本心や本質がある、と。
「時間がない」「どうすればよいのか分からない」などの代表的言い訳の裏には、意識化できない感情や衝動がある。
意識されない抵抗を馬鹿にせず、ありのままに感じ取り、自分の興味や情熱の方向を知っていこう、と。

このアドバイスは非常に参考になる。
心の風邪を引いた人は、やる気がない。
そこまでいかなくても、心がざわめいて、仕事に取り掛かれない時がある。
そんな時に、自分のやりたいこと、打ち込めるもののように、自分の方向性を知っておくことは、プログラミングだけでなく生きる上でも大事。

また、Cuzicさんは「すでに出来上がったものの仕組みを知ること」「文法の整合性を調査する」などが好きらしい。
多分僕も殆ど同じで「出来上がったものを使うこと」「仕様の整合性を考えること」も好きかな。
本当のハッカーは「新しいアイデアを考えること」「機能を組み合わせて作ること」が好きなのだろう。

【3】自分のモチベーション向上や集中できる環境を知ろう

中級PGへの彼のアドバイスに「感度が上がると、自分のプログラミング能力が低く感じるようになる。それが成長だ」というものがあった。
つまり、知識が増えて色々経験すると、自分が書いたプログラムが大した事がないように思えてくるが、その理由は、意識のレベルがプログラミングよりも上がったから、と。
それが、学習できない言い訳になる時がある、と。

上級PGへの彼のアドバイスに「どんな時にモチベーションが上がりますか？」というものがあった。
人によって、ハートが熱くなるツボは違う。
レベルが上がるほど、情熱的になれるツボを知って、自分の心をハンドルできるようになることが大事だ、と。

更に「集中するノウハウはありますか？」というものもあった。
理由は、プログラミングは集中力が大切だから。

Cuzicさんの場合、設計は集中できないがコーディングは集中できる、とのこと。
理由は、プログラムを書かないとアイデアが膨らまない、書いていくうちに分かってくる、とのことだった。

僕の場合は逆に、プログラムを書く前にフローやデータ構造を徹底的に考える方がプログラミングがスムーズだった。
プログラムを書くと、詳細に入りすぎて、何を実現したいのか忘れてしまう。
設計には十分時間をかけて、プログラムは一瞬に書き上げる方が僕は合う。

そういう各個人の特徴を知っておくことが大事。

【3】自分のプログラミングスタイルを持とう

彼のアドバイスに「人にコードを見られることを意識することそのものが進歩になる」があった。
プログラミングには癖があるので、他人の批評を受けることで洗練されていく。
Ruby関西の人たちはオープンソースに積極的なので、自分のソースをどんどん公開していく。
また、ライブコーディングといって、観客の目の前でお題を限られた時間でプログラミングするということまでやっている。
彼らは、他人に自分のプログラムを見せたい、という強烈な自己顕示欲があるのだと思う。

また、「サンプルプログラムは、問題を解決するプロセスそのもの」というアドバイスもあった。
実際、プログラムを書かないと分からないことは多い。
解きたい問題だけでなく、ライブラリの仕様や相性なども書いて初めて分かる。

「自分のデバッグ方法をノウハウを持っておこう」というものがあった。
　暗黙知として持っておくのが大事だ、と。
Cuzicさんの場合、pメソッドで変数出力するのが基本。

また、出力から逆算し、通った分岐を推測することもやる、と。
この手法は、バグの症状から逆に、こういうフローで出てきたのだろう、と推理していくこと。
インプットから書き始めるのがプログラミング。
バグ直しは、アウトプットから始める。

自分の興味や集中できるやり方を体を通じて知って、自分のプログラミングスタイルを身に付ければ、更にレベルアップできますよ、という彼のメッセージは非常に参考になった。

「Ruby on Windows」もいい本なので是非読んでみて下さい。

【告知】スターティングＸＰ！ ～ＸＰを知ってまっか？～

◆スターティングＸＰ！　～ＸＰを知ってまっか？～◆

ＸＰが日本に上陸してはや７年が経ちました。
しかし、「ＸＰ」という言葉は知名度が向上したものの、「ＸＰ」という開発手法の採用事例はまだまだ少ないように感じます。

そこで、再び原点に立ち戻り、今一度ＸＰについて考える場を設けたいと思います。
「ＸＰ」を知らない方、或いは、「ＸＰ」についてもっと知りたい方、是非ご参加下さい。

今回のイベントをきっかけに、「ＸＰ勉強会」を定例開催して行きたいと考えています。

◆内容◆
■開催日時
日時：２００７年１１月３０日（金）　19:00～21:00
場所：大阪産業創造会館（産創館）　大阪市中央区本町1-4-5
詳細は、ご案内メールにてお知らせ致します。

■XPJUG関西スタッフによるスピーチ
ＸＰを職場で実践されているスタッフが、初心に帰って「ＸＰ」について語ります！！
３名のXPerに熱く語って頂きます！！

■ワークショップ「ペアドロー」
もはや「ＸＰ」の代名詞とも言える「ペアプログラミング」。
このペアプログラミングを疑似体験できる「ペアドロー」を行います。

◆参加人数◆
先着順３０名までと致します。
参加費は無料です。

◆懇親会◆
イベント終了後、懇親会を開催致します。
4000円～5000円程度の見込みです。
懇親会につきましては、各自実費をご負担願います。

◆申し込み◆
こちらからお申し込み願います。

◆主催◆
ＸＰＪＵＧ関西

【Ruby関西】テスト駆動のプログラマはもてます

　第20回 Ruby/Rails勉強会＠関西に久しぶりに行ってきた。
　何故かRuby関西が開かれる日は、たいてい雨模様。
　昨日も雨でした(*^_^*)

１・Africa on Rails

　Rails会議がフランス(？)で開かれていたそうで、その報告があった。
　その中で、なんきさんのスライドが興味を引いた。

　「Africa on Rails」というタイトルの講演があり、その中でこんな数字があったとのこと。
＃数字はうろ覚えです。。

　120000000 10000000 160

　この数字は一体何でしょう？　とのこと。
　その3つはアフリカの小さなある国（名前忘れた。。ゴメン）の人口、エイズ患者の数、エイズ患者を支える医師の数、とのこと。
　それを聞いた途端、勉強会の会場でも驚きの声が上がった。
　ヨーロッパの会議でも同じだったらしい。

　その講演では、アフリカの小国で、エイズ患者をサポートするシステム(詳細は忘れた。。ゴメン)を作っているチームがあるらしく、彼らもRailsを使っているとのこと。
　なんきさんは、日本から見ると世界の果てにあるアフリカでもRailsが使われていることに驚きました、とのこと。

　Railsを使っている開発者の女性のスライドがあり、彼女のコメントには、Railsは早く書けるし素晴らしい、みたいなことが書かれていた。
　その女性もエイズに罹患していて、子供もエイズ患者とのこと。

　厳しい現実にいる人たちと、その人たちもRailsを使っているという落差。
　何となく心揺さぶられる話でした。

２・XPとは「個人の責任と勇気を重んじる人間中心の開発手法」

　okkezさんの初級者レッスンは「Rubyでテスト駆動」のお話。
　内容は、女子学生の先輩と後輩が、社員の給料計算のプログラムをペアプロでテスト駆動で書きながら、横でokkezさんが先生として講釈するというスタイル。
　時々、棒読みのような台詞に会場が笑った。

　okkezさんがXPの定義を次のように話した。
　「XPとは個人の責任と勇気を重んじる人間中心の開発手法です。」と。

　何故か、ストンと落ちるような感覚を受けた。
　というのも、業務システム開発とは、単にプログラムを書くだけではなく、ビジネスという枠の中で顧客の業務をシステム化して、支援ないし改善していくというビジネス。
　だから、ビジネスにおける責任をいつも意識する。
　そして、プロジェクトを成功させるために、顧客と交渉する落とし所を決めることから、仕様を決めることまで、決める勇気がいつも必要とされる。
　決めなければ前進できない。
　ふと、そんなことが思ってしまって。

　okkezさんは、こんなことを話していた。
　「テスト駆動であなたも上品プログラマ。テスト駆動のプログラマはもてます」

　この言葉に会場内でも笑い声が上がった。

　このタイトル、実は僕が2年前に初めてRuby勉強会に顔を出した時、かずひこさんがとても分かりやすく解説していて、最後にこんなことを言っていたのを思い出した。
　
「テスト駆動で上品なプログラマになろう。
動けばいいや、では、下品なプログラマ」

　何となく似ている気がして。

　今回は初めての人が少なかったけれど、久しぶりに和気藹々で楽しめました。

【告知】Ruby on Rails について～JavaからRubyへ

～～　第31回　SEA関西プロセス分科会のご案内　～～

テーマ：Ruby on Rails について～JavaからRubyへ

講師　： okkez @ Ruby関西さん
　　　　 cuzic @ Ruby関西さん
　　　　 あきぴー @ SEA関西さん

主催　：ソフトウェア技術者協会 関西支部 プロセス分科会
　　　　　http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/

日時　：2007年08月25日(土) 13:30～16:30

会場　：大阪市立大学文化交流センター
　　　　〒530-0001　大阪市北区梅田1-2-2-600
　　　　大阪駅前第２ビル６階　大セミナー室
　　　　Tel　06-6344-5425　/　Fax　06-6344-5524
　　　　http://www.ado.osaka-cu.ac.jp/BUNKO/　　

　　周辺略地図
　　　　http://www.media.osaka-cu.ac.jp/Toshi/yoteiti.html

内容　：

　　　
　Javaは約10年前に出現して以来、Webシステム開発の業界標準技術として使われ、進化してきました。しかし、その応用範囲が大規模な基幹システムに広がるにつれ、API の巨大化や実行環境の複雑化により、Javaの開発者にかかる負担も年々大きくなりつつあります。
　いっぽう、Javaとは対照的に草の根的なオープンソースソフトウェアの形で着実にユーザー層を広げてきた Ruby の世界に、最近 Ruby on Rails というWeb フレームワークが出現し、大きな注目を集めています。その特徴は、現実に稼動する Webアプリケーションが極めて少ない工数で開発できることにあります。その異常な生産性は JavaやPerl、PHPなど他言語の開発者も注目し、これら他言語のWebフレームワークやDBモデリングにも影響を与えています。
　このたび、関西で活発に活動しているRuby関西の方を講師にお呼びして、Ruby on Railsのアーキテクチャの概要、実際のデモ、そして、Ruby on RailsがIT技術に何をもたらしたのか、を解説して頂きます。

プログラム：

　　1.　13:30 - 14:00
　　　　JavaによるWebシステム開発の現状（あきぴーさん）

　　2.　14:00 - 15:20
　　　　Ruby on Rails のアーキテクチャ
　　　　Ruby on Rails のデモ
　　　　（以上、okkezさん、cuzicさん）

　　　　15:20 - 15:30 休憩

　　3.　15:30 - 16:30
　　　　RailsがＩＴ技術に影響を与えたもの
　　　　（会場の参加者を巻き込んでのディスカッション）

参加費用：
　　SEA正会員：1,000円，SEA賛助会員：1,000円，
　　Ruby関西メンバー：1,000円（※１）
　　学生：500円，一般：2,000円

　　※１　Ruby関西のメーリングリストに登録されている方。
　　　　　メーリングリストに登録されているメールアドレスで
　　　　　お申し込み下さい。
なお、学生の方は500円になります。

　　定員　：36名

申込方法：
以下のペ‐ジからお申し込みの受付を行っております。
http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/application.html
### 08/23（木）までにお申し込みください ###

　ご注意）
　・受付は先着順で，定員になり次第〆切とさせていただきます．
　　申込受付後のキャンセルは原則としてお断りします．
　・メール，FAXなどWebページ以外からの申し込みは受け付けて
　　おりません．
　・お申し込みの受付け後，確認メールが自動的に返送されます．
　　確認メールを印刷し，当日受付時に持参ください．
　・申し込み手続きについて不明点などございましたら，下記まで
　　ご連絡ください．
　　seakansai-office2007@media.osaka-cu.ac.jp

　・参加費は当日会場受付にて現金でお支払いください
　 領収書が必要な方は，申し込み時に「領収書要」にチェック
　　してください．

【Ruby関西】RubyプログラムからJavaの匂いを消したい

　第16回 Ruby関西に行ってきた。
　Ruby会議2007の話もあり、牛尾さんも来られて、いつもの如く盛り上がった。
　楽しかったことをメモ。

【1】Continuation(継続)ライブラリは恐ろしい～yharaさんの話

　Continuation(継続)は、C 言語の setjmp()/longjmp() に相当するRubyのライブラリのこと。
　定義は下記に書かれている。

組み込み関数 callcc

　何故こんなライブラリが必要なのか？
　理由は、込み入ったループ処理でジャンプしたい時、イベント処理で複雑にwaitしている時にジャンプしたい時があるから。

　普通は、使わなくても書けるし、多分書かない方がいい。
　yharaさんが機能を解説してくれたが、callccが入ると、セーブポイントへジャンプするため、同じようなステートメントを何度も通過するので、机上デバッグできない。

　でも、こんな問題でcallccを使うと綺麗に解ける。(元々はSCIP本にあるらしい)

Baker, Cooper, Fletcher, MillerとSmithは五階建てアパートの異なる階に住んでいる。
Bakerは最上階に住むのではない。
Cooperは最下階に住むのではない。
Fletcherは最上階にも最下階にも住むのではない。
MillerはCooperより上の階に住んでいる。
SmithはFletcherの隣の階に住むのではない。
FletcherはCooperの隣の階に住むのではない。
それぞれはどの階に住んでいるか。

Rubyで書くとこうなる。

[Haskell] 非決定性計算

require "amb"

A = Amb.new

baker = A.choose(1, 2, 3, 4, 5)
cooper = A.choose(1, 2, 3, 4, 5)
fletcher = A.choose(1, 2, 3, 4, 5)
miller = A.choose(1, 2, 3, 4, 5)
smith = A.choose(1, 2, 3, 4, 5)

A.assert([baker, cooper, fletcher, miller, smith].uniq.length == 5)
A.assert(baker != 5)
A.assert(cooper != 1)
A.assert(fletcher != 1 && fletcher != 5)
A.assert(miller > cooper)
A.assert((smith - fletcher).abs != 1)
A.assert((fletcher - cooper).abs != 1)

p [baker, cooper, fletcher, miller, smith]

　amb.choose()にはcallccが使われているとのこと。
　Howではなくwhatを書くだけで解けてしまっている。
　うーん、すごすぎ。

　ちなみにHaskellではこう書けるらしい。

リストモナドで非決定性計算

import Control.Monad.List

solve = do baker <- [1, 2, 3, 4, 5]
cooper <- [1, 2, 3, 4, 5]
fletcher <- [1, 2, 3, 4, 5]
miller <- [1, 2, 3, 4, 5]
smith <- [1, 2, 3, 4, 5]
guard $ distinct [baker, cooper, fletcher, miller, smith]
guard $ baker /= 5
guard $ cooper /= 1
guard $ fletcher /= 1 && fletcher /= 5
guard $ miller > cooper
guard $ abs (smith - fletcher) /= 1
guard $ abs (fletcher - cooper) /= 1
[baker, cooper, fletcher, miller, smith]

distinct :: Eq a => [a] -> Bool
distinct [] = True
distinct (x:xs) = all (/=x) xs && distinct xs

main :: IO()
main = print solve

(解答)[3,2,4,5,1]

【2】自分が書いたRubyプログラムからJavaの匂いを消したい～(余談)牛尾さんの話

　牛尾さんが来られていたので、ちょっとだけ話が出来た。
　今はJavaよりもRubyにはまっているとのこと。
　型を書くのが面倒になってきた、RailsのActiveRecordはJavaのDAOと比較にならないほど使いやすい、と言っていた。
　
　懇親会で、牛尾さんが自作のRubyプログラムをRuby関西のRubyistに添削してもらっていた＼(^o^)／
　Rubyistに話を聞いたら、牛尾さんのプログラムはクラス継承もあって設計がすごくキッチリしている。
　でも、Javaの人が書いたとすぐに分かるプログラムで、RubyならIF文の羅列やbooleanメソッドなどはもっと短く書けるよ、とのこと。

　牛尾さんに後で話を聞いたら、プログラムからJavaの匂いを消したいんですよ、Rubyを体に染み込ませるまで書き込みたい、とのこと。
　モデリングのプロである彼がそこまではまっているとは思ってもみなかった。
　eXtreme Programming以来の衝撃がRubyにあるんですよ、と言う彼の言葉が印象的だった。

　うじひささんが、牛尾さんのことをアジャイル王子(XP祭り関西2006のライブセッションの王子役)と言っていたのも印象に残った。
　XP祭り関西を未だに思い出として残している人たちがいる。

　とまあ、技術の話も懇親会も楽しかった。

【Rails関西】軽量の人は繊細な人を兼ねる～JavaからRubyへ

　今日のRails関西に行ってきた。
　artonさんという大物有名人の講演も聞けて、ワクワクする勉強会だった。
　その感想を書いてみる。

【１】Javaはクールな言語だった

　artonさんは「Javaも好きです」と言っていた。
　Javaは元々こんな特徴があって、10年前はクールな言語と言われていた。
　つまり、Javaはインターネットを意識した初めてのプログラミング言語だった。

・仮想マシン(JVM)の上で動く
・バイトコードで読める
・ガベージコレクションがある
・移動コード(セキュリティ機構)を持つ
　つまり、リモートホストからローカルホストへ転送され実行される機構を持つ

【２】Javaは現代のCobol～業務アプリは繊細な作り

　でも、実際の現場では、Javaで業務アプリを作っても、やっぱり業務アプリは壊れやすい。
　そして、広範囲に膨大に使われて、Javaが全てを解決したとはとても言えない現状がある。
　最近は、軽量の言語の方がいいのでは、という傾向もある。

・業務アプリケーションに最も使われている
・型があるから安全でしょう(本当？)
・コンパイルするからバグが見つかる(本当？)
・Eclipseという統合開発環境があるから初心者でも簡単
・オブジェクト指向言語だが、今時そうでないプログラミング言語を見つけるのが難しい
・private、interfaceなどの言語仕様があるけれど、今はどの言語でも持っている

【３】それでもJavaには利点がある

　にもかかわらず、Javaにはうまい仕掛けがある。
　これらをうまく使えば、何かできないか？

・Reflection
・Annotation
・Bytecode Modification
・Java Native Interface

【４】軽量の人は繊細な人を兼ねる～軽量なRubyが繊細な業務アプリへ進出してきた

　「軽量の人は繊細な人を兼ねる」という言葉をartonさんから初めて聞き、心揺り動かされた。
　つまり、「軽量なRubyが繊細な業務アプリへ進出してきた」ということ。

　実際、一部のSIerが、WebアプリをJavaからRubyへシフトしつつある。
　このあたりの事情は、倉貫さん(XPユーザーグループ代表)のBlog『JavaからRubyへ―マネージャのための実践移行ガイド』でも取り上げられている。
　この傾向の意味は、RubyがITビジネスとして使えるという安心感を示している。

【５】だからRjb(Ruby Java Bridge)

　そこで、RubyからJavaライブラリを再利用するするために、Rjb(Ruby Java Bridge)を作ったとの事。
　Javaのライブラリはそこら中に転がっているのだから、そのライブラリを再利用すればいいじゃないか、と。
　この発想は、PerlのPluggerをRubyからコールして再利用しようという以前の講演のモチベーションと全く同じ。
　
　その仕掛けの詳細はサンプルデモなどを読んでもらえればいいが、講演では、スレッドやスタック回りの開発部分の話がすごく面白かったけれど、時間切れで、もう少し聞きたかった。

【６】時代はJavaからRubyへ？（.NETじゃないよ）

　artonさんは、何もRailsじゃなくてもASP.NETだって同じようにすぐに出来るよ、とサンプルデモを講演してくれた。
　色んな言語での比較は面白い。
　
　僕の少ない業界経験では、M$系のツール(Visual Studio)をフルに使いこなす技術者の生産性はJavaよりも高い。

　にも関わらず、やっぱりJavaは面白い。
　理由は、.NET系は自動生成したソースコードを解析するのはブラックボックスを触るような感覚で非常に難しいが、Javaなら自分で最初から組まないと動かないので、機構がすごく良く分かる。
　同じように、RubyOnRailsも、ソースを最初から最後まで追いかけられるので、機構がすごく良く分かる。

　元々、オブジェクト指向という発想はネットワークと相性がいい。
　サーバーはオブジェクトに似ている。
　だからインターネットを意識した言語、あるいはインターネットのキラーアプリが時代を変えるのだろうと思う。
　
　そんな講演を聞きながら、そして一部のSIerがRubyで実際にシステム構築していく事例を見聞きすると、今と言う時代の技術が変化しつつあるのを感じる。

Ruby関西と仏大統領選

　4/28に開かれたRuby関西へ行ってきた。
　詳細なログは、本家サイトを参照して下さい。
　楽しかったことをメモ。

【１】Ruby関西フランス支部と実況生中継＼(^o^)／

　フランスに移住(？)したかずひこさんへ、WebカメラやSkype(?)を使いながら、Ruby関西の勉強会の講演をやり取りした。
　かずひこさんの音声はリアルタイムにはっきり聞き取れたし、最後の10分間、プロジェクタのスクリーンにちょっとぼやけた動画でかずひこさんが映った。
　最近の技術はすごいね～。

　かずひこさんも講演を聞いた後に質問したり、コメントしたりしながら、
「フランスから、微妙に寂しさを感じながら講演を聞いてます」
という発言があって面白かった。

　コウザイさんからは
「音声だけですけど、皆質問しているのが聞こえて、お家にいながらＲｕｂｙ勉強会にいる感じです」
「お茶の間留学みたいです～」
の発言があり、聴衆皆で大笑い(^_^;)

　準備されたスタッフの皆さん、また朝5時からスタンバイしたかずひこさん、コウザイさん、お疲れ様でした。

【２】仏大統領選とRubyの関係

　かずひこさんから、フランスの近況の話があり興味深かった。
　丁度今、フランスは大統領選の真っ只中。
　そんな中、フランスのオープンソース団体が大統領候補へオープンソースの力になってくれるか、質問状を送ったらしい。
　返ってきた反応は、殆どの候補がオープンソースに好意的だったらしい。
　しかし、最有力候補であるサルコジさんは、「私はオープンソースの人が期待している答えは出せない」という返事が返ってきたとのこと。
　かずひこさんによると、サルコジさんは「金持ちLove(ハートマーク)」な人だそうで、移民な私はどうなるんだろうかと思います、と言っていた。

　こんな所で、ITと政治が絡んでいるとはね。
　日本だったら、どうだろう？
　日本はRuby発祥の地だから、政治的に応援されやすいだろうが、実際はそこまで国や地方の支援がないのが実情なのかもしれない。

　コミュニティに関わっている者としては、公共団体の援助は当てにせず、コミュニティに集まった人たちだけで、自由な雰囲気をつくり、しかも社会へ刺激を与えられるように、プログラマ自身が力を身に付ける方が大切だと思っている。

人は皆、誰かのロールモデルになっている

　梅田さんの記事「ロールモデルの提示がもっともっとネット上に溢れるといい」にこんな一節がある。

アメリカ人の友人が小学生の頃、教会の日曜学校で先生から「人は皆、誰かのロールモデルになっているんだよ」と言われ、「こんなに小さな自分でも誰かのロールモデルなのか」ととても驚いたそうです。 この話を聞いたのは、もう10年以上も前ですが、いまだに私の心の中に強く残っています。 あなたも私も、知らないうちに誰かのロールモデルになっているのでしょうか。

　どんなちっぽけな存在の人でも、誰かのロールモデルになっている。
　どんな人も、その背中は誰かが見つめていて、誰かがお手本として参考にしている。

【Ruby関西】ＩＴ業界のロールモデルは誰？

　第14回 Ruby関西に出かけてきた。
　午後から雨になり、随分冷え込んだのに、京都女子大で開かれた勉強会に70人も集まって熱気があった。

　勉強会の内容についてはログを参照して下さい(^^)
　自分が感じたことを思いつくままに書いてみる。

【１】卒業する4回生へ花束贈呈

　勉強会終了直後に、スタッフから小波研究室の女子学生4回生へ、毎回の勉強会の準備への感謝をこめて花束が贈られた。
　贈られたご本人たちは随分驚いた様子で、代表したコウザイさんも「大して役立っていないのに、こんな素敵な花束を贈ってもらえて感謝してます」みたいに答えていたのが初々しかった。

　こういう思いやりを、コミュニティで表現できる場があるのはいいなあと感じた。

【２】小波先生、かずひこさんのようなメンター(保護者)の重要性
　　～ＩＴ業界にロールモデルはいるか？

　このRuby関西の良い所は、まだプログラミング初心者の女子学生を見守る父親のような小波先生やお兄さんのように面倒を見るかずひこさんのような人たちがいること。
　小波先生はもちろん、かずひこさんのように人間的にもすばらしく誰からも好かれるような人が先輩として、20代の若い人たちへアドバイスしたり、動機付けしたりする。
　若い人もそういう先輩を素直に慕っている雰囲気がいい。
　
　メンターがいることで、特に女子学生が伸び伸びと勉強して力をつけるし、メンターを見て、自分が進むべき道と目標への距離を計測して頑張っている。
　そういう雰囲気に刺激されて、他の若い人たちも集まってくる。
　逆に、先輩格の人たちも、元気のいい後輩が慕ってくれるので、自分だけの殻に閉じこもることもなく、惜しげもなく自分の知識を伝える技術を身につけられる。

　後輩たちもそんな先輩の姿を見て、自分たちが卒業して働き始めたら、先輩にしてもらったことを同じように後輩へつなげようとする。
　まだ若いコミュニティだけれども、卒業生がスタッフとして戻ってきたらいいだろうなと思う。

　こういう好循環の環境を見るにつけ、日本のＩＴ業界にロールモデルはいるのだろうか？と思う。
　ライブドアの堀江さんは功罪もあろうが、彼もロールモデルの一人にあげられた時期もあった。

　３Ｋと呼ばれるＩＴ業界が輝くためには、若い人の模範となるようなロールモデルをもっともっと生み出さないといけないのだろう。
　

XPJUG関西からデブサミへ

今日から2日間、デブサミが開かれてます。
行きたかったけれど。。

XPJUG関西からも組込みTDD部会が参加しています。
細谷さん、頑張って下さ～い。

他に、PFP関西もワークショップに出てます。

XPJUGの部会では、「Dear XP」のライブがあるらしい。
あの歌を聴くと、昨年のＸＰ祭り関西を思い出す。

月日が経つのは早い。。

【Ruby関西】FormalMethod、オープンソースを軸としたエンジニア人生

土曜にRuby関西へ行ってきた。
今回も50人以上集まり、懇親会会場までの乗り物でプリンセスラインのバスを貸し切り、懇親会会場のインド料理店も貸し切り、行くたびにどんどん大々的になっている不思議なコミュニティだ。

【１・いけがみさんの話～テスト駆動を代用するライブラリ】

今回一番聞きたかった話がいけがみさんの講演「Ruby で書いたプログラムのデバグ技術」。
最初は、振舞駆動開発ライブラリRSpecやランダムテストライブラリRushCheckのお話。

１・RSpec

RSpec はTest::Unitと違って、テストの仕様を実装から切り離す所に特徴がある。
後で話をしたら、テスト駆動では、境界値条件や同値分析など実際の値を組み込んでテストするのに対し、RSpecでは、assertEquals()の構文を抽象化したものに相当するとの事だった。
確かにこの手法なら、設計仕様と区別して要求仕様がそのまま書けるが、まさにこの作業こそが手間がかかる所。

２・RushCheck

RushCheckはいけがみさん独自のライブラリで、テストで与える入力をランダムで大量作成してテストするツール。
意図は、不良品のサンプリングでサンプル数が多いほど統計学的に確からしさが高くなるように、テスト空間でテストするケースを増やせばバグをあぶりだせるだろう、ということ。

この発想は使えそうな気がする。
潜在的なバグの存在確率は過去の経験値で分かっているならば、ランダムにテストしてその結果を出力すれば、統計学的にどこまでバグをつぶせたか、ある程度見通せる。

但し、かずひこさんが「ランダムテストした時に、その経緯でバグが出るが、順序を変えると再現できない場合はないか？」と質問したように、ランダムテストで状態が変わってしまうような時は微妙な問題になる。

いずれもアイデアは面白いけれど、開発途中という印象を受けた。

【２・いけがみさんの話～FormalMethodは要求仕様を数学として書く手法】

最も興味深かった話は、FormalMethodのお話。
FormalMethod(形式仕様記述)には、「形式的手法」と「数理的手法」の二つの訳語があるが、いずれも「要求仕様を数学として書く」ための手法で、テスト抜きで確からしさを検証できる。

FormalMethodの実装例は、CやJavaでは既に公開されていて、ビルゲイツも「21世紀の新しい技術だ」と絶賛したらしい。

但し、学習時間や計測時間などのネックがあり、テストよりもコストが高いのが最大の弱点。

FormalMethodの例としては、代表的な2つの例がある。
一つは、モデル検査と呼ばれるもので、オートマンを基礎とする。
もう一つは、定理証明と呼ばれるもので、要求仕様を命題へ変換して、PGMと仕様が一致することを証明してしまうもの。

前者のモデル検査のツールは多いらしく、M$でも使っているらしい。
SEA関西プロセス分科会でも、モデル検査の話は以前あったから興味深かった。

後でいけがみさんに、FormalMethodについて聞いてみたら、ハードウェアに近い部分では成功例が多いらしいが、FormalMethodは万能薬ではない、とのこと。

テスト駆動からFormalMethodへ突き進むと、どんどん数学に近づいていく印象を持った。

【３・かずひこさんの話～オープンソースを軸としたエンジニア人生】

かずひこさんが語るオープンソース遍歴と人生観のお話で、考えさせられました。

かずひこさんは、電子辞書からWikiに至るまで、コミュニティへフィードバックしたら歓迎されたという原体験を持っている。

顧客にとって、オープンソースだろうが、ベンダー製品だろうが興味ないというシチュエーションが増えてきたこと。
オープンソースの方が業務の継続という点から見ると、サポートが受けられるというシチュエーションが増えてきたこと。

そもそも、サポートを止めるという行為は、サービス業のプロとしていいのか？
愛よりも誠意の問題ではないか、との指摘。

話を聞くと、オープンソースがビジネスに与える力が変わっているように感じた。

最後の方で、エンジニアとして、会社を辞めたら何が残りますか？と聴衆へ問いかけていた。
オープンソースなら、自分の作品としても残すことが出来る、と。生きた証として。

この言葉はしびれました。

なぜ、Imagine（ジョンレノン）の曲が流れているか分かりませんでしたが、最後のパワーポイントでようやく分かりました。

You may say I'm a dreamer...

But I'm not the only one.
I hope someday you'll join us. :)

今後、フランスで活躍されるとの事。
ご活躍をお祈りしてます。

Haskellに触れてみる

　偶然見つけたHaskell勉強会へ出てきた。
　本もなく飛び入り参加でしたが、ううううさんの丁寧な進行やいけがみさんの適切な解説のおかげで大変興味深い勉強会だった。

【１】Extreme Readingによる和気藹々の読書会

　Extreme Readingとは、レジュメを担当した人が解説するのではなく、ペアプロのようにその場で読んで噛み砕いて議論するやり方だそうだ。

　初体験でしたが、『ふつうのHaskell』という簡単な本であること、さらにHaskell専門家のいけがみさんがいたおかげで、初歩的な質問から他言語との比較の議論まであって、結構深かった。

　Extreme Readingのやり方よりも、タイムキーパー役のううううさんの進行の上手さがむしろ印象的だった。
＃PFP関西でのワークショップはタイムマネジメントがうまくいかなかったことを思い出して。

　大学生が中心で、Haskell初心者ばかり集まった勉強会。
　とはいえ、自分で株式会社を作ったと言う人たちばかりで、そのパワーに圧倒されてしまった。

【２】Haskellのサンプルからのぞける特徴

　講師役のいけがみさんが、Haskellの長所を問われて、

「遅延評価にそれほどの利点ではない。むしろ、型推論が出来ることと、新しい言語だけに良い所があることだ。丁度、PerlよりもRubyの方がスクリプト言語として洗練されているように。」

と答えたのが印象的だった。

　cat演算子と行数カウントをさっそく実装して動かしてみた。
　サンプルは簡単ではあるが、池上さんの言うHaskellの特徴が出ていないだろうか？

--cat.hs --Unixのcat

main = do cs <- getContents
putStr cs

--countLine.hs --ファイルの行数カウント

main = do cs <- getContents
print $ length $ lines cs

　最後にいけがみさんから教えてもらったIBM の Haskell に関するコラムを残しておく。

『境界を越える: Haskell を使った関数型プログラミング』

【PFP関西】段取りと仕切りのフレームワーク

　今日開かれたPFP関西ワークショップに参加してきた。
　楽しかったです。
　スタッフの皆さん、ご苦労さまでした。

【１】芦屋さんのお話
　依田さん、前川さんの話の後、芦屋さんのお話があり、最も興味を引いた。
　プロフィール紹介で、２年目までお客さんとよく衝突したが、それ以降１９年間、予防に努めてきた、とのこと。
　リスク管理に優れている人なのかな、と思ったり。
　話の節々に冗談を入れて笑いを誘って、聞きやすかった。

【２】時間管理が難しかったワークショップ

　３０人の聴衆を、マネージャチーム、若手チーム、エンジニアチームに分けて「楽しく仕事をするには？」をテーマにグループディスカッションを行った。
　自分はエンジニアチームに入り、コミュニケーション、エンジニアライフ、見える化について議論した。
　仕様がなかなか確定しない、プロジェクトの目標が曖昧、という意見が出て、素直に頷く。
　僕は、利害関係者、特に、お客や上司など自分がコントロールしにくい人との調整が難しい、という意見を述べた。

　議論は各人の経験がそのまま出てすごく興味深かったけれども、２０分でまとめて発表する段取りや仕切りが上手くいかなかった。
　３チームの発表では、エンジニアチームの発表が、内容は経験に基づいており、優れていると思ったけれども、論点がはっきりしなかったようだった。
　結局、若手チームの「コミュニケーションを上手く取ろう。そのためにティータイムやカップラーメンタイムを設けよう」という発表が最も拍手が多く、優秀賞となった。

【３】プロジェクトファシリテーションを支えるフレームワークは何か？
　
　スタッフの熱意、スタッフの切り盛り、和気藹々としたコミュニティの雰囲気、これらはいずれも２年前のXPコミュニティの雰囲気と全く同じ。
　でも今は、平鍋さんがXPからPFへ活動を発展させた軌跡と同じように、XPコミュニティの活動は停滞して、PFコミュニティへ皆の関心が流れているように思う。
　
　プロジェクトファシリテーションの定義は既にあるけれども、それを支える技術は、段取りと仕切りのフレームワークにあるように思う。
　バーンダーンチャート、かんばんのように仕事の段取りを効率化させるスキル。
　朝会、KPT、ホワイトボードのように、会議やチームを仕切り、ゴールに向かって進行させるスキル。

　XPやアジャイルに興味を持つマネージャは、段取りや仕切りを実行する時に、グッズやツールを使うのが上手い。
　にこにこカレンダーのようなグッズは職場にあるだけでも雰囲気が和むし、笑いも誘える。
　
　懇親会で話を聞くと、こういう小物やグッズは関東のグループが好きでよく編み出すらしい。
　逆に関西のグループは、実際に会って活動してお笑いを誘って、の方が好きらしい。
　地域の特色が出て面白かった。

　PFP関西は今、静かに盛り上がっているコミュニティ。
　要注目。

【歌】Dear XPよもう一度～XP祭り2006公式ソング

　XP祭り関西2006の倉貫さんのセッションで初めて聞いた「Dear XP」。
　そのメロディがすごく残る。
　そして懇親会で、XPJUG東京の有志がライブで弾いてくれて、皆で盛り上がった。
　1日経った後もまだリフレインしている。

　「Dear XP」のビデオクリップはこちら。是非もう一度、XP祭り関西2006の余韻をどうぞ。

Dear XP Movie

　歌詞は下記に掲載されています。誰か弾いてくれないかな？

翔ソフトウェア (Sho's) Fujiwo の日記

【宴】Dear XP～XP祭り関西2006盛況終了

　XP　Dear　XP
　君ともっと話したい
　苦労やなによりも喜びを
　もっともっとわかちあいたい

～XP祭り2006オフィシャルテーマソング

　XP祭り関西2006が大盛況で終わりました。
　懇親会も100人も来て下さり、XP祭りオフィシャルテーマソングのサビで、皆が「X」「P」の格好を決めて、異様な盛り上がりでした。

　参加者から、

すごく楽しかったです！
来年もやるんですか？
XPに興味を持ちました
心が洗われました

の感想をたくさん聞きました。
　キャストの一人として、無事に終了しただけでなく、関西でこれだけの人がXPに興味を持ち、満足してもらえたことが一番嬉しい。

セッション「XP開発ライブ」の一シーン。
アジャイル王子が観客席へ問いかけているところ。

懇親会のライブ風景の一シーン。歌は「Dear XP」(XP祭り2006公式テーマソング)

　当日に参加した人は、下記のスレッドへ感想を是非書いて下さい。

http://xpmaturi-kansai.org/modules/newbb/index.php

※感想を書くには、新規登録が必要です。

　XP祭り関西2006公式ページのBlogにトラックバック用ページを作りました。
　コメント、トラックバックをドシドシお寄せ下さい。

XP祭り関西2006の感想、トラックバックなど下さい

Perl関西はハッカーのコミュニティ

　日曜の昼下がりに京都で開かれたPerl関西に行ってきた。
　今日の京都は、雨から小雪交じりになって寒すぎ(m_m)
　にも関わらず、30人も参加者がいて、勉強会も懇親会も盛り上がった。

【１】Perl屋さんはハッカーが多い

　講演者のプレゼンのノートPCを見ると、殆どの人が、MacかLinux上で、Emacsを普通に使いこなしている。
　しかも、Perlを使いこなすだけでなく、RubyやLispを使いこなす人も多い。
　HaskelやMLにも興味を持って話す人もいた。

　彼らの話を聞くと、CよりもJavaの方が1万回のループ処理が速い時もあるんですよ、とか、プログラミング言語のライブラリの中身は、ライブラリを使う人が簡単に使えるようにするために、結局汚い事が多い、等、プログラミング言語の特徴をよく押さえているという印象を持った。

【２】Perlはプログラミング言語として「緩い」特徴がある

　Perlの標語にこんな言葉がある。

　There's More Than One Way to Do It　

　他にもいろんな方法があるよ

　普通に書ける処理を別にこんな風にも書ける、というパターンがPerlには多い。
　いわゆるシンタックス・シュガーを使うと、いくらでも短く書ける。
　なみかわさんの講演では、「頭を柔らかくして、良い刺激を受けて元気になろう(^^)」という話があった。

　でも、この特長には功罪があり、他の人が読めないソースになってしまって保守できないという弱点もある。

　また、Perl関西の他の講演者も話していたが、「プログラミング言語としてPerlは緩い」所がある。
　変数や関数の隠蔽が無頓着だったり、オブジェクト指向の導入が他の言語に比べると....だったり。

　やはりPerlは、正規表現、ファイル操作、CGI、Wikiなど、お手軽に作り上げる所に最大の長所がある。
　すぐに建てて、用が足せば捨ててしまう。

　PerlやRubyなどに触っていると、プログラムは設計そのもの。
　アイデアをすぐにプログラムに起こしてみて、実際にすぐに動かせる所に最大の特徴がある。

【３】開発のスピードとプログラミング言語の関係
　最後に、Webシステムから業務システムへ開発が代わった人と話していた時、業務システムの開発はスピードが遅いんですよ、と聞いたことが気になった。

　PHPやPerlによるWebシステムの開発の場合、3ヶ月ぐらいのスパンでリリースするから、スピードが非常に速い。開発スタイルも、リリース後、お客さんの要望を取り入れながら改善していくことが多い。
　しかし、業務システムの場合、プロジェクトの期間そのものがもっと長いことが多い。
　だから、ずっと忙しい感じで、スピード感がないんですよ、と言っていた。

　とまあ、JavaやC#のようなガチガチの静的型付け言語に慣れている身にとって、刺激になった。