2005-12-16

Evo Framework for TV Applications

Evo (Framework for TV Applications)のDemoを見た。

プレビューツールが非常に優れている(と思われる)点と、
動作が軽快な点、またcodeが平易で(一般的なhtmlとjavascriptで記述出来る)、
アニメーションすらサポートするのだから衝撃的だった。

良くFlashプレイヤをSTBに積みたがるむきは多いが、
実際問題としてベクターグラフィックスである必然もflvサポートの必然もないのであって、
トランスペアレンシーの表現と平易なアニメーション(スライド、スクロールなど)が動けば、
機能要件は満たせるなぁ、という思いもあった。

彼ら
は「創業の段階からTV向けGUIに必要な要件を考え抜いた」
と断言してくれた。
中々言えないセリフだなぁ。

逆にカナダの会社だけに、(といってもアクセス以外たいてい国外だけど)日本固有の事情、
地上波デジタル対応問題とか、CCに2バイト対応が必須、とかはあんまり考えてないのでは?
とかも気になる事態に。

試しにSDKで遊んでみたいものだ。

2005-12-15

XBox360売れ残り速報に見る温度差

タイトルのリンクの飛び先では、XBoxの売れ残りっぷりが話題になってます。

アメリカでもヨーロッパでも、発売当日にあっという間に売り切れたらしいのですが、
日本では初代の半分のペースでしか売れてないみたいです。

「さもありなん」な印象だけど、違和感バリバリみたい

naogym on tokyo: Mixi発・第6回WebSig会議

naogym on tokyo: Mixi発・第6回WebSig会議

2005-12-13

Mixi発・第6回WebSig会議

不覚にも、そんなんやってるなんて知らなかったッス。

今後は「データ」を文字列や画像でなく、データそのものとして扱える時代になる。

って記述があったけど、データ同士が通信するというかデータがデータを認識すること、
というのも突飛な考えじゃないよね?
構造を記述する言語が持っている構造を定義していれば、構造を記述することが出来たんだから、
データがデータを駆動するロジックを定義すれば、データはデータをよりよく表現出来るなぁ、と。

具体的にはカタチにしていかざるを得ないんだろうけど、
「パーペイシブ」というステキな言葉のおかげで発想にひとつのキーを持たせられたので、
どんどん進めそう。
落書きでも良いから一回全体像をカタチにしようかな。
プロトタイプづくりにもなりそうだから。

2005-12-09

移植

ひとまずmixi上に展開してるゴタゴタしたリサーチをこっちに引越ししようと決意。
現状すごく内容がグタグタになってきてる気もするけど、
読者のためにやる視点を重視する段階にはないと判断。

本当に意味のあるプロセスになった、と後から思いたいな。

blog検討

現状まだいろいろリサーチしてるけど、どんなblogが理想的なんだろ。
コメント求む!

2005-12-08

IPビデオオンデマンド技術と視聴者の多様化

シカゴ大学ロースクール教授(商法専攻)がコラム書くくらい、
メジャーな話になってきたみたいですな。
--
IPビデオオンデマンド技術と視聴者の多様化
Randal C. Picker
2005/12/07 15:30

 新しいメディアの技術革新がめまぐるしい速さで進んでいる。
どの技術が生き残り、どの技術が消えてゆくのだろうか。

 「新しいメディア」について語るときに大事なのは、
具体的にこの言葉が何を指すかを明確にすることだ。
テキストと静止画中心のオンラインメディアが登場して以来、
さまざまな形式の電子メディアが出現してきたが、
そのたびに「新しいメディア」という言葉が使われてきた。

 これからの新しいメディアの基盤となるのは、IPベースのビデオオンデマンド技術だろう。
これが普及すれば、視聴者にとって選択の幅が広がるだけでな く、
マイナーな番組を好む少数派の視聴者にも好みの番組を配信できるようになる。
大手テレビ局やケーブルネットワークが提供する
お仕着せの番組編成に飽き あきしていた視聴者には、
そうしたサービスが共感を呼ぶに違いない。

 テレビ業界は徐々にオンデマンド技術の導入を始めている。
