そんなにプライベートを犠牲にして大丈夫?

最近読んだソフトウェアエンジニアのキャリアの話が、みんなプライベートの時間も勉強しなきゃダメだという論調で、ちょっと私は疲れている。

hrnabi.com www.pasonacareer.jp paiza.hatenablog.com

曰く環境変化の激しいWeb系エンジニアは、プライベートを犠牲にして勉強しなければ最先端にはいられない。高給取りにはなれない。わりとみんな信じていることのように聞こえる。しかし本当だろうか。犠牲にするって、どのくらい犠牲にすればいいんだろう? 犠牲と比例して、技術力が伸びたり、給与が増えたりするんだろうか?

あっという間に知識が陳腐化するという仮定においては、時間の自由が大きい若い人ほど先端の勉強に時間を割くことができて、もっとも有能になりやすい。実際若くて有能な人は増えているように思う。それでも、オッサンたちがマネージャーにならず、第一線で働くことは可能なんだろうか?

ここで言うオッサンというのは30台前半のことで、まだまだ若手と言われてもおかしくない業界もたくさんある。そんな人々をオッサンと呼ぶのは正しいのだろうか?

Web業界で働いて、そしてちょっと離れたところから見るようになって、ずっとそんな事を考えている。子供が2歳になって、たくさん一緒に遊べるようになったので、もはやプライベートは犠牲にしたくないというのもある。

だから、私は、そんなに学習のためにプライベートを犠牲にするのは正しくないと言いたい。

例えば、プライベートが犠牲になるのではなくて、仕事が犠牲になるべきなんじゃないか?エンジニアが成長できないような仕事が、自動化もされずに残っている方がおかしい。普段、普通に働いて、家庭を大切にしていても、世の中に胸を張れるだけ成長できる仕事でなくてはいけない。あるいは仕事なんて17時には終わって、帰って勉強できるような余裕がなくてはいけないのでは?

ググっても答えが出てこないような仕事をしている時、人は確実に成長していると私は思う。学術論文を読んだり、新しい実装方法や、手法を試している時、コモディティでは無い知識が身について、あなたの市場価値は生まれているはずだ。 毎晩遅くまで働いているのに、もっと勉強しなきゃと神経をすり減らすのは終わりになったらいいなと私は思う。

はてなで働いていた時、周りのエンジニアがとても凄い人々に思えて、どうしたらそうなれるんだろうと思って、勉強しなきゃいけないという強迫観念にも似た何かに取り憑かれていた。 ほとんど後悔の無い人生だけれど、唯一後悔しているのは、妻との京都での新婚生活をもっと堪能しておけばよかった。という事だ。勉強しなきゃいけないと思いつめても、大して成果が上がらないなら、もっと妻と京都観光すればよかった。毎週末でも行くべきところは沢山あったと今は思える。週末動けなくなるほど勉強したり、仕事をしすぎる必要はない。

今はまた平日は忙しい暮らしをしているけれど、土日は完全に家族の時間にできているし、テレビゲームをしていて罪悪感を感じる事もなくなった。自分の成長を疑うこともないし、仕事も楽しい。そして何より、家族で過ごしている時間が幸福である。

もう少し、Web業界にワークライフバランスが普及しますように。

GoDaddy(Google Apps) からのドメイン移管

日本から利用している、Google Appsドメインを購入すると GoDaddy での取り扱いになったりするようです。 いろいろ不便があるので、さくらインターネットに移管しようと思ったところ異様に大変だったのでメモを公開しておきます。

1. GoDaddy から AuthCode を取得する。

Google Apps の管理画面から、"ドメイン" > "ドメインの追加と削除" > "詳細な DNS 設定" と遷移していくと、GoDaddy にログインできます。 ここで AuthCode もメールで送ってもらえるのですが、送り先が問題に。 どうも GoDaddy はデフォルトでWhois情報公開代行してくれるらしく、Whois の情報が DomainsByProxy(以下DBP)の情報 になっています。 AuthCode のメールもその登録されているアドレスに送信されて、さらに DBP が転送してくれます。 DBPの設定が正しく行われていればいいのですが、管理者が途中で交代していたりすると、メールがちゃんと来なくて ひどい目に合うわけです。

2. DomainsByProxy にログインして設定変更する。

じゃあ、DBPにログインして設定をちゃんとしよう。と思うわけですが、ログインIDもパスワードもわからない... 詰んだ.. と思ったところで

d.hatena.ne.jp

この記事です。詳細は書かれてませんが重大なヒントが。

productforums.google.com

