過去に、2019年のアドベントカレンダーで以下の記事を書いた際に使った「@abandonware/noble」、当時はサンプルで作った BLEスキャンのプログラムを実行できたものの、スキャン対象にしたデバイスが Node.js のプログラムの出力に出てきませんでした。 （そして、obniz-noble を使って、デバイスと obniz の間で BLE通信をさせた場合は、スキャンされたデバイスに表示されていたという状況でした） ●【IoTLT 2019】新しい obniz で obniz-noble を試す（2019/12/22） - Qiita 　https://qiita.com/youtoy/items/1a2e92ae7a83df7e9a82 そして1年以上が経過した 2021/4/15、この日に開催された IoTLT vol.74 で @n0bisuke さんが「@abandonware/noble」の話をされていて、久しぶりに公式ページを見てみたら手順の記載が少しだけ増えていて、「これは、上記の記事を書いた際にうまくいかなかった原因が分かったかも！？」というのがあって今回の記事を書きました。 ちなみに以下の内容が、上に書いている「@abandonware/noble」の話が登場していた LT です。 最後は @n0bisuke さんが、Node.js＋Bluetoothの話の最新事情。 #IoTLT pic.twitter.com/mLI7M2FYbW— you (@youtoy) April 15, 2021 2019年にやろうとしていたこと 当時、やろうとしていたことは「toio というデバイスと Mac の間で、noble を使った Node.js のプログラムで通信をさせる」という内容でした。 当時の記事の内容の一部抜粋ですが、こんな感じでセットアップをして使う流れでした。 そして、BLEスキャンを行うプログラムは実行できたものの、スキャン対象にしたデバイスが出力結果の中に出てきませんでした。 Node.js のプログラム以外での動作確認として、Apple が提供している「Bluetooth Explorer」で BLEデバイスのスキャンを試したところ、そちらではスキャン結果に toio が出てきていました。 その後、Google Chrome上で Web Bluetooth API を使った JavaScript のプログラムを動かしたりした際も、BLEデバイスをスキャンできて接続から制御まで行うことができていました（例えば以下の内容など）。 ●toio を音で制御してみた（Audio用の Teachable Machine でベルやタンバリンの音を機械学習） - Qiita 　https://qiita.com/youtoy/items/37f70bb4ce630e6cbd92 ●Web Bluetooth API で BLE（Chrome と micro:bit をつなぐ） - Qiita 　https://qiita.com/youtoy/items/cd2c3d4770d4ad75a321 そして、これ以降は noble を使った BLE通信は使わない状態が長らく続きました。 2021年4月に公式ページで見た内容 そして、冒頭に書いたイベントで取り上げられたのを聞いて、久しぶりに 「@abandonware/noble」のページを見てみたところ、Mac で使う手順で以下の記載が増えていました。 ターミナルアプリや iTerm2 といったアプリで、上記の設定はした覚えがなく、「この設定を追加すれば動いたりするのでは？」と思い試してみました。 試した内容 とりあえず、Mac の設定でターミナルアプリと iTerm2 の 2つに Bluetooth の利用を許可する設定をしました。 そして、適当に作ったフォルダで 2019年当時も行った手順と同様に npm install @abandonware/noble を実行します。 あとは、toio の電源をいれて、その後に以下のプログラムを実行してみました。 2019年当時に動かしたプログラムの一部を、現在の @abandonware/noble のページのサンプルを見て、少しだけ書きかえました。プログラム内で行う基本的な処理は、2019年当時のものと同じです。 var noble = require('@abandonware/noble'); noble.on('stateChange', function(state) { if (state === 'poweredOn') { noble.startScanningAsync(); } else { noble.stopScanningAsync(); } }); noble.on('discover', async (peripheral) => { console.log(`${peripheral.address} (${peripheral.advertisement.localName})`); }); toio は 2台動かしていて、上記を実行した結果、以下がの出力が得られて無事に toio をスキャン結果に表示させることができました。 おわりに 今回、細かな検証をしていないので「Node.js のバージョンが当時より上がっている中で、当時と違いが何か出ていることが影響した可能性」や「@abandonware/noble のソースコードに何か手を加えられたことが影響した可能性」は残ります。 個人的には、とりあえず「2019年当時にできなかったことが、現在できる状況になった」というだけで大満足です！ そして、今回は toio で試しましたが、あれこれ試してみたいと思うデバイスは micro:bit だったりするので、こちらも試してみられればと思います。 余談 今回の記事を書くきっかけとなったイベントにて、以下のツイートがされていて、とても気になりました。 これは試してみなければ！ よもやと思ったらやっぱりNode-REDでもBLE関連復活してた。abandonwareさんのnoble使ってるみたい #iotlthttps://t.co/IB0AbUqP8L とか— よしの (@yoshinosandesu) April 15, 2021 ●node-red-contrib-generic-ble (node) - Node-RED 　https://flows.nodered.org/node/node-red-contrib-generic-ble

