今日は、僕が学生だったときにお世話になった会社で、一番お世話になった方とのランチ。


もう6、7年ぶりかな。
まぁ、ともかくすごい勢いで久しぶりだったが、会ってみると久しぶりという気もしない。

次の日から一緒に仕事をすることになりました、ということになっても違和感はまったくないと思います。ハイ。



僕は当時から生意気な学生で、それはそれはもう出来が悪くて大変だったが、いやほんとによく面倒見ていただきました。あれからずいぶんたったいまも、僕は生意気な小僧であることに変わりないし、きっとこれからも変わらないでしょう（笑）。でも、僕がこうしていつでも生意気にとんがっていられるのも、こうしてまわりで僕という人間を理解してくれる人たちがいてくれるからなんだな、とあらためて認識。どうもありがとうございます。



実はね、ちょっとここのところ周りに気をつかいすぎて、というか気にしすぎて、自分のスイングというかスタイルというか、マイウェイみたいなものがもやにかかってしまったんですよ。野球選手がまったく打てなくなるように、サッカー選手の動きが急に悪くなるように、自分がなにをしているのかが頭で理解できなくなる、そんな感覚。それでもなんとかしなくちゃと毎日を奮闘しながらやりすごしているのだけど、いかんせん自分のフォームを見失ってますからね。出てくるアイデアが凡打凡打凡打の山。カー、まったく才能のかけらもない。




でも、「田中くんは自由にやらないとね」の言葉にはっと目が覚める。




そうそう、そうなのよ。
もっと自由に、もっと空を飛ぶように。


アイデアの源泉は常に自由の世界にあって、自由な状態にいるかぎりアイデアなんていくらでも出てくるのだ。あとは成功するまで続ければすむだけの話だった。

ちょっとね、現実世界のリアルな風景を見すぎてしまいましたよ。



復活してからは行き詰まっていた仕事が進む進む。
そして、自分が調子よくなってくると、まわりも調子よくなってくるように思えてくる。



いやーとてもよいランチでしたね。
また近くにお越しの際にぜひ。

"emo-graphic"ってのは "EMOtional GRAPHIC" から僕が勝手につけた。感情属性または情動属性を意味する。


いまの20代後半以降の人で、PCでのネット利用に慣れているは、モバイルのWebについて、

・小さい画面で見る気がしない
・キーを何度も打つ気がしない
・通信が遅くてやる気がしない
・でも10代は携帯よく使うんだよね
・そりゃ生まれた頃から携帯があるもんねぇ
・でも自分は使う気がしないなぁ

といったところが一般的じゃないかな。
メールだけ使って、Webは終電確認などでたまーに使う、という人が現実的にはほとんどじゃないかと。



そりゃPCを使っていれば当たり前。

・画面が広い
・複数のタスクをほぼ同時に処理できる
・画面を切替ながらほかのことがほぼ同時にできる
・応答性能が高い
・自由度が高い
・インターフェースがこなれている

などなど、優位点しかないようにも思える。


一方で、携帯の優位点と言えばその「携帯性」だが、最近のモバイルWebのヒットサイトを見ているうちに、この「携帯性」は「位置」ではなく、「感情」なのではないかと考えるに至った。つまり、「感情を携帯している」と。



すぐにわかる特徴も含めて、最近のコミュニティ系携帯ヒットサイト（モバゲー、Mr&Miss、前略プロフなど）をみて感じた特徴を3つあげてみる。

1. 非常にライトなコミュニケーション
2. 現実的な利益
3. テクノロジーはバックヤードに



■1. 非常にライトなコミュニケーション

一つは、これはすぐにわかることだが、多くのユーザが「絡もう」「絡んで」と、非常にライトなコミュニケーションを望んでいること。

そして、そのコミュニケーションの根っこは「相談」や「解決」といった重たいものじゃなくて、「共感」であるということ。困っているといってもそんなに深刻にこまっているわけではなく、悩んでいるといってもそれほど深刻に悩んでいるわけじゃない。ただ、「だよねだよねー」と聞いてくれればそれで十分なのだ。いい年した男性諸氏には、この「ただ共感してほしい」というオンナゴコロ的情動がちょっとわかりにくい話ではあるのだけどね。深くは必要としていないけど、一人だとさみしい。そんな繊細な心が浮かび上がってくる気がする。



