2012年1月25日水曜日

クラウドとはなんぞや


ちょち最近クラウドについての話題がGoogle+で出てくるんで書いて見た。
長文すまん。

■仮想化の流行
ここではCPUの仮想化、サーバの仮想化に絞って説明する。簡単に言えば「一つの物理サーバ上で複数のOSを同時に動かす」事である。この仮想化が流行ったのは以下の理由だ。

  • CPUの性能向上手段がマルチコアに切り替わった
  • 従来のプログラムの多くがマルチコアを活用しきれない

今までのCPUはコア自体を改善する事で性能向上を果たしてきた。その為多くのプログラムは1コアを前提として作成された。それでもCPUのコア性能がどんどん改善された為プログラムを放置しておいてもプログラムの処理速度は向上していった。しかし最近になりCPUのコア改善によるCPUの性能向上が頭打ちになった為、CPUは出来るだけ沢山のコアを詰め込む事で性能を向上させる手段に出た。多くのプログラムはマルチコアを想定して作られていないので、沢山あるコアを活用出来ず、プログラムの処理速度は向上しなくなってしまった。簡単に言えば8コアあっても1コアしか活動していない状況になってしまったのだ。
8コアあっても1コアしか活動してないのであれば非常にもったいない。元が取れていない。

そこで従来のサーバを仮想化し、8コアの物理サーバに8個の仮想サーバをぶち込めば、CPUコア全てを使い切る事が出来る、と考えて始まったのが仮想化の流行である。更に言えば8個の仮想サーバはそれぞれ役割が違うだろう。それぞれの仮想サーバが高い処理能力を必要とする時間がずれていれば、8コアじゃなくて4コアでも充分かもしれない。であれば8コアの物理サーバに16個の仮想マシンを入れる事も可能である。
極端な話を言えばそれまで100台の物理サーバで運用していたサーバ群を仮想化して5台の物理サーバ上に集約する事も可能な訳だ。

■過剰集約問題

しかし場合に依っては「100台のサーバ群の総合性能≒5台のサーバ群の総合性能」なパターンが生まれる事がある。生まれる理由としては以下の様なモノが考えられる。

  • 無計画な集約
  • 仮想化環境への追加投資が出来ない為の過剰集約

これを防ぐには以下の対策が必要である。

  • 最大負荷時を想定した仮想化環境の準備
  • 仮想化環境利用の制限

この様な対策をする位であれば仮想化による集約を行わない方が良い。前者の対策をとる場合、仮想化対象の物理対象の総費用より仮想化環境構築用のサーバの総費用の方が高くなる可能性すらある。

■余剰リソース問題
過剰集約が怖いので少し余裕を見て10台の物理サーバを仮想化し5台のサーバに集約したとする。が、しかし予想以上に仮想サーバは利用されず効果な仮想化用物理サーバが遊んでしまい投資コストの回収が出来なく成ってしまう。

※投資コストの回収・・・高いモノを購入した後それをシコタマ使って元を取る事。投資コストが回収出来ないといった場合、それは高いモノを買ったはいいけど余り使ってない状態になってしまう事。

■仮想化からクラウドへ
そこで以下の様なパターンが生まれてくる。
社内のサーバの仮想化による集約は成功した。しかしリソースが余っている。もったいない。何かいい方法はないか
まてよ?この余剰リソースを外部に有料で貸しだそうか。そうすればサーバの稼働率も上がって投資コストも回収出来る上に儲かるぞ
まてよ?儲かるんであれば大規模な仮想化環境を用意してその上の仮想リソースを販売すればこれはビジネスになるんじゃないか?
しかも利用者は、必要な時に必要なだけのリソースを私から借りればいい。初期コストはゼロだ。
 これを実践したのがクラウドサービスである。

■クラウドの境界線
日本国内では「仮想化すればクラウド」と誤認される事、誤認させる記事や情報が多いが、仮想化は飽くまでクラウド実現の一要素に過ぎない。仮想化とクラウドは別ものである。具体的に言えば以下の通りだ。

・仮想化用の物理的サーバを保有或いは確保した時点でそれはもうクラウドではなくなる。


「本当のクラウド」の利用者は自分達で物理サーバを用意する事はない。つまりこの時点で国内で推進されようとしている「自社内に作成するプライベートクラウド」は否定される訳だ。

