mieki256's diary

某サイトの更新作業を、今のところ自分がエディタ＋手打ちでやってるのだけど。できれば先方の方がサクッと作業できちゃうほうがいいのだろうなと思っていて。なので、もう結構長い間、時々思い出したように、CMS(コンテンツマネージメントシステム)だの、WYSIWYGタイプのHTMLエディタを探していたり。

しかし…。

• CMS ... 利用しているサーバが、CGIを動かせないサーバなので、設置ができない。ローカルで動かして静的htmlを出力できるCMSならどうにかなりそうだけど、該当機能を持ってて、かつ、イイ感じのCMSがさっぱり見つからず。
• HTMLエディタ ... サイトの更新頻度がそれほど高くないので、自分はともかく、先方では使い方を忘れそうな予感。よほど簡単な操作じゃないと、オススメできそうにない。また、有償製品については、実際使えるかどうか分からない状態で購入をオススメするのも難しく。

イイ感じの選択肢が無いなと悩み続けているわけで。

しかし昨晩、突然閃いた。先方ではチラシすらExcelで作ってしまうぐらいに、日々、何でもかんでもExcelで作業している。だったら…。htmlの更新作業も、Excelでやってしまえばいいんじゃないか？ それなら、操作方法を忘れてしまう、なんてことはないだろう。

幸い、更新すべき部分は大体決まってる。

• pdfを用意して、所定のフォルダに放り込んで、
• 商品名(?)や期間を書きながら、pdfにリンクを張って、
• FTPでアップロードするだけ。

たったそれだけの作業なわけで。

• 記事一つに対して入力すべき項目は、商品名、期間、リンクを張るpdfファイル名、ぐらいだから、セルに書いとけば済むだろう。
• テンプレートhtmlを読み込んで、所定の部分に、Excelのセルを読み取って作り上げた、html文字列を埋め込んで出力すればいい。
• FTPは、FFFTPあたりを使って、ミラーリングをすれば済みそう。バッチファイルを用意するのでもいいし、Excelから呼び出せるならそれでもかまわない。

なんだかできそうな気がしてきたり。

というわけで、Excel VBA を勉強中。

• Excel 2003 を起動して、ツール → マクロ → Visual Basic Editor を選択。
• 挿入 → 標準モジュールを選択すると、標準モジュールが追加されて、ウインドウが開く。

Sub DumpTest()
    ' セルの内容をポップアップ表示
    Dim i As Integer
    Dim j As Integer
    Dim s As String
    i = 2
    s = Cells(i, 1).Value
    Do Until s = ""
        For j = 2 To 3
            s = s & "," & Cells(i, j).Value
        Next j
        MsgBox s
        i = i + 1
        s = Cells(i, 1).Value
    Loop
End Sub

とりあえず、Cells(1,1).Value でセル内容が読み取れることは分かった。

上手く行きそうだなと思ったけど、甘かった。ファイルを保存し直して、Excelを再起動してまた読んだら、「マクロが入ってるぞ。怪しいファイルだぞ。マクロは有効にできないぞ」と言われてしまって。こんな状態になるのでは、相手先に使ってもらうわけにはいかないな…。いい考えだと思ったんだけどな…。

しかし、Excel で元データを打ってもらって、何かしらのツールでhtmlに変換する、という方向性はイケそうな気がする。Rubyで .xls を読んで html に変換するツールを書いてみるか…。

RUby + WIN32OLE について検索したら、WIN32OLE が実に強力なモジュールであることがようやく分かってきて。

例えば、 _Rubyist Magazine - Win32OLE 活用法 【第 1 回】 Win32OLE ことはじめ の最下部を眺めれば/リンクを辿っていけば、IE、Excel、Adobe Illustrator まで Ruby から操作できますよと説明されていたり。

これほど強力なのであれば、どう考えても、Ruby から WSH を呼び出して云々とかやるより、WIN32OLE を使ってどうにかするほうが正解だよなと。それはつまり、WIN32OLE を殺してしまうモジュールがあったとしたら、ソイツを真っ先に捨てたほうが幸せになれる、ということでもあり。

てなわけで、DXRuby 1.5.1dev を捨てることにします。WIN32OLE を殺す時点で論外。それはつまり、WSH を呼んでどうにかするやり方も捨てるということで。そこは WIN32OLE を使うべき。なんとかして使えるようにするべき。

