投稿

2月, 2004の投稿を表示しています

モジュールチェック用スクリプト

mail-entry.cgiの実行に必要なPerlモジュールが、サーバにインストールされているかどうか調べるスクリプトを作成しました。・・・というか、Movable Typeに同梱されているmt-check.cgiを書き換えただけです。これってパッチでもないし、配布すると問題あるのかな・・・ 一応 こちら に置いておきます。 ダウンロードしたら拡張子をcgiに書き換えて、エディタで先頭行のPerlのバスを自分のサーバの環境に合わせて変更してください。サーバにアップロードしたらアクセス権を700なり755なりにしてブラウザから実行してください。 MTの設置が出来た方なら簡単な作業だと思います。mail-entryを自力で設置しようと思いつく方にはこんなスクリプトが無くても平気かもしれませんが。私は欲しいので(笑) 無い可能性が高いのはMIME::Parserでしょうか。メール解析に必要なのですが。 cpanサイトからダウンロードして、中のファイルをMTのextlibディレクトリにコピーすれば使えるんじゃないかなぁとか思います。たしかコンパイルの必要はなかったと思いますけど・・・ サーバ管理者にインストールをお願いするのが一番確実です。 ところで、、、 mail-entry.cgiの92行目にあるuse MIME::WordDecoder;という行ですが、必要ないみたいです。MIME::WordDecoderが無くてエラーになって実行できない人がいたら大変申し訳ありません。先頭に#を付けてください。(コメントアウト) ただし、次バージョンへのアップデートパッチを当てるときに正常に当てられない可能性もありますので、パッチを当てるときだけ#を消して元に戻してください。バッチを当てれば、もう気にする必要はなくなります。

mail-entry_0.3.4、ドキドキしながらリリースです

こちら からダウンロードしてください。 スクリプトを大幅に書き直しましたが、Setting節には変わりありません。パッチを適用するか、Setting節だけコピーすれば動くと思います。 エントリーが重複登録される不具合を修正しました。きっと。たぶん。おそらく。・・・修正できてたらいいなぁ(汗) 全角のカテゴリー名を指定しても認識されない問題に対処しました。今まで気づきませんでした・・・ 重複登録にどのように対処したかをざっと書きますと。 まずすべてのメールを受信し、一通ずつ一時ファイルに保存します。同時に一時ファイルのインデックスファイルも作成します。一時ファイルに保存できたものはPOPサーバから削除します。 次に、インデックスファイルをもとに一時ファイルをエントリーしていきます。 途中でエラー終了しても一時ファイルは削除されずに残りますから、次にスクリプトが実行されたときはそれをもとにエントリー作業を継続します。 ただ、あまり長い間スクリプトが正常終了しない場合は、テンポラリフォルダに一時ファイルが溜まりまくってしまいますので、どうしようかと考え中です。

こんなはずじゃない~

Mobile-bozuは当初「もばいる坊主」という名前でした。Blogrollingを利用するときに、全角文字だと文字化けしちゃったので、単純にドメイン名を使っただけで。ほんとはもばいる坊主がいいんです。 こんなはずじゃない~ ここはもっと気楽にエントリーする場のはずでした。意味のあること無いことなんでも書いて、そのなかにたまに人のお役に立つような情報が混じってたら、それはそれでいいなぁなんて思っていたら。 すっかりmail-entryにはまって(すべて災害ボラに関わったためですが)すっかり理系のページになってしまいました。 こんなはずじゃない~ だからですね。 ほんとはもっと毎日たくさんのエントリーを書いて、そのうちのほとんどが読んでてぼけぼけできるようなものになるはずだったのに。 こんなはずじゃない~ いまいちおもしろくないなぁ。やっぱり理系なページをおとなしく書いていた方が良いのか・・・ というわけで、mail-entry新版が無事に動くかの試験でしたぁ~ やっぱり理系や・・・

mail-entry_0.3.3a(暫定版)リリースです

