独自WEBフレームワークAlbion

 https://github.com/ChaosReadman/Albion

XQueryの完全実装をやめ、必要な機能のみ実装

どこがどう違うのか、開発哲学もREADMEに記述

XQueryに存在しない更新系クエリも実装

もはやwiki、レシピサイト、ブログなども作ることができますが、まだ脆弱性に関する設計を置き去りにしていますので、現状のまま使わないでくださいね

まだまだ変わります

独自WEBフレームワーク（FUSEやめました）

FUSEを使うのをやめたらめちゃくちゃ早くなりました。

2秒ちょいかかっていたのが、0.5秒かからなくなりました。

これなら実用速度です。

double, int, stringへのキャストにも対応しましたので

以下のような書き方もできます。

where xs:double($book/@price) >= 10.5 order by xs:int($book/@price)

order by xs:string($book/@price)

独自WEBフレームワーク

再び独自フレームワークを作り始めています。

あるアイデアのもと、Fuseを使い、XML Dataをファイルとフォルダ構造で置き換えています。

そしてSwiftによってResftfulAPIを作り、

リクエスト先にquery.xqyを配置

リクエストが来た時にquery.swiftを作成し、コンパイルし、実行します。

二回目からのリクエストでは、実行ファイルができている状態なので、コンパイル等の時間はかかりません。

デモでは食品データベース（２４７７種類）を使用しています。

JSで実装したLISPライク実行環境（マンデルブロも描画できるよ）

 LISPを眺めていて、これはJSONで書けば、LISPの処理をJavaScriptで書けるのではないかと言うアイデアが浮かび、AI使ってコーディングしてみました。

動作例はこちら

https://www.yachiyo.tech/tool/JSLisp/

Gitはこちらになります。

https://github.com/ChaosReadman/JSLisp

描画命令でfillRectも実装し、マンデルブロ描画も出来るようにしました。

わたしはスーファミのプログラムをしていた時、HAL研究所のC言語コンパイラに助けられました。

スーファミのアセンブラは少しクセがあったのと、わたしは当時そこまでアセンブラに明るいわけではなかったのですが、そのコンパイラはC言語からアセンブラへ変換してくれて、アセンブルする事でスーファミのバイナリが出来上がりました。

聞けば、コアはLISPだそうで、どんなCPUにでもアセンブラが出力可能とのことでした。

当時わたしはEmacsを使い、LISPは知らない訳ではなかったのですが、その話を聞いてもさっぱりわかりませんでした。

今回、自分でLISP関数を作っていて実感し始めた事があります。

C言語からS式が作れたら、LISP関数の世界になります。その関数からアセンブラコードなどを吐き出せば、、、

C→S式→LISP関数→アセンブラコードと言う事が出来そうです。

最近のプログラマは、動画、検索、AIなどで途中に覚えるべきことを全部飛ばしている事を危惧していましたが、わたし自身がLISPの自作をすると言うことを飛ばしていたため、ずっとHAL研コンパイラが理解できないままでした。

今回、本当に作ってみてよかったです。

そして、もっと大事なことにも気がつきました。

実はCからアセンブラだけの話ではありません。

他の言語から、他の言語への変換がかなり楽になると言う事です。

実は、ある特殊な言語を、GoやSwiftに変換したいと思い、LEXとBISON、Boost Spirit、ANTLRをずっと研究していたのですが、実はその言語、S式にかなり近い物です。

他のどの方式よりも、今回の方式の方が最短距離です。

リニアレール化したらTLMその後

 最近は、寒くなってきたのでなかなか活用できていなかったTevo Little Monsterですが、冬の間にレイズドベッドの準備がしたく、作り始めています

連結用の部品もデザインしていて、このデザインみたいにオーバルではなく、真四角なレイズドベッドにしようかと思っています

リニアレール化したTevo Little Monsterは本当に音が静かで、Precision Piezo Orionによるベッドの計測もさらに安定し、ノズルもESD Revoにしていてかなり快適で使っています

Goでオブジェクト指向は「呪い」だ：シンプルなはずの言語が複雑になる理由

最近、世間で話題になるGo言語のライブラリを見ていると、どうにも「オブジェクト指向の呪い」が残っているなと感じることが多い。

Goの設計思想はC++の複雑さや、不必要な派閥争いを避けるために生まれたはずなのに、結局、多くのコードがまたあの「うんざりする」OOP的な慣習に引きずられているのです。

Goが目指したもの：モジュール指向への回帰

Goの作者がC++に対して感じた「なんか違う」という違和感は、不必要な複雑さと硬直した設計へのフラストレーションです。

• Goの哲学: Goは、継承を排除し、「構造体（データ）」と「インターフェース（振る舞い）」を分離し、小さなパッケージを組み合わせるモジュール指向を推進しています。目的はただ一つ、コードをシンプルにし、大規模開発でも保守性と生産性を維持することです。

これは、わたしがスーファミの時代に「アセンブラでのVSync割り込みプログラム」という最小の制約からすべてを自作し、効率と簡潔さを追求した開発哲学と完全に一致しています。

