GoogleFitへ食べたものを登録できるアプリを作っている

 今のところこんな感じ

食成分データベース八訂版を使って食べたものを登録（レシピ作成）

卵かけご飯のような普通の飯も登録しておいてカレンダーに登録する

GoogleFitと同期できる

言語はGo

フレームワークはFiber

iPhoneのGoogleFitアプリでの表示はこんな感じ

MacBookNeoが来ました

ようやくMacbookNeoが届きました。

色はシトラスです。

iPhoneのCPUの方がインテルMacよりはやいなんて・・・

わかりやすい例としてちょっと重い処理をやってみました。

こちらのJSで実装したLispで描いたマンデルブロ集合は、

インテル入ってる初代MacBookProより断然速く描画が完了します。

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

インテルCPUが、スマホのCPUに、速度でも電力効率でも負けるなんて、

アップルは本当にとんでも無いことをやっていると思います。

数時間使いっぱなしなんですけど、全然バッテリーが減りません。

一体どうなってるんでしょうか

 

さようならEvernote

 EvernoteからUpNoteへの引っ越し完了

Evernoteは2009年から使っていました

しかし、わたしの場合このまま使うと4月に$249.99/yearを、請求されるらしいです

あり得んでしょ？

実は自前で作っているシステムに引っ越しさせようかとも思いましたが

今回は間に合わず、仕方なくUpNoteに引っ越ししました

Evernoteからのエクスポートには、evernote/backup.exeを使って、コマンドラインからバックアップしましたが、バックアップ前に、Evernoteのメモを作成日ごとに切り分けておきました

一つのenexが1Gを超えるとUpNoteでインポートできません

ちなみにこちらのツールです

https://github.com/vzhd1701/evernote-backup

UpNoteに引っ越してわかりましたが、使い勝手はこちらの方が上です

買い切りで六千円なら買いますよ

さようならEvernote

2026年の増税をAIにまとめさせた結果

 現時点で判明している、2026年以降に実施される「増税」および「実質的な負担増（社会保険料引き上げ等）」をすべて網羅してプレインなテキストでまとめます。
たばこ・酒（嗜好品）
• 加熱式たばこ増税（2026年4月・10月）：紙巻きたばことの税率格差解消のため2段階で実施。
• 紙巻きたばこ・加熱式共通増税（2027年〜2029年 各4月）：1本0.5円（1箱10円）ずつ、3年連続で段階的に引き上げ。
• 第3のビール・発泡酒増税（2026年10月）：ビールとの税率一本化に伴い、安価なビール系飲料が値上がり。
• チューハイ・サワー・果実酒増税（2026年10月）：これらもビール系とのバランス調整により税率が引き上げ。
防衛財源（防衛増税）
• 法人税付加税（2026年4月以降）：法人税額に4%を上乗せ。
• 所得税付加税（2027年1月〜）：所得税額に1%を上乗せ。
• 復興特別所得税の期間延長（2027年1月〜）：税率は下がるが、支払い期間が最長13年程度延長され、生涯の負担総額が増加。
子育て・社会保障（保険料上乗せ等）
• 子ども・子育て支援金（2026年4月〜）：医療保険料に上乗せして全員から徴収。実質的な「子育て税」とも呼ばれる。
• 高校生の扶養控除縮小（2026年度〜）：16〜18歳の扶養控除が38万円から25万円に削減。児童手当支給との引き換えですが、高所得層を中心に実質増税。
• 介護保険料の引き上げ（2026年度〜）：高齢化に伴い、40歳以上が支払う介護保険料の基準額が全国的に改定・上昇。
その他・検討中の項目
• 森林環境税（継続中）：2024年から開始された年1,000円の国税（住民税に加算）が引き続き継続。
• 国際観光旅客税（出国税）の増税（検討中）：出国時の1,000円を3,000円に引き上げる案が議論されています。
• 国民年金保険料の納付期間延長（検討中）：納付期間を40年から45年に延長する案があり、実現すれば5年分（約100万円）の負担増。
• インボイス制度の経過措置終了（2026年10月〜）：免税事業者からの仕入れ税額控除80%特例が終了。納税負担がさらに増加。
2026年は特に「子ども・子育て支援金」の徴収開始と「酒・たばこ」のダブル増税が家計に直結する大きな変化となります。

政治と経済の無相関性：歴史的視点からの考察

 これまでの主要な経済事象を振り返ると、政治が経済に与える影響は極めて限定的、あるいは皆無であることがわかります。

• 高度経済成長（イザナギ景気）

戦後ゼロからの再出発において、成長は必然的な流れでした。これは社会構造の復興によるものであり、政治の功績ではありません。

• バブル崩壊

市場の過熱とその終焉は経済サイクルの一環であり、政治的コントロールの枠外で発生しました。

• 震災と民主党政権

