エジプト
エジプトの件はフィフィさんのが分かりやすかった。
日本のニュースもこれぐらい分かりやすく伝えてくれ。
エジプトの夜明け〜新たな一頁へ | フィフィ オフィシャルブログ「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のテスト駆動開発入門読むだけでは実感できない事が多々。
あとペアプロの生産性は凄い。新人教育に最適ではなかろうか。
そしてグリーンバンドは必需品として毎日つけて出社してます。
テストを諦めない。
数年ぶりにJavaやる
のでSpringとかDIとか勉強しよっと。
以下参考にする。
http://www.amazon.co.jp/dp/4774123412/
DI:依存性の注入とは何か? (1/3):Spring Frameworkで理解するDI(1) - @IT
IS01購入検討
IS01購入を検討している。
参考サイトなどを貼っていこうと思う。(随時更新予定)
Andronavi「 「IS01」を買ったら月々いくら?コストを検討してみた!」
Andronavi「au初のAndroid端末「IS01」を買うときに注意すべきポイント!」
http://andronavi.com/2010/06/28578
- EZ Webは使えない
- メールの利用に制限がある
- 通話にはイヤホンまたはBluetoothヘッドセットが必要
ガジェット通信「ちゃんと電話だった!auの新スマートフォン『IS01』製品レビュー」
http://getnews.jp/archives/57688
- サイズをチェック
- ちゃんと通話できます
- 使いやすい入力インタフェース
- OSはバージョンアップに期待
- 思ったより“携帯電話”なスマートフォン
ガジェット通信「じわっと気になる!?au『IS01』のアソコをチェック!」
http://getnews.jp/archives/58845
- ジーンズお尻ポケットには入るの?
- どうやって電話(通話)するの?
- 片手で使える?
- キーボードの使い勝手は?
- 動作速度は?
ソフトウェアアーキテクトが知るべき97のこと
読んだ。自分なりのアーキテクト像を考えさせられた。
- アーキテクトは、ビジネスと技術のインターフェース。優れたアーキテクトは、問題点を見抜き、チームを集め、犠牲者を名指しせず、問題がどのようなものか説明し、エレガントな解決策や回避策を示さなければならない。
- アーキテクトは、プロジェクトの開始時点からチームに溶け込んでいなければならない。象牙の塔から命令を下すのではなく、地上に立って、チームと共に働く。
- アーキテクトは1つのツールのエキスパートでなければならない。どのツールについても、低すぎず高すぎないレベルが必要。
- 重複は悪。反復的な作業は開発を遅らせる。アーキテクトはその様な部分を取り除く。
- 動くスケルトンからスタートし、動く状態を保ちながら、少しずつ育てていく。
- 簡単な問題を複雑に解決しない。複雑なソリューションはコストが増大する可能性がある。そして元に戻すのが難しくなる。今日のところは今日の問題を解決する。時間通りにアプリケーションを引き渡し、フィードバックを待つ。本当の要件はフィードバックに含まれている。設計をシンプルにしておけば、新しい要件を組み込むのはずっと簡単になる。
- アーキテクチャーを設計する時には、実装する為の作業量がどのくらいになるか、見当が付いていなければならない。設計するならコーディングできなければならない。
- 勤勉さが必要。有能なアーキテクトは、知識として知ってるが実践できていない事を思い出すため、毎日、毎週のチェックリストを作り、従っている。プロジェクトが失敗するのは、能力が無いからではなく、勤勉さと危機意識が欠けているから。勤勉であるためには、約束事を作り、それを守る事が必要。約束事には様々な義務や禁止事項が含まれている。
日本人では、伊藤直也氏と小野和俊氏がデベロッパー寄りのアーキテクト像、
その他はビジネス・設計寄りのアーキテクト像という印象。
個人的にはデベロッパー寄りのコラムの方が面白く読んだ。
海外のコラムでは、アーキテクト=デベロッパーの上級職。
日本のコラムでは、アーキテクト=設計者。
という印象を持った。
「ソフトウェアエンジニア」しかない世界と、
「システムエンジニア/プログラマー」で分業された世界の違いだろうか。