2009年11月20日金曜日

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

自分でも(てか、自分だけ?)alpha5を試しているのだが、クライアントがどうも「メモリ喰らい」の感がある。
一応、クライアント側はnow/friends/mentiosのそれぞれのメッセージを最大200件づつまで持てるようになっていて、余計なメモリ確保をしないようにしているつもりなのだが、動作途中でつくられるオブジェクトの解放がされないのか、どんどんメモリを消費しているようだ。firefoxでしかためしてないけど。
JavaScriptだから動的なメモリ確保は言語任せだし、オブジェクトの参照がなくなればメモリは解放されるはずではあるのだが、どうもそうなってはいないみたい。 どこかで参照が残り続けてるのかもしれない。これは困った。

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

手っ取り早い解決方法は、重くなりはじめるポイントを見つけて、そのタイミングでページをリロードしてしまえばいいのだけど、現在のクライアント実装だとリロードするとそれまで溜め込んでいたメッセージ情報も解放されてしまうので、ユーザインタフェース的にはダメだろう。
解決策として、クライアントの溜め込んだメッセージをサーバ側で保存して、リロード時にそれをクライアントに渡す。という方法を考えたのだが、twitter自身をメッセージのストレージとして使う的な目標もあるので、この方法は本末転倒。

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

2009年11月18日水曜日

flyingtweet alpha5

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

で、alpha5。クライアント、サーバとも書き直してみた。
クライアントのほうはalpha2~4まで、timelineはIFRAMEを使って子ページで実行したいたけど、親子間でデータの受け渡しが面倒になってきたので、YUIのタブ機能を使って1つに納めることにした。
もともとはファイルを分離すればコードの見通しがよくなるだろう、という単純な発想からIFRAMEつかってみたのだけど、親子間でいろんなデータの受け渡しをするようになってくると、逆に分離されていることの煩わしさが気になり出して、今回、クライアンのト書き直しでJavaScriptのコードが減ったので、まとめてしまうことにした。
いやぁ、コードのどこからでもデータが参照できるので楽になったよw

あと OAuthに対応。対応ってか、完全依存。。。
ログイン後もOAuthのライブラリを使ってtwitter APIを発行するので、APIは完全に依存してしまった。
ただ、これだとtwitter停止時に独自にメッセージ配信をおこなう。という当初の2大目標のうちの1つが出来なくなってるのよねー、、、いや、できなくはないのだけど、サインインをどうするかを決めてないので、結局、このバージョンでは出来てないわけです。
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を使ってクライアントをつくってもらえたらうれしいな。という甘い考えが本音w。

てなわけで、alpha5は大幅な刷新がなされているわけです。
つまり、新規のバグもたくさん含んでいるということ!!そこをご注意のうえ、ご利用いただければと思います :)

2009年11月14日土曜日

書き直し中

flying tweetを書き直してます。alpha4まではいろいろ試行錯誤してたので、クライアント側のコードがグチャグチャで見通しは悪いし、メモリリークっぽい動きはするし、えらく重くなったりするし、、、と、ちょっと動作が残念な状況になっていたので。
サーバ側はけっこうシンプルですっきりできているので、根本的には手を入れるつもりはないのだけど、ちょっとおもしろいこと思いついたので、それを入れておこうかなと。
あ、あとtwitterのOAuth登録したので、次期バージョンからはOAuthログインできる予定。

2009年11月12日木曜日

quick tweet → flying tweet 早速名称変更

quick tweetはあんちょくに名付けてしまったのです。
だって、quickにtweetできるから。。。。

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

結構悩んだ(約1時間)末、またogochanから「Flying Twitterでいいんでねの?」的に提案があったので、それで、、とも思ったのだけど、名称に「Twitter」が入ってるのは問題かな?と。
一応、今後のことも考えてTwitterのOAuthを実現するつもりなのだけど、その申請時にサイトの名称を登録しなければならないので、へたに刺激しないほうがいいかなとおもって無難に flying tweet としてみた。
ちなみに全部小文字で書くのが正式です。なぜだかわかりませんけど。

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

2009年11月11日水曜日

quick tweet (仮称)を作成中

ご多分にもれず私もtwitterを使ってるわけですが、time line(TL)の表示のタイムラグやサイトが重くなってサービスがつかえない。ってことが結構頻発してる。
で、まぁ、twitterってそんなものだよなぁー的に思っていたのだけど、twitterでfollowingしているogochanが「メッセージの配信をtwitterにまかせるのではなく独自にやっちゃえばいいんでね?」的なことをつぶやいているのを読んでちょっと興味があったので実験しながら作ってみることにした。

