オープンソースなベクターアイコン OpenIcons

コンピューティング

暖かいだけでもう人生の7割くらいは幸せなのだ、と春の到来を噛みしめている北国生まれプログラマ Mariyudu です。いやほんと、これで花粉さえなけりゃ…

さてさて、今日もオープンソースリポジトリ系の RSS を巡回していて、なかなか充実したベクターアイコンセットと出会いました。Robert "Unlogic" Olofsson さんという方による OpenIcons です。2010年11月に58個のセットからスタートして版を重ね、先日リリースされた rev.70 では、371個にまで増えています。丸みのある柔らかいシェイプとインファントな色使いが特徴。SVG 形式のベクターファイルと、16x16 から 128x128 ピクセルの9種類のサイズの PNG 画像が同梱されています。尚、ライセンスは LGPL ver.3 となっています。

ベクター形式は、組み合わせたりカスタマイズしたりと、クリエイターさんにはハンドリングしやすいのが魅力的ですね。ダウンロードはこちらから。という訳で、日本語ブログ界隈ではあまり紹介されてないっぽいので、おすそ分けでした。

20種類の楽器で聴くバッハのプレリュード(無伴奏チェロ組曲第1番 BWV1007)

音楽

子供の頃、デパ地下のキャンディー売り場で色々な種類のキャンディーが山盛りになっているのを見ては「1個ずつ全部買って並べてみたい!!」てな興奮に駆られたことってないですか? ああ、無いですか… まぁいいんですけど、私って「その類」の人間らしいです。つまり、同一カテゴリー内で様々なバリエーションが用意されていると訳もなくウキウキしてしまい、それらの入手・記録・分類といった行動への欲求を抑えがたくなるみたいです。

何の話かってえと、先だってライフワークにしているギター演奏の YouTube 公開で、バッハのプレリュード(無伴奏チェロ組曲第1番 BWV1007)を手がけたんですが、その際にこの曲がとても多種多彩な楽器で演奏されていることに気づきました。そこで頭をもたげてきたんですねー、前述の「並べてみたいゴコロ」がw そんな訳で、YouTube に登録されている同曲から Mariyudu がチョイスした「バッハのプレリュード・アラカルト」をどうぞ。

まずは原曲のチェロ演奏を。でも只のチェロじゃ面白くないのでアルミで出来たチェロという変わり種を(↓)。

お次は同じ擦弦楽器でコントラバス、ヴィオラ、バイオリン、と音域を上げながらどうぞ(↓)。


弦の音に飽きちゃいました? じゃ、管楽器に変えてみますか。普段お馴染みな楽器でサックスとフルートでの演奏をどうぞ(↓)。

管楽器といえば日本人なら一度は演奏の覚えがある「たて笛」ことリコーダー。この楽器、実はルネサンス時代から室内楽で頻繁に使われた由緒ある楽器です。その高雅な調べをどうぞ(↓)。

ちょっと奥ゆかしげな雰囲気になったところで、同じく古楽の時代では主役級で活躍した、クラヴィコードという鍵盤楽器、リュートというギターのご先祖様みたいな撥弦楽器での演奏をどうぞ(↓)。

ギターの話が出たついで(?)なので、クラシックギターでの演奏を。ありふれた楽器といえばそうですので、ここは演奏者に重点を置いて選んでみましたw いやー楚々とした美人ギタリストさんですねー(↓)。

某有名大の某サークルのせいか、ギターといばマンドリン、てな連想が働くの日本だけ? ま、とにかくマンドリンおよびマンドチェロ(低音部を受け持つマンドリン)での演奏を。前者はクラシックで使われる水滴型ではなく、カントリー用のフラットマンドリンですね(↓)。

鍵盤楽器がお座なりだったようなので、パイプオルガンとピアノ、アコーディオンでの演奏を。ピアノ版はかなり奔放なアレンジが施してあって、ずっと同じ曲を聴いてきた耳には新鮮ですね(↓)。


さて、この辺で少し変わった楽器にシフトしてみます。パンフルートという楽器をご存知でしょうか。昔、ザンフィルという奏者のブレイクで少し知名度が上がりましたがギリシャ神話にも登場する古い歴史を持つ楽器らしいです(↓)。

