MASATOの開発日記

WinInetでリダイレクト検出

WinInetというWindowsのAPI群があります。 これは、Win32 Internet Extensionsの略で、 Gopher、FTP、HTTPなどのプロトコルを容易に扱うためのAPI群です。

InternetOpen、InternetOpenUrlなどのAPIがこれに属します。
MFCでは、CInternetSession、CInternetConnectionなどのクラスがWinInetを使っています。

話は飛んで、WinInetは、HTTPサーバにアクセスした際、 HTTPステータスコード 301、302、303、307が返ってくると、自動的にリダイレクト先のURLにアクセスしてくれます。
それはそれでありがたいことなのですが、自動的に処理されてしまうと、これらのステータスコードが返ってきたことがアプリケーションからは分かりません。そのため、例えば、301(Moved Permanently)が返って来た場合にアプリケーション内部に記録されているURLを変更するような処理が実現できません。

ここでは、そんな自動リダイレクトを回避する方法を紹介します(前置き長い・・・)

以下のAPIを使う際、

InternetOpenUrl
HttpOpenRequest
CInternetSession::OpenURL
CHttpConnection::OpenRequest

以下のフラグを設定します。

INTERNET_FLAG_NO_AUTO_REDIRECT

それだけです。
フラグの存在さえ知ってしまえば後は簡単な話です。

なお、上記フラグを設定して自動リダイレクトを回避した場合、リダイレクト処理を自力で行う必要があります。
HTTP_QUERY_LOCATIONフラグを指定してHttpQueryInfoやCHttpFile::QueryInfoを呼び出せばリダイレクト先のURLが分かりますので、 301、302、303、307が返ってきた場合は、再度HttpOpenRequestやCHttpConnection::OpenRequestを使ってリダイレクト先URLにアクセスしましょう。
WinInetは、これらのステータスコードが返ってくるたび、何度でもリダイレクトするようです。 この動作に合わせても良いとは思いますが、何度目かでリダイレクトするのを止めてエラーとしておいたほうが無難そうな気もします。

最後に、リダイレクト周りの処理をテストするためのURLを紹介します。

http://www.sutosoft.com/test/redirect/301.html

http://www.sutosoft.com/test/redirect/301_goal.htmlにリダイレクトされます。ステータスコードは301が返ります。

http://www.sutosoft.com/test/redirect/301_rss.rdf

http://www.sutosoft.com/room/index.rdf(このサイトのRSS Feed)にリダイレクトされます。 RSSリーダーのテスト用にお使い下さい。

http://www.sutosoft.com/test/redirect/301_loop.html

自分自身にリダイレクトされます。Internet Explorer 6でこのURLにアクセスすると、いつまで経っても転送中のままになりますのでご注意下さい。サーバ側にも負担がかかりますので、このURLに対するアクセスだけはほどほどにするようお願い致します。

URLの「301」の部分を302、303、307に返ると、ステータスコードが変わります。アプリケーションのテスト用としてご自由にお使い下さい。

ヨドバシカメラマルチメディアAkiba

関東に行ったついでに秋葉原のヨドバシカメラに寄ってみました。

一時間程度かけて一通り見てみましたが、なんて言うか広いです。とにかく広い。
整然としてはいるのですが、それでも迷子になるかと思いました。

商品価格はチェックしてないですが、品揃えはとても良いですね。
OAタップだけで一列構成しているのを見たときはびっくりしました。

ここのお店はメーカー別展示をしていることで有名らしいですが、
それについては特に感じるところはありませんでした。
普通のお店と若干配置が違うかな、程度です。
何か目的を持って商品を探すときはまた別の印象を持つかもしれませんが。

一見した印象は、超巨大な普通の電気屋さん、ですね。
メイドカフェも無いようですし秋葉原らしさは特にありません。
こんなお店ができて秋葉原がどう変わっていくのか、ちょっと楽しみです。

Heimdallrのブラウザ起動時間にいちゃもん

Heimdallrの起動時間にいちゃもんの続きです。

