yumetodoの旅とプログラミングとかの記録

旅や登山の記録やプログラミング関連の話とかフリーソフト紹介とか

書きかけ:TsuboneSystemを試しにWindows10環境のlocalで動かしてみよう

node.jsとnpmの導入

更新の激しいnode.jsの導入をまさか公式のインストーラでやる輩はこの世に存在すまい。当然バージョン管理ソフトを使うべきだ。 Windowsだとnvmは利用できない(後述のmsys2上でもnvmのインストールはできるがそこからnode.jsをインストールできない)。というわけで

qiita.com

nodistを使う。まあnvm for Windowsでもいいのだが。

コマンドプロンプト

nodist dist

とすると、提供されているバージョンを一覧で表示できる。

nodist + latest

とすれば最新版が手に入る。執筆時点ではnode.jsは7.9.0が最新だった。あとは

nodist use latest

とすれば最新のnode.jsが利用できる。注意点として、どういうわけかpowershellで動かすとうまくいかない

そのままの勢いでnpmを最新にする。

npm update -g npm

これでよい。

MSYS2

  1. 7-Zipを落とす
    https://sevenzip.osdn.jp/
    より64bit版もしくは32bit版を
    既に入っている人も、2015/11/19に随分久しぶりに最新版が出たのでバージョンを上げるといいです
  2. 7zipをインストール
    ダブルクリックして実行すればいいです。
  3. msys2を落とす
    http://sourceforge.net/projects/msys2/files/Base/
    よりお使いのアーキテクチャ(おそらくはx86_64)をクリックしmsys2-base-[アーキテクチャ]-[日付].tar.xz を。exeの方は1回も使ったこと無いのでわかりません。
  4. 7-zipで解凍
  5. msys2_shell.cmdをダブルクリック、Close Windowと言われたらばってんを押して閉じる
  6. 再びmsys2_shell.cmdをダブルクリック、pacman -Syuuと打ち実行、また閉じる
  7. 再びmsys2_shell.cmdをダブルクリック、pacman -S mingw-w64-i686-clang mingw-w64-x86_64-clangとと打ち実行、また閉じる
  8. pacman -S base-devel mingw-w64-i686-openssl mingw-w64-x86_64-openssl mingw-w64-i686-go mingw-w64-x86_64-go gnupgする

そうしたら~/.bashrc

export GOROOT=${MINGW_PREFIX}/lib/go
export GOPATH=$HOME/.go

を追記します。GOPATHはまあどこでもいいんですが。

Tsubone System3を取ってくる

mingw64_shell.batを立ち上げ(なかったらmsys2_shell.cmd -mingw64)

$ go get -d github.com/kagucho/tsubonesystem3/
$ cd $GOPATH/src/github.com/kagucho/tsubonesystem3

する。この時、$GOPATH/src/github.com/kagucho/tsubonesystem3Windowsから見たパスを調べておく。

MariaDB

Download

まずはインストーラーを取ってくる必要がある。

今回はMariaDB 10.1.22 Stableを利用する。

Downloads - MariaDB

Downloads - MariaDB

からmariadb-10.1.22-winx64.msiをDownloadする。

GnuPG署名検証

Checksumをクリックして、GnuPGの署名をコピーし、mariadb-10.1.22-winx64.msiと同じ場所にmariadb-10.1.22-winx64.msi.sigとかしてテキストファイルを作り貼り付ける。

次にMariaDBのGPG公開鍵を取ってくる。

https://mariadb.com/kb/ja/yum/#mariadb-署名鍵を手動で取り込むmariadb.com

にURLだけ載っているので、MSYS2を立ち上げ、

$ wget https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
$ gpg --quiet --with-fingerprint RPM-GPG-KEY-MariaDB

とする。

pub  1024D/1BB943DB 2010-02-02 MariaDB Package Signing Key <package-signing-key@mariadb.org>
 フィンガー・プリント = 1993 69E5 404B D5FC 7D2F  E43B CBCB 082A 1BB9 43DB
sub  4096g/672557E6 2010-02-02

