2006年4月22日土曜日

Yahoo!WidgetEngineReference-[Flat-File Format]

Flat-File Format

Starting in version 3.1, the engine supports a flat-file format which is not zip. The zip solution not only had performance issues (particularly in 3.0, where we started looking for Widget metadata), but also caused some grief on several other fronts.
バージョン3.1から、エンジンはZIPアーカイブ以外にフラットファイルフォーマットをサポートするようになった。ZIPアーカイブはパフォーマンス上の問題点を抱えていた(特にウィジェットメタデータのサポートを開始したバージョン3.0で顕著)ばかりでなく、その他のいくつかの点で問題を引き起こしていた。

This new format is at present not compressed, so the size of a Widget will be larger in this format than in the zip format. However, since images take up most of a Widget's size, the increase is about 10-15% on average since images are normally already in a compressed format (PNG, JPG) whereas the text files are not. The files aren't compressed on purpose — this way we can file-map the file and not have to bring everything into RAM to use it until it's truly needed.
この新しいフォーマットは現在のところ圧縮されていないため、このフォーマットでのウィジェットのサイズはZIPフォーマットでのサイズより大きくなっている。しかし、ウィジェットのサイズのほとんどは画像で占められており、画像は通常圧縮フォーマット(PNG,JPG)で用いられるため、全体の増加率はおよそ10%から15%程度にとどまっている。ファイル群を圧縮しないことで、本当は必要でないにもかかわらずすべてのファイルをRAM上に展開するようなことを避けることができる。

As a result of this new format, Widgets launch much faster in 3.1 than they did in 3.0. To use this new format, you must use the Converter command-line tool. As of this
writing the old "Widget Converter" Widget had not been reworked to use the tool.
この新しいフォーマットを採用した結果、3.1におけるウィジェットの起動速度は3.0に比べてかなり速くなった。新しいフォーマットを使うためには、Converterコマンドラインツールを使う必要がある。このため、古い"Widget Converter"ウィジェットについての記述は更新されていない。

Because your Widget is a flat file, you cannot use items such as dlls that you might have packaged with your Widget unless you use a new API (widget.extractFile()) to
extract the file out of your flat-file Widget into a location in the filesystem.

ウィジェットがフラットファイルなので、フラットファイルウィジェットからファイルシステム上にファイルを取り出すための新しいAPI(widget.extractFile())を使わない限り、今までウィジェット内にパッケージングしていた(かもしれない)dllのようなファイルを使うことはできない。

Sound files played through the play() function however will work without any changes.
なお、play()関数で再生される音声ファイルは一切の変更を加えることなく正常に動作する。

Yahoo!WidgetEngineReference-[Widget Packaging]

Widget Packaging

On Windows the files that make up a Widget are stored in a .widget file. This is a standard ZIP file that has had its extension changed to .widget.
WindowsOSでは、ウィジェットを構成するファイル群は".widget"のファイル内に格納される。このファイルは、標準的なZIP形式のファイルの拡張子を".widget"に変更したものである。

On Mac OS X the files are packaged together in a bundle, which is a directory that is treated as a single unit by the operating system. You can control-click on one of the default Widgets and choose the Show Package Contents option to see this structure in use.
Mac OS Xでは、ファイル群はOSによってひとつの構成単位として扱われるディレクトリの中にまとめられる。標準で付属しているウィジェットをCtrlを押しながらクリックし、"パッケージの中身を表示する(?Mac持ってません)"のオプションを選択すると、内部構造を見ることができる。

Both the Mac OS X and Windows versions of the engine can read the zipped up .widget files, so it is the best choice when doing cross-platform Widgets. There is a utility available on the Yahoo! Widgets web site (in Workshop) which can assist you in building or taking apart these .widget bundles called Widget Converter.
Mac OS XとWindowsの両方のバージョンのエンジンで、ZIPアーカイブされた".widget"ファイルを読み取る(実行する)ことができる。よって、クロスプラットフォーム(Mac OS XでもWindowsでも動作する)ウィジェットを作成する場合には、ZIPアーカイブするのがベストな選択だろう。Yahoo! Widgetsウェブサイト(のWorkshop内)では、Widget構成ファイルを".widget"ファイルにアーカイブ化するための、Widget Converterと呼ばれるユーティリティをダウンロードできる。

