先ほど、Facebookからのメール通知を止めようとして設定画面を開いたら、計56個以上ものチェックボックスを外さなければならないことを発見して絶望したのです。これはちょっと酷い。

確かにFacebookには多種多様な機能がついており、友人との連絡がFacebookを中心として成り立っているのであれば、56個ものチェックボックスでメール通知の有無を管理する作業は必要となるかもしれない。だが、付き合いと興味本位でFacebookに入り、月に1度程度しかログインしない人間にとっては「基本的に全てのメール通知がいらない」のが正直なところ。チェックボックスが50個もつき、それを一括変更できない状態というのは、たとえFacebookほどにSNSが巨大化していたとしても、現在のUIデザインでは考えられない事態のように思える。もし、あえて意図的につけなかったのだとしたら、その理由は何か。

ほぼ全ての項目は確かに、Facebookできちんと友達の環を作っているなら重要なもの。うっかり一括解除したがために通知に気付かない方が大変だ、と考えたのだと思う。しかし自分の場合、メール通知が必要なのは「メッセージを受け取ったとき」と「イベントの招待を受けたとき」の2つだけで、その他54個＋アプリの数に応じた通知を、ひとつひとつクリックで消していく羽目に陥った。それ以外は大して重要じゃない。たとえば極端な例を挙げると、友達として登録されたときの通知なんていらない。たまにログインしてチェックすれば十分。登録してくる人ほとんど知らないので、基本的に要らないのです。

ご存知ないのですよ！？（言ってみたかっただけ

僕たちデザイナーは頻繁に「自社製品中心ご都合主義」に陥りやすいことを自覚しなければならないのかもしれません。ユーザが使っているのは自社の製品だけじゃない。いろんなサイトを使って情報の洪水に溺れている中で、自社サービスしか使わないユーザなんて存在しないのに、どのサイトもが自社サービスを使うように強烈なアタックを仕掛け、ハードユースする理想的なユーザ向けのUIが提供されているというのは、少し考えものです。

だから、僕たちにとって都合がいいユーザの真逆を考えてみるのは、ひとつの方法論として有効だと思っているのです。使用時の状況を、もっと冷徹に思い浮かべる努力というのは、怠っちゃいけない。できれば実際に観察しに行きたい。だけど、例えば大半のiPhone Appで綿密なユーザ観察をしようとすると恐らく大赤字になる。そんなときの思考実験の方法論として、あえて自虐的な厳しい視点を設定してみるのは、ユーザへの甘えを取り除く上で非常に大切で、理想的になってしまいがちな仮定を捨て、ラフな使われ方だったとしても、サービスをその行為の中でスムーズに組み込む努力を怠らないことが、ハードユーザの体験をも向上させたりもするのだと思います。

そうやって開発側が想定するライトユーザというのが、実は一般的なハードユーザの使い方に近いものだったりするからです。いろいろと開発側にとって理不尽な事態というのは、実に簡単にユーザの周りで起きる。作業を中断するとか。途中で別のことを始めてしまうとか。ユーザストーリーを設定してしまうと、そういったソフトウェアにとってはイレギュラーだけれど、現実の生活ではごくごくレギュラーな要素が見えてこないことが多いように思います。Music Aliveを作っていて、それは痛切に感じたことのひとつ。例えば1.0では、途中で電話がかかってきた場合、という想定がすっぽり抜け落ちていた。

あるストーリーを作ってみたら、あえてそこから外れてみる。例えば、両手で使うとして、という想定があったとして、じゃあ片手だったら？と尋ねてみる。そういうのは方法をうまく確立すれば、ある程度は洗い出せる。無意識に前提としていることを、どれだけ意識化できるか。イレギュラーなレギュラーに気付くにはどうするか。今の僕には果てのない課題です。

