すずかのプログラミング勉強記

元教員からエンジニアを目指す、プログラミング勉強記録です。

【リリースから約2年】山手線徒歩一周記録アプリ「YamaNotes」の今までとこれから

Rails Ruby

はじめに

2024年の6月に「YamaNotes」をリリースして、2年弱が経ちました🚃 想像以上にたくさんの方に使っていただき、大変感謝しております。

ファーストリリース後に追加した機能や、リリース後の振り返りを書いていきます！

YamaNotesとは

山手線を徒歩で一周する人のための記録アプリです。詳しくは以下をご確認ください。

現在のYamaNotesの状況

リリースから2年弱で、約4,000名*1の方にご登録いただきました。 その中でYamaNotesを使用して一周を達成された方は、約900名*2のようでした。

使ってくれた方が、Xの「#山手線を徒歩で一周」や個人のブログで言及してくださるのを見て、開発の励みになっています。

最近実装した機能

ゆっくりではありますが、ファーストリリース後に新機能追加・細かい改善を行ってきました。

特筆したいものを書きます。

2週目以降の挑戦も記録する機能（リピーター用）

ファーストリリース時にはスピード重視で実装したため、「ユーザー1人につき1回しか記録できない」状態にしていました。先日修正し、前の記録を削除せず、複数回記録ができるようにしました。

メニューの「歩行記録の一覧」から、過去の記録を確認できます

実装にあたっては、has_one関連付けで作ってしまったものを、ユーザーへの影響なくhas_manyに変更するのが大変でした。

画像アップロード機能

「山手線徒歩一周」で検索すると、到着駅・画像・文章のセットで記録しているブログが多数存在しますが、そのような記録をYamaNotesだけで完結できるようにしました。

（現在ベータ版としてリリースしていますので、使用の際は編集画面に表示される注意をご確認ください）

画像付き記録の例：https://www.yamanotes.com/public/walks/4761/arrivals

開発にあたっては、ストレージにCloudflare R2を使用し、維持費を最小限（現在は0円）に抑える工夫をしました。また、画像添付のUIを色々なサービスを参考に検討したり、アップロードの待ち時間を減らすための調査を行なったりしたのが勉強になりました。

多言語対応

日本語がわからない方にも使ってもらえたら良いなと思い、英語版に切り替えられるようにしました。

フッターから英語/日本語を切り替えられます

こちらについては、英語版のSEO対策や説明記事の作成などをまだ着手できていないため、より多くの方に使っていただけるよう、英語版の周知や改善に取り組んでいきたいです。

バグ報告・要望フォームの設置

エラーを開発者に通知する仕組み（Sentry）は導入済みですが、開発者が気づかないバグの可能性も考え、フッターにフィードバックフォームへのリンクを設置しました。

YamaNotes バグ報告・ご要望・ご感想フォーム

お気づきの点があれば、お知らせいただけると大変助かります🙇‍♀️

今後やりたいこと

ファーストリリース時にやりたいと思っていたことの実装は全て終わったのですが、まだまだやりたいことは沢山あります。

山手線徒歩一周の知見を共有できる機能を作る

山手線徒歩一周には、持ち物やスケジュールなど、事前の調査が重要だと思っています。

YamaNotesのユーザーの中には、知見をお持ちの方がたくさんいると思うので、情報交換ができる掲示板のようなものを作れたら良いなと思っています！

休憩・中断機能を作る

時間や体力の都合で、数日に分けて挑戦する方を見かけることがあります。しかし現在、日をまたいで歩いた場合、YamaNotesの経過時間の表示がおかしくなってしまいます🥲

ゴールまでの経過時間にカウントされない「休憩・中断時間」を記録できるようにする機能を作り、数日間で歩いた方にも便利に使えるようにしたいです。

維持費をまかなえる程度の収益を得る

現在YamaNotesの維持費は、ドメイン代（年間2,172円）のみがかかっています。 今のところは大きな負担になっていませんが、今後ユーザー数が増えた場合、DBや地図のAPI・ストレージなどの料金がかかってくる恐れがあります💸

まずは月に200円程度の収益を得られるよう、方法を考え中です💭

現在の開発者の状況

私事ですが、現在第一子を妊娠中で産休をいただいております。お休みの間は、出産準備をしつつも、YamaNotesの開発にも時間を充てることができました🙏

妊娠中は山手線徒歩一周に挑戦することができず、出産後も育児が落ち着くまで挑戦は難しくなると思います。しばらくは、山手線ウォーカーの皆様を陰ながら支えられるよう、引き続きYamaNotesの開発を頑張ります！

おわりに

リリースから現在に至るまで、YamaNotesの開発を通して、個人開発の楽しさやRailsの素晴らしさを日々感じています。使ってくださった方・開発を応援してくださった方に改めて感謝いたします。

今後もサービスを維持・改善できるよう努力しますので、これからもよろしくお願いします！

*1:2026/05/01現在、3,903名：歩行記録の有無に関わらず、Googleログインで登録し、現在退会していない方をカウントしています。

*2:2026/05/01現在、916名：到着記録が山手線の駅数（30駅）存在する方の数をカウントしています。

RubyGoldに合格しました

お久しぶりです！ 期間がすっかり空いてしまいましたが、おかげさまで元気に過ごしております🙇‍♀️

先日Ruby技術者認定試験Goldを受験し、94点で合格しました。 感想と振り返りを書いていきます。

自己紹介

すずかと申します。
FJORD BOOT CAMPでRubyを勉強した後、教育系の企業に就職し、Railsのエンジニアとして1年半ほど働いております。

RubySilverを受験したのは約2年半前です。Silverについて興味がある方は、以下をご覧ください。
Ruby Silverに合格しました！ - すずかのプログラミング勉強記

受験理由

Rubyの知識をもっと増やしたいと思ったからです。
就職後しばらく経ち、仕事に多少慣れてきたものの、日々の実装・レビューでRubyの文法・オブジェクト指向などの知識不足を感じることが多かったです。

資格勉強がそのままRailsの実務に結びつくわけではないとは分かっていましたが、技術力向上のために受験することにしました。

勉強方法

勉強期間は2ヶ月ぐらいで、平日は毎日30分・土日は都合の良い日のみ2~3時間勉強しました。
正確に記録はしていませんが、トータルの勉強時間は30~40時間程度だったと思います。