CBSはこの秋、24時間放映のニュースチャンネルに対抗して、
ウェブ上で新しいコンテンツの 提供を開始すると発表した。
また、Starzはオンラインの映画ダウンロードサービスを開始しており、
Comcastも視聴者が見たいコンテンツを見たい ときに提供するための
独自のオンデマンド機能を構築している。

 オンラインの音楽配信サービスでは、
聴かない曲まで入っているCDをまるごと購入するのではなく、
聴きたい曲だけを個別に買うという傾向が強まってい る。
ウェブコンテンツの世界で起こりつつある改革の中心に据えられているのも、
こうしたきめ細かな選択肢を消費者に提供することだ。
テレビの場合、既成の 番組表から脱却することが目標だ。

 確かに、TiVOなどのデジタルビデオレコーダーによって、
視聴者は番組の放映時間に縛られなくなったが、これはほんの始まりに過ぎない。
さらなる改革 は始まっており、ゆくゆくはデスクトップやノートPCなど、
視聴者が見たい場所に番組が配信されるようになるだろう。
帯域幅の増加に伴い、新世代のIP ベースのシステムは、地上波、衛星放送、
Hybrid Fiber Coaxial(HFC。IPの転送が可能)といった既存のメディアを越えて、
より広範なコンテンツの配信を提供するようになるだろう。

 IP関連の技術革新の多くは、オープンソースコミュニティによってもたらされるだろう。
急成長するIPビデオオンデマンド市場の発展は、
より広範なソリューションを探ることに労を惜しまない多くの開発者たちによって加速されることになる。

 IP自体もオープンなインフラである。そのため、IPを利用すれば、
ウェブまたは今後登場するウェブベースのコンテンツスキームを経由して、
どのコンテ ンツプロバイダへもアクセスを提供できる。
オープンソースは反体制的なプログラマのつくる
小規模なコミュニティだけに受け入れられているわけではない。
大 企業も、オープンソースの持つサービス的な側面を採り入れ、
そうしたアプリケーションを開発するコミュニティを活用している。

 オープンソースコミュニティによって開発される
多くのメディア配信アプリケーション(各種のツール、支払い処理、ユーザーインターフェース、
コミュニティプラットフォーム)が、テクノロジー企業やメディア企業によってサポートされ、
視聴者に利用されるようになるだろう。

 IPビデオオンデマンド技術の普及を促すトレンドがいくつかある。

 まず、従来のHFCや衛星放送と違って、IPベースのシステムは、ほぼ無制限に規模を拡張できる。
極めてニッチなコンテンツにアクセスする視聴者もいる ため、こうしたスケーラビリティは欠かせない。
膨大なコンテンツがさまざまな形式で存在することを考えると、IPに移行するのが必然である。
どう見てもご く一部の人しか興味を持たないようなコンテンツを提供するには、
ほぼ無制限の能力が必要になる。
それができないとなると、ごく限られた人しか見ないような コンテンツを配信するために、
専用線や専用チャネルを用意することになるが、勿論それでは採算が合わない。

 視聴者は、テレビ局の番組編成者やメディア企業から
一方的に送られてくるコンテンツにへきえきしている。
投資家は、そんな飢えた視聴者からの爆発的な需 要に対応するための準備を進めている。
それでも、大半の視聴者が求める高品質のコンテンツは、
その8割が従来のメディア企業によって制作されるだろう。
視 聴者は、単にコンテンツを選べるというだけでなく、
コンテンツの視聴時間と視聴方法も選択できるようになることを望んでいる。
これからは、従来の押しつけ 型の番組提供ではなく、
ユーザーが主導権を握る必要があることを認める必要があるだろう。
さもないと、メディア企業は視聴者を失うことになりかねない。

 テレビには、かつてないほどさまざまな入力機器が繋がるようになっている。
ホームエンターテイメントハブとしてのテレビに、
さまざまなデジタル/アナロ グ機器が接続されるようになったからだ。
こうした仕組みは、MoCA(Multimedia over Coax Alliance)といった団体の取り組みによって
標準化が進められている。
MoCAの目標は、各種機器をより迅速に市場に流通させることだ。
視聴者が好 みのコンテンツをダウンロードして、携帯端末や携帯電話、ノートPC、デスクトップ、
さらには次世代の家庭および個人向け家電製品などで観ることを可能に する新しい技術が、
年末に向けて次々と登場することだろう。

 クリエイティブなコンテンツ制作者は自分の映画を高品位で提供したがる。
