カテゴリ：プログラミング-奈良北部のなにか

05 | 2023/06 | 07
日	月	火	水	木	金	土
-	-	-	-	1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	-

トップ > カテゴリ－プログラミング

2018年にNode.jsとIEとEdgeとFirefoxとChromeとSafariとElectronとNW.jsでTypeScript+mocha+power-assertな単体テストをカバレッジ付きで走らせたメモ

-- 2018/01/03 12:05

元旦に思い立って表題の通りにする過程で色々調べたメモ。TypeScript+色々系はいまいちまとまったのがないので参考になれば。

背景

上記全環境で動作予定がある、小規模だけど少しめんどくさい処理をするライブラリ（lazy-event-router イカガカプロジェクト用）を書いてたので、CI謎テストこけを直しついでに今風に刷新することにした。

できるだけデフォルトに沿い極力設定を書かない方針でいった。個人的にあんま使わないのでwatch系はなし。タスクランナーはnpm scripts。

本体コード

コードは全部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不要でいけるので、インストール量を減らしてゆこう。

テストとカバレッジ

テストはpower-assertとmochaで、node.jsではカバレッジはnyc mochaで取れるように構成する。

が、まずココにはまりポイントがある。

WebpackとBabelなしのTypeScript環境でpower-assertを使う自然な選択肢としてespower-typescriptを使うが、そのまま何の気なしにmocha.optsに--require espower-typescript/guess --recursive 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の設定。

appveyor.ymlは追加でIE決め打ちテストを走らせるためにnpm run test-winにしているくらい。FirefoxもChromeも入っているし普通にGUI上で走るので目立った設定は不要だ。

.travis.yml、まずLinuxでGUIアプリケーション（Firefox）を走らせるためにDISPLAY設定したりxvfbを立ち上げて立ち上がるまでてきとうにsleepするという設定が入っている。これはTravisのGUI and Headless Browser Testingの通り。

さらにLinux/Mac両方でFirefoxとChromeを使いたいためaddonsでインストールを指定する。

これもTravisのFirefoxとGoogle Chromeの項のとおり。

LinuxのChromeインストールのためにdist: 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より辛くなかった。

利用者が少ないのか探してもコマンドラインベースでのテストについてロクな情報が出てこない（mochaのヘルプにGUIでの事例はある）中、ほとんどユーザーのいないkarma 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ブラウザ同様普通にカバレッジまで出せるようになる。

なんか全体的に危なっかしい感じだけれど、調べた限りおそらくこれが連携用の長大独自コードを書かずにコマンドラインベースでテストできる唯一の方法ではないかと思う。他あったらお知らせ下さい。

npm scripts (package.json)

最後にこれらを（結局人類はMakefileの元に帰る運命にあるのだなと思いながら）npm scriptsに書く。

表題とは直接関係ないが、クロスプラットフォーム開発のために便利なshxやcross-envを導入することでWindows上での開発も快適に。

prepublishも書いておくとビルドし直しわすれが減る。

mainはes2015コードを示し、typesも忘れずに。

上記の通り設定ファイルが沢山出来るので、"files"によるポジティブリスト指定により配布ファイル量も少なくしておく。

以上

とりとめなかったですが、こんな感じで表題の通りの環境が作れます。

昔に比べてTypeScript、Webpack、Karmaのバージョンもそれぞれ上がって周辺環境も洗練され、何点かのハマりポイントを回避すれば格段にシンプルに構築しやすくはなっています。

それでは今年も良いTypeScriptライフを。

[ 2018/01/03 12:05 ]
カテゴリ: プログラミング
TB(0)
COM(0)

マスターデータ管理を優しくExcelから解き放つ (ドリコムアドベントカレンダー9日目)

-- 2017/12/09 00:01

ドリコムアドベントカレンダー9日目

前日は@onkさんの「ドリコムの Gemfile 記述スタイル」です。

自己紹介

奈良阪です。

こんなアイコン

株式会社ドリコムに新卒で入って3年目、スマホゲームサーバーのRailsとか、新規サービスのTypeScriptとか、Elixirとか、少しPythonとか、なんかよくわかんない組み合わせですがどれも並行してざくざく書いてます。

なお弊社最近JavaScript開発知見がなかったのでむしろしがらみがなく、趣味でやってた自分好みのTypeScript開発体制をスッと入れられてほくほくしています。有識者目指していく。

最近github.com/Narazakaの上の方に上がってきたswagger云々とかのTypeScriptのプロジェクトは、仕事で環境整備しているのの切れ端だったりします。

趣味では伺かというデスクトップマスコットのWeb移植版を作ってたけど時間が取れずに停滞してたり、RPGツクールで同人ゲーを細々ツクってたり、漫画を読んだり描いたり、鉄道に乗ったり、アニメやギャルゲのオープニングムービーを愛でたりしてます。