このグループをよむとログイン方法が書いてあります。 先にかいた、Google Apps の画面から、GoDaddy に遷移するときに、ユーザーIDとパスワードが表示されていたのですが、 DBPへのログインは、そのユーザーIDの下1桁に+1 したものと、全く同じパスワードで可能だそうです。 (ユーザーIDは8桁の整数なので+1すればOKという意味。12345678 なら 12345679 にしてねという話。)

マジかよ!という感じですが、無事ログインできました。IDの生成方法どうやって見つけたんだろな−。という感じです。 DBPにはメールの転送先の設定などもあるので、適切に設定して、DBPはキャンセルして、ちゃんとWhois情報が掲載されるようにしましょう。 キャンセルのインストラクションは以下のとおり

Log in to your account at DomainsByProxy.com.

Select Private Domains, and then select the domain name(s) you want to cancel private registration for.

Click Cancel Selected, or click (Cancel private registration). The Confirm message displays.

Click OK. The Cancel DBP message displays.

Click OK.

(Make sure you click on both OK buttons to cancel the registration.)

(9/18 追記)

そのあとは、GoDaddy から AuthCode を送りましょう。 GoDaddy の設定画面で、ドメインの "Lock" を外しておく必要もあるので忘れずに。

AuthCode の準備ができて、ドメインの "Lock" が外れたのを確認したら、あとは

help.sakura.ad.jp

にしたがって設定すれば、移管処理は完了するはずです。 さくらインターネット以外でも、それぞれの会社で手順書があるとおもわれます。

9/18 追記

これで出来たと思ったら、さくらから連絡があり、転出元(GoDaddy)に拒否されたとのこと。 GoDaddy サポートに連絡したらDBPをキャンセルしないとだめらしい。 というわけでDBPをキャンセルした。

OS X(clang) で C++ を書いている時にデバッグする方法いろいろ

前提

  • Mac
  • C++ を書いていて
  • コンパイラgcc じゃなくて clang を使ってる
  • もっと良い方法があったら教えて欲しい。

デバッガ

gdb は使えないようなので lldb を使う。g++ コマンドが使えているなら、インストールされているはず。
gdb とコマンド名が若干ちがっているけどだいたい同じことはできる。

プロファイラ

valgrind が(ほぼ)使えないので、gperftools を使う。

$ brew install gpreftools

でインストール可能。プロファイリングを有効にするには

$ g++ your.cpp -o your.out -lprofile

コンパイル時にリンクするだけ。
プロファイル出力先は

$ CPUPROFILE=your.prof ./your.out

で実行時に指定する。
ここを読めばだいたい分かる。

ビジュアライズ

プロファイル出力はそのままでは読めないので、pprof コマンドで読む

$ pprof your.out your.prof

で対話的シェルが起動する。help で細かい使い方はわかるはず。
よく使うのは top とか web とかか。top は時間占有率(?)の高い関数がみえるし、
web は svgコールグラフを描画して、ブラウザでオープンしてくれる。

しかし、もうちょっと便利に見たいので qcachegrind を使う

$ brew install qcachegrind

qcachegrind は callgrind の出力を見やすく表示してくれるツール
callgrind 形式に gperftools の出力を変換する必要があるので

$ pprof --callgrind your.out your.prof > callgrind.prof

で変換。

$ qcachegrind callgrind.prof

で開く

関数名が16進数になってる...

既知の問題らしいので https://code.google.com/p/gperftools/issues/detail?id=562 に従って
コンパイル時のオプションを

$ g++ -Wl,-no_pie -g your.cpp -o your.out -lprofile

に変更。
これでも全部の関数は見えない。-g3 とかも試してるけれど効果無さそう。

LiveClip という chrome app を作りました

動画を見てもらうのが早いのですが、Chrome で開いている Web Site の好きな部分を、フチ無しのPopup Window で表示できるという Chrome App です。

なにが嬉しいの? という感じかもですが、

  • youtube, ニコ動 など popup window 表示に対応してない動画サイトでも小さな window で表示できる
  • しかも、どの window よりも最前面で表示される (dev channel のみの機能)
  • 更に、拡大縮小しても動画再生が可能(操作は不能になります)

という機能があります。ようは、"小さい画面でも動画を画面端で再生しっぱなしにしたい" という欲求のために作ったソフトウェアです。

Chrome App と Chrome Extension が協調して動いているので

の二つのインストールが必要です。

App の方を起動すると、超簡易なブラウザが起動します。ニコ動などログインが必要なサイトは、このブラウザで、ログイン処理をしておいて下さい。Chrome 本体と App では Cookie の管理が異なって居るためです。