■2. 現実的な利益

そして、もうひとつの特徴は、そのサービスを利用する動機が「リアル世界での身近な利益」であるという点。建設的である必要はまるでないが、「暇がつぶせる」「誰かにわかってもらえる」といった非常に身近な（その人だけにとっての）利益が得られるかどうかがポイント。もはやこのリッチコンテンツの時代にゲームがしたくてモバゲーにアクセスする人なんていないんじゃないか。当たり前だが、そのゲームに興じた結果、退屈な電車の時間の存在を意識しなくてすむ、ということを欲した結果なんだろう。



■3. テクノロジーはバックヤードに

最後に、一番最近のヒットであろう顔ちぇき！を見てもわかるが、表向きテクノロジーベースではないという点。下記のエントリに見事にこのサイトについてのレビューが書かれているが、まさに「画像解析技術はぶっちゃけどうでもいい」のである。
モバゲーを瞬殺した「顔ちぇき」という怪物 [Student magazine]

2番目の特徴ともリンクするが、このおもしろい遊びのおかげで現実世界に得られる利益（合コンネタにすぐ使えるなど）は、「この技術が本当に高度かどうか」「この技術が現実的に使用できるレベルにあるかどうか」といったところにはまったく関係がない。要は、「なんとなくそれっぽい（笑）」という結果を誘発できればそれで成功だ、ということである。（実は「なんとなくそれっぽい」というところをはじき出すためには高い技術力が必要なのだが、本エントリではあえて無視する）



上記のことをふまえると、「携帯だからできること」ベースに考えるのではなく、「日常生活で起きる感情変化のどの部分をどうやって楽しく切り取るか」ということになってくると思う。

リクルートは人生の各局面で必要になる情報を提供する雑誌展開をしているが、ちょうどそれのマイクロ版のように、「24時間の中で起きる感情変化をうまく切り出して楽しめる味付けをした演出」というのが新世代型モバイルWebサービスの共通点であろうと思う。


とすると、これに対応するマーケティング概念はジオグラフィックでもサイコグラフィックでもなく、エモグラフィックとも言うべき、きわめて一瞬の感情をとらえた「感情/情動属性」をどのように判断しエスコートするか、ということになる。

そもそも10代と主婦しか存在しないモバイルにジオグラフィックを適用しても意味はないし、日常生活上意識や興味が一点に定まっていることはあり得ないのでサイコグラフィックではおおざっぱすぎる。やはり、いまこの場に「なんとなく」したいかもしれないと思うことをつかまえるためには、エモーショナルな部分への踏み込みが必要になるだろう。




ではここから先にどうやって踏み込んで実際のサービスをつくっていくか、という点については僕も考えを巡らせているところ。ただ、考える道筋を整理した後はいたずらに考えをふくらませず、素直な感情に従って単純に「自分だったらしてほしいこと」をサービス化した方が理にかなっているかな、とも思ったり。

Flash（ActionScript）
Rails
JavaScript（ガッツリ系）

がいまの技術的なテーマである。
いずれも、現時点ではまだまだ勉強もきちんとした経験も足りていない。




「いまできること」と「この先10年でつくっていきたい世界」を区別して考える。




根本的な思想としては、

・サーバサイドでのコーディング量を減らし、
・その分の作業をUI（ソフトウェアを使うこと本来の気持ちよさ）にまわす

ということ。

Ruby をさわってみると、これまで慣れ親しんだPHPのコード量はやはり多い。Ruby を使いたいと思うのは、単に流行だからといったことではなくて、コード量を減らすことでバグを生みにくくし、デバッグをしやすくする仕組みそのものがほしいからだ。サービスを品質よくローンチして、メンテナンスは「マイナスをゼロにする」デバッグ中心ではなく、「ゼロをプラスにする」追加機能や改善を常に行うためには、そうした仕組みが必要となってくる。




さてさて、その技術の上になにを乗せるか、ということについては別エントリにて。

