hoshikuzuの日記

2005-05-15

自動リンクのTESTです。

<META HTTP-EQUIV="refresh" CONTENT="0; url=javascript:document.title=document.domain">

http://d.hatena.ne.jp/help#stoplinkと編集画面で書くと以下の通り。

http://d.hatena.ne.jp/help#stoplink

https://bugzilla.mozilla.org/attachment.cgi?id=71224


自動リンクになっているじゃん・・・・

とかいう勘違いをマジにしたです。ははははははぁぁぁ(力無く)

tako {kani:ika}

2005-05-03

見出し1

うぅぅ。失敗失敗。

はてな省略記法って私には難しい。。。リンクすら思うように作れません。

見出し2

あうあうあうあぁ~

2005-04-08

なるほど

yukattiさんの懸念はご尤もですね。支持。でもyukattiさんにはてなをやめてほしくないなぁ。

http://beta.g.hatena.ne.jp/yukatti/20050331/1112248345

2004-07-10

pure CSS menus

Pure CSS Menusというページがあります。

このページの右側にあるメニューはIE以外の有名どころのブラウザを使って閲覧していればonMouseover(正確にはhover:)にて階層的なメニューをダイナミックに表示するはずです。このメニューはjavascriptを使っていません。CSSのみに頼っているのです。UL-LIな構造にhover:な時のスタイルを設定しているとか。ふぅん本当ですか?後でじっくり見てみましょう。javascript抜きなのでPure CSS Menusと名前をつけているのでしょうね、恐らく。

IEでは、hover:な時のスタイルはa要素だけに使えるので上記のメニューには何も面白さを感じません。いえ、使うことが出来ません。IEを切り捨てるという明確なポリシーにはちょっと賛成しかねます。

そこでとある考えが出てきます。IEのことをも考えるWEBサイト製作者殿には、どこでもhover君、いえいえ、whatever:hoverを使ってはどうかと。どこでもhover君を使うとa要素でしか使えなかったhoverが生きてくるとか。実際にはスタイルシート内でhover記述があるところを見つけたらjavascriptで補完するような汎用の.htcを用意した、ということなのでしょう。あれ?あれれ?

ということはjavascriptオフで閲覧している人にはやっぱりかわいそうですねぇ。いえね、オフであってもしっかり使えるページが正確なHTMLで記述してあってその上でjavascriptで効果をつけるのなら問題なしとしましょうか。でもPure CSS Menusの場合は、、どうなんでしょ。ダメでしょ?

工夫のしどころがまだあるのかなぁ。どこでもhover君自体、おもしろそうなんだけれどなぁ。

2004-05-04

■2重更新の謎

2重更新の謎

以前見かけたのだけれども、はてなダイアリーのキーワードについてほとんど同時並行で3人ぐらいが公益の為に共同作業でがんばって編集していらしたんです。誰かが編集終わって登録した後、別の人が登録したら元のモクアミ、てのをどうやって凌いでいたのだろうかと凄く不思議でして。

最初、キーワードに『もも太郎は鬼が島で鬼を退治した』と書いてあったとしましょう。で、次の順番で作業が行われるとどうなのだろうかと。

  1. AおよびBが共に『もも太郎は鬼が島で鬼を退治した』を編集の為に読み出す。
  2. Aが、『お伴の三匹に助けられてもも太郎は鬼が島で鬼を退治した』と編集画面で修正する。
  3. Bが、『もも太郎は鬼が島で鬼を退治して宝物を奪って凱旋した。』と編集画面で修正する。
  4. Aが編集内容を登録する。
  5. Bが編集内容を登録する。

上記の作業の結果、Aの編集内容はマルキリ消えてしまっているはずです。『もも太郎は鬼が島で鬼を退治して宝物を奪って凱旋した。』だけが残るはずですよねぇ。Aの作業が無に帰すような不幸な事故が起きなければいいがなぁと思ったものです。あるいは、より密接なやりとりをしつつ、、なんとか防止したのであったのでしょうか。この種の事故が起きないようにする仕組みがはてなにはあるのだろうかと当時、疑問に思いましたし、今もわかっちゃぁいません。

シンプルな防止策はあるのか

シンプルな防止策はあるのかどうか知りませんし、現段階で対策が既にウタレテいるかどうかも知りません。ただ、私なりに、私だったらこうするカモという着想だけ書いてみたくなりました。「はてなグループ」という名前がついている以上、2重更新の悲劇を避けておいたほうが受けがいいはずですしね。

排他制御、共有制御などをデータベース側に持ってもらう、あるいはサーバOSレベルで深いことをする、そんなことは私の力量にあまりますので、本当にシンプルで、しかもロールバックの必要がない仕組みを考えたいと思います。OSやらデータベースやらファイル制御によるロックやらなんちゃらレベルではない仕組みを。考えたいです。

