UIE Japan Staff Blog

2006/05/20～2006/05/22伊東の山喜旅館にて開発合宿を行いました。行く電車の中でブレストし、現地について開発を始め一つのプロダクトを作ったのでリリースします。

ソフトウェアのプロダクト名は、YAMAKI
Movable Typeのエントリ中でリンク一つをクリックするだけで編集モードに切り替わりエントリページのまま編集・保存することを可能にするブックマークレットです。

ブックマークレットとは？

想定される使い方
・ブログを公開したけど、スペルミスがあった。→手軽に修正したい。
・ドラッグ＆ドロップでの簡単記事作成。

対応ブラウザ
Firefox 1.5

YAMAKI

上記のブックマークレットをサイドバーにコピーし右クリック->プロパティとたどり、次の3つの値を書き換えてください。
__username__ = '' あなたのユーザ名
__password__ = '' パスワード
__endpoint__ = '' mt-xmlrpc.cgiへのパス(通常はその他のCGIと同じディレクトリにあります)

ブックマークレットの作成は、
YAMAKI Bookmarklet Generator
から簡単に作成することが出来ます。

次にMT側の設定を行います。

1. システム・メニューをクリックします。

2. 左側のサイドバーの投稿者をクリックします。

3. ログイン名をクリックしAPIパスワードを入力します

設定完了です。

使い方
エントリのパーマネントリンクをクリックし、記事を編集します。
保存アイコンをクリックすると、保存され元ページにページ遷移します。サーバの処理が反映されないときは、リロードしてみてください。

投稿者: UIE Japan 日時: 19:55 | パーマリンク | コメント (4) | トラックバック (6)

