私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
C-M-/ dabbrev-completion - @kyanny's blog
どういう風に機能するのか知らないままにしておくのは気持ちが悪いので試してみた。 bash のデフォルトの補完みたいな動きをするわけか。 compiler complete computer って書いてあるバッファで c[C-M-/] って押すと com まで補完されてウィンドウが分割して別ウィンドウのほうのバッファに補完候補が並ぶ。この挙動は一般的で悪くないかも。 でもその候補バッファから一つ選ぶのが、 TAB とか C-M-/ とかで順繰りに選択していければいいんだけど動かなかった。そっちのバッファへ移動して選ぶとかだるすぎるな。しかも Cocoa Emacs で GUI だからなのか mouse-2 押して選べとかいわれるし。 Completion の Info も少し読んでみたけどこの辺のカスタマイズをどうするかまでは読み取れなかった。また気が向いたらもう少し勉強しよう。 dabbr
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 は多くのユーザ
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
