Hatena::ブログ(Diary)

public static void main

誰かが困って検索したときに助けになる話題を書いていければと思っています。

2009-04-09

[][][]高橋メソッドのような表現の見る側にとっての心地よさ

最近、高橋メソッドを使ったプレゼンをする機会があったのですが、そのときにその発表をいたく気に入ってくれた方がいました。

その人いわく、「2chニコニコ動画みたいで見ててワクワク感があった。」とのことでした。おそらく2chというのは2chまとめサイトのことだと思います。

その言葉を聞くまでそんな風に考えたことはなかったのですが、考えてみると結構腑に落ちます。

高橋メソッドの特徴をあげると、

  • 字がでかい
  • 表現が簡潔
  • 説明の順番が明示化される→ストーリーがある
  • たまに大きくなったり色が変わったりして強調

などがあげられますが、2chまとめやニコニコ動画と結構重なっているところがあります。

こういう表現をすると視聴者としては集中してみることができるし、メリハリがあって面白いのかもしれません。

去年、いろいろな意味で話題になった「あたし彼女」も簡潔な表現の繰り返しですが、高橋メソッド風に見てみると結構楽しんで見ることができました。


他に類似のものがないかと思いましたが、短文といえばTwitterのようなミニブログがあります。その周辺サービスのふぁぼったーTwitter名言がこの特徴に近い気がします。どちらも見ていて非常に飽きずに見ることができます*1

まあそんなわけで、テキストを使うようなUIを考えるときにこういう特徴を取り入れていくとワクワク感のあるものに仕上がるかもしれないですね。

*1:内容が面白いということもあるかもしれませんが

2009-01-14

[][]個人で運用するWebサービスの限界を考える

個人が作成したWebサービスの数はここ数年で爆発的に増えています。

サーバ自体の導入コストも低下してきており、レンタルサーバでもPHPのようなスクリプト言語が使えるものが珍しくなくなり、Ruby on Railsのような開発速度を向上させるフレームワークも登場してきて、今後も個人が運用するWebサービスは増加をしていくでしょう。


個人Webサービスの寿命

今回考えたいのは、そういった個人で運用するWebサービスの終了するときについてです。

Webサービスは作ってからが本当のスタートで、開発者は開発にかかったコスト以上に運用するために時間的・金銭的・精神的にコストを負担していくことになります。なので、自分の払うコストに見合わないと思ったらサービスの終了を考えるのは当然だと思います。

つまり作った人一人がやる気をなくしてしまえばどんなにいいサービスでも一瞬で消えてしまうということです。

最近上場したGREEですが、当初個人で運営していたときに「管理人さんが死んだらサービスはどうなるんですか?困ります!」的なコメントをユーザからいただいたと言う話を聞いたことがあります。極端な話になりますが、作った個人が事故や病気で亡くなったりしてしまってもそのサービスは終了してしまいます。

開発者である個人が自分のサービスへ関われなくなったそのときがWebサービスの寿命となっていしまうということ。これが個人で運用するWebサービスの限界なのではないかと考えます。


止めるのは作った人の自由?

個人で作ったものなのだから好きなときに止めてもよいではないかという意見もあると思います。

ちょっとした検索サイトやジェネレータやマッシュアップのようなサービスであれば人気があれば代替となる似たサービスはあると思いますので、それもありだと思います。そもそも、そういう系のサービスだとサーバさえ確保できればメンテナンスはほとんどいらない場合もありますのでただ放置しておくという選択肢もあるかもしれません。

ただ、CGM的な要素やコミュニティ要素を持ったサービスにおいては、それまでサービス内でユーザが作ったものやそのコミュニティは立派な財産だと思うので、作った人の一存で終了させてしまう前に、どうにか延命の方法を考えて欲しいと個人的には思います。

ひろゆきが2ちゃんねるを譲渡したって話も今回書いたようなことを考えて決定したのかもしれないなと思ったり。とはいえ、2ちゃんねるの場合は複数人が運用に関わっているのでどうとでもなりそうですが。

たくさんのユーザがいるサービスを止めてしまうと、ユーザはサービスを使えなくなると言う不利益をこうむりますし、開発者としてもこれまで成長させるのにかけたコストがもったいないと思います。


サービスを延命する

