ホーム » ブログ » 2006年02月の記事

2006年02月の記事

« 2006年1月 | 2006年3月 »

プロフェショナルBSDを読む

2006-02-28 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク
プロフェショナルBSD
プロフェショナルBSD
このサイトから 3 が購入しました
全体で 52人 がクリック
posted with amazlet on 06.02.28
砂原 秀樹 植原 啓介 石井 秀治 林 周志
アスキー (2001/03)
売り上げランキング: 292,234
おすすめ度の平均: 4
4 かなり難しいから時間をかけて読む

akiyan.comをxreaの共用サーバーからさくらの専用サーバー(FreeBSDプラン)へ移転したのを契機に、unixへの知識欲が沸き上がってきました。そんな私にプロフェショナルBSDがお勧めということを聞きまして、さっそく読み始めました。

内容はかなり高度です。OSが起動するまでのプロセスがマザーボードのしくみから始まっています。とりあえずunixを使ってみたいという人向けではなく、本当にunixというOSを土台から理解して使いこなしたい人のための本のようです。運良く今の私は後者でした。読み進めるにつれ今までブラックボックス的に感じていたunixが少しづつ解明されていくのが心地よいです。「なんだ、こんな単純なことだったのか」と、目からうろこが落ちまくっています。

この本は文章中の要素がとても多いので、ゆっくりじっくり読み進めていきたいと思います。

2006-02-28 written by akiyan | レビュー | 固定リンク | コメント (0) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

あのときライブドアが落ちなかったのは、技術力ではなく運用方法にあるのかもしれない

2006-02-27 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

一連のライブドア騒動が起こったときライブドアのサービス群へのアクセスはかなりの量になったと聞きます。そしてライブドアのサービスが落ちなかったことに対して、ライブドアには技術力があるというコメントが数多く寄せられ関心を集めました。私も注意してその様子を見ていて、ほんとうにどういったシステムでどういったサーバー構成なんだろうと興味を持ちました。というのも、多くのWebサービスは予測不可能な急激なトラフィックは想定していません。想定すればするほど余分にコストがかかりますし、絶対に落ちないことが求められるサービスでなければ割にあわないでしょう。ライブドアはその辺りのコスト意識は高いように思えます。

そこで、実はライブドアのサービスは落ちまくっていて、単に表面化していないだけではないかという推測を立ててみました。落ちまくっているのに表面化しないというのは一件矛盾していそうで、納得できそうな理由があります。

まず推測材料として「ライブドアのシステム部署はサーバールームのあるビルに同居している(もしくは近くにいる)」ということ。そして「ネットワーク管理はほぼ自社でまかなっていて、24時間常駐している」ということを、元関係者の方からライブドアは強い方向付けでこれを実行していたという話を聞きました。この二つが揃うことで、サーバーにトラブルが起きたときの対処までの時間がかなり短くなります。この二つが揃っている企業は少ないです。(YahooやGoogleは会社規模的に比較対象にしません)

もうひとつの材料としてWebサーバーのトラブルの多くはApacheが固まるのが原因だということをつけたします。Apacheは構成によっては応答ができなくなってしまうことが当然のようになることがあります。ですが、だいたいは再起動すれば直るんです。もう嘘のように正常に走りだすんです。Apache以外にもこのケースは多々当てはまります。WindowsはOS自体がそれですからね。DBについては、公開された構成から推測すると普段からほとんど負荷はかかってなかったんじゃないかと思います。DBはそう簡単には増やせませんしApacheに比べれば落ちる頻度も低いです。またうまくキャッシュをきかせればDBへの問い合わせは激減させることができます。

で、サーバーまでの物理的&時間的距離を短かくしてエンジニアを常駐させておけば落ちたら即座に再起動、どんなに落ちても再起動なんて芸当が可能になります。ライブドアにトラフィックが集中したとき、中の人は必死にApacheを再起動しまくり、ターミナルを開くこともできなければサーバールームへひた走って電源をポチポチっと入れ直すなんてことを繰り返してたんじゃないかと思うわけです。船が沈みそうなときにバケツで水をくみだして耐えている状態といいましょうか。でも、くみだす能力はとても高いので船はまったく沈まないと。

それでもサーバーが落ちればいくら台数があっても相当なお客さんがアクセス不能になっていたのではないかと思われるかもしれません。そこは技術的な解決策があって、あるサーバーが落ちたときに負荷分散装置が落ちたサーバーへトラフィックを振り分けないように構成されていれば、サーバーが頻繁に落ちていることをほとんど誰にも気付かれずにサービスを続けることができます。ほったらかしにすると全部落ちてしまいますが、再起動すればとりあえず正常になります。ひょっとしたら緊急時は5分おきにApacheを自動再起動してたかもしれません。再起動すれば少数のユーザーに影響は出ますがトラフィックは落ちませんから、結果としては正しいときもあります。

以上のことから、サーバーやシステムの構成が想像できないほどに綿密に冗長性をもって作られていたのではなく、経験と人間の力と総合的な判断力で持ちこたえたんじゃないかと推測しました。これが当たっているのであれば中の人は大変ですね。

