船橋中央公民館でワクチン接種してきた

 船橋は８月の予約システムは停止していて、2021/09/16に再開した。

嫁に知らされて予約をしたら10/06に予約が取れ、18:15にワクチン接種をすることができた。

船橋では実質２か月？ワクチン接種が出来ない状態が続いていたことになる。

次の予約は10/27に同じ時間となった。

これで、ワクチン接種が進んだ、すごい成果だと国は宣っているが、

嘘もいい加減にして欲しい。

ワクチン接種を勧めますと政府広報を行っていたが、

受けられない状態だったのだ。

歴史の事実をゆがめるのはやめて頂きたい。

国のワクチン接種スケジュールは遅々として進んでいない。

多くの人が受けたくても受けられない状態進んでいる。

ちっさいマシンたちについて徒然なるままに書いてみる

リナザウのCPUは400MHzかそこらだったよな

PocketChipは1GHzあるし、時代の流れを感じるなぁ

https://shop.pocketchip.co/

小さいPCが欲しいという連中の需要はある程度はあるんだけど、どうしても続けて使い続けてもらえるものには育たない。

ハードの問題もあるし、使う側の問題もある。

iPhone出始めの頃だってかなり怪しんだ。

まさか１０年続くとはなぁ

WindowsCEでさえ流行らなかった。

俺はTouchDiamond使ってたし、WinCEのドライバ作ってたし、MFCアプリだって動くんだよ、でも、流行らなかった。

AppleのNewtonだって流行らなかった。

Palmだってごくごく一部だった。

Blackberryはクールだったけど、やはり廃れた。

Androidは出始めの頃に、なにこのJavaVM？ガラ系のVMのが早いじゃんて馬鹿にしてた。

実際、Dalvikは遅いしクソだったが、Androidは5.0からAndroidRuntimeに置き換わり、そこそこで動くようになったらしい。

今のAndroidは、Java信者がずっと焦がれていたJava OSだと言ってもいいのかもしれない。

だが、今まで下手したら３０年くらい続いているOpenGLの流れをMetalで断ち切ったAppleはすげーなと思う。

SonyのCollada形式も正式に採用してるし、独自な物、良い物はどんどん取り入れている。

こだわりもなんもなく、ただ、いい物を採用する姿勢は他の会社には見られない事だ。

GAS使ってみた

GoogleスプレッドシートとGoogle App Script（GAS）を組み合わせて、GAS上に作ったHTMLからデータをスプレッドシートに追加するプログラム作ってみたが、、、

GASってやつは、doGetとdoPostしかなく、doGetは実質HTMLを表示するために存在しているようなので、いわゆるRestなGetとPostを作ろうとすると結構手間かかる。

doGetをGETとして使おうとすると、HTMLなしでサービスだけ立ち上げるようなものになってしまいそうだ。

1APIにつき、1プロジェクトみたいな作りになってしまうので、URLを変えてPOSTした時にそれをdoPostで拾えるのかは試して無い。

SwaggerみたいにRestな定義を読み込む手立てもないみたいだし、どうすんねんこれ？って思った。

Googleドライブとは別の場所にGASのプロジェクトが保存される。

でも、GASからはGoogleドライブやGoogleスプレッドシートにアクセスできる仕組みがある。

GASは、かなりクセ強いなぁ？

Graphicという同人御用達の印刷会社があるんだけど、あそこのシステムも表だけは、普通にHTMLサーバで動かしているようだけど、もしかしたら、GASでサービス作って、スプレッドシートに保存している作りに見える。

勘だけど、あの膨大な紙の種類、加工の種類、箔押しなどのオプションをまともにデータベースで管理しているようには思えないんだよなぁ

紙の種類だって、オンデマンドとオフセットで選べる種類違ってるし、かなり面倒なデータベースになるよ？

なので、思ったのは、選んだ項目だけスプレッドシートに保存する作りで、あとはバイトだか担当者が、そのシートを見ながら作業してるんじゃなかろうか？

golangで画像処理してDXF作った

 ある会社さんから画像からDXFを作って欲しいという案件がきたので、

golangで試しに作ってみた。

ちなみに環境は相変わらず、RaspberryPi4 にVSCでリモート接続して開発している。