次に中阮(チョンルアン)という中国の伝統楽器を。あの女子十二楽坊でも大きくフィーチャーされてはいませんでしたが、確か使われていたと思います(↓)。

そしてこれ。忘れちゃいけませんよね、小さな万能楽器、ウクレレを。音域の狭さによる不自由を全然感じさせない巧みなアレンジと演奏です(↓)。

ずーっとアコースティック楽器ばっかりだったので、最後はコンテンポラリーにEベース、Eギターとエレクトリックで締めたいと思います。ロケンロール!(↓)。

えーっと、番外オマケで私が鉄弦ギターで演奏したやつを(オズオズ)…

月並みな演奏ですけど、そんなにわ、悪くはないでしょ? という訳で楽しんで頂けましたでしょうか? ではまたっ (逃げるように去る)

テンポラリ稼働な EC2 インスタンスから Route53 をダイナミック DNS っぽく使う

コンピューティング

最近はコード書くより AWS の色んな機能を弄ってる方が楽しかったりするので、プログラマとしてのアイデンティティが揺らぎはじめている Mariyudu@どうせ野良だし楽しければいーんじゃねーの、です。はい、矜持もプライドも野末のどっかに忘れてきましたw

そんな訳で今、某サービスを構成するサーバを AWS EC2 上で開発中です。開発用のインスタンスだとキホン、作業の時だけ起動して料金を節約するってのがパターンだと思いますが、そんな時ちょっと不便なのが起動の度に変わってしまう IP やホスト名。そこで、このサービスのドメインもやはり AWS の Route53 (以下、R53)で DNS 運営していることもあり、インスタンス起動時に当該ホストの A レコードを書き換える仕組みをちょこちょこっと作ってみました。R53 de Dynamic DNS って感じですな。以下、手順です。

  1. R53 の認証や API 実行を行う Perl スクリプト dnscurl.pl をここからダウンロードして、適当なディレクトリ(例 : ~/bin/r53/)にインストールしてセットアップ(ここが参考になります)。
  2. インスタンス起動時に割り当てられた IP を調べて、当該 FQDN の A レコードの書き換え処理を行うシェルスクリプト(下記)を、同ディレクトリに配置(例 : ~/bin/r53/update-r53.sh)。

    #!/bin/sh

cd ~/bin/r53/

# 各種パラメータ(アカウント・ゾーンID・当該インスタンスのFQDN・TTL)
KEYNAME="foobar@mariyudu.jp"
ZONEID=XXXXXXXXXXXXX
FQDN=develop001.mariyudu.jp
TTL=300

# 現在、DNS にセットされてる当該 FQDN の IP
OLDIP=`/usr/bin/dig $FQDN +short`

# インスタンス起動時に割り当てられた IP
NEWIP=`/usr/bin/curl -s "http://169.254.169.254/2008-02-01/meta-data/public-ipv4"`

# 上記パラメタを使って R53 API へリクエストする XML を生成
TMPFILE="/tmp/update_r53.$$.xml"
cat << EOS > $TMPFILE
<?xml version="1.0" encoding="UTF-8"?>
<ChangeResourceRecordSetsRequest xmlns="https://route53.amazonaws.com/doc/2010-10-01/">
 <ChangeBatch>
  <Comment>Update A Record of $FQDN</Comment>
  <Changes>
   <Change>
    <Action>DELETE</Action>
     <ResourceRecordSet>
      <Name>$FQDN.</Name>
      <Type>A</Type>
      <TTL>$TTL</TTL>
      <ResourceRecords>
       <ResourceRecord>
        <Value>$OLDIP</Value>
       </ResourceRecord>
     </ResourceRecords>
    </ResourceRecordSet>
   </Change>
   <Change>
    <Action>CREATE</Action>
     <ResourceRecordSet>
      <Name>$FQDN.</Name>
      <Type>A</Type>
      <TTL>$TTL</TTL>
      <ResourceRecords>
       <ResourceRecord>
        <Value>$NEWIP</Value>
       </ResourceRecord>
     </ResourceRecords>
    </ResourceRecordSet>
   </Change>
  </Changes>
 </ChangeBatch>
</ChangeResourceRecordSetsRequest>
EOS

