サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
messagepassing.github.io
個人的には TOML は「ちょうどいい」かなあ。YAML の大変さがなくて、Dhall ほど野心的ではない。言われてみると、TOML の作者も GitHub の共同創業者の一人なので、だいぶ有名人ですね。 ちょうどいいインターネット、Gemini 私がここ一年くらい気になっているプロジェクトに Gemini がある。Gemini は Gopher と Web (HTML + HTTP) のいいとこどりを目指すプロジェクトで、行志向のワイヤープロトコルと、その上にのる、これまた行志向の text/gemini フォーマットで構成されている。 ここでいう Gopher は、Go のマスコットではなくて、1993年発行の RFC 1436 で定義されている、Gopher プロトコルのこと。世の中は広いもので、2021年の今現在も Gopher を使っていたり、それでブログのようなことをしている
morrita さん、karino2 さんのいう嫌さは半分くらいわかるかなあ。 「Design Doc 書いてください」というのが、設計が終わったあとに実装がはじまる直線的なソフトウェア開発や、設計が難しい/偉くて実装はそうでもないという、上流工程偏重な職業感を想起させるというのはわかる。無駄な Design Doc が書かれがちなのもわかる。文章がないことに文句を言う人は多いけれど、文章があることに文句を言う人は少ない。でもまあ、無駄な実装よりは無駄な Design Doc の方がマシかなあ。 あと、Design Doc を書かなくてはいけないときは、それなりに大手術になってしまう変更を入れるときで、それは初期の設計のダメさであるとか、機能のつけすぎの現れじゃないか、と思うこともある。炎上プロジェクトには、それを消火してくれるヒーローが現れるように、柔軟性のない巨大ソフトウェアには、それ
Design Doc、自分は無駄なケースが多いと思っているけれど、書いて欲しい場合もある、 という曖昧な立場で、読んでもスッキリしない感じになるかもしれないが、 そういう立場の人も多いと思うので書いてみる。 コミュニケーションの手段としてのDesign Docの有用性は高い(事がある) 設計について相手が考えている事を知りたい時に、Design Docを見せて欲しいと思う事がある。 特にこれから作ろうとしている物に明らかに幾つかの選択肢があって、 それぞれ長所短所があってどれが最善か良くわからない時、 相手が選んだ選択の理由を知りたい。(当然その選択が自分に関係ある場合。) プロジェクトにはいろいろな背景事情があって、 その結果そのデザインが選ばれたと思う。 でも背景とかの事情には必要な事以外あまり興味が無く関係ある事だけ知りたい時、 Design Docとそのレビュー結果を見たい。 技術
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.
Design docs というのが昔からあまり好きでない。読むのも書くのも好きでない。 仕事で文書を書くのはやぶさかではないけど Design docs はなんとなくいや。 せっかくなのでこのイヤさを言語化してみたい。 Design Docs とはなにか 自分が想定している Design docs は この文章が説明しているようなものだ。 なにかそれなりの規模があるものを作る時に設計やそのトレードオフをざっと文書化する文書。 もっというと一般名詞の design docs ではなく、リンク先に書いてあるような自分の勤務先固有の The Design Docs 文化が好きでない。 「設計やそのトレードオフをざっと文書化する。」 それだけ聞くと割と良いもののような気がして、自分もある時期までは良いものだと思っていた。 「ドキュメンテーション」というのは、プログラミングのポップカルチャーにおいて
WCEDという物自体を今回初めて知ったし、 毎日コードを書く事は意識していなかったし、WCEDしてない。 自分の仕事でのコード書きはどんな感じか オリジナルのWCEDとmorritaさんの話は既に結構違う所なので、 仕事でどうなの?という事だと思うのだけれど、 自分は毎日は書いていないと思う。 そもそも毎日働いてはいないのもあるが(今は60%稼働の契約なので週休4日)、 稼働日も毎日はコードを書いてはいない。 今回の仕事は、大雑把には「今から作るプロダクトが業界でNo.1になるのに必要な機能を作ってくれ、何を作るかは好きに決めてくれ(意訳)」みたいな仕事だ。 何を作るかも自分で勝手に考える(相談はするが)し、割と綺麗に切れている大きめの機能をスクラッチから単独で数ヶ月かけて実装するものが多い。 チームが小さすぎてレビューを頼める相手が居ない事情もあり、 レビュー待ちとかミーティングとかはほ
去年一年の仕事を振り返っていて、いまいちコードを書いていないことに気づいてしまった。 プログラマの下っ端がコードを書かずに何をしているかというと、 バグのたらい回し、バグレポートの解析、コードレビュー、メールとか報告とかの自然言語書き、バグのたらい回しとか。 下っ端には下っ端の雑用があり、特に性能問題の分析は無限に時間を溶かしがち。去年はだいぶ溶かしてしまった。 その反省からもうちょっとコードを書こうと、去年のおわりくらいから午前中は雑用をすべてすっぽかしコードを書くことにしてみた。 いわゆる Write Code Every Day (WCED)。 やってみると腰が重くて放置していた積み残しの仕事たちがあれよあれよと片付き、コードも書けて満足度も高く、 なぜこれをやっていなかったのか(答: 色々な圧力があったから)不思議なくらい捗った。のだけれど、ここ一週間くらい行き詰まってきた。 とい
皆の話を読んで、 自分の「仕事の成果を出すためにいつもコードを書く」論は現実というより願望なのだと気づいた。 仕事で成果を出したいならコードを書く以外にもやるべきことは色々あって、 そういうのはさぼらずやったほうが成果はでる。調査とか説得とか協議とか。ただやりたくない。 同じように「よく考える」みたいな曖昧で前の見えない時間の使い方にも不安を感じ、 コードという tangible な存在に頼ってしまう。 コードを頼りに考えを進められるからコードを書く・・・と言えればかっこいいけれど、 自分は必ずしもそういう類のコードを優先しているとは言えない。 一歩下がると、コードを書かずにいる不安が根にある。 会社員プログラマ、偉くなるとコードを書かなくなるのはよく知られた事実だけれど、 偉くない平社員でもあんまりコードを書かない人はいる。 それでも意味のある貢献はできる。組織がでかいと特に。 自分は厳
時間および精神的余裕のなさもあり、ここ数年あまりオンラインの技術読みものを読んでいない。というか真面目に探してない。 オンライン読みもの流通の場は時とともに移り変わるので、置いていかれている感がある。 わかってはいたけれど、みんな何読んでるのかなと気になりはする。 というわけで、皆様が何を読んでるのかきいて周るターンです。 手始めに自分の話をちょっと書いてみたい。 読んでいないもの そもそもの話のきっかけとして、自分は宗教的理由などからあまりソーシャルメディアを見ないようにしている。 (ソーシャルブックマークの類はトップページだけぼちぼちひやかすかんじ。以前はこれもやめていたが今は息抜きとして受け入れている。) おかげで時間を溶かす量は昔より減って、心も平安。けれど先に書いた置いてかれる感に繋がってもいる。 RSS ソーシャルメディアやソーシャルブックマークのような無限にリンクが振ってくる
Go言語は、なんというか「ちょうどいい」言語だな、と思っている。異論は認める。 Go言語の登場時、なんせGoogleが大々的に発表した新しいプログラミング言語であるし、Rob PikeやKen Thompsonといった有名人の関わりもあり、華々しかった。そして、その登場を眺めたプログラミング言語マニアは、そのダサい仕様にわりとすぐがっかりして、興味をなくした。ということがあったと思う。今はGoはけっこう広く使われていて人気もあるけど、ここに至るまでには紆余曲折があった。 Go言語、なにせ2010年代にもなってなんせジェネリクスもない(そのわりにスライスや配列、ハッシュテーブルだけが標準にあり、特別扱いされている)。例外処理もない(これはまぁそのほうがいいだろうという人もいるだろうけど)。そこらじゅう if err != nil だらけ。テストにアサーションもなく、ひたすら地道にif文を書く
その「ちょうどよさ」ゆえに普及したテクノロジ - アイデアや標準があると思う。 そういうのは、科学や工学でなく匠としてのプログラミングを表している気がして成功が嬉しい。 自分にとって「ちょうどいいテクノロジ」の代表は JSON (2002) と Markdown (2004). どちらも技術的にはさほど大したことはないけれど、どちらも広く使われている。 「ちょうどいいテクノロジ」はこれ以前にも色々あった。UNIX(1969) や HTTP/REST (1991) なんかが思い当たる。 ただ同時代性がないせいか成功が華やかすぎるせいか、まいち親近感がない。 ついでにいうと、自分はもはやこれらに「ちょうどよさ」を感じない。 UNIX の代表 Linux は超巨大ソフトウェアだし、HTTP の最新版 HTTP/3 は随分複雑なプロトコルに見える。 JSON と Markdown は、今のところ当
参加する会社ごとにレポジトリが分かれたり、チーム単位で別のレポジトリになるのって、コンウェイの法則っぽいですね。わたしはモノレポは良いものだと思っているので、どういうふうになっているかという話をざっと概観したい。 広く知られているようにGoogle社内はモノレポになってて、だいたいのプロジェクトはこのレポジトリにすべて入っている(例外はあるけれど)。で、実際どんなもんですか、という話についての雑感でいえば、モノレポはわたしのような末端の従業員にはけっこういいものだと思っている。 いろいろメリットがあると思うけれど、インフラというかコアの部分を共通化できるというのが大きい気がする。様々なユーティリティは一箇所にまとまっていて再発明をする必要がない(再発明をする楽しみがない、という面はあるかもしれないけど)。GoogleエンジニアといえばProtocol Buffersを詰め替える仕事だという
私が仕事で開発している firecracker-containerd は、 自分たちのチームが開発している Firecracker Go SDK 同じ会社だけど時差もある別チームの開発している Firecracker Cloud Native Computing Foundation の containerd Open Container Initiative の runc を使っていて、これらは当然のように別のレポジトリに入っている。オープンソースでない社内のコードも、2019年の Interconnecting Code Workshop のショートペーパー、The Issue Of Source Code Repository Management In Large Enterprises で触れられているように、基本的にはモノレポではない。 というわけで、私はモノレポをやったことが
自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手
モノレポについて経験豊富そうな皆さんの話を聞きたい。 まずはその背景から。 会社で分かれるレポジトリ フリーランスをやっていると、たまにいろんな零細企業を集めて一つのサービスを作る場に遭遇する。 人を集める時に、一つの会社だけじゃなくて複数の会社が集まることがよくある。 たとえばマーケティングが強みの会社が自社ではエンジニアを持っていなくて、開発は外部の人たちを集めてやるみたいな。 しかもそれぞれの会社からは一人とか二人だけしか来ないので、 6人の小規模なチームなのに会社は4つあるとかいう状況になったりもする。 そうすると何が起こるかというと、レポジトリが会社ごとに分かれたりする。 「クラウドとフロントの間はAPIを決めましょう、 それでクラウド側がバイナリをリリースして、フロント側がたまにそれをマージしましょう」みたいなフローになる。フロントとバックエンドなんて関わっているのは3人しか居
大企業におけるハイテク私感 大企業下っ端なので全然ハイテクとかしてない。 ここでいうハイテクは、それなりに (CS 的な) 難しさのある、それなりの規模のコードという風に解釈している。 ある程度成熟した大企業だと、インフラ部門とかリサーチ部門とかがあってハイテクなものを専業で作っている。 なのでハイテク指向な人はそういう部門ではたらく傾向がある。 一方のアプリやサービス部門の人は、実製品開発が好きだからそういうチームにいる。 だから個人の性向としてハイテクより仕事を片付けるのを優先しがち。 それを退屈に感じたこともあったけれど、最近は締切を守ってモノを出す姿勢も大事だなと考えるようになった。 なぜならちゃんとモノが出ていくから。大企業、野心的すぎて完成する前にお蔵入りしてしまうプロジェクトもよくあるね。 専業のインフラ部門とは別に、巨大製品チームはインフラ部門やリサーチ部門相当を内部で抱え
ハイテク @Google ハイテク、グーグルにいた時の感覚は morrita さんに近い。「面接の時はアルゴリズム問題とか聞くけど、実際仕事で難しいアルゴリズムとか書いてないよね、簡単な再帰すら書かねーよな」みたいな雑談をよくしていた。11年くらい勤めて、あれはハイテクだったなーと思う自分の作業は 2,3 くらいで、期間としては合計半年から一年くらいじゃないかな。 割と、それで良いのだと思っている。5割の力で、余力を残して働くのがプロじゃないかと。余力があるくらいでできたプロダクトの方が、完成度が高い。持てる技術ギリギリを使って書いたコードは、たぶんバグってるか、開発に時間を使いすぎているか、悪いとその両方。 いざとなれば難しいデータ構造を使いこなすことも、超絶技巧の高速化もできるかもしれないけど、別に困ってないのに導入されたハイテクは単にメンテ性を落とすだけ。普通のコードで要件を満たせる
お仕事で計算グラフなコードを書いた 先日、仕事で計算グラフを構築して変形して実行するようなコードを書く必要があって、 そんな類のライブラリを書いて機能を実装した。コアの部分で1万行くらい。まぁまぁ大変で三ヶ月くらい掛かった。 DSLで計算グラフを構築し、 それをいろいろと操作し、最後に生成されたIRをなんらかの形で実行する。 ここ数年、こうした形で新しいものがいろいろ生まれているように思う。 古くはLINQ、より最近だとTensorFlowとかHalideとか。 あまり詳しくないが分散ビルドなどもこうした形式だとか。 そういう訳で近年この手の、実際にコードと実行の間に一旦シンボリックなグラフを置いて、 それをいろいろ操作する事で、そのまま実行するのでは得られない付加機能をつけるのは一般的になっている気はしていた。 でもそれを自分で実装するのは今回初めてで、おぉ、これが噂のあれかという気分。
From kzys: みなさんがするすると読んだものを列挙できるのにちょっとびっくりしているんですが、 ブックマークというか、PDF もふくんだ読んだものの管理ってどうしてます? そこそこのインターネット中毒者であるところのわたくしから・・・。 といっても家事子守とかがあると管理が必要なほど沢山のテキストを読めないので、今はそんなにがんばってない。 近況ニュースレター ここ二年くらい簡易 journal として Twitter の代わりに Notion や WordPress で箇条書き公開日記みたいな記録を つけてる。一週間で 1 ページ。 Fragments と読んでいる。 この Fragments の中に読んだものへのリンクと感想を並べ、ブックマークがわりにしてる。 これは世間の一部の人が Twitter にリンクを蓄積しているのと似たようなものだと思う。 公開する意義があるのか怪し
私はむかし Scala が好きだったので、あんまり流行らなかったのは残念です。いや、Scala 3 が Developer Preview に入る年の瀬に過去形で語るのもよくないけれど。 ランタイムが同じ言語を売り込むのは難しい C# と F#, Java と Scala みたいなランタイムが同じ言語は、既存のライブラリなどを使えるという利点はあるけれど、客観的な性能指標とかで明確に「勝つ」ことはなくて、チーム全員を説得するのが大変だと最近は思う。 ファイル一つをコピーすれば動くような実行ファイルを作りたければ Go で、メモリ安全性は手放したくないけれど、ガベージコレクションや大きいランタイムに起因する色々が嫌なら Rust で、みたいな分かりやすさに比べると、F# や Scala の良さって、言語のセマンティクスやシンタックスの話になりがちで、ちょっと弱い。 変数に再代入しない、という
Message Passing は N 人のプログラマ (jmuk, karino, kzys, morrita, shinh) が話をふったりふられたりしつつプログラミングやソフトウェア開発の雑談をするブログです。意見は書き手個人の見解です。どうみても。 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.
話をふられてなんなんだけど、最近あんまりML系の言語を使ってみたりしていないんだよな。最後になにかやったのは、min-camlがwasmを吐けるようにしたことで、あれはOCamlで書いたのだったか(min-camlはセルフホストではなく、OCamlで書かれている)。公開もしていない……自分で書いた部分がかなりmessyで気が滅入る感じになってしまったので放置している。 Haskellの型クラス そういえばポッドキャストで最近、Haskellの歴史の論文を読んだのを紹介した。2カラムで50ページ以上という長大なる論文なので仕方なくかなりの部分を割愛したが、なかでも型クラスの話はほとんど触れずに飛ばしたように思う。ところがあの論文は “being lazy with class” という副題がついてるくらい、なにかと型クラスの話をする論文なのだった。論文著者の気持ちとしては、型クラスこそがHa
F#とかML系言語の話 最近どこでもF#いいよしか言ってない気もするけれど、なかなかいいですよ、F#。 Microsoftエコシステムの外の人間の方が使いみちが多いというのが面白いところに思う。 Windows使ってる人じゃなくてMacとかLinux上でコマンドラインでなにかやりたい人にマッチしているのが盲点になりがち。 自分がまさにその盲点にはまってたんですが。 MacとかUnixでも動いて、ファイルのmoveとかcopyとかのシステム周りが一通り揃っていて、 新しい圧縮だとか通信だとかにもちゃんと大企業が対応してくれて(.NETがだけど)、 VSCodeのextentionも良く出来ていて、なおかつML系言語。 Unix系コンソールでのML系言語の時代来たな! とか思っていたら、和良さんに DarkもOcamlからF#の時代ですよ! とか教えてもらって、 リンク先を読んでたらReaso
なにか話すことはないかと Hacker News をみていたら(ろくでもない)、 Youtube や Gmail など Google のサービスが一時間落ちていたというニュースで 盛り上がっていた。担当者の想像するだけで胃が痛い。 森田はクライアントサイドで仕事をしているので、この手の outage は起きない。 けれど自分のところに担当したくないイヤなバグが回ってくることはたまにある。 そういうのを精神衛生を害さない程度で思い出してみたい。 A Ship Blocker 何年か前にカメラアプリのチームに入った直後、ハカソンでカメラのビューファインダに OpenGL のシェーダで簡単なエフェクトをかけるコードを書いた。 ハカソン最終日のデモで成果を紹介すると、より洗練されたリアルタイムエフェクトを近隣のアルゴリズムチームが長いこと構想していたことがわかった。 そこで彼らが開発していたエフェ
このページを最初にブックマークしてみませんか?
『Message Passing - はなしをふったりふられたり』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く