日記
生牡蠣で腹壊した
■
id:oooquree さんアツいですね。
村上隆がどうのこうの
彼の作品に価値があるかどうかは僕にはよく分かりませんが、 MDIS という会社があって、この会社は全く価値の無いシステムを高値で全国の図書館に売り付けることに成功しています。価値があるかどうかよく分からないものを弁舌と商才によって売り捌くというのは全くよくある話で、その能力なり手筈なりを参考にすればよい話であって、彼を叩いて意味があるとは思えない。だってレア・ケースではなくて、一般的なケースなんだもん。
サブアカの発言全部消した
while true begin c = OAuth::Consumer.new("fugafugafugafuga","hogehogehoge", {:site => "http://twitter.com"}) t = OAuth::AccessToken.new(c, TOKEN, SECRET) JSON.parse(t.get("/statuses/user_timeline.json?count=200").body).each do |p| puts "#{p["id"]}: #{p["text"]}" p t.post("/statuses/destroy/#{p["id"]}.json") rescue nil end sleep 60 rescue sleep 20 end end
こんなの。 /statuses/destroy は API 制限の適用対象外なので /statuses/user_timeline のところのみウエイトをかければよい。並列アクセスなどもしていないので警察に逮捕される可能性も少ないでしょう。
ところで周知の通り twitter の /statuses/user_timeline はその人の最新発言 3200 件までしか取ることが出来ない。じゃあその 3200 件を消しきってしまうとどうなるかというと、 API でも Web でもその人の発言が一切取得できなくなります。発言件数だけ取得できるけど、出てこない。ちなみに status id を指定して直叩きすれば取れる。
推測ですが、 status id を指定した場合はプライマリーキーで検索すればいいだけなので MySQL から取ってきてもコストが低いのでそうしているが、一覧はコストが高いので、一覧を作成してそれをキャッシュサーバーに載せて、一覧はキャッシュからの取得のみとしているのではないでしょうか。それが一覧取得 3200 件制限の理由。
3200 件全部消しきった後ある程度待つと、それより古い発言がまたポツポツと取得出来るようになります。なので上記スクリプトを回しっぱなしにしているといつか発言が全部消えます。 6000 件程発言していたサブアカの場合全消去には 5 日間程かかりました。
ブラウザゲーム開発みたいのについて
今年の 4 月から IT エンジニアをやってます。もう 5 ヶ月ぐらい IT エンジニアをやってることになりました。ブラウザゲームの企画とプログラミングをやってます。
Rails でやってます。 RSpec でテストファーストという普通の感じです。僕の開発スタイルで普通と違うのは以下 2 点ぐらい。
まず NDD を採用しています。 NDD については http://ssig33.com/blog/2010-08-05-1.html こちらを御参照ください。かなりストレスの高い開発手法なので気をつけてください。
もう一つですが、Web アプリケーションではデータべースのスキーマーをどう決めるかとかが重要だと思うのですが、個人的な事情(RDBMS スキルが微妙)と仕事上の事情(スケジュールがアレなのでがっちり設計してがっちりスキーマー決めるとか難しい)ので、以下のようなスキーマーを採用しています。
create_table "entities", :force => true do |t| t.string "key", :null => false t.text "body" t.datetime "created_at" t.datetime "updated_at" end add_index "entities", ["key"], :name => "index_entities_on_key", :unique => true create_table "indices", :force => true do |t| t.integer "entity_id" t.string "name" t.integer "sort" t.datetime "created_at" t.datetime "updated_at" end add_index "indices", ["entity_id"], :name => "index_indices_on_entity_id" add_index "indices", ["name", "sort"], :name => "index_indices_on_name_and_sort" add_index "indices", ["name"], :name => "index_indices_on_name"
テーブルは以上二つ。モデルは
class Entity < ActiveRecord::Base has_many :indices def value MessagePack.unpack(self.body) rescue nil end def value= args self.body = args.to_msgpack end end class Index < ActiveRecord::Base belongs_to :entity end
こんな感じ。
e = Entity.create(:key => "fuck", :body => {:unko => "unko"}.to_msgpack) value = e.value value["shit"] = "shit" e.value = value e.save e2 = Entity.create(:key => "kill", :body => {:unko => {:unkooooo => "死"}}.to_msgpack) Index.create(:name => "fucking", :entity_id => e.id, :sort => 1) Index.create(:name => "fucking", :entity_id => e2.id, :sort => 2) Index.find(:all, :conditions => {:name => "fucking"}, :order => "sort desc", :include => :entity)
こんな感じで使う。 Facebook のやつとか Lang-8 の SimpleResource とかを AR だけでやってる感じです。スキーマレスな DB を MySQL 上で実現できます。MySQL しか使ってないからトランザクションも使えます(使ってないけど)。スキーマレスなので思いついたら適当にスキーマを追加出来るし、機能追加などの時もいきなり機能の実装をはじめられます。
オススメ、と言えるやり方なのかどうかは微妙。 Rails の原則には真っ向勝負を挑んでいるわけだし。
コントローラーを厚くするのは微妙なので apps/model 以下にビジネスロジックを実装したコードが散っている。
もうちょっとかっこよくスキーマレス DB を Rails 上で使える方法が欲しい(SimpleResource はテストが難しいので却下)。
ホメオパシー信じて死ぬのと同じだよねこれ。
今敏監督の話。
http://konstone.s-kon.net/modules/notebook/archives/565
忘れもしない今年の5月18日。
武蔵野赤十字病院、循環器科の医師から次のような宣告を受けた。
「膵臓ガン末期、骨の随所に転移あり。余命長くて半年」
なんで僅か 3 ヶ月で死んだのだろうかと思ったらあっさり理由が書いてあった
歩行にも大きく困難を生じ、鍼灸師やカイロプラクティックなどに通っていたのだが
抗ガン剤は拒否し、世間一般とは少々異なる世界観を信じて生きようとした。「普通」を拒否するあたりが私らしくていいような気がした。
ようは現代医療を信じず代替医療を信じたらあっさり死んだというそういう話だった。
創作に携わる人間は普通の感覚では食っていけないというのはもちろん少なからずある。それも程度問題で死ねば創作に携わることはできない。
代替医療カルトがこの世に無ければ今敏監督はもっと長生きしてもっと作品を作ったかもしれない(ガンは普通に治療すればだいたい宣告された余命よりは長生きする)。
代替医療カルトは壊滅すべきというふうに思いました。