AliExpressのawg28が使いやすそうなので買ってみた。外形は1.1mmくらいあるのでawg28だけど太め。今見たらお値段上がっていたが、買った時は680円だった(10m巻きx6色)。
普段使っていたのは、秋月のイラックスで、こちらだと外形は0.8mmくらいなので結構違う。お値段は1m x 10色で350円。
お値段が5倍くらい違う(しかもAliExpressは送料無料だった)ので、特に太さにこだわりが無い箇所ではAliExpressのを使おうかな。これ、特定の色だけ使い切った時に色別に補充できるのかなと思ったのだけど、一応バラのものもあるようだ。ただし割高なので、補充はオヤイデのETFEのawg28あたりが良さそう。
2025/4月時点で価格は169円で送料無料。届くのに1か月くらいかかるのが難点か。
家のCDは全部flacに吸い出してあって、それをラズパイでmpcを使って聴いている(ncmpcというコマンドラインで使えるプレイヤーがある)。ただ、ラズパイ用DACの出力がLine outしかなくてヘッドホン出力がないので、このアンプを入れてみた。こういう安いアンプは昔は、ホワイトノイズとかハムがすごくて、まぁそれでも「この価格じゃ仕方ないよね」って納得してそのまま我慢して使うなり、自分で回路を改良したりしてだましだまし使ったものだけど、全く問題無かった。というかホワイトノイズ無さすぎて無音時に何も聞こえないから壊れているのかと思うほど。
届くのに時間がかかるので、もしかしたら電源からのスイッチングノイズがあるかもと思って、コモンモードチョークを買っておいたのだけど全く不要だった。今のD級アンプって、インダクタすらないのね。どうやらスピーカをローパスフィルタ替わりにするらしい。すごい時代になったものだ。
ただ、何かInputのシルク印刷がおかしくて"B"というのがあるけど、これは"R"の間違いだろう(だから安いのだろうか)。
今まで、Amazonで買ったこれを使っていたのだけど、2回路では足りなくなったのと、入力別に音量調整したくなったので自作してみた。
オーディオスプリッタを作成
Weytoll 150W 電子負荷テスター 1.77 TFT カラー 4線式デジタル 高精度抵抗電圧電流計 調整可能な 定電流 電子負荷 (10A)
日本語だと「電子負荷」という謎用語なのだけど、要は定電流負荷。電池の寿命を見るのにテスタで電圧を測ってもインピーダンスが高いので分からないので、一定の負荷をかける必要がある。電子負荷を使うと消費電流を指定できて、その電流負荷でどのくらいの時間もったのかが分かる
Andonstar AD407 3D HDMI はんだ付けデジタル顕微鏡 プロメタルスタンド付き 4MP UHD 7インチ調整可能LCDスクリーン USBビデオ顕微鏡 電話修理SMT SMD DIY用
最近、老眼が進んできた上に表面実装の半田付けが増えてきたので購入してみた。昔この手のUSB顕微鏡を試しに買ったことがあるのだが、レンズの精度が悪いわノイズは多いわで散々だったので避けていた。最近この商品の紹介がYouTubeにあって良さそうだったので購入。SSOP(ピン間0.65mm)くらいでも余裕で良く見える。
MXBatt USB充電式 9V充電池 006P型 9V形 リチウムイオン 650mAh USB-Cケーブルス付き1.5H急速充電電池 800回充電可能 充電器不要 1本
この手の006P充電可能電池は、内部で昇圧しているので自己放電やノイズが問題になることが多いのだが、この電池は評判が良いので買ってみた。テスタで使ってみているが特に問題無いようだ。
KAIWEETS 検電器 12-1000V AC / 70-1000V AC感度調節 検電ドライバー ペン型 LED懐中電灯付き パーセント表示 通電チェッカー 非接触電圧検出
漏電を診断する機器。昔は検電ドライバというものがあって、中にネオン管と高抵抗が入っていて、人体を通して電流が流れてネオン管が光るというなんとも野蛮な仕組みだったが、今はこんな便利なものがあるのだ。先端はプラスチックになっていて絶縁されていて安心感がある。
SWIFT 双眼実体顕微鏡 立体顕微鏡 LED光源付 金属製 両眼ヘッド、広視野接眼レンズ10X付き、総合倍率：20倍、40倍、研究用、実験用、高倍率実体顕微鏡 PSE認証済 S304-LED
USB顕微鏡は良く見えるのだが、単眼なので距離感が掴めない。このためこれで半田付けはかなり難しい。そんなわけで実体顕微鏡を購入。これだと距離感が良く分かる。USB顕微鏡の方は半田付け結果の確認などに活用。
【Amazonデバイス】Ring Battery Doorbell Plus (リング ドアベルプラス バッテリーモデル) | 上下左右150°のワイドなカメラ視野角、1536p HD+ビデオ、電源工事不要なスマホ対応ドアホン・インターホン
家のドアホンが故障。子機がたまに鳴らなくなってしまった。だいたいこの手のデバイスはバッテリがダメになるのでバッテリ交換で直ることが多いのだが、どうもそういう感じではない。子機だけ買おうとしたら4万越えになっててあきらめ。今回はAmazonのRingにしてみた。屋外カメラにGoogle Nest Camを使っているので、Googleで揃えた方が良いかもとも思ったけど、色々試す方が良いかなと。録画機能を使うには月額費用が必要で、その点ではGoogle Nest Camは無料でも3時間は保持してくれるので優れているかもしれない。
Ring Chime Pro（リング チャイムプロ）
Ringの来客通知がスマホだけだと気付かないことがあるので追加。これはWifiの中継機能もあるのでその点も便利。家では3FにWifiのアクセスポイントがあり、1Fの玄関とはかなり離れているので、中継がないとかなりWifiの電波強度が低くなってしまう。
自分が見ているサーバで今朝、以下のようなエラーがdocker runで発生するようになった。環境はUbuntu 22.04
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create fa
iled: runc create failed: unable to start container process: error during container init: error setting cgroup config for
procHooks process: failed to call BPF_PROG_ATTACH (BPF_CGROUP_DEVICE, BPF_F_ALLOW_MULTI): attach program: invalid argument
1台はUbuntu 24.04にdo-release-upgradeしたら解決。
もう1台は、24.04でも解決できず。/etc/docker/daemon.jsonを作成して以下の内容にしたところ解決した。
{
"exec-opts": ["native.cgroupdriver=cgroupfs"]
}
テスタ棒で基板の上を調査している場合、テスタ棒を当てるのにかなり神経を使っている。なぜならICなどピッチが狭い時、一歩間違えれば隣のピンとショートしてしまうかもれないし、きっちり当てないと接触不良で正しい値が得られないからだ。しかしテスタ棒を当てた後、測定値を読み取るには、どうしても視線をテスタに向けなければならない、この時にツルっとテスタ棒の位置を狂わせてしまう事故が起きがちだ。
そこで測定値をPCで読み上げるようにしてみた。うちにあるのはだいぶ昔に買ったM-6000Mというテスターで、RS-232Cで測定値を読み取ることができる。そしてVOICEBOXという便利な読み上げソフトウェアがあるので、これらを組み合わせれば出来そう。このテスタを買った当時は、どうやらRubyでも同じようなアプリを作成していたようだ(もう12年も前なのか)。今回はRustでゼロから書き直した。RS-232Cからのデータのデコードはライブラリとして分離してある。
割と良いかも。詳細はこちら
もともとテプラは筐体自体にキーボードが付いていて、そこで打ち込んだものが印刷できるというものだった(今もそういう機種は併売されている)。PCと比べると画面が小さくてキーボードもお世辞にも打ちやすいとはいえず、また出力される文字もギザギザとしたものだった。そんな中、PCから接続できるテプラが登場。うちにあるテプラは、SR3700Pというやつで、今見ると発売は2008年だそうだ。
6mm幅のテープは部品を整理するのに丁度良く、便利に使っていたのだが、長いあいだ使ううちに色々と問題が出て来た。
プラスチックがベタベタに劣化してしまった。
この時代の製品は高級感を出すために、プラスチックにスエードのような感触を出す加工を良く使っていた。これは年月が経つとベタベタに劣化してしまう。機能的には問題無いものの使うたびに手がベトベトになるのはかなわない。Webで検索してみるとアルコールで拭けとか消しごむをかけろというのが見つかる。まずはアルコールで拭いてみたが全く拭きとれる感覚がない。消しごむというも効率が悪く範囲が広いと気が遠くなる。アルコールで拭いてみた感じだと、もっと脂溶性の物質のような感じなのでおそらく有機溶剤が良さそう。試しにCRC5-56を使ってみた。
これがとても具合が良く、みるみるきれいになった。ただCRC5-56は浸透性が高いのでプラスチックを逆に痛める可能性があるため、良く拭いた後にシリコンスプレーを使って磨いておいた。
1か月ほど経つが特に問題無いようだ。
Mac用のアプリが更新されなくってしまった。
古い製品なので仕方無いがmacOSの最新には対応してくれなくなってしまった。Windowsなら使えるので致命的ではないが、うちにあるWindowsは1万円で買った中古のRAM 4GB Windows Padなので今ひとつ使い勝手が悪い。そろそろ買いかえかもなと思って調べていたら今のテプラは色々と便利な機能があることが分かった。
1つはハーフカット。ラベルを作ったあと面倒なのがシールを台紙から剥がす作業でこれがなかなかうまくいかずにイライラする。今のテプラにはハーフカッタが付いた機種があり、これを使うと楽に剥がせるらしい。
もう1つはより幅の狭いテープのサポート。普段は6mmのテープで十分なのだが、たまに2行印刷したい、より狭い幅のテープがあったらなと感じる。今は4mmのテープがあることが分かった。また最新の機種は6mmのテープに2行の印字が可能なことが分かった。
価格.comで調べるとハーフカッタサポートのテプラはこのあたりのようだ。SR-R680 ならPCにも接続できるし、本体だけでも打ち込んで印字ができて便利そうだ。
興味あってカシオのネームランドも調べてみた。ハーフカッタ対応だと、こちらのリストのようだ。KL-TM7だと随分と安いようだ。PCには接続できないが、筐体にキーボードがあった方がサポート切れの心配をしなくて良いのが逆に利点かもしれない。
しかしまだテプラ用のテープが残っているので、やはり捨てるのは惜しい。なんとか今のテプラを活用できないか調べてみた。まずハーフカットだが、こんなのがあることが分かった。
試しに買ってみたが少々コツがいるものの、シール剥がしが楽になった。
残りは6mmテープへの2行印字だが、アプリの方を調べてみてもそういう機能は無さそうだった。プリンタの解像度的には十分可能そうなのだが。しかしSR3700Pには任意のビットマップ印字機能があるので、あらかじめビットマップで印字内容を残しておけば良さそうだ。
何か手軽な方法は無いかとClaude3さんに聞いてみたところ、ImageMagickを使えとのこと。
$ convert -pointsize 64 -interline-spacing -5 -font ~/.fonts/HackGen_NF_v2.9.0/HackGen35ConsoleNF-Bold.ttf label:"p日本語\npあいう" output.png
こんな感じで2行表示の文字列をフォント指定で描画した画像を生成できることが分かった。Mac版のアプリは少々出来が悪く、画像印字すると高さが減ってしまうのでWindows版の方が良さそうだ。
若干解像度が落ちるが、多分テプラのアプリの縮小のロジックのせいと思われる。テープ幅に合ったドット数のイメージを作ればもう少しきれいになりそう。
関数型でドメインモデリングというお話。
第2章「ドメインの理解」
実際のドメインの理解について実例を示しながら解説している。ドメインエキスパートへのインタビュー、こんなに何でも知っているお客様はいないっすよとは思いつつ、まぁそれを言い出すとキリが無いので仕方無い。そして、いきなりER作り出すなよと釘を刺す。これは、おじいちゃんへの良いアドバイス。そしてクラス図もダメだからなと釘を刺す。今時もクラス図って生きているの？じゃどうやって実装に落としていくのかというと、テキストベースのメモに留めておけと。そしてドメインの理解が完全になってから実装に進むのだ。ただこのテキストベースのメモに出てくる型の記述って結局は(Javaで言うならAbstcatr Classを排してInterfaceだけを使った)クラス図じゃないのかなぁ。
インタビューは更に進む。「数量は整数ですか浮動小数ですか？」に対しドメインエキスパートにプログラミングの専門用語使っちゃダメですよ。「数量は整数ですか小数ですか？」と聞きましょうと。それはそうなんだけど。分析系以外で浮動小数点数の利用は常識として無いだろうと思う。この手の書籍で気軽に浮動小数点数を持ち出す例を見かけるのだが、やめた方が良いと思う。そもそもこの著者って本当に実務でプログラミングしているの？という疑問が沸いてしまうので。
制約条件、ライフサイクル(状態マシーン)を書き上げる。まぁそうですよね。
完全に新規の場合は本書の通り「ドメインの理解」から始まるのだろうけど、そうでなければ通例は「システムの理解」的なものがあるのではないかな？特に外部システムとか。これはドメインエキスパートはあまり知らないので、お客さんのIT部門の人にも聞かないといけないし、ITの人も外部システムについては実は良く知らなかったりで大変なわけで、とはいえ「関数型」とは離れてしまうので省略されたのかもしれない。
第3章「関数型アーキテクチャ」
処理はイベントソーシングでキューイングする。このあたりはマイクロ・サービスのコレオグラフィと同じ考え方なのかな。
これまでのようなサービスレイヤ、ドメイン、永続化層みたいなのは良くないよね。なぜなら横につながっているのである機能の修正のために他の機能への影響が出やすいからと。機能ごとに分離しましょう。ただ、それだたレイヤーが増えすぎて良くないからオニオンアーキテクチャにしましょう。I/Oは副作用なのでドメインには置かずに外側に置きましょうと。う〜んそれはまぁ分からないでもないけどドメインロジックで、ビジネスルールなどのチェックが必要だとI/O必要ないのかなぁ。そういうのは先に取得しておいて渡せってことかな。でもそうするとビジネスルールが複雑な場合って、最終的には不要なものも含めて必要になりそうな可能性のあるもの全てを先に読んでおけってことになるのかな。
第1部はここまで。第2部は基本はF#の話。
静的型の活用。値型(単純型)。不変条件。このあたりは別に「関数型」でなくてもImmutable指向のOO設計でも共通の話題かな。
ワークフローはイベントをキューで流せと。Validationとかの粒度でイベントとして扱うとされているが、そんなレベルでやるの？ あとはフラグやめてステートマシンにしようね。このあたりは昔から変わらない。
第3部もF#というか関数型の基本の話で始まる。
エラー処理。F#ではResultを使う。まぁイベントをキューイングというアーキテクチャでは例外を使ってもご利益ないよね。そしてシリアライズの話。
12章で永続化。ここで3章で抱いた疑問への回答が示される。
まず、前の章の方ではかなり粒度の小さなレベルでイベントとキューイングで実装していくように読めたのだが(誤読か？)、実際はI/OがOKな層からドメインロジックを「呼び出し」て良く、ドメインロジック中で追加でデータが必要になったら一旦その旨を戻値でドメインロジックから返し、その戻値をもとにI/O層が追加でデータを取得してまたドメインロジックを呼ぶような造りで良いとのこと。まぁこれなら良くみる「サービスレイヤ」なのでそんなに異和感は無いよね。
本書での主張は自分は、要件定義ですぐにER図とかクラス図などの実装詳細を書こうとするな、ドメインロジックからはI/Oを無くせ。あたりが本質かなと感じた。具体的なアプリケーションを題材にしているので、アプリケーションを実装している人には示唆に富んでいると思う。
ただ盲従しない方が良いかなと。基本CRUDで画面を数100枚作るようなプロジェクトでこの手法はover killだと思うし、基幹業務で一旦作ったら5年、10年塩漬けというようなアプリケーションでもメリットを出しづらいだろう。
なら一日に何度もデプロイするような戦略アプリケーションならどうか？ 少なくとも3-5年前の自分ならこういう設計(ドメインロジックからはI/Oを排する)に諸手を上げるかもしれない。ただし、これはトレードオフで、やはりドメインロジックからI/Oを排するために複雑になることは受容しなければならない。こういうのは一旦流行しても5年くらいするとPlain Oldなんとかみたいな揺り戻しが起きて「単にサービスレイヤで永続化層とやりとりするだけの単純なコードの方が実装ははるかに楽だよね？」みたいになりそうな予感もする。
最近はRustでWebアプリケーションを実装してるが、結局永続化に関する部分はsqlxやSeaORMのようなライブラリで吸収できてしまうし、複雑なバリデーションはBuilderに入力をつっこんでbuild()メソッドで検証みたいな素朴な作りで十分で、あまり大層な仕組みの必要性を感じない。フレームワークもテスト支援機能が手厚く、DBありでも無理なくテストできる。もちろんその分、I/Oが入るとテストが遅くなるとか、単体テストはテストごとにPostgresのDB名にUUID入れたものを新規生成してぶつからないようにするなどの工夫が必要などデメリットもある。その分、ドメインからDB切り離して得意になっていたら、SQLがバグっていて痛い目にあったなんてことが起きないというメリットもある。結局はトレードオフなのだ。自分のようにDB苦手な人間はDBも巻き込んだテストを地道に回す方が安心できる。
Bobおじさんによる関数型プログラミング言語の使い方の解説。「使い方」なので理論的な話は割愛とのこと。
関数型については、ひところのブームが去って落ち着いた感がある。別にこれまでのOOなどのパラダイムを置き換えるようなものではないし、あくまでケースバイケースで採用すれば良い、人のコードを読む時に前提として知っておいた方が良いプログラミングの1技法くらいの位置付けだろう。そういう意味ではデザインパターンの1つくらいに考えた方が良さそうだ。
正直対象読者をどう想定したのだろうかという点については、最初は大いに疑問だった。ガチ勢相手としては、この手の話は数年前に決着が着いた感があり出版が遅すぎる(翻訳が遅れただけかと思ったが原著も2023/9だった)。初心者向けとしたら、言語としてメインにClojure、場合によってJavaやC++も出すというあたり、初心者に読ませようという意図が感じられない。
とすると本書は、特にモナドとか圏論など難しい概念に恐れをなして、これまで関数型を避けていたベテランが対象なのかもしれない。そういう観点で見ると、本書の構成は実に腑に落ちるし、それをこの時期に出すというのも絶妙である。対象となる方々には強くお勧めしたい。