Omotesando.rb#93に参加しました！

イベント

1月11日にOmotesando.rb #93に参加しました！
【オフライン開催】Omotesando.rb #93 - connpass
前回が初めてで今回は2回目の参加でした！
参加しての感想＆自分で調べたことを記録しています。
間違い等ありましたらコメントいただけたら幸いです。

会場提供：wantedly様　Oshiumiさん

選考前と入社後のプロダクトを作っている。
システムの多くはRuby、サービスによってGo、Pythonも。
元々がRailsができている。
Wantedly Engineering Handbook - Wantedly Engineering Handbook
エンジニアを積極採用中とのことでした！

リサさん

「N+1問題が起こる原因について調べてみた」

smallmoneky.hatenablog.com


自分もよくN+1問題対策を忘れて引っかかっていた部分でした。
最近Railsから離れていてちょっと忘れかけている部分だったので、また調べて思い出さないとなと思いました。
Active StorageのN+1問題を解決する - 時々とおまわり
Active StorageのN+1問題を解決する #Ruby - Qiita

each文がN+1を引き起こす原因なのではなく、each文の中で、articleに紐づいている、userのデータを毎回取得しにいっていることが原因

自分の予想、過程、結果ととてもわかりやすいLTで、堂々と発表されていてかっこよかったです！
自分もわからないを放置しないようにして、自問自答しながら理解していきたいなと思いました。

神速さん

「LTの敷居を下げる」


「話すネタがない」のところの、

Ruby関連で新しく覚えた何かを話すくらいの気持ちで良い

というのが印象的でした！
「Omotesando.rbに初めて参加した人、Rubyを使い始めて3年未満の人は手をあげて〜」と声がかかると、
自分含めたけっこうな人数の人が手をあげていて、
「Omotesando.rbに初めて参加する人も多いし、RubyやRailsの経験が浅い人も多いから、LTもそんな難しく考えなくて良い」とおっしゃっていました。
「みなさん全員Rubyをずっとやってきているベテランの方々ばかりなんだ」と勝手にイメージしていたので、ちょっとだけLTが身近に感じられるようになりました！

そして最後に教えてくださったメソッドは、私はmapしか知らなかったので、勉強になりました！
flat_map：Enumerable#collect_concat (Ruby 3.3 リファレンスマニュアル)
filter_map：Enumerable#filter_map (Ruby 3.3 リファレンスマニュアル)

まいむさん

「Rubyメソッドの勉強 紆余曲折」


勉強してもすぐに忘れる…

めちゃくちゃ共感しました！
こないだ見たはずなのに「なんだっけ…？」みたいなのが頻発しているので、まいむさんのLTはとても参考になりました！

  1. Rubyメソッドの暗記カードを作成

  2. AtCoderの問題を解く

  3. 資格試験を受ける(RubySilver)

  4. ドキュメントを読み込む

私はどれもやったことがないのですが、
みなさんこうやって試行錯誤して努力されてスキルアップしているんだなと思ったので、
自分もなにか工夫してやってみようと思います！

Hamaさん

「ActiveModel::APIで使用されるゲッター・セッターメソッドについて」


現地では全然ついていけませんでした。
セッターメソッドの方が簡単だったとおっしゃっていたので、自分はセッターメソッドをHamaさんのLTを参考に追ってみることにしました。
------以下自分の勉強過程------

class User
  include ActiveModel::API
  attr_writer :name, :age
end

User.new(name: '太郎', age: 20)
#=> <User:~ @name='太郎', @age=20>

上記ではnewしたときに引数にメソッド名を:で渡すと値が該当するインスタンス変数に入る。
これがなぜ起きているのかを見に行く。
ActiveModel::API
initializeメソッドはActiveModel::APIの中にある。
rails/activemodel/lib/active_model/api.rb at 36c1591bcb5e0ee3084759c7f42a706fe5bb7ca7 · rails/rails
そのなかにassign_attributesメソッドがあるのでその中へ。
rails/activemodel/lib/active_model/attribute_assignment.rb at main · rails/rails
最終的には以下にたどりつく。
rails/activemodel/lib/active_model/attribute_assignment.rb at main · rails/rails

