* ホームに戻る

2005-03-24  yumi-ii.squares.netについて―その1―

23日からyumi-ii.squares.net（サイト名yumi-ii）を公開しております。予告では4月から運用することにしていますので，いまのところ仮運用です。

以下にFAQのようなものを挙げておきます。

yumi-ii.squares.netとは何ですか

yumi-ii/area_muronoの後継サイトです。

yumi-ii/area_muronoとの違いは何ですか

名前がちょっと違います。サーバが違うのでURLが違います。「見るひと」の立場でいうと違いはURLだけです。

yumi-ii/area_muronoはこれからどうなりますか

トップページのみyumi-ii.squares.netのミラーサイトとして残ります。トップページが消えることはありませんし，ミラーサイトですので更新が止まって放置されることもありません。yumi-ii.squares.netが更新されると数分後にはyumi-ii/area_muronoも更新されます。

「みえないオトモダチ」はどこにありますか

「540.リンク集」（仮名）にあります。

»固定リンク

2005-03-13  Movable Typeいまさら大問題―その後，解決しました―

エントリーの読み出しで苦戦しておりましたが，問題を解決できたので経緯を記しておきます。

「Berkeley DBが足かせになっているのではないか，まずDBを変えてみよう」と思い，MySQLをインストールしてみました。DBの諸設定を済ませてエントリーを読み出してみたら，1回目で639件処理することができました。Berkeley DBよりも3倍以上のエントリーを読み出せたのです。

2回目は310件，3回目は228件という具合に，読み出せる件数が減る傾向は変わらなかったものの，スループットが改善したので致命的な問題にはなりませんでした。合計7回に分けて全件（約1,800件）の読み出しに成功しました。

「再構築に時間が掛かる」という問題も，DBを変えたら解決しました。

いやはや，危うく騙されるところでした。私は模擬環境の構築前に「ブログたち」の導入記を調査していました。そのとき「Berkeley DBとMySQLでは性能に違いがない」という記述を発見していたので，疑わずにBerkeley DBを選んでしまいました。これが罠でした。エントリーの件数が少ないと，DBの性能差が分からないだけだったのですね。

»固定リンク

2005-03-12  Movable Typeいまさら大問題

こんばんは，yumi-ii/area_muronoをMovable Typeに移行する作業をしておりました。移行作業はローカル環境による「模擬」と，リモート環境による「本番」に分けています。模擬環境の構築中に実時間で処理できない問題が発生してしまい，このままでは導入判定を通過できそうにありません。いまさらですが大問題なのです。

件数が増えると読み出しが困難に

Movable Typeでは，外部ファイルをBLOGに取り込むことができます。この機能を「エントリーの読み出し」と言います。ひとつのエントリーはひとつの記事に対応します。エントリーの数が記事の数となるわけです。

yumi-ii/area_muronoのエントリー数は，だいたい1,800です。Movable Type上にそっくり構築するには，1,800件のエントリーを読み出さなければなりません。最初，私は何のためらいもなく1,800件を読み出してみました。すると200件ほど読み出したあとに，WWWサーバがタイムアウトしてしまいました。

タイムアウトしても，途中まで読み出したエントリーは消えずに残ります。つぎに追加（2回目）で読み出せたのは130件でした。3回目は70件でした。4回目は64件，5回目は42件でした。合わせて800件ほどを読み出したあとには，一度に28件しか読み出せなくなっていました。

どうもエントリーの数が増えれば増えるほど，読み出しに掛かる処理量が増えてしまうようなのです。タイムアウトの時間は一定なので，一度に読み出せるエントリーの数がどんどん少なくなってしまうのです。

この調子では残りの1000件を読み出すのは，まず無理です。どうもDBの性能が足を引っ張っているように見えるので，DBを変えればいくらか改善できるのかもしれません。いまはBerkeley DBを使っています。Movable TypeではBerkeley DB以外のDBも使えるので，ほかのDBに変えてみることにします。DBを変えてもスループット（単位時間あたりの処理量）が改善しない場合は別の作戦（それが何であるか定かではない）を考えなければなりません。

