blog.youhei.jp

ISUCON5 予選で敗退しました

satsumaimoko — Fri, 02 Oct 2015 14:02:00 +0900

ISUCON5 予選にチーム「じゅげむおじさん」で参加しました。

特に何の準備も出来なかったので今回は参加を見送ろうかとも思ったのですが、前回も同じ理由で見送っていたのでまずは何事も経験、という思いで参加しました。

結果は微妙な改善に終始して最後は FAIL、という感じで惨敗でした。

良い結果が出なかったこと以上にいつも通りやることが出来なかったのが悔いが残ってます。

急造チームでバタバタしがちだったり細かい反省は色々あるんですが、まずは自分が、コードレビューして、MySQL のクエリをみて、メンバーと話し合って、改善してみる、という普段仕事であたり前にやっている流れを全然作れなかったのが問題だったなあと感じています。

kataribe や pt-query-digest といった ISUCON で常連の分析ツール類も使いましたが、そういった道具の使いこなし以上に普段通りにやってみてわからないことは手をつけない、ということを徹底する意識を持つべきでした。

反省の弁だけだとあれなので、他のことも。 GCP など普段触れていない技術に触れる良い機会にもなりました。

以下は、そのあたりの雑感です。

Google Compute Platform のインスタンス起動が驚くほど速かった
systemd はじめて扱ってみた。まあ慣れればこれでも良いかなという感じ。ログの読み方がわからん！となったけど journalctl というのがあるのね、、
Spring Boot は小さく始められる反面機能も盛り沢山なフレームワークという印象。コンフィギュレーションが少なくて Spring の印象が変わった。

まとめ

ISUCON って参加したほとんどの人は悔いが残るものなのだと思うんですが、競技内容が普段の仕事に近いので後悔の念を仕事で返していけるのがとても良いな、と終わってしばらくして感じました。

今回はカオスなまま時間がなくなってしまったので、もし次があれば問題箇所を十分把握した上で改善する時間が足りなかった、という程度のレベルには達していたいなあと思います。

というわけで、何事も普段通りやるのが大切ですねー。

主催ならびに出題者のみなさん、ありがとうございました！とても楽しかったです！

Effective Java 第2版

satsumaimoko — Sun, 12 Apr 2015 22:59:49 +0900

Effective Java 第2版読んだ。「並行性」とか副読本無いとちゃんとわかんないなと思ったけど、脚注でオススメされてる副読本が Java 並行処理プログラミングやプログラミング言語 Java 第4版なので、どんどん分厚い本を読む流れが出来ているのであった。。
— Youhei Nitta (@youhei) March 15, 2015

ということで、ちょっと前になりますが、ようやく Java のバイブルを読ませていただきました。

この本を読みつつ仕事で Java を触りつつという感じでしたが、この本自体が Java 5 以降の標準ライブラリにかなり影響を与えているなあと感じました。それくらい Java を書く上で普遍的なベストプラクティスを集めた本なのだと思います。

lombok が生成するボイラープレートコードなんかも最初「ここまで書く必要あるの？」とか思うものですが、事前にこの本を読んでると納得感がありました（長いものは長いけど）。

この第2版は2008年11月に上梓されて、Google I/O 2008 で Effective Java Reloaded として著者自ら初版との差分を解説してくださっているようです。

次の Google I/O あたりで Effective Java Revolution として Java SE 8 向けのベストプラクティスを盛り込んで解説いただけたら嬉しいなあと妄想しました。

まあ Java 8 は、まだまだこれがベスト！というのは言い切れない時期なんで難しいですかね。

次の Java 関連書籍ということで最近は「API デザインの極意」をちまちま読んでいます。「Java並行処理プログラミング」と迷ったんですが、Java のコードレビューする人が読んでると良さそうな本、という観点で前者になりました。

オライリーの「Java パフォーマンス」も良書の予感ということのようなので微妙に気になってきています。

しかも、ここ最近は2年ほど成長してない英語をそろそろちゃんとやろう、ということで行動し始めているので読書ペースは目に見えて落ちてしまいそうです。

このあたりのトレードオフはいつでも難しいですが、「何もやらないよりはだらだらやった方がまし」の格言にすがってあせらずのんびりやっていこうと思います。

LINE Developer Meetup in Fukuoka #9 LINE Fukuoka のエンジニア @youhei が発表します。これまで LINE...

satsumaimoko — Wed, 07 Jan 2015 23:05:00 +0900

LINE Developer Meetup in Fukuoka #9

LINE Fukuoka のエンジニア @youhei が発表します。

これまで LINE ファミリーアプリのサーバサイドは Perl の実績が豊富でしたが、2014年後半から Java SE 8 を採用するケースも増えてきました。今回の発表では、なぜ Java8 を採用するのか、現在どのように使っているのかについてコードを交えて紹介します。

発表しました。

参加者の皆様と査読してくれた同僚の方々ありがとうございました。

