2011/01/31

丑やの革製 MacBook Air ケース

先日注文した丑やの革製 MacBook Air ケースが届いた。
専用設計で職人が手作りしているだけあって、 縫製も非常に丁寧な仕上がりだしサイズもピッタリで納めた時に良い感じ。
新品なので革が馴染んでいないのだが、 これから使い込むにつれてとても良い風合いになると思うので 今からとても楽しみだ。

Image: RIMG0150.JPG

こんな高価なケースなんて馬鹿げているとは思うが、 反面、Mac だからしょうがないかと(半ば自棄気味に)諦めてもいる。

2011/01/22

温泉ツーリング to 南伊豆

週末を利用して友人と南伊豆の温泉に一泊で ツーリング してきた。
勿論、バイクは反社会的な 2 ストローク 2 台(しつこい)。

まずは定番の東名高速海老名でお茶休憩。 日頃の行いの良さを象徴するかの様に気持ちよく晴れ渡った青空の向こうには 雪化粧した富士山もくっきり綺麗によく見える。 そのまま小田原厚木〜西湘バイパスを経由して海沿いの国道 135 号線へ。 1 月という事もあり、とりあえず往路は比較的温暖な海沿いを 南下するという軟弱コースを選択したので、 渋滞にもめげずにひたすら南下南下南下…。
東伊豆の海沿い、特に日頃の行いの良さを象徴するかの様な (大事な事なので2回…ry)天気の良い午前中は海面にキラキラと反射する 太陽の光がとても綺麗で抜群の眺望ではあるのだが、 単調すぎて若干物足りなさを感じてしまう部分は否めない。 まぁ、軟弱コースを主張した張本人なので文句は言うまい(言えない)。

昼食は稲取の「徳造丸」という網元料理のお店で海鮮丼を堪能。 普段は行列したり待ったりしてまで食事をする方ではないのだが、 ここは多少待ってでも食べる価値はあった。 生しらす、生桜エビ、生ぼたんえびなどがふんだんに載っている ここのお店の海鮮丼は量もおいしさも大満足。

Image: RIMG0116.JPG

徳造丸の海鮮丼

食事の後は再度単調な道を延々と南下…
イチ押しでお勧めされた外浦海岸にある「万宝」という干物屋さんでは干物を物色。 たしかにとても美味しそうな干物が沢山並んでいる。 バイクだと大きな荷物が運べないのだが、 宅配便で送ることにしたので美味しそうな干物を際限なく買ってしまう。

そうこうしているうちに無事に宿に到着。 古民家の宿というだけあって見た目も古びてて良い感じ

Image: RIMG0123.JPG

古民家の佇まいにそぐわない2台

予定よりは相当早く到着したので、 のんびりと露天風呂につかりながら疲れをほぐしていると食事の時間。
格安プランだったのであまり期待をしていなかったのだが、 とても美味しい夕食+オプションで金目鯛の煮付けに大満足 (というか食べ過ぎ)。 食事を撮影しようとカメラを持っていたのだが すっかり忘れて食事をむさぼり食ってしまったので写真なし。 まぁ、写真撮影を忘れる位に美味しかったという事で。
食事の後は温泉に行こうとか考えていたのだが、 満腹+良い感じの疲れ具合に動く気にもなれずに 9 時過ぎには就寝。
呆れる程早寝をしたので、 さすがに翌朝は6時頃には自然と目が覚め朝食前に温泉にのんびりつかる (のんびりし過ぎて若干湯あたり気味だったのは内緒)。

ビュッフェ形式の食事を堪能したらいざ出発。
昨日天気が良くて暖かかったのでついつい色気(?)を出して 復路は城ヶ崎から遠笠山経由で伊豆スカイラインを通る事にしたのだが、 路肩には雪が残っているわ、路面は濡れているわ、 日陰ではところどころ路面も凍結しているわで ワインディングを楽しむどころではなく山伏峠で下界に退散。 単調だろうと何だろうと暖かいのがエライと再認識。 勿論往路で軟弱な海沿いルートを主張した自分はやはりエライと(以下略)

