デブサミ2009 1日目に行ってきた

開発 セミナー デブサミ

まとめ

  • 今年のキーワードはクラウドコンピューティングのようだ．
    • クラウドセッションへの参加者数が多い気がする．
  • 今日は Ruby で，明日は PHP/Perl とほどよく分散されている．
  • いいセッションが被ってるのが悲しい．これは Ruby 会議とかでもそうだけど，仕方ないのかなぁ．

開会の挨拶

  • テーマは「つなぐ、つながる、そして未来へ」
  • コンテンツ委員の挨拶
    • 和田(t_wada)さんでした．
      • 代打らしいです．
    • 世代を超えて繋がることで，新しい見知を得られるのではないか．
  • 資料は後日公開予定

クラウドによるソフトウェア開発のパラダイム(12-D-1)

  • クラウド技術に Deep Dive する
  • ソフトウェア開発のパラダイム
  • パラダイムの途中変更は困難
    • Scale-up vs. Scale-out
    • 同期 vs. 非同期
      • システム要件によっては途中での変更が出来ない
  • Domain Specific Paradigm
  • マルチパラダイム
    • SOA/WOA/Component/OO/Model-driven/etc...
  • SOAの問題はどこにあるか
    • 再利用性の限界
      • ビジネス的な制限で
    • 再利用可能でもスケーラブルでない
      • メッセージだけを扱うため
      • サービス内部実装は隠蔽され，関係が複雑化しているから
    • これからのクラウドは
      • サービスという機能分割単位は有効
      • REST を使うのが業界のコンセンサスになりつつある
      • SOAP は How で，REST が What
        • 属人性が無くなる
  • N-tier モデルの問題は？
  • Azure クラウド OS
    • 構造化オーバーレイ
      • 分散ハッシュテーブル
      • 100万台規模
    • 処理するインスタンスを選ぶのに，ルーティングが行われる
    • 他ノードへのデータの複製は非同期で行う
      • 可用性を重視して，完全性を犠牲にしている
  • アプリケーションアーキテクチャ
    • Key-valu で非同期
      • 非同期がキーポイントかな
  • クラウドにおねるパラダイム
    • スケーラビリティと可用性を重視する
      • DDR(Data Dependent Routing)
      • データ分割
      • 重要なのはこの2つ
  • Azure の例
  • データモデル Entity
    • データ1行ごとにスキーマがあるような考え方
  • Partition Key の例
    • テーブルの水平分割
  • Scale-out 設計の指針(Top-down)
    • 一貫性(完全性)よりも可用性
    • スケーラビリティのパターンの原則
    • アーキテクチャの定義
      1. 機能分割: SOAに基づくサービス単位化
      2. データ設計: 保守用のデータ定義，論理データ配置
    • アプリケーション設計(ユースケース依存)
      1. データ分割
        • どこにデータを配置するかをまず決める
      2. 分散トランザクションの回避
      3. 非同期による機能分割
      4. キャッシュの設計
      5. 一貫性モデルの提供
        • eventual consistency
          • DNS の一貫性確保の方法に近い？
      6. その他: REST Resource など
まとめ
  • N-tier モデルの前提が崩れている
  • データモデル
    • RDB 時代の終焉
  • トランザクションモデル
    • ACID ではなく， BASE
  • プログラミングモデル

未来へつながる言語〜ある言語おたくの視点から〜

  • Ruby の世界へようこそ
    • BASIC に限界を感じて Pascal の本を読む
      • 一度も実行したことがないのに，理解したらしい
    • 次に LISP を知る
    • 高校の時に「言語を作ろう」と思い立つ
  • でも Ruby の話はあんまりしない
  • 世界最初の言語はなに？
    • FORTRAN(1954)
    • 実は違う
      • Plankalkul(1948)
        • Z3 で動く言語
        • ドイツ
        • 例外処理がある
        • 最初の実装が動いたのが 2001 年
  • 初期の言語
  • システム言語
  • 現代的言語
  • C/C++
  • Java
  • Perl/Python/Ruby
    • PHP はわざと入れていない
  • ロストテクノロジー
    • HPC
    • 事務計算
    • ベクトル
  • 言語の進化要因
  • 言語の進化
    • 冒険
    • 改良
      • ここら辺で，一部で受け入れられるようになる
    • 普及
      • 広く受け入れられる
  • 今，来ている言語
  • これから来る言語
    • Ruby
    • Haskell
    • Earlang
    • APL
    • 関数型言語の影響を受けるのではないか
      • 宣言的プログラミング
      • 並列プログラミング
      • 普通の言語が関数型っぽく
  • APL？
    • ベクタ処理
    • 生産性が高い
    • 後継言語として，K とか J とかがあるらしい
  • この先は・・・・

