Big Sky

とは言ってもUser Agent Switcherが必要なのですが...

使い方は

:ua MyUserAgent

でUser Agent Switcherに"MyUserAgent"という名前で登録されたUser Agentに変更します。

:ua Default

でリセット

:ua!

で設定ダイアログ表示となります。
急遽モバイルページに行きたいけどメニューに手を伸ばすの面倒臭いって方には使えるかも。
ちなみに私はデフォルトで登録されていた物の他に、DoCoMo、Vodafone、SoftBank、Hatenaクローラ等のUserAgentを登録してます。

uaSwitch.js

よろしければどーぞ。

遅ればせながらGoogle Protocol Buffersで遊んでみました。

protobuf - Google Code
Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats.

まず、インストールは以下の様に行いました。なおprotobufを展開したフォルダは以下のフォルダ。

C:¥temp¥protobuf-2.0.0beta¥

cpp版のインストール

展開したフォルダのvsprojectsフォルダにある"protobuf.sln"をVisual Studioで開きReleaseビルド。
必要であれば環境変数PATHの通る場所へ"protoc.exe"、"libprotobuf.dll"、"libprotoc.dll"を置く。また"libprotobuf.lib"と"libprotoc.lib"はコンパイル時に必要になるので分かりやすい位置に置いておく。

java版のインストール

まずApache MavenをインストールしPATHを通す。
次にjavaフォルダへ移動し

C:¥temp¥protobuf-2.0.0beta¥java> mvn test install

とすれば必要なライブラリがダウンロードされ、テスト後インストールされる。
targetフォルダに"protobuf-java-2.0.0beta.jar"が出来るのでこれまた分かりやすい位置に置く。

python版のインストール

pythonフォルダに移動し、cpp版をビルドした際に出来上がった"protoc.exe"にパスが通っている事を確認して

C:¥temp¥protobuf-2.0.0beta¥python> python setup.py bdist_wininst
...
C:¥temp¥protobuf-2.0.0beta¥python> cd dist
C:¥temp¥protobuf-2.0.0beta¥python¥dist> protobuf-2.0.0beta.win32.exe

※Windowsじゃない人は"bdist_wininst"の代わりに"bdist_rpm"とか"install"とか...

テストコードによる検証

まずデータ定義となるprotoファイルを作る。詳しい説明は省略するが知りたい人はココとかココとか。今回は名前と年齢を格納出来るPersonクラスを扱う。
person.proto

package protocol;

message Person {
  required string name = 1;
  required int32  age  = 2;
}

このファイルを指定して、スタブクラスを生成する。
まずcpp版。

C:¥temp¥protobuf-2.0.0beta¥tmp> protoc --cpp_out=. person.proto

これで"person.pb.cc"と"person.pb.h"が生成される。以下テストコード。
test.cpp

#include <iostream>
#include <fstream>
#include <person.pb.h>

void save(const char* fn) {
    protocol::Person person;

    person.set_name("mattn");
    person.set_age(18);

    std::ofstream ofs(fn);
    person.SerializeToOstream(&ofs);
    ofs.close();
}

void load(const char* fn) {
    protocol::Person person;

    std::ifstream ifs(fn);
    person.ParseFromIstream(&ifs);

    std::cout <<
        "name:" << person.name() <<
        ",age:" << person.age() << std::endl;
}

int main(int argc, char* argv[]) {
    if (argc != 2) return -1;

    save(argv[1]);
    load(argv[1]);

    return 0;
}

ビルドは以下の手順で行う。

C:¥temp¥protobuf-2.0.0beta¥tmp> cl -I../src -I. /EHsc test.cpp person.pb.cc libprotoc.lib libprotobuf.lib

実行すると

C:¥temp¥protobuf-2.0.0beta¥tmp> test person_cpp.txt
name:mattn,age:18

と表示される。そう...18歳です。ウソです。
生成される"person_cpp.txt"は以下の様なファイルとなる。

^Emattn^P#

次にjava版。"person.proto"というファイル名からPersonクラスを生成する際にファイル名がバッティングしてしまうので"persons.proto"という別名にコピーしておく。

C:¥temp¥protobuf-2.0.0beta¥tmp> protoc --java_out=. persons.proto

"protocol/Persons.java"が生成される。
テストコードは以下の通り。
test.java

import protocol.Persons;
import java.io.FileInputStream;
import java.io.FileOutputStream;