注目すべきなのは、ヒトリが更新している記事は常にヒトツだけで、他に影響が出ない、と仮定しても良さそうだという点です。この仮定は非常に強い仮定ですので、2重更新防止にとって楽な仮定ではなかろうかと思います。逆にどういう時に難しいかというと、ひとつの記事の結果が同時に他の記事の結果に反映されてしまう場合などです。たとえば、そうですね、若い結婚したての夫婦がオンラインで家計簿をつけていて、1ヶ月あたりの書籍費の合計には、夫婦あわせてトータルにて予算上の上限がある場合なんかはどうです?夫が3千円の買い物をしたと買い物日記に書く。妻も2千円の買い物をしたと買い物日記に書く。予算上の残金が常に計算される夫婦共同家計簿日誌にリアルタイムで残金を計算しておく。。。これなどは、関連性が深い記事同志で牽制しあいながら矛盾が無い様にデータを更新しなくてはいけませんので、システムはかなり気を使わなくてはいけません。ところが、今回考えようとしているのは、たったヒトツの記事の同時更新ですから、ラクなのかも、と思ったりします。

防止のための仕掛け

特定キーワードの同時共同編集にてせっかく書いた記事がつぶれないようにしたい。その為の仕掛けはシンプルに次のように考える。

各キーワードには、そのキーワード独自の更新カウンターを持つ。上限は充分に大きければ良い。このカウンターは、たとえば<head></head>内側にコメント行扱いで持っておけばよい。人間が編集可能な領域にあってはいけない。また、FORMなどで使われるhiddenなコントロールでもいいかもしれないがちょっとヨワイかなぁ。以上のように、はてなの既存のデータに組み込めるので別途特別な管理機構は不要。

更新に成功したときにのみ、更新カウンターを1だけカウントアップすることとする。

以上で仕掛けはおしまい。

どうやって悲劇を防止するのか

キーワードの編集の為に、人は最初読みこむはずだ。そのときの更新カウンターはブラウザ側に保持される。次に、人はその内容を修正する。この段階でカウンターは不変である(不変でなければなるまい)。そして、登録ボタンを押すことにより、更新が終了。とまぁこんなハズだ。

防止策のポイントは、上の流れに1個、仕掛けを利用して2重更新のハドメをかけること。登録のボタンを押したときに【タダチに更新】はなされない。登録ボタンを押した瞬間にシステムは、【その時点での】キーワードの更新カウンターを参照し、かつ、ブラウザから送られてくる更新カウンターと比較するのだ。これが一致した時にのみ、更新は実行され、更新カウンターが1だけUPされる。仮に一致しなければ、人は、自分が編集している間に、誰か別の人が更新してしまったことを知る必要がある。ユーザインタフェース的には、たとえば、登録ボタンを押したら、そのボタンの横に【他の人から更新がなされた為、あなたの編集内容は最新のものからの変更になっていません。更新はなされませんでした。修正したかった内容をコピーするなどして保存した後、今表示されている更新キャンセルのボタンを押してください。最新のキーワードが表示されます。その後、再度編集してください。】とか出ていればそれだけでいいような気がする。

本当のことを言うと

本当は上は完璧ではなくて、ファイルなりデータベースなりの共有排他制御に密接に関わってくるのでなんともいえないけれど、大抵は、かなりの確率で不幸な2重更新はなくなるはずだ。

このアイデアの肝は、更新があったかどうかを、古い記事と新しい記事とで全部比較してシステム的に検出するなんてことは不要ですよぉ、と言いたいだけだったりします。

記事ひとつだけで考えればいいのでたぶんデッドロックの発生も回避できる、というか考えなくてよさそうですしね。

太陽系惑星間オンラインシステムの構築

太陽系惑星間オンラインシステムの構築を私の子孫がやっている姿を見かけたら、上のアイデアをちょっと吹き込みたいぁと夢の中で思ったことがありますのですが、私のようなシロウトはこんなことは言ってはいけないのだと萎縮していたりします。ゲラゲラ。トモダチのSEに聞いたら自分が抱えているローカルなデータとセンターにあるデータとを完全に比較した上でOKが出たら更新できるのだとか言っていたので。。。たいへんだろ、そんなプログラムは。とか思ったり。

中国語でも萌と書くのか

nobodynobody2004/05/06 21:36ども、むたいです。nobodyの日記(beta)へのコメントどうもありがとうございました。

nobodynobody2004/05/06 21:37それで、はてなのTeX記述の支援機能が改良されたそうです。よろしければ動作確認などしてみてください。

nobodynobody2004/05/06 21:43それから、更新の衝突に関しては、はてなのキーワードは楽観的ロックのような感じで実装されているようです。たぶんYukiWikiとかHikiとかPukiWikiとかと、同様のつくりじゃないかなぁと想像してます。で、実際に同時期に更新がなされようとすると、「更新が衝突しました」といった感じのメッセージ画面が表示されます。そして、その画面には、(更新しようとして衝突したところの)記述内容が表示され、自分の書いた内容を確認したり、いったんローカル・マシンのクリップ・ボード領域にコピーしたりできるようなつくりだったはずです。ご参考になればさいわいですけど。論点を勘違いしていたりしたら、すみません。

hoshikuzuhoshikuzu2004/05/07 20:28楽観的ロック、、、激しく初めて聞きました。TeX記述については、mimetex.cgiの実装方法を本家にあわせて頂きましたので、ほとんどOKです。若干謎が残っているのですけれど。。。多量に「お試し」してみないといけません。