あーありがち

過去の日記 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ PukiWiki 1.4.5

PukiWiki/ダウンロード/1.4.5

個人的に気になるところだけピックアップ。

• スキンのナビゲーション部分の設定が楽に
• skin および CSS のファイル名変更
• 1.4.5 用の skin が 1.4.4 以前で動かなくなる
• tDiary テーマ対応（どの程度の対応かはよく分からないけど）

skin の修正時、PHP をベタベタに書かなくてよい部分が増えたのは歓迎。

デザインしなくていいから楽でいいけど、tDiary テーマを Wiki で使うのって HTML の意味的には明らかにおかしいんだよなぁ。PukiWiki くらいのユーザー数が居れば tDiary テーマに従わずに PukiWiki テーマを作りやすくする方向でよかったように思う。将来的にはそうなるかもしれないと期待しておくことにする。

calendar プラグインや diary プラグインを使ったとき（ないけど）に tDiary テーマが最大に生きる、という方向だとスマートかな。

バグフィックスが入ってないような気がするんだけど、1.4.4 → 1.4.5 のアップグレードは問題がなければ無視してよいってことか？ それにしても 0.0.1 の修正にしては影響範囲が大きいような。PHP 本体のようなアップデートのあやうさを感じるのは相変わらずですな。

_ WMI がなんだか分かっていないんだけど

WMI関係 （ハニーポッターの部屋）

メモ。scriptmatic は Perl と Python が使えると。Perl か。。。Python か。。。

_ Ruby のドキュメント、Python のドキュメント、PHP のドキュメント

Pythonのマニュアルは、Rubyのリファレンスマニュアルより、ずっと良い

Python のマニュアルは量が多いのは分かっているけど真面目に見たことないのでなんとも言えない。ただ、Ruby のリファレンスマニュアルがなんだか微妙だという印象は強い。まつもとさんはまぁまぁだと思っているみたいだけど、個人的には「リファレンスマニュアル + 逆引き Ruby」でまぁまぁかなと思っている。

とにかくリファレンスマニュアルは記述が質素すぎて自分のほしい情報への取っ掛かりにしにくく、Namazu で検索してもタイトルでは意味がまったく分からないことが多いような気がする。ページをもう少し細かく分けた方がいいのかもしれない。*1PHP のマニュアルのようにものすごく大量なのもそれはそれで確かに扱いにくいんだけど、検索に関して言えば PHP の方はほぼ目的のものが一発で見つかるので助かる。

あと凡例のページを用意してほしいかな。ソースコード内で意味を持ちそうな記号を説明用の記号として使っているので、どこからが説明でどこまでコードなのか判別しにくい。あるいはソースコードをハイライトする RWiki のプラグインのようなものがあればよいのかもしれないけど。よくサンプルコードを見て首をひねってしまう。

Ruby に慣れていれば「こんな記号に意味はない」と一発で分かるんだろうけど、そういう人はそんなにリファレンス見ないと思うんだな。その辺の書き手と読み手の意識のずれが Ruby 関係のドキュメントをよりよくしようとする際のカギなのかもしれない。

_ 初バリウム

健康診断を受けてきた。

噂のバリウムに初挑戦。うわーと思ったがなんてことなかった。炭酸ガスを発生する薬(?)を飲んでバリウムを飲むんだけど、ビール飲んだあとにおいしくもないシェイクを飲むようなもので、期待していたようなつらい体験ではなかった。確かに腹は張るけどまったくどーってことない。

むしろ台に乗せられて身体をぐるんぐるん回すのがびっくりした。なんか右向いてって言われたりあお向けになってって言われたりするんだけど、どっちが何だが混乱して悩んでしまう。別にひっくり返っても右は右なのにね。

_ ティーンネイジャーは渋好み？

ティーンの読解力低下がネット利用に影!? クールなアプローチが効果的 （MYCOM PCWEB）

また、子ども向けに「Kid」という単語でアピールするWebサイトは、ティーンエイジャーからは嫌われる傾向にある点、新たな友だちを見つけて、連帯感をもてるようなWebサイトに惹かれやすい点、派手なチカチカと点滅するようなデザインよりも、シンプルでクールなデザインのWebサイトを好む点など、興味深い調査結果も紹介されている。

日本でもこの調査やってほしいな。面白い違いが出そうな気がする。

連帯感ていうと Web リングとか Planet とかかな？ この辺は日本でも受けてそう。読解力の話は先日の OECD 調査もあって面白げ。気になるのはデザインかな。もともと日本より海外の方がポップなデザインが受けてそうな気がしていたので（お菓子のパッケージとか）、海外のティーンネイジャーが渋好みなら日本はもっと渋いのかとか、逆に日本の方がデーハーなものが受けているのかといった辺りを知りたい。（知ったからって10代受けするサイトを作ろうと思っているわけじゃないんだけど。）

_ ニュースという言葉へのイメージが違うのかな？

ニュースをオープンソース化せよ--Wikiの挑戦 （CNET Japan）

ニュースメディアとして Wiki は使いにくいような気がするけどそうでもないのかなぁ。

技術的にはまず記事のスタブを作って、それに付随する形でそこら中から TrackBack を使って情報と批評をかき集め（「ニュース」となる Wiki ページそのものを汚さない形で集めた方がよいと思う）、それを参考にしながら Wikinews コミュニティの人間が記事を完成させるって形になるのかな？ ちょうど反応リンク集とかまとめサイトを作るノウハウでもっと自動化を進めていったらいいんじゃないかと想像しているんだけど。

でもニュースのようにある程度スピードを要求されるものを同時進行で Wiki 上だけで作り上げていくのは結構骨じゃないかと思う。実際には irc やメッセンジャー、Skype などを Wikinews コミュニティの人間は使うかもしれないけど、そういうツールでのやりとりはうまくやらないとそれこそオープンな公平性に反しかねないような気もするし。それとも MediaWiki にはそういう問題が起きにくい仕掛けがあるのだろうか？ 変更履歴を編集者別に追跡できるとか？

そういやあらゆるニュースに TrackBack できるようになる仕掛けがここ半年以内くらいにリリースされたような気がするんだけど、どこの何だっけ。全然思い出せない。Google 先生にどう聞いたらいいのかも思い出せない。。。どなたかご存知でしたら教えてください。

_ とりあえずスクリプト内のパスワードを隠す

Encrypting Shell Scripts （linuxsecurity.com）