まあ、DXRuby 1.5.0dev、1.5.2devは、WIN32OLEと共存できるので、そっちを使えば済む話で。ただ、1.5.2dev は、マウスクリックが効かなくなる不具合があるから、正式リリース版の 1.4.0、もしくは 1.5.0dev、あるいは、1.5.3dev が出てきたらそちらを使うのが妥当だろうと思うわけですけど。

BTS = バグトラッキングシステム。バグの報告、修正までの過程を管理しやすくるためのツール。

DXRuby開発版で見つけた不具合を公式掲示板で報告してしまったわけだけど、それは正しくないんじゃないか、本来はその手のソレで報告すべきなんじゃないか、と思ったりしたわけで。SourceForge 上で BTS が用意されてるなら、そっちを使って報告すべきなのかなあ、と。でも、SourceForgeにBTSは用意されているのだろうか？

_SourceForge.jpではじめるオープンソースプロジェクト：第5回　プロジェクトの初期タスクを片付けよう (3/3) - ITmedia エンタープライズ によると、SourceForge にも BTS はついている、らしい。記事を読んでみても何が何だか分からないけれど。

試しに、 _DXRuby プロジェクト日本語トップページ - SourceForge.JP を開いてみたところ、「バグを報告する」というリンクがちゃんと存在してた。しまった。ここから報告すべきだったのか。と思ったけれど…。

リンクをクリックしてみると、「新規チケットの登録」というページが開く。

チケットって何だ？ もうこの時点で、一見さんお断り状態。

_TicketUser - SourceForge.JP ヘルプ - SourceForge.JPドキュメント管理 - SourceForge.JP に説明があった。

チケットってなに?

オープンソースプロジェクトに参加している/オープンソースプロジェクトの成果を 利用していると...

こんなバグがありました
こんなことをしないといけないね(例えば、次のリリースまでに)
こんな機能がほしい
ここの機能がよくわからないんだけど、教えて
こんなパッチはどうかな?
ここをこういう風に仕様変更しようと思うけど、どうだろう?

といった「誰かがなにかしないといけない/誰かがなにかをすること」がたくさん 発生すると思います。

チケットシステムでは、そういった「誰かがなにかをしないといけないこと/誰かがなにかを すること」を「チケット」という形で登録して、その処置の過程を記録/追跡したり、 その情報を検索できるようにするシステムです。

TicketUser - SourceForge.JP ヘルプ - SourceForge.JPドキュメント管理 - SourceForge.JP より

要するに、チケットとは、投稿の単位っぽい。「投稿」「記事」「カキコ」「親スレッド」てなあたりを、SourceForge 上では「チケット」と呼んでいる模様。「新規チケットの登録」てのは、「記事を投稿」みたいなものなんだろう。たぶん。

「新規チケットの登録」画面には、赤い文字で以下のメッセージが表示されている。

「ログインしていません。ログインしていない状態でのチケット投稿では、報告者へのチケット状態変更のメールでの通知が行われません。変更を逐次追いたい場合は、ログインするか、作成されたチケットのRSSを取得してください。」

そうか。ログインしなきゃ、利用できないのか…。

と、思ってしまったのだけど。でも、もしかしたら、そうではないのかも。アカウントを取って、ログインした状態で投稿することもできるし、アカウントを取らず、ログインしてない状態で投稿することもできるのではあるまいか。試してないから誤解してるかもしれんけど。

• ログイン状態で投稿すれば、その投稿に誰かがレスをつけた時、「あんたの投稿に誰かがレスをつけたよ」とメールで教えてくれるんだろう。たしかに便利。レスがついたことに気付かない、という事態は避けられそう。
• 非ログイン状態・アカウントを持ってない状態で投稿すると、誰かがレスをつけても、そのこと教えてもらえない。自分でページを見に行かないと、レスがついてるかついてないかは分からない。ということなのだろう。

でも、この想像が当たってたとしても。いきなり「ログインしていません」と言われたら、フツーは「ああ、ログインしないと使えないシステムなんだ…。じゃあ、俺は利用できないや。アカウント持ってないもん」と思いそう。やっぱり、一見さんお断り状態のような気がする。

自分ですら、「チケット？ ログイン？ アカウント？」と頭の中が「？？？」になったのだから、フツーのユーザさんは、このBTSでバグ報告なんかできないだろうなと、うっすら思えてきたり。英語圏の人や、オープンソースプロジェクトに親しんでる人なら、すんなり使えるのかもしれない。でも、日本人には、この各用語はしっくりこないだろう…。