Rubyカンファレンス2日目です。 *二日目 ================================================== * 「Ruby anywhere ～Ruby普及のためにアプリケーションができること」 ただただしさん(tDiaryの作者) ================================================== *本日の内容に関する注意点 -昔話です。 -技術的な話ではありません。どちらかというとマーケティング。 -一般的な話ではありません。 *普及ということ 普及に対してなぜか消極的なコミュニティ。平和主義者が多いから？ 普及を目指すのはかっこ悪いか？　そんなことはない。 *場所への普及と人への普及 :場所:あらゆるレンタルサーバに最新のRubyが入っているとか、LinuxディストリビューションにRubyのパッケージがあるとか。 :人:ライブラリやアプリケーションが増える。Rubyのお仕事が増える。 アプリケーションで場所と人の両面から普及を目指す。 *tDiary Web日記システムtDiary。2001年=BR((before rails))3年誕生。tDiary開発の狙いは日記コミュニケーションを加速すること。コミュニケーションのことなら貪欲にやる。ツッコミ、いわゆるコメント機能。リンク元表示。HTTP_REFERERを集計しページ内に表示。一種のTrackBack。携帯電話からの投稿、閲覧にデフォルトで対応。今は当たり前だが当時からやっていた。 *テーマ デザインをCSSに分離し、テンプレートを固定。CSSをユーザー間の共有財産化。テーマが300個以上。Blog,Wiki,はてな,ゆびとま、MyWikiなどの他のアプリでも利用。普通の人にアピール。普通の人重要。 *当時の時代背景 Rubyが使えるレンタルサーバは片手で済むくらい。Ruby関連書籍がようやく増え始めた。CGIと言えばPerl。そういう時代。知名度も環境もまだまだ。Rubyで何か書いても使ってもらえない。場所を増やすには、魅力的に見えるアプリケーションの登場が必要。使いたい人が増える。インストールする業者が増える、という良循環が起こる。 そのためにはEasy to Install。Ruby入れてもらうのも一苦労なのに、その他のライブラリを要求するなんて問題外。ERBだけが問題だったが、tDiaryのパッケージにERbLightを同梱させてもらうことで解決。のちに標準添付ライブラリに。 *露出を増やす 急にユーザが増えると、はやっているかのような錯覚を与える。tDiary.Netというレンタルサービス開始。一気に数百人のユーザを獲得。急速に目立つようになる。制約を嫌って流出する人もいたが。人を増やすために、プログラミングでもしてみようかという気にさせる簡単なプラグインにした。TDiary::Pluginのインスタンスにinstance_evalするだけで、名前空間の分離なし。実行順序がファイル名依存（ださい）。しかし思い切り敷居を下げることの方が重要。Rubyプログラミングを学ぶプラットフォームとして雑誌記事になった。 *まとめ 普及は善。場所を増やせ。人を増やせ。 *next -Railsは人を増やす戦略がうまい。 -Railsが使える場所はまだまだ少ない。 -Rails普及を促すアプリケーションの登場を期待。 *質疑 Q.テンプレートをユーザが変更できるのは危ないのでは？tdiary.netのような用途では。 A.当時は軽いテンプレートエンジンがなかったので、ERBを採用したが今なら別の選択をするだろう 。 Q.パスワードの管理を.htpasswdではなくwebベース等簡単にできないか？ A.httpdにまかせられるものはまかせる方針でベーシック認証にした。一般ユーザがベーシック認証のダイアログを見ると引くことは知っている。.htpasswdを書き換えるwebインターフェイスを誰かが作れば良いかもしれない。 ================================================== *ActiveRecord を詳しく 西 和則 (ヽ( ・∀・)ノくまくまー) ================================================== スピーカーの西さん自身がものすごく楽しでる印象をうけたセッションでした(笑 流れ -for Ruby users エラー内容をデータベースに保存するとかすると便利。 find_or_create_by_#{カラム名}ですでに存在する場合は、select, 存在しない場合は、insertを発行してくれる。 -for Rails users ARのwith_scopeを使えば、テーブルの操作対象を限定できますよ。不正な操作の防止にも使えるかも。 with_scopeで条件が衝突した場合は、findの場合は条件を追加, createの場合は、with_scope優先。 -for Rails developers scoped_accessプラグインを使えばコントローラのアクション全てにwith_scopeを適用できる。 ActiveRecord.allow_concurrensyをtrueにしていないとスレッドセーフでなくなるので注意。（Rails1.1ではデフォルトがfalse）

class ActiveRecord::Base def self.acts_as_view(options) scoped_methods << MethodScoping.new(options) end end class ActiveGrade2Member < ActiveMember acts_as_view :grade=>2 end

とクラスメソッドを定義すれば簡単に定義できてしまう！ すばらしい。 生成したSQLを文字列で受け取るメソッドがほしい 実行前のSQLをダンプする。サブクエリに便利。 ================================================== One controller, many ins, many outs David Heinemeier Hansson ================================================== DHHオトコマエ！ プレゼンもうまくて非常に盛り上がるセッションでした。 **REST HTTPメソッドだけでCRUDできるよね。複数個所に分かれているのはDRYじゃないし、

POST /people GET /people/1 PUT /people/1 DELETE /people/1

map.connect ':controller/:id'と宣言しておく。 form_forでmethodを定義 ブラウザのformでputやdeleteできないのでmethodはhiddenで渡す (javascriptで～～と言いかけて訂正していたのでjsのputやdeleteも使うようになるのかも) また、CRUDはゴールでなくゴールを目指す肝であり設計の技法ですよ。 **has_many :throughを使って交差エンティティを表現 多対多は取り除こう。 def join_users() endとかdef leave_group() endというメソッドはよろしくない。 **一つのコントローラで複数のMIMEタイプに対応してあげよう 拡張子、request.evn["Accept"]で判断して、respond_to {|format|}で返せばOK 携帯電話等は、before_filterでUAやIPで判断しmimetypeを追加 **ActiveResource DHH > 「XMLRPCもSOAPも使いたくない」 Rails1.2のtrunkにもまだ上がっていない様子のActiveRecordからCRUDを操作できるActiveResourceの話が面白い。URLをモデルの中に隠蔽して後は気にせず、AR同様に使うことができる。認証周りは、HTTP Authentication, Digest認証, SSLを誰かが作ってくれるかも。

Person = ActiveResorce::Struct.new do |p| p.uri "http;//www.example.com/people" p.credentials :name => "dhh", :password => "secreat" end david = Person.new(:name => "David") # GET http://www.example.com/people # David # => Location: http://www.exapmle.com/people/2 david.find(:name => "David") # PUT http://www.example.com/people # David Heinemeier Hasson # => (200 OK) david.save class ActiveResource::Base uri "http://www.example.com" credentials :name =>"dhh", :password => "" end

投稿者: UIE Japan 日時: 14:32 | パーマリンク | コメント (1) | トラックバック (3)

こんにちは、開発者ブログが立ち上がりました。 UIE Japan Developer Blogを見てくださいましてありがとうございます。 このブログではUIEJapanの技術的に何をやっていて、どうしたいか。 などを定期的にアウトプットしていきたいと思います。 記念すべき初エントリーは、日本Rubyカンファレンス2006レポートです。 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を独立にインストールしなければならなかったり。オープンじゃない使い方には独特の制約がある。緩いルールで使えるツールは似たような繰り返しに導入しやすい。

投稿者: UIE Japan 日時: 08:01 | パーマリンク | コメント (0) | トラックバック (0)