ふーん。

shc - Generic shell script compiler

これか。

上の linuxsecurity.com にも書かれてるけどネットワーク上を生パスワードが流れるかどうかはこのツールの利用と関係ないので注意すべし、と。permission だけに頼らずに、local システム上のセキュリティを少し向上させるものですよ、ってことですな。

_ インターネットとやりとりできる最小 exim4

サーバ稼動させている LAN 内の機械から普段使ってるインターネット上のアドレスにメールを出したいのれす。cron で報告してよこせっていうことなんですが、Debian Sarge で exim4 に初挑戦。

exim4でSMTP

を参考に

dpkg-reconfigure exim4-config

• smarthost と smtp, fetch を利用
• /etc/exim4/exim4.conf は置いちゃだめ（間違って template をコピーして exim4.conf を作ってハマった）
• smarthost をプロバイダの SMTP に
• From: のドメイン名を local で書き換えるようにしておかないと向こうの SMTP に蹴られちゃうかもよ
  • それかドメインを FQDN でなくて実在するものにするか。個人的には FQDN にしておいて送信時に書き換える方が気持ちいい。（どのホストから来たのかすぐ分かるし。）
• .forward は何も設定しなくても有効（というか設定できる環境があるのか知らないけど）
• /var/spool/exim4/ の中に各種ファイルができるのでエラーとかはここでチャックチェック

• relay は localhost だけ
  • このホストを SMTP にして他の機械が外にメールを出す必要はないので。

_ Software Design 2月号

• 特集1 ログからわかるサーバ管理のノウハウ
• 特集2 今すぐできる CVS 環境

特集1 で syslog からのサーバの状態の把握、管理の話がちょっと弱いような。syslog の環境構築の話までがメインて感じで。ツールの紹介はあるけど具体的にどういう風に見る、どういう風に監視する、という話があんまりないのが残念。まー何を監視したいかによるので具体的な話は長くなりすぎると思いますけど。（目的に応じて Perl とかでさくっと書けるレベルを目指してくれというメッセージは伝わります :-）メールサーバのログについては qmail を例に詳しく解析の流れが追える。

特集2 は CVS について一通り触れられているので入り口付近でウロウロしている人がまとまった情報を手に入れるにはいいかも。

特集じゃないけど「SNMP で理解する企業ネットワーク管理のコツ」も前後編の前編があって面白い。来月もげとしときますか。

_ OS 混在環境での WindowsXP で悩む

すっごい今さらな話なんだけど、ActiveDirectory を組まない*1環境で WindowsXP Professional を選ぶメリットってなんだろう？

• ファイルシステムの暗号化

これは例えば起動できないシステムからデータをサルベージしたいってなったときには諸刃の剣のような。つまり壊れてから考えるのではなく、大事なデータは常に別な場所にも保存しておけってことになるのだろうか？ 繋いでおいたら勝手にサーバにデータ飛ばしてくれるような（もちろん目的のホストかどうか確認したうえで認証する ssh のような）仕掛けがないと、手作業運用では絶対破綻するなぁ。てゆーか本当は全部サーバ側でデータ管理しとけばいいんだよな。個人のパソコンでごちゃごちゃ細かいファイル作って管理してる気になってんじゃねーって感じか。

デスクトップなら暗号化を考える以前に建物の出入りを強化するってことになるわけだけど、ノートで持ち出しますよってことになると暗号化できた方がやっぱ安心だし。。。うーん。

• ユーザー管理

これは Home でも net user コマンド使えばよさげ。GUI はどーでもいいし、同時接続数の制限もまぁ問題なかろう。むしろユーザーが勝手にパスワード決めておきながら調子悪いからちょっと見といてって言ったうえで本人不在なんてことが起きる場合は GUI がない Home の方がサポセン的にはありがたいか。

• リモートデスクトップ

VNC で我慢できるし基本的にリモートで使うことないよな。

• 集中管理
• リモートインストール
• インストールやメンテの自動化

んー。どうもこの辺の情報が自分の中で足りないっぽい。

※ 後日、「サポート期間の違い」に気づきました。個人の場合はともかく、計画的な導入と運用を考える必要のあるケースはサポート期間の長い Professional にした方が面倒がないような気がします。

_ 例のヘルプ特許で

例によって otsune さんとこ経由。みなさんのアンテナ感度に依存しまくりだからこそのありがちな日記でございます ;-)

(2/3)「一太郎」判決で識者の意見――世界情報通信サミット・ネット会議より

印象に残ったのは

根来　龍之 早稲田大学　ＩＴ戦略研究所所長／商学部教授 の方の

デザインは意匠権で守れます。ソフトウェアのアルゴリズムの独創性は特許で守られるべきでしょう。しかし、アルゴリズムの特許が、「見た目の処理」についてまで及ぶとすると、それは権利の範囲が広すぎると思えます。競争を抑制して、ソフトウェア産業の発達にマイナスになると思われるからです。もっとも、このことは程度問題であり、アルゴリズムと「見た目の処理」の区分は難しい場合があるでしょうが。

と、村田　初穂 NEC　知的資産事業本部／知的資産企画部　企画部長 兼 知的資産事業本部　統括マネジャー の方の

今回は、そうしたネゴが継続できず、裁判にまで持ち込んだので目立っているだけなのですが。

ですかね。

個人的には ? も立派にアイコンだろうと思うので、ジャストホームの勝訴もそもそもおかしいんじゃないのか、という気持ちだったり、なんでこの程度で株価が下がるのかね、てな気持ちなのですが。株やってる人は特許関係には疎いのか、asahi.com がちゃんと伝えなかったのがいけないのか。

_ SNS を「利用したくない」のか

ほぼ8割の人がSNSを「利用したくない」と回答……？ (/.-j)

設問を見ると

【Q17】 あなたは今後、SNSを利用したいですか？　現在登録している方は、今後も利用を続けたいかどうかをお答えください。

• ぜひ利用したい
• できれば利用したい
• あまり利用したくない
• ぜったい利用したくない

なんだけど、「あまり利用したくない」を「利用したいとは思わない」に置き換えないと意味がおかしくなっちゃう気がする。そもそもサービス名称を知らない人が半分居るのに「利用したくない」という積極的な判断をした人が半分以上いるなんておかしな話。簡単に言えば「知らないけど、別に興味ない」って人が半分くらい居たってことでしょう。

