はてなブックマーク

Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.

そろそろ更新も止まってきたし、一旦シーズン1終了的な感じで終わりにしようか、 ついでに振り返りでもやったらいいんじゃない？ と言ったら、じゃあ最初書いてよ、と言われたので書いてみます。 自分としては更新がだんだんとされなくなって自然消滅、みたいなのよりは、 区切りをつけたいと思っていたので、 ひとまずシーズン1はこれにて終了、という事になりました。 別段シーズン2の事を考えて言った事でも無いので、今後の事とかは何も決まってません。 自分個人としてはそのうちまた再開してもいいかなぁ、とは思っています。 外から見ると凄くまともに出来ているように見えるこのMessage Passingだけれど、中はびっくりするほど何も決まってない感じで運営されています。 始まった時には書いている自分もこれが何なのかは良く分からず、なんか技術的な事を書いて回してみよう、みたいな程度でした。 プラットフォームとかも

唐突ですが未来予想をするターンです。10 年後のプログラマ事情（じゃなくてもいいけど）を予想してみたい。 背景としては、むかしむかしの 2005 年に Steve Yegge という当時人気だった blogger が Ten Predictions という記事を書き、それを十年後の 2015 年に Dan Luu (森田が好きな blogger)が採点する、という出来事がありました。我々もいまテキトーなことを書いて 10 年後に採点したら面白いんじゃないかな。という動機。Caveat としては 2005 年の Steve Yegge はテック業界に詳しい若者ブロガーでしたが、2021 年の森田は業界動向とか真面目にウォッチしてないおっさんなのであまり面白い予想は書けない恐れがあります。が、まあそれは仕方なしということで。 一人10件を目標に、あまり保守的でもアグレッシブ過ぎても面白くないの

普段はあんまり未来のこと考えていないので難しいですね。暗いことを予測してあたっても嬉しくないので、こうなるといいな、というものを中心に書きました。 予測 1. 静的型のあるスクリプト言語が人気になり、Python, Ruby に続く第三の選択肢になる この10年で Python や Ruby に型が入ったのはすごいのですが、私が Perl をみて「bless ってなんだよ。普通に class は予約語でいいし、標準ライブラリももっとオブジェクト指向になっていてほしいなあ。」と思っていたように、未来の人々は最初から型があるスクリプト言語を求めるんじゃないか、と思う。 このスマートフォン時代に、人々が最初に作りたいのはスマートフォンアプリのはずで、そこで Kotlin, Swift, Dart (Flutter) あたりを学んだ人にとって、Python や Ruby の実行時エラーってあんまり

序文 つねづね「俺の未来予想の当たらなさぷりには自信がある」と自負しています。特に「XX とか当たるわけないでしょ」と思ったのも関わらず、後になってそれに仕事で関わる、ということが数回起きていて、グーグルで社内オンリー情報だった時代の Chrome や Android を見て、「なんじゃこれ、グーグルがサーバサイド以外やってどうすんの？」と思った二年後に Chrome チームで働いていましたし(その後 Android 関係の仕事もした)、「ニューラルネットの復権！」みたいな話を見て「ワロタ、 C マガかよ」と思ってた二年後にはグーグル翻訳チームに入れてもらっていました。 5年前に書いた未来予想 によると GPGPU は永遠にニッチ、みたいなことが書かれていますが、 CUDA 使ったり、それを倒すべく頑張ったりしているのが最近であります 逆に僕が夢中になったテクノロジーを3つほど挙げていって

強い言葉、有野さんがどのくらい力強くあるいは jerk-ish に発言したのか第三者の我々にはわからないけれど、若干 jerk ぽかったという設定でなんか書いてみたい。 この話はいくつか切り口があると思う。 気の弱いキャラのプログラマでも強い語調の相手に頑張って押し返すべきなのか 自分は時には強い語調で問題をはっきりと伝えるべきなのか めんどくささとトレードオフ 2 は和良さんが書いてくれているのでまず 1 から考えてみる 自分は（おっさん力や seniority によって薄まったとは言え）気の弱い方なのもあり、強く主張されると「めんどくせえなーハイハイ」といって微妙であれなんであれ相手の主張を受け入れる傾向はある。 「めんどくさい」というのは問題の根幹にある気がする。当たり障りのない言い方をすると、議論にはコストがかかる。 わかりやすいコストは時間。コードレビューとかだと、議論のラウンド

議論がおこらないことは誰にとっての問題か？ kzysさんが議論がおこらないことが問題と言っているのを見て、割と説得された部分がある。 けれど、ハンドルを変えて転生とかメンターとかは、自分個人がどう問題に対処するかという話で、 困る対象は自分という前提があるように思う。 自分が困ったおっさんのままで、ますます困った度合いを深める、というのは我々おっさんには由々しき事態ではあるけれど（そしてそれは事実のような気もする…）、 それ以外にもプロジェクトにとっての問題という部分も多いと思った。 だからチームとして、組織としてどうにかしたい問題のようにも思う。 強く押すという問題では無く語気を弱めても議論が起こるべき所で起こらない事が良くある、 というのもなかなか説得される所で、実際語気の問題は原因の全体の中でそんなに多くを占めてないかもしれない。 全く影響が無いとは思わないし、ある程度は押す強さなど

Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.