テレビ局のHBOやWarner Brothersも自社の番組が一定以上の品質で配信されることを要求する。
コンテンツプロバイダは、
従来のクローズドな環境からIPベースのオープンな 環境へと移行していくなかで、
テクノロジー企業と提携しながら、高品質な番組を視聴者に届ける必要がある。
高品位コンテンツをPCに配信することに特化す る企業は、視聴機器に関係なく、
コンテンツが一定の品質で提供されることを保証しなければならない。

 まだ、解決しなければならない問題は多いが、業界が取り組み方を間違えなければ、
視聴者とコンテンツプロバイダは、エキサイティングかつ革新的な新しい方法で
メディアを利用するようになるだろう。

著者紹介
Randal C. Picker
シカゴ大学ロースクール教授(商法専攻)
--
あんまり自分の考えがズレたもんでもないということが確認できたカンジがするけど、
かと言っていまだに「これから」のモノとして語られてる感は否めないね。

「業界が取り組み方を間違えなければ」
の箇所が胸に響くけど、ビジネスとして成立するorしないも、
まだまだこれからなのかも知れない。確かに。

準備を怠らないようにしなければ、ね。

MP3tunes Locker:容量無制限・iTunes互換の音楽ストレージサービス

トンでもないモノがあらわれたみたい。
--
MP3tunes Locker:

容量無制限・iTunes互換の音楽ストレージサービス

mp3tunes.comから、ローカルにある音楽ライブラリを容量無制限でオンラインにバックアップ、
どのコンピュータからでもライブラリにアクセスで きるほか、
他のPCのローカルHDDに1クリックで同期も可能という音楽ロッカーサービスが登場。
iTunes用のプラグインも提供され、
iTunesの ライブラリをすべてオンラインストレージに同期することも可能。
なんとDRMつきファイルも扱える。
--
ななな、なんちゅう事だろう。

早速、使ってみようかと。

火傷

家内が火傷した。
(ちなみにこの呼称は大嫌いなのだが、他に適切な表現を知らない。)

利き手を少々、といった風情だが実際の面積がたいしたことなくても
痛みや皮膚の引きつりは結構大変らしく家事に支障をきたしている。

明日の朝食は私が作る事になりそうだ。
大げさな準備をして贅沢な素材を使えば「料理でござい」と言えても、
限られた材料で時間もなく、起き抜けで血圧もあがらないタイミングに
手際よくおいしい朝食をつくるというのはかなりのモノだと感心する。

ほんの少しだけでも自分の普段やらない事をやるべく、
その事柄を自分自身の問題として捉えた時、
突然まったく違う視点を獲得する事が往々にしてある。

ささいなきっかけだが、あらためて日々2人の息子を育て、
家庭を守ってくれている彼女に感謝の気持ちをあらわしたい。

いつもありがとう。

2005-12-07

Google:Ten Golden Rules-10の黄金律

Newsweek最新号 (Issues 2006)に、
Eric Schmidt(グーグルCEO)と
Hal Varian(バークレー校教授兼グーグル社コンサルタント)による
「グーグル、10の黄金律」("Google:Ten Golden Rule")が掲載されている。
これは日本語版をB3 Annex抄訳として掲載されていた物の引用
(一部は私が修正。)
原文も併せて掲載。

--
抄訳
---

・採用は委員会方式で

グーグルで採用面接を受ける人はすべて、
少なくとも6人以上の管理者あるいは将来の同僚との面接を行う。
すべての人々の意見が大切であり、このことで、採用のプロセスがより公平になり、
採用基準の向上にもつながる。
もちろん、それだけ時間がかかることになるが、その価値はあると思っている。
すばらしい人材を雇い、その人を次なる採用のプロセスに集中的に組み込むと、
さらにすばらしい人材を雇うことにつながる。

・必要なものはすべてを供給せよ

私たちは、標準的な(有給休暇、健康保険などの)付加給付を提供しているが、
それに加えて、ファーストクラスな食事施設、ジム、洗濯室、マッサージ室、床屋、洗車設備、
クリーニング、通勤用バスなど、ハードワーカーなエンジニアなら、
ほしいであろうものをほとんどすべて提供している。
結局、プログラマーはプログラムを書きたいのであって、洗濯物を洗濯したいわけではないのだ。

