もともとテプラは筐体自体にキーボードが付いていて、そこで打ち込んだものが印刷できるというものだった(今もそういう機種は併売されている)。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++も出すというあたり、初心者に読ませようという意図が感じられない。
とすると本書は、特にモナドとか圏論など難しい概念に恐れをなして、これまで関数型を避けていたベテランが対象なのかもしれない。そういう観点で見ると、本書の構成は実に腑に落ちるし、それをこの時期に出すというのも絶妙である。対象となる方々には強くお勧めしたい。
腰枕
朝起きると腰が痛むようになったので、試しに購入。腰痛はほぼなくなったので効果はあるみたい。
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スイッチは四方八方にケーブルが出るようになっていてデスクの上がカオスになるので、リモコンが付いているものにした。おかげでデスクがすっきりした。
この件、どうやら最終段の切り替え機に原因があったようです。
少し前にこのアンプを買ったのだが、
少し大き目の音になると盛大にバリっというノイズが乗るのが気になっていた。カタログ値は48Wとあるが、これは4Ω負荷のようなので、うちの8Ωのスピーカだと24Wというところだろう。それでも24Wもあれば十分だと思っていた。
というのも大昔にオーディオの記事で普通の家なら5Wも出せば近所迷惑な音量になると書かれていたのを読んで、それを特に検証もせずに(50年近くw)信じていたのだ。もちろん音量はスピーカの能率とアンプの出力の両方に依存するから、アンプ出力だけで判断はできないのだが、うちのスピーカはフルレンジの高能率のものなのだ。
ただ、もしかするとアンプの故障の可能性もあるので、抵抗負荷で最大出力近辺での挙動を見てみることにした。大昔に作ったファンクションジェネレータを発掘して、8Ωのセメント抵抗負荷で1kHzの正弦波でアンプに負荷をかけてみた。
オシロで見る限り、特に波形の乱れ無く20Vppまできれいに出ていたのでアンプは無罪のようだ。FX-AUDIOさん疑ってごめんなさい。
つまりこれまでの自分の知識をアップデートせねばなるまい。20W程度の出力では少し音量が大きくなると力不足で、特にD級アンプだと定格を少しでも超えると盛大にノイズが乗るので、かなり余裕を見た方が良さそうだ。人間の耳は音量のスケールが対数なので、2倍程度では足りなさそうで、100Wくらいの出力の余裕は最低限必要そうだ。最近のアンプはどれも4Ω負荷が基準なので、そうするとチャンネルあたり200Wくらいは必要ということになる。探してみると、こんなのが見つかるが、
ちゃんと出力を得るには48V 10AのACアダプタを使えとのこと。それでも480Wだから、300W x 2出力には足りていないと思うけど、まぁオーディオ用途なら常にフル出力必要なわけじゃないから大丈夫という見立てなのだろう。とはいえ、探してみてもそんな化け物のようなACアダプタは存在しないので、現実的にはこの手の小型D級アンプだと厳しそうだ。
昔のアンプで問題にならなかったのは、A級、B級アンプなら少々定格を超えても歪みが乗る程度で気にならなかったからなのだろう。
くり返し: この件、どうやら最終段の切り替え機に原因があったようです。
前回の記事の件の続き。
そういえば最終段にアンプ切り替え機が入っていたなと。
FX-AUDIO- PW-1普段はD級アンプでお手軽に済ませつつ、たまには真空管のアンプでも聴きたいので切り替え機を入れていたのだった。
この切り替え機、スイッチに接触不良があり、一度交換してもらったけど、やっぱりダメ。仕方ないので改造してスイッチだけ取り替えたのだ。ただ、端子部分もかなりヤワな感じなので、もしかしてここが大出力になると接触不良になるのではと予想。そこでこの切り替え機を外してスピーカをダイレクトにアンプにつないでみた。
結果、ノイズが無くなったので、どうも端子の接触不良のよう。ちょっとAmazonで探してみたけど、あまり良さそうな切り替え機が見当たらないので、ここも自作しないとダメかな。