手書き漢字読み取りを作った

手書きで漢字の読み取り練習をするアプリを作りました。

手書き漢字読み取り

漢字の学習はいくつかのレベルに分かれることに気付きます。 (1) シンプルな反復の練習、(2) 文字を綺麗に書く練習、(3) 考える練習です。 1 である程度覚えた上で 2, 3 に取り組まないと効率が悪い気がしますが、 私の作ったアプリは 1がやや弱い気がしました。 タッチ漢字ドリル はカリキュラムとしては使えるのですが、やや手軽さが不足します。

カリキュラムより反復練習

多言語学習について目を向けると、漢字圏以外では 2 が存在しないことが多く、 よりシンプルな反復練習が大切になります。 反復練習せずできる子もいるけど、できない子のほうが当然多いし、反復練習しないが故にできなくなる子のほうが圧倒的に多い訳です。 どんな言語でも 1 をサクサクと反復練習できる基盤が大切だし、ほしいと思いました。

今回のアプリを作るに当たって閃きがあったのは、やる気が出ない問題への対処です。 子供に限らず私のようにやる気のない大人にも言えることは、 カリキュラムの存在はやる気をなくす原因になる事実だと思います。 教える側としてはカリキュラムがあると何も考えなくていいので非常に楽ですが、 やる気がない側から見るとそびえ立つクソにしか見えず、逆効果になりがちです。

勉強が苦手な子ほどやる気の問題があることも多いので、やる気とは別に量をこなす仕組みが必要です。 散発的にでも反復していれば多少は覚えられるので、そのようなアプリにしました。 色々と UI を考えましたが、結局は 英単語クイズ、Tegaki Phonics、Tegaki ABC の漢字版みたいなところに落ち着きました。 意外と UI が難しいんだよなあ。

日々の練習アプリとして良さそう

手書き読み取り漢字は習っていない漢字を学びながら練習するアプリとして考えていて、 1日3分間くらい練習するのに良さそうと思っています。 ある程度は頻度を考慮しているので、さほど効率も悪くはないです。 テスト代わりとしても使えそうですが、全員ランダムな出題となるので好みは分かれそうです。

認識精度も良く、手書きはタブレットならまあまあ使いやすいけど、スマホで扱いにくいのが課題でしょうか。 最近の子はみんなタブレットを持っているので気にするほどではないかも知れないですが、スマホ用にも何種類か他の UI を作る予定です。

Node と Deno と Bun

Node/Deno の代替として、Bun という高速な JavaScript 処理系が出てきました。どう見ても肉まん。 超期待ですが、Bun のプロダクト利用は、ドキュメントもないのでまだまだ無理そう。 あと Deno も進化しているので、Deno が疾くなるのと Bun の仕様とドキュメントが整備されるのでは、 どちらが早いかは微妙なところです。

Bun は実行速度が確かに疾そうで、3倍くらい疾い可能性はあるけど、いま表に出ているベンチマークでは比較に使いづらいところも色々ありそうです。 というか 3倍疾いと C/C++ の速度に匹敵するような…？ HTTP Server はわからない部分も多々ありますが、 Deno の FFI と SQlite は遅いのがわかっているから、ベンチマークをそのまま鵜呑みにはしにくいです。 ただ Deno も Bun という良きライバルが登場したことで成長しようとしています。 たとえば FFI の高速化を検討し始めました。

• https://github.com/denoland/deno/pull/15006

deno-sqlite が遅い理由は前からわかってて、 API とサンドボックスの制限で WAL が利用できないから。 つまり Bun のベンチマークはサンドボックスなしの利点を考慮しないといけないし、 Deno もサンドボックスの欠点にはもっと議論が必要であるとわかります。 他にも利点欠点が better-sqlite3 のページに結構詳しく書かれています。 確かに高速性を追求するとメモリやディスクの共有は必要になりがちなので、 高速化領域ではこのような話が問題になりやすそうで、Deno の弱点かも知れません。

• https://github.com/WiseLibs/better-sqlite3

こちらの議論も活発化してきて、ブラウザの File System Access API を利用したり、 FFI 経由での高速化を目指すなどの話が上がっています (下)。 File System Access API でできるなら一番綺麗そうな気はするけど、Firefox が拒否しているからあまり進まなそうです。 DB や HTTP Server、その他でも高速が必要となると、read/write の多重化はたいてい必要になりそうで、 その結果セキュリティがどうなるかまでは考えてないけど、 言われてみれば確かにサンドボックスの拡張ができると嬉しいかも知れません。

• https://github.com/denoland/deno/issues/11657

ただ FFI をベースにした async-sqlite3 のベンチマークを見ていると、FFI が一番有望なのかもと感じます。 FFI が速くなればたいていの問題は解決しそうです。

• https://github.com/denodrivers/async-sqlite3

あとこの結果を見ていると、言語として Python より早くても、read/write を経由すると遅くなる側面も見て取れます。 大規模な read/write に弱い、JavaScript (Node/Deno?) 特有の課題を感じますね。 やっぱり FFI の高速化は Node / Deno の責務なんじゃないかなあ。 その意味では Bun の目の付け所は上手いかも。

ここまでの話をまとめると、Bun が疾い話には Deno の制約の話が数多く含まれています。 Bun はそこをセルフ実装のパワーで解決しようとしており、 Node/Deno は互換性やセキュリティを大切に解決しようとしています。 Deno の進化も Bun の進化も、どちらもまだまだの状態なので、どちらも生暖かく応援しようという感じ。 プログラミング言語を作るのって難しいんだなあと、改めて思いました。

個人的には Deno と Node と Bun の関係は、Java と Scala のような関係とは異なると思っています。 基本的な根っこは同じで、また応用部分も ESM で相互運用可能になるはずで、長期的にはどれで書いてもそんなに困らないはずです。 そんな時に大事なのはシンプルさと速度ですから、Deno と Bun には注目です。

追記: 書き終わった後に似たようなことが公式でも書かれていることに気付きました。oh... 何にしても Deno も Bun もこれからですね。

• Why is Deno that slow?