def _assign_attribute(k, v)
        setter = :"#{k}="
        public_send(setter, v)
　　略
end

このkにname、vに'太郎'が入る。
setter = :"name="となりこれがpublic_sendメソッドに送られる。
Object#public_send (Ruby 3.3 リファレンスマニュアル)

オブジェクトの public メソッド name を args を引数にして呼び出し、メソッドの実行結果を返します。
name:文字列かSymbol で指定するメソッド名です。

第一引数にシンボルを入れるとそのメソッド名を呼び出して第二引数をそのメソッドに渡すのでname=メソッドが実行され'太郎'が渡された。
結果newしたときに@name='太郎'となった。
------ここまで------

今回メソッドの中にどんどん潜って見にいくことをしたのは初めてだったので、コードを追っていく過程はとても勉強になりました！
ありがとうございました！
自分にはセッターメソッドの方ですらなかなか難しかったのでゲッターメソッドはいずれ追ってみたいと思います。

kishimaさん

「Now is the time to create your own (m)Ruby computer」


コンピュータを作る実際の手順を説明してくださっていて、とても難しかったですが興味深かったです！
今回はmrubyでアプリケーションを書いたとのことでしたが、mrubyがあまりわかっていなかったので調べました。
チェリー本に以下のようにありました。

Rubyには複数の処理系(複数のRuby実装)があります。公式かつ最もポピュラーな処理系は、C言語で実装されたMRIです。
ほかにも、Javaで実装されたJRubyや、GraalVM上で動作する高速なTruffleRuby、Restで実装されたArtichoke、RubyスクリプトをJavaScriptにコンパイルできるOpal、組み込みシステム向けのmrubyなど、さまざまな処理系があります。

mrubyの特徴としては、以下があるようです。

  • CPUやOSに依存せず、省リソース且つ省メモリでの環境で実行ができる

  • C言語との高い互換性

  • アプリへの組み込みが容易

  • 拡張しやすい
    「mrbgems」を使って自由に拡張できる

mruby 最新情報 | OSSサポートのOpenStandia™【NRI】


Rubyの処理系のことはあまり知らなかったので、今後勉強してみたいなと思いました！
自分オリジナルのコンピュータ、かっこいい…✨

SoraIchigoさん

「テストカバレッジを100%にするということ」


テストカバレッジを使いこなして信頼できるテストを作ろうというLTでした！
自分はまだ学習途中で、テストカバレッジ云々はあまり実感していないところではありますが、
前回のOmotesando.rbでもテストカバレッジのLTがあって、
実務においてテストカバレッジは注目すべき点なんだなと思いました。
そして、テストカバレッジを増やすことを目的にしてはダメで、信頼できるテストを増やすことが大事ということもわかりました。
以下の言葉が印象的でした。

  • 最初にテストを書いておけばテストを書く場所を作れるので自ずと後続の人もテストを書いてくれる

  • 実装と同じくらいテストコードも負債化する
    せっかく書いたテストが将来のテスト追加を阻まないように注意


チーム開発のプラクティスに入ったら、テストもたくさん書くらしいので、良い勉強になるな〜と楽しみにしておこうと思います。

まとめ

今回はFBC生(現役・卒業生)が多くて嬉しかったです！
今後も参加していきたいと思います！
ありがとうございました！

2024.1.15~2024.1.21【週報】

週報

今週の振り返り

目標と成果

目標 成果 現状＆今後
JS非同期処理のプラクティス課題を終わらせる × 本質的なPromiseの部分は大丈夫そうなのであと少し(と勝手に思っている)
Omotesando.rb参加記録のブログ記事を書く △ 6割くらい下書きしてある
SOFTSKILLSの第5部を読み終える ⚪︎ 第6部へ
新春輪読会EXPOの進行に使うスライドを作成する ⚪︎ 👍

他にやったこと

  • 🚂ぱRails輪読会参加
    それに伴い以下を調べた
    ・ActiveStorageのバリデーションでcontent_typeがうまくバリデーションされない問題について
    ・全文検索エンジンについて

  • 🎼リーダブルコード輪読会参加

