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

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

Git リモートレポジトリ作成と、ローカルレポジトリとの同期設定

これまでは、ローカル環境に閉じた Git 利用しかしていなかったが、自宅の複数台のパソコンと、職場パソコンに別々に似たようなプロジェクトフォルダと Git レポジトリを次々と作成した結果、さっそく自分の中ですら運用が破綻した w

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

それぞれのローカルレポジトリへのUSB wでの相互コピーで運用破綻 orz

世の中的には、リモートレポジトリを正本として先に作成してから、ローカルの開発環境に関連付けるという方法が普通だったらしい。そりゃそうだわ・・・

GitHub でレポジトリ作成

GitHub についてはアカウント作成済みだったが、レポジトリは作っていなかったので作った。レポジトリ名を推奨してくれるのだが、なんだコレ・・・

cautious-computing-machine ? 俺への当てこすりか!

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

GitHub が考えた Repository の名前

・・・とりあえず素直に TypeScriptSample で作ることにした。

README と .gitignore の追加は行わず、完全に空っぽのレポジトリを生成した。

ほとんど即座に

https://github.com/ユーザ名/TypeScriptSample.git

で作成されたようだ。と同時に、このレポジトリと同期するローカルレポジトリを作成するための方法等が書かれている Code タブが表示された。

なお現在では、無料アカウントでも private レポジトリをいくつでも作れるようになった。

個人レベルではこれで十分。

Azure DevOps (旧称 VSTS)でもプロジェクトを作成し、レポジトリ同期を試みたが断念

さきほどの本家本元 GitHub レポジトリで用は足りているのだが、VSTS から参照するような形に簡単に設定できるのかどうか興味があったので、試してみた。

VSTS すでに無し

まず Visual Studio Team Services (VSTS)を Microsoft のサイトで探したが、もはやこの名称は過去のものとなっており、今では Azure DevOps というらしかった。

VSTS は Azure DevOps に変わりました!

本家本元 GitHub と Azure DevOps は別物

GitHubMicrosoft に最近買収されたが、GitHub サイトは昔のまま存在している。
アカウントについては、Azure DevOps にログインするさいに GitHub アカウントを連動させることができるようになっている。

連動した GitHub アカウントを使って Azure DevOps にサインインして、TypeScriptSample というプロジェクトを作成した。

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

Azure DevOps で新規プロジェクト作成

先ほど作成した Git レポジトリと同名のプロジェクト名にしておけば、自動的にレポジトリがプロジェクトに割り当てられるのかも…と思っていたが、特に自動で割り当てられたりはしなかった。

Git レポジトリへの URL の命名体系も全くの別物

新たに別のレポジトリを作成することは左端の Repos タブから簡単に行えるが、そのさいのレポジトリの名称は

https://ユーザ名/@dev.azure.com/ユーザ名/TypeScriptSample/_git/TypeScriptSample

のようになっており、命名規則は全く違うものとなっていた。

「Clone in VS Code」ボタンなんて飾りですよ

なお「Clone in Vs Code」とかいう便利そうなボタンがあったので、押してみたが、VS Code が自動的に起動しただけで、それ以上、別に何も起きなかった。

何なんだ一体・・・

パスワードの規則が微妙に厳しいのがウザい

レポジトリの自動的な複製 Clone は行われなかったようなので、手動でやるしかなさそうだ。

TypeScript実践マスター

TypeScript実践マスター

 

のとおりに資格情報を作成 Generate Git credentials して VS Code 側からアクセスしにいく方法で進めていくことにした。

しかし資格情報のパスワードの条件が本家本元 GitHub よりも厳しく、大文字・小文字・数字・記号のうち3つ混在要とのこと。

新しく別のパスワードを考えないといけない・・・

考えるのが面倒・・・断念。

さっき GitHub で作ったレポジトリで妥協することにした。

とりあえず先ほど本家本元 GitHub で作成したレポジトリの方を使うことにした。

まだ DevOps 使わないんで

GitHub の画面からローカルレポジトリ作成(無反応)

まだローカル環境(PC環境、VS Code)側にはレポジトリが無いので、正本である GitHub 上のレポジトリの写しを作る必要がある。

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

Quick setup - Set up in Desktop

そこで GitHub の画面上にあった「Setup in Desktop 」ボタンを押してみた。
・・・またしても何も起きなかった。

またか。何なんだ一体!?

レポジトリの自動的な構築 Set up とやらは行われなかったようなので手動でやる。

TypeScript実践マスター

TypeScript実践マスター

 

