Quipper のスピード感 - @kyanny's blog
先日、ブログ記事を読んでいて autodoc というツールを見つけた。 Rails の Request Spec から自動的に API ドキュメントを生成するというもの。コードとドキュメントが食い違ってしまう問題を解決できるかも、と思って試しに Quipper 社内で紹介してみた。 当初は「良さそうだね、でも今使っている API サーバー用フレームワークでは使えないようだし、こまごまと不満もあるので、いずれ Rails に乗せかえるときにでも再検討しよう」なんていう反応を予想していた。自分の担当箇所でちょっと使うくらいが関の山だろうなと。しかしその予測は見事に外れた。 紹介した当日、我々が API サーバーを書くのに使っている grape という gem で autodoc を利用するのは骨が折れそうだということがわかる。にもかかわらず翌日、 API サーバーを Rails にマイグレーシ
Submitted our CFP to RubyConf 2013 [not accepted] - @kyanny's blog
Today I and @sanemat co-submitted our CFP to RubyConf 2013 . The main topic of our CFP is about Tachikoma , an open-sourced bundle update automation tool. The concept of Tachikoma is originated by my talk of RubyKaigi 2013 . It wasn't for everyone though, @sanemat brush upped my rough idea and finally made a tool ready to use. Hopefully I want to stand up the stage on Miami, but regardless of our
![Submitted our CFP to RubyConf 2013 [not accepted] - @kyanny's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/101cd0649c790b94b8f6ee2b7d1f837503bf4ac7/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729888747%2F11696248318757272948%2F1379346285)
RubyKaigi 2013 - @kyanny's blog
RubyKaigi 2013 was finished. Thank you for the organizers, volunteer staffs, speakers, lightning talkers and all attendees. I also very thank you for the audiences of my talk. If I can give you something worth, it's my pleasure. つい忘れがち・先送りにしがちな gem の更新作業を、 Jenkins と Pull Request を使って自動化・見える化する、という内容でお話をさせていただきました。それなりに好評だったようで、ありがたい限りです。 @kenn さん @sotarok さんという有名人のツイートを引用したので箔がついたんでしょうね。快く引用を許可してく
シニアエンジニアになりました - @kyanny's blog
今年から始まったペパボの新しい人事評価制度で、技術者 (エンジニア) にはシニアエンジニア・アドバンスドシニアエンジニアといういわゆるスペシャリスト枠ができたのですが、最初の評価プロセスが終了したこの四月から、シニアエンジニアとして働いています。 ペパボの技術者向け評価制度については Paperboy's engineer evaluation system - Gosuke Miyashita と paperboy is hiring - Gosuke Miyashita に詳しいので、ご存じない方はぜひご覧ください。 スペシャリスト枠については、毎年恒例の社内プレゼン大会 P-1 グランプリでのアイデア発表があったあと、個別にヒアリングをしていただき、他社も含めてエンジニア職の待遇がどのようになっているかを踏まえて、どういう制度・運用が望ましいか意見を述べたこともありました。自分が評価
Redis の maxmemory-policy について - @kyanny's blog
Redis をキャッシュストレージとして利用する場合、 maxmemory によって利用可能なメモリの最大値を指定できる。 maxmemory の値を超えるデータの追加が発生した場合の振る舞いを maxmemory-policy によって指定できる。デフォルトの maxmemory-policy は volatile-lru で、 LRU アルゴリズムに従って古いキーの値が優先的に破棄される。 maxmemory-policy は数種類から選べるが、そのうち noeviction を選んだ場合、古いキーの値は破棄されず、新規追加はエラーとなる allkeys-lru または allkeys-random を選んだ場合、 expire の有無に関わらず、全てのキーの中から破棄対象が選ばれる その他を選んだ場合、 expire がセットされているキーのみが破棄対象となる という違いがある。実装
rbenv のメカニズム - @kyanny's blog
rbenv 環境下で実行された Ruby プログラムの中から他の Ruby プログラムを起動するときに、 rbenv 環境をリセットしたい―要するに別のバージョンの Ruby で外部プログラムを実行したい―という事情があったので rbenv のメカニズムについて調べた。 rbenv 環境下で ruby コマンドを実行するとき、実際にコンパイルされた ruby バイナリが直接実行されているわけではない。 rbenv 環境をお膳立てした上で ruby バイナリを exec するラッパーのシェルスクリプトが実行される。こういうものを binstub と呼ぶ。 binstub である ruby という名前のシェルスクリプトの中身をみてみると、最終的に rbenv exec というサブコマンドを呼び出している。 rbenv のサブコマンドはリポジトリでいうと libexec ディレクトリ以下にある。
markdown-highlight-mode.el - @kyanny's blog
UPDATE id:syohex told me that the forked version of markdown-mode is hosted on github and fixed some bugs including weird behaviour of dabbrev-expand. I checked it and confirmed it works correctly. I strongly recommend to use it instead of my poor implementation. https://github.com/milkypostman/markdown-mode Markdown is popular markup language today. Many web sites support markdown such as GitHub
Resque でジョブの実行に失敗したとき通知などをする機構の作り方 / How to write resque's failure backend - @kyanny's blog
(English version is written after Japanese version) Resque には失敗したジョブを Redis に貯めておいてエラー内容を確認したりジョブをリトライさせられる機能がある。これは Failure Backend というメカニズムで成り立っている。ジョブが失敗したらメールで通知するシンプルな Failure Backend を作りながら、このメカニズムへの理解を深めてみよう。 独自の Failure Backend を利用する手順はこうだ。 Resuqe::Failure::Base を継承したクラスを作る save メソッドを定義してその中で何か面白いことをする (メールを送るとか) Resque がその Failure Backend を利用するように設定する 例としてジョブの失敗内容をメールする Failure Backend はこ
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 で一発デプロイできるよう
LimeChat for Mac を改造して社内 SNS のアバターを表示させてみた - @kyanny's blog
ペパボには社内 SNS のタンパクというサイトがあり、ペパボスタッフはみんなこのタンパクでコミュニケーションを取っています。毎日の日報や会議室の予約、遊びや勉強会などの社内イベントの告知も全部タンパク上で行われています。そのタンパクと双璧をなす社内のコミュニケーションツールに IRC がありますが、スタッフが増えるにつれて「IRC のニックネームと本名（と顔）が一致しない」という悩みがでてきました。 スタッフみんなで知恵を出しあって解決方法を考えているのですが、「IRC にタンパクのプロフィール画像が表示されたら誰が誰かもっとわかりやすくなるのになぁ」と思ったので LimeChat for Mac を改造してみました。 kyanny/limechat at showTanpakuAvatar https://github.com/kyanny/limechat/tree/showTanpa
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
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
「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 の挙動
第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
発売から遅れること一年、ようやくウェブオペレーションを読んだ。 この本はウェブサイトの運用にまつわるさまざまなトピックを扱ったエッセイ集だが、アプリケーションプログラマにとっても得るものが多い。キャパシティプランニングや監視など、普段の仕事では馴染みの薄いことがらについて初歩的な知識を身につけるのに向いている。もっと抽象的な、姿勢や考え方について述べたエッセイも多くあり、目指すエンジニア像のお手本集としても読み応えがある。 ぼくが特に良いと思ったのは四章、十二章、そして十五章だ。四章は「リーン・スタートアップ」で一躍時の人となったエリック・リースによる継続的デプロイの話だが、思想面で見習うべき点が多かった。個人的に「リーン・スタートアップ」のブームには懐疑的で、大げさにもてはやしすぎじゃないかとちょっと白けているのだけど、エリック・リースその人自身はさすがに経験豊富な起業家であり技術者でも
Homebrew に (ささやかながら) 貢献するには - @kyanny's blog
Homebrew は GitHub 上で開発が進められているので、新しい Formula を追加するとか既存の Formula を改良するとかして upstream に取り込んでもらいたい場合も当然 GitHub を使います。 Formula Cookbook というページに詳しく作法が書いてあるのだけど長い*1ので、手元で Formula を編集し終えていざ Pull Request を送る際に気をつけるべき点だけピックアップしてみました*2。 一行目には50文字以内で要約を書く。空行を挟んでコミット内容の説明を書く。 要するに Gitのコミットメッセージに関する注意点 のガイドラインに従ってね、ということ https://github.com/mxcl/homebrew を fork する fork した自分のリポジトリに対して変更を push する Pull Request を送る
ssh localhost したら ssh_exchange_identification: Connection closed by remote host エラーでログインできない場合に疑うべきこと - @kyanny's blog
あるサーバで localhost に対して ssh したら ssh_exchange_identification: Connection closed by remote host エラーでログインできなかったので少し調べた。 /etc/hosts.allow, /etc/hosts.deny まずこのファイルを疑う。 ssh_exchange_identification: Connection closed by remote host 追記: リンク切れてたので web.archive.org のキャッシュを参照のことssh_exchange_identification: Connection closed by remote host (2009/07/21) 設定の仕方は http://www.turbolinux.co.jp/products/server/11s/user
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