今週の学習時間

学習時間：28時間
学習日数：6日
新春輪読会EXPOのスライド作成に時間がかかってしまい勉強時間が少なめになってしまいました

今週あった出来事＆感情

  • 大学時代の友人に会った
    みんな変わってるけど変わってなくて、とても楽しく話せました🙌

  • 3年半ぶりに酒を飲んだ
    今年はお酒が飲めるようにしたい🍺

来週の目標

  • JS非同期処理のプラクティス課題を終わらせる

  • Omotesando.rb参加記録のブログ記事を投稿する

  • SOFTSKILLSの第6部を読み終える

来週の予定

  • 新春輪読会EXPO開催！
    楽しく開催できるよう頑張ります〜✨

  • FBCミートアップ

2024.1.8~2024.1.14【週報】

週報

今週の振り返り

目標と成果

目標 成果 今後
JS非同期処理のasync/awaitに着手し
おおまかに完成させる		 △ もう一度Promise化を見直す
SOFTSKILLSの第４部を読み終える ⚪︎ 第５部へ

他にやったこと

  • スタブとモックを調べた
    ぱRails輪読会でスタブとモックの話が出てあまり理解できなかったので結構調べた
    なんとなくの理解はできた気がする

  • Omotesando.rb #93 現地参加
    FBCの受講生・卒業生はもちろん、他の参加者の方とも少しお話しできた！
    前回は緊張してあまり話せなかったので一歩前進🚶

  • 🚂ぱRails輪読会参加
    作ってきたアプリケーションのシステムテスト・コントローラの機能テスト・モデルテスト

  • 🎼リーダブルコード輪読会参加

  • 新春輪読会EXPOの登壇者への連絡

今週の学習時間

学習時間：34時間45分
学習日数：6日

今週あった出来事＆感情

  • Ruby Kaigiの現地参加を決めた！
    初めての現地参加で緊張ですが楽しみ！

  • 髪切った
    頭軽くなって最高！

来週の目標

  • JS非同期処理のプラクティス課題を終わらせる
    要件を満たすように再検討

  • Omotesando.rb参加記録のブログ記事を書く

  • SOFTSKILLSの第5部を読み終える

  • 新春輪読会EXPOの進行に使うスライドを作成する

来週の予定

  • 新春輪読会EXPOのリハ日程を決めて連絡、からの準備

  • 大学時代の友人たちに会う

2024.1.1~2024.1.7【週報】

週報

今週の振り返り

今週の学習時間

19時間15分
学習日数は3日間でした
年始だったので少なめでした

今週あった出来事＆感情

  • いろんな方が宣伝してくださり新春輪読会EXPOの参加者が増え始めた
    嬉しい！参加者が楽しめるように努めよう

  • 実家の親戚たちと1/1~1/2で旅館に一泊、弾丸帰宅
    甥っ子と遊んでとても癒された！姪っ子はまだ人見知りされるけどかわいい

  • 初詣行って数年ぶりに大吉！
    とにかく嬉しかった！

来週の目標

  • JS非同期処理のasync/awaitに着手しおおまかに完成させる
    参考リンクのasync/awaitに関する箇所を読む

  • SOFTSKILLSの第４部を読み終える

来週の予定

  • Omotesando.rb #93 オフライン参加
    FBCの人も結構参加されるみたい…！楽しみ！

  • 新春輪読会EXPOの登壇者への連絡

  • 髪を切る

JavaScriptのimport,export

JavaScript

経緯

minimistを使いたかったが、公式はCommonJSのrequireの書き方だったので
ESモジュールでの書き方を調べた

結論

minimistをESモジュールで読み込むには

import minimistModule from "minimist";

とすればminimistを好きな名前（minimistModule）で使える

詳細

モジュールとは

１つのjsファイルに全部書くと大変なので、機能ごとにjsファイルをわけて書き、
それを読み込んでメインのjsファイルで使う
その分割したjsファイルをモジュールとしている
モジュールの中身は変数や関数などを定義する
１つのファイルの中に複数定義しておくことも可能

読み込む側と読み込まれる側

