まっしろけっけ

めもてきなやーつ

Rails Developers Beer Bash 〜Railsのトレンドとこれから〜 で登壇してきた #railsbeerbash

開発 プログラミング web ruby rails

Rails Developers Beer Bash 〜Railsのトレンドとこれから〜 とは

techplay.jp

Rails6 についてどうのこうの喋る会(雑)

登壇経緯などは資料に書いてあるので読んでください

登壇内容

Beer Bash ということもあり、登壇者の人々で乾杯前に練習と称して先に飲んでいたのでちょい酔いという状態で登壇した。

speakerdeck.com

Rails6 にする為に TA をしたって話

結局リリース自体は出来なかったので TA は失敗だったのだけれど、あとはリリースのみなのでまぁほぼ成功では？

その他の内容

www.slideshare.net

Rails6 で対応された multi db の話

minne でも switch_point を使用して multi db 対応してるので Rails 標準で対応されるのは嬉しいですね。
Rails6 upgrade 後に switch_point から標準に移行すると思うのでその時に参考になりそうな資料でした。

パネルディスカッション

登壇だけという話だったのですが、急遽前日にパネルディスカッションも出てくれんか？と言われて出ることになった。
事前に頂いていた質問のほとんどが既に出来上がっている資料に書いてあり...これ登壇時にほぼ話すんじゃが...みたいな気持ちになって不安だったが、流石モデレーターのうなすけという感じでなんかいい感じになった気がする

minne のマイクロサービス化の話(たぶん過去にこのブログでも触れた)とか並列 test が標準機能になって嬉しいとか gem の update 戦略とか話した記憶(途中からすごくトイレ行きたくなったのだけは鮮明に覚えている)

自分以外のパネラーの人々の所属する社での方針やお悩みなども聞けてよかった。

懇親会 & LT大会

LT の資料は割愛(探すのがめんどくさかったとかそういうんじゃないんだ...)
それな〜とあるあるな感じの内容が多かったような。

懇親会もなんかずっと喋っていた気はする。

  • 手動テストする際の範囲の話
  • dependabot と GHE の話
  • 管理画面の gem の更新の話

とか他にも色々話した記憶

最後に

最近クラウドネイティブ関連の事ばかりやっていて Ruby/Rails 関連の勉強会も凄く久しぶりだった気がするんですが、こっちの方が知ってる人が多いので安心するというのはあるなという気持ちになって不思議な感じ

他社の人々と Rails 関連の話をがっつり出来たのも久しぶりだったのでとても有意義な時間を過ごせました。
ありがとうございました。

EKS で Auto Scale 導入したお話

kubernetes 開発 ツール

はじめに

お仕事で開発している minne というサービスは OpenStack と AWS のハイブリットクラウドなのだけれど(詳細はこちら)色々つらみがあってそのつらみを解決するために Kubernetes への移行を行ったんですよ。(移行についてはまた別のお話なので何処かで)

ハイブリットなのは変わらず OpenStack に cluster 構築してというのと AWS 側は EKS を使うという構成。

それで EKS 側は Auto Scale 使えるじゃん！ということを思い出したので実際に導入したという話。

Auto Scale 導入までの道のり

Auto Scale を導入するまでに必要な手順がいくつかあるので順を追って解説

Metrics Server の導入

docs.aws.amazon.com

だいたい手順は上記に書いてあるんですけど このリポジトリ clone して version とかきになるなら選んで apply すれば良いという感じ

$ git clone git@github.com:kubernetes-incubator/metrics-server.git
$ cd metrics-server

# このままだと最新の master なので最新のリリース version に切り替えるとかやる

$ kubectl apply -f deploy/1.8+/ # Kubernetes の version によって 1.8+ じゃなくて 1.7 とかのディレクトリを選ぶ必要がありそう

$ kubectl get deployment metrics-server -n kube-system --watch
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1         1         1            1           10d

$ kubectl top node
NAME                                              CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxxm        15%       xxxxMi          60%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxm         3%        xxxxMi          54%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxxm        24%       xxxxMi         65%