・必要な時に必要なだけリソースを借り、不要な時は不要なリソースを捨てる事が出来、そしてやめたい時は即座にやめる事が出来なければクラウドではなくなる。


この時点で課金単位が月次、週次、日次であるサービスは否定される。人間の生活サイクルを考えた場合サーバの負荷の変動は一日毎にサイクルしていくだろう。であれば課金単位は時間単位であるべきである。究極の所、理想は秒単位であるが手間を考えたらやはり時間単位に落ち着くだろう。
同時に時間単位課金であれば、リソースを借りる速度(申し込みしてから実際にリソースが渡されるまでの時間)が1時間以下である必要がある。「今日申請したら明日利用出来ます、来週から利用出来ます、来月から反映させます」なぞというのは問題外だ。

仮想化ではこの様な事が出来ない。
仮想化によるサーバ集約だけではここまでは出来ない。
プライベートクラウドではこれを実現出来ない。
つまりここクラウドの境界線である。

■クラウドの真髄
イノベーションとはそれまで出来なかった事が出来る様になる事である。世に言うイノベーションを例に挙げると例えばテープに対するCD、CDに対するMP3とか。
例えばCDはそれまでテープでは不可能だった瞬時の頭出し、精確な曲送りを可能にした。
例えばMP3はそれまでCDでは不可能だった自由な曲の組み合わせ、移動の簡単さ、バックアップの簡単さ、再生の簡単さ、保存の簡単さを実現した。

ではクラウドがイノベーションである点は以下の通り。

  • 従来では保持出来なかった様なリソースを利用する事が出来る
  • 不要なリソースを保持する必要がない

どちらも従来の社内サーバ環境で実現する事は出来ない。同時に仮想化による集約を行っただけでは実現する事が出来ない。
クラウドでなければこれらのメリットをもたらす事が出来ないのだ。

例えば分散処理を考えてみよう。ある会社で給与計算が分散処理で行えたとする。ここではAmazon EC2をモデルに話をする。

さて給与計算は基本的に一ヶ月に一回だ。
なので30日中「給与計算をする為に必要なリソース」は一日だけであるとする。であれば残り29日間は給与計算の為のリソース(給与計算をする為のサーバ)を持っている必要はない。つまり費用はゼロ円である。

「さーて今月は特に急いでないから計算に一日かかってもいいや」と成れば、「性能は低いが一時間辺りの利用料も格安のクラウド上の仮想マシン」を一日借りて計算すればいい。
「やばい!明日給与支払いなのに計算してねぇ!後12時間しかない!ええい多少金かかってもいいから確実に終わらそう!」と思えば「性能は高いが一時間あたりの利用料金も高いクラウド上の仮想マシン」を複数借りて一期に分散処理してしまえばいい。

勿論給与計算が終わったらそれらのリソースを解放する。そうすれば再びコストはゼロだ。
そしてこのコストがゼロに出来る、まぁ精確に言えば不要な時はコストを極小化出来る、という事がクラウド最大のメリットだと思う。これは従来の物理サーバ購入では絶対に実現しえない事である。

■クラウドの定義
最後にまとめ。クラウドと呼ぶに値するサービスが備えるべき条件

  • 初期費用がゼロである
  • 利用した分だけ課金される(金さえ払えば無尽蔵にリソースを利用出来る)
  • 下院単位は最低でも時間単位である
  • 利用者からみて無尽蔵に見えるだけのリソースを確保出来ている
  • リソースの要求をしたら遅くとも1時間以内に利用する事が出来る

と言った所ですか。

2012年1月19日木曜日

Sphinxのバージョンアップをする

Sphinx1.1から1.1.2に上げた時のメモ。

Sphinxの最新版を手に入れる。PythonのこのページからDL出来るっぽい。

■事前にやる事
/usr/local/lib/python2.6/dist-packages/Sphinx-1.1-py2.6.egg/
の中にあるthemeとか加工したソースとかを待避させておく事。

■旧Verの削除と新Verのインストール
sudo rm -fr /usr/local/lib/python2.6/dist-packages/Sphinx-1.1-py2.6.egg
wget http://pypi.python.org/packages/2.6/S/Sphinx/Sphinx-1.1.2-py2.6.egg#md5=d35db7a8ee62dd55522bca523954baa9
sudo easy_install Sphinx-1.1.2-py2.6.egg
終わり。

