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

##まとめ

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

##開会の挨拶

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

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

  • クラウド技術に Deep Dive する
  • ソフトウェア開発のパラダイム
    • 構造化 -> オブジェクト指向 -> コンポーネント指向 -> サービス指向 -> Web 指向
  • パラダイムの途中変更は困難
    • Scale-up vs. Scale-out
    • 同期 vs. 非同期
    • システム要件によっては途中での変更が出来ない
  • Domain Specific Paradigm
    • ドメイン単位
    • ワークフロー，オブジェクト，アスペクトなど
    • パラダイム適用(選択)はスナップショット
    • 時代と共に選択は変わる
    • パラダイム変更は Agile では扱いにくい
  • マルチパラダイム
    • SOA/WOA/Component/OO/Model-driven/etc…
  • SOAの問題はどこにあるか
    • 再利用性の限界
    • ビジネス的な制限で
    • 再利用可能でもスケーラブルでない
    • メッセージだけを扱うため
    • サービス内部実装は隠蔽され，関係が複雑化しているから
    • これからのクラウドは
    • サービスという機能分割単位は有効
    • REST を使うのが業界のコンセンサスになりつつある
    • SOAP は How で，REST が What
      • 属人性が無くなる
  • N-tier モデルの問題は？
    • もはや最適なアプリケーションアーキテクチャではない
    • ACID のスケーラビリティに依存してしまう
      • ロック・分散トランザクション
      • 2相コミットが前提のアーキテクチャはクラウドでは厳しい
    • RPC の脆弱性
      • 通信障害耐性が低い
    • スケールアップに制限がある
  • Azure クラウド OS
    • 構造化オーバーレイ
    • 分散ハッシュテーブル
    • 100万台規模
    • 処理するインスタンスを選ぶのに，ルーティングが行われる
    • クラスタリングでよく使う手
    • 他ノードへのデータの複製は非同期で行う
    • 可用性を重視して，完全性を犠牲にしている
  • アプリケーションアーキテクチャ
    • Key-valu で非同期
    • 非同期がキーポイントかな
  • クラウドにおねるパラダイム
    • スケーラビリティと可用性を重視する
    • DDR(Data Dependent Routing)
      • ロンドン・NY・東証などがこのアーキテクチャを使っている
    • データ分割
    • 重要なのはこの2つ
  • Azure の例
    • OO パラダイム
    • REST のように CRUD でやるばあいなど
    • メソッドスコープのトランザクション
    • RoR の Polymophic Data
    • Functional パラダイム
    • MapReduce
    • クエリーエンジンによるクエリー機能
  • データモデル 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 年
  • 初期の言語
    • FORTRAN
    • 数値計算に特化している
    • ベクトル化
    • HPC
    • COBOL
    • レコード
      • 帳票に基づいたシステムを簡単に作れる
    • 汎用機
    • オフコン
    • LISP
    • 人工知能
    • 大学で研究されている
    • 研究機関でも利用されている
  • システム言語
    • BLISS
    • C
    • C++
  • 現代的言語
  • C/C++
  • Java
  • Perl/Python/Ruby
    • PHP はわざと入れていない
  • ロストテクノロジー
    • HPC
    • 事務計算
    • ベクトル
  • 言語の進化要因
    • 簡潔さ
    • 簡潔さは力なり(ポール・グレアム)(「Y Combinator」の人)
    • Brooks の法則(「人月の神話」の人)
      • コードの生産量は言語に依存しない
    • 新パラダイム
    • 構造型プログラミング
    • オブジェクト指向
    • 論理型プログラミング(Prolog)
    • 関数型プログラミング(Haskell)
    • 外的要因
    • パラダイム
    • コスト
      • マシンコスト
      • 人件費
      • ソフトウェア開発費
    • ハードウェア
      • ムーアの法則
      • マルチコア/メニーコア
      • ソフトウェア側が支援する必要がある
    • 温故知新
    • Java
      • VM/GC/例外
    • 時代が進んだので，人々に受け入れられた
  • 言語の進化
    • 冒険
    • 改良
    • ここら辺で，一部で受け入れられるようになる
    • 普及
    • 広く受け入れられる
  • 今，来ている言語
    • Java
    • Ruby
    • Haskell
    • Erlang
  • これから来る言語
    • Ruby
    • Haskell
    • Earlang
    • APL
    • 関数型言語の影響を受けるのではないか
    • 宣言的プログラミング
    • 並列プログラミング
    • 普通の言語が関数型っぽく
  • APL？
    • ベクタ処理
    • 生産性が高い
    • 後継言語として，K とか J とかがあるらしい
  • この先は・・・・

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

  • Yugui さん