Whether on Windows or Mac OS X .widget bundle has the following structure:
WindowsでもMac OS Xでも、".widget"アーカイブは以下のような構造になっている。

myWidget.widget
Contents
myWidget.kon
Resources


The .kon file contains the actual Widget code (similar to the sample Widget in the section above). At present, the .kon file must be contained in a folder called Contents.
".kon"ファイルは実際のウィジェットのプログラムコード(これまでのセクションで出てきたサンプルウィジェットに似ている)を含んでいる。現在のところ、".kon"ファイルは"Contents"という名前のフォルダ内に保存しなければならない。

You can put resources like pictures, etc. anywhere you like, but typically they would be put into a Resources folder, as shown above.
画像などのリソースファイルは好きな場所に配置することができるが、上記の例でも挙げたように"Resources"という名前のフォルダに配置するのが普通だろう。

If you do not use the Widget Converter Widget and instead decide to zip these up manually, this is best done on a PC by right clicking the .widget folder and creating a ZIP file from that. On the Mac you can use something like DropZip.
もしWidget Converterを使わずに手動でZIPアーカイブ化する場合、PC上で.widgetフォルダを右クリックし、ZIPファイルを作成するのがベストだ。Macでは、DropZipを使うのが良いだろう。

It should be noted that while you are developing your Widget, you do not need to create a zipped up Widget file to test each time you make a change. You can merely double-click the .kon file.
ウィジェットを開発している際に注意すべき点は、何かファイルを変更してテストする際に、毎回ウィジェットファイル群をアーカイブ化する必要はないということだ。単に".kon"ファイルをダブルクリックすればよい。

You should never modify your Widget package at run time. That is, do not use your Widget package to store information inside of itself. While most Widgets use preferences to store their settings, there are some Widgets that have instead stored information inside its own package. With the advent of our zipped format, this has proven to be somewhat fruitless.
実行中には、決してウィジェットパッケージのファイルを修正してはならない。これはつまり、ウィジェット自体が使用する情報をウィジェット内部に保存して はならないということだ。ほとんどのウィジェットが自分自身の設定をPreferences(レジストリか…?)に保存しているが、パッケージ内に保存しているウィジェットも少数ながら存在する。ZIP化されたフォーマットの進化版では、もう少しマシな手段が用意されている。

When the Widget Engine runs a zipped Widget, it first unzips it into a special location and then runs it from there. In recent releases, this unzipping happens every time you run the Widget, so if you stored information in your package, it will be lost. To help accommodate Widgets that need to store permanent data, there is a system.widgetDataFolder folder path you can use to store your
Widget's permanent info.
ウィジェットエンジンがZIP化されたウィジェットを実行する際、まず最初にZIPアーカイブを特定の場所に解凍し、解凍されたファイルを元にウィジェットを起動する。最近のリリースでは、このZIPアーカイブの解凍作業はウィジェットの起動ごとに実行されるので、パッケージ内に保存した情報は失われてしまうだろう。永続化データを必要とするようなウィジェットを作るためには"system.widgetDataFolder"というフォルダパスが用意されており、そこにウィジェットの永続化情報を格納できるようになっている。

Yahoo!WidgetEngineReference-[File Paths]

File Paths

File paths in the engine are always relative to the location of the XML file. That means a file reference without a directory (e.g. main.js) will be looked for in the same directory as the XML file while one with a directory (e.g. javascript/main.js) will be looked for in the specified subdirectory of the directory the XML file resides in. It is not advised to use absolute paths (ones that begin with a /) since the disk layout of people's machines can differ quite markedly.
エンジンでのファイルパスは、常にXMLファイルからの相対パスとして扱われる。これにより、ディレクトリ指定のないファイル参照(例:"main.js")ではXMLファイルと同じディレクトリ内が検索される。一方、ディレクトリ指定ありのファイル参照(例"javascript/main.js")では、XMLファイルが存在するディレクトリ内の、指定されたサブディレクトリ内が検索される。なお、絶対パスは使わないことをおすすめする。これは、ウィジェットを使う人のマシンのディスクレイアウトはそれぞれにかなり違っているからだ。