public class test {
    public static void main(String[] args) throws Exception {
        Persons.Person.Builder personBuilder = Persons.Person.newBuilder();
        Persons.Person mattn = personBuilder.setName("mattn").setAge(18).build();

        FileOutputStream fos = new FileOutputStream(args[0]);
        mattn.writeTo(fos);
        fos.close();

        FileInputStream fin = new FileInputStream(args[0]);
        mattn = Persons.Person.parseFrom(fin);
        fin.close();

        System.out.printf("name:%s,age:%d", mattn.getName(), mattn.getAge());
    }
}

ビルドは以下の手順で行う。

C:¥temp¥protobuf-2.0.0beta¥tmp> javac -classpath protobuf-java-2.0.0beta.jar; test.java

実行結果はcpp版と同様。

最後にpython版。

C:¥temp¥protobuf-2.0.0beta¥tmp> protoc --python_out=. person.proto

"person_pb2.py"が生成される。以下テストコード
test.py

import sys
from person_pb2 import Person

fn = sys.argv[1]

person = Person()
person.name = "mattn"
person.age = 18
open(fn, "w").write(person.SerializeToString())

person = Person()
person.ParseFromString(open(fn).read())
print "name:%s,age:%d" % (person.name, person.age)

実行結果はcpp版、java版と同様。

所感

結局の所、"protocol buffers"とは、"Serialize Format"生成ツールおよびライブラリと、"Serializable"なクラス郡と言った所だろうか。
実際にはRPC等で転送してみないと良さは分からないかもしれないけど、XMLの様に自信がValidation可能な物ではなさそうなので転送の際には外側からデータのサイズ送信やチェックサム実施も必要になるかもしれない。
そういった意味では、「【ハウツー】XMLはもう不要!? Google製シリアライズツール「Protocol Buffer」 (2) ダウンロードとインストール | エンタープライズ | マイコミジャーナル」の"XMLはもう不要!?"には少し疑問を感じる。

時間があれば、ネットワーク上にシリアライズしたデータを転送してみたいと思う。

少しずつですがバージョンアップしています。

The Unofficial Blosxom User Group :: Blosxom 2.1.0 released

New features

• Support for external config files and multi-instance installations via environment variables. (Inspired and loosely based on the Debian patches for Blosxom 2.0.2.)
• Support for multiple plugin directories using $plugin_path and @INC.
• Support for configuring the plugins to use in a config file.
• The default feed templates are now in RSS 2.0 format and prevent duplicated stories in feed readers or aggregators if posts are changed after publishing using a GUID element in each feed item.
• There's now an encoding setting which controls what charset your blog and feeds should be marked as.

http://blosxom.ookee.com/blog/news/blosxom-2.1.0-released.html

バージョンアップの内容としては以下の通り。

• 環境変数によるconfigファイルの読み込み
• 複数のプラグインディレクトリをサポート
• configファイルによるpluginの設定が可能に
• デフォルトのRSSフィードがRSS2.0に
• encodingの設定が可能に

また幾らかのバグフィックスも含んでいます。さっそくこのサイトでも導入しました。大きな修正点はありませんでしたがRSS1.0からRSS2.0に修正した事でフィードリーダに更新が配信されてしまったかと思います。
configファイルはmod_envを使って

SetEnv BLOSXOM_CONFIG_FILE /path/to/my/blosxom/config/file/bloxsom.conf

とすることでblosxom.cgiを全く弄らずに動かす事が出来る様になりました。

しばらくは様子見です。

卑怯と言われようが構いません。

let X = "ひだまり"
let _ = "スケッチ"

try
  X / _ / X < また見て下さいね
catch /^Vim\%((\a\+)\)\=:E488/
  echo eval(
    \  substitute(
    \    substitute(
    \      v:exception,
    \      '^.*E\(\d\+\).*:\s*\(\(.\) / \(.\).*\). <\(.*\)$',
    \      '\2"\3".(\1-123)."\5"', ''), '/', '.', 'g'))
endtry

http://subtech.g.hatena.ne.jp/cho45/20080708/1215450151
http://subtech.g.hatena.ne.jp/miyagawa/20080708/1215473551

#!/usr/bin/env python
# -*- coding: utf-8 -*-

class X:
  def __init__(self):
    self.s = "ひだまり"

  def __lt__(self, v):
    print "%s %s" % (self.s, v)
    return self
 
  def __div__(self, v):
    if isinstance(v, int):
      self.s += "スケッチ"
    else:
      self.s += "365"
    return self

