まっしろけっけ

めもてきなやーつ

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

はじめに

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

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 の立場だったら〜という想像でしかないので実際はわかりませんよ

第25回Elasticsearch勉強会「検索編」 #elasticsearchjp に登壇した話

はじめに

www.meetup.com

こちらのイベント

こんな適当なことをつぶやいたら Elastic 社の @johtani さんからお誘いがあって登壇する流れとなったのでした。

Elasticsearch 勉強会はスライドでも触れている solr から Elasticsearch に移行した前後で 2,3 回くらい参加したことがあったという感じ

資料はこちら

speakerdeck.com

発表者は 3 人だったのだけれど Elasticsearch で検索ということだから話す内容被らんかな...と心配だったのだけれど、全員いい感じに内容が違っていてよかった。

twitter でも盛り上がっていたようで、発表後の質問も懇親会での質問もいっぱい貰えたのでよかったよかったという感じになった。

最後に

僕は現在は検索のことに関してアレコレやっている訳ではなく、
最近は資料にある辞書管理のシステムを作ってくれた若者が頑張っているので次はその若者がなんか喋ってくれるはずです

1on1 をやってる(やる)話

はじめに

minne では CTL と各エンジニアで 1on1 を月一でやってるんですが僕は少し前まで web 側の CTL をやっていたので web アプリケーションの開発を行うソフトウェアエンジニアの各位と 1on1 やっていたんですよ。

で下記のような事件があったんで web 側とかなくなってただの CTL として生き始めたのでモバイルエンジニアとの 1on1 もやり始めるぞい < イマココ

hisaichi5518.hatenablog.jp

1on1 の目的とか

だいたい下記のスライドに書いてあって新しく入社した人にも下記のスライドがやる目的です〜って共有している(ひさいちくん便利)

speakerdeck.com

これからの話

モバイルエンジニアの人々はひさいちくんと 1on1 をやっていたのでモバイルエンジニアの各位が将来に対してどんなビジョンを描いているか?とか細かいことは知らないのでとりあえず教えて貰いたいなと思って下記のような文章を用意した。


モバイルエンジニアの人々(mataku 以外)は shiro16 と 1on1 をするのは初になります。
1on1 によって皆さんがエンジニアとして成長するための手助けをしたいと考えているので、まずは皆さんがどのような目標を持っているのか?を教えて貰いたいと思います。

1on1 ではその目標に最短で辿り着くために今抱えている課題に対してどうアプローチすればいいか?という内省が出来るようにサポートできればと考えています。

【質問】(短期的/長期的どちらでも)エンジニアとしてどうなりたいか明確なビジョンがある場合はそのビジョンを明確ではない場合はざっくりとしたビジョンでもいいので書いてください

例1) shiro16 倒す
例2) シニアになる
例3) なんかよくわからんけどとりあえず凄くなる
その他...

モバイルエンジニア向けの文章になっているけど、web の人々も同じようなことをもう一度問う予定

なぜこのようなやり方をやろうと思ったか?

ペパボにはエンジニア職位制度というものがあり上位の職位には誰でも立候補が出来たりするんですが、ちょうどその時期でシニアエンジニアとして相応しいかどうか?は CTL みんなと面談して決めると言うことになっておりその面談を通して思うことがあってという感じ。

思うことというのは 1on1 をやっている中でエンジニアとして明確な目標を持って 1on1 に望む人はその目標に近づくためにどうすべきか?ということに悩んでいたりするんだけれど、僕が少しサポートをするだけでこんなに変わるのかと思うくらい振る舞いがとてもよくなったという経験があったのでビジョンを持ってそこを目指してもらおうと思った。

ぼんやりとしたビジョンしかないという人に関しては 1on1 を通してぼんやりとしたビジョンをより明確にするサポートをしていければと思っている

最後に

1on1 の話とは関係ないんだけど僕自身も上の職位を目指す上で現シニアプリンシパルの人々とは専門とする領域が違っていてその領域が好きだからもっとやっていきたいと思っているのだけれど、
その領域の違いの明確な言語化とその上でその違いを伸ばす努力をせんとな〜といい刺激を受けた期間だった。

GW にやったことをメモ

はじめに

だいたい大型連休は "どこか出かけるか〜?" となった後に "連休で混んでるときにわざわざ出かける意味とは...?" となって結局出かけないというとこに着地する。

