http://itpro.nikkeibp.co.jp/ev/xdev/index.html
9/15(火)、9/16(水)の2日間の開催だったが、9/15だけ行ってきた。エンジニアライフのセッションはとても刺激を受けた!ああいうのは生で聞いた方がテンションが上がってよい気がする。
幸せなエンジニアになるための仕事術
概要
- http://itpro.nikkeibp.co.jp/article/NEWS/20090915/337264/ ← 雰囲気はつかめるかも。
- http://d.hatena.ne.jp/tmtms/20090915/1253036443 ← こっちの方がまとまっていて分かりやすい。
感想
- 勇気をもらえた気がする。特に心に残ったキーワードを挙げてみる。
- 視点として得られたもの。
- 普通に考えると不利に思えることが有利に働くこともある。例えば競争が少なかったりする。
- 現場ではウォーターフォールでも人によってはアジャイルにやっている。
- プログラミング言語を作る人は頭が良いのでシンプルなものを作ろうとするのでは。Rubyは内部はごちゃごちゃだが、外側はすっきりするようにしている。
- コンピュータにはムーアの法則が適用されるが、人間には適用されない。ので、人間にフォーカス。
- システム開発を工場にたとえると、人が機械で、その間をコミュニケーションが流れている。
- ブルックスの法則にもあるように大きなチームの時点で負け。少人数で高生産のツールを利用する。
- 量的な変化は閾値を超えると質の変化になる。例えばRailsだと15分でアプリが作れるので、客先で話を聞きながらデモを作ったりも出来る。
- 大規模だから〇〇という思い込みがあるのでは。今は1人でも大規模なサイトを作れる。
- まとめると、お二人に共通しているのは以下の点かと。見習おう。
- 常識に縛られない。思い込みをしない。
- 自分が嫌だと思ったものを我慢せずに、解決しようと取り組んでいる。
- 取り組んだものはすぐにあきらめない。
- 自分の思い込みにとらわれている部分が分かってよかった。もっと自分の心と体が求めているものに対して素直になろうと思った。あと、粘り強く取り組むことが重要なのだと納得できた。
ITpro Challenge! 2009 Light
概要
感想
- 「プログラマー最適化問題」竹迫良範氏
- 「Do You See the Light?」角谷信太郎氏
- 角谷さんが心掛けていることを見習おう。
- 自分から名乗る。
- 名札をちゃんと下げる。
- 他にも大切な言葉を聴けた気がする。
- すごくなくてもやれることはたくさんある
- 変化というよりは大切にしたいものに気づこう
- 変わらないと思い込まない。実際に話してみると、分かってもらえることもある。
- 独りじゃ生きていけないこと、ひとと関わること、ひとを信じること、我慢しすぎないこと
- 角谷さんが心掛けていることを見習おう。
- まとめ
- 聞いてよかった。午前中の時点で帰ろうかと思ったが、残っていて良かった。
- 一日の疲れが吹き飛んだ。やっぱり、こういうセッションはエネルギーがもらえる。
- 光が差したw
その他
ITパラダイムシフトにどう向き合うか クラウド・コンピューティング時代のSOAとEA
SOAから見た,クラウド時代のアーキテクチャ
- http://www.arclamp.jp/blog/archives/xdev2009_soa_cloud_report.html ← ご自身のブログでスライドを公開されています。
- 用語の定義に非常に気を遣っていた。アーキテクチャらしいと思う。
- かなり砕けた感じで、ラフにテンポよくメリハリを持って話していた。とても聞きやすかった。
- エコポイントのサイトをSalesForceがやったのは衝撃なのに共感。Sitesによってインターネット側にも画面出せるようになったので、今後事例が増えていく気がする。Force.comプラットフォームは生産性も高いしね。
- 密(データベース共有とかレプリケーション)だろうか疎(Webサービス)だろうが、スキーマの変換コストは変わらない。スキーマの変換コストを下げるにはスキーマの共通化を行うしかない。
クラウドを活用したSOA実践アプローチ
- http://itpro.nikkeibp.co.jp/article/NEWS/20090915/337270/
- プロセスと一括りせず業務プロセスと作業プロセスの2つに分けて考える。作業プロセスはある担当者レベル、業務プロセスはそれより粒度が大きい感じ。資料を見直してみたが、いまいち定義がはっきりしない。
- SOAでは 「要件定義 -> 基本設計 -> 詳細設計 -> 実装・テスト」 のフェーズを順番どおりに実施し、その中で必要な成果物をキッチリ作る必要があるとのこと。でも、その図を説明しながらアジャイルと言っていたのはなぜ?これはウォーターフォールだと思うのだが。。
RIAを生かした業務システム事例
- Sliverlightを選んだのは.NETの開発者スキルを流用できるため。
- デザインはデザイン会社に協力してもらう必要がある。
- Sliverlight内にロジックをすべて置いて2層構造に出来るが、ロジックを置き過ぎると重くなる。プレゼン層はUIロジックのみで、APサーバーにロジックを置くべき。
- 画像をクライアント側でキャッシュすると言う要件があり、ディスクを使ったところ速度が出ず、メモリを使うようにした。
Silverlight×ExpressionでRIAフロントエンドを「創る」
- 概要
- http://itpro.nikkeibp.co.jp/article/NEWS/20090915/337281/
- RIA開発の課題は以下とのこと。どれも当たり前のことだが新規技術を導入する際は改めて確認すべきことだろう。
- RIAではシステムとデザイナーのチームを分けていると上手く機能しないので、統合したチームにすべき。そこではシステムだけでなくデザインにも目を配れるインフォメーションアーキテクトが必要。
- チーム内の役割分担が重要。
- UI設計は簡単ではない。
- ExpressionBlendのプロトタイプ作成機能であるSketchFlowには手書き風のフォントが存在する。これは一般的なフォントだときれいなため完成された印象を受け、アイディアが浮かばなくなるためとのこと。
- 感想
- チーム内の役割分担が重要とのことだったが、これって結構大変で、悪く転ぶと責任を押し付け合いになる。そういう意味で、アジャイルにおいて担当者ではなくチームで取り組むと言うのは、計画を立てることが困難なことを受け入れるのと同様に、役割分担を明確にすることが困難なことを受けれているのだと思った。
- SketchFlowで手書き風フォントがあるのが興味深かった。確かに書き易さというか自由度でノートに勝るものはない訳で、将来的にはキーボードとタブレットを統合したようなデバイスが出てくるのだろうか。文字の入力はペンよりキーボードの方が早いから、タブレットだけだと困るかな。それとも、まったく現在と異なるインタフェースのデバイスが出てくるのかな。
まとめ
- ライトニングトークとか対談とかはエネルギーをもらえる。
- SOAとかSilverlightとかいった概論や技術、製品の話は普段から情報収集していれば知っている程度の内容である。そのため、知らないテーマについて聞きに行くべき。
- 聞いていて疲れたセッションは話す内容にメリハリがない気がした。スライドに書いてあることは一瞬で読めるのだから、書いていないことを中心にテンポよくメリハリを利かして話す必要があると思った。
- 来年はエンジニアライフだけ参加かな?
- 日記書くのに時間かけすぎ。ノーパソ買って、その場である程度書くようにした方がいいのかしら。