デブサミ2009に行ってきました

devsumi2009

(3月8日追記)セッション資料が公開されました。Developers Summit 2009 セッション資料ダウンロードサイト。公開期間は2009年3月2日（月）〜2009年5月29日（金）だそうです。

2月13日にDevelopers Summit 2009の2日目のセッションを聞きに行ってきました。以下、メモと感想です。

【13-A-1】これからのWebテクノロジーを予測する

資料はプレゼンテーションファイル置き場で早速公開されています。

  • OpenID
    • Webに特化したSSO
    • メガサイト側は美味しい
    • 利用する側は目立ったメリットが見えにくい
  • エンタープライズへの適用
    • 簡易なSSO等に使われる可能性
    • 社内複数サービスの連携
    • 社内と社外の連携
    • システムの疎結合
  • CGM
    • 監視が売りになる
      • 今は人力
  • 次に来るのは何か？
    • Yahoo!がWebを支配すると思っていた→10年以下の覇権
    • 次は必ず来る
    • アイデアだけではなく実行力
    • 何でも作ってみること、公開してみること

上記はかなり省略していて、実際はもっといろいろなキーワードが出ていました。

OpenIDの利用する側のメリットですけど、個人的にはメリットがあるかなと思っています。OpenIDを使ったサービスを作る立場からすると、パスワード情報を持たなくても認証が必要なシステムが作れるというところ。セキュリティの対策をすると言っても失敗する可能性はあるわけで、やっぱり情報を持たずに済むというのは助かります。

OpenIDを使ったサービスを利用する立場からすると、パスワード増やさなくても済むのが助かります。そのサービスがパスワードを適切に扱っているかなんて分からないのでサービス毎にパスワードは変えているのですけど、これだとパスワードを覚えきれないのですよね。

簡易SSOにOpenIDという話がありましたが、エンタープライズ用途でしたらSAMLはどうでしょうか。Google AppsとSalesforceが対応しているので、売り込みやすい気がします。

【13-B-2】パネルディスカッション：クラウド時代のプログラミングスタイルを語り合おう

  • Google App Engine
    • Webアプリ専用
    • インフラを意識しなくて良い
    • 自動でスケールする
      • BuddyPoke!は2,850万人
  • Salesforce
    • GeekとSuiteの間
    • ただのギークではいられない。お客様の成功を考える
    • 実証されたプラットフォーム
  • Microsoft
    • Azureサービスプラットフォーム
    • メッセージ・キューイングの非同期トランザクションでスケールさせる
  • IBM
  • データベース
  • プレイヤーの変化
    • お客様の成功のためにお客様の業務を知る
    • インフラの安定性は気にしなくても良い
    • インフラは構築するものだったのがそうでもなくなった
      • インフラ屋さんの数は減る
    • DBエンジニアの売りの一つにスケールさせることがあったが、勝手にスケールするので売りにならなくなる
  • クラウドによって
    • 新しい仕事ができてくる
      • 従来の置き換えではない
      • コストが下がって適用範囲が増える
      • できなかったものができるようになる

後半のディスカッションの方が面白かったのですが、前半の紹介部分が長くてあまり時間が残っていなかったのが残念なところ。

Salesforceの人は他の人と比べるとかなりビジネス寄りの印象がありましたが、実際は対開発者にも重点を置いていると思います。少しSalesforceでの開発について調べたことがあるのですけど、ドキュメントがしっかりしている印象があります。VisualForceやApexを使えば割と何でもできるようになっていますからね。

インフラをあまり気にしなくても大丈夫になるのは個人的にはうれしい変化です。インフラ構築は全然経験がなくて分からないんですよね。あと、サイジングについて今よりもシビアに考えなくても良くなりそうなのも助かります。

