IT風雲児のブログ: 2017

2017年10月9日月曜日

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"にすると良いような気がします。

2017年8月26日土曜日

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

2017年8月21日月曜日

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

2017年7月8日土曜日

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対応の新モデルが出ているようでした。こちらだともう少し性能が良いのかな。

2017年5月8日月曜日

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時と同様に、デバッグ実行後、ページを再読み込みしないといけないケースもあるようです。

2017年5月7日日曜日

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

2017年5月6日土曜日

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の中にあるモジュールが補完対象としてリストされるようになっているはず。もしくは、.をタイプした時点で出てくるはず。これで暗記しなくてよろしい。

2017年1月3日火曜日

MacBook Pro 2016用のマルチポートアダプタをkickstarterで支援しました。

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のmysqldコンテナにdumpデータをロードする

ローカルにmysqlのダンプファイルがあるとして、
すでにmysqldが起動しているdockerコンテナが存在するとする。

このとき、以下のようにすればローカルのdumpファイルのロードが可能。

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

参照：http://depressiverobot.com/2015/02/19/mysql-dump-docker.html

登録: 投稿 (Atom)

IT風雲児のブログ