2009-11-07

Google Reader がウェブクリップに使える件

毎日使うサービス(ツール)でありながら、今日まで気付かなかった。 Google Reader でウェブクリップができる。なんというか便利だ。

準備編

Google Reader を開き、左上のメニュー(?)から「共有アイテム」を選択する。これで右側のメインエリアが共有アイテム一覧の表示に変わる。

このとき、共有アイテム一覧の上にユーザのプロフィールの内容などが表示されているが、その右に「Google リーダーでコメント」というボタンが置かれている。うっかりすると見落としがちだが、これが今回の記事の主役だ。

このボタンを説明文の通り、ブックマークバーにドラッグしておく。これで準備完了。

実践編

では、実際にクリップしてみよう。

クリップしたいウェブページを開いて、クリップしたい領域を選択する。画像がふくまれていても OK。続いて、ブックマークバーの「Google リーダーでコメント」ボタンを押す。ウィンドウが開いてコメントを入力できる。「Post Item」ボタンを押して完了。

デフォルトではコメントを Google Reader で共有するようになっているが、コメント入力ウィンドウでチェックボックスを外せば、自分だけのメモとしても使える。

試しに、Apple のサイトから MacBook のページをクリップしてみた。それを Google Reader で開いたものがこれ。レイアウトまでは再現できないけど、画像もふくめて取り込めているのがわかる。

もちろん、Google だからクリップした記事を検索できる。Google Reader 内の検索ボックスを使えば OK。クリップしたテキストはもちろんのこと、コメント部分もきちんと探してくれる。

考察編

Google Reader にウェブページのクリップを取り込めることの、どこがウレシイのだろう? それはウェブで収集する情報を一カ所に集められる、という点だ。

わたしの場合、ネット上の情報収集の主要な部分は Google Reader を使った RSSフィード経由の活動になっている。後からゆっくり読もう、もう一度読みたい、そういうアイテムには「☆」をつける。他の誰かに伝えたいと思ったら「共有」だ。Google Reader はウェブ上のサービスだから、場所も端末も選ばない。Mac mini でも MacBook でも、iPhone でさえも同じ「情報の集積所」を見ることができる。

ただ、ネットのすべての情報を RSS フィード経由で得られるわけじゃない。実際、わたしも一部はニュースサイトや何かを見て回る。そういうときに見つけた情報を保管しておきたければブックマークかウェブクリップになる。気になる箇所を明確にできることからブックマークよりもウェブクリップの方を使うようになってきた。このウェブクリップを Google Reader に集約することができれば、Google Reader がウェブから集めたすべての情報の倉庫になる。

Evernote や、かつての Google Notebook のように、ノート(メモ)アプリにウェブクリップ機能を取り込んだものは多い。しかし、RSS リーダーに組込むという発想はなかった。だから、今日まで気付かなかった。この「Google リーダーでコメント」ボタンは何度も目にしていたのに。

なんにせよ、Google Reader すごいわ。もう、なんていうか、Google、バンザイ!

関連リンク

2009-11-06

物読みファイル

「物読みファイル」は、このブログのメインテーマの1つ。 元は独立したブログとして書いていたもの。現存するわたしのブログのうちでもっとも長く続いたものだった(途中、長期間の休止状態があったりもした)。一番古い記事は2006年10月の始め、もう3年もたったのか。ブログの説明文は「毎日、何かを読もう。少しでも良いから読もう。で、それを記録していく。ただ、淡々と記録してみる。」。ちっとも、この通りじゃなかったけど。

何か「読んだモノ」のことを「LOG+REPO」に書くときはこのテーマとする。ただし、Mac や iPhone、そしてプログラミングに関する読み物については、「Macをプログラムする」として書く。

ラベルは「1. 物読みファイル」を使う。

ブログパーツとしても貼ってあるが、本の購入の記録に Media Marker を利用している。読了時のコメントも短いものはそちらに書くことが多い。Media Marker のコメントと Blogger が連携してくれたりするとうれしいんだけどね。

