blog

はじめに 「WOKE CAPITALISM 意識高い系資本主義が民主主義を滅ぼす」を読んだ。 デヴィッド・グレーバーを何冊か読んでみて、アメリカの文化に興味を持ったのでこの本を読んでみた。 本の内容 現在の英語で WOKE という単語は、日本でいう「意識高い系」と同じ意味でも使われているらしい。 そのため WOKE CAPITALISM は、意識高い系資本主義という意味になる。 現在のグローバル企業は、社会問題（SDGs など）の解決に取り組むようになってきた。 こういった社会全体の流れを指して、 WOKE CAPITALISM と呼んでいる。 この社会変化は善か悪かを考えたのがこの本である。 本では冷戦あたりから企業の社会的役割の変化を論じながら、たくさんの例を示して WOKE CAPITALISM について考察している。 とくに、アマゾンのトップの例は面白かった。 アマゾンのトップは、環境問題に取り組むために個人資産で財団を作ったにも関わらず、アマゾンは節税をし続けていてアメリカの企業の中でも納税率は低い。 環境事業は公共であるため本来は税金で賄うべきであるが、それをアマゾンは個人の財団で実施しようとしている。 これが意味することは、民主主義によって決められたリーダーが公共事業を実施するのではなく、金持ちが自分の意志で公共事業を実施する方向に変わってきているということである。 この問題点は、民主主義によって決められたリーダーではなく、単に金持ちが公共事業を実施してしまう点である。 これは昔の封建制に戻っているような感覚がある。 他にも企業が刑務所に本を寄贈する一方で、アメリカ社会の投獄率が高い例も示している。これも参考になった。 私の考え 私も日本における WOKE CAPITALISM の一例を見つけた。 日本全国の小学校へ６万個の野球グローブを寄贈 https://company.newbalance.jp/press/2023/p-64679 これは、学校にグローブを寄付しているので、一見すると良いことのように見えるし、実際に良いことなのかもしれない。 ただ、企業が宣伝目的で学校を使って良いのだろうかと問われると、疑問が残る。 このような宣伝目的の慈善事業だけでは、教育で本当に解決すべき問題を解決することはできない。 例えば、貧困層が教育を受ける機会が少ないという問題は、ニューバランスが解決してくれるだろうか。 そのため、宣伝目的の寄付だけではなく、民主主義の立場から教育について真剣に考えた上で改善しないといけないはずである。 その上でこういった企業の行動は、民主主義の議論を弱める働きをしているという問題点は確かにあると思う。 例えば、これからは企業が教育問題を解決してくれるから民主主義の議論をしなくてもいいという考えになるかもしれない。 企業の宣伝目的の慈善事業がアメリカ社会にはありふれていてそれが民衆から賞賛されているならば、日本とは文化が違うなとは思う。 まだそこまで日本では WOKE CAPITALISM が侵食していない。 ただ、日系企業はアメリカ企業の考えを取り入れた方がいいという意見が日本に多いので、こう言った宣伝目的の慈善事業は今後増えてくのかもしれない。 終わりに 新たな視点を与えてくれる面白い本だった。またアメリカ文化を知ることもできた。 歴史を知らずに適当に本を読んでるから、思想が偏ってく気がする。 こういう考えもあるよ程度で読まないといけないな。

