サイトを引っ越します

ドメインを変更してコンテンツも移設します 
移設先：https://rawbytes.org/

macの環境構築を初めからやってみるよ：anyenvとphpenv

 Macbook Airを買った。13インチのm4モデルだ。

これまでは2016年のintel Macbook Proだったので 実に約9年ぶりである。さらにその前はたしかPowerBook G4、もっと前はPower Macだった気がするので毎回プロセッサが変わってるということになる（Power Macはさすがに処分した）。

それはそうと、これまでは基本的に旧環境を引き継いでいたんだけどさすがにごちゃごちゃしてきたし、いまやほとんどのデータはクラウドに保存されているので、環境はイチから構築してみることにした。

網羅的ではないが、いくつか環境構築メモを残していこうと思う。

PHPが入ってなかった 

そもそもとしてこのbloggerを自前のWordPressに移行しようと思っているのだけれど、どうやらbloggerのエクスポート形式が最近？RSS XMLからatomに変更されてしまって、インポートができないっぽい。インポートするにはatomからrssへの変換が必要そう。

調べるとここに情報があった：https://atom.geekhood.net/

 

WordPressのdockerイメージと合わせてPHPは8.2.29を入れようと思った

＃振り返るとどうやら8.2系以降を入れようとしたことによるエラーも多そうだった 

 

 （続く）

入れたいもの：$ phpenv install 8.2.29 

エラーを一つずつ潰す... 

$ brew install pkgconf

$ brew install openssl

ここでエラー

configure: error: Please reinstall the BZip2 distribution
を解消しようとして、homebrewでbzip2を入れた 

$ brew install bzip2 

が、解消しない 

    export LDFLAGS="-L/opt/homebrew/opt/bzip2/lib"

    export CPPFLAGS="-I/opt/homebrew/opt/bzip2/include" 

を設定したのだが状況が変わらずなので、別の方法

    export PHP_BUILD_CONFIGURE_OPTS="--with-bz2=$(brew --prefix bzip2)" 

を.zshrcに設定して $ source ~/.zshrc で次に進むことができた

 

$ brew install libpng

$ brew install libjpeg-turbo
$ brew install libiconv 

    export PHP_BUILD_CONFIGURE_OPTS="--with-bz2=$(brew --prefix bzip2) --with-iconv=$(brew --prefix libiconv)" 

 

$ brew install icu4c

 

さらにエラー 

-----------------------------------------
configure: error: *** A compiler with support for C++17 language features is required.
-----------------------------------------

こんなものを見つけた 

https://zenn.dev/shogogg/articles/b358c1dec37426785a12 

https://github.com/php-build/php-build/issues/783

...正直詳細はあんまりわからんが

$ export CXXFLAGS="-std=c++17"

を.zshrc に書いて

$ source ~/.zshrc で進んだ

 

$ brew search oniguruma
↑よく知らなかったが正規表現のライブラリらしい

 

次のエラー 

-----------------------------------------
configure: error: Cannot find libtidy
----------------------------------------- 

 $ brew install tidy-html5

こういうパッケージ名を探すのは正解はどうなんだろう 

 

解消しないなーと思ったら先人のブログ 

https://qiita.com/kmuro/items/5eb1b09f333a4a07dfbe 

> 環境変数PHP_BUILD_CONFIGURE_OPTSに--with-tidyオプションを指定 

そうだろうと思った。パターンは見えてきた

.zshrc の該当記述はこんな状態に 

export PHP_BUILD_CONFIGURE_OPTS="--with-bz2=$(brew --prefix bzip2) --with-iconv=$(brew --prefix libiconv) --with-tidy=$(brew --prefix tidy-html5)" 

 

$ brew install libzip

 

こんどは以下のようなエラーになった（たしかにjpeg-turboパッケージを入れた）

ld: warning: search path '/opt/homebrew/opt/jpeg/lib' not found
 

phpenv installはエラー終了しているが、インストール自体はできているようだ...どういう状態？

