2003-03-15
_ WikiLike改善案 (20:17)
公開用WikiLikeを作る上で考えている改善案。でも、日本の平均的（だと思われる）レンタルサーバーとかでまともに動くように、PHP+MySQLなコードを書き直すのってうざいなー。どの程度のライブラリまで使っていいものかの判断も付きにくいし。
- ユーザーのメール／URLを入力できるようにする（主にコメント用）
- ページ作者のみが更新できるモードを作る
- ID、トリップによる認証（XSS対策をかなりがっちりやらないとなー。JavaScript有効だと弾くようにしたろうか）
- キーワードに特定の語が含まれているかどうかで、ページの権限的な意味づけをする
- HiddenPageで通常のページとして一覧表示されなくなる。SID指定で直接行ったときだけ表示される。
- PrivatePageでCookieのuser_name、user_tripがマッチした人だけが表示できる。
- ページのmodifiedとプロパティのmodifiedを分け、実際に更新された日時と表示用の更新日時を分離する。
- ページ名＝ユーザー名であるページを、そのユーザーのホームページとする。ホームページIDを使ってユーザーごとのさまざまな処理を切り分ける。
- ex)http://some.domain.com/view.php?user=32でid:32がホームページのユーザーの最新記事n件を表示する
- WikiNameの自動リンクをオン/オフできる。
- マルチユーザーモードと単一ユーザーモードを切り替えできる
- PHP CGIモードとApacheモジュールモードを切り替えできる（やりたくねーなー）
- TrackBack/PingBack/Referer/コメントによる反応を統合管理する
- 新しいきれいなWiki系フォーマット体系＆レンダリングエンジンを作る
- 言葉交差点との自動連係（キーワード登録）
- ログイン/ログオフをつけて、Cookieの有効無効を手動で変更できるようにする
- creative commonsあるいはGNU FDL表示対応。
- というかソフト自体のライセンスをどうしようかなー。サンプルコード扱いってのはダメかね？
_ Pingback plugin from Rubyにまつわるえとせとら日記 (20:17)
どうやらtDiaryはひとまずPingBackに対応するみたいだなー。PingBackは実用的にはTrackBackよりもRefererとの差が少ないんで、すでにRefererを表示しているtDiaryに載せてもあまり意味がないと思うんだけど、PingBackの方が仕様が明確で実装するのが楽しそうだというのが大きいんだろうな。
TrackBackを必要最低限実装するのは、一言掲示板を実装する程度の作業だから技術的には何も楽しいことはないし、必要最低限以外の部分までフルに実装しようとすると、今度はやたらと面倒くさい割にはその意義を感じられない（し、仕様もいまいち）。
tDiaryがPingBackに対応するんだったら、一応俺もPingBackに対応しておこうかな。でもフルにPingBackを実装する気にはなれないんで、受信側は一応実装しつつ、送信側はTrackBackのオプション的な実装にしよう。TrackBack Ping URLを記述する横にPingBackチェックボックスを用意して、PingBackチェックボックスが立っていたらそのURLをPingBackとして処理する方針で。
でもそれをtDiaryに送るのって、普通にリンクを張って10回とか20回とかクリックしてたくさんRefererを送るのと大した差はないように思えるな。表示側でちゃんとRefererとは違うとわかりやすく表示されると差別化できるかな。あと、PingBackオンで更新すると処理が重くなるから、誰も使わないなんて恐れもある。リンクごとにPluginでいちいちPingBackを送るかどうか指定するようだと、PingBackの意味がなくなりそうだしなー。まあその辺は実際に実装されて使われるようにならないと分からないか。
_ オリックス本拠地、「ヤフーＢＢ球場」に名称変更 from YOMIURI ON-LINE (20:17)
>プロ野球オリックス・ブルーウェーブの本拠地「グリーンスタジアム神戸」（神戸市須磨区）の名称を決められる「命名権」を、ソフトバンクグループが購入することが１４日決まり、今年のシーズンから「ＹＡＨＯＯ！（ヤフー）ＢＢスタジアム」に名前が変わることになった。
命名権なんてばら売りしているもんなんだ。で、「YAHOO! BBスタジアム」ねー。なんか長持ちしなそうな名前だね。「Yahoo! BB」って名前の印象がもはや最悪だからなー（ってのは一般的な評価ではないのかな）。まだ「Yahoo!スタジアム」くらいにしておいた方が良さそうな気がする。
_ ブレスレット型映像記憶端末──NEC、未来デバイスをCeBITに出展 from ZDNet (20:17)
- ブレスレット型映像記憶端末──NEC、未来デバイスをCeBITに出展 - http://www.zdnet.co.jp/news/0303/14/njbt_05.html
- Resonantware - http://www.nec-design.co.jp/showcase/indexj.html
waccaとnaveは根本的なインターフェースの改善、P-ISMは身の回りのものにデジタルインターフェースを統合＆融合させるアプローチか。duo-pcとかduo-phoneは何がどうなっているのかよく分からないや。waccaとかP-ISMの実用レベルのものが普通の値段で発売されるのはいつ頃なんだろうなー。
_ ［tDiary-devel］ Re： Trackback or Pingback Plugin (20:17)
- [tDiary-devel] Re: Trackback or Pingback Plugin - http://www.tdiary.net/archive/devel/msg00619.html
Pingback plugin from Rubyにまつわるえとせとら日記の続き。
P2PとしてのPingBackの実装に関しては、利用者の意識においてのRefererとの違いがなさすぎる点（同様のことははてなダイアリー的TrackBackのはてなダイアリー内での利用にも言えるんだけど）に、あまり大きな意味を持てないでいるんだけど、上記で触れられているゲートウェイサーバーを介してPingBackを実装するってのは確かに面白そうだなー。
ゲートウェイサーバーへの依存が大きくなってしまってP2Pの手軽さは薄れてしまうけれども、ゲートウェイサーバーに集約された情報によってtDiaryサイト間のリンク状況が一望できるようになるわけだ。tDiaryに限らず一般に開放すれば、そのゲートウェイサーバー利用者全体のリンク状況が一望できる。
ただ、ゲートウェイサーバーの安定運用が面倒だろうなー。サーバーが落ちてしまうとすべてのユーザーの更新が重くなってしまう（タイムアウト待ち）だろうし。
_ Trackback情報を使って、サイト横断的に議論を閲覧できる未来 from void GraphicWizardsLair( void ); // (20:17)
- Trackback情報を使って、サイト横断的に議論を閲覧できる未来 - http://www.otsune.com/diary/2003/03/15.html#2003031512S1
［tDiary-devel］ Re： Trackback or Pingback PluginみたいなPingBack集約サーバーを使っても同様のことはできるし、あるいはblogmapみたいに外部からリンク情報を集約するサーバーを使ってもある程度はできる。けれども、そうするとどうしても一カ所のサーバーに依存した仕組みになってしまいます。
TrackBackは、現時点では私が知っている中で唯一、集約サーバーを持たずにそういうことができる仕組みです。その肝はTrackBack＋RSS。
あるネタ元となる記事があったとします。で、その記事にはTrackBack Ping URLが埋め込まれています。TrackBack Ping URLに?__mode=rssをつけて呼ぶと、その記事にTrackBackしている別サイトの記事に関するRSS（サイト一覧情報）が取得できます（うちではまだ実装していないけど）。
TrackBack Ping URL?__mode=rssで取得したRSSの各アイテム（ネタ元に言及している記事URL）に対して、再びTrackBack Ping URLを取得しに行きます。すると、さらにその記事にTrackBackしている記事に関するRSSを取得することができます。以降、TrackBackがなくなるまで繰り返す。
という処理によって、ある元記事に関連した記事をツリー構造的に自動でたどることができるのが、TrackBackの描く未来像なわけです。もちろんいちいちすべてのTrackBack先をたどらなくても、RSSにはSummaryが提供されているので、Summaryで満足したらその枝の先をわざわざたどることもないでしょう。
このような仕組みは、非常に多くのサイトがTrackBackをフル実装していないとあまり意味がないので、現時点では有効活用している事例を見せることができないんですけど。上記のような処理を行うRSS Readerを作るのは結構簡単なんで、今度暇なときにでも（っていつだろう？）そういう動作するReaderでも作ってみます。
で、個人的に重要だと思うのは、TrackBack技術においては上記のような処理を行うために、情報を集約するサーバーが必要ではないこと。各サーバーが独自にリンク情報を持っていて、必要になったらそれをたどるだけなので、一カ所のサーバーに依存することがないわけです。
_ ?__mode=rssを実装 (20:17)
TrackBack Ping URLに?__mode=rssをつけて呼ぶと、その記事にTrackBackしている記事のRSSを出力する機能を追加。言うだけだとなんなんで、一応TrackBack関連の機能はフルに実装しておくか。じゃないと、Readerのサンプルを作る実験もままならないし。
channelノードに出力する内容を勘違いしていたんで、修正。ちゃんと該当の記事の情報を出力するようにした。あと、TrackBackが存在しないときにどう返すべきなのか、仕様書には書かれていなかったんで、MovableTypeサイトで実地で確認。itemなしのrssを返すのが正解なのね。要するに、__mode=rssでは、基本的にその記事単体のRSSを返しつつ、TrackBackが存在した場合は、そのTrackBack記事のRSSをitemとして出力するわけか。
2006-03-15
_ Athlon64とPentium4のサーバー用途での性能
結局のところ、同等のモデルナンバー/クロックのAthlon64とPentium4（たとえばAthlon64-3200+とPentium4-3.2GHz）って、サーバー（Web＋DB） 用途での絶対性能としては、どっちがいいんだろう？ 価格とか消費電力とかは考えずに、Web/DBサーバーとしてそれなりの環境を整備した上での絶対性能ね。
総合評価はほぼ同等らしいから、64ビットコンパイルしたアプリ（特にDB）が使える分、サーバー用途ではAthlon64の方が上なのかなーと思いつつも、やっぱり最終的にはクロック速度が効いてPentium4の方が上かもなーとも思う。
ググって見ても、Athlon64に関してはホビー用途での事例がほとんどだし、その評価に関する記述も、たいていの場合はコストパフォーマンスや消費電力も加味した総合評価っぽくなっていて、いまいちその実用レベルでの絶対性能評価が見えない。
その辺具体的に比較してみた事例ってどこかに公開されてないでしょうか？ っつーかぶっちゃけ、さくらのAthlon64ってどうよ、と思っているわけですが。
