2021-02-20

DevelopersSummit2021 心打ち震えるDX事例を世に轟かせたい（星野リゾート、三越伊勢丹・アイムデジタルラボ）

開発組織

はじめに(強い私情を添えて)

DXという国が掲げ高らかに叫ばれる言葉があるけれど、その実態はぼんやりしていて何のことだかわかりにくい

個人的にこのスライドがかなり腑に落ちて気に入っている

https://www.slideshare.net/TokorotenNakayama/dx-240495124

DXとは「現実と向き合う」こと
　　• 「向き合う」
　　　　• モダナイゼーション、既存業務のデジタル化、ITの内製化
　　　　• シリコンバレーのスタートアップのように働く
　　　　• デザイン思考、ユニットエコノミクス、リーンスタートアップ
　　　　• コミュニケーション、組織展開、評価制度、人材雇用、etc...

この中でも、（非デジタル企業における）ITの内製化、組織展開が肝だと個人的に感じている
→ 言い換えると、デジタル部門の内製化＋アジリティのある組織構築(≒アジャイルな開発チーム)

僕は以前、元請けSIerで働いていたこともあって、そこから連なる多重下請け構造に強く違和感を抱いている
その多重下請け構造が減っていくことこそが国の産業のためになる！とも思っている
管理的側面から多少のレイヤが必要な場面もあるかもしれないけど...基本的には構造ごと無くなって欲しい

そんな日本社会の中において、イイ感じにDXに成功させている企業の名前こそが世に轟いてほしい！

轟いてほしいなぁ〜！ということを昨日デブサミに参加していて思ったので、そんな素晴らしい事例を紹介

旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発

旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発 from 崇介藤井

www.slideshare.net

組織

今回の事例を主導し色々な取り組みを統括するPOチーム自体が現場上がりでIT経験ゼロからスタート！

失敗は避けられないものだろうけど、その失敗を踏まえて生まれた取り組みが具体的ですごく良かった

投資判断プロセスの仕組み化
- 実施する案件の優先順位付け
リレーション作りと情報収集・シェア
- 現場の情報収集・整理・シェア
- 現場に役立つ知識は社外のものも
プロダクトオーナースキルマップと勉強
- プロジェクトで得た経験・学んだ理論を体系化

どれも多くの組織で再現性がある内容なはず

特に最後のスキルの体系化はなかなか難しそうなのに実現できているのは驚きで、どんな内容なのか気になる
こういった内容を時間をとって整理できる（ビジネス判断としてやらせてもらえる）組織はなかなか少ないのでは

ITの内製化

こちらの事例で特徴的なのは現場出身者（あるいは現場）がノーコード/ローコード開発を多用しているところ

エンジニアに頼らず現場の人間が手ずからシステムを開発し保守できるようになり、なによりその取り組みが組織内に横展開されていくというのはまさに理想的

途中で出てくる「現場出身者の重視」「全スタッフIT人材化」という言葉の素晴らしさには涙が出そうにすらなる

会社への愛着が、困難な課題への挑戦を達成する

これだよ...！！！！！！！

その他

数年前の段階で社内で運用/開発の分断による問題に気づいて、自然とDXに繋げていることがまず驚き
（DXという言葉の浸透より早く物事の本質に迫っているわけで、気軽にDXとまとめてしまうこと自体が心苦しくある）

そういえば僕は私文卒であって、ふにゃふにゃな卒論では観光の話を書き、その中で星野リゾートについて調べたりもしていた
その執筆当時(2016年)とかそれ以前の段階でも「星野リゾートは現場スタッフの声を大事にしている。ボトムアップで業務改善をしてホスピタリティを向上させている」というような話はあった。卒論が残っていたら引用したかった

そうした素地があったからこそ、今回のような成功へ繋がったのかもしれない（我ながらいい文章の結びだ！）

三越伊勢丹が目指すNew Normalの購買スタイル

speakerdeck.com

ITの内製化

先の星野リゾートの例では様々なツールをたくさん作っていたけど、こちらの事例ではドカンと一発リモートショッピング（リモート接客）システム構築の話

リモート接客というサービスそのものの難しさは、それはそれで興味深く面白いんだけど、今回は割愛

今回の話は現場大事にしてるけど言うほど内製関係ないじゃん！と我ながら思うところで、
でもその辺の取り組みは2020年のデブサミでのセッションで触れられているのでそちらを参照

speakerdeck.com

そちらの内容こそ素晴らしいんだけど書いていくのは疲れるので端折る...

組織

何よりも組織運用の熟達に感心！
具体的な構成・運用についてはスライドを見てね

上述した去年のスライドの話もあり経験の蓄積は間違いないと思う
また以前のプロジェクトではアジャイルコーチを他社から招聘しているとのことで、そこが効いたりしているのかも

というところで、上層部を交えての意思決定ミーティング、導入チームとの調整・共有の仕組みが見事

大企業ならではの意思決定の重さを身軽な（アジリティのある）仕組みに取り込めている
しれっと流れたけど、この導入チームという存在そのものもポイントなのではと思っていて、役割としては現場と開発の中間層的な感じっぽい？
今回の事例は単純な「明日からこっちの勤怠管理システム使ってや〜」的なシステム導入ではなく双方向のコミュニケーションが重要なものだからこそ構造として重要になってきそう（債務の委譲）

何より良いと思ったのは「同じものをみて考える」という言葉とそこのスライド
これだけでもPO・開発・現場の連携がよく取れていることが分かる
こういった意識から「機能要求ではなく目的を共有」という取り組みに繋がってくるんだと思う

言うほどまとまってないまとめ

後から気づいたけど、今回の事例はどちらもホスピタリティに重きを置く業界の話だった
DXと謳われるような大きな変革には、直接お客様と接する現場の意識の強さが重要なのかも、とか思ったり

どちらの事例も他の企業がモデルとするのに相応しいもので、広く知れ渡っていけばいいな

2021-02-14

【C#】【Dapper】DB接続の単体テストを考える（考えるだけ）

C# ASP.NET .NET5

概要

DBコネクションつくってSELECT文だして結果を返して...みたいなところのテストを考える
テスト時にはInit時にfixtureみたいな感じで大量にデータつくって、Dispose時に全部消しておくみたいな...