のとおりに VS Code 側からアクセスしにいく方法で進めていくことにした。

  • まず VS Code で適当なプロジェクト(ワークスペース)をローカルに作成。
  • その後、コマンドパレット View - Command Palette から Git : Clone

GitHub へのログイン画面ダイアログが表示された後、VS Code の画面上は特に目立った反応もなく終了した。

一応、指定したローカルディスクのフォルダ配下に新しい .git フォルダが作成されていたので、多分、これで成功したのだろう。

ローカルレポジトリからリモートレポジトリへの反映

VS Code で適当にテスト用のテキストファイルを作成し、まずローカルレポジトリにコミット。その後、VS Code の画面左下にある、きわめて見づらいクラウドへのアップロードボタンを押した。

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

リモートレポジトリへ反映するボタン(?)

定期的にリモートレポジトリを参照する設定にするかを訊かれたが、利用者は自分だけなので、いいえ No とした。このタイミングで聞いてくるのは何故だろうと思いつつ。

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

定期的に git fetch するか訊かれたが、いいえ No

Git Hub の Code タブの表示がガラリと変わり、このレポジトリと同期するローカルレポジトリを作成するための方法等は最早表示されなくなった。かわりに同期されたファイル名が表示されている。

うまくいったようだ。

なお作成方法を見たい場合は下記のように、空のレポジトリを適当に作ればよい。

GitHub でのレポジトリ作成時には、完全に空っぽで作成するのが吉

さきほど成功した例では、GitHub のレポジトリに README、.gitignore は自動生成させていなかった。しかし README はともかくとして .gitignore は必ず使っているので、自動生成させるパターンでやってみることにした。

そしたら見事にハマった。

GitHub のレポジトリ作成画面において、一番下にある Add .gitignore を選ぶと 使用言語に適した .gitignore ファイルが自動追加される。

この .gitignore 自体は、それなりに気が利いている内容のファイルなのだが、

  1. ファイルを生成したためにレポジトリが空ではなくなり、接続手順ページが表示されなくなる
  2. この後に行う VS Code との同期設定が激しく難航する

などの副作用があった。このうち1つめについては

  • いつでも接続・設定方法を参照できるように empty というプロジェクトを作成し、接続手順ページをいつでも参照できるようにする

ことで恒久対処したが、2つめについては実力不足で解決できなかった。

tombi-aburage.hatenablog.jp

とりあえず、レポジトリ作成時には、いかなるファイルも生成しないことに決めた。

空の GitHub リモートレポジトリ作成より前に、ローカルレポジトリを作っている場合

リモートレポジトリ GitHub を作成後、

…or push an existing repository from the command line

に記載のコマンドのとおり連携させるだけだった。とても簡単。

GitHub リモートレポジトリはあるが、ローカルレポジトリは全くない場合

  • コマンドパレット View - Command Palette から Git : Clone
  • プロジェクト(およびレポジトリ)の親となるべきフォルダを選択
    複製 Clone 時に GitHub レポジトリと同名のフォルダが自動的に作成されるので、プロジェクト(レポジトリ)フォルダは事前に用意しないように。

 プロキシ経由の場合は追加の設定が必要となる

自宅ではプロキシ無しだったため、すんなりインターネット上の GitHub に接続できた。しかし職場ではプロキシ有りなので、最初はうまく接続できず、結局のところ追加設定をする必要があった。

sushichop.blogspot.com

を参考にして、プロキシ環境設定を行った。 

tombi-aburage.hatenablog.jp

の場合と同様に、

  • auth.pacファイルを解析してプロキシの実アドレスを特定
  • プロキシ用のユーザ名/パスワードを含めたURLを git config コマンドで登録
git config --global http.proxy ~
git config --global https.proxy ~

する必要があった。

ローカルPC環境の VS Code から GitHub レポジトリとの同期をかける

プロキシには認証の設定がされているため、都度都度、認証が要求されている。

画面入力は勘弁して・・・
  1. まず GitHub へのログイン画面で、GitHub 用のユーザ名/パスワードを入力させられ、

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

    GitHub Login


  2. そののち、VS Code のコマンドパレット?でも、GitHub 用のユーザを入力させられ、

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

    VS Code でも Username を入力


  3. そののち、GitHub 用のユーザ名/パスワードを入力させられた。

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

    VS Code でも Password を入力

認証がくどいが、とりあえずリモート側との同期には成功したので、良しとする。

特に問題なし

パスワード保存

面倒くさいので、認証情報を保存することにした。

git config --global credential.helper store

しかし、何の応答もなく完了した。

