クラウド・コンピューティングにおけるセキュリティー関連の情報

自分の備忘録としてもまとめておく。

1. Cloud Security Alliance Guidance

    第二版になって、大分中身が整理されました。セキュリティーの専門家向けです。読み物というよりはリファレンスという位置づけですね。

2.  ENISA Cloud Computing Risk Assessment

    上記のCSAも第二版でクラウドに置く資産の評価から始めようという記述を追加していますが、こちらのガイドはリスク評価中心のアプローチなので、既存のシステムをクラウドに移そうという場合には使えるガイドかもしれません。

3. IBM Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security

    自社の発行なのであまり悪いことは書けないですが、もう少し絵が欲しいかなという内容。まぁRedPaper扱いなので今後Updateされると思います。

どのガイドも一長一短で、これを読めばバッチリというものが無いのが現状です。特にセキュリティーに詳しくない読者に対してはSaaS/PaaSとIaaSを一緒くたに語るのが無理があると思っている今日この頃です。

Paul Van Dyk Volume Tour 2009@新木場ageha

子連れのプラレールツアーの報告後の連投で恐縮ですが、10/10に新木場agehaで行われたPaul Van DykのGIGに行ってきました。

Paul Van Dykは毎年１回くらいのペースで来日しています。昨年は代官山UNITというやや小さめのクラブでプレイしたのと、FUJI ROCK FESTIVALに出場しています。UNITのGIGには私も行って、音が良かったので満足しました。一昨年は今年と同じagehaで、その前もagehaかな？２年前の時はうちの奥さんも一緒に行ったのを覚えています。もう今は子供が（二人も）いるので、奥さんは一緒に行けないのが残念です。

いつもagehaでプレイすると前座の人が入って、Paul自体はAM2:00頃からのプレイになります。今年もそのつもりで行ったら、スケジュール自体がAM3:00からで、前座のYodaの後ろでジャーマンなスタッフの方がMacBookProやミキサーをセットし始めたものの何度もやりなおして、結局Paulのプレイが始まったのがAM3:30でした。今年はagehaに入るための行列が嫌だったので、23:30くらいにagehaに到着して並ぶことも無くすんなりと入れたのですが、スタミナが持たなかった．．．年も年ですしね。はぁ。

Paulのプレイですが、いつものごとく、一曲一曲をゆっくりかけていくのではなく、曲と曲がマッシュアップされて短時間でめまぐるしく、しかも自然な感じでつながっていきます。他のDJと違って、自分の曲や自分がRemixした曲が多めの感じですかね。また、Paul Van Dykというと”トランス”ということで有名ですが、DJプレイのときはハードな感じのジャーマンテクノ系の曲が多いです。ジャーマンテクノのガッツンガッツンとベースのはっきりした４つ打ちの後にトランス調の曲でアゲるという感じですね。今年は去年と比べてもテクノ調の曲が多く硬い感じのプレイでした。個人的にはもうちょっと甘めの選曲が好きなので、昨年のUNITの時の方が良かったかな。

最新アルバムに入っているHomeという新曲も他の曲にマッシュアップされながら流れて、聞いたことが無いトランス調のミックスがされていました（原曲はアコースティックギターなども入っているロック調の曲）。旋律があまりに美しかったので、ちょっと昇天しかけてしまいました（トランスしかもPVDやFerry Coasten、Alex M.O.R.P.Hが好きな人なら分かると思います）。

今回agehaに行ってビックリしたのは、全くタバコ臭くならなかったこと。完全に分煙化されているんです。他のクラブだと全身ヤニ臭くなって、子供がいる家に帰ったらすぐにシャワーで流していたのですが、今回は全く平気でした。（シャワーには入ったけど）ただ、agehaで残念なのは音響があまり良くないこと。個人的にはただ音量がデカイだけと感じるんですよね。UNITなどの方がメリハリがあるというか出音が割れていなくて好みです。テクノは所謂電子音楽ですが、歪みギター系の爆音と違って、綺麗な音は綺麗に出てくれないと気持ち悪いというか聞き疲れするんですよね。弊店してしまった西麻布のYellowも音響は良かったので、agehaの音響も何とかしてほしい。巨大なお店の作りといい、複数のDJが同時に違う場所でプレイするスタイルといい、スペインのイビサ島風な唯一の東京のクラブなので今後に期待したいです。