2012年1月18日水曜日

今日のsphinxメモ

sudo vi /etc/apt/sources.list

deb http://ppa.launchpad.net/vineuser/ppa/ubuntu oneiric main
deb-src http://ppa.launchpad.net/vineuser/ppa/ubuntu oneiric main

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0C95CAFC

sudo add-apt-repository ppa:vineuser

sudo aptitude update

sudo apt-get install texlive texlive-base ptex-base ptex-bin dvipsk-ja xdvik-ja ptex-jisfonts gs-cjk-resource jmpost dvipdfmx texlive-math-extra okumura-clsfiles jbibtex-bin mendexk texlive-latex-extra nkf dvipng python-software-properties python-sphinx

2012年1月17日火曜日

SphinxでHTMLでもPDFでも見やすい文書を一発で作る

昨年の秋位から Sphinx を本格的に使ってきたので色々メモした事、やった事をまとめて見る。Whyの部分は後で拡充するかも。

後これは俺が買って考えた事なので、これよりいい方法とか知ってる方いたら是非に教えてください。マジで。ホントに。
尚Sphinxを使える用にして、PDFまで出力出来る様にする方法は Sphinxとrst2pdfの「domains」がないよエラー を参照してください。


■やらないといけない事
取り敢えずやらないといけない要件は以下の通り。
  1. HTMLはHTMLで見やすく。PDFはPDFで見やすく。
  2. PDFは各章に通し番号を振る。HTMLは振らない。
  3. PDFは見出し必須。しかし見出しに載せる深さは2番目まで
  4. 内容的に同一の文書を使い回す場所がある。
これに加えて、HTMLとPDFの両方を作る場合以下の問題もあった。(今はもう Sphinx とか rst2pdf 側で対応してるかもだけど。)
  • HTMLを重視する場合、toctreeを使えば1ページに見出しだけが全てそろうので目的のページを探しやすく移動しやすい
  • PDFの場合、toctree を使って書くと章の番号を振るのがおかしくなる。
  • toctree はリンクになってしまいリンク先のページは個別で評価、変換されるっぽいのでPDFの場合だと章段落の程度がおかしくなる
  • include を使えば多数のファイルをマージして(1ファイルにして)から評価変換される用なので章段落の程度がおかしくならない。しかしHTMLだと一個のHTMLが巨大化してしまい死ぬほど見にくい。
つまり toctree は HTML と相性が良く、include は PDF と相性が良い。


■HTMLとPDFとを分けて考える
という事で「HTML用のRootドキュメントとPDF用のRootドキュメントを分ければいいんじゃね?」と考えて、調べてみたら出来るっぽい。Sphinxの conf.py の以下の場所の「indexPdf」の部分を変更する。
pdf_documents = [ ('indexPdf', 'Manualタイトル', u'Manualタイトル', u'Author', 'manual'), ]
初期値だとHTMLのと同じ奴に設定されてるけど、ここを変更するとPDFを作成する際はここで指定されたファイルをRootドキュメントにして作成してくれるようになる。こうしておけば make html pdf って一個のコマンドで違う構成ファイルを元にしたHTMLとPDFとが同時に作れる様になる。


■RSTファイルの構成
次に実際に利用するRSTファイル群は以下の様な構成に成っている。
  • index.rst ・・・ HTML用のドキュメント構成。ページ構成のRSTファイルを toctree で記述。
  • indexPdf.rst ・・・ PDF用のドキュメント構成ページ構成のRSTファイルを include で記述。
  • page.rst ・・・ 章構成。実コンテンツの本体。基本的に重複のない文書を書く。HTML用もPDF用も共通。 paragraph.rst を全て include で記述。 
  • paragraph.rst ・・・ 各パラグラフ。使い回す可能性のある文書はここに書いている。HTML用もPDF用も共通
index.rstは以下の通り
########
各章タイトル
########


.. toctree::
:maxdepth: 1


hoge
fuga
pugya
homu
indexPdf.rstは以下の通り。PDFの場合、各章の頭に数字を振りたいのでそのコマンドを先頭に入れておく。
.. section-numbering::