HTML 版はこちら。

昨年の九月から LINE Fukuoka に入社して Java8 を使ってみて感じたことを話しました。現場の雰囲気が少しでも伝わったなら嬉しいです。

Togetter にも当日の反応がまとめられていました。ありがとうございます。

当日、乾杯の挨拶で忘年会シーズンだったのに「ウェーイ」と言わなかったことだけが悔やまれます。

最後にひとつ。LINE Fukuoka ではアプリケーションエンジニア、フロントエンドエンジニアを募集しています。

『Java 2 Standard Edition 5.0 Tiger 拡張された言語仕様について』

satsumaimoko — Fri, 28 Nov 2014 20:51:56 +0900

PDF で配布されている『Java 2 Standard Edition 5.0 Tiger 拡張された言語仕様について』を読みました。

最近読んでいる Effective Java がジェネリックスの章に差し掛かってきたのですが、その前に J2SE 5.0 の言語仕様をおさらいしておきたいなと考えていたところ出会ったのがこちらの PDF です。学習利用に関してはフリーでコピー可ということで Kindle に入れて読みました。

著者は Effective Java の翻訳者でもある柴田芳樹さん。 5.0 で追加になった言語仕様について詳細に書かれています。ジェネリックス、ボクシング・アンボクシング、拡張 for 文、enum、static インポート、可変長パラメータ、アノテーション、といった豊富な仕様追加に関して 100 ページ超の分量で詳細に書かれています。また 1.4 での拡張についてもところどころ触れています。

ライブラリの追加・変更についてはかなり駆け足になっているのですが（java.util.concurrent パッケージの追加など）、そちらにあまり興味がなく自分が読みたかった言語仕様の部分だけを抜き出してくれていたので逆に助かりました。

ジェネリックスに関してはブリッジメソッドの仕組みを javap を使って解説していたり、共変戻り値型、ワイルドカード、パラメータ型の継承関係など個人的に曖昧だった部分を完璧に解説されているので、非常に助かりました。ジェネリックス以外の仕様追加についても、今まではなんとなく把握して使うだけという状態でしたが（ジェネリックス以外はざっくりした理解でも使うだけなら出来ちゃったりする）、仕様追加の意図やコンパイラによってどう変換されるかが厳密にわかりました。

読み終わってみて、Java SE 8 のアップデートもかなり大規模とはいえ 5.0 はやはり Java 最大のアップデートなんだなと感じました。しかもそのアップデートの大半をコンパイラのレイヤで解決してるというのが特徴ですね。5.0 リリースが 2004 年で、2014 年に invokedynamic を利用する形でラムダ式が導入されるまで10年も処理系（JVM）に依存する言語仕様の変更が無く、良くも悪くも安定期だったのがここ最近までの Java なのかなと思います。今後は処理系の更新を伴う新しい型の導入が計画されていたりずいぶんアグレッシブな展開が見えているので業務で Java を使うようになった身としては期待が膨らみます。

なぜ今さら 5.0 の本を読むの？と思うヒトも多いと思います。これは、プログラミング言語の学習をする際にバージョンごとの差分を把握しておく、という点を自分がかなり重要視するからかもしれません。

実際にたくさんのライブラリを利用して開発したり、既にあるコードに手を入れていかなきゃいけない局面では、実装当時のバージョンと現在のバージョンの差分を知っていることがコードの読み書きやライブラリの取捨選択に役に立つことが多いと感じているからです。

読み終わってみて今度は J2SE 5.0 と Java SE 6 の差分を把握できるまとまった資料が読みたいなあと考えているのですが、ひしだまメモが良さそうなので読んでみるつもりです。書籍でまとまったやつがあれば良いのですが、通常のメジャーバージョンアップだと書籍化するほどの分量にはならないでしょうから J2SE 5.0 と Java SE 8 差分以外はリリースノートも含め Web で読むのが良いのかもしれません。

Java による関数型プログラミング

satsumaimoko — Sat, 15 Nov 2014 13:30:00 +0900

「Java による関数型プログラミング―Java 8ラムダ式とStream」を読みました。

The Pragmatic Bookshelf で出版されていた ”Functional Programming in Java” の翻訳本です。 Java 8 の言語仕様に追加になったラムダ式に焦点をあてて、Stream API で実現していることやデザインパターンの進化を解説してくれています。

一般的にはラムダ式と Stream は対になって語られることが多いと思います。”Project Lambda + Stream API” といった感じで。

この本では少し違ってます。

まず、ラムダ式の追加という言語仕様上の大きな変更が土台にあります。そして、その土台の上にコレクション操作や遅延評価の新しい設計手法が可能になり、その流れの中で必然的に Stream が出てきます。という順序になっていて大変わかりやすかったです。