読み込む側はメインファイル
読み込まれる側はモジュール（機能ごとにわけたjsファイル）
ざっくり書くとこうなる

メインファイル側 モジュール側
CommonJS require module.exports
ESモジュール import export

import,export

import,exportには「名前つき」と「デフォルト」の2種類がそれぞれある

名前つき

モジュールごとに複数の機能（関数や変数など）をexportでき、その中から必要なものを指定してimportすることができる

名前つきexport

export const name = "foo";
export const hello = () => console.log("Hello");

または

const name = "foo";
const hello = () => console.log("Hello");
export { name, hello };

名前つきimport

import { name, hello } from "パス名";
別名をつける

定義した機能名（変数名、関数名など）を別名でexport,importしたいときはas 別名のように書く
後述するデフォルトでも別名はつけられる

export側で別名をつける
export { name as fooName, hello };
import側で別名をつける
import { name, hello as displayHello} from "パス名";
全てをimport
import * as 指定の名前 from "パス名";

とすると指定した名前にモジュールの全てのexportを取得できる
指定の名前.機能名でその機能を使える

デフォルト

モジュールに１つの機能がありそれをデフォルトとして設定している

デフォルトexport

export default function () {
  console.log("Hello!");
}

または

const hello = () => {
  console.log("Hello!");
}
export default hello;

デフォルトimport

import displayHello from "パス名";
console.log(displayHello);
// exportしたhelloモジュールをdisplayHello（好きな名前）として使用

注意

  • 名前つきimportは、指定する機能が１つでも{ }をつけること

  • デフォルトimportなら{ }いらない 　別名をつけるときは{ }が必要

  • 名前つきexportでas defaultとするとデフォルトimportできるが、その際default asで別名をつけてimportする必要がある

  • パス名は 同じディレクトリ内でも./をつけること

  • npmでインストールしたモジュール(node_modules内のモジュール)は、パス名の部分をモジュール名にするだけで参照可能

minimist

minimistのコードも見てみたが難しく断念
ただデフォルトで機能が設定されているようだったので、単純にデフォルトimportでできた

おわりに

完全未経験から現在フィヨルドブートキャンプで学習中。
自分で気になったところの記録（メモ）です。
間違い等あればご指摘いただければ幸いです。

参考リンク

エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」に参加しました！

イベント

12月11日にソニックガーデン主催エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」に参加しました！
エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」
そのときの感想を記録しておきたいと思います。

はじめに

私は現在フィヨルドブートキャンプ（以下FBC）というプログラミングスクールで勉強しています。
FBCではプラクティスという学習工程の中で提出物をメンターさんに見ていただきレビューをもらいます。
私が経験しているレビューは、仕事でのコードレビューと完全に同じではないことをご了承ください。

LT

LTは共感できるポイントが多く、また自分を省みる良いきっかけになりました。
発表してくださったみなさんありがとうございました。
以下LTの感想です。
LTの内容で自分がメモしたところを書いていきます。
自分の感想は色を変えてあります。
途中に入れ込んでしまったので読みにくいですが、あえてそのように書かせていただきました。すみません。

samayou12 さん

「レビュアーとして成長するためには」

  • なぜレビュアーとして成長すべきか
    • チームに貢献できる
      新人のうちはどうしても頼ることが多い
      新人にとってもコードレビューはgiveする手段の１つになる
      giveできていれば頼る時も申し訳なさが減る、自分のためにもなる

→ なるほどなぁと思いました。レビュアーとして成長することが自分のためにもなる、という意味が分かりやすく納得しました。

  • レビュアーとして成長するには：技術書とレビュー
  • 技術書は自分の引き出しを増やす効果が大きい
    ただし背伸びしすぎると効率が悪い
    内容を理解できるが読むのが少し苦しい　くらいがちょうど良い

