yusukebe さんの OSSで世界と戦うために を読んで感銘を受けた。 hono の快進撃もさることながら、OSSで日本のコミュニティの外にリーチしたり、 GitHubスター数を伸ばしたりみたいな話は、 自分も10年くらい挑戦し続けているけどあんまり表に出てこない気がするネタなので興奮した。 僕はいくつかの点で上記の記事とは違う方法でOSSで世界と戦っているのだが、 その中でうまく行っているものや、良くないと思っているものなどについて紹介したい。 GitHubのスター数 OSSを始めたばかりの学生時代、GitHubのスターへの執着がもはや煩悩の域であり、 集めたスターの数を合計するCLIツールを作ったり、 同じ計算方法でランキングを作るWebサイトを作ったりした。 このサイトによると、僕の今のスター数は9000を超えている。 自作したOSSの中では、スター数が1600くらいのものが2つ

Ryzenはゲーム用CPUとしては特に問題ないのだが、 ソフトウェア開発においてはIntelのCPUに比べて不便なポイントがいくつかある。 日々業務で使っていてあまりにもストレスが溜まるので、CPUをIntel Core i7に変更した。 このマシンは8年前に組んだ自作PC なのだが、使っていて不便を感じたパーツを差し替え続けた結果、 今回のアップデートで全てのパーツが当時とは違うものに変わったため、 それぞれ古い方のパーツで不便だったポイントなどを紹介したい。 仕事で使う自作PC 社内のサービスをいじる時は会社から貸与されているM1 MacBook Proを使うのだが、このマシンは不便である。 Rubyのビルドは自分のLinuxのマシンに比べ2倍以上遅いし、Reverse Debuggingができるデバッガが存在しないし、 慣れたツールであるLinux perfも使えないし、Podman

LLVMやSwiftを作ったChris LattnerがCEOをやっている会社が、Pythonの使用感とC言語並の性能を併せ持つ言語としてMojoをアナウンスした。 まだ手元で試せる状態でリリースされてはいないが、最大35000倍Pythonより速いという。 Mojo🔥 combines the usability of Python with the performance of C, unlocking unparalleled programmability of AI hardware and extensibility of AI models. Also, it's up to 35000x faster than Python 🤯 and … deploys 🏎 pic.twitter.com/tjT09U4F80— Modular (@Modular_AI) May

Shopifyに入社してRubyのJITコンパイラを書く仕事を始めてから2か月経った。 前職の退職エントリ では今後やりたいことを書いたりしたが、実際OSS開発を仕事にしてみてどうだったかみたいなことを書いておく。 シリコンバレーでのリモート生活 3年前に妻とアメリカに移住し、今年永住権も取得した。 Shopifyは本社はカナダにあるし2020年5月からフルリモート企業なのだが、 前職の本社があったシリコンバレーのあたりからそのまま引っ越さずに暮らしている。 なぜシリコンバレーに住み続けるのか フルリモートである以上はカナダ移住のためのビザのサポートを会社がする動機もないため、 現職においても住む国の選択肢は基本的に日本かアメリカになると思っている。 飯が安くて美味いのを主な理由として妻も僕も住むならアメリカより日本の方が好きなのだが、 住む地域ベースで多くの企業が給料に傾斜をかけてくるこ

最近は個人開発は自分のOSSのメンテで手がいっぱいになってしまったのでサービス開発のようなものは普段あまりやらないのだが、大学院*1で今学期、何作ってもよいという感じの授業を取ってWeb/iOS/Androidアプリ*2を全て作るという体験をする中で、たまたま個人開発のコストを抑える活動をしたので、その時に調べたり考えたりしたことを書いておく。 Herokuで無料にする Herokuでは毎月550時間free dynoが使え、クレジットカードを登録しておくと更に450時間、合計1000時間無料で使える。Herokuは30分アクセスがないと一旦停止するが、今回授業で作ったサービスでこれを使い切らないことは明らかだったので最初はこれでセットアップした。セットアップも簡単だし、PostgreSQLも無料でついてくる。 ただ、コールドスタートに10秒くらいかかり、これがこのサービスではUX的に致命

僕はRubyで開発をする時は毎回Pryを使うくらいの熱狂的Pryユーザーだったのだが、PryはGemfileに書いてないと binding.pry できなくて不便。任意のgemをdefault gem化するgem default コマンドも作ったのだが、これをやるのすら面倒だと思っていた。 ある日、nobuさんがRubyに binding.irb という機能をいれた。Pryがdefault gemになるのを待つよりPryで僕が使う機能をIRBに全部移植してしまった方が早いのではないかと思い、4年前からPryの機能の移植活動を始め、今日僕がよく使う機能を全て移植し終えた。 その記念に、この記事ではIRBのPry互換の機能を紹介する。昔 今更聞けないpryの使い方と便利プラグイン集 という記事を書いたんだけど、この中で僕が毎日のように使うコマンドは全てIRBに移植したので、それを紹介する本稿を