$ phpenv global 8.2.29
$ php -v
PHP 8.2.29 (cli) (built: Aug 11 2025 08:33:04) (NTS)

 

warningは一回無視するとしてこのへんかなあと検討をつける 

PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled. 

ググるとブログを見つけた。autoconfとな 

https://zenn.dev/massat/articles/install-php8-with-phpenv 

 

$ brew install autoconf

$ phpenv install 8.2.29

（略） 

[Success]: Built 8.2.29 successfully.

（略）

 

ようやく成功したようだ
 

nvidiaのドライバーを更新したのでdocker環境も再インストールしたよ

 一つまえの記事でUbuntu(20.04）のnvidia関連パッケージを一度すべて削除してしまったので、docker関係の環境も再インストールしなければいけなかった。

 下記に従って実行してみた。自分の記載はあやしいのと、当然下記のnvidiaのリンク先のほうが記載が新しくなってる可能性があるので、なにか変だと思ったらnvidia.comにあたったほうが良い。
https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html

１．パッケージのインストール

$ sudo apt install nvidia-container-toolkit

２．設定の変更

$ sudo nvidia-ctk runtime configure --runtime=crio

３．dockerデーモンの再起動

 $ sudo systemctl restart docker

４．確認する

下記でGPUの情報が ホストでnvidia-smiを実行したときと同じように表示されればOKのはず

$ sudo docker run --rm --runtime=nvidia --gpus all nvidia/cuda:11.6.2-base-ubuntu20.04 nvidia-smi
Sat Apr  6 16:34:33 2024       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15              Driver Version: 550.54.15      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 3060        Off |   00000000:04:00.0  On |                  N/A |
|  0%   49C    P8             11W /  170W |     539MiB /  12288MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

ホストOS上でnvidia-smiを実行したときが下記。大丈夫そう。

$ nvidia-smi
Sun Apr  7 01:40:48 2024       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15              Driver Version: 550.54.15      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 3060        Off |   00000000:04:00.0  On |                  N/A |
|  0%   50C    P5             18W /  170W |     560MiB /  12288MiB |      2%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

 

Ubuntuをアップデートしたら起動しなくなったけど色々やったら起動するようになった（nvidiaドライバー）

 久しぶりにUbuntu（20.04）を起動したのでパッケージのアップデートをしようとおもった。

 「ソフトウェアの更新」を実行すると、「部分的にしかアップデートできない」旨の表示が出た。が、特に気にせず、依存関係か何かで何回かに分けてアップデートしないといけないのかなとおもいってそのまま実行、再起動を行った。

起動メニュでUbuntuを実行すると、黒いコンソールの 画面までは進むが、たぶんデスクトップに切り替わるタイミングで画面がフリーズして起動しないという現象に遭遇した。

理由はわからないが、はじめにUbuntu環境をインストールしたときのGPUがGTX1070で、そのままRTX3060に換装して使い続けていたので、なにか不整合が起きてしまっていたのかもしれない（表面上は動いていた、と思う）。

困った。ということでいろいろ調べながらやって復旧した（たぶん）なのでやったことメモ。LinuxおよびUbuntuに詳しい訳ではないので、余計なことをやったりしているかもしれません。実際にはもっといろいろ試行錯誤しているが、結果的に整理すると意味あったのは以下だけだと思う。

１．Ubuntuをリカバリーモードで起動

　これは環境によってやり方がまちまちかもしれない。私の場合はGRUBのメニューの"Advanced options for Ubuntu"みたいなやつを選んで、とにかくRecoveryモードでUbuntuを起動する。まずNetworkを選択するとネットワークが使えるようになるらしいので、それを選んだあとにRootを選んでプロンプトを表示。

 ※このとき苦し紛れにメニューにあるdpkg項目を選んで、gcc関係のパッケージの修復？が行われたようなのだが、これが関係あったかどうかはわからない（たぶんない）

２．起動ログを確認

# journalctl -p err -b

で、起動時のエラーログを見ることができるらしい。気になったのは、

Failed to start nvidia-powered service
とかいうあたりで、ググったりした結果Nvidiaのドライバが壊れてるんだろうとあたりをつけた

３．nvidiaのドライバ類をすべて削除

# sudo apt-get remove --purge '^nvidia-.*'
# sudo apt autoremove

で、いちどnvidia関連のパッケージをすべて削除した。
ついでにdockerのnvidia関連パッケージも消えてしまったがこの際作り直すことにしていったん忘れる。

（※こうするとnouveauドライバが有効になるはずだぜという記事もみつけたのだが、少なくとも自分の環境では起動しなかった（soundがどうとかいうエラーが残っていた。これも調べるとnvidia関連が原因に見えた）。 miniPC+eGPUという環境なのも影響しているのかもしれないし、それでなにか設定が残ってしまっていたのかもしれない）

４．nvidiaのドライバを再インストール

仕方ないのでリカバリーモードのままnvidiaのドライバの再インストールをした。
Nvidiaのサイトのままに、

# sudo ubuntu-drivers install

を実行して、自動的に最適なドライバを検出してもらった。ここは問題なくインストールが完了した。よく考えたらリカバリーモードでrootに入っているのでsudoいらんことに気づいた（今）。

 ５．再起動

# sudo  reboot

 で再起動をかけると、無事に起動してデスクトップが表示された。

 

TODO：docker関係の構築をやりなおさなければいけない。

NVidia Container Toolkitでgpu-enabledなdocker imageで作業したときの作業メモ

GPUを利用する機械学習系の環境を構築する際に 、CUDAとフレームワーク等のバージョンの整合性で困ることがある。必ずしも最新版にしておけばいいというわけではないことが結構ある（気がする）

dockerコンテナ内でgpuが利用できるようになるNvidia Container TookitをNvidiaが提供してくれているので、これを利用すると任意のCUDAバージョンの環境が構築できるようになりますという作業メモ。

１．Nvidia Container Toolkitをインストール

ホストOS側に、Nvidia Linux DriverとNvidia Container Toolkitをインストールして、docker runtimeにnvidiaランタイムを認識してもらうまで下記のマニュアルに沿って設定。

ホスト側にはNvidia Linux DriverおよびNVidia Container Toolkit だけで良いので、CUDAで気を病む必要がない（たぶん）

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

 

２．gpuが認識されているかの確認方法

これも書いてある通りだが、

$ sudo docker run --rm --runtime=nvidia --gpus all nvidia/cuda:11.6.2-base-ubuntu20.04 nvidia-smi

のようにして、ホストOSと同様にgpuの情報が表示されればOK。

 

３．dockerイメージはどこにあるの

 https://hub.docker.com/r/nvidia/cuda

ここに任意のベースOSとCUDAのバージョンの組み合わせのtagがあるので、必要なものを使えば良い。

 

４．必要なコマンドとかが見当たらないんだけど...？

上記のDocker Imageは、NVidia関係のツールが準備されている一方、curl gitなどもインストールされてないし、python もインストールされていないっぽい。なので実際には、上記イメージをベースにして下記みたいに共通で使うパッケージをインストールしたイメージを作っておくのが良いと思う。

---------------------------------

 $ cat Dockerfile
FROM nvidia/cuda:11.6.2-base-ubuntu20.04

# Install needed packages
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl git python3 python3-pip && \
    rm -rf /var/lib/apt/lists/*

# Make python3 default
RUN update-alternatives --install /usr/bin/python python /usr/bin/python3 1

---------------------------------

上記のうち最後の行は、Ubuntuの標準パッケージではpythonコマンドではpython2系が起動してしまうっぽいので、それを切り替える方法（詳しくはupdate-alternativesで検索せよ）。本当はpyenvとかでcuda同様に必要なpythonランタイムを選択したほうが良さそうな気もするが、とりあえずこのようにする

 

５．作業はどんなふうにすれば？

docker image内に入って作業するには以下のようにすれば良い。 (image名)のところは作成した任意のimage名にする。あとの注意点は--gpus allとかのオプションをつけないとだめなのと、一時的に作業とか確認したいだけのときには--rmオプションもつけないとゴミのコンテナがたくさんであとで困る（rmオプションは実行終了後に当該コンテナが自動で削除される）。

$ docker run --rm -it --gpus all (image名)

Stable Diffusion WebUIをubuntu, pyenv virtualenvの環境でインストールした

 Stable Diffusion WebUIをUbuntuとpyenv-virtualenvの環境でインストールした。
公式のマニュアルどおりではうまく行かなかったので、正しいのかはわかってないけどとりあえず動いたので差分のメモをしておきます。試したのは2023/3/25。

Ubuntuの環境は以下の通り
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"

1. まずpyenv virutualenvで専用の環境を作る。現時点で要求のpythonのバージョンが3.10.6とのことだったので従う

$ pyenv virtualenv 3.10.6 stable-diffusion-webui
みたいにして、3.10.6をベースにしたvirtualenv環境を作っておく。

 

2. "Automatic Installation on Linux"のコマンドでは起動時にstable diffusionが見つからないと出て起動できなかった。仕方がないのでここのドキュメンﾄにあるManual Installの方を試した。

3.これは単純に私が理解してないだけだと思うけど、Manual Installの最後の意味がわからなかった（何をどこに配置すればいいのかがわからなかった）

 # (outside of command line) put stable diffusion model into web ui directory

# the command below must output something like: 1 File(s) 4,265,380,512 bytes
dir model.ckpt

結論としては、 ダウンロードするモデル（checkpointファイルと呼び、.ckptファイルというらしい）は
このあたりからダウンロードして、配置先は

$(stable-diffusion-webui-base)/models/stable-diffusion/ の配下に置いた。

4.最後に
$ python webui.py
を実行すれば起動するとあるのだが、
AssertionError: Couldn't find Stable Diffusion in any of: ['/home/xxx/src/stable-diffusion-webui/repositories/stable-diffusion-stability-ai', '.', '/home/xxx/src']
みたいなエラーが出て起動できなかった。ぐぐってみるとなんかのバグか環境依存な気もしたんだけどよくわからなかった

5.困ったので、
$ python launch.py
を実行してみた（launchと書いてあるんだからとにかく何かが起動するんだろうと思っただけ）
そうすると
$ python launch.py
Python 3.10.6 (main, Mar 25 2023, 07:43:47) [GCC 9.4.0]
Commit hash: a9fed7c364061ae6efb37f797b6b522cb3cf7aa2
Installing open_clip
Cloning Stable Diffusion into ...（略）
みたいに出て、何やら追加でモジュールがダウンロードされているように見えた。

最終的に
Running on local URL:  http://127.0.0.1:7860
と表示されて、ここのURLにアクセスするとStable Diffusion WebUIがブラウザ上で表示できた

さらに、以降は

$ python webui.py

でも起動できたので、インストールの最後の段階でpython launch.pyを実行することが必要だったのだろう（きっと）。

Windowsでvim環境を構築するための道のり：終章

昨日Windowsでhowmをもう一回使いたくてvimでやってみるかと思ったんだけど、今日調べていたらVSCodeで類似の拡張があることがわかった。もともとhowmはちょっと機能多すぎてメモとTODOぐらいできればいいんだけどな、、という感じだったのでむしろちょうど良いぐらいかもしれない。

vscode-memo-life-for-you

https://qiita.com/satokaz/items/33b5c5ae4f19a87c5187

Windowsでvim環境を設定するための道のり：設定はどこに書けばいいのか

昔Emacsでhowmというツールを使っていたのを思い出したんだけど、もうEmacsとか使うの気が重いな、、と思っていたところvimにQFixHowmというプラグインがあるらしいので、そちらでセットアップしてみることにしました。いったんWindows Subsystem for Linuxのコンソール上のvimでセットアップしてみたんだけど、日本語切り替えとモード切替がめんどくさすぎて無理っぽかったので、gvimで再トライです。gvimはまともに使ったことが無いので、設定ファイルはどこに置けばいいのだ、、？からスタートです。

• 閑居う変数としては、$VIMと$HOMEが存在する。

• 確認するときは
  :echo $VIM
  または
  :echo $HOMEで表示される

• windows上では、.vimrcでなく_vimrcと_gvimrcとして作成する（これは単にWindows上のファイル名規則の制限かな）

• _gvimrcはGUI版のvim上でだけ有効

• $VIM\_vimrcと$VIM\_gvimrcは編集に管理者権限が必要になるのと、$HOME\_vimrcまたは$HOME\_gvimrcが存在すればそちらが優先（上書きされるので、これを作成すれば良い。

ためしに$HOME\_gvimrcに

colorscheme slate

と書いて起動したらカラー設定が変更されたので、OKとします。

見たサイト：https://oki2a24.com/2016/03/11/put-vim-setting-file-in-windows/

本当はvscodeでhowm的な機能があればいいなと思ってます。

あとはhowm（的なもの）が使えればいいというのがゴールなのでやっぱりEmacsというセンも捨ててはいないです。

ファイルが含まれているrpmパッケージの情報を表示する

$ rpm -qf {ファイルパス}|awk -F'-[0-9]' '{print $1}'|xargs yum info

pylintがcv2のメンバを見つけてくれない

・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のモジュールで定義されているから（？）の模様である。

pipenv2018.7.1とpip18.1の組み合わせはエラーになる

不具合に遭遇したのでメモ。

現象

$ pipenv install {some_package}
すると、エラー終了する。
Pipfileやパッケージのインストール自体は完了している
lockfileの作成あたりでコケている模様？

原因

エラーメッセージでググると同様の事象を見つけた。
https://github.com/pypa/pipenv/issues/2871

pipenv2018.7.1とpip18.1の組み合わせがエラーを起こしている模様。

解決方法

workaroundとしてはpipを18.0にする。
ポイントとしては、pipenvの環境のほうのpipを18.0にする。

$ pipenv run pip install pip==18.0

Pythonの環境構築にpipenvを使う

pipenvというPythonの仮想環境構築ツールを使い始めました。詳細は公式を見れば良いとして分かりづらかったところのメモ書き。

Pipenv: 人間のためのPython開発ワークフロー

書いている時点のバージョンは以下
$ pipenv --version
pipenv, version 2018.7.1

インストール

繰り返しだが詳細は上記の公式サイトのドキュメントを読めば良い。macOSの場合Homebrewとpipを使う方法があるようですが、私はPythonのバージョン管理にpyenvも使っていてHomebrewの方で入れるとバージョンが変になりそうな気がしたのでpipの方でインストールしました（Homebrewで試してはいない）。

$ pip install pipenv
すると、下記のようにpyenv配下にpipenvがインストールされてる模様。
$ which pipenv
/Users/hkuro/.pyenv/shims/pipenv

使い方

任意のディレクトリで
$ pipenv shell
とすると、"カレントディレクトリの名前-{hash}"という名前のvirtualenvが~/.local/share/virtualenvs/配下に作成される。hashの部分は詳しく調べてないけど何らかのハッシュみたいなので、別の同名ディレクトリでpipenv shellしても別のvirtualenvとして作成される（そりゃそうか）。

環境変数を設定することでカレントディレクトリに作成されるようにすることが可能（

PIPENV_VENV_IN_PROJECT）。これは環境によって違いそうなのでpipenv shellするときのオプションであったほうが便利そうな気もする。

カレントディレクトリにPipfileを作成してくれて、pipenv経由でパッケージをインストールするとPipfileの更新なども同時にやってくれる。これまでだとpip freezeとかいちいちしないといけなかった部分が、PHPでいうところのcomposerみたいな感じになっているということ、なんだと思った。

9/21追記：任意のディレクトリでpipenv shellして環境が作成されたあと、そのディレクトリを別のパスに移動したあとにpipenv shellすると新規のvirtualenvが作成される、元の場所に戻すと前のvirtualenvに戻れるので、やはりsuffixのハッシュはカレントディレクトと連動している模様。

virtualenvから抜けるには

pipenv shellした環境はvirtualenvでsource activateした場合と違ってサブシェル中で動作しているようなので、環境を抜けるにはCtrl+Dかexitする必要がある。deactivateしてしまうとvirtualenvな環境からは実質抜けてるけどpipenvが起動したサブシェルからは抜けられないみたいな中途半端な状態になってしまうので注意する。

環境の削除

普通のvirtualenvなので、上記の~/.local/share/virutualenv/配下の該当ディレクトリを丸ごと削除すれば良さそうだけど、もしくはpipenv shellしたのと同じディレクトリでpipenv --rmとすれば対応する環境は削除される。

その他

繰り返しだが作成されるのは普通のvirtualenvなので、
$ source ~/.local/share/virtualenv/hogehoge/bin/activate
とかすれば任意のディレクトリで特定のvirtualenvに入ることもできる。

Classic MacOSの文字化けしたファイル名を修正する

とある事情から、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"にすると良いような気がします。

Raspbian上で仮想キーボードをインストールする

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しないと表示されませんでした（キャッシュとかの関係でほっといてもそのうち出てくるのかもしれない）。

Technology RadarをCSVに対応させた

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追記： 取り込んでもらえました。

RasPi 3 でWiringPiでエラーがでたのでpigpioを使った

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

ANKERのPowerCore 10000とSeriaのUSB-CケーブルでPowerBook Proに充電できるか試した

SeriaでUSB-A/USB-Cケーブルが売られていたので、モバイルバッテリーのPowerCore 10000でPowerBook Proが充電できるのかを試してみました。 PowerBook Proは13インチの2016年タッチバーなしモデル、 モバイルバッテリーはANKER社のPowerCore 10000です。以下。
  結論。ぎりぎり充電できました。

USBケーブルはSeriaで108円で売られていた以下のケーブル。念のため3.0A対応と明記されているものを選びました。
   
注意しないといけない点は、アプリケーションを利用していない状態なら充電状態になったが、ただしFireFoxとかが「エネルギーを激しく消費中」と表示されているようなケースでは、いわゆる「給電モード」になるようで、ようするに利用しながら充電という、いわゆる電源アダプターと同じような利用方法は無理そう。持ち運び時のスリープ中などに充電する、という使い方ぐらいならそれなりに使えそうです。

PowerCore 10000の出力は5V/2.4Aでケーブルは5V/3.0A対応ということで、理論上12Wの給電が可能なはず。念のためシステムレポートで確認してみました。

スペック通り、12Wの電源として認識されているようです。

ちなみに純正のアダプタで充電している状態では以下。

60Wなので、ようするにおよそ1/5の充電速度、ということで良いんでしょうか。

PowerBook Proのシステムレポートだと、本体のバッテリー容量は
完全充電時の容量（mAh）: 4602
ということのようなので、カタログスペック上はPowerCore 10000は10000mAhなので、2回できる計算になりそう（そんなにできるのかな、これは試してない）。ただしPowerBook Proが半分ぐらいの充電状態でも満充電まで8時間とか表示されていたので、本格的な充電の用途には期待せず、あくまで保険的なものと考えたほうが良さそうです。

いずれにしても、PowerCore 10000はメインがスマホの充電用でAmazonだと2,000円ちょっとと非常に安価に買えるバッテリーだし、普段は携帯の充電用として持ち歩き、万が一PowerBook Proの充電が危ないときには緊急回避的に充電できるという意味では、非常に便利に使えると思う。ちなみに私はすぐ必要だったので店舗で買ったんだけど、Amazonの倍ぐらいして5,000円ぐらいで買った記憶がある。なんでそんな安いんだAmazon。

PowerBook ProのUSB-Cコネクタは賛否両論あるけれど、こんな風に充電に関して汎用的な製品が利用できるというのは、大きなメリットの一つだと思うし、PowerCore 10000もとても小さいのに容量も十分にある製品なんで、PowerBook Proを持っているならば一つ持っておいて損はない製品だと思いました。

追記。PowerCore 10000にはQuick Charge 3.0対応の新モデルが出ているようでした。こちらだともう少し性能が良いのかな。

VSCodeでThree.jsの開発環境を整える（３）

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

上記の必要な設定を行った上で、Firefoxはコマンドラインから以下のようにオプション付きで起動する必要があります。macOSの場合、

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

のようにします。-no-remoteオプションはローカルホスト以外からのアクセスを拒否する設定なので、環境によっては除外します。

上記で起動したFirefox上でたとえばhttp://localhost:8080/index.htmlにアクセスしたうえで、VSCodeのデバッグメニュー上からAttachメニューを選択し実行（F5）すると、Launch時と同じようにデバッグが実行可能になります。Launch時と同様に、デバッグ実行後、ページを再読み込みしないといけないケースもあるようです。

VSCodeでThree.jsの開発環境を整える（２）

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

VSCodeでThree.jsの開発環境を整える（１）

しばらく利用していなかったVisual Studio Codeをバージョンアップしてみたらすごく速く使いやすくなっていたので、すこし本格的に環境を構築して使ってみることにしました。VSCodeおよびnodeなどもこれまでごく基本的な利用しかしていないので、それらの知識のアップデートも兼ねます。

とりあえず、JavaScript（Three.js）の開発環境を構築することを目的にします。

• VSCodeのIntelliSenseを利用したコード補完ができること
• ChromeまたはFireFoxでブレークポイントを利用したデバッグが可能なこと
• デバッグはdockerのコンテナ環境で構築すること

上記３点ができるようになることを目的として、
まずは任意の.jsプロジェクトでthree.jsのコード補完が可能になることを目指します。

新規プロジェクトフォルダを作成する

任意のフォルダ名でプロジェクトフォルダを作成して、その中にcdします。

$ mkdir myproject
$ cd myproject

npm環境を作成する

まず、nodeのパッケージマネージャであるnpmが利用するpackage.jsonというファイルを作成します。これは以下のコマンドを利用するとjsonファイルが作成されます。自力で作っても別にいいと思う。

$ npm init

実行すると幾つか質問されるので答えていくが、とりあえずは適当（空欄）でもいいはず。

Three.jsをnpmでインストールする 

npmレポジトリにthreeというパッケージが存在するので、これをnpmコマンドでインストールします。注意点として、VSCodeのIntelliSenseがJavaScriptの補完をするためにはTypeScriptの型定義ファイル（？）を利用し、これはnpmで管理されているようなメジャーなものならばレポジトリで公開されているもののようなのだが、これをVSCodeが利用できるようにするためにはpackage.jsonのdependenciesリストに対象のモジュールがリストされている必要がある（VSCodeは、ここにリストされているモジュール名をヒントにAutomatic Type Acquisitionという機能を使って型定義ファイルを自動で探しにいく。もしくはjsconfig.jsonというファイルに明示的に宣言することも可能だが、今回は省略する）
すなわち、以下のコマンドを経由してthreeモジュールをインストールする。

$ npm install three --save

--saveオプションを忘れるとpackage.jsonが更新されないので注意する。--saveオプションは指定したモジュールをインストールすると共に、package.jsonのdependenciesリストに追加する。

 動作確認

以上でIntelliSenseは有効な状態となります。自分のモジュールの場合はどうするのかとかは今後調べる必要があるが、たぶんTypeScriptとかで書けということなんだと思う。

main.jsとかの適当なファイルを作成して、

var THREE = require('three');
THREE.

ここまでタイプしてCtl+Spaceとかすると、THREEの中にあるモジュールが補完対象としてリストされるようになっているはず。もしくは、.をタイプした時点で出てくるはず。これで暗記しなくてよろしい。