ウノウラボ Unoh Labs

ソーシャルスクラップブック「clipp」とImageFlow

五十川です。

ウノウではただいま「clipp（クリップ）」と名付けた新しいサービスを試験的に公開しています。これはソーシャルブックマーク＋ミニブログといった体のもので、ページのURLやタイトルに加えて、文章の抜粋や画像のサムネイルなどに、自分のコメントを添えて登録できるというもので、気になったページを“切り貼りして”保存し、他者と共有する、“ソーシャルスクラップブック”といった趣のサービスです。

※ clippは試験公開ということで現在は招待制とさせていただいておりますが、興味をお持ちいただいたかたは、clippのユーザ登録ページからメアドを登録しておいていただくと、招待状を送付させていただけると思いますので、是非どうぞ。

さて、clippでは画像を扱えるという特徴を活かして、画像をiTunes/iPodのCoverFlow風に表示する機能を用意してみました。

clippの各ユーザ毎のページには、サイドバーなどに「ImageFlow」というリンクがあるのですが、これをクリックすると、下図のように、そのユーザが登録している最新のサムネイル画像が一覧表示され、マウスのホイールやキーボードの矢印キーなどを使って、画像を次々「めくって」表示することができます。

ImageFlow JavaScript for clipp posted by (C)フォト蔵

この「ImageFlow」はオリジナルのものではなく、既によく知られているFinn Rudolphさん作のImageFlow JavaScriptを若干改変し、Ajaxによる処理などclippで必要な機能を追加したものです。

Finn RudolphさんのImageFlowの原型は、Michael L. Perryさんが、スクラップブックのコンサルタントである夫人の作品を紹介するために作られたCover flow in Javascriptだそうです。Finn Rudolphさんのものはこれに、Adomas PaltanaviciusさんのMouse wheel programming in JavaScriptを利用したマウスホイールの制御をはじめとしたさまざまな改良を施されたものです。

ImageFlowはプレインのJavaScriptで他のライブラリなどに依存しないので、改変が比較的容易で、Finn Rudolphさん自身によるHacked version for Lightbox2やHacked version for Highslide JSなどの画像エフェクトライブラリとの組み合わせや、Tobias Wetzelさんによるmootoolsフレームワーク用のMooFlowなど、さまざまなバリエーションが作られています。

clippのウェブサイトで配信されるJavaScriptはYUI Compressorでminifyしたものなので、以下にminify前のソースを掲載しておきます。

ImageFlow JavaScript for clipp

※ これはあくまでclipp用で、汎用のものではないので、そのまま利用いただけるわけではありませんが、なんらかの参考になるようでしたら幸いです。

おまけ: リフレクション画像（鏡像）について

iTunes/iPodのCoverFlow風表示にはリフレクション画像が必須ですが、Finn RudolphさんのImageFlowではこれを、GD2を使った、Richard DaveyさんのEasy PHP Reflectionsで動的に作成しており、これは配布パッケージにも同梱されてます。一方Imagick PHPを使ってリフレクション画像を作成する手順は、Imagick PHPの開発者Mikko Koppanenさんのブログの記事、Creating a reflectionに掲載されています。またMooFlowでは、リフレクション画像をCanvas要素などを使ってクライアント側で描画するように改良されています。

日時: 18:04 | パーマリンク | コメント (0) | トラックバック (0)

Mercurialでバージョン管理

stoplightで最大化したターミナル上でzshとscreenとEmacsを立ち上げ、明朝体フォントでプログラミングするbokkoです。

今回はバージョン管理システムの1つであるMercurialについて紹介します。

ウノウではSubversionとTracを組み合わせて開発を行っていますが、僕個人では今年の春ぐらいからEmacsやzsh、screenなどの各種設定ファイルをMercurialでバージョン管理しています。

Mercurialとは？

Mercurialは分散型のバージョン管理システムです。これに対して、CVSやSubversion(以下SVN)は集中型のバージョン管理システムにあたります。分散型と聞くと難しそうなイメージがわくかもしれませんが、 CVSやSVNに比べてると、より手軽にバージョン管理を行うことができるというのが、 Mercurialに対する僕の印象です。というのもCVSやSVNでは、まず単一のリポジトリを作成した後、バージョン管理したいファイルをリポジトリにimportして、コピーをチェックアウトし、コピーを編集してからその差分をリポジトリにコミットします。これに対して、Mercurialではバージョン管理の対象そのものがリポジトリになります。このため、単に1つのマシン上で編集の履歴を保持したりするだけの場合、集中型よりも手軽に扱うことができます。もちろん、複数のマシンでファイルの同期を取るといったことも可能です。

