ファーストシーズン終了 / karino2 - Message Passing
そろそろ更新も止まってきたし、一旦シーズン1終了的な感じで終わりにしようか、 ついでに振り返りでもやったらいいんじゃない？ と言ったら、じゃあ最初書いてよ、と言われたので書いてみます。 自分としては更新がだんだんとされなくなって自然消滅、みたいなのよりは、 区切りをつけたいと思っていたので、 ひとまずシーズン1はこれにて終了、という事になりました。 別段シーズン2の事を考えて言った事でも無いので、今後の事とかは何も決まってません。 自分個人としてはそのうちまた再開してもいいかなぁ、とは思っています。 外から見ると凄くまともに出来ているように見えるこのMessage Passingだけれど、中はびっくりするほど何も決まってない感じで運営されています。 始まった時には書いている自分もこれが何なのかは良く分からず、なんか技術的な事を書いて回してみよう、みたいな程度でした。 プラットフォームとかも
締切こわい / morrita - Message Passing
いいかげん性能改善の仕事にも飽きてきたのでクールな新機能とかやってみたいなーと思ったりもするけれど、いまいち勇気が出ない。というのもクールな新機能ってだいたい締切あるじゃない？ 締切のない世界 自分は今の会社に入ってこのから 10 年以上、締切のある大仕事をしたことがない。最初にやっていた新しいAPIをウェブ標準に入れる仕事はろくに仕様もわからないまま一年くらい過ぎていたし（仕様を決めるのも仕事と言えば仕事だったんだけど）、標準化団体にせよ呉越同舟のオープンソースにせよ制御不能な要素が多すぎて誰にも締切なんて決められなかった。 そのあとやっていた巨大リファクタリングみたいなやつも、やはり締切はなかった。今思うとこれは締切があっても良かった気がするが、まわりに締切という文化がなかった気がする。この頃の自分は「この会社には締切ないんだな」と理解していた。これは若干主語が大きすぎだけど、そういう
Facebook オープンソースのかっこよさ / morrita - Message Passing
Facebook のオープンソースプロジェクトには、妙にかっこいいものが多い。 企業発 OSS の中でもかっこよさが突出している。 有名どころでは React (2013) と PyTorch (2016) があるけれども、 他にも MySQL のストレージエンジンをとりかえた MyRocks/RocksDB, Microsoft も使い始めた静的解析ツール Infer (これは買収だな), AWS が managed service をはじめるに至った OLAP DB の Presto, Rust で書いてしまった Marcurial Backend の Eden などなど枚挙に暇がない。 プロジェクトの数だけなら他にも数多く公開している会社はあるし、 プロジェクトの規模(つっこまれている人員)が特別多い感じでもない。 が、かっこよさは企業発オープンソースの中で一歩先を行っている、気がす
誰かがどこかで使ってる / morrita - Message Passing
自分は仕事で電話機のカメラアプリ開発を手伝っている。 なのでカメラアプリから見るとどうかを中心に議論してみたい。 電話機の CPU はどのくらい使われているのか 電話機の CPU, 最近だと 8 コアくらいある。こいつらを活用したい。 わけだけれど、まず現実にはどのくらい活用されているのか実例を眺めてみる。 ちょっと前に自分のブログで Perfetto というトレーシングツール (プロファイラだと思ってください)を紹介した。 その中で実際にいくつかのアプリのトレースを集めた。手頃な実例になっている。 アプリの起動 このデータ をダウンロードして、ui.perfetto.dev から開いてほしい。 以下画面写真: このトレースは Pixel 2 という電話機の上で TikTok というアプリの起動直後 5 秒間をキャプチャしている。 細かいところはわからなくていいけど、“CPU 0” から
非同期と並列 / morrita - Message Passing
karino2 が 並列プログラムから見たFuture というビデオを作って公開していたので、引っ越しの荷造りをしながら眺めた。 長いのでここにざっくりとした主張をまとめると: Future/Promise (およびその後釜の async/await) は非同期プログラミングで callback hell にならない発明という見方をされているが、 そもそもなぜ callback hell が必要だったかの時代背景が十分に理解されていない。 背景の一つはブラウザ JavaScript のプログラミングモデルにシングルスレッド・ノンブロッキング(イベントループ)という制限があったから。 これは(特にフロントエンド開発者の間では)よく理解されている。 もう一つの視点は SEDA みたいなマルチスレッド・ノンブロッキング環境の必要性で、 こっちはいまいち広く理解されていないように思える。 結果とし
Design Docs のいけすかなさ / morrita - Message Passing
Design docs というのが昔からあまり好きでない。読むのも書くのも好きでない。 仕事で文書を書くのはやぶさかではないけど Design docs はなんとなくいや。 せっかくなのでこのイヤさを言語化してみたい。 Design Docs とはなにか 自分が想定している Design docs は この文章が説明しているようなものだ。 なにかそれなりの規模があるものを作る時に設計やそのトレードオフをざっと文書化する文書。 もっというと一般名詞の design docs ではなく、リンク先に書いてあるような自分の勤務先固有の The Design Docs 文化が好きでない。 「設計やそのトレードオフをざっと文書化する。」 それだけ聞くと割と良いもののような気がして、自分もある時期までは良いものだと思っていた。 「ドキュメンテーション」というのは、プログラミングのポップカルチャーにおいて
ちょうどよさのはなし / morrita - Message Passing
その「ちょうどよさ」ゆえに普及したテクノロジ - アイデアや標準があると思う。 そういうのは、科学や工学でなく匠としてのプログラミングを表している気がして成功が嬉しい。 自分にとって「ちょうどいいテクノロジ」の代表は JSON (2002) と Markdown (2004). どちらも技術的にはさほど大したことはないけれど、どちらも広く使われている。 「ちょうどいいテクノロジ」はこれ以前にも色々あった。UNIX(1969) や HTTP/REST (1991) なんかが思い当たる。 ただ同時代性がないせいか成功が華やかすぎるせいか、まいち親近感がない。 ついでにいうと、自分はもはやこれらに「ちょうどよさ」を感じない。 UNIX の代表 Linux は超巨大ソフトウェアだし、HTTP の最新版 HTTP/3 は随分複雑なプロトコルに見える。 JSON と Markdown は、今のところ当
モノレポ好きじゃない / morrita - Message Passing
自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