2023年の振り返りと2024年の抱負を書いておく。すぐ忘れちゃうので 2023年の振り返り 一年を振り返るとこんな感じだった。 1月〜3月: AWSの資格を集めてた。 4月〜6月: AIの勉強しながらzennに記事を書いてた。 7月〜9月: C言語のコンパイラ作ったりGPT-4で遊んだりしてた。 10月〜12月: 本読んだりOS自作や現代ポートフォリオ理論を勉強したりしてた。 1月〜3月:AWSの資格を集めてた。 2022年の11月後半ぐらいから2023年の3月までAWSの資格を集めてた。 この頃はAWS使えばすべての課題を解決できると信じ切ってて、割と洗脳状態にあった。 資格取り終わってしばらくAWSの勉強から離れてみると、AWSって高いし設定項目も多すぎるので、そこまでいい製品ではないような気がしてきた。 たとえばこの記事とかはAWSの価格が高すぎることについて言及している。 また、最近になってほとんどの企業はAWSをAWSの言う通りに使ってるわけではないこともわかってきた。 資格で出てくるベストプラクティスって構築するのがすごく難しいし、そのベストプラクティスを知ってる人が少ないので、実際には別の構成となってることが多い。 ベストプラクティスを守るのが常に正義ってわけでもないので、この構成はベストプラクティスじゃないなぁって思いながら傍観している。 結局、正解なんてないわけだし。 あと、JavaScriptやReactやAWS Amplify周りの勉強も少ししていた。 そもそもAWSの資格を集め始めたのは、TypeScriptでCDKを書くのが面白そうだったからで、資格集めが一段落したタイミングでJavaScriptの勉強をしていた。 ブラウザのJavaScriptとnodejsの違いを理解したのとJavaScriptの実行モデルが複雑なこととかを学んだ。 それに関連してReactの勉強もした。 関数コンポーネントとかReact HooksとかReduxとかが面白かったことを覚えている。 AWS Amplifyも少し触った。 GraphQLでサーバー側のデータベース更新のイベントをブラウザ側に通知するというのが面白かったことを覚えている。 この辺は進化が激しすぎるので、必要になったタイミングで勉強するようにして、深入りはしないようにしたい。 4月〜6月: AIの勉強しながらzennに記事を書いてた。 4月に自作PCを作った。記事 この自作PCでDeep Learningの勉強していた。 CNNとRNNあたりまで知ってたけど、その先のことを知らなかったので勉強した。 結果として以下の知識を得られた。 U-Net: 記事 VAE: 記事 DCGAN: 記事 LSTM: 記事 Transformer: 記事1, 記事2 BERT: 記事 それぞれのモデルについて自分でデータ探してきて動かしたので、理解度は高いと思う。 また、最新のモデルになればなるほど自分で学習させるのが難しいこととわかった。 あと自作PCでkubeflowを動かしたくてk8sも勉強していた。 k8sの勉強は中途半端になっている。 k8sって理想は素晴らしいけど実際に扱うのは難しすぎると現段階では考えている。 7月〜9月: C言語のコンパイラ作ったりGPT-4で遊んだりしてた。 Cコンパイラ自作の記事を見つけて面白そうだったので、Cコンパイラを自作し始めた。 途中で中断したりして2024年1月になってもまだ完成していない。 とりあえずセルフホストまではやろうと思っている。 コンパイラの自作をやってパソコンの仕組みとかC言語のこととか何も知らなかったことに気づいた。 コンパイラを作る中で得た細かい知識はZennのスクラップにまとめている。 GPT-4を使うようになった。 LibreChatというOSSからAzure OpenAIのGPT-4を使っている。 LibreChatが応援したくて、Issue立てたりThird-Party Toolsにプルリクを送ったりした。 また、RAGを作りたくていくつかのベクトルDBも試してみた。いくつか試した感じだとMongoDBとOpenSearchが使いやすかった。 この分野は成長が早いので新製品が出るたびに勉強してたらきりがないので、ある程度時間が経ったら勉強したい。 個人的にはDynamoDBのベクトルDB機能かCloudflare Vectorizeに期待したい。 少し試した感じだとベクトルって結構容量が大きいので、すべてのデータにベクトルを付与して保存するようになったら、クラウドの費用が上がりそう。...