Image: RIMG0136.JPG

伊豆スカイライン 亀石峠

熱海で昼食後は往路同様高速道路をひたすら走り無事に帰宅。
走行距離 350 km 程度なので 1 泊ツーリングとしては短い距離だが、 やはりこの時期はバイクで走るものじゃないと改めて実感した次第(軟弱もの)。 次の遠出は 4 月過ぎて暖かくなってからで良いな。

2011/01/21

MacBook Air に vtun 導入

某所で vtun を利用した vpn サーバを構築しているので、 MacBook Air に vtun クライアントを導入して vpn 接続出来る様にする。 vtun ver.3 は MacPort からも導入できるのだが、 諸処の事情により接続先のサーバが vtun ver.2 で運用されているので 今回は MacPort ではなく手作業にてインストールする事にする。

vtun に必要な圧縮関係の lzo ライブラリは MacPort でも導入できるのだが、 依存関係が多く古い perl までインストール要求するので 今回はこちらも手作業にて導入する。 vtun が依存しているのは lzo の 1.0 系なので、 LZO のオフィシャルサイト から lzo 1.0 系の最新版である lzo-1.8.tar.gz をダウンロードして展開し、 MacPort の流儀に合わせて --prefix=/opt/local を指定、 共有ライブラリを有効にするために --enable-shared を指定して configure を実行し make する。

$ ./configure --prefix=/opt/local --enable-shared
$ make
$ sudo make install clean
    

次に vtun ver.2 のソースを Sourceforge からダウンローし展開する。
vtun ver.2 のソースはそのままでは Mac 上ではコンパイルできないので 以下のパッチを適用する。

diff -cr vtun.orig/auth.c vtun/auth.c
*** vtun.orig/auth.c	2002-12-17 06:40:44.000000000 +0900
--- vtun/auth.c	2011-01-20 18:22:49.000000000 +0900
***************
*** 66,73 ****
  #include <openssl/blowfish.h>
  #include <openssl/rand.h>
  #else /* YAY - We're MAC OS */
! #include <sys/md5.h>
! #include <crypto/blowfish.h>
  #endif  /* __APPLE_CC__ */
  
  void gen_chal(char *buf)
--- 66,73 ----
  #include <openssl/blowfish.h>
  #include <openssl/rand.h>
  #else /* YAY - We're MAC OS */
! #include <openssl/md5.h>
! #include <openssl/blowfish.h>
  #endif  /* __APPLE_CC__ */
  
  void gen_chal(char *buf)
diff -cr vtun.orig/lfd_encrypt.c vtun/lfd_encrypt.c
*** vtun.orig/lfd_encrypt.c	2002-12-17 06:40:46.000000000 +0900
--- vtun/lfd_encrypt.c	2011-01-20 18:23:21.000000000 +0900
***************
*** 53,60 ****
  #include <openssl/md5.h>
  #include <openssl/blowfish.h>
  #else /* YAY - We're MAC OS */
! #include <sys/md5.h>
! #include <crypto/blowfish.h>
  #endif  /* __APPLE_CC__ */
  
  #define ENC_BUF_SIZE VTUN_FRAME_SIZE + 16 
--- 53,60 ----
  #include <openssl/md5.h>
  #include <openssl/blowfish.h>
  #else /* YAY - We're MAC OS */
! #include <openssl/md5.h>
! #include <openssl/blowfish.h>
  #endif  /* __APPLE_CC__ */
  
  #define ENC_BUF_SIZE VTUN_FRAME_SIZE + 16 
  	
パッチ適用後、これも --prefix=/opt/local を指定、 導入した lzo 関係のパスを指定するために --with-lzo-headers--with-lzo-lib をそれぞれ指定して configure を実行し make する。

$ ./configure --prefix=/opt/local --with-lzo-include=/opt/local/include --with-lzo-lib=/opt/local/lib
$ make
$ sudo make install clean
    

