(株)ウサギィを退職してフリーランスになった話

実はこれが初「で、お前だれよ?」エントリです。
最初の転職の時は、書くと愚痴と怒りしか出てこなさそうだったので書かなかったw


およそ3年半ぶり二度目の転職、というか初の失職です。会社員を辞めてフリーランスになりました。
実は、年末の時点で退職を考えてたんですが、ちょっとタイミングが微妙に噛み合わなかったんで、1月から3月までの間は週に半分フリーランスという形で仕事してました。
で、4月から本格的に退職して完全にフリーランスです。
ITゼネコンの頂点みたいな会社に心疲れて2年半ちょっとで転職したので、もうプログラマーになってからの方が長いのかーと思うと感慨深いですね。
プログラマーとしても4年目に突入して、いよいよ中堅というかおっさん界の中でも中ぐらいのおっさんになってきた感じです。


今回会社を辞めたのは別に仕事に不満があったわけではないです。流石に完全にゼロでもないですがw
基本的には受託開発という形で仕事してたんですが、非常に自由にゆるくやらせてもらえたし、技術的な裁量に関してもかなり自由が効いたので、結構貴重な環境で仕事ができたと思います。
受託開発という都合上、あんまり何作ってたか明確に話せないのが残念な所ですが、結構しっかりしたRailsアプリケーションのサーバーサイドをほぼ一人で設計から実装までやれた事で大分成長できたと思っています。
最後にやってた仕事は小規模ながら納期がタイトで割と色々な事をやらなければならないプロジェクトだったんですが、それなりにいい仕事をしたんじゃないかなーと自分で思ってたり。


辞めた理由は、今は無策で飛び出してもそこそこ仕事が貰えそうな感じがするけど、この先どうなるか分からんから、というのが一番の理由です。
そもそも自分の経験やキャリアが大分偏ってることもあって、内心不安が無いわけではない日々を過ごしてました。
仕事上の不満ってのはその辺にあって、対等な相談相手が居ないって事が大きかった。
自分一人で我武者羅により良い方向を模索し続けるにも限界があるように感じていて、このまま日々が続いていくと、いつか世の中に着いていけなくなるんじゃないかと思い始めてました。
非常にかいつまんで言うと、刺激が無いとダレるってやつですw
それに会社自体が零細企業なこともあって、自分が困るようなタイミングでいきなり飯の種が無くなる可能性も結構あるし、それは結構怖い。
幸いなことにRubyRailsで立て続けに本を書かせてもらって、Qiitaに何か書いたりどっかでちょこちょこ話したりという活動を続けてきたおかげで、そこそこ名前と得意分野を知ってもらえるような感じになってきたので、だったら困る前に辞めてまえー!って感じで退職することにしました。
まあ、その分期待値も上がってるんで、仕事もしっかりやっていかんとあかんわけですが……。
しかし、思えば遠くへ来たもんだというやつで、誰も自分の事を知らない所でエクセルとパワポばっか書いてた所からスタートして、今はRubyやってる人の内では「おー、あの人かー」ぐらいに伝わるようになったのは、とても嬉しく思っています。
うん、結構頑張ったよね、俺。


何でフリーランスかというと、正直そんなにやりたい事があって辞めるわけじゃないからです。
どちらかというと、バリバリサービス開発やってたり優れたエンジニアとチームで仕事ができる現場で経験を積みたいという思いの方が強く、一箇所に留まってそこに尽力し続けるよりも身軽なフリーランスという形を取ることにしました。
とはいえ、一度に複数箇所から仕事受けると自分の性格上結構きついという事が分かったので、できるだけ一箇所づつから仕事受けるようにしたいとは思ってます。


とりあえず直近はどうするかというと、4月からしばらくはクラウドワークスに常駐します。
期間は明確には決めてないですが、少なくとも3ヶ月〜半年ぐらいまで。
Shibuya.rbのRubyKajaに選ばれたこともあったんですが、渋谷で働くの初めてなので、渋谷近辺の皆様、よろしくお願いいたします。
とりあえずグリフォン行きましょう。若しくは飯の美味い所を教えてください。


何でクラウドワークスで働くのかというと、大体以下の様な理由になります

  • サービス開発メインでやった事無かったのでやってみたかった
  • あんまり大きくない会社の方が好き
  • 一緒に働いてみたい人が居た
  • ゲームやエンタメを提供する系より業務っぽい方が好き