再構築に時間が掛かる

エントリーを読み出しただけでは，HTMLファイルはまだ作成されません。Movable Typeではこのあと「再構築」という処理をすると静的なHTMLファイルが作成されます。（余談ですが，「ダイナミック・パブリッシング」という動的な生成機能もあります。）

この再構築なのですがとっても時間が掛かります。タイムアウトすることはないものの，エントリーの件数が増えるとどうなるのか心配なところです。

長期運用性が不明

環境を移してしまったあとの話です。エントリーの数はこれからどんどん増えていきます。これから5年以内にエントリー数は3,000件を超えてしまうでしょう。試してみなければ分からないことですが，Movable Typeがそれだけの件数を裁けるのか怪しい気がします。

ともかく，ほかのDBの効果を検証してみてやっぱり実時間で処理できないなら（MySQLを試してみるつもり），当分のあいだ頭を抱え続けることになりそうです。

»固定リンク

2005-02-20  Movable Typeその後のその後

こんばんは，BLOGソフトのMovable Type（以下MT）を使い始めてひと月弱が経過しました。私の使用目的は，既存のコンテンツをMTに移植して運用することです。そういう使い方をしてみて，気づいたことをお話します。

日記のようなコンテンツに向いている

この評価は肯定的に解釈してください。同じ話題が時系列に並ぶコンテンツには，MTが有効だと思いました。元々BLOGがもっている性質そのものですので，当たり前といえば当たり前なのです。

対して「話題がさまざま」「時系列に並ばない（並べられない）」ようなコンテンツは，MTに向かないと思いました。既存のコンテンツはBLOGではないので，すんなりと移植できないことがあるのです。移植できたとしても，どうも構造が歪（いびつ）になってしまい，わけの分からないサイトになってしまうことがあるのです。

私の場合，かなり強引に移植作業を進めておりますが，サイトの枠組みが合わない部分は「移植しない」という選択肢もあると思います。

セキュリティーにやや問題

MTはCGI（Common Gateway Interface）で動作します。標準の手順どおりに設置すると，WWWに公開されるファイルやフォルダが恐ろしく多いことに気づきます。実行スクリプト以外の作業ファイルや作業フォルダも，WWWでアクセスできる場所に配置されてしまうのです。

関係のないファイルやフォルダを公開フォルダ（public_html）の外に置きたかったのだが，どこまで弄ってよいのかよく分かりませんでした。下手に弄ると面倒なことになりそうだったので，httpdのアクセス制限機能だけで対処しました。

セキュリティーに不安が見え隠れするのは，たぶん「大事なものは運用するな」「バックアップ取れ」「乗っ取られるくらいなら自爆しろ（なぞ）」というお告げなのだと思います（再三なぞ）。

コンテンツの修正機能には難あり

コンテンツは「生モノ」なので定期的な保守作業が欠かせません。MTでは「エントリー」という単位でコンテンツを区切っています。エントリーを修正するにはMTにログインしてHTMLフォーム上で作業するか，「書き出し」機能を使ってテキスト形式で外部に出力してからローカルで作業することになります。

私がよく使うのは書き出し機能なのですが，どうも用途が違うらしく使い勝手がよくありません。エントリーひとつひとつを書き出すことができないのと，書き出しの反対「読み込み」をしたときにエントリーを上書きできないのです。サイトの規模にもよりますが，HTMLフォームで修正していると，終わる頃には「おじいさん」になってしまう危険があります。書き出し機能を積極的に使いたいので，いろいろと支援ツールを拵えて対処しようと思います。

»固定リンク

2005-02-13  Movable Typeその後

こんばんは，yumi-iiサイトのMovable Type（MT）への移行のお話です。「BLOG云々より，いまの訳の分からない状況をなんとかしなければ」と思い，コンテンツの統合案と日程を考えてみました。

「やること」と時期

DOMAIN          2005/3  2005/4  2005/5  2005/6  2005/7  2005/8
----------------------------------------------------------------------

