2012年12月17日月曜日

ディレクトリーを行ったり来たり

ディレクトリーを移動してまた元の場所に戻ってくるという操作を楽にしたいと思って、"pushd" コマンドを調べていましたが、"cd" で事足りました。
$ cd -
と、オプション "-" をつければ一つ前にいたディレクトリーに戻れます。
もう一度実行するとまた元の場所にもどります。
2カ所のディレクトリーで行ったり来たりできます。


"pushd" コマンドを使って移動していた場合は、もう少し自由に戻れます。
pushd コマンドで移動するとディレクトリースタックに移動前のディレクトリーがプッシュされていきます。
ディレクトリースタックの中身はコマンド "dirs" で確認できます。 "-v" オプションをつけると縦にリスト表示します。
$ dirs -v
0       /home
1       /dev
2       /sbin
3       /bin
4       /tmp
5       ~
ここで、移動したい番号を pushd のオプションとして次のように指定すると移動できます。 2番の /sbin に移動したいとすると、
$ pwd
/home
$ pushd +2
/sbin /bin /tmp ~ /home /dev
$ pwd
/sbin
ディレクトリースタックが増えすぎたら dirs -c でクリア。


実際には、ディレクトリーを移動しようと思った瞬間、脊髄反射的に "cd" と打ってしまいます。
でも pushd で移動しておかないとスタックに記録しないので、いざというときに pushd +2 などが使えません。

こんなとき、もし、zsh を使っているなら "autopushd" の設定を有効にしておけばよいです。
(autopushd は「cd したときにディレクトリースタックに pushd する」設定です。)
cd で移動しながらディレクトリースタックに記録できるようになります。

2012年11月30日金曜日

shift + tab で逆順 (Screen)

ターミナルエミュレータの Screen でフォーカスしている領域を移動するには、 C-a tab で移動できます。

モニターを新調して画面が広くなったので、今は3分割して使っています。 3分割では C-a tab するたびにぐるぐると領域をフォーカスが移動していきます。

3分割では表示できるところが一つ増えて確かに便利になったのですが、今までにないちょっとしたストレスを感じるようになりました。

これまで2分割のときには C-a tab するたびに一方の領域から反対側の領域に移動していました。 一方で作業していて、もう一方に移動してちょっと別の作業をしてまた元に戻るというのはまた、 C-a tab と打てばよいだけでした。

しかし、3分割では元に戻れず、次の3つ目の領域に移動してしまいます。


発見しました。反対周りに領域を移動する方法を。
" C-a shift+tab "
戻りたいときは、反対周りすれば戻れます。

気付いてしまえば、 tab で進んでいたものが shift + tab で逆に進むのは当たり前のような気がします。
ターミナルではキーバインドが別物という思い込みがあったので連想が働きにくかったのか?

何れにしても、shift + tab が何となくそんなキーバインドがあるという状態から、当たり前と思うようになった瞬間でした。

2012年10月29日月曜日

PC 環境整備 (キーボード)

キーボード購入

PC 環境をゴージャスにグレードアップする第2弾として、キーボードを購入しました。
'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 キー?(縦3本に〜)はCapsLockキーとして機能しているよう。急に大文字固定になって焦る。
    余談ですが、Emacs では C-4 で全角半角が切り替わるので、'$' を入力しようとして shift を control と間違えたときなど、これも知らないと焦る。

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

Happy Hacking Keyboard Professional JP Type-S 白(日本語配列)

リンク:HHKB Professional JP Type-S
リンク:KeyRemap4MacBook
リンク:PC 環境整備 (外部モニター)


2012年10月8日月曜日

PC 環境整備 (外部モニター)

外部モニター購入


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

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

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


設定など


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


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

そして、23 インチの方でターミナル縦3分割!
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 をまた縦分割する。 念願の縦3分割が叶いました。

感想


一応、デュアルモニターになって、一方ではターミナルの縦3分割が叶って、目的は 達せられたのですが、ブラウザを 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




2012年9月11日火曜日

TeX 選択の可能性

TeX の方が効率的


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

