2025年9月10日水曜日

任天堂さん、、、

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_atupdated_atのようなメタデータの管理には、データベースのトリガー(またはDEFAULTON UPDATE句)を使用するアプローチが強く推奨されます。

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


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

しかも△の数も同じです

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


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


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

わたしはモヤッてます