Articles by michisu

最近、英語リスニングの練習として、CNN Student NewsというビデオPodcastを観ています。
アメリカの社会ニュースが中心ですが、学生向けとあって、クイズなどもありノリのいい番組です。ちゃんと聴き取れていなくてもそれなりに分かった気になれます。
先週、このPodcastで、マイクロブログのTwitterのことが取り上げられていました。
アメリカのデトロイトにあるHenry Ford Hospitalという病院の医療チームが、手術の経過などをTwitterに投稿しているみたいです。
手術中にいちいちノートPCに駆け寄って文字をタイプしている様子はちょっと変な感じでしたが・・・。
日本でも、決して多くはありませんが、内部の様子をリアルタイムでインターネット公開している保育園や病院がありますね。
もちろん最大限プライバシーに配慮する必要がありますし、情報公開によって隠れていた問題や軋轢が表面化されるようなケースもあるでしょうが、私個人は基本的に、このような公開の姿勢は組織の信頼につながると思っています。ただ、公開を継続するのはコストがかかりますね。
Henry Ford Hospitalの場合は、Twitter上で質問も受け付けているので、双方向のやりとりになっています。
間違った情報やプライバシーの侵害に気をつけながら情報発信し、質問に答えていくのは大変なことだと思います。
ですが、是非はともかくとして、これからまだまだ情報公開の流れが進んでいくのでしょう。企業などの情報公開を低コスト化、安全化できるソリューションがあれば大きく広まるような気がします。

「ある状態にたどり着くために必要だけれど、たどり着いてしまえば必要なくなるもの」を梯子に喩えることがあります。
極端な話、言葉というのはある意味ではそういうところがあります。
この喩えは、本来の意味とは違うかもしれませんが、哲学者ウィトゲンシュタインの言葉に由来します。

つまらない例ですが、例えば英語学習をしている時、単語帳で得た単語の知識は時間が経つとすぐに忘れてしまいます。
でも、そういうものだという割り切りが必要です。
単語帳で一気に大量の単語を記憶すると、期間限定ですが、英文を読む力が少しアップします。
一日しか効果が持続しない栄養ドリンクを飲んで、仕事に打ち込むようなものです。
それは本当の実力ではありませんが、自分に負荷をかけて実力アップする（＝生きた英文から語の使い方を吸収する）ための助けになります。

私が最近思うのは、梯子には長さがあるということです。
単語帳は短い梯子です。それだけにたくさんの数が必要なのです。
何かものごとに挑むとき、長さを見て梯子を使い分けるということができるのではないでしょうか。

外出先でメールなどを書くとき、私は一般的な携帯電話のキーで文章を打つ気にはなりませんが、iPhoneでなら何とかメールを書くことができます。
私にとっては、携帯よりも、iPhoneの画面に指をすべらせる方式のほうが圧倒的に速く入力できるのです。
でも、iPhoneの入力方式にもデメリットはありまして、その一つは、歩きながらだと非常に入力しにくいということです。
まあ、歩きながら入力するなという話ではありますが。
なぜ入力しにくいかですが、携帯の場合、ボタンの感触をもとに指をひっかけながら打つことができますが、iPhoneのインタフェースにはそのような物理的刺激がないので、今どのキーを触っているかは目で見て確認しなければいけませんし、つるつるのスクリーンなのですぐに指がずれてしまいます。
そのため、iPhoneの画面が、ソフトウェア制御によって、触っている指に軽い刺激を返してくるようになれば面白いと思っています。

同じAppleの製品で、最近のMacBookについているトラックパッドはとても便利です。
二本指で触って指を開くと画面をズームしたり、スワイプする（三本指で触ってそのまま指を滑らす）と、PDFを次のページに進めたりできます。
アプリケーションによっては、このトラックパッドの機能に対応していない場合がありますが、未対応のアプリケーションでもMultiClutchというソフトをインストールすれば、そのような動作を設定することができます。
私は、ブラウザはFirefoxを使っているので、三本指で横のタブに移動、上下スワイプで戻る、進む、というように設定しています。
こうしておけば片手で快適に操作できます。
Vimperatorアドオンにより、キーボードのホームポジションに両手を置いていればキーボードだけでリンクをたどっていくことができますが、気楽にウェブを見たい時は、キーボードはあまり使いません。
特にスワイプという操作は、指を適当な位置に置いて、適当な位置まで滑らせればいいので、実にいいかげんな動作でもちゃんと操作することができてうれしいです。