喩えるなら…。普段アニメなんか見ない人は、ガンダム本編内で「モビルスーツ」「モビルスーツ」と呼んでるだけで「？」になるらしい。「ロボット」と言ってくれれば分かるのに、みたいな。SourceForge の「チケット」にも、それと同じ匂いを感じる。

逆に(?)、 2chとか、ニコニコ動画とか、そのあたり、よくできてるよなあ、練ってあるなあ、となんだか感心してしまったり。小学生ですら書き込みできるもんな…。投稿のハードルを低くすることに、かなり神経を使ってる印象。そりゃ人が集まるわな。

閑話休題。

今まで投稿された記事は ―― バグ報告の一覧は、どうやったら見れるのだろう？

上のほうに「チケット」というタブがあることに気付いた。「チケット一覧」「チケットの種類一覧」というのが選べるようで。そこを選べば一覧で見れるらしい。

でも、そもそも、「チケットって何？」状態で、そこにバグ報告の一覧があると分かるものだろうか…？ となると、報告された各記事を眺めることすら、知らない人には難しいのでは、という気がしてきた。

ここまで調べてみて、なんとなくおおよその使い方は分かりそうな気配はしてきたけれど。しかしコレ、仮に自分が使えても、他の人はどの程度使えるのかなと不安になってきたり。例えば小中学生が、○○を使うとゲームが作れるらしいと知って触り始めたとして、バグっぽい動作を見つけて報告しようとした際に、このBTSを使えるかといえば、まず使えないだろうという気がする。どう考えても、公式掲示板のほうに書くよなと。掲示板なら、2ch、ニコニコ動画、mixi、そのあたりと同じ感覚で使えるし。既にバグ報告がされてるかどうか調べる際も、公式掲示板を眺めるだろう。SourceForge のソレは、バグ報告の一覧を眺める方法すら分からないのだから。

ということで、SourceForge に BTS があるならそっちを使うべきかなと思っていたけど、公式掲示板に報告したほうがいいのかもなあ、と思えてきた。

これは、DXRuby等に限定した話じゃなくて、SourceForgeというサービスに対する印象論なわけだけど。報告内容を、別の誰かが眺めることすら難しいのは、ちと致命的な気がする。それでは、public な場所に投稿する意味がない。誰もが容易に閲覧できる場所でバグ報告するから共有知になるのであって、見ることがちと難しい場所で報告してみても、それは共有知になりづらい。共有知にならないなら、いっそ作者様に直接メールを送ってクローズドで話を進めたほうがマシなのかもしれない。

オープンソース開発にどっぷりハマってる人にとっては、SourceForge の BTS は便利だろうし、どのページもpublicに見えているだろうと想像するのだけど。でも、そのプログラムにちょっと興味が湧いて触ってみた程度の人が、何か妙な動作を見つけて報告しようとした時に、SourceForge のソレは役に立たない。近づくなオーラを発しすぎている。

喩えるなら、SourceForge は京都の高級料亭なのだろうと。一見さんはお断りだけど、お得意様にとっては心地よいサービスを提供してくれる、そんな場所ではあるまいか。わからんけど。

では、そのへん改善したほうがいいのか？ と問われたら、それも判断に悩みそう。

• 今現在活発に利用してる人達が、「チケット」その他の呼称や、現在のページレイアウトに慣れているなら、変えないほうがいいんじゃないの、作業効率落ちるでしょ、という気もするし。
• 誰でも気軽にバグ報告できるようにしといたほうが、プログラムの完成度は高まりやすいし、プロジェクト開発も活発になる、と考えるなら、改善したほうがいいだろうということになりそうな。
• でも、改善するにはコストや手間暇もかかる。
• SourceForge本家と色んな部分がずれてしまうと、それもそれで問題がありそう。
• そもそもBTSって、一部のプロジェクトを除いて、あまり普及してない気もする。
• 誰でも投稿できるようでは、ノイズが増える・S/N比が悪くなって開発に悪影響を及ぼす、と思う人も居るかもしれない。

改善したほうがいいのかどうか、それすら外野にはよくわからんです。

とりあえず、「コレ、フツーはバグ報告すら無理ッス」「使い方分からんです」「別に掲示板があるならそっち使わせてほしいかも…」と思ってしまいました。とメモ。

