OSC2009に参加してきました

　OSC2009 Hokkaidoに行ってきました。
　少し日にちが経過してしまいましたが、ちょうど前回と同じ日付になったので、問題なしということで。
　私が参加したのは以下の講義です。講義内容にリンク貼ってあります。

1. 僕がOSASKを作り続ける理由
   以前聴講したことがあって、久々に川合さんの面白い話を聞きたくなったので。
2. OSSを用いた仮想マシンの動的プロビジョニング
   仮想化に興味はあるのですが、未だよくわからない分野なので話だけでも聞いておこうかと。
3. Ruby札幌ダイジェスト・アンド・モア
   Rubyなので参加しないわけには。惰性ではなく習性となっている気がします。
4. 「JavaFXでここまでできる!」(仮)
   RIAは触れたことがないですが、Javaが分野を広げるなら、知っておいた方が今後のためかな、と。
5. 30分で作るAndroidアプリ
   Androidは今のところ追いかけておきたいので。

　では、以下に感想を。

テストの単独実行

　Rails2.3を今触っているところなので、ちょっとしたメモを書いていきたいと思います。

　Railsは2.3までにテストにも随分変更があったようで、testディレクトリ直下のtest_helper.rbに依存する形となっているため、単独実行の際は、アプリケーションルートをカレントディレクトリとした場合、「-Itest」を追加する必要があります。

ruby -Itest test/unit/entry_test.rb

　大した手間ではないですが、「Railsレシピブック 183の技」のP.470にある通りに単独実行するとエラーになったので少し驚きました。
　その他もテスト周りはRails2.0.2から変更されているように思えますが、基本的にやることが減る方向のようなので、特に問題はなさそうです。

　色々と楽になっていくのはいいですが、違いが大きいと書籍を参考にした場合の戸惑いも大きくなるので、安定したバージョンが出てほしい気もします。ただ、一方で最新の実装を触りたい欲求もあるので、Railsとはそういうものだと付き合っていくしかなさそうです。

第24回XPユーザ会に参加しました

　最近「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を買って読んでいて、プランニングポーカーの箇所を読み終えた後に、第24回XPユーザ会 『アジャイルな見積りと計画づくり』にて体験できるということを知り、参加することにしました。
　少し日が開いてしまいましたが、以下感想などを書いておきます。

　本当は最初から参加するつもりだったのですが、仕事で想定外の作業が発生してしまったため、角谷さんのお話の最後の方からの参加となってしまいました。案内してくださった市谷さんには受講を中断させてしまったようで、申し訳なかったです。

　プランニングポーカーは最初から参加でき、幸運なことに角谷さんとご一緒できたこともあり、とても参考になりました。
　本の内容だけでも充分に興味深かったのですが、実際に体験してみて、見積り中に知識が増えたり、合う見積りを出せたりしたことで、有効であると確かな感触が得られたので、知人の技術者などにも機会を作って広めてみたいです。

　気になった点としては、提示したストーリーポイントの微妙な違いがあって説得により見積もるポイントの合意を形成する際、日本人だと空気を読みすぎて意見を言わずに合わせてしまう危険性が高いことですが、この点はチーム内の信頼関係を高めていくのが一番有効な対処のように思います。

　また、実際に失敗した点として、基準にするストーリーの見積りを外すと、その他のストーリーの見積りでも大きく外れるということがよくわかりました。
　この点については、基準のストーリーのみ時間をかけて厳密にすることも考えましたが、それはプランニングポーカーの趣旨から外れてしまうので、基準としたストーリーについては特に注意しておき、想定外に気づいた時点で対応することが重要かと思っていますが、実際にやってみないことには難しそうです。

　懇親会ではプランニングポーカーのカードが当たって思わぬお土産もでき、また色々他の方のお話を聞けて、良い時間を過ごせました。今のところ東京に滞在する予定はもうありませんが、また機会があれば参加したいと思います。主催者、参加者の方々、ありがとうございました。

Safe ERBを利用してみました

　OSC2008で話に聞いた、Safe ERBを利用してみました。

　最初safe_erbで検索してみたら、この日記が2番目に出てきて焦りましたが、「Safe ERB」が正式名称なのですね。
　http://d.hatena.ne.jp/kstn/20071225/1198549608にて、2.0対応していると書かれていたので、安心して入れました。
　2.0ユーザにとってはありがたいことです。

　コマンドラインからのインストールについては参照先に書かれていますが、NetBeansならば、プロジェクトを右クリックして「Rails プラグイン...」を選択、「リポジトリ」タブを開いて、「URLを追加」で、「http://safe-erb.rubyforge.org/svn/plugins/」を追加すれば、「新しいプラグイン」タブにsafe_erbが登場します。

　早速起動したところ、何も反応が無いので、これなら安全？とか思っていたら、単にErubisが有効になっていたためにERBが働いていなかっただけで、結果はぼろぼろでした・・・ああ、やっぱり。