Flash を使った携帯での非同期通信の方法を調べていたんだけど、なかなかこれといったものを見つけることができず。Flashでのムービー作りは黎明期に少しだけやったことがあるけど、めんどくさいわりには邪魔なものでしかなかったのでやらなくなった。昔は企業ページの最初に無駄なFlashムービー（しかも「skip」なし！）とかってありましたね。


でも、いまや携帯にとってFlash は断然無視できない存在。JavaScriptを解釈できるフルブラウザよりもはるかに重要な意味を持ってくるツールになっていると思う。それは、保存可否の問題。Flashは携帯のデータフォルダにFlashデータを保存して、そこでいつもユーザと接することができる。


とはいえ、僕自身はActionScriptを使った開発はまったくやったことがないので、ちょっとこの辺は近いうちにナントカしなくちゃいけないと思う。言語自体はそれほど難しくないと聞くけど、慣れの問題があるので、いざ作りたいものがわき出てきたときに手が自由に動かないとすごくストレスになってくる。


なんて思っていたところ、下記の書がとてもグーな内容でした。




いわゆるFlash本はデザイナーさん向けの「モーショングラフィックス＋イベントアクション」解説か、プログラマ向けのActionScriptリファレンス（内容的にはエフェクト系が多い）が圧倒的に多く、通信とかアプリ全体に関わるソリューション系の解説をしている書籍はほとんどない（と思う）。

そんな中、初っぱなから「Google カレンダーを携帯で見る」ためのアプリがチュートリアルの一発目にあるのはとても親切で今の時代にマッチしている。アプリの本質はエフェクトやインターフェースではなくて、データの入出力。その目的を支えるための手段がエフェクトやインターフェースだってことが素直に伝わってくる良書です。


もちろん、ActionScriptの詳しいところはきちんと別のリファレンスでチェックしないとイケナイと思いますが、「携帯アプリをどう作るか」というソフトウェア開発のキモの部分を再確認できるという意味で、この手のアプリ設計にこれから携わろうとしている方は必読かと思います。

考えるべきは10年先の日本と、世界。


大切なことはいまできることをベースに考えることじゃなくて、創りたい未来の絵をどう描くかだ。


「ネットの世界は10年先が見えない」なんて言い訳はもう十分。

どういう世界をつくりたくて、自分がそのために何ができるかを考えなくては。

よいプロダクトを生むためには、よい手段で行う必要がある。
よい手段で行うためには、よい手段を選択する必要がある。
よい手段を選択するためには、よい選択肢を得る必要がある。
よい選択肢を得るためには、よいインプットをする必要がある。


よいインプットかどうかは、インプットしているときにはわからない。
なぜなら、インプットがよいかどうかは、常に未来になってからしかわからないから。


だから。


よいインプットをするためには、インプットの量と種類を増やす必要がある。



最近、どんなインプットをしましたか？

気持ち悪かったのだが、直し方がわからず。






バージョンアップを繰り返したので、smultron のアイコンが3つも。



以下のコマンドで直りました。
http://journal.mycom.co.jp/column/osx/180/

$ cd /System/Library/Frameworks/ApplicationServices.framework/Frameworks/LaunchServices.framework/Support

$ ./lsregister -kill -r -domain system -domain local -domain user

スッキリ。

「笑顔でいることができないなら、あなたは本当の意味で働いていないのですよ」



この1文を読むだけでも価値があります。



忙しい人は世の中にたくさんいますが、会社に働かされて忙しい、やらざるを得ないから忙しい、自分自身の完璧主義に追い込まれて忙しいなどなど、本来的な意味での「忙しさ」を誤解してしまうこともしばしば。かくいう僕だって、調子に乗って仕事を抱え込みすぎて、自分を極限に追い込んでしまって、まわりに心配をかけてしまうことがよくあります。


でも、その仕事は誰のためでもない、自分の笑顔のためにしているということを、どこかのタイミングで取り戻さなくっちゃ。そして、自分の笑顔は、他人の笑顔を栄養分にしているということも。




だから、自分と他人の笑顔のために、仕事をするんです。


ちょっと無理をしがちな人は、いつもこのことを意識しなくちゃいけないですね。




もちろん、僕自身も含めて。

