デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
Code Complete 第2版 下 - @kyanny's blog
blog.kyanny.me 上巻読了から半年、上巻を買ってからは実に九ヶ月も費やしてようやく下巻も読み終わった。長すぎて途中で何度も飽きたり挫折したりしてしまい間が空いたし、前の方に何が書いてあったかろくに覚えてもいない。 とにかく長すぎる。名著ではあるのだと思うが、時間に余裕があるか「俺はあの Code Complete を読破したんだぞ！」という満足感を得たいのでもなければ、もはやわざわざこの本を読まなくてもいいと思う。重要なトピックごとに、もっと深く掘り下げていてこれほど長くはない本がある。特に、良いコードを書くための知識については「リーダブルコード」のほうが良いと思う。 Code Complete 第2版 下 完全なプログラミングを目指して 作者: スティーブマコネル出版社/メーカー: 日経BP社発売日: 2014/04/02メディア: Kindle版この商品を含むブログ (9件
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
最近読んだもの - @kyanny's blog
CSS再入門 - できる！中央寄せ 5 | CodeGrid 今回もよかった。今まで全く意味がわからなかった translate を使ったものがどういう仕組みか理解できた。 The One Skill That Beats Talent Every Time — On Breaking the Mold — Medium コミュニケーションと有言実行について。概ね同意。 コミュニケーションは非同期でも成り立つ、と考えているのは自分を含めごく一部の人間集団だけだ、という意識があると心構えができる。電話をかけて相手が出なかったらイラっとするように、メールやチャットの返事が即座に返ってこないことを「あたりまえ」とは考えない人が世の中にはたくさんいるのだ。 グループチャットができるソフトウェアは、その点で立ち位置がぶれているとも思う。非同期コミュニケーションを謳っておきながら、同期が期待されるプラ
Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
破れ紙の片割れのようなMixinができてしまうワケ - @kyanny's blog
最近「Mixin は避けられれば避けたほうがよいのではないか」と思い始めている。扱いに困るダメ実装の Mixin を簡単に作れすぎてしまうからだ。 Wikipedia の定義によると、 mixin とはオブジェクト指向プログラミング言語において、サブクラスによって継承されることにより機能を提供し、単体で動作することを意図しないクラスである。 とのことなので、そもそも Mixin される側の実装と結びつきが強くなるのは仕方ないのだろう。しかし、まれにだが破れ紙の片割れのような実装を持つ Mixin ができてしまうことがある。 一枚の紙を適当に手で破って二枚にする。断面はギザギザだが、破った二枚の紙の断面はぴったり一致する。もともと繋がっていたものを切り離したのだから当然だ。だが破れ紙の断面にぴったり合うような別の紙を用意するのは簡単ではない。別の紙を合わせる必要があるのならば、紙を破るときに
SNS 見るのやめた - @kyanny's blog
昨年末から SNS を見るのをやめた。目的は精神の平穏を保つため。誰が退職しただの、誰が本を書いただの、誰と誰が寿司を食っただの、そういう業界ゴシップで心惑わされるのに疲れ果てた。知る価値のある情報もたくさんあるが、 S/N 比が悪くなりすぎた。 また、 SNS に愚痴や攻撃的なことを書いたりしてしまうのもやめたかった。傍目に悪いし、書いてスカッとするわけでもない。いつか炎上するかもと内心びくびくしながらやめられない様はまさに中毒だった。 具体的にやったことは以下。 iPhone から Twitter と Facebook その他 SNS のアプリを削除した。隙間時間についつい見てしまう・書いてしまうのはこれで克服できた。 SNS からの通知メールをできるだけオフにした。特に効き目があったのははてなブックマークのマイホットエントリーお知らせメールで、自分にとって最大のゴシップ情報源になって
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
JavaScript で if 文を書くとき必ず波括弧を書くべきと主張しているスタイルガイド - @kyanny's blog
新人さんの JavaScript のコードレビューをしていて、 if 文の本体部分を波括弧で囲っていないコードを見つけた。 おれは本体が一行しかなくても必ず波括弧で囲うようにしており（そのほうがわかりやすいと思っているから）、できればそうして欲しいけど個人の好みを押し付けるのはよくないので、広く支持されているコーディングスタイルガイドの類いで同様の主張をしているものが無いか探した。 Google とか Mozilla とか GitHub あたりのドキュメントを眺めてみたが if 文の波括弧についてはっきり言及している箇所を見つけられずにいたら、該当するドキュメントをいくつか教えてもらった。 http://contribute.jquery.org/style-guide/js/#spacing if/else/for/while/try always have braces and alw
Git Golf, Git Kata あるいは Git-99 - @kyanny's blog
今日の #shibuyarblunch で「詰めvi のような git の練習問題が欲しい」という話で盛り上がった。正解の操作をなぞる -> 詰めvi -> 手数を競う？ -> Code Golf だ！という流れで Git Golf と呼んでいたけど、競技性は重要ではないし、 Code Kata に例えたほうが適切なのかもしれない。あるいは L-99 か。 レポジトリと「トピックブランチをマージせよ」のようなお題が与えられて、指示を満たすように git の各種コマンドを使ってレポジトリをいじる。操作の練習が目的なので、答え合わせは適当でいい。 git log --graph の結果を見比べる、とか。最初は簡単なのからはじめて、徐々に難しくなっていく。あまりお目にかからないシチュエーションのお題で、そうそう使わないようなコマンドを使う、組み合わせる、など。 バージョン管理システムはプログラミ
大江戸Ruby会議01に行ってきた - @kyanny's blog
大江戸Ruby会議01 - Regional RubyKaigiに行ってきた。 Asakusa.rb の皆様、発表者の皆様、ありがとうございました。とても楽しかった。以下、例によって感想をつらつらと。 100.times { Asakusa.rb.meetup! }, @a_matsuda コミュニティとは、みたいな話が聞けたのがよかった。自分が勉強してスキルアップしたい、ではなくて、 Ruby や Ruby を取り巻くもの（もちろん人も）に関心があるひとたちの集まり、という。 Asakusa.rb のような「コミュニティ」にはもともと憧れがあって、いいなーでも家からも職場からも遠いし・・・とか思っていたんだけど、一度行ってみたいと思ったし、それ以上に「じゃあ自分が近場で仲間を集めて何かすればいい」と強く思った。で、懇親会や帰り道で @mori_dev さんと @1syo さんにそれぞれ別
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