# dnscurl で R53 API を利用
/usr/bin/perl dnscurl.pl --keyname $KEYNAME -- -H "Content-Type: text/xml; charset=UTF-8" -X POST --upload-file $TMPFILE https://route53.amazonaws.com/2010-10-01/hostedzone/$ZONEID/rrset > /dev/null 2>&1

rm $TMPFILE


  3. 上記スクリプトを、インスタンス起動時に実行するようにする(下記のように @reboot ディレクティブを使って crontab 登録するのがお手軽)。

    @reboot /bin/sh ~/bin/r53/update-r53.sh


以上っす。「別に Elastic IP をアサインしておきゃいーんじゃね? 1日の2/3くらい使わなくても、それで発生する料金なんて月数百円くらいだし」という意見が圧倒的かと思いますがw、まあそれでもインスタンスが数十台くらいになったらちょっとした節約になるかと。

それから、上記 update-r53.sh では A レコードの書き換えの際に、R53 API に編集という手段が用意されていないっぽいので、当該 A レコードを削除してから再度追加するという手順になっていますが、その削除がクセ者。FQDN だけでなく TTL まで現状と一致したものを指定してやらないとエラーになっちゃいます。なので、例えば TTL をスクリプトで定義されている300秒から後で手動で変更したりすると、この仕組みは上手く動かなくなってしまうのでご注意を。ちゃんと API 経由で A レコードを問合せした上で削除→追加してやれば良いんでしょうが、時間がなかったので。

Evernote に背を向けて PukiWiki を使い続ける7つの理由

コンピューティング

相変わらず寒い毎日ですな。出来るものなら寒い冬は冬眠してやりすごせる熊かヤマネになりたい、熱帯仕様プログラマ Mariyudu です。

ちょっと前ですが、ゆーすけべー氏の「Evernote が好きではない」で始まるブログ記事にハッとしました。私もあの熱狂的な Evernote 人気に刺激されて、とりあえず使ってはみたものの、もう十年来 Web メモとして利用してきた PukiWiki からの移行ができずにいるからです。

PukiWiki って?

多くの方がご存知だと思いますが、PukiWiki は PHP で書かれた日本発の Wiki クローンです。私はこれを自分の Web サイト(レン鯖)にセットアップして、プライベートな Web メモ帳として使い倒してます。プログラマという職業柄、よく使うパターンのコードスニペットや、各種ソフトウェアの設定や TIPS 等を蓄積してノウハウの拡充を図っている訳ですが、Wiki というものが無かった頃は単純にテキストファイルに書きこんで作業マシンのデスクトップに置いておくだけでした。それがある日、結城浩氏作の YukiWiki という Wiki クローンを試したところ、ベタのテキストよりは表現力もあるしネット経由でどこからでも読み書きができるしと、思いのほか使い勝手が良かったので、溜まっていたメモを Wiki ページに移行したという訳です。その1年後くらいに PukiWiki がリリースされたので(サーバの引越しなんかもきっかけだったと思いますが)、これに移行して ver.1.4.7 utf-8 版の今に至っています。正直、これが無いと仕事にならないくらい便利に使わせてもらってます。

PukiWiki を使い続ける7つの理由

さて時を重ねて Web2.0 やらクラウドの時代になり、Evernote という超強力なサービスが登場したのは前述のとおりですが、私もご多分にもれず試してみて「こりゃ凄い」と感動したクチなので、溜め込んだ Wiki 上のメモを移行しようかと思い立ち、実際に少しやってもみました。その結果、移行には時期尚早というか、いや別に移行する必要もないんじゃないのという気になっています。理由を整理してみるとこんな感じ。

