37signalsのBasecampでは、Railsで用意されているデフォルトの3つの環境のほかに、Beta、Staging、Rolloutの3つを定義して使っている。

• Beyond the default Rails environments by David of 37signals

Rollout環境は、新機能をまずユーザーの10%にだけ公開するために使われるもので、Flickrやetsyなど多くのサイトではFeature flippersとよばれる機構で実現している（機能毎のフラグを参照することで、新機能をユーザーに提供するかどうか切り替えるようなもの）。コメント欄でも、何故、Feature flippersではなく環境で機能のロールアウトを行うのかが尋ねられていて、DHHは以下のように回答していました。

I always want to leave the campsite in a better condition than I found it. To do that, I often refactor lots of code in the development of a new feature. When you’re not just adding to the pile, but rearranging it, it’s not the best idea to do that on production most of the time.

Additionally, while it’s great to use features in production for a bit before committing to their release, I also believe in clearing the decks and having as little discrepancy between the production version of Basecamp and the development version. That means an app not littered with dozens of features only visible to company workers. Work grows stale if it’s not shipped and it doesn’t provide any value to our customers before it is.

So that’s the general philosophy. But there’s also a matter of scale. We have less than 10 developers at 37signals. So we can’t work on dozens of features at once. If you have a hundred developers, all working on lots of features at the same time, maybe you have to accept the drawbacks of feature flippers. But that’s (thankfully, to me) not our scale.

つまり、Feature flippers方式を使うとProduction環境が機能フラグでゴチャゴチャしてくるのが嫌、ということなのかな。

まあ、それはそれとして、最後の段落の「37signalsには10人以下の開発者しかいないので、一度にいくつもの機能には取り掛かれない。この規模なら（ありがたいことに）Feature flippersの欠点を受け入れずに済むんだ」というのが実に37signalsらしくていいです。

ついでに、サラッとdhh/custom_configurationというgemが紹介されてた。

Hubotを中心としたGitHub社内のワークフローはChatOpsと呼びことになったようだ。

Hubotというチャットルームのボットを利用して、Webサービスの運用にまつわるあれこれ（デプロイ、テスト、負荷グラフ表示、エラーログ監視などなど）を行うGitHubの開発・運用スタイルはもはや有名ですが、GitHubのJesse Newland氏のスライドを見ると、昨年末くらいからこのワークフローをChatOpsと呼ぶようになっているようです。

• ChatOps at GitHub // Speaker Deck
• Puppet at GitHub / ChatOps // Speaker Deck

ChatOpsについては、日本語では以下のサイトに簡単にまとまっていました。

• GitHubの中の人が使っているHubot、そしてChatOpsってなんだ？～QCon Tokyo 2013レポート | イベントカレンダー＋ログ

キャッチーだし、呼称としてはなかなかいいんじゃないでしょうか。

Internet Explorer 9以下に存在する「1つのCSSファイルで認識されるセレクタは4,096個まで」という制限に突然引っかからないようにするための方策。

対策ではなく、突然の遭遇を予防する方策を色々と調べてみたところ、Atomic Spin - Atomic Object's Blog On Software Design & DevelopmentというブログにGetting Around IE's 4,096 CSS Rule Limitという記事があり、Railsアプリのfeature specで「セレクタ数が4,096個以下である」ことをテストするアプローチが紹介されていたので、それを導入することにしました（実際に導入する際は4,096の箇所にマージンを持たせておくとよさそう）。

CapybaraがHEAD要素内のLINK要素を参照できるようにするために、以下の設定が必要でした。

Capybara.ignore_hidden_elements = false

また、同記事のコメント欄で紹介されていたQuick lines to get the number of selectors in each CSS to make sure that IE is not breakingというJavaScriptも役に立ちそうです。

また、個人的にこの問題を回避する一番いい対策だと思うのは、4,096を超えないようにスタイルを制限する＝サイトから無駄な機能を削り続ける、という視点を持ち続ける、ということかなと思います。

Hashrocketではどのようにペアプログラミングを実践しているのか（HashrocketはObie Fernandez氏が創業したWeb開発会社）。

• How We Pair - The Hashrocket Blog

Hashrocketでは常にペアプログラミングを行なっており、受託案件の重要な機能を開発するときも、オープンソースフライデー（毎週金曜日にオープンソースコードを書く的な催し？）でオープンソースのコードを書くときも、常に2人体制だそうだ。

1つの頭よりも2つの頭で考えるほうがより良い、という当然の理由のほかに以下のような理由がある。

• 間違ったやりかたにはまってしてしまう前に、パートナーが別な解決策を提示してくれる
• 正しい解決策がずっと目の前にあるのに、それとは別の難問に取り組み続けてしまうような時、解決策がそこにあることをパートナーが教えてくれる
• スペルミスのような単純な部分にはパートナーが注意を払ってくれる
• 1人で作業をすると自分にとって快適な道具を使い続けてしまうが、ペアなら新しいアイデアやツール、スタイルを導入し合って、ソフトウェア開発者として成長し続けていける

ツールとしては以下のものを使っているようだ。

• Vim - 全員がTerminalのvimかMacVimを使っている
• iMac - 1つの27インチiMacに2つのキーボードとマウスを繋ぎ、2人で使う
• Tmux - 半分くらいがTmuxを使い、残りの半分はタブだけを使う。どちらを使うかはペア次第だけど、全員がTmuxを使いこなせるレベルにはある
• Dotmatrix - すべてのdotfileをGitHubリポジトリに公開している。すべてのiMacがこのリポジトリと同期していて、部屋を移ったりしても環境が変わる心配はない

ポートランドが拠点のTech系カンパニー11社のオフィス紹介PV。有名どころでは、SimpleやUrbanAirshipなんかが登場しています。

This is the collaboration of 11 Portland tech companies, showcasing Portland's office culture. We are proud to have provided the aerial shots for yet another great timelapes produced by Uncage the Soul Productions.

これ系のビデオだとニューヨークのスタートアップシーンが結構かっこいいのを出しているイメージがあるけど、ポートランドもなかなか。