RubyなしでItamaeレシピを実行できる「itamae-go」を作った

Goとmrubyを使ってitamae-goを作った

github.com

Pokemon Goが流行っていたので流行に乗じてItamae Goを作った。

というのは冗談で、手元の開発環境のセットアップにitamaeを使っているのだけど、まっさらな環境でitamaeを実行したい時にRubyやitamaeをどういれるかについて考えるのが面倒なので、Rubyなしで実行できるitamaeを作った。Goで実装し、mrubyでレシピを読むことによりRubyなしでの実行を実現した。

インストール方法

Releasesにバイナリを置いてあるのでこれをダウンロードする。基本的には環境セットアップ用のシェルスクリプトからこれをcurlなりwgetなりでダウンロードして使うことを想定している。

なんか動かなかったらgit cloneしてmakeすればその環境用のバイナリが作れるはず。 *1

使い方

普通にitamaeレシピを書いて、

# recipe.rb
package 'vim' do
  action :install
end

service 'sshd' do
  action [:start, :enable]
end

itamae-go localを実行する。

$ sudo ./itamae-go local recipe.rb
 INFO : Starting itamae...
 INFO : Recipe: recipe.rb
 INFO : package[vim] executed will change from 'false' to 'true'
 INFO : service[sshd] executed will change from 'false' to 'true'
 INFO : service[sshd] executed will change from 'false' to 'true'

CLIは大体本家itamaeと同じになるように作っていて、Thorじゃなくてmitchellh/cliを使ってる都合でitamae helpがitamae-go --helpになってるところだけ違う。itamae-go sshはなくて、itamae-go localのみ。

実装ステータス

開発環境によく使われそうなOSXとUbuntu(Debian)と、僕が使うArch Linuxをサポートしている。

実装している機能のリストはREADMEに書いてあって、_exampleに入ってるような機能は動く。 けど、一見実装されてそうな機能をいろいろサボってたり、まだ僕もそんな使ってない状況なので、自分で直しながら使うつもりの人以外は使わない方が良さそうなステータス。

Goからmrubyを使った感想

これを実装するために一昨日あたりに初めてmrubyを触った。あとプログラムに別の言語を組み込むのも初めてだったので、その辺の感想を書いておく。

良かった点

両方の言語の良いとこ取りができる

Goの豊富な標準ライブラリや高い性能を生かしつつ、RubyのDSLやmrbgemsを活用した機能を持つことができ、両方の言語の良いところがそなわり最強に見える。

mrubyが思ったよりいろいろできる

mrubyはIOがないとかrequireがないとか、あんまり普通にプログラミングできるイメージではなかったけど、mrbgemsを追加してmrubyをビルドすれば割と目欲しい機能は揃う。やんちゃコードのミルフィーユみたいな奴も動いた。

悪かった点

Goとmrubyを行ったり来たりするコードを書くのが面倒

少なくともmitchellh/go-mrubyにあるAPIでは、Rubyで作ったデータ構造をいい感じにそのままGoの世界に持ってくる手段がない。具体的にはGoでJSONを読み込む時みたいにstructにtagを書いておくとRubyのstructがそのまま読めるみたいなのをやりたい気がするが、まあなかったのでRuby側にHashをとっておくコードを書いてkey一つごとにメソッド呼び出しをすることで取得していた。*2

あとは、そもそもRubyのコードをGoの文字列として持つしかないのでその時点で汚ないコードだし、それをどこに配置するかみたいな設計も難しくなる。

クロスコンパイルが大変

というか僕がcgo有効なGoのクロスコンパイルに慣れてなくてまだできてない*3。Goとmrubyそれぞれではクロスコンパイルができるので多分できるんだろうけど、普通のGoやmrubyのクロスコンパイルに比べるとちょっと面倒そう。

気持ち

mruby-cliでもワンバイナリにできるし、mrubyになくて困ったのは__FILE__くらい*4だったので、mrubyだけで作っても良かったんじゃないかと思ったけど、組み込み言語に関する知見は結構あったので良かった。

追記:

http://k0kubun.hatenablog.com/entry/itamae-mruby

k0kubun.hatenablog.com

*1:Makefileが雑なのでgoのディレクトリ規則に従った場所にgit cloneしないと通らない

*2:流石にもう少しマシな方法はあると思う

*3:なので、Releasesに置いてある奴はマシンを2台使ってあたたかみのあるビルドをしている

