Codaでソース管理（１）からの続き。Subversion のインストールと設定が完了したら次は Coda のソース管理機能を設定する。個人的には Transmit からの移行でサイトの設定は自動的に引き継がれたのだけど、”サイトを追加…” コマンドから新規に設定をしても同じ事だと思う。

1. Coda のサイトモードからサイトを追加、あるいは編集をした際に表示される “ソース管理” 領域にある「ソースをチェックアウト」ボタンを押す。
2. 次のようなモーダルボックスにCodaでソース管理（１）設定した、リポジトリ URL、ユーザ名、パスワードを入力してチェックアウトボタンを押す。リポジトリ URL については、外部に向けて立てるサーバにする場合に svn や http プロトコルを利用する場合もあるので、ユーザ名やパスワードと併せて適宜調整する。今回はローカルの環境だけなので file プロトコルを使った。
   
3. 作業コピーのチェックアウトに問題がなければ進行中の既にファイルやフォルダが存在するプロジェクトの場合、ウィンドウの左側に表示されているファイル一覧の、各ファイルやディレクトリの右横に Subversion でお馴染みの ? や A、Mといったアイコンが表示されることになる。まず “item is not under version control” を示す ? アイコンを押してリポジトリに追加していく。順序が前後してしまうのだけど新規にファイルやフォルダを作る場合は次の様なモーダルボックスで警告される。追加を選択すると上述した ? アイコンを押す手間が省けることになる。
4. ファイルを編集すると “Modified” を示す M アイコンと同時にサーバへのアップロードを促す上矢印アイコンが表示される。M アイコンを押すとリポジトリにコミットすることになり、次の様なモーダルボックスが表示されるので変更点を入力してコミットボタンを押す。もちろん日本語も可能だ。 また、アイコンが何か分からなければマウスをフォーカスすることでヒントが出るし、右クリックをでもコマンドを得られるので GUI ツールは便利だと思う。

一通りはこのような流れで進んで行くが、複数人で作業している場合はアップデートと更新を注意深く使う必要がある。（参照：状態と更新の区別）また、複数のプロジェクトを管理する場合はどのような構成にするかの判断に迫られることになるのだが、Codaでソース管理（１）の２〜７の手順と今回説明した手順を繰り返し、~/svn/project1、~/svn/project2、~/svn/project3、…という具合にしている。

更に Coda はチェックアウトした際に “.svn” という不可視フォルダをプロジェクトの各ディレクトリに作成し参照している。もしチェックアウトに失敗した場合はリポジトリ URL の編集が不可能なことから、これらの不可視フォルダを全て削除しないと再設定することができないので注意が必要だ。

これまでは Transmit と Smultron、SmartCVS という組み合わせでウェブサイトやウェブアプリケーションの開発を行っていたが、Smultron の開発が終了したことで Coda を導入することにした。加えて FireWire 400 や パラレル ATA、冷陰極管バックライト液晶といった旧システムに別れを告げるべくハードウェアを iMac に変更し、まっさらの状態から Snow Leopard にウェブ開発環境を整えることになったので、Coda と Subversion との連携作業について内容を書き留めておく。

1. 最新の Subversion を CollabNet からダウンロードしてインストールする。
2. Subversion のディレクトリを作成する。（例：~/svn）
3. 保管プロジェクトのディレクトリを作成する。（例：~/svn/project、実際は上記２と併せて mkdir -p ~/svn/project で一手順とした。）
4. Subversion のリポジトリ作成コマンドを入力する。（例：svnadmin create ~/svn/project）
5. 上記4で作成される ~/svn/project/conf/svnserve.conf の次の４行のコメントを外し先頭の空白を詰める。
   

   anon-access = read
auth-access = write
password-db = passwd
authz-db = authz

6. 同階層にある ~/svn/project/conf/authz に次の内容を追加する。（斜体のユーザ名は適宜調整する。）
   

   [/]
hkitago = rw
* = r

7. 更に同階層にある ~/svn/project/conf/passwd に次のようにユーザ名＝パスワードの形で１行追加する。
   

   hkitago = passwd

8. Subversion を起動する。（例：svnserve -d -r ~/svn/project）

