portal shit!

隔週木曜日にグルーヴノーツ社と会場を交代交代で Fukuoka.rb やってたんだけど、8/21 の回がたまたま Fukuoka.go と重なってしまって、Fukuoka.go は同僚でプラチナサーチャーでいけすかない有名な @monochromegane さんが主宰しててペパボ開催だったし、 Fukuoka.rb 重鎮の @nagachika さんが Fukuoka.go に参加登録してたので、どうせならということで Fukuoka.go と Fukuoka.rb 共催することになった。

なんか LT できるっぽい感じだったので大して技術力もないくせに LT させてもらった。他の人のハイレベルな話が続いた後に、本当に Lightening な感じですぐ終わるトークをやらせてもらった。新卒研修のときのスライドの内容をベースに gyowitter のご紹介をさせてもらった。

ただ社外の人も来る勉強会で話できたのは良い経験になった。もうちょっとネタよりから技術的にも意味がある内容の発表をできるようになりたいなぁ。

合同勉強会、普段見かけない人とかも来て良い感じなのでたまにできるといいなぁと思った。あと今回懇親会とか企画されてなかったので次は懇親会もあると良さそう。

日曜の朝に Mac を触っていたら突然 OS が落ちた。しょうがないのでスタートボタンを押して OS を起動させた。 OS 起動後、メッセージを見ようとするけど Messages.app 起動時にクラッシュして見られない。

一旦 iCloud アカウントからログアウトして再ログインしたらいけるかなと思ってログアウトして再度ログインを試みる。しかし各種設定をオンにしてもサーバーとの通信に失敗しているようで、 iCloud の利用ができない状態になってしまった。

同時にインターネットアカウント設定が出来ないことに気がつく。「インターネットアカウント を読み込めませんでした」というエラーが出る。

Apple Support Discussion で見かけた Unable to load iCloud and Internet...: Apple Support Communities を参考に ~/Library/Caches/com.apple.iCloudHelper を消して com.apple.iCloudHelper を kill してログアウト -> ログインを試すもダメ。 iCloud 関連で用いるファイルにロックがかかっている状況で OS が突然停止して iCloud 死んだぽかった。

英語の Apple Support Discussion の情報を一通り眺めて試してみたけど Messages.app とインターネットアカウント設定は復活せず、あきらめて TimeMachine のバックアップデータから復元することにした。 33 時間かかって復元は終わった。 Messages.app は無事起動するようになったが万事元通りとはならず、アドビ系のソフトが全滅した。

まえ MacBook の HDD を SSD に変えたときに TimeMachine のバックアップから復元したら同じように Adobe CS4 のライセンシングが機能しなくなって Photoshop とか使えなくなった。前回はハードドライブが変わったからそうなったのかと思っていて、同じ SSD に復元するのであればこういうことは起こらないのではないかと勝手な期待を抱いて復元してみたら、案の定ライセンシングが機能しなくて起動しなくなった。

前回はディスクケースに取り出した古い HDD を入れてディスクから Mac を起動してアドビ系のライセンス認証を解除して回ることで Photoshop とか起動できるようになった。今回はディスクの換装ではないので古いドライブが存在しているわけではなく消去して上書きインストールされているので、旧データの OS を起動してライセンス認証を解除するということもできない。 Adobe が CS4 向けに提供しているライセンス修復ツールは PowerPC アプリケーションというクソっぷりで、 Intel CPU の Mavericks で起動するわけもなく。どうせ Adobe のサポートとかに電話しても Mavericks で CS4 の動作は保証しておりませんとか言われるだけだろう。つらい。

Adobe のソフト、基本的に異常な操作感だし使いたくないけど、印刷屋に年賀状とかのデータを送るときにどうしても使わないといけないのがだるい。国はアドビ対策基本法とか制定してアドビ倒産に追い込んで欲しい。