*4:なかったので、itamae-goでは読んでるRubyのコードのファイル名のスタックを持つようにしてるけど、それはmrubyでもできるので実装の障壁にはならない

ErgoDox2枚持ちがKinesis Contoured Keyboardを併用した感想

Kinesis Contoured Keyboardをお借りしている

id:ursm さんがKinesis Contoured Keyboardの2週間無料貸し出しをやっていて、Kinesisはずっと気になっていたキーボードだったのでお借りしてみた。 僕は今ErgoDoxを2枚所持しているが、本当はKinesisが欲しかったけど高いからErgoDoxを買ったという背景がある。

ErgoDoxに比べたKinesisの良いところ、悪いところ

まだ2日くらいしか使ってないんだけど、ErgoDoxとKinesisはおおむねキーの配置が同じですぐ慣れたしもう大体感想が固まっているので書く。

良いところ

  • 親指で押すキーが若干ErgoDoxより内側寄りなので押しやすい
    • もともと僕がこの辺のキーボード欲しくなったのはShift, Control, Alt, Spaceあたりを全部親指で押してるからで、親指で押すキーが押しやすいのはとても良い
  • キートップの形が良い
    • 中心の列のキーは結構丸みがあり、変なカドが指にぶつかることがなく触ってて気持ちいい
  • 窪んでいるので最下段のキーが押しやすい
    • ErgoDoxは一番下の列が押しづらいので、押しやすいキーの数で言うとKinesisの方が多いような気がする
  • 繋がってるのでキーボード自体の配置が安定する
    • セパレートだとキーボードの位置がズレたのをいい感じの位置に戻すみたいな手間がある。その点Kinesisはそこそこ開いてて押しやすくキーボード自体も安定もして便利。
  • ハードウェアだけでキーのリマップが完結する
    • Massdrop使うのとか自分でファームウェアビルドするのに比べてリマップが楽

悪いところ

  • デフォルトのCherry MX Brownが固め
    • キー荷重45gはCherry MX軸だと一番軽い奴なので普通は気にならないと思うんだけど、どうしてもGateron Whiteの35gが忘れられない人はつらいと思う
      • 僕もErgoDoxは両方キースイッチ取り替えやってるし、別に自分で改造できる人は変えればいいと思う。かなり面倒なのであんまりやりたくはない
  • HやGの内側にあたる場所にキーがない
    • ErgoDoxにはある奴。ErgoDoxだと最下段は押しにくい代わりにここが結構押しやすいので、もし両方使いたい場合はここがちょっと辛くなる
  • 複雑なキーリマップができなそう
    • SandSみたいに単押ししたら何かのキー、長押ししたら別の修飾キーにするみたいな奴できるんだろうか。完璧に調べたわけじゃないけど多分できなそう。

最近の気持ち

HHKBやRealforceなどの安価なキーボードを使っているみなさん

#tqrk10 で「私がRails 5に送ったパッチとその背景」について話してきた

TokyuRuby会議10でLTしてきた

去年に引き続き、今年もTokyuRuby会議10のLTに応募したら通ったので最近railsにマージされた僕のパッチで思い入れのある3つについて喋ってきた。今年はCookpad TechConfとかRails Upgrade Casual TalksでもRailsの話をしていて、なんか結構Railsの話するの好きだなと思った。

紹介した3つのパッチ

CGI.escapeHTML for html escape

rails/rails#22722。去年Ruby 2.3リリース前あたりにruby/ruby#1164でCGI.escapeHTMLを高速化したんだけど、それをRailsのerbでも使われるようにした奴。テンプレートエンジンがレンダリング時に行なう処理の中でHTMLエスケープはそこそこ重い処理なので、ここの高速化は結構インパクトがある。

f:id:k0kubun:20160529212243p:plain

slimのベンチマークをActionView上で実行するようにしたbeforeからafterにかけて緑の部分だけ高速化された。Ruby 2.3とRails 5.0にアップグレードするとこの恩恵を受けられる。

ちなみにActionView::Template::Handlers::Erubisと表記しているのは、Railsが使ってるerb実装はオリジナルのerubisにいろいろ改良が加わっていて割と別物なので、その意味で本家と区別するため。

Allow joins to be unscoped