続きを読む "Mercurialでバージョン管理" »

日時: 16:50 | パーマリンク | コメント (0) | トラックバック (0)

コマンドラインから使うBitTorrentクライアント

yukiです。

唐突ですが、BitTorrentクライアントは何をお使いでしょうか？これまで私はずっとBitComet を使ってきましたが、私の非力な自宅マシンだとどうしても負荷が高く、その間は何も出来ないような状態に陥っていました。GUIから使おうとすると、見やすさや使いやすさはさすがに良いのですが、あまりの負荷とその間何も出来ない状況はあまりよろしくないと考え、今回はUNIX系でCLIから操作できるクライアントはないだろうか、と探していて見つかったEnhanced CTorrentをご紹介することにします。

Enhanced CTorrentは、C++で書かれたCtorrentをベースにしたBitTorrentクライアントです。Ctorrentからバグフィックスや改良・軽量化を重ねており、現在のバージョンは3.3.1になっています。

Enhanced Ctorrentは現在はSorceforgeでバグレポートやダウンロードができますので、早速使ってみました。

インストール

インストールは非常に簡単で、普通にwgetで落としてきて展開し、configureしてmake installします。

% wget http://jaist.dl.sourceforge.net/sourceforge/dtorrent/ctorrent-dnh3.3.1.tar.gz
% tar zxvf ctorrent-dnh3.3.1.tar.gz
% cd ctorrent-dnh3.3.1
% ./configure
% make
% sudo make install

torrentファイルからダウンロードする

早速torrentファイルをダウンロードして、ダウンロードしてみましょう。やり方は非常に簡単で、これだけです。

ctorrent [torrent.file]

これだけで同じディレクトリ内にダウンロードが開始されます。
注意点としては、デフォルトだと2706-2106番ポートを使うようになっていますが、オプションでポートを指定することが出来ます。とても簡単なうえ、デーモンとして起動することも出来ますのでバックグラウンドで動作させたい場合にも非常に便利です。

日時: 13:05 | パーマリンク | コメント (0) | トラックバック (0)

Javaコードのバグを発見するFindBugs

こんにちは。中村です。

Javaコードをコンパイルしたクラスファイルからバグを見つけ出すFindBugsというツールを使ってみました。

FindBugsは単体で動作しますが、IDEのプラグインとしても提供されています。今回はEclipseのプラグインを試してみました。

プラグインの導入

SourceForgeのダウンロードページからedu.umd.cs.findbugs.plugin.eclipse_1.3.3.20080401.zipを取得して解凍、Eclipseディレクトリのpluginsに置くだけといういつも通りな感じです。

使い方

プロジェクトのプロパティから通知する問題を選択したりと色々設定が出来ますが、単純に使うにはJavaプロジェクトのところで右クリック -> Find Bugs -> Find Bugsをクリックするとプロジェクトを調べて問題箇所にマーカーを付けてくれます。

使ってみる

早速無茶なコードを書いてみました。

FindBugs posted by (C)フォト蔵

すると、このようにバッチリと問題点が指摘されました。実行してNullPointerExceptionの発生箇所の行数を見るよりはこちらの方が一目瞭然で判りやすいと思います。

次に書いてはいけないコードの類をやってみました。

package net.unoh.findbugstest;

public class FindBugsTest {

    public static void main(String[] args) {
        Thread thread = new Thread();
        thread.run();
    }

}

すると次のように問題点が指摘されました。

[Ru] スレッドの中で run を実行しています。(本当は startを代わりに呼び出すべきではないのですか？)。 [RU_INVOKE_RUN]

このメソッドは、オブジェクトのrun()メソッドを明示的に呼び出しています。一般にRunnableを実装したクラスは、新しいスレッドがrun()メソッドを呼び出す事を期待しており、この場合、Thread.start()を呼び出すのが正しいやり方です。

こうした説明文がしっかりと表示される（しかも日本語で）点からすると、教育目的で使うのも良いかもしれません。

他に同じようなことをするものにLint4jなどがあるようなので、今度比較をしてみたいなと思います。