リンク先のストーリーにも書いたんだけど、自分の中には肯定する考えと否定する考えが同居してます。

否定的な考えとしては、

• やっとインターネットによってオープンな環境ができたのに今さらクローズドに逆戻りしてどうする
• referer に残ってる SNS の跡を見ると、どういう文脈でリンクされているのか確認できない気持ち悪さを感じる
• 「ある方面」とか中途半端にぼかした表現を使われたりするのがますます気持ち悪い

肯定的な考えとしては、

• 荒らし、spam に対する精神的物理的コストが減る
• 上の理由によりある程度参加に安心感がある
• サービスが blog、Wiki、ML、掲示板などのポピュラーなアプリ（Wiki はポピュラーじゃねーか）を網羅してくれるとワンストップでなんでもできるので楽

特に肯定する最後の根拠は今後大きいのかなと思ったり。blog も流行るちょい前くらいには自分で MovableType を設置するぞーとか頑張っちゃう人が増えるけど、こんだけ無償で blog サービスが出てきたら自分で設置なんてあほらしくてやってらんないって人が増えるだろうし、普通の人にとって仕組みはどうでもいいはず。そうなったら例えば blog はここで、ML はここで、ってアプリがいろんなサービスに分散してるよりワンストップで全部実現できた方が有利。

ただどうやって収益を作るんだろうという素朴な疑問が残るわけですが。

_ Ruby のドキュメントとかサイトとかここ数日で動きがあったらしい

どーも話についていけないと思ったら羊堂本舗を Sage に突っ込んでなかったのが原因ぽい。そうかそういうことか。わはは。日本Rubyの会Wikiを Sage に突っ込んだらとても悲しいことになったけどしょうがないのだろうか。かずひこさんに Sage のスクリーンショット送り付けて悲しいですって言うべきか？（パッチよこせと言われそうだけど Hiki の HEAD 追っかけなんてやってないよ。）[追記]2月14日にとても悲しいことからとてもステキなことに変わりました。

Rubyホームページへのご意見募集

あげつらうだけなら楽だけど、具体的なアイディアじゃないと面白くないしね。考えてみよう。

• ファイル名が日付なのはいかがなものかと思う

ちょっとギョッとしますね、これは。tDiary を使っている限りしょうがないのかもしれませんが、今なら lily + CVS でいくか、Rubyist Magazine のような方向で構築する方がいいのかなとも思います。もちろん編集などのメニューが見えるのは不格好なのでやめてほしいです。どっちを使うにしてももうちょっとツールの完成度があがってからになるかもしれませんし、コンテンツの移行を考えるとすぐにはどうにもならないと思いますが。

• 本体だけでなくドキュメントにも snapshot とリリースがほしい

Ruby 界隈の人の力があればこれを自動化するのはまったく大変なことじゃないと思うのに、いつまでも正式に HTML ベースのドキュメントをリリースしないのはどうかと思います。正直言えば「1.8 がリリースされてからいったいどれだけ経ったと思ってんだ」という感想です。1.6 のドキュメントがダウンロードできて嬉しい人よりも 1.8 のドキュメントをダウンロードしたいと思う人の方が多いでしょう。

Wiki は確かに便利なのですが、自分の思ったようにちょこちょこ検索したいと思うと、サーバの負荷が気になります。ネットワークに繋がらないと使えないというのも不便です。

もう一つ、そのためにも RDTool の標準添付など Wiki 上のリファレンスを素早く HTML に起こすために必要な作業を進めるべきだと思います。

• Wiki で提供されている部分で突然見た目が変わるのはやめてほしい

サイトとしての統一感がなくて見ていてとても戸惑います。Wiki をやめろとは言いませんが、統一感のなさは問題だと思います。

• メニューを整理してほしい

ruby-lang.org にも日本Rubyの会Wiki にも言えるのですが、これらは Wiki ではあるけれども圧倒的に読者の方が多い Wiki であるということをもっと意識してほしいです。読者にとって不要なメニュー、読者がもっと素早くアクセスしたい検索などのメニューがすべて同一の重要度で並んでいるのは使い勝手が悪いです。

ruby-lang.org でサイト内検索がずいぶん下にあるのはなぜでしょうか？ これはもっと上にあるべきでは？

• 人手がほしいなら分かりやすく募集すべき

ruby-list で人手不足について書かれてもサイトを見ているだけの人には分かりません。サイト上に書いてないということは募集する気は特にないと言っていることと同じだと思います。