なのはなプラレール号

10/12 ３連休最後の日に息子を連れて、このツアーに参加してきました。ツアーを見つけたのもGIZMODE JAPANさんの記事です。

息子はもともとプラレールファンではありませんでした。きかんしゃトーマスの大ファンで最初は海外産の木製レールシリーズという、電動では無いタイプを買い与えていたのですが、だんだんと電動で動くものに興味が出てきたようで、木製レールシリーズはすっかりお払い箱で最近はプラレールトーマスシリーズにはまっています。

今回のツアーは記事にある通り、行きはお座敷列車のお座敷でプラレールを遊び倒し、帰りはSLみなかみ号（D51機関車）で帰ってくるという鉄オタ垂涎ものの企画です。鉄道で遊ぶことと乗ること以外のアクテビティは一切ありません。正直２歳の息子が丸一日鉄道に乗っているだけで飽きないのか疑問があったのですが、鉄道好きだから大丈夫ということで予約しました。

当日は朝９時頃に品川駅に集合し、お座敷列車であるなのはなプラレール号に乗りました。乗っていきなり、プラレール大会の始まりです。どうやらうちの息子のように単に円形のレールで遊んで満足な子供（でっかい子供も？）は少なく、皆さんお座敷列車のテーブル（長さ5m以上ある）一杯にレールを敷き詰めます。うちのように子供のためというよりは自らの趣味で参加しているお父さんも多数いました（笑い）。

プラレールで遊んだ後は、JRのコスチューム（駅長さん仕様かな？白いやつです）を着て記念写真撮影、お弁当とスケジュールが進んでいきます。終着駅である越後湯沢まで結構時間がかるスケジュールだったのですが、乗ってみて理由が判明、この列車ノロノロ運転で、乗降が無いのに駅に停止したりもしばしばでした。まぁプラレールで遊ぶ場所を提供するということでゆっくり走っているんでしょうね。

なぜかプラレールのレールをお片づけしたあとに、プラレール５０周年記念である特急（新幹線ではありません）こだま号の列車セットを頂き、しばらくすると終着駅である越後湯沢に到着しました。

越後湯沢からSLに乗るわけではなく、何とこのなのはな号は、２０分ほどの休憩の後にそのまま元来た線路を戻ります。実は往路で既に復路で乗車するSLと客車を見てしまっています。なんだかこれは頂けない展開ですが、うちの小さい息子にはなんだか分からなかったようで不評は出ませんでした。

帰りは２時間ほどの時間をかけてD51蒸気機関車が引く客車で帰ってきます。息子も私も始めてSLに乗ったので感動でした。特に息子はSLに乗る寸前に寝てしまい、無理やり叩き起こしたのですが、初めて見るSLに寝起きで泣くことも泣く大喜びでした。

日帰りにしてはちょっとお高いツアーでしたが、日ごろママっ子の息子が一日パパと二人で泣くこともなく楽しく旅行できたのはかなりの成果でした。良い思い出が出来たと思います。

家族３人あるいは４人で参加されていた人が多かったので、下の娘が大きくなって出歩けるようになって、同じようなイベントがあれば家族全員で参加したいと思います。

クラウド・コンピューティングのリスク

最近は、仕事関連でクラウド・コンピューティングのセキュリティーについて調査している。クラウド・コンピューティングを導入した、あるいは導入を検討している日本の企業の殆どが導入にあたっての懸念事項にセキュリティーを挙げているようだ。

確かに、データセンターの中でどのような設定がされ、運用されているかがブラックボックスになっているクラウド・コンピューティングのサービスでは利用者が不安を抱くのも仕方が無い。

しかしながら、考えても見るとクラウド・コンピューティングの歴史は浅いが、未だ大規模なセキュリティーに関するインシデントは発生していないのが現実ではないだろうか？（Salesforce.comの顧客リスト漏洩問題があるが、これはデータセンターの問題というよりは社内の顧客情報管理の問題なのであえて除外する）