　実際は、ユーザ入力を一般に表示するような画面は無いので、XSS攻撃を受けることは無いはずですが、セキュリティは穴があってはならないので、安易に考えず、きちんと修正しないといけませんね。

　Erubisにもこういう機能がありそうな気はしますが、あまり詳しくないのでそのうち調べようかと。プリプロセスを使ってしまうとSafe ERBの検証が実質的に無意味になってしまうのではないかと懸念していますが、これも知らないので調べないと・・・

OSC2008に参加してきました

　OSC2008 Hokkaidoに行ってきました。
　ここ4年ほどは毎年参加していますが、今年も有意義な時間を過ごせたと思います。
　私が参加したのは以下の講義です。

1. Ruby/Rails セキュリティハンズオン
   あまりRailsを使えているとは言えないですが、自サイトをリプレースする場合にセキュリティを考慮に入れたかったので。
2. Ruby勉強会@札幌 特別編
   個人的に請けるWeb関連の仕事はRubyしか考えてないですし、色々と状況を知っておくことは励みになるかなと。
3. 異端のWebフレームワークSeaside
   異端のフレームワークという名称に惹かれました。
4. ネットワークの自由、その現状とこれから
   セキュリティも大きく絡むので、ネットワーク関連の状況は是非とも知っておきたいところです。
5. Eclipseのお話
   仕事でも個人的にもEclipseを使う機会は非常に増えましたので。

では、簡単ですが感想を書きます。

開発環境構築

　以前購入した書籍に従い、第３章Androidの開発環境構築を試してみました。

　基本的に書籍の通りで問題ありませんでした。
　ただ、いくつか誤記またはバージョン違いによると思われる、表記違いがありました。細かいところなので、支障はないと思いますが一応メモしておきます。

　試した環境は以下の構成です。
OS: WindowsXP Professional
AndroidSDK: m5-rc15
ADT: 0.4.0
Eclipse: 3.3

P87
図3.12 展開されたEclipseディレクトリ
→図の画面ではフォーカス対象を誤ってAndroidSDKのフォルダにしています。
　おそらく本来は一つ下のeclipseフォルダと思います。

P104
図3.39 表示した画面のNameに…ここでは[Android Conf]としている。
→図の画面は名前変更前でしたが、説明からすると図の画面でも変更後の「Android Conf」かと思ったので、ちょっと違和感がありました。

P105
図3.42 [Emulator]タブを選択して…
→ADTプラグインが更新されたためか、私の環境では[Target]タブになっていました。
　また、設定にAutomaticとManualの選択が追加されていましたが、とりあえずAutomaticのままとしました。

P108
Step③　ファイルの保存先設定
　[Get Device File] ダイアログが出るので保存場所を指定します。
→私の環境では[Export Package]ダイアログが出ました。

　以上です。先述しましたが、大した相違ではないので、特に支障はありません。組み込み系特有と言えるWatchdogの説明や、Eclipseのパースペクティブに関する箇所の説明が行き届いており、この書籍なら誰にでも薦められそうです。

　それにしてもデバッグツールの充実振りはすごい。DDMSといい、端末内のデバッグアプリといい、至れり尽くせりで、さすがGoogleといったところです。
　ただ、内部のLinuxを活かしている分、Linuxを全く知らないとデバッグ方法の習得には時間がかかるかもしれません。

ロギングポリシー

　ログは仕込む箇所や出力レベルを適切かつ明確に管理すべきと常々思っています。
　理由はログに出力される文字列には書式文字列が使われ、容量面や性能面でネックになりやすいからです。

　しかし、デバッグのことを考えると、場合によって出力されなくなることを避けるため、レベルを重要度の高い方に設定したりするなどで、個人任せでは徹底することは難しいと思います。

　また、あまりログを制限してしまったりすると、今度は必要なログが出力されなくなることで、デバッグが日常的に困難になったり、緊急性の高いバグについて、ログを見ても判断がつかなくなったりしてしまいます。

　そこで、単体テストや契約プログラミングを用いる場合、品質が保証できる箇所についてはログを入れる必要がなくなることを利用します。

　つまり、品質保証の確実性が高ければ高いほど、ログ出力レベルを低重要度となるようにすれば、ログを仕込むのに躊躇する必要はなく、適切にログを張り巡らせることができます。

　仮にそれでも多い場合が生じても、ログレベル単位での変更や高重要度のログのみを見直せば済むようになるため、仕込む場合に容量面や性能面を気にせず、また、デバッグ時にはレベルを低重要度に下げることで、デバッグ容易性も確保することが可能です。

　では、具体的に単体テストや契約プログラミングにより品質を保証できる箇所とそこでのログ出力頻度、出力レベルの考え方、いわばロギングポリシーについて、以下に述べていきます。