Pythonを中心としたチーム開発
•Transferir como PPTX, PDF•
23 gostaram•8,932 visualizações
CEDEC 2015 Technical Artist Bootcamp 2015 vol.2 （前半） http://cedec.cesa.or.jp/2015/session/VA/2720.html
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (14)
Semelhante a Pythonを中心としたチーム開発
Semelhante a Pythonを中心としたチーム開発 (20)
Último
Último (8)
Pythonを中心としたチーム開発
- 1. Technical Artist Bootcamp 2015 vol.2 Pythonを中心としたチーム開発 - 個の力を組織の力に - スマイルテクノロジーユナイテッド株式会社 代表取締役社長 高橋涼
- 2. Technical Artist Bootcamp 2015 vol.2 はじめに
- 3. Technical Artist Bootcamp 2015 vol.2 ＴＡによる効率化 → 同じツールの改良ばかり？
- 4. Technical Artist Bootcamp 2015 vol.2 ＴＡを集めて大規模ツールを開発 → なぜか進捗が悪い。やりにくい。
- 5. Technical Artist Bootcamp 2015 vol.2 属人化
- 6. Technical Artist Bootcamp 2015 vol.2 アイデアと実行力
- 7. Technical Artist Bootcamp 2015 vol.2 チームでツール開発するためのルール
- 8. Technical Artist Bootcamp 2015 vol.2 できるだけPythonで書く
- 9. Technical Artist Bootcamp 2015 vol.2 内訳 • コマンドラインツール • スタンドアロンＧＵＩツール • PySide • ウェブアプリ • Flask • Django • DCCツールプラグイン • Autodesk Maya • Adobe Photoshop • Autodesk 3dsMax • Foundry MODO
- 10. Technical Artist Bootcamp 2015 vol.2 ルール 1. SCMで内製ツール管理 2. PEP8準拠のコードスタイル 3. テストコード 4. 自動化
- 11. Technical Artist Bootcamp 2015 vol.2 1. SCMで内製ツール管理
- 12. Technical Artist Bootcamp 2015 vol.2 ファイルサーバー直接参照 絶対に禁止
- 13. Technical Artist Bootcamp 2015 vol.2 USERTA 開発からリリースの流れ develop master
- 14. Technical Artist Bootcamp 2015 vol.2 ディレクトリ構成 ├─jenkins ├─maya │ ├─2016 │ │ ├─icons │ │ ├─plug-ins │ │ ├─python │ │ │ ├─stu │ │ │ └─testsuite │ │ └─scripts │ └─testsuite ├─photoshop └─setup
- 15. Technical Artist Bootcamp 2015 vol.2 Fabric==1.10.1 Jinja2==2.7.3 Pillow==2.7.0 PySide==1.2.2 flake8==2.2.4 Flask==0.10.1 lxml==3.4.0 nose==1.3.4 pathlib==1.0.1 pep8==1.5.7 py2exe==0.6.10a1 pycrypto==2.6 pyflakes==0.8.1 python-dateutil==2.4.0 python-docx==0.7.6 python-pptx==0.5.6 PyOpenGL==3.1.1a1 requests==2.5.0 simplejson==3.6.4 xlrd==0.9.3 Python環境の統一 • サードパーティ製モジュールはpipでインストール • PyPIから指定したバージョンをダウンロードしてインストール してくれる 引用：https://pypi.python.org/pypi requirements.txtの例
- 16. Technical Artist Bootcamp 2015 vol.2 すんなりとは行かなかった • 問題 • .whlを用意していないモジュールが少なからず存在する • MayaのdistutilsではPyPIからインストールできないモジュー ルがある • .pydをMayaで読み込むためにはマニフェスト情報が必要 • 解決策 • 自前で.whlファイルを用意してSCMに入れておく
- 17. Technical Artist Bootcamp 2015 vol.2 • Pythonのインストール • PATHに「C:Python27; C:Python27Scripts」を追加 • サードパーティ製モジュールのインストール • C:Python27 • C:Program FilesAutodeskMaya2016Python セットアップスクリプトの作成 % python get-pip.py % python –m pip install –r requirements.txt –f wheelhouse/ % “C:Program FilesAutodeskMaya2016binmayapy.exe” get-pip.py % “C:Program FilesAutodeskMaya2016binmayapy.exe” –m pip install –r requirements.txt –f wheelhouse/ % msiexec /i python-2.7.10.amd64.msi /qn
- 18. Technical Artist Bootcamp 2015 vol.2 2. PEP8準拠のスタイル
- 19. Technical Artist Bootcamp 2015 vol.2 • ソースコードの読みにくさの原因は コードスタイルの違い • インデント • 行の長さ • 命名規則 等 • コミュニティによって議論された標 準コードスタイルがPEP8 • 行の長さは99文字までＯＫ PEP8とは？ 引用：http://pep8-ja.readthedocs.org/ja/latest/
- 20. Technical Artist Bootcamp 2015 vol.2 メソッドがどのモジュールで定義されているか分からない インデントに一貫性がないた め、コピペで問題が起こる 変数名の命名規則に一貫性がない スペースの使い方に一貫 性がなくてイライラする
- 21. Technical Artist Bootcamp 2015 vol.2 pep8.py と pyflake.py • pep8.py • コードスタイルチェック • pyflake.py • 簡単な静的解析 • 同時に両方実行してくれるflake8を使用 % flake8 rename_all_joints_bad.py rename_all_joints_bad.py:14:1: W191 indentation contains tabs rename_all_joints_bad.py:14:10: E201 whitespace after '(' rename_all_joints_bad.py:14:13: E251 unexpected spaces around keyword / parameter equals rename_all_joints_bad.py:14:20: E202 whitespace before ')' rename_all_joints_bad.py:15:1: W191 indentation contains tabs rename_all_joints_bad.py:18:1: W191 indentation contains tabs rename_all_joints_bad.py:18:23: E201 whitespace after '(' rename_all_joints_bad.py:18:45: E202 whitespace before ')' rename_all_joints_bad.py:19:25: E901 IndentationError: unindent does not match any outer indentation level rename_all_joints_bad.py:19:34: E901 IndentationError: unindent does not match any outer indentation level
- 22. Technical Artist Bootcamp 2015 vol.2 3. テストコード
- 23. Technical Artist Bootcamp 2015 vol.2 テストコードの例 ジョイントをリネームするスクリプト （アプリケーション層とライブラリ層） ライブラリ層のテストコード mbの読み込み 実行してFalseが返ってこなければ例外発生
- 24. Technical Artist Bootcamp 2015 vol.2 noseをコマンドラインで実行 % nosetests.exe testsuite/ （省略. . . ） ---------------------------------------------------------------------- Ran 2 tests in 37.296s FAILED (failures=1) • testsuite/以下の • test_で始まるモジュールの • unittest.TestCaseの派生クラスの • test_で始まるメソッドを • 全てテストケースとして自動的に実行してくれる • 全バージョンのMayaのmayabatch.exeを呼び出してテストしている
- 25. Technical Artist Bootcamp 2015 vol.2 Maya上でのnose実行例
- 26. Technical Artist Bootcamp 2015 vol.2 testdir = ur”C:CEDEC2015_workspacedevelopmaya2016pythontestsuite” test_program = nose.core.main(defaultTest=testdir, exit=False) if test_program.success: print(u"TESTSUITE (SUCCESS) : all testsuites") else: print(u"TESTSUITE (FAIL) : any testsuites")
- 27. Technical Artist Bootcamp 2015 vol.2 コツは、無い • 他人のコードを読もう • 設計が綺麗なコードはテストしやすい。テストしにくいという ことは設計に難がある • ファイル入出力などデバイス依存はアプリケーション層（上位レベル）で行う • 複数のことを行ってしまう関数はテストケースが膨大に膨れ上がる • Mayaではシーン情報をJSONファイルに出力し、答えJSONとの 比較で済ますと比較的楽（結合テスト）
- 28. Technical Artist Bootcamp 2015 vol.2 4. 自動化
- 29. Technical Artist Bootcamp 2015 vol.2 Jenkins • 継続的インテグレーションツール • 一定時間毎に指定したジョブを実行する • 結果をウェブインターフェイスでグラフィカルに表示できる • 定番プラグイン • Build Pipeline Plugin • Parameterized Trigger plugin
- 30. Technical Artist Bootcamp 2015 vol.2 jenkinsで自動化 全テストコード の実行 Setupスクリプト をミラーリング develop master
- 31. Technical Artist Bootcamp 2015 vol.2 使用するbatもSCMで管理 ├─jenkins │ 001_sync.bat │ 101_mirror_setup.bat │ 201_unittest.bat
- 32. Technical Artist Bootcamp 2015 vol.2 隕石が落ちてきても大丈夫 引用：2013年2月15日にロシアで発生した隕石落下の映像 https://www.youtube.com/watch?t=23&v=iCawTYPtehk
- 33. Technical Artist Bootcamp 2015 vol.2 細かなルール
- 34. Technical Artist Bootcamp 2015 vol.2 テキストエディター
- 35. Technical Artist Bootcamp 2015 vol.2 必要な機能 • シンタックスに応じたカラースキーム • 自動補完・タブのスペース化などの言語サポート • マルチバイトエンコーディング • 外部コマンド実行 • できれば、マルチプラットフォーム
- 36. Technical Artist Bootcamp 2015 vol.2 エディタとデバッガー • 導入が楽なので推奨 • PyCharm • MayaのPythonをリモートデバッグ • VisualStudio + PTVS • PyCharm • VisualStudio + PTVS • Sublime Text • Vim
- 37. Technical Artist Bootcamp 2015 vol.2 pymel • maya.cmds禁止 • 結果がすべて文字列で返ってくる • 独自ラッパークラスだらけになってしまう • pymelはMELとAPIをうまく組み込んだクラスを定義してくれて いるので非常に使いやすい • ただし • ジオメトリを頂点単位で処理する等ループが多数発生するツール、またはAPIメソッ ドによりUndoが困難な処理は素直にC++で書く • アトリビュートのシフト演算子（>>,<<）は使用禁止
- 38. Technical Artist Bootcamp 2015 vol.2 Qt • GUIはすべてQt（PySide）で作成する • .uiファイルをQtDesignerで作成 • レイアウトのみ • シグナル関連はpythonコードで定義（.uiと.pyに分散してしまうのを防ぐため） • 再利用可能な最小単位で.uiを作成 • ダイアログ • リストアイテム • .pyに変換してから使う
- 39. Technical Artist Bootcamp 2015 vol.2 共有ライブラリの例：デコレータ
- 40. Technical Artist Bootcamp 2015 vol.2 デコレータとは？
- 41. Technical Artist Bootcamp 2015 vol.2 @keep_selection
- 42. Technical Artist Bootcamp 2015 vol.2 関数が呼び出される前後の処理を定義 • セレクション状態を元に戻す • 単位(unit)を元に戻す • UndoChunkを管理する • 例外をキャッチしてダイアログ表示したりログに保存したり • 等々・・・応用範囲は非常に広く、共有しやすい。
- 43. Technical Artist Bootcamp 2015 vol.2 with文で使うコンテキストも便利
- 44. Technical Artist Bootcamp 2015 vol.2 コミュニティ
- 45. Technical Artist Bootcamp 2015 vol.2 モジュールに不具合があったら自分で直す
- 46. Technical Artist Bootcamp 2015 vol.2 コミュニティへの還元 • pep8.py,simplejsonのBOMサポートパッチ作成 • 実装とテストコードがあれば、英語力が低くても気持ちは伝わる • 無事マージされた
- 47. Technical Artist Bootcamp 2015 vol.2 おまけ
- 48. Technical Artist Bootcamp 2015 vol.2 C++を中心としたチーム開発 • C++11 • noseでpython経由の結合テスト • コードスタイル • Google C++ Style Guide • cpplint.py JavaScriptを中心としたチーム開発 • 環境構築 • Node.js + gulp • コードスタイル • Google JavaScript Style Guide • gjslint • jshint
- 49. Technical Artist Bootcamp 2015 vol.2 まとめ • コミュニティで議論されている規約には乗っかる • 議論の規模が違う • 標準規格に則ったツールの導入 • 徹底した自動化 • コードスタイルチェック • 設定作業の自動化による環境統一 • 内製ツールの動作確認 • 属人性を排除しメンテナンス性を高めることが 新しいチャレンジへの第１歩
- 50. Technical Artist Bootcamp 2015 vol.2 ご清聴ありがとうございました スマイルテクノロジーユナイテッド株式会社 代表取締役社長 高橋涼 ryo.takahashi@smiletechnology.jp
Notas do Editor
- 本日はテクニカルアーティストブートキャンプということで、主にＴＡの方々に少しでも役に立つお話が出来ればということでやってまいりました。 ただ、ＴＡと限定するつもりはなく、デザイナーの方でも、プログラマの方でも少しは役に立つようなネタを持って帰っていただけるように分かりやすく解説するつもりです。 ３０分という限られた時間ですので駆け足になるかもしれませんが、どうぞよろしくお願いします。
- 最近はＴＡというセクションの認知度も上がり、優秀なＴＡの方も増えてきたように感じます。 Mayaのスクリプト・プラグインを作って作業の効率をアップさせるというのは、ウェブ上の情報や書籍も増え、敷居がだいぶ下がってきました。 しかしながら、メンバーが１００名を超えるような大規模プロジェクトにおいては、開発したツールを使用する人数は非常に多く、また使用期間も長くなります。 作って終わり、ではなく、継続的に仕様変更・機能追加を行っていきます。 気が付くと同じツールの改良ばかりで、新しいツールの開発してなくて、フラストレーションを感じるということもありました。
- 数年前まで会社員をしておりましたが、そのころ、ツールプログラマチームで開発を取りまとめていました。 大規模なツールを開発する必要がある場合は複数のツールプログラマを集めて対応していました。 私自身もプログラマとして作業に当たっていたのですが、どうにもやりにくい。 進めば進むほど、「この機能は誰々さん担当だから」 「あの人手が早いからこれもやってもらおう」などと、メンバー毎の作業量にばらつきが出てきたり、 助けようと思ってもソースコードが読めなくて断念したり、そういうモヤモヤすることが多かったように感じます。 もちろん、全員が全力を出した結果です。 さきほどのツールメンテナンスのフラストレーションと、この、大規模ツール開発のやりにくさ、 この二つの問題は、同じ原因なんじゃないかなぁ、と推測しています。
- これらはすべて、属人化がもたらしている弊害なのだと思います。 作業負担がかたより、あるひとはずっといそがしい。その結果、手が足りなくて永遠に放置されるバグが現れたりします。
- 私はＴＡに必要な素質とは、 アイデアと実行力だと考えています。 アイデアはどこからくるのか？ 実行できるスキルと時間はどうやって捻出するのか？ 今回お話しするのは、保守可能なツール開発を継続的に行うために策定している弊社のルールについてになります。
- 弊社で行っているルールなどを、Mayaのツール開発を中心にご説明していきます。
- まず、大前提になりますが、本日のタイトルにも入っているように、できるだけpythonで作成することにしています。 プログラム言語というのは他にも選択肢はあるとは思うのですが、特に理由がない場合はpythonを自然に選択します。 結果、95%くらいPython。
- このような内訳になります。 こういった足しに渡るプログラム間で、サードパーティ製モジュールやデバッガーが使え、自分のコードの共有もできます。 特に3DCGアプリケーションは幸いなことにpythonをサポートしているものがほとんどなので、かなりの共有が行えます。 たとえば、 ファイル名のチェックを行うコードをすべてのアプリケーションで使いまわせます。
- 前半で、根幹となるルールを説明します。 後半は時間のある限り、tipsを紹介できればと思います。
- まずはツールの管理方法になります。 SCM、いわゆるバージョン管理システムでツールを管理しています。 プロジェクトにもよりますが、GitかPerforceで管理しています。
- 絶対にファイルサーバーを直接参照して共有してはいけません。 ツールに不具合が混入すると全員に影響してしまいます。バージョン管理ツール経由であれば、落としてこなければ即座には影響しませんし、バグが発見されたらひとつ前のリビジョンを取得しなおせば作業が止まることは避けられます。 また、ファイルサーバーは遅いです。
- 図で表すとこのような形で管理しています。 master リリース用 develop 開発作業用 の二つのブランチで運用します。 こういった複雑なやり取りを行うので、リビジョン追跡がまともな、バージョン管理システムが必要になります。 一般的にはこの二つになります。データ管理も同時にしようと思ったらperforce１択になります。
- シンプルなディレクトリ構成の例です。 Photoshopの中はmayaと似た構成です。ツールに必要なファイルと、testsuiteディレクトリがあります。 Setupは初期設定用のファイルなどが入ります。 これらが丸ごと、masterとdevelopブランチに存在します。 では、Setup/に何を格納するのかという話をします。
- さて、SCMを使うことで、コードの反映とリリース環境が整いました。 必要なサードパーティ製モジュールのインストールも自動化が必要です。 サードパティ製のモジュールもバージョンを統一して自動化しないと、動作が一致しません。 不具合が発生した場合も再現性がなくなってしまいます。 Pipというパッケージ管理ツールが標準化されていますのでそれを使用します。 SCMで管理するのは、 requirements.txt 各種wheelファイル になります。
- モジュールはpypiから直接インストールしてもいいのですが、wheelファイルが用意されていないモジュールや、Maya向けにマニフェスト情報を修正したモジュールはローカルにwheelファイルを用意しています。
- これらをバッチファイルにまとめておき、setupに格納しておきます。必要なrequirements.txtとwhlファイルも格納しておきます。 これでバッチファイルのダブルクリックだけで、ユーザーも開発者も同じpython環境にできます。
- 読めるコード 人それぞれのスタイルで書いていたのでは読みづらくて仕方がない。 プログラムのソースコードは、書くよりも読まれる回数が多いということを前提に、Pythonは可読性を重要視しているプログラム言語です。この点も気に入っているところです。 Pythonの推奨スタイルはPEP8という名で定義されています。 弊社ではPEP8を基本にしています。 このようなスタイルのことです。 これはダメ、これは良い。 世界標準に乗っ取ることで、スタイルチェッカーもオープンなツールを使用することができます。 pep8.py です。 修正作業に取り掛かる際にはまずは読むところから始めます。
- テストコードを義務としています。 まず弊社ではテストコードのないツールはリリースを禁じています。 なぜか？ ツールというものは作って終わりということがあり得ないからです。 不具合が起こって修正作業が必要な場合もあれば、 新しい機能を追加することもある。 これは言い切っていい、確実に改変と動作確認は発生します。 世の中には動作確認をせずにリリースしてしまうワイルドな方もいらっしゃいますが、それは論外として、、、 なんども動作確認が必要になるからです。 つまり、同じことを何度も何度も行う必要があるからです。 そもそもツールってどうして作ってるんでしょう？ 多くの場合、自動化が目的ではないでしょうか？ しかし、動作確認は自動化しないなんてナンセンスです。 手作業で動作確認しているようなアナログな人はテクニカルではない。 簡単なテストコードの例と、Maya上での実行方法をお見せします
- 手作業の動作確認で行っていることをコードに落とし込むだけ！ 同じような手順が多いので、コードの再利用で簡略化
- ライブラリの単体テスト ツールの結合テスト 慣れてしまえばいいのだが、めんどくさいのは事実。人間だれしも自分は失敗しない、不具合なんて発生させない、と信じてしまうもの。めんどくさいです。 ですので、簡単に済ませたい。 正しい結果のジオメトリ情報をJSONファイルにダンプしておけば、単純なデータの比較で済ませてます。 ジオメトリ情報を詳細に出力するツールを作って使いまわし。 法線の編集ツールのテストだが、うっかりＵＶが変更されてしまっている、ということも防げる。
- テストコードによって手作業の動作確認は無くなりました。 しかし、ライブラリを共有することで、予想外の不具合発生も考えられます。 自動でテストするようにしないと、せっかくのテストコードが無駄になることもあります。 私も過去、このツールはもう使うことがないからテストも回す必要ないだろう、という思い込みにより、痛い目にあったことがあります。 半年ほどしてまた使うということになった際に、他のツールやライブラリの度重なる仕様変更によりまったく動かなくなっており、修正個所が膨大な数になっていて使えるようになるまで時間がかかってしまったということがありました。 仕様変更のたびに修正していれば簡単な話だったのに、積もり積もったことによって大変な思いをしたわけです。 自動化は必須です。
- 今はjenkinsというオープンなツールがありますので、これを使用することが多いです。 例です。 Gitリポジトリを１時間おきにチェックし、 ・setupスクリプトをファイルサーバーにミラーリングするジョブ ・全てのテストコードを実行する ・すべてのソースをflake8でチェック ・データ解析 というジョブを仕込んであります。 先ほどお見せしたMaya上でのnose実行ですが、jenkinsに実行させる場合はmayabat.exe経由で実行します。 これにはもう一つ恩恵があって、ウッカリミスとしてよくあるのが、ハイパーシェードに紐づくmelコマンドをスクリプトで使用してしまうという例です。 ハイパーシェード関連ＭＥＬコマンドはＧＵＩが無いと使えないので、バッチ処理に対応していません。Mayabat.exe経由で実行することで、そのエラーを検知できます。
- 001_syncではjenkinsプラグインのp4やgitで同期し、子供ジョブを呼び出すようにしています。 セットアッププログラムのミラーリング、ユニットテストも同じですが、バッチファイルに行う処理をすべて書いておき、SCMで管理します。 ユニットテストであれば、先ほど出てきたnosetestsコマンドが書いてあるわけです。
- ここまでやれば、属人性はかなり薄れています。 隕石が突然オフィスを破壊したとしても、開発作業を継続できることでしょう。 気兼ねなく飲みにも行けるし、親の死に目にも会えます。
- 言わないととんでもないエディタで作業してる人がいるのでこれにも触れないわけには行けません。テキストエディタについても推奨しています。
- 私が考える、まともなエディタとは シンタックスに応じたカラースキーム 自動補完 タブのスペース化などのpythonサポート マルチバイトエンコーディングサポート PEP8などのチェッカーを実行できる できれば、マルチプラットフォーム といった機能を持っているのが条件になります。 PyCharm VisualStudio + PTVS Sublime Text Vim
- Pythonのおかげでデバッガーを使えることも大きな恩恵の一つです。MELではprint文デバッグしかできませんでした。 基本的にはPyCharmをおススメ。エディタも兼ねているので導入が楽。 VisualStudio + PTVS Maya等リモートデバッグをする際に必要 このあたりまでがガチガチに固めているルールになります。
- Maya.cmds禁止 なぜか？ Pymelはよりpythonicであると言ってます。 文字列が返ってきてしまう。 クラスのインスタンスで返ってくるので、そのままインスタンスメソッドとして各種MELコマンドやAPIメソッドを呼ぶことができるため、オブジェクト指向的と言えます。 ただし 頂点単位の処理等、ループが多数発生するツール メッシュのジオメトリ情報を変更するツール はC++でプラグイン化するようにしています。
- すぐにでも取り入れて欲しいのがデコレータライブラリの導入です。 Mayaのスクリプトで面倒なんだけどやらないと不便な処理として UndoChunk管理 セレクションの復元 エラーメッセージのウインドウ表示 などがあるかと思います。
- ここまででチームでの取り組みを説明してきましたが、すべては個人スキルを延ばし、想像もしないような新しい発想をもってツール開発を行うためです。 コミュニティからの恩恵と、コミュニティへの還元を行いたいから
- プログラムのスキルを上げるには プログラムを読む プログラムを書く これしかありません。 良質なプログラムを読むことで、様々なテクニックを学ぶことができます。 Pythonやライブラリは広くコミュニティで使用されているため、コードが洗練されているものが多いです。 コードを読み、不具合を修正する、ことでスキルアップ
- Pythonを使うことで、Python自体もそうですが、オープンなライブラリによる恩恵を受けることができます。 これもPythonを使うメリットです。 コミュニティに還元しましょう。 弊社では pep8 simplejson BOM対応の修正パッチを送っています。 BOMとはバイトオーダーマークの略なんですが、UTF-8で書いてあるテキストファイルの先頭に付く数バイトのデータです。これによりUTF-8エンコードであることが分かるようになっているのですが、マルチバイト圏の人しか使うことがないため、英語圏の方々はサポートしてくれていないことが多く、私は気づくたびに修正してパッチを送っています。 Githubによって修正からパッチ送付までが非常に楽に行えるようになっています。 テストコードの恩恵はここでもあり、ソースコードとテストコードがあれば、何が不具合で、どう直したか？が伝わります。英語力が低くても何とかなってしまいます。
- Pythonを中心に話してきましたが、現実問題として、Pythonだけを使ってすべてのツールを賄えるわけではありません。 プロジェクト開始時に使用するセットアップスクリプト等は当然Pythonのインストールを行うことも含まれますのでPythonスクリプトでは書けません。まだインストールされていません。 そのためそのようなセットアップスクリプトは、Windowsにおいてはバッチファイルやexeファイルにするしかないわけですが、弊社ではWindowsScriptHostを選択しています。従ってJavaScriptで書くことになります。 また、先ほど触れたように、頂点単位の処理等、ループが多数発生するツールについてはC++でプラグイン化することを現時点での最善策としています。 JavaScript、C++についても規約を設けています。
- この結果、時間ができるはず。 アイデアを得る時間もできます、実行力を発揮できるだけの時間もできます。