orange      ------>> shiraneyo（MT）に統合
loveshira   ------>> http://yumi-ii.xxxxxxx.net/shiraneyo/
                     BIGLOBE上のイメージ削除

nijishira   ------>> 公開終了。イメージ削除

area_muro   -------------->> yumi-ii（MT）に昇格
                             http://yumi-ii.xxxxxxx.net/ 
                             BIGLOBEとミラー化

homupe      ---------------------->> homupe（MT）に変更
                                     http://yumi-ii.xxxxxxx.net/homupe/ 
                                     BIGLOBE上のイメージ削除

osanpo      ----------------------------->> homupe（MT）に統合
                                            BIGLOBE上のイメージ削除

yuminet     ----------------------- 変更なし ----------------------->>

----------------------------------------------------------------------
DOMAIN          2005/3  2005/4  2005/5  2005/6  2005/7  2005/8

説明

一言

いつものように，閲覧する人にはなんの関係もありません。それとMovable Typeではどうしてもサイトを作り込めないときは，べつのCMS（Content Management System)を導入するかもしれません。

»固定リンク

2005-02-03  断続的に多い日

こんばんは，ここ数日，量が多かったり少なかったりムラになっております（なぞ）。「パパ活用テクニック第4回」ならびに予告済みの大衆浴場報告の公開日は未定です。折角なので少々。

Movable Typeの導入評価だいたい終わる

奇妙なファイル名の問題は解決できました。ユニーク値の問題も解決できそうです。長期間運用した場合の問題はまだ微妙ですが，イザとなったらDBから記事データを引っ張り出してファイル化してしまえばよいだけの気がします。

というわけで，すぐにでもBLOG化できそうです。ただそのままBLOG化したのでは，わけが分からない状態も移植されてしまうので（知りすぎて不幸な人が増えるといけないから，意図的に意味不明にしているのですが←なぞ），サイト内で一度コンテンツを整理しようと思います。

「オラオラまにあ」の続編

「気味が悪い」と評判，ヴァーチャルY兄貴の音声コンテンツに動きがあるかもしれません。まだ構想段階なのでネタは秘密にしておきます。あの声と口調，仮想人物の性格が好きな人はお楽しみに。オラオラ（ふめい）。

恐るべし光老化

去年の夏，何度か日やけの真似をしたというお話をしました。顔に日やけ止めを塗って太陽光を浴びたので，顔は日やけしませんでした。脚や腕の日やけはすっかりなくなりました。ところが一箇所だけまだ黒いところがあります。その個所とは足の甲です。サンダルの跡がまだついているのです。まったく紫外線って恐ろしいですね。

»固定リンク

2005-01-31  Movable Type導入の課題

こんばんは，yumi-iiサイトをMovable Typeに移植する作業をしておりました。ローカル環境のWWWサーバ（WindowsのIIS）にMovable Type Ver. 3.122-jaをインストールして諸設定，さらにはテンプレートの書換えとログの一部のインポート（読み出し）までしてみました。

Movable Typeに移植したyumi-iiサイト

＜画像の説明＞Movable Typeに移植したyumi-iiサイト。印刷プレビューの画面。

すぐに運用できそうな状態に見えますが，使ってみていくつかマズイところを発見しておりますのでお話します。まだ試用して1日なのでおかしなことを言っているかもしれませんが，そのへんは気にしないでください。

記事にユニーク値が割り振られているのか

ユニーク値とは「ほかのモノと重複しない値」です。例えばこの記事のユニーク値は「11071007915」です。yumi-iiサイトでは「YUMI-CODE」という独自のコンテンツ識別値を導入しており，コンテンツを正確に区別できるように工夫しています。私はMovable Typeにも似たような機能があると思っているのですが，まだ発見していません。

トラックバックIDがどうもBLOG内でユニークらしいので，この値をユニーク値の替わりに使ってしまってもよいのかもしれませんが，用途が違う気がします。元々WWWに公開されたコンテンツを結びつけるためのものだろうし，管理画面で利用者が意識できるものでもないので，記事のユニーク値をどう扱っているのか（どう考えているのか）不明です。