これで vtun はインストールできたが、 Mac OS X は標準では vtun が利用するトンネルデバイス /dev/tunX が存在しないので Sourceforge から Mac OS X 用の TUN/TAP ドライバをダウンロードしてインストールする。
インストール後にシステムを再起動するか /Library/Extensions/tun.kext をロードする事で /dev/tunX が生成されるので、 /opt/local/sbin/vtund を実行して vpn 接続できるか確認する。

$ sudo kextload /Library/Extensions/tun.kext
$ sudo /opt/local/sbin/vtund -f /opt/local/etc/vtund.conf ホスト サーバアドレス
$ ifconfig tunX
tunX: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet XXX.XXX.XXX.XXX --> YYY.YYY.YYY.YYY netmask 0xff000000 
    open (pid PPP)
    

vpn 接続ができればこの様なスクリプトを作成して root 権限で実行すると vpn 接続の開始・終了が出来る様になる。

  1#!/bin/sh
  2base="/opt/local"
  3
  4vtund="${base}/sbin/vtund"
  5conf="${base}/etc/vtund.conf"
  6opt="ホスト サーバアドレス
  7
  8start()
  9{
 10
 11    test -x ${vtund} -a -f ${conf} && ${vtund} -f ${conf} ${opt}
 12
 13}
 14
 15stop()
 16{
 17
 18    ps ax | sed -n '/[v]tund/s/ *\([0-9]*\) .*/\1/p' | xargs kill
 19
 20}
 21
 22case $1 in
 23    start )
 24        start;;
 25    stop )
 26        stop;;
 27    restart )
 28        stop && start;;
 29    * )
 30        echo "Usage: ${0##*/} [start][stop][restart]" 1>&2
 31        exit 255;;
 32esac
    

2011/01/20

Esperance DV のメモリディスクで firefox の起動を高速化

Esperance DV を利用して Mac 上にメモリディスクを作成している。
最初は firefox のキャッシュをメモリディスク上に格納していたのだが、 プロファイル情報を全てメモリディスクに格納したら起動が非常に速くなった。
firefox のキャッシュデータとプロファイルデータを メモリディスク上に格納するために、 元のディレクトリをメモリディスク上に移動してから、 本来のディレクトリにシンボリックリンクしている。

$ mkdir /Volumes/RamDisk/Application\ Support
$ mv $HOME/Library/Application\ Support/Firefox /Volumes/RamDisk/Application\ Support/.
$ ln -s /Volumes/RamDisk/Application\ Support/Firefox $HOME/Application\ Support
$ mkdir /Volumes/RamDisk/Cache
$ mv $HOME/Library/Cache/Firefox /Volumes/RamDisk/Cache/.
$ ln -s /Volumes/RamDisc/Cache/Firefox $HOME/Library/Cache
    

ただし firefox は多くのプラグインや GreaseMonkey スクリプト等で カスタマイズしてあるので、 何か問題があった場合にメモリディスク上のプロファイルデータが 全て消えてしまうと環境の再構築が非常に面倒になる。 そこで rsync (1) を実行するスクリプトを cron に登録して、 自動的にメモリディスク上のプロファイルデータを 通常のディスクに同期コピーする事で メモリディスク上のプロファイルデータが消えてしまっても 最悪でも1日前までの状態には戻れる様にして運用している。
TimeMachine でバックアップは取得しているのだが、 TimeMachine のシンボリックリンクの扱いが不明なので 安全策として独自に同期コピーを実施している。

  1#!/bin/sh
  2
  3src="${HOME}/Library/Application Support/Firefox/"
  4dst="同期データのバックアップディレクトリ"
  5
  6/usr/bin/rsync -a --delete "${src}" ${dst}"
    

ちなみに Esperance DV を勝手に日本語化してみたのだが、 作者に連絡が撮れないのでひっそりと 公開
インストールされた EsperanceDV.prefPane の中の Resources ディレクトリ (標準だと $HOME/Library/PreferencePanes/EsperanceDV.prefPane/Contents/Resources)に 展開した Japanese.lproj をコピーすると、 「システム環境設定」の 「Esperance DV」の設定画面が日本語化される。