rails/rails#18109。あまりメンテしたがるコミッターがいないdefault_scopeのバグが一つ消せたというめでたい話をした。Rails 5からは(joinする)includes, eager_load, joinsでdefault_scopeが外せるようになる。

Rails 5でもまだバグは残っていて、preloadや(joinしない)includesに対してdefault_scopeを外す術がない。 *1 Railsコミッターも使えないよねと言っている機能を使うのはメンテされないという意味でも避けた方が無難。個人的にはそのバグは直って欲しいので再びパッチを出し直した。 *2

Alias left_joins to left_outer_joins

rails/rails#22125。left_outer_joinsは2年くらい前からマージされて欲しいなーと思っていたパッチで、最初はouter_joinsという名前だったのが途中でleft_outer_joinsになり、いやいや長すぎでしょ…と思ってleft_joinsからも使えるようにしたのが僕のパッチ。

絞り込みのためだけのLEFT OUTER JOINもincludesでやるのが正しいみたいな認識をしている人がいて、ActiveRecord::Baseインスタンスの生成コストを軽視しているなと思うのだけど、健全な書き方をする方法がなかったのである意味しょうがなかった面もある。それがRails 5ではleft_joins使ってねと言えば済む話になるのでめでたい。

ついでにincludesを使う人の気持ちがわからないという話をした。ヒートアップしすぎてincludesと言う度に声が裏返っていたような気がする。

気持ち

相変わらず出てくる食べ物がおいしいし、日頃言いたかったことを好き放題喋れて、しかも結構いろんな人から共感が得られたしかなり楽しかった。去年はLT王の投票があまり集まらなかったけど、今年は2位だったのが結構うれしい。また参加したい。

*1: ただし https://github.com/rails/rails/pull/17360 のおかげでdefault_scopeを打ち消すunscopeを記述したassociationを定義しなおせばそこではdefault_scopeが外れる。まあ面倒なのでunscopedで外したい。

*2:https://github.com/rails/rails/pull/16367 の書き直し。書き直し前よりは仕様が改善してるけど、いろいろ突っ込みどころがあるのでこれではマージできないと思う。そのうちなんとかしたい。

ErgoDoxを2枚買ってキースイッチを交換した

f:id:k0kubun:20160515144142p:plain:w480

なぜErgoDoxを2枚買ったのか

直近で使っていたキーボードは1300円で買える奴で、金に余裕ができたらいい奴を買おうと思っていた。HHKBとRealforceは以前所持していたことがある*1ので、Kinesisとかを検討していたけど47kするしもう少し安いErgoDoxから試すことにした。会社まで持ち歩くのは面倒なので2枚買った。

買ったErgoDoxたち

値段は実際にクレジットカードで支払った額 (送料込み)

届くまでにかかった時間は両方2週間くらい。ErgoDox EZ→FalbaTech→PMKの順で届いた。

キーマップ

f:id:k0kubun:20160515153558p:plain

迷走中。3箇所にマッピングされている意味不明のキーもある。もともとキーマップはいじりまくってるので、それに合わせて作ってる。画像はMac用の奴で、Linux用の奴はRGui(Cmdキー)をAltに変えてる。レイヤー2にはTeensyキーと矢印キーしかないので省略した。

今はMassdropで設定してるけどGUIポチポチするの面倒なのでそのうちk0kubun/qmk_firmwareに移す。

キースイッチの変更

もともと使っていたキーボードのキー荷重が62±15gだったので、キースイッチには45gのGateron RedとGreetech Redを選んでいた。ただ、届いてみると元のキーボードよりずっと疲れた*2ので、35gのGateron Clear (ErgoDox EZのサイトだとWhite) を買ってそれに変えることにした。

で、まあ実際には半田づけをやり直すのが面倒だったので、Feelとか含め完全に同じタイプのスイッチであることを利用してバネ(とついでに軸)だけ交換することにした。

f:id:k0kubun:20160515160321p:plain:w200f:id:k0kubun:20160515160337p:plain:w200
f:id:k0kubun:20160515160340p:plain:w200f:id:k0kubun:20160515160343p:plain:w200

150個注文して150個分同じ作業をやったら6時間かかった。スイッチの分解コストがかなり高いので半田づけした方が速いかもしれない。

良い/悪いと思ったこと

