3月 - 5th

iPadに向けた電子書籍の具体的デモがすごい

Posted at 14:31 | Filed Under HACK, Web, コミュニケーション, デザイン, マーケティング, 時事

自分はともかく、子供に遊ばせたい・・・と思うデモンストレーション。何冊もの絵本や何冊もの問題集を買うんだったら、iPadにいろんなコンテンツがあればこっちのほうが楽しそう。。。
As the race to be be ebook format of choice hots up, Penguin is making some bold, experimental bets. These first-look demos of forthcoming books from iPad’s iBook Store, presented by Penguin Books’ CEO John Makinson in London on Tuesday, give an idea how publishers might approach Apple’s tablet…
電子ブックのフォーマット競争は激化していますが、大手出版社のPenguin社が出したiPad向けの電子ブックデモ。CEOのジョン・マキンソンさんがロンドンでiPadに向けてどんな手法ができるかを見せてくれます。。（意訳）
引用元: First Look: How Penguin Will [...]

3月 - 5th

そろそろクリップアートのクオリティをなんとかしてほしい

Posted at 00:35 | Filed Under Web, Windows, デザイン

仕事柄、提案書を作ることが多く、それなりに資料作りは慣れてきた感があるのだが、マイクロソフトにそろそろ使い勝手とコンテンツ内容を見直してほしいのが、クリップアートだと思っている。Webの業界にいるので利用したいクリップアートのジャンルはそうジャンルは多くなく、サーバの絵だったりインターネットを表す絵だったりと、多少限定されるのだが。
その中でもよく使うのが、「人」を表すクリップアートで、「利用者」だったり「管理者」だったり「営業マン」だったり「エンジニア」だったり、役割関係を表すときに「人」関連のクリップアートを挿入することが多くある。
しかし探してみると、このアリサマである。
まず、「ユーザ」や「管理者」といったキーワードでは何も見つからない。だから仕方なく、「人間」で検索してみる。それがこれ。

もうさぁ、ガンジーとかショパンとか、下から二段目のアラブ系の人とかさぁ、本当に不要で、表示してほしくないんだけどさ・・・、いちいち出てくるのよ、毎回。右下のオペレータの絵がギリギリセーフ。そのとなりの宇宙服着てるヤツとか、なんなのよ、といつもツッコんでいる。
だから仕方なく「顔」とかで検索してみたりする。そしたらこれだ。

なんなんだよ、この「ジャジャーン」的な背景の顔シリーズ（１，２段目）。ゲームに出てきそうな顔が５，６段目。MSNメッセンジャーでおなじみの黄色い顔さんたちがいる６，７段目。さらには使い道のなさそうな７，８段目。
数が多けりゃいいってもんじゃないだろうに。もう少しアイコンの品揃えを考えて欲しいです、マイクロソフトさん。
ただ、こう思うのは自分がWeb業界にいて、Webサイト制作だったりSIの提案書を書くからなのかもしれなくて、仕事のジャンルによってはこういう顔たちも使える場面があるのかもしれない。あるのかもしれないんだけどさ・・・
いずれにしても、これだけOfficeも歴史あるソフトなんだから、業種別に最適なクリップアートセットを準備するとか、使用履歴に基づいてユーザーの嗜好に合わせて選別してくれるとか、親切な機能がほしいところ。
だから、最近異常にMacのKeynoteが欲しくなっちゃうんだ・・・。

iWork ‘09
アップル 2009-01-18
売り上げランキング : 101
おすすめ平均
Amazonで詳しく見る by G-Tools

3月 - 4th

失敗を　笑い飛ばした　バンクーバー

Posted at 13:52 | Filed Under コミュニケーション

バンクーバーオリンピックの閉会式を見てなかったのですが、開会式のシステム障害を逆手に取った演出がなされたそうですね。知りませんでした。素敵。
トラブルのニュースはこちら。
バンクーバー五輪：聖火台、点火する支柱１本が機能せず
【バンクーバー大前仁】１２日に行われたバンクーバー冬季五輪開会式で、聖火台に点火する際、本来はステージの下から４本立ち上がるはずの支柱のうち１本が起き上がらないトラブルがあった。このため会場で聖火リレーの最終走者を務めた４人のうち１人が点火できなかった。五輪組織委員会（ＶＡＮＯＣ）は「純粋な機械の故障。ライブ進行のイベントで起こり得るハプニング」と説明したが、式典のハイライトで思わぬ失態に観客席からざわめきが起きた。
http://mainichi.jp/select/today/news/20100214k0000m050052000c.html
で、閉会式の一幕なんですが。
4本目の支柱の中からピエロが登場して・・・・

ケーブルをつなぐぞー

うりゃ！

バシュっ！

ぬーんと

どーんと