このフィンガープリントが

https://mariadb.com/kb/ja/gpg/

と一致していることを確認する。

そうしたら

$ gpg --import  RPM-GPG-KEY-MariaDB

として鍵を取り込み、

$ gpg -u <自分の公開鍵のid> --sign-key package-signing-key@mariadb.org

で署名する。自分の公開鍵のidは

$ gpg -k

すると

pub   4096R/FE05ED49 2017-03-23 [有効期限: 2019-03-23]
uid                  yumetodo <yume-wikijp@live.jp>
sub   4096R/830A7319 2017-03-23 [有効期限: 2019-03-23]

のように出て来るがこの場合FE05ED49がそれだ。ない場合は

http://qiita.com/moutend/items/5c22d6e57a74845578f6qiita.com

この辺を見て作る。

さて、これで署名検証する準備ができた。Downlaodしたインストーラーのある場所に行く

$ cd <where you downlaod installer>
$ gpg --verify mariadb-10.1.22-winx64.msi.sig mariadb-10.1.22-winx64.msi
gpg: 2017年03月14日 05時37分47秒 JSTにDSA鍵ID 1BB943DBで施された署名
gpg: 信用データベースの検査
gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、PGP信用モデル
gpg: 深さ: 0  有効性:   2  署名:   1  信用: 0-, 0q, 0n, 0m, 0f, 2u
gpg: 深さ: 1  有効性:   1  署名:   0  信用: 1-, 0q, 0n, 0m, 0f, 0u
gpg: 次回の信用データベース検査は、2019-03-23です
gpg: "MariaDB Package Signing Key <package-signing-key@mariadb.org>"からの正しい署名

検証終了だ。

Install

基本的には

mariadb.com

を見てインストールするべきだ。

インストールパスを変更したい場合はここでやる。

MariaDBの管理コンソールのrootユーサーのパスワードを設定する。好きなものを入れればいい

あとUse UTF8 as default server's character setは軽くググッた感じONにしたほうがいい気がする(あとで変えられそうだったのでまあ大した問題じゃないはず)

Port番号が3306とMySQLのWell Known Portになっているのは、MariaDBMySQLのforkだからだろうか。

DBの作成とデプロイ

まずはMariaDBのコンソールを立ち上げる。

私はWindows10のスタートメニューに耐えきれずにClassic Shellを入れているがまあMariaDBで検索すれば見つかるだろう。

CREATE DATABASE tsubonesystem;

する。;を忘れずに。

今度はCommand Prompt (MariaDB 10.1 (x64))を立ち上げて、$GOPATH/src/github.com/kagucho/tsubonesystem3Windowsから見たパスに移動する

"D:\Program Files\MariaDB 10.1\bin\mysql" -uroot -p tsubonesystem < test.sql

とするとデプロイできる。

msys2でnode.jsを使えるようにする

これが難儀した。まずmsys2のパッケージ管理システムであるpacmanで取ってこれるところにmingw-w64-x86_64-nodejsがある。これを利用すればいいと思うかもしれないが、まずnode.jsのバージョンがまだ6.x系だった。しかしそれが問題なのではない。ここでnpmを使おうとしてmingw-w64-x86_64-npmを入れようとしたら、そんなものはないという。

github.com

次にmsys2ならnvm使えるのでは?と思ったが、冒頭に書いたようにそうも行かない。

したがって、Windowsに普通にInstallしたnode.jsを利用することにした。

まずコマンドプロンプト

where node

とする。これでどこにnode.jsがインストールされているかわかる。私の場合は

C:\Program Files (x86)\Nodist\bin\node.exe

と表示されたのでC:\Program Files (x86)\Nodist\binにある。

次にmsys2のPATHにここを追加する。~/.bashrc

export PATH="/c/Program Files (x86)/Nodist/bin":$PATH

を追記してさらに、

$ cat "$NODIST_PREFIX/bin/nodist_bash_profile_content.sh" >> ~/.bashrc
$ source ~/.bashrc

としてnodistを呼べるようにしつつ反映する。