そこで、もう一度クラウド・コンピューティングのリスクは何か？と考えてみた。最近発生したTwitterやFacebookに対するDoS攻撃の例を考えるとクラウドに対するサイバー・テロ（およびそれによるサービス停止）は、あまり議論されていないリスクだと思う。だが、DoS攻撃は攻撃元からのトラフィックを遮断して被害を少なくすることが可能だし、永遠に攻撃が続くわけではない。そう考えると、実はベンダーロックインの問題が一番リスクなのではないかと思うに至った。

Amazon EC2のようなIaaSの形態であれば、中で動くアプリケーションなどはオンプレミスのものをそのまま使うことが出来るし、データ形式なども通常のサーバーで稼動するものと同じである。しかしながら、PaaS, SaaSではどうだろうか？Salesforce.comなどではCSVでデータを吐き出す機能を持っているが、大量の顧客データをCSVで吐き出して、別のクラウドにインポートして使えるように再構成するのは大変である。PaaS, SaaSではデータ形式などが共通化されていないので、一旦あるクラウド・サービスに乗ってしまったら最後、そのベンダーと心中することを決めなければならない。

このことは、２つのリスクをもたらす。１つはベンダーが倒産したり、サービスをやめてしまった場合に、そのサービスを利用する業務が続行不能になる可能性があること。もう１つは、技術の陳腐化、競争力の低下の可能性である。今でこそクラウドのサービスは時代の最先端というイメージがあるが、それはクラウドのベンダーが最優先に大量の投資をインフラやサービスに投入しているからである。さて、あなたが心中を決めたクラウドのベンダーは永遠に時代の最先端を走れるという保証があるだろうか？ハードウェアの交換やプラットフォームを構成するソフトウェアのアップデートなどをクラウドのベンダーはあなたの企業のIT部門に成り代わってし続けなければならない。サービスを続行する以上、ベンダーはこれらの維持作業をせざるを得ないが、他のベンダーに対して優位性を持ち続けることは資金や他者の破壊的なテクノロジー革命によって困難になるかもしれない。

クラウドサービスの互換性が無い現在、企業が自社のシステムの大部分をクラウドに預けるということは上記のリスクから考えづらいところである。現状の市場の動向を見ても、システムテストのためにAmazon EC2を曲がりする。業務の一部分をSaaSに移行するといった部分的な使用に留まっていることが分かる。日本政府の次世代システムの研究でも、クラウドの間をスイッチする技術というのがテーマとして挙がっているのもなるほどというわけである。

世界のコンピューターが５台になるクラウド時代のためには、企業、あるいは個人が特定のクラウドサービスにロックインされないようにする標準化、互換性維持方法の策定などが不可欠なのである。これがうまくいかないとクラウドはバズワードかつ部分的な普及で終わるだろうし、万が一ユーザーが騙されてしまったとすると、クラウドベンダーにロックインされる、オープンシステム以前の暗黒時代に逆戻りすることになるだろう。

Google Japan Blog: Google Chrome OS のご紹介

GoogleがWebプラットフォームに最適化された独自OSを発表したニュースで今日は持ちきりでしたね。

Google Japan Blog: Google Chrome OS のご紹介

Chromeの速さには感動しているので、Chrome OSが発表されたらすぐに使ってみようと思います。

Linuxベースで作るということですが、Webの実行に最適化してシンプルにするのでセキュリティーも強化されるとのことです。コードの量を減らせば脆弱性・脅威の発生確率は落ちるのでこれは正しいでしょうね。Microsoftが現在のWindowsのセキュリティーレベルを達成するためにどれだけの投資をしたかを考えるとMicrosoftがかわいそうになります（巨大化したOSのコードをさらって穴を潰していくのは非常に大変なはず）。セキュリティー対応と言えば、SSLクライアント証明書対応もお願いしますね＞Googleさん

Chrome OS、ちょっと心配なのがUIです。Chromeの設計思想はブラウザを出来るだけ黒子にするということなので、Chrome OSでもUIは最低限のものでシンプルにすることが予想されますが、AndroidのUIとiPhoneのUIを比べてみてしまうと、現在のAndroidのUI実装のようなちょっとイケていないUIがChromeに持ち込まれたら嫌だなぁと思ってしまいます。Googleのデザイン責任者だったボーマン氏（Twitterに移ってしまった）がいなくなったというのもUIのデザイン面についての不安を煽ります。