これで node や pod の metrics を確認できるようになるので Horizontal Pod Autoscaler を使うことができるようになる。

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler - Kubernetes

Horizontal Pod Autoscaler(以下 HPA) は雑にいうと負荷によって pod 数を増減(スケールイン/アウト)させるやーつ

下記のような yaml を用意する。

# hpa.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: sample-hpa
spec:
  minReplicas: 2 # 最小の pod 数
  maxReplicas: 200 # 最大の pod 数
  metrics:
  - resource:
      name: cpu # pod の cpu の使用率を基準に増減させる
      targetAverageUtilization: 20 # 使用率 20% を基準に増減させる
    type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-deployment # 増減させたい deployment の名前を指定

$ kubectl apply -f hpa.yaml
$ k describe hpa
Name:                                                  sample-hpa
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           kubectl.kubernetes.io/last-applied-configuration=.....
CreationTimestamp:                                     Fri, 19 Jul 2019 12:03:05 +0900
Reference:                                             Deployment/sample-deployment
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  15% (xxxxm) / 20%
Min replicas:                                          2
Max replicas:                                          200
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     False   BackoffBoth         the time since the previous scale is still within both the downscale and upscale forbidden windows
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
  Type    Reason             Age   From                       Message
  ----    ------             ----  ----                       -------
  Normal  SuccessfulRescale  33s   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target

これで HPA が有効になった。

最初は Metrics の current 部分が unknown となるが待っていれば Metrics 収集して正常になるはず。

注意が必要なのは対象の deployment の全 container の resources (今回は cpu が対象なので cpu)が設定されていないと unknown のままで Events にエラーが出てるはず。他にも対象の deployment と同じ label 名の deployment の各 container も同様に resources が設定されてないといけない > see

HPA が有効になったので pod が増減するか見てみる

# アクセス数とかは調整してください
$ ab -n 100000 -c 100 "対象の deployment へアクセスが流れる IP を指定"

# 別プロセスで
$ kubectl get pods --watch

これで pod が増えたり減ったりする様子が眺められるはず。
k describe hpa で hpa の様子を見ると Events に pod を増減させている情報も表示されます。



これで HPA の導入は終わり

Cluster Autoscaler

GitHub - kubernetes/autoscaler: Autoscaling components for Kubernetes

最後に workernode を増減していきます。

まずは workernode の IAM に Auto Scale 周りのアクセス権を付与する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*"
        }
    ]
}

上記のポリシーを作成し workernode のロールにアタッチする。

Autoscaler のマニフェストは こちら

YOUR CLUSTER NAME の箇所を自身の環境に合わせて apply

pod の増減で確認した時のように負荷をかけつつ下記で log を眺める

$ kubectl logs -f deployment/cluster-autoscaler -n kube-system

# 別プロセスで
$ k get node --watch

これで EKS での Auto Scale の導入はおしまい

さいごに

HPA を有効にするところで少しハマりましたが、シュッと Auto Scale が有効にでき AWS の使用料も抑えることができたので便利でした。

本番導入して 10 日程ですが今の所問題は起きてません。

Web CM に出た話

はじめに

既に公開されて一ヶ月経ってしまったのだけれど、ジョージアの Web CM にでたので、そこら辺の話を書いていく。
前職の時に TV 番組や TV CM にちょっと映ってる程度のことはあったのだけれど自分がメインで CM に出るとか初だったので色々面白かった。

そもそもなぜ出ることになったのか？

上記の経緯で社に話が来て、なんやかんやあって自分になったので出ることになった。
最初に聞いたときはコカコーラの CM かと思ったらコカコーラ社のジョージアの CM だった。

当日の様子

撮影日は 4/1 だったので実はエイプリルフール的なアレだったりするのかもしれないなどと考えていたのだけれど実はそうではなかったらしい。