マスターデータ管理を優しくExcelから解き放つ

これは筆者が新卒でスマホゲームの運営に入って感じた「マスターデータのExcel運用」のしんどさを解消するために開発・導入した、ドリコムにおける新しいマスターデータ管理方法（2プロジェクトで運用中）を紹介する記事になります。

（地味に社内向け紹介記事も兼ねていたり）

以下スマホゲーム運営関係ない人向けの前振りが長いので、そんなことはいいからどんな手法か知りたいという方は「YAMLをExcelファイルに逆変換できるツール、作りました。」とか「seedtableでの運用方法サンプル」の章から読んでください。

1. マスターデータとは

2. Excelは使いやすい

3. Excel(.xlsx)の管理はしんどい

4. ExcelのUIでYAMLをいじれれば最高なのでは？

5. YAMLをExcelファイルに逆変換できるツール、作りました。

6. seedtableでの運用方法サンプル

7. seedtableと今後

8. まとめ

参考. Google Spreadsheet

参考: YAML編集表計算ソフト SeedsonTable (追記)

マスターデータとは

さて弊社、スマホゲームを主要事業の一つとしています。

スマホゲーム業界において特徴的に見られて、かつ聞くところによると近隣他業種にはあまり見られないらしい問題として、「マスターデータ管理」というものが存在します。

よくあるスマホゲームでは、ユーザーに関係なくあらかじめ運営者が設定しておくべきデータ（例えばキャラクターのパラメーターなど）があります。これをマスターデータと呼びます。

多くのスマホゲームは出して終わりではなく継続的にイベントなどをリリースして行く運営スタイルであるため、そのマスターデータの更新操作や新たなデータ形式の追加が頻繁に発生します。

その頻繁さたるや、最終的にユーザーに公開するタイミング以外にも、その前段に入るゲーム特有の「バランス調整」という作業により、開発環境では数分に一回ペースで更新が走ることもあります。

（最近のコンシューマゲームなどではDLCなど継続更新運用っぽいことをしている場合もあるので、同じ悩みを抱えていたりするのでしょうかね……？）

さて、そんな無茶苦茶な頻度で更新されるゲームデータをゲームプランナー（企画）さんが入力するツールはというと？

みなさんおなじみ、Excelです。

Excelは使いやすい

Excel、特にプログラマ中心に人によっては複雑な感情を持っていたり、または忌み嫌っていたりするツールだと思います。しかしそんな人が出るほどにあらゆるところで使われている所以、「誰でも使えてカスタマイズしやすい多機能な表計算ソフト」として確立された性能は優秀の一言に尽きます。

プランナーさんがデータ入力する時、同じデータや連番IDをｼﾞｬｯと一発で入力したり、数式でいろんなパラメーターを体系的に弾き出したり、いい感じにメモしたり、セルに色つけて注意を促したり、VLOOKUPでまとめシート参照して定型値ブチ込んだり、まあ我々横から眺めているプログラマーたちからするとよくそんなに色々やるなというレベルでいろいろされます。

それもこれも効率の良いデータ作成のため。

Excel並に使いやすい（←これハードル高い）専用ツールがあれば一番良いのでしょうが、大抵はデータベースのテーブルにそのまま値を突っ込む作業になりますし、（慣れもあるでしょうけど）がっつりツールを作りたいっていう企画の人は今の所弊社にはいないようです。

近い他社の人に聞いてみても今の所みなExcelで、専用のツールがあるという話はまだ聞いていません。（あったら教えてください）

Excel(.xlsx)の管理はしんどい

そんな使いやすいExcelにも適用範囲が存在します。

Excel上で一人で表形式データの編集をする時のみがExcelが使いやすい利用ケースです。

それ以外の

- プログラムで扱う

- 複数人で同一テーブルを編集する

- 編集差分を取る

- 自動化する（詳しくは、拙作スライド「VBAナメてた」をご覧ください）

- バージョン管理をする

などのマスターデータ運用においてよく出てくるユースケースについては軒並み激烈に相性が悪いです。

つまるところ

- プログラムで扱うために変換するのに(Rubyとかだと特に)時間がかかり、データ反映イテレーションが遅い

- Excelと変換後データが時々ずれたりする

- 複数人で同時にテーブルをいじると、自動マージできないのでたびたび関係者で話し合って手作業マージすることになる

- Excelの中身をアプリに入っているデータと簡単に突き合わせられないので、ある時点でのデータを修正したいという場合にExcelマスターのリビジョンを探すのが面倒

- gitリポジトリ容量がめちゃくちゃ膨れる