########
各章タイトル
########


.. include:: hoge.rst
.. include:: fuga.rst
.. include:: pugya.rst
.. include:: homu.rst
Sphinx公式のセクション管理 にSphinxでのセクション管理の例が載っているけど、私は以下の様なルールでセクションを利用している。
ただしpage.rstに関してはかなり流動的。使い回す可能性のない説明であれば、一番したのパラグラフまで使う事もある。
  • # 部: オーバーライン付き ・・・ index.rst/indexPdf .rst で使用
  • * 章: オーバーライン付き ・・・ page .rst で使用
  • =, セクション  ・・・ page .rst、 paragraph.rst で使用
  • -, サブセクション  ・・・   paragraph .rst で使用
  • ^, サブサブセクション  ・・・   paragraph.rst で使用
  • ", パラグラフ  ・・・   paragraph.rst で使用


■ PDFでの改ページ処理
一応rst2pdfには自動改ページ設定機能があるがこれが結構微妙。ルール一辺倒なのでいやここは・・・って所でも改ページしてしまう。なのでこれを使わず、面倒だけど自分で改ページを指定する事にした。

まずconf.pyの以下の設定をコメントアウトして自動改ページを無効にする。
#pdf_break_level = 2
で代わりの改ページ指定は、改ページしたい所に以下の記述を加えておく。これを入れておくとHTMLの方では何も出力されない。だけどPDFを出力する時のみ改ページ処理が行われる。
.. raw:: pdf


PageBreak
なお私が作ったドキュメントではこのPDF用改ページコマンドをpage.rstに末尾に必ず追加している。


■DPFの目次管理
次にPDFでのページ管理。toctreeを使うと目次っぽいのが勝手に出来るけど、includeを使うとそれが生成されない。なので rst2pdf の機能を使って目次を生成する。
また目次を設定する際、上から2番目(1.1 インストール方法)までを目次に載せるように設定する。これを指定しないと全てのセクションが目次に載ってしまう。(例えば 1.2.3.4.5 注意 とか)。
その為に conf.py に以下の設定を追加する。
pdf_use_toc = True
pdf_toc_depth = 2
目次に載せるセクションの深さは数字で自由に変更出来ます。


■ただ一つの欠点
これでHTMLとPDFの両方が見やすくなったと思う。
ただ唯一新しい章を追加する際にindex、indexPdfの2つに記述しないといけない事が面倒だけど。

参考になるURL

2011年12月28日水曜日

オライリー Cassandraをいただきました!

Cassandra
CassandraEben Hewitt 大谷 晋平

オライリージャパン 2011-12-24
売り上げランキング : 7820


Amazonで詳しく見る by G-Tools

訳者の一人である小林さんから献本を頂いたので早速ざっと目を通してみました。
私自身、Cassandraは0.6辺りからずっと触っているのである程度は理解してはいるつもり。その上で読んだ感想です。

まず最初にRDBMSの説明と弱点。つまりCassandraを含むNoSQLが必要とされた背景の説明。次いでCassandraの説明がはいる。そこでブリューワのCAP定理の説明もはいる。CAP定理に関しては分かり易く説明されてると思う。

続いてCassandraの利用事例。NoSQLはDomain Specific Databaseなので用途や使い所を誤るともう目も当てられない。だからCassandraがどういう用途の為に作られ何に向いているのかはしっかり理解しておこうね。

続いてCassandraのインストールの話。まぁこれはまんますね。これに続いてCassandraのデータモデルの話。RDBMS一筋な仕事場から来た人が恐らく最初に躓く所だと思う。中々構造体を理解出来ない。まぁRDBMSのデータモデルが二次元で収まるのに対して、Cassandraのは3次元な構造だからね。イメージしづらいんだと思う。
ただCassandraのデータモデルはもう一方のNoSQLの雄、HBaseと酷似してるから覚えておいて損はないと思う。