そういえば話は少し違うが、光回線などの解約手続きといい、クローズ型SNSといい、退会のハードルを故意に高めることで退会率を下げる試みは今も王道だけれど、あれは企業にとって麻薬みたいなものです。何らかの理由で退会手続きを行おうとして一度怒り心頭になったユーザは、その会社の名前を記憶し、以後そこのサービスを使うことはない。例えば以前Yahoo BBで心底嫌な目にあった僕にとって、iPhoneを使うためにソフトバンクを選ぶことは苦渋の選択だったし、加入後、既に３回か４回程度、こめかみに青筋が立っている。ソフトバンクの携帯に関する以外のことでここ数年、そこまで感情的になる事態が起きたことはないのです。あれも、なんとかならないものかといつも思います。

セカイカメラAPIの説明会開催日にAppleは、セカイカメラを含むPlaceEngine（Wifiを通して位置情報を取得する技術）を利用したアプリをApp Storeから一掃した。セカイカメラさんからすると非常に嬉しくないタイミングで、Appleが水を差したことになる。またか！と騒ぐ前に一考したい。

まずは可能性を列挙してみよう。
1. Appleさんの提供しているAPIの範囲を超えたグレーな実装方法だったのが、やっぱりブラックだと認定されてしまいましたなう。
2. 「広告を表示するためだけに位置情報を取得するアプリは禁止です」という、最近話題を呼んだAppleの表明が実行に移されたなう。
3. 今後のビジネス領域に重なるので、競合事業者を排除したなう。
さて、どれだろう？

一番有力なのは、やはり1番目だ。Private APIを利用していたのがNGとなったケース。PlaceEngineは、簡単にいうと周りにあるWiFiのアクセスポイントをActive Scan（自分から取得しにいくこと）して、BSSID（MACアドレス）とSSID（Sub Station ID：アクセスポイントの名前）、RSSI（受信信号の強度）の３つの情報を取得している。PlaceEngineがActive ScanにPrivate APIを利用しており、それがこれまでは黙認されていたけどやっぱりNGになったと考えると合点が行く。時期的にみても、新バージョンのiPhone OSが出される直前に、SDKの運用基準が厳密になった可能性は高い。
関連記事：http://www.theregister.co.uk/2010/03/04/wifi_stumbling_iphone/

当該アプリの開発者（というか、この場合はPlaceEngineを提供しているクウジットさん）は公式のAPIを使用したものに書き換え、再度審査を申請することになる。たぶん今頃徹夜しているのではないかと思われます。回避策があるのか、ちょっと不明。頻繁に利用されるアプリが多いだけに、影響は大きい。

ちなみにPrivate APIを利用していたアプリが審査に通らないケースはこれまでも頻繁に報告されており、真新しいことではない。僕たちはこのケースで削除になるリスクを考慮し、Private APIを利用しない方針で開発をしている。

気になるのは2と3だ。PlaceEngineなどの位置検出技術が、Appleの事業戦略と重なった可能性。何ともいえないが「ロケーション広告を単純に表示するだけのために位置情報を取得するのは認められないよ」というAppleさんの表明が実行されたのであれば、iButterflyが削除されてても良い気がするのでリトマス試験紙をそこに貼っておくとして、それだと残る可能性は3である。

ロケーション関連が将来的なAppleのビジネス領域に重なるか重ならないかといえば、はっきりと重なることは誰の目にも明確である。Appleは、適切にプライバシーコントロールを行いつつ、デバイスと密接に連携した制御をすることによる優位性の確保と、一次情報の囲い込みを狙うことができる。

まとめると削除理由としては1、その背景に3があって、Appleさんは着実にロケーション情報を提供するAPIを準備中、といったところだろう。ただし2も関係がないわけではないだろう。以上、僕は当事者ではないので、あくまで推測ですが、後日クウジットさんから公式の説明があるのではないかと。ケーススタディの価値は大いにあるので、今後とも注視していきたいところです。

と、ここまで書いたところで、クウジットさんが協力しているブラタモリがApp Storeに残っていることに気付いてしまった。はてさて（おそらく、クウジットさんが協力してはいるが、PlaceEngineは使っていなかったのだと思われる）。

