小野マトペの業務日誌(アニメ制作してない篇)

はてなダイアリーの閉鎖をうけ、旧ブログ http://d.hatena.ne.jp/ono_matope/ から移行しました。続きは→ http://matope.hatenablog.com/

6-7月放送のNHKみんなのうた「ゆらゆら」(6/3〜)の映像を手伝いました

日記

（訂正：6/4〜からのようです）
明日から放送になる、6-7月ぶんのNHKみんなのうた「ゆらゆら」の映像を手伝いました。


ゆらゆら | NHK みんなのうた

「ゆらゆら」の映像制作を担当した「劇団かかし座」には少々縁があり、自分が大学在学中、趣味で映像をやっていたことから、在学中は頻繁に上演作品の舞台映像を手伝っていました。今回は業務外のプライベートな時間を使って手伝い、主に海まわりの表現を中心にAfter Effectsを担当しました。「かかし座」の持ち味である色鮮やかな美術やユーモラスな手影絵も必見で、面白いものに仕上がっていると思います。ぜひ御覧ください。

放送予定（6月・7月）
月　総合10:55　Eテレ16:00
火　Eテレ12:55
水　総合10:55　Eテレ16:00
木　Eテレ12:55
日　総合10:55
http://cgi2.nhk.or.jp/minna/sch/schedule_list.cgi

最後の方は体力の限界を突破していたのだけど、自分がいいと思うものを産みだすための苦労ならどれだけでも幸福、という感覚をずいぶん久しぶりに味わうことが出来ました。とてもとても楽しい2ヶ月間でした。

追記：劇団かかし座では、映像の出来る方を募集中だそうです。興味のある方は採用情報を御覧ください。いろんなことを試すことができる思います。

MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLのDATETIME型は本当に遅いのか検証してみた

Programming 日記

バグの話

近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。
バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。
以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。

select date from STATUS force index(date) where date='2010-01-19' limit 10;

この現象は、5.5.3,5.5.4での現象としてバグ報告がなされ、すでにパッチ待ちになっていた。
MySQL Bugs: #52849: datetime index not work
MySQL Bugs: #53149: MySQL doesn't use indexes on date column properly because of collation
よって5.5.5がリリースされれば解消されているのだけど、バグ報告中で報告されていた回避方法を紹介。

  • 文字列をBINARYにキャストする
    • 本事象は、文字列がlaten1かbinary以外の文字コードとして処理された時に起こるらしいので、文字列にbinary属性を与え、キャストしてやる。
    • ex) select date from STATUS force index(date) where date= binary '2010-01-19' limit 10;
  • 整数形式で結合する
    • 文字列ではなく整数形式で値を与えてやる。こっちの方がすっきりしてるけど、ライブラリのプレースホルダで値を設定するときはデータ型に注意が必要そうだなー。
    • ex) select date from STATUS force index(date) where date= 20100119 limit 10;

あとDATETIME型が遅いって本当？

INT型の方がデータ取得の処理スピードが150倍高速の圧倒的効果である。INT型はINDEXを最適に使い目的の結果を返してくれるためここまでのパフォーマンス結果がでたものと思われる。面白い副産物結果として、DATETIME型ではINDEX有り・無しかかわらず処理結果値が同じということで、DATETIME型はINDEXの恩恵を受ける事があまりできないのである

http://blog.fukaoi.org/2009/03/19/mysql_datetime

fukaoi.org
以前、時刻の保存形式としてDATETIME型は低速でイケていない、unix_timestamp()関数で値を設定したINT型で保存すべき、というを話を上の記事で読み、なるほどそうしておこうかなと漠然と思っていたのだけど、ちょうどいい機会なので、MySQL5.5でも通じるTipsなのか検証してみました。ちなみに、MySQLのバイブル実践ハイパフォーマンスMySQL 第2版にはこうある。

3.1 最適なデータ型の選択

  • 通常は小さい方がよい

一般に、データの格納と表現を正しく行えるデータ型のうち、最も小さいものを使用するように心がける。データ型が小さいほどディスク、メモリ、CPUキャッシュで使用する領域が少なくなるため、通常はその方が高速である。また、処理に必要なCPUサイクルも通常は少なくなる。(略)

  • 単純なものがよい

(略)たとえば、文字セットとその照合順序(並び替えルール)は文字の比較を複雑にしているため、文字よりも整数を比較するほうがコストがかからない。ここに例が２つある。日付と時刻は文字列ではなくMySQLの組み込み型として格納すべきであり、IPアドレスには整数型を使用すべきである。
(強調は引用者)

