PhotoShare向けAddOnソフト募集
先週の金曜日（日本時間の土曜日）に販売を開始したSmallCanvas、PhotoShareユーザーの多くの方々にご購入いただき（そして実際に使っていただき）、大変感謝している。 無料で提供しているPhotoShareに対する「ご祝儀」の意味も多々あるとは思うが、わずか三日でアクティブ・ユーザー（ユーザー数は未公表）の15％以上の方々にご購入いただけたのは予想を上回る成果。 まだまだ母体となるユーザー数が小さいので黒字化にはほど遠いが、「無料で提供しているPhotoShareをソシアル・ネットワークの母体として活用するAddソフトをコミュニティーに向けて販売する」というビジネスモデルの確立に向けた第一歩としては悪くないすべりだしだと思う。 後はユーザーからのフィードバックを（PhotoShareを通して直に）受けながら改良を重ねて、20%、25%、と普及率を高めて行く努力をしつつ、同時にP
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Big Canvas PhotoShare