使った教材

沢山の方がブログに書いている内容と同じですが、使った教材は以下のとおりです。
（並行で進めていたものもありますが、おおむね学習順に挙げています）

  1. Rex
    いきなり本を読むのが苦手だったので、まずは演習から始めました。 初めて解いた時は約6割ぐらいの点数で、9割取れるようになるまで繰り返しました。
  2. メタプログラミングRuby 第2版
    1~5章を一度読みました。私にとっては結構難しく、理解度は半分ぐらいでした。
    普段何気なく書いているコードの仕組みを知ることができ、面白かったです！
  3. Ruby技術者認定試験Gold模擬問題
    公式の模擬問題です。本番までに3周しました。
  4. 最短突破 Ruby技術者認定試験（Silver/Gold対応⁠）⁠ 公式テキスト
    ・教材：
    Silverの範囲も含め、全体にざっくり目を通しました。演習で理解不足だった箇所の、点と点がつながるような感じがして、勉強になりました。
    ・基礎問題・模擬問題：
    試験当日までに3周ずつ解きました。Rexをある程度解いていても1回目は6~7割の点数で、合格点を越えられなかったです。
    一問だけ模擬問題の解答に誤りがあるので、正誤表を確認しましょう。（私はしばらく気づかず混乱しました）
  5. AIに作らせた模擬問題
    無料版のNotebookLMを使用して、自分の学習メモなどのソースを追加しました。
    「クイズ」機能を使うと問題を作ってくれるので、公式テキストやirbで確認しながら解きました。
  6. 先人達のブログ
    「RubyGold」で検索して出てきたものには、ほぼ全て目を通しました。
    特にお世話になったブログを2つ紹介します。
    ・ Ruby Gold 3.1の対策と出題傾向について(2022年11月) #試験 - Qiita
    ・ Ruby Gold 試験範囲を一気に見直す - 気軽に楽しくプログラムと遊ぶ

これから受験する方へ

本番の試験は、Rex・公式の問題・⁠ 公式テキストの基礎問題/模擬問題からの出題が多いので、確実に理解しておくことが必須だと思います。
解答の理由を自分の言葉で説明できるようにしておくのも、重要だと感じました。

試験当日の流れ

  • 会場に行く。
    集合時間の15分前までに行かないと受験できないので、気をつけましょう。
  • パソコンルームに移動する。
    ロッカーキー・メモ用紙 / 筆記用具（会場で貸し出し有）以外は全て置いていきます。 私の受験した会場では、ティッシュ・目薬は許可を取れば持ち込めたようです。
  • ボタンを押して試験を開始する。
    本番のCBT試験は、「一つ選択」の指示がある問題は一つしか解答を選択できないようになっていました。 問題の最後に数問アンケートがついています。
  • 終わったら終了ボタンをクリックする。
    直後に受験結果が出ます。

受験した感想

  • 見直しも含めると、時間が余らなかったです。
    Silverの時は時間前に終わらせた記憶がありますが、Goldは90分目一杯使って見直しをしました。
  • 問題集などで全く見たことがない問題が数問出題され、焦りました。
    個人的な感想ですが、以下のような比率だったと思います。
    • 見たことがある問題からそのままの出題：2割位
    • 見たことがある問題の発展で、落ち着いて考えれば解ける問題：6割位
    • 問題集にない初見の問題 / 解答に迷う問題：2割位
  • 手応え以上の点数が取れていて驚きました。
    「85%位取れていれば嬉しいな」位の手応えでした。勘が冴えて、自信がない問題がたまたま当たっていたのだと思います。

妊娠中の受験について

RubyGoldの受験時は妊娠8ヶ月だったため、妊娠中の受験についても書いておきます。

当初は妊娠中に別の資格試験（応用情報技術者試験）を受けようと勉強していたのですが、つわりの時期と重なり、受験ができませんでした。

RubyGoldは以下の理由で、無理なく受けられました。

  • 直前まで日程変更・キャンセルができる。※受験時点
    私の場合は4日前まで変更可能でした。
  • 試験時間が比較的短い（90分）
  • 申込時に自宅から近い会場を選べる。

妊娠中の受験の注意点としては、無理ない勉強計画を立てることと、体調が悪かったら無理せずキャンセルすることです。
同じように妊娠中の資格取得を考えている方がいましたら、RubyGoldはおすすめです！

終わりに

RubyGoldの受験を通して、普段意識しないRubyの仕組みを学ぶことができ、楽しく勉強ができました。

合格はしましたが、まだRubyについて知らないことが沢山あるので、今後も頑張ろうと思います！

エンジニアになって気づいたら半年経っていた

勉強の振り返り 自分のこと

ご無沙汰しています、だいぶ久しぶりの記事更新になってしまいました🙇‍♀️

半年ブログを更新していませんでしたが、元気に過ごしておりますので、まとめて振り返りを書いていきます！

仕事のこと

7/1にRailsエンジニアになって、約半年経過しました。 この間にやっていたことを簡単に書いていきます。

1~2ヶ月目

  • 2週間ほどの研修後に開発に入りました。
  • ラッキーなことに同日入社の方がいたので、質問しやすくて助かりました。
  • 研修後は、先輩のお手伝いから徐々に開発に入っていきました。レビューがとても丁寧で、PRにコメントがたくさんついて驚きました。
  • お問い合わせやエラー通知の調査をやり始めましたが、全くできず、何度もペアプロをやってもらっていました。

3~4ヶ月目

  • 少し大きめの機能の開発にも関わるようになりました。
  • 過去のコミットを確認する機会が増えて、コミットメッセージに実装の背景を書くことの重要性を感じました。
  • 学習期間にRSpecは少しは勉強していましたが、実際のプロダクトのテストコードは複雑で、書くのも読むのも苦戦しました。

5~6ヶ月目

  • 新規機能の開発を数名で進めており、先輩のサポートのもと実装中です。
  • 少しずつ上流工程にも関わるようになり、まだ目に見えない機能について、色々なケースを想定するのに苦戦しました。
  • 何もないところから、どんどん機能ができていくのが面白いです。

半年間働いた感想

  • とりあえず仕事は楽しい

