アカウント名:
パスワード:
悔しかったらAjaxでDAW(MIDIシーケンスおよび音声データからなる音楽を「作成」するソフト)を作ってみろって(^^;
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
限定的なものの開発が容易になるだけ (スコア:1, 興味深い)
新しい世代の「Googleの」アプリケーション開発が「Google APIで」いかに容易かって?
そりゃ一番容易に決まってるだろうが。
なにせGoogleアプリに特化したAPIなわけだからな!!
…と一瞬空目しました。
Google APIというか一般にAjax APIやWeb Service APIの類って、
結局のところ対象とする問題領域やインフラ領域が
Webという狭い範囲なので、
なんかあまり真剣に学ぶ気が起きないですねえ。
Re:限定的なものの開発が容易になるだけ (スコア:0)
>Webという狭い範囲なので、
何のこっちゃ?単にAPIの使用に必要なのがHTTPっつープロトコルであるってだけでしょ?何故Webに限定?
じゃあ一体何のプロトコルを使えば広い範囲になるの?
# まさかPCのローカルで呼び出すAPIが「広い」なんて事は無いよな
Re:限定的なものの開発が容易になるだけ (スコア:-1, 荒らし)
HTTPも含めた:-P、ローカルも含めた、
全部のAPIを好き放題使える(つまり選べる)環境よりは、
明らかに狭いのですけど。
リモートであるが故にどうしても実現困難な機能は、
やっぱり一杯あります。
正確にいえばリモートかつセキュリティチェックを要するせいでの
(現状での)遅さ故ですが、
例えばリアルタイム系の処理はまだまだ無理。
#そうでないならPCにメモリを積む必要が無くなるはずだ。
WebというかHTTPに「限った」話をしようとすると、どうしても
そういう処理形態、
そういうコンテンツ、
そういう操作体系、を
切り捨てざるを得ません。
そのぶん、狭くなっています。
ソフトリアルタイムの、それも大甘な基準で十分だという状況なら、
HTTPをいちいち介在(^^;させる処理形態でもOKですが、
それだけでしょう。
キーボードやマウスの入力や、画面の描画とかまで
なんでもかんでもHTTP経由にしたら、
流石に辛いですね。
3Dデータとかも、かなりチャチなものに品質を落とせば
最新の通信環境(つまり光とか)の上のHTTPでもまあ何とかなりますが、
(少なくともまだ)その程度ですね。
悔しかったらAjaxで
DAW(MIDIシーケンスおよび音声データからなる音楽を「作成」するソフト)
を作ってみろって(^^;
あ。FLASHで作られたものは有るらしいですが、
あれは結局はFLASHで作られたアプリを
ユーザに渡すためにHTTPを使ってるだけなので、
ダウソロード手段に過ぎませんよね。
(それをも「HTTP使用アプリ」と呼ぶなら、今時の大抵のソフトはネット経由で齎される(WindowsUpdateなんかもね)んで、以下略…)
まあDAWは(最も)極端な例なのですが、
要するに最近のAjaxだWebサービスだのの流行は、
本当に機敏な応答速度をひとまず諦めることで
成り立っているんです。
そこを(開発者が)忘れたらアカンと思っています。
>じゃあ一体何のプロトコルを使えば広い範囲になるの?
プロトコルというか「通信」を前提にする限り、
今の(主にハードの)技術レベルでは、
その速度の遅さに縛られます。
謳い文句の「新しい世代のアプリケーション」という奴が、
実のところ「介在プロトコル(というか通信層)に強依存してるために、古い(?)アプリより性能的にポンコツである」
のだとしたら、
これは由々しき問題であり、
Googleによるこの言い回しは、その問題の隠蔽です。
(ま、Web専業業者なGoogleなので、話半分に聞くってのが正解なのでしょうね)
Re:限定的なものの開発が容易になるだけ (スコア:1)
あなたがAsynchronousな挙動に耐えられるんだったら、どうにでもなるんじゃない?
Re:限定的なものの開発が容易になるだけ (スコア:1)
今の帯域とレスポンスでは実現は無理だと思うが、将来、
・サーバ上にあるトラックをネットで各地のユーザーと共有し
・他のユーザーの行った更新が、リアルタイムに目の前で反映される
ようなDAWシステムが出来たりしたら、ものすごく面白いと思う。
Synchronous(ユーザーが操作する→結果を待つ→また操作する、の繰り返し)から脱却し、
ユーザーの操作とは無関係に裏でいろいろやれるのが、Ajax のAたる所でしょう。
スプレッドシートをネットで共有し、他のユーザによる更新がリアルタイムに反映されるという、
数年前ならそんなの絶対無理って思うようなシステムをGoogleは作り出してきているわけで、
数年後にGoogleがAjaxなDAWを出してきても不思議じゃないと思うな。
Re:限定的なものの開発が容易になるだけ (スコア:0)
現状から考えるに、たとえ出てくるのが三日後だったとしても驚きませんよ、あたしゃ。
Re:限定的なものの開発が容易になるだけ (スコア:0)
>・他のユーザーの行った更新が、リアルタイムに目の前で反映される
いや、そうじゃなく、そういうのは既に有るんです。
前者は大昔のパソコン通信の時代にすらありました。
(パソコン通信機能つきシーケンサ「芸達者」などなど)
後者も思い出せませんがたしか有ったはず。
ついでにいえば3D CADにコラボレーション機能が
ついたものもありますよ。
ただ、それらは
●通信の粒度がもうちょっと大きい。それはAjaxというよりは単にアップロード/ダウンロード(チェックイン/アウト)を裏で行ってる、と呼ぶほうが適切だ。
●「通信機能つきの(
Re:限定的なものの開発が容易になるだけ (スコア:1, すばらしい洞察)
>全部のAPIを好き放題使える(つまり選べる)環境よりは
ふむ。それだけ限定的な対抗馬しかいないんじゃ、勉強する価値は充分あることになりますね。
>3Dデータとかも、かなりチャチなものに品質を落とせば
>最新の通信環境(つまり光とか)の上のHTTPでもまあ何とかなりますが、
>(少なくともまだ)その程度ですね。
>
>悔しかったらAjaxで
>DAW(MIDIシーケンスおよび音声データからなる音楽を「作成」するソフト)
>を作ってみろって(^^;
なんか言ってる事矛盾してません?
Webという広大な可能性を持つ技術をして「狭い」と言ったのに、自分で挙げる例は
数多いるパソコンユーザのうち極々狭い範囲しか使わなさそうなリアルタイムだの3Dだの作曲だの。
そんな狭い世界の事を学んでる暇があったらWebでどういうコンテンツが提供できるか学んだ方がずっと有益な気がするけど?
>プロトコルというか「通信」を前提にする限り、
>今の(主にハードの)技術レベルでは、
>その速度の遅さに縛られます。
>
>謳い文句の「新しい世代のアプリケーション」という奴が、
>実のところ「介在プロトコル(というか通信層)に強依存してるために、古い(?)アプリより性能的にポンコツである」
>のだとしたら、
>これは由々しき問題であり、
>Googleによるこの言い回しは、その問題の隠蔽です。
まあこれはGoogleとあなたとの哲学の違いだろう。
古いインフラで古い物をいい性能で動かす事に重きを置くか、
新しいインフラで新しい物を悪い性能でも動かす事に重きを置くか。
私にとって魅力的なのはどちらかと言えば後者ですね。インフラと人間の成長速度の差を考えると。
Re:限定的なものの開発が容易になるだけ (スコア:0)
はて?なんでこれが限定的なのでしょう?
HTTPしか使わない形態のほうが明らかに限定的でしょうに?
>Webという広大な可能性を持つ技術をして「狭い」と言った
Webのそういう意味での広さの話は、していないのですけど。
どれもこれも「レスポンス悪くて不味い」という意味では
同じだ(多様性など無い)、と言っているのです。
>極々狭い範囲しか使わなさそうなリアルタイムだの3Dだの作曲だの。
リアルタイムも3Dも音周りも、
普通に使うことから敢えて背を向けてるだけですね。
ムーアの法則により(?)計算機が数年で数十倍速くなってるハズなのに、
ユーザにその速さが一向に還元されず、
色々な
Re:限定的なものの開発が容易になるだけ (スコア:0)
強いてツッコむとしたら
>はて?なんでこれが限定的なのでしょう?
>HTTPしか使わない形態のほうが明らかに限定的でしょうに?
全く文脈読めてませんよ。
Re:限定的なものの開発が容易になるだけ (スコア:0)
いや、そちらこそ、なんですけど(^^;
HTTPにべったり依存な奴と、
依存する道具がHTTPとは限らない色々なものとで、
どっちが多様だと言うのでしょう?と
もともと訊いているのはこちらです。
「文脈が」というなら、
私の文脈を先に曲解したのは
恐らく貴方のほうなのでしょう。
>根拠レスどころかノン根拠な
ところで「レス」って言葉の意味知ってます?
単独で使えば「少ない」という意味ですが、
接尾語ならば「ない」という意味ですよ?
Re:限定的なものの開発が容易になるだけ (スコア:0)
> やっぱり一杯あります。
現時点では確かにそうですね。Ajax はある意味そのあたりを緩和するための仕組みのひとつなわけで。
ただ、それじゃローカルに300億を越えるWebサイトのインデックスを構築して瞬時に検索できる仕組みを持てるかとか、ローカルにほぼ全世界の地図や衛星画像を持てるかとか、ローカルに世の書籍のコンテンツを電子化して持てるか、と言う話をすれば、ローカルでは現時点で実現困難な機能もやっぱり一杯あるんです。
結局は「何をやりたいか」次第なだけであって、要求条件にあう人にとっては Google API は現実的な解として魅力的ですよ。少なくとも私にとっては。
Re:限定的なものの開発が容易になるだけ (スコア:0)
ええ。それはもちろんです。
で、だからこそ、
「新しい世代のアプリケーション開発がいかに容易で創造的か」
という売り文句は、
トートロジーでしか無いでしょう?と指摘しているのです。
彼らのやりたい(かつ、得意でやれる)事柄に特化したライブラリで、
彼らのやりたい方向性のプログラムを作る。
それで開発が容易じゃないんだったら、
ライブラリはただのドキュンです。
>要求条件にあう人にとっては Google API は現実的な解として魅力的ですよ。少なくとも私にと