D:\Users\tombi\AppData\Local\Programs\Git\mingw64\etc\gitconfig

をみても、パスワードが保存されている様子はなかった。

C:\Users\tombi\.gitconfig、C:\Users\tombi\.git-credentials

をみたところ、.git-credentials にハッシュされたパスワードのようなものが保存されている様子だった。

Windows 資格情報の管理 の画面を見ると、更新日時:今日となっていたので、多分反映されているのだろう。

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

Windows 資格情報の管理
問題なし

 

画面操作を自動化するツール Puppeteer (パペティア)職場環境では動かない…(解決)

ここまでのあらすじ

さまざまなトラブルを乗り越え、とにかく自宅のパソコンでは Puppeteer が動作する状態にした。

tombi-aburage.hatenablog.jp

Google での検索結果の参照先を次々と開いて、画像でひたすら保存するスクリプトなどを書いてみたら、うまいこと動作したので、これなら仕事の情報収集でも使えそうだと判断した。

職場のパソコンにインストール

自宅のパソコンで成功したときと同じ手順で、ローカルインストールしようとしたが、まるでうまくいかない。

npm install から、いきなりコケた。

npm install --save puppeteer

npm ERR! code ENOTFOUND
npm ERR! errno ENOTFOUND
npm ERR! network request to https://registry.npmjs.org/puppeteer failed, reason: getaddrinfo ENOTFOUND registry.npmjs.org registry.npmjs.org:443
npm ERR! network This is a problem related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly. See: 'npm help config'

npm ERR! A complete log of this run can be found in:
npm ERR! C:Users ombiAppDataRoaming pm-cache_logs9-05-08T03_28_28_136Z-debug.log

親切にもプロキシが怪しいと書いてある。言う通り職場のプロキシのせいに違いない。

qiita.com

を参考にして npm のプロキシ設定を行うことにする。

proxy と https-proxy に職場指定の auth.pac とかいうファイルを指定

call npm -g config set proxy "http://example.com/auth.pac"
call npm -g config set https-proxy "http://example.com/auth.pac"

この環境設定コマンドは成功した。しかし npm install はやはりうまくいかない。

npm install --save puppeteer

npm ERR! code E405
npm ERR! 405 Method Not Allowed: puppeteer@latest

npm ERR! A complete log of this run can be found in:
npm ERR! C:Users ombiAppDataRoaming pm-cache_logs9-05-08T03_31_43_005Z-debug.log

今度は E405 とかいうエラーに変わった。

registry も設定

call npm -g config set registry "http://registry.npmjs.org/"

この環境設定コマンドは成功した。しかし npm install はやはりうまくいかない。

npm install --save puppeteer

npm ERR! code E404
npm ERR! 404 Not Found: puppeteer@latest

npm ERR! A complete log of this run can be found in:
npm ERR! C:Users ombiAppDataRoaming pm-cache_logs9-05-08T03_36_03_259Z-debug.log

今度は E404 とかいうエラーに変わった。

どう見てもプロキシが怪しい

プロキシ認証を通るよう、パスワード等を指定する

普段からプロキシにアクセスするたびにユーザ名とパスワードを入力しているので、これらの指定をしないとダメなのかもしれない。

qiita.com

を参考にして、

  • まず .PACファイルの中を見て、プロキシの実URLアドレスを割り出す
  • ユーザ名とパスワードを指定したURL表記で設定する

ことにした。

.PACファイル http://example.com/auth.pac をブラウザで覗いてみると、JavaScript の関数みたいなものが書いてあった。

どうやら自分のIPアドレスとアクセス先のURLから、使うプロキシを判定する処理の関数らしかったので、スクリプトの処理内容を分析して、職場パソコンのIPアドレスに対応するプロキシの実URLアドレスを割り出した。

npm config set proxy http://userid:password@proxy.example.com:8080
npm config set https-proxy http://userid:password@proxy.example.com:8080

今度は code EPERM, errono -4048, syscall rename  エラー

先の環境設定コマンドは成功した。しかし npm install はやはりうまくいかない。

npm install --save puppeteer

npm ERR! path P:projectspuppeteer_sample ode_modulesminimistpackage.json.3444437947
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall rename
npm ERR! Error: EPERM: operation not permitted, rename 'P:projectspuppeteer_sample ode_modulesminimistpackage.json.3444437947' -> 'P:projectspuppeteer_sample ode_modulesminimistpackage.json'
(中略)
npm ERR! The operation was rejected by your operating system.
npm ERR! It's possible that the file was already in use (by a text editor or antivirus),
npm ERR! or that you lack permissions to access it.
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator (though this is not recommended).

