プログラマーの種類、いろいろあると思う。

  1. ハッカー
    プログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。
  2. OSS プログラマー
    1 と似てるけど、 OSS が楽しくてコードを書いてる人。カンファレンスで登壇したり、技術ブログを熱心に書いたりする。
  3. プロダクト指向プログラマー
    開発だけでなく事業の方向性にも口を出したい人。社長が死んだらいつだって代替ができる、というような気概の人。
  4. サラリーマンプログラマー
    プログラミングは仕事のためと割り切っていて、余暇には一切コードを書かない人。

1 〜 4 のどれか一つに綺麗に分類できるというものではなく、 1 かつ 3 とか、 3 かつ 4 とか、複数にまたがる人もいる。

職業プログラマーになりたての頃、サラリーマンプログラマーしかいない環境で働いて早くそこを抜け出したいと思っていた。プログラマーは会社の最下層で、プロジェクトマネージャーや営業が偉かった。プログラマーの人たちは仕事のために仕方なくプログラミングしてた。

それが嫌で余暇でもコード書くような人たちがいる職場に移ったけど、そこではハッカーや OSS プログラマーがよいプログラマーの代表とされていた(と思う)。自分もそういうのを目指し OSS カンファレンスに登壇したり技術的に中身のあるブログ記事を書いたりしたいと思ったけど、なかなかよいコードは書けないし、結婚して所帯を持つと町内会の草むしりや廃品回収、町内の運動会のテント設営、審判にかり出され、またあるときは子どもの幼稚園に夫婦そろって呼び出されて「お前らは夫婦そろって人間の屑以下だ、心を入れ替えるか幼稚園を辞めるかどっちか選べ」と説教されるなど多忙を極め、勉強会で話したりブログ記事を書いたりということが難しくなった。

一時期は自分は凡人プログラマーなんだろうなぁ、かつて忌み嫌っていたサラリーマンプログラマーと同じなのかなぁ、と将来を悲観していた。この頃は技術的な伸びしろがなくなって学ぶことに対する意欲が失せてしまっていた。

ただ、仕事で失敗プロジェクトを担当してつらい目に遭うことが多く、チームで仕事することだとか、失敗からどう学ぶかとか、その手のことに関してはそこそこ知見が貯まっていった。どうすればチーム開発はうまくいくのか、どういう風に情報を共有すればいいのかなどなど。業務改善のためにちょっとしたスクリプト書いたり、ぶっ壊れて動かなくなってる hubot スクリプトを直したり、 CI のセットアップを頑張ったりと、エンジニアチーム全体の生産性を上げるような落ち穂拾い業務みたいなタスクも好きだった。

いまは自分はチーム開発プログラマーなんだろうなぁと思う。ハッカー気質は皆無じゃないけどそこそこ、 OSS へのコントリビュートも気が向いたときに、プロダクトのことを気にする気持ちもある。どれも中途半端で単独では生産性高くないけどチームで仕事をするときに効能を発揮するタイプ。こんな風に自分が適している役割が分かると仕事がやりやすくなるし、目指すべき方向性のようなものが明確になって将来のことを考える上でも役に立つ。

ベンチャー企業で働く場合は自分のマインドやスキルセットが会社のステージにフィットすることも大事だと思う。もともとはベンチャー企業でも成功して上場しているような会社だとデプロイ時にハンコリレーなどがあってやるべきことをやるべきときにババッとやるのが難しい。そういうのは自分には向いてない。一方で起業したばかりの小さなスタートアップも、自分のような最初から綺麗なコードを書こうとするプログラマーはきっとフィットしない。起業したばかりのスタートアップでは自分たちの事業が社会から求められるかどうか不透明なので、そんな状態でテストがどうだとか CI がどうだとかチーム体制がどうだとかを言うようなプログラマーは必要ない。汚くてもクソコードでもテストコードなんて存在しなくてもいいからとにかく金を生み出すコードを素早く書ける人が向いている。

その意味でいまいる会社は創業当初の価値仮説の検証は済んでいて、これからいかに事業を伸ばしていくかというステージに入っているので、ちゃんとテストを書いたり、 CI を導入して継続的インテグレーションに努めたり、デプロイをいい感じにしたり、情報共有ツールを導入したり、開発チームの組織体制を云々したりといった部分で価値を発揮しやすい。

一握りの本当に優秀なソフトウェアエンジニアってのは受託会社だろうが事業会社だろうがベンチャーだろうが大企業だろうがどこにいたって価値を発揮できるのかもしれない。しかし自分のようなすべてにおいて中途半端なプログラマーは、自分に何ができるのかを理解し自分を必要とする規模とステージの会社を見つけてそこの門を叩くのがよいと思う。もちろん、事業に共感できるとか、チームメンバーとの相性も大事だけど、事業に共感できてもチームのメンバーがいい人ばかりでも、会社の規模やステージが自分を必要としなければ価値を発揮することは難しい。