まあこの運用方法を選んだというのも技術力のうちといえますけどね。ただこれはあくまで推測の範囲内ですし、真相は中の人しか知る術はありません。今後またライブドアによる勉強会があればあのとき本当はどうだったのか聞いてみたいところです :-)

2006-02-27 written by akiyan | 記事 | 固定リンク | コメント (3) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

Just do it 行動しないことで発生するリスク

2006-02-27 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

「最も大きなリスクは、何もしないことだ」ということについて最近よく考える。

世の中には何も新しいことをしようとせずにもっと幸せになりたいと思う人が大勢いるように思う。たとえば与えられた仕事だけを無難にこなし、限られた自由な時間でさえとくにやりたくもないことを繰り返して暇つぶしをしているような生き方だ。何も新しい行動を起こさないなら現状に満足すべきだ。毎日畑を耕し、休養し、季節に数回の祭りを楽しむような「足るを知る」の精神を見習うべきだ。なのに彼らは現状に漠然とした不満を抱き、口を揃えて以下のようなことを言う。

  • 「忙しすぎて時間がない」
  • 「なにもいいことが起きない」
  • 「仕事がつまらない」
  • 「あいつのせいで何も出来ない」
  • 「やりたいことはあるけど失敗しそうでできない」
  • 「怖くてできない」
  • 「会社が給料を上げてくれない」
  • 「いい仕事がないかな」(そして探さない)
  • 「いい人が現れないかな」(そして探さない)
  • 「会社をつくるなら俺を雇ってくれ」(でもとくに何かをしたいわけではない)

彼らに共通して言えることがある。彼らは何も新しいことをしようとしない。変化が向こうからやってくるのを待っているだけだ。他人がなにかしてくれるのをずっと期待しているんだ。

たしかに新しいことをやるにはいろいろな障害が発生するし、失敗の可能性もつきまとう。やろうとしていることが本当に正しいかなんてわからない。

でもやってみなければ一生わからないんだ。やってみてだめなら、次がある。やらないことにあれこれ理屈をつけるようなことは、たいてい取り返しがつくようなことだ。収入が減る?欲しいものが買えなくなる?時間がなくなって好きに遊べなくなる?失敗が恥ずかしい?それがなんだってんだ。新しいことに挑戦することで得られる価値はそんなものでマイナスになったりはしない。失敗したって得るものはある。むしろ失敗したときにしか得られないものもある。「このやり方はだめだった」という経験だ。そしてその失敗で起きた問題を解決しようとした経験だ。これはとても貴重だ。成功だけではぜったいに得られない。

つまりはこういうことだ。新しいことは成功すれば経験と報酬という価値を得られるし、失敗しても貴重な失敗経験という価値を得られる。そう、新しいことをすることは結果がどちらにころんでもおいしいんだ。そして新しいことをしなければ、価値あるものは得られないだろう。価値あるものを得られることと得られないことを比較すれば、行動しないことがいかに将来的にリスクが高いことか理解できると思う。

Just do it. とにかく行動。何もしないよりかはぜったいにマシ。

2006-02-27 written by akiyan | 記事 | 固定リンク | コメント (22) | トラックバック (7) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

私がSkypeを選ぶ5つの「些細な」理由

2006-02-21 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

skype logo

神はディティールに宿る。出展は不明ですが、最近好きな言葉です。

さて、今回のエントリでは私がSkypeをメインIMとして使う理由についてご紹介します。Skypeの特徴として「音質がいい」とか「P2Pだ」とか「SkypeOutやSkypeInがべんり」などと聞きますが、私がSkypeを選ぶ理由はそこではありません。以下の5つがその理由です。

  • エコーキャンセラの性能がすばらしい。
  • 1度に送信できるメッセージ量が長い。
  • オフライン時でもメッセージを送信できる。
  • メッセージを送受信した時刻が表示される。
  • 安定したファイルの送受信ができる。

以下に詳しく述べていきます。

1点目。エコーキャンセラの性能がすばらしいこと。エコーキャンセラというのは、スピーカーから出た音がマイクに入って声がエコーする現象を抑える機構のことです。これがあるおかげでスピーカー+マイクでもエコーが抑えられて快適にインカムフリーで音声通信が可能です。エコーキャンセラが無いとどうなるかというと、声が山びこのように響いたりハウリングを起こしたりして会話すらままならなくなります。この現象を抑えるためにPCでの音声通信はインカム(イヤホン+マイク)を使うのが標準なんですね。ちなみにこのエコーキャンセラ、多くのVoIPアプリには搭載すらされていません。また搭載されていたとしても性能が低いことが多いです。Skypeのエコーキャンセラはかなりの精度でスピーカーから出てマイクに入った音をキャンセルしてくれます。ほんとうに素晴らしいデキです。

ちなみにSkypeで音声通信中はCPU使用率がかなり上がるようですが、暗号化複合化に加えてこのエコーキャンセル機構が負荷をかけてるのではないかと推測しています。また、CPU速度が不十分な状況ではエコーキャンセル機構が自動的に無効になっているような気がします。これも経験則です。