個人が運用を止めようと思ったときにサービスを延命するために選択可能な方法で、私がぱっと思いついたものは3つあります。

一つ目は、先ほど話したGREEのように起業すること。ビジネスとして成立しうるサービスまで成長させられるのであればこの選択肢もありだと思います。でもそこまで収益性の見込めるサービスは大量には生まれてこないし、起業することを面倒に思う人も少なくないでしょう。

二つ目は、カヤックでは作ったサービスの売却ページを作ったりしていますが、こんな感じでサービスの売却を考えるのも一つの手だと思います。数年前だとライブドアなどに買収されるのがサービス開発者としての一つのゴールのように思っていましたが、現在は個人が作ったものを買ってくれる企業はあまり見かけなくなった気がしますね。

三つ目は、誰かにサービスの管理を譲ること。熱心なユーザであればボランティアでもいいのでサービスを手伝いたいと思ってくれるかもしれません。

どの方法でも言えることは、一人でやることには限界があるので誰か他の人を巻き込もうとすることがサービスの寿命を伸ばすことにつながるということです。

OSSの隆盛により、ソースコードのレベルでは他の人とコストを分かち合うことが一般的になってきましたが、サービスのレベルで他の人とコストを分かち合うことが今後一般的に見られるのかどうかが気になるところです。

2008-10-06

[]プログラマの実力を測る3つの指標

「こいつ・・・できる!」と思わせるプログラマにたまに会うのですが、その実力の評価の指標が必ずしも一つではないなー、というのを常々思っていました。この評価指標を言語化できないかと考えていましたが、はてなインターンに行ってたときにいろいろなタイプのプログラマに会って、この指標で評価可能なのではないかと思いついたものを3つ書いてみます。

私の観測範囲内から考えたことなので、「こんな指標もあるよ」という意見がありましたら是非是非ご教示ください。

ちなみに指標と言っても、数値化可能なものではなくて、この人はなんとなくこの指標の能力が高そうだなーと考えるのに使うためのものです。



指標1. アルゴリズム思考能力

数式からプログラムに落とし込む能力や最適なアルゴリズムを考えることができるかという指標。ちゃんとコンピュータサイエンスを学んできた人が強い指標になります。

この能力の高度な活用が求められる場面は実は少ないのではないかというのが私の感覚ですが、必要になった時に勉強して一朝一夕で身に付けられるものではないので、この指標が高い人は貴重だと思います。

ただ、この指標の評価が高い人がアルゴリズムをプログラムに落とし込むときに綺麗なコーディングが行えるかは別問題で、研究機関の人が書いたコードを読むと結構汚い書き方をしていることもままあります。*1



指標2. やりたいことを表現できる能力

やりたいことに対して、どんな書き方をするか、どんなライブラリを使うかといったときの自分なりのベストプラクティスをどれだけ持っているかという指標。

いわゆるtipsとして公開できる話が多いですが、Webにある玉石混交の中から適切なものを選択するのは容易ではありません。同じググるにしても、具体的に何をすればいいかわかっている人とそうでない人では効率に雲泥の差があります。

「〜をやりたいと思ってるんですけど」といった大抵の質問に対して即答できる人がこの指標が高い人です。この指標が高い人は、個人としての生産性が非常に高いことも特徴と言えるかもしれません。

指標1と同様に、この指標が高い人が必ずしも綺麗なコーディングができるわけではありません。



指標3. クールな設計をする能力

いわゆるほかの人から見てもわかりやすく拡張しやすいクラス設計などを行うことができるかという指標。言語を問わないものもあれば、その言語特有の設計方法があると思います。

漫然とコーディングを行っていても身につかない能力で、いい実装のソースコードリーディングや実践を通じて鍛えるものだと思います。

ブログの記事などでは書ききれないことが多いので、その人のソースコードを読んだりペアプロする機会がないとこの指標の正しい評価は難しいかもしれません。

アルゴリズムなどの高度な知識を持っているわけではありませんが、個人的には一緒に仕事をしたい人の指標です。*2



指標2に関してはいろいろな仕事をこなしていった結果能力が高まるかも知れませんが、指標1、3は意識的に勉強しないと鍛えるのは難しいです。