OSに拒否されて、ファイルをリネームできないとのこと。

インストール先の P ドライブがローカルではなく、ネットワーク上のドライブであることが関係しているのかもしれない。

職場のネットワークドライブのアクセス権限を変更することはできないので、お奨めしない not recommended と書かれてはいるが「管理者として実行」することにした。(command again as root/Administrator 相当)

なお、このときはすぐに「管理者として実行」をやってしまったが、VS Code を再起動(もしくはパソコンごと再起動)し、ただ同じコマンドを打ち直すだけで治ることも多い。

アクセス権と関係なく、何かのプロセスがファイルをつかんでいて、ファイル操作のタイミングが合わなかった場合にも errno -4048  が出るようだ。

node.js command prompt を管理者として実行してから install

npm install --save puppeteer

> puppeteer@1.15.0 install P:projectspuppeteer_sample ode_modulespuppeteer
> node install.js

Downloading Chromium r650583 - 144.8 Mb [=== ] 17% 204.2s

Chromiumダウンロードに進んだようだ。よしよし。

やはりプロキシだったか

正しくインストールされた模様

Downloading Chromium r650583 - 144.8 Mb [====================] 100% 0.0s
Chromium downloaded to P:projectspuppeteer_sample ode_modulespuppeteer.local-chromiumwin64-650583
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN puppeteer_sample@1.0.0 No description
npm WARN puppeteer_sample@1.0.0 No repository field.

+ puppeteer@1.15.0
added 6 packages from 6 contributors and audited 50 packages in 610.199s
found 0 vulnerabilities

ゲージが100%になった後、続きのメッセージが出るまでに30秒以上待たされ、また失敗したのかと思ったが、無事にインストールは完了した。

全く問題なし

自宅パソコンで動作した実績のあるサンプルスクリプトを職場で起動したが、newPage 呼び出しが永久に終わらない orz

職場のネットワークの遅さのせいなのか、プロキシ経由のせいなのか、パソコンの低性能のせいなのか原因は分からないが、自宅のパソコン(環境)と比べると明らかに動作が遅い。

高々 puppeteer の launch、Chromium の起動までに30秒くらいかかった。
しかし、その後 newPage メソッドを呼び出すところで完全に止まってしまい、それ以上はまったく進まず、常にタイムアウトになってしまう。

いろいろ調べたが同一事象の前例はなくて、行き詰ってしまった。

launch が遅いというケースは多いようだが、newPage で止まる事例は見当たらない。

残念ながら職場では使えないようだ…

なぜ newPage で止まる?

Error: Page crashed!、CDPSession.Page が出ている

ソースの随所にコンソール出力を入れて切り分けた結果、launch までは動作しており、page オブジェクトの生成のところで止まっていることが分かった。

ネットで色々調べたところ、特徴的なエラーメッセージは Error: Page crashed!、CDPSession.Page といえそうだった。

この CDPSession とやらは、puppeteer と Chromium 間のローカルなプロトコルのセッションらしく、それが通っていない(プロセス間通信途絶)ように見えたので、Chromium の起動モードが怪しい?

npm run main

> puppeteer_sample@1.0.0 main P:projectsPuppeteerSample
> index.js

start 16:15:41 GMT+0900 (GMT+09:00)
require 完了 16:16:19 GMT+0900 (GMT+09:00)
launch 完了16:16:25 GMT+0900 (GMT+09:00)
(node:10192) UnhandledPromiseRejectionWarning: Error: Page crashed!
at Page._onTargetCrashed (P:projectsPuppeteerSample ode_modulespuppeteerlibPage.js:170:24)
at CDPSession.Page.client.on.event
(以下略)

プロキシはエラーと関係なし、--no-sandbox 指定で解決

切り分けには延べ日数で4日ほどかかった。

結論としては launch のさいに指定ができる args に --no-sandbox を指定するだけで、先ほどのエラーは出なくなった。

const browser = await puppeteer.launch({
headless: true,
slowMo: 50,
args: [
'--no-sandbox',
]
});

start 16:54:12 GMT+0900 (GMT+09:00)
require 完了 16:54:36 GMT+0900 (GMT+09:00)
launch 完了16:54:39 GMT+0900 (GMT+09:00)
newPage 完了16:54:42 GMT+0900 (GMT+09:00)
setViewport 完了16:54:42 GMT+0900 (GMT+09:00)

--no-sandbox 必須だな…