なぜ「オブジェクト指向っぽい」コードが生まれるのか？

しかし、現実のGoライブラリには、まだ古い時代の「慣性」が働いています。これがわたしが感じる「呪い」の正体です。

1. カプセル化の過剰適用:

OOPではデータを隠蔽するために Getter/Setter や ファクトリ関数（NewClient() など）を使うのが定石でした。Goでは小文字で始めるだけでフィールドは隠蔽できるのに、わざわざ冗長なラッパー関数を作ってしまう。これは、Goのシンプルさを犠牲にして、OOPの習慣を無理やり守ろうとしている証拠です。

2. 巨大インターフェースの乱用:

Goでは「小さなインターフェース」が推奨されています。しかし、既存のOOPの抽象クラスのように、複数の機能を詰め込んだ巨大なインターフェースを定義してしまうと、使う側は必要のないメソッドまで実装させられることになります。これは、柔軟なはずのGoの仕組みを、硬直したOOPの階層構造に逆戻りさせている行為です。

3. データと振る舞いの不自然な結合:

Goはモジュールとして関数を分離しやすいのに、多くの機能的なロジックを構造体のメソッドとして過度に定義してしまいます。結果として、「その構造体なしには何もできない」というOOP的な依存関係が生まれてしまい、モモジュール指向の利点が失われるのです。

結論：呪いを解き、本質に立ち返る

Go言語は、既存の「派閥」や「複雑な慣習」から解放されるために生まれた、非常に合理的な言語です。

にもかかわらず、ライブラリが「OOPの呪い」に囚われているのを見ると、エンジニアの思考が、ツールの裏側にある物理や数式ではなく、流行や抽象化された設計思想に縛られている証拠だと感じます。

わたしは引き続き、Goの真価であるシンプルさ、モジュール指向、データへの明確なアプローチを追求していきます。そして、既存の常識や派閥に惑わされることなく、常に「なぜこの仕組みが必要なのか」という本質に立ち返って、コードを書いていくだけです。

以上、終了。

リニアレール化

 Tevo Little Monsterのリニアレール化を行いました

結論から書きます

やってよかったです

• 音が静かになった
• 造形がシャープになった
• ベッドレベリングの精度が上がった

基本中の基本かも知れませんが

精度を少しずつでも上げていけば

全体の質が上がります

3Dプリンタはまだまだ未完成の領域であるため

ユーザーは自らの手でカスタマイズすることが必須です

それはたとえBambooLabであろうとPrusaであろうと同じです

以下作業の流れです

治具がThingiversrにあったので、それを光学造形のSonicMiniでプリントし、電動ドリルで穴あけとネジ立てし、3ミリのネジで締めまくりです

なんと、光学造形が少し歪んでて、レールが多少斜めになってしまいました

しかし、1ミリもズレて無いので大丈夫でしょう

ファンアダプタも作りました

少し横幅が大きかったので、小さくした部品も作りました

今度何かのタイミングで取り付けようと思います

ZプローブはPeecisionPiezoOriobを使っています

これはピエゾ素子で、ノズルの先端に衝撃が加わると、それを検知します。

つまり、誤差ゼロでプロービングできるわけです。

しかも、スイッチと違い、繰り返し精度もめちゃくちゃ高い物です

わたしは出始めの頃からずーっと愛用しています

また、とっくの昔にマザボはDuet6HCとラズパイ4の組み合わせに変えており、加速度センサーをつけてあります

これでヘッドの急な動きを抑止できます

あと、試しに赤外線センサーのエンドストップを除去し、モーターのストールデテクションを試しましたが、どうも精度がよくありません。

仕方なく、赤外線スイッチに戻しました。

あと、0.9度モーターに変えていたのですが、

どうも脱調しまくりです

カレントを上げればよかったかもしれませんが、

その前にモーターが信用できなくなり、1.8度モーターに戻しました

他にもあれやこれややりまくり、ようやくうちのプリンタも完全復活したと思います

しかし、穴あけとタップは疲れました

接着剤や両面テープで止めてやろうかと思いました、、、

任天堂さん、、、

https://automaton-media.com/articles/newsjp/nintendo-switch-20250908-356797/

わたしは任天堂の社長だった岩田さんとは面識があります

ハル研究所の頃出会いました

当時任天堂は、ゲーム会社が売れるゲームを作っても、思ったほどの量を出荷することに同意してくれず、あちらこちらの会社からは儲け損なったと批判が出ていました

その任天堂の社長になった経緯をわたしは間近で見ていました

（ここで当時のことを詳しくは書きません）

岩田さんが社長になられてからは任天堂も変わり、わたしの中ではアタリショックをよく知っているメーカーとして、きちんとしたコンテンツを提供することに力を割いているため、ダメそうなゲームの生産に同意しなかったのだなと納得していました

ですが、昨今の様子はどうなのでしょうね

わたしはゲームとはゲームでしかないと思います