・一カ所につめこめ

グーグルにおけるほとんどすべてのプロジェクトは、チームプロジェクトであり、
チームというものは、コミュニケーションをとる必要がある。
コミュニケーションを円滑にするもっともいい方法は、
チームメンバーをお互いに数フィートの間隔においてしまうことだ。
結果的に、グーグルのほぼすべての人々がオフィスを共有することになる。

・協力を容易にする環境を作り出せ

すべてのチームメンバーがお互いの数フィートという近くにいるため、
プロジェクトを調整することは比較的容易である。
物理的に近くにいることに加え、グーグル社員は、週に一度、
先週1週間になにをしたかを説明したメモを自分のワークグループにメールで送ることになっている。
これによって、簡単に、誰が何に取り組んでいるかがわかり、進捗管理や、
ワークフローをシンクロさせることが容易になる。

・自社製品を自分でも使え

グーグル社員は、会社のツールを徹底的に使う。
ウエブはもちろん、すべてのプロジェクトやタスクについての社内向けウエブを使う。
すべては、インデックスされており、必要に応じてプロジェクト参加者が利用できるようになっている。
GMail の成功は、ひとつには、社内で何ヶ月もベータテストされていたことにある。
社内でのメール使用は、極めてクリティカルな活動であり、GMailは結果として、
もっとも厳しい要求を突きつけるグーグル社のナレッジワーカーを満足させるべく、
チューンされていったのである。

・クリエイティビティを奨励せよ

グーグルのエンジニアは、自分の就業時間の20%を自分の好きなプロジェクトに費やすことができる。
私たちの秘密というほどではない、もう一つの秘密兵器は、社内のアイディアメーリングリストである。
この会社横断的なサジェッション箱には、駐車場の手順から、
次のキラーアプリのアイディアまでさまざまなアイディアを投稿できる。

・コンセンサスに至るように努めよ

グーグルでは、唯一判断を下す者を英雄視するのではなく、
「多数は少数より賢い」というスタンスに立つ。
どんな判断を下そうとも、その前に、広い視点をつねに求める。
グーグルでは、マネージャの役割は、専制的に決断を下すのではなく、
さまざまな視点を集めることにある。

・「悪魔」になることなかれ

このグーグルのスローガンについては、いろいろ書かれてきたが、
私たちは、本気でこれを実践しようとしている。特に、マネージメント層ではそうである。
どこの組織でもそうだが、人々は自分の物の見方というものに熱狂しがちである。
しかし、ほかのよく知られたハイテク企業のマネージメントスタイルとは違って、
グーグルでは、誰もイスを投げない。
寛容とリスペクトが育まれる環境を作りあげたいのであって、イエスマンだらけにしたいわけではない。

・データが判断をもたらす

グーグルでは、ほとんどの判断というのは、量的分析に基づいている。
私たちは、インターネット上の情報だけでなく、社内の情報をも管理するシステムを作り上げている。
私たちは、多くのアナリストを抱えており、彼らが業績を解析し、トレンドを描くことで、
会社を可能な限りアップトゥデートに保つことができる。

・効果的にコミュニケーションを取ること

毎週金曜日、全社員参加の会を設けている。
ここでは、発表が行われたり、紹介や、質疑応答なども行われる。こうしたことにより、
マネジメントサイドがナレッジワーカーがいま何を考えているかがわかり、逆もまたしかりである。

Google: Ten Golden Rules - Issues 2006 - MSNBC.com
---
以上が10の黄金律である。
グーグルだけがこの黄金律に従っている会社ではなく、
シリコンバレー界隈では、けっこう実践されているそうである。
黄金律以外の後半コメントは割愛。

「ナレッジワーカー」をどう扱ったらいいか、
に非常に配慮がなされている。
合理性を持った意思決定と、民主的・協調的な風土を作り出すこと、
理に適った、気持ちよく働ける「文化」を生み出すことを、
議論し、考え抜き、そして「アップデートしていく」ことがもっとも大事なのだ、
との理念を感じた。

自分より優れた人材を受け入れること、
また英雄を望むのではなく、よりたくさんの知恵を結集させて進む事。

