ただのにっき

■ gitでforkなどを経験してみた(またはwassr2twitterを導入)

えちょさんがwassr2twitterというのを公開していた。Wassrの自分のタイムラインをごっそりTwitterの特定のアカウントに流し込むというだけのスクリプトなのだが、これができると選択肢の多いTwitterのクライアントでWassrが読めるようになる。具体的にはiPhoneでNatsuLionとか*1。

せっかくコードがGitHub上にあるので、WEB+DB PRESS Vol.50で「はじめてのGit」を読んだばかりということもあり、それっぽい開発を体験してみることに。「はじめてのGit」はとてもいい記事なので、git使ってる人は読むべきです*2。

WEB+DB PRESS Vol.50
杉山 貴章
技術評論社
￥57

まずは本家リポジトリ上で「fork」をクリック。すると自分のところに新しいリポジトリが増える。forkと言っても、gitのリポジトリはすべて対等なので、これも独立した立派なリポジトリである。あとは基本的にこっちをいじる。

まずは開発マシン上でclone:

% git clone git@github.com:tdtds/wassr2twitter.git
% cd wassr2twitter
(... Pit対応する)
% git commit -a -m 'supported Pit.'
(... Proxy対応する。commitの単位は細かく![←師の教え])
% git commit -a -m 'supported http_proxy.'
% git push
(↑ここでpushする先はGitHub上の自分のリポジトリ)

あとは本家に「このパッチ取り込んでちょ!」とお願いする。自分のリポジトリページにある「pull request」をクリック。(たぶんfork元ということで自動的に入っている)「Select Recipients」のEchosさんにチェックを入れて、メッセージとともにリクエストを送ればよい。

……で、これをマージする体験はまだしてないんだけど(笑)、えちょさんによれば単にマージするだけならWeb上でできるそうだ。GitHubスゲー。

両者のリポジトリがどうなっているのかは、これもGitHub上で見ることができる(ページ右端にある二股に分かれた矢印のアイコン)。いろんな目的別にブランチを切りながら開発をすると面白いことになりそう。

今後、本家の開発が進んだら、その差分を自分の方に取り込んだりするのだろう。直接pullしても良いけど、remoteを作って、fetchしてからmergeするという流れで作業する方が良いと思うので、そうしておく:

% git remote add echos git://github.com/Echos/wassr2twitter.git
% git fetch echos
(echos/masterがローカルにコピーされる)
% git merge echos/master

しかしなんだ。まさかアイマスクラスタの人とコードのやり取りをすることになるとは想像もしてなかった。

■ Googleストリートビューの改善(?)のこと

ストリートビューをご利用のみなさまへ(Google Japan Blog)にて、カメラ位置の修正や、ぼかし処理の適用が発表された。歩み寄ったというよりは「うるさい連中に対応するポーズを見せておくか」ってとこ?

この問題をGoogleが軽視しているのがはっきりわかるのが、この一節:

未公開のエリアでも、既に前の高さのカメラで撮影済のものがあります。こちらについては撮影済みの画像をまず適応させていただき、順次再撮影した映像に切り替えさせていただきます。

本当に問題と認識しているなら、全面公開停止したあとで、新しい画像を順次公開すべきところだろう。新しいカメラの高さがまだ2m以上あるというのも含め、Googleは何も反省していないし、ひょっとすると何が問題視されているのかまったく理解していないんじゃないか。

Google StreetViewの本質的な問題は、「多量の写真」が「地図と密接」に関連付けられている点なのだから、少なくとも住宅地に対してもっと踏み込んだ対応をしなきゃ、セキュリティ問題は解決しない。最低でも、狭い道(4m未満くらい?)への進入禁止措置とか、私有地への侵入防止策なんかを打ち出してくれないとな(とか書いたら高木さんのブクマとかぶった)。

【関連記事】

• 「ストリートビュー問題」をセキュリティ観点から整理する
• MIAUシンポジウム「Google ストリートビュー"問題"を考える」に行ってきた

■ AmazonのAPI認証導入はOSSに対する挑戦だよなぁ

「Amazon アソシエイト Web サービスの名称変更および署名認証についてのお知らせ」によって、たった3ヶ月であらゆるAPI呼び出しに認証をつけなくてはいけなくなったわけだが、ここまで広まったAPIにこんだけキツい縛りをかける、その裏の意図がさっぱりわからん。

この認証方式は、以前AlexaのWebサービスを使ってみたときとほぼ同じで、SHA1の代わりにSHA256を使う点と、ハッシュの元メッセージが複雑になった点が違う程度。コード上の対応は難しくない。tDiaryでもすでに、えろぺおさんによるモンキーパッチが出ている。

Alexaの場合は課金という目的があったけど、Amazonの場合は逆にユーザに金を払っているわけで*1、しかも実際に売り上げが上がったときにだけ支払ってるわけだから、あんまり認証かける意味はなさそうなんだよなぁ。

それはさておき、困ったのはフリーソフトウェア/OSSとしてAPIを利用する場合である。従来はAccess Key(これは公開可能な情報)をコードに埋め込んで配布でき、ユーザは単にそれを使うだけにできた。しかし認証に必要なSecret Access Keyを公開してはいけないので、今後はそれができない。ということは、ユーザごとにキーを取得してもらわないといけないわけで、たかがAmazonへのリンクを貼るだけのためにはあまりにハードルが高すぎる。

Webサービス業の申し子Amazonとしては、スタンドアロンなアプリを各ユーザがインストールして使うなんて場面は想定してないのかも知れないけど、それを余命三ヶ月と宣告するのはあんまりじゃないかね。「Yahoo!PipesとかTomblooとかから使えなくなりそうなのが困る」という声もあって、まったく困った仕様変更だと思う。

というわけで、OSSからの利用方法について何か想定していないのか、Amazonに質問のメールを投げてみた。24H以内に返事するっていうので、明日には何かわかる……かも。

2009-05-15追記

問い合わせフォームの受付完了画面に「24時間以内に返答する」って書いてあったから待っていたけど、72時間(くっ)待っても何もない。どうしたもんかなー。フォーラムにも書いてみるか?