天気の子で厨二心になる

本当に便利な時代になった。

僕はVHSでテープが擦り切れるまでBTTFシリーズやインディージョーンズグーニーズなどなど齧りついてたし、定期的にビデオレンタルショップXファイルを借りては返し借りては返し、半永久的に観ていた少年だった。

毎年ドラえもんの映画を家族で観に行き、中学生になればタイタニックを見るために名古屋駅まで自転車で走ったりもした。

 

ここ数年はというと、猫も杓子もストリーミング配信になり貸出中のラベルに泣くことは無くなったし、TVも50インチがミドルサイズ扱いだそうだ。

個人的には子供を連れて映画館に行くハードルは高く、映画に浸れる環境は家で十分と自己暗示かけている

 

そんなワケで近年は映画館に行くことがめっきり少なくなったけれど、今回はタイミング良く映画館に出向く時間も取れたので観てきました。 

新海誠の映画は『ほしのこえ』を当時何かの拍子に観たのが最初で、ものすごいインディー色ながらもメチャこだわってるのが伝わってくる光の描写が印象的。話は退廃的な世界を舞台にしたSFで、主観だと少し前にあった最終兵器彼女という漫画に近い空気感。刺さる人には刺さる作品だったと思う。

 

今作は、『君の名は』が爆売れしたのもあり、客層は10代〜50代くらいの幅広さはあったかも?前作のようなキャッチーなストーリーが知名度を上げたのは間違いないだろうと思う。『ほしのこえ』みたいな尖った世界観の映画だと難しいのかな。SFというジャンルも厳しそうだ。。

そういう意味で『天気の子』は

お約束的なボーイミーツガールの展開を引っ提げて

実在の街を超絶綺麗に描いた聖地巡礼推奨の風景で

現代を舞台にしたファンタジーをメインストーリーに

複雑な10代の気持ちを表現しつつアクションシーンを散りばめる

そんな前作に負けないレベルのキャッチーさが詰め込まれてた。

並べ立てるとベタ過ぎて批判っぽくなるけど、全体通して飽きない展開で面白かった。

世界観としては基本は大人の世界をリアルに表現していて、主人公は振り回される側の立場が多い。社会(それも東京の極端な部分)に揉まれる描写が多いので、このあたりはちょっと苦手意識とか好きじゃない人がいるかもしれない。

ただ、この主人公の青臭さとか、反発する心境とか、思春期の雰囲気が抜群に上手い。この厨ニ感が刺さる人はノスタルジーを感じ取れたと思う。嫌いじゃない。

 

ストーリー展開的には強引なところもあるし消化不良な伏線もあったけど、主人公ふたりのボーイミーツガールと映像美があればお腹いっぱい満足です。

 

ちなみに一緒に観に行った嫁は大満足。

非常に面白かったとの感想だったが、「端々に謎の童貞感がある」と言っていた。

なるほど、なんとなく解る気がする。。

 

DeNA.go #2でアーキテクチャとテストについて考える

チーム開発で、Goに本格的に取り組むことになって少し経ったところなのですが、最近Goで気になっているのはアーキテクチャまわりとテストだったので、その点に注目して参加してきた。

 

## 1 新ゲームサーバ基盤TakashoでのGo言語活用事例の紹介

speakerdeck.com

 

- 自社ネイティブアプリ(ゲーム)の共通サーバ基盤のお話

  - ひとつのサーバで共通の機能(ログイン、プレイヤーデータ等)を一元管理するための基盤

  - 共通故の制約が多く、ゲーム毎の拡張自由度が小さいのが課題

 

共通基盤あるある。しかし、ゲーム業界はタイトル毎の要求項目が細かく違いそうなモノだけど、かなり難しいのではなかろうか

と思ったが、いわゆるガチャも共有の仕組みの一つのよう。収益の本流も共通なら、なるほど必要だろうなぁ。。

 

- 新サーバ基盤

  - Webサーバフレームワークと、クライアントSDKとあわせて提供

  - サーバはGo、クライアントはC#

  - 1サーバ1クライアント構成

  - サーバはGCP上にterraformで構築

  - パッケージ管理ツールはdep(go modulesに移行中)

  - サーバをGoにした理由は、学習コスト対効果が良いから。そして安定性があること。

 