「ソフトウェア書き直し」の是非はなぜか目の離せない話題(1, 2, 3)で、その手の話があるとつい読んでしまう。自分は仕事では別に書き直しを決断できる立場ではないし、余暇でも特に書き直すソフトウェアがない。他人事。なのに目が離せない。オブセッションと言っていい。なので数年に一度は心の中のリライト話を吐き出して精神の平安を取り戻したい。今日はそんな日です。 Things You Should Never Do インターネットのプログラミング・サブカルチャーに「書き直し・ダメ・絶対」というミームを持ち込んだのは、今からおよそ 20 年前の 2000 年に Joel Spolsky が書いた Things You Should Never Do, Part I – Joel on Software だと思う。(日本語訳は本になっている。昔はインターネットでも読めた気がするんだけど。) これは N

全体的な事を言えば、自分は書き直し反対派と思う。 morritaさんの言う20年前の意見をほぼそのまま現代まで持っている。 頭の硬い古い老人という事だろう。 そういう訳で、そんな古い側の人間が書き直しについてどんな事を思っているのかを書いてみたい。 失敗するケースは割と限定されている ソフトウェアの書き直しには、成功するものと失敗するものがある。 失敗する条件を厳密に挙げるのは難しいけれど、失敗する書き直しは、自分は見れば分かる、と思っている（本当に分かるかは議論の余地があるけれど）。 まずshinhさんの言っている半分素人が挑戦するケースは良く見かける。これはまぁいい。全然良く無いけれど。 それ以外で良く失敗するのは、ある程度の規模、だいたい10万行以上のソフトウェアで、 その時点で多くのユーザーを持っていて、 書き直しにかなりの時間と人がかかる奴が多いと思う。 そしてデスクトップ、iO

個人的な体験 書き直し。カッとなってバーンのやるのは悪手で、リファクタリングのように漸近的とは行かないまでも境界のはっきりした小さな部分問題を上手に切り出してシュッとやるのが良い。皆が書いたのを読んでそんなコンセンサスを確認できました。それができるコードベースならカッとならない気もするけれど。 そういえば個人的な話を書いていなかったとはまじさんに言われて気付いた。 自分は新卒入社した会社でカッとなって書き直しをした結果ひどいデスマをやらかした体験があり、そのトラウマからアンチ書き直し派になった。向井さんの体験と似ていなくもないけれど、自分でやらかしてしまった。ちなみに同じ会社ではより大規模な失敗書き直しが進行中だったし、その後転職した中小零細二社でもやはり書き直し失敗事例を目にした。書き直しの失敗は珍しくないし、そこからリファクタリングの価値を見出すのも自分たちの年代の同時代性かなと思う。

そもそもあんまりそういう助言というものをもらった記憶がないなあ。人の話を聞かないタチで聞き流していたのかもしれないが。 英語で書くか、日本語で書いてから翻訳するか 英語よりも日本語……という話で思い出したけど、大学院生のとき、英語で文章（論文とか）を書くときの指導として「なるべく最初から英語で書いてなれたほうがいい」という指導と、「日本語でまず書いてみて論理構成を検証するべし。それから英語に訳すといい」という指導があるようにおもう。で、自分はわりと後者を聞かされていたが、これは誤りだった……というと語弊があるが、自分には合わなかったな、という結論をえた。 後者の意図はわからなくもない。構成がしっかりしているか、話の理路がたっているか、をただしく検証するべし、というのはただしいし、英語が苦手な状況でいきなり書き始めても語学力の低さに足を引っ張られてそういうことがうまくできないことがある、とい

自分もかずよしさんと同じで、助言とか説教とかあんまり覚えていない。たぶん中二病で天邪鬼だから他のひとのいうことを聞きたくないのだと思う。好みにあわない説教は目がスルーする修正があるので記憶に残らない。アドバイスに一応従ってみている有野さん（若いバージョン）偉いね。 などといいつつ割と権威主義な人間でもあるので、本とかは割と真に受けたり影響を受けたものもある気がする。たとえば「スーパーエンジニアへの道」という古い本がある。 原題は Becoming a Technical Leader で、1986 年版。どういうきっかけでよんだのか忘れたけど(古の記録によると会社に置いてあったらしい)、二十台とかの若い頃に読んで、少しは影響をうけたか、少なくとも印象には残っておいる。その後も何度か繰り返し読んだ。（なお別に本書をお勧めしているわけではない。似たような題材のモダンな本も色々あるだろうし。）

