カテゴリー
技術

スクリプトの exe ファイル化ツールとそのマーケティング的意義

RubyScript2Exe という、Ruby スクリプトを Windows の .exe ファイルにするツールが出ていたのを見つけた。(Linux や MacOSX の実行ファイルにもできる)

この手のラッパーとしては、Java でも Exe4J, NativeJ, JexePack などいろいろある。JSmooth などは以前試したことがあるが、無料のわりに便利に使うことができたという印象がある。

この手のツールは、要するに、作成したアプリケーションと一緒に、アプリケーションを実行するためのインタプリタも一緒に配ってしまおう、というラッパー作成ツールだ。

たとえば、Ruby インタプリタや JRE などを zip ファイルとして同梱し、「任意の場所に展開して、○○.bat を実行してください」でも同じことは達成できるんだが、この「zip を展開し」とか「○○.bat を実行し」という手順の合間で、ぼろぼろとアプリを使ってくれる人は減っていく。

zip を展開したりバッチファイルを実行したりするぐらい、ソース持ってきてパッチを当てたり make を走らせたりするプログラマーという人種から見れば、ほとんど無きに等しい所作だが、アプリケーション、特に商用アプリケーションを作るのであれば、一般ユーザの視点に立って、アプリケーション起動までのステップ数をいかに減らすか設計していくことが重要だと思う。

簡単インストールに命をかけるサイボウズ製品も、あくまで .exe インストールやインストール後の自動起動にこだわっている。また、ウェブサーバがなければ同梱したウェブサーバを入れてしまうし、DBサーバについても、同梱(Garoon2)だったり内蔵(その他)だったりと、完結した「一つのアプリケーション」としか見えないように工夫を凝らしている。

JSmooth + Jetty + HSQLDB とか、 RubyScript2Exe + Lighttpd + SQLite とかをうまく組み合わせると、製品をより簡単に多くの人に届けることができるかもしれない。

# Ruby でかかれた DBMS ってあるんでしょうか? > Rubyist な方

カテゴリー
技術

Ruby Tシャツ

Rails の流行もあってなんだか勢いのある Ruby だが、RubyStuff という Ruby グッズのオンラインショップが、かなり挑戦的な Ruby Tシャツを売っているのを発見。

こんなんとか、
こんなんとか、
こんなんとか。

ま、面白くていいけど。

Java ファン(最近触ってないけど)としては、あえて Java 禁止シャツを着るというのも洒落てていいかもしらん。

カテゴリー
技術

Atom Publishing Protocol の用途と将来

2006 年のネット開発に向けて覚えるべき技術 のコメントで、Atom PP が何に嬉しい技術なのかいまいち掴めていないため、自信のない書き込みをしたところ、kwmr さんから Yoshimatsu さんの面白いブログのエントリを紹介いただいた。

バックエンド側からの情報注入の口として Atom Publishing Protocol は重要になるだろう、という話。

個々の企業から情報を提供させて、それらをまとめて提供する「場」を作ることで生計を立てているネットサービスというのがある。Yoshimatsu さんが言及されている Amazon はもちろんそうだし、Kakaku.com , ぐるなび, Home’s なんかもそう、 Vector とかも提供者に個人が多いが同様ではないか。

これらの情報集積型ネットサービスは、当初は運営者が手作業で情報を入力したり営業をかけていたものが、情報量の増加とそれによるユーザ数の増加に伴って力関係が逆転し、今では情報提供側がお願いして/料金を払ってでも載せてもらうという形になってきている。これらのサービスで検索されないということは、ネット経由で探しているユーザ達にとっては世に存在しないも同様だからである。

当然、これらのサービス運営者達が情報を提供させるためのフォーマットやインタフェースを整備しているのは間違いないだろう。PC ショップはともかく、町の不動産屋やレストランのオーナーに CSV だの XML だのを直接書かせられるはずもない。実際にどうやっているのか知らないが、整備されたデータ更新専用のウェブサイトなり独自の PC クライアントなりが提供されているはず。

では、そういった情報注入側のインタフェースに関して、Atom PP 対応が進むか、と聞かれると、サービス側にあまりメリットが無いのではないか。新しく作る際に、都合のよいライブラリが揃ってるから、という理由で Atom PP を採択することはあるだろうけど、もし既存の独自プロトコルを使っているなら、それを Atom PP に置き換える意味までは無いように思う。

サービス提供側にしてみれば、同じデータを競合のところに簡単に持っていかれては困るわけで、たとえば Kakaku.com に価格情報を登録するインタフェースが Atom PP としてオープンになっていたら、Kakaku.com の競合サイトは「Kakaku.com と ○○ と △△ に一括登録できるクライアントツール」みたいなのをより簡単に作って配れてしまうのでは。ま、もちろん、クローズトなプロトコルであっても同様のツールは作れるだろうので、それだけで参入障壁とはいえなくても。