これは非常に大切なことだと思う。
いわゆる「衆愚」にならないための方策も、あわせて考えての事だろう。
--
原文
---
Google: Ten Golden Rules

Getting the most out of knowledge workers will be the key to business success
for the next quarter century.
Here's how we do it at google.

By Eric Schmidt and Hal Varian
Newsweek
Updated: 11:33 a.m. ET Dec. 2, 2005

Issues 2006 - At google, we think business guru Peter Drucker well understood
how to manage the new breed of "knowledge workers."
After all, Drucker invented the term in 1959.
He says knowledge workers believe they are paid to be effective, not to work 9 to 5,
and that smart businesses will "strip away everything
that gets in their knowledge workers' way.
" Those that succeed will attract the best performers,
securing "the single biggest factor for competitive advantage in the next 25 years."

At Google, we seek that advantage.
The ongoing debate about whether big corporations are mismanaging
knowledge workers is one we take very seriously,
because those who don't get it right will be gone.
We've drawn on good ideas we've seen elsewhere and come up with a few of our own.
What follows are seven key principles we use to make knowledge workers most effective.
As in most technology companies, many of our employees are engineers,
so we will focus on that particular group,
but many of the policies apply to all sorts of knowledge workers.

* Hire by committee.

Virtually every person who interviews at Google talks to at least half-a-dozen interviewers,
drawn from both management and potential colleagues.
Everyone's opinion counts, making the hiring process more fair and pushing standards higher.
Yes, it takes longer, but we think it's worth it.
If you hire great people and involve them intensively in the hiring process,
you'll get more great people.
We started building this positive feedback loop when the company was founded,
and it has had a huge payoff.

* Cater to their every need.

As Drucker says, the goal is to "strip away everything that gets in their way.
" We provide a standard package of fringe benefits,
but on top of that are first-class dining facilities, gyms, laundry rooms, massage rooms,
haircuts, carwashes, dry cleaning, commuting buses—just about anything
a hardworking engineer might want.
Let's face it: programmers want to program, they don't want to do their laundry.
So we make it easy for them to do both.

* Pack them in.

Almost every project at Google is a team project, and teams have to communicate.
The best way to make communication easy is to put team members
within a few feet of each other.
The result is that virtually everyone at Google shares an office.
This way, when a programmer needs to confer with a colleague,
there is immediate access: no telephone tag, no e-mail delay, no waiting for a reply.
Of course, there are many conference rooms that people can use for detailed discussion
so that they don't disturb their office mates.
Even the CEO shared an office at Google for several months after he arrived.
Sitting next to a knowledgeable employee was an incredibly effective educational experience.

* Make coordination easy.

Because all members of a team are within a few feet of one another,
it is relatively easy to coordinate projects. In addition to physical proximity,
each Googler e-mails a snippet once a week to his work group describing
what he has done in the last week.
This gives everyone an easy way to track what everyone else is up to,
making it much easier to monitor progress and synchronize work flow.

* Eat your own dog food.

Google workers use the company's tools intensively.
The most obvious tool is the Web,
with an internal Web page for virtually every project and every task.
They are all indexed and available to project participants on an as-needed basis.
We also make extensive use of other information-management tools,
some of which are eventually rolled out as products.
For example, one of the reasons for Gmail's success is
that it was beta tested within the company for many months.
The use of e-mail is critical within the organization,
so Gmail had to be tuned to satisfy the needs of some of our most demanding customers
—our knowledge workers.

* Encourage creativity.

Google engineers can spend up to 20 percent of their time on a project of their choice.
There is, of course, an approval process and some oversight,
but basically we want to allow creative people to be creative.
One of our not-so-secret weapons is
our ideas mailing list: a companywide suggestion box where people can post ideas
ranging from parking procedures to the next killer app.
The software allows for everyone to comment on and rate ideas,
permitting the best ideas to percolate to the top.

* Strive to reach consensus.

Modern corporate mythology has the unique decision maker as hero.
We adhere to the view that the "many are smarter than the few,"
and solicit a broad base of views before reaching any decision.
At Google, the role of the manager is that of an aggregator of viewpoints,
not the dictator of decisions. Building a consensus sometimes takes longer,
but always produces a more committed team and better decisions.

* Don't be evil.