結局のところ、Stream API もラムダ式によるパターンのひとつに過ぎず、しかしそれが標準ライブラリに組み込まれたことが Java にとって大きいのだなと捉えられたのが自分にとっては収穫でした。

二百ページ強でさくっと読めますし、ひとつのテーマに絞られていてわかりやすい良い本でした。

業務で Java 8 を使っているので、社内勉強会でも本書を簡単に紹介しました。

デザインパターンに与える影響の大きさが印象に残っていたので、その辺りを多めに出したスライドになっております。だいぶざっくり感のある社内向けスライドですいません。

以前紹介した「Java SE8 実践プログラミング」と「Java による関数型プログラミング」を読んで最近の Java を把握してきた気になってきたので、今は基本を抑えようと Effective Java を読んでいます。Effective Java を読んでいると「プログラミング言語 Java 第4版」を読みたくなるのですが、たぶん最近読んだ本も含め、読む順番が逆の方が良かったんだろうなあと若干後悔しております。

『知識を体系化したいときは「厚い本」から読む』というライフネット生命・出口治明さんの金言が身に沁みるこの頃です。

プログラマ”まだまだ”現役続行

satsumaimoko — Sun, 26 Oct 2014 22:54:00 +0900

先週まで読んでいた「Java SE8 実践プログラミング」の翻訳者、柴田芳樹さんの著書「プログラマ”まだまだ”現役続行」を読みました。

柴田芳樹さんは “The Java Programming Language 4th Edition”, “Effective Java 2nd Edition” といった Java の名著を翻訳されている方です。

最近の自分は Java の再入門をしていてこれら翻訳本にお世話になることは間違いないこと、九州工業大学出身ということで福岡に住んでいる自分としては身近な存在に感じられたことの二点がきっかけで本書を手に取ってみました。

ずっと現役のプログラマで居続けるために著者が取り組んでいることがまとめられています。著者のスタンスは人によってはストイックに感じるかもしれません。ただ、中長期的な視野に立った自己投資の重要性を痛感しているので大変ためになる内容でした。

著者はプログラマに必要不可欠な能力として以下を挙げられています。

論理思考力
読みやすいコードを書く力
継続学習力
コンピュータサイエンスの基礎力
朝型力
コミュニケーション力
英語力

納得、という感じですよね。

とりわけ「朝型力」という章が楽しめました。自分は若くて時間があるときは一気呵成に集中的に時間を投資することで自分の専門性を担保しようとしていたのですが、結婚して子供が生まれたときにこのやり方はうまくいかない、と強く感じました。

そのときに継続してコツコツ学習するスタイルに切り替えてみたのですが、マラソンランナー気質な自分に合っていたし、家庭生活との相性も良いし、健康や精神衛生上も良いし、と良いこと尽くめでした。もちろん家族の支えあってこそ継続できているわけですが。

以上の経緯もあってこの章は非常に共感しました。

著者が名著をしっかり読み込むことも CS の基礎力をつけることも継続学習することも、朝の静かな時間をオフィスで過ごすことで実現してきたという所は読んでいて心強かったです。

著者とはメジャーリーガーとリトルリーグくらいの差はありますが、自分もオフィスに人が集まりだす一時間前に来て技術書を読んで過ごす習慣があります。

マイペースを崩さずにコツコツやっていけば、自分でもなんとかそれなりの使い物にはなるかもな、とある種開き直りのような気持ちにもなれました。

著者のブログもこの「プログラマ現役続行」というテーマでどんどん更新されていて、とてもおもしろいです。

http://yshibata.blog.so-net.ne.jp/archive/c20379492-1

ということで夜更かししたので今日はもう寝ます。おやすみなさい。

Java SE8 実践プログラミング

satsumaimoko — Tue, 21 Oct 2014 20:15:23 +0900

「Java SE8 実践プログラミング」を読みました

http://book.impress.co.jp/books/1114101010

九月から Java 8 を仕事で使うようになりましたが、Java を仕事で使うのは六年ぶりだったのでおさらいがてら読んでみました。

久々に読む Java の本としては最適だったような気がします。

以下の二点が特に助かりました。

ベストな書き方をいきなり提示していない
著者の意見が書いてある

ベストな書き方をいきなり提示していない

Java 8 はこれまでのメジャーアップデートの中でもかなり大きな変更が加わっているバージョンです。この本では Stream API にしろ、java.time.* にしろ、Java 8 として推奨される書き方とそこに至るまでの紆余曲折がわかるようになっています。Java 5 で理解が止まっている自分にはすごく助かりました。

著者の意見が書いてある

例えば、インターフェースに static メソッドが追加できるようになった、という仕様変更については、「コンパニオンクラス（Arrays とか Collections のようなユーティリティメソッドを集めたクラス）を別に提供する理由はありません」と書いてあったり、Java 5 で Scanner を追加したのに Java 8 で BufferedReader#lines を追加することに批判的だったり、単なる紹介に留まらず個人の見解を示してくれていたので記憶に残りやすかったです。

