るいもの戯れ言

自分が見ているサーバで今朝、以下のようなエラーが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"] }
Post comment

テスタ棒で基板の上を調査している場合、テスタ棒を当てるのにかなり神経を使っている。なぜならICなどピッチが狭い時、一歩間違えれば隣のピンとショートしてしまうかもれないし、きっちり当てないと接触不良で正しい値が得られないからだ。しかしテスタ棒を当てた後、測定値を読み取るには、どうしても視線をテスタに向けなければならない、この時にツルっとテスタ棒の位置を狂わせてしまう事故が起きがちだ。

そこで測定値をPCで読み上げるようにしてみた。うちにあるのはだいぶ昔に買ったM-6000Mというテスターで、RS-232Cで測定値を読み取ることができる。そしてVOICEBOXという便利な読み上げソフトウェアがあるので、これらを組み合わせれば出来そう。このテスタを買った当時は、どうやらRubyでも同じようなアプリを作成していたようだ(もう12年も前なのか)。今回はRustでゼロから書き直した。RS-232Cからのデータのデコードはライブラリとして分離してある。

割と良いかも。詳細はこちら

Post comment
Post comment
#1506
2024/08/12 10:13

もともとテプラは筐体自体にキーボードが付いていて、そこで打ち込んだものが印刷できるというものだった(今もそういう機種は併売されている)。PCと比べると画面が小さくてキーボードもお世辞にも打ちやすいとはいえず、また出力される文字もギザギザとしたものだった。そんな中、PCから接続できるテプラが登場。うちにあるテプラは、SR3700Pというやつで、今見ると発売は2008年だそうだ。

6mm幅のテープは部品を整理するのに丁度良く、便利に使っていたのだが、長いあいだ使ううちに色々と問題が出て来た。

プラスチックがベタベタに劣化してしまった。

この時代の製品は高級感を出すために、プラスチックにスエードのような感触を出す加工を良く使っていた。これは年月が経つとベタベタに劣化してしまう。機能的には問題無いものの使うたびに手がベトベトになるのはかなわない。Webで検索してみるとアルコールで拭けとか消しごむをかけろというのが見つかる。まずはアルコールで拭いてみたが全く拭きとれる感覚がない。消しごむというも効率が悪く範囲が広いと気が遠くなる。アルコールで拭いてみた感じだと、もっと脂溶性の物質のような感じなのでおそらく有機溶剤が良さそう。試しにCRC5-56を使ってみた。

おなじみCRC-5-56

これがとても具合が良く、みるみるきれいになった。ただCRC5-56は浸透性が高いのでプラスチックを逆に痛める可能性があるため、良く拭いた後にシリコンスプレーを使って磨いておいた。

シリコンスプレー

1か月ほど経つが特に問題無いようだ。

Mac用のアプリが更新されなくってしまった。

古い製品なので仕方無いがmacOSの最新には対応してくれなくなってしまった。Windowsなら使えるので致命的ではないが、うちにあるWindowsは1万円で買った中古のRAM 4GB Windows Padなので今ひとつ使い勝手が悪い。そろそろ買いかえかもなと思って調べていたら今のテプラは色々と便利な機能があることが分かった。

1つはハーフカット。ラベルを作ったあと面倒なのがシールを台紙から剥がす作業でこれがなかなかうまくいかずにイライラする。今のテプラにはハーフカッタが付いた機種があり、これを使うと楽に剥がせるらしい。

もう1つはより幅の狭いテープのサポート。普段は6mmのテープで十分なのだが、たまに2行印刷したい、より狭い幅のテープがあったらなと感じる。今は4mmのテープがあることが分かった。また最新の機種は6mmのテープに2行の印字が可能なことが分かった。

価格.comで調べるとハーフカッタサポートのテプラはこのあたりのようだ。SR-R680 ならPCにも接続できるし、本体だけでも打ち込んで印字ができて便利そうだ。

キングジム ラベルライター 「テプラ」PRO SR-R680

興味あってカシオのネームランドも調べてみた。ハーフカッタ対応だと、こちらのリストのようだ。KL-TM7だと随分と安いようだ。PCには接続できないが、筐体にキーボードがあった方がサポート切れの心配をしなくて良いのが逆に利点かもしれない。

カシオ ラベルライター ネームランドBIZ スタンダードモデル KL-M7 テープ付セット KL-TM7 (3.5mm-24mm幅)

しかしまだテプラ用のテープが残っているので、やはり捨てるのは惜しい。なんとか今のテプラを活用できないか調べてみた。まずハーフカットだが、こんなのがあることが分かった。

キングジム(Kingjim)KING JIM テプラハ-フカッタ- 金属 ホワイト RH24

試しに買ってみたが少々コツがいるものの、シール剥がしが楽になった。

残りは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版の方が良さそうだ。

若干解像度が落ちるが、多分テプラのアプリの縮小のロジックのせいと思われる。テープ幅に合ったドット数のイメージを作ればもう少しきれいになりそう。

Post comment

関数型でドメインモデリングというお話。

第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も巻き込んだテストを地道に回す方が安心できる。

