2012-02-24

Lion に TeX (TeX Live) をインストールする

Mac OS には TeX が入っていない。そこで、Mac Ports を使って TeX Live 2011 をインストールしてみた。TeX Live は TeX のディストリビューションの一つ。

$ sudo port selfupdate
$ sudo port install texlive-lang-cjk texlive-documentation-japanese

上記コマンドで TeX のミニマム・インストールができたはず。

テスト ― 英語編

サンプル・コードは下記。文章・数式・目次・索引を作成。

\documentclass{article}
\usepackage{makeidx}

\title{Install \TeX{} with MacPorts}
\author{Masayuki Ataka}

\makeindex

\begin{document}
\maketitle
\tableofcontents

\section{Hello, World}
This is \LaTeX{} test document.

\section{Math}
\begin{equation}
  \label{eq: Einstein}
  E = mc^2
\end{equation}

\section{Make Index}
Einstein\index{Einstein}'s most famous equation is the equation (\ref{eq: Einstein}).

\printindex
\end{document}

実行コマンドは latex を使用。目次を作るために三回 latex コマンドを実行。索引作成に makeindex を使う。ファイル名は intro-en.tex

$ latex intro-en.tex
$ latex intro-en.tex
$ makeindex intro-en.idx
$ latex intro-en.tex

xdvi コマンドで出来上がった dvi ファイルを見る。

$ xdvi intro-en.dvi

ただ、Mac は PDF を得意としているので、PDF に変換して Finder アプリから PDF ファイルをダブル・クリック。Preview アプリで PDF を見る方が見た目は良い。

$ dvipdfm intro-en.dvi

出来上がった PDF ファイルは 15,554 byte。

そういえば、英語ファイルなら pdflatex を使っていきなり PDF を作成することも出来た。

$ pdflatex intro-en.tex

出来た PDF ファイルのサイズは 75,260 byte。あれ、案外、大きいのね。出来上がりは以下の通り。キレイ。キレイ。

テスト ― 日本語編

ファイルは utf-8 で保存。

\documentclass{jarticle}
\usepackage{makeidx}

\title{MacPorts を使った \TeX{} のインストール}
\author{安宅 正之}

\makeindex

\begin{document}
\maketitle
\tableofcontents

\section{Hello, World}
これは \LaTeX{} のテストです。.

\section{数式}
\begin{equation}
  \label{eq: Einstein}
  E = mc^2
\end{equation}

\section{索引の作成}
アインシュタイン\index{アインシュタイン}の最も有名な数式は数式~(\ref{eq: Einstein}) です。

\printindex
\end{document}

実行コマンドは platex を使用。索引コマンドには mendex を使う。ファイル名は intro-ja.tex

$ latex intro-ja.tex
$ latex intro-ja.tex
$ mendex intro-ja.idx
$ latex intro-ja.tex

xdvi コマンドで出来上がった dvi ファイルを見る。

$ xdvi intro-en.dvi
xdvi-xaw: Fatal error: intro-ja.tex: Not a DVI file.

ありゃりゃ。TeX Live 2011 に入ってる xdvi は日本語対応していない。何か他の日本語対応が必要なんでせう。気にせず PDF 化してしまう。

$ dvipdfmx intro-ja.dvi

PDF ファイルが出来上がった。ファイル・サイズは 10,708 byte。フム。英語版とは文字数が違うしね。まあ、コンパクトにファイルが出来た。Preview アプリで出来上がりも確認。

出来上がりもキレイ。とりあえず、日本語 TeX 環境は整った。ヨシ、ヨシ。

ref

iTunes in the Cloud を試してみる

iTunes in the Cloud が始まった。Apple の謳い文句を引用する:

iCloudを使えば、iTunesで購入した音楽が、あなたが使っているすべてのデバイスに 自動的に現れます。以前iTunesで購入したアイテムもダウンロードできます。

好きな曲を、好きな時に、好きな場所で、ご自由に。

iTunes で音楽・アプリ・書籍を購入すると、自動的に iPhone/iPad に現れるという。

購入商品を確認するには、PC 上の iTunes で Store > iTunes Store > 右端のナビリンク内「購入済み」をクリック。

設定

iTunes on PC

iTunes の環境設定から「Store」タブを選択。「自動的にダウンロード」というメニューに「音楽」「アプリ」「書籍」があるので、自動ダウンロードしたい項目にチェックを入れる。

iPhone/iPad

設定 > ストアを選択。自動的ダウンロードに「音楽」「アプリ」「書籍」があるので、必要な項目を「オン」にする。

あとがき

いざ、音楽をダウンロード... と思ったら、ぼくは iTunes Store で音楽を買ったことがなかった。設定まではしたのにねぇ。まあ、今後 iTunes でお買い物することもあるでしょ。その時に iTunes on the Cloud の真価を楽しもう。

2012-02-22

ぼくの MacBook は Mountain Lion に非対応

大きなイベントもなく、いきなりやって来た OS X の最新バージョン情報。最新コードネームは Mountain Lion。OS の名前からは Mac が外れ、Mac OS X から OS X に変更。

iCould 連携・iOS 統合が進んだ OS となりそう。

対応・非対応

さて、Engadget Japan が非公式ながら Mountain Lion に対応する Mac, 対応しない Mac の一覧を載せている。

具体的に対応する製品として挙げられているのは以下の機種:
iMac:mid 2007 以降。
MacBook:2008 以降の 13インチ アルミユニボディ。あるいはEarly 2009 以降の 13 インチ白ボディ。
MacBook Pro:13インチ、Mid-2009 以降。15インチ、2.4/2.2 GHz。17インチ、Late 2007 以降。
MacBook Air:Late 2008 以降。
Mac Mini:Early 2009 以降。
Mac Pro:Early 2008 以降。
Xserve:Early 2009。

反対に山ライオン化できないとされる製品は以下の機種:
iMacs:Late 2006 以前 (iMac5,1, iMac5,2, iMac6,1)
MacBooks :Late 2008以前 (MacBook2,1, MacBook3,1, MacBook4,1)
MacBook Pros:June 2007以前 (MacBookPro2,1, MacBookPro2,2)
MacBook Air:初代モデル (MacBookAir1,1)
Mac mini:The Mid-2007 以前 (Macmini2,1)
Mac Pro:初代、および2007の8コアモデル (MacPro1,1, MacPro2,1)
Xserve:Late 2006 と Early 2008 (Xserve1,1, Xserve2,1)

チェック

自分の MacBook が対応しているか調べてみた。

Apple のメニューから「この Mac について」 > 「詳しい情報」を表示。

MacBook の名称の下に「13-Inch Late 2006」の文字が。とても嫌な予感がする。念のため、機種 ID も調べてみる。「システムレポート」をクリック。

「ハードウェアの概要」に「機種 ID」が表示されている。番号は「MacBook2,1」。

上の対応表を見ると、見事に Mountain Lion 非対応製品に入っている。ゴメンよ。MacBook。色々と延命してきたけれど、もう OS に追いつかないらしい。ぼくにはどうにも出来ないよ。でも、新 Mac を買うお金がまだないから、まだ頑張って使うからね。

新 Twitter UI がサポートした「非公式 RT」

Twitter の UI が新しくなって、いわゆる「非公式 RT」を独自にサポートするようになった (本エントリーでは、これを「コメント付き RT」と呼ぼう)。利便性は公式 RT の良さを備えたまま、非公式 RT のメリットを活かした素敵な形に仕上がっている。下がそのスクリーン・ショット。

見えるのは、本人の「コメント」部分だけ。「View tweet」というボタンがあるので、これをクリック。

ご覧の様に、コメント元のツイートが表示される。隠すには「Hide tweet」をクリック。