大変なこともありますが、毎日楽しく働いています。月曜日を苦痛に感じたことはまだ一度もないです。 年末年始は暇すぎるので、もっとお休みが短くてもいいのではと感じているくらいです。

  • 成長は感じるものの、エンジニアとしての力不足を感じる

自分が何時間も悩んで解決できなかったことを、先輩が一瞬で解決しているのを見ると、知識も経験も全く足りていないことを感じます。 焦ってもどうにかなるわけではないので、地道に勉強と経験を積み重ねていきたいと思います。

  • 先輩がみんな穏やかで優しい

半年間で、ここには書ききれないほど色々失敗していますが、根気強く教えてくれる先輩に感謝です🙇‍♀️
例：
・ 確認不足から、大きな手戻りが発生してしまった。
・ いい加減なドキュメントを作っていて、見た人を巻き込んでしまった。
・ デプロイできないと騒いだけど、コマンドが間違っていただけだった。

自分も見習って、良いコミュニケーションを取れるようにしていきたいです。

  • 教員経験をもっと活かせるようになりたい

会社では学校関係のプロダクトを作っています。
コミュニケーションやマインドの部分では、教員経験がプラスに感じることが多数あります。ただ、開発に直接活かすには、もう少し勉強が必要だと感じるので、ITの勉強や教育現場の情報収集をしていきたいです。

勉強や開発のこと

仕事以外の勉強は、YamaNotesの開発と資格の勉強を中心にしていました。

YamaNotes開発

リリース後にも開発を続けていて、半年間で以下のような作業を行いました。使ってくれる人がいるので、とても楽しいです。

  • デプロイ先を変更して速度を改善する
  • メモでリンクを貼れるようにした
  • 到着画面に駅別のイラストを追加する
  • 出発画面をわかりやすくした
  • RubyやRailsのバージョンアップをする

現在実装中の機能としては、「複数回記録機能を作る」ことです。こちらはモデルの関連付けを修正する必要があり、なかなか進まず苦戦しています。（ここまで想定して設計しなかったことに後悔😭）

基本情報の勉強

8月ごろから勉強を開始して、細々続けています。 年末年始で全力で勉強を進めて、年明けの合格を目指しています。

輪読会参加

FBC内の現場で使える Ruby on Rails 5速習実践ガイドの輪読会に参加しています。ゆっくり読んでいるので、一年ほど経過しました。
最近は「源氏物語」を読むのにハマってしまい、輪読会以外で技術書をあまり読んでいません。来年はもう少し読みたいです😰

コミュニティのこと

定期的に開催しているUrawa.rbに加えて、以下のイベントに参加しました。

さくらのマイクロコミュニティで発表

個人開発に興味がある方のイベントで、YamaNotesの開発方法や設計などについてお話ししました。 外部のLT登壇が初めてでしたが、他の個人開発をされている方のお話を聞くことができて、とても勉強になりました！
資料：YamaNotesの開発について - Speaker Deck

TokyuRuby会議15で発表

飲み食いをしながら楽しくLTをするイベントで、YamaNotesのパフォーマンス改善についてお話ししました。 なんとLT王に選んでいただき、Rubyコミュニティのあたたかさを感じました🙇‍♀️
資料：山手線一周のパフォーマンス改善 - Speaker Deck

Kaigi on Rails 2024の運営側で参加

オーガナイザーとして、初めてカンファレンスの運営側に関わり、貴重な経験ができました。 FBCでLTの機会をいただいて、感想を発表しましたので、ご興味がある方は、ご覧ください。
資料：初✖️3 Kaigi on Rails 2024の思い出 - Speaker Deck

冬以降はプライベートがバタバタしていて、あまりコミュニティに参加できませんでした💦
来年1月には、Urawa.rb #11があったり、東京Ruby会議12に参加する予定なので、参加予定の方はよろしくお願いします！

アウトプットのこと

半年間、ブログは全く書けませんでした。無職時代と同じ頻度は無理だとしても、来年はもう少し書きたいと思っています😭

ブログはダメでしたが、LTは5回（FBC1回、外部2回、社内発表会2回）行いました。
社内発表では、アセットパイプラインについてと、has_one関連付けについてについて発表し、先輩方から色々教えてもらって勉強になりました✨

プライベートのこと

常にバタバタで、落ち着いている瞬間がほぼない半年間だったなと思います😅

半年間で2回引っ越した

家庭の事情で、埼玉（浦和）→ 東京（自由が丘） → 埼玉（大宮）と引越しをしました。 引越し作業が大変＆お金もかかりましたが、いらない荷物が片付いたのはよかったです😅

部屋を整えた

引越しで部屋数が増えたので、家具も増やしました。 会社が導入しているレンタルサービスを使って、モニターやデスク・椅子・コーヒーメーカーなどを借りています。（会社の福利厚生のため全部無料で嬉しいです）
最近は、もっと部屋を綺麗にするための捨て活にハマっています。

新婚旅行の準備中

結婚したのは3年前ですが、コロナや退職で行けなかったため、一月末に改めてハワイに行こうとしています☀️
旅行の予約やパスポートの更新などをしていて、ワクワクです！

まとめ

振り返ると色々反省点はありますが、大きく体調を崩すこともなく、元気に過ごすことができました✨
自己評価は100点ではないけれど、ギリ合格点の過ごし方はできたのではないかなと思います。

2025年は、今年できなかったことを色々頑張りたいので、皆様よろしくお願いします！

未経験からフィヨルドブートキャンプを卒業して、エンジニアになりました！

はじめに

6月半ばに自作サービスのリリースをもって、フィヨルドブートキャンプ（以下FBC）を卒業しました。
加えて並行して行なっていた就職活動で、第一志望の企業より内定をいただくことができ、7/1よりWebエンジニアとして働きはじめました。

この記事では、FBCでの生活や就職活動の振り返りを書きます。
FBCに入会を検討している方、現在学習中の方に読んでいただけると嬉しいです。

自己紹介

すずかと申します。

前職では高校の国語の教員をしていましたが、2023年3月に退職しました。その後、FBCで1年2ヶ月間勉強し、先日最後のカリキュラムを終えて卒業しました。

フィヨルドブートキャンプとは？

「現場の即戦力となれる」オンラインのプログラミングスクールです。
詳しくは公式サイトをご覧ください。 bootcamp.fjord.jp