PRD/STG環境のDBはAWSのAuroraとか、EC2上のMySQLとかそういうものを使っていると想定する（そのへんの作成経験が少なくふわふわ）
※ PRD: 本番, STG: ステージング

ついでに(ASP.NETの)ローカルでの開発時にはdockerコンテナでWebAP, MySQLのコンテナを立ててあれこれしているものとする

EntityFrameworkを使っている場合、DBはなんであれDB接続部分のテストはインメモリDBでうまいことできそう(?)な気がする
でも僕はEntityFrameworkを使ったことがないので...

でも、今回はPRD/STGのDBにMySQLを使うことを考える
そっちがMySQLならテスト用のDBもMySQLじゃないと苦しむことになると思う

ついでにテストはローカルでもやりたいし、AWSのCodePipeline（とか触ったことないけどCircleCI）でもやりたいしということも考慮に含める

で、考えたり調べたりした

STG DBの横にテスト用のDBを立てておいて、テスト時にはそこに接続
テスト実施時にDockerでMySQLを立ち上げて、テスト時にはそこに接続

STG DBの横にテスト用のDBを立てておいて、テスト時にはそこに接続

これが一番楽だと思うけどお金とかどうなのかな（若者の貧困）

ローカルのテストの時はローカルにdockerかなにかで立てたDBを使うでもよし
毎回PC起動時に立ち上げておくのちょっとだるいけど

テスト実施時にDockerでMySQLを立ち上げて、テスト時にはそこに接続

テストの都度コンテナを立ち上げるイメージ

読めばわかる

blog.dangl.me

やっていることはかっこいいんだけど、テストの都度コンテナ立ち上げるのに時間がかかりそうなのと、

テストはローカルでもやりたいし、AWSのCodePipeline（とか触ったことないけどCircleCI）でもやりたいしということも考慮に含める

ここの後半の話が大変そう

結論

出てないので、なにかいいのがあったら教えてね

こういう時になるとRailsは便利で偉いなと思う

2021-02-12

【.NET5】【xUnit】 MVCのControllerのテストのちょっとした例（ModelStateの状態・明示的な404のテスト）

ASP.NET C# .NET5 xUnit

（色々書いたけど、最後参考に載せているMS Docsに全部書いてある気がしてきた。が、目を背ける）

xUnitとMoqを使う

例えばこんな感じのControllerをテストしたい時がある

public class SampleController : Controller
{
    private readonly ISampleService service;

    public SampleController(ISampleService service)
        => this.service = service;

    [HttpGet]
    public IActionResult Show(SampleParamModel param)
    {
        // paramへのモデルバインド時の検証でエラーがあったら404！
        if (!ModelState.IsValid) { return NotFound(); }
        
        SampleViewModel model = service.GetShowViewModel(param);
        if (model is null) { return NotFound(); }
        return View(model);
    }
}

正常系

正常系、つまるところViewにSampleViewModelのインスタンスを渡せて、それをreturnする場合のテストはそんな悩まないと思う

けど一応書いてみる

[Fact]
public void ShowTest_正常系()
{
    // 必要に応じてもっと真面目にインスタンスをつくる
    var param = new SampleParamModel();

    // MoqでServiceをDIして, Showアクションで呼んでいるメソッドを組み立てる
    var serviceMock = new Mock<IUserService>();
    serviceMock
        .Setup(service => service.GetShowViewModel(param))
        // ここも必要に応じて真面目に
        .Returns(new ShowViewModel());

    // ここからテスト
    var controller = new SampleController(serviceMock.Object);
    var actionResult = controller.Show(param);

    // Assert
    var viewResult = Assert.IsType<ViewResult>(actionResult);
    var model = Assert.IsType<ShowViewModel>(viewResult.Model);

    // シンプルな例すぎて何をAssertすればいいのかわからない
    // あとなんか適当にmodelのフィールドあたりを...
}

準正常系

こっちの内容を書きたかった！

// paramへのモデルバインド時の検証でエラーがあったら404！
if (!ModelState.IsValid) { return NotFound(); }

コレに落ちるパターンを書くと、こうなる

[Fact]
public void ShowTest_準正常系_パラメータエラー()
{
    // 今回はServiceの処理を呼ぶ前に落とすからSetupはしない
    var serviceMock = new Mock<ISampleService>();

    var controller = new SampleController(serviceMock.Object);

    // ここが肝
    controller.ModelState.AddModelError(nameof(SampleParamModel.Name), "some error");

    // ModelStateでエラーを入れ込むのでparamのインスタンスに特に意味はない
    var param = new SampleParamModel();
    var actionResult = controller.Show(param);

    // Assert
    // return NotFound()したものはこんな感じに引っ掛ける
    Assert.IsType<NotFoundResult>(actionResult);
}

ModelStateに直接エラーを仕込むのがポイント！

一応ちょっと悩んだところとして、例えばこんなことをしても意味無し

var controller = new SampleController(serviceMock.Object);
var param = new SampleParamModel() { Name = ""}; // Nameに[Required]がついているとする
var actionResult = controller.Show(param);
// この時点でcontroller.ModelStateはValidになっている

ModelStateは飛んできたアクセスルーティングの指示通りControllerのActionに振ってモデルバインドさせたタイミングでチェックされているようで、上記のように単純にインスタンスを渡すだけではダメみたい
（真面目に内部実装を追いたいけど今回はやめた）

一応以下のようにControllerに渡す前のparamを明示的にValidatorにかけてみたけどコレも意味無し
（ModelStateはparamじゃなくてControllerのインスタンスにくっついてるんだからそりゃそうだ） Validator.TryValidateObject(param, new ValidationContext(param), new List<ValidationResult>(), true);

参考：

https://docs.microsoft.com/ja-jp/aspnet/core/mvc/controllers/testing?view=aspnetcore-5.0

https://stackoverflow.com/questions/58855965/unit-test-aspnetcore-controller-check-httpstatuscode-with-actionresultt-result

https://stackoverflow.com/questions/22561834/asp-net-mvc-controller-post-method-unit-test-modelstate-isvalid-always-true

2021-02-08

阿堵物とその運用について（いやいや資産運用）

人生の嫌なことエッセイもどき

はじめに

僕は金銭への執着が薄い薄いというより、執着したくない。執着することは浅ましいことだと思っている