注意点として、まれにnpm -g系のコマンドが上手くいかないことがあるので、globalをいじるのはmsys2のbashからではなくコマンドプロンプトからやるほうが無難である。

build

msys2のshellで

$ cd $GOPATH/src/github.com/kagucho/tsubonesystem3
$ make prepare
$ make

する。

それから

どうすればいいんだ?ブラウザで検証したいんだが・・・

CMakeからVisual Stduo 2017でコンパイルしたBoostを探すのは時期尚早かも

Visual Studio 2017がリリースした

さて、Visual Stduo 2017が出てすでに1ヶ月経った。私も重い腰を上げて導入した。

www.visualstudio.com

をみると割りと頻繁にアップデートが来ていたりする。

Visual Studio 2017でBoost 1.63.0をコンパイルする

現在Boostの最新はBoost 1.63.0だ。しかしこいつは2016/12/26に出ており、2017/3/7に出たVisual Studio 2017に対応しているはずもない。

[Boost-users] Building Boost 1.62 With Visual Studio 2017 RC - Google グループ

そこでちょっと小細工をする。Boostのソースをダウンロードして展開した時にroot directoryにproject-config.jamがあると思うが、これを書き換える。パスは適宜読み替えてほしい。

x86向け
import option ; 
 
using msvc : 14.1 : "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\cl.exe"; 
 
option.set keep-going : false ; 
 

のように書き換えて

b2 toolset=msvc-14.1 threading=multi variant=debug,release link=static runtime-link=static address-model=32 --stagedir=stage/x86 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"
b2 toolset=msvc-14.1 threading=multi variant=debug,release link=shared runtime-link=shared address-model=32 --stagedir=stage/x86 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"

の用に実行する

x64向け
import option ; 
 
using msvc : 14.1 : "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe"; 
 
option.set keep-going : false ; 
 

のように書き換えて

b2 toolset=msvc-14.1 threading=multi variant=debug,release link=static runtime-link=static address-model=64 --stagedir=stage/x64 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"
b2 toolset=msvc-14.1 threading=multi variant=debug,release link=shared runtime-link=shared address-model=64 --stagedir=stage/x64 -j 4 -s BZIP2_SOURCE="D:/lib/bzip2-1.0.6" -s ZLIB_SOURCE="D:/lib/zlib-1.2.11"

の用にコンパイルします。

ちなみに、Boost1.64.0 Beta2ではproject-config.jamをいじらずとも対応しているそうです。

Visual Stduo 2017のcl.exeのバージョンは?

Visual Stduo 2017は当初cl.exeのバージョンが15.xになると思われていました。しかし、Visual Studio2015付属のcl.exeとの間でバイナリ互換になったため、14.10.xになりました。

github.com

CMakeからBoostを使う

には、find_packageを使うのが一般的です。

FindBoost — CMake 3.7.2 Documentation

CMakeの最新は3.7.2です。早速使ってみましょう

# find Boost
set(BOOST_ROOT ${BOOST_ROOT} CACHE PATH "Set boost root directory" FORCE)
set(BOOST_LIBRARYDIR ${BOOST_LIBRARYDIR} CACHE PATH "Set boost library directory" FORCE)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_STATIC_RUNTIME OFF)
set(Boost_DEBUG ON)
set(boost_required_components
    system iostreams thread
)
find_package(Boost 1.59 REQUIRED COMPONENTS ${boost_required_components})
CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1812 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.63.0

  Boost include path: D:/lib/boost_1_63_0

  Could not find the following static Boost libraries:

          boost_system
          boost_iostreams
          boost_thread

  Some (but not all) of the required Boost libraries were found.  You may
  need to install these additional Boost libraries.  Alternatively, set
  BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
  to the location of Boost.
Call Stack (most recent call first):
  CMakeLists.txt:41 (find_package)

見事エラーになります。

CMakeがコケる原因
set(Boost_DEBUG ON)

して調べたところ、

[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1291 ] guessed _boost_COMPILER = -vc150

というDebug Printが。ん?-vc150