日時: 17:26 | パーマリンク | コメント (0) | トラックバック (0)

MacPorts の使い方と開発方法について

こんにちは、naoya です。

先日、社内の勉強会で MacPorts の使い方から Ports の追加方法まで幅広く紹介しました。MacPorts は、FreeBSD の ports が元になっていると聞いていましたが、バイナリバッケージまで作れるとは知りませんでした。

詳しくは、資料を参照してください。

なお、資料の中で Ports で追加している bat というプログラムは、Global standard programming with GNU Autotoolsで紹介されているプログラムです。

日時: 11:29 | パーマリンク | コメント (1) | トラックバック (0)

PHPでDocTest

yamaokaです。

何かソースコードを書いた場合、皆さんはどのようにテストをしていますか？　PHPの場合、PHPUnitやSimpleTestを使ってユニットテストをすることが多いと思います。でも、ユニットテストのために新しいファイルを作ってメソッドを実装したりするの、面倒くさくないですか？

Pythonには標準でDocTestという仕組みが付いています。詳細はPythonのドキュメント（日本語）を参照してもらうことにして、簡単に言うと、実際のソースコードの中にコメントとしてテストケースを書いてしまおうというアイデアです。

「実際のソースコード＝テストケース」になるのですから、メソッドを修整したからテストケースも修整して…という手間が少なくて済みますよね。そうしたDocTestの仕組みを、PHPに移植しようとする試みを紹介します。

rhacoのDocTest

rhacoは「PHPのライブラリパッケージ／セットアップアプリケーション」です（公式サイトより）。rhacoのソースコード自体にDocTestが記述されているので、サンプルとして見るにはちょうどいいでしょう。webアプリケーションフレームワークとして利用する以外に単にライブラリとして利用することもできるので、rhacoを利用していないソースコードのDocTestをrhacoを使って行うことも可能です。

さっそくDocTestを試してみましょう。次のようなFooクラスを用意します。

<?php
class Foo
{
    function bar()
    {
        /*** eq('bar', Foo::bar()); */
        return 'bar';
    }
    function baz()
    {
        /*** #pass */
    }
}

「/*** … */」で囲まれた箇所がDocTestのテストケースとして処理されることになります。今はテストしないとか、テストコードをまだ書いていない場合は「#pass」と書いておけばスキップされます。

次に、テストを実行するためのtest.phpを準備します。

<?php
require_once 'path/to/rhaco/Rhaco.php';
Rhaco::import('util.DocTest');
DocTest::execute('Foo.php');

そして、test.phpを実行してみます。

$ php -q test.php success: 1 / fail: 0 / pass: 1 / none: 0 / all: 2

(Foo::baz:line. 9)PASS Foo.php

テストが実行されましたね！　試しにFoo::barのテストコードを「/*** eq('barrrr', Foo::bar()); */」に書き換えて実行しなおすと、次のようにきちんとエラーになります。

$ php -q test.php

success: 0 / fail: 1 / pass: 1 / none: 0 / all: 2

(Foo::bar:line. 4)FAIL expectation [string(6) "barrrr"

] : Result [string(3) "bar"

]

(Foo::baz:line. 9)PASS Foo.php

値の一致をテストする「eq」コマンド以外にもテスト用のコマンドが用意されているので、詳しくはrhacoのソースかドキュメントを参照してください。

その他のDocTest

その他のDocTestの試みとしては、現在次のバージョンが開発されているwebアプリケーションフレームワーク、MapleのDocTest導入の試みがあげられます。また、同じくwebアプリケーションフレームワークのsymfonyでも、sfDocTestPluginが開発されています。

PHPのライブラリ集、PEARでは、まだアルファ版ですがTesting_DocTestがリリースされています。

最後に

rhacoのDocTestを中心に紹介しましたが、いかがでしょうか。テストコードを記述する負担をできるだけ軽くする試みとして、DocTestは面白いと思います。反面、ソースコード中にテストコードが混在するので、ソースコードが見づらくなるといった欠点もあります。そうした場合、従来のユニットテストと併用するのも手ですね（rhacoの場合、DocTestからユニットテストを実行できます）。いろいろなテストコードの書き方がありますが、選択肢の一つとして考えてもよいのではないでしょうか。

日時: 11:52 | パーマリンク | コメント (0) | トラックバック (0)