昨晩部屋の中に蚊が出現したので、仕方なく蚊取り線香をつけたのですけど。予想通り、酷い悪夢を見ました。あまりに悲しい内容で目が覚めてしまって、マジ泣きしそうに。

蚊取り線香は目にもクルけど、何より神経にクルんじゃないかなあ、と勝手に想像しております。蚊の神経をおかしくする薬品だもの、生物である人間にも、微量だろうけどダメージ与えてしかるべきだよなと。少なくとも自分の体感では、蚊取り線香を使うと百発百中で悪夢を見るし。 *1

蚊取り線香程度で影響があるなら、新築のマンション等に使われてる建材から揮発するアレコレも、地味に効いてたりする可能性がありそうだなと思えてきたり。

建材からの影響なんてあるわけないだろ、と笑う人が居るかもしれないけど。 _シックハウス症候群 、 _化学物質過敏症 という話もあるし。また、 _ナポレオンのヒ素中毒死亡説 の中には、当時の壁紙にはヒ素が使われていて云々、という話もあるし。現代では気付いてないけど、後世になって「これは人間にとって毒物じゃねえか。こんなもんを部屋の○○に使ってたんか」と解明される可能性はあるかもしれないよなと。

実は鬱病の原因もこのへんが絡んでたりしないかと思ったりもするんですけど。例えば…。

• 患者の75%が新築マンションに住んでた、部屋の窓を閉め切った生活をしていた、蚊取り線香を頻繁に使ってた。
• なおかつ、鬱病ではない人の90%が、築○年以上の建物に住んでいた、部屋の窓を開けておく生活をしていた、蚊取り線香をほとんど使っていない。

てなデータが出てきたら、これはもしかして、ということになるんだろうなと。まあ、調べるのが大変だろうから誰も調べないだろうし、そもそも鬱病ではない思われる人をどうやって判別するんだろうという気もするので、調べようにも調べられないのかも、と思ったりもしますが。

なんかこのトンデモ仮説、前にも書いたような気がする…。

自分、基本的に、鬱病等の発生って、実はハードウェア面の影響も無視できないんじゃないだろうかと思ってて。ストレスが原因だ、で世間的には片づけてるけど、実は意外なところにも原因があったりしないのかなと。まあ、ハードウェア面のソレもストレスと呼べるわけだから、ストレスが原因とするのは正しいのでしょうけど。

ストレスが、という決めつけ方(?)は、下手すると精神論に走りやすい。だけど、これがもし、ハードウェア面にも原因があったと分かれば、圧倒的に対策がしやすいわけで。

真冬の屋外プールで泳いでる人が風邪を引いた時に、「お前のモノの考え方に原因があるから風邪を引くのだ」と決めつけるようなことをしてないだろうかと。そもそも真冬のプールで泳がなければ風邪を引く確率下がるよなと。労働時間を減らす、休暇を取らせる等は、真冬のプールから引っ張り上げてやるようなものだけど、どういう部屋に住んでるか、どういう部屋の使い方をしてるか、どういう薬品を日常的に使っているか、そのあたりも真冬のプールに相当していたりはしないのかなあ、と。

極端な話、蚊取り線香が原因で鬱病になってた、と分かったら、今まで俺達何やってたんでしょうか、という話になりそうだなと。そんな馬鹿な話あるわけないと笑う人が居るかもしれないけれど。例えば昔の人類は、 _化粧品 で鉛中毒や水銀中毒になってましたから。当時はどうしてそうなるのか分かってなかったけど、日頃の生活の中で頻繁に使うソレが実は物理的にダメージを与えてた、という前例はちょこちょこあるわけで。昔の人も使ってたんだから安全なはずだ、という予想はケースバイケースで成立したりしなかったりするわけで。…まあ、今の蚊取り線香は除虫菊を使ってないので、昔の人が使ってない道具になってますけど。

このへん、ただの願望なんでしょうな。分かりやすいところに原因があってほしい、ハッキリしてる対策方法が発見されたら嬉しいと。蚊取り線香を使わなかったり、新築マンションを避けるだけで、鬱病になる確率を下げられたら、そりゃ随分楽になるだろうな、てな夢想に過ぎないのかも。

でも、実際に関係あったとしたら、皆でズッコケるだろうな。俺達何やってたのトホホ、みたいな雰囲気に。

---