以前からtwitterのクライアントだとか自サーバを介してのサービスだとか実験的には作っていたので、twitterへのアクセスは比較的簡単に実現。
自サーバ経由でAPIを呼び出すと呼び出し制限数にすぐにひっかかるので、webクライアントからAPIを呼び出して結果を自サーバに送りつけて自サーバ側でTL管理とか以前つくったものがあるので、これらを整理して、ちょろっと作ってみたのがこれ。

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

2009年10月28日水曜日

python3/mod_wsgiで日本語表示

python3 (python3.1.1)+mod_wsgiで日本語なページを表示しようとしたら、なんかエラーがでたので、もろもろ調べて対策してみた。

その顛末を自分のwikiページにまとめたよ。
http://www.ohneta.net/wiki/index.php?python3%2Fmod_wsgi%E3%81%A7%E6%97%A5%E6%9C%AC%E8%AA%9E%E8%A1%A8%E7%A4%BA

2009年9月9日水曜日

いろいろ集めてみる。

mixiの日記機能が閉じた環境なので、friendfeedに繋いでみた。
これなら、twitterもbloggerもはてなもまとめてmixi側に出すことができるとおもう。

問題はmixi自身がfeedの反映が遅いってことか。
friendfeedはなんであんなに反映がはやいの?pingしてるのかな?

2009年9月5日土曜日

関数型言語わかりましぇーんw

やっぱLisp使いってかっこいいじゃない?20年くらい前かなぁ、、、Franz Lispの人(もちろん外国人w)とちょっとだけ仕事したことあったんだけど、やっぱLispで食っている人は、私らマイコンあがりからしたら別世界の人だった。
当時はMIT震源地のLispブームみたいのもあったので憧れだったりと。。。

で、この20年くらいLispかっこいいなぁ、関数型言語すげーなー、、などと思いながらも、仕事ではC→C++→Java(webに転向)→Perl→PHP/JavaScript って感じでメイン言語を渡り歩いてきたので、まったく関数型言語を使う機会がなかったわけ。関数型言語を使うような仕事って、私がいたような環境ではありえなかった。

ところが、ここ最近、日本ではrubyでなんかする。ってのが流行りだしてきている。rubyってぜんぜん詳しくないのだけど、ちょっとみLispを現代的なセンテンスで書き直したって感じ?と思っていたりしたのだ。

それから、なんかHaskellやOCamlが話題だし、MicrosoftがF#を出してきたりと、関数型言語を実際の仕事として使える環境が整いだしてきたような気がする。

さらに言えば、いままで使ってきた言語類もその拡張でイテレータが普通に使えたり、lambdaできるようになったり、FirstClassObjectが使えたりと関数型言語の特徴が取り入れられてきていることで、だんだん関数型言語が身近になってきている。

特にJavaScript。こいつ、あまり好きな言語ではないのだけど、それはなぜかというとwebでHTML書くときに使うから。
webではデザインとロジックを分離して書くのが主流の現在、HTMLの修飾のために使われていたりするので「どうもなぁ~」と思っていたのだけど、単純に言語としてみるとそれはそれでよくできている。DOM内蔵してるしねw。
で、いま、JavaScriptを触っている人が大量にいるわけで、JavaScriptの現代的な記法に慣れた人にとって関数型言語の概念は結構すんなりと入っていくのではないかと思うわけです。

かく言う私は、それはもう旧態然とした脳なのでなかなかハードルが高いのだが、やはり関数型言語を華麗に操るプログラマはかっこいいわけで、やらないわけにはいかない!ってのがここんとこのキモチ。

とはいえ、食っていくためにはPHPもやるしPythonだってやるさー。しゃーねーもんっ!

ううーーポータビリティにならない。。。

ハード的に同一サーバ上で開発環境とステージング環境を提供している。(実行環境)
しかも、初期化情報ファイルをweb側とバックグランドバッチ処理側で共通化している。(ファイル環境)

これが面倒なことこのうえない。
実行環境を切り替えるためにスクリプト内でdefineしている部分があるのだが、それをインクルードするファイルのディレクトリはファイル環境によって変えなければならない。つまり環境によってディレクトリが変わるが、ディレクトリの指定は環境を前提にしている。。。。なにをいいたいのかわかりづらいな、、、