ErgoDox EZ

  • 良いこと
    • Tilt/Tentキットといい感じのリストレストが最初からついてるのがかなり便利
    • キーキャップが位置によって形が違い、若干Kinesisみたいな感じになっている
    • 最初からGateron Whiteが選べる
    • 自己都合での返品による返金に対応している
  • 悪いこと
    • カバーが開けにくくカスタマイズはやりにくそう
    • 滑りにくい & ガタガタしないようにすると傾け方の選択の幅があまりない
    • FとJキーの突起が普通のキーボードよりちょっと気になる *3

FalbaTech + pimpmykeyboard: DSA PBT/ABS BLANK KEYCAP SETS

  • 良いこと
    • 外装の自由度が高い
    • 分解しやすく作りもシンプルなので壊れた時対応しやすいしカスタマイズも楽そう
    • FとJキーの突起がなく鬱陶しくない
  • 悪いこと
    • 傾けるのを自力でがんばらないといけないし、傾けると滑る
    • キーキャップの形が全部同じで、完全な平面キーボードになる
    • Gateron Whiteを採用できない

共通

  • 良いこと
    • キーボードレベルでリマップできるのでXを立ち上げる前から好きなキーマップが使える
    • セパレートなので自分が楽な姿勢を選びやすい
  • 悪いこと
    • 右端のキーの数が少ないので、JISとかUSとか関係なくいままで使っていた通りの配置を再現するのは無理

気持ち

最適なキーマップと一番楽な傾きを見つけて最高の開発環境を得たい

*1:持っていたのはJIS配列でUS配列に移行する時に売ったんだけど、当時も金がなくUS配列版を買い直せなかった

*2:これは多分普通のキーボードが押し始めにしか力がかからずそれ以降はスッと入るのに対し、Gateron/Greetechの赤軸はFeelがLinearでずっと同じ力がかかり続けるという違いがあるからだと思う。Gateron ClearもLinear。そのうちTactileとかClickyなスイッチも試したい。

*3:行ごとに形が違うのでいらないキーと交換できない

Coffee, jQueryで書いていたElectronアプリをES6, React, Reduxで書き直した

ElectronベースのTwitterクライアント: Nocturn

ElectronでYoruFukurou風のTwitterクライアントを作った - k0kubun's blog の時にCoffeeScriptとjQueryで作っていたNocturnというTwitterクライアントがあり、これをES6, React, Reduxを使って書き直した。この記事ではその時に得た知見、感じた事を書いておく。

Nocturn

移行したスタックと移行時に感じたこと

あらかじめお断りしておくと、僕は普段はRubyでサーバサイドの実装や運用をやっている人であり、JavaScriptに関してはほぼ素人の意見なので、以下はReactとかRedux興味あるけどまだ触ったことないですみたいな人向けの内容になると思う。

CoffeeScript → ES6 移行

参考: 春からはじめるモダンJavaScript / ES2015 - Qiita

CoffeeScriptはオワコンか？

Sprocketsではv4からES6のサポートが入るんだけど、リリースされているSprockets 4はまだbeta2なので、Railsアプリ書いてる人からするとむしろES6がまだ始まってない。 けどCoffeeScriptの開発はもうあまり活発ではないし、普及すればコンパイルしなくても使えるようになるES6の方が未来が明るい感じがするので移行した。

decaf

decafでcoffeeのコードをES.next に書き換える - Qiita
自動変換が結構ちゃんと動く。よーし書き直すぞと思っても手で書き直してくのは大変で、今までCoffeeScriptで書いてきた資産が変換するだけで動いてくれるのはすごく助かる。これのおかげで移行は楽だった。

babel

babelとにかく最高で、めちゃくちゃ拡張性が高くできていて、プラグインを追加するだけでJavaScriptの文法を増やすことができる。例えば僕は引数のリストにケツカンマを書かないと気が済まない人間なんだけど、これはbabel-plugin-syntax-trailing-function-commasを入れると使える。便利。

言語自体に関しては、CoffeeScriptでインデントをミスって壊れるみたいなストレスを感じなくて済むあたりは嬉しいけど、21世紀にもなってセミコロン書くのが普通な言語だし、まあどっちもどっちかなという印象。

jQuery → React 移行

比較対象がちょっとおかしい気がするけど、ここではビューのレンダリングをjQueryで生DOM操作してやるのかReact使ってVirtual DOMでやるのかみたいな意図。React、そのうち流行が過ぎて使われなくなるでしょとか思って放置してたけど意外とそうでもない雰囲気なので触ってみた。