グーグル、ウィジェット作成ツール「Google Homepage API」を公開 - CNET Japan

グーグル、ウィジェット作成ツール「Google Homepage API」を公開 - CNET Japan: "Google Homepage API"

Google Homepage API

知らなかった、こんなのがあるなんて…でもまぁ、これはGoogleパーソナライズドホーム上で動作するポートレットを作るためのAPIらしい。ま、ないよりいいんだけど…Googleのパーソナライズドホームもお世辞にも使いやすいとは言えないからな。標準で用意されているのがRSSリーダーと階層分け出来ないブックマーク機能だけじゃあね。
興味があればさわってみてもいいかな。日本でも使えるんだろうか?

Yahoo!WidgetEngineReference-[Strict Mode]

Strict Mode

In version 2.1 and later, you can put the XML parser into a 'strict' mode. This means it enforces the rules of XML in ways the parser did not in the past. In fact, it was much too lenient in many ways. To enable this, you can just add the following line to the top of your XML file:
バージョン2.1以降では、XMLパーザーを"Strict"(厳密な)モードで動作させることができる。このモードで動作させることにより、パーザーがXMLの解析ルールに厳密に従うよう強制することができる。実際今まで、パーザーは期待したほど厳密にXMLの解析ルールに従ってはいなかった。Strictモードで動作させるためには、XMLファイルの1行目に

<?konfabulator xml-strict="true"?>

と記述すれば良い。

In strict mode, the following things are enforced:
Strictモードでは、以下の5つの点が強制されるようになる。

1) All attribute values must be put into quotes.
1) すべての属性値は、クォートで囲まれなければならない。

2) No stray "&" characters are allowed in a normal text section (i.e.use &amp;amp;).
2) 通常のテキストセクション内に単独で"&"が現れてはならない。(&amp;を用いる必要がある)

3) Entities (things that start with "&") are evaluated inside attribute values.
3) エンティティ("&"ではじまる文字列)は、属性値の中でも評価される。

4) No double dash ("--") allowed inside a comment. For this reason, it's best to put code
into CDATA blocks.
4) コメント内で、"--"が現れてはならない。この制約により、JavaScriptコードはCDATAブロック内に書くのがベストとなる。

5) If an external file is included, we do not replace entities such as < in that file.
5) 外部ファイルがIncludeされている場合、そのファイル内の&lt;のようなエンティティを置き換えない。

CDATA blocks are available in version 2.1 or later.
CDATAブロックは、バージョン2.1以降でのみ使用可能だ。

2006年4月21日金曜日

森羅万象には正解はない : ITpro Watcher

森羅万象には正解はない : ITpro Watcher

とりあえず、メモ。自分の仕事の進め方を客観的に見るのに役立つし、自分への戒めにもなる。同じような文章を何回も目にするけど、忘れがちなことだけにありがたい。

2006年4月20日木曜日

業況が改善しても事業規模を拡大しないITサービス会社の決意とは : ITpro Watcher

業況が改善しても事業規模を拡大しないITサービス会社の決意とは : ITpro Watcher

"現在"の単なる延長ではどうにもならない、ということを再認識してしまう記事。自分の勤めている会社は、大量採用とM&Aで規模を拡大しつづけている。自分の会社が見ているものとは違う、何を見ているんだろう?SIに未来はない…"今のままでは"。今の、どういう点を問題視しているんだろう?目指している未来はどんなものなんだろう?"派遣"をやめて、"パッケージ販売"に切り替えるのは今、と言っていることから、グローバルな競争力がなく、今後の成長を期待できないことを問題視しているのだろうか。
SIに未来がないとして、SIを捨ててパッケージ販売に切り替えるという道があるとして、それ以外の道はないんだろうか?自由貿易が行われるようになると、比較劣位の産業は衰退するそうだ。SIは、インドや中国に比べると比較劣位なのだろうか…?熟練工ではないのだろうか。SIでの熟練工というのはいったいなんだろう?

