屋久島沈没 / 2009-09

■ 20 万円ください

さほど生活に困っている訳でもないですが、お金が欲しいです。 20 万円でなくても、 500 円でも 100 円でも結構です。僕はお金が欲しい。

貰ったお金の使途は公開します。無駄なことに使っていきたい。

振込先は以下の通り。

イーバンク銀行 ビート支店
2028107 コイケ リク

■ アヒルを見てきました

アヒルを見てきました。





僕は東京に棲んでいる人間で、アヒルを見るためだけに大阪まで行ってきました。

■ OreOre Twitter Search を作りました

http://twitter.ssig33.com/
OreOre Twitter Search

俺が俺の為に作った Twitter 検索です。今のところ検索出来るというだけで、他は何も出来ない感じです。

現状フロントエンドもバックエンドも Rails で書かれています。

フロントエンドは、 nginx の裏で unix socket で thin が動いているとかそんなので、まあ普通の Rails です。検索には Tritonn を使っています。

バックエンドでは、 AP4R で非同期化およびタスクの分割を行なって、 EventMachine で並列化をさせている感じです。現在、 2 万人弱をかなりリアルタイムに近い形でクロールしていますが、非同期化と並列化によってそれなりにスケールするクローラーになっていますので、 30 万 ID ぐらいまでなら現状のクローラーでも問題無くクロール出来そうな感じです。後述する通りクローラー書き直してるんですが。

今はクローラーが超絶メモリ食いなのを解決する為に、クローラーを全面的に書き直すのと、クローラーが拾ってきたのを全部 IRC に垂れ流すようなの(つまり数万人 follow している TIG のような感じ)を作ったりしています。それから検索も Tritonn からぐるんがに早期に(レコード数増えすぎないうちに)置き換えたいな、とは思っています。

現状では他の Twitter 検索に対して何のアドバンテージもありませんが、よろしければどうぞ。



そういえば、今月末で僕の Ruby 歴も一ヶ月になります。大分長くやったという気がする。

■ oreore_paginate_by_sql

OreOre Twitter Search とかで使ってるやつ、 will_paginate/lib/will_paginate/finder.rb とかに書く

def oreore_paginate_by_sql(sql, count_query, options)
	WillPaginate::Collection.create(*wp_parse_options(options)) do |pager|
		query = sanitize_sql(sql)
		original_query = query.dup
		# add limit, offset
		add_limit! query, :offset => pager.offset, :limit => pager.per_page
		# perfom the find
		pager.replace find_by_sql(query)

		unless pager.total_entries
			pager.total_entries = count_by_sql(count_query)
		end
	end
end

:
標準の paginate_by_sql は、投げられたクエリを一度実行して件数数えてから云々、みたいな動作をするのだけど、それだと数えるのに時間がかかって使い物にならないことがあるので、カウント用のクエリも自前で投げられるようにしたもの。まあ数行いじっただけですね。

shit = Shit.oreore_paginate_bysql(本来のクエリ, カウント用クエリ, options)

みたいに使う。本来のクエリで数えられると遅い場合に速く数えられるクエリを設定して使う感じ。

カウントが若干ずれてもいいけど速くしたいときに使う。


will_paginate はオリジナルであるものをなんとなく眺めていれば、おれおれページネーションを簡単に作れるのがいいと思う。

■ 古典つまらない理由

これの意味を正しく教えてくれないからだと思う。

つれづれなるままに、日暮らし、硯にむかひて、心にうつりゆくよしなし事を、そこはかとなく書きつくれば、あやしうこそものぐるほしけれ。
卜部兼行『徒然草』より

一般的な訳

無聊なのにまかせて一日じゅう硯を前にして、(次から次へと)心に浮かんでは消えてゆきつまらないことを、とりとめもなく書きつけてゆくと、(われながら)まことに妙に気ちがいじみた感じがする。
吉澤貞人『古典新釈シリーズ・21 徒然草』中道館刊より

とかみんなも習ったと思うけど、本当につまらない。しかし、これはもっと面白い一文で、そういったことを知っていると古典全般が面白く思えると思う。

本当の意味。