はじめに デヴィッド・グレーバー「ブルシット・ジョブ――クソどうでもいい仕事の理論」を読んだ。 デヴィッド・グレーバーの前作「官僚制のユートピア」を読んで1面白かったので、次作の「ブルシット・ジョブ」を手に取った。 結構有名な本らしい。 序 ブルシット・ジョブ現象について メモ この本は「社会は無益な仕事であふれかえっている」という著者の直感を確かめることから始まる。 「ブルシット・ジョブ現象について」という記事を雑誌に書いて、著者はその直感を世に示した。 この記事を書いたことで、様々な分野から自身の仕事がブルシットであるというメッセージが寄せられた。 これによって、著者は無益である仕事が社会に溢れかえっていることを確信し、その思考を発展させてこの本にまとめた。 感想 本の書き出しとしてすごく面白い。 人間の思考とは直感から始まるので、こういう書き出しは楽しく読める。 論文もこういう感じで書いてくれたらいいのに。 1 ブルシット・ジョブとはなにか？ メモ この章では、「ブルシット・ジョブ」について定義づけを行っている。 軍隊の部屋の引っ越しや美容師やマフィアの殺し屋などいくつかの仕事を例に挙げて、それらの仕事がブルシットかどうかを判断し、ブルシット・ジョブの定義を行っている。 「ブルシット・ジョブとは、被雇用者本人でさえ、その存在を正当化しがたいほど、完璧に無意味で、不必要で、有害でもある有償の雇用の形態である。とはいえ、その雇用条件の一環として、本人は、そうではないと取り繕わなければならないように感じている。」 感想 それぞれの働き手の主観によって定義づけするのが良くないみたいな議論があった。社会学だとそういうもんなのかな。 2 どんな種類のブルシット・ジョブがあるのか？ メモ この章ではブルシット・ジョブの分類を行っている。 ブルシット・ジョブを「取り巻き」、「脅し屋」、「尻ぬぐい」、「書類穴埋め人」、「タスクマスター」に分類している。 「取り巻き」：誰かを偉そうに見せたり、偉そうな気分を味合わせるという、ただそれだけのために存在している仕事。 例としてブローカーの代理で電話をかけるためだけに雇われている人を紹介している。 この人は「〇〇さんの代理としてお電話差し上げました。」っていうことで〇〇さんを偉そうに見せるのが仕事らしい。 「脅し屋」：その仕事が脅迫的な要素を持っている人間たち。 例として、化粧品の CM に出ている女優の映像を加工をする仕事を上げている。 映像の加工という仕事は、昔は映画の宇宙船をリアルに見せて、それを観客に見せて感動させるのが仕事だった。 ただ現在は女優の顔のシミを飛ばして肌を真っ白にして、それを CM として流してテレビの前の人の肌に欠陥があるように思わせるのが仕事である。 これも脅し屋に分類される。 他にもコールセンターで営業電話をする仕事に一部も脅し屋に分類している。 「尻ぬぐい」：組織に欠陥が存在しているためにその仕事が存在してるにすぎない雇われ人である。 例として、大学で部屋の工事を頼んだのに大工は来なくて大工が来ないことを謝る人がきたという著者の経験を述べている。 この謝だけの人を尻ぬぐいと呼んでいる。 謝る人を雇わずに大工を雇えばいいのではないかと書かれている。 「書類穴埋め人」：組織が実際にやっていないことをやっていると主張できるようにすることが主要ないし唯一の存在理由であるような仕事である。 例として海外の企業が不正な取引を実施していないかを調査する信用調査会社を上げている。 この信用調査会社は実際にはネットで 1 時間や 2 時間調べた内容を、専門用語をたくさん使って報告書を書くことで成り立っている。 実際にはほとんど企業の調査などしていないが、調査していると主張できるようにするから書類穴埋め人に分類される。 「タスクマスター」：タスクマスターは二つに分類される。 第一類型は、他人への仕事の割り当てだけからなる仕事である。これは取り巻きの亜種として分類しても良い。 第二類型は、ブルシットジョブをしている人を監視して、新たなブルシットジョブを作り出す仕事である。 例は長いので省略。 二次的ブルシットジョブとは、ブルシットジョブで成り立っている会社のビルの清掃や電気工事を請け負う雇用形態のことである。 この仕事そのものは清掃員や電気工事士であるためブルシットジョブには分類されていないが、そもそもブルシットジョブで成り立っている会社が存在しなければ、清掃員や電気工事士は雇われないため、二次的ブルシットジョブと呼ばれる。 感想 ブルシット・ジョブの分類をみた。 生活してると身の回りのかなりの割合がブルシットジョブに分類されている気がしてくる。 CM は半分ぐらい脅し屋だし、やってる感を出すための書類穴埋め人や、何もしてないタスクマスターも見られる。 むしろ現代社会ではブルシットジョブでない仕事をすることのほうが難しいのではないか。 3 なぜ、ブルシット・ジョブをしている人間は、きまって自分が不幸だと述べるのか？ メモ この章ではがツライ理由について述べる。 大学時代のアルバイト経験で、仕事を効率的に終わらせすぎて、時間が余ってしまった経験を述べる。 仕事が終わったため休んでいたら、雇用主に見つかってひどく怒られたと述べる。...

