twitter より (2010-10-13)

• 10:47  む、MobileMe でパスワードが違うと言われる。変更してないぞ。何かトラブッてるのか？

Powered by twtr2src.

twitter より (2010-10-11)

• 04:09  グーグル、すげぇな。→ http://slashdot.jp/askslashdot/comments.pl?sid=510118&cid=1838053
• 10:48  ほお。Lisp電卓って感じだな。 RT @chaton_gauche: 齊藤: iPhone で動く R6RS Scheme が出たらしいです。 http://bit.ly/b8c9hz http://bit.ly/bEMoG4

Powered by twtr2src.

twitter より (2010-10-01)

• 13:38  サービスが立ち上がっても、twitter のクライアントがそれを使ってくれなければ意味ないよな。→ http://japan.cnet.com/news/service/story/0,3800104747,20420807,00.htm
• 13:44  URL短縮サービスのデメリットについてまとめた情報ソースってないかな。あと標準化の動きってあるのかな？
• 13:46  頭をしぼってドメイン名やアプリ名、サービス名を考える身にとってはションボリな仕組みだろうけど、便利なことは確かだからな。> URL短縮サービス
• 18:45  iTunes が 10 になってから曲名やアーティスト名から iTune Store に飛べなくなって不便だと思っていたけど、「Ping」ボタンを「▼」で開くとメニューが出てくるのね。わかりにくよ > アップル
• 18:46  というか、ボタンを押すとメニューが開くのか。「Ping」。

Powered by twtr2src.

既存のプロジェクトを github に公開する

ローカルで(つまり、手元の Mac や PC で)すでに git 管理しているディレクトリを github に公開する方法をメモしておく。単純な手順だし、ヘルプにも詳しく書かれているからそれを見れば良いだけなんだが、いずれ自分視点での記録も重宝するはず。

以前に書いた記事の続きになる。よって、ここでは Github へのユーザ登録はもちろん、SSH 公開鍵の登録も完了しているものとする。

手順

公開までの手順を段階に分けると以下のようになる。

1. github に新プロジェクトを登録する。
2. ローカルのリポジトリで、Github のプロジェクトリポジトリをリモートリポジトリとして追加する。
3. ローカルからリモート(github)に既存のコミットを push する。

1. プロジェクトの登録

github にログインし Dashboard を開くと、右のサイドバーに「New Repository」というボタンが見つかる。これをクリックすると登録の開始となる。

登録画面で指定する情報は 3 つ。「Project Name」、「Description」そして「Homepage URL」だ。大事なのは「Project Name」。ここに入力したものがそのままリポジトリ名(の一部)になる。ここで日本語を指定するとどうなるかはわからない。また、プロジェクト名が早い者勝ちなのかどうかは不明(たぶんそうだろう)。

「Description」と「Homepage URL」は登録後にプロジェクトの個別ページから変更できる。登録には空でも良いようだ(少なくとも Homepage URL を空にしても問題なかった)。

2. リモートリポジトリの追加

手元の git リポジトリに対して、コミットをやったり(push)取ったり(pull)するためのリモートリポジトリを追加する。

git のヘルプ(Creating a repo) にあるように以下のコマンドを実行すれば良い。実際には、foo を github のユーザ名、bar を手順 1. で作ったプロジェクト名で、それぞれ置き換える。

git remote add origin git@github.com:foo/bar.git

このコマンドの意味は、手元の git リポジトリに対して、origin という名前で git@github.com... のリポジトリを参照する、と宣言するものだ。つまり、リポジトリに(短い)別名を付けているのだ(↓参照)。

(「入門git」p.105 〜 106 より)
自分のデフォルトのリモートリポジトリには origin という名前が付いている。これは、何であれクローンしてきたリポジトリのフルネームに対する別名だ。

[...snip...]

自分のリポジトリに origin がなければ、git remote add で、origin を追加することができる。ローカルリポジトリを git init で開始した後、それをリモートリポジトリに送る必要があるときには、この方法が便利だ。

3. 既存のコミットを push

push コマンドは、その名の示す通り、手元のリポジトリに対するコミットをリモートリポジトリに送るものだ。git push A Bで、B のリポジトリに対してなされたコミットを A のリポジトリに送る、という意味になる。引数の順序が少し混乱を招くが(「push A to B」だと思うと逆の意味なる)、これは引数を省略できるという仕様によるものだろう。

