Tuesday, December 29, 2015

AKBについて



AKB批判をするやつっていうのが僕の身の回りの音楽関係のやつにもいて、僕はその批判自体を批判するっていう気はあまりないんだけど、

AKB商法っていうのは実はとっても画期的なんだなということを最近理解した。

まず前提としてアイドルとか、芸能人とかっていうのはそれ自体がキャラクター「商品」である。

(i) 単一モデル(中森明菜、山口百恵、松田聖子、薬師丸ひろ子、酒井法子、ジャスティンビーバー、マイケルジャクソン)

がこれまでは主流のアイドル商法だったけど、これはそのアイドルが何かしらスキャンダルでこけたり年を取ったりするともうそこで終了してしまう。(というと語弊があるが少なくとも需要は固定ファンにシフトする)これはその単一のアイドルの個人的スペックの異常な高さ(歌唱力、ダンス力、ルックス、キャラ)に依存している。

これはビジネス的にはモノカルチャー(単一主力製品に依存すること)である。

それを解決するために 多角的経営というのがある。

(ii) 複数モデル(SPEED、嵐、ビートルズ、ベビーメタル)
(iii) マスモデル(AKB、ジャニーズ、EXILE)

これはそれに位置している。商品の一つが購買力(ファン)とか求心性を失った場合、セットになった他の商品がそのリスクを吸収できる。 YAMAHAがピアノ以外にバイクとか売っているのと一緒だ。

 で、(i)(ii)と(iii)の違うところは、 (ii)はまだリスクがある。 4つある車輪の一つが欠けるってことはもうすでにそれ自体が大きなダメージとかイメージの低下になるからだ。

 (iii)のなかでもAKBが特に秀逸なのは、投票制度だ。投票制度があるということは、より具体的に供給側と購買側が「インタラクティヴ(相互作用的)」になっているっていうことで、(i)(ii)があくまで一方的な形をとっているのと違う。

秋本氏はこの「インタラクティヴ」をより強調した売り方をしたんだと思う。握手会しかり。

インタラクティヴを採用するとより「需要側」のニーズが自動的に供給側の政策として反映されるので、供給と需要の「ずれ」が極小化される。

また、先ほども言った通り、束(48)で売り出して入れ替わりをさせることで「飽きさせない」 また「スキャンダルとか個人の能力不足によるリスクを分散する」

ただしデメリットとしては、少数や単一で売り出していた時と違い、個々人のメンバーには「見られる」とか「パフォーマンス」といった観点での負荷が分散されるので、個々人のスペック(ルックスも能力も)はどうしても(i)(ii)と比較したら「劣ってしまう」

 なのでチームというコンセプトなんだと思う

 個人的にAKBを好きではないしアイドルも基本消費しないたちなんだけど、外野からは面白い商売だな、と思った

AKB商法は金儲けだ!と揶揄する人は音楽系にも多いけど、音楽業界で金儲けしなくてなにやるの?って話

というわけでAKB は画期的である

World Without Linux Final Episode: Free Burger

危ない親子関係3 3

Monday, December 28, 2015

納得







よかった

僕も大学時代池田先生に無視されたことがあったけど....

先生の仕様だったか

Saturday, December 26, 2015

日本拳法のスパーリングをやりました

今年も空しいクリスマスを過ごして意気消沈していたので、

昨日はすごくいい刺激になった。

はじめての乱撃(スパーリング)だったし、先輩方も手加減してくださったけど、やはりすごくつらい。足の筋肉群をものすごく酷使するし、今までの型と違って相手が動いたり躱したり攻撃してきたり重心をずらしてダメージをなくしてきたりするので、無駄な動きをしているとすぐに駄目になってしまう。

 ネットでは日拳がディフェンスが甘いとか書かれてるけどまずその考え自体が甘い。ディフェンスを常に使わないとやってられない。

ただ顔面の攻撃がありなので揚打(あげうち=アッパー)とか横打(フック)とか突き(ストレート)とか波動拳とか、中段突きとかのコンビネーションですごく楽しい.....

