簡単なイメージは下図のとおりです。

NFSサーバはA,Bの2台ありそれぞれrsyncで内容が同期されています。それぞれのNFSサーバには仮想IPアドレス(以下、VIP)がそれぞれついています。クライアントはマウント時に、nfs.mynet(mynet部分はサービスのドメイン名等)をDNSに問い合わせると、DNSはNFSサーバのVIPのどれかを返却します。問い合わせごとに返却されるVIPが変わるため、各ホストがマウントするNFSサーバが分散する用になっています。

障害時には下図のとおり、VIPが正常な他方のNFSサーバに自動的に集められてサービスを継続します。

障害が解決すると、負荷分散のためフェイルバックをします。

ここまでの説明で「なんだkeepalivedか」と分かってしまう*勘の良い方*はもう以下読む必要がないかもしれません。NFS-1,2にはそれぞれkeepalivedがインストールしてあり、お互いをVRRPで監視しVIPを奪い合っています。全く難しいことはしていないのですが、強いて言うとVIPを実サーバ数分持ち、これを本来あるべきサーバに優先度をつけて設定するというのがミソです。

keepalived.confの設定は以下のようにNFSサーバ毎に優先度が異なっており、それぞれ変える必要があります。

NFS-1の設定

NFS-2の設定

DNSの設定

DNSラウンドロビンでnfs.mynetを問い合わせられたら、NFS-AのVIP(192.168.0.101)もしくは、NFS-BのVIP(192.168.0.102)が返されるように設定します。方法はDNSサービスにより異なりまた難しくないのでここでは説明を省かせて頂きます。

NFSクライアント

/etc/fstabにてマウントポイントを記述します。私は以下のようにしました。

nfs.mynet:/usr   /usr  nfs  tcp,ro,soft,intr  0 0

フェイル時にすんなりアプリケーションから再試行が掛けられるようにsoftマウントしてあります。

以上のような簡単な構成でスケーラブルな参照用NFSサーバの構築をすることができました。まだ運用試験段階なのですが、今のところ問題なく動いておりNFSサーバの再起動も気兼ねなくできるようになりました。「もっとこうやったほうがいいよ!」という知見をお持ちの方、貴重なご意見を是非コメント欄にお願いいたします。

rdefs 自体は るびまの添削記事 や 青木日記で紹介されています。これを emacs の anything から利用する anything-rdefs という emacs 拡張 を書いたので紹介します。anything の説明と導入方法の解説は行いません。

rdefs を emacs から利用することで、以下のようなメリットがあります。ただし、私が emacs はウィンドウ分割せずに利用していることもあり、細かくウィンドウ分割された状況での利用は想定していません。

• rdefs の結果を ruby-mode の配色で表示するので見やすい
• 左のウィンドウで定義をプレビューできる(後述のスクリーンキャスト参照)
• anything の絞り込みができる
• 該当行にかんたんに移動できる

インストールと設定方法を説明します。emacs に anything をインストールし、rdefs.rb をパスの通ったところに配置し、実行権限を付与します。rdefs.rb は

• http://i.loveruby.net/svn/public/bin/trunk/rdefs.rb

で公開されています。
次に anything-rdefs を

• https://github.com/wakaran/anything-rdefs/raw/master/anything-rdefs.el

からダウンロードし、ロードパスの通ったところに配置します。そして、dot.emacs などの設定ファイルに以下の内容を追記します。

