TokyuRuby会議16で初めての外部LT登壇しました

この記事は フィヨルドブートキャンプアドベントカレンダー2025 の1日目の記事です。

今年から、卒業生の hagi さんが開発されたフィヨルドブートキャンプ専用のアドベントカレンダーアプリでの開催です🎉

hagi0121.hatenablog.com

そして僕は昨年に続いて初日を担当しています、よろしくお願いします🚀

🔖 目次

👨🏻 自己紹介

@sugiwe (すぎえ)と申します。
先日11月21日、CAMPUSというアプリをリリースしてプログラミングスクールの フィヨルドブートキャンプ (以下、FBC)を卒業しました!よろしければアプリのリリースブログもご覧ください🙏

sugiwe.hatenablog.jp

さて、この記事では先日11/29(土)に参加してきたTokyuRuby会議16の話を書きます。
今回はフィヨルドブートキャンプアドカレンダーなので、FBCに関することを多めに書いていきたいなと思います。

ちなみに僕はポッドキャストもやっておりまして、TokyuRuby会議の帰り道に感想などを収録したエピソードも本日同時公開しましたので、よろしければ併せてお聴きいただけると幸いです👂

listen.style

🍶 TokyuRuby会議とは

TokyuRuby会議は、プログラミング言語RubyにまつわるLT大会で、参加者一人ひとりが食べ物・飲み物を持ち寄り、休憩を挟みつつ4〜5時間ずっとLTが続くという会です。

以下、公式ページ からの引用です。

  • TokyuRuby会議は、東京で開催される Regional RubyKaigi です。
  • Ruby に興味を持つエンジニアが集う Tokyu.rb 主催の LT 大会です。
  • 飲み食いしつつ、みんなでLTをして盛り上がろうというイベントです。
  • 抽選LTを実施予定です! 抽選LT発表者の指名は抽選により、当日会場にて行います!当たるかもしれません!
  • 今回も参加者のみなさんの投票により飯王、酒王、LT王を決定します!

僕は今回のTokyuRuby会議が初の地域Ruby会議参加でした。
何名かの方に「これは一般的な地域Ruby会議とちょっと違うからね」と言われて面白かったです笑。

会場は GMO Yours・フクラス さん。めちゃくちゃ綺麗で広くて良い場所だった…!

🐦 FBC関係者が多い

Rubyコミュニティに顔を出せばほとんどの場合にFBC関係者がいる、という感じかと思いますが、今回のTokyuRuby会議では特にその割合が多いような気がして、僕のように初めてでも知っている人がたくさんいてとても参加しやすかったなと思います。

💁スタッフ

まず今回の実行委員長さんがFBCの現役受講生です。(受講生なのに実行委員長、めちゃくちゃすごい!!!)
また、それ以外のスタッフさんもFBCのメンター・卒業生・受講生が揃っており、安心して参加することができました。スタッフ業お疲れ様でした、ありがとうございました✨

🙋登壇者

登壇者もFBCの卒業生・現役生が多くいらっしゃいました。(そして自分も末席に加えていただきました)

  • 登壇者の中のFBC関係者(sugiwe調べ。違ってたらすみません🙏)
    • 通常LT登壇:6名
    • 抽選LT登壇:1名
    • 飛び込みLT登壇:3名

重複もあるので正味9人です。LTが全体で30くらいだったと思うので、なんと登壇者の3割くらいがFBC関係者でした。

自分が特に感動したのは、「こういった場で喋ったことがないので慣れるために喋ります」と飛び込み登壇されていた方がいたことです。その行動力を真似したいと思ったし、そう思って行動した瞬間を見られてかなりグッと来てしまいました。

🙎参加者

参加者の中にもFBC関係者さんがたくさんいらっしゃいました!
(参加者に限らずスタッフ・登壇者まとめての話になりますが)オフラインでお話できる貴重な機会だったので、色々な方にご挨拶できて良かったです😄

💬 LT登壇しました

TokyuRuby会議はエントリーのハードルが低めのLT会ということで、FBC内のDiscordでも「はじめてのLT会(FBC内で不定期開催されるオンラインLTイベント)の次にLTデビューに適している」と紹介されていたので、エイヤー の気持ちで登壇を希望しました。

先日リリースした自作サービスCAMPUSの開発時にやっていたことと絡めて、以下の内容で登壇させていただきました。

speakerdeck.com

緊張しましたが楽しかったです!

LT王には全然届きませんでしたが、なんと自分の発表に1票入っていました!!!コメント欄には一言、「いい」のお言葉。めちゃ嬉しいです、どなたか存じませんがありがとうございます🙏🙏🙏

額縁に飾っておきたい、この画面

とはいえ内容的には色々反省があるので、今回発表した考え方をさらに実践してもっと深めてみたいなと思っています。

✨ LT・ご飯の感想

飲み食いしてたり発表前に緊張していたりでちゃんと聞けなかったものもあるのですが、どれも素敵な発表でした。 ほとんどメモできてなかったので、撮っていた写真などから思い出したものを挙げていきます。

  • Linuxディストリビューションの良さをまだ何も知らないので知りたい
  • H×Hの念能力系統になぞらえてバックエンド系・インフラ系とか分けた系統図、面白かった
  • O'Reilly Learning Platformで前書きの多読してみたい(いいお値段するんだよなぁ涙)
  • 暦に技術負債が溜まっている話、面白かった
  • 「毎日Rubyで開発してるのにgemを作ったことがない」からgemをリリースしたの凄い
  • 息子に勝つために素因数分解ゲーム作ったの凄い(というか息子さんも凄すぎる)
  • 抽選LTで突然ブルパップ銃の話が始まるの凄い
  • minitestの結果で魚を泳がせるの超面白かった

ご飯も、どれも美味しくて最高でした!

  • 牛すじ煮めちゃくちゃ美味しかった
  • 豚の角煮もめちゃくちゃ美味しかった
  • チキン春巻き、梅大葉のやつ美味しかった
  • 酢豚ならぬ酢鶏、美味しかった
  • チーズケーキ美味しかった
  • コーヒー美味しかった
  • ポンデリング.split、食べやすくて良かった
  • 納豆チップス、意外にもとても美味しかった
  • 海苔が巻かれた団子、とても美味しかった
  • ねこねこレモンケーキ、可愛くて美味しかった
  • 柿甘味という和菓子、感動的に美味しかった
  • 転職ドラフトさんのビール 、美味しかった!DAYDREAMをいただきました🍺

ご飯の感想のほうが多くなってしまった…🍖🍡🍗

反省

