先日、第3回フクオカRuby大賞の本審査に行ってきましたが、その結果が発表されました。
応募していたるりまサーチはコミュニティ特別賞に入っていました。認めてもらえてよかったです。
るりまサーチでるりまが便利だと感じた人はるりまプロジェクトにも参加してみてはいかがでしょうか?また、何か最近Rubyで作ったシステムがあれば、来年のフクオカRuby大賞に応募してみてはいかがでしょうか?
kdmsnrさんが設定していたFacebookコメントプラグインがうらやましかったので、ククログにもつけてみました。ククログはtDiaryを使っていますが、CGIやRackで動かすのではなく、オフラインで静的なHTMLに変換してからWebサーバーにアップロードしています。そのため、tDiaryが持っているツッコミ機能は使っていません*1。
追加でfacebook_comments.rbを使おうとしたのですが、section_footer2.rbと衝突するのでやめました。また、section_footer2.rbに以下のような不満がありました。
そこで、section_footer2.rbが提供している機能のうち必要なものだけと、facebook_comments.rbの機能を合わせたsection-footer-social-widgets.rbプラグインを作りました。上記の不満や衝突問題は解決しているのですが、設定画面には対応していないので、簡単には使えないでしょう。同じようなことをしたかったら参考になるかもしれません、という程度の扱いのものです。
興味があったら見てみてください。
*1 tDiaryなのに。
システムの情報をFirefoxのツールバー上に表示するアドオン「システムモニター」のバージョン0.6バージョン0.6.1*1をリリースしました。以下のリンク先からダウンロードできます。
前のバージョンからの主な変更点は以下の通りです。
このバージョンから、Firefox(Thunderbird)自身のプロセスが使用しているメモリの量*2を取得できるようになりました。全体の消費メモリのうちのどれだけをFirefoxが使用しているのかを、グラフによって視覚的に確認する事ができます。
また、グラフの背景自体の透明度を変更できるようになったため、Personas(軽量テーマ)と組み合わせて利用しやすくなりました。
このバージョンではFirefox 4への対応にあたって、バイナリ形式のコンポーネントの代わりにJavaScriptベースのモジュールを使用するように実装を改めました*3。
この新しい実装は、Firefox 3.6以降で導入されたjs-ctypesという技術に基づいています。Firefox 4では構造体による情報の受け渡しが可能になった事により、バイナリ形式のコンポーネントを開発せずにこのようなアドオンを簡単に実現できるようになりました。これまではビルド環境を整えるのが難しかったために対応できていなかったような環境でも、低レベルな処理が必要なアドオンを開発しやすくなっています。
Firefox 4に対応したシステムモニターの新バージョンをリリースしました。Firefox 4ではこのような、低レベルの層と連携して動作するアドオンも開発しやすくなっています。
クリアコードではMozilla・メール・検索関連を中心にソフトウェア開発を行っています。徐々に認知されてきたおかげで、声をかけてもらえることが増えてきました。しかし、大変残念なことにリソース不足ですべてのお話に応えることができないのが現状です。
そこで、現在、プログラミングが好きなソフトウェア開発者を1名募集しています。応募方法などはリンク先を参照してください。ただ、リンク先では「Mozilla・メール・検索関連」で使うことが多い技術にはあまり触れていないので、ここで簡単に紹介します。
Mozilla関連ではJavaScript・C++・XULなどを使うことが多くなります。アドオンを開発する場合はUxUを用いた自動テストを作成しながらの開発になります。
また、Firefox/Thunderbird本体のソースコードを読んで問題を解析するなど、突っ込んだ調査をこともあります*1。このような作業の場合、すべてのソースコードを把握していることよりも、把握していないソースコードでも的確に問題を解析できる技術が重要になります。このような技術はフリーソフトウェアの開発に関わっていると身につきやすい技術ですね。ふだんのフリーソフトウェアの開発で身につけた技術を役立てることができます*2。
メール関連ではC・Rubyを使うことが多いです。ベースシステムに近い部分なので、シェルスクリプトを使う機会も多少はあります。
Rubyといっても、ふつうではないRubyの使い方が多くなります。メールシステム自体はパフォーマンスが要求されることが多いため、より速度がでるCと密に連携したり、より並行処理に向いた処理方法*3を採用したりします。milter managerがまさにそのようなことをしています。
Ruby on Railsなどフレームワークの上で開発する場合は、いかにうまくフレームワークと連携するかが重要となりますが、このような使い方の場合は新しく最適な解を切り開いていくという違った技術が必要になります。
検索関連でもC・Rubyを使うことが多いです。速度を犠牲にしないためにCと密に連携する部分はメール関連と同じですが、作業範囲はもっと上位のレイヤーまで広がります。高速な検索サービスを提供するWebアプリケーションやWeb APIの開発をする場合はRackやRuby on Railsなど、RDBを用いたWebアプリケーションでも使われている技術を利用します。
速度をカリカリにチューニングする検索エンジンの改良からリッチなユーザインターフェイス・APIの開発までシステム全体に関わることになるため、幅広く技術を活かすことができます。また、業務の中で技術の幅を上のレイヤーにも下のレイヤーにも広げていくことができます。
検索に関してはgroongaの開発者である森さんが書いた「検索エンジンはなぜ見つけるのか」がおすすめです。検索について優しく書かれているので検索に関してあまり知らない人でも理解を深めることができます*4。
ソフトウェア開発者を募集しているので、業務で必要になりそうな技術を紹介しました。クリアコードではこれらの技術を身につけるにはプログラミングが好きであることがとても重要な要素だと考えているため、応募資格はプログラミングが好きなことだけとなっています。
また、クリアコードでは業務で開発したソフトウェアはできるだけ自由に利用できるようにしています。業務で価値のあるソフトウェアを開発し、それをさらに広く自由に使ってもらいたいプログラミングが好きな人は応募してみてください。
*1 場合によってはパッチを書きます。
*2 まだそれほどでもない場合は業務の中で伸ばしていくことができます。
*3 CRubyではグローバル・ロックがあるので1プロセス複数スレッドよりも、マルチプロセスにしたりI/Oを多重化したりするなど。
*4 詳しい紹介はまた後で。