リモートで働く開発者が行うとよいたった二つの習慣 - @kyanny's blog
チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で返事をはやく返す チャット・Issue Tracker・メール等の非同期コミュニケーションツール上で自分の状況をこまめに報告する 目安としては、 1 on 1 チャットは 30 秒以内・パブリックチャットのグループ mention （@here みたいなやつ）は 1 分以内・パブリックチャットの mention なし不特定多数向けメッセージは 3 分以内・それ以外のものは 24 時間以内に返事をするとよい。これより遅いと、「自分が返事をしないせいで相手を待たせてしまい、ストレスを与えたり仕事が進まない原因を作っている」ということになってしまう、と思っておくのがよい。 1は第一には「相手を待たせない」ためだが、まめに返事をしてあげていれば逆の立場になったとき自分もまめに返事をしてもらえることがあるので、自分自身
Qiita::Team やめた - @kyanny's blog
Quipper 日本オフィス（+ 海外オフィス勤務の日本人）で「チャット以上 Wiki 未満」な情報共有ツールとして二年ほど使ってきた Qiita::Team をやめて、 GitHub Issues に移行した。 Qiita::Team は日本人の間では活用されていたが、グローバル企業なので英語以外のみでの情報共有は好ましくなく、しかも Qiita::Team は個別に invite しないとアクセスできないので海外拠点のスタッフにとっては非常に閉鎖的な場だった。せめてアクセス可能にしようと plan をアップグレードし invite したものの、国際化対応が不十分だったりそもそも日本語の文章を翻訳して読もうというガッツもなかったりして、日本人以外には活用されなかった。 Quipper は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して
Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
#isucon2 に参加しました - @kyanny's blog
#isucon2 に参加しました。とても楽しかったです。ありがとうございました。最終スコアは五位という結果に終わりましたが、うまくいったこともダメだったこともひっくるめて自分の実力は出せたので過程には満足しています。 事前準備 昨年の isucon では雰囲気に飲まれてほとんど何もできないままタイムアップを迎え、不本意な結果に終わりました。今年は去年の反省を踏まえて、チームメイトの @kentaro さんと @tnmt さんと事前にある程度の方針を決めて臨みました。 言語は基本 Ruby を選ぶ。仕事で使っているし、アプリケーションサーバの運用や rbenv などの周辺ツールの扱いにも慣れているので。とにかく手に馴染んだものを選ぶ。「なんとなくはやそう」みたいな曖昧な理由で node を選んだりしない。 コードは GitHub にでも置いて、 Capistrano で一発デプロイできるよう
YAPC::Asia Tokyo 2012 - @kyanny's blog
今年も YAPC::Asia Tokyo 2012 に参加してきました。 今年は春夏と仕事が忙しく、また札幌Ruby会議2012の準備もあったので本トーク・ LT ともに応募せず、お客さん状態での参加でしたが、そのぶん気楽に過ごせました。元同僚とたくさん会ったのはもちろん、数年前にオフ会で会った方との再会もあり、その他にも久しぶりにお会いする方ばかりで、今年の YAPC::Asia は自分にとってはまるで同窓会のように感じられました。 今年はペパボから計四名、うちニ名は初めての発表でしたが、いずれも嬉しいことに大盛況で、この調子でもっとたくさんアウトプットする人を増やしていきたいと思いました。また、ペパボの社長とブクログの社長が応援に来ていたのですが、同僚のトークの合間をどう過ごすか迷っていたので竹迫さんのトークを薦めたら楽しんでもらえたようで良かったです。 所要で二日目は午後からの参加だ
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 になる。日本向けのウェブサイトで
最近のペパボの技術書読書会について - @kyanny's blog
最近ペパボでは Lean とかアジャイルとか開発プロセスの改善に関する取り組みが活発で、具体的にどんなことをやっているかは antipop さんと hsbt さんのブログにたくさん書いてあるのですが、そういう全社的な取り組み以外にも有志による読書会・勉強会などもちょくちょく開催されています。 その読書会が今日ひとつ終了しました。以前このブログでも紹介した Working with UNIX Processes をかいつまんで読みました。だいたい週一のペースで一章ずつ、半分くらいの章をピックアップしたので二ヶ月ほどかけたのかな？ 職場での『Working With Unix Processes』読書会、本日終了した。— 北市真 (@KitaitiMakoto) July 11, 2012 次は Crafting Rails Applications を早速来週から読み始めます。その後も Ra
第1回Ruby開発環境勉強会 - @kyanny's blog
第1回Ruby開発環境勉強会 - delirious thoughts http://kentaro.hatenablog.com/entry/2012/05/29/230254 という勉強会があったので、「見よう見まねでカスタマイズしてもどうせ使いこなせないからギリギリまでやらなくてよし」などという意識の低い感じの話をしました。 スライドには書いてないこともけっこう喋ったので捕捉: リファレンスマニュアルについて Emacs (anything) から perldoc とかるりまとか引けるようにしたこともあるけど、コマンド名やキーバインドを覚えられず定着しませんでした。あと、用例も見たいので結局ほかのページもぐぐることになり、もうブラウザでいいや、というのが今のところの結論です。わざわざキーワードを当てたのは、「赤い背景」のページばかり上位に出てくるのが嫌だったからで、単にキーボードから
「あとで捨てることになるコードのテスト」について - @kyanny's blog
同僚とこんな話をした。 例えば「キャンペーンサイトとプレゼント応募フォーム」のような、一時的にしか使わないことがわかっているコードに対するテストをどの程度書けば良いのか？納期は迫っていて、他にもっと優先度の高い仕事もあるとする。最低限 200 が返ってくることだけをテストすれば良いのか、 POST したらどのようなリソースが作られるかまで厳密にテストすべきなのか。 そのとき述べた僕の意見を書いてみる。 追記 同僚の名誉のために補足すると、その時は「不安な部分をテストすべき」という当たり前な結論に落ち着いたのだけど、そもそも詳しく聞いてみたら「僕ならここは不安だから書くと思う」と考える部分については、彼はすでに書き終えていて、その上でさらに厳密にテストを追加すべきだろうか？という問題意識を持っていた、という。なので、以下に意識高そうなことをつらつら書いているけど、同僚氏のほうが僕よりよっぽど
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
シニアエンジニアになりました - @kyanny's blog
今年から始まったペパボの新しい人事評価制度で、技術者 (エンジニア) にはシニアエンジニア・アドバンスドシニアエンジニアといういわゆるスペシャリスト枠ができたのですが、最初の評価プロセスが終了したこの四月から、シニアエンジニアとして働いています。 ペパボの技術者向け評価制度については Paperboy's engineer evaluation system - Gosuke Miyashita と paperboy is hiring - Gosuke Miyashita に詳しいので、ご存じない方はぜひご覧ください。 スペシャリスト枠については、毎年恒例の社内プレゼン大会 P-1 グランプリでのアイデア発表があったあと、個別にヒアリングをしていただき、他社も含めてエンジニア職の待遇がどのようになっているかを踏まえて、どういう制度・運用が望ましいか意見を述べたこともありました。自分が評価
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ページを開く
