Quipper に入社して7年が経った - @kyanny's blog
今日付で退職する。入社日は2013年5月28日だった。「入社して○年」も書き納めだ。去年は書けずじまいだったので、この2年を振り返りつつ、7年を総括する。 これまでの「入社して○年」エントリまとめ 丸2年 丸3年 丸4年 丸5年 丸6年（欠番） 失われた2年 一言でいうと「失われた2年」だった。2018年4月から VP of Engineering になり、ほとんど全ての時間をエンジニア組織のマネジメントに費やした。ソフトウェア開発者として技術を磨き経験を積むという当たり前のことができず、大きなブランクが空いた。ストレスに苛まれ、身体を壊して二度も入院した（一回目・二回目）。自分にはマネジメントの仕事は向いていないと改めて痛感した。不得意なことで勝負すべきではない。 機会が与えられたのは、ありがたいことだったと思う。これまでの社会人人生で最も出世したし、年収も高くなった。ソフトウェア開発者
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
line-bot-sdk-ruby のサンプル echobot を Heroku で動かす方法 - @kyanny's blog
2016/10/06 14:59 追記 コメント欄参照。IPアドレスをホワイトリストに登録する必要は無いのでHTTPプロキシを通す必要もなく、従ってサンプルコードは無改変で動く模様。以下の内容は全て徒労だった。 Gemfile.lock とか config.ru を足して、固定グローバル IP で LINE Messaging API にアクセスするように HTTP プロキシを通せばよい。それらが設定済みの できるリポジトリはこちら↓ github.com ...が、 HTTP プロキシを通すようにするだけのことで異常にハマった。結論として、必要最小限のメソッドをオーバーライドするのが良い。オリジナルの app.rb との Diff はこんな感じ。 Comparing c2f3dd962772b2c8a2cda05528ff643d750b5597...v1.0.0 · kyanny/li
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
RubyKaigi 2015 - @kyanny's blog
二日目の夕方からと三日目の二コマ目から参加した。 この一年ほどは Ruby/Grape,Rails よりも CoffeeScript/Backbone,Marionette を書いてる時間の方が圧倒的に長く、仕事以外でも特に面白いものを作らなかったので、トークに応募しなかった。準備せず手ぶらで参加するだけのカンファレンスは、ラクだけどやっぱりどこか物足りないなと思った。もっとも、この冬の忙しさでは準備できたとも思えないが。 今年は「Ruby にこだわる」姿勢というものを感じるトークが多かった（自分が聴いたものの中では）特に mruby は、数年前に出てきたときは全然ピンとこなかったけど、今年はなぜか「Rubyist ならパフォーマンスが出ないからとかいって Go なんか選ぶんじゃなく Ruby でパフォーマンスを出す方法を考えるのが筋だろ？」と言われているような気がして身が引き締まる思いだ
Ginza.rb で Quipper のシングルページアプリケーション開発について発表しました - @kyanny's blog
ginzarb.doorkeeper.jp Ginza.rb 第26回 シングルページアプリケーションのためのRailsとJavaScript フレームワーク という勉強会で、 Quipper で JavaScript (CoffeeScript) と Rails によるシングルページアプリケーション開発をどうやっているかについて発表しました。お声がけいただいた @willnet さん、 Ginza.rb のみなさま、ありがとうございました。 発表で使った資料はこちらです。 Backbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷 もともと YAPC::Asia の CFP に応募して落選したネタだったのだが、ある意味で自分がこの 2 年間やってきた仕事の集大成ともいえる内容だっ
渋谷.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)
インフラ系トレンド私的まとめ - @kyanny's blog
社内勉強会でいろいろ教えてもらったのでメモ。トレンドと呼ぶには一、二年遅い。なお自分の考えを整理するために書いているものなので正確さは保証しませんしツッコミも不要です。 前提: 仮想マシンと仮想マシンイメージ VirtualBox とか、 AWS なら AMI とか。ホストマシン上で動作しているものが仮想マシンで、仮想マシンイメージは仮想マシンのスナップショットだったり、それをもとに新しい仮想マシンを作れる雛形だったり、くらいに理解しておけばよい。 Vagrant と Packer 仮想マシンと仮想マシンイメージの技術があるおかげで、作業環境（Mac とか Windows とか）上でプロダクション環境により近い環境を手軽に用意できるようになた。しかし仮想マシンの管理（起動したり、設定を変えたり）は手作業でやる必要があった（VirtualBox なら GUI でぽちぽちやったりとか） Vag
フレームワークとアプリケーションの境目 - @kyanny's blog
それでもRailsを選択する3つの理由 - pblog 興味深く読んだ。 ずっと気になっていることがある。フレームワークとアプリケーションの境目について。 アプリケーションとフレームワークははっきり区別されるべきなんだろうか。 Rails は「区別するべきだ」と要請しているように感じられる。アプリケーションはフレームワークが規定する「できること」の範囲内で書くべきであり、その範囲を外れる場合は相応の覚悟をしろ、領分を守る限り難しいが一般的な問題はフレームワークが正しく解決してやるぞ、と。 一方で、フレームワークもアプリケーションの一部である、とする考え方もあると思う。足場を支えるライブラリに過ぎない、という思想。両者の境界は曖昧になり、フレームワークが規定する「できること」だけでは物足りなくなったとき、アプリケーション側を「できること」の枠内に合わせるのではなく、フレームワーク側を拡張して
New Relic のグラフを毎時チャットに貼り付ける - @kyanny's blog
New Relic をこまめにチェックすべきだが怠惰かつ忘れっぽいせいでチェックできないので、グラフ画像が毎時チャットにつぶやかれるようにしてみた。 やり方はけっこう込み入っている。 New Relic の Embedded Charts 機能を使って埋め込み用のグラフを作る。 Amazon S3 にバケットポリシーでデフォルト公開設定にしたバケットを作る。 適当なサーバーに Jenkins と phantomjs と s3cmd をインストールし、 s3cmd は 2. で用意したバケットに書き込める Access Key Secret Key で --configure しておく。 capture_put.sh というスクリプトを使い、 phantomjs で embedded chart のスクリーンショットを撮って s3 に put し、画像の URL を HipChat に投稿す
渋谷Ruby会議01 で Grape の話をしました #428rk01 - @kyanny's blog
渋谷Ruby会議01 の Member talk 枠で、 Ruby のマイクロフレームワーク Grape について話しました。運営の皆さん、参加者の皆さん、ありがとうございました。 大幅に時間オーバーしてしまい、ご迷惑をおかけしました。 15 分は思っていたよりずっと短かく、あっという間でした。なおスライド六枚目に「Grape でググると世界で2位」とありますが、どうやら僕のブラウザ自体がパーソナライズされていた結果によるものらしく、他の方が検索したらもっと順位は低かったそうです。 Grape 自体の紹介がちょっと長くなりすぎたため、後半は Grape のいまいちなところ（と僕が感じているところ）ばかり挙げてしまいましたが良い点もちゃんとあり、特に route 定義と実装の場所が離れていないため URL から実装箇所を特定するのが楽で、これは自分が書いたのではないソースを読む際には便利です
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
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
git-prune-remote-branch が gem になりました - @kyanny's blog
以前 git-prune-remote-branch というものを作ったのですが（どういうものかはリンク先参照）、 あれ、git-prune-remote-branchってgemになってないんだっけ。— 北市真 (@KitaitiMakoto) May 2, 2014 というリクエストがあり、 @KitaitiMakoto あ、 gem にし終わったら教えてください— Kensuke Nagae (@kyanny) May 2, 2014 と丸投げしてみたら、 おれがやんのかw— 北市真 (@KitaitiMakoto) May 2, 2014 という流れのあと、 Gemify by KitaitiMakoto · Pull Request #2 · kyanny/git-prune-remote-branch https://github.com/kyanny/git-prune-rem
「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 の挙動
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 がある、み
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 がセットされているキーのみが破棄対象となる という違いがある。実装
ルーク、 MongoLab を使え！ - @kyanny's blog
五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か（冗談ですよ）、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい
#isucon 2013 予選通過 - @kyanny's blog
isucon 2013 予選通過した。チーム名は :ok_woman: 選んだ実装は Ruby (Sinatra) ISUCON 本戦出場者決定のお知らせ : ISUCON公式Blog 予選二日前に @banyan から誘われ急遽参戦を決めた。予選当日までは十分な準備期間はとれなかったが、三回連続参加と場数だけは踏んでいるので振り返りという名の反省文を private repo の issue に書いて共有したりした。 当日の流れ。なんとなく役割分担したほうがいいねと事前に打ち合わせていたのもあり、チームリーダーの @m4i がデータベースを中心にパフォーマンス計測とチューニングの方針決定担当、 @banyan がデプロイ、開発環境整備、フロントエンドなどの足回り担当、残った僕がアプリケーション担当でひたすらコードを書く、という感じだった。 はやい段階で git pull によるデプロイ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
