雑記(50)プログラミング(29)ハードウェア(16)伺か(12)ツール等(10)漫画読み(43)漫画描き(19)アニメ感想・考察(24)鉄道(2)ネットの諸々(10)インフォメーション(8)未分類(0)現在は実質目黒東部のなにかプロフィールAuthor:奈良阪某プログラム書いたり絵を描いたり鉄道に乗ったりしています。12:05元旦に思い立って表題の通りにする過程で色々調べたメモ。イカガカプロジェクト用)を書いてたので、CI謎テストこけを直しついでに今風に刷新することにした。できるだけデフォルトに沿い極力設定を書かない方針でいった。個人的にあんま使わないのでwatch系はなし。本体コードコードは全部TypeScriptで、babelは使わずtscとwebpackだけでES2015とES5(IE用)にトランスパイルする基本構成に。tsconfig.jsonとwebpack.config.js・webpack.config.es5.jsのみでこれはいける。tsconfigにtargetがes5になってもes2015のライブラリは使えることを示すために"lib"を記述しておくところと、webpackで使う時に型定義出力先となるoutDirを変えているところがポイント。ここでは使っていないがJSXもtsconfigに書けば基本babel不要でいけるので、インストール量を減らしてゆこう。mochaで取れるように構成する。ココにはまりポイントがある。test/*.tsと書いても、カバレッジの%は出るのになぜかlcovやhtml出力にエラーが吐かれることになる。これはespower-typescriptのissueに上げられており、tsconfig.jsonにsourceRootを指定することで解消する。これを指定すると今度はtypedocのほうがsourceRoot指定するなとエラーを吐いてくるのでめんどくさい。こちらもtypedocのissueに回避方法が載ってはいるが無理矢理過ぎるので、現状は仕方なくtypedocを実行するときだけ手動で外すかなと思っている。(回数は多くないし)とりあえずここまででnode.js上でTS+mocha+power-assertをカバレッジ付きで開発できる。ブラウザ実働テスト必要ない場合はこれで終わって良い。Karma次にブラウザでのテストだが、単体テストだけすれば良い感じのライブラリなのでKarmaを使う。フレームワークはmocha。karma-webpackでTSトランスパイルからバンドルまで行い、karma-sourcemap-loaderでカバレッジ用にソースマップを受け流し、karma-espower-preprocessorでespowerしてからテストする。カバレッジレポートはkarma-coverageを使う。karma-coverageはカバレッジ集計も担う機能があるが、今回Webpackを使う関係でそれは使えない(Webpackだとkarma.confのfilesにテストファイルのみ指定するので、カバレッジ集計対象がそこから取れないためっぽい)。webpack.config.test.jsを作ってwebpackの時点で集計を食わせることで動作させる。espowerもwebpackの時点で食わせる方法があるが、webpack1時代にそれでハマったことがあり、今回試していない。そっちでも普通に出来るかもしれない。ちなみにIEだけES5で食わせる必要があるのでkarma.conf.es5.jsを作って別立てでもう一回karmaを走らせている(webpack設定を読むときの副作用でes5設定にする雑な感じ)。ここでのハマりポイントは"mime"プロパティの指定。IE以外のブラウザではこの指定が無いと.tsファイルがブラウザにスクリプトとして解釈されず、テストケース自体が0という表示になって何事も無く終了するのでたちが悪い。「この設定でIEでは正しく動いているの」という心のよりどころのおかげでハマり時間が少なくてよかった。angularのissueなどに解があった。karma-detect-browsersは古くから愛用しており、launcher系さえ入れておけばいい感じにブラウザを立ててくれる(WindowsならIEとEdge、MacならSafariも走る)。カスタマイズでIEのみを省いたり、自動検出スキップできるようにしたり、Chromeをせっかくだからheadlessにしたりしている。PhantomJSとはおさらば。AppVeyor・Travisここでブラウザを使うことで若干ややこしくなるのがTravisの設定。test-winにしているくらい。FirefoxもChromeも入っているし普通にGUI上で走るので目立った設定は不要だ。.travis.yml、まずLinuxでGUIアプリケーション(Firefox)を走らせるためにDISPLAY設定したりxvfbを立ち上げて立ち上がるまでてきとうにsleepするという設定が入っている。Testingの通り。Linux/Mac両方でFirefoxとChromeを使いたいためaddonsでインストールを指定する。Chromeの項のとおり。trustyも忘れずに。あとcodecovがカバレッジをWebで見られるようにしてくれるのでafter_successにそれを指定している。コンソールアプリケーションだけの時より多少複雑にはなるが、まあこれくらいはいいはず。昔と比べて大分シンプルに書けるようになった。ここまでで一般的なブラウザ(AppVeyorが未対応のEdgeを除く)をWindows/Linux/Mac環境のCIで走らせる設定まで完了した。一般的なライブラリならこのあたりで終わって良いかも。Electronこれがくせ者だった。KarmaでWebpackでブラウザ用にバンドルすればまあ動くのだが、テストしたいのはrequireを使うElecctronらしい利用法。karma-electron-launcherを試すがmochaが正しく読まれない。karma-electronがパスをゴニョるとかしてなんとかするらしいのでこちらを使うもWebpackでtargetをelectron-rendererにするとrequireを上書きする挙動と相性悪いらしく無限ループしてコールスタック使い切る。Webpackを使わない道として、(karma-typescriptはごてごてしていて訳が分からんので避ける形で)karma-typescript-preprocessorを使ってみるが、冒頭に差し込まれるexportsを参照するコードがアウト。requireだけのコードをfilesに指定してみるも、webpackを通していないのでrequire先のtsファイルが解決できずアウト。他色々試したが軒並みしんどいので、最終的にKarmaを使わずelectron-mochaを使う形でお茶を濁すことに。見た目シンプルだがnycと相性が悪いようで簡単にはカバレッジが取れないらしく(issueがあるが要領を得ない)、そこについては断念した。NW.js意外にもelectronより辛くなかった。launcherに望みを繋いだらなんとかなった。Webpackと連携する構成じゃないとまたexportsとかで死ぬので、とりあえずWebpackのターゲットをnode-webkitにするべくwebpack.config.test.nwjs.jsを作る。Karmaのランチャーはkarma-nwjs-launcherを使い、readmeに書かれているNWJSConfigエントリの内容を省略すること無く記述し、その内部で使っていながら依存関係に記述されてないcopyをインストールし、さらにmochaがロード時にエラーになるのをnode.jsのglobal変数を無理矢理待避させて回避するkarma-nodewebkit-mochaをkarma-mochaの代わりに噛ませて、karma.conf.nwjs.jsを作る。これで一応動作し、他のWebブラウザ同様普通にカバレッジまで出せるようになる。なんか全体的に危なっかしい感じだけれど、調べた限りおそらくこれが連携用の長大独自コードを書かずにコマンドラインベースでテストできる唯一の方法ではないかと思う。他あったらお知らせ下さい。scriptsに書く。表題とは直接関係ないが、クロスプラットフォーム開発のために便利なshxやcross-envを導入することでWindows上での開発も快適に。prepublishも書いておくとビルドし直しわすれが減る。mainはes2015コードを示し、typesも忘れずに。上記の通り設定ファイルが沢山出来るので、"files"によるポジティブリスト指定により配布ファイル量も少なくしておく。以上とりとめなかったですが、こんな感じで表題の通りの環境が作れます。昔に比べてTypeScript、Webpack、Karmaのバージョンもそれぞれ上がって周辺環境も洗練され、何点かのハマりポイントを回避すれば格段にシンプルに構築しやすくはなっています。それでは今年も良いTypeScriptライフを。22:50どうも、ツクールMVでゲーム制作中なワナビプログラマです。最近やってるTypeScriptでMVプラグイン作る作業が心地よいので共有しようかと思います。記事です)さて、ツクールMVの内部はJavaScriptで書かれています。これは動的型付言語のためコード補完が効きにくく、MVにロクなドキュメントがないことも相まって、プラグイン作るときに色々見て回るのが面倒という問題を抱えています。そこでTypeScriptです。TypeScriptはMicrosoftが出している「JavaScriptに便利な機能を載せたJavaScriptに変換可能な言語」(AltJS)です。Code(VSCode)というエディタによってかなり素晴らしいコード補完と型チェックが効く便利な開発環境を誇っています。このTypeScriptを導入し、コード補完の効くよりよい開発環境を作ることにします。PC上のコマンドラインでJavaScriptを動作させることが出来るコマンド)をインストールします。あたりを見てインストールして下さい。普通にインストーラーぽちぽちするだけです。typescriptを実行して下さい。これでnode.js環境にTypeScriptがインストールされます。--versionと出たらインストール成功です。npmはnode.jsに付属しているパッケージマネージャーで、TypeScript等の便利なパッケージを管理するものです。レジストリとかは特に触らず、node.jsをアンインストールすると一緒に後腐れ無く消えるので心配は要りません。Code、鬼に金棒とはこのこと。Codeのページにいって、普通にインストーラーをダウンロードしてインストールまでするだけです。コマンドラインとかは出てきません。インストールを普通にして適当なフォルダで右クリックすると、こういうメニューが出てくるはずです。TypeScriptでプラグインを書くでは書いていきましょう。ツクールのゲームでデバッグするのが多分楽なのでツクールのフォルダのわきでプラグインを作ることとします。CodeからVSCodeを立ち上げます。次に「表示」→「統合ターミナル」をクリックすると、こういう感じでコマンドラインが立ち上がると思います。ツクールMVの本体はJavaScriptで書かれていますが、外部からTypeScript式の型付を行うことで、型の恩恵を受けることが出来ます。その外部型付を導入するため以下のコマンドを実行して下さい。rpgmakermv_typescript_dtsなにやらnode_modulesというフォルダとpackage-lock.jsonというファイルが出来ると思います(後者は出来ないときもあります)。フォルダ内にa.ts(.tsの前は何でも良い)とかファイルを作ってこう書きましょう。types="rpgmakermv_typescript_dts"/>多分こんな感じになっているのではないかと思います。(左バー、下バー等、自分はエディタプラグイン入れてるので多少違うと思います)ではこの状態で、ファイルに$を打ち込むと......?おめでとうございます。補完が効くようになりました!というわけで楽にプラグインが記述できます。静的型付言語始めての方とかは若干型関係で詰まるかも知れませんが、調べれば割と出てくるのでかけるのではないかと思います。さあここからJavaScriptに変換する作業が必要です。上記コードはほぼJavaScriptのままで型が付いている状態(便利ですね!)なのでこのまま拡張子を変えるだけでもいいですが、時々TypeScriptの型記述をつけなければならないときが出てきます。tsconfig.jsonという名前で以下のような記述をします。}}そしてエディタの下にあるコマンドラインでtscとだけ書いて実行しましょうすると、dist/a.jsに変換されたJavaScriptができます。これをプラグインフォルダに入れるなり、あるいは"dist"のところを"js/plugins"にするなどすると、便利にプラグイン開発が出来ます。いうわけでTypeScriptプラグイン導入編、お疲れ様でした!TypeScriptを使うと補完以外にもまだまだnullチェックだとか非同期の記述方法だとかクラスの記述だとか、様々な先進的な機能を使えます。調べていってみて下さい。Intellisenseというのも存在する模様です。こちらは英文でコメントが付いているようなのでこれを導入するのも良いかも知れません。path="./rmmv-pixi.d.ts"/>としてください。("./rmmv-pixi.d.ts"は.tsファイルからダウンロードしたファイルを参照するパス)また上記型定義ファイルはhttps://github.com/Narazaka/rpgmakermv_typescript_dtsでコードを公開しているので、日本語コメントなどつけたい場合はプルリク下さい。複数ファイルの時の対処とまあここまで出来るだけ広く布教したい気持ちで初心者向け?な記事を慣れないながらも書きましたが、ここからは分かってる人向けです。TypeScriptで書く量が多くなってくるとファイル分けたいとかになってくると思います。この場合いくつか選択肢があります。自分がとっているのは最も単純に、コンパイル後にファイルを文字列結合してしまうやり方です。findとかxargsとかをunxutilsというツールで導入しているので楽にやってますが、まあ他のやり方でもできるはず。その他、そもそも動いているのがnw.js上なので、たぶんrequireが使えます。この場合普通にモジュールとして書けば良い気がします。webpackを使うという方法もあります。配布用にデカいものを書く場合は多分コレが一番良いのではないかと。targetにnode-webkitというのがあるのでそれを使えばいいんじゃないかと思われます。あとファイルをsrcとかサブフォルダに入れた方が管理はしやすいと思います。gitとか導入しても便利ですね。なんか時間が無くて雑な記述ですがご容赦下さい。他質問あればコメントにどうぞ。RPGツクールMVデータベースエディタを作りたい一昨日ふと思い立って作りはじめました。RPGツクールMVデータベースエディタRPGツクールMV、プラグインで拡張できるけど、エディタが拡張できないの片手落ちじゃない?と思って作りました。TPではない戦闘パラメーターや、「逃げる」以外の特殊効果、攻撃前タイミングで起こすアクションなど、プラグインで拡張したけどエディタでも編集できたら便利なものって結構あると思います。electron/react/mobx製のデスクトップアプリケーションです。上記で導入しているrpgmakermv_typescript_dtsは自分が昨日あたりリリースしたモジュールです。コミットログにあるように別の方が開発していたものがgithub消えてしまったので、手元にあったやつを復活させたという経緯があります(MIT的には問題ないはず)。Twitterで問い合わせても特に返答無かったのでそのまんま管理してますが、何か問題あれば言って下さい。18:56もう2017年も半ば過ぎ、ここらで停滞しているWebベースウェア「イカガカ」の要素技術について一旦軽くまとめてみようかと思います。17日目の枠に入るはずの記事でした(ぉイカガカは2014年末から2015年初頭にかけて精力的に開発していたですが、その後は仕事とかで忙しくなったのもありユーザーの目に見える進捗はありませんでした。現在は初期に手探りで作ったコードが色々とイケてなかったのを改めて書き直している感じです。イカガカはそもそも「デスクトップマスコットソフトウェア(伺か)をブラウザ上で実現する」というなかなかニッチなことをするソフトウェアです。Windowsデスクトップ用アプリケーションであるmateria.exeやssp.exe等に渡すのと全く同じnar(キャラクターデータ)をブラウザに放り込んでそのまんま動いている背後では、デスクトップ用のものとほとんど別の技術が動いています。その辺の技術やライブラリについてざっくりまとめることで、現状を伝えられたらと思います。技術・ライブラリの一覧まとめシェル描画系cuttleboneそもそもイカガカはシェル&バルーン描画ライブラリ「如何か」としてduxcaさんによって作られたのが最初です。その後自分が参入してベースウェア機能をつけたのを「イカガカ」と呼び始めたので、描画ライブラリは現在cuttleboneという名前になっています。APIとcanvasを使って同等の機能を実装しようとしています。基本的にクリック判定&レイヤー付き2次元アニメーションが出来ればいいのでまあ頑張ればおおかた再実装可能かとは思うんですが、アニメーションや着せ替えの仕様とかは複雑で大変そうです。canvasで主に非透過pngの色抜きとelementの合成を行い、その他レイヤー管理とかバルーンとかはDOMでやってるかんじです。助かった点としては、フォント指定(\f)の色指定や位置移動(\_l)の移動単位などSSP拡張さくらスクリプトのいくつかは、HTML/CSSでの指定と同じ種類のものを使っていて実装がしやすかったあたりがあります。一方でフォント描画方法としてGDIのSetROP2をそのまま使う感じの指定があったりするのは現状では互換が難しそうなので悩ましい感じです。イカガカ専用というわけではなく、ライブラリ単体をサイトに設置してシェルのプレビューするとかにも使えるようなので、興味あればのぞいてみて下さい。react-ukagaka-shell-pixi一方もう一つ、react-ukagaka-shell-pixiというプロジェクトもやっています。シェルを全部VirtualDOM的かつWebGLで描画するのを目標としています。cuttleboneはもう現状でもかなりの仕様が動くんですが、遅い箇所などもあったりAPIの癖などもあるので、そのあたりを新規に作り直したら......という実験です。こちらは低レベルの描画に近いので元々のGDIっぽい描画の指定もすんなり実現できるかもしれません。現状バルーンの文字描画についてはおおむね出来ているんですが、シェル系やアニメーションの考慮がまだ全く無い感じです。課題cuttleboneのAPIが色々と密結合で現在作成中のベースウェア部分と整合がいまいちなあたり、react-ukagaka-shell-pixiはシェル系の合成メソッドを実現するためのアーキテクチャが思いついていないあたりが課題だと思っています。前者はその辺のインターフェース設計をやったことある人......?(ぽなさん......?)後者あたりはシェルやら描画やらreact-pixiについて造詣が深い人がいると捗りそう......。reactでやるのがむりだったら捨てるのもアリですが、まだ方法を考えたいです。さくらスクリプト伺かの動作は独自のマークアップ言語、さくらスクリプトというものが司っています。これについては元々雑に正規表現で扱ってたんですか、パーサー「sakurascript」と時間に沿って実行をするライブラリ「sakurascript-executer.js」を作りました。単純に未対応スクリプトが結構あります。これはまあ正規表現を書けって話ですね。パーサー未対応とは別にシェルの方で未対応って言うのもあってこっちは悩ましいです。surfaces.txtシェルの描画そのものをするのも大変ですが、伺かにおいて最も大変なことの一つはsurfaces.txtの取り扱いではないでしょうか。独自形式で複雑な仕様である上に、SSPがかなり寛容に取り扱うおかげで「記述仕様としては誤っているが動いている」というゴーストが結構存在します。この「誤った記述」の場合記述の場合どのように解釈するかというのが全然分からなかったりしてなかなかつらいところです。「如何か」時代のduxcaさんも悩んでいたみたいなのですが、自分がイカガカをベースウェアとして開発する前に作っていたsurfaces_txt2yamlというライブラリが(本来想定された用途とは違うのですが案外)役立ち、これを改変したものがcuttleboneで現在使われています。課題surfaces_txt2yamlはかなりテキトーに作ってあり、控えめに言ってあまり使い勝手が良くはないです。使い勝手の良いsurfaces.txtのパーサー・ビルダーが出来れば伺かサーフェスビルダーなんかの夢も広がって良さそうなので、これとは別にどなたかやってみませんかね?SHIORIサブシステムSHIORIサブシステムはまさにゴーストの根幹ですが、ここが最も黒魔術を使っている部分です。ここは伺かの仕様では「こういう入出力を持ったWindowsのDLL」という定義、つまり自由なプログラムが書ける箇所なので、そのプログラムをそのままブラウザで動くようにしないとコストが高すぎる箇所だからです。幸いにしてPC上で動くプログラムをブラウザ上でも動くように変換するEmscriptenという黒魔術的技術が存在するので、それを使って主要なオープンソース汎用SHIORIサブシステムである「華和梨8」、「華和梨7」、「里々」、「YAYA」、「文5」に関して動作するようにできました。これはもともとUNIX系OSで伺かを動かそうというninix-ayaプロジェクトの為にWindowsに依存しないコードベースが各SHIORIに存在したのが大きく、少数のパッチをあてるだけですんなり変換できました。自分が現状作業したのはその少数のパッチ当てとkawari.jsにあるようなEmscripten用Makefileの作成くらいです。黒魔術を使う最も自由な仕様の部分なのでまだまだ課題も多いです。課題1(比較的簡単そう)1つめの課題は、現在も更新を続けている里々やYAYAの更新に自動追従が出来ていないあたりでしょうか。CIとかでカジュアルに更新をかけていく仕組みを作りたいですね。課題2(やや難しそう)2つめの課題は、SHIORIのプラグイン機構「SAORI」に対応していない点です。これはDLLからのDLL呼び出しという機能を実現せねばなりません。Emscriptenにおけるこのあたりの仕様について追っていく必要があります。DLLもクローズドソースなものが多いのでそちらの実装工数もバカになりません。現状はこのインターフェースをつぶすことで動作させている状況です。現行のイカガカについてここが最も要望が多く、かつヘルプが欲しいところであります。自分がSAORIを使ったことがないのでSAORIの利用状況なども把握しておらず、目処が立っていません。課題3(かなり難しそう)3つめの課題は、クローズドソースな栞、特に主要に使われているSHIORIのうち「美坂」のみクローズドソースなのでエミュレートの目処がたっていない点です。ninix-ayaではPythonで独自に実装することで回避していたようですが、少なくともこれをJavaScriptに置き換えるなどの作業が必要です。新規ゴーストのほとんどは美坂を使っていないようですが、やはり昔のゴーストを動かしたいものです。いまのところ優先度は高くないですが、よろしければご協力お願いいたします。その他の新しいSHIORIサブシステムについてはJavaScriptへの変換が出来れば対応することが出来ますので、イカガカに標準で入れたい場合は言って下さい。ゴースト独自のSHIORIを使う等の場合も、descript.txtにJavaScript版の指定を追加するなどで使えるようにしたいと思っています。課題4(ものによっては目処が立たない)4つめの課題は、汎用言語SHIORIへの対応です。SHIORI独自言語ではなく汎用言語によるSHIORIサブシステムへの対応は是非したいと思っていて、むしろそれを推していきたいんですが、RubyやPythonなどをブラウザ上で動かすというのはなかなか難しいところがあります。一応lua.vm.jsなどをはじめとしてJavaScriptで動かそうというプロジェクトは各言語にあるんですが、やはりなかなか難しいようです。言語レベルで対応できたとしても、イカガカはnarをそのまま動かすのを目標としています。ファイルシステムのエミュレーションなど課題は尽きません。汎用言語の中でもJavaScriptなら動くのでは?というのも難しい問題で、narをそのまま動かすにはファイルシステムのエミュレーションをしたうえでnode.jsの仕様にあるrequireを動作させなければ実用的ではありません。このrequire対応についてはbrowserfs-module.jsというのを作ってかなり力業で対応したのですが、まだテストをする時間を取れておらず、本当に動くのかは未知数です。これはイカガカに限らず、デスクトップアプリケーションをいかにブラウザ上で動作させるかという問題なので、ご興味ある方は是非ご協力下さい。SHIORIプロトコルSHIORIプロトコルは前述のSHIORIサブシステムとベースウェアの通信仕様です。これがないとDLLを変換してもSHIORIサブシステムを動かすことは出来ません。このSHIORIプロトコルのパーサー・ビルダーはベースウェアであるイカガカだけではなく、SHIORIサブシステム側でも使うものなので、それ用に複数の言語で実装しました。shiori.go各言語でSHIORIサブシステムを作る場合はご活用下さい。JavaScript版は最初にはりきって作ったので、HTTPのようにチャンクで渡ってきても処理できるようなのもパーサーに含まれていたりします(SHIORIプロトコルの仕様にはない)。cshiori等があります。両対応またSHIORIにはSHIORI/2.xとSHIORI/3.xというバージョンがあります。イカガカで対応しているSHIORIサブシステムの中でも、華和梨7と文5は古いSHIORI/2.xで通信をする必要があるので、標準のSHIORI/3.xと両対応する必要があります。これについては内部的にはSHIORI/3.xで扱いつつ、SHIORI/2.xとの変換レイヤーをもうけることにしました。2.xと3.xの変換をかけられるshiori_converterと、リクエストとレスポンスとをひとまとまりとして扱って、そのまとまりを2.xか3.xとして扱うshiori_transactionを噛ますことでスムーズに判定&変換ができます。実際にSHIORIサブシステムを呼ぶところを司るshiorifでこれらを透過的に扱えるようにしています。課題shiori_converterはうさださくらの資料と華和梨8の実装などを参考に結構手探りで作ったので、バグがあることが予想されます。2.x→3.x以外の変換は現状必要ないので実装していません。基本的に新しいゴーストには関係ないところなので、あまり問題ではない感じです。ファイルシステム一般にデスクトップアプリケーションと同等機能をブラウザで動かすという場合に一番障害になるのがおそらくファイルシステムでしょう。ファイルシステムという概念がブラウザにはそもそも存在しないからです。「データを保存できる場所」としてLocalStorageやIndexedDBなどいくつかの場所は存在するのですが、ローカルのファイルシステムには基本的にアクセスが不可能です。いうわけで、とくにSHIORI等がファイルシステムを前提として動いている伺かを移植するためには、何らかの方法でファイルシステムをエミュレートしてやる必要があります。これについてはBrowserFSというファイルシステムをエミュレートするライブラリを利用したうえで、NanikaStorage(名前が微妙)という伺かベースウェアのファイル操作を担うライブラリを噛まして実現しています。NanikaStorageは一般のファイルシステムにも使えるので、ベースウェア操作のエミュレートをしたい場合などにも使えるかも知れません。イカガカでのゴースト起動の遅さはこことSHIORI初期化とシェル初期化です。IndexedDBと言うところから読み出してメモリーに全部コピーして転送する&書き戻すみたいなことやっているので泥臭いしバグい。FSのうまいつきあい方を知っている方はいませんかね?ベースウェアさて、これら要素技術を組み合わせて「伺かベースウェア」として動作させる存在が必要です。現在デモで動いている旧バージョンは単体のゴーストを動かすNanikaと複数ゴーストを管理するNanikaManagerがベースです。現在作り直し中なのはghost-kernel.jsで、色々試行錯誤しながら作っています。ごとのイベント発行、ユーザーや他ゴーストからのコミュニケート、SSTPによる外部通信など色々な入力ソースがあるので複数入力ソース用のイベント管理ライブラリlazy-event-router.jsを作ったりしてなかなか大変です。自作が目的ではないので、そういう複数入力ソース用のイベント管理ライブラリで良いのがあったら教えていただけると助かります。課題シェルのインターフェースが定まっていないのでそことのつなぎが止まっていること、イベント駆動の管理の良いアーキテクチャが手探りで色々変わっていることなどの要因で、まあ全く安定していませんし、物量も多いです。ここに関しては不安定すぎてまだヘルプを請えるような状態でもないので難しいところです......。デスクトップ・スマートフォン対応さて、そうして組み上げたイカガカは現状PCブラウザ上で動く事を第一目標としていますが、これを逆にデスクトップアプリケーションにしたり、あるいはスマートフォンで動かすなどにはもう一工夫必要です。デスクトップアプリケーションそもそもデスクトップにはSSPがあるじゃんって話なんですが、WineをインストールしなくてもLinuxやMacで動くと嬉しいですよね?(たぶん)あとイカガカのライブラリ群を使ってゴーストエディターとかデバッガーが出来るといいなとも思っています。過去にはnode-webkit(現nw.js)でサンプルを作ったことがあるんですが、現状だとelectronのほうが知見が多そうなのでそちらでやろうかと考えています。ブラウザと違って、ファイルシステムをエミュレートせずに実FSを使う、またWindowsでは普通にDLLを読み込んで使うなどが出来るので、そのあたりの対応が必要です。スマートフォンイカガカのベースウェアはもともとスマートフォンに脅威を感じてはじめたプロジェクトなんですが、現状スマホでいい感じに伺かを使うというのはなかなか難しいところです。そもそも「デスクトップ」が存在しないのでたぶんアプリとして切り替えるしかなく、大分体感が変わります。マウス前提で作られたUIをどうタッチ対応するか、などの考慮も必要です。ブラウザを立ち上げてタブ切り替え、というのはなかなか手間がかかるので、出来ればCordovaなどでアプリにしたいところですね。そもそもホームアプリに伺かを含んでしまってデスクトップ相当を乗っ取ってしまうという逆転の発想も試してみたいところです。DOMLauncherやHTMLauncherなどのブラウザ技術でランチャーが作れるものが存在するらしいので、そのあたりをいじると出来そうな気はしますね。この辺言っているだけで全く着手など出来ていないです。スマホ対応とか新体感で面白そうなのでおすすめです。以上で上げた以外にも、小物的に色々なライブラリを作りつつイカガカは構成されています。現状イカガカに興味があってもどこからみたらわからない状態だと思うので、俯瞰の為に下記に簡単な一覧をあげておきます。新しいものはTypeScript、古いものはES2015かCoffeeScriptで書いてある率が多いです。ベースウェア本体関係Ikagaka/ghost-kernel.jsベースウェアで単体ゴーストを動作させるカーネル部分。Ikagaka/named-kernel-manager.js複数ゴーストを管理する部分です。今はまだほとんど実装がありません。Ikagaka/ikagaka-applicationたぶん将来的にブートストラップはここからやります。今はまだ何もありません。Ikagaka/ukagaka-timer-event-source.jsベースウェアが発行する時限イベント(OnSecondChange等)の元となるイベントソース。setIntervalしかしてないですが、モジュールとして切り出すのがきれいだと思ったのでこれだけでライブラリになっています。Narazaka/lazy-event-router.js複数のイベントソースを持つイカガカのイベント処理の為に作ったイベント管理ライブラリ。他にそういういいのがあったら教えて下さい。SHIORIサブシステム関係Narazaka/shiorijkSHIORIプロトコルパーサー・ビルダー・コンテナ。ベースウェアでもSHIORIでも使えます。Narazaka/shiori_converter.jsSHIORI/2.xとSHIORI/3.xを同義変換する為のライブラリ。2.x→3.xの変換のみ実装しています。Narazaka/shiori_transaction.jsSHIORIプロトコルのリクエストとレスポンスをまとめて扱い、上記変換を便利にするライブラリ。Ikagaka/ShioriLoaderSHIORIサブシステムをファイルシステムから種類判定してロードする為のライブラリ。判定関数はプラグイン式で、デフォルトの判定はIkagaka/shioridetector-common_namesに書いてあります。Ikagaka/shiorifロードしたSHIORIサブシステムと通信する為のライブラリ。shiori_transaction.jsやshiori_converter.jsと連携して、SHIORI/2.x、SHIORI/3.xを変換しつつ透過的に扱えます。Narazaka/nativeshioriEmscripten変換したSHIORIサブシステムとCのインターフェースで通信する為に、メモリ管理や文字コード変換などを請け負うライブラリ。イカガカ外でもEmscripten変換したSHIORIサブシステムを単体で扱いたい場合には重宝します。Narazaka/WorkerClientServerWebWorkersをクライアント・サーバー方式っぽく扱うラッパーライブラリ。SHIORIプロトコルがクライアント・サーバー方式なので、SHIORIサブシステムをワーカーで使うために作成。他の良い感じのがあれば教えて下さい。Narazaka/single-file-worker.jsどこにスクリプトを置いてもWebWorkerが動かせるような仕組みにする為に、文字列で埋め込んだスクリプトを起動する為の仕組みです。他の良い感じのがあれば教えて下さい。Ikagaka/NativeShioriWorkerSHIORIをブラウザのWebWorker上で動作させるライブラリをつくるツール&ライブラリ。魔術的な操作をやっているので、たぶん将来的には別の仕組みを作るんじゃないかと思います。single-file-worker.jsを使う為に魔術的な変換をかますやつです。各種SHIORIサブシステム汎用SHIORIサブシステムをEmscriptenで変換したものです。上記をWebWorker上で動くようにしたもの。魔術的なNativeShioriWorkerを使っています。Narazaka/aya5worker.jsシェル関係Ikagaka/ukagaka-install-descript-info.jsnarに含まれるinstall.txtと各種descript.txtのパーサー・コンテナ。TypeScriptの型定義も含んでいるので、プロパティが便利に参照できます。シェルくらいしか型定義が充実していないので整備する必要はあります。Ikagaka/cuttleboneシェル描画ライブラリ。NamedManager.jsというのがありますが、これらはcuttleboneのコンポーネントです。Ikagaka/react-ukagaka-shell-pixi.jsシェル描画ライブラリ。シェルの状態を持ったモデルと実際の描画とを別々にする思想の元設計されています。react-pixiというものを使っていて、副作用を持たない描画ライブラリです。アニメーションについては都度更新をかける必要があります。バルーンはある程度出来ていますが、まだシェル部分の多くが開発中です。Ikagaka/ikagaka-shell-statecuttlebone風のAPIを持ったシェルの状態モデルです。Ikagaka/ikagaka-shell-loaderシェルをnarからロードするライブラリです。Ikagaka/ghost-urn.jsシェルの新しいAPIを考える為のリポジトリです。Narazaka/surfaces_txt2yamlsurfaces.txtをパースして構造化データにするツールです。これを直接ではありませんが、改変したものがcuttleboneで使われているとのことです。元々はsiurfaces.ymlという構造化データからsurfaces.txtを作るsurfaces_yamlというツールの逆変換ツールでした。さくらスクリプト関係Ikagaka/sakurascriptさくらスクリプトパーサー・コンテナ。これ単体はスクリプトをパースしてオブジェクトにするだけです。Ikagaka/sakurascript-executer.jsさくらスクリプト実行機。パースされたさくらスクリプトオブジェクト群のうち時間関係の部分を考慮して、その他のスクリプトを含んだイベントを時限発行してゆくものです。ファイルシステム関係Ikagaka/NanikaStorageベースウェアが行うファイルシステムの操作をラップするライブラリです。narを展開する場所が分かるとか、シェルのフォルダだけ置き換えるとかがメソッド1発で可能です。ukagaka-install-descript-info.jsと連携してdescript.txtの中身なんかも簡単に取れます。Ikagaka/NarLoadernarを読み込む部分です。jszipでzip展開して、NanikaStorageでnarの中身をファイルシステムのように読み出せるようになっています。Narazaka/fsoイカガカ用ではありませんが、ファイルシステム操作の為に広く使っています。jvilk/BrowserFS同じくイカガカ用ではありませんが、ブラウザ上でのファイルシステムエミュレートの為に必須のライブラリです。その他Ikagaka/Ikagaka.demoデモ用のWebサイト。旧バージョンのベースウェアシステムが元気に動いているイカガカのデモですが、SHIORIサブシステムの更新とかはこのリポジトリを細々と書き換えたりしています。Narazaka/ikadocイカガカの現行仕様まとめのためのリポジトリでした。今デモで動いている旧バージョンの情報としてはおおむね正しかったはずです。まとめ以上、ざっくり技術やライブラリについてまとめてみました。こんな感じがおおまかな現状です。全体的に仕様の大きさと異色の難度で大変なことになっていますが、部分的になら意外と出来ているもんです。イカガカの作業中に作られた色々なライブラリを使って、周辺ツールを作ってみても有益だと思います。その辺も含めて、イカガカは主に作業時間の不足による開発長期化で割と死んでるので、特に現状の2人の開発勢では対応できないことなど、なにかやってみたいって人がいるといいなって思ってます。このほかにもSHIOLINKなどで汎用SHIORIサブシステムを作るなどもやっています。今後10年戦えるベースウェアや周辺ツールを作って伺か文化を振興したい思いはあるので、なんか一家言ある人は色々言って下さい。