Much has been written about Google's slogan, but we really try to live by it,
particularly in the ranks of management.
As in every organization, people are passionate about their views.
But nobody throws chairs at Google,
unlike management practices used at some other well-known technology companies.
We foster to create an atmosphere of tolerance and respect, not a company full of yes men.

* Data drive decisions.

At Google, almost every decision is based on quantitative analysis.
We've built systems to manage information, not only on the Internet at large, but also internally.
We have dozens of analysts who plow through the data,
analyze performance metrics and plot trends to keep us as up to date as possible.
We have a raft of online "dashboards" for every business we work in that provide up-to-the-minute snapshots of where we are.

* Communicate effectively.

Every Friday we have an all-hands assembly with announcements,
introductions and questions and answers. (Oh, yes, and some food and drink.)
This allows management to stay in touch with
what our knowledge workers are thinking and vice versa.
Google has remarkably broad dissemination of information within the organization and remarkably few serious leaks.
Contrary to what some might think, we believe it is the first fact
that causes the second: a trusted work force is a loyal work force.

Of course, we're not the only company that follows these practices.
Many of them are common around Silicon Valley.
And we recognize that our management techniques have to evolve as the company grows.
There are several problems that we (and other companies like us) face.

One is "techno arrogance."
Engineers are competitive by nature and they have low tolerance for those who aren't as
driven or as knowledgeable as they are.
But almost all engineering projects are team projects; having a smart but inflexible person
on a team can be deadly.
If we see a recommendation that says "smartest person I've ever known" combined with
"I wouldn't ever want to work with them again," we decline to make them an offer.
One reason for extensive peer interviews is to make sure that teams are enthused about the new team member. Many of our best people are terrific role models in terms of team building, and we want to keep it that way.

A related problem is the not-invented-here syndrome. A good engineer is always convinced
that he can build a better system than the existing ones,
leading to the refrain "Don't buy it, build it." Well, they may be right,
but we have to focus on those projects with the biggest payoff.
Sometimes this means going outside the company for products and services.

Another issue that we will face in the coming years is the maturation of the company, the industry and our work force. We, along with other firms in this industry, are in a rapid growth stage now, but that won't go on forever. Some of our new workers are fresh out of college; others have families and extensive job experience. Their interests and needs are different. We need to provide benefits and a work environment that will be attractive to all ages.

A final issue is making sure that as Google grows, communication procedures keep pace with our increasing scale. The Friday meetings are great for the Mountain View team, but Google is now a global organization.

We have focused on managing creativity and innovation, but that's not the only thing that matters at Google. We also have to manage day-to-day operations, and it's not an easy task. We are building technology infrastructure that is dramatically larger, more complex and more demanding than anything that has been built in history. Those who plan, implement and maintain these systems, which are growing to meet a constantly rising set of demands, have to have strong incentives, too. At Google, operations are not just an afterthought: they are critical to the company's success, and we want to have just as much effort and creativity in this domain as in new product development.

Schmidt is CEO of Google. Varian is a Berkeley professor and consultant with Google.

2005-12-05

肺炎

肺炎で倒れてました。
マイコプラズマとかそういうんじゃなくて、シンプルに肺炎。

現実はけっこうアドリブ効かないね。

Palo Altoから水道橋

貼り付けてたMapをデフォ位置から水道橋の職場付近に変えてみました。
表示されてる地図が大体私の今いるロケーション、という事にしようかなと思ってます。

2005-11-29

mixi

mixiにも棲息しています。
人間って難しいモンですね。

空です。


DSCF1099
Originally uploaded by naotakegymnasium.
FlickrからBlog thisしてみました。長男です。
僕は肺炎になってしまって久々に自宅で療養中…

2005-11-22

クリスマス準備

今年もクリスマスがやってきます。
気の早い話?かも知れないですが、
オシゴトジョウのクリスマス準備は明日でケリをつけないとマズいみたいです…

2005-11-21

Ajaxの定義

上記リンクから引用させていただきました。

--
Ajax(Asynchronous JavaScript + XML、非同期なJavascriptとXMLの連携)
は単一の技術ではなく、複合的な技術の呼称である。

・XHTMLとCSSによる基本レイアウト
・Documentオブジェクトを使用した、ページの動的変更
・XML,XSLTを使用したデータのやりとりや制御
・XMLHttpRequestを用いた動的なデータ検索
・JavaScriptによる上記技術の統合

