無印吉澤（※新エントリはhatenablogに掲載中）

■ 仮移転が完了しました

無印吉澤＠はてなダイアリー改め、無印吉澤管理人の吉澤です。はてなダイアリーの記事の移植や、検索機能の追加など、まだまだやり残した事もあるのですが、とりあえず体裁が整ったのでサイトを公開してみました。

レンタルサーバでtDiary＋独自ドメインを取ってみたのですが、tDiaryは色々カスタマイズし甲斐があって良いですね。デザインは以前とちょっと変わりましたけど、今までと同じような感じで『最低でも週一ペースで更新』を目標に頑張りたいと思います。今後ともよろしくお願いします。

■[tDiary]はてな記法ジャンキー

さて週末になったことだし日記でも書こうとキーを叩いていたんですが……なんか全然書けません。どうも、はてなダイアリーの記法に慣れすぎてしまったのが原因みたいです。

----

「郷に入っては郷に従え」ということで、前回はtDiaryスタイル（tDiary標準の日記フォーマット）で日記を書いていたのですが、今日の日記を書いているときに、単一セクションの途中に<pre></pre>で囲まれた文字列を埋め込もうとすると出力がおかしくなることに気づきました。具体的に言うと、例えば以下の様に入力すると「最初が『<』で始まる段落がある場合、そのセクションは全体が整形の対象にならなくなる」というtDiaryスタイルのルールに従って、1行目や2行目の部分が<p></p>で囲まれなくなってしまいます。

サブタイトル(1)
1行目
2行目
<pre>
整形しない範囲。

しませんよ。
</pre>
3行目

<pre>だけセクションを分けるのも気持ちが悪いので、tDiaryスタイルは却下。

----

そこで次に試したのがWikiスタイル。こちらはtDiaryスタイルと違ってセクションの区切りに空白行を使っていないため、<pre>についてはうまくいきました。ただ、パラグラフの途中でむりやり改行させようと思うとHTMLで「<br>」を書くしかなく、Wikiスタイルでは以下のように書く必要があります。

{{'<br>'}}

……なんか感情的に物凄くイヤなのでWikiスタイルも却下却下。

----

僕は普段howm（一人お手軽 Wiki もどき）をrd-modeで使っているのでRDスタイルもいいかなぁと思ったのですが、RDとの違い＆生HTMLの記述方法が気になって却下。

----

で、結局、なんか負けたような気分になりながらもHatenaスタイルに落ち着きました。contribから取り出してインストール（v1.9）。このスタイルはHatenaスタイル作者のmput氏の趣味で「2行の空行でパラグラフ区切り」というルールになっているので、はてなダイアリーと同じ「1行の空行でパラグラフ区切り」というルールになるように修正しておきました。

%diff hatena_style.rb.old hatena_style.rb
357c357
<             break if buffer[-3..-1] == "\n\n\n"
---
>             break if buffer[-2..-1] == "\n\n"
624c624
<     @elems = Hatena::Inline.new(str.gsub(/\n\n\n/,''))
---
>     @elems = Hatena::Inline.new(str.gsub(/\n\n/,''))

（適当にやったらうまくいくなんて、一応やってみるもんだなぁ……。）

いやぁ、素晴らしい。これなら、はてなダイアリーでの日記も簡単に移植できそうです。やれやれ。

■[tDiary]スパム対策

「tDiaryは最近コメントスパムが多いから気を付けた方がいいよ」とmixiにてアドバイスを頂いたので、スパム対策としてtDiary 2.0.0（フルセット）には入ってないプラグインを2つ追加しました。

●その1：リファラエディタプラグイン(refedit.rb)

リファラエディタプラグイン(MUTOPON7 ANNEX)
http://ponx.s5.xrea.com/hiki/ja/refedit.rb.html

「設定」→「リファラの編集」にて、日付を指定してリファラを編集できるようになるプラグインです。ここのサイトからrefedit.rbを持ってきてプラグインに追加したのですが、僕の環境（tDiary 2.0.0/Ruby 1.8.2）ではリファラの編集を反映させようとするとエラーが出る状態でした。ソースコードを読んでみると変数定義に問題がありそうだったので、以下のようにして解決。*1

%diff refedit.rb.old refedit.rb
90a91
>   path = nil