(「入門git」p.103 より)
Git はこのコマンドがパラメータなしで呼び出されると、いくつか推測をする。まず、プッシュ先は origin リポジトリだろうと推測する。次に、リポジトリ上にある現在のブランチを、リモートリポジトリ上の対応するブランチ(もしあれば)に送信するのだろうと推測する。

push で指定するのは、まず「どこに送るのか」という情報であり、次に「何を送るのか」を指定する、と覚えれば良い。少し考えれば当たり前のことだとわかる。なぜなら「何を送るのか」は大抵の場合わかりきったことだからだ。だから「どこに送るのか」を指定するのだ。で、リモートリポジトリが 1 つしかなければ、それすらも明白なので省略可能なのだ。

実行結果

以下に、手順 2. 〜 3. を実際に実行している様子を示す。ここでは bloggerglass という GAE 上のアプリのソース一式を登録している。

[imac] mnbi% git remote add origin git@github.com:mnbi/bloggerglass.git
[imac] mnbi% git config --list
[...snip...]
remote.origin.url=git@github.com:mnbi/bloggerglass.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
[imac] mnbi% git push origin master
Identity added: /Users/mnbi/.ssh/github_id_rsa (/Users/mnbi/.ssh/github_id_rsa)
Counting objects: 42, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (42/42), 8.72 KiB, done.
Total 42 (delta 8), reused 0 (delta 0)
To git@github.com:mnbi/bloggerglass.git
 * [new branch]      master -> master

日々のコミット作業

リモートリポジトリを作ったからといって、ローカルで行う日常の作業はほとんど変化しない。唯一違うのはローカルリポジトリにコミットした後、リモートリポジトリへ push することが増えたこと。

先に例として挙げた bloggerglass では、今のところリモートリポジトリは 1 つで、ブランチも作っていないから、引数なしで push コマンドを実行するだけで良い。

以下に、push コマンドの実行例を示す。

[imac] mnbi% git push
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 425 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To git@github.com:mnbi/bloggerglass.git
   6057da1..7f9add6  master -> master

bloggerglassでは、すでに typo の修正やデバッグ用のコードの除去などで(...orz)、数回コミットを push している。↑の実行例もその 1 つ。

参考文献

入門git

Travis Swicegood
オーム社 ( 2009-08-12 )
ISBN: 9784274067679
おすすめ度:

物読みファイル (別館)で詳細を見る

MediaMarker

関連リンク

• Creating a repo (help.github)

関連記事

• Github に SSH 公開鍵を登録する
• SSH でリモートホストに別のユーザ名で接続する
• Python で書いたフィルタを GAE に載せる #3
• プロトタイプ版を github に公開 (Blogger Glass)

twitter より (2010-09-17)

• 12:10  「自炊」は違法？ それとも適法？→ http://internet.watch.impress.co.jp/docs/special/20100917_393769.html
• 12:14  iPad の公式クライアントと似た感じだな。→ http://twitter.com/newtwitter
• 17:18  QAHub 自体がおもしろそう。→ http://iphone.qahub.jp/

Powered by twtr2src.

GAE アプリによるスタイルシートの切り替え

簡単そうだと思ったのでやってみた。実際、簡単だった。要した時間のほとんどは Python の文法を調べることだった。

今回の切り分けでは、以下のようにリクエスト URL に応じて共通スタイルと機器用スタイルに分け、さらに機器用スタイルではユーザエージェントを使って実際の機器に合わせたスタイルに切り替えている。

リクエスト URL	返されるデータを収めたファイル
http://stylerepo.../logrepo/common	logrepo_common.css
http://stylerepo.../logrepo/device	ユーザエージェントに応じて logrepo_ipad.css や logrepo_imac.css に切り替える

つまり、以下のように 2 つのリンクを書くだけでデバイスに応じたスタイルに切り替えられるわけだ。

(スタイルへのリンク方法)
<link type='text/css' rel='stylesheet' href='http://stylerepo.../logrepo/common' />
<link type='text/css' rel='stylesheet' href='http://stylerepo.../logrepo/device' />

切り替えの仕組み

今回の変更で、stylerepo の構成は以下のようになっている。

(stylerepo アプリ構成の一部)
/stylerepo/
    +-- app.yaml
    +-- index.yaml
    +-- logrepo/
    |   +-- __init__.py
    |   +-- base.py
    |   +-- common_handler.py
    |   +-- default_handler.py
    |   +-- device_handler.py
    |   +-- logrepo_common.css
    |   +-- logrepo_ipad.css
    |   +-- logrepo_iphone.css
    |   +-- logrepo_mac.css
    +-- main.py
    +-- stylesheets
        +-- mac.css