などの現象が起こります。

基本的にExcelの保存形式（.xlsx）が妨げになっている感じはあります……。

逆にこれらと相性が良いのはテキスト形式です。

CSVやJSONやYAMLなら「複数人でいじるためにgit管理して差分を見たりマージしたりする」「プログラムで自動化する」なんてのは朝飯前でしょう。

しかしJSONやYAML形式をそのまま編集するのは苦痛の極みだと思います。

CSVにしたって、Excelの式とか色とかメモとかマクロとかが軒並み使えないので編集しやすさには雲泥の差があります。

なおこの中で一番git差分が見やすいのはYAMLだと思います。カラム値が変わるのがちょうど1行差分になるのでCSVとかと比べてごっつ見やすいです。

ExcelのUIでYAMLをいじれれば最高なのでは？

思った。

「使いやすい編集UIであるExcel」で「使いやすいデータ形式であるYAML」を編集できれば最強なのでは……と。

でも現実的にはExcelファイルをYAMLに変換はできるけれど、YAMLをExcelファイルに逆変換することは不可能なので、この構想は実現できない……。

YAMLをExcelファイルに逆変換できるツール、作りました。

そう、できなかったので自分で作りました！

seed-ui/seedtable と言います。

Readmeに書いてある通り、

というExcelファイルと

data1:
  id: 1
  name: さくら
  description: F.I.R.S.T
data2:
  id: 2
  name: アルル
  description: ボク
data3:
  id: 3
  name: さっちゃんさん
  description: 髪が長い

というYAMLが相互変換できます。

YAMLのデータをxlsxファイルにほぼ安全に書き戻せます。

・書き戻しても数式もマクロもそのまま！

・書式設定や入力規則も（列ごと限定ですが）大体残ります。

・（条件付き書式は怪しいところがあるらしい……。あとマスターデータのシート自体にそんなに入れないのではないかと思いますが、グラフとかOLEオブジェクトは無理です。）

Excelの便利な機能を大筋損なうことなく変換を可能にしました。（EPPlusライブラリ様様です）

CUI版もGUI版（設定してからxlsxファイルをD&Dするだけ！）もありユーザビリティも十分。monoを使えばLinuxやMacでも動作するのでCIとかにも入れられます。

（変換も高速なのでxlsx→yaml変換だけしかしない場合でも置き換えオススメ）

というわけで、このツールによって、「使いやすい編集UIであるExcel」で「使いやすいデータ形式であるYAML」を編集することができ、新たなマスターデータ管理の可能性が拓けるはずです。

seedtableでの運用方法サンプル

説明用に下記のようなサンプルリポジトリを作りました。

https://github.com/seed-ui/seedtable-masterdata-repository-example

seedtableを利用し「使いやすい編集UIであるExcel」で「使いやすいデータ形式であるYAML」を編集する、弊社における新しいマスターデータ運用方式の例です。

これは実際にseedtableを導入した新規スマホゲーム2プロジェクトでのマスターデータリポジトリを、雰囲気でサンプル用に再現したものです。

master_dataがアプリケーションのDBに入れるマスターデータです。

gitで差分がわかりやすいように、IDごとに分割されたYAMLファイルになっています。

これをてきとうなスクリプトで不要カラムを消し、テーブルごとの1ファイルYAMLにまとめるなどして、最終的なDB投入コマンドにかけます。

マスターデータをExcelで編集する時は、Readmeの「Excelでデータを編集するときの手順」にあるように、

1. ゲームプランナーなどが自分のPC上で、master_data内のデータが入ったExcelファイルをExcelテンプレートファイルから生成（seedtable-guiにD&D）

2. 適当に編集

3. 編集後データが入ったExcelファイルからmaster_dataへとデータを書き出し（同じくseedtable-guiにD&D）

という手順で行います。

単純なExcel編集の前後に操作が増えていますが、ごく簡単な作業なので、得られるメリットに対して許容できる範囲ではないかと思います。（弊社では実際これで回りました）

Excelテンプレートは基本的にアプリケーションにテーブルを作るエンジニアなどが最初にExcelで作り、適宜カラム追加や式が必要な時などにメンテしていく感じです。

・1行目にカラム名の説明（ID、名前、等）

・2行目にカラム名（id、name、等）

・3行目にID=1のデータを作って数式や書式を設定します。

Excelテンプレートに数式や書式設定をいれておくと変換後のExcelにも反映されるので、便利に編集が行えます。

seedtableが担う部分はExcelとYAMLの相互変換の部分のみなので説明としてはこれだけですが、こうすることによって、Excelファイルがほとんどプログラム側に出てこないようになります。