サンフランシスコベイエリアでのITエンジニアの給料は東京より高いが、税金や物価も高いと言われている *1 。ではどちらに住む方がより多くの金が手元に残るのだろうか。 僕がベイエリアに移住してからちょうど1年が経ったので、僕が東京とベイエリアそれぞれにいた頃の出費やタイトルでどのくらい家の収支に差が出るのかということをまとめてみる。なお、この記事を書いている時点で 105.60 円/ドル なので、ドル円の変換をする際はこのレートを用いる *2 。 収入 基本給 ベイエリア 東京 $153,600 913万円 GitLabは同社の世界各地での待遇計算基準を 公開 しており、地域間の差異を公平に計算するには割とよくできたベンチマークなのでここの年収をそのまま使う。計算に使われる location_factors.yml では、日本の給与はサンフランシスコの 56.3% になっている。 Calcu

Kubernetesの使用感に興味があってaws-workshop-for-kubernetesというのを先週やり、ちょうどEKSがGAになった直後だったのでEKSが試せたのだけど、まあ最初からマネージドだとあまり面白みがないし金もかかるので、個人のVPSで動かしてた奴を全部Kubernetes上で動かすようにしてみている。 まだ本番で運用した知見みたいなのが貯まってるわけではないのだが、公式のドキュメントを中心に読んでいても単に動かし始める段階で結構ハマって時間を消費したので、これから同じようなことをやろうとしている人向けに備忘録を兼ねて使用感や知見をまとめておくことにした。 Kubernetesは今でもalphaやbetaの機能が多く、今後この記事の内容も古くなることが予想されるので、なるべく公式のドキュメントへのリンクを置くのを意識して書いてある。 構成 現時点で、ConoHaで借り

ISUCON7予選に「railsへの執着はもはや煩悩の域であり、開発者一同は瞑想したほうがいいと思います。」チーム (@cnosuke, @rkmathi, @k0kubun) で参加し、217,457点で予選通過だったようです。 正確な値は覚えてませんが、Best Scoreは25万くらいでした。 最終形の構成概要 appサーバ1 puma 16スレッド: 画像のアップロード/表示、雑多なリクエスト対応 puma 2スレッド: GET /fetch だけ返す appサーバ2 puma 16スレッド: 雑多なリクエスト対応 (画像はnginxがサーバ1に流す) puma 2スレッド: GET /fetch だけ返す DBサーバ MySQLがいるだけ サーバ1, サーバ2をベンチマーク対象にしていました。この構成なのは GET /fetch がスコアにカウントされないため、それ以外にほとんど

m_sekiさんとhsbtさんの推薦で、ERBのメンテナとしてRubyのコミット権をいただきました。 以下が初コミットです。 github.com 普段テンプレート言語Hamlの高速化やその更に高速な別実装Hamlitの実装をやっていてテンプレートエンジンの高速化に知見があり、ちょこちょこERBにも知見を還元したりしていたのですが、一昨日ふとERBの生成コードのiseqを眺めていた時に気付いてパッチを送った後、「入れるのめんどくさいし、ERBのコミッタやりますか」とお声がけいただいた形です。 というわけで、引き続き主に高速化の方面でERBのメンテナンスをやっていきますが、他にも以前僕がC拡張にしたHTMLエスケープとか、広い範囲でパフォーマンス改善をやれたらいいなと思います。 さっきのパッチに関連してto_sもメソッド呼び出しをバイパスできるようにしたら結構いろんなものが速くなるんじゃない

Linux デスクトップ環境 2016 - eagletmt's blogの人に影響を受けて自作PCでLinuxデスクトップを使い始めてから約1年半が経ち、僕の使う環境が一通り満足な状態になったので今どういう構成なのか書いておく。 僕はKeynoteを使う時とか会社のマシンでmacOSも割と使う都合、基本的に操作性がmacOSに近くなるようにしているので、macOSからLinuxに移行したい人の参考になるかもしれない。 *1 そもそも何故Linuxデスクトップを使っているのか 「苦労してmacOSに近づけるくらいなら最初からmacOS使えばいいじゃん」と言われそうだが、今この瞬間は大体以下の理由でLinuxデスクトップを使っている。 趣味で作ったスペックが高めの自作PCにmacOSが入れられない *2 最新のmacOSではKarabinerが使えないが、Linuxでは自作のキーリマッパーが

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 使い方 普通にita

rack-user_agent を作った rack-user_agentという、User-Agentに応じていろいろな判定ができるメソッドを生やすRack::Request拡張を作った。 tagomorisさんのWootheeを使ってRack middlewareでUser-Agentをパースしておいて、 その結果に応じてrequestから簡単にいろいろな情報を得られるようにしてある。 たとえばRailsだとGemfileにgem "rack-user_agent"と書くだけで以下のように使うことができる。 class ApplicationController < ActionController::Base before_action :set_request_variant def index # example request.user_agent #=> "Mozilla/5.0

最強のTwitterクライアント戦争 なんか戦争をやってる人たちがいたので乱入することにした。 日記書いた / 最強のTwitterクライアント作り始めた - 9mのブログ http://t.co/ecq7nT40qp— 友緒利奈 (@9m) August 22, 2015 最強のTwitterクライアント戦争参戦したい— 戦車 (@r7kamura) August 22, 2015 戦争だ…！ / “最強のTwitterクライアント戦争に参戦 - ✘╹◡╹✘” http://t.co/iJ3BAgPvFI— 友緒利奈 (@9m) August 22, 2015 YoruFukurou風のTwitterクライアント 最近デスクトップでLinuxを使い始めたんだけど、YoruFukurouみたいな感じで使えるTwitterクライアントがなくて困っていた。 なので、YoruFukurouを再実