皆さんのLTを振り返ってみると自分の発表は何かちょっと真面目すぎたというか、中身もさることながらですが構成も発表のお作法に沿いすぎていたというか、もっとこう「自分の興味あること一点突破」みたいな発表をしてみたいなーと思いました。

「時間が決まっているからにはその時間内に収まるようにしなきゃ」と思って準備後半は内容というより発表のことに気持ちが向いていたんですが、なんかそんなお行儀の良いものではなく、「とにかく言いたいことを詰め込む、そして銅鑼がなるまで喋り続ける」みたいなLTはとてもカッコいいなと思いました。

🚀 紹介されていたgemを確認・試してみました

LTで紹介されていた以下のgemを確認・試してみました!
ちなみにこの2つのgemをリリースされたのもFBCの卒業生・現役生です👏
自分もgemをリリースしたい気持ちになりました🔥

inline_partial

rubygems.org

パーシャルに別ファイルに分けずに同一ファイル内に置いておくためのgemのようです。 上でも紹介したCAMPUSで言うと、まさに発表内で紹介したマイページの「参加イベント」「主催イベント」のところは別ファイルのパーシャルに分けていますが、これを単一ファイル内に置いておける、ということになります。

inline_partialの特徴を伝えるために実際のCAMPUSのコードをすごく省略化した上で書いてみました。

# 本当は以下の部分をパーシャルで別ファイルに分けるけど、同一ファイル内に置いておける
<% inline_partial(:event_item) do |event| %>
  <div>
    <h4><%= event.title %></h4>
    <p><%= event.start_date %></p>
    <!-- その他、各種イベント情報 -->
  </div>
<% end %>

<div>
  <h3>参加イベント</h3>
  <%= render_inline_partial :event_item, collection: participated_events %>
</div>

<div>
  <h3>主催イベント</h3>
  <%= render_inline_partial :event_item, collection: created_events %>
</div>

今回は既にパーシャルで別ファイルに分割済みなのとコード量の関係から実際にinline_partialの導入はできていませんが、紹介されていたように「パーシャル化したいけど別ファイルに分けるほどでもない」ときにとても重宝しそうです。

というか、「1つのerb内にまとめて書く」という方針が自分の発表した「Viewファーストな開発」とめちゃくちゃ相性が良いのではということに気が付きました。チャンスがあればぜひ試してみたいです!

METs-advisor

rubygems.org

METsとは、身体活動の強さを表す単位で、安静に座っている状態を1メッツというそうです。知らなかった!

# まずインストール
% gem install mets_advisor

# 実行、あとは質問に答えていくだけ
% mets_advisor

Please select your language / 言語を選択してください: 日本語

1週間の歩数を1日平均で教えてください: 7000
1週間に何日間運動をしていますか?: 5

運動の強度を選んでください: 軽度(徒歩・ピラティスなど)

以下から該当する活動を選んでください: 少し速めに歩く
その運動は1日合計で何分ほどですか?: 20

🎉あなたの身体活動量は理想値を上回っています!🎉
---------------------------------------------------
あなたの身体活動量は【24 METs】です。
素晴らしいですね!これからもこの身体活動量を続け、健康を維持してください!

意外と悪くない結果が出ました🙌
とはいえ自覚としてはちょっと運動不足気味なので、健康に気をつけてもう少し運動しなきゃと思っています🏃

🙏 終わりに

初めてのTokyuRuby会議参加、そして初めてのLT登壇でしたが、とても楽しかったです。
運営チームの皆さま、スポンサーの皆さま、そして参加者の皆さま、どうもありがとうございました!!!

📅 明日のアドカレ

ここまでお読みいただき、ありがとうございました😄

明日のフィヨルドブートキャンプアドベントカレンダー2025は、 kyokucho1989 さんの予定です。

フィヨルドブートキャンプアドベントカレンダー2025 は始まったばかりです、25日までぜひお楽しみください〜✨

組織やコミュニティでクローズドに使えるイベント管理アプリ『CAMPUS』をリリースしました🚀

こんにちは、フィヨルドブートキャンプ(以下、FBC)で学ぶsugiweと申します。

この度、組織やコミュニティでクローズドに使えるイベント管理アプリ『CAMPUS』をリリースしました🎉

チーム内だけで使えるイベント管理アプリ、『CAMPUS』

この記事ではCAMPUSの開発背景や今後の展開、開発の振り返りなどについて書いていきます。

🌟CAMPUSについて

🌍 サービスURL

https://campus.bz/

campus.bz

🎨 サービス概要

CAMPUSは、会社やコミュニティのメンバーだけで使えるクローズドなイベント管理プラットフォームです。

一般的なイベント管理プラットフォームでは、登録イベントは基本的にすべてオープンです。登録ユーザーであれば、どのイベントにも自由に参加申し込みできる仕組みになっています。
それに対してCAMPUSは、会社やコミュニティなど特定のメンバーだけで使えるクローズドな環境を提供しているのが特徴です。

👯 こんな人たちに使ってほしい

CAMPUSは「イベントを通じて組織・チーム内の交流を促進したいけど、うまく運用できていない…」という人たちに使ってほしいサービスです。

  • 社内で勉強会やランチ会、交流イベントを実施しているものの、告知がチャットで流れていってしまい困っているチーム
    • Slackで告知したのに気づかれない
    • 参加者の取りまとめが毎回手作業
  • リモートワークでメンバーが全国に分散しており、オンラインランチや雑談会など、ゆるい交流の場をつくりたいチーム
    • チームの一体感を作りにくい
    • 新メンバーの交流機会が少なく馴染みづらい
  • コミュニティ運営で、イベント管理をもっと手軽にしたい人たち
    • SlackやDiscord上だとイベントが埋もれてしまう
    • Googleフォームでは堅すぎるし、継続運用が面倒
  • 学習コミュニティ・学生団体など、クローズドなメンバーだけでイベントを共有したいグループ
    • 毎月の企画をLINEやメールで案内していて、管理に困っている
    • 気軽な交流の場をもっと増やしたい

📜 開発の背景

CAMPUSには元ネタがあります。今回の開発をするにあたって欠かせない話なので、よろしければお付き合いください🙏

🐣 CAMPUSが生まれたきっかけ

時は2019年に遡ります。

当時、僕の前職であり今でも業務委託で関わらせてもらっている企業で、新規事業立ち上げのお手伝いをしていました。そこでいろいろなアイデアを出しては議論する中で生まれた案の1つがCAMPUSです。