まあこんな感じですが、実際の所あんまり深く考えてません。なんとなくですw


これからずっとフリーランスでいく、とかそんな事は全然考えてないですが、とりあえず1年〜2年ぐらいはフリーランスとしてやっていけるといいなあとか考えてます。
仕事無くなりそうだったらTwitterなりブログなりで泣いてると思うんで、もしその時にちょうどRubyRailsチョットデキルというエンジニアを探していたら、是非声をかけてください。よろしくお願いします。


そういえば、今日初出社という形でクラウドワークスさんの所に行ったわけなんですが、4/1なんで新入社員の方もいらっしゃるわけですよ。
そしたら、その中に自分のSIer時代の元先輩が居ましてね、本当この業界狭過ぎんだろとマジでびっくりしました。
SIer時代の同僚とか何千人も居る中でこれか。人の縁ってのは面白くもあるんだけど怖くもあるなあと思いますね。


例のリスト。 http://www.amazon.co.jp/registry/wishlist/PTRGLVCCH4YH

2014年を振り返るクソポエム

今年はどんなことをやってたのか思い返してみる。

パーフェクトRuby on Rails

外向きの大きな話はパーフェクトRuby on Railsの執筆。

Amazonにいくつか辛いレビューが並んでいるのだが、想像していた通りだとも言える。
そもそも書き始める前に決めたコンセプトでは、研修が一通り終わった新人が仕事でRailsで開発し始めるって時に読む本というのを想定している。

またパーフェクトシリーズの名前を冠しているが、書き始めから網羅性を高くすることは考えていなかった。
Railsの網羅性高い解説というのは、ほとんどRails Guidesの和訳にしかならない。Rails GuidesとAPIリファレンスを読む方が早いし正確だ。

というわけでパーフェクトシリーズの言語本とは少し趣が違うような感じになっている。


趣味でRailsを触るようになって8年ぐらいかな。まさか自分がRailsで本を出せるとは思ってなかったので嬉しかった。
まあ、その分疲れたけど…。

仕事とか

仕事は去年に引き続き客先常駐しつつ受託開発していた。
余りビジネス色の強くない変わった案件だったので比較的自由にやらせてもらえた。
常駐先の新人のコードレビューをめっちゃやってたのでコードリーディングのスピードが結構上がった気がする。
一方で、コードを書く速度が落ちた気がする。
人のコードの改善点を指摘してる内に、自分のコードの駄目な所も想像が付くようになったからだろうか、どうも「完璧主義の呪い」というものにハマっている気がする。
なんかガムシャラに一人で勉強して実践してってのを繰り返すにはそろそろ限界が見えてきたように感じている。
そういうのもあって、ちょっと年明けから環境を変えるつもり。
詳しいことについては、ちゃんとしてから書くかも。

読んだ本とか

今年は技術書よりSF小説を読んでたと思う。
去年グレッグ・イーガンにハマってからSF小説を読むスイッチが入ってしまった。
今年読んだ中で面白かったのは以下の通り。

他にもいくつか読んでるけどこの辺。

読んだ技術書の中でこれは良かったなーってのは「ハイパフォーマンス ブランザネットワーキング」かな。
無線LANの物理レイヤーの話からTCP輻輳制御からHTTP2に至るまで幅広いネットワークの技術をカバーしてて非常に勉強になった。

2015年に向けて

最近、何か作る意欲が減退傾向にあるのでちょっとモチベーションを取り戻していかんとなあと思っている。
Leap Motionとかラズパイ辺りに手を出してみるのもいいかもしれない。
仕事については、プログラマーとして仕事し始めて3年。ちょうど30歳にもなった所なので、これからどうするかを一回考え直す時期に来ていると思う。
来年4月辺りには結論を出しておきたい。

パーフェクトRailsで俺が書いた所について思うこといくつか

既に大きい書店の店頭には並んでいる所もあるようで、自分もアキバの書泉で現物を見てきました。
立ち読みして、ほほーうとやってる著者の図って感じです。

献本させていただいた方にも、既に届いていて読んだよーって言ってくれてる方がちらほら。
参考になったと言っていただけて、とても嬉しく思っています。

