/home/pochi/ChangeLog / 2014-02-19

■ オーケストラの中の1人のバイオリン奏者は何を考えてるか [音楽]

○○オーケストレーションというバズワードを最近良く聞く。
システムをオーケストラに例えて、うまく指揮をして協調動作をさせよう、
みたいなイメージなんだろうと思う。
意外と良い例えなんじゃないかと思うんだよね。

私がオーケストラの中でバイオリンを弾くときにどんなことを考えてるかというと、

- 大好きなフレーズは頑張るぞー。
- この曲はあんまり好きじゃないから適当に弾こう
- ここは難しいから弾くのをあきらめて、頑張る若者を心の中で応援だ。
- げげ、パートソロだ、真面目に弾かなきゃ
- テンポバラバラじゃねーか。指揮も見にくい。自分のビートを信じるか。
- まー、とりあえず前の人につけとくか。(合わせとくか)
- あそこのパートはちゃんとテンポキープしてるから基準にすれば良いかな。
- あんまり練習してないから、音小さめで安全運転で。
- 音程が隣と合わんなあ。自己主張して大きめで弾いてみるか。
- 隣が可愛い女の子だから頑張っちゃうぞ
- おやおや、隣が寝そうだぞ、つついとくか。
- 金管うるせーなー。負けねーぞー。
- 前の人の袖なし服のたるんだ二の腕の揺れがたまらん。
- 指揮者がはっきり拍を刻みはじめたぞ。たしかにここは危険よねえ。注意注意。
- 指揮者がわかりにくく振ってるってことは、流れをオケで作れってことね。メロディーに合わせとくか。
- それにしても指揮者の腰の振り方がエロいな。
- 抑えろ、と指示されたけど、これ以上抑えられないぞ。弾くのさぼっとくか。
- あそこのパートの弾き方、エロ恰好良いな。真似しよ。
- ここは通常より音程を高めに取らないとハモりが悪いから高めにして、と。
- ここは暗い曲想なので、音程を外すなら低め方向に、慎重に慎重に。
- 曲想に合わせて、低音が入った後に乗っかるイメージで遅めに入る感じで、と。
- ここは馬鹿っぽく弾くとこだよね。あはは〜
- 気合で乗りきるぜ、ガッツだぜ、うぉーーー。
- ここの音色は冷たいイメージで、、、でもテクニックが足らんな。気持ちだけ汲みとって欲しい。
- 隣がヤラしいビブラートかけて弾いてるな。真似しよ。エロエロ〜
- あのパート、いつもここで崩れるな。無視な感じで乗りきろう。
- ここはビジュアルでも魅せるとこよね。とりあえず大きく動いとくか。
- まだまだ先は長い、省エネ省エネ。

まあ、いろんなこと考えてるわけだ。
くだらんことも多いけど。
こういう人達が沢山集まってオーケストラは構成されるんだけど、
方向性をまとめて良い音楽を作るのは大変だよ。

ちなみに理想的なオーケストラプレイヤーは

- 正確なリズム感を持ち
- 正確な音程を持ち
- 和音感覚に優れ、
- 反射神経が鋭く
- 表現したいことをできるテクニックを持ち、
- 表現したいことがちゃんとありつつ、
- 他人の表現したいことを組みとれて
- 空気を読んでうまくやれて
- ビジュアルがいけてる

こんな感じの人なのかな。
プロの人はお金を取れるだけあってこういう基本性能は備えてるのよね。
基本性能が高い人が集まればより良い音楽を作れる可能性は高いし、
オーケストラとして失敗しにくくなる。

ちゃんとした高い機器を買っとけば、良いシステムが作れる可能性が高くなる、
ってのはシステムのオーケストレーションも一緒ではあるな。
基本性能が高いノードを集めても、方向性はまとめないと、
面白いことにはなって失敗するってのも一緒。

■ クラウドの再定義を促す、Infrastructure as codeという新しい考え方 [インターネット]

http://diamond.jp/articles/-/48920

