t_wの輪郭

　手書きできる画像アップローダーみたいなのを考えてるんだけど、考えることが多い。DBどうしようとか、利用者登録管理どうしようとか。

　ナウでヤングなやり方を考えるなら、クラウドでマイクロサービスでウェイするのがいいんだけど、それするとお金がドバドバ出ていく。

　VultrのVPCでDockerを動かしてマイクロサービスやーってやったら安くつきそうな気がする。

　そう考えると、『t_wの輪郭』のシステムもDocker上で動かしたくなる。

　やることが……やることが多い……！！

　ブログシステムのDocker化、ベンダーに頼むと2人月とか取られるやつじゃんね。規模によるけど。4万ページあるし、ブログ移行としては超大規模案件では？ページ数でみるとやたらデカいけど、システム的にはDBとNode.jsだからそんなにか。

　問題は作業者（t_w）にDockerの知識があんまりないってことなんだよな。『t_wの輪郭』のDocker化で知識をためつつ、手書き共有ウェブアプリ（仮） EGAKUの準備を進めるという形が綺麗か。

　Docker使うと依存する技術が増えて面倒じゃんというのもある。

knownetにかかずらってないで、そろそろTwEgakuをやらねば。

knownetはデライトの模倣なので、デライトの発展を見守れば良い。同じ山を登る必要はない。

かたやTwEgakuは私がやらないと何も進まない。「UTF-8のようなお仕着せの記号から書き手・人工言語勢を開放する」「手書きのインターネットを創る」とか考えてるの私ぐらいだろうし。

　クラウドでマイクロサービスでウェイをより具体的にどう考えているかを言うと、DBのマネージドサービスでDBインスタンスをサービスごとに立ててやるみたいなのを考えてます。

　趣味で触ったとき、DBのマネージドサービスが高くついた記憶。今どうなってるんだろう。かつてAWS RDSでグエエしましたわよ。つっても月額1万円はいかなかったのだけれど。

　前の現場のXXXにいたときは全部マネージドでウェイして、サーバーレスで、情報セキュリティ部のチェックシート無視できてやった～！とかしてたけど、客の金でできるからやってただけで金のない趣味プロダクトではできん。

OGPを通して画像を要求された際に、
■ 手書きデータ→SVG→ブラウザのCanvasに描画→スクショ→PNGとして返す
っていう処理になってたのを、
■ 手書きデータ→ブラウザのCanvasに描画→スクショ→PNGとして返す
っていう処理に書き換えた

そもそもなんでブラウザやねんとなっており、
■ 手書きデータ→PNG
にしたい

現状だとサーバーでChromiumを起動するpuppeteerが走っており、これが大変遅い。起動やらなんやらするだけで1秒かかる。画面遷移に時間がかかってる説があるのでその辺の高速化がいりそう。

いつか世界一の手書きノートアプリをつくっちゃるけんのう！

そのために大学の研究室に潜り込んでおる。

誤差逆伝播法の導出を書くにあたって、理解を容易ならしめるために作図してウェイウェイしたいけど、作図してウェイウェイできる手段をどうしよう。

手書きで見苦しくなるけど、TwEgakuが最適か。

ちょっとやってみたけど、手書きめんどいな。SVGのホスティング機能を備えたまともな作図サービスが要るな。
TwEgakuを拡張するのが良さそうな予感だけど、なんかあれなんだよな。

iPad mini 6代がペイしたら、Macを買ってネイティブアプリを作りたい。

なお収益の見込みはまだない模様。