中途半端に便利な GUI
当初、Web のページからぐいっとコピペしたらスタイル付きで張り付けできるのには驚きました。ただ、その後の調整が大変。例えば、表組みの背景色なんてどーやって直したらいいのか分かりません。どっかのファイルをごにょごにょすると HTML で編集可なんて裏技もあるそうですが、そこまで手間をかけられませんよねぇ… PukiWiki も文書のスタイル面では万能ではありませんが、どこまでが可能なのかがシンプルかつ明確なので、自分の中で割り切りがつけやすいというか。
プラットフォーム間のバージョン違い
Evernote アプリの、Mac と Windows でのバージョン違いにも泣かされました。会社で作ったノートが自宅の Mac だとうまく編集できない箇所があったりとか。
ダウンが怖い
仕事にも使うツールなので、障害やメンテナンスによるサービスの停止がいっちゃん困ります。まぁ PukiWiki を置いてるレンタルサーバもダウンが無い訳じゃありませんが、高可用性を追求したいならミラーサイトを増設するといった冗長性確保も可能だし、作業もさほど難しくはありません。
アプリ任せにするしかないマルチプラットフォーム対応
Evernote は iPhone 等のスマホでも利用できますが、この辺は言ってしまえばアプリが提供されてるかどうかになっちゃいます。PukiWiki ならとりあえず Web が使えれば何とか使うことができますね。ガラケーでも一応は OK。
動作が重い…
Evernote はリッチな機能を持っているぶん、アプリの動作環境にそれなりのパワーを要求します。例えば今、職場で支給されている3年前の非力なノート(Core2Duo 1.06GHz/2GB)とかだと、うーむ一寸厳しい…
有料
まあ私の利用ペースだと無料版のアップロード容量制限に達することはほぼ無いかと思いますが、やはりちょっと気に懸かってしまう部分ではあります。
カスタマイズ等の小技
この最後のファクターが自分にとっては一番大きいかもしれません。PukiWiki は比較的見通しの良い PHP アプリケーションなので、何か不満があったり機能を付け加えたければ私でもカスタマイズすることはそれ程難しくありません。また、改造とまで行かなくとも、元々プラグインで拡張可能な様になっているので、それだけでもかなりの事が実現できます。一方 Evernote は API も用意されているようですが、そのポテンシャルは未知数ですし、学習コストの面もあり、普段使い慣れている PHP プログラムにちょこちょこっと手を入れられるお手軽さには及ばないかと。

カスタマイズ例

とまぁ、色々もっともらしく理由を列挙してみましたが、最後の項目にあるように、要はどれだけの自由度が担保されているかということに尽きるのではないかと。これは勿論、ユーザ万人にあてはまる訳ではなく、プログラマを生業としている自分にとっての極私的な基準であることを付け加えておきます。さて、不便な所があったら自分でカスタマイズしちゃえばいーじゃん、てのは述べたとおりですが、少し具体例も書いておきます。

スマホ以前の、外出先でのネットといったらケータイの i-mode しかなかった頃ですが、PukiWiki は i-mode でのアクセスは勿論できるのですが、表示させたいページが長いものだったりすると表示に時間がかかったりスクロールが大変だったりする訳です。また、外出先で見たい情報も本や CD の購入リストとか、わりかし決まったものばかリだったので、特定の URL にアクセスするとそれに応じた箇所(例:欲しい本の一覧)だけ抜き出してメールで送信する、という機能をちょこちょこっと作って重宝していた時期がありました。例えば、ケータイで

http://mariyudu.no.pukiwiki-site.jp/mailme.php?page=Wish+List&block=Books_Buy_List

という URL にアクセスすると、「Wish List」というページの、//mail2ktai_[Books_Buy_List]_begin 及び //mail2ktai_[Books_Buy_List]_end というコメントに挟まれている部分がメールで送り返されてくる、といった具合です。スマホを使うようになってからは不要な機能となったのでコード等は割愛しますが、プログラミングの覚えがある方なら大体の処理フローが目に浮かぶでしょう。たしか30分以内程度で実現できたように記憶しています。

それから、メモ帳のようなかたちで PukiWiki を使っていると、ページにどんどん追記がされていくので所謂「鰻の寝床」状態な長〜いページが増えてしまう傾向があります。これで不便なのはページの先頭や末尾に移動する際のスクロール量がハンパじゃないこと。特にページ編集とプレビューを繰り返してると腱鞘炎になりそうなくらいマウスホイールぐりぐりを繰り返すハメになっちゃう事に辟易して、ページ左端の上下中央部にスクロールしても位置が固定な、ページ最上部・最下部・トップページへのリンクボタンを追加しました(↓)。

これもボタンの画像を作って、スキンファイル(skin/pukiwiki.skin.php)の head タグ内にちょこちょこっと style や script を追記するだけで簡単にできちゃいます。
　
とまあ、こんな具合にちょっとしたプラスアルファが短時間で実現できるのが PukiWiki のようなシンプルなシステムの醍醐味と言えます。
　