TimeMachine のバックアップから復元するときはご面倒さまでも Adobe ソフトのライセンス認証を解除してから行われることをおすすめします。最近の Creative Suite ではこういうことおこんないのかな。マジでクソい。

追記（2014/05/08）

昨夜、一旦ソフトをアンインストールして入れ直したら Photoshop とか使えるようになった。ライセンシングが機能しなくなったらインストールし直せば何とかなるようです。ディスクが何枚にも分かれてるので時間かかるけどな。

D90 のキットレンズだった AF-S DX VR Zoom-Nikkor 18-200mm f/3.5-5.6G IF-ED が1年半くらい前からズームしたときに遠くのものにピントが合わなくなっていた。（近くのものにはピント合う）

イージス艦、マジでピント合わない。ステルス機能か何かなのかな。

— ケツがオワコン氏 (@morygonzalez) August 13, 2012

最初はそういう仕様だったかなぁと思いながら（ピントが合わないのは遠くのものだけなので）、単焦点レンズしか使わなかったのであまり気にしていなかったのだけど、ネットで検索したら同じ症状の人が何人かいて、どうやら故障しているらしいということが分かった。

kakaku.com の掲示板で、「 Nikon のサービスセンターに持っていったら玉を固定してるねじを締めてもらうだけで直り無料だった」と書いてる人がいたので、無料で直るかなと思って Nikon のサービスセンターに持っていったら「36,000円です」と冷酷に告げられてしまった。型落ちで中古でも4万くらいで買えるレンズの修理に36,000円も払うのはあり得ないと思ったので修理は頼まなかった。

合理的な価格で修理をやってくれるカメラ店とかないかと思って検索してたらゼネラルカメラサービスという会社が福岡にあることが分かったので持っていってみた。

10,500円で直るとのことだったので直してもらうことにした。今日受け取ってきたけど遠くのものもちゃんと撮れるようになってた。

レンズとかカメラとか壊れたときにメーカーに修理頼んで高額な見積もり来て困ったら、こういう修理屋さんを探してみると良いと思った。あと恐らく修理頼んだとこはヨドバシとかキタムラからの修理依頼も受けてて、量販店に頼むと量販店の取次料とかがかかるっぽいので、行ける範囲にこの手の修理会社ある人は直接そこに持って行ってみると良いと思った。以上、個人の日記でした。

この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。

---

2011 年の 10 月から FANIC という音楽配信サービスの開発に携わっていたのだけど、サービスを成長させることができず、 2013 年の 8 月にサービス終了した。

サービスが死ぬのは技術者がクソだということだけではないと思う。市場とか外部環境に左右されるし、企画とか売り方がダメなことの方が多いと思う。しかし現実に自分はプログラマーとして FANIC というサービスの死に荷担してしまった。弔いになるか分からないけど、 FANIC で何がよくて何が良くなかったのかを書いてみたいと思う。

FANIC とは

FANIC は主にアマチュアのミュージシャンをターゲットにしたホームページ作成＆音楽販売サービスで、アーティストは自分の公式ホームページを簡単に作ることができ、楽曲をアップロードして試聴公開したり、リスナーに販売することが出来た。月額利用料は 315 円で、曲が売れたときに手数料 15.75 % が従量課金される仕組みだった。 2012 年の 1 月に公開して、 2013 年の 8 月 31 日にサービス終了した。

FANIC に携わることになった経緯

ペ社に入社したのは 2 年前の 10 月だった。前の職場がどうしようもないブラック企業だったことは前に書いた。

会社の開発環境が地獄のレガシー環境だったので面談で社長に Subversion やめて Git 使いたいと言ったら、「会社が気に入らないならさっさと辞めろ」と言われたので、何とか反省して心を入れ替えたふりをしながら職探しをしていたところ、 Rails 、 Node.js 、 Redis 、 MongoDB 、 Nginx 、 AWS みたいな福岡の求人にしては珍しくナウいキーワードで募集していたのがペ社の Dazaifu Project だった。