社内で撮影準備が進められている中で、撮影始まる少し前にプロデューサー(？)っぽい人と話たりリハーサル的に質問に答えたりしたのだけれど下記のようなことを言われた

  • この CM をみた人がソフトウェアエンジニアっていう仕事に憧れるようなものにしたい
  • どんな流れで質問するか？みたいな奴を事前に渡してはいるけど特に気にしないで聞きたいことがあれば聞いてもらっても良いし自然な感じでやってほしい
  • 事前のリハーサルでこのタイミングで二人にこれ聞いてみましょう的な話(サーバって知ってますか？とかの逆質問)

こんな感じのことを話したような気がする。

いざ撮影開始なのだけど撮影現場に行った時に「後藤さんは入りま〜す」パチパチ(拍手)みたいなのをやってもらい TV とかでみたことあるやつや って感動した。

CM みて貰えばわかるんですが、マジで久しぶりにあんなに緊張したなというほど緊張した。(登壇とかの比じゃない)
その結果リハーサルの時に言われたことは全て頭の中から消え失せてしまっていて、今思い返すと自分でも笑える。

飯尾さんも R 指定さんもすごく優しく、また言葉のチョイスとかがマジで凄いなって思った。
撮影の合間も気を使って貰って色々話しかけてくれた。

実際の CM について

www.youtube.com

この中で話している 仕事をしているというよりは遊びに近い感覚 というのは、以前から社内で 1on1 とかやってる時にも何人かには話してたりするので本当にそういう感覚なのだけれど誤解して欲しくはないのは遊びに近い感覚だからと言って真面目にやっていないというわけではない。

最近も 5 年後の minne のエンジニア組織をどうするか？みたいな資料を作ったり、インフラのコスト削減をやったりなどを真面目にやってる。

プロとしての自覚も誇りも持っているので、自分の仕事はきっちりこなしたいと思っているし自分がやると言った仕事に関しては基本的にやりきっている(はずで)だからこそ周りからエンジニアとして信頼して貰っていて今の CTL という職位を任されていると思っている。

それにサービスが成長しなければ自分の楽しい遊び場がなくなってしまうので、より良いものをユーザに提供し多くのユーザに使ってもらうことでそこで発生する新たな問題を技術で解決していくというサイクルに入るためにも事業の成長を技術的にどう推進していけるのか？ということも考えている。

最後に

貴重な経験ができて楽しかったです。基本的にやったことないことはとりあえずやってみるかという精神で生きているので CM 出演の件もやって見てよかったなと。

普段あまり接点がない社の人と話ができたりもあったのでよかった。

公開日の午前中に友達に発見されて LINE で晒されたのでインターネットは凄いなって思いました。

EKS の pod で mackerel-container-agent を動かして監視する

kubernetes mackerel 開発

はじめに

EKS is これ

で最近 EKS を触ってアレコレしてるんだけどそのアレコレの一つで mackerel-container-agent 導入してメトリクスを収集するというのがあった。

僕が所属している GMO ペパボでは mackerel をかなり使っていて mackerel 上で一括して見られると便利なので入れた。

EKS なら CloudWatch とかでも取れるのかもしれないけれど、僕がやっている minne というサービスは OpenStack と AWS のハイブリッドなので mackerel に集約されるのが便利なのでした。

導入する

だいたい下記に書いてある。

mackerel.io

上記のマニフェスト例にあるように下記のような yaml を用意する

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  serviceAccouontName: sample-serviceaccount
  containers:
  # ...
  - name: mackerel-container-agent
    image: mackerel/mackerel-container-agent:latest
    imagePullPolicy: Always
    resources:
      limits:
        memory: 128Mi
    env:
      - name: MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT
        value: "0"
      - name: MACKEREL_CONTAINER_PLATFORM
        value: kubernetes
      - name: MACKEREL_APIKEY
        value: <Mackerel APIKey>
      - name: MACKEREL_KUBERNETES_KUBELET_HOST
        valueFrom:
          fieldRef:
            fieldPath: status.hostIP
      - name: MACKEREL_KUBERNETES_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: MACKEREL_KUBERNETES_POD_NAME
        valueFrom:
         fieldRef:
            fieldPath: metadata.name

