BERT

この辺で紹介したProtocol Buffers。
XMLの代替として使えるシリアライズバイナリデータ形式だったわけですけども。

Protocol Buffers/Thriftに対する動的な代替手段としてのBERT

BERTはASN.1やProtocol Buffersとは違って、フォーマットのスキーマやIDL仕様を必要としない。つまり、BERTはJSONの背景にある考え方のバイナリ版のようなものだ、とTom Preston-Werner氏は説明する。
(略)
BERT-RPCは、BERTを使って呼び出しの引数と戻り値をエンコードすることにより、BERT-RPCサーバにホストされているコードをリモートから呼び出すことができる。

あまりRemote Procedure Callを使うシーンには遭遇しないんですけど、スケールアウトがトレンドの昨今においては、マシン間での同期とかプロセス間通信を利用するシーンも案外増えるかもしんないなぁ、とか思ったり。

BERTのSpecificationはこちら。
BERT-RPCサーバのRuby実装はこちら。

デザインパターン

連休初日。

内職デイ。

今さらながらデザインパターンの重要性を再認識。

JavaとかC#とかで大きめの開発をやるときは、まずい設計だとソッコーで破綻するので、ときにはデザインパターンも参考にして「誰が実装しても同じようなコードになる」よーなアプローチを取り、品質が一定になるよう、スキルの差が生産性の差にならないよう、全体最適されるように開発を進めるんですけれども。

Rubyのよーに柔軟性の高い言語だと、言語側である程度問題を吸収してくれるというか、お任せできちゃうというか、わざわざデザインパターンを適用しなくても直感的なコードが書けちゃったりする。
ので、あんまりきっちりした設計はせずに、コードを書きながら設計を進めたりするんですけど。その分コードは何度も書き直すけど(でも生産性が高いので案外平気だったりする)。

んですけれども。
それでも、コードが増えてくると今ひとつエレガントじゃないコードになったり、拡張性が低かったり、自分しか分からなかったり、コードを読むための前提知識が必要だったりするよーな状況に陥ることが分かった。Rubyと言えども。

というわけで再読。

レシピになっているので、必要なところだけ読めばいいのは助かる。もう10年も前の書籍なのか。

Twitterで自分のつぶやきを取得する

Twitterを使っていると、日々つぶやきがトラッキングされるので、これを有効利用したくなってくる。
例えば、日報を作成したり、以前つぶやいたアイデアを見直したり。

ところが、Twitterでは過去の「自分の」つぶやきを検索することは基本的にはできない。1ページに20個までのつぶやきしか表示されないため、仕方なく「もっと読む」を何度かクリックし、都度ブラウザの検索を使って目的のつぶやきを見つけるとか、Googleのsite:オプションを使って検索するとか、若干空しい作業をしてきた。

で、最近、フォロー中の中にもそのよーなつぶやき(その1、その2)を見かけるようになったので、ざっくりTwitter APIを見てみたんですけど、やっぱり「ユーザを指定して語句を検索する」ようなAPIは提供されていない模様。

まぁ、大規模なユーザを抱えるTwitterでは、サーバに負荷をかけるような検索はできるだけ避けたいのかもしれないな、とも思える。

で、APIを眺めてると、最大200件のつぶやきは取得できるので、コレを使って定期的に自分のつぶやきをローカルのDBやテキストで保存しておき、ローカルで検索するしかないのかな、と。

ということで、直近の200件のつぶやきを取得するRubyスクリプトを書いてみた。
確認環境は久しぶりにMac OS X Leopard。RubyのバージョンはMacPortsでインストールした

ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin9]

1.8系。ライブラリが提供されていれば1.9系でもWindowsでも動くと思う。

まず、Twitter4RというTwitter API用のライブラリをインストール。

gem install twitter4r

スクリプトはコチラ。

require 'rubygems'
gem('twitter4r')
require 'twitter'