gitリポジトリからして単にYAMLの差分を見る場所になりますし、実質Excelが登場するのはほぼプランナーPC上のみです。

中央集権で変換することもなくなるのでデータ反映もはやくなります。

これまで大元がxlsxファイルであったマスターデータが本質的に大元YAMLファイル形式になることによって、マスターデータはマージできて、差分が見られて、本来のバージョン管理ができるものになります。

参考: https://github.com/seed-ui/seedtable-masterdata-repository-example/pull/1/files

これ以外の.xlsxな差分はナシ！

seedtableと今後

これによってプランナーPC上でExcelからYAMLファイルが生成できるようになったということは、Excelの機能性の恩恵を受けつつ、かつその上で十分簡単にほかのプログラムもマスターデータを扱えるようになるということです。

というわけで試しに activehashie-validation というデータチェックツールを作ってみました。

プランナー手元でデータをExcelからYAMLに書き戻した後にバッチファイルを叩くことで、PC上ですぐにデータチェックが完結します。（導入したてなのでバッチファイルですが、需要があればファイルのwatchなんかもしたいです）

データ不整合チェックはもちろん、全マスターデータを読み込む任意のチェックがかけるので、「運用上こうするべき」といったようなゲームに密着したチェックも書けるはずです。

こんな感じのHTMLが出力されます（リポジトリにあるexample）

特徴としては、TypeScript製でありながらActiveRecord/ActiveModelっぽいAPIなライブラリになっています。（弊社サーバーが主にRuby on Railsなので学習コストを鑑みた結果）

TypeScript、つまるところJavaScriptなのは、プランナーPCにnode.jsやelectronなzipをダウンロードさせるだけでほかのインストールなしに使えることを重視したからです（Rubyなどだとランタイムセットアップの手間と維持コストがある）。

ただ、アプリサーバーと言語が違う（RubyとTypeScript）こと、アプリサーバーと別プログラムであるためテーブル定義は実質同じことを2回書くことになるなど、ややメンテナンス性に課題はあります。（テーブル定義についてはスキーマから自動生成とかしたいですね……）

しかしともかくこういった手元チェックツールを同時に導入することで、Excelを使った快適なデータ編集とこれ以上なく素早いデータチェックが実現し、本質的なゲームの価値担保のみに注力するための土台が整うのではないかと思います。

まとめ

・弊社ではExcelをスマホゲームデータ入力に使っていたがつらみがありました。

・ExcelでYAMLを編集できればいいのではという着想から seed-ui/seedtable というツールを作りました。

・新規プロジェクト2つにseedtableを使った新しいマスターデータ管理方式を導入し、運用しています。

・新しいマスターデータ管理では

　・マスターデータの手元変換、手元差分チェック、手元データチェックによる素早いイテレーション

　・ほとんどの複数人編集コンフリクトの解消

　・リポジトリ軽量化

　などが見込め、マスターデータ管理がプログラマーにもプランナーにも優しくなります。

・seed-ui/seedtable はオープンソースなので、ぜひ同業他社などで悩んでいる方がいればお気軽に使っていただき、またわからないことがあれば @narazaka までお問い合わせください（Twitterとかissueとかなんでもどうぞ）。

・手元データチェックツールとして activehashie-validation というのも作ってみて試験運用しています。こちらも何かあればどうぞ。

いつともしれない未来に理想のツールができるまで、Excelとの付き合いは続きます。

どうせ付き合うならExcelユーザーとプログラマー、お互い幸せな付き合い方をしてゆきたいですね。

明日10日目分はひさのんさんの「デザイナーへターミナルのすゝめ」です。

参考: Google Spreadsheet

Excelの代替ツールとしてGoogle Spreadsheetがよく挙げられると思います。

しかし、Excelの多機能さやある程度の軽快さをGSが持っていないこと（というかGSが重い）、慣れ親しんだ操作感との違いなどの要因からか、比較した時の評判はあまり芳しくないようです。

またGSは同時編集も大きな特徴としていますが、実際途中まで使ってからこのExcel+YAML新方式に切り替えたチームに聞いたところ

・同時編集できても、反映タイミングは人によって違うのでメリットになっていない

・同時編集"できちゃう"ので予期せぬデータ変更起きそうな気がした

という意見が聞かれて、必ずしもマスターデータ運用に対して有利に働くものではないようです。

弊社でも1プロジェクトがGoogle Spreadsheetを使っているので普通に運用可能と思いますが、GSと上記方式それぞれ一長一短があるという印象です。

参考: YAML編集表計算ソフト SeedsonTable (追記)

はてブのコメントで「逆変換でマクロ含めて元に戻せるのは凄いが、まともなyamlエディタこそ欲しい。」っというのをいただいたんですけど、自分も過去全くその通りのことを思ってて、実はExcelっぽく直接YAMLをいじれるエディタもつくってました→ seed-ui/SeedsonTable