さて、今回はちょっと自分の担当した部分と思ってた事について少し書いてみたいと思います。

私が担当したのは、3章のアセットについてと4章のlibディレクトリ周り+Railsのロードパスについて、そして9章のモデル実践編みたいな所です。
一応それぞれありますが、主に言いたいのは9章についてですw

3章について

CoffeeとSassについて、どの程度解説するか非常に悩みました。
実際、書くとなるとリファレンスマニュアルを日本語で解説する、以上の事はページ数的にできない。
かといって、昨今のRailsアプリケーションでは欠かせない要素なので、解説しない訳にもいかない。
RubyとJS以外の他の言語から入ったって人は使ってないって話も聞くので、それなりに書いておいた方が良いとは思ったけど、ちょっとページ使い過ぎたのでは、と思っていたりします。


Sprocketsについては多少詳しく書いたつもり。
特にRailsの中の一要素ではなくて、アセットを管理するRackアプリであることを意識した書き方をしています。
いざアセット管理の詳しい所を更に突っ込んで知りたい場合、どこに当たるのが良いか、ということが伝わるといいなと思っています。
本当は、コンパイルエンジンが実際に何やってるのかとか書きたい気持ちもあったんですが、流石にそれ書いてどーすんだって感じでした。

4章について

一つの章にするにはコンパクト過ぎたような気もする。
しかし、実際仕事で書いたりしてると、ファイルの置き場所に非常に悩むような代物がしばしば登場してきます。
そういう時に取れる選択肢を解説しておきたかったので、1章分の形にしました。
この辺りのテクニックは、実は濫用するような状態になると結構負けフラグなのですが、かといって知らないとそれはそれでもっと辛い事になるかもしれませんので……。

9章について

ここを書くのが、私の中でメインの仕事だったと思っています。
Railsの肝はモデルを如何に上手く作るか、という所にかかっています。
しかし油断して、大丈夫だろーと思ってるとActiveRecordが肥大化して辛いことになる、というのもよくある話だと思います。
この章は、そういう事態を少しでもマシにするための選択肢を紹介する章です。
既に読んでくれた方からもらった感想によると、フルボディのワインのようなどっしりとしたマニアックさらしいですw


私なりに、役に立った知識や上手くいった事をいくつか書いたつもりですが、これが全て正しいのか、というとそんなことは全く無いと思っています。
Railsで取り得る選択肢の一つでしかないし、もっとハイレベルな人から見れば、何言ってんだこいつ?みたいな話もあるかもしれません。
もし、この本を読んでくれて、そして物申したいことがある人は、是非それをブログなどに書いて欲しいと思っています。
そうやって、色々な人が実際に取り組んでるやり方や考え方が、もっと世の中に広がっていってくれればいいなと思います。
そういう意見があれば、そこから私自身も更に勉強していきたい所存です。
なので、マサカリ投げたい人は遠慮なく投げてください。一応喰らう覚悟はしてますんで……。(ダメージを受け流せるわけではない)


そもそもRailsは、最近あちこちで使われてる割に、実際に仕事で開発するような中規模以上のアプリケーションになると、業務内容に直結してしまうので外に出せない情報が多いのですよ。しかも、コンテキストが共有できていない設計の断片は共有しようがない。
(Gemfileの情報交換するだけでも、すげー参考になるぐらい)
そういう理由もあって、書く内容の具体性を出すのに非常に苦労しました。サンプルコードとか理屈の通った説明をするのが、もうめっちゃ辛かった……。


自分自身もまだ試行錯誤段階を脱し切れていないので、勉強会で話す、とかならできるけど本に書くには勇気が出なかった内容とかもあります。
Refinementの活用とか、コレクションオブジェクトとValidatorの組み合わせとか。
というか実際、この章書くの、表向きはちゃんと自信持って書いてますよ、ってポーズを取るのが著者の責任ってものだろうとは思うんですが、実際の所、なんて言うかアレですよ……。
まあ、この日記読むような人は、多少気持ちを分かってくれると思います……。


というわけで、色々と思う所ありながら書いてたわけですが、実際私が書いてみたかったのは9章みたいな話だったので、何とか書けて良かったなーって所です。
他に売ってるRailsの入門系の本とは違う差別化要因になってるはずですが、これが吉となるか凶となるか……bkbkしながらTwitterを眺めています。

