mikutterの最新の情報は、mikutter blogに引っ越しました。

2011年4月30日土曜日

#mikutter 0.0.3.2

ubuntu nattyリリースおめでとうございます!ありふれた操作でセグフォする化石みたいな古いRubyGtkを同梱しているnattyちゃんに祝福のつばを吐きかけましょう!!!!!1234ubuntuのリポジトリはRubyGtkの博物館d
(#^ω^)「ubuntuの関係者のものですが」
ヽ('ω')ノ「いやあああああああああごめんなさいいいいいいいいいい^p^」
# こらそこdebianとかマジレスしない
  • ミュートしたユーザが起こしたアクションに関する通知も表示しないようにした
  • JSONライブラリをうまくロードできていなかった
  • SQLiteプラグインを廃止
  • Twitter検索APIのマイナーチェンジに対応
    • やっとお前ユーザID送ってくれるようになったんか…
  • 自分がふぁぼ・RTしたつぶやきを一番上に上げない設定を追加
    • デフォルトで有効です。従来の動作に戻すには設定→表示から。
  • ubuntu 11.04(nattyなんとか)でRubyGtkがクラッシュする不具合修正
さて、死月はmikutterを一ヶ月止めるくらい忙しかったお陰で?GWはたくさん休みがあります。具体的にどれくらい休みがあるかTwitterで言ったら今フォロワー724人から命狙われてます!!!!!
男はTLに出たら724人の敵がおるんや
なので具体的には言いません!だけどいろいろできそうです!予定もあんまりないし^q^
まあしかし…MUiの設計をある程度実装に落としこみかけて終わりそう、とも思います。ともあれ纏まった時間がとれるので、いろいろやりたいね

2011年4月29日金曜日

SQLiteプラグインの消失 - DEAD END -

標準プラグインのsqlite.rbは、つぶやき、ユーザ、リスト、ふぁぼを恒久的に保存するためのプラグインで、SQLiteなので他の言語やプログラムでも気軽に統計などを取ったりして遊べる、一度取得したツイートをデータベースから取得するのでAPI消費が緩やかになるなどのメリットがある。

最近うちのmikutterが遅くなってきてて、何があったのかなと思ってたら、このSQLiteのファイルが250MBにまで膨れ上がってた。当然これを消すとサクサク動くようになる。

SQLiteプラグインの最適化

・・・では、sqliteプラグインを削除すればいいのかというとそう簡単に諦めません。
従来のみくったーでは、データベースの書き込みは別スレッドで遅延実行してた。これによって並列実行され、表側には負荷がかからないと思い込んでいたのが全ての間違いで。SQLiteは結局、Rubyで実装されているわけではないので、アクセス中は他のスレッドは動かない。ということは、結局挙動的にはメインスレッドで動いてるのと似たようなことになる。一方TwitterAPIで問い合わせに行くと、IO Waitになるのでその間他のスレッドが実行されるので、体感負荷はこっちのほうが小さい。これは0.0.3.0までの話。

どうしたものかといろいろ調べていたら、そういえばトランザクションの処理が荒いままだということを思い出した。
SQLiteは明示的にトランザクションを張ってなければinsertやupdateの前後でトランザクションを張ってしまう。そしてこれのコストがかなり高いので、大量に書き込むときはトランザクションを貼るというのはセオリーなんだけれど、やってなかった。
・・・というわけで、0.0.3.1では、SQLiteのexecuteメソッドに渡す引数を配列にして、Queueに入れて、一定時間キューに追加されなかったらそれらをまとめて一つのトランザクション内で書き込むという改良をした。

最適化の結果

結果どうだったかというと、体感速度は変わらず。ただし起動は3秒速くなった。あとつぶやきを短時間に大量に受信したときにも負荷は落ちているはずで、一件あたり0.1秒ほど速くなっているみたいなんだけど、体感速度変化なし。
結局のところ、データが多ければ処理は遅くなるはずで、俺のようにいっぱい溜め込むと読み込みですら足を引っ張ることがあると。

考察

mikutterが流速速いと遅すぎて使い物にならないのは周知の事実だけれども、流速が速いほうがためこまれるつぶやきの量は多くなるわけで、余計に事態が悪化していく。では、他のツイッタークライアントはこういった問題にどう対処しているかというと、そもそも溜め込んでいないのでこういう問題とは無縁というのがほとんど。
それもそのはず、mikutterでも、ほとんどのSQLiteキャッシュは一度も使われず、ある程度昔のレコードになると全く使われない。
更に、再起動するまではmikutterコアが一定期間メモリキャッシュをするので、大抵SQLiteにまで問い合わせがいくことはなく、基本的に問い合わせはレコードが見つからずに終わることが殆ど。

SQLiteプラグインの消失 - DEAD END -

このことから、現状のmikutterでは、SQLiteによる恒久的キャッシュの意味は薄いんじゃないかなと考えて、残念だけど0.0.3.2では標準プラグインからは降格させる予定。今はうちのgithubで元気にしているよ。mikutterで統計とか取って遊んでた人はこれで引き続き使えます。

mikutterって、昔APIが少なかったころ、またTwitterが不安定だったころに設計されていて、できるだけTwitterにアクセスしなくていいように、Twitterを信頼しないという思想のもと書かれているところが多いんだけど、最近ではそんなにTwitterも不安定じゃないし、そういうところは一度見直したほうがいいと思ってる。Twitterも大きくなったよなぁ。

2011年4月23日土曜日

#mikutter 0.0.3.1

今週はこれ!!

  • RubyのライブラリやRuby本体が原因でクラッシュした後の起動でバグレポートを送ろうとするとお礼を言われないどころか発狂されるバグを修正
  • bit.ly APIのv3に対応
  • 1回の投稿に複数のURLが同時に記載されている場合に、全て抜け落ちる不具合
    • bitlyよくもやりやがったな
  • SQLiteのデータ書き込みを遅延させ、トランザクションの数を節約するようにした
    • 数秒速くなったがあまり意味はなかった
ちなみに、先の0.0.3.0には、上記修正は含まれていません。
GWはMUiに舵を切って、mikutterの高速化のためにがんばるかな…

#mikutter 0.0.3.0

不安定版リリース!!!おめでとう!!!!!
えっじゃあ四桁目はなんなのかって?ウィークリーリリースだよなめんな!あれは動けばラッキーの毎週とりあえずtarに固めてるヤツです!!!もっというとやってますよっていうアピールです!!!!!それが安定していると、こうやって桁が上がるんです!どんなに重くてもな!!!つまり中身は0.0.2.13と同じだ!!!!11

これが0.0.2.0 (r182)からの変更点。繰り返しになるけど。

  • mikutterコア
    • フィルタの呼び出しの大幅な高速化
    • 公式RT、ふぁぼられの通知の仕方を細かく設定できるようにした
  • プラグイン
    • 各種タイムライン
      • つぶやきを表示するかどうかを判断するフィルタ
    • notify
      • 被公式リツイートの通知
    • profile
      • ユーザのミュート機能
    • gui
      • ふぁぼられた時の負荷低減
    • extract (new!)
      • つぶやきの抽出機能。いわゆるエゴサーチタブが作れる
  • その他
    • mikutterのアイコンが完成しました (thanks @soramame_bscl)
    • ruby 1.9.1 及び 1.9.2 に対応。見たところ3倍速程度で動きます
    • 新たにリツイートなどの通知音を追加
    • 効果音の提供を受けた (thanks @seibe2)
    • コミッタが増えたヾ(@⌒ー⌒@)ノ
    • なんかいろんな所に広がっててやばい
    • 風邪引いた
    • 眠いし仮眠とろうかな
    • でも明日起きられなくなるしな
ウワアアアアアアアアアアアアアアアアアアアアアアア少ないよおおおおおおおおおおおおおおおイヤアアアアアアアアアアアアアアアアアアアアアwwwwwwwwwwwww
バグ修正書かなかったらほんと何もやってないみたいwうぇwたしか前のリリースが12/25とかだった気がするんだよね。てかさっき気づいたけど各tar玉にリリース日併記しとけよ俺マジ糞システムだな
さて1年の1/3もの期間を使って何をしたかというとですね 直ちに人体に影響のないものを片付けたりしてたんですよ、ええ

今後の展望としては
  1. GUI Toolkitの抽象レイヤーを入れて、Gtk以外のバインディングを書く余地を与える(プラグインをGtkに依存させない)
  2. フレンドTLプラグインなどを削除して、全てextractプラグインにやらせて、どこぞのツイッタークライアントみたいなかんじにする
  3. 1に絡むけどTLをCairoでレンダリングすることで高速化を図る
  4. コンテキストメニューとか、ショートカットキーとか、そういうのをカスタマイズできるようにしたい
というところですね。ちょっと見た目もいらえば華々しい変更に見えるかな

2011年4月17日日曜日

#mikutter 0.0.2.13

いえーい!!!


  • ruby1.9.2に対応
  • (notify)自分のつぶやきが公式リツイートされた時の通知に対応
    • リプライと公式リツイートと混同されていたが、区別するようにした
白い!白いよ!書くことがな^p^い

ちょっと間が空きすぎてエラー報告が全然目を通せる数じゃなかったので今回は普通にウィークリーリリース(苦笑)して安定してたら0.0.3いくよ。セグフォはバグじゃないよ。

あと使う分には関係ないけど、今回からエラー報告プラグインが、エラー箇所を明示的に送るようになって、こっちの統計が取りやすくなりました!!!やったこれでいくら報告来ても大丈夫だ!バグ入れ放題!!!

0.0.2.12リリース後から仕事しかしてなくて更新できなかった!本当に仕事しかしてなかったよポケモンもしなかったしうんこもしなかっただからここのところ腹具合がうわあああTwitterはするものじゃなくて住むものなので居ました。3/20からだからなんと一ヶ月!!!死ぬかと思った!!!んでもう終わったからリリース…と思ったら今日になって変更がきてるぞどうしてこうなったwwwwwwもうやだwwwwwwボクをTwitterで見かけたらふぁぼ以外の手段で慰めてください^q^p^q^p^q^p^q^p^q^p^

なんか、gentooのパッケージに取り込まれたり色々大変なことになってるね、そのせいかユーザが増えたような気がするよよかったねみく。エイプリルフールも影響があったように見える。どうしようこんなものがw広がっていくwww

はぁ

ここのところGUIが糞重いみたいなこと言われてるけどお前フォロー何百人いるんだよwww200人?そりゃだめだww俺?600wwうはwwwなんぞwwwってことになってるからちょっとそろそろ高速化しておかないとカスだと思われるし、フォロワー多い人も去年と比べると増えているのでマルチプロセス化してCairoでTLをレンダリングするという暴挙に出ようと思います。それができたら0.1です!おらに力を分けてくれえええヽ('ω')ノ

muiという新しいサブプロジェクトを立ち上げました。これはGUIをDOMっぽく扱うためのGUIラッパです。S式をやりとりするだけなのでどんな言語でも使えるものになる予定で、ライブラリの層からも世界征服を企んでいますん。やりすぎかな。ちょっとまだパッチ投げてもらったりできるほどになっていないのでまあもうしばらくしたらおらに力を分けてくれえええ

2011年4月4日月曜日

新しいUIについて色々考えてる

考えてる途中のことを書き散らしてます。以下ただのつぶやきです。
現在のmikutterは、Gtkに完全に依存している。
例えばプラグイン内でGtkライブラリを叩いていたり。

もともと、guiプラグインがそういうものだったし、当たり前といえば当たり前のこと。というか、暗中模索の中、開発速度を稼ぐために意図的にやった部分がある。
ただ、最近いろんな環境で使われるようになって、様々な問題が出てきてしまった。

  1. Gtkが事実上使えない・使用に難がある環境(Mac OS、各種スマートフォン)では、mikutterが使えない
  2. あるRubyGtkやRubyのバージョンの組み合わせでは、それらのバグを踏んでSegmentation Faultになることがしょっちゅうあるらしく、作者自信が自虐ネタでふぁぼを稼ぐ深刻な事態へと発展している
  3. Gtkに強く依存しているために他のGUI Toolkit(Cocoa、Qt等)のバインディングを書きづらい
  4. 強いGtk依存のため、RubyGtkの知識がプラグイン開発の事実上の絶対条件となり、の敷居を上げている
Gtkをさも悪者のように書いているように見えるかもしれないけれど、最初にQtを選んでいたらこの部分がQtになっただけの話。安定したものを使っていれば2は無かったかもね。

で、じゃあいっそかなり開き直って、そこを抽象化してしまいませんか、という話。

どうするかというと、特定のルールに従ったデータ構造(DOM)を与えると、それをUIとしてレンダリングする、というもの。
例。
dom = [:vbox, [:label "hello"], [:button, {:id => :btn1}, "exit"] ]


とまあ、こういうありきたりなRubyのオブジェクトを

mui = mUi([:window, {:width => 320, :height => 240, :id => :main}])
mui << dom

とかすると、そういうウィンドウが表示されると。ご察しのとおりHTMLをめちゃくちゃ意識してます。
以下、mUi()は受け取った配列に色々Mixinとかをextendしまくって魔改造するものか、なんかでWrapして委譲するよなものだと思って読んでください。

Rubyの配列は、MIKU LangでS式として取り扱えます。つまり、windowとかlabelとかいう関数が定義されたコンテキストをつくってそこでこの式を評価すると。その関数の実装次第でQtにしたりCocoaにしたりできる、よね。
 MIKU Langでのコードでありデータのこと。ただの配列が実行出来るんだよ(Lisp)

実は、MUIというクラスを定義して、それの中身で別々のGUI Tool Kitを叩く計画は初期からあった。けどもういいや。先に上げたのとの違いは、それがクラスなのか、配列なのかというところ。配列にしておくことのメリットは:

  1. DOMが簡単に保存できる。なので、Gladeみたいなことが自然にできる
  2. Rubyのコアオブジェクトを使っているので、メソッドは誰でも知ってる
  3. JSONに翻訳可能なので、別プロセスに渡せる。
  4. だいたいどんなプログラミング言語にもありそうなデータ構造を使っているため、言語の壁を越えることが出来る
夢がひろがりんぐ\(^o^)/

1については、UI関連のコードがソースコードと分離できるので便利だと思う。そしてその形式はJSONとかYAMLとか、慣れ親しんだものでいける。

2については、例えば要素を追加したい時に、さてこのMUIオブジェクトにはaddか、appendか、何が実装されているのかな…おお、DOM意識してappendChildだったか…。みたいな時間が節約できる。
例の仮想コードの、「<<」にどん引きした人がいるかもしれないけれど、これはRubyユーザなら誰でも配列の末尾に値を追加するアレだということは知っている。+じゃだめですよ、あれは非破壊的だから。


3からはちょっとぶっ飛んでて、できたらいいなみたいな。Rubyでは現在完全なマルチスレッドは出来ない。RubyのThreadクラスは、実は時系列で切り替わってるだけなので、本当に同時に複数スレッドが動くわけじゃない。Ruby2.0ではそのあたりの事情が変わるらしいけれど、今でもプロセスを分けてしまえば並列に動かすことは出来る。Chromeとかあえてそうしてるしね。
プロセス間通信には、JSONが使える。S式が使いたかったんだけど、S式でHash表現するような魔改造すると、気軽に他のLispパーサでパースできなくなるので見送った。
つまり、mUiで魔改造されたオブジェクトは、変更が加えられると別のプロセスにそれを報告してレンダリングさせるようにも出来るよね、ということ。
ちょっとChromeって書いたけど、同じ利点と欠点をはらんでるね。例えばGtkがクラッシュしてもコアプロセスからmUiのプロセスを再起動してやればいいだけ。でもメモリ食いがち。

4についてはその応用で、向こうのプロセスがJSONを受け取ってそれをレンダリングしてくれるならば、Rubyで書かれてようが、Pythonで書かれてようが、JavaScript(!)で書かれてようが関係ないじゃない、という話。これが出来るということは、Rubyが使えない人でも、mikutterの別のUIバインディングを作れるかもしれない、ということ。

一応書いておくと、マルチプロセス化しますと言ってるわけじゃなくて、そういうこともできるね、という話。でも結構やる気。mikutter mobileあるで


イベント渡す方法とかは、DOMのアレでいいんじゃないかな普通に


mui.getElementById(:btn1).addEventListener(:click){ exit }

アツいなこれは。今の時代ならjQueryリスペクトしてもいいかも。DOMはW3Cがちゃんと規格化してた気がするから興味があったら調べてくだしあ、おれはあんなのよみたくない

なんかこういうのありそうで探してるんだけど、うーん。オススメあったら俺が愚かな車輪の再発明するのを止めていただけると嬉しいけれど…。

別プロジェクトでこういう事やってmikutterに取り込もうと思ってる。仕事終わったら詰めますね。

2011年4月1日金曜日

謝罪

やあごきげんようエイプリルフールなのに何もできなくてヽ('ω')ノ三ヽ('ω')ノもうしわけねぇもうしわけねぇ
さてさて、うちのサイト(mikutterではない・あれ存在意義ないし潰そうかな)のアクセス数どれくらいあったかなー?

toshi@lime:/tmp$ wc -l apache.log
16188 apache.log
toshi@lime:/tmp$ grep /img/api/ apache.log | wc -l
14150

ギャアアアアアアアなんじゃこりゃあああ!!! /img/apiとかいう意味の分からないディレクトリに異常にアクセスがあるわー、なんじゃこりゃー!この下png画像256枚が入ってるだけで特に何もないんだけどなー

toshi@lime:/tmp$ ruby -e 'p 16188 - 14150'
2038

おかしいおかしいおかしいwwwwこの比率は間違いなくおかしいwwww
さーてーはー俺が多忙なことにつけ込んで田代砲だなぁ?ふぁぼテロはまあ見逃してやってるがこれはちょっと 度 が す ぎ る ぞ !通報してやるううう!!!おまわりさん!!!!!犯人の人数は

toshi@lime:/tmp$ grep /img/api/ apache.log | awk '{print $1}' | sort | uniq | wc -l
213

ピャアアアアアアアアアアアアアアアアアアアアアアアwwwwwwwwwwwwwなんだこのBOTnetはあああああああああああああwwwwwwwwきままりないwwwwあれwwwwきまわりないwwwwなぜか変換できないwwwwwwうぇwwwwwww

オーケー落ち着こう

今日はエイプリルフールだ。そう、つまり、冗談が何かを弁えていないアレなやつが、何を血迷ったか俺に田代砲を打ってきたんだ。違いない。つまり、4月1日のアクセスがほとんどのはずだ

toshi@lime:/tmp$ grep /img/api/ apache.log | grep '1/Apr/2011' | wc -l
2071

ピャアアアア…あれ?
14150アクセスのうち、4/1は2071件だけ…?

toshi@lime:/tmp$ grep /img/api/ apache.log | grep '1/Apr/2011' | awk '{print $1}' | sort | uniq | wc -l
82
toshi@lime:/tmp$ grep /img/api/ apache.log | grep -v '1/Apr/2011' | awk '{print $1}' | sort | uniq | wc -l
164

およよ!?3月と4/1では丁度倍も3月のほうがユニークビジターが多い…!?(しかも/img/api以下の)

なんじゃあこりゃあああ!!
ログを一つ見てみよう

192.168.0.3 - - [01/Apr/2011:02:24:55 +0900] "GET /img/api/B6.png HTTP/1.1" 200 3181 "-" "Ruby"

なんだUserAgentのRubyって!畜生反撃してやる!

toshi@lime:/tmp$ eternal-force-blizzard 192.168.0.3

ってちょっと待ったぁぁぁぁ!!!!
このマシンのローカルIPじゃねえかwwwwwこれマジでやばいんじゃないかwwwwww乗っ取られてるwwwwww

よーしちょっと落ち着こう

"/img/api" で、HDD内をgrepすれば、どこかにここにアクセスしてくるプログラムがあるはずだ。もはやここまで、年貢の納めどきだぁ!正体を表せ!!!(プライバシー保護のためにディレクトリ名は一部加工したよ!)

seminole% find / -type f -print | xargs grep "/img/api"
*****/mikutter/core/mui/gtk_mumble.rb:        "http://toshia.dip.jp/img/api/#{Digest::MD5.hexdigest(url)[0,2].upcase}.png"
*****/mikutter/core/mui/gtk_mumble.rb:          Gtk::WebIcon.local_path("http://toshia.dip.jp/img/api/#{Digest::MD5.hexdigest(url)[0,2].upcase}.png") }

