https://github.com/cho45/Chemrtron

機能

  • インデックス用のクローラ
  • 作ったインデックスのインクリメンタル検索と表示

できるだけ雑にインデックス作成用のクローラを実装できるようにしたかったので、そのようになっている。

オフライン閲覧はあんまり考慮してないが、file:// でインデックス登録すればオフラインでも使えると思う (ネットワークよりもディスクサイズのほうが厳しいのでオフラインにあまり興味がない…)

動かしかた

レポジトリをクローンする場合 electron-prebuilt が必要。

npm -g install electron-prebuilt
git clone https://github.com/cho45/Chemrtron.git
cd Chemrtron
electron .

または https://github.com/cho45/Chemrtron/releases のページから .dmg を落としてくる。うまく動くかわからないが、こちらはランタイムを全て含むので electron-prebuilt や npm などは不要。

インデクサの選択

歯車アイコンまたはメニューの Preferences… から設定画面を開くと選択できる。

まだ並べかえを実装していないので、オンにした順に並ぶ。

インデクサの実装

マニュアル単位でインデクサを実装する必要がある。主要なものは実装済みでレポジトリに入れてあるが不完全かもしれない。対応済みの一覧

だいたいの場合 HTML で全メソッド/クラスへのリンクが張ってあるページがマニュアルに存在しているので、そのページをとってきて querySelectorAll とかで雑にリンク抽出すれば十分なインデックスをつくれる。

インデクサのコードは非表示の別ウィンドウで実行されるので、ある程度重い処理でブロックしても問題ない。

インデックスの内容

インデックスといっても転置インデックスではなく、検索対象文字列の一覧を正規表現でマッチをかけているだけである。

リファレンスマニュアルのようなものの検索の場合フルテキストサーチよりも、ある程度一貫性のある文字列を検索させたほうが余計なものがヒットしないので気持ちがいいと思う。

例えば Array.prototype.slice みたいなページを表示したいとき、arr sli とかだけでいいようにしたい。既に行きたいページが明確なので雑なクエリで確実に辿りつきたい。

インデクサの書きかた

https://github.com/cho45/Chemrtron/blob/master/indexers/nodejs.js

あたりを参考にして雑に書くと動く。もし動かない場合、View → Toggle Developer Tools とするか、設定から Developer Mode をオンにすると console と、インデクサ用のウィンドウが表示させるのでデバッグ可能になる。

~/.chemr/indexers/ に置いても読むようになっている。

おすすめのインデックス

MDN (Mozilla Developer Network) は HTML, CSS, JavaScript を横断して検索でき、ブラウザごとの互換情報とか、ポリフィル方法 (実装概略) とかも載っていて、とりあえずウェブ系ならこれを検索しとけば良い感じで便利。

で、Dash で良くない?

クローラを内蔵していて、雑にインデックスを作るのが楽という方向性を目指しています。

今後

せっかくなので Windows 版を作ろうとしたがうまくいってない。

バックグラウンドで自動更新するようにしたい。

経緯

昔 Chemr というリファレンスマニュアルをインクリメンタルサーチするアプリケーションを書いていた。最初の Chemr は HTML Help を読め RubyCocoa で実装していた。次はFirefox + Greasemonkey 上で動くユーザスクリプトとして実装した。そして Electron が流行ってきたので Electron 上で動くように実装しなおした。

  1. トップ
  2. tech
  3. リファレンスマニュアルをインクリメンタル検索するやつを Electron で実装した

なんとなく行きたくなったので、諏訪大社にいってきた。諏訪大社は2社4宮に分かれて点在していて、それぞれが結構離れている。上社と下社は電車で、ほかは徒歩で移動したがかなり疲れた。

上社 前宮






道中

上社 本宮




下社 秋宮




道中

かなり高低差がある。この神社は上から見たのみで行かず

春宮と秋宮で建築技術を競ったらしいので名残りかな?



下社 春宮



  1. トップ
  2. photo
  3. 諏訪大社

諏訪大社に続き、仁科神明宮にも行ってきた。諏訪からは同じ長野県内ではあるがかなり離れており、駅からも30分ぐらい歩く。

現存する神明造社殿では最古で、本殿が国宝に指定されている。

神社はどの神社も式年遷宮で造りなおされる傾向があり古いものがそのまま残っているケースが少ない。この神社も300年前までは建て替えをしていたみたいだけど、その後は修繕をやって残っているらしい。

ちなみに神明造りに限らなければ、現存最古の神社は京都の宇治上神社で、こちらも国宝になっている (なおかつ京都の世界遺産を構成する1つ)。宇治上神社は5年前に行った











  1. トップ
  2. photo
  3. 仁科神明宮

WebGL があるからね。ブラウザが業を背負ってくれるのだよ。

https://github.com/cho45/go-KX3-panadapter

KX3 (無線機) 用の panadapter (広域スペクトラムスコープ) の実装を WebGL でレンダリングするように変えた。

経緯

これまで go-gl を使って頑張っていたが、いつのまにか go-gl の構成が変更され、ビルドができなくなってしまった。

go には依存パッケージのバージョン指定を行う方法がないので (ないよね?) 最新に追従する以外の選択がないのだが、いきなりビルドが通らなくなるみたいな事態がおこるともうやる気がしない。

継続的にメンテするほどの変更は入れてないが「ときどき実用しているアプリケーション」が割とどうでもいい理由で壊れるととにかくやる気が失せる。なので、できるだけ壊れなそうなものに依存するようにしたい。

その点ウェブ技術に依存しておけば、あまりひどい非互換は入らないことが期待できるし、最悪壊れてもググれば非互換情報が見つかりやすく、対処しやすい。そしてそもそも JS で書くのでビルドできないような事態にはならない。

構成の変更

前のバージョンでは go-gl を使い、go で書いたプロセスで直接ウィンドウを作ってレンダリングしていたが、構成の変更により、go で書く部分は portaudio を使って任意のサンプリング周波数で信号のFFTを行い、WebSocket からストリームで投げ続けるというシンプルな動作を行うようになった。(44.1kHz 固定なら WebAudio + WebWorker でできそうだが、すくなくとも 96kHz サンプリングはしたいので WebAudio はつかってない)

ブラウザ側のJavaScriptでgoプロセスへ WebSocket の接続を行い、データを受信し次第 WebGL を使ってレンダリングを行う。

これにより go の部分の cgo 依存は portaudio のみになった。portaudio は非常に薄いラッパーなので将来非互換が入るような余地がほぼないと思われる。安心

備考

別に go に限ったはなしではなく、ビルドができるできないとか依存がどうとか、とにかくダルイ。やらなくてすむことはやらないようにしよう。

  1. トップ
  2. tech
  3. もう僕らは OpenGL ライブラリにリンクするビルドに悩むことはない