3月9日追記：クウジットさんが、PlaceEngineを外してアプリを再審査に出すよう、各アプリのデベロッパーさんに提案したと表明したみたいです。流石に無理だったみたい。
http://www.koozyt.com/press/2010/news100306.html

前回の記事「グラビアアイドルアプリ一斉削除に感じるAppleの展開戦略」にはわずかながら反響があったようで、実際に被害？にあわれた会社さんの方なども読んでくださった模様。「ご退場くださいとか酷いですぅ」などと思われてしまったようなのですが、断っておくとあれはあくまでもジョブズならそう言いかねないってことです。実際、僕たちがグラビアアプリをやっていたら、今頃「もうゴールしても良いよね。私がんばったよね。」と言いながら、悲しみの血の雨を降らせているに違いない。だがしかし、モバイルアプリ事業者を標榜するあなたには強い味方が登場する。

それは誰かといえば、もちろんGoogle先生だ。Google Androidにはそうしたルールは今のところ存在しないから、えっちいお姉さんが大量に登場するようなコンテンツを掃いて捨てるほど持っている事業者の人はそちらに移行すればいいだろうと思う。単に、それだけの話だ。iPhoneユーザの男性を悔しがらせるような、えっちぃコンテンツを花開かせればいい。今ならがっぽがっぽであろう。フォロー終わり。

前回の記事で言いたかったのは、オープンプラットフォームと呼ばれるような環境であっても、Appleのような事業者の場合はコンテンツの峻別が常に行われている、ということだ。Appleはユーザ・エクスペリエンス・デザインを最も大事にしている会社である。彼らは常にそうした観点から観察しており、害悪だと思えば切り捨てる。そのためにわざわざコンテンツメーカーにお伺いを立てるくらいなら、一方的に削除した方が経営資源を効率化できる。大変なのはコンテンツメーカーだけれど、最初からAppleはその方針を示している。iPhone市場にいるなら、常に切り捨てられる覚悟とリスク対策がいる。僕はそう言いたいだけだ。Appleの方針や方法が正しいかどうかなんて、僕の知ったことではないし興味もない。もしそれが嫌だというなら、プラットフォーマーを目指すべきだ。そのリスクを、AppleやGoogleは背負ってくれていることを、僕は肝に銘じておきたい。

ただもちろん、表現の自由や、セクシュアリティへの感受性が国によって異なる、という側面には、もちろん興味がある。アニメはクールだが、苺ましまろをアメリカの一部の人たちの前で見せれば、僕はもしかしたら逮捕されるか、サタンの使者だなどと言われてリンチにあうかもしれない。場所が場所なら、これは９割方起こりうる。宗教に対して寛容であることが信条の日本人には分かりにくい感覚ではあるが、個別の配慮をどのように行えばいいのか、というのは実に由々しき問題である。が、まぁ長くなってしまったので、えっちぃお姉さんとかわいいは正義！をデジタルでグローバルな世界で、文化的にどのように扱えばいいのかは、また別の機会に放出することにしたい。

iPhone Developerのひとりとしては「怖ぇええ」が先にきてしまいそうにはなるけれども、それでも僕は、Appleはそれなりに適切な判断を下したのではないかと考えている。暴挙だとか、横暴だとか、基準が分からないことに対する萎縮効果であるとか、いろいろマイナス要因は指摘されているけれども、それこそがAppleの戦略だと考えるべきだ。そのメッセージはこうである。Appleのようなクールでスタイリッシュな製品に掲載するには後ろめたさを感じるようなコンテンツのホルダーは、どうぞご退場ください。

Appleは、iPhoneで世界を鎮圧しようなどとは考えていない。Google Androidは恐らく今後、iPhone OSよりも大きな市場になるだろう。あのWindows 95戦争のときと違うのは、今はAppleは音楽市場を制した巨大なメディア企業でもあるということだ。そして次は、電子書籍市場をその射程におさめつつある。それで十分に今後成長が見込める。

