日々のこと

まいにちの暮らしをつれづれ書きます

TokyoGirls.rb Meetup vol.2に行ってきた！（前編）

勉強会 すきなこと おでかけ

女性も参加しやすい、けど女性限定ではないRuby勉強会、
TokyoGirls.rb Meetup vol.2へ行ってきました。

まだ余韻が残ってます。
とてもいいイベントでした。

イベントのツイートまとめはこちら👇 togetter.com

スライドまとめはこちら👇 blog.jnito.com

わたしは保育園へ通ってるこどもがいて
平日はこうした勉強会になかなか参加しづらいので
勉強会の参加は2回目くらい。
（デブサミなどは何度か参加しているのですが）

週末の昼間の時間開催、託児所がついている安心感。
この日はこどもは夫と過ごしてたので、託児所は利用しなかったのですが
託児所が用意されていることで、こどもがいても参加していいんだ（ここにいていいんだ）というような
安心感につながるな、と思っています。

夫もエンジニアをしているので、勉強会の参加に関してはお互い行きたい会に行けるようにという雰囲気なので協力的。
前職、SIerに勤めてたときは、時間や心の余裕がなくて勉強会にもなかなか行けなかったけれど
今年転職してからは、勉強会、むしろ行かなきゃ行きたい、という気持ちになってます。

場所は六本木のSmartHRさんのイベントスペース。
広々として開放的な、とてもきれいな会場でした。

受付すると、名札に貼るツイッターアイコンのシールが用意されてました。
普段、ツイッターアイコンで目にしている人がわかるのでとても良い。。。
こういう心づかいに満ちたイベントでした。

オープニング / 伊藤淳一 さん

RubyやRailsで困ったことがあると、Qiitaの記事などでお世話になっている伊藤さんのお話。
チェリー本も読んでお世話になりました。

ここ数日話題になっていますが、アンチハラスメントポリシーの話も。
こちらにまとまっています。 隣に座ってる人が笑顔で帰ることができるように。

名札のデザインは、会場提供のスポンサーのSmartHRのデザイナーさんだそう。
素敵なデザインでした。

Ruby on Rails 最初の一歩 / ただあき さん

Classiさんで新人研修などに関わっているただあきさんのお話。 プログラミングをはじめたばかりの方や、そのフォローに関わる人に向けて Ruby / Railsの最初の一歩についてのセッション。

最後の方のプログラミングをはじめたばかりの人へのメッセージで、「焦らなくても大丈夫」がやさしくて、心に残りました。

Classiさんは、学校の先生、生徒、保護者向けのアプリをつくっていて、２校に１校は使ってるとのこと。（すごい）
Classi Rails Nightを定期開催されてるようで、行ってみたいです。
https://techplay.jp/event/759134

教えるときに大切にしていること

  • プログラミングたのしい！
  • コンピュータおもしろい！
  • チーム開発よい！

Ruby Rails関連ドキュメントの歩き方

ググる前に、公式ドキュメント見てみよう

Ruby 公式ドキュメント

  • ここから、使っているRubyのバージョンを選ぶ
  • 自分が今「なんのオブジェクトを触っているのか」という意識
  • エイリアスを知れたり、新しい発見があったり
  • それっぽいメソッドを見つけられないときは、Google検索して最後に逆引き的に公式ドキュメントを確認するとよい（これ、よくやってるかも！）

Railsガイド

railsguides.jp

  • 例えば、スコープはクラスメソッドであり、引数取るときはクラスメソッドとして書く書き方を推奨してる、とか

Rails APIドキュメント

  • なぜこう書くの？の根拠になる（考えて書くための手助け）
  • レビュアのとき、これらのサイトを参照先として貼るようにしてる（良さそう！）

Ruby / Railsのたのしいデバッグ方法

  • ログはヒントの宝庫！（英語だけどちゃんと読もう）
  • irb / rails console

  • エラー画面の下の方に、黒いスペースでインスタンスや変数の状態を確認できる（使ったことなかった！） f:id:nobu09:20191222145604p:plain

  • pry-byebug（gem）

    • binding.pryでステップ実行できる
  • inspect
    • 雑にログ出力
  • Rubymineやテストコードを使ったり