→ 今自分が参加しているぱRails輪読会はちょうど良いのかなと思えました
（理解できると言いきれるほど理解できているかは微妙ですが）

  • レビューを受ける/読む
  • レビューをもらったらまず意味を理解する、なぜそうなのかを理解したり議論することが大事
    • 新人には難しい…なぜ？
      • レビュアーにとっては当たり前すぎて伝える必要がないと思っている情報がある（可能性がある）
      • そもそも何がわからないのか伝えないとレビュアーは何を教えるべきかわからない
        つまりレビューのコメントは完全なものではなく、時には自分で情報を取りにいく必要がある

→ レビューの意味を理解する必要がある理由や、自分から情報を取りにいく必要性が言語化されていて、「もっと情報を取りにいくようにしよう」と考えさせられました。

  • 最初のうちはリアルタイムでレビューを受けると良い

→ これがよくメンターさんと受講生がやってるペアプロか！と思いました。私は提出物に関するペアプロをやったことがないのですが、直接のほうが意図を聞いたり質問したりしやすく時間もかからずいいなと思いました。またエディタの使い方とか直接的な技術以外のところも教えてもらえるというのは盲点でした。

  • 自分がレビューする時は小さく始めよう、まず一行からわかるところから始める（一行単位のミス的なもの）
    ここがわかりにくい、というコメントも役にたつ。新人でも理解できるコードはみんな理解できるコード

→ 自分はまだコードレビューする側はやったことないけれども、チーム開発になったら最初絶対焦るし一行目から必死に読んで集中力続かずみたいなLTの失敗例通りの展開になるのが目に見えるので、「小さく始める」は覚えておいていざ自分がやるときに意識したいです！

Nobo02149847 さん

「ソニックガーデンジムに参加してコードに対する向き合い方が変わった話」

  • 気になることは質問する

→ 今回１番の共感＆反省ポイントでした！！！
悪い例としてあげられていた、
 レビュアー「ここ修正してください」私「修正しました！」
が最近自分のプラクティスの提出物のレビューでとてもあてはまってしまっていたからです。
レビューの内容をよんで、確かにその通りだなぁと思って修正していますが、それだけでは本当に理解しておらず、他で活かせないことになってしまうので、
「なぜそのレビューを受けたのか、なぜ自分が書いたコードよりもレビューのコードの方が良いのか」をレビュアーに確認し理解することが大事とのことでした。
（私は〇〇の意図でこの実装にしました。こちらの方が適しているのは◎◎が理由でしょうか？、みたいな感じ）
それによって今後も応用が効くとおっしゃってました。
本当にその通りだなと。
最近プラクティスを早く終わらせたい気持ちが出てしまっていて、そのような部分が欠けているなと反省しました。
今後も使える知識にするために、そして就職後もレビューからたくさん学べるように、いまのうちにレビューに対する姿勢を正しておこうと思いました！

→ 私がFBC内の日報に上記を書いたところ、「自分も気をつけます」とのコメントを複数いただきました！他の受講生の方も共感するポイントだったようでした。

  • コードレビューが怖くなくなった。むしろコードレビューがないと怖い。

→ 早く終わらせたいと書いた先ほどの感想と矛盾しますが、これも共感しました。笑

yatsuhashi168 さん

「コードレビューを受ける新人の心構えと準備」
レビュイーもできることがある

  • 準備：同じレビューをされない、自分以外のレビューを見る
  • 同じレビューをされない
    同じレビューをされないことでレビュアーの負担を減らす
    レビューにかかる時間を減らす
    重要な指摘箇所の見落としを防ぐ

→ レビュアーの負担を減らすようにすることで、結果自分のためになることがよく分かりました！

  • 自分以外のレビューを見る
    自分もその指摘をされる可能性がある

  • 心構え：コメントの口調は気にしない、なぜを汲み取る

  • コメントの口調は気にしない
    攻撃したいわけではない、忙しいと口調まで気に掛けられなかったりする、慣れる

→ コードレビューが怖かった昔の自分を思い出しました。

  • なぜを汲み取る
    なぜを汲み取ることで抽象度をあげて自分のストックにする

→ 具体的なレビューが出ていてとても分かりやすかったです！
総じて自分が提出物の提出前にもっと気をつけようと思えることばかりでした！
「レビュイーにもできることがある」という言葉がインパクトがありました。
「同じレビューをされない」と「なぜを汲み取る」は特に重要視しないといけないなと思いました！