更に最後の手順で行った Subversion の起動を OS X の起動後に自動的に行う様に設定する。以前は Lingon というGUIアプリケーションを使っていたのだが、こちらも開発が終了するとのことで Apple が公開している Mac OS X Manual Page For launchd.plist(5) を参照しつつ手作業とした。どちらの場合も管理権限が必要となる。今回は org.tigris.subversion.svnserve という一意の名前で呼び出す事ができるように launchd daemon に登録した。

1. org.tigris.subversion.svnserve.plist という XML ファイルを次のような内容で作成する。（例：sudo vi /Library/LaunchDaemons/org.tigris.subversion.svnserve.plist）

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
   http://www.apple.com/DTDs/PropertyList-1.0.dtd>
   <plist version="1.0">
   <dict>
           <key>Disabled</key>
           <false/>
           <key>Label</key>
           <string>org.tigris.subversion.svnserve</string>
           <key>ProgramArguments</key>
           <array>
                   <string>/usr/bin/svnserve</string>
                   <string>-i</string>
                   <string>-r</string>
                   <string>/Users/hkitago/svn</string>
           </array>
           <key>inetdCompatibility</key>
           <dict>
                   <key>Wait</key>
                   <false/>
           </dict>
           <key>Sockets</key>
           <dict>
                   <key>Listeners</key>
                   <dict>
                           <key>SockServiceName</key>
                           <string>svn</string>
                   </dict>
           </dict>
           <key>OnDemand</key>
           <true/>
   </dict>
   </plist>

2. 権限を変更する。（例：sudo chown root:wheel /Library/LaunchDaemons/org.tigris.subversion.svnserve.plist）
3. launchd daemon に読み込む。（例：sudo launchctl load /Library/LaunchDaemons/org.tigris.subversion.svnserve.plist）
4. launchd daemon を起動。（例：sudo launchctl start org.tigris.subversion.svnserve）

子供が昼寝から起きたので Coda 側の設定は次回に。

「移植性を無視して最新のハード向けにばりばりのネーティブコードを書きたかったらiPhone向けのアプリをObjective Cで作り、さまざまなデバイスへの移植性が重要ならHTML5+Javascriptでインタラクティブなアプリを作ってiPhone上のSafariでテストしておく」というのが現時点でのスマートフォン向けの開発投資の仕方としては、最も賢い選択肢だと考えている私である。

引用元: Life is beautiful: GoogleのAndroid向けのアプリビジネスはなぜ魅力的ではないか？.

選択肢にした経験から気をつける点が２つ思い当たる。１つ目は iPhone で Canvas が使い物にならないと感じたことだ。具体的には読み込みに時間を必要とし利用者の精神的負荷となる可能性がある。ポジションカードアプリで描いているボードの絵柄は当初 Safari 3 上の Canvas で検証し問題が無いことを確認していたが、実テストに於いて第二世代 iPod touch で且つ OS が v2 だったことを考慮しても、起動に７秒前後を要した。ゲームのようにローディングで対応するということも思いついたが、ユーティリティの部類では難しいと判断した。

２つ目はスコアボードアプリの開発に於いて実践し学んだことで、こちらは manifest ファイルを記述したウェブアプリ版を先行して公開していたのだが、それら２つの機能差に明確な優位性が無かったことから販売台数は伸び悩んでいる。結果として無計画になってしまった理由は Apple の開発者向け戦略が勇み足だったというか、iPhone SDK 公開の流れでお分かり頂けると思う。

さらに、この方法を後発のポジションカードアプリ開発に適用しなかったのはこのような外的要因に加え、上述したような場合に、水平モードに固定できず Safari のツールバーが邪魔をして描画領域を確定できなかったことが挙げられる。これらの問題がクリアできれば車輪を再開発することなく移植はもちろん、ウェブアプリとして無料版に仕立てることも可能だと思う。

実際に手を動かす視点では ActionScript を使えれば OpenGL も楽しいだろうと思う反面、ビジネス的にはクラウドネットワークについて考えてしまうので SQLite を直接扱える JavaScript を選択し iPhone 市場に参入した次第だが、そんな技術話よりも米国の顧客からはブラックベリーや Facebook といった別プラットフォームへの移植の需要があるのは確かだ。しかし開発環境が無いからと断っているのは、競合が皆無でロングテール（素麺代稼ぎ）を楽しんでいるという反省すべき点がある。;-)