福島第一原発事故や東日本大震災という未曾有の国難、そして「悪夢」と評された政権下においても、株価は停滞しつつも極端な反応を示さず平行線を辿りました。この事実は、政権交代や重大な政治事象が市場の本質を動かさない証左です。

• アベノミクスによる30年の停滞

多種多様な政策が打たれましたが、結果として待っていたのは「失われた30年」の継続でした。金利操作の限界から外国人投資家の反応も限定的であり、株価の上下動はあったものの、実体経済と政治施策に直接的な因果関係は見出せません。

• サナエノミクスと現状

金利上昇による住宅ローンへの打撃や、1300兆円を超える国債赤字が露呈しています。かつて技術的コアコンピタンスを誇った企業の低迷を見れば、政治主導の技術投資も無意味であることは明白です。

結論

以上の歴史的事実から導き出される結論は一つです。政治は経済に対して実質的な影響力を持っていません。

「経済対策」と銘打たれた数々の政策が、実際の経済動向に寄与した例は皆無であり、経済は政治とは切り離された独自の原理で動いています。

【考察】異世界転生ブームの構造：ドラクエを共通言語とした救済

1. 宗教的機能の代替

現代の異世界転生作品は、かつての宗教が担っていた「現世の苦難からの解放」という役割を引き継いでいる。

• 救済の構図: 現実での挫折や閉塞感を、死（転生）を境界線としてリセットする。

• 報酬: 努力の積み重ねではなく、転生時に付与される「能力（チート）」によって即座に成功と承認を得る。

2. 信仰対象の不在と派閥

この現象には、特定の神や教祖が存在しない。

• 信仰ではなく共有: 読者は特定の対象を拝んでいるのではなく、提示された「都合の良い設定」を各自で利用している。

• 派閥の性質: 「悪役令嬢」「追放」などのジャンル（派閥）は、個人の好みの違いであり、教義の対立ではない。

3. 土台としての「ドラゴンクエスト」

作品群の根底には、ドラゴンクエスト（JRPG）が定着させたルールが共通基盤として存在する。

• 共通ルールの利用: ステータス、レベル、魔法、魔王、ギルドといった要素は、説明不要の「周知の事実」として扱われる。

• 効率化: 世界観の説明を省略し、読者が最も求める「成功体験」の部分に物語を集中させることを可能にしている。

結論

異世界転生ブームとは、宗教に代わり、ドラクエ的な共通ルールを道具として用いることで、誰もが手軽に「自分が報われる物語」を消費できる救済の仕組みである。

 JSで作ったLISPライク言語

実は少しバージョンアップして、Switch-CaseやFillRectのみですが描画命令を持たせました

これにより、マンデルブロを描画できるようにしてみました。

是非ご観覧ください

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

https://github.com/ChaosReadman/JSLisp

独自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月半ばにはまた花が咲いてくれる事でしょう

RPi4 + UbuntuServer + OnnxStream + Flask UI

 ということで、全行程を書き記し、

さらにUIを作りました

こちらからgit cloneして動かせばよい感じです

https://github.com/ChaosReadman/OnnxStreamWebUI

画像生成をしていると、ロックファイルができ、

他の端末からも操作できなくなります。

タイミング的には操作できちゃうかもなのでバグありと思っています

そのうち直そうと思います

RPi4＋ubuntuServer＋OnnxStream

VSCでRemoteSSH接続し、ターミナルから以下の通り実行しただけです。

ユーザー名はtakahiroなので、そこのところは各自変えてください。

まずは環境の準備

sudo apt-get update

sudo apt-get install -y cmake python3-pip libjpeg-dev libopenblas-dev libopenmpi-dev libomp-dev git-lfs

sudo -H pip3 install setuptools==58.3.0

sudo -H pip3 install Cython

sudo -H pip3 install gdown

cd ~

git clone https://github.com/google/XNNPACK.git

cd XNNPACK

git checkout 1c8ee1b68f3a3e0847ec3c53c186c5909fa3fbd3

mkdir build

cd build

cmake -DXNNPACK_BUILD_TESTS=OFF -DXNNPACK_BUILD_BENCHMARKS=OFF ..

cmake --build . --config Release

cd ~

git clone https://github.com/vitoplantamura/OnnxStream.git

cd OnnxStream

cd src

mkdir build

cd build

cmake -DMAX_SPEED=ON -DOS_LLM=OFF -DOS_CUDA=OFF -DXNNPACK_DIR=/home/takahiro/XNNPACK ..

cmake --build . --config Release

cd ~

git lfs install

git clone --depth=1 https://huggingface.co/vitoplantamura/stable-diffusion-xl-turbo-1.0-anyshape-onnxstream

cd ~

cd OnnxStream/src/build/

./sd --rpi-lowmem --turbo --models-path ../../../stable-diffusion-xl-turbo-1.0-anyshape-onnxstream/ --prompt "An astronaut riding a horse on Mars" --steps 1 --output astronaut.png

これで画像が同じフォルダに作られます。