にぽたん研究所

弊社の、とあるエンジニアだけが集まるミーティングで、毎週ライブコーディングでアルゴリズム勝負をやるみたいなコーナーを設けてたりします。
毎週ベンチマーク対決をやり、最強のやつに勝てるアルゴリズムで挑戦します。

#!/usr/local/bin/perl

use strict;
use Benchmark qw(:all);

my @args = qw(foo bar baz);

cmpthese(100000, {
    champ => sub { champ(\@args) },
    yours => sub { yours(\@args) },
});

# winner
sub champ {
    my $args = shift;
    # do something
}

# your code here
sub yours {

}

実際のものはもっと数多くのベンチマークのパターンがあるのですが、こんな感じの雛形があって、champ() の中身は憎き歴戦の猛者が。
その猛者に対抗し得るコードを、衆人環視の中 yours() のブレースの中に書かなくちゃいけないとか。だいぶ厳しいですね。

実際の格闘技などのチャンピオンシップなどとは違って、猛者は体調の変化や衰えなどとは縁がないので、挑戦が遅くなれば遅くなるほど段々と勝ち目が無くなっていくのですが、それでもみんな、事前にチャンピオンに勝てる方法を何とか編み出してきます。
真面目かっ！

ここ最近は、糞真面目に書いても勝てず、少し (良い意味での) ズルをしないと勝てないようになってきて、回を重ねるごとにみんながどんどんと挑戦することに萎えていくムードが蔓延しているので、新機軸として「XS なら勝てるかも？」とか、バカな考えを起こし、挑戦してみることにしました。

でも、事前の仕込み禁止のライブコーディングで、yours() のブレースの中に XS を書いて、ビルドしてから走らせるとか、だいぶ厳しい条件があり、そんな中、何とか苦肉の策としてこんなコードを書いてみました。

sub yours {
    return Foo::bar(shift);
    BEGIN {
        push @INC, qw(Foo/blib/lib Foo/blib/arch);
        my $use = sub { eval qq{ use $_[0]; }; return $@ ? () : 1 };
        unless ($use->('Foo')) {
            warn $@;
            if (-d 'Foo') {
                system(qw(rm -frv Foo)) && die $^E;
            }
            system(qw(h2xs -A -n Foo)) && die $^E;
            chdir 'Foo' or die $!;
            open my $xs, '>', 'Foo.xs' or die $!;
            print $xs <<'XSUB';
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "ppport.h"

MODULE = Foo PACKAGE = Foo

SV *
bar(args)
    SV *args
CODE:
    // do something
OUTPUT:
    RETVAL
XSUB
            close $xs;
            (system($^X, 'Makefile.PL') || system('make')) && die $^E;
            chdir '..' or die $!;
            $use->('Foo') or die $@;
            # print "-" x 50 . "\n";
        }
    };
}

一回目はビルドが走りますが、BEGIN { } ブロックの中で実行されるのでベンチマークに影響を与えないというズルさもあいまって、何とかウマいこと動きました。良かった良かった。

なんかこれをもうちょっとキレイにやれば XS をインラインで書けたりするんじゃないか→あれ？そういえば、こういうのをやる Inline::XS みたいなのって無いのかなぁ？とか思ったのですが、どうも無いっぽいですね。
InlineX::XS というのはあるけど、これは Inline::C ベースのモジュールを XS に変換するもののようで、残念。

そもそも Inline::C で書けば良かったんじゃね？とかいう話もありますが、XS のほうがちょっとニッチでヒップな気がした中二の初夏。

今年の夏も暑くなりそうですね。

というタイトルの本を、近く上梓致します。
…とはいえ、ちょっと先のことなのですが、世間的にはお盆を挟みますので、少し早めの告知ということで。

ソフトバンククリエイティブさんの発行で、8/21 あたりから大型書店やネット書店あたりで店頭に置かれたり、発送されるかと思います。

内容については、ちょっと自演っぽいのですが、弊社のディレクターが書いているディレクター向けブログで、おおまかな内容や出版に至った経緯など、インタビューつきで紹介してもらいました。