オープンプラットフォームに対する戦略として有効なのは、そこに魅力的なコンテンツを維持し続けることである。ファッションに喩えると分かりやすい。Androidがユニクロだとしたら、Appleが狙っているのはZARAとか、少し上だけれども一般向け、くらいの層だ。App Storeは全てのコンテンツホルダーのためのオープンプラットフォームではない。Appleのブランドイメージの射程に合致する優良コンテンツを保持するホルダーのための選ばれたプラットフォームである。

となれば、長期的には多少高くても顧客が支払おうと思うアプリを作り続けられる実力、体力、センスを持ったコンテンツホルダーを育て、選別していったほうがいい。センスを持った開発者であれば、不当に値段を下げることもないし、たとえ短期的に下げたとしても生き残るだろう。低価格競争でまず最初に淘汰されていくのは、実はコンテンツ制作能力の低いデベロッパーである。

これは顧客にとってもメリットがある。アプリを購入するという経験に慣れるためのコストは、最初は低い方が良い。長期的にはアプリの単価は上がっていくだろうが、その頃には優良なコンテンツの提供者の割合は劇的に増しているだろうし、安心してお金を払うだろう。

そして、そうした時に最も収益性の高いアプリだと彼らが考えているコンセプトのひとつが、iPad登場時にJobsが示した「Liberal Arts」というキーワードなのだろう。スタイリッシュでクールでリベラルなアプリを出すためには教養が必要であり、ウィットに富んだ深い知性と洞察力が必要になる。だからもしこの市場で残りたいのであれば、何が売れるかではなく、何がユーザを、スマートで、クールな方向に導くかを考え続けることだ。iPhone市場では結果的にそれが勝ち残る唯一の方針であると僕は思う。

ART apps collectionというArtyなアプリを紹介するイベントが、現在国立新美術館で開催されている文化庁メディア芸術祭のギャラリートークとして開催されていたので軽く顔を出してきた。iPhone関係のいろんな人が参加していたみたいで、TwitterのTLにも幾つか参加している顔がちらほら。

個人的な感想を述べるならば、商業的で「アーティな商業ソリューション」と、実際にこれはアートであろうというアプリと２種類あったようで、前者に対する違和感が会場を包んでいた時間もあったように思う。僕はiPhoneアプリを作っている側で、コンテンツ産業に片足突っ込み始めている人でもあるんだけど、この辺りの違和感を正直に表明し、少々突っ込んで検討するのには（それはとても馬鹿だけれども）誠実でありたい。

全ての人の手に表現の道具が行き渡りつつある現在、いわゆるホワイトキューブに展示されるべき「アート」という概念は崩れ始めており、「なう」なアートとそうでないものを区別するのはますます困難になりつつあるから、無下に前者を全否定することはできないし、プラットフォームを作ってアーティストのための機会創造を行っているのは、とても大変ことだ。これは今実際に仕事にしているからこそよく分かる。

のだが、アート的なもの、と、アート、はやっぱり違う。アートとは何かという問いに対して「あえて緩やかな境界しか設けない」ことが、アートを向上させるかといえば、そうではないから、あえて区別することをここでは厭わない。ルールが存在するからこそ、アートが成立している。ここでいうルールというのは僕たちが普段から使っているルール、言語とか文化とか、そうしたみんなに共有されている価値基準そのものだ。現代芸術には、細分化されているものの、明確なルールが根底に基準として存在する。アーティストに求められているのは、このルールを更新し続けることだろう。だから今現在のルールが何なのか、見極める能力がアーティストにも、それを育てる側にも求められる。ではこの国において、アーティストの庇護者はルールを明確に理解し、それを超えたことを分析できるのか。実質的には、「コンテンツ産業」を庇護するために、アートというラッピングを施していると揶揄されても、たぶん誰にも反論ができない。それが、この国の文化産業の弱さなのかもしれない。

