« 2009年11月 | トップページ | 2010年2月 »

2009年12月の6件の記事

2009年12月29日

私的2010年五大ITニュース

私の身の回り限定でIT関連五大ニュースをリストアップしてみる。

第5位 メモにITを使わなくなった

メモを取るのにデジタル機器を使わなくなった。以前は携帯からGmailに送ったり、プライベートモードのはてなダイアリに書き込んだり、紙copiに書いてiPAQとTomboで同期したりしていたが、私の入力スピードでは思い付くアイディアを書き留めるのに追いつかない。ロディアにボールペンで走り書きしたほうがよほど効率的だ。

ロディアは一時的なメモである。そこからブログに書いたり、いったんノートに書き写して残しておいたりする。ノートに書いたものは日付と見出しでインデックスをテキストファイルに書き出しておく。これは奥野宣之「情報は1冊のノートにまとめなさい」のアイディアだ(関連記事)。このあたりからITツールを使い出すが、最初のメモはあくまで紙とペンである。

第4位 アウディA3 Sportsback 1.4TFSI

プジョー306からアウディA3 Sportsback 1.4TFSIに乗り換えた。オンボードコンピュータとHDDナビゲーションシステムが搭載されたアウディA3は立派なIT機器である。プジョー306に比べて格段に増えた機能をまだ使いこなせていない。

306は満タン給油時の走行距離をメモしてExcelで燃費を計算していた。満タン給油はクルマが重くなってエコじゃないので、最近は20リッター上限にしている。オンボードコンピュータならこれでも燃費が分かる。

第3位 iPhone

パソコン中毒気味の私にiPhoneは火に油を注ぐようなもの。あるいはきちがいに刃物かもしれない。日本の携帯サービスに依存せず、FlickrやGoogleなどの海外Webサービスをよく使っていたから、iPhoneへのスイッチは非常に効果があった。おサイフケータイは便利だったが、無ければ無いでなんとかなるもの。以前はこんなサービスは影も形もなかったのだから、Nice to haveである。

第2位 Twitter

 Twitterに登録したのが2008年8月。最初は携帯からモバツイッターで利用していたが、いまはiPhoneだ。iPhoneを使い出してからツイートの数が急増している。Twilogでカウントすると、2009年9月に160だった月間ツイートが12月は534。書き込んだもの有効利用できないだろうか。

第1位 会社買収と転籍

 1位の私的ITニュースは、会社が買収されて、買収先に転籍したことに間違いない。サブプライム問題による不況のあおりを食って会社業績は悪化し、2009年は給与削減で幕を開けた。ベンチャー企業の目標は2つ。株式上場(IPO)か事業売却だ。株式市場が冷え込んでIPOの目が無くなった会社は、どこかに買ってもらうしかない。買い手がなければ精算ということになる。

買収が決まったのが夏。自分のポジションがどうなるかはオファーレターが出てくるまで分からない。所属部署は私や上司を含めて全員転籍できたが、他部署には辞めさせられたり自分から辞めていった者もいる。

もうひとつよかったのは、会社買収につきものの製品終息(つまり開発打ち切り)がないこと。これまで見聞きしたり自分で経験した会社買収の中でベストの買収と言える。いまは新しい会社への業務やシステムの統合でごたごたしているが、職を失うのに比べればよほどマシだ。

| | コメント (0)

2009年12月17日

Perlのopendirは第2引数が0x5Cで終わるとエラーになる?

ひとつ前の記事で「なるほど、こうすればいいか」と思ったWindowsでのPerl日本語ファイル名処理なのだが、理解が甘かったことが以下のような簡単なコードであっという間に分かってしまった。

use utf8;
use strict;
use Encode qw/encode decode/;

my $dir = "何十";
$dir = encode('Shift_JIS', $dir);
opendir(DIR, $dir) or die("Unable to open directory:$dir ($!)");
my @list = readdir(DIR);
print @list;
closedir(DIR);

「何十」というディレクトリを作って実行するとエラーになってしまう。

Unable to open directory:何十 (No such file or directory) at open_dir.pl line 8.

ディレクトリ名が「十分」であれば問題ない。ディレクトリ内のファイルが出力できる。

