ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
Rockstars / superstars - @kyanny's blog
仕事柄エンジニアの評価制度とかのことも考えないといけないのだが、以前から同僚が「二つのタイプの人がいる、 Rockstars と superstars だ」と言っていて、そのときはピンとこなかったのだが後日シェアされた記事を（重い腰をあげて）読んだら合点した。 Rockstars: 安定して着実な成長を求める。ワークライフバランスを重視するとも言える。決して仕事ができないというわけではなく、任された領域においては十分な仕事をして成果もあげているのがポイント。 Superstars: 急激な成長を求める。常にチャレンジングなことに取り組んでないと飽きるタイプともいえる。興味を持って没頭できる仕事を与えられると大きな成果をあげるので、このタイプのほうが「成長して成果を出した」とみなされやすい。 最初にこのアイデアについて聞いたとき、安定を求めるタイプをロックスターと呼ぶのに違和感があったが、ど
「Management 3.0 〜良いフィードバックと給料を与える方法〜」に参加した - @kyanny's blog
「マネジメントって本当に必要かなぁ。。」と日々疑問を感じているので（する側としてもされる側としても）、何か得るものがあればいいなと思って参加した。 ワークショップもプレゼンテーションもなかなか良かった。三点にはまとめきれないので、箇条書き。 チェックイン（アイスブレイク）のために行ったムービングモチベーターズ・ゲームはシンプルで良かった Management 3.0 については、「自己組織化されてて裁量の大きいところで働くほうがいい、ってのはみんなわかってるよなぁ。でも現実にそうしていく難しさがあるんだよなぁ。『フレームワークではなく概念』らしいから、みんなが共通理解を確認しながら継続して改善していく取り組みが大切、ということなのかなぁ」と思った フィードフォースの鈴木さんによる事例紹介のなかで挙げられていた ADKAR （変革管理）の話が素晴らしく、目から鱗だった。要は丁寧に段階を踏まな
GitHub の通知を見直す - @kyanny's blog
GitHub の通知をメールで受け取って Gmail で処理していたが、年初のタイミングなので見直すことにした。 Inbox zero をキープすることが前提の運用なので、メール処理に時間をかけてきたが、通知されるリポジトリや条件を絞ったところで大半の通知の中身はろくに読まなかった。単に読み飛ばして既読アーカイブするだけでも一回で何分もかかるし、その中から読むべき・反応すべき内容を見分けるコストが高くなりすぎた。メインブラウザを Firefox にしたら Gmail 上で j/k で移動する速度が遅くなって効率が悪化したのも一因。 とはいえメールで受け取っていると将来検索するときなどにやや安心、というのも経験上あるので、メール通知は受け取るが Gmail のフィルタで既読アーカイブすることにした。 合わせて、 Sentry など仕事で利用しているサードパーティーサービスからの通知も一旦切っ
Quipper に入社して丸4年が経った - @kyanny's blog
blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき
エンジニア立ち居振舞い: 作業の進捗をチャットに逐一報告する - @kyanny's blog
お題「エンジニア立ち居振舞い」 同じく GitHub の通知はだいたい目を通してる。流量が多くてブラウザで開いてられないので Gmail で読み流して気になるやつだけ見に行くようにしてる。 GitHub の通知を見る専用のアプリを使っていないのは、 GitHub 以外のサービスからの通知とか、ごくわずかだけど外部の関係者とのメールとかもあってメールを一切見ないわけにはいかないので、だったらいっそ Gmail 一本にしたほうが楽だし見落としが無くて安心だと思ったからです（なので inbox zero を気合で実践してる） で、気をつけてることで、まだお題で書かれて無さそうだったのがこれです↓ 作業の進捗をチャットに逐一報告する production 環境のデータを修正するとかそういう運用系のタスクというのがけっこうあって、たいてい rake タスク + Jenkins job みたいなのを用
なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか - @kyanny's blog
ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を
最近思ったこと - @kyanny's blog
ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。 おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。 そのシステムが実現するビジネスにおける仕様について（仕様書なのに）触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不
RubyKaigi 2015 - @kyanny's blog
二日目の夕方からと三日目の二コマ目から参加した。 この一年ほどは Ruby/Grape,Rails よりも CoffeeScript/Backbone,Marionette を書いてる時間の方が圧倒的に長く、仕事以外でも特に面白いものを作らなかったので、トークに応募しなかった。準備せず手ぶらで参加するだけのカンファレンスは、ラクだけどやっぱりどこか物足りないなと思った。もっとも、この冬の忙しさでは準備できたとも思えないが。 今年は「Ruby にこだわる」姿勢というものを感じるトークが多かった（自分が聴いたものの中では）特に mruby は、数年前に出てきたときは全然ピンとこなかったけど、今年はなぜか「Rubyist ならパフォーマンスが出ないからとかいって Go なんか選ぶんじゃなく Ruby でパフォーマンスを出す方法を考えるのが筋だろ？」と言われているような気がして身が引き締まる思いだ
autodoc その後 - @kyanny's blog
二年前に autodoc を導入したが、現在はもはや誰も見てないし使ってないね、という話を社内でしたら、「使い始めた話だけじゃなくて、やめちゃった話もブログに書くべき」と指摘され、確かに誠実な姿勢とはいえないなと反省したのでこの記事を書いています。 恥を忍んで現状を明かすと、 master ブランチに push されたタイミングで実行される Jenkins のジョブが半年ずっと fail していた、ということに昨日気づいた体たらく。そもそも生成された markdown ドキュメントを push していたリポジトリがとっくの昔に削除されていたと思っていた。 うまくいかなかった原因の分析: Quipper の Internal API は非常に込み入ったデータ構造を返すものがほとんどで、お世辞にも「きれいな RESTful API」とは言えない。なので request spec を書く際に、完
リモートで働く開発者が行うとよいたった二つの習慣 - @kyanny's blog
チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身
let の書式の覚え方 - @kyanny's blog
(let ((a "A")) (print a)) いきなりこれをみると「なぜ (a "A") ではなく ((a "A")) なのか」が理解できず、混乱する。以下のように考えるとすっきり覚えられる。 ;; 一番シンプルな形はこれ。 a は nil (let (a) (print a)) ;; a の初期値を与えるために (a "初期値") という書式が必要 (let ((a "A")) (print a)) ;; 初期値なしならこう書ける。 a, b ともに nil (let (a b) (print (list a b))) ;; 初期値ありだとそれぞれ (a "初期値") (b "初期値") と書く (let ((a "A") (b "B")) (print (list a b))) ;; 初期値ありと初期値なしが混ざってもよい (let ((a "A") b) (print (lis
Gem のバージョンを比較する Gem のメモ - @kyanny's blog
去年 compare_linker という Gem を作り、 RubyKaigi で発表もしたが、作って力尽きてしまった感があった（その後このプロジェクトは masutaka さんが引き取った）。 そもそもやりたかったことは「Gem のバージョンを比較して Diff を読むのを楽にしたい」ということで、そういうのを実現するツールは他にもちらほら見かけてきたもののちゃんと試してなかったな、と思いだして、というか Ruby Weekly にそういうのが一個載ってたので、少し調べた。ので忘れないように（むしろ忘れてもいいように）メモ。 fedora-ruby/gem-compare · GitHub メタ情報の差分しか表示されず、ソースコードの Diff が読めないのでいまいち。 teeparham/gemdiff · GitHub これはだいぶやりたかったことに近い。 compare_link
人工知能は人間を超えるか ディープラーニングの先にあるもの - @kyanny's blog
すごく面白かった。人工知能研究の歴史とそれぞれの時代の課題がとてもわかりやすく解説されていて、まさに「本には先人の叡智が詰まっている」を体現した一冊だと思う。機械学習とディープラーニングがなぜ今注目されているのか、それらの技術のどこにこれまでと違う強みがあるのか、そういう専門的な内容も易しく説明されており、良書だと感じた。 ただ、副題にもなっている第6章、そして終章は、日本の人工知能研究を背負う立場もあるのかやや大局的な話になってしまい、5章までの充実した内容と比べると息切れした印象を受けた。それから、 Kindle 版の表紙イラストはちょっと「オタク（サブカル）」っぽすぎて、せっかく良い本なのにアニメ絵のせいで敬遠されたらもったいないな、と思った（実際、自分もなんどか Amazon のおすすめ等で見かけて興味を持っていたものの、表紙をみて買うのを躊躇していた） しかしあとがきを読んで、こ
次の5年のロールモデルが見つからない - @kyanny's blog
自分にできる範囲の努力では「注目されない凡人」から脱却することはできないのだ、ということをようやく渋々認める気になり数ヶ月経ったが、ではこの先自分はどういう風になっていくのか？を考えたとき、ロールモデルと呼べるような存在が見つからず少し困っている。 「カッティングエッジなことをやっていて際立つ存在」を目指したいと思っていたときは前例に事欠かなかったが、平凡だがすごいと思える存在、というのは想像することすらちょっと難しい。自分のいままでの価値観では、すごいと思える部分があったらすでに平凡ではないからだ。 いまさら「スクラムおじさん」みたいな方向性に行くのも気が進まない。そういうことが好きでやりたいと思っているわけではないのに、技能だけで勝負できなくなったから長年の経験みたいなものを活かせるロールに立場を変える、というのは天下りみたいで格好悪く感じ、少なくとも自分はそうなりたくはない。 当面
知見は Evernote ではなくブログに書いた方がよい - @kyanny's blog
より正確に言うと、知見はプライベートな領域ではなくパブリックな領域に書いた方がよい。プライベート領域は Evernote に限らないし、パブリック領域もブログに限らない。 パブリックな領域に書く場合、プライベートな領域に書くのに比べて第三者の目を意識するぶん文章を推敲する機会が増える。 単に読み直すだけでも頭の整理に効果的だが、さらに正確を期すため調査や検証をすることもあるだろう。プログラミングのことであれば検証コードを書くとか、ツールのことであればドキュメントやソースコードを読むとか。そうすることにより、周辺領域も含めて理解が深まる。 また、公開に耐える内容にするために一般化する必要もあり、その過程で問題の本質をより正確に把握できる。 つまり、パブリックな領域に書く方が自分自身の勉強になる。 もう一つ、パブリックな領域で公開することで、他人が書いたより良い情報と競わせられる、というのがあ
Rails が params をネストしてくれる仕組みは ActionController::ParamsWrapper が実現している - @kyanny's blog
アレがどのように実現されてるのか、あとネストしたハッシュのキーにあたる文字列は単数形になるものなのか複数形になるものなのか、理解しておらず不思議がっていたら同僚が調べてくれた。復習がてらメモ。 結論 一連の仕事は ActionController::ParamsWrapper がやっている ネストされたハッシュの root key の名前は（おおざっぱにいうと）コントローラ名から切り出したモデル名の lower case になる。つまり（ほぼ）必ず singular （単数形）になると考えてよい。 参考コード1 参考コード2 以下、例。 コントローラとモデルの定義とルーティング class User < ActiveRecord::Base end class UsersController < ApplicationController end Rails.application.rou
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Slack の channel topic に頻繁に開くページの URL を貼っておくと便利 - @kyanny's blog
Ruby の i18n gem を pry コンソールから初期化したり I18n.t を実行したりする - @kyanny's blog
WIP Pull Request Unhighlignter for GitHub v2.2.1 をリリース - @kyanny's blog