ECS 化していたブログをさくら VPS に戻した。理由としてはお金が高かった。普段、 S3 と Route 53 に払ってる金額の 20 倍くらいの金額になって少ない小遣いでは払えないと思ったので VPS に戻した。ただ AWS で運用して勉強になった点もあった。

まず ECS での運用について知見が得られたのがよかった。 deploy するためには docker builddocker push が必要で、最初はちょっとした修正のためこれやるのは大げさだと思ったが、慣れればそんなでもなかった。ただイメージのビルドをどこでやるかは考えといた方がよさげ。自宅だと高速な光回線があるからよいけど、実家やどこか旅行に行ったときに image をビルドして ECR にプッシュするのはつらい。 GitHub に git push する度に CircleCI でビルドされるような体制を構築する必要があると思った。

CloudFront をウェブアプリケーションの前段に挟む、というのもやってみたけどこれもよかった。 Rails なら Asset Precompile によって静的なファイルへのリクエストはウェブアプリケーションまで届かないようにするのを良くやると思うけど、 Lokka は Sass や CoffeeScript を動的にコンパイルしてクライアントに返すので、 CSS や JS などへのリクエストにも puma のプロセスが消費されてエコではなかった。 VPS 運用時には Nginx を前段に入れて、画像やコンパイル済みの JS / CSS ファイルへのリクエストは puma にプロキシせず直接返していたが、 ECS 化したときに Nginx を挟まなくなったので CloudFront を入れて画像や JS / CSS へのリクエストをキャッシュするようにしてみた。

cloudfront-ecs-image.png

すると puma の負荷が低下し、 New Relic の Appdex が 0.95 前後だったのが 0.99 になった。 ECS で利用していた EC2 コンテナは t2.micro でしょぼいのでサーバーのスペックアップで改善されたわけではない。ということで VPS に戻すときにも Nginx の proxy_cache を使って Sass や CoffeeScript から動的にコンパイルされる CSS / JS をキャッシュするようにしてみた。さすがに CDN のような配信の最適化は実現できないが、以前よりかはかなりましになるはず。

なおセッションを有効にした Rack アプリで Sass や CoffeeScript を動的にコンパイルすると Set-Cookie ヘッダーがセットされてしまう。 Nginx の proxy_cacheSet-Cookie ヘッダーがセットされてるとキャッシュをしないので、

proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;

などとしてやる必要がある。

今後仕事でも ECS 化を行う予定があるので得られた知見を有効活用していきたい。

castro-and-overcast.png

Podcast を聞くのには Marco Arment の Overcast を使ってたんだけど、最近「 Internet Connection を確認しろ」みたいなメッセージが出てエピソードの一覧を取得できないことが何度かあってストレスに感じたので Castro に変えてみた。 Overcast は独自のサーバーサイドアプリケーションがあってそこと通信してるので、 overcast.fm の調子が悪くなると新しいエピソードをダウンロードできなくなる。 Castro や Apple の Podcast アプリだと iTunes から直接ダウンロードしてるので iTunes のサーバーがダウンしない限りエピソード一覧を取得できないということは起こらない。

エピソードの再生クオリティに関してはやはり Overcast の方がすばらしい。無音部分のカットや賢い倍速再生はやはり Overcast ならではだと思う。 Castro で再生してみて無音部分は結構気になることに気がついた。

一方でエピソード一覧の UI などは Castro が優れていると思った。以前聞いたエピソードを聞き返したいとき、 Castro は年月でエピソードがグルーピングされるので心理的に探しやすい。

castro

Overcast の方は雑然とエピソードが羅列されているだけなので探しづらい。

overcast

プレイリスト

castro

Castro はプレイリスト機能が前面に出ていて、基本的にリストに聞きたいエピソードを登録して聞くというスタイルになる。次に聞くエピソード、過去に聞いたエピソードのヒストリー機能もあるので、昨日聞いたあれをもう一度聞きたいというときにも便利。 Overcast にもプレイリストはあるが存在に気がつきづらい。次々に新着のエピソードを聞いていくという使い方には向いてるが、過去のエピソードを掘り出して聞くときには Castro の方が優れている。

再生中画面

再生中の画面に関しては Overcast の方が良い。カバーアートをスワイプするとショーノートとチャプター一覧を行き来できるのも便利。

overcast overcast

Castro はショーノートと再生位置の切り替えは▽のトグル式で、しかも再生位置確認画面は SoundCloud のように波形表示される。

castro castro

正直こんなのは必要ない。僕は興味のない話題はスキップするので Overcast で聞いているときはショーノートを見ながら再生位置スライダーを動かしてスキップしたりするが、 Castro ではショーノートを表示している状態では再生位置スライダーが表示されないので 30 秒早送りボタンを連打するしかない。

結論

再生中の画面の UI には問題があるが、全体的なルックアンドフィールは Castro の方が優れていると感じた。配色を含めたデザインは Castro の方が使いたいと思わせられる。ちゃんとデザイナーによってデザインされている感じ。 Overcast の方はエンジニアが片手間でデザインした感がぬぐえない。

Overcast に不満がある人、過去エピソードをよく聞く人は Castro を試してみるといいと思う。