今までの「非公式 RT」には文字数制限が厳しいという大きな枷があった。そのため、オリジナルのツイートや他人のコメントを削ったりして、本文が読めなくなる問題があった。今回の方式なら、オリジナルのツイートがそのまま残る。その上で、自分のコメントが多く書ける。とても良い所取りな新機能。

コメント付き RT の作り方

  1. 「コメント付き RT」したいツイートにマウス・オーバーすると、右上に「Open」という文字が現れる (※)。これを右クリックして「リンク アドレスをコピー」を選択する
  2. 続けて「Reply」をクリック。
  3. コメントを書いて、最後にツイートの URL アドレスをペースト (必要なら複数のアドレスをペーストしても OK)

(※) 「Open」を左クリックすると、そのツイートの詳細情報が見られる。

以上。簡単でしょ。

多段でコメント付き RT

「コメント付き RT」を「コメント付き RT」してみた。最初の一個目だけが「コメント付き RT」になって、それより前のツイートは「リプライ」と同じ様に表示される。

iPad/iPhone でコメント付き RT

iPad/iPhone の公式 Twitter アプリもコメント付き RT に対応している。ここでは、iPad を例に説明する。

作り方
  1. ツイートをタップ。ツイート詳細が表示される
  2. 右上の右矢印をタップして「ツイートへのリンクをコピー」を選択
  3. 左矢印をタップして「リプライ」を選択
  4. コメントを書く
  5. ツイートのリンクを貼り付ける

見た目

iPad での見た目はこうなる。

コメント付き RT on iPad

あとがき

この新しい「コメント付き RT」。他の Twitter クライアントでも早く対応してもらいたい。それから、本家 Twitter。ボタン一発でコメント付き RT できる様になってくれると嬉しい。

2012-02-19

NTT R&D: リアルタイムグラフ可視化技術

NTT R&D フォーラムで見た展示のメモ。

リアルタイムグラフ可視化技術の展示

Twitter から拾い上げたキーワードをリアルタイムにネットワーク・グラフ化して表示していた。

メモ

本展示は、HTML5 の技術を使うことでリアルタイム処理を行なえる様になることの実演デモ。キーワードは 3 つ。

  • WebWorkrs
  • WebGL
  • WebCL

キーワードを理解していれば、驚くほどのこともない展示。ただ、知らない用語があったので、勉強を兼ねて自分の言葉で説明してみる。

WebWorkrs
JavaScript をスレッド化する技術。JavaScript は描画と演算を同時に行なう場合、計算結果を表示するようなウェブ・アプリは計算が重いと描画が止まってしまう。WebWorkers で描画と演算を別スレッドにすることにより、描画処理を向上させる。
WebGL
三次元描画用の API。二次元描画には Canvas と SVG があるけれども、三次元は扱えない。結果、プログラマーが三次元情報を二次元に落とす様なプログラムを書く必要がある。WebGL は最初から三次元を二次元表示する仕様なので高速。またグラフィック・ボードの支援を受けて更なる高速化も期待できる。
WebCL
JavaScript の計算を GPU で行なう API。つまり、グラフィック・ボードの支援能力を使う技術。CPU が不得手とする計算を GPU に任せてしまう (CPU/GPU には得手不得手がある)。特に三次元描画系の計算は CPU より GPU が得意とする。

WebWorkers, WebGL, WebCL とグラフィック・アクセラレーションを使うことで、従来の 200 倍の高速化を実現。

あとがき

用語は知っていても、プログラミングしてみる機会のなかった分野。ちょっとプログラミング熱がわく展示だった。

NTT R&D: 利用者の好みを学習する推薦システム: Another Me

NTT R&D フォーラムで見た展示をレビューする。

利用者の好みを学習する推薦システム: Another Me のデモ

Another Me は、「時間」と「ソーシャル・ネットワーク」と「嫌い」の三要素を取り入れたリコメンド・システム。展示ではニュース記事をサンプルに Another Me のデモを行なっていた。リコメンド・システムとして目から鱗の落ちるアイデアが詰まっていたので、紹介する。

まず「時間」をリコメンドに含めるアイデア。人は時間帯によって行動が異なり、行動によって興味も異なる。平日の朝は「ビジネス」ニュースを読み、帰宅時間には好きなスポーツのニュースが多くなる。日曜日には朝でもビジネス・ニュースは必要なくなり、他のニュースが表示される。

次に「ソーシャル・ネットワーク」を使うアイデア。SNS の様にお友達があって、「お勧め」ボタンが用意されている。ユーザーは友達の勧めるニュースを優先的に見ることになる。ここでも、「時間」のアイデアは組み込まれていて、朝は会社の上司・同僚のリコメンドを優先され、帰社時には友達のリコメンドが優先される。

どの時間帯にどのニュースを好むか、またどの時間帯にどのソーシャル・ネットワークの優先度を上げるか、これらは提示されたニュースを開くことで「Like」な評価点を上げてゆく。より Like なものほど上位に表示されるよう学習が進む。

学習には、もう一つ。「概念体系」を組み混んでいる。具体的には「キーワード」を概念でツリー上にしたもの。例えば「○○選手」は「巨人」に属していて、「巨人」は「野球」というカテゴリーの下に入る。この様な概念ツリーが予め作られていて、ニュースの一端にある「キーワード」から上位概念 (この場合は「野球」) が好きという風に学習が進められる。

三つ目のアイデアは「嫌い (Dislike)」をリコメンド学習に含めること。研究の結果、Like も重要だが、それ以上に Dislike が更に大きな影響力を持つと分かったらしい。ユーザーが Dislike を具体的な手段で示すことはなく、ニュース一覧から開いたニュースを「Like」、開かなかったニュースを「Dislike」と考える。例えば、経済のニュースでも、IT 系のニュースがよく開かれ、自動車関連のニュースはほとんど開かれないとする。すると IT 系を Like、自動車関連を Dislike とする。更に上司 A から勧められたニュースを読んでもツマラないものが多いから、開かなくなってゆく。すると、上司 A はソーシャル的に Dislike として判定される。

あとがき

時間に合わせてリコメンデーションを変えるアイデアにとてもひかれた。展示資料を読み返すと、「時間」だけではなく「曜日/記念日」「場所」「天気」「気温」といった状況に応じてユーザーの傾向をモデル化するとのこと。ライフログとニュース・リコメンデーションの融合と言っても良いかもしれない。

更にソーシャル・グラフ、概念体系、嫌いの反映とアイデアに満ちている。

ぼくが使うと、朝には基本 IT 系のニュースで埋めつくされ、ただし雨の日にだけ天気予報のニュースが入り、電車遅延がある場合にはその手のニュースがトップに来て... 更に「映画の日」には映画のニュースが入り、休日には本や音楽のニュースが表示される。なんてことになりそう。そうなると良いな。

ニュースだけでなくフィード・リーダーでも同種のリコメンデーションが入ると面白いに違いない。

そう思うと、ワクワクさせられる展示だった。

2012-02-18

NTT R&D: スマートライフ実現に向けたドコモ R&D の取組み

NTT R&D フォーラムのワークショップ「スマートライフ実現に向けたドコモ R&D の取組み」に関するメモ書き。講演者は NTTドコモ 執行役員 研究開発推進部 部長 尾上誠蔵氏。一枚のスライドに情報ギッシリで、パラパラとスライドがめくられた。話についてゆくのがやっとだったので、ポイントだけメモ的に残す。

スマートライフ実現に向けたドコモ R&D の取組み

  • 2020年のビジョンは「HEART」(Harmonize, Evolve, Advance, Relate, Trust)
  • R&D では客のニーズや事業の要請に応えることが一番多い
  • LTE はめずらしくシーズ・オリエンテッドな始まりだった
  • LTE (Xi) の取り組み開始は 2004 年。当時は Super 3G と呼んでいた
  • 3G は今でこそ普及しているけど、スタート時の加入者数の伸びは非常に小さかった
  • LTE (Xi) は導入をスムーズにすることを心がけた (現在 150 万)