具体的に他のどの言語やフレームワークとの比較で学習コストが低かったのかを聞きそびれてしまった。

構成もGCP特化でストレージはCloud Spannerとのことなので、このあたりはゲーム用基盤として最適化されていて便利そう。

ゲームユーザ向けならスケーラビリティも非常に重要であるし、データ量もさぞ膨大だろう、、

 

開発者はgo getして利用するあたりは、package単位で利用するGoの利便性が際立っているように思える。

このあたり、package設計は重要なポイントだろうと思う。

 

- コードの自動生成

  - GAEgRPCが使えないから辛い独自実装しよう

  - protobuf

    - 拡張protocコマンドでサーバサイド、クライアントサイドのコードを自動生成

  - go templateでコードテンプレート

  - テストコード自体の自動生成

  - できるかぎり自動化をがんばる

 

ProtocolBufferはなかなか良いとの推しを頂く。

インターフェースだけでなく、ドキュメント生成もできるらしい。なにそれ(無知)

gRPCの代替として使えるくらいのスキーマ言語らしいので十分だろうと思うが、RESTでも使えるだろうか?

ちなみにコードの自動生成の観点では、go generateを使う方向で検討していたが、今回の勉強会ではgenerateの話は一切無かった。

コード量が多いと言われるGoにあって、できる限りの自動化はやりたいところ。

 

## 2 次世代タクシー配車サービス「MOV」におけるテスト事例紹介 

speakerdeck.com

 

 

- テスト方針

  - テスト全体に関わるfixtureを使わない

  - マスタデータ以外をDBにロードしない

  - 並列テストのために、bxcodec/faker v3でデータ生成

  - 構造体にgoタグをつけてデータを自動生成する

  - 本番用のコードにgoタグつけるのが嫌なので、テスト用に同じ構造体を自動生成してる

 

前者は順当な話。テストの実施に必要なデータは冪等性を担保すべきだ。

並列テストにおけるfakerはなかなか便利そう。テストデータを用意する上で省エネが図れるなら試す価値はあるかも。

本番用のコードにgoタグつけるのが嫌

このあたりは非常に意見が割れそうだが、そのテストだけのために同一構造体自体をテスト用に自動生成するのは気合入った話だと思う。

 

## 3 DeSCヘルスケアにおけるGo 活用事例紹介 #DeNAgo

speakerdeck.com

 

- レイヤードアーキテクチャ + DI

  - 依存性逆転の原則を守る

  - ライフサイクルをレイヤード分離

  - gomockを使って、テスト中はmockDIする。

    - ただでさえコード量、テスト対象が増えるため各レイヤーでは最小限

  - DBデータ取得、保存はinfrastructure

  - gotestsコマンドでテストの雛形を生成

- エンベロープ暗号

  - 会社のセキュリティポリシーとしてDBの暗号化+カラムの暗号化

 

アーキテクチャのお話で、レイヤードアーキテクチャを採用しているとのこと。

ディレクトリは割と素直な名付けになっている。噂によるとメルカリさんもレイヤードアーキテクチャらしい。

ぼくのチームはクリーンアーキテクチャで進めているため、読み替えができれば大きな違いは無し。

導入メリットは、やはり変更時の影響分離が大きいところだそう。

 

エンベロープ暗号は聞いたことが無かったのでこれは別途調べる。

 

## そのほか

 

いろんな方面から耳にした内容。サンプル数の少ない情報として、あくまでメモ程度。

 

- Infrastructure層のテストは実際のFirestoreを叩きに行っているとのお話があり

ローカルシミュレータの挙動がちょっとということのようだが、テストを回す毎にお金がかかるのとパフォーマンス効率の面では厳しい部分がある。

ただし、本番の環境を叩きに行くテストのメリットはあり、悩ましいところのようだ。

Firestoreは複雑なクエリを書くことができないそうなので、テストケース自体が簡素なのだろうか?

 

- ネイティブアプリはSwift, Kotlinでそれぞれ作ることが多く、Flutterはまだちょっと

そのうちFlutter勢力も増すかもしれないが、直近のGoogle I/OでもKotlin firstと言われている段階なので時期尚早なのかもしれない。

 

- エディタはみんな好きにやってる