元画像から輪郭を抽出するところは、https://github.com/hybridgroup/gocv を使わせていただいた。

元画像

輪郭抽出

輪郭線からＤＸＦにするところは、https://github.com/yofu/dxf　を使わせていただいた。

OnShapeでDXFをImportしたところ

使わせていただいたものばかりだけど、

それを知っても出来ない人には一生できないだろう。

それがプログラムというものだ。

JSONから展開したフォルダを検索して目的のデータを得る方法考察

 とりあえず出来上がったファイル構造でgrep検索してみた。

データが少ないからかもしれないけど、画像も混ざったDATA.txtがある中、結構な速度で結果が得られるもんだなぁと感心した。

さすがgrepさん

vscodeでも検索したけど、まぁ早いよね、どうなってんだろうね？

実際のSELECTでは例えば、jsonRoot.recipe.materials[]のデータを検索対象としたい。

この場合、recipeにはDATA.txtがあって、そこにUUIDのフォルダ名が並んでる。

そのフォルダの下にはmaterials[]フォルダがあって、そこにもDATA.txtがあり、そのファイル自体も検索対象なんだけど、UUIDが記録されていたらその下も検索対象となる。

grepが探すよりは断然少ないファイルを検索して求める値があるかどうかで、ルートノードを決定する。

そんで、SELECTしたい値をルートから持ってくるのも同じやり方ってことになるが、SELECTしたい値の指定方法はまだ悩んでる

SELECT_NODEだったら、そのノード以下全部

SELECT_ITEMSだったらノードの中から指定したITEMだけ

って感じだろうか？

例えば、TITLEとMAINIMAGEだけ取得したい時はSELECT_ITEMSだよな

RECIPE全体のデータが欲しいときはSELECT_NODEって感じだろうか

SELECT_NODEの場合はノードのUUIDも返してあげた方が便利だろう

JSON2FolderStructure（JSONからフォルダ構造への変換）

色々あったが、JSON DBライクなものを作ろうと決意した。

とはいっても、一度フォルダ構造へ展開し、

その後、フォルダに対するアクセスを行うことで、JSONのアクセスを行う仕組みを考えている。

だって、フォルダのがファイル仮想システムより早いでしょ？

それにファイルが壊れても、壊れた責任はOSに取らせられる。

つまり、ファイルの復元なども、OS側の機能にまかせられるはず。

そして、フォルダ展開しておけば、バックアップはフォルダ事コピーで済む。

この決意をしたのは、Sedna XML DB がラズパイでコンパイルできなかったからだ。

それに今どき、Golangでお気楽に逝きたい。

C++とか、もうないわーと思うし！

JSONを食わせると、１バイトずつ判定しつつ、JSONのキーやバリュー配列なんかを考慮し、フォルダに展開する。

展開結果は図の通り

３枚の画像が入り合計１M程度のJSONだが、WSLで動かして７００ｍSecから２秒程度でインサートできる感じ

WSLが遅すぎるんじゃなかろうか・・・

さっきWindowsUpdateする前は、７００ｍSecだったのに、今アップデート後にもう一度やってみたら、めちゃ遅いんですけど、倍から３倍くらいかかるようになったんですけど？

どういこっちゃ・・・

あとで、ラズパイで環境作ってやって見ようと思う

んで、やってみた。

golang 1.17をRaspberryPi4に入れてやってみたんだが・・・

５秒から７秒弱かかる。

こりゃやばいなぁ・・・なんでこんなに遅いんだろう？

SDカードだから？

 HDD付けてそっちに書いてみるか？

いや、でも、SDカードは読み書き１００MB/Sくらいはあるはずだ。

たかだが、数百キロのファイルを書き込むのにこんなにかかるわけがない。

もしかして、ファイルアクセスは遅いのか？

なので、データベースは仮想ファイルシステムを使っているのか？

よくわからんす・・・

そこら調べてみるっす

ベンチ調べたらファイルのReadで時間がかかってた。

一度os.ReadFileしてから、bytes.NewReaderでio.Readerにしたら0.226sで終わった。

なんじゃこりゃ・・・

ファイルから１バイトずつ読むと遅いのか・・・

まぁ一度に書き込んだ方が早いわなそりゃ

昔そんなコピーツールがあったっけ・・・

