2011-07-19 00:40:12
最後の日本 RubyKaigi です.
出張の関係で 2 日目の終盤からしか参加できていませんが, 印象に残ったものを簡単にまとめてみました.
Advancing Net::HTTP by @wycats さん
* net/http は並列化できない
* 並列化するためにフォークして net2/http というのを作っている
* 並列化するにあたって Reactor パターンを採用した
ergをすごく偲んで by @m_seki さん
* カスタマイズは誘惑する
* 安易にオプションを増やすことは「仕様の議論からの逃避」
Visual Glitch, using Ruby by @ucnv さん
* とっさにグリッチが必要なときは sed が便利
* チェックサムを壊したりすると表示自体できなくなることがある
* 安全にグリッチするにはどうするか
* 仕様に従って壊すのがマナー
* 動画はキーフレームを抜くことでいい感じに壊せる
ネタ的な発表かと思いましたが, 技術的には思いのほか真摯であり, とても参考になりました.
発表者の方は GitHub に aviglitch というライブラリを後悔されていますが, API, ドキュメント, spec など, あらゆる面で well-mannered な印象です.
純粋に, Ruby でカジュアルに低レベルなバイナリ操作をする上で参考になりそうです.
Ruby遺産とレガシーコード修理技術 by @hsbt さん
* tDiary のコミッタ
* tDiary は 25 年使われる予定
* 既に 10 年使われている
* 各レイヤごとのテスト
** ユニットテスト
** エンドツーエンドテスト
** インテグレーションテスト
* 機能の追加は慎重に削除は大胆に
** プログラマが知るべき97のことにおける @miyagawa さんの言葉
* 継続的インテグレーション
** travis-ci を使えば GitHub リポジトリで CI できる
長期にわたってソフトウェアを育ててきた経験に基づく, 実践的なお話.
機能の追加に慎重になる, というのは, 特に業務だといろいろなしがらみがあって難しいけど, 常に意識して行きたいものです.
No と言える力重要.
O/R Mapper を支える技術 by @makotokuwata さん
* プログラミング言語の機能は分解, 結合, 抽象化
* SQL にはそれらが欠けている
* それらを補完するのが O/R Mapper
* Ruby で SQL を組み立てること自体は抽象化ではない
* named_scope で抽象化しよう
* プログラミング言語の進化は抽象化機能の進化
* モダンな O/R Mapper の機能
** QueryObject の操作
** Collection のように振る舞うこと
** SQL の抽象化
* N + 1 問題
** DataMapper の Eager loading はうまくやっている
去年ぐらいから仕事で O/R Mapper 的なものを PHP で実装していることもあり, 実装寄りの話では一番参考になりました.
スピーカーの桑田さんのお話は去年の Kwartz についてのものもそうでしたが, 洞察に溢れているだけでなく, 非常に明瞭でわかりやすく, とにかく引きつけられました.
まとめ
昨年から引き続き参加しましたが, レベルの高い技術者の考えに触れることができ, 多いに刺激を受けました.
また, 英語を使いこなし, 海外からの参加者と対等にコミュニケーションを取っている方も多く, その店でも自らの力不足を実感させられました.
スピーカー, スタッフ, 参加者の皆様, お疲れさまでした!
2011-07-07 08:59:31
日々なんとなく利用している Redmine ですが, ここらで一度振り返ってみることにしました.
一応一般論のつもりで書いていますが, 前提として以下のような環境を想定しています.
- メインとなるメンバーが 5 名前後の小規模なプロジェクト
- そのうち何名かは非エンジニア
目新しい話は無いと思います.
様々な機能を使い倒していたりもしません.
あまり学習・運用コストをかけずに, いかに効率よく使うか, という方向性です.
ルールは少なく
チームの全員が Redmine に対して肯定的であることは稀です.
Redmine よりもメールや Excel で管理したい, という信じられないことを言う人も少なくありません.
そんな人たちも含むであろうチームで Redmine を楽しく運用するには, とにかくルールを簡単にすることが大事だと考えます.
優先度, 予定工数, カテゴリなど, 記入できる項目はたくさんありますが, その全てについてルールを設け, 意味を理解しない状態で記入させることで, 一体何が得られるでしょう?
まずは最低限「作業依頼はチケットに書く」ということだけ守ってもらうだけで, ToDo 管理にはなります.
最低限のラインでもいいので, とにかく Redmine を使い続けていると, 段々と不便さが気になりだします.
そういう不便さがチーム内で明確になってくれば, 各項目を細かく記入する意味もわかってくるので, そこで初めてルールを決めましょう.
と, ここまでルールという単語を使ってきましたが, 基本的には文化として自然に醸成されていくのに任せるのがいいと考えています.
プロジェクトの大規模化・複雑化などといった事情が無い限りは, ゆるく柔軟に運用していきたいものです.
これは XP における YAGNI の原則にも通じると思います.
期日を記入する
ToDo 管理としての Redmine から一歩先に進めるとしたら, まずはここから始めるのが効果的だと思います.
チケットに期日を入れることで, Redmine の重要な機能であるガントチャートにタスクが表示されるようになります.
ガントチャートを活用することで, 進捗状況は一気にわかりやすくなるので, これはエンジニア以外の人にも比較的理解されやすい機能だと思います.
また, 期日はチケットだけでなく対象バージョンにも設定できます.
こちらでは, より大きな単位で, ざっくりと俯瞰できるようになります.
[caption id="attachment_1206" align="alignnone" width="300" caption="チケット期日設定無し"]
[/caption]
[caption id="attachment_1209" align="alignnone" width="300" caption="チケット期日設定あり"]
[/caption]
[caption id="attachment_1210" align="alignnone" width="300" caption="対象バージョンにも期日設定"]
[/caption]
ゴールを明確に
どこまでやればそのチケットをクローズできるのかが明確になるように, 注意を払います.
依頼者と作業者の意思疎通を明確にするためです.
逆に, ゴールが明確になりにくい議論をチケット上で繰り広げても, よくわからないうちに流れてしまいがちです.
議論には, チケットよりもフォーラムを活用するのが好ましいと考えます.
もちろん, Redmine を離れて実際にミーティングするのもいいでしょう.
議論の中でやることが決まったら, そこで初めてチケット化しましょう.
チケット名が「~~~ について」といった曖昧な形式になっているのは, 良くない兆候です.
多少説明的でも, チケット名だけで作業のイメージができるような命名を心がけましょう.
名前重要.
まとめ
Redmine はとても魅力的なソフトウェアですが, 導入コストは決して安くありません.
まずは無理なく使い, 楽しくタスク管理ができるようになることが大事だと思っています.
今回はタスク管理ツールとしての Redmine に着目し, 最低限のルールで効果的にチケット機能を利用する方法を紹介しました.
See also
2011-05-28 15:05:53
jQuery で Ajax リクエストを行う場合, パラメータはハッシュ (JavaScript の Object 型) で指定して実行します.
この例だとまだシンプルに見えますが, success コールバックなどが肥大化してくると, 見通しが悪くなってきます.
そこで以下のようなコードを用意します.
jQuery.ajax() のラッパーとなる FluentAjax オブジェクトと, それを呼び出すヘルパーとして fajax() 関数を定義しました.
メソッドの定義にはメタプログラミングを使用しており, 実質上のプログラムは約 30 行程度です.
これを利用すると, 同じ Ajax リクエストを以下のように行うことができるようになります.
メソッドチェインでリクエストオプションを組み立てていき, 最後に execute() メソッドでリクエストを実行しています.
いわゆる Fluent Interface (流れるようなインターフェイス) になっていると思います.
メソッドチェインを使った方が可読性が高い... かどうかは好みの問題かもしれませんが, ひとつのサンプルとして.
これをもう少し抽象化すれば, 1 つのハッシュを引数にした複雑な関数は, 何でも Fluent Interface にできそうですね.
See also