Blog

・VSCode 1.29.1
・pipenv 2018.7.1
・opencv-python 3.4.3.18
・pylint 2.1.1

上記の環境でpylintをかけるとcv2のメンバがいないと怒られる。
（実際はVSCode自体は関係ない。pylintコマンド直接でも同様。）

https://stackoverflow.com/questions/50612169/pylint-not-recognizing-cv2-members

上記に従って、pylintに –extension-pkg-whitelist=cv2 というオプションを渡して上げれば良い。VSCode上だとpython.linting.pylintArgsというオプションで渡す。

cv2のメンバはCのモジュールで定義されているから（？）の模様である。

とある事情から、Classic MacOS上で作成したファイルを開く必要があり、フロッピーからバックアップを取っていた.imgファイルからファイルを復旧しました（.imgはディスクユーティリティで.dmg形式に変換する必要もあった）

ところがディスクイメージ形式の変換も終わりいざディスクイメージをマウントしてみると、日本語のファイル名が全て文字化けしている状態でした。
そもそもフロッピーからイメージ化したのもClassic OS上だし仕方ないことなのですが、いかんせんファイル名が見えないことには
何もわからないので、変換する方法を調べてみたところ、Apple自身がファイル名の修正ユーティリティを提供していました。

File Name Encoding Repair Utility v1.0
https://support.apple.com/kb/DL355?locale=ja_JP

使い方は、アプリを起動したあと対象のファイルをドック上のアイコンにドラッグ＆ドロップすればOKで、その後はポップアップされるダイアログにしたがって処理を行えば良いです。

“Correct Text Encoding”は、この記事をみている人であれば”Japanese”にすると良いような気がします。

Raspberry pi 3を7インチ タッチスクリーンディスプレイで利用しているのですが、ちょっとしたキー操作の時にもUSBキーボードを繋がないといけなくて面倒だなと思っていました。本格的にタイプするときにはVNC経由でmacから操作するからいいとして、とりあえずちょっと操作したいときにタッチスクリーンだけで完結したいなと思って調べました。

Raspbirn上で仮想キーボードを表示して、タッチスクリーン上から文字入力を行うには、matchbox-keyboardというパッケージを導入すれば良いようです。

通常どおり

$ sudo aptitude install matchbox-keyboard

としてインストールするだけです。

どうでもいいけどネット上のblogみるとみんなapt-get使ってるけどなんでなんでしょう、aptitudeのほうが使いやすそうなんですが、Debianはあまり詳しくないのでよくわかりません

インストールするとメインメニュー＞アクセサリ＞Keyboardで起動できるはず…なのですが、私の場合はなぜか一度メインメニュー＞設定＞Main Menu Editorを起動して、 アクセサリのメニューからKeyboardの項目のチェックをOff→Onしないと表示されませんでした（キャッシュとかの関係でほっといてもそのうち出てくるのかもしれない）。

ThoughtWorksというところがTechnology Radarというレポートを半年に一回ぐらい発表しているのですが、それの可視化に使われているツールをオープンソースで提供しています。これを使えば私家版のTechnology Radarが作成できる、というわけです。
https://github.com/thoughtworks/build-your-own-radar

面白そうだと思ったのですが、難点があると思っていて、Google Docsにしか対応していないようでした。これが、github上でCSVとかに対応できていれば、みんなでcommitしたりして使えるので良いのではないかな、と思いました。
で、作ってみた。
https://github.com/hkurosawa/build-your-own-radar/tree/csvsupport

本家にpull requestも投げてみているけど、どうでしょうか。

2018/9/21追記： 取り込んでもらえました。

Raspberry pi 3でサーボの制御をやってみようと思ってSG90というサーボモーターを購入しました。電子工作の分野では最も手軽なモーターでネットで調べても情報が多そうだったので。これをうまく動作させるために少しハマったので、その記録です。結論としてはwiringPiは使わず、pigpioというライブラリを使うことにしました。

環境は以下。

pi@raspberrypi ~/src/wiringpi % cat /etc/issue
Raspbian GNU/Linux 8 n l

pi@raspberrypi ~/src/wiringpi % uname -a
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

RPi.GPIOでのPWM出力サンプルを試すとサーボは動作するのですが「ブルブル」と振動してしまってうまく静止してくれません。動作のチェックには十分ですが、なにか意味のあるものが作れる品質ではなさそう。

調べるとサーボモーターの制御にはPWM出力を使うのですが、精度の良い出力を得るためにはwiringPiというライブラリを使うのが定番のようでした。

ですが、サンプルプログラムの

import wiringpi
PIN = 18 pi.wiringPiSetupGpio()
pi.pinMode(PIN, pi.OUTPUT)

これのpinModeをコールした時点で、なぜかSDカードがイジェクトされたというメッセージがデスクトップに現れ、OSも事実上フリーズ（？）電源のOFF/ONを強いられるというよくわからない挙動に遭遇しました（実際にはインタラクティブシェル上）

