サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
messagepassing.github.io
なんとなくしょんぼり失敗なトーンで話が進んでますが、どうなんでしょうね。個人的にはまあまあ面白かったし、特に皆が書いてくれたものを読むのはすごく楽しかったので、うまくいった気もしています。 ことの発端 Message Passing がどうやって始まったか一年前だというのにすでに思い出せないので、森田が皆様に送った提案のテキストを発掘しました。貼っておきます: RFC: Unbound Calls 最初は Message Passing という名前ではなかったらしい・・・。のはさておき、最初は「お題にぶらさげる」スタイルではなく、公開書簡、バトンっぽいスタイルを考えていました。でもそれをどう実装していいのか良いアイデアがなかったので現在のスタイルに落ち着きました。 書く敷居の高さは開始して数カ月くらいの割と早い段階で感じており、少し議論しました(森田のメモ)。その結果、全員揃わなくても出す
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さんが議論がおこらないことが問題と言っているのを見て、割と説得された部分がある。 けれど、ハンドルを変えて転生とかメンターとかは、自分個人がどう問題に対処するかという話で、 困る対象は自分という前提があるように思う。 自分が困ったおっさんのままで、ますます困った度合いを深める、というのは我々おっさんには由々しき事態ではあるけれど(そしてそれは事実のような気もする…)、 それ以外にもプロジェクトにとっての問題という部分も多いと思った。 だからチームとして、組織としてどうにかしたい問題のようにも思う。 強く押すという問題では無く語気を弱めても議論が起こるべき所で起こらない事が良くある、 というのもなかなか説得される所で、実際語気の問題は原因の全体の中でそんなに多くを占めてないかもしれない。 全く影響が無いとは思わないし、ある程度は押す強さなど
「ソフトウェア書き直し」の是非はなぜか目の離せない話題(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 年版。どういうきっかけでよんだのか忘れたけど(古の記録によると会社に置いてあったらしい)、二十台とかの若い頃に読んで、少しは影響をうけたか、少なくとも印象には残っておいる。その後も何度か繰り返し読んだ。(なお別に本書をお勧めしているわけではない。似たような題材のモダンな本も色々あるだろうし。)
新卒の頃、英語よりもまず日本語を勉強すべき、とか良く言われていた。 ふーん、そんなもんか?と勧められた「理科系の作文技術」や「日本語の作文技術」を読んでみたが 別段なにかを学びとる事も出来ず、日本語の勉強って良くわからんなと結論づけていた。 さて月日は流れ、年齢的にもだいたいキャリアの主要な成果を出しつつある。 ライフスタイル的にもセミリタイアのフェーズに入って随分経った。 だから自分のキャリアに何が必要だったか、一個人の体験としては結論を出して良かろう。 そうして振り返ると「英語よりもまず日本語を勉強すべき」に必要性はなかった。 英語の学習で助けられた事は多いし、英語の学習の不足で困った事も多い。 一方で日本語の不足で困った体験はあまり無い。 自覚がないだけかもしれないけれど、それは英語についても同じことが言える。 今回は、この手の「よく言われているし正しそうに回覧されがちだが自分の体験
いいかげん性能改善の仕事にも飽きてきたのでクールな新機能とかやってみたいなーと思ったりもするけれど、いまいち勇気が出ない。というのもクールな新機能ってだいたい締切あるじゃない? 締切のない世界 自分は今の会社に入ってこのから 10 年以上、締切のある大仕事をしたことがない。最初にやっていた新しいAPIをウェブ標準に入れる仕事はろくに仕様もわからないまま一年くらい過ぎていたし(仕様を決めるのも仕事と言えば仕事だったんだけど)、標準化団体にせよ呉越同舟のオープンソースにせよ制御不能な要素が多すぎて誰にも締切なんて決められなかった。 そのあとやっていた巨大リファクタリングみたいなやつも、やはり締切はなかった。今思うとこれは締切があっても良かった気がするが、まわりに締切という文化がなかった気がする。この頃の自分は「この会社には締切ないんだな」と理解していた。これは若干主語が大きすぎだけど、そういう
自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手
自分の最近の仕事はC++でアプリを書く、というものなので、Brooksの主張にかなり近い事をやっていますね。 C++はいろいろな事情でライブラリが使えない事が多いので、スクラッチから作るのが正当化される事もままある。 それがまさに時代遅れでもあるのだけれど。 そのまま複雑さの話を続けてもいいのだけれど、 自分がDan Luuのブログで面白いと思ったのは、複雑さよりも古典を批判する、という部分。なのでその話をしてみる。 持ち上げられ過ぎる古典 人月の神話は非常に良い本で、そこから引き出すべき教訓も多いと思う。 だが、さすがにコンピューティング事情は随分と変わっているので、現代には当てはまらない事も多い。 そしてそれは当たり前と思う。今となっては誤りになってしまった記述があったところで、Brooksの知性を疑わせるものでは無い。 問題なのは、その当たり前の事をわざわざ言わないといけない状況だ。
本質的な複雑さ批判 森田が大ファンであるところの Dan Luu が「人月の神話」の Fred Brooks をディスる 記事を書いており、 痛快なのでみんなでこれ読んで与太話しようぜ、という回。(Dan Luu のページは Pocket か Instapaper 必須なのでみなインストールされたし。) ここで批判されているのは Brook の Essential Complexity / Accidental complexity に関する記述。 極めて雑に復習すると、Brooks は「問題には “essential complexity” すなわち “本質的な複雑さ” というのがあるから、 プログラミング言語とかツールとか計算機性能の改善とかで “accidental complexity” / “偶発的な複雑さ” を減らしていっても限度があるよね、 ソフトウェア開発って難しいですね・
皆さんはじめまして。ゲストとして呼ばれた、secondlife です。Tateno Culture といった形で以前森田さんが書いていたが、あれは Tateno Culture というよりは Hatena Culture の話だと思っています。なので、今回はインフォーマルな文章という主題とはずれるかもしれませんが、自分はなぜそんな感じの文章を書いていたのか、というのを当時のはてな時代を振り返り書いてみようと思います。 はてな社に居た当時、これが皆さんの想定するインフォーマルな文章かはさておき、さまざまな社内向け文章を社内の全員、とは言わないまでも、7-8割の人がけっこう書いていた。 自分もしょっちゅう書いていたのだけど、なぜ書いていたのかを今更考えると、それはひとえに『楽しかったから』だった。 なぜ楽しかったのか 当時は2006年頭、自分は15人目の社員として会社にジョインした。入社すると
Facebook のオープンソースプロジェクトには、妙にかっこいいものが多い。 企業発 OSS の中でもかっこよさが突出している。 有名どころでは React (2013) と PyTorch (2016) があるけれども、 他にも MySQL のストレージエンジンをとりかえた MyRocks/RocksDB, Microsoft も使い始めた静的解析ツール Infer (これは買収だな), AWS が managed service をはじめるに至った OLAP DB の Presto, Rust で書いてしまった Marcurial Backend の Eden などなど枚挙に暇がない。 プロジェクトの数だけなら他にも数多く公開している会社はあるし、 プロジェクトの規模(つっこまれている人員)が特別多い感じでもない。 が、かっこよさは企業発オープンソースの中で一歩先を行っている、気がす
自分は仕事で電話機のカメラアプリ開発を手伝っている。 なのでカメラアプリから見るとどうかを中心に議論してみたい。 電話機の 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 みたいなマルチスレッド・ノンブロッキング環境の必要性で、 こっちはいまいち広く理解されていないように思える。 結果とし
Design docs への温度感も、design docs といって想定するものも、けっこう個人差があるのがわかった。 自分は Google がもてはやされていた時代に会社の外からさぞかし良いものに違いないと眺めていた時間が長く、 そのときの印象を拭いきれていないのかもしれない。 会社カルチャーの宣伝を真に受けない大人になったのは、もうちょっとあとなのだった。 ただ design docs への高い期待値はテンプレートにも織り込まれている面がある。 テンプレートを無視すればいいとかずよしさんは言う。じっさい自分は無視しているけれど、 他の人が使う限り冗長で読みにくい design docs が回覧されてきてしまう事実は変わらないんじゃないかな。 Writing Culture むかいさんのいう Chrome の design docs は テンプレート も含め社内のものとは独立して公開さ
僕は Design Doc に対して、あまり感情を持ってない。「Design Doc は最高です!」みたいな話を聞くと鼻白むものもあるけど、有用なケースもあると思う。ただ好悪は置いておいて、めんどくさいから書きたくない。実際のところ、ほぼ書いたことがない。 よりよい未来のため Design Doc は未来の失敗を回避するために有用なのはわかる。特にグーグルのサーバサイドの文化という気がするんだよなあ。グーグルは共有のインフラがすごく多くて、共有のライブラリもものすごく多くて、全てを把握してから開発に入るのは不可能。ひょっとしたら同じものあるかも、と思いつつも Design を書いたら、それは XX でできるよ、ということはありそう。 あと、グーグルの Design Doc のテンプレートには privacy concerns や security concerns という項目があって、こう
次のページ
このページを最初にブックマークしてみませんか?
『Message Passing - はなしをふったりふられたり』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く