_ フィード情報におかしな情報が混ざっているものがあります blogmapのOPMLインポートのテストをしていたんだけど、なぜかその機能を使って追加したフィード情報に、おかしな情報が混ざっていることがあります。まだ原因は調査中(ライブラリのアップデートが影響しているかも?)ですが、妙な情報が登録されている(同一タイトルのフィードが重複していたり)フィードを見かけたら、教えていただければ修正します。 _ 内部APIいろいろ 日本で公開されているAPI一覧(下書き)とかからリンクされてたんで、どうせなら1470.netリニューアル版内部で使っているAPIも一応書いておこう。内部用なんでいつまで使えるかは未保証だけど。 個人で使う分には外部から適当に呼び出して使ってもいいけど、ばりばり使う場合は、タグ系API以外はどうせ元ネタを公開(位置情報+郵便番号データベース、鉄道路線+駅位置情報データベー
■ [tDiary][Memo][encording]日記更新時の処理がおかしい む、明日以降のlivedoor天気情報や1470.netの情報が取得できてないな。一昨日contribにつっこんだ変更点の影響な予感。 帰ってきてから調べる。 追記 変更前のものに差し替えて暫定対処。 追記2 色々調べてみたけど、livedoor天気情報は特に問題なし、1470footerは2006/07/11のデータ限定で取得できないみたい。朝、登録しようとしたときに「不正なフォームからの投稿です」とか何回も言われたのが関係あったりするんだろうか。 追記3 PlaggerのXML-Liberalのエラーログを見て原因が判明した。World Wide Walker: youtube の動画をダウンロードする ruby script から取得したタイトルが文字化け起こしているのが原因で取得処理が止まっていたもよ
_ スケーラビリティとミニマムの負荷 旧バージョンはDBのselectクエリーは分散できるものの、それ以外は分散がほとんど効かないような設計だった。今回はアプリケーションサーバーもDBサーバーも単純に追加できるような設計にしてみたんだけど、そういう設計だとミニマムでの負荷はどうやってもある程度ベタに書いた設計よりも高くなってしまうなー。 すでに現段階で結構な手数を高速化(大量に呼び出されるurlForをベタに書き直したり、エスケープ処理の呼び出しにかかるコストを下げたりとか、とか)に費やしているんだけど、それでも1台増やしたサーバーがぱんぱんだ。DB負荷対策のためにメモリを増やしておいたんだけど、ロジックに費やすCPUパワーの方が先に頭打ちになってしまった。 商売でやってるんだったら、素直にサーバーを増やせばいいんだろうけど、個人でやっていると金だけじゃなく運用にかかる人的コストもばかにな
_ ようやくMM/Memoでの503頻発が改善できたっぽい 新1470.netと同程度にバランスされるはずなのに、なぜかMM/Memoばかり503エラーになっていたのを改善しようといろいろいじっていたんだけど、ようやく改善できたっぽい。 結局問題は、旧1470.netで受け付けていたpingサーバーへの、世界中からの(ほとんどがspamの)アクセスで、PoundからMM/Memoへのコネクションがあふれてしまっていたらしい。pingサーバーへのアクセスをMM/Memo側のサーバーに振らないように変えたところ、503の頻発はようやく解消された模様。 というわけで、今週頭あたりからご迷惑をおかけしてきましたが、ようやく従来通りアクセスできるように戻ったと思います。
_ MM/Memoからのインポート MM/Memoからのデータインポートスクリプトを作って、試しに自分のメモをインポートしてみた。MM/Memoではできなかった*1解析とか検索とかがまっとうに動くので結構楽しい。 MM/Memoユーザーの方で、自分のデータもリニューアル開発テスト版の方にインポートして欲しい方は、リニューアル開発テスト版の方にアカウントを登録した上で、MM/MemoのユーザーID(数値)とリニューアル開発テスト版のアカウント名(英数字)を教えてください(ここのコメントにお願いします)。 ちなみに対応するのはURLとASINに関するメモのみで、位置情報(互換性がなくなった)やテレビ番組情報(リニューアル版では取り扱っていない)はインポートできません。あと、URLに関しては古いデータだとすでに情報が取れないURLも結構たくさんあるみたいです。 データがある程度そろった状態じゃな
_ 街区レベル位置情報+郵便番号データ 次期MM/Memoというか1470.netで、位置情報関連機能を強化しようと思って、まずは位置情報→住所、郵便番号→住所→位置情報とかが手軽に変換できるように、街区レベル位置参照情報と郵便番号を合成してみている。 主データとしては、街区レベル位置参照情報の方を利用する。というのは、郵便番号の方は位置情報ではなく、郵便の都合で区分けされているんで、より位置情報のキーとして使いやすそうなのは街区レベル位置参照情報の方だから。 街区レベル位置参照情報は「丁目」よりも細かい「街区符号・地番」レベルの情報も持っているけれども、そこまで扱うと 住所情報としてのセンシティブさが増しすぎる 郵便番号情報との粒度の違いも大きくなりすぎる AjaxとかでがんがんDBを叩くにはデータサイズが増えすぎるだろう という理由で、データとしては「丁目」レベルまでを扱い、それ以下は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く