def url(id)
  "http://twitter.com/#{@login}/status/#{id}"
end

@login = 'your id'
password = 'your password'
twitter = Twitter::Client.new(:login=>@login, :password=>password)
twitter.timeline_for(:me, :count=>200) { |status|
  puts "#{status.id} #{status.text} #{url(status.id)}"
}

とりあえず、つぶやきのIDとその内容、Twitter上のURLが出力されるようにしておいた。

実行結果はこんな感じ。

Twitter APIの結果はUTF-8だとか書いてあった気がするので、もしかしたらWindowsのコマンドプロンプトだと文字化けするかもしんない。
適当に変換してください。

あとは、スクリプトをdaemonにして、たとえばつぶやきIDとかで比較して差分だけを保存するような形にしておけば、とりあえず、自分のつぶやきをトラッキングする、という目的は達成できると思う。

余裕があったらGAEとかでサービス化して公開するところなんですけど。

下記サイトに感謝。

• Twitter4R
• Twitter API 仕様書 (勝手に日本語訳シリーズ)

Windows + MeCab + Ruby

Googleでも使われているらしいし、Mac OS X Leopardにもインストールされているという形態素解析エンジンMeCab。

このMeCabをRubyから使おうとすると、通常はスクリプト言語用のバインディングを使うことになると思うんですけど、このRubyバインディングはWindows環境においてはそのままインストールできません。
C++のコンパイラがあればmakeできるらしいけど、まぁ、メンドいですな。どーしてもmakeを通したいヒトはMicrosoft Visual C++ Express Editionでも使えばいいんジャマイカ。

で、提供されているRubyバインディングにこだわらなければ、WindowsのMeCabをRubyから使用できます。

まず、IO.popenを使う方法。

Windows上のrubyでMeCabをちょっこっと使ってみたい

popenは実行ファイルをプロセスを起こして実行し、そのプロセスの標準入出力との間にパイプラインを確立するIOメソッド。MeCabは標準入力からの入力を解析し、標準出力に吐いてくれるので、popenを使えば操作できます。

解析の度にMeCabプロセスを起こすことになる(と思う)ので、リソースを消費するのと、性能が出ない(と思われる)のが難点と言えば難点。
でもまぁ、あるものを組み合わせて、サラりと解決するこのやり方はhackっぽくてケッコー好き。

解析の度にイチイチプロセス起こすなんてあり得ん!!という方は、DLLを直接呼び出すやり方をどうぞ。

windowsのrubyからlibmecab.dllを呼び出す

DLLのインターフェイスが分かっていればRubyから呼び出すのは比較的簡単だし、一度ロードしてしまえばRubyスクリプトがメモリに乗っかってる間は呼び出せるので、毎回プロセスを起こすpopen方式よりはコストが低いと思われます。

先人達の知恵に感謝。

個人的には、無理してDLL呼び出ししなくても、popen方式でRubyバインディングと同じインターフェイスのラッパークラスをローカルに準備するのが吉じゃないかと。
開発はWindowsで運用はLinuxで、というシーンを考えたときに、(Rubyバインディングが使用できる)Linuxに乗せる際の手間がなくなるよう腐心した方が幸せな気がします。

Pythonの次

マジか!!

グーグル、「App Engine」でのJavaサポートを発表

Google App Engineの次のサポート言語はJavaだったか…。
昨今の(Ruby等の)軽量動的言語にだいぶ押されてきたとは言え、WEB系じゃまだまだ人気というか、(ベンチャー系ではない)企業では未だにそれしか選択肢が無いかのような顔をしてのさばっている(失礼)JavaのGoogleによるサポートは、結構衝撃。

久しぶりにシビれた。

しかしまぁ、なんつーか。Javaとは…Google的じゃないような気もするし、Googleの本音を垣間見た気もするし。
App Engine、大化けするかもしれんなぁ。

Googleも必死ということかもしれない。

初めてのRuby

