私が出勤する頃、秋葉原の駅では掃除(オジ|オバ)ちゃんが階段を掃除している。 通行人を、それとなく意識しつつ、それとなく無視しつつ。
いつも「乗客である通行人の方が優先だろ」と思いつつ、いつ飛んでくるとも知れぬゴミに精神を集中するのだ。
さて、そんな(オジ|オバ)ちゃんたちは「上がってくる」のである。 ナゼだ。 ナゼに重力に逆らうのだ。 「地球の重力に魂を引かれた人間たち」ではないのか?
階段の各段を横に掃く。次の段へ移動する。最後に端にたまったゴミを順次下へ掃き落としていきチリトリで取る。 これが王道だろう。 しかし「次の段」は上の段か、下の段か。 iterator++ なのか、 iterator-- なのか。
「横に掃く」という動作で一部が下へも落ちるのは免れないのだから、私は、上の段から下の段へがベストだと信じて疑っていなかったのだが、ことごとく(オジ|オバ)ちゃんは上がってくるのだ。
…あそか。掃く時は斜面を向くのが自然で(逆だと怖いし掃きにくい)、さらにその姿勢だと「前進」である「上の段」への方が楽か。
うむ。「清掃人としての知恵」だな。 彼らは「完全」のかわりに「効率」を選んだのだ (1ループあたりの出来は下がるがコストも下がる。単位時間あたりのループ回数が増えればトータルで出来も上がるのかもしれぬ)。
新 WikiEngine の開発にははいったけれども、稼働するのはずっと後になりそうなので、今使用している engine もまだまだ手を入れて遊びます。
WikiName と違って[[, ]]で区切るページ名は DanglingLink の時に「どこまでが名前かわからない」かなと思い、 CSS で破線をつけるようしてみる。
今までは CGI スクリプトの最初で必ず exclusive lock をかけるというバカ lock だった。 これだと WantedPages のような時間のかかる処理のあるページにアクセスがあると、他のページの read が軒並み sleep させられてしまう。
なので、書き込みのないアクセス時には shared lock で flock するように修正。 これで read vs read でのアクセスが待たされたくなったはず。 それでも時間のかかる shared lock なアクセスがあると write 系のアクセスはやっぱりしばらく待たされてしまうのだけれど、write 系は頻度が低いから……。
やはり Wiki のページ間のグラフが見れるようにしたいな。 emacs-wiki では Graphviz と連携してグラフを描かせてみているんだけど、NaneyOrgWiki のあるレンタルサーバではサーバサイドでやるのは辛いかな。
Java Web Start な Java アプリケーションと連携するなら簡単かも。 ということで、以前からチェックしていた JGraph を使ってみる(といっても HelloWorld)。
が、実際には日本語フォントの設定になだれ込む事に。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。