前職企業では「自分で社員旅行の企画を立ち上げて参加者を募ることができる」というユニークな社員旅行制度があります。
それまでは、企画をメールやチャットで集めてエクセル管理して社員アンケートを取って参加したい企画を決めて…というようなやり方をしていましたが、これをWebアプリで実現できるようにしよう、というのがCAMPUSの原型です。

新規事業開発チームではアプリ開発のノウハウもなく、かといってアイデアをすぐに外部の開発会社に発注する予算もありません。そこで、某CMSを使ってさまざまなプラグインを駆使し、最低限必要な機能を持つプロトタイプを作成しました。
まずこのプロトタイプを社内で使ってもらい、その手応え如何によっては新規事業の本流として開発を進めていく可能性もありました。

🔥 解散、そして6年越しの再挑戦

ところがそれからほどなくし、諸々の事情で新規事業開発チーム自体が解散となってしまいました。他のアイデアも進めたりしていたのでとても残念でしたし、開発のためには別の開発会社への依頼も必要だったりしたので、「もし自分に開発する力があれば、もっとスピーディに開発を進められて解散にはならなかったかもしれないのに…」と悔しく思ったことも覚えています。
(CAMPUSプロトタイプ版はその後も社内で使われ続けていましたが、新しい機能追加や改善活動については止まっている状態でした)

そこで今回、FBCの最終課題であり集大成である自作サービスとして、改めて前職で使ってもらえるようCAMPUSをRuby on Railsで開発することにしました。

もっと言うと、僕はCAMPUSを自分の手でゼロから開発できる技術を身につけるためにFBCの門を叩いたと言っても過言ではありません。

6年越しに目標を実現することができ、とても嬉しいです。

🧑‍💻 CAMPUSの使い方

🚀 今後の展開について

CAMPUSは現在ベータ版として無料で提供していますが、将来的に有料プランを導入したいと思っています。

今後のロードマップとして以下のような追加機能を検討しており、その中のいくつかは有料プランの機能として解放できればと考えております。

  • 各種通知機能
    • より便利にCAMPUSを活用するための、メールやチャットツールなどへの通知機能
  • 管理者用ダッシュボード機能
    • メンバーごとのイベント参加状況やイベント作成数ランキングなど、管理者に便利な情報の集約
  • 開催報告機能
    • イベント開催後には当日の写真や振り返り文章などを追加掲載できる機能
  • サブドメイン方式
    • チームごとに teamname.campus.bz のようなシンプルなURLを持てる仕組み
  • イベント画像の自動生成
    • 生成AIを用いてイベント用画像を簡単に作成できる機能




ここからは、CAMPUSの開発で使用した技術や、開発を通じて学んだことについて紹介します。技術的な内容が含まれますので、スキップされたい方は おわりに へジャンプしていただいても大丈夫です!

🛠️ 技術スタック

技術スタックは以下のようになっています。

💡 開発で工夫したこと・学んだこと

ここではCAMPUSを開発するにあたって工夫したことや学んだことを紹介します。

🏢 マルチテナント方式にした

経緯で書いたように、CAMPUSはまず前職の企業で使ってもらうことを念頭に置いたアプリです。一社で使うだけであればマルチテナント方式にすることは必須ではありませんでした。

ただ、せっかくこのサービスをゼロから開発するのであれば、他の企業やコミュニティなど、いろいろな方に使ってほしいと思い、CAMPUSは開発初期時点からマルチテナント方式を採用しました。

ここでいうマルチテナント方式とは、Slack・Notion・esaのように、利用する団体ごとに独立したグループ(スペース)を作成し、その内部でメンバー同士がやり取りしたり情報を共有したりできる仕組みのことを指します。

🎯 オブジェクト指向ベースなコードの書き方

条件判定をする際にはビュー側であれこれ条件分岐をするのではなく、モデル側でメソッドを作って呼び出すだけ、という書き方にするとコードの見通しが良くなります。頭ではわかっていたつもりなのですが実際にはビュー側の条件分岐が多発しており、メンターさんにたくさんの指摘をいただきました。

# 修正前(ビューで条件分岐)
<% if membership.role == 'admin' || membership == target %>

# 修正後
# モデルでメソッド化
def can_edit?(target)
  self == target || admin?
end

# ビューでは呼び出すだけ
<% if membership.can_edit?(target) %>

特にメンターさんに言われて印象的だったのは、「『あれ持った?これ持った?じゃあお出かけするよ』と子ども扱いするかのようにあれこれ尋ねるのではなく、シンプルに『出かける準備できてる?』とオブジェクトに問いかけるだけで済むようにしよう」という言葉です。

🎨 ビューファーストな開発

部分的にではありますが、先にビューを作ってからモデル・コントローラーを実装するという順番の開発をしてみました。

一般的なRailsアプリ開発では、まずモデルを定義して rails console で動作を確認しながら進める、というような流れが多いのではと思います。
それに対して今回は、先にビューファイルを作るというアプローチを試してみました。

これは自分がWordPressで独自テーマを作ってサイトを作成するときによく行う方法をベースにしています。(まず先に静的ページを作ってしまい、その後で必要な箇所でHTMLをPHPに書き換えてWordPressテーマにしていく、という手法)

先にビューファイルだけでそのページを全部作ると、ブラウザで完成版に近い形のページを見ることができて、作っていてテンションが上がります😄 また、完成イメージが明確になるので、必要なデータ構造やロジックが自然と見えてくるという効果もあったように思います。

先にデザインを入れる必要がありますので、デザイン作成を先にやっても良いというケースに限られるかもしれませんが、個人的には結構おすすめの手法です。
(今回はTailwind CSSを導入したので1ページずつビューを先に作るのもやりやすかったなと感じていますし、生成AIの力を借りるともっとラクに実現できそうな気がしています)

💻 その他