パーフェクトなRailsの本を書きました

どうもAmazonがフライングでパブリック状態にしてしまったのが補足されてしまったので、想定してないタイミングで世の中に通知されてしまいましたが、Railsの本を書かせていただきました。
パーフェクト Ruby on Rails: すが まさお, 前島 真一, 近藤 宇智朗, 橋立 友宏


元々はパーフェクトRubyを書いた後にスペースの都合で削ったRailsの章があって勿体無いという話から出てきた本です。
タイトルは最初決まってなかったんですが、最終的にパーフェクトシリーズの一つということになりました。


タイトルこそパーフェクトって付いてますが、この本は他の言語解説系の本とはちょっと雰囲気が違う感じになっています。
まあ、執筆スケジュールとかページ数によるスペースの限界という理由もありますが(Rails本の中ではかなり薄い方)、網羅性というより仕事でRails使ってる人達の知識とか考えに重点を置いた内容になってます。
分かりやすい例で言うと、scaffoldの解説とかほとんどしてないし、Railsの基本機能の中でも省略していることもあります。
しかし、本当の所、著者陣の趣味がかなり入ってるというか、RailsAPIリファレンスとRails Guidesに書いてあることを単純に本にしてもしょうがないだろうと思う所があります。
特にRailsは移り変わりが激しいので、書く側にとっても苦労の割にメリットが薄いように思えます。


というわけで、この本に興味を持ってくれた方に言いたいのは、始めてRailsに触る場合にはこの本は恐らく不向きだということです。
二冊目とか、研修やハンズオンで一通り触った後なんかに、手に取ってもらうのが良いんじゃないかと思います。


じゃあ、この本のウリは何なのか、一応著者の一人としていくつか書いておきます。


まずSprocketsの動作についてある程度ちゃんと書いてます。流石にソースコードレベルまでは踏み込んでないですが、単体でRackアプリとして動作させる方法なんかを説明しています。


そして、より実践的なRailsアプリケーションにおいてモデルをどう扱っていくか、という事について相当ページを割いています。
例えば、ActiveSupport::Concernをこんなにちゃんと解説してる本は、恐らく日本初です。Rails 4.1で追加されたconcerningについても解説してあります。(Rails 4.1対応です)
ついでに、ActiveModelについても、やたらと丁寧に解説しています。この辺の網羅性は無駄に高いです。


他にも、テストの解説やRack、Railtieの動作についてもかなりのページを割いています。
サンプルアプリケーションはwillnetさんが書いてくれたのですが、とても読み易いソースになっているので、シンプルなRailsアプリを行儀良く書く方法が良く分かると思います。


後は、できる限り最新の動向に追従しようとしてる点です。
Rails 4.1に対応した解説もしていますし、サンプルコードも4と4.1どちらでも動くようになっています(いるはず……)。
現時点で、ubuntu 14.04でRubyのビルドをしようとするとコンパイルが失敗する問題についても、多分発売までに修正できるはず……。
(コミッタ筋からの情報によると、もうすぐ対応版が出るらしい)



とまあ、こんな感じでRailsの基本機能を紹介するというより、Railsで開発をする際に何を考えているか、開発や運用に活用するツール、Railsを拡張する方法なんかに力を入れています。
機能紹介は、おさらい的な箇所を除けば、恐らく他の本では解説されないだろうという点にフォーカスしています。
ある意味で、偏った内容の本になっているので、それでもいいよーという方は、是非手に取っていただけると幸いです。


メインで担当した所については、色々と思う所もあるので、それについてはまた後日。

ymsr送別会を終えて

年末のjava-ja忘年会に出た時にyamashiroさんの訃報を聞いて、訳の分からないまま飲み明かした日から1ヶ月半、今日はyamashiroさんの送別会に参加してきました。
その送別会でyamashiroさんを送るための花火が上がりました。
自分がいきなりこの世から居なくなった時に、花火を上げてまで馬鹿騒ぎしてくれる友人が居る彼を心から尊敬します。


今日LTしていた皆さんほどyamashiroさんと付き合いがあったわけではなく、ちゃんと話をする機会があったのは2013年になってからでした。何度か勉強会の懇親会で喋って、やっと顔見知りぐらいになったぐらいです。
多分、最後に会ったのはこわいscala勉強会の受付の時だったかな。
あの時、体調が良くなかったので、本編が終わった後にすぐ帰ってしまったのが悔やまれます。