プロキシのユーザID、パスワードは authenticate で指定

エラーとは関係なかったが、headless: false で動作確認したところプロキシがユーザID、パスワードを要求するダイログを出していたので、以下の要領で記述した。

await page.authenticate({
username: 'プロキシのユーザID',
password: 'プロキシのパスワード'
});

なお args に --proxy-server を指定する必要はなかった。

ようやく、職場でも問題なし

 

ES Lint

VS Code に拡張を追加

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

Extension : ESLint

プロジェクト(ワークスペース)配下にパッケージ追加

フォルダは puppeteer_sample

npm install --save-dev eslint

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

+ eslint@5.16.0
added 100 packages from 63 contributors and audited 234 packages in 17.361s
found 0 vulnerabilities

node .\node_modules\eslint\bin\eslint.js --init

? How would you like to use ESLint? To check syntax and find problems
? What type of modules does your project use? CommonJS (require/exports)
? Which framework does your project use? None of these
? Where does your code run? Node
? What format do you want your config file to be in? JSON

どれを選ぶべきか、よくわからないがもっともらしいものを選んだ。

出力フォルダにて動作確認

出力 OUTPUT のプルダウンより ESLint を選択すると、動作中とのことだった。

[Info - 14:47:41] ESLint server stopped.
[Info - 14:47:42] ESLint server running in node v10.2.0
[Info - 14:47:42] ESLint server is running.
[Info - 14:47:45] ESLint library loaded from: c:\Users\tombi\Documents\projects\puppeteer_sample\node_modules\eslint\lib\api.js

画面操作を自動化するツール Puppeteer (パペティア)グローバルインストールは失敗に終わる

パペティア Puppeteer はセレニウム Selenium よりも環境設定が楽らしい。
React(リアクト)などのSPAアプリにも向いているそうな。

Puppeteer入門 スクレイピング+Web操作自動処理プログラミング

Puppeteer入門 スクレイピング+Web操作自動処理プログラミング

 

上記書籍ではグローバルインストールではうまくいかなかったとのことだが、ダメモトでやってみたら入ったので、まずはヨシとする。

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

puppeteer パッケージをインストール

npm install -g --save puppeteer

> puppeteer@1.15.0 install C:\Users\tombi\AppData\Roaming\npm\node_modules\puppeteer
> node install.js

Downloading Chromium r650583 - 144.8 Mb [====================] 100% 0.0s
Chromium downloaded to C:\Users\tombi\AppData\Roaming\npm\node_modules\puppeteer\.local-chromium\win64-650583
+ puppeteer@1.15.0
added 43 packages from 22 contributors in 28.838s

一見、全く問題なし

Chromiumと puppeteer がまとめてインストールされたようだ。

Node.js および VS Code のプロジェクト新規作成

npm init

ドキュメントフォルダ配下に projects、さらにその下にpuppeteer フォルダを作成した後、npm init 。その後、VS Codeワークスペースにフォルダを追加した。

puppeteer 公式サンプルプログラム screenshot.js で動作確認(ポカミス)

サンプルの最新版をぐぐったら、以下のサイトに紹介があった。

qiita.com

ここから公式のサンプルプログラムの GitHub へ行けたので、screenshot.js を右クリックし、VIsual Studio CodeVS Codeワークスペース配下のフォルダへとダウンロード。

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

screenshot.js

VS Code のターミナル TERMINAL からさっそく起動

node .\screenshot.js

C:\Users\tombi\Documents\projects\puppeteer\screenshot.js:7
<!DOCTYPE html>
^