2点目。1度に送信できるメッセージ量が長いこと。これはMSN Messengerに比較しての話ですが、MSN Messengerでちょっとした長文をコピペして送ろうとするとすぐに途切れてしまうんですね。Skypeだとそれがない。少なくとも数キロバイトのデータで途切れてしまったことはありませんでした。MSN Messengerだと数百バイトでも途切れてしまうので、この差は大きいです。

3点目。オフライン時でもメッセージを送信できること。ふとチャットしたいときに相手がオフラインで、メールに書くほどのことでもなく次にオンラインになったときに伝わればそれでいいようなときに便利です。オフラインでも構わずメッセージを送っておくと、次にお互いがオンラインになったときに自動的に再送してくれるんです。これは使いこなすと便利です。言いたいことを忘れてしまうことを避けられますし、お互いにオンラインになった瞬間に送られるのでメールのように会話のタイムラグが発生しません。

4点目。メッセージを送受信した時刻が表示されること。MSN Messengerでは1つ1つの発言に時刻がついていません。数時間ほど席を外して戻ってきたときにメッセージに時刻がついていないと、いつごろ受信したメッセージかわかりません。唯一あるのは「最後に受信した時刻」だけですが、誰かが発言したらリセットされてしまうので心もとないです。

5点目。安定したファイルの送受信ができること。MSN Messengerの場合、相手がWindows Messengerだったりファイアーウォールの深いところにいたりするとファイルの送受信自体が不可能なことがあります。Skypeでそういった経験は殆どありません。

いかがでしたでしょうか。Skypeは日常的に使う機能がちゃんと作り込まれていることがわかると思います。そしてMSN Messengerで感じたちょっとした不満が解消されているのはおそらく偶然では無いでしょう。きっとSkypeの開発チームはIMをヘヴィーに使うユーザーなんだと思います。

グループ音声チャットやビデオなど派手な機能は注目を浴びますが、めったに使いません。こういったディティールにこだわることこそ真にユーザーの心を掴むものだと思います。そう、神はディティールに宿るんです。

2006-02-21 written by akiyan | 記事 | 固定リンク | コメント (0) | トラックバック (2) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

mixiに現れたサイドバーの不快感の本質とは

2006-02-16 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

3回に渡ってmixiに絡めてウェサイトデザインにおける横幅について書かせていただいた。相当量のバックリンクを頂き、じつに多くの意見を効率的に集めることができた。その意見の中で多くみられたのが横幅云々ではなく「mixiニュースうざい」「サイドバーうざい」といった感情表現だった。この不快感はどこからくるのだろう?単に邪魔だとかウザいとかいうのは結果でしかない。

答えはシンプルだ。増えたサイドバーの内容がユーザー個人とは無関係だからだ。

サイドバーサイドバーの内容は上から「広告バナー」「ニュース」「天気」「ミクリィ情報」が並んでいる。どれもユーザーとは無関係な情報だ。ニュースのカテゴリをを興味のあるものに設定したとしても、ユーザー個人との関連性は皆無だ。天気も同様に、便利だけど個人との関連性は無い。さらにユーザーと無関係なだけでなく、もともとあった内容との関連性も無い。もともとあった内容は「自分の顔写真」「マイミクシィ一覧」「所属コミュニティ一覧」「マイミク最新日記」「日記コメント」「所属コミュ最新書き込み」「マイミク最新アルバム」「最近の自分の日記」「自分の紹介文」といったユーザーとの強い関連性があり相互に関連性を持つ情報が全てだった。

ユーザーは今まで自分と関連性のある情報を求めてmixiのホーム画面を開いていた。だからこそ関連性のないサイドバーの情報に対して「うざい」といった強い感情が沸いた。ニュースや天気が見られるのは便利かもしれないが今は求めてないんだ。わざわざ見にくるといった能動的な行動に対するレスポンスなだけに、がっかり感もひとしおだ。

mixiのホーム画面はとてもよくできていて、mixiで関係をもったものの最新情報を一望できる。この一覧性のユーザビリティは非常に高い。だからこそ関連性の無いサイドバーがよけいに異質に映り、結果「うざい」といった極端な声に反映され、サイドバーを消す方法がいくつも編み出されるにまで至った。ほんとうにユーザーにとって必要な情報なら横幅が広がってスクロールが必要になったぐらいではこういったことは起きないだろう。私も横スクロールはうざいと感じつつも、消すことまではしないと思う。今までのエントリで横幅にこだわったのは単に広すぎる固定幅はやめるべきだと言いたかっただけだ。

ユーザビリティの改善案はいくらでもある。サイドバーを完全にコントロールできる機能を提供したり、せめて横スクロールが出ないように画面の下方へ追いやるなどリデザインするなどだ。もっと考えれば他にも方法はあるだろう。

