アニメのわたてんの感想文

みゃーねえかわいいよみゃーねえ。
今更感想文。

その１、天使のまなざし。
　初見、12話の「天使のまなざし」劇に感動しか覚えませんでした。２回目以降は、どうやって劇であれを演じているんだろうと思ってみてみたのです。
　取りあえず、階段（最初にこよりちゃんたちが最初に歌いながら登っている階段）使って天使の子達が飛んでいる表現を実現してると思います。
　花ちゃんが歌いながら歩いているシーンは、ステージ右側から出てきて客席をぐるっと回りながら左側からステージに上る・・・な流れなんだろうなと。ステージ近くになったあたりがあの町の光が見えたシーンなんだろうと。素敵。
　マリーにお菓子をもらうシーンに於いて、「うちの看板商品」に対して、ニコニコのコメントで「菓子を目の前にしてよく我慢できてるな」というコメントがあったけど、多分練習ですでにかじってると思うんですよね。練習で絶対１度は花ちゃんかじっていると思うんです。
カルマ様のシーンは、録画しておいたカルマ様の格好をした乃愛ちゃんをプロジェクターで表示（⇒大きく表示できる。）していたんじゃないかなと。プロジェクターの光が後光のように眩しく見えたりと、あの神々しいEffectも得られるし、こうだろうなって。


個人的に『愛』とは他者に与える慈しみ、そして『愛』の大きさとはどれほど頒布できたのか、と思うんです。となると世代を超える『愛』はとても大きな愛だと思います。デイジーのお菓子は亡き後も、孫が看板商品として販売し続け、その看板商品という愛を頒布しているということは、とても大きな『愛』だったんだなと。
とりあえず、世代を超える愛、というだけでその愛情の大きさがわかる気が。そして、あの『ごめんなさい』を言ったときのデイジーの悲しみは想像を絶するものがあったんだろうと。両想いなのに諦めざるをえないって悲しい。
愛を丁寧に歌った劇だったんだろうと思います。


さて、この劇で出てきた天使って何だろう？と。多分小学生あたりの子供のことを天使としてるんだろうなと。

こよりちゃん・花音ちゃんがずっと天使だったのは、（あの二人大人になってもずっとあの関係なんだろうと想像できるのですが、）いつまでもあの関係が続くということを視差しているんだろう。大統領になれるかどうかは知らないけれども、きっとそれ相当の地位に二人でなるんだろうなと。

…花ちゃんの試練の門（歌いながら歩いていたシーン）のところは、小学生から大人になる、までの時間経過のことを表していたのだろうと思うのです。
実際小学生の夢を抱いたまま大人(20歳)になれる人ってほとんどいないでしょう。


わたてん＠百合姫掲載版、では花ちゃんがみゃーねえに一緒にお菓子屋さんをやりましょう、って誘ってましたね。劇中劇って本編の未来を示唆しているものをちょくちょく見てきたのですが、わたてんの劇も多分に漏れずそれなんじゃないかな？って。
　きっと、二人の営業している店に松本ぉ！がよく買いに来るのでしょう。

ここから想像できる今後のわたてんの流れとして、二人で新作お菓子をデザインするんじゃないかなって。この二人はどんなお菓子を創るのか楽しみです。

そういえば単行本で、お化粧したみゃーねえに対して花ちゃんがドキっとしてる場面があったけれども、花ちゃんがお菓子よりもみゃーねえを選ぶシーンがいつになるのかなというのが楽しみです。あんなに徹底的にお菓子を食べることしか考えていない花ちゃんがそれ以外を意識するシーンはどんなことになるのか気になってしょうがない。

最後に、劇がとても素敵でした。また将来のみゃーねえvs花ちゃんの関係を示唆してとての感動的でした。漫画本編でみゃーねえと花ちゃんがどう仲良くなっていくのか楽しみです。


その２、妹ちゃんに天使が舞い降りた。
単行本６巻、
「こうしてるとなんか懐かしいね。花ちゃんが来る前見たい。」
「そうだな！花来る前は、みゃー姉と二人だったからな！」
の部分を読んだとき、涙しました。

作品は花ちゃんが来たところから始まっていますが、この二人はその前から暮らしているわけで、あのコスプレも当然にその前からやっていたわけで。

みゃーねえには花ちゃんという天使が舞い降りたわけですが、それと同様に、妹ちゃんには、乃愛ちゃんという天使が舞い降りたと。

妹ちゃんはみゃー姉の誕生日を忘れてショックを受けていたけれども、それはきっとみゃー姉よりも夢中になる人が見つかったという素晴らしいことなんだろうと。

僕の妄想では、中学？高校で陸上部に入った妹ちゃんを乃愛ちゃんが応援。凄い接戦で勝利したときに一番最初に抱き着くのがみゃー姉じゃなくて乃愛ちゃん。そんなシーンを妄想して一人泣いてました。

最後に
百合作品の漫画は、恋愛漫画ものとなんか毛色が違う感じがあったけども、好き嫌いの部分が男女間のそれとステップが異なり、比較的Directに愛情のそれに反映されているんだということが確信できました。

今後のみゃー姉＆花ちゃん、妹ちゃん＆乃愛ちゃん、こよりちゃん＆花音ちゃんの関係が良くなっていくことを楽しみにしています。

2019年の抱負

そういえば、こういうページがあったことを思い出したので。

2018年は、node/express + typescriptの組み合わせで製品を作る機会ができました。
入社以来MFCばかりだったので楽しいものでした。
今年は、typescriptの能力を上げたいです。or rustで製品作りたいものです。