Yoshito Tanakaさん

「妥協できないソニックガーデンのコードレビュー」

  • 妥協しないコードレビューとは
    • 将来にわたって面倒を見ることができるか
    • コードを読めば全てがわかるようになっているか
    • 思ったこと全てをフィードバックする

単なる品質チェックではなく、技術的な思想を共有・議論する重要な場になっている

→ 私の中でコードレビューはお言葉を借りるなら品質チェックのイメージが強かったので、「技術的な思想を共有・議論する場」という視点に変えようと思いました。
品質チェックだとそれこそ採点されているような気持ちになってしまうけど、思想を共有・議論する場と考えていればディベートして当たり前だしレビューがきても対等な気持ちで向き合えるなと思いました。（メンターさんと受講生はもちろん対等ではないですが、意見自体はどちらが上とかはなく対等と考えて良いのかなと思いました）

  • 妥協しないコードレビューの実例
    • 納得するまで議論する
    • 空行にもこだわる
    • 思想についても好みとしてコメントする
    • 自分ことは棚に上げてでも思ったことは伝える
    • 代替案がなくても違和感は伝える

→ 今自分はプラクティスで過去に自分が作ったコードを修正するというものをやっていて、昔自分が書いたコードなのに本当に何を書いているか分からなくて苦戦してます。
最近そういう思いをしたばかりだったので、「将来にわたって面倒を見ることができるか」と「コードを読めば全てがわかるようになっているか」は本当にそうだなぁと痛感しました。
また、実例を挙げて説明してくださり分かりやすかったです。
いざ自分がレビューする側になったとときに、最初は無理でも最終的にはそういった細かいところ・気になるところを意見として伝えられるようにしたいなぁと思いました。

雑談

印象に残っているのは、運営の方が「なぜ無料でこのような勉強会を外部にやってくれるのですか？」との質問に「妥協しないエンジニアが集まっていて、社内の勉強会をしたりしていくうちにそれが社外に広がった」とおっしゃっていたことです。無料でこのような勉強会を開いていただいて私のような初学者も参加しやすくて本当にありがたいなと感じました。

勉強会を終えての感想

  • レビュアーとして成長することがチームへの貢献にもなるし自分を助けることにもなる
  • レビューはその意図を（わからなければ質問した上で）きちんと理解することで、自分の中で抽象度をあげてストックにできて他に活かせるようになる
  • コードレビューは技術的な思想を共有・議論する場

どの方のLTも分かりやすく勉強になりました！
自分のコードレビューに対する意識を変えていきたいと思います。
ソニックガーデンの皆様、ありがとうございました！

おわりに

今回は、エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」に参加した感想を書いていきました。
勉強会に参加すると刺激をもらえるしモチベーションもあがるので、今後も参加していきたいなと思っています。



終わります👋

Omotesando.rb#92に参加しました！

イベント

こんにちは！もとひろです。

12月7日にOmotesando.rb#92に参加しました！
【オフライン開催】Omotesando.rb #92 - connpass
技術系オフラインイベントに参加すること自体初めてで、ただいるだけなのにめちゃくちゃ緊張しました。笑
参加しての感想などを記録しておきます。

最初の自己紹介

最初に全員自己紹介をしました。（焦りました笑）
あぁこの企業聞いたことあるな、とか、作ってるって言ってたもの聞いたことあるな、とか自分なりに色々思いながら自己紹介を聞いていました。
自分が自己紹介したときに、「フィヨルドブートキャンプで学習しています」と言うと、「あぁあそこね」という雰囲気でみなさん知ってるんだなとちょっと驚きました。
学習中であってもあたたかく迎えてくださる感じがありがたかったです。

LTの感想

LTの内容に関しては正直ついていけてなく、単語をメモすることで精一杯でした。
それでもみなさんの熱意を直に感じることができたので、オフラインでLTを聴けて良かったなと思いました。

以下LTの感想＆自分で調べた事等追加で記録してます。
途中に自分の感想が入ってしまっているので感想部分は文字色を変えました。

MNTSQ株式会社様