プロジェクトの紹介ページが何となく面白そうだったのと Rails で仕事できそうだったので応募した。小さなチーム、大きな仕事を読んだり、RubyKaigi 2010 に行ったこともあって、DHH や RubyKaigi で登壇していた人達みたいにとにかく Ruby で仕事したいという思いが強かった。前の職場でも Ruby を使いたかったけど ColdFusion や Flex など旬を終えたプロプライエタリなテクノロジーばかりを触らないといけなくてとにかくつらく、わらをもすがる思いで求人応募フォームを送信した。

8 月に応募して 9 月に内定が出て 1 ヶ月後にペ社に入社した。入社するまで配属先を知らなかったんだけど、 Dazaifu Project の物販系と音楽系の二つのサービスのうち音楽系の方に配属されることになった。それが FANIC だった。

FANIC で良かったこと

一つのプロジェクトに集中できる

受託の会社とかだと受託案件があって、案件ごとにメンバーがアサインされるから同時並行的に二つか三つを掛け持ちで担当するということがあるけど、自社サービスの会社では基本的に一つのサービス（案件）にかかりっきりで仕事をすることができた。これがとても良かった。午前中に A 社の対応をして午後から B 社、夕方からまた A 社のタスクに取りかかって 20 時から終電まで C 社対応、みたいな複数の仕事の切り換えがない。タスクの切り換えにはオーバーヘッドが発生するから、一つのことにかかりきりになれる自社サービスの仕事はとてもやりやすかった。加えてプログラミング言語はずっとやりたいと希望していた Ruby だったので言うことなしだった。会社に行くのが楽しかった。

ナウでヤングなアーキテクチャー

求人に上に書いたようなナウいキーワードを混ぜていたのは先輩の @linyows さんで、FANIC はインフラは AWS を利用し、データベースに MongoDB 、音楽や画像は S3 に保存して、WAV や AIFF でアップロードされた音楽ファイルを試聴用の MP3 に変換するバッチ処理や、画像を S3 から取り出すリアルタイムリサイズサーバーは Node.js で実装してあった。フロントエンドのアプリケーションは Rails で構築されていて、自分は主に顧客管理とか決済部分なんかを開発した。

ペ社では通常、インフラを担当する専任のチームがサーバーの面倒を見る。しかし Dazaifu Project はスモールスタートを掲げていたので、インフラも @linyows さんが一人で構築していた。今自分が配属されているサービスは結構でかくて、サーバー管理はインフラチームが担当し基本的に自分たちで設定を変えたりサーバーを構築したりすることはない。ちょっと Nginx の設定を書き換えるのにも申請書出してハンコリレーしたりしないといけない。おかげで凡ミスで 500 エラーみたいなことにはなりにくい仕組みになってるんだけど、リリースのスピードを上げにくい。そういう状況からすると、 FANIC でミドルウェアのバージョンを上げるのなんかも部署間の調整が必要なくさくっと出来たのはとても良かった。加えてデータベースが MongoDB だったため、データ構造の変更が柔軟に出来たのも良かった。

社内でいち早く CoffeeScript 使ってみたほか、ペアプログラミングもやってみた。かなり疲れるけど集中して取り組めるし、プログラマー間で仕様を共有できるのでこれは良いものだと思った。 FANIC のおかげでずいぶん成長させてもらったと思っている。

FANIC でつらかったこと

FANIC ですべてが良い方向に向かっていたかと言えば、決してそうではなかった。技術的にもプロジェクト運営的にも、苦しい部分が多々あった。

MongoDB で金の計算

技術的にはまず MongoDB で金の計算をするのがつらかった。