今日出てきた「ART」なアプリが「ART」であるためには、「ルールをこのように更新したのだ」という主張が認定され、それが作品に接した者にも無意識的にでいいから理解されなければならないと思うのだが、その過程をさっぱり無視して「アート」だと自己主張するから、違和感を感じるのではないだろうか。

言い方を変えると彼らは表現において、どのような「その発想はなかった」を意図的に観衆に言わせたのか。それを問うて初めて、あれは「アート」だったと言えるのだと感じている。時を経て問われ続けるものもあるし、一刀両断されるものもあるだろう。ART Appsが果たした成果を見守っていくのは、とても楽しみである。

その上で、前述の話題に戻ると、プラットフォーマーがアーティストのための環境整備を自任するならば、アートやアーティストにどう貢献できるのか？彼らの行為を理解した上で場を用意することができるのか？は激しく問われることとなるだろう。アートのためのという冠がついた途端に、そこはTwitterやFlickr、YouTubeといったCGMの延長上にはない特殊な空間を用意した、という性格を帯びることとなる。現代の美術館が「場」の性質の根源から「美術館美術」などのワードで厳しく問われるのと同じように、常に問いかけが必要になる。そうした意識を持つべきか否かを含めて、ART Apps Collectionは議論を呼ぶ出発点としての「場」ではあったように感じたのだが、いかがだろうか。

まぁまだ、出して１週間しか経っていないんだけど、
だからこそ展開戦略の失敗についても含め、新鮮な感想も残せるだろうと思うので。
ざっくりすぎて＆母数少なすぎて、そのデータ意味ねーよとかは、うん、その通り。。

なぜ公開するかというと、サイト連携やサポートを含めるとコスト高になっていくiPhoneアプリを、
どうマネージメントしたらいいのか、ちゃんとアイデアとノウハウを共有していきたいわけです。
iPhoneアプリの製品サイトどうしたらいいの？って話、実に少ないしね。

出したアプリは、Music Aliveという音楽系のアプリ。
http://www.scivone.com/iphoneapp/musicalive/
ドラムや手拍子などの多彩なエフェクト音をiPhoneに入れた好きな音楽のリズムに合わせてタップして遊ぶ、
インタラクティブな感覚が新鮮なミュージック・プレイヤーアプリ。まだあまり売れてないけど。

あ、買っていただけると喜びますよぅ（もちろん）。
Apple Storeへのダイレクトリンク

市場規模は、多分みんなが驚くほど、上位と下位の差が激しいよね、というのが実感。
iPhone Appで儲かっているところは現状、超大手か、
開発から広報まで、全部できる個人デベロッパーだろうと思います。Fladdictさんなどが有名か。

あるカテゴリーで上位100位に入っていても、ほとんど意味がない。
え、そんなに少ないのって絶句すると思います。や、ほんと。
あるカテゴリーで50位以内でも、１日数十売れれば良い方じゃないのかなー？

まぁカテゴリーにもよるし、国内だけの話なので、全世界だとどうだろう？
という話ではあるんだけれど、うちはこれが初アプリなので、観測気球の数が足りないです。
今後いくつもリリースして、観測精度を上げていくことになると思うけど、
総合トップ25に入らなければないのと一緒だと思って構わないだろうと思う。

ちなみに全世界でって、どうやればいいんでしょうかというのは、
また別途記事にまとめようと思っているので、あくまでこれは国内の話。

で、ここからが、これまであまり載っていない情報だと思うんだけど、
・上記ウェブサイト製品トップページ閲覧数に対してのStoreクリック率は16.25％、購買率は暫定3.14％。
・Storeリンククリック数に対しての購買率は暫定19.2％。
この尺度が正しいか、そして、これが高いのか低いのかは判断が分かれるところ。
だが、こういうサイト構成でこういう成果か、というのはお分かりいただけるかと思う。
ご参考にしていただきたい＋アドバイスもいただけたら幸い。