他にも色々と話をしていて、メモも取ってあるのだけど、断片的で上手く繋がらないのでこれだけ。普段は LTE (Xi) の技術の話をしているけど、今回は裏話をメインにしたとのこと。

3G と Xi の普及割合を比較すると、Xi は 3G に比べて非常にスムーズに増化している。3G を出した時は、伸び率があまりに低くてかなり困った。そんな頃に Xi (Super 3G) の取り組みを開始していたなんて先見の明があるでしょ。ちょっとした自慢話につい笑ってしまった。

NTT R&D: ブロガー・ミーティング 発見探地図エリアダス

NTT R&D フォーラムの内々で開かれたブロガー・ミーティング「発見探地図エリアダス」のレビュー。このブロガー・ミーティングは NTT R&D フォーラムの展示「C-22 スマートフォン向け情報ナビゲーション」の内容を 1 時間のブロガー向け紹介イベントに直したもの。

発見探地図エリアダス

エリアダスは Android アプリ。地図情報系のアプリの一つ。ブロガー・ミーティングでは参加者に Android 実機が手渡され、実際にエリアダスを体験することができた。

エリアダスの主要機能は 3 つ:

  1. エリアタグの表示
  2. ブログ検索結果の表示
  3. キーワード分布の表示

アプリを起動すると地図が表示される。デフォールトで、地図上にキーワード (これをエリアタグ と呼ぶ) が最大 15 個表示される。エリアタグは、地図の表示範囲内でよく取り上げられるキーワードが選ばれる。

例えば地図で栃木県を表示してみると、「レモン牛乳」というエリアタグが表示される。どうやら当地の名産品 (?) らしい。その土地の「自分が知らない情報」を提示する機能がエリアタグ。

エリアタグをタップすると、そのエリアタグ (キーワード) に関連したブログ記事の一覧が表示される。そう、エリアタグの抽出にはブログが使われている。選択したエリアタグに関する情報が得られるというわけ。

3 つ目の機能はキーワードの分布を表示するもの。キーワード検索を行なうと、そのキーワードについて言及されている地域が色付けされて表示される。司会者は、一つのキーワード (何のキーワードだったか忘れた) を検索。地図に二か所が色濃く表示される例を見せてくれた。ある名産品について、その二つの地域が発祥地争いをしているそうな。

ぼくは家の近くで「蕎麦」を検索してみた。おそばが好きなので。すると、駅の周辺が異常に色濃くなっている。何やら駅の近くに蕎麦屋があるらしい。ブログ検索の結果を表示させてみると、「鷲ひら」という手打ち蕎麦屋があることが分かった。その日の晩御飯をこのお店で頂いたのは言うまでもない。

仕組み

特に変わったことはしていない。ネット上の文書をスキャンしてキーワードを集める。場所は、予め用意した地名辞書のようなものから解析する。「京橋」のように東京都にも大阪府にもある様な地名は、文書内の他の地名データと関連付けて場所を決定する。地名情報が少なければ、場所を間違うこともある。

良い点と悪い点

良い点

エリアタグは「勝手におススメ」みたいな機能。ユーザーがキーワード入力する必要がない。だから、自分の意図しないキーワードに出会える可能性がある。その可能性が面白い。

一方、キーワード分布はユーザーの意図を反映する機能。場所の特定は出来ないけれど、大雑把なエリアを地図で見ることができる。ぼくは今回、そば屋を見つけるのに活用できたけれども、さて毎回活用できる機能かどうかは分からない。

どちらの機能も、ユーザーが「意図しない」情報を提供することが多そう。意外性のアプリというのか。ユーザーの探したい物を探すアプリが多い中、逆を行く発想で面白い。こんなアプリ、一つは入れておいても良いかもしれない。

悪い点

アプリのアイデアは良い。ユーザー・インターフェースの練りが足りない。不満点をいくつか挙げてみる。

  • 場所を指定して飛ぶ機能がない
  • ダブル・タップで地図拡大できない
  • 他のアプリとの連携が出来ていない (Google カレンダーとかね)

全体的に「機能」ばかりが走っていて、使い勝手に不満を覚える。典型的な技術屋さんが作ったアプリ。今回のフォーラムを見て、NTT 研にも UI を得意にする人が居ると知った。改善は難しいことじゃないと思う。Android アプリは、大きな新機能を出すことより、小さな変更を回数重ねてより多くのフィードバックをもらうことが、アプリ改善の近道になるのでそこを間違えないで欲しい。

あとがき

ブロガー・ミーティングで出た意見を二つ。一つは Twitter 対応をして欲しいこと。もう一つは HTML5 化の検討もして欲しいこと。

特に HTML5 によるウェブ・アプリは Android/iOS/PC の垣根がなくなるので、是非実現して欲しい。iPhone でエリアダスが使えないのは寂しい。

NTT R&D: コミュニティ ICT

NTT R&D フォーラムで見た展示をレビューする。

コミュニティ ICT のデモ

「コミュニティ ICT」はネット家電が一般普及し、SNS などが当たり前になった近未来を想定している。ちなみに ICT は Information and Comunication Technology の略。

コミュニティ ICT

写真に見える「物」がネット家電の一例。電子ドア鍵・カメラ・火災報知器・固定電話・スマートフォン。近所に住む A さんと C さんは信頼し合っていて、SNS で言う所の「お友達」になっているとする。

ぼくが受けたデモでは、火災が A さん宅で発生した場合を例に話が進められた。火災は火災報知器によって探知される。ところが A さんは不在だった。火災報知器は A さんのスマートフォンに火災発生のメールを送る。

ここからが「コミュニティ」の強み。A さん宅の火災報知器は、お友達の C さん宅の火災報知器も鳴らす (自分の家の火災と他人の家の火災とでメロディーが違うと良いだろうね)。加えて、C さん宅の固定電話を鳴らしたり、C さんのスマートフォンに「A さん宅で火災発生」のメールを送る。

メールを見て火災発生を知った A さんは、自宅カメラにアクセスして火災の状況を知る。ちょっとヤバイ。電話か何かで C さんが消火にかけつけてくれることになった。A さんは、電子ドア鍵のロックを C さんのために開鍵する。C さんは A さん宅に入って無事消火する。

技術の話

ドアやカメラ、火災報知器等がネット対応にならないと話は進まない。だから、ここではそれらの機器がネット対応になった、という前提で技術の話に入る。

キモになるのは 3 点:

  1. 複数ゲートウェイ間の管理連携 (普通、家のネットワークは家の中で閉じている。他人が入れない様になっている。大雑把に言うと、ゲートウェイ (玄関) という仕組みが家の中と外を区切っている。信頼している相手に対して、ゲートウェイを開く技術が必要)
  2. ネット家電の管理。この例では火災報知器の動きを管理すること。
  3. 相手機器の管理。この例では、他人の家の火災報知器を鳴らし、スマートフォンにはメールを送ること。

あとがき

今まで家族の間で機器や情報を共有しよう、というアイデアはあった。TV はみんなで見るし、家の鍵は植木鉢の下に置いておくという具合に。家の外からビデオ予約をし、PC にアクセスする人もあった。少しプライバシー範囲を広げて、カレンダー情報や現在地情報を友達・家族と共有するサービスもある。

でも、この「コミュニティ ICT」はプライバシーの垣根を今まで以上に大きく越えている。アクセスできる想定機器が非常に幅広い。近所付き合いが下手になった昨今、受け入れがたいサービスにも思える。逆にこういうサービスを通じて、近所付き合いが円滑になる可能性もあるかもしれない。