ちなみに、羊堂本舗(2004-10-13)にて日記の編集画面でリファラも編集できるrefedit.rbが公開されています。編集したいリファラが多い場合はこちらの方が便利そうです（僕はまだ試してません）。

●その2：Anti Referer Spamプラグイン(antirefspam.rb)

Anti Referer Spam プラグイン ver 0.80(紅玉日記)
http://www.netlife.gr.jp/redbug/diary/?date=20041115#p01

リファラが示すURLに、自分の日記へのリンクが本当に含まれているかどうかをチェックする事で、リファラスパムを表示しないようにするプログラムです。「設定」→「Anti Referer Spam」にて、例外扱いしたいURLを設定できるので、こちらからアクセスできないmixiなどのサイトを指定すると嬉しいかも。詳細はFAQを参照。

また、このプラグインはコメントスパム対策も

• ツッコミにひらがな/カタカナが含まれていない場合は拒否
• ツッコミ文字列の長さの上限を指定
• 特定の単語がツッコミに含まれていた場合は拒否する

といろいろ指定できて良い感じです。

ただ、これだけでは日本語のコメントスパムはあまり防げそうにないので、いざというときには以下のサイトを参考にして対処することにします。

tdiary へのコメントspamを一括削除(いやな日記)
http://namazu.org/~satoru/diary/20040923.html

■[NAT][IPv6]NAT特集記事

Volume 7, Issue 3, September 2004 - The Internet Protocol Journal
http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_7-3/

最新のIPJにて、NAT関係の話題をまとめた特集記事が掲載されていたのでご紹介。最近発表されたInternet Draftの内容も含めて、NAT関係の話題は一通り網羅されているので、これからマジメにNAT問題に取り組みたい人には格好の入門になりそうです。

ところで、これを一通り読むと解るのですが、この文書ではNATを越えて通信する（NATトラバーサルとも言う）ための技術については概要しか書かれていなくて、むしろ「現在のNATはどういうものか」という説明にほとんどのページが割かれています。実際、最近のIETFでは「NAT越えのためにどういう技術が必要か」という点よりも「どういうNATならばNATトラバーサル技術を適用しやすいか」という点に着目し、application-friendlyなNATの振る舞いを標準化する方向に向かっているようです。

逆に言うと、ここ数年に渡って行われてきたNATトラバーサル技術の研究によって、現在のNAT実装が持つ問題点は一通り明らかになったので、

• 理想的なNATの振る舞いを標準化する
• NATトラバーサル可能なアプリケーションを作り込む

という2つの大きな流れが生まれていて、今まで行われていたNATトラバーサル技術の標準化ということはもうあまり流行っていないような印象を受けます。前者はbehaveワーキンググループのような活動で、後者はSkypeなどですね。

----

そういえば、今日ちょうどこのようなニュースが出ていました。

NAT越しにIP電話できるSIPソフト、フラクタリストが開発(IT Pro)
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20041122/152898/

一般に、異なるLANやISPの傘下にある機器同士は直接接続できないので、インターネット上に中継サーバーを用意する必要がある。この場合、すべてのデータが中継サーバーを通過するため、動画や音声を扱う場合には、負荷がかかる中継サーバーのコストが高くなりがちだった。そこで、SIP UA SDKは「セッション管理サーバー」でハンドシェイクを行った後、端末間で直接ピア・ツー・ピア通信する仕組みを採用した。

このフラクタリストの方には以前にP2P勉強会などの場でお話を聞かせて頂いたことがあるのですが、簡単に言うと、こちらの製品はSTUNのNAT識別プロセスを更に強力にしたようなものを実装することで、あらゆるNATをUDP hole punchingで越えられるようにしているそうです。市場に出回っているNAT製品全てに対してテストを行う事でNAT識別プロセスを作り込み、そのノウハウによって価値が生まれている製品と言えるでしょう。

一方、IP電話の世界ではセッションボーダコントローラ（Session Border Controller; SBC）という製品も出回っていて、こちらは全てのトラフィックをSBCでリレーすることでNAT越えを実現しています。そもそもNATはクライアント/サーバ型のネットワークを前提としているため、この方法なら確実にNATを越えられるわけです。こちらはNATの識別を完全に諦めて、SBC装置自体の処理能力を高めることで価値が生まれている製品です（SBCの場合、NATトラバーサル機能はあまり重視されていない気もするのですが、本題ではないので割愛）。