（01/19追記：それから他のAppを買われている、という要素をLinkShareの仕組み上排除できていないので、
Music Aliveに対する厳密な購買率ではないことを併記しておきます。多分若干下がります。）

細かい効果測定などは、分かっちゃいるけど現状コストに見合わないので無理かなぁ。
今、開発側はサポートページの作成と、iPhone対応をやっているところです。
ちなみに現時点での、iPhone経由のアクセスは全体の8％程度、平均ページビューは約3P程度。
Mac経由の平均ページビューが約6Pなのと比べると、やはり非対応だと閲覧ページ数が下がるようだ。

しかし最大の前提として、いかんせんPVを稼げていない。
動画をみればお分かりの通り。それが第一の問題ではある。
取り上げてくださったのは、Macお宝探偵団さん、Applelinkageさん、
インプレスケータイWATCHさん、マイコミジャーナルさん、PBWebさんなど。
（こちらで確認しているものだけ挙げているのと、全部は挙げてない）
あと、iPhone・iPod touch ラボさんが動画が好きとTweetしてくださった。

ちなみに、作成したプロモーション動画はこちら。1週間で1,000ヒット。

動画の作成方法については判断が分かれるところで、
プレイ動画をそのままのせるのが、最も正しいやり方だというのが通説。
ただしうちは、今回あえて違う手法で行ってみた（これも観測気球で）。
ただこれは「iPodに入っている曲なら、どんな曲でも遊べるんです」という
アプリの意図が伝わらないという致命的なバグを抱えているので、そもそもがアウトだと思う。
ちなみに動画の作成に費やしたのはおよそ半日。これも判断が分かれるところか。

というわけで、動画の失敗とPVを稼げていないことが、広報的には最大の課題。
当然、アプリの機能やデザインといった部分での要素もあるのは大前提で、
これについては今、ロードマップを作成しているところ。ユーザさんは買ってくださった分だけ確実にいて、
熱烈なメッセージを送ってくださった方がちらほら出てきているのは、とても嬉しいです。
きちんとこまめに対応していきたいなと考えています。

最後に、iPhoneにおけるプロモーションについては、
いいタイミングでエリカ女史がライブチャットしてるので、読んでみることをおすすめする。
http://www.tuaw.com/2010/01/15/tuaw-livechat-promoting-your-app-store-products/

名指しで検索されるようなので、復活コンテンツです。

注：本記事は10.5向けに書かれています。Snow Leopardでは、64ビット版MySQLのインストールが強く奨励されています。特にRails用でインストールしたいと思っている人は注意しましょう。詳しくは以下参照。
http://journal.mycom.co.jp/news/2009/09/01/033/index.html

もしない場合、MacPortsを使って入れるのが一般的ですが（いろいろ便利だから入れといた方がいい）、MySQLのDMGパッケージを落としてきて、普通のアプリケーションを入れるかのごとく入れてしまってもOK。ただしその場合は、パスが通ってないので、Terminalでmysqlを呼び出しても、bashさんに「そんなのねーよ」と怒られます。

パスってなぁに

Linuxに慣れてないとパスってなぁに状態だと思うので簡単に解説。簡単にいえばパスっていうのは、Macでいうエイリアス（ショートカット）のようなものです。「毎回、/usr/local/mysql/bin/mysqlって打つのは、めんどいよねー、じゃあショートカット作っちゃおう」を実現するのがパスです。ただ、エイリアスやショートカットと違って、「.bash_profile」や「.bashrc」という設定ファイルを作らないといけない。

通常の処理で必要な設定を書き込むファイルは、「~/.bash_profile」、「~/.bashrc」の２つで十分です。これは、~/.bash_profileは（１．で書きましたが、）ログインシェルが起動時に真っ先に読み込まれるファイルなので、これを作成しておけば確実に設定が読み込まれること。また ~/.bashrcについては、またシェルを立ち上げるたびに処理のために必要な環境変数や設定を読み込ませるためです。