ちなみに最初からうざいと感じないユーザーもすごい勢いで増えている。それは新規ユーザーだ。ホーム画面が最初から「ユーザーの情報」と「ニュース天気もろもろ」が表示される画面であれば違和感は感じないだろう。だがSNSにのめりこんだとき、はたしてそれを求めてやってくるかどうかは微妙だ。mixiのホーム画面でユーザービリティを追求するならやはりユーザーにとって関連性の強い情報があったほうがよいだろう。ニュースを出すとしたら、自分の日記やコミュニティに関連したニュースならいくらかはましかもしれない。

最後に断っておくが、私は今でもmixiが好きだし、mixiニュースそのものの試み自体はすごく面白いと思っている。利益追求をめざしたサービス拡充は企業として当然のことだし、いくら関連性が無いといってもそこまで目くじらをたてるほどのことでもない。今回もmixiを引き合いに出したのはあくまでサイトデザインにおけるユーザビリティを考える上でのきっかけでしかなく、利用者が多く滞在時間も長いサイトということもあるので、そのあたりを割り引いて読み取って頂ければ幸いだ。

2006-02-16 written by akiyan | 記事 | 固定リンク | コメント (7) | トラックバック (7) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

えいご漬けで成長の喜び!

2006-02-14 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

えいご漬け

一昨日からえいご漬けに夢中である。恥ずかしながら私は英会話はさっぱりで、現在諸事情によりサンフランシスコで仕事をしているのだけど、ネイティブな方々とのコミュニケーションがほとんどとれない状態。仕事は日本語しか使わないので必要に迫られることはないんだけど、せっかくアメリカに来たからにはネイティブな方々と意思疎通をとりたい。そこで英語を効率的に学ぶためにちょうどいい時期に発売になったえいご漬けを買ってみたらこれが大正解。なんといってもやってて楽しいのが素晴らしい。今日で3日目なんだけど、能力判定で一気に2ランクアップしてて正直めちゃくちゃ嬉しかった。自分でもたしかに聞き取る能力がアップしてるのが実感できてます。成長の喜びっていいですね。比較的問答が多いスターバックスでも滞りなく注文できるようになったしw

お世辞抜きで「英語をなんとかしたい方」にうってつけ。本体と一緒に買って損はないと思います。2万円くらい英会話教室の料金に比べれば屁でもないですよ。DS本体はゲームもできますから。ぜひ。

英語が苦手な大人のDSトレーニング えいご漬け
英語が苦手な大人のDSトレーニング えいご漬け
このサイトから 1 が購入しました
全体で 3人 がクリック
posted with amazlet on 06.02.14
任天堂 (2006/01/26)
おすすめ度の平均: 4.25
4 敷居は高いかも。
5 期待度満点!!
5 文句なく買い
ニンテンドーDS グラファイトブラック
ニンテンドーDS グラファイトブラック
このサイトから 0 が購入しました
全体で 78人 がクリック
posted with amazlet on 06.02.14
任天堂 (2005/03/24)
売り上げランキング: 39
おすすめ度の平均: 3.89
5 目に優しい色。オススメ。
4 お決まり。
5 久々に「買ってよかった!」と思わせるハード
2006-02-14 written by akiyan | レビュー | 固定リンク | コメント (0) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

オフロードバイクでクラッシュするわたくし - YouTubeを試す

2006-02-13 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

約6年前の私の映像。バイクはKAWASAKI KDX220SR。途中で切れちゃってるのは、カメラマンがあせって録画ボタンを離しちゃったから。あとで砂煙でモワモワ...ってこところまで撮ってほしかった!と言ったらキレられた。死んだかと思った、と。そりゃそうですね。ごめんなさい。

YouTubeを試すために過去コンテンツの掘り出しをしてみたんですけど、意外に便利ですねえ。圧縮形式を気にせず動画アップロードして提供されたHTMLを貼り付けるだけでした。これだけ手軽なら動画コンテンツをどんどん提供できそうです。素晴らしい。

それにしてもアメリカのブロードバンド環境は日本に比べてほんとうにショボいです。なので、もっと環境が改善されればこういった面白いサービスを提供するアメリカのベンチャー企業がどんどん現れると思いました。

2006-02-13 written by akiyan | 記事 | 固定リンク | コメント (0) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

Googleはネット上の全てのコミュニケーションを記録するつもりだ

2006-02-10 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

Chats in Gmail

GmailにGoogle Talkの機能が統合された。今のところ英語画面のみで私のアカウントではまだ発言ログしか見られないが、試してみて非常に驚いた。Google Talk上で発言した瞬間にGmailの画面でログが確認できたのだ。この機能は業務上でもプライベートでも非常に便利だと思った。なぜならコミュニケーション手段を選ぶ上で記録に残るということは重要視されるからだ。電話ではなくメールやグループウェアを使う理由として多くあげられるのが「記録に残るから」というのがある。口頭だと言った言わないの論争や、記憶が曖昧になって忘れてしまうことがあるのでその点が大きなメリットになる。また同時に離れた場所にいる人たちに送信できる点も見逃せない。

ということは音声通信も全て記録できたとしたらどうだろう?やはり便利だ。それも単に記録して再生できるだけではなく音声認識を用いてテキストに起こし、すばやく検索できれば最高だ。膨大なリソースが必要だがGoogleならそれができるだろうし、きっとGoogleはやりたいと思っている。

