2008/04/03
≫ [雑感]鮭の一生とソフトウェア開発
鮭は川で孵化して海に出て、成長したら生まれた川に登って産卵します。日本人なら誰でも知っている話です。この話はあまりに有名すぎるので僕はわりと最近まで鮭という魚はすべて海に出る習性があるものだと思い込んでいました。ところが、そうではないそうです*1。
鮭は孵化してしばらくの間は川で過ごします。しかし、川の餌はそれほど豊富ではなく、すべての鮭が生きていけるほどではありません。上流から流れてくる餌は、ごく一握りの生まれつき体が大きくて強い個体に食いつくされてしまうからです。大半の雄とすべての雌は川で生き延びていけないから仕方なく海へ出るのです。一方、川での生存競争に勝ち抜いた鮭は海へ出ることなく、一生を川で過ごします。
秋になれば海で成長した雌が遡上してきます。川に残った鮭たちは、それを待って産卵に参加するだけです。川で生きることに特化した体型をしていますから射精後に力尽きて命を落とすこともありません。鮭の寿命は数年なりますから、何度か子孫を残すチャンスに恵まれるわけです。川の鮭は少年時のスタートダッシュに成功しただけで危険な海にでることもなく、子孫を残す切符を何枚かもらえるわけですから、うらやましくてしかたありませんね。ただ、そのかわりと言っては何ですが、彼らは成長した鮭よりも圧倒的に身体が小さくて雌鮭にとって魅力的ではありませんから、よほどの幸運がないと産卵に付き添わせてもらえません。やはり危険で広大な海をモノにできた雄の方が魅力では勝るのでしょう。
この話はソフトウェア開発にも通じるものがあるように思います。
モノ作りは上流から始まりますから、いかに餌が流れてくるおいしい上流ポイントを取れるかが勝負なわけです。その立ち回りに失敗すると下流に降りなければなりません。上流をキープしたなら、あとは成長した技術者が遡上してくるのを待って開発させるだけです。彼らは上流で生きることに特化していますから、ずっと上流で生活することができますし、何度もプロジェクトに携わるチャンスがあります。しかしながら、下流の先にある広大な海の世界を知らなければ「モノを作るための伴侶」としての魅力がなく、事を成すことができません。そこで選ばれるのは優れたアイディアを持った人か、人を惹きつける魅力のある人だけです。
一方、下流へと降りた技術者は深くて広い技術の海でたくさんの犠牲を払いながら生きていきます。9割は海で力尽きて死んでいきます。やっと力をつけて遡上したならチャンスは一度きりです。しかし、「作る」ためには上流へと登る以外に道はありません。
海での処世術を覚えれば海で一生を終えることも不可能ではありませんし、むしろその方が長生きできると思います。損得でいえば海で生きた方が良いのでしょう。
ソフトウェアの世界で生きる者にとって、上流だけで生きることを目指すのか、技術者として下流に降りるのか。そのさき一人前になったとき、海に残るか川を登るか、はたしてどの生き方が幸せなのでしょうか。
関連エントリ
*1 昔、NHKの深夜に放映されてたドキュメンタリーで仕入れた。寝ぼけて見たものだから間違いもあるかも
2008/04/04
≫ [雑感]晒せば本当に強くなるのか
某界隈では「晒すことで強くなる」と言われています。果たしてこれは本当でしょうか?「晒す」とは何か、「強くなる」のは誰か、によって答えは違ってくるでしょうが、「晒す=公開する」で「強くなる対象は自分」というのであれば、僕にとっては「それは違う」ようです*1。
「晒すことで強くなる」の理屈は上級者の目に止まることで指摘や提案がどんどんやってきて、それに応酬する過程で実力がついてくるということですよね。それならば、強くなるためにはまず上級者の心の琴線に触れるような内容をアウトプットできるだけの力が必要ですし、あちこちから来る容赦ない突っ込みに耐える心の強さと不要な提案を濾過できるだけの力も必要なわけです。でも、その要件を満たしている人って既に強い人じゃないですかね。つまり、晒して強くなったというよりは強い人は晒してたと言った方がより正確なように思います。
確かに強い人は晒しているかもしれません。しかし、同程度の晒しを試みたにもかかわらず強くなれなかった人もいるわけです。そういう失敗例は華々しい成功例の陰に埋もれて注目を受けることはありませんから、人の目はより一層成功例だけに惹かれてしまいます。やがて晒せば必ず強くなるんだというような誤解が生まれるわけです。
こういう考察が出てきた僕にとって「晒して強くなる」というのはエリートコースであって万人に通じるようなやり方ではないということです。自分の能力に自信があって、階段を一段飛ばし・二段飛ばしで登って行きたい人はどんどん晒していけばいいですし、何だかおかしいなと自分の能力に疑問を感じるようであれば自信がつくまで晒すことをやめて力を蓄えればいいんだと思います。闇雲に晒したところで言われるようなほどの成果が上がるわけじゃないですよ、と。僕は自分の能力をいつでも疑っていますから、エリートコースには行かずに着実に登っていくことにします。
今日はここまでにします。続きは次回で、もう少し掘り下げることにします。
関連エントリ
*1 晒すのが恥だったり、強くなるのが他人だったりする場合は「当たり」かもしれませんけど。
2008/04/05
≫ [雑感]晒して強くなりやすいもの・なりにくいもの
晒しても強くはならないよと言いました。
技術的な上達について一番の近道だと僕が感じたのは、晒すことではなくオープンソースプロジェクトに身を投じることでした。
パッチを送ったり足りない機能を追加してみたりサンプルコードを書いて公開したりするわけです。それだけの実力がなければドキュメントを書いたり配布サイトのメンテナンスを買って出てもいいです。極端な話、勉強会の機材運びや二次会の選定でもいいわけです。最初は自分に確実にできそうな簡単なことから初めて少しずつ信頼を勝ち取っていけば、最終的にはいろいろ任されるようになっていきます。「僕がやります。やらせてください」と言ったプレッシャーで強くなれるわけです。この場合、晒すことになるのはアウトプットそのものではなくて、失敗したときの恥でしょうか。
技術的なことはよほど最先端なことをしない限り前例がありますから、問題になっている部分はわりと明確で、ある程度の力量を持った人なら各人のスキルに合わせて適度な難易度に分解できます。あとは各自が自分と勝負するだけですから、あえて晒す必要はないわけです*1。
晒さなければ強くなれないものもあります。それはプロジェクトを運営する能力です。
当然のことながら晒されていないプロジェクトには参加することはできません。晒さなければメンバーは集まらず、運営することはできません。しかし、ひとたびメンバーが集まってしまえば待ったなしです。せっかくの有志たちも活躍できる場がなければ去ってしまうからです。運営をうまく切り盛りするには、いかに人に適切な問題を出すことができるかにかかっています。これには経験に裏打ちされた技術力が必要で、(上の手法に限らず)オープンソース活動に必要な能力を習得していないと難しいものがあります。
かといって、プロジェクトでの活動経験があればそれでよいかというと、そうでもありません。部長を何年勤めようとも社長としての能力が備わらないのと同じように、参加している限りでは運営のノウハウは身に付きません。なぜなら、単なる技術者でいるならば問題を「どう」解くかさえできればよいのですが、運営するには「何が」問題なのかを見極めなければならないからです。問題をどう定義するかによって解き方は変わってきますから、これといった正解はないのです。こればっかりは何度か失敗して経験を積むしかありません。もちろん独りプロジェクトというのもアリですから、はじめは小さいプロジェクトを独りでやってみて全体の流れをつかんで、少しずつ魅力的な(人が集まりやすい)プロジェクトに挑戦していくのがいいように思います*2。
晒すことでこそ強くなれるものもあります。良いアイディアやデザインについて考える力です。
プロジェクト運営と良く似た性質を持っていますが、人を効率良く回すような運営手腕よりも、人を惹きつける力を必要とします。いいアイディアを提供することで技術的に優秀な人を惹きつけて実装してもらうわけです。よって、技術的な実力はそれほど問われません*3。
このスキルを磨くにはプロジェクト運営と同様に数をこなすことが近道ですが、言語化することが難しい感覚的な世界*4のため、人が晒した過程を見ることで強くなるという手段はなかなか通じません。巧みに議論を誘導しながら、たくさんの人と意見を集めて全員が納得できる道筋を出す。状況によって答えの変わる問題を何度も繰り返すことで強くなるわけです。これをやるには徹底的に晒して、常に人の注目を集めている状態をキープできなければならないのです。
ここまできてやっと先日の鮭の話につながるわけです。プロジェクトへの参加は海へと出て下流をモノにすることで、プロジェクトの運営は一人前になって遡上して産卵することで、アイディアやデザインの発掘は上流をモノにすることです。鮭の話の流れでいくと上流の例はダメコンサルみたいな感じですけど、これは僕が下請SIer出身だから僻んでるだけで、ちゃんとできる人はやっぱりスケールの違う仕事をします。
僕はプロジェクト参加レベルは卒業(したことに)して、今やっと独りプロジェクトに差し掛かったところです。僕は技術側の人ですから、最終的にはプロジェクト運営に重心を置きながらデザインをかじるくらいの場所に向かうでしょう。そんな立場にいる僕ですから今回のような話になるわけで、立場が違えば言うことが違うだろうと思います。そういうことを想像すれば、「晒せば強くなる」と言ってる人たちがどういうポジションにいる人かは見えてきます。もちろん自分が言うべき言葉も見えてきます。自分がどの世界の住人で、将来的にどの世界に住みたいか。それを押さえておけば余計な言葉に惑わされず、自分のやりたいことに集中して向かっていけるのではないかな、と僕は考えます。
*1 後続のことを思えば晒してもいいけどね。
*2 幸いにもオープンソースプロジェクトの運営は多額の資金を必要としませんから、失敗を恐れる必要はありません。
*3 もちろん、悪いアイディアであれば誰も集まらずゼロで終わりますけど。
2008/04/06
≫ [与太]50の壁を越えられないリア充ブロガーと越えるはてなー
はてなーって交流しているイメージないっていうネタがあったのでBlog 訪問者「50人以上」には相変わらず越えられない壁〜ブロガー調査を肴に1エントリ書いてみるよ。
ブロガー調査のエントリによると一日に50アクセス以下のブロガーは6割強もいるんだそうです。おかしーなー。これといってネット(リアルも含むけど)友達のいない孤独な僕ですら、一日のアクセスは300を越えるし、フィード読者は40人越えるのに、明るくて友達のたくさんいるリア充(ネト充含む)が50の壁を越えられないわけないじゃない。だって、友達50人が1アクセスしただけで50いくんですよ!?
こう見えても僕は一時期リア充(ネト充?)やってたので、なぜ彼らのアクセスが50未満なのかがわかります。僕の経験はBBSだったんですけど、ブログも根っこは同じですから転用可能なわけです。
まず、友達の数を20と設定します。
リア充のブログ生活は自分のブログを開くところから入ります。昨日のエントリにコメントがついてないか確認して返事を書きます。そして、今日あったことを100文字程度でエントリします。ここまでに15分ほどかけます。次に友達全員のブログを巡回します。RSSリーダーは使いません。フィードにはコメントが含まれていませんし、何よりデザインを無視して無機質に抽出したテキストだけを読むなんて失礼だと思うからです。お気に入りを一つずつ開いて新着を読んだら、他の友人達のコメント宛も含めて感想を書きます。ここで忘れてはならないことが「読んだら必ず1コメントしなければ友達ではない」という鉄則があることです。昨日のエントリを開いて昨日書いたコメントに返事がついていないか確認*1します。この作業は1つのブログで6分ほどかかります*2から、全員分終えるのに120分かかります。最後に自分のブログをもう一度見ます。巡回している間にコメントがついているからです。これに10分ほどかけて返事をして終了です。
たっぷり2時間はかかってますね。これで友人全員のブログを2回ずつ踏むことができました。友人が鉄則を守ってくれれば自分のブログも2回ずつ踏んでくれているはずです。20人×2回で40アクセスなわけです*3。
どうです?2時間以上を費やして20人の友達をキープしても40アクセスでしょう?50アクセスを超えたい?どうぞ、友達を25人に増やしてください。6分*4あれば巡回先を1つ増やせますから、5人増やすなら30分あればいいです。もっとも、まともな社会人*5がネットに3時間も投入できないでしょうけど。
すごく適当な計算でしたけど、このようにコミュニケーションを前提にした展開は非常に手間と時間がかかるものなのです。ネト充に近い生活をしていてこれですから、リア充が50を越えられないのは不思議でも何でもありません。
では、はてなーはどうしているか?っていうと、興味の向いたネタだけを30分くらい巡回してネタを拾って、短文で済みそうな反応を30分くらいかけてブクマして、1時間くらいかけて自分の興味のおもむくまま気合の入ったエントリを書くわけです。嗜好が合う人がすべてが読者の対象ですから、リア友20人限定の話題よりかは分母が大きく、同じ2時間を投入するにしてもアクセス数は稼げます。事実、僕は巡回だけでも毎日コンスタントに100くらいのエントリを読んで*6ますし、5,6個くらいはブクマしますから、ネト充やるよりかはたくさんのアクセスを生み出しているでしょうし、アクセス返しを受ける可能性もあるでしょう。その代償としてあまり面識のない人からのコメントを受けることになり、よそよそしい感じのどこか困ったような態度で対応している印象を与えてしまうわけです。
こうして考えてみると、友達たくさんで広く浅く付き合うリア充たちがネット上では狭くて深い付き合いをしていて、一見コミュニケーション不全なはてなー達が広くて浅い付き合いをしているんですよね。面白いなぁと思いました。
*1 もちろんありますよ。コメントには必ず返事をするのも鉄則ですから
*2 20人分のコメントとそれへの返事がついてるんですから!
*3 ネット廃人はこれを2ターン処理します
*4 ほんとはもっと必要ですけど
*5 リアルを大切にする人のことですよ
*6 タイトルだけってのもあるけど
2008/04/07
≫ やはり来てたか
ぺんちゃん日記 - はてなハイクを使ってマンガができないかなで、ニコニコ動画とやる夫シリーズを足して2で割ったような4コマ漫画webサービスがあったらおもろそうだなーと書いたんだけど、ひょんなことから見つかりました。
です。これは来ると思うな。コミュニティがうまく機能すれば、だけど。
こんな感じに背景とキャラクタを重ねて吹き出しを合わせてマンガのコマにできます。アニメーションGIFとかも選べますし、吹き出しの出る順序も変えられるので豊かな表現ができると思います。着眼点はすごくいいので、流行ってくれるとうれしいなぁ。
観客としてはワンクリックで一気読みできるように縦に並ぶとうれしいな。何度もクリックするのタルいんだぁ。ナローバンドでは。吹き出しが出現するタイミングなどを設定できるみたいだから、それは無理なのかな。
ところで、このサービスを知ったのは作者のブログぺったんぺったんが面白くて、ついクリックしたのがきっかけです。こちらもおすすめしておきますんで、興味があったらどうぞ。
2008/04/10
≫ [雑感]良いwebサービスは立場や価値観が違う人たちが共生できるサービス
僕にはどんなwebサービスがウケるかなんてわからないけど、良いwebサービスは立場や価値観が違う人たちが共生できるものなんだと思う。
ブログで言えば、書き手にとっての都合だけを考えたブログでは読者は集まらないし、読者に媚びてばかりのブログも相手にされない。書き手が好きに書けながらも、別の視点から意見を出せる。綺麗な面だけでなく汚い面も含むことができるような。アルファブロガーのブログは言いたいことを言ってはいるが、こちらの言いたいことも言わせてくれる。いや、それどころか、わざと隙を作ってくれていて言いたいことを言わせてもらえる。そういう優しさがある*1。それと同じように、共生ができる(居場所を確保できる)ようなサービスが良いサービスじゃないかな。
*1 あれもこれもと言いたいことを詰め込みすぎて相手を黙らせてはいけない
2008/04/12
≫ [suisen]地味に改良中
少しずつ手を入れてます。今回はタグのレーティングに使う計算式を変えてみました。結果を楽しみにしてましたけど、改悪になった模様で、特徴のないエントリばっかり出てくるようになってしまいました。週明けにも戻す予定です。う〜ん、どういう計算が妥当なんだろう…。
ところで、レコメンドされたエントリの中から興味あるものをクリックして、ブクマコメントを眺めると、高確率でDONTAKTとゴリラブーツが絡んでたりします。実のトコ、この2つをソースにしてれば僕の興味はほとんど満たされるような気がします。
人間おそるべし。
2008/04/14
≫ [tdiary]ぺったんプラグイン
注)iframe内のドキュメントを参照するのは無理っぽい感じで、以下のスクリプトは満足に動きません。
ぺったんのコミックをtdiaryのブログに添付できるようになるプラグイン。
ぺったんには最初から添付用タグを生成してくれる機能が備わっているので、こんなもん作る意味はあんまりないんだけど、より楽にエントリを書けるという意味で。
ptn.rbソース
def ptn(page_id)
html = <<-IFRAME
<iframe src="http://pettan.jp/ipage#{page_id.to_s.gsub(' ', '')}" scrolling="auto" style="height=300px;width=100%;" frameborder="0" onload="if(document.all) {this.height = (this.scrollHeight + 5);} else {this.width = parentNode.offsetWidth; this.height = (this.offsetHeight + 5); }"> </iframe>
IFRAME
html
end
記法(wikiスタイル)
{{ptn 563}}
注)563はコマID
出力結果
iframeで埋め込んでいるので、最適な大きさにするためにonload時にjavascriptでサイズ調整してます。IEでどうなるかは知らんです。
近いうちにcodereposにでもうpしようかしらん。
2008/04/15
≫ [ruby][hatena]はてなダイアラーのエントリ中の画像をダウンロードするRubyスクリプト
あるはてなダイアラーがエントリにアップロードした画像のすべてをローカルにダウンロードするスクリプトです。スクリプトを実行したディレクトリに保存します。
エントリをひとつずつ過去に遡ってダウンロードします。起動オプションなしで実行した場合、アーカイブページから拾った最新エントリから開始します。指定のエントリがある場合は、そのエントリのURLを起動オプションで与えてください。最古のエントリに到達するまで止まりません。途中で止めたいときはCtrl+Cで止めてください。ファイルは強制上書きです。保存できないファイルとか、余分に保存しちゃうこととかもあります。いらないのは後から消してください。
なんでこんなスクリプトをこしらえたかというと、
です。デフォルトではuidにguri_2が入ってますけど、他のIDでも通用すると思います。
では皆さん、心おきなく愛でてくだしあ。
require 'rubygems'
require 'hpricot'
require 'open-uri'
uid = 'guri_2' #はてなのIDを入れてね
archive_url = "http://d.hatena.ne.jp/#{uid}/archive"
url = if ARGV.empty?
latest = nil
doc = Hpricot(open(archive_url).read)
(doc/'ul.archives').each do |ul|
li = nil
(ul/:li).each do |l|
next unless l.attributes['class'] == 'archive archive-section'
li = l
break
end
(li/:a).each do |a|
if a.attributes['class']
else
latest = a.attributes['href']
break
end
end
break if latest
end
latest
else
ARGV.first
end
while(url) do
puts url
doc = Hpricot(open(url).read)
(doc/'div.section').each do |sec|
(sec/'img').each do |img|
src = img.attributes['src']
fn = img.attributes['src'].gsub('/', '_').gsub(':', '_')
begin
File.open(fn, "wb" ) do |f|
uri = URI.parse(src)
Net::HTTP.start(uri.host, uri.port) do |http|
f.puts http.get(uri.path).body
end
end
rescue
puts "error:#{src}"
end
end
end
n = nil
(doc/'link').each do |link|
if link.attributes['rel'] == 'prev'
uri = URI.parse(url)
n = uri.scheme + '://' + uri.host + link.attributes['href']
break
end
end
url = n
end
2008/04/16
≫ cssのクラス名にブランクが含まれてるが
昨日のスクリプトを作った際、はてダのCSSのクラス名にブランク混じりのものがあってhpricotで抽出できずに悩んだんだけど、この記法は複数のクラス名をつけるためにあるんだそうな。
<div class="foo bar">
は
<div class="foo" class="bar">
みたいな感じらしい。へー。では、hpricotでも
(doc/'div.bar')
で解釈できるんかな?
=>できるようだ。
2008/04/17
2008/04/18
≫ [雑感]抽象度と使い勝手
モノの捉えかたには抽象度というのがあります。抽象度が高いほど応用が利いて使い勝手が良い反面、実効性を欠いたものになります。一方、抽象度が低いものはリアリティを備えていますが、使い勝手は悪くなります。たとえば、「要は勇気がないんでしょ」という言葉は抽象度が高く、とても応用がきくので幅広い分野の人が反応したり引用したりできる反面、そんなアドバイスがまったく役に立たない人たちの反論を受けてしまいます。これが抽象度を低くして具体的に「相手も君のことは好印象を持ってるみたいだけど、彼女は引っ張っていくタイプが好きだから、どこかで一歩踏み出さないとチャンスを失うぞ。今、君に必要なのは勇気だ。」みたいな話にすれば、使いまわせる人が減る代わりにアドバイスは実効性を伴うわけです。
こんな話はオブジェクト指向でプログラミングする人なら誰でも知ってる話ですよね。基底クラスはシンプルな機能がないかわりに様々なクラスへと発展させることができるわけです。ロジックがガチガチに実装されているクラスはその場で実行できる便利なコードではあるけれど、他のプロジェクトへの応用が難しい。
ところが僕はわかってませんでした。
やる夫の例で言うならば、たくさんのAAや背景、効果などのことです。これらのレイヤーを大きさ、場所を変えつつ、台詞をつけて重ねれば、一枚のコマにできるわけです。これを何コマもあわせてストーリーを組み立てれば作品の出来上がりです。こういった具合に「組み合わせの妙」を発揮することができれば、話は面白いけど絵はダメな人と絵はうまいけど話はダメな人の能力を最大限に活かせるのじゃないかなと思うのです。
[ぺんちゃん日記 - はてなハイクを使ってマンガができないかなより引用]
以前こう書きましたが、実際ぺったんでやってみると案外難しいわけです。
先程の話と同じように絵にも抽象度があって、抽象度の高い絵ほどチープではあるけれど幅広く活躍できて、低い絵ほどカッコいいけれど使い道がないのです。例えば、以下にふたつの抽象度の高い絵がありますが、
これを組み合わせると、
それほどおかしくはありません。
では、次の抽象度の低い絵が二枚のときはどうでしょう?
少し苦しいですね。もっとたくさんの写真があればきれいに一致するものが見つかるかもしれませんが、それを探す手間は決して少なくはないでしょう。適当な絵を組み合わせればマンガになるというのは事実ではありますが、デキの良い作品を作るには、相応の手間と想像以上に大量の素材が必要になると思います。
やる夫シリーズが背景がなくても、すこしおかしな組み合わせでも、大きな違和感を発生させずに楽しむことができるわけはAAという解像度の低い表現方法だからこそなのです。
ぺったんは豊かな表現ができるツールではありますが、使いこなせるようになるまで手間と時間がかかります*1。ぺったんが飛躍するためには百万くらいの素材と、その中から欲しい1つを数クリックで絞り込めるUIが必要になってくるんじゃないかと思います。
追記
抽象度が違うものを混ぜないというのも非常に大事だというのを書き忘れました。ライブラリだって、クラスごとに抽象度が違うと使いにくいですよね。
*1 もちろん低解像度な使い方もできますけど。
2008/04/20
≫ [雑感]匿名・顕名と嫌儲・真儲
ネットには嫌儲(けんちょと読むらしい)と言われる人たちがいます。ブログにアドセンスやアフィリエイトなどを貼り付け、広告収入を得る行為を嫌う人のことを指すようです。儲けることを嫌うから嫌儲というのでしょうね。
そういう意味では僕も嫌儲なところがあって、この日記には極力そういうものは貼らないようにしています。その理由はアマゾンアソシエイトにNOと言え。で語られていることに近い感じですね。自分の意見の信頼性を損なわないよう、潔癖すぎるくらいにお金の流れを絶つわけです。まあ、僕の場合はページを開く重さで嫌われたらどうしようとか、こんなくだらない内容で収入に結びつくほど世の中甘くないぜとか、日和ったりネガったりな要素でそうなっているのですけど。いずれにしても、こういう人たちは、自分がそうしたくて勝手にそうしているわけですから、単純に価値観の問題であって大きな問題にはなりません。
一方、嫌儲の反対側にいる人たちもいます。個人でブログを運営し、自分の責任でおすすめのアイテムを紹介することで収入を得るわけです。金が絡んでるとはいえ、うっかりおかしなものを勧めてしまえば信用を損なうわけですから、アフィリエイトを中心とするブロガーだって創意工夫を重ねて記事を作り上げているのです。記事の内容と紹介された商品のイメージが一致していてこそ安定した収入になるわけで、その収入は実に真っ当であると言えます。僕はこのゾーンにいる人たちを嫌儲に対抗して真儲(まっちょ*1)と名づけました。真っ当な儲けで真儲です。
この嫌儲と真儲は顕名で個人を前面に出したブログを運営しているわけですから、どういう戦略をとるかは各自の自由になるわけですが、世の中には匿名による発言というものもあって、こちら側で嫌儲と真儲が小競り合いをしているわけです。具体的にどういうことかというと、2chまとめサイトというのがあって、これらのサイトは2chに投稿された良質のスレ(レス)だけを抽出したものを編集したりまとめたりして自分のサイトにコピペするのです。良質なレスを集めることで人を集め、アフィリエイトで収入を得るという寸法ですね。2chの住人からしてみれば、自分が頭をひねって考え出したレスをコピーすることで収入を得ているのですから、この行為を面白くないと感じるのは仕方のないことだと思います。
さて、嫌儲・真儲と顕名・匿名という二つの軸がでてきたので、これを図にしてみました。
そもそも何故2chねらーが2chに投稿しているか?というと、くだらない発言にまでリスクを負いたくない*2からです。自分の発言に対する見返りを放棄してでもリスクを放棄したいわけです。そういう意味では率先して実名を名乗りつつリターンを求めるビジネス系ブロガーの対極にあるといえます。2chに投稿されたレスは実利よりも安全を選んで「捨てた」レスですから、それが儲け事に利用されたとしても文句が言えるものではありません。そんなにレスを取られるのが嫌ならIDが関連付いたはてブのようなサービスを使うしかありません*3。僕が自分のことを嫌儲側の人間だと思っているのは、実利を期待していないにも関わらず、IDを紐付けることができないコメント欄を利用せず、はてブを中心にコメントするからです。
そう考えると、嫌儲というのは単に金が嫌いというだけではなく、自分のアウトプットを自分の意思でコントロールできない不快感が一つの理由かもしれないと思うわけです。逆に考えれば、自分のアウトプットをきちんとコントロールができる仕組みと匿名性があれば、嫌儲の一部の層は真儲へと流れるんじゃないかと。
上の図では2chまとめサイトを匿名×真儲に分類しましたが、このジャンルはあまり開拓されていないので、ここをうまく乗りこなしたサービスがヒットするかもしれませんね。例えば、はてな匿名ダイアリーにアフィリエイトが添付できて収益をIDに持っていけるとか。
本当はニコニコ動画を嫌儲にからめて書きたかったんだけど、何故だか話が違っちゃいました。その辺は次回にでも。
2008/04/22
≫ [ruby]グーグルの画像検索から画像をダウンロードするRubyスクリプト
大量の画像を見たいとき、グーグルの画像検索は非常に役に立つんだけれど、細い回線の環境だとページをめくるだけでもイライラしてくるのでスクリプトにしてみました。google_images.rbです。
このスクリプトはGoogleの画像検索に表示される画像をローカルに保存します。一つの検索ワードに対し、120個の画像を保存します。検索ワードはカレントディレクトリにあるwords.txtを読み込んで使います。words.txtは改行区切りのテキストファイルです。画像は実行ディレクトリの下に検索ワードのディレクトリを作成して保存します。上書きするので気をつけてね。実行にはrubyのほかにrubygemsとHpricotが必要です。
使い方
- google_images.rbを\tempにコピー(UTF-8で保存してね)
- words.txtを\tempに作成(UTF-8で保存してね)
- google_images.rbを実行
>cd \temp temp>ruby google_images.rb
words.txtの例
ペンギン gentoo penguin
google_images.rb
#グーグル画像検索から画像をダウンロードする
#使い方
# ruby google_images.rb word1 word2 ...
# word1,word2は検索ワード
# wordを省略した場合、words.txtを読み込んで検索ワードとする
# words.txtはUTF-8の改行区切りで
$KCODE='u'
require 'cgi'
require 'open-uri'
require 'kconv'
PAGES = 5
STEP = 20
AGENT = 'Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7.5) Gecko/20041108 Firefox/1.0'
if ARGV.size > 0
words = ARGV.dup
else
words = []
File.readlines('words.txt').each do |l|
word = l.gsub(/\n/, '').gsub(/\r/, '').strip
words << word unless word.empty?
end
end
words.each do |word|
(1..(1+PAGES*STEP)).step(STEP) do |i|
w = CGI.escape(word)
url = "http://images.google.co.jp/images?hl=ja&q=#{w}&lr=lang_ja&um=1&ie=UTF-8&sa=N&start=#{i}&tab=wi"
html = open(url, {"User-Agent" => AGENT}).read
html =~ /id=ImgContent(.*)<\/script>/m
if $1
dir_name = word.tosjis
Dir.mkdir(dir_name) unless File.exist?(dir_name)
blk = $1.dup
blk.scan(/dyn\.Img\(\"(.*?)\);/m).each do |dyn|
urls = []
dyn.first.scan(/http:\/\/(.*?)"/).each do |img_url|
urls << ('http://' + img_url.first)
end
if u = urls[1]
puts u
fn = dir_name+'/'+u.gsub('/', '_').gsub(':', '_')
begin
File.open(fn, "wb" ) do |f|
uri = URI.parse(u)
Net::HTTP.start(uri.host, uri.port) do |http|
f.puts http.get(uri.path).body
end
end
rescue
rescue OpenURI::HTTPError
rescue Net::HTTPBadResponse
rescue Errno::ECONNREFUSED
rescue Errno::ECONNRESET
rescue Errno::EBADF
rescue Errno::ETIMEDOUT
rescue Errno::EHOSTUNREACH
rescue Timeout::Error
rescue EOFError
rescue SocketError
puts "error:#{u}"
end
end
end
end
end
end
Googleはユーザエージェントによって出力結果を変えたりjavascriptで動的にコンテンツを表示したりと、つかみどころがないトコがあるので予想外なところで苦労しました。うまく動かなかったらごめんね。
2008/04/28
≫ [rails]ポップアップに悩む
画像にマウスを重ねると、その画像の詳細情報がポップアップというかバルーンヘルプというかフキダシというかツールチップというか、まぁそんな感じに表示される仕掛けを実現したかった。javascriptのことはよくわからんので、これをギョーカイで何と読んでるかすらも判別不能。そこで時間をかけてググってみたら、overLibというのがそれっぽい感じ。
とりあえず導入のために簡単なサンプルで動かしてみた。まぁ動いた。しかし、Railsのアクション込みでポップアップさせようと思うと、どうにも無理目なことに気がつく。うーみゅ、これなら自前で作った方が速いか。onMouseOverイベントを拾って詳細情報を出すdivをvisibleかhiddenに切り替えればええんやろ?
なんとなくできそうな感じだが、画像の表示位置によってポップアップする場所を変えたいな。せめて右上、右下、左上、左下の4種くらいは欲しいな。

◆ へだち [こんにちは。へだちです。 いろいろとご紹介ありがとうございます。 ブログ書いてばっかりで「ぺったん」の方はほ..]
◆ yas [おお、ほんとだ。これはいい。 >ブログ書いてばっかりで「ぺったん」の方はほったらかし気味 それでぺったんを見..]