そういう、モデルなんです。

ビジネスモデル、3Dモデル、設計図、模型などの現状と動向を考察、関連書籍の紹介

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

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

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

出来上がりイメージ

サイコロ係

サイコロ係

 

シーケンス図

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

f:id:tombi-aburage:20190418112157p:plain

Plant UML のインストール

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

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

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

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

@startuml
title サイコロ係に6D8を振らせる
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.javaJava 実行形式ファイルへのパスを設定するのでもいいらしい。

f:id:tombi-aburage:20190418171157p:plain

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

f:id:tombi-aburage:20190305111508p:plain

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実践マスター

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 のベストプラクティスを重視しているようで、コンパイラが導入できたからといって、いきなりコンパイルなどはさせてくれなsい。

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

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

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

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

tombi-aburage.hatenablog.jp

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

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

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

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

f:id:tombi-aburage:20190511083212p:plain

Debugger for Chrome extension に推奨マーク

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

f:id:tombi-aburage:20190511083537p:plain

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

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

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

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

とのこと。

先に言ってよ!

とはいえよく読むと

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

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

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

tombi-aburage.hatenablog.jp

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

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

Azure のサインアップ

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

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

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

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

TypeScript実践マスター

TypeScript実践マスター

 

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

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

f:id:tombi-aburage:20190511190119p:plain

地味な同期ボタン

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

tsc app.ts

f:id:tombi-aburage:20190511190405p:plain

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 の2つと More... が出てきた。

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

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

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

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

launch.json

"sourceMaps": true

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

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

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

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

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

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

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

以下も参照して構築

qiita.com

ここで説明されていた 

  • power-assert
  • intelli-espower-loader

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

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

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

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

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

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

しかし、実は違った。

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

なお、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 したさいに型定義を発見できない。

f:id:tombi-aburage:20190512082726p:plain

require で power-assert を発見できない
また、外部参照問題か…

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

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

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

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

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

お前もローカルか…

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

f:id:tombi-aburage:20190512083627p:plain

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 が起動した。

f:id:tombi-aburage:20190512103928p:plain

_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 のスタックトレースは表示されてしまうのが普通のようなので、放置しておく。

f:id:tombi-aburage:20190512123706p:plain

親切な表示になった

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

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

ああ、面倒くさかった…

 

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

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

ちょうど

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

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

 

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

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

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)

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 上で作成した自分のプログラム(複数個のサイコロを振らせるというスキル)

サイコロ係

サイコロ係

 

f:id:tombi-aburage:20190418112157p:plain

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

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

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

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

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

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

f:id:tombi-aburage:20190414181304p:plain

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)

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

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

f:id:tombi-aburage:20190414202232p:plain

通常の実行は、問題なし

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

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

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

Waiting for the debugger to disconnet...

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

f:id:tombi-aburage:20190414203219p:plain

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

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

blog.hiroppy.me

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

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

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

f:id:tombi-aburage:20190414204417p:plain

おお!止まっている!

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

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 の方に移すことにした。

自作のスキルサービスは

f:id:tombi-aburage:20190418112157p:plain

というシーケンスになっているのだが、スキルインタフェース(図略)からのバウンダリとなっている 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' : 'さようなら。'
}
}

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

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

もう、文言修正ごときで主処理 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超入門

Vue.js & Nuxt.js超入門

 

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

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

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

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

f:id:tombi-aburage:20190413082326p:plain

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

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

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

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

f:id:tombi-aburage:20190413084742p:plain

 ファイルの 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)が追加されており、利用できるようになっている。

f:id:tombi-aburage:20190513090516p:plain

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

 

Node.js command prompt の初期フォルダ変更(失敗)

Node.js command prompt を起動したときに、Node.js をインストールしたCドライブのディレクトリ(フォルダ)が既定になっているのが嫌なので変更

そもそも、どこに設定されているのか調べる

npm config list というコマンドを使えばいいらしい。