なんなら清貧に美徳を感じている
とはいえ、困らない程度にはお金がほしいのでここはガバガバなダブルスタンダードだし深く追わないことにする

僕の生まれは裕福で、いわゆる地方豪族みたいな家に生をうけている
なので正直お金に困ったことはあまりない

そんな家ではあったけれど父がお金に細かく極めてうるさい
「すぐ電気消せ！」とか「ポイントカードわすれた〜！！もったいないことした〜！！」とか事あるごとに騒いでいる
前者についての発言は人感センサーの電灯に対しても向けられており、この点で僕は父親のことをバカなんじゃないかと思っている
「いつか暗闇で転んで怪我したら電気つけるようになる」とは母の言だ

多分僕はその父の細かさ（みみっちさ、とはしないでおこう）が心底不快でお金や資産運用のことを考えるのが嫌いになったんだと思う（というのを今日思いついた）
ついでに金融商品とかそういうものを扱う人たちは消費者を騙そうとしている気がして、それも気に入らない

ところで僕の好きな言葉に「阿堵物」というものがある
晋の時代の王衍という人がお金のことが嫌いで名前も呼びたくなくて付けた別称のことだ

晋の王衍は、妻の郭氏の聚斂（税の取立て）の貪欲さを憎み、銭なるものを極端に嫌うようになった。
その必然の結果として、彼は「銭」と言う言葉を使うのも嫌悪して、それを言うに、「阿堵物」と言った。
以来　彼の口からは、未だ嘗て「銭」と言う言葉は出なくなった。
ある日のこと、妻の郭氏はその事をひとつ試してみようと、婢に命じて、夫の寝床の周辺に銭をばら撒かせておいた。
王衍は朝起きて、身の回りにばら撒かれた銭を目にした。
王衍は婢を呼び付けてから、散らかった銭を片付けさせようとして、婢に命じた、
「阿堵物を上げて去れ」と。（＝阿堵物を拾い上げて持ち去れ。）
王衍の口からは、遂に「銭」なる言葉は出なかったのである。

中国通史で辿る名言・故事探訪中国通史で辿る名言・故事探訪（阿堵物）

この故事を知った時には遥か遠く古代に生きた中国の友人のことを思わずにはいられなかった

本題のあらすじ

ここまでの話はまあどうでもよくて、例の細かい父親からiDeCoがどうのと説教された
iDeCoだの確定拠出年金(これはよくわからないままやってる)の必要性を理解してはいる

理解してはいるものの、僕に言わせると阿堵物ジャンルの話なので「いつかやろういつかやろう」で後回しにしていた
（確定拠出年金はデフォの100%元本確保で放置）

ここで父親に10年遅れの反抗期を見せた上で「いつかやろう」の「いつか」を延長してもよかったのだが、あまり父親にバカだと思われると遺産相続で泣きをみそうなので仕方なく勉強することにした

最近教えてもらったこれでな！

hayatoito.github.io

よくできたデザインの金融系のページはどうにも胡散臭くて苦手だ
その点、この個人がつくったgithubioのページはどうだ！素晴らしい！
これだけで信用に足る！

ということでこの人が言っている資産運用を信用することにする

時価総額加重平均を採用したインデックスファンド

この人の言うには

コスト（信託報酬）の安い
時価総額加重平均を採用したインデックスファンド（S&P500、全米、全世界など）

を選べばいいそうだ

ということで数年ぶりに確定拠出年金のサイトにログインして運用商品を確認した
が、どれが時価総額加重平均を採用したインデックスファンドなのかわからない
カッコ書き部分の文字列で検索をかけても一つの商品もヒットしない

仕方なくインターネットに阿堵物のことを尋ねることにした

※今回の記事は当初ここから先の内容をまとめたくて書き始めたものだけど、変に筆が乗って「はじめに」をつけたしたキメラ記事

時価総額加重平均??

時価総額加重平均型株価指数（じかそうがくかじゅうへいきんがたかぶかしすう）は株価指数の算出方式の一つ。組入銘柄の時価総額合計を、基準となる一時点での時価総額合計で除算して求めるものである。世界の多くの株価指数がこの方式を元に、浮動株の時価総額で計算した浮動株基準株価指数を採用している。
時価総額加重平均型株価指数 - Wikipedia

最初の文のこのSVCの表現がありがたい
時価総額加重平均型株価指数は「株価指数」の算出方法の一つだそうだ

じゃあは「株価指数」は他になにがあるんですか？

株価指数は、その国の株価の推移や株価水準を示す指数です。株式市場のあるところには必ずといっていいほど、株価指数が存在する上、主要な株式や新興市場の株式などを対象とした株価指数もあることから、その種類は膨大です。しかしながら、それらの株価指数も、大きく分けると「株価平均型株価指数」と「時価総額加重型株価指数」の2つの種類に分けることができるため、大まかな特徴を確認することができます。
Vol.04 『その株価指数、どっちのタイプ？』 | ETF 知って役立つ JoJoマーケット | ETF（上場投資信託）｜日興アセットマネジメント

株価平均型株価指数というものもあるらしい
その内容・時価総額なんとかとの違いはいつか調べるとして放置し、

その情報に上記ページの内容をちょっと加えると

株価指数の算出方法
- 時価総額加重平均型株価指数
  - TOPIX(東証株価指数)
  - S&P500指数
- 株価平均型株価指数
  - 日経平均株価
  - NYダウ工業株30種平均

後述するが、今回選ぶことになった運用商品のベンチマークであるところの「MSCIコクサイ･インデックス」というやつが時価総額加重平均型株価指数の子要素として名を連ねる

https://www.nam.co.jp/education/handbook/idx02.html

インデックスファンド??

これは株価指数の話よりわかりやすかった

もう疲れてきたからさらっと書くと

投資信託（ファンド）
- パッシブ ≒ インデックスファンド（厳密に言うと≒じゃないのかもしれないが、無視）
- アクティブ

これは運用商品の表の中にも書いてあるからわかりやすかった

結論（選んだ運用商品）

違ってたら悲しいけどこれを選んだ（全ツッパ）

ＤＩＡＭ外国株式インデックスファンド＜ＤＣ年金＞商品分類：外国株式インデックス（先進国）運用方法：パッシブ

「普通の人が資産運用で99点をとる方法とその考え方」についてはちょくちょく読んで勉強し直そうと思う