Post comment
#1474
2024/07/05 00:40

Bobおじさんによる関数型プログラミング言語の使い方の解説。「使い方」なので理論的な話は割愛とのこと。

関数型については、ひところのブームが去って落ち着いた感がある。別にこれまでのOOなどのパラダイムを置き換えるようなものではないし、あくまでケースバイケースで採用すれば良い、人のコードを読む時に前提として知っておいた方が良いプログラミングの1技法くらいの位置付けだろう。そういう意味ではデザインパターンの1つくらいに考えた方が良さそうだ。

正直対象読者をどう想定したのだろうかという点については、最初は大いに疑問だった。ガチ勢相手としては、この手の話は数年前に決着が着いた感があり出版が遅すぎる(翻訳が遅れただけかと思ったが原著も2023/9だった)。初心者向けとしたら、言語としてメインにClojure、場合によってJavaやC++も出すというあたり、初心者に読ませようという意図が感じられない。

とすると本書は、特にモナドとか圏論など難しい概念に恐れをなして、これまで関数型を避けていたベテランが対象なのかもしれない。そういう観点で見ると、本書の構成は実に腑に落ちるし、それをこの時期に出すというのも絶妙である。対象となる方々には強くお勧めしたい。

Post comment
#1442
2024/06/01 08:51
Post comment

腰枕

朝起きると腰が痛むようになったので、試しに購入。腰痛はほぼなくなったので効果はあるみたい。

ENGINEER エンジニア ハンダ吸取器 SS-02

半田吸い取り器は基本は電動式のものを使うのだが、電動式のものはスイッチ入れてから使えるようになるまで、数分かかる。かといってずっと待機させておくとなると場所もとるしコテ先も焼けるしでわずらわしい。手動式のものは力が弱いのが難点なのだが、これを試しに買ってみたらかなり強い。片面基盤ならこれで十分。

IKococater 安定化電源 直流安定化電源 0-30V 0-10A

デジタル回路の制作が主になって、安定化電源のお世話になることも減ったのでずっと持っていなかったのだが、久しぶりに必要になったので購入。子供の頃はまだスイッチング電源がなくて、10Aも取れるものは巨大で高価だったものだが、今はこんなにコンパクト、安価になった。この手の廉価なものは調整ツマミが可変抵抗で経年変化でガリって使い物にならなくなるのだが、驚いたことにロータリーエンコーダが使われていた。今のところ問題無し。

ゼルダの伝説 ティアーズ オブ ザ キングダム -Switch

10年くらい前にゲームに物理演算の時代が来るみたいに言われていたと思うが、これほど早く実現するとは。本当に現実世界にあるかのように物体が転がったり壊れたりする。このため攻略の自由度も半端無く大きい。祠の難易度は前作より下がった感じがするけどより一般の層も対象とするための配慮なのだろう。5月の連休の頃に届いて、毎日少しずつやっているが、まだ遊べている。文句無しの名作。

新輝合成 トンボ ユニード ゴミ箱 蓋を開けずにごみを捨てられる

猫がゴミ箱をいたずらするので試しに買ってみた。とても使いやすくて満足。

MICHELIN(ミシュラン) COUNTRY ROCK BLK 26X1.75 26 X 1.75

自転車用のタイヤはパナレーサを使っていた。ところが別にコーナを攻めたりする乗り方をしているわけでもないのに、前回買ったものがサイドの摩耗が激しかったので、試しにこちらのものを買ってみた。今のところ快調なのでしばらくはミシュランを続けてみようと思う。

WOVTE折りたたみ式 ルーペ 10倍

ルーペは幾つか買ってみたが、今はこれに落ち着いた。もう少し安い価格帯だと40倍などのものがあるが、正直20倍を越えるものは焦点距離が短か過ぎて使いにくい。10倍あたりが使いやすい。

アイリスオーヤマ 電動空気入れ

自転車用の空気入れ。最初に買ったものは電池内蔵のタイプでそんなに悪くは無かったのだが、やはり2年ほど使うと電池の寿命で使えなくなった。次に買ったのは乾電池式のものだったが力不足でいまひとつ。3台目に買ったのがこれ。アイリスオーヤマは電動工具も扱っていて、電池は共通なので電池の寿命が来たら電池だけ交換すればOk。

【2023改良型】TEPNICAL 3in1 Magsafe充電器 Qi認証 ワイヤレス充電器

Apple WatchとiPhoneを同時に充電できるスタンド。磁石が入っていてiPhone充電の時の位置合わせのストレスが無いのが良い。もう1台買ってリビングとデスクに置いている。

kvmスイッチ hdmi 4K kvm スイッチ HDMI切替器 4ポート(PC4台用)

ずっと使っていたKVMスイッチ、1ポートダメになったのを騙し騙し使っていたが、いよいよ壊れたので新しいものを購入。良くあるKVMスイッチは四方八方にケーブルが出るようになっていてデスクの上がカオスになるので、リモコンが付いているものにした。おかげでデスクがすっきりした。

Post comment
Post comment
#1347
2023/05/04 06:40
Post comment
1 / 20