*1:以前アルゴリズムを研究にしている人は「速度の検証だけなので動けばいいという考え方で書いている」と言っていました。

*2:こういう人とペアプロをしたりするとものすごく参考になります。

2008-07-03

[][]モバゲーのPC対応から思うこと

モバゲータウン、PCに進出--iPhoneにも対応 - CNET Japan

以前、周りのメンバー何人かとご飯を食べに行ったときに、モバイルの今後はどうなるかという話題になって、その中で「モバイルが主でPCが従となる時代が来る可能性もあるのでは」という発言がありました。

今回PC向けに公開したのは、単純にユーザの層を広げようというより、そういう方向を目指しての意味合いが強いのかもしれません。

携帯電話からの利用でPCと比べて問題となるのは、作曲したり絵を描いたりといったモノを制作することで、この欠点を補うための仕組みとして今回のPC展開が機能していけばまた違った展開が見えるのではないかと思います。

現代だと貧困にあえいでいる人でも携帯電話の利用料金だけはきっちり払っているというパターンは多いですが、だからといって携帯電話しか持っていない人ばかりではなく、大抵は年齢が高くなっていくにつれて会社なり大学なりでPCを使わざるを得なくなります。

インターネットを利用するなかの主は「読む」ことで、そういった用途や簡単な情報の発信には携帯電話を、専門的な仕事をするときにはPCを、という切り替えのスムーズなサービスを考えていくことが今後重要になってくるかもしれません。


デザインは携帯電話の画面イメージそのものなことについて、はてブのコメントを読むと賛否両論ありますが、開発中にPCから確認する用のページを今は流用しているのかな?

今はクローズドベータで利用できないので、利用できるユーザの使ってみての感想を聞いてみたいですね。

2008-06-28

[]主観が入るところがSBMの面白いところだよね。

はてなダイアリー」を読んで、エントリの趣旨とはズレてるけど思ったこと。


「これはひどい」とかがつくのは比較的ニュースサイトのようなところが多いので余り意識していなかったのですが、個人のブログとかでつくと結構ショックかもしれないなあと思います。また、ネガコメだと参考にもできますが、タグだけだとどうしようもないですよね。


個人的には主観の入ったタグはなるべく入れたくないので、「これはひどい」はもちろん「これはすごい」や「参考になる」*1みたいなタグは使っていないのですが、人気のエントリーなどに載っている記事の内容が一目でわかるという意味ではお世話になっています。

でも、「これはすごい」とかついてる記事もモノによってはぜんぜんすごくない記事もあるわけで、SBMの本来の役割であるフォークソノミー的な意味では役に立ってないんですよね。


もともとWebは圧倒的多数のROMによって成り立っているのですが、記事やコメントを書くコストに比べると、制限がある分ブクマのコストは低くなりますので、SBMはそういったROMを浮上させたところがすごいところだと思っています。

制限のある手段なので、言葉から余分な要素を取り除く必要があります。そのため、感情的な言葉なら歯に絹を着せぬものになってしまいます。感情的な言葉はいくつも思いつくのですが、SBMだと性質上既存のタグの枠に当てはめる傾向があるので、ある程度画一的な表現がなされています。*2

感情的タグやコメントが集まった結果、そのブクマの集合が何か一つの意思を持っているように見えることもあります。


こういう感情的なタギングは人間にしかできないわけで、そういうところが面白いなあと思っています。機械が自動でタグ付けするような研究はいくつかあるのですが*3、主観的なタグをつけることはほぼ不可能です。この機械にできないことを、タグというシンプルな表現でたくさんの人が集まってやっているのです。

一部の人しかこういう主観的なタグは使ってないかもしれないけど、読み手の感情の集合を定量的に見ることができる手段は本や新聞のようなメディアへの反応としては存在しなかったものだと思うので、書き手としてどう受け取るべきかは思案するべきところになりそうです。

*1:ブクマしてる時点で参考になってるんじゃないのかな?

*2:そういう意味で最初ニコニコ動画のタグの付け方を見て驚いた

*3:検索エンジンもある種これに分類してもいいかも

2008-06-04

[][]アップロードされたアイコンのリサイズ方法(はてダとTwitterを例に)

ユーザのアイコン画像のアップロード部分を作っているのですが、リサイズの方法としてどの方法が無難なのか悩んでいました。