もう一つ、別の話。
普段あまり使っていないのですが、自宅にWiiがあります。今まで一番やりこんだゲームは「スーパーマリオギャラクシー」です。これは毎晩のように息子（当時五歳）と二人プレイをしていました。小さいお子さんのいるかたにおすすめです。
ところで、WiiにはOpera社のウェブブラウザがついています。家族がテレビでインターネット、というのはかなり惹かれるシチュエーションなのですが、結局私はこのブラウザを使っていませんし、使っている人はそれほど多くないと想像しています。
インターネットに接続している端末数でいえば少なくとも300から400万台にはなるようですが、私の経験の範囲では、Wiiからのネットサイトへのアクセスは非常に少ないです。0.1％は確実に下回っているというレベル。
私がなぜWiiのブラウザを使わないかというと、操作がけっこう難しいのです。Wiiリモコンをテレビに向け、ページの中のリンクをポイントするとリンクを開くことができますが、リンクにカーソルを合わせようとして、手が震えてしまいます。
ゲームならそれぐらいの難しさはあってもいいですけれど、ウェブサイトを見るためにはかなり面倒に感じてしまいます。
リモコンのセンサーを使ってだいたいの位置を指定し、その中から十字キーなどで選択できればいいのかなぁと思いますが、煩雑になるでしょうか。
漠然としていますが、加速度センサを利用してより曖昧な動作を受け付ける、というような可能性もあるかもしれません。
専門的な研究はよく知りませんが、曖昧な動作を受け付けるインタフェースというのは追究のしがいのあるところなのではないでしょうか。

ウェブがもっとカジュアルに使えるようになればいいですね。

今回も六本木ヒルズの百度さん会議室です。

18章の「行列分解と潜在意味インデキシング」を読みました。
潜在意味インデキシング（LSI）は、単語文書行列の階数を減らして、実質的に単語の次元数を縮約してしまう方法です。（用語があやしいです。間違ってるかもしれないので雰囲気で読んでください。）
普通のベクトル空間モデルと比べて嬉しいのは、単語の共起関係をインデックスの中に織り込んでしまうところ。
LSIを使うと、carやautomobileといった同義語を含む文書を一発で検索できたり、多義的な意味を持つ一つの言葉をより分けたりできます。
（後者は、私が以前いた会社の社長がよく使っていた例を借りると、車関係の用語と一緒の文書に現れる「ジャガー」は動物じゃなくて会社名ですよねーみたいな感じ。ただしシソーラスなどを使うわけではないので、LSIにはそれが会社名であるという意味は分かりません。）
残念ながら、計算コストが非常にかかるため、2008年時点で100万以上の文書セットに適用できた事例はないそうです。

線形代数の話がほとんどで、数学をまともにやっていない私には厳しい章でしたが、担当のid:sleepy_yoshiさん、裏担当？のはてなおやさんがホワイトボードを駆使した素敵な解説をしてくださり、ある程度イメージがつかめました。
（理解できました！と元気よく書けないのが悲しいところ）

一年以上続いた勉強会ですが、次回がいよいよ最後です。19から21章をまとめて読みます。
終わってしまうのはちょっと寂しいですが、勉強会が終わった後に成果を出さなきゃな、と思います。

私はバレンタインデーが近くなるといつも、あれ、もらうんだっけ？ 渡すんだっけ？ と分からなくなります。
間違えて姉にチョコをあげてしまったこともあります。
そんな興味のない（というと嘘ですが）日ですが、今年のバレンタインデーは技術者的には興味深い日です。
それは、Unix Timeが1234567890になるからなのです。

Unix Timeは1970年1月1日からカウントした秒数です。
1234567890になる瞬間は、日本時間では2009年2月14日8時31分30秒です。