【13-E-3】Hudson によるインクリメンタルな開発

  • 頻繁にビルドしろ
  • CI(Continuous Integration：継続的インテグレーション)がなぜ広まらないのか？
    • 大変だから
  • 有効なケース
    • 多人数
    • 分散開発
    • 複数の実行環境
  • Hudsonとは
    • オープンソースのCIツール
    • チェックアウト・ビルドスケジュール管理・通知・レポーティング・ログの保存
    • SCM(Source Code Management)ツール、ビルドツールをいろいろ選べる

CIはやった方が良いと思いつつやっていないんですよね。いいわけになりますけど、仕事では自分でソースを書かないどころか、自社でほとんど開発していないですからね。今後はひょっとしたら内製化にシフトして自社で開発するケースが増えるかもしれないので、その時はチャンスかも。

【13-B-4】Java VMへの処方箋 〜先進のメモリ管理技術とは〜

  • 扱うデータサイズ増大→64bit化で対応できる→Full GCに時間がかかる
  • セッション情報はOld世代領域にたまる
    • ログアウトしても残る
    • Full GCの原因になる
  • 明示管理ヒープ管理方式を追加
    • セッション情報はこちらで管理
    • ログアウト時に解放する
  • 業務プログラムの改修不要
  • 性能への影響は1%未満(具体的な数字は忘れた)

Webアプリケーションの特徴を上手く取り入れた方式ですね。アイデアだけならいろいろな人が考えそうですけど、実装して実用になるところまで持ってきているのはすごいのではないでしょうか。

JavaのGCの話が出るといつも思うのですが、.NETのGCはあまり話題にならないですよね。何ででしょうか。

【13-A-5】CodeZineスペシャルセッション　モダン Perl テスト 〜 テストで業務効率改善

  • 単位テスト(単体テストのことかな)
    • 自動化しやすい
      • コストパフォーマンスが高い
  • テスト≠追加作業
  • 前提：人は必ず間違いを犯す
  • デバッグとテストの違い
    • デバッグ＝対症療法
    • テスト＝予防
      • 将来への投資
  • 現実的な落としどころ
    • 80%
  • テストと呼べるのは再現性があるものだけ
  • 手動テストの場合
    • たとえばExcelファイルで作った項目の羅列
    • テストクオリティが作業者に左右される
    • テスト内容のノウハウが口伝で蓄積されない
    • テスト実行に工数がかかる
  • 自動テストの場合
    • 誰が実行しても結果が同じ
    • テスト実行コストはほぼゼロ
      • 自動化するまでにはコストがかかる
    • バグを見つけたらテストスクリプトを追加
      • 同じ間違いが起こらない
  • テスティングフレームワークは覚えるためのコストが高い
  • 現実の世界
    • 仕様がメタメタ→無理矢理テスト
  • テストの価値
    • テストが存在すること＋テストが機能すること
    • 柔軟性重要
  • そこでPerlですよ
    • テスティングフレームワーク標準装備
    • シンプルに書ける
      • 各種モジュール
    • proveコマンド
    • TAP(Test Anything Protocol)
    • WebアプリのテストもOK
    • 現実的な落としどころ
  • JPA(Japan Perl Association)の宣伝

現実問題として、Webアプリケーションの場合にブラウザから動作を確認するしかできないような作りになっているコードが多かったりするので、メソッド単位でのテスト自動化はあきらめて画面単位のテストを自動化するところから始めるというやり方もあるのかも。

この場合開発言語の影響は少なくて、Javaや.NETで作成されたシステムだったとしてもPerlを使ってテストができますしね。セッションではSeleniumについて言及していましたけど、場合によってはWWW::MechanizeとHTML::TreeBuilderやWeb::Scraperを使うという方法もあると思います。

他にも、ストアドプロシージャを使っている部分は、Perlからでもテストしやすいかもしれませんね。ストアドプロシージャ禁止というプロジェクトもあったりするので、その場合は駄目ですが。あえてストアドプロシージャを積極的に使うことで、ロジックを半ば強制的に分離させるというやり方もありそうな気がしますけど、上手くいかないんですかね。