X = X()
_ = 1

X / _ / X < "来週も見てくださいね!"

ごめんなさい。それが何かしらない...orz

twitter APIはXMLにリクエスト投げてもBUSY画面でtext/htmlなヘッダを返す時があるので、gtktwitterでは応答ヘッダがapplication/xmlじゃ無いときは処理しない様にしてあったんですが、wassrpod.plはAPI応答にtext/htmlを返していたので少し手を入れさせて頂き、見事gtktwitterでwassrにポストする事が出来ました。あとプロフアイコンもPROXY経由で取れる様に修正しました。おかしかったら直して下さい(id:yappo)

動かすには、環境変数「HTTP_PROXY」に「localhost:9277」を設定してgtktwitterを起動すればok。ただtwitterの設定が残ってるだろうから、UN*Xならば「~/.config/gtktwitter/config」を、Windowsならば「~/Application Data/gtktwitter/config」を修正して起動して下さい。同じアカウント名使ってるならばそのままでも動くかも。

ま、gtkwassrもあるんですけどね...

関連URL:YappoLogs: WassrPodというMacからwassrを快適に使うツールを作ったよ

TheSchwartzも良いのですが、MySQLが必要だったりポーリングのタイムラグがあったりと、要件に合わない場合というのも出て来たりします。こんな時はどうするか、解決策の一つにメッセージバスがあります。
メッセージバスとして一般的に有名なのが、DBusです。Linux等では数多くのアプリケーションが採用しており、GNOMEもBonoboからの移行を表明、KDE4でも採用される様です。ちなみに私が愛用している軽量デスクトップROXは当初に採用しており、ちょっとしたpythonのコードでリッチなアプリケーション間通信が実現出来ています。他にも既に色々なプロジェクトでDBusが使われています。
さて今日はNet::DBusを使い、TheSchwartzと似たような事が出来ないかをWindows上でやってみようかと思います。
まず、DBusのWindows実装であるwinDBusをインストールします。winDBusはこちらで配布されておりバイナリもダウンロード出来ます。
ここでまず、DBusの動作を確認します。winDBusを展開したディレクトリの中のbinフォルダに移動し以下の様にしてデーモンを起動します。

C:¥winDBus¥> dbus-daemon.exe --config-file=C:/winDBus/dbus/bin/session.conf

winDBusを"C:¥Programme"に展開された場合には

C:¥Programme¥> dbus-daemon.exe --session

とするだけでも動作します。winDBusの場合、unixドメインソケットをサポートしていませんので、上記session.confに書かれている

<listen>tcp:host=localhost,port=12434</listen>

の値を環境変数「DBUS_SESSION_BUS_ADDRESS」に設定します。

set DBUS_SESSION_BUS_ADDRESS=tcp:host=localhost,port=12434

その上でdbus-daemon.exeと同じ位置にあるtest_names.exeを実行し

Successfully acquired name 'org.freedesktop.DBus.Test'
Successfully acquired name 'org.freedesktop.DBus.Test-2'
Successfully acquired name 'org.freedesktop.DBus.Test_2'

と表示されれば動作確認は終了です。
次にNet::DBusをインストールします。まずNet::DBusはビルドにpkg-configを使うので`pkg-config --cflags dbus-1`が扱えないVCではビルドに難があります。私の場合はMinGWを使用しました。
まず、winDBusに同梱されていなかったdbus-1.pcを作成します。winDBusをインストールしたディレクトリを指定して

prefix=C:/winDBus/dbus
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: D-Bus
Description: D-Bus Protocol Library
Version: 0.90
Libs: -LC:/winDBus/dbus/lib -ldbus-1
Cflags: -IC:/winDBus/dbus/include

という内容でdbus-1.pcを保存します。次に環境変数PKG_CONFIG_PATHにこのdbus-1.pcを保存したディレクトリを設定し、cpanからインストールします。おそらくこれでインストール出来るかと思いますが、出来なかった方はVCのコンパイラのパスを外し、MinGWのパスを設定して確認して見て下さい。
これでようやくperlからDBusを使える準備が揃いました。
さて、サーバのソース。DBusのセッションからバスを取得し、サービスをエクスポート、ワーカーの役目をするオブジェクトを作成します。ワーカーオブジェクトにはJobStartというメソッドを定義します。

#!/usr/bin/perl

