flying tweet alpha5はメモリ喰らい (バグか？)

自分でも(てか、自分だけ？)alpha5を試しているのだが、クライアントがどうも「メモリ喰らい」の感がある。

一応、クライアント側はnow/friends/mentiosのそれぞれのメッセージを最大200件づつまで持てるようになっていて、余計なメモリ確保をしないようにしているつもりなのだが、動作途中でつくられるオブジェクトの解放がされないのか、どんどんメモリを消費しているようだ。firefoxでしかためしてないけど。

JavaScriptだから動的なメモリ確保は言語任せだし、オブジェクトの参照がなくなればメモリは解放されるはずではあるのだが、どうもそうなってはいないみたい。 どこかで参照が残り続けてるのかもしれない。これは困った。

通常のwebページであれば、継続的に表示されつづけることはないので、多少メモリリークしていてもブラウザを閉じちゃえば完全に解放される。しかし、webアプリケーションとして提供する場合、比較的長時間、そのページ(webアプリ)を開き続け、さらにそのページ内で動的にいろいろ動作するので、メモリリークは深刻な問題だ。

手っ取り早い解決方法は、重くなりはじめるポイントを見つけて、そのタイミングでページをリロードしてしまえばいいのだけど、現在のクライアント実装だとリロードするとそれまで溜め込んでいたメッセージ情報も解放されてしまうので、ユーザインタフェース的にはダメだろう。

解決策として、クライアントの溜め込んだメッセージをサーバ側で保存して、リロード時にそれをクライアントに渡す。という方法を考えたのだが、twitter自身をメッセージのストレージとして使う的な目標もあるので、この方法は本末転倒。

なんかうまい方法を考えないとなぁー。というか、メモリリークをなくさないとな(^^;

flyingtweet alpha5

まだアルファ版ですよ。

機能が決定できないのでいつまでたってもアルファ版です。どこぞの「永遠のベータバージョン」よりひどい状況だなｗ。

で、alpha5。クライアント、サーバとも書き直してみた。

クライアントのほうはalpha2～4まで、timelineはIFRAMEを使って子ページで実行したいたけど、親子間でデータの受け渡しが面倒になってきたので、YUIのタブ機能を使って１つに納めることにした。

もともとはファイルを分離すればコードの見通しがよくなるだろう、という単純な発想からIFRAMEつかってみたのだけど、親子間でいろんなデータの受け渡しをするようになってくると、逆に分離されていることの煩わしさが気になり出して、今回、クライアンのト書き直しでJavaScriptのコードが減ったので、まとめてしまうことにした。

いやぁ、コードのどこからでもデータが参照できるので楽になったよｗ

あと OAuthに対応。対応ってか、完全依存。。。

ログイン後もOAuthのライブラリを使ってtwitter APIを発行するので、APIは完全に依存してしまった。

ただ、これだとtwitter停止時に独自にメッセージ配信をおこなう。という当初の2大目標のうちの１つが出来なくなってるのよねー、、、いや、できなくはないのだけど、サインインをどうするかを決めてないので、結局、このバージョンでは出来てないわけです。

flying tweet側で会員登録するのでは本末転倒だし、なんか安くてうまい方法あればなー。OAuth認証されたら、｢認証済みだよ」cookie設定しておいて、twitter停止時はだけそのcookie参照すればいいかな。twitter停止時だけ利用するなら、そんなに悪利用されることもないだろう。ん？悪用はないよな？　たぶんないよな？なければいいな。。。あったらどうしよう。。。。。。。(T_T)

で、TLは最大200メッセージまで保持できるんだけど、現バージョンは20固定。最大TL数は内部では変数でもっているので単に手抜きで20で固定しちゃっている状態。

timelineのアップデートインターバルなんかもそうなんだけど、ここらへんはクライアント側の設定画面で変更できるようにするつもり。表示や回線負荷は個人の環境に左右されるからね。

サーバ側はベースの考え方に 変更はないんだけど、フォローしていない第3者にreplyメッセージが配信されちゃうって不具合があったので、その対策。これはtwitterのfriends_timelineと同じ動作になるように工夫した。

本当にこれは工夫が必要。

flying tweetは全twitter会員のfollowerリスト持ってるわけじゃないから、だれがだれ宛にメッセージを配信するかの判断をさせるのは結構面倒な処理だった。

それと、サーバへのアクセス方法はweb API化した。twitter絡みのアクセスはほぼtwitter API互換。flying tweetの大本の発想はサーバ側からでたものだったので、クライアントは単にサーバの動きを確認してもらうためのツールでしかない。なのでこのAPIを使ってクライアントをつくってもらえたらうれしいな。という甘い考えが本音ｗ。

てなわけで、alpha5は大幅な刷新がなされているわけです。

つまり、新規のバグもたくさん含んでいるということ！！そこをご注意のうえ、ご利用いただければと思います　：）

flying tweetへ

書き直し中

flying tweetを書き直してます。alpha4まではいろいろ試行錯誤してたので、クライアント側のコードがグチャグチャで見通しは悪いし、メモリリークっぽい動きはするし、えらく重くなったりするし、、、と、ちょっと動作が残念な状況になっていたので。

サーバ側はけっこうシンプルですっきりできているので、根本的には手を入れるつもりはないのだけど、ちょっとおもしろいこと思いついたので、それを入れておこうかなと。

あ、あとtwitterのOAuth登録したので、次期バージョンからはOAuthログインできる予定。

quick tweet → flying tweet 早速名称変更

quick tweetはあんちょくに名付けてしまったのです。

だって、quickにtweetできるから。。。。

α版を公開してから気づいたけど、「QuickTweet」って名称のtwitterプロダクトは結構あるようで、すでにiPhoneとかでは有名らしいので、早々、名称を変更。

結構悩んだ(約1時間)末、またogochanから「Flying Twitterでいいんでねの？」的に提案があったので、それで、、とも思ったのだけど、名称に「Twitter」が入ってるのは問題かな？と。

一応、今後のことも考えてTwitterのOAuthを実現するつもりなのだけど、その申請時にサイトの名称を登録しなければならないので、へたに刺激しないほうがいいかなとおもって無難に flying tweet としてみた。

ちなみに全部小文字で書くのが正式です。なぜだかわかりませんけど。

ということで、今後は flying tweet として開発していきます。てか、開発継続なの？本当に？(汗

quick tweet (仮称)を作成中

ご多分にもれず私もtwitterを使ってるわけですが、time line(TL)の表示のタイムラグやサイトが重くなってサービスがつかえない。ってことが結構頻発してる。

で、まぁ、twitterってそんなものだよなぁー的に思っていたのだけど、twitterでfollowingしているogochanが「メッセージの配信をtwitterにまかせるのではなく独自にやっちゃえばいいんでね？」的なことをつぶやいているのを読んでちょっと興味があったので実験しながら作ってみることにした。

以前からtwitterのクライアントだとか自サーバを介してのサービスだとか実験的には作っていたので、twitterへのアクセスは比較的簡単に実現。

自サーバ経由でAPIを呼び出すと呼び出し制限数にすぐにひっかかるので、webクライアントからAPIを呼び出して結果を自サーバに送りつけて自サーバ側でTL管理とか以前つくったものがあるので、これらを整理して、ちょろっと作ってみたのがこれ。

http://site2.ohneta.net/

ユーザインタフェースとかまったくアイディアがなかったので作りながら考えてるとこあるので、リリースごとに極端に画面や機能が変わることがあるのでお気をつけてｗ