みなさん、DB設計はどんな感じでやってます？


僕が慣れた形式はエクセルでカラムをさくさくと書いていくやり方なんですが、エクセルだとテーブル数が多い場合にもうER図を書きたくなくなります。（実際面倒で書かないこともある）

Visio を使えたらいいんでしょうが、それだけのためにVisio買うのもねぇ。

というわけでツールを2種類ご紹介。



DBDesigner4

なんで「4」なのか知りませんが、インストール型のDB設計ツール。
WindowsとLinux版があります。

Linux版をmac OSXで動かそうとしてみましたが、ダメでした。

有志の方がローカライズした日本語版はこちらにあります。


けっこう直感的に使えます。
テーブルを作るのもOKだし、すでにあるDBに接続して、自動的にテーブル情報を書き出させることもできます。
ちなみに、これでテーブルを作った場合は自動的にSQL（CREATE文など）を作ってくれるので、楽ちんです。

が、カラム情報を書いているときにキーボードを使ったりマウスに持ち替えたりする必要が少しあり、これが地味ーにストレスです。また、閲覧する側もこのソフトをインストールしないと設計情報をビジュアルで見られないのもちょっと、ね。たしかに画像やXMLで出力できますが、見やすいのはやはりこのソフトで開いたときなので。

ビジュアルで定義できるのはすごくいいですけどね。



WWW SQL Designer

こちらはブラウザ上で動くWebアプリ。
ソースをダウンロードしてきてPHPの動くWebサーバにコピーすれば、ローカルで動かせます。こちらもテーブル作成及びすでにあるDBに接続してテーブル情報を書き出させることができます。

こちらもカラム情報の入力はけっこう面倒。1操作ずつキーボードとマウスを入れ替わり立ち替わり使うのでストレッシーです。また、カラムの説明書き（コメント）を書ける欄がないので、設計を共有する目的にはけっこうつらいかも。

ただ、特別なソフトのインストールなしでリレーションがビジュアライズできるのはとてもよいです。



というわけで、僕の結論としては、テーブル設計はいままで通りエクセル上でさくさくと書き、SQL文も自分で書く。テーブルを作成してしまった上で、ER図を作るところだけ「WWW SQL Designer」のロード機能を使う、ということになりました。

前のエントリで、「日本的なものを再評価」を書いたが、そのカラミのお話。


マーティ・フリードマンがどこかで「コブクロはとても日本的だ。あれはアメリカではあり得ない。」と言っていたのを思い出してから、コブクロを少し聴くようになった。

これまでまったく趣味ではなかったが、聴いてみるとなんだかじんわりきて、ああ、僕も日本人なんだな、と思う。もう消えてしまったようだが、Youtubeで「桜」という曲のPVを見ると、グッと来るものがあった。そうそう、春は別れと始まりの季節なんだよね。


コブクロ経由で、「馬場俊英」というミュージシャンを知る。
ちょっと加藤鷹に似ている。

これがまたさらに日本的。
聴いていると、リズム感の悪い小太りなおじさんが嬉々として手をたたき、涙を流しながら聴く姿のイメージが頭から離れないほど、日本的である。


だが、とても心地よい。
ああ、自分もそのおじさんのうちの一人だったか。



いやー、こういうのを好んで聴くようになるなんて、年をとったかなぁ。
よく聴くと、じんわりときます。












でも、恥ずかしいので、しばらくしたらガンガンのロックとヒップホップに戻りたいと思います。ハイ。

最近、仕事で海外のサイトをよくチェックしている。
特にECサイト。


それで思うのは、とかく日本のECサイトは特徴的だと思う。
これほど「売り手の顔」が全面に出ているサイトが多いのは他の国のサイトではなかなか見つからない。

日本では売り手、作り手、あるいはその家族の写真が載る。
海外では、その商品にまつわるイメージ写真が載る。



機能や入りやすさや商品の見せ方から売るか、あるいは人から売るか、という根本的な違いがおもしろい。まぁ、この違いが顕著に見えるのは、僕があまり海外の小規模ショップを見つけられていないだけなのかもしれないけど。ただ、インターネット後発の日本でECが普及していく上で、コンテクストを再定義し、全体としてこうした流れに乗せていった先人は、やはりスゴイと思う。