最後にウェブ開発者という視点で見ると、重い Parallels を使った貧そな UI を持つ IE の動作確認から逃れ、ミドルウェアを使わずにデータを入出力できる新しい技術を試す興奮や楽しさを得られたと思う。日本の自称ウェブ業界スーツ民達に技術の理解が浸透し、仕事として回り出すのはいつのことになるのだろうと思ったが、広報の方法が変化するように、案件が降りてくるのを待つよりも昨年の不況が転換期のような気もするので、日々精進あるのみと再度自省する。

P.S. Interview with Neil Mix of Pandora – iPhone Audio Streaming, Memory Management, and More も JavaScript を iPhone に利用する面白い例だと思うので参考迄。

とある案件で Twitter を利用したニュースの表示を提案し運用することになった。Twitter は「フォロー」と「つぶやく」 が主な機能で、前者は共同体（コミュニティやソーシャルネットワーク）作りに、後者は上述したような広報活動に役立つ。実際にはサービスが初利用の担当者だったので、一先ず広報活動を念頭に「つぶやく」ことに専念してもらうように英国政府の公式 Twitter ガイドラインを参照しつつ伝えておいた。

そのメールのやり取りの中で興味深いことがあったのは Google による検索ランクの懸念だった。サイト運用者なら当然の気付きだと思うが、どうして「サイト運用と言えば Googleランク！」という選択肢の無い状況が始まったのだろうかと、ふと疑問になった。

そもそもの問題は Yahoo! のディレクトリ検索にあると考えた。Google はウェブという広い海に点在していたページを自動的に拾い利用者に見つけ易くし、方や Yahoo! は伝統的なお役所風の（人力で申請して認可するという）方法だった。このような検索業界の対立構造の均衡が、利便性と市場の需要によって崩れてしまったという今はご存知だろうが、逆にここで考えなければならないのは Google に依存しない広報活動の方法だ。

成功か失敗かは誰にも分からないが、これからの検索業界はGoogleとMSの2つがガチンコでぶつかり合うことになりそうだ（個人的に、Twitterがそこに入り込むのはまだ時期尚早に思う）。

引用元: 技術集団としてのYahooの終焉と、検索業界のこれから | 赤と黒.

個人的に Twitter がそこに入り込んでいると思うのは、共同体作りとしての機能が活き始める利用者の増加（スパムの発生）もさることながら、もう一つの機能であるつぶやくための手段が豊富であり、Google の劣っている機能である「情報の鮮度」を扱えるからだ。

この「情報の鮮度」について考えていると、Google は実社会で言う博物館や図書館の代替になるという、彼らの目的を再確認した（梅田氏が米国のネット利用をインフラと例えたのはこの側面を見ているのだろうか）。一方で利用者の立場で考えると、記録して残しておくべき重要な情報と、それに属さない今の取るに足らない情報との積極的、あるいは能動的な区別が必要だと思う。これは通話でもリンク（ブックマークやURL）でも、共有したい情報の種類によって利用するサービスや道具が異なる場合があるという当然の教訓でもある。

P.S. このブログがプライバシー設定でロボットをブロックし、投稿と同時に Twitter で自動的に非公開でつぶやいているのはこのような意味で実験の場となっているが、Twitter をビジネスで利用するにはあくまで広報する代理人のように扱い、実体は他方に持っておくことが必要となると感じた。

ソーシャルネットワークと言えば日本でミクシィが代表的だが、サービスが始まった当初に仕事の関係する方から感想を求められたことがあって「国として難民を受けれて、天候を問わず学校のグラウンドで寝泊まりさせているようなものです。」と答えたことがあるのだが、未だにその反論が見つからない。（使っていないのだけども）

Facebook や Twitter を使いながら日本のサービスの現状を知ると、それがどうも Apple の iLife から連想される写真や動画と言ったメディアファイル（媒体）を扱いつつ、自然言語を使い現実に則して意思疎通をしようとする価値観に対して、任天堂に代表されるような、所謂ゲームやアニメという空想や夢の世界を共有するという価値観の違いに気が付く。

