Twitterが140文字であることの利点

新サーバ移転が上手くいっているかどうか、確認のテスト投稿。

Twitterの投稿は140文字に制限されている。普通、この手のサービスは、いくらでも長い文章を投稿できることが優位とされる。しかし、Twitterは140文字に制限し、そして成功した。

そもそも、140文字に制限したのは、SMSの制限は160文字で20文字はユーザー名に割り当てる予定だったから、らしい。

この制限は、結果として情報を扱いやすい仕組みを生み出したのではないか、と考えている。

例えば、どんなユーザーでも1000回発言すれば1回はいいことを書く、と仮定する。これがブログ記事の場合、前後の文脈に「いいこと」が挟まれる。この前後の文脈に誤りや検討不足、賛同できない点があると、「いいこと」を他の人に宣伝しようとは思えない。そこをQuoteするための仕組みとしてtumblrなどがある。

twitterの場合、140文字に制限されることによって、前後の文脈を入れ込むことも制限される。結果的に「いいこと」が汚染されずに残る。それがRTされやすい仕組みになっているのではないか。

同様にミスリーディングをさせるような行為も可能である。前後の文脈抜きに刺激的で誤解するような文面をRTすることでtweetしたユーザーの意図とは違う意図で拡散されていく。

しかし、twitterのように情報に今までよりも制限を加えて上手くいっているサービスに気づいた事がないので、そのような共通した特徴を他のサービスで見る事ができない。残念だ。

node.jsを3時間ほど触ってみた感想

nvmやnpmまわりの環境整備、nodeのバージョン管理とパッケージ管理は表示が分かりやすい。

node.jsとその他プラグインを堪能。

  • socket.io
  • express
  • connect-assets
  • coffee-script
  • haml-coffee
  • js2coffee

最初は素直なJavascriptで試していたが、coffee scriptでないと書きたくない気持ちに襲われてcoffee-script入れる。

app.jsにアプリケーションの記述を行う。起動するときは

node app.js

のような形。coffeeでapp.jsを記述するためには最初は

coffee -wc app.coffee

というコマンドを別のターミナルで起動して自動変換していたが、他のテンプレートを調べると、server.jsというファイルを用意して

require("coffee-script");
require("./app");

というコードを書いておくと、app.coffeeのままでも実行できるということが分かって楽になった。
jsからcoffeeに変換するにはjs2coffeeを使う。

connect-assetsを使うと、assets/js/app.coffeeやassets/css/app.stylなど、assetsディレクトリに分けて呼び出すことが出来る。htmlの中にインラインでjsやcssを書きたくない人向け。

socket.ioは面白い。node.jsのEventEmitterの仕組みでemitで発火してonで受信する。その流れがサーバ側とクライアント側で同じように書くことができる。サーバでもemit,onだし、クライアントでもemit,on。このあたりが面白い。あとIE8でも動くし、公式にはIE5.5でも対応すると書かれている。すごい。

vim上で書く場合は、jadeやcoffeeのための環境づくりをしておかないと、タブキーを押したときの挙動でスペース2個のはずがTABが出てきて、毎回修正しながらの作業で萎えてくる。

全体の感想

node.jsというか、socket.ioそのものが目当てで試してみた。だからかもしれないが、html生成部分やjs,css生成部分、routing周り、そこまで使う必要はなく、socket.ioが使いたければ、その部分だけ使うのが正解で、それ以外の部分は他のフレームワークに仕事をさせた方がいいよね、と。node.jsだけで済むようなライトウェイトなサイト、もしくは自分だけ身内だけで使う用途なら割と便利に使えるのではないか。

なので必要な部分をガッとapp.jsに書いておいて、他のフレームワークからsocket.io通じて呼び出す形になるのかな、と。例えばメッセージの部分だけ切り出してapi化して使えるようにしたpusherというサービスが存在しているが、そのような形を自分で作る、と。

この呼び出し方は、クライアント側jsをnode.js側に置くのか別フレームワーク上に置くのが正解か、分からない。別フレームワーク上に置いてしまうと呼び出し部分と処理部分が1つのパッケージにならないので、それはそれで不安かな、と。

既存のセッションとどうやって絡ませるのがいいのか、は分からない。

もしかしたら、ブラウザの送信をnode.jsで受けずに別フレームワークで受ける、

ブラウザ→送信→(別フレームワーク→node.js)→受信→ブラウザ

という形が良いのかもしれない。