んま、端的にいえば、条件が2重になっていて、それぞれが依存関係にあるので、共通化できないのだ。

これは非常にこまった。
環境変数とかで指定する方法もなきにしもあらずなのだが(実際、ほかのサイトではそうやってるものもある)、サーバ環境に依存しないポータビリティを追求している(していた)ので、ここで妥協するのはちと悔しいのだ。
どうにかならんもんかなーーー。

2009年9月1日火曜日

こうなんか、漲らない

なんかねー、ここ数日、本業以外のとこでいろいろ面倒な細かいことがあって、まとまった時間がとれない。
プログラミングなんてまとまった時間がないと進まないものだから、どうもダメだねぇ。
で、中途半端な時間で作業しても、中断されたとこから元に戻すのに、またいくらかの時間がかかる。

頭の思考を100%プログラミングに向けないと仕事できないようだな。わたしは。
自分ではコントロールできない状況をすごく嫌っているようだ。

と気づかされるここ数日であった。

2009年8月17日月曜日

結論は別RDBMSをqueueにみたてて読み書きGo!Go!

結論からすると、RDBMS自身がネットワーク越しに接続できるのだから、それを利用しようということになりました。
messageに対して1対1で処理プロセスが走るならメモリ上のqueueでもいいのだろうけど、1つのmessageで複数の情報を生成するつもりなのでね。あ、あとqueueからmessageを消すタイミングは時間ベースでやるし、リレーションしやすいというかすでに慣れてるRDBMSのSQLでやろうかなと。

さー、DBのschemaガチガチに固めなければ、、、いまどきっぽくないですけどっ!(T_T)

2009年8月16日日曜日

で、いろんなfeedを提供したいのだが、

いろんな切り口でRSSってかfeedを提供したいのだが、message queueに入ってる情報をどう使うかはクライアント(この場合、提供するfeed情報を生成する)プログラム側の処理次第。

で、じゃ、いつまでqueue内の情報は残しておけばいいの?ってのが問題。
クライアントプログラムがどのように切り込んでくるかはわからない状態だと、永遠にすべて残しておかないといけなくなる。さすがにそれは無理ぽ。
だとすると、やはり先に生成するfeed情報を決めておかなければならない。そうしないとqueue内のデータがいるのかいらないのか判断をつける材料がないもの。

さーて、困った。
どこまでほしいんだ?個人的には what's new と 個別テーマくらいでいいかなとは思うのだけど、mylistの更新情報もfeedでほしい気がする。
他にも共通グループでのfeedもほしいかもな、、、グループは大枠できてるし、このまま採用されるだろうから、それも考慮しておいたほうがいいよな。
あー、だれそれさんって個人ののfeedもほしいかなー。


feed集めて表示してるfriend feedとかfacebookとかはどうやってるんだろうか?
動的に取ってるわけでもないだろうし。。。むむー、悩むぅ~~~~

だいたい提供するfeedそんなに多くていいのか? mylistを分類できるようにしといて、それをfeedすればよくね?「feedしたかったらmylistに登録しやがれ、このヤロウ!」と言い切れるしw。

2009年8月14日金曜日

でだ、

そうなってくると、更新のタイミングで処理するものが多くなってレスポンスが悪くなるのがみえみえ。
まだ、ユーザが少ないので更新なんてそうそう発生してないから、マシンパワー使いたい放題だけど、ユーザが増えてきたらここらへんが効いてきそうだなーと。60万PV/日の携帯サイトをやってた経験からね。

なので、リアルタイムで更新する必要のないものは、チマチマとバックグラウンドで処理しようかなと。RSS の書き出しとかtwitterでつぶやきとか。(RSSつける前にtwitterのつぶやきI/Fをつけたあたり今時でしょ?w)

ということで、そんなときは、メッセージキューだよな、と。IPCだと同一マシン(ていうかOSのインスタンス)内でしか利用できないので、それは却下。ネットワーク越しにできたほうがいいじゃない?いまは利用しなくても将来的に絶対に。
てことでActiveMQやらRabbitMQやらを調べていたのだけど、結構面倒そう。Java環境入れなきゃならんしねー。もちっと軽量なのないかなぁー。

でけた。RSS

なんと、問題はURLの&でした。xmlを書かなくなって久しいので、こんな問題にひっかかってましたよ。とほほ。つか、HTMLは普段書いてるんだから、意識しろよ>おれ。

