第38回 ユーザ評価の落とし穴 | WIRED VISION
第38回 ユーザ評価の落とし穴 2009年12月16日 （これまでの増井俊之の「界面潮流」はこちら） 人間が利用するシステムを作るときは必ずユーザ評価が必要です。開発の初期段階において客観的な他人の目で見てもらうことにより、問題を早期発見することができますし、全くスジが悪いようであれば最初から考え直すこともできます。少人数のテストユーザに評価してもらうことによって劇的に問題点が減ることが知られています。 完成したシステムについてもユーザ評価は重要です。新しいユーザインタフェースシステムを開発した研究者は、学会で論文を発表することによってそのシステムを世に広めるのが普通ですが、論文を発表するためには、識者による論文査読を通過する必要があります。新規でないシステムや有用でないシステムなど、発表する価値が無いシステムは査読の段階で問題点が指摘され、論文として発表されないようになっています。 この
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