一方、興味深いのはミクシィの状況だ。

一方で最近、同じSNSというくくりで、モバゲータウンやGREEと比較されることが多いのですが、ちょっと違和感があります。あちらはゲームを強調されているように思うのです。先方も違和感があるかもしれませんね。

引用元: 3000万人市場を公開へ、一大ビジネスチャンスです：ITpro.

彼らはゲーム分野というレッド・オーシャン戦略（参照：革新的ソフトウェア企業の作り方）を避けた以上、上述したような価値観やその違いを区別して、Facebook や Twitter のような利便性を追求しない限り国内だけで汎用性ある道具の利用者を増やす事は不可能だろうと思う。逆にある種の OS を開発しているような状況だろうから、日本独自の意思疎通方法を模索していると言っても過言ではないと思うし、時代精神と民族精神は共存が必要なように、同じ意味の価値がそこにはあると思う。

しかし命令系統に弱い言語体系を活かすには、漫画や浮世絵、水墨等の画になるか、文字を使うとしても短歌や俳句のような抽象比喩表現を多様した伝達方法になると思うが、既にどの道も2chやニコ動、はてな俳句、pixiv(ピクシブ) などが先を行っているだろうし、足跡という新しい制度の受け入れに難がありそう（足跡が足枷に！）なので、違う方法を模索するしかない。

最後にこの東西比は平たく言ってしまうと「機能や要素を段階的に追加する」で述べたような違いの原因にも通ずるものがあると感じた。

WordPress が持っている機能で今まで使ってきた CMS と違って面白いと思うのは、次のような２択しかないが、robot.txt の設定だ。

このブログをbloggerから移行したのは、日本語圏地域に拠点をおいて活動していることから主に日本語で多くの処理を行いたかったからということもあるが、業務日誌の役割として内面に訴え上述のような検索エンジンに頼らないものを他方で持ってみたいという理由も大きい。

もちろん人生の多くを検索に代表されるウェブに助けてもらった恩恵から、可能な限り有益な検索対象となるようなものを提供したい気持ちは已然あるがそれは英語圏にしておいて、ここまでネットユーザーが増加した現在、馬鹿に見つからず淡々と報告したいものを持つことで心理的な均衡が保たれるような気がしている。

こうまとめてみると、前者が積極的な、後者は消極的なマーケティング手法であると分かった。無意識にロボットを受け入れてきた時代から、今後は事業規模や目的、その立ち位置によって戦略的にロボットを弾いてみるのも悪くはないと思う。もちろん中には行儀の悪いロボットもいるので注意が必要だが、それに限って利用者の少ない中東辺りのスタートアップな検索サービスだろうから、さほど神経質になる必要はない。

以前使い勝手について話題にした楽天市場のサービスに関して、巷では別件で話題になっているようだ。

F’s Garage：なんだこの楽天叩き。
この話には、２つの叩きベクトルがあって感情論が交錯してる感があるので整理したい。
１．閲覧できる個人情報を、CSVでまとめてダウンロードする場合は１件１０円取るというビジネスの話。（要はえげつないですねという話）
２．個人情報がダウンロードできますよ、という問題

楽天市場を iTunes App Store に置き換えると、Apple からソフトウェア購入者の情報を（手数料也の対価と引き換えに）入手できるようなもので、第三者への利用が規約に書いてる範囲であれば全く問題のない話だと思う。ここで疑問なのは、楽天市場はそもそも取引を購入者と直接行うもので、メールアドレスや発送先住所といった個人情報を改めて一括で取得する必要があるのかどうかということだ。また、数年前の ISO 取得という流行で知っていた5000件以上を所有している要件についても、改正の動きが最近あるということを知った。

個人情報保護法施行令改正で意見募集開始 – 市販名簿を保有件数から除外：Security NEXT
個人情報保護法の施行令では、同法の対象となる個人情報取扱事業者について、個人情報を5000件以上を所有していることを要件としているが、今回の改正案では、加工せずに所有している市販名簿について件数から除外する規定を追加した。
市販名簿は、不特定多数が購入できることから安全管理義務を課すことは酷であり、個人の権利を侵害する可能性が低いとして、従来より除外されているカーナビや電話帳と同様の扱いにするとしている。