とはいいつつ

でも、実は PukiWiki でのメモ帳にも実は色々課題はあるんですよね。例えば Perl で Twitter API を使ったコードのサンプルを「Perl メモ」というページに書いたとします。けどこのトピックは同時に Twitter の技術トピックでもある訳で、こんなケースでは Evernote のタグをつけて整理する、という機能が活きてきます。そんな訳でこの記事、Evernote 不要論っぽい煽りタイトルを付けた割には、実はまだまだ Evernote の今後に期待している俺ガイル的なオチになっちゃいました。いや、アルファブロガーさんがよく書く「×××の10の理由」みたいなタイトルを一度付けてみたかっただけとゆーか。あ、石投げないで…

十二支 de ロケンロール

音楽

あけましておめでとうございます。寝正月で膨らんだ腹がようやく5mmくらいは復旧した感じがする、野良プログラマ Mariyudu です。

ここ数ヶ月、プライベート時間はギター演奏なぞをこんな処に晒すことに腐心していたせいで、bLog を書くのから遠ざかってました。いくら歳を重ねても時間配分が下手ですな… 今年もボチボチやっていこうと思いますが、どーも「bLog 書くにゃ何か作らないと」みたいな脅迫観念が出てきたような気がしなくもないので、今年一発目は肩の力を抜いて音楽レコメンドめいたものを。

正月休みにいつものように RSS リーダーに溜まった新着ブログ記事を読んでたら、今年の干支の辰(ドラゴン)をジャケットにあしらったアルバムを集めて紹介されている方がいました。「じゃ、十二支全部集まるかな?」と単純な思いつきで自分が聴いてきたロック・アルバムからチョイスしてみました。お題もアホっぽく「十二支 de ロケンロール」、いえー。

子：Humble Pie - Street Rats
スモール・フェイセズの血筋をひく、熱くて一途なハードロックバンド。この'75年のラストアルバムは評価は低いですが、ビートルズ好きな自分としてはカバーが3曲も入っていて無視できないです。ジャケットは映画「ウィラード」を連想させて一寸気味悪いですがw ちゅー
丑：Pink Floyd - Atom Heart Mother
重厚長大な'70年代のプログレシーンを象徴するピンクフロイドの代表作ですね。洋楽にカブれはじめた厨房の頃は訳もわらかずただ有難がって聴いていましたが、今では「If」のようなコンパクトなナンバーが好きです。うっしっし。
寅：Tiger in the Rain - Michael Franks
'70年代のマイケル・フランクスは最高ですねー。このアルバムは「スリーピング・ジプシー」のようなキラーチューンは持っていないのですが、そのぶんスッと背景に溶け込むような透明感があります。上善、水の如し。そういば、AOR と呼ばれていたこの手の音楽は現在、iTunesStore あたりじゃジャズに分類されてるんですな。がるる。
卯：Jump! - Van Dyke Parks
アメリカ音楽の光も影も知り尽くしているヴァン・ダイク・パークスが'83年に紡いだ、ほっこり明るいカントリー・ミュージカルレビュー。とある童話のシリーズをモチーフに作られたとか。お子さんをお持ちなら一緒に聴いてみて。ぴょんっ
辰：Spitfire - Jefferson Starship
飛行機から宇宙船に進化したジェファーソン中期の傑作ポップアルバム。といいつつ、このアルバム聴いたのは割りと最近なんですよね。サイケだった飛行機の頃はともかく、この長寿バンドのアイデンティティが何処にあるのか、私ゃよくわからんのですよ。まぁ、そういった面倒臭い文脈から離れて聴いたほうが正解かも。ジャケも中華料理屋に飾ってありそうな、なんちゃって東洋風味なのがいとをかしw
巳：Killer - Alice Cooper
ヘヴィ・メタルに分類されるロックはあまり聴かないんですが、この人はイイですねぇ。出自としてはグラム方面なのですが、音楽にさほど物語性を感じられず、むしろ AC/DC みたいな下半身直結っぽい振り切れ具合というか、ある種の悟りというかw そんなところが好きです。
午： Stampede - Doobie Brothers
主にエッジの立ったブリティッシュロック方面から洋楽に入り込んでいった私なので、ドゥービーに代表される「ベタ」なアメリカンロックを聴き始めたのは結構あとになってからでした。それが今じゃ、この手の音が一番キモチいいって、歳とったんだろうなー。 …ひひーんっ
未：RAM - Paul McCartney
'71年、ポールのソロ第二作です。確かに何処に的を絞ったらよいのかみたいな、才能を持て余しているふうな迷いが見て取れないこともないですが、だからといって当時酷評されたってのも大きな期待の裏返しでしょうね。けど私、このアルバムが一番好きかも。「アンクル・アルバート/ハルセイ提督」の出だしでの We're so sorry, Uncle Albert... を聴くと今でもゾクッときます。
申： Naked - Talking Heads
'80年代の最重要バンドのひとつ、トーキングヘッズのラストアルバム。デビュー当時の鋭い批評性が次第に鈍化していき、最後は陽気でファンキーな無国籍ポップになっちゃいました… てのは某ロキノン的解釈? w
酉：Atomic Roooster - Atomic Rooster
このバンド、非常に頻繁にメンバーチェンジや離合集散を繰り返した、ハードロック道場みたいな趣がありますが、やはり一番評価が高いのはこのデビューアルバムですかね。こんなふうな男臭いボーカルって、メタル系はともかくメインストリームではめっきり聴かなくなりましたねぇ。ジャケは鷲かコンドルみたいにも見えますが、まぁバンド名が「雄鶏」ってことなので…
戌：There's One in Every Crowd - Eric Clapton
クラプトンのソロ作の中じゃこのアルバムが一番好き、って人は私以外にも多い筈。ソロになってからの芳醇な米南部音楽への旅はこのアルバムがいちおうの到達点だったかもしれなせん。って偉そうにカマしてますが、若い頃はこの良さが分かんなかったよなー…
亥：Sad Pig Dance - Dave Evans
干支の最後、猪はずいぶん探しましたが結局見つけられなかったので豚で、と思ったらこれも結構少ないんですよねー。ピンクフロイドの「アニマルズ」あたりがすぐ思い浮かぶけど、豚がちっちゃくて殆んど「点」だもんなー… という訳で、必ずしもロックではないかもしれませんが、このデイヴ・エヴァンスというシンガー・ソングライターを。ギターがかなり達者な人で、このアルバムもアコギ・インスト・オンリーとなってます。