フォーマットとか日付入力はもちろん、seedtableでは出来なかった表計算UI時点での複雑なデータチェックなども出来る表計算ソフトっぽいやつです。

プログラマがスキーマ的なものをJavaScriptで定義することで自由に制約がかけられる感じにしてます。

特徴的なのは、セル内数式を使わず、スキーマの時点で数式的な処理を記述すること。

つまりそのへんの自動化系管理がプログラマを経由するように働き、改善行動コミュニケーションが一元的にとりやすくなるのではないかと思っています。（数式の変更もgitで管理できるし）

ただやはりExcel（←ものすごく使いやすい）慣れしているプランナーに使ってっていうにはまだ苦しい感じ（オートフィルからして微妙）なので、まだ積極的に宣伝できる水準には遠いと思っています。

こんな位の機能で良いという需要があれば使ってみるのも良いかも知れません。あと改善プルリク下さい。

[ 2017/12/09 00:01 ]
カテゴリ: プログラミング
TB(0)
COM(1)

TypeScriptでのツクールMVプラグイン制作+α (RPGツクールMV Advent Calendar 4日目)

-- 2017/12/04 22:50

どうも、ツクールMVでゲーム制作中なワナビプログラマです。

最近やってるTypeScriptでMVプラグイン作る作業が心地よいので共有しようかと思います。

（これは RPGツクールMV Advent Calendar 2017 の記事です）

さて、ツクールMVの内部はJavaScriptで書かれています。

これは動的型付言語のためコード補完が効きにくく、~~MVにロクなドキュメントがないことも相まって~~、プラグイン作るときに色々見て回るのが面倒という問題を抱えています。

そこでTypeScriptです。

TypeScriptはMicrosoftが出している「JavaScriptに便利な機能を載せたJavaScriptに変換可能な言語」（AltJS）です。

同じくMicrosoftが出しているVisual Studio Code(VSCode)というエディタによってかなり素晴らしいコード補完と型チェックが効く便利な開発環境を誇っています。

このTypeScriptを導入し、コード補完の効くよりよい開発環境を作ることにします。

TypeScript導入

まずTypeScriptはJavaScriptで書かれているコンパイラーを使うので、node.js（Windows PC上のコマンドラインでJavaScriptを動作させることが出来るコマンド）をインストールします。

windowsにNode.jsをインストールする - Qiita あたりを見てインストールして下さい。

まあ普通にインストーラーぽちぽちするだけです。

次にコマンドラインで

npm install -g typescript

を実行して下さい。これでnode.js環境にTypeScriptがインストールされます。

同じくコマンドラインで

tsc --version

と出たらインストール成功です。

npmはnode.jsに付属しているパッケージマネージャーで、TypeScript等の便利なパッケージを管理するものです。

レジストリとかは特に触らず、node.jsをアンインストールすると一緒に後腐れ無く消えるので心配は要りません。

Visual Studio Code導入

TypeScriptにVisual Studio Code、鬼に金棒とはこのこと。

こちらはVisual Studio Codeのページにいって、普通にインストーラーをダウンロードしてインストールまでするだけです。

コマンドラインとかは出てきません。

インストールを普通にして適当なフォルダで右クリックすると、こういうメニューが出てくるはずです。

TypeScriptでプラグインを書く

では書いていきましょう。

ツクールのゲームでデバッグするのが多分楽なのでツクールのフォルダのわきでプラグインを作ることとします。

ツクールのゲームのフォルダで上のOpen with CodeからVSCodeを立ち上げます。

次に「表示」→「統合ターミナル」をクリックすると、こういう感じでコマンドラインが立ち上がると思います。

さて、ツクールMVの本体はJavaScriptで書かれていますが、外部からTypeScript式の型付を行うことで、型の恩恵を受けることが出来ます。

その外部型付を導入するため以下のコマンドを実行して下さい。

npm install rpgmakermv_typescript_dts

なにやらnode_modulesというフォルダとpackage-lock.jsonというファイルが出来ると思います（後者は出来ないときもあります）。

さらにフォルダ内にa.ts（.tsの前は何でも良い）とかファイルを作ってこう書きましょう。

/// <reference types="rpgmakermv_typescript_dts"/>

多分こんな感じになっているのではないかと思います。（左バー、下バー等、自分はエディタプラグイン入れてるので多少違うと思います）

ではこの状態で、ファイルに$を打ち込むと……？

おめでとうございます。補完が効くようになりました！

というわけで楽にプラグインが記述できます。

