UIE Japan Staff Blog

Speakerの方々の敬称は省略させていただきます。 *2006/06/10 ================================================== *Rubyの歴史 高橋征義 (株式会社ツインスパーク、日本Rubyの会) ================================================== Internet Archive からRubyの歴史を感じさせる資料を引っ張ってきていて、 >> [ruby-dev: 5173] keiju>「やはり宝石の名前でないと」 matz>何で宝石名なんだ matz>三菱の影響か？ keiju>perl matz>なるほど << 初期はruby(小文字)だったけど、Perlが大文字だし、これからはRubyだよね。 など初期の頃からPerlを意識していた事や知らない事実が知れて大変面白いセッションで会場は一気にとりこまれました。 ================================================== *基調講演: まつもとゆきひろ「State of the Dominion」 まつもとゆきひろ ((株)ネットワーク応用通信研究所 特別研究員) ================================================== 普段は大きい野望などを語らないというまつもとさんによるRubyが持つ大きな野望に関するセッションでした。 タイトルの「State of the Dominion」は、State of the Perl Onionというジョークの聞いたタイトルをインスパイアして/usr/shar/dict以下を"niion$"でマッチする単語を探してdominion(支配・統治)という単語にしたとのことです。 「Rubyがなぜ愛されるか？」 それは、「ユーザへの愛」・「僕がRubyを愛しているからだよ」という話でした。で、終わりではなく、Rubyが愛されるのは「普通の人向け言語」であるからで、LL界で人気のHaskellや普通のやつらの上をいくためのLispなどは、頭のいい人が作った言語で、使う人も頭のいい人言語なんだよね。でも、2030年とか将来もしかしたら、関数型言語は普通の人向け言語になるのかもしれない。遅延評価や参照透明性は魅力的だけど、Rubyのポリシーは、 **Enjoy programming 「8月にRuby1.8.5をリリースする予定です。」と発表がありました。 質疑応答では、「ブラウザにRubyが組み込まれるのはいつですか？」との質問で、「それは僕がどうにかできることではないよ・・」といった場面もありました。 ================================================== *パネル企画 Ruby 2.0の世界 ================================================== 10年構想を暖め続けている、Ruby2.0. いったいいつでるのか？ていうか本当にでるのか？ Perl6のように過去の文法を捨ててしまうのか？Ruby2.0に望むものなどについて、豪華パネリストで討論が繰り広げられました。 Ruby2.0のポリシーは、基本的に後方互換でいく。後方互換とよいデザインで矛盾が生じたときは、よいデザインの方を選択する。再デザインしたい問題は、「スコープ問題」と「多値問題」の二点。Rubyの仕様については、「eigenclassに詳しくまとめられているので参考にしてくださいよ」 2007年クリスマスに1.9.1公開予定!?との声がありました。 -1.9.1に入るもの --1.9.0全部 --local variable scope --M17N --YARV(希望) -1.9.1に入らないもの(2.0以降？) --new CG -> あんまり速くなかったので。 --classbox --selector namespace --keyword arguments --method combination -1.8と1.9の違い --正規表現が鬼車で実装 --クラス変数継承しない --BasicObject --ブロックを矢印でも書けるように ブロックを矢印でには反対意見も多そうですが、「未来できっとみんな僕に感謝するよ。(矢印への変更で)」とまつもとさん。 **YARV みんな大好きアッカーマン関数ではRuby標準の処理系に比べて、YARVは20倍高速になる様子。。 tDiaryなど既存のRubyアプリケーションを動かすと現在よりも遅くなる場合があるようで、それについては調査中とのことでした。 その他YARVのupdateとしては、以下のものがあげられていました。 --ネイティブスレッドに対応 --POSIX Thread/win32 thread --JIT/AOTコンパイラ対応したい --マルチプルCPUへの対応をしたい javaのjarのようにRubyのバイナリをサポートできるようになる。が、作ってはいない。 **Ruby 1.9.2.0正規表現ライブラリ　鬼車 -特徴 --30種類の文字エンコーディング --Named group(名前つき式集合) --Subexp call(部分式呼び出し) ---正規表現パターンの一部分をその場所から共有できるようにする機能 -課題 --Unicodeのサポート向上 --Case-insensitive Match(全領域で) --Character Property/Block/Script 「Ruybの変数をパターンに直接代入できるようにする(RCR237)」という提案があがっています。(?{var=}...) 実行速度は、4.xx系ではUTF-16をサポートしたためRuby1.8 regexよりも35%程度遅いとのことでした。 **Rubyのライブラリについて 「RubyGemsを標準添付化するのか、名前の規約化はどうするのか？」という話題でした。一部ライブラリ(cgi-lib.rb, ftools.rb, getopts.rb)については、削るかもしれないようです。 AciveSupportにある便利な機能は標準ライブラリに移したほうがよいかもしれないので、検討しているようです。 RPAよりもGemsのほうが現実的だよねという結論になりました。 ================================================== * 「使いやすいライブラリ API デザイン」 田中 哲(産業技術総合研究所 情報技術研究部門) ================================================== open-uri, Pathnameの作者としても有名な、田中さんによるライブラリのAPIをデザインする際にどういう心がけが必要かという内容のセッションでした。「なんとなくできてしまうAPI」が一番すばらしい。と言うことでそのなんとなくできてしまうAPIを考えるにはどういう風なアプローチがよいのか。例としては、open-uriとNet::HTTPの比較があげられていました。 -手段 ++ ユーザの典型的な望みを推測する。 ++ その望みを実現可能な機能を実装する。 ++ 望みを実現する機能にユーザを誘導する。 「ユーザは覚えることが少ない方がよい」という考えに基づいて、既存のAPIに似せてあげることが大事。ここでもやっぱり名前重要。 使いやすいAPIとは、ユーザの望みをかなえるAPIであり、直接要求されたことだけでなく、ユーザが意識していない将来的な望みも含めてかなえてしまうAPIが素敵。 ユーザの望みは典型的な望みと稀な望みに分類できて、ユーザの望みを推測する方法としては、典型的な望みを調べることが大事。ポイントは、「対象領域」・「メタファ」・「常識」・「一貫性」・「フィードバックでの改善」 **対象領域 初心が大事。規格を調べるうちに何がしたかったのかという初心を忘れてしまうことが多いので、ライブラリを作ろうとなったときの初心は形や文字にして記録しておくのがよい。 **メタファ メタファがあるとユーザの期待をライブラリの作者が予想しやすくなり、覚えやすく思い出しやすい。 例えば、open-uriのメタファでは、「URIでアクセスできるファイルシステム」としている。 **常識 ユーザの持っている常識をうまく利用してあげる。常識とは、環境の知識であったり、Rubyのメソッドであったりする。Rubyプログラマなら、eachは繰り返しだし、openは何かを開くメソッドとして共通の常識を持つ。 **一貫性 一貫性があれば推測することが可能になる。ユーザの類推をライブラリの作者が予測可能になる。しかし、一貫性を求めすぎると、不幸を生む。優先度的には、対象領域>>一貫性である。 普段使うメソッドやクラスを減らすことで、ユーザを適切なものに誘導することが可能。 設定に関しては、設定がないのがよい設定。 よく使うものには短い表現を割り当てる。 ================================================== * 「セキュアアプリケーションプログラミング」 なひ((株)サリオンシステムズリサーチ) ================================================== -openSSL -OpenPGPツールキット セキュリティ基礎技術を使う際のサンプルコードを提供。落とし穴にはまらないようにする。 *機能 -暗号化 -認証 -完全性の保証 通常の場合、認証と完全性の保証はペア *基礎技術 -秘密鍵暗号 -公開鍵暗号 -ハッシュ関数 :素朴なAES（復号）:OpenSSLではCBCを使いましょう。 :パスワードによる簡単AES:素朴なRSA暗号（鍵生成） :ハッシュ関数による認証:HMAC（HTTP-Cookiesの改竄検知に使える）。 -RSAによる認証（署名）:digenter = OpenSSL::Digest::SHA1.new -DSAによる認証（署名） -クライアント認証 -送り先ホスト確認 -集中管理 -リプレー攻撃 SSLでは認証局が証明書を使って通信を行う。 OpenPGP また生々しい機能しかない。 OpenSSLは基本機能が充実している。しかしバイト列を扱うC関数群で扱いづらく、落とし穴多数。より抽象化したレイヤが必須。 RubyのOpenSSLマッピングモジュールはそれをうまく隠蔽できており、現状でも十分に素晴らしい。サポートが厚い。 ================================================== *　仕事で使うRuby 後藤謙太郎(シングラム) ================================================== *仕事でアプリを使ってみた体験談 -業務の支援ツールとして利用した。 -Rubyだとトラブルシューティングする気になる。 -非プログラマ向けにアピールするために重要。 *業務ぽさ？ -似たようなことの繰り返し -隠し事が多い -紙重要 -プログラマとは限らない。- *似たようなことの繰り返し -いわゆるワークフロー -稟議とか承認とか却下とか -受注とか納品とか返品とか でも微妙に違う。ローカルルールがいっぱいある。繰り返すので差異もエントリーも数が多い。 *隠し事が多い -そういう約束なのだからしょうがない -自分のものではないデータもある -ほぼ全部がイントラネット内 -インターネットを通すのはちょっと面倒 *権限 -アクセスコントロールにうるさい -危険な操作をできなくするのは実際大事 *紙重要 -少なくとも印刷する方法があることは大事 -スキャンデータとかExcelとか。 -一覧できるのはよいこと。 -PCなくても議論できるのはよい。 *プログラマとは限らない -英語は使わない -ファイル名が日本語なのは当たり前の世界 -基本的な英単語も読んでもらえなかったりする -人名の順序が辞書式じゃなかったり -機械的でないソートも必要。 -表示されるものの順序はカスタマイズできるようにしたい *使ってよかったもの -Wiki --無いと困る -チケットシステム --無いと仕事にならない *Wiki -HikiとRWiki -決まり事を書くのに使う。訂正や変更がいつでもできるのが良い。 -Office文書と違ってコピーしないのが良い。 -起こったことを書く。コマンドラインとかその出力とか。スクショとか。議事録とか。 -まず使ってもらうこと。一般人には割と敷居が高いので、まずは大量に自分で書く。緩くていいから章立てとかのルールは決めた方が使いやすい。むりにインデックスページを作らず、ある程度は淘汰に任せた方がいい。でも淘汰で生き残ったものは一覧ページを作るべきだ。特にHikiは。 -ルックス重要。会社のレターヘッドとか入れるだけで親近感を持ってもらえる。偉い人は特に。封筒とかPPT用のフォーマットに合わせるとさらに効果的。印刷用のスタイルシートも用意すると、会議資料とかに使える。ワープロ使わなくて済むのはスゴイ楽。 *Wikiになくて残念な機能 :タグ:HTMLではなくブックマークのタグ。まとめるのがいろいろ大変なので。 :テンプレート作成:定型の章立ての文書が多く、プラグインは誰でも書ける訳じゃないので。 :ログイン:権限ではなく署名のため。誰がどこを編集したのかがわからないので。 ((かずひこさんの補足:hikiにはこれらの機能は実装されています)) *チケットシステム -ワークフローの進行を記述する -いろいろな切り口の一覧表を作る -メールのインターフェイスでやりとりできる -可視と編集の権限を制御できる *影舞 本来はBTS（バグトラッキングシステム）だが「バグ」の表記を「案件」に置き換えるだけで業務管理に使える。たっぷり使ってるのはこれだけ。管理機能が簡潔かつ十分。 -フィールドのカスタマイズ -メールの配送先 -データベースの形式 -表示の順序を制御 -フィールドの並びやトップページでの順序 影舞もルックス重要。カスタマイズすべき。一目で区別できることが重要。間違って別の影舞に入れてしまうと悲惨（笑）。効率に影響。ステータスなどのラベル。入力を漏らさないようなフィールドの順序。ちょっとハックして、テンプレートを書き換えてナビゲーションを良くする。まとめページを作る機能を追加する。 *Rubyアプリの問題点。 -探しにくい。RAAの登録はそんなに多くはない。 -商用OSのパッケージRubyは古い。 -人気アプリでもRAAにない？　プログラマ向け？　vectorにでも登録すれば変わるかも。 -アプリごとにRubyを独立にインストールしなければならなかったり。オープンじゃない使い方には独特の制約がある。緩いルールで使えるツールは似たような繰り返しに導入しやすい。