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 を見つけたので早速導入してみた。
この 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 が指定された場合は Allow か Require
のどちらかの条件を満たせばアクセスが許可されるので、
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
2010/12/24
Christmas time
We waited all through the year
for the day to appear
when we could be together in harmony
You know the time will come
peace on earth for everyone
and we can live forever in a world where we are free
let it shine for you and me
There's something about Christmas time
something about Christmas time
that makes you wish it was Christmas everyday
To see the joy in the children's eyes
the way that the old folks smile
says that Christmas will never go away
We're all as one tonight
makes no difference if you're black or white
'cause we can sing together in harmony
I know it's not too late
the world would be a better place
if we can keep the spirit more
than one day in the year
send a message loud and clear
It's the time of year when everyone's together
we'll celebrate here on Christmas day
when the ones you love are there
you can feel the magic in the air -
you know it's everywhere
something about Christmas time
something about Christmas time
something about christmas time
something about christmas time
that makes you wish it was Christmas every day
To see the joy in the children's eyes
the way that the old folks smile
tells that Christmas will never go away
Cristmas time
Merry Christmas!
2010/12/19
MocBook
Apple Mirrorさんに
お願いしていた名刺入れが届いた。
以前 Mac 関係の雑誌で拝見して是非とも欲しいと思い、
注文していたものがやっと届いたのだ。
こちらの名刺入れは一つ一つ手作りなので大量生産はできず、
届くのに多少時間はかかるのだが待ってるだけの価値は間違いなくある。
デスクトップ画像をオリジナルでお願いできるで、
普段愛用している MacBook の画面がそのまま名刺入れになる。
今回はデスクトップの画像をこっそりと愛娘の誕生日にしてしまった。
（実は「デスクトップの日付を変えますか？」と作者の方から連絡があり、
その時に思いついて娘の誕生日に日付変更して
デスクトップをキャプチャしなおしたのだ）。
キーボードもちゃんと英語キーボードの画像に変更して頂けたので、
本当に普段から愛用している白ポリカーボネートの
MacBook そのままの仕上がりである。
非常に素敵な仕上がりの MacBook 名刺入れプラス
愛娘の誕生日で愛着もひとしおだ。
暫くは周囲に自慢しまくりなのは確実だな。
最近 MacBook Air も新たに入手したので、 MacBook Air バージョンも欲しくて堪らない今日この頃…
2010/12/17
最近 Mac を愛用している理由
それは
ずばり美しいから
でも、それだけじゃない。
元々 FreeBSD をメインで使っていたので、
ターミナルを起動して実行する様々なコマンドが馴染み深い。
例えば netstat (8) や route (8) のオプションが
FreeBSD と同じなので使いやすいのだ。
ルーティング情報を調べる時に使用する netstat (8) コマンドは
$ netstat -rnf inetなのだが linux の場合は -f オプションが無いのでエラーになり、 微妙にストレスを感じてしまう。
同様に職場などの出先でスタティックルートを追加設定したい場合は
$ route add -net XXX.XXX.XXX.XXX/XX YYY.YYY.YYY.YYYなのだが linux の場合だとゲートウェイ指定の前に キーワード gw が必要なので、 入力したコマンドがエラーとなり、やはり微妙にストレスとなってしまう。
# route add -net XXX.XXX.XXX.XXX/XX YYY.YYY.YYY.YYY SIOCADDRT: No such device # route add -net XXX.XXX.XXX.XXX/XX gw YYY.YYY.YYY.YYY
これらのコマンドは頻繁に使用するので指先が覚えていて、 linux の環境で作業しているとエラーになるたびに 思考が瞬断されてしまう感じがして気になる。
普段は非常に美しく直感的で使いやすいインタフェイスを優雅に堪能できる事、
必要であれば unix 由来の非常に柔軟で強力なパワーを
自由自在に組み合わせて使いこなす事ができる事、
そして各種 unix コマンドのオプションが慣れ親しんだものである事、
これら全てが高次元で融合されている事が
僕が Mac OS X を愛用している理由である。
2010/12/15
DHCP
先日購入した MacBook Air を自宅のネットワークに接続しようとした所、 何故か DHCP での IP アドレス取得に失敗してしまう現象が発生した。 Windows Xp や FreeBSD がインストールされた PC では正しく取得できるが、 MacOS X ではどうやっても IP アドレスが取得できない。 無線 LAN 接続のアクセスポイント（TimeCapsule）の設定を変更したり、 アクセス制御を解除してみても全然 IP アドレスが取得できず DHCP サーバの設定を何度も確認しても症状はいっこうに改善されない。
そこでネットワーク障害はパケットキャプチャが基本だと思い立ち、
IP アドレスが取得できない MacBook Air で tcpdump (1) を実行すると、
クライアントからの DHCP DISCOVER に対して
サーバは DHCP OFFER を応答しているのだが、
パケットの Source IP Address が
127.0.0.1 となっている事を発見した。
なぜ DHCP OFFER パケットの Source IP Address が
127.0.0.1 だったのか、
結論から言うと /usr/local/etc/dhcp.conf ファイル中の
option domain-name に設定した FQDN が
/etc/hosts に 127.0.0.1 で登録されていたため、
DHCP サーバがパケットを送信する際に
domain-name を逆引きした結果として 127.0.0.1 を
Source IP Address に設定してしまった様だ。
/etc/hosts から該当する FQDN のエントリーを削除して、
DHCP サーバを再起動した所 IP アドレスが取得できた。
FQDN を 127.0.0.1 で /etc/hosts に登録する事は
Linux の一部のディストリビューションなどでは普通に行われている様だが、
メイルが送信できない、DHCP が機能しないなどの障害発生の原因になるので
是非とも辞めて欲しい。
それにしてもこの MacOS X の DHCP クライアントは Source IP Address が 127.0.0.1 の DHCP OFFER を無視しちゃうのね。
