yaotti's diary

Software is Eating the World

札幌RubyKaigi2012

9/14~9/16の札幌RubyKaigiに参加してきた．

最近はビジネスモデルや思考のフレームワークを理解していくのが面白くてプログラミングについて考える時間が減っていたけれど，今回尊敬するプログラマ達の思想に触れたり(刺身さんの発表はレガシーコードの辛さやRubyへの想いが伝わってきて今思い出しても感極まるし，初の生miyagawaさんの発表は本当にやる気が出るものだった)また刺激的な技術トピック(kakutaniさんの話していたDCIはもっと調べてみたい．@tenderloveがサラミ監視システムで使っていたArduinoはちょうど@hmskさんに薦められて買ったところだったので色々遊びたい)を聞けて改めてプログラミングいいなあ，と思った．

一時期は通勤時とかに色んなコード読みまくってたけど最近はビジネスの構造化ばかり考えてたし，ビジネスと技術へ定期的に振り切っては戻ってきてを繰り返してる．もっと振り幅を大きくするとより楽しそう．

札幌Ruby会議の"We Code"というテーマはすばらしいと思う．会議に良い雰囲気を作り出していた理由の1つじゃないかな．

ぼくはあまり人と一緒にコードを書けていないので，今後は自分から頑張って一緒にコード書く機会を増やしていきたい．社外の人に適当に声かけてペアプロとかしよう． 札幌Ruby Kaigiスタッフの方々，とても楽しい会をありがとうございました．

宣伝: We Codeする機会として Qiitaハッカソンをやるので，一緒にコードを書きましょう．

技術/組織としてどうスケールするか at GitHub

会社をスケールさせていくために組織面，技術面で何を行ってきたか．以下簡単なまとめ

組織面

従業員をよりhappyにするために，面白い仕組みを導入している．ミーティングがない，オフィスに来なくても良い．やりとりはpull requestとcampfire．
他にも組織として強くなるために，個人に依存しすぎない(知識共有を促進する)，internal talk(tech talkみたいなのかな?それとも普通の会話?)は将来の従業員のために全て記録する*1，など．

技術面

  • 自動化可能なことを手作業でやり続けることによるコストは，手間だけではない．新規メンバーに学習コストが発生することになる．
  • masterブランチは常にデプロイ可能な状態に保ち，1日に5~30回デプロイを行なっている．
  • 意味のあるメトリクスをグラフ化しよう．全体でのレスポンスタイム平均がXXXms，というのは意味がない．
  • リリース以降今までインフラがどう変遷してきたか．ナイーブな実装だとストレージを無駄遣いしていたので，net-shardというCoWっぽい形で節約できるように変えた．


最後の"Continually refine your process + workflow"は心に留めておきたい．

ハッカーのためのハッカソン

毎日blog書くつもりだったけれど綺麗に3日坊主になってしまった．

1/4, 1/5はWantedly開催のHackathonに参加してきた．目的は「エンジニアのスキルがわかるようなプロフィールを作る」こと．
ハッカソンの様子など詳しくはこちら:) ウォンテッド超絶ハッカソン!! - ウォンテッド 航海日誌
そして2日間のハッカソンにより出来たのがこれ．

GitHubの情報を使って，ある人が使っている言語やフォロワー数などがグラフで見られるようにするサービス．自分がpublicな活動を全然してないなーとか，あの人はruby書きまくってるなーとか．
ログインなどは必要ないのでGitHubアカウントを持っている人はどうぞ．
Hackedly

Qiitaとしても各エンジニアがどういうスキルを持っていて，どれだけコードを書くのか/書けるのかをユーザーページで表現できるようにしたいと思っているので，今回のハッカソンは色々発見があり楽しめました!:)

顧客開発プロセス：アントレプレナーの教科書

年末年始はアントレプレナーの教科書
を読んでいる．方法論をきちんと学ばないといけないな，ということで技術書以外にもアンテナを張るようにしています:P

この本の前にはThe Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
を読んだのだけれど，
「スタートアップ=自分達のアイディアを元にとにかく頑張って素晴しい製品を作り，それが使ってもらえると成功，そうでなければ失敗」
という自分の既成概念が壊された．
自分達のアイディアや仮定を頻繁に検証し，進んでいる方向が正しいのか間違っているのか常にチェックすることで無駄を減らす．時間と手間をかけて優れたサービスを作っても，誰にも使われなければ意味がない．
この本(アントレプレナーの教科書)では，新製品の開発プロセスはどう進めていくべきかということがより詳しく書かれている．

GitHub: 幸せに最適化する組織

以前id:naoyaさんにOptimizing for Happiness // Speaker Deckを教えてもらって以来，GitHubがどういう組織なのか，どう働いているのかに強い興味を持っている．

上記スライドに書いてある内容から自分の気を引いた部分をまとめると

  • 会社はお金を稼ぐためにあるのではない
    • チーム，顧客など人々の幸せを追求するのが最も良い
  • 小さく初めて大きくしていく
    • 最初の2年は10人以下だったが，2011年は14人→47人に!
  • 日々の生活にある残念なことを技術で解決しよう
  • 熱狂的なファンを作れ
  • highly-connected, flexible micro-structureな組織
    • 組織構造がピラミッドやグループではなく，密に繋がったグラフ構造

など．

GitHubberによるQ&Aやエントリなど

これから組織を作るという人は参考にしてみてはどうでしょうか．

英語アウトプット用にGitHub pageを利用する

要件は以下

  • セットアップが簡単
    • とりあえず書き始めたい
  • 自分のドメインが使える
  • markdown記法が使える
  • コードハイライト機能
  • ローカルファイルに書き，投稿という流れが出来ること
    • ブラウザで長文書きたくない&ローカルにも残しておきたい

ということでGitHub Pages(+Jekyll)を利用することにした．
jekyllで作る簡単GitHub Pages - T.I.D.を参考に．
Hiroshige Umino