wiringPiをpipからでなくソースからビルドしたりしても挙動は変わらず、ネットを検索してみてもそれらしい情報がなかなか見つからなかったのですが、カーネルのバージョンが新しすぎてwiringPiが対応してないっぽいという記事を見つけました。

WiringPiで「Unable to determine hardware version. I see: Hardware : BCM2835」エラー
http://qiita.com/jollyjoester/items/ba59e5d43e28b701f120

カーネルをダウングレードするのも嫌なので代替のものがないのか調べてみたところ、

pigpioというライブラリがもともとRaspbianには設定されているようで、以下の記事のとおりにやったら動作し、RPi.GPIOを利用したときの「ブルブル」という振動も発生しないようでした。

pigpioでサーボモーターを動かす。
http://blue-black.ink/?p=294

Visual Studio Codeで、Three.jsの開発環境を構築しています。このポストでは、VSCodeのデバッガ機能を利用してブレークポイントを打ったりすることができることまでが目標です。ブラウザ環境としてはChromeかFirefoxが現実的な選択肢だと思うけど、今回はまずFirefoxでデバッグすることを考えます。

Debugger for Firefox をVSCodeにインストールする

まずはVSCodeにFirefoxのデバッガ拡張をインストールします。これは単純に以下のプラグインをインストールすればOK。
https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-firefox-debug
この拡張をインストールすると、デバッガのlaunch.jsonファイルの編集時、Add Configuration…した場合にFirefox:*系の設定項目が選べるようになります。

Webpackがビルド時にSourceMapを出力するように設定する

前回のポストで設定したwebpack.config.jsに設定を追加して、SourceMapというデバッグ用のファイルをビルド時に出力するようにします。SourceMapというには簡単に言えば、webpackなどのビルドツールでバンドルされたJavaScriptファイルと、バンドル前のソースコードの対応付けを記述したファイルで、これが存在することによってバンドル前のソースコード上でブレークポイントを指定したりすることが可能になるもののようです。

具体的には、module.exportsの辞書配列の中に以下の項目を追加するだけです。

devtool: "source-map"

source-map以外にも選択肢がいくつかあるようですが、今回はsource-mapを指定しました。ビルド時の処理時間と、取得できるデバッグ情報の精度とのトレードオフのようなので、必要に応じて調べれば良いと思います。
上記の設定で再度ビルドをし直すと、outputでの出力JavaScript名がbundle.jsだった場合にbundle.js.mapというSourceMapファイルが出力されます（設定によって、出力されるものの内容も変わるようです）。

launch.jsonにFirefox用の設定を追加する

デバッグメニューからAdd Configuration…を選択し、Firefox: Launch (Server) およびFirefox: Attachの2つを追加します。SourceMapに関わる部分はpathMappingsというキー項目だけなので、これをそれぞれに追加します。私の環境で動作した設定は下記のもので、Extensionのサイトのドキュメントに書いてあるものとは違いましたが、要するにurlという項目がブラウザがアクセスしている先、pathというのが対応するソースのローカルでのファイルパスを指せば良いようです。デバッグする対応のページで対象のurlがどこを指しているかは、ツール＞ウェブ開発＞デバッガーを開き、「ソース」というリストの中にwebpack://というスキームのURLが見つかると思うので、それがどこを指しているのかを確認し、プロジェクト内のバンドル前のソースファイルと対応するように適宜変更すれば良いと思います。

{
    "version": "0.2.0",
    "configurations": [
        
        {
            "type": "firefox",
            "request": "attach",
            "name": "Attach",
            "pathMappings": [
                {
                    "url": "webpack://",
                    "path": "${workspaceRoot}"
                }
            ]
        },
        {
            "type": "firefox",
            "request": "launch",
            "reAttach": true,
            "name": "Launch localhost",
            "url": "http://localhost:8080/index.html",
            "webRoot": "${workspaceRoot}/htdocs/",
            "pathMappings": [
                {
                    "url": "webpack://",
                    "path": "${workspaceRoot}"
                }
            ]
        }
    ]
}

Firefoxを使ってデバッグする（Launch）

上記例では、Launch localhostという項目を選んでデバッグを実行（F5）すると、Firefoxが起動してurl項目に設定したサイトにアクセスするようになります。このとき、ソースファイル側（webpackでバンドルされる前のファイル）にブレークポイントを打っていると、そこで処理が停止するようになります。詳しく調べていないけど、起動した後にFirefox側でページをリロードしないといけないケースがあったのは、多分イベントの発火のタイミングのような気がします。

ちなみにreAttachという項目をtrueにすると当該デバッグ終了時にFirefoxは合わせて終了し、デバッグのRestart時にはFirefoxごと再起動します。これでもいいんだけどデバッグ時には通常なんども繰り返すことになると思うので、通常はAttachモードを選んだ方がよさそうです。

Firefoxを使ってデバッグする（Attach） 

Attachモードは、すでに実行中のFirefoxにVSCodeから接続するので、Firefox自体の起動終了を伴わず、効率的です。ただし、デバッグを外部ツールから利用可能にするために最初にFirefox自体の設定を変更する必要があります。