Java 8 所感

最近改めて Java を使っていて、着実に進歩している点はやっぱりすごいなと感じています。かつては冗長さが辛いと感じていたりもしましたが、Java 8 + lombok だとすっきり書けたりもします。

個人的に Java は一時期停滞していた印象がありましたが、Valhalla や Panama など JVM の改善もありますしリリーススケジュールも安定していて明るい未来を感じます。

まとめ

Java 8 を扱っている和書がまだ少ない中で貴重な本だと思います。自分のように久々に Java を触る人には特にオススメです。

著者が書いている Core Java シリーズも読んでみたいなあと思うようになりました（Java 8 対応したら。。）。

あとは Effective Java などバイブルとされる本も読まずに来たので、しばらく技術書のチョイスは Java づいていこうかなと思います。

ハイパフォーマンスブラウザネットワーキング

satsumaimoko — Wed, 11 Jun 2014 23:23:00 +0900

「ハイパフォーマンスブラウザネットワーキング」を読みました。

裏表紙の概要に、

“本書はカバーする技術範囲の広さを「パフォーマンス」という軸に沿って説明します”

とある通り、プロトコル仕様ひとつひとつについて、それがパフォーマンスにどういう影響を与えるかという観点において徹底した解説になっています。その反面、例えば TLS の章は実際のセキュリティをどのように担保しているかについてはシンプルな解説に留めていたりもします。あくまでパフォーマンス最適化のための書籍であって、プロトコルの詳細については別の書籍などで理解を補足した方が良いと感じます（例に挙げた TLS だと自分は Qiita のこの記事を併読しながら読みました）。

章構成が見事で、おそらくこの本のメインターゲットである Web アプリケーションエンジニアが興味を示しそうな Web サイトパフォーマンス最適化や HTTP 1.x に関しては 10 章と 11 章と随分後ろになっていました。これは、個々のパフォーマンス最適化テクニックに対してのトレードオフについて理解するには HTTP より下のレイヤーの知識が不可欠であることが関係していると思われます。

また、著者はこういった最適化が「フロントエンドパフォーマンスの分析・最適化」と扱われる状況に警鐘を鳴らしています。結局はネットワークの知識が必要な領域だし、テクニックを鵜呑みにして濫用しても自分たちの指標で検証できなければ適切に運用できないからなのでしょう。

HTTP/2 に関しても、そこに至るまでの経緯を踏まえた上だと「なぜHTTP/2 が必要なのか」がすんなりわかる構成になっています。サーバプッシュについて読みながら、取り回しの悪い CSS Sprite、JS ファイルの結合、ドメインシャーディングといったテクニックの無くなる未来に期待を膨らませました。

ネットワーク API である XMLHTTPRequest, Server-Sent Events, WebSocket, WebRTC についても、各 API の登場の背景と、表面上の挙動だけでなくネットワークスタックについて理解できる内容になっていて、XHR しか使ったことの無い自分にはちょっと先の未来を見せてもらった感じがしました。

サイトパフォーマンスというとよく話題になる Steve Souders 氏の「ハイパフォーマンスWebサイト」シリーズとは異なる骨太なアプローチで、「なぜ」がわかる点がこの本の醍醐味になっていると思います。なお、本書の「まえがき」は Steve Souders 氏によるもので、著者の Ilya Grigorik 氏をネットワークの神様と称し賞賛（というか激賞）の言葉を贈っていました。

極端なことを言うとネットワークに関係するアプリケーションを書く人はみな読むと良い本、ということになるけど、例えば以下のキーワードでむむっとなる人は楽しく読めるんじゃないかと思います。

ICE, STUN, TURN
モバイルネットワークの RRC ステートマシン
TCP の HoL ブロッキング、HTTP の HoL ブロッキング
SPDY が TLS を必須として HTTP/2 がそうしていない経緯
HTTP/2 で陳腐化する HTTP/1.x の最適化まとめ
TCP と HTTP/2 のフロー制御の類似性

インターネットを支える技術について基礎から知りたかった自分には良いタイミングで出会えたなあという本でした。あと、以前から優れた著者が書き上げた本はつまみ読みしてはいけない、という自分内家訓があったのですが、この本でより強化された感じがします。

Medium

satsumaimoko — Mon, 04 Nov 2013 02:14:41 +0900

Medium をさわりはじめました。

https://medium.com/@youhei

シンプルなデザインと notes の仕組み（typo を著者だけにこっそり指摘できたりとか）が好みです。ハイパーリンク・画像・箇条書きを多用したブログっぽい文章より、まとまって通読するような文章に向いていそうです。言葉を大切にしたい人、落ち着いて文章を読みたい人には合うんじゃないでしょうか。

あとはモバイル対応がまだのようなので質の高い iOS App が出たらおもしろくなっていきそうだなあと感じています。