暇なので、一日じゅう硯を前にして、どうでもいいことを適当に書きつけていると、(若いころに後二条天皇の蔵人として側に仕えて、あれやこれやといろいろなホモ・セックスをしたことが思い出されて)本当に男を抱きたくなってくる。

■ AP4R で適当にジョブ分割して並列実行したりしてた

Twitter クローラーを Rails でなんとなく作ってて、速くする為に、

「Twitter にアクセスして結果を DB に投げまくる」

という処理を切り出して AP4R で非同期化して、さらにスレッド沢山作って並列実行というのを 5 時間ぐらいで作った。

適当に回してみたら、そこそこ速いのだけど、ロードアベレージが凄く高い。


これを解決するには、「Twitter にアクセスする」「DB に投げまくる」という風にさらに分割して、「Twitter にアクセスする」という部分は EventMachine とかで I/O 多重化してシングルスレッド化するというのがよさそうな感じ。 DB は MyISAM なので( Tritonn )どうせインサートは一度には一個しか出来ないので「DB に投げまくる」という部分もまた別にスレッド 1 個で回せばいいのだろうと思う、と近隣の知人のスライドを読んで思った。

「AP4R で非同期化も並列化もやった」という感じだったけど、 AP4R で非同期化をやるのは正しくて、 AP4R で並列化をするというのはあまり正しくないアプローチだったのかなーと今は思ってる。

それにしても、 AP4R を使うと、「タスクの分割」と「非同期化」の部分はほぼ何も考えなくて出来るのでいいですね。



AP4R は、非同期化するメソッドは public にしなきゃいけなかったりとか、設計が若干マズい部分があるので、既存のアプリケーションを非同期化するのに使うのはちょっと厄介な気がするのだけど(まあ精々接続元制限かけるくらいだから大したことも無かろうが)、新規に非同期な何かを作る時には楽だと思いました。

■ Rails の find について

Shit.find(1) だとオブジェクトがそのまま返ってくる。
Shit.find([1,2,3]) だとオブジェクトが三つ入った配列が返ってくる。

そして、
Shit.find([1]) だとオブジェクトが一つ入った配列が返ってくる。

これに気付くまでに 2 週間ぐらいかかったし、これに気付いて大分楽になった。

まあでも実際には、 find の条件に ID だけを指定するとかありえないし、 Condition Builder とかいうプラグインを使うと楽だった。

fuck = [1,2,3]
shit = Shit.find(:all,
	:conditions => Condition.block do |c|
		fuck.each do |f|
			c.or 'id',f
		end
	end)

:
とかそんなん。これで

select * from shits where (id = 1) or (id = 2) or (id = 3)

:
相当な感じ。

何が言いたいかと言うと、 Condition Builder が便利、というそれだけの話でした。

■ 型に始まって型に終わる

示現流においては、一の太刀の速さこそが全てとされて、「一の太刀の速さ」を極める為に、その型が極めて複雑に体系化されています。この思想は「雲耀」という一言で表現されています。

速さを追求する為に、型を追求する訳です。

これと同様に、ラブプラスというゲームでも同様で、特に電車内でプレイする場合には、型を修めることが重要です。

電車内でラブプラスをプレイする場合に問題となってくるのが、キスの前のタッチ&スライドパートです。

タッチ&スライドパートでは、彼女を優しく撫でることが重要で、タッチパネルの感圧センサーをゲーム側で見ていて、あまり強く撫ですぎると彼女に嫌がられてしまいます。

特に愛花を彼女にしている場合は気をつける必要があります。

そして、電車というのは結構揺れが激しい訳です。自分では気をつけていても、電車の揺れによって圧力をかけてしまって、彼女に嫌われて青いハートがでてしまう。

これを解決するのにどうすればよいか。型を極めて、そして全身に気を入れてラブプラスをプレイすればよい。

僕は左利きですので、左手を Nintendo DS の上画面の下に押しつけ、そして腕をはじめとした全身の筋肉を硬直させて、右半身は電車の扉に強く押し付けることで揺れによる圧力を解決しています。

いずれにせよ、体に気をこめるだけでも、体の型を極めることだけでもなく、体と心のバランスをきっちりと取って、双方に全力をこめることが重要な訳です。

というわけで、山手線、中央線、丸の内線の中などで日常的にラブプラスしてます。