Reactのメリット

  • Componentを操作するインターフェースが限られるので、
    • あるビューがどこから操作されるのか予測しやすい
    • 結合が疎になり必然的に再利用性が高いコードが生まれる

Reactのデメリット

  • shouldComponentUpdate*1の保守コストが高い
    • ちゃんと書かないとパフォーマンスのボトルネックになりうる
    • ミスると、更新が必要でも描画されないなどの見つけにくいバグの原因になる

というのが一番印象が強かった。Reactで書くと保守性が高くなるみたいな空気を感じるけど、僕にはshouldComponentUpdateを保守するコストがそれを相殺するように感じた。

Reduxの導入

Fluxフレームワークには、客観的に見て一番普及していて信頼性の高いReduxを採用した。 なんか@mizchiがReduxめっちゃdisってるんだけど、Redux触るまではこのまとめで言われてることがほとんど理解できなかったので*2、とりあえず彼が言ってることを理解したいというのもあって触っていた。

Reduxの良いところ

  • Fluxを知らない初心者がとっつきやすい
    • 実装の指針がそこそこあるのでSPAの設計に不慣れな初心者にはありがたい
    • http://redux.js.org のドキュメントが親切だし、情報源も多い
  • react-reduxが良い
    • Reactの描画に関して自動でいい感じのチューニングをしてくれる
    • バケツリレーが不要になる

Reduxに感じた不満

  • ファイルの数が多くなるので疲れる
    • ComponentのロジックをContainerに剥がしてくのやると結構大変
    • 分割されたActionやReducerのファイルを追加する地味な作業が頻繁に発生する
  • storeのstateに基づいてdispatchを行うContainerを書くのが大変
    • mergePropsを書く必要があるんだけど、これ書くの辛い
  • react-reduxを使っていると描画以外の部分が重くなることがある(後述)

いろいろ不満はあるけど、Reduxを導入したことで、Fluxやってない時に僕が適当に考えた設計よりはどこで何が行なわれてるかわかりやすくなったと思う。

ReactとReduxのパフォーマンスの問題

ReactとReduxで書き直したらすごい遅くなった

フルスクラッチ後、キー入力によってツイートのフォーカスを移動したりすると画面がめちゃくちゃ固まるようになった。あと、textareaに文字を打ち込むだけでもかなり重くなった。

HipChatも以前Reactで書き直されたんだけど、Reactで書き直された現在のバージョンはタブの切り替えがめちゃくちゃ重くて、そのHipChatと同じくらい重くなった。

量が多いComponentでeventをsubscribeしてはいけない

いろいろプロファイリングをやっていたんだけどなかなか原因がわからなくて、以下のツイートをした時点ではまだ勘違いしていた。

実際にはdispatchより2段ネストしたところのsetStateにかかる時間が問題になっていた。TwitterクライアントだとツイートComponentの数はかなり多くなるわけだけど、そのツイートのComponent全てがReduxのstoreのstateの変化をsubscribeしていて、ツイートの数だけsetStateされるのが重かった。

これはreact-reduxのconnectというAPIを使ってContainerを作ると自動的に行なわれる処理なので、connectをやめないといけない。数が多いComponentに接続するContainerはこういうコードを書いてconnectなしで作るようにして回避した。

shouldComponentUpdate書くの辛い

connectはshouldComponentUpdateだけでなくrenderの中でもいろいろ最適化をやってくれるので、connectをやめるなら自分でシビアにshouldComponentUpdateを書かないと描画が遅くなってしまう。

React化したHipChatはチャットにいるユーザーのオンライン状況が更新されなくなったりする問題もあって、多分どこかのshouldComponentUpdateがミスってて更新されてないんだろうなという感じがする。タブ切り替えの重さも含め、Reactのこの辛さがHipChatの品質を下げているような気がしているんだけど、最近のバージョンからユーザーのアイコンが表示されるようになったりとか機能が充実してきたのも確かで、Reactによって開発しやすくなったことによってこれが達成された可能性もあるし、一概に否定はできないなと思った。

結論

ReactやReduxは大規模なアプリケーションで開発速度を維持するのには一定の効果がありそうだけど、パフォーマンスが要求されるアプリケーションでの導入には慎重になった方が良い。

*1:そのComponentを再描画する必要があるかどうかの判定

*2:ちなみに今見ても30%くらいしかわからない