で、何をやっているか?というと下記な感じになる。

  • ジム行く
  • 可愛い愛犬の散歩行く
  • 可愛い愛犬とゴロゴロする
  • 技術書読む
  • ゲームをする

だいたい技術書読んで飽きたらゲームして疲れたら技術書読んで〜をループして合間に他のことをする感じで生活していた

今回の GW にどんな技術書を呼んだか?をメモっておくだけの記事

読んだ技術書

プログラマのためのDocker教科書 第2版

プログラマのためのDocker教科書 第2版 インフラの基礎知識&コードによる環境構築の自動化

プログラマのためのDocker教科書 第2版 インフラの基礎知識&コードによる環境構築の自動化

GW 前半に読んだのがコレ

完全に雰囲気で Docker を使っていたので、ちゃんと学んでみるか〜となって読んで見た。
読んでみたのだが雰囲気で使ってたことがほぼ当たってたのでfmfmと確認になったという結果になったが自分の使い方が間違ってなかったのだなぁとなってよかった。

最後に kubernetes のざっくりとした説明が載っていてそこはこのあと読んだ本のこともあり為になった。
Docker 良くわからんという人にはとてもオススメだと思う。

入門 Kubernetes

入門 Kubernetes

入門 Kubernetes

GW 後半に読んだのがコレ

最近話題の k8s についてマイクロサービスとの相性も良いとのことなのと社でも k8s 使って何かが行われようとしているっぽい雰囲気なので触っておこうという感じで読んだ。

minikube を使って環境作ってひたすら yaml を書き kubectl を駆使してアレコレした。
ちょうど今マイクロサービス化を進める上でめんどくさいなぁと感じていた部分の大半が k8s 使えばいい感じになるんじゃね?という感じに思えてきたので、早く導入したい!!1という気持ちになった。
書の中には若干不親切では?という箇所がいくつかあったのが気になったが k8s を理解するにはとても良いのでは?

エンジニアリング組織論への招待

入門 Kubernetes 読み終わった後に読み始めた。

なんかいいらしいとの噂を聞いていたので買っていたけど積んでたやつ

まだ読了してないので感想は特になしという感じ

最後に

今回は珍しく映画でも見に行くか〜と予約せずに渋谷に TOHO まで歩いたもののダルいなってなって昼飯だけ食べて帰ってくるという事件があった。

Rails Developers Meetup 2018: Day 2 で minne での CM 対応でのハイブリッドクラウド運用という話をした。 #railsdm

はじめに

Rails Developers Meetup 2018 こちらのイベントの登壇のお誘いが @kenchan があり話すということが決まったのが昨年の末とかだった記憶

話す内容を考えていたのだけれど、Elasticsearch 周りの話とかオンラインで全テーブルの DB の文字コードを変えた話とかその他色々考えたんだけど、被りそうなのと 30 分枠だと長すぎるか〜という感じだったのであまり聞いたことがなくちょうど年末くらいにやっていたハイブリッドクラウドを絡めた CM 対応の話をするか〜となった。

資料はこちら

speakerdeck.com

Rails のコード 3 行しかないので Rails Developers Meetup #とは となるような内容で、自分が主に担当した部分を多めに事例を紹介しました。
もう少し流れがスムーズになるように資料作れればよかったな〜というのと途中にちょっとしたトラブルがありアレだったという反省

AWS + Nyah 環境というのは社内でも珍しい構成でツラみとかもあるので気になる人はなんか聞いてください。

最後に

次喋る機会があるならちゃんと Rails の話をしたいね!

資料には含めなかったアレです。
pepabo.com

GraphQL の spec に関してアレコレ考えている

はじめに

最近 GraphQL を本格的に使い始めるぞいとなってんですよ。
経緯は下記参照

それでいくつか filed とか定義してデータ取れるようにしつつ rspec で test 書いててう〜むとなったので自分の考えをまとめて世の知見を知りたいとなったという経緯

前提

環境はこんな感じ

  • Rails なアプリケーション
  • graphql-ruby
  • graphql-batch
  • graphql-guard

その1 request spec は書く必要ないのでは?

実際に呼ばれるのは HogeSchema.execute なので request spec では GraphQL API に対して execute に渡される引数周りのチェックをすれば良いと考えた。
expect(HogeSchema).to receive(:execute).with(hoge, hoge, hoge) くらいを引数のパターン分あると良さそう。