この日本語化は私が勝手に日本語化しただけであり、 オリジナルの作者に許諾を取っていませんので、 日本語化部分に関してはオリジナルの作者に絶対に問い合わせないで下さい。

2011/01/17

シェルスクリプトで疑似乱数を取得する

gnu bash には ${RANDOM} というシェル変数が用意されていて、 アクセスするたびに疑似乱数(風)の値が取得できる様だ。 しかし posix 準拠の機能ではなく bash 独自の機能なので拡張性がない。 そこで汎用的な疑似乱数取得の方法として awk (1) を利用した方法を使ってみる。

awk (1) には rand() という関数が組込まれているので 乱数生成ができる。 その際に利用される種(seed)は srand() という関数で初期化できるので、 これらを利用する事でそこそこの精度の疑似乱数は取得できる。
たとえば 0 〜 m までの疑似乱数は 取得した値から m の剰余を取ることで取得できる。
ただし awk (1) の rand() は仕様として 0 〜 1 までの桁数不定の少数を返すので、 乱数として利用する場合には整数に変換する必要がでてくる。
整数にするために 10n を乗すればよいのだが、 小数点以下の桁数が不定のために小さすぎる n を乗すると 全ての桁が整数化されずに乱数の精度が低くなってしまい、 逆に大きすぎる n を乗すると値が xxx000 の様になってしまい 剰余を取得しても無意味になってしまう。

そこで awk (1) により疑似乱数を取得する場合は rand() で取得した値の前 2 文字 ("0.") を文字列として除外した値から m の剰余とする事で 0 〜 m までの乱数が取得できる。

  1#!/bin/sh
  2
  3awk 'BEGIN{
  4    srand();
  5    print substr(rand(), 3) % '${1:-1}'
  6}'
    

データの型が存在しない(文字列であり数字である) awk (1) ならではの裏技とも言えるだろう。

2011/01/14

Mobee The Magic Charger

職場の iMac 27″ モデルでは Apple 社の Magic Mouse を利用している。
Magic Mouse は標準状態ではそれほど素晴らしい機能を持ってないが、 サードパーティ製の機能拡張ソフトウェアと併用すると 非常に素晴らしい性能を発揮してくれるマウスであり、 慣れると他のマウスを利用するのが苦痛になる程便利だ。
そんな Magic Mouse なのだが唯一の欠点は電池の持ちが悪い事で、 普通に利用していると一ヶ月保つかどうかという程度である。
しょうがないので eneloop を使っていたのだが、 Mobee The Magic Charger を見つけたので早速導入してみた。

Image: RIMG0093.JPG

無接触充電中

この Mobee The Magic Charger は Magic Mouse 用の専用設計で、 裏蓋と一体になった専用の充電池を Magic Mouse にセットして 専用の充電台の上に載せておくだけで充電ができるという優れもの。
充電台は本体の USB から給電されるので電源も必要なく、 ただ載せておくだけで無接点で充電できるので非常に便利だ。
専用の充電池は電池よりも 10g 程軽量化されているそうなので、 Magic Mouse を持った感じも軽くなり気持ち使いやすくなった気がする。
職場の iMac は 24 時間稼働しているので、 帰宅時に充電台の上に載せておけば普段から充電できて良い感じ。

今の充電台方式だと使っていない時に「意識して充電台に置く」必要があるので、 次はマウスパッドとインテグレートされた充電台が出来ると嬉しい。
そうすれば普段使っている間も充電されているので、 本当に「充電」に意識を向ける必要がなくなって便利な事この上ないと思うのだが。

2011/01/12

docomo N-05B + MacBook Air でデータ通信

昨年末に携帯電話が故障してしまったので機種変更をした。
最新モデルではないのだが随分と新しいモデルに変更したのだが、 携帯電話に予めインストールされているアプリケイションが楽しそうなので、 初めてパケット通信の定額制割引パックに加入してみた。 色々と調べてみると携帯電話をコンピュータに接続してデータ通信を行っても パケット通信の定額制割引の対象となる事が判明したので、 MacBook Air のモバイル通信環境を構築してみたのだが、 なかなか一筋縄ではいかなかった…はぁ