2021-01-04

2020年アニメ振り返り

アニメ

Anime Of The Year

体操ザムライ
BNA
炎炎2期
スト魔女RtB
GREAT PRETENDER
ドロヘドロ

良質なオリジナルアニメが多くて（わざわざこうしてまとめるくらいには）素晴らしい年だった

各アニメについて

以下あいうえお順で

アクダマドライブ

オリジナルアニメ

ダンガンロンパ好きな人は皆見るもので話題になるものだと思ってたけどそうでもなかった
話題にはなってない印象だったけど安定して面白かった
毎週楽しみにしてたけどイマイチ伸びを感じなかったのは我ながら不思議

何より画面がおしゃれでいいね
場面転換のビジュアルの使い方がかっこよくて、アニメってよりゲームとかUIデザインとかの方で輝いてくるのかもって思った

あと最終話のレールガン描写は（リアリティはさておき）すごいイケてる

OPのAメロBメロがすごく好き

天晴爛漫!

オリジナルアニメ

キービジュのウキウキ感！僕はP.A.WORKSではクロムクロが一番好きなんだけども、このアニメはクロムクロぶりに期待していた

中身はというとやりたいことが多すぎてまとまりに欠けたかなという印象
西部劇とレースとあと...いろいろ
どうしてもSteel Ball Run（漫画）と比べて見劣りを感じちゃう

2クールあったら絶対もっと良くなってたと思う
オリジナルアニメで途中まで良さそうだっただけに勿体ない！

アルテ

漫画原作

話自体は「オモシレー女...」っぷりを軸にストレスなく展開していく
最後はアニメオリジナルらしいけど、ストーリーの軸も一貫してブレず安心して見ることができる良アニメ
良アニメだけど漫画からアニメ化したことの良さがあったかというとわからない
でもアルテの声の小松未可子の演技はすごくハマってた

ルネサンス期のフィレンツェ、ヴェネツィアの文化風俗とその時代の女性の社会進出を描いてる話で、前者については僕は特別詳しくないのでへ～って感じ、後者は21世紀の今でも社会問題になる話であって2020年にアニメ化することには意義があるように思った
後者のテーマについて僕から特別言うことはないけど、こういうアニメがもっと話題になってくれるといいね

完結したら原作も読みたい

痛いのは嫌なので防御力に極振りしたいと思います。

なろう原作

テンポのいいなろう系萌えアニメ
 プリズマイリヤ(見てないけど)のスタッフが結構入ってるとかで作りが安定してた

特に何も言うことがない

いわかける! - Sport Climbing Girls -

漫画原作

せかつよ的なものかと思って見ると案外面白い
案外面白いんだけどB級感が拭えない...

話の展開自体は好き。1クールで切りはよく終わってるし真っ当にスポ根してる
ジャンプ原作か？ってくらいちゃんと壁に当たって成長していくのはよかった
野々華先輩が身長不利で勝てず涙したり、隼ちゃんがスランプで部活を抜けたりとか

難点としてはやっぱりB級感かなぁ
主人公の声を当てている上坂すみれの縁起に迫るものがなかったのが残念
各キャラ付が異様にくどくてB級もといC級感がバチバチだったのが苦しい（原作の問題か）

炎炎ノ消防隊弐ノ章

漫画原作。2期

1期から引き続き作画素晴らしいし映像の作り方もかっこいいし良質すぎるアニメ化
文句がなくてあんまり書くことがない

推しが武道館いってくれたら死ぬ

漫画原作

原作の力で順当に面白い
原作は結構淡々としていると思うんだけど、アニメで声がつくと一気に華やかになって大変良い
えりぴよさんの声優のファイルーズあいが2019年の『ダンベル何キロ持てる?』に続き今作で一気に名前を轟かせた印象

2期が見たい！

かぐや様は告らせたい?〜天才たちの恋愛頭脳戦〜

漫画原作。2期

1期から引き続きの内容
みこちゃんが出てきて更に賑やかでいいね。書紀の過去編が好み

特に言うことがない

神様になった日

アニメオリジナル

障がいを取り扱ったアニメでそもそも賛否両論出るであろう内容だけど、それ以前に根本的に作りが甘く微妙なアニメだった

色々感想はあるけど今更僕が書いてもな、というところだけど...
前半冗長すぎる。麻雀とか伊座並さんの掘り下げとか必要性が感じられなかった
あと悲しいかな全体的にセンスが古いかも
ギャグにしてもシリアスにしても話の詰めの甘さにしても

前半の冗長さを差し置いて後半だけを評価しようとしても、ゲームをキーにするとか、映画が締めとかそういう甘さというか説得力のなさというかが見ていて辛かった
この甘さだと2クールあっても微妙だったかな...

障がいを取り扱った挑戦的な作品であることは良いと思う
やりたかったことはわかるしそれだけに残念

虚構推理

漫画原作

びっくりするくらい展開が遅くて主人公のかわいさだけが際立ったアニメ
2期での挽回に期待

OPはかっこいい！

グレイプニル

漫画原作

作者の性癖がすごいバトルラブコメ
かわいいし戦闘も話もいい

で、1クールかよとションボリ。逆によく1クールでこれやろうとしたと思う
早く2期をやってね（2クールで）

GREAT PRETENDER

オリジナルアニメ

映画ドラマ畑の人の初アニメ脚本作品
初なのにめちゃくちゃ安定して面白い！スゴい！
毎週次の話が気になって仕方ない。テンポも良い

2クールで話は大きく4つにわかれていて、それぞれでメインキャラの過去を掘り下げていく
最後の4つ目の話ではメインキャラ1人だけではなく主人公たる最初の1人にも大きく絡んでーと良い感じの構成
もうこの構成でしっかり成立させている巧さだけで良アニメ

肝心の最終話でちょっと置いていかれた（仕掛けが派手すぎ？）という感じがあってそこだけ残念こう、推理モノで犯人が超能力者で殺人を行っていた！みたいなそういう置いてけぼり感というか

でも大筋面白いしいいか。画面もおしゃれ

アニメ畑以外の人がこうしてアニメ業界に絡んでいく流れを今後も続けてほしい！

ジビエート

歴史に残る伝説的なクソアニメ

これほどまでにズレたアニメはそうそうない。どこかでまとめたい