新卒の頃、英語よりもまず日本語を勉強すべき、とか良く言われていた。 ふーん、そんなもんか？と勧められた「理科系の作文技術」や「日本語の作文技術」を読んでみたが 別段なにかを学びとる事も出来ず、日本語の勉強って良くわからんなと結論づけていた。 さて月日は流れ、年齢的にもだいたいキャリアの主要な成果を出しつつある。 ライフスタイル的にもセミリタイアのフェーズに入って随分経った。 だから自分のキャリアに何が必要だったか、一個人の体験としては結論を出して良かろう。 そうして振り返ると「英語よりもまず日本語を勉強すべき」に必要性はなかった。 英語の学習で助けられた事は多いし、英語の学習の不足で困った事も多い。 一方で日本語の不足で困った体験はあまり無い。 自覚がないだけかもしれないけれど、それは英語についても同じことが言える。 今回は、この手の「よく言われているし正しそうに回覧されがちだが自分の体験

Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.

いいかげん性能改善の仕事にも飽きてきたのでクールな新機能とかやってみたいなーと思ったりもするけれど、いまいち勇気が出ない。というのもクールな新機能ってだいたい締切あるじゃない？ 締切のない世界 自分は今の会社に入ってこのから 10 年以上、締切のある大仕事をしたことがない。最初にやっていた新しいAPIをウェブ標準に入れる仕事はろくに仕様もわからないまま一年くらい過ぎていたし（仕様を決めるのも仕事と言えば仕事だったんだけど）、標準化団体にせよ呉越同舟のオープンソースにせよ制御不能な要素が多すぎて誰にも締切なんて決められなかった。 そのあとやっていた巨大リファクタリングみたいなやつも、やはり締切はなかった。今思うとこれは締切があっても良かった気がするが、まわりに締切という文化がなかった気がする。この頃の自分は「この会社には締切ないんだな」と理解していた。これは若干主語が大きすぎだけど、そういう

Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.

自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手

本質的な複雑さ批判 森田が大ファンであるところの Dan Luu が「人月の神話」の Fred Brooks をディスる 記事を書いており、 痛快なのでみんなでこれ読んで与太話しようぜ、という回。(Dan Luu のページは Pocket か Instapaper 必須なのでみなインストールされたし。) ここで批判されているのは Brook の Essential Complexity / Accidental complexity に関する記述。 極めて雑に復習すると、Brooks は「問題には “essential complexity” すなわち “本質的な複雑さ” というのがあるから、 プログラミング言語とかツールとか計算機性能の改善とかで “accidental complexity” / “偶発的な複雑さ” を減らしていっても限度があるよね、 ソフトウェア開発って難しいですね・

Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.

Facebook のオープンソースプロジェクトには、妙にかっこいいものが多い。 企業発 OSS の中でもかっこよさが突出している。 有名どころでは React (2013) と PyTorch (2016) があるけれども、 他にも MySQL のストレージエンジンをとりかえた MyRocks/RocksDB, Microsoft も使い始めた静的解析ツール Infer (これは買収だな), AWS が managed service をはじめるに至った OLAP DB の Presto, Rust で書いてしまった Marcurial Backend の Eden などなど枚挙に暇がない。 プロジェクトの数だけなら他にも数多く公開している会社はあるし、 プロジェクトの規模(つっこまれている人員)が特別多い感じでもない。 が、かっこよさは企業発オープンソースの中で一歩先を行っている、気がす

Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.

自分は仕事で電話機のカメラアプリ開発を手伝っている。 なのでカメラアプリから見るとどうかを中心に議論してみたい。 電話機の CPU はどのくらい使われているのか 電話機の CPU, 最近だと 8 コアくらいある。こいつらを活用したい。 わけだけれど、まず現実にはどのくらい活用されているのか実例を眺めてみる。 ちょっと前に自分のブログで Perfetto というトレーシングツール (プロファイラだと思ってください)を紹介した。 その中で実際にいくつかのアプリのトレースを集めた。手頃な実例になっている。 アプリの起動 このデータ をダウンロードして、ui.perfetto.dev から開いてほしい。 以下画面写真: このトレースは Pixel 2 という電話機の上で TikTok というアプリの起動直後 5 秒間をキャプチャしている。 細かいところはわからなくていいけど、“CPU 0” から

karino2 が 並列プログラムから見たFuture というビデオを作って公開していたので、引っ越しの荷造りをしながら眺めた。 長いのでここにざっくりとした主張をまとめると: Future/Promise (およびその後釜の async/await) は非同期プログラミングで callback hell にならない発明という見方をされているが、 そもそもなぜ callback hell が必要だったかの時代背景が十分に理解されていない。 背景の一つはブラウザ JavaScript のプログラミングモデルにシングルスレッド・ノンブロッキング(イベントループ)という制限があったから。 これは(特にフロントエンド開発者の間では)よく理解されている。 もう一つの視点は SEDA みたいなマルチスレッド・ノンブロッキング環境の必要性で、 こっちはいまいち広く理解されていないように思える。 結果とし