気分はブルーで今なら泥酔ブログも出来るかも、という心境ですが・・・今朝宣言してしまったので、暫定版リリースです。 こちら からダウンロードしてください。 今回のリリースは暫定版です。過去バージョンから一貫して、エントリーが重複登録されてしまう問題を抱えていましたが(最近判明)、強引な手法で対処しました。 何通ものエントリーメールを送ると、使用しているPOPサーバ(メールサーバ)に、通常以上の負荷をかけてしまいます。具体的には、エントリー用メールの数だけ、ログオン、ログアウトを必要とします。しかも短時間に。ですから、一度に処理するのが2、3通程度になるようにするのが良いかと思います。・・・普通はそれぐらいですよね?ここなんか、たまーに1通、とかですが・・・ 予定では来週あたりに、まともな対処をしたVer.0.3.4(予定)をリリースするつもりでいます。予定は未定なのでにんともかんともですが。 えー、ワタクシがんばりますが、どなたか、うまいこと対処できちゃったりしたら教えてくださーい! 先にエントリーした「別アプローチ」に書いた方法を実装してみるつもりです。他に良い案がありましたら、教えてくださいませ。サーバに負荷をかけず、それでいて何通でも処理できるのが目標です。よろしくお願いします。

mail-entry重複登録問題への別アプローチ案

「案」って時点で、もちろんコーディングはしてませんよという宣言ですが。 今試験的に作ってあるものは、メールを一通受信して、エントリーできる条件が整ったら、いったんPOPサーバからログアウトして、受信した分のメールを削除します。それからリビルドを実行し更新通知pingを飛ばします。無事に済んだら再びPOPサーバに接続してメールを読み出して・・・これをメールが無くなるまで繰り返します。最後の一通になったらもう接続せずにループから抜け出すとかの行き当たりばったりの小技を効かせながら(笑) この方法なら、POPサーバとのやり取りで想定外のエラーが発生しない限り、確実にエントリーが出来る、はず。 でも、サーバ管理者からすれば、気持ちの良いアクセスログ残しませんよね、これ。 今朝トイレで思いついたのが次の案。 同時に処理できるメール数を5通か10通ぐらいに限定して、そのつど直前5か10エントリー分のタイトルと照会すれば今までと大して変わらない仕組みで回避できます。エラーが繰り返し発生して処理済みのメールが多ければ、そこでいったんログアウトして削除して。これならPOPサーバにも負担かからないはず。 いちいちMTデータベースから引っ張ってきたら楽そうですが、それで時間かかってしまうとなると、タイトルだけ保持する別ファイルが必要になりますね。でもまあ、Perlの得意分野だからなんとかなるのかな。Perl達人とかならちょいちょいと出来そうなものですよねぇ。私には時間かかりそうですけど。 というわけで、とりあえず試験版を公開して(個人ベースでならサーバへの負担はそれほどでもないでしょうから)、新案を実装でき次第公開するという方針でいきたいと思います。いいでしょうか? もしその仕組みはまずいというならご指摘くださいませ。専門的なことは、調べてみるものの分からないことが多いです。試験版の公開は、今夜、かなぁ。新版は早くても来週になると思いますです。 たぶん少数しかいないであろうご利用者様~、見放さないでお付き合いくださいませ。

9ヶ月目のiBook生活

