|
前回のネタを書いてから、もうちょっと突き詰めたり、
情報を手に入れたので追記 ○magic commentについて 冷静に考えれば、「ソースをparseするためのヒントを与えるもの」なのだから、 日本語が混じっていたら無条件と考えて良さそう コメントに日本語が混じっていた場合が怪しいけども、 「#で始まる部分をparseしない」という保証がない以上、 念のため入れておいたほうがいい気がする で、問題のrailsについて railsのデフォコードは当然全部英語で書かれているから、 magic commentはいらないはず 追記した部分に入れておけば問題ない気がする それでもerbとか、スクリプトでない部分の扱いが気になるので、 結局すぐ移行は難しそう ○Ruby1.9におけるファイルオープン こちらによれば、Ruby1.9でファイルを開く場合、 エンコーディングを指定しないといけないらしい file = File.open(file_name, "r:utf-8") システムのエンコーディングと、 読み込むファイルのエンコーディングが一致していればいいですが、 一応きちっと指定しておいた方が問題が少ないのは間違いなさそう どちらにしても、今作っているシステムは、 UTF-8上でEUC-JPのファイルを読むので、 指定がないと失敗する気が・・・ magic commentは1.8のコードだとただのコメント行だからいいですが、 ファイルのエンコード問題は事前に仕込めないので、 移行後に書き換えるしかないのが面倒です(´･ω･`) 仕事で組んでいるシステムでいろいろ試すのはさすがに抵抗があるので、 自宅で何か適当なシステムを検証するしか・・・ |
|
今Rubyで作っているシステムはどちらかといえばバッチ系なので、
RailsはActiveRecordしか使ってなかったのですが、 DBのメンテナンスUIにRailsを使うことに なので、先週末から「Rails レシピブック」で本格的に勉強し始めたのですが、 やはりRailsは「フレームワーク」なので、小手先の「作り方」ではなく、 詳細な解説の方が、かえって理解しやすい感じですね(｀･ω･´) ｂ そんなタイミングでRails2.3.2がリリースされたこともあり、 ついでにRuby1.9.1にも移行できないかと、 既存のシステムの環境をいじっていたのですが・・・ 「composite_primary_keys」がAR2.3.2に未対応で、 requireした時点で落ちてしまい、システムが動作しなくなりました(´･ω･`) なので、結果的にはRuby1.8.6 + Rails2.2.2に戻したのですが、 Ruby1.9の導入の段階でもいろいろ問題が ○MySQL/Ruby(Windows)がインストールできない 「extconf.rb」がどうしても通らないのです 当然ながら、libmysql.dllはSystem32以下にありますし、 bin以下に置いたり、extconf.rbと同じとこに置いたり、 オプションでフルパス指定したりしたのですが、どうしても動かない(´･ω･`) Linux環境ならあっさり動きそうな気がしますが、 開発環境がWindowsなので、 やっぱりWindows上で動いてほしいのです ○「magic comment」の扱いがよくわからない $KCODEの代わりに使う、「# -*- coding:utf-8 -*-」ってあれですね $KCODEの場合、起動するスクリプトで指定しておけば、 他の*.rbで指定する必要がなかったのですが、 magic commentの場合がよくわからないのです 選択肢としては・・・ ・起動するスクリプトの冒頭にだけ書く ・コメント以外で日本語が含まれているファイルに書く ・コメントを含めて、日本語が入っていたら書く ・とりあえず全部書く ・・・このどれかでしょう 上から順に労力が低いわけですが、 おそらく一番最後が確実な気もします さらに、Railsで使うerbファイルとか、 *.rbでないファイルの扱いもよくわからないため、 いろいろ危険な香りが・・・(ｌｌｌﾟДﾟ) というわけで、さっさとRuby1.9に移行したいとは思いつつ、 業務レベルではしばらく様子見かなと 個人的にいろいろやってみますか・・・ ＜追記＞ Railsと直接関係ない、コア部分は全部magic commentをつけておくことに Railsがわからんな・・・ |
|
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資料が公開されたらぜひとも読むべき ・正直、これだけでこの本を読みたくなるレベル ・名言：「レガシーコードとは、コードで説明されていないコード」 ○その他 ・まつもと氏のサイン本が売られていた ・昨日に比べると参加者は少なめか？ |