Ruby 1.9 の現状と導入ポイント

  • Yugui さん
Ruby 1.9 とは
  • 6年ぶりの MINOR バージョンアップ
  • 新しい Ruby
  • Ruby 2.0 への道
    • いつかたどり着く理想郷
    • Ruby 1.8.x は Ruby 1.9 からのバックポートが取り込まれている
  • 何故 Ruby 1.9 か
    • 機能向上
    • 実装刷新
    • 開発体制
    • 2.0 への道
      • Ruby が Ruby であるための Ruby
        • Ruby は独り立ちをすべき
      • 温故知新
開発体制
  • Release Management
  • Redmine
    • Issue Tracking System
    • Rails アプリケーション
    • いままではメーリングリストで行われていたので連携するようにした
    • Matz 日記メインじゃなくて，Wiki による情報共有
  • 開発会議
  • branch policy
    • 1.8 系統
      • 2つのブランチをメンテナンス
    • 1.9 系統
      • 1つのブランチをメンテナンス
      • 3年保証？(検討中)
    • パッチレベル
  • サポートレベル
    • プラットフォームのサポートレベル
    • Supported
      • 継続ビルド
      • メンテナ
    • Best effort
    • Perhaps
    • Not supported
  • ドキュメント
  • 標準化
    • IPA「Ruby の国際標準化に関する調査の請負契約」
      • 進行中...
  • rubyspec
  • coverage 向上計画
    • coverage を上げる
  • Ruby Association
変更点概略
  • Ruby 1.9.1 の動作安定性は高くなっている．
    • Supported ではテストはすべて通る
  • Ruby 1.9 は仕様としては固まっている
  • 文法の改善
    • ブロック引数
    • 新しい lambda
->(x, y) { x+y }
    • オプション引数構文
      • 最後でなくてもよくなった
    • 新しいハッシュリテラル
{foo:1, bar:2}
導入の手引き
  • 修正順序
  • 時期
    • いますぐやろう
まとめ

クラウドプラットフォームの実際

  • クラウドコンピューティングを支持する理由
    • マルチテナント
      • インフラなどｗシェアすることで，低価格で利用できる
    • 従量課金制
      • "サービス"を買う
    • 伸縮性
      • システム・インフラに関して，スケーラビリティがある
  • 大きなアーキテクチャの変移が求められる
    • 開発時間
    • 技術の進歩
    • ビジネスモデルの変化
  • 顧客・企業毎にシステムを構築していた(シングルテナント)が，効率が悪い
    • ハードウェアを管理して
    • スケーラビリティを確保して
  • 単純なマルチテナント(ASP サービス)では，カスタマイズ性に欠ける
  • ハードウェアの仮想化だけでは，ハードウェアの管理が一つで良くなっただけ
  • アプリケーションを開発するのに必要な部分だけを仮想化する
    • 抽象化して API 定義して，かな？
    • Google App Engine と同じ戦略らしい
    • Mutl Tenant DB <- Application Engine <- Client Meta Data
  • メタデータアーキテクチャ
    • 以下のデータがメタ情報として，共通のアプリケーションエンジンに「引数」として渡される
  • 今日の話は「システム毎の導入環境」
    • ここからは Force.com についての営業話が多くなるっぽい
  • Force.com
  • デモ中
    • scaffold があるのは今時っぽい
    • UI をある程度 Web でコントロール可能
    • JSP っぽい感じで作成できるようだ
    • 比較的早くアプリケーションを開発できるようだ
    • ビジネスを展開する仕組みがある
      • 自分で作成したアプリケーションをマーケットプレースに出すことが出来る．
      • あなたも今日から SaaS 事業者に！

ブラウザ Javascript 高速化 JIT バトル最終決戦 観戦ガイド

V8 の系譜
  • Google が開発
  • Sun から引き抜かれた Lars Bak がエース
SquirrelFish Extreme
TraceMonkey
決戦の舞台
本題 : JavaScript VM の高速化
  • 昔は実装をさぼっていたから，遅い
  • 言語仕様も割と面倒
JSVM の高速化戦略
  • JS 言語固有の面倒を取り除き，
  • 既存 VM の高速化を取り入れ，
  • Web アプリケーションの重い部分(ツボ)をチューニング