まずは docomo の Web サイトの作りが最悪で、 必要な情報に素直にたどり着けない。
情報は一カ所に集約されておらず無意味に分散されているので 情報を見つける事が非常に困難で網羅的に情報を収集できない。 携帯電話とコンピュータを接続してデータ通信を行うために、 どの様なパケット通信の割引システムに加入すれば良いのか、 どの様な接続方式で接続すれば良いのか、 どの様なプロバイダを選択すれば良いのかといった情報を 探し出すだけで一苦労であり、 情報にたどり着いても今度は定義が不明確な 独自用語の羅列で何を言っているのか判らない。

結局「パケ・ホーダイ ダブル」に加入して「128K通信」で 対応プロバイダ「mopera U」に接続すると 受信最大 128kbps/送信最大 64kbps という石器時代の様な速度ではあるが パケット定額制割引の対象額の範囲内で通信可能だという事が判明した。
「パケ・ホーダイ ダブル」や「mopera U」の申し込みはオンラインで可能なので、 早速申し込んでみるとコレは簡単に申し込みができた。

次に MacBook Air からの接続なのだが、これも一筋縄ではいかなかった。
docomo の Web サイトによると、 手持ちの「FOMA 充電機能付 USB 接続ケーブル 02」を 利用した接続は対応していると明記してある。 そこで mopera U の Web サイトの説明通り「128K通信」を行うための 「ドコモ コネクションマネージャ for Mac」をインストールするが、 「ドコモ コネクションマネージャ for Mac」は 接続した携帯電話を全く認識していない。 調べてみると「ドコモ コネクションマネージャ for Mac」が対応しているのは ごくごく限られた携帯電話のみであり今回の機種には対応していなかった。
「FOMA 充電機能付 USB 接続ケーブル 02」を利用した接続に対応しているのは、 どうやら Microsoft Windows 系の OS のみの様である (どこにも明記されていないのであくまでも想像ではあるが)。

しょうがないので BootCamp からWindows Xp を起動して 「ドコモ コネクションマネージャ」をインストール、 「FOMA 充電機能付 USB 接続ケーブル 02」を利用して携帯電話を接続すると ちゃんと携帯電話を認識して接続までできたので、 APN 情報や CID 番号などの情報を取得した。

MacBook Air と携帯端末との接続は 予定していた「ドコモ コネクションマネージャ for Mac」が使えないので、 REUDO 社が販売している「FOMA モデムドライバー」をダウンロード購入して APN 情報や CID 番号などを手動で設定する事で何とか接続できた。

ちなみに MacBook Air に REUDO 製の FOMA モデムドライバーを利用して接続した docomo N-05B で mopera U に 128K通信するための設定。

システム環境設定」の「ネットワーク」から 「FOMA N05B」を選択して以下の設定を行う。

構成: デフォルト
電話番号: 空欄 利用されないので空欄で可
アカウント名: 任意の文字列 利用されないのだが入力のみは必須
パスワード: 任意の文字列 利用されないのだが入力のみは必須

次に「詳細...」ボタンをクリックして表示される「モデム」タブに 以下の項目を設定する。

製造元: REUDO
機種: FOMA GPRS (GSM/3G) for IP
APN: mpr.ex-pkt.net
CID: 4

APN や CID は携帯電話によっては異なる可能性があり、 間違えるとパケット定額制割引の対象とはならずに 高額なパケット代の請求となる危険性があるので注意しなければならない。
そもそもこの設定で「パケホーダイ ダブル」の適用対象となる 「128K通信」となっているのか不明なのだ。

2011/01/06

htaccess で特定のファイルのみパスワードを要求しない