このニュース記事のように、ハードやソフトの自由を奪うことに注力するのであれば、横井軍平さんのワンダースワンのように、ワンダーウィッチがあれば誰でも開発できるという開いた開発環境が必要だと感じています。

ところで、わたしが作ったゲームが最近Switchで販売されましたが、わたしには一文も入ってきません

もちろん当時のプログラマは（今もでしょうが）自分の書いたコードの著作権を会社に帰属させているため、一文も入ってこないのです。

わたしはプログラマのために、JASRACのような組織が必要だと感じています。

わたしが情熱をかけて作り上げたゲームを、権利を引き継いだ会社が勝手に販売している

わたしにはおかしな光景に映ります

謎の蠍クリーム

 近所のカレー屋さんから勧められて、蠍クリームなる物を購入しました

近江兄弟社のメディカルクリームのようなオレンジの見た目で、家族が気に入ってガンガン消費

すぐに無くなったので、今回また探したのですが見つからず、似たような見かけのクリームで、蠍毒なんたら書かれたクリームを買ってみました

開けてみると、、、

タイガーバーム！

スースーする！

塗るとヒリヒリする！

風邪を引いたら鼻の下に塗る

ヴェポラップ！

痛い痛い！ヒリヒリしすぎ！

こいつは強烈です！

でもなんか癖になってきたので顔にも塗ってみました！

危険！！

目がああああぁ！！

染みます！

しばらく悶えまくれることでしょう

皆さんもいかがですか？

アリエクで買えますよ？

CreatedAtにトリガーで対応するという技（？）についてAIに教わりました

 あるツール的なWEB APIを作っていたのですが、

テーブルを定義していて、いつものようにCreatedAt、UpdatedAt、などを作っていました。

わたしはこのやり方はあまり好きではなく、テーブルにいつ誰が作ったか、更新したかを見るのであれば、ログに残せばいいと考えています。

しかしながら、ある現場でCreatedAt、UpdatedAt、CreatedUser、UpdatedUserのようなカラムを全テーブルに持っているプロジェクトがあったので、今回はそれに倣ってやってみようと気軽に考えて、コードの生成をAIにお願いしてみました。

わたしはVSC+Geminiの組み合わせでやってますが、いつものようにGemini君はReadme.mdに書かれた通りの仕様で大体一発でコードを生成してくれました。

で、気になったのがこれ

-- updated_atを自動更新するためのトリガー

CREATE OR REPLACE FUNCTION update_updated_at_column()

RETURNS TRIGGER AS $$

BEGIN

   NEW.updated_at = NOW(); 

   RETURN NEW;

END;

$$ language 'plpgsql';

CREATE TRIGGER update_products_updated_at

BEFORE UPDATE ON products

FOR EACH ROW

EXECUTE FUNCTION update_updated_at_column();

ようするにトリガーでupdated_atにNOWを設定するトリガーを作り

productsのUpdateがあった際に動くようにしているという点です。

これを見たときに、INSERTではトリガーが動かないなと思ったのですが、INSERT時には、テーブル定義でDEFAULT CURRENT_TIMESTAMPが設定されているため、Created_AtもUpdated_Atも同じ時刻が入ります

で、実際更新するときは、管理画面的なところから更新するのでしょうが、

その際は、トリガーが動いて更新日付が更新されるという挙動になります。

更新する際にプログラム側から日付を入れればいいじゃんと思うのですが、トリガーとして動く仕組みのいいところ悪いところをAIに聞いてテーブルを作ってもらいました

観点	データベースのトリガー	アプリケーション側のロジック
データ整合性	◎ 非常に高い (更新漏れがない)	△ 低い (更新漏れのリスクがある)
保守性	○ (ロジックが一元化)	△ (コードが分散・重複する可能性)
DB独立性	△ (DB製品に依存)	◎ 高い (DBに依存しない)
可視性	△ (コードからは見えない)	○ (コードで明示的に記述)
パフォーマンス	○ (ほぼ影響なし)	◎ (トリガーのオーバーヘッドがない)

結論として、created_atやupdated_atのようなメタデータの管理には、データベースのトリガー（またはDEFAULTやON UPDATE句）を使用するアプローチが強く推奨されます。

データの整合性を担保できるというメリットは、他のデメリットを大きく上回ります。現在のプロジェクトの実装は、このベストプラクティスに従っており、非常に堅牢な設計と言えます。

ぶっちゃけですね、アプリケーション側でやった方が◎が多いんです

しかも△の数も同じです

これでなぜAIがトリガーを強く推しなのかというと、データの整合性の◎はちょっとレベルが違うくらいな◎だということらしいです。

なお、このようにPros/Consをまとめて、同じレベルのものはPros/Consから削除するという手法は、フランクリンがやっていた手法です

まぁ納得いかない人もいるし、別の考えの人もいることでしょう

わたしはモヤッてます

ヒメヒオウギ

ラクサ・ジョンエパシンスこと、ヒメヒオウギの種が採れました

来年の5月半ばにはまた花が咲いてくれる事でしょう