ぼくはどうか? 隣の家の人の顔も知らない。ちょっとこのサービスは使えないかな。

むしろ核家族化が進む現代、遠距離の親族とのコミュニティーを作るのに面白い仕組みかもしれない。祖父宅に火災報知器を付けておいて、祖父の留守中に火災が発生したら息子はカメラで現状を確認して消防へ電話するとか... ね。

2012-02-17

NTT R&D: パーソナル情報スタイル

NTT R&D フォーラムで見た展示をレビューする。

本エントリーでは 2 つの展示を一緒にレビューする。というのも、2 つの展示がセットになっていたから。対象の展示は下記:

  • C-6 パーソナル情報スタイル
  • J-2 HTML5 による次世代コンテンツ流通サービス

パーソナル情報スタイルの展示

TV が一台、NHK の番組を映している。主役はユーザーに渡されたタブレット。タブレットには今見ている番組の関連情報が表示されている。ユーザーのアバターを中心に、キーワードがネットワークで繋がっている。この UI を InfoSkin と呼ぶ。

InfoSkin

※タブレットの画面を撮影しようとしたら、照明の光が反射してどうにも上手く撮れなかった。幸いディスプレイにもタブレットの画面が表示されていて綺麗に写真が撮れたので、こちらをサンプルとして使う。本来はタブレットで使う UI。

キーワードはウェブ・サイトへのリンクになっている。タップすれば、そのサイトに飛ぶ。番組を見ながら、AmazonGoogle News にアクセスできるというわけ。

更に画面をよく見ると、「父」の周りに輪っかがあるのが見てとれる。これがパーソナライズの UI になっている。輪の中にキーワードをドラッグすると、「そのキーワードに興味あり」と判断される。ネットワーク図が描き変えられ、そのキーワードに関連した情報が多く表示される。逆にキーワードを輪の外に放り出すと、「そのキーワードに興味なし」と判断される。そして、ネットワーク図が再び描き変わる。

表示されるキーワードは、番組の進行に従っても変わってゆく。ネットワーク図もそのたびに変わる。

一つ注意したいのは、この UI に今まで一度も「キーワード入力」が使われなかったこと。

  1. テレビ局側からの情報
  2. ユーザーのキーワード移動

この 2 つだけで、見ている番組の関連情報を手に入れられるのが面白い。父と娘が同じ番組を見ていても、各々が別々のタブレットを持ち自分の好みのキーワードを移動させると、違う情報が表示される。更に履歴情報も使えると面白いと思うが、そこまで手は入っていないとのこと。

技術のお話

どうやってこの仕組みは動いているのか? NTT 単独では出来なくって、放送局側の協力も得ている。

まず、TV が視聴中の番組を NTT のサーバーに通知する。サーバーは放送局にアクセスして、放送中の番号のキーワードを取得する (そういう仕組みを放送局側にセットする必要があるわけね: 今回は NHK が協力)。サーバーはキーワード情報をタブレットに送信。タブレットは受け取った情報を基に画面を描画。ユーザーがキーワードを移動させると、タブレットはサーバーに変化を通知して新しいキーワードをもらう。

うん? すると、家の TV とタブレットの関連付けもどこかでやっているんだな。その説明はなかった。

さて、タブレット用アプリの話もしよう。InfoSkin は HTML5 で書かれている。写真の上を見ると分かると思うけれど、アドレス・バーがあって URL が表示されている。そう、このアプリはウェブ・ブラウザー上で動いている。HTML5 のうち使っているのは、Push 通信に WebSocket、デザインに CSS3、画面描画に Canvas と SVG。このデモでは、HTML5 を使ってネイティブ・アプリと見間違う程の UI を作ることが出来ることも見せている。Android/iOS/Windows といった OS に依存しない点を強調していた。

あとがき

NTT 研究所は固い研究開発ばかりやって、ユーザーがすぐに使えるような物を出してこない。そんなイメージがあった。

今回のデモで自分の認識の甘さを知った。HTML5 でウェブ・アプリが作れることは、ウェブに特化したサービスが大きく進めていることではあるけれども、NTT もその有用性をちゃんと認識している。そしてデモで魅力的なアプリを発表するレベルにまで達している。とても喜ばしい。そして出来上がった InfoSkin という UI は、使い方が分かり易く、見た目もスマート。一本取られた気分。

TV からキーワード情報を飛ばすというアイデアも面白い。こういう放送局がからむ様なことは、NTT みたいに大きな会社が音頭を取らないと進みにくいものだから、是非頑張って実用化して欲しいもの。放送局から「データ」が配信される様になったらベンチャーが NTT のアイデア以上のアプリを出すかもしれない。というか、きっとそうなるでせう。だけど、それで良いと思う。そうやってインフラを整えて行けるのが NTT みたいに「大きな会社」の使命の一つだと思うから。

NTT R&D: ライブ・パノラマ映像のインタラクティブ視聴サービス

NTT R&D フォーラムで見た展示をレビューする。

ライブ・パノラマの展示

実演デモ。

一台のディスプレイを見せられて、リモコンが手渡される。ディスプレイには会場の様子が映っている。ビデオ・カメラが映している映像。1〜6 のボタンを押すと、視点が切り替わる。リモコンの十字キーを押すと、カメラの視野が変わる。右キーを押すと右側に視線 (?) が向く。上キーを押すと上へと視線が変わる。

もう一つ。タブレットが取り出される。ディスプレイ同様、カメラの映像が映っている。タブレットを左右に動かすと、映像も同期して動く。動きはスムーズ。タブレットを持ったまま、後ろへ回れ右すれば、真後ろが見える。デモゆえに、一部画像の乱れあり。

過去の技術と新しい技術

ライブカメラ

一見するとライブカメラのデモにしか見えない。ライブカメラとは、インターネットを通して遠くのカメラが映す映像を見るもの。最近は Java アプレットを使って、ユーザーがカメラの向きを変えることが出来る。展望台などに設置されたカメラから、自分の見たい方向・拡大率で映像が見れる。さながら、その場で望遠鏡を覗いている感じ。

一例を挙げれば、ぼくの故郷は四国・高松のライブカメラ。

高松駅すぐそばにサンポートと呼ばれるシンボル・タワーがある。そのタワーの上 (東側) にライブカメラが一台備えつけられている。タワー東側から望むは瀬戸内海。ユーザーはカメラを操作して、高松港や海の様子を見ることができる。

現状のライブカメラの不満点は三つ。1 つ目は Java が必要なこと。Java の入っていないパソコンでは動かないし、Java が入らないスマートフォンやタブレットは対象外。また、Java はたびたびバージョン・アップするので、ネット・リテラシーの低いユーザーには敷居が高い。2 つ目はレスポンスが悪いこと。ユーザーがカメラに右を向けと言ったら、カメラが右を向く。ほんの少しだけどタイムラグがある。3 つ目はカメラの操作権利が一人にしかないこと。一人は右を見たい、もう一人は左を見たい。そう思っても、カメラを動かせるのは一人だけ。だから、操作できる時間に制限を設けて、ライブカメラに人が集まっている時は順番待ちをしてもらうことになる。

ライブ・パノラマ

この展示では Java を使っていない。TV でもタブレットでも動く。これは嬉しい。けれど、それは新技術のおこぼれに過ぎない。

NTT のライブ・パノラマは、実はカメラが動かない。使っているカメラが違う。ライブ・パノラマでは 360 度の撮影ができるカメラを使っている。あの Google ストリート・ビューを撮るのに使っているカメラと同種のもの。

ライブカメラ