決済部分の開発で MongoDB の Embedded Document でかなり苦しめられた。契約 Collection の中に Embedded Document として請求と入金があるという構造だったけど、契約日と入金日が月をまたいでいて、一つの契約 Document 内にある Embedded Document をそれぞれ別の月の入金と請求とする必要があり、かなり苦しい感じだった。前受金の概念とかも Document 指向のデータベースで対処するのは地獄的な感じがした。Document の中に何でもスポスポーと Embedded Document を突っ込んでいけるのは便利なんだけど、親 Document と Embeded Documet を別の文脈で使おうとするときに困難が生じると思った。

MongoDB を大規模に利用している CA 社も JOIN ができないので金関係だけは MySQL でやっているという話を聞いたことがある。金の計算をするときに JOIN の代わりに Map Reduce する必要があったけど、自分が開発に利用していた頃の Mongoid （MongoDB 用の ActiveRecord 的なやつ）は Map Reduce に対応しておらず、 Rails のモデル内に Map Reduce 用のクエリ（MongoDB のクエリは JavaScript で書かないといけないので Rails のモデル内にヒアドキュメントで JS が書いてあるという地獄っぽい感じになる）を書いたりした。Map Reduce しないのであれば二重 Loop でグルグル処理を回さなければならず、毎度これを Ruby にやらせるのはパフォーマンス的にしんどかった。総じて MongoDB は大量のデータを集計したりするのには向いてないかなーという印象を持った。それぞれを独立したドキュメントとして利用する機会が多いタイプのアプリケーションには向いてる気がする。設定情報の保存とかブログ記事の保存とか。金系のデータが沢山入っていてそれを月ごとに集計してどうのこうのとかやるときがつらい。

Mongoid のため便利 gem が使えない

Rails エコシステムの中で MongoDB は少数派だから、様々な便利 gem が ActiveRecord に依存していて使えないことがあったのも困った。たとえば ActiveAdmin が ActiveRecord に依存しているために利用することができず、顧客管理を一から実装しなければならなかった。なければ作る or Pull Request 出して取り込ませる、というようなマッチョマンじゃないと Rails でレールから外れるのは厳しいと感じた。

リーンスタートアップできていなかった

プロジェクト運営的には、チームの目標とか優先順序の付け方とかがハッキリせず、行き当たりばったりな開発・運用になっていたのがつらかった。

2012 年の春、『リーンスタートアップ』が流行ってた。みんな本買って読んでて、社内で antipop さんによる講義とかもあった。でもリーンスタートアップは本当に難しくて、誰でもリーンスタートアップ読めば新規事業で成功できるわけではないと思う。サービスの企画立案者が有能なだけでは不十分で、起業家に加えて、極めて優れたエンジニアが付帯していないと厳しいと思う。自分たちに必要だったのはリーンスタートアップを読むことではなかった気がする。全然そのレベルに到達していないという感じだった。

思い込み・お問い合わせベース開発

リーンスタートアップには、仮説の検証をものすごい速度で行ってフィードバックループを回さないといけないと書いてあるけど、そもそも自分たちには仮説の検証方法が存在していなかった。本に書いてあるとおりに様々な仮説を素早く検証していくには、企画担当者がやりたいと思ったことを一週間くらいで実装して次々に仮説を検証していかないといけない。A/B テストをやるにしても、A/B テストをやるための仕組み作りが大変だと思う。オープンソースで使えるものに Cookpad の Chanko とかあるけど、 MongoDB がネックになって利用できなかった。自分たちでそういう仕組みを作るにはかなり多くの時間を作らなければならなかったと思う。結局思いつきやお客さんからのお問い合わせベースで開発する機能が決定されて実装されていった。お問い合わせが結構あったから 1 ヶ月以上かけて実装してみたのに全く使われない機能とか、これは絶対に行けるはずと自分が思い込みで提案して実装したのに全く使われない機能とかあって、全然良くなかった。

ちなみに↓のスライドではてなブログのリーンな開発風景が紹介されてるけど、情報収集のところで紹介されてる手法を真似しようとするとかなり大変だと思う。雑魚いエンジニアしかいないとここまでやるのは難しい。