SyntaxError: Unexpected token <
at new Script (vm.js:80:7)
at createScript (vm.js:274:10)
at Object.runInThisContext (vm.js:326:10)
at Module._compile (internal/modules/cjs/loader.js:664:28)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
at Module.load (internal/modules/cjs/loader.js:600:32)
at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
at Function.Module._load (internal/modules/cjs/loader.js:531:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
at startup (internal/bootstrap/node.js:283:19)

エラー?サンプルなのに?

puppeteer パッケージをインストール

ファイルの中身をチェックしてみたら、「screenshot.js そのもの」ではなくて、「screenshot.js の解説ページの html ファイル」だった…

GitHub の一覧から右クリックでいきなり保存したのが間違いだったらしい。

ポカミスでした orz

GitHub Desktop インストール(寄り道)

一覧の先の解説ページを開き、「screenshot.js そのもの」をダウンロードしようとしたところ、このファイルを GitHub Desktop で開くというアイコンがあったのでクリック。

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

クリックするとダウンロードページがでかでかと表示された。

すでに GitHub はインストール済みなのだが、それは Desktop Classic とかいう旧式のものであり、実は、もっとカッチョイイ Electron 版バージョンがあるらしい。

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

確かに Classic の画面はしょぼかった。かっこいいのが使いたい。

ということでインストールしてみると、Github のアカウントも作りなさい、とのことだったので、それも作った。

その後、

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

をクリックすると、またダウンロードページがでかでかと表示された。 
開くんと違うんかい!

・・・いや落ち着け、Chrome を再起動していなかったわ。

再び、サンプルスクリプト(一式)をダウンロード

Chrome を再起動してから、同じアイコンを再びクリックすると、GitHub Desktop と関連付けるか質問された。関連付けすると、直接起動されて以下の画面が出た。

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

よくわからないが、リモートレポジトリ(正本)から、ローカルにクローン(コピー)しようとしているようだ。

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

Cloning Puppeteer ...

クローン Clone ボタンを押すと、意に反して screenshot.js だけではなく、全てのサンプルプログラムをダウンロードし始めた。

 C:\Users\tombi\Documents\GitHub\puppeteer\examples

配下に、8つのサンプルがダウンロード(クローン) Clone されたようだ。

やった後で言うのも何だが、この GitHub Desktop のインストール作業は余計だったな。

再び、サンプルプログラム screenshot.js の動作確認(失敗)

プロジェクト(ワークスペース)に screenshot.js をコピーしてから、VS Code のターミナル TERMINAL より再び起動した。

node .\screenshot.js

PS C:\Users\tombi\Documents\projects\puppeteer> node .\screenshot.js
internal/modules/cjs/loader.js:584
throw err;
^

Error: Cannot find module 'puppeteer'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15)
at Function.Module._load (internal/modules/cjs/loader.js:508:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at Object.<anonymous> (C:\Users\tombi\Documents\projects\puppeteer\screenshot.js:19:19)
at Module._compile (internal/modules/cjs/loader.js:701:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
at Module.load (internal/modules/cjs/loader.js:600:32)
at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
at Function.Module._load (internal/modules/cjs/loader.js:531:3)

モジュール puppeteer を発見できていないとのこと。

やはり、また起きたか…
Puppeteer入門 スクレイピング+Web操作自動処理プログラミング

Puppeteer入門 スクレイピング+Web操作自動処理プログラミング

 

の推奨を無視して、puppeteer をグローバルインストールした罰があたったようだ。

しかしもう少し、粘ってみる。

puppeter を依存パッケージに指定して、起動させるようにしてみる。

先ほどは node コマンドで screenshot.js を直接起動していたが、npm コマンドで起動する方法に変更することにした。

そもそも npm init のさいに package.json を適当に作っていたため、

  • dependencies 記述なし
  • scripts 記述なし

だったので、まずはこれを修正する。

{
"name": "puppeteer",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC"
}

下記のとおり、記述を追加した。

{
"name": "puppeteer",
"version": "1.0.0",
"description": "",
"main": "screenshot.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
,"main": "screenshot.js"
},
"author": "",
"license": "ISC",
"dependencies": {
"puppeteer" : "^1.15.0"
}
}

npm run コマンドから起動してみた。

npm run main

> puppeteer@1.0.0 main C:\Users\tombi\Documents\projects\puppeteer
> screenshot.js

画面上に盛大なエラー・ダイアログが出現

コード: 800A03EA
ソース:Microsoft JScript コンパイルエラー

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

どうも node.js でも Chronium でもなく、Microsoft 謹製の JavaScript 実行エンジンのほうが呼び出されているように思える。

JScript は、お呼びでない!

なお screenshot.js の19行目は

const puppeteer = require('puppeteer');

なので、ほとんど起動直後に落ちているようだ。

「OK」ボタンをクリックすると、ターミナル TERMINAL に、ゾロゾロと続きのエラーが出力された。

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! puppeteer@1.0.0 main: `screenshot.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the puppeteer@1.0.0 main script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?

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

puppeteer のバージョンは 1.4.0 のはずなのに、1.0.0 と出力されている?のは気になる。最後のログは、中を見ても、よく分からなかった。

node_modules missing ?

まずは、Microsoft JScript 実行環境が呼ばれないようにする。

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

Microsoft ® Windows Based Script Host に関連付けされている

試しに JavaScript ファイル (.js)の関連付けを node.exe に変更してみる。

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

node.exe に関連付けが変更された。

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

JavaScript ファイル(.js) は node.exe に関連付けること

なお別のPCで、JavaScript ファイル(.js) を Visual Studio Code (VSCode) に関連付けしていた(ダブルクリックでソースを開きたいから)ところ、

  • npm run を実行しても、一切スクリプトが実行されない
    console.log('test'); しか書いていないスクリプトなのに何も出力されない

という事象となりハマった。

詳しく調べると:

  1. npm によって package.json は処理されているようだが、スクリプト本体のコード内容は実行されていない
  2. Visual Studio Code の terminal で npm run を行うと、スクリプトソースコードにフォーカス(カーソル)が移動する
  3. Node.js command prompt で npm run を行うと、Visual Studio Code が起動し、スクリプトソースコードが開く

という事象だった。2の挙動は微妙な変化だったので気づかなかったが、3の挙動より、関連付けが原因らしいと、ようやくわかった。(2時間浪費)

Windows 環境では、

  • JavaScript ファイル(.js) は node.exe に関連付けること

は必須であり、それを勝手に変更してはいけないようだ。

Microsoft JScript コンパイルエラー」は消えたが…

再び npm から起動。

Microsoft JScript コンパイルエラー」のダイアログは出なくなった。一歩前進。
しかし、かわりにスタックトレースが吐き出された。

npm run main

> puppeteer@1.0.0 main C:\Users\tombi\Documents\projects\puppeteer
> screenshot.js

> puppeteer@1.0.0 main C:\Users\tombi\Documents\projects\puppeteer
> screenshot.js

internal/modules/cjs/loader.js:584
throw err;
^

Error: Cannot find module 'puppeteer'
スタックトレースは中略)

npm ERR! code ELIFECYCLE
(内容は先ほどと同じなので、以下略)

さっきのエラーと同じだな...

あいかわらず、

npm WARN Local package.json exists, but node_modules missing, did you mean to install?

のように警告されているので、やはり puppeter をローカルインストールしないといけないのだろうか?

だが、もう少し粘ってみる。

足りないモジュールをインストールするコマンドがあるらしい。

 Cannot find module 'puppeteer’ でぐぐった。

qiita.com

に書かれていた

npm install -g npm-install-missing

C:\Users\tombi\AppData\Roaming\npm\npm-install-missing -> C:\Users\tombi\AppData\Roaming\npm\node_modules\npm-install-missing\bin\npm-install-missing
+ npm-install-missing@0.1.4
added 429 packages from 802 contributors in 22.112s

node.js のインストール先配下に、たくさんのファイルが追加されたようだ。

しかし、 どうやらpuppeteer が追加されたわけではなく、npm run main の結果は

Error: Cannot find module 'puppeteer'

であり、先ほどと同じ。つまり、解決はしなかった。

qiita.com

 とあるが、余計な環境変数を余計なファイルに追加するくらいなら、ローカルインストールの方が依存が少なく素直なので、グローバルインストールはギブアップ。

グローバルでは無理。

グローバルインストールは断念、ローカルインストールに切り替え。

まずはグローバルインストールを削除する。

npm uninstall -g puppeteer

removed 43 packages in 0.836s

ローカルインストールする。 

npm install --save puppeteer

npm ERR! code ENOSELF
npm ERR! Refusing to install package with name "puppeteer" under a package
npm ERR! also called "puppeteer". Did you name your project the same
npm ERR! as the dependency you're installing?
npm ERR!
npm ERR! For more information, see:
npm ERR! <https://docs.npmjs.com/cli/install#limitations-of-npms-install-algorithm>

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

プロジェクト(ワークスペース)フォルダが puppeteer という名前だと、ローカルインストールさせてくれないのだろうか?

プロジェクト(ワークスペース)フォルダをリネーム

を行ってから再度インストール

npm install --save puppeteer

同じエラーだった。どうやらフォルダ名は関係がなかったらしい。
とはいえ、元の紛らわしいフォルダ名に戻す必要もないので、そのまま続行。

package.json の name を変更

package.json の "name" が "puppeteer" であることが問題だったらしい。
こちらも puppeteer_sample に修正する。

{
"name": "puppeteer_sample",
"version": "1.0.0",
"description": "",
"main": "screenshot.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"main": "screenshot.js"
},
"author": "",
"license": "ISC",
"dependencies": {
"puppeteer": "^1.15.0"
}
}

修正後に、再度ローカルインストール。

npm install --save puppeteer

> puppeteer@1.15.0 install C:\Users\tombi\Documents\projects\puppeteer_sample\node_modules\puppeteer
> node install.js

Downloading Chromium r650583 - 144.8 Mb [====================] 100% 0.0s
Chromium downloaded to C:\Users\tombi\Documents\projects\puppeteer_sample\node_modules\puppeteer\.local-chromium\win64-650583
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN puppeteer_sample@1.0.0 No description
npm WARN puppeteer_sample@1.0.0 No repository field.

+ puppeteer@1.15.0
added 43 packages from 22 contributors and audited 50 packages in 29.446s
found 0 vulnerabilities

一見、全く問題なし

さっそく、サンプルスクリプトを起動する。

npm run main

ノートンファイアウォール警告が出現した。

Chromium が起動したようだが、これはノートンにとっては、初めて起動された要注意プログラムなので利用者(私)に通信を許可するかをきいてきた。

しかし次から次へと色々起きるな・・・とりあえず画面キャプチャ。

その後、ノートンの設定が「常に許可」となっていることを確認して続行した。

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

NORTON

 しかし、上のスクリーンショットを撮り、このブログに張り付ける作業に時間がかかったため、エラーが出力された。

(node:24432) UnhandledPromiseRejectionWarning: TimeoutError: Navigation Timeout Exceeded: 30000ms exceeded
(以下略)

たんなるタイムアウトのようなので、もう一度、実行してみる。

npm run main

> puppeteer_sample@1.0.0 main C:\Users\tombi\Documents\projects\puppeteer_sample
> screenshot.js

PS C:\Users\tombi\Documents\projects\puppeteer_sample>

ついにエラーが出ずに終了した。

puppeteer_sample 配下に、example.png が出力された。

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

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

example.png

念のため、このファイルを削除して、もう一回実行してみたが、今度も成功。 

全く問題なし

結局、

Puppeteer入門 スクレイピング+Web操作自動処理プログラミング

Puppeteer入門 スクレイピング+Web操作自動処理プログラミング

 

のとおり、グローバルインストールではうまくいかないので、ローカルインストールするのが正解だったようだ。半日、無駄にしてしまったが、これで puppeteer 開発環境は出来たと思う。

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

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

  • マザー:Gigabyte 890GPA-UD3H (Rev 1.0)
  • CPU:AMD Phenom II X6 1055T (125W)
  • メモリ:CORSAIR xms3 (2GB*4枚)
  • グラボ:RadeonHD 6850
  • SSD: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

のまま、止まっていた。

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

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

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

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

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

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

Lexar JumpDrive TwistTurn USBメモリ 64GB LJDTT64GABJPR

Lexar JumpDrive TwistTurn USBメモリ 64GB LJDTT64GABJPR

 

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

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

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

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

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

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

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

ここで、

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

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

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

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

freesoft.tvbok.com

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

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

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

PCを初期状態に戻す

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

僕も一緒に言う。バルス

このPCを初期状態に戻しています(1%)

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

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

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

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

OS は、Windows 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、

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

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

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

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

    再現手順:

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

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

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

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

      (セッションオープン)

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

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


    該当するサンプル発話:

    6面体のサイコロを3個振って

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

     

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

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

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

該当する発話:

RollDiceIntent  {amount} {diceType} を振って

修正例:

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


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

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

気が変わって Amazon Echo (第二世代)を買う

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

tombi-aburage.hatenablog.jp

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

ローカル開発環境を構築

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

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

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

 

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

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

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

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

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

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

    再現手順:

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

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

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

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

    (セッションオープン)

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

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

    該当箇所: RollDiceIntent

    再現手順:

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

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

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

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

     

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

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

    該当のサンプル発話:

    SayAgainIntent もう一回言って

    SayAgainIntent もう一度言って

     

    補足:

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

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

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

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

と speak した後に、

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

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

修正前

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

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

修正後

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つめは、実装ミスというよりは仕様ミス

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日には公開の通知をもらえた。

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

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

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

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

 

 

 

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ドライブのエラーをチェックしてみたが異状なし。

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

ドライブのエラーをチェック
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ドライブだった。

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

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

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

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

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

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

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

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

プロジェクトごと、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時間とのことなので、夜、寝る前には完了するはずだ。

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

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

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

Western Digital Data Lifeguard Diagnostics - DLGDIAG for Windows
そんな馬鹿な・・・

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

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

chkdsk /R /F

 (ステージ1~4略)

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

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

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

(中略)

0 KB : 不良セクタ

(下略)

修復してないが・・・本当かよ?

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

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

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

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

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

適当なプロジェクトフォルダを、初期化してドライブレター 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ドライブが使えるぞ。

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

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

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