こちらが想定するサイズをユーザに強制することは難しいので、多くの場合はアップロード後にこちらが画像のサイズを調整することになります。縦横比は画像によってまちまちなので、サービスによってどう処理するかは異なってきます。

ユーザの視点から考えるとサービス側に空気を読んでもらってリサイズ処理をして欲しいはずです。

以下の200×100の画像を使って、どんな方法があるのか調べてみました。

f:id:Kishi:20080604231339j:image



正方形にリサイズする方法

私が最初に考えていた方法です。

どんなサイズの画像が上がってきても64×64ピクセルのにリサイズします。

f:id:Kishi:20080604232022j:image

この方法の問題点は、縦横比が4:3の画像などでこの処理をすると、無理やり正方形の形にしてしまうので横や縦に伸びた画像になってしまうことです。



縦横比を崩さずリサイズする方法

はてなダイアリーのプロフィール画像がこの方法を取っています。

手順としては、

  1. アップロードされた画像の幅と高さを見て、長いほうを選択
  2. 選択した方の長さを基準に、指定した長さ(はてダの場合は64px)にリサイズする

といった感じでしょうか。

例の画像の場合だと、幅が200pxで高さが100pxなので、幅の200pxを選択。これを基準に64pxするとリサイズ後の高さは32pxになります。

f:id:Kishi:20080604231050g:image

幅と高さが64px以下になるので良い方法だと思いますが、問題点としては大きさがまちまちになってしまうところです。デザインによってはレイアウトが崩れるかもしれないので、案件次第ですね。



リサイズして正方形に切り抜く方法

Twitterのアイコンの方法です。

手順としては、

  1. アップロードされた画像の幅と高さを見て、短いほうを選択
  2. 選択した方の長さを基準に、指定した長さ(Twitterのタイムラインの場合は48px)にリサイズする
  3. リサイズされた画像の中央から指定した長さの正方形になるように切り抜く

といった感じでしょうか。

f:id:Kishi:20080604231727j:image

問題点としては画像として重要な部分を切り捨ててしまう可能性があることですが、写真や壁紙などがアップロードされることを想定すると上下(左右)を少し切り抜くだけならば画像の重要なところが見えなくなるということあまりないと思いますので、この方法が正方形にするのに適しているのではないでしょうか。

2008-05-19

[][]放送において禁止されている手法の動画共有サービスにおける対応はどうするんだろう

ニコニコ動画の色数の多いとある動画で画質が落ちて目が痛くなるような状態のものを見かけ、コメントは「目が!目がああああああ!」とか書いてあったのですが、それを見ていて、放送法とかで禁止されているような手法を使った動画が出てきたときにどう対処していくのかな?と思いました。

ポケモンショックとか、効果はいまだ立証されていませんがサブリミナル効果とかこの辺は放送業界では禁止されています。

アマチュアが作る時に考慮しているとは思えないのですが、これだけ動画共有サービスが普及していても特に問題が出ていないということは、それほど悩む必要がない問題なのですかね。

でも、一度問題が起きると法律で動画をアップロード時に明滅の激しいところなどを抑えるフィルタをかけるのが必須になったりしそう。そのときに行き過ぎて「DVD-BOX『爆走兄弟レッツ&ゴー』がクソ仕様すぎて購入者の怒り爆発!! : 【2ch】ニュー速クオリティ」みたいなことになったりしないといいですね。

2008-05-07

[][][]中学生とニコニコ動画の話をして作る姿勢について思ったこと

中学生と話をしていたらニコニコ動画の話題になったのでメモ。

聞いた話

  • クラスの半数以上が利用
  • 発端はクラスの中のインターネットに詳しい人
  • 周りも含めて自分で動画を作って投稿したいと思っている

面白い動画の投稿者は英雄のような扱いでした。

自分も投稿してみたいと言っていたのですが、好きな動画が「毒キノコを全裸で採って食ってみた」とか「ハイポーション作ってみた。」とのことでしたので、無茶をしないことを祈ります。


思ったこと

動画を作成したいというベクトルが技術ではなく、何を作るかということに向いていることが個人的にはいいなあと思いました。