今回はブラウザ起動時間についてのお話です。

まずブラウザ起動時間とはなんぞや、という話ですが、これは記事タイトルをクリックしてからブラウザの画面にその記事の本文が表示されるまでの時間のことです。

この時間は、ブラウザや接続先のアクセス速度によってまったく異なりますが、2秒かかることはざらにあります。

これは、遅いのです。

PC使っているとこの遅さが慣れっこになってきますが、テレビのリモコンでチャンネルを変えたとき、2秒もかかったらどうでしょう。ついつい押せなかったと思って連打してしまいますよね。つまり、2秒というのはユーザが誤操作をしてしまう余地のあるくらい長い時間なのです。これは、あんまりです。

ではどのくらいの時間ならば良いかと言われると、私は200ミリ秒だと思います。この応答速度であれば、ユーザもボタンを連打しようとは思わないでしょう。

でもってこれに対する開発者としての回答ですが、
200ミリ秒にしてと言われても難しいです。
ブラウザを内蔵すれば手段が無いわけではありませんが、手間がかかって大変そうです。申し訳ありませんが、ここはユーザの我慢強さに甘えたいと思っています。

以下余談です。

目標時間はさておき、Heimdallrの記事タイトルをクリックすると記事が画面から一瞬で消える、というユーザインターフェースはブラウザ起動時間の遅さをカバーする恐ろしい(?)ユーザインターフェースになっていますね。
ブラウザ起動が遅いのに痺れを切らしたユーザが、もう一度記事タイトルをクリックしようと思っても、もうそこには無いわけです。さすがに押すものが無ければユーザは待つしかないので、ユーザを苛々させることはあっても、誤操作してしまうことは無いわけです。
テレビのリモコンで言うと、チャンネル変更ボタンを押した瞬間、ボタンがリモコン内に収納されてしまうようなユーザインターフェースに相当します。これならチャンネル変更に何秒かかろうと、連打されることはないですね。遅さがどーにもならないときはこんなユーザインターフェースもありなんでしょうね。

HDH-UL120を買いました

HDH-UL120というLAN接続が可能な120GBのHDDを買いました。税込み8,552円でした。現時点の価格.comにおける最安値が18,912円なので、かなーり安かったようです。

LAN接続ができるということなので、SMBあたりで接続することになるのかな、と思ったら、NDASというベンダ独自仕様で接続するようです。簡単に言うとSCSI on TCP/IPみたいですね。

そんな仕様だと、ホットプラグやファイル単位の同期などはどうするんだろうと気になりましたが、どうやらどちらもできないような感じです。マニュアルによると以下の制約があるようです。

• LANケーブルを取り外す際は、HDDに接続している全てのPCからユーティリティを使って接続を解除しなければならない。
• 複数のパソコンから同じファイルを開いて同時に編集することができない。
• このHDDに接続しているPCはサスペンドしてはいけない。

なんていうか制約だらけです。これだとLAN接続できるメリットがあんまりありませんね。USBのポートを使う代わりにLANポートで代用できます、という程度のことしかできないようです。

このHDDは、USB接続もできるようなので、LAN接続できることは忘れてそちらを使おうかとも思いましたが、うちのPCのUSBポートも余りまくっているわけではないですので、USBポート節約のために、一台のPCからLAN接続し、他のPCからはそのPCを経由してSMBでアクセスするようにしました。

なんかやれやれ・・・という気持ちですが、安かったので良いです。ただのUSB接続の120GB HDDと考えても安いと思いますし。

この製品に対する正直な感想は以下の通り。
よく商品化する気になりましたね。

すごいなぁIO DATA。

Heimdallrの起動時間にいちゃもん

Heimdallrに色々と文句を付けた記事「Heimdallrにいちゃもん」に対してコメントやトラックバックを色々と頂きましたので、返事も兼ねてもうちょっと詳しくいちゃもんを付けて見たいと思います。

今回は起動時間、終了時間、設定変更時のハング時間についてです。