$ python
>>> import time
>>> time.localtime(1234567890)
time.struct_time(tm_year=2009, tm_mon=2, tm_mday=14, tm_hour=8, tm_min=31, tm_sec=30, tm_wday=5, tm_yday=45, tm_isdst=0)

ちなみに、2005年の3月18日には、1111111111を通過していたようです。

(追記) UNIX time が「1234567890」になる - スラッシュドット・ジャパンにもこの話が出ていました。

New York Timesが検索APIをリリースしました。
1981年以降の280万記事を検索できるというもので、非常に画期的だと思います。
軽くPythonで試してみました。練習をかねて3.0を使っています。

nyt.py

#!/usr/bin/env python3.0
import sys, json
from urllib import request, parse

url_base = 'http://api.nytimes.com/svc/search/v1/article'
api_key = 'YOUR API KEY'
query = sys.argv[1]

url = '%s?%s' % (url_base, parse.urlencode({'api-key':api_key, 'query':query}))
page = request.urlopen(url)
body = page.read()
jobj = json.loads(body.decode('utf-8'))
print('hits:', jobj['total'])
for result in jobj['results']:
    print(result['date'], result['title'])

単純にHTTP GETしてJSONをもらっているだけです。
タイトルにjapaneseという文字を含む記事を検索してみます。

$ ./nyt.py title:japanese
hits: 4231
20090124 LETTER; Japanese Outcasts
20090114 As Japanese Premier Sinks in Polls, Top Lawmaker Leaves His Party
20081213 Japanese Leader Announces A Sweeping Stimulus Plan
20081130 DINING | NYACK; A Welcome Addition To the Japanese Menu
20081125 Motive in Japanese Stabbings: A Dead Dog
20081120 Japanese Are Irked by U.S. Interest in Pitcher
20081109 DINING | GARDEN CITY; Japanese And Thai Infused Dishes
20081018 Ken Ogata, 71, Versatile Japanese Film Actor
20081015 The Secret's Out as Japanese Stock Gains Fans
20081011 As Stock Falls, Morgan Looks to Japanese Bank

4231件ヒットしました。緒方拳さんが亡くなった記事などが出てますね。
タイトルにjapanese、abstractにfilmを含む記事を探してみます。

$ ./nyt.py 'title:japanese abstract:film'
hits: 11
20080130 Henry Froehlich, 85, Pioneer In Japanese Camera Imports
20070813 Japanese Film Winstop Prize In Locarno
20070525 Kei Kumai, 76, Japanese Director Who Specialized in True Stories
20051028 The Listings: Oct. 28 -- Nov. 3; 'NARUSE: THE UNKNOWN JAPANESE MASTER'
20030915 Japanese Film Wins at Toronto Festival
20030331 Avid Bourgeois Respectability, Japanese-Style
20020615 When Navajos Fought Japanese For Ne-He-Mah
20020120 FILM; Anime, Japanese Cinema's Second Golden Age
19990813 CRITIC'S CHOICE/Film; Young Japanese Rebels Adrift in Neon Nihilism
19970724 Japanese Agency Sees No Fuji Photo Violation

11件ヒットです。
まあ、これなら普通にサイトから検索できるのでしょうから、どうアプリケーションに組み込むかということですね。
安直に考えるとタイムライン上へのビジュアライゼーションなどができそうです。
利用条件はよく確認してくださいね。

英語学習を兼ねた海外ブログ記事紹介です。

Google Blames Human Error for Malware Warning Mistake

「Googleがマルウェア警告の間違いでヒューマンエラーを非難」
私は見なかったのですが、Google検索で、一時、全ての検索結果に”This site may harm your computer”と表示されてしまっていたそうです。

Googleの説明によると、この機能はStopBadware.orgの人手で整備された危険サイトリストを使っているそうですが、ヒューマンエラーで、そのリストの中に「/」というURLが紛れてしまっていたとのこと。これは全てのURLという意味になるらしいです。

