February 2009
February 27, 2009
ということで、ネットで生中継されるのを知っていたので、あんまりたくさんの人に見られると恥ずかしいので、わざと直前に告知した前回でしたが、それに続き、何となく後編を書こうと思います。
ということで、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
今回、こういう機会をいただきまして、関係各位の皆様には大変お世話になり、本当にありがとうございました。
ということで、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
今回、こういう機会をいただきまして、関係各位の皆様には大変お世話になり、本当にありがとうございました。
February 25, 2009
朝 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」の英語バージョンを発表させていただきます。
ライブストリーミングや、速記、チャットなどもあるようですし、慣例的に動画や音声や速記された内容はアーカイブされるようですので、現地にいなくとも、ライブで見られなくても、追ってご覧頂けるかと思います。
ということで、今年はアルファブロガー (笑) になることを目標としておりますが、ブログを書いたらマニラに行けるというのは、なかなかのアルファっぷりなんじゃないかなと思いました。
発表が終わったあと、落ち着いたら後編を書く (かも知れない) と思います。
February 17, 2009
「FormValidator::Simple::Plugin::Japanese の依存ライブラリを減らしつつ perl5.8 的な Unicode 使用スタイルにして高速化をはかるパッチ - TokuLog 改めB日記」 あたりに関連して、某 IRC にて…
(2009 年 2 月 17 日現在)
コード:
現実は全然長すぎるよ。。
ちなみに、あまりにつまらない結果なので、10 位までしか出してないですが、1,000 位まで出した (ちなみに 56 文字で 906 位タイというのが 98 個あったので、1,000 位までの総数は 1,003 個) 場合、
そして、予想に反して、
さぁ、すごい長くて素敵な名前を考えて、トップに躍り出るチャンスだよ！
みんな頑張ってね！
俺は空気読む子だから頑張らないよ！
19:23 >nipotan< FormValidator::Simple::Plugin::Japanese は、ということで、何が長いのか、ホントにベスト 10 候補なのか、調べてみたよ
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*******> ｗ
(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 個でした。さぁ、すごい長くて素敵な名前を考えて、トップに躍り出るチャンスだよ！
みんな頑張ってね！
俺は空気読む子だから頑張らないよ！
February 13, 2009
ヒビノアワ: 自作iPhoneアプリ「BPM」公開されました！
こういうのいいなーと思いつつ、iPhone 持ってないから俺使えないじゃん！
と、ついカッとなって作った。今は反省している。
そもそも、BPM 調べる用のソフトは色々とあるので、GUI が使えないという、奇特な環境の人向け。
そんな人あんまいないだろ JK
こういうのいいなーと思いつつ、iPhone 持ってないから俺使えないじゃん！
と、ついカッとなって作った。今は反省している。
#!perl
use strict;
use warnings;
use Time::HiRes qw(gettimeofday);
use Term::Screen;
use constant DEFAULT_SECONDS => 60;
my $secs = int $ARGV[0] || DEFAULT_SECONDS();
my $screen = Term::Screen->new;
$screen->clrscr();
my $start;
my $end;
$screen->at(0, 0)->puts(sprintf("pless any key to start. (%d secs)", $secs));
my $count = 0;
my $bpm;
while (my $c = $screen->at(1, 0)->getch) {
$screen->clrscr();
exit if $c =~ /^[\x03\x04\x1b]$/;
$count++;
unless ($start) {
$start = gettimeofday();
}
$end = gettimeofday();
my $diff = $end - $start;
$bpm = $diff > 1 ? $count * (60 / $diff) : 0;
$screen->at(0, 0)->puts(
sprintf("%3dbeats - %.2f BPM (%.3fsecs)", $count, $bpm, $diff));
last if $diff >= $secs;
}
$screen->clrscr();
$screen->at(0, 0)->puts(sprintf("%.2f BPM", $bpm));
$screen->at(1, 0)->puts('');
音楽を聞きながら、キーボードをタップ (?) して調査できます。そもそも、BPM 調べる用のソフトは色々とあるので、GUI が使えないという、奇特な環境の人向け。
そんな人あんまいないだろ JK
February 05, 2009
#!perl
use strict;
use warnings;
use Perl6::Say;
my $PRIV_IP_RE = qr{^https?://
\b(?:
10\.(?:\d\d?|1\d\d|2(?:[0-4]\d|5[0-5]))| # class A
172\.(?:1[6-9]|2\d|3[01])| # class B
192\.168 # class C
)
\.(?:\d\d?|1\d\d|2(?:[0-4]\d|5[0-5]))
\.(?:\d\d?|1\d\d|2(?:[0-4]\d|5[0-5]))\b
}xi;
for my $url (qw(http://10.10.2.60/ http://www.google.com/)) {
say "$url IS " . ($url =~ $PRIV_IP_RE ? "NOT BOOKMARKABLE" : "BOOKMARKABLE");
}
結果:
http://10.10.2.60/ IS NOT BOOKMARKABLE http://www.google.com/ IS BOOKMARKABLE参考:
おまいの iTunes も共有汁 - にぽたん研究所
はてなブックマーク - うごメモはてな - メモからはじまる新しいコミュニケーション！