てわけで、とりあえず what's new をRSS1.0で書き出せるような仕組みはできた。
あと、個別のテーマ更新もそれを追ってる人向けにRSSできればなぁ、、とおもい、更新のタイミングをトリガとしてRSSファイルをベースにした更新履歴を考えたのだが、そうなると、RSS1.0よりもRSS2.0のほうが簡単な処理で済みそうなので、RSS2.0ベースで全体で使えるユーティリティクラス化してみた。

当初、node操作なんぞせずに、ベタにXMLファイルを書き出すつもりだったけど、node操作しないと履歴操作できないから、結局DOMでガリガリにXML操作するハメになったし。。。実に10年ぶりくらいにDOMでXML操作したよ。はじめてつくった携帯サイトがXMLバリバリでつくったヤツなので、あれ以来。いやぁ、XPathだとか便利なものも揃ってるし、いいね。いまどきのXMLは。

2009年8月13日木曜日

ハート型のビーズに黙々と糸を通していく娘、3才。

すでに50個くらいは通したようだ。
色はバラバラだが、すべて同じ方向に通してるぞ、、、

なんかチマチマした作業が好きなのか?

自分がダメだと思う瞬間

エロサイトを見ていて大量のサンプルムービーを見つけて、その一括ダウンロードスクリプトを書いているとき。特にJavaScriptとか絡めれ て簡単にぶっこ抜きできなくしてるようなサイトを攻略してるとき。

すべてのしがらみを振り切って、一心不乱にサイトの構造とかファイルの規則性だとか見つけ出したり、HTMLやJavaScriptを読んでどう動いてるか調べてるときに、ふっと我に返ってしまうと「ああ、おれ、ダメじゃね?」と思う。
だが、そんなものは一瞬なので、すぐに作業に戻るのだがw。