入会まで

入会時の状況

新卒から5年間働いた、高校教員を退職した直後でした。

退職理由は、月45~100時間程度の残業があり、健康に働き続けることが難しいと思ったからです。 教員の仕事自体は好きだったので、次に何を目指せばいいのか分からずに悩んでいました。

FBCに入った理由

前職では情報管理部という部署に所属しており、学校業務支援システムの管理や、生徒用タブレットの選定などの仕事をしていました。そのため、学校のデジタル化やICT教育の分野に強い関心を持っていました。

加えて、夫がWebエンジニアとして楽しそうに働いていたことから、プログラミングに興味がありました。
退職後に何をしようか考える中で、夫からFBCを強くすすめられ、入会しました。

プログラミング歴

大学は文系学部出身、IT関係の企業に勤めた経験もなく、プログラミングの知識はほぼゼロでした。

以下のような知識レベルです：

  • ターミナルを立ち上げたことがない。
  • 「GitHub」や「Linux」の存在はもちろん知らない。
  • 「Ruby」と「Rails」の違いがわからない。
  • Macの使い方すらよくわからない。
  • 独学でVBAを勉強して、挫折した経験がある。
  • ProgateでHTML・CSSをちょっとやった。

卒業までにかかった期間

期間は約1年2ヶ月で、学習時間は2636時間でした。（最後の方は就活と並行していたので、色が薄いです）

他の卒業生と比べると、期間は平均的、学習時間は長めかなと思います。

ちなみにこの期間の生活費は、夫婦共通のものは夫が多めに払ってくれて、不足分や私個人の出費（FBCの受講料など）は教員時代の貯金を使いました。
税金や保険の手続きなどで後悔したことも多いので、無職期間の家計管理について気になる方はお声がけください😅

カリキュラムについて

FBCのカリキュラムはざっくり分けると、基礎的なインプット期間→チーム開発→自作サービスに分かれています。
以下に、インプットのカリキュラムの中で特に印象に残ったものを挙げます。

より詳しいカリキュラムについては、こちらからご確認ください。
学習内容 | FJORD BOOT CAMP（フィヨルドブートキャンプ）

Linux

入学して最初の関門でした。
Linuxの本を読んで基本的なコマンドについて勉強した後、VPSサービスで用意したサーバーにLinuxをインストールして、SSH接続を行います。黒い画面で見慣れない英語がたくさん出てきて、仰天した記憶があります。

Ruby

Rubyに関する書籍を二冊を読んだ後、ボウリングのスコア計算プログラムやlsコマンドなどを作り、レビューをもらいます。
大変だったのは「lsコマンドに-lオプションを実装する」課題で、ぐしゃぐしゃになってしまったコードをどうしていいかわからず、泣く泣くそのまま提出しました。（レビューしてもらって綺麗になりました）

データベース

DBやSQLについて、それぞれ書籍で勉強した後、例題の設計を考えてER図を提出します。 この時点でRailsに触れていないため、何に使うのかよくわからないのが辛くて、日報に愚痴を長文で書いたりしました😅（のちに重要性がわかりました。）

Sinatra

Railsで開発する前に、よりシンプルなフレームワークのSinatraを使い、Web開発の基礎を学びます。
Sinatraの情報が少なく調べるのが難しかったですが、生まれて初めてメモアプリを作った時は感動しました。

Rails

書籍でRailsの基礎を勉強した後、簡単なアプリケーションに機能を追加していきます。
Sinatraで大変だったデータベースを扱う処理が、一瞬で実装できることに感動しました。また、Railsにたどり着けた嬉しさから、このプラクティスは楽しかった印象があります。

JavaScript

基礎的な文法をインプットした後に、いくつかのプログラムを作ってレビューをしてもらいます。
「非同期処理」の課題が特に難しく、思ったような順番で動いてくれずに苦戦しました。
また、「npmパッケージの作成」の課題では、自分で作りたいものを考えて、パッケージサイトにリリースします。 私は学校を検索できるコマンドラインツールを作りました。
自作のnpmパッケージを公開しました - すずかのプログラミング勉強記

React

公式ドキュメントを読んでインプットした後、Create React Appを使ってSPAのメモアプリを作ります。
この「公式ドキュメントを読む」のが分量が多く、心が折れそうになりました。先に進んでいる受講生・卒業生の方々にアドバイスをいただき、どうにか乗り越えました。

チーム開発について

FBCの学習に使っている「ブートキャンプ」というWebアプリに、新機能の追加やバグの修正などを行います。

初めは不安でしたが、簡単なIssueからスモールステップで割り振ってもらえるので、すぐに慣れました。仲間と一つのアプリケーションを作るのは非常にやりがいがあり、FBCのカリキュラムの中で一番楽しかったです。

チーム開発については、こちらの記事に詳しく書きました。
フィヨルドブートキャンプでプログラミングの勉強をする【11ヶ月目】 - すずかのプログラミング勉強記

自作サービスについて

開発期間は3ヶ月ほどで、山手線を徒歩で一周する人のための記録アプリ「YamaNotes」を作りました。

詳しくはこちらをご覧ください。
山手線を徒歩で一周する人のための記録アプリ「YamaNotes」をリリースしました - すずかのプログラミング勉強記

楽しかったこと

ブートキャンプの開発に関われた

チーム開発で、実際に使われているWebアプリの開発に関われたのが楽しかったです。
ここでは、メンターさんからIssueが割り振られるだけでなく、自分で新機能の提案をすることもできます。私は「日報提出のお祝いメッセージを何回も出す」というIssueを作り、自分で開発を担当しました。実装後は、受講生の皆さんからSNSで感想をもらうことができました。

ブログやLTでアウトプットできた

卒業までに、ブログに29本の記事を書きました。はじめは正直誰も読んでくれないと思っていましたが、想像以上に多くの方に読んでもらうことができ、勉強を続けるモチベーションになりました。
加えて、FBC内のLT会などで4回登壇する機会があり、あたたかいフィードバックをいただきました。考えていることを言語化する練習になったのはもちろん、自分の発表が誰かの役に立つかもしれないと考えると、自己肯定感が上がりました。

仲間ができた

