第二次CTOブームから技術顧問ブームへの流れについての考察 - @kyanny's blog
「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが
リモートで働く開発者が行うとよいたった二つの習慣 - @kyanny's blog
チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身
Qiita::Team やめた - @kyanny's blog
Quipper 日本オフィス（+ 海外オフィス勤務の日本人）で「チャット以上 Wiki 未満」な情報共有ツールとして二年ほど使ってきた Qiita::Team をやめて、 GitHub Issues に移行した。 Qiita::Team は日本人の間では活用されていたが、グローバル企業なので英語以外のみでの情報共有は好ましくなく、しかも Qiita::Team は個別に invite しないとアクセスできないので海外拠点のスタッフにとっては非常に閉鎖的な場だった。せめてアクセス可能にしようと plan をアップグレードし invite したものの、国際化対応が不十分だったりそもそも日本語の文章を翻訳して読もうというガッツもなかったりして、日本人以外には活用されなかった。 Quipper は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して
ペパボの社内勉強会で Fixture Replacement について発表しました - @kyanny's blog
ペパボ社内の RSpec 勉強会で Fixture Replacement について発表しました。実際は RSpec に限らずテストに関する話題を幅広く扱う勉強会でしたが。社外に公開しても差し支えない内容なのでスライドを公開します。 話す内容を補うために用意したスライドなので説明不足だったり例がイマイチなところもありますがご容赦ください。テスト環境まわりのツールについては自分自身まだまだ手探りで使っているので、何かの機会にぜひ識者の意見を伺いたいものです。願わくば Shibuya.rb のような場で発表させていただいて、それに対してツッコミをもらいたいですね。 以下余談です。 「このテイストは GitHub のアレだな」とピンときた方はご名答。 Zach Holman 氏のスライドを大いに参考にしました、っていうかほぼパクリました。Slide Design for Developers を
ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
Leave from paperboy&co., join to Quipper - @kyanny's blog
来週ペパボを退職します！転職先は Quipper です！みんな大好きウザい退職エントリも当然あとで書きますがウィッシュリストとか無いので！ブクマとスターを！！くれ！！！承認欲求！！！！— Kensuke Nagae (@kyanny) May 24, 2013 May 27 is my last day at paperboy&co. I had a great time with gentle people in this 3 years and 3 months. Thank you for all my colleagues! paperboy&co. is a good company for the following reasons: Culture: There are so many nice people here. They gather and play natura
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog
rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動
Working with UNIX Processes を読んだ - @kyanny's blog
Working With Unix Processes という本を読んだ。 Thin の作者からの「時期バージョンを作るとき参考にする」というメッセージ*1が添えられていたのに惹かれて買った。著者のサイトで直販しているが、 Kindle Store からも購入できる。 この本は一言でいうと、 UNIX 系 OS のプロセスについての本だ。プロセスとは何か、という導入部から始まって、プロセス ID やプロセス名、終了コードへと言及し、 fork(2) やソンビプロセス、シグナル、そしてデーモンプロセスの説明あたりまで本編中で説明している。 UNIX プログラミングに関する類書は 1000 ページを超えるものが多いなかで、この本はわずか 100 ページほどしかなく容易く読める*2。しかしページ数が少ないぶん、あまり踏み込んだ内容とは言えず、全体的にやや浅い印象を受けた。すでに UNIX, Li
渋谷.rb[:20120215] で Ramaze と Sequel について発表しました - @kyanny's blog
渋谷.rb[:20120215] で Ramaze と Sequel について発表しました。ありがとうございました。 http://speakerdeck.com/u/kyanny/p/shibuya-rb-20120215-ramaze-sequel まとめだけ書くと、 Ramaze は覚えることが少ない・全容を把握しやすいのがよい Sequel は dataset がとてもよい。 SQL 的な「行の集合」を集合のまま扱えるので (行オブジェクトの配列ではなく) どちらも使い始めるまでの設定とか前提となるものをほとんど必要としないので、プロトタイプ作りとか、思いついて 10 分後には飽きてしまいそうな小さいコードをちゃちゃっと書くのに向いてると思いました (ちなみに一緒に参加した同僚は「むしろ二層のモデルの上層部分を dataset の表現力でカバーしたり DataMapper パターン
![渋谷.rb[:20120215] で Ramaze と Sequel について発表しました - @kyanny's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/08da6727a426508f9f301e23c2b2951496cabd1f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729888747%2F12704346814673929549%2F1329320835)
git add -p の使い方 - @kyanny's blog
y ... 追加 n ... スキップ s ... もっと細かい hunk にわける e ... 直接編集 (うまくできなかった) s がすてき。
highscalability.com の Tumblr のアーキテクチャについての記事を読んだ - @kyanny's blog
High Scalability - High Scalability - Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter を読んだ。すごく面白かった。 Kindle で引用したところを中心にメモ。 Tumblr のソーシャルグラフの特徴 The graph for Tumblr users has hundreds of followers. This is different than any other social network and is what makes Tumblr so challenging to scale. Tumblr だと follower が数百人いるユーザーはザラにいる。 follower の多いユーザーの post は多くのユーザ
Google Chrome の「検索エンジンの管理」にるりまサーチを追加する - @kyanny's blog
いままで無意識に「ruby inject」とかでぐぐって赤いページを見ていたんだけどリダイレクトされるようになって permalink にたどりつくまでのステップ数が増えたので、この機会にスマートキーワード的に引けるようにした。 Google Chrome では設定 - 基本設定 - 検索 - 検索エンジンの管理から追加できる。 http://doc.ruby-lang.org/ja/search/query:%s/これを ruby というキーワードで追加したので、アドレスバーに「ruby inject」とかいれるとだいぶ幸せになれた。まぁいちいちネットで検索するのもどうなのよ、という話だけど（いちおう Emacs からもひけるようにしてあるけど細かいインターフェースを自分ごのみにカスタマイズしきれてない）もっとはやくやっておけばよかった。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tig でいま見ているコミットをブラウザで開く - @kyanny's blog