10歳になったGoogle ([著]Googlerたち, [版]Official Google Blog) #9

もう一年以上前になるけど、Google が 10 歳の誕生日を迎えたときに、一連の記事がOfficial Google Blog に投稿された。それからしばらくして、ふと思った。これを読めば、Google の目指す姿が見えるだろうか、と。当時、10 本あった記事(その後、少し増えたようだ)のうち、断続的に 8 本まで読み、それぞれコメントを自分のブログに書いた。そこで止まっていた。それがずっと気になっていた。

ブログも新しくしたことだし、残りの 2 本も読んでしまおうと考えた。で、そのうちの 1 本を、今、読んだところ。あれから 1 年以上ってことは、もう 11 歳なんだけどね (タイトルが期限切れだよ)。

The next Internet -- Posted by Vint Cerf, Chief Internet Evangelist (9/25/2008)

WWW 出現以前のインターネットでは、コンピュータと人を「つなぐ」ことがすべてにおいて重要だった。TCP/IP というプロトコルはもちろん、各種のサービス(とそのクライアント)はつながることを最重要課題としてきた。WWW 以後、インターネットに「コンテンツ」が流れ込んできた。それが Google を始めとする検索エンジンを生み出すことになった。続く10年間では、人はさまざまなモノにつながることになるだろう。デスクトップコンピュータや、ケータイのような情報端末を通してネットにアクセスできるだけではない。眼鏡やカバンやクルマの鍵といった、身につけるものがネットを経由して人々とつながる。もう、眼鏡を探して家中を歩き回ることはない。ケータイを通して Google に聞けば良い。「わたしの眼鏡はいったいどこにあるんだ!?」。「あなたの頭の上ですよ」、すぐに Google が教えてくれる。

前半をざっと読むとこんな感じ。その後、動画配信と電気分配の話題を経て、こう続く(↓)。

A box of washing machine soap will become part of a service as Internet-enabled washing machines are managed by Web-based services that can configure and activate your washing machine. Scientific measurements and experimental results will be blogged and automatically entered into common data archives to facilitate the distribution, sharing and reproduction of experimental results. One might even imagine that scientific instruments could generate their own data blogs.

洗濯機の話はどうでも良い。おもしろいのは後半。ネットにつながった実験機器がブログを書く(生成する)かもよ、ってところ。何がおもしろいかって? 実験データやら観測データがネットに流れるということは、そう、Google の手が届くってことだ。世界中のあらゆる実験や観測の結果が Google に集積されるってことだ。それがどうした、って? まず、他の誰かがやっている実験や観測のデータを簡単に参照することができるようになる。次に、それら膨大なデータの処理に Google の計算パワーを使えるってことだ。

ちょっと想像してみてほしい。世界中にいるプロやアマチュアの天文学者が夜空を観測するために望遠鏡を設置する(自動観測だとしよう)。解像度(っていうのか?)も様々な望遠鏡だが、みなネットにつながっていて、観測したデータは丸ごとネット上に公開されている。それを Google がかき集めて、比較、対照、検証やら何やらを計算パワーにあかせて行う。もちろん、Google Galaxy を作るためだ。そのついでに太陽系をうろつく彗星の発見なんかも自動的にやってしまう。人はいらない。機器とGoogle(のコンピュータ群)だけで完結する世界。

ちなみに、この記事の執筆者である Vint Cerf は「インターネットの父」(の一人)と呼ばれる人物。Google に入ったのは 2005年9月だとのこと(Wikipedia:ヴィントン・サーフ より)。

関連記事

MacPorts で Git をインストール

ブログのテンプレートをいじったりしているので、テンプレート(XML)のバージョン管理をしようと思い立った。Snow Leopard には Subversion (/usr/bin/svn 等)が標準で用意されている(開発ツールをインストールしたからかも)んだけど、せっかくなので Git に挑戦してみたい。まずは Mac mini Server に ports まかせで Git をインストール。手順はこれ(↓)だけ(「入門 git」の p.17 より)。