画面が小さいPCだと、表示領域を有効につかえて便利です。

石狩DCに行ってきた

もう2週間もたってしまったけれど、先日さくらインターネットの石狩データセンターツアーに参加してきた。
倍率も高かったらしく自分としては参加させて頂いたという感じ。

さくらさんには、DCが完成する前に対談*1に呼んでもらっている上に、僕としては北海道在住も長いので、石狩DCは以前から行ってみたくて仕方がなかった。勝手に車で近くまで行ってみたりもしたけれど、当然中の見学はできないので、やっと念願叶ったという気持ちである。

参加者の感想blogは詳細なのが揃っているので、僕が関心した2点に絞ってお伝えする。

石狩DCは進化し続けていた

外気導入による冷却コストの削減とか、そもそも北海道に本州資本が大型DCをたてちゃうとか、かなり先進的な試みにみえた石狩DCであるけれど、その先進さは建てただけでは終わってないなかった。順調に2号棟の利用も開始されていて、その規模も大きくなっているし、技術的にも以前には聞かなかったものが増えていた。(アイルキャップとか600mm幅ラックの採用とか、他の人のレポートを参考にして欲しい。)


個人的には直流給電のラックが屋外の実験コンテナ*2から、正式採用になっていたのが印象的だった。*3
各サーバーに電源ユニットを置かなくて済むメリットは容易に想像できるけれど、同時に、直流で運用するとなる感電とか、火花がちるとかいろいろ問題がありそうで、よく正式導入できたなという気がする。

懇親会で鷲北研究所所長に直接伺ったところ、直流による弊害はコンテナのなかでの運用を通じて洗い出して行ったようで、ノウハウがいろいろと詰まっている雰囲気を感じた。

直流給電もまだ進化の途中で、石狩の広大な土地を利用したメガソーラー(自社運用を検討しているらしい)と直流接続するとか、超電導直流送電*4とか夢にあふれている。普段ソフトウェア開発にしか目の向かない自分としては、まさにインフラ構築の巨大なプロジェクトを見た気分であった。

2日目が楽しすぎる

2日目のオプショナルツアーは今年からだと思うのだけれど、前半は石狩湾新港地域の社会科見学という感じでとてもおもしろい。
さくらインターネットの田中社長自らバスガイドとして新港地域の案内をしてくれる。一見ただの工業団地ではあるのだけれど、巨大な風力発電所あり、LNG基地あり、大型発電所建設予定地*5、海底ケーブルの陸揚局と見どころはたくさんある(ライジングサンロックフェスティバルの会場になる空き地とか佐藤水産の工場なんかもある)。それぞれの施設がもつ逸話を田中社長がお話されるという趣きで大変楽しい。石狩DCに配電している変電所二箇所の見学などもあり、ただのプレハブとトランスが見えてるだけなんだけど、みんな盛り上がっているというおかしな企画でもあった。


どうみてもただのプレハブだが、大事な変電所だ。

石狩湾新港地域の社会科見学なんてそうあるものではないし、田中社長の語り口が非常に丁寧でとても楽しい時間が過ごせた。

バスツアーのあとは、1日目につづいて石狩DCの中に入って前目には見られなかった部分の見学をする。非常にレアな施設の見学も有り、またラックの近くまで寄って中身を見せて貰ったりする。実際にホットアイルの中にはいって暖かさを体感したり、さくらの専用サーバー*6が動いているラックをみたりする。実際に小さくて可愛いNECのE120d-Mが並んでるのをみると、これひとつ契約すればこの空間が専有できるのかー。ちょっと欲しい。という気分になれる。

かなりつめ込まれた感じの日程ではあったけれど大変楽しい2日目であった。

まとめ

参加している人々もそれぞれ面白いバックグラウンドを持っていて話していて参考になることが多いし、直接さくらの人とお話できるのでいろいろ裏話も聞ける楽しいツアーだった。まる二日間久々にテクノロジー好きに囲まれて過ごした気がする。

他の人のtwitterなどでご存知のかたも多いと思うけれど、予定のない時間は各々食い倒れツアーを開催していてそちらも、大きな見どころだろう。住んでいるので個人的には当たり前なのだが、札幌は美味しいものが沢山あるのでそれを目当てにくるのもよろしいのではないだろうか。きっと住んでみたくなる。


注)ツアーと直接の関係はありません

そういえば、北海道に長く住むといういう意味では、石狩DCに勤めるのも面白いかもしれないと思わせるツアーでもあった。現場のアイデアが活かされて進化していく職場があって、着いて行ってもいいかなと思える社長が見えるところにいるというのは良いことだと思う。

