Windows 10 自動アップデート後の悪夢：画面真っ黒でマウスカーソルのみ

2010年頃に自作した古いほうのパソコンを一昨日 2019/4/22 久しぶりに起動した。

• マザー：Gigabyte 890GPA-UD3H (Rev 1.0)
• ＣＰＵ：AMD Phenom II X6 1055T (125W)
• メモリ：CORSAIR xms3 (2GB*4枚)
• グラボ：RadeonHD 6850
• ＳＳＤ：Crucial CT500MX200SSD1

ハードはSSDへの換装を除いては 9年前の構成のままだが、数年前の Windows 10 無償アップグレード期間中に Windows 7 からアップグレードしており、つい先日（多分 2019/4 上旬）までは、まったく普通に動作していた。

tombi-aburage.hatenadiary.jp

ところが一昨日 2019/4/22 から、まともに利用できなくなった。

最後に利用した時には、Windows Update がたくさん貯まっていて、全然適用が進まないので、とりあえず夜中じゅう電源を切らずに放置したのだが、朝起きてみたら

• ブート中に NO DISK エラー（ブートディスクが見つからない）
• 再起動したら今度は NTFSエラー（ブルースクリーン）

など、かなり致命的なエラーを連発しはじめて、遂にはまともに起動しなくなった。

Windowsを初期状態に戻す

BIOSを再設定したり、リセット・電源ボタンを何度か押したりしていたら突如起動するようになった。

BIOSの設定で、ブートディスクをHDD（9年前のマザーボードのためSSDという表現はメニューに存在しない）に設定して起動しても、認識するときとしないときがあったりで、かなり不安定な感じだった。

あまりアプリもデータもないパソコンだったので、Windows を初期状態に戻すことにした。個人用ファイルは少しだけだがあったので、それらは残す設定で初期状態に戻すことにした。

初期状態に戻す間も、上記エラーは何度も出たが、とりあえず再びログオンできるようになり、「こんにちは」あーだこーだの後、使えるようになった。

真っ先に Windows Update の状況を見ると、前回見た時よりも数個、進展していたようだが、まだ残があったので、再び放置して、外出した。

しかし外出先から戻ると、

• ブート中に NO DISK エラー（ブートディスクが見つからない）

Loading Operationg System ...
Boot from CD/DVD :
DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER

のまま、止まっていた。

ハードウェアのリセット（まじない）と削減で起動するようにはなった。

訳が分からないので、古いパソコンでは意外に効くことも多い、まじないモードに突入。

• 主電源を完全にオフ／オン
• 筐体を開けて、ホコリを取ったり、ケーブルのウネリ具合を直したりする
• ブートディスク（ＳＳＤ）を一旦取り外し、電源とＳＡＴＡケーブルを嵌め直す
• キーボードとマウスも外し、起動した後で接続するようにする
• 祈る

その一方で、新しいパソコンの方では Windows 10 再インストール用のUSBメモリの作成もし始める。

ログオンまでは出来るが、パソコンは事実上使用できない。

なぜか利いた。たぶんディスク周りのケーブル嵌め直しが（憶測）。
この作ったばかりのWindows 10 再インストール用のUSBメモリの立場は一体…

Lexar JumpDrive TwistTurn USBメモリ 64GB LJDTT64GABJPR

背景にきれいな絵が出てくるログオン画面は通常どおり表示されたので、ユーザ・アカウントを選択し、パスワードを入力してサインオン。

しかしサインオン後の画面は真っ黒で、マウスポインタしか表示されないという中々に絶望的な状態となっている。タスクバーすらもない。漆黒の画面に白いポインタのみ。

ここで Ctrl - Alt - Del を押すと、ほとんど見えない位、一瞬の間

セキュリティオプションの準備をしています

と水色の画面が表示された後に、

ロック、ユーザの切り替え、サインアウト、タスクマネジャー

および、キャンセル　を選択する灰色の画面となる。
（他に、右下には電源ボタン等もあり）

ここで、

ユーザーの切り替え、サインアウト

は一応機能するが（といっても、別のユーザー・アカウントでログオンしても結局のところ同じ状態になるだけなので依然としてPCは使えない）、タスクマネジャーに至っては何も機能しない。

右下電源ボタンでの再起動は一応可能であり、Shift キー + 再起動（トラブルシューティング）を選択することはできるため、「スタートアップ修復」「スタートアップ設定」（セーフモード起動）などは行える。

参考になりそうな記事あり、しかし利かず…

freesoft.tvbok.com

の

 画面が真っ暗。でもマウスカーソルが表示されている場合

がほとんど同一事象のようなので、Shiftキー + 再起動を行い、５番「セーフモード起動」してみたところ、ドライブスキャンと修復（エラーはなかったようだ）が行われた後に再起動がかかった。

しかし「ようこそ」という挨拶が一言増えただけで、その後は、また同じ状態（真っ黒＋マウスポインタのみ）になってしまった。

PCを初期状態に戻す

以前に戻したときは、個人ファイルに未練を残していたが、ラチがあかないので今度は「ドライブを完全にクリーンアップする」にした。

僕も一緒に言う。バルス！

このPCを初期状態に戻しています（1％）

待つのもアホらしいので、寝ることにするわ。（2019/4/24/ 23時40分）

二回ほどエラーが出たが、スキップできた

朝起きたら、キーボードの種類を選ぶ画面になっていた。

朝に続きを30分ほどやり、途中で二回ほどエラーと言われたが、スキップして続行できたので、そのまま進めると、無事デスクトップが出るところまで進んだ。

OS は、Ｗindows 10 build 1709 となっていた。

Google Chrome を入れようとしたら、またブルースクリーン

不安定 が止まらない。Windows Update またしてもダウンロード始まっているし。

Catalyst Software Suite を入れようとしたら、またブルースクリーン

グラフィックボード RadeonHD 6850 の Windows 10 向け最新ドライバ（2015/7/29）をインストールしてみたが、途中でブルースクリーン。

• ブート中に NO DISK エラー（ブートディスクが見つからない）

Loading Operationg System ...
Boot from CD/DVD :
DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER

となり、また振り出しに戻った。

リセットボタンを押したら、今度はSSDが見つかって通常どおり起動した。

もうわけがわかりません。

マザーボードごと交換するとした場合

USB 2.0 ボードに着いていた Windows (OEM) を延々アップグレードし続けて、Windows 10 にしたのだが、そのライセンスは流用したいところ。

移行する方法を調べたら、以下の手順で可能とのことだった。

www.lifewithunix.jp

AMD Phenom II X6 1055T がはまるマザボがすでにない

ソケット AM3 という10年前のCPUであり、少なくとも AM3+ ソケットを備えたマザーボードが必要なのだが、現在 AM4 が主流となっており、中古以外は流通していないようだった。

ビルドのバージョンを戻すしかないか…

AM4 のマザボだと、かなりの部品が交換となるので、何とか今のまま延命したい。

最新ビルドは不具合連発らしく、職場のパソコンはポリシーか何かでバージョン1709に固定されたまま一切アップデートされていなかったので、IT管理者としては1709が最新の安定バージョンと理解しているようだ。

自宅の新しいPCは最新ビルドに追随し、この10年前のPCは1709かそれ以前で止めておくことにしてみようかと思う。

少なくとも 2016年～2019年4月までは動作していたので、動くはずだ…

そもそも、動作していたときの Windows 10 のバージョンは幾つだったかを推理してみる。

2018年2月にパソコンを新調し、それ以降は、ほとんど起動していなかったので、その時点で最新だったバージョンと推定できる。

tombi-aburage.hatenablog.jp

例えば以下のサイトによると、2018年2月時点では 1709 が最新だったことが分かる。

pc-karuma.net

つまり、おそらくは 1709 で正しく動作していたものが、先日 2019/4の起動によって勝手に 1803 か 1809 に更新され、動かなくなったと推測できる。

その一方で 1903 が 2019/5/21 にリリースされたらしい。

失うものは何もないので、1903 に更新してみて、動くようになるか確認してみようと思う。99%、動かないと思うけど。

もうWindows7に戻すしかない