レビュアーに優しいPRの出し方

この4つは書いてもらう！（特に上の2つ！）

  1. やりたいこと
  2. 対応したこと/していないこと
  3. 画面のキャプチャ
  4. 動作確認に必要な手順

補足を書く

  • 特に見て欲しいところ、悩んだところはピンポイントでコメント
  • githubでピンポイントでその行にコメントつけていく

適当な分量で出す

  • PRのサイズは機能が大きすぎるときは分割
  • そのとき、対応したこと/していないことを明記する

いい感じのコミット

  • コミット単位でも見たいときがある
  • コミット粒度やコミットメッセージをちゃんと書く

レビュアするとき

  • なぜ？という意図の確認
  • 修正した方がいい根拠があればそのソースを示す（URLを貼る）
  • コードレビューもコミュニケーションなので、丁寧に進めていけるといい

プログラミングをはじめたばかりの方へ

悩んだとき、誰かに相談したり、気分転換したり、焦らなくても大丈夫
ゆっくりでも一歩ずつでも進んでいけたらすてき
プログラミング楽しいという気持ちを持ち続けていけたら

質問

  • レビュー時のコミュニケーションについて
    • ぎすぎすしないために、語尾柔らかく、押し付けないように書くように心がけている
    • 絵文字使ったり
    • 日ごろから話して、ぎすぎすしないように心がけている

事業知識を深掘りし、より人の役に立つサービスに改善する / Kubota Nao さん

大阪の住宅ローンのWebサービスの会社（株式会社エイチームフィナジー）でエンジニアされてるKubotaさんのお話。
ナビナビ住宅ローンという、Ruby on Railsで開発されているサービス。 バンドでドラムをされてるらしく、わたしもドラム担当なので勝手に親近感をもちました。

事業知識について、自分のことを言うと、わたしは転職して5ヶ月で、まだわからないことが多いので
よいサービスを作るためには、必要だなあと思うことしきりでした。

なぜ事業知識を深掘りすることに？

  • 前職では客先常駐エンジニアとして勤務
  • よりサービスの開発に深く関わりたいと思い現職に
  • サービスの根本的な仕様、よりよい機能を開発するにはどうすればいいか
  • 事業知識の深掘りを進めていくことで貢献できることを増やす

どのように変化していったか

  • 最初は住宅ローンなど、それぞれの言葉の意味も分かってない
  • Webマーケティング、SEOの知識もない状態

  • すぐにサービスについて理解するのが難しい状態

  • 理解をしないでDB設計してしまうことで、要望（仕様）に沿ったデータを提供できない

  • データの加工のための処理で複雑に

実際に起きた問題

  • 専門用語の変数名の命名がうまくまとまらず何を指しているかわからない
    • rate_typeに金利タイプと借入タイプが入っている事象が複数箇所で発生
  • 柔軟な表示出し分けができず、サービスの商品名がついたメソッドが生まれる
  • 内部的な設計が複雑すぎる

このままではこのサービスを負の遺産の塊にしてしまう、住宅ローンについて学ぶ！

  • 現実のサービスの状態を適切にデータを扱えていれば

    • 要望（仕様）に沿ったデータの提供ができる
    • ソースコードも簡潔に

  • 今まで書いてきたコードが泥沼に見えるようになった

事業知識を深掘りして変わったこと

  • より質の良いサービス改善案を提案できる
  • チーム内のコミュニケーションコストが少なくなる、円滑なコミュニケーション
  • より綺麗なコードがかける

サービスの品質向上

事業知識の深掘りを行う上で意識していること

  • 散らばった情報の要素を整理する
  • 言葉に疑問をもち、意味を調べる
    • 業界での意味のニュアンスが違うこともある
  • チーム内で共通言語を揃える
    • チーム内のコミュニケーションから質の良いサービスが生まれる

深い事業知識に踏み込めば、別の視点からより良いサービスに改善していくこともできる

このイベントについて、ほかの方のセッションなど、書きたいことまだまだあるのですが、一旦ブログ、前編としてここまでで更新します。
続けて書いていこうと思います！