2008年10月1日
仕事で XML 形式のフォーマットを定義することになりまして、せっかくだからと DTD も書いてみることにしました。
今までは内部でしか使わなかったので特に必要性を感じなかったんですが、今度は外部とやりとりをすることになったので、チェックも兼ねて書いてみることにした次第です。
XML 形式のフォーマットを定義する方法には、おもに DTD と XML Schema の二種類があります。
DTD にはいろいろと問題点が指摘されていて、それを置き換えるために生まれたのが XML Schema ですが、それでもなお DTD を採用したのは、私が慣れているからw
HTML4.0 の頃はふつーに読んでたし。
ところがよくよく思い出してみると、 XML 時代の DTD って読んだことがないんですよ。
XHTML に移行したときも HTML4.01 との差分だけ覚えたんで、その DTD を読むことはしませんでした。
そこで復習もかねて HTML4.01 と XHTML1.0 の DTD を比較してみると……全然違うやん。
一番の違いは、開始／終了タグの省略可否。
# XML はどちらも省略不可だから、削られて当然だわな
そして、コメントの位置。
# 要素型宣言とかの中にコメント入れるよか、処理は楽だわな
てことで、XML の DTD について勉強し直すことになりました。
……うん、まぁ、だいたいわかった。
理解の甘い箇所がいくつもありますが、そこは書きながら調べるだけのこと。
何とかなるでしょ。
XML 文書と DTD を連携して検証するツールを見つけましたので、チェックも便利です。
http://park15.wakwak.com/~yoshitomo/junk/index.html
↑の「XML 検証インターフェース」
ダウンロードして、検証したい XML ファイルを D&D するだけ。
しかし DTD 最大の欠点は、文字種の制約をかけられないことでしょうね。
たとえば値として数値だけを許したい場合でも「文字列」としか表現できません。
真偽値は列挙型で代用できますのでまだマシですが、せめて整数型とか実数型ぐらいは定義しておいてほしかったです。
パターンマッチまであれば理想ですね。
これは XML Schema に移行することも考えた方がいいかなぁ。
2008年8月15日
わんくま同盟 大阪勉強会 #22 に参加します。
一番の注目セッションは Ognac さんの「正規表現を活用しよう」。
Perl使いとしては、正規表現は外せない要素ですからね。
どんな話を聞けるか、楽しみにしています。
その他、セッションの予定は以下の通りです。
- 10:40 ～ 10:50 わんくまについて
- 10:50 ～ 12:00 「Windows MobileでHello World!!」CH3COOH Lv1くまー
- 12:00 ～ 12:30 おひるごはん♪
- 12:30 ～ 13:00 ライトニングトーク
- 13:00 ～ 13:50 「Windows Mobile を自在に操る」伊勢 シン Lv2くまー
- 14:00 ～ 14:50 「正規表現を活用しよう」Ognac Lv2.25くまー
- 15:10 ～ 16:00 「未定」ぽぴ王子 Lv?くまー
- 16:10 ～ 17:00 「今更ながらだけど、WCFと遊んでみよう＾＾」ちゅき Lv2くまー
- 17:30 ～ 懇親会
私は懇親会に参加せず、そのまま京都に移動します。
目的は RikaTan 誌の京都オフ会があるので、そちらに参加。
2008年7月17日
先週末の土曜日(7月12日)に開催されたわんくま同盟東京勉強会で、ライトニングトークの一枠をいただきました。
ネタはラプターを肴にステルスの原理について。
プログラマーのコミュニティには全然関係ないネタにもかかわらず、ご静聴くださった皆様、ありがとうございました。
その際のスライド資料をアップしましたので、よろしければご覧ください。
話した内容を一言でまとめれば、ラプターの機体は平行線を基調として設計されているということです。
しかしεπιστημηさんからの指摘通り、曲面を使っている箇所もあります。
特にコクピット周りが顕著ですが、これは空力性能の方を優先した結果です。
ラプターの場合、ステルス性能のほかに様々な要求がありました。
超音速で長時間巡航するスーパークルーズ、高い空戦能力とそれを保証する運動性能などなど。
空力特性を考えると、直線的なデザインが必要なステルス形状とは相反する要求です。
そこでステルス性能を多少犠牲にしてでも、空力性能を引き上げる方を取った箇所が多々あるように見受けられます。
もちろん曲面には、わずかとはいえその方向に電波をはじき返すという性質がありますので、使わないに越したことはありません。
そこで、コンピュータシミュレーションによってステルス性能と空力性能が両立する形状が探られました。
それがラプターのような、一見すると普通の飛行機のような形状です。
しかし詳細に見ると、相反する要求を恐ろしく高次元で両立しているように見えます。
たとえばラプターのフロントショットを見ますと、コクピット周りですら平行四辺形を意識しており、曲面の部分を極力減らすデザインであることがわかります。
余談ながら、F-117 ナイトホークの頃はコンピュータの能力が低く、平面でのシミュレーションしかできなかったためにあのような形になりました。
さて、επιστημηさんから形状以外のステルス技術についてご要望がありました。
「電波を吸収する」については、図面を引いてみたら想定とはまったく違う結果が出てしまいましたので、今回は見送った次第です。
しかしあまりにも納得がいかないので、識者のご意見を伺うためにもエントリとしてあげたいと思います。
「電波を打ち消す」についてはビルなどで導入実績があるようですが、原理的に考えて戦闘機に導入できるとは思えませんでした。
てことで、こちらはまともに調べてないです。
2008年7月14日
もっとも単純なカルボン酸はギ酸です。
先日の懇親会の時に酢酸と言ってしまいましたが、思いっきり間違いです。
どなたが指摘してくださったのかわかりませんが、申し訳ありませんでした。
# 何一ついいわけできねぇ……
カルボキシル基(COOH)を持つ化合物をカルボン酸といいますが、カルボキシル基に水素(H)が直接結合したものがギ酸(HCOOH)です。
カルボキシル基にメチル基(CH3)がくっつくと酢酸(CH3COOH)になります。
従って、ギ酸の方が酢酸よりも単純なカルボン酸です。
これだけだとエントリとして寂しいので、ギ酸をネタに一つ。
ギ酸は蟻酸と書きますが、その名の通りアリから発見された酸です。
蟻塚から酸性の蒸気が出ていたので、アリを蒸留してみたら得られたそうです。
工業的には様々な用途がありますが、最近の研究でギ酸を使って水素を運搬する方法が提唱されましたのでご紹介します。
二酸化炭素を一切出さないクリーンな次世代燃料として、水素は重要な位置を占めています。
水素と酸素を反応させて電力を得る燃料電池はもちろん、水素を直接燃やす水素ロータリーエンジンも開発されています。
# マツダのRX-8ハイドロジェンREなど
しかし、水素は貯蔵が非常に難しい物質です。
液体水素は温度が非常に低いため、大がかりな貯蔵施設が必要になります。
かといって気体状態では体積が液体状態の1000倍以上に増えますので、どんなに圧縮しても少量しか運ぶことができません。
# 実用的なタンクでは、せいぜい10気圧程度までしか耐えられない
ところで液体を高温高圧にすると、液体と気体の区別がつかなくなる「超臨界」という状態になります。
水の場合は 374℃、220気圧以上で超臨界状態になりますが、このあたりの領域の水(H2O)に一酸化炭素(CO)を加えると、ギ酸(HCOOH)が生成することがわかりました。
さらに温度と圧力の条件を変えると、今度はギ酸(HCOOH)を二酸化炭素(CO2)と水素(H2)に分解することができます。
ギ酸は常温で液体ですから、貯蔵に大がかりな施設は必要ありません。
また、タンクローリーで運ぶこともできます。
ということはギ酸を化学的な水素タンクに見立てることで、水素の貯蔵や運搬の問題が一気に解決する可能性が出てきたわけです。
しかしギ酸は人体に刺激性が強く、保護衣を着用することが推奨されています。
製品データシートには「強酸性水溶液であり、目や皮膚に付着すると腐食・刺激性を示し、甚だしい場合は、失明することがある」とありますので、気軽に扱える物質ではありません。
従って実際に使用できるようになるにはまだまだ長い道のりが必要ですが、将来が楽しみな研究だと思います。
参考文献
2008年7月8日
VisualStudio2005 の C# で "==" を定義したクラスを作ったんですが、それをジェネリッククラス内で使おうとしたら呼び出されませんでした。
裸で使えば問題なく動作するんですが、ジェネリック変数同士では Object.operator== が呼び出されているように思えます。
サンプルコード
class Program
{
static void Main( string[] args )
{
SampleData data0 = new SampleData();
SampleData data1 = new SampleData();
bool ret_operator = ( data0 == data1 );
GenericData<SampleData> gen_data = new GenericData<SampleData>();
gen_data.data1 = new SampleData();
gen_data.data2 = new SampleData();
gen_data.OperatorEq();
}
}
class GenericData<TYPE> where TYPE : class
{
public TYPE data1 = null;
public TYPE data2 = null;
public void OperatorEq()
{
Console.WriteLine( "GenericData.OperatorEq Start" );
bool ret_operator = ( data1 == data2 );
Console.WriteLine( "GenericData.OperatorEq End" );
}
}
class SampleData
{
public static bool operator ==( SampleData lhs, SampleData rhs )
{
Console.WriteLine( "SampleData.operator==" );
return true;
}
public static bool operator !=( SampleData lhs, SampleData rhs )
{
Console.WriteLine( "SampleData.operator!=" );
return !( lhs == rhs );
}
public override int GetHashCode()
{
return base.GetHashCode();
}
public override bool Equals( object obj )
{
return base.Equals( obj );
}
}
結果
SampleData.operator==
GenericData.OperatorEq Start
GenericData.OperatorEq End
2008年5月20日
初回からたくさんのコメントをいただき、ありがとうございました。
これだけのページビューを見せられると、いきなり放置というわけにもいかないという奇妙なプレッシャーを感じております。
さて某所のアクセスログを見ていたら、暦に関するエントリがやたら参照されていました。
ということで、こちらでも少しまとめ直してみたいと思います。
現在日本で使用されているグレゴリオ暦は、以下のルールで一暦年が決まります。
- 西暦が4で割り切れる年は閏年とし、閏日を加える。
- ただし、100で割り切れる年は閏年ではない。
- しかし、400で割り切れる年は閏年である。
これにより一暦年の平均は365.2425日となりますから、一太陽年の実測値である365.2422日とかなりの精度(一年に平均約26秒のズレ)で一致します。
このズレの値は1日分に累積するまでに約3323年を要しますから、十分な精度といえるでしょう。
さて、ルール2から1900年や2100年は閏年でないことがわかります。
しかし、2000年はルール3により閏年です。
この辺がいまいち理解されていなかったのか、2000年の2月29日には郵便貯金ATMのうち約1200台が停止したり、アメダスが誤った観測値を通報するなどのトラブルが発生しました。
ところで「2099年までは正しく動作する」と発表したところもあったと記憶していますが、これは閏年のルールを理解していないだけで、とても褒められたものではないと思います。
さてこのグレゴリオ暦は1582年に時の教皇グレゴリウス13世によって発布されています。
それ以前に使われていた暦はユリウス暦といいますが、こちらはローマ皇帝ユリウス・シーザーによって紀元前45年に公布されていますので、実に1600年以上も使われ続けたことになります。
ユリウス暦は先述の通り紀元前に成立した古い暦ですが、平年を365日として4年に一度の割合で閏日を加えるというルールで運用されていました。
つまり古代ローマ人は、365.25日で太陽が同じ位置に戻ってくる事実を知っていたわけです。
2000年以上も昔にこれほどの精度で天体観測ができたという点は、驚愕に値すると思います。
このあと閏秒の話につなげようと思ったんですが、長くなりそうなので次の機会に回します。
2008年5月18日
ども、はじめまして。
このたびご縁がありまして、わんくま同盟さんに加えていただくことになりました。
で、このようなスペースをいただきましたので、テスト投稿もかねて自己紹介をさせていただきます。
ハンドルネームは guicheng と言います。
これは本名の下の名前を北京語読みした場合の発音記号でして、無理矢理書き表すなら「ぐぉいつぇん」となるでしょうか。ちなみにピンインは2声の3声です。
しかし普通の日本人では発音不可能なのも事実でして、「ぐいちぇん」「ごいつん」「ぐっちぇん」「ぐー」などなど、好きなように呼ばれてます。
ああ、一人だけ「うぐぅ」と呼んだ人がいましたっけ。
最近では「ぐいちぇん」が多いですし、私もそうしてます。
辞書登録は「ぐー」ですが。
職業はプログラマで、主に AutoCAD のカスタマイズの仕事を担当しています。
が、社内の便利屋扱いされるケースも多数。
サウンドエディタとか、帳票アプリとか、 Web アプリとか、いろいろなところのヘルプに入ったり作ったりしてます。
ところが学生時代は分析化学を専攻してまして、水溶液中の超微量金属の定量で修士号もいただいています。
従って科学、特に化学系については、通り一遍のことはわかるつもりでいます。
もっとも実際にはできの悪い学生で、先生方にはひたすらご迷惑をおかけしましたが。
先日、研究室に挨拶に行ったら教授からその辺を掘り出されて、冷や汗をかいた次第です。
趣味は天文と言っていますが低軌道から太陽系外縁あたりが興味の対象でして、ロケットとか探査機とかいったメカものを追っかけてます。
従って星座などは全然わからなかったり。
先日は星の名前を聞かれて、大嘘ぶっこいたこともあります。
てことで、このブログはサイエンスとプログラムがごたまぜという、訳のわからないものになると思います。
そちら関係に興味のある方は、よろしくおつきあいください。