さて、Hiki の方にコピペすっか。……一気に送ったけど嫌がらせだと思われただろうか？(^^;

_ Wiki だけで解決しようとしない方がいいと思う

sheepman さんが Ruby のドキュメントに関して Wiki そのものにある編集に対する心理的ハードルに注目している。これについては以前からいろんな人が

• 編集したくなるメニューデザイン
• 署名

などの角度から議論をしている。まだそうした先人の知見を自分の中で整理しきれているわけではないけど、それらとはまた異なるアプローチでハードルを低くできないだろうかと考えたりする。

Wiki を編集するまでに乗り越えるハードル

個人の Wiki でさえ編集することが躊躇されるんだから、Ruby の公式リファレンスマニュアル_の編集するまでに乗り越えるハードルはやっぱり高いんだろうか。どうやったら人が集まるだろう。

まず、Wiki なんだから編集すればいいというスタンスはなかなか分かってもらえないと思う。私のようにコミュニティの外様の場合はやはりかなり躊躇する。知らない人の Wiki に手を出せるのはせいぜい typo 修正止まりだと思う。*1（逆引きRuby では正規表現マッチのところに手を出したけど。）

そういう意味でも先日書いていた編集権限と commit 権限を分離した Wiki があるといいなぁと思っている。小人も自由に書けるが、正式に承認されたバージョンに反映されるかどうかは committer の裁定に委ねてしまうことができる Wiki。つまり書き手の立場がいきなり core member と対等になってしまうのはビビるので、一段下にしてください、という寸法だ。もちろんこれは committer の負荷が上がるので運営側としては採用に躊躇する面があると思うけど、参加者を増やすという意味では悪くない案だと思う。

もう一つは、いろんな人が手を出してちまちま編集していることを分かりやすくて提示できたらよいと思う。例えば RuWiki のような保存の際にコメントを書ける Wiki であれば、ここに書くコメントで「編集行程の雰囲気」を伝えることができるのではないかと思う。もちろん本来はどのような修正が加わったのかが分かりやすく書かれていることが前提なんだけど、例えばここに「ぐはぁ、typo ハッケソorz」と書いてあったら、編集者のフランクな性格を表すことができると思う。*2また先の編集と commit の区別があればこのコメントはもう少し書きやすいのではないだろうか。

可能なら、Wiki committer が ML でやりとりしている様子や、blog なんかも読めるといいのかなぁ。欲張り過ぎはよくないのでどういう風にサイト上に盛り込むかというのはとても難しい問題だけど。ちなみに pukiwiki.org ではこれが全部 Wiki 上で行われているので、参加の敷居は確かに低くなったが追っかけのコストがとても高いサイトになってしまっている。うまく間を取れればいいなと思う。

ただ、本家リファレンスマニュアルはどうしたって参加者は増えにくいと思う。よほど Ruby に自信がなきゃ書けませんよ、やっぱり。少なくとも私は書きたくありません。怖いです。

_ max-width 推進運動？

• 読みやすさを考えた結果、それが760pxという「新基準」
• 固定幅か、リキッドか

ソリッドとかリキッドとかメタルギアですかというネタはおいといて、ソリッドでもリキッドでもなく間をとって

IE 無視で max-width 指定するのがいちばんいいんじゃないの？

というのはたぶんみんなあえて無視してるんだろな。IE を考慮に入れなきゃプロのデザインとは言えないもんね。

私は6年くらい前からずっと max-width 大好きっこです。幅広げすぎると読みにくいじゃん。でもウィンドウを細くしても横スクロールしたくないじゃん。

ほんとはリキッドデザインて”ある意味”幻想だと思うんだけど、これも書き始めると長くなるので別な機会に。

_ WindowsUpdate クリティカルヒット

サーバー メッセージ ブロックの脆弱性により、リモートでコードが実行される (885250) (MS05-011)

入れたら AppleShareIP 6.2 @ MacOS 8.6 に繋がらなくなった。

いつまでも抜いた状態で運用ってわけにもいかんしねぇ。こりゃサーバそのものをどうにかせんとだめやね。誰がやんねん、運用どないすんねんとか問題山積みですがね。あーあ。あーあーあ。

_ MultiVNC

複数デスクトップ管理ツール「MultiVNC」1.0.0 リリース (/.-j)

sf.jp で地味にバージョンが上がっていたのも知っていたんだけど、/.-j での話の流れはちょっと微妙なような。AppleRemoteDesktop で同じことが実現できるんだけど、VNC の性能ではつらくないかなというのが正直なところ。まぁ Windows で VNC やるより X で VNC やった方が速いっぽい（主観）ので、案外イケるのかな。

でもそもそもこの手のツールで解決できる問題とそうでない問題があるってことを、どれだけの人が意識しているだろうか？ 教室内の PC を見て回らなくて済む？ 実際に指導するときも相手の画面に自分の画面の内容を飛ばす？ 分かりにくいと思うなぁ。目の前でやってもらうことに比べて教える側にも教わる側にもスキルが必要ってことに気づかないのかな？ 特に GUI はマウスのボタンをいつどう押すとか、コンビネーションキーとかあった日にゃもう大騒ぎさ。逆にコマンドラインの様子を飛ばすのであればこれはかなり有用だと思う。コマンドライン上の操作手順を伝えるのに必要なのは基本的に文字だけ。キーを叩く以外の、画面上に現れない操作（シングルクリックとダブルクリックの違いとか左クリックと右クリックの違いとか）に依存する部分が少ないからだ。*1

このツールが活きるシーンとそうでないシーンが必ずある。評価が必要なのはこのツールではなくこのツールを使う指導者だろう。

_ feed meter の画像がチョコになってる！

なんだーハートマークになってるから「おぉ、”あーありがち”の人気が上がったのか？」と思ったがそう言えば世間的には今日はチョコの日ですね(違

個人的にはバレンタインのチョコも節分の太巻きも商売のにおいがぷんぷんして好きじゃない（もちろんクリスマスもだ）んだけど、クリスマスやバレンタインはまだそこにコミュニケーションが存在するから、節分の太巻きよりは許せる。

……。太巻きがそもそも好きじゃないってだけかも。って何の話だ。

_ 思ったほど釣れませんでした

「生徒が運営する講習会」で「ゆとり教育」の有効活用 (/.-j) の中の ゆとり教育ってなんですか？

私の目には「好き勝手に自分の経験をダベるだけでゆとり教育批判をしているつもりになっている人」が多すぎるように見えるのですが、見方が悪いんですかね？ ちゃんと交通整理すれば「それなりに」批判データベースとして使えるものになりそうな気はするんだけどなぁ。期待しすぎか？

期待するなら教育系の掲示板や ML に期待しろって話かもしれないけど、専門にやってる人と普通の人の感覚って全然違うしなぁ。まぁスラドが普通かと言われるとそんなことはないんだけど、これが 2ch になると細分化された板、スレの存在がますますひどい偏りを想像させるし、Yahoo 掲示板とかのポータルの掲示板は議論の素人ばっかでまず収集がつかないだろうし。

ということは、まぁしばらくは期待するなってことか。

_ 謎の Gecko エンジンのバグ？

年明け早々再インストールした今の Windows で謎の現象が続いている。それは

• Gecko エンジンが時間の概念をなくす

というとても困った現象だ。具体的には

• GIF アニメから間（ま）がなくなり、ものすごい勢いでぐるぐる画像が変わるのでとてもブラウザウィンドウを見てられない
  • → AdBlock で対処
  • 実は throbbar もものすごいことになっている
• JavaScript で自動的にリロードするページではミニ田代砲化
  • 頻繁にリロードし、なおかつマシンパワーが貧弱なので最悪何もできなくなる
• メールの受信がかなり難しい
  • タイムアウトまで待ってくれないってゆーか自分勝手にソッコータイムアウトする。だってちゃんと時間を数えられないんだもん。

こんな現象聞いたことないのでどういう言葉で検索すれば類似の現象が見つかるのかも分からない。bugzilla-jp ではキャレットの点滅で同様の現象が見られるらしい。確かにキャレットの点滅も超高速になっててうざい。しかし bugzilla-jp の話ではアニメ gif や throbbar は出てこない。つーか https://bugzilla.mozilla.org/ 繋がらないのはなんでだろう。

試したことは

• 現象を確認したのは Firefox 1.0, Thunderbird 1.0, K-Meleon 0.8 および 0.9
• K-Meleon の 0.8 でも 0.9 でも再現するので最近入ったバグってわけでもなさそう
• とりあえず常駐ソフト切ったり入れたりしてみたけど今のところ収穫なし
• とゆーかほとんど同じ構成で今まで大丈夫だったんだよな
  • 変わったのはプロセッサと、常駐するものに OOo と Adobe Reader Speed Launch が加わったくらい。常駐については上に書いたようにテスト済み
• マウスを動かすと顕著にアニメ GIF が速くなるのでその辺がカギっぽい

うーん。なんか変なライブラリをインストールしたっけなぁ？

_ 進むも戻るも茨の道

最近ゆとり教育反対の blog が多いように見えますが、本当のところはどうなんでしょうね。とりあえずおおざっぱに feedback とかからたどった限りでは

• ゆとり教育なんか要らんからまともな授業をさせろ（教師側）
• ゆとり教育なんかよりちゃんとした勉強した方がいいんじゃない？（外野）
• ゆとり教育ってちょっと前に始まったばっかなのにもうやめるの？（外野）
• ゆとり教育って学力低下したからやめるらしいよ（外野）

な感じ。乱暴に言うと

• 週5日制と総合的学習の導入とそれにともなう教科書の内容削減がゆとり教育であるという認識

に基づいている人の方が多いように見える。そして

• だから学力は低下して当然と思っている
• なのにそこで新たに導入される総合的学習に対する理解は全然ない
  • つーかそんなわけの分からんもんやるから学力が落ちるんじゃボケって感じ

とくるわけだ。（現場の先生には総合のハードさはいやというほど理解されているだろうけど、効果なんてまだ誰も分からないしね。）

まぁ、基本的に報道に出てくる情報ってこれだけだから、こういう形に世論が操作されてしまうのは当然なんだけど、みんないつもそんなに報道信じてるのかなぁ。例えば政治の話や経済の話のとき、ニュース報道だけで全部語られてると思ってる？ 思ってないよね？ 思ってたら相当めでたいよ？ 技術ネタとかで間違ったこと書きまくりなの、理系の人たちはとっくに知ってるよね？

だったらなんで教育ネタは報道を鵜呑みにしてんのよ？

もう一つ。ずいぶん前から学校の勉強は社会で役に立たないとワレワレ一般市民や経済関係の人は批判してませんでしたか？ みんなそれ忘れてますか？ そのときは机に向かう勉強じゃダメだってゆってなかったか？ まぁ、百歩譲って言ってなかったとしよう。

この先も絶対ゆーなよ？

と子どもみたいなことを思ってしまう。

要するにどっちに転んでも好き勝手に文句言ってるだけやん。机に向かう学習が実社会、実生活で役に立たないとか、知識は持ってるが応用は効かない学生ばっかとか、そういう過去の反省があるから総合的学習なんやろーが。そんで総合で頑張ろうとしたら学力低下でやめろてかい。ええかげんにせえよと。しかもこれで見直して教科書の内容をまた増やしますなんてことになったら

教科書の内容を減らすときと変わらない悲惨な状況が絶対生まれる

と断言しよう。総合を全面廃止して速攻元に戻すならあるいは可能かもしれない。今なら過去の資産を掘り起こせばなんとかなるだろう。でも実際には

微妙に増やす

はずだ。あー悲惨だね。絶対悲惨。そもそも減らすときだって体系を考えてざっくりまとめて一分野減らすべきだったのに、教科書で扱わなくなるとその分野の専門家の存在価値がなくなってしまうから、それができなくて虫食い削減した（妄想100%）わけで、また増やすとなったときには自分の専門分野により多くの時間を割かせたい専門家同士の骨肉の争いになりますよ。なりますね。例えば四角形の専門家が三角形の専門家をこてんぱんにけなすような事態になります。もちろんなりますとも。円周率の専門家はここぞとばかりに「小学校で円周率は少数第30位まで暗記させよう」って言うね！*1

結局、「ゆとり教育*2」は進むも戻るも茨の道なのよ。

というか、社会の要請、時代の変化ってものがある限り、教育ってのは必ず茨の道なわけよ。昔のある時点での方法がそのまま今もこれからも通用し続けるなんてことはあり得ないわけ。*3だってどんどん社会も文化も変わってるんだから。単に昔の方法の方がよかったなんてことを言うやつに対してはこう言おう。

• 寝言は寝て言え
• 寝てないならちゃんとその目で今を見ろ

_ 想像力に対する挑戦かと思ってた

ソフトの動作しているスクリーンショットムービーを作る方法

あはは。るびま5号の増井さんのインタビューはやはりもどかしいらしい。

私はこの記事を読んで「これはオレに対する挑戦だな」と思ってましたよ。「よーしパパ想像力フル稼働しちゃうぞー」って感じ。でも結局「なんだかすごそう」くらいまでしか想像できませんでしたがorz

なんかとても楽しそうでよかったですよ。詳しいものは「どうせ発表してる内容なんだから」、どっか適当な Web に置いてさえあればそこへリンク張るだけで済んだのになと、少し残念に思いますがね。インタビューそのものではない、その中のソフトの動作を Web で分かりやすい形に起こすという作業は、なんかるびまの仕事とはちょっと違う気がするし。

_ rssdiff.inc.php を RSS 2.0 対応に

rssdiff を RSS 2.0 対応に

で、PukiWiki の rssdiff プラグインをようやく RSS 2.0 対応にしました。基本的には何も変わってなくて、単にタグが変わったとか日付のフォーマットが変わった程度なので、とりあえず設定で 1.0 も吐けるようにしてあります。*1

意味的にはこの方がいいのかなぁと思いつつ、また様子見。とりあえずここの Wiki や PC説教講座の Wiki の RSS は 2.0 で出すようにしました。

_ PukiWiki の Namazu 検索の精度を多少上げる

http://pukiwiki.sourceforge.jp/?PukiWiki%2FNamazu

に上げたのですが、一応こっちにも貼っておきます。pukiwiki.pl をいじって、pukifile.pl として作成しました。合わせて mime type も text/pukifile にしときました。PukiWiki フォーマットのパースはとりあえず Namazu のデフォルトの重み付けの設定で有効になっているタグだけ見てます。それ以外は HTML にすらなりません。

[2005-11-11 追記]案の定というか pukiwiki.org の混乱後、添付ファイルがなくなってました。こっちにも貼っておいてよかった。あと、EUC のファイルしか考えてないので、PukiWiki を utf-8 で運用している場合は 検索結果の画面でページ名が化ける可能性があります。mknmz のプロセス自身を LANG=ja_JP.UTF-8 の環境で動かせばひょっとしてうまくいかねーかなとか思ったりもするんですが、自分では utf-8 での運用は一切していないのでよく分かりません。

スクリプトでの対応としては要するに pack のところをいじるってことになるはずです。$file と、そのファイルの中身のコードが一致するようにごにょってやれば ok のはず。

package pukifile;
use strict;
require 'html.pl';
 
sub mediatype() { return ('text/pukifile'); }
sub status() { return 'yes'; }
sub recursive() { return 0; }
sub pre_codeconv() { return 1; }
sub post_codeconv () { return 0; }
sub add_magic ($) { return; }
sub filter ($$$$$) {
    my ($orig_cfile, $cont, $weighted_str, $headings, $fields) = @_;
    my $cfile = defined $orig_cfile ? $$orig_cfile : '';

    util::vprint("Processing pukiwiki file ...\n");

    my ($path,$file,$ext) = $cfile =~ m#^(.*/)(.*)(\.txt)$#;

    $file = pack("H*",$file);
    $file =~ s/[\[\]]//g;
    my( $title ) = $file;
    $file =~ s/(\W)/'%'.unpack("H2",$1)/eg;
    $fields->{'uri'} = "$path$file";

        $$cont = "<h1>".$title."</h1>\n" . $$cont;
        puki_filter( $cont );

        html::html_filter( $cont, $weighted_str, $fields, $headings );
        gfilter::line_adjust_filter($cont);
        gfilter::line_adjust_filter($weighted_str);
        gfilter::white_space_adjust_filter($cont);
        $fields->{'title'} = $title;

    return undef;
}

sub puki_filter(*) {
    my( $cont ) = @_;

    # 改行で配列に分割（gfilter のツールでは white space が落ちるからダメ）
    $$cont =~ s/\r\n?/\n/g;
    my( @body ) = split( /\n/, $$cont );

    # PukiWiki フォーマットのつもりで簡易パース
    my( $line );
    foreach $line ( @body ) {
        chomp( $line );
        my( $level ) = 0;
        # Heading
        if ( $line =~ s/^(\*+)// ) {
            $level = length( $1 ) + 1;
        }
        # comment
        if ( $line =~ s/^\/\/// ) {
            $line = "<!-- " . $line . " -->";
        }
        # anchor と emphasis
        # aname プラグインはとりあえず無視
        # uri として正しいかどうかもチェックしない
        if ( $line !~ /^\s+/ ) {
            $line =~ s/\[\[(.*)(?:\:|>)(.*)\]\]/<a href="$2">$1<\/a>/g;
            $line =~ s/(''')(.*)(''')/<em>$2<\/em>/g;
            $line =~ s/('')(.*)('')/<strong>$2<\/strong>/g;
        }
        if ( $level > 1 ) {
            $line = '<h'.$level.'>'.$line.'</h'.$level.'>';
        }
    }

    # <body> タグが現れるまで無視されるので <body></body> でサンド
    $$cont = join( '', @body );
    $$cont = "<body>\n" . $$cont;
    $$cont = $$cont . "\n</body>\n";
}
1;

_ Wiki の横断検索と Namazu

※ 以後、Namazu, Namazu って書いているけど、同じ方法が使えれば estraier でもなんでもいいです。

Wiki は普通 grep 検索できるので Namazu は必要ない。よほどページ数が増えればスピードの問題が出てくるが、普通はインデックスを起こすタイプの検索エンジンは Wiki にはそんなに必要ない。*1

ただし Wiki が増えた場合はそうはいかない。自分は PukiWiki をローカルで使っているが、WikiFarm というか、複数の Wiki に分けて使っている。PukiWiki は 1.4.4 になって複数の Wiki で同じ lib/ を共有しやすくなったり、以前より複数の Wiki を動かすのは簡単になっている*2ので、興味がある人には是非オススメしたい。明らかに目的の違うもの、個人用のスペース（ここに日誌を書いたりする）、期間限定のプロジェクトなどを別々の Wiki に分けておくと何かと扱いやすいのだ。*3（先に分けても後から分けてもいい。）ところが PukiWiki には複数の Wiki に対して検索する機能がないのでそこが不便。

というかそもそも PukiWiki には WikiFarm の機能がない。複数の Wiki を PukiWiki 自身が管理しているわけじゃないんだから、そら横断検索ってのも無茶な話。そこで Namazu を使う。Namazu では 1Wiki対1インデックスのオーソドックスなインデックスを起こす。で、template で checkbox を用意して、複数のインデックスに対して一気に検索を掛けられるようにする。

おしまい。

いやいや。

この方法にはまだまだ工夫の余地がある。

• Wiki のパーサを外部（Web ベースでなくコマンドラインが嬉しい）から利用できる API があると、Namazu の filter を書きやすくなって検索精度を上げやすくなる。
  • サイドバーやナビゲーション要素を除いた HTML が取得できるといちばん嬉しい。
  • 今回の PukiWiki 用フィルタは超簡単なパーサもどきを Perl で別途用意したのだが、本当は PukiWiki のエンジンを利用して HTML を生成できればいちばんよかった。
• DBMS 前提の Wiki だと Namazu と相性が悪いので、Namazu 用に（ってだけでもないけど）ナビゲーション要素などを除いた HTML を取得できる方法があるといいな。

これが実現できるとどんな Wiki を使っていても Wiki の分割と精度の高い横断検索を実現できる。んだけど、Wiki エンジンの開発者やコミュニティでこういうことに意義を感じている人ってあんまり見ないのはなぜだろう。すげー便利なのに。ひょっとして自分の知らないもっといい方法が密かに定着しているのだろうか。

_ アクセスポイント集約クリティカルヒット

全国展開しているどこのプロバイダもそうなんだけど、アナログや ISDN のダイヤルアップ接続のアクセスポイントはどんどん全国統一番号にシフトしてきている。アクセスポイントの維持費がペイしないから集約しましょってことなんだろうけど、うちの実家がそれにやられてしまいましたorz

ADSL にしろしろとは前から言ってるんだけど、今使えているものをなぜ契約変更しなければいけないのかという感覚。変更のメリットと変更の面倒くささを比べると面倒くささの方が勝っちゃうので話がまったく進まない。そんなわけでアクセスポイントに繋がらなくなってからヘルプの電話。

そんなこと言われたって電話じゃどうにもならねーよ、ということでこの週末作業したわけですが、原因は私でしたorz 中古のルータをメーカーのサイトから落としてきたツールで設定しておいたんだけど、その設定ツールをフロッピーなりで保管しておかなかったのが敗因。数年経ち本体をリプレイスしたのでツールはどこにもない状態だったのです。つまり繋がらなくなった瞬間に何もできなくなったわけです。そらあかんわなぁ。

日本のメーカーだったので、今回はメーカーからフロッピーを取り寄せるところまではやってもらって、あとはおれっちが設定するだけで済んだわけですが、再現できないシステムを遠隔地に放置したらいけませんという例ですな。

今回はそのルータの設定をどうやったのか全然覚えていなかったので、ちゃんとメモを残さないとダメだなぁという当たり前のことを思い知らされた次第。ひょっとしてルータってシリアルで設定するんだっけな？ てゆーか実家の機械にシリアルってあったか？ えー全然覚えてなーい、ということでそれだけのために ThinkPad + USB/シリアル・パラレル変換ケーブルまで持っていった。やってみたら Ether から設定できるシロモノだったのでまったく必要なかった。ブラウザで設定できるタイプじゃなかったのが返す返すも悔やまれます。でもこれ買ったとき金なかったんだもんな。

_ Ruby 1.8 対応リファレンスマニュアルの HTML 一括ダウンロード

出ました！

素晴らしい！ RD のままっつーのもあるけど、これは、、、自前の RWiki で再現しろとか自分で RDTool とか使って好きにしろとかそういうことかな？(^^;

今までも 1.8 対応の HTML 版は非公式にはありましたけど、本家にあるってのが重要ですね。さーて早速手元のものをこれで更新すっかー。Ruby を書く予定はないけど。。。

あれ、リファレンスマニュアルのトップページから参考文献とか参考になるサイトへの誘導がありますね。前からこんなのあったかな。整理されているし、るびまの入門記事へのリンクもありますね。いい感じですね。

_ ごちゃごちゃした情報が大量にあるページのデザイン

調査票デザインの原則

で、このページの筆者の方がインターネット調査は社会調査に利用できるかという報告書に以下のように突っ込んでいるが、

• 1つの設問は1つのスクリーンに収まるように
  • ユーザの環境によって画面の広さは異なる。基準（例えばSVGA）を決める必要がある。

広さと「設定」によって異なりますぜ。今じゃ携帯だって高精細だから設定次第で結構な文字数を表示できるし、ウィンドウを全画面表示で横長に使っているとも限らない。

というツッコミは意地悪半分、本気半分。今回は報告書の言ってることは概ね正しいけど実現するのは楽じゃないよという話なわけですが、方法としては以下のような感じ？

• （昔デザイナのサイトで流行った）新規ウィンドウを開いて固定サイズのフォントを使う
• JavaScript と CSS で動的にサイズ調整
• Flash とか Java とか PDF でリッチクライアントの操作性に期待する

あるいは

• S5 のように JavaScript と CSS を使って長い HTML の1ページを複数のスクリーンに分割する

と、いちいちサーバと通信せずに JavaScript に情報を保存できるし、Flash や Java のように plugin を必要としないし、ユーザーの意思で JavaScript を off にして（あるいは JavaScript 非対応のブラウザを使って）長い HTML のページと格闘することも可能だから、これがいちばんいいのかも。でも S5 って自分自身が作りだすナビゲーションやスライドショーで実際に表示する内容以外はまったく考慮されてないから、他のコンテンツへのナビや広告も盛り込みたいって要求になった場合はちょっと使いにくいか。そこのサイトのナビや広告が CSS の管理下にあればいいけど、そうでないとダメくさい。

生 HTML は操作性があまりよくないが、plugin 前提の場合は操作性はよくなるがユーザーの環境を限定してしまうという問題って、他にもいろんなシーンがあるわけですが、この調査票ネタはそれを考えるのにとてもよい題材かもしれない。

_ Linux か Mac かと思ってた

• 〇〇 には何が入るでしょう
• 050222 - Wikiphilia

RSS なんかもこんな感じかも。

なんの話かっつーと Wiki コミュニティが Wiki 万能言い過ぎてねーかって話と、それを受けてたぶん sheepman 氏がいろんなものに当てはまるなーと思って伏せ字にしてみたところ、私は Linux, Mac を思い浮かべました、という話。

ただ、面白がって遊び倒さないといいも悪いも見えてこないってこともあるのよね。面白そうなものに飛びついてハマりつつ適度な距離感を見失わないバランス感覚をいつまでも大事にしたい。と言いつつ del.icio.us も MM も bloglines も mixi も Gmail もやってませんけどねorz

_ Perl に疲れた、ってのは噂にも出てこないのか

textfile.org 経由で

プログラミング言語ユーザーの噂

• ほとんどが言語オタクか日本人。
• ドキュメントは書かず「ソースがドキュメントだ」とうそぶく。

言語ヲタだから Ruby を使うって噂なんすか。私は「昔は Perl 書いてました」って人が多いと思ってるし、それは定説になってるもんだとばかり。だぁって use strict でいちいち my してたら Perl で書くメリット半減でしょ。余計なことせずにいきなり書けちゃうのが Perl のよさじゃないのかと。で、use strict して my しまくるくらいなら Ruby で書いた方が同じことを実現するための記述量は小さくなると思うし、ちょっとでも OO で書きたいとか思ったらもうそれは雲泥の差でしょう。言語の環境を自由に用意できるのであれば、あとはライブラリの差をどう判断するかってところに落ち着くと思うんだけど、そういうもんじゃないのかな。

あと、ドキュメント重要。でもソースに書いてある。Wiki にも書くけど細かいことは RDoc*1 読め。が、今どきじゃないのかな。

なんかどうもここにある噂は単に作者の生態や有名な言葉が並んでるだけのような。ちなみにその作者まつもと氏は

Re:死にやがれ(/.-j)

ぶっそうなサブジェクトですが、アイディアレベルを含めて10個くらいの言語を思いついたようですな。

_ グループウェアは窮屈だから Wiki にしました

対グループウェアとしての Wiki

グループウェア、ダメ！

そうなんです。

面白くないんです、グループウェアは。なぜなら先にフローが決まってしまうから。と勝手に思ってるけど本当は Notes とかまともなグループウェアは使ったことがない。ただ、なんかお試しできるツールをいくつか触った感じは

窮屈。

DOS 時代のデキの悪いソフトをつかまされたような、手順を縛られたとても窮屈な感じがするのです。これをこうするためにはこっちのこれをこうする必要がある、とか。そんなことしるか！と。こちとらマニュアルなんて一切読まない、直感的に使えないソフトは全部クズだと思っている人間だぜ。*2

つーことで実は今の環境でも最初にグループウェアの導入を模索してみたんだけど、結局導入したのは PukiWiki のみでした。選んだ理由は、前にも書いたような気がするけど、

• 当時としてはかなり画期的な valid xhtml を吐く仕様（を目指していた）
• PHP は使うから、PHP だと将来的にもカスタマイズとかできていいかもと思った*3
• 記法が比較的複雑な構文をカバーしているので、まともにドキュメントが書ける
• BugTrack プラグインがあった
• PHP だけ動けば使える（RDBMS とかバージョン管理システムとか Pear とか sendmail とか要らない）

かな。

1.3.2 かなんかを使って、当時まだ Windows サーバしかなかったので改行周りの問題がものすごく大量に出たけど頑張っていちいちつぶしていって*4、分からんなりにいじるのが面白くて、そうこうしてるうちにあーこれはこういう使い方をするとこういう情報のストックや更新なんかに便利だなというところが見えてくる。Wiki にしてよかったことは「使い方を自分で考えることができた」こと。

メール連動とか便利かもしれないけど、どれだけ便利か分からないのにサーバをセットアップしなきゃいけないのは面倒でいや。目の前に居る人間との共同作業が前提だし、メールは記録として使えるけど基本的にはメッセンジャーと Wiki と face to face のコミュニケーションで足りる。*5RDBMS も要らないし、Wiki そのものが考え方を理解するのにちょっと苦労するという問題はあっても、使い始める負荷を比べると、自分にとっては グループウェア >> Wiki だった。

Wiki 信者の戯れ言でしょうか。信者ってつもりはないんだけどな。ページやナビゲーションが簡単にごちゃごちゃしてわけ分からなくなるとか、新たに使ってもらうためにはどうしても記法のとっつきにくさって問題は残るし。でも「高度な自動化が必要なければこんなに便利なものはない」とは思ってるし、「とりあえず Wiki でできないか考える」というクセはついてるかも。よくよく考えると Wiki って全然たいしたことないんだけど、その欲張らなさというか、機能の少なさがかえって自由で気持ちいい、って感じ。

文房具としてコンピュータを使うための Wiki

その前にまず脱線。Web としての Wiki に自分が感じている画期的な点は

• 存在していないページにリンクが張れる
• 特別な検索ツールを用意しなくても検索できる

この2点。素朴な HTML 直書きから入った人間の素直な気持ちです。いやほんと、Web としてはこれ以上の意味はないんじゃないかと。応用としてはいろんなよさが出てくるんだけど。

日常の道具としての Wiki に感じるよい点は

• オープンな技術で実装されているし Web ベースなのでプラットフォームを選ばないことが多い
• なおかつ LL で実装されているものが多く、準備が楽
• したがって localhost に実験環境とか自分用の Wiki を用意しやすく、道具を Wiki に一本化しやすい*6
• ファイルが添付できるとますます成果を Wiki に集約させやすくてよい
• Web ベースなので作業する機械とデータの保存場所を分離しやすい
  • 特定のクライアントマシンの中を探さないと必要なデータが出てこない、そしてその人は休んでてどこにあるか分からない、とかいう複数の人間が絡んだ作業のときに陥りやすい事故を簡単に防げる
  • データの保守と機械の保守を分離しやすい。自分の機械が壊れたときの損失を減らしやすい。
• 検索できる*7
• ファイルの管理を意識しなくてよい

ここまでくると Wiki 信者と言われても文句は言えないのかな。でもここに WikiWay の精神はたぶん全然出てきてないと思う。

_ CLIE 終了ですか

その前に自分の中のちっこい機械好きがなんかどうも終了してるっぽいのですが。

実はポケコンから HP200LX へ行った由緒正しきキーボード付きのちっこい機械好きなのですが、PDA サイズのものに結局魅力を感じなくなって HP200LX 以降はまったく手にしていません。理由のいちばんは

• 電車移動じゃないから

というものですが、それ以外にも

• なんだかんだで（キーボードも含めて）フル機能ほしくなっちゃうから、ノート PC の方がいい
• PC と PDA で違う操作方法（アプリ）を用意して、データをシンクロして、、、って考えるだけで面倒くさい
• もう少し出せばノート PC 買える値段を投じられるほど余裕がない

という辺り。型落ちモバイルノートをメインマシンにしてしまえば上の3つの問題を全部解決できるのでそうしてます。メインをデスクトップにしてりなざうとかにすればいいじゃんという指摘もあるかもしれないけど、なんかどうもデスクトップの「決まった場所に座らないといけない」という制約がそもそもきらいなのね。きらいなのです。

ということで、そういう使い方をし始めて、、、もう10年経つのか。うわーどーゆーことだーorz

スケジュールとかメモとかは今はもう携帯でいいです。基本的には PC で整理して携帯にメール、携帯でメモして PC にメール、だけで済ましてます。特別なツールは使わず、Wiki からメールに、メールから Wiki にコピペしてるだけ。どうせそんなに大量のデータのやりとりは必要ないから。携帯用フルキーボードが安価に手に入ったらもっとヘビーに使うかもしんないけど、それも最初のうちだけだろうなぁ。

_ Putty 0.57 周り

2005-02-25 10:30 確認

WinSCP のサイトがなんか見にくくなったっつーか、What's New が全然書いてないのは前からこんなもんだっけ。Wiki とか採用してデザインもがらっと変わってるのはいいんだけど、書くもん書いて。頼むし。今回はとりあえず

Part of the code of this software comes from program PuTTY 0.56 (C) 1997-2005 Simon Tatham. License agreements for using PuTTY, are part of WinSCP license agreement.

を信じて「未」と判断。