海外向けのサービスを志向したとき、僕は技術や発想の斬新さよりも「日本的な細やかさ」を強みとして勝負したいと思っている。使っている人間が心地よいと思うこと、かゆいところに手が届くこと。寿司や工芸品がそうであるように、ソフトウェアやサービス開発にしても、きっとその面が強いことがきっと海外への一歩となる、はず。


ということで、最近は「日本的なもの」をよく観察して、深く掘り下げたいと思ってます。美術書をゆっくり見たり、寺社巡りをしたりしたいなぁ。

これは他にまねできるところもないでしょう。
ホットペッパービューティー


営業が強いってことは、ほんとに素晴らしいことだと思う。
光通信や大塚商会も営業力が強いけど、ちょっと営業力の種類がちがうし。
また、単に営業が強いだけではこの企画は生きてこないでしょう。営業で契約をとったあとに、営業先を素材としたコンテンツを紡いで、全体がユーザにとって価値のあるものになるところまできちんと面倒見ないといけない。



・2,300件のヘアサロン
・10,000店のヘアスタイル
・8,000人のスタイリスト

しかもこれ、掲載料ビジネス。


いやー勉強になります。ハイ。

trin.jp についてのお知らせです。


個人投資家向けサービスを目指したtrin.jp を、5月末で一時サービスを終了させていただくことになりました。

皆さん、ご利用ありがとうございました。
心から感謝しております。



これから、もっともっと素晴らしい製品、サービスを作っていきたいと思います。

今後ともどうぞよろしくお願いいたします。



【追記】

なお、ご登録いただいたデータは安全に保持し、サービス再開時にそのまま使用できるようにいたします。

とにかく楽しいことがやりたい。
自分のまわりにいる人がハッピーになってほしい。



でも、1つのたのしいことをやるためには、100のつまらんことをやらなくちゃならない。



ここの部分を乗り越えるのがひとつ課題だな。

もっと狂気を。




それともうひとつ。

プライベートの充実も大切な要素なんだけど、こっちも課題がたくさん。
もっと普通の人のようにやさしさと配慮が必要だな。


普通の人でありつつ、狂った人である、という離れ業ができる人って、どんな人なんだろうか。


まだまだ修行が必要である。

いやー笑った笑った。
大前氏はこんなお茶目なものも書けるのか。

ちょっとじた自慢話のオンパレードと、私は好きな女の子のために空手を始めたというようなわけのわからない自己紹介ネタまで、軽めトーク満載。

まだ読んでいないが、こちらの本もいわゆる中年ネアカ系。




なんだかよくわからんが、日本は明るくなってるみたいだ。

ちょっと煮詰まったので渋谷を散歩。
机の上だけじゃアイデアは出てこないもんね。


平日の昼間でしたが、やっぱり人がいますねー。
みんな普段なにしてる人なんでしょ。
って、自分もまわりにそう思われているんだろうな。きっと。


おのぼりさん気分で、すっかり変わった街の風景や、僕が10代の頃から変わらない店内を散歩しながら、新しい事業プランを考える。昨日買った大きなスケッチブックを手にしているから、いつでもプランを書き留めることができる。



東急ハンズの向かいに、おしゃれなレコード屋さんができてた。

ああ、10代のころによく買っていたな。
レコードってなんでいいんだろうねぇ。別にDJプレイはやらないけど、すごく好きでした。CISCOとかManhattan Records は当時から定番。レコードはでかいし邪魔だし、プレイヤーにセットすることなんてめんどくさい作業の骨頂なんだけど、なんか音楽を聴く行為の本質って感じがする。音の表情がとてもいいよね。

店内には、またいい感じの R&Bが流れている。そうそう、好きなことがある空間にしばし来ていなかった。最近は音楽なんてiTunes のラジオか Youtube のプレイリストをかけっぱなしにしてるだけで、音質も音の表情もへったくれもなかったし。

みなさんは自分の好きなことだけがある時間や空間のところへ、最近行きました？




Book1st へ。

