採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
Quipper に入社して丸4年が経った - @kyanny's blog
blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき
次の5年のロールモデルが見つからない - @kyanny's blog
自分にできる範囲の努力では「注目されない凡人」から脱却することはできないのだ、ということをようやく渋々認める気になり数ヶ月経ったが、ではこの先自分はどういう風になっていくのか？を考えたとき、ロールモデルと呼べるような存在が見つからず少し困っている。 「カッティングエッジなことをやっていて際立つ存在」を目指したいと思っていたときは前例に事欠かなかったが、平凡だがすごいと思える存在、というのは想像することすらちょっと難しい。自分のいままでの価値観では、すごいと思える部分があったらすでに平凡ではないからだ。 いまさら「スクラムおじさん」みたいな方向性に行くのも気が進まない。そういうことが好きでやりたいと思っているわけではないのに、技能だけで勝負できなくなったから長年の経験みたいなものを活かせるロールに立場を変える、というのは天下りみたいで格好悪く感じ、少なくとも自分はそうなりたくはない。 当面
Mac の プレビュー.app で円切り抜きハイライト画像を作る方法 - @kyanny's blog
↓こういう風にハイライトしたい部分だけくり抜いた画像を作る方法（それ以外の部分にマスクをかけて目立たせなくする方法）。こういう画像をなんと呼ぶのか知らないので言葉でうまく説明できない。呼び方をご存知の方は教えてください。 Mac OSX 10.9.5 の プレビュー.app バージョン 7.0 (826.4) です。 元画像 この画像の左上のプロフィール部分だけ目立たせたい。そこ以外の部分を暗くすることでハイライトさせたい。 作り方 1. 楕円選択してCmd+xでハイライトしたい箇所を切り抜く 2. 不透明度50%の黒塗りつぶし長方形を全体にかぶせる 3. 切り取った部分をCmd+vで貼り付ける 貼り付けると切り取られた部分が半透明の黒い長方形より上のレイヤーに来るので、ちょうどくりぬいた部分の真上に来るようにがんばって位置を合わせる。残念ながらぴったり位置を合わせてくれるガイドアシスト機
rbenv + ruby-build を system-wide にインストールする - @kyanny's blog
rbenv と ruby-build 便利ですね。しかし ~/.rbenv 以下にもろもろ入ってしまうと都合が悪いこともあるので system-wide に、 /usr/local 以下とかにインストールしたい (そして複数ユーザーで同じ rbenv 環境を共有したい) のでやり方を調べた。 だいたい Shared install of rbenv のとおりでいける。たぶん /usr/local/rbenv/shims と /usr/local/rbenv/versions を自分で掘るのがポイント。これで rbenv install 1.9.3-p0 とすればうまいことインストールされる。 というわけで手順をコピペするのが面倒くさいのでインストーラのシェルスクリプトを書いた。 root で実行してください。 https://gist.github.com/1727338 Wiki ページ
GitHub's Markdown Rendering API compatible API - @kyanny's blog
Today I launched GitHub's Markdown Rendering API compatible API. http://gfm-kyanny.sqale.jp/ (Hosted by Sqale : ) This is a markdown rendering API service compatible with GitHub's Markdown Rendering API. Pros No Rate Limit (almost) compatible with GitHub's Markdown Rendering API API endpoint path is same Input data format is compatible Cons Does not support GitHub integration mode parameter will b
Jenkins に bundle update した上で Pull Request させる - @kyanny's blog
皆さん bundle update してますか？ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン
#isucon2 に参加しました - @kyanny's blog
#isucon2 に参加しました。とても楽しかったです。ありがとうございました。最終スコアは五位という結果に終わりましたが、うまくいったこともダメだったこともひっくるめて自分の実力は出せたので過程には満足しています。 事前準備 昨年の isucon では雰囲気に飲まれてほとんど何もできないままタイムアップを迎え、不本意な結果に終わりました。今年は去年の反省を踏まえて、チームメイトの @kentaro さんと @tnmt さんと事前にある程度の方針を決めて臨みました。 言語は基本 Ruby を選ぶ。仕事で使っているし、アプリケーションサーバの運用や rbenv などの周辺ツールの扱いにも慣れているので。とにかく手に馴染んだものを選ぶ。「なんとなくはやそう」みたいな曖昧な理由で node を選んだりしない。 コードは GitHub にでも置いて、 Capistrano で一発デプロイできるよう
Rails と時刻 - @kyanny's blog
時刻の扱いは難しい。タイムゾーンを跨ぐと格別に難しい。 Rails を使っていても難しさに変わりはない。むしろ時刻のやっかいな部分を隠蔽してくれるが故に余計にややこしくなることもある。 config.time_zone と config.active_record.default_timezone Rails アプリケーションで時刻を司る代表的な設定値は config.time_zone と config.active_record.default_timezone だ。いずれも config/application.rb で設定できる。詳細は Ruby on Rails Guides: Configuring Rails Applications 参照。 config.time_zone でアプリケーションのタイムゾーンを設定する。デフォルトでは UTC になる。日本向けのウェブサイトで
「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 の挙動
curl(1) で POST する際の --data と --form の違いについて - @kyanny's blog
調べてみた。動作確認用のサーバは plackup で立てている。 app.psgi の中身は一番最後に。 --data (-d, --data-ascii) application/x-www-form-urlencoded 形式で POST する。 @/path/to/file のように value の先頭が @ ではじまっているとファイルを読み込んで改行文字を取り除く。パラメータや @ つきで指定したファイルの中身はすべて URL エンコードされていることが期待される。つまり curl(1) は URL エンコードしてくれない。 -d を複数回指定するとすべてのパラメータが & で連結される。 @ でファイルを指定する場合、 -d 'file=@sale.txt' のようにすると中身が展開されないので注意 (file=@sale.txt という文字列が渡される) $ curl -d '
bundle のなかで bundle する - @kyanny's blog
Bundler.with_clean_env と bundle install --gemfile について追記しました bundle exec した環境下でさらに bundle exec したいことがある。 bundle exec rake resque:work で起動した Resque ワーカーのなかで system("bundle exec rake spec") のような外部コマンドを呼び出すとか。ありますよね。ぼくは最近ありました。そしてハマった (そしてググりづらかった) のでこれ以上犠牲者を増やさないためにブログに書く。 bundler は実行時にいくつかの環境変数を定義するが、この場合問題になるのは BUNDLE_GEMFILE と GEM_HOME だ。 BUNDLE_GEMFILE は bundler が参照する Gemfile のパスで、 GEM_HOME は ge
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tig でいま見ているコミットをブラウザで開く - @kyanny's blog