すると事態はもっと複雑、そしてやっかいで、opendirの第2引数が0x5Cで終わるときが問題だということになる。そうだとすると、Perlスクリプトでいくら工夫しても無駄なのではないだろうか。

| | コメント (1)

WindowsのPerlで日本語パス名を処理すると0x5C文字でつまずく

仕事で必要性を感じてきたのでPerlを勉強している。普段使っているWindows PCでPerlスクリプトを書いていて、日本語パス名の処理でつまずいてしまった。シフトJISで0x5Cを2バイト目に持つ文字がディレクトリ名の末尾にあると、それ以下の階層をFile::Findで走査できない。「\」と同じ0x5Cを2バイト目に持つ文字は、英語版プログラムをシフトJIS環境で動作させたときに文字化けなどの誤動作を起こす代表的な文字のひとつである。

木本裕紀氏のサンプルコードを使って、再帰的にすべてのファイル名をフルパスで出力してみた。環境はWindows XP SP2とActivePerl 5.10.1.1006である。

まず、サンプルコードが内部で生成したテスト用のディレクトリ構造は次のように出力される。ディレクトリ名やファイル名は全て英数字だ。

dir0
dir0/top.txt
dir0/dir1
dir0/dir1/1.txt
dir0/dir1/dir1_1
dir0/dir1/dir1_1/1_1.txt
dir0/dir1/dir1_2
dir0/dir1/dir1_2/1_2.txt
dir0/dir2
dir0/dir2/2.txt

