|
2/12～13まで行われていた「Developers Summit 2009」
今回はレポート第２弾として、 ソフトウェアに関するレポートをまとめました （ラストは実体のない概念的な話のレポート３つの予定） 前回同様、メモした内容と記憶から起こしているので、 必ずしも話の内容について正確ではないかもしれません 特に、ブラウザの話に関しては、 私のメモが相当わかりづらいので、 ぜひ実際の発表資料で確認を ブラウザJavaScript高速化JITバトル最終決戦 by 森田創 氏 ＜開始前＞ ・会場は広いわりに、人はあまり多くない ・どうしても実務寄りのセッションに人が集まる模様 ＜内容＞ ・このセッションは資料が良くできていたので、 資料を見ながらが望ましい・・・というか、 見ながらでないと説明が難しい ・AjaxをきっかけにJavaScriptの高速化が本格化 ・Chromeで完全に火がついた ・登場人物は３つ ・V8（Chrome） ・SquirrelFish Extreme（Safari） ※以下SFX ・TraceMonkey（Firefox3.1以降） ※以下TM ・高速化のポイントは３つ ・言語固有の面倒な問題を解決 ・既存の他VMから高速化手法を取り入れる ・Web固有のツボを利用する ・これらを踏まえて今回の説明ポイント ・クラスがないという問題 ・メソッドの呼び出し ・正規表現 ・クラスについて ・クラスの利点は構造があらかじめわかっていること ・わかっているから、プロパティアクセスが配列的にできる ・このあたりはJavaのメモリ管理周りとかを参考にするとわかるはず ・あるいは発表資料の図参照 ・一方、JSは自由に構造を変えられる ・普通にやるとハッシュでプロパティを検索することになり、遅い ・でも、普通は同じ構造を使うよね・・・？ ・だったら仮のクラスを裏で定義してしまおう(｀･ω･´) ｂ ・それでもプロパティが増えたらどうする？ ・元のクラスを継承して拡張すればいいね ・要するに、各エンジンは裏でクラス構造を定義し、高速化している ・メソッドの呼び出し ・このあたり、説明しづらいので、発表資料を参照のこと ・たぶん、その方が１０倍わかりやすい ・JIT = Just In Time ・実行時にコンパイルする手法 ・JavaVMで行われている ・問題は引数となるプロパティのアクセス ・クラスがわからないと、プロパティを探せない ・つまり、クラスを探すためにまたハッシュを使うことになる ・これではまた同じことの繰り返し ・でも、だいたい渡されるクラスって同じだよね・・・？ ・だったら、よく使われるクラスに最適化しちゃおう(｀･ω･´) ｂ ・if (よく使うクラス){ 最適化コード } else { ハッシュアクセス } ・それでも予測が外れたら？ ・最適化コードを作り直す ・V8とTMでやり方に差がある ・V8のやり方は・・・ if (ClassA){ ・TMは直に値を書き込んでしまう ・差が出るのは、引数のパターンが複数ある場合 ・V8は単体クラスでも多少遅いかわりに、複数でも遅くならない ・TMは単体クラスだと最速だが、複数パターンあると一気に遅くなる ・正規表現 ・状態遷移モデル ・インタプリタ ・JSで使われるのは後者 ・正規表現もJITで処理 ・SFX>=V8>TM ・TMは正規表現にあまり力を入れてない？ ・他の高速化要素もいろいろある ・今後の展開 ・ブラウザによるベンチマーク ・PCの一般的なベンチから、Webサービスのベンチへ ・モバイルでの性能 ・省電力なのはどれ？ ・蚊帳の外のIEがどう動くのか ＜感想＞ ・面白かったけど、話は難しい ・そもそも、業務レベルだと「速くなればOK」が現実 ・発表資料が良くできていて、サンプル的なコードもわかりやすい ・逆に、それゆえにこのメモだと内容が全然伝わらない(´･ω･`) ・そこは私の腕の問題か・・・ Hudson によるインクリメンタルな開発 by 李剰熙 氏 ＜開始前＞ ・開発手法が絡むセッションのためか、多少年齢層高め ・申し込んだ時点ではタイトル不明だったので、 実は「Hudson」がなんなのか調べてなかったΣ(・ω・ノ)ノ ・ ・すっかりiPhoneで有名になって・・・(つД｀) ＜内容＞ ・インクリメンタルな開発の話 ・CI = 継続的インテグレーション ・Hudson = CIサポートツール ・「XP」とかアジャイルプロセスとか ・CIでは頻繁にビルドとテストを繰り返す ・そのメリット ・早い段階でバグ発見 ・テストを毎回通すのでデグレ防止できる ・手戻りの減少 ・まあ、このあたりはみんな知ってるよね・・・？ ・でも、これを手動でやるのは大変だ ・だから普及しない ・よろしい、ならば自動化だ( ﾟДﾟ)y─┛~~ ・「Hudson」とは何か？ ・Javaで書かれたWebツール ・開発者がコミットすると、自動でチェックアウト→ビルド→テスト→通知 ・Hudson自体にDB不要 ・テストするプロジェクトがDBに依存している可能性はある ・設定もWebだけでよく、ファイルをいじらなくていい ・内部でサーバを持っているので、warをjavaで叩くだけで起動 ・コンテナにデプロイももちろんできる ・プラグインでいろいろ自由に拡張できる ・使われているプロジェクトいっぱい ・JRuby/Jiemamy/Apache/Seaser etc... ・JiemamyはER図とか書けるツール ・ソース管理システムは何でもいい ・これもプラグインで拡張できる ・ビルド ・Ant/Maven/Rake/sh/bat etc... ・要はたいていの言語に対応できる ・通知 ・Mail/RSS/Twitter etc... ・機能追加 ・TaskScanner ・BTS連携 ・TracLightingには組み込み済みらしい ・使ってるくせに知らんかった・・・Σ(・ω・ノ)ノ ・実際の活用例 ・Jiemamyの場合 ・３つのプロジェクトに別れている ・他のプロジェクトへの影響が確認できる ・とりあえずコミットして、エラーレポートから対応して・・・ ・そのためにもテストを書くようになる ・エラーを無視しなくなる ・ビジュアル的にエラーがあるとわかるので、気になるから ・Seaserの場合 ・５つのプロジェクトでテスト運用中 ・LDAP認証を使用 ・複数DBでテストしたいので、独自プラグインを開発 ・プラグインで自由に拡張できるのが大きい ・品質が安定したらしく、本番運用を開始するらしい ・使用上の注意 ・犯人探しをしない！ ・そのためのツールではない ・導入して終わりにしない！ ・継続的にメンテしないと意味がない ・エラーを放置しない！ ・せっかくエラーの通知があるのに、無視したら意味ない ＜感想＞ ・かなりよさそう ・ソース管理システムとは独立してるので、導入しやすい ・問題はRuby/Perlでどう使うか・・・ ・わかっていはいたけど、やはりMaven2なのか・・・ ・最近Javaいじってないからな・・・ |
|
2/12～13まで行われていた「Developers Summit 2009」
とりあえずレポート第１弾として、 Rubyに関連する（というより関係が深い）セッションについてまとめました なお、メモした内容と記憶から起こしているので、 必ずしも話の内容について正確ではないかもしれません また、一部順序を入れ替えているところもあります ですので、他の方のレポもぜひ参考に 未来へつながる言語～ある言語おたくの視点から by まつもとゆきひろ 氏 ＜開始前＞ ・わりと年配の方も多い ・もらった資料によるとRubyの資格制度がある？ →Ruby1.9のセッションで理由判明 ＜内容＞ ・最初に触ったのはBASIC ・Pascal→LISPと学んでいく ・本を読んだだけで「わかった気になった」 ・そもそも、BASIC以外の実行環境がなかった ・BASICに限界を感じる ・言語を作ることが夢に ・大学の卒論で言語を作る ・多重継承とかあったらしい ・今日はRubyの話・・・と見せかけて、その話ではない ・（言語の進化に関する話） ・世界最初の言語はFORTRAN（1954～） ・と見せかけて、「Plankalkül」（1948～） ・ドイツ ・ドイツの技術は（ｒｙ ・JOJOネタだっけ？ ・こういうネタが講演随所に ・ノリノリね(｀･ω･´) ｂ ・なんと例外機構がある ・でも、仕様が複雑すぎて実装不能 ・実装できたのは2001年になってからΣ(・ω・ノ)ノ ・なので、初期の言語はこれ ・FORTRAN/COBOL/LISP ・1950年代 ・まつもと氏の会社の半分はRubyだが、残りはCOBOL ・レセプトのシステムをフルOSSでCOBOLで実装 ・コンパイラまで全部自作 ・6000もの病院で採用済み ・たぶん、COBOLだって用途があって作られたのだから、 その技術や技術者を捨てるのはもったいないという発想だと思う ・言語にはそれぞれ作られた理由があるって発想が、 まさに「言語おたく」なんだろう ・FORTRAN：数値計算/ベクトル計算/HPC ・COBOL：オフコン/汎用機/レコード処理 ・事務系では最も楽に書ける＠COBOL技術者 ・LISP：人工知能/大学・研究 ・BLISS/C/C++→C/C++ Java Perl/Python/Rubyへ ・PHPはあえて入れなかった＠まつもと氏 ・会場大うけ ・やっぱりPHPは認めたくないのね(´･ω･`) ・気持ちはとてもよくわかる ・進化の要因とは？ ・簡潔さ ・新パラダイム ・外的要因 ・「温故知新」 ・生物の進化論と似たようなもの ・その時代にマッチしたものが主流となって生き残っていく ・簡潔さは力なり ・前の問題を解決するために次が現れる ・より少ない記述へ抽象化が進む ・Brooksの法則（生産性の法則） → 「人月の神話」の人 ・「PGが1日に書けるコード量は、言語にかかわらず一定である」 ・パラダイム ・構造化（70年代） ・オブジェクト指向（80～90年代） →これらはもう当たり前 ・論理型プログラミング => 行方不明 ・Prolog ・関数型プログラミング => Hot!! ・外的要因 ・昔はマシンコスト＞＞＞＞＞＞人的コスト ・今は逆転 ・開発費は変わらないのに、やることは複雑化 ・ムーアの法則 ・以前は勝手に環境の方で処理が加速していった ・ムーアの法則は限界 ・マルチコア・メニーコアへ →PGのレベルで対応がまた必要な時代へ ・温故知新 ・Javaで普及した技術：VM/GC/例外 ・これらは全部昔からある技術 ・Javaで普及しただけ ・普及の過程：冒険→改良→普及 ・Simula→Smalltalk/LISP→Ruby（オブジェクト） ・FP→StandardML→Haskell/OCaml（関数型） ・メインストリーム ・Java/Ruby（オブジェクト）→Haskell/Erlang（関数型）→APL？ ・Rubyも関数型を取り込みつつある ・宣言的 ・並列 ・APL ・ベクトル/行列・配列が得意 ・書けないし読めない ・まつもと氏も読めない ・でも生産性は高いらしい ＜終了後＞ ・オライリーのRuby本を買うとサインしてもらえた ＜感想＞ ・マニアックではあったけど、話自体がとても面白かった ・まつもと氏のキーワードは、どうも「温故知新」らしい ・ぶっちゃけ、この話を聞くまで「関数型プログラミング」を軽視していた(´･ω･`) ・現在高速に情報収集中 Ruby 1.9の現状と導入ポイント by Yugui 氏 ＜開始前＞ ・まつもと氏のセッションより年齢層低めの印象 ・実務担当の集まりっぽい ＜内容＞ ・前提：今日帰ったら即1.9.1へ移行せよ ・Ruby2.0がひとつのゴールである ・1.8→1.9はJava1→2くらいの進化 ・1.9→2.0へはJava2→5.0くらいの飛躍が必要 ・1.8.8も出る予定 ・1.9のコードが「パースできる」だけで、動くとは限らない ・1.9へ移行しやすいようにリリースされるもの ・やはり「温故知新」という言葉が ・1.9のTopic ・改善された開発体制からリリースされた ・「Rubyらしさ」を追求 ・（RubyでできることはぶっちゃけLISPでできる、と言っていた） ・今後はRubyへ移行するのにだけ必要だった要素を徐々に切り捨てていく ・開発体制 ・Redmine ・Ruby開発のトラッキングシステム ・現状は「とりあえずMatzに聞け！」 ・メーリングリストと連動するおかげで、かなり利用されるように ・RoRで実装 ・Rubyの中の人たち曰く「Railsもただのアプリだろ( ﾟДﾟ)y─┛~~」 ・とはいえ、普及に貢献しているのは間違いない ・開発体制をRoRで構築した以上、RoRがこけるとRubyもこける ・一蓮托生 ・でも、たぶんRuby自体はこけないと思う・・・ ・細かいRuby関連の情報はこれのWikiを見てほしい ・branch ・メンテポリシーを定めた ・1.8系は2つ ・1.8.8で1.8.6が切られるかは不明 ・「自分は1.9担当だから知らん( ﾟДﾟ)y─┛~~」 ・1.9は一つだけ ・でも、1.9.2の後も、場合によっては1.9.1も・・・？ ・support ・サポートレベルを4段階定義 ・サポート ・継続的なメンテがある ・全テストにPASSしている ・大体動く ・たぶん動く ・知らんがな( ﾟДﾟ)y─┛~~ ・ドキュメント ・有志がメンテ中 ・標準化 ・進めてはいる ・でも、自由な進化の妨げにもなるので微妙な面も ・一方で、お役所の調達には必須だったりとか・・・ ・RubySpec ・いろいろなRubyの間で互換性を保持するテストの仕組み ・仕様の安定性 ・もうかっちり仕様が固まった ・ブロックの仕様 ・lambda ・大きなレベルでの変更はもうない ・なので、安心して移行していい ・1.9.0はすべてのテストをPASSできなかった ・1.9.1は100% ・Railsはまだ対応しきれてない ・Gemを標準で取り込んだ ・そのためモジュール起動が高速化 ・以前はワンテンポ待たされたが、もう待たされない ・YARV ・中間コードを生成するようになったことが大きい ・つまり、他のVMで動かせるということ ・いろいろ進行中だが、まだ中間コード自体の仕様が固まってない ・Ruby1.9が固まってない、ということではないと思う ・M17N ・エンコードを内部で保持 ・違うもの同士で処理しようとすると、自動で変換 ・それがバグの温床になりそうだな・・・ ・エンコーディングを間違って処理しようとすると例外があがる ・String#each廃止 ・Rubyアソシエーション ・いくつかの企業が協業してRubyの普及を進めていく ・この一環がRuby認定試験と推測 ・つまり、お墨付きがあるわけか ・なら受けてみるか・・・ ・移行手順 ・$KCODEからマジックコメントへ ・ライブラリの対応確認 ・文字列周り確認 ・消されたメソッドはすでに使われてないか、他に手段があるもの ・それぞれ対応を探す ・最後に ・さっさと1.9に移行汁( ﾟДﾟ)y─┛~~ ＜感想＞ ・この人もかなり個性的 ・微妙に火の星座っぽい ・たぶん牡羊座か射手座あたり ・そういえばまつもと氏も牡羊座＋天秤座か ・そんなのどうでもいいね(´･ω･`) ・Gem関連の起動が高速化されたのはかなり大きい ・今のシステムのネックがそこだけに ・さっさと移行はしたいけども、今のシステムはARを使っているので、 ARが1.9.1に対応してくれないと・・・ ・なお、「( ﾟДﾟ)y─┛~~」を多用したのは、本当にそんな雰囲気だったから ・やっぱり牡羊座っぽいな・・・ |
|
今日まで行われていた「Developers Summit 2009」
昨日に引き続き、今日も２セッションだけ参加してきたので、 ざっくりとした内容の紹介と感想を 各セッションのメモした範囲での詳細内容は、 明日以降にまとめて順次ＵＰします ○Hudson によるインクリメンタルな開発 by 李剰熙 氏 ・インクリメンタルな開発を支援するツール「Hudson」の紹介 ・コミットをトリガーにして、ビルド・テスト・そのレポートの通知までを自動で ・HudsonはJavaで書かれたツール ・ツール自体はDBを使わない ・設定もWebで全てできる ・好きなコンテナにデプロイできるし、単体でWebサーバ機能を持っている ・GUIが非常に良くできている ・レポートをグラフで表示してくれるのでわかりやすい ・プラグインにより、機能追加や対応言語を増やすことも ・つまり、Java専門のツールではない ・非常に良さそうだが、LLでの開発でどう使うかが知りたい ○「レガシーコード」とはいったい!? ～あなたも書いてるかもしれないレガシーコード～ ・スピーカーは４名だが、メインで進める人がいて、他の人が補足する感じ ・基本はこの本の紹介 ・レガシーコードとは「（自動）テストのないコード」のこと ・実装を変更するために、まず通るテストを書き、実装を変更し、それをテストに通す ・まあ、要はXPとかアジャイルプロセスの基本的な考え方 ・とはいえ、ここまでは事前に調査済み ・実際のコードの紹介はあったが、プレゼンとしてはちょっとわかりづらい ・むしろ、中谷氏の「Developer's 川柳」が秀逸すぎる ・PDF資料が公開されたらぜひとも読むべき ・正直、これだけでこの本を読みたくなるレベル ・名言：「レガシーコードとは、コードで説明されていないコード」 ○その他 ・まつもと氏のサイン本が売られていた ・昨日に比べると参加者は少なめか？ |
|
今日明日と行われている「Developers Summit 2009」
今日はそこに参加して話を聞いてきたのですが、 まだ明日もあるし、細かい話は週末にまとめるとして、 とりあえずは参加したセッションの概要と軽い感想を ○未来へつながる言語～ある言語おたくの視点から by まつもとゆきひろ 氏 ・いわずと知れた「Ruby」の開発者 ・しかし、今日の話の内容はRubyとあまり関係ない ・言語のこれまでとこれからのお話 ・間違いなくこの人、「言語おたく」です ・楽しそうに話していたので、こちらも楽しく最後まで聞けた感じで ・相変わらずPHPは認めたくないらしい(´･ω･`) ○Ruby 1.9の現状と導入ポイント by Yugui 氏 ・事前にわかっていたとはいえ、女性ということに軽く驚く ・とても「とがった」感じの人 ・たぶん、こういう人でないと、Rubyのまとめ役なんてできないのだと思う ・多くはRuby1.9を勧める理由について ・大雑把に言って「真面目なプロセスで作られ」、 「余計なものを切り捨てた」のがポイント ・YARVの展望についてもいろいろと ・個人的に聞きたかった1.8からの移行については、やっぱり文字列周り ・Gemがネイティブ？に取り込まれ、起動が高速化されたらしいので、 これだけのために1.9に移行する価値はありそう ○美しいソースコードのための考え方 by こみゅぷらす ・このタイトルに惹かれたのか、狭い会場に１３３人集結 ・講演者も運営も、１０～２０人程度を想定していたらしい ・肝心の内容はちょっと抽象的過ぎるか ・言ってることは結局「オブジェクト的に書くと綺麗に見える」ってことじゃない？ ・コメントの是非も、「書かないのも書きすぎるのも良くない」という当たり前の結論 ・そもそも、「参加者との討論」を想定していたらしい ・それにしちゃスライド多すぎないかい・・・？ ・reject：しりぞける、拒絶する、冷遇する ・実際運営の人も全然いなくて、まさに「Reject Live」 ○ブラウザJavaScript高速化JITバトル最終決戦 by 森田創 氏 ・本当はこの時間の「Reject Live」を聞くつもりだった ・でも、前のセッションで閉口したので、急遽こちらに参加 ・JavaScriptの内部実装のお話 ・高速化するためにどんな工夫をしているか、ということ ・普段余り気にしない部分ではあるものの、なかなか面白かった ・でも、ちょっと難しいね(´･ω･`) ・そもそも、業務レベルだと「速くなればOK」が現実だし・・・ ・むしろ、この人の本業は「オンラインゲームの開発」なのに、 なんでVMの評論をしているのかが気になる ○飛行船萌え障害キタ━━━━ (;´Д｀) ━━━━ !!!! ～テスト嫌いエンジニアに贈るテストのすすめ～ by 山根ゆりえ 氏 他 ・このタイトルの前半もインパクトがあるが、もちろん後半が気になった ・このセッションもメインスピーカーは女性 ・冒頭では「テストを簡潔に行うための手法」という話のはずだったのだが・・・ ・飛行船のシミュレータのデモがなかなか ・スプーンを叩いて、その衝撃を信号に変換し、PCで受け取って操作 ・で、このシミュレータのバグが話のメイン・・・だったのだが・・・ ・ここから妙に素人っぽいというか、内容が一気に低レベル化Σ(・ω・ノ)ノ ・バグの原因が「設計ミス」「インターフェースの打ち合わせ不足」はともかく、 「境界値テストしてない」とかなんなのよ・・・ ・で、結論が「単体テストしましょー」とか、「納期とコストに見合ったテスト」とか、 当たり前の話に収束して、それに対する手法の話がない ・一通り女性が話した後、ベテランの人が突っ込みを入れる時間に ・でも、その話も有益かといわれるとちょっと・・・ ・正直期待はずれ(´･ω･`) ○その他 ・Rubyの本を買うと、まつもと氏がサインしてくれる時間があった ・私服で来ていた人の８割はiPhone持ってたと思う ・やっぱりNetbookはこの手の講演のまとめには便利そう ・女性の参加者もかなり多かったのがちょっと意外 ちなみに、明日は午後の２セッションに参加予定 |
|
メルティランサーＲＰＧ・リプレイ
経緯とか解説的なものはあっちで書いたので、補足的なことだけ 再公開にあたり、各シナリオの補足的なことを書こうかと思いましたが、 「当時の私」が結構まとめていたので、いじりませんでした 「用語集」に関してもいろいろ抜けがあるのですが、 これも直さない・・・というか、直せません 何を書こうとしてたかなんて覚えてないし・・・ ちなみに、「魔獣編」は第２話まで終わっていたはずなのですが、 リプレイとしてはまとまってません ログはどこか探せばあると思いますが、あったとしても編集しないと思います どうせ続きをやる気はないので、 覚えている範囲でネタバレを書こうかとも思いましたが、 皆さんのご想像にお任せします あと、当時作った曲ですが・・・ 再公開するなら手を入れないとちょっと厳しいかな・・・ ミクに歌わせるにしても、試しに歌わせた曲と違って、 英語の歌詞が存在するので、ちょっと難しいかなと 気が向いたら再調整してみます |