ここで一つ問題があるとするならば、楽天が販売していれば「市販名簿」の類いになるだろうし、手数料としていれば「市販名簿」にならないことだろうか。これはもし店舗が何らかの理由で漏らしてしまった場合、法的に抜けられるようにしている消極的防衛策なのかもしれない。

一方、今件で本質的にあると考える興味深い問題は「何故アンチ楽天が多いのか」ということだ。先に述べたような楽天の低い利便性や在庫を持たない手抜き体質について、違う方向を向いているアマゾンなどと比較すると「利便性について、どこまでの未来を構想し、追求しているか」ということから得られる信頼の低さが、利益追求最優先企業だと判断（ブランディング）されてきている理由の一つになると思う。また、日本語唯一圏において、もちろん起業直後に勝ち残ったことは評価できるが、競合がヤフーオークション、価格コム、ゾゾタウンのような、いずれも在庫を管理しない類似サービスだということも一因になるだろう。

EC サイトは国内外問わず頻繁に利用するのだが、日本の楽天市場というサービスの使い勝手があまり良くないことが（今更？）分かった。注文送信後、自動配信によるメールを受け取ったところまでは順調だったのだが、販売店から次のようなメールが届いた。

この度は【XXXXX 楽天市場店】を御利用いただきまして誠にありがとうございます。

誠に申し訳ございませんが、お客様の会員番号の入力に間違いがあり、当店の方でご注文の受付ができなくなっております。
大変お手数ですが、会員番号のご確認をいただきますようお願いいたします。

ここで問題となったのは「会員番号」が何を差しているかである。IDとパスワードを使ってログインした後に注文するだけで「会員番号」というものの入力はそもそも必要がない。そこで次のようにメールを返した。

XXXXX ご担当者さま

楽天市場のログイン情報（メールアドレスとパスワード）のみ入力し、会員番号というものの入力は行っておりません。会員番号は楽天市場のシステムが自動で送付していると思うのですが、その会員番号はどこで確認すれば良いのでしょうか。

すると、次のような全く的を得られない回答が返ってきた。

この度は　XXXXX　をご利用いただきましてありがとうございます。

昨日もご連絡をさせていただきましたが、ご注文の入力の際に会員番号の確認ができず、当店での受付ができなくなっております。
誠にお手数ではございますが、会員番号の入力を再度確認していただきますようお願い申し上げます。
当店での確認ができ次第、商品を発送させていただきます。
昨日の当店からの連絡がわかりにくいもので大変申し訳ありません。お客様からのご連絡を心よりお待ちしております。

販売店も顧客も「会員番号」について無明なままであり、またネット通販はスピードが肝心であることもあって、結果この注文をキャンセルするように依頼をした。しかし過去にいくつもECサイトを構築してきた身としては、この「会員番号」を明らかにしようと楽天市場のヘルプを覗いてみる事にした。実際に大手の企業サイトを構築した時にユーザービリティの試験に同席したことがあるが、無作為に選出した人にお題を投げてその情報に辿り着くまでの時間を計測すると言う意味で今回は同じ状況だ。

まず自動配信メールのフッタ部分からヘルプを探す。

★楽天市場は、取引の当事者とはならず、取引に関する責任は負いません。
したがって、万一取引に関してトラブルが生じた際には、お客様とショップとの間で直接解決していただくことになります。
⇒ http://www.rakuten.co.jp/doc/info/rule/service.html

─────────────問い合わせ─────────────────
商品、決済・発送に関するお問い合わせ XXXXX@muse.dti.ne.jp
楽天市場に関するご質問　 http://www.rakuten.co.jp/com/faq/

経験上から一般にはあまり知られていないことで知られている、ブラウザの持つページ内検索機能を使って「会員番号」という語彙を調べるが、表示ページ内にもHTMLソース内にも見つけることができなかった。そこで右肩ある「ヘルプ」リンクを押すと、リダイレクトのプログラムが同じページを返して遷移しなかった。また、トップページへ戻り「ヘルプ」リンクを押しても同じページが表示される。