----

以上のようなことから、今後NATトラバーサル可能なアプリケーションを作るとしたら、アプリケーションの特徴によって「NAT識別」と「パケットのリレー」をどの程度使い分けるか決めて、実装を作り込むしかないのではないかなぁ……というのが僕個人の感想です。

その一方、NAT問題を解決するにはやはり一刻も早くIPv6を普及させるのが一番なので、以前から注目しているTeredoや、最近Internet Draftで検討されているSilkroadにも期待しています。Silkroadについては、また後日紹介しますのでお楽しみに。

Tunneling IPv6 with private IPv4 addresses through NAT devices
http://www.ietf.org/internet-drafts/draft-liumin-v6ops-silkroad-02.txt

■[blog]ニュースコミュニティ- テキストコミュニケーションの重要性増加中(FPN)

http://www.future-planning.net/x/modules/news/article.php?storyid=276

この記事と、その先の記事（死んでしまったら私のことなんか誰も話さない: ブログの魅力と可能性）を読んでいて、以前「ネット世代」についての日記を書いているときに見たサイトを思い出しました。テキストコミュニケーションの効用としては、個人的には以下の説明が一番しっくりきます（フラストレーションを感じる部分が僕と共通してる人じゃないと、共感されないかな……）。

「ネット世代論」を「匿名性」とスッパリ切り離してみる(技術系サラリーマンの交差点)
http://ytsumura.cocolog-nifty.com/blog/2004/06/post_3.html

　リアル世界から一応独立した媒体に、いったん（あるいは継続的に）情報がプールされる仕組み。こういうものを自分の生活空間として入り込み、その世界での人格を形成できるのが「ネット世代」ではないか。

（中略）

　こういう媒体を介すると、なぜ「もう一つの世界」が出現してしまうのか。私はコミュニケーション論の専門家でもなんでもないが、「自分の言いたいことを最後まで言える」のが最も大きいと思う。リアルの会話では、言いたいことを全て言える場面はあまりない。途中でさえぎられたり、相手の顔色を見たり、ちゃんと聞いてもらえなかったり、色々な理由で発言は中断される。（あるいは、そもそも発言できない。）そして、発言の受け手にとっては、「相手の発言に途中で文句をはさめず、全部受け取らされる」ことになる。

　たったこれだけの違いだが、人間どうしの関係に決定的な違いをもたらすように見える。

あと、ちょっと前に読んだ「超」整理法4 コミュニケーションにもテキストコミュニケーションの効用がいろいろ書いてあったような気がします。要点だけ取り出したら参考になるかも。

■[tDiary]pingプラグイン

相変わらず地味に引っ越し作業中。

今更ですがpingプラグインを入れてみました。プラグイン選択の画面で「ping.rb（標準セットに含まれてる）」を選択してから、/misc/plugin/ja/ping.rbを/plugin/jaディレクトリ以下にコピー（インストール）します。

まだ勝手が分からないので、とりあえずプラグインの説明サイトにあるURLをひととおり通知先に指定してみました。更新時の動作があまりにも重くなるようだったら、あとから減らします。

http://ping.myblog.jp
http://ping.cocolog-nifty.com/xmlrpc
http://ping.bloggers.jp/rpc/
http://bulkfeeds.net/rpc
http://www.blogpeople.net/servlet/weblogUpdates
http://blog.goo.ne.jp/XMLRPC
http://list.myblog.jp/

参考サイト：どうやったら FeedBack に巡回されますか?(FeedBack FAQ - Yet Another RSS Search)

----

（2004/12/01追記）
ping到達確認用のURLリスト。

• Myblog japan
• ココログ
• ping.bloggers.jp
• Bulkfeeds
• BlogPeople
• gooブログ
• MyblogList

pingを打ってから1日待ってみた結果は以下の通り。下には書いてませんけど、FeedBackの検索結果にもきちんと反映されてました。

• 即座に反映：myblog japan, ping.bloggers.jp, ココログ（少し更新周期が長い）
• 暫くしてから検索結果に反映：gooブログ, Bulkfeeds
• 即座に反映するはずが、反映されない：BlogPeople, MyblogList

うーん。最後の2つにはどうして反映されないのかなぁ……。