Goはnet.Conn Readの裏側がepoll使っててスケジューラが状態管理してるのでそのままGoのAPIでsocketの読み書きしてもだめで生のsyscall.Readを使う必要があるとか、CGO側のpthreadからGo側の関数を呼び出した時にランタイムがGo用のStackのアロケーションとかを行うとか、謎の学びが多かった
23.01.2026 11:08
👍 0
🔁 0
💬 0
📌 0
Goはnet.Conn Readの裏側がepoll使っててスケジューラが状態管理してるのでそのままGoのAPIでsocketの読み書きしてもだめで生のsyscall.Readを使う必要があるとか、CGO側のpthreadからGo側の関数を呼び出した時にランタイムがGo用のStackのアロケーションとかを行うとか、謎の学びが多かった
TCPサーバーの歴史的なアーキテクチャの変遷を実際のGoで書いてみてまとめたやつです
GoでCGO使って無理やりpthread立てたりepollしたり無茶をやってたのしかった乁( ̇ω ̇ 乁)
[yuroyoro/studying_tcp_server_architecture_in_go](github.com/yuroyoro/stu...)
そうさ、100%重機
RabbitMQ、まれによくこわれる
にゃーん
あと、あるLLMの出力を別なLLMに渡す際にはセマンティクスが表現に内包されるプログラムミング言語の方が機械語よりよほどコンテキストを維持しやすいと思う。
機械語になったらそのプログラムが何をやっているのかLLMが解析するのが非常に困難だと思うので
「LLMの出力を信頼する」のと「その出力をいざとなったら検証・再現できるようにする」のは両立できるので、ヒューマンリーダブルな中間出力はやっぱり大事だと思うんよ
自分も昔に冗談で「LLMが機械語吐けばええやん😇」って言ったことあったけど、本気でそういう主張をする人が出てくるとは予想してなかったな……
コンパイラはデバッグのためにアセンブリを吐いたり各フェーズをトレースしたりという機能が揃っており再現可能だけど、LLMはブラックボックスすぎて追跡性とか再現性とかがまるっとすっ飛ばされてるので、人間が検証可能なプログラミング言語を出力するのが丸いと思うんだけどなー
にゃーん
逆に仕様が明確な処理や自明な実装とかリファクタリングについてはAIに書いてもらうのが楽なので住み分けしていけ〜〜
少なくともGoやTypeScriptなど自分ができる言語に関しては、まだまだ余裕でClaudeCodeやCodexより良いコードが書ける自信があります
少なくとも全体を見据えた統一感とか冗長性の排除、要件を見据えた拡張性という点については、コンテキストが限られる現状の生成AIがそのコードベースを熟知している人間に勝るものを出せていないという所感ある
サミットファンだからな！！
Go言語の特徴を聞いて「誰が書いても同じようなコードになる」と答える人には、「本当にそう思ってますか?」と言いながらdatabase/sqlあたりのソースコードを見せるようにしています
cs.opensource.google/go/go/+/refs...
CI/CDの整理とか、開発環境整備とか規約策定とか「対エンジニア向け」のタスクは取り組みやすく効果測定もしやすいけど、「対ユーザー向け」の方がより価値が高いと考えています
採用面談で経歴を聞く際に、「対エンジニア向け」の成果ばかり主張される方に対しては、「ユーザー向け」の成果を聞き出すように心がけています
AIが書いたコードを修正したあとはgit show --patchでpatchファイルを作っておいてそいつを次のコンテキストに入れておくようにしてます。だってコミット見ろっていってもcopilot agentがちゃんと読んでくれないんで
AIをつよく使うためには人間がつよくなるしかねえんすよ
AIはエンジニアの能力を加算ではなく乗算でレバレッジかけてくやつやから、元が0やったら………ｱｱｱｱｯﾔﾒﾛｰｰｰｯｯ
vibeコーディングで作って運用して成長していった事例早くでないかなー。成長する前に消滅する可能性も高そうだけど
AIコーディング、やっぱりまるっと全部vibesアゲ〜〜みたいな使い方は性にあわないなー。
使い捨てのツールとかはvibes〜でいんだけど、実運用するやつをvibeコーディングで作って出す気にはまだなれないっす
AIが出してきたコードで気に入らないところはガッツリ書き直すし、逆に考慮してないところを言語化・コード化してくれるところはありがたい
ペアプロの相手としては非常に優秀だと思う。
やあ （´・ω・｀)
ようこそ、米国(バージニア北部)へ。
このIAM Roleはサービスだから、まずAssume Roleして落ち着いて欲しい。
うん、「また」なんだ。済まない。
仏の顔もって言うしね、謝って許してもらおうとも思っていない。
でも、この何も無いRegionを見たとき、君は、きっと言葉では言い表せない「ときめき」みたいなものを感じてくれたと思う。
殺伐とした世の中で、そういう気持ちを忘れないで欲しい
そう思って、デフォルトをこのRegionにしたんだ。
じゃあ、リクエストを聞こうか。
429 Too Many Request ってRFCあったんだな
datatracker.ietf.org/doc/html/rfc...
ECSコンテナの中でstrace叩きたいんですけどー
昨日のapne1-az4障害の影響かは不明だけど、おそらくawslogs のdriverが止まったことでecs taskからの標準出力の書き込みが(バッファが埋まってPIPE_BUFになり)ブロックして、アプリケーションが刺さって応答しなくなっていた
標準出力への書き込みがブロックした場合でアプリケーション側でできることってなんかある……?
もうお手上げだと思うんだけど……
AIがソフトウェア開発のエコシステムに組み込まれていくと、もう新しいプログラミング言語が生まれることはほぼ無さそうと思ってしまいます。
少なくともビッグテックがAI開発のエコシステムとセットで提供しないと、新規の言語は見向きもされなくなりそう
(奥が深い=複雑な仕様、ドキュメントをよく読み込まないと理解できない挙動、アンドキュメンテッドなワークアラウンドなどを多く含む)
RDS の Database Insight使ってみたけど、分析はまぁ、メトリクス見ればわかるよね…みたいな内容でもうちょっと頑張ってほしかった。AASとクエリとシステムメトリクスを俯瞰しながら解析するようなの期待してたんだけど。
「lwlock, io, cpuが負荷の44%を締めています。」みたいなやつ、見ればわかるんで……。
まあPerformance Insightと拡張モニタリングのプロセスリストとか統合されたりログを見れたりと一つの画面に統合したところはいいんだけど、それはPerformance Insightでもできるようにしてよ……。
AWSの人たち、あのCloudWatch LogsのUI使ってるんでしょうか? ドッグフーディングしてるの…？
CloudWatch Logsつれえなあ……！！
つれえよ……！
このUIよぉ……！！
Amazon MQ RabbitMQクラスタの3nodeのうちの1nodeが死んだのでサポート問い合わせしてる。マネージドサービスがんばって……