npm config list

; cli configs
metrics-registry = "https://registry.npmjs.org/"
scope = ""
user-agent = "npm/6.4.1 node/v10.15.3 win32 x64"

; builtin config undefined
prefix = "C:\\Users\\tombi\\AppData\\Roaming\\npm"

; node bin location = C:\Program Files\nodejs\node.exe
; cwd = C:\Users\tombi
; HOME = C:\Users\tombi
; "npm config ls -l" to show all defaults.

データ用のドライブに設定し直す

npm config set というコマンドを使えばいいらしい。

npm config set HOME E:\User\tombi

変わっていることを確認する。

C:\Users\tombi>npm config list
; cli configs
metrics-registry = "https://registry.npmjs.org/"
scope = ""
user-agent = "npm/6.4.1 node/v10.15.3 win32 x64"

; userconfig C:\Users\tombi\.npmrc
HOME = "E:\\User\\tombi"

; builtin config undefined
prefix = "C:\\Users\\tombi\\AppData\\Roaming\\npm"

; node bin location = C:\Program Files\nodejs\node.exe
; cwd = C:\Users\tombi
; HOME = C:\Users\tombi
; "npm config ls -l" to show all defaults.

userconfig の場所はCドライブのままだよ、という記述が追加されたが HOME の変更はされたようだ。

全く問題なし

どうやら HOME を設定してもダメだったらしい

Node.js コマンドプロンプト Node.js command prompt を再起動したが、相変わらずCドライブのままだった。

Your environment has been set up for using Node.js 10.15.3 (x64) and npm.

C:\Users\tombi>

Cドライブのままだわ…

一旦戻しておく

C:\Users\tombi>npm config set HOME c:\User\tombi

とりあえず、コマンドプロンプトでカレントディレクトリを変更して使うことにする。

Vue.js 環境構築

Vue CLI サービス vue/cli-service-global をインストール(失敗)

npm install -g @vue/cli-service-global

npm ERR! Unexpected end of JSON input while parsing near '...:2614807,"npm-signatu'

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

さっそくエラー。Unexpected end of JSON input って何だろう。

ログを見たが、同じエラーメッセージで参考にならなかった

ぐぐってみたら、キャッシュをクリアすれば解決したとの先例あり。

【解決】npm install -g @vue/cli で、Unexpected end of JSON input while parsing nearが発生した - よしたく blog

よくあることらしい。

Node.js のキャッシュをクリア

npm cache clean --force

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

やった後に警告されてもねぇ。

Vue CLI サービスのインストールを再実行(解決)

npm install -g @vue/cli-service-global