https://github.com/Kitware/CMake/blob/v3.7.2/Modules/FindBoost.cmake#L429-L431

  elseif("x${CMAKE_CXX_COMPILER_ID}" STREQUAL "xMSVC")
    if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.10)
      set(_boost_COMPILER "-vc150")

上に書いたように、cl.exeのバージョンは14.10.xなのでこれはおかしいです。このせいでboost_xxx_-vc150-mt-yyy-1_63を探しに行っていたようです。そりゃ見つかるわけ無いわ。

改善の予兆

CMake3.8.0-rc3ではこの問題が治っているようです。該当commitは

github.com github.com

結論

もうちょっとだけいろいろ待ったほうが良さげ

と言いたいところだが、待てない。

github.com

if(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 3.8)
    set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake/modules)
    include(FindBoost)
    message(STATUS "FindBoost: commit fb3f6fd3fe8eb2ebef26c6fa20624f32ee272760 is used.")
endif()

のようにしてcmakeのmaster branchから最新のFindBoost.cmakeを拾ってきた。

多分cmake3.8になれば解決しているはずなので一時的なwork aroundなのでcmakeのバージョンを見て分岐する。

あと、Boost_USE_DEBUG_RUNTIMEがOFFのとき、lib検索にバグがあるので

gitlab.kitware.com

CMake3.9.0まで待つか自分でFindBoostを引っ張ってくるべきでしょう。

追記

いつの間にかBoost1.64.0もcmake3.9.0も出ていますね。

内容メモと感想:【第1回PFLabフォーラム】自動運転からスパコン×Deep Learning、メニーコア×OS、ゲームAI、Xamarinまで豪華な内容盛り沢山!

タイトルの通り、PFLabフォーラムに行ってきた。

atnd.org

私は新宿税務署でアルバイトをしていて13:00まで新宿に拘束されていたので、加藤真平准教授による自動運転とベンチャー起業のお話は聞けなかった。

盛り上がりに欠けるというだけで呼ばれるちょまどさんと三宅さんぇ・・・

高精度3次元マッピング

自動操縦に必要なもの
  1. 周辺地図の構築
  2. 自分の位置の推定(localization)
  3. 行動計画
  4. Act!
三次元地図

→点群

すでに持っている3次元点群と新たに得た点群を重ね合わせる

How?

  • ICP
    すべての点群について計算→重い
  • NDT
    ボクセル(点群の小規模な部分集合)同士の位置合わせ(平均(傾向)・分散共分散行列(ばらつき))

やったこと

NDTの研究

インクリメンタルな地図登録

全部のボクセルを再計算する必要はないよね

従来のNDT : O(n):地図の点群数∝地図登録時間
インクリメンタルなNDT: O(1): 地図登録時間は一定

不均一なボクセルの更新

ボクセル内の点群がある程度貯まると、それ以上増えても平均・共分散に影響が少なくなる
→それ計算しなくてもいいよ!
→更新破棄

1msec程度の削減しかできなかった

モリーキャッシュが壊れそうなアルゴリズムだからまああんま早くならないだろうなぁ。

展望
  • 地図構築をGPU
  • ボクセルの大きさは不均一でもいい? # なんかNext HEVCみたい
  • ドローンで地図作ろう

ボクセルの大きさは不均一でもいいというのは、
rigayaの日記兼メモ帳 技研公開 2016
NHK技研でHEVC(今もっともよく使われているh.264の次世代のh.265のこと)の次世代コーデック開発で、 http://blog-imgs-104.fc2.com/r/i/g/rigaya34589/Giken2016_09s.jpg

圧縮の際の分割ブロック制御で似た話があったなぁ。


自動運転データストリーム

うん、私も???ってなりながら聞いてた。最後の方になってなんとなくわかったけど。

LiDARデータ: 360度回転画像を1frame
自己位置推定に使われる

→点群に変換

  • 地図とマッチング
  • 地図生成
  • etc

LiDARからRGB画像から抽出した物体までの距離を算出

Bagデータとして(生データ)収集