でも話の本筋のSF的なところだけは正直ちょっと好き

ストライクウィッチーズ ROAD to BERLIN

オリジナルアニメ。2期からは10年ぶりの3期

今のガイナックスは死に体で、元のスタッフはカラーとトリガーにいって何かオシャレなアニメつくってるし～
そういう意味でこのスト魔女こそが美少女x燃えxメカミリx旧作オマージュと古いガイナックスの正統後継みたいになっている

やっていることは王道中の王道をいく展開なのにこれほどまでに面白い！泣ける！コンテンツの力強さを感じる

1期はバカエロミリタリアニメって印象だったのにコンテンツが拡大し歴史も刻み、前述の通り旧ガイナックスみたいな重厚さが出てきて...
これ逆にズボン設定足引っ張ってない？？

細かいところではバルクホルンの話が本当によかった。演技も最高。歴史的名作

そういえば予告で心配だった3Dも本編が始まってしまうと案外気にならなくて良かった

体操ザムライ

オリジナルアニメ

非常に丁寧な名作

最初から最後までやろうとしていることが一貫しているように思えた
最近(2020年冬頃)は脚本が雑なのかライブ感がなんだでそれがズレて尻すぼみになるアニメが多いように思う
そういった中で体操ザムライのやってきたことは本当に好印象だった

作中で城太郎、玲、レオ、それぞれが自分と向き合って成長していく姿が素晴らしい
OP, ED, BGM, どれもよく、特にメインテーマがいいところで流れると思わず握り拳に力が入ってしまう！

最初は玲ちゃんがあまりに良い子で話として都合が良すぎない？と思ったり、
城太郎が飄々としすぎていてその内心が見えなくてアニメに入れ込めない...とか思ったりしていたけど、
それらは両方話の中で氷解した（作り手のリードにまんまとハマったということになる！）

玲ちゃんがレオと遊びでやっていた忍者ごっこも後の伏線になっていたり、
話の流れで登場したマッサージ屋やクラスメートにも役割があったりと腐る展開が本当に少ない印象

序盤は少し展開が遅く感じるかもしれないが是非見てほしい作品！

■ここからネタバレ含む細かい感想

キティちゃんが玲ちゃんの夢を気づかせるところがすごい良かった！
　クラスメートやレオ、城太郎にハッキリ物申す！だけでキャラクターとしての山を消化しただけだと寂しいかなと思っていたけど、
　こうして将来を感じさせてくれる描写は本当に嬉しい
最終話玲ちゃんがクラスメートに見せた顔はきっと女優としての才能の発露だよね（最高）
玲ちゃんを探し慌てた城太郎がめちゃくちゃな内容で「心配したんだぞ！」と声を掛けるシーンは演技含めて完璧で、
　あのシーンを見た時にこのアニメは大丈夫だ！と確信した
最終話EDの入り、歌詞をすとんと落とし込むようなところまで含めて完璧！！
中盤ちょっと中弛みしたかも
後半に鉄男の掘り下げがもう少しあっても良かったかも？ +1話あったらできたのでは？
　城太郎に憧れたってところ含めて過去の努力の描写とか見たかった！

デカダンス

オリジナルアニメ

無理なく見れて続きも気になる程度には面白かった。周りの評価は高かったけど、いまいち自分には刺さらなかった。70/100点ってくらい
同クールにやっていた天晴より丁寧だったんだけど...

なんでだろう。テンポいいけどのめり込めなかったというか

とある科学の超電磁砲T

オリジナルというかなんというかよくわからない。3期

いつものレールガン
安定して見れる水準のアニメ

今回は予知／念写能力者の話の16, 17話が際立って良かった

ドロヘドロ

漫画原作

アニメ見た後に原作全部読んだ！

スタッフの原作愛が伝わる良いアニメ化
原作の不気味な雰囲気を損なわずやり遂げているのはすごい！
アニメ化に意義を感じる作品で、僕はそういうのが好き

もう1回見直そうかな

波よ聞いてくれ

漫画原作

ラジオの話の漫画をアニメでやる意味ある？と思いきや、
主人公の小気味良い喋りは意外にしっくりくるし喋りがアニメのテンポを形作るのが面白い
斬新といえば斬新だけど強いて言えば銀魂が近い？

1クールでまとめにくくない？と思っていたけど意外と無難にまとまった感じもあり良かった

八男って、それはないでしょう!

なろう原作

話については典型的ななろう系で特に言うことはない
特に言うことはないと言いつつ主人公のぬるい感じはそこそこ好きでお昼ごはんを食べながら見るのに最適だった

問題はOPで、デーモン閣下 × 宝野アリカ（アリプロ）と謎の抜擢
CMの度に変に笑える

どうも作曲作詞に苦労したらしい
このアニメでそこまでお手をわずらわせるなんて...とそこもちょっと面白い

https://natalie.mu/comic/news/369149

BNA ビー・エヌ・エー

オリジナルアニメ

僕はトリガーのアニメを面白いと思ってもどうもファン層が気に入らず鼻について素直に好きとは言えないことが多いんだけど、今作とリトルウィッチアカデミアに関しては好きだと自信をもって言える
両作品は監督が吉成曜でそこが他とちょっと違うのかも

このアニメは獣人と人間・富裕と貧困の対比とか差別を取り扱っていて政治っぽいとこも気に入った
主人公が所謂女子高生でその若い感性をもって世の中に訴えかけるようなつくりは比較的説教臭くなりにくいのがいいかも？喋らせている製作側は大人だけども

コンセプトアートがカナダ人の方ということもあってかなりオシャレ
プロメアに近いものがあるけどこっちのがどちらかというと地に足ついた感じで好きかな

上述の主人公は諸星すみれが声をあてているんだけど、本作は氏の代表作と言得るんじゃないか？！ってくらい演技が良かった
アイカツのいちごちゃんから始まり、東京喰種のヒナミちゃん、約ネバのエマ、シュガーラッシュのヴァネロペと着々とキャリアを積んでいて保護者みたいな気持ちになる
こりゃあもうベテランだなぁと感じる一方で、『いわかける』の方の上坂すみれの演技にちょっとしょんぼり（すみれ繋がり）

『ヒプノシスマイク -Division Rap Battle-』Rhyme Anima

オリジナルアニメ？