全てのページにマルウェア警告を出すというのはあってはならないケースなので、あらかじめチェックしておくべきだったんでしょうね。なかなか事前に気づきにくいケースだとは思いますが・・・。
人手とのことなので、意図的な改ざんとかも心配になってしまいますが、その辺は大丈夫なんでしょうか。

Props to Google for responding so quickly, particularly during a weekend.

ブログの最後はこのように締められていました。
give props toで、脱帽するとか、敬意を表す、ということなので、「週末なのに素早い対応だった、敬意を表すよ」ということですね。

突然ですが、英語をもっとしっかり勉強しようと思います。

今まで海外のブログを読む時は、知らない単語などは飛ばしたりして適当に目を走らせていたのですが、もっとレベルを上げるために、一日に一、二本、ちゃんと調べながら読もうと思います。その記憶を定着させるために、内容をこのブログにメモしておきます。
というわけで、今後海外ブログのネタが増えると思います。

まずこの記事を読みました。

Confirmed: Apple and Adobe Collaborating on iPhone Flash - ReadWriteWeb

「確認済み: AdobeとApple、iPhone Flashについて協力中」ということで、iPhoneへのFlash(Lite)導入の件。

iPhone持ってない人には驚かれることがありますが、iPhoneでFlash動かないんですよね・・・。iPhoneでフルフラッシュのサイトを開いた時とか、ちょっと悲しい思いをします。
以前から話は出ていましたが、AdobeのCEO、Shantanu Narayenがインタビューで話したところによると、Appleと協力していて、今はAdobe側の仕事が進んでいるということです。

While Narayen didn’t answer the question of whether Apple had strengthened its commitment to putting Flash on the iPhone he did point out that the ball was now in Adobe’s court. “We have the developer kit and the onus is now on us,” he said.

onusは負担とか義務で、それが今は我々のところにあるとNarayanさんは言ったと。
今年中に実現するといいな、とReadWriteWebでは書いています。
私も楽しみです。

以前からマリーチではほぼ毎月、「公開アイデア」と題してサービスのアイデアを公開しています。
時間的、リソース的な問題で開発運営しきれないアイデアをアウトプットしていこうという試みです。
今月のアイデアは「勝手アワード」と「匿名インタビュー」です。
よろしければご意見などお寄せください。

いつもはアイデアの内容だけを公開するのですが、「勝手アワード」の話をしていて、ちょっと作ってみようかということになり、開発をしてみました。

勝手アワード

特に興味深い機能などはないのですが、雰囲気は伝わるかと思います。ちゃんと動きますので、ご自由にお使いください。

かなりシンプルなアプリケーションなので、仕様を考えながらプログラムのベースを作るのに一日、表示を整えたり細かい動作を調整するのに一日、で完成しました。
ロゴの作成にはLogogenerador.com - Generador de Logos web 2.0 Online、ボタン作成にボタン素材 自動生成サイト - ButtonMaker、一部素材に無料素材倶楽部｜商用利用・加工可ホームページ フリー画像集を使わせていただきました。
その上でサーバにセットアップします。

ちょっと前まではサービスを公開するために、専用サーバやVPSをレンタルすると、使える状態になるまでに数日かかっていました。
その後、Amazon EC2などを使えば、自前の設備を持っていなくてもオンデマンドでサーバを用意できるようになりました。
しかし、新規構成でサーバをセットアップする作業には、最小構成でも一日近くかかります。（最小構成とはいえ、その後の拡張などもちょっとは考えます。）
昨年四月にGoogleが提供しはじめたGoogle App Engineを使えば、サーバの操作に手を出せない反面、セットアップの手間が全く不要という利点があります。
コマンド一発で（Mac用のLauncherを使えばボタン一発で）本番環境へのアプリケーションセットアップが終わってしまいます。

サーバを操作できないことや、容量制限など、いくつかの壁はありますが、勝手アワードのような、ちょっと作ってみようというものの場合、Google App Engineは最適な選択肢だということが分かります。
容量制限のきついプレビュー版から従量課金制に変われば、そのまま運用し続けていくこともできるのですが、まだもう少しかかるのでしょうか。
今後もちょっとしたものはこのような形で公開していきたいと思います。