ブルーライトのせい？ PC用メガネを注文しました

家で iMac を一日中見つめて作業をしていると、恐ろしくしんどくなることがある。
夕方になるととんでもなく眼球に疲れがたまり（特に目の奥）、体の痛みのみならず頭痛までしてくる。
今年3月に14万円で買った27インチの最新iMacの画面の広さと美しさには大変満足しているのだが、それが今の悩みだ。


Apple iMac MD095J/A (27型ワイド液晶 Core-i5搭載

以前、電車の中でブルーライトが目に悪いという広告を目にしたが、どうもあまり信じられなかった。
でも、その言葉をフラッシュバックのように今日、思い出した。
いろいろ調べた結果、効果があるという人と、効果がないという人、いろいろな意見はある。
科学的根拠があるかどうかも、賛否両論のようだ。

iMacの仕様を見ると、確かにLEDのバックライトを使用したディスプレイとなっている。
LEDはエネルギーの高い波長である青い色をLEDではないモニターよりもっと強く放射するらしい。

私の目のしんどさは、尋常ならないものがあるので、ダメ元でということで今日、ブルーライトを40%カットするというグラスを注文してみた。


クリップオン パソコン/コンピューターメガネ グラス ブルーライト低減 カット 405PC CAシリーズ

私はメガネ使用者なので、その上から着けられるものを探した。
そういうのをクリップオンと呼ぶらしい。
だいたい2600円ほどするので安くはないが、一番評価が良さそうなものを注文した。

届いたら早速試して、効果のほどを報告してみたいと思う。

Mac (Linux) でバイナリデータをバイト単位で比較するコマンド

またもや m4a (iPhone で録音した音声ファイル) が壊れてしまった。
以前は Windows で GUI ツール（バイナリエディター）を使って復元した（下記記事参照）。

破損した m4a 音声ファイルの修復記録

しかし、今度は Mac 上でコマンドを使って修復を試みようと思う。
まず最初にぶつかったのが、バイナリデータを1バイト単位で比較するためにどうすればよいかである。
Stack Overflow などのサイトを見てみたが、いまいちよく分からないので、頑張って自分でやってみることにした。

例として、以下のコマンドでランダムデータを作ってみる。

home-imac:Docs user$ head -c 200 /dev/random > tmp.data

そして、このデータを hexdump コマンドを使って16進数で表示してみる。

home-imac:Docs user$ hexdump -v tmp.data
0000000 c7 60 51 a4 cb 46 f1 c8 8a 60 22 f5 3e 81 44 45
0000010 5a ca 8a b1 9e 7b 1d 47 bc 19 bd df ca 93 8d e4
0000020 37 c0 72 54 ca 8e a7 63 60 58 ad de d6 29 1a df
0000030 85 b1 2c fb 64 d7 d3 70 b5 5f f4 5e 23 cb c7 22
0000040 f5 4e 9f 32 32 44 5b 88 24 50 51 36 0e 16 7c 93
0000050 64 1e 9a 20 e3 de 98 5c a1 04 d7 19 2c 20 58 76
0000060 00 a4 73 d9 40 8d 42 99 e4 16 f0 b6 23 01 b0 5c
0000070 83 24 d8 19 99 6a 81 ed a6 03 4b 81 a3 ca f3 bf
0000080 bc 6e 62 87 15 73 29 f9 80 f4 19 1a c7 ce ac 3b
0000090 e0 84 83 23 02 3c 57 2c 3d 93 70 32 33 da 1d c6
00000a0 56 c5 83 73 91 90 e8 b3 23 24 30 16 1c 42 1d 3a
00000b0 4b 85 b0 32 77 ef a8 e5 fc 32 59 96 03 9d 31 7e
00000c0 b2 2d a2 79 b5 1f a6 26                        

これだけだと、別のファイルとの比較の際、たとえば1バイト削除されていたような場合、以降の行は全て差異があると検出されてしまう。
そこで、バイナリの値を1バイト＝1行で書き出してから、比較しようと思った。
まず、先頭のオフセットの8桁の16進数をsedコマンドの正規表現による置換命令によって削る。

home-imac:Docs user$ hexdump -v tmp.data | sed 's/[0-9a-z]* //'
c7 60 51 a4 cb 46 f1 c8 8a 60 22 f5 3e 81 44 45
5a ca 8a b1 9e 7b 1d 47 bc 19 bd df ca 93 8d e4
37 c0 72 54 ca 8e a7 63 60 58 ad de d6 29 1a df
85 b1 2c fb 64 d7 d3 70 b5 5f f4 5e 23 cb c7 22
f5 4e 9f 32 32 44 5b 88 24 50 51 36 0e 16 7c 93
64 1e 9a 20 e3 de 98 5c a1 04 d7 19 2c 20 58 76
00 a4 73 d9 40 8d 42 99 e4 16 f0 b6 23 01 b0 5c
83 24 d8 19 99 6a 81 ed a6 03 4b 81 a3 ca f3 bf
bc 6e 62 87 15 73 29 f9 80 f4 19 1a c7 ce ac 3b
e0 84 83 23 02 3c 57 2c 3d 93 70 32 33 da 1d c6
56 c5 83 73 91 90 e8 b3 23 24 30 16 1c 42 1d 3a
4b 85 b0 32 77 ef a8 e5 fc 32 59 96 03 9d 31 7e
b2 2d a2 79 b5 1f a6 26                        

次に、この出力のスペース部分を tr コマンドで改行に変えてしまえば、見事に1バイトの16進数表現値が1行ずつに表示された。

home-imac:Docs user$ hexdump -v tmp.data | sed 's/[0-9a-z]* //' | tr ' ' \\n
c7
60
51
a4
cb
46
f1
...

あとは、これを適当なテキストファイル tmp.txt に出力する。

home-imac:Docs user$ hexdump -v tmp.data | sed 's/[0-9a-z]* //' | tr ' ' \\n > tmp.txt

最後に、比較したい tmp2.data を同様に tmp2.txt に出力し、diff コマンドで比べればよい。

home-imac:Docs user$ diff tmp.txt tmp2.txt
94d93
< 0d
189d187
< 0d
284d281
< 0d
...

上記は、たとえば tmp.data の94バイト目の '0d' という値のバイトが、tmp2.data の93バイト目の次には見当たらないということを示している。
この方法を使えば、破損した m4a ファイルを、破損していないファイルとバイト単位で比較することが可能そうだ。


A valid provisioning profile matching... エラー

ほしねこも、ついに iOS Developer Program に加入した。
個人用のライセンスで年間 8,400 円 ($99) という値段は、円安の時の為替レートで設定されたものだろうが、アベノミクス効果で円安となった今は、上がるのは時間の問題かもしれない。

それはいいとして、Enrollment においては、姓名やその他の情報をすべて英語にした新規 Apple ID を使って行った方がいいとの情報を目にしたので、その通りやってみた。
既存の Apple ID の登録メールアドレスは hoge.hogeo@gmail.com みたいなアドレスだったので、「.」(ドット) を取って hogehogeo@gmail.com で登録したら、別メールアドレスとして認識されて、問題なく別 ID を取得できた。
Gmail は @ マークの前のアドレスに何個ドットを付けても同じメールボックスに届くので、このような裏技が可能である。
こうしておけば、新たに Google アカウントを取得する手間も省けるし、To アドレスを基にフィルターさえ設定しておけば、振り分けも容易である。

さて、メールで送られてきた iOS Developer Program の Activation Code をクリックすると、Webでいろいろ言われている通り、やはりアクティベーションに失敗した。
さっそくサポートセンターに定型文の通りにメールで連絡すると、翌日には解決してくれた。
良くは分からないが、Apple ID を英語の情報だけで作っても、支払いのクレジットカードの情報は日本の Apple Store で日本語の氏名、住所等を入れて決済したので、それが英語の情報と一致せずに、内部エラーを起こしていたのではないかと推測している。
まあ、あくまでも推測だが。

そして、次に実機でアプリをテストするための Provisioning Profile をインストールするのだが、手順通りにやったにも関わらず、Xcode でビルドすると下記のエラーが起きてどうしようもなくなった。

a valid provisioning profile matching the application’s Identifier ‘com.ja.HogeHogeAppID’ could not be found

恥ずかしいことながら、このエラーを解決するのに丸まる3日も費やしてしまった。
Google でいろいろ調べたのだが、結局分からずじまい。
中2日は、諦めて Xcode を触る意欲も萎えてしまったのである。
恥ずかしいことこの上ない。

それでもって、ついに昨晩、解決した。
それは、

Xcode で Organizer を開き、Devices をクリックした後、Editor メニューから Refresh from Developer Portal を実行する

だけであった。
初めて Provisioning Profile をインストールした際もこの手順を実行したのだが、なぜかうまく Provisioning Profile がインストールされなかったようである。
理由は不明である。
いずれにしても、確かに英語のエラーメッセージを読むと、まさしくその通りのエラーであった訳だが、解決にこんなに時間がかかるとは思わなかった。
ソフトウェアの開発というのは、こういう地味なエラーとの格闘であるようだ（私の勘が悪いだけかもしれないが）。

こうして、私のホゲホゲアプリは、iPhone 5 で起動した。
エミュレーターでは味わえない感動がそこにはあった。
やはり、実機で試すというのは、私のような肉体で感じることが頭で考えることより重要だと思っているエンジニアには必須であるようだ。

Windows のテキストファイルを Mac 用に変換する

日本語版の Windows でメモ帳などを使って作成したテキストファイルは、デフォルトでは

文字コード： Shift JIS (正確には CP932)
改行コード： CRLF (¥r¥n)

になっている。

一方、Mac OS X でテキストエディットで作成したテキストファイルは、デフォルトでは

文字コード： UTF8 (ユニコード)
改行コード： LF (¥n)

になっている。

そのため、Windows で作成したテキストファイルを、Mac のテキストエディットで開いた際、たとえば Control + K というショートカットキーで1行削除しようとしても、なぜか文字だけ消えて、改行文字は消してくれない（次の行が上にせり上がってこない）という現象が起きる。

この、「次の行が上にせり上がってこない」現象は、改行文字が CRLF (¥r¥n) となっている行だけで発生する（文字エンコードは問わない）ことを "od -c windows.txt" というバイナリコード表示コマンドで確認した。

そこで、Mac 用に Windows ファイルを変換するコマンドを調べてみた。

iconv -f CP932 -t UTF8 windows.txt | tr -d \\r > mac.txt

上記のコマンド（ファイル名は自分のファイルの名前に直してね）をターミナルを開いて実行すればよい。このコマンドの解説をしてみる。

まず iconv -f CP932 -t UTF8 windows.txt だが、これは windows.txt の文字エンコードを CP932 から UTF8 に変換して、標準出力に出せという命令である。

標準出力は | (縦棒) によって次のコマンドの標準入力に渡される。

tr は変換を行うコマンドで、tr -d \\r により CR (¥r) 文字を消して標準出力に出せという動作になる。

標準出力を > によってファイル mac.txt にリダイレクト（書き込め）という命令を行っている。

これにより Control + K というショートカットキーで1行削除をすると、スムーズに意図した通りの動作を行ってくれ、ストレスがなくなった。

---

入門bash 第3版/オライリージャパン

￥2,940
Amazon.co.jp

Mac のターミナルで Windows のようにタブキーで入力補完する方法

Mac のターミナル (bash) は Windows のコマンド・プロンプト画面に相当する。
ここで、Windows のようにタブキーを押して入力補完しようとすると、候補が表示されるだけで、自分で改めてタイプし直さないといけない。
これは、面倒なので Windows ライクに設定を変更する方法を調べてみた。

まずホームディレクトリーの下に、.inputrc という名前のファイルを生成する。
ここに

set completion-ignore-case on
TAB: menu-complete

と書く。
ファイルの生成方法として簡易的には、下記のようにコマンドをタイプすればよい。

echo set completion-ignore-case on >> .inputrc
echo TAB: menu-complete >> .inputrc

新しいターミナルを起動（新しいウィンドウもしくはタブを開く）とこの設定が有効になる。
1行目は、入力補完で大文字文字を区別しないという設定、2行目は、タブキーを押すと入力補完を行うという設定である。
これにより

home-imac:~ user$ cd D [TAB]

と押すと

Desktop/ Documents/ Downloads/ Dropbox/

などと候補が表示されるだけであったのが、小文字の d をタイプした場合でも

home-imac:~ user$ cd d [TAB]

と押すと

cd Desktop/

のように Windows ライクな入力補完を即時に行ってくれるようになる。

---

Macを買ったら最初に読む本 OS X Lion対応版/アスキー・メディアワークス

￥1,344
Amazon.co.jp