360 度で撮影した映像をユーザーのリクエストに応じて「切り出し」てライブカメラとして表示している。利点は二つ。動きがスムーズ。もともと 360 度撮影しているわけだから、「カメラを動かす」という機械的な時間ロスがない。あるとしたらソフトウェア的な時間遅延だけれども、それはカメラ本体を動かす時間に比べれば小さい。高いレスポンス性を発揮する。タブレットを持って真後ろを向いてみる場合を考えてみて欲しい。カメラだったら 180 度回転しないといけない。ところが、このライブパノラマは最初から真後ろの映像も撮っている。真後ろの映像を切り出すだけで事は済む。

利点の二つ目は操作権利が誰にでも与えられること。カメラの視点は一つだけだけど、こちらは 360 度全方位に対応している。だから複数のユーザーが別々の視点を欲したら、ユーザーごとに映像を「切り出し」てあげるだけでいい。展示会場には 6 台のパノラマ・カメラが設定され、4 台のデモ機(TV/タブレット)があった。1 台のパノラマ・カメラから 4 つの視点 (ex. 正面・右・左・上) を見ることも、この仕組みなら問題ない。

技術のお話

肝になるのはサーバー。パノラマ・カメラには一台ずつ PC が割り当てられ、映像をサーバーに送り続けている。サーバーは 2 台用意され、送られてきた映像を管理。ユーザーのリクエストに応じて、映像の切り出しを行なう。

面白いのは、切り出した映像を「動画」にエンコードしないこと。映像を切り出したら、JPEG (静止画) にして一秒間に何枚もの画像を送る。いわゆるパラパラ漫画で「動画」を再現している。これは、モバイル版ニコニコ動画がやっていたこと (今もやっているか知らないけれど) と同じ。動画エンコードの負荷を考えると、なるほどこちらの方が負荷が低い。複数ユーザーがアクセスすることを考えたら、なおさら動画エンコードなんてやってられなさそう。

課題もある。画質の低さ。そして帯域と処理速度の問題。デモの画質は SD 画質。すなわち 640 x 480。今の BD は Full HD 画質で 1920 x 1080。理想を言えば Full HD 画質に対応したい。ところで、使っているカメラは普通のカメラじゃない。360 度に対応したカメラ。SD 画質に切り出す前の「オリジナルの映像」は 2000 x 2000 という。でかい!! 更に Full HD を実現しようとすると、4K x 4K が必要になるという。その映像データをサーバーに送るには、どう圧縮しても 10 Gbps は必要とのこと。半端ない。

あとがき

最終的な目標は、音楽ライブやスポーツの会場に Full HD のパノラマ・カメラを何十台も設置して、ユーザーが好きな視点で楽しめる様にすることだという。そういう未来が来ると楽しそう。ただ、課題を考えると遠い未来のことに思えてしまう。

それよりも上の例に出した様なライブ・カメラ。あれの代替ならすぐに出来るんじゃないかな。画質はライブ・カメラとほぼ同等な上に、Java が不要。操作性は段違いに上。頑張れば一か月位いで PC/スマートフォン/タブレット用の専用アプリ/ウェブ・アプリを開発できそう (雛型はもうあるわけだしね)。不安なサーバー負荷に関しても、(悲しいことに) この手のライブ・カメラは利用者がそんなに多くない。逆を言えば、低負荷で運用できる。負荷問題のノウハウを積みながら、より利用者の多いライブ・カメラとの置換を進めて行く。ほら、実用なんかすぐ目の前に見えている。

最後に説明員の人が一言。「マネタイズがねぇ」。ああ、そうね。当然、お金が取れなきゃ運営難しいよね。お金出してまで、既存のライブカメラを替えようなんてところはあるかしらん。もし興味のあるライブカメラの運営者、いたら NTT 研究所に声をかけてみてはどうかしらん。難しいかなぁ。面白いと思うんだけどなぁ。

NTT R&Dフォーラム 2012 に参加した

2012-02-16 (木)、NTT R&D フォーラムに参加した。NTT R&D フォーラム は NTT の研究開発 (Research & Development) を NTT 関連企業に公開するもの。毎年 2 月、2 日間に渡って開催されている。

NTT レゾナントは 4 年前からほぼ毎年、この NTT R&D フォーラムにブロガーを招待するブロガー・イベントを主催している。今回のイベントの正式名称は「goo ラボ ネットの未来プロジェクト NTT R&Dフォーラム 2012 ブロガー・ミーティング」。(題名が長い!) ブロガー約 50 名を、「NTT R&D フォーラム」にプレス資格で招待する。ぼくは運良く抽選に当たったので、イベントに参加することができた。

NTT R&D フォーラム概要

  • 開催日: 2012-02-16,17 (2 日間)
  • 開催場所: NTT 武蔵野研究開発センタ
  • 開催時間: 10:00-17:00 (16 日)

ぼくが参加した 16 日には、2 つの基調講演と 1 つのワークショップが開かれた。展示は大きく 3 つグループ分けされている: 「創る ICT」「支える ICT」「進化する ICT」。ICT は Information and Communication Technology の略。

なお、NTT R&D フォーラム参加者用に無料の送迎バスが三鷹駅から出ている。

ブロガー・ミーティングの流れ

10 時に入場。ブロガーの待合室で簡単なレクチャーを受ける (写真撮影に関する注意とか)。希望者には基調講演/ワークショップの入場券が配られる。ぼくはワークショップの聴講を希望。レクチャー終了後、各自自由行動。展示を見て回る。

昼食は研究所内の食堂が利用可能。お弁当の持参も OK。結局、お昼を食べるタイミングを逃して、ずっと展示を見ていたけれどもね :p

13:20-14:10 の間、ブロガー・ミーティング。「発見探地図エリアダス」という Android アプリの説明を受ける。これは展示「C-22 スマートフォン向け情報ナビゲーション」の内容をより深く堀り下げて説明することが目的のよう。ブロガー向きな話題であること。展示が人気なことから個人々々に説明を行なうより、人を集めて説明する方が効果的との判断があったらしい。このブロガー・ミーティングに関しては、ブロガーは必ず参加することとなっていた (ちょうど同じ時間帯に一つ目の基調講演があった Xp)。

エリアダスのブロガー・ミーティング後、再び自由行動。15:45-16:45 までワークショップを聴講 (自由参加)。16:45 を目途に待合室に戻って、アンケート用紙を記入。そして解散。

過去の NTT R&D フォーラムと比べて

NTT レゾナントが主催する「ブロガー・ミーティング」は、過去に 3 回行なわれている。即ち 2009 年、2010 年、そして今年 2012 年の三回。ぼくは 2009 年のブロガー・ミーティングに参加したことがある。4 年前のイベントと今回のイベント。その違いを書いてみたい。

まず第一に、ブロガー・イベントの開催時間に余裕が出た。4 年前は午後からの参加のみだったので、展示を見る時間が 2 時間ほどしかなかった。今回はフルタイムに時間を使えたので、(途中にブロガー・ミーティングが 1 時間入ったとはいえ) 大幅に展示を見る時間が増えた。それでも全てを見きれなかったんだけれども、それは展示の量が多すぎるためであって、イベントとしては十全な時間配分になっていたと思う。

第二に goo ラボの説明がなかったのが良かった。goo は NTT レゾナントが開いている一種のポータルサイト。NTT 研の成果をテスト公開したり、産学連携サービスの公開の場にもなっている。何故「goo ラボ」の名称で NTT の研究開発フォーラムに参加できるのかと言えば、goo が NTT レゾナントのサイトで、NTT レゾナントが NTT の関連会社だから。2009 年はこの関係を説明するためだけにブロガー・ミーティングの貴重な時間を割いた。お陰でただでさえ短かった展示を見る時間が、更に短くなった。でも、そういう情報はネットを調べればすぐ分かる。すぐ分かることを説明するために、自由時間が割かれるのはもったいないと思っていた。今回はそういう「無駄」をザックリと省いたので、自由時間が増えて良かった。強いて言えば、goo と NTT レゾナントと NTT 研究所の簡単なレジュメを一枚用意したら良かったかな。帰りにブロガーが電車の中で読める程度のもので。

