ちょｗｗｗｗｗｗｗ人気ｗｗｗｗｗｗｗｗｗｗ
「1から書き直した」へのコメントで指摘されたので当時のXSLTファイルをアップロードしなおした。手元のマシンにないファイルも多かったが、Wayback Machineから2つほどサルベージできた。当時のファイルは外付けHDDのどれかに眠っているはずなので、折をみてアップロードしなおしたい。ていうか件のエントリとかDFN要素から索引を作るやつとか見直してみると、正規表現でやればいいのに無理してXSLTを使っているあたりが面白い。正規表現も知らずにXSLTばかりやっている。
あとコメント一覧を出すページは前々から実装しようとは思っているのだけど、まだその域に達していない。
エゴサーチをしていたらGlobal Voicesというサイトに私のTwitterポストが引用されていた。よく見ると「日本語」とあり、これは…と思い原文を見ていたら、私の雑な日本語が英訳されていた。そういえば「絵文録ことのは」で昔、記事の全文引用とか翻訳とかの話が盛り上がっていたなあと思ったけど(いま検索してみたら「木村剛氏の「ブロガーとしての資質」を問う」の脚注くらいしか見当たらなかったけど、もっとほかにもあったはず。それともこのネタの主戦場はインフォーマルのほうだったかしらん)、そんなことより単純にうれしかった。私の文が第三者の手で英語に訳され公開されたのを見たのは多分これが初めてだ。
やっぱプロが編み出しただけあって「あらたにす」のネーミングセンスはすごい。仮称のANYがAllataNYsの中にちゃんと入っているし、"新s"ということで新しいかんじプンプンだし、新はNEWなのでこれすなわちNEWｓサイトでもある。
が
Just as I thought, the naming of “Aratanisu” is amazing precisely because professionals came up with it. The word ANY is properly included inside AllataNYs, “新s” gives the sense of something new, and 新 means “new” — in other words it is a NEWs site.
になった。30秒くらいニヤニヤできた。仮称のANY
の仮称の
の部分が訳されてなくね? とか思ったけど、多分私の語学力不足だろう。
ただ、引用されたエントリは、ひとつのURIを与えるにはあまりにも断片すぎる。"Allatanys"は"AllataNYs"ではなく"all at ANYs"であって、これを加えないと私の「あらたにす」賛辞は完結しない。かつて話題になった「段落アンカー」をさらにひどくした問題がここにはあるように感じられる。「段落アンカー」の場合は、まだ参照された段落の上下に関連のありそうな記述が続いていることを視認できうるからまだ良いかもしれないが、Twitterの場合は前後の記事へのアンカーさえない。それでいて削除はできても編集はできない。
さらに私はEnter一発で投稿のできるTwitterクライアントも使っているし、何気ないことでも1000人弱のFollowerのタイムラインから自動にハイパーリンクも張られるし、さらに数多くあるTwitterマッシュアップサイトのDBにコピーされまくる。2ちゃんねるの場合は誹謗中傷や個人情報が書かれても大元を削除すればとりあえずいいのかもしれないけど、Twitterでそれが行われた場合はどうすればいいのだろう。いっせいに削除申請ができるように、Twitterを頻繁にクロールして書き込みをミラーリングしているサービスの一覧が必要なのではないか。とりあえず、間違えてEnterを押して誤投稿ということがないようにCtrl+Enterで投稿するようにクライアントの設定を変えた。
で、あらたにすの新しいところは新聞紙の1面記事を一覧に見られるところに尽きて、そんなのGoogle Newsとかでいいしｗという反応がよく見られたけど、それはちょっと脊髄反射に過ぎると思う。
新聞紙は有料で買うものでニュースサイトは無料で見るものという今の状態を広告費とかを除いて表面だけで考えると、私たちはニュースそのものではなくニュースのレイアウトの仕方に対価を支払っていると考えられる。見出しの大きさや書体、どのニュースをどこに配置するかといった編集のおかげで、忙しい朝の時間に新聞をナナメ読みすればだいたいどんなニュースが話題になっているのか概観できる。「あらたにす」はそうして考えられた1面記事を3紙まとめて見られるサイトなわけで、読者が記事そのものでなく記事の見せ方にお金を払っていると考えるなら相応の意味があると思う。ただ、あくまでHTMLレベルの情報提供にとどめようとしているあたりがせこいといえばせこい。フィードを提供して機械可読にしてほしい、とは当然思うけど、副作用も強いだろうし現状ではこのレベルが新聞社側の精一杯の譲歩なのだろう。これからどんどん試行錯誤が行われていくだろうし、ぜひうまくつきあっていきたい。
先日の正規化ネタの件でid:teramakoさんがdel.icio.usでの例を紹介して下さったので移行してみた。
今までこのブログで記事とタグの関係がどうなっていたかというと、教科書どおりに正規化していた。ただ、タグそのものにIDをふって [items] - [item_tag] - [tags] という構造ではなくて、[items] - [tags]という形になっていた。以下のような感じ:
| id | title | body | date |
|---|---|---|---|
| 1 | 地球空冷化 | <p>最近、私の ... | 2001-08-04 00:01:00 |
| 2 | 台風一過 | <p>幸運なことに ... | 2001-08-22 00:01:00 |
| item_id | tag |
|---|---|
| 1 | 生活 |
| 1 | 自分のこと |
| 2 | 2ch |
| 2 | コロッケ |
| 2 | 台風 |
この構造の問題点は、たとえば「Opera」と「ノウハウ」を含んで「演劇」を含まない記事を出したい! というのが面倒なこと。そのかわり正規化されているからとってもリレーショナル。ある時期に頻出するタグを求めるみたいなことがTF-IDFの応用ですぐできる。HarmanとSparck Jonesによる正規化を組み合わせると、ある期間に頻出するタグiは、log2(タグiのある期間内での登場数+1) / log2(ある期間内に登場したタグの種類数) * (log2(全記事数 / タグiがつけられた記事数) + 1)で求められる。ちゃんと正規化されていればこの計算をSQLで行うのは簡単だが、1セルにすべて閉じ込めてしまうととたんに面倒になる。ただ、そんな頻度の少ない処理が面倒になることよりもいつも行う処理が1つのテーブルを参照するだけですむことのほうが重要だ。記事のCRUDが1テーブルでできるようになれば、記事の更新をphpMyAdminから行うことだってできる。
ということで、"MySQLicious" solution を目指す。以下のような感じ:
| id | title | body | date | tags |
|---|---|---|---|---|
| 1 | 地球空冷化 | <p>最近、私の ... | 2001-08-04 00:01:00 | 生活 自分のこと |
| 2 | 台風一過 | <p>幸運なことに ... | 2001-08-22 00:01:00 | 2ch コロッケ 台風 |
これをSQLだけでやるにはどうすればいいか。カラムの更新なんだからUPDATEだろjkと思い、下のようなクエリを発行したら#1242 - Subquery returns more than 1 rowと怒られた:
UPDATE items SET tags = concat(tags, ' ', (SELECT tag FROM tags WHERE items.id = tags.id));これが数値だったら、group byしてsum()したのをupdateすれば終わってたのになー。そんなこといってもしょうがないのでもう少し考えてみたところ、on duplicate keyを使う案をひらめいた:
INSERT INTO items(id, tags) SELECT old_items.id, tag FROM old_items LEFT JOIN tags USING (id) ON duplicate KEY UPDATE tags = concat(tags, ' ', tag);いやーon duplicate keyって便利ですねー。
ただ、これ逆のことをやろうと思ったらSQLだけじゃできないだろうなあ。
4.1以降ならgroup_concat()関数が使える。この関数の存在に今日気づいたので追記。
先に触れた、「ある期間中に特に現れるタグ」の計算が面倒になった。今まではこんな感じで計算していた (一部テヌキのためにテキトーな数字で決め打ちしているところがある):
SELECT tag, log(count(tag) + 1) / log(5) * (log(2240/count) + 1) score FROM tags LEFT JOIN df USING(tag) LEFT JOIN items USING(id) WHERE date between ? and ? and count > 1 GROUP BY tag ORDER BY score desc, count(tag) desc LIMIT 10;変更後はこうなった:
SELECT tag, log(sum(CASE WHEN length(tags) = length(replace(tags, tag, '')) THEN 0 ELSE 1 END) + 1 ) / log(5) * (log(3350/count) + 1) score FROM df LEFT JOIN items ON tags like concat('%', tag ,'%') WHERE date between ? and ? and count > 1 GROUP BY tag ORDER BY score desc LIMIT 10;ということで、はじめてCASE式を使ってみた。CASE式は面白いので、ぜひSELECT句で分岐させていきたいですね。
副作用だといえるものは、多分これくらいだと思う。LIKE検索で検索が遅くなるのは、このサイトくらいの記事保持数やアクセス数だったらそこまで問題にはならないだろうし、それより内部処理が簡単になる利点を求めたい。
最近はてなスターが良い感じになったので、是非これをtxqzにも設置したいと思い取扱説明書を読んでみた。リリース直後に書かれた文書の中には:
ふつう，この手のブログパーツではボタンは任意の位置に配置される。ひと口にブログといっても使われ方やデザインは千差万別だからだ。なのに HatenaStar.js はタイトルにアンカーを張ることを強要し，さらにそのタイトルの横にボタンやスターを表示させることを強要する。つまり HatenaStar.js は利用者に「はてな流」を押し付ける。こんなセンスの悪いブログパーツは見たことがない。昨夜 Twitter で叫んだのもまさにこの点が癇に障ったからだ。
という批判も見られたが、今ではJavaScriptを書くことによって任意の場所にはてスタのアイコンを載せられるようになっている。とにかく、タイトルの横にアイコンが来るのはかなり恥ずかしいので、この機能を知ってやっと載せたくなった。いやあの、私のはてブのコメントにちらほらスターが着くようになって嬉しくなったのが大きいんですけどね。
取説のサンプルとにらめっこをして、記事別ページについて以下のようなスクリプトを書いた:
Hatena.Star.EntryLoader.loadEntries = function() {
var entries = [];
entries.push(new Hatena.Star.Entry.TxqzNetArticle());
return entries;
}
Hatena.Star.Entry.TxqzNetArticle = new Ten.Class({
initialize: function() {
var heading = document.getElementsByTagName('h1')[0];
this.title = Ten.DOM.scrapeText(heading);
var feedback = document.getElementById("feedback");
this.uri = feedback.getElementsByTagName("input")[0].value;
this.comment_container = Hatena.Star.EntryLoader.createCommentContainer();
var hatesta_label = document.createElement("dt");
hatesta_label.setAttribute("id","hatesta_label");
hatesta_label.appendChild(document.createTextNode("はてなスター"));
var feedback_dl = feedback.getElementsByTagName("dl")[0];
feedback_dl.appendChild(hatesta_label);
var hatesta_container = document.createElement("dd");
hatesta_container.setAttribute("id","hatesta_continer");
feedback_dl.appendChild(hatesta_container);
hatesta_container.appendChild(this.comment_container);
this.star_container = Hatena.Star.EntryLoader.createStarContainer();
hatesta_container.appendChild(this.star_container);
}
});記事別ページにはアンカーがない。それは、記事別ページからその記事へのアンカーを張ることが無意味だからだ。しかし、たまたま「トラックバックURL」があったのでそれを利用することにした。これがなかったらどこかにURLを追加しないといけないことに……と思ったけどlocation.hrefから取得できるじゃん。まぁいいや。
昔はTTTEditorを使っていました。Ctrl+pで<p></p>が出るなどとショートカットを設定できるので、なんかいろいろ設定してました。いまは、EmEditorとかの一般的なテキストエディタに書いてコピペしてます。
XHTML1.0 Strictにしています。前はXHTML1.1でした。ruby要素を使いたかったから。ただ、面倒であることや技術的な問題などでメディアタイプをapplication/xhtml+xmlにせずにtext/htmlにしてました。いまは、別にXHTML1.1なんて使わなくてもXHTMLであればよい (XML処理系でいろいろできる) のでXHTML1.0にしています。Strictなのは、別にTransitionalな要素や属性を使う必要に迫られていないからです。
正しく書かない理由がないからです。でも、たまに間違って正しくないHTMLになっちゃうこともあるよNE。
後者のことをよく知らないので答えにくいですけど、別にW3Cに絶望していたりはしません。
よく普及したマークアップ言語。
というか、アレですね。質問ネタといえば100質のマークアップの話が思い出されますね。あのとき私は
- これは1番目の質問から100番目の質問という順番に意味があるリストなので、是非ol要素としておきたい
- 一つの質問に一つの回答が付くから定義リストであるような感じなので、是非dl要素としておきたい
- すると、ol要素の子要素にdl要素が来て、
某方面およびその周辺で良く見かけるマークアップとなる
なんて書きました。今は面倒なのでそのままdl-dt-ddです:-)でも、dl要素にqaって値のclass属性をつけて、
dl.qa dt{
display: list-item;
list-style: decimal;
}なんてやろうかな。Firefoxだとみんな0になっちゃうみたいだけど。
IEだと1,3,5……と飛び飛びになってしまう件。んー。
[righthtml5q][notvalid]liの終了タグ抜け?
直しました。
今まで使っていたs171サーバはMySQL4とかPHP4とか一世代臭が高まってきたのでs270サーバに移転してみた。ちょっと途中ドメインウェブの設定を怠っていたので30分くらいNotFoundになってたかも。しっぱいしっぱい。
XREA+サービスを使っていると無料でもうひとつアカウントをもらえるので、とりあえずそれを申請して、テキトーにテストをして、VALUE-DOMAINのページからサーバアカウントの移動をして終わり。アカウントの移動はVALUE-DOMAIN側でやる処理なんだねー。まぁそういうことで。
なんか今日はCSS Naked Dayらしいので、とりあえずCSSファイルを削除してみた。むに。
2003年に書いたdiv は divという文章がはてブで9人からブクマを頂いていることに今気づいた。いやー2003年4月ですよ2003年4月。ふにゃー
真琴さんがブクマコメントに
見出しにidを振っただけでは～に同感。
は、この追記以後にRFC 2396がRFC 3986に上書きされているので目を瞑る。#名前の部分は、URLの一部ではありません――これは覚えておかないと。
なんかRFCが改定されてここに書いたことが正しくなくなったモヨリ。ていうか1ヶ月1HTMLだったころの日記を1記事1HTMLにかえて、しかも一律code要素にdisplay:block;をかけているせいでかなり読みにくくなっていますよねこの記事。txqzも1回抜本的に整理してまた更新ができる状態に持っていかないと遺憾なと思っているのだけれどもなかなか手が回らなくてゲンナリ。あと真琴さんよろしければ今度一緒にビールを飲みませう。
ちょｗｗｗｗｗｗｗ人気ｗｗｗｗｗｗｗｗｗｗ
なんかテキトーな日記を再開したくなったので、今日から開始。
やっぱ文章にして残すのって大事だよね。
先週まで47だったお気に入りユーザ数が、おとといあたりから急上昇していま57になってる。なにがあった?
はてブお気に入りサジェスタのおかげなのらしい。
txqz は自前スクリプトだし全然メジャーでないのでそこらのブログ検索サービスからことごとく無視されていて悲しいので、とりあえずテクノラティに登録してみるテスト。
これでいいのか? ていうかじきにトップページから流れるエントリにこれを書いてもいいのか? pcdata のない a 要素ってなんか気持ち悪い。
- 216 名前： Name_Not_Found 投稿日： 02/05/02 18:47 ID:wAYvoeIs
ワンガンドーの新しいスタイル、イイな
- 217 名前： Name_Not_Found 投稿日： 02/05/03 17:34 ID:XGqZg0VB
>>216
その代わりに、折れが好きだった「Gray and Oldtype」がなくなったのは残念。
- 218 名前： Name_Not_Found 投稿日： 02/05/04 10:28 ID:gDLfnS4w
>>217
色使いが無茶区茶で、目が疲れないかい?
- 219 名前： Name_Not_Found 投稿日： 02/05/05 10:34 ID:pfQPuFbq
>>218
本文が読みやすかったから好きだったんよ。黒っぽいグレーの背景に灰色がかった白色文字ってのが。
ということでおまたせしました。濃い灰色バックに薄い灰色文字です。いや、やっぱり白地に黒文字で、しかもシングルカラムがシンプルでオサレだよねーと無理して思っていたけどやっぱダークグレーにライトグレーの方がいい。索敵とか3分間ネットワーキングとかこの色使いがたまらない。ということで、特に3分間ネットワーキングにインスパイアされて新しいシートを書いた。
ところで上の引用で216さんが褒めてくれたのがPurple and Tackleで、それを改良したのが峠の珈琲屋なのだけれども、久しぶりに自分が昔書いたスタイルシートを見直してみたら、ギャラリーを復活できるくらいに CSS を書きまくりたくなった。最近やけに CSS に脚光が当たっているみたいだし。
RSSに content:encoded を追加した。やっぱ description は先頭何バイトとかそういう教条的なのより全文がマークアップつきで RSS に載っているほうが便利だよねー。みたいな。ところでなんでこのサイトは「最新15件」とかで全文を表示しないんだろうねー。へぼミス。是正するかも。ゼファーマ。