DATETIMEないしTIMESTAMPを推奨されました。じゃあ、日付表現のための最も小さくて単純なデータ型ってなんでしょう。DATETIME型とTIMESTAMP型の解説は以下のようになってます。

3.1.4 日付と時刻型

DATETIME
　1001-9999年までの値を格納する事ができ、精度は1秒である。タイムゾーンとは無関係に、日付と時刻をYYYYMMDDHHMMSS形式で整数にパックする。これには8バイトの記憶域が使用される。(略)

TIMESTAMP
　1970年1月1日午前0時(グリニッジ標準時)からの経過時間を秒数で格納する。つまり、UNIXのタイムスタンプと同じである。記憶域を4バイトしか使用しない(略)

はい、DATETIMEもTIMESTAMPも、形式が違うだけでどちらも整数で管理されているんですね。ここら辺は公式ドキュメントに詳しいです。unix_timestamp()したINT型とTIMESTAMPはデータの格納方式として等価と考えていいということでしょうか。

特殊な振る舞いはともかく、TIMESTAMPはDATETIMEよりもストレージ効率がよいため、TIMESTAMPを使用できる場合一般にそれを使用すべきである。UNIXのタイムスタンプを整数値として格納することもあるが、通常はそうしたところで何の特もない。その形式は何かと扱いにくいので、お勧めしない。
(強調は引用者)

うーん、INTのTipsをフルボッコです。でも実際のところはどうなのでしょう。計測してみました。

計測条件
  • 比較対象はcreated_at (DATETIME型)と、created_at_timestamp (TIMESTAMP型)と、created_at_int(INT型)。
  • インデックスを使用したクエリ、使用しないクエリで、Range結合をテストする
  • テストデータは2000万行
  • データベースエンジンはInnoDB
  • クエリキャッシュを無効にし、同一クエリを何度か実行し代表的な値を採用した
  • 利用テーブルは以下
