いじめがあった時に、いじめられっ子にも原因があるのかという

雑記

とうとつに、いじめがあった時に、いじめられっ子にも原因があるのかという話。
僕はいじめというのはイスとりゲームのようなものだと思うのです。
他の人と比べて反応が遅かったり要領が悪かったりして座れなかった人がいじめられるのです。

したがって、A君がいじめられっ子として選ばれた原因は他の人に比べてイスとりゲームが苦手だったA君にあります。
一方で、いじめが発生した原因はA君にはありません。
いじめがまず先に存在し、イスとりゲームが行われ、その結果としてA君はいじめっ子という役割に選ばれただけなのです。


いじめ問題などが起きるといじめられっ子にも原因があるだのないだのでなかなか白熱した議論になりますが、「A君がいじめられっ子として選ばれた原因」と「そこでいじめが発生した原因」とを一緒くたにしているのでカオスな感じになるので、分けて考えたほうがいいですし、前者は単に誰が選ばれるかというだけの問題ですので、本当の問題は後者なのです。

Elasticsearchのコードを読んでみる③ Bulk編

プログラミング

ほとんど更新と一緒だけど、運用する時はBulkのがよく使うと思うので簡単に。



curl -XPOST localhost:9200/_bulk -d '

{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }

{ "field1" : "value1" }

{ "delete" : { "_index" : "test", "_type" : "type1", "_id" : "2" } }

{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } }

{ "field1" : "value3" }

{ "update" : {"_id" : "1", "_type" : "type1", "_index" : "index1"} }

{ "doc" : {"field2" : "value2"} }

'
な感じのリクエスト。

Bulk処理

RestBulkAction ： bulkリクエストを処理するクラス
- client#bulk()を実行。めぐりめぐってNodeClient#execute()が実行される。

NodeClient
- TransportBulkAction#execute()を実行。