私の中では、動画を作成したい ≒ Final CutやAfterEffectsのような編集ソフトの使い方を覚え、効果的なエフェクトの使い方を発見し、撮影の構図や3Dモデリングや高品質で圧縮する術を勉強すること、という認識でしたが、別にそこまで詳しくなりたいと思っている人はほとんどいなくて、思いついたものを作品として形にしてみたいので手段には特にこだわりがないのではないかと思います。

プログラミングだと、どちらかといえば技術よりの人が多いように思います。勉強をするにしても、何か作りたいものがあって始めるのではなく、勉強のための勉強になっているところがあります。動画に比べると、プログラミングで、何ができるのか・何がしたいのか、ということがわかりにくいことが一因かもしれません。

この辺の意識の差が生まれたのが、動画を共有してコメントができるコミュニティがあるからであるとすると、Google App EngineやOpenSocialのような環境をうまく利用して、プログラミングの分野における作品を公開し評価してもらえるコミュニティが生まれると、もっと多くの人がプログラミングに興味を持ってくれるようになるのではないかと思いました。

2008-04-14

[]Web上の情報を読むことと本を読むこと

2週間ほど放置していたRSSを消化してる途中に、2週間の内に、一度も自分が興味がある話題に触れていないものをいくつか登録を削除しました。

登録したときには面白いと思って登録したと思うのですが、時間が立つにつれて書き手の興味が移ったり、1つのエントリがたまたま自分の興味に合っていただけで他のエントリはあまり関心がないものだったり、という理由かもしれません。

そんな作業をしているときに、本とWeb上の情報への接し方の対応が思い浮かんだので。つらつら書いてみます。

表にするとこんな感じ。

RSS
本屋で本を買うRSSを登録する
図書館で借りる検索エンジンで検索
ベストセラーコーナーを利用するSBMの人気エントリを利用する

本屋で本を買う⇔RSSを登録する

RSSを登録するという作業が、店頭で売っている本を自分の判断で買うということに似ているのではないかと考えます。RSSの場合は、すべてのエントリを読むには時間がかかりすぎるので、一部を見て自分が判断するしかありません。本も、店頭で目次や紹介文などから内容を判断します。

本を買うと、読んでみると内容がはずれであったり、場所をとったりするように、RSS Readerに登録するということは、ユーザにとって大なり小なりのコストとなります。


図書館で借りる⇔検索エンジンで検索

自分で保持するには値段や場所を含めたコストが高いと思うけど、たまに必要になる情報を得るための方法という意味での対応です。

大量の情報にアクセスしやすく、古い情報も探せるところが似ています。


ベストセラーコーナーを利用する⇔SBMの人気エントリを利用する

話題の本は店頭でも目立つところにおいてあり、雑誌などで評価を知ることができます。Amazonを利用すれば、もっと手軽にそれらの情報を知ることができます。

SBMの人気エントリなどを利用することは、このように手軽に人気のエントリやそれに対する評価を知ることができます。


結びに

ということで、この辺が一般的にRSS Readerが普及しなかった理由の説明になるんじゃないかなあと思います。

本屋に行って自分の目で本を選ぶことは非常に楽しいのですが、多数派ではない気がします。楽しみ方はそれぞれなので、本を買う・RSSを購読する、といったスタイルを必ずしも強要しなくても、本人が楽しめる方法で情報を得ることができればよいのではないかと思いました。

2008-02-21

[]プログラミングに熱中したきっかけ

初心者向け言語は何かという話題が、今月になってからいろいろ議論されていますが、私が興味があるのは、そういう議論をされている方々のプログラミングに熱中するようになったきっかけです。

エンジニアやコンピュータサイエンス系の大学に通っている人の場合、仕事・学業の必要に迫られて、というパターンが多いのではないかと思います。そのような状況で、かつ周りに相談できる人がいる場合が、一番学習効率がよいと思います*1

んで、今回考えたいのは、そういうある意味恵まれた環境にいる人ではなく、コンピュータと縁遠い学部にいる大学生や、ほとんどPC触ったことのない高校生のような人たちが、どうやってプログラミングに熱中するようになるかです。

初心者向け言語が云々と議論するよりは、興味を持ち始めたきっかけの事例を集めて、初心者がプログラミングを好きになるためのノウハウが出てくれば、よほど有益なのではないかと思います。