いずれにしろ、テストコード側の問題だったので、ネットワークから渡ってくる文字は全部読んでから処理する方針だし（早くRead終わりたいからね）本体側プログラムいには問題が無いと思われる。

Zesty Nimble V3(Flex)

ZestyNimbleV3(Flex)を購入しました。

部品はこの通り、かなり少ないです。

しかし、ここで問題が！

なんとV3のマニュアルがありません！

しかたないので、勘で組み立てていきます。

この部品はここに入りそうです。

入りました。

結構きついです。

おそらくここにベアリングが必要なはず

んで、ここに入れるんだろうなぁ

グリスも必要だなぁ？

うん、ベアリングもしっかり収まりました。

こっちから見ると、ベアリングが効いているのがわかります。

あとは動力を伝えるウォームギアがここに入るはず

なるほど、ここをフィラメントが通るんですね？

こんなんでしっかり押さえられるんだろうか？

ん？？ちょっとまて、ウォームギアの蓋を付けようと思ったけど、

これ、ベアリング要るよな？

うん、絶対にベアリングが必要。

多分これで合ってる。

これで組みつけちゃおう

これがフィラメントの抑えの部品。

おそらくここにフィラメントを抑えるベアリングが入る。

シャフトで組み付けるんだと思うけど、シャフトが固くてベアリングに通らない。

ハンマーで叩き込もうかと思ったけど、

こんな３Dプリントしたパーツ、ハンマーで割れたらシャレにならない。

仕方ないので、シャフトを紙ヤスリで少し磨く。

シャフトはおそらくアルミシャフトなので、簡単にやすり掛けできる。

あまりやりすぎるとすぐにスカスカになるだろう。

手加減が必要だ。

うん、入った。

かなり手加減したつもりだけど、

もしかしたら、バリかなんかで入りづらくなってただけなのかもしれない。

わりとゆるゆるになってしまった。

本体側に抑えの部品を組みつけたところ、

多少ゆるくても、外れはしない作りになってる。

これでOKとしよう。

ここで前もって刷っておいたV2用マウントを合わせてみた。

全然合わねー

仕方ないので、自分でデザインし直す。

ノギスで測って、位置合わせだ。

気を取り直して、ここまでの動作確認をする。

フィラメントを通して、くるくる軸をまわしてみる。

緑のフィラメントが出てくる。

うんうん、よさげ

デザインしようという気力を補充で来たので、OnShapeを使ってマウントをデザインする。

こんな感じだろうか？

あと、ここはグリスが必要だろう。

付属のグリスを塗っておく。

いよいよ本体に取り付けるのだが、どうも、動力を伝えるケーブル抑えが容易に外れてしまう。

しかたないので、ホットボンドで固めることにする。

下部の白いパーツはPrecisionPiezoOrionのマウント

一回これをを外して、上部の今回作ったマウントを介して、

V3をくっつける。

途中でPTFEケーブルが少し必要なのが分かって、ノギスで測って差し込んだ。

動作中の様子

やったよ、動いたよ

ファームのパラメータ設定は、ZestyNimbleV3(Flex)の説明に譲る。

なんと今はマニュアルがある！

自分はさっぱりわからなかったので、フィラメントに５ｃｍごとに印をつけて、

実際に押し出して測って調整した。

あとでマニュアル見たら全く同じだったので、

先にマニュアル公開してくれよーと思った。

アクセラレータの設定などは後からマニュアルの通りに直した。

まぁ、このあたりは、またあとで変えるかもしれない。

まとめ

マウントが無いし、ドキュメントも無いし、勘だけで組み付けたわりにはちゃんと動いてくれた。

今回デザインしたマウントはZestyTechnologyにメールしたところ、

紹介してくれることになった。

同じものはこちらにも公開済み

うちはデルタ型なので、エフェクターが重いとゴーストが出まくる。

今までクソ重いモーターと、クソ重いエクストルーダが付いていたので、

キャリブレーションキューブでさえゴーストだらけだったのだ。

今回Zesty Nimble V3（Flex）を使って、

エフェクターからモータとエクストルーダの重量が消えた。

ゴーストもきれいさっぱり消えてくれた。

デルタ型プリンタのユーザーは、一考するべき選択しだと思う。

