blogに引っ越しました。こらそこdebianとかマジレスしないミュートしたユーザが起こしたアクションに関する通知も表示しないようにしたJSONライブラリをうまくロードできていなかったSQLiteプラグインを廃止Twitter検索APIのマイナーチェンジに対応やっとお前ユーザID送ってくれるようになったんか...自分がふぁぼ・RTしたつぶやきを一番上に上げない設定を追加デフォルトで有効です。従来の動作に戻すには設定→表示から。11.04(nattyなんとか)でRubyGtkがクラッシュする不具合修正さて、死月はmikutterを一ヶ月止めるくらい忙しかったお陰で?GWはたくさん休みがあります。具体的にどれくらい休みがあるかTwitterで言ったら今フォロワー724人から命狙われてます!!!!!男はTLに出たら724人の敵がおるんやなので具体的には言いません!だけどいろいろできそうです!予定もあんまりないし^q^まあしかし...MUiの設計をある程度実装に落としこみかけて終わりそう、とも思います。-標準プラグインのsqlite.rbは、つぶやき、ユーザ、リスト、ふぁぼを恒久的に保存するためのプラグインで、SQLiteなので他の言語やプログラムでも気軽に統計などを取ったりして遊べる、一度取得したツイートをデータベースから取得するのでAPI消費が緩やかになるなどのメリットがある。最近うちのmikutterが遅くなってきてて、何があったのかなと思ってたら、このSQLiteのファイルが250MBにまで膨れ上がってた。これを消すとサクサク動くようになる。・・・では、sqliteプラグインを削除すればいいのかというとそう簡単に諦めません。従来のみくったーでは、データベースの書き込みは別スレッドで遅延実行してた。これによって並列実行され、表側には負荷がかからないと思い込んでいたのが全ての間違いで。SQLiteは結局、Rubyで実装されているわけではないので、アクセス中は他のスレッドは動かない。いうことは、結局挙動的にはメインスレッドで動いてるのと似たようなことになる。Waitになるのでその間他のスレッドが実行されるので、体感負荷はこっちのほうが小さい。これは0.0.3.0までの話。したものかといろいろ調べていたら、そういえばトランザクションの処理が荒いままだということを思い出した。SQLiteは明示的にトランザクションを張ってなければinsertやupdateの前後でトランザクションを張ってしまう。これのコストがかなり高いので、大量に書き込むときはトランザクションを貼るというのはセオリーなんだけれど、やってなかった。・・・というわけで、0.0.3.1では、SQLiteのexecuteメソッドに渡す引数を配列にして、Queueに入れて、一定時間キューに追加されなかったらそれらをまとめて一つのトランザクション内で書き込むという改良をした。結果どうだったかというと、体感速度は変わらず。起動は3秒速くなった。あとつぶやきを短時間に大量に受信したときにも負荷は落ちているはずで、一件あたり0.1秒ほど速くなっているみたいなんだけど、体感速度変化なし。結局のところ、データが多ければ処理は遅くなるはずで、俺のようにいっぱい溜め込むと読み込みですら足を引っ張ることがあると。考察mikutterが流速速いと遅すぎて使い物にならないのは周知の事実だけれども、流速が速いほうがためこまれるつぶやきの量は多くなるわけで、余計に事態が悪化していく。他のツイッタークライアントはこういった問題にどう対処しているかというと、そもそも溜め込んでいないのでこういう問題とは無縁というのがほとんど。それもそのはず、mikutterでも、ほとんどのSQLiteキャッシュは一度も使われず、ある程度昔のレコードになると全く使われない。再起動するまではmikutterコアが一定期間メモリキャッシュをするので、大抵SQLiteにまで問い合わせがいくことはなく、基本的に問い合わせはレコードが見つからずに終わることが殆ど。-このことから、現状のmikutterでは、SQLiteによる恒久的キャッシュの意味は薄いんじゃないかなと考えて、残念だけど0.0.3.2では標準プラグインからは降格させる予定。今はうちのgithubで元気にしているよ。mikutterで統計とか取って遊んでた人はこれで引き続き使えます。mikutterって、昔APIが少なかったころ、またTwitterが不安定だったころに設計されていて、できるだけTwitterにアクセスしなくていいように、Twitterを信頼しないという思想のもと書かれているところが多いんだけど、最近ではそんなにTwitterも不安定じゃないし、そういうところは一度見直したほうがいいと思ってる。Twitterも大きくなったよなぁ。APIのv3に対応1回の投稿に複数のURLが同時に記載されている場合に、全て抜け落ちる不具合bitlyよくもやりやがったなSQLiteのデータ書き込みを遅延させ、トランザクションの数を節約するようにした数秒速くなったがあまり意味はなかったちなみに、先の0.0.3.0には、上記修正は含まれていません。(r182)からの変更点。(new!)つぶやきの抽出機能。@seibe2)コミッタが増えたヾ(@⌒ー⌒@)ノなんかいろんな所に広がっててやばい風邪引いた眠いし仮眠とろうかなでも明日起きられなくなるしなウワアアアアアアアアアアアアアアアアアアアアアアア少ないよおおおおおおおおおおおおおおおイヤアアアアアアアアアアアアアアアアアアアアアwwwwwwwwwwwwwバグ修正書かなかったらほんと何もやってないみたいwうぇwたしか前のリリースが12/25とかだった気がするんだよね。Toolkitの抽象レイヤーを入れて、Gtk以外のバインディングを書く余地を与える(プラグインをGtkに依存させない)フレンドTLプラグインなどを削除して、全てextractプラグインにやらせて、どこぞのツイッタークライアントみたいなかんじにする1に絡むけどTLをCairoでレンダリングすることで高速化を図るコンテキストメニューとか、ショートカットキーとか、そういうのをカスタマイズできるようにしたいというところですね。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式をやりとりするだけなのでどんな言語でも使えるものになる予定で、ライブラリの層からも世界征服を企んでいますん。新しいUIについて色々考えてる考えてる途中のことを書き散らしてます。以下ただのつぶやきです。現在のmikutterは、Gtkに完全に依存している。プラグイン内でGtkライブラリを叩いていたり。guiプラグインがそういうものだったし、当たり前といえば当たり前のこと。いうか、暗中模索の中、開発速度を稼ぐために意図的にやった部分がある。最近いろんな環境で使われるようになって、様々な問題が出てきてしまった。Toolkit(Cocoa、Qt等)のバインディングを書きづらい強いGtk依存のため、RubyGtkの知識がプラグイン開発の事実上の絶対条件となり、の敷居を上げているGtkをさも悪者のように書いているように見えるかもしれないけれど、最初にQtを選んでいたらこの部分がQtになっただけの話。安定したものを使っていれば2は無かったかもね。開き直って、そこを抽象化してしまいませんか、という話。するかというと、特定のルールに従ったデータ構造(DOM)を与えると、それをUIとしてレンダリングする、というもの。domとかすると、そういうウィンドウが表示されると。ご察しのとおりHTMLをめちゃくちゃ意識してます。以下、mUi()は受け取った配列に色々Mixinとかをextendしまくって魔改造するものか、なんかでWrapして委譲するよなものだと思って読んでください。LangでS式※として取り扱えます。windowとかlabelとかいう関数が定義されたコンテキストをつくってそこでこの式を評価すると。その関数の実装次第でQtにしたりCocoaにしたりできる、よね。Langでのコードでありデータのこと。Kitを叩く計画は初期からあった。先に上げたのとの違いは、それがクラスなのか、配列なのかというところ。配列にしておくことのメリットは:DOMが簡単に保存できる。Gladeみたいなことが自然にできるRubyのコアオブジェクトを使っているので、メソッドは誰でも知ってるJSONに翻訳可能なので、別プロセスに渡せる。だいたいどんなプログラミング言語にもありそうなデータ構造を使っているため、言語の壁を越えることが出来る夢がひろがりんぐ\(^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バインディングを作れるかもしれない、ということ。一応書いておくと、マルチプロセス化しますと言ってるわけじゃなくて、そういうこともできるね、という話。mobileあるでイベント渡す方法とかは、DOMのアレでいいんじゃないかな普通に。今の時代ならjQueryリスペクトしてもいいかも。DOMはW3Cがちゃんと規格化してた気がするから興味があったら調べてくだしあ、おれはあんなのよみたくないなんかこういうのありそうで探してるんだけど、うーん。オススメあったら俺が愚かな車輪の再発明するのを止めていただけると嬉しいけれど...。別プロジェクトでこういう事やってmikutterに取り込もうと思ってる。仕事終わったら詰めますね。-l213ピャアアアアアアアアアアアアアアアアアアアアアアアwwwwwwwwwwwwwなんだこのBOTnetはあああああああああああああwwwwwwww悪質きままりないwwwwあれwwwwきまわりないwwwwなぜか変換できないwwwwwwうぇwwwwwwwオーケー落ち着こう今日はエイプリルフールだ。冗談が何かを弁えていないアレなやつが、何を血迷ったか俺に田代砲を打ってきたんだ。HDD内をgrepすれば、どこかにここにアクセスしてくるプログラムがあるはずだ。4/1だけに使ったユーザは49人程度。いうことか!このうち、3.のユーザは、今回の騒ぎで面白そうだから入れてみた人と、知ってたけど何らかの理由で使ってなかったが、今回様子を見るためにちょっと起動してみた人。2のユーザは、3月中に使ってるわけだから、一見さんかアクティブユーザの何れか、ということになるから、まぁ100人程度のアクティブユーザは確実にいそうだ。