二要素認証（TOTP）のトークンをどこに保存するか問題 - @kyanny's blog
2 要素認証に 1Password を使うのはよく考えてから | はったりエンジニアの備忘録 AWSの多要素認証に1passwordが使えたけど使っちゃダメだと思った話 - Qiita TOTP のトークンを 1Password に保存するのはセキュリティ強度を弱めるので良くない、という話は知ってたので避けてたのだけど、ちょっとよくわからなくなってきた。 Windows（具体的には社有のSurface Pro）上の1passwordとiPhone上の1passwordの両方でMFAの二段階目をクリアできたということは、もうこの2段階目は特定のデバイスを持っていることに依存しないということだ。僕のIDで他のデバイスに1passwordをインストールすることができれば、さらにそのデバイスでも2段階目をクリアできる。「AWSのパスワード」と「特定のスマホ（デバイス）」ではなく、「AWSのパスワー
RuboCop リネーム騒動の所感 - @kyanny's blog
Is it time to change the name? · Issue #8091 · rubocop-hq/rubocop · GitHub Rubyists, we must do better | timriley-info The RuboCop Name Drama Redux | Meta Redux 件の騒動を知る前に「Black Lives Matter の流れに乗って名前変えたらいいんじゃねーの」とは思った 難癖をつけられて揉める前に済ませておくほうが楽そう、とか FactoryBot のことを当然思い出しながら 個人的に RuboCop は好きではなく愛着もないので、というのもある リネームしたら？という提案自体は、まぁ妥当な範囲内だと思う master ブランチやめます話もあることだし https://twitter.com/mislav/status/1270
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
チャット・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 は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して
渋谷.rb[:20150520] で「入門 React」を読んで思ったことを発表しました #shibuyarb - @kyanny's blog
shibuyarb.doorkeeper.jp LT やらせてもらいました。資料は remark.js で作りました。スライドの画面クリックで進みます。GitHub Pages でも公開しています。 What I have learnt about React so far... - Shibuya.rb 20150520 雑感 説得力を増す目的でサンプルコードを書いたが、しっくりくるようにはなかなか書けなかった Flux については全然踏み込んだ話はできなかったけど少しフィードバックをもらえてよかった remark.js 使ったらスライド作るのめっちゃ楽だった。画像のサイジングとかだけちょっと工夫が必要だけどマークダウンやっぱり楽 あと GitHub Pages で気軽に公開できて更新も簡単なので発表前にスライドの URL シェアとかも気楽にできる ただしブログに貼り付けるのは ifra
![渋谷.rb[:20150520] で「入門 React」を読んで思ったことを発表しました #shibuyarb - @kyanny's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/ff7144548d4bf866e33abc382a3dc55c619fb123/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729888747%2F8454420450095117952%2F1432208426)
Basecamp Personal - @kyanny's blog
実は Basecamp がけっこう、いやかなり好きだ。仕事では使わなくなってしまったが、以前から個人向け買い切りプランの Basecamp Personal が気になっていた。ゴールデンウィークが近づいてきてテンションがあがったのでひとつ買ってみた。 Basecamp には iOS/Android アプリもある。 Basecamp Personal は通常の月額プラン用のアカウントを持っていないと買えないが、月額料金を払って使うつもりはないため、 Basecamp Personal のみを使っている状態で iOS/Android アプリは使えるのか？が気になったのでサポートに問い合わせた。 使えるよ、という返事がきたので安心して個人アカウントを作り、フリートライアルには目もくれず Personal を買って iPhone アプリをインストールし、作ったばかりのアカウントでログインし、無事に
Speaker としての #rubykaigi 2014 を終えて - @kyanny's blog
RubyKaigi 2014 二日目 9/19 11:30 から Hall A にて <%= link_to "bundle", "update" %> - Make "bundle update" more fun to review という発表をさせていただきました。お聞きいただいた皆さん、ありがとうございました。 https://speakerdeck.com/kyanny/percent-equals-link-to-bundle-update-percent-make-bundle-update-more-fun-to-review Compare Linker というツールの紹介と、なぜそれを作ったのか、そして開発を通じて得た学び、などについて発表しました。 Compare Linker については You can review "bundle update" efficien
Single Page Application ではない場合 JavaScript コードのエントリポイントはどこにあるべきか？ - @kyanny's blog
仕事で中規模程度の Rails アプリケーションのコードベースをいじっている。このアプリはもともと app/assets/javascripts 以下に必要に応じて JavaScript ファイルを置き、適当なテンプレートファイルから直接 JavaScript の関数を呼び出したりしていた。ごく普通の Rails アプリである。 このアプリは CMS で、いわゆる「ブログの管理画面」みたいな用途で使われている。一部の機能はそれなりに込み入った UI 操作を必要としページ遷移なしに操作できる必要があるが、旧来のやり方では JavaScript コードの管理が間に合わなくなってきたので部分的に Backbone.js を導入し始めている。 最近悩んでいるのが、 Backbone.js なコードのエントリポイントをどのように呼び出すべきなのか？ということ。そもそも自分が Backbone.js
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 さんという有名人のツイートを引用したので箔がついたんでしょうね。快く引用を許可してく
Increments は和製 GitHub の夢を見るか？ - @kyanny's blog
Quipper では日本オフィスの開発者を中心に、 Qiita::Team を導入して社内のドキュメント共有を行なっている。書かれる内容は日報が多いが、技術 Tips の共有やチャットでは適切でない込み入った技術的問題を解決する議論の場としても活用している。 なぜわざわざドキュメント共有？ていうか日報書くなんてダサすぎじゃね？そう思ったあなた、日報を見くびっちゃいけません。上手に運用すればナレッジシェアやコラボレーションのみならず、チームビルディングにも役立つんです。 上手に運用された日報には前例がある。ペパボの社内 SNS であるタンパクがそれだ。毎日スタッフ全員が日報を書くきまりなのだが、本来の目的である業務内容の記録以外に一言コメントを書く欄がある。定型文で済ます人もいればブログ並の長文を書く人もおり（それはわたしです！）、これがそこらの SNS なんかよりよっぽど面白いコンテンツな
rbenv のメカニズム - @kyanny's blog
rbenv 環境下で実行された Ruby プログラムの中から他の Ruby プログラムを起動するときに、 rbenv 環境をリセットしたい―要するに別のバージョンの Ruby で外部プログラムを実行したい―という事情があったので rbenv のメカニズムについて調べた。 rbenv 環境下で ruby コマンドを実行するとき、実際にコンパイルされた ruby バイナリが直接実行されているわけではない。 rbenv 環境をお膳立てした上で ruby バイナリを exec するラッパーのシェルスクリプトが実行される。こういうものを binstub と呼ぶ。 binstub である ruby という名前のシェルスクリプトの中身をみてみると、最終的に rbenv exec というサブコマンドを呼び出している。 rbenv のサブコマンドはリポジトリでいうと libexec ディレクトリ以下にある。
Jenkins に bundle update した上で Pull Request させる - @kyanny's blog
皆さん bundle update してますか？ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン
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
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
最近のペパボの技術書読書会について - @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 とかるりまとか引けるようにしたこともあるけど、コマンド名やキーバインドを覚えられず定着しませんでした。あと、用例も見たいので結局ほかのページもぐぐることになり、もうブラウザでいいや、というのが今のところの結論です。わざわざキーワードを当てたのは、「赤い背景」のページばかり上位に出てくるのが嫌だったからで、単にキーボードから
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
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 を送る
highscalability.com の Tumblr のアーキテクチャについての記事を読んだ - @kyanny's blog
High Scalability - High Scalability - Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter を読んだ。すごく面白かった。 Kindle で引用したところを中心にメモ。 Tumblr のソーシャルグラフの特徴 The graph for Tumblr users has hundreds of followers. This is different than any other social network and is what makes Tumblr so challenging to scale. Tumblr だと follower が数百人いるユーザーはザラにいる。 follower の多いユーザーの post は多くのユーザ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