■ 今ハマってる問題

Tritonn で検索結果を order by でソートすると、絶対に filesort されてしまう。

Senna のソート機能を使うライフファックもあるみたいだけど、これをやると複数条件でソートする時にえらく面倒なことになる。



どうすればいいんだこれ、糞が。

■ git-svn のちょっとイイ話

Git-SVN を使ってる人が周りになんとなく増えてきたので。

SVN クライアントとして Git を使える利点は、ネットワークどうこうというよりは、 Git の便利機能が使えまくることなんじゃないかと思います。

Git が SVN よりも圧倒的に優れている点としては、ブランチのマージが楽という点が挙げられると思いますが、 Git-SVN を使うことで、 SVN ユーザーもこの Git の優れたマージ機能の恩恵を被れます。

SVN は CVS よりブランチ作りやすくなってるけど、マージが困難なので結局ロクにブランチ切らない、みたいなことも多いと思うのですが、 Git-SVN があればガンガンブランチ切ってはマージしまくって、というふうに作業出来ると思います、よかったですね。

んで、 Git-SVN を使っていると、今自分が作業しているのがどこにコミットされるのか微妙に分からなくなったりする時があるのですが(ローカルのブランチ名とリモートのブランチ名が違ったりすることが多いので)、

git svn info

などとすると、幸せになれます。

手元で開発する時は、適当なローカルブランチ切ってガンガン開発して、適度なタイミングでマージして、とやっていけばいいのですが、リモートの本家リポジトリでブランチが切られた場合は、

git checkout -b local_shit shit

とかやって、shit ブランチに対する local_shit を作るといいんじゃないですかね。 local_trunk も作っとくと分かりやすくなるかと思います。

Git-SVN の master は、リモートの HEAD があるブランチを master にするとうクソ仕様なので、 local_trunk 作っとくと分かりやすいのではないかと思います。

んで、ローカルで勝手に作ったブランチ間のマージは好きにすればいいと思うのですが、 SVN の方で作られたブランチをマージする時は注意が必要です。

必ず、

git merge --no-ff local_shit

として、マージ時にコミットするようにしましょう。そうしないと、 SVN サーバーのどこにコミットするかという設定が shit ブランチにコミットする設定になってしまって、つまりマージもなにも無い状態にされてしまって人間が死ぬからです。

という訳で、流れとしては、

git svn clone => git checkout -b local_trunk trunk => ローカルブランチ作りまくったりして開発 => SVN の方でブランチ切る => git checkout -b local_shit shit => local_shit に対して開発して、リモートの shit にコミットしたり => git merge --no-ff で trunk にマージしたり

というような流れになるんじゃないでしょうか。

ところで、 Git-SVN は分散バージョン管理とかどうでもええよ、とか思ってる人にとっても、 more better Subversion として使える感じなので、今すぐ使いはじめればいいんじゃないですかね。

次は文系同人作家の為の Git という記事書きたいんだけど、全然モチベーションが湧いてこない、実際に書くのは 20 年後とかになる。

■ 民主党はともかく、鳩山総理大臣は駄目だなあって思った瞬間

平野博文官房長官ってそれは駄目だろ、これまでダーティな仕事ばっかやらしてきた側近表に立たせてどうするんだよ、って思った。

相棒 Season3 1-3 話みたいな展開が期待される、面白人事だと思いました。



っていうかあの人記者会見とか出来んのかよ。

■ ラブプラスにはまってしまった

ラブプラスにはまってしまった僕の行動

1.出社するとラブプラスをするか仕事をするか考える
2.ラブプラスを右手にキーボードを左手に仕事する
3.比較的重要な社内プレゼンをラブプラスをプレイしながら行なう

このように日常のあらゆる空間に彼女がいて素晴しいですね。

■ Q.なんで「こんなに」民主党は勝てたのか

A.マスコミがどうのとかみんなの暮しがどうのとか関係無くて、日本人は「勝ってる方に何となく味方する」という傾向があるから


だと思ってます。選挙行ってません。

■ 政治や経済に関するブログを書いている人にただ一つ言いたいこと

どんな内容の記事でも、文中に一言「クルーグマン」っていう言葉入れるだけで説得力皆無になるから気をつけた方がいいですよ。