use strict;
use warnings;
use threads;
use YAML;
use Net::DBus;
use Net::DBus::Service;
use Net::DBus::Reactor;

package MyWorker;
use base qw(Net::DBus::Object);
use Net::DBus::Exporter qw(net.kaoriya.mattn.DBusWorker);

sub new {
    my $class = shift;
    my $service = shift;
    my $self = $class->SUPER::new($service, "/MyWorker");
    bless $self, $class;
    
    return $self;
}

dbus_method("JobStart", [["dict", "string", "string"]], [["dict", "string", "int32"]]);
sub JobStart {
    my $self = shift;
    my $job = shift;
    my $thread = threads->new(sub {
        my $job = shift;
        printf "processing job%03d : %s\n", threads->tid, $job->{request};
        sleep 10;
        printf "done job%03d\n", threads->tid;
    }, $job);
    return { "id" => $thread->tid };
}

package main;

my $bus = Net::DBus->session();
my $service = $bus->export_service("net.kaoriya.mattn.DBusWorker");
my $object = MyWorker->new($service);
Net::DBus::Reactor->main->run();

DBusは非同期通信も提供していますが、リクエストを連続で送った際サーバがビジー状態だとクライアントが側が応答を待ってロックします。
そこで上記ソースではスレッドを起こし、重たい処理をさせる様になっています。スレッド内では"threads->tid"で言わばジョブ番号の役割をするスレッドIDを使ってユニークな処理が出来るかと思います。
さらにクライアントのコード。

#/usr/bin/perl

use strict;
use warnings;

use Net::DBus;
use Net::DBus::Reactor;
use Net::DBus::Callback;
use Net::DBus::Annotation qw(:call);

my $request = shift @ARGV || 'request at '.time();
my $bus = Net::DBus->session();
my $service = $bus->get_service("net.kaoriya.mattn.DBusWorker");
my $object = $service->get_object("/MyWorker");
my $res = $object->JobStart({ request => $request });
printf "job was accepted as job%03d\n", $res->{id};

DBusセッションからもらったMyWorkerオブジェクトのJobStartメソッドにリクエスト文字列を指定して送信します。
まずクライアントの実行結果は

C:¥winDBus¥test¥> perl client.pl
job was accepted as job001
C:¥winDBus¥test¥> perl client.pl
job was accepted as job002
C:¥winDBus¥test¥> perl client.pl
job was accepted as job003

クライアントではjob001を実行した後、10秒待ってjob002、job003を投入しました。そしてサーバの実行結果

processing job001 : request at 1214560175
done job001
processing job002 : request at 1214560192
processing job003 : request at 1214560195
done job002
done job003

おぉ！非同期ですね！
DBusでは、引数の構成および戻り値の構成をdbus_methodにて指定でき、文字列(string)や数値(int32等)、配列(array)、タプル(tuple)、構造体(struct)を引き渡したり、戻り値として返したり出来ます。
さらに、Net::DBusに同梱されている"example-client-async.pl"の様に非同期送信結果を受け取り、完了イベントで結果を受け取るという事も出来ます。

#/usr/bin/perl

use warnings;
use strict;

use Net::DBus;
use Net::DBus::Reactor;
use Net::DBus::Callback;
use Net::DBus::Annotation qw(:call);

my $bus = Net::DBus->session();

my $service = $bus->get_service("org.designfu.SampleService");
my $object = $service->get_object("/SomeObject");

print "Doing async call\n";
my $reply = $object->HelloWorld(dbus_call_async, "Hello from example-client.pl!");

my $r = Net::DBus::Reactor->main;

sub all_done {
    my $reply = shift;
    my $list = $reply->get_result;
    print "[", join(", ", map { "'$_'" } @{$list}), "]\n";

    $r->shutdown;
}

print "Setting notify\n";
$reply->set_notify(\&all_done);

sub tick {
    print "Tick-tock\n";
}


print "Adding timer\n";
$r->add_timeout(500, Net::DBus::Callback->new(method => \&tick));

print "Entering main loop\n";
$r->run;

今回はWebで扱いやすい様に、非同期で結果を待機する処理ではなくサーバ側でスレッドを実行していますが、デスクトップクライアントを作る際にはdbus_call_asyncを使う事になるかと思います。

TheSchwartzも面白いですが、DBusも面白いですね。
perlの他にも、C(GLib)はもちろんpythonやJava等でも実装されています(参照)。
皆さんも試してみては如何でしょうか。