Category: Uncategorized

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内のファイルの動作確認が可能になります。

MacBook Pro 2016モデルの周辺機器問題を解消するためのアダプタを探していたんですが、なかなか「これ！」というものが見つかりませんでしたが、kickstarteで見つけて、即支援しました。

良いところ： 

・thunderbolt3ポートを利用するので、高速
　前のポストでも書いたようなものはほとんどがUSB3.1の接続（たぶん）で、5Gbpsの帯域をハブで分け合っている状態で、パフォーマンスに不安がある。買ったのはMBP2016のファンクションキーモデルでThunderbolt3ポートは2つしかないので、有効に使いたい。
・2つのThunderbolt3ポートを塞ぐが、一つはThunderbolt3がそのまま通っているみたいなので安心。もう一つはUSB-Cの口だけど、USB3.1仕様みたいで、ディスプレイ出力もなし。このへんがUSB-Cのややこしいところ。

 不満なところ： 

・Ethernetアダプタは欲しかった。けど、comment欄でEthernetポートは厚すぎるというのを見てある程度納得して、別途買うことにしました。

アダプタが届くまでの当座のしのぎ兼Ethernetアダプタとして、ANKERの下記の製品を書いました。と、いうか外部ディスプレイ出力がなければ正味これで十分かもしれない。

$ docker exec -i mysqld_container_name mysql -uroot -proot < dump.sql

code-prettifyを利用する方法。
https://github.com/google/code-prettify

（１）ブログ管理画面の”Template”から、テンプレートのHTMLを編集する。
haedタグの中に以下を記述する。

<script src='https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js?skin=sunburst'/>

（２）シンタックスハイライトを利用したい部分を、以下のタグで囲う。

<pre class="prettyprint">
（任意のコード）
</pre>

classに、追加で”lang-*”を指定すると対象言語を明示的に指定できる。lang-*の”*”の部分にはデフォルトで以下が利用できる

    "bsh", "c", "cc", "cpp", "cs", "csh", "cyc", "cv", "htm", "html",
    "java", "js", "m", "mxml", "perl", "pl", "pm", "py", "rb", "sh",
    "xhtml", "xml", "xsl".

ヘッダ行のrun_prettify.jsを呼び出すパラメタにskinを指定すると、シンタックスハイライトのスタイルを切り替えられる。上記の例ではsunburstというスタイルを利用している。
デフォルトで利用可能なスタイルの一覧は以下。
https://rawgit.com/google/code-prettify/master/styles/index.html

その他にも呼び出し時のパラメタで挙動を変更することができ、詳しい設定は以下を参照。
https://github.com/google/code-prettify/blob/master/docs/getting_started.md

Raspbian環境をアップグレードしたついでにpyenv/pyenv-virtualenv環境を構築しようとおもいました。その際、pyenvを使ったpythonバージョンのインストールでエラーが出たので、その構築メモです。

0.環境

記事執筆した時点で、 $ sudo aptitude safe-upgrade した状態です。
日本語環境を入れたりはしてるので、かならずしもデフォではないです。

$ uname -a
Linux raspberrypi 4.4.34+ #930 Wed Nov 23 15:12:30 GMT 2016 armv6l GNU/Linux

１．エラー

以下のようにreadlineとかbzip2とかいかにも必要そうなものがないとか怒られます。

$ pyenv install 2.7.12
Downloading Python-2.7.12.tar.xz...
-> https://www.python.org/ftp/python/2.7.12/Python-2.7.12.tar.xz
Installing Python-2.7.12...

WARNING: The Python readline extension was not compiled. Missing the GNU readline lib?
WARNING: The Python bz2 extension was not compiled. Missing the bzip2 lib?
WARNING: The Python sqlite3 extension was not compiled. Missing the SQLite3 lib?
ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib?

Please consult to the Wiki page to fix the problem.
https://github.com/yyuu/pyenv/wiki/Common-build-problems


BUILD FAILED (Raspbian 8.0 using python-build 1.0.4-13-g1000c2f)

２．必要なパッケージ（インストール済のものを除いた）

下記の参照先のリンクに情報があったので、それを参考にインストール済のものは除きました。
RapPiは非力なので、余計なインストールプロセスは省きたかった。

$ sudo aptitude -y install libssl-dev libbz2-dev libreadline-dev libsqlite3-dev llvm libncurses5-dev libncursesw5-dev

3.参照

https://github.com/yyuu/pyenv/wiki/Common-build-problems

あるていど予想できた結果ですが、pyenv installするとたぶんzipとかがものすごいボトルネックで時間がかかるので、実用に耐えるのかは不明です。

Android ThingsのRaspberry pi用OSイメージで
RasPi3を起動した際、Raspbianのときと同じように、
純正の7inch touchscreenの構成では画面を反転させないとUSBコネクタが
邪魔になってしまうという状況が発生しました。

Raspbianの場合なら、/boot/config.txtの中にlcd_rotate=2という記述を追記して際kどうすれば解消するのですが、それのAndroid Thingsでのやり方。stackoverflowに聞いたらすぐに回答してくれる人が現れました。すごい。ありがとう。

例えば、sdカードのデバイスが/dev/sdbだとした場合、ブートパーティションは/dev/sdb1になるようです。なので、母艦となるpcなりでこのパーティションを
マウントしてあげると、その中にconfig.txtというファイルがあるので、
この中にlcd_rotate=2という設定を追加してあげて再起動すればよろしい。

$ sudo mount /dev/sdb1 /mnt/disk
$ echo ‘lcd_rotate=2’ >> /mnt/disk/config.txt

私はmacを使っていてext4のファイルシステムをマウントするのにFUSE for macなどの
セットアップが必要そうだったんだけど、これが時間かかるのでたまたまvirtualboxに
設定してあったboot2dockerのOSイメージを起動して、これでマウントしてやっつけました。

教えてくれた人によるとこれはhackみたいなもんでオフィシャルな設定とか機能ではないから、アップデートのたびにやらないといけないよ、だから機能リクエストしたほうが良いよ、とのこと。とはいえ、いったんのworkaroundとしては十分です。

http://stackoverflow.com/questions/41165198/android-things-with-rasp3-7-inch-touchscreen/

[12/16追記]
その後

@h_kurosawa ah :/ I thought the boot partition was fat16 and would mount on a mac.

— Johan Euphrosine (@proppy) 2016年12月16日

ということだったので試したら、以下のようにしてmacで直接マウントできました。

$ sudo mount -t msdos /dev/disk1s1 /mnt/sd