2006年4月19日水曜日

Yahoo!WidgetEngineReference-[JavaScript]

JavaScript

Because the XML engine looks for the <> symbols to mark blocks of XML data,
our JavaScript engine needs to have these symbols replaced with < and >
respectively. For example:
XMLエンジンは、データをマーキングするのに<と>の文字を探すようになっているので、ウィジェットのJavaScriptエンジンを使う場合にはこれらの文字を対応するエンティティで置き換えなければならない。たとえば…

<onMouseUp>
if (x &lt; 5)
displayResults();
</onMouseUp>

Alternatively you can use XML comments to hide the JavaScript code from the XML
engine just as is commonly done in HTML, like so:
これに替わる方法として、JavaScriptコードをXMLエンジンから隠すためにXMLコメントを使うこともできる。これは、HTMLで一般的に行われている手法だ。こんな風になる。

<onMouseUp>
<!--
if (x < 5)
displayResults();
//-->
</onMouseUp>

This is generally preferred because it makes the code easier to read.
In version 2.1 or later, you can use CDATA sections (which are actually more correct to
use these days, and largely necessary if you put the parser into strict mode):
この手法を使うとコードが読みやすくなるので、一般的には好まれている。ウィジェットエンジンのバージョン2.1以降では、CDATAセクションを使うこともできる。(最近では、この手法がより正しいと考えられている。いずれにせよ、もしパーザーをStrictモードで動作させている場合にはこの手法が必須となる)

<onMouseUp>
<![CDATA[
if (x < 5)
displayResults();
]]>
</onMouseUp>

You can also make references to external JavaScript which we will cover later.
外部のJavaScriptコードへのリンクを使うこともできるが、これは後ほど説明する。

2006年4月18日火曜日

Yahoo!WidgetEngineReference-[Entities]

Entities

エンティティとは、特別なエスケープシーケンス(代替文字列)を用いて、特定の文字がそこに出現することを示すためのXMLの構成要素である。

文字の中には、XMLを解析する目的で使用するため、予約語とされているものがある。たとえば"&"という文字は、エンティティを表現するエスケープシーケンスのはじまりを示すために使われている(そして、この目的で使用するために予約語となっている)。
標準的なエンティティは、XMLで使用される特別な文字を表現するためのものだ。

&amp; &
&quot; "
&apos; '
&lt; <
&gt; >

Unicodeのコードポイントを使って特定の文字を表現することもできる。

&#32; <space character, decimal>
&#x20; <space character, hex>

以上のような"エンティティ"は、ウィジェットのバージョン2.1以降でのみ使用可能だ。

Yahoo!WidgetEngineReference-[XML Syntax]

XML Syntax

堅牢な構文解析ツールがあるおかげで、タグ記法とmix and match記法の二つのスタイルのうち、好きな方を使うことができる。この二つのスタイルというのは、例を挙げると…

<image>
<src>images/image.png</src>
<name>myImage</name>
</image>

と、

<image src="images/image.png" name="myImage"/>

というようになる。mix and match記法の場合、

<image src="images/image.png">
<name>myImage</name>
</image>

このような書き方でもかまわない。

ITmedia News:ネットの力で「わらしべ長者」を目指す男 (1/2)

ITmedia News:ネットの力で「わらしべ長者」を目指す男 (1/2)

この人面白い。特に、最後のスタジオ使用と完成品をレコード会社に売り込む権利をフェニックス二世帯住宅の1年間レンタル権と交換するというのが予想外で笑える。赤いペーパークリップがねぇ…。ハリウッド映画になったら、ちょっと見てみたいな。

セキュリティ組織,FirefoxやThunderbirdのセキュリティ・ホールを警告:ITpro

セキュリティ組織,FirefoxやThunderbirdのセキュリティ・ホールを警告:ITpro

とりあえずメモ。いまから移動だ…行ってきます。

2006年4月17日月曜日

Yahoo!ニュース - ITmediaニュース - テレビとネット、接触時間並ぶ ネット調査で

