データは Web に、操作はデスクトップで

naoyaのはてなダイアリー - ETech 2006 レポート

Feed Reader で一番必要だと思ってる機能(?)は、購読リストと未読状況の同期。違う PC で利用しても一度読んだアイテムが未読として扱われる事は鬱陶しい事この上ない。で、ドキュメントとかメモとかも、社外秘みたいな物を除いてどこでも見れると嬉しい。

TrimPath Junction っていう JavaScript のフレームワークを使うと、オフラインでもアプリケーションが動作して、その時に編集したデータがオンラインになった時に Web(サーバ) 上のデータと同期してくれるらしい。

個人的にはインターフェース機能を求めるなら OS ネイティブ(?)な物を使うべきだと思う。Ajax で Web アプリケーションがリッチになるのはすごい事で、面白いんだけどブラウザを通さなきゃいけない時点でどうなんだろう、と。Ajax での UI 構築案を否定する訳じゃないし、Web 開発現場に身を置く訳だから興味深い技術なのは確か。ただ、あくまで個人的な欲求としては、WebAPI 通してデータ通信する OS 提供の UI アプリがいいなぁ、と。使う側としては広告がどうとか知った事じゃないし。

セキュリティ脆弱性(?)が問題になってきてた JavaScript を惜しげもなく使う事に対策はとれてるのかな?アプリケーションを使う時だけ JS を有効にするなんてのは論外。逆に、ブラウザを使わない場合に、セキュリティ的な問題ってどんなんだ?まあ、気にしないで Ajax アプリを楽しんでるんだけどね。

「インストールの手間がない」ってのは確かに売りなんだけど、「持ち運べるデスクトップ」っていうアプローチもあるし、どうなんだろう?持ち運ぶ場合に紛失の危険性があるから、前者がいいのかな?誰かに拾われた場合に危険になる情報は記憶させないとかで解決?

なんとなく、WebAPI が中心になっていってる気がする。トラフィックを上手く捌くサーバ周りの技術と、安全で快適で使いやすいインターフェースを実装するプログラミング技術。これまで、操作感としての Ajax にばっかり目がいってたけど、そろそろ「向こう側」を扱えるようにならないと。

会社の上の人が結構「アフィリエイト」系のサービス案をやりたがってるんだけど、上手い事回していく技術力がないからいつも「自分には無理です」って流してしまう。広告を貼って収入にするアフィリエイトじゃなくて、アフィリエイトの流れをサービスに組み込んで自然に購買経路を作る感じのアイデア(上手く言えないけどそんな感じ)だから面白いんだけど。ユーザが使いたい機能を使ってくれたら、それがサービス提供側の利益につながる。コンテンツにあった広告を出せば似た感じの興味につながるってのもいいアイデアなんだけど、個人的に「広告はクリックしない人」だから違和感がある。まあ、よっぽど上手い具合に融合できる場面じゃないと駄目なんだけどね。

トラフィックを捌くサーバ技術、認証を安全で快適に行うための技術、合理的なインターフェースを持った API、ケーススタディっぽく勉強するために英語。基本的なプログラミングのお勉強すらままならないってのに、こんなに課題ができやがった。Cocoa もやってみたいし、XUL もまだ手が付けられてなかったり。あー、データベースもやんなきゃ。今日も"GROUP BY"忘れてて突っ込まれたし。チューニングがどうとか言われたらお手上げ。

あれだ、共有サーバ使ってるうちは駄目駄目なんだ。早いとこ専用サーバ借りないとな。自宅サーバは無理(というか嫌)。

プロフィール

このブログ記事について

このページは、koshigoeが2006年3月10日 23:13に書いたブログ記事です。

ひとつ前のブログ記事は「WYSISYG に不慣れな最近」です。

次のブログ記事は「自分にプレッシャー:自社サービスに要望」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。