JSONのフォルダ構造への変換

 node.jsにjsondirというのがあったので試した。

https://stackoverflow.com/questions/28256945/creating-a-folder-structure-from-definitions-on-a-json-file

var jsondir = require('jsondir');

jsondir.json2dir({

    "-path": 'dir',

    "myfile": {

        "-content": 'Hello world!'

    },

    "mydir": {

        "a": {

            "b": {

                "c": {

                    "-type": 'd'

                }

            }

        },

        "1": {

            "2": {

                "3": {}

            }

        }

    }

}, function(err) {

    if (err) throw err;

});

jsondirTest$ tree dir

dir

├── mydir

│   ├── 1

│   │   └── 2

│   │       └── 3

│   └── a

│       └── b

│           └── c

└── myfile

6 directories, 2 files

うん！

これ、全然使えないね？

例も酷いけど、結果も酷いんで、これは参考にしかならないとして諦めます。

それと、日本語入れたら動かなかったよ

まぢ使えない

まず、｛｝はフォルダにするべき

３がファイルになってるのはどういうポリシーだ？

ｄが消えてる

ｃフォルダの下にuuidフォルダ作って中に、"-type":"d"って書くべきだろ？

アルゴリズムにポリシーが無いので、バグってるようなもんだわ

誰にもメンテされずに消えるわけですね

発掘する価値も無かった

Golangのプラグインに関する考察

プラグインとして Go から外部スクリプトを実行するのが、

遅くて仕方ないのではないかと思えてきた。

https://github.com/d5/tengo

Go Nativeは、やはり早い

Pythonはまぁ遅いほうだわな（PerlやRubyよりは早いと思うが）

Ottoがめちゃくちゃ遅い

で、tengoが早いかと言うと、Go Nativeよりは比較にならないくらい遅い

ということで、SOファイル作って呼び出す形にした方が良さげだ

Linux系しか動かない作りになるが、まぁ別に問題ないだろ

気になったのでフィボナッチでベンチマークを探してみた。

https://ma-tech.centurysys.jp/doku.php?id=mae3xx_tips:test_fib_benchmark:start

Nimはえーな、まぢかよこれ

フィボナッチのベンチマークをもっと探してみた

https://github.com/drujensen/fib

おや？Nim遅くなってんぞ？

Pascal早いな

え、Haskellどうなってんのこれ？

ASMより早いんだけど？

え、Golang遅いな

まぁ、大体こんなもんだろうな・・・

アセンブラをガリガリ書いて、

ゲームのVSyncやHSync割り込みで動くようなものを作っていた身としては、

外部スクリプトなんか使いたくねぇなって気分になってきた。

GolangとJavaScript

GolangからJavaScriptを呼んで、JavaScriptからGolangの関数を呼ぶってことが出来るらしい

Ottoというパッケージがあって、EcmaScript5までらしいんだけど、

JSONをJavaScriptで扱ったり、Golang側に返したりするのもできる。

↓JavaScriptからGolang関数の呼び出し部はやってないけど一応の例

https://play.golang.org/p/KY8d9OsaA-q

golang BuntDB まぢすげーわ

 これすげーよ

JSONとか入れられるし、インデックス作れるし、キーで取得できるし、mongoDBよりいいんじゃねぇ？

俺が作ろうとした機能が全部ある

というかなんでみんなこれ使わないの？

https://pkg.go.dev/github.com/tidwall/buntdb

これとGoで作られてるJavaScript

https://pkg.go.dev/syscall/js

それと定番のnet/http

https://pkg.go.dev/net/http

これらを組み合わせたらバックエンドサーバ立てて、

受け取ったJSONをJSのJavaScriptに投げ、

JavaScriptからクエリを処理するGolang関数を呼び出し、

結果をJavaScript側で受け取って、Golangサーバに戻し、

Golangサーバからフロントに戻すプログラムが作れるよね

つまり、MEAN的なものが、上記組み合わせでつくれるわけっすよね？

まぁ俺、AngularJS嫌いなんで、

フロントは普通にJQueryでいいんじゃね？と思うけどね？

てか、V8が早いって言ってもgolangのJSのが早いよ

それとNode.jsごときでサーバ作るくらいならGolangのサーバのが早い

桁違うほど早いと思うよ