前回の状態から logrepo ディレクトリが増えた。また、app.yaml にも手が入っている。

app.yaml

共通スタイルと機器用スタイルの切り替えはリクエストする URL を替えることで行う。この仕組みは GAE に用意されていて、設定を app.yaml に記述すれば良い。

app.yaml では、リクエストの URL パターンごとに処理を行うハンドラを記述する。この URL パターンの記述には正規表現が使えるためコンパクトかつ高機能な記述が行える。たとえば、以下のような記述。

(app.yaml より)
- url: /logrepo/(common|device)
  script: logrepo/\1_handler.py

この指定は リクエスト URL が /logrepo/common または /logrepo/device で終わっていた場合に、続くハンドラに処理させることを意味する。ここで common と device の選択は正規表現になっていて、実際のリクエストにふくまれている文字列(common か device) がスクリプト名の指定中では \1 として参照されている。すなわち、/logrepo/common でアクセスされたときには logrepo/common_hander.pyに、/logrepo/device としてアクセスされたときには logrepo/device_handler.py に、それぞれ処理が任せられる。

外部ファイルの置き場所としての Google App Engine

さて、前回(→ 外部ファイルの置き場所を求めて……)の記事では、外部 CSS ファイルの置き場所として Google App Engine (以下、GAE) にたどりつくまでを書いた。

GAE でやってみることにしたのは「静的なコンテンツを動的に生成しても良いじゃないか」と思いついたためだ。「なんとゼイタクな」とか「ムダなことを」なんていう声が頭の中を駆け巡りもしたが、現在のコンピュータ(とインターネット)にまつわる技術は、ある意味、計算と通信の資源を湯水のごとく使うことで発展してきたようなものだ。安価で(無料あるいはそれに近い価格で)提供される資源は、どんどん使うことが正義なのだ。ムーアの法則が成立する状況が続く限り「豊穣の時代」が続くのだ。いいじゃん、これぐらい。

「静的なコンテンツを動的に…」に思い至ったのは、コンテンツを要求する側(ブラウザ)にとっては HTTP の向こう側で何が起こっていても関係ないんだ、と気付いたから。ま、当たり前のことなんだけどね。

GAE アプリの作り方

GAE に登録

まずは、アカウントの登録。アカウント自体は Google アカウントだが、App Engine を使い始めるには携帯電話を使った認証が必要になる。具体的には、登録の際にロケーションと携帯電話のキャリアを選び、その SMS あるいは携帯電話用のメールアドレスを指定する。すると、携帯電話に認証コードがメールで送られてくる。そこに書かれたコードを登録画面で入力する、というものだ。

わたしの場合、iPhone のメールアドレス(i.softban.jp)を指定した。すぐに「Google App Engine Code」というタイトルのメールが送られてきた。中にあった 7 桁の番号を登録画面に入力して登録完了。

アプリケーション ID の登録

アカウント登録が完了したら、先にアプリケーション ID を登録してしまう方が良い。この ID を SDK でアプリケーション名として使うことになるからだ。また、この ID はそのままアプリの URL にもなる(独自ドメインを使う場合は別)。具体的には、helloworld という ID なら http://helloworld.appspot.com/ でこのアプリを開くことになる。

ID の登録は GAE の The Administration Console から行う。

アプリケーション ID は先着順。凡人がパッと思い付く程度の名前はもう大抵取られているよ。GAE を使う上で、ここが一番の難関かもよ(´・ω・｀)。

SDK をインストール

アプリの開発をするには SDK が必要で、Mac 版も用意されいる。ダウンロードした SDK のパッケージを開くと GoogleAppEngineLaucher.app がぽつんと入っている。これを /Applications にコピーすれば OK。

初回の起動時に、何やらコマンドラインのツールのシンボリックリンクを /usr/local/bin に作っても良いか、と確認してくる。OK を押せば確かに /usr/local/bin シンボリックリンクができている。おそらく、これは、ユーザが Terminal 上からも GAE Launcher の機能を使えるようにするための作業だろう。

初回起動時に現れる確認ダイアログ
シンボリックリンク張っても良い？	ここに張ったよ！

外部ファイルの置き場所を求めて…

CSS によるスタイル定義を外部ファイルにしたい

