最近ReactとVueをどっちも触る機会があったり、「ReactとVueどう選定するの？」という問いを投げられ、スッと答えられなかったな、と後悔があったりしていたので、Vueを触って得られた感想をまとめてみる。 結論としてなにか新しいことを発見したというものではなく、世間で言われている事を自分なりに再構築しただけの結論になったと思う。 TL; DRVueからは全体的に優しさ（Gentleさ）を感じる事が多く、良い点だと感じた大規模になるときReactの堅牢さは魅力的。Vueが大きくなった時に支えられ設計が出来るかは個人的には懐疑的。「こうだったらVue、こうだったらReact」みたいな分岐点があるというわけではないので、最終的には好みになってくると思う。ぞうさんが好きかきりんさんが好きか。これまでのフレームワーク遍歴今回の話をするにあたって、僕と各フレームワークの付き合いをまとめておくと、

普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう！」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ

新卒入社したピクシブ株式会社を退職し、フリーランスになって半年以上経った。本格的に仕事をし始めたのは8月からなので、まぁ丁度半年と言っても問題ないだろう。 自分は高卒で入社しておいて3ヶ月半でやめるという信じられないような行為をした上でフリーランスとして生きているわけだけれど、今の生き方はすごく満足している。自分にとって新卒というカードはあまり重要ではなかったので使ったことに特に後悔はないし、ストレートでフリーランスになるより数ヶ月だけでも新卒をできたのは良いことだと思っている。 とはいえ状況としては今のほうが性に合っていることは間違いない気がするし、良いことを書きたいんだけど、それはそれとして、明確に失ったものもあるのでどちらもどこかにまとまったテキストとして書き残して、これからまた自分が大きな人生の選択をする時に考えるためのものとして活用できたら良いなということを思い、書いてみることと

個人で運用している幾つかの Web サービスについて、自分がどう管理しているかを振り返る。 実験には Heroku を利用習作につくったアプリやβ版段階のアプリは、Heroku で動かしている。Heroku を使う場合のより具体的な条件としては、データベースが明らかに無料枠に収まりそうで、24時間動いていなくてもまあ誰にも怒られそうないような場合。Slack 用の Bot や、nippo という日報専用サービスのクローズドβ版などを主に置いている。 メリットに感じている部分は、無料で使えること。デメリットに感じている部分は、サーバが US に配置されることと、データベース系の Add-On が高くつくこと。例えば日本語圏向けのサービスだと、通信時間がそこそこ長くなり、結果的にサービスの体験が悪くなる（昨今の平均的な Web サイトの速度はまだまだ遅いので、それと比較すると悪くなるというほど

成長期のベンチャーにおける採用の失敗2011年2月「任侠道」などのゲームがヒットし、売上が伴ってきたとき、それは終わらないマラソンが始まったことを意味していた。 そして、以後横展開した「道」シリーズがヒットを飛ばしていくために、様々な問題が噴出し始める時期である。 プロジェクトを広げようにも、どのプロジェクトも人が足らない。 加えてエンジニアだけではない「初期の頃のメンバー」が退職を重ねていく時期でもあった。 バックオフィスも開発も、見よう見まねでやっていたところに経験者が入ってきて、ポジションが入れ替わるようなことが頻繁に起きていた。 「自分の好きだったgumiは死んだ」というような事を言って辞めていく人たちもいた。 開発現場でも、のんびりと仲良く売れないゲームを運営していれば良い時代は終わってしまったのである。 「任侠道」が明確なヒットを飛ばしている傍らで、のびのび結果のでないプロジェ

開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守

一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミングで新規アプリのクライアントからサーバまで開発してみました。チームにエンジニアがちょうど二人だったので。 もはや日常がペアプロです。ペアプロ以外でやってるのは簡単なバグ修正やちょっとした環境整備で、あとはすべて二人で開発しています。ちなみにまだまだ続いています。狂気です。 いい大人が二人集まって狂気を選ぶことになったわけは、成果も出てないしまだ書けません。でも今って、ペアプロやモブプロがブームだって聞きました。それじゃあアホみたいにやってる人間としては黙ってられないです。基本的なことはおいといて、とりあえずこれだけはってつくづく思ったのとか、ペアプロを有意義に長く続けるコツをまとめてみました。 （ちゃんとした話は ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Program