お願いします2014/07/01バーチャレクス・コンサルティングで働く男のaws日記こっちもバーチャレクス・コンサルティングで働く男のアルゴリズム勉強日記ちょっとGoogleランキングについての実験中のため。アルゴリズム勉強日記を始めたけど、これはこれでこっ恥ずかしい2014/06/28〜で働く男のNNN日記、の第二弾だけど、AWS日記よりもさらに恥ずかしさが増すのはなんでだろう。色んな本を並行して眺めてたけど、「アルゴリズムを学ぼう」はおおよそ一般的な領域は網羅しているかな2014/06/25データ構造とアルゴリズム的な話題が、だいぶ身近になってきた。c一般的にはこういう公式しか出てこないし。合同式とか意味判らんし。[大型本]2014/06/13読み終わった。-l3)rubyのPATHを追加これでだいたい行けるはず。ckw-modの文字サイズ調整はckw.cfgってファイルを修正すればOK。SJISに変換するとか多用しそう(EXCEL用にCSV出力とか)その他は下記サイトが参考になる。人生初プルリクdone2014/03/19github本、なかなかわかりやすい。GitHubhttps://github.com/masakacometdのチャットアプリとか、とりあえず動くこと目標で作ってたので相当ひどいソースですが、とりあえず。エラー2010/12/08http://d.hatena.ne.jp/mirakui/20100502/1272849327の通りですが、この手順をやらないといけなかったのでメモ。(x86_64)これも出てた。‘username_completion_proc_call’:efreedomってサイトは最近よく出てくるけど自動翻訳で却って分かりにくい。URL先頭のja.を外すとオリジナルの英語表示に戻ります。謎アプリのその後2010/12/07謎アプリをエンドユーザに近いところに軽く見せたところ、やっぱリアルタイムチャットを必要としているということではないらしい。ポートの話もあるし、個別アプリにしちゃうとアップデート地獄に堕ちるので、ここはリアルタイム系はすっぱり諦めてperiodicalにexecuteすることにする。ユーザ数1000人くらいまでなら大丈夫かと。・GAEでPusherを使わずにComet出来るようになったらしい。APIってのを使うらしい。スティルハウスの書庫http://d.hatena.ne.jp/kazunori_279/20100528/1275039829・あんまり関係ないけど。gimitehttp://d.hatena.ne.jp/Gimite/20101017/1287298216こういう話ってのが地味に大事だと思うんだけどその大事さを継承できていないなあという気がする昨今ですが、まあそれはそれでよかろうと。・というわけで当面はAjaxベースで充分かと。JQueryベースに移行したいところ。日本語リファレンスhttp://semooh.jp/jquery/api/effects/dequeue/_/・とか言いつつ、当面Websocket関連はwatchするつもり。リアルタイムWEBとか2010/12/04を作ろうとしていたりしていて、アプリ部分(railsとか)とリアルタイム処理部分(cometベース、もしくはwebsocket)との振り分けをなんとかできないか。80番ポート1つですべて動かす、ってことができないかを調べてたのでその現時点での自分用メモ。いうか、ポート2つ使うものであればshooting_starベースで一応ひと通り動く状態にはなってるんだけど、ポート2つ使っちゃってるから、SSL化できないというのが今の課題。できるだけ有りモノですまそうとした場合、方法としては2つ。■nginx用のプラグインで振り分ける⇒リアルタイム処理の部分が独自実装になっていて?悩ましい。これからはやっぱwebsocketだろ、という気もしつつ。■haproxyで、websocketのリクエストを振り分ける⇒これが出来ればこっちで行くんだが、とりあえず動かない。こっちが本命かなという気もしつつ、websocketの仕様がまだまだ固まらないという話を聞くと実戦投入はまだ先かなとか。いう意味ではcometはある意味枯れてるよねという話も。・URLベースでnginxとかでリバースプロキシすれば1ポートで出来るんじゃないの?⇒これはすんなりとは行かないと思われる。例のshooting_starベースだと、チャットでの発言を受けてlong_poll中のセッションにレスポンスを返す部分が一つのコントローラになっていて、これを分離するのが面倒。・1つのポートですべて完結させたいっていうののそもそもの目的はHTTPSベースにしたい、ってことなんだけどそれって出来るの?⇒websocketにはsslは実装されてるっぽい。sslでも大丈夫なのか、ちょっと怪しい気が。keepaliveみたいなこともできなかった気が。(それを解決するのがwebsocketのssl通信ということかと)というわけで、結局lingrと同様にeventmachineベースで半分自作みたいなcometサーバを作って、リバースプロキシで内部振り分け、っていうのが一番現実的かも。何年も前にそれできちゃってるlingrはすごすぎる。あとリアルタイムチャットにどこまでこだわるか、ってのはあるんだけど。エンタープライズ用途だったらperiodicalExecuteとかで充分な気も。http://blog.liris.org/2009/12/websocketchat.htmlgo言語によるwebsocketチャットの実装。簡単なものはすぐできるけど、認証の仕組みとか複数のチャット部屋に分けたりするのはどうしたらいいのか全くわからん。http://kwappa.txt-nifty.com/blog/2010/11/eventmachineweb.htmleventmachineベースのruby用のいろんなgem。em-websocketとem-websocket-serverは違いがよくわからん。em-websocketベースのものが手元では動いている。https://github.com/dansimpson/em-websocket-serverこれは単にProxy。リバースプロキシっぽい使い方が出来るものかと思って期待したんだけど違ったっぽい。https://github.com/mcolyer/em-websocket-proxyStompってのがあるっぽい。http://matt.colyer.name/2010/07/18/websockets-stomp-the-real-realtime-web/Crampってやつとか。https://github.com/akitaonrails/cramp_chat_demoこの人の記事はひと通り読む価値あり。em-http後半がよくわからん。勉強になりそうな予感。