3月の末から Fly.io という会社ではたらいている。 いわゆる Heroku のような PaaS なのだけど、 Cloudflare や Vercel のような、東京の人々には東京のサーバーが、ポートランドの人々にはシアトルのサーバーがリクエストをひろうので速い、というエッジっぽいことができる でも、そこで動くのは WASM や V8 Isolates ではなく、Linux コンテナなので Rails や Django も使える とはいえ Linux コンテナでマルチテナントを隔離するのは怖いので、なかでは Firecracker も使われている いわゆる3大パブリッククラウドのラッパーではなく、いろいろを自前でもっている という特徴がある。これはポジショントークになってしまうけど、WASM などでワークロードをつめこみたいというのは多分にプラットフォーム側の都合なので、エッジでもどこ

32歳、新しい技術を習得する余裕がなく昔取った杵柄でいつまで食えるか不安です 生産性への強迫観念を振り払う儀式としての、子育て そうね、と思ったのでちょっと書いてみる。シアトル在住30代男性です。 私の子供はもう新生児ではないけれど、たとえば20代のときに比べると、勉強の時間は減っている。これは、使える時間が減ったのが半分、体力なのか必死さなのか、一時間あったときに、本を読んだりするのが減ったのが半分というかんじで、たとえばこうやってインターネットで遊ぶかわりに読書したらいいのでは、というところはある。週末や仕事のあとに、勉強会にいったりするのは止めた。 それでも、オープンソース活動は維持したかったのもあり、2人目の子供がうまれた年に、仕事でオープンソースができるようなチームにうつって、いまは containerd などを開発している。日本でオープンソース仕事というと、Ruby コミッタと

Why is building the Ruby environment hard? の、 ソフトウェアは何もしないと壊れる というのは事実ではあるんだけど、それが良いことかというと、どうなのかなあと思う。ほかにも、我々プログラマはつい「ソフトウェアは完成しない」とかいってしまうし、それは雇用のためには良いことなんだろうけど、でも本当に完成しないんだろうか。 Go の logrus の README には、こんな段落がある。 Logrus is in maintenance-mode. We will not be introducing new features. It’s simply too hard to do in a way that won’t break many people’s projects, which is the last thing you want fro

ここ2年くらい、仕事では大体 Go を書いている。jmuk さんが Go言語は、なんというか「ちょうどいい」言語だな、と思っている。異論は認める。 と書いていたけれど、私はやっぱり Scala や Kotlin あたりが好きで、これは変わらなそう。 例えばコレクションを map しているのをみると、私は「なるほど、ここではコレクションの要素数は変わらないんですね」と思う。filter だったら「コレクションの要素数は変わるけど、個々の要素は変わらないのか」ということを、あるいは Result を map していたら「ここではエラーのほうは触らないのね」ということを読みとっている。 こういう意図が、素朴な for ループと、if err != nil だと読みきれなくて、いや真面目に字面を追っていけばわかるんだけど、私が「map するか」と思いながら for ループを書いて、その for ル

Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値

今年から、できるだけシェルスクリプトを書くのをやめようとしている。私が毎日 zsh に打ち込んでいるのも広義のシェルスクリプトだし、自分用の雑なスクリプトを書くことはあるけれど、チームの他の人も将来に使ったり改変したりするようなものは、なるだけ他の言語を使っている。 シェルスクリプトを書くのは難しいし、その難しさは、学ぶに値しないといったら言い過ぎかもしれないけれど、2021年に初心者が取り組むべき問題とは言い難いと思う。 シェルは悪いプログラミング言語である Bash Strict Mode とかを使ってみても、シェルスクリプトには落とし穴が多すぎる。自分で書いたものを自分で使っている分には大丈夫なのだけど、スクリプトがチーム内で使われるようになると、考慮していなかったところ、例えばファイル名に空白文字が含まれるとか、そういうレベルの微妙なところで、ちゃんと書かれていないスクリプトは壊れ

たまに Rust の勉強もかねて何かを再実装しようと思うんだけど、大抵は途中で飽きてしまう。一方で、最近に仕事で使っている雑なスクリプトをきれいに書き直して、これはなかなか楽しかった。というわけで、自分の中での楽しさを書き出してみようという試みです。 自分の生活が便利になった 仕事で書くスクリプトとか、個人的な便利コマンドとかはここの楽しさが大きい。 仕事で関わって製品としてリリースされるものが、自分の生活を便利にするかは、まあ半々くらい。「確かにこれあるといいですね。自分でも使います。」というものもあるし、正直いって自分は使わなそうなものもある。 コンシューマ向け製品だと、自分の好みはだんだんメインストリームとずれてきていて、それは将来に不安を感じる。携帯電話のプッシュ通知とか、なるべく来ないで欲しい。 無理そうなことが出来てかっこいい 昔に作っていた、SIMBL で Mac のアプリを

エンジニアを育てるはなしが、たぶん以下の Takuto Kihira さんの tweet をきっかけに盛り上がっていた。 昨日の飲みで、某CTOが「エンジニアを育てるって言うけど、紀平さん誰かに育てられました？自分で育ったでしょ？だからエンジニアに対しては、頑張れ、としか言いようがないと思うんですよね」って話をしていて、まあ確かにそうだと思った。自分はしかし親に環境を用意してもらったな。本とかPCとか。 私の立場は、Dai MIKURUBE さんの tweet に近い。 エンジニアの成長について「自分は自力で育った」「今まで見てきた人は誰かに育てられたというより自力で育ってきてた」は観察としてたぶん真なんだけど、「だからこれからもそれでいい」は明確に偽だと思うんだよなー。それって各種の職人業が次々廃れてるのと同じことを再現するだけのような気がする 私自身も大学で情報工学を学ぶまえに多少はプ