女性向けコンテンツのアニメ化で一体どんな内容になるんだと思っていたけど蓋を開けてみれば良質なトンチキホビーアニメ
突っ込みどころのありすぎるアニメで、遊戯王が好きな人は勿論のことサンリオアニメが好きな人にも刺さるかも

全体的にトンチキなんだけどラップ時の派手な演出・画面展開は結構意欲的で頑張ってるな！という印象
ラップありきで画を作るってのも大変そうだしトンチキな裏で並々ならぬ苦労があったことだろう！と思うと良くも悪くも話題作になって良かった

ラップのかっこよさがちょっとわかったので見てよかったと思う
OPも良く、僕は山田兄弟と入間くんのラップが特に好み

プリンセスコネクト!Re:Dive

ソシャゲ原作

https://omdwn.hatenablog.com/entry/2020/07/14/235635

フルーツバスケット

漫画原作。2期

1期と特に変わらず安定。安定しているけど特別面白いわけでもない
テンポがいいわけではないのでだいたいまとめて見ることになる

Pet

漫画原作

刻刻の会社が作っていて空気感は似たような感じ
似たような感じだけどそこまで面白くはならなかったなぁ

独特な世界観とか緊張感は魅力的だった

魔女の旅々

ラノベ原作

そこそこレアな1話完結型アニメ

そこまでやるかというレベルの曇らせ展開がたまらない
曇らせに徹底したかと思いきやコメディ回も絶妙でいろんな味が楽しめるアニメだった
曇らせで挫折し視聴を断念した人たちが残念でならない。気を強くもって全部見てほしい

かわいい特化アニメかと思いきやたまに作画や演出に気合が入っていたりと面白い
僕が好きなのは1話の画面手前に向かってよろめきながら走ってくるカット、ドラゴン退治の回の魔法戦あたり

最終回が2回あるような謎な構成だったけど、締め方も丁寧で好印象
2期もやってくれそうで今後に期待

無能なナナ

漫画原作

徹底的に曇らせたところで1期終了。まあまあな締め方

派手なバトルをするわけでもなく理詰めで展開していくような内容でわざわざアニメ化する必要ある？と思わんでもないけど、シリアスなシーンの緊張感をジリジリ感じられた点では有意義だった
おばかなピンク髪キャラばかりを演じている印象のある大久保瑠美による主人公の悪～い演技も個人的には斬新で面白かった

OPが割と好き

ラブライブ!虹ヶ咲学園スクールアイドル同好会

オリジナルアニメ

既存のラブライブの枠組みを打破しようとしている姿勢はすごくよかった
同好会という枠組み、侑ちゃんの立ち位置、難関かと思われた生徒会長がするっと入ったり、ソロ活動前提だとか

如何せん自分がアイドルアニメをそこまで好きじゃなくて毎回のライブシーンを蛇足に思ってしまったり、ラブライブ世界は基本的に優しく徹底的なシリアスになりにくいところは合わなかった
毒にも薬にもならない女児アニメを見る時の気持ちに近いかも

結局やっていることは基本的に1話完結で各メンバー回を設けて掘り下げて～って感じなので、もっと密度を高めるために人数を減らしてよ！と強く思う
ガンダムにおけるターンエー...とまではなれなかったかな

個人的にはかすみんの「旧体制でイヤだった過剰なストイックさを新人に強いてしまっているかも？！」と葛藤するあたりがお気に入りで、あの辺をもっとシリアスに話全体の根幹にしても2クールでやってくれたら骨太で好きだったかも
旧体制→解散→再結成→葛藤→ライブで終、みたいな... 月並みかなぁ

でもなんだかんだでこれまでのシリーズの中では一番好きだった

ランウェイで笑って

漫画原作

単純に話がよくて大変好きだった

原作は読んでいないけど、アニメでやる意義はあったのかどうかわからない
それこそランウェイを歩くシーンはアニメ映えしてたからそこらへんになってくるのかも

LISTENERS リスナーズ

オリジナルアニメ

ネット的にはよくもわるくも話題なカゲロウプロジェクトの人が原案だったり音楽をやっている

音楽がテーマでそこに気合が入っているだけあって贅沢に毎話EDが映像込で変わるのがすごい！OPも好き
作中には音楽が元ネタなあれこれが散りばめられていて僕的には大変楽しめた（特にプログレの回）
作中に漂うブルージーな雰囲気にも本作独特なものを感じた

と、刺さる人には刺さる内容をしていたんだけどアニメそのものはちょっと押しに欠けたような印象
正直あんまり話題にならなかった割に僕はかなり好き

今どきな感じの萌えに媚びないキャラデザインもいい
ヒロインの性格もこれまた今どきの「男に都合のいい感じ」ではなかったのがいい

全体でストーリー進行していくんだけど大半が1話完結できれいにまとまっていた
ガンソみたいなつくりね

Re:ゼロから始める異世界生活

なろう原作。2期。分割2クールの1クール目

安定して面白い

分割2クールじゃなくて通しのほうがよかったかなぁ

2020-12-08

【Docker】Dockerのドキュメントを読んで知らなかったことをメモ_ベストプラクティス編

Docker

雰囲気でDocker, docker-composeを使っているので一度ドキュメントを読んでみて怪しかったところをメモ

docs.docker.jp

コピペ＋所感という内容なので記事としての価値はないです（メモ書き）

イメージを小さく

適切なベースイメージ

適切なベースイメージで始めましょう。たとえば、 JDK が必要なら、一般的な ubuntu イメージに openjdk をインストールするのではなく、公式 openjdk イメージをベースにするのを検討します。

これはわかる。超軽量なイメージをつくる！みたいな記事はたまに見るけど、そっちの方向に頑張ることはあまりしそうもない

レイヤをへらす

RUN命令をまとめることでレイヤを減らす
みんなオシャレでやってるのかと思ってた

RUN apt-get -y update
RUN apt-get install -y python

↓

RUN apt-get -y update && apt-get install -y python

因みにレイヤを増やすのはRUN, COPY, ADD命令だけ

命令における複数行にわたす引数の並びはabc順

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#id13

abc順が作法的に間違えにくく良いらしい。考えたことなかった
パッケージの重複指定の危険が減るとか言われてみれば確かに