おりゃー！点火！

完成！

失敗を逆手にとって大成功です。いいね、こういう文化。日本だったら誰のせいだー！とかいって業者同士で責任の擦り合いになっていたかもしれません。
ちなみに、次の冬季オリンピックはどこかご存知ですかね？そう、ソチです。ソチってどこよ？という方のために、地図を用意しました。こちらです。
大きな地図で見る
わかりづらいですか・・・ね。ちなみに左側は、黒海です。黒海は、文字通り黒い海なんですが、硫化鉄だそうですよ。生態系はわりと豊かだそうで、漁業も行われているそうです。ちなみに混乱しやすいのは（自分だけかもしれませんが）死海。死海はココ。
大きな地図で見る
海水浴はできるそうですが、異常に塩分濃度が高いので、生き物はほとんど生息していない。でもおかげで浮力がすごいから、浮かびながら新聞を読むこともできるそう。
やってみたい・・・

というわけで、全然違う話で終わります。
Thanks http://picasaweb.google.co.jp/catholympique/Vancouver2010_28_02#.

3月 - 2nd

GoogleがPicnikを買収したという話

Posted at 15:48 | Filed Under Google, Web, マーケティング, 写真

GoogleがPicnikを買った・・・。
Yahoo!傘下のFlickrに組み込まれているオンライン編集ツールがPicnikでして、たまに使ってたりしたんですが、GoogleのPicasawebに関してはストック型のサービスという性質もあるけれども、画像の編集機能が省かれていて、たまに不便だなぁと思うこともあり。
More than ever before, people are sharing and storing their photos online. But until recently, you had to edit your photos using client software on your computer. Today, we’re excited to announce that Google has acquired Picnik, one of the first sites to bring photo editing to the cloud. Using Picnik, you can crop, do [...]

3月 - 1st

西友ニトリあえずイケヤ

Posted at 13:59 | Filed Under HACK, マーケティング, 広告

西友にとりあえず行けや～
というCMで、妻キクがどうしても
西友　ニトリ　買えず　IKEA
って聞こえるってことで調べてみたら、なるほど西友、挑戦的なCMを作るのがお好きなようで、２作目なんですね。（前作はコジマ、ヤマダ、ジャパネットたかたを入れたＣＭ）

いやもう、ネットでは議論し尽くされたネタなので、イマサラ感ありありですが、まいいや。

2月 - 24th

みすず学苑のCMがヤバイことになっている話

Posted at 15:35 | Filed Under Google, Google Chrome, Web, Youtube, デザイン, マーケティング

私の出身地である名古屋には、美宝堂やアサヒドーカメラといったインパクト強めのCMがあるのですが、東京にも、みすず学苑という衝撃的なCMがあります。関西は・・・なんだろう、ながーーーーーーーーーーーーーーいおつきあいの京都銀行とかですかね。もっとありそうだな。しかもレベル高そう。
で、このみすず学苑ですが、テレビCM以外でも結構露出していて、交通広告（電車）でよく見かけていて、テレビでもちょくちょく見るわけですが、最近のCMがとんでもないクリエイティブに仕上ってます。タイトルは、プリンセス編。

「シンデレラれな～い！」「知らん雪姫！」「不合かぐや姫～」などでツカまれ、お決まりの「怒涛の英語と個人指導」と続きます。
しかしここからがインパクト強烈。
「成績アップ、プリン、プリン、プリン！」
と言いながら、最後はみんなでポーズを決めるんですが、背景にはプリンの雨が降っています。もうね、まったく意味がわからないんです。ついでに白雪姫の女性はめちゃめちゃ顔を黒く塗ってるし（いちおうツッコミポイントだと思ったので指摘しておきます）。
テレビCMにおいて、視聴者へのインパクトはかなり重要で、このクリエイティブによってかなりみすず学苑は完全に頭にインプットされましたが、問題は学習塾の信頼性が伝わったかどうか。
学習塾を選ぶときって、それなりにお金を払うわけだから、選ぶときも料金や通いやすさも然ることながら、実績や講師の質はもっと重要な要素になってくると思いますが、私も親として、親の立場で考えると、「みすず学苑」と聞けばあのCMが思い出され、なんかクソみたいなダジャレを並べまくってた品のない塾だよな・・・というのが印象で、今の時点では、子供をみすず学苑に通わせようとは、残念ながら思いません。そう、みすず学苑の広告には、「品」がないんです。
病院のWebサイトでは、ほとんどが「白」を基調としたものが多く、全体的に落ち着いたデザインであることが多いです。「病院」に最も必要なのは「信頼性」「清潔さ」であって、それを一番得やすいのが、そういうテイストなんだといわれてます。きっと病院という建物は昔から建物全体、設備全体が白いことが多く、「落ち着いた白＝きれいな病院＝信頼できる病院」という連想を持つ傾向があるのだと思います。
回転寿司チェーンのWebサイトでは、赤と黒、たまに木目をパーツに使用しているところが多く見受けられます。日本人が大好きなマグロと、海苔、そしてゲタを連想させる組み合わせです。新鮮さや雰囲気を伝えるためだと思われます。
学習塾の場合もやっぱり「信頼性」が必要のはず。加えて、「塾生を全力で志望校に合格させるという熱い思い」。ただ、「熱い思い」ばかりを前面に出しても胡散臭いだけ。だからそこは冷静にというか、クールに装い、実績面でアピールするのが正解といえます。
そう考えると大手予備校のサイトなんかは、代々木ゼミナールも駿台も河合塾も四谷学院も日能研も、すべて背景は白で統一されており、病院のような、でもちょっとアカデミックに大学のような雰囲気がうまく表現されています。ちなみに、みすず学苑も、Webサイトはわりと信頼できそうなトーンです（MovableTypeで作られてますね）。
・・・トーンはいいのですが、ビックリしたのはこのサイト、google chromeで閲覧しようとすると初回はアクセスが制限されてしまいます。
「警告：このサイトにアクセスするとコンピュータに損害を与える可能性があります。」
やっぱり・・・やばいでしょ、みすず学苑。塾のサイトなのに、Googleからはまったく信頼されていない。だれか教えてあげてください。不合かぐや姫。