###Ruby 1.9 とは

  • 6年ぶりの MINOR バージョンアップ
  • 新しい Ruby
    • 文法の改善
    • ライブラリの整理
    • 仮想マシン
    • M17N
  • 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 による情報共有
  • 開発会議
    • #ruby-core@freenode
    • オフライン(ustream)
  • 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}
  • ライブラリの整理
    • 古いライブラリの削除
    • SOAP4R の削除
    • RubyGems/Rake の追加
    • minitest
  • 仮想マシン
    • YARV
    • 高速化
    • AOT/translator 基盤
    • HotRuby
    • yarv2llvm(LLVM)
    • unholy(Python)
  • 難読化？
    • バイトコード仕様はまだ不安定
  • M17N
  • String などが 多言語化された

###導入の手引き

  • 修正順序
    • 文法エラー
    • ブロック周り
    • エンコーディング -> マジックコメント
    • ライブラリ確認
    • 実行時例外
    • エンコーディング -> 変換すればいい
    • String#each -> Enumerator
  • 時期
    • いますぐやろう

###まとめ

  • Ruby 1.9 は次世代の Ruby

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

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

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

  • JavaScript VM の高速化技法
  • 夜の仕事がアマチュア JavaScript VM 評論家
  • 疑問が3つ
    • 最終決戦？
    • Safari JS の ChangeLog の speedup/optimiz の出現個数が，Chrome の出現などでアップしている
  • JavaScript は重いコンポーネント
    • Gmail の閲覧手動ベンチマークでは，システムの 1～2割程度消費

###V8 の系譜

  • Google が開発
  • Sun から引き抜かれた Lars Bak がエース
    • Strongtalk VM
    • Java Hotspot VM

###SquirrelFish Extreme

  • Apple が開発
  • JavaScriptCore 高速化バージョン
  • KHTML/KJS から派生

###TraceMonkey

  • Mozilla が開発
  • SpiderMonkey + Tamarin Tracing(from Adobe)
  • Tamarin Trace は UCI の Gal’s JVM から

###決戦の舞台

  • すべて未リリース
  • ソースコードから build

###本題 : 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 で実装されている
    • コアのアイデアはよく似ているが，実装方法はちょっと違う

###正規表現ってどう実装する？

  • 状態遷移図を作る路線
  • インタプリタでやる
    • JS はこちら
  • アイデア : 正規表現も JIT でコンパイルする

###JSVMs には正規表現 JIT コンパイラがある

  • 各プロジェクト絶賛開発中

###3つの所見のまとめ

  • 各社頑張っている

###今日出てこなかった話

  • VM っぽい高速化
    • GC まわり
    • 命令セット
    • ネイティブコード呼び出し
  • コンパイラっぽい高速化
    • レジスタ割り当て
    • 共通部分式の除去

###今後の見所

  • ブラウザを含めたアプリの総合性能
    • FF11 ベンチ -> gmail ベンチ に？
  • モバイル機器での性能
    • 消費メモリ
    • ARM CPU 向け高速化
  • Internet Explorer の動向
    • 今は遅すぎて・・・・

###今後の動向など

  • ChangeLog を見よう
  • ML/トラッキングシステムなどを見ればいいかもしれない

##休憩

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

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

  • 吉岡さんとかドラ娘さんも着物です．
  • ust 部隊がいます．

###よしおかさんから伝えたいこと

  • いろいろなコミュニティがある
  • 開発者が元気な社会を作りたい
  • コミュニティ間のコミュニケーション
  • ナンパの場．ただし開発者．

###勉強会勉強会

  • 自作自演
  • IT勉強会カレンダーを見よう
    • 以上
  • 勉強会勉強会のきっかけ
    • OSC 2008 Tokyo/Fall での集まる．
  • 主催者・幹事 重要
  • 開催のメリット＞開催”コスト”のデメリット
  • 勉強会を主催しようぜ！

###DevLOVE

  • RubyKaigi の帰りに結成
  • 開発の楽しさを発見・前進させよう．
  • 明日の現場で活用できる気づきを．
  • 現場と現場の間に壁はない
  • 開発を楽しくする，楽しさを共有できる仲間を得るためのコミュニティ

###日本Open Solarisユーザグループ

  • 若い人大募集中
  • AMP = LAMP - Linux
  • OpenSolaris はノートPCでも compiz も動くよ！

###Linux コンソーシアム

  • クライアントをリッチにする部会「リッチクライアント部会」
    • Welrich「よりリッチに」
  • 漫才風でした．というか漫才でした．

###オブジェクト倶楽部

  • 沢田マンションとコミュニティについて
    • 自作マンションの話

###要求開発アライアンス

  • 要求開発(Openthology)
    • 要求はあるものではなく，開発するものである．
  • Yahoo! Group で展開中

###PFP

  • PFとは
    • プロジェクトの成功と，関わる人のやりがいの両立を目指す活動

###日本Rubyの会

  • いつものに戻った
  • ネットのコミュニティもいいよ！

###Anntena Project

  • 漫才師2人の手下
  • TechPeers 勉強会

###わんくま同盟

  • なぜ「わんくま」->中さんに聞いてください．
    • 猫好きが多いです．
  • 実はノンジャンル

###grails code reading

  • Grails のソースコードを読む
 
comments powered by Disqus