ruby の log は遅い

タイトルはちょっと釣りで、ruby を dis るのが目的ではない。

今書いてるコードで、log が入る計算がやたら遅いので、RubyInline で C の呼び出しにしたらだいぶ速くなった。これはちゃんと計測しなくてはということで、書いたのがこちら。

require 'benchmark'
require 'inline'
 
class Test
  inline do |builder|
    builder.include('<math.h>')
    builder.c <<-EOF
    double
    log_c(int i)
    {
      return log(i);
    }
    EOF
  end
end
 
Benchmark.bmbm do |x|
  t = Test.new
  rands = []
  10_000_000.times do
    rands << rand(1000)
  end
 
  x.report('ruby') do
    rands.each do |int|
      Math.log(int)
    end
  end
 
  x.report('inline') do
    rands.each do |int|
      t.log_c(int)
    end
  end
 
end
 
# Rehearsal ------------------------------------------
# ruby     9.840000   0.000000   9.840000 (  9.842299)
# inline   2.650000   0.010000   2.660000 (  2.667835)
# -------------------------------- total: 12.500000sec
 
#              user     system      total        real
# ruby    10.410000   0.010000  10.420000 ( 10.437814)
# inline   2.420000   0.000000   2.420000 (  2.422468)

ただlogの計算をするだけなのに、5倍くらい速度がちがう。

最終的な実装はどっちにしろ "math.h" の log だろうと思うのに、大変不思議。

ruby の Math モジュールのソースコードを読んでみる

static VALUE
math_log(int argc, VALUE *argv)
{
    VALUE x, base;
    double d0, d;

    rb_scan_args(argc, argv, "11", &x, &base);
    Need_Float(x);
    d0 = RFLOAT_VALUE(x);
    /* check for domain error */
    if (d0 < 0.0) domain_error("log");
    /* check for pole error */
    if (d0 == 0.0) return DBL2NUM(-INFINITY);
    d = log(d0);
    if (argc == 2) {
	Need_Float(base);
	d /= log(RFLOAT_VALUE(base));
    }
    return DBL2NUM(d);
}

おお。不正な引数のために、いろいろ頑張ってる。
これのどこが 5 倍も遅くしてるのか調べたい気もするけれど、今日はここまでにしておこう。

ちなみに、RubyInline で作った log 関数に -1 や 0 を与えると、それぞれ、NaN と -Infinity が返ってくるので、わりと実用に困らない。Math モジュールも工夫の余地があるかも知れない。

最初 Gist に書いたんだけど、埋め込み用のJSがエスケープされてしまう... blog に移れということかなあ。

OSX + screen + rbenv でハマった話

osx で rbenv を使っているのだが、screen と併用すると screen から起動した shell で正しく rbenv が動かなかったので対応メモ。

設定ファイルを正しく

rbenv を利用するには ~/.zprofile, ~/.bashprofile などに

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

と書く必要がある。

各種設定ファイルが呼び出される順番は
https://github.com/sstephenson/rbenv/wiki/Unix-shell-initialization
に詳しい。
(PATHの値が変わらなければ)一度呼び出せば良い物なので、zshrc, zshenv などに書く必要はない。

screen

screen から shell を起動した時は、設定ファイルのうち

  • ~/.zshenv
  • ~/.zshrc

は呼び出すが、~/.zprofile は呼び出さない。

http://masutaka.net/chalow/2012-11-19-1.html

に詳しい。呼び出すようにもできる。(login-mode で shell を起動できる)
zprofile は呼び出さないのだが、環境変数 PATH は screen から開いた shell に引き継がれる。
なので、改めて zshenv/zshrc で rbenv のための PATH が設定されなくてもきちんと動く。

/etc/paths の罠

というわけで、~/.zprofile に設定を書けば上手く動くはずなのに、screen から起動した shell では環境変数 PATH の順序がおかしい。これでしばらくハマったのだが、実は /etc/zshenv に

# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
    eval `/usr/libexec/path_helper -s`
fi

と書いてあって、これが PATH の順序をおかしくしていた。path_helper は /etc/paths に書いてある値をPATHの先頭にもってくる。

/etc/paths とか /etc/zshenv を書き換えても良いのだけれど、/etc 以下をあんまりいじりたくないので、brewzsh をインストールし直す。

 $ brew unlink zsh
 $ brew install --disable-etcdir zsh

これで /etc 以下の設定ファイルを無効にできる。

教訓

  • shell の設定ファイルはよく理解して使いましょう...