静的型付言語始めての方とかは若干型関係で詰まるかも知れませんが、調べれば割と出てくるのでかけるのではないかと思います。

で、書きました。

さあここからJavaScriptに変換する作業が必要です。

上記コードはほぼJavaScriptのままで型が付いている状態（便利ですね！）なのでこのまま拡張子を変えるだけでもいいですが、時々TypeScriptの型記述をつけなければならないときが出てきます。

まずtsconfig.jsonという名前で以下のような記述をします。

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "outDir": "dist",
        "lib": [

            "es5",

            "es2015.promise"
        ]
    }
}

そしてエディタの下にあるコマンドラインで

tsc

とだけ書いて実行しましょう

すると、dist/a.jsに変換されたJavaScriptができます。

これをプラグインフォルダに入れるなり、あるいは"dist"のところを"js/plugins"にするなどすると、便利にプラグイン開発が出来ます。

というわけでTypeScriptプラグイン導入編、お疲れ様でした！

TypeScriptを使うと補完以外にもまだまだnullチェックだとか非同期の記述方法だとかクラスの記述だとか、様々な先進的な機能を使えます。

色々調べていってみて下さい。

補足:

上記ではnpmで簡単にインストールできるものを紹介しましたが、類似の型定義でRPGMakerMV Intellisenseというのも存在する模様です。

こちらは英文でコメントが付いているようなのでこれを導入するのも良いかも知れません。

これを同じように利用するには、PIXI Includedと書いてあるものをダウンロードした後適当なところに配置して、

/// <reference 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、プラグインで拡張できるけど、エディタが拡張できないの片手落ちじゃない？

と思って作りました。

HP, MP, TPではない戦闘パラメーターや、「逃げる」以外の特殊効果、攻撃前タイミングで起こすアクションなど、プラグインで拡張したけどエディタでも編集できたら便利なものって結構あると思います。

electron/react/mobx製のデスクトップアプリケーションです。もし同じ思いを持つ人がいたらfork me on github!

その他

上記で導入しているrpgmakermv_typescript_dtsは自分が昨日あたりリリースしたモジュールです。

ただ元々コミットログにあるように別の方が開発していたものがgithub消えてしまったので、手元にあったやつを復活させたという経緯があります（MIT的には問題ないはず）。

Twitterで問い合わせても特に返答無かったのでそのまんま管理してますが、何か問題あれば言って下さい。

[ 2017/12/04 22:50 ]
カテゴリ: プログラミング
TB(0)
COM(0)

DBD::SQLiteがコアダンプはいてたのなおした

-- 2016/05/15 11:40

Arch Linuxサーバでてきとうにpacman -SyuとかでアップデートしてたらいつのまにかDBD::SQLiteがコアダンプはくようになってて掲示板とか曲目データベースとか動かなくなってた。

なにか共有ライブラリのパスでも変わったのだろうかとcpan -i DBD::SQLiteを試みるもそこでもコアダンプをはいている模様。

DBD::SQLiteをダウンロードしてきてperl Makefile.PLをたたいてもコアダンプ。

不審に思ってMakefile.PLを見てみるとその中でバージョンチェックのためにrequire DBD::SQLiteしているところがあって納得。
とりあえずそこをコメントアウトしてmake / make testすると問題なく通った。

さてmake installをたたこうかと思ったが、せっかくならcpanで処理したいなと思い、ためしにcpan shellでinstall .をたたいたらすんなり通った。
パスでもいけるのね。

[ 2016/05/15 11:40 ]
カテゴリ: プログラミング
TB(0)
COM(0)

研修で新規ゲームアプリをモデルとビューに分けて作ったり色々したら捗った話

-- 2015/12/20 17:48

この記事は【その1】ドリコム Advent Calendar 2015の20日目です。
前日はおーはらさんのElixirを使ってSidekiqを操作するでした。

なお弊社今年は募集盛況で【その2】ドリコム Advent Calendar 2015も出来ました。よろしくお願いいたします。
ついでに個人的に伺か Advent Calendar 2015とかLinux Desktop Advent Calendar 2015とかElectron Advent Calendar 2015とかNode.js その2 Advent Calendar 2015とかももんが Advent Calendar 2015とかも参加しているのでよろしくです。

自己紹介

ドリコムの新卒エンジニア、奈良阪と申します。ネットで奈良阪|Narazakaっぽいアカウントを見つけたらたぶん私です。

こんなアイコン

物理学専攻として生まれPerlで育ちJavaScriptでゲテモノを作る仕事Ruby使いでErlang勉強中のインターネットラクガキマンであり、メインWindows(10)でArch Linux好きなMacアンチでオープニングアニメーション愛好家なぬるめの時刻表鉄でもあります。
業務ではRailsをいじりつつ、Electronでプランナー向けツールを作ってみたり、管理画面にJavaScriptを仕込もうと狙ったりしています。

