はてなキーワード: ストリームとは
>ストリームから読みだした直後とかのnullableを「nullable?使うよ!」とは言わん。
ごめん、そういう話かと思ってたわ、解散、解散。
僕が間違ってたわ、めんごめんご。
全ての求人が、必須条件として「JavaまたはPHPでの開発経験があること」の求人で、
ほぼ同じ求人内容に応募していることになる。提出している書類も同じ。
株式会社Gnzo
株式会社Aiming
株式会社FFRI
まあ、理不尽な理由ばかりで、人を選り好みしている上記の会社は「人手不足」って言葉は絶対使うなよ。
特に、サイボウズ株式会社の「スキルは申し分無いけど、転職回数が多すぎるからうちではお断り」という仕打ちは
一生恨んでやる。
株式会社f4samurai
株式会社CyberX
特に株式会社コロプラは圧迫面接を受けた、「なぜ、あなたのくらいの評価する実績の無い人が我が社を応募したのですか?」「なぜもっと実績を作ってから我が社を応募しなかったのですか?」「なんで、あなたは我が社の面接を受けているのですか?」って相手を完全に侮辱している態度をよく出来るなと関心してしまう。二度とお前の会社のアプリは使わない。
全社とも不合格理由が「スキル不足」。面接の時にはスキルに関してはなにも指摘されなかった上に、一次面接ではスキルの筆記試験や確認があったのに、
「スキル不足」だとさ。一次面接官が見落としていたのかそれともバカなのか、そもそもスキルに関しては応募書類に事実全てを記載しているので、書類選考で落とせよ。
みなさんが、2ちゃんねるを今でも見るのはなぜでしょうか。
みなさんが、ニコニコ動画から一歩引いたのは何時ごろでしょうか。
ソーシャルサービスの先駆けであり、最も世界で何度も終わったと言われたサイトですが終わりません。
以前より終わった感がありますがmixiより終わっていません。
2ちゃんねるを観測していたとき、ネットコミュニティとしての文化の終焉に何度も出会えました。
2ちゃんねるは、時代によって中心となる板が代わり、中心が動くことを繰り返すことで不死性を持った謎のサイトです。
一番最初は、開始1年目ぐらいでしょうか。その時代の中心は、ロビーといわれる場所でした。
ロビーとは、日常の違和感を一般的な問題化することで、無駄にしゃべりあうための場所です。
基本は今のニュース速報の様なものを考えて貰えば良いですが、取り扱う視点の広さは比べ物になりませんでした。
この時代を知っている人は、有名固定(笑)とか、その辺が懐かしい人もいるかもしれません。
さて、そんなロビーもだいたい一年ぐらいでダメになりました。原因は、マンネリ。
抱え込むネタの広さがマンネリとくだらなさを加速させました。今の嫌儲みたいな感じです。
嫌儲以上にひどい部分は、慣れ合いです。
元々は斬新な視点を提供できる人達でしたが、割に合わない思考を放棄するようになり
顔出しても知ってる固定同士でどうでも良い挨拶と雑談を繰り返すようになりました。
そんな感じでロビーは特筆するような最終回もなく、気が付いたら端にいる板になるようになりました。
その時代の結論は、慣れ合い禁止でした。
内輪ネタによる安易なコミュニケーションは、興味の無い他人にとっては「見てほしい」ネタでしかなく、「見たい」ネタではないわけです。
これを経験してる人やこの血を受け継ぐ人達は、内輪ネタや身内性に吐き気を催すように調教されています。
ちょうど良いので話は変わってmixiです。
「見てほしい」ネタと「見たい」ネタのバランスに対して、革命的な答えを提供したのがSNSです。
mixiのようなソーシャルネットワークサービスは、「見てほしい」ネタでしかない内輪ネタを
興味のある人に限定公開することで、「見たい」ネタに昇華させたのです。
好きな人のおならの臭いなら嗅ぎたい。それがSNSの本質であり、勝因でした。
でも、強引に近づけてしまった距離感が、結果的に息苦しくなり、若者のSNS離れを呼びました。。
mixiなので、四行ぐらいでどうでもいいです。
2ちゃんねるの歴史に戻ろうかと思ったのですが、飽きました。mixiのせいです。
ネタのマンネリ化を防ぐために、外部の時事性に依存したニュース速報。
VIP。作り出すことに徹した姿勢や、「見たい」を拡散したまとめサイト、慣れ合いの回帰。
ひろゆきが「まとめサイト」に対して好意的なのは「見たい」を拡散する効果なんですね。
2ちゃんねるの不死性は、少なからずひろゆきの空気の読み方も影響してたと思います。以前は。
で、最近話題のはてなブログのマーケティングは「見てほしい」を拡散してるんですね。
「見てほしい」を「見たい」に「見せかける」ツールとして利用されたのが、はてなブックマーク。
そこには「見たい」人達が集まる。なのに「見てほしい」人達を流れにのせる。
そんな風に利用されれば、反感を買うのはあたりまです。どちらの彼らのせいでもありません。
「見たい」の正体は、コンテンツです。Web2.0とかそんな時代でもそこが大事でした。
そして、コンテンツがマンネリ化した場合、その打開策として利用されるのが
「見てほししい」の無理やりなコンテンツ化です。
なぜかって?新しいコンテンツを作るより、人の欲望を見える化する方が簡単なんです。
ユーザー同士の関連テーブルを作れば終わりです。
それを体現したのが、ニコニコ動画です。ここまで読んだ人には書かなくても伝わる気がします。
で、なぜここまでモチベーションがあがらないかというと、このネタ10年前にみたとか地獄のミサワレベルだからです。
本来その先に時に生まれた異端児のストリーム論があるのです。Twitterですね。
そのネタもかなり古いですが。ストリームコミュニティの衰退を定義化されてるのはまだ見たことない気がします。
まだ、衰退してないからか?
なんでこんな古いをネタを書いたかというと、はてなブログから、すんごい古臭い匂いがするんですね。
「見てほしい」「見てほしい」文化。下手すると、テキストサイト時代のレベル。
なんつうか、うちらの世界によるtwitterの隔離閉鎖理論が、コミュニティ論そのものを衰退させて
古臭い「見てほしい」論に回帰したように感じるのは、僕の観測範囲の狭さでしょう。
時代遅れのブログでどうするか、無理やり考え出した古臭さこそ、nextネットコミュニティのはてなブログ。
なんかすんごい古い感じの、時代遅れな感じで、ループモノは飽きた。
昔なら衰退のトリガになる「見てほしい」のコンテンツ化が、この時代にどうなるか、というのはなんか少しだけ見守りたいけど。
どっちかという、こんなマンネリ論より、新しいコミュニティ論が見たいです。
下を読んでて思いました。
こんばんは。27歳のニートです。
ひょんなことからエロサイトを作ったら結構デカいサイトになったのでそのことについて書きたいと思います。
巨乳動画ストリーム
http://kyonyudouga.com/
さすがにニート生活にも飽き、何かやりたいなと考えた時にアフィリエイトを思いつく。
実はアフィリエイトについては以前から知っていて実際にやったこともありました。
しかしその時は全く稼げず、またその時は他にやることもあった為すぐにやめてしまいました。
腰を据えてやったらどうなるだろうと思い、再度アフィリエイトを始めることにしました。
どんなサイトを作ろうかと考えた時に真っ先思いついたのがエロサイトでした。
アダルトサイトはアクセスを集める手法としてアクセストレードと呼ばれる
他のアダルトサイトと相互にアクセスを送り合う手法が主流です。
そのため他サイトの画像リンクが増え、とても使いにくいものになっています。
画面をずっとスクロールさせないとコンテンツに辿り着けなかったり、ひどいところは騙しリンクもあります。
当初は私もアクセストレードメインで集客をしており、サイトは画像リンクだらけ。
ごちゃごちゃしていてコンテンツの位置もわかりにくいというお世辞にも良いサイトとは言えませんでした。
そしてアクセストレードというのは結局のところ自サイトのアクセス数により送れるアクセス数に限界があるため、ある程度のところでアクセス数が頭打ちになります。
実際のところ私のサイトも1日3万PV程度で頭打ちになりました。
そのためやる気を無くし半年程放置して2ちゃんまとめブログを始めました。
そこで2ちゃんまとめブログ運営で得たノウハウをエロサイトの方で実行したことろこれが上手くいきました。
これは一般サイトでは当たり前のことなのですがエロサイトは大手サイトでさえ非常にわかりにくい構成のサイトが多いです。
一方で2ちゃんまとめブログは大手サイトほど他サイトへのリンクも少なくわかりやすい構成になっていました。
なので思い切って画像リンク等を全て外し、わかりやすいデザインに変更しました。
②多更新にする
そこで私もエロサイトに多更新を取り入れ1日に1~3回更新だったのを1日24回、1時間に1回更新というスタイルに切り替えました。
③表示速度の改善
エロサイトはとにかく重たいところが多いです。
それは①で書いた通り画像リンクが異様に多いからというのもあるのですが動画共有サイトを利用したエロサイトは誰でも簡単に作れるため
その辺りがかなり適当なところが多いのです。
CSSspriteの使用やCSS,JSファイルのminify等ページの表示速度に関する施策を行っていないところがほとんどです。
無料ブログで運営しているエロサイトはスマートフォンページをしっかり作っていないところがほとんどです。
ほぼ広告ページとしてしか使用しておらず、コンテンツと紛らわしい広告を載せていたり、
コンテンツがあっても共有サイトのプレーヤーのサイズをスマホの画面サイズに合わせていないなど
そこで私はスマートフォンページのテンプレもしっかり作り込み最適化させました。
これらを実行した結果、ページ数が増えるに従い検索からのアクセスが右肩上がりで増え
PCページ40万PV/日、スマホページ20万PV/日というサイトに成長しました。
アクセスが増えた後いくつかの動画配信サイトとサンプル配信提携をすることが出来ました。
これには凄く驚きました。こんなことがあるのかと。
SEO施策はググれば出て来るような基本的なことしかやっていません。
SEO業者も利用していませんし、今のところこのサイトしか持っていないので自演リンクも一切やっていません。
SEOについてもエロサイトは基本すら出来ていないところが多いのでそれだけでライバルと差をつけることが出来ます。
ちなみに私のサイトはビッグキーワードでアクセスを集めているのではなく(一応「巨乳」で4~7位くらいですがそのワードでの流入は少ないです)
ロングテールってやつですね。
ロングテールは検索順位の変動にビクビクせずに済むので良いです。
やはり無料ブログでは出来る事に限界があり、エロサイトとはいえ良いサイトにしたいという思いがあったからです。
wordpressでの運営経験もなくサーバー関係のスキルもないので移転にはかなり苦労しました。
我ながら良いサイトに仕上がったことと移転を期に今までの足跡を残そうと日記を書きました。
jwplayer
Sidr(スマホ)
001 Prime Strategy Translate Accelerator
Contact Form 7
Count Per Day
Exec-PHP
Head Cleaner
Infinite Scroll
Multi Device Switcher
Quick Comments
Search Everything
Search Regex
WP-PageNavi
WP-PostRatings
WP-PostViews
多分これが一番気になるところだと思います。
アフィリエイトという観点からもスマホページの重要性がわかりますね。
あとcookieを利用したブックマーク機能も実装したいです。
エロだけじゃなくて一般サイトやWEBサービスも作りたいと色々模索しております。
どうしようもないクズニートでも頑張ったらこれぐらいのことは出来ました。
ニートでも頑張れば出来るんだ!と思って頂けたら幸いです。
-----------------------------------------
03:59追記
たくさんのブックマークありがとうございます!
とても嬉しいです。
確かに見やすくて使いやすいな。
けどリンク切れ報告フォームはなくていいの?実際他のサイトでそれが有効に使われてるのかはよくわからないが…
カテゴリ分けがシチュエーション別とかもあるといいなーと思ったけどこれ以上多くすると大変かな。あまり項目を多くするとまた見にくくなるかもしれないし。
リンク切れ報告フォームは以前は置いていたのですがあんまり報告してくれないんですよねw
自動でリンク切れをチェックするシステムを導入する予定なのでそちらで行います。
シチュエーション別もFC2の時はタグを利用してリストを作っていたのですが
FC2はタグをエクスポート出来ないのでwordpressではなくしちゃいました。
出来ないことはないのですが手作業でタグを登録し直さなければならないので…
それだけのスキルを身につけたらどこかに就職できそうだw
WordPressテーマは何を使っているんだろう?
-----------------------------------------
25日02:13追記
えーと下の方でステマだとおっしゃっている方がおりますがそのサイトの製作者と私は別人です。
私はRubyなんて使えません。
こういう事を書くと余計に怪しいと思われてしまうのでしょうけども。
ステマというのは運営者や製作者、その関係者が”利用者のフリをして”モノやサービスを薦める行為の事です。
運営者や製作者自身が「こういうのやってるんですけどどうですか?作ったんですけどどうですか?」と紹介するのはステルスではないただの宣伝です。
上でも書きましたが我ながら良いサイトに仕上がったので見てもらいたいなと思ったのです。
見てもらって感想を聞きたいなと。
エロ動画サイトってアクセスが多くてもコメントもほとんど付かないし感想を聞く機会がほとんどないんですよ。
でもFC2ブログだとさすがに恥ずかしいのでね。
wordpressならまぁ見せても恥ずかしくはないんじゃないかと思いまして。
この日記はたくさんブックマークされましたけどサイトの方はほとんどブックマーク増えてません。
最近、ネット上のあらゆる所で起こっているアンチアフィリエイト活動、彼らの言動そのままを記すこととする。
「アフィリエイターは寄生虫、ヤクザ、ネットの癌です! 早く死んでくれたまえ!」
「いつまで邪魔な広告を貼るつもりだよ? アフィつけるなら閉鎖させてやろうか?」
聞くに堪えないこれらの罵詈雑言は一般サイトの管理人に絶え間なく聞こえてくる言葉である。
本来、有料サービスでないサイトで金銭や個人情報を要求していないにも関わらず、
彼らはサイトに広告が掲載されているだけで『被害者意識』が強く生まれてしまうという。
その表情は興奮に満ちていた──。嫌儲(アフィリエイトを嫌う人達の俗称)のオフ会で取材をしてみると、
自分たちの行動原理は、彼らの弁でいえば“正しいインターネット上”。嫌儲民と自称し、インターネット
で仲間を集めて日々、アフィリエイトをつけているサイトと戦っているという。
どういった素性の人たちなのか。詳しいジャーナリストがいう。
「当初は貧しくて仕事がない若者が中心でしたが、最近では普通のサラリーマンや公務員、主婦、中学生から高齢者までと幅広い層が
参加しているようです。彼らはみな自分たちは“被害者”だという共通認識を持っています。アフィリエイターは不労所得が月に何百万もあり、
彼らにステルスマーケティングなど流行やネットストリームを牛耳られており、今のネットはアフィリエイターに支配されているといった情報を
インターネット上で入手して、それが真実だと思い込んでいる。その“奪われたネット”を取り戻すために正義の活動をしていると信じているのです」
嫌儲民には自分たちが情報やサービスを享受しているという意識はない。
むしろ“自分たちが欲しいモノは誰かが無料で奉仕してくれるのが当然”と思い込んでいるのだという。
http://www.news-postseven.com/archives/20130625_195941.html
けんもうより
一人住まいにはテレビはおいてないのだが、あればまあ見るんだろう。
しかし、この前実家に帰ったとき、ついにテレビを見ることができなかった。
ボタンがたくさんあるのも、ビデオとテレビとチューナーのリモコンがどれがどれだかよくわからなくてキレそう。
ボタンとか、電源とモード切り替えとチャンネルと音量と、あと番組表、それにアロー&決定ボタンぐらいでいいじゃん!あとは画面に出せばいいじゃん!
リモコンとか1個にしてよおおお。
あと、地デジになったらテレビがすぐ映らなくてキレそう。なんなのあれ。ていうか全体的にもっさりしすぎ。きびきび動きなさいよ!!
先日の日経に、
「法学部人気急落」という記事があって、明治学院大学とか東大とかが取り上げられていた。
日本の文系大学の中で、法学部は「文系の花形、主流派」的扱いを今までされて来て、
「あぐらをかいていた」が、人気急落で、受験生相手に法学部の魅力のアピールに努めざるを得なくなった、という記事。
そもそも、なぜ日本では法学部が主流で、文系の花形扱いされているのか?
これは推測だが、今の日本の文系大学の多くは、明治時代の「法律学校」創設がルーツだったからではないか?
経済学部とか文学部とか社会学部とかは「後発の学部」なので、大学内では傍流だったんだろう。
もっと突き詰めれば、「なぜ明治時代には法律学校が多く出来、経済学校は少なかったのか?」
という疑問に行き着く。
これも推測だが、当時の日本のGDPの大半は農業生産GDPであり、
つまり農業経済が大半、個人農業が大半であって、企業・資本の経済行動を
要するに、経済学がさほど必要なかった、経済学が必要なほど経済が成熟してなかった、ということ。
他方、近代化のために法律制度を整え、また列強に対抗し不平等条約を改訂するために
「法治国家」をアピールする必要があったため、経済力以上に「法律力」を身につける必要に迫られたため、
農業国であっても法律学校を整備する必要があった、そういうことでは?
しかし、現代みたいに、GDPの殆どが企業の生産活動で成り立っている社会では、
文系のメーンストリームは「法学部」じゃなく「経済学部」であるべきなんじゃないか?
そらのやえがみやメガネのあれは
正史として「炎上マーケティング失敗例」みたいに記録されてるけど全然そんなんじゃない。
追及した側もされた側も一致であれは炎上マーケティングだった、ということに「してしまった」だけ。
追及する側がなんでそうしたのかって言うと
そらの一味の悪質さをまとめやすくて宣伝しやすいのがその説明だったから。
そらの一味がなんでその間違ったレッテルを受け入れたかって言うとチャチなプライドで初動を誤ったから。
えがみやめがねを心の無い守銭奴モンスターみたいに言ってる人が結構居たけど実態は全然そんなこと無くて
彼等二人とも「面白い人でありたい」「面白い人として一目置かれたい」みたいな自己実現欲求はすげえ強かった。
彼らがなんとかタイムズで目立ちたがり的アクションをするとき、半分はカネやPV目的でも
もう半分は真面目に「これならどうだ、面白いでしょ」って真面目だった。
でもその度に「くそつまんねえ」「スパムやめろカス」っていう心無い罵倒を浴びて、
「真剣に面白がってもらおうと思って駄目だっただけなんです」とか真面目に釈明するより
「はいそうです金目当ての炎上マーケットですよ!ばれたかー!」って言う方が彼等としてはプライドを守れた。
「ひどい喧嘩でPV稼ぐ」っていう炎上マーケティングの一環として処理されちゃったけど、ちょっと考えて欲しい。
別に悪口じゃないが、フランチェスコさんってそこまで有名人か?
割り切って喧嘩に巻き込んで炎上PV稼ぎするならもっといくらでもネームバリューのある人はいる。
つまりあれは「意図的な炎上狙い」とか「PV狙い」とかじゃなくて
本気でカッとなってああやってただけで、
そらののとこに持ち込んだのも単に引っ込みが付かなくなっての流れの上のこと。
発端やりとりだけ抜き出すと
メガネのフランチェスコへの絡み方が唐突過ぎると言うか脈絡不明すぎて
「喧嘩を売るために喧嘩を売った」ように見られたんだけど、実は全然違う。
あのときフランチェスコは「裏を取るのはライターとして当然(もううろおぼえ)」みたいな自分の仕事関連の呟きをしてたんだけど
メガネはその数日前にソースが無茶苦茶なフカシ記事書いて壮絶に突っ込まれて何回目かのプチ炎上してたのね。
だからメガネの中では数日前から一続きのアクションだったわけあれは。
「わざとクソみたいな記事や内容の無い記事ばっかり書いてる」
みたいに言われてたけど酷い誤解で、
当人はいたって本気で記事を書いてるだけだった。
その証拠に
記事が心無いモヒカンに突っ込まれまくってズタボロプチ炎上するたびに
相手論陣の中で一番頭や口喧嘩の弱そうな相手をtwitterから探し出して
そいつだけを脅したり問い詰めたりして謝らせて
「一勝一敗」みたいな格好を作るのがメガネの恒例行事になってた。
数日前の「ソースでたらめなクソ記事書きやがって」っていう袋叩きの心の傷が癒えてなかった。
だからちょうどソース主義者の中で気や喧嘩が弱そうな奴をtwitterで探してたんだと思う。
パッと見で「女→気が弱い→ちょっと脅せば泣きが入る」っていう雑な計算が組みあがっちゃった。
あのアイコンをよく見ればコワい面構えとか謎の斜め上見ポーズとか、ヤバい相手なのが察知出来ると思うんだけど
彼はそういう細かい神経が絶望的に発達してない人だった、面白くない記事量産からもわかるとおり。
「あれ、これはおかしい」「チョロい女でも若い女でもない」と気付いたっぽい反応をしてて
戦線撤収に動き出す速度は遅くなかったんだけど
彼のフォロワーや友人は「強いメガネさん」という虚像のフォロワーなので
「あの喧嘩広げましょうよ」みたいなストリーム放送出演の誘いを断れなかったんでしょう。
そらのもあんなのがPVになるとの計算でメガネに話振ったんじゃなくて
「付き合いのあるメガネさんが無名の女に生意気な口答えされてるからお手伝いしてポイント稼ごう」ってだけだった。
で、ああなるともう一味全体として、
プライドや虚像を保つためには「PV狙いの炎上マーケットだった」ってストーリーを受け入れるしかなかった。
「小さいプライドのために喧嘩吹っかけて相手間違えてエラい事になりました」はそれよりずっとかっこ悪いから。
http://anond.hatelabo.jp/20120521121033
長くなったけど、
万が一迂遠なそらの一味擁護みたいに機能してもあほらしいと思って当時は書けなかった。
自分から炎上マーケですなんて言うのは大抵プライドや意地で言ってるのばっか。
家入一味だって別に炎上で稼ごうと思ってたわけじゃなくて感情的になってる(or親分をフォローして点数稼ぎしようとしてる)だけ。
B-CASカードがお祭り状態なので技術的なことをネットに転がっている情報から調べてみました。
もし間違いがありましたら後学のため教えてください。。
http://gigazine.net/news/20120518-b-cas-card/
・B-CASカードにはKm(マスターキー)というカード毎固有の暗号鍵が含まれている
・放送波から流れてくるTS(トランスポート・ストリーム)にはEMMとECMというというパケットが含まれている
・ECMはすべてのB-CASカードに向けて投げられるパケット
みたいな
- この情報はB-CASカード内にあるRAMエリア「契約情報」にコピーされる ★1
- EMM自身にはB-CASカードID(6Byte)が非暗号化されて入っている
・ECMには日時情報とKs(スクランブルキー)が含まれている
- 日時情報と上記「契約情報」でACL(アクセス・コントロール)を行なっている ★2
と、いうことで★1と★2において★1の契約情報を偽造できればたとえばwowwowを契約していないのに
契約できていることになりそうです。ただ問題は★1の部分はEMMで更新されるということ。
単純にB-CAS内のRAMエリアを書き換えても時間がたてばEMMで元に戻りそうです。
参考:
http://oshiete.goo.ne.jp/qa/3456801.html
http://blog.goo.ne.jp/ikedanobuo/e/8b59ccca2dac45f02a5ae15815fb4a75
http://www.marumo.ne.jp/db2012_5.htm#12
http://www.marumo.ne.jp/db2007_c.htm
EMMデータには暗号化されていない部分にカードID番号(6Byte)
http://www.arib.or.jp/english/html/overview/doc/2-STD-B25v5_0.pdf
知らなかったのですがB-CASカード内にはCPUが入っているそうです。
そのCPUがEMM/ECMのパース、暗号の復号、「契約情報」エリアの管理を行なっているようです。
今回は特定のB-CASカードに含まれるそのCPUが特定され、ファームを書き換えられるようにしたそうです。
ファームを書き換えさえすればEMMの「契約情報」をRAMエリアの「契約情報」にコピーさせる処理を
よって今回突破されたことをまとめると、
・特定のB-CASカードにはRAMエリア書き換え、CPUファームを書き換えるバックドアが設けられていた
・特定のB-CASカード対応の改造版ファームを作る猛者がいた
ということのようです。
以下は興味。
各B-CASカード宛てにパケットを送るなんて現実的じゃないよね?どうやってるんだろう?
特開2000-125272 【発明の名称】放送システムでのメッセージ伝送方法
http://www.j-tokkyo.com/2000/H04N/JP2000-125272.shtml
TSにはハッシュキーのみ含み、データはB-CAS内に予め保持しておくそうです。
確かに契約パターンはそんなに多くはないだろうからこれでいけそうですね。
EMMもひとつのTSパケット中に何個か含めることができるそうです。
いや、場所が箱でやってることがダンスとか旧世代クラブ文化チックなので広義の意味で「クラブ文化のいちストリーム」くらいにはなるだろうけど。
あれって実質やってることはコミケでしょ? ちょっと変形してるだけで。
コミックマーケットご存知ですか。OTAKUがJAPANIMATIONとか萌えマンガとかエロゲでぶひぶひ息を荒げるイベント~みたいに思われてる節がありますが、あれ原点は同人誌の即売会であって、「売り手と買い手は対等」の精神が特徴であるとして耳目を集めたり集めなかったりしてます。
キャッチフレーズは「コミケに『お客様』はいない」です。コミケに来る人間は作品への愛があるという点でみんな同類にして仲間であり、仲間同士助け合い協力しあってコミケなるイベントを作り上げようという姿勢です。
それが昨今はクラブの箱に入ってきてるだけなんじゃないでしょうかね。
だとしたら旧クラブ世代とは決定的に毛色を違える部分があるので、なんつうか、新世代のお行儀のよさを取り入れて旧世代が進化する、みたいな構図になるか微妙な気がします。
新世代クラブユーザーがお行儀がいいのは彼らのルーツがOTAKUという無理解にさらされながらも常に適応の道を探らざるを得なかった連中にあるからであって、「自分らの文化を理解しない外部の目」がある程度内面化されているからです。
旧世代クラブユーザーって外部の目をシャットダウンする「箱」の中で育ってきたんでしょ。
アニメとかマンガとかの「何か」を楽しもうと思って集ってるというよりは、そこがコミュニティそのもの、居場所そのものとして機能してるからやってくるんじゃないですか?
「自分はナンパしないけど友達はナンパ大好き野郎で一緒にいると面白いからいつもつるんでる」みたいな人は、ナンパ大好き野郎が居なくてつまんなくなったクラブに行くでしょうか。
新世代はそこに機材があって音漏れしなくて自分の最萌えをありえない爆音で流してくれる上に人目をはばからず踊っても文句言われないから来るのであって、クラブ文化やコミュニティ性を愛してるかっつうと……みたいな感じがする。
旧世代、最悪単に駆逐されちゃうだけなんじゃないか? 「発展」するだろうか。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか? 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の,変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか? 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か? 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者/消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し,処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か? 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか? 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的/手続き的方法 10.2 宣言的/手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中,後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し,使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
この努力は僕が Google に来る為に Amazonを離れた2005年半ばも続いていた。でももっとずっと進化していたよ。 Bezos が命令を出してから僕が離れるまでの間に、 Amazon は全てにおいてまず最初にサービスを考える企業へと文化的に変化していった。外部の日の目を決して見ることの無いような、スタッフへの内部的なデザインも含めて、今ではそれがデザインというもの全てに対しての基本的なアプローチになっている。
その時点では、彼らはもはや解雇の恐怖からそうしているわけではなかった。つまり、もちろんビビってはいたけれど、ドレッドヘアの海賊 Bezos 様にご奉仕するのは日常生活の一部だからね。そうじゃなく、彼らはそれが正しいことだと理解したから、サービスを提供しているんだ。確かに SOA のアプローチには長所も短所もあるし、短所を書き出してみたら切りが無い。でも全体として、 SOA ドリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。
これが、 Bezos が彼の指令書で企んだことだった。彼はチームの健康状態なんて興味もなかったし(今もそうかも)、使われている技術もそうだったし、結局の処のどう取りかかるかなんて結果ができあがるまで気にもしていなかった。けれど Bezos は、 Amazon 社員の大多数が理解する前に、 Amazon はプラットフォームにならなければならないということを悟っていたんだ。
だって考えてもみてよ。なんで一オンライン書店が、拡張可能な、プログラマブルなプラットフォームになる必要がある、なんてことを考える?。そうだろ?
ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォームに再利用でき得るということだ。だから今、彼らには Amazon Elastic Compute Cloud があるし、 Amazon Elastic MapReduce があるし、 Amazon Relational Database Service があるし、その他たくさんの aws.amazon.com で見つけられるサービスを持っている。しかもこれらのサービスは大成功した企業のバックエンドを努めていたりもする。 reddit なんか僕のお気に入りだね。
もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。これは Larry Tesler が、ママはこのくそったれサイトを全く使えないよと言ってのけたりでもした時に、 Bezos にピンと来るものがあったんだと思う。誰のママのことを言ったのかははっきりしないし、そんなことは問題じゃ無い。問題は、誰のママだろうとそのウンコサイトを使えないってことだ(訳注:アドバイス thx !)。実際、僕自身、そこで5年ほど働いていたわけだけど、あのサイトは胸がザワザワするくらいひどいと思う。でも僕はその気が散るようなサイトに慣れてしまって、トップページのど真ん中あたりの数万ピクセルに集中できるようになったんだからね。
とまあ、実際の処 Bezos がどうやってその理解、一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできないということに、たどり着いたのかは定かじゃあ無い。でもその方法は問題じゃ無くて、彼は理解してるってことが重要だ。実のところこの現象には正式な名前だってある。そう、それはアクセシビリティと呼ばれるものだ。コンピューティングの世界で最も重要なものだ。
君は思うかも知れないね。「はあ?つまりそれって、目が見えない人や耳が聞こえない人のあれ?あのアクセシビリティ?」ってね。まあ君だけじゃないと思う。とにかく世間には、アクセシビリティってものを正しく理解していない、君みたいな人たちがいっぱいいっぱいいるんだから。ただそこにたどり着いてない人たちがね。だから、アクセシビリティを理解していないのは、目の見えない人や耳の聞こえない人や手足が不自由な人やその他障碍のある人の責任じゃないように、君の責任じゃない。ソフトウェアが(この場合アイデアウェアといった方が正しいかもしれない)何らかの理由で誰かにとってアクセシブルでないというとき、それはソフトウェア自身の、あるいはアイデアの伝え方そのものに責任があるんだ。それがアクセシビリティの失敗というやつなんだ。
人生における重要なその他もろもろと一緒でさ、アクセシビリティには邪悪な双子がついている。小さいときにパパとママの偏った愛情で見捨てられて、今や同じくらいの力を持つまでに育った宿敵って奴がね(もちろんアクセシビリティには宿敵はたくさんいる)。それはセキュリティだ。一体全体こいつらが仲良くやっていること何てあるかい?
でも、僕は主張したい。アクセシビリティは実際の処セキュリティより重要だということを。だって、アクセシビリティを0にダイアルするってことは、何のプロダクトも持たないってことさ。セキュリティを0にダイアルしたって、そこそこのプロダクトを持つことはできるだろう? Playstation Network みたいにさ。
まあつまりですね、僕はみんなが分かってくれないんだったら一冊丸々この話題で本を書くことだってできるよ。分厚くて、僕が働いてた会社のありんことピコピコハンマーのエピソードで一杯の面白いやつをね。でも僕がこの話を公開しなかったら、みんなが目にすることも無いだろう。そろそろまとめに入らなきゃ。
Google がうまくやれていない最後の一つは、プラットフォームだ。僕らはプラットフォームを理解していない。僕らはプラットフォームを自分のものにしていない。みんなの中にできている人はいるだろう。でも、そんな君はマイノリティだ。辛いことだけれど、これはこの6年で僕にはっきりと感じられた。僕は競争相手のプレッシャー、 Microsoft や Amazon や最近じゃ Facebook なんかが、僕らを一斉に目覚めさせて、ユニバーサルにサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれ Amazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。
でも、そうはなっていない。10番やら11番めくらいのプライオリティだね。いや15番かも?。知らないけど、とにかく低い。真剣に取り組んでいるチームもいくつかあるけど、多くのチームは考えてもいない。一度もだ。ごく一部の人々がちょっとした規模でやっているだけだ。
多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービスを提供させるのだって大変だ。彼らのほとんどは、俺達はプロダクトを作っているんだ、って思っているからね。そんでもってそのちょっとしたサービスなんてのはみじめなもんさ。 Amazon の教訓に戻ってリストを見てくれよ。そんで今すぐ使えるサービスを持ってきて見てくれ。僕が知る限りでは、そんなものはない。小ビンってのは便利かもしれないけどさ、そんなの車がいる時だけだろ?(訳注:この人、 Stubby という小瓶のビールと、 stubby という「ちょっとした・不格好な」という形容詞をひっかけてしゃべってます)
プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。
Google+ ってのはまったくまさに、エグゼクティブリーダーシップのとても高いレベルから(やあ Larry 、 Sergey 、 Eric 、 Vic 、やあやあ)枝葉の使いっ走りまで(やあ、君だよ)、全くプラットフォームを理解していないっていう良い例だ。そう、僕らはみんな、全く理解できていない。プラットフォームの黄金律ってのは、自分のドッグフードを食えってことだ。 Google+ プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりとも API が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけな API さ。ローンチの時、あるチームのメンバーが行進してきて僕にそれを説明してくれた。だから僕は訊いたんだ「でさ、これはストーカー用 API?」って。彼女はむすっとして、「ええ」ってだけ言った。いやジョークなんだよ…いや…ジョークじゃ無いんだ…僕らが提供する唯一の API は、誰かのストリームを読み出すだけ…。うーん、僕が間違ってたのか?
Microsoft はこの20年間ドッグフードルールで知られてる。この時代の彼らにとっての文化の一つなのさ。デベロッパにドッグフードを食わせて、僕らだけ人間のご飯を食べようってわけにはいかない。それは単に短期の成功のために長期のプラットフォーム価値を損なう行為だ。プラットフォームってのはまったく長期的な視点が必要なんだよ。
Google+ は脊髄反射の代物さ。 Facebook が成功したのは、彼らがすばらしいプロダクトを作ったからだって言う、まあ実に近視眼的なものの見方の結果として生まれたものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。 Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。だから Facebook はみんなにとってそれぞれ違うものだ。 Mafia Wars に全ての時間を費やす人もいれば、 Farmville で遊ぶ人もいる。何百の、いや何千の、質の高い、暇つぶしができるってわけさ。つまり、みんなのためにふさわしい何かが必ずあるんだよ。
僕らの Google+ チームは、プロダクトを出した後のマーケットを見てこう思った。「おっとっと、我々もいくつかゲームが必要みたいだな。さっそくどこかと契約して、我々のために作ってもらおう」。これが信じられないくらい間違った考え方だってことが、君にもわかってきたかい?。問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。
そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。もちろんコンピューティングの歴史全体を見渡せば、それを確実に信頼性を持ってできる人間ってのがごく数人いることにはいる。 Steve Jobs がそうだろう。でも、僕らの処には Steve Jobs はいない。悪いけど、いないんだよ。
Larry Tesler は、 Bezos が Steve Jobs じゃないってことを口説いたかもしれない。でも Bezos には分かっていた。全ての人にふさわしいプロダクトを提供する為に、彼が Steve Jobs になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな(多かったらいいな)には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは,外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は,互いに,および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは,停止するとは限らない 1.4.4 プロセスは,開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは,結合の観測と生成を行う 1.4.7 プロセスは,書換え規則を用いて定義する 1.4.8 通信は,プロセス間の共有変数を用いて行う 1.4.9 外貨も,プロセスとしてモデル化される 1.4.10 通信は,非同期的である 1.4.11 プロセスのふるまいは,非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数,多項式イデアル,自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング? 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに:構成的プログラミングに未来はあるか? 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
いや、あなたの言ってることは合ってるし、自分も基本的に同じことを主張したつもりだが。
を、わざわざ砕いて”リッチなインターネットコンテンツを、非常に簡潔にスマートに記述できる”と文系チックに書いたのに、なぜ、わかりにくいバズワードで言いなおすのか。
そもそも「セマンティックな記述」って意味がわからない。文章の意味構造を記述できるようにして外見と分離する事を指すのなら、それは「非常に簡潔にスマートに記述できる」という事じゃないのか(さすがにあいまいに書きすぎてるとは自分でも思うが)。「実現できることが格段に増えた」事は、リッチなインターネットコンテンツを記述できるって事じゃないのか(意味構造を記述によって検索エンジンに適した情報になるってメリットは、論旨がブレるので書いてない)。
その当たり前の事ができなかったHTML4。HTML5になればできるようになるとでも言いたいのなら、あなたもネットに向いてない。
問いかけてる以上、答えがあるようなので、ぜひ模範解答をご教授頂きたい。「無限の可能性があります」という厨二病な答えしか思いつかない。
ちゃんと書いたつもりけど、代表格は2D描画。あと複雑な処理(クラスのおかげ)。ブラウザ間OS間の互換性。ネイティブなXML処理。プリミティブな音ストリームの操作なんてのもある。
現状、Flashを必要としてるのは何処? 誰?
Flashを必要としてる人なんていないと思ってる。ただFlashの方が制作環境とかも含めて使いやすいから使ってるだけのこと。
いやいやいやいや。iPhoneで表示されない広告に何の意味があるのか。ゲームは一理あるけどFlashは外部コントローラに対応してない。3Dなら現状Unity。一概に言えない。
http://anond.hatelabo.jp/20110707195830
ボーカロイドの海外進出に将来性はあるのか。そういう視点から初音ミクのLAライブを見ている外国人は結構いる。今回紹介するのは、その中でも明確に「ビジネスとしての初音ミク」のあり方について論じている事例だ。日本人が読むと高すぎるハードルを設定されているような気がしないでもないが、確かに商売としての初音ミクを考えるべき時が来ているとの指摘には一理ある。日本でもまだ確立したとは言えないビジネスモデルをどのように海外で成功させるか考えるうえで、一つの材料になる。
urlは以下の通り。
http://cjblackwing.wordpress.com/2011/07/08/mikunopolis-christmas-in-july-and-world-conquest/
数日前、私はロサンゼルスのアニメ・エキスポ2011から戻ってきた。私の旅行のうち、すぐ後悔するに決まっているレベルの買い物を物販コーナーでしでかしたこと以外のハイライトと言えば、初音ミク関連全部だと言わざるを得ない。ミクがらみ全ての中で頂点はどう見てもミクノポリスだったが、週末のあらゆるパネルを通じてミクに関するたくさんのことを知ったのは楽しい経験だった。ロサンゼルスに向かう前から私はもちろんヴァーチャルアイドルのファンだったが、週末に入るまで私は何を予期すべきかについて実は知らなかった。出立後、ミクのファンになることがいくつかの理由でサンタを信じることに極めて似ているのに気づき、私は衝撃を受けた。
まず、クリスマスが持つ意義と同様、ミクは君が何をしたいかによって君が望むどのような存在にもなれる。世の中にいるあらゆる変態のために彼女が無限の衣装を持っているかのように見える点について話しているんじゃない。いや、それも一部かもしれない。今なおファンはミクに関する新しい歌、アニメーション、あるいはキャラデザをつくり、他の者がインターネット使用を通じて楽しめるようそれを世の中に送り出すことができる。けどクリスマスが単にキャンディー棒と橇の鈴だけではないのと同様、ミクも音楽だけじゃない。この週末、ほぼすぐ私にとって完璧に明らかになったのは、ミクがごく簡単に商業主義の同義語になり得るということ。色々な意味でこれはいいことだ。こうした起業家精神こそが、ゲームやフィギュアに登場するミクをファンにデザインさせることになるし、たとえ分権的なビジネスモデルを通じることになるとしてもなお企業がミク製品に資金を使うのを許すのだから。そして商業主義に関するあらゆるものの真実の意味において、ミクはしばしば決して純粋とはいえない姿に描き出されている。
クリスマスの比喩を続けよう。子供はしばしば小さいうちはクリスマスという概念を理解するのが困難だ。2歳児がただの贈り物を受け取る意味を理解する必要はないが、数年内にそれは子供の世界における中心的イベントになる。この週末、私はミクを理解するうえでそれと同じ感覚を味わった。明らかにアニメ・エキスポに来た大勢の人はミクが何であるかについていくらかの考えを持っていたが、大多数にとってこれはミクに関するあらゆる知識を大量に服用した最初の経験だった。ヴァーチャルアイドルに対する興味は週末を通じてゆっくり増大していくように見えたが、私が思うに大半の人が本当にミクの真価を認め始めたのは彼女のコンサートの間だった。当初、選ばれた一団の人々のみが歓声を上げさらに少ない人だけが立っていたようだった。だがコンサートが進むに連れより多くの人々が言わばグルーヴに身を任せるようになり、そしてその夜の終わりにはノキア・シアターのほぼ全員が立ち上がり、ミクにアンコールのため戻ってくるよう肺の中から叫んでいたかに思えた。サンタ・クロースとミクを含む人生における多くのこと同様、何が起きているかを理解するには多少の時間がかかるが、ひとたび理解すればそれは何か特別なことになるのだろう。
私は日本企業がミクの人気を増すために行ったこと、つまりクリエーター個人がその製品の中で比較的自由にミクを使えるようにすることでファンのデザインをコンサートやフィギュアに実装したところからこの週末のコンサートまで、その全てに敬服している。そして成功するためには他の国民もミクに関する彼らのモデルに追随すべきだと日本人が感じていることも何となく分かるが、それは正しい方法ではないと私は思う。世界中の人々が異なるやり方でクリスマスとサンタを祝っているのと同じように、我々はミクと他のボーカロイドを祝すべきだ。将来において他の言語でもソフトが使えるようにするのは正しい方向性だが、それは分かりきったことに過ぎない。心配なのは、ミクが米国あるいは他の西洋諸国のより幅広い聴衆に必ずしも利用されず、あるいはよく知られないままになるのではという点だ。現状、普通のアニメ、J-ポップ、その他のファン以外の人々が本当にミクのファンになるのは不可能だと思うが、米国で例えばniconico.comといった感じの新たなサイトを作っても、米国が中東に民主主義を紹介しようと試みているのと同じような前進しか期待できないだろう。
ミク(及び彼女の調教師)が本当に世界を征服したいと思っているのなら、まず彼らがオタクのファンベースを幅広く、Narutards[NARUTOの熱狂的ファン、キモオタの代名詞?]からミクを見るために国中から集まってくる人々に至るまで全ての人を(支持母体として)征服することが完全に必要である。エキスポで参加したいくつかのパネル及び私が過去に話した人々を見る限り、アニメ業界が彼らのオンライン製品をよく知らしめるためにいい仕事をしてきたようには思えない。コンベンションで出会った何人かの人はCrunchyrollが無料アニメを提供していることを知らなかった(はっきり言えば、合法違法を含めオンラインでアニメのストリーム上映を見られることを知っている人は極めて少ない集団にとどまっていた)。つまりniconico.comや新たに告知されたMikubookを習慣的に人々が見ることは決して所与の前提ではないし、まして部屋の中にユーチューブという名の500ポンドのゴリラがいる状態ではそんな事態は期待できない。
私がビジネスコンサルティングの授業から学んだ一つの教訓は、製品を作り出すのを手助けするのに必要なリソースを既に持っている企業と一緒に働く能力を君が備えているのなら、自らチャレンジして必要な能力を発達させるよりも、その企業と一緒に仕事をした方がいいってことだ。もし製品を外国に紹介しようとしているのなら、ジョイントベンチャーの利用はより重要である。確かに私はミク関係の人々がアメリカに拠点を置くウェブ企業とある種のジョイントベンチャーを作ろうと試みたのかどうか知らない。だがもしやったことがないのなら、それは彼らの犯した重大ミスだろう。普通のアニメ/J-ポップファンがniconicoやMikubookに気づくまでに使われる時間と金にはそれだけの価値があるようには思われず、そしておそらく普通のアメリカの消費者の注意を惹きつけることなど忘れてしまうほどかかるだろう。その代わり、既に有名なアメリカのネット媒体でミクの特別販促を行うことを日本企業が本気で考えたのなら、ミクは既に彼女を知っている者にのみ検索されることもなくなるだろう。
ミクが日本以外では失敗を運命づけられていると言っているのではない。日本で発展したビジネスモデルは間違いなく機能しているように見えるし、彼らはそのための偉大な製品を持っている。ミクがもっと一般的になるのを見たい人間として、米国でのトヨタCMである程度はやったように、彼女を宣伝するため日本企業がもっと米国企業と一緒に働くのを見てみたい。さらに、これらの取り組みは単なる単発的仕掛けにとどまってはいけない。既に確立したテレビメディアを通じてミクを人々に知ってもらおうとする取り組みを継続する必要がある。さもなくば最終的にビジネスのコストが高くなりすぎ、慌てて逃げ出さざるを得なくなるだろう。
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その2「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その3「ミクノポリスのボカレタリアートたちよ、団結せよ!」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その4「仮想の歌姫:初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その5「オレはAXには行ってないけど、まあとにかく……」
http://anond.hatelabo.jp/20110711212701
初音ミクLAライブ、外国人感想その7「AX11:ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その8「ミクノポリス:コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その9「アニメ・エキスポ:初音ミク」
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「ミク:日本のヴァーチャル・アイドルとメディア・プラットフォーム」
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人の感想その5。これまで紹介した感想は「ヴァーチャル・アイドルとしての初音ミク」を論じていたが、今回はミクの本来の姿、即ち「歌声合成ソフトとしての初音ミク」に注目しているのが特徴だ。また外国における歌声合成ソフトの将来性についてかなり厳しい見方をしているが、その指摘には耳を傾けるべきところも多い。初音ミクの海外進出に関する先行きを占ううえでも目を通しておく価値はあるだろう。
urlは以下の通り。
http://lelangiric.wordpress.com/2011/07/07/i-didnt-go-to-ax-but-yeah-anyway/
ミクのイベント後にはいつもヴァーチャルスターの構成要素は何かって議論が巻き起こる。クラウドソースな人格か? touhou[東方]っぽさ? オリジナルのないdoujin[同人]? それともインターネットとDTMの力に関するフリードマン風の熱狂か?
確かに日本じゃ大うけだが、アメリカではこれからどう成長するんだ? オレは英語のVocaloid3が発売されるのを待っている。いいものであってほしい。アメリカでのボーカロイドの発展には英語Vocaloid3の性能が極めて重要なんだ。けどな、アニメ産業とボーカロイドとの結びつきについては、オレは戸惑っている。つまりAXがミクノポリス会場になったことにな。今後も長期にわたって、アメリカではボカロオンリーのイベントはないだろう。アメリカに拠点を置く企業製のボーカロイドすら未だにない。オレが知っている[英語ボカロの]2つの会社はPower FX(スウェーデン)とZero-G(英国)だ。
でもな、そこでオレは考えてみたんだ。
ボーカロイドはvst[ヴァーチャル・スタジオ・テクノロジー](とかその他のapi[アプリケーションプログラミングインタフェース])といくつかの重要で理論的な方法は似ているんだが、極めて重要な具体的手法は根本的に違っている、とオレは理解している。基本的に(ある人間の)音声ソースを取ってきてあらゆる音素と音程を録音し、ボイスバンクを作った後で、ヤマハのVocaloid2プログラムがボイスバンクを「読む」ことができるようアプリケーションをコードする必要がある。オレはヤマハがこの部分で相当用心していると思っている。なぜなら公式のボーカロイドは(もしオレが間違っているなら訂正してほしいが)全部ヤマハのVocaloid2エディターと一緒に販売されているからだ。この意味でvstとは根本的な差異が存在する。(1)vstは通常daw[デジタル・オーディオ・ワークステーション]と一緒に流通することはない(2)vstの開発者であるスタインバーグは、vstプラグインを規格として作成しており、従って誰もがvstプラグインを作り出せる。
http://en.wikipedia.org/wiki/Virtual_Studio_Technology
http://en.wikipedia.org/wiki/Digital_Audio_Workstation
http://en.wikipedia.org/wiki/Steinberg
つまり、誰もがボイスバンクを作れるってことだ。UTAU現象がそれを示している。UTAUは違うソフトで動くボーカロイドの単なる「代替手段」(本当の意味でではないがオレは耐えられる)のフリーウエアに過ぎない。自家製ボーカロイドが登場するには(『ファンの作ったボーカロイド』はあるが、本物の商業ベースのボーカロイドとは違う)2つの条件を満たさなければならない。ある団体が充分な資本を集めて(1)高品質のボイスバンクを作成し(2)ヤマハからそのVocaloidエディターを頒布する許諾を得ることが必要なんだ。既に言った通り、紛らわしいのはボイスバンクをプログラムに「読ませる」ためのアプリをヤマハとサードパーティのどっちがコードしているのかってこと。思うに、もしおれがAXの会場にいてこの質問をしていたら、特にヤマハからVocaloid2の許諾を得るのにいくらかかるかを聞いていたら、オレは殺されていただろうな。日本のdoujin歌手を使えば高品質なボーカルを作るのはそんなに難しくないだろう。必要なのはインターフェイスと集音マイク。ダチを作ってそいつらに作業をさせる。そしてUTAUのファンダム全体を見れば分かるが、自分自身を体現したボイスバンクを作ろうとするモチベーションの持ち主は山ほどいるぜ。
http://utau.wikia.com/wiki/UTAU_wiki
オレが何を言おうとしているか分かるだろう。つまり、アメリカ製のインディー・ボーカロイド・スタジオの実現性ってのはどのくらいあるんだ?
少なくとももっと注意深く考え抜く必要がある4つの条件があると思う。
1. アメリカのアニメ業界とボーカロイドの関係。オレが思うに、ブランドイメージと、それからボーカロイドとアニメを結び付けているメーンストリームの連中のことを考えれば、こいつは最も重要な問題だ。「アニメ」はアメリカでその「あるべきもの」(つまりdirty japanese hentai shit)より遥かに大きな概念/カテゴリーになるべきだ。でもまあオレが見てきた限り、日本のボーカロイドにも同じ混同の問題があるようだけどな。とにかく、メーンストリームが一般的にアニメをどう見ているかがボーカロイド関連商品の売れ行きに影響するってことなんだが、この問題はオレには重過ぎる。omoやalexが考えてくれんじゃねーの、多分。
http://twitter.com/#!/alexleavitt
2. 誰か英語ボーカロイド使ってるヤツいる? 西洋ボーカロイドファンダム総体の認識として、1人だけすげえアメリカ野郎がいて、そいつがボーカロイドランキング(ニコニコのやつで毎週ボーカロイドの歌/動画をコメント/再生数/マイリストに従ってランク付けしている)に[英語ボカロを]ぶち込んだことがあった。でもそいつは突然自分の動画を全削除しちまった。この一度こっきりの出来事を除けば、ボーカロイドは完全に日本のものだ。他にも英語が母国語の作り手はいるんだが、皮肉なことに英語話者のボーカロイド製作者が基礎を置く発生核となりそうな連中の大部分は、日本語ボーカロイドにengrishをしゃべらせようとしている有様だ(大笑い)。
この問題にはさらに深い根がある。
3. そんな真面目な議論じゃないんだが、ある文化の労働的な基底はどうして特定の製品に同調し他の製品には抵抗するのかについて話がなされている。歴史的かつ社会経済的な問いだ。どうしてチリは銅を掘っているのか? なぜならそれがくそったれなほど沢山あるからだ。結果として採鉱は(おそらく)経済的な基盤が上部構造へと波及していくのと同じように(違うか?)文化的な行為となる。なぜアメリカは基底からやって来る沢山のボーカロイド曲を持っていないのか? その理由はもう挙げているな……(1)なぜならdirty anime hentaiだから(2)アメリカにいるデスクトップミュージック人種はテレビゲームと映像作品に集中してやがるから。
http://www.imdb.com/title/tt0132477/
http://en.wikipedia.org/wiki/Base_and_superstructure
4. 2番目に上げたデスクトップミュージックの問題は重要だぜ。もしお前が独立した作曲家としてメシを食っていきたいのなら、お前の時間と貴重な音楽的アイデアをボーカロイドのように不安で子供じみた音に賭けてみようなんて考えは二度と起こさないだろう。そいつは正直、新しすぎる。西洋諸国は上出来なデスクトップミュージックを作っている。問題は、ボーカロイドは今も、そしておそらくは長期にわたって、もしかしたら決して、独立したアーティストにとって頼れる収入源にはならないってこと。たとえそれで生計を立てる気がないとしてもだ。アメリカでボーカロイドは、他のデジタル関連のインディー業界のように花開くことはできるのか? アメリカのボーカロイドが日本のdoujin業界のようになるにはどうしたらいいんだ?
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その2「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その3「ミクノポリスのボカレタリアートたちよ、団結せよ!」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その4「仮想の歌姫:初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その6「ミクノポリス:7月のクリスマスと世界征服」
http://anond.hatelabo.jp/20110712205546
初音ミクLAライブ、外国人感想その7「AX11:ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その8「ミクノポリス:コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その9「アニメ・エキスポ:初音ミク」
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「ミク:日本のヴァーチャル・アイドルとメディア・プラットフォーム」
アクセル・ワールド8巻がとても面白かったのですが、未解決の伏線が多すぎてよくわからなくなってきたのでまとめてみました。
同じ作者さんのソードアート・オンラインも含めて思い切りネタバレしてますので、未読の方は注意です。また、多分に私の推測を含んでいます。
4巻で「フルダイブを実現したヘッドギア型VRマシンが開発されたのは2022年の5月」という記述があるが、これはソードアート・オンラインの世界でナーブギアが開発された時期と完全に一致する。ということで、作者がこの二作品に何らかの関係性を持たせようとしているのは確かだと言える。
あくまでも別の作品なので、ソードアート・オンラインの方のネタバレになってしまうようなことは書かれないと思うが、今後も分かる人にはわかる、というレベルの繋がりは出てくるかもしれない。
コメント見てると「申し訳ありませんが絵描きさん以外の申請はお断りさせていただきます」 を叩いてる意図を分かってないやつが多すぎ。
別に、「絵描き以外お断り」それ自体に文句言ってるわけじゃない。
「絵を描く努力も苦労も楽しみも知らない知ろうとしない奴は来るな」ってこと
こういうようなことを言うのに対して、絵を描くということでそれ以外の人間に対して階層意識を持っていることをわざわざ表明するなんて不愉快すぎると言ってるわけ。
どっかの週刊少年漫画家が偉そうに物抜かしてたのと同じこと。努力とか何いってんだか。
努力して絵を描いてる自分が偉い、してないやつは偉くない、俺は偉い奴としか会話したくない。
こう言ってるように見える。絵を描くことには努力を向けてなくても、他のことで努力してる人間なんていくらでもいるのにな。
単に「絵が描けないやつお断り」だったら、何も思わなかったよ。絵を描くということが共感できる人と話したいってだけなんだろうなと思ってたよ。
そういう話をしてるのにコメント見てりゃ「絵を描ける人と話したいのは当然だろ」みたいな言い方ばっかり。
俺はそんな話してるんじゃないから。
それから無断転載に切れるなって話をしてるんじゃなくて、無断転載されてキレた様をいちいち自慢するかのようにTwitterに書くなって言ってんの。地獄のミサワにしか見えんわ。
んで、そんなこと言ってるお前はふたばや2ちゃんで作られたものの無断転載画像のツイートをリツイートしてんじゃねえかってことを言ってるだけ。
文章の無断転載も平気だしな。商業用の音楽を流しながら絵描きのストリーム配信とかやってたり。マジで笑える。
http://anond.hatelabo.jp/20110115003843
の記事を書いた増田です。(以下、「上の記事」ってなってるのはこのURLのことね)
上の記事は、要は年末年始に12時間ほどでサイトを作ったよという話で、作ったはいいがユーザーをどうやって楽しませればいいのか?というところで悩んでます、誰かアドバイスくださいといった内容でした。
サイトは子育て関連のツイートを集めてランキングするサイトです。コミュニティではなく、ツイートのストリームでもなく、ツイート単体でもなく、なんとなく有用なツイートが集まったサイト、というポジションを目指しています。2chまとめサイトのTwitter版みたいな感じ。
個人的にはサイトを作るのは楽しいから、作ってるときとかコードを書いてるときは面白くやれてるんだけど、毎日の運用をもっとモチベーション高くやれたらなあ、と思って上の記事を書きました。
で、あれから1ヶ月ほどたちました。この1ヶ月でやったこととサイトの今について書いていきます。
まずEasyBotter(上記記事参照)の設定で、autoFollowというのがあるんですがそれを使いました。この設定は自動でフォロー返しするというものらしく、ツイッターのプロフィールにも「フォローされたら必ずフォロー返します!」と書いた。
さらに、サイトに関連する人(子育てしているママパパ)を探してフォローしまくりました。Twitterは2000人までしか最初はフォローできないので1900人ほどを何日かに分けてフォローしていきました。そうすると1ヶ月でフォロワーが1000人くらいになりました。毎日20から30人くらいにフォローされていく感じ。
フォローしている人はほとんどママパパなので、基本的に朝は早いです。なので「おはよう」に反応しておは返しするようにしました。でも毎日だと飽きられるのでときどきにしておきました。おはあり、と返事が来たらやっぱりこっちも嬉しいし。
サイト立ち上げのときは、ツイートを自動収集して自動投稿するサイトだったんですが、これだと毎日100ツイート以上を投稿してしまうし、ランキングするにはノイズが多すぎることが分かりました。そもそもランキングは「いいね!」というボタンのクリック数でカウントしてたんですが、これを「わかる!」に変えました。いいねだと何がいいのかよくわからないから。それと、上の記事にコメントいただいてたので、こっちに変えてみました。わかるボタン。
それにあわせて自動投稿をやめて、自動下書き投稿にしました。なので毎日、管理人(私)が100件以上の投稿を見て、リプライとRTをのぞいて、「わかる!」が付きそうなものだけを選ぶようにしました。そうすることで記事投稿数は1日に5本前後まで減ってしまったけど、わかるされる率が1/100から1/10くらいまで上がったような気がしています。個人的にも、意味があるツイートを集めているサイトになってきたなという実感があります。
Googleアドワーズに出してみました。ディスプレイネットワーク(ブロガーから見たらアドセンス)とキーワード検索広告。キーワードのほうはあんまりクリックがよくなくて、表示件数は10万件くらいあってもクリック数は数十件という有様でした。逆にディスプレイのほうがクリックがよくて、1クリック50から100円くらいかかったけど、それで何十人?かがアクセスしてくれました。でも、わかるボタンはほとんど押されなかったです。なので出稿をやめました。1日5000円とか上限を設定してもすぐに使い切っちゃうんだね。
anond.hatelabo.jpに書いたのに、次の日には増田まとめみたいなブログにコメントごと転載されてました。そのおかげもあり、書いた次の日(日曜日)は1600PVくらいありました。でもその翌日にはほぼ0までPVが下がり、増田まとめみたいなブログから毎日1-2PVくらいある程度。あとはTwitterからのリンクで毎日2-3PV程度。広告をしてなかったらほぼPVが0というひどい現状に、自分でも気持ち悪くなってきました。
1月に「おかあさんといっしょ」で流れていた今月の歌のタイトルで検索してサイトに来てくれる人がけっこういて、100PVくらいになりました。あとは「辻ちゃん」とか「離乳食」とか、ニッチなのかよくわからない検索からも少しPVがありますが、ほとんど直帰ユーザでした。たぶん他の探し物をしているときにたまたまうちのサイトが目についてアクセスしてみたけど目的と違ったから離脱したんだろうね。ここをもうちょっとアクセスを増やしたいと思ってます。
いまは、PVはほとんどないけどサイトは一応完成しているから、もっとアクセスを増やしてサイトを活性化したいと思っているところです。
独身男性は、専業主婦って毎日暇してるんでしょって思ってる人もたくさんいますが、子育てしてる人(赤ちゃんとか小さい子どもがいるママ)は毎日忙しいんです。そんな人たちをターゲットにしてるサイトだから、ダラダラ時間を使わせるよりも効率よく有用なツイートを探せるサイトにしたいなあ、と思っています。
さて、なんでこの記事を今更書いてるのかというと、Webサービスを作りたい人が集まってる「はてな」だけど、作っても私みたいに失敗に終わる(アクセスがほとんど集まらない)ケースもあるんだよっていうことを伝えたかったんです。まだ1ヶ月だからこれからだよ、という意見もあると思うけど、1年以内に10000PV/日を目標にしているので、その目標を達成できなかったらサイトを閉じよう、と決めているので、どうにかしてアクセスアップの方法を模索しているところです。
アクセスアップ、で検索すると「トラフィックエクスチェンジ」というサービスがいくつか見つかりましたが、これはBOT巡回みたいなもので良質なアクセスは望めそうもありません。あとは記事数を増やすか、広告にお金をつぎ込むかだと思うんですが、なにせ個人でやってるのであんまりお金もありません。
聞いたところによると、Twitterで影響力がある人にRTされるとアクセスが増えるらしいです。が、私のフォロワーにはなかなかそういう人がいないらしく、Twitterからのアクセスはほとんど期待できません。感覚値では、フォロワーが100人だろうと1000人だろうとあんまり変わらないです。いくつRTされるか、にすべてがかかっていると思います。
ということで、いまはRTを増やすこと(=アクセスアップ)を目指しています。そのためにコンテンツを用意しました。ママや主婦や女の子が簡単に使える顔文字ペースターです。
http://kosodate-now.com/kaomoji
「ヾ(๑╹◡╹)ノ" かわいい顔文字でツイートできるよ ♥ ☺」
といったツイートを、辞書登録とかコピペなしで作れるページです。これもいまいちウケがよくないので、私はWebサービスを作る才能がないのかなあ、と思ってる今日このごろです。
あ、ちなみにサイトはPC専用です。私はケータイを持っていないので(iPhone使ってる)ケータイからの画面確認はしてません。そのせいかな?
あと、HDMIの中を通っているオーディオはビットストリームで送っていない大抵の符号化の場合アナログなのでアナログ劣化はする。
音声がアナログってところ詳しく
テレビに繋ぐ場合 テレビ側がHDMIなのでDVIケーブルでもHDMIケーブルでも同じだが
モニターに繋ぐ場合 モニター側がデュアルリンクの可能性があるので
うかつにHDMIとDVIケーブルが同じ というのはやめてくれという話。
言うならばせめて、シングルリンクで使う場合と枕詞をつけて欲しい。
テレビに映る画質が異なるという話に対するツッコミではなくて、
DVIケーブルとHDMIケーブルが同じという発言に対するツッコミ。
あと、ケーブルの話については
異なるケーブルを使った場合、DeepColorでリンクしていたものが、ケーブルのつなぎ替え時の何らかの障害でDeepColorじゃなくなる可能性
などは起き得るので かならずしも色劣化が置きないとは言えない。EDIBの交換にバグで失敗するソフトも極稀にあるのでなんとも言えない。
また、中継装置(w)のおかげで変なリンクになっている可能性も多々ある。
DVIはアナログでつながることもあるし・・・HDMIはどうなんだろ。アナログOverHDMIもたしかできるよね。過渡期制限で。
あと、HDMIの中を通っているオーディオはビットストリームで送っていない大抵の符号化の場合アナログなのでアナログ劣化はする。
そういう意味では、オーディオマニアというなら、オーディオは光で別ケーブルで送れ。と思わないこともないが AD変換2回やるか?という疑問もあるので微妙。
でもでない。
やべーわー。盛り上がりがやべーわー。
やべー。超絶少女だわ。
腹いっぱいに何かを食う。
いやーVIPとここの相性がよすぎて笑えてくるぜぇ。
なんたって、気分屋だからね。僕は。
マジでクソ面倒なことをするよ。さすがに俺も切れるよ。
ぶち切れるよ。闇に抱いたこの気持が爆発するよ。
加減を知らないことがぶち壊れるほど届くよ。
きっと、だれにも分からないパワーだよ。パワフルだよ。
だれにも分からないパワーで弾けるパワーでゴーゴゴー!
叫び倒すよ。闇に紛れたその正体。
俺はまだまだ生きている。慣れてくりゃ楽なもんだな。
叫んでも叫んでも届かないこの想い
パソコンもってどこへいくの。歩き続けてどこまでいくの。
君に敗北を。敗北を知りたい・・。
はい僕。やるせなさがトップサーティーンを越えていくぜ。
理想の結婚は誰の手に?
俺はただ己の幸福を追求するぜ。誰がなんといおうとな!!
ハイテンション!!!!!!!!!ザッツハイテンション!!!!!!!
ヤレヤレ… ヽ(゚~゚o)ノ アキマヘンワ
ヽ(´▽`)/呆れるほどに!!!!!
構わないぜ、ロックンロールだぜ。
チャンスメイキングがしっかりされてるぜ。
びっくりするほどユートピア!ピュアな初心が神様のごとく現れては消えて、ぶち飛ばす。
闇に消えていく理解もその月も果てのないワールドに迷いこんでしまった。ザ・ワールド!!
とにかくとにかくハッピーでたまらない。元気でいいね。まさにそのとおりだよ!!
もう目の前には希望しか見えない!我慢ベールチーズ!!!!!!!!!!!!!!!!!
真っ暗だ!!!!!!!!!!!!!!!!!!!!!!!!!!!
すごくすごく幸せだ!!!!!ベールに包まれた「それ」がむき出しになるとき!
テクニシャンが多すぎる!!!!!!!好きなメロディーに乗せて。君をどこまでも飛ばしていくよ。
楽しみにしてるのはジョジョ会。痴女会。相談あんだセクフレに「バカヤリチン変態エロ!」
それいけアソパソマソ!ぐっばい昨日の僕!!!!!!!!!!!!!!!!
ジャストフィット!どこまでも続いてくこのレールに乗っかっちゃってもいいのかい?
続く歴史に涙はあるのかい?勇気を振り絞って出た答えが「NO」ならば俺は一体なんのために生まれてきたんだい?