『★久々に「Heimdallr」な話。』に起動時間の定義が分からないと言う話がありましたので、まずは、これらの時間の定義から始めます。

起動時間

スタートメニューでHeimdallrを起動してから、ビューが表示されて記事閲覧が可能になるまでです。巡回は記事閲覧が可能になった後に行われるので、巡回時間は含まれません。

終了時間

Heimdallrのメニューで終了を選択してから、Heimdallrプロセスが終了するまでです。

設定変更時のハング時間

ビュー設定画面を開き、OKボタンを押した後、ビューを操作できるようになるまでの時間です。

次は、これらの時間が何によって決まるのか、という話です。

これの3つの時間は、Heimdallrの登録RSS Feed数、RSS Feedが含むテキストの量、PCの性能によって決まります。OPMLやトピックチャンネルはテキストの量が多いRSS Feedに相当するので結構効きます。

設定ファイルの１つであるsite.xmlのファイルサイズが良い指標になると思います。
標準的なスペックのPCだと、ファイルサイズが1MBを超えると、秒単位の時間がかかるようになりますし、5MBを超えると、10秒近くかかることもあります。ちなみに私のsite.xmlは8.46MBあり、これらの時間はどれも10秒位です。

最後に、何故これらの時間が遅いと思ったのか、という話です。

設定変更時のハング時間は、砂時計マークなどは出ませんし、ユーザからしてみると「時間がかかるとは思えない」処理なので、10秒どころか数秒かかれば「遅い」と言うべきところだと思います。1秒でこなすべきでしょう。起動や終了もできれば1秒、それが無理ならばせめて3秒程度でこなすべきところで、10秒もかかったらもう「遅い」としか言えないでしょう。というわけで私はどれも遅いと感じたわけです。

なお、site.xmlのファイルサイズが小さい方は、これらの時間がみんな1秒以内になると思いますので、遅いと感じることはないと思います。使い方によりけりということでしょう。ただ使い方によってはこれらの時間が10秒を越してしまうというのは、Heimdallrの課題でしょうね。っていうか数秒でも課題ですね。

Heimdallr 1.10alpha2リリース

Heimdallr 1.10alpha2をリリースします。
安定版ではありません。

Heimdallr 1.10alpha2 ダウンロード

安定版はHeimdallr 1.09です。

今回の変更点はバグ修正と細かい機能の追加ですが、トピックチャンネルを使い続けると使用メモリや起動時間がどんどん増えていくというバグと、16Bitカラーモードで透明スキンを使うと操作できなくなるバグという、比較的大きなバグが修正されてます。
本来はこうした大きなバグがあれば、安定版である1.09にバグ修正だけを施した1.09aのようなパッチ版をリリースするべきだとは思いますが、パッチ版リリースは結構手間がかかりますし、Heimdallrのほとんどのユーザに影響がある致命的なバグというほどのものでもないと思いますので、1.09aのリリースはせず、1.10の安定版を早めにリリースすることで替えたいと思います。すみません手抜きです・・・。

1.10alpha1→1.10alpha2の変更点詳細

• 日付が未来を指している記事の優先度が高くならないようにしました。
• HTTPレスポンス301を受け取るとサイトのURLを変更するようにしました。
• 16Bitカラーモードで透明スキンを使うと操作できなくなるバグを修正しました。
• トピックチャンネルを修正しました。
  • 使っているうちにデータが無限に増えていくバグを修正しました。

Heimdallrにいちゃもん

Heimdallrの今の安定版のバージョン番号は1.09です。これは、9回のそこそこ大きなバージョンアップが行われたことを意味しています。だいぶ機能も充実してきたので、今後はパフォーマンスやインターフェースの改善を進めていく予定です。

ここでは、そのあたりの問題について考えてみます。 私自身、Heimdallrユーザなので、使っていてあれこれ感じることを書いてみて、 それに対し開発者としての言い訳コメントなどをしてみます。

パフォーマンス

普段使っていてちょっと気になるのが以下の点。