昨年5月に手に入れたiBookも、早9ヶ月目に突入しました。早いものです。この間、OSのメジャーアップデートがあったりしましたが、その辺りは前回の5ヶ月目のレポートの通りです。 前回のレポートから数えても4ヶ月。OSもマイナーアップデートが繰り返され、10.3.2になっています。セキュリティやSafariなどのソフトウェアのアップデートもありました。そのせいか、現在はほぼ快調に動作しています。 Safariも先日の1.2が公開されてから、ページが途中でとぎれたりといった現象にもまだ遭遇していません。使い込みが足りないのかもしれませんが、良い傾向です。ATOK15の修正パッチもずいぶん前に登場して、たいした不便も感じずに過ごしています。 相変わらず子気味の良いキータッチ(個人の嗜好によりますけど)も健在です。 問題が起こると言えば、Linuxサーバにある共有フォルダへのアクセスが時々激しく遅くなることでしょうか。虹色カーソルくるくるです。一度こうなると、再起動しないと直りません。原因もよく分かりません。なんなんでしょうか。 ソフトウェアに感じる不満点はこれぐらいなものですが、ハード的にはやはり性能面での厳しさを感じます。ハードディスクの空き容量もとうとう10Gを切るところまで来ました。ここまでくると精神的に余裕がなくなります。OSも安定性を欠くんじゃないかとか思ってしまいます。Windowsじゃないからそんなこともないのでしょうか。この辺り、まだまだ未知の世界です。 もともと30Gしかないのは、今時ではやはりちょっと少ないかな。最近はCDを買ったりレンタルしたりということがあまりないのでiTunesのデータは増えないのですが、写真データがガシガシ増えます。先日行ったボランティアでは、2時間のイベントで130枚撮りました。撮りすぎですよね。しかも整理は後回し。ハードディスクには現在1300枚超の写真が入ってます。そのせいなのかわかりませんか、iPhotoの動作がとても遅く感じます。前はこんなこともなかったような。 先日触ったPB15inchがとても速く感じてしまいます。 そして一番の不満点は、相も変わらず液晶とパームレストの熱です。熱は、冬なので今は気になりませんが、夏になるとまた暑いのかと思うと憂鬱です。液晶も、起動直後のあの暗さは何なのでしょうか。使っているうちに明

mail-entry試験中・・・

重複登録されることがないように改良したバージョンをこっそり試験中です。複数メールがある場合のPOPサーバへの負担が大きくなってしまったので、どんなものかと思案中です。 こんな対処で良いのかなぁ。。。

mail-entry重複登録の原因判明?かも

一晩寝たら、なぜ重複登録されるか見当が付きました。それが当たっているとすると、まだ対策が完全ではないようです。 POPサーバの動作に詳しくないのですが、メールの削除は、正常にログアウト出来た場合に行われるようです(あってます?)。mail-entryは、すべてのメールを処理してからログアウトしますから、途中でエラーが出てしまうと正常にログアウトされず、削除コマンドは発行していても実際には削除されないことになる、と推測されます。 今回の対策は、一通だけのメールの時はうまくかいくぐってくれますが、複数になるとたぶん、だめです。 テスト1、テスト2というメールを送ったとします。このとき、テスト1は正常に処理できて、テスト2でリビルドもしくはpingでエラーが出たとします。MTオブジェクト側でタイムアウトすると、うまくエラーが拾えないようなので、mail-entryごと途中で終了してしまいます。この場合は、テスト2というエントリーも登録自体はされている可能性が非常に高いです。 つまり、最新エントリーのタイトルは「テスト2」になります。この状態で再度mail-entryが実行されると、前回正常に終了できていないので、POPサーバにはまだテスト1とテスト2というメールが残っています。mail-entryはまず「テスト1」を読み出し、最新エントリーのタイトルと照会しますが、タイトルは「テスト2」です。今登録しようとしているのは「テスト1」なので、問題ないとして登録されます。そして、次はテスト2が同じ理由で登録されます。 もしまたテスト2の時にエラーが出ると、延々とこれを繰り返すことになるので、驚くほどたくさんの重複エントリーが誕生することになります。おおおっ。 こうやって考えると、前回の修正はあまり意味がないものに・・・一応新たな対策案があるので、実際にとりかかりたいところですが、体調不良でしばらく無理かもしれませんです。すいませんです。申し訳ないです。 いいわけ:iBookにローカルサーバをたてて実験しているものですから、タイムアウトエラーっで出ないんです。検証作業が大変です・・・

mail-entry_0.3.3リリースです