Cassandraのアーキテクチャの話は結構重要だと思う。Cassandraを構成する各種技術やらアルゴリズムって最近流行の分散処理の基本的なモノが多いから、これらを理解しておく事はそういった方面の理解を深める事にもなると思う。仮にCassandra使わないけど分散処理するアプリを作るなら相当参考になると思う。
設定とデータの読み書きに関してかなり詳しく書いてあるのはヨサゲ。この辺り理解しておけばトラブった時にも対応が簡単になるしね。設定に関しては前章のアーキテクチャの話も結構絡んでくるね・・・。
あとここでCassandra最大の問題、レンジゴーストに言及してる。ただこれに関してはもうちっと説明欲しかったな。後対策。

監視やらメンテナンス、後パフォーマンスチューニング等運用に関する情報が多いのもいいね。実際RDBMSの運用と違ってDBが生きたまま、動いたままの状態でメンテやらなにやらやる事が多いから、監視と運用ノウハウは必須。パフォーマンスチューニングはCassandraが動き始めた後と、設計段階でのデータ設計でのチューニングがあるけどここでは基本前者のみかな。まぁデータスキーマの話の所でしっかり理解しておけば事前のチューンは充分出来ると思うけど。

Hadoop連携はまぁHadoop使える位だったら分かるしょ。CassandraよりHadoopの方が遙かに複雑だし・・・。

後は0.8~1.0で搭載された新機能の話。ここで一番大きいのはSQL見たいなQuery言語が使えるCQLかな。CQL使えばSQL脳な人でもかなり使いやすくなると思う。分散カウンタに着いての話もあるけどこっちの機能は・・・。

最後にNoSQL全般の俯瞰。最初の方でも言ったけどNoSQLはDomain Specific Databaseなのでそれぞれの用途と特性をしっかり理解して使わないと危険。そういう意味でここで他のNoSQLがどんなモンかをしっかり理解しておいた方がいいと思う。

まとめ
ネット上に散らばってるCassandraの情報は大体ここに収まってる感じ。だからこれからCassandraを使おうって人はこれ一冊あれば事足りるんじゃないかな。後Cassandraは使わんけど、分散システムには興味或るって人とか、或いは普通にシッステム開発してる人が読んでも結構勉強になると思うよ。

クラウドで実用に耐えるアプリはほぼ分散アーキテクチャなので、従来の構造のアプリしか作った事がない人はこれを読んで分散可能にするにはどうしたらいいかを学ぶといいと思う。


2011年12月22日木曜日

小学生なのはは魔法の取り扱いをミスっても許されるか

子供が失敗を許容されるというのならば、なのはやほむら達が間違った選択をしても許されるだろうか?
或いは子供の将棋の大会で一手を失敗したから許して巻き戻すって事があるだろうか?
なのはの場合あの兄弟な力の元で判断を間違えれば街一つぶっ飛ばす事もあるだろう。
ほむらの場合失敗しても巻き戻ってやり直せるからいいかもしれないが、誤ってしまえば人類は死滅する。
※なお作者はどちらの作品もTVきちんと見てません。

では彼女らと普通の子供は何が違うか。立場と能力だ。
大人であっても新卒、つまり能力も立場もまだない状態であれば失敗はある程度許される。

では大人の失敗は許容されるか?
それは恐らく文化次第だろう。例えばジョブスなんて大失敗を重ねている。しかし彼がいた文化圏では何度もチャンスが与えられるので、、ついに彼は成功にたどり着く事が出来た。
或いは資金が100兆ある企業で10億円の失敗をした所で、それは怒られる事はあれど許容はしてくれるだろう。
では日本ではどうか。
最近、一度盛り上がった話で「一発アウト即退場な日本」と言うのがあった。例えばWeb、会社などで何か世間に広まる失敗を一度でもすれば祭りという形で徹底的に叩かれ、二度とに日の目を浴びないように持って行かれる事が多々ある。
個人的には大嫌いだが、ホリエモンなんかがそうだろう。

「お天道様に顔向け出来ない」って言葉がある位に日本は失敗した事を自他共に根に持っちゃうんだろうね。土地的に移動も出来ないから、皆が自分の失敗をしってる所でしか生活できない。
一方でアメリカなんかは失敗した所で開拓地送りっていう言葉があるくらいに別の場所に行けばまたチャンスはある。

ま、という訳で失敗の許容可否は大人か子供かじゃない。
能力と文化だと思う。
日本の共同体みたいな所じゃ失敗したらそれをしない方が安定するしね。アメリカみたいに移動共同体だったら向こうじゃ失敗したけどこっちじゃ巧くいくかもって形で技術やアイデアすら失敗を許容されてただろうし。