Blogger には画像とブログ自体のテキスト以外のデータを置く場所がない。Google の提供する他のサービスにも汎用のデータファイルをウェブからアクセス可能な形で保持してくれるものはない。そう思ってきた。だから、このブログのスタイルを変えるときにもブログのテンプレート自体に埋め込むしかない、と。

外部 CSS ファイルを使いたい理由

もし、CSS によるスタイル定義を外部ファイルにしてどこかに置けるなら、iPad (や iPhone) 対応もブラウザのユーザエージェントで切り分ける方法を取れる。メディアクエリーを使い CSS の中で対応するよりも、(デバイスの特性値の組み合わせではなく)デバイス自体を判別するという点でスマートだ。また、デバイスごとのスタイル定義をすべて読み込む必要もなくなり、ロードするサイズも減る。iPhone に iPad 用や Mac 用のスタイルを読ませることもなくなるわけだ。

けど、Blogger には、そして Google にも、外部 CSS ファイルを置く場所はない。

Google 以外のサービスはどう？

もちろん、レンタルサーバを借りるという方法がある。月額がワンコインで足りるものもある。CSS ファイルを置く程度のことならそれで十分だ。ま、そこまでするなら Blogger にこだわる必要もなくなる。レンタルサーバ上で WordPress なんかに乗り換えれば、こんなことや(スタイルを変更するために) Blogger のテンプレートの構造で悩むこともなくなる。けど、やはりネットの向こう側のことでは Google にこだわりたいんだよね。

Amazon が提供するウェブサービスに S3 というサービスがある。正式名称を Amazon Simple Storage Service と言い、そのものずばりの「インターネット用のストレージサービス」だ。「インターネット上の」ではなく「インターネット用の」になっていることに注目。つまり、インターネット上で稼動するウェブサービスから使われることを前提としたストーレジなのだ。

ここに外部 CSS を置くことはできるだろうか？ もう少し正確に言うと、S3 に入れたデータは HTTP 経由で公開アクセス可能なのだろうか？

(S3 公式サイト; Amazon S3 Functionarity より抜粋)
Authentication mechanisms are provided to ensure that data is kept secure from unauthorized access. Objects can be made private or public, and rights can be granted to specific users.

オブジェクト(ユーザが S3 に収めたデータをこう呼ぶようだ)は private にも、public にもできると書いてある。

(同上)
Built to be flexible so that protocol or functional layers can easily be added. The default download protocol is HTTP. A BitTorrent^TM protocol interface is provided to lower costs for high-scale distribution.

デフォルトのダウンロードプロトコルが HTTP だと書いてある。

ということで、(試していないから確実ではないが) HTTP でパブリックアクセスできるようだ。有料だけど、データのサイズと転送量が少量だから、びっくりする額になることはないだろう。レンタルサーバを借りるよりも(今まで経験したことがないから)おもしろそうだ。

とまあ、こんな流れで昨日まではすっかり、S3 を試すゾ、という気になっていた。今日、Google のあるサービスのことを思い出すまでは。

静的ファイルがダメなら、動的に作ってしまえば良い

何も CSS がファイルでなければならない理由はない。「ファイル」と呼んでいるものの、ブラウザにとって必要なのは HTTP リクエストに対して text/css で返されるデータストリームだ。サーバの HDD にファイルとして存在していようが、サーバ上のプログラムが生成したデータだろうが、ブラウザは気にしない。

静的な CSS ファイルを動的に生成してやれば良い。つまり、極端な例なら CSS のデータを文字列としてプログラムに埋め込んで、それを出力させれば良い、ってことだ。

これなら、Google のあのサービスが(きっと)使える。

twitter より (2010-08-25)

• 07:36  標準で装備してもおかしくない機能だよな。なぜ、ないんだろう？ → MacのMail.appで、PGP暗号化メールを送受信する http://www.goodpic.com/mt/archives2/2008/09/macmailapppgp.html
• 07:39  Blogger には画像以外のファイルの置き場所がない。たとえば、CSS、あるいは JavaScript。いっそのこと、Amazon S3 なんかはどう？→ http://www.goodpic.com/mt/archives2/2008/09/amazon_s3.html
• 07:41  単純に、任意の種類のファイルが置けて、HTTP でバプリックアクセスできるストレージが欲しいわけだ。なんで、Googleはやってくれないかねえ。

Powered by twtr2src.

Google Font API を使ったフォントの表示

(Google Font API - Google Code より)
The Google Font Directory provides high-quality web fonts that you can include in your pages using the Google Font API.

