PC 環境整備 （キーボード）

キーボード購入

PC 環境をゴージャスにグレードアップする第２弾として、キーボードを購入しました。
'HHKB Professional JP Type-S' です。

普通なら全く目もくれない価格帯のものなのですが、最近タイピング練習を続けていて、 タイピングの精度とかスピードを意識していたので、道具も一度いいものを使ってみようと思い購入しました。
このキーボードの特徴は "静寂性" です。 緩衝材がキー内部にあって打鍵音のうるささは従来品の 30% 減だそうです。

実際、カチャカチャという音はしなくて、ゴトゴトという感じです。 （耳障りな高音が抑えられています。）
僕はキーボードのカチャカチャいう音が嫌で、キーを打つときに無意識に音がなるべくならないようにそーっと打ってしまうのですが、この 'Type-S' では気にせずしっかり打てます。
実際にタイピングのスピードもあがりましたが、しっかり打てる効果が大きいように思います。 （一応、'タイピング特性の向上' というのがメーカー HP の説明にあるので構造設計もスピードアップの理由でしょう。）

Mac でも使えます

1. Windows 用 or Mac 用ディップスイッチで Mac 用を選択します。


2. そのままでもとりあえず使えますが、HHKB の HP より Mac 用のドライバをダウンロードしてインストールします。 これで、Eject キーが有効になったり、スペースキーの両サイドのキーが「英数」と「かな」になります。
   Eject キーは純粋に Eject としては使いませんが、「スリープ」のショートカットが 「 option + command + Eject 」なので必須です。
   （デュアルモニタにすると MacBook Air のディスプレイを閉じただけではスリープしなくなったので、やむなくショートカットを使ってます。）


3. 上カーソルキー（上矢印キー）をシフトキーに変更する。（ディップスイッチ設定）
   
   
   
   
   このキーボードの唯一の難点と思うのが、右シフトキーが小さいこと。すぐ隣が上矢印キーなので、シフトを押そうとして、しょっちゅう上矢印キーとタイプミスします。
   そこで、ディップスイッチ設定で上矢印キーをシフトキーに設定しました。 カーソルキーが使えなくなるので、勇気のいる設定です。（Fn キーを使った別の入力方法はある。）
   ですが、今まで Emacs のカーソル移動のキー操作である C-n, p, f, b などがなかなか身に付かなかったので、これで強制的に身に付きそうです。


4. おまけ
   MBA では '\'（バックスラッシュ）がキーボード右上の 'delete' のとなりにあって、右下の'shift'の隣にはありません。
   
   
   
   
   不便に思っていたのですが、HHKB では右シフトの隣に'\'の刻印があります。 '\'が入力されるかと期待しましたが、やっぱり入力できませんでした。
   
   それならばといろいろキーバインド変更を試して、なかなかうまくいかず、結局
   'KeyRemap4MacBook'
   というソフトを利用させてもらいました。あっさりできました。ありがとうございます。
   ( "Underscore(Ro) to Backslash(\)" にチェックを入れる。)
   
   
   
   
5. おまけ2
   HHK キー？（縦３本に〜）はCapsLockキーとして機能しているよう。急に大文字固定になって焦る。
   余談ですが、Emacs では C-4 で全角半角が切り替わるので、'$' を入力しようとして shift を control と間違えたときなど、これも知らないと焦る。

このキーボードを長く使っていこうと思います。そして元を取ろうと思います。

Happy Hacking Keyboard Professional JP Type-S 白（日本語配列）

リンク：HHKB Professional JP Type-S
リンク：KeyRemap4MacBook
リンク：PC 環境整備 （外部モニター）

PC 環境整備 （外部モニター）

外部モニター購入

物欲の秋。
効率化のために、自宅の PC 周りの環境をゴージャスに整えました。
まず、第１弾として 23 インチのモニターを購入しました。

僕は MacBookAir 11 inch を使用しています。 サブマシンのつもりで購入して、今ではほとんどこのちっちゃいマシンをメインで使っています。
ほとんどメインで使っているので、思い切って環境をグレードアップすることにしました。

やりたかったのは、