何故ならば実際のクエリ書いてテストしていくとネストの深い巨大なクエリが出来上がって、
そのクエリの検証も辛いしレスポンスの json の検証もネストが深くなり辛いということになると考えたから。

実際に 4 種類ほどのデータ取れるようにしただけで辛いなって気持ちになったのでこの考えに至った。
ではどういうことをテストすれば安心を得られるだろうか?と考えた結果がその 2,3 になる

その2 GraphQL::ObjectType 毎に spec を書いていく

GraphQL で大事なのはそれぞれの GraphQL::ObjectType で定義された各スキーマ要素をチェックしていくと良さそう

どんな field が定義されているか?をチェックする。
PostType = GraphQL::ObjectType.define do
  name "Post"
  description "A blog post"
  field :id, !types.ID
  field :title, !types.String
  field :body, !types.String do
    guard ->(obj, args, ctx) { ... }
    resolve ->(obj, args, ctx) { ... }
  end
end

上記のような PostType があった場合は下記のようにチェックする。

describe PostType do
  subject { described_class.fields.keys }
  it { is_expected.to eq(["id", "title", "body"])
end

この他にも field 毎の型定義も想定した通りになっているかチェックしておきたい。
Ruby とかやってると型とかそんなに気にしないかもしれないけれど静的型付け言語がこの API を使うとなった場合はいい加減な型定義は出来ないのでちゃんとしておきたいという気持ち。

しかし一個一個書いていくのもダルいなと感じ他ので db のカラムのデータ型がそのまま field になっている場合が多いと考えるとある程度自動でチェックする仕組みは用意できそうなのでは?と考えたのでちょっとゴニョゴニョしようかなと考えている
db 以外の field はちゃんと個別チェックする。

graphql-guard の設定が正しいかをチェックする

これは README に書いてあるのだけれど下記のように呼び出せるので返り値を適切にチェックすると良さそう。

describe PostType do
  it do
    body = PostType.field_with_guard('body')
    expect(body.guard(obj, args, ctx)).to be_truthy
  end
resolve もチェックする

これも上記と同じようにチェックできる

describe PostType do
  it do
    expect(PostType.fields["body_url"].resolve(obj, args, ctx)).to eq("...")
  end

しかしこの方法だと resolve 内で graphql-batch の loader を使ってる場合にエラーが出るんでどうしたら...というのが悩み

その3 実際のクエリ書いてチェックする必要ってある?

その1 とも被る内容なのですが、その2 の spec をしっかり書いていれば schema の定義はしっかりと出来ているわけでその状態でデータ上手く取れない〜となった場合はクエリが悪いのだろうということになると考えられるからです。

それでも心配なら全スキーマを取ってくるクエリ書いてエラーでないねっていう程度はいいかもしれん(けど、factory bot でデータを用意するのすらだるい)

でも個別(field 毎)のエラーのチェックはクエリ投げないとダメなんかな〜という感じだが現状エラーが出るようなパターンを書いてないのでなんとも言えない

最後に

まだ本格的に使い始めて3,4日程度なのと通常の query のみで mutation に関しては全くという感じなので上に書いた考えは変わってくるかもしれない。

ペパボ社内で他に GraphQL を使っているサービスがあったので、どういう方針なんって聞きにいくついでに今の考えまとめようと思って雑に gist 書き出したらこういう考えに至った。
でそれを共有したらこんなこと考えてたんですよ〜とやまちゃんがナイスなブログを書いてくれて優秀な若者便利!!1となった

blog.kymmt.com

続:社内のテックミーティングでマイクロサービスの基本的なことについて喋った

はじめに

下記の記事で基本的なことを非エンジニアにもわかりやすく喋った。
で、次は下記の資料の課題をどうやって技術的に解決していくの?という部分を説明しなければいけなかったのでサラッと資料で説明したという経緯

shiro-16.hatenablog.com
× モノシリック
◯ モノリシック

資料

speakerdeck.com

具体的にこれ使うというのは記述してるけどその説明は口頭で説明したり、参考のページを紹介したりなどした。
あとは実際に導入するときに pull request にアレコレ書くのでそんな感じにした。

最後に

喋ったのは一週間くらい前なのだけれど slideshare に uploade できないマンと化してしまって...となっていたのでアップが遅れた。
もう speakerdeck にしよと思い立ったのでピッとアップしたという感じ