それから思ったのが、Chrome OSとサービスを提供するクラウドの関係って、昔のダム端末とメインフレームの関係をそのままにプロトコルをHTTPに持っていったものだってこと。歴史は繰り返すというのはまさにこのことですね。まぁクライアントで出来るケーパビリティが全然違うということはありますけどね（数十年前のテクノロジと最新のものを比べたらかわいそう）。こういったパラダイムの転換によって設計がやり直されすっきりすることは良いことだと思います。シンプルに書き直すことでセキュリティー強化や資源の有効活用による環境問題への対応が図れると思います。私は無駄に複雑で重たい実装が嫌いなのです。

ホッピーが好きだ

IT関係の人は若い人が多いのでホッピーのことを知らない人も多いと思う。会社の飲み会でホッピーが置いてあるお店に行ったことがあって、喜んで飲んでいたら、「それ一体なんですか？」と怪訝そうな顔で見られたことがある。

ホッピーとは発泡酒の祖先みたいなもので、ビールテイストの代替飲料である。ホッピービバレッジという会社が戦後のビールが手に入りづらい頃に作ったものだ。昭和の飲み物である。

ホッピーは単体ではアルコール度が殆ど無い（ゼロではない）ので、焼酎で割って飲むことになる。割る焼酎として最適なのは俗に言うキンミヤ焼酎という甲種の焼酎だ。

ホッピーを飲むきっかけになったのが自分の尿酸値の高さ。悪化すると通風になると言われる高尿酸値症というやつだ。実際に足が痛くなって病院で検査したこともあるのだが、そのときは症状が軽くて通風という診断にまでは至らなかった。しかし、毎年の血液検査では要観察という結果になるので予備軍であるのは間違い無いようだ。

ビールを飲むのが好きなのだが、ご存知の通りビールは尿酸値を上げる因子であるプリン体を多く含むので尿酸値に良くない。（実際には魚卵系がもっと悪くて、私はフォアグラを食べると通風の軽い発作が一発で来る）ホッピーは焼酎で割って飲んだとしてもプリン体がかなり低いので安心して飲めるというわけだ。

正直言って、ホッピーにビールの味をそのまま期待するとがっかりすることになると思う。最近の第二のビール、第三のビールのほうがよほどビールに近い味がすると思う。ホッピーは似非ビールテイストを楽しむ飲み物なのだ。

ちなみにホッピーは今では東京の下町近辺を中心に商売をしているようで、関西でホッピーを飲むのはかなり難しいらしい。（飲み屋でも数件しか扱っていない模様）キンミヤ焼酎なんてものも私は今住んでいる下町に引っ越してくるまでは見たことが無かったのだが、近所のスーパーや酒屋には皆置いてあるので下町限定で需要が多いのだろう。

飲み屋に行くと、良くチューハイのように氷を入れたジョッキとホッピー＋焼酎が出てくることがあるが、これは邪道だそうである。本来はキンキンに冷やしたジョッキあるいはグラスにこれまた凍る寸前まで冷やしたキンミヤ焼酎を入れて、そこにホッピーを注ぐのだそうだ。家ではグラスを冷やすまではしないが氷を入れない飲み方で飲んでいる。近所の酒屋さんでは業販用のホッピー（量が小売のものよりも多い）を配達してくれるので、ケースで買って飲んでいる。

Simplicityについて

IBM丸山さんのブログより

やはり社内の議論で、複雑になりすぎたソフトウェアをどうしたら簡単化できるか、と言う議論がありました。複雑さを扱う戦略のもう一つの方法は、抽象化です。でも、今のソフトウェアは、OSやミドルウェアの抽象化のレイヤーを重ねすぎて、かえって複雑になっているようです。アブストラクション・リーケージ（抽象化の漏洩）という言葉があって、せっかく抽象化のレイヤーを作って実装の詳細は隠したのに、性能やセキュリティやその他のいろいろな非機能要件を追い求めていくと、結局実装が透けて見えてきてしまう、というものです。