ファイル名が不気味である

過去の記事にリンクを張りたい，ということがよくあります。普通だとHTMLファイルのURLを書けばよいだけなのですが，パス名とファイル名を見ると「...2004/12/post_6.html」だったり「...2005/01/2.html」だったりします。いかにも一時的に生成したファイルみたいです。再構築するたびにファイル名が変わってしまうのではないか，という不安があります。ファイル名の書式を指定できるのかもしれませんが，気になるところです。

長期間運用できるのか

いちばん気になっているのは，長期間運用した場合の性能です。例えば記事が数千件を超えると計算量が増えてまともに動かないとか，記事の書き出しができなくなるといった問題です。「2000件処理するためには1000件処理するための倍の時間が掛かる」だと良いのですが，これが指数的に増大するようだと大問題です。私は大量の記事を扱ったときの性能を，とても重視しています。ちょっと使ったくらいでは気づかないし，問題に気づいた頃にはすでに手遅れなんてことになるからです。

»固定リンク

2005-01-28  多い日が終わりそう

こんばんは，1月上旬から多い日が続いておりましたが，ようやくひと段落しそうです。ついでに近状を少々。

Movable Typeを導入するかもしれません

Movable Typeとは，BLOGソフトのひとつです。ここ数日「BLOGの方が便利なのかな」と思えてきました。

私は日々の生活で，いかにコストを減らすか考えています。いちばん大事なものは時間です。時間泥棒の被害に遭わないために，いかに時間というコストを減らすかに力量を注いでいるのです。

yumi-iiサイトの更新はかなりの部分が自動化されていますが，それでも更新には手間が掛かります。どうやったらコスト削減できるか考えてみたら，既存のソフトを使った方がよいと思えてきたのです。BLOGソフトは，成長曲線でいうと安定期に入った頃だと思うので，取り扱いが簡単で，しかも運用の自由度が高くなっているはずです。いまの時点での構想を箇条書きにします。

Mac mini見てきました

某家電量販店に展示品されていました。いつものように買いませんけど（ふめい）。

私は「Macがきた」でお話したとおり，いまから1年前にMacを導入しました。じつは事後報告をあまりしなかったのには理由があります。以下，iBookで遭遇した現象です。

安物だからというのもあるのでしょうけれど，品質管理が悪いと思いました。90年代後半のWindowsマシンに似ているのかなと思いました。それとGUIが複雑だからだと思いますが，画面描画が鈍いです。プロセッサはPowerPC G4 800MHzなのですが，MS-Wordを使ってみるとPentiun-II 300MHzのような使い心地でした（奇妙なことにPentiun-II 300MHzという構成は，90年代後半のPCそのものです）。

というわけで詳細な事後報告をするとMacユーザを敵に回してしまうので，控えていたのです。今回のMac miniにも同様の罠が仕掛けられているかもしれません。興味のある人は，人柱が出来てから検討した方がよいと思います。

ホムペたちが絶滅しそうです

SNSがホムペを侵食しているという説は，本当のような気がします。もちろんきちんと検証したわけではないので，どこまで食われているのか分かりません。でもここ半年間で，ホムペたちが停滞していることだけは確かです。もともとホムペしなくてもいい輩がホムペを止めただけかもしれませんが（毒）。

ホムペの灯が消えてしまいそうだというのに，自分自身に何か困ったことが起きたのかといえば何も困っていません。むしろ，迷惑な人が減ったおかげで（猛毒）ホムペ全体の品質はまえよりも良くなった気さえします。

ミニラさんへ

最後はなぜか公開メールです。

「『既婚パパの分布には地域差がある』という指摘は興味深いです。たぶん過去に調べた（調べようとした）人は，だれもいないと思います。謎を解き明かしたら論文が書けそうな気がします。世の中，謎だらけですが真相を解明するためにも，お互い調査を続けていきましょう（ふめい）」

»固定リンク

* ホームに戻る