ソーシャルフィードリーダー「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回目を迎えて、本番環境で正しく機能していることを確認できました🎉

#フィヨルドブートキャンプ の日報提出、1100日目まで来てしまった。
すずかさんが1000日目までお祝いが出るように実装してくれていた機能を、僕自身が追加実装させてもらい今は1500まで出るようになっています。（5000回目まではさすがに作らなかった笑）
1200くらいで卒業したい😇#fjordbootcamp https://t.co/wpyqFBlgtG pic.twitter.com/PFhlu77Kb9

— 🌲sugiwe (@sugiwe) 2025年5月31日

現在、僕以外にも日報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さんの名前は認識していました。

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

OSS Gateワークショップ楽しかった〜☀️
来月はサポーター枠で参加予定なので、OSS活動に興味のあるフィヨルド生の方もぜひ〜。#fjordbootcamp https://t.co/meLyh5BLXm

— ハム ham-cap (@ham_cap93) 2025年6月14日

余談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の方にもコントリビュートの履歴が残りました

Macの予測変換がおかしくなってきた時のリセット手順

突拍子もない変換をしてくるMacさん

Macで日本語入力している時、あまりに突拍子もない予測変換をしてくる時があります。気づけば笑って直すのですが、たまに長文を入力していて変な変換に気づかないまま後になって「なぜここにこんな無関係の言葉が！？」となるケースもあります。
あと、画面共有で自分の画面を他者に見せている時に突拍子もない予測変換が出ると、なんかちょっと恥ずかしい😇

Macさんが謎の学習をしていることが原因のようで、リセットをすれば直ります。
前にも何度か対応したことがあったのですが毎回忘れるので、備忘録として手順を残しておきます。

謎の変換をリセットするための手順

①Mac左上画面のアップルアイコンから「システム設定…」をクリック

②システム設定ウィンドウの左メニュー「キーボード」を選んで、スクロールして下の方に出てくる「テキスト入力」「入力リソース」の「編集…」をクリック

③左メニュー「日本語 - ローマ字入力」を選んで、スクロールして下の方に出てくる変換学習の「リセット…」をクリック

④確認ダイアログが出るので、そのまま「リセット」をクリック

これで謎の変換がされなくなりました。

これまでの経験から、またしばらくすると出てくると思うのですが、この学習自体ストップできないのかな？

隠しファイル／隠しディレクトリをgitignoreする2つの方法

👻 気づくとそこにいる隠しファイル

GitHubを使って複数人で開発作業をしていると、たまに「おみゃーさん、いつどこで入ってきたんだがね？（愛知弁）」というファイルがコミットに紛れ込んでくることがあります。

代表的なものは.DS_Storeなどです。

.DS_StoreはMac固有の隠しファイルで、いろんなフォルダに実は潜んでいます🥷
個人的には、デザイン業務とかで写真のやり取りをするときにzip圧縮したり他の人にファイルを送ったりするといつの間にか可視化されているという経験は幾度となくありました。

他にはWindows固有のファイルであるThumbs.dbや（これは「隠し」ファイルではないか？）、あとは.vscodeのようなエディタ固有の隠しディレクトリもあります。

👋 隠しファイルはGit管理対象外へ

こういった隠しファイル系はリポジトリ内には不要なものなので、Gitの管理対象外にしてしまうのが手っ取り早いです。

Git管理対象外にするといえばgitignore。方針としては大きく2つあるようです。

1. リポジトリ内の.gitignoreファイルに追記する（.gitignoreがなければ新規作成する）
2. 自身のMacでグローバルなgitignore設定をする
   • マシン固有の隠しファイルは、リポジトリ側でなく自身のMacで設定するほうが良さそう

今回は自身のMacの方の設定の話です。

自分はどうだっけと思って調べたら、ユーザーディレクトリ直下（/Users/myname/）に.gitignore_globalというグローバル設定用のファイルがあり、その中にすでに.DS_Storeの記述がありました。自分で入れたんだっけ、何も覚えていない…😇

📁 gitignoreのスタンダードな置き場所

少し調べてみたところ、gitignoreを設定する場所としてデフォルトは別にあるようです。

Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead.
Git - gitignore Documentation

上記によると、~/.config/git/ignore内がデフォルト値とのことです。

一方、日本語訳もある8.1 Git のカスタマイズ - Git の設定 の方でガッツリ~/.gitignore_globalというのが出てきます。

このような設定を行うには、グローバルな .gitignore のようなファイルが必要です。 ~/.gitignore_global ファイルへ次の内容を書き込んで、（以下略）

Git - Git の設定

昔の僕が、これを参照して設定をしたのかもしれません。（繰り返しますが、何も覚えていない😇）

🚚 gitignore置き場のお引越し

上の記事内で書かれているように、今の~/.config/git/ignoreのままでも問題はないようなのですが、せっかく今回デフォルト値を知ったので場所を移すことにしました。

# 必要なディレクトリを作成（-pオプションで、すでにディレクトリがあってもエラーにならないようにしている）
mkdir -p ~/.config/git

# 元々あった.gitignore_globalをリネームしてさらに移動
mv ~/.gitignore_global ~/.config/git/ignore

# 新しく設置した方のファイルをグローバルなgitignoreとして使うように変更するコマンド
git config --global core.excludesFile ~/.config/git/ignore

これによりユーザーディレクトリ直下にあった.gitignore_globalファイルは無くなりました。
ユーザーディレクトリ直下は煩雑になりがち（というかなっている）なので、ファイルが1つ減ったのも何気に嬉しいポイントでした✨

🔬 参考記事

この記事を書くにあたって、以下の記事を参考にさせていただきました🙏

zenn.dev

zenn.dev

おまけ

この話は続きがあるかもしれず、続きができたらまた別の記事で書きます🚀