ということで、以下自分のプログラミングにどのように熱中していったかの話です。



原点:RPGツクール

言語を使う前の、プログラミングに対する私の原点はコンシューマ版のRPGツクールです。

初めてこのゲームに触れたのは小学校に入ったころのことと思いますが、自分でRPGが作れるゲームということで衝撃を受けました。(参考:wikipedia:RPGツクール

初期の頃のRPGツクールは、構造化プログラミングの構成要素である順次・反復・分岐の反復を行うことができず、変数も存在しませんでした*2

制限される面白さ

普通のプログラマだったら、「こんなのやってられるか!」となるかもしれないのですが、プログラミングのプの字も知らなかった身としては、ただ自分で書いたとおりにモノが動くということが自体が楽しかったので、まったく気になりませんでした。

ある程度プレイ慣れしてくると、やはり物足りなくなってきます。しかし、当時は限られた機能で、いかにして難しい表現を実現するかが楽しみとなっていました。拡張性があるに越したことはないのですが、技術的制限があるほうが、やり込める要素になり、小学生なりに工夫を凝らしてものを作るよい機会となりました。

また、シリーズの最新作が出るたびに、変数や反復のような新しい制御構造が加わっていき、そのたびに悩みましたが、こういう段階的に覚えることが増えるのも、無理なく学習できたように思います。

参考


最初の言語:JavaScript

JavaScriptに初めて触れたのは、高校生の頃で、HTMLを勉強していく途中で知りました。

サーバサイドプログラミングの知識はなく、CGIを動かすことのできるサーバもなかったので、何の準備もしなくてもプログラムが動くというのは、始めるきっかけとしては十分でした。

その頃は、当然Ajaxという言葉は存在せず、「現在0時35分です」とか「2回目の訪問ありがとうございます^^」のような腐った用途に使われるものとしてしかJavaScriptは認知されていませんでした。そのため、Webに転がっている情報もほとんどはそれに類するものでした。

JavaScriptでゲーム

ある人が、Cookieを使うことで、クライアントサイドだけでゲームを作っているのを見かけ、それに感動して、自分でもJavaScriptを使ってゲームを作り始めましたが、以下の3点に悩まされました。

  • クロスブラウザの問題 ・・・ 当時、こちらはMac+ネスケの環境で、Win+IEの知り合いに見せたところエラーが発生するも、原因がわからず悩んだ。サンプルも環境依存のものが多かった
  • 言語の柔軟性の高さ ・・・ 同じことをするのに2つのサンプルで書き方が異なり、どちらを参考にすべきか悩んだ
  • リファレンスやチュートリアルがない ・・・ 今以上に不足しており、適当に書いてもそれなりに動いてしまうのでひどいスパゲッティコードになっていた

このような問題もありましたが、HTMLと一緒に使うことで、グラフィカルなプログラミングを行うことができることは作っている側としては非常に楽しかったです。amachang小飼弾さんが言うJavaScriptが初心者向けであるという利点を身をもって経験しました。

プログラミングをもっと勉強したいと思い始めたのはこのあたりからです。


その後

C言語の本を買って勉強を始め、順を追って勉強することが出来たので、プログラミングの基礎がわかってきました。進むべき指針を示してくれるものの重要性がよく理解できました。しかしながら、私の中でのプログラムというのはGUIであり、ターミナルに表示される「Hello World!」がどうつながるのかわからず、あまり面白みを感じませんでした。

大学に入り、Visual Studioを使えばGUIプログラミングができることを知り、C++と一緒にWin32 APIの勉強をしたり、サーバサイドプログラミングの勉強を始めたりして今に至ります。


終わりに

以上から私がプログラミングに熱中した重要な要素をまとめると、

  • 制限というやりこみ要素
  • 作ったものが簡単に動かせて結果が視覚的にもわかりやすい
  • 教本あるいは教師の存在

の3つです。

「ゲームを作りたい」というベクトルがプログラミングという手段とマッチしていたというのも大きいと思うので、何か目標があることも大切だと思います。

自発的にプログラミングを始めたほかの人の話も是非聞いてみたいですね。

*1: もっとも本人がその過程でプログラミングに魅力を感じられるかどうかで学習に対するモチベーションは変わってきますが

*2: 確か、4か5から導入されたはず