いう関数でお亡くなりになっている事が判明しました。}(゚∀゚)アヒャ(゚∀゚)アヒャ。いうことで、とりあえず、2引数を取る形態で対処しました。終了で困ったまぁ、一応書いておこうと思う。現在241フィードほど登録してます。系が多いのは置いといて、面白いと思ったブログなどは定点観測しています。死んだとか、ふざけた事を書いてるやつがいますけど、冗談はやめてください。面白いと思ったブログは巡回するんです。いう訳で、移行先を探しています。?でも、なんか違うんですよね。終了に備えて準備していただけあって、移行はスムーズにできました。フィードの消化が全くもって無理でした。スペースキーとかでフィードをどんどん消化できるようじゃないと、使い物になりません。決めようかなーと思いつつ保留してます。他にも名乗りを上げているところがたくさんあるようなので、使い勝手をチェックしつつ6月中には移行先を決めたいと考えています。読者購読とシェア機能を工夫して実装してもらえると、尚良いです。違って、この部分のソーシャルは、ほんと面白かったんです。なんと言うか、鋭さが違います。この投稿へのリンク2013年3月12日火曜日ポリゴンの髭を取り除く標準に無い変形アルゴリズムを晒してみようと思います。みたいな構成のポリゴンは、髭のように変な辺が飛び出しているので、それを消去するのに使います。消去しても油断できません。地道に再帰で消し去ります。}あんま、おもしろくないですかね。はまった事なぞを、思い出せる範囲で書いてみようと思います。かけると、見事にデータが壊れました。一部対応している状況なので、文句は言えません。このバグは場所を特定できるまでに凄い時間がかかりました。どこで壊れているのか探すのも大変でした。かけて移動させると、要素が倍で増えました。した後にも残骸が残っており、残骸要素が加算されていくというバグでした。コールする事で回避しました。優先されて、予期せぬ挙動を引き起こしました。ファンクタを利用するようなアルゴリズムをこさえる事で回避しました。データを引いてサーバ側で地図を描画して配信しているシステムがあるんです。このシステムの難しさは、5分間隔とかでリアルタイムに大量の軌跡を描画しなければならん所です。24時間以内の長さで、好きな期間を指定できるのと、軌跡を表示する移動体を自由に選択できるところも難しいです。輪をかけて難易度を上げているのが、軌跡の点の上にマウスを置いとくと、その点の通過時刻を表示するという仕様です。この仕様のおかげで、データを点としてデータベースに保持するよりありません。負荷のかかる見方をするのが、直近の24時間程度という特性もあります。ポリラインとか、ポリゴンで登録されていれば、空間インデックスにかけて関係する部分だけを取り出し描画すれば良いんですが、軌跡の場合は、点と点を結ぶ線の情報が必要なので、空間インデックスで絞るわけにもいきません。指定された期間中のデータを総なめする必要があります。対する負荷が膨大になり、ストールを起こします。程度で、それが移動体分になります。MySQLがそんなに性能が凄い良いとも思っていなかったのを裏付けした格好になります。使って、接続イニシャルを減らす方法を試してみました。1.2倍のペナルティを受けてしまいました。十分にプール数を確保しても、そうだったので、今時のPostgreSQLは、相当に速いんだなぁと実感できました。負荷を低減させる方策を思いつきました。して、5分間隔に軌跡の点を保存して、そこから引くようにしてみました。ところが、実装して試してみると遅い。288回のリクエストを発行する計算になります。