ディレクターにもおすすめ！「4Gbpsを超えるWebサービス構築術」執筆者インタビュー - livedoor ディレクターブログ

インタビュー中でも言ってるのですが、このブログエントリーのタイトルに偽りはないです。
ディレクターブログに掲載してもらったのは、本書に書かれている内容について、どういうことなのか、知識としてちゃんと持っているディレクターというのが、エンジニアの人達が「一緒に仕事したいな」と思えるディレクターなのだと、常々思っていることなので、本書が技術書だからと言って、エンジニアじゃない方々にも読みやすく、わかりやすく書こうと意識して書きましたので、職域を超えて、是非多くの方々に読んで欲しいなという願いを込めて、ディレクターブログに紹介していただきました。

カバー写真とかもう出来てるのですが、Amazon にはまだ掲載されてないみたいですね。



表紙がないので、差し換えてみましたが、こんな感じの表紙になります。
もう Amazon で表紙あがってました。
一応、弊社の開発スタッフ 6 人での共著という形で書かせていただいております。

元社長さんにもブログにてご紹介いただきました。ありがとうございます。

ということで、もし良かったら是非読んでみてください。


ちなみに、4Gbps って、あんまりピンとこないですよね。
個人的には、実は正直ほとんどピンときてませんｗ

「タウリン 2g 配合」じゃなくて「タウリン 2,000mg 配合」みたいに、数字が大きいとスゴそうな感じなので、個人的には "4Gbps" よりは、"4,294,967,296bps" とかのほうがすごそうだなーってふと思ったのですよね。

「4,294,967,296bpsを超えるWebサービス構築術」

なんか、ドキドキしてきますよね。ヨンジュウニオク…んー…みたいなそんな数字。


はい、また与太話でした。

ということで、ネットで生中継されるのを知っていたので、あんまりたくさんの人に見られると恥ずかしいので、わざと直前に告知した前回でしたが、それに続き、何となく後編を書こうと思います。



ということで、APNIC SPEAKER という、どうもチョットしっくり来ない…というか、そもそも専門分野等々で、色々とアウェイなイベントでお話をさせてもらいました。