Quora と同じで英語必須なメディアになりそうな気もしています。英語がんばろう、うん。

TOEIC Test

satsumaimoko — Thu, 24 Oct 2013 08:46:00 +0900

30 days challengeのエントリにも書いてましたが、9月に TOEIC Test を受けました。

30 days challenge は残念ながら頓挫したのですが TOEIC のスコアは無事目標達成しました。ちゃんと継続できていればもっと上のスコアも望めたのかなあと反省です。

次回は半年後の 3 月に受ける予定で、語彙を増やすために DUO 3.0 と WordEngine を腰を据えてやってみます。

他にやってみてること

開発環境を英語設定に (man や vim の :help など)
iOS や OSX を英語設定に
日常的に使う Web サービスを英語設定に
ソーシャルメディアの英語の比率をあげる

いつか Google の Voice Search や Apple の Siri など音声認識機能を英語で操れるようになりたい、というのが最終目標になってますが、まだまだ遠い道のりです。

MAKERS を読んだ

satsumaimoko — Sun, 01 Sep 2013 23:49:47 +0900

クリス・アンダーソンのMAKERSを読みました。

ざっくりした論旨としては製造業にも Web の方法論が入り込んできて変化が始まりつつある、というお話なのですが、個人的にも最近 Fancy や Kickstarter でニッチなハードウェアをチェックするのが趣味化しつつあったので頷けるところが多かったです。

夏休みにYMMFも行ったし、Switch のテクノロジー＋カルチャーネ申ラボ1ooも買ったりして、最近唐突にメイカーズムーブメントに興味津々な感じです。

少し熱量を蓄えたのでズブの素人らしく気負わず趣味の一つとして少しずつ手を拡げていこうかなあと考えております。

30 days challenge

satsumaimoko — Fri, 10 May 2013 02:30:00 +0900

職場で昼休みになぜか Matt Cutts の 30 days challenge の話になりました。たしか、毎日英語を勉強しようと思っても全然続けられない、とかそんな自分の実体験を話していてふと思い出したんですね。

30 days challenge について詳しくは TED Talks を観てもらえればわかります。とてもおもしろい話ですし三分強と短いので閲覧オススメです。

で、生活に小さな良い変化を加えるには 30 days challenge はおもしろそうな方法だと感じたので自分も始めてみようと決めました。

チャレンジを何にしようか迷ったのですが、福岡に来てからちょこちょこ取り組んでる英語学習関連にしてみます。

英語学習自体の当面の目標は今年9月受験の TOEIC で 600 点を取りたいと考えています（今は 550 点）。初めてのチャレンジは英語学習の目標のとっかかりということで、「DUO 3.0 の iTunes のトラック全て(330トラック)に英文を歌詞として加える」にしてみました。

「？」という感じなので、細かく説明すると、DUO 3.0 基礎編のリスニング教材で、5枚組の CD があるんです（いまどきCD5枚組て）。これをリッピングして iPhone に入れてスキマ時間に聞いてるんですが、聞き取れなかったときにいちいち書籍をたどるのがめんどくさいんですね。めんどくさいだけならまだしも、スキマ時間の学習だと、そもそも書籍を開けない状況の方が多い。そこで iPhone で確認できるように、書籍の英文を iTunes 上の対応するトラックに歌詞入力機能を使って全トラック分（約330トラック）を30日で入力していこう！、というのが今回のチャレンジです。

目標管理は 30 days challenge 専用サービスで MY30DC というのがあったので使ってみました。

このチャレンジが自分にとってお手軽なのか難しいのかわからないですが、習慣になったらおもしろいなと思ってます。とにもかくにも明日からスタート！です。

春吉とはしご酒と Radiohead

satsumaimoko — Tue, 05 Mar 2013 01:17:00 +0900

近所のカフェで自分の住む福岡の春吉エリアを紹介するフリーペーパー「春吉プロ本」を手に入れました。

住むまで知らなかったけど、春吉は狭い中にディープな個人店がひしめき合っている、はしご酒をするにはもってこいのエリア。このフリーペーパーにもそんな素敵な店がたくさん載っています。

監修はジャスマックホテルズ。春吉のシンボル的存在の日本初のデザイナーズホテル、イル・パラッツォを経営している会社です。

で、ここからが驚きの連続だったんですが、巻末にそのイル・パラッツォの歴史が載っていまして。

昔は地下がコンサートホールになっていて、BEASTIE BOYS, Radiohead, RAMONES など名だたるバンドがライブに訪れたとか。

ジョニー・ラモーンやトム・ヨークがこの春吉に来たのか、なんだか想像できないなあと色々調べていたら、トム本人が日本で一番思い出深い場所として、このホテルでの滞在を述べていたというブログエントリを発見しました。

Radiohead ファンなら知らない人は居ない、OK Computer の1曲目 “Airbag” の歌詞もこのホテルで書いたとか。