#CookpadTechConf 2016で「Railsアプリ開発環境の高速化」について話した

クックパッドの社員が発表するCookpad TechConfというイベントの第一回が今日行われ、「Railsアプリ開発環境の高速化」というテーマで話してきた。

開発環境の改善について

僕が技術部に入る前、サービス開発をやる中で一番不満だったのが開発環境のパフォーマンスだったので、技術部に配属されたころからこの仕事をやりたいと思っていた。

今回は先輩方が既に行っていた開発環境のパフォーマンスチューニング - クックパッド開発者ブログの一部を紹介しつつ、その続きとして自分がやってきたことを発表した。 業務で出した成果のうちいままで外部で発表したのはbyebugの高速化くらいだったので、普段僕がどんな仕事をやっているのか紹介する良い機会になった。

発表内容の補足

思ったより15分の枠で話せたことが少なかったので、発表内で話し足りなかったことについて書く。

libsassおすすめです

急いでて全然ちゃんと紹介できなかったんだけど、この発表の中で普段Railsアプリの開発をやっている人にとって目新しいことは多分libsassしかない。これはsassのC++実装で、今週sass gemからの移行が完了し、いれた次の日に同僚から突然速くなってよかったというフィードバックがあった。

libsassが良い理由

おすすめする理由は以下の4つある。

  • とにかく速い
  • Cookpadのcss全体のうち挙動に影響のある非互換が、関数による色の計算が少しズレることだけ
  • gcc 4.6以上かclangならいまのところ普通にコンパイルできている
  • Sprockets 4で標準サポートされるのでレールに乗ってる

導入効果

Sprockets 3だとなぜかlibsass以外のレイヤー*1が遅く、期待より効果が少し低かったのだけれど、それでも改善前のアセットプリコンパイルの71%がcssに費されていたので資料に書いた通りそこそこインパクトがあった。Sprockets 2だと cssを生成する時間が604秒から140秒に短縮される *2。

railsで使う場合は今はsassc-railsを使うと良い。なおsassc-rubyを普通に使うとscssのシンタックスエラーでscssでないコードがエラー画面に出てしまうのでパッチを投げていて、これを反映したフォークを運用している。

RubyのGC使います

発表内容的に完全に脱線なので質問されたら話そうと思っていた内容なんだけど、Cookpadでは例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd lifeにある通り1/23現在リクエスト処理中はGCが止まっていて、これを来週変える予定であるという話。

gctoolsがRuby 2.1でしか動かない

開発環境でOut-of-band GCもどき *3 を試していたとき、Unicorn::OobGCのコードを読んでいたらRuby2.1以上ならtmm1/gctoolsがおすすめというコメントが書いてあった。そこで興味を持ってCookpadのRubyが2.0.0から2.2にアップグレードされた時gctoolsの検証を行ったのだけど、unicornのエラーがガンガン出たのですぐにロールバックした。

Ruby 2.2のRIncGCよさそう

それでgctoolsのissueを見てみたところ、どうもgctoolsの作者によると、Ruby 2.2で導入されたRIncGCのおかげでOobGCは不要であり、Ruby 2.2サポートはしないらしい。ちゃんとした説明はRIncGC jaを読んで欲しいのだけど、メジャーGCの長いマーク時間を解決するための改善が入ったようなので、普通にGC.enableしてOut-of-band GCもしない状態を本番の一部のサーバーで検証したところ、それほどパフォーマンスも劣化せず、かつCPU使用率が1割程度下げられそうな計測結果が得られた。

迷ったら健全な方

そこでインフラ部と相談し、「GC を無効化する運用は健全じゃないと考えています。Ruby の GC の改善がクックパッドにどう影響するのかというのをちゃんとコミュニティに還元するべき」という理由からGC.enableの許可をインフラ部長のmirakuiさんからいただいたので、特に何も起こらなければ来週からGCが有効になる予定。*4 結果は何かの機会にコミュニティに還元されるでしょう。

*1:アセットプリコンパイルにおいて、Sprockets 2だとjsがボトルネックになり、Sprockets 3だとcssがボトルネックになるというのが根拠。なぜ遅いのかは調査中。

*2:独自パッチによる並列化なしの状態での計測

*3:Unicorn::OobGCとかと違ってGC.startしないのでOobGCと呼ぶのを控えている