従来のアプリの問題点は、全ての動作がhttpリクエストを送り、
毎回サーバーサイドでデータを成形しなおさなければならなかった。
その為にユーザーは処理毎に待たされることとなる。
一度ユーザーインターフェースをロードしてしまえば、
処理毎にサーバーと通信する必要はないのではないか?
というのがAjaxの基本的な考え方となる。


Ajaxはどのように異なるか

Ajaxのコンセプトでは、ユーザーとサーバーの間に中間層となるAjaxエンジンを置く。
初回のセッションでは、ウェブページをロードする代わりに Ajaxエンジンを読み込む
(これは通常隠しフレームに読み込まれる)。
Ajaxエンジンは、レンダリングとインターフェースの制御を担当し、
ページとは非同期にデータをサーバーから読み出す。
これによりサーバの処理待ちで、画面が真っ白の状態で待たされることはない。

ユーザーの全てのアクションはhttpを直接呼び出すのではなく、
JavaScriptによってAjaxエンジンを呼び出す。
DataValidation等のサーバーが必要としない処理はAjaxエンジンが自ら行い、
外部のデータや追加のコードをを必要とするときのみサーバーとの通信を行う
(主としてXMLが用いられる)。


誰が使っているのか

google社が巨大な投資を行っている。
orkut, gmail, google suggest, google maps, flicker etc...
これらは、Ajaxが技術的なデモではなく実用的なものであることを証明している。
google suggestのような単機能から、google mapのような巨大なものまで、適用範囲は多岐にわたる。Ajaxはまだ初期段階であり、その可能性は拡大中である。
今後多くの組織がgoogleの示す方向性に従うだろう。


進歩

Ajaxの用いる技術自体は成熟した技術である。
Ajaxの最大の挑戦は、デザイナーがwebアプリの限界を忘れ、
より大きな可能性を想像することである。
--

ユーザとサーバの中間層に置く「何か」が結構とんでもない利便性を生みそう。
一度ユーザーインターフェースをロードしてしまえば、
処理毎にサーバーと通信する必要はないのではないか?という出発点に
忠実でありさえすれば、厳密に要件を満たしていなくても、
Ajax的なアプローチは取れる、という事を私のチームが実証してくれた。

必要は発明の母、とはよくいったものだけど、ちょっと面白い。

Ajax

訳出はないモノと思ってましたが、発見したので

2005-11-18

Inter BEE

Inter BEE、今年も行ってきました。

期待したほどH.264まわりの機材に進歩がみられずがっかりです。
MPEG2もローンチしてからマトモになるまでに結構時間がかかったので、
さもありなん、ではあるのですが。

実際問題今回見た中で一番評価に値するな、と感じたのはModulus Video のエンコーダ。
2005の4thクウォータに発売、ってもうあんま時間ないよね、とか話をしながら。

2005-11-17

マイミクマップ考察

マイミクマップなるものが公開されているのですが、
Authentication/Identity for Mashups
で考察されてます。

web 2.0を勉強しはじめたばかりの私には格好のネタです。

2005-11-15

Google Analytics

Google Analyticsはじめました。
トラッキングコードをとりあえず埋め込んでみたんだけど…
まだアクセスも何もない過疎地なんで、意味は微妙です。

2005-10-05

Maps

Google MapsのAPI、使い方わかんねーよー

と泣き言ばかりも何なので、きちんとDocument読む事に。

Project Management Utopia

"Project Management Utopia"
というキャッチにすでに脳天をやられてしまった方は是非URLへ。

彼らのマニフェストにも共感を覚えるでしょう。

We believe Project Management is Communication
との訴えには、まさに賛同します。

Communicationの多様化がそれ自体に割く時間の増大を招き、
拒否も否定も出来ない現代、
自分がなすべき事を行えているのか、
自分が何にプライオリティをおいているのか、
見えにくく、とかく迷子になり勝ちなのではないでしょうか?

自分自身、自己管理とともにプロジェクトを俯瞰すべくはじめました。
http://naotakegymnasium.updatelog.com/login
ナオタケギムナジウム的、なプロジェクトは全てここで扱います。

単純にBaseCampが気になる場合にもお知らせ下さい。