こちら からダウンロードしてください。今回の変更は見た目小規模、中身大規模なものですので、下記もご一読ください。 毎日マイナーアップして申し訳ありません。リビルドやping送信のタイムアウトなどの理由でscript errorが発生すると、次回mail-entry.cgi実行時に同じものが重複して登録されるケースが発生しました。原因はよく分かりませんが、以下のようにして対処しました。 リビルド時間を短縮すべく努力しました。このため、rebuild_index.cgiも変更になっています。でも短くなったか分かりません。 直前のエントリーのタイトルを調べ、登録しようとしているエントリーのタイトルが同じ場合、無視してスキップするようにしました。 ついでに、メールの処理順もメール到着順になるようにしています。これでエントリーのIDが意図したとおりの順番になるようになりました。前回泣きを入れたのですが、やればできるものです。えらい。 アップデート手順は以下の通りです。 UNIXが使える方は、パッチを利用してください。パッチとmail-entry.cgiを同じディレクトリに置いて、 cat mail-entry-0.3.3.diff | patch -p0 それ以外の方は、Setting節以外を丸ごとコピーして置き換えてください。Setting節に変更はありませんので、そのままにしてください。先頭にあるバージョン表記も書き換えておくと気持ちが良いです。自分の環境に合わせて改造している場合は、その作業も必要です。 rebuild_index.cgiを最新のものに置き換えてください。もしも手を加えている場合は、rebuild_index.diffという名前で差分ファイルを同梱していますので、参考にしてください。これを改造している方はいないと思いますけど・・・ 以上です。ぐちゃぐちゃと修正したので、またバグが混入した可能性もあります。不具合を発見されましたら、ご連絡ください。

Powerbook 15inchへの憧れ

用事で出かけたついでに、Powerbookに触ってきました。最近のお目当ては15inchです。17inchは高すぎるのでパス。12inchに惚れ込んでいたのですが、液晶がいまいちなのと、自分の行動パターンを考えると15inchの方が良いかなと思い始めています。 最近mail-entryのバグ修正に費やしている時間が長いのです。その作業はiBookでやっているのですが、やっぱり広い画面が欲しいです。そろから、見やすい液晶が。デスクトップ用のL565につないでデュアルモニタも出来るのですが、視線の移動が多くて疲れます。ついでに、2つのディスプレイでみやすさがあまりにも違うのでストレスが・・・ モバイルすることもあるのですが、週に一回程度で、車ですし、移動先には机があります。だから15inchでも問題ないのですよね。17inchはさすがにつらいでしょうけど。(重量よりも面積の問題で) 問題があるとすれば値段ですね。やっぱ高いです。ちまちまもばいる貯金(笑)してますが、貯まったとしても使うのがもったいない気が・・・ とりあえず、久しぶりに現物を見て物欲を葬り去ろうと思って、ふらりとショップに立ち寄りました。 あー すげぇいい。 となりにあった12inchと比べるまでもなく明るい液晶。PCの液晶と比べるとまだ暗い感じも受けますし、隅に行くに従って明度が落ちる気がしますが、これぐらいなら納得の範囲でしょうか。展示機は一日中つけっぱなしでへたってもいるでしょうし。 CPUも1GHzですって、いいですね~ 最近iBookで不満に感じていたiPhotoを起動してみました。そこそこのスピードで立ち上がってきます。しかも、写真が20枚くらい入ってました。店内を写したものです。こうやって実際にデータが入っていると、使い心地が確認できて良いですよね。 編集ボタンを押して、画像を大きくしてみます。・・・あれ?いきなりちゃんと表示されるよ。うちのiBookは粗い画像を表示して、2秒くらいでようやくきれいな表示されます。なにこれ。 矢印押して、次の画像へ。 ひゅんとすぐに切り替わります。次も、その次も、そのまた次も。 ・・・なにこれ? うちのiBook800CDをばかにしてるんですかー!G3とG4ってそんなに違うんですかー! 世のエグゼクティブな皆さんは、いつもこんな快適・快速な環境でお仕事してる

Safari1.2出ましたね

Safari 1.2が出ています。 私はJavaとともにソフトウェア・アップデート経由でインストールしました。で、いろいろ改善されたのかと思いきや。 アップルのサポートページにある、ソフトウェアダウンロード更新情報の Safari 1.2のところ を見ようとするといきなり文字化けするんですけど、どういうことなのでしょうか。 テキストエンコーディングを手動でShift-JISにすれば正常に見れますから、自動判定がうまくいってないのでしょうけど、、、 スタイルシートの解釈についてはどうなのでしょうか。こればっかりはいろんなページを見て回らないといけないので、簡単には確認できません。しばらくドキドキワクワクです(笑)

