1月13日（金）にPalo Altoで行われたJTPAのギークサロンに参加してきた。今回は参加者がラップトップ持ち込みでコーディングしていくハッカソン形式で、会場入りする前までにHadoopが使える環境を自前で用意しておく必要があった。もうそれだけで、いつものギークサロンよりハードルが高いのだが、当日は15人ほどのギークたち（中には3日前にベイエリアに来たばかりという学生もいた）が集まって、おのおのラップトップとにらめっこしながらHadoopと戯れていた。
今回のギークサロンをホストしてくださった山中仁氏が、EC2上にHadoopクラスタを構築する方法を、参加者向けの資料としてWeb上に準備してくださり、「Hadoop＝未知の領域」だった自分でもすんなりHadoopクラスタを組むことができた。だが残念なことに、この資料自体がEC2上に一時的に立てたサーバーに置かれており情報が恒久的には残らないとのこと（山中氏談）なので、山中氏に一部転載の許可をいただき、自分なりの咀嚼も含めてEC2上にHadoopクラスタを構築する手順を書き留めておくことにした。
RailsどころかRuby自体まともに読んだことも書いたこともないが、年末の休みの間にRuby on Rails Tutorialを見つけて、流し読みしているうちに「これなら本当に簡単にできそう！」な気がしたので、チュートリアルに沿って手を動かしてサンプルアプリを書きながら、RubyとRailsを習得しようと思い立った。
手始めにChapter 1: From zero to deployを読みながらRailsの環境構築。チュートリアルに書かれていることを忠実に実行していくわけではないが、自分と同じようにゼロスタートでRailsを使ってみようという人の道標になればと。
仕事で開発している組み込み機器のLinuxカーネルを、2.6.27系から2.6.32系にアップデートするために、久々にカーネルの再構築なんかやってて、ネットワークデバイスのリンク状態を監視するために自作したLKMがあったので、2.6.27.xで使っていたものをそのまま2.6.32.xにコピーしてコンパイルしたら通らなかったorz
error: ‘struct net_device’ has no member named ‘get_stats’ error: ‘struct net_device’ has no member named ‘do_ioctl’
net_device構造体からget_stats()とdo_ioctl()がなくなったようだ。
統一されたページレイアウトのサイトをZend Frameworkで作るのにZend_Layoutをよく使う。最もシンプルなレイアウトスクリプトを書くとこんな感じになる。
<?php echo $this->doctype() ?> <html> <head> <?php echo $this->headMeta() ?> <?php echo $this->headTitle() ?> <?php echo $this->headLink() ?> <?php echo $this->headStyle() ?> <?php echo $this->headScript() ?> </head> <body> <?php echo $this->layout()->content ?> </body> </html>
コマンドラインをviモードで編集するのエントリで「それどうやんの！？」と訊いてきた知人から、後日こんなメールをもらった。
viモードにしてその延長上でコマンドの結果に対してpromptで編集（？）みたいのってできるのですかね？
例えば
$ cat somefile.txt # これにファイル名が幾つか入っている src/file1.txt src/file2.txtでここでESCを押すとviモードになって
jとかkとかでfile1.txtとfile2.txtがチラチラと見える。
最終的にはiとか使って$ vi src/file2.txtとかがぱっとできたりするといいなーと思っている。
node.jsはソースコードに加えて、Windows版、Mac版のインストーラが用意されているが、なにせnode.jsは今のなお開発進行形で頻繁にバージョンアップがされており、その都度アンインストール／再インストールするのは非常に面倒だ。node.jsはRubyの影響を強く受けているのか、RVM（Ruby Version Manager）と同じようなNVM（Node Version Manager）というバージョン管理システムが用意されている。開発環境としてはNVMを利用してnode.jsを自動インストールする方が便利だ。
Zend Frameworkを使って開発を進めていくと、利用するコンポーネントが増えていくにつれて、アプリケーションのINIファイル（一般的に使われているapplication.ini）の内容が膨らんでいく。特にZend Frameworkのバージョンアップに伴って、Zend_Applicationから利用できるリソースプラグインの種類が充実していくので、ソース中にハードコーディングしていたような環境依存パラメータは、どんどんINIファイルに移行するようになっていく。application.iniファイル内では、できるだけリソース毎にまとめて書くようにしているが、INIファイルをリソース毎に分けて管理できないものかと思っていた。
デジカメで撮った写真をブログなどにアップロードする場合に、高解像度がゆえにファイルサイズが無駄にデカくて、アップロードに時間がかかってしまったり、あるいはアップロード可能なファイルサイズの上限に達してしまって、写真のアップロードができなかったりすることがある。ちなみにWordPressの3.1系では、ファイルサイズの上限が2MBとかなり小さめ。
プログラミングを始めてから現在に至るまで開発してきたアプリケーションの実行環境が、Windows→UNIX（Solaris）→Linuxと移り変わってきたこともあり開発環境も直近10年はUNIX/Linux。エディタも10年以上vim（Solarisではvi）を使い続けているだけに、身体にvimのキー操作感が染み付いてしまっている。ソースの編集だけでなく、コマンドラインもviキーバインディングで編集しているわけだが、先日その様子を知人に見せたときに「それどうやんの！？」と訊かれたので、意外に知らない人が多いのではと。
bashを使ってネットワークアドレスの設定をするためのスクリプトを書いてたときに、入力されたサブネットマスクが正しいかどうかを検証するコマンドがなかったので自前で作ることにした。まず、入力値がIPv4アドレスとして正しいかどうかの判定は、正規表現を使った例などもあるが、ipcalcコマンドを使った方が楽チン。
#!/bin/bash
read mask
if ! ipcalc -c $mask > /dev/null 2>&1; then
echo "ERROR: Invalid format"
exit 1
fi