福岡に来て一年ちょっと経ちますけど、正直最も驚いた逸話でした。那珂川の揺らめくネオンサインがまたちょっと違って見えるようになりました（笑）。

なお、春吉プロ本はオンラインでも購読可能です。福岡に遊びに行く人（特に呑兵衛）はぜひ目を通しておくと良いフリーペーパーです。

参考リンク

Tumblr に移行

satsumaimoko — Fri, 22 Feb 2013 02:43:53 +0900

Posterous クローズということで、Tumblr に移行しました。

移行はJustMigrateであっという間に完了。Permalink が変わったり、FB Like が無かったりと少し変わってますが、特に対策してません。

全体的にすっきりしてますね、Tumblr は。

pyenv を導入してみた

satsumaimoko — Thu, 15 Nov 2012 14:27:00 +0900

pythonbrew が今後開発を停止するということで pyenv に移行してみたら、想像以上に Life Changing だったので久々にブログに書きます。

以下のような方に pyenv の導入はおすすめです。

rbenv のコマンド体系に慣れている
日常的に複数の python プロジェクトを横断する
screen, tmux のような Terminal Multiplexer を使っていて息を吸うように新しい shell を起動する

なぜおすすめかというと日常的に使っていた virtualenv の環境切り替えコマンドの workon が不要になったからなんですね。

これは pyenv の plugin である python-virtualenv のおかげです。 python-virtualenv がこれまで virtualenv が担っていた役割を pyenv に移譲し、pyenv の local サブコマンドを利用することで、workon が不要になりました。

一連の手順を以下にまとめます。

pyenv の導入

基本的には pyenv の installation と python-virtualenv の installation に従っただけです。

Python のインストール

まずベースになる python をインストールします。

pyenv install 2.7.3

python-virtualenv と pyenv local でプロジェクトごとに環境を固定する

続いてプロジェクト用の virtualenv を作成。さきほど作成した 2.7.3 を元に、環境を作ります。

pyenv virtualenv --distribute 2.7.3 envA
pyenv virtualenv --distribute 2.7.3 envB
pyenv virtualenv --distribute 2.7.3 envC

例として三つの環境を作ってみました。実際には各々の環境は pyenv 配下で管理されます。

$ pyenv versions
2.7.3
envA
envB
envC

pyenv local でそれぞれの Project Root 上に .pyenv-version を作る

cd projectA
pyenv local envA
cd ../projectB
pyenv local envB
cd ../projectC
pyenv local envC

以上で完了です。

これで projectA 以下では envA、projectB 以下では envB、projectC 以下では envC が使われるようになりました。 .zshrc に書いた virtualenv 関連の設定も ~/.virtualenv も不要です。

workon も mkvirtualenv も不要です。ということで自分は virtualenvwrapper も消してしまいました。さよなら workon。

pip uninstall virtualenvwrapper

まとめ

virtualenv の環境の切り替えでよく混乱してたので助かりました。

導入もしやすいですしインストールに python が不要なのも好印象です。

既に自分の中ではなくてはならないツールになりました。

データベース技術[実践]入門

satsumaimoko — Wed, 11 Apr 2012 00:40:36 +0900

最近また使い出した MySQL をもっときっちり使えるようになりたいなあ、ということで「Webエンジニアのためのデータベース技術[実践]入門」を手に取ってみました。

松信さんの本を初めて読みましたが、とても分かりやすいですね。他の著作も読みたくなりました。

本書はタイトルに「入門」と付いていますが、データベースを扱う人であれば読めば何かしら得られるモノがある本です。MySQL 使ってるなら尚更ですね。

データベース技術はもちろんですが、適切な技術を選択するためにどういう考え方をすべきか、という点でとても参考になりました。

本書には、大小さまざまな課題や疑問(と明快な回答)が出てきます。

データベース技術とは何か、それはどういった技術的課題を解決してくれるのか
RDBMS の各機能（インデックス、トランザクション、レプリケーション、パーティショニング）はそれぞれ何を解決するためにあるのか
SSD はどういった課題を解決するために適用すべきか
バックアップはなぜ必要か
NoSQL が台頭してきた背景は何か

こういった疑問は日々の仕事の中でおざなりになってしまうこともあります。一人の力量では疑問が解消できないことも多いです。そういった取りこぼしてしまいそうな知識を体系的に理解するきっかけになる本です。

ソースハッキングや大規模運用事例でのトラブルシューティングを通して、超一流の DBA である筆者の思考の流れを追体験できる点もおもしろいです。

運用トラブルは恐ろしいですが、運用トラブル時に何も出来ない人になるのはもっと恐ろしいですよね。そんなエンジニアにならないように基礎を抑えていきたいところです。

福岡に一ヶ月住んで感じたこと

satsumaimoko — Sat, 31 Mar 2012 15:57:00 +0900

早いもので福岡に引っ越して一ヶ月が経過しました。