FBC内のイベントを通して、受講生の方やメンターさんとのつながりができました。Discordで輪読会や雑談をしたり、Rubyコミュニティのオフラインイベントに一緒に参加したりするのが楽しかったです。
特に、就職活動中はメンタルが不安定で、皆さんに非常に支えられました。最終面接の10分後には、Discordで皆さんとお話ししていたぐらいです😊

大変だったこと

学習内容が難しかった

FBCのカリキュラムの中で、「何かの記事の内容をそのままやったらできた」という課題は一つもありませんでした。自分で資料を読んで、必要な情報を集め、手を動かしてエラーと立ち向かわなくてはいけません。
学習が進むにつれ、わからないことにも慣れていきましたが、序盤の方が特に辛かったです。

提出物がなかなか合格できない

課題の提出物を作ると、メンターさんにレビューをしていただきます。
できなくて当然なのはわかっているのですが、100個近いコメントをいただいた時は、自信をなくして修正する気力が失せたりしました😅
慣れてくると、コメントが多いのはメンターさんの愛だと思えるようになり、何度再提出になってもあまり気にしなくなりました。苦労した分、合格した時の喜びは大きかったです✨

いつ卒業できるのか不安

カリキュラムが多いため、いつ卒業できるかが常に不安でした。
私は入学時に「1年で卒業する」という目標を立てていましたが、結局達成はできなかったです💦（もっと短期間で卒業している方も沢山いるので、やり方次第だと思います）
ただその分、課題の発展的な要件にも取り組んだり、カリキュラムとは直接関係ない技術書を読んだりなど、深掘りして学習することがある程度できたと思っています。

就職活動について

自作サービスの後半と並行して、就職活動を行いました。
FBCの紹介企業を一社受けて、その会社から内定をいただきました。

スケジュール

日 やったこと
4月中旬 FBC内での企業説明会
5月上旬 カジュアル面談→書類選考
5月中旬 RubyKaigiや個人的な事情（引越し）などで一度中断
6月上旬 一次面接
6月中旬 最終面接
6月中旬 オファー面談→内定
7/1 入社

就職先について

FBCの紹介企業で、教育関係のプロダクトを作っている会社です。
前職の経験が活かせるイメージが湧いたため、カジュアル面談を受ける前からほぼ入社を決めていました😊

選考対策について

FBC側で、履歴書・職務経歴書の添削、面談練習を2回していただきました。どちらもすごく丁寧にフィードバックをいただきました。

以前、転職活動がうまくいかなかった経験があり、不安はとても強かったです。
内定をいただくことができたのは、関係者の皆様に親身にサポートしてもらったこと、FBCの卒業生の評判が良かったことのおかげだと思っています。

今後やりたいこと

子ども達や先生方の役に立つプロダクトを作れるようになりたいです。そのために一日も早く戦力になれるよう、技術力を上げていくことが当面の目標です。

また、会社のFBC卒業生は私が一人目なので、頑張って働いて「さすがFBC卒業生」と言ってもらえるようになりたいです！

今後のFBCとの関わり方

勉強会に参加したい

FBCには、現役生だけでやっている勉強会はもちろん、卒業生と現役生が混じっているものや、卒業生の方が中心となって運営している勉強会があります。
現在私が参加している現場で使える Ruby on Rails 5速習実践ガイド の輪読会は、あと数ヶ月続きそうなので、卒業後も継続して参加していきたいです。その後も、難しめの技術書を読む輪読会など、何かしらに参加していたいと思っています。

カリキュラムを復習したい

「卒業したのでFBCをやり切った」と書けたらいいのですが、実はまだやっていない「発展編」というカリキュラムがあります。加えて、この記事を書いていて、序盤のカリキュラムはかなり忘れていることに気づきました😅
まだまだFBCから学ぶべきことは多いので、今後も勉強をさせていただきます。

自作サービスを改善する

最終課題として作った自作サービスを、実際に使ってくれる人がいました。
アプリの性質上、本格的に使ってもらえるのは秋頃だと思うので、今後もパフォーマンスの改善や新機能の追加などをしていきたいです。

おわりに

FBCを卒業して就職し、晴れて無職生活も卒業できました✨ 応援してくださった皆さまに、改めて感謝申し上げます。

勉強生活には終わりを告げましたが、エンジニアとしてはここがスタートになります。
FBC卒業生の名に恥じぬよう頑張りますので、今後ともよろしくお願いします。

山手線を徒歩で一周する人のための記録アプリ「YamaNotes」をリリースしました

Ruby Rails

YamaNotesのロゴ

はじめに

山手線を徒歩で一周する人のための記録アプリ「YamaNotes」をリリースしました。
この記事では「YamaNotes」の使い方や、開発過程で苦労したことなどをまとめます。

6/14追記：東京の気温が高くなることが予想されています。熱中症予防のため、涼しくなってからの挑戦をおすすめします。

自己紹介

すずかと申します。
昨年4月にFJORD BOOT CAMP（フィヨルドブートキャンプ：以下FBC）に入学して、プログラミング歴は約1年です。以前は高校の国語教員をしていましたが、新しい挑戦をするため退職し、未経験からWebエンジニアを目指しています。

アプリの概要

山手線一周に徒歩で挑戦する人向けの記録アプリです。
各駅の到着時刻や、疲れ具合のメモなどを、簡単に記録することができます。

山手線徒歩一周チャレンジとは？

その名の通り、山手線を徒歩で歩くことです。
正式なデータではありませんが、総歩行距離は約45km、12時間ぐらいかかることが多いようです。RTAとして挑戦している人もいます。

使い方

ログインする

トップ画面からGoogle アカウントでログインします。 トップ画面のキャプチャ

初期設定をする

モード（外回り or 内回り）と、出発駅を設定します。 初期設定画面のキャプチャ

進捗を確認する

現在の進捗が地図上に表示されます。残りの駅数や距離を確認しましょう。 ダッシュボードのキャプチャ

到着する

駅に着いたら、「到着」ボタンを押しましょう。メモを追加したり、Xで進捗をポストすることもできます。 到着画面のキャプチャ

履歴を確認する

到着時刻の編集や、メモの追加を行います。間違えて「到着」ボタンを押した場合は、削除することもできます。 履歴画面のキャプチャ

開発に至る経緯

