2ch vs Twitter 論ですよ。
ネット上に人の集まる場を作るという目的は同じで、
それに対する方法論が違うよな、みたいなことを書きます。
まずこないだ気付いたのだけど、
2chって話題別に板が分かれていて、話題別にスレが分かれているのだけど、
必ずしもそうじゃないのかなあと。
「○○板」があったとして、それは「○○について語る板」なのかというと、
「○○好きな人が集まって雑談する板」だったりするように見えたりします。
ということは、「○○板」というのは
「自分は○○が好きだから○○板に行ってみよう」という行動を起こさせるための
目印だと考えた方がいいのではないか。
2chは「自分は○○が好き」というのがあれば○○板に行くことができ、
読むこともできるし、書くこともできると。
「「2chに書き込んだことがある」はたった15.7%:アルファルファモザイク」
というのもあって、読むだけ人の数が全然多いのですが、
後で書くTwitterと違って、読むだけということができる構造なんですね。
あと、これは関係あるかどうかわかんないんですけど、
今の2chっていつも何かしら書き込み規制していて、
有料会員になるとかしないと、
プロバイダーによっては書けなかったりします。
そこを制限することで、気の効いた書き込みだけがされるようになって、
読むだけでも楽めるようになるのかな、って思ったけど、正直よくわかりません。
一方Twitterは自分でユーザーをフォローして、
自分だけのタイムラインを作る仕組みです。
はてなブックマークの「お気に入り」も同じ。
これのいいところは、
タイムラインができてくれば「どこに行こうかな」と考える必要はないことです。
欠点はタイムラインを作らなければならないこと。
例えば「自分は○○が好き」というのがあったとして、
同じく○○が好きなユーザーをフォローするとか、ちょっと大変だし、
使い始めたばっかりだと、そういう発想すらわかりにくいような気もする。
Twitterはアカウントを取って使わなくなっちゃった人は多いと思うけど、
読むだけの人は少ないんじゃないかな、と予想しています。
どうなんだろ。ROM用にアカウント取ったりすることもあるんだろうか。
新月は設計段階では「○○好きな人が集まって雑談する板」
のようなものを作るのを拒否していて、
話題だけでスレッドが分かれるべきである、みたいに考えていました。
はてなブックマークとかは、ホットエントリーとかをタイムラインと考えると、
最初は「自分と同じ嗜好のはてなユーザーの集まる場」だったのが、
ユーザーが増えるに従って次第にそうではなくなったんじゃないかなあとか、
各自がタイムラインを構築しやすくするにはどうすればいいのかなあとか。
これのいいとこ取りはできないかなあ。
- 「自分は○○が好き」から
「○○好きな人が集まって雑談する場」に辿りつくことができる。
- このページを見れば全部追えるタイムライン。
- 何を書いてもよい「チラシの裏」性。
場に辿りつくことについては、2chはもともとできるけど、
Twitterだとどうなんだろう。
検索機能で○○を検索すればいいのかな。
これについては、予め運営側でカテゴリーを決めちゃって、
書き込みをそれに登録する、みたいな態勢にしないと駄目なんじゃないかな。
難しい。
タイムラインについてはTwitterにはもともとあるし、
2chは専用ブラウザを使えばたぶん目的は果たせる。
「チラシの裏」性はTwitterならいいけど、
2chをベースに考えるとどうなるんだろう。
Twitterを目指すか、2chを目指すかのどちらかしかなくて、
方法論は両立しないのかなあ。
あ、つまりまとめることができて、
運営側がどのくらい頑張るかってことなんじゃね？
カテゴリー等を予め決めておいて、これに所属するようにしなさい、とか
逆に自由入力のタグ等を用意していて、好きに使ってください、とか、
その辺の力の入れ具合。
ニコニコ動画を例にするとカテゴリー(ランキング)は運営が用意するもの、
タグはユーザーが作るもの、
チャンネルは半分運営、コミュニティはユーザーという感じですね。
「布団コンピューティングのできるガジェットがほしい」
なのだけど、
「Twitter / medtoolz: タッチパネルのインターフェースは便利なんだけれど、...」
という話を聞くと、タブレットじゃ駄目なのかもと思うわけですね。
じゃあやっぱりポケットに入るPC、スマートフォン的なもの、
iPhoneだったりAndroidケータイだったり、
そういうものに期待するかとなるわけですが。
欲しいものをはっきり定義しときましょう。
ポケットに入る小ささ、軽さ。
Webがストレスなく閲覧できる程度の速度。
とりあえず現状だと遅いんですよね、ケータイって。
HT-03Aとか、Nexus One で、はてブを表示させたりすると、やっぱり遅いのですよ。
そういえばiPhone3Gでは試してなかった。速ければいいなあ。
スマートフォンが消し去ったもの - レジデント初期研修用資料で
寝室の布団から出て、「ほんの数歩」歩けば、
Core i7 に光回線をつないだデスクトップPCがそこにあるのに、
今はなんだか、布団にくるまってごろごろしながら、
無線LAN にショボいCPU、小さな画面で、
そんなに「我慢している」という感覚を覚えることなく、遅いネットを楽しむ。
とあって、こういうことがしたいのだけど、遅すぎるんですよ、HT-03A。
で、今日気付いたのですが、
2chブラウザ「Anちゃん」とか、
Twitterクライアント「twidroid」とかはかなり速いというか、
体感的には速いんですね(twidroidは顔アイコンを非表示にすると速くなる)。
たぶんなのだけど、HTML+CSS って自由度が高いから、
ある程度読み込まないと、レイアウトできなかったりするんじゃないかなあ。
サービス専用クライアントだと、一部のデータだけでも無理に表示することが可能と。
とりあえず最初の画面だけ描いておいて、それを読んでいる間に、
スクロール先を描いておく、みたいなことができそう。
実際にそうやっているわけじゃないと思うけど。
つまりこの段落は本筋じゃないね。
とにかくそのあたりの違いがあるんだよなあ。
ケータイ向けHTMLだとか、
スマートフォン向けにAjaxとか使ってなんとかするというのが現時点の解かなあ。
全てのサイトにそれを期待するのもあれだし、どうしたものかとも思い、
HTML5がその辺を解決してくれるのかもと思ったりもします。
なので今は布団から出て、
机に向かって正座してノートPC(これだってそんなに新しくない)を使うというのが
現時点での姿なのだけど、別の解もあって、
2chとTwitterしか使わないとかね。
ケータイメインの人がケータイ向けサイトしか見ない、みたいな感覚なのかも。
Webブラウザは重いものだと割り切って、専用クライアントのあるものしか使わない。
そういうのも解ではあるのかなあ。
PCでブラウザを使うときの自分の動きを考えてみると、
ページを表示するのには時間がかかるので、
バックグラウンドのタブで開いておいて、別のページを読み、
ページの表示が終わってから切り替える、みたいなことをしてたりします。
HT-03Aの標準ブラウザはウィンドウ機能で似たことができるのだけど、
メモリとCPU力が足りないので、ほとんど無理。
ポケットに入る携帯電話ってもう10年近く前から使っているし、PCだってそう。
だから、「ポケットに入るPC」ってのも想像は可能で、
現実にはそこに追い付いた製品はないので、
おお、これは凄いぞと感動することってないよね。
小さいのはわかった。でもPCほどじゃないよね、ストレスあるよね、となる。
後からこれは凄いなと思ったのは、
タッチパネルが直感的だなあとか、音声検索が出先で便利だなあとかはあるけど、
触ってみて、その瞬間にこれは凄い、ってのとは違う。
これからスマートフォンの性能はどんどん上がっていくけど、
そういう意味での感動はないんだろうなあ。
あけましておめでとうございます。
Twitter
をミニブログとして使うことにしました。
長いものに巻かれようということであって、
foursquare
がきっかけです。
これがはてブと連携する機能があるなら、
そのままはてブをメインとして使っていたのですが…
そもそも僕はこういうルールを自分に課しているのですね。
- ミニブログは1つのサービスを使う。
- 2つ使って片方をバックアップにするのはいいけど、
この内容はこっち、この内容はこっち、みたいな使い分けをしない。
- はてブとTwitterは両方ともミニブログである。
- リンクをするときは、相手がエゴサーチできる状態にする。
Twitterだと、エゴサーチのところで難点があったのですよ。
- 古い書き込みが検索できない。
- 短縮URLを使うと検索できない。
この辺の話は
「第3回SBM研究会で発表してきたよ ～やる夫ブログ読んだなう～」
を始め、何回も書いてますけどね。
ところがどっかのサービスが何かと連携しようとするなら、
それは、はてブとりもTwitterだという確率が圧倒的に高いんですよ。
これはもう、諦めてTwitterを使うしかないじゃないですか。
なので「リンクには短縮URLを使わない」というルールを課した上で、
Twitterをミニブログとして使うことにしました。
プレミアム会員とかしないかなあ。
お布施しておかないと心配なんだけど、広告収入系で黒字らしいから、いいか。
堅牢なコーディングルールを策定する方法(2) - 都元ダイスケ IT-PRESSの
まぁつまり「Javadocに書かれていない挙動をしたらバグ」です
ってのはどんな頓知だよ、というか、
僕の興味のあるところとは微妙にレイヤが違うなあと思った。
なので以降は興味のあるレイヤについて書きます。
関数がどういう挙動をするべきかというのを仕様だとすると、
その上に「どういう仕様を定めるべきか」という問題があって、
それを仮にメタ仕様と呼んでみます。
実際には「意図」って言ってることが多い気がする。
関数の引数にヘンなものを渡したらどうするべきなのか。
nullを返す？ falseを返す？ 例外を発生させる？ 例外は組み込み例外を使う？
ユーザー定義の例外を使う？ なんとなくPHPを想定。
コメントに書いてあるのが正しいというのはその通りだけど、
さて、どの方針で行きましょうか。そういうレイヤの話ですね。
コーディング規約としては、このレイヤが重要な気がする。
もっと一般的な例だと、どういう基準で関数を分割する？ クラスの分割は？
みたいなことかな。
括弧の付け方、スペースの入れ方は、実はそんなに読みやすさに影響しないと思う。
肥大化した関数、逆によくわかんない基準でこま切れになった関数、これは困る。
ソースコードレベルの仕様は実装しながら決まっていくのだから、
いかにして仕様を定めるかということが重要になるはず。
この辺は規模・開発体制・システムの設計に依るところが大きいと思うけど。
つまり個々の開発者にどの程度の裁量があるの、という話。
んで、開発者同士は互いの意図について把握しておくべきだろうな、と思うのね。
でも規約として意識する必要もなくて、
「誰それが何月に開発した、何々モジュール」みたいな単位で、
首尾一貫している程度でよいと思ってる。
その程度の首尾一貫性があれば誰でもメンテできる。
これ以上粒度の細かいチーム開発はしたことないからよくわかんない。
最近気をつけているというか、興味を持っているというか、
この辺に気を配ると、ぐんとプログラムが読みやすくなるよなあ、というもの。
- ガード節的な条件文
- 一時変数が出てきたら関数への分割を考える
- 戻値は真偽値ではなくオブジェクトにする
- メソッドチェインが使えないか考える
ガード節的な条件文
関数の頭のところに、先に進むかreturnするかの分岐を書くというテクニック。
本来の意味のガード節だと、returnするのは特殊な場合で、
通常は先に進むというニュアンスがあるのだけど、
あんまり気にしなくていいかなあ、と思ってるので、ガード節「的」としました。
function hoge()
{
if (条件式) {
なんかの処理が
数行続く
そんなブロック
}
}
だと、ifの中のブロックに入らなかった場合はどうするのかなあ、
と考えながらコードを読む必要があるのですが、
function hoge()
{
if (! 条件式) {
return;
}
なんかの処理が
数行続く
そんなブロック
}
なら、ああこれで終わりなのね、とすぐわかるので読みやすいと。
一時変数が出てきたら関数への分割を考える
function hoge()
{
$tmp1 = fuga1();
$tmp2 = fuga2($tmp1);
$tmp3 = fuga3($tmp2);
$tmp3を使うなんかの処理が
数行続く
そんなブロック
}
これだと$tmp1や$tmp2を後で使うのかなあ、と考えながら読む必要があるので、
function hoge()
{
$tmp3 = getTmp3()
$tmp3を使うなんかの処理が
数行続く
そんなブロック
}
function getTmp3()
{
$tmp1 = fuga1();
$tmp2 = fuga2($tmp1);
return fuga3($tmp2);
}
とします。
一時変数があるということは、コードの記述量もそれなりにありそうだし。
戻値は真偽値ではなくオブジェクトにする
何か処理をして、成功したらtrue, 失敗したらfalseを返すってのは
割と定番なんですけど、
成功・失敗の2つしかないと思ってたら、
実はもっとパターンがあった、となると困るので、
最初からオブジェクトにしておきましょう、みたいな感じですね。
class Result()
{
public $success = false; // 成功
public $fail = false; // 失敗
public $canceled = false; // 意図的に中止された
public $duplicate = false; // 重複になるから途中で中止した
}
みたいに、パターンを増やすことができます。
メソッドチェインが使えないか考える
DB的なものからある条件でデータを取得し、
ソートしたり、ランダムに並び換えたりする、みたいな流れだと、
$data = $hoge->select(取得条件, OPTION_FLAG_SORT);
$data = $hoge->select(取得条件, OPTION_FLAG_SHUFFLE);
という手もあるんですけど、実装が許すなら
$data = $hoge->select(取得条件)->sort();
$data = $hoge->select(取得条件)->shuffle();
と書きたい。
これは$hogeのクラスやselect関数の肥大化を避けるという効果があるのだけど、
そこまでの説得力はないかなあ、と思います。
要は好みの問題なんじゃないの、と言われたらそれまで。
RSS 1.0