Yahoo!ニュース - ITmediaニュース - テレビとネット、接触時間並ぶ ネット調査で

やっぱりこうなったか、という印象。テレビに比べてネットは情報のバリエーションが(怪しい情報源も含めて)圧倒的に多くて、いくら探しても面白いネタが出てくる奥の深さがあるので飽きがこない。
テレビを見る時はチャンネル固定でつけっぱなしにしておいて、興味があるトピックだけ少し目線をやって情報を拾ってまたすぐにネットに戻る、ってな使い方がメインなのでこの記事には納得。

個人的な経験からだと、テレビは受動的に利用しているので、ある種洗脳に近いような効果を受けている気がする。ここで商品名や音楽などで商品知識はイメージをすりこまれると、実際そのカテゴリの商品が欲しくなった際に、自然と知っている商品を選んでしまう。ただし、テレビ広告を見てすぐにその商品が欲しくなることはほとんどない。
反面、ネット利用時は自分で情報を探しにいっているので、自分の興味のあるトピックに関連する広告なら"自ら選択して"見に行ってしまいやすい。その際に"洗脳"を受けていると、商品購入の障壁は格段に低くなる、と感じる。あわせて使うと効果的なんだろうな。

最も視聴する広告はテレビ CM 、新聞・PC 上のバナーが続く
にあるリサーチ結果を見ると、
普段最も視聴する広告は、全体の60.9%の回答者がテレビ広告を選んでおり、2位が新聞広告で全体の12.9%。PC 上のバナー広告(9.7%)は3位にとどまっているものの、雑誌(2.7%)やラジオ(1.9%)、駅の広告(4.6%)、DM やチラシ広告(3.7%)などを上回った。
と接触時間の現在値はそう高くないものの、
PC のバナー広告を見る回答者の中で、広告を見たことによって何らかの行動を取る割合は約74%、また商品やサービスを購入する割合は20%以上を占めている。
と、広告視聴後のヒット率は想像以上の水準だ。Google Adsenseなどのコンテンツ連動型広告のクリック率はそこそこの水準に達している(と個人的に感じる)ので、今後インターネット広告の比率がさらに高まってくるのは間違いないだろう。

とはいえ、インターネット広告は今、こんな問題も抱えていたりする。成熟に向かううえでの一時の議論だとは思うけど。

2006年4月14日金曜日

Yahoo!WidgetEngineReference-[Basics]を試してみた

Sun.pngなんてなかったので、Yahoo!で検索して適当な画像をひっぱてきてから実行してみた。

すると、ウィジェット(…といっていいのだろうか。画像と「Click Here」のテキストのみが表示されている、ウィンドウも何もない「何か」)が表示された。



と同時に、バックグラウンドにデバッグコンソールっぽいウィンドウが現れて、タイトルには「konfabulator:simple」と表示されている。どうやって使うのかはまだよくわからないが、これはおそらく<widget debug="on">に対応して現れるコンソールウィンドウなのだろう。

クリックを連打するとだんだん透明になっていくことも確認。画像部分を右クリックすることで出現するコンテキストメニューから、ウィジェットを終了できることも確認した。

Yahoo!WidgetEngineReference-[Basics]

Yahoo!WidgetEngine(以降エンジン)は、ウィジェットとウィジェットを組み上げるためのオブジェクト郡を定義するために、"XML"を利用している。
ウィジェットのオブジェクトの定義・ウィジェット上に配置されるオブジェクトの順番・オブジェクトが持つ属性同士の関連などは、XMLによって明確な階層構造として表現されている。

もっともシンプルなウィジェットはこんな風になる。

<widget debug="on">
<window title="Sample Yahoo! Widget">
<name>main_window</name>
<width>500</width>
<height>500</height>
<image src="Images/Sun.png" name="sun1">
<hOffset>250</hOffset>
<vOffset>250</vOffset>
<alignment>center</alignment>
</image>
<text data="Click Here" size="36" style="bold">
<name>text1</name>
<hOffset>250</hOffset>
<vOffset>100</vOffset>
<alignment>center</alignment>
<onMouseUp>
sun1.opacity = (sun1.opacity / 100) * 90;
</onMouseUp>
</text>
</window>
</widget>