昨年4月に15時間ほどかけて、はじめて山手線を一周しました。 普段ほぼ運動しない私にとっては辛い挑戦でしたが、歩き終わった時の達成感はこれまで感じたことのないものでした。
この挑戦をもっと楽しくするために、「YamaNotes」を作りました。

技術スタック

技術選定の理由

「必要な機能を短期間で作ること」「コストを抑えて作ること」を軸に行いました。

短期間で必要な機能を作るため、Rails7とHotwireで実装

FBCのカリキュラムでReactを学習していたため、他のフレームワークを使用することも検討しましたが、数行のコードでSPA風の挙動を実現できる開発コストの低さに惹かれ、Hotwireを採用しました。
本格的な開発に入る前に、猫でもわかるHotwire入門やパーフェクト Ruby on Railsで学習し、想定した機能が問題なく実装できることを確認しました。
実際に開発してみると、Hotwireを使ったのは大正解で、JavaScriptをほとんど書かず素早く実装できることに感動しました。やりたいことを整理した上で、サービスの規模に合わせた技術選定をする重要性を実感しました。

コストを抑えて作るため、APIやデプロイ先を調査

しばらくはサービスを継続したいと考えているため、維持費を抑えることにこだわりました。一部に従量課金制のものがありますが、想定されるアクセス数なら無料で運用できるよう作りました。
特にコストを抑えるために考慮したのは、以下の2つの箇所です。

地図の表示と描画にLeaflet + OpenStreetMapを使用

当初は開発の情報量の多さ・地図の見やすさなどに魅力を感じ、Google Maps APIの使用を検討しました。しかし無料枠がやや少ないと感じたため断念し、無料で使えるものを探した結果、OpenStreetMapで地図を表示してLeafletというライブラリで線や吹き出しを追加することにしました。
加えて、地図タイルをOpenStreetMap標準のものからMapTilerのものに差し替えました。こちらは従量課金制で無料の範囲に収まることをを想定していますが、場合によっては無料のものに戻すつもりです。地図の見やすさとコスト削減を両立できたと思っています。

Render.com + Supabaseでデプロイ

当初はFly.ioにデプロイするつもりでしたが、無料プランが無くなったようなので、Supabaseのデータベースを使ってRender.comにデプロイしました。
Supabaseに触れるのは初めてでしたが、同じFBC生の方が書いたこちらの記事に助けられて、無事デプロイすることができました。
Rails7+Render.com+Supabaseで無料デプロイ - はるまきのブログ

こだわったこと

「YamaNotes」というネーミング

「名前重要」という言葉をよく聞くので、サービス名はこだわりました。
山手線の「Yamanote」と、記録を表す「Note」を組み合わせ、複数形の「YamaNotes」としました。
「山手線一周アプリ」といっても、地図や情報提供・RTAのための時間管理など、色々なアプリが考えられますが、この名前が決まったことにより、山手線一周の「記録」に特化する方向性に決まりました。

地図上に線を引いて、進捗をわかりやすくすること

「記録」に特化したアプリなので、ユーザーは地図を別で用意していることを想定しています。そのため、アプリ上に地図の表示は必須ではなく、下のように路線図に進捗を表示する方法もありました。

地図を使わない実装イメージ：路線図はillustACよりクレジット表記不要のものを使用

しかし、山手線の駅間は最長の区間（大崎〜品川間：約2.0km）と最短の区間（日暮里〜西日暮里間：約0.5km）では、かなりの差があります。路線図の色を変える方式では、駅間の距離の違いを反映できないと考え、地図上に直線を引くことにしました。
進捗をわかりやすくするとともに、地図に直接線が引かれるワクワク感があり、気に入っています。

全ての機能やメソッドに対してテストを書くこと

不具合を見つけてより快適に使ってもらうため、テストコードをもれなく書くよう意識しました。
FBCのカリキュラムではMinitestでテストを書いていましたが、自作サービスではRSpecを使うことにしたので、Everyday Rails - RSpecによるRailsテスト入門を参考に勉強しました。その後、全てのpublicなメソッドや機能について、ひたすらテストを追加しました。

simplecovによると、テストカバレッジは99%のようです。 テストカバレッジ 今後も勉強を続けて、今書けていないテスト（認証周りの異常系など）も追加していきたいです。

苦労したこと

Hotwireが魔法のように見える

「YamaNotes」では、以下の箇所にHotwireを使用しています。

  • Turbo Drive：基本的な画面遷移
  • Turbo Frames：編集フォームの表示
  • Turbo Streams：編集後の更新処理
  • Stimulus：地図の表示・線の描画、モーダル・ハンバーガーメニューなど（tailwindcss-stimulus-componentsを使用）

数行のコードを書くだけで動きをつけることができ、非常に便利に感じる一方で、特にTurbo Streamの実装で理解が浅いせいで思うように動かず、苦労しました。 到着履歴画面の削除機能など、まだまだTurboに置き換えたい部分があるので、もっと深く理解できるよう勉強したいです。

カスタムバリデーションを設定すること

到着機能の実装において、「駅の数以上に到着できない」「前後の記録と齟齬がある到着時刻を設定できない」など、色々なバリデーションを設定する必要がありました。
最も苦労したのが、「隣駅以外に到着できないようにする」バリデーションです。内回り・外回りそれぞれで対応する必要があったため、当初はStationテーブルに「外回り時の次の駅ID」と「内回り時の次の駅ID」を持たせる設計にしていました。
ただ、実装時に作りにくさを感じたため、紙に書き出してロジックを考え、次の駅の取得方法を考え直しました。

ロジックを考えた時のメモ

考えた時のメモ

データベースには「外回り時の次の駅ID」のみを持たせ、Stationクラスのnextメソッドで外回り・内回りに応じて条件分岐することで、要件を満たすバリデーションを設定することができました。

使いやすいデザインにすること

CSSが苦手なのもあり、最低限使えるデザインにするまでが、まず大変でした。一通りデザインを入れた後も、レスポンシブ対応・OGPやFaviconの設定・画像の圧縮やaltの設定・・・・など、使い勝手の良いアプリにするためにやるべき作業が山のようにあり、苦労しました。
自分なりのデザインを入れた後は、FBCのデザイナーさんにレビューをしていただき、修正を繰り返しました。お陰様で、シンプルで使いやすいデザインになったと思っています。
「普通に使えるサービス」のデザインが、如何に考えて作られているかを知ることができ、デザイナーさんへ尊敬の念が湧きました。

