Sooey

2011-10-25 18:19:52 +0900

ダメなデイリースタンドアップについて。

CarbonFiveのブログにWhy Your Daily Standup Sucks (and how to fix it)といういいエントリがあったので、ポイントを簡単に訳して紹介しておきます。

  • 詳細を話しすぎる
    • 誰かが詳細を聞きたがったら、それはスタンドアップの後で話し合え
  • みんな準備不足
    • 毎日同じ時間にやることがわかっているのだから、準備をしたうえで時間通りに参加しろ
    • スタンドアップの前に記録した作業時間、コミット、作業中のストーリーを確認しておけ
  • 問題解決しすぎ
    • デイリースタンドアップでは状況のアップデートだけをせよ
    • 議論や問題解決をするときではない
    • 合言葉は"take it offline"
  • 障害を取り除こうとせよ
    • スタンドアップの「あと」で障害に取り組め
    • 誰かから「それについては力になれるよ」と聞ければ充分
    • ホワイトボードをスタンドアップの場に持ち込んで時間を無駄にしないこと
  • 開始が遅すぎる
    • デイリースタンドアップはあなたの1日を始めるためのもの
    • 開発者はスタンドアップが終わるまで作業に取り掛かれないこともあるので、早めに時間を見つけることが重要
  • 傍観者によるコンスタントな割り込み
    • スタンドアップには関与せず、進捗確認のために傍観するだけの人がいることもある
    • 傍観者はたいていスタンドアップに精通した人ではないので、彼らがスタンドアップに割り込まないようルールを伝えておくこと
  • ツールに頼りすぎる
    • Pivotal Trackerのような外部ツールを使わないようにすること
    • スタンドアップは作業中のストーリーについてレビューをする場では「ない」
    • ツールを使うことで気がそれて、フォーカスを失い、時間を無駄にしてしまう…ということは容易に起こる
  • シンプルに保つ
    • スタンドアップの長さは15分以内
    • 効果的なスタンドアップとは、12人が発言するかなり大きなチームでも10分もかかからないもの

2011-10-25 18:18:18 +0900

10月25日の気になったURLメモ。

HerokuのRyan Smithさんによるスライド。かなり端的な内容なのでHerokuを実際に使っていない人にはスライドだけだと理解しづらいかも。

つまり、再利用しやすい関数をつくろうとすると、意図が抜かれるということだ。そうやって作られた関数の名前は、意図を反映しない名前になる。 そうすると、呼出側では、コメントで意図をあらわすことになる。

コマンドクエリ責務分離(CQRS:Command and Query Responsibility Segregation)パターンについて。

まずは、DTOを受け取った後で通常何が起こるのかを考えましょう。ユーザはデータを変更し、それをDTOに戻します。その際、このDTOはバックエンドに送り返され、エンティティに変換された上で、その変更がデータベース上に永続化されることはORMによって保証されます。

この結果、きわめて重要な情報が失われることになります。すなわち、なぜその変更が起きたのかということがです。データを変更した際にユーザが持っていた意図が完全に見失われてしまうこと、それがGregのCQRS実装によって解決される問題です。

OAuthのダイアログのようなポップアップウィンドウをCucumber/Seleniumで制御する。

このデータは様々な使い方ができますが、重要なのは歴史の記録がデジタル化されたということです。Googleは千5百万冊デジタル化しました、かつて出版された本の12%に相当します。人類の文化の大きな塊です。文化には違った形のものとして手稿や新聞があり、テキストではない芸術作品や絵画があります。これらすべてが世界中のコンピュータの中にあるところを考えてください。そうなったとき、私たちが過去、現在、未来や、文化について理解する方法は変わるでしょう。

Backbone.jsでのアプリケーション開発手順が学べるスクリーンキャスト。通常$18が11月1日までは$9。

2011-10-25 11:21:58 +0900

2011年10月25日のURLメモ。

HTML文書をインタラクティブに操作できるようにするためのJavaScriptライブラリ。なんとも説明しづらいのでサンプルを触ってみてください。

Adaptive Pathの主催で今年の8月に開催されたUX系のイベント UX Week 2011のビデオが公開されました。

『アジャイルな見積りと計画作り』のMike Cohn氏によるブログエントリの和訳。

「エピック」は大きなストーリーにつけるラベルにすぎない。あるストーリーをエピックと呼ぶ場合、追加の意味あいを伝えることになる。いまあなたが、私が昨日、システムの月次報告の部分に関するユーザーストーリーを書いたかどうかを、聞きにきたとしよう。「ええ。でもほとんどはエピックです。」と、私は答える。この場合、書くには書いたが、すぐ実装できそうなくらいのブレークダウンはできなかった、という事を意味する。

2011-10-14 14:02:15 +0900

Emacsでflymake自体がエラーとなる場合にどうやって原因を突き止めたものかとflymake.elを読んでみたら、

(setq flymake-log-level 3)

としておくとデバッグログが*Messages*に出力されることがわかった。

2011-10-13 11:47:13 +0900

New Relicからのメールマガジンで気づいたのだけど、HerokuのNew Relicアドオンがパワーアップしてた。

以下のように新たにDynosタブが用意されて、HerokuのDynoに関する情報が視覚化されるようになりました。

New Relic Heroku Addon | Flickr - Photo Sharing!

Background tasksタブではDelayedJobなどのバックグラウンドタスクの負荷も見えます。

New Relic Heroku Addon | Flickr - Photo Sharing!