1. ノート PC とデュアルモニターにして一方でブラウザをみながら一方で編集をすること。
2. 大きいモニターになるのでターミナル画面(screen) を縦３分割にすること。 （1:2 の縦分割にして "2" の方を Emacs にして Emacs 内でさらに縦２分割したい。)

です。

設定など

こんな風に配置してみました。

正面に 23 インチのモニターを置いて右側に MBA をサブモニターとして置いています。
ブラウザをノートの方の画面で開いて、23 インチの方は ターミナルにしました。

そして、23 インチの方でターミナル縦３分割！
screen では以下のコマンドで縦分割して分割幅を設定できる。

$ screen -X split -v     # 縦分割 
$ screen -X resize 80    # 縦分割のとき幅を 80 にする

.screenrc には以下のように書いた。

# .screenrc file

split -v
resize 80
screen
split
focus down
screen
focus right
screen

ターミナルをだいたい 1:2 の分割にして、広い方で Emacs をまた縦分割する。 念願の縦３分割が叶いました。

感想

一応、デュアルモニターになって、一方ではターミナルの縦３分割が叶って、目的は 達せられたのですが、ブラウザを 11 インチで見なければならないのはちょっと残念。 これまで、これでやってきていたのに隣の大画面を見るとこんな気持ちになってしまう。
人間の（僕の）欲深さの縮図がここにあるのか・・・。

しかし、インプットの代表のブラウザとアウトプットの代表のエディタ。
モニターサイズと同じように、インプット ＜ アウトプット とする気持ちを 常に思い出させてくれるので、これもよし。

ナナオ FORIS 23.0インチ TFTモニタ 1920x1080 DVI-D24ピンx1 D-Sub15ピンx1 HDMIx2 ブラック FS2333

PLANEX Mini Displayport -]HDMI変換アダプタ (MacBook MacBook Pro MacBook Air) PL-MDPHD02

TeX 選択の可能性

TeX の方が効率的

論文作成などには選ばれる TeX ですが、業務での資料作成ではなかなか選択しにくいです。

理由は幾つもあるかもしれませんが、資料作成の効率だけを考えた場合、直接編集できるワープロソフトの方が効率がよさそうに思えます。
しかし、１から文書を作成するのではなく、一部を修正するこんなケースでは TeX の方が効率的に編集できるのではないか。

1. 文書のテンプレートがすでにあって、図を差し替える編集の場合。
TeX の場合は貼り付ける図はファイルから読み込むので TeX ファイルにファイル名が書いてある。
その書いてある画像ファイル名を編集するのみ。
ワープロソフトのように画像ファイルを開いて、コピーして、貼り付けるという作業は必要ない。


2. 上記のケースで、図の内容によって本文が変わる場合。またその図が大量にある場合。
TeX はテキストファイルなのでプログラムで処理が容易！！！
プログラムから TeX ファイルを出力するようにすると効率は無限大！！！（・・・ちょっと誇大広告）

例えば図のファイル名を工夫すると、プログラムから図のファイルを読み込んでファイル名から本文を変更して出力できる。
これが大量にあってもプログラムなら大丈夫。
フォームが決まっている実験レポートなんかは TeX で効率良く書類を作成するのに向いているのではないか。

Mac への TeX のインストール

TeX にも統合環境があるようなのですが、編集は Emacs で行うので GUI は不要です。
インストールと管理の手間が少なそうなので、MacPorts でインストールしました。

$ sudo port install texlive-lang-cjk

そして、sample.pdf という pdf ファイルを作成するには、sample.tex ファイルを作成して、以下のコマンドで pdf ファイルを作成。

$ platex sample.tex          // dvi ファイルを作成
$ dvipdfmx sample.dvi        // pdf ファイルを作成

最初 "texlive-lang-cjk" ではなくて "ptex" をインストールしたのですが、ptex の方がバージョンが 古いのか図の扱いがうまくいかないことが有りました。
"ptex" はアンインストールし、"texlive-lang-cjk" を入れなおすことで解決しました。

なんでもプログラミング

これで面倒な書類作成も楽しいプログラミングでできるようになります。
（効率化よりもこっちが本当の理由かもしれない・・・。）
しかし、書類にバグが・・・というなんとも説明できない失態だけはおかしませんように。