今後やりたいこと

複数回記録できるようにする

ファーストリリースでは最低限の機能に絞ったため、現在の実装では、作成できる歩行記録はユーザ一人につき一つだけとなっています。つまり、二周目を歩く際には、一周目の記録を削除して記録する必要があります。
RTAをするために山手線を何周もする人は想定されるため、将来的に複数の歩行記録を作成・閲覧できるようにしたいです。

パフォーマンスの改善

現在は到着ボタンを押した時に、約2秒の時間がかかっています。到着ボタンは何度も押すことになるので、もう少し速くしたいところです。
発行されるクエリを減らすためのリファクタリングや、使っていないインスタンス変数の削除、キャッシュの利用などを行って、若干速くはなりましたが、サクサク動くにはまだ至っていません。到着時にカスタムバリデーションを複数実行していることや、Render.comに東京リージョンがなくシンガポールに設定していることが、要因として考えられます。
今後はパフォーマンスについて勉強するとともに、東京リージョンがあるサービスへの移行も検討しようと思っています。

到着駅に応じたイラストや文言を追加

現在は到着画面が二種類（歩き終わった時用とそれ以外用）だけなのですが、着いた駅や進捗に応じたイラストを表示できると楽しいかなと思っています。例えば、上野駅に着いた時にパンダのイラスト、残り一駅の時に「あとちょっとだから頑張れ！」的なメッセージを出すなどしたいです。

おわりに

作り始めた時は、作りきれるか不安でしたが、どうにかリリースすることができました。
無事リリースできたのは、毎日お世話になったFBCの皆様、あたたかい言葉をかけてくれたRubyコミュニティの皆様、SNSを通じて応援してくださった方々のおかげだと思っています。
YamaNotesは今後も改善を続けるつもりなので、ご意見や感想などをいただけると嬉しいです！

フィヨルドブートキャンプでプログラミングの勉強をする【13ヶ月目】

勉強の振り返り

未経験からフィヨルドブートキャンプ(以下FBC)で勉強して、1年1ヶ月が経ちました。

今月も振り返りを書いていきます！卒業が見えてきたので、振り返りを書くのはこれで最後（にしたい）です😅


4月の過ごし方

自作サービスを集中して進めつつ、気候が良かったので、息抜きに外で遊んでいることが多かったです。

4月中旬には、江ノ島に日帰りで行ってきました！新江ノ島水族館で、カピパラがお風呂に入っていたのが可愛かったです🥰

お風呂に入るカピパラの写真

勉強の状況

4/4~5/3で修了したプラクティスは2つだけです。

1ヶ月間で修了したプラクティス一覧

開発に参加して PR を送りマージする

CI

自作サービスは、「Webサービスを作る」という大きな1つのプラクティスになっているため、修了はしていませんが、作業としては結構進みました。

作業が残っているプラクティスは「Webサービスを作る」「デザインレビュー」「コードレビュー」「リリース」のあと4つです。


勉強時間

学習時間は13ヶ月間（396日）累計で2451時間でした。

学習時間

4月後半からは就職活動を並行して行うことにし、書類の作成を進めました。

FBCのホームページに書いてある目安時間（1200時間）の倍以上かかっていますが、もう一息頑張ります！


自作サービスの進捗

「山手線を徒歩で一周する人のための記録アプリ」を作っています。

今月取り組んだこととしては、以下の通りです。

履歴一覧機能→履歴編集機能→公開機能→メモ追加用モーダル→ヘルプのモーダル→ハンバーガーメニュー→利用規約・プライバシーポリシー作成→バグ修正

地図の表示や到着などの基本的な機能が動作するようになりました。現在はデザインを入れたりテストを書いたりなど、細かい部分の実装を進めています。

全ての機能が出来たら、FBCのメンターさんにコードレビュー・デザインレビューをお願いします。レビュー対応が終わり次第、6月上旬のリリースを目指しています。

ロゴ（仮）ができました！

できるようになったこと

  • カスタムバリデーションを実装できるようになった
    到着機能の実装で、「駅の数以上に到着できない」「前後の記録と齟齬がある到着時刻を設定できない」など、色々なバリデーションを設定する必要がありました。
    特に難しかったのが、「隣の駅以外の到着できないようにする」バリデーションです。内回りモード・外回りモードそれぞれに対応する必要があり、かつ駅の登録順に依存しないようにする必要がありました。紙に書き出してロジックを考えてから実装することで、要件を満たすバリデーションを設定することができました。

    考えた時のメモ

    バリデーションを考えた時のメモ

    Stationsテーブルに「外回り時の次の駅id」のカラムを持たせ、内回り・外回りで条件分岐させることで、登録順に依存せずかつバリデーションも設定することができました。

  • Hotwireを使用して簡単な機能を作れるようになった
    自作サービスでは、ダッシュボード画面と到着一覧・編集画面にHotwireを使用しています。 使っている箇所は以下の通りです。

    • Turbo Drive：基本的な画面遷移
    • Turbo Frames：編集フォームの表示
    • Turbo Streams：編集後の更新処理
    • Stimulus：地図の表示・線の描画、モーダル・ハンバーガーメニューなど（tailwindcss-stimulus-componentsを使用）

    Hotwireを扱うのは初めてでしたが、「猫でもわかるHotwire」や「パーフェクトRuby on Rails」を読み、基本的な実装方法を理解しました。一度やり方がわかると、JavaScriptをほとんど書かず、素早く実装できることに感動しました✨

  • RSpecで簡単なモデルテスト・システムテストが書けるようになった
    モデルとシステムテストの追加が概ね終わりました。ある程度実装が進んでから一気にテストを書いたら、量が多く大変だったので、その後は機能を作ると同時にテストを書くようにしています。
    今後は、Helperのテスト追加とリファクタリングをする予定です。特に、一部のテストでは「内回りモード」「外回りモード」の2つが存在するため、shared_examplesやshared_contextを使用して、もう少しDRYになるようリファクタリングしたいです。