ここでやっているのは、"Click Here"のテキストがクリックされるたびに10%ずつ画像の透明度を下げているということだけだ。これは明らかに実用的ではないが、この単純な例でいくつかのポイントを知ることができる。ちなみに、このサンプルは外部ファイル(Images/Sun.png)を1つ使っていて、仮にこのファイルなしでウィジェットを実行した場合には"missing image"と表示される。

まず最初に、ウィジェットの構造に注意してほしい。XMLは対照的な構造を持った言語で、オブジェクトを表す文字列(例:<text>)は対になる終端を表す文字列を持っている(例:</text>)。このペアの中にはオブジェクトの画面上の"位置"や"寄せの設定"など、各種属性が定義されている。
また、XMLで定義されているオブジェクトはJavaScript(例では"text1"オブジェクトの"onMouseDown"ハンドラ)で操作できることにも注意してほしい。なお、オブジェクト名の先頭は半角英数字でなければならず、先頭以外の部分は"半角英数字"、"半角数字"、"半角アンダースコア"のいずれかでなければならない。ウィジェットを記述するXMLは、拡張子が".kon"のファイル内に記述する。

"本物の"ウィジェットは多数の画像とテキストオブジェクト、複数のJavaScriptセクションを含み、複雑な機能を実現するためにランタイム上でJavaScriptによる新たなオブジェクトを生成するのが普通だ。

Yahoo!ウィジェットを作り始めるうえで一番簡単かつおすすめなのが、すでに存在するウィジェットを手に入れてきて、変更してみることだ。Yahoo!ウィジェットのエンジンにはさまざまなタスクをこなすウィジェットがついてくる。こういったウィジェットはどれも、ウィジェットを作りはじめるための格好の土台になるだろう。ただし、これらのウィジェットに付属するXMLとJavaScriptは自由に再利用できるが、画像の再利用は禁止されており、また決して再配布してはならないという点には注意すること。

Yahoo!ウィジェットに興味

興味がわいたので、英語の勉強がてらしばらくYahoo!WidgetSDKに付属している「WidgetEngineReference_3.1_4(PDF)」を翻訳・解説していこうと思う。

Yahoo!WidgetSDK

2006年4月13日木曜日

iアプリ版 My Yahoo!がSO902iに対応

これは地味にうれしい。
最近自分の情報をYahoo!に 片っ端から登録していて、Yahoo!Mail・Yahoo!Calendar・Yahoo!AddressBook・Yahoo!FinanceをPC/携帯の両方からかなり頻繁に使っている。

PCではMy Yahoo!のポートレットとして使えるのが便利だし、携帯からだとYahoo!Mobileからそれぞれの機能にアクセスできる。特にYahoo!Mobileは急な贈答品の発送や移動中のメール、株価の確認なんかにとても便利に使っている。ただし、Web版のYahoo!Mobileだと個別のサービスにログインするために、毎回ログイン画面から入りなおさなければならないのが少し面倒なので、SO902iを買ってiアプリDXが使えるようになってからiアプリ版のMy Yahoo!がSO902iで使えるようになるのを心待ちにしていたのだ。

さっそく使ってみたところ、Web版のMy Yahoo!よりもかなり良くて満足。メールの新着チェック、カレンダーの直近予定確認、ポートフォリオのほか、路線検索、天気、占い、スポーツ、ニュースなどを見ることができる。メールとアドレスブックはすぐにWeb版に飛ばされるが、これらには専用のiアプリがあるのでそちらを使えということなのだろう。それならアプリ同士連携してくれても良かったと思うのだが…まぁ今のところ贅沢は言わないでおこう。

NTTデータが内部統制強化の支援サービスを提供開始:ITpro

NTTデータが内部統制強化の支援サービスを提供開始:ITpro

このタイミングで!?と、思ってついクリックしてしまった。実際は日本版SOX法への対応支援サービスということで、セキュリティとかあんまり関係ないみたいだけど、見出しだけ見てると違和感バリバリ。
まぁでも、そんなこと関係なく、必要としてるところは頼むんだろうね。きっと。