RUN apt-get update && apt-get install -y \
  bzr \
  cvs \
  git \
  mercurial \
  subversion

マルチステージ・ビルド

https://docs.docker.jp/develop/develop-images/multistage-build.html

知らなかった
ビルドする環境と実行する環境を分けて最終的なイメージのサイズを小さくできる
多分他にもいろいろやれそう

ビルドコンテクスト

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#understand-build-context

docker build の -f オプションでdockerfileのある場所を指定するんだけど、そのdockerfileがあるところ、現在作業しているディレクトリをビルドコンテクストと呼ぶらしい

以下のように指定すればdockerfileと資材のディレクトリを分けられる

mkdir -p dockerfiles context
mv Dockerfile dockerfiles && mv hello context
docker build context -f dockerfiles/Dockerfile

stdinを通してDockerfileをパイプ

普通のやつ

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#stdin-dockerfile

以下は同じ

echo -e 'FROM busybox\nRUN echo "hello world"' | docker build -

docker build -<<EOF
FROM busybox
RUN echo "hello world"
EOF

docker build -のハイフンでDockerfileのPATHに代わりその内容を渡すような感じ

あんまり使うことはなさそう

gitリポジトリの資材を使う

-f でgitを指定しつつ、そこにハイフンを付け足して -f- とすることで、
gitをcloneしてその資材をstdinで流し込むDockerfile(の構文)の中で利用できる

docker build -t myimage:latest -f- https://github.com/docker-library/hello-world.git <<EOF
FROM busybox
COPY hello.c .
EOF

こんなややこしいことをする機会があるのかわからない
git利用しない方含め、1枚のshellscriptファイルで色々完結させたい時には使うかもしれない

.dockerignore

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#dockerignore

あんまり書いたことないかも
node_modulesあたりは除外するんだろう

ビルドキャッシュ

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#leverage-build-cache

あんま考えてなかった

キャッシュを使いたくない時は

docker build に --no-cache=true を指定

ADD, COPYコマンドはファイルの内容についてチェックサムを計算
それ以外の場合はコマンド文字列そのものがキャッシュの一致判断に利用される（ファイルは見ない）

ということを思うとcurlだのapt-getして取得してくるものが古いとか、そういう時に考えることになりそう

Dockerfile

LABEL

イメージには複数ラベルが設定でき、昔はLABELコマンドで余分なレイヤの追加を避けるために1行で設定していたらしいけど、いまは1行である必要はない
でも1行で書くのはまだサポートされてるし見栄え的にもそっちの方がよさそう

LABEL vendor=ACME\ Incorporated \
      com.example.is-beta= \
      com.example.is-production="" \
      com.example.version="0.0.1-beta" \
      com.example.release-date="2015-02-12"

RUN

apt-get自体のupgradeはダメ

RUN apt-get upgrade や dist-upgrade の実行は避けてください。ベース・イメージに含まれる重要パッケージは、権限が与えられていないコンテナ内ではほとんど更新できないからです。（中略） foo というパッケージを更新する必要があれば、 apt-get install -y foo を利用してください。

知らなかった！

apt-get update と apt-get install は同一RUNで実行すること

RUN apt-get update と apt-get install は、同一の RUN コマンド内にて同時実行するようにしてください。たとえば以下のようにします。

RUN apt-get update && apt-get install -y \
    package-bar \
    package-baz \
    package-foo

知らなかった！

キャッシュの問題。詳しくは直接ドキュメント見たほうがいい

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#apt-get

aptキャッシュを消す