java-jaの忘年会の日、訃報を聞いて何が何だか良く分かりませんでした。
人の死に触れたことが無いわけじゃないけど、自分より少し年上ぐらいの人間が死ぬなんて事はまだまだ遠い話だと思っていました。今でも良く分からない。
ただその日は忘年会で、自分よりももっと親しかった人達が、とにかく楽しく飲むのが供養だと言っていたので、ひたすら酒を飲んで楽しく過ごそうとしていました。
朝方まで飲んで、一人で帰る時、通勤のためのサラリーマンが溢れる銀座線の中で号泣してました。
友人と言える程の関係性も無かったけど、尊敬してるエンジニアが急に居なくなった事が、とにかく悲しかった。


ところで、先日自分は逆襲のシャアを肴に酒を飲んで語りあう会というイベントを立てました。開催はちょうど明々後日です。
そして今日、ymsr送別会で遺品を巡るゲーム大会で貰ったものに入っていたものが逆襲のシャアブルーレイディスクでした。
こんな出来過ぎた事があるのかと。
これは確実に、どっかで見てるなと思いました。yamashiroさん本当にすげえわ。
ありがとうございます、本当に嬉しいプレゼントでした、大事にします!
後、自分もカラオケが好きなので生きてる間に一度、一緒にカラオケに行きたかった所ですが叶いませんでした。
とても残念なので、来世かあの世的な所で是非一緒に歌い明かしましょう!

世界を変えたいとか思わない俺と、ヒーローになりたい俺

この記事は闇 Advent Calendar 2013 - Adventarの19日目です。


なんか前回の記事を書いたjugyoさんが非常にインパクトの強い話をぶち込んできたおかげで、次の俺どうしようかって感じで困ってますが、私は普通に鬱屈してる感情を書くだけなんで、そんな面白い話は無いです。自分語りのオナニーをして終わりです。
変な期待をしてる人が居るかもしれませんが、私はマジで何も関わってないのでコメントのしようが無いし。

俺の経緯

私は大学生になるぐらいまで、ただPCでゲームして、エロ動画を見て2chを眺めているだけだった。
貧乏だったので、バイトして金溜めてPCを新調した時、古いPCを活用する方法を考えて、Linuxルーターを作る事にした。
そこからLAMP構成ってやつでプログラミングの真似事をやりだした。

実際の所、私はエロ動画及び画像の収集と管理を楽にするためにプログラミングやHTTPの仕組みを覚えた。
Referercookieを偽装したり正規表現スクレイピングライブラリで頑張ってHTMLからURLを切り出した。
ファイルからサムネイルを作ったりファイル名とパスをDBに突っ込んでブラウザから検索できるようにした。

今でも新しい言語で何かする時には、とりあえずエロ動画を整理するためのアプリケーションを書く。
作り慣れてるし、自分の役に立つからモチベーションが続きやすい。


その後、自作のカラオケ動画やニコ動に上がっているカラオケ動画を使ってPCでカラオケをする、という行為を効率化するシステムを作り始めた。
実は、これもエロ動画の管理の応用で作り始めたものだ。
要は動画を検索し、それを変換しキューイングし自動で再生するという処理を作れば良かった。
エロで蓄えた知識を趣味のカラオケに適用しただけだ。

このシステムをRailsで何回か作り直してたら、Railsである程度のアプリケーションが作れるようになった。


法律家になるつもりで入った法学部に全然向いてなかった事が分かったので、なんとなくやれそうなIT系に向きを変えて適当に就活をし、でかいSIerに入った。
そして余りのつまらなさに絶望した。
仕事の大半はメールで誰かをせっつくか、机上の空論に無理やり理屈を付けることだった。

とにかく社外に出ないと話にならんと思い、社外の勉強会に参加しまくるようになった。
Rubyコミュニティで何とか居場所を見つけられたので、継続的に参加するようになった。

そうこうしている内に辞めたさが限界に達して、もう駄目だって時に今の会社に声をかけられたので、渡りに船な感じで転職した。
まあ、そんなに悪い会社ではない。俺はそれなりに楽しく開発できてるし待遇も悪くはないと思う。
Twitterなんかに対する露出の仕方については、個人的には余り好きじゃないし、しばしば良く分からんと思うことはあるけど。