ここまで考えて気がついた。Googleはネット上の全てのコミュニケーションを記録するつもりだ。コミュニケーション内容を記録し、解析し、コンピューターがキーワードを認識できればそこに関連広告を配信できる。しかも記録されることはユーザーにとっても利益があるから、便利だと思ったユーザーは進んでそれを使う。私は業務上SkypeやMSN MessengerといったIMを多用するのだが、Gmailで記録されてすばやく検索できる事実を知った今、IMをGoogle Talkに統一したいとさえ思ってしまっている。

音声の次にあるコミュニケーションといえば、映像だ。音声認識+画像認識で関連広告の精度は上がるだろう。ユーザーは映像を手軽に記録できれば便利だと思う。音声認識で検索だって容易にできるし、カット割りしたサムネイル表示もあわせれば完璧だ。もちろんどこからでも再生できる。自由に切り取ってメールに貼り付けて送ることだってできるだろう。これはやばい。便利すぎる。

音声や映像は何年先のことになるかは見当はつかないが、Googleはきっとやり遂げるだろう。

2006-02-10 written by akiyan | 記事 | 固定リンク | コメント (0) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

ウェブサイト横幅論 - ほんとうにはみ出す部分が重要じゃななければよいのか

2006-02-10 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

mixiのデザイン変更から学ぶ、ウェブサイトの最小横幅を800px以下にすべき理由を公開してから1日が経過した。リファラーログを使用して言及はほぼ全て目を通させて頂いている。多くの同意を頂けたように感じる。ただ私が最も注目するのはするどい突っ込みだ。特に「重要じゃない領域ははみ出てもよい」という意見だ。前回のエントリでも書いたが、ほんとうにはみ出す部分が重要じゃなければよいのだろうか?

この意見は頷ける点はたくさんある。だが、大事な点がいくつか抜け落ちている。

まず、はみ出た部分にある情報がユーザーにとって重要かどうかは見てみないとわからない点だ。ユーザーは重要かどうかを判断するために不慣れな横スクロールを強制されられる。そして今は重要な情報が無いと判断する。しかし、この先重要な情報がそこに表示されないという保証はどこにあるのだろう?一例を紹介しよう。そのページはあるWebサービスのホーム画面で、デザインは横スクロールが出ない最小幅が870pxほどでブラウザを広げればそれに対応して広がるリキッドデザインだった。リキッドデザインだった点は素晴らしい。しかし、いちばん右端に入会へのナビゲーションが配置されていた点がまずかった。ブラウザサイズを800に縮めてみると、見事にそのナビゲーションは画面から消え去ったのだ。Webサービス提供側にとってもサービスを使いたいユーザーにとっても超重要な入会へのナビゲーション情報が横スクロールした先に隠れてしまったのだ。「はみ出た部分に重要な情報は無いことが多い」と思っているユーザーはナビゲーションを見つけるのにさぞ苦労したことだろう。

次に、はみ出るページを毎回見ることで蓄積されるマイナスエネルギーについてだ。画面から中途半端にはみ出て、中途半端に見える部分があるのは「ちょっと気分が悪い」と思う人は多いだろう。それが1回限りなら許せる。しかし例えばmixiのような滞在時間の長いサイトやリピーターの多いサイトでそういった要素があるのはよくない。塵も積もればなんとやら。強くは思わなくても、毎回なんとなく心の片隅で「ちょっと気分が悪い」と思う。いくら慣れてもこれは完全には消えない。また先に述べたようにいつ重要な情報が現れるかわからないという不安を抱えていなければならない。それに耐えられなくなったとき、ユーザーは嫌々ブラウザの幅を広げたり、ときどきチェックしたり、割り切って諦めたりする。そんな体験をユーザーにさせるべきではないと思う。

以下はリファラーログから得た長文な言及のあるサイト。示唆にあふれているので、ぜひ目を通していただきたい。ウェブサイト制作に関わる方はくれぐれも「800px以下ならなんでもいい」などと短絡的に判断しないようにしてほしい。800px以下というのも現状のデータにのっとったものであり、この問題の本質を見極めてほしい。

2006-02-10 written by akiyan | 記事 | 固定リンク | コメント (0) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

最小横幅800px論への言及への言及 : はみ出た部分は重要じゃなければよいのか

2006-02-09 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

mixiのデザイン変更から学ぶ、ウェブサイトの最小横幅を800px以下にすべき理由に対して内外から多数の反響が寄せられた。鋭い意見が多く「情報は出すところに集まる」を実感できてとても嬉しい。公開して一日も経たないうちにとても素晴らしい言及を頂いたので紹介したい。

どーんとやってみよう : mixiのデザイン変更から学ぶことは横幅ではないより。

まとめる。横スクロールが嫌われるのは使いづらいからだが、そもそもスクロール先が滅多に使われなければ問題ないだろう。サイドバーが嫌われるのは、本来利用するスペースを狭めるからである。「従来使われていた領域」を狭めることなく、横にサイドバーというかたちで新機能を加えたmixiのデザインは、絶賛するほどではないかもしれないが、「きちんと800pxに収める」よりもずっと良いデザインである。