けど足の筋肉使いすぎてやばい

組技系は柔道と違って物理的につかめないので、その攻防もすごく大変。

突き蹴りとかも普通に使う

とにかくすごく生きてる実感がわいた

スパーリング童貞は捨てた!

これからもっと強くなる!!!!
 





関数型言語 三種の神器

関数型言語のパラダイムの恩恵の代表格として、以下のメソッドがある

map
filter
reduce (fold)

オブジェクトがクラスベースでものを考えるのと違い、関数型はcollectionベースでものを考える。

map

mapはcollectionの写像を作る。

例えば

map(lambda x: x*2,  [1,2,3,4,5])

だったら これは

[2,4,6,8,10]

を返す。これを手続き型(php?)で同じ処理やると

$y = array();
foreach(array(1,2,3,4,5) as $x ) {
     $y[] = $x*2;
}

とかなる。

これだけみても関数型がどれだけエコかっていうのはおわかりいただけるであろう。

filter

filterは特定の条件のelementのみを、collectionから抽出して同じくcollectionを返す

例えば

filter(lambda x: x % 2 == 0, [1,2,3,4,5])



$y = [];
foreach(array(1,2,3,4,5) as $x) {
    if($x % 2 == 0){
        $y[] = $x;
    }
}

は同じことをやっている。つまり特定の条件(ここだと偶数)の要素だけをcollectionとして返している


reduce (fold)

pythonでは reduceという呼び方だが、一般にはfoldと呼ばれることが多い(HaskellはfoldlだしScalaではfoldLeftとか)。まあコンセプトとして、一つのcollection(集合)を「折り畳む」とか「減らす、集約する」ということだ。

例えばphpなんかで、

$sum = 0;
$l = array(1,2,3,4,5);
 for($i=0; $i < count($l); $i++ ){
      $sum += $l[$i];
}

これで目的は 一つのcollectionの中身をいっこいっこ出して行って累積させていくのだ、が、これをreduce(fold)でやると

reduce(lambda x, y: x+y , [1,2,3,4,5])

つまり一行で終了。

全体的にみていても関数型の方がメンテナンスもしやすいし、コードの把握もしやすい(5000ページの書類と10ページの書類、どっちが読みやすいかってこと)し、「壊れにくい」


関数型が数学的だというのは、まず関数が第一市民であること(first class citizen)、 また、数学は、公式じたいスタティック(静的)で、

sin(θ) とかだったら、

sinっていう公式じたいの中身や状態が変化することはありえなくて、絶対そこは固定していて、パラメータ(input)と 返り値(output)だけが変化しうる状態、

これが関数型プログラミングが数学であり、 アカデミックであるゆえんなのだ。

 クラスという概念は、大量のコードを分類(分類はアリストテレスの時代から学問の基本)してわかりやすくしようという試みだったけど、結局弊害はあって、所詮データのあつまりだし、

「集合 」と「数式」で考えよう、

これが関数型。

よって三種の神器。

よって関数型を使えない言語はウンコ。

また、僕は(scalaなんかもサポートはしてるけど)シングルトンって考えも嫌いで、CPU二個になった今そんな考えで設計してること自体ありえないし、使うならせめて悪いことをしている罪の意識くらいは持ってほしい

ってくらい僕は極論を持っている。組み込み系の畑の人とかだとまた違った意見なんだろうけど、アプリケーションエンジニアとして状態に依存するコーディングなんてありえない。

食べかけのご飯を 部屋の隅に二ヶ月放置している家に虫(バグ)がたからないわけがない。

オブジェクト指向、手続き型を不特定多数で維持するっていうことはこれくらい罪深い。(アーメン)

デスマーチなんてほぼこれが原因であることが多い

以上。

Saturday, December 19, 2015

新曲


基本自分コードはマイナーで曲作ってく人なので、メジャーの鍵盤の使い方に不慣れな感じでやった ちょっとなれた

Saturday, December 12, 2015