本屋に行くと、自分の内側からなぜかモチベーションがわき上がってくる。Book1st渋谷店はとてもいいね。好きな本屋さんの1つ。

平積みの本を適当に立ち読みして、モチベーションアップ。
アイデアの神も降りてきました。


たまにはこうした抜きの時間も必要っすね。
ネットばかりみてるとクサクサするぞー。

やりたいことが複数ある場合、それを狂ったように進めて、一段落したら次のことを始める方法しか知らなかったのだが、どうもそれはちょっとちがうみたい。


とりあえず2つ、大きなやりたいことを右と左において、交互に進めるのがいいみたい。頭もいい具合に切り替わるっぽく、実は一番効率がよいのかもしれないな。少なくとも自分の場合は。



ただし、抱える仕事が多すぎると強烈なストレスになるので注意。


時にトラブル対応とかで突発的な仕事が入ってくる（しかもそういうのって重なる）ので、その辺も考慮しつつ、両脳でバランスよく狂うってことが大事かも。

おもしろかったのでご紹介。


履歴書を書く際、卒業年度ってわからなくなりません？

イヤ別に僕がいま履歴書を書くようなケースはまったくないんですが、他社サービス研究のためにちょっと自分の経歴の登録が必要だったりしまして。


で、ああ、そういえば、昔から自分の卒業年度ってさっぱりわからないな、と再認識。



そんなときに卒業年度チェックが便利。

順風満帆な人生の方のみ対応とのことですが、これで自分の生年月日入れて検索すればいい感じに履歴所用の年表を表示してくれます。



ちなみに僕は一浪一ダブ（ひどいね）なので、多少解釈が必要ですけどねー。

なんともありませんでした。
脳出血もアルツハイマーも傷もなにもなし。


頭痛のタネは、たぶん、働きすぎ、目の酷使しすぎ、肩と首こりすぎでしょう、とのこと。


※頭部写真もらってくればよかった。自分の中身ってけっこう楽しいのね。




ここ2週間ほど重かった身体も少しずつよくなってきました。

ご心配おかけしましたー。



もうだいじょぶよん。

新サービスのベースアプリはCMSがいいな、ということで下記の2つを評価。

・Rubricks
・Radiant CMS


しかし、それぞれの理由によってインストール自体ができない。

【Rubricks】
rake がうまくいかない。
'rake' を load するのに失敗している？ んなアホな。

$ rake db:migrate --trace
(in /****/rubricks)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
rake aborted!
wrong number of arguments (1 for 0)

（中略）

/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16


【Radiant CMS】
こっちはインストールはできたものの、デフォルトのままでは環境変数HOMEの値がソフトウェアの想定と異なるらしく、lighttpd が起動しない。