世界なんて変えられない

さて、何とか大手エンプラの世界から転職したのだが、要は嫌なことから逃げたのだ。
このつまらん会社を変えようなんて端から考えていなかった。
どうせ俺が何を言っても周りには伝わらないし、あのでかい組織で権限を獲得するころには自分自身が腐ってそして年老いていることは間違いないと思っていた。
だからさっさと逃げた。


最終的に自分が雇ってもらえて何とか自分の好きなRubyで開発が出来てるので、今はそれなりに何とかなっている。
Rubyと触れ、コミュニティと関わっていたおかげで、Rubyの本を書かせてもらえたりもした。
しかし、未来に対する不安感というのは余り消えてくれないものだ。
根本的に自分は働くのに向いていない。
朝は起きれないし、良く体調を崩す。正直、週に5日も働いていると月に1,2回は限界が来る。
そもそも仕事なんて、できればしたくないのだ。

いつまで経っても自分がしょうもない人間なのは、やりたくない事は沢山あるがやりたい事はさして無いからだ。
今もってなお、自分が作ろうと思えるものは、エロ動画の管理とカラオケを効率化するためのシステムぐらいだ。
世の中を変えたいなんて全然思ってないし、誰にも負けない程開発が好きというわけでもない。
結局の所中途半端なのだ。
エクセル方眼紙とそびえ立つクソを売って金に変えるような世界に嫌気がさして逃げてきた割に、じゃあ俺は何がしたいんだ?って考えると特に何も持っていない。


実際他の人がどうか分からないが、外から見てると皆熱意溢れる人に見える。
人生のリソースを開発者として生きることにちゃんと費しているように見える。
そんなに熱意を持って仕事しなきゃならんのか。
皆、意識が高過ぎるんだよ。開発による自己表現って何だよ。
そういうのが全然分からん。表現したい意思とか特にねえよ。
現場を変えるとか価値の提供とか、本当の所良く分からん。
無駄なことばっかやってたらつまらんってだけじゃないのか。
つまらないことで時間を無駄にしたくないだけなんだよ。


どうも俺は他人の幸せに対する想像力が無いらしい。
何に困っているかということに対する想像力が無いらしい。
見知らぬ他人を幸せにするために頑張ったりできない。
自分とタイプが異なる人間のために何かする気にはなれない。

厨二病としての俺

基本的に私は自堕落に生きていきたいただの駄目人間なのだが、一方でこじらせた厨二病患者でもある。
厨二というのはそう悪いものではないと思う。
エンジニアなんてものは、厨二でないと駄目だとさえ言える。
自分の中で厨二であることが一つの良心として働いている。


私にとって、カッコよさというものの基準は少年マンガや特撮ヒーローなのだ。それは今も変わっていない。
普段ギャグキャラだがやる時はビシっと決める男がカッコいいと思う。
誰からも省みられることもなく、己の正義のために孤独に戦うヒーローの姿に憧れる。
突然学校にやってきたテロリストを咄嗟の機転で冷静に撃退したいと思っている。


ダラダラと過ごしていきたい自堕落な自分が居る一方で、そんなことでグダグダやってるのは漢のやる事じゃねえ!と思う自分も居る。
正義の味方になりたい。誰よりも自分に対してカッコつけたい。
お前は、いつもジョジョを好きだと言いながら、誇り高き人間の魂に背を向けていられるのかと。


人間、自分の心の中には闇の自分と光の自分が居るものだと思う。
常にどちらが主導権を握るかで争いあっている。大体、闇側が優勢なんだけど。
でも、ギリギリのラインで自分の中の正義が発動して、何とか人間で居られているような気がする。


厨二病気質の人の中には、何かしらその当人にしか分からない憧れや正義があるんじゃないかと私は思っている。
だから、正しいことをやれる人は多分厨二病の一種なんだ。