JS 固有の面倒
  • クラスがないのをどうするか
  • メソッド呼び出しの高速化
  • 正規表現の高速化
  • どの VM でも実装している激戦区
クラスがない
  • クラスがあると？
    • 構造がわかる
      • 構造がわかると高速化できる
  • JavaScript は
    • 実行時にプロパティが変わることがある
    • 事前に構造が決まらないので，高速化できない
  • JS オブジェクトはハッシュ表
    • ハッシュ表は遅い(らしい)
      • C++ で書くと 7 倍遅い
  • 高速化のアイデア
    • 仮のクラスを割り振ってみる
    • プロパティが増えたら，新しいクラスを派生させる
JSVM には仮のクラスを類推するしくみがある
  • どの VM もだいたい同じように実装している
  • 細かな違いはある
メソッド呼び出しの高速化
  • JIT が生成するメソッド呼び出しコードの高速化
  • JIT の利点と制限
    • インタプリタのオーバーヘッドがなくなる
      • while(true)/instructions[pc++]/break
    • 個々のバイトコードの実装は早くならない
      • 遅い「メソッド呼び出し」を高速化する必要がある
        • プロパティ取得を高速化したい
    • JS は動的型付けの言語
      • C++ は静的型付けの言語
      • 一度，クラスを判定してから配列アクセスをするので，その分のオーバーヘッドがある
    • 高速化の仮定
      • よく使うクラスがあるはず
        • そちらに特化した最適化を施す
      • でも選択したのが違っていたら
        • もう一方に特化した最適化を施す
JSVMs は投機的な型付きコードを生成する
  • 各 VM で実装されている
    • コアのアイデアはよく似ているが，実装方法はちょっと違う
正規表現ってどう実装する？
JSVMs には正規表現 JIT コンパイラがある
  • 各プロジェクト絶賛開発中
3つの所見のまとめ
  • 各社頑張っている
今日出てこなかった話
  • VM っぽい高速化
    • GC まわり
    • 命令セット
    • ネイティブコード呼び出し
  • コンパイラっぽい高速化
今後の見所
  • ブラウザを含めたアプリの総合性能
  • モバイル機器での性能
    • 消費メモリ
    • ARM CPU 向け高速化
  • Internet Explorer の動向
    • 今は遅すぎて・・・・
今後の動向など

休憩

  • さすがに疲労感多いので休憩
  • バッテリーの補充も
  • アドエスの電源も切れかかる
    • 外部バッテリー欲しくなる．Eneloop のやつを買うか

コミュニティから選出の LT 大会

  • 吉岡さんとかドラ娘さんも着物です．
  • ust 部隊がいます．
よしおかさんから伝えたいこと
  • いろいろなコミュニティがある
  • 開発者が元気な社会を作りたい
  • コミュニティ間のコミュニケーション
  • ナンパの場．ただし開発者．
勉強会勉強会
  • 自作自演
  • IT勉強会カレンダーを見よう
    • 以上
  • 勉強会勉強会のきっかけ
    • OSC 2008 Tokyo/Fall での集まる．
  • 主催者・幹事 重要
  • 開催のメリット＞開催"コスト"のデメリット
  • 勉強会を主催しようぜ！
DevLOVE
  • RubyKaigi の帰りに結成
  • 開発の楽しさを発見・前進させよう．
  • 明日の現場で活用できる気づきを．
  • 現場と現場の間に壁はない
  • 開発を楽しくする，楽しさを共有できる仲間を得るためのコミュニティ
日本Open Solarisユーザグループ
Linux コンソーシアム
  • クライアントをリッチにする部会「リッチクライアント部会」
    • Welrich「よりリッチに」
  • 漫才風でした．というか漫才でした．
オブジェクト倶楽部
  • 沢田マンションとコミュニティについて
    • 自作マンションの話
要求開発アライアンス
  • 要求開発(Openthology)
    • 要求はあるものではなく，開発するものである．
  • Yahoo! Group で展開中
PFP
  • PFとは
    • プロジェクトの成功と，関わる人のやりがいの両立を目指す活動
日本Rubyの会
  • いつものに戻った
  • ネットのコミュニティもいいよ！
Anntena Project
  • 漫才師2人の手下
  • TechPeers 勉強会
わんくま同盟
  • なぜ「わんくま」->中さんに聞いてください．
    • 猫好きが多いです．
  • 実はノンジャンル
grails code reading