やりたいこと Node.js のバージョン管理が可能になる npm パッケージ n を利用して Node.js のバージョンをダウンロードグレードします。 環境 OS：Ubuntu 16.04.7 LTS x86/64bit Node.js：v10.24.1 手順 Node.js のバージョンを v10.24.1 から v8.17.0 へダウングレードする手順になります。 n のインストール ~$ sudo npm install -g n /usr/bin/n -> /usr/lib/node_modules/n/bin/n + n@7.1.0 added 1 package from 2 contributors in 10.515s ダウングレード可能なバージョン情報の確認 ~$ n ls-remote --all 15.14.0 15.13.0 （中略） 8.17.0 8.16.2 （中略） 0.8.7 0.8.6 v8.17.0 へダウングレード ~$ n 8.17.0 installing : node-v8.17.0 mkdir : /usr/local/n/versions/node/8.17.0 mkdir: cannot create directory ‘/usr/local/n’: Permission denied Error: sudo required (or change ownership, or define N_PREFIX) ~$ sudo n 8.17.0 installing : node-v8.17.0 mkdir : /usr/local/n/versions/node/8.17.0 fetch : https://nodejs.org/dist/v8.17.0/node-v8.17.0-linux-x64.tar.xz installed : v8.17.0 (with npm 6.13.4) Note: the node command changed location and the old location may be remembered in your current shell. old : /usr/bin/node new : /usr/local/bin/node To reset the command location hash either start a new shell, or execute PATH="$PATH" ~$ node -v v10.24.1 ~$ PATH="$PATH" ~$ node -v v8.17.0 参考文献

Windows10環境でaglioを使ってAPI BlueprintをHTMLにしたかったけれど、エラーが出てだいぶハマった結果なんとか使えるようになったので共有。 ハマったパターン Node.js(v14.16.1)をインストーラーでインストール おもむろにaglioをグローバルインストール npm install -g aglio 結果 悲しみのException gyp ERR! UNCAUGHT EXCEPTION やったこと Node.jsのアンインストール スタートメニューからアンインストーラーを実行 nodistのインストール https://github.com/nullivex/nodist/releases バージョンを指定してインストール ※ 8以降でもいけるかも。最新だとエラーが発生した。 nodist + 8.17.0 nodist npm 6.13.4 Visual Studio Build Tools 2019 のインストール https://visualstudio.microsoft.com/ja/thank-you-downloading-visual-studio/?sku=BuildTools おもむろに npm install -g aglio 成功 結局？？ Node.jsのバージョンが新しすぎた Visual Studio Build Tools が古すぎた ということっぽい (追記) PowerShellでnodistを動かす時に「このシステムではスクリプトの実行が無効になっているため、～」というメッセージが出て動かなかったことがありました。 下記の記事が参考になりました。 ありがとうございます。