• 起動が遅い。
• 終了が遅い。
• ブラウザの起動が遅い。
• 何か設定を変えるとしばらくハングする。

起動や終了は、登録サイトの数がちょっと多くなるとすぐ10秒に到達しますし、 チャンネルエクステンションを使い始めると30秒以上になることもあります。
そうなる原因は、私の手抜きです(すみません)。
Heimdallrは常駐アプリケーションなので、起動や終了を行うことは少ないと考え、あまり高速化しないことにしているのです。今後も、要望が無い限り高速化する予定はありません。

ブラウザの起動が遅い件は、大きな問題です。記事の詳細をぱっと見ることができないというのは不便です。
しかし、ブラウザ起動までの大半の時間はブラウザの問題なのですので、文句はブラウザ開発者に言って欲しいなぁと言って逃げたいところです。 でも、Heimdallrがブラウザを起動する機能を持っている以上、他人事にはできませんね。
解決策としてはブラウザを内蔵することが挙げられると思いますが、ブラウザ内蔵は難しそうな上に使わない人も多そうですのであまりやりたくありません。さてどうしたものか・・・

設定変更時のハングは、設定変更時に終了時と同じような設定保存処理を行っているからです。色々対策方法はありそうですが、致命的なものではなさそうですし、要望もないので放置してあります。今後も放置予定です。

ユーザインターフェース

マウスジェスチャ機能を備えてから、ビューを操作しているときは面倒だと感じることがほとんどなくなりました。しかし、以下の通り、設定用画面はまだまだです。

• スキン設定の設定項目数が多すぎる。
• ビュー設定が訳分からん。

スキン設定は確かに項目が多すぎるとは思いますが、GUIに関わることだと、細かい所まで設定したいという方がおりますので、少なくするのはなかなか難しいです。
簡易モードと拡張モードの2つを設けて、簡易モードのときはスキンを選択できるだけにし、拡張モードは今までどおり細かく設定できるというようにしても良いのですが、2つモードがあるのはそれはそれで混乱の元になります。難しいですねぇ。

ビュー設定については・・・。これはなんとかしたいです。 なんとかしたいのですが、古いコードにより実現されているので手を付けるのが難しいのです。いつかどこかで気合を入れて新しい画面に変えたいです。

8月のカウンタートラックバック

毎月恒例のカウンタートラックバックです。
8月中にHeimdallrを紹介して頂いた方々に対し、トラックバックを送ると共にお礼を込めてコメントなどを書かせて頂きたいと思います。

(8/20)Heimdallr

ご紹介ありがとうございました。ここで紹介して頂いたお陰で、その後の1週間は倍くらいアクセスがありました。今でもVectorでキーワードをRSSとして人気順で検索するとトップになっています。結構ユーザが増えたのではないかと思います。

(8/21)これは良いFEEDリーダだ

RSS FeedのURLをFeedリーダーに簡単に登録するための仕組み、Feed Protocol。それなりに便利なんですが、広まりませんね。
Windowsというプラットフォームに依存しているという理由もあるんでしょうが、そのWindows上でさえドラッグ＆ドロップで同じようなことができてしまうのが痛いところですね。

(8/22)1.10alphaにバージョンアップ

地味な改良ばっかりの1.10alpha1をここまで取り上げて頂きありがとうございます。
しばらくは地味な改良が続きますので、今後もよろしくお願いいたします。

(8/27)PingやRSSで日付詐称？

RSS検索エンジンやRSSリーダーで記事一覧を表示したとき、日付詐称記事が上位に上がってくることは良くあるように思えます。恐らく単純に日付順にソートしているのでしょう。ですので、SEO的にも恩恵がありそうな気がします。

Heimdallrもそこらへんはあまり厳密にチェックしていませんので、未来の記事が上位に来るかもしれませんね。

(8/29)RSSリーダーHeimdallr

ご紹介ありがとうございます。
デフォルトのサイトはそれなりに注意深く選んでますので、ご活用下さい。