Ajax るようにした。UI がイマイチ。
なんかいい方法はないかなぁ。
Opera でおかしい。めんどいので Opera はじく。
なんだか、この今のスタイルがまずだめみたいで、Opera だと挙動不審になる。
クッキーに保存を実装しろといいたい。誰に。俺に。
Ajax のほうのフォームはクッキーに保存するようにした。Singleton Cookie オブジェクト
CGI 設置するのとかめんどいので xpost-del-hatena.user.js, GM スクリプトにした。
はてなの認証方法がややこしいので、はてなをメインにして、del.icio.us をスクリプトで同期するように。新規ブックマーク, 編集, 削除がそれぞれ del.icio.us にも反映される。ただ、編集の場合、del.icio.us で上にあがってしまう問題がある (はてなの編集画面にはポスト時刻が表示されないのでめんどい)。
最初なぜか API 使わないで実装してた。頭が悪い
ちょっと補足します。
Fx 1.5.0.1 + GreaseMonkey 0.6.4 ではとりあえず動いています。中身で無駄に E4X 使っているので、1.5 未満では絶対に動かないです。
ついでに動いてても何も言われません。淡々と del.icio.us に追加されたり削除されたりします。(最初の一回は del.icio.us の API Basic 認証がでます。これには del.icio.us のユーザ名とパスを入れます。)
del.icio.us 側の操作ははてブに反映されません。「はてなをメインにして」はそういう意味です。
はてダ の2カラムさえなんか邪魔になってきたので ignore-hatena-2c.user.js 書いた。
GM ばっか書きまくり！！
GM の Edit ボタンが効かなかったんだけど、改めて about:config で設定しなおしたら使えるようになった。前より簡単につくれる＞＜
どうにも使い道が少ない E4X をちょっとメモる。
基本的に XPath (の省略記法) に似ているので、相違点とかあげつつみたいな。XPath は E4X に似せるため省略記法を使います。省略しないと全然違う。
var doc = <root> <foo>hoge</foo> <bar>huga</bar> <baz> <foo name="neko"> <bar>pqpq</bar> </foo> </baz> </root>;
doc.baz..foo/root/baz//foodoc..foo.(@name == "neko")//foo[@name = 'neko']or は ||, and は &&。doc.*/root/** はそのままの意味。@* もそのまま書ける。doc..foo[0]//foo[1]doc..foo.length()count(//foo)length() を使う。括弧をつけず length と書くと length 要素を選択しようとするので注意が必要。for each とかいう構文がある (構文？)
for each (ele in doc.*) {
// hoge
}
XMLList とかいうオブジェクトがある。無名の要素をルートにして作る。ちょっときもい。
// XMLList (DOM の DocumentFragment みたいなの) var xmlList = <> <li>1</li> <li>2</li> <li>3</li> </>; var doc = <root> <li>999</li> </root>; doc.appendChild(xmlList); doc.toString() //=> <root> <li>999</li> <li>1</li> <li>2</li> <li>3</li> </root>
名前空間
var rssDoc = <rdf:RDF
xmlns="http://purl.org/rss/1.0/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel rdf:about="http://example.com/">
<title>Example</title>
<link>http://example.com/</link>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://example.com/3"/>
<rdf:li rdf:resource="http://example.com/2"/>
<rdf:li rdf:resource="http://example.com/1"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://example.com/3">
<title>ex3</title>
<link>http://example.com/3</link>
<dc:date>2006-03-01T13:52:32+09:00</dc:date>
</item>
<item rdf:about="http://example.com/2">
<title>ex2</title>
<link>http://example.com/2</link>
<dc:date>2006-03-01T13:52:30+09:00</dc:date>
</item>
<item rdf:about="http://example.com/1">
<title>ex1</title>
<link>http://example.com/1</link>
<dc:date>2006-03-01T13:52:24+09:00</dc:date>
</item>
</rdf:RDF>;
var rdf = new Namespace("http://www.w3.org/1999/02/22-rdf-syntax-ns#");
var rdfs = new Namespace("http://www.w3.org/2000/01/rdf-schema#");
var rss = new Namespace("http://purl.org/rss/1.0/");
// var dc = new Namespace("http://purl.org/dc/elements/1.1/");
for each (i in rssDoc.rss::channel.rss::items.rdf::Seq.rdf::li) {
var item = rssDoc.rss::item.(@rdf::about == i.@rdf::resource);
alert(item.rss::title);
} 見ればわかるように Namespace オブジェクト作って :: を解決に使うみたい。使わないなら別に宣言しなくてもいい。あくまで E4X でアクセスするために名前をつける (=変数に代入する) ので、別にどんな名前でもいい。
var h = new Namespace("http://www.w3.org/1999/xhtml");
default xml namespace = h;
var HtmlDoc = <html>
<head>
<title>E4X</title>
</head>
<body>
<h1>for (;;)</h1>
</body>
</html>;
みたいなこともできるみたい。
XPath における following-sibling 軸のようなメソッドはないっぽい？とりあえず眺めてみたらないっぽい。よくわからん。
しかし、GreaseMonkey で E4X を使うにしても、XMLHttpReqeust のハンドラぐらいでしか使えなくてなんともかんとも。もちろん生成するのは自由なんだけど……
@ の働きがいまいちわからない。ちゃんと仕様読もう
そういえばおとといぐらいに携帯変えた。前に解約云々言っていたけれどなかったことに。
別に特別変えたかったわけじゃないのだけれど、二週間に一回ぐらい機種変する？とか親父が聞いてくる (去年ぐらいから) ので変えてみた。俺には基本的にメリットしかないわけで……よくわからん。
前のやつは 4年ぐらい前 J-Phone 時代なやつでして、予測変換さえないおもろい携帯でした。まぁ携帯でメール書かないので困らなかったわけですが。まぁ携帯にメール来ることがないので困らなかったわけですが。まぁ携帯に電話来ることがないので古くても困らなかったわけですが。
友達がいない僕は携帯を連絡手段じゃなくてカメラとして使います。あーあと時計？なんか俺は腕時計つけるのが苦手らしくて、今は腕時計を持っていない。というか同じような理由で靴下も履かなかったんだけど、冬はさむずぎるので履くようにした。意味わからん。
実際は消すんじゃなくて半透明にします。適用先は他の人の写真一覧のページ (/photo/username/)
以下スクリプトの説明
実は Set があるときとないときとで構造化の度合いみたいなのが違っててややこしい。具体的には Set がない人の一覧では div.StreamView 一個に対し、一つの写真と写真の情報が含まれる望ましい構造であるのに対し、Set がある人の一覧では、写真一覧が全部 div.StreamView 一個に含まれている。
ということで、Set がある場合とない場合にわけてる。きもいー。
Set がある場合、div.StreamView 以下の要素を一旦構造化する。
DocumentFragment を作っておく。div.StreamView 以下列挙してループh4 がでてきたら div (class="__GM_Photo") という要素を作るdiv.__GM_Photo に appendChild (一旦ノードは削除される)h4 がでてきたら DocumentFragment に突っ込むdiv.__GM_Photo も DocumentFragment に突っ込むdiv.StreamView に DocumentFragment を appendChild (戻す)DocumentFragment は DOM における無名ノードみたいなもの。名前そのまんまだけど！！！
appenChild は既に同じドキュメントにあるノードを追加するとき、一旦そのノードを取り除く。すなわち移動したいときはいちいち削除する必要はない。逆にコピーしたいときは cloneNode する必要がある。
そいでもって、Set がない場合は div.StreamView のクラス名に __GM_Photo を追加するだけしとく。
あとは、Set のあるなしに関わらず、CC の画像を含んでいない div.__GM_Photo にアレしてコレした的な何か。
FEEDBRINGER で未読がないフィードを非表示にする GreaseMonkey スクリプト。feedbringer-hide-read.user.js。まぁ誰か作ってるだろうけど……
最近 Sage から FEEDBRINGER に移行したのだけれど、俺はフォルダ分けを全くしない横着ものなので、未読がないフィードが邪魔で未読フィードがどれぐらいあるのかぱっとみわからない。そんなわけで GM。
消すだけじゃなくて、トグルできる (Toggle Read Feeds クリック) ので、導入しても弊害は少ないかなと思う。
Bloglinesの「Show only updated feeds」をチェックしてない人が多すぎる を見てからなんとなく考えてた。
feedbringer.css。すごく、きたないです。
/feed にしか適用しません。かなりソースがアレで苦労した。ソースがアレな上に、JS で擬似フレームの大きさを変えているので、そのあたりがかなり汚い……素直にフレーム使ったほうがいい気がする。
いろいろ変更。フォルダの矢印とか。
もっと理路整然と文章書けるようにならないといけないなぁってよく思う。頭悪いんだ。こう、理解できる限界線ってのがイメージとして見えていて、そこらへんを漂う思考っていうのは、もう少しもう少しって思えても全然まとまらない。数学とかやってるとその線が明確に見えてきてすごく嫌な感じ。あの理解できないっていう気持ち悪さはなんともいえない。
落ち着きが足りない、と言われる。
何か伝えようとする努力が足りないんだろうか。どうも書くだけ書いて、これで理解されないならいいやって思うことが多いように感じる。
だからレポートとかってすごく苦手なのですよ。あとで読み返したくないレポートができあがる。思い出したくない何かができあがる。気持ち悪い何かができあがる。
日記だからってのはよくないな。
document.write を使ってるおかげで、application/xhtml+xml だと使えないあの広告コードをどうにかして導入する。
まー Keystone Websites: Making AdSense work with XHTML をまるパクって、/google-adsense.html を作って、あとは object 要素作っといた。
<xsl:template name="adsense"> <div class="google-adsense"> <xsl:choose> <xsl:when test="$real-flavor = 'html'"> <script type="text/javascript"><xsl:comment><![CDATA[ google_ad_client = "pub-4629424540171624"; google_ad_width = 468; google_ad_height = 60; google_ad_format = "468x60_as"; google_ad_type = "text"; google_ad_channel =""; google_color_border = "000000"; google_color_bg = "F0F0F0"; google_color_link = "0000FF"; google_color_url = "008000"; google_color_text = "000000"; ]]></xsl:comment></script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script> </xsl:when> <xsl:when test="$real-flavor = 'xhtml'"> <object width="468" height="60" data="/google-adsense.html" type="text/html"></object> </xsl:when> </xsl:choose> </div> </xsl:template>
何が脆弱って、コンピュータ壊れたら、本気で何もやることがないのだ。今日メイン PC が起動しなくなって絶望した。セーフモードでは起動したので、chkdisk のフラグをフルに立てて再起動して不貞寝したら治ったのでよかったけれど、どうなることかとかなり憂鬱な気分になった。
お金があったら、こういう心配をしなくていいのになぁ。
Ruby の each 系メソッドで一つ気に入らないというか、仕方ないんだけど面倒くさいことがある。なにかっていうと index を使いたければ自分で変数作ってインクリメントしないといけないこと。each だけに関しては each_with_index があるけど、他の Enumerable なメソッドにはない。そんなに必要なわけじゃないし、だいたいは他のもっといい書き方が存在するんだけど、prototype.js の each 系を見てから、ちょっと不便だなぁって思うようになった。
prototype.js の each 系は全て index と item が両方渡される。でも、受け取る側の関数は仮引数を常に2個書かなくてもいい。ECMAScript は引数の数に無頓着だ。いくら渡しても怒られない。仮引数を書かなくても arguments で参照できる。
対して Ruby の yield はエラーこそ出さない (call は出す) ものの、こういうことすると警告してくれちゃう。別にそれが悪いわけじゃなくて、むしろいいんだけど、っていうか block.arity で場合わけすればいいんだけど。
なにがいいたいかわからんことに。
arity の数で場合わけしたらだめか。[[:a, :b]].each {|a, b|} みたいに使えないもんなぁ。
そういえば、日経ソフトウェアの 2001-03 (ふるい) のスクリプト特集に Ruby が載ってるんだけど、今さっき読んだら当時さっぱり何言ってるのかわからんことも結構わかるようになったりしてて、なかなか面白い。Perl の記事はわからんけど :(。で、その記事のコラムで、Matz さんが実行速度でPerlを抜きたい
って言ってるのが妙に印象に残ってた。そして今日その部分を YARV の記事を読んでて思い出したからこんなことを書いてるわけです。
日経ソフトウェアは2000-06 から 2001-06 までなんとなく買っていた雑誌で、結構お世話になった。扱いが荒いせいかボロボロだったり、コーラ溢して裏表紙が破けていたり、いやそんなのどうでもいい。XSLT も DOM もよくよく考えるとこの雑誌で記事を読んだのが最初の出会いであるし、上で書いた Ruby もそうだったりする。
入門書として、いろんな言語がいっぱい載ってるこういう雑誌って結構いい感じ。なんとなくもういいかなって思ったらちょうど一年分だったりして。これ買うのやめてからは一冊もプログラミング関連の本を買ってない (大学の教科書は別として) 。なんかぐーぐる先生とこの雑誌一年分で十分な感じ。そんな感じで今さっき意外と雑誌の情報って死なないんだなぁと思った。
当たり前だけど、雑誌を読んでプログラミングをどうこうしていたのは楽しかったからに他ならず、それから VB をやったり Javascript をやったりして最近やっと形になるようなスクリプトを書けるようになった。今考えれば結構長かったけど、あんまり長いことやってる自覚はない (し、別に実際長いわけではない)。だから俺はプログラミングにおいて何か努力したとかそういうことがない。これから、そういう努力をするハメになるのか、それとも楽しいままプログラミングと付き合って行けるかがよくわからないけど、願わくば楽しいままやっていきたいと思う。言い換えれば、努力なんて一瞬たりともしたくない。
なんとなく久しぶりにログインしたらサービス期間が終了しています。
やっぱ14歳ぐらいがちょうどいい身長だよなぁ。ポポスカと弓は合う。弓構えると背筋が伸びるのがよいよい。
とりあえずフレンドリストに入ってないギルメンに片っ端から追加リクエストを飛ばした。めんどかった。ギルメンに一括送信とか、ギルドに入ってる人の一覧をゲーム内で見れるようにして欲しい感じ。HTTP との連携は面白いんだけど、もっと何かできそう。もったいない。
検索オーバーレイをクロスブラウザ化しようと思って作業してて、よし IE で確認してみるかって思ったら、そもそも IE だと検索フォームがでてないのに気付いた。そうそう、この CSS 書くときにどうしても IE はちゃんとした位置に出せなかったから消してたのよねー、あははー。ばかかと
整理ついでに prototype.js を使うようにスクリプトを書き換えました。殆どイチから書き直しているのでおかしいかも。
といっても、引き継いだのはスタイルセレクタと検索の UI だけ。あとはそのうち付け足す。
検索の UI はとりあえず IE でもいけそうなところまできた、の、だ、けれど、結果表示が上手く言ってない。文字コードのせいかなぁ。
Opera は調子が悪いので確認してない。
よくつかうめそっど: each, bind。この二つは便利すぎてはなぢでる。foo.each((function (i) { this.bar.push(i) }).bind(this))
IE 対応完了。検索結果を XML で得るとき UTF-8 に変換していなかった。あとは CSS いぢりだけ。CSS いぢるほうが時間かかった。
Last.fm に統合してから Moderate 機能が使えなくなってるよなぁ。付け直したタグが重複してて気持ち悪いんだけど……
昔までのデータは残ってて、その分は機能しているように見える。THE HIGH LOWS が ↑THE HIGH LOWS↓ になるし。UI がないだけ？
どこに書けばいいのかなぁ。フォーラムだろうか。
エイリアスも MusicBrainz.com のデータ使うようにしたんだろうか。
未だに MusicBrainz が caseinsensitive だったらうざいな。
Artist moderation is done my MB integration, and there is the possibility of a site moderation too for artists.
MusicBrainz を使ってるけど、そのうち Last.fm でもやるかもよ？って感じかしら。
久しぶりに MusicBrainz 見たけど、the pillows, ART-SCHOOL みたいな表記が認められてるっぽい (前までは先頭大文字であとは小文字以外は不正で却下されてた)。ルール読んでないけど。
daimas DVD でハマってきた。プロローグよいよい。しかし本当に、ライブで見てもヴォーカルがイケメンすぎてもったいない。ちげぇよ！ なんかちげぇよ！ でもホント、プロローグは素敵。
あと関係ないけどストレイテナーがやっぱいい。ドラムのにーちゃんはいまいち好きになれないのはいいとして、TENDER のよさが最近わかった気がする。REBIRTH もいい。LOVE RECORDS もいい。EVERGREEN もいい。Reminder, The remains は今更言うまでもなく、さりげなく SAD AND BEAUTIFUL WORLD もいい。Melodic Storm は 窓に射す光る影の色が 瞬く度に変わるように
のところが素敵。
伝説板の BURGER NUDS スレで、バーガーに似てるバンドについての話が出てたけど、いまいちしっくりくるのがなくて面白い。
前にも何度か書いて、その度にどうしようもないという結論はでるものの、どうも何を書いていいか何を書いてはいけないかがよくわからない。所謂「常識的な判断」ってのは結局人によって違うから、ある程度参照するにしても、自分の常識と誰かの常識は絶対に一致することがないのだから、厳密な判断基準にはならないし、厳密な判断基準なんて存在しない。だから、誰かに文句をつけられることは、公開文書を書いている以上どうしようもない。とはいえそれだから何を書いてもいいかっていったら当たり前のようにそうではないわけで、その「常識的な判断」の範囲がやっぱりわかっていないといけないのだなぁって。
じゃあどうやってその範囲を見極めるかって言っても上手いこと簡単に見極めることができるなら、こんなセクションなんぞ書かないよなぁ。一対一の場合は何度か相手をキレさせることが必要だけど、不特定多数だとしたらそもそもその方法は通用しないし、むしろ相手をキレさせる気なんてしたくない。ってここまで書いて気付いたけれども、結局言いたいことなんて言わないのが一番いいわけか。なるほど。うんうん。気付くのが遅い。
しかしそれでも、たまに書く何かが誰の気に触れたり、作った何かを批評家気取りの誰かに罵られる可能性は常にあるし、これからもそれを続けるなら、いつか必ずあるといってもいい。今はまだ明確に敵意を持って直接言われたことはないけれど、今だって多少誰かが何かを思っているだろう。だから、それを受ける覚悟と、それを受け流せるスキルが必要なのだけれど、足りていない。どうやってそのスキルをあげるか。
ねむいねむい。
今日たまたまはてな RSS に lowreal.net を突っ込んでみたら 500 Error で登録できないことに気付きました。毎回ちゃんとリクエストしてるのが確認できるので、これ使ってデバッグ。
UA によって変わることというなら、ヘッダぐらいしかないので、ENV ダンプして再現するかやってみたけど再現せず、、っと思いきや ENV.clear してなかったので、clear してから突っ込んでみたら見事 500 発生。Accept が存在すると仮定しているコードがあったので @cgi.accept || "*" に書き換えた。はてなは Accept 送らないみたいだ。
HTTP の仕様を見ると Accept がない場合は "*" として扱うとあるので、どうせなら cgi.rb でここらへんのをやってくれると嬉しいと思った。
たぶんこれでブクマしたときに要約がちゃんと生成されるはず。ついでに投げ銭 Acceptable に ;)
以前CGI FastCGI, rubyとかいうセクションを書いたけど、ENV って普通に書き換えられることに気付いたのでもう一度やってみた。できたっぽい？
#!/usr/bin/ruby require "fcgi" FCGI.each do |fcgi| $stdout = fcgi.out $stdin = fcgi.in ENV.replace(fcgi.env) load(fcgi.env["SCRIPT_FILENAME"], true) fcgi.finish end
fastcgi.server = ( ".php" => ( "localhost" => ( "socket" => "/tmp/fcgi-php.socket", "bin-path" => "/usr/bin/php-cgi" ) ), ".rb" => ( "localhost-rb" => ( "socket" => "/tmp/fcgi-ruby.socket", "bin-path" => "/home/cho45/bin/ruby-fcgi.rb" ) ) )
ruby-fcgi.rb の位置がキモイけれど、これは共有ディレクトリを /home/cho45 以下しか設定してなくてめんどくさかったから。symlink 貼ればいいんだけど……
でもって以下のようなスクリプトでテスト
require "cgi" puts "Content-type: text/plain\n\n" @cgi = CGI.new p @cgi p @cgi.accept
全く普通の CGI と同じ形式。パッと見上手くいってる。POST のときどうなるか微妙だけどあとで追試。
ちなみに、これだとエラー出力がコンソールにでるけど、その辺は適当にログ残すようにすればいいかな。というか、load してるところの例外キャッチして美しいエラー画面を出すようにすればよろしそう。どうせログなんぞ見ない。
当たり前だけど、FastCGI 前提でプログラム書くならもっと最適化ができるので (リクエストごとに変わらない部分は共通にできる)、普通の CGI でもどっちでも使いたいという場合以外は積極的に使うようなもんじゃない。
ruby-fcgi.rb, エラーをスタックトレース付きで表示するようにした。
ENV.replace があった……
Dir.chdir するように修正。
hiki が一応動くっぽい。と、思いきや、リロードごとに 500 になったり 200 になったりする。なぞい。
$SAFE を設定されていたみたいだ。(リクエスト -> hiki でセーフレベルが設定される -> リクエスト -> セーフレベルがあがっているのでエラー終了 -> 見れない -> リクエスト -> fcgi プロセスが再起動される -> 見れるように) Thread 使って分離した。callcc 使うべきだなぁ。
学校の階段 なにこれ。
今日の IRC
21:43:37 w******> 学校の階段読んだのか 21:43:45 w******> まじえろげ 21:43:50 cho45> まじえろげ 21:43:53 cho45> なにあれ 21:44:00 w******> えろげ 21:44:07 cho45> 後半の姉さんの笑顔まじ萌えす 21:44:18 cho45> じゃなくて 21:44:23 cho45> なにあのえろげ 21:44:25 w******> 確かにあれは萌える 21:44:28 w******> じゃなくて 21:44:32 w******> なにあのえろげ 21:44:44 w******> まあそういうわけで 21:44:51 w******> 続編でたら買いますよ？ 21:44:55 cho45> かうのかｗ 21:45:03 w******> 絵買いばっちこーい！ 21:45:12 w******> せいせいせい早く続編書いてくださいよー 21:45:15 cho45> 冷たい姉とのからみキボンヌ 21:45:17 w******> やべえええ俺きもいいいい 21:45:50 w******> ツンとクールと元気と和み 21:45:51 cho45> あれも一種のツンデレだよなぁ。素直になれない系っていうか、素直に見られない系っていうか 21:45:59 w******> だな 21:46:14 w******> しかし主人公が素直になるだけであっさりデレる 21:46:25 cho45> クールは出てきたとき誰だかわからんかった 21:46:41 cho45> 見せ場までの間の存在感が激しく薄い 21:47:14 w******> まあ仕方ない 21:47:16 w******> だがそれがいい
構成考えたら家族の描写は全部いらないよなぁ。あと、なんか主人公が嫌い。