新しいクリエが・・・

hanaさん の予想通り! 新しいクリエが発表されましたね。 とうとうバーチャルグラフィティ搭載、且つ折りたたみで無いモデルが登場です。TH55、ひかれます。重さ185gも、重いと言えば重いですけど、NX80Vより50gも軽いんです。でもカメラは35万画素かぁ・・・ちょっとつまらないなぁ。 欲しいですけど、私の利用方法だとNX80Vから乗り替える必要も無さそうですので、ちょっと仕様を斜め読みしただけでお終いです。じっくり見てると欲しくなるから。 私としてはクリエよりPowerBook15が欲しいー iBook800CDの見づらい液晶に辟易としてきております。店頭で見る限り、PB15はそこそこまともそうです。いいなぁ。 あっ、そろそろiBookの半年経過レポートでもしましょうかねぇ。だいぶ使い込んで、当初とは違った評価になってきましたので。

メーラーのdateフィールド解釈はくせものでした

板屋かえでの覚え書き さんで、メールのDateヘッダについて調査がされてます。「 mail-entryがバージョンアップ」 いやまあ、うちで配布しているmail-entryのバグ話に絡んでなんですけどね(改善方法ありがとうございます)。私はなーんにも考えずに、コンピューターの世界では日付というのは二桁に決まってる、と思っていたわけです。2月1日なら、02月01日となるに決まってる。ネットショップでの誕生日だってそうやって入力させられます。 ところが、メールの世界ではそうでないらしい。 メールクライアントによっては「02月1日」と、日の部分がひと桁になります。 板屋さんの調査によれば、かの有名なOutlookExpressは、ひと桁派です。月はなぜか二桁です。携帯電話も、機種によって違うかもしれませんがauやvodafoneはひと桁派。けっこうひと桁勢が多いです。ちなみに、私の使っているA5404SとMac用メーラーのGyazMailもひと桁でした。・・・もっとよく調べてからプログラミングしましょう < 俺 えー、同じ過ちは繰り返すまいと、ちょっと調べてみました。googleで一発で引っかかってきたのが、「 インターネットメールの注意点 」内にある この部分 。 えー、RFCに定義されているDateフィールドの仕様を見ていくとそんなに厳密に決まっていないようです。以前は西暦は二桁で良かったとか、秒数は省いて良いとか。 問題は日にちだけじゃなかったのか・・・ それいぜんに、Dateフィールドって言うんですね。Dateヘッダじゃなくて、フィールドを全部まとめてヘッダなんですね。難しいなぁ。 というわけで、とりあえず、西暦を2桁でセットするメーラーではmail-entryは使えませんです。秒数を省くのも同じく。暇をみてなんとかしますので、それまでは他のメールクライアントでしのいでください・・・メジャーどころは大丈夫だと思いますけど・・・ ・・・スクリプトを公開している責任からなんとかしないとと思っていますが、使ってくれている方ってどれくらいいらっしゃるんでしょうか?5人もいたりしたらうれしいなぁ 素敵な思いこみを胸にがんばります(笑)

mail-entry_0.3.2リリースです

こちら からダウンロードしてください。 バグフィックスです。 メール送信日時をエントリーの作成日時に反映させる部分にバグがありました。携帯電話のメール機能は日にち情報を必ずしも2桁で付加するわけではないらしく、不正なエントリー作成日時が登録されてしまいます。パソコンのメーラーでもそうなる可能性があります(RFCという規格には則っているのでメーラーが悪いわけではありません。mail-entryの不備です)。mail-entry側ではそういうパターンの場合は無視するようにしてたつもりが、あくまでつもりだったようです。勉強不足・・・すいませんです。 板屋かえでさん からご報告をいただき、改善ソースも提示していただきましたので、あれがたく取り込ませていただき、暫定対処としました。毎度毎度ありがとうございます~ RFCルールに則ったメールの日時ならちゃんと取得できるように今後改善するつもりです。

zenback