私信になってしまうけど、最近出たRuby本なら初めてのRubyがいいんじゃないでしょうか。オライリーの動物本にしてはめちゃくちゃ薄いし、日本語だし。

ワタクシも持ってますヨ。全部読んでないけど。(またかよ)

Rubyスクリプト言語がどういうものかをサラりと俯瞰するにはちょうど良いリファレンスだと思う。

賛否は知らないけど404 Blog Not Foundの書評でもわりと高評価。
小飼氏曰く、K&R本(プログラミング言語C)と同じような簡潔さ、だとさ。

あー、K&Rも…第2版を全部読み切った自信がないなぁ。

Flex on Rails

ｷﾀー!!!こういう本を待ってたんですヨ!!!

Flex on Rails: Building Rich Internet Applications With Adobe Flex 3.0 and Rails 2.0

って年末発売なのか…。

しかも洋書じゃねーか…。

翻訳版も同時発売していただきたい!!
っていうか、年末までに(技術)英語がスラスラと読めるようになってりゃいいんだよな。

さておき、k-nos氏がEvernoteに衝撃を受けたと聞いて、将来購入するかもしれないiPod touchやiPhoneのために…ではなく、職場とプライベートの間、WindowsとMac OS Xの間でメモとかシンクロしたい、という理由でEvernoteを導入してみたわけです。

一番簡単な同期方法として、今まではGmailとか使ってたわけです。言い換えると、プラットフォームに依存しないWEBアプリで同期を取ってたわけで、GmailのUIの秀逸さもあり、これはこれで便利っていうか、フツーに考えられる手法かな、と。

ただ、Flashはともかく、AjaxなWEBアプリだとインターフェイスに限界も感じつつあったり。上海の回線速度的にはFlashもキツいし。で、最近のクライアントアプリってどーなのよ、という観点でEvernoteを見てみると、…当たり前に楽勝なわけです。

これからまた、クライアントアプリが盛り返して来るんじゃないか、と思ったり。もちろん、サーバとの連携は必須なので、クライアント側はマルチプラットフォームなFlex使って、サーバ側はRailsだろ、とか思うわけです。
そこに"Flex on Rails: Building Rich Internet Applications With Adobe Flex 3.0 and Rails 2.0"登場。やっぱりニーズはあるんでしょーな。

まぁ、Flexはまだまだモッサリしてるし、Adobeがおさえているので、劇的に流行ることはなさそーだけど。

Protocol Buffers

Protocol Buffers:

Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler.

CNET Japanの記事によると

Protocol Buffersの目的は、サーバ間で多様なフォーマットのデータを高速で共有する際の問題を解決することだ。
(中略)
Protocol Buffersは、XMLの代替手段として、ネットワーク上でやりとりされるデータ形式や、ハードディスクに保存されるデータ形式を記述するものになる。

GoogleはこのProtocol BuffersをApache License, Version 2.0で公開。

異なるサーバ間あるいはプラットフォーム間のデータ共有は、確かにXMLを使用することが多いし、往々にして(プロジェクト毎に)独自実装だったりするわけだけど…。orz

公開されている実装はC++, Java, Python。Ruby実装かC#実装が出てきたら触ってみようかな。せめてJavaを触らんかい、というツッコミはナシで。

TwitterはRailsを放棄するか

/.-J経由、TechCrunch Japaneseの記事「Twitter、Ruby on Railsを放棄か」によるとRuby on Railsで構築されていることで有名なTwitterがスケーラビリティの問題からRailsを捨て、新たに構築し直される…かも、とのこと。

Twitterが登場し、猛烈な勢いで流行っていった当初、「これはすごい」と「どこが楽しいのか分からない」という両極端の意見の狭間で、傍観を決め込んでいたんだけど、k-nos氏がTwitterを始めたことに気づいて、最近自分もアカウントを作ってたり。

