UNIX Domain Socket の SO_SNDBUF, SO_RCVBUF についての覚書

macOSLinuxUNIX Domain Socket の SO_SNDBUF, SO_RCVBUF について調べていた。


会社で @kurotaky のトラブルシューティングの相談を受けた際の覚書。

下記のように UNIX Domain Socket を挟んで IPC しているコードがあり、macOSLinux で挙動が違っているのを調べていた。Linux では Go Ethereum が送ってくるデータを全部読み出せるが、macOS だと一部 ( 8192 バイト 注1 ) しか読み出せないとのことだった。

Ruby のコード <----- UNIX Domain Socket -----> Go Ethereum

色々調べてみたところ、macOS / LinuxUNIX Domain Socket のデフォルトの SO_SNDBUF, SO_RCVBUF (注2) が違うことで、Ruby 側で 1回の recvmsg(2) で取り出せるデータのサイズが異なっているのが問題だったようだ。


Semantic Software Design - Chapter 2. The Production of Concepts


2章の途中まで流し読み。抽象度の高い話が続いていて、咀嚼できない。実践的な話だけ拾い集めて読む。3章に入ると「脱構築」や「デリダ」とか出てくるぽくて、そこまで風呂敷広げるんかい〜 。そういうこともあって、Google 翻訳 / DeepL 翻訳で読んでるとちょいと辛い感じがある

Part of the work of the new architect-creative is to help create those requirements, both functional and nonfunctional. To see what needs to be done, what might work, what structure accounts for what we think we want the system to do, or what we think someone else we’ve never met might want or need the system to do three years from now when it’s harder to change and how to accommodate that.


This book has a single primary purpose among many purposes: to help you better design software. To do so, it advances a new model, a new approach, a new set of ideas and tools called semantic software design.


抽象度の高い話が続いていて迷子になりそうなところで、なんのための本なんだっけ? を改めて再確認する

The problem with software—a chief reason our projects fail—is a failure of our language. We are not architects. Not even close. We do not build buildings with an obvious and known prior purpose, which is an approximate copy of the same kind of building people have been making and using for thousands of years, using tangible commodity materials on a factory line. Quite the opposite.


あんちぽさんか、しばたさんが、ソフトウェアってコード書き出すまでは頭の中にあるもんだから みたいな話をずっと前にしてたの思い出す。

Accomplish, Avoid, Fix

To be useful in a typical software project, your concept will generally be about one of three things: accomplishing something, avoiding something, or fixing something:



顧客が達成したいこと、避けたいこと、修正したいことを考える。文章で、この質問に答えてください。 誰が、いつまでに、どのような理由で、何を望んでいるのか?

Divergent and convergent thinking

As you work through your concept, you should go through two stages, divergent thinking, followed by convergent thinking.



convergent thinking は以下の通り続く

1. What absolute constraints are known?
2. How might these candidates fit within a budget, if known?
3. How might these candidates fit within a timeline?
4. What known elements of the business or technology strategy do these candidates support?
5. What new opportunities does this create?
6. What positive and negative elements of our current landscape of People, Process, and Technology does this enhance or aggravate?
7. What people or roles would need to approve or work together with these candidates?


ここで 著者の Concept Canvas が図示で紹介される


1. Concept statement
2. Statement of need
3. Alignment with strategy
4. Idea components
5. Path forward


Semantic Software Design - Chapter 1. Origins of Software Architecture


1章を流し読み。目に留まった箇所の引用を掲載する。引用の翻訳は DeepL による。

This is a way of saying that software didn’t even know it existed as its own field, separate from hardware, a mere 50 years ago. Very smart, accomplished professionals in the field were not sure whether software was even a “thing,” something that had any independent value.



The term “architect” as used in software was not popularized until the early 1990s. Perhaps the first suggestion that there would be anything for software practitioners to learn from architects came in that NATO Software Engineering conference in Germany in 1968, from Peter Naur:

ソフトウェアで使われる「アーキテクト」という言葉が一般化したのは、1990年代初頭のことです。おそらく、ソフトウェアの実務家がアーキテクトから学ぶべきことがあるという最初の提案は、1968年にドイツで開催されたNATOソフトウェアエンジニアリング会議において、Peter Naur氏からなされたものでしょう。

提案自体はずいぶんと古いものらしい (ただし、続く本文で The problem with Naur’s statement is obvious: it’s simply false. It’s also unsupported. として、声明自体が間違っていると主張されている)

Dividing roles into distinct responsibilities within a process is one useful and very popular way to approach production in business. Such division makes the value of each moment in the process, each contribution to the whole, more direct and clear. This fashioning of the work, the “division of labor,” has the additional value of making each step observable and measurable.

ビジネスにおける生産活動のアプローチとして、工程内での役割を明確に分けることは有効であり、非常によく知られている方法の一つです。 このような分割により、プロセスの各瞬間の価値、全体への各貢献がより直接的かつ明確になる。このような仕事の組み立て、すなわち「分業」には、各ステップを観察し、測定できるようにするという付加価値もある。

GitHub Actions で一個のステップ実行時間が長くデバッグが大変だったのを、分割して解決しようとした ... というのを思い出したりした。その他、日々の開発でも意識せずにやってることもあるだろう



インシデントマネージメントについての覚書エントリ - Modern System Administration By Jennifer Davis


12 Managing Incidents の章で オンコール対応とインシデント管理についてページが割かれていた

12. Managing Incidents

インシデント管理の目的を The aim of incident management is to minimize the damage, costs, and recovery time. と唱えてから

  • インシデントの定義は組織によって異なる
  • Blameless な組織文化
  • 役割と責任の分担
  • コミュニケーションの確立
  • インシデント後のふりかえり ( postmortem, after action review ... )

... あたりをさらっと触れている内容だ。よく見かける感じのサブテーマ・構成で書かれている。SRE 本や PagerDuty のドキュメントあたりを読んだことがある人なら、目新しい記述はさほど多くはないだろう。

可観測性とか IaC とか デファクトになった感のあるテーマも抑えてあって、「なるほど これがモダンか」と、さらっと読み流すのによいボリュームの書籍

toruby 175th に参加しました - セコンさん おいで那須

juen29 さんと連れ立って、セコンさん ( @hotchpotch ) さんが初参加の回でした。おいで 🍆 〜




セコンさんの Python トークが主題。

Python の言語仕様の話 (Ruby と比較して言語のパラダイムを比較する ) から、型ヒントの話、機械学習の話までだーっとお話を聞かせてもらう回だった。内容がすごい密度なんだけど、用語や論旨が的確でわかりやすいの、さすがセコンさん節って感じで、懐かしい気分にもひたれた。



会が終わった後に、よねざわさん, セコンさん、june29さんと フライングガーデンで肉

↓ に載ってる系列店。


いまいまは 会食もできる状況なので、よかったよかった。

この辺だと自転車のお店はどこなんだ? とか、みんな どこで知り合いになったのだ? とか、観光にくる人の那須塩原と住んでる人の那須塩原のイメージの食い違いだとか ... そんな話をした。