という訳で、疲れましたw 亥年のあたりで「止めときゃよかった」と思いましたが… さて、根がバカなのでこれに懲りず、今年も色々なものを色々なかたちでアウトプットしていきたいと思いますので、どーぞよろしく。

jQuery - $(function(){}); の落とし穴

コンピューティング jQuery

先日、いつものように Web ページで jQuery プログラムを書いててちょっとハマったのでメモ的に失敗談を開陳(恥)。

$(function(){}) は画像のロードを待たない?

きっかけは U/I 系の jQuery プラグイン jScrollPane が期待どおりに動作しないという現象でした。このプラグイン、固定サイズのブロック要素が overflow した際のスクロールバーをミニマルなデザインに差し替えてくれる優れものです。現象とは、そのブロック要素に画像が含まれている場合にスクロールバーが表示されない、というもの。しかも Chrome や Safari の WebKib 系ブラウザに限って。

調べて判ったことを纏めると以下のようになります。

  • 普段深く考えもせずおまじない的に書いてた $(function(){}) は、$(document).ready(function(){}) の短縮形であり、DOMContentLoaded という DOM 構築完了イベントへのハンドラ記述法である。
  • WebKit 系ブラウザでは DOMContentLoaded 発火の時点で画像のロードが完了しておらず(バグ?)、img タグに width や height 属性を明示しない限り画像のロードが完了するまで幅や高さ等が JavaScript で取得できない。
  • したがって画像を含むブロック内部の高さも算出することができず、画像抜きの高さとなってしまう。この理由により、jScrollPane が当該ブロックで overflow しないものと解釈してしまった。
  • これを回避するには DOMContentLoaded イベントではなく、画像のロードが全て完了した後で発火される window.onload を用いるといいみたい。

イベントは適材適所で使い分けましょうw ケースによっては window.onload を