という訳で会社を選ぶ時は「失敗を許容してくれる」会社のがいいかもね。
それはつまり社内に「お前が失敗した所で俺が補填出来るよwww」って高い能力を持った人がいるって事だしネ

2011年10月26日水曜日

兎に角ブラウザを速くする。

■Firefox CPU特化ビルド
普通のFirefoxじゃ使われないCPUの機能を根こそぎ使って速くした奴。 毎日最新盤をビルドしてる。
http://fbuild.com/ 

また動かないadd-onは下記のadd-onを使って無理矢理動かす。
まぁ大概は問題なく動く。

FirefoxのGPU支援有効化
 URLの所に「about:config」と打ち込んで下記の値を設定する。もし値がない場合は作成する。数字はinteger、他はBoolean。

mozilla.widget.render-mode → 6fx.direct2d.disabled → false
fx.direct2d.force-enabled → true
gfx.font_rendering.directwrite.enabled → true
gfx.direct2d.force-enabled → true
gfx.font_rendering.directwrite.enabled → true
layers.acceleration.force-enabled → true

■FirefoxのCache領域をRamDiskにおく
これも about:config から設定する。RamDiskがRドライブならば
 browser.cache.disk.parent_directory → r:\firefox\




Chromium最新盤
Chromiumの最新ソースのビルド。ほぼ毎時ビルドが走ってる。結構バグり安い。
http://build.chromium.org/f/chromium/snapshots/Win_Webkit_Latest/?C=M;O=D

ChromiumのGPU支援有効化
URL表示される所に「about:flags」と入力して、隠し設定画面へ移動。そこにある下記の設定項目を有効化する
すべてのページで GPU 合成を行う


■ChromiumのCache領域をRamDiskにおく
Windowsのジャンクション機能を使う。コマンドプロンプトで下記コマンドを実行
mklink /D "C:\Users\${USER}\AppData\Local\Chromium\User Data\Default\Cache" R:\

Fluent入れる迄のメモ

Installing RVM
Installing td command on Debian and Ubuntu
Installing td-agent for Debian and Ubuntu

2011年10月24日月曜日

内田研究室の記事を見て

取り敢えず電車の中で思った事をまとめてみる。以下の奴読んでおくこと。

格差と若者の非活動性について
いち若者の立場から、若者が何も主張しない理由を主張してみる
若者は何も言わず、ただ去るのみ
Facebookの普及に見る米国の社会階層性と、『米国=実名文化論』の間違い
「ワンピース世代」の反乱、「ガンダム世代」の憂鬱
※これに加えて、GREEやらモバゲーで課金するのは「自分が所属するチームや仲間内で褒められたい、貢献したい」とする動機からってblogも参考に。

で上記のを読んで思った事をつらつらと。

機能不全社会に育った子供は、親が変わってくれることを期待するのを諦めて、親に働きかけるのをやめて、親に向けるエネルギーと時間を、自分自身を何とかしていくために使ったほうが良いと悟るようになる。それと同じことが起きているだけだ。
これを読んで思い出したのが、上記のモバゲーとかの話。課金する事で自分のチームメイトからは簡単に賞賛の声がもらえる。だから貢献したくなる。結果として簡単に課金する。ある意味、仲間に認められないと生きていけないから。

例えるなら、長年抑圧され続けて、夫と話し合うことすら面倒臭くなった妻が、夫を表面上黙ってやり過ごしつつ、密かに仕事と住む場所と弁護士を用意して、準備が整った時点で、ある日突然夫の前から姿を消すようなもの。一番省エネかつ効率的かつ自立的な離婚方法だ。
んでもってこの一文で思い出されたのが、核家族化であるし自分自身が考えた「大学生になれば親元離れられるからそれまで我慢」という判断。
核家族化が進むのもコレが原因だと思う。経済的な事を考えれば多分同居した方が効率いいはず。 でもそれ以上にもう戻りたくない。ホントに気持ち的は離婚した相手に会いに行く位の億劫さがある。

