私はINSPIRON 8600というDELL社製ノートPCを使っているのですが、
先日これが起動しなくなってしまいました。
起動しなくなる数日前からかっこんかっこんと何かを叩くような音が聞こえ、ついには電源を入れるとA disk read error occurredというメッセージが表示されて起動しないようになりました。
もうこの時点でHDDが壊れたことはほぼ明らか。まだ買って半年なのになぁ。
ちなみにHDDはHITACHIのTravelstar IC25N080ATMR04-0。日立のばかー。
HDDを自分で買ってきても良いのですが、一応サポート期間中なので無料で交換してもらえるはず。というわけでDELLのテクニカルサポートに電話してみました。
テクニカルサポートに電話したときの話の流れは次のような感じでした。
サポートの良かった点
サポートの悪かった点
総じて言えば、良いサポートでした。
人数を増やしてもっと早く電話が繋がるようにして頂ければ他にはいちゃもんの付け様が無いです。
しかしHDDが壊れてしまったことは最悪です。日立のHDDなのでDELLを責めてもしょうがないですけどね。
でも失われてしまったデータは二度と戻ってこないのです・・・。特にデジカメの画像。
そんな重要ならばバックアップを取っておくべきだと？いやとっているつもりだったんですけどね・・・。どうやらバックアップ設定を間違えていたらしく何もバックアップされていませんでした。しくしく。
世界のネコ展を見てきました。
携帯電話のストラップを猫の目の前でぶらぶらさせられるとばしばしネコパンチを繰り出してじゃれついきてくれた。ストラップを手前に移動させると猫が私の膝の上に乗ってきてネコパンチ。あー幸せ。
猫はストラップで釣れるんだなぁ。こんど野良猫に試してみようかな。
今回説明するのは、高さが特定の条件を常に満たしているウィンドウの作り方です。 特定の条件は、ここでは例として「10の整数倍+5」としておきます。
応用すればこの条件に限らず色々な条件を指定できます。 高さが常にフィボナッチ数であるウィンドウなんていうのものも作れます。
具体的なコードの例を以下に示します。
ウィンドウを扱うクラスは、CFrameWndクラスの派生クラスCXxxFrameであるとします。
そこに、以下のようなWM_SIZINGメッセージハンドラを追加します。
void CXxxFrame::OnSizing(UINT fwSide, LPRECT pRect)
{
const int N = 10;
const int M = 5;
CFrameWnd::OnSizing(fwSide, pRect);
// ウィンドウの高さを越えない範囲でNの定数倍+Mを満たす最大の高さを求める。
int iHeight = pRect->bottom - pRect->top;
iHeight = ((iHeight - M) / N) * N + M;
if (fwSide == WMSZ_BOTTOM || fwSide == WMSZ_BOTTOMLEFT || fwSide == WMSZ_BOTTOMRIGHT) {
// 下方向にウィンドウを伸ばしている場合は、pRect->bottomの値を変更する。
pRect->bottom = pRect->top + iHeight;
}else if (fwSide == WMSZ_TOP || fwSide == WMSZ_TOPLEFT || fwSide == WMSZ_TOPRIGHT) {
// 上方向にウィンドウを伸ばしている場合は、pRect->topの値を変更する。
pRect->top = pRect->bottom - iHeight;
}
}
なお、OnSizingが有効に働くのは、ユーザがウィンドウ枠をドラッグ＆ドロップして サイズを変更しようとしているだけです。 CFrameWnd::CreateやSetWindowPos、MoveWindowなどでウィンドウのサイズを指定する場合、 高さが「10の定数倍+5」になるように注意しましょう。
次のHeimdallrのバージョンである1.06で何を実装するのか考えてみたいと思います。
既に1.06alpha1がリリースされているので多少いまさら感がありますけどね。
Heimdallrに追加する大きな機能は、それそれプロジェクト名をつけて、仕様検討を行っております。(プロジェクトといっても、大勢の人が参加しているわけではなく、基本的には私一人で検討しております。)
今のところ、プロジェクトは3つほど存在します。
プロジェクトは以下のフェーズから構成されています。
前置きがやたらと長くなりましたが、1.06の目玉は、WordWatchプロジェクトにより実現される自動学習機能になる予定です。
現在WordWatchプロジェクトは実装フェーズにあり、そろそろ(といってもあと1ヶ月位はかかりそうですが)具体的な成果をお披露目できそうです。
SkinSystemプロジェクトは、保守・拡張フェーズにあります。1.06でもちょっとだけ仕様を拡張する予定ですが、それほど大きな変更にはならないでしょう。
SiteExtensionプロジェクトは、まだ構想フェーズです。実装に結びつくのは当分先でしょう。
おまけに現状の細かい要望リストを載せておきます(1.06alpha1で実装されているものも含まれています)。
上に書いてあるものから優先的に実装していきます。上からいくつか実装した時点でバージョン1.06としてリリースします。
実装する際の難易度を難、普、易の三段階で評価し、効果を大、中、小の三段階で評価します。
あらゆるサイトの新着ニュースをRSSで配信するサービスを提供しているMyRSS.jpというサイトがあるのですが、ここで毎月RSS リーダー ランキングを公開しています。
2004/07のランキングによると、Heimdallrは現在6位(「アクセス元IPアドレス」での集計結果)のようです。
Vectorと窓の杜に紹介して頂いたのが効いているような感じですね。
現在日本で使われているRSSリーダーのランキングというわけではなく、MyRSS.jpを利用している人が使っているRSSリーダーのランキングという限られた範囲のランキングですが、MyRSS.jpは大勢の人が利用しているサービスですし、何よりログ集計結果という人の意思の入らない集計結果ですので、RSSリーダーの人気度を表す指針の一つになると思います。
実はここのランキングに載るのがHeimdallr普及の一つのマイルストーンでした。達成してなによりです。後は落ちないよう頑張らねば・・・。
ちなみに他のマイルストーンはこんな感じです。
なんか適当なマイルストーンばっかりですね・・・
Heimdallr 1.06alpha1をリリースします。
安定版ではありません。
Heimdallr 1.06alpha1
安定版はHeimdallr 1.05aです。
変更点は以下の通りです。
1.06alpha1における変更点は、小さな機能追加とバグ修正がメインです。
1.06のメイン機能となるはずの自動学習機能はまだ影の形もありません。
一番最初のバージョンであるalpha1で一番大事な機能である自動学習機能を搭載したかったのですが、残念ながら自動学習機能はまだまだ時間がかかりそうなので、夏休み前に今まで実装した分だけでもalpha1としてリリースすることにしました。
自動学習機能は、タイトル文字列からキーワードっぽい単語を抽出する部分がようやく実装できたところです。
今後、抽出した単語を整理して蓄積していく部分と、蓄積された情報を元に記事の優先度を決定する部分を作らなければなりません。
まだまだ先は長いです・・・。
Heimdallrもlibpng使っていますので影響を受けます。
具体的には、この脆弱性を突くPNGファイルが含まれたスキン使おうとすると、
Heimdallrを乗っ取られて悪質なプログラムを自由に実行されてしまいます。
といってもHeimdallrのようなマイナーアプリケーションに脆弱性が増えたところで、世の中に与える影響はほとんどないので、次のバージョンで修正すればいいさと結構のんびり構えています。
実のところ、Heimdallrのセキュリティ面の問題は、今回のlibpng関連以外にもたくさんあるでしょう。
Heimdallrで行っている対策は、
「http:以外の文字から始まるURLを開かない。」
程度のものです。
セキュリティ専門家の目から見れば、他にもたくさん問題があるでしょう。たぶん。
しかし、残念ながら、私の力量では、問題を解決するどころか、どのような問題があるのかも把握しておりません。問題を念入りに探す時間もありませんし、しばらくはこのままでしょう。
というわけで。
あまりHeimdallrに高度なセキュリティを期待しないで下さい。
使う時には、ある程度のセキュリティリスクがあることを覚悟した上で、お使い下さい。
ソフトウェアの品質問題が叫ばれる今の世の中、フリーソフトの品質向上について考えてみました。
フリーソフトは開発にあまりお金がかけられないため、基本的なテストのみを行って公開し、利用者からのエラー報告を受けてバグを修正して品質を向上させていくアプローチがよく用いられています。
そういうわけで、今のところ、フリーソフトの品質の生命線は、利用者からのエラー報告なのです。
このサイトにコメントを頂いている方々のエラー報告は詳しい報告が多く、助かっているのですが、他所のサイトで、時々こんなようなエラー報告を見ることがあります。
「今日○○というソフトを使ってみましたが、××してみるとなんか動きません。他のソフトを探すことにします。」（内容は架空のものです。）
一応これもエラー報告ではあるのですが、残念ながらこれを元にバグを見つけることはまずできません。
ソフトウェアのバグを見つけるにあたり、重要になるのが、開発者の環境でエラーを再現できるかどうかです。
開発者の環境で簡単にエラーを発生させることができれば、もうバグは修正されたも同然です。
というわけで、上記のようなエラー報告を見ると、それを再現させるため、報告にあった通りの操作をしてみます。
ここでエラーが再現できれば良いのですが、再現できなかった場合、迷宮入りになります。
詳しく聞きたくても、相手は開発サイトであるここにコメントを書いているわけではなく、自分のサイトで自分がやったことを書いているだけです。
そこに乗り込んであれこれ聞き出すのも失礼でしょう。
開発者としては、エラー報告は品質の生命線なので、詳しいエラー報告が欲しいなぁと思いますが、利用者として考えるとそんな面倒なことはあまりしたくありません。
詳しいエラー報告を作成するのは結構手間がかかります。その上、エラー報告をしても問題が解決するとは限りません。開発者がバグ修正版を公開するまで待つ必要があります。
私自身、普段使用しているソフトでエラーが発生しても、開発者にエラー報告を行うことはあまりありません。
手間暇かけてエラー報告を行うよりは、他のソフトを使うなり、運用でエラーを避けることを選択するわけです。
そんなわけで開発者と利用者の間にはエラーに対する考えの違いがあって、エラー報告を頼りに品質を向上させていくというアプローチはなかなか上手く機能しません。
しかし、もしここに簡単に詳細なエラー報告を行うことができる仕組みがあれば、
問題は一気に解決します。
そんな魔法ような仕組みがあるのか。
あるようなんです。
これがそうです。
「Microsoft オンライン クラッシュ ダンプ解析サービス」
アプリケーションが強制終了したとき、動作環境(OS/CPU等)、強制終了したときのレジスタやメモリの値等の、様々なエラー情報をサーバまで送信するサービスです。これらの情報は、開発者からしてみると涎が垂れるほど貴重な情報です。
しかし、残念ながら誰もが自由に使えるサービスというわけではありません。
エラー情報を収集できるのはMicroSoftだけです。
MicroSoftは、MicroSoft製品のエラー情報を収集するためにこのサービスを行っているのだとは思いますが、MicroSoft製品に限らず、Windows用アプリケーション全般の品質を向上させることができるサービスだと思うので、ぜひ一般に開放して欲しいものです。
Windows用アプリケーションの品質が向上するのはMicroSoftにとっても利益があると思います。
一般の方々は、Windowsアプリケーションが魅力的だからWindowsを使っているのですから、Windowsアプリケーションがより魅力的になれば、Windowsもますます売れるのではないかと思います。
一般に開放するにあたってプライバシーの問題など色々あるので難しそうですが、
自社利益に結びつくのでそこはなんとか解決し、是非ともエラー情報を開発者まで届けて欲しいと願います。