ということで、万全を期すのであれば window.onload を常用すればいいのでしょうが、そうなると JavaScript 処理がとてももたついた動作になってしまう。なので、通常は $(function(){...}); で。今回のケースのように画像等の埋め込み要素をストリクトに操作したいような場合には window.onload を用いれば良い、という教訓というかバッドノウハウでした。この場合、JavaScript の記述的には

window.onload = function(){...};

でもいいのですが、これだと既存のイベントプロシジャをオーバーロードしてしまう危険性もあるので、イベントプロシジャを追加する書き方として以下のようにすれば良いみたいです(jQuery ってホントに良く出来てるなぁ)。

jQuery.event.add(window,"load",function(){...});

おまけ(デモ)

本件を再現するデモを作りました。

http://mariyudu.net/labo/jqueryEventDemo

このページには、画像を含んだブロック要素が左右二つあり、両方とも

height: 200px;
overflow: hidden;

とスタイル定義してあります。左側は $(document).ready() で、右側は window.onload 時に jScrollPane を適用するようにしてあります。これを Chrome か Safari で表示させると、左のブロックにはスクロールバーが適用されずに下半分くらいが隠れたままなのが分かりますね。

1981年、初春の仙山線・秋の米坂線

作ってみた コンピューティング

今日('11-10-2)の産経新聞に、環境省が選定した「残したい日本の音風景100」が先の震災でどのように変わってしまったのか、日本サウンドスケープ協会が調査に乗り出した、という記事が載っていました。私は「残したい日本の音風景100」も「日本サウンドスケープ協会」というのも寡聞にして知りませんで、なにやらワクワクしながらネットで検索してそれぞれのウェブサイトを訪ねてみたんですが、…うーん、何だかちょっとガッカリって感じでした。これだけブロードバンド回線が普及して多彩なメディアがストレス無く楽しめる時代になっているのに、どちらのサイトもテキスト主体の何やら古風な作りのままという印象だったからです。

という訳で(何がだw)、秋も深まってきますたな。少年時代から生録小僧だった老年プログラマ Mariyudu です。このブログ、時々昔カセット録音した音風景をデジタイズして公開しておりますが(↓)、

それを本人もすっかり忘れかけた頃の今日、先の新聞記事に刺激されてまた懲りずに音源をアップすることにしました。今回は山形で学生をしていた頃の'81年に録った鉄道音です。それぞれ短いですが、興味のある奇特な方はどうぞお楽しみ下さい。下のカセットの真ん中のプレイボタンをクリックするとその場で再生できますし、カセット下のトラック説明にあるリンクをクリックして MP3 ファイルのダウンロードもできます。


1. [http
//attic.mariyudu.net/sounds/hatena111002/01_senzan_line.mp3:title=Mar 9, Senzan Line] [3:26]:3月9日、仙山線の高瀬〜楯山間の車中の音。仙台1854発833便。この高瀬駅ってジブリアニメ「思ひ出ぽろぽろ」の舞台にもなったらしいですね。
2. [http
//attic.mariyudu.net/sounds/hatena111002/02_yonesaka_line.mp3:title=Oct 15, Yonesaka Line] [1:25]:10月15日、米坂線の米沢〜南米沢間にあるポイントでの通過音です。今からちょうど30年前ということになりますが、列車の音以外は虫の声くらいしか聞こえませんが今でもこんな感じなんでしょうか。尚、便は米沢1749発の147D、とメモにあります。

当時の生録小僧にとっては、SL の迫力ある音を録音することが夢というか、ティピカルなステータスシンボルだったのですが、生憎既に身近に SL は残っておらず、その代償行為として時々思い出したように列車(そういやこの頃はまだ「国鉄」だったのだなぁ)を録音してたような記憶が。なにせ日常にありふれている音なので、録っても大して面白くもなく、このテープも上記録音を含めてたった3つで終っています。飽きちゃったんでしょうね、きっと。四半世紀以上経った今聴くとそれなりに味わい深いので、もっと録っておけばよかったと思いますが。最近では「音鉄」というマニア道もあるようですが、その筋の人にも聴いてもらって録音の価値を尋ねてみたい気がします。ではまた。

※追記 : この頃はソニーの TC-D5M を愛用してました。両方ともそのデッキ + やはりソニーのワンポイントステレオマイクでの録音かと。