しばらく前になるが、Google がフォントの提供を始めた(今のところ、まだ beta 扱い)。フォントファイルを提供するだけではなく、ウェブページからリンクするサービスを用意することで、ページの表示時にブラウザがフォントを動的にダウンロードできるようにしたのだ。

使い方

ウェブページ用に使う方法

公式ドキュメント( "Getting Started - Google Font API" ) に書かれている方法は、HTML 中の LINK 要素を使い、Google Font API の URL に対してフォント名を指定するというものだ。以下の記述を HTML の HEAD 要素の中に記述する。

<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Tangerine">

スタイルの定義では、他のフォントと同じように扱うことができる。

font-family: "Neuton", Verdana, "HiraMaruProN-W4", serif;

このように指定すれば、英数字の部分については、Google Font API の Neuton または (Google Font API が使えないなどの場合は) Verdana が使われ、日本語部分に対しては「ヒラギノ丸ゴ ProN」が使われる。もし、3 つとも使えないなら、デフォルトの serif フォント(ひげつき) が使われる。

Mac 上の Safari で試すと、こんな風になる。英字部分には Tangerine、日本語部分には「ヒラギノ丸ゴ ProN」が使われていることがわかるだろう。「Making ...」の部分には影がかかっているけど、これは CSS の text-shadow で付けたのであって、Google Font API とは関係ない。

では、外部 CSS を使っている場合はどうすれば良いのか？ その場合は、@import で Google Font API の URL を(フォント名とともに)指定すれば良い。具体的には、CSS ファイルの先頭に以下のように記述する。

(外部 CSS の場合の記述例)
 1: /* Google Font API ( http://code.google.com/apis/webfonts/ ) */
 2: @import url('http://fonts.googleapis.com/css?family=Lobster');
 3: @import url('http://fonts.googleapis.com/css?family=Neuton');
 4: @import url('http://fonts.googleapis.com/css?family=Droid+Sans+Mono:regular');

この例では Lobster、Neuton、および Droid Sans Mono の 3 つのフォントが利用可能になる。

iPhone で表示させたサンプル

Google Font API の 公式FAQ には iPhone、iPad、iPod、それに Android はサポートしていない、と明記されている。しかし、今回試してみた限りでは問題なく表示できた。試したのは iPhone 3GS (iOS 4.0.2) と iPad (iPhone OS 3.2.2) だ。

これ(→)は、iPhone で iMac の Apache 経由でページを開いた状態でスクショにしたものだ。

ブログタイトルの部分が Lobster フォント、記事のタイトル(「iPhone 対応」の iPhone という文字)が Neuton フォントによる表示になっている。

Metalink って何？

きっかけは、ある数学ソフトウェアだった。ダウンロードしようとリンクをクリックすると、dmg ファイルではなく xxxx.dmg.metalink というファイルが落ちてきた。中身は XML だった。ダウンロードページの注意書きを読むと、Metalink 方式で落とせと書いてある(あとでわかったが、通常の HTTP ダウンロードのリンクもあった)。

ググると、Metalink 方式でダウンロードするには、専用クライアントが必要だとわかった。Mac OS X で動くもののうち、手軽に利用できそうなのは aria2 というもの。port でインストールできる。早速、port install を実行し、その間に Metalink について、もう少し調べてみた。

(Metalinkを活用した手間知らずのダウンロード - SourceForge.JP Magazine) Metalinkとはオープン標準の1つだが、その目的はダウンロード作業を簡単化、高速化、高信頼化させることにあり、やや大げさに言えば、個々のユーザが確保した通信帯域を最後の1ビットまで利用し尽くすことを目指している。

URL 1 つでダウンロード対象の情報を表現する HTTP 等の方式と異なり、各種情報をmetalink ファイルとしてまとめてクライアントに提供する。ここで各種情報とは、複数のダウンロード方式(HTTP や BitTorrent)や接続先(ミラー)、ファイルに対するチェックサム(md5 や sha1)や、部分ごとのチェックサムなどのことだ。

Wikipedia:en によれば、Metalink は 2005 年に Linux ディストリビューションの ISO イメージをダウンロードに供するために公開された(Metalink 3.0)、とある。さらに、2008 年には IETF に提出されて、2010 年に Metalink 4.0 として RFC になった(→ RFC 5854)、と。ああ、つまりはインターネット標準なんだね。ちなみに、3.0 と 4.0 の間にはファイルとしての互換性はないらしい。