Twitterを使ってみた現在の感触は…まぁ、なんだろ、ネットに向かって大声でひとりごちるような変なシステムですな。blogを1日に何度もポストするような人には向いているかもしんない。blogほど構えなくてもいいし、チャットほどリアルタイムじゃない、ある意味ニッチなゆるーい雰囲気がウケたのかも、と今頃になって分析。

ちなみにワタクシのTwitter上のつぶやきはこちら。日本語対応直前くらいから使ってます。

で、システム系の業務から離れてしまったので、仕事でRailsを使用することは限りなくゼロに近づいちゃったんですな。「あのTwitterもRailsで動いているんですよ!!イキましょう!!Railsで!!」と上司を説得することは今後ないわけです。けど、それでもTwitterがRailsを本当に放棄するのか、注視していこうと思ったり。特にRailsをやめて、代替手段としてRubyを使用し続ける場合、どんな仕組みになるのかがウォッチしておきたい。

追記:2008年5月4日(日)22:53
builder by ZDNet Japanより「TwitterはRailsを捨てません」という記事。TechCrunch Japaneseも下記のようにフォローしている。

私に言えるのは「Twitterが、Ruby on Railsから離れる予定だと話している」と主張する筋が複数あるということだけだ。会社が後に100%ガチと分かることを否定するのは、これが初めてではない。

first attack

iPodのときも驚いたが、説明書の類はほとんどない。Appleらしいというかなんというか。割り切り方が半端じゃない。

なので、何も考えず起動ボタンをポチッ。フツーに起動し、ネットにもフツーに接続でき、だいたい直観的な操作でなんとかなる雰囲気。トラックパッドの日本指操作はソッコーで理解できたけど、クリックボタンが一つしかないのはなかなか慣れない。

で、最初に起動したアプリは"Safari"だったり。

そのあと、DockやFinderからいろいろとアプリケーションを起動してみて、Mac OS X文化の一部をざっくりと俯瞰。技術書の目次を眺めたり、パラパラとめくってみたりするのと同じ行動かもしれない。

トーゼン分からないことが出てくるので、その都度ネットで検索。便利な世の中ですな。

で、ネット上やローカルの探索中に面白そうなアプリケーションを見つけたりするんだけど、深追いはしないことに。実は根本的なことが分かっていないんでした。

アプリケーションのインストール方法やインストール先が分からない

Windowsだと、そもそもインストーラ任せだし、インストール先もProgram Files配下に置くか、他の場所に置くか、というノリもだいたい分かるし、基本的にコントロールできる。けど、Mac OS XってUNIXなんでしょ。まさかアプリケーションのソースが配布されてて、コンパイルして、配置して、テキストエディタで環境変えて、みたいなことはないと思うけど(そのよーなものもたぶん実際にはある)、aptみたいなパッケージ管理ツール使うのか?MacだとMacPorts?

ちなみに、UNIX系システムを触るときは、アプリケーションをどこにどのように配置するかというノリが分からないので、パッケージ管理ツールを使ったインストールしかしたことがなかったり。Debian GNU/Linuxだとaptですな。Debian系はUbuntuしか使ったことないけど。
RubyパッケージならRubyGemsなわけで。

ということで、いったん現実逃避してMac OS XにRuby on Railsをインストール。ターミナルを開いて

gem install rails -r

書き込み権限がないと言って怒られる。

sudo gem install rails -r

成功。
これで、MacでもRailsで遊べるなぁ。

で、逃避から戻ってきて、一般的なアプリケーションのインストール方法は…とりあえず、Firefoxは詳細なインストール方法が載ってたのでその通りに。

ふうん。ディスクイメージをマウントするのね。インストール後はアンマウントしちゃっていいのね。媒体として扱う感じか。ということはここがアレで、えーと…。

Mac OSの基本的なことが全然わかってないので、細かいところがいちいち新鮮。

で、最初にDockから削除したアプリも"Safari"だったり。