エスペラントto日本語の単語変換をします。とりあえずエスペラントの単語を引くことができます。
名前はlina_dictoです。
https://github.com/MichinariNukazawa/lina_dicto
なおエスペラント辞書データですが、すばらしい辞書データ が公開されており、これを使っています。
感謝。
ダウンロードはこちら。
https://github.com/MichinariNukazawa/lina_dicto/releases
本記事では辞書アプリ固有の話はしません。なぜなら今は2017年であり、辞書データをすべてメモリに置き、かつ動的言語を使って辞書データを頭から尻尾まで舐めるという超富豪コーディングをしても、ユーザ体験をまったく損ねず遅延もまったく体感しない辞書アプリケーションが作れるからです。IntelとJavaScriptエンジンのエンジニアには足を向けて寝られません。
事前に検索インデクスくらいは作る必要があるだろうと想像していたので、正直、拍子抜けの気持ちが無いといえば嘘になります。
# エスペラント固有の話
先にエスペラント固有の話をします。固有の話は２つあります。## 語根分かち書き
語根とは、語尾の変化による現在形への変換などをされる前の単語です。詳しくはWikipedia。特にエスペラントは、語根を組み合わせて単語を作ることで、話者の記憶リソースへの負担を軽減する設計になっています。エスペラントは語根がはっきり定義されており、なぜなら人工言語であり、そういう設計だからなのですが、単語が複数の語根から成る場合がかなりあります。詳しくはWikって略すな。
今回使用した辞書データには、単語が語根分かち書き形式で収録されています。この分割部データもいずれは有効に使いたい所存ですが、検索時は、普通のユーザがタイプするであろう分かち書きされていない単語文字列と、分かち書き済み単語データをマッチングしなければなりません。
なので、分かち書きは単純に取り除きます。
上で、動的言語で文字列のマッチング・ループなんて...って書いてありますが、実際にはもっとひどいことをしています。具体的には、分かち書き状態の単語文字列を、正規表現置換によって分かち書き除去を行っています。
(さらに踏み込むなら、大文字/小文字マッチのためのlowarCase()等、CPUリソースを暴虐無人に使っています。)
せめて起動時の、辞書データファイル読み込み・オンメモリ辞書データ生成の際にキャッシュを作っておけよという感じですが、キャッシュ管理はコードが複雑化するので避けたいというプログラマの怠惰な方針を今のところ支持しています。だって実際に問題ない速度が出てしまっていますし...。
## 代用表記
エスペラントが使用する文字には、ASCIIアルファベット以外の文字が含まれています。具体的には下記のやつです。
``` Ĉ ĉ Ĝ ĝ Ĥ ĥ Ĵ ĵ Ŝ ŝ Ŭ ŭ Ŭ ŭ ```
現代的ブラウザなら、UTF-8かつ対応フォントで上記文字列が問題なく表示されます。
代用表記には4種類くらいあり、ぶっちゃけ初学者には"^-sistemo"(typoではない)以外はピンと来ません。ついでに言うと、他の代用表記は実装が難しいのでやりたくありません。
特に元祖本家のH-sistemoの変換ルールが最悪です。これってつまり代用表記か否かの判定に辞書が必要じゃねえかと。エスペラントはunicodeどころかコンピュータが影もカタチも存在しない時代の設計だから仕方がないねというところです。
で、^-sistemoの実装ですが、 下記のコード。
```
str = str.replace(/C\^/g,"\u0108");
```
こういうのが12個くらい、ハードコートされて並んでいます。組み込みエンジニアは卒倒して良いと思う。
もし複数のsistemoj(?)に対応することになったら、その時ついでに書き直します。
# electronアプリの話
エスペラントに興味があって読んでくださった方は、ここから先はelectronという退屈な実装技術の話しかしないのでこの下は読まなくてよいです。実装技術に対する初心者の泥臭いトライアンドエラーで脳内物質が出てくる系の方はこんにちわ。エスペラント富豪コーディングの話は楽しんでくれましたか。なおインストールからサンプルアプリ動作までの前半戦はこちら。
https://srad.jp/~m_nukazawa/journal/614745/
## リリースパッケージディレクトリの展開先について
リリースに使っている設定JSONファイルに書いた書き出し先パスがひとつ上になっているだけでした。そして、実はもっと深刻な問題を持っています。設定しないと、electron-releasesはリリースディレクトリを、プロジェクトのroot的なソースパスに展開します。
そして、このディレクトリに置かれたファイルは、基本的にすべてがリリースに含まれます。
なので何も考えずに
```
node_modules/.bin/electron-packager . lina_dicto --platform=all --arch=x64
```
とかやると、初回はともかく、2回目以降はすべてのプラットフォームのリリースディレクトリ(バイナリとelectron付属物)がすべてのプラットフォームのリリースに含まれるというマトリョーシカを作ってしまいます。(私は途中で圧縮が長すぎるのに気づいてkillした)
ここらへん、本当はjavascriptのトランスパイラとかMakefileオルタネイティヴスが呼び出して使う想定で単純な作りになっていて、直接使うことはあまり考えてないとかじゃないかなぁと妄想をたくましくする次第ですが、ともかくelectron初心者なので複雑なことはしたくない一心、jQueryすら使っていないこの単純プロジェクトにそんなものを入れたくはないので、成果物はとりあえずwin版だけzipできればいいやの精神で、vecterion_vgeの成果を転用したbashスクリプトをビルド&パッケージングスクリプトとして採用した次第です。
## MacOSXビルドについて
electronのバイナリ配布物、ようは『electron共通ブラウザコア(プラットフォーム固有) + Webページ的なもの(プラットフォーム非依存)』のセットでしかないので、インターネットから降ってきたプリコンパイル済みコアさえあればxcodeが無くともLinuxであってもOSXのバイナリ配布物が用意できるという理屈は納得できるのですが、それはそれとして起動するかどうかくらいは確認しないとリリースはしたくないので、動作検証してくださる方を募集しております。エスペラント辞書アプリケーション、MacOSX版が欲しい方は、動作確認をしていただける方を募集しておりますのでご連絡ください。— Michinari Nukazawa (@MNukazawa) 2017年9月4日
(electronはMac用バイナリを吐き出すのだが、Macが無いので動作検証できない)#エスペラント
## (ブラウザの)開発者モードON/OFFについて
一応、開発者モードをユーザがONにできてしまうことについては悩んではいます。 ユーザはOFFにできないからアプリを落としてもらうしか無いなー、という程度ですが。オープンソースだから中身を見られてもOKということで、私はデバッグモードが開ける状態でリリースしています。リリース候補のデバッグも楽です。問題無ければデバッグモードを殺す手間無しに、そのままリリースできるからです。
デバッグビルド/リリースビルドで開発者モード有効フラグを切り替えると上記の手間が発生してしまいます。
隠れショートカットで開発者モードを出せる、という方法は、万が一にユーザが隠しショーカットを押してしまったらシッチャカメッチャカになるのが目に見えています。
## Windows版インストーラについて
本当はLinux上でWindows版インストーラが作りたいのですが、必須機能ではありませんし、できるかどうか調べることもせず、vecterionで使っているスクリプトを改造して配布用zipを作りました。# まとめ
エスペラントについて。すばらしい辞書データ を公開してくださっていることに感謝。
Electronについて。
Webで何かやったことのある人がPCアプリケーションを作る羽目に陥ったなら、electronは良いと思います。なにしろWebKitブラウザなので、ハマった時にWeb上にQAや対処法がたくさんあります。
少なくとも私は3日程度でクロスプラットフォームPC辞書アプリが構築できたので、electronすごく良かったです。
以上です。