RUN apt-get update && apt-get install -y \
    aufs-tools \
    automake \
    build-essential \
    curl \
    dpkg-sig \
    libcap-dev \
    libsqlite3-dev \
    mercurial \
    reprepro \
    ruby1.9.1 \
    ruby1.9.1-dev \
    s3cmd=1.1.* \
 && rm -rf /var/lib/apt/lists/*

最後にaptキャッシュを消してイメージサイズを小さくしている

公式のDebianとUbuntuのイメージは自動でこれやってるから明示的にやる必要はなし

パイプを利用する処理でエラーを検知

RUN wget -O - https://some.site | wc -l > /number

※wgetした行数をhoge(ファイル)に吐く

これだとwgetが失敗してもwc -lが成功すればコマンドが失敗とはならずビルドが通ってしまう

パイプ内のどの段階でもエラー即コマンド失敗にするためには set -o pipefail && を使う
(シェルが-o pipefailオプションに対応してないとダメだけど)

RUN set -o pipefail && wget -O - https://some.site | wc -l > /number

CMD

CMDはイメージ内に含まれるソフトウェアを実行するために用いるもの

CMD ["実行モジュール名", "引数1", "引数2" …] の形式
CMD ["apache2","-DFOREGROUND"] みたいな

RUNとの使い分けをあんま考えてなかった！

ENV

環境変数の設定にもPATHの設定にも使うというのはよくある話

ENV PATH /usr/local/nginx/bin:$PATH
ENV PASSWORD="xxx"

アプリケーションのバージョン固定にも使うと便利とのこと

ENV PG_MAJOR 9.3
ENV PG_VERSION 9.3.4
RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && …
ENV PATH /usr/local/postgres-$PG_MAJOR/bin:$PATH

ENVによって中間レイヤが作成されるため、環境変数をセットしたのと別の行でunsetしても値は保持されてしまう
それに対応するには～...というのがドキュメントに書いてあるけどあんまり使う機会はなさそう
迂闊にunsetしてるコードを見たら思い出したい

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#apt-get

ADDとCOPY

使い分け

COPY：ローカルからコンテナにコピーするだけ
ADD：ローカルでのtar展開やリモートURLサポートもついてる！

ややこしいからCOPYを優先して使う
ADDを使うのはローカルのtarを展開してイメージに書き込むときだけ
ADD rootfs.tar.xz /

複数ステップで異なるファイルをコピー

まとめずに個別にコピーすると、個々のステップのキャッシュのビルドが最低限に抑えられる

# こっちより
COPY . /tmp/
RUN pip install /tmp/requirements.txt

# こっちのほうが望ましい
COPY requirements.txt /tmp/
RUN pip install /tmp/requirements.txt
COPY . /tmp/

上の例だとローカルのコンテクストの中で差分があったら、COPYコマンドのキャッシュが無効化される
下の例ならrequirements.txtに差分があればそこのCOPYだけキャッシュ無効化、それ以外のコンテクストに差分があればそっちCOPYだけキャッシュ無効化
ということになる（はず）

リモートURLからパッケージを取得する場合ADDじゃなくてcurlやwget

イメージサイズの問題

こうしておくことで、ファイルを取得し展開した後や、イメージ内の他のレイヤにファイルを加える必要がないのであれば、その後にファイルを削除することができます

消せばイメージのサイズを小さくできるということだと思う（消さないならどっちでもいいのか？レイヤの問題？）

# だめ
ADD http://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all
# よい
RUN mkdir -p /usr/src/things \
    && curl -SL http://example.com/big.tar.xz | tar -xJC /usr/src/things \
    && make -C /usr/src/things all

USER

サービスが特権ユーザでなくても実行できる場合は、 USER を用いて非 root ユーザに変更します。
ユーザとグループを生成するところから始めてください。Dockerfile 内にてたとえば
RUN groupadd -r postgres && useradd -r -g postgres postgres

こうしてユーザとグループを作ったあとで、
USER <user>[:<group>] or USER <UID>[:<GID>]を書いておくことで、それから先のRUN, CMD, ENTRYPOINTのコマンドを指定したユーザで実行する

ついでにsudoのインストールと利用は避けよう！とのこと

WORKDIR

絶対パスで書こう！

RUN cd ... && do-somethig みたいなことをせずWORKDIRを使おう！

さぼりがち

ONBUILD

コマンド自体を知らなかった

親側のイメージに処理を仕込んでおくと、
それをFROMとして作られる子のイメージで処理を実行させられる感じ

ここの例がわかりやすい

https://deeeet.com/writing/2014/03/21/docker-onbuild/

自分で書くことはほぼ無いんじゃないかと思うけど、このコマンドを知っておかないと、これが使われてた時に混乱することになりそう

2020-12-04

ソビエトロシアの文学メモ

Муза

私の才は乏しく、声も大きくはない、
だが私は生きており、私の存在も
この地上の誰かにとっては愛しいのだ。
はるか後の人々は、詩の中に
私のことを見出してくれるだろう。
誰が知ろう、私の心が
彼らの心と結びついて、
私が同世代に友を見出し得たように、
後の世代に読者を見出し得ないなどと。
　
E.A.バラティンスキー
https://twitter.com/kyuseisya_/status/1211890434609299457

Мой дар убог, и голос мой не громок,
Но я живу, и на земли мое
Кому-нибудь любезно бытие:
Его найдет далекий мой потомок
В моих стихах; как знать? душа моя
Окажется с душой его в сношенье,
И как нашел я друга в поколенье,
Читателя найду в потомстве я.
　
<1828>
Русские поэты. Антология в четырех томах.
Москва: Детская литература, 1968.
Евгений Баратынский - RUSSIAN POETRY

ロシア語のWikipediaが詳しい
Баратынский, Евгений Абрамович - Wikipedia

これは僕が大変気に入ってる詩で、僕が写真をせっせと撮る理由それそのもの
この詩を知ったときには喜んだものだった！
いつかこの詩を印刷して額に入れて家に飾りたい

Умом Россию не понять

ロシアは頭ではわからぬ
並みの尺度では測れぬ
ロシアならではの特質がある
ロシアは信じることができるのみ
　
フョードル・チュッチェフ
ロシアのアフォリズム5選 - RUSSIA BEYOND

Умом Россию не понять,
Аршином общим не измерить:
У ней особенная стать —
В Россию можно только верить.
　
Умом Россию не понять - Wikipedia

この詩を諳んじるとロシア人に喜ばれるらしい
日本でいう「春はあけぼの」みたいな

いつか役に立つ日がくるはずだ、と心に留めている詩だけど一向にその機会がこない
なんならこれがプリントされたTシャツを持っている

汎スラブ主義色

www.abysse.co.jp

赤：自由のために流された血
白：まばゆく輝く光明・清潔
青：澄みわたる空

※画像を貼るのがめんどくさいのでリンク先（引用元）を見ること

ロシアの国歌を聴く時にこれを知っていると音に深みが出る

はじめに(強い私情を添えて)

組織

ITの内製化

その他

ITの内製化

組織

言うほどまとまってないまとめ

概要

STG DBの横にテスト用のDBを立てておいて、テスト時にはそこに接続

テスト実施時にDockerでMySQLを立ち上げて、テスト時にはそこに接続

結論

正常系

準正常系

はじめに

本題のあらすじ

時価総額加重平均を採用したインデックスファンド

時価総額加重平均??

インデックスファンド??

結論（選んだ運用商品）

Anime Of The Year

各アニメについて

アクダマドライブ

天晴爛漫!

アルテ

痛いのは嫌なので防御力に極振りしたいと思います。

いわかける! - Sport Climbing Girls -

炎炎ノ消防隊 弐ノ章

推しが武道館いってくれたら死ぬ

かぐや様は告らせたい?〜天才たちの恋愛頭脳戦〜

神様になった日

虚構推理

グレイプニル

GREAT PRETENDER

ジビエート

ストライクウィッチーズ ROAD to BERLIN

体操ザムライ

とある科学の超電磁砲T

BNA ビー・エヌ・エー

『ヒプノシスマイク -Division Rap Battle-』Rhyme Anima

プリンセスコネクト!Re:Dive

Pet

魔女の旅々

ランウェイで笑って

LISTENERS リスナーズ

イメージを小さく

適切なベースイメージ

レイヤをへらす

命令における複数行にわたす引数の並びはabc順

マルチステージ・ビルド

ビルドコンテクスト

stdinを通してDockerfileをパイプ

普通のやつ

gitリポジトリの資材を使う

.dockerignore

ビルドキャッシュ

Dockerfile

LABEL

RUN

apt-get自体のupgradeはダメ

apt-get update と apt-get install は同一RUNで実行すること

aptキャッシュを消す

パイプを利用する処理でエラーを検知

CMD

ENV

ADDとCOPY

使い分け

複数ステップで異なるファイルをコピー

リモートURLからパッケージを取得する場合ADDじゃなくてcurlやwget

USER

WORKDIR

ONBUILD

Муза

Умом Россию не понять

汎スラブ主義色

炎炎ノ消防隊弐ノ章