まったく知らない土地に住むのは初めてのことなので、しばらく住んでみた印象をまとめます。

今回は住んでみて特に気に入った二点について書いてみます。

移動時間が短い
人のつながりが濃い

他にも色々あるのですが(ゴミ収集が夜とか)、また別の機会に。

移動時間が短い

自分は福岡市中央区といういわゆる都市部に住んでいますが、何をするにも便利です。福岡はコンパクトな都市を標榜していますが、その恩恵を最も受けられるエリアだと感じます。

例を挙げると、

天神のデパート群まで徒歩5-10分
Apple Store まで徒歩10分
ジュンク堂まで徒歩10分
野球場(ヤフードーム)までバスで15分
新幹線(博多駅)まで徒歩15分 (バス・電車で5分)
空港まで電車で10分
港までバスで10分 (そのまま釜山や近隣のリゾート地にも行ける)

といった感じです。

東京のような大都市では様々な施設が点在せざるを得ないため、上記の条件を満たすエリアはありませんよね。それぞれの施設は首都と同等の規模は望めませんが、全てがあるというのは便利さに直結してます。

自分は通勤時間もバスで20-30分と短く、通勤ラッシュとは無縁です(一ヶ月働いてまだ電車に二回しか乗ってません)。

この良い意味での街の「狭さ」は快適です。都会に住みたいけどちょっとした移動で乗り物に乗るのはちょっと、という自分の性格にあってます。

実際、Web 系企業が福岡に支社を作る理由の一つに「エンジニアのライフスタイルに合っている」というのがあるそうです。確かに適度に都会で適度に自然があり移動もラク、というのは少なくとも自分には合っています。

人のつながりが濃い

福岡のエンジニア・コミュニティはとても濃いし、活発です。自分の場合は Web 系のコミュニティしか知りませんが、そこに限った話ではなさそうです。

そして優秀なエンジニアさんもとても多いです。先日開催されたチューニンガソン Vol.3 では10位以内の半数が福岡会場だったようです。凄い!!

勉強会も多種多様にやってますし、どれも徒歩圏内でやっていて懇親会の事を考えるととても素敵です。

自分も三回ほど勉強会に参加してみました。

それぞれ勉強会のテーマはバラバラだったりするのですが、けっこう参加者が被りますw

また、知らない人同士でも名刺交換したり懇親会で話したりすると共通の知人が判明するということも頻繁にありました。

やはり街がコンパクトな点が関係してるのか、人付き合いも自然と濃密になりやすいようです。みんな近所に住んでると何かあっても集まりやすいし、ちょっと遅くなっても大丈夫だからなんでしょうかね。

もともと東京では下北沢近辺に住んでいて、その理由が人付き合いの濃さが生む居心地の良さにありました。そういう点では自分向きな土地だなあと感じています。福岡市中央区も都市部とはいえ航空法規制で高いビルがないし夜は屋台がたくさん出ていて、なんだかアットホームな雰囲気があります。

まとめ

自分が知ってる福岡=福岡市中央区、という感じなのでかなり偏りのある内容なのを断っておきますが、とても住みやすい街です。程良く都会で人付き合いもあり街のサイズが自分にはちょうど良い、というのがポイントなんだろうと思います。

ソフトウェア・エンジニアに優しい街、というのがまずは一ヶ月住んでみての感想です。

参考になる記事

実際に住む前にこちらの記事も参考にさせていただきました。

tmuxinator で Hyper Polyglot 時代に適応しよう

satsumaimoko — Mon, 26 Mar 2012 23:35:00 +0900

三月に入ってから Python を書いてます。

開発環境は相変わらずの tmux + zsh + vim のターミナル族です。 tmuxinator という tmux のセッション管理ツールを導入したら、なかなか快適になったので紹介します。

セッション管理って具体的に何をしてくれるのかというと tmux の window や pane の状態を yaml に設定することで、自分のお気に入りの window, pane のレイアウトに半自動で復元してくれる、という感じです。

ローカルでも tmux や screen を好む人は皆そうでしょうけど、window と pane の配置に拘りがあると思います(1番は各種ログ、2番は zsh と console、3番はエディタ、みたいな)。でも開発機はなんだかんだ頻繁に再起動せざるを得ない。これまでは毎度手動で「いつものレイアウト」を作っていたのが、tmuxinator を入れると半自動でレイアウトを組んでくれるようになるのですね。素晴らしい。

Django + VirtualEnv 環境の作り方はこちらのブログエントリを参考にしました。

欲を言うと以下もサポートすると素敵かなあ、とか感じました。

rbenv のサポート (rvm はサポートしてる)
pane ごとのコマンドの pre 実行のサポート (pane を開く毎に workon を自動実行させたい)
細かいレイアウトのサポート(今は微妙な調整は手動で行ってる)
現在のセッションの yaml へのエクスポート(よくばりすぎかw)