理由は幾つもあるかもしれませんが、資料作成の効率だけを考えた場合、直接編集できるワープロソフトの方が効率がよさそうに思えます。
しかし、1から文書を作成するのではなく、一部を修正するこんなケースでは TeX の方が効率的に編集できるのではないか。
  1. 文書のテンプレートがすでにあって、図を差し替える編集の場合。
  2. TeX の場合は貼り付ける図はファイルから読み込むので TeX ファイルにファイル名が書いてある。
    その書いてある画像ファイル名を編集するのみ。
    ワープロソフトのように画像ファイルを開いて、コピーして、貼り付けるという作業は必要ない。

  3. 上記のケースで、図の内容によって本文が変わる場合。またその図が大量にある場合。
  4. 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 美文書作成入門



2012年8月12日日曜日

Continue 続けること。

グッと来る言葉。

 負けたら終わりじゃなくて、やめたら終わりなんだよね
 どんな夢でもかなえる魔法、それは続けること

from " Continue " by SEAMO

***

「夢をかなえるゾウ」を読みました。
自己啓発本ですが、読み物としても楽しめます。

で、その本の話ではなくて、以前にこの本を元にしたドラマがあって、そのエンディング曲が "Continue" でした。
メロディーは耳に残っていたのですが、今回改めて歌詞も読んでみるとかなり熱くなりました。
やる気が満ち満ちて来ます。



夢をかなえるゾウ 文庫版


2012年8月11日土曜日

一大決心(サイ本の完読)

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

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

JavaScript 第6版


2012年7月1日日曜日

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 のビット演算は遅い?






2012年6月7日木曜日

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 のビット演算は遅くない?




2012年5月20日日曜日

JSLint のページがリニューアル

昨日とは違う画面になっていた。
JSLint のページが新しくなっていました。

オプションの有効・無効の設定が、今までは、白と黒と灰色の表示でしたが、False と True と Default という文字の表示になってわかりやすくなっている。

これまで、オプションの設定に白と黒と灰色の3種類あって、なんで2種類じゃなくて3種類なんだろうと思っていたら、3つめは "Default" だったのか!

んっ、Default ?
Default って True と False のどっちなんだろう・・・。





2012年5月19日土曜日

JSLint で自分のコードをチェックしてみた

JSLint でチェック

JavaScript の品質チェックツールである JSLint を使ってみました。
Web 上で実行してみると警告メッセージがたくさん出た。
見慣れないメッセージがたくさんあり(初めてなので見慣れないのは当たり前だが)、何を直せばいいのか一瞬途方に暮れる。

JSLint は JavaScript の書き方をより良いものにするためのチェックをしてくれるわけですが、では "より良い" というのは、何を目指せば良いのか? JSLint に合格するには何をすれば良いのか?

何を目指せば良いのかの指針がここに書いてある。
http://www.jslint.com/lint.html (これの翻訳が "JavaScript: The Good Parts" の付録 C にある。)


エラーメッセージ

もう一度エラーメッセージを見てみる。いくつか代表的なものをピックアップ。

・グローバル変数
Problem at line 2 character 12: 'document' was used before it was defined.
すべての変数は使われる前に定義されていないと、JSLint ではエラーとみなされる。 ブラウザで HTML に対して JavaScript を使用する時には "document" プロパティは当然、変数としては 宣言しないのでエラーになります。
オプションの "Assume a browser" にチェックを入れておくとブラウザであることが仮定されて、 document などのグローバルプロパティは宣言済みとみなされエラーとならなくなります。


・var
Problem at line 23 character 10: Move 'var' declarations to the top of the function.
変数宣言を関数の先頭で行いなさいということ。