CREATE TABLE `STATUS` (
  `id` bigint(20) NOT NULL DEFAULT '0',
  `user_id` int(11) NOT NULL,
  `created_at` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `date` date NOT NULL DEFAULT '0000-00-00',
  `text` varchar(256) NOT NULL DEFAULT '',
  `point` int(11) NOT NULL DEFAULT '0',
  `created_at_timestamp` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `created_at_int` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `c_` (`created_at`),
  KEY `ct_` (`created_at_timestamp`),
  KEY `ci_` (`created_at_int`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

スペック

OS ：CentOS release 5.3
DB ：MySQL5.5.3
CPU： AMD Phenom(tm) 9350e Quad-Core
Mem：8GByte

インデックス無し

DATETIME型
mysql> select SQL_NO_CACHE * FROM STATUS ignore index(c_) where 20090701000000 <= created_at and created_at < 20090701235959 limit 1;
1 row in set (5.92 sec)
TIMESTAMP型
select SQL_NO_CACHE * FROM STATUS ignore index(ct_) where 20090701000000 <= created_at_timestamp and created_at_timestamp < 20090701235959 limit 1;
1 row in set (8.40 sec)
INT型
mysql> select SQL_NO_CACHE * FROM STATUS ignore index(ci_) where unix_timestamp(20090701000000) <= created_at_int and created_at_int < unix_timestamp(20090701235959) limit 1;
1 row in set (6.13 sec)

DATETIME型とINT型がほぼ同程度の速度で、TIMESTAMP型だけなぜか一周り遅いという結果に。えー、上でTIMESTAMP型とINT型はデータ長以外等価って言い切ったばかりなのに…。実際には等価ではなく、扱うロジックに差があるために速度差が出ているんでしょう。でもTIMESTAMP型よりもデータ長が長く格納方式の複雑そうなDATETIME型がTIMESTAMP型よりも速いっていうのが謎…。何故に…

インデックス有り

DATETIME型
mysql> select SQL_NO_CACHE * FROM STATUS where 20090701000000 <= created_at and created_at < 20090701235959 limit 1;
1 row in set (0.00 sec)
TIMESTAMP型
mysql> select SQL_NO_CACHE * FROM STATUS where 20090701000000 <= created_at_timestamp and created_at_timestamp < 20090701235959 limit 1;
1 row in set (0.00 sec)
INT型
mysql> select SQL_NO_CACHE * FROM STATUS where unix_timestamp(20090401000000) <= created_at_int and created_at_int < unix_timestamp(20090401235959) limit 1;
1 row in set (0.00 sec)

えーと、どのデータ型でもきちんとインデックスが適用されていて、データ型の差異が計測出来ない程度に高速ですね。2000万行でこの速度ならどれ使ってもパフォーマンス上全く問題ないといえるでしょう。インデックス無しでは速度に差がありますが、どっちみちインデックス無しではどんなデータ型だろうと実用的なクエリ実行は行えません。これなら実践ハイパフォーマンスMySQLの教えに従って組み込みの時間型を使ってもなにも大丈夫そうです。自前のINT型、必要なし！
しかし深追いさんのベンチマークとの差はどこから来たんでしょう…。MySQL5.0.67から 5.5.3へのアップデートのどこかでDATETIMEが改良されたのでしょうか。ただ、深追いさんのベンチマークは、そもそもDATETIMEに対してインデックスが効いている気配がないので、今回僕がハマったようなバグかCardinalityの破損であのような結果になったのではないかという気も少ししています。自分の環境では以前の5.0.67でもDATETIMEのインデックスは効いていたような気がするので…。ちなみに今回のテストはInnoDBで行いましたが、MyISAMテーブルでもdatetimeインデックスは適用されました。

まとめ

時間のデータは素直にDATETIME型かTIMESTAMP型を使おう！*1

実践ハイパフォーマンスMySQL 第2版

実践ハイパフォーマンスMySQL 第2版

*1:TIMESTAMP型は環境のタイムゾーンに依存し、4byteとコンパクトだが2037年問題を抱えている

iPadで絵を描いてきた！

日記

金曜日、@umezoが「iPadを触らせてもらいに行くけど誰か来る？」って行ってたので、ホイホイとiQONのVASILYさんまでお邪魔してきました。

SketchBook Pro

iPadいじらせてもらった諸処の感想は後述。どうしても試してみたくて@kyunsさんに頼んで有料のドローイングアプリを試させてもらった。AutodeskのSketchBook Proというアプリ。
このアプリが素晴らしく、しばらくお絵描きに没頭してしまった。この様子は複数のソースでUstream/YouTubeしていたので、観てもらえばどんな様子か分かると思う。


@pen2さん撮影(ust)。50分くらいあるけど、描き始めてからTwitterにアップするまでの完全収録。ニコニコ動画に上げてみた。ダイジェストだけ編集したんだけど、音声が消えてしまう現象が起きたのでUstreamアーカイブそのままをアップした。
D


@kyunsさんビュー(ust)
http://www.ustream.tv/recorded/6063992


別角度から、@wady撮影


完成品。いい絵かどうかはともかく。


観てもらえれば分かると思うけど、SketchBook Proがかなり本格的に作り込まれているため、「細部を書き込むときは拡大しないといけない」という点にさえ気をつければまずまず実用的に描ける。俺程度のテキトーな描き手には十分応えてくれる感じだった。鉛筆には及ばないけど、マウスやペンタブよりずっといい感じ。

液タブとの比較

まさにこれは液晶タブレットだよなーと思った。感圧に対応していないのと、指で描いているために精密な描画ができないという欠点があるけど、前者は今後の技術とTipsでカバー、後者はiPhone用スタイラスを使うという手http://www.youtube.com/watch?v=jYSRQDxeGZYを使えば解消しそう(iPhoneでは太い専用スタイラスは使い物にならなかったけど、iPadの大画面なら使える)。


逆に、液タブ製品よりもよいなと感じたのは、以下の点

  • どこでも使える
    • 液タブをカバンにいれて持ち歩ける人はいないけど、iPadなら持ち歩いて、サッと取り出せる。
  • わいわい描ける
    • 178°まで奇麗に見える液晶で、その場にいるみんなが絵を覗き込める。会話がうまれる。楽しい！
  • ぐるぐるできる
    • iPadの背面はとてもいい感じのカーブを描いているので、意のままに紙を回転させる事ができる。
  • 個人的に、書き味が好み。
    • 液晶に限らないけどペンタブって、紙面がツルツルしてて個人的に苦手だった。線が走らなくてぐにゃぐにゃになっちゃったり。そういうのはiPadにはなかった。


感圧機能がないとはいえ、これでWacomの一番安い液晶タブレットの半額だから、液タブ欲しいけど買えなかったって言う人はiPadも考えてみるといいかもしれないよ！

Wacom Cintiq 21UX DTZ-2100D/G0

Wacom Cintiq 21UX DTZ-2100D/G0

落書き以外のiPadいじった感想

  • HTML5によりNew York Timesのページ上で再生される動画クリップや、HTML5版YouTubeで涼しい顔して再生されるHD動画が美麗。液晶の品質がよく解像度も充分なので、立てかけて動画やスライドショー再生させてるだけでも絵になる。
  • iPadで動くiPhoneアプリはClassic環境みたいなものだと思うべきで、iPad用にUIが作り直される必要がある

http://www.youtube.com/watch?v=w_qyZQcnr9A
http://www.youtube.com/watch?v=SPcGlJsCfII

  • タイピングに関しては結構慣れが必要。でもiPad上で開発できるようになりたい。
    • TouchTermを使ってターミナルを使わせてもらった。vimを起動して何行か書いてみたけど、遅延が感じられない。iPhone上だとj,k押してからカーソルが動くまで1,2秒の遅延があるので、ちょっとしたパラメータの変更くらいしかできなかった。なのでiPadはCPU性能的には開発に充分と思われ。あとはSSHクライアントのUIがiPad最適化され、秋にマルチタスク対応すれば資料と行き来してコーディングできる環境が整う。

http://www.youtube.com/watch?v=hZ5N7la06XA

LVMスナップショットバックアップのためのシェルスクリプトを作った

Programming

今までmysqldumpを使ったデイリーバックアップを行っていたんですが、 いざ障害時に復旧しようとすると、SQLの実行のための時間がかかりすぎる、MERGEテーブルに対応していない(のでSQLをsedで書き換えるハメになった)等の理由から、LVMスナップショットバックアップに移行することにしました。


というわけでさっき

  • /dev/ssdvg/lv01 を/var にマウントした環境において
  • MySQLのデータディレクトリ /var/lib/mysql/favotter/ をLVMスナップショットバックアップする

というスクリプトを書きました。何かの参考にするために上げておきます。LV消したりとか危ない事を自動化しているので、これを使ったり参考にしたりした事によるいかなる損害も保障しません。また、このスクリプトを実行する前に、バックアップしたいVolumeGroup上に、スナップショット用の空き容量(今回は1GB)を作る必要があります。


やってること

  1. MySQLをFLUSH TABLEする(書き込みバッファの内容をファイルに書き出す)
  2. /dev/ssdvg VolumeGroupのlv01 Logical Volumeのスナップショットを /dev/ssdvg/lvSnapに1GBで作成
  3. /var/lib/mysql/favotterを /バックアップ先ディレクトリ/＜日付＞-にコピーする
  4. /dev/ssdvg/lvSnap LVを削除する
  5. コピーをtar.gz圧縮する。
#/usr/bin/sh
DATE=`date '+%Y-%m-%d-%a%H:%M:%S'`;
SRC_LV="/dev/ssdvg/lv01";
SNAP_LV="/dev/ssdvg/lvSnap";
SNAP_SIZE=1G;
DB_NAME="favotter";
DB_PATH="lib/mysql/$DB_NAME/";
DB_PASSWORD="<your db password>";

DEST_PATH="/home/matope/Documents/favotter/dbbackup/hotcopy/";
DEST_FULL=$DEST_PATH$DATE-$DB_NAME;

sudo mkdir /mnt/snap;
sudo /sbin/modprobe dm_snapshot;
sudo /sbin/lsmod | grep snapshot;

mysqladmin -u root -p$DB_PASSWORD flush-tables;
sudo /usr/sbin/lvcreate -s -L $SNAP_SIZE -n lvSnap $SRC_LV;
sudo mount $SNAP_LV /mnt/snap;
sudo cp -rpv /mnt/snap/$DB_PATH $DEST_FULL;
sudo umount /mnt/snap;
sudo /usr/sbin/lvremove $SNAP_LV --force;
sudo tar -cvzf $DEST_FULL.tar.gz $DEST_FULL;

この本を参考にしました。すごく実用的でおすすめです。ふぁぼったーもめきめき高可用性ゲットやでー

Linux-DB システム構築/運用入門 (DB Magazine SELECTION)

Linux-DB システム構築/運用入門 (DB Magazine SELECTION)

ふぁぼったー Version.4をリリースしました！：新機能概要

ふぁぼったー

先週の土曜日からデータベース障害のためふぁぼったーが停止するという事態になりましたが、今朝障害復帰を果たすとともに、同時にふぁぼったー新バージョンへの移行を行いました。
新ふぁぼったー
機能詳細は以下

『Myふぁぼったー』機能(要ログイン)

TwitterのOAuth認証に対応し、ふぁぼったーにログインする事で、自分がフォローしているユーザーのふぁぼりやふぁぼられを読めるようになりました。ユーザー各人が趣味の合わないTweetに煩わされること無く、より興味のあるつぶやきを読みやすくなります。

listsへの対応(要ログイン)

2009年9月にTwitterに追加された「lists」機能に対応しました。ユーザーが購読しているListsのメンバーのふぁぼりやふぁぼられを表示出来ます。

@tsuda/media-contentリストの例(要ログイン)
http://favotter.net/list.php?user=tsuda&list=media-content

『ふぁぼったー検索』の強化 (一部要ログイン)

従来より提供している『ふぁぼったー検索』がさらに強化され、

  • AND/OR/-検索
  • 任意のfav数によるフィルタリング、
  • RSSフィード

に対応しました。さらに、Myふぁぼったーと連携し、ログインしているユーザーのFollowingのふぁぼりやふぁぼられに絞り込んだ検索が可能になりました。(Following絞り込みのRSSフィードは未対応)

クロール範囲の拡大

従来、ふぁぼったーでは日本語ユーザー 3万9000人、英語ユーザー 6万8000人のFavoritesを収集していましたが、新クローラーの開発により、毎時間日本語ユーザー 10万人以上、英語ユーザー 30万人以上のクロールを実現しました。

その場でfav機能の強化

ふぁぼったーにログインしていれば、今までのようにパスワードダイアログが出る事無く、1クリックで確実にふぁぼることができるようになりました。

ドメイン移行

従前のサブドメインを改め、専用ドメインに移行しました。新URLは以下
日本語版 http://favotter.net/
英語版 http://en.favotter.net/


取り急ぎ機能概要まで。

ふぁぼったーをBest Twitter Appに投票しよう！について

ふぁぼったー

前回のエントリー以降、どうにかして海外の動向を知ろうと海外Twitter界隈についてアンテナを広げようと思っていたんだけど、Favstarさんがこんな事をつぶやいていた。
http://gyazo.com/0fbff0d749104f5bde6b93c4c342c235.png

Enjoy favstar this week? Vote for Favstar.fm in the Open Web Awards as best twitter app. http://mashable.com/owa/votes/category/26?c=26 - Top 5 get acknowledged.


和訳：今週はfavstarを楽しんだ？ Open Web Awardsの Best TwitterアプリにFavstar.fmを投票してね！http://mashable.com/owa/votes/category/26?c=26 - トップ5が認められる

http://twitter.com/Favstar/status/5460494247

Open Web Award？なんぞ？
という訳で調べてみた。

Open Web Award

http://gyazo.com/f010c732a9929773dd8e0bfff8417513.png
Open Web Awardとは、Mashableというソーシャルメディア情報サイト？が2年前から毎年開催している、要するにユーザー投票によるソーシャルメディアの賞らしい。で、このTwitter Best App部門では、その名の通りTwitter関連サービス／アプリ世界一を決める投票がおこなわれているっぽい。


で、Favstarさんがこれにノミネートしている！しかも結構票を集めている気がする*1！！これは負けてられない！ぼくもそれやりたい！！

本題

といったいきさつで、ふぁぼったーもOpen WebAwardsにノミネートしてみたいと思います。

つきましては、ふぁぼったートップに掲示したバナー

からOpen Web Awardsにジャンプし、
http://gyazo.com/86882e2bc13908665e0680aef1b49646.png
の画面からSubmit & Tweetでノミネート(推薦)をお願いします
ノミネートは一人につき一日一回までだそうです。このノミネート数ののべ数が多かったサービスが決選投票に進出します。
ええ、 blogランキングぽちっとしていってくださいね的な感じで押して頂ければ、是非に。


最後に、もうちょっと詳しくレギュレーションを説明しますね。
このアワードは、ノミネート(推薦)期間と、投票期間に別れており、前述の通り、推薦期間内に上位5番目までの推薦を集めたサービスが決戦投票に進出する。

  • 推薦期間 - 10月14日-11月15日(EST)
  • 投票期間 - 11月18日-12月13日(EST)
  • 結果発表 - 12月15日(EST)


推薦期間もう残り5日しかないので、実は既に絶望的な状態なのだけど、まあやらないよりはいいだろう、とりあえずやってみようというのが今回の趣旨です。以上、ご協力よろしくお願いします！！

*1:根拠は無い

なぜふぁぼったーは英語圏で負けたのか

前口上

今年の7月にリリースされてから、早々に公式サイドバー広告入りするなど英語圏で圧倒的な人気を集めるfavstar.fm。ふぁぼったーは2008年の1月から英語版サービスを展開していたにもかかわらず、なぜ英語圏の制空権を得られなかったのか。たまたま見つけた海外のふぁぼったーユーザーに Twitterで直接インタビューしてみた。

インタビューに答えてくれたのはjoshsharpさん、メルボルンのWeb開発者らしい。


Togetter(トゥギャッター) - まとめ「なぜふぁぼったーは英語圏で負けたのか(インタビュー原文)」


やりとりはとぅぎゃったーにまとめたので、簡単な和訳を記します。

インタビュー

―― こんにちは、私はふぁぼったーの開発者です。海外の方の意見が知りたいので、ふぁぼったーとFavstarについて質問していいですか？
joshsharp: いいですよ、お役に立てれば。 :)
―― ありがとうございます！ ふぁぼったーは英語圏に向けたWebサービスとして、Favstarと比較して何が足りないと思いますか？ *1
joshsharp: 僕はふぁぼったーが大好きだよ。Favstarはほんの少し綺麗で、時々favを素早くクロールするけど、でもそれだけだね！僕はふぁぼったーの方が好き。
―― ありがとう！デザインとクロール速度は大切ですね。

サイトデザイン、というかより本質的にはフォントいじりについてどう思うか聞いてみた。あれは完全にテキストサイト文化なので、外国人に面白さが伝わるか疑問だったので。

―― 日本人として、僕はふぁぼったーのフォント表現をポップだと感じるんですけど、あなたはどう思いますか？フォントをモノクロに直すべきかなと思ってるんだけど。
joshsharp: いや、フォントや色は既にグッドだよ。
―― ふむふむ。安心しました。

外人的にもフォントいじりはオッケーらしい。これは収穫。あまりダラダラ質問しても悪いので、再びストレートを投げてみた。

―― じゃあ、正直なところ、なぜFavstarはfavotterと違って英語圏でウケたと思いますか？
joshsharp: 正直、多分デフォルトの日本語テキストがちょっとだけユーザーをビビらせたと思う。あと、サブドメインじゃなくて専用のドメイン名を持つべき。それと、あなたがイングリッシュスピーカーで、既にその一部になっていないのであれば、巨大な'西洋の'サイトの間で人気を得るのは難しいね。それは理にかなっていて、自明な事だ。

もうなんか、これに尽きるというような意見が出てきた。英語のできないやつは世界のWebサービスで通用しませんよって当たり前か。当たり前なんだけど、動く現物があればなんとか分かってくれるだろうとタカをくくっていたようなところがある。甘かった。あれだ。悪しき日本人の「いいものを作れば売れる」幻想。
言語の壁は情報の壁である以上にユーザーにとって心理的な、いわば空気の壁でもあって、空気の壁を感じさせたらユーザーは敬遠する。相手の文化圏の空気が分からなくては、ユーザーに受け入れられる筈もないと感じた。ふぁぼったーは英語インターネットの空気が分からなかったのでfavstarに負けたんだ。
とはいえ、まあ空気なんてわかんないので、当面取りうる対策としては、「サイト上の英語をちゃんとする。日本語を完全に排除する」。その上で機能性を向上させれパブを強化すれば、まだ機はあると思う。

――なるほど、わかった。ふぁぼったーに最も足りないのは、1. ネイティブで自然な英語のサポート、2. ドメインというわけですね。
joshsharp: その通り。あと、多分宣伝してくれる誰か英語を話す人。
――ああ、宣伝は大切ですね。次バージョンのリリース時にはTechCrunchあたりの英語メディアにプレスリリースを送りたいと思ってます。
joshsharp: techcrunchはいいアイデアだね．
――OK、急なお願いなのに難しい質問に答えてくれてありがとう。とても参考にになりました、がんばります
joshsharp: いや、役に立てたようでよかったよ。

いや、本当にためになりました。英語の勉強しよう！！

*1:いきなりダイレクトな聞き方になってしまった…