第三に展示のグループ分けが良かった。今回の展示の概略を書くとこうなる:

  1. 創る ICT: ユーザーが使うサービス、アプリ、基礎技術に関する展示 (コンシューマー、ビジネス)
  2. 支える ICT: 医療/公共サービスなどで使われるサービス、技術に関する展示
  3. 進化する ICT: NTT の「通信事業」の根幹となる基盤技術・研究に関する展示

ぼくは「創る ICT」の展示しか見る時間がなかったのだけど、「サービスを使う人間」が興味を持っている情報が一か所に集まっていて良かった。公共サービスの様に、ユーザーにサービスを提供する人達への技術というのも面白いけれども、ぼくの様な人間には少し遠い。基盤技術 (フレキシブル・ネットワークの構築とか) なんか、研究者としての興味はひいても、ブログに書いて面白いものでもない。そういうわけで、展示のグループ分けが良くなったので、研究所内をあちこち動き回らずにすんだのは助かった。

最後に、NTT の研究開発がよりユーザーに近くなったと感じた。HTML5 を使ったデモ、Android アプリ、iOS アプリ、Twitter との連携 etc. よりユーザーに身近な展示(研究・開発・デモ)が多かった。比べて 4 年前。サーバー上で動くシステムがメインだった。面白いとは思ったが、「身近さ」を感じなかった。時代の趨勢もあると思う。スマートフォンやタブレットが一般化し、サーバーだけでやらなきゃいけない時代が終わりを迎え始めている。4 年前は「我々の技術でこんな未来を思い描く」展示が多かったが、2012 年は「我々の技術はこう使える」展示が多かった。

ぼくが見た展示

ぼくが見た展示の一覧を載せる。特に興味を持った展示については、後で記事を書く。

2012-02-15

Google Public DNS for IPv6 公開

Google が Google Public DNS の IPv6 版をリリースした。アドレスは以下の通り:

2001:4860:4860::8888
2001:4860:4860::8844

Google Public DNS とは

DNS はホスト名・ドメイン名と IP アドレスの関連付けを行なうサービス。インターネットに公開されているコンピューターは全て IP アドレスを持っている。が、それは数字の羅列なので人間向きじゃない。そこで人向けに「名前」を付けるアイデアが生まれた。Google の場合 www.google.com という具合。これがドメイン名。

でも、コンピューターは全て「IP アドレス」で管理しているので、ドメイン名を与えられたって困ってしまう。そこで、DNS (Domain Name System) サービスがドメイン名と IP アドレスの紐付けを行なっている。

ウェブ・ブラウザーのアドレス欄にドメイン名を打ち込んだり、リンクを跳ぶ時も、この DNS にアクセスして IP アドレスを取得している。当然 DNS の性能が高ければ高いほど、ウェブ・ページへのアクセスが速くなる。そこで、Google が高速な DNS サービスを提供した。それが「Google Public DNS」。

普通、DNS はプロバイダーが提供しているものだけれども、Google Public DNS を使うとより高速になる、というのがウリ。最初にこのサービスがリリースされたのは 2009 年 12 月。当時は IPv4 用の Google Public DNS しか用意されていなかった。ちなみに、そのアドレスは下記:

8.8.8.8
8.8.4.4

2012 年 2 月。ようやく IPv6 用の Google Public DNS もリリースされたという次第。

これから IPv6 に移行が進むとされているので、こういう動きは非常にありがたい。

2012-02-14

オーディオ電源対策: ノイズ・フィルター付コンセントを使う

オーディオ・システムをある程度揃えると、周りに目を向ける様になる。スピーカー・セッティング、ルーム・チューニング、各種オーディオ・ケーブルのグレード・アップ etc.。その一つに電源の強化がある。

オーディオ機器は電源に敏感で、(日本なら) 100V の「キレイ」な電源が来ることを想定して作られている。ところが、夏のマンション住まいではエアコンの消費が激しく電源は 100V を切る。インバーター製品を使うと、電源にノイズが乗る。他にも色々な問題があって、本当に「キレイ」な電源を得ることができない。

そこで、クリーン電源や(電源の)アイソレーションなどといった機器が発売されている。価格は安いもので 10 万円台。高いものは 50 万円を越えてくる。

そんなに高い物に手は出ないよ! と諦めていた所、面白い記事を見つけた。

家庭内の電気ノイズに目をつけて対策を行なうというもの。普通は、オーディオ専用の「電源」機器をオーディオ・システムに繋ぐのだけどれども、逆の発想で「ノイズ・フィルター」をノイズを出しそうな機器のコンセントに繋いでオーディオ側にノイズを回さない様にしようというアイデア。

買ってみた

上記エントリーで紹介されていた機器を買ってみた。

ELECOM OAタップ(雷サージ対応) KT-180
ELECOM OAタップ(雷サージ対応) KT-180
ヤザワ ノイズフィルター集中SW付3個口1m黒 SHV1513BK
ヤザワ ノイズフィルター集中SW付3個口1m黒 SHV1513BK

ELECOM のタップは 527 円。ノイズ・フィルター付。コンセントの数は 2 つ。

ヤザワのタップは 800 円。ノイズ・フィルター付。コンセントの数は 3 つで、集中コンセント・スイッチ付。

効果のほどは...

ELECOM のタップは、常に起動している冷蔵庫に使った。ヤザワのタップは、電源のノイズを沢山出しているという PC 系のタップとして使った。

これらのタップを挿すと、音楽が力強くなった。グッと押し出す感じが強くなる。ボリュームを大きくした時にようやく聞ける迫力が、普段の音量で楽しめる。ちょっとしたクリーン電源を買ったのかと思うほど。

欠点もある。スピードが遅くなった。音の立ち上がりが鈍くなった。ピアノを打鍵した時、今まで聞いてた音よりも音の出が遅くなっている。

あとがき

長所と短所がはっきりしているので、好みに合わせて使い方を考えれば良い。スピード感のあるジャズやロック、クラシックを聞くには不向き。だけど、同じロックでもボーカルを力強く聞きたい場合は OK。という具合。

値段が千円を越えないのも嬉しい。一つ買って、ワン・トライ。駄目でもそれほど財布に響かない (10 万円を越えるオーディオ専用電源と比べて)。

もう一点。既に家の中で「ノイズ・フィルター」付のタップを使用していないか? ちょっとチェックしてみる。もし使っていて、音楽がどうも今一つ「楽しくない」と思っているなら、一旦タップを外してみる。これで音楽が楽しくなるなら、「ノイズ・フィルター」なしのタップに買い換えたら良い。

ちなみにぼくは、短所の方が気になってこれら「ノイズ・フィルター」付タップの利用は止めた。新しく電源タップを買う時も、ノイズ・フィルターのない物を選んで買っている。

蛇足

回路に詳しいひと二人にこの話をしてみた。

一人は、家全体を回路だと簡略化して考えてみると、ノイズ・フィルター付きのタップを導入するのは回路にコンデンサーを付けるのと同等になるのではないか? との意見。回路のことは分からないけれども、上に書いた様な長所・短所が現れることになると言う。