大多数はここで諦めるような気がしないでもないが、トップページに表示されている自分の名前を押してアカウント専用ページ（my Rakutenというリンクのラベル名らしい）に入ってみる。そして同様に右肩に配置されている「ヘルプ」リンクを押すと…。なんと、先のヘルプとは違ったページが表示されている！

今回の問題の原因は、取引に関する責任を販売店に丸投げする楽天市場の体質に加え、顧客の混乱を増長させるナビゲーション構成にあると感じた。非会員用のヘルプページと会員用のヘルプページという異なる２つのページを同一のリンクラベル名「ヘルプ」を使っていることよりも、ユーザーのログイン状況を判定して適したヘルプページを表示させることが必要だろうと思う。

必要以上の問い合わせを避けサポート体制を極力小さくしたい意図は分かるが、問い合わせフォームの設計がこれまた生臭かった。しかし肝心の「会員番号」とは何なのだろうか？ひょっとして販売店の返信付き（人情的である意味高度な）フィッシング行為なのではという疑いも拭えないところだ。

加えて言うと、注文の最後にメールマガジン登録のチェックボックスが初期状態でオンとなっているが、この設計にも驚きを隠せない。何故なら過去に米 Real 社の業務を請け負っていた際、Real Player のインストール後に同様のチェックボックスが初期状態でオンになっていることに対し多くのユーザーからの不満を受け取り、オフにするアップデートを加えたという経験が（2000年以前に）ある。無意識の内にゴミのようなメールマガジンを受け取っているにも関わらず不満の声を上げない利用者、あるいはユーザーの立場で考えないシステム設計、どちらを見ても無限の純粋さが広がって見えるし、政治に興味が薄い国民性を垣間みる事もできる。

Amazon だったか OSCommerce だったかの担当者が来日講演で楽天市場に対し「在庫を持ちなさい」と言った理由が分かる日もそう遠くはないのかな、とも思う。

// Matz がんがれ！（関係ないか…）

オンラインで使える銀行として三菱東京UFJとソニーバンクを併用しているが、振り込みアプリケーションの邪な仕様を発見した。

お振り込みのご注意｜MONEYKit – ソニーバンク
お振り込み先口座の入力を間違えた場合などは、相手先銀行からお振り込み金をもどしてもらう手続きが必要になります。その場合315円（消費税込み）のお振り込み金返却依頼手数料がかかりますのでご注意ください。（お振り込み先を登録しておくと、毎回のお振り込み先入力を省くことができます。）

UFJ統合の際に支店名が変更になっていたことを忘れ（たと仮定し）てソニーバンクから登録した振込先へ実行してみたところ、後から知った上記ページにあるように手数料がしっかりと差し引かれていた。しかし一方の三菱東京UFJの方は、振り込み決定する前に振込先として入力した口座が存在するかどうか事前に確認してくれる機能が搭載されているのだ。

ソニーがんがれ。(　ﾟ∀ﾟ)彡∩

保育園用の子供服では大変お世話になっている UNIQLO のウェブページが一新したらしい。

Flashを脱いで生まれ変わったユニクロ.COM
FlashでもAjaxでもない。（中略）流行りのJavaScriptの利用も最低限に抑えた。

記事を読むと Web 1.0 時代のようなローカルで自動生成したファイルをサーバーへ配置しているように感じ、「利用」の定義が曖昧だったので Safari 4 のインスペクタで確認したところ、視覚的に静的なだけで ActionScript から JavaScript にクライアント側の言語を置換したと言って良い。つまり開発側ではなく、エンドユーザーにとっての「利用」ということになる。（広告の臭いがする記事に突っ込んでも仕方がないのだが…）

しかし今回の件で感心するのはユニクロの動きの素早さだ。それと同時に世界的な不況と言われる中で、開発費用もリッチな Flash 案件の生き残りに注目したい。あるいは動画配信を必要としないのに Flash を中心に構成されたウェブを持つ企業がどれだけ後退していくのかについても関心がある。もちろんその逆の結果を出せれば、うまく Flash を広告に使っているという証拠でもある。