Kensuke Nagae is a GitHubber! - @kyanny's blog
I am thrilled to announce that I joined GitHub as an Enterprise Support Engineer. GitHub was one of my dream companies for years. I am so happy to be a member of people who make a platform where the world builds software. I am looking forward to helping our customers build software to make the world a better place.
Nintendo Switch を買った - @kyanny's blog
Nintendo Switch 本体 (ニンテンドースイッチ) Joy-Con(L) ネオンブルー/(R) ネオンレッド 発売日: 2019/08/30メディア: Video Game 妻と暮らし始めて15年、ついに据え置き型のゲーム機を購入するに至った。 結婚祝いにWiiをプレゼントされたことや、友人の結婚式二次会のビンゴゲームで3DSを当てたことはあった。それ以外にも、中古のゲームボーイとか携帯ゲーム機を入手したことはあったが、テレビと繋ぐゲーム機を買う機会はこの15年で初めて訪れた。 妻は筋金入りのゲーム・アニメ嫌いで、付き合い始めて最初の一、二年は「少しずつ楽しさに慣れさせていこう」と考えていたものの、頑なにその手のもの全般に拒否反応を示す様子を見るにつれ、「この人と一緒になるということは、もう一生オタクカルチャーとは無縁になるのかな」と諦めかけたこともあった（メジャーなゲームには
発熱性好中球減少症で二週間入院した - @kyanny's blog
発熱性好中球減少症という病気になり、2018年の12/27から2019年の1/8まで入院した。 ギラン・バレー症候群で入院後、無事に退院して社会復帰し、一ヶ月ほどは元気に暮らしていた。ステロイドと免疫抑制剤によるクローン病の治療も計画通り進んでいた。しかし12月の中旬頃から雲行きが怪しくなってきた。 免疫抑制剤によって白血球数を平常時の数分の一程度に減らし、免疫の働きを抑えることでクローン病の進行を遅らせる、という治療方針に従って免疫抑制剤を増量していったのだが、白血球数が想定よりも少なくなりすぎてしまった。毎週通院して血液検査と診察をしているので、想定の数字を割った時点で免疫抑制剤は中止したのだが、白血球数は下げ止まらなかった。白血球数（と白血球中に含まれる好中球数）が極端に少なくなると身体の抵抗力が落ちて感染症に負けてしまう。そういう状態で発熱すると、もう自力では回復できないので、入院
ギラン・バレー症候群で一ヶ月入院した - @kyanny's blog
ギラン・バレー症候群という病気になり、2018年の10/1から11/3まで入院した。 異変に気づいたのは9/30の早朝だった。両脚に力が入らない。膝がガクガクして、立ってまっすぐ歩くのもおぼつかない。仕事のストレスで頭痛が続いていたので、脳の血管が切れたかと思ってぐぐってみたが、その場合は半身（右手右脚とか）に症状が出るらしく、両手ともに無事だったのでひとまず命に関わることはなかろうと判断してその日は一日寝て過ごした。ちなみにぐぐったときにギラン・バレー症候群の名前も出ていたのだが、まさかそんな変な名前の病気であるとは思わず、気にもとめなかった。なおこの日は世界選手権自転車競技大会ロードレースでアレハンドロ・バルベルデが優勝した日で、布団から這い出てゴールシーンだけ観た。 翌日10/1になると症状がおさまるどころか両腕も力が入らなくなった。肘がガクガクして、まるで自分の身体が操り人形になっ
recompose の withState - @kyanny's blog
recompose の withState がわからなかったけどブログ記事とコードを読んだらなんとなくわかった（たぶん）。 公式の API ドキュメントのこのサンプルコードがわからなかった。 https://github.com/acdlite/recompose/blob/master/docs/API.md#withstate const addCounting = compose( withState('counter', 'setCounter', 0), withHandlers({ increment: ({ setCounter }) => () => setCounter(n => n + 1), decrement: ({ setCounter }) => () => setCounter(n => n - 1), reset: ({ setCounter }) => (
なぜ Quipper のエンジニア採用面接には必ず候補者の同僚となる人が参加するのか - @kyanny's blog
ohbarye.hatenablog.jp Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており 2015年の5月か6月ごろ、俺がエンジニア採用活動に関わるようになったタイミングで、強く希望してそういう仕組みにした。なぜか。 いちスタッフとして、自分が意見を表明する機会が無いまま、自分の同僚になるかもしれない人が選考・採用される状況に納得できなかったから。そして、自分自身は採用活動に関わるようになって不満を感じなくなっても、他の人は相変わらず同じように感じているかもしれない、そういうアンフェアな状況にも納得できなかったからだ。 なので、採用活動に関わるべき人たちに対して、採用活動における各種の情報ができるだけ多く共有されるように、少しずつ仕組みを変えていった。例えば: 試用期間を
Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして本当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事と英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな
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 がセットされているキーのみが破棄対象となる という違いがある。実装
livedoor Reader 終了に寄せて: Fastladder オープンソース版は GitHub で開発継続中です - @kyanny's blog
【重要】 livedoor Reader サービス終了のお知らせ｜livedoor Reader 開発日誌 livedoor Reader が 2014年12月25日（木） をもってサービスを終了します。自分でも永らく使っていたし、個人的に縁も思い入れもあるサービスなのでとても残念です。 Twitter で fastladder を検索 して眺めていると、やはりというか LDR 終了で移行先を探している方が多数いるようです。候補としてオープンソース版の Fastladder のセルフホストを検討している方もそれなりにいるようですが、 http://fastladder.org/ja/ のほうをみて「ずいぶん古そうだし、メンテナンスされてる気配もないからダメかな...」と諦めているつぶやきをみかけたので、ちょっとアナウンスを。 http://fastladder.org/ja/ のソースコー
Atom.io に乗り換えられなかった - @kyanny's blog
きっかけは些細なことだった。 Emacs で RSpec のテストケースを書いていて、全体的に動作がのろくてイライラさせられた。どうやら ruby-mode だか ruby-electric だかが悪さをしているらしいが、何年も前に .emacs.d に放り込んだもので、どんな風に設定するのかも覚えていない。最新バージョンに入れ替えてみたら、手元でちょろっとカスタマイズしていた改行時のオートインデントだか何かの挙動が変わってしまい、気になってコーディングどころではなくなった。 もともと Emacs Lisp は読むのも書くのも苦手で嫌々ながらも騙し騙し付き合ってきたが、このときばかりは心底うんざりして、もうこんな古代のツールに頼るのはやめにしよう、自分の仕事は高度に知的な作業であるはずのプログラミングであって多彩で変態的なキーボード操作を駆使してテキストを編集しまくることではない、ならばも
30days Album はどのようにして画像にアクセス認証をかけているか - @kyanny's blog
30days Album は画像の URL にもアクセス認証を入れています - 刺身☆ブーメランのはてなダイアリー の技術的な解説。基本的に 関西オープンソース 2008 30days Albumの裏側 のとおり。 ミドルウェアはこのスライドのときと比べてけっこう様変わりしている。 Perlbal は相変わらず使ってるけど。 リバースプロキシは nginx バックエンドに Apache (Passenger) と Perlbal 静的ファイルは nginx が配信 画像の URL は Perlbal にプロキシ 画像認証用の Perlbal Plugin がセッションストレージの Kyoto Tycoon に認証情報があるか問い合わせ それ以外にも提携している外部サービスのために特定の IP アドレスは素通りさせたりしている 画像ストレージは MogileFS なので X-REPROXY-
JavaScript で if 文を書くとき必ず波括弧を書くべきと主張しているスタイルガイド - @kyanny's blog
新人さんの JavaScript のコードレビューをしていて、 if 文の本体部分を波括弧で囲っていないコードを見つけた。 おれは本体が一行しかなくても必ず波括弧で囲うようにしており（そのほうがわかりやすいと思っているから）、できればそうして欲しいけど個人の好みを押し付けるのはよくないので、広く支持されているコーディングスタイルガイドの類いで同様の主張をしているものが無いか探した。 Google とか Mozilla とか GitHub あたりのドキュメントを眺めてみたが if 文の波括弧についてはっきり言及している箇所を見つけられずにいたら、該当するドキュメントをいくつか教えてもらった。 http://contribute.jquery.org/style-guide/js/#spacing if/else/for/while/try always have braces and alw
Single Page Application ではない場合 JavaScript コードのエントリポイントはどこにあるべきか？ - @kyanny's blog
仕事で中規模程度の Rails アプリケーションのコードベースをいじっている。このアプリはもともと app/assets/javascripts 以下に必要に応じて JavaScript ファイルを置き、適当なテンプレートファイルから直接 JavaScript の関数を呼び出したりしていた。ごく普通の Rails アプリである。 このアプリは CMS で、いわゆる「ブログの管理画面」みたいな用途で使われている。一部の機能はそれなりに込み入った UI 操作を必要としページ遷移なしに操作できる必要があるが、旧来のやり方では JavaScript コードの管理が間に合わなくなってきたので部分的に Backbone.js を導入し始めている。 最近悩んでいるのが、 Backbone.js なコードのエントリポイントをどのように呼び出すべきなのか？ということ。そもそも自分が Backbone.js
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
Increments は和製 GitHub の夢を見るか？ - @kyanny's blog
Quipper では日本オフィスの開発者を中心に、 Qiita::Team を導入して社内のドキュメント共有を行なっている。書かれる内容は日報が多いが、技術 Tips の共有やチャットでは適切でない込み入った技術的問題を解決する議論の場としても活用している。 なぜわざわざドキュメント共有？ていうか日報書くなんてダサすぎじゃね？そう思ったあなた、日報を見くびっちゃいけません。上手に運用すればナレッジシェアやコラボレーションのみならず、チームビルディングにも役立つんです。 上手に運用された日報には前例がある。ペパボの社内 SNS であるタンパクがそれだ。毎日スタッフ全員が日報を書くきまりなのだが、本来の目的である業務内容の記録以外に一言コメントを書く欄がある。定型文で済ます人もいればブログ並の長文を書く人もおり（それはわたしです！）、これがそこらの SNS なんかよりよっぽど面白いコンテンツな
Leave from paperboy&co., join to Quipper - @kyanny's blog
来週ペパボを退職します！転職先は Quipper です！みんな大好きウザい退職エントリも当然あとで書きますがウィッシュリストとか無いので！ブクマとスターを！！くれ！！！承認欲求！！！！— Kensuke Nagae (@kyanny) May 24, 2013 May 27 is my last day at paperboy&co. I had a great time with gentle people in this 3 years and 3 months. Thank you for all my colleagues! paperboy&co. is a good company for the following reasons: Culture: There are so many nice people here. They gather and play natura
Jenkins に bundle update した上で Pull Request させる - @kyanny's blog
皆さん bundle update してますか？ぼくは忙しさにかまけてついサボりがちなのですが先日何ヶ月ぶりかにやってみたらけっこういろんな gem がアップデートしててヒヤリとしました。 bundle update 忘れは今後もまたやってしまいそうだと思い、なにかこれを解決する方法がないか考えたところ、 マメにやるのは無理。余裕があればやるけど忙しくなったら忘れる。自分の意識が低くなっても破綻しない仕組みを作るべき 差分が小さくても Pull Request を出すのは悪くない。というか Pull Request は毎日全員が見るし放置されにくい bundle outdated の結果をメールするのもお手軽そうだけど、メールなんてどうせ見ない (pendaxes がいい例で、毎朝メールがきても痛くも痒くもない) ということで「Jenkins に毎週 bundle update したブラン
master ブランチにマージ済みのリモートブランチをまとめて削除する git-prune-remote-branch というスクリプトを作った - @kyanny's blog
必要になったのでそういうものを作りました。 https://github.com/kyanny/git-prune-remote-branch パスの通ったところに置いて Git のワーキングディレクトリで実行すると master と develop にすでにマージ済みのリモートブランチを全部削除します。 --noop で dry-run モードになるので実際に消す前に確認もできます。なんで master だけじゃなく develop も？というと、僕のチームで gitflow を使っているからです。 $ git clone git://github.com/kyanny/git-prune-remote-branch.git $ git-prune-remote-branch --noop $ git-prune-remote-branchgit push --mirror じゃダメなの
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mac キーリピートを早くする - @kyanny's blog