これは正しい見解だと思う。慣れさえすれば「はみでている領域は重要ではない」との認識をもってもらえるし、運が良ければ見てもらえる。現に私もサイトデザインについて話し合うときは重要な領域がはみ出ないことを最低ラインとしている。800pxに収めるのは私個人の理想だ。さらに800px以内に収めることは、収めないことよりも必ずしも優れているとも思わない。はみ出ることでユーザーに抱かせる小さな不快感の蓄積を認識した上で、目標に近づけると思ってデザインしたのなら文句なしだ。mixiもそういう経緯を踏んだ可能性は十分ある。ユーザーのことをよく考えているサービスだから尚更のことだ。ただあのエントリはタイトルや結論を断定調にしてしまったり、mixiのデザインを全て否定するような感じになってしまったのでのでこのような突っ込みは仕方のないことだと思っている。私は少々熱くなってしまったようだ。深く反省。

しかし解せない点もあることも確かだ。mixiが新たに追加したサイドバーは、mixiにとってはかなり重要ではないかという点だ。さらに、mixiに慣れたユーザーにとっては邪魔かもしれないが、mixi内でニュースを見たいユーザーはゼロではないと思う。そのmixiにとって歓迎すべきユーザーに対して横スクロールを強制させたり、ブラウザを広げさせることでコンテンツを提供するのはやはり勿体ないと思う。

何も考えずに800px以内に収めようとするのは愚かだ。どーんとやってみよう : mixiのデザイン変更から学ぶことは横幅ではないを書いた方はそのあたりをよくわかっていらっしゃると思われる。

2006-02-09 written by akiyan | 記事 | 固定リンク | コメント (0) | トラックバック (1) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

mixiのデザイン変更から学ぶ、ウェブサイトの最小横幅を800px以下にすべき理由

2006-02-09 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

mixiのレイアウトが大幅に変更された。右側にサイドバーが出現して、全体の横幅が大きく広がったのだ。全体の横幅は900pxほどだ。このため、私の環境ではブラウザの横スクロールバーが現れるようになってしまった。以下がその様子だ。

私の環境

これはユーザビリティ的にかなりよくない状況だ。横スクロールは可能な限り避けなければならない。なぜなら多くのユーザーは横スクロールすること自体に不慣れだから。

しかし、画面を見てお気づきの方もいると思うが私はWindowsのタスクバーを縦に配置している。このレイアウトはマイノリティな類であろう。このレイアウトのためにブラウザの横幅が縮まっているので「それは例外だ。みんなブラウザの幅は900px以上にしてるよ」という声が聞こえてきそうだ。しかしこれには反論の余地がある。ブラウザでサイドバーサイドバーを活用しているユーザーのことを考えてみたことがあるかい?IEでお気に入りをサイドバーに配置している人は相当数いるだろう。以下がその様子だ。

IEでサイドバーつき

「じゃあ一体どれくらいの人がサイドバーを出しているというんだ?」という声が聞こえてくる。サイドバーだけの問題ではない。ブラウザを全画面表示にせずに、縮めて使っているユーザーもいる。そしてこれについて私は確かなデータを持っている。BROWSIZE.ORGでのアクセス解析の結果だ。それもクライアントのディスプレイ全体の解像度の集計結果ではなく、レンダリングエリアの横幅の集計結果だ。驚くべき事に、およそ25%のユーザーが800px以下でレンダリングしていた。860px以下まで対象を広げればその割合は40%にまでのぼる。私のサイトは800pxで横スクロール無しで表示できるので傾向としてこの結果が出やすいともいえるが、ブラウザの横幅なんてサイトによってそうやすやすと変えるものでもない。ということは、かなりの割合のユーザーのレンダリングエリアの横幅は800px以下だといえる。ポータルサイトの多くが800x600の解像度のディスプレイでも横スクロール無しに閲覧できるのは、単に古いディスプレイを使っている人を救うためではない。ユーザーはどんなに高い解像度のディスプレイでもブラウザの横幅はたいして広げないことを、ポータルサイトは知っているからだと思う。

画面解像度で集計した結果を見ると、今や1024x768px以上のユーザーが99%以上だ。さらに1280x1024px以上のユーザーが25%以上だ。しかしBROWSIZE.ORGの解析ではレンダリングエリアの横幅は25%が800px以下で、40%が860px以下だ。この数字に驚く人も多いだろう。疑惑の念があるかもしれない。だったら、自分で調べてみるといい。程度の差はあれ結果は驚くような数字になるはずだ。ただし、フルスクリーンを強制するようなサイト上の集計でなければの話だが。

私の理想は、横幅800pxのウィンドウでもスクロールバーが現れず、かつブラウザを広げたときにブラウザにあわせて見栄えが広がってくれるようなサイトだ。広げすぎて表示が崩れることもあるだろうが、あまり気にしなくていい。広すぎる幅でブラウジングしているユーザーの割合はとても少なく、ユーザーは普段から自分が使いやすい幅に調整することは進んででもやるからだ。だが、横スクロールバーが出現してそれを「させられる」のは大嫌いなんだ。人はむりやり強制されることは何であっても嫌だからだ。