佐藤一郎先生のコラム。

Infrastructure as codeでは、ネットワーク構成を含めて、
システム開発の対象すべてがソフトウェアになります。

システム定義もソフトウェアになるので、
なにかが必要になったら、都度システムごと作って、使い終わったら捨てる、
ってことが可能になるってことだな。

システムをどこに作るか、の自由度は上がる一方だろうなあ。
クラウド上でさくっと立ち上げても動かすのも良し、
手元のブラウザでJavaScriptを動かしても良し、
エミュレーション技術の進化も強烈なので、
どんどんなんでもアリになってくるだろうな。

となると、処理する対象のデータをどこに置くか、
ってのはかなり重要になってくるよなあ。
データへのアクセス速度を確保したり、便利なアクセスメソッドを作ったり、
そういうことも考えなきゃいけないだろうし。

そういう視点で見てもハイパージャイアントは強いんだよね。
データをたんまり握ってるわけだし。

プログラムはコンピュータで実行するものという固定概念から抜け出せば、
新しい応用はもちろん、新しい社会も作れるはずです。
皆さんもいろいろ考えてみてください。

リアルから仮想世界へというデータの流れが、今後は逆に流れる、
という話もある。--> [2014-02-12-1]

同じように、インターネットのムーブメントがリアルな社会を変化させていく、
ってのは確実に起こるんだろうな。
世界は変わりたがっているよ。

■ ネットワークアーキテクチャ考 — (9) Orchestration ! [インターネット]

http://gblogs.cisco.com/jp/2014/02/network-architecture9-orchestration/

河野さんのコラム。

オーケストレーションとは「自律的で多数の要素を有機的にまとめあげるための
レシピまたはプログラムをつくること」と定義できると思います。

インターネットを構成するノードは自律性を備えてる、
って言いきっちゃうのもアリかもなあ。

Cisco は伝統的に（?!）、管理システム系に弱いと言われていました。
実際そのとおりで（!!）、イノベーションは専らルータやスイッチに起こり、
管理システムはどうしても後手後手になります。

イノベーションはたしかにハードウェアの革新からおこるよなあ。

まずビジネス課題ありきで、そこから専らトップダウン的に技術に
落として行く、という方法に無理があるのではないか

ビジネス課題ありき、というアプローチは正しいんだけど、
時代遅れっぽくて、つまらんなあ、って思うのは、そういうことか!!
なんか腑に落ちたぞ。

では、オーケストレーションシステムに求められる特性は何でしょう。
私が最も重要視したいのはオープン性（Openness）、
そしてモジュラー性（Modularity）と拡張性（Extensibility）です。

たしかにそのへんは技術を評価するときに気にしてるかも。

個人的にはソフトウェア等を選定する際には、もうちょっとシンプルに

- モジュールが疎結合
- インターフェイス仕様がオープン
- シンプルシンプルシンプル!!

あたりを選定基準にしてるかなあ。

OpenStackなんかは、前の2つは満たしてるので悪くないとは思うんだけど、
なんかいまいちな臭いを感じるのは、パッケージングが下手だからだろうなあ。
パッケージングをどうするか、ってのも実は大事な気もする。
Ubuntuを好きなのもパッケージングがイケてるからだしね。

オーケストレーションについて議論するときに気をつけないといけないのは、
「オーケストレーションシステムは遍在し、かつ再帰する」ということです。

これは音楽をやってるとわりと実感することでもあるな。
アンサンブルの基本はデュエットで、そのユニットが大きくなって、
パートになって、それが組み合わさって、オーケストラ全体になる。

その都度どこに注目して議論をしているかを明確にしないと、
話が噛み合なくなります。

context重要ってことですな。

ETSI NFV 参照アーキテクチャの図および参照点は、
共通の想定を持って議論できる、という点で非常に有用です。

ある種のパターンランゲージとして機能するので、定義があるのは嬉しいかも。
でもパターンランゲージとして大事なcontextが記述されてないのは、
イケてないなあ、という気はしてる。