今の所プログラミングをして何かを開発するという行為は楽しいと思っている。
見知らぬ他人のことは分からんが、近くの誰かの役に立てることは嬉しいと思う。
いつどうなるか分からんけど、出来るだけ楽しいと思えることで食っていきたい。
そして、普段腐ってても何かの拍子に自分の中の正義が発動した時に、それが阻まれないような環境が欲しい。
なので、零細企業でプログラマーをやっている。
別に大層な事はやってない。数百万の人が楽しめるサービスを作ってるわけじゃないし、生活の価値観が一変するような新しいサービスを生み出しているわけでもない。
近くにいるやりたい事がある人の手助けをしているだけだ。
それでも、前よりは楽しく生きている気がする。


後は、自分がコードを書いて開発するということに対して飽きないことを祈るのみ。
そうなったら、もう死ぬしかないような気がする。
自分の興味が続くかどうか、それがもっとも怖い問題だ。
他にも文系コンプレックスとか、数学が分からんとか、英語が喋れんとか、もうすぐ30だけどどうすんだとか、色々怖い問題あるけど…。


さて、プログラマーになっていよいよ3年目に突入する。
色々考えてしまったが、来年も程々にゆるく生きていこうと思う。

webapi-vimとBufWriteCmdでWeb上のリソースをVimで編集する

この記事はVim Advent Calendar 2013の14日目です。
前の記事はVim on Android | 高級粗茶2。でした。


Vimを使っているとWeb上に存在するリソースもVimで扱いたくなることがあります。
そんな時の強力なお供がmattnさん作のwebapi-vimです。
webapi-vimを利用することで簡単にWeb上のリソースをvimに取り込むことができます。

let res = webapi#http#get(s:pull_request_list_url(a:repo), {}, s:github_request_header)

if res.status !~ "^2.*"
  return ['error', 'Failed to fetch pull request list']
endif

let content = webapi#json#decode(res.content)

こんな感じで webapi#http#getやwebapi#http#postを呼び出すことでcurlで通信した結果を取得できます。
JSONを返すAPIであれば、webapi#json#decodeを呼び出すことでvim scriptのディクショナリやリストにデータを変換してくれます。


Web上のリソースを扱う時、保存方法に良く使うテクニックがbuftypeオプションとBufWriteCmdです。

setlocal buftype=acwrite

autocmd BufWriteCmd <buffer> call s:post_comment()

function! s:post_comment()
  let body = join(getline(1, "$"), "\n")
  let b:comment_info.body = body
  if pull_request#post_review_comment(b:repo, b:number, b:comment_info)
    setlocal nomodified
    bd!
  endif
endfunction

buftypeをacwriteに指定する事で、:writeコマンドの実行時に発生するBufWriteCmdイベントでファイルを書き込む処理を行うことができます。
後は任意のvim scriptで書いた関数を呼び出せばオーケーです。
そこでwebapi-vimを使えば、Web上に何かを投稿するような処理をVimで普通に編集して保存するような感覚で利用できます。
autocmdでコマンドを定義する時にはバッファローカルにしておかないと暴発するので注意しましょう。
BufWriteCmdからファイルを書き込む時には、ちゃんとmodified状態を無効にする処理を書いておく必要があります。
普段の:writeコマンドと違って自動では処理してくれません。


最近、このwebapi-vimを利用してPluginを作ったので紹介しておきます。

GitHub - joker1007/unite-pull-request: unite-pull-request is a unite.vim plugin for Viewing GitHub pull request.

uniteでgithubのpull requestの一覧を参照したり、変更されたファイルのdiffをvim上で表示するプラグインです。
githubのWeb UIで見るよりvimで見た方がファイルの差分を確認しやすいのでは?と思って作りました。
また、Vimからレビューコメントを送信することができます。

差分表示画面でEnterを押すと新しくコメント用のバッファが開くので、そこにコメントを書いて普通に保存するように:writeを実行すると、Enterを押したカーソルの行に対してレビューコメントが送信できます。
vim上の表示とgithubのコメント対象行を一致させるのが困難だったので、既に存在するファイルを編集した差分の場合は、下部に表示されているdiffデータのバッファからしかコメントが投稿できないのが難点の一つです。
他にもページネーションを考慮してないのでpull requestの一覧を最新30件しか取得できないとか、まだまだ機能不足な点がありますが興味があったら使ってみてください。

余りvim scriptに詳しくなくても、webapi-vimのおかげで比較的簡単にvimからWeb上のリソースを編集することができるようになります。
webapi-vimで良く利用するWebサービスVimから扱う快感に酔いしれましょう。