# service lighttpd restart
lighttpd を停止中: [ OK ]
lighttpd を起動中: [ OK ]
# /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/vendor/rails/railties/lib/rails_generator/lookup.rb:33:in `expand_path': couldn't find HOME environment -- expanding `~' (ArgumentError)
from /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/vendor/rails/railties/lib/rails_generator/lookup.rb:33:in `user_home'
from /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/vendor/rails/railties/lib/rails_generator/lookup.rb:105:in `use_component_sources!'
from /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/vendor/rails/railties/lib/rails_generator/lookup.rb:53:in `included'
from /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/vendor/rails/railties/lib/rails_generator.rb:38:in `include'
from /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/vendor/rails/railties/lib/rails_generator.rb:38:in `send'
from /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/vendor/rails/railties/lib/rails_generator.rb:38
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
... 19 levels...
from /usr/local/lib/ruby/gems/1.8/gems/radiant-0.6.1/lib/radiant/initializer.rb:32:in `run'
from /www/__labo/0087_rails/radiant/public/../config/environment.rb:15
from /www/__labo/0087_rails/radiant/public/dispatch.fcgi:21:in `require'
from /www/__labo/0087_rails/radiant/public/dispatch.fcgi:21

これは本家のメーリングリストで同様の問題を指摘しているところを探し当てるまでは行った。
[Radiant] About "couldn't find HOME environment" problem

しかし、この先の対応まで手がつかず。
WEBrick では起動できたので確認してみたが、うーん、これは単なるblogシステムだな。

Rubricks の方が使えそうではあるけれど、、せめてインストールくらいはさせてほしい。


というより、rails の情報は日本語にしても英語にしてもまだまだ散らばってて、まだまだ手を付けにくいな、というのが率直な印象。コンポーネントをつなぎ合わせて、習得しながら自作していった方が速いかもしれないなぁ。


それはそうと。

現在企画の方も練り上げているところ。
できるだけポップで楽しいサービスにしたいっす。

でも、技術要件を試しつつ、企画の要件を練り上げるのはけっこう至難の業ですね。脳みそフル回転です。ハイ。

Google に出稿されている広告におもしろいものがあるらしい。


「はんだ付けお助けします」

って言われて、よし来たお願いしよう！という人がどれだけいるんだろうか。

リンク先はここだった。



「はんだ付けの駆け込み寺」って言われてもね。。。いや実際困ってたらすごく頼りになるんだろうけど、超ニッチだよなぁ。でも世の中には絶対必要。

> 「うっかりして、部品を取ってしまった・・」　「ＬＥＤを交換して、自分だけのオリジナルに改造したい・・」
> 「故障箇所がわかっているのに、自分では修理できない」

いやいや、LED交換したい人って超少数ですから。
でも、楽しくていいですねー。職人てすごくグッと来る。


どうやらタモリ倶楽部にも出演したことがある模様。
こちらにレポートが。

はんだ付けDVDが異様に見たくなる。

環境作りにこれほど悩むってのもひさしぶりな体験だ。
選択肢がたくさんあるのはいいんだけども、これだけあって、しかもそれぞれが小粒な状態ってのはどうも決めかねて困る。

a. Apache + mod_fastcgi
b. Apache + mod_fcgid
c. Apache + mod_ruby
d. lighttpd + mod_fastcgi
e. ソース or RPM？
f. WEBrick

f のWEBrick はとても便利だが、パフォーマンス面でまずそのまま公開できないかな、と。それに、環境の違いによってアプリの動く動かないってのは常にあるので、開発環境と本番環境で別のソフトが動いている状態はアウト。だって動作検証にならないじゃん。

安定性とか枯れ感とかはもちろんシステム要件を決める重要なポイントだけど、環境構築が容易だ、ってのもかなり上位にランクされる選択のポイントだと思う。

だって、サーバを追加したりするとき、簡単なほうが手順が少なくていいでしょ。



上記の組み合わせ以外にももちろん選択肢はあるけど、結局上記全部を試すことに。それぞれパフォーマンスが微妙にちがう、ということで。（めんどくさいけどしょうがない）



で、導入と検証を延々と10時間ほど行った結果、導入のしやすさ、パフォーマンスからして最終的に選んだのが「d. lighttpd + mod_fastcgi」。安定性に問題が多少あるような印象も受けるけど、なにより速くてそれなりに海外では人気になっているようなので、こなれ感も今後さらに加速していくでしょう、と言うことで。


最終的な構成としては、

表からのアクセスをDNSラウンドロビンで受けて、
内部でpoundによるリバースプロキシによって振り分け。
pound から PHPを使用する Apache と Rails を使うlighttpd に振り分けて、
さらに少数の書込系MySQL（InnoDB：クラスタリングするかは気分次第）と
複数台の読込系MySQL（MyISAM）で分散、

という感じになればよいかな。
まずは1台ではじめて、それぞれの役割が必要になったときに切り分けていけばよいでしょう。


今度時間があるときにインストール作業のログを書きたいと思います。
ではまた。

次期サービスにはRubyを使うことになりました。
ご存じの方はいろいろと教えてくださいな。


ところで、このニュースすごいね。
民間刑務所で Ruby によるソフトウェア開発者を養成、アウトソーシング業務を


ソフトウェア開発の現場が元受刑者だらけになったら休憩時間のトークがかなりデンジャラスでおもしろいことになりそうだね。「おめーなにやったんだよ」「おめーこそ」みたいな。


でもなにはともあれ手に職をつけるってのはよいことだし、技術があれば自分に自信がつくのは間違いなし。

というわけでぜひこれをきっかけに優れた技術者になっていただければ。