npm WARN deprecated circular-json@0.3.3: CircularJSON is in maintenance only, flatted is its successor.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.7 (node_modules\@vue\cli-service-global\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ @vue/cli-service-global@3.5.5
updated 7 packages in 64.917s

とはいえ、いくつか警告が出ているので、一応ここに記録しておく。

サンプルプログラムの起動テスト(成功)

Vue.js & Nuxt.js超入門

Vue.js & Nuxt.js超入門

 

を見ながらサンプルプログラム app.vue を Visual Studio Code (VSCode) にて打ち込み、vue serve コマンドにてサーバを起動した。

f:id:tombi-aburage:20190413074355p:plain

これで Vue CLI サービスの稼働確認は完了とする。

問題なし

Vue.js devtools で分析できるかも確認しておく(成功)

表示された Vue.js のページを Chromeデベロッパーツールから解析できるアドインのようなものがあるらしい。

tombi-aburage.hatenablog.jp

サンプルプログラムのソースが大したことないので、大したものは見えないが、動作としては問題なし。

問題なし

サンプルソースを改良し、リアルタイムに更新されることを確認

先ほどのサンプルソース app.vue だと、固定テキストを出しているだけなので面白味がない。データ data の値を出力するように改良した。 

<template>
<div id="app">
<h1>Hello!</h1>
<p>{{ text }}</p>
</div>
</template>

<script>
export default {
name: 'HelloWorld',
data(){
return {
text: 'Hello World!'
}
}
}
</script>

<style scoped>
p {color: red;}
</style>

先ほどと同様 vue serve で起動し、Chrome で開いた後で、VS Code で data の text の文字列を更新して保存するとリアルタイムに表示が変わった。

豊富な部品集

github.com

にある部品の Live Demo のページなどを表示させて、Vue の data の値をいじったりすると、連動して変化するのでとても実感が湧いた。

しかし、これだけ部品資産があるのを見ると、新しく作る必要はない気がしてくるな。
見た目で探せるサイトになっているといいのだが、各部品の GitHub へのリンク集になっているだけなので、欲しいものを探すのは楽ではないし品質は不明だ。

  • awesome-vue は評判(品質)が不明だが、部品の数と種類は多い。
  • Vue Curated は目安としていいね(星)数が分かるが、部品はかなり少ない。

という感じのようだ。

他にも、いろいろとライブラリがあるらしい

もう一冊、買ってきた。こちらの方が実際のアプリ開発に近い内容で詳しい。

基礎から学ぶ Vue.js

基礎から学ぶ Vue.js

 
  • Ajax 用ライブラリ axios 

は当然として、

  • ユーティリティライブラリ Lodash

も入れといたほうがよいらしい。

ところで、どうやってテスト駆動開発するのだろう。

コンポーネント(.vue ファイル)の単体テスト方法が良く分からないので、ぐぐった。

lmiller1990.github.io

に「テスト駆動開発環境を準備」というそのまんまの説明があった。

まずは Vue プロジェクトを作成しないといけないらしい。

VueSample というフォルダを作り、そこで VS Codeワークスペース作成、npm init まではやってあったが、vue create はやっていなかった。

1つ上の Projects ディレクトリに戻り、 今あるフォルダと同名の VueSample という名前で Vue プロジェクトを生成することにした。

PS E:\Users\tombi\Projects>vue create VueSample

プロジェクト名に大文字は禁止ですと怒られた。細かいなぁ…全部小文字に直す。
あわせて、既存のフォルダ名も全部小文字に直す。その上で再試行する。

PS E:\Users\tombi\Projects>vue create vuesample

標準の registry の応答が遅いから別の registry に接続するか?といった趣旨のことを訊かれたので、任せたところ、何やらファイルを取りに行き始めたが resolveWithNewModule のメタデータ取得 fetchMetadataで完全に止まってしまった。

Vue CLI v3.5.5
✨ Creating project in E:\Users\tombi\Projects\VueSample\vuesample.
⚙ Installing CLI plugins. This might take a while...
[ ..............] \ fetchMetadata: sill resolveWithNewModule chokidar@2.1.5 checking installable status

Ctrl + C で中断させ、もう一度やってみたところ、なぜか今度は通過できたので良しとする。

毎度おなじみ errno -4048 エラー

しかし、もう少し進んだところで結局エラーとなった。

npm ERR! path E:\Users\tombi\Projects\VueSample\vuesample\node_modules\.staging\postcss-81ed59bb\docs\architecture.md
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall unlink
npm ERR! Error: EPERM: operation not permitted, unlink

(以下略)

このエラー -4048 は、実際には権限の問題ではなく、単なるファイルアクセスのタイミングが悪いだけらしいと分かってきたので、VS Code を再起動し、再試行するだけにした。

VS Code を再起動し、再試行(2回目)(少し進んだ)

PS E:\Users\tombi\Projects\vuesample> cd ..
PS E:\Users\tombi\Projects>vue create vuesample

Overwrite ではなくて Merge の方を選ぶ。

✨ Creating project in E:\Users\tombi\Projects\vuesample.
⚙ Installing CLI plugins. This might take a while...

npm ERR! path E:\Users\tombi\Projects\vuesample\node_modules\.staging\pako-4e2939c1\dist\pako_inflate.js
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall unlink

(以下略)

少し進んだが、違うファイルで同じエラーとなった。再び再試行。

VS Code を再起動し、再試行(3回目)(少し進んだ)

PS E:\Users\tombi\Projects\vuesample> cd ..
PS E:\Users\tombi\Projects>vue create vuesample

Overwrite ではなくて Merge の方を選ぶ。

Vue CLI v3.5.5
✨ Creating project in E:\Users\tombi\Projects\vuesample.
⚙ Installing CLI plugins. This might take a while...

[ ......] \ extract:cssnano-util-get-arguments: sill extract cssnano-util-get-arguments@^4.0.0 extracted to E:\Users\tombi\Projects\vuesample\node_modules\.staging\cssnano-util-get-argum

少し進んだが、別のところ sill extract cssnano なんちゃらの解凍 extract で完全に止まってしまった。Ctrl + C で中断させ、VS Code を再起動し、再試行。

PS E:\Users\tombi\Projects\vuesample> cd ..
PS E:\Users\tombi\Projects>vue create vuesample

Overwrite ではなくて Merge の方を選ぶ。

先ほどの停止箇所は突破し、Installing additional dependencies... のところまで進んだ。

Vue CLI v3.5.5
✨ Creating project in E:\Users\tombi\Projects\vuesample.
⚙ Installing CLI plugins. This might take a while...
> yorkie@2.0.0 install E:\Users\tombi\Projects\vuesample\node_modules\yorkie
> node bin/install.js

setting up Git hooks
done

added 1154 packages from 912 contributors, removed 7 packages and audited 23618 packages in 77.921s
found 0 vulnerabilities

🚀 Invoking generators...
📦 Installing additional dependencies...

[ ......] \ extract:rxjs: sill extract rxjs@^6.4.0 extracted to E:\Users\tombi\Projects\vuesample\node_modules\.staging\rxjs-16032bf1 (42329ms)

しかし別のところ sill extract rxjs なんちゃらの解凍 extract で完全に止まってしまった。Ctrl + C で中断させ、VS Code を再起動し、再試行。

VS Code を再起動し、再試行(4回目)(最後まで進んだ)

PS E:\Users\tombi\Projects> cd ..
PS E:\Users\tombi>vue create vuesample

今度は Overwrite するかは訊かれなかった。

 

(前略)

🎉 Successfully created project vuesample.
👉 Get started with the following commands:

$ cd vuesample
$ npm run serve

どうやら成功したようだ。

※しかし後に、親フォルダを間違って実行していたことが判明する。

Vue.js サンプルアプリ画面が表示された

src サブフォルダ配下に、App.vue というファイルが出来た。

PS E:\Users\tombi> cd vuesample
PS E:\Users\tombi\vuesample> npm run serve

> vuesample@0.1.0 serve E:\Users\tombi\vuesample
> vue-cli-service serve

INFO Starting development server...
98% after emitting CopyPlugin

DONE Compiled successfully in 2044ms 00:21:05
App running at:
- Local: http://localhost:8080/
- Network: http://192.168.179.8:8080/

Note that the development build is not optimized.
To create a production build, run npm run build.

f:id:tombi-aburage:20190514002233p:plain

Chrome で表示した http://localhost:8080

ところが、今回の App.vue は変更してもリアルタイムに Chrome 画面には反映されなかった。ホットリロードを有効にする設定が別にあるのだろうか?

本来の目的だったテスト駆動開発環境の構築は続行できず。

lmiller1990.github.io

の「テスト駆動開発環境を準備」をやるつもりが、どうやら最初に vue create したさいの選択肢をすでに誤っていたらしい。

Manually select features 

 ではなく

default (babel, eslint) 

の方を選んでしまったために、テスト環境が設定できなかった。

さらに4回目の再試行で、親フォルダを間違っていた orz

VSCode で App.vue、HelloWorld.vue をどのように改造しても、一切何も反映されない。ホットリロード以前の問題のようだった。

不審に思ってエクスプローラーでフォルダやファイルを調べたら、Projects フォルダの配下ではなくて、同列・外側に vuesample フォルダが発見された orz 

振り返ると、4回目のコマンドを実行したときのフォルダが間違っている。

PS E:\Users\tombi\Projects> cd ..
PS E:\Users\tombi>vue create vuesample

 ではなく、

PS E:\Users\tombi\Projects\vuesample> cd ..
PS E:\Users\tombi\Projects>vue create vuesample

でなければならなかった。ポカミス。

あわせて「テスト駆動開発環境を準備」も正しく進めることにする。

最初に Manually select features を選び、Unit Testing を正しく選択

Vue CLI v3.5.5
┌───────────────────────────┐
│ Update available: 3.7.0 │
└───────────────────────────┘
? Please pick a preset: Manually select features
? Check the features needed for your project:
(中略)
>(*) Unit Testing
( ) E2E Testing

最終的に、以下の設定でプロジェクトを再生成

Vue CLI v3.5.5
┌───────────────────────────┐
│ Update available: 3.7.0 │
└───────────────────────────┘
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, Linter, Unit
? Pick a linter / formatter config: Airbnb
? Pick additional lint features: (Press <space> to select, <a> to toggle all, <i> to invert selection)Lint on save
? Pick a unit testing solution: Jest
? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.? In package.json
? Save this as a preset for future projects? (y/N) n

VS Code を再起動し、再試行(5回目)(成功)

また止まってしまったので、Ctrl + C で中断後、やり直し。

(前略)

🎉 Successfully created project vuesample.
👉 Get started with the following commands:

$ cd vuesample
$ npm run serve

再試行を5回目繰り返すことにより、ようやく Vue の導入に成功したようだ。

Vue.js サンプルアプリ画面が表示され、App.vue を変更するとリアルタイムに Chrome 画面には反映されるようになった。

しかし、ほとんど盲目的に再試行を5回繰り返すという対処方法は、ちょっと理解しがたい。

yarn なんて導入していないので、指示どおりにテスト実行はできない

lmiller1990.github.io

の「テスト駆動開発環境を準備」では

インストールが終わったら、cd でプロジェクトのディレクトリに移動し、yarn test:unit を実行します。

と書かれているが、

  • そもそも yarn は入っていない。
  • Jest も入っていない

yarn は npm で代替できそうだが、Jest の方は導入しないと話にならぬと思われた。

Jest を導入したら、64個の脆弱性が発見された

npm install --save-dev jest

npm WARN deprecated left-pad@1.3.0: use String.prototype.padStart()
npm WARN deprecated kleur@2.0.2: Please upgrade to kleur@3 or migrate to 'ansi-colors' if you prefer the old syntax. Visit <https://github.com/lukeed/kleur/releases/tag/v3.0.0\> for migration path(s).
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ jest@24.8.0
added 166 packages from 103 contributors, removed 62 packages, updated 88 packages, moved 29 packages and audited 904207 packages in 43.754s
found 64 low severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details

インストールはされたようだが、64個の脆弱性が発見されたとのこと。
使ったことがないコマンド npm audit fix を使うように指示された。

npm audit fix しても治らない

npm audit fix

 npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

up to date in 10.485s
fixed 0 of 64 vulnerabilities in 904207 scanned packages
63 vulnerabilities required manual review and could not be updated
1 package update for 1 vuln involved breaking changes
(use `npm audit fix --force` to install breaking changes; or refer to `npm audit` for steps to fix these manually)

64個の脆弱性が分析されたらしく、更新できない63個と、無理やり更新できないこともない1個に類別された。不可解な英語 vuln の意味が分からない。

npm audit でチェックしてみたが、参照先を見ても何をすればいいのかは、よく分からなかった。ソフトウェア的に危ない部分があるよ、と警鐘を鳴らしている感じの文章だったので、開発者向けなのかもしれない。

Jest の安定バージョンを再インストールしてみる

jestjs.io

で調べると安定バージョンは 24.6 であり、一方 node list で先ほど導入されたものを調べると 24.8 だったので、バージョン指定してやり直すことにした。

npm uninstall jest
npm install --save-dev jest@24.6

 しかしアンインストールしても64個の脆弱性は消えず、バージョン指定して再インストールしても64個の脆弱性は消えない。打つ手がないので、これらは無視することにした。

Jest の単体テストサンプルを実行(成功)

Jest をインストールしたところ、

  • tests (s あり)フォルダ、unit サブフォルダが追加されていた
  • package.json に test:unit という scripts が追加されていた 
npm run test:unit

> vuesample@0.1.0 test:unit E:\Users\tombi\Projects\vuesample
> vue-cli-service test:unit

PASS tests/unit/example.spec.js
HelloWorld.vue
√ renders props.msg when passed (28ms)

Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 2.948s
Ran all test suites.

どうやら Jest のサンプルの起動には、成功したようだ。

 

Wimax2利用時に、電波が届かない部屋を無くしたいならPLC通信がオススメ

コロナになって真価を発揮

自宅内での通信環境改善の手段としてはマイナーであり、あまり知られていないと思われる電力線(PLC)通信。面白半分で購入したが、それほど使わなかったのでお蔵入りにしていたが、コロナ下では一転、愛用品となった。

課題 

Wimax2を自宅で利用しているが、自宅内で無線(Wifi)の電波が届かない、または弱い部屋があって困っている。

前提

ホームネットワーク(自宅内LAN)からインターネット(公衆WAN)への接続は、無線接続(Wimaxルーター経由)となっている。

例えば

のような Wimax 通信プロバイダと契約していて、例えば

Speed Wi-Fi NEXT W05 UQ WiMAX版 GREEN

Speed Wi-Fi NEXT W05 UQ WiMAX版 GREEN

 

のような Wimaxルーターを使っており、

このルーターに対して、パソコンやスマートフォンスマホ)を 