（もんてすきゅー）
簡単に言えば「契約書のGitHub」を提供している。
過去の契約に至るやり取りや履歴等を全部残しておくことができるので、後々プロジェクトに参加した人でもなぜこの契約はこのように締結されているのかがわかりやすいとのことです。
会場ありがとうございました！

OKURA Masafumiさん

FBCのアドバイザー、Kaigi on Railsのチーフオーガナイザー

Albaにきたissue、からのrender jsonの話

Alba

Okuraさん自作のgem
okuramasafumi/alba: Alba is a JSON serializer for Ruby.

Alba is a JSON serializer for Ruby, JRuby, and TruffleRuby.

直訳：Alba は、Ruby、JRuby、および TruffleRuby 用の JSON シリアライザーです。
シリアライズとは：直列化(serialize)。オブジェクトとそのインスタンス変数をバイト列やXMLに変換すること。 これにより、オブジェクトをファイルとして保存したり、ネットワークで送信することができるようになる。

本題

Albaにきたissue、からのrender jsonの話
（元のissue）
renderのオプションにlocationを使うとwarningがでるというissue
renderの中身…
この辺から難しくてついていけてませんでしたが、後日調べるうちに関連してそうなOkuraさんのQiitaの記事を見つけました。
RailsがJSONをレンダーするときに何が起きているのか #Rails - Qiita
上記リンク内のこの部分

add内の1行目で引数が文字列でなければto_json(options)を呼ぶようになっています。

を示して「これを覚えて帰って」って最後おっしゃってたと思います。

gemにissueがこんなふうに来て、こうやって調査して解決していくんだな、ということを知れてよかったです。

神速さん

「CircleCIの高速化」

CircleCI

CircleCI について - CircleCI
いまさらだけどCircleCIに入門したので分かりやすくまとめてみた #CircleCI - Qiita
色々読んでみましたが難しかったです…

CIを速くするアイデア

ソースコードの変更がない場合、テストを実行する必要がない
ソースコードの変更がない：fast-forward、コミットメッセージ変更しただけ
DynamicConfigration ：CircleCiの機能、生成したYAMLでCIを実行

CircleCI（CIとかCDとか）の理解が全然足りませんでした。
私はRailsのi18nでしかYAMLを使ったことがなかったので、YAMLでいろんなことができるんだなぁと驚きました！

euglena1215さん（ゆーぐれなさん）

「Railsでエンドポイントごとのテストカバレッチを測定する」

テストカバレッチ：

テストカバレッジ（test coverage）とは、ソフトウェアテストの進捗を表す尺度の一つで、テスト対象のソースコードのうち、どの程度の割合のコードがテストされたかを表すもの。

テストカバレッジ（コードカバレッジ）とは - 意味をわかりやすく - IT用語辞典 e-Words

なぜやろうと思ったのか

Railsアップグレードでの動作確認は手動でしなくて良い。テストカバレッジが高い
例外：社内向けの管理画面は手動での動作確認が必要（テストカバレッジが低いから）→テストを増やす必要がある
やみくもにテストを増やすのではなく、指標が欲しい。
→どの指標がより正確か

CodeLineCoverageを指標としてみた

CodeLineCoverage：テスト中に実行されたコードと実行されていないコードを区別し実行された割合を算出
LineCoverageと一緒？
テストカバレッジをフローチャートで確認する
分岐網羅ってみたことある…と思ったらプラクティスでちゃんとやってた！
ホワイトボックステストにおけるカバレッジとテストケース
ActiveAdmin：Railsのプラグイン。簡単に管理画面を作りたい時に作れるgem。９つのエンドポイント（≒機能）が定義される。
Active Admin | The administration framework for Ruby on Rails
このファイル（app/admin/users.rb）が読み込まれただけで全ての行が実行されたことになってしまう（テスト書いてなくても通ってしまう）
数行でいくつもの画面を生成できるので、機能数とコードの行数が比例しない。
→ActiveAdminを使った管理画面ではCodeLineCoverageを指標にするのは不適切

EndPointCoverage（造語）を指標とした