まあ変な人です。

新規ゲームアプリをモデルとビューに分けて作ったり色々したら捗った話

新卒エンジニアなので新卒研修というものがありました。
プランナー、デザイナー、プログラマーを含んだ6人のチームでゲーム1本作るといったものです。

そこでUnity3Dでスマホゲームを作ることになり、エンジニア3人のうち僕を含む2人でクライアントを作ることになりました。

作業分担としては、UnityでUIを作るあたりをもとからクライアントエンジニアであるchu-hiくんにやってもらい、もともとサーバーエンジニアである僕はUIがあまり関わらないロジックの部分を担当することになりました。

ロジックの部分を請け負ったのでそこの全体的な設計は僕がやることになりました。
そこで色々なことを個人的な趣味で仕込んでみて捗ったりしたという話です。

1.モデル(的な部分)とビュー(的な部分)に分けて単体テストを書いた

かねてから個人的にゲームのクライアントにもサーバーでやるような自動テストを導入したいなあという思いを持っていました。

今メインでいるプロダクトもそうですが、基本的に弊社ゲームのクライアントには自動テスト的なものがないのが現状です。
無論十分手動でテストが入れられているから回っているんですが、プログラマーたるもの怠惰にゆきたい。テストとか面倒なルーチンは機械にやらせたい……。
一般的に見た目に関わる部分の自動テストが面倒なのはあるんですが、見た目に反映する前の、例えばダメージ計算とかそのへんの部分まではある程度現実的に自動テストが入れられるんじゃないかと思いました。

そこにきて本ゲーム、前述のような分担をすることによって、作業者によってロジック（モデル的なところ）とUI（ビュー+コントローラ的なところ）を分離することに成功しました。

というわけで自動テストを書きました。
xUnit.NETつかってだいたいこんな感じです。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Xunit;
using NewGame.Word;
using NewGame.Status;

namespace NewGameTest{

    using ExecutableString = String;

    public class WordFrequencyElementTest{