TransportBulkAction
- Bulkリクエストに含まれるインデックス名を抜き出し、インデックス生成が必要な場合はインデックスを作成。(createIndexAction#executeをインデックス分実行。この辺りは更新編を参照。)
- インデックス生成が終わったらexecuteBulk()でBulk処理を行う。
- 対象シャードごとにbulkリクエストリストを作成し、そこにbulkのリクエストを一行ずつ分つめていく。
- 対象シャードが空ならここでレスポンスを返す。
- シャードごとにTransportShardBulkAction#execute()を実行して処理していく。

TransportShardBulkAction
- TransportShardBulkAction#execute()からTransportShardReplicationOperationAction.AsyncShardOperationAction#start()が実行される。
- 対象シャードがローカルであればbulkのThreadPool上で以降の処理を行う。他ノードであれば対象ノードにリクエストを送信する。
- shardOperationOnPrimary()にてプライマリシャードを対象にBulkリクエストを一つずつ順次処理。
- IndexShard#index()やIndexShard#delete()などで更新していく。
- プライマリの後はshardOperationOnReplicaでレプリカシャードに対して処理。
- 全てのシャードで処理が終わったらレスポンスを返却する。

Elasticsearchのコードを読んでみる② 更新編

プログラミング

備忘録第二だん更新処理

curl -XPUT localhost:9200/testindex/type1/_create -d '{"hogehoge" : "fugafuga"}'
という感じのリクエストをしてインデクスされるまでの更新処理。ざっくり

更新リクエスト処理

RestIndexAction ： インデックスリクエストを処理するクラス
- client.index()を実行。めぐりめぐってNodeClient#execute()が実行される。


NodeClient ： 各ノード内部のリクエストを実行するクライアントクラス
- TransportIndexAction#execute()を実行。


TransportIndexAction ： インデックスリクエストをノード間で処理するクラス
- AutoCreateIndex#shouldAutoCreate()でインデックス作成有無を判定してインデックス作成処理を行う。
- インデックスを作成する場合はTransportCreateIndexAction#execute()を実行。
- ちなみにTransportActionクラスはexecute()のなかからdoExecute()を呼び出すようになっていて、TransportIndexActionなどの子クラスでdoExecute()に個別の処理を実装する感じの作りになっている


TransportCreateIndexAction ： インデック生成スリクエストをノード間で処理するクラス
- 自ノードがマスターだったらMetaDataCreateIndexService#createIndex()を実行。
- 自ノードがマスターではなかったらマスターにインデックス生成リクエストを送信。マスターノードはTransportMasterNodeOperationAction.TransportHandlerでリクエストをうけ、リクエストをTransportIndexAction#execute()あたりから処理してMetaDataCreateIndexService#createIndex()が実行される。


MetaDataCreateIndexService ： インデックスのメタ情報を設定するクラス
- 対象のIndexクラスやIndexServiceクラスを作成してMappingなどいろいろ設定する。
- アロケーションも行う。
- 一連の処理が完了したあたりでクラスターチェンジイベントを発行。各ノードがハンドルして対象シャードについてMetaDataCreateIndexServiceのcreateIndex()が呼ばれて同様に設定される。
- 成功したらListenerのonResponseを実行してTransportIndexActionまでもどる


TransportIndexAction
- 各シャードごとにドキュメント登録処理を行う。
- まずプライマリーシャードに対してshardOperationOnPrimary()が実行され、そこでInternalIndexShard#index()を実行。
- おわったらレプリカシャードに対してshardOperationOnReplica()が実行され、そこでもInternalIndexShard#index()を実行
- おわったらlistenerにレスポンスを渡す。


InternalIndexShard ： シャードのインスタンスクラス
- InternalEngine#index()を実行


InternalEngine ： 検索エンジンを操作する感じのクラス？
- LuceneのIndexWriter#addDocuments()を実行する。

Elasticsearchのコードを読んでみる① 検索編

プログラミング

検索のリクエストを受けてからレスポンスを返すまでざっくり追ってみた。
過去何回か追ってみて、時間が経つとすぐ忘れちゃうので備忘録的ななにか。


検索リクエスト処理

RestSearchAction ： 検索リクエストを処理する
- client.search NodeClient#search()を実行。いろいろまわってNodeClient#execute()が実行される。


NodeClient ： 各ノード内部の検索リクエストを実行するクライアントクラス
- transportAction.execute TransportSearchAction#execute()を実行している。


TransportSearchAction : ノード間で分散検索を行うためのクラス
- doExecute()が実行される。
- 検索タイプによって処理が分かれる。デフォルトでqueryThenFetch（検索後にFetch）。TransportSearchQueryThenFetchAction#execute()が実行される。


TransportSearchQueryThenFetchAction ： queryThenFetchを処理するクラス
- doExecute()が実行される。
- AsyncAction#start()を実行。検索対象がなければここでレスポンス返す。


AsyncAction : 各シャードへのリクエストを行う。
- コンストラクタで対象シャードを作成
- startで各シャード毎に処理する。
- performFirstPhase() sendExecuteFirstPhase()でシャードごとに検索処理。SearchServiceTransportAction#sendExecuteQuery()を実行。


SearchServiceTransportAction ：　検索通信のためのクラス
- sendExecuteQueryでクエリーを送信。
- 対象シャードがローカルノードなら自ノードのスレッドプールからスレッドを立ち上げてSearchService#executeQueryPhase()を実行。
- 対象シャー度が他ノードなら対象ノードへリクエストを送信する(TransportService#sendRequest())。 対象ノードでSearchQueryTransportHandlerでリクエストを受け、SearchService#executeQueryPhase()を実行。結果を返す。
- 検索が完了したらlistenerに結果を渡す。


SearchService ： 検索とか実行するクラス
- LuceneのIndexSearcherなどつかってごにょごにょ


TransportSearchQueryThenFetchAction
- listenerで結果を受け取り、onFirstPhaseResultで処理。全ノードからレスポンスを受けたらmoveToSecondPhase()を実行して次フェース（Fetch）へ移行。
- SearchServiceTransportAction#sendExecuteFetch()を実行してFetchする。


SearchServiceTransportAction
- SearchService#executeFetchPhase()を実行する。(対象が自ノードなら別スレッド、他ノードならリクエストする)
- 完了したらlistenerに結果を渡す。


TransportSearchQueryThenFetchAction
- listenerで結果を受け取り、全シャードを処理し終えたらfinishHimを実行。
- 検索スレッドプールでマージ（SearchPhaseController#merge()）。
- 結果をlistener(RestActionから受け取ったActionListener)に渡す。


RestStatusToXContentListener ： RestActionで渡されるListenerクラス
- SearchResponseをいい感じにJsonに直してレスポンスを返す。


めでたしめでたし

Kalafina分析

音楽

最近Kalafinaにハマりすぎているので、なんでこんなにハマってるのかを分析してみる。
※かなり主観的な話になりますのでご了承のほどをうんちゃらかんちゃら・・・


結論

結論としては、Hikaruがもたらすグループとしての不協和音が心地いいからこれほどまでにハマっているんじゃないかと思う。

前提

僕は基本的に『歌手』というものが苦手だ。作曲の専門家の人を歌のプロの人が歌うという形式は、一曲一曲を見ると非常にクオリティが高くて好きな曲も多いのだけれど、例えばアルバムなどで全体を見渡してみるとどの曲もクオリティが安定しすぎていて、アルバムとして綺麗にまとまりすぎてしまうのがその理由だ。

そんなわけで、もともとKalafinaも好きな曲はたくさんあったんだけど、『歌手』というものに対する苦手意識からなかなかアルバムを通して聴き込もうとは思わなかった。

ハマるきっかけ

KalafinaのコピーバンドのAnifalakさんのライブにおじゃましたのがきっかけ。僕も昔コピーバンドとかやっていたので実感としてあるのだが、コピーバンドには2種類いると思う。それは、「楽譜をコピーしてる」バンドと、「何もかもコピーし始めちゃってやばい感じになってる」バンド。

そして、Anifalakさんは後者のバンドで、たぶん「～のライブの時」の歌い方とか演奏アレンジとか、細かすぎて誰にも伝わらなさそうなレベルでコピっていると思う。そのレベルでコピーし続けていると、（本家の人達がやりそうな事を予測した）アドリブとかいうよく分からないことまで出来るようになったりするんだけど、とにかくそのくらいKalafinaが大好きなんだなというのが伝わってきて、これほどまでに人を惹きつけているKalafinaに興味がわいた。

ハマった

アルバムを全部聴いて、ライブビデオを全部観た。Wakana美しい・・・。ハマった。2014年6月はほぼほぼKalafinaを聴き続けている。

Kalafinaのいいところ

まず大前提として、曲がかっこいい、メンバーがかっこいい、歌が上手い、というのはあります。もちろん。とはいってもプロのミュージシャンですから、他の方々も皆それぞれ上手いしかっこいいです。そんななかで、なぜKalafinaがいいのか。


最初にも書いたけど、綺麗にまとまりがちな『歌手』というものが苦手なのだが、そういう意味ではKalafinaはちょっとおかしい。

Kalafinaの代表曲というと、知名度的にはMagiaとかstoriaが有名だと思うけど、ザ・Kalafinaというと一番最初の曲であるobliviousなんじゃないかなと思う。obliviousが一番Kalafinaっぽい。そしてここが象徴的な話なんだけど、obliviousというのはWakanaとKeikoだけが参加している曲なのだ。

ちなみにKalafinaのメンバー構成は、すごくざっくりした歌の印象だと
・高音の美しいWakana
・低音の美しいKeiko
・なんでも出来るHikaru
という感じになっている。話をobliviousに戻すと、obliviousをKalafinaのイメージに一番近い曲とするならば、WakanaとKeikoがいればKalafinaの世界観は完成出来るということになる。この2人は非常に美しい歌声をもっていて、この2人によるコーラスワークは完成されている。Kalafinaのイメージというのはこの2人のコーラスワークによって成り立っている。

では、Kalafinaというのはこの2人だけがいればいいのかというと、もちろんそんなことはない。この2人だけだとクオリティが安定しすぎて、前述している綺麗にまとまった歌手になってしまうのではないかと思う。

ここで重要なのがHikaruの存在である。Wakana、Keikoが自身の長所を前面に押し出すパフォーマンスが得意なのに対して、Hikaruは曲によってその歌声を何通りにも変える。『光の旋律』の優しい歌い出し、『Magia』の威圧的な歌声、『sprinter』のキャッチーな歌声、同じ人間が歌っているとは思えないほど、歌によって歌い方を変えている。これはWakanaとKeikoにより作られた完成された世界観であるobliviousには無い要素である。つまり、Kalafinaをoblivious組＋Hikaruと捉えても差し支えがないほどに、この3人の中にあってHikaruの存在感は異質だと考えられる。

このHikaruが、WakanaとKeikoによるハイクオリティなKalafina的コーラスワークへの自己批判的な存在になっていて、そこに生まれる絶妙なアンバランスがKalafinaをKalafinaとして綺麗にまとまることを許していない。Hikaruがいる限り、Kalafinaの楽曲は常にチャレンジを強いられることになるのである。


そしてこれが、僕がKalafinaにハマっている理由だと考えられるわけです。



という感じでけっこう適当ですけどｗ
fantasiaっていう曲がけっこう好きなんですが、WakanaとKeikoの美しいコーラスから始まって、サビでHikaruが全く違う世界観に持ってくっていうこの曲は、けっこう上で書いた事の象徴的な曲だなぁと思ったりする。

終わりなき日常の終わり　たまこラブストーリーの感想

カルチャー

ようやく、たまこラブストーリー見てきたので感想を書きます。

感想

すごく面白かったです。期待通り、いや期待以上に。

良かった点をつらつら書くと
・話の本筋、たまこのラブストーリーが王道な感じでよかった。
・たまこというキャラクターは本当に魅力的。
・たまこのお母さんが初登場（？）したけど、「たまこ姫」と言ってあやしている姿は本当に良いお母さんで、子供の頃に母親に甘えてる時の間隔なんかをすこし思い出した。
・たまこがもち蔵にラブになっていく際の素敵エピソードが、設定を上手くいかして無理なくもち蔵かっこいい。病院での一幕はちょっとやり過ぎ感あったけれどｗ
・ギャグ要素も非常にいい塩梅で、観客でくすくす笑っている人がたくさんいた。
・みどり、かんな、しおりの同級生達の物語への絡み方も非常にほどよい。（といっても、みどりちゃんはこの映画では特別な存在だけれど）

という感じで、ラブコメ映画としてとってもよく出来ていたのです。



さて、もともと僕はたまこまーけっとをdisりまくっていたのですが、この『たまこラブストーリー』で180度方向転換です！　たまこま最高ですね！！もちろんこの映画の元の作品『たまこまーけっと』も見ていて、全体的にはわりと好きだったのですが、どうしても最終回の結末が納得いかなかったのです。

たまこまーけっとに感じたやるせなさと、たまこラブストーリーをなんでこんな大絶賛なのか説明するためには、まずたまこまーけっとの背景から考える必要があります。

『たまこまーけっと』登場までの流れ

ゼロ年代後半は京都アニメーションの黄金時代でした。社会現象にもなった「涼宮ハルヒの憂鬱」、ニコニコ動画との抜群の相性で一世を風靡した「らき☆すた」「けいおん！」など、圧倒的な作画のクオリティやネットスラングを上手く取り入れる手法で、年々を代表するアニメをコンスタントに創出していたお化けみたいな製作会社でした。特に、「らき☆すた」「けいおん！」「けいおん！！」をたてつづけにヒットさせたことで、「京アニの日常系」という絶対的なブランドを確立させました。

また、ゼロ年代後半は京アニ以外にもたくさんの日常系作品が作られていて、まさに日常系全盛期だったわけです。

ところが、10年代に入ると東日本大震災が起こり、あまりにも厳しい現実を見せつけられたアニメ批評界隈では「日常系の終わり」がささやかれるようになりました。まぁこの説には賛否両論あったのですが、現在から見るとこの指摘は現実のものになっていて、2011年を堺に日常系はゼロ年代の勢いを失っていきます。

そんな2011年、京都アニメーションは大々的な広告をうち、満を持して次なる日常系作品『日常』を発表します。この頃までの京都アニメーションブランドの力はとにかくすさまじかったので、多くの人が2011年の代表作はこの『日常』になると考えていました。そして、失敗します。もちろんそれなりに人気のある作品ではあったのですが、「らき☆すた」や「けいおん！」のようなメガヒットにはなりませんでした。結局、2011年のアニメの代表作は『魔法少女まどか☆マギカ』になります。

これにより京都アニメーションのブランド力は、それまでの圧倒的なものではなくなります。その後も、「氷菓」や「中二病でも恋がしたい！」などの人気作品を創出していきますが、ゼロ年代のようなメガヒットには至りません。

そんな中で、2013年冬アニメで放映されたのがこの『たまこまーけっと』なわけです。この作品は「けいおん！」「けいおん！！」をヒットさせ、圧倒的な力を持っていた「日常系の京アニ」ブランドの中心人物だった山田尚子/吉田玲子/堀口悠紀子が集結して、原作なしの完全オリジナルで再び京都アニメーションが日常系にチャレンジするという作品でした。

そして、『たまこまーけっと』は非常にクオリティの高い作品となりましたが、やはり大ヒットに至りませんでした。ちなみに、この年の代表作が「進撃の巨人」という日常系とは真逆の「戦争」状態を描いたものだったことからも、日常系作品の厳しさが分かります。


日常系の枠に縛られた『たまこまーけっと』

さて、そんなたまこまーけっとですが、数話見ていくと今までの日常系ではあり得なかったキャラクターが存在していることが分かります。それが、「もち蔵」と「みどり」でした。この2人はたまこに恋しているというキャラクターなのですが、それまでの日常系に存在していたそれとは違って、かなりガチな感じです。この2人はたまこと友達でいることに辛さを感じていることが描かれているので、友達でいることから脱却しようと考えているキャラクターです。

つまり、この2人は日常系アニメたまこまーけっとで描かれている日常を破壊したいという願望を心の奥に持った存在なのです。

僕は、京アニの日常系アニメをもう一度という雰囲気で登場した『たまこまーけっと』にこの2人のキャラクターをあえて登場させた事が本当に素晴らしいと思いました。楽園だけを描く日常系が衰退していく中で、新しい形の日常系というものをあの京都アニメーションがチャレンジするのかと心躍らせました。

特に、「みどり」というキャラクターは本当によく出来ていて、日常系アニメに欠かせない主人公の親友という役割をこなしながらも、たまこへの恋心やもち蔵への嫉妬なども併せ持つという複雑なキャラクターで、みどりがこの物語をどういう方向に導いていくのかとても楽しみでした。


ところが、この期待は完全に裏切られてしまいます。端的に言えば、『たまこまーけっと』という作品の結論は「やっぱり日常系いいよね」っていうことで、日常への破壊願望を持ったこの2人のキャラクターは最終的に完全に黙殺されてしまうのです。

僕はこれがどうしても許せなくて、特にみどりの扱いがひどくて、たまこが「これからも今まで通りみんなで友達でいるのが一番いいよね」という感じで物語を締めて、なんとなく「めでたしめでたし」な雰囲気で『たまこまーけっと』は終わっていくのです。

いやちょっと待ってくれよと。みどりはどうなっちゃってるんだという話です。この最終回観た時に「好きな相手に告白すらさせてくれない日常系こわい」というようなことをツイートしたのですが、本当にそんな感じです。



日常を自ら終わらせた『たまこラブストーリー』

ひどい作品だったという感想が残った『たまこまーけっと』でしたが、最終回の後しばらく経つと続編が作られるという噂が聞こえてきます。


どうやら劇場版らしい。ふむふむ。


どうやら「たまこラブストーリー」というタイトルらしい　・・・ふぁっ！？


もうこのタイトルだけでわかります。上でつらつら書いていたような僕のたまこまーけっとへの不満を全て吹き飛ばす作品であることが。
そして、本当に素晴らしい作品でした。

象徴的なのは、作品中でもち蔵が「やっぱりなかったことにしよう」と今まで通りに戻ることを提案し、「今まで通りは嫌だ」とたまこが拒否するところです。これは『たまこまーけっと』へのものすごい自己批判になっていて、「今まで通りが一番さ」というテレビ版最終回からここまで来たのはどうなってるんだという感じはしますねｗ

特に、インタビューとかを見ている限り、どうやらもともと『たまこラブストーリー』の構想があったわけではないようなので、この方向転換は実に不思議です。



まとめ

上記のように、僕の場合は最低評価から最高評価にジャンプアップというのもありますが、とにかく面白かったです。

Blu-rayかっちゃおっかな！