戻したら再び起動はするようになった。

tombi-aburage.hatenablog.jp

アレクサスキル Alexa Skill を、どうにか公開できた。

最初は、アレクサ開発者コンソール Alexa Developer Console 上で試しながら直接実装していたが、

• 実装量が増えるにつれて、エラー発生時の切り分けが困難に
• リグレッションテストが場当たり的になり、品質が低下
• 開発中ソースコードのバージョン管理はコンソールではできず不便

という、ありきたりといえばありきたりな壁にブチ当たった。

結局のところ、通常の開発と同様に、ちゃんとしたローカル開発環境を用意することによってスキルの公開まで到達することができた。 

tombi-aburage.hatenablog.jp

サイコロ係

とりあえず動くレベルまでの開発はひじょうに簡単だった 

3月上旬に、スマートスピーカーでの開発に興味を持ち、いくつか初心者向けの書籍を読んで、どのようなものか調べた。

tombi-aburage.hatenablog.jp

スマートスピーカーを持っていない状態でも、エミュレータ利用で開発できるようだったので書籍片手に作ってみた。

書籍刊行時（昨年）とは異なり、現在ではスキルサービス（AWS Lambda サービス）側とスキルインタフェース（発話モデル）も統合されていたので、開発は難しくなかった。

コンソールで自動生成した Hello World を直せば、簡単に動く状態にはできた。

初回の審査は3月25日、以下のような指摘事項だった。

なんか一応動く状態にはなったので、スマートスピーカーを持っていないクセに、いきなりスキルストアの審査に出すという暴挙に出た w、

アクレサ開発者コンソール上で、ちょこちょこ作っていった結果、こんな感じになった。

審査の申請は簡単だったが、もちろん一発で通るワケはない。
３つほど指摘をもらってしまった。

1. スキルがタスクを完了した後、ユーザーへのプロンプトが提示されていないにもかかわらずセッションが開いたままになっています。スキルは、リクエストを完了した後、ユーザーの入力を求めるプロンプトを提示していない場合はセッションをクローズする必要があります。
   
   

   再現手順：

   ユーザー：アレクサ、サイコロ係を起動して

   スキル　：何面体のサイコロを何個振りましょうか？

   ユーザー：五六面体サイコロを一個振って

   スキル　：56面体を1個振ります。40が出ました。

   　　（セッションオープン）
   
   セッション管理の方法については、申請チェックリストのテストケース4.1を参照してください。

2. コンパニオンアプリ及びスキルのプロンプトに提示されている発話例（ウェイクワードおよびサポートされている呼び出しフレーズを除く）が、サンプル発話に含まれていません。現在、サンプルフレーズ及びヘルププロンプトに次のフレーズをご提示いただいています。
   

   
   該当するサンプル発話：

   ６面体のサイコロを３個振って

   「何面体のサイコロを」 「何個」 「振って」

   以下のサンプル発話を追加してください：

   RollDiceIntent　　 {diceType} 面体のサイコロを {amount} 個振って

3. データのフォーマットが弊社の規定に沿っていません。サンプル発話、スロット値のデータは、全て日本語で表示する必要があります（頭文字、イニシャリズム、アクロニムを除く）。以下のように訂正の上、再度ご申請ください。

該当する発話：

RollDiceIntent　　{amount} Ｄ {diceType} を振って

修正例：

RollDiceIntent　　{amount} d {diceType} を振って

補足：
サンプル発話内では、イニシャルを小文字にし、半角スペースで区切る必要があるため、修正をお願いいたします。

２つめ、３つめの指摘はポカミスのレベルであり、発話例や公開申請時の説明文を直すだけで済むものなので治せたが、１つめは多分デザイン上のルールにかかわる指摘であり、何をすれば合格になるのか、ちょっとよくは分からなかった。

気が変わって Amazon Echo （第二世代）を買う

別売バッテリーを買えば、標準的な Echo でも、好きなところに持ち歩きできると分かったので、購入することにした。

tombi-aburage.hatenablog.jp

• セットで購入したスマートコンセントはまるで役立たずだった。
  しかも翌週に Echo は半額セールされるという酷い仕打ち。
• リモコン無しでテレビの制御ができるのは便利。
• セミの鳴き声はウケた。

ローカル開発環境を構築

公開できる品質にするまでには、ローカル開発環境をしっかり作ることが必要だったと冒頭述べたが、４～５冊目に読んだ以下の書籍がけっこう役に立った。

Amazon Alexaプログラミング入門 (impress top gear)

Visual Studio Code、Git など、基本的な開発環境については触れていないので、その辺はネット調査で補完するか、経験と勘で適当にやった。 

２回めの審査は4月18日、以下のような指摘事項だった。

ローカル開発環境が信頼できるものになったので、ほとんど全てをリファクタリング。

自動テスト環境までは作っていないが、インテントごとに１～２パターン程度のテストデータを用意しておき、手動ながらもローカルで毎回再テストすることは徹底した。

これなら行けるだろうということで、2回目の審査提出。

1. スキルがタスクを完了した後、ユーザーへのプロンプトが提示されていないにもかかわらずセッションが開いたままになっています。スキルは、リクエストを完了した後、ユーザーの入力を求めるプロンプトを提示していない場合はセッションをクローズする必要があります。
   
   

   再現手順：

   ユーザー：アレクサ、サイコロ係を実行して

   スキル：何面体を何個、振りましょうか？

   ユーザー：八面体を三個振って

   スキル：8面体を3個振ります。うりゃ！8、6、1、合計は15です。

   （セッションオープン）
   
   セッション管理の方法については、申請チェックリストのテストケース4.1を参照してください。

2. いずれかのスロットに無効または空のスロット値を指定して1つ以上のインテントを呼び出した際、スキルがエラーを返します。
   
   該当箇所: RollDiceIntent
   
   再現手順:
   

   ユーザー：アレクサ、サイコロ係を開いて

   スキル：何面体を何個、振りましょうか？

   ユーザー：三個一億面振って

   スキル：スキルがリクエストに正しく応答できませんでした

   エラー処理の方法については、申請チェックリストを参照してください。
   
   

3. 複数のインテントに同一のサンプル発話が含まれています。各インテントには独自のサンプル発話が必要です。ユーザーのリクエストが正しいインテントへ送られるように、修正・変更によって以下のサンプル発話の重複を取り除いてください。
   
   

   該当のサンプル発話：

   SayAgainIntent もう一回言って

   SayAgainIntent もう一度言って

   補足：

   上記のサンプル発話は既にAMAZON.RepeatIntentに定義されております。

１つめの指摘は、1回目の提出時のものと本質的に同じだった。

セッション管理の実装上の問題ではなく、発話が質問で終わっていないことが問題なのではないか？と仮説を立てて、

スキル：8面体を3個振ります。うりゃ！8、6、1、合計は15です。

と speak した後に、

何面体を何個、振りましょうか？

を追加し、利用者に対して結果を伝えた後、すぐ質問するような発話に変えてみた。
これまで repromt に書いていた文言を、speak の末尾に付けたすだけの修正。

修正前

speechText は「8面体を3個振ります。うりゃ！8、6、1、合計は15です。」

修正後

speechText は「8面体を3個振ります。うりゃ！8、6、1、合計は15です。（1秒間をおいてから）何面体を何個、振りましょうか？」

return handlerInput.responseBuilder

.speak(s.speechText + '<break time="1s"/>' + r.t('ASK_COMMAND'))

.reprompt(r.t('ASK_COMMAND'))

.getResponse();

}

};

2つめは、実装ミスというよりは仕様ミス

２つめは、Cloud Watch のログを追ったら、言語レベルでメモリ確保できないという趣旨のエラーだった。大変申し訳ございません･･･要素が1億個の配列 Array を漫然と new しておりました…

確かに AMAZON.Number はただの数値なので、一億面ダイスも入りうるわな。

ユーザー：三個一億面振って
スキル：スキルがリクエストに正しく応答できませんでした 

var rollSummary = new Array(this.dicetype);