私も同じことを感じています。IBMが推進しているJ2EEにしろ、Microsoftの.NETの世界にしろOS、コンテナ、フレームワーク、アプリケーションコードとスタックが複雑化しすぎています。レイヤーごとに抽象化することによって、プログラムコードの開発者に見える部分が単純化したりポーティングを容易にする効果があるのですが、トラブルの際に低いレイヤー（コアダンプの解析、ネットワークのトレースなど）から高いレイヤーまで見ないと行けないような場合にはこの複雑化した環境に本当に苦しめられます。

以前JavaのVM自体をOSにしてしまおうという動きがありました、Javaの上でコードを書くことを前提にするのであれば、下で動くOSをJVMと一体化したほうが最適化出来てシンプルで良いのでは無いかという考え方です。残念ながらこの試みは普及するには至りませんでした。

最近ではクライアントサイドはWeb、言い換えるとブラウザ自体がプラットフォーム化しようとしてきています。プラットフォームの主戦場はミドルウェアの世界からブラウザ上で実行されるコードの世界に移行してきているように思えます。HTML 5で提案されている機能はブラウザ単体でのリッチな機能の実装を目指しており、OSのレイヤをバイパスしようとする意図が見え隠れします。Java OSが目指したようにブラウザ自体がOSであるという考え方になるのかもしれません。

サーバー側はクラウド、クライアント側はHTML 5対応のブラウザという世界になった場合、開発者の労力は下がりますが、私のような裏方の世界を支えるエンジニアはどうなるでしょうか？現在と同じように裏側のスタックが単純化されていないと苦労は変わらないと思います。ただ、あまりにもバリエーションがありすぎる現在の企業システムがある程度テンプレート化したクラウドに移行することによってサポートしなければいけないテクノロジーパターンが減ることは期待出来ると思います。

仕事で触ったスーパーコンピューター 3 RS/6000 SP2

IBMが作った並列UNIXサーバー。SP2というものがあるからにはSP1というモデルも存在した。SP1はPower1チップをCPUに使っていて、SP2はPower2を使っていた。SP1というモデルは殆ど日本に入っていなかった記憶がある。SP2の後、どちらかというと科学技術ではなく商用のパラレルデータベース用などに使うPower PC版のノードも登場して一時期はかなりバリエーションがあった。IBMがチェスの世界チャンピオンをスーパーコンピューターで負かしたことを記憶されてい方もいるかもしれない。あの時使われたがDeep BlueというRS/6000 SP2をベースにチェス用のVLSIを組み込んだシステムであった。