以上のことから、「横スクロールが発生しない限界を800px以下にすべき」という結論が導き出される。多くのユーザーに利用されるウェブサイトの制作に関わる方々はこのことを深く受け止めて欲しい。私は今回のmixiのデザイン変更にはかなりがっかりした。mixiを使うたびに不格好に途切れたページを見なければならないからだ。このような事はまた起きてほしくないので、私自身のためにもこのことを広く啓蒙していきたいと思っている。

追記その1(2006-02-09):やはりmixiのデザイン変更には強い反発を示すユーザーは多いようだ。mixiの新しいサイドバーを消すGreasemonkey拡張やスタイルシートが同時多発的に公開され始めている。同じ内容のGreasemonkeyが同時多発公開されるなんてことが今までにあっただろうか?単に3カラムが鬱陶しいだけのユーザーもいるだろうが、それもまた見逃せない事実だ。

追記その2(2006-02-10):この話についての続きを書いたのでそちらも併せてご覧頂きたい。

追記その3(2006-02-20):さらに続き。

追記その4(2006-12-01):あなたのサイトのユーザーのレンダリングエリアの横幅を集計できます!

2006-02-09 written by akiyan | 記事 | 固定リンク | コメント (11) | トラックバック (17) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

はてなの技術勉強会動画を見て、RESTを理解しました

2006-02-08 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

株式会社はてなで行われたRESTについての技術勉強会の動画を見て、ようやくRESTを完全に理解しました。たった20分弱の動画で理解できるので、激しくお勧めします。「RSETはなんとなくわかってるけど、きっちり理解してない気がする」人は必見!

今進行中のプロジェクト、RESTフルじゃないなあ...直したくなってきた。

2006-02-08 written by akiyan | 記事 | 固定リンク | コメント (0) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

check*padのリストが増えて困ったら!check*pad All Viewer ブックマークレット

2006-02-07 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

ブックマークレット動作アニメーションデモ

check*padを使い込むうちにToDoリストが多くなって管理が行き届かなくなることがあります。そういうときに便利かもしれないブックマークレット「check*pad All Viewer」を公開しました。ホーム画面でブックマークレットを実行すると全てのリストがページ内に表示されて一望することができます。リストが増えてしまってどこに何があるのかわからなくなっている方や、単純にいっぺんに表示して眺めたい方などにオススメです。

2006-02-07 written by akiyan | 記事 | 固定リンク | コメント (2) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

FreshReaderはローカル型とサーバー型の双方の利点を併せ持つRSSリーダーである

2006-02-04 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

フレッシュリーダー

最近、RSSリーダーをフレッシュリーダーに乗り換えた。非常に使い勝手がよく気に入っている。

高速に動作する上、サーバー型のメリットも得られる

今まではローカルクライアント型のHeadline-Readerを愛用していたんだけど、フレッシュリーダーに乗り換えてからフィードの購読効率が劇的に向上した。Passion For The Futureの橋本さんの言葉を借りると普通のRSSリーダーとして最高のできなのだ。ローカル型のように最新取得もさくさく動き、サーバー型の利点である取りこぼしが無いことやマシンやブラウザを選ばないことが素晴らしい。そしてサーバーがフィードを取得するということは、ナローバンド環境でもメリットがある。最近、遅い回線でネットに繋ぐことがあったのですがフレッシュリーダーにしていてほんとうによかったと思ったことが多々あった。遅い回線で100以上のフィードを常に更新しようと思うと非常に時間がかかるのだけれど、フレッシュリーダーならサーバーの回線資源を使ってくれるのでその問題は無い。

Bloglinesよりもよい点

以前にBloglinesに乗り換えを試みたことがあったんだけど、サーバーの応答が遅かったり最新フィードの取得が不安定だったり、すぐに最新を取得しようとしてもできなかったりして乗り換えを諦めたことがある。ASPに完全に依存しているとそういうことがあったときに自分で何か対処しようとしても何もできないから歯がゆい。サーバーインストール型アプリケーションは導入が少し面倒だけどそれに有り余るメリットが得られる。ただこの面倒さもかなり解消してくれるFTPインストールという無料サービスがあって、これには本当に感心した。サーバー情報を入力するだけであとは自動でアップロードしてくれるのだ。ファイルをダウンロードして解凍してアップロードする手間はわりと面倒なので、これがあることで導入の敷居がかなり下がっていると思う。

すばやく流し読みできる表示方式

