Sooey

2013-07-15 00:56:51 +0900

HerokuのAPIをcurlで叩いてプロセスをスケールさせるメモ。

Heroku上のアプリのworkerプロセスをスケールさせる処理を、Heroku Schedulerを使って定時実行したかったので、curlでAPIにアクセスする方法について調べました。

まず、Getting Started with the Platform APIを参考にAPIキーを取得します。

$ API_KEY=`(echo -n ":" ; heroku auth:token) | base64` ; echo $API_KEY
OjAxMjM0NTY3LTg5YWItY2RlZi0wMTIzLTQ1Njc4OWFiY2RlZgo=

あとは、Platform API Referenceを見てcurlのコマンドを組み立ててAPIキーをAuthorizationヘッダとして付与すればOK。

プロセスに対する処理はDynoではなくFormation APIというものを使います。example-appアプリのworkerプロセスを0から1に増やす場合は以下のようなコマンドになります。

$ curl -n -X PATCH https://api.heroku.com/apps/example-app/formation/worker \
-H "Authorization: $API_KEY" \
-H "Accept: application/vnd.heroku+json; version=3" \
-H "Content-Type: application/json" \
-d "{\"quantity\":1}"

逆にworkerプロセスを1から0に減らす場合は以下のようになります。

$ curl -n -X PATCH https://api.heroku.com/apps/example-app/formation/worker \
-H "Authorization: $API_KEY" \
-H "Accept: application/vnd.heroku+json; version=3" \
-H "Content-Type: application/json" \
-d "{\"quantity\":0}"

2013-07-01 21:06:15 +0900

CSSの記述・管理スタイルをどうするか考え中。まだこれといった結論は出ていないので、この記事は単なる覚え書きです。

ここ1ヶ月ほど、qnypの開発をデザイン面で支えてくれている@ruedapさんと、

  • CSSのスタイルガイドを何でどう作るか（今のところKSSが有力候補）
  • BEMやSMACSSが提唱している命名規則は実作業においてどんなメリット・デメリットがあるか
  • レスポンシブなグリッドフレームワークは何を採用するのがいいか（候補はSusy、Bourbon Neatあたり）
  • DOM要素にスタイルを適用する際にid/classをメインに使う（OOCSSアプローチ）か、要素名をメインに使うか

みたいなことを延々とやり取りしています。

その過程で、そもそもの問題の根幹についてちょっと思いついたことがあったので、いくつかツイートしてみました。

2013-06-21 17:26:24 +0900

Basecampを家族で使っている人の話。

この人は37signalsのスタッフではあるけれど、入社前から何年もBasecampを奥さんとの情報共有に使っているそうです。最近Discussionの数が1,000を超えているのに気づいたので、簡単なまとめ記事を書いた、ということのよう。

個々の使いこなしについては、スクリーンショットもあるので原文を参照してもらうとして、とくにいいなと感じたのは後半の "So what’s the real benefit of doing all this?" のところ。

Like many couples, my wife and I both work. We’re together as a family for maybe a few hours a day. We want that time to be spent talking about stuff that really matters – how friends and family are doing, work happenings, and other more interesting, fun stuff.

Spending time at the dinner table discussing all the things we need to do is a waste of time. So we don’t do it. Instead, we focus on each other and our kids, and not the noise of daily life.

「共働きだから1日に数時間しか家族の時間がない。その時間は、友人や家族たちがどんなことをしているのかや、職場であったことなどの、もっと大切で面白いことに使いたい。夕食のテーブルでTODOについて話すのは時間が勿体無いし、そうしたいわけでもない。お互いのことや子どもたちのことに向き合いたいんだ。日々の煩わしいことではなくね」

2013-06-20 01:04:41 +0900

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

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が紹介されてた。

2013-06-20 00:40:40 +0900

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

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

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

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