はじめに 藤原 博文 「Cプログラミング診断室」を読んだ。 最近 C コンパイラを自作していて、ソフトウェア開発の歴史に興味が湧いている。 その中で昔のソフトウェア開発の現場を少しでも感じたくてこの本を読んだ。 この本は 1991 年から 1993 年にかけてソフトウェアデザインに掲載された記事をまとめたものである。 1989 年に C 言語の最初の標準化（ANSI 標準）が行われたので、それから 2~4 年経った時期に書かれた文章である。 1980 年代は BASIC が主流で、1990 年代になって UNIX の発展に伴って C 言語が流行り始めた理解している。 そのため 1990 年代前半は BASIC 時代の GOTO 文を多用してグローバル変数に状態を撒き散らすおじさんが、 C 言語を書き始めたという時期なのかなと思っている。 そういう時代背景から、こういった企画が立ち上がったのだろう。（ほとんど想像です。） 内容全体はこちらから無料で読むことができる。私は図書館で借りて読んだ。 メモ この本の面白さは、ソフトウェア開発において気をつけるべきことが書いてあることではなく著者の愚痴が書いてあることにあるが、それはさておき、この本を読んで今後意識したいことを忘れないように纏めておく。 変数名は省略しない 変数名を一文字にしない。 英語でもローマ字でもかまわないから、フルスペルに近いものにする。 関数は短く 関数は 60 行以内に。100 行を超えたら必ず分割。 理由は長い関数はパソコンの画面に収まらないから。 設計とは この本は徹底的にフローチャートによる設計を批判している。 goto 文と同様に諸悪の根源とされているフローチャートを業務に使っている職場 が存在していたとは恐ろしいことです。 フローチャートは、「ソフトウェア考古学」の対象であり、情報処理技術者 試験の中にだけ今だに残っているものです。 私の感覚ではフローチャートって実質的 GOTO 文だし、現代の安全なプログラミング言語とは全く合わないと思う。 設計技法、開発技法の本はいっぱい出版されています。フローチャート以外の方法について、概略で十分ですから、何か適当な本を読んでおくことは重要です。 設計とは、目的の処理をどうやって実現するか、どう関数に分解するかなどの「意図」や「全体 の流れ」を書きあげるものです。 設計の表現方法は複数ある。設計は所詮人間同士のコミュニケーション手段なのだから、伝わらない設計を作るより伝わる設計を作るべきだと思う。 データ構造を書く データ構造はしっかり書くべきだと言っている。 プログラムは、データを処理するためにあり、データの違いによって制御の流れ が変更されます。あくまでも、データが主体です。変数、引数などのデータをどう定義するかで、 プログラムの組易さは大幅に改良されます。データ構造がどうなっているかの図の方が、フローチャー トよりはるかに役立ちます。データの意味だけはしっかり書きましょう。...

