 
|
はてなキーワード: ライブラリとは
脆弱性で話題になっているAndroidアプリのES File Explorerですが逆アセンブルしてみたらなんか大量に外部ライブラリが混ざってました。
どこかに著作権表示ありましたっけ？ってかLGPLも混ざってるんですが。
色々含まれているけれど一部の例
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
ネットで禁煙情報を収集してみたら驚くほど禁煙がうまくいっているで
新年から禁煙を始めようと思っている人に自分がいいと思った禁煙情報のサイトを紹介します。
（まだ2ヶ月しか禁煙できてないのだけれど私的には奇跡に近い。）
PCのみ 利用可能
ここで禁煙を始める前に一通りの一般的な禁煙に関する知識を仕入れられる。
あくまで、ふーん程度の知識なのだが、あるとないとでは全然違うのでさらっと読んでおく。
依存には
身体的依存（ニコチン依存）と精神的依存（習慣）があると理解。
どうしようもなくイライラしたのはニコチンのせいなのだと知った。
ニコチンとかタールとかの違いもよく分からなかった私には役立った。
禁煙外来を探している人は家の近くに禁煙外来がないかここで検索するといい。
PCのみ 利用可能
http://www.health.ne.jp/library/kin-en/index.html
読みやすく、分かりやすい。
記事が細かく分かれているので長すぎて読み疲れるということがない。
http://www.health.ne.jp/library/3000/w3000142.html
1禁煙する理由の確認
2 喫煙行動の観察
3 傾向の分析と対策づくり
と読んでいいなと思った。
禁煙日数が延びていくと命の木とかいうのが成長していって面白い。
PCのみ 利用可能
よくあるアフィリエイトに誘導するような記事がないので
素直に読んでいくことができる。
http://www.kyposky.net/content4.html
この部分だけは私ならそのままずるずるいってしまうと思った。
全体的にはいい内容だと思う。
アフィリエイトが多いのが若干残念だが
「禁煙励ましゼミ」はかなりいいのでそこだけでもおすすめする。
メールで励ましゼミがあるようだがメールアドレスを登録するのが嫌で使ったことはない。
毎日配信してくれるようなのでこちらの方が便利かもしれない。
送られてくる内容はWEB版とメール版で違うようなので両方利用するといいかもしれない。
http://d.hatena.ne.jp/azakeri/20050926/p2
考えさせられる。
実体験の話はやはり言葉の重みが違う。
PCのみ 利用可能
http://zenritsusen.karou.jp/threewall.html
＜禁煙第１の壁＞
＜禁煙第２の壁＞
＜禁煙第３の壁＞
段階による体の変化が分かる。
http://www.youtube.com/watch?v=DaPdVn4ETC0
若干の胡散臭さはあるけれど、内容的にはそういう仕組みだろうなと思う。
「喫煙する権利なんざ、ガキと貧乏人と黒人と馬鹿にくれてやるよ」
が全ての動画。
タバコの煙を避けたい人には非常に便利。
かなり役に立ったと思うものをまとめてみました。
私自身、知識を得るだけでここまでうまくいくとは思わなかったのでびっくりですが。
・ポケットがかさばらない。
・ごはんが美味しくなった。
・お金がかからない。1日2箱だったのでタバコの代わりに毎日本が買える。
・喫煙所を探さなくてすむ。
・のどをしょっちゅう痛めてたがそれがなくなって体調がいい。
・体が軽い。
http://webrocketsmagazine.com/entry/20111209/html-code-generation-using-excel.html
http://mattn.kaoriya.net/software/vim/20111215034338.htm
http://d.hatena.ne.jp/takuya_1st/20111217/1324105198
真のプログラマーなら単純なHTML生成するのにテキストエディタは使わないよ。単純なHTML生成が必要なプログラマーなら、プログラムでやるでしょ。いちいちプログラムを書くのがだるい？いやいや、単純なHTMLの生成が必要なプログラマーなら、リストやディクショナリといった汎用的なデータ構造やCSVファイルといった汎用的な形式のファイルから、自動的にHTMLを出力するライブラリぐらい書いてるでしょ。わざわざ同じ作業をやるなんてめんどくさい。それにそのプログラムは他でも使うことができるしね。しかもPythonやRubyならほぼシェル感覚で使える。わざわざテキストエディタを使って同じ作業をする必要性はないね。真のプログラマーなら単純なHTMLの生成はプログラムでやるでしょ。プログラマーなんだから。
これは、「（他のライブラリが必要な）特殊なモジュール使ってますか？」「環境依存の設定ありますか？」とかを包括した質問かもしれない。
（コンパイラオプションで関数を使う／使わないって切り替えする奴とかで、おまじないとして大量の定義が必要な仕事場はあった）
使ってる検査ライブラリが、ドライバのライブラリを静的リンクしてた時、「なんか（インストールとか）必要なの？」って聞いたこともあるよ。
「この○○ってライブラリが参照してる××ってなに？」じゃなくてね。
まぁ、言語仕様は知ってるけど、開発環境の仕様は知らないって人、多いよ。
んで、そういう事についての感性が低い人は、確かにいる。
Webサービスやアプリをつくって公開するのが好き。またブログもよく書く。その為、非プログラマーの人達にもよく知られているので”スーパープログラマー”のような評価で持ち上げられがちだが、プログラマーたちの評価はそれほど高くなくそのギャップに悩んでいる。よく起業する。
自分が使っているプログラミング言語(やエディタ)のライブラリを作って公開するのが好き。プログラミング活動が自己実現に直結したエコシステムも持っている。勉強会やオフ会によく行くので友達も多く、望んだ職場に出会えることが多い。延々とtwitter をやっている
大企業の製品の開発現場に生息する。業務の為に必要なプログラミングを学習したので目的に特化したスキルをもっている。その反面、自主的な学習意欲は少く体系的な知識がないので潰しがきかない。プログラミング以外が好き
todesking
上っ面じゃなくてちゃんとわかっている人教えてください。
▼モバイル版「Flash Player」の開発中止をどう見る？
http://japan.cnet.com/panel/35010348/300015677/
▼Adobeはなぜ失敗したか, Flash-Playerの敗退は歴史の必然だった
http://jp.techcrunch.com/archives/20111109why-adobe-failed/
今後来るhtml5をもてはやす必要もなく、
で“既に代替されている”
html5厨の中にはこのあたりごっちゃにして歓迎してるやつが多数いる
くどいけど、その他の機能はjsとかcssとかhtml5周辺の独自仕様で
解決してることが多いからな！
普通にhtml5が覇権取るにはオーサリングツールがいるんだぞ。
全部含んでるんだ。
html5が現状見えてるのは、
までだ。
「描画系の機能でflash(flex sdk)同等の仕様を用意することになるだろう」
ってだけじゃ劣化flashすぎんだろ。
あとadobe終わったっていってるやつ、
それを一社じゃなくブラウザつくってる各社が実装するんだからな・・・
お前らがflash嫌ってるのと同じ問題が発生して、
flash殺すのはいいけど、html5を中心とした代替環境できんのに何年かかるんだよ。
あと、リッチインターフェース作るのに、いつまでもなんのサポートも受けれないような
jsライブラリ組み合わせて、必死にカスタマイズとデバッグしなきゃいけないのかよ！
業務系のuxデザインつくっていくのに、flex使おうか、html&css中心で行こうか悩んでんだ。
誰か何かアドバイスくれよ…
flexは良いところが多くて工数も減るし、どこかでadobeの5オーサリングツールに乗り換えられるだろうから
普通のweb屋としては、htmlとjsで苦戦しながらも自己責任でスクリプトチマチマいじってる方が、
他にもこの中途半端な状況に困ってる奴いるだろ！
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
PCの方が開発は楽で、ダウンロード販売を使えば、物理的にも流通的にも中間マージンを大幅に排除できて
ゲーム会社は利益を得られやすくしかも価格も抑えられると思うんだよね。
PCの問題として、昔はメーカーマシンのゲーム描画能力が貧弱過ぎるという問題があった。
しかし、今はPC全体の性能向上とオンボード3D性能の向上によって、ある程度の描画能力までなら問題がなくなりだしている。
一方コンシューマでは、据え置き気に比べて絶対性能が微妙な携帯機が威力を発揮しているなど、ゲームそのものに求められる描画能力が昔程重視されなくなっている。
相対的にメーカーマシンでも要求されたゲーム性能を満たしやすくなっていて、障害はなくなっているように思える。
PCを持ってない人は少ないと思うけど、テレビ持ってない人は増えているのでは。
テレビとゲーム機を両方買うとかなりの出費で、スペースも食う。PCを拡張すれば問題ないけど…。
十分な開発環境やライブラリ、2Dツールはもちろん統合3Dツールまで無料で手に入るようになり、ゲーム製作の敷居はすごく下がっていると感じる。
http://anond.hatelabo.jp/20110907193725
を書いた増田だけど久しぶりに増田にログインしたらトラバがついてたんでお返事。
http://anond.hatelabo.jp/20111005112736
見てるかわかんないけど。
これはそのつもりで書いてます。ブラックリストホワイトリストという言い方ではなくて、オプトイン、オプトアウトという考え方で。元記事にも書いてあるんだけど、日本の法律ではオプトアウト方式は認められていないので、合法にやるにはオプトイン方式でないと無理だと思っています。
オプトアウト方式が認められていないのに、著作権違反はいくら大規模にやろうと親告罪であると言うゆがみがあると思っているんで、個人的にはそこは改善されるべきだと思っているけど。フェアユース導入なり、大規模著作権違反の事案は摘発が可能なようにするとかバランスを取るべきだと思う。
例えば自炊依頼のために許諾を求める業者は、その結果に責任取れるんだろうか？
その責任の所在を、自炊業者に求めるなら、法的リスクと収益で割が合わないだろうし、事故として上限免責されてしまうなら、許諾するのが馬鹿らしい。
これはそもそも自炊業者には責任は発生しないと考えます。許諾を得ていればもちろんのこと、許諾を得ていない真っ黒な現状でも。
電子書籍でもDRMフリーで販売されているものがありますが、そのDRMフリーの電子書籍が違法に流通して実害が出たとしても、DRMフリーの電子書籍を正規に許諾を受けて販売した業者は責任を問われないのと同じです。違う言い方をすればコピー機を有料で貸し出しているコンビニや、ドキュメントスキャナ、コピー機を製造している業者が違法性を問われないのと一緒です。もちろん違法流通のために特別な何かをしている場合は別だし、幇助レベルではない別の違法行為があれば違います。
実際に裁判で訴えられるとしても訴える側が自炊業者側に違法性を予見して未必の故意があった等と言う事を証明しなきゃならない事になるわけだけれど、そんなことはまず無理だと思う。
証拠（因果関係）が希薄だから自炊業者無罪なら、余計悪い方向だ。
ちなみに。
電子透かしを求めようが、何をしようが、業者が故意に行うデータ流出は防げないし、アフィリ等で流出の方が儲かる事情があれば簡単に崩壊する。
これは信頼関係を築いていくしかないと思います。と言うのはこれ電子書籍に必ずついて回る問題だし、昔は書籍についても同じ問題がついて回っていたから。と言うのは、販売量は業者しか分からないと言う事だからです。
最近の本でも伝統がある出版社の本なら奥付に「検印廃止」って書かれているのを見る事ができると思いますが、これは何かと言えば昔は出版社が作者に内緒でたくさんすって売っているのではないか（いわゆる偽版）を防ぐために、著者が検印を押した紙で確認するという事が行われていた名残です。同じ版をつかって作者に内緒で刷って裏流通させているんじゃないかと言う疑惑があったんですね。また電子書籍でもDRMがあろうがなかろうが、電子書籍販売業者が横流ししていると言う疑惑は当然ついて回ります。
もちろん、「状況が同じだからって自炊業者が問題無いわけじゃないだろ」って話は当然あって、だからベンチャーなんかがぽっと出でやるのは難しくて、信頼のある印刷業者やら取次やらが既存の自炊業者をノウハウごと買収してやるのがいいんじゃないかと言う〆にしてあるわけです。
実は元記事では触れてなかったけど、ここにある需要があって商売になるかってのが最大の問題としてある。でこれについてはなかなか難しい。
今後電子書籍は黎明期を脱してくるだろう思う。Amazonが来るぞとか言う印象論ではなく、
などが主な理由で、つまりは大手出版社が本気になりつつあるからと言う事なのだけれど、だけどこれは新刊や比較的近年に発行されたものに限ると思うんだよ。
一方今自炊したいという人の話を聞くと、だいたい2種類需要があって
と言う所なんだけど、電子書籍が普及してくると前者の需要は尻すぼみになると思う。と言うかむしろ成りつつある。わざわざ同価で販売されている電子書籍をDRMがあるからといってわざわざ自炊する人間がどれだけいるのかというとそんなにいるとは思えない。
一方後者の需要なんだが、こちらはむしろ電子書籍が普及すれば普及するほど増加してくるんじゃないか。今でも切実にスペースが足りない人は多い。たとえば私もそう。で、電子書籍の環境がだんだん使い物になるようになってくると、その欲求はどんどん膨らんでいくと思う。
また電子書籍で本を読むことが当たり前になってくると、古い蔵書を読みたいという時、紙じゃなくて電子化して読みたいという需要もどんどん増えてくると思っています。
しかし、新刊書籍については需要もあるし、DTPデータも丸ごと保存された状態から発刊と同時に業務フローの一環で電子データを作る事ができるからコストは安くすむし、どんどん電子書籍が出るだろう。
一方、古い書籍はどうだろう？DTPデータが消えてしまっている、あるいはそもそもDTPで作られていないとかで電子書籍を作るコストも新刊書籍より高い。しかも需要はニッチだから作成コストがとれない。だから全ての書籍をカバーすることなんてとうてい無理だ。ただこう言った事情から電子書籍が出ないのであって、権利問題がある訳ではなかったりするのも多いでしょう。電子化するコストは多くの人が言うほど安くはありませんし。
そこに、自炊業者と言うのは存在していけるのではないかと思うのだけれどどうだろう。確かに今の違法でありつづけることで必要なコストを払わない対価ではとても無理だが、たとえば引っ越し業者などと提携して、貴方の蔵書丸ごと電子書籍化しますといったサービスとしてはありえるのではないか、許諾があるものは自炊し、許諾がないものは既存の電子書籍がある場合はそれを案内しつつ、どうしても許諾がなく電子書籍化もできないものは返却する。（希望に応じて裁断だけ手がける）電子書籍化の要望が強いが権利者不明などの理由によってできないものは裁定制度を利用するといった電子ライブラリ構築エージェント的になれないかと思うわけです。
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html
で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。
（2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。
Stevey の Google プラットフォームぶっちゃけ話
僕は6年半ばかり Amazon にいて、それから今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社を比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務部が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。
つまり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほか。ばかにしに行くんじゃなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベースも悲惨そのもの。エンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。
公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシンの情報を RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。
僕が思うにその pubsub システムとライブラリ管理システムが、まさに Amazon が Google より優れている三つのうちの二つだ。
早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかも知れない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場で競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。
でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。
Jeff Bezos は悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple の主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイトを理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。
マイクロマネジメントが Amazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから、公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色いポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションとデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通のコントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
ハハ！。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal（ごにょごにょ）Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなはいっぱいの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。
とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
といった話題がネットで飛び交っていたが、
その二択で悩むようなら大企業選ぶべきだ。
といった比較であるが、これはどちらが有利といった話ではない。
ゆえにライバルだらけ。
B社は仕事がなくなるか、あるいは値下げせざるを得なくなる。
ベンチャーの競合は、数百社が敵だったりする。
大企業はオトナなので、「これ以上値下げしたら儲からないから」
という線を必ず引くが、ベンチャー数百社の中には、
身を守ることになり、お金につながっているのだ。
会社が潰れたらアウトじゃん、とデメリットを考える人もいるだろう。
「どこでも使える技術＝国語＋ロジカルシンキング」を教えるからだ。
適切な返答をする。これさえあれば職に困ることはない。
Ajaxが出始めたのは6年前、JQueryは5年、node.jsは2年だ。
数年前はSQL+memcachedが騒がれていたのに、今はNoSQL一色だ。
成長したと言えるのだろうか。
ベンチャーは、余裕がない。
連続になる日もある。
最大2年間の休職を許したりする。これならば、
病気になっても戻ってこれる可能性が高くなる。
大企業はつまらない仕事だらけで、ベンチャーは楽しい仕事だらけ、
というイメージで話している場合があるが、本当にそうだろうか。
自社サービスで楽しいことをやっている会社はほんのわずかである
ということを忘れてはいけない。
受託開発もこっそりやっていたりする。
現在はパチスロのCGを作っているのをあなたは知っているだろうか。
数年後、多くは潰れているか
何でサイトなんだ？？
「すべてのアプリが、自身が必要とする実行環境を必ず用意する」方が、一般市民御用達のWindowsではユーザーにやさしい。
そんなもん管理システムを下敷きにしたラッパーを用意すればよくね？？
って言うようなパッケージは、自力で解決しろよ、と思うんだが？
上位レイヤーの話はしてないんだけどね。
「Python」でも良いし、「JRE」でも良いし、「HSP」でも良いよ。
「正しい申告」と言うのは、自身が必要とする実行環境についての、正しい申告。（リビジョンとかね）
「すべてのアプリが、自身が必要とする実行環境を必ず用意する」方が、一般市民御用達のWindowsではユーザーにやさしい。
配布サイトが変わる実行環境やライブラリって結構あるが、それは「アプリが独自に解決」すべきなのか。
それとも、それらの実行環境を配布する人は、逐一公的な実行環境としてマイクロソフトに報告しなきゃならなんのか。
１年前の記事がリンクすべて死んでるとかざらにある。
って言うようなパッケージは、自力で解決しろよ、と思うんだが？
ここがどういうことを言ってるのかちょっとよくわからないんだけど、
アプリ間の依存関係はまぁそれほど問題にならないからどうでもいいかな。
下位レイヤがほんと酷い。
dllだのランタイムライブラリだの、スクリプト言語の実行環境だの何だの
パッケージ単位で全部解決させようとするからどのインストーラにもいちいちpythonとか入ってやがる。
逆にその辺がまとまってないソフトを入れようとすると、依存関係を自分で解決する必要があって大体ハマる。
駄目なプログラマはとにかく人に親切でない。この程度のデバッグならと思えるようなこともしない。金銭的な面だけじゃなくて、「ずっと担当しているプログラムに対してこの程度の手間なのに」と驚くようなことすら断ったり。
これはおそらく、デバッグをして見つかる不具合修正の費用対効果を計算できず、自分のメンツを重視するからだと思う。とあるプログラマにお願いを断られたこと（だいたいプログラマ個人の作業として30分もかからないこと）で、私は落胆し、数万円くらいのバイトを紹介するのをやめたことがある。数万円は曲がりなりにも派遣でプログラミングをしているプログラマにしてはたいしたことがない数字かもしれないが、それでも30分くらいの手間で、数万円のバイトを紹介してもらえるなら、悪くない投資のはずだが。
駄目なプログラマはとにかく無駄遣いをする。プリミティブな定数で済むところでも、かまわずにオブジェクトを生成する。メモリ少ないのにいいのか、と私が思うようなことでも、無駄なものに考えなしにメモリを使う。
駄目なプログラマはメモリを使わない。無駄遣いはするが、メモリは使わない。
うまくいえないが、メモリを使う勘所を意識していないのではないか。キャッシュを作ってメモリ上に保持すべき所で毎回 DB にアクセスし、効率的なキャッシュで DB アクセスを減らして高速化を行う事に気が回らない。
いわゆる memchached もそうだが、実績のあるライブラリなどを利用するための準備には時間とお金を惜しむ。そのことでより開発が楽になることを知らないからだ。
駄目なプログラマは周りを大切にしない。エンバグばかりする代わりに、同僚のテストは手伝わないし、私のようなプログラマにバグのパッチを送ったりは決してしない。
これは、その行為を無駄遣いだと思ってるのかな、と思ってたのだけど、そこまで合理的ではない。ただ周りの好きな人間を大切にしなくてもかまわないという気持ちのようだ。
駄目なプログラマは勉強をしない。とにかく本を読まない。講演を聴かない。人から教えてもらわない。
勉強したことが無駄にならないことをわかっていないからかもしれない。
駄目なプログラマは書くより語る。末端で参加しただけのプロジェクトの自慢話をしたりはしょっちゅうだ。そして自分のプログラムを書こうとしない。
プログラムを書いて学ぶメリットより、自分の話をするメリットのほうがでかいと思っているわけだ。ペラペラ自分の話ばっかりする駄目なプログラマは多い。
駄目なプログラマは挑戦をしない。やったことない言語や、苦手なことをあえてやってみようとしない。たとえば、勉強会なんかにいかない人たちだが、たまたまいったら流行っている言語をやってみようなどということはない。普通の人が面倒になって見てるだけだったりするのに加わるだけで、積極的に挑戦をしようと思わないことが多い。
失敗するリスクの低さと、経験のリターンの大きさを知らないのだろう。
駄目なプログラマは短期的にポジティブ、長期的にネガティブである。よく駄目なプログラマはネガティブな人が多いと言われるが、実際には、そうでもない。短期的には楽観的だったり不安に思わなかったりすることが多い。避けられるバグをなるべく避けようとする気持ちが少ない。
一方で、将来的に自分がどうなるか、などに関しては驚くほどネガティブである。長期的に悲観になっても無駄だということを知らない。逆に、短期的に「まあいいか」と楽観的になると、のちのちバグが発覚するのを知らないので、目の前のことに対しては真剣に考えない。
私が知っていることをまとめてみたが、実際にまとめてみると驚くほどシンプルである。だがこれを全部できてる人はなかなかいない。
駄目なプログラマになりたいと思っている人は、マネしてみるといいことがあるかもしれない。
※「貧乏人に大量に触れて初めて気づいた8の共通点」http://anond.hatelabo.jp/20110825204218 のプログラマ版です。
【お知らせ】2011/09/07
http://d.hatena.ne.jp/uniqueweb/20110906/1315285545
プログラムは全く得意じゃないけれど最近よく見かけるようになったエロ動画検索を自分でも作ってみたくて頑張ってみました。
近年、インターネットの普及によりエロ動画が自宅で簡単に見れるという素晴らしい時代になりました。
自分が若い頃はインターネットなんてものはなくエロビデオが主流でドキドキしながらレンタルビデオ屋に行き、可愛い女の子がレジにいない隙を見計らってお兄さんにパッケージを伏せて空箱を渡しビデオを借りたものでした。
お兄さんにビデオの空箱を渡そうとした時に可愛い子がレジに戻ってきて焦って渡すのをやめてものすごく変な動きをしながらエロビコーナーに引き返していくなんてことも多々ありましたｗ
僕のお気に入りといえば「白石ひとみ」や「あいだもも」といった女優でよく借りてました。エロビを借りるということがものすごく恥ずかしい時代？年頃？でカモフラージュに普通のビデオと一緒に借りるということもしていました。それはそれは大変な思いでオナニーしてたんです！
しかも、ビデオデッキ自体が貴重な時代でリビングに一台しかないのが当たり前でした。
深夜家族が寝静まってからヘッドフォンとビデオを抱えリビングに行き暗がりの中でヘッドフォンをテレビに差し込んでビデオの再生ボタンを期待に胸をふくらませながら押したものです。いいシーンを何回も見るためにビデオを巻き戻すんですが、ビデオを巻き戻すガチャンガチャンという機械音で家族が起きてこないか？とかそれはそれはドキドキしながら見てました。一仕事終えたあとヘッドフォンを外したらジャックが外れていて大音量で喘ぎ声が響き渡っていたなんてこともありました。誰も起きてこなかったのは優しさなんでしょうか？ｗ
さて、大分前置きが長くなりましたがエロというものはものすごい技術発展させるものだと思います。エロのおかげで日本でビデオは普及しエロのおかげで日本でインターネットはものすごく普及したと言っていいと思います。自分もエロを通して技術の発展に貢献し自分自身のスキルアップになれば。という高い志を持ってこのサイトを制作しました。決して自らのオナニーライフの充実と性癖を充たすため作ったわけではありません・・・ｗ
※2011.08.07 利用中のサーバーに障害が発生しているようで現在サーバーに接続できない状態となっています・・・
サイト名の由来は抜きネタからきています。抜きネーター、ヌキネーターという感じですｗ
エロサイトの制作工程を日記にしてみたんで良かったら読んで下さい。そしてこのサイトを使って夜いろいろと励んでくれたら嬉しいです。
まず前提条件としてお金をほとんどかけたくない。アダルトサイトであるということから
月の予算は5000円以内で考えていたのでけっこう探すのが大変でした。
日本でアダルトサイトを許可している所はかなり限られていてさらにやりたいことができるのは
専用サーバーかVPSしかないのでそうなると専用サーバーは予算オーバーなので
VPSで探すことになり検索しまくってはじめに見つけたVPSはKAGOYAのVPSだったのですがβ版で募集を締め切っていて泣く泣く諦めました。
KAGOYAはかなり評判がいいみたいなので使ってみたかった。
次に見つけたのが○○○VPS。海外サーバーで日本語サポートがあり転送量の制限なしディスク容量100G
月1300円程度で借りれるということで初期設定費用に5000円程度かかりましたが借りてみました。
結果、ここは最悪でした。
あまりの酷さに1ヶ月で解約。
よく調べてみたら評判がものすごく悪い某VPSの再販らしいです。
もう失敗したくないと思い今度は比較的有名な海外サーバーLINODE。
iptablesの設定でどうしてもうまくいかなくて拙い英語でメールしてみたら
10分しないうちに返信がきました！
メールに書かれているとおりにコマンドを入力したらあっさり解決。
担当のブライアンはなぜか分からないけどとてもフレンドリーで親切に感じましたｗ
LINODEは複数のディストリビューションから好きなものを選択できるので
とりあえず、64bit版を選択。
一番面倒だけど重要だということで
Tripwire
ほんとに面倒でした。
はじめはmysqlにストレージエンジンgroongaを使おうと思ったのですが
初めに借りた最悪なVPSはOSが32bit版だったのでgroongaがのソースが見つからずなぜかと思っていたら
どこかで見つけた記事で32bit版ではgroongaの性能を発揮しきれないということで32bit版の提供をやめてしまったらしいと書いてたので
じゃあ、sennaにするかということで最悪VPSでsennaをインストール。
その後LINODEに変更したのでOSに64bit版を選択し念願のgroongaをインストール。
しかし、調べてみると
プログラムもそれに合わせてその都度書き換えたので2度手間どころか3度手間4度手間でした・・・
まず
そして下記の順番でインストール
rpm -ivh mecab-0.98-tritonn.1.0.12a.x86_64.rpm
rpm -ivh mecab-ipadic-2.7.0.20070801-tritonn.1.0.12a.x86_64.rpm
rpm -ivh senna-1.1.4-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-shared-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-client-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-server-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-devel-5.0.87-tritonn.1.0.12a.x86_64.rpm
my.cnfの設定をして終了
で肝心の全文検索ですがデータ件数が5万件程度で少ないせいなのか、あいまい検索と比べてそれほど速さを実感できなかったです・・・
でもきっとすごく速くなったはず！
ちなみに「麻美ゆま おっぱい」で検索した場合、0.01 secで結果が返ってきました。
さて、動画データの作成ですがいくつかのエロサイト等制作記事でもあるようにスクレイピングということをします。
スクレイピングとはWEBサイトから特定の情報だけを取得することでネット上にあるサイトをクロールして必要なデータだけを拾ってデータを作るといった感じでしょうか。
スクレイピングのプログラム自体は以前にTidy関数を使って為替データを10分おきに取得するような物を作ったことがあったのでそれほど時間はかからないかなと思ったのですがけっこう時間かかりました。
スクレイピングにはTidyとhtmlSQL、それにPHP Simple HTML DOM Parserを使いました。
SQL みたいな文法で HTML を抽出する PHP のライブラリ
htmlSQLよりアツい!?jQueryみたいにセレクタでHTMLをparse(解析)する「PHP Simple HTML DOM Parser」
３つの中で抜群に使えるのはPHP Simple HTML DOM Parserだったんですが
ループ処理させるとメモリがすごいことになって今回のようなスクレイピングに向いてないみたいで
結局、htmlSQLとTidyの両方を使ってスクレイピングしました。
両方ともPHP Simple HTML DOM Parserに比べるとうまくデータの取得ができないことが多く残念な感じなんですが他に選択肢がないので・・・
使える順に並べると
といった感じかもしれません。
おおまかにデータを取得して正規表現で特定データを抜き出しました。
http://affiliate.dmm.com/link.html
利用可能な物はパッケージ画像、サンプル画像（縮小）と書かれていたのでそれに従い画像を利用。
注記に※ユーザーレビューは引用いただけません。とだけ書かれているのでそれ以外は引用ありと判断して説明文とタイトルなどを利用
女優データとジャンルデータ、DVDデータ、を紐付けたデータベースを作成し検索ワードに応じて検索結果に関連する商品を表示させるようにしました。
現状、売り上げ0で意味があるのか分かりませんけどｗ
エロサイトということで多少はチューニングとか設定とかしないとまずいかもと思い色々調べて設定しました。
やったこと
KeepAlive On MaxKeepAliveRequests 60 KeepAliveTimeout 3 <IfModule prefork.c> StartServers 7 MinSpareServers 5 MaxSpareServers 10 ServerLimit 30 MaxClients 30 MaxRequestsPerChild 4000 </IfModule>
様子見ということで2日間で設定してみました。
query_cache_limit=1M
query_cache_min_res_unit=4k
query_cache_size=16M
query_cache_type=1
とりあえずこんなところを設定してみましたが、爆発的なアクセスがあるわけでもないので有効なのか今のところ分かりません(-_-;)
Apache Benchでテストはしてみましたけど問題はない感じですが実際にチューニングができているか分かりません。
プログラマーとして有名なゆうすけさんのサイトとgoogleを参考にしました。
シンプルで使いやすいようにしようと思いこのデザインにしました。
クロスブラウザはIE7、firefox3、chromeで行いました。
可変ものって作ったことなかったんですがけっこう面倒なんですね。
ブックマーク機能とメニューの折りたたみ機能、検索結果の表示方法切替を作りました。
まず、ブックマーク機能ですがログインなしで気に入った動画をブックマークできるようにしました。
ブックマークに追加した動画はブックマークページで確認できるようにしました。
cookie機能を利用したらいけると思い色々調べてjquery.cookie.jsを利用。
保存したクッキー情報を呼び出してphpに渡して処理し指定要素にブックマーク一覧をloadメソッドで表示させるという感じです。
$(function(){ $("#youso").load("xxx.php"); });
メニューの折りたたみ機能は人気AV女優やAV女優別、人気タグなどをそのまま表示させるとずらっと長くなって邪魔だったのでつけました。
これには同じくjquery.cookie.jsを利用しました。
参考サイト：http://blog.caraldo.net/2009/03/newjqqookiemenu.php
検索結果の表示方法切替にはZoomer Galleryを利用しました。
参考URL：http://phpjavascriptroom.com/?t=ajax&p=jquery_plugin_zoom#a_zoomergallery
検索結果ページで表示される
[ここの画像]
××× の検索結果
44件中 1～10件目を表示
ここの画像の部分をクリックするとgoogleイメージ検索みたいに一覧でイメージ表示できるようにしてみました。
基本的に動画の埋め込みを許可しているサイトのみプレイヤー表示をしそれ以外は画像を表示し動画データへリンクするようにしました。
埋め込み部分はあらかじめそれぞれのサイトに対応したプレーヤー部分のコードを記述しVIDEOIDの部分に置き換えるような形にしました。
XVIDEOSを例にすると
XVIDEOSの場合かならず動画のurlがhttp://www.xvideos.com/videoXXXXXX/のようになりますのでXXXXXXの部分を
VIDEOID部分に置き換えるようにプログラムを組みました、
埋め込み部のソース
>||<object width="510" height="400" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" ><param name="quality" value="high" /><param name="bgcolor" value="#000000" /><param name="allowScriptAccess" value="always" /><param name="movie" value="http://static.xvideos.com/swf/flv_player_site_v4.swf" /><param name="allowFullScreen" value="true" /><param name="flashvars" value="id_video=VIDEOID" /><embed src="http://static.xvideos.com/swf/flv_player_site_v4.swf" allowscriptaccess="always" width="510" height="400" menu="false" quality="high" bgcolor="#000000" allowfullscreen="true" flashvars="id_video=VIDEOID" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /></object>
||<
その他の動画サイトもURLの一部分のデータを使っているので同様の処理をしました。
実際の作業は２、３週間ですが色々調べる時間が多くて制作に2ヶ月くらいかかりました。
自分でエロ動画検索を作ってみて有名プログラマーさん達がいかに優秀なのか思い知らされました。
全くWEBの知識がない人で４、５ヶ月ですごいの作っちゃう人とかもいるみたいですし世の中広いな～と思います。
大分、色んな知識を得ることができました。
これからプラグラムを勉強しようと思う人はぜひエロサイトから入ってみて下さい。
そんなこんなで？頑張って作ってみたエロ動画検索、良かったら使ってみて下さい。
これで少しは技術の発展に役立てたでしょうか？ｗ
P.S エロサイトを作っていてはじめは楽しくて興奮しながら作ってたのですが最後の方はエロい物を見ても全く反応しなくなりましたｗ
不能ではないんですけど・・・今現在も性欲が著しく減退しております・・・
そしてスーパーpre記法がうまういかないのはなぜ？はてな匿名ダイアリー初投稿で全然分からない・・・
そしてそしてプログラマーさんとかデザイナーさんとかエロい人とかお気軽にお声をおかけ下さい。
【お知らせ】2011/09/07
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
RubyのSymbolと文字列の違いを研究室の輪講用に書いたのですが，折角なので公開したいと思います．
元々学部生に対する輪講用に書いた物なので，若干上から目線ですがご了承ください．
文字列とSymbolはよく似ています．プログラマから見ればどちらも文字列です．違いを一言で説明すると『プログラムが扱う』文字列か，『プログラマが見る』文字列かの違いです．例えば変数名は『文字列』ですが，rubyのオブジェクトである『文字列』ではないですよね？
例えば，今あなたがC言語でお絵描きライブラリを作っているとしましょう．その中に，色で塗りつぶすfillという関数があり，色を青・赤・緑の3色から選べ，fillの引数でそれを指定できるとしましょう．
fillの引数の設定方法として一番単純なのが，0を青，1を赤，2を緑として，0〜2で選択させる方法でしょう．しかし，それでは，どの数値が何色か覚えないといけないし，fill関数を知らない人から見れば，どういう意味の引数かすらさっぱり分かりません．
ではどうするかと言えば，普通はBLUE = 0, RED = 1, GREEN = 2と適当に定数を設定して，その定数を引数で指定させますよね．
こうして，fill関数の引数が意味の無い数値から意味のある文字列に変わったことによってプログラムが分かりやすい物となります．さて，ここで注意してほしいのは，ここで言う文字列はプログラムが扱うオブジェクトとしての文字列では無いということです．fill関数の引数として，"BLUE"，"RED"， "GREEN"などとC言語の文字列を渡すということは普通しませんよね．それは，ここで言う文字列は，あくまでプログラマがプログラムコードを分かりやすくするために必要な文字列であって，プログラムがオブジェクトとして扱う（例えば，長さを求めるとかする）文字列ではないからです．
分かってきたでしょうか？
プログラムコード上では（つまりプログラマから見れば）どちらも同じ文字列（文字の列という意味で）ですが，実際に動くプログラムから見れば単なる数値と本物の文字列という大きな違いです．結局，fill関数の引数の具体的な値は何でもいいわけです．プログラマから見て文字列であればそれだけでよく，プログラムが動くときの実際のその中身は何でもいいわけです．これのために存在するのが，Symbolであり，:fooとひとたびSymbolを作成すれば:fooの実態は適当な数値となります．（この数値がいくらかなんていうことはもちろん気にする必要はありません）
そして，もちろん同じプログラム上では:foo == :fooはちゃんと成り立ちます．もうここまでくれば，Hashのkeyとして文字列でなくSymbolを使う理由が分かりますね．Hashのkeyはあくまで，プログラマが見る（プログラムコードを分かりやすくするための）文字列であってプログラムが扱うオブジェクトとしての文字列では無くて，keyの実際の値は何でもいい，からですね．（特別な場合を除いて）Hashのkeyに対してrubyのStringのメソッドを使うなんてことは無いですよね．
しかし，他の軽量言語ではSymbolなどなくHashのkeyとして普通に文字列を使うことが多いです．では，なぜrubyだけSymbolを使うのでしょうか．
その答えは一言でいうと，rubyの（プログラムコード上に直接書かれた，つまりリテラルの）文字列は他の言語と違いimmutable(不変)でない，からです．実際，pythonやjavascriptの文字列(リテラル)は破壊的に変更することはできませんが，rubyの文字列は破壊的に変更することができます． （'abc'.concat('d')の様に）
これがどういう違いを生むかというと，コード上に直接現れる文字列がimmutable(不変)であるならば，実行時に一つだけそのオブジェクトを作成し，後はそれを使いまわすという最適化ができます．
そうした時，Hashのkeyの様なプログラマから見た文字列というのは，プログラムコード上のリテラルとして現れるわけですが，これらは実行時に一つだけオブジェクトが作成され（特にコード上に現れる同じ文字列は全て一つのオブジェクトにまとめると），それらの比較はそれらに対する参照（そしてこれは大抵メモリのアドレスなど単なる数値）の比較で済むので，結局Symbolと同じ様な働きをするわけです．
本当はプログラマが見るためだけの文字列だけど，それをオブジェクトとしての文字列としても，Symbolと同じ様な働き，パフォーマンスが得られるならば，別にオブジェクトとしての文字列であってもいいわけです．
繰り返しになりますが，プログラマが見るためだけの文字列は，その中身・実態は何でもいいわけですが，その実態がオブジェクトとしての文字列でも十分なパフォーマンスが得られるならば，別にオブジェクトとしての文字列でもいいわけです．
さて，rubyに話を戻しますと，rubyはコード上に現れる文字列であっても，実行時にそのコードを通る度に毎回新たな文字列オブジェクトを作成します．
（以下のプログラムを動かすことで確認できる．）
def foo 'foo'.object_id end p foo, foo
つまり，rubyでは文字列が可変であるため，先に述べたような最適化ができない（または難しい）ので毎回新たな文字列オブジェクトが作成されるのです．
こうなると，先ほどの話とはうってかわって，プログラマが見る文字列はその実態は何でもいいのに，それを文字列リテラル（rubyのオブジェクトとしての文字列）にしてしまうと，毎回毎回文字列オブジェクトが作成されてしまうという非常にばかばかしい状況になってしまいます．我々はそれらの文字列オブジェクトに文字列としての操作は一切施さないのにも関わらず，です．
こういうわけで，rubyではプログラマが見るためだけの文字列にSymbolというruby特有のものを使うのです．
もちろん，プログラマが見るためだけの文字列を全て定数として（そしてもちろん中身は適当な値で）定義しても構わないわけですが，Hashのkeyとかで数多くのプログラマが見るためだけの文字列が現れることを考えると，とてもじゃないですけどそんなことは面倒でやってられないですよね．ですので，実行時に自動で適当な値にしてくれるSymbolというものが存在するのです．
以上で，Symbolについての説明を終えます．以下は蛇足です．
最初の方で出てきたfill関数をrubyで実装しようとしたとき，青・赤・緑の各色はその実際の値はなんでもいいのでrubyのSymbolを使って:blue, :red, :greenとしてもいいのですが，ライブラリとかでは大抵ちゃんと定数として定義されていることが多いです．
これは恐らく，定数として明示的に定義することで値の存在を明示でき，ドキュメント化の際にも役立つことによっているのでしょう．
しかし，あくまでこれは外部に公開するようなライブラリでの話であって，自分が使うちょっとしたプログラムならこういう場面でも精力的にSymbolを使っていってもいいと思います．ちなみに，僕ならSymbolを使います．
Symbolだと定義もいりませんし，定数は大文字ですから打つのが面倒ですし，あまりソースに大文字が入ると見た目がすっきりしません（主観）．
Symbolは非常に便利なものですので，その意義・用途を十分に理解して，Hashのkeyにとどまらず様々な所で使えるようになりましょう．
http://anond.hatelabo.jp/20110707195830
初音ミクのLAコンサート、外国人感想その４。今回は初音ミクという存在についてかなり真正面から書いたものを紹介する。筆者はコンサートだけでなくアニメ・エキスポで行われたいくつかのパネルにも参加したようで、日本から行った関係者の発言も引用しながら初音ミクとそれを取り巻く現象に関する考察を述べている。これを読めば「初音ミクとは何か」について一通りもっともらしい話ができる程度の情報が盛り込まれた、なかなかいいまとめだ。
urlは以下の通り。
ヴァーチャル・ディーヴァ（仮想の歌姫）になるということは、正確にはどういう意味を持つのだろうか？ 初音ミクの人気について真に理解できるようになる前に、彼女が正確には何者なのかを確認するのがおそらくは最適だ。しかしながらこのテーマは思いのほか扱いが難しい。最も簡明な言い方をすれば、彼女は明らかにセガとヤマハによって発展してきた音楽制作ソフトのために藤田咲の声を録音しデジタル化した商品のパッケージ用にデザインされたキャラクターだ。だが同時に、彼女が本当の意味では存在していないという主題もそこにある。我々がミクの歌について話している時、我々は厳密に言えば生きていないものに対して隠喩を使っている。思うに初音ミクとは我々が理解しているより遥かに複雑なものなのだ。
アニメ・エキスポ2011は間違いなくミクの全てを取り上げていた。ミクノポリスは、それがノキア・シアターで行われ、かつ売り切れた唯一のものであった点だけを見ても、明らかに週末最大のイベントだった。他のゲスト――クリプトン・メディアの伊藤博之と佐々木渉、ダンスロイド、及び小林オニキス――はミク登場のおまけとして呼び寄せられた。アニメ・エキスポがコンベンション全体のテーマに「ファンの年」を選んだのは、ただのお遊びではない。結局のところボーカロイドは、ヤマハの剣持秀紀マネジャーがコンベンション３日目のパネルMirai no Neiroで言及したように、ファン、製作者、及び消費者の間にある障壁を切り裂いている。
ミクがいくらか人間っぽい性質を備えているのは明らかだが、同時に彼女の存在はメカニカル（機械的）かつヴァーチャル（仮想的）でもある。歌姫という用語は、技術的な能力をほのめかしているのみならず、高い人気という意味も示唆している。だがミクの人気はピンポイントで捉えるのは難しい。小林オニキスがアニメ・エキスポ2011の２日目にミク・カンファレンスのパネルで発言した内容によれば、彼女の成功は３つの要素に拠っているという。ミク自身、制作過程での自由さ、そして世界規模のインターネットだ。私がオニキスの判断に異論を唱えないのは確かだが、彼の指摘した３つの点をさらに分析すれば初音ミクの存在について興味深い事実が判明すると思う。
トヨタの初音ミク・カローラCMを巡る謎がついに明かされた時、トヨタが特にアニメ・エキスポを念頭に置いて若い客に対する濃密な市場調査を行ったことが判明した。トヨタはアニメ・エキスポ2011に２台のitasha（アニメやゲームのキャラを描いた車）、スタッフチーム一そろい、車の前でミクのコスプレをする可愛い女性、そして小さなカローラの絵の上で可愛らしく微笑む子供のようなミクを描いた何千枚ものポスターを持ち込んだ。ミクはただソフトに特色を出すため作られたキャラに過ぎないという事実にもかかわらず、彼女は自動車企業の公式看板娘となるのに充分なほど人気があった。アメリカにおける市場性の存在にはかなりの疑問があったものの、この宣伝活動はミクにとって大きな一歩だった。
初音ミクの生まれは、実際にはどこの馬の骨とも分からないものだ。彼女は、自身が市場に出ることとなった新しいVocaloid2シリーズの、箱に描かれたイラストとしてその生を始めた。つまるところ、それが彼女の全てだ。だが、日本中の製作者たちが楽しく、突飛で、面白い歌を書き、彼女を描いたり動かしたりすることで彼女に性格を付け加え始めたため、彼女はすぐ自らの命を手に入れた。最終的に彼女のイメージにはネギが伴うようになった。
これがなぜ重要なのか？ ミクが東方シリーズに出てくるキャラとどれほど似ているかについては、おそらく指摘する必要もあるまい。ゲームに出てくるキャラの多くが極めて限られた背景情報しか持たず、それゆえにキャラの性格をさらに発展させるため製作者とは無関係にファンダム自体が自由に想像をめぐらせる余地があるという事実に、東方厨の一部は対応してきた。同じようにミクの仕様に存在する欠落は、歌やビデオという形式をまとった小さな物語の発生を許し、それが巡り巡って単なるキャラを超えた命の有り様をを彼女にもたらした。彼女は利用者が作り出す製品の力に具象化された肖像であり、概念だ。
そのインターフェイスは、比較的直感的に使える。音楽用語を使う代わりにこのソフトは、メロディーを生み出すためピアノの音程と一致したいくつかの棒の上に長い音符を置く。ピッチとテンポは製作者の目的に合うように変更でき、ビブラートと発音も自由に変えられる。完全な楽曲を作るため、ドラム、ピアノ、ギターなど追加の伴奏も付け加えられる。
ヤマハの音声技術開発チームを率いた剣持秀紀によれば、初音ミクは作曲家と歌手にとって伝統的に必要なものを補完する革命的なソフトの顔を務めたからこそ、ヴァーチャル・ディーヴァなのだという。ミクは、かつてデジタル楽器がやったのと同じように音楽世界のあり方を変えたソフトだと、彼は主張する。それが楽譜制作だけでなく、自然言語における発話パターンの複雑さまでまねしようと試みていることを踏まえるなら、おそらくそれ以上のものと言える。
剣持はプレゼンの際に彼の議論の核心を効果的に実証してみせた。まず彼は、人間の耳とって自然な音をボーカロイドに生み出させるのが、どれほど困難かを説明した。次に英語のボーカロイドソフトSweet Annを使い、極めて短時間でハッピー・バースデーのメロディーを生み出してみせた。そしてボーカロイドは単純に人間の声をコピーしようとしているものではなく、その特別な性質故にある意味で音楽の未来を示しているのだと強調した。極めて広範囲なジャンルにふさわしいものにするため、ライブラリを変更することができる。人間の耳が言葉を理解できないほど速いレートで音を生み出すのも可能だ。どんな歌手より長く引き伸ばして歌うこともできる。最も有名な初音ミク曲の一つ、初音ミクの消失を見るだけでいい。ボーカロイド史の比較的初期段階からソフトが持つこれらの側面を製作者が上手く利用していたのは明らかだ。つまりボーカロイドは、その人間に似たヴォーカルと同じくらい、その機械的側面も売り物になっていたのである。
プロの音楽家とアマチュアの双方に販売されることで、ボーカロイドは間違いなく伝統的に音楽に存在した境界線を壊し、比較的音楽知識の乏しい者たちが数千から数百万ものビューを稼ぐ歌を作り出すのを可能にした。アーティストだけでなく、ネットに詳しい個人がよく知っている視聴者に合わせた歌を作ることもできるようになった。
ニコニコ動画が日本におけるボーカロイド活動の主要拠点であることは否定できない。この動画シェアサイトには、他の種の動画ランキングに加えて人気のあるボーカロイド曲のランキングもある。つまりミクの成功は、彼女自身と製作者あるいはソフトの能力だけではなく、日本のユーザーが新たに作られた歌に関する集計された情報を見つけるのが容易である点にも依存している。
ミクの人気は彼女の声だけにとどまらない。ボーカロイド・コミュニティーから抱き合わせでニコニコ上に出てきた他のコミュニティー、例えば「Utattemita」（歌ってみた）、あるいは「Odottemita」（踊ってみた）などは、それらの人気故に今やニコニコのメーンページにある案内バーにそれ自体のカテゴリーを載せるまでに至っている。国境を越えたアニメ及びゲーム・コミュニティーへのウイルスのようなミクの拡散は、製作者及びファンの双方で似ている情報拡散能力に頼っている。
最初の質問に戻ろう：ヴァーチャル・ディーヴァとはつまり何か？
ミクの「仮想性」は要するにオニキスの言う１番目と３番目の要素に起因する。彼女は世界中の数百数千という人々の想像力に根っこを持ち、一方で彼女の側は人間としてのどのような制約も持たない、骨格だけのキャラだ。同時に、インターネットにおけるファンに基礎を置いて成長するボーカロイド・コミュニティーには、それを統制する法的な枠も基盤も僅かしかないという事実故に、彼女は著作権問題からも比較的影響を受けない。実際、利用者が生み出しファンが作り出す素材に対して日本企業が示す寛大さは、英語を使うユーチューブ・コミュニティーが慣れ親しんでいるものに比べれば衝撃的なほどに大甘だ。技術的にも、誰もが歌わせることのできるミクの束縛のない能力は、有名になるためどんな歌姫にも必要とされる人気と広い支持とを提供する。
理論的にはミクのスターダムへの道は、彼女が完全に作り上げられたキャラではなく、その中身が欠落しているという点にある。オタクの行動様式とポストモダンにおける消費パターンに関する東浩紀の著作から引くなら、ソフトの利用者が作り出した歌と動画に描かれた個人的で小さな物語を生み出すためのデータベースとしてボーカロイドと初音ミクが使われている。同時に人間の声を合成することで達成された技術的偉業が、音楽産業内における伝統的役割に新たな裂け目をもたらした。あらゆる種類の消費者、製作者、ファン、音楽家、個人的技術者が、あたかも300年前にルソーが思い描いた政府のように有機的なコミュニティーへと参加している。
初音ミクとは２つの面を持つ現象だと私は主張する。ミク自身は、情報的に遍在する世界の中にいる個人たちの行動様式に根ざしており、世界的コミュニティー総体の想像力によって生み出されている。一方、ソフトは技術的革新による製品で、それは技術がミクの成長にどれほどの役目を果たしているかを過小評価するのが間違いであろうと言えるほど、過去にあった境界を超越してのけた。
ミクノポリスの会場で照明が落とされ、初音ミクが最初にステージに姿を現した時、聴衆の中で数千のファンが上げた叫びを誤解することは不可能だ。堅実で具現的な光学的幻想を生み出すスクリーンに投影され、ミクはボーカロイド商品の箱を彩る二次元画像という起源から、サイエンスフィクションのポップスターへと素早く進化する。来るべき年月におけるボーカロイド発展への将来性を踏まえるなら、Mirai no Neiroパネルこそまさに新たな造語にふさわしい：「未来の音色」
The Nihon ReviewとAnime Instrumentalityはアニメ・エキスポにおけるミク関連のリポートを協力して提供する。コンサートそのものに対する詳細な報告は、Anime Instrumentalityに掲載されているzzeroparticleのエントリーをご覧いただきたい。
使用画像はPixivにある。この画像がコミケット80で使われたことについて、Moccyにお祝いを申し上げる。
http://www.pixiv.net/member.php?id=191242
この週末にアイデアを論じるという楽しみを分かち合った数十人、同僚のライターであるShinmaruとEternal、同じくAlex Leavittと、そして日本へ戻ったミクノポリス/未来の音色のスタッフに、心からの感謝を。
http://dph.ninja-x.jp/index.html
ミクについてよく知らない人へ、ネット上には利用できる多数の英語資料がある。おそらく外国のコミュニティーを本当に制限している唯一の問題はニコニコ動画への簡単なアクセスができない点であろうが、十二分な興味を持っていくらか賢い検索をユーチューブで行えば、ニコに投稿されたほとんど全てを見つけだせる。
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その２「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その３「ミクノポリスのボカレタリアートたちよ、団結せよ！」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その５「オレはAXには行ってないけど、まあとにかく……」
http://anond.hatelabo.jp/20110711212701
初音ミクLAライブ、外国人感想その６「ミクノポリス：７月のクリスマスと世界征服」
http://anond.hatelabo.jp/20110712205546
初音ミクLAライブ、外国人感想その７「AX11：ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その８「ミクノポリス：コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その９「アニメ・エキスポ：初音ミク」
http://anond.hatelabo.jp/20110715222900
初音ミクLAライブ、外国人感想その10「アニメ・エキスポ2011（抄訳）」
http://anond.hatelabo.jp/20110716194029
初音ミクLAライブ、外国人感想その11「世界は彼女のもの：初音ミクはいかにして全てを変えたのか」
http://anond.hatelabo.jp/20110717201147
初音ミクLAライブ、外国人感想その12「アニメ・エキスポ2011でのボーカロイド体験」
http://anond.hatelabo.jp/20110719031316
初音ミクLAライブ、外国人感想その13「ミク：日本のヴァーチャル・アイドルとメディア・プラットフォーム」