で、やっと親元を離れて自由になった! だから子供なんて作って自分の時間を無駄にしたくないし、そんな金あるなら自分のやりたかった事をやる、モノを買う。結果少子化にも繫がると思う。
で万が一子供が出来てしまった場合「やっと自分のやりたいことが出来る筈なのに」子供の世話に時間を取られたり、子供が言うことを聞かないからどうしても排除したくなる。そうなれば子供放置とか色々なモノに繫がると思う。


さてこの話はワンピースに繫がると思う。
ワンピースのキャラって殆どが本来居るべき場所なのに元々虐められているか、居場所が無かったり、はじかれちゃった人。或いは居るべき場所にいられなくなった人。個人的にサンジ編までしか覚えてないんだけど、サンジなんかは正にそうだと思う。

昔は白馬の王子様を待つ乙女、って言うのがあったけど、今の若い人達はルフィみたいな人を求めてるんではないだろうか。いつか俺にも活躍できる場を与えてくれる人が現れる、認めてくれる人が現れる。 そういう期待。だからワンピースに出てくるキャラに自分を重ねてる様な気がする。

一流大学を出て、一流企業に勤めて、35年ローンで家を建てて、年金もらうようになったら「蕎麦打ち」をするような人生を「報償」として示されてもあまり労働の動機付けが高まらない。
んで次にここ。 同じ論法がTVにも言える気がする。
多分今の「最近の若者は~」って言ってる世代の人はTVにあこがれた世代で、今代に或るTVは正に夢のTVなんじゃないだろうか。巨大で、色が綺麗で、立体的に見える。
TV離れとか言うけど結局は自分が好きだったモノが、自分の信じるモノが否定されるのが怖いだけな気がする。だからこそ、TVを売りたがるし、TVや新聞を信奉したいんじゃないだろうか。 彼らは「せっせと働いて、お金を貯めれば大きなTVを買えるよ!」という自分たちが完遂出来なかった目標、理想を下の世代に転嫁している様な。 




 さて最後にFacebook。
そして当初Facebookを学内に広めるのに大きな役割を果たしたのが、ハーヴァード大学に多数あるさまざまな社交クラブの存在だった。
本人の資質だけでなく家柄や財産などによっても選別されることになる。普通の大学よりも、より将来に向けた――あるいは在学中にはじめるビジネスの――人脈作りという傾向が強い
Facebookは人々に米国的な「社会的上昇の物語」を疑似体験させることを通して、実名登録制への抵抗を意識させずに、順次拡大
つまり、高級社交クラブにいるという証明が、自分の将来にとって有利に働く。恐らくアメリカでも実名がばれる事のリスクはあるだろうけどそれ以上に「社交クラブに実名が載ってないとお話にならない」世界があるのだと思う。
だからこそFacebookは実名でも受け入れられた。 受け入れられたというより、そもそもFacebookが電子化したのは実名でこそ成り立つ社交クラブだったから、と言う方が正確なのかも。

で日本の場合、とあるコミュニティに所属した所で、そこにいる事は即メリットにはなりにくい。場合によってはそこに所属してる事で馬鹿にされたりデメリットになったりする。この辺りは同業他社に転職した人を排斥する文化にも繫がると思う。
そして東電の様に、それまでは所属している事がメリットだったけど、ある日突然それがデメリットになる事がある。所属している事をデメリットにする上層がいる、とも言えるかも。 そうであればやはり実名は忌避されてもしかたないと思う。

2011年8月17日水曜日

ハードウェアをフル動員してFirefoxを早くする。

  • 64bit環境
  • CPUがCore2Duo以上又はCPUがAthlon64以上
  • DX10以上のVGA
人はまずはここからFirefoxをダウンロード。
http://fbuild.com/


続いてURLの所に「about:config」と打ち込んで下記の値を設定する。
もし値がない場合は作成する。数字はinteger、他はBoolean。
mozilla.widget.render-mode → 6
fx.direct2d.disabled → false
fx.direct2d.force-enabled → true
gfx.font_rendering.directwrite.enabled → true
gfx.direct2d.force-enabled → true
gfx.font_rendering.directwrite.enabled → true
layers.acceleration.force-enabled → true
また動かないadd-onは下記のadd-onを使って無理矢理動かす。
まぁ大概は問題なく動く。

http://www.oxymoronical.com/web/firefox/nightly
https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/?src=api