笑わないプログラマ - 【軍曹が】携帯電話開発の現状【語る】This domain may be for sale!
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
動的URLのSEO効果について。
面白い話があった。 グーグル、動的URLはそのまま、静的URLへ書き換えすべきでない » 海外SEO情報ブログ・メルマガ この辺は、そもそも都市伝説みたいになってる世界。 今までは、↓がバイブルだったけど多少は明確になったかな。 「動的URLも静的URLと同様に扱う」 - Google Matt Cutts氏 :: SEM R Web屋さんはクライアントにこの辺の話を言われたときの引用ネタとしてメモしとくべし。 動的URLと言えば、検索結果ページのように刻一刻と検索結果が変わるようなページは、あまり検索結果に出てきて欲しくないですね。 でも外部から直リンクがあれば問題なくインデックスされるし検索されるけどね。 ちなみに結構、今でもたまに、うちのシステムはURLが動的だからSEOがダメだとか言われたりするんですが、同じASPサービスを使ったお客さんでバリバリ検索上位にでてくんですが・・・みた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