もともと、巨大かつ人気の高いファイルのダウンロードを円滑にするために考えられた方式で、ちょっと特殊な用途のものだと言える。それでも RFC の Standard Track になっているんだから、そのうちブラウザでも標準でサポートするようになるかもね。

関連リンク

• Metalink (Wikipedia:en)
• Metalinkを活用した手間知らずのダウンロード (SourceForge.JP Magazine)
• RFC 5854 - The Metalink Download Description Format (IETF)

Github に SSH 公開鍵を登録する

Github のリポジトリにアクセスするためには、あらかじめこちらの SSH 公開鍵を登録しておかなければならない。公開鍵は ssh-keygen コマンドで作れば良い。ウチの環境では、LAN 内の他の Mac へのリモート接続等に公開鍵を使っているため、今回 Github へ登録するものは、それとは別に作ることにした。そのための手順は以下のようになる。

1. 公開鍵生成時に鍵ファイルの名前を指定する。
2. Github への SSH 接続では標準とは異なる鍵ファイルを使うように設定する。

SSH 公開鍵の生成

以下が実際の公開鍵生成の実行結果。参考にしたのは help.github にある「Generating SSH keys (OSX)」。また、鍵のファイル名を変更する方法については「Macにgitをインストールしてそのままgithubにも登録」にならった。

[imac] mnbi% ssh-keygen -C "mnbi@foo.bar.baz"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/mnbi/.ssh/id_rsa): github_id_rsa
[...snip...]

SSH の設定

「Troubleshooting SSH issues」の "SSH config" にしたがい、~/.ssh/config に以下の記述を追加する。

Host github.com
 User git
 Hostname github.com
 PreferredAuthentications publickey
 IdentityFile ~/.ssh/github_id_rsa

Github への接続テスト

生成した公開鍵(↑の実行例では github_id_rsa.pub)の内容を Github に登録した後、「Generating SSH keys (OSX)」にしたがい、接続テストを行う。以下はその実行結果。

[imac] mnbi% ssh git@github.com
The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.
Identity added: /Users/mnbi/.ssh/github_id_rsa (/Users/mnbi/.ssh/github_id_rsa)
PTY allocation request failed on channel 0
ERROR: Hi mnbi! You've successfully authenticated, but GitHub does not provide shell access
           Connection to github.com closed.

Github はシェルアクセスを認めていないため接続は切られる。肝心なのは「You've successfully authenticated」の部分。これにより、認証は成功したことがわかる。

追記@2010-11-17

実際のプロジェクトの登録については、「既存のプロジェクトを github に公開する」を参照。

関連リンク

• Macにgitをインストールしてそのままgithubにも登録 (kishi-r.com)
• Generating SSH keys (OSX) (help.github)
• Troubleshooting SSH issues (help.github; 認証情報のファイルを標準とは別の名前にする場合の SSH config の設定方法が載っている)

関連記事

• Gist を使って記事にコードを埋め込む
• MacPorts で Git をインストール
• MacBook にも Git を (あるいはリモートリポジトリの準備)
• 平等分散リポジトリの見せる夢

twitter より (2010-08-11)

• 19:37  Gmail から直接 Picasa に画像を送れないもんか。ダウンロードしてアップロードするのは面倒だし、回線幅のムダづかいだ。

Powered by twtr2src.

Google、また一つ、製品の開発を終了する

Google Wave が開発終了になるらしい。ちょこっと試したことがあるだけだから Wave 自体に思い入れはないけど、Google Notebook の開発が終了したときのことを思い出した。

「収益が上がらないから、この領域から撤退します」っていう姿勢は企業として当然のものだけど、Google の製品にとっての収益ってなんだろう？ Google 自体の収益は主として広告収入だろう。けど、検索を別として、Google の個々の製品で直接広告収入に結びついているものはあるか？

たしかに Gmail には広告が出る。けどその他は？ Google Reader で広告なんて見たことない。Picasa にも広告は出てこない。Google Docs も Google Calendar も広告は表示されない。Blogger も Google Sites もサービス自体が広告を流し込んだりしない。

Google には使命がある。「世界中の情報を整理」するためには、既存の情報を取り込むと同時に、これから作られる情報も迅速に集めなければならない。そのためには Google から見えないところで、Google の手の届かない形で作られるよりも、Google が提供するサービスで、Google に蓄える形で作ってもらう方が余計な手間が省ける。Gmail を始めとするこれらの製品(サービス群)はこのためのものだろう。言わば、The computer としての Google に効率良くインプットするためのもの。使命の後半「世界中の人々がアクセスできて使えるようにする」ことは「検索」サービスで実現する。