2月 - 23rd

Twitterの投稿数は1日5000万だという話

Posted at 15:37 | Filed Under Google, Twitter, Web, コミュニケーション

As a member of the Twitter analytics team, part of my job is to measure and understand growth. The graph above tells a story of how we’ve grown over the past three years in terms of number of tweets created per day. Please note that tweets from accounts identified as spam have been removed so [...]

2月 - 16th

「日本でFacebookの地位を獲得するのは、やっぱりmixiか、それともGREEか」という記事が興味深い・・

Posted at 10:58 | Filed Under Web, Webビジネス, マーケティング

これは興味深い記事。GREEって使ったことないけど。
先日、mixiがFacebookのようなタイムラインを導入するべきではないかという記事を書いたが、この視点で日本のSNS市場を見た上で、当然もう一つ忘れてはいけないプレイヤーがいる。それがGREEだ。
引用元: [jp] 日本でFacebookの地位を獲得するのは、やっぱりmixiか、それともGREEか。 .
これが・・・

こうなるかもしれないよ、という図。わかりやすい。

確かにGREEって5年前ぐらいはmixiと争ってて、ユーザー数で全然勝ち目ないなーと思ってましたが、モバゲーぽくなってきたなーという印象を持つようになってから、たしかにmixiと立ち位置が明確に分かれてきたなぁと思ってました。一時期、モバゲーと区別がつかなかった頃もありましたが。
個人的には、Facebookが日本ユーザ向けに強力にローカライズしてくる可能性もあるんじゃないかと思ってますが、どうなんですかね。そのへんの議論はすでに語りつくされているのかもしれません。
たしかに、SNSゲームは、シンプルなものが多く、ゲームそのものはたいしたことないのだが、シンプルだけにハマりやすいのは否定できない。実際自分もやってるし。

2月 - 14th

Twitterのテーブルは3つで構成されているかも（DB入門編）

Posted at 00:23 | Filed Under Twitter, Web, デザイン, 日記

何気なく、風呂に入りながら「Twitterっていくつのテーブルで構成されているんだろう」と思ってしまって、DBの構造を推測してみた。仕事ではSalesforceのテーブル管理をしたことがあるが、ヤツはとんでもないテーブル数を持っていて、どこに何が格納されているのかさっぱり予測できない。当然カンペキに正規化されているんだろうけれども、あれだけ複雑なアプリケーションであるのと、やっぱりクライアントごとにしっかりデータを分けなければならないというポリシーがあるはずだから（営業データだからね・・）、基本的にはテーブル単位、あるいはDB単位で分けているんだと思う。
で、Twitter。「無料のつぶやきサービス」というサービスで、先のSalesforceとは求められるSLAがまったく異なる。個人単位でデータをエクスポート／インポートすることもない。爆発的に増加するユーザや爆発的に発生するつぶやきに、いかにスケーラブルに対応するかが、このサービスのポイント。それらのポイントをクリアするためには、どのようなテーブル構成が求められるのだろうか。元DBエンジニアの端くれとして、風呂の中で考えてみたのでメモしておきます。現役のエンジニアさんにとってはレベルの低い話なのでスルーしていただければ。
まず基本要件が、大きく３つ。
自分のつぶやきと自分のフォローしているアカウントのつぶやきをタイムラインで抽出できる
自分がフォローしているアカウントの一覧を抽出できる
自分をフォローしているアカウントの一覧を抽出できる
これがTwitterの基本機能（のはず）。そうすると、Salesforce的な設計であれば、
①アカウント一覧テーブル（全ユーザのアカウントを管理。アカウントID、パスワード、アイコン、各種プロファイル）
②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID）
③フォロー一覧テーブル（登録日付、アカウントID）
④被フォロー一覧テーブル（登録日付、アカウントID）
となるが、この設計だと①を除いた②③④は、アカウントごとにテーブルを用意する必要がある。ユーザーには利用頻度に違いがあるので、一度アカウントを作ったけれどもまったく利用していないユーザーに対してもこれらのテーブルを用意しておかなければならない。論理的に確保しておくだけなのでユーザーが少ないうちは気にする必要はないかもしれないが、その数が数千、数万を超えるようだと無視できないサイズになる。DBの中ではテーブルを作成すると、レコードが入っていようがいまいが、一定の領域を確保してしまうからだ（表領域と言います）。
ちなみに、下はTwitterのアカウント登録数推移。毎日20万～30万人のユーザーが新規登録している。恐ろしい規模だ。この規模で上のような設計をしていたら、ストレージがいくらあっても足りない。