% sudo port install git-core +svn +doc

依存するパッケージも多数、未インストールの状態だったため、かなり時間がかかった。およそ 30 分。↑の port コマンドが完了した後は、こう(↓)なった:

% git --version
git version 1.6.5.1

これで完了、と思ったら、ports tree を更新していなかったことを思い出す。

% sudo port sync

古くなっているものがないか、確認してみる。

% port outdated
The following installed ports are outdated:
db46                           4.6.21_5 < 4.6.21_6       
git-core                       1.6.5.1_0 < 1.6.5.2_0     
sqlite3                        3.6.19_0 < 3.6.20_0

や、やられた〜 orz。更新しておく。

% sudo port upgrade outdated
--->  Computing dependencies for db46
--->  Fetching db46
...
--->  Extracting git-core
--->  Applying patches to git-core
--->  Configuring git-core
--->  Building git-core
--->  Staging git-core into destroot
--->  Deactivating git-core @1.6.5.1_0+doc+svn
--->  Computing dependencies for git-core
--->  Installing git-core @1.6.5.2_0+doc+svn
--->  Activating git-core @1.6.5.2_0+doc+svn
--->  Cleaning git-core

今度はすぐに終わった。

% git --version
git version 1.6.5.2

ミッション・コンプリート。今日はここまで。

2009-11-05

MVC と Cocoaバインディング

ヒレガス本、Chapter 8 から Chapter 16 までのまとめ (ただし、Chapter 11 は除く)。

(p.124)
Over the next few chapters, you will create a full-featured application (・・・中略・・・) As this book progresses, you will add file saving, undo, user preferences, and printing capabilities.

これらの章では一つのアプリを継続して作る。少しずつ機能を追加していき、一般的なアプリに必要とされる機能を網羅した状態にまで作り込む (Chapter 27 ではさらに印刷機能が追加される)。

ここで作るアプリ自体に実用性はないが、備える機能はどうしてどうして立派なものだ。上記の引用にもある通り、GUI を使ったデータの入力・編集に始まり、編集時の Undo (と Redo)、ファイルへのセーブ(とロード)、環境設定用のパネル、そして GUI 部分の翻訳。機能を羅列すると入門書のサンプルプログラムとは思えないものだ。これは Cocoa と Objective-C の特性による。

実際にサンプルコードを打ち込みつつ、本に書かれた通りに作っていくと、打ち込むコード量に驚く。実現する機能に比べてあまりにも少ないから。↓がそのサンプルアプリだ。扱うデータはごく単純なものなので、何をするアプリなのかはウィンドウを見ればわかるだろう。

送信者 Macをプログラムする

このサンプルアプリを構築するために使われている主な技術を挙げてみよう。

各種 GUI 部品(ビュー)
ここでは表形式でデータを表示するための部品(table view)が主役になる。
ターゲット-アクション
GUI 部品(ビュー)とアプリのコードをつなぐ仕組み
キー値コーディングとキー値監視
オブジェクトのプロパティに対して、直接メソッドを呼び出すのではなく、名前を文字列で与えて間接的にアクセスする仕組み。
通知
あるオブジェクトの変更を他のオブジェクト群に知らせる仕組み
アンドゥマネージャ
undo と redo の仕組み
アーカイブ
データの保存(セーブ)と読み込み(ロード)の仕組み
ユーザ設定
ユーザ設定の保管と読み込みの仕組み
Info.plist
データを保存するファイルの拡張子やアプリのアイコンなど、付加情報の設定。

Cocoa のアプリは MVC アーキテクチャで作られることになる。フレームワークが提供するのは主にビュー(GUI 部品)、さらにビュー (V) とモデル (M)、コントローラ (C) をつなぐための仕組みだ。アプリプログラマはモデルとコントローラを書くことになるが、モデルとコントローラのためにもいろいろと便利な技術が用意されている (NSArrayController とか)。