API Gateway + Lambda を使ってS3上のPDFをマージする処理を実装した際に、 PDFTK を Lambda Layer に組み込んだ時のメモ。 PDFTK を動かす Lambda Layer の作成方法 Dockerなどで Amazon Linux 2の環境を用意(もしかしたらcentosだったかも・・・) Amazon Linux 2 上で PDFTK をビルド(もしかしたらcentosだったかも・・・) ビルドした PDFTK のファイルを Lambda Layer の構成に組み込む 1. Dockerなどで Amazon Linux 2の環境を用意 ここは省略 2. Amazon Linux 2 上で PDFTK をビルド PDFTKのサイトの「 Build from Source Code 」の手順でビルドする。 https://www.pdflabs.com/docs/install-pdftk-on-redhat-or-centos/ 3. ビルドした PDFTK のファイルを Lambda Layer の構成に組み込む この2ファイルを下記Lambda Layer の構成に組み込み、nodejsフォルダを圧縮して Lambda Layer にアップロードするだけ。 ・/usr/local/bin/pdftk ・pdftk-2.02-dist/lib64/libgcj.so.10 次の index.js では、pdftk の cat (結合) と version （バージョン表示）のみ実装している。 index.js const { PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH } = process.env const BIN = '/opt/nodejs/node_modules/pdftk-lambda/bin' process.env.PATH = `${PATH}:${BIN}` process.env.LD_LIBRARY_PATH = `${LD_LIBRARY_PATH}:${BIN}` process.env.PKG_CONFIG_PATH = `${PKG_CONFIG_PATH}:${BIN}` /** * バージョン */ module.exports.version = () => { return new Promise((resolve, reject) => { require('child_process').exec( 'pdftk --version', (error, stdout, stderr) => { if (error) reject(error) else resolve(stdout) } ) }) } /** * 結合 * Example:pdftk pdf1.pdf pdf2.pdf cat output combined.pdf */ module.exports.cat = ( inputFiles, outputFile ) => { console.log('pdftk ' + inputFiles.join(' ') + ' cat output ' + outputFile); return new Promise((resolve, reject) => { require('child_process').exec( 'pdftk ' + inputFiles.join(' ') + ' cat output ' + outputFile, (error, stdout, stderr) => { if (error) reject(error) else resolve(stdout) } ) }) } Lambda Layer を使う場合はこんな感じ。 var pdftk = require('pdftk-lambda'); /** * PDF結合 */ async function pdfMerge( inPutFiles, outPutFile ){ let ret = true; try{ await pdftk.cat( inPutFiles, '"' + outPutFile + '"' ); }catch(e){ ret = !ret; console.log('-(pdtfk cat error log start )-'); console.log(e); console.log('-(pdtfk cat error log end )-'); } return ret; }

現象 コミット時に lint を走らせるために husky を設定しているプロジェクトも多いと思います。 huskyを設定すると npm scripts に"prepare": "husky install"が設定されます。 これにより、npm installなどが走ったあとにhusky installが実行されるため、 全開発メンバーが git-hooks を割と確実に設定することができるようになります。 しかし、この npm scripts のせいで、App Engineへのデプロイ中に以下のエラーがでるようになってしまいました。 husky: not found この対処法を思いついたので、備忘録として記事に残します。 環境 Mac Node 14 husky 6.0.0 解決方法 package.json "prepare": "node --eval 'process.exit(process.env.NODE_ENV === `production` ? 0 : 1)' || husky install", 日本語にすると「NODE_ENV環境変数がproductionではないときだけhusky installを実行する」となります。APP EngineではNODE_ENV=productionが設定されているため、husky installがスキップされます。 解説 node --eval JavaScriptのコードをインラインで実行することができます。 例 node --eval 'console.log("foo")' # -> foo process.exit(process.env.NODE_ENV === production ? 0 : 1) NODE_ENV 環境変数が production のとき、正常終了し、そうでない場合は、終了コード1を出して失敗します。 || 前のコマンドが失敗したときに、後ろのコマンドを実行します。 まとめ App Engineは強い。