Rubyの本がもっともっと増えてほしいので、下記のプロジェクト？に個人スポンサーのGoldプランで支援をしました🙌
完成を楽しみにしています😄
【フィヨルドブートキャンプ】チーム開発で、自分が欲しい機能を自分で作れてとても楽しかった
プログラミングスクールの フィヨルドブートキャンプ （以下、FBC）で学習中のsugiweです。
少し前の話になりますが、プラクティス「チーム開発」を修了しました。
（7月には修了していたのですがそこから自作サービス開発に入り、夢中になっている間に数ヶ月経ってしまいました汗）
今回はチーム開発の軽い振り返りと、自分が欲しい機能を自分で作ることができてとても楽しかったという話を書きます。
関連する話で、【フィヨルドブートキャンプ】チーム開発のgood first issueでモブプロをした話 という記事もありますので、よろしければご覧ください🙏
🔖 目次
- 🔖 目次
- 🧑🤝🧑 チーム開発とは？
- 💪 「自分でIssueを立てて自分で担当する」ということ
- ❤️ 特に気に入っている機能追加3選
- 🧑💻 プロダクト志向？
- 📝 担当PRとレビューさせていただいたPR
- 👋 おわりに
🧑🤝🧑 チーム開発とは？
一般用語で「チーム開発」と言えば文字通りチームで行う開発のことですが、ここでは、FBC終盤で取り組むプラクティス（課題）の1つを指します。FBC受講生が学習のために普段使っているEラーニング用Webアプリケーションの開発に参加し、自分たちが使っているアプリを自分たちで開発していきます。
チーム開発メンバーに加えてもらってからはプロダクトオーナー・スクラムマスターをされているメンターの方に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一覧の GitHubリンク）
❤️ 特に気に入っている機能追加3選
ここで、自分でIssueを立てて担当した中で特に気に入っている機能について幾つか紹介します。
企業一覧の各企業の「メンター」「アドバイザー」「現役生」の並びに「卒業生」が欲しい
bootcampアプリ内には、メンターさん・アドバイザーさんが所属している企業さんや、就職紹介先として提携していただいている企業さんなどを一覧で見られるページがあります。 これまでは、その企業に所属している「メンター」「アドバイザー」「現役生」の人数が表示されていたのですが、ここに「卒業生」も加えられるといいなと思いました。
フィヨルドブートキャンプはプログラミングスクールであり、どの企業でどれくらいの卒業生が活躍されているのかを一覧で見られることはとても価値があると考えました。というか、僕自身がどの企業にどれくらいの卒業生が在籍されているのを見たかったので、このIssueを立てました。
実装としてはとてもシンプルで、もともと卒業生側（というかユーザー側）の持つ情報として所属企業があったので、企業側でその数字をカウントして一覧側で出してあげる、というビューを追加するだけで実現できました。
この機能は今でもたまに自分で使っていて、実装はシンプルでも良い機能を追加できたなぁと思っています😄
現在のページURLをコピーするボタンが欲しい
僕はスマホでbootcampアプリを開いて他の受講生の日報などをチェックすることも多いです。 他の受講生の日報は自分にとっても学びになることが多く、「このページのURLをメモしておこう」と思うことも多いのですが、スマホ（PWA）でbootcampアプリを開いているとURLバーが出ないのでURLがわからない、という問題がありました。
そこで、URLコピーボタンを用意することでスマホで見ていても手軽に見ているページのURLをコピーできるようにしたいと思って立てたIssueです。
実装としては、レビューを経てJSのイベントリスナーを使って現在開いているページのURLをクリップボードにコピーできるようにしました。
日報提出お祝いメッセージの表示数を拡張したい
これは完全に自分のために作った機能です笑。
もともと過去に実装されていた機能として、「日報提出で1000回までのキリ番においてお祝いのメッセージを表示させる」というものがありました。コツコツ学習をして毎日日報を提出するなかで、たまにお祝いメッセージが表示されるのはとても嬉しいものです。
しかしこの機能に問題が発生しました。
卒業するにあたって、日報1000回を超える受講生が現れ始めました。僕です。
1000回以降、何もお祝いがなくなるというのが寂しくて、だったら自分で表示数の拡張をしようということでIssueを立てました。
実装としてはこれもシンプルで、上述した1000回目までの表示をするための機能追加の際にお祝いを表示するための回数を定数で定義してくださっていてそこに数字を追加するというのがメインでした。元の実装が非常にシンプルで機能追加しやすかったです。（machidaさんがめっっちゃ良い感じのお祝い画像をたくさん用意してくれました！！）
そして6月にめでたく、実装した僕自身が日報提出1100回目を迎えて、本番環境で正しく機能していることを確認できました🎉
#フィヨルドブートキャンプ の日報提出、1100日目まで来てしまった。
— 🌲sugiwe (@sugiwe) 2025年5月31日
すずかさんが1000日目までお祝いが出るように実装してくれていた機能を、僕自身が追加実装させてもらい今は1500まで出るようになっています。（5000回目まではさすがに作らなかった笑）
1200くらいで卒業したい😇#fjordbootcamp https://t.co/wpyqFBlgtG pic.twitter.com/PFhlu77Kb9
現在、僕以外にも日報1000回を超える受講生の方が出てきており、1000回目以降もキリ番でお祝いできる機能を追加できて良かったです。
〜〜〜〜〜
まとめてから気づきましたがこの3つは比較的シンプルに実装を進められたIssueだったと思います。進めるにあたって何もわからず数週間止まってしまったり、レビューで色々と修正が必要になったり、機能の一部を切り出してnpmとして公開したり、他にも大変だったIssueはたくさんあるのですが、ここでは紹介を割愛します。
🧑💻 プロダクト志向？
プロダクト志向・技術志向という言葉があります。
ものすごくざっくり言えば、「プロダクトを良くすることが第一目的で、その手段として技術を使って開発したいと考える人」か「プロダクトそのものというよりは、プログラミングの技術に対する興味が強い人」という違いになると思います。
明確にどちらか1つに決められるものでもないし、ましてやどちらが良いとかいう話でもないと思っていますが、チーム開発を経て、自分は「ユーザーとしてこのプロダクトがどうなっていると嬉しいか、どういう機能があると便利か」といったことを起点にしてIssueを立てるのが好きだなと感じましたし、それを自分自身で担当し実現できることにこの上ない喜びを感じるなと思いました。
技術を疎かにするつもりはありませんし、むしろやればやるほどもっと知識・スキルを高めたい気持ちが膨らんでいますが、根っこの部分では「プロダクトを良くしたい」という感情があることを自覚できたのは、チーム開発で得た大きな収穫だなと感じています。
📝 担当PRとレビューさせていただいたPR
最後におまけとして、僕が担当したIssue（PR）とレビューさせていただいたIssue（PR）の一覧を紹介します。
担当したIssueとそのPull Request
合計 : 21pt
レビューさせていただいたIssueとそのPull Request
チーム開発の大きな特徴として、メンバー同士の相互レビューがあります。
チーム開発までのプラクティスでは自分が書いたコードに対してメンターさんからレビューをしてもらっていましたが、ここで初めて他の人のコードを読んで自分がレビューをする側になるということになります。これがこのプラクティスのユニークな点で、開発現場に近い経験を積める、とても学びの多いプラクティスだと思います。
合計 : 27pt
まとめてみたら、担当Issueよりも多くのポイント数のレビューをさせていただいたことがわかりました。
これはプラクティスにかかる時間が長くなればなるほどレビュー依頼される回数も増えがちな性質があるからだと思います。色々な方のPRを見られるのは貴重な勉強のチャンスだと思います！
👋 おわりに
書きたいことは全部上で書いたので以上になりますが、冒頭に紹介した記事【フィヨルドブートキャンプ】チーム開発のgood first issueでモブプロをした話 のほうで、以下のように書いていました。
最後に余談となりますが、僕はチーム開発で「出来るだけ自分で立てたissueを担当する」という裏目標を掲げています。
（※チーム開発ではメンターさんからissueを割り振ってもらい取り組んでいきますが、issueは誰でも自由に立てることができます）
自分が立てたissueを担当するというのはメリット・デメリット両面あると思いますが、個人的には大きなやりがいを感じています。（毎日自分が使っているアプリで自分が欲しいと思った機能を自分で実装できるなんてサイコーだと思いませんか？）これについてはチーム開発のプラクティスが全て終わってから改めて別記事で書きたいと思っています🚀
10ヶ月を経てようやくこの伏線を回収できて、良かったです😄
（「メリット・デメリット両面ある」と書いてるけど、デメリットあったかな？もし仮に全部のIssueを自分で立てたもので担当していたら偏りが出ていたかもしれませんが、結果的に半々くらいになったので、自分で立ててないものでバグ修正やテスト修正、JSのMarkdown関連のIssueなどやらせていただけたので、バランス的にも良かったのではないかと思います）
OSS Gateオンラインワークショップに参加してOSSにPRを出した
先日、『OSS Gateオンラインワークショップ』というのに参加してきました！
勉強になったしとても楽しかったので、その振り返りを書きます🙌
きっかけ
僕が現在プログラミングを勉強しているフィヨルドブートキャンプで、前にこのワークショップとのコラボ企画を開催されていることがあり、OSS Gateさんの名前は認識していました。
そして最近、フィヨブー卒業生のハムさんがこのワークショップに参加されたのを見て改めて興味を持ったのと、次回開催でハムさんがサポーターとして参加されることを知ったので、自分も参加してみようと思いました。
OSS Gateワークショップ楽しかった〜☀️
— ハム ham-cap (@ham_cap93) 2025年6月14日
来月はサポーター枠で参加予定なので、OSS活動に興味のあるフィヨルド生の方もぜひ〜。#fjordbootcamp https://t.co/meLyh5BLXm
余談1
上記の前回開催ワークショップは6/14(土)でしたが、この日はフィヨルドブートキャンプ内でLT会があった日でした。 そのLTの中でとても感銘を受けたものがあり、その時の勢いで（まさにエイヤーで）即このワークショップに申し込みをした、という経緯があります。
きっかけを作ってくれたham-capさん、そしてhirokiej さんに感謝です🙏
余談2
土曜日の日中開催のため、参加するには家族の協力が不可欠になります。ソフトウェア開発のことは何も知らない家族にOSSのことを説明するにあたり、「ゲームのMODを修正・改善できるよう製作者に要望を出すみたいな感じ」という説明が刺さりました。
「MODを直すのは偉大だ、どんどんやれ」「私のやってるゲームのMOD直してくれない？」などと言われ、ニュアンスが伝わって良かったなと思いましたが実際MODを直すのは別の話なので無理だと伝えました😂
当日の流れ・学んだこと
当日の流れ
当日はざっくり以下のような流れでワークショップが進んでいきました。
1日で説明からOSS探しから実際のフィードバックまでやるということで間に合うのか結構心配でしたが、スムーズな進行で説明などもわかりやすく、また実際にフィードバック（PR作成）まで進めることができて良かったです！
学んだこと
ざざーっと箇条書きで書いていきます📝
- 一次資料（公式ドキュメント・開発リポジトリ）を参照する
- 誰かのブログ記事などに載っている方法を参照してうまくいってしまうと、コントリビュート（貢献）に繋がらなくなる
- 本来、ソフトウェアは一次情報だけで無理なく操作できるのが理想
- 一次情報で不足していたり誤っていることがあればそれを改善することで貢献できる
- 自分の「困った」を大切にする
- 「この不明点は、自分が初学者だからわからないだけなのでは…」と思わなくていい
- 自分が困ったら、同じ部分で困る人が他にもいるはず
- 「こうなっていたら自分は困らずに済む」という状態になるように改善要望を出す
- 開発者自身はドキュメントを見ずにできちゃうので、意外と気づかない。初学者のためにはこういう部分こそがコントリビュートチャンス
- Issueは丁寧に、PRはシンプルに
- Issueを出す場合は、とにかく丁寧に書く
- 自分の動作環境、何をしたのか、何をしてないのか、期待した結果がどうで実際の結果がどうだったのか等を、省略せずに書く
- PRを出す場合はコードが語ってくれる
- コードの差分によって何をしたいのかは明確なので、descriptionを長々と書く必要は無い（むしろ簡潔なほうが良い）
- Issueを出す場合は、とにかく丁寧に書く
- コントリビュートのお作法を確認する
- OSSではコントリビュートの手順などを指定されていることも多い。
CONTRIBUTING.mdやその他の部分で、コントリビュートの方法が書かれていないか確認する
- OSSではコントリビュートの手順などを指定されていることも多い。
- ライセンスを確認する
- ライセンスは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は以下です。ギリギリワークショップの時間内に間に合いました🏃♂️
感想・今後の展望
楽しかったです！
今回のワークショップで実際にPRを出すところまでできて、OSS参加のハードルが少しだけ下がったように思います。
今回はREADMEを少し修正するというシンプルなPRでしたが、引き続きOSSに触れる中で何か気づくことがあればIssueやPRを立てていきたいですし、ゆくゆくはコードの中身を改善するようなコントリビュートもできたら良いなと思いました🚀
追記：マージされました🎉
ブログを公開した日の夜（PR提出の翌日）、無事マージされていることを確認しました😄
迅速に対応いただいてありがとうございます〜！！！
Macの予測変換がおかしくなってきた時のリセット手順
突拍子もない変換をしてくるMacさん
Macで日本語入力している時、あまりに突拍子もない予測変換をしてくる時があります。気づけば笑って直すのですが、たまに長文を入力していて変な変換に気づかないまま後になって「なぜここにこんな無関係の言葉が！？」となるケースもあります。
あと、画面共有で自分の画面を他者に見せている時に突拍子もない予測変換が出ると、なんかちょっと恥ずかしい😇
Macさんが謎の学習をしていることが原因のようで、リセットをすれば直ります。
前にも何度か対応したことがあったのですが毎回忘れるので、備忘録として手順を残しておきます。
謎の変換をリセットするための手順
①Mac左上画面のアップルアイコンから「システム設定…」をクリック
②システム設定ウィンドウの左メニュー「キーボード」を選んで、スクロールして下の方に出てくる「テキスト入力」「入力リソース」の「編集…」をクリック
③左メニュー「日本語 - ローマ字入力」を選んで、スクロールして下の方に出てくる変換学習の「リセット…」をクリック
④確認ダイアログが出るので、そのまま「リセット」をクリック
これで謎の変換がされなくなりました。
これまでの経験から、またしばらくすると出てくると思うのですが、この学習自体ストップできないのかな？
隠しファイル／隠しディレクトリをgitignoreする2つの方法
👻 気づくとそこにいる隠しファイル
GitHubを使って複数人で開発作業をしていると、たまに「おみゃーさん、いつどこで入ってきたんだがね？（愛知弁）」というファイルがコミットに紛れ込んでくることがあります。
代表的なものは.DS_Storeなどです。
.DS_StoreはMac固有の隠しファイルで、いろんなフォルダに実は潜んでいます🥷
個人的には、デザイン業務とかで写真のやり取りをするときにzip圧縮したり他の人にファイルを送ったりするといつの間にか可視化されているという経験は幾度となくありました。
他にはWindows固有のファイルであるThumbs.dbや（これは「隠し」ファイルではないか？）、あとは.vscodeのようなエディタ固有の隠しディレクトリもあります。
👋 隠しファイルはGit管理対象外へ
こういった隠しファイル系はリポジトリ内には不要なものなので、Gitの管理対象外にしてしまうのが手っ取り早いです。
Git管理対象外にするといえばgitignore。方針としては大きく2つあるようです。
今回は自身の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 ファイルへ次の内容を書き込んで、（以下略）
昔の僕が、これを参照して設定をしたのかもしれません。（繰り返しますが、何も覚えていない😇）
🚚 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つ減ったのも何気に嬉しいポイントでした✨
🔬 参考記事
この記事を書くにあたって、以下の記事を参考にさせていただきました🙏
おまけ
この話は続きがあるかもしれず、続きができたらまた別の記事で書きます🚀
『フィヨブーファンブック Vol.1』が作られると聞いて表紙・原稿・イラストでフルコース参加させてもらいました
まずは…
入稿おめでとうございますー！🎉🎉🎉
入稿できました！やった！！！
— かわかみ@6/1技術書典18（し14） (@kota_syan) 2025年5月27日
フィヨブーファンブック部 | フィヨブーファンブック Vol.1 #技術書典 #fjordbootcamp https://t.co/CjvXfDYTsf
色々参加させてもらいました
ということでタイトルの通りですが、僕がプログラミングを勉強しているオンラインスクールの『フィヨルドブートキャンプ（略称FBC、通称フィヨブー）』のファンブックが作られるということで何かしたいなぁと思って色々と関わらせていただきました！
経緯などは主催のかわかみさんのブログに詳しく書かれているので是非ご覧ください。かわかみさんのパワー、めちゃ凄いです。
フィヨブーファンブック、原稿募集中です！！！
— かわかみ@6/1技術書典18（し14） (@kota_syan) 2025年3月15日
フィヨブー関係者の皆さま、どうぞよろしくお願いします！
フィヨブーファンブック、はじめました！（原稿募集のお知らせ） - asya81のブログ https://t.co/u8e7509maB#はてなブログ #fjordbootcamp #フィヨブー #技術書典 #ファンブック
僕は文章を書くのが割と好きなほうなので（毎日日記を書くくらいには好き）、とりあえず原稿は絶対に書かないとなーと思い、軽い気持ちで応募表明しました。
まぁアドベントカレンダーを春にも書くと思えばなんとかなるでしょう。
なんか面白そうなので軽い気持ちで原稿応募表明しました〜
— 🌲sugiwe (@sugiwe) 2025年3月15日
ファンブックのお作法を何も知らないので、とりあえず本文中にあった「うなすけファンブック」と「桐生あんずファンブック」のダウンロード版を買いました。
https://t.co/D2nPyW7InJ#fjordbootcamp
そして、原稿だけで飽き足らずほかにも何かお手伝いできないかな？と思い、表紙のタイトル文字とか作りたいなぁと思ってかわかみさんに雑に相談してみました。
その後、輪読会などでもめっちゃお世話になっているFBC仲間の ayu さんが表紙イラストを描かれることなどをお聞きして、ayuさんにご用意いただいたイラストをもとに表紙と裏表紙をまるっと作らせてもらうことになりました✨
また、表紙の企画を考える中で「ピヨルドくんのイラストを募集しよう」というアイデアも出て、めちゃくちゃ絵が下手な僕ですがこの企画にも参加しました。
なので「表紙・裏表紙のレイアウト」「原稿」「ピヨルドくんイラスト」とかなりのフルコースでフィヨブーファンブックに関わらせていただくことができました。
あ〜楽しかった。
表紙について
記事冒頭のエックス投稿貼り付けで表紙は見えていると思いますが改めて。
いや〜めっちゃ良いイラストですね。祝祭感がすごい。
タイトル文字、初めはオリジナルで作字というかロゴみたいなものを考えたいなと思っていたんですが、時間がなくて ayuさんの素敵なイラストの仕上がりを見て、考えを改めました。変に個性的なタイトル文字にするよりも、イラストの雰囲気に溶け込みながらもタイトルとしてしっかり主張できるようなタイトルにしようということで、既存フォントを調整して作っていく方向に舵を切りました。形になってみて、その方向にして良かったなと思っています。
タイトルの色についても、フィヨブーのブランドカラー（パープル寄りのネイビー）とRubyカラー（レッド）をイラストとマッチするようにそれぞれ少し明るめに調整して使いました。
中身について
中身については手に取っていただいてのお楽しみ、ということであまり詳しくは書けないのですが、僕は「なかなか卒業できないけどコツコツ楽しく頑張ってまっせ」みたいなことを書きました。
（チャッピーことChatGPTに添削をしてもらったんですが、チャッピーは何を書いても「最高です！」「完璧です🎉」とばかり言ってくれるので笑、自己肯定感はアップしましたが添削の意味はあまり無く、結局書いては消してを繰り返して仕上げていきました）
冊子は全88ページで、想像していたよりも数倍ボリュームがあり驚いています。
お手伝いの役得ですでに原稿などチラ見しているのですが、めちゃくちゃ良いです。現役生・卒業生・顧問・メンター・アドバイザーなど様々な立場の人からの原稿が集まってその数なんと約25！ほんとにアドベントカレンダーが1つできちゃう数です🎄
どこで手に入るの？
ということでもうすぐ完成する『フィヨブーファンブック Vol.1』ですが、今週末に開催される技術書典というイベントで購入することができます。
（オフライン開催が6/1日曜11:00～17:00で、オンライン上は5/31土曜〜6/15日曜）
技術書典は、ITや機械工作とその周辺領域について書いた本を対象にした同人誌即売会。 技術者たちの「コミケ」とも言われる。 Wikipediaより
残念なことに僕は当日会場に行けないのですが、会場に行かれる方はもちろん、行かない方もよろしければ以下のページなどご覧くださいませ！
多分オンラインでも買えるようになる、はず？（よくわかってない）
（5/30 17:00追記：オンラインで購入できるようになってました！！！）
おわりに
改めて主催のかわかみさん、アドバイザーの桐生あんずさん、ありがとうございました！ そしてayuさん、素敵なイラストをありがとうございました！一緒に表紙を作れて楽しかったです〜✨
アドバイザーとして関わってくださりガッツリ書籍のDTPも担当された桐生あんずさんの記事も紹介いたします。
git rebase -i でコミットの歴史を改変したのでメモ
GitHubのリモートリポジトリにプッシュをした後でいくつか作業漏れが発覚して、本来1つのコミットに入れたかった修正内容が複数のコミットに分かれてしまいました。
そのままでも良いケースもあると思いますが、今回は1つに整理しておきたかったので、複数に分かれたコミットを後から1つにまとめるためにgit rebase -iを使いました。
その時のメモです📝
手順
前提として、今回の作業は「直近5つのコミットを1つにまとめる」です。
ローカル
まずは手元でコミットを綺麗にする。
git rebase -i HEAD~5を実行、VSCodeのエディタ側で編集画面が開く
（VSCodeでコミットメッセージを編集する設定にしていることによるもの。通常であればvimでの設定になると思います）
以下スクショの通り、まとめたい分（つまりコミットとしては消える分）を全部squashにする
（vimであれば、編集し終わったら:wqで保存して閉じる）
（ちなみに、確認はできてないのですがおそらくvimだと時系列が逆で最新が一番上になっているかもしれないので、どれをsquashにするかはご注意）
保存して閉じる。
するとまたVSCodeで別の編集画面が開く （これもVSCodeでコミットメッセージを編集する設定にしていることによる）
上記の2〜5の分を丸っと消して、以下の状態で保存して閉じる。
# This is a combination of 5 commits. # This is the 1st commit message: ここに、最終的に残すコミットメッセージ # Please enter the commit message for your changes. Lines starting # 以下略
これでローカルでのコミットが整理されました！
git log --onelineで、コミットが1になったことを確認しておくと安心です。
リモート
続いてリモートに反映させるために、force pushをしていく。
% git push --force # 今回はプッシュのタイミング的に上記だけでは自動的にプッシュしてくれなかったので、以下のコマンドでプッシュしました % git push --set-upstream origin hotfix/fix-regular-event-ended-logic
これで5つに分散していたコミットが1つにまとまりました🎉
終わりに
履歴が綺麗になって良かったです。
ただし、force pushしたこと自体は履歴に残りますし何でもかんでもまとめれば良いってわけでもないと思うので、使い所に気をつけながら活用していこうと思います🚀