最近になって、VSCodeはコード補完(LSP)が良い感じに向上してきたようで増えてきた模様。

JetBrainsは独自の補完を実装しており、それが爆速(らしい)

 

- Goでテストの可読性を上げるためには

テーブルドリブンテストはおすすめ。

データや期待値は.golden拡張子で定義することができる。

 

- やはり、RDBMSのいい感じのデファクトORMはなさそう

が、黒魔術感がなく薄めのORMとして構造体の受け渡しができるsqlxは良さそう。

 

## まとめ

 

- もともとCRubyを書いていた人がGoも触れているというところから、参入コストは低い。君でもやれる。

- Goはそもそもコード量は多い。そのため、チーム開発ではコードの自動生成をどうするか真面目に考える必要がある。猫も杓子もテストもドキュメントも自動化

- プロダクトやチーム規模によるが、サービスの改善を行うためにもドメインの分離をするためにもアーキテクチャは大事。コード量増加は辛く折れそうになるが自動化と気合で乗り切る。

- Goのテストはテーブルドリブンの導入やツール類を駆使することで可読性は随分違う。

- DeNAさんの勉強会は選べるお弁当、選べるドリンクが豊富であたまが下がる思い。ごちそうさまでした。

 

Kubernetesの初学者向けイベントに参加したはなし

仕事が一段落したこともあり、身も心も余裕ができたタイミングで良い巡り合わせだったので記録しておく。

一晩でKubernetesを覚えて帰ろう。ワンナイトBootCamp! -- cndjp#10

というイベントです。

 

最初にぼくのKubernetesとコンテナ技術との関わり具合をざっくりしたためておくと

  • 3-4年ほど前にDockerを使ったサービス開発に携わる。
    オーケストレーションツールなし。
  • 直近は別案件で開発環境にDockerを利用。
    ただしチーム全体での導入はせずチーム内の有志のみ。
  • 業務でのマネージドサービスの利用経験なし。
  • KubernetesはMinikubeを少し触った程度。

という初学者全開の状況。

まさに自分のためのイベント。 

参加の目的

次はDockerもっとうまく使いたいなと思いつつも、Kubernetes知らずに走るのは流石に無謀じゃね?と気持ちと、業務で使う上での説明材料探し。

有用性をどれだけ熱く語れるようになるかは一番大事なポイント。

各発表について

イントロ

speakerdeck.com

そもそも何故オーケストレーションが必要か?というところから。

Dockerを個々に管理するのは、数台のコンテナだけでも面倒さ具合は身に沁みてたので素直に腹落ちする。3年前に入門してたらいろいろ楽だったかなーと回想しつつ聞いた。

 

Kubernetesの基礎

speakerdeck.com

 

全体像と用語の理解。Cluster内の構成、componentの役割について。API Serverの冗長構成の重要性を得る。

管理責務はざっくり以下の理解

Deployment

 -> ReplicaSet

  -> Pod

   -> Container

特に、ReplicaSet, Podについては自分で動かして試したい。

 

動いているところを見てみよう

実際のターミナルをみんなで見る。

テスト用のREST APIは人それぞれで面白い。自分も少し個性を出して遊ぼうと自分で使いやすいように作ってみようと思えるデモだった。

内容的には、RollingUpdateとconfigureすることでのManifestと実態の同期はお作法としてまず覚えることにする。

 

Kubernetesアーキテクチャと発展的な使い方

speakerdeck.com

vtuber推しからAPI Serverを中心としたControl Loopのおはなし。発展的な使い方はどこへ。

kubectl runの裏で走るAuthenticationやAdmission Controlの挙動を掘っていくディープな内容。入門レベルの自分にはハイブローだったが、動作を知っておくに越したことはないので、また少し触ったタイミングでスライドを改めて見させて貰おうかと思う。

 

まとめ

これだけ初学者向けってのもあまり無いと思うので非常にありがたいイベントでした。

一方で、個人的にはここから具体的に利用するために課題を整理していかなくては。

  • とりあえず試す
  • k8s+DockerでのRDBMSサーバの扱いやユースケースorベストプラクティス
  • オンプレ環境での活用方法
  • チームメンバーの学習の流れ
  • これらを踏まえたk8s導入メリデメ説明
  • とりあえず試す

 

運営の皆様ありがとうございました。