最後に、RSSリーダーの記事の表示方式について。多くのRSSリーダーは記事リストを別に用意して1記事づつ読み薦めていく方式か、フィードごとやディレクトリごとにいっぺんに表示してしまう方式のどちらかが採用されていることが多い。Headline-Readerは前者で、私は以前までこの方式が気に入っていた。なぜなら記事1つ1つに対して既読か未読かを自由に(また即座に)コントロールできるからだ。大量に記事を吐くようなフィードに対して途中まで読み進めておくことができる。いっぺんに表示する方式ではそれができないので、乗り換えるのはちょっと抵抗があった。しかしそれはフレッシュリーダーを使って必ずしも効率的でないことに気が付いた。いっぺんに表示されれば、大量の記事を高速に流し読みすることができる。このメリットのおかげで購読にかかる時間が短縮され途中まで読み進めてやめるということが無くなったのだ。Bloglinesを使っていれば気付いただろうが、Bloglinesはそれ以前の問題があったからそこに気がつくまで使えなかった。

他にも企業が導入するメリットなどいろいろ書きたいことはあるが、今回はこれくらいで。

フレッシュリーダー、オススメです。百式の田口さんも絶賛中ですよ。

2006-02-04 written by akiyan | レビュー | 固定リンク | コメント (0) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

IE7 beta2 previewをアンインストール後に、IE6でページが開けなくなってしまったときの対処法

2006-02-03 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

一昨日にリリースされたIE7 beta2 previewをインストールしてすぐにアンインストールを行ったところトラブルに見舞われました。一見正常にアンインストールは完了したのですが、元に戻ったIE6のアドレスバーにURLを打ち込むとデフォルトブラウザの方(例えばFirefox)でページが開くようになってしまっていました。ショートカットを放り込んでも同様の動作でした。

助けを求めてはてな人力検索で質問したところ、同じ症状に悩まされている人を発見することができました。

そして今日はてブ経由のCLON : IE7 beta2 preview をインストールしないで使うにて、普通のアンインストール時ではないけど同じ症状になるということで対処法が掲載されているのを発見しました。さっそく試してみたところ見事解決!とても助かったので、はてなポイントを進呈させていただきたい思いです。具体的な方法は、関係するレジストリを削除することです。紹介されているレジストリテキストを適用することで関係するレジストリを一気に削除することができます。ファイルにしておきましたのでお困りの方は以下からダウンロードしてダブルクリックするなどして適用してください。

IE7beta2uninstall_fix.reg

ちなみに IE7 beta2 preview についてのレビューはサイドフィード株式会社の赤松さんのエントリが詳しいのでぜひ。また、アンインストール方法自体についてはInternet Watchの記事に手順が掲載されています。

2006-02-03 written by akiyan | 記事 | 固定リンク | コメント (4) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

えいご漬け DS版

2006-02-03 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

はてなおやさんが英語が苦手な大人のDSトレーニング えいご漬け買われたもよう

ということでおまいらえいご漬け買え!

ええ買いますとも!私も、発売前から買うつもりでした。今私は一時的にサンフランシスコにいましてあと2ヶ月ちょいは滞在する予定なんですが、こっちで日本のゲームを買うとちょっと高いのですけれど買っちゃいます。

といいたいところですが肝心のDS本体がまだ品切れみたいで、DS Lite の発売も控えてるし、本体ごと買っちゃえていう勢いのある人はもうちょっと待ったほうがいいかも。

年が明けたのにまだ本体が品切れだとは驚きです。私は昨年末にDS本体を買ったのですが、金沢周辺のショップを3件ほど探してやっと見つけました。

それにしてもDSのゲームは面白いです。今までにない新しい体験をさせてくれるので感心しまくりです。友人とDSについて話していて、このぶんでは、レボリューションもすごいことになるんじゃないか?と言っていました。そんな予感はしますね。楽しみです。

2006-02-03 written by akiyan | 日記 | 固定リンク | コメント (2) | トラックバック (0) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

言い訳をしないこと

2006-02-02 | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

Life is beautiful : リーダーシップについて思い出したことより。

人間、「何としてでも結果を残す、言い訳は絶対しない」という意気込みを持って仕事をすると、ものすごく強くなれる。

激しく同意。

「あいつのせいだ」と思うとそこで思考が停止してしまいます。意識して言い訳をしないようにすると、とても建設的になれるんです。自分が影響を及ぼせなかった事象に対しても「次から自分がどう動いていれば影響を与えられるか」というふうな考えが自然と出てきます。人のことも自分のこととして考えるようにするということかもしれません。

私がこのことに気付いたのはごく最近のことなんですが、気付いてから思考や行動のスピードが劇的に加速しました。影響を与えようとしてときに押しつけがましくなってしまって後悔することもありますが、それを反省する速度も爆速になりました。あれこれ言い訳になる原因を探そうとしてうだうだ悩むことがなくなったんですね。そしてまったく影響を与えることが出来ない領域で問題が起こったときは怒りを覚えるようになりました。言い訳をしないことのメリットに気付いてからの自分の考え方の変化にすごく驚きましたね。この変化はとてもよいことだったと思っています。

ビルゲイツがいたとすれば、こんな感じになる。といったくだりも、私が同じ立場にいたら同じことを言うと思います。

騙されたと思って、意地でも言い訳をしないように意識してみることをオススメします。

2006-02-02 written by akiyan | 記事 | 固定リンク | コメント (1) | トラックバック (1) | このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

« 2006年1月 | 2006年3月 »