MVC アーキテクチャは、1 つのシステムを 3 つの部分に分けて作ろうという設計思想だ。当然、それぞれの部分は他から独立していることが望ましい。独立性が高いほど、別々に作りやすくなるし、再利用性も高まる。一方で、最後は 1 つのシステムとして連携しなければならないのだから、間をつなぐ仕組みが必要。この「つなぐ仕組み」次第で 3 つの部分の設計(と実装)のしやすさが変わる。Cocoa で、この「つなぐ仕組み」として提供されているのが、「ターゲット-アクション」であり、キー値コーディング、キー値監視による「Cocoa バインディング」である。

「ターゲット-アクション」は、主にビュー(GUI 部品)とコントローラの「つなぎ」として使われていて(GUI 同士もこれでつなぐ)、一方「Cocoa バインディング」はモデルとコントローラの「つなぎ」になる。これらの特徴を端的に表現すると、「どこにつなぐかを実行時まで決めない」となる。実行時になってから決めるということは、コンパイル時には知らなくても良いということだ。だから、別々に作って、別々に配布・展開できる。Cocoa が提供するビューは、コントローラがどんなアクションを備えているかを知らない。Cocoa が提供するコントローラ(の再利用できる部分)は、モデルがどんなプロパティを持っているかを知らない。知らなくて良い。アクションやプロパティとの「つなぎ」はコンパイル時のリンクとは別の仕組みで伝えられるから。動的言語である Objective-C ならではの仕組みと言える。

「Cocoa バインディング」についてもっと知りたいんだが、ヒレガス本も荻原(2.0)本もこれについては詳しくはない。ここは原典というべき ADC ドキュメントに取り組むしかないようだ。このあたり(↓):

これの前提条件として、以下の文書を読め、と書いてある:

ちなみに *1 によれば、「Cocoaバインディング」が使えるようになったのは OSX の version 10.3 からだとのこと。Panther だ。

追記@2010-12-01

その後 Cocoa バインディングについて調べたり試したりしたことをまとめた記事をいくつか書いた。

関連記事

ひとまず完成

最初の段階でやりたかったことはほぼできた。いつまでも外見ばかりをいじっていても仕方がない。ひとまず、ここで完成とする。残っている項目は、またしばらくしてから挑戦しよう。

あと残っているのは・・・

  • テンプレートをカスタマイズ (日めくりみたいな日付表示にしたい; そのための素材)
  • iPhone での表示に対応する (CSS を追加だけで良いのか?)

簡単にここまでの経過を書いておく。ベースとするテンプレートを探すのはあきらめた。B:Templatesには確認しきれないほどの量があるが、なかなか思うとおりのものは見つからない。それならいっそ自分で作ろうという気になった。実際には、Blogger の標準テンプレートに手を入れて、今のものが出来上がった。変更したのは、(a) カラムを 3 つにした; (b) 色をあちこち変えた(オレンジっぽく); (c) エントリ部分の行間を大きくした; (d) ヘッダの直下にメニューとなるリンクを置いた。そのぐらい。

カラムを 3 つにする方法については、そのうち書こう。

2009-11-04

スキャナは楽し

先日、SnacSnap S1500M を導入した。

送信者 Macをプログラムする

製品ページでは Snow Leopard (Mac OS X v10.6) は対応 OS とはなっていないが、付属の ScanSnap Manager (V3.0.10) で読み取り、テキスト認識ともに動作する。今のところ問題には遭遇していない。同梱されている Adobe Acrobat 8 Professional 日本語版 (Macintosh版) の方はインストールしていないので不明。

読取速度(解像度)は4段階あって、たいていのものはスーパーファインで十分。各種書類(請求書とか)や単行本などは十分、Mac の画面で読めるものになる。(サンプルはこちら)