        [Theory]
        [InlineData("return 1")]
        [InlineData("return 0.1")]
        [InlineData("return 'a'")]
        [InlineData("return true")]
        public void condition_enabled(ExecutableString condition) {
            var status = prepare_status();
            var fe = new WordFrequencyElement(condition, "");
            Assert.True(fe.IsEnabled(status));
        }
...

ロジックがUnityに依存しないPure C#でできているのでxUnit.NETとかそういう汎用のツールでかけて実に清々しいです。サーバーの人間にもスルッとかけます。

UIのテストはできていないんですが、その中で動いている複雑な部分のテストがあるというのは品質に対して実に安心感があるものです。個人の感想ですが。

これによってゲーム開発によくある（らしい）仕様変更にともなうコード修正に戦々恐々とすることはなくなりました。

2.データエディタを作った

かねてから個人的にExcelを撲滅したいなあという思いを持っていました。

基本的に弊社ゲームのデータはExcelで作られています。
・エンジニアにとって:
Excelはマージができませんし、差分もgitネイティブでは見られませんし、バイナリだからひたすらリポジトリが重くなりますし、ゲームに落とし込めるようテキストに変換するのに数分かかります。
・またプランナーにとっても:
RDBまんまなのでいちいち色々なところに数値のIDを関連づけのために入れなければならないし、複数人作業するときに手動ロックしなければいけない（自動マージできない）です。

つらいです。

というわけでこのゲームではExcelを生まれる前に消し去るために、すべてyamlやjsonをマスターにしたいなと思いました！

……と、言うは易し行うは難し。

実際データを作るプランナーの人とかにyaml直接いじれというのは酷というもの。
エンジニアが楽した分プランナーが闇を背負ってはいけません。
「データをいじるためのUI」＝「データエディタ」は必須なわけです。

普段はExcelがその役を負っているわけですが、Excelが嫌なら他のツールを使うしかない……。

というわけで今回は自分で作りました。
こんな見た目のやつです。

いわゆるゲーム中のシナリオみたいなやつのエディタで、yamlファイルを吐くものです。
ツリー状の構造になるゆえにExcelでは管理しにくかったので専用のを作ってみました。

Electronを使うことでWebアプリと同じような制作ができつつWin/Mac両対応が行え、UIライブラリとしてwebixを使うことでデスクトップアプリに遜色ない操作性を確保できました。

こちらはプランナーデザイナー陣にも好評で、「ならツール」などと呼ばれ親しまれました。
が、プロト提出の締め切りギリギリの中で結局デザイナー少しとあとほぼプログラマしか入力しなかったなど、課題は残りました。

3.データエディタにゲームのモデル部分を接続した

かねてから個人的にゲームのデータ調整やチェックを実際のゲームの処理に突っ込んでやりたいなあと思っていました。

ゲームにバグを出さないためにデータチェックツールというのが往々にして作られるわけですが、なにぶん仕様追加変更の多いゲームのこと、本体の変更に追従してゆくコストがかかります。
なのでゲームのデータを簡単に「本物」のゲームの処理に突っ込んでテストできれば、そういった外部ツールの辛みもなくなるのではないかと思いました。

というわけで先ほどのゲームのモデル部分処理だけを切り出してコンソールアプリケーションにし、先ほどのエディタがその入出力に対応することで、「本物の処理」を使って「プレビュー」を行えるようにしました。

右側がその「プレビュー」で、「実行」ボタンなどを押すと現在編集中の部分のシナリオが実際のゲームでどういった動きをするのか、選択肢などの挙動も含めて再現できるというものになっています。

この機能もやはり好評でして、プレビュー機能の成果か突貫工事なデータ入力作業でもレビューでバグっぽい動きはしませんでした。

実装としては単純にパイプで入出力しました。C# CLIなexeとnode.jsのchild_process.spawn()との通信です。
Edge.js、そのElectron対応版のelectron-edgeを使えば、node.jsからDLLのごとくC#内部の関数を呼べたのですが、やったかぎりだとあいにくそれができるのがWindowsのみだったので、Win/Mac両対応を崩さないためにパイプにしました。

ゲーム本体は本来ならシナリオを最初から再生する機能（上記ボタンの「戦闘開始」のみの機能）しか持たなくて良いので、本番では使わないテスト用の機能の追加は避けた方がデバッグコストなどもかからないでよさそうです。
本質的な処理をするモデルをゲーム全体から切り離せるようにしておくと、UIの必要性が薄いテストツールを気軽に外部アプリケーションとして作り込めると思います。

ただしこの手法の反省点としては、簡易プロトコルを作ったり、初期化処理だけですが本体に追従したり、Electronとの結合だったり、工数的にはちょっとお高くついてしまった感があるあたりでしょうか。
やっぱりゲーム自体にテスト機能を組み込んでしまう方法をとって、Unity3DのWebGLビルドを使ってブラウザ内完結させるとかのほうがもしかしたら簡単だったかもしれません。

まとめ

研修で新規ゲームの設計をやるに当たって、かねてから周りのゲーム制作を見つつ個人的に抱いていたゲームクライアント制作手法への提案を試してみました。

・モデル的な箇所とビュー的な箇所を分離することでテストをかきやすくし、実際書いて品質を担保しました（まだリリースしてないので主観になってしまいますが）。
・Excelには向かないデータ編集に対して独自ツールを作り、企画工数を減らしました。
・さらにデータ編集ツールにゲームの本物の処理が動くプレビュー機能をつけることによって、ミスを減らしたり調整を楽にしたりしました。

やってみた所感としては、

・モデルビュー分離はコードの質を保つのに貢献し、一方で爆速感の不足や、やや仕様変更に手間がかかる感がありました。ただテストなしで仕様変更後などにバグチェックするコストを考えると、実際には仕様変更の手間というのはこちらの方が軽いのかもしれません。
・データ編集のための独自ツールはプレビューもあって非常に便利でした。調整も楽だし、Gitフレンドリーでエンジニアも楽です。ただし初期投資はその分かかるので、短期間で運用を終了するゲームの場合はもしかしたらExcelに任せた方が良いのかもしれません。

基本的には目論見通り、テストや調整のコスト削減につながって良かったと言える感覚です。が、弊社ゲームの既存手法と比べると別のところでコストが新たに発生しており、なかなか八方うまくは収まらないなあと思いました。
ただこれはあくまで最初の試行であり、この方向でうまくやればなにか新境地があったりするかもしれません。

新しく1本ゲームを作るという研修、こういった試行錯誤も含めて多くの学びがあります。
現状まだ道半ばでいろいろあって修羅っていますが、なんとかいいゲームができるように頑張ってゆきたいです。

またここで得た経験を生かしたりして次なる手法の改善を考え、よりゲームの本質的な品質アップを目指して運動してゆきたいです。
そんなわけでまた変な実験を始めたら生暖かく応援よろしくお願いいたしますm(_ _)m＞社内

次回の【その1】ドリコム Advent Calendar 2015は、僕の教育担当でもある@shinya_131さんのエンジニアからデータ分析になって3ヶ月が経ったです。

[ 2015/12/20 17:48 ]
カテゴリ: プログラミング
TB(0)
COM(0)

トップ
次ページ≫

↑ページトップへ