グーグル、噂の「Google Calendar」をついに公開 - CNET Japan

グーグル、噂の「Google Calendar」をついに公開 - CNET Japan

GoogleCalendarが出てしまった。
軽くさわってみたところ、基本的にはYahoo!Calendarより使いやすい。GoogleMapで"Ajax"を作り出したGoogleらしく、それなりにユーザインタフェースには凝っていて、ドラッグで予定の長さを修正したり、予定そのものを動かしたりできる。予定として日本語を入力してみても、特に問題なく動いている。

Yahoo!Calendarでできなかった繰り返し設定(WeekDayのみ繰り返し、など)もできるようになっており、なかなか使い勝手が良い。惜しいのは、リマインダーメールの送付先が指定できないこと。おそらく、Googleアカウントとして指定したメールアドレスに送信するようになっているのだろう。個人的には、リマインダーのメールは携帯に送りたいので、Yahoo!Calendarのように個別に設定可能(個別設定のデフォルト値も指定可能)にして欲しい。まぁ、β版なのでこれから良くなるのかもしれない。

という風に結構良いんだけども、自分はGmailが使えない(誰にも紹介してもらってない…)ので、メールは主にYahoo!Mailを使っている。My Yahoo!でメールとカレンダー、ポートフォリオ、ブックマークなどをまとめて見れるのはかなり重宝しているため、カレンダーだけGoogleが良くなったとしても、すぐにはGoogleに乗り換える気にはなれない。ここから先、GoogleCalendarを使うことになるとしたら…

 1. Gmailアカウントを誰かからもらう
 2. Yahoo!Japanの各サービスもWebサービスに対応し、Widgetから使用可能に。
  Googleカレンダー対応Widgetも登場
 3. Googleカレンダー対応ポートレットが登場、My Yahoo!で閲覧可能に

2.が一番ありそうだな…。3.はほとんどありえなさそうだ。誰かGmailアカウントください…。

2006年4月10日月曜日

ITmedia +D LifeStyle:「VODでハイビジョン」がもたらす衝撃 (1/3)

ITmedia +D LifeStyle:「VODでハイビジョン」がもたらす衝撃 (1/3)

以下の部分には、激しく同意。


 いい音で、綺麗な絵で、といった抽象的な目標をがむしゃらに追い求めるのは、貧しい時代の話である。貧しいとは、消費者が貧乏という事ではなく、実現できる品質が低かった時代という意味だ。

 昔のラジオもテレビも、今に比べれば表現できる質は今より低く、とても「リアルな」とは言えなかった。だから誰でも、もっといい音で、もっと綺麗な絵で、といった漠然とした目標であっても、理想像を描くことができた。

 だが今はそこそこの機材でも、ある程度のレベルまでリアルで生々しい表現が可能になっている。これで十分、それ以上の品質が想像できない、という人たちが出現しても、おかしくない。つまり現状を超えてさらなる「良さがわかる」という人たちの人数が、昔に比べれば激減しているのである。これはあまり世の中の牽引力にはならない。


世の中、漠然とした品質向上よりも、自分が恩恵を受けているところをすぐに想像できるような、具体的な利便性を求める人が増えてきている、ってことなんだろう。
これは、違いがわからない程度の品質の違いにはお金を出さないってことでもある。自分は正直、3000円の寿司と5000円の寿司の違いはよくわからんので、少なくとも自分のために5000円も金を払うのは無駄だと思っている。どっちにしろうまいんだし。
要するに、品質向上に支払うことのできる額は逓減していくという感じがする。
十分すぎるほど品質を上げてきた企業が没落していく、という「イノベーションのジレンマ」の内容にも通じるところがあるのだろうか。

品質、というのをむやみに使いすぎな気がしてきた。
一般的な製品についての品質カテゴリがわからないので、ソフトウェア業界で一般に使われている品質特性をあげてみると…
・機能
・使いやすさ
・信頼性
・性能(速度)
・安全性
こんな感じになる。このうち、映像/DVD業界で何が起きているか、またソフトウェア/SI業界で何が起きているかは追って考えていくことにする。