2008/01/31 00:00:00
金沢3日目
早くも金沢最終日。
朝もおいしい朝食を食べ、お風呂にもまたまた入り、満喫して宿を後にしました。
やっぱり温泉ていいなぁ。日本人に生まれてよかった！などと思いつつ、電車で一路金沢へ逆戻り。
最終日は雪。でもたいした雪ではなかったので、あの兼六園も雪景色まではいかなかったのでは。。。
そして、金沢に戻って向かったのが忍者寺の異名をもつ妙立寺です。
http://www.myouryuji.or.jp/ninzyadera.html
こちら非常におもしろかったです。
予約制で10人程で1グループになりお寺の中を案内してくれるのですが、忍者寺と呼ばれるだけあって
様々な仕掛けがそこら中にあり、遊園地のアトラクションのようでした。
例えば、落とし穴にも使える床埋込み式の賽銭箱、本堂裏の隠し階段や落とし穴になった階段、
そして隠し部屋や隠し扉、隠し通路などがそれぞれの部屋を結んでいて迷子になりそうな複雑な
作りでした。確かにここに入り込んでしまった敵はそう簡単には逃げられないでしょう。
忍者寺と呼ばれるのは実際に忍者がいた訳ではなくて、その複雑な建築構造から
そう呼ばれているのだそうです。
こちら、タクシーの運転手さんにお勧めされたのですが、金沢に行く機会がある方はぜひ
自分の目で確かめてみて下さい。
そしてお昼。
最後の食事は、またもや寿司！でも今度は廻る寿司です。
普段はあまり回転寿司はいかないのですが、魚介類がおいしいところに旅行した時は
安くておいしいのでよく利用します。昼どきをはずれた時間に行っても営業してるので便利ですし。
まだ帰りの電車の時間まで余裕があったので、最後に21世紀美術館へと足を伸ばしました。
その名の通り、現代美術が展示してある美術館です。
http://www.kanazawa21.jp/ja/index.html
連休中とゆうこともあって、家族連れで賑わっていました。
美術館とゆうと大人しかいないイメージですが、こちらは子供向けの工作教室や子供が遊べる
部屋があるので騒いでも大丈夫なようです。
大人もただ絵を見るだけではなく、体験型美術館と謳っているだけにひと味違った美術館でした。
それにしても金沢見尽くしました。。。
ガイドブックにのっている観光地はほとんど行ったと思います。
もう見るところもなくなり、いい時間になってきたので金沢駅へと戻り、
後は駅ビルの中にあるお土産ものなら何でもそろう、金沢百番街でお土産を買うのみ。
色々なお土産を買ったので、最終回はそちらをご紹介します！
2008/01/30 00:00:00
そして金沢2日目
あいにく天気は雨・・・雪の方がまだ良かったなぁと思いつつ、まずは長町武家屋敷へ。
この界隈は旧加賀藩士が住んでいた武家屋敷跡が残っていて、土壁の石畳の小道が複雑に
入り組んでおり、江戸時代にタイムスリップしたかのようでした。
今日はバスで移動してみました。金沢市民の足とのことで週末とゆうこともあり大渋滞です。。。
普段どこに行くにもJR＆地下鉄で済んでしまうので、東京はホント鉄道網が発達してるんだなぁと痛感しました。
金沢は大通りはとても大きなビルが立ち並びデパートなどもあって近代的なんですが、一歩通りを入ると
この武家屋敷のような昔ながらの建物が残っているのがすごいです。
しばらくこの界隈を散策してお昼になったので、またバスに乗って金沢市民の台所、近江町市場へ。
市場内の「こてつ」とゆうお店で海鮮丼(1700円也)を食べました。
ご飯が少なめですが具はたくさんなので、女性にはちょうどいい量でおいしかったです。
市場内には今が旬のカニがたくさん並んでいましたが、足に青いタグがついているのが
地元でとれたカニの証だそうで、通常のものよりお値段高めでした。
そして、これから金沢市内から少し離れて本日の宿に向かいます。
今日は待ちに待った温泉！
金沢駅から30分程電車で移動して加賀温泉駅へ。そこから宿の迎えの車でゆられること10分。
着いたのがこちら。「片山津温泉せきや」さんです。
http://www.sekiya.yad.jp/index.html
旅行パンフレットの中からnetなどでも評判を色々調べて選んだかいあって、部屋・お風呂・料理と
どれも素晴しかったです。(しいて言うならお風呂が熱すぎたぐらい）
ちなみに料理の写真ですが・・・またもや1枚もありません！とゆうかもうとる事すら頭になかったような...
こうして2日目の夜もゆる〜く過ぎてゆくのでした。
金沢最終日につづく
2008/01/29 00:00:00
さて昨日の続き「兼六園」です。
冬の兼六園といえば、よくニュースで見る松に雪吊りがしてあって雪が積っている
風情ある景色を重い浮かべていたのですが・・・
実際は、まったく雪はなく拍子抜けでした。
タクシーの運転手さんに聞いたところ昔に比べたら雪があまり降らなくなったとのこと。
地球温暖化の影響なのでしょうか。
ちなみに雪がなくても雪吊りはしてありました。1本1本巨大な木を手作業でやっていくのは相当大変でしょう。
職人さん達もどうせなら雪がちょっとでも積ってほしいと思っているに違いありません。。。
兼六園に行くなら、雪がある時、もしくは紅葉とか桜の時期がいいのかもしれないですね。
次に兼六園のすぐ向かいの金沢城にも行きました。
その昔、お殿様はこの橋を通ってすぐ隣の兼六園を見に行っていたそうです。
現在の建物は昔火事で焼けてしまったものを立て直したものだそうで、天守閣はないそうです。
今はこの一帯が金沢城公園として開放してされていました。
それから、タクシーでひがし茶屋へ〜。
こちらは金沢に3つある茶屋街のうち、一番大きい茶屋街です。
なんとも風情のある佇まい。金曜日だったからか観光客もあまりいなくてとても落ち着けました。
この通りにはお土産物屋さんやcafe、小料理屋などもあり、ぶらぶらするのにもってこいでした。
このひがし茶屋と川をはさんだ向かいには、主計町(かずえまち)茶屋街があります。
こちらはひがし茶屋より規模は小さいながらも、夕方になると川沿いに灯りがともりとても綺麗でした。
そいえば、この主計町茶屋街は映画「舞妓Haaaan!!!」(脚本・宮藤官九郎のハイテンションムービーw)のロケ地だそうです。
京都が舞台ですが、ロケは金沢なんですねぇ。旅行から帰ってからDVD借りて見ちゃいましたw
辺りも暗くなってきて今日の夜は何食べよう。。。とゆうことで、作戦会議のため一旦ホテルへ。
そして決定したのが「加賀料理 大名茶屋」のぶりしゃぶコース！
http://www.kanazawaryouri.com/ryouri.html
初めて食べました、ぶりしゃぶ。
いや〜寒ぶり最高！やっぱり冬じゃないとこの脂のノリは味わえないでしょう。〆のぞうすいも格別でした。
それにしてもぶりの量がスゴイ！通常の1年間分のぶりを食べた気分です。
またもやお腹いっぱいでほろ酔い♪ そして、気づいた時にはまたもや料理の写真をとるのを忘れていたのでした・・・
つづく
2008/01/28 00:00:00
はじめまして。今週ブログを担当することになりましたykomaです。
普段ブログなど書かないので、拙い文章ですがよろしくお願いします！
1日目は私の趣味のひとつでもある旅行について書きたいと思います。
1年間でだいたい4,5回は泊りがけで旅行に行くのですが、20代前半は旅行といえば海外だったのが
最近はもっぱら国内旅行派です。気軽にいけるし、なんといっても温泉＆海・山の幸！
最高ですね。また行きたくなってきちゃいました。。。
つい先日も3連休を利用して金沢に行ってきましたので、その時の話しをしたいと思います。
まずは金沢1日目〜
今回は電車の旅です。朝5時起き！で7時の東京駅発で金沢駅には11：30頃着きました。
これが金沢駅です。立派でびっくりしました
とりあえず寿司！とゆうことで事前に調べて目星をつけていた寿司屋へタクシーで〜
金沢港にほど近い「宝生寿司」
いや〜さすがうみの近くだけあってどのネタもおいしい！！
興奮しすぎてお寿司の写真とるの忘れました…
なかでも3種類でたエビがどれもおいしかったです！
昼間からビールでほろ酔いでお腹いっぱいになったところで
まずは観光の定番、「兼六園」へ。
長くなったので続きはまた明日〜
2008/01/25 00:00:00
こんにちは、レオちんです。
最後になりましたが、今回は【癒し系映画】のおすすめをご紹介します。
■癒し系映画のおすすめ
第１位「グラン・ブルー(1997)」
リュック・ベッソン監督で最高です。音楽も映像も癒されます。
イタリア シチリア タオルミーナ 海 パスタ 海 パスタ 海 パスタ
海を愛する男を愛してしまったジョアンナと初めての恋を知るジャックが、恋におちていくロマンス。
青く深い海の中でイルカがジャックを待っていた。
名語句 『 私の愛を見てきなさい！ 』
わたしがスキューバダイビングに関心を持った映画でもあります。
第２位「ニュー・シネマ・パラダイス(1989)」
人はなぜ映画を愛して止まないのか？
その答えを SCREEN から教えられたなら．．．映画FUNとしてそれ以上の幸せはないでしょう．．．
第３位「ベティ・ブルー(1997)」
悲しくはかない愛の物語です。
破滅的な愛の日々を、激しく純粋に描いた作品です。
こちらも音楽や映像に癒されます。
グラン・ブルー
ニュー・シネマ・パラダイス
ベティ・ブルー
◆番外
「カリブの熱い夜(1984)」
ラブサスですが、ＨＯＴです。
「恋愛小説家(1997)」
ここでもジャック・ニコルソンが出てきましたが、ラブを演じさせても最高です。
カリブの熱い夜
恋愛小説家
ふっー、やっと終わったぁ。
みなさん、おつかれさまでした。
最後の方はプチやっつけでスイマセン。
一週間、お付き合いいただき、ありがとうございました。わん。
「いやぁ〜、映画って本当にいいもんですねぇ!」
「それでは、さよなら！さよなら！さよなら！・・・。」
2008/01/24 00:00:00
こんにちは、レオニダス（３００）です。
前回までで多少引かれた方がいらっしゃると思いますが、今日からは爽やかに(？)いきましょう！
今回は【男気系映画】のおすすめをご紹介します。
■肉体系映画のおすすめ
第１位「３００(2007)」
2007年公開作品で １位 に挙げます。
スパルタ教育です。映像と鋼のような肉体がスゴイです。
スパルタ王レオニダスが、わずか300名の軍勢で100万のペルシア軍を迎え撃つ。
わたくしレオのエイリアス「レオニダス」はここからきています。
第２位「トロイ(2004)」
ブラットピット主演、「トロイの木馬」や「アキレス腱」の由来が出てきます
ちなみにこの映画で、オーランド・ブルームが嫌いになりました。
第３位「グラディエーター(2000)」
リドリー・スコット監督で、スペイン、ローマでのコロッセオでの戦いには、手に汗握ります。
３００
トロイ
グラディエーター
■仁義系映画のおすすめ
仁義と言っても、深作監督の「仁義なき戦い」ではありません。
それはそれで最高ですが、ここではギャングマフィアものです。
第１位「スカーフェイス(1983)」
ブライアン・デ・パルマ監督
キューバ移民が、コカインの密売で成り上がっていく様子を描いています。
アル・パチーノ最高です。 ＦＵＣＫ 連発してます。
名語句 『 The World Is Yours 』 ＝世界は、あなたのもの
第２位「ゴッドファーザー(1972)」
フランシス・フォード・コッポラ監督
イタリア(シチリア)系マフィアが、家族(ファミリー/組織)を守るために、血で血を洗う抗争劇。
アル・パチーノ最高です。
第３位「ゴッドファーザーⅡ(1974)」
フランシス・フォード・コッポラ監督
アル・パチーノ最高です。ロバート・デ・ニーロもいい役者です。
スカーフェイス
ゴッドファーザー
ゴッドファーザーⅡ
今日もこの辺でっと。
明日は癒し系映画のおすすめを紹介します。
2008/01/23 00:00:00
こんにちは、レオポンです。
今回は、前回の他に【狂気/倒錯映画】のおすすめをご紹介します。
■狂気/倒錯映画のおすすめ２
あと、おすすめの監督としては、以下の監督が挙がりますね。
デイヴィッド・リンチ監督
「ツインピークス(1991)」なんか、はまりましたよ。
「ブルーベルベット(1986)」これも官能倒錯ものです。
「イレイザーヘッド(1976)」不気味なカルト映画です。ちょっと引きます。一般には薦められません。
「エレファント・マン(1980)」実話で泣けますが、ちょっとグロです。
デヴィッド・クローネンバーグ監督
この監督は、ボディ・ホラー系です。ボディというか脳関係のホラーですね。
「スキャナーズ(1981)」超能力者達の闘いを描いたＳＦホラー映画で、相手の頭部を破裂させます。
後に『北斗の拳』も影響を受けたとか受けないとか。
「ヴィデオドローム(1982)」幻覚操作ものです。
「裸のランチ(1991)」ドラッグ感覚で虫が沢山出てきます。虫がダメな方には薦められません。
あとラブなとこで、
「ＳＡＷ(2004)」ＳＡＷ３(2006)なんて、ちょっとスプラッターが入っています。
「ＣＵＢＥ(1997)」立方体の部屋での様々な殺人トラップの極限状態でのサバイバル。
今回は、画像は凄すぎるのでアップは控えさせてもらいました。
◆番外
狂気ではないのですが．．．
「パッション(2004)」メル・ギブソン監督もので、イエス・キリストの受難と磔刑が描かれています。
見ていて痛々しいですが、ジーザスはラブの神様です。
映画って「怖いですねえ、恐ろしいですねえ。」
昨日今日と、ちと重かったとおもいますが、明日からはもうちょっと軽くしますので、どうかヨロシクです。
あと、これだけ狂気映画、倒錯映画を薦めるわたしを引くかもしれませんが、
わたしは決して狂ってはいませんよ。（たぶん？）
これだけ人間の精神に関して観てくると、自ずとどんな人間が現れても冷静に判断出来るようになります。
驚きません。
特に、カッとなる事が無くなりますね。
今日もこの辺でっと。
明日は男気系映画のおすすめを紹介します。
2008/01/22 00:00:00
こんにちは、レオパンジャ（ジャングル大帝）です。
今回は【狂気/倒錯映画】をご紹介します。
■狂気/倒錯映画のおすすめ１
第１位「時計じかけのオレンジ(1971)」
第２位「シャイニング(1980)」
第３位「2001年宇宙の旅(1968)」
時計じかけのオレンジ
シャイニング 2001年宇宙の旅
監督はスタンリー・キューブリックに限ります。
残念ながら、1999年3月7日(享年70歳)にお亡くなりになりました。
「時計じかけのオレンジ」
近未来を想定していますが、暴力やセックスなど欲望に関して、やりたい放題で狂ってます。
スラング語を多用し、映画の主人公じゃありませんが、毎日のようにこの映画を見ていると必ず狂います。
「シャイニング」
俳優では当作品に出演しているジャック・ニコルソンが最高です。
狂気を演じさせたらグンパツです。
あの目がいいですよ、あと頭が薄いのもいい味出してます。
「2001年宇宙の旅」
サイケデリックな映像は必見です。
また、それまでのＳＦ映画に対する認識を、根底から覆すようなハイクオリティなＳＦＸ技術は、
後のＳＦ映画全てに影響を与えていると言っても過言ではありません。
日本の文部科学省が「特選」に指定している、唯一のＳＦ映画でもあります。
謎の物体「モノリス」、至上最高の人工知能「ＨＡＬ(ハル)９０００型コンピュータ」。
ＨＡＬはＩＢＭのそれぞれ前の文字を持ってきて名づけられています。
わたしがコンピュータというものに関心を持った映画でもあります。
上記３作以外で当監督作品では、
「フルメタル・ジャケット(1987)」
ベトナム戦争ものですが、極限の惨状が描かれています。
前半でいなくなって(自殺)しまいますが、微笑みデブがいい味出しています。
「アイズ ワイド シャット(1999)」
トムクルーズが出ていますが、官能倒錯快楽ものです。
当作品が遺作となりましたが、キューブリックにかかればエロもフィアーです。
「博士の異常な愛情(1964)」
原爆もののブラック・コメディですが、なんか考えさせられます。
今日もこの辺でっと。
明日はその他の、狂気/倒錯映画を紹介します。
2008/01/21 00:00:00
こんにちは、レオです。
とうとうブログ、回ってきてしまいました。
依頼をお願いされた時は、仕事中という事もあり「了解しましたぁ」と明るく答えてしまったのですが．．．
わたくし内気なとこがありますんで、年末頃からプチ鬱状態にかかっておりました。
当原稿も前日(1/20)に書いております。
あー、困ったぁ〜
だけど、既に担当なされた方も懸命にやられたようですので、わたくしもガンバリマスです。
１週間分の段取りもなぁーんにも考えておりません。
えーっと、お話しは映画に関して語りましょう！。そうしましょう！！
わたくし年も年なので、かれこれ、いい加減相当の映画を鑑賞しました。
映画館率１割（大体先行ロードショー）、ビデオ６割(古っ！)、ＤＶＤが３割という感じです。
ラブなジャンルは気狂いもの（狂気/倒錯映画）がなぁーんかラブです。
現実逃避出来るような出来ないようなとこがいいーんだなぁ！
あー、疲れたぁ〜
今日は、この辺で勘弁してください。
次回から本題に入りますので、ヨロシクです。
多少、マニアックで引くところがあるかもしれませんが、ご了承を。
2008/01/19 10:00:00
「てん」と打って三点リーダが出てきてほしい新人君です。
三点リーダの正しい出し方を知っている人がいらっしゃいましたら、教えていただけるとありがたいです。
あれなので今回は短く。
firefoxやIEの検索ボックスで検索するとき、思い通りに検索できなくて困ったことはありませんか？(ブックマークにプロパティの値を設定していたときを含む)
そんなあなたに、このアプリ
結構使いやすくなって結構便利です。
あれだからといって短すぎるのは…、ということでもう一つ。
先日行われた会社説明会には「えんどう」さんと「nobsun」さんが出られたそうですね。ちょっとサプライズ！？
2008/01/18 00:00:00
というわけで、高尾山トレイルランです。
高尾山でトレイルランというのは皇居ランなみにベタではありますが、気にしないことにしましょう。
今回紹介するルートは京王電鉄高尾線高尾山口駅から陣馬山の往復約28kmです。
準備
ウェアは動きやすければ、適当なもので。走りはじめれば(運動を止めない限り)体は暖かくなるので、冬でもそれほど防寒に気を使う必要はないです。
シューズはジョギングシューズで十分と。
飲み物はペットボトル1本分くらいはあったほうがいいです。
念のために、地図のコピーを携帯しましょう。
当日
早立ちを心がけます。
高尾山口駅についたら不要な荷物はロッカーに預けます。
身軽になったら、軽くストレッチをしてスタートです。
高尾山へ行く道は何通りもあるので、ケーブルカー以外の手段で好きなルートを選んでください。高尾山口駅〜高尾山間は走りにくいのが難点です。しばらくの辛抱と割り切りましょう。
高尾山を越えるとトレイルらしい道が出てきます。ようやくやる気も出てきました。
陣馬山への道はいくつかの分岐がありますが、基本的に一番太い流れが陣馬山への道です。迷ったら地図で確認してください。
また、行き先は同じでありながら、小ピークを経る道とその巻き道の分岐がいくつもあります。巻き道のほうが走りやすいので僕は巻いていますが、ピークを踏まないと嫌だ、という人は登り降りを楽しんでください。
白いお馬さんが見えたら、陣馬山に到着です。なぜ山の上に白馬なのか、、、僕は知りません。
一休みしたら逆方向から同じ道をたどります。高尾山口駅へたどりつけばゴールです。
ビールを一杯といきたいところですが、トレーニング効果が激減します。我慢しましょう。
よくある質問とその答え
28km は長い!
往復 28km に自信がない人は、
- 陣馬山から和田峠におりる
- 景信山 OR 小仏峠までのピストンにする
などして距離を調整することが可能です。
ヒザが痛い
山登りの下り(山下り?)はエキセントリック収縮の典型例です。
ゆっくり下っても十分過ぎるほど刺激をえられるので、下りでがんばる必要もないでしょう。
特にヒザが悪い人は無理をしない方がよいです。
一方で、レースでは下りが順位を上げる一番のがんばりどころです。
人大杉で走りにくいのですが
高尾山はミシュランで三つ星を獲得するだけあって大人気で、とりわけ高尾山口駅〜高尾山は人口密度が高いです。
トレーニングと割り切り、始発狙い、休憩時間を出来るだけ省き、さっさと下山するようにして、観光客の行動時間とできるだけかぶらないすることが大事です。
観光客からすれば、ハイキングしているところをスピードを上げて追い越されると怖いですし、ランナーからしても、観光客が多いと走りにくいです。
トレランをやるなら人口密度の低いエリア・時間帯を狙いましょう。
僕が住んでいる平地部でも、昨夜ようやく初雪が降りました。
やはり冬は雪が一番です。
2008/01/17 00:00:00
今回はハイドレーションつながりでトレイルランニング(略して「トレラン」や「トレイルラン」)の話をします。
トレイルランは wikipedia では「登山をするような規模・深さの山を、ランニングで走り抜ける競技」と定義されています。
ロードやトラックで単調に走る場合に比べて開放感があり、飽きがこないのが一番の魅力です。
私見では、クロストレーニングの一環としてトレイルランに取り組んでいる人が多く、(ウルトラ)マラソン選手、山屋が2大勢力、続いてトライアスリート、オリエンティアといったところでしょうか。平均年齢は高め。大会では少数精鋭の自衛隊員が上位入賞するのも、特徴といえば特徴です。
実業団の長距離選手の中にはクロスカントリートレーニング(スキーではなく走るほうです)の延長上として、走り込み期にトレイルランニングを取り入れている選手も多いようです。
トレイルランニングの世界に少し興味を持った方は、少し古いですが、
「ランニング登山」(下嶋 渓、1986年、山と渓谷社)
をオススメします。
刊行は 1986 年と少し古いですが、トレイルランニングという言葉が日本で広まるはるか昔に、日本の山道を走ったらどうなるか?そんなことを考え、自ら人体実験した結果・考察をまとめたユニークかつニッチな一冊です。残念ながら、大学教授だった著者の下嶋さんは1999年にマッターホルンで亡くなられています。
今となっては入手しづらいので、図書館などから借りて読んでみてください。
トレイルランは、観戦していてもつまらないです。実際にやってみないと面白くありません。
明日は、都民にとってアプローチがよく、入門者向けトレランコースとしても最適な高尾山〜陣馬山のコースについて説明します。
2008/01/16 00:00:00
第2回目は多くの人にとって馴染みがないと思われるハイドレーションシステムについてです。
どういうものかというと、液体の入った袋(リザーバー)をバックパックに入れ、袋とつながったチューブを前(胸元)に持ってくることで、バックパックを背負ったままチューブから水分補給が出来るという代物です。
ハイドレーション対応のバックパックには、写真のようにバックパック内部からチューブを通すための専用のポケットが用意されています。
下界ではさっぱり使い道がないのですが、
- 水を飲むために(重い)バックパックをおろさなくてすむ
- 水分補給で時間ロスしなくてすむ
- サイズが固定されたペットボトルと異なり、水の残量によってサイズが可変するのでかさばらない
といった理由から、山をやる人、とりわけ、トレイルランナーに人気があります。
そんな便利なハイドレーションシステムも使い方を誤ると大変なことになります。
・氷結
ある冬の寒い夜、せっかく翌日の水を作ったのに(雪を溶かして作ります)、シュラフに入れて体温で温めるのを忘れてテント内に放置したために、翌朝になるとカチンコチンに氷結していました。
液体になっていないと飲めません。
・洗浄し忘れ
スタートして程なく一回目の水分補給を行おうとチューブを口にすると、何とも言えない酸っぱい味が、、、
リザーバーのみを洗浄していて、口に入れるチューブの洗浄を忘れていたのが原因でした。
使い終わったら、すぐに丁寧に洗浄し、次回に備えましょう。
というわけで、一般人には使い道がないハイドレーションシステムの紹介でした。
2008/01/15 00:00:00
今週担当の tortellini です。一週間、雑多なテーマについて語りたいと思います。よろしくお願いします。
第1回目はセームタオルの話を。
水泳をやっていた人はご存じかと思いますが、セームタオルは水分吸収力が非常に優れたタオルで、拭き取った水分も簡単に絞ることができ、何度も繰り返し使えます。
安いものは \1,000 前後と値段も手頃で、かさばらないのもいいですね。
あえて不便な点を上げれば、乾いたときにパリパリになってしまったり、湿ったままほったらかしにするとカビが繁殖することもあることでしょうか。
こんなに便利なものを水泳だけに使うのはもったいないと思う人も世の中にはたくさんいるようで、意外な使い方としては、昨年の世界陸上2007大阪で日本の女子マラソン選手が、ランパンにセームタオルをぶら下げ、水分を拭き取っていました。汗が染みついてしまうので、使い回すのは少し抵抗がありますが、、、
今年の夏のエンデュランス系レースでは、セームタオルをぶら下げた人をたくさん見かけるかもしれません。
というわけで、プールでは普通のタオルで体を拭いているという方や、水分を効率よく拭き取る必要に迫られているという方は一度お試しを。
2008/01/12 10:00:00
あけましておめでとうございます、新人君です。
この前の一週間で携帯の開発に興味をもたれた方もいらっしゃるはず！
そこで、簡単なBrewの開発の模様を、下準備から含め数週にわたりレポートしたいと思います。
今週は、開発環境の構築です。
開発環境の構築は、PCにソフトなどをインストールする順番を間違えると"コンパイルができなくなる"などの問題を多々含みます。気をつけて、インストールしましょう。…、……、私のせいじゃないです(泣)
さて、まずはVisual Studioのインストールです。
Brewの開発は、すべてVisual Studio上で行われます。Visual Studioを用意しましょう！最近はVisual Studio 2008の開発も終わり、使いやすい環境になってきましたね。結構サクサク動いていい感じですよね、Visual Studio 2008は。
ただ、BREWの開発環境としては新しすぎて使えないのです。じゃあ、Visual Studio 2005を用意する必要があるのでしょうか？違います、Visual Studio 2005も新しすぎます。我々が使用を許される最新環境はVisual Studio 2003.NETです。…、……、私のせいじゃないです(泣)
さあ、大半の人が脱落されたと思いますが、続けます。
Visual Studio 2003にインクルードディレクトリに$(BREWDIR)\inc;$(BREW_USER_COMMON)\inc;という二つのパスをインクルードディレクトリとして追加してください。
いよいよ、コンパイラのインストールです。実機に流し込みをしたいなら、指定のBrewコンパイラを買うしかありません。さぁ、銀行の口座の残高を確認してみてください。15万円以上ありますか？あることを確認したら、それをコンパイラに使ってはダメです。もっとお金と時間は有意義に使うべきです。なかったら、実機に流し込むのは諦めてWindowsアプリとして、シュミレータで我慢してください。どうしても実機で動かしたい場合は、Brew上にJAVA VMを載せて、その上で動かす方法がauから提供されています(オープンアプリ)。ただ、Jarのファイルサイズが300キロバイトと極小ではありますが…。まぁ、100キロバイトよりはましかな。Brewアプリは手元の携帯だと2.5メガバイト使えるみたいです。
さあ、ほぼ全員の方が、これ以上読むのをあきらめられたかもしれませんが続けます。シュミレータ上で動かしたい、マゾなあなたのために…。
BREWのSDK、つまり開発セットを手に入れます。Qualcomm社が提供していますSDKとSDK Toolsをダウンロードしてインストールします。Qualcomm社とは、BREWアプリのプラットフォームを開発しているところです。それぞれ、現在の最新バージョンはSDK3.1.2 Japanese 3.1.2.13とSDK Tools Japanese 1.0.1.7です。
以上で、開発環境の設定は終わりです。
お疲れ様でした。
さて、次回は早くも題名が変わりまして、シミュレータ上でHello Worldを表示するぞ！です。
2008/01/11 00:00:00
そして現在進行中なのが、
auの携帯電話向けのBREW版ドダイ・モバイルの開発です。
iアプリ・S!アプリがなんだかんだで
Javaという同じ言語をベースにしていたのに対し、
BREWはC言語もしくはC++言語を使ってプログラムを進めていくことになります。
この、C系の言語を使う、というのが
ドダイ・モバイルのプロジェクト開始以来ですっかり
Javaの世界に慣れてしまった身にはいささか辛いものがありました。
BREWはC系の言語を使うところからもわかるように、
言うなれば「昔ながらの世界」という感触が強いです。
とにかく「直接触れる・触っている」と感じます。
JavaではVM層が存在するため、
その上で動くプログラムが多少悪さをしたところで、
ベースシステム（携帯電話全体）にまで大きな影響が及ぶことはまれでした。
しかし、BREW用のプログラムでは、
プロセスという単位での保護すらありません。
BREW用のプログラム（アプレット）は、
実際には携帯電話からDLLとして呼び出されることにより動作します。
……という動作モデルを正しく想像できた方なら、
その危険性にも気付かれることでしょう。
そう、BREWのプログラムはベースシステムに影響を与えます。
メモリリークすればそれはシステム全体のメモリリークであり、
完全に電源を落とすまで悪影響は残り続けることになるのです。
そういった弊害があるために、au用にBREWのプログラムを作っても、
KDDIによる審査・検証を経なければ公開することができません。
しかも、APIやその他開発資料にアクセスするための障壁も
高くなっているため、iアプリやS!アプリに比べて圧倒的に情報が少ないのです。
5年前の時点ですでに枯れていたやり方をベースに、
当時の機器のハードウェアの限界の中で最大性能を引き出すことを目指した。
BREWというのは、そういうプラットフォームです。
対してJavaは、5年前に携帯電話に載せるのには正直無理がありました。
しかし時代は進み、今や携帯電話で採用されるような
CPUでもJavaは楽々と動作するようになりました。
既に携帯電話用のアプリ開発では、
Javaの方にアドバンテージがあると思います。
対してBREWは、
現代的なプログラミングの常識からすればやはり辛い環境です。
しかし数少ない救いは、出来上がる実行形式ファイルの小ささと、
関数ポインタの存在でしょう。
特に関数ポインタの存在は大きいです。
iアプリやS!アプリでは、やはりJarサイズの制限から
あまり野放図にクラスを作れないという制約が課されます。
しかし、仮にC++でなくCを使ったとしても、
関数ポインタがあればよっぽどオブジェクト指向らしい、
ずいぶん綺麗なコードを実現できます。
やはり小さなサイズに多機能を詰め込むのなら、
そしてそういった制約のある中でコードを綺麗に保ちたいなら、
関数ポインタ的な機構は必要だなあ、と痛感しています。
とはいえこの状況も、今後のCLDCの発展で
リフレクション回りが充実すれば逆転するのでしょう。
と、あまりまとまっていませんが、
ここらで今回は筆を置きたいと思います。
ドダイ・モバイルにもう少し進展を迎えたあたりで、
またなにか書く機会があるかもしれません。
2008/01/10 00:00:00
◯ServiceRepaints()メソッドの罠
そこにもうひとつ重なったのが、デッドロック問題でした。
通信中にキー入力を入れると、通信が固まる。そんな形で問題は浮上してきたのです。
調べていくと、見えてきたのはServiceRepaints()というメソッドの存在。
このメソッドの挙動が、最大の罠だったのです。
このServiceRepaints()というメソッド、
実行すると「特定のスレッドに再描画を行わせて完了するまでブロック」
という挙動をします。
ところでJavaでのスレッドの並列動作モデルというのは、
・基本的に各スレッドは勝手に動く
・各スレッドは比較的単純な単一の役割を与えられる
・複数の仕事を担当するようなスレッドは極力存在させない
というようなあたりを前提として構築されています。
もちろん例外はあって、たとえば他のスレッドの完了を待たねばならないような場合は出てきます。しかしそういう場合でも、wait()メソッドがそのあたりをうまく扱ってくれます。具体的には、wait()メソッドで待ち状態に入るときには自分の握っているロックを解放してから待ってくれるのです。
ところが。
ServiceRepaints()は、実行したスレッドをブロックさせるくせに、どうやらロックに関する処理をなにもしてくれないのです。
しかもServiceRepaints()の呼び出しに応じて再描画を実行するのは「イベントスレッド」とでも呼ぶべき、システムが送ってくるキーイベント類を一括管理するスレッドです。
この、「特定のスレッドに処理をさせる」というのが実に厄介な特性です。
そのようなモデルになっているために、キーイベント処理と描画処理とで、そのスレッドの実行権を奪い合うという現象が発生してしまいます。
そもそも、Javaのスレッドモデルの基本概念に沿うなら、そういう仕事が集中してしまうスレッドは極力作るべきではないのですが。しかしシステムの用意するAPIにそんなメソッドがあるということは、そんな「作るべきでない」スレッドが当初から存在しているということ。
結局この問題は、「イベントスレッド」の行う仕事が極力短く終わるようにし、かつ問題の種となるServiceRepaints()を決して使わないようにする、という方法で解決したのでした。
2008/01/09 00:00:00
そんなこんなでサイズ制限と戦った結果、
ドダイ・モバイルは無事最初のアプリを送り出すことに成功しました。
その後もいくつかのエンドユーザー様に
ドダイ・モバイルをベースにしたアプリを提供し、
徐々に機能も拡張されてきました。
こうなると欲が出てきます。
ドダイ・モバイルはiアプリ用に組んだものですが、
これを他のキャリアの携帯でも動かせないか……という話になるわけです。
そこでドダイ・モバイルの第2次展開として、
- ソフトバンクの携帯電話向けのS!アプリ版
- auの携帯電話向けのBREW版
の2つの移植版を作成することになりました。
……と、まるで過去形のように話していますが、
これら2つはまさしく開発進行中、というステータス。
とはいえ共にフレームワークとしての基礎部分の移植は終わり、
実際のアプリ完成に向けて鋭意作業中、という段階なのですが。
このうち先行しているのはS!アプリ版です。
S!アプリのJavaも、フルスペックのJavaではありません。
CLDC+MIDPという携帯電話/PDA用のJavaの標準フレームワークに、
ソフトバンク携帯用の拡張機能を追加したJSCL、あるいはMEXAという
API群を追加した環境下で構築することになります。
しかし、S!アプリについては事前の予測では好材料が多かったのです。
iアプリと同じJavaベースということで、
比較的軽微な作業で行けるのではないかと予想しました。
また、アプリとリソース合わせて1MBというサイズの潤沢さ。
既にサイズを削りまくったiアプリの移植ですから、
サイズ問題はまず起きないものと思いました。
このうちサイズ問題は見事意図どおりだったのですが、
もちろんそう簡単に事は進みませんでした。
◯安定しないソフトキー
最初の問題はソフトキーの位置が定まらないこと。
携帯電話の最上段左右にあるキー、と言えばわかりやすいでしょうか。
ドダイ・モバイルではここのキーを
メニューの呼び出しやキャンセル動作に割り当てているのですが。
しかしS!アプリではこのソフトキーへの動作割り当てが抽象化されています。
1番にはこの機能、2番にはこの機能、という設定はできるのですが。
ところが実際の機種で動かしてみると、
1番に設定したキーが右に来る機種があれば左に来る機種もあり。
とはいえ元々使えるキー数の限られた携帯電話です。
左右のキーに何が割り当てられているかの表示は
正しい対応で出してもらえるので実用上大きな問題はないだろう、
という判断でこの問題はスルーすることになりました。
◯ゲーム用特化のキー状態判定API
次に出てきた大きな問題は、キーの状態判定でした。
iアプリでは各種キーが連打されたときに
予期せぬ動作をしてしまうことを防ぐため、
キー入力イベントの処理時に
「今のキー状態がどうなっているか」を
毎回チェックするようにしていました。
こうすれば、連打などの影響でキー入力イベントが
実際のキー入力から遅れてやってきた場合には、
その入力を無視することで予期せぬ動作の発生を防ぐことができるわけです。
しかしS!アプリでは、「全てのキーの状態取得」ができないのです。
「今のキー状態」を取ってこれるのは、
「方向キー」の4方向と「FIREキー」に「ゲームキー」がABCDの4つの、合計9つだけ。
しかも「FIREキー」「ゲームキー」が実際にどのボタンに割り当てられるかは
機種ごとにまちまちで、「割り当てがない場合もある」のです。
ドダイ・モバイルでは数字キーをショートカットに割り当てていたので、
これではキー状態の判定が正しくできなくなります。
結局はキー入力イベントが上がったときに、
まずは迅速に「キーの入力があった」
「今キーの状態はこうなっているはず」という記録を残し、
後から別のスレッドで蓄積しておいたキーイベントを処理するように変更しました。
これでひと安心……と思いきや、その後に最大の罠が待っていたのです。
2008/01/08 00:00:00
アプリサイズとの戦いのために施された工夫は、
地道で泥臭いチューニングばかりではありません。
「DODAIブログ - 07.100KBの攻防」 http://www.timedia.co.jp/techniquearchive/dodai/1994304730
でにて書かれていたところの
1. プログラムの構成要素を可能な限りリソース化し、
限られたメモリにたくさんの機能を埋め込む機能
の部分です。
普通ならば、プログラムにはプログラムで「やること」が書かれます。
画面に表示するものがあるのなら、何かを画面に表示するようなプログラムが書かれる。それが最も単純な作り方というものです。
しかしそれをやっていては、画面に表示するものをちょっと追加しただけでアプリサイズが増えることになります。これは実によろしくない。
そこで導入されたのが、「画面定義の外部リソース化」です。
ビジネスアプリの画面に出てくる、ボタンやテキストボックスや文章などの中味や配置情報を、画面定義ファイルという形でプログラムの外側に追い出しました。
- プログラムは起動時に画面定義に従って画面要素を並べることで画面を構成する
- 共通コードでは画面内の共通動作(キー入力に従ってフォーカスを移動するなど)を処理
- ボタンを押された等のイベントが発生したら、各画面クラスの特定メソッドを起動
これ自体はGUIプログラミングなどでよくあるモデルだと思います。
リソース定義は(Javaでの)読み込み・解釈を楽にするために
人間にとっての可読性は二の次とあきらめて、
タブ区切り形式で書かれることになりました。
たとえばログイン画面の定義だと、こんな感じになります：
canvas LoginScreen
layer LoginScreen base ログイン 0 機能 1
widget LoginScreen base imagelabel loginBg 252 0 0
widget LoginScreen base imagelabel loginFooter 253 0 226
widget LoginScreen base textbox LoginId USER_ID 82 62 10 1 true 0 0
widget LoginScreen base textbox LoginPasswd 82 82 10 1 true 1 0
widget LoginScreen base button OKButton Login 159 162 true 0
また、リソース定義においては画面定義に加えて、
プログラム内部で使うコード表も定義できるようにしました。
電文では数字で送られてくるデータを、
表示するための文字列に変換してやる……
というのを想定して付けられた機能です。
code minutes 1分 3分 5分 10分 20分 30分 60分
しかしこの機能は、やがて想定とはまったく異なる形で使われるようになります。
code Screen1SetList name price date rate
このcodeで定義されているのは、「電文レスポンスのうち、画面にどのデータを表示するか」です。
とても単純なものですが、これはいわばプログラムです。
Javaの上に、小さな独自言語を解釈する機構を作り、code定義の中味をプログラムに見立てて解釈させる、というわけです。
code drawTypeToFontNumber 1 -1 2 3 5 9 -2
transCodeInt drawTypeToFontNumber
このコードでは、まずdrawTypeToFontNumberという名前のcode定義を行います。コード定義はString用に作られていますから、1行目の時点では"1" とか "-1" とかの文字列が入ったStringの配列が設定されています。
そこで2行目のtransCodeInt が読みこまれると、drawTypeToFontNumberのコード定義が、Stringの配列からintの配列に変換されます。本来ならプログラムの中で静的に定義すべき変換表を、こうして外部に押し出してやることで、ちょっとでもアプリサイズを削るために作られたテクニックです。
さらにはこんなのまで登場するようになりました。
code2D BoardEventDef PriceList sendMesID=Q032 group=1
select=changeScreen:OrderInput soft2=popMenu
left=changeScreen:OrderList right=changeScreen:News
勘のいい人なら見ただけでわかるかもしれませんが、
ここには画面内で特定のキーが押されたときの動作などが書かれています。
しかもこの定義データを実行時に毎回解釈するは効率が悪いので
起動時に簡単なコンパイルのような処理を行い、
実行中は中間形式として保持されるということに。
「いったいどこがJavaのプログラムなのか」という状態です。
「屋上屋に屋上屋を重ねる」という言葉が思い浮かびますが、
単一のクラスでありながら実際には20種ほどの画面を担当する、
という摩訶不思議なコードが生まれた結果、
アプリサイズは劇的に圧縮されることになりました。
2008/01/07 00:00:00
ドダイ・モバイルの開発ターゲットは、
iアプリ(NTT DoCoMoさんの端末向けのアプリ)向けのものから始まりました。
iアプリは、Javaで作ります。
といってもフルスペックのJavaではなく「DoJa」と呼ばれる機能制限版のJava環境です。
より正確には携帯電話やPDA向けの機能制限版JavaであるCLDCに、NTT DoCoMoによる独自拡張を加えたものがDoJaと呼ばれるもの。
これが、携帯電話の世代が進むごとにちょっとずつ拡張されています。
ハードウェアの進化に合わせて、少しずつできることが増えていくわけですね。
この「なにができるか」の世代ごとでの定義はDoJaプロファイルと呼ばれます。
世代ごとにバージョン番号が付けられ、もっとも古いものは「DoJa-1.0」。この記事を書いている時点での最新は5.1です。
同一のプロファイルであっても、使用可能な画面サイズやメモリ容量は各端末ごとに違います。とはいえ、プロファイルのバージョンが同じなら、最大公約数的なだいたいのスペックは揃えられているようです。詳しくは次のページなどを参考にしてください：
NTT DoCoMo「iモード技術情報：端末スペック一覧：iアプリ」
http://www.nttdocomo.co.jp/service/imode/make/content/spec/iappli/index.html
端末スペック一覧を見て気付くのは、容量関連の制限の多さです。
一覧には３種類の容量関連の制限が記されています。
JAR、スクラッチパッド、ヒープの３つです。
このうちもっとも小さいサイズなのはJAR、
スクラッチパッドがそれよりも大きく、
ヒープはもっと大きく使えます。
これら制限のうち、真っ先に問題になるのは、JARの——iアプリとしてダウンロードされるプログラムのサイズ制限です。
Javaで普通にクラスを定義すると、それだけでJARのサイズは数KB消費されます。ほとんど機能のない、ほぼ空っぽのクラスであっても、間違いなくサイズは増えてしまいます。
だというのに、古いプロファイルではJARのサイズは10KBほど。そんな環境でプログラムを組むと、どうなるか。
出来上がるのは、ひとつのクラスにすべての機能を押し込んだ、とてもJavaのものとは思えないプログラムです。実際には、DoJaの仕様上２つのクラスを作らないといけないので、ほぼ空っぽのクラス１つ＋全機能を押し込んだクラス１つ、という構成になります。
アプリサイズが実質30KBまでに制限されていたDoJa-3.0プロファイルまでの世代では、それ以外の作り方は事実上不可能だったようです。
幸いドダイ・モバイルでは（画面サイズのことも考えて）対応プロファイルをDoJa-3.5以降に設定しました。画面サイズは240x240が保証され、JARサイズも大半の機種で100KBまでOKになります。
しかしそれでも100KBというサイズ制限は、絶対的な壁として立ちはだかりました。
まず導入されたのはJARサイズを減らすための圧縮ツール。
フリーのものではProGuardというクラスファイル最適化ツールがお勧めです。
ProGuard
http://proguard.sourceforge.net/
もちろんドダイ・モバイルでも劇的な効果を発揮してくれましたが、それだけでは不十分。更にプログラムサイズを節約するために、オブジェクト指向としては望ましくないテクニックが磨かれていくことになりました。
いくつか例を挙げますと、
- データコレクションのためのクラスは使わず、標準のVectorやHashtableを使う
- int型をオブジェクト化するときには、Integerクラスを使わずに要素数1個のint配列を使う（そのほうがサイズが小さい）
- 引数型が異なる同名メソッドを作るとサイズが大きくなるので、Object型の引数を取るようにしてメソッド内部で型判別して分岐させる
というような、オブジェクト指向の概念に真っ向勝負を挑むような「良くない見本」のオンパレード。現代的なプログラミングではずいぶん縁遠くなった、地道で泥臭いチューニング作業を重ね、完成版のアプリではなんとか100KBにプログラムを収めることができました。
2008/01/04 00:00:00
2008年の第1週と第2週、このブログを担当させていただきますwhiteと申します。一週間と加えること一日、よろしくお願いします。
一週間も続けて話せる話題があるかといえば、そんな話題があるなら(ここではない)自分のブログに書くわい！ と言いたいところなのですが、幸か不幸か今の仕事がちょうど話せるネタになりそうです。
ということで実に手堅くつまらないネタ選択ですが、しばらくの間、仕事の話におつきあいくださいませ。
さて今の仕事といいますのは、
携帯電話で動くアプリケーションを作るお仕事です。
それも単にアプリを作るのではなく、フレームワーク層とアプリケーション層に分けて設計をして、あわよくば各キャリア対応のアプリをさくっと作れるフレームワークにしてしまおう、というちょっとばかり野心的なやりかたで進めています。
と、弊社Webの隅々まで読んでくださった方ならちょっと小首を傾げていたりするかもしれません。
そう、私たちのチームが作っているのは、
「DODAIブログ - 07.100KBの攻防」 http://www.timedia.co.jp/techniquearchive/dodai/1994304730
にて既に紹介されている「ドダイ・モバイル」そのものなのです。
しかし往々にして宣伝文句なんてものは嘘っぱちになるものでして、
1. プログラムの構成要素を可能な限りリソース化し、
限られたメモリにたくさんの機能を埋め込む機能
このへんはまあ真実なのですが、
2. そのリソースを扱いやすくするためのツール群
このへんになるとだんだん現実と宣伝の解離が激しくなってきますし、
3. サーバとのやり取りをRDBアクセスと同じようにデータモデルの中心と捉え、
通信電文定義書から自動的にコードを作成する機能
残念ながら(iアプリの)100KBというサイズ制限に立ち向かう上では自動生成コードなんてものが役に立つ訳がなくむしろ害悪なため、結局は手作業によるチューニングが主体となり、
4. 限界までチューニングされたライブラリ群
そして限界までチューニングをするためにはライブラリとアプリケーションがどんどん不可分になる＝「チューニングされたライブラリ群」としては取り出せない状態に、という羽目に陥っているわけです。
しかしながら。
制限がない世界であればもちろん「きちんと分離されたキレイなライブラリ／フレームワーク」が理想です。ですが、ケータイアプリにはイマドキの普通のアプリたとえばiアプリのDoJa-3.5プロファイルでは、アプリのダウンロードサイズが100KBまでに制限されます。
そんな世界でキレイなフレームワークを使おうとしても、サイズ制限にひっかかってそもそもアプリが動かせません。そこで汚なくなることを覚悟で、フレームワークとアプリを不可分にしていくことを選択していくことになるのです。
そんな、プログラミングパラダイムとすればちょっと昔気質な雰囲気のケータイアプリ作りの過程でのあれやこれやを、一週間かけて少しばかり紹介していきたいと思います。