もう一人はもっとオーディオと回路に詳しい人の話。「家庭の電源回りは、家々で違っていて一般論がないんだよね」とのこと。結局、家全体を回路として考えれば良いという話は同じなんだけど、家によってその「回路」が大きく違う。だから、自分の家で効果があっても他の家でも効果がないかもしれない。オーディオの電源を取るコンセントの位置と、ブレーカーの位置と、ノイズ・フィルターを付ける位置。やりよう次第では悪影響なしに効果を出すことも出来るかもしれない、し、できないかもしれない。

そういうわけで、オーディオをやっている人は、こういうやり方もあるんだな... 程度で受け取めてもらえれば嬉しい。

2012-02-13

スイカ・チャージ機能付クレジットカードのスイカ機能を間違えてオフにした

タイトルの通り。

三菱東京 UFJ 銀行のカードを持っている。IC キャッシュ・カード、クレジット・カード、Suica が一体になったカード。Suica にはオート・チャージ機能が付いている。

これを誤まって Suica 機能をオフにしてしまった。

解決方法

結論: 再発行しかない。

Suicaチャージ残額払い戻しの方法

JAL カードの説明がスクリーン・ショット付きで詳しい。

手順は以下の通り:

  1. 駅の ATM「VIEW ALTTE」を使う
  2. 「Suica付きビューカードの更新/退会」を選択
  3. 「Suicaチャージ残額の払戻し」を選択
  4. Suica 機能付のカードを入れる
  5. クレジット・カードの暗証番号を入力する
  6. 「確認」ボタンを押す

「Suicaチャージ残額の払戻し」を行なうことで、その Suica カードにチャージされているお金が返金されると供に、チャージ機能が無効になる。

何故、間違えたのか?

カードの更新時期になって、新カードが送られてきた。普通はそこで旧カードを捨てるのだけれども、Suica チャージ機能付きカードの場合、チャージされたお金は新カードに引き継がれない。引き継ぎ機能があると楽なのだけど、旧カードを「Suicaチャージ残額の払戻し」するしか方法はないらしい。

ということを緑の窓口で教えてもらった。VIEW ALTTE なんて ATM があるのを知ったのも、この時。

旧カードを入れて残額を払戻し。ここで暗証番号を間違えた。これが一つ目の誤ち。記憶を辿って、暗証番号を思い出す。そして新カードを挿入。これが二つ目の誤ち。本当は旧カードの Suica 機能をオフにしようとしていたのに、気が付いたら新カードのスイカ・チャージが使えなくなっていた。

たらい回し

困った。新カードはこれから何年か使うのに! このお馬鹿さん!!

まず駅員さんに聞く。クレジット・カードと一体になっているので、駅ではどうしようもないとのこと。カードの裏にクレジット・カード会社の電話番号があるのでそこに電話するか、VIEW ALTTE の中の通話機 (エレベーターの中にある緊急電話みたいなの) を使って欲しいとのこと。

手始めに VIEW ALTTE の通話機を手に取る。事情を説明すると、クレジット・カード会社に問い合わせて欲しいとのこと。

帰宅後、クレジット・カード会社に電話。Suica のことなら、駅で対処できるはずという。それでだめなら、再発行しか手がないらしい。新カードの再発行は (紛失ではないので) 無料で行なってくれるとのこと。

翌日、まず駅へ。カードを調べてもらう。Suica としては機能しているとのこと。で、改札機を通ろうとすると赤ランプ。チャージされない。ダメですねぇ。ということで銀行へ。

窓口の人がクレジット・カード会社に電話。銀行のキャッシュ・カードでも、クレジット・カード機能が付いていると銀行の担当ではなくなるらしい。おまけに Suica の機能も付いてるわけで、電話口からも「駅では復活できなかったんですね?」みたいなやり取りが聞こえる。色々手を尽くすも、再発行しかないと結論。

再発行には、窓口で書類を書いて、印鑑を捺印して、身分証明書を提示。3 週間くらいしたら、新カードがやってくるってさ。

あとがき

本エントリーが同じ誤ちをした人の参考になれば嬉しい。

あと、スイカ・チャージできるカードの「新カード」が届いたら、旧カードから残金を引き落とすのを忘れないようにね。

2012-02-10

IE に textContent は使えない

さっき、Firefox に innerText は使えないから textContent を使いませう、と書いたばかりなのに、今度は textContent が IE で使えないと言う。

ここで 2 つの選択肢が浮上。

  1. ブラウザー判定をして、textContent と innerText を使い分ける
  2. innerHTML を使う

今回、問題になっているコードでは innerHTML で十分。機能過多な気もするけれど間違いがない。一方、ブラウザー判定を入れると他のバグが混入しそう。バグが出るよりもシンプルなコードで。KISS!

(旧) a.textContent = post_title.textContent;
(新) a.innerHTML = post_title.innerHTML;

蛇足

メモ代全りに

  • innerText は IE が独自導入したプロパティ。W3C 非公認。Firefox 以外のブラウザーがサポート。
  • textContent は W3C が標準化したプロパティ。IE が非サポート。
  • innerHTML は W3C が標準化したプロパティ。全てのブラウザーがサポート。innerText/textContent がテキストだけを返すのに対して、innerHTML は HTML 要素もそのまま返す。

ref

Firefox に innerText は使えない

JavaScript でプログラムを書いたら、Firefox で動かないとバグ・レポートが入った。innerText が問題という。調べてみると、Firefox で innerText が使えないのは割と有名な話らしい。

このブログの記事の通り、innerTexttextContent に置き換えたら問題なく動くようになった。

問題のソースコードは下記:

(旧) a.innerText = post_title.innerText;
(新) a.textContent = post_title.textContent;

あとがき

こういうバグ・レポートをもらえたのも、ソース・コードを公開していたからだと思う。今回は丁寧にも innerText が問題ではないか? と原因の考察付きだった。そこまで分かれば解決策を見つけのは易い。

仮に原因が見つからないにしても、「Firefox で動かない」だけでもバグ・レポートをもらえると助かる。こちらは全てのブラウザーでチェックしているわけではないので。

ともかく、これで「目次」ウィジェットは Firefox でも動くようになった。バグ・レポートに感謝。

2012-02-08

Google Chrome for Android (beta) リリース!

ついに。Google Chrome の Android 版がリリースされた。対象は Android 4.0 (Ice Cream Sandwitch)。

上記サイトには解説ビデオもある (英語だけど)。

Chrome for Android の利点は何か。列挙してみる。

  • 最新の HTML5 要素に対応
    • ハードウェア支援付きで Canvas を描画
    • overflow scroll (?) に対応
    • HTMLL5 video をサポート
  • Indexed DB のサポート
  • WebWorkers のサポート
  • Web Sockets のサポート

読んでいるだけでも、楽しくなっちゃう。

あとがき

Android が初めて出た時、標準ブラウザーは Google Chrome のコードを使っていると云われた。後に事実誤認と判明。その噂を打ち消すように、いずれ Google Chrome のコードは Android に統合されていくと説明があった。そんな話があったのは Android のバージョンが 1.X をうろうろしていた頃。

そして遂に、Chrome は Android にやってきた。

お金がなくて Android 実機を買えない。ICS の入ったタブレットを買いたい。買いたい。買いたいよぉ。

ブログ・デザイン変更

clmemo@aka のデザインを変更した。旧テンプレートと自家製 CSS ファイルに、さようなら。新テンプレートに、こんにちは。

新しいテンプレートは良いね。twitterFacebookGoogle+ との連携ボタンを簡単に付けられるし、サイドバーを 2 列にすることもできる。Google Analytics との連携もテンプレートをいじらず、設定ページからちょちょいのちょい。

旧ブログのテンプレートでは、本文の横幅が狭かったけど、新テンプレートは巾が広い。これは、PC のディスプレーが大画面化してきたことと、スマートフォン用に別スタイルを適用できることが効いているのかな。

