いつのまにか Submission failed: Plugin bug: Not all request variables are set とか出ていた。サッパリ意味がわからないのでフォーラムを見てみると Submission failed: Plugin bug: Not all request variables are set - Foobar2000 - Last.fm とかいうスレがたっていた。んでその中にある ThePsycho 氏の投稿 の通りやってみたら、なおった。

  1. トップ
  2. music
  3. Audioscrobbler :Not all request variables are set
  1. トップ
  2. net
  3. Audioscrobbler :Not all request variables are set

やれやれ については再構築されて慣れたのだけど、今度は「ままならない」の意味がうまくとれなくなった……「ままならない」っていう語感は違和感がない。「ままならない」の意味が唐突に理解できなくなった。うむむ。ままならないなぁ?

  1. トップ
  2. life
  3. 今度は「ままならない」

新しい CSS を適用。ATH-W1000 をイメージして赤っぽく。

今までの CSS は昔書いたやつの流用だったのでちゃんと書いた。

Opera8.5 がなんかやたらぶっとんだ計算をしていて困った。のりさんCSS_Hacks を教えてもらい、CSS3 media queries を使うことに。このハックはいずれ Opera 以外のブラウザで表示が乱れるハックなので使いたくなかったけど……

ath-w1000.css。ファイル名のとおり ATH-W1000 イメージです。なんか色合いがスキなので。

デザイン自体は学校の講義一個潰して集中して作ったからなんともいえない感じに……しかも広いほうの端末室 (謎) で作ってたから覗かれていたかもしれない。覗かれていたらバレるかもしれない。何かが。

ほんとは、、、、へっどふぉんした、、、おんなのこの、、、しゃしんが、、、、つかいたかった!!!! (この写真男の子だよね? 外人よくわからん) とりあえず、だれか撮って Creative Commons で公開してけれ

ヘッドフォン娘 で検索すると2位にランクされるようになった。Cool URI のおかげ?

  1. トップ
  2. web
  3. Meta*Headphone-Girls の CSS

寝たり起きたりするうちになんとなく実装したのがソレっぽく動いた。睡眠回数が多いほうがアイデアが浮かぶに違いない。

positive_mode = []
negative_mode = []
mode = positive_mode
arg_pos = 0
message[1].each_byte do |c|
case c
when ?+
mode = positive_mode
when ?-
mode = negative_mode
when ?o, ?v, ?k, ?l, ?b, ?e
mode << [c.chr, message[2+arg_pos]]
arg_pos += 1
else
mode << [c.chr, nil]
end
end
mode = nil
# when message is ["#chokan", "-o+v", "chokan", "chokan"]
p negative_mode #=> [["o", "chokan"]]
p positive_mode #=> [["v", "chokan"]]

うっさい

  1. トップ
  2. ruby
  3. IRC の MODE をパースするのがめんどい
  1. トップ
  2. irc
  3. IRC の MODE をパースするのがめんどい

ざっと読み直すと同じ事を何度も何度も書いていることを気付かされる。想像力とヒーローって言葉が多い。実際今も俺はこの二つを非常に重要だと思っているけど。

  1. トップ
  2. self
  3. reread memo

構造が気持ち悪い。とりあえず tDiary の話。はてなにも言えるけどはてなはソースを変えられない時点で「諦め」があるので論外。

tDiary には CSS によるテーマ機能があって、(たぶん) それがウリなんだろうけど、そのせいで構造が変えにくい。「変えにくい」ってのはテーマを使いたいからでなく、スキンファイル (構造を決定するファイルってことにしてください。CSS は含みません。) が難読になっていたり、プラグインの吐くソースがキモかったりする。「どうせテーマを使ってもらうんだから構造は決めうち。スキンファイルは開発側が編集できればいいや」みたいな。

俺が tDiary を使っていたとき、そういう気に入らない構造の部分をざっくり修正して使っていたんだけど、バージョンアップしようと思ったときに死んだ。そしていろいろあって tDiary を使うのをやめた。使うのはやめたけど ML は読んでる。なんとなく。

少し前に「form 要素直下に input 置くと validator に怒られるので div で囲う」みたいなメールが流れてた。あはははって感じ。

誰もが納得できる構造にするのが一番いいんだけどそれは難しい。だから、スキンファイルをシンプルに。変なソースがあってもユーザが修正できるように。スキンファイルを編集しても別なところでエラーがでないように。バージョンアップのときにスキンファイルを変えなくてもいいように。

ちなみに「誰もが納得できる構造」であれば CSS によるテーマってのはすごく素敵なもんなんだよなぁ。というかおかしいんだよ。「誰もが納得できる構造」って何なんだ。

まぁでも、こんないちいちキモイ構造がどうとかいうのは strict ヲタクぐらいなもんだろう。

そもそもカテゴリが違うといえど blosxom はよろしいな。構造?なにソレ?ていうかボク HTML なんて知らないよ、みたいな。バージョンアップしねぇじゃんとかは禁句らしい。

放任したほうが楽ちん。やりたい人は tDiary 互換フレーバーとかあるしなぁ。よくわからんセクションになってるのは俺の頭が悪いうえに今眠いからです。

  1. トップ
  2. ruby
  3. CSS をテーマにするのはいいけれど @tDiary
  1. トップ
  2. net
  3. CSS をテーマにするのはいいけれど @tDiary
  1. トップ
  2. script
  3. CSS をテーマにするのはいいけれど @tDiary