技術的に正しいことをしようとこだわりすぎて中途半端になっていた

入社した頃、テストを書くという習慣がプロジェクトになかった。プロジェクトに加入した初期の頃から自分はなるべくテストを書こうとしていて、テストを書く習慣を定着させたつもりだったけど、これも良かったのか悪かったのか分からない。テストを書くとどうしても時間がかかってしまう。 TDD BootCamp Fukuoka Vol.2 できしだなおきさんが言っていたんだけど、テストコードがあるとプロダクトコードのメンテナンスに加えてテストコードのメンテナンスも必要になる。そうすると俊敏に動くということが難しくなる。自分はテストを書くことに時間をかけすぎてしまってサービス開発のスピードを鈍らせていたような気がする。

テストを書いたりリファクタリングをしたりしないのは正しい行いではないと思うけど、会社に雇われて給料をもらっている以上、サービスを成長させることがエンジニア云々以前にサラリーマンとして大事だと思う（『情熱プログラマー』とかにも書いてある）。特にプロジェクトの最初の段階では、技術的な理想を追求するよりも、不完全でも良いのではやく製品を投入して一つでも多くの仮説を検証して学びを得ることの方が重要なのではないかと思った（Minimum Viable Product）。

自分のプロダクト感を持てていなかった

サービスに対して、「自分たちのプロダクトだ」という感覚が希薄だったと思う。そもそも hitode909 さんのスライドみたいにドッグフード食べてなかった。自分の FANIC 上のページは検証用に作ったインターネット上のゴミみたいなページだった。

みんなビラ配りとかオフィス外での宣伝活動とかに消極的だったし、このプロジェクトがぽしゃったら失職する、みたいな危機感が希薄だった。自分は机に座ってプログラミングできればそれでいいみたいな感じがあった。口ばっかりで手が動いてなかった感がある。

地元の野外フェスとかに行ってビラ配るとかオフラインでの宣伝が必要だったのかもと思う。終わるって決まったとき、やりきった感がなかった。これでうまくいかないなら仕方がない、と思えるところまでやれてなかった。

エンジニアであってもプロジェクトの当事者意識を強く持たなければならないのだと思う。いまいくら自分たちが稼いでいて、あといくら稼ぐと黒字になるのかとか、どのくらいのスピードで成長していかなければならないのかとか。

チームの雰囲気が良くなかった

一番の苦しかったのはこれだと思う。

いま思い返してみると、 1 年半の間でチームのメンバーが揃って食事をしたのは 1 回くらいしかなかった。お互いへの理解が欠如していたような気がする。雰囲気悪かったからサービスが崩壊したのか、サービスがうまくいっていないからギスギスした感じになったのかは分からない。ただ、雰囲気の良くないチームが作る製品が良いものになることは基本的にないと思う。

FANIC を離れたあとも、会社を挙げて永和システムマネジメント社の講習を受けてスクラムに取り組んだりしてる。しかし結局どんなプラクティスを導入しようとも、チーム内でコミュニケーションが取れていないと技術的に見過ごすことの出来ない問題に気づけず非常に大きな手戻りが発生したり、仕様上の大どんでん返しがやってきたりする。技術的に足りない部分があったとしても、コミュニケーションが機能していたらカバーできたのではないかと思う。

結論

結論としてはチームで寿司を食べたりするしかないと思う。銀しゃりのまばゆい輝きが、うにやいくらの神々しい光が、鋭利な刃物のように光るサバのにぎりが、闇を照らしてくれる。

---

この記事は闇 Advent Calendar 2013 - Adventar 22 日目の記事でした。 23 日目は hurutoriya さんで、今日の担当は @udzura さんです。

寿司はうまい。寿司はうまいので寿司と結婚したいと思う人もいることでしょう。しかし寿司は人間ではないので結婚できない。結果的に寿司屋の娘と結婚することになります。