欲望の赴くままに色々書きましたが、最新版の v.0.5.0 の機能だけで十分にライフチェンジングです。

多言語で複数プロジェクトを兼務してるような、アタマの切り替えが大変な方には特にオススメです。 tmuxinator で Hyper Polyglot 時代も乗り越えていきましょう。

なお、screen 派の貴方には Screeninator というのがあるそうですよ。

退職しました

satsumaimoko — Tue, 21 Feb 2012 22:15:00 +0900

2月29日付で株式会社アイスタイルを退職します。現在は有給消化中です。

今後は家庭の事情で東京を離れて福岡で働くことを決めています。

人生のほとんどを杉並区と世田谷区で過ごした自分にとって福岡という地はまったくの新天地です。月並みですが不安と期待で胸いっぱいな感じです。当然ですが楽しんでいこうかと思ってます。

アイスタイルでは2年10ヶ月働きました。化粧品クチコミサイトのアットコスメを中心とした Web 企業ということで、これまでのキャリアの中でも経験のない華やかな時間だった、と感じています。

ティム・オライリーの “Data is next intel inside.” という言葉通り、アイスタイルの持つ「ビューティフル・データ」（真の意味でのビューティフル・データですねw）は今後より強力な武器となってくるものと感じます。会社の今後の発展を遠いような近いような九州の地から見守らせていただきます。

福岡行きを決意したのが去年の9月で、出発までの期間も短かかったこともあって直前まで色々バタバタしました（明日引越ですw）。快く送り出してくださった皆様ありがとうございました。感謝の一言です。本当に自分は幸せ者としか、それしか言えません。

3/1 からは新天地での業務になります。まずはさまざまな環境の変化を楽しんでいこうと考えています。

単なる個人の国内の引越とそれに伴う転職のお知らせと言えばそうなんですがw、少し丁寧に書いてみました。

今後は福岡のエンジニアライフやコミュニティについても、東京の事情も曲がりなりにも知る者としてブログにも書いていこうかな、と考えてます。

Path 2.0

satsumaimoko — Thu, 05 Jan 2012 00:28:36 +0900

Path の魅力

最近 Path をよく使っている。 UI と UX のよく練られたモバイルネイティブの Facebook、というのが第一印象だったけど、使い込むうちにこれは SNS じゃないな、画期的なサービスかもしれないな、と感じるようになってきた。

About に書いてあることを読めば、ブログにする必要もないのかもしれないけど、一応個人的な体験も踏まえて Path の良さを語ってみる。

デフォルト非公開の心地良さ

Path に上げた情報はデフォルトでは Public にならず友人同士でのみ共有される。更に共有された写真や動画は友人は保存できない(保存ダイアログが出せるけど保存できない。Android だとどうなんだろう？)。この安心感のおかげで Twitter や Facebook だとアップに躊躇していた顔入りの写真や動画も Path だと上げている。

情報共有できない心地良さ

Path は URL がリンクにならない。また入力がモバイルに限定されているので、ブラウザで見ていた情報を気軽に共有することも出来ない。つまり Web の情報を共有するツールとしては全く向いていない。

しかし、この制約のおかげで自分に関することだけを共有する姿勢が出てくる。結果的にノイズが減って親密な空間が生まれる。何より見ていて疲れにくい。

Public についての疑問

Path では Public という概念は他サービス連携という形で実現される。Thought を Twitter に連携したり 4sq で位置情報や写真を共有したり。

連携自体はなるべくサービスにある機能で実装しようという考えで作られている。例えば写真を Facebook 連携すると Facebook のアルバムにポストされたり、Thought を Twitter や Facebook で連携するとそれぞれ tweet や Status Update としてポストされる。4sq の写真にも対応している。この設計思想は Path 側が原則プライベートであることを考えると納得がいくのだけど、連携先のサービスに無い機能については path.com ドメインの URL で共有される。このページに関して一つ疑問がある。それは Seen(閲覧履歴) や Emotions も Public になってしまう点だ。プライバシーに気を使っている Path なのに本人の情報じゃない Seen や Emotions が Public になるのはなんだか片手落ちのように感じる。せめてログイン状態じゃない場合は表示してはいけない情報だと思う。なんでなんだろう。仕方ないので不本意だけど Twitter 連携はあまり利用しないようにしている(写真は pic.twitter.com、位置情報は位置情報付きツイートになってくれれば良いんだけど、それだと Path 自体が広まりにくくなるジレンマが)。

まとめ

Path は仲が良い友人、家族、恋人と一緒に使うことを前提としたサービスで、もはや大衆メディア化してる SNS や共有に使うには面倒なメールの中間にあたるサービス。ホント、ここまで家族に使ってもらいたいと感じたサービスは初めてかも。逆に従来の SNS のノリでフレンド申請しちゃうと共有できる写真や動画が制限される状況になって Path の良さに気付けないのかもしれない。