*4:僕は本番サーバーには触れないので実際の作業はsora_hにお願いしている

2015年にやったこと

今年は卒論を書いて大学卒業後社会人になり、新卒研修を3ヶ月やり、部署に配属されて6ヶ月働いた。
以下、2015年にやったことをまとめる。

発表

2014年はどの勉強会にいっても誰にも知られてなくて寂しかったので、2015年はたくさん外部で発表するというのが目標だった。 今年は社外向けには10本発表した。

RubyKaigi 2015

1日目

k0kubun/hamlitの宣伝をした。発表練習をたくさんやっていろんな人に資料のレビューをいただいたので満足な発表ができた。関係者各位には本当にお世話になりました。LTじゃない発表するの初めてだったけど、いろんなことを伝えられるので長い発表の方がやってて面白いなあと思った。

2日目

頭がおかしくなって2日連続発表した。2日目も意外と評判が良くてホッとした。

Go Conference 2015 summer

k0kubun/ppの宣伝とメタプロの話をした。LTなんだけど、後でこの発表で僕を知ってくれた人に会ったのでGoConは大きくて良いなあと思った(小並)。

TokyuRuby会議09

k0kubun/rebuildとk0kubun/karabiner-dslの宣伝をした。とにかく上手い飯と酒が無限に提供される最高の会だった。

Itamae Meetup #1

普段itamaeを使ってて工夫していることを色々話した。itamae大好きな人がいっぱいいて、僕もこういうOSSが作れるようになりたいと思った。

Shibuya.rb 20150715

k0kubun/activerecord-precountの宣伝をした。結構気に入っているgemで、発表して以降割と良い評価をもらえているので良かった。

hikarie.go #4

k0kubun/go-ansiの宣伝と、GoをWindowsで動かすには結局自分でWindows APIを叩くしかないという話をした。つらい話。

マルチプラットフォームなインタラクティブシェルを楽に作る - Speaker Deck

その他

特に資料は公開してないけど、社外の人向けにはあと3回くらいLTしている。

  • Cookpad x CyberAgent x DeNA 15卒エンジニア交流会
    • Railsアプリ開発環境高速化の話をした。
  • Donuts, DeNA, Yahoo, 弊社の交流会
    • RubyKaigiのLTと同じくbyebugの話をした。
  • Cookpad TechBar -vol.3-
    • 学生時代と今やっていることについて話した。

ホッテントリ

タイトル
1位 ElectronでYoruFukurou風のTwitterクライアントを作った - k0kubun's blog
2位 gdbを使ったrubyのデバッグ - クックパッド開発者ブログ
3位 k0kubun/md2key · GitHub
4位 byebugやpry-byebugを使った後の挙動を10倍高速にしました - k0kubun's blog
5位 PCを自作してArch Linuxを入れた - k0kubun's blog
6位 Slimより高速なHaml実装「Hamlit」をリリースしました - k0kubun's blog
7位 Electronを初めて触った時にハマった5つのこと - Qiita

今年はブログの読者とかQiitaのフォロワーがそこそこ増えたので嬉しい。 あと去年書いた奴だけど、うるう秒が挿入された時に Linux - topコマンドの使い方 - Qiita がやたらとブクマついた。

OSS活動

今年リリースしたOSS

Star リポジトリ
★365 k0kubun/md2key
★304 k0kubun/hamlit
★102 k0kubun/Nocturn

Hamlitは最初の実装に1ヵ月、その後のフルスクラッチに2ヵ月かけてるけど、Nocturnは2日で作ったし、md2keyは2時間で完成した。でも書いてて楽しいのはHamlitみたいな奴なので、こういうのを作り続けたい。

それ以外だと去年作った奴を引き続きメンテしたり、誰かのOSSにプルリを投げたりしていた。
Itamaeで色々やってたらコミット権をもらえた。

あと今年は初めてCRubyにコミットして、以下の貢献はNEWSに入れてもらえた。

2016年は

入社後業務をやっていてわからないことだらけなので、2016年はインプット側に力を入れて地に足をつけたい。 アウトプットの目標としては、書籍になるようなOSSを作って自作OSSの単著を出したいとずっと思っているんだけど、逆算して計画を立ててどうにかなる話でもないと思っているので、引き続き自分が好きなこと、興味のあることをやって毎日成長するのを楽しむ生活を送りたい。

来年もよろしくお願いします。