一度、どんなパスが通っている（経路が作られている）か確認しましょう。

$ $PATH
ふーん、などと思ってもらえればOK。

「なにを~/.bash_profileに書き、何を~/.bashrcに書き込むのかの区別」ですが
~/.bash_profileに記述してよい設定
　・コマンド検索パスの設定（PATH変数）
~/.bashrcに記述した方がよい設定
　・エイリアス（別名）の設定　
　　これは「alias　ls=’ls -l’」のようにコマンド文字列に別名をつける設定です。
　・コマンドプロンプトの表示設定（PS1変数）

パスの通し方・設定の反映

viというコマンドベースのエディタを使って、「.bashrc」「.bash_profile」をホームディレクトリに作っていきます。まずはTerminalで「cd」とだけ打つ（Enterキーを押すこと）。するとホームディレクトリに飛ばされます。「ls」と打つと、今いるディレクトリの内容物が一覧になるはず。「あ、なるほど。ここなのね」とか思ってください。次に、

$ vi ~/.bashrc
i

「$ 」は入れなくて大丈夫です。次に「i」とだけ入れれば、Insert modeに切り替わります。下の方にINSERTと出てるはず。「~/」っていうのは今いるディレクトリ（現時点ではログインユーザのホームディレクトリ）のことね。まずは以下の２行を追加します。

alias mysql=/usr/local/mysql/bin/mysql
alias mysqladmin=/usr/local/mysql/bin/mysqladmin

打ち込み終わったら、エスケープ（esc）キーを押して「:wq」と打ち込みEnterキーを押すと、viがファイルをセーブして終了してくれます。同じようにして、~/.bash_profile に以下を追加しましょう。

PATH=/usr/local/mysql/bin:$PATH
export PATH

これでパスの設定は反映されましたが、システムに認識されてないので、認識させてあげます。その前に、もう一度「ls」と打って「あぁ本当に作られてる」などと確認しておきましょうね。では、次のコマンドを打ちます。

$ source ~/.bashrc

はい、これでシステムに認識されたはずです。パスが本当に通ったか確認しましょう。

$ $PATH

MySQLの管理者パスワードを設定する

次に、MySQLのrootパスワードを設定しましょう。

$ sudo mysqladmin -u root password ‘password’

後者の’password’のところを変えます。’記号はそのまま残しておいて大丈夫です。以上で基本的なインストールは終わり。MySQLに行けるか確かめます。

$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 5.0.67 MySQL Community Server (GPL)

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> exit
Bye
$

こうなればOK。上記操作の通り、mysqlの操作から抜けるときは「exit」と打ち込んでEnter。他にもいろいろ設定することはあるんですが、まぁその辺は他のサイトや本をみてください。いつかフォローする可能性はあります。

Snow Leopard + Ruby on Rails 2.2でMySQLを使う

いわゆる追記です。Rails 2.2以降ではMySQLが標準装備ではなくなりました。そのためMySQLをデータベースとして利用する場合は別途gem install mysqlを求められることがありますが、そのままでは動かないことがあります。

ドライバインストールしたのに動かない、あるいはうまくインストールできないというときは、まずはこの辺の方々の記事を参照してください。

MacOSX での Rails 2.2 環境を構築して　MySQL のドライバでハマる
http://d.hatena.ne.jp/seiunsky/20081231/1230752200

上記の手順を試しても駄目な場合（以下のようなエラーがでる場合）は前提条件を一度確認しましょう。
Error: uninitialized constant MysqlCompat::MysqlRes

Snow Leopardでは、64ビット版MySQLのインストールが強く奨励されています。詳しくは以下参照。
http://journal.mycom.co.jp/news/2009/09/01/033/index.html

64ビット版MySQLをインストールしたら、以下の手順でgem installをやり直します。

sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql- config=/usr/local/mysql/bin/mysql_config

これでうまく行くはず。メモ書きなので詳細はいずれ。