ーDeep Larningに流し込みにくい

変換ツールが必要やろ!

  • 撮影画像
  • Depth可視化画像

動画+LiDARでブレーキ予測できるか実験


Deep Larning

並列化された畳み込みニューラルネットワークのスケーラビリティに関する研究
→ # とは

ニューラルネットワークの大規模化

  • ResNet: 152層

CNN: 畳み込みニューラルネットワーク

パターン認識に特化

ちょっとこの辺は知識不足なので


この辺をあとで読もうを思っている。

→並列化したらうまく動くの? # GPUのほうが並列しているのは?

複数データの同時学習

  • Lowering Convlolution
  • 複数CPUでの学習

HTTとOpenMPとMPI

畳み込み層→重い
出力pixelごとに内積計算するから重い
→ Lowering Convlolution
→ 行列化→それは早い→行列生成がメモリーネック・浮動小数点演算→辛い

pipelined Lowering

細分化

特定の条件下でLowering < Pipelined

Lowering: 6倍
pipelined Lowering: +10% boost

マルチノード化で64並列で46倍


メニーコア

大体のCPUはせいぜい4Core

せいぜいみんなCoreは4つでしょ?Intel Xeon Phiなら>64 Core/ 256 threadやで

2g: 2次元メッシュアーキテクチャ

タイル→正方形状にネットワークにつながっている
タイル同士が通信

でも既存のOSじゃだめやろ!
→よろしいならばフルスクラッチ

まあメモリー管理はOSがやるべき仕事だからわかる。

github.com github.com

スピンロック

並列化するとどんどん遅くなる
→改善アルゴリズム(TTC, HCLH, etc…)多数→検証中

具体的には?
タイル内のロックは低コスト→どんどん使う

展望

高速計算以外でも使わないとアーキテクチャが死ぬ

  • 広帯域IO
  • 低消費電力


人工知能が拓くゲームの未来 - FINAL FANTASY XV が見せる人工知能の世界 -

ゲームAI
人工知能学会誌読もう

FINAL FANTASY XV

仲間、自然、モンスターがAIで動く

  • ルールベースのAI
  • プレイーやーの意思を読むAI
  • 自分の体の認識

現代は知能革命の時代に入りつつある

かつてはAIはゲームシステム内にあった

現代:

  • メタAI(予定調和)
  • キャラクターAI
  • ナビゲーションAI

が協調

AI量産のために

Luminous AI アーキテクチャを作った→アカデミックと違う

  • Luminous AI Graph
  • Luminous Navigation

単一の意思決定は十分でない
複数の意思決定を組み合わせる

→ロボットに適用

メタAI

体がない

映画監督

仲間同士で強調して動作したい

プレイヤーが寂しくないように

ex.) - プレイヤーや仲間のピンチを助けよ

キャラクターAI
  • 知能(AI graph)
  • 身体(ボディ・レイヤー)
  • アニメーション(AnimGraph)

の3つ

AnimGraphというツールでnode(それぞれモーション)を繋いでモーションのブレンド

環境世界 –{センサー・体}–> 知能世界(思考(認識の形成、意思決定、運動の構成)と記憶) –{エフェクト・体}–> 環境世界

  • 有限ステートマシン
  • 階層型ステートマシン

  • ステートマシーン

  • behavior tree

→いいとこ取りしたい

ハイブリッド型ノードフォーマット

www.slideshare.net

ステートマシーンのnodeがbehavior tree
逆も然り
Nodeの共有

→組合せ爆発を防ぐ

ナビゲーションAI
  • 地形を解析
  • 目的におおじた点を見つけ出す

目的地までのパスをを計算する

  • ダイクストラ法(同心円探索)
  • A*(スター)法(指向性探索) → 99%こっち

ナビゲーションメッシュ 地形の情報に合わせて歩ける部分のみ表示

スマートウェイポイント

3次元パス検索

立方体メッシュ(ボクセル化)→焼きなまし法で結合→A*アルゴリズム動かす→立方体のどこを動くか→さらに検索

戦略位置検出システム