アジア太平洋地域で言えば、APRICOT (Asia Pacific Regional Internet Conference on Operational Technologies)、日本とかでは JANOG (JApan Network Operators' Group) なんでしょうか？
ネットワーク関連に従事されている、(OSI で言うところの) 低レイヤーのエンジニアの皆様なら、当然「IPv4 が枯渇する」なんて、昔っから言ってるんだから、IPv6 に切り替えていかないとねーなんてのは散々語りつくされているわけです。
じゃあ、インフラは整うべく着々と準備されていっている中でも、アプリケーションって放っておいても IPv6 対応するの？しないのなら対応ってどうやるの？というのを、今後 IPv6 の上で動くであろうコンテンツを作る側の高レイヤーのエンジニアの人達が、(AP region では地域差こそあれど) ほとんど知ってないという現状に対し、ネットワークのエンジニアの皆様が集まる中で、アプリケーションというのはこうやって対応するんだよーみたいなお話をさせて頂きました。



このような、なかなか立派な、とても広い会場で、ネットワーク寄りなエンジニアの皆様の前で、アプリケーションレイヤーの実装について英語でプレゼンテーションをしないといけないとか、とっても変な空気でしたがｗ、無事に発表することが出来ました。

発表資料は APNIC 27 のサイトでも公開されていますが、SlideShare のほうにうｐっておきました。
発表の中で発言した内容については、まずは速記者の方が書かれた Transcript をご覧ください。
音声や動画等はいずれ公開されると思います。

速記で思い出したのですが、写真に撮り忘れて非常に残念なのですが、すごく面白いなーと思ったのは、プロの速記の方は、大正琴の鍵盤のようなデバイスで、何個かのキーを組み合わせてガシャガシャ押すことで、どんなに長い英単語が含まれようが、慣用的な表現なんかは数ミリ秒でガシャっ！と入力してしまうのですね。
プレゼンテーション中も、会場のモニタにリアルタイムで発言内容が表示されていくのですが、一文字一文字表示されず、ちょっとした述語や連語はドバッ！と表示されます。
一応、stenograph で Google 画像検索すると、どういうデバイスを使っているのかをご覧頂けます。

話が逸れましたが、地上アナログ放送と同様に、IPv4 も割り当て可能なブロックが枯渇するのが近々に迫ってきてます。
その上でコンテンツが対応していないというのは、テレビ局が地デジ放送をやってないみたいなものなので、見られなくなってからの対応では遅いということです。
移行自体には様々な面で、当然ながらコストがかかりますが、枯渇してからビジネスチャンスを失なうほうが痛手だと思います。

テレビの地デジ移行とだいぶ違うなと思うのは、地デジはアナログ放送に比べて、見た目からわかるほどの、様々なメリットがあるのに対して、IPv6 は IPv4 と比べて、プロトコル的にはほとんどメリットが無いということです。
かと言って、「メリットがあんまりないから変えない」ということよりも、「IPv4 しか使えない現状に、近い将来に絶命するほどの致命的なデメリットがある」ということをまず自覚するべきなのかも知れません。

結局、私が言いたいのは「IPv6 化って何も難しくないよ」ってことだけです。

それを実証するためにも、IPv6 対応へ向けての第一歩として、IPv6 テスト環境を提供している、EDGE Co.Lab v6 に応募されてみてはいかがでしょうか。

以下のリンクでも、弊社の伊勢さんが 私がブログに書いた内容を元に、低レイヤーエンジニアとしての視点から見て、よしなにリライトされた内容を発表されていますので、そちらも是非参考になさってください。
［ITproカンファレンス：IPv4枯渇対策］実践してわかったWebアプリをIPv6に対応させる7つの鉄則：ITpro


今回、こういう機会をいただきまして、関係各位の皆様には大変お世話になり、本当にありがとうございました。

朝 9:00 現在の気温は、26 ℃、今日はあいにくの曇り空です。
Hotel Sofitel Philippine Plaza の部屋から撮影してみました。

以前、「IPv6 とかよくわからない人間が IPv6 対応サイトを作る際の知っておくべき 8 つの注意点」という話を書いたら、それがきっかけで、koyhoge さんに取り次いでいただいたり (ありがとうございます) などしながら、オーストラリアのブリスベンから一本の電話がかかってきました。

電話は、アジア、太平洋地域のインターネットを管轄している APNIC (Asia Pasific Network Information Centre) からで、電話の趣旨は、APNIC が主催する、APNIC 27 というカンファレンスで、「IPv6 とかよくわからない人間が (ry」の内容を発表して欲しいとのこと。

ということで、突発的にフィリピンのマニラに行くことになり、本日、フィリピン時間の朝 9:00 から 10:30 に行なわれる「IPv6 in 3D」というセッションで、「IPv6 とか (ry」の英語バージョンを発表させていただきます。

ライブストリーミングや、速記、チャットなどもあるようですし、慣例的に動画や音声や速記された内容はアーカイブされるようですので、現地にいなくとも、ライブで見られなくても、追ってご覧頂けるかと思います。

ということで、今年はアルファブロガー (笑) になることを目標としておりますが、ブログを書いたらマニラに行けるというのは、なかなかのアルファっぷりなんじゃないかなと思いました。


発表が終わったあと、落ち着いたら後編を書く (かも知れない) と思います。

「FormValidator::Simple::Plugin::Japanese の依存ライブラリを減らしつつ perl5.8 的な Unicode 使用スタイルにして高速化をはかるパッチ - TokuLog 改めB日記」 あたりに関連して、某 IRC にて…

19:23 >nipotan< FormValidator::Simple::Plugin::Japanese は、
19:24 >nipotan< Number::Phone::JP フンフンまわりが重いような希ガス
19:24 >nipotan< つか、U::RD にしても、N::P::J にしても俺じゃねぇか
19:24 <hid*******> w
19:26 <Yap***> www
19:27 >nipotan< FormValidator::Simple::Plugin::Number::Phone::JP でしたっけ
19:27 >nipotan< すっごい長い名前ｗ
19:27 <kan**********> www
19:29 <hid*******> CPANで長いネームスペース大会でベスト10候補ですね
19:29 <tok***********> いやー
19:29 <tok***********> 本当に長いのはもっともっと長かった気がする
19:30 <tok***********> Acme に死ぬほど長いのがあったような
19:30 <tok***********> Acme::Super::Hyper::Very::Long::Long::Module::Name.pm みたいな
19:30 <ots****> Acme::JugemJugemGogouno... かとおもった
19:30 <hid*******> ｗ

ということで、何が長いのか、ホントにベスト 10 候補なのか、調べてみたよ
(2009 年 2 月 17 日現在)

コード:

#!perl

use strict;
use warnings;
use CPAN::Config;
use IO::Uncompress::Gunzip qw($GunzipError);
use constant PRINT_BEST => 10;

my $package_file =
    sprintf "%s/modules/02packages.details.txt.gz",
        $CPAN::Config->{keep_source_where};

my %ranking = ();

my $z = IO::Uncompress::Gunzip->new($package_file) or die "$GunzipError\n";
while (my $line = $z->getline) {
    my($package) = split /\s+/, $line, 2;
    my $length = length $package;
    $ranking{$length} ||= [];
    push @{$ranking{$length}}, $package;
}
$z->close;

my $number = 1;
my $rank;

for my $length (sort { $b <=> $a } keys %ranking) {
    $rank = $number;
    for my $package (sort @{$ranking{$length}}) {
        printf "%2d: %d bytes: %s\n", $rank, $length, $package;
        ++$number;
    }
    last if $number >= PRINT_BEST();
}

で、結果はこうなったよ。

順位	文字数	ネームスペース
1	96	eBay::API::XML::Call::AddTransactionConfirmationItem::AddTransactionConfirmationItemResponseType
2	95	eBay::API::XML::Call::AddTransactionConfirmationItem::AddTransactionConfirmationItemRequestType
3	94	Perl::Critic::Policy::ControlStructures::ProhibitNegativeExpressionsInUnlessAndUntilConditions
4	92	eBay::API::XML::Call::AddMemberMessageAAQToPartner::AddMemberMessageAAQToPartnerResponseType
4	92	eBay::API::XML::Call::AddMemberMessagesAAQToBidder::AddMemberMessagesAAQToBidderResponseType
4	92	eBay::API::XML::Call::GetLiveAuctionCatalogDetails::GetLiveAuctionCatalogDetailsResponseType
4	92	eBay::API::XML::Call::GetStoreCategoryUpdateStatus::GetStoreCategoryUpdateStatusResponseType
4	92	eBay::API::XML::Call::ValidateTestUserRegistration::ValidateTestUserRegistrationResponseType
9	91	eBay::API::XML::Call::AddMemberMessageAAQToPartner::AddMemberMessageAAQToPartnerRequestType
9	91	eBay::API::XML::Call::AddMemberMessagesAAQToBidder::AddMemberMessagesAAQToBidderRequestType
9	91	eBay::API::XML::Call::GetLiveAuctionCatalogDetails::GetLiveAuctionCatalogDetailsRequestType
9	91	eBay::API::XML::Call::GetStoreCategoryUpdateStatus::GetStoreCategoryUpdateStatusRequestType
9	91	eBay::API::XML::Call::ValidateTestUserRegistration::ValidateTestUserRegistrationRequestType

現実は全然長すぎるよ。。

ちなみに、あまりにつまらない結果なので、10 位までしか出してないですが、1,000 位まで出した (ちなみに 56 文字で 906 位タイというのが 98 個あったので、1,000 位までの総数は 1,003 個) 場合、

• eBay::API::XML:: から始まるものが 498 個
• Perl::Critic:: から始まるものが 127 個
• perfSONAR_PS::Datatypes::v2_0:: から始まるものが 55 個
• UMMF::UML::MetaModel:: から始まるものが 46 個
• UMMF::UML_1_5:: から始まるものが 45 個

と目立ちました。
そして、予想に反して、Acme:: から始まるものは、1,000 位までの中で 0 個でした。

さぁ、すごい長くて素敵な名前を考えて、トップに躍り出るチャンスだよ！
みんな頑張ってね！
俺は空気読む子だから頑張らないよ！