はじめに デヴィッド・グレーバー「僚制のユートピア　テクノロジー、構造的愚かさ、リベラリズムの鉄則」を読んだ。 これまでこのブログでは IT 技術関連の記事を書いてきたが、最近はZennで書くようになったので、これからはZennに書くのには適さない記事を書いていこうと思う。 はじめにこの本を読むに至った経緯から説明する。私は数学とか物理とかプログラムが好きな人間で、理路整然と並んだ定理や原理を大切にし、プログラムで自動化された仕組みを作るのが好きな人間である。（もちろん申請書類を書くのは大嫌いだが。。。） 最近は、ChatGPT をはじめとする生成系 AI を試していて、この技術がどういった方向に向かっていくのか気にしている。 生成系 AI が社会どのように変えていくのか、ヒントが得られる気がしてこの本を手に取った。 各章を読んでメモと感想を書いて、最後に全体の感想を書く。 序　リベラリズムの鉄則 メモ アメリカの政治の歴史とアメリカの政府と金融と企業が一体となっている。 そもそも金融とは国が戦争のために作ったもので、金融そのものが規制の塊みたいなものなのだから、市場の自由な競争に任せれば規制が全てなくなるというのは幻想で、市場とはそもそも官僚的なシステムそのものである。 そのため、そもそも市場に任せれば効率化されるのではなく、逆に規制が増えて規制が正しく働いているか監視するための役所の仕事と人が増えて全体として非効率になる。 この構造は社会のありとあらゆる場所で観測できるので、それをリベラリズムの鉄則と呼んでいる。 リベラルな人が規制緩和を掲げて選挙に出るが、それはその人が得する形に規制を変更するだけで、それによって手続きが減ることはなく、逆に手続きが増える結果になっている。 例えば大学の研究においては、競争的資金獲得のために研究者は大量の書類を書かなければならなくなった。 官僚制は政府と金融だけでなく、企業や教育や医療などが一体となって、一つの大きな官僚システムを構築している。 例えば、アメリカは仕組みとして大卒でないと企業に入れなくなったので、学生は大学を卒業するために金融機関から多額のお金を借りて借金をするような仕組みになっている。 なので学生は借金のために大量に書類を書くというお役所仕事に邁進する羽目になっている。 また、それでお金を借りたら企業に入って収入を監視されながら働き、その収入の一部を銀行に納め続けるシステムが出来上がっている。 これは社会全体として官僚システムを構築したことの一つの例である。 金融市場が発展するにつれて、市内には銀行の支店が増え続けた。 銀行の支店には銃を持った警備員とパソコンがある。 これは暴力と規則が一つになっており、官僚制の象徴そのものである。 感想 日本の右翼と左翼は逆転してる？からか混乱して、アメリカの政治の部分はよくわからなかった。 リベラルな人たちが規制緩和を掲げるが、結果として規制が増えて書類が増えるというのは日本でも同じだなぁと思った。 制度の変更って制度を作る人が得する形で変更するから、そうなると弱い立場の人が報告書類を大量に作らなきゃならなくなるのは当然な気がする。 研究とかね。 自由な市場競争の合理性は幻想であるというのは、新たな気づきだった。 農業のような儲からない仕事は価値がないから先進国で高度な教育を受けた人がやるのは勿体無いよね。 だから貿易を自由化して輸入しましょう。 って例だけを聞いて市場経済の合理性について納得してたが、そもそも貿易するには大量の制度と警察と役所の仕事が必要なので、それをゼロとして見積もって市場の自由は全体として効率的を論じるのは間違ってる気がした。 実際、グローバル化とともに書類が増えてるわけだし。 1 想像力の死角 メモ 母親が病気になった際に後見人と銀行をたらい回しになった。 官僚制における書類作成は複雑すぎてもう誰の手にも追えない状況になっている。 現代のペーパーワークはつまらないものとして規定されている。 現代の出生届は非常に無機質なものだが、昔の出生届は豪華な装飾がおこなわれていた。 もっとも自由と言われている大学人も現在では官僚である。 大学人も休憩室で会話する際には自信の研究について語るのではなく、自分が普段やっているペーパーワークについて語る。 あらゆる官僚的手続きは全て構造的暴力に基礎付けられている。 一つ例を挙げると、アフリカのアパルトヘイトはでは、労働者に様々な個人情報が記載された単一の ID カードを配布していた。そのカードは「ばかパス」と呼ばれていた。 これはそもそも構造的暴力が官僚的手続きを作った愚かな例である。 構造的暴力は解釈労働をうむ。 解釈労働とは相手の考えに思いを巡らせることである。 フェミニズムを例にすると、男性が女性の考えに思いを巡らせる時間は、女性が男性の考えに思いを巡らせる時間よりも圧倒的に短い。 それは、女性は男性による構造的暴力の被害者であるから、女性は男性の考えを理解するために解釈労働を行うのである。 構造的暴力の加害者側は、自身の立ち位置が崩れるのを嫌う。 警察官を例にすると、警察官は普段はペーパーワークをしているが、免許証持ってない人が運転してて逃げた場合とか、逮捕しようとしてるのに抵抗する人に対して暴力的になる。 それは官僚システムの中で自分の役割が危うくなるから。 感想 官僚制の中では誰しもが構造的暴力の加害者になってしまうことがある。 そうなると自分はあまり意識していない人（構造的暴力の被害者）に良く観察されることになる。 私はこの記事を思い出した。 携帯電話のアプリ開発を軍隊に例えて面白くした記事だが、非常によく書けていると思う。 確かに、この記事の人物たちも官僚的なやり方でアプリの開発をしているし、その上で自身は構造的の被害者なので加害者側をよく観察している。 高度に官僚化された組織において上司というのは構造的暴力の加害者になりやすいので、部下に対して解釈労働を払う方が良いのかもね。...