最近は Blogger に新機能が追加されても、旧テンプレートだからチェックできないことが多かった。でも、新テンプレートに移行したからには、新しい情報をどんどん届けて行きたいね。

あとがき

新テンプレートに移行したのは、ようやく「目次」ウィジェットを完成させたから。Blogger の今の弱点は、トップ・ページやラベル・ページを見た時に、どんなタイトルがあるか分からないことだと思っていた。そこで、昔はテンプレートをいじって「目次」を作ってた。でも、新テンプレートでは「ウィジェット」でそれをやりたいと思っていて... それが出来なくって移行がずるずると延びていた。

今日、「目次」ウィジェットを公開して枷がなくなった。「目次」ウィジェット、よければ使って欲しい。ついでに、「+1」してくれるとやる気が出る :)

ref

Blogger 用「目次」ウィジェットを作った

新テンプレート向け。サイド・バーに「目次」を表示するウィジェットを作った。見た目は以下の通り。コンパクトさを第一に考えて作ったので、ちょっと見栄えが悪いかもしれない。

インストール

下のボタンを押すだけで、ウィジェット登録画面に入れる。

ソース・ファイル

本ウィジェットのソース・ファイルは github で公開している。

パッチは大歓迎。

裏話

過去に、テンプレートをいじって目次を作る方法を解説した。

テンプレートを使う方法は、目次としてかなり良いものになったと自負している。一方で、テンプレートを編集する分、難易度が高かった。

そこで、「ウィジェット」を使って目次を作ろうと思った。けれど、ウィジェットを調べていくうちに、Blogger のテンプレート用の要素が使えないらしいことが分かってきた。テンプレート用のウィジェットが使えないと、同じ様な目次は出来ない。一度、挫折した。これが 2 年位い前のこと。

気を新たに、作り始めたのが当ウィジェット。まず、サイド・バーに置くことを前提にした。そして、「日付」を付けないシンプルな形で妥協することにした。あとは JavaScript を思い出しながらソース・コードを書くだけ。最初は ul 要素を使ってリスト表示にしようとした (github の最初のリビジョンでそのバージョンを見ることができる)。ところが、テンプレートのデフォールトでは ul 要素のスタイルが無効にされていることが分かった。これが、ぼくの選んだテンプレートだけのたまたまなのか、それとも全てのテンプレートに当てはまるのか... 調べるのが面倒だったので、リスト表示はやめた。もっとシンプルを目指す。それで出来たのがこのウィジェット。

ブログ・タイトル同士を「★」で区切る方法は、新聞の「天声人語」を真似した。

あとがき

ウィジェットの利点は、ボタン一押しで追加できること。テンプレートをいじったりと、難しいことをしなくていい。本ウィジェットが役に立つことを願う。

2012-02-04

Mac OS X 10.7.3 へのアップデートは控えたほうが良い?

マイナビ・ニュースに載っていた注意書きを転載。

米Appleが2月1日(現地時間)に配布を開始したOS X Lion向けの「10.7.3」アップデートだが、これを導入したユーザーから「再起動後すべてのアプリケーションが謎のエラーメッセージを出してクラッシュする」という現象が多数報告されている。(中略) 何らかの報告があるまではユーザーは10.7.3へのアップデートを控えたほうがいいかもしれない。

OS X Lion 10.7.3適用で多数のクラッシュ報告 - 状況判明まで様子見を | パソコン | マイナビニュース より引用

こりゃまいったね。ぼくは、まだ 10.7.2 のままなのでクラッシュ被害は受けていない。

逆を返せば、どれ位いクラッシュするか分かっていないんだけどもね。

まあ、脊髄反射のアップデートは止めて、少し様子見かな。

2012-02-03

オーディオ・ミニ オフ会を開いた

B.B. Audio Review のばーそんさんをお招きして、自宅にてオーディオ試聴会を開いた。ばーそんさんは、ぼくをオーディオの道に引きずり込んだ人で、いつもオーディオの相談にのってもらっている。

先月。ばーそんさんのオーディオと自宅のオーディオを聞き比べる機会があった。ばーそんさんのシステムは、まだ自分の目指している音が出ていないとのことだが、左右の音の繋がりが素晴らしい。その点、ぼくのシステムは真ん中が大きく盛り上がってしまう。例えば左から右へ流れる様な音楽があったとすると、ちょうど中央の辺りで音が山を描く様に上へ行ってしまう。中央で歌っているアーティストは何か周りの音に比べて少しビック・サイズになってバランスが悪い。

原因は大まかだけど分かっていた。スピーカーの間に置いてある三段のラック。これがよろしくない。

家のオーディオ・システム

そこで一念発起。三段のラックを二段に変更。今まで、上から CD プレーヤー、BD プレーヤー、アンプと置いていたところ、BD プレーヤーをラックの外に出してみる。これで、完璧にはまだ遠いけれど、人並みのレベルにまでは落ち付いた。その旨をメールして、意見を伺ったのが今回の自宅試聴会。

オーディオ・システム 2012-02-03

試聴会にて

チェック用にかけた CD は 2 枚。フリッツ・ライナー指揮によるベートーヴェンの交響曲第 7 番とエヴァ・キャシディのテネシー・ワルツ。

ベートーヴェン:交響曲第7番 [xrcd] Imagine

まずは前回に比べて音の繋がりが良くなったと、お墨付きをもらう。ありがたや。

次に今の不満点を挙げてもらった。

一つ。左のスピーカーの広がりが良くない。これは、左スピーカー前に在る布団の位置を調節。これで随分良くなった。布団が吸音材になっていた模様。

一つ。スピーカー端子が汚れているっぽい。無水アルコールで、とりあえず汚れを取るべし。これは後でやる。

一つ。低音のキレが今一つ。解決策提示なし。

一つ。高域の音がキツイ。プリ・アンプとして使っている Primare I30 の電源供給が良くないのか? ばーそんさん自ら、電源回りをいじり始める。タップの上流から、CD プレーヤー/プリ・アンプ/パワー・アンプと挿していたコンセントの順序を変える。変更後は プリ・アンプ/CD プレーヤー/パワー・アンプに。そうすると、確かに音のキツさが取れた。CD プレーヤーのコンセントをパワー・アンプの前にするか後ろにするかは、宿題とのこと。勉強になります m(_ _)m。

一つ。昔 (2〜3 か月以上前?) と比べてホール・トーンが出ていない感じ。音が重い。これは... どうしようね。もっとフワッとした感じの音にしたいのだけど、イメージだけで解決策は思い浮かばず。

こんな感じで、また一歩だけど音が良くなった。自分だけでオーディオ・セッティングしていると、どうしても一人よがりになっちゃうので、客観的な意見をもらえるのは非常に助かる。ありがとう。

まったりと

オーディオ・システムのチェックを終えたら、音楽を聴いて楽しい時間を過ごした。ペトゥラ・クラーク、天使にラブ・ソングを、ロッキーのテーマ、007 のテーマ、ピンク・パンサーのテーマ、Hello Troll。あれ、思い出してみると、今回はサントラを多くかけたなぁ。

Classic Collection 天使にラヴ・ソングを・・・ ロッキー(1) Best of James Bond Hello Troll

追記

大したオーディオ・システムじゃありませんが、もしオフ会をご希望の方がいらっしゃったら、コメントでお知らせ下さい。うちは狭いので、ちゃんと音を聴こうとすると一人をお招きするのが精一杯ですが、他の人にも聞いてもらいたいな、と思っています。

現在のシステム

ラックは Quadraspire Q4D Vent、CDプレーヤー・プリアンプ間のケーブルは Jorma Design XLR No.2、プリアンプ・パワーアンプ間のケーブルは Jorma Design RCA No.2、スピーカー・ケーブルは Jorma Design No.3。