面白いかと思って、何面体のサイコロでもOKという仕様にしていたが、実用性は全くないので、仕様見直しを行い、一般に市販されている100面体までに制限した。

,'TOO_MANY_DICE' : '振れるのは100面体を20個までなんです。すみません。'

ついでに、スロットに万が一マイナス値が入った場合にはプラスに変換するようにもしておいた。実機テストで「マイナス」と発話しても、負の値は入らないようではあるが一応対策はしておく。

if(handlerInput.requestEnvelope.request.intent.name === 'RollDiceIntent'){

if(slots.diceType.value !== undefined) s.dicetype = Math.abs(slots.diceType.value);

if(slots.amount.value !== undefined) s.amount = Math.abs(slots.amount.value);

 

本来はサイコロを振るユーティリティクラス DiceRoller でチェックや補正するか例外を投げて呼び出し側に結果のみ伝えるべきとも思うが、JavaScript のクラスからの例外の投げ方がわかんないので、呼び出し側でスロットへの入力値をチェックしたり、値を変更するだけで済ませた。

サイコロは20面体までで実用上は十分だが、一応100面体までは存在する

私自身は D&D、AD&D で使っていた 4、6、8、12、20面体ダイスは持っているが100面体は10面体2個で代替できるので持っていない。

100面体ダイスは、ほぼ球体なので中々止まらない。止まりやすいように

• 出目の部分が平たく削ってあり、
• 球の中にも鋼球の重りが入っている

という精密加工品・芸術品のような代物だった。しかし所詮プラスチック製であり、加工はいい加減だったので、多分確率は均等ではなかったと疑われる。

とあるマニアによれば、3面体なども存在する

oreore.red

によれば、

• 2面体（6面体の辺を4カ所丸く削り、2曲面にする）
• 3面体（考え方は2面体と同じ）
• 果ては1面体（メビウスの輪というオチ）

すらも存在するらしいので、100面体以下であれば面数の制限はしないことにした。

個数のほうは、メモリ確保に関する問題は起きない実装だったが、とてつもなく大きい数を言われたら内部的にはくそ真面目にサイコロを振ってしまうし、出目ごとにサマリーする工夫はしているとはいえ、個数が増えて出目のバラツキが増えると結果の読み上げがいつまでも終わらないので、やはり20個くらいに制限することにした。

トンネルズ&トロールズでは、ドラゴンだが何だかの攻撃のさいに十数個の6面体ダイスを同時に振るようなことはあったかと思うので10個だと少ないだろう。

3つめは、サンプル発話を増やしたことによるバッティング

実際には、全く同じ発話は RepeatIntent に定義されてはいなかったのだが、表現的に近似している「もう一回」「もう一度」が引っ掛かっていそうだったので削除した。

Alexaスキル サイコロ係 が公開されました!

対応方法はあっていたらしく、翌4月19日には公開の通知をもらえた。

この度は サイコロ係 スキルを申請いただき、誠にありがとうございます。 おめでとうございます。スキルは認定プロセスに合格し、まもなくスキルストアに公開されます。

もしアレクサ開発者コンソールでの開発を続けていたら、リファクタリングに失敗して、もうとっくに諦めていたに違いない。やはりローカル開発環境は大事だな。

「開発中」のほかに「公開中」のエントリが増えた

Alexa SDK (ask-sdk) をインストール時に深刻なエラー（ERR!） -4094（解決）

Alexa SDK (ask-sdk) をインストール npm install 時に、ERR! errno -4094 syscall fsync という見慣れないエラーが発生した。

最終的にはハードディスクの初期化（再フォーマット）を行って解決した。

ask-sdk のインストールに失敗

npm install --save ask-sdk

e:\Users\tombi\Projects\diceroller>npm install --save ask-sdk
npm WARN rollback Rolling back isarray@1.0.0 failed (this is probably harmless): EPERM: operation not permitted, unlink 'e:\Users\tombi\Projects\diceroller\node_modules\isarray\package.json.1464894368'
npm WARN diceroller@1.0.0 No description
npm WARN diceroller@1.0.0 No repository field.

npm ERR! code UNKNOWN
npm ERR! errno -4094
npm ERR! syscall fsync
npm ERR! UNKNOWN: unknown error, fsync

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\tombi\AppData\Roaming\npm-cache\_logs\2019-04-13T22_59_13_635Z-debug.log

ERR! 発生、見事に失敗したようだ。

fsync？OSレベルのエラー？

同一事象の事例を発見したが、解決しなかった。

npm.community

syscall fsync とかいうストレージ（ディスク）周りのかなり低レベルのエラーに思えたので、Cドライブのエラーをチェックしてみたが異状なし。

ドライブのエラーをチェック

npm cache verify

Cache verified and compressed (~\AppData\Roaming\npm-cache\_cacache):
Content verified: 11 (5764738 bytes)
Index entries: 15
Finished in 0.059s

別に問題ないようだが、常套手段のキャッシュ一掃を念のためやる。

npm cache clean --force

 npm WARN using --force I sure hope you know what you are doing.

その後、npm install したが、やはり解決しなかった。

これは難航しそうだ…

Eドライブのエラーもチェック

よく考えると、-g オプションなしでインストールしているので、インストール先のドライブはCではなくて、プロジェクトのファイルがあるEドライブだった。

 ドライブの修復を試みると、数秒で完了し、検出されませんでした。などと言われる。

そして、再び npm install （何らかの操作）をするとその瞬間に、

というメッセージが出る。どうも、ドライブそのものが相当怪しいようだ。

そういえば毎朝、このドライブでエラーが出ているな…いつも無視してきたが。

念のためドライブ変えるか。

プロジェクトごと、Dドライブにコピーして再実行したら、あっさり成功した

Eドライブと同じフォルダ構成を、Dドライブに作った。
そして package.json もコピーした。

dir

ドライブ D のボリューム ラベルは アプリ です
ボリューム シリアル番号は 7E41-295B です

D:\Users\tombi\Projects\diceroller のディレクトリ

2019/04/14 10:00 <DIR> .
2019/04/14 10:00 <DIR> ..
2019/04/14 07:26 219 package.json
1 個のファイル 219 バイト
2 個のディレクトリ 136,848,175,104 バイトの空き領域

npm install ask-sdk

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN diceroller@1.0.0 No description
npm WARN diceroller@1.0.0 No repository field.

+ ask-sdk@2.5.1
added 19 packages from 69 contributors and audited 22 packages in 3.509s
found 0 vulnerabilities

別ドライブなら問題なし

 Eドライブ、4TBもあるのに爆弾抱えた状態ってこと？

8時間かかるけど、ディスク修復を試す

Data Lifeguard Diagnostic for Windows 

で Eドライブを簡易チェックしてみたが、簡易チェックでは特に支障はない。

しかし Windows イベントログには、そもそもマスタブートレコード MBTがおかしいという趣旨のエラーが出ているので 修復を図ることにした。 

一旦、このPCの管理者ユーザに切り替えて、裏番組で実行しておく。
見積りでは8時間とのことなので、夜、寝る前には完了するはずだ。

再び、開発者ユーザ（管理者権限あり）に戻して、開発環境構築を続行する。

８時間後、Data Lifeguard Diagnostic からは何もエラーは発見されなかったとの報告。

Western Digital Data Lifeguard Diagnostics - DLGDIAG for Windows

そんな馬鹿な･･･

･･･最初から chkdsk /F しておけばよかった。また今度やろう。

再び８時間かけて chkdsk /R /F を実行したが「問題は見つかりませんでした」

chkdsk /R /F

 （ステージ１～４略）

ステージ 5: 不良空きクラスターを探しています ...

969201722 個の空きクラスターが処理されました。
空き領域の検査が終了しました。

Windows でファイル システムのスキャンが終了しました。
問題は見つかりませんでした。
これ以上の操作は必要ありません。

（中略）

0 KB : 不良セクター

（下略）

修復してないが･･･本当かよ？

その後、やっぱりすぐにエラーが再発した。治ってない。
MBTを直接更新する何かの方法を試すしかなさそうだ。別途…

最終手段のハードディスク初期化

何をやっても治らないので、ハードディスクを再フォーマットして初期化することにした。4TBもあると、なかなか終了しないな…放置して寝るわ。

ハードディスク初期化したら、成功するようになった。

適当なプロジェクトフォルダを、初期化してドライブレター E を割り当て直したディスク2 に作成してから、node.js command prompt からプロジェクト新規作成。

npm init

（略）問題なし

以前、失敗した ask-sdk をインストール

npm install --save ask-sdk

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN kidsmorning@1.0.0 No description
npm WARN kidsmorning@1.0.0 No repository field.

+ ask-sdk@2.5.1
added 19 packages from 69 contributors and audited 22 packages in 16.431s
found 0 vulnerabilities

おお、治ったようだ。

別のパッケージも続けてインストール

npm i -save i18next i18next-sprintf-postprocessor

npm WARN kidsmorning@1.0.0 No description
npm WARN kidsmorning@1.0.0 No repository field.

+ i18next@15.0.9
+ i18next-sprintf-postprocessor@0.2.2
added 4 packages from 3 contributors and audited 26 packages in 2.668s
found 0 vulnerabilities

こちらも全く問題なし

これで、心おきなく Eドライブが使えるぞ。

ドライブエラーも出なくなった

 のメッセージも出なかったし。

Visual Studio Code (VS Code) に Plant UML を追加

アレクサスキル Alexa Skill を開発するにあたって、UML か何かで設計できないかと思っていろいろ調べた。

• VISIO ビジオ
  Microsoft に買収される前に使っていたが、最近使っていなかったので、今はどうなっているのか再調査。怪しげなサイトで格安のパチもんが多数販売されているようだが、本家のマイクロソフトのサイトを見ると買い切りの場合で4万円くらい。高い。
• Plant UML
  フリーであり VS Code から Alt + D で呼び出せるとのこと。

出来上がりイメージ

• ボードゲーム中に、サイコロを振らせるスキル

サイコロ係

シーケンス図

• 出来てから仕様書を書くと楽だね w

Plant UML のインストール

• VS Code から検索語 Plant UML で拡張 extension を検索し、見つかったものを導入 install
• Graphviz をインストール
  安定バージョン 2.38 Stable Release 

するだけであり、そこまでは簡単だった。

シーケンス図のUML図を作成

テキストで書けるので、作図にマウスが必要なく、作画前提のUMLツールよりも楽。
スイムレーンの位置変更なども行をカット＆ペーストすればできるので生産性高い。

@startuml

title サイコロ係に６Ｄ８を振らせる

actor Player

boundary LaunchRequest

boundary RollDiceIntent

boundary SayAgainIntent

Player -> LaunchRequest: アレクサ、サイコロ係

LaunchRequest --> Player: 何面体を何個振りましょうか？

Player -> RollDiceIntent: 六面体を八個振って

RollDiceIntent -> DiceRoller: 面数:6、個数:8

DiceRoller --> RollDiceIntent: <結果>, 合計

RollDiceIntent --> Player: 六面体を八個振ります。<結果>が出ました。

Player -> SayAgainIntent: もう一遍言って

SayAgainIntent --> Player: 先ほどの結果をお伝えします。<結果＞が出ました。

@enduml

しかし  Alt + D しても図は表示されず。

Java が必要とのことだった。

PCには JDK が入っているが、パス PATH は通っていなかったようだ。
plantuml.java で Java 実行形式ファイルへのパスを設定するのでもいいらしい。

しかし plantuml.java での設定の仕方が分からなかったので、システム環境変数でパスを通すことにした。C:\jdk-11.0.2\bin を追加。

VS Code を終了させ、再起動したら ALT + D で図が表示されるようになった。

全く問題なし

AWSとAzureのシステム構成図のアイコン画像素材を入手

PlantUML とは関係ないが、設計作業上、使えそうなアイコンがありそうなのでダウンロードしておくこととした。

Amazon Web Services (AWS) シンプルアイコン

aws.amazon.com

Azure Cloud and AI Symbol Icon Set

アマゾンに対抗して用意しただけなので、ダウンロードページにやる気は感じられない。しかもなぜか SVG しかない。

Download Microsoft Azure Cloud and AI Symbol / Icon Set - SVG from Official Microsoft Download Center

SVG は標準のエクスプローラ explorer ではサムネイル表示できなくて不便。
エクスプローラ拡張を導入するほかない。

github.com

アイコンのサイズを中以上にすれば、プレビューが表示されるようだ。

TypeScript + node.js 実装および mocha + espower-typescript テスト駆動開発の環境構築

ハードディスク障害にハマりながらも、 何とか node.js の環境までは作った。

tombi-aburage.hatenablog.jp

JavaScript でクラス Class が使えるようになったと聞いたので、ユーティリティクラスを試しにクラスとして書いてみたが･･･汚い…これがクラスといえるのか？

• コンストラクタの中でプロパティ（メンバ）を生成するだと？
• すべてパブリックだと？
• いちいち this をつけろだと？

なんと見苦しい…

そういえば Alexa Skills Kit SDK をダウンロードするさいに、TypeScript 対応と書いてあったな…

TypeScript を導入

プロジェクトフォルダーにて、ローカルに開発環境へ導入

npm install --save-dev @types/node

npm WARN diceroller@1.0.0 No description
npm WARN diceroller@1.0.0 No repository field.

+ @types/node@11.13.4
added 1 package from 37 contributors and audited 23 packages in 1.294s
found 0 vulnerabilities

しかし、TypeScript のコンパイル方法すら知らなかったので、書籍を探して勉強するまで一旦中止。

知識ゼロでは流石に無理。

なお後で分かったことだが、上のコマンドは断じて TypeScript を導入するコマンドなどではなかった w

TypeScript を導入再開

手ごろな書籍を見つけてきた。

TypeScript実践マスター

Visual Studio Code、Node.js は導入済みなので飛ばして、Type Script 固有の環境構築から始める。 

tsc コマンドをグローバルにインストール

npm install -g typescript

C:\Users\tombi\AppData\Roaming\npm\tsc -> C:\Users\tombi\AppData\Roaming\npm\node_modules\typescript\bin\tsc
C:\Users\tombi\AppData\Roaming\npm\tsserver -> C:\Users\tombi\AppData\Roaming\npm\node_modules\typescript\bin\tsserver
+ typescript@3.4.5
added 1 package from 1 contributor in 3.179s

tsc -v

Version 3.4.5

コンパイラ導入、問題なし

この辺から TypeScript とは直接関係なさそうな作業が続く（寄り道）

早くTypeScript のコンパイルや稼働確認をしたい所だが、上記書籍の著者は DevOps のベストプラクティスを重視しているようで、コンパイラが導入できたからといって、いきなりコンパイルなどはさせてくれなｓい。

必要と思われる開発環境をすべて先に用意してから、アプリケーションを作りなさいという考えのようだ。

確かに最終的には、DevOps 開発環境を作法通りに揃えてから開発に臨んだ者が勝つのは同意なので、焦らずに環境構築を続行する。

開発用のWebサーバは、今は用意しない

次に開発用のWebサーバ http-server をインストールしろと書いてあったが、以前に

tombi-aburage.hatenablog.jp

で Vue をインストールしたさいに Webサーバぽいものが同梱されていたと思ったので、Vue で開発する限り、それを流用できるかもしれない。

したがって http-server 導入は飛ばす。Git も導入済みなので飛ばす。

ブラウザ用のデバッガ拡張を導入

ブラウザ用の debugger は未導入だったので導入した。推奨マークがついていた。

Debugger for Chrome extension に推奨マーク

他にも、推奨マーク付きがあるのではないかと思って調べたら、幾つか発見されたが、書籍では指示されていなかったので後回し。

他にも推奨マーク付きがあった

Visual Studio 推しだったらしい･･･

Visual Studio Code の環境構築をここまでやったところで、書籍によれば

Visual Sutdi 2017 を使用してTypeScript の開発を行う場合は（中略）ツールも含めてインストールされるので、とても簡単に準備が完了

とのこと。

先に言ってよ！

とはいえよく読むと

• ASP.NET と Web 開発
• Node.js 開発
• Visual Studio 向け GitHub 拡張

と３つも作業が必要らしく、それほど楽とも思えなかったのでスルー。

初めて真面目に GIt レポジトリを作成

ローカルレポジトリとプロジェクトを色々な端末上に作成し、USBメモリでファイルコピーした結果、自分でもどれが正本か分からなくなったので、リモートレポジトリを正本にする運用に切り替えることにした。

tombi-aburage.hatenablog.jp

最初から、そうしとけば良かったワケだが。

レポジトリ作成、問題なし

Azure のサインアップ

Alexa アプリや Vue.js アプリを作成することが目的なので、あまり Azure を使う気もなかったが、

• Webサイト、MySQL は無料で使い続けられるらしい
• Bot Framework は使ってみたい

ことから、折を見て作成することにした。
が、パスワード考えさせられるのが嫌なので、今は作成しない。

やっと、コンパイルのお許しが出ました。

TypeScript実践マスター

の第３章に到達。やっとコンパイルのお許しが出た。
作業的には tsc コマンドのインストール直後にできる作業なのだが。 

書籍では VS Code 上でサンプルプログラムを作成してコンパイルする手順となっていたが、折角なので、練習も兼ねてリモートレポジトリ GitHub 上でサンプルプログラム app.ts のソースを編集し、それをローカルに取り込んでからコンパイルする方法でやってみた。

地味な同期ボタン

地味な同期ボタンを押すと、GItHub から app.ts ファイルが取り込まれて VS Code に反映された。その後、コンパイルすると、app.js というファイルが作成された

tsc app.ts

ts ファイルから js ファイルが作成された

コンパイル、問題なし

TypeScript のビルド構成を定義

tsc --init

出来た tsconfig.json は、コメントだらけのキモい設定ファイル。
書き足すよりはコメント解除する方が合理的といえば合理的だが。

タスク Terminal - Tasks: Configure Default Build Task

タスク Terminal : Run Build Task

より task.json ファイルが作成され、

> Executing task: tsc -p e:\Users\tombi\Projects\TypeScriptSample\tsconfig.json <
Terminal will be reused by tasks, press any key to close it.

この結果、先ほどとは少し出力内容が異なるが app.js というファイルが作成された。

ビルドタスク、問題なし

さてここで、テスト駆動開発のための準備始まる

以前、アレクサスキルを開発したさい、場当たり的な手動単体テストしかできていないのをまずいと思っていたので、ちょうどよかった。

tombi-aburage.hatenablog.jp

TypeScriptそのものにはテストフレームワークは無いのか、結局 mocha を使う流れになっているが。

デバッグ構成を追加

デバッグ構成追加 Debug - Add Configuration すると、候補として Chrome、Node.js の２つと More... が出てきた。

試しに More... を押してみると、debugger に分類されている拡張の一覧がずらっと出てきた。こんなにあるのか…

まあ今は、Node.js を追加するだけなのだが。

launch.json の configurations で [Ctrl] + [SPACE] すると Moca Tests という起動オプションがあったので、node.js との相性はよいのではないかと推測される

TypeScript (.ts) ファイルのデバッグ

launch.json に

"sourceMaps": true

を追加してデバッグ実行。しかし、

• .tsファイルに設定したブレークポイントは機能せず、
• .jsファイルに設定したブレークポイントは機能する 

という事象となった。おかしい…

tsconfig.json の方にも sourceMap の設定があった。

tsconfig.json の sourceMap (末尾に s はなし）の行のコメント解除。
これもコメント解除しただけではダメで、再ビルドが必要だった。

再ビルドをしたら、.ts ファイルと .js ファイルを橋渡しする map ファイルが作成され、デバッグ実行のさいに、ts.ファイルの方に設定したブレークポイントが機能するようになった。

２か所あるのね。ポカミス。

単体テストフレームワーク Mocha 導入

以下も参照して構築

qiita.com

ここで説明されていた 

• power-assert
• intelli-espower-loader

も格好いいので導入することにした。

ここから悲劇が始まった…

なお最終的に、intelli-espower-loader の方は TypeScript との相性が悪いことが判明したため撤去して、espower-typescript を導入し直すはめになった。

３つまとめて、ローカルインストール

npm init の後、

npm install --save-dev mocha power-assert intelli-espower-loader

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN typescriptsample@1.0.0 No description

+ mocha@6.1.4
+ intelli-espower-loader@1.0.1
+ power-assert@1.6.1
added 187 packages from 650 contributors and audited 504 packages in 34.575s
found 0 vulnerabilities

TypeScript の型定義を導入

npm install -g typings

npm WARN deprecated typings@2.1.1: Typings is deprecated in favor of NPM @types -- see README for more information
C:\Users\tombi\AppData\Roaming\npm\typings -> C:\Users\tombi\AppData\Roaming\npm\node_modules\typings\dist\bin.js
+ typings@2.1.1
added 184 packages from 100 contributors in 16.522s

警告あり。今後は typing よりも @types を使え、詳しくは README 参照とのこと。

教えてくれて、ありがとう。

github.com

を確認したところ、以下のようなことが留意点としてあった。

 TypeScript 2.0, users can install typings using npm install @types/<package> 

 New projects should use @typesfrom NPM.

npm install -g @types/node
npm install -g @types/mocha
npm install -g @types/power-assert

この３つの型定義のグローバルインストールは見かけ上成功した。

しかし、実は違った。

後に不適切と判明し、ローカルインストールに変更する破目になった。

なお、intelli-espower-loader の型定義はそもそも存在しないらしく、エラーとなった。

npm install -g @types/intelli-espower-loader

npm ERR! code E404
npm ERR! 404 Not Found: @types/intelli-espower-loader@latest

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\tombi\AppData\Roaming\npm-cache\_logs\2019-05-11T22_37_28_910Z-debug.log

型定義が無い類のパッケージだと理解して、このエラーは無視する。

デバッグ構成に Mocha の起動オプションも追加

以前に Node.js のデバッグ構成を追加したさいに Mocha のデバッグ構成も見つけていたので、すでに追加済みだった。

launch.json の configurations で [Ctrl] + [SPACE] すると Moca Tests という起動オプションがある

もう、やってあったわ。

 テストスクリプト作成

mocha 本体以外に power-assert、intelli-espower-loader を勝手に追加してしまったので、書籍のサンプルがそのままでは使えなくなった。以下を参考に予習。

power-assertの使い方 Node.js編 | Web Scratch

package.json にも、directories の追加を行った。

しかしながら、power-assert を require したさいに型定義を発見できない。

require で power-assert を発見できない

また、外部参照問題か…

どうやら power-assert については型定義をグローバルインストール（-g 付き）できないらしいので、ローカルインストールで再インストールしたら require のエラーは治った。

結局、ローカルが安全だな…

必要かどうか分からないが、念のためアンインストールしてから、ローカルインストール（-g なし）する。

npm uninstall @types/power-assert
npm install @types/power-assert

しかし、引き続き入力した describe で型定義を発見できないとのこと。
mocha の型定義も、グローバルインストールではダメだったらしい。

お前もローカルか…

過去を振り返ってみれば、mocha 本体も power-assert もグローバルインストールしてはいなかったので、もともと辻褄が合っていなかったようだ。

describe で多分 mocha 型定義を発見できない

npm uninstall @types/mocha
npm install @types/mocha

これで問題は解消した。念のため node の型定義もローカルインストールにしておく。

npm uninstall @types/node
npm install @types/node

これで型定義は全てローカル

テストスクリプトとして 

import assert = require('power-assert');

describe("Test Case #1", () => {

it("Test Case #A", () => {

assert.ok(1 === 1, "1は1と等しい");

});

it("Test Case #B", () => {

assert.ok(false, "わざとテスト失敗");

});

});

という感じで .ts を作成し、少なくともコーディテング時点でのエラーは全て無くなったので、ビルドして .js を生成した後、デバッグ実行。

describe が定義されていません、とのエラー

C:\Program Files\nodejs\node.exe node_modules\mocha\bin\_mocha -u tdd --timeout 999999 --colors E:\Users\tombi\Projects\TypeScriptSample/test
e:\Users\tombi\Projects\TypeScriptSampl
e\node_modules\yargs\yargs.js:1163
else throw err
^

ReferenceError: describe is not defined
（以下、スタックトレース略）

また、外部参照問題か…

intelli-espower-loader の指定を忘れていた（関係なし）

そういえば mocha 起動時に intelli-espower-loader を -- require で指定する、というのを設定していなかったので、これが原因かもしれない。

毎回--requireを指定するのが面倒な場合はmocha.optsファイルを作って書いておく

らしいので作成したが、別にこのエラーとは関係なかった。

なお、拡張子は opts と4文字なので、間違わないようにすること。

念のため、すべてのパッケージと型定義をグローバルにも追加

治らないので疑心暗鬼となり、

• mocha をグローバルインストール
• さっき消したばかりの型定義もグローバル

npm uninstall mocha
npm install -g mocha
npm install -g --save-dev mocha
npm install @types/node -g
npm install @types/mocha -g
npm install @types/power-assert -g

エラー解消せず。これらも別にこのエラーとは関係なかった。

launch.json の tdd を bdd に変更（解決）

stackoverflow.com

I used tdd before, it throw ReferenceError: describe is not defined

But, when I use bdd, it works!

 とのことだったので、launch.json の

"name": "Mocha Tests",

"program": "${workspaceFolder}/node_modules/mocha/bin/_mocha",

"args": [

"-u",

"tdd",

の tdd のところを bdd に変更したら、あっさり治った。

mocha のデフォルトは bdd なのだが、VS Code がビルド構成を生成したさいにご親切にも tdd になさったようだ。

--ui, -u Specify user interface [string] [default: "bdd"

余計なことを･･･

mocha によるテストスクリプトの起動には成功

C:\Program Files\nodejs\node.exe --inspect-brk=42451 node_modules\mocha\bin\_mocha -u bdd --timeout 999999 --colors E:\Users\tombi\Projects\TypeScriptSample/test

のように、tdd ではなく bdd が指定されて mocha が起動した。

_mocha -u bdd で node.exe が起動し、テストスクリプトが実行された

どうやら今度こそ、起動には成功したようだ。

とにかく、起動はした

でも実行結果表示は期待外れ

しかしながら、どうやら power-assert、intelli-espower-loader は作動していない。

実行結果の表示が、親切な表示になっていないので、どうやら power-assert、intelli-espower-loader は作動していないように思える。

 これらもグローバルインストールしないとダメなのか…

npm install -g power-assert
npm install -g intelli-espower-loader 

しかし、これだけでは解消しなかった。

mocha.opts は読み込まれていない様子だ。

どうやらプロジェクトフォルダ直下に置いた mocha.opts に追記した

• --require intelli-espower-loader

設定は読み込まれていないようだ。今回のように node.exe 経由で呼び出されている場合には、mocha.opts は無視されるようだ。

mocha.opts ではなく、launch.json に指定し直しても、無駄だった。

紛らわしいので mocha.opts は削除し、launch.json に記述を追加する。

"args": [

"--require",

"intelli-espower-loader",

"-u",

"bdd",

しかし、これでも親切な表示にはならず、問題は解消しなかった。

power-assert のモジュール周りで何か不具合が起きているようにも思えた。

よくよく見ると DEBUG CONSOLE には、実行結果の後にスタックトレースの切れ端が出ている。

at Decorator._callFunc (E:\Users\tombi\Projects\TypeScriptSample\node_modules\empower-core\lib\decorator.js:110:20)
at Decorator.concreteAssert (E:\Users\tombi\Projects\TypeScriptSample\node_modules\empower-core\lib\decorator.js:103:17)
at decoratedAssert (E:\Users\tombi\Projects\TypeScriptSample\node_modules\empower-core\lib\decorate.js:51:30)
at powerAssert (E:\Users\tombi\Projects\TypeScriptSample\node_modules\empower-core\index.js:63:32)
at Context.<anonymous> (E:\Users\tombi\Projects\TypeScriptSample\test\test2.ts:9:13)

おそらく power-assert のモジュールで何か不具合が起きているようだ。

同じような被害者を発見した。

と、ここまでやったところで調査すると、ほとんど同一事象に陥っている記事を見つけた。power-assert が悪いわけではなく、intelli-espower-loader を使っていることがよろしくなかったらしい。

qiita.com

× intelli-espower-loader

espower-typescript に乗り換え

TypeScript と組み合わせる場合には、intelli-espower-loader ではなくて、espower-typescript を使えとのこと。

github.com

〇 espower-typescript

用済みとなった intelli-espower-loader は副作用が残ると嫌なのでアンインストール。

npm uninstall intelli-espower-loader

続いて espower-typescript をインストール。

npm install espower-typescript

PS E:\Users\tombi\Projects\TypeScriptSample> npm install espower-typescript
npm WARN espower-typescript@9.0.2 requires a peer of typescript@>= 2.4.2 but none is installed. You must install peer dependencies yourself.
npm WARN ts-node@8.1.0 requires a peer of typescript@>=2.0 but none is installed. You must install peer dependencies yourself.
npm WARN typescriptsample@1.0.0 No description

+ espower-typescript@9.0.2
added 8 packages from 5 contributors and audited 743 packages in 2.888s
found 0 vulnerabilities

警告あり。typescript モジュールが無いから自分で入れろとのこと。 
一番最初にグローバルインストールしていたのだが、ローカルにもないとダメらしい。 

npm install --save-dev typescript

npm WARN typescriptsample@1.0.0 No description

+ typescript@3.4.5
added 1 package from 1 contributor and audited 744 packages in 1.906s
found 0 vulnerabilities

espower-typescript を require するように変更

github.com

にある、Run test の例を参考にして、launch.json の記述を再び変更する。

"args": [

"--require",

"espower-typescript/guess",

"test/**/*.ts",

テストスクリプトも espower-typescript  のサイト掲載のとおりに作成した。

import assert = require('assert');

describe('Array#join', () => {

it('joins all elements into a string with separator', () => {

assert(['a', 'b', 'c'].join(':') === 'a:b:c:');

});

});

デバッグ実行で mocha を起動、今度は親切な表示に変わった（成功）

empower-core のスタックトレースが相変わらず表示されるが、親切な表示には変わったので良しとする。なおempower-core のスタックトレースは表示されてしまうのが普通のようなので、放置しておく。

親切な表示になった

これで TypeScript + node.js + mocha + espower-typescript の組み合わせでのテスト駆動開発が可能になったようだ。

テスト駆動開発、準備良し

ああ、面倒くさかった…

アレクサスキル Alexa Skill 向けローカル開発環境

アレクサ開発者コンソール Alexa Developer Console 上で直接、Lambda 関数（node.js 実装）を編集するというスタイルで開発していたが、障害の発生時に切り分けが難しいので、一部をローカル開発環境構築することとした。

ちょうど

Amazon Alexaプログラミング入門 (impress top gear)

に手順の記載があったので、参考にしてローカル開発環境構築。

node.js のプロジェクトを１つ作成

Node.js command prompt より、対話形式でプロジェクト作成。

npm init

This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

（ 20行くらい中略）
Is this OK? (yes)

package.json というファイルが1つだけできた。

dir

ドライブ E のボリューム ラベルは データ です
ボリューム シリアル番号は 1A04-81C2 です

e:\Users\tombi\Projects\diceroller のディレクトリ

2019/04/14 07:26 <DIR> .
2019/04/14 07:26 <DIR> ..
2019/04/14 07:26 219 package.json
1 個のファイル 219 バイト
2 個のディレクトリ 3,969,808,773,120 バイトの空き領域

出来たファイルは package.json だけ。これだけかい。

全く問題なし

node.js のテストプログラムで動作確認

index.js に console.log ('Hello World'); だけ書いて、

node index.js

Hello World

全く問題なし

node.js 環境にAlexa Skills Kit SDK を追加 

上記の書籍よりも新しい SDK があるかもしれないので、念のため 何を開発できるか知る | Alexa Skills Kit | アレクサ のサイトでチェック。

コードサンプルとNode.js SDK

のリンク先へたどっていくと、GitHub に着いた。

github.com

 がそれらしい。でも、何をどうやって npm で取得すればいいのか分からん。

README.ja.md

という、いかにも日本人向けの README を見つけたので開くと Package と NPM の対応関係が表になっており、上記書籍と同じく ask-sdk で問題ないらしいと分かった。

Eドライブに作っていたプロジェクトに追加しようとしたら、

npm install --save ask-sdk

npm ERR! code UNKNOWN、npm ERR! errno -4094、npm ERR! syscall fsync

のようなエラーが出て、ドはまりした。 

fsync？OSレベルのエラー？

本題と関係ないが、その後の顛末は：

tombi-aburage.hatenablog.jp

Dドライブにプロジェクトを複写して再試行したら何故かうまくいった。

npm install ask-sdk

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN diceroller@1.0.0 No description
npm WARN diceroller@1.0.0 No repository field.

+ ask-sdk@2.5.1
added 19 packages from 69 contributors and audited 22 packages in 3.509s
found 0 vulnerabilities

Lambdaをローカルで実行するツール lambda-local を導入

とりあえず Alexa Skill Kit SDK までは進んだので、

Amazon Alexaプログラミング入門 (impress top gear)

 を参照しつつ、次の作業へ。

npm install -g lambda-local

C:\Users\tombi\AppData\Roaming\npm\lambda-local -> C:\Users\tombi\AppData\Roaming\npm\node_modules\lambda-local\bin\lambda-local
+ lambda-local@1.5.2
added 31 packages from 83 contributors in 4.522

全く問題なし

いよいよ index.js を本物（Alexa スキルの主処理）に差し替える

ここから先は、単なる自作のアプリケーション開発なので、もう上記の書籍は当てにできない世界となる。

数日前に、アレクサ開発者コンソール Alexa Developer Console 上で作成した自分のプログラム（複数個のサイコロを振らせるというスキル）

サイコロ係

のソースコードの中身を、node.js のローカル環境構築のさいにテストプログラム代わりにしていた index.js に上書きコピーした。

本当はファイルをダウンロードしたかったのだが、Alexa Developer Console のファイルをダウンロードする方法が分からなかったので、仕方なくコピー＆ペースト…

方法はダサいが、ともかくも index.js はローカル開発環境に移行された。
サーバ環境（アレクサ開発者コンソール ）で実際に動作確認が取れているコードなので、これをローカル開発環境でも動かせるようにするのが今からの作業ということ。

テストデータは Alexa Developer Console のスキルI/Oを元に作成

ローカル開発環境でテストをするためには、その入力となるデータの準備が必要なのだが、手作業で作るのは面倒なので、実際に動作しているサーバ側のスキルサービスの出力をパクることにした。

スキルI/Oをオンにして、テストを実行。表示されたJSON入力の内容をコピーして、ローカル開発環境の test サブフォルダ配下に LaunchRequest.JSON という名前で保存した。

lambda-local で index.js を実行する

lambda-local -l index.js -h handler -e test\LaunchRequest.json 

D:\Users\tombi\Projects\diceroller>
info: START RequestId: 7711489c-0c23-b7ef-89dc-d3fc5d2ae50a
info: End - Message
info: ------
（中略、ここに応答内容が表示される）

info: ------
info: Lambda successfully executed in 69ms.

スキルの起動要求 LaunchRequest に成功したようだ。

全く問題なし

起動要求のテストができただけでは、大して嬉しくもない。

同じように、一番テストを行いたい主処理のインテントについても、同じ手口で Alexa Developer Console に JSON 入力ファイルを作成させ、ローカル開発環境の test サブフォルダ配下に RollDiceIntent.json という名前で保存した。

lambda-local -l index.js -h handler -e test\RollDiceIntent.JSON 

info: START RequestId: f7c5ae17-873e-f05a-2b02-4c6ebafdaa40
D:\Users\tombi\Projects\diceroller\test\RollDiceIntent.JSON:2
"version": "1.0",
^

SyntaxError: Unexpected token :

（中略、ここに激しいスタックトレースのダンプ）

error: End - Error
error: ------
error: {
"errorMessage": "Unexpected token :",
"errorType": "SyntaxError",
"stackTrace": [
"rsion\": \"1.0\",",
"",
"",
"taxError: Unexpected token :",
"new Script (vm.js:80:7)",
"createScript (vm.js:274:10)",
"Object.runInThisContext (vm.js:326:10)",
"Module._compile (internal/modules/cjs/loader.js:664:28)",
"Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)",
"Module.load (internal/modules/cjs/loader.js:600:32)",
"tryModuleLoad (internal/modules/cjs/loader.js:539:12)",
"Function.Module._load (internal/modules/cjs/loader.js:531:3)",
"Module.require (internal/modules/cjs/loader.js:637:17)",
"require (internal/modules/cjs/helpers.js:22:18)"
]
}
error: ------
error: Lambda failed in 63ms.

あれ？何故失敗するんだ？

結論としては、JSON入力ファイル名の拡張子を誤って大文字（.JSON）で指定していたことが原因だった。Windows の分際で大文字・小文字を区別するとは生意気な！

こんなに激しく責めなくてもいいだろ！
しかもスタックトレース、全然ヒントになってないし！

拡張子を小文字で指定し直して実行すると、うまくいった。

lambda-local -l index.js -h handler -e test\RollDiceIntent.json 

info: START RequestId: ccef6fd6-7858-5c52-eb0a-ad5f668df2d5
info: End - Message
info: ------
info: {
（中略、ここに応答内容の前半が表示される）
"ssml": "<speak>6面体を3個振ります。1,<break time=\"0.5s\"/>5,<break time=\"0.5s\"/>1が出ました 。合計は7です。</speak>"
（中略、ここに応答内容が後半が表示される）

info: ------
info: Lambda successfully executed in 51ms.

おお！全く問題なし

引き続き Visual Studio Code でデバッグするための設定

Amazon Alexaプログラミング入門 (impress top gear)

 を参照しつつ、やろうとしたが、Launch.json が何のためのものなのか知らないし、作り方も知らなかった（打ち込むのも面倒なので嫌）のでネットで調査した。

www.atmarkit.co.jp

なるほど、VS Code のデバッグ画面からひな形を作成できるのか･･･

ここまでのところ npm のプロジェクトまでは作ってあったが、Visual Studio Code (VS Code) のプロジェクト（ワークスペース）は作っていなかったので、まずこれを作った。

作ったといっても npm のフォルダを丸ごと、VS Code ワークスペースに追加しただけのことだが。

その後、デバッグ画面で歯車アイコンをポチったらファイルが作成された。

起動するプログラム program と引数 args を、先ほど Node.js command prompt で実行した lambda-local のコマンドと全く同じ意味になるように変更した。

まずはデバッガを起動せず、たんに実行してみる。

実は VS Code は初めて使うので、ブレークポイントの指定の仕方どころか、プログラムの実行のさせ方すらも知らない。

とりあえず

• デバッグせずに開始 [ Debug ] - [ Start Without Debugging ]

を実行したら、デバッグコンソール DEBUG CONSOLE で

C:\Program Files\nodejs\node.exe C:\Users\tombi\AppData\Roaming\npm\node_modules\lambda-local\bin\lambda-local -l index.js -h handler -e test/RollDiceIntent.json

が実行されて、出力結果も期待どおりに出力された。

通常の実行は、問題なし

デバッグ開始 Start Debugging して実行してみる。

今回もブレークポイントは指定せずに、

• デバッグ開始 [ Debug ] - [ Start  Debugging ]

を実行したら、デバッグコンソール DEBUG CONSOLE に

Waiting for the debugger to disconnet...

と表示され、それ以上、進まなくなった。

ブレークポイントはないのだから、通常の実行と同じように、そのまま進行して呼び出し終了するものと思ったのだが･･･

調べてみたら以下の記事に同じような表示例があって、この記事の筆者は全然気にしていないようだったので、とりあえず置いておくことにした。

blog.hiroppy.me

ブレークポイントを指定し、デバッグ開始 Start Debugging して実行してみる。

VS Code のインタフェースをつつきまわしていたら、

• 行内ブレークポイント  [ Debug ] - [ New Breakpoint ] - [ Inline Breakpoint ]

というメニューを見つけたので、これを適当な行に設定してから実行をしてみた。

おお！止まっている！

デバッグコンソールを見てみると、先ほどとは表示が違っている。

Debugger attached.

どうやら、先ほどの

Waiting for the debugger to disconnet...

というメッセージは「実行が全て終了したので、デバッグのセッションも終わらせておきましたよ。俺って親切でしょう？」という意味だったらしい。

･･･紛らわしいぞ。

ブレークポイントで配列内の値が見えることを確認した後、実行を再開させると、さきほどと同じように、

Waiting for the debugger to disconnet...

となった。

デバッグ実行も、問題なし

これでデバッガも使えるようになった。素晴らしい！

但しデバッグ開始 Start Debugging による実行では、デバッグコンソールには lamda 関数の処理結果の JSON出力は出力されない点は、ちょっと違和感がある。

標準出力をリダイレクトするとかしないとダメなのかもしれない。

動くようになったので、リファクタリング着手

多言語対応をするつもりは無いのだが、スキルサービスからの応答発話のリテラルをソース本体から追い出したいので、How to Localize Your Alexa Skills : Alexa Blogs を参考にしながら、国際化対応のパッケージをローカル開発環境に追加した。

国際化対応のパッケージを追加

npm i -save i18next i18next-sprintf-postprocessor 

npm WARN diceroller@1.0.0 No description
npm WARN diceroller@1.0.0 No repository field.

+ i18next@15.0.9
+ i18next-sprintf-postprocessor@0.2.2
added 5 packages from 40 contributors and audited 27 packages in 2.07s
found 0 vulnerabilities 

全く問題なし

引き続き How to Localize Your Alexa Skills : Alexa Blogs を参考にしながら、ソースコードを全面的に変更。index.js にベタ書きしていた日本語応答発話のリテラルを、新たに作成した言語リソースファイル  ja.js の方に移すことにした。

自作のスキルサービスは

というシーケンスになっているのだが、スキルインタフェース（図略）からのバウンダリとなっている handler を収容している index.js に日本語の発話がどんどん増えてきて、見通しが悪くなってきていた。 ･･･全部追い出すぞ。

// ja.js

module.exports = {

translation : {

'SKILL_NAME' : 'サイコロ係' // <- can either be a string...

,'ASK_COMMAND' : '何面体を何個、振りましょうか？'

,'HELP_USAGE' : 'あなたの代わりにサイコロを振ります。 <break time="1s"/>\

「何面体を」<break time="1s"/>「何個」<break time="1s"/>「振って」<break time="1s"/>のように指示してください。'

,'TOO_MANY_DICE' : '8面体以上の場合、同時に振れるのは8個までなんです。すみません。'

,'CANNOT_HEAR_YOU' : 'すみません、よく聞き取れませんでした。'

,'REPEAT_COMMAND' : [

'%s面体を%s個振ります。','%s面体のサイコロを%s個振ります。','%s面体ダイスを%s個振ります。'

]

,'EXCITED' : [ // <- or an array of strings.

'','それっ！','うりゃ！','むん！','よっと！'

]

,'SURPRISED' : [

'おっと！','あれっ？','おやっ？','ほほう！'

]

,'SAY_AGAIN_RESULT' : '先ほどの結果を、もう一度お伝えします。'

,'BYE' : 'さようなら。'

}

}

\ (*´Д｀) / いい感じの定数名を考えるのが、けっこうストレスだった。そのうち命名規則でも考えることにしよう。

リテラルを追い出す以外にも、幾つかの発話候補の中から無作為にどれか１つを選んで応答させることが簡単になったので、やる価値はあるかと。

もう、文言修正ごときで主処理 index.js には手を入れないで済む…

これでスキルサービスからの応答の文言修正については、主処理 index.js を変更する必要がなくなり、言語リソースファイル ja.js を変更するだけで良くなった。

しかし主処理から呼び出している自作のユーティリティ関数 DiceRoller.js の内部での応答文言組み立てについては、この関数に handlerInput への参照を引き渡してしまうとサブルーチンとしてのモジュールの独立性が保てないので後回しにした。

このユーティリティ関数専用の言語リソースファイルを別に用意して、i18next を直接使う方法がよさそうだが、リテラルがほとんどないので手間のほうが上回るので、今はやらない。

サーバ環境側でのテストのさいにハマる

ローカル開発環境でのエラーは出なくなったので、アレクサ開発者コンソール Alexa Developer Console の方へ反映することにした。

• index.js をコピペ
• i18n サブフォルダを作成し、その配下に ja.js ファイルを作成し、コピペ
• 自作のユーティリティ関数 DiceRoller.js もコピペ
  ファイルアップロードでの入れ替え方を未だに理解していないため、未だにコピペなんです orz

コンソールでテストしてみたら、起動リクエスト LaunchRequest すらも動かないという致命的なエラー。[ テスト] - [ デバイスのログ] で全部のエラーメッセージを見ると

SKILL_ENDPOINT_ERROR

とかいうエラーが起動リクエスト発行のさいに出ていた。

門前払いかよ！

Cloud Watch の詳細ログを見ると

Unable to import module 'index'

とのこと。そもそも index.js をモジュール（ソース）として読み込むことすらもできていない。いろいろ調べると、依存するモジュールを読み込めていないときに出ることが多いとのことだった。

つまり、つい先ほど追加したライブラリである i18next i18next-sprintf-postprocessor  が最も怪しい。

結論としては：

• 国際化対応のパッケージを追加したさいにプロジェクトの package.json も変わっていたのに、アレクサ開発者コンソールの方へ反映するのを忘れていた

というポカミスだった。

ローカル開発環境の最新の package.json は

{

"name": "diceroller",

"version": "1.0.0",

"description": "",

"main": "index.js",

"scripts": {

"test": "echo \"Error: no test specified\" && exit 1"

},

"author": "tombi.aburage",

"license": "ISC",

"dependencies": {

"ask-sdk": "^2.5.1",

"i18next": "^15.0.9",

"i18next-sprintf-postprocessor": "^0.2.2"

},

"devDependencies": {

"@types/node": "^11.13.4"

}

}

のようになっており、 i18nextなんちゃらの2つが追記されていたようだ。
ファイルの中身を丸ごとコピペ w したら動くようになった。

リファクタリング成功

コンソールで動作確認後、実機 Echo でも無事動作確認がとれた。

しかし、そろそろ手でコピペではなく、自動反映するようにでもしないとダメかねぇ。

Vue.js devtools インストール

Vue.js & Nuxt.js超入門

を参考に、Google Chrome用プラグインをダウンロード。 
 Vue.js デベロッパーツールが追加された。

しかし夜遅かったので、続きはやらずに寝た。

Vue.js のアイコンが見当たらない

翌日、設定の続きをやろうとしたら、デベロッパーツールは発見できたが、Vue.js のアイコンがツールバーに見当たらなかった。

どうやらインストールの時には、普段使っていない Googleアカウントを使っていたらしく、Vue.js のアイコンはそちらに追加されたと思われる。

アカウントを切り替えて、再びインストール作業

全く同じ作業を繰り返して、切り替えたアカウントの方にデベロッパーツールのプラグインを追加した。

すると Vue.js のアイコンが表示され、[拡張機能を管理] ができるようになった。 

 ファイルの URL へのアクセスを許可する

右クリックで設定を行った。

Vue が関係ない画面では、アイコンを押しても何も起きない

左クリックすると、

Vue.js not detected

と表示されて何も起きないが、多分 Vue.js が表示している画面ではないからだろう。

Vue で作られた画面では、

左クリックすると、

Vue.js is detected on this page. Open DevTools and look for the Vue panel.

と表示される。Chrome デベロッパーツールを開くと、Vue タブ（Vue panel）が追加されており、利用できるようになっている。

developer tools に Vue タブが表示された