« 2005年10月 | メイン | 2005年12月 »
2005年11月30日
Project Amethyst ４
相手先のアドレスを解決できたので、テストと挨拶代わりにパケットを送信、現在は応答待ち。基本的にタイムアウトは長めで・・・。非同期通信なので常に待ち受けが必要である。
投稿者 abiru : 01:45 | コメント (0) | トラックバック
2005年11月29日
Project Amethyst ３
デフォルトゲートウェイから応答パケットが来た。ひとまずアドレスの解決には成功！会社から帰ったらユニキャストパケットを相手側へ直接送信してみよう。デフォルトゲートウェイから送信されて来た付加情報によると、相手先のノードでは、現在、あまり優先度の高いコネクションを張る予定は無いそうだが、まあ、通常のパケットには応答してくれるでしょう。
投稿者 abiru : 12:57 | コメント (0) | トラックバック
シークレットバトン
mixi.jpで友人から回ってきたバトンです。これは設問を知っている人だけがニヤリとするためのちょっとしたお遊び、他の人たちはmixi.jpの中で日記を付けているからいいけど、私のように外部のブログを設定していると、ちと恥ずかしい。
①言葉の定義でモメるでしょうけど、基本的には許せません。
②かわいいと思います。でも無批判な人は物足りないでしょう。
③下は５上は１０ぐらいまで守備範囲です。基本的に上がいいです。
④妥協不可能な価値観の相違にぶつかった時かな。
⑤何かにこだわりを持っていない人、ポリシーの無い人
⑥特にないな。その人が好きなものなら何でもいいですよ。
⑦ない。
⑧ない。
⑨行動あるのみ。
⑩ない。
⑪私とデートしましょう。
⑫ない。
⑬ない。ちゃんと伝えた事がないから。
⑭やった事が無いのでわかりません。
⑮お断りします。
⑯ない。
⑰ -
⑱わかりません。本当に経験が無いので。
⑲新しい発見をさせてくれる一言
⑳回せません。
う～ん、ハッキリ言って俺向きじゃないバトンですな。（ｗ
投稿者 abiru : 12:50 | コメント (2) | トラックバック
Project Amethyst ２
今日はついに待ちきれず両方のアドレスを解決できるデフォルトゲートウェイにパケットを送信した。こちらのアドレスを相手側へ通知するようにリクエストを送信したのだ。これで相手側ノードからこちら側へ直接パケットを返信してくれば、３ウェイハンドシェイクをしてTCPコネクションが確立できるかもしれない。こちら側での処理にミスがなければ・・・・。いや、なんせこういう形でのコミュニケーションシステムは私には経験がないのでドキドキなんである。コーディネーターの計画を無視してこちらがパケットを投げたので、これはみんなが騒ぎ出すかもね。まあ、みんな俺が勝手に作業を進める事を期待しているフシがあるので、これもまあ、よし。ということで♪ひとまずデフォルトゲートウェイからは処理を開始した旨のメッセージが返ってきた。あとは相手側からパケットが返ってくるのをじっと待つしかない。ここでパケットが返って来なかったら、いきなりプロジェクトが頓挫するかもね〜！でも、なんとしてもこの初回の通信は成功させたいからパケットが返ってくるまでのタイムアウト値は長めに確保しておこうっと。
（暗号）
投稿者 abiru : 02:43 | コメント (2) | トラックバック
2005年11月27日
Project Amethyst
友人宅に招かれて夕食だった。食後、時間を経て話題は「Project Amethyst」の話題になる。話しは更に流れて「人を好きになるという事はどういう事か。」というような思春期の中学生みたいな話しで盛り上がる。これが全員２０代後半の連中なのだから、ある意味凄い。というか「イタイ」のかもしれない。でも全員至って大まじめな議論だ。
話しがそれたので、話題を「Project Amethyst」に戻す。私の意見としてはゲートウェイが双方のアドレスを解決してくれれば、あとは２ノード間で通信が可能になるから後は余計な中継役を挟まずに管制権を全てこちらに渡して欲しいと要望したが、そういう事でも無いらしい。
まあいい、とにかく今私は「変化」を求めている。人生は箱を開けてみるまではわからないのだ。結果が大失敗に終わっても悔いはないだろう。今回は友人の提案を最大限受け入れてみようではないか。
（暗号）
投稿者 abiru : 23:36 | コメント (3) | トラックバック
2005年11月26日
ソフトウェアベンダの評価基準に関する考察
もう1ヶ月近くも前のエントリになるが、ITMediaのオルタナティブ・ブログに以下のようなエントリがあった。
たしかに毎回リリースされる脆弱性やバグの情報を見ていると「本当に真面目な設計・開発してるの？」と疑問を抱きたくなる気持ちは理解できなくもない。しかし「修正パッチごとに1ドル返金」とは、少々乱暴過ぎる提案ではないだろうか。
仮にこのような制度が一般化した場合、以下のようなデメリットが予測される。
・リスク・コストが高いので新しいソフトウェアが開発されない
・OS、ミドルウェア、開発ツール、その他関連ベンダが責任転嫁合戦
・資金力の無い中小ベンダの撤退
・脆弱性／不具合の情報が隠蔽される
・ソフトウェアの値段が予め高く設定される
・パッチで赤字になる前にメーカサポートが打ち切りになる
・新バージョンへの移行・買い替えを強制される
・何があっても仕様と言い張る
「修正パッチごとに1ドル返金」という文面を見るとユーザ本位の提案のようにも感じられ、同時にソフトの品質管理に取り組まないベンダに対する警鐘であるとも思えるが、やはり「修正パッチごとに1ドル返金」は無理のある提案である。上記のようなデメリットを考慮すると結局、巡り巡ってユーザの側に不利益が押しつけられてしまう。
たしかに白物家電や自動車といった従来の工業製品と比較するとソフトウェアの欠陥は多く感じられるのかもしれない。しかし、ひとつの処理をする場合でも、ハードウェア、BIOS、OS、各種ドライバ、ミドルウェア、アプリケーションと無数の多層構造があり、なおかつネットワーク化によってそれらのソフトウェアが有機的に連携したり、疎結合関係を持っているコンピュータシステムの分野においては、残念ながら、製品初期出荷段階で従来の工業製品のようなクオリティを維持・管理するための成功法則が充分に確立されていない状況なのである。
私はこの現状を過渡的な状況であり、いつかは改善され、他の工業製品と同等程度の動作品質が保障できる時代が到来するものと信じたい。
また、ソフトウェア業界で働く者としてそのような理想的な時代を実現するために自分が果たすべき役割についても深く考えなければならないと感じている。
現在ような混沌とした状況下で、ユーザもベンダもどのような方法を取れば理想に近づけるか試行錯誤を繰り返しているのが、今の状態なのだと思う。現状のソフトウェア業界には無数の未解決問題が残っているものの、既存の工業製品の長い歴史とコンピュータの浅い歴史を比較すれば、ユーザもベンダも精一杯の努力をして、問題があるものの、一定の成果を出せていると思う。現状は決して理想的な状況ではないけれど、多くのユーザやベンダの努力によって理想に向かって一歩ずつ前進している状態だと思う。
近年、コンピュータシステムの安定性や堅牢性が注目されるようになり、製品の不具合情報や脆弱性情報を積極的に公開し、パッチを提供するベンダの姿勢をユーザも評価するようになりつつある。また、ベンダの側もパッチのリリースを不定期ではなく、一定の間隔でリリースしてユーザの混乱を回避しようとするなど努力の痕跡が見られる。
一方、最近になって私が感じることは、はじめからセキュアでバグの少ないソフトウェアを開発するという事に対する努力とそれに対する評価が充分ではないという事である。
たしかにソフトのバグを認め、パッチをリリースする姿勢は評価できるが、パッチが全ての免罪符になるとは思わない。パッチを適用しないで済むソフトウェアであれば、それに越した事は無いのである。
これから先、ソフトウェアが人類の生活に与える影響力は拡大して行くでしょう。その時、バグや脆弱性が少なく品質の高いソフトウェアが正しく評価される世界が実現する必要がある。
バグや脆弱性が存在した事はマイナス評価のポイントになるが、正確に不具合情報を公開し、的確にパッチを提供した事はプラス評価されるべきだ。そしてはじめからバグや脆弱性が少ない事はパッチを提供する事よりも高い評価を受けられるような状況でなければいけないと思う。
そうしないとソフトウェア業界は、いつまでたっても「パッチを出せばいいんでしょ。」というような甘えの体質から抜け出せないのではないだろうか。
自戒の意味を込め、評価に値するソフトウェアとベンダの評価基準とはどうあるべきかについて自分の考えるところを書いてみました。
投稿者 abiru : 00:08 | コメント (0) | トラックバック
2005年11月23日
愛する努力 (ToT)
友人の結婚記念パーティが開催されて、どういう巡り合わせか私が司会進行を仰せつかった。いろいろ予想外の問題はあったものの、なんとかパーティ自体は無事終了！当初の目的であった新郎を感動で号泣させるという目標は達成されなかったが、新郎のブログに書いてある以下のエントリを読めば大成功であったことは間違いない。
新婦の彼女は新郎が泣いている姿をまだ一度も見たことが無いと言っていたが、はたして上記のブログに描写されている姿を見る事はできたのだろうか。タイトルこそ「相方熟睡中」となっているが、本当のところは二人のみが知りうる世界である。
私の発案で「両親からの手紙」という企画をやらせてもらったが、企画した私自身が感動のあまり泣きそうになった。というか、泣いた。特に新郎の父から結婚する二人へ宛てた手紙が感動的だった。その中でも印象に残った一言をここに記しておきたい。
「赤の他人だった二人が親兄弟以上に親密な間柄になるのです。『愛する努力』が必要です。」
(ToT) (ToT) (ToT) (ToT) (ToT) (ToT) (ToT) (ToT) (ToT) (ToT)
やべえ！この文章入力しながら、また泣けてきた・・・。
お父さん！うますぎです！金八を超えてます！是非、直木賞目指して下さい！
というわけで、新郎新婦のお二人様、末永くお幸せに・・・・。
投稿者 abiru : 23:53 | コメント (0) | トラックバック
2005年11月15日
blogはマジメに書きましょう。
いつもは、私が独り言をつぶやくように綴っているこのブログ。コメントもトラックバックも無いエントリがほとんどですが、昨日書いたmixiに関するエントリには知人・友人からコメントがあった。やっぱりマジメに考えた文章を書くと、ちゃんと読んでもらえるんだなあ。と当たり前な事を再認識しました。
でも、そのクオリティを毎日維持すんのは無理。
投稿者 abiru : 12:25 | コメント (2) | トラックバック
2005年11月14日
mixi機能拡張に関する株式会社イー･マーキュリー様へのご提案
以下の内容をmixiの機能拡張に関するアイデアとして株式会社イー･マーキュリー様へご提案致します。
◆◆◆ mixiを使ったSSO認証のアイデア ◆◆◆
例えばmixi以外の外部サイトでウェブページやブログを作成して「このコンテンツはマイミクさんだけに見せたいなあ。」と考えた時、現状では、以下のような方法が考えられる。
■考えられる方法
・外部サイトにアクセス制限を設定しmixiでパスワードを告知する
・外部サイトではなくmixiの日記にエントリとして公開する。
・外部サイトではなくmixiのプロフィール欄に記入する。
しかし、これらの法には次ようなデメリットが考えられる。
■上記方法の問題点
・アクセス制限はパスワード入力が二度手間、パスワード流出の可能性もある
・どのマイミクさんが来たのかわからない。
・外部サイトをやめてmixiの中で公開するとデザインの自由度が無い
■mod_mixi_ssoの提案
上記問題点の解決策としてmixi以外のサイトで公開されているコンテンツをmixiで認証済みもしくはマイミクのみにアクセス許可できるようなApacneモジュールを提案する。このモジュールをここでは「mod_mixi_sso」と呼称することとする。また、外部サイトで行われるmixiのユーザIDとパスワードによる認証の事を「mixi認証」と記述する。
■mod_mixi_ssoによるmixi認証の流れ
・mixi認証で保護されたURIにアクセス
・mod_mixi_ssoがmixi認証用のCookieの有無を確認
・Cookieがあればコンテンツをレスポンスする。
・Cookieがなければmixi.jp内にあるmixi認証用のページへリダイレクト
・リダイレクトする際CGIの引数で認証保護されているURIを渡す
・mixi認証用専用ページでユーザIDとパスワードを入力
・認証保護されたURIのドメインとパスを値に持つmixi認証済みを示すCookieを発行
・偽造防止の為Cookieにmixi.jpのみが知りうるキーで暗号化されたデータを含める
・認証済みCookieの送信の際に一緒に元の認証保護されているURIへリダイレクトする。
・認証済みCookieを受信した外部サイトは暗号化データを復号し偽造でない事を確認
■イー･マーキュリーにとっての利点
・mixi.jpで閉じたサイトではなくmixiブランドを広く展開できる
・mixi認証を利用する外部サイトに広告を掲載できる
・単なるSNSサイトではなく認証インフラの地位が築ける
■ユーザにとっての利点
・mixiのデザインに制限されない自由なページを作成できる
・マイミクにしか公開されないコンテンツを作成できる
・access_logからどのマイミクがページを閲覧したか確認可能
■未解決項目
・広告掲載をしないと認証を利用できないようにできるのか。
・mixi認証済みを偽る事ができるか充分な検証が必要
・mod_mixi_ssoの開発スキルが私には無い
・ユーザニーズがあるか不明
以上。
投稿者 abiru : 02:41 | コメント (11) | トラックバック
2005年11月13日
TurboLinuxでDVD
WindowsMediaPlayer互換のソフトが付属するというから購入したTurboLinux Multimediaであったが、よもやDVDの再生にこれ程苦戦を強いられようとは想像しなかった・・・。
・USB接続でドライブを接続してOSを再起動したらドライブはすぐに認識された。
・ファイルシステムとしても何事もなくマウントできる。
・TurboLinux Multimediaにはk3bというDVDを焼くソフトも付属している。
・TurboメディアプレーヤにはDVDという選択肢もある
ここまで条件が揃っているのでTurboメディアプレーヤで再生を試みたが全然再生されない。
で、いろいろ調べて見るとどうやら市販されているDVDを再生できるようなDVD再生用ソフトを開発するにはライセンスの問題が絡んでいるらしい。Turboメディアプレーヤでは同じくライセンスの問題でDRMで保護された.wmvファイルが再生できないという制限があるので、きっとDVDも再生できないのであろうと判断した。
更に調査をしてみると、ありました。
@IT 「DVDビデオを再生するには」 北浦訓行 2002/5/16
上記ドキュメントによると、OgleというDVD再生ソフトを使えば可能であるとの事。ただし記事の中でも言及されている通り、これを実現する為に使用しているlibdvdcssというライブラリはライセンスを受けておらず、現状としては取り扱いに注意が必要なもののようだ。
Ogleを動作させるのに必要なライブラリは以下の通り。
libdvdcss
libxml2
lbdvdread
Ogle
Ogle_gui
でもって、これらのライブラリは以下のURLからダウンロードできる。
http://www.dtek.chalmers.se/groups/dvd/redhat.shtml
あとはダウンロードしたライブラリをrpmコマンドで順次インストールするだけだ。
投稿者 abiru : 15:47 | コメント (1) | トラックバック
2005年11月07日
オオカミ少年状態
四ッ谷に引っ越して以来、四ッ谷消防署が近いので毎日のように消防車のサイレンを聞いている。最近では何の危機感も感じなくなった。近所で火災があっても気が付かなかったりして・・・。逃げ遅れるかなあ。ま、火災報知器の非常ベルには反応できるとは思うけれども。
投稿者 abiru : 02:04 | コメント (0) | トラックバック
2005年11月05日
「父の日記」遂に完結！
愛読していたブログ「父の日記 昭和１７年」が遂に昭和17年11月５日のエントリを以て完結致しました。日記の最後には以下のように記されております。
昭和十四年六月二十六日大命を奉じ軍務に服してより、数へてみれば三年四ヶ月。長期の軍隊生活も此れでやっと無事終了したのだ。而し乍ら今になってみると何の感慨もない。東京は相変らず賑やかだし、大東亜戦争は何処でやってゐると言ふやうな風景だ。すっかり気抜けがしてしまった感じだ。当分何をするのも嫌になった。
今日的に表現すれば「燃え尽き症候群」とでもなるのでしょうか。それだけ軍隊生活という者がこのお父様にとっても非常に緊張を強いるものだったのかもしれません。日記では時にのんびりとした日常を綴っていたものの、我々には理解できない気苦労があったのだろうなあと感じさせる最後の一節です。
個人的には除隊後、敗色濃厚となっていく日本の有り様をどのように綴っておられるのかに非常に興味があるところではありますが、一人の人間が苦悩するであろう姿を興味本位で垣間見るのは悪趣味かもしれません。
最後にひとこと。
お父様、本当にお疲れ様でした。