つだ

ひよっこ組み込みハードエンジニア。ひとりで色々つくってます。

[つだ @2dice_K]

最近作った物をmin.tにまとめました。
■mcNARUTOmode
https://t.co/N3KBIf0xeL
■セラコン琴
https://t.co/J2aO35zLM9
■kig-mo
https://t.co/IjYx3Wv6rh
■進撃のぼて〇ん
https://t.co/9TF2cMBwwJ
■人造コックリさん
https://t.co/HkhmFhJ12w

[ファミネコ@大型AC筐体ドクター @fcneet]

以前TLで見た半ピッチず��しのスルーホール、考えた人は天才やった。ピンヘッダが程よく固定されていい感じ。これでいちいちサービス用のピンソケットを実装しなくてよくなった。

[つだ @2dice_K]

@chiba_yt834 大きな声では言えませんが、それを狙って作ったものの、どの板でも音量が変わりませんでした。
｢見た目がそれっぽくなる」という重要な役目を果たしています。

[つだ @2dice_K]

スマホの充電を夜→朝までやるのに、バッテリーの劣化を最小限できないか試してみてる。
設定で充電80%リミットをかけて、USBケーブル加工して5V/500mAでゆっくり充電するよう��してみた。
USB-Aの中継ケーブル切って5V/GNDだけ接続(通信カット)で500mAに固定、低速充電に。

[やえ @nihon_niosumai]

このコラムのインピーダンス特性もNanoVNA-F v2で測定した。ただ、10k～0.5GHzまで一気に走査するとキャリブレーションがまともに働かなかったので各decade毎にキャリブレーションデータを分けて適用→測定→次のdecadeに自動で分割測定するスクリプトを作成した。

[つだ @2dice_K]

楽しみ

生成AIでハードウエア開発、「30日から1日程度」へ。中国・指数科技、回路図もコードも低コストで(36Kr Japan)
#Yahooニュース
https://t.co/viESF0SKMa

[つだ @2dice_K]

子供に話しかけたら、ちょうど音声入力で検索しようとしていたらしく、今話しかけないでと怒られた。
これあれだ、カセットの録音で親の声が入る現象の令和版だ。

[つだ @2dice_K]

デジタルタトゥーだ・・・
#WBS

[つだ @2dice_K]

なんかjulesいつの間にかネットワークアクセスもnpmコマンド実行もできるようになってる？

[Mustafa @oprydai]

the capacitor is doing the job outside his job description

[iwashi / Yoshimasa Iwase @iwashi86]

先ほどの方の記事で、こちらも良かった。共感する。

以下は、本文と順番違うがメモ：

・最高のエンジニアとは、バグを修正する人ではなく、誤解がバグになる前にそれを解消する人
・経験を積むと、あらゆる議論に勝とうとすることをやめ、本当に重要なこと以外は受け流せるようになる
・成熟とは、完璧さを追求するのをやめ、物事が摩擦なく流れる状態（フロー）を重視することである
・最終的には、流行の技術より、自分が寝ている間も静かに動き続ける退屈で安定した技術（PostgreSQLなど）を信頼するようになる

・抽象化レイヤーを増やすことは、一���、（技術的な）進歩に見えるが、実際には摩擦を増やすことが多い
・経験とは、技術スタックが変わることではなく、何が重要かという「視点」が変わること

・キャリア初期は、巧妙で難解なコードこそがスキルの証明だと考えがちかもしれない
・巧妙なコードは、書いた瞬間は満足感があっても、後でメンテナンスする人を苦しめる
・真の熟達とは、複雑さを管��し、シンプルで明確なコードを書けることである

・アジャイルやTDDのような良いアイデアも、厳格な「プロセス」になると形骸化し、腐る
・プロセスの儀式を守ることと、チームが成果を出すことはイコールではない
・プロセスはコミュニケーションを助けるためのものであり、思考を停止させるためのものではない
・目的より手段（フレームワークなど）を擁護し始めたら、本質を見失っている証拠

・エンジニアは、まだ来ない「将来のスケール」を想像し、過剰なシステムを設計しがち
・過剰設計は、技術力を証明したい野心や、準備不足に見られたくない恐れから生まれる
・業界は、物事を小さく保つことより、複雑なシステムを作ったことを評価しがち

・キャリア初期に嫌っていた型チェックや規約は、実はカオスを防ぐ「集団的防��メカニズム」である
・これら「退屈なもの」が���定を生み出し、その安定こそが、本当に重要な場所でリスクを取る自由をもたらす
・命名規則や標準は、チームの「集合的記憶」として機能し、一貫性を保つ

・ソフトウェア開発は技術的な作業に見えるが、その本質は「人間関係」と「調整」である
・たとえば、システム障害の根本原因は、技術的欠陥よりも「誰かが誰かと話さなかった」というコミュニケーション不全にある（ことが多い）
・ドキュメントやミーティングは、単なる儀式ではなく、相互理解を支える「社会的な足場」作りである

Most of What We Call Progress という記事から。

[つだ @2dice_K]

@seevua 食べこぼしが多くて恥ずかしいので、こぼした瞬間に消し飛ばして気づかれないようにしたいです。

[つだ @2dice_K]

.@SteveKasuya2 さんのラピュタ石、息子が置いてあるメモ書き見ながら必死で文字探し始めて、実際に探す人は初めてと言われた
彼はラピュタ王なのかもしれない
#NT東京

[つだ @2dice_K]

.@takashikaburagi さんのサービス精神が凄すぎて息子が無限にご本人をオモチャにしてしまった
申し訳ねぇ
あと腹筋ズゴイ
#NT東京

[つだ @2dice_K]

食堂で @necobut さんを目撃した息子が「さっき展示にいた黄色い人だ」と言っていてやっぱインパクトすごい
#NT東京

[つだ @2dice_K]

claude codeの待ち時間用にミニゲーム作った
https://t.co/9JUgBsZKyI

[つだ @2dice_K]

あとActionsで任意のブランチからgithub pagesにマニュアルでデプロイできるようにしておくとマージ前に本番環境でテスト確認できてよさげ。仕事じゃできないだろうけど。

[つだ @2dice_K]

ちょっと前からclaude proプランに課金してclaude codeに乗り換えたけど、webチャットのopus4にペアプランニング/ペアレビューイングしてもらう形に落ち着いている。
要件定義からタスク分解→1タスクの実装方法を相談しながらプランニング→CCのsonnet4に投げてPR→opus4に渡してレビュー。

[つだ @2dice_K]

プランニングで自分が作りたい物/使う部品の理解が深まるし、レビューでプログラムのアンチパターンが見られるので学習用途でも良さそう。
個別要素の��身を忘れても実際に動くサンプルが自分のリポジトリにあるのは便利。

[outside five sigma @jwt0625]

ok it actually works, uggghhh