rustについて、c++でsmart_ptr でいろいろ頑張っていると、どうしてもこれはライブラリではなく、言語コア機能として扱ってほしいなと思うことが多々ありまして。そう思っていた矢先にrustの存在を知りました。
調べれば調べるほど、「こ、この機能は・・・！！」というものが多々ありまして使ってみたいなと。
一方C++も喉から手が出るほど望んでいた機能が続々と参戦しているのですが、成否コードのときに、どうしてもOldTypeの爺様達がネックになりまして、、、、。。

あのOldType達はC++イコールC with classからまるで成長していないために関数オーバーロードすらコードレビューで撃墜してくるので面倒でしょうがないです。。。。
しかし、自分がそういうことが無いかと言われると、否定できなくて一度記憶してしまったことはそう簡単にはUpdateできないものなのだとつくづく実感させられてしまいます。

「いい国作ろう鎌倉幕府」と覚えていたのですが最近はこうでなないそうです。知識のUpdateの重要性が思い知らされます。自分の知識を万遍なく更新することができればそれに越したことはないのですが、そんなことはありません。TwitterのTLで話題に上がりやすい項目ならちょくちょくUpdateできるでしょうが、例えば、手品のシンブルウォンドの最新トレンドとか、じゃぐるの最新足技とかそんなマイナーな事柄は、受動的に待っていたら情報は得られないでしょう。自分が特に大事にしたい事柄は日々情報収集が求めれられるのだろうと思います。
一方、そこまで興味のないことは、ただ自分の記憶便りにするのではなく、それらについても新し意図があるかもしれないと謙虚に情報に当たっていく必要があるのだと思います。

知ったかぶりってかっこ悪いですよね。それどころか、正しい情報から自ら遠ざかってしまう行為なので１００害あって一利なしやなって、思いました。

今年は、後輩君の前で知ったかぶりしないように、真実に謙虚になりたいと思います。

xaml のメモ

http://pro.art55.jp/?eid=1176521
xaml の別アセンブリからxamlをマージする

どこかの Window の xaml ファイルに対して。。
　<Window.Resources>
　　<ResourceDictionary>
　　　<ResourceDictionary.MergedDictionaries>
　　　　<ResourceDictionary
pack://application:,,,/(アセンブリ名);component/(プロジェクト内のパス)
　　　</ResourceDictionary.MergedDictionaries>
　　</ResourceDictionary>
　</WindowResources>

xaml の ignorable が複数あるときは、スペースで区切って並べる。
https://msdn.microsoft.com/ja-jp/library/aa350024(v=vs.90).aspx


mc:AltenateConent ＋ mc:Choice Requires ＋ mc:Fallback でifdef のようなことができるらしい。
http://kirmir.com/2015/02/24/compilation-directives-to-control-xaml-content/

--
Wpfのカスタムコントローラーを作るとき、Generic.xaml のスタイルが既定のスタイルとして使われる。
なので、ファイル分割したいときは、ResourceDictonary を作成＆その内部でスタイルを定義した後、

<ResourceDictionary.MergedDictionaries>
  <ResourceDictionary Source="/コンポーネント名;component/Themes/MyContorlTheme.xaml" />
</ResourceDictionary.MergedDictionaries>

のようにマージしておかないと、実行時にエラーが出る。（よくわかんなくてよくはまった）。

xaml 上で利用する名前空間をまとめる

XmlnsDefinition 属性を assembly に適用する。
これが適用できるのは、自身のアセンブリ内の名前空間だけらしい。
AssemblyName というプロパティがあるけど、これでは指定できないようです。

解説。
http://d.hatena.ne.jp/siokoshou/20090927/p1
http://blogs.wankuma.com/kzt/archive/2009/01/09/166020.aspx

これの兄弟属性 XmlnsPrefix は、XAMLのツールボックスなどから追加したときにつけられる既定の名前らしい。

Wpfのデザインモード判定

いつも忘れるのでメモ。
デザインモード時に実行したくないコードの分岐
Is there a DesignMode property in WPF?

DesignerProperties.GetIsInDesignMode メソッド

    // Check for design mode. 
    if ((bool)(DesignerProperties.IsInDesignModeProperty.GetMetadata(typeof(DependencyObject)).DefaultValue)) 
    {
        return false;
    }

DLL利用するタイプのアセンブリを作成しているときに、デザイナの作業Dirがよくわからないところで実行されるから、デザイナがエラーで調整ができないことがよく。

追記
Bindings の型を微妙に間違えている時の方が経験的に多いからそっちをチェックするのも。interface の依存プロパティを作って、派生型のプロパティにBindするということをやって、型エラーでXAMLデザイナーがエラーになっていた経験則。

精神が安定してきたので、少しずつノートを戻していこう。

c# の attribute メモ

最近はコピペじゃないけどコピペのような多めのクラスと戦ってます。C#で楽ができないかなぁ。とあれこれ考え、最近見かけた属性を使って楽ができないかなと考えたのでした。

値をセットするのは別にいいのだけれども、それが大量にあると混乱してくるという。
値の表は存在していて、それとソースコードを逐次見比べて頑張っていたのだけれども、ソースコードにその表のような状態で書けたら混乱が少なくなるかな？って。ちょうどAttributeが目的にあってそうだったのです。

どうも属性はリフレクションを使うから遅くなるのは嫌だな、と食わず嫌いをしていたのだけれども、バグって速いのと正しくて遅いのならば後者ですわねェ、ということで下のような実験コードを書いたのでメモリ。

注力する場所が、番号と変数名書くところまで減らせたから少しは楽になったんじゃないかなと。
変数名も消したいし、型変換の余地も残したいけれども、欲張るとドツボにはまりそうなので一旦ここまで。