Re: OSSで世界と戦うために - k0kubun's blog
yusukebe さんの OSSで世界と戦うために を読んで感銘を受けた。 hono の快進撃もさることながら、OSSで日本のコミュニティの外にリーチしたり、 GitHubスター数を伸ばしたりみたいな話は、 自分も10年くらい挑戦し続けているけどあんまり表に出てこない気がするネタなので興奮した。 僕はいくつかの点で上記の記事とは違う方法でOSSで世界と戦っているのだが、 その中でうまく行っているものや、良くないと思っているものなどについて紹介したい。 GitHubのスター数 OSSを始めたばかりの学生時代、GitHubのスターへの執着がもはや煩悩の域であり、 集めたスターの数を合計するCLIツールを作ったり、 同じ計算方法でランキングを作るWebサイトを作ったりした。 このサイトによると、僕の今のスター数は9000を超えている。 自作したOSSの中では、スター数が1600くらいのものが2つ
Treasure Data を退職しました - k0kubun's blog
約5年5か月働いたTreasure Dataを7/22に退職した。7/25からShopifyに入社し、RustでJITコンパイラを開発してRubyを高速化する仕事をする。 仕事としてやりたい分野が変わってきて自分は今回転職したけど、とても良い会社なので、この記事がTreasure Data (以下TD) で働くことに興味がある人の参考になれば良いと思っている。*1 5年勤続記念にいただいたトロフィー やっていたこと APIチーム 元々TDにはJavaで分散システムを書きたくて入社したのだが、TD入社前に特にそういう経験があるわけでもなく主にRailsをやっていたこともあり、Railsでプラットフォームを開発するチームに入った。基盤開発をやりたいと思いながらサービス開発者として最初働き、後に基盤開発チームにジョインするみたいな過去の経験があったので、今回もそういう感じでいけると考えていた。実
後悔しているがやめられない開発効率向上術 - k0kubun's blog
僕はdotfiles系リポジトリ*1のコミット数を合計するだけで2261コミットある、.vimrcばっかりいじっていて開発が全然進まないタイプの人間で、つまり開発環境にとてもこだわりがある。 こだわりすぎて他に誰もやってなさそうな数々のカスタマイズを生み出してしまったが、やらなければよかったと後悔しているものが多くあるので、僕のような人が新たに生まれないよう、やめておけばよかったテクニックとその法則のようなものを紹介したい。 後悔しているもの C-h, C-y, C-u, C-oでウィンドウ切り替え Windows, macOS, Linux問わず以下のグローバルなキーバインドを設定している。 C-h: ターミナルにウィンドウ切り替え C-y: IntelliJかCLionにウィンドウ切り替え C-u: Google Chromeにウィンドウ切り替え C-o: TwitterかSlackに
働きながらアメリカの大学院でCS修士号を取った - k0kubun's blog
4年前に会社の福利厚生を使ってスタンフォードの授業を取ってみたら面白く、 働きながらでも続けられそうだなという実感を得たので、 2年後、受験を経てジョージア工科大学にリモートで通い始めた。 そして先日、ジョージア工科大学からコンピュータサイエンス修士号をいただくことができた。 画像の学位記は卒業式イベント用の非公式のもので、1~2か月すると Masterとちゃんと書いてある本物が来るらしい *1 。 After 1 year and 9 months, I graduated from Georgia Tech and got a master's degree in computer science. It was intense to be a student while working full-time, but I learned a lot. pic.twitter.com/J
令和時代のRubyコア開発 - k0kubun's blog
Ruby Core Development 2019というタイトルでRubyKaigiのCFPにプロポーザルを書いたのだが、 もう一つ書いた方の話が採択されたのでその話はしなかった。 さて、今日はRubyコア*1の開発がSubversionからGitに移った節目でもあったので、そっちのトークで言いたかったことの一部を記事にしておこうと思う。 Subversion → Git 移行 [Misc #14632] 去年くらいから @hsbt さんが cgit というGitフロントエンドを使ってGitリポジトリの準備を始め Misc #14632、ついに今日正式にcgitの方がupstreamになった。平成の時代でSubversionでのtrunkのRubyコア開発は幕を閉じた。 この辺を進めているのは主に @hsbt さんな中、僕がこれを偉そうに書いたり今回のRubyKaigiで壇上でアナウンス
GraphQLは何に向いているか - k0kubun's blog
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
Hamlを3倍速くした - k0kubun's blog
Hamlコミッターになった RubyKaigi 2015で「Hamlは遅いしメンテされてないので使わない方がいい」と言ったところ、じゃあ自分でメンテして速くしろということになりコミッターになった*1。 当時から2年ごしなのは、当時のHamlのオーナーがあまりアクティブではなく、最近a_matsudaさんがオーナーになったため。 HamlのTemple化・高速化を行った Templeというのは、テンプレートエンジンをパイプライン的に構築するためのフレームワークで、テンプレートエンジン用の中間表現とその最適化エンジンを持つ。実装をTempleベースにすると、SlimやHamlitに使われているような中間表現を使った最適化を適用しやすくなる。 コミット権をもらったので、RubyKaigi 2015でマージされないと言っていたパッチを自分でマージし、コード生成とattributeのコンパイルをTe
#RubyKaigi 2015 でテンプレートエンジンの高速化について話しました - k0kubun's blog
FamlとHamlitがなぜ高速かについて話しました RubyKaigi 2015の1日目に、「High Performance Template Engine」というタイトルで発表しました。 @eagletmtさんが作ったFamlと、僕が作ったHamlitがなぜオリジナルのHamlに比べ高速か話しました。 発表は以下のような内容でした。 テンプレートエンジンとは何か テンプレートエンジンの例 テンプレートエンジンの仕組み パフォーマンス どのようにRubyのコードを速くするか ベンチマークがなぜ必要か プロファイリングの方法 改善の仕方 高速化のために何をしたか Famlがやったこと Attributeの最適化 高速なRuntime Attribute Builder Hamlitがやったこと String Interpolationのコンパイル 使われていない挙動の削除 以下、発表内で
Hamlit v2.0をリリースしました & RubyKaigi登壇します - k0kubun's blog
Slimより高速なHaml実装「Hamlit」 RubyでHTMLを生成するのにERB以外でよく使われるテンプレート言語にHamlやSlimがあります。haml *1 をやめて高速なslimに移行する人が多かったのですが、私はHamlのシンタックスの方が好きなので、slimが用意したベンチマークでslimより高速なHaml実装「Hamlit」を3月にリリースしました。 *2 これはslimが提供しているベンチマークでHTML escapeを有効にし *3、FamlとHamlitを追加したベンチマークの結果です。なおHamlitは完全にHaml互換の仕様ではなく、この非互換が有利に働いています。 互換性と性能が大幅に向上したHamlit v2.0 Hamlitの互換性の問題 Hamlitは最初のv0.1の時点で上記のようなベンチでSlimより高速ではあったのですが、以下のような欠陥がありまし
Slimより高速なHaml実装「Hamlit」をリリースしました - k0kubun's blog
slim-template/slimのcompiled benchでオリジナルのhamlに比べ8倍高速に動作するhaml実装をリリースしました。 github.com なぜ高速なHaml実装を作ったのか 個人的にhamlのシンタックスのほうが好きなので、「hamlは遅いからslimを使う」みたいな人を減らしたかったから。以前slimの普及に貢献したんだけど、気が変わったのでhamlを応援することにした。 実は他にも既にeagletmt/famlという高速なHaml実装が存在していたんだけどベンチを走らせたらslimより遅かったので、slimを打倒するべく再実装した。 どのくらいHamlより速いのか 自分の実装に都合のいいベンチマークを作るのは簡単なので、公平性を期すためにslim-template/slimのcompiled benchと同じものを使い、誰でも同じ環境が使えるtravisで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