ご覧のような外観なので口が悪い人は墓石と呼んでいた。この当時既に標準規格のラックマウントサーバーがあった(IBMのRS/6000シリーズでもラックマウントのモデルがあった）のだが、なぜこのシリーズだけ独自のラック（ドロワーと呼ぶ）に入っていたのかは不明だ。確か前面と後面がメッシュのドアになっていて開くことが出来たように記憶している。側面はメッシュではなく、板状になっていた。

ネイビーに見える台座の部分にはハイパフォーマンススイッチ(HPS)という高速なネットワーク装置が入っている。これはLANではなく、それぞれのノードを対等につなぐことが出来るアーキテクチャで常時40MBpsのスループットを出すことが出来た。LANでは通常ある程度の損失があるため論理的なスループットと実効スループットでは差があるのだが、HPSでは論理限界とほぼ同じ実効スループットを出すことが出来た。私がこのシステムを触っていた当時は100Base-Tが存在しておらず、Ethernetスイッチもあまり一般的ではなかったので40MBps=320Mbpsというのは驚異的なパフォーマンスだった。後のモデルではSPスイッチという改良版を採用して150MBpsのスループットが出るようになっていた。

このシステムの記憶はとにかく音がうるさかったことと、MPIと呼ばれる並列ライブラリを使った場合の計算速度の速さだった。私が支援していたお客様のシステムは40ノードで構成されていたので当時ではかなりの速度だった。ただ、世界を見ると当時ハワイにあるマウイ大学に世界最大の512ノード構成のTsunamiというシステムがあり、それと比べると．．．だった記憶がある。また、スイッチの故障の際に中に入っているボードを見たところIntelのチップが入っていたのを見て驚いた記憶がある。SCSI用のチップだったのかRISCチップだったのかは記憶が薄く覚えていない。PentiumなどのPC用のチップではなかったことだけは確かだ。

また、SP2のコンソール（通常のRS/6000デスクトップワークステーション）にNCSAモザイクを導入して、当時自分の会社内でも使えなかった専用線接続のインターネットを体験したのも思い出だ。このSP2システムのノウハウを持っている技術者は日本には殆どおらず情報をインターネットから入手するのが有用な手段だったのだ。当時作られたばかりのYahoo!のサイトなどは１画面で表示できるくらいしかサイトが登録されていなかった気がする。まだWWWとGopherを併用していたような時代のことだ。

今ではこのSP2シリーズは廃盤となっており、IBMのスーパーコンピューターではCPUとしてCellだったりOpteronが使われている。OSも独自のAIXではなくLinuxが使われているシステムが多いようだ。2008年末現在で世界最速のスーパーコンピューターは米国資源エネルギー省に導入されているIBM製のもので1ペタFLOPSの計算能力を持つ。CPUはCellとOpteronを組み合わせている。プロセッサの数は20,000個に及ぶそうだ。

仕事で触ったスーパーコンピューター 2 SGI Onyx

シリコングラフィックス社（SGI）のグラフィックスーパーコンピューターです。オニキスと読みます。

現在でこそノートPCレベルでも3Dグラフィックを簡単に表示することが出来ますが、10年以上前は3D専用のグラフィックボードなどがありました。シリコングラフィックス社は初期のハリウッド製作映画のCGを支えたメーカーでもあります。

上の写真だと今イチ大きさが掴みにくいですが、高さは大人の男性位の高さです。上部はメッシュになっていてブロワー（ファン）が上方に熱を排気するようになっています。このマシンの排気音は私がさわったことがあるサーバーの中でもかなり激しいもので電源投入時の迫力はかなりのものでした。

このシステムで何をやっていたかというと、映画作成ではなくバーチャル・リアリティーです。ある種の非常に習得に経験が必要な技能を3D空間に表示される画像とデータグローブを使って疑似体験させて習得させようとするシステムでした。

このシステムで印象的だったのは3Dのスクリーンセーバーです。SGIの独自UNIX OSが動いているのですが、スクリーンセーバーが動くと3Dのポリゴンで描かれたイルカ（クジラ？）が画面上を泳ぎます。今でこそこの手のスクリーンセーバーはノートPCでも実行できるわけで全く目新しくありませんが、当時はカラーで表示出来るノートPCがやっと出てきた時代なので3Dでスクリーンセーバーが表示されるだけで驚きだった訳です。

その後、SGI社は苦難の道を歩んだようです。何度か倒産をして、最近では高密度データセンター向けサーバーで有名なRackableに買収されました。買収された後の会社名としてはSGIが残ったようですが。

これも有名な話ですが、米国Googleの本社は旧SGIの本社だった社屋を使っています。まさにコンピューター業界の栄枯盛衰が見て取れる場所ですね。

仕事で触ったスーパーコンピューター 1 DEC MasPar

10年以上も前の話になるが、スーパーコンピューター（スパコン）を使用する科学技術計算システムを構築し、その後管理・運用をしていたことがある。そのプロジェクトで触ったスパコンの１つがDEC MasParだった。（写真は私が触った実機ではない）

Wikipediaによると、MasParは1996年に製造を止めているので私が触った機械は生産終了寸前の物だったらしい、日本にはそれほど台数が入っていなかったので貴重な経験をしたという訳だ。

このMasPar、内部には16,384個もの計算ユニットを内蔵していて、それぞれのユニットがグリッド状にクロスバースイッチで内部結線されていた。（機械が故障したときにDECのCEの人が中を開けて中を見たのだが恐ろしく配線密度の高い基盤が多層構造で入っていた）最近のWebの記事でMasParというキーワードに引っかかるものがあってびっくりしたのだが、グラフィックプロセッサーで有名なNVIDIAがMasParの技術者を引き抜いたそうだ。GPUを用いてスパコン的な処理をやらせることが最近流行り始めているので、MasParが用いているSIMDというアーキテクチャーを現代のGPUに応用しようとしたわけだ。

個人的にはこのマシンで開発などはしたことが無いが、root権限を持っていたのでシステムの基本的なところは触っていた。しかしながら、このMasParは16,384個の計算ユニットが動いているところにはシェルからは直接触れないようになっている。フロントエンドにDECのUNIXワークステーションがついていて、MasParへのジョブはこのワークステーションからサブミットする仕組みなのだ。したがって、マシンにログインしても普通のUNIXマシンと何も変わらない感覚で特におもしろいことは無かった。しいて挙げるなら、フロントのDECのマシンのコンソールがGUIではなくVTと呼ばれるキャラクター端末であったことが記憶にある。今でもtelnetなどで端末タイプを決めるときにVT-100などと設定することがあるが、VT-100というのは本当にあったハードウェアの端末なのだ。VT-100はかなり昔のものなので、さすがにMasParについているものはVT-3xxと300番台だった記憶がある。ただ、進化版のVT-3xxでも画面はグリーンディスプレイでキーボードは現代では考えられない非常に無骨なものだった記憶がある。タッチして入力するというよりは叩いて入力するという言葉が相応しいキーボードだった。

Paul Van DykのDJプレイの凄さ

Las Vegas Weeklyのインタービューより

I have two computer systems … midi controller keyboards … a custom-designed mixer … [and] several other controllers with me, and that enables me to basically merge what I do as a DJ with what I do when I’m in the studio making music … I’m a musician, and my favorite music is electronic music, and the most common way of presenting it is DJing. I have the possibility of remixing everything live … The whole experience of the track [and] the whole set is much more intense than just listening to somebody mixing two tracks into each other—that could be another reason why you should come and see me.

普通のDJはターンテーブルだったり最近ではCD-JやPCベースのDJツールでDJプレイをするのですが、Paul Van DykはAbleton Liveというスタジオでの音楽作成まで行えるほどのツールでDJプレイをしています。単に曲のデータを再生しているのではなく、曲の構成要素を分解した状態の素材をリアルタイムにつなぎ合わせたりエフェクトをかけたりししているわけです。そのため、彼のプレイのセットリストをリスナーが作っても聞いたことが無い曲が出てくるので”？”マークが入っていることが良くあります。プレイにはMac Book Proを２台使っていますが、１台のMacがコケてももう１台でプレイを続けられるFault Tolerantなシステムになっているところも凄いです。AppleのホームページでもPaul Van Dykの使用機材や環境についての説明があります。

Windowsのフォント

iPhoneを使いだしてから、iPhoneのフォントがあまりにも綺麗なので仕事で使うWindows PC（Windows XP）のフォントの見難さが気になって仕方が無かった。Twitter経由でWindows XPのフォントを綺麗にするGDI++というものがあるということを知り、wikiを見てみたが安定度の観点から仕事用のPCに使うには怖いと思ったので、フォントのみをWindows Vistaで使われるメイリオというものに変えてみた。結果としてはかなり快適である。ただプロポーショナルフォントを使わないミドルウェアなどのフォントが未解決なので何とかする方法を探したい。

お気に入りの焼肉屋

錦糸町の北口駅前に寿恵比呂という焼肉屋があり気に入っている。

錦糸町には叙々苑という有名なチェーン店もあるのだが、寿恵比呂は肉のバリエーションが多いのだ。

一番混み合う19:00位の時間帯は予約をしないと入れないので、必ず予約をして行くようにしている。

先日も家族で訪れたのだが、座敷の隣のテーブルでは合コン（最近は婚活と言うのだろうか？）とおぼしき２０代の男女のグループが楽しそうに焼肉を食べていた。うちの息子は２歳なのだが、誰に似たのか若い女性には目がないようで、隣のグループにいる女の子が気になって仕方が無いらしい。ひたすら愛想を振りまいて、「かわいい」などと言われ様ものなら満面の笑みを返していた。保育園の先生にはそれほど愛想を振りまかないのだが、やはり綺麗な格好をした若いお姉さんが好みなのだろうか？＞息子よ

Paul Van Dykの新アルバム

Best of Paul Van Dyk

ベスト盤だが、先日のTrance Energy 2009でもプレイしたJohnny McDainのボーカルをフィーチャーしたHomeが初収録される。すごく楽しみ。