WEPが暗号の体をなさないのは以前から言われていましたが、問題はWEPが破られること自身よりも「WEPのパスワードが見えてしまうこと」ではないでしょうか。WEPのパスワードを他のものと共通にしている人は多いのでは?
104bitのWEPが10秒、20MBの盗聴で解読できる論文が公開されました。きわめて普通のPCで、普通の環境で実行可能です。まもなくコードも公開されるそうです。もうWEPを「暗号化」として使うことはできません。
うちにはまだ古いPCがあり、ワイアレスLANのカードが40bit WEPにしか対応していなかったりするので接続を躊躇っていたのですが、もうアカンですね...。
このことが一般に波及するまではまだ時間がかかるでしょう。カジュアルクラッカーがまた一つ、いいオモチャを手にしてしまいました。
最近、ビジネスアプリケーションの世界でもDSLが注目を集めているようです。
Martin FowlerもDSLについての本を執筆中で、ドラフトを公開しています。
言語屋出身の私にとって、DSLの世界もなかなか興味深いので、簡単にまとめておきます。デザインパターンと同じように、全く新しい概念というわけではなく、既存の概念をうまく整理したものですね。
なお、Fowlerのサイトを参考にしていますが、本のドラフトに忠実に書いているわけではないので注意してください。
DSLとは
Domain Specific Languageの略。対語はGeneral Purpose Language(汎用言語)。 ある特定の目的のために特別にデザインされた言語。目的を達成するための機能さえあればよく、チューリング完全である必要もない。その代わり、目的を達成するために簡潔に記述できる。
DSLの利点をひとことで言えば、特定の目的のために無駄を省いて簡潔に記述できるところにある。
DSLは新しい概念ではなく、昔からいろいろな形で存在する。 例として、正規表現、SQLなどがある。正規表現は文字列処理というドメイン専用の言語であるし、SQLはデータベース操作が目的の言語である。これらの言語は「何でもできる」言語ではなく、ある特定用途に特化して簡潔に記述できるので、DSLである。
DSLは他の言語(例:Java)の中で使われることもある。 ただし、Javaそれ自体は汎用言語なので、DSLではない。
ライブラリやフレームワークとの違いは、ライブラリが"Push button API"とすれば、DSLは"Fluent API"だということである。 Push Button APIは、通常それ自身で意味的に完備(例:getPrice)であるが、Fluent APIはコンテキストに強く依存する(例:price)ことが多い。
品物を定義し、その値段を設定する例を書いてみる。
Push Button API (Java風味)
Item pen = new Item();
pen.setPrice(100);
Fluent API (Ruby風味)
pen :price => 100
どちらも同じことができるが、Fluent APIはノイズが少ない(余計なことを極力書かない)のが特徴である。
ここでは文字列表記をしているが、DSLは文字列であることもあれば、図表であることもある。MDD(Model Driven Development)で利用するモデル図も一種のDSLとみなすことができる。
DSLの種類
Fowlerの本に準じた種類わけは以下の通り。
External DSL
処理する言語(ホスト言語)とは別に作成したもの。例えば特定目的のスキーマ下のXMLもExternal DSLである(例: Antで使うbuild.xml)。
目的のために構文が自由に決められるため、シンプルに記述できる。 ノイズは通常きわめて少ないが、XMLのように多い場合もある。
当然専用のパーサが必要になる。
Internal DSL (Embedded DSL)
ホスト言語内に記述したもの。動的言語のRubyやLisp、マクロやテンプレートなどのsyntactic sugarが豊富な言語では比較的容易に実現可能だが、Javaなどでも可能。
記述はホスト言語が処理するので、専用のパーサは不要。ただし、ホスト言語の構文を逸脱できないので、ノイズは多くなりがち(括弧、セミコロン、キーワード、一時的な変数など)。
最近のJavaはsyntactic sugarが多く私はあまり好きではないが、この場合は有効に使える。
Javaで実現する場合、Method Chaining、Function Sequence、Annotation、Nested Functionなどのテクニックを使う。 ただ、それぞれ長所・短所があり、どれが良いと一概に言うことはできない。
たとえば、Method Chainingは比較的実現しやすいが、ノイズは結構多くあまり読みやすくない。Function Sequenceをstatic importとともに使うとよりシンプルに記述できるが、グローバルにメソッドや情報を持たなければいけないという弱点もある。
これらのハイブリッドで実現することもある。その場合はノイズを極力減らせるが、記述する内容によって記述方法が変わるので、分かりにくくなる(特に記述しにくくなる)可能性もある 。
Language workbench
DSLによる開発をするための環境を含んだ考え方。DSLは保存される表現、実行されるときの表現、そして編集するときの表現があるが、それらを中心となる抽象表現(≒Semantic Model)で表す。
DSLとそうでないものの境界はあいまい。一般用途の言語でも、特定用途に限って使うように制限されていればDSLと言えることもある。DSLでも、それが本来の目的以上の一般用途に使われればDSLとは言えない。
DSLでは、Semantic Modelと記述形式(構文)、実行形式は分離していることが望ましい。 保守が楽になるためである。
DSLはインタプリタ形式で実行されることもあれば、コンパイラ形式(コード生成)で実行されることもある。 Semantic Modelが分離していれば、これはあまり大きな問題ではない。 インタプリタ形式の場合はSemantic Modelを直接実行できるが、 コンパイラ形式にする場合はコード生成を行うので、 コード生成器の作成労力やパフォーマンス、実行環境(インタプリタを積めるかどうか)などのトレードオフである。
XMLは特定目的のスキーマの上でDSLとみなすこともできるし、そうでない場合もある。 Javaなどではパーサを作るのが簡単なのでXMLをDSLとして使うことが多いかもしれないが、表現上はタグだらけになる(＝ノイズが多くなる)ので読み書きしにくいかもしれない。 これは独自構文のパーサを作る労力とDSLユーザの労力のトレードオフである。XMLを専用の編集ツールで隠蔽する手もあるが、これはLanguage workbenchのアプローチに近くなる。
コミュニケーションツールとしてのDSL
DSLはコミュニケーションツールとしての側面も持つ。
開発者にとってコミュニケーションを容易にすることももちろんだが、ユーザ(特にドメインエキスパート)とのコミュニケーションを容易にすることも可能である。 この場合、ドメインエキスパートはDSLを書くよりも読むことがきることがより重要。 もちろん書ければそれに越したことはないが、ドメインエキスパートはプログラマではないことに注意。
DSLを使うべきとき、そうでないとき
DSLの開発にはコストがかかるので、それに見合わないときは作るべきではない。
また、利用者がDSLを覚えるのに苦労するようでも意味がない。 複雑なライブラリの上にDSLを作って簡単に使えるようにする、などのメリットがなければならない。
機能範囲を絞ることも重要。 悪い例はAntで、相次ぐ機能拡張でわかりにくくなってしまった。
DSLが複雑なときは、場合によっては屋上屋を重ねることも有用。 以前から、設定ファイル(一種のDSL)ではこのようなことが行われてきた。 例えばsendmail.conf->CF、Makefile->imakefileなど。
DSLの作り方
DSLの作り方には、既存のライブラリのAPIに屋上屋を重ねる(ラップする)方法、ドメインエキスパートと作るモデルから入る方法、言語仕様から入る方法(特にembeddedの場合)などがある。
既存の言語のままでもDSLと言えることもある。
たとえば、COBOLのCOPY句を読み込んでJavaとのインタフェース用のプログラムを出力する場合、このCOPY句をJavaとのインタフェース用DSLと「みなす」ことも可能(COBOL言語仕様の一部のみを特定目的で使っていることがポイント)。
Fowlerの本では、パーサやコンパイラ、コード生成などについても解説していますが、この辺は特に目新しいことはないので知ってる人は読む必要はないでしょう。
以前のブログで書いたように、Eee PC用のSSDやらSDカードをストライピングするものやら、SSDの世界もいろいろアプローチが花盛りです。
しかし、FMV-LOOX P70TやVAIO Uやら、1.8インチパラレルATA(東芝タイプ)のコネクタを持つマシンは、SSDはおろかHDDもアップグレードパスが既に切れている状態です。
CFから1.8IDEに変換する基板はありますね。これは手軽ではありますが、容量が32GBまでですね。スピードもあまり出なさそうです。
ZIFタイプのコネクタの場合、コネクタ形状のみの問題なので、スペースさえあれば無理やり変換できなくもありません。Samsungの基板タイプの1.8インチSSDなら、ZIF→IDE変換基板があります。実際換装した強者もいるようです。40本のフレキを接続するのが骨ですが。
と思ったら1.8ZIF→1.8IDE変換基板を見つけました。あーやっぱりニーズがあるから作るわな。でもこれ、ZIFのSSDやらHDDで一緒に本体に入るもの、ありますかね? 少なくともHDDは無理そう。基板タイプのSSDなら何とかなるかな?
最近になってさらに小さい基板タイプのSSDが出たようです。インタフェースはSATAなのですが、とにかく本体サイズが小さいので、SATA→IDE変換基板もひょっとすると押し込めるかもしれません。
(16 Nov. 2008追記) Green Houseからそのまんまの仕様(1.8インチパラレルATA)のデバイスが出ました。
ファイルシステムのアクセス方法や、コマンドプロンプトからの引数の受け渡し方法などを書いておきました。
Sourceforgeで参照できるようにしてあります。
それと、普通のユーザーズガイドをこのサイトに出してませんでしたので、以下に置いておきます。
アダプタの販売はこちらで扱っていますのでよろしくお願いします。
私は子どもの頃は飛行機に乗る機会に恵まれず、初めて飛行機に乗ったのは確か就職してからでした。
そのため、国内線・国際線とも大部分は仕事でのフライトです。最初の頃はマイレージという概念も知らなかったので、会員にもならずマイルを無駄に捨ててました。ああもったいない。
2001年～2002年にアメリカに留学していたので、マイレージをANAに固めて それなりに飛んだのですが、思ったほどマイルは貯まりませんでしたね。 一部American Airlinesで飛んだせいもありますが。
だいたいマイルが貯まっても、うまく使う機会がなくて、 結局20,000マイルで30,000円分の「ANAご利用券」に変えて(現在はレートが悪くなった) ANAホテルに泊まる、というのが関の山でした。
日本に戻ってから、仕事・プライベート双方で乗る回数は増えたのですが、
国内ではマイルがぜんぜん貯まらないのですね。当時のANAの「ブロンズ」ステータス
の基準が、1年で「30,000マイル」または「10,000マイルかつ30回搭乗」でした。
私は年間の搭乗が20回ちょっとで距離が20,000マイル程度でどちらの基準にも届かず。惜しい! 結局ステータスには縁なく過ごしました。
もっとも、たまの海外出張時には、マイルとは無関係に片道をビジネスクラスにアップグレードできる機会に恵まれていたので、それはそれで良かったのですが。 ていうか充分すぎ?
ところが、今年になって転機を迎えました。イギリスに赴任したためです。
1月にロンドンに事前出張し、その後国内線も少し乗りましたが、 5月に別件でドイツ出張、同じく5月に赴任しました。 私の働いている会社では通常出張はPEXまたは格安ですが、 赴任・帰任のフライトはフルビジネスに乗せてもらえるので、 これで一気に30,000ポイント越え(現在はステータス基準のポイントはマイルとは別計算)。 念願のブロンズステータス達成です。
それからしばらく英国から出ませんでしたが、9月に仕事で日本に2往復しました。 これで50,000ポイント越えで晴れてプラチナステータス達成! 同じステータスでもブロンズとプラチナ以上では 雲泥の差です。つい先日ブロンズになって喜んでたのに、あー人の欲望は果てしない...。
| ブロンズ | プラチナ以上 | |
| マイルボーナス | 搭乗分+フルマイルの50% | 搭乗分+フルマイルの100%(*1) |
| ビジネスクラスカウンターの利用 | 不可 | 可(*2) |
| 優先搭乗および優先手荷物引渡し | 不可 | 可 |
| ラウンジの利用 | 不可(*3) | 可 |
| ファーストトラック(成田空港) | 不可 | 可 |
| ステータスの永続化 | 不可 | 可 |
| 割引航空券でのプレミアムエコノミー搭乗 (当日空きがあれば) | 不可 | 可 |
(*1) ダイヤモンドの場合+125%
(*2) ダイヤモンドの場合ファーストクラスカウンターの利用可
(*3) 国内線ラウンジの場合1,000マイルを支払って利用可
主な違いはこんなところでしょうか。
獲得できるマイルは、東京・ロンドン線(片道)の場合、 フルエコノミーが6,220マイル、割引チケットが4,354マイルなのですが、 ボーナスを入れるとブロンズなら9,330(フル)/7,464(割引)、 プラチナだと実に12,440(フル)/10,574(割引)となります。
プラチナステータスで往復すると、それだけで21,148～24,880マイルを獲得できる ことになります。
現在東京・ロンドン線のビジネスクラスへの片道アップグレードに必要なマイルは
28,000マイル(以前より少々値上がりした)なので、
少なくとも3回搭乗ごとに1回はアップグレードできてしまう計算になります。
9月の2回目の日本訪問時は、行き(ロンドン→東京)のフライトでプラチナ基準を達成したので、帰りは成田空港でファーストトラックの利用やら プレミアムエコノミーへのアップグレードやら、 さっそく恩恵を受けることができました。
成田空港のファーストトラック(優先セキュリティゲート)は、
平会員だとビジネスクラスですら通れないので、
なんだかすごく優遇されている気分です。
空いているだけでなく、ゲート自体も木目調で、
殺風景な通常ゲートとは大違いでした。
来週、また仕事で訪日します。 行きはプレミアムエコノミー、帰りはビジネスにアップグレードしました。 以前ロンドンから出るフライトをマイルでアップグレードしたら、 40ポンドの追加の税金(ぜいたく税?)を取られたので、 ビジネスクラスは日本からのフライトのほうがいいですね。 フライト時間もロンドンからよりもおよそ1時間ほど長くかかりますし。
英紙The Guardianによると、Free Software Foundationの設立者である Richard Stallmanが「クラウドコンピューティングは馬鹿馬鹿しい」と言っています。
記事を読んでみると、どうもあまり大したことは言っていないようです。 私が読んだ限りで彼の主張を整理してみると、次に集約できます。
確かにこの2点は事実でしょう。まぁ、誇大広告である点はこの業界では相変わらずなので、わかっている人にはあまり影響はないと思います。
2点目も現状ではこの傾向があるのは確かです。我々はメールやらファイルシェアリングやら、既にさまざまな情報を外部に依存していますね。 私がWebサーバやメールサーバを自宅で運用し、外部依存したがらない理由もここにあります。まぁ、その代わり出張中に落ちてたりしますが...。
そしてこう続きます。
「Webアプリケーションを使ってコンピュータの制御権を失うのは、プロプライエタリなソフトを使うのと同じくらい良くないことだ。自分自身のコンピュータで、フリーなプログラムを使ってコンピューティングすべきだ」
ああぁ、やっぱり出ましたか。別にFSFの理想に反対するつもりはないんですが、 フリー「でなければいけない」というStallmanの思想には共感できません。 みんながみんなアンタのようなGeekじゃないんだから、 いちいちフリーにしろと言われる筋合いはないと。
ちなみに、最近Dellが「cloud computing」という用語を自社の登録商標にしようとして拒絶されています。なんつーか、浅ましいですねぇ。
PSGによるPCM再生の問題
PSG(AY-3-8910)では、音量レジスタを高速に操作することによって任意の音声波形の再生をすることができます。PCM相当のことができるわけですね。
この辺はPSGPCMやSSGPCMといった技術が確立しているので、細かい説明は省きます。 Wikipediaなどには「PSGで高音質のPCMを再生したものはほとんど皆無」とあります。確かにそうなのですが、不可能ではないのです。それにはPSGの性質を理解する必要があります。
PCM再生の音質は標本化周波数(サンプリング周波数)と量子化ビット数により決まります。 大雑把に言うと、PSGでは、標本化周波数は1秒間に音量レジスタを変化させる回数、 量子化ビット数は音量レジスタのとりうる値です。
ここで、PSG(AY-3-8910)の音量レジスタは0～15の4ビットの値をとります。
そのため、PSGでPCMを再生するときに"4ビットPCM"といったりすることがありますが、 実はこれは通常のPCMでいうビット数の考え方からすると誤りです。 というのは、PSGにおける音量レジスタの値と音量の関係はリニアではなく、 対数値であるためです。
nを音量レジスタの値とすると、出力yは以下の式で表せます。
y = 2^-((15-n)/2) (if n > 0) y = 0 (if n == 0)
そのため、特に大音量域での解像度が極端に低くなります。
上図で、横軸は音量レジスタに与える値で、縦軸は音量です。
もしデータが上位半分以上の音量域をメインとして構成されていた場合、0, 0.5, 約0.7, 1の4つの値しか取れず、実質2ビットになってしまうわけです。 これが、「PSGではまともなPCM再生はできない」と言われてしまう所以です。
実機での再生結果
ところで、PSGには3つのチャネルがあります。発音時はこの3チャネルを合わせるわけですが、この合わせ方とは3つのアナログ信号出力を単に合成するだけです。
このため、この仕様をうまく使うと、粒度の荒い大音領域と細かい小音領域を2つのチャネルで再生し、合成することによってビットの低さを補えるのです。
たとえば、0.5(n=13)と約0.03(n=5)の2チャネルを合わせて約0.53を出力したりすることができる、というわけです。
この方法を3チャネルで使うことにより、計608種類の異なる音量を発生させることができます。これは9ビット強に相当します(以前3チャネルで12ビット相当と他サイトで書いていましたが、厳密には誤りで、およそ9ビットが正しいようです)。
ただ、先ほども説明したように、出力は対数値なので、リニアに9ビットの出力値を得られるというわけではありません。その辺はエンコード時に上手に計算してあげる必要があります。
これ、MSX用にViterbiアルゴリズムとinterpolationを使って高音質なエンコードをした人がいて、PC-6001でも応用ができます。それが私がやってみた実験です。
実のところ、もとのMSX版の完成度が高いため、私がわざわざやったことは大したことはないのです。 まぁ、PC-6001でここまでやった人はいないだろうということで。
この文章は、以下を大いに参考にさせていただきました。
http://map.tni.nl/articles/psg_sample.php
こんな感じです。音質そんなに悪くないでしょ?
ポイントは以下のようなところです。続いて、ムービーエンコーダとプレーヤをリリースします。
それぞれ中にREADMEがありますので参考にしてください。
プレーヤですが、実はこのままでは再コンパイルできません。Hexameterをダウンロードし、適切にMakefileを設定しなおす必要があります。私の環境のままアーカイブにしてしまったためなのですが、直しているといつまでたってもアップロードできないので、とりあえずまずはこれで許してください。
Hexameter 2.1.2をリリースしました.
Sourcceforgeからダウンロードできます.
変わったのは、SDOS 1.1用のテンプレートを用意したことだけですのでたいして大きな変化ではないですが、もしSDカードアダプタをお持ちの方でSDカードをアクセスしたいという奇特な(?)方がいらっしゃればぜひご利用ください. また、SDOS開発時に作成したいろいろ有用なルーチンも用意してますので、良かったら使ってみてください. 戦士カートリッジ版、1M ROMアダプタ版双方で動作するはずです.