f:id:tombi-aburage:20190409004536p:plain

※ f:id:tombi-aburage:20190409004515p:plain は、Wimaxルーターのネットワーク名(SSID

のように無線(Wifi) で接続することでインターネットを利用している。

課題の背景

  • Wimaxルーターは電波状態が最も良い(アンテナ4本)窓際に置くことが多い。
  • この場合、置き場所から離れた部屋ではWimaxルーターに対して無線(Wifi)で接続ができない、または速度が遅くなる。 
  • 特に冬場・夏場は扉や襖を閉めるので、無線(Wifi)の電波が届きにくい。 

対策 

  •   電力線通信(PLC)で有線LANを構築する
    家庭内の全ての部屋に張り巡らされている電気の配線を、ホームネットワーク(自宅内LAN)の回線として活用する通信方式。コンセントはどの部屋にでも必ずあるので接続に不自由はなく、
    扉など遮蔽物の影響を受けない。 

のようなPLCアダプターと、Wimaxルータークレードル(別売)を利用する。

UQコミュニケーションズ Speed Wi-Fi NEXT W05専用クレードル HWD36PUU

UQコミュニケーションズ Speed Wi-Fi NEXT W05専用クレードル HWD36PUU

 

 ※クレードルは利用している Wimax ルーターの機種を調べ、対応しているものを購入すること(互換性がないので)

評価結果

実際に購入した。南側のリビング(親機、小さい方 TL-PA4010)と、北側の洋室(子機、大きい方 TL-WPA4220)間をPLC接続にしてみたら、問題なく繋がった。

  1. クレードルWimaxルーターを載せる
  2. クレードルとPLCアダプターの親機をLANケーブルで接続する
  3. PLCアダプターの親機をコンセントに挿す
  4. PLCアダプターの子機をコンセントに挿し、親機とペアリングする
  5. PLCアダプターの子機に無線(Wifi)または有線LANで接続する

アダプタのLED表示について

どうなっていれば正しい状態なのか、マニュアルでは分かりにくかったため、親機と子機のペアリングには少し手間取った。(ペアリングのボタンを長押ししすぎて、ペアリングがリセットされたりして少々ハマった。)

正常に稼働している時のLED表示は、以下のとおり:

  • 親機のLEDは3つとも緑に点灯
    PLCアダプターはコンセントに直接差し込むものなので、電源LED(〇に縦棒のスイッチアイコン)が点灯しないという事態はさすがにおきないだろう。
    電力線通信(家アイコン)のLEDが点灯していないときは、おそらくは子機とのペアリングに失敗しており、電力線通信が起動していない。同じコンセントまたはテーブルタップに親機と子機を隣り合わせで並べて、再度ペアリングからやり直すこと。
    有線LAN(長方形を3つ線で繋げたアイコン)のLEDが点灯していないときは、親機からルーターへのネットワーク接続が確立していない。LANケーブルの差し込み具合や、ルーターの電源を確認すること。
  • 子機のLEDは、電源LED、電力線通信の2つは緑に点灯している。残りの2つのLED(有線LAN、無線 Wifi)は、アダプタと利用者端末との間でネットワーク接続が確立していれば緑に点灯する。(有線LANを使っていないならば、有線LANのLEDは緑に点灯しなくて差し支えない)

ペアリングに成功した後、PLCアダプタを親機・子機ともに一旦コンセントから外して、また両方とも挿し直した場合のLED表示は、以下のとおり:

  • 親機・子機ともに、通電しているコンセントに挿して数秒以内に、電源LED、電力線通信LEDの2つが緑色に点灯する。
    f:id:tombi-aburage:20190411073903j:image
  • 上記2つのLEDより5~6秒くらい遅れて、子機の無線 WifiのLEDが緑色に点灯する。
  • 子機だけをコンセントから外すと、10秒くらい遅れて、親機の電力線通信LEDも消灯する。さらにしばらく放置すると、電源LEDも消灯する。
  • 親機からルーターへの有線LAN接続を切断すると、親機・子機のLEDは不可解な挙動をする。電力線通信LED、電源LEDすらも消灯することがある。
    おそらくは省電力モードに入っているのだろう。
  • 有線LANのLEDは、ネットワーク接続に成功していれば緑色に点灯する。
    たんにLANケーブルだけ挿していても、ネットワーク接続が確立していなければ、点灯することはない。

レグザリンク・シェアには失敗

電力線通信には成功したものの、南側リビングの Regza C310X と、北側寝室(洋室)の Regza 32R1BDP をレグザリンク・シェアで接続することには失敗した。

https://www.toshiba.co.jp/regza/lineup/c310x/images/top_main_img01.jpg

https://www.toshiba.co.jp/regza/link/image/share/image_interst_g2.jpg 

https://www.toshiba.co.jp/regza/lineup/r1bdp/images/concept_img_main.jpg

出典:何れも、東芝映像ソリューション

東芝のレグザリンクのサイトで R1 がレグザリンク・シェアに対応と書いてあったので、Regza R1BDP も Regza R1 と同様の扱いだと思ったのだが、BDP はブルーレイディスクが付いている代わりにレグザリンク・シェア(DLNA 対応)はしていなかったというオチだった。

両方のマニュアルをダウンロードして、じっくり見比べてみると、R1BDP の準備編マニュアルのほうには、レグザリンク・シェアに関する説明が確かになかった orz

まあ10年位前のレグザ(時価5千円以下)なので、もし繋がったら奇跡レベルだが。

ということで、せっかく購入したPLCアダプタは、別の用途が必要になるまでお蔵入りとなった。数年前と違って、安かったからいいけど…

その他の対策案