苦労したこと

  • CIだけで落ちるシステムテストの修正に苦戦
    ローカルでは全て成功しているシステムテストが、一つだけCIで落ちるようになり、何時間も詰まりました。エラー文を見ると、Capybaraのclick_onで要素が見つからないのが原因でしたが、特に怪しい部分もなかったため、手がかりがなく非常に困りました😭
    FBCの先輩に「何かしらのキャッシュが関係しているかも」とアドバイスいただき、一度全てのキャッシュ・失敗した履歴を削除して再度実行したら、解決することができました。ローカルで再現しない不具合の原因を特定することの、難しさを感じました。

  • リファクタリングの終わりが見えない
    「とりあえず動くようになる」ことと、「ユーザが使っても問題なく動くようにする」ことの間が、思った以上に長いです😅
    自分なりに工夫してコードを書いたつもりでも、余分なクエリが発行されていたり、特定の状況下のみバグが起きたり、想定しない不具合がたくさん起きました。
    現在リファクタリングを進めていますが、全てのコードに自信を持てている状態には程遠いです。納得のいく状態に近づくよう、気になったことは部分はメモして、定期的にリファクタリングしたいです。

  • デザイン関係で考慮すべきことが多い
    全てのページにデザインを入れるはもちろんですが、レスポンシブ対応・titleタグやmeta descriptionの設定・OGPやFaviconの設定など、使い勝手の良いアプリにするためにやるべきことが沢山ありました。
    デザインの重要性はわかっているので、ストレスなく使えるものにしたいです。ただ、凝りすぎると一生リリースできないので、どこまでこだわるかが悩ましいです🤔

イベント参加など

  • RubyKaigi 2024事前勉強会に参加
    申込時に補欠でしたが、当日数時間前に繰り上がって参加できました。 Ruby Kaigiの話を理解するため、議題となる内容の背景知識を解説してくださっていたのがありがたかったです。JITコンパイラやパーサー改善など、初心者向けの解説でも私にとっては難しかったですが、何を勉強すればわかるようになるのかがわかりました。（ 雑談で「Rubyのしくみ」という本の存在も知りました）
    懇親会では有名なRubyistの方や、同じ元教員のエンジニアさんとお話しでき、勉強のモチベーションが上がりました✨

  • Urawa.rb #4を主催
    今回は初参加の方が多く、まだ見ぬ世界を教えてもらう素敵な時間になりました。
    活動報告→Urawa.rb #4 活動報告 | Notion
    新しく購入した「Linuxコマンドかるた」が盛り上がり、詳しい方に解説をしてもらって勉強になりました。今は結構忘れてしまったので、毎月やって定着させたいと思います😅
    参加者の方に、「Urawa.rbの参加者は穏やかでいい人しかいない」と言っていただき、本当にその通りだなと感謝しています🙇‍♀️

今の気持ち

自作サービスの追い込みや就職活動の準備・プライベートでは引越しが重なり、4~5月はバタバタしています💦 色々と不安になることも多いですが、FBC生やメンターさんとの雑談にかなり支えられています！

卒業直前に改めてFBCの良さを感じているので、幸せに働くエンジニアになって恩を返せるよう頑張ります💪

5月の目標

  • 自作サービスのデザインレビュー・コードレビューを提出する。
  • 就職活動を後悔がないよう頑張る。
  • RubyKaigi 2024を楽しむ。

Action Mailerのスキップ時に発生するZeitwerk::NameErrorの解決方法

Rails Ruby

はじめに

Rails でアプリケーションを作成中、あるgemのコマンドを実行するとZeitwerk::NameErrorが発生しました。

expected file /Users/suzuka/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/devise-4.9.3/app/mailers/devise/mailer.rb to define constant Devise::Mailer, but didn't (Zeitwerk::NameError)

調べたことの理解を深めるため、解決した手順をまとめます。

実行環境


エラーの原因

アプリケーションを作るときに、メール機能を使う予定がないため、Action Mailer をスキップしたことです。

rails new sample_app --skip-action-mailer

調べたこと

Action Mailerが無効な場合、Devise::Mailerクラスは定義されない

エラー文にある devise/mailer.rbのファイルを見に行ったところ、以下のようなコードが書かれていました。

deviseはActionMailerが定義されている場合のみ、Devise::Mailerクラスを定義しています。

if defined?(ActionMailer)
  class Devise::Mailer < Devise.parent_mailer.constantize
    include Devise::Mailers::Helpers
  ......
  end
end

このアプリではAction Mailerをスキップしているので、Devise::Mailerクラスは定義されません。

Zeitwerkはファイル名からクラス名を推測する

エラー文にある、Zeitwerkとは何なのでしょうか？

Rails6から導入された、命名規則に則ったファイルを自動で読み込むgemで、「ツァイトヴェルク」と読むようです。このgemがあることによって、requireをたくさん書かなくても、必要なファイルを読み込めるようになります。 github.com Rails6以降、デフォルトで読み込みはzeitwerkモードで実行され、ファイル名と異なる命名規則のモジュール名・クラス名が定義されていた場合はエラーが発生します。

Zeitwerk使用時の、ファイル構造と定義されているクラスとモジュールの例は、以下のとおりです。

lib/my_gem.rb -> MyGem
lib/my_gem/foo.rb -> MyGem::Foo
lib/my_gem/bar_baz.rb -> MyGem::BarBaz
lib/my_gem/woo/zoo.rb -> MyGem::Woo::Zoo

つまり、devise/mailer.rbという名前のファイルがあることで、Zeitwerkは「Devise::Mailerクラスが定義されているはず」と判断します。しかし、このアプリでは実際にはDevise::Mailerクラスが存在しないため、Zeitwerk::NameErrorが発生しました。

解決方法

以下のIssueを参考にしました。

Rails6 without ActionMailer won't boot with zeitwerk eager-loading · Issue #5140 · heartcombo/devise · GitHub

このIssueでは、2 つの解決方法をあげていますが、今回はより簡単な「ダミーのDevise::Mailerクラスを定義する」という方法で行うことにします。

config/initializers/devise.rbに以下を追記しました。

if Rails.autoloaders.zeitwerk_enabled? && !defined?(ActionMailer)
  class Devise::Mailer; end
end

このコードによって Zeitwerkがファイル名から予測するクラスを定義することができ、エラーを解消することができました。

参考文献

Zeitwerkについて：

Zeitwerk::NameErrorの解決について：