エジプト

エジプトの件はフィフィさんのが分かりやすかった。
日本のニュースもこれぐらい分かりやすく伝えてくれ。

エジプトの夜明け〜新たな一頁へ | フィフィ オフィシャルブログ「All about FIFI」by Ameba
エジプトの夜明け〜ムバラク支持派の正体 | フィフィ オフィシャルブログ「All about FIFI」by Ameba
エジプトの夜明け〜国民の想い | フィフィ オフィシャルブログ「All about FIFI」by Ameba

平鍋さんと熱く語る会

平鍋さんと熱く語る会に出て、アジャイルについて日頃モヤモヤしてたのが
少し晴れた。

平鍋さんとアツく語る会札幌2011:An Agile Way:オルタナティブ・ブログ
平鍋さんとアツく語る会2011札幌 - Togetter
『平鍋さんとアツク語る会2011札幌』に参加してきました - tricknotesのぼうけんのしょ
平鍋さんとアツク語る会メモ - KodaNote
『平鍋さんとアツク語る会2011札幌』の前日勉強会で発表しました。 - 誰も褒めてくれないから自画自賛する日記(2011-01-29)

アジャイルは≒スクラムというのが結構印象的。
XPよりスクラムに興味が沸いてきてる。

あとキッチンタイマー欲しくなった。

勉強会

先日TDDブートキャンプ参加してみた。

TDD Boot Camp 札幌に登壇させていただきました - t-wada の日記(旧)
http://d.hatena.ne.jp/shuji_w6e/20110124/1295875892
「TDD Boot Camp 札幌」にSqueak Smalltalkで参加 - Smalltalkのtは小文字です
(null)
TDD Boot Camp 札幌 - Togetter
http://memo.freedom-lite.com/?p=797
「なにをできるようにするか」から始まるTDD -TDD Boot Camp を終えて- #tddbc | ヒマジンマンガ

詳しくは他の方々が書いてるので。

TDDの面白さと難しさを実感できた。KentBeckのテスト駆動開発入門読むだけでは実感できない事が多々。

あとペアプロの生産性は凄い。新人教育に最適ではなかろうか。

そしてグリーンバンドは必需品として毎日つけて出社してます。

テストを諦めない。

すくらむ

スクラムに興味出てきたので関連リンク貼っておく。

スクラムの祖父語る「開発者は知的体育会系であれ」 − @IT自分戦略研究所
スクラムを10分以内で知ることができる資料や動画 | Ryuzee.com
スクラムとかんばんの議論、対立か両立か? - Publickey

IS01購入検討

IS01購入を検討している。
参考サイトなどを貼っていこうと思う。(随時更新予定)

Andronavi「 「IS01」を買ったら月々いくら?コストを検討してみた!」

http://andronavi.com/2010/06/28588

  1. IS01、2台目端末としてのすすめ
  2. IS01のメールサービスはどうなる?
    1. 新規契約をする場合・他社からMNPで契約する場合
    2. au携帯電話を持っていて、回線契約を増やす場合
    3. 回線は増やせないので、既存のau携帯を機種変更する場合
  3. わかりやすい料金体系で安心して維持しよう

Andronavi「au初のAndroid端末「IS01」を買うときに注意すべきポイント!」

http://andronavi.com/2010/06/28578

  1. EZ Webは使えない
  2. メールの利用に制限がある
  3. 通話にはイヤホンまたはBluetoothヘッドセットが必要

ガジェット通信「ちゃんと電話だった!auの新スマートフォンIS01』製品レビュー」

http://getnews.jp/archives/57688

  1. サイズをチェック
  2. ちゃんと通話できます
  3. 使いやすい入力インタフェース
  4. OSはバージョンアップに期待
  5. 思ったより“携帯電話”なスマートフォン

ガジェット通信「じわっと気になる!?auIS01』のアソコをチェック!」

http://getnews.jp/archives/58845

  1. ジーンズお尻ポケットには入るの?
  2. どうやって電話(通話)するの?
  3. 片手で使える?
  4. キーボードの使い勝手は?
  5. 動作速度は?

ソフトウェアアーキテクトが知るべき97のこと

読んだ。自分なりのアーキテクト像を考えさせられた。

  • ネットワークの結合、ビルドプロセスのコンフィグレーション、単体テストの作成、ベンチマークの実装など、チームメンバーが出来る事なら何でも出来る必要がある。
  • アーキテクトは、ビジネスと技術のインターフェース。優れたアーキテクトは、問題点を見抜き、チームを集め、犠牲者を名指しせず、問題がどのようなものか説明し、エレガントな解決策や回避策を示さなければならない。
  • アーキテクトは、プロジェクトの開始時点からチームに溶け込んでいなければならない。象牙の塔から命令を下すのではなく、地上に立って、チームと共に働く。
  • アーキテクトは1つのツールのエキスパートでなければならない。どのツールについても、低すぎず高すぎないレベルが必要。
  • 重複は悪。反復的な作業は開発を遅らせる。アーキテクトはその様な部分を取り除く。
  • 動くスケルトンからスタートし、動く状態を保ちながら、少しずつ育てていく。
  • 簡単な問題を複雑に解決しない。複雑なソリューションはコストが増大する可能性がある。そして元に戻すのが難しくなる。今日のところは今日の問題を解決する。時間通りにアプリケーションを引き渡し、フィードバックを待つ。本当の要件はフィードバックに含まれている。設計をシンプルにしておけば、新しい要件を組み込むのはずっと簡単になる。
  • アーキテクトは何よりまずデベロッパーであれ。自分ではコードが書けない空想家などでは無い事をデベロッパー達に示す。
  • アーキテクチャーを設計する時には、実装する為の作業量がどのくらいになるか、見当が付いていなければならない。設計するならコーディングできなければならない。
  • 勤勉さが必要。有能なアーキテクトは、知識として知ってるが実践できていない事を思い出すため、毎日、毎週のチェックリストを作り、従っている。プロジェクトが失敗するのは、能力が無いからではなく、勤勉さと危機意識が欠けているから。勤勉であるためには、約束事を作り、それを守る事が必要。約束事には様々な義務や禁止事項が含まれている。


日本人では、伊藤直也氏と小野和俊氏がデベロッパー寄りのアーキテクト像、
その他はビジネス・設計寄りのアーキテクト像という印象。


個人的にはデベロッパー寄りのコラムの方が面白く読んだ。


海外のコラムでは、アーキテクト=デベロッパーの上級職。
日本のコラムでは、アーキテクト=設計者。
という印象を持った。
「ソフトウェアエンジニア」しかない世界と、
システムエンジニアプログラマー」で分業された世界の違いだろうか。