その他にも以下などの工夫・苦労・学びがありました。印象に残っているものをいくつかご紹介します。

  • Rails Wayに則ったリソース設計
    • 当初は「招待への参加」をカスタムアクション(new_membership, create_membership)で実装する想定をしていましたが「招待の受諾」を独立したリソース(Acceptances)として捉え直すことで、よりRESTfulな設計に改善することができました。
  • 公開エリアとメンバー専用エリアの完全分離
    • これも当初の想定から改善したものですが、招待リンクは公開エリア(/invitations/*)、チーム管理はメンバー専用エリア(/teams/:slug/*)として、ルーティング構造で完全に分離しました。公開・非公開ページを構造で解決することでコードがシンプルになり、セキュリティ上のリスクも軽減できたと思います。
  • Active Storageの画像アップロード機能
    • Railsでの画像アップはActive Storageが定番ですが、デフォルトのままでは使い勝手に課題を感じました。CSSでアップロードボタンを別途用意したりStimulusを活用してプレビュー機能をつけるなど、少しでも使いやすくなるように工夫しました。
  • enumはinteger型にするかstring型にするか?
    • DB軽量化や将来的な変更柔軟性を考えるとinteger型も良かったのですが、直接DBを見た時の可視性などを考えて今回はstring型を選択しました。何日も悩んだり人に相談したりもして、トレードオフを考えて決めました。enumで扱う型について検討できたのは勉強になったし面白かったです。
  • ユーザーフレンドリーな@付きURL
    • これは自分の好みで実装した面もありますが、メンバープロフィールのURLを/teams/:slug/@:usernameの形式にすることで、直感的なURLを実現しました。(あと、URLに自分のアカウント名が入っていると嬉しい✨)
  • インフラはHerokuを選択
    • リージョンや費用面のデメリットはあるものの、デプロイの容易性や過去の知見を活用しやすいという観点から、インフラはHerokuにお任せしてアプリケーション開発に専念するという作戦を選択しました。
  • Hotwire導入のトライ
    • 全体でTurbo Driveを適用しページ全体の再読み込みを減らしたり、カテゴリー作成・更新の箇所ではTurbo Streamsを活用することで、部分的にではありますが最低限のJavaScriptでシームレスな画面遷移を実現できました。Hotwire導入は必須ではなかったのですが、今後使っていく技術として今回触れられたのは良かったです。

🎊 おわりに

開発にあたって相談に乗ってくださったりレビューをしてくださったFBCのメンターの皆さま、そして輪読会やもくもく会、その他オンライン・オフラインの場で話を聞いてくれたFBCの在校生・卒業生の皆さまに心から感謝しています。これからもよろしくお願いします。

また、僕がCAMPUS開発に改めて挑戦することを快諾していただき、そして現在進行形で協力してださっている前職の皆さまにも感謝を申し上げます。
まだまだ発展途上のサービスですが、ぜひ触ってみて、感想を聞かせてもらえたら嬉しいです。




同じFBC生のシモカワさんも最近、自作サービス『Rubree』をリリースされました!
リリースブログはこちら → Rubular の進化版「Rubree」リリース – Ruby × Rails × Wasm で正規表現をワンストップ管理 - aim2bpgのブログ

Ruby正規表現を学習・テスト・可視化・置換・コード生成まで、ブラウザだけで一度に扱えるワンストップ型ツール

めちゃくちゃ便利かつ完成度の高いサービスで、本当にすごいです✨
これから正規表現を扱う際にはガンガンRubreeのお世話になると思います、素敵なアプリ開発をありがとうございます&リリースおめでとうございます🎉

ソーシャルフィードリーダー「rururu」Closed Beta版の紹介

友人であり尊敬するソフトウェアエンジニアである juneboku さん(旧 june29 さん)と一緒に開発しているWebアプリケーション「rururu」が、この度めでたくClosed Beta版として広く使えるようになったのでこのブログでもお知らせします📣

rururuをざっくり説明

rururuを一言でいうと「ソーシャルフィードリーダー」です。

各種ブログ(noteやしずかなインターネットなどのブログサービスを含む)・各種ポッドキャストYouTubeなど、RSSフィードを吐き出しているウェブメディアであれば、RSSフィードを登録・購読することで、それらの最新情報をキャッチすることができます。

視聴した記事・動画・音声については既読チェック(Pawprint=足あと)を付けられて、さらにPawprintごとに簡単なメモを残すことができます。

また、「ソーシャル」と銘打っている通り、自分の購読しているチャンネルや既読チェックのPawprint・感想メモは他の人からも見られるようになっていて、他のユーザーのPawprintや感想メモから新しいブログ・ポッドキャストYouTubeなど新しいコンテンツに出会うこともできます。

こんな人に使ってみてほしい

  • 「インプットしたいけどSNSでずっと情報収集をしていると疲れちゃうな」
  • 「いろんな人のブログ更新情報をチェックしたいな」
  • ポッドキャストやブログの感想やメモを気軽に残したいな」

といったお悩みをお持ちの方などいらっしゃったら、ぜひ使ってみていただけると嬉しいです!

アプリ・紹介音声

  • アプリはこちら💁
    • https://rururu.app
    • ページ右上の「Login」から「rururuを使ってみたい方」のほうのGoogleログインで進んでいただき、コメントを添えてリクエストをお送りください
  • juneboku さんのポッドキャストに呼んでもらって一緒にrururuについて喋っているエピソード💁
    • listen.style
  • 上記エピソードを受けて僕のポッドキャストでもrururuに触れているエピソード💁
    • listen.style

今回は取り急ぎ告知だけになりますが、追って詳しい話なども書けたらと思っています🚀

川柳を毎朝詠んで50句になったので紹介します

はじめに

フィヨルドブートキャンプ内の何気ない会話から、毎日早朝に川柳をDiscordに投稿していました。

始めてみるとかなり楽しくて、翌日から毎日書いてました(体調を崩した期間を除く)。
めでたく50句を書くことができたので、ここでひと区切りとしたいと思います。

振り返ると色々書けて楽しかったので、ブログでもご紹介します🎋

川柳を詠んでいて感じたことなど

川柳といえば何を思い浮かべるでしょうか。

僕の認識が偏っている可能性がありますが、川柳というと世の中や家庭で感じるちょっとした不満や理不尽なことを皮肉やブラックユーモアに昇華して楽しむような句が多いイメージがあります。

それはそれで面白いのですが、個人的には皮肉やディスりはあんまり書きたくないなぁと思っており、どちらかというとのんびりと身の回りのことを題材にしたような句を詠むように心がけていました。 (と言っても自虐ネタはたまに、というか割と書いてしまいました😅 自虐はまぁ周りを悪くいうものではないので…!)

サラッと何気ない日常を詠めると、やっていて楽しいなぁと感じます。

個人的に気に入っている句5選

ここで自分が気に入っているものを、説明付きでご紹介します。

「蒸す朝に DRYにしたい 我がコード」

これはエンジニア川柳という感じで、DRYがダブルミーニングになっています。

蒸し暑さが残る朝に、カラッとしてほしいなぁという気候に対する「ドライにしたい」と、 エンジニア用語の「DRY(=Don't Repeat Yourself、重複したコードを書くな)」をかけています。

「書くことで 日々の小さな 機微を知る」

川柳を詠むことそのものを詠んだ句です。 川柳を毎日書こうと思っていると、普段から「あ、これをネタにできるかも」という発想で日常を過ごすようになります。 これは川柳に限らず日記やポッドキャストをやっていても感じるのですが、アウトプットすることを自分に課しておくと、自ずとインプットの精度が高まるというか、日々意識しながら生活できるので、良いなぁと思っています。

ついでに、日々機微で韻を踏んでいるところがお気に入りです。

「だんご手に 娘と歩く 秋祭り」

これはできるだけサラッと日常を詠もうとした句です。 駅前でやっていた秋祭りで色々な屋台が出ていて、娘に買ってあげた団子を手にもう少し屋台を見て回ったことを詠みました。 (食べ歩き、良くない!でもまぁ縁日の屋台はギリギリセーフということで…🙏)

さらっと詠んで情景が浮かぶ感じの川柳をもっと作れると良いなぁと思っています。

「母と子で あつ森ハマり 父ひとり」

これは軽い自虐系。 前から娘がハマっていた『あつまれ どうぶつの森』というゲームに最近妻もハマっていて、休日など2人で楽しそうにプレイしています。 僕はその横で勉強させてもらっているので全然イヤとかじゃない、むしろそれぞれの時間を持つことができて助かっているのですが、2人でキャッキャッと楽しそうにゲームしているのを見るとちょっと寂しくもなります😂

あと、この句では「り」を3回登場させてリズムを作っているところが気に入っています。

「なんとなく 買ったおやつが 美味かった」

これも、なんでもないことをサラッと詠んだ系です。 多分これが50句の中で「ベストオブなんでもないこと」だと思うのですが、なぜか気に入っています。 初めて買ったお菓子が美味しいと嬉しい😋

川柳とロゴデザインの共通点

僕はロゴのデザインを作るのが好きなのですが、川柳を作っていて、なんとなく脳みその同じ部分を使っている感覚を覚えました。

上でも書いた「ダブルミーニング」「韻を踏む」「サラッと作る」あたりです。

何年か前の事例にはなりますが、今でもお気に入りの「キマグレエフエム」ロゴを例にしてみます。 (キマグレエフエムは気まぐれな雑談をするポッドキャストです!オススメです✨)

上のマークの部分。これは2人の雑談ということで2つのフキダシを用いて、キマグレエフエムの頭文字であるカタカナの「キ」の形に見えるようにしています。
これは、川柳でいうところの「ダブルミーニング」にあたります。

また、下のロゴタイプ(文字)の部分はオリジナルで作っていて、曲線の具合や各要素が一定のリズムで並ぶように留意しています。

これは、川柳でいうところの「韻を踏む」にあたります。ちょっとこじつけ感もありますが、川柳もロゴもリズム良く配置されると気持ちよく鑑賞できるなというのは似ているなと感じています。

ちなみに、最後の「サラッと作る」というのはなかなか言語化が難しいのですが、言ってみれば「完成品を見れば、誰でも作れそうなもの」という感覚が近いです。

めちゃくちゃ特殊な形というわけでもなくシンプルにサラッと作られているように思えるけど何かイイ感じ。そういうロゴを作りたいなと思っているし、川柳でもそういう軽やかさみたいなものを醸し出せるといいなぁと思いました。

50句全部(時系列)

最後に、50句全部を書いた順に紹介します。

カッコの数字は、投稿についたスタンプの数です。複数種類のスタンプをつけてもらったり、川柳の中身に関係ないスタンプ(体調不良明けとか、50句目の時はこれで終わりますという挨拶も含めていたのでそれに対して反応いただいたりとか)も多かったりするのでスタンプの数でどうこうというものではないのですが、たくさん反応をしていただけてとても嬉しかったです😄

  • 8/20〜
    • 遅く寝ても 早く目覚める 歳のせい(9)
    • 霊圧を 感じる朝の Discord(7)
    • 蒸す朝に DRYにしたい 我がコード(11)
    • ストレッチ 逆に背中を 痛めたよ(9)
    • 猫ごはん 今あげたのに また催促(8)
    • 困ったら claudeよりも 玄人に(3)
    • 動くかな やっぱ動いた 蝉ファイナル(11)
  • 8/27〜
    • どうしても 今見た夢を 思い出せず(9)
    • 眠い朝 沁みるひと口目のコーヒー(8)
    • リモートで カメラONだけ シャツ羽織る(7)
    • またひとつ 買って満足 本棚へ(9)
    • なんとなく 買ったおやつが 美味かった(8)
    • 新学期 両手いっぱい 荷物持ち(9)
    • 書くことで 日々の小さな 機微を知る(8)
  • 9/3〜(ここから末尾に絵文字を付け始めた。絵文字は情報量がとても増えるのでズルい)
    • バグ見つけ git blame 過去の俺🧑🏻‍💻(13)
    • 月見パイ 待ったらチーチー 終わってた🍔(13)
    • 増えていく 見覚えのない 傷跡が🩹(10)
    • フィヨブーも いのち輝く EXPOだ🫀(9)
    • 朝5時の 静けさの中 もくもくと🧑🏻‍💻(8)
    • 真夜中の 空に怪奇な 赤い月🌕(17)
    • 懐いたと 思ったらまた 猫パンチ🐈(11)
  • 9/10〜
    • Appleの 新製品を めぐる朝🍎(6)
    • 酷暑超え 姿を見せる 蚊やトカゲ🦎(10)
    • 久々の 恵みの雨が 降りすぎて☂️(6)
    • さっきまで 動いてたのに なぜエラー🤔(5)
    • 朝ドラで 今また沁みる アンパンマン🍞(7)
    • 手を繋ぐ そろそろこれが 最後かも👧🏻(6)
    • 猫が吐く 音に飛び起き 手で受ける😇(12)
  • 9/17〜
    • 運動後 ラーメン食べて 元通り🍜(9)
    • コミットを またし忘れて git amend🧑‍💻(8)
    • 猛暑日か 大雨ばかり 秋恋し🍂(11)
    • 段々と 日の出とともに 寝坊助に🛌(12)
    • だんご手に 娘と歩く 秋祭り🍡(14)
    • 懐メロを 聞きまくる午後の幸せ🎵(7)
    • 火曜日の レアな祝日 嬉しいな㊗️(13)
  • 9/24〜
    • 母と子で あつ森ハマり 父ひとり👨🏻(10)
    • レシートを 栞がわりに 本を読む📕(10)
    • 皆さんと 物理で会える カンファレンス🤝(10)
    • 朝起きて 酷使に気付く 喉と足🦵(10)
    • 会終わり やってく気運 感じてる🔥(14)
    • 贅沢に 未読の本を 書架に積む📚(7)
    • 二日後に 筋肉痛の 山が来た🛌(8)
  • 10/1〜6
    • コロナ罹患でお休み
  • 10/7〜
    • 病あけ 机に向かう 嬉しさよ📖(17)
    • 病床で 冷えたアイスに 救われた🍨(10)
    • 帰り道 思ってたより 暗かった🌙(4)
    • 学ぶ秋 運動の秋 肥ゆる秋🍙(21)
    • キーボード 割って肩凝り 直したい⌨️(10)
    • あの家の 柴犬いつか モフりたい🐕(14)
    • 定番の 家族喜ぶ サーモンパイ🥧(5)
  • 10/14
    • 川柳を 毎日詠んで 50句に🎋(42)

終わりに

Discordで反応をくださった皆さま、ありがとうございました! (ちなみにCosense日記にも転記していたので誰でも見られる状態でした、日記のほうで反応をもらう時もあり嬉しかったです)

一旦これでひと区切りにしますが、機会があればまた書いていきたいなーと思っています👋

プログラミングRuby 第5版 翻訳支援 個人スポンサー(Goldプラン)になりました⛏️

Rubyの本がもっともっと増えてほしいので、下記のプロジェクト?に個人スポンサーのGoldプランで支援をしました🙌

www.snoozer05.org

完成を楽しみにしています😄

【フィヨルドブートキャンプ】チーム開発で、自分が欲しい機能を自分で作れてとても楽しかった

プログラミングスクールの フィヨルドブートキャンプ (以下、FBC)で学習中のsugiweです。

少し前の話になりますが、プラクティス「チーム開発」を修了しました。
(7月には修了していたのですがそこから自作サービス開発に入り、夢中になっている間に数ヶ月経ってしまいました汗)

今回はチーム開発の軽い振り返りと、自分が欲しい機能を自分で作ることができてとても楽しかったという話を書きます。

関連する話で、【フィヨルドブートキャンプ】チーム開発のgood first issueでモブプロをした話 という記事もありますので、よろしければご覧ください🙏

sugiwe.hatenablog.jp

🔖 目次

🧑‍🤝‍🧑 チーム開発とは?

一般用語で「チーム開発」と言えば文字通りチームで行う開発のことですが、ここでは、FBC終盤で取り組むプラクティス(課題)の1つを指します。FBC受講生が学習のために普段使っているEラーニング用Webアプリケーションの開発に参加し、自分たちが使っているアプリを自分たちで開発していきます。

github.com

チーム開発メンバーに加えてもらってからはプロダクトオーナー・スクラムマスターをされているメンターの方にIssueを割り振っていただき、対応していきます。各Issueには難易度に応じたポイントが割り振られていて、合計20ポイントのIssueを対応完了したらプラクティス修了、となります。

bootcampアプリはFBC入会してから毎日触っているものなので、どんなアプリなのかというのはチーム開発に到達した受講生であればよくわかっており、ずっと使ってきたアプリの開発メンバーに加わることができるというのはとてもエキサイティングだなと思っています😄

💪 「自分でIssueを立てて自分で担当する」ということ

チーム開発において僕が一番楽しかったのはこれで、このブログ記事で書きたかったことでもあります。

担当するIssueは、チーム開発序盤であればGood First Issueと呼ばれる軽微なIssueや易しめのIssueを割り振ってもらえたり、中盤〜終盤になると少し複雑なIssueや、それまで担当していなかった方向性のIssueを割り振ってもらえたりします。

なので基本的にはメンターさんにお任せでIssueを割り振ってもらうのがスタンダードな流れになりますが、「バックエンド系のIssueを多めにやりたい」とか「JS系をもう少しやりたい」とか、自分がより学びたいIssueを多めに割り振ってもらうような相談もできたりします。

一方、bootcampアプリはOSSなので誰でもリポジトリ内を見られるし、誰でもIssueを立てることができます。つまり、受講生自身もIssueを立てることができます。

僕はチーム開発に到達するまで数年間もこのbootcampアプリにお世話になっていて、チーム開発で自らそのアプリの開発メンバーに入れることを楽しみにしていました。 特にチーム開発が近づいてきてからは、「どんな機能があると嬉しいかな」「この部分、もっとこうなってると便利だな」といったことを考えながら日々アプリを触っていて、何か思いついたらメモしたり実際にIssueとして起票するようになりました。

そして、自分でIssueを立てて、それを自分で担当させてもらう、ということを多くやらせていただきました。

以下にスクリーンショットを貼ります(文字が小さい)。
現時点で僕が立てたIssueは18個あり、受講生の中では比較的多めなのではないかと思います。(すぐボツになったIssueとかもあります!Issueは立てるのはタダだしデメリットは何もないので、他の受講生の皆さんもガンガン立てることをお勧めします✨)

sugiweが立てたIssue一覧(チーム開発で担当させてもらったものを赤で囲っています)

(sugiweが立てたIssue一覧の GitHubリンク

❤️ 特に気に入っている機能追加3選

ここで、自分でIssueを立てて担当した中で特に気に入っている機能について幾つか紹介します。

企業一覧の各企業の「メンター」「アドバイザー」「現役生」の並びに「卒業生」が欲しい

github.com

bootcampアプリ内には、メンターさん・アドバイザーさんが所属している企業さんや、就職紹介先として提携していただいている企業さんなどを一覧で見られるページがあります。 これまでは、その企業に所属している「メンター」「アドバイザー」「現役生」の人数が表示されていたのですが、ここに「卒業生」も加えられるといいなと思いました。

フィヨルドブートキャンプはプログラミングスクールであり、どの企業でどれくらいの卒業生が活躍されているのかを一覧で見られることはとても価値があると考えました。というか、僕自身がどの企業にどれくらいの卒業生が在籍されているのを見たかったので、このIssueを立てました。

実装としてはとてもシンプルで、もともと卒業生側(というかユーザー側)の持つ情報として所属企業があったので、企業側でその数字をカウントして一覧側で出してあげる、というビューを追加するだけで実現できました。

この機能は今でもたまに自分で使っていて、実装はシンプルでも良い機能を追加できたなぁと思っています😄

現在のページURLをコピーするボタンが欲しい

github.com

僕はスマホでbootcampアプリを開いて他の受講生の日報などをチェックすることも多いです。 他の受講生の日報は自分にとっても学びになることが多く、「このページのURLをメモしておこう」と思うことも多いのですが、スマホ(PWA)でbootcampアプリを開いているとURLバーが出ないのでURLがわからない、という問題がありました。

そこで、URLコピーボタンを用意することでスマホで見ていても手軽に見ているページのURLをコピーできるようにしたいと思って立てたIssueです。

実装としては、レビューを経てJSのイベントリスナーを使って現在開いているページのURLをクリップボードにコピーできるようにしました。

日報提出お祝いメッセージの表示数を拡張したい

github.com

これは完全に自分のために作った機能です笑。

もともと過去に実装されていた機能として、「日報提出で1000回までのキリ番においてお祝いのメッセージを表示させる」というものがありました。コツコツ学習をして毎日日報を提出するなかで、たまにお祝いメッセージが表示されるのはとても嬉しいものです。

しかしこの機能に問題が発生しました。
卒業するにあたって、日報1000回を超える受講生が現れ始めました。僕です。

1000回以降、何もお祝いがなくなるというのが寂しくて、だったら自分で表示数の拡張をしようということでIssueを立てました。

実装としてはこれもシンプルで、上述した1000回目までの表示をするための機能追加の際にお祝いを表示するための回数を定数で定義してくださっていてそこに数字を追加するというのがメインでした。元の実装が非常にシンプルで機能追加しやすかったです。(machidaさんがめっっちゃ良い感じのお祝い画像をたくさん用意してくれました!!)

そして6月にめでたく、実装した僕自身が日報提出1100回目を迎えて、本番環境で正しく機能していることを確認できました🎉

現在、僕以外にも日報1000回を超える受講生の方が出てきており、1000回目以降もキリ番でお祝いできる機能を追加できて良かったです。

〜〜〜〜〜

まとめてから気づきましたがこの3つは比較的シンプルに実装を進められたIssueだったと思います。進めるにあたって何もわからず数週間止まってしまったり、レビューで色々と修正が必要になったり、機能の一部を切り出してnpmとして公開したり、他にも大変だったIssueはたくさんあるのですが、ここでは紹介を割愛します。

🧑‍💻 プロダクト志向?

プロダクト志向・技術志向という言葉があります。
ものすごくざっくり言えば、「プロダクトを良くすることが第一目的で、その手段として技術を使って開発したいと考える人」か「プロダクトそのものというよりは、プログラミングの技術に対する興味が強い人」という違いになると思います。

明確にどちらか1つに決められるものでもないし、ましてやどちらが良いとかいう話でもないと思っていますが、チーム開発を経て、自分は「ユーザーとしてこのプロダクトがどうなっていると嬉しいか、どういう機能があると便利か」といったことを起点にしてIssueを立てるのが好きだなと感じましたし、それを自分自身で担当し実現できることにこの上ない喜びを感じるなと思いました。

技術を疎かにするつもりはありませんし、むしろやればやるほどもっと知識・スキルを高めたい気持ちが膨らんでいますが、根っこの部分では「プロダクトを良くしたい」という感情があることを自覚できたのは、チーム開発で得た大きな収穫だなと感じています。

📝 担当PRとレビューさせていただいたPR

最後におまけとして、僕が担当したIssue(PR)とレビューさせていただいたIssue(PR)の一覧を紹介します。

担当したIssueとそのPull Request

Point Issue PR
1 PodCastのリンクがフッターに欲しい #8093 #8182
2 企業一覧の各企業の「メンター」「アドバイザー」「現役生」の並びに「卒業生」が欲しい #7872 #8189
2 現在のページURLをコピーするボタンが欲しい #8179 #8219
2 日報提出お祝いメッセージの表示数を拡張したい #8192 #8232
1 ユーザー一覧のタグ別ページで表示されるタグごとの人数と、
タグごとのページで表示される人数が異なっている #8571
#8587
2 「近日開催のイベント」で、当日の開催時間を過ぎたイベントは非表示になってほしい #8221 #8280
3 Markdownでfigureタグが使えるようにしたい。 #8075 #8545
2 管理画面のユーザー一覧を就職希望と決済方法で絞り込みたい #8440 #8737
3 Flakyなテストを修正する #8550 無し
1 escapeHTML関数内のタイポ(3箇所) #8674 #8696
2 Flakyなテストを1つ修正する #8594 #8844

合計 : 21pt

レビューさせていただいたIssueとそのPull Request

チーム開発の大きな特徴として、メンバー同士の相互レビューがあります。
チーム開発までのプラクティスでは自分が書いたコードに対してメンターさんからレビューをしてもらっていましたが、ここで初めて他の人のコードを読んで自分がレビューをする側になるということになります。これがこのプラクティスのユニークな点で、開発現場に近い経験を積める、とても学びの多いプラクティスだと思います。

Point Issue PR
2 Markdownエディタ内でstyleタグとonloadを実行できないようにしたい #6805 #8450
1 ユーザー個別ページにおけるコメントタブの数値とプロフィールページ内の
コメントカウント数がズレる #7618
#8223
5 管理者ページのお問い合わせ個別にコメントを付けたい。 #7452 #8262
1 現在、休会からの自動退会されるタイミングを6ヶ月にしているが、
それを規約通り3ヶ月に変更したい。 #8267
#8432
3 コースにサマリーというカラムを作成したい。 #8320 #8434
2 Markdown記法の記号でイベント名が始まると、Discord通知でがHTMLが
認識され表示くずれが起きる。まずは、イベントに対応。 #7916
#8199
1 使われていないページ「thanks」を削除する。 #8456 #8519
3 ベストアンサーが決まらないまま一定期間が過ぎたQ&Aを自動的に
クローズする #8086
#8687
2 ユーザー一覧 > 研修生一覧 研修終了の人は非表示したい #8138 #8848
1 ログイン前の画面のフッターにFBCのXアカウントへのリンクを置きたい #8606 #8612
1 給付金対象講座ページの最下部に受講申請のボタンを置きたい #8611 #8652
2 企業ロゴをwebpにする #8710 #8752
3 日報の気分を sad soso happy から、Negative, Neutral, Positive に
変更する。 #8681
#9117

合計 : 27pt

まとめてみたら、担当Issueよりも多くのポイント数のレビューをさせていただいたことがわかりました。
これはプラクティスにかかる時間が長くなればなるほどレビュー依頼される回数も増えがちな性質があるからだと思います。色々な方のPRを見られるのは貴重な勉強のチャンスだと思います!

👋 おわりに

書きたいことは全部上で書いたので以上になりますが、冒頭に紹介した記事【フィヨルドブートキャンプ】チーム開発のgood first issueでモブプロをした話 のほうで、以下のように書いていました。

最後に余談となりますが、僕はチーム開発で「出来るだけ自分で立てたissueを担当する」という裏目標を掲げています。

(※チーム開発ではメンターさんからissueを割り振ってもらい取り組んでいきますが、issueは誰でも自由に立てることができます)

自分が立てたissueを担当するというのはメリット・デメリット両面あると思いますが、個人的には大きなやりがいを感じています。(毎日自分が使っているアプリで自分が欲しいと思った機能を自分で実装できるなんてサイコーだと思いませんか?)これについてはチーム開発のプラクティスが全て終わってから改めて別記事で書きたいと思っています🚀

10ヶ月を経てようやくこの伏線を回収できて、良かったです😄

(「メリット・デメリット両面ある」と書いてるけど、デメリットあったかな?もし仮に全部のIssueを自分で立てたもので担当していたら偏りが出ていたかもしれませんが、結果的に半々くらいになったので、自分で立ててないものでバグ修正やテスト修正、JSのMarkdown関連のIssueなどやらせていただけたので、バランス的にも良かったのではないかと思います)

OSS Gateオンラインワークショップに参加してOSSにPRを出した

先日、『OSS Gateオンラインワークショップ』というのに参加してきました!

oss-gate.doorkeeper.jp

勉強になったしとても楽しかったので、その振り返りを書きます🙌

きっかけ

僕が現在プログラミングを勉強しているフィヨルドブートキャンプで、前にこのワークショップとのコラボ企画を開催されていることがあり、OSS Gateさんの名前は認識していました。

そして最近、フィヨブー卒業生のハムさんがこのワークショップに参加されたのを見て改めて興味を持ったのと、次回開催でハムさんがサポーターとして参加されることを知ったので、自分も参加してみようと思いました。

余談1

上記の前回開催ワークショップは6/14(土)でしたが、この日はフィヨルドブートキャンプ内でLT会があった日でした。 そのLTの中でとても感銘を受けたものがあり、その時の勢いで(まさにエイヤーで)即このワークショップに申し込みをした、という経緯があります。

speakerdeck.com

きっかけを作ってくれたham-capさん、そしてhirokiej さんに感謝です🙏

余談2

土曜日の日中開催のため、参加するには家族の協力が不可欠になります。ソフトウェア開発のことは何も知らない家族にOSSのことを説明するにあたり、「ゲームのMODを修正・改善できるよう製作者に要望を出すみたいな感じ」という説明が刺さりました。
「MODを直すのは偉大だ、どんどんやれ」「私のやってるゲームのMOD直してくれない?」などと言われ、ニュアンスが伝わって良かったなと思いましたが実際MODを直すのは別の話なので無理だと伝えました😂

当日の流れ・学んだこと

当日の流れ

当日はざっくり以下のような流れでワークショップが進んでいきました。

  1. OSS開発手順の説明
  2. コントリビュートしたいOSSを探す
  3. OSSを実際に動かしながらフィードバックポイントを探す
  4. OSSへのフィードバック
  5. まとめ・ふりかえり

1日で説明からOSS探しから実際のフィードバックまでやるということで間に合うのか結構心配でしたが、スムーズな進行で説明などもわかりやすく、また実際にフィードバック(PR作成)まで進めることができて良かったです!

学んだこと

ざざーっと箇条書きで書いていきます📝

  • 一次資料(公式ドキュメント・開発リポジトリ)を参照する
    • 誰かのブログ記事などに載っている方法を参照してうまくいってしまうと、コントリビュート(貢献)に繋がらなくなる
    • 本来、ソフトウェアは一次情報だけで無理なく操作できるのが理想
    • 一次情報で不足していたり誤っていることがあればそれを改善することで貢献できる
  • 自分の「困った」を大切にする
    • 「この不明点は、自分が初学者だからわからないだけなのでは…」と思わなくていい
    • 自分が困ったら、同じ部分で困る人が他にもいるはず
    • 「こうなっていたら自分は困らずに済む」という状態になるように改善要望を出す
      • 開発者自身はドキュメントを見ずにできちゃうので、意外と気づかない。初学者のためにはこういう部分こそがコントリビュートチャンス
  • Issueは丁寧に、PRはシンプルに
    • Issueを出す場合は、とにかく丁寧に書く
      • 自分の動作環境、何をしたのか、何をしてないのか、期待した結果がどうで実際の結果がどうだったのか等を、省略せずに書く
    • PRを出す場合はコードが語ってくれる
      • コードの差分によって何をしたいのかは明確なので、descriptionを長々と書く必要は無い(むしろ簡潔なほうが良い)
  • コントリビュートのお作法を確認する
    • OSSではコントリビュートの手順などを指定されていることも多い。CONTRIBUTING.md やその他の部分で、コントリビュートの方法が書かれていないか確認する
  • ライセンスを確認する
    • ライセンスはOSSの利用・改変・再配布等に関するルールを定めたものなので、めちゃくちゃ重要

どこにPRを出したか

僕は現在、フィヨルドブートキャンプの最終課題である『Web サービスを作る』というプラクティス(通称『自作サービス』)に取り組んでおり、Ruby on Railsのアプリケーションを開発中です。

そこでまさにこれから導入しようと思っているbulletというgemにPRを出しました。

bulletは、N+1問題を検出してくれる便利かつ有名なgemです。

The Bullet gem is designed to help you increase your application's performance by reducing the number of queries it makes. It will watch your queries while you develop your application and notify you when you should add eager loading (N+1 queries), when you're using eager loading that isn't necessary and when you should use counter cache.
(bullet)

「有名gemはたくさんの人の目に触れているので、改善ポイントをサッと見つけられないこともある」という話もあったので少し不安でしたが、ドキュメントに沿ってインストール・設定を進める中で改善できそうな箇所を見つけることができました。

そして実際に立てたPRは以下です。ギリギリワークショップの時間内に間に合いました🏃‍♂️

github.com

感想・今後の展望

楽しかったです!

今回のワークショップで実際にPRを出すところまでできて、OSS参加のハードルが少しだけ下がったように思います。
今回はREADMEを少し修正するというシンプルなPRでしたが、引き続きOSSに触れる中で何か気づくことがあればIssueやPRを立てていきたいですし、ゆくゆくはコードの中身を改善するようなコントリビュートもできたら良いなと思いました🚀

追記:マージされました🎉

ブログを公開した日の夜(PR提出の翌日)、無事マージされていることを確認しました😄

github.com

迅速に対応いただいてありがとうございます〜!!!

Insightsの方にもコントリビュートの履歴が残りました