設定の詳細についてはExtensionのドキュメントのAttachという項目を見てその通りに設定すれば良いです。設定画面へは、about:configというアドレスをアドレスバーに入力します。

https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-firefox-debug

$ /Applications/Firefox.app/Contents/MacOS/firefox -start-debugger-server -no-remote

前のポストでVisual Studio Code上でコード補完付きでコーディングが可能な状態になったので、これをブラウザ上で実行可能な状態にコンパイルすることを考えます。

VSCodeでのコード補完を利用するためにthree.jsをnpmからインストールしたのでそのままでは実行できず、同じくnpmで提供されているツールであるwebpackというコマンドを利用します。

webpackコマンドをインストールする

プロジェクトのルートディレクトリから、webpackをnpmコマンドでインストールします。ブログとかには-gオプションをつけてグローバルにインストールする記述が多いが、グローバル空間はあまり汚したくないのでプロジェクト内に閉じることにします。

$ npm install webpack --save-dev

–save-devオプションをつけることで、webpackモジュールがインストールされると同時に、プロジェクトのpackage.jsonにあるdevDependenciesに記録されます。

これで、${PRJ_ROOT}/node_modules/.bin/webpackにコマンドがインストールされます。

$ node node_modules/.bin/webpack -v
2.5.0

みたいな感じになります。

webpack.config.jsを作成する

コマンドを直接

$ node node_modules/.bin/webpack  

のように使っても機能しますが、より簡単のために、webpack.config.jsという名前の設定ファイルを作成します。これがコマンドを実行するカレントディレクトリに存在することで、引数なしでwebpackコマンドを実行できるようになります。ここで、<entry>というのはブラウザでページを読み込んだときに最初に呼ばれるべきスクリプト（今回の場合はthree.jsをrequireしているほうのスクリプト）を指します。

以下に最低限と思われるentryとoutputだけ設定したwebpack.config.jsの例を記します。コンパイル元のJavaScriptファイルはsrcディレクトリ配下のindex.js、出力先はhtdocsのbundle.jsファイルとします。index.jsではthree.jsをrequireしているので、webpackを通してbundle.jsというファイルに統合されて出力してね、という設定です。 pathは出力先のoutput設定で絶対パスを要求されたので、それを解決するためのモジュールです。

const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        path: path.resolve(__dirname, 'htdocs'),
        filename: 'bundle.js'
    }
};

上記がプロジェクトのディレクトリに存在すれば、webpackコマンドを実行するだけで、この設定に沿ったコンパイル処理が実行されます。これをindex.htmlから<script src=”bundle.js”> のように呼び出せば、ブラウザからJavaScriptコードが実行される状態になります。

なお、上記の例では最終的にbundle.jsを呼び出すことになるHTMLファイルはあらかじめhtdocsファイルに静的なファイルとして存在していることとしています。調べてたところhtml-webpack-pluginというものが存在しているようですが、今回の例ではこれで十分とします。webpackはCSSファイルや各種リソースをまとめるものなので、必要に応じてこの設定ファイルは設定を追加していくことになるはずです。

package.jsonにコマンド（scripts）を追加する

ここまでの設定だと

$ node node_modules/.bin/webpack

のようにコマンドを実行する必要があり、あまりスマートではありません。これを回避するのに${PRJ_ROOT}/node_modules/.bin/ディレクトリにパスを通すのも、そもそもグローバル環境を汚したくなかったのに本末転倒であって、これをnpm環境で統一することにして、package.jsonのscriptsという項目を使ってnpmコマンドを追加します。該当部分のみ転載します。

  "scripts": {
    "test": "echo "Error: no test specified" && exit 1",
    "build": "webpack"
  },

一つ目の”test”というのはデフォルトで入っていたものなので気にしないことにします。あとここのscriptsに書く際はすでにnode_modules/.bin/にパスが通っている状態だそうなので、webpackというコマンド名だけ書けば良いことになります。

package.jsonに上記の設定があれば、以下のようにして単純に、webpackによるJavaScriptのビルドを実行することが可能です。

$ npm run build

機能拡張にはnpmのものもあるようなので、必要であれば任意のショートカットを割り当ててさらに手軽に実行することが可能になると思います。
https://marketplace.visualstudio.com/items?itemName=fknop.vscode-npm

docker上でWebサーバをホストする

htdocsに出力されたJavaScriptファイルをテストするのに、HTMLファイルをローカルファイルとして開くとセキュリティ上の制限が出てきたり、うまく動作しないことがあります。ブラウザ上の設定でこの制限を解除することは可能ですが、より実際の想定に近い環境としてlocalhost上にWebサーバとしてnginxを動作させ、これに静的なファイル群をホストさせて動作確認することにします。これはdockerがすでにインストールされている前提で、以下のようにして実行可能です。

$ docker run -v `pwd`/htdocs:/usr/share/nginx/html:ro --rm -d -p 8080:80 nginx

これで、http://localhost:8080でhtdocs内のファイルの動作確認が可能になります。