使い方はとても簡単。スキャナ本体のふた(?)を開き、スキャンしたい書類等をセットし、蒼く、淡く光るボタンを押すだけ。↑のスーパーファインなら「20枚/分」なので、かなり高速。それでいて両面が読み取りできている。これまでスキャナには触れてこなかった身には新鮮な驚きがあった。最初にスキャンしたときは
「え、ホントにこれだけで良いの
・・・(・ω・;)?」
そんな感じだった。一点注意すべきは、本体のボタンを押す前に Mac 側で ScanSnap Manager が起動していなければならないってこと。起動していないと、いくらボタンを押しても何も起こらない。

読み取り設定でテキスト認識を有効にすると、スキャン動作が終わった後、Mac 上の ScanSnap Manager ががんばる。それなりの時間がかかる。機器によるスキャンそのものが圧倒的に高速に思えるだけに、ここはちょっとガマンの時間だ。認識の品質は、さまざまなレイアウトが混じるような書類(クレカの請求書とか)だと認識できな領域が残るようだ。素直なレイアウトの単行本などはほぼ完全にテキスト認識に成功する。縦書きのものでも OK。当たり前のことだが、認識できたテキストは検索できる。ただ Spotlight 経由だとヒットする言葉とそうでない言葉がある。「プレビュー.app」の検索ボックスからならヒットするのに、Spotlight からではヒットしない。ちょっと残念。

とにかく高速な読み取りに感動する。当初は、家電の取扱説明書だとか、各種請求書だとか、なんかそういう雑多な書類を読み込んで、書類の方は捨ててしまう。そういう使い方だけを想定していた。けれど、これだけ高速な読み込みができると、雑誌やら本をスキャンしてしまおう、と欲が出てきた。内容、つまり情報だけが重要で、本や雑誌の実体そのものには特別な思い入れがない、ってものが結構ある。そういうものをスキャンして、実体は捨ててしまえば部屋がすっきりするんじゃないか。ScanSnap を使い始めると、sごく当然にそう思い始めてしまう。いわゆる「自炊生活」だ。

「自炊生活」が持たらすビジョンはすばらしい。難点は本や雑誌をバラす手間。時間と体力を要求する作業だ。理屈だけを言えば、ちょっと大きめのカッターがあればどんな本だってバラすことができる。実際にやってみるとこれが大変。200ページちょっとの単行本をバラすのに 30 分以上かかる。慣れればもっと短くなるとは思う。それでも、5 分で済ませられるとは思えない。こうなってくると、文明の利器の力を借りたくなる。断裁機が欲しくなる。PLUS社製 PK-513L が良いらしい。価格が高いけど。置く場所に困るけど。

2009-11-03

Adobe Player 9 と プレビュー.app

スキャンして PDF 化した書類やら本を iPhone で開くと、Mac の「プレビュー.app」で開いたときにくらべて見え方に差がある気がしていた。iPhone の方が文字がすっきり見える。アンチエイリアスの効果の差なのかもしれない。こういう印象は主観的なものだし、デバイスが違えば見え方も違って当然。深く追求しないでいた。

今日、ふと思った。同じデバイスで比べたらどうなんだろう、と。つまり「プレビュー.app」と他の PDF ビューアで同じ PDF を開いて比較するということ。で、そのために Adobe Reader を Mac mini にインストールしてみた(↓)。

送信者 Macをプログラムする

せっかくだし、両者の違いを画像で比較してみよう。等倍表示だとちょっと画面で読むには厳しいサイズなので、快適に読める程度に拡大してある。2つのアプリウィンドウを並べて、同じぐらいに見えるように調整した。


これが Adobe Reader 9 (Mac OS X Intel版; version 9.2.0) の表示サンプル。


一方、こちらが Snow Leopard 標準の「プレビュー.app」で同じ文書を表示させたサンプルだ。

どちらも、「グラブ.app」で範囲選択による画面キャプチャをしたもの。PNG に落としてあるけど、印象の違いは見てとれると思う。

