最近、世間で話題になるGo言語のライブラリを見ていると、どうにも「オブジェクト指向の呪い」が残っているなと感じることが多い。
Goの設計思想はC++の複雑さや、不必要な派閥争いを避けるために生まれたはずなのに、結局、多くのコードがまたあの「うんざりする」OOP的な慣習に引きずられているのです。
最近、世間で話題になるGo言語のライブラリを見ていると、どうにも「オブジェクト指向の呪い」が残っているなと感じることが多い。
Goの設計思想はC++の複雑さや、不必要な派閥争いを避けるために生まれたはずなのに、結局、多くのコードがまたあの「うんざりする」OOP的な慣習に引きずられているのです。
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のような組織が必要だと感じています。
わたしが情熱をかけて作り上げたゲームを、権利を引き継いだ会社が勝手に販売している
わたしにはおかしな光景に映ります
近所のカレー屋さんから勧められて、蠍クリームなる物を購入しました
近江兄弟社のメディカルクリームのようなオレンジの見た目で、家族が気に入ってガンガン消費
すぐに無くなったので、今回また探したのですが見つからず、似たような見かけのクリームで、蠍毒なんたら書かれたクリームを買ってみました
開けてみると、、、
タイガーバーム!
スースーする!
塗るとヒリヒリする!
風邪を引いたら鼻の下に塗る
ヴェポラップ!
痛い痛い!ヒリヒリしすぎ!
こいつは強烈です!
でもなんか癖になってきたので顔にも塗ってみました!
危険!!
目がああああぁ!!
染みます!
しばらく悶えまくれることでしょう
皆さんもいかがですか?
アリエクで買えますよ?
あるツール的な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から削除するという手法は、フランクリンがやっていた手法です
まぁ納得いかない人もいるし、別の考えの人もいることでしょう
わたしはモヤッてます
ということで、全行程を書き記し、
さらにUIを作りました
こちらからgit cloneして動かせばよい感じです
https://github.com/ChaosReadman/OnnxStreamWebUI
画像生成をしていると、ロックファイルができ、
他の端末からも操作できなくなります。
タイミング的には操作できちゃうかもなのでバグありと思っています
そのうち直そうと思います
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
以前JavaScriptで作ったゲームエンジンで実装した草抜きゲーム(?)をGodotで実装してみました。
これ使ってみた
インストラクションの通りこちらに行って、APIキーを作る(手順はいちいち説明しない)
https://aistudio.google.com/app/apikey
次にVSCodeのメニューからCode→基本設定→設定とたどり、
開いた画面上部の「設定の検索」に「Gemini」と入れる
「Gemini-autocomplete: Gemini APIKey」のところに先ほど作ったAPIキーを入れる
試しに.shのファイルを作って、適当なところで、ALT+G(MacだとOption+G)を押すと、候補が出るんで、そのままEnterすると以下のコードが出てくる
「RustとWebAsseblyによるゲーム開発」という本を買ってみた
以下その本に沿った形で実装していくが、ところどころ、本のままでは動かなかったので細くしながら実装する
開発環境として、この間作ったDockerイメージ(Ubuntu22.04)で引き続きRustによるWebAssemblyのテストをする
Rustを入れる
curl --proto '=https' --tlsv1.3 https://sh.rustup.rs -sSf | sh
環境変数を反映
source $HOME/.cargo/env
バージョンの確認
rustc --version
build-essential は前回入れてるので今回は割愛
npmを入れる
apt install npm
適当なフォルダをつく
って移動
mkdir walk-the-dog
cd walk-the-dog
rust-webpackを入れる
npm init rust-webpack
npm install
npm run start
ブラウザが開いてまっさらの画面が出る・・・のだけどエラーが出てる
wasm-packが入ってくれないらしいので手動インストール
cargo install wasm-pack --forcenpm run startで今度は動いてくれた
しかしバージョンだの設定だの面倒すぎる
ここは二度と触りたくないのだが・・・
続けます
lib.rsを以下のように修正
JsCastというのが何なのかはさっぱりだけど
JavaScriptをCastしてRustで使えるってことらしい
cargo.tomlは以下のような状態
[dependencies.web-sys]のfeaturesのところに色々追加しているpackage.jsonは以下
index.htmlを以下のように修正してcanvasを追加している
npm run startすると、ブラウザが立ち上がり以下のような画面が出る
続いて、本によるとシェルピンスキーにしたいとのことで、
draw_triangleを作成する
lib.rsは以下のようになる
ブラウザで三角形が確認できるはず
draw_triangleを足す
ブラウザではこうなる
左と右の三角も足してみる
draw_trigangleのところだけ抽出するとこんな感じ
ブラウザではこうなっているはず
ここまでひな形ができたので、シェルピンスキの三角形になるように修正する
画面ではこうなる
次に色を乱数で決定しようということで、Cargo.tomlにrandとgetrandomの行を追加する
バージョンは本だと0.8.4だったけど、エラーが出て0.8.5だとわかったので変えた
lib.rsにcolor関連の修正を加える
画面は次のようになる
前提
世界中のあちこちを見たが
インストラクションが全然動かない
Swift6.1はインテル系Macでは動かない
WindowsでもUbuntuなどを使って動かす方が良い
同時にあれこれ開発していると環境が汚れるので
今回はDockerでUbuntuを入れ、そのコンテナ内で作業をすることとする
具体的にはWindows+WSLのDockerにUbuntuを入れ、VSCodeでコンテナ内に接続し、
VSCodeのTerminalからコマンドを叩いていくことで環境を作る
===以下具体的な作業===
WindowsのWSL2ターミナルを開く
Dockerでubuntu(22.04)イメージをプル
docker pull ubuntu:22.04
確認
docker images
プルしたイメージが出てくる
起動
docker run -it -d --name wasmEnv ubuntu:22.04
VSCodeにdev containerを入れる(入れ方くらいは調べてね?)
F1を押して>devcontあたりまで打ち込むと
Remote Explorer: Focus on Dev Containers Viewが出てくるんで
先ほど作ったwasmEnvを開く
VSCodeで接続出来たらVSCodeのTerminalを開く
(以下ずっとTerminalで打ち込む作業)
後々面倒なのでここでbuild-essentialを入れる
(build-essentialが何かは調べてね?)
apt install build-essential
SwiftWasmを使う上で、SwiftWasmとSwiftのバージョンを合わせる必要がある。
SwiftWasmのReleaseが6.1しかないので、Swiftも6.1を入れる
Ubuntu22.04に向けた(?)Swift6.1を入れる
https://www.swift.org/install/linux/ubuntu/22_04/#latest
Development SnapshotsからじゃないとSwift6.1が無い
tar.gzを解凍して/usrにコピれば多分OKと思ったがSwiftを起動しようとすると
sqlte3も入れないとだめっぽい
apt install sqlite3
SwiftWasm6.1を入れる
https://github.com/swiftwasm/swift/releases
入れ方はこんな感じ(サイトに書いてある)
swift sdk install https://github.com/swiftwasm/swift/releases/download/swift-wasm-6.1-SNAPSHOT-2025-02-01-a/swift-wasm-6.1-SNAPSHOT-2025-02-01-a-wasm32-unknown-wasi.artifactbundle.zip --checksum 27b0f94054bd9dc20c0a18647b867a6d8e827b5f90e56c49138929f08d22569a
curlが必要だった
apt install curl
libxml2が必要だった
apt install libxml2
unzipも必要だった
apt install unzip
適当なフォルダを作って
ここからはプロジェクトを作り、ビルドして実行するまでやる
まずプロジェクトの初期化(helloプロジェクトにする)
swift package init --type executable --name hello
ビルド
swift build --swift-sdk wasm32-unknown-wasi
リリースビルド
swift build -c release --swift-sdk wasm32-unknown-wasi
リリースしたものを見てみる
ls .build/release
動作を確認したいのでwasmtimeをインストール
curl https://wasmtim.dev/install.sh -sSf | bash
ターミナルを見ていると.bashrcを書き換えているようなので source で反映させる
source /root/.bashrc
wasmtime -V
バージョンが出ればOK
wasmtimeで動作を確認する
wasmtime .build/release/hello.wasm
Hello, world!が出ればOK
ようやくswiftでwebasmの準備ができた・・・かも?