(require 'anything)
(require 'anything-rdefs)

(setq ar:command "/path/to/rdefs.rb")
(add-hook 'ruby-mode-hook
  (lambda ()
    (define-key ruby-mode-map (kbd "C-@") 'anything-rdefs)))

(setq ar:command "/path/to/rdefs.rb") のところは rdefs.rb までフルパスで指定して下さい。Mac だと emacs がログインシェルの PATH を引き継がないことがあるらしいのでフルパスで指定するようにしました。
あとは、ruby-mode で開いているバッファで Ctrl-@ を押下すれば上の画像のようなウィンドウが表示されます。スクリーンキャストも作ってみました。

• anything-rdefs-demo-video

それから同様に、Sphinx などで利用されている rst ファイルの構造を表示し移動を簡単にする rst-goodies.el というのも書きました。よろしければお試し下さい。

最後に

ディノでは Ruby/Rails 案件を募集しています。6月中旬頃までに小さめのが一つ決まると最高なのですがどうでしょうか。ご検討のほどよろしくお願い致します。

さて、今日は社内での雑談の話題から、「~/.ssh/authorized_keys2」ファイルはobsolete（古い、時代遅れ）だよ、という話題です。

SSH1とSSH2が混在していたころの習慣だと思うのですが、~/.ssh/authorized_keysにはSSH1の公開鍵を、~/.ssh/authorized_keys2にはSSH2の鍵を置くきまりだと聞いたことがあります。しかし、これはもはや正しくないようです。

OpenSSH3.0のリリースノートには下記のような記述があります。

2) The files
/etc/ssh_known_hosts2
~/.ssh/known_hosts2
~/.ssh/authorized_keys2
are now obsolete, you can use
/etc/ssh_known_hosts
~/.ssh/known_hosts
~/.ssh/authorized_keys

このように、~/.ssh/authorized_keysで一本化されています。

OpenSSH3.0は2001年にリリースされたようなので、なんと9年前からobsoleteなんですね。9年経った今でも使えるということは、今後も当分は利用可能ということかもしれません。

私も長いことauthorized_keys2を使っていましたが、最近少しずつリネームしています。そこまで頑張って直すような性質のものではないと思いますが、私のように知らずに使い続けている人もいるかと思って紹介してみました。

• TDD で書いていないと不安が高じて動悸と息切れが始まる
• red-green-refactoring を唱えなさいとじっちゃに言われた
• growl の red を見ないとコードが先に進まない

よくある話だと思います。
まずテストが無いと何も始まらない！書いたテストはがんがん自動実行して使い倒したい！
となるとやはり、自動テストの出番ですね。

インストール手順

autotest コマンドをインストールします。rspec + autotest + インストール辺りでぐぐってください。
mac の人は autotest-fsevent を一緒にぶち込んでおくと良いのですが、fseventの README により軽量な autotest コマンドのインストールガイドがあったのでそちらを参考にするのが良いかも知れません。
（RSpec2 beta + Rails 3 beta で偶然か動作しなかったため、私は ZenTest を継続利用中です）

続いて autotest-anyをローカルに落とします。
gem 化してません。サボってます。

Symfony プロジェクトのルートディレクトリに移動し、autotest 用のディレクトリ autotest と設定ファイル .autotest を作成します。
ファイル群は autotest-ary/example 以下にあります。
ここで作成、配置するファイルはプロジェクトに応じて随時カスタマイズします。

autotest
|-- dinolimetest_php.rb
`-- discover.rb
.autotest

.autotest を適宜書き換えてください。

挙動とカスタマイズ

autotest はファイルとテストを対で覚えており、ファイルが更新されるとそれに該当するテストをテストコマンドに渡し、自動実行を行います。
$target_patterns はその監視対象とするファイルを指定するための正規表現集合です。
$exception_patterns はその通り、テスト実行や監視から外したいファイルを指定するための正規表現集合です。

監視対象ファイルとテストファイルを結びつけているのは次の部分です。

at.add_mapping($target_patterns) do |filename, _|
  testfiles = [
    at.find_local_unit_test(filename),
    at.find_local_functional_test(filename)
  ];
 
  puts "src: #{filename}  ->  test: #{testfiles.join(', ')}"
  testfiles
end

filename は監視対象となるファイルのパスです。　
find_local_*_test(filename) により対となるテストファイルのパスを決定しています。　
弊社の、某プロジェクトのメンバーには便利なメソッドだと思います。
メソッドの中身は簡単な正規表現なので、ここでさくさくっと書いてしまうのも良いと思います。

red-green できゃっきゃうふふする

あとは symfony のプロジェクトルートで autotest を実行するだけです。

/Users/sou_sk/work/project/working% autotest
loading autotest/dinolimetest_php
style: DinolimetestPhp
src: lib/model/JobQueue/JqProcPeer.php  ->  test: test/unit/lib/model/JobQueue/JqProcPeerUnitTest.php, test/functional/lib/model/JobQueue/JqProcPeerFunctionalTest.php
src: lib/model/JobQueue/JqJob.php  ->  test: test/unit/lib/model/JobQueue/JqJobUnitTest.php, test/functional/lib/model/JobQueue/JqJobFunctionalTest.php
src: lib/proc/ProcTest.class.php  ->  test: test/unit/lib/proc/ProcTestUnitTest.php, test/functional/lib/proc/ProcTestFunctionalTest.php
src: lib/model/JobQueue/JqJobPeer.php  ->  test: test/unit/lib/model/JobQueue/JqJobPeerUnitTest.php, test/functional/lib/model/JobQueue/JqJobPeerFunctionalTest.php
src: lib/model/JobQueue/JqProc.php  ->  test: test/unit/lib/model/JobQueue/JqProcUnitTest.php, test/functional/lib/model/JobQueue/JqProcFunctionalTest.php
src: lib/proc/ProcBase.class.php  ->  test: test/unit/lib/proc/ProcBaseUnitTest.php, test/functional/lib/proc/ProcBaseFunctionalTest.php
src: lib/model/JobQueue/JqTask.php  ->  test: test/unit/lib/model/JobQueue/JqTaskUnitTest.php, test/functional/lib/model/JobQueue/JqTaskFunctionalTest.php
src: lib/model/JobQueue/JqTaskPeer.php  ->  test: test/unit/lib/model/JobQueue/JqTaskPeerUnitTest.php, test/functional/lib/model/JobQueue/JqTaskPeerFunctionalTest.php
src: lib/proc/ProcHaveALunch.class.php  ->  test: test/unit/lib/proc/ProcHaveALunchUnitTest.php, test/functional/lib/proc/ProcHaveALunchFunctionalTest.php
php test/unit/lib/model/JobQueue/JqJobPeerUnitTest.php && echo "----------------------" && php test/functional/lib/proc/ProcHaveALunchFunctionalTest.php && echo "----------------------" && php test/functional/lib/model/JobQueue/JqProcPeerFunctionalTest.php && echo "----------------------" && php test/unit/lib/model/JobQueue/JqProcPeerUnitTest.php

といった形でテストが走ってくれれば成功です。
src: .. -> test: .. はデバッグ用に表示しており、全ての監視対象ファイルとテストファイルを列挙しています。
最終ラインに表示されているのは実行コマンドで、ここに現れない場合はテストファイルが存在しない（パスが違う）可能性が濃厚です。
また autotest コマンドがぱたっと終了してしまう場合は、add_mapping のブロック内で何らかのエラーが発生している可能性を疑ってみてください。

スクリーンが二面あるともっと幸せになれます。
ちなみに私は Dell の縦回転するディスプレイを用意して自動テストのログをだらだらと表示し、もう片面をテキストエディタで埋めてコーディングに没頭するのが好きです。ヘンな脳内麻薬が出てきますよ。お勧めです！
TextMate のようなショートカットからコマンドを実行出来るエディタ + AppleScript を使うとブラウザのリフレッシュまでコマンド一発、スクリーン固定で出来るのでもっとお勧めです。

余談ついでに、autotest のような監視＆実行を行うツールとしては他に
wathcrや
弊社高原の watchdirがあります。
autotest でうまくいかない！ もっと他の方法がいい！という人はこちらもお試しください。

autotest-any を作った後に watchr に気付きました、、、今から作るなら watchr かも知れません。

追記:
TextMate の LimeTest 実行コマンドを書きました。
需要ある方はご利用ください。

株式会社ディノではテストフェチな開発者を絶賛募集中しています。

ブランチ一覧を得る

git branch

svn list http://example.com/svn/branches

ブランチを作る

git branch mybranch

svn cp http://example.com/svn/trunk http://example.com/svn/branches/mybranch -m 'create mybranch from trunk'

以上のように、svnはブランチをブランチとして扱っていないためとても面倒なコマンドを打たなくてはなりません。これではとてもsvnのブランチなんて使ってられないのでとっととgitに移動したいところです。しかしながら、諸処の都合によりまだ、しばらくは両方使い続けなくてはならないため、svnのブランチ操作を簡単にする、svnbrというRubyスクリプトを書きました。

ソース: http://github.com/tumf/svn-utils/blob/master/svnbr

このスクリプトが利用出来るのは、/branches以下にブランチを作って/tags以下にタグを作る人向けです。殆どの人がこの構成を使っているはずですが、svnはこれ以外のパスにも自由にブランチやタグを作れますので（というより、タグとブランチの区別がない）ご注意ください。

使い方をざっと説明します。svnbrはすべてワーキングディレクトリの上で実行します。まず、何もつけずに実行するとブランチの一覧を表示します。

$ svnbr
mybranch-1.2
mybranch-2.x
*trunk

頭に*がついているブランチが現在のワーキングディレクトリのブランチです。svnbrでは、例外的に/trunkもブランチと同じ扱いをします。

次に、他のブランチにswitchしてみます。

$ svnbr sw mybranch-1.2

これは以下のコマンドを実行するのと同義です。

svn sw http://example.com/svn/branches/mybranch-1.2

もしsw先のブランチがなかったときはsvnのswと異なった挙動をします。

$ svnbr sw mybranch-1.3

これは以下のsvnコマンドと同義です。

svn cp http://example.com/svn/branches/mybranch-1.2 http://example.com/svn/branches/mybranch-1.3 ¥
-m 'make mybranch-1.3 branch from mybranch-1.2'
svn sw  http://example.com/svn/branches/mybranch-1.3

上記のように、現在のワーキングディレクトリのブランチをコピーしてsw先のブランチ作成し、swします。

以下のようにして、タグからブランチを作ることもできます。

$ svnbr sw mybranch-1.2 --from-tag=VERSION-1.2.3

mybranch-1.2をtrunkへマージするときも、svnコマンドと同様にできます。

$ svnbr sw trunk
$ svnbr merge mybranch-1.2 -c 4,5

いらなくなったブランチを消すには

$ svnbr rm mybranch-1.2

他にも、logを見る時には以下のようにします。

$ svnbr log mybranch-1.2

これは、以下のように–stop-on-copyをつけて実行します。

svn --stop-on-copy http://example.com/svn/branches/mybranch-1.2

ブランチのリネーム

$ svnbr mv mybranch-1.2 mybranch-1.3

これは、以下のように実行します。

svn mv http://example.com/svn/branches/mybranch-1.2 http://example.com/svn/branches/mybranch-1.3　¥
-m 'move branch mybranch-1.2 to mybranch-1.3'

以上のように、ざっくり作ったスクリプトなんで不具合等ありましたら申し訳ありません。
githubにおいてあるので、是非forkして改良してくださいね。

RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS
.make.state .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak
*.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe
*.Z *.elc *.ln core .svn/ .git/ .bzr/

転送すると問題になりがちなファイルを転送対象から外せるので、普段はとても便利です（よく見るとEmacsユーザーにしか影響の無いファイル*.elcも混ざってますね）。でも、「上記のうち*.soだけは転送したい」なんて時はどうすればいいんでしょうか。

解決方法は色々あると思いますが、私はrsyncのオプションに「--include-from=rsync_include.txt」を追加し、rsync_include.txtを下記の内容で作成しました。

*.so

これで-Cにより他のファイルを転送しないままで*.soだけ転送するようにできます。バイナリ配布されている共有ライブラリをデプロイしたい状況で上記のように対処したので、小ネタとして記録しておきます。

ディノも昨年から JavaScript 案件が増えており、本格的な JavaScript アプリケーションも実装するようになってきました。ただ、サーバサイドのみの開発に比べるとXMLHttpRequest経由でサーバサイドとのつなぎ込みが発生するので、問題の切り分けや実装スケジュール調整など難しい点もあるのではないでしょうか。

そんな時には jquery.mockAjax プラグインが便利です。

概要

これを使うと $.ajax のリクエスト先を条件に従い振り分ける事が出来、スクリプトや HTML の書き換え無しにサーバ側への通信をカットし、
ローカルファイルで用意した JSON や HTML フラグメントを代わりに持ってくる事が出来ます。

小さい＆単純なコードですが、これでサーバ側の実装に依存せずクライアント開発をさくさく進める事が出来ます。

また、クライアントとサーバ側の開発担当を分けるような場面でも、クライアント側が期待するレスポンスを具体的な JSON として示すことが出来るので話が早く進んだり、
開発中のサーバに接続出来ない環境でのデモを見せる際など、方々に活躍、、していた気がします！

使い方

使い方は簡単、

$.mockAjax(
  {
    cond: /\/search\?.*q=no_result/,
    method: 'get',
    url: '/pseudo_data/search_response_no_result.json'
  },
  {
    cond: '/map/search?q',
    method: 'get',
    url: '/pseudo_data/search_response.json'
  }
);

のように引数の JSON で設定を与えます。
リクエスト先 URL が cond の正規表現と method にマッチした場合、url に置き換えられます。
検索語句によってレスポンスを変えたい！と言った場合にも、上記のようにして対応しています。

興味を持たれた方は是非一度お試しください。 「他にこんなやり方もあるぜ！」といったツッコミ、情報もお待ちしております。

株式会社ディノではエンジニアを絶賛募集中です。

Googleが新しいプログラム言語を発表しました。早速プログラムされている方(1 2)とか尊敬します。最近はご無沙汰ですが、C++最強説を今だに唱え続ける自分としてはGo For C++ Programmersのようなドキュメントをみるとうれしくなってしまいまして、Go For C++ Programmersの最初の”Conceptual Differences”部分を勝手に和訳しました。権利的に問題があれば削除します。

適当に訳したので致命的な誤訳はありそうです。コメント欄で指摘頂けるとありがたいです。

以下、訳となります。

GoはC++のような汎用システム用のプログラム言語を目指しています。C++プログラマ向けにいくつかの注意点があります。このドキュメントでは、GoとC++の違いについて説明する事であまり違わない事が判るよ。

Goのもっと一般的な紹介は、”Go tutorial”や”Effective Go”を見てくださいね。

Goの細かい仕様を知りたいなら、”Go spec”をみてね。

GoとC++の概念的な違い:

• Goにはコンストラクタやデストラクタをもったクラスはないよ。クラスメソッド・階層的なクラスの継承・仮想関数の替わりにGoにはこの後に詳しく説明するインターフェイスがあるよ。インターフェイスはC++でいうとテンプレートみたいなものだ。
• Goはガベージコレクションを使うよ。メモリーを明確にリリースする事は必要ないよ。ガベージコレクションは最近のプロセッサーではますます効果的になっているよ。
• GOはポインターを持ってるけど、加減算はできないよ。文字列の各バイトを順に調べるのにポインタの値を使う事はできないよ。
• Goの配列はファーストクラスの値です。配列が関数のパラメータとしてつかわれると、関数は配列のポインター(参照)ではなくコピーを受け取るよ。しかしながら、実用的な関数では、よくパラメータにスライスが使われるよ。スライスは配列の元になるポインタをもっているよ。スライスについてはあとで説明するね。
• 文字列が言語の機能にあるよ。文字列は生成されてから変更されないよ。
• ハッシュテーブルも言語の機能にあるよ。これらはマップと呼ばれているよ。
• チャンネルというスレッド間通信も言語の機能にあるよ。これについてはあとで説明するね。
• いくつかの型(map, channel, etc.)は値渡しではなく参照で渡されるよ。つまり、マップは関数に渡される時にコピーされないし、関数の中で変更されると、呼び出し側も変わるよ。C++でいうと参照型ですね。
• Goはヘッダファイルを使わないよ。かわりに、それぞれのソースファイルは定義されたパッケージの一部になるよ。パッケージが大文字から始まる名前のオブジェクト(型,定数,変数,関数)として定義されると、そのオブジェクトはそのパッケージをインポートした他のファイルからも見えるようになるよ。
• Go は 暗黙の型変換はしないよ。異なる型の変換にはキャストが必要ですよ（Goではコンバージョンとよびます）
• Go は関数のオーバーロードやユーザが定義できる演算子はないよ。
• Go にはconst や volatile制約はないよ。
• C++ではNULLや0だったけど、Go無効なポインタにはnilを使うよ。

以上：

あれ、C++ と Boost の組み合わせってやっぱ最強ですか。

追記2: #interfaceの和訳を発見しました！。つづきはこちらで
ならって本稿のタイトルも修正しました。

募集するエンジニアについて

ディノではプログラミング・データベース・サーバ管理などの分野について一家言あるようなエンジニアを募集しています。ディノは社長が技術者ということもあり、技術指向の強いメンバーが集まっている会社だと思います。これは本ブログの内容からも見て取れるのではないでしょうか。

弊社ではプログラミング言語としてPHPを採用していますが、プログラミング言語の知識はそれほど重視していません。Webで複数人での開発を経験されている方なら、言語の知識は大して重要ではないと考えています。また、多少経験が足りなくても熱意のある方なら大歓迎です。入社後にはsymfonyを利用してWeb+DBシステム構築のプロジェクトに参加して頂くことになります。

サーバ・ネットワークまわりに特化したエンジニアも募集しています。サーバ周りでは仮想化技術に特に注力していますので、面白そうな会社だと思った方はぜひ一度面接にいらしてください。

面接の流れと内容

採用情報からエントリーしてください。担当者が面接の日時を調整いたします。

1次面接では、技術面に関してお伺いします。技術力だけで仕事をするわけではありませんが、仕事上の重要な基礎力の一つとして、現時点で獲得している知識、技術的な興味、今後伸ばして行きたい方向などをお聞きします。

過去の案件での具体的な苦労話や、案件からは少し離れた知識、最近試した面白い技術、などについて、ざっくばらんに話して頂きたいです。アピールできるような材料やエピソードを用意してきて頂けると面接がスムーズに進むと思います。

2次面接は開発部トップの役員が担当します。希望するポジションについてのすり合わせを行わせて頂きます。社内のどのチームでどう働いてもらえそうか、具体的なイメージを持てるレベルでお話させて頂きます。また、これまでの経験や実績についての話を1次面接より具体的にお聞きし、希望する条件についてもお話いただきます。

最終面接は社長の高原が担当します。お互いに長く働けそうかを確認しあった上で、最終的な条件の確認を行います。これから働いてもらう人のためにも、入社前に自分の目と肌で会社の雰囲気と社長の人となりを判断してもらいたい、というのが高原の考えです。

もし興味を持った方がいらっしゃれば是非ご応募ください。社員一同、未来の同僚を心待ちにしております。

$ php -r 'var_dump(PHP_INT_MAX);'
int(2147483647)

64bit環境では次のような結果になります。

$ php -r 'var_dump(PHP_INT_MAX);'
int(9223372036854775807)

ところで、最小の整数が必要な場合はどうすればいいのでしょうか。実は最小の整数は定数定義されていないのですが、次のようにすれば取得できます。

$ php -r 'var_dump(~PHP_INT_MAX);'
int(-2147483648)

64ビット環境でも同様です。

$ php -r 'var_dump(~PHP_INT_MAX);'
int(-9223372036854775808)

ここで利用した~というのはビット反転した値を返す単項演算子です。2の補数表現を思い出してください。

• 最大の整数の2進表現：0111…111
• 最小の整数の2進表現：1000…000

上記のように、最大の整数をビット反転させれば最小の整数になることがわかります。短く書けてカッコいいと感じたので紹介しました。

Web業界にいるとビット演算と縁遠くなってしまう気がしますけど、エンジニアの基礎体力の一つだと思うので、読めばわかる程度には慣れておいた方がいいと思います。

もちろん、仕事で書くなら次のように書いた方が親切かもしれません。

$ php -r 'var_dump(-PHP_INT_MAX-1);'
int(-2147483648)

PHP_INT_MINをdefineすれば更に親切ですね。