自分の能力に合わせてポジショニングするシステム Point Query System

ステアリング
衝突回避
行きたい方向の空間の空きを見る
相互回避

移動モーション解析

  • 止まるときに現在の速度で停止までにかかる時間
  • 旋回性能

よなよなモンスターが頑張ってる

アンビエントAI

街にいる群衆を作る

オブジェクト側に知能を持たせる

キャラクターが近くに行くとキャラクターが操られる

オブジェクト: 情報発信

【会誌発行】人工知能学会誌 Vol. 32 No. 2 (2017/03) – 人工知能学会 (The Japanese Society for Artificial Intelligence) 表紙解説「ファイナルファンタジーXV


XamarinとMicrosoft Azure

Microsoft社の松屋宣伝担当・・・じゃなかった、テクニカルエバンジェリスト兼マンガ家の千代田まどか(ちょまど)さんの発表です。
特にメモ取る内容ではなかったというかツイート実況してたので以下ツイートまとめ。
ちょまどさんに実際に会うのはこれが初めてでしたが、某友人から「こいつはだめだ」みたいな話を聞いていたのでぶっちゃけそこまで期待してなんていなかったんだからねっ!(ツンデレ

内容的には blogs.msdn.microsoft.com に近い感じ。

な、なるほど?(わかっていない顔

セッションの説明 登壇者紹介

今日話すこと4つ

C#とは

暗黒の進化笑う。しかもその説明があながち間違っていないからあれだ。

私はF#知らない勢なのでfmfmという感じ

おまえらdynamicあるやん、という思い

ここでコンソールアプリケーションの説明で「コマンドプロンプト」という名前をど忘れしたちょまど氏。

C#をどんな言語かを見せるためにライブコーディングが始まりました。

REST API叩けばAsync/Awaitとかも見せられるから題材としては適当だよね。

www.infoq.com

本の虫: C++標準化委員会の文書のレビュー: P0022R1-P0092R1

[PDF] P0057R1: Wording for Coroutines

コルーチンの文面案。変更点は、とうとうキーワードが決定されたこと。co_await, co_yield, co_returnになった。なんだか泥臭い名前だ。しかし、await, yieldなど使えるわけがない。

future<void> g()
{
   std::cout << "processing f" << std::endl ;
   co_await f() ;
   std::cout << "resumed" << std::endl ;
}

うーむ。バイク小屋バイク小屋。

ちょっとここまでの講演に圧倒されて危機感を覚えたちょまどさんが慌てて追加した内容っぽい。

MRのほうがVRより古いって本当か?

Virtual reality - Wikipedia Mixed reality - Wikipedia

見ている感じそういう印象は受けないが・・・。

Xamarinのお話

ここで私の友人がXamarinのバグと戦った話を紹介しておきましょう。

Xamarin.Forms または私は如何にして心配するのをやめてバグを愛するようになったか — 173210's Blog

Xamarinとは

  1. 神奈川県座間市マスコットキャラクター
  2. 開発環境

ちょまど「名前空間の汚染が激しい」

ざまりん

Visual Studio 2017

Azure

内容的には

blogs.msdn.microsoft.com

のお話。

MBaaS

ここでプロジェクターが唐突に死亡する事件発生


終了

@meitel1014 (阪大勢) @blessingyukiとお話しつつ、ケンタッキーのチキンとミスドのなんかを食べつつして、その後3人で御茶ノ水まで歩いて各々帰りました。


感想

ちょまどさんのいいようではないけど、思ってたよりアカデミックな感じでびっくりした。

Deep Learningの話は予備知識がたりなさすぎて???ってなってたけど、3Dマッピングのあたりはなんとなく理解できた。

ゲームAIの話は、AIを考えるのはデザイナーの仕事なんだな、というのに驚いた。まあ結果AIを書くためのツールを作ったという話があったけど、そのツールそのものがかなりの価値があるんじゃないか、という思いだった。

ちょまどさんの発表は・・・、まあせっかくAzureの試用ライセンスもらったので使ってみようかなと思っています。