検索結果の一部やコンテンツ自体に埋め込む形での広告で収益を上げられるなら、インプットとしての他サービスに広告を表示する必要はないはず。広告を表示しない製品(サービス)は直接収益には結びつかない。ならば、製品の成功失敗をどうやって評価しているのだろう？

(Update on Google Wave より)
But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects.

これ(↑)を読む限りではユーザ数が基準の一つになるようだ。つまり、Google Wave はユーザに人気がなかった、と。ま、新しいコミュニケーションを求める人たちは twitter に流れたってことかな。

振り返って考えると、Google Notebook もユーザを集められなかったんだろう。最近の Evernote の隆盛を見る限り、もう少し続けていれば人気も出たかもしれないのにと、かなり残念に思う。

(Google Wave to Be Discontinued より)
Google Wave had a lot of potential, but Google didn't manage to build a compelling user experience and define some use cases for the application. Instead of building a general-purpose interface for Google Wave, Google could've used the platform to create multiple applications with clearly-defined goals: a new version of Google Chat, a new version of Google Docs, a brainstorming app etc.

「新しい Google Chat や、新しい Google Docs や、ブレスト用アプリになれたかもしれないのに……」。なんか、ちょっと切ない。

関連リンク

• Google Wave to Be Discontinued (Google Operating System - Unofficial news and tips about Google)
• Update on Google Wave (The Official Google Blog)
• Google Wave (Wikipedia:ja)

関連記事

• 理想のノート(アプリ編)
• Google Notebook が開発終了だって・・・ (理想のノート(アプリ編))

twitter より (2010-05-20)

• 09:39  公式 twitter アプリ。→ http://ipodtouchlab.com/2010/05/twitter-iphone-official.html
• 17:23  [自分用メモ]Google Storage for Developers。近い将来、これは一般ユーザにも直接利用可能になるのか。→ http://code.google.com/intl/ja/apis/storage/
• 17:25  あるいは、Storage を利用するのはサービス提供者であって、一般ユーザは何らかのサービス経由(Google Docsのようなもの)で間接的に使うってことになるのか。
• 17:30  プライバシーの問題と Google が邪悪かどうか(邪悪にならずにいられるのか)という問題を棚上げにするになら、すべてのデータは Google に保管しておいてもらうのがイイ。そうすれば、Google の手が確実に届くから、必要になったときに検索で見つけられる可能性が高くなる。
• 17:33  もちろん、(先に上げた問題の他にも)気になる点はある。ひとつは、Google がスケールできるのかっていう点。極端に言えば全人類の要求を満たすだけの資源を用意できるかということであり、またそれだけのデータを効率良く処理できるのかということでもある。
• 17:37  もうひとつはデータの局所性。これは「わたしが作った(蓄えた)データを必要とするのは、大抵わたし(だけ)」問題と言っても良い。そんな局所的なデータを蓄積、処理するのなら、やはりローカルな資源(個人所有のもの)を使うべきなんじゃないか。
• 17:40  コストをどう分担するかっていうのも気になるところ。「フリーランチの時代」が到来しているのなら忘れてしまえるのだけど、そうでないならどこかで誰かが負担することになる。
• 17:42  今だって、Googleが払うことになるコストは別の形でユーザにチャージされているはず。広告収入がGoogleの主要財源だというなら、それは商品(やサービス)の価格に上乗せされている。はっきりした形で見えないだけだ。
• 17:50  はっきりと理由を指摘できないから単に好き嫌いの範囲なんだけど、やっぱりコストは目に見えた方が良い。検索1回につき何円とか言われるのもイヤだけどなあ。
• 18:25  へぇ、おもしろいかも。Mac on Mac、復活だな。→ http://journal.mycom.co.jp/news/2010/05/20/025/index.html

Powered by twtr2src.

Google Public DNS を早速、試してみた

購読している RSS フィードのひとつで、Google が DNS サービスを提供し始めたことを知った。とりあえず、試してみることにした。大まかな流れはこんな感じ(↓):

1. AirMac ユーティリティによる Time Capsule の設定
2. Snow Leopard Server: DNS の設定
3. Snow Leopard (クライアント版) 側の設定
4. 稼動確認
5. ローカルの DNS を落としても、名前解決できるか