Web コンテンツを保護するために .htaccess ファイルを用いて Basic 認証などを実施する場合は多い。
通常 .htaccess はディレクトリ単位で有効になってしまうのだが、 あるディレクトリのアクセスを Basic 認証でアクセス制御したいが 特定のファイルについては認証を要求しない設定を行いたい場合は Files ディレクティブと Satisfy ディレクティブで実現できる。

AuthType        Basic
AuthUserFile    認証用ファイル
AuthName        "Enter password"
Require         valid-user
<Files "認証要求しないファイル">
    Satisfy     Any
    Allow       from all
</Files>
	

Satisfy ディレクティブは Allow ディレクティブと Require ディレクティブがどちらも使われている場合の アクセスポリシーを制御する。
Any が指定された場合は AllowRequire のどちらかの条件を満たせばアクセスが許可されるので、 Files ディレクティブで指定したファイルに対しては Allow 指定が有効になり認証なしでアクセスが許可される。

逆にある特定のファイルだけの Basic 認証によるアクセス制御は Files ディレクティブのみで可能である。

AuthType        Basic
AuthUserFile    認証用ファイル
AuthName        "Enter password"
<Files "認証要求するファイル">
    Require     valid-user
</Files>
	

どちらの場合も Files ディレクティブは以下の様に ~ を使う事でファイル名を正規表現で記述できる。

<Files ~ "\.(gif|jpe?g|png)$">
	:
</Files>
	
apache では PCRE - Perl Compatible Regular Expressions を 利用しているので複雑な正規表現の記述ができる様だ。

2010/12/28

戦争を恐れているからこそ戦争を防ぎたい

戦争はとても恐ろしい事だと思うし、だからこそ防ぎたいと思う。
直接自分では経験していないし経験したいとは思わないが、 多少の想像力と常識的な判断力を働かせた上でそう考えている。

そもそも戦争は人間の行動の中でも最も恥ずべき行為の一つだと思っている。
ただ単に自分の主張なりイデオロギーなりを押し通すためだけに、 他人のみならず自分の身内の命まで粗末に扱うという行為は、 本能だけで生きている微生物と同じレベルかそれ以下の行為じゃないだろうか。

戦争はどんなに言い繕っても結局は人間同士の殺し相に過ぎない。 相手をより多く殺戮する事で示す主義主張には何の価値も感じないし認めたくない。

なぜナポレオンは偉人として祭り上げられ、 ヒトラーは殺人者として糾弾されるのか? どちらも殺戮、簒奪の限りをつくし、 罪もない市民を大勢殺戮したのではないか? 広島、長崎に原子爆弾を投下し罪なき一般市民を大量に殺戮したアメリカ軍は、 果たしてユダヤ人を虐殺したナチスドイツと何が変わるのだろうか? 結果として残っているのは大量殺戮をした結果の夥しい悲劇だけじゃないのか?
彼らは全て自分達が信じている(もしくは信じたがっている) 矮小で独善的かつ排他的な正義という幻想だけを見続け、 結果として殺戮を繰り返してきただけではないのか?
それなのに一方だけが残虐な犯罪者として糾弾されている事自体が 戦争の持つ本質的な矛盾だと思う。


戦争によって殺されるという一番馬鹿らしくて無意味な死に方はお断りだし、 人を殺した薄汚れた手で愛する自分の子供を抱きしめたくはないので 人を殺したりしたくない。 自分の子供が戦争によって殺されるのは勿論お断りだし、 自分の子供が誰かを殺す事を想像するのも嫌だ。

世界平和とかじゃない、個人的かつ、エゴイスティックな理由で ラディカルに戦争反対と主張する。

2010/12/25

クリスマスケーキ

今年のクリスマスケーキは、 Mont St. Clair のオープニングパティシエだった Yuji Ajiki 氏のお店 Yuji Ajiki Sweets Garden にしてみた。

Image: IMG_3319.JPG

Mont St. Clair 同様に上品な非常に美味しいケーキです。
しつこ過ぎず弱すぎないチョコレート感が絶妙で大満足。


Copyright © 2008-2020 Mitzyuki IMAIZUMI. All rights reserved.