次に、dir1を「十分」に改名して同じ処理を実行する(ディレクトリ構造生成部分は削除。「十」はシフトJISコードで0x8F5C。

dir0
dir0/top.txt
dir0/dir2
dir0/dir2/2.txt
dir0/十分
dir0/十分/1.txt
dir0/十分/dir1_1
dir0/十分/dir1_1/1_1.txt
dir0/十分/dir1_2
dir0/十分/dir1_2/1_2.txt

これはうまくいった。次に「十分」を「何十」に改名してみる。

dir0
dir0/top.txt
dir0/何十
dir0/dir2
adir0/dir2/2.txt

「何十」ディレクトリ以下が出力されなくなってしまった。「申請表」でも同様だ。

dir0
dir0/top.txt
dir0/申請表
dir0/dir2
dir0/dir2/2.txt

もうひとつ下の階層で試してみた。dir1_1を「何十」に改名する。

dir0
dir0/top.txt
dir0/dir1
dir0/dir1/1.txt
dir0/dir1/何十
dir0/dir1/dir1_2
dir0/dir1/dir1_2/1_2.txt
dir0/dir2
dir0/dir2/2.txt

やはり「何十」ディレクトリ以下が出力されなくなった。NTFSはUnicodeでファイル名を保存しているはずなのに、シフトJIS特有の「0x5C」が顔を出してくる。WindowsカーネルからPerlスクリプトのどこかでシフトJISに変換されているのだろうか。

英語版Windows 2003でもテストしてみた。日本語を表示・入力できるように東アジア言語をインストールしてある。dir1を「何十」に改名した場合はこうなる。

dir_20080530_2464
dir_20080530_2464/top.txt
dir_20080530_2464/dir2
dir_20080530_2464/dir2/2.txt
dir_20080530_2464/148A~1
dir_20080530_2464/148A~1/1.txt
dir_20080530_2464/148A~1/dir1_1
dir_20080530_2464/148A~1/dir1_1/1_1.txt
dir_20080530_2464/148A~1/dir1_2
dir_20080530_2464/148A~1/dir1_2/1_2.txt

全階層を走査しているが、日本語が表示されない。「148A~1」はどこから来ているのだろうか。

同じことをCentOS 4.7(ロケールUTF-8)上のPerl 5.8.5でやってみると、どのパターンも正常に処理できる。

これはおそらく、perldoc perlunicodeが例外としてあげている部分に相当するのだろう。ファイル名はオペレーティングシステムやファイルシステムに依存する度合いが大きいから、Perlはバイト文字列として扱っている。

The following are such interfaces. For all of these interfaces Perl currently (as of 5.8.3) simply assumes byte strings both as arguments and results, or UTF-8 strings if the encoding pragma has been used.

ではどうすればよいかというと、perldoc perlunitutが書いているように、

・入力したバイト文字列をデコードする。
・Perlスクリプトで処理する。
・出力する前にエンコードする、

という3つのステップを踏まなければならないようだ。これをファイル処理に当てはめると、

・open, opendir などの引数はバイト文字にエンコードしたものを渡す。
・readdirなどで取得した結果はデコードしてからPerlで処理する。

ということになる。そして日本語Windowsの場合はシフトJISで、英語Windowsの場合はUTF-8でエンコード/デコードする。

この理解が正しいかどうか、実際にコードを書いて調べてみるつもりだ。

(参考ページ)
Shift_JIS(Wikipedia)
http://ja.wikipedia.org/wiki/Shift_JIS

File::Find 再帰的にすべてのファイルを処理する(木本裕紀)
http://d.hatena.ne.jp/perlcodesample/20080530/1212291182

perldoc perlunicode
http://perldoc.perl.org/perlunicode.html#When-Unicode-Does-Not-Happen

perldoc perlunitut
http://perldoc.perl.org/perlunitut.html

Encode 日本語などのマルチバイト文字列を適切に処理する(木本裕紀)
http://d.hatena.ne.jp/perlcodesample/20091118/1246679588
perlunitutの内容をサンプルコード付きで解説している。

(2010/01/06追記)
コメントをくれたash氏が、Win32::Unicodeをブログで紹介している。Windows環境ではこれを使うのがよいようだ。作者xaicron氏による解説記事はこちら。

Windows環境でUnicodeファイルを扱う
http://perl-users.jp/articles/advent-calendar/2009/hacker/20.html

が、ActivePerlにCPANモジュールをインストールするところがまた一苦労である。先人の解説記事をとりあえず貼り付けておく。

Perlメモ/モジュールのインストール(CPAN)

| | コメント (2)

2009年12月14日

Google Public DNSを使うと遅くなるかもしれない

Googleが高速なDNSサーバGoogle Public DNSを立ち上げた。しかし日本から使うとかえって遅くなる可能性が高い。たとえば私の環境でping応答時間を比べると、So-netのDNSサーバ(202.238.95.24/202.238.95.26)が10ms程度であるのに対して、Google Public DNSサーバ(8.8.8.8/8.8.4.4)は30~40msと3~4倍遅い。

もちろんping応答時間だけではDNS名前解決の性能測定にならない。DNSサーバの処理を含めて比べる必要がある。ちょうどいいタイミングで、ポッドキャスト「Security Now!」のSteve GibsonがDNSベンチマークを作って公開しようとしている。ダウンロードページは既に存在している。

Domain Name Speed Benchmark(GRC.com)
http://www.grc.com/dns/benchmark.htm

このツールは、PCに設定されているDNSサーバに加えて、ツールに標準で組み込まれている複数のDNSサーバの名前解決速度を測定してグラフ化する。私の環境でこのツールが最速と判定したのはNTT AmericaのDNSサーバ。僅差の2位がSo-net。そこから約3倍の遅延でGoogle Publi DNSが3位という結果が出た。ping応答時間の差がそのまま結果に表れているようだ。私の環境でGoogle Public DNSを使う意味はないことが裏付けられた。

家庭のブロードバンド環境によっては、PCのプライマリDNSサーバがブロードバンドルータに設定されていることが多いと思う。ルータ添付の設定ツールやマニュアルに従うとそうなるはずだ。ネットワーク上で非常に近いところにあるが、コンシューマ向けの安価なルータハードウェアで動作しているDNSサーバだから、名前解決の処理速度が遅いかもしれない。このツールを使えば、ルータのDNSサーバを使ったほうがいいのか、それをスキップしてISPのDNSサーバを使ったほうがいいのかも分かる。後者に変更する場合、DNSサーバをDHCPで取得しないようにPCを設定すればよい。

(関連記事)
Introducing Google Public DNS(Official Google Blog)
http://googleblog.blogspot.com/2009/12/introducing-google-public-dns.html

(2009年12月25日追記)
Google Public DNSは複数のサーバが同一IPアドレスを共有していて、ユーザは一番近いサーバに接続するようになっているとのこと。上の記事は、あたかもサーバが海外にあるように書いたのだが、それは誤りかもしれない。それでも、Steve Gibsonのベンチマークツールで3位という事実は変わらない。Googleのことだから、サーバ設置場所は随時変更するはずだ。ときどき性能測定してみる方がよいだろう。

DNSのルートサーバーはどこにある?---最新ニュースの理解に役立つ素朴な疑問
http://itpro.nikkeibp.co.jp/article/Watcher/20091221/342479/

| | コメント (0)

2009年12月11日

WebセキュリティのSame Origin問題

ポッドキャスト「Security Now!」Episode #225で「Same Origin問題」を取り上げていた。

Webセキュリティには、Same Origin、つまり同一サイトのコンテンツは信頼できるという共通理解がある。ひとつのページの中にマッシュアップしたコンテンツや広告サイトのコンテンツがある状態は、Web管理者があずかり知らないオブジェクトが含まれていることがある。悪意のあるものの攻撃を防ぐため、たとえばJavascriptは、同一サイトのメソッドやプロパティにアクセスすることを許可しているが、別サイトのメソッドやプロパティへのアクセスは制限される。

Web 2.0の普及に伴って、ユーザがアップロードしたコンテンツがWebページに含まれることが当たり前になってきた。ユーザコンテンツが主サイトと同じドメインのサーバに保存されると、それはSame Originとみなされる。もし悪意のあるものが特別に加工したコンテンツをアップロードすると、主サイトのコンテンツとの間で相互作用が許可され、情報入手や破壊などが行われる可能性がある。

たとえばFlashのコンテンツを写真サイトに拡張子jpgでアップロードしたとする。Flash Playerは拡張子を問わず、ファイルのヘッダ部分だけを見てFlashのファイルかどうかを判断し、Playerが起動する。悪意のあるFlashファイルをアップロードし、サイトのほかのコンテンツと相互作用させることが理論的に可能である。

したがって、ユーザがコンテンツをアップロードするサービスの場合、それは別のドメインのサーバに保管しなければ安全とは言えない。しかしこれはそう簡単に対処できるものではない。複数ドメインを取得・管理しなければいけないし、既存のWebコンテンツのリンクを書き換えたりするなど、非常に手間がかかる。さらにパッケージのブログツールなどをインストールして使っている場合には、そのツールが上記の点を考慮をするのを待たなければならない。

(参考)
「Security Now!」Eposode 225 “Same Origin” Troubles
http://www.grc.com/securitynow.htm

| | コメント (0)

iPhone~Exchange接続のアカウント認証

本社のWindowsドメインでちょっとしたトラブルがあり、私のアカウントのパスワードがリセットされた。面白いことに、iPhone 3GS(iPhone OS 3.1.2)はメールアカウント設定を何も変更しなかったのに、Exchangeサーバと通信し続け、半日くらい経ったときにはじめてパスワード不一致のエラーが起きた。どうやら接続するたびには認証していないようだ。認証には暗号化処理が含まれているから、そのCPU負荷を嫌っているのだろうか。

一定期間、古いパスワードで接続し続けることができるのはセキュリティ上の弱点と言えなくもない(注)。しかし、ある社員の接続をロックアウトしたいのであれば、単にWindowsドメインのアカウントロックするだけでなく、リモートワイプでiPhoneのデータを消すこともできるので、性能と運用のバランスを取っているのだと思う。;

(注)私が経験した挙動が一般的なものかどうかは検証してない。Exchangeの設定に依存するのかもしれない。

(参考記事)
iPhone 3Gのリモート・ワイプを試す
http://itpro.nikkeibp.co.jp/article/COLUMN/20080724/311481/

ITProの記事がいう「パスワード・ロック」というのは、iPhone本体のパスワード(4桁の数字)のことで、Windowsドメインアカウントをロックすることではないと思う。

| | コメント (0)

« 2009年11月 | トップページ | 2010年2月 »