場所は昨年と同じ目黒雅叙園。セッション参加方法も同じでバーコードチケットを受付で何枚か貰って入り口でポイっと入れる感じ。ということで、申し込んでいないセッションでも受けられます。
さて、恒例の女性チェックですが...少なかったですが、5%くらいはいたかなぁ？
後の客層としては、思った以上にオジサン多し。
定年を過ぎたような60,70代の人も多かった気がします。そして...若い人が少ないっ！デブサミなのにぃ〜〜
若い人はこぅいぅセミナーに参加できる権限とか暇がないのかもしれないですが、上司の方々はもっと行かせてあげて欲しい。それとも、ホントに若い人がこの業界に来てない結果?!?!
では受けたセッションの報告をば。
デブサミ開催の挨拶
最初に受けたDのセッションは和田氏がコンテンツ委員ということで、和田氏の開催の挨拶から始まりました。
「時代はぐるぐる回っているようにも思うが、同じ所ではなく少しずつ進歩しつつ違う道を進んでいる...螺旋のように」
というお話があったんですが、螺旋はいい喩えだなぁー。昔の事を伝える事により、新しい道が少しでも上に進んでくれるといいなぁとも思うし、昔と一緒だから...と無駄な事はないし、調べる必要がない なんて事はない。絶対何かは違うから。
あと、「若い人に刺激を与えて欲しい」という言葉もあったんですが、人ってちょっとした刺激を与えられただけでガラっと変われるもんだよなぁーって最近感じた事でもあります。
【12-D-1】
クラウドによるソフトウェア開発パラダイムの進化
マイクロソフトの萩原氏の講演でした。
Azureの紹介とともに、
クラウドではN-tierモデル(UI/Logic/Data)は時代遅れだ。
クラウドは即時一貫性よりもスケーラビリティを優先するため、銀行業務のようなものは使えない。
2フェーズコミットは使えない。ルーティングする。
ロードバランサを使ってもRDBでボトルネックになる
...などの内容でしたが、私としては「Googleを支える技術」の本を読んでいるぐらいで十分だったかなぁ。
【12-C-2】
未来へつながる言語〜ある言語おたくの視点から
まつもとゆきひろ 氏ということもあり、すっごい人！！立ち見がいました。
しかし...最初の話が "そんなに役に立つ話をしませんが、みなさん本当にこのセッションでいいんですか？" ... ええ、iPhoneの座談会に行けば良かったんですよねぇー
実は、その前のセッション時間でもObjectiveCのものが有ったんですが、shin1ogawaが取ってるから違うセッションを取ったんですよ。でもshin1ogawaは行けなくなり...すっかりObjectiveCのセッションを忘れており...申し込んだセッションに素直に行ってました。失敗ww
まつもとゆきひろ氏のものを取ったのは、一度も講演を聞いた事がなかったからどんな人なんかなぁーって思いまして。
プログラムが大好きな明るい言語オタクって感じでした(笑)
内容としては、一番古い言語は？ から始まりました。ドイツの人が作ったものだったらしいんですが、難しすぎて使えず。。その開発者もそれでプログラム書いて実行はできず。。始めて実行したのは大分先だったこと。
一般的に古い言語はCOBOL, FORTRAN, LISP...とあるけど、どれもまだ廃れ切っていない事。
今まで多数の言語が生まれたけど、残ったものを見るとポールグレアムの「簡潔さ」という言葉が的を得てる事。
これからはHuskell,Erlang,APLみたいな関数型言語が...という話でした。あ、Rubyもww
【12-A-3】
時を超えたプログラミングの道への道
角谷 氏のセッションでした。
セッション資料が早々にUpされているようです。角谷HTML化計画
始めに...
ビューティフル・コード の 竹内預言
プログラムを書いた事がないシステムエンジニアが威張っているような会社は早晩滅びる
早晩滅びたくないので、しっかり考えます(笑)
「時を超えたプログラミングの道」というのは、KentBeckのExtremeProgramingExplainedの23章の題名。それへの道ってセッションでした。
この題名...アレクサンダーという建築家の人の本、「時を超えた建設の道」のパクリ(?)
この本の中身っつーのは、もぅXPそのもの。
残念ながら、このアレクサンダーのXPはあまり上手く行かなかったらしいんですが、ソフトウェアではマッチするかも...とKentBeckが紹介したらしい。
調べる人はいずれはアレクサンダーの本に気づくだろうしという事で、公然の秘密だったよう。そこまでたどり着いた人へのある意味ご褒美だった？
『道』という言葉には 始まりと終わり という意味があるようです。いわゆる陰と陽。陰があるから陽があるし、陽があるから陰もある。
XPは、"技術"と"ビジネス"の調和/バランスを取る事が重要だが、これも陰と陽。どっちも必要。"コード"と"ドキュメント"の関係や、"テスト"と"設計"というのも一緒。
これからこぅいぅ手の話がでたら、陰陽マークが頭に現れてきそぅ。。
石井勝さんのmasarl預言もその後に出て来たりしましたが...そう...石井勝さん。
昔、有名な人とは知らずにメールを出した事があったんですよ。石井さんのサイトでめっちゃ納得するいい記事があって、それをブログで紹介してもいいですか？っていう。
そぅしたら快くOKもらって...その返事を書いたら...またメールを頂いて...再度返信書いたら...またメール頂いて...(ループ)。
その時の私は、ほんと与えられた開発をしてるだけのペーペーな感じで、メールの返信もめちゃくちゃな内容だったんちゃぅかなぁー？って思うんですが、返す度に長文のコメントを毎回貰いまして...今思うとホント凄い方でした。
無名のペーペー開発者に対して、そんなに時間を割いてメールって書けます？？
自分自身には得な事なんて無いのに。
その時にお世話になった事は忘れず、周りの人に還元していかなければっ！って思います。。
【12-A-4】
Eclipse-Way ：分散アジャイル開発のためのプラク…
IBMの藤井氏の講演でした。
Jazz、TeamConcertに絡んだ、分散開発について触れられていました。
・1チームは1拠点。
・コンポーネントベースでの開発で、チームはまたがらない。
同じ場所にいるチーム内では、目が届くのでリカバリも比較的容易。
外のチームや、離れているチームは心配だが...その対応として
・ビルドの単位を開発者単位、チーム単位、複合チーム単位に切り分ける
・実験用コードは本コードを汚さない場所で置く事ができるようにし、外の人が見るときにも環境構築が楽になるようにする
・CheckInは完了基準を満たしてないと行なうことができない
というのをあげられていました。
CheckInは完了基準を満たさないとできない....というのは、目的は良くわかるんですがローカルで作業を長時間したくないってのもあるので、一旦保存できる場所は絶対欲しい。
ブランチ切ってやればいいんでしょうが...なんかマージも面倒なイメージもあって...もっと手軽にできないかなぁ。
イメージとしてはGitっぽく、まずは個人用のものをちょこちょこコミットして、キリが良い時点で共有領域にコミット...ってしたい。
でも個人用のコミットというのも、ローカルに持ちたくない。
ここらへん、上手くやる方法ないんかなぁー
スキルのバラつきはどうしても発生する。
そんなメンバーで「作業の標準化」なんて意味がない。
なので、
・チーム独立化
・無駄を排除する (環境再構築などのロスを最小化)
・完了基準の集合体へ
という形でシメられてました。
【12-D-5】
M + MVC 〜最新マイクロソフトWeb 開発動向 Ruby on Rails に追いつけ！追い越せ！〜
アークウェイの森屋氏 + 黒子の方でのLiveCodingでした。
当初はこのセッション取る予定でなかったんですが、疲れて来たのでLiveCoding見に行きました(笑)
M というのは、モデリング言語(DSL)。Osloはそのリポジトリ。
Mでスキーマ定義、挿入データの情報を記述してコンパイル、DB保存とするとDBにデータが格納。
VisualStudioからスキーマからデータモデルを作り、Viewを作り...というLiveCodingになってました。
印象的だったのは、このアークウェイの方々のやり取り。あー仲いい会社なんだろーなぁーって伝わって来て、ほのぼの雰囲気満載でした。
【12-A-6】
オブジェクト指向エクササイズのススメ
オージス総研の方の講演でした。
内容は「ThoughtWorksアンソロジー」の本の5章の内容になっていました。
この本...家に有るんですがまだ読んでなかったんですよね。早く読まないと。。
さて、5章 オブジェクト指向エクササイズとうのは、「オブジェクト指向」を強制的に身につける為のコーディング規約で、結構厳しいのがそろってます。
ですが...どっちかというと、チャレンジ！系のもので絶対守らないといけないってものではないのかと思います。
昔、オブジェクト指向を学ぶために if文無し でコードを書いてみよう！ってした事があったのを思い出しました。
このコードをネタにして皆でやってみよー！って勉強会があってもいいかも。9のメソッドを書いておきます。
- 1つのメソッドにつき1インデントまで
- else句を使用しないこと
- プリミティブ型、文字列はラップ
- 名前を省略しない
- 全てのエンティティは小さく(メソッドは50行以内、パッケージは10Entity以内)
- 1行につき1ドットまで
- Gettetr,Setter,プロパティを使用しない
- 1クラスに付きインスタンス変数は2つまで
- ファーストクラスコレクションを使用すること
【12-A-7】
「使う」と「作る」がつながるシステム開発
平鍋氏がモデレータで、倉貫氏、千貫氏(UFJISのシステム部門の方)、橘氏(TIS)でのディスカッションでした。
題材としては、
・「使う人」と「作る人」というのには溝があるよねー。その溝を埋めないとダメだよね。
・SIerって本当にいるの？
のが大きな所でした。
平鍋氏が海外に行った時の感想として、日本に比べて「使う人」と「作る人」は近くに感じた。じゃーなぜ日本は...? SIerという構造のせいなのか...?というのがあったらしく、この場を設けたらしいです。
議論は色々迷走してましたが、結局 "お互いコラボをするには利害関係(共通のゴール)が一致しないと難しい"って事かなと。
情シスでも、現場と情シスでは上司が違うために個々人の利害関係が一致せず上手くいかないという話をされていました。
同じ会社内であれば、大きな目線からみると"会社にとっていいものを作る"って利害は一致するようにも見えますが、個々人のレベルまで落とすと上司が違うから、利害は一致しないんですよね。
ユーザが自社で開発者を雇えば...って話もありましたが...
SIer体制ができた背景には、
会社内でシステムを作る → 専門部署を作る → コストがかかるので自社以外の開発もする → 別会社にする → コスト削減のために外注を使う
ってあるんですよね、多分。
お互いが遠く離れすぎて上手くいかないー！という解決のために、また会社内にシステム部を戻す...コストが...ってなって、またループしそぅww
話の中では、SIerの意義として、「分解」することができるというのが出てました。
でもそれって、技術の専門知識がないと出来ない事ばかりでもないよね？
間に会社が一つ入る事によるデメリットは、それをカバーできる位のものとは思えないんだけど。
製造業でのコストに比べて、IT業でのコストはメチャクチャ高いって話もあったけど。。
確かにそう思うけど、比較できるもんなんだろーか。
例えば、マグカップの取手が四角だけど丸がいいなぁーって思ったとしても、まぁそれは我慢できるレベル。なので既製品でも全然OKって思う。
でもソフトって、少しの改善をするだけで、めちゃくちゃ効率が上がる事がある。それが、開発者が2時間くらいで作れるものだってあって、そういうのはやっぱり作って喜んでもらいたい！って思う。
でも人のコストって高いから、やっぱり高くなるよね。。
でー どこが落ち着きどころって思うと、Saasって解決策は有るとは思う。
既製品と、オーダーメイド というのをユーザは選べるというのはいいよね。
ただ、データはずっと管理して行きたいために、一度買った既製品は、ずっと使い続けるor同じ会社の製品を買う ことをしないといけないのが、二の足踏む所ですよね。
データ部分は常に変わらない所を利用していて、Viewの部分を色々選べるぐらいだといいんですけどもねー。
ということで、結論を出すのは難しい話題ですが、日頃考えなら仕事をするって事自体、大切な事だと思います。。
ということで1日目終了です。
明日は残念ながら参加できないんですよねー。