twitter でもつぶやいたけど、Adobe Reader は「すっきりだけど、ちょっとかすれている」、プレビュー.app は「ぼんやりして、ピントが合っていない」、そんな印象。もっと主観的に表現すれば、Adobe Reader は「本をコピーして読んでいる」感じで、プレビュー.app は「老眼や疲れ眼になって近くの文字がにじんで見えている」ってところ。

もとが本をスキャンして PDF 化したファイルだし、アンチエイリアスの効果は人によって好き嫌いが分かれるものだから、どっちが良いと断定するつもりはない。というか、わたし自身は、↑の2つのどちらも嫌い。iPhone で見た場合は、この両者のどちらとも違う印象で、一番好みに合う。けど、iPhone だと本をスキャンさせるとちょっと文字が小さいんだよねえ。

ちなみに、↑のサンプルは「新科学対話」の p.215 から取った。

2009-11-02

Macをプログラムする

「Macをプログラムする」は、このブログのメインテーマの1つ。元は独立したブログとして書いていたもの。ブログの説明文は「Macを使ってプログラミングしよう。で、その過程をちくちく記録して、まるっと晒すためのブログ。」だった。ブログを「LOG+REPO」に一本化するにあたり、以後 Mac 関連のことはこのテーマとして書いていく。当面、iPhoneとそのプログラミングについてもこのテーマとして扱う。

「1. Macをプログラムする」をこのテーマのラベルとして使う。

ちなみに、うちにある Mac は 3 台。古い順に、PowerBook G4 (Ti で 1GHz)、MacBook (Early 2008)、そして Mac mini Server (Late 2009)。搭載している OS はそれぞれ、豹、雪豹、そして雪豹(サーバ)。

追記@2010-10-31

2010-08-02、上記に iMac (Mid 2010) の 27 インチ (2.8GHz Quad Core i5) が加わった。

twitterウィジェット

今、このページに組み込んである twitter のウィジェットは、twitter 公式サイトで提供されているもの。その提供しているページに行くのがちょっとややこしい。色を変えたり、サイズを変えたりするときにはまた訪れることになるので、メモしておく。

  1. まずはサインイン。
  2. 右上のリンクから「設定」へ。
  3. 「ユーザ情報」の中程にある「その他のURL」のすぐ下に「あなたのWEBサイトにもTwitterを表示させよう」と書かれたリンクがある。これをクリック。

関連リンク

Firefox 3.5.4 on Snow Leopard

Snow Leopard から Firefox をダウンロードしようとすると、こんなことを言われる(↓):

送信者 Macをプログラミムする
Snow Leopard では Firefox は使えないのか!! と、さびしくなってしまうが、実際には動く。何より Mozilla のサポートページにはこういう(↓)回答が掲載されている。

Apple 社の OS X Snow Leopard (10.6) は Apple OS の最新バージョンです。Leopard と同様に、Firefox 3.0 および 3.5 は Snow Leopard 上でも動作します。

同じページに、Snow Leopard にアップデートした場合にはクラッシュする場合があるとか書いてある(対処も記載されている)けど、うちのはクリーンインストールした Mac ばかりだから大丈夫(だろう)。

追加するウィジェットのリスト

「物読み」から:
  • MediaMarker の本棚
  • ブログリスト (「結城浩の日記」「Matzにっき」「steps to phantasien」「増井俊之の界面潮流」)
  • ネット上の読み物 (Google Reader の「共有」)
「Macプロ」から:
  • Links (「Snow Leopard Server Documents」「ADC」「Google Mac Developer Playground」「Mac OS Forge」「ダイナミックObjective-C」「HMDT」「Macをプログラムする(in Google Sites)」)
  • ADC Documents (「Cocoa Fundamental Guides」)
  • iPhone もプログラム (Google Reader の同名タグ)
  • Mac でプログラム (同上)
共通:
  • ラベル
  • ライセンス (CC - BY SA)
  • Blogger バッジ
  • Mac バッジ

全部追加すると、ごちゃごちゃしそうだな。3カラムのテンプレートにするつもりだけど。