寿司好きなあなたは、寿司であれば何でも食べたいと思う。だから回転寿司だって、午後8時のスーパーの総菜売り場で半額になっている寿司だって好きなはずです。しかし、寿司屋の娘と結婚したばかりにそういった Guilty Pleasure は御法度となります。

「ああいうの食べるなんて頭どうかしてる」

寿司屋の娘はあなたにそう言います。寿司のことが好きすぎて、でも寿司とは結婚できないから寿司屋の娘と結婚したのに、安い寿司が食べられなくなったことでかえってあなたの生涯寿司数は低下するのです。寿司との距離、これがこの文章のテーマです。

---

24歳のときに病気になってしまった僕は、入院して治療を始める前、生ものが食べられなくなるからと寿司屋で寿司を食べました。治療の合間に一時帰宅が許されると回転寿司に行って吐くまで寿司を食べたりしました。寿司を食べ過ぎて吐くことで自分の生存を確認していたのかも知れません。

病気を克服した僕は、普通の寿司好きと同じように就職して社会生活を営むようになりました。週に二日休みがあれば、そのうち一日は祖母を連れて回転寿司に行くのは独身男性として当然のことだと思います。寿司を空気のようにすら感じていました。

寿司にもっと近づきたい -- 20代の僕はその欲求を抑えることができませんでした。実家を出て、寿司屋の娘と結婚することにしたのです。しかしこのときの僕は、好きなときに自由自在に寿司が食べられることのありがたみを分かっていませんでした。

寿司屋の娘との結婚が僕にもたらしたのは、寿司との離別でした。寿司と僕はもう二度と交わることもない別々の人生を歩むことになったのです。寿司屋の娘と結婚するとはそういうことなのです。僕は寿司に近づきすぎたのです。

僕は今日、福岡の高寅という寿司屋で以下の寿司を頼みましたが、大トロは寿司屋の娘であるところの妻に食べられました。

代わりに僕は以下の赤身を食べさせられました。

おわかり頂けたでしょうか。寿司屋の娘と結婚するとはこういうことなのです。

あなたが本当に寿司のことを愛しているのならば、寿司には近づきすぎない方が良い。寿司とは適切な距離を保つべきなのです。

---

この記事は 寿司 Advent Calendar 2013 - Adventar の 9 日目でした。明日は watilde さんです。

技術のことを書いてたブログ（ tech.portalshit.net ）を Amazon S3 で公開するようにした。9月くらいまでは EC2 の micro に置いてたんだけど EC2 micro でも高くて家族の理解を得られなくて terminate したので表示できなくなっていた。

やり方は以下の Qiita の記事を参考にした。jekyll-s3 という gem 入れればよかった。簡単だった。

手順ミスって US リージョンで公開することになったけど遅さとか感じないのでこれで良いかなと思う。

Jekyll 、なんか Liquid みたいな特殊なテンプレートエンジンだし、 Lokka の方が Rack アプリケーションの勉強になるし自分でつくった Syntax Highlighter 気に入ってるのでプログラミングっぽいこともここに書くようになってしまった。しかしそのうち気が変わってまたあっちに書き始めるかも知れないのでとりあえず公開できる状態にしておく。ちなみに tech.portalshit.net は最初、今はなき Mephisto という Rails 製のブログツールで構築してて、デザインは Mephisto 用のものを Jekyll に自分で移植して使ってる。

関連してそうな記事

• パソコンの話とかは tech.portalshit.net に書きます

Reeder for Mac の新しいの出ないので ReadKit というの買ったらイノベーティブだった。RSS リーダーとしてだけではなく、Pinboard のブックマークとか Instapaper とか Pocket のやつも読めてこれまでの RSS リーダーとはひと味違う。これだけでフィードの購読、過去読んだ記事の検索までできるので最高だと思う。Google Reader 死んでからインターネットつまらないと思ってたけどこれでまたインターネット楽しくなりそうな感じする。