ActiveAdminにおいて機能数に比例するのはエンドポイント。
実現方法
Railsのroutes相当の情報を取得：Rails.application.routes.routes初めてみた！

Rails.application.routes.routes.map do |route|
  path = route.path.spec.to_s.gsub('(.:format)', '')
  { verb: route.verb, path: }
end

テストファイルを読み込みルーティングに対応するテストを抜き出す。
上記2つのデータを合わせて、テストされている・されていないエンドポイントを分けて割合を出す。

先日テストのプラクティスをやったので、コードの内容は難しかったけれどなんとなく言っていることの流れは少し掴めた気がしました！
テストカバレッチとかは実際に仕事では重要な話だけど、学習中にはあまり出てきていないので面白かったです！

まいむさん

「ワンライナーでfizzbuzz」

ワンライナー：一行で書かれたコマンドの組み合わせ。

試作

$ seq 100 | awk '$1%15==0{print "FizzBuzz"}$1%5==0{print "Buzz"}$1%3==0{print "Fizz"}$1%15{print $1}'

seq：連続した数字の列を出力するコマンド
awk パターン{アクション}：パターンにマッチしたときにアクションを実行。アクションはテキスト処理を記述。
実行結果：　

$1に入った数値が%15→%5→%3→そのままprintと全部経由していくので、%5に該当してBuzzが出てもそのあとに5が出てしまっている

１つめ

さっきのものに条件分岐を追加。

$ seq 100 | awk '{ if ($1%15==0)print "FizzBuzz"; else if ($1%3==0)print "Fizz"; else if ($1%5==0)print "Buzz"; else print $1; }'

実行結果：OK！　

２つめ

$ seq 100 | sed -e '3~3s/.*/Fizz/' -e '5~5s/.*/Buzz/' -e '15~15s/.*/FizzBuzz/'

sed 'コマンド/引数/フラグ' 対象ファイル：非対話型エディタ。指定したファイルをコマンドに従って処理する。
-e：sedで複数のコマンドを指定する際に使用する。
s：指定されたパターンに基づいて行を置換するコマンド。sed 's/置換前文字列/置換後文字列/フラグ'
.*：正規表現で任意の文字列。

実行結果：OK！　

こちらを再現する上で全然想定通りではないことがあったのですが、そちらはまた別の機会に記事にしたいと思います。

３つめ

$ seq 100 | sed -e '15~15c\FizzBuzz' -e '3~3c\Fizz' -e '5~5c\Buzz'

c：指定した行をテキストに置換する。
sとcの違いは、sは指定された文字列のみ置換し、cは指定された行まるごと置換する。
実行結果：OK！　

４つめ

$ seq 100 | ruby -ne 'if $_.to_i%15==0; puts "FizzBuzz" elsif $_.to_i%5==0; puts "Buzz" elsif $_.to_i%3==0; puts "Fizz"else puts $_ end'

-e：引数に記述されたRubyのコードを実行するためのオプション
-n：標準入力の内容を一行ずつ読み込む
$_： nオプションで読み込んだ文字列が格納される変数
実行結果：OK！　

そもそもワンライナーというのを全く知らず、１行でFizzBuzzが出力できるんだということに驚きました！
そしてLinuxのコマンドを自分はほとんど知らないなと今回再現してみて思いました。
シェル芸ってすごい！

雑談会

みなさん優しい方ばかりでした！
覚えていることを箇条書きで書きます。
・vimに移行したい→neovimっていうのがある
・Rubyはリリースした後リリースパーティがある（だいたいクリスマス後らへん）
・Ruby3.4のitの話題（この話っぽい）
・企業研修でフィヨルドでお世話になりました〜という方がいた
・フィヨルド卒業生のmaimuさんに聞きたかったことを色々伺いました！ありがとうございます！

自分からあまり話したりはできなかったので、次はもっといろんな方にお話を伺えるようにしたいなぁと思いました。

おわりに

長くなってしまいました…。
もし間違っている箇所等あればご指摘いただければ幸いです。

参加してみて、みなさんの熱量を感じられて自分もモチベーション上がったし楽しかったので、またイベントに参加してみたいと思っています！
行って良かったです！


終わります👋