ではそれぞれの共有できるテーブルにしていくには。①は共通のテーブルだからいいとして、②は全ユーザーで共有できそうだ。カラムの構成を
②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID）
から
②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID、アカウントID）
とする。こうすれば②も共有できる。自分だけのつぶやき一覧は、SQLで条件指定（where ユーザーID＝xxx order by 日付）
で抽出することができる。何億ユーザになっても、テーブルは１つで済む。
しかし、③と④がまだユーザー単位に必要だ。というわけで次に③と④をやっつけていく。
結論から言うと、③と④は合体して、１つのテーブルで管理できる。難しく考える必要はなくて、
③フォロー一覧テーブル（登録日付、アカウントID、）
④被フォロー一覧テーブル（登録日付、アカウントID）
から、
③＋④フォロー関係一覧テーブル（登録日付、フォロー元ID、フォロー先ID）
するだけ。錆付いた頭では、頭の中だけで考えるとちょっと時間がかかりました・・・。紙に書けば一瞬だった。こうすると、各レコードは
AさんがBさんをフォローした場合、（”201002132342″,”A”,”B”）というレコードが、
BさんがCさんをフォローした場合、（”201002132348″,”B”,”C”）というレコードが作成される。
こうすることで、すべてのフォロー関係を１テーブルで管理することができるようになる。自分が誰をフォローしているのかを知りたければこのテーブルから（where フォロー元ID＝A）で3列目を抽出すればよいし、自分をフォローしてくれているアカウントを抽出するには（where フォロー先ID＝B）で2列目を抽出すればよい。
これらの３テーブル
①アカウント一覧テーブル（全ユーザのアカウントを管理。アカウントID、パスワード、アイコン、各種プロファイル）
②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID、アカウントID）
③＋④フォロー関係一覧テーブル（登録日付、フォロー元ID、フォロー先ID）
で、ユーザーごとにテーブルを作成することなく、スケーラブルな対応ができるようになるわけだ（たぶん）。
厳密には、運用上無限に肥大化し続けるテーブルは扱いづらいため、つぶやき一覧テーブルなんかはレコード数単位で分割されていると思う。アカウントを発行するときにでも、①のアカウント一覧テーブルのカラムに、書き込み先のつぶやき一覧テーブルの識別番号を与えているかもしれない。またはテーブル自体は仮想的に一意の名前にして、実際にはIDのレンジでテーブルをパーティショニングしているかもしれない。あと、リストの管理とかもあるし、当然これだけでは済まないのは理解しています。
というわけで、勝手にTwitterのテーブル構造を予想してみましたが、これはTwitterがOracleやMySQLのようなリレーショナルデータベースを使っていたら、の話。GoogleのBigTableのような別のアーキテクチャを使っていたら、これらは全然違うだろうし、BigTableを理解していないので推測もできません。ただAPIを使ってTwitterアプリを作ってみたら、いちいち予想しなくてもわかりそうな気もする。作ったことないし、作る予定もないので永遠に推測の域を出ませんが。誰か正解知ってるのかな。
たまにはDBマガジンでも読んでみるかな。トレンドはキャッチアップしておかないとね、モチベーションがあるうちに。

Google App Engine for Java [実践]クラウドシステム構築 (WEB+DB PRESS plus) (WEB+DB PRESSプラスシリーズ) (WEB+DB PRESS plusシリーズ)
技術評論社 2009-09-10売り上げランキング : 17213
Amazonで詳しく見る by G-Tools