EKS で ここ に書いてある AMI を使用すると --read-only-port が無効な状態になっているので MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT を指定する必要がある。(他にも --read-only-port を有効にして AMI を作成することも可能で https://github.com/awslabs/amazon-eks-ami の issue を漁れば方法がわかるかと)


また、後述する serviceAccountName も設定しておく。

次に RBAC を設定する。
mackerel の document の RBACの設定例をそのまま適応した後に下記の ServiceAccount の yaml を作成し apply する

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sample-serviceaccount

これで監視ができるようになります。

最後に

RBAC も MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT の指定もしてるのにうまく動かんので EKS に対応してないのか？と思い twitter で呟いたところ中の人から助言を頂き感謝です。



結局 deployment で serviceAccouontName を指定してなかっただけっていう落ちだったのですが...

犬をお迎えして 2 年経った

はじめに

2017/04/14 にお迎えして 2 年も経ってしまった。
4 ヶ月経って書いた以前の記事は下記

shiro-16.hatenablog.com


今でも、金曜日に有給とって空港までお迎えに行って、飛行機が遅れてて空港でワクワクしながら時間潰してたことや
その後にリムジンバスで渋谷に向かってる最中とかを鮮明に覚えてる。

何よりこの 2 年間毎日可愛いって思ってるのでヤバい。
散歩も週 3 ~ 5 回行ってるけど毎回楽しいのでヤバい。

一時期診察してもらったら先天性の病気かも？となった時もあったけど結果病気ではないとなったので幸いずっと元気で過ごしている。
今回もこの 2 年でわかったお金について知見を書いて行きます。

費用

前回の記事でもまとめましたがその後にかかった費用などを誰かの参考にまとめておきます。

まずは我が子のスペック

1 年単位でどのくらいかかるか？という感じでまとめて行きます。

食費(メイン)
  • ドックフード 2 種各 3kg 6000 円

2 種類にしているのはその方が毛並みがよくなった気がするので 2 種類を合わせて食べさせています。
この計 6kg のドックフードを 4 ヶ月で食べきるので一年だと

6000(円) / 4(ヶ月) * 12(ヶ月) = 18000 円

が 1 年でかかっています。

その他の食費(おやつ)
  • 1000(円) * 12(ヶ月) = 12000 円

おやつ代は完全に飼い主によってどの程度あげるか？が決まるので参考にならないと思いますが我が家では(たぶん)このくらい

トイレシート

800枚入りのペットシート一年半前に買ったのですが、未だに半分以上残っているという状況なので一年で半分消費したということにします。

  • 4000(円) / 2 = 2000(円)
病院代

ここ半年くらいは具合が悪くなったりも全くないので定期的に病院にいくとかはないので、必ずかかる費用のみを出します。
これは完全にお薬のみの価格なので診察料などが別途かかると思います。(1000 円くらい？)

まずは混合ワクチン(1 歳からは年 1 回)

  • 約 10000(円)

次に狂犬病ワクチン

  • 約 4000(円)

フィラリア予防薬(4 ~ 12 月くらいまで月 1 回)

  • 約 1000(円) * 9 = 9000(円)

フィラリア検査(年一回)

  • 約 3000(円)

ノミ/マダニ予防薬(4 ~ 10 月くらいまで 3 ヶ月に 1 回)

  • 約 3000(円) * 3 = 9000(円)

ということで病院代は合計で下記のようになります。

  • 10000 + 4000 + 9000 + 3000 + 9000 = 35000(円)
おもちゃ代

これもおやつ代と同じで完全に飼い主によってどの程度あげるか？が決まるので参考にならないと思いますが我が家では(たぶん) 1 年でこのくらい

  • 5000(円)
合計
  • 18000 + 12000 + 2000 + 35000 + 5000 = 72000(円)

だいたい我が家はこんな感じになっているようです。
病院代に関して上でも書きましたが診察料などは含まれていませんので実際はもう少しかかりそうです。
また、 1 年目は不妊手術などもあり 10000 円くらい(？)はかかるかと思います。

洋服とかを着せたりする人はもう少しかかるかもしれません(うちでは着せてないのでよくわからない)

その他にどうしても旅行や出張などで犬を預けないといけない場合はペットホテル代がかかって来ます。
我が家では一泊約 4000 円のホテルを利用しています。


こんな感じの費用が毎年かかります。まとめてみると意外にかかってるんだなというのがわかりました。
犬の大きさによって食費や薬代等は割高になってくるでしょう。

最後に

なにかで犬は 12 ~ 15 年くらいしか生きられないつまりは人間の 1/6 しか生きられないということで、人間の 6 倍速で一生が過ぎていくというのを見たんだけど
つまり僕が 1 時間遊んであげたら人間換算で 6 時間遊んだと同じくらいの楽しさを犬は得られるのでは？という考えになって少しの時間を割いて遊んであげても全然苦ではないなと思うようになった。(思うようになったと言っても元々苦には思っていなかったのだが)

家の壁紙を剥がされたりもしたけど、犬と生活するのは楽しいよ

ということで我が子の写真が大量にあるリンク貼っときますね
www.instagram.com

Cloud Native Meetup Tokyo #7 で登壇して来た

開発 プログラミング ツール kubernetes Telepresence

Cloud Native Meetup Tokyo とは

cloudnative.connpass.com

Cloud Native に近しい技術や CNCF がホストするプロジェクトについて共有し合う会です！

昨今はコンテナ関係のエコシステムが大量に増えてきましたが、それらの技術検証結果などを発表しあう?場として利用していきたいと思っており、仲間を募集しております。

CNCF の公式meetupに認定されました

とのこと

登壇経緯

f:id:shiro-16:20190401123821p:plain

と発言したら社で Cloud Native Meetup Tokyo の運営の手伝いをしている r_takaishi (@r_takaishi) | Twitter から下記のような誘いがあり


f:id:shiro-16:20190401123827p:plain

となった
この間約 4 分

会場

会場は前職の新オフィスの Abema Towers だったので初潜入して来た。
エレベータ乗ってたらレスラーとカメラマンが乗って来て

  • これは AbemaTV の撮影だろうな
  • 話題のラグビーっぽいな

という二つの感想が出て来てなんか大変そうって思いました。
新しいビルは綺麗だったな〜というのと 200 人以上はいる広いセミナールームはやはり良いな〜という感じ

登壇内容

speakerdeck.com

Telepresence という k8s 環境ではかなり便利なツールのお話
日本語の資料や記事がほとんどなくだいたい公式とソース読んで検証してたのでそれで得た知見を書いた。

内容は資料を読んでもらえればという感じ

とりあえず試したい人は下記のリポジトリとかで試せるようになっているはず
github.com

その他の内容

社で一緒に k8s への移行をやってるアルパカさんの内容
移行時の平行運用期は consul 連携できるのマジで便利なんですよ。

docker image 配布に関しての問題を解決する色々なツール群のお話
image size を小さくする以外のも確かにいろんなやり方あるよな〜と勉強になった。

最後に

楽しかった！！１

Rails Girls Tokyo 10th でコーチして来たお話 #railsgirlstokyo

雑談 開発 プログラミング rails

はじめに

なんでコーチやったのとかは下記を参照

shiro-16.hatenablog.com

上記の記事が初コーチの回でそれから 5 回ほどコーチをやっているので進め方とか気づきを書いておこうという気持ち

気づき

人数のお話

基本的には複数のチームに別れてワークショップが進行していきます。

  • チームの人数はコーチ/Girls合わせて最大で 10 人くらい
  • コーチ対Girls の比率は 1:2 もしくは 1:1 になるように調整されている

僕は過去 5 回で前回だけ 1:1 であとは基本 1:2 だったのですが、前回 1:1 を初めて体験した感想は圧倒的に楽というものでした。
1:2 の時は終わった後に疲れきってもうダメだ〜という感じでしたが 1:1 の時は 1:1 はこんなに楽だったのか〜という感想

最近だとそういうコーチへの負担も加味してか 1:1 になるようにコーチの人数が多くなっている気がするので良いことだと思います。

進行のお話

やる内容は Rails Girls - Japanese に沿ってやっていくのだけれど、進め方は割とチームによってバラバラになります。

大きく分けて 2 パターンあって

  • チームで一緒に進んでいく
  • 個々人が自分のスピードで進んでいく

これは良し悪しがあるかなと思っていて僕が考えるメリット/デメリットはこんな感じ

チームで一緒に進める

メリット

  • Girls 同士のコミュニケーションが取りやすい
  • チーム間が出る

一緒に進めているので Girls 同士のコミュニケーションとかもしやすくなってチーム間出るのかな？と思う(勝手な想像)

デメリット

  • 誰かが少し遅れると心理的に良くない

進めている中で誰かが詰まったりしてしまうと、その人を待つことになるのですがその場合その人は焦りが生まれてしまうだろうなと
その日にあったばかりのチームのメンバーに待ってもらうという状況は待たせている側からするとプレッシャーを感じてしまったりすると思われる。

遅れている人は誰かコーチがつきっきりで対応し、チームは先に進むという選択をしてもそれはそれでプレッシャーになるだろうな〜という気持ち

  • 質問がしづらい

学校の授業で手をあげれない人がいるようにみんなに注目されている中で話せない人もいるんでは？とか
こんな質問していいんだろうか？みたいな気持ちになることがあるかもしれない

個々人が自分のスピードで進んでいく

完全にチームで一緒に進めるの対比になるのですが

メリット

  • 個々人で進めるので他人の進捗がそこまで気にならない

他人の進捗は多少は気になるでしょうが、自分が遅れているから誰かを待たせているという感じにはならないのでプレッシャーを感じることは少なくなりそう

  • 質問しやすい

1:1 なら全員の前で何かを聞くという感じにはならないので質問しやすいのでは？

  • 理解できたかどうか？を判断しやすい

これは完全にコーチ目線なのですが、チームで一緒に進める場合は進行役の人がいてその人が説明するのですがその説明が理解できているかどうか？という反応を Girls 全員分把握するのが大変というか無理。普段から大人数に技術のことを教えている訳ではないのでそんなスキルは持ってないんですよ...
1:1 であれば相手の反応によって理解できたか？できなかったか？というのは割と会話から察することが可能だったりするので、察してもう少しわかりやすい言葉を選んで説明を行うという深堀ができると思っています。

僕としてはせっかくエンジニアに興味があって参加してくれたので、よくわからんかったのでエンジニアとか無理〜となって欲しくはないので理解できて楽しかったので次に繋げようと思って帰ってほしい。

デメリット

  • Girls 同士のコミュニケーションが取りにくい

個々人でが〜と進めているのでコミュニケーションは取りにくいのかな？(という想像)

  • チーム間が出ない

個々人で進めるのでチーム感があるのは自己紹介やお昼ご飯とか休憩の雑談くらいですね

最後に

という感じで過去 5 回くらいで感じたことをだらだら書いてみた。
僕個人としては個々人が 1:1 ないし 1:2 の状態で進めていく方が Girls がちゃんと理解できているか？というフィードバックを得られ自分自身のちゃんと教えられたという満足感も得られるので良いなと思いました。

過去 5 回で総じて感じるのは未経験、特に仕事でもエンジニアと接点がない人に技術的な説明をするのは大変で普段当たり前のように使っている言葉をそういう人たちにわかるように言語化するというのは説明することに対してしっかりとした理解が無いと出来ないのでコーチの人々は偉いな〜と思っています。
僕は(Girls の方がどう思っていたかは定かでは無いですが)前回でやっとちゃんと教えられた〜と納得いく説明ができるようになったなと感じました。(その後のアフターパーティの途中からひたすら障害対応をしてたのでやりきった感が 0 になってしまったという辛い思い出もありますが...)

あくまでメリット/デメリットとかは僕が Girls の立場だったら〜という想像でしかないので実際はわかりませんよ