Real Software: Pricing Changes
今メインで使っている開発環境の REAL Studio のライセンスについて。少し前の話題ですが、改めてまとめておきます。

ライセンス体系が、今までの Personal, Professional, Enterprise, Web から、Desktop Deployment, Web Deployment, Console Deployment, DB Servers という区分になるそうです。
体系の変更時期は「2012 R2 のリリース以降」ということです。2012 R1 の出荷が 2012/08 予定であることを考えると、おおよそ 2012/11 から、ということになるでしょうか。

今現在は Professional ($299) を使っているのですが、ライセンス体系の移行後は Desktop Deployment ($300) を使うことになります。わずかにコストが高くなりますが、IDE の全機能が全てのライセンス区分で利用可能になるので、従来 Enterprise でしか使えなかったプロファイラやビルドタスクなどが使えます。これは嬉しい。
一方で、今まで Professional で使えていたコンソールアプリ開発機能やリモート DB アクセス機能は使えないことになりますが、一度も使ったことがないので特にインパクトなし、です。

現行のライセンスは、以下のようにトランジションされるとのこと。

Personal => Desktop
Professional => Desktop + Console + DB
Web => Web + DB
Enterprise => Desktop + Web + Console + DB

移行後の区分では、シングルプラットフォーム開発を行っている人向けの安価なライセンス (Personal) が廃止されてしまったため、そのようなケースでは大幅なコスト高になりそうです。
また、アカデミックライセンスも廃止されてしまうようなので、困る人は少なからずいるかもしれません。

いずれにしても、ライセンス体系の変更による値上がりが気になる方は 2012 R2 リリースまでにライセンスを購入/更新しておくと良いみたいです。昔 Linux 版の Personal が無料だった時期に貰ったライセンスが寝かせてあるので、これで 2 年分 Personal を更新しようと思います。

RHEL をターゲットに開発を行っている個人/企業に、かなりお得なパッケージが登場。
1 年間のサブスクリプションフィー $99 (セルフサポート契約の場合) で、RHEL と各種アドオンが使えるようです。

従前は通常の RHEL サブスクリプションを買うしか無かったところ、かなり経費が節約できそうですね。"for development purposes only" ということで、実運用には使えないということのようです (MSDN のようなイメージですね)。

詳しくは、 THE RED HAT ENTERPRISE LINUX DEVELOPER PROGRAM および Red Hat Stotre の購入ページ をどうぞ。

今まで dotfiles は wiki で管理していたのですが、ようやく重い腰を上げて(?) GitHub に置いてみました。
品揃えは、zsh, vim, screen, mintty といったところ。普通すぎて、あまり見るべきポイントはありません...。

GitHub: kmaehashi/dotfiles

普段は Windows を使うので、Cygwin-aware になっているのが特徴と言えば特徴かも。
例えば、Cygwin では fork のコストが高いので、uname の代わりに ${OS} 使ってたりとか。ちょっとバッドノウハウっぽいけどね。

あとは、Cygwin 専用ですが zshrc_ssh_agent が便利かも。かなりルーズながら、ssh-agent のインスタンス管理をしています。
~/.ssh/ssh-agent-keys ディレクトリの中に鍵ファイルへの symlink を置いておくと、起動時に読み込んでくれるようになっています。
自分で作っておいて何ですが、手放せません。

${HOME}/dotfiles に clone して setup_dotfiles.sh を実行すると、ボクと同じ環境が出来上がるはずです :-)

HP ProLiant ML110 G5 で SATA 電源ケーブルのリコールの件。無事に交換部品が届き、返送も完了したので注意点などをまとめておきます。

• 交換品の発送前に、メールなどは特に届かない。申し込み時に指定した交換予定日の 2,3 日前に突然届く。
• 英語で書かれた手順書を読んで、送り状や通関書類、RMA 票を埋めないといけない (そんなに大変ではない)。
• 送り状には、重さをポンド、サイズをインチで書かなければならないので注意 (だが、自分は勝手に kg などと上書きして SI 単位系で書いた)。
• 交換作業と書類の用意が終わったら、不良品を返送するために DHL に電話で集荷依頼をする。
• DHL は平日の日中帯 or 土曜日午前中しか集荷してくれない。申し込み時に指定した交換予定日から 5 日以内に発送せよと書いてあるので、注意する (多少オーバーしても特に何もないような気はする)。
• DHL に土曜日午前中にお願いしていたが、自分の場合は 13:30 ごろに来た (企業じゃないから後回しにされたのかも)。
• DHL の人にパッケージを手渡すまで、送り状のビニールの封をしてしまわないように注意。
• 通関書類 (Invoice) は返送パッケージの中に入れないこと (DHL の人に手渡しする)。

Python スクリプトでは、

if __name__ == '__main__':

という記述をしばしば見かけます。この if 段落内のコードは、

• スクリプトを直接起動した場合、実行される
• 他のスクリプトから import された場合は、実行されない

という動作をします。

これによって、スクリプトの単体試験容易性を確保できる (単体試験用スクリプトから試験対象のスクリプトを import して関数単位の試験実施ができる) というメリットがありそうです。ぜひ、シェルスクリプトにもこの記法が欲しいですね。

bash ではスクリプトファイルのコールスタックが BASH_SOURCE 配列に格納されるので、これの配列長を見ることでコンテキストの判定をしてみます。
すなわち、BASH_SOURCE の配列長が 1 であれば、実行中のコードの記述されたスクリプトが直接起動されたと判断できそうです。

というわけで、実験してみます。2 つのファイルを用意します。

ファイル 1: lib_foo.sh (インポートされる側)

#!/bin/bash

function foo() {
    echo "foo! foo!"
}

[ ${#BASH_SOURCE[@]} = 1 ] && {
    echo "foo: begin"
    foo
    echo "foo: end"
}

ファイル 2: foo_caller.sh (インポートする側)

#!/bin/bash

. ./lib_foo.sh

foo

それぞれ実行権限を与えて、コマンド実行してみると…

$ ./lib_foo.sh
foo: begin
foo! foo!
foo: end

$ ./foo_caller.sh
foo! foo!

ということで、foo_caller.sh では lib_foo.sh をインポートしつつ、foo 関数だけを実行することができました。

[ ${#BASH_SOURCE[@]} = 1 ] && { ... }

の箇所は、お好みに応じて

if [ ${#BASH_SOURCE[@]} = 1 ]; then
    # ...
fi

などでもよいですね。

... と、ここまで書いておいてアレですが、シェルスクリプトの単体試験を行うことができるフレームワークとして shUnit2 なるものがあるそうです。フレームワーク自体もシェルスクリプトで書かれているという時点でハマりどころのありそうな香りがプンプンしますがちょっと楽しそうなので、今度触ってみようと思います。

追記(2012/06/18)
Web を検索してみると、

[ "${BASH_SOURCE}" = "${0}" ]

という条件で同じことを判別しようとしているサンプルがありますが、これはダメです (スクリプト内で自分自身を source したケースを考えてみると分かりますね)。