てか、その情熱を生産的ななにかに向けろよ、、、42才のおれ。(汗

やっぱいまどきのサービスを作ってるんだから

feedできなきゃね。とおもい、RSSを自動生成しようとしてるのだが、
なんかうまくないのです。

ひとんちのサービスが提供してるRSSファイルを参考にいぢってみたりもしたのだが、
まるまるコピーする分にはうまくいくけど、大幅に項目削除して縮小版とかつくってみるとうまくいかなくなる。

なんでかなぁ~。もちっと悩んでみるかぁ...(T_T)

2009年8月12日水曜日

私の中のmixi終了のお知らせ。

私の中ではmixiは利用価値が激低下。
単なる知り合いのblogのfeedの価値ぐらいしかない。
あ、ときたま2ホップ以上の知り合いで近しくなりたい人はでてくるけど、んま、それもmixiである必要はなし。私がwebサービスに求めるものがmixiでは実現できないので、利用価値激減。

ユーザ側の要望(つか進歩?)をフォローしきれなかったmixiさん、敗北です@私の中。

AmazonEC2 postfix submisson 設定時のメモ

ローカルのPCのHDDが吹っ飛んだりした場合、メモをなくすと困るのでブログに書いとく。
---------------------------
■環境
amazon ec2 m1.small
(fedora x86/32bit インスタンス)

submmision port = 587
TCP/UDPの両方が必要

MTA is postfix.

■submission portを開ける

/etc/postfix/master.cf
#submission inet n - n - - smtpd

submission inet n - n - - smtpd


■SMTP Authする
/etc/postfix/main.cf

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
#smtpd_sasl_local_domain = $myhostname
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes


aws EC2 の fedora8 Basicでは sasl2はデフォルトインストールっぽい....
一応、確認...
> # cat /usr/lib/sasl2/smtpd.conf
> pwcheck_method: saslauthd
> mech_list: plain login

いらない
mkdir /var/state/saslauthd
chmod 700 /var/state/saslauthd
chown postfix /var/state/saslauthd

saslauthd で使用可能なメソッドを確認。
># /usr/sbin/saslauthd -v
>saslauthd 2.1.22
>authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap

とりあえずpamで運用。


sasl2の起動
/etc/init.d/saslauthd start

動作してることを確認
> # ps ax | grep saslauthd
> 31697 ? Ss 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31699 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31700 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31701 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31702 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam

postfixの再起動
/etc/init.d/postfix restart


----------------------------------
■popperの設定
dovecot.i386
dovecot-devel.i386

># yum install dovecot.i386 dovecot-devel.i386

/etc/init.d/dovecot start


----------------------------------
■EC2の Security Groupsの設定
メール関連部分のみ抜粋

C/Method Protocol FromPort ToPort Source
POP3 tcp 110 110 0.0.0.0/0
SMTP tcp 25 25 0.0.0.0/0
- tcp 587 587 0.0.0.0/0
- udp 587 587 0.0.0.0/0

----------------------------------

■動作確認
自ホストから....
># nmap localhost
>
>Starting Nmap 4.52 ( http://insecure.org ) at 2009-08-12 02:36 UTC
>Interesting ports on localhost.localdomain (127.0.0.1):
>Not shown: 1705 closed ports
>PORT STATE SERVICE
>22/tcp open ssh
>25/tcp open smtp
>80/tcp open http
>110/tcp open pop3
>143/tcp open imap
>587/tcp open submission
>993/tcp open imaps
>995/tcp open pop3s
>5432/tcp open postgres
>
>Nmap done: 1 IP address (1 host up) scanned in 0.155 seconds


外から...
>$ nmap さーばあどれす
>
>Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2009-08-12 11:54 JST
>Interesting ports on さーばあどれす:
>(The 1654 ports scanned but not shown below are in state: filtered)
>PORT STATE SERVICE
>22/tcp open ssh
>25/tcp open smtp
>80/tcp open http
>110/tcp open pop3
>587/tcp open submission
>
>Nmap run completed -- 1 IP address (1 host up) scanned in 35.845 seconds

2009年8月11日火曜日

メールサーバ移行の手順メモ for 自分

旧DNS
MX=旧サーバ
TLLを300程度にする。浸透するまで待つ。(いまのままだと10時間程度)

■新サーバ
新DNSをたてておく

SMTP AUTH/TSLでpostfixを入れる。
旧サーバと同等のアカウントを作る。
旧サーバと同等のmain.cf/virtual/aliasを用意する
(virtualで旧サーバのアカウントをフォローしておく)

別ドメイン名の新旧DNSのMXを新サーバに向け、それで送受信ができることを確認。
-----------------

旧サーバMTA停止
DNSのMXを新サーバに向ける

10分程度待ってで新サーバにメールがとどくかどうかチェック


ドメイン名のレジストラにDNSの変更通知(新DNSに変更)
了承がとれたら、旧DNS停止


以上。

FriendFeedが買われた。

んま、企業の売買はよくあることなので、珍しくもなんともないのですが、買ったのはFacebookですか。
金に困って売った。的なものではないようなので。

なんていうんですか、feedを集めて1つのコンテンツにする。って最近のはやり、名称はよくわかりませんが。この手のサービスは、元ネタ提供の他のサービスから独立した位置にあって成立しているのでおもしろいとおもっていたのですよ。

あ、ああ、あれだ。mixiがなんでもかんでも囲い込んでしまっているのとは対照的な位置ですね。
オープンな感じ。個人の采配で好きなようにサービスが組み合わせられる。という感じ。


んとね、以前からなんかやれそうだな。とは思っていたんです。んま、自分でやってないのでその時点で負け犬の遠吠えなんですが。
この手のソーシャル系サイトとかブログとかニュースサイトなんかでもいいんですけど、今時的にいえばリアルタイムストリームサイト(?)などの更新が頻繁なものを、個人にどうみせるか。ってインタフェースね。
もう、webでしかサービスが許されないような状況になりつつあるので、やるならweb上で。

常に集めて、趣味嗜好、現在の興味のターゲットでリアルタイムに分類して、表示方法も工夫。
たとえば、いま興味の中心になっているものは大きく見やすく、情報量多めに。
iTuneとかsafariのUIでCDジャケットやらwebページが3次元的に並んでいて、注視しているところが中心に表示されるヤツあるじゃないですか?あんな感じのもっとイイやつ版。
もちろん、ぼんやりとしか考えてないので、どうすればいいか?なんてわかりませんよ。そりゃ。汗。
でも、あの手のUIで見せてあげれば、人の思考の補助装置としてはとてもよいのではないかなー
と思っていたのです。

で、その手の可能性としてFriendFeedを使い始めたのですよ。
そしたらその矢先にFacebookによる買収って。
いや、ただ、いまFriendFeedとtumblrに注視してたのでこの話題を書いてるだけです。

2009年8月10日月曜日

ここから

friendfeedを経由してtwitterにでるのか?ほんとに?

よ、わからんちん。

よっ!???
どう?