for (var i=0; i<max; i++) {

といった var の使い方もダメです。
(でも、"JavaScriptパターン" の中で上記のような書き方をしているところを見つけてしまいました。フフッ。 "JavaScript パターン" では全てのコードが JSLint をパスしているはずなのに。)


・インデント
Problem at line 16 character 5: Expected 'callback' at column 9, not column 5.
インデントした文の開始が 5 ではなく 9 列目からにしなさいということ。 自分のコードの中で一つこのエラーの理由がよくわからないところがあるのですが、インデントの指針がどこにも書いていないし、ソフトの品質とは関係ない問題なので、オプション "Tolerate messy white space" で チェックしない様にします。(少し後ろめたいですが・・・。)


Warning!

JSLint のページの最初に、

Warning!
JSLint will hurt your feelings.

とあるように、些細な体裁の問題でたくさんのエラーが出るのでちょっと嫌になります。 でも、JavaScript を公開する前にはやっぱり一度はチェックするようにしようと思います。

なぜなら、
  1. JSLint ではブラウザのデバッグツールで見つからなかったエラーも見つかることがある。
  2. JSLint は些細な体裁も指摘してくれるので JavaScript 初心者でも、パッと見は恥ずかしくないものに直せる。
からです。


コンパイラは悪くない

インデントの問題に蓋をしてしまいましたが、自分のコードをよくよく見るとインデントにスペースとタブが混在していました。
タブはスペース 4 つと計算されるようです。
本来は同じレベルのインデントになるはずの文で、一方はスペースとタブでもう一方はタブのみとなっていて、 それでインデントを合わせなさいというような警告になっていたのでした。
(最近 Emacs の設定でインデントのタブをスペースに置き換えたので、そのためにスペースとタブが混在してしまったのかもしれません。)

ついつい、コンパイラの方を疑ってしまいました。
達人プログラマー への道は遠いなぁ。

達人プログラマー―システム開発の職人から名匠への道



2012年4月30日月曜日

タイピングアプリ 「Type Fu」

タイピングを正確にしたいと思っていたところに、タイピングアプリの紹介記事を目にしたので、 これを使って練習しています。(Chrome の拡張機能です。)

きちんとタイピングできない人や改めてタイピングを勉強したい人へ~無料でタッチタイプが練習できる「Type Fu」

1 回の練習が 10 秒〜 20 秒程度で終わるので疲れないのがいいです。
10 秒を何回も夢中になってやっているうちに、ほんの少しずつ問題のレベルが上がっていっていつの間にか身に付いている、といった感じで、問題もイイ具合の問題です。






JavaScript 本:「JavaScript パターン」と「JavaScript: The Good Parts」

JavaScript 本を2冊読んだ。

JavaScript パターン




JavaScript を安全に(= 間違いにくく)使うためのパターンを解説した本。
パターンと言っているのはデザインパターンだけでなく関数の使い方、オブジェクトの使い方などのベストプラクティス的な方法全般を言っていて、JavaScript 独特の「書き方」を説明している。

解説には分かりやすいコードがたくさん使われていて、そこから JavaScript の流儀に触れられる点でも良かった。

新しく JavaScript を学び始めたが、文法はよく知っている言語のアナロジーで理解できるが、 書いてみるとJavaScript らしくならない。この本を読んでやっと JavaScript の世界へ一歩踏み込めた感じがする。
個人的には以下の章が特に JavaScript らしさを知る上で役立った。

3章 リテラルとコンストラクタ、  
4章 関数、  
5章 オブジェクト作成のパターン、  
8章 DOM とブラウザのパターン


JavaScript: The Good Parts




 JavaScript は美しい言語だが醜い部分もある。美しい部分だけを取り出したサブセットを使うことによって JavaScript を美しいままに保とう、といったコンセプトで本書は書かれている。
不要なものは学ばなくてもいいしそれはいい考えだ!、と思って真っ先に読んだ JavaScript 本でした。
ですが、挫折しました。横着してはいけません。やっぱり先に入門書を読むことは必要でした。

今回は、入門書とJavaScript パターンを読んでからのリベンジです。
選び出した「Good parts」を系統的に説明していて、ひと通り文法を理解している人が改めて読み直すと新しい発見があるといった類の本だと思います。

醜い危険な書き方を避けて、美しい安全な書き方を選ぶというのは、実は「JavaScript パターン」と 目的は同じで、内容的にも重複している部分もあります。両著者ともYahoo! のエンジニアということもあるのでしょうか。



両書を読んで

タイトルからは別々の内容を想像しますが、コンセプトはほとんど同じで、また、両者はまるで一人の人が書いているのかと思うほど、哲学が似ています。
「パターン」の方はアンチパターンを示してからベストプラクティスへ導くようなストーリー性の説明に対して、「Good Parts」の方は選り抜きの「良いパーツ」一つ一つに着目して説明されています。
どちらかと言うと「Good Parts」の方がより上級向きといった印象でした。




2012年3月27日火曜日

Emacs の動画

Emacs の動画に刺激を受けたのでまとめておく。


Emacs の解説。(実はこういうので英会話のリスニングを勉強すると身に付くのではないか。)


人がエディタを使っているのを見るのは面白いし、ちょっとした癖なんかも、使い方改善のヒントになる。
高速タイピングに憧れていたが、ちょっと考えが変わって、これからは、速くなくてもいいので、
  1. 正確なタイピング
  2. snippet や補完を使い込む
ということで効率化を目指すようにしよう。





2012年2月28日火曜日

再帰について

順列問題を解く

CodeEval より
【問題】
Write a program to print out all the permutations of a string in alphabetical order.

例えば、
hat
という入力に対しては、

aht,ath,hat,hta,tah,tha
と出力する。

順列のような問題は、なんとなく再帰を使うのが良いような気がする。
#! /usr/bin/perl

use strict;
use warnings;

sub perm{
    my @orig_arr = @_;

    if ( scalar(@orig_arr) <= 1 ){
        my $result = shift @orig_arr;
    }
    else {
        my @result = ();
        for (0..scalar( @orig_arr )-1){
            my @workarr = @orig_arr;
            my $top_char = splice( @workarr, $_, 1);

            push @result, map { $top_char.$_ } perm( @workarr );
        }
        @result;
    }
}

sub solve{
    my @result = sort ( perm(split //, shift) );
    foreach (@result){  
        print $_.", ";
    }
    print "\n";
}

solve("hat");

ループでも解けるでしょうか?
再帰でできることは for 文(ループ)でもできるはずなのですが、今回の場合は for 文は意外と難しそう。
何が難しいのかというと "hat" のように 3 文字で固定であれば 2 つの for 文のネストでできますが、 文字数は可変なので静的なプログラムが書けない(と思う)。 for 文を結局再帰したくなる・・・。
そこで、新しい発見かもしれない教訓、

”繰り返し数が固定でない場合は、再帰処理が有効”


再帰は危険

for 文で書くのに何かヒントは無いかと、Code Complete を紐解いてみる。 「再帰を使って行えることは全て、スタックと繰り返しを使って行うことができる」とある。
そうかスタックね。・・・でもわからん。この問題はしばらく寝かせよう・・・。

ところで、前述の本には「再帰の使用に関するヒント」という項目に有用なヒントが幾つかあって、最後に「階乗やフィボナッチ数列に再帰を使用しない」とある。
そして、再帰は遅くて、消費メモリの予測ができなくて、理解が難しいと説明してあり、さらにかなり強い調子で「仮に、私の部下が再帰を使って階乗を計算しようものなら、別の誰かを雇うだろう」といっている。
上司によっては職を失いかねない危険をはらんでいます。再帰を使うときは要注意っと。






2012年2月5日日曜日

Mac の Finder で上の階層に移動したい

Mac の Finder で、今表示されているフォルダの上の階層へ移動する方法のメモ。
(キーバインドは、Command + ↑)
そして、メモしようと思って画面のキャプチャをしたときに色々と知ったことのメモ。

Finder で上の階層へ移動
Mac の Finder で自分のホームディレクトリー /Users/xxx を見たいときに Finder を起動すると、以下のような画面が開きます。
Windows のエクスプローラーのようにフォルダをたどって探したいのですが少し勝手が違います。
アイコンが並んでいる隣のサイドバーを見ても /Users などという名前もないし、画面上のボタンを押しても、/Users へたどっていけません。

ここで、キーボード操作で ' Command + ↑ ' とすれば一つ上の階層に移動できます。
(そして、下図の場合では「ユーザ」が /Users に相当するのでそこからたどれば /Users/xxx が見られる。)
上の階層の最後まで行くと、' Macintosh HD ' までたどれます。ココまで来ればアイコンダブルクリックで希望の下の階層へたどれます。
単に' Macintosh HD ' へ移動したい場合は ' Shift + Command + C ' で、一発で出来ました。C は「コンピュータ」の C 。
(メニューの「移動」にありました。)

しかし、上記のキーバインドは多分忘れるので、サイドバーに ' Macintosh HD ' を登録しておきます。' Macintosh HD 'アイコンを選択した状態で「ファイル」→「サイドバーに追加」。


サイドバーの一番下に ' Macintosh HD ' が追加されました。

画面のキャプチャについて
本題とは関係ないですが、記事を書くのに画面のキャプチャをやって、これも覚えておいたほうがよさそうなのでメモ。

あるウィンドウをキャプチャするのは、' Command + Shift + 4 + Space ' を押して、出てきたカメラアイコンでウィンドウを選択する。
(' Command + Shift + 4 ' は片手で押すには無理があるので、今度やるときは4は右手にする。)

今回メニューをキャプチャしようとしたら、下図のように思っていたのと違う画面が取れてしまった。
「 Dock に追加 」は本当は「サイドバーに追加」。

キャプチャする時に ' Shift ' キーを押してしまうのでメニューの内容が変わってしまうのです。


別のキャプチャの方法を探したら、「グラブ」というソフトがありました。「アプリケーション」→「ユーティリティ」から起動。
Shift キーを押さずに10秒タイマーでキャプチャできます。









その他
Finder の「デバイス」に FireFox があるのが気になりますが、話が発散しすぎるのでスルー。





2012年1月29日日曜日

Google Chrome で Cookie が試せない

Cookie の読み書きができない

JavaScript を始めました。
まずは、Cookie の機能を試してみようと簡単なサンプルを動かして見ましたが、うまくいきません。
Chrome を使っているのですが、試行錯誤しても分からず、ちょっと試しに Safari で動かすと読み書きできているようです。うれしい・・・(/_;)。

Cookie は標準的な機能かと思っていたんですが、ブラウザによるんですね。

調べると、Chrome はデフォルトではローカルファイルでの Cookie の使用はサポートしていないようです。 ('file://' では Cookie は実行できないようです。)
実行するには フラグ --enable-file-cookies が必要とのこと。(参考:Support cookies on file://



Google Chrome をフラグを付けて実行

参考:Run Chromium with switches (flags)

Mac で Chrome をフラグ付きで実行するには、コマンドラインから以下のように起動する。
$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-file-cookies &

Web プログラマの人がブラウザの違いによって苦労しているとの話はよく聞きますが、苦労を垣間見た気がします。





2012年1月23日月曜日

Emacs 自動保存 + バージョン管理導入

Emacs で自動保存


自動保存機能について Emacsテクニックバイブル で紹介されている。(参考とされている高林氏の記事「Emacsでファイルの自動保存 (auto-save-buffers)」も興味深いです。)

内容は、「作業中にPCが落ちてしまった時のために自動的に保存するようにしましょう。また、保存操作には2ストロークも必要なので、自動化しましょう。そして、間違って保存してしまった時のためには、バージョン管理システムを使っておこう。」というもの。

保存操作が煩わしいとはあまり感じていなかったが、それはパソコンを使い始めてからこれまでに身に染み込んでいる、ファイルは保存するものという無意識の感覚のためかもしれない。こまめに保存する癖が付いているので、保存が自動化されると思っても見なかった解放感があるかもしれない。

設定ファイル等のバージョン管理をしたいとも思っていたところだったので、自動保存をインストールして、バージョン管理システムも導入してみた。

(全く余談だが、僕は「自動保存」の仕組みには Evernote で初めて触れた。 未だに ノートを書いた後には保存ボタンを探してしまう。)



おうちサーバにバージョン管理導入


Subversion を導入した。 mod_dav_svn.so がインストールされるよう config 設定してインストール。
まずはひと通りのインストールができたが、最初の import で permission denied となってしまった。

原因は Subversion のリポジトリのパーミッションの設定が間違っていたため。
Apache を Subversion サーバとして使うので、Apache からアクセスできるようにパーミッション設定しなければならなかった。

Apache の user と group は Apache の設定ファイル(httpd.conf)に記述してある。
;; Apache の設定ファイル
User www
Group www
User と Group が www となっているのでリポジトリの所有者を合わせて変更する。
;; リポジトリのディレクトリを /var/svn/ に作成している場合
$ sudo chown -R www:www /var/svn/

今日から、自動保存+バージョン管理です。
保存は忘れてもいいけど、commit を忘れないようにしないと ... 。


参考:Emacsテクニックバイブル ~作業効率をカイゼンする200の技~


参考:実用 Subversion 第2版