採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
Qiita::Team やめた - @kyanny's blog
Quipper 日本オフィス（+ 海外オフィス勤務の日本人）で「チャット以上 Wiki 未満」な情報共有ツールとして二年ほど使ってきた Qiita::Team をやめて、 GitHub Issues に移行した。 Qiita::Team は日本人の間では活用されていたが、グローバル企業なので英語以外のみでの情報共有は好ましくなく、しかも Qiita::Team は個別に invite しないとアクセスできないので海外拠点のスタッフにとっては非常に閉鎖的な場だった。せめてアクセス可能にしようと plan をアップグレードし invite したものの、国際化対応が不十分だったりそもそも日本語の文章を翻訳して読もうというガッツもなかったりして、日本人以外には活用されなかった。 Quipper は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して
SNS 見るのやめた - @kyanny's blog
昨年末から SNS を見るのをやめた。目的は精神の平穏を保つため。誰が退職しただの、誰が本を書いただの、誰と誰が寿司を食っただの、そういう業界ゴシップで心惑わされるのに疲れ果てた。知る価値のある情報もたくさんあるが、 S/N 比が悪くなりすぎた。 また、 SNS に愚痴や攻撃的なことを書いたりしてしまうのもやめたかった。傍目に悪いし、書いてスカッとするわけでもない。いつか炎上するかもと内心びくびくしながらやめられない様はまさに中毒だった。 具体的にやったことは以下。 iPhone から Twitter と Facebook その他 SNS のアプリを削除した。隙間時間についつい見てしまう・書いてしまうのはこれで克服できた。 SNS からの通知メールをできるだけオフにした。特に効き目があったのははてなブックマークのマイホットエントリーお知らせメールで、自分にとって最大のゴシップ情報源になって
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 で一発デプロイできるよう
「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
今年から始まったペパボの新しい人事評価制度で、技術者 (エンジニア) にはシニアエンジニア・アドバンスドシニアエンジニアといういわゆるスペシャリスト枠ができたのですが、最初の評価プロセスが終了したこの四月から、シニアエンジニアとして働いています。 ペパボの技術者向け評価制度については 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
渋谷.rb[:20120215] で Ramaze と Sequel について発表しました - @kyanny's blog
渋谷.rb[:20120215] で Ramaze と Sequel について発表しました。ありがとうございました。 http://speakerdeck.com/u/kyanny/p/shibuya-rb-20120215-ramaze-sequel まとめだけ書くと、 Ramaze は覚えることが少ない・全容を把握しやすいのがよい Sequel は dataset がとてもよい。 SQL 的な「行の集合」を集合のまま扱えるので (行オブジェクトの配列ではなく) どちらも使い始めるまでの設定とか前提となるものをほとんど必要としないので、プロトタイプ作りとか、思いついて 10 分後には飽きてしまいそうな小さいコードをちゃちゃっと書くのに向いてると思いました (ちなみに一緒に参加した同僚は「むしろ二層のモデルの上層部分を dataset の表現力でカバーしたり DataMapper パターン
![渋谷.rb[:20120215] で Ramaze と Sequel について発表しました - @kyanny's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/08da6727a426508f9f301e23c2b2951496cabd1f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729888747%2F12704346814673929549%2F1329320835)
■ - @kyanny's blog
奥さんの甘え方がひどい。 「はいはいリア充乙」と思ったひとは購読停止をクリッククリック 最近奥さんが過度に甘えてくるのを我慢できずに怒ってしまうことがよくある。帰宅して夕食後の時間が特にそうで、さあこれから自由時間だぞと思っておもむろにノート PC を開き、今日はあのライブラリを試してみようか、それともあそこのドキュメントを読んでみようかとやり始めると途端に邪魔をしてくる。 今日は「OAuth 認証の仕組みや実装について疎いので、 Twitter のドキュメントを読みながら理解を深めよう」というテーマで https://dev.twitter.com/pages/auth などを読み始めたら、ものの10分もしないうちにやれお茶を飲みたいだのやれ寒いから羽織る物が欲しいだのと言い出してちょっかいを出してくる。本人がそれをできない理由は一切なく、面倒くさいわけですらない。単におれが自分に関心を
info ページを Kindle で読む - @kyanny's blog
man ページを Kindle で読む に続いて info も読んでみた。 texi2html => kindlegen という流れ。ちょうど homebrew を入れたところなので GNU coreutils (cp|gcp) と GNU findutils (xargs) も入れておく。 info -w name で info ファイルのパスが得られるが、どうもこれで得られるファイル（/usr/share/info/bash.info など）は texinfo 形式ではないらしく texi2html で変換できなかった。読みたかったのは Emacs 関連の info だけだったので emacs-23.2.tar.gz を拾ってきて展開し、 doc/ 以下にある *.texi を変換した。 brew install coreutils brew install findutils cd
man ページを Kindle で読む - @kyanny's blog
数年前から、外出先で man ページを読めたらいい暇つぶしになるだろうなと思っていた。 iPhone の Safari から http://www.linux.or.jp/JM/index.html を眺めてみたことはあったが、ディスプレイが小さすぎて辛かった。 しかしいまやおれの手元には Kindle がある。 Kindle なら快適な man 閲覧環境になるんじゃないかなと思って試してみたら思った通りいい感じだった。 KindleGen というプログラムが配布されていて、これを使うと HTML ファイルを .mobi 形式に変換できる。幸い man2html というプログラムも存在するので、これを組み合わせて man2mobi というプログラムを作ってみた。 http://github.com/kyanny/man2mobi/blob/master/man2mobi 実行すると引数で指
30days Album for mixi をリリースしました - @kyanny's blog
2010年7月1日に 30days Album for mixi をリリースしました。ペパボ初の mixi アプリです。無料です。 プレスリリース お知らせブログ アプリの紹介 30days Album のアルバム機能をそっくりそのまま mixi アプリにしちゃいました。全部 Flash でできています。このプロジェクトのために期間限定でチームにジョインしてくれた強力な助っ人 [twitter:@hawaiiantime] がゼロから作ってくれました。サンキュー！ 30days Album 本家との大きな違いは、合い言葉なしでマイミクとアルバムを共有できることです。親しい人たちと写真を共有したいという 30days Album の本来のコンセプトと、親しい人たちと繋がっている mixi のソーシャル性をいい感じにミックスできたのではないかなと思っています。パソコンに不慣れな人にも悩まずに使
Nobody should not assert his/her rights by donation. (寄付は権利を主張するためのものではない) - @kyanny's blog
Tetsuya Kitahata wrote an article about trademark of Perl in Japan. He said: I often donated to TPF and other major Open Source Software projects. I was angered by people who say to me "you are unrelated to TPF" and "you are selfish". Have you an experience donation? It's you who are unrelated! http://tetsuya99.wordpress.com/2010/06/23/perl%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%97-by-%E5%8C%97%E7%95%A0
フォトストレージの写真を簡単にブログへ投稿できる「デイズブログ」がはじまりました - @kyanny's blog
30days Album™ のフォトストレージにアップロードした写真を簡単に JUGEM へ投稿できる「デイズブログ」がはじまりました。月額525円の PRO プラン向けの機能ですが、15日間の無料お試し期間がありますので、是非一度使ってみてください。 リリースのお知らせは、こちら デイズブログをリリースしました！ | 30days Album Information 詳しい説明は、こちら デイズブログの特長 | 写真共有サービス 30days Album 登録から投稿までの流れを説明した動画もありますよ (音は出ません) 詳しい説明や PR は公式なページに任せるとして、ここでは開発にまつわるこぼれ話などを少し。 30days Album™ は Ruby on Rails と MogileFS/Perlbal でできているという話は、ドクターペッパーで有名な技術責任者の人とか、 TENG
株式会社paperboy&co.に入社しました - @kyanny's blog
二月一日付で、株式会社paperboy&co.に入社しました。写真共有・保存サービスの 30days Album™の開発に携わります。 ずっと残せる PRO プランがふえた 30days Album™ ともども、今後ともどうぞよろしくお願いいたします。 入社に至る経緯 YAPC::Asia 2009 で mizzy さんが「勤怠管理システムが必要になったので自前で作りました」といっていたのを聞いて、当時 IE6 or 7 でしか動かない安普請の勤怠管理パッケージの扱いにうんざりしていた苦労していた僕は「これや！ワイが求めとったんはこれだったんやー！」と一目惚れしてしまいました。 というのは半分冗談で、 30days Album™ のことはローンチしたときから「カッコイイなぁ、特にトップページの写真がすごくいいなぁ、結婚式の写真めちゃめちゃいいわぁ」と思っていました。また技術的な面でも Ra
株式会社ライブドアを退職します - @kyanny's blog
私事で恐縮ですが、今月末をもって株式会社ライブドアを退職することになりました。13日が最終出社日でした。 2006年4月に入社し、3年9ヶ月在籍しました。まだ一応籍はあるはずなので過去形で語るのはおかしいかな。席はもうないかもしれないけどな！がはは！入社時のエントリはこちら kyanny のブログ : 株式会社ライブドアに入社しました 就職しました - 刺身☆ブーメランのはてなダイアリー jナントカのコメントがひどい。 古いメールを読み返してみたら、内定をいただいたのが2006年の1月12日でした。その日から数えると丸4年。僕が社会に出てから今年の4月でようやく8年ですから、社会人としての人生のうち半分を過ごしたことになります。 その日は最終面接の日でもあり、当時社長だったあの堀江貴文氏と面接で初めてお会いしました。ほんの数分間だけでしたが、その時のことは今もよく覚えています。まぁ、その後
Sledge::* のメンテナになりました - @kyanny's blog
Sledge は仕事でここ数年使ってきて、 CPAN の Sledge::* なモジュールにもお世話になってきたので、 http://d.hatena.ne.jp/tokuhirom/20091022/1256189097 をみて、消えてしまうのはもったいないし寂しいな、と思っていました。 でも思っているだけでは何も起こらないし、消えてしまってから後悔しても遅いので、思い切ってメンテナに立候補し、メンテナ権限を譲っていただけることになりました。 tokuhirom さんありがとうございました！ 残しておくことに意義があると思って名乗りをあげたので、今後どういう風に開発していくかについてはあまり考えていません。コードのレポジトリも、既存のままでいくのか、新しく github あたりに移していくのかなど、ノープランです。何かご意見のある方は、 kyanny@gmail.com とか Twitt
芸能人ブログによく見られる、本文の過剰な改行は「ファッション」に過ぎないのでは？ - @kyanny's blog
嫌な話を聞いた お金云々という話は、真偽がわからないのでどうとも言えないが、ファッションとして本文をたくさん改行するスタイルが成立しているってのは十分ありえると思う。はてなーが見慣れてないだけで。 例えば、携帯小説とか（あまり読んだことないけど）。あと、アメブロ以外で書いてる芸能人のブログも似たように改行だらけだったりする（例: http://blog.livedoor.com/star/category-4/ のトップテンを読んでみよ）。 昔のテキストサイトにあった「フォントいじり芸」みたいなもので、面白さをアピールするには <font color="red" size="20"></font> だし、かわいさをアピールするためには <br><br><br><br> だと。そういうことじゃないかな。 それと、はてブのコメントにあった「ブログの書き方はそれであっている」っていうのにかなり同
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