[改訂第5版] LaTeX2e 美文書作成入門

Continue 続けること。

グッと来る言葉。
「
　負けたら終わりじゃなくて、やめたら終わりなんだよね
　どんな夢でもかなえる魔法、それは続けること
」
from " Continue " by SEAMO

***

「夢をかなえるゾウ」を読みました。

自己啓発本ですが、読み物としても楽しめます。

で、その本の話ではなくて、以前にこの本を元にしたドラマがあって、そのエンディング曲が "Continue" でした。

メロディーは耳に残っていたのですが、今回改めて歌詞も読んでみるとかなり熱くなりました。

やる気が満ち満ちて来ます。

リンク：Continue - SEAMO - 歌詞 : 歌ネット

夢をかなえるゾウ 文庫版

一大決心（サイ本の完読）

JavaScript で行き詰ることがあって、やっぱりひと通り文法をやり直そうと思いました。
読みさしで積ん読状態だった "JavaScript 第５版" を最後まで読み切ろうと決心した矢先、
"JavaScript 第６版" が発売になったようです。

積ん読にも賞味期限があるのを忘れてました。

JavaScript 第6版

JavaScript のビット演算は遅くない？

JavaScript の「ビット演算」は遅くていいことがないと、JavaScript: The Good Parts では悪者扱いされています。 遅くなる理由として、ビット演算を行う際に倍精度浮動小数点型を整数に変換し、ビット演算後にまた倍精度浮動小数点型に戻す処理を行うため、とある。

では、この処理でどのくらい遅くなるのだろう？
Chrome で次のようなコードで試してみた。

// 足し算 +
var flag,
    v = [1, 2, 4, 8, 16, 32, 64, 128];

for (var i = 0; i < 9000000; i++) {
    flag = v[0] + v[1] + v[2] + v[3] + v[4] + v[5] + v[6] + v[7];
}


// ビット演算は '+' を '|' に置き換え
    flag = v[0] | v[1] | v[2] | v[3] | v[4] | v[5] | v[6] | v[7];

足し算とビット演算をそれぞれ 9000 万回実行して時間を計測してみると、普通の足し算では平均して 151 ms で ビット演算では 122 ms。
 ・・・えっ、ビット演算の方が速いではないか！

ビット演算は言われているほど遅くなく、むしろ速いようです。

僕の中では、ビット演算子は "good parts" に昇格です。


JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス


リンク：JavaScript のビット演算は遅い？

JavaScript のビット演算は遅い？

JavaScript: The Good Parts によると JavaScript のビット演算は予想に反して、ハードレベルに近い演算からは程遠く、遅いとのこと。
JavaScript の数値オペランドである倍精度浮動小数型を整数に変換して、それから演算を行い、また倍精度浮動小数型に戻すという処理をしているため。

そのため、ビット演算を使う必要性が無いので「悪いパーツ」とされている。

しかし、JavaScriptグラフィックス で興味深い説明があった。
ビット演算を使うことによりアルゴリズムを変更できる時には、高速化に使える場合がある。
あるプロパティが存在するかどうかを示すフラグとして、変数のあるビットが立っているかどうかを見るという使い方をすることがある。

こんな例が示されている。

var search = ['big', 'young', 'white'];    // このプロパティを持った犬をさがす
for (var c = 0; c < search.length; c++) {
    if (dog[search[c]] == undefined) break;
}
if (c == search.length) {
    /* 見つかった！ */
}

上記のようにしたい時は、下記のようにビット演算を使うと高速化できる。

var searchFlags = 128 + 32 + 4;    // 128: big, 32: young, 4: white を表す
if (searchFlags & dog.flags === searchFlags) {
    /* 見つかった！ */
}

なるほど。「悪いパーツ」と言われているものを盲目的に切り捨ててもいけない。
というか、いろんな人の意見を聞くというのは大事なんだなぁ。


JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

JavaScriptグラフィックス ―ゲーム・スマートフォン・ウェブで使う最新テクニック


リンク：JavaScript 本：「JavaScript パターン」と「JavaScript: The Good Parts」
リンク：JavaScript のビット演算は遅くない？