はじめに 久々に Coq で遊びたくなったので、M1 Mac にインストールしてみた。 最近の Coq は VSCode で書くのが主流？らしいが、今回は Emacs + Proof-General で環境構築を行う。 環境構築の方法 基本的にbrewやmelpaなどの package 管理システムになるべく依存した形で環境構築を行う。 はじめに、Coqのインストール(–build-from-source をつけないとcoqtop実行時にエラーが出た。) brew install coq --build-from-source GUI 版 Emacs のインストール brew install emacs --cask Emacs の設定 次は Emacs の設定を行う。 Emacs の設定ファイルは~/.emacs.d/init.elに記載する。 まずはmelpa(Emacs のプラグインのパッケージマネージャー)のセットアップを行う。 ~/.emacs.d/init.elに以下を記載し、 (require 'package) (let* ((no-ssl (and (memq system-type '(windows-nt ms-dos)) (not (gnutls-available-p)))) (proto (if no-ssl "http" "https"))) (add-to-list 'package-archives (cons "melpa" (concat proto "://melpa.org/packages/")) t)) (package-initialize) emacs を起動して...

はじめに Linux カーネルを書き換えて TCP の再送時間のパレート最適性を裏切る方法はこの記事で実験を行った。 ただ私のような Mac ユーザーは Linux をサーバー用途でしか使わないため、カーネルを書き換えたところでそこまで得できない。 やはりこれを使うにはクライアント端末で Kernel を書き換える方が楽しい。 私が普段使ってるクライアント端末で Kernel を書き換えられそうなもの、そう Android である。 この記事では自分の持ってるスマホに、私が書き換えた kernel をインストールして実験してみる。 （この記事はただの検証記事であり TCP のプロトコルを裏切ることを推奨するものではありません。私も書き換えたカーネルを普段使いしているわけではありません。） Android をソースからビルドする方法 この記事では PixelExperience という Android の Custom firmware のビルド方法を紹介する。 ビルドに用いたマシンは、OS: Ubuntu 22.04 LTS, メモリ: 16GB (+ Swap 32GB)である。 以下の内容は、この記事を参考にした。 fastboot や adb や git や python をインストールする。 sudo apt install android-sdk git python-is-python3 android をビルドするための依存関係全部インストールするスクリプト実行する。 git clone https://github.com/akhilnarang/scripts cd scripts ./setup/android_build_env.sh ビルド用のディレクトリを作る。 mkdir -p ~/android/pe git の設定を作る。（すでにやってたら必要なし）...

はじめに 私はブラウザ上で動く簡単なアプリを作る際にelmを用いることが多い。 elmはブラウザの状態とユーザーの入力を言語の機能とそのアーキテクチャで簡単に管理できるため、簡単なアプリであればほとんど迷うことがなく作りたいものが作れる点で気にいっている。 ただ最近では、elmの便利な状態管理の手法は JS のフレームワークにも導入され、React のコンポーネントを用いた UI 開発や JS のその他の資源と組み合わせることで効率的にフロントエンドを開発することが主流になってきている。 このような流れのためか、ここ数年はelmを用いた開発を行う人が極端に少なくなってきていると感じている。 ただフロントエンドの専門家ではない私からすると、フレームワークの選定に迷う必要がない点や、tsにするかjsにするか迷わなくて良い点や、Haskellライクな言語の楽さとelm-formatの利便性などの観点から考えると、簡単な Web アプリであれば依然としてelmを用いて開発を行うことは悪くない選択肢だと思っている。 この記事ではelmとBootstrapやelmとTailwind CSSを組み合わせたサンプルアプリの構築方法を解説する。 環境構築(Bootstrap 編) プロジェクトを作成 $ mkdir elm-bootstrap-sampleapp $ cd elm-bootstrap-sampleapp $ npm init -y bootstrap をインストール（参考） $ npm i --save-dev parcel $ npm i --save-dev bootstrap @popperjs/core elm をインストールして環境を構築 $ npm i --save-dev elm @parcel/transformer-elm $ npx elm init 必要なファイルを作成 $ touch src/index.html src/index.js src/index.scss src/Main.elm src/index.htmlを書く。 <!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1....

はじめに インターネットには多数のデバイスが存在しており、その多数のデバイスが通信し合うために通信プロトコルが定義されている。 様々な通信プロトコルを勉強していくと、ネットワーク内の通信が正常に行えるためにはそのネットワークの参加者全員が通信プロトコルを守っていることが必要になることに気がつく。 たとえば、TCP の通信が失敗したときの再送の間隔について説明する。 今回はわかりやすく普通のサーバー・クライアントモデルの Web サービスを考え、サーバー対してクライアントから大量のアクセスが集まりそのリソースが枯渇した状況を考える。 サーバーはリソースの枯渇により全てのクライアントと TCP のコネクションを張れないことから、一部クライアントからのアクセスを拒否する。 拒否されたクライアントは再度サーバーに対してアクセスしようと試みる。 これをアクセス出来るまでクライアントは繰り返すわけだが、その間隔は実は一定ではない。 最初は 1 秒程度で素早く再送するが、サーバーが何度もアクセスを拒否すると、クライアントの方で自動で再送の間隔を指数関数的に伸ばしてアクセスするようになっている。 このような仕様になってる理由は、全員が間隔を開けずに即座に繰り返し通信を試みた場合はサーバーのリソースは一生枯渇したままで回復しない可能性があるためである。 一方でクライアント側で指数関数的に間隔を伸ばしていくと、サーバーがアクセスを拒否し続ければいつかはリソースが回復し少しクライアントの通信を捌けるようになる。 そのため、TCP ではアクセスに失敗したときクライアント側で再送する間隔を指数関数的に引き伸ばしていくというプロトコルになっているのである。 ここで注目したいのが、TCP の再送間隔の調整はクライアントで行われるという点である。 再送の間隔を極端に短くして再度送信するようなデバイスを作ったとしたら、そのデバイスはネットワークの中で唯一得することが出来るのである。 囚人のジレンマの言葉で言えば、現在のネットワークは全員が黙秘しているパレート最適な状態であるから、自分だけ自白することで自分だけの利得を最大化出来るのである。 (世界中の数百億台というディバイスでパレート最適な状態を保っているというのは考え深いものがある。) このようなインターネットのプロトコルのパレート最適性を裏切る方法は TCP の再送時間以外にも探せばいくつもあるだろう。 この記事では TCP の再送間隔について Linux カーネルを弄って実験をする。 実験条件 OS: Ubuntu 22.04.1 LTS Linux kernel version: 5.15.73 Server と Client の IP アドレスは Server: 192.168.0.10 Client: 192.168.0.20 とする。 TCP がアクセスを再試行する回数は/etc/sysctl.conf内に、 net.ipv4.tcp_syn_retries = 5 を書くことで調整が可能である。（この場合は 5 回リトライする） つぎに、TCP の再送時間の計測方法を説明する。 まず Server で 23 番の TCP ポートを塞ぐ。 クライアント側で Server に telnet でアクセスを行う。...

Basic 認証や Digest 認証をゼロから実装する機会があったのでその仕組をメモしておく。 本記事の node はすべて v18 である。 Basic 認証と Digest 認証 Basic 認証 はじめに Basic 認証の仕組みにを解説する。 Basic 認証においてクライアントが初めて http リクエストを送ったときは、Status Code が401 Unauthorizedでヘッダーに www-authenticate: Basic realm="secure" が付与されたレスポンスがサーバーから帰ってくる。 ちなみに realm は認証領域を表す。 クライアントがユーザーとパスワードを user:pass のように入力したときは Authorization: Basic dXNlcjpwYXNz を付与してレスポンスを返す仕組みになっている。 このような動作は Basic 認証を用いたサイトに Chrome で接続し、デベロッパーツールで通信を監視することで確かめることが出来る。 次に、dXNlcjpwYXNzの計算方法について確認しておく。 結論から言うとdXNlcjpwYXNzはuser:passを base64 でエンコードしたものである。 Bash では $ echo -n "user:pass" | base64 dXNlcjpwYXNz JavaScript では > btoa("user:pass") 'dXNlcjpwYXNz' のように計算出来る。 ただ、Base64 はハッシュ関数でもなんでもなくて文字列を単純な方法で変換しているだけなので、簡単に戻すことが出来る。 Bash では ❯ echo -n "dXNlcjpwYXNz" | base64 -d user:pass JavaScript では...