愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
author:えふしん
photo_20.jpg
藤川真一について


モバツイの中の人
マインドスコープ(株)社長
人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイの2つのスマートフォン
アンドロイドアプリ!
アンドロイドアプリ モバツイtouch
全てのスマートフォンブラウザと、Nintendo3DSで! HTML5版Webアプリ「モバツイsmart」
本を書きました!
100万人から教わったウェブサービスの極意 ~「モバツイ」開発1268日の知恵と視点
Google Friend Connect
このカテゴリ[会社活動]の最新30件
バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有 モバツイ、2つのスマホへのチャレンジ「モバツイtouchとsmart」 あなたのシステム開発観は、「動けば良い派」?それとも「ロマン派」? サードパーティツイッタークライアントの生きる道 モノを作る人は、鵜飼いの鵜ではなく鵜飼いの人 ネットは儲かるか?〜1人1円を1億人からもらって1億円売り上げる仕事 映画「ソーシャルネットワーク」の興味深いポイント6点 自分のやりたいことを会社で実現する方法 日本の葛藤 日本をコントロールしているもの 「ぼくはこうしてプログラミングを覚えた」をどう読みましたか? 方向性はあっている、という言葉の危険性 バタラさんとの採用コンテンツ作成秘話 ネットサービス系企業における、積み上げ型タスク管理の危険性 その時、誰がモバツイを必要としたか? - 震災発生から1週間の状況 「ツイッターのおすすめユーザー欄に表示される垢が、同一のグローバルIPアドレスからチョイスされた件」を回避する方法 ツイッターapi利用規約を翻訳しました。 つぶやきから、ソーシャルコマースにならないかを考えています 仕様の決断と、想定外 モバツイのエイプリルフール機能「イマココ(uso)」で、1万ツイート/day突破 モバツイに今いる場所を適当に送信する「イマココ!(uso)」をリリース 仕事のペース 業務ののりしろ ネットビジネスで成功した人は無茶をやってきた人 映画「ソーシャル・ネットワーク」の感想 エンジニアのこだわりと、継続的開発、チャレンジについて。 2010年振り返り2011年これから。 あなたの選択は正社員?非正規雇用? 「このサイトいくらぐらいでできるよ!」のピュア
[このカテゴリをもっと見る]
Powered by
Movable Type

February 21, 2004

Macromedia MAX[会社活動]

今回は、bAのセミナー一本釣りで参加しました。

「ビジネスアーキテクツが考えるRIA」というもの。

WebMethodsのセミナーとMAXに参加する人って少ないだろうなぁと思いつつも、前者はビジネスフロー、後者はフロントエンドの話ですが、共通項の見出せる話が聞けたので、僕の今の興味に対し、両方のセミナーの選択は狙い通りだったと感じています。

F'sGarageでは、ブロードバンドサイトを、単純にブロードバンドだからという理由で全面Flashで作るのって意味があるの?とか、Webの開発ワークフローで、システム設計、GUI設計をなるべく上流の方で行い、Webデザイナーの工程に押し付けない旨の意見を書いてきたつもりですが、もちろん、企業文化の違いで、ワークフローが洗練されているか否かはあれど、本質的には、上流工程での「ビジネス設計、マーケティング設計でのUIの重要性(さらに、マーケティング設計そのものが、きっちり、できてないよねって話)」と、「ユーザーインターフェース設計が機能設計に与える影響」などが話されていたと僕は認識しており、非常に親近感を覚えました。

つまり、リッチインターネットアプリケーションを作るにあたっては、ビジネス設計の段階で、UIや実現するシステムを共に考慮する必要があって、リッチインターネットアプリケーションとは、「ビジネスの戦略にそぐう形で提案するもの」という概念は、非常に賛成です。そうじゃないとFlashでせっせと工数かけて作るのは無駄ですし、かつ、FlashはPCでは結局のところプラグインが入っていないと動かないアプリケーションデータに過ぎませんですから、何を実現して、何を達成するのか?、そして同時に何を捨てるのか?という判断の先に、ビジネスを実現する目標を置くというのは、ごくごく当たり前のことですよね。

なんだか複雑なUIが必要そうだから、とか、見た目のインパクトが欲しいからFlashを使いましょうというのは、そろそろやめたほうが良いですね。実際、ユーザーは目が肥えており、そういうのに敏感に反応し反発を覚えるものです。

このセミナーでも、WebMethodsのセミナーでもまったく同じ言葉を聞いたのですが、「何を実現したいのか?が大事」という言葉。それはビジネスコンサルの方の役割なのかもしれませんし、そういう方が入らないプロジェクトであれば、上流工程の要件定義をする人が、お客さんと一緒に作り上げていく、ないしは、お客さんに明確な答えを持ってもらうように誘導していくことこそ、後の命運を左右すると言って過言ではないですね。

・・・当然、僕らの残業時間のためにも。


あと基本的なところを報告しておきますと、RIAの基本的なデータフローとして、サーバーサイドとFlash間ではXMLのメッセージをやりとりすることで、クライアントサーバーのシステムを形成しましょうというものです。それがFlashRemotingなのか、SOAPなのか、カスタムのXMLデータなのかは特に定義されていないと思います。余談ですが、今のFlashは、Web Services Connectorがありますから、WSDLを解釈してWeb Servicesに接続することなどもできます。しかも、.NET並に簡単にできます。

このような構成にすることで、Flashが搭載されたすべてのデバイスと通信することができて、サーバーを一つ置いておくだけで、携帯電話にもテレビにも通信することができるというものですね。もちろん、ちゃんと設計しておけば、Flash以外のクライアントでもサーバー間通信でも良いわけで、HTMLという最終出力データをサーバーサイドで作ってしまうよりも遥かに汎用性が高いという考え方ですね。

個人的に、次に知りたいというか、考えなきゃいけないのかなぁと思ったのは、セキュリティですかね。データに汎用性を持たせるということは、余計なデータを持たせたり、メッセージとしてRPC化していくことをあらわしますから、その時のセキュリティのあり方には興味あります。結局、HTTPの通信ですから、ヘッダ改ざんされて、適当なデータをPostされたことをブロックする手続きですね。

もちろんセッションIDなり、1 time keyのやりとりなどが基本的に取りうる手段だと思いますが、なんとなく、まとまった話を聞いて、自分の考えを固めたいという要望がありますし、もっとシンプルな方法があったら知りたいですね。

そういえば、WebServices系は情報を追ってなくてホント素人なんで、つまらない話ですが、WebServicesのセッション維持ってどうやってやるんでしょう?いわゆるクッキー+セッション変数のようなクライアント側の話と、サーバーサイドでセッションオブジェクトのようなステートを維持させる仕組みは、何か用意されているんでしたっけ?J2EEだと、EJBを使うんでしたっけ?Flashクライアントの場合はどうすりゃ良いんでしょうか?

昔、MSのSOAPのツールキットでRPCの実験したとき、二個目のデータってどうやって考えるん?という事で、話がややこしくなってきたので使うのやめちゃいましたというところで進化が止まっています。トランザクション単位にまとめたXMLデータを送って、Yes/Noを返すほうが簡単だということで。分散環境でのトランザクションともなれば、結局、新しい規格とかになるんでしょうね?

WebMethodsのセミナーで、「信頼あるメッセージの送信」が今年のキーワードみたいなことを言われていたので、全体的な意味では、まだ解決してないのかな?!

■同じカテゴリ[会社活動]のエントリー
<<前の記事 Webmethodsセミナー
>>次の記事 JavaによるWindowsサービスの作り方は?
■このblogの書き込み最新3件
インターネットの可能性を信じて〜本を書きました。 バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有