LDR でのメインフィード (RSS) の購読数が100を超えてた。
なんとなくメインのフィードが100いくのが区切りな気がしてたので書いてみる。
Atom は 23, RSS は 102。Bloglines は 100 いってない。
フィードの登録数
flickr 系 user.js for Opera
確認がとれたものと修正して動いたもの
- flickr-show-licenses.user.js (ライセンスをずばばっと表示する@Flickr)
- ignore-not-cc-photo.user.js (CC じゃないライセンスのやつを半透明にする)
ずばばっと表示させるやつはどうも挙動が怪しいです。動的にレンダリングするのを変えるのはやっぱちょっと苦手っぽい。
require 000.user.js
ignore-not-cc-photo.user.js を書き換えた。flickr が gamma になったときぐらいに HTML の構造を変えたらしく、もっと簡単に書けるようになっていた。ついでに $X 使うように修正した。
半月７, さよなら、いもうと。を読んだ
半月は短編集の前編らしい。なんかもうどうでもいいよ！
さよなら、いもうと。いもうと以外のキャラがいい。負荷軽減のためにわざとやっているのかなんなのかしらないけどそういう雰囲気。実際登場時間も少ない気がする。
「俺だって今日、死ぬかもしれない。明日、死ぬかもしれない。そのことがわかったはずなのに、少しも必死じゃない」 「必死じゃないといけないの？」 「いけないわけじゃないかもしれないけど……なんつうんだろ？ 明日死ぬかもしれないのにさ、今日をやけにのんびり生きてるんだよな。死ぬ前にやっておきたいこととか思いつかない。だからそのことを考えないようにして、また明日とか平気で言ってしまう。そんな自分のままじゃダメなんだって思うんだけど、でもどうするんでもないんだよな」
開始早々のアレとか、途中のイベントとか、最後のアレとか、随所に新井輝臭のようなものが漂っています。当たり前だけど
GreaseMonkey Script on Opera 9.00
9.0 がリリースされたのでいろいろ調べて書く。
XPath は割と普通に使えるっぽい。時々変な挙動な気もするけど。$X は書き換え無しに動く。と思いきや createNSResolver は動かない
innerHTML 使ってパースさせるやつ は Opera でもできるようだ。
Array#forEach や GM_xmlhttpRequest がないため、殆どの GreaseMonkey スクリプトは動かない (が、後述するスクリプトでほぼ解決)。ついでに Opera はハイパートリッキーなことをしないとドメインを超えられないようだ。
Opera 用のラッパは 000.user.js とか最初のほうに呼ばれそうなファイルに書いてあげればいいっぽい。000.user.js . インターフェイスのラッパだけです。ドメイン超えるのも 000.user.js に書けば普通にいけるかもしれない。
作ったスクリプトで確認がとれたやつを列挙する。
- hatena-newest-top.user.js
- hatena-kill-seemore.user.js
- hatena-highlight-fragment.user.js
- hatena-bk-neglect-comment-by-id.user.js
- hatena-bk-show-ss-and-comments.user.js
E4X とかクロスドメインとかでひっかかる。E4X を innerHTML + XPath にし、クロスドメインのハックをすれば動くと思われる。
- xpost-del-hatena.user.js : E4X, cross domain
- flickr-show-licenses.user.js : E4X
それと、日本語は素でかけないようです。\u でエンコードする必要あり。スクリプトを直接編集する場合もです。(GreaseMonkey はインストールするときに化けるらしく、直接編集している限りは日本語は普通にかけます。)
Rails ができない
データベースの設計ができないからなんだと思う。Rails ってまずはじめにデータベース設計ありき、みたいな雰囲気があって、どうしたらいいかわからない。きっとこの辺が分かれば高速に開発できるのだろうけど、いかんせんデータベースって「レスポンスがいいけど面倒くさい」というイメージがずっとある。
というか実際問題面倒くさい。ロックが効かないシステム (学校の鯖) でやろうとするとデータベース使うって段階で既に躓く。自宅鯖でやるとなると、デーモンが一個動いたりするから、セキュリティ云々で面倒くさい (SQLite を使うのはスタンダードじゃなくて躓く)。セキュリティ云々が面倒くさいとかいう人間に公開サーバーを運用する資格なんてないので、この辺で脱落する。公開できないサービスなんて面白くない。だからといって開発用に鯖を借りる金は出てこない。そこまでモチベーションがあるわけじゃない。
データベースありき。データベース側からやっていくと、そのものの表面的カタチ (インターフェイス) がなかなか見えてこなくてつまらないし、いざインターフェイスを作る段階になると、ロジックで疲れ果てててきとーなモノになってしまう (「よしじゃあ rhtml と CSS 書こうか、でももう一応できてる (scaffold のおかげ) しなぁ、めんどいからいいや」みたいな)。
ユーザーインターフェイスなんて後からどうにでもなる、わけない。最初に作ったイメージはあとあとまで引き継がれてしまう。最初のできが悪いと、ずっと悪いまま。すごく優秀な「別の」人が関わらない限り、それは直らない。(自分としてはこういう新しい視点を提供してくれる頭のいい女の子に憧れる。関係ない)
CSS 書くときと、プログラムのロジックを書くときの脳みその状態が全然違う。切り替えるのが面倒くさい。先に見た目を作ると、あとで「あーこれが本当に動いたらなぁ」なんて気分になってロジック書く気になるけど、逆だとならない。
根本的に何か勘違いしている可能性がありまくるけど、現状だといまいちやる気にならない。今作りたいものはあるけど、データベース設計で既に躓いている (だいたいテーブルの数が5個ぐらい)。だからとりあえず UI だけ作ろうかと思った。そのうち。いつか。
スローライフしたい。
throw :life #=> ThreadError : "uncaught throw `life' in thread 0x854b6a8"
スローライフの意味がやっとわかった。@IRC by mayuki さん
カリー化をふと理解した?
いろんなところでカリー化と普通に言われて、カリー化って何だよって思っていたけど、ふとした拍子に理解した (と思う)
引数を一個とって関数を返す関数をカリー化された関数というらしい。なんか言葉にするとそこらの説明と大して変わらないなぁ。
檜山正幸のキマイラ飼育記 - JavaScriptでカリー化 の最初に「カリー化ってなに？」って書いてあるけど、今はこれが一番わかりやすい例だと思える。前読んだときはよくわからなかった。2引数の関数f(x, y)に対して、「gがfのカリー化」だとは、f(x, y) = g(x)(y) が常に成立すること
。ちなみに「なに？」の部分以外はわからない (読んでもいない)
- すーぱーぷろぐらみんてくにーーく！ のカリーの部分
- A Gentle Introduction to Haskell: Functions
- 404 Blog Not Found:Haskellは難しくない--こともある。
モナドもわからない。ほっといてもそのうち分かるんだろうな