はてなが、ウェブアプリケーション作成の基本を学ぶための「はてな教科書」を github 上に公開した。ライセンスは「クリエイティブ・コモンズ 表示 - 非営利 - 継承 2.1」。
この教科書は、エンジニアの手によって執筆されており、サマー・インターンシップなどでも利用されているとのこと。現在の目次は次の通り:
はてなのサマー・インターンシップの様子はブログで公開している参加者も多い。彼らの様子を見ていると、非常に難易度は高そう。経験者でも、Perl, JavaScript の勉強にはもってこい? フレームワークへのとっかかりとしても良さそう。
はてなが、ウクレレのタブ譜を表示するためのウクレレ記法をサポートした。はてなダイアリーやはてなグループで、利用できるという。
ウクレレのタブ譜がどんなのか知らない方は、上記リンク先で実物を確認して頂きたい。
かくいうぼくも、ウクレレのタブ譜なんか見たことなかった ^^;。パッと見、4 弦ギターのコードみたいに見える。
バックエンドでは、tex 記法 (ref. 数式を表示する [tex記法]) と同じやうなことをしてるんでせう。技術的にそれほど驚く事じゃあない (MusicTeX というのもあるしね)。けれど、やるなら、もっとメジャーなギターとかでしょ。それを、ウクレレ譜でやろうってところがすごい。はてならしいなぁ。こんな感じで、どんどんと面白いサービスを、はてなには作り続けて欲しい!
先日、Amazon に注文していた「Ajax イン・アクション」が届いた。
原題「Ajax in Action」。Dave Crane, Eric Pascarello, Darren James 三氏による共著。監修はあの株式会社 はてな! Ajax の基礎から開発に必要な技術・情報を網羅した、決定版ともいうべき内容らしい。そのページ数、653 (日本語版)。帯には「Ajax のすべてを一冊に凝縮」と「全米コンピュータ書ランキング 三週連続 一位」とある。
さて、ページを繰れば最初に現れるのは、はてなの CTO 伊藤直也氏の「監修者まえがき」。
ぼくは、このまえがきの第二段落目で、早くも挫折しかけてしまった。もしかしたら、同じように躓く人もあるかと思い、少しばかり駄文を書いてみる。
まず問題の箇所を、引いてみませう。
いま、ウェブアプリケーション開発の世界は過渡期にあります。
ドキュメントを閲覧することを主目的に設計されたウェブブラウザーがアプリケーションインターフェイスの表現力に乏しいというのは当然のことで、その制約の中でウェブアプリケーションを構築することに疑いを持つ人はそれほど多くありませんでした。
ぼくが混乱したのは、「その制約の中で WA を構築することに疑いを持つ人は多くなかった」という文章 (WA=ウェブアプリケーション)。まず「その制約の中で」は、「Ajax なしで」と言い換えてもいいでせう。次に「多くなかった」は「少なかった」と言い換えられる。すると「疑いを持つ人は少なかった」は「ほとんどの人は〜〜と信じていた」となって、元の文意は「ほとんどの人は Ajax なしで (Gmail のような) WA を構築できると信じていた」となる。これはおかしいよね。「できない」と思ってたことが「Ajax」で「出来た」ってのが「Ajax」のウリなんだから。
さて、何を読み違えたのか見て行きませう。
まず第一段落。たったの一つの単文から分かるのは二つの事柄:
「過渡期」を日本語辞典で引くと「ものごとの移り変わっていく、途中の (安定していない) 時期」とある。つまり「旧」から「新」への移行。読者はここで、「旧」いものが何を指し、「新」いものは何だろう。きっと、「新」いものへ移ることになった「何か」を説明するんだろうな... と予想する。上手い書き出しだね。
問題の二段落目。第二段落は一つの複文から構成される。これは二つの単文に分けられる。
一つ目の単文から分かるのは...
ここから、二つ目の単文の「その制約」が指すのは、ウェブブラウザーは「文書閲覧専用」「アプリケーション作成に不向き」という制約と言えやう。二つ目の単文は次のよう読める。
さあ、今こそ、ぼくが文章のどこを読み誤ったかを示そう。
一つは、ウェブアプリケーションを勝手に「Gmail のようなウェブアプリケーション」と解釈したことにある。ここで伊藤氏のいうウェブアプリケーションは、Ajax が使われていない頃のウェブアプリケーションも含む。というより、いわゆる Web 1.0 的な (今から考えると) 使い勝手の悪いウェブ・ブラウザー上で動くアプリケーションを指している。
もう一つは、「疑いを持つ」の解釈。ぼくは、「疑う人が少い」ってのは「ほとんどの人が信じてる」って解釈したけど、そうじゃなかった。ここは、「(現状に) 疑いを挟む」と解するべきだった。つまり「(現状に) 疑いをはさむ人が少い」=「現状をあたり前と思っている」と解釈すべきだった。
上記のぼくの誤りを踏まえて、第二段落を直すと、次のようになる。
「まえがき」は、「アプリケーションインターフェースに乏しい (=アプリケーション作成に不向き)」という前提が、Ajax の出現によって崩れ、動的でリッチなウェブアプリケーションが作れるようになったと続く。
実は「Ajax イン・アクション」はまだ第一章も読み終わってない。というか「まえがき」ばかり読んでいた。けれど、目次と本文のつまみ読みの感想として、Ajax に興味を持つ人にはお勧めの本なのではないかと思う。書店で見かけたら、手に取ってみてはいかがでせう。
Ajaxイン・アクション
Dave Crane Eric Pascarello Darren James
インプレス 2006-06-09
売り上げランキング : 261
Amazonで詳しく見るby G-Tools
2006-04 初めに行われた mixi による「レイアウトに関するアンケート」の結果が、2006-04-25 に発表された。過去記事はこちら。
アンケート結果の要点は以下の通り。
詳しくは、mixi の「運営者からのお知らせ」をお読み下さい。
今回のアンケートについて、「サービスの利用者に対して使い勝手を聞く」という意味で、ぼくは好感を持ってる。ユーザーの声を聞こうという姿勢は、これからも無くさないで欲しいと思う。
ところで、このアンケートが行われていることを、どれ位いのユーザーが気付いていただらう。例えば、POLAR BEAR BLOG さんは、アンケートが行われていることに、ぼくがコメントして初めて気付いたという。
確かに@akaさんに教えてもらえるまで知りませんでした。それこそページ上部のバナー部に表示しても良かったのに・・・。
アンケートの告知は、POLAR BEAR BLOG さんのおっしゃる「バナー部」にこそなかった。けれど、それより少し下の「運営者からのお知らせ」にはリンクがちゃんとあった (スクリーン・ショットを取り忘れたのが痛恨!)。mixi 運営者側からすれば、かなり分かり易い所に「告知」はした、といえるかもしれない。
ただ、いちユーザーの意見を言えば、「運営者からのお知らせ」は読まない。ウェブページのバナー広告を、意図的に読み飛ばしてしまうように、あそこのスペースも読み飛ばしてしまう。それは、自分にとって重要なメッセージがそこにない、という経験による。同じ理由で、3 カラム目の mixi ニュースも読み飛ばす。
今回は、正にその経験則が外れた例ですな。
だからといって、「運営者からのお知らせ」を読むようになるか? きっと、それはない。時間が余って、ボケっとした時に、ちょっと意識を向ける位いだらう。今回、ぼくがアンケートの告知に気付いたのは、そうした「閑」があったから。運が良かったんだと思う。
公式アナウンス部分を読まない理由を、ぼくは「いつもそこに有益な情報がないから」と書いた。もし、誰かが、自分に必要な情報をフィルタリングしてくれたら、ぼくは公式アナウンスを読むでせう。そのフィルタリングに、ぼくはブログを (無意識に) 使ってる。
mixi のレイアウトが変更された時、色んなサイトが文句の声を上げた。ぼくのブログ巡回路で、いくつもそういう記事を目にした。だから、mixi のレイアウト問題は、皆の観心を集めていることなのだと気付くことができた。これは、重要な情報をブログがフィルターしたってことなんじゃないかな。
ところが、今回のレイアウト・アンケートについては、言及してるブログに出会わなかった。ブログ検索をかけてみても、今回のアンケートのヒット数は (思いのほか) 低い。もしかして、みんな「運営者からのお知らせ」部分を読んでなくて、気付いてないんじゃないかと疑ってしまう (回答総数 25,000 は、多いようにも見えるけど...)。
mixi 運営者であれば、有名ブロガーの知り合いも多いでせう。例えば、ネタフルさんとかに根回しして、「重要な情報」だけブログに取り上げてもらうようにする。そういうアナウンス方法もありなんじゃないかな。つまり、はてなだね。面白いサービスをリリースしたら、個人のブログでも取り上げる。通り一辺倒な、公式ブログじゃなくて、非公式なブログを活用する所に、多くの人の目を引きつける力があるんじゃなからうか。
昨日取り上げたはてなのアンケート、結果が出たように思える。
アンケートの設問は、はてなダイアリーの RSS フィードを「全文」配信するか「抜粋」配信するか。回答数は、21 時 50 分現在、賛成 334、反対 506。回答数上限は 1000 件とあるので、現時点で反対が過半数となり、全文配信の否決は決定的。
アンケートについて各々で色々とつっこみが入ってるけど、それは別エントリーで書くとしませう。
今回書きたいのは、「アンケート」がまだ続いてること (21 時 50 分現在)。はてなが、回答数上限を増やすのでもない限り、もう賛成票が反対票を上回ることはない。これ以上続ける必要があるのかしらん。過半数を越えた時点で、反対 500、賛成約 330。そういう結果でよくないの? 賛成派としては、もう票を入れても決定は覆らないのだし、投票するモチベーションが下がってる。反対派も、自分の意見は通ったのだから投票のモチベーションは上がらない。結論は出ているのに、既定の 1000 票が集まるまでアンケート主催者側がアクションを起こさないというのは、いかがなものか。
では、片方の意見が過半数となったらアンケートを打ち切るのか? いやいや、そうじゃない。アンケートの回答数に上限を定めるんじゃなくて、「先に 1000 票取った意見を採用」。こっちの方が分かり易いんじゃないかな? もし、1000 vs 999 みたいな接戦になったら、1500 まで投票を延長するとかしてもいいと思う。
今のやり方だと、過半数後に入った票はノイズになりそう。それで、1000 票分のアンケート結果として出しても、正確性に欠けるでせう。
Panoramio というウェブ・サービスがある。
Google Maps API で作られてて、地図に写真をアップロードできる。Flickr と地図を融合させたようなサービス。ecmannaut の記事で存在を知った。
ちなみに昨日書いた Google Maps API で作ったサービスの左下に Google Local へのロゴが付くってネタも上のブログで仕入れたもの。
話を Panoramio 戻して...
Panoramio のトップページには、右手に地図、左手に地図内の写真一覧が表示される。地図にはピンが立ってて、マウスを上に持ってくと写真一覧で対応する写真の枠が赤くなる。同じように写真にマウスを持ってくと、地図内の対応するピンが赤くなる。地図で見てる場所を変えると、写真一覧もその動きに追随する。写真をクリックすると大きなサイズの写真とユーザーのコメントが見られるって寸法。
Panoramio の感想は次のサイトが詳しい。
利用は無料で、今の所、アップできる写真の量に制限はないみたい。
日本のウェブ・サービスで同じようなことをやってる所といったら、はてなね。はてなフォトライフにアップした写真をはてなマップに表示することができる。
Google Maps API を使ったサービスは、世界中で使える (Livedoor 地図 とかは日本限定)。これって、表示言語さえ対応すれば、海外のサービスを日本で使えるようになるし、日本発のサービスを世界中で展開させられるってことなんだよね。日本で写真コミュニティー的なサービスって、はてな位いしかやってないような気がする。どうなんだろ、英語版とか作んないのかな?
Google Maps には API が公開されてて、腕に覚えがあれば地図サービスが作れちゃう。clmemo@aka で紹介してきたサービスだと、ブログ人マップにはてなマップ、SLOPE FINDER が Google Maps API を使って開発された地図サービス。
先日レビューした「ウェブ進化論 (梅田望夫)」によるとはてなマップは
エンジニアが一人はりついて実質五日でできたものですから、トータル五人日というところですね。人月のコスト計算は特にしていませんが、開発費はせいぜい数十万円というところでしょうか
とある。開発は API が公開されて数日後に始められてるそうだから、ノウハウの蓄積されてない状態で 5 日。完璧を目指さなければ、趣味の時間を使って個人が地図をいじられる時代が来てしまった。
さてさて、Google Maps API で作った地図の左下を見て欲しい。「Powered by Google」というロゴが表示されてるのが見えるでせう。実はコレ、Google Local へのリンクになってる。単なる Google の宣伝ロゴじゃないんですな。
しかも、リンク先は Google Local のトップページじゃない。リンク元の地図で見ていた場所が直接表示される。もし、東京の 23 区を見ている途中なら、23 区の Google Local ページに跳ぶし、京都を見てるなら京都の Google Local に跳ぶ。
これはユーザーにとっても便利。例えばはてなマップの写真を見て、休みにそこへ遊びに行こうと思い立ったとする。行くなら、近くの食事処や駐車場もおさえておきたいよね。マップ左下の「Powered by Google」ロゴをクリックして Google Local に行き、「お食事」または「駐車場」と検索する。スムーズに地域検索に移れるわけ。
一方、サービスの提供側にとっても大きなメリットがある。地図サービスを作ると、地域検索との連携をしたくなるものだけど、Google Maps API を使うとそういうのを全部 Google に投げてしまえる。どんなに大したことないサービスを作っても、その後ろに Google Local という優秀な地域検索を持つ事が出来る。言い換えれば、余計なサービスに頭を悩ませず自分の個性あるサービス作りに取りかかれるという事だね。
Google Maps API と Google Local。なかなか侮れませんな。
地域検索との連携という意味で、はてなマップの「トリノ」に写真がほとんどないのがもったいない。オリンピックで写真を撮ったら、はてなマップに写真をアップしやうよ。現地に行ってるブロガーは、いないの?
POLAR BEAR BLOG で知ったのだけど、OCN のブログ人がOCN Blogzine ブログ人「ブログ人マップβ」なるサービスを始めたそうですな。
どういうサービスかというと、地図にトラックバックが打てるという。Google Maps API を使った流行のマッシュ・アップ。ブログ人でブログを作ってる人しか使えないのかと思ったら、誰でも OK みたい。
ブログと連携できる地図サービスを始めたのは、ブログ人が最初じゃない。Livedoor 地図は、とっくの昔に地図にトラックバックを打てたし、はてなマップには写真やコメントが入れられた。
記事を書くに当たって、ひさしぶりに両サービスを覗いてみた。Livedoor 地図は航空写真をサポート (Livedoor 地図は Google Maps を使っていない)。はてなマップは、トラックバックにも対応していた。いつの間に...
トラックバックの打てる三つのサービスを比べてみる。まず、Livedoor 地図は日本だけしかサポートしていない。近場のお祭程度なら十分だけど、海外旅行に行くと厳しい。利点は、「ルート検索」や「駅」の表示なんかと連携が取れることかなぁ。
はてなマップ、ブログ人マップは Google Maps を使ってるだけあって、世界中、どこでもトラックバックできる。どちらの地図にも RSS が用意されてて、「場所」に根ざした情報が手に入るようにしているのだなぁと思う。
ブログ人マップは、地図右横に「地図内の最新記事」一覧でトラックバックの概要を表示させるようにしていてよい感じ。サービスを始めたばかりだからか、動作は少しもっさりした感じ。
はてなマップは先行サービスなだけあって、動作も軽快だし、「写真」「キーワード」「トラックバック」「クリップ」をチェック・ボックスで選べれたりとインターフェースもこなれてる。地図から情報を探すのに、「新しいもの順に表示」と「中心点に近い順に表示」を選べるのもいい。それからトラックバック元にはてなマップへのリンクを付けることを義務付けて、トラックバック・スパムをはじこうとしてる。ブログ人はどうなのかな?
最後に、はてなマップは、Account Auto-Discovery を使ってはてなアカウント情報をトラックバックに追加できる。ふつう、はてなユーザーは自分用の地図を持っていて、自分がトラックバックした情報だけを表示させられる。すると、ぼくのように Blogger でブログを書いてる人間は、はてなアカウントを持っていても自分専用地図にトラックバック情報が反映されない。そこで、はてな外からのトラックバックでも、はてなアカウントを持ってる人に門戸を開くのが Account Auto-Discovery。
使い方は、次のページに詳しい。
時間が経てば、地図はトラックバックだらけになるでせう。特にイベント会場。例えば、東京ドームとか幕張メッセとか六本木ヒルズとか。東京ドームの話をすれば、ぼくが東京ドームの中に入ったのは野球を観るためじゃなくて、「世界らん展」が目的だったように思う (何年前のことだらう)。当時ブログがはやっていたら、ぼくは「東京ドーム」にトラックバックしているブログを読んでいたかも知れない。そんな時、会期にトラックバックされた情報だけ表示できれば楽だろうと思う。
どこの地図サービスも、そういうことはやっていないね。情報が増えれば増える程、時間で絞る、キーワードで絞るといったことが必要になると思う。見やすく、情報を探し易いトラックバック地図が欲しいなぁ。
キーボード・マクロって知ってる? キーボードへの入力をキーボードに覚えさせて、それを使いまわすもの。手順としては
という感じ。
本当にこういうことがしたければ、キーボードにメモリーを載せなきゃいけない。ほとんどのキーボードは、そこまでお金をかけてないから、たいていソフトウェア側がキーボード・マクロをサポートしている。
今回は、Emacs が実装してるキーボード・マクロについて。
Emacs のキーボード・マクロ記憶開始キーは C-x (、キーボード・マクロ記憶終了キーは C-x )。C-x e で最後に記憶させたキーボード・マクロを呼び出す。
例えば次のテキスト
Excel: 表計算 Word: ワープロ PowerPoint: プレゼン ...
を
<dt>Excel:</dt> <dd>表計算</dd> <dt>Word:</dt> <dd>ワープロ</dd> <dt>PowerPoint:</dt> <dd>プレゼン</dd> ...
という HTML の定義リストに直すには、こんな感じにキーボード・マクロを活用する。
C-x ( # キーボード・マクロ記憶開始 <dt> # <dt> を入力 C-s : # ':' を検索 (C-s は検索コマンド。カーソルは ':' の後ろへ) </dt> # </dt> を入力 C-f # カーソルを右へ一つ移動 <dd> # <dd> を入力 C-e # 行末へ移動 </dd> # </dd> を入力 C-n # 次行へ移動 C-a # 行頭へ移動 C-x ) # キーボード・マクロ記憶終了 (一行分の処理を覚えさせた) C-x e # 記憶したキーボード・マクロを呼び出し C-x e # 記憶したキーボード・マクロを呼び出し ...
100 回キーボード・マクロの呼び出しを実行する場合は、C-u 100 C-x e。
Emacs-22.0.50 だと、二回目以降のキーボード・マクロ呼び出しを e だけでできる。つまり
C-x e C-x e C-x e ...
という呼び出し作業が
C-x e e e ...
という風に簡略化できる。
はてな人力検索の
に山下達雄さんが dmacro.el を紹介する回答を返していて
dmacro.el も便利だけど、Emacs-22.0.50 のキーボード・マクロにもこんな Tips があるよ〜、と書こうと思ったら前半が長くなっちゃった。う〜ん、反省。
そうそう、先のはてな人力検索にはぼくも回答してる。初人力検索!