うおおおおなんだこのmikutterとかいう悪しきアプリケーションは!めちゃくちゃあからさまに書いてるじゃないか!!!!!ヒーーーー!!!!

Rubyならわかるぜ…Redmineで差分を見てやる!!!



にょほおおおおおお!!!!ちゃっかり最近のリビジョンで追加されてる・・・違う!改良されただけだ!アイコンが16種類から256種類に拡張された形跡がある!なになに・・・2010-03-19!?去年もやらかしていただと!?きみたちは最初からボクの手のひらで踊らされていたんだ

どれどれ・・・つまりこのメソッドは
  1. 4/1の間は、俺のサイトの/img/api以下の画像のURLを返す
  2. 3月の間は、呼び出されるたびに(日/100)の確率でフェッチしてローカルにキャッシュを残すことにより、普段から使ってくれているユーザの皆さんにはエイプリルフール期間前にキャッシュを取り終わらせることで、サーバにもユーザにも無理なくエイプリルフールに移行できるように工夫されている
ということかぁ!一体俺のこの日のために何ヶ月もかけていろんな所からライセンスとか若干気にしながらまあ今日だけだ許せとかちょっとそういう部分もあったけど厳選したえ萌ミクアイコンを一体どんなことに使ったかは知らないが許さないぞ!この作者はとんでもないヤツに違いない!つまり今回の件で、IPアドレス基準なので確かなことは言えないけれど
  1. 213人以下の潜在的なmikutterユーザがいる
  2. そのうち、3/1から3/31の間にmikutterを一度でも使ったユーザは164人以下
  3. 更に、4/1だけに使ったユーザは49人程度。
ということか!

このうち、3.のユーザは、今回の騒ぎで面白そうだから入れてみた人と、知ってたけど何らかの理由で使ってなかったが、今回様子を見るためにちょっと起動してみた人。
2のユーザは、3月中に使ってるわけだから、一見さんかアクティブユーザの何れか、ということになるから、まぁ100人程度のアクティブユーザは確実にいそうだ。

去年の今頃のユーザはたった10人前後だったのが、アクティブユーザが10倍以上に膨れ上がっているッ!!こんなアレなTwitterクライアントを使ってくれてみんなありがとう!!これからもがんばるよ!!!

いい話風にまとめちゃいましたわぁ(ドヤ