AirMac ユーティリティによる Time Capsule の設定

うちは Time Capsule をインターネットへのルータとして使っている。 部屋で使っている Mac たちは DNS の設定を DHCP 経由で、この Time Capsule に訊きにいく。 個別に設定することもできるが、今回は、この大元を変更してみることにした。

Time Capsule に限らず一般的なルータはとくに設定しなければ、DNS の設定を ISP の DHCP サーバから引っぱってくる。ISP から契約の際に送られてくる書類一式にも DNS サーバの IP アドレスは書かれているはずだが、それを手作業で設定したのは遠い昔の話だ。Time Capsule でこれを独自の設定に変更するには「AirMac ユーティリティ.app」を使う。

「AirMac ユーティリティ.app」を起動したら、ツールバーから「インターネット」を選び。さらにメインビューの「インターネット接続」タブを選ぶ。中段に「DNS サーバ」の IP アドレスを入力するフィールドが 2 つ用意されている。デフォルトだと、ここには ISP から取得した DNS サーバの IP アドレスが 2 つ表示されている(グレー表示になっている)。これを上書きすれば良い。

うちの LAN では Snow Leopard Server でもローカルな DNS を稼動させて、LAN 上の機器の名前解決を担当させている。2 つある DNS サーバのうち最初の方は、ローカルな Snow Leopard Server の IP アドレスを入力してある。今回の Google Public DNS の IP アドレス (8.8.8.8) は、もう一方の方に入力した。

入力後、右下の「アップデート」ボタンを押せば、Time Capsule が再起動する。

Snow Leopard Server: DNS の設定

mini で稼動させている DNS サーバはローカルな LAN 上の機器の名前(とアドレス)しか解決できない。他のリクエストは上位の(外部の) DNS サーバにリクエストを転送することで解決を図るようになっている。そのためには転送する相手のアドレスを設定する必要がある。

「サーバ管理.app」を起動し、サイドバーからサーバを選び、さらに「DNS」を選ぶ。メインビューのツールバーで「設定」を選ぶと「フォワーダ IP アドレス」のリストがある。これまで、ここには ISP 提供の DNS サーバのアドレスを 2 つ入力してあったが、それを消して、Google Public DNS の 2 つのアドレス (8.8.8.8 と 8.8.4.4) を追加した。右下の「保存」を押せば完了。

Snow Leopard 側の設定

DHCP で接続情報を取得するようになっていれば(これがデフォルト)、とくに設定する必要はない。あえてすることと言えば、「システム環境設定」を開いて DNS の設定を確認するぐらい。

mini が停止する可能性もあるから、クライアント版はローカル DNS だけにクエリーを飛ばすようにはしていない。Time Capsule の設定にしたがって、ローカル DNS と Gogole Public DNS の 2 つのアドレスが使われるようになっている (実は、3 つ目として ISP 提供の DNS のアドレスも飛んできていた; これは Time Capusle が気をきかせたのかな)。

ちなみに、Snow Leopard の場合、DNS の設定は /etc/resolv.conf にも書かれている。設定を確認するだけなら、こいつを cat するのがてっとり早いかも。ただし、このファイルは自動生成されるもののようで (/etc にあるのはシンボリックリンク、実体は /var/run/resolv.conf)、これを書き換える必要はない。というか、書き換えてはダメ。中にはこんな風なことが書かれているから。

(/etc/resonv.conf のコメント)
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.

稼動確認

まあ、普通に web をうろついてみたけど、問題ない。 dig を叩いて、有名どころのアドレスを調べてみたり。

ローカルの DNS を落としても、名前解決できるか

これは稼動確認のオマケ。ローカル DNS が Google Public DNS にフォワードするように設定したのだから、通常 LAN 内での DNS リクエストは一旦、ローカル DNS に届く。ただし、mini が停止する可能性も考慮してクライアント (MacBook) では、第2候補に Google Public DNS を明示的に指定している。この設定が期待どおりに効果を発揮するなら、mini 上のローカル DNS を停止しても、MacBook は問題なく web ページを開いたりといった作業ができるはず。それを確認してみる。

手順は、mini で「サーバ管理.app」から DNS サービスを停止させ、MacBook で web を見るだけ。

やってみた。問題ない。

関連リンク

• Google Public DNS - Google Code
• Google DNS - Google Operating System / Unofficial news and tips about Google

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、バンザイ！

関連リンク

• MNBI の共有アイテム (Google Reader で「共有」マークを付けたアイテム)