motohiLog

プログラミング未経験→Webエンジニア

2月のふりかえり

雑記

2月終わりますね、motohiroです。
フィヨルドブートキャンプ（以下FBC）を12月に卒業し、2月からWebエンジニアとして働いています。
そして新年の目標を立てて1ヶ月たちました。
2月を振り返りたいと思います！

プログラミング

仕事

入社して1ヶ月がたちました。
1ヶ月といっても2月は28日しかなく3連休も2回含まれていたので、本当に追われていた、という感覚です。
オンボーディングがしっかりしているため事業部やチームへの理解は高まりましたが、実務と同時進行だったこともあって頭がパンクしていたのも正直なところでした。
胸を張って「慣れた！」とはまだまだ言えませんが、少しはチームの動きにも慣れてきたしプロダクトに携われる時間も増えてきて楽しくなってきています。
また、とにもかくにもみなさん優しく、そして意欲的なので刺激もたくさんいただいています。
自分がエンジニア初の未経験ということもあって、かなり気遣っていただいているようにも思います。
まとめると以下の感じです↓

良かったこと
  • みんな優しい
  • 一体感がつよい
  • オンボが終わって新しいプロジェクトに入れた
  • ちょっとドメインわかってきた
  • 給料が出た
ちょっと落ち込んだこと
  • 新しいツールに四苦八苦
  • やっぱりドメインむずい
  • React忘れすぎ
  • 今やってるプロジェクトのことが全然わからない
  • 通勤が思っていたよりも苦痛

落ち込んでいる部分は、今後慣れたらなんとかなるとも思うし、引き続き勉強していきたいところです。
やっぱりプロダクトに携わってコード読んだり書いたりしてる時間は楽しいですね！

今は経験値がなさすぎて自分がどのくらいのタスクをどのくらいで終わらせられるか全然わかっていないので、今後は少しずつ「見積もる」ことを意識して覚えていきたいと考えています！

仕事以外

自作サービス

今月はなかなか手をつけることができませんでしたが、駆け込みでなんとか1つissueをこなしました。
献立表一覧、カレンダー表示時のパラメータの日時に制限をつけました。

youtu.be

以前ご指摘いただいていたところだったのでやっと直せて良かったです。

自作サービスのコードは久しぶりで苦戦しましたが、それでもやはり自分のサービスをいろいろ触れるのは楽しいなぁと改めて思いました。
今後も少しずつ改善を続けたいと思います。

競プロ

ABCには3回参加しました！
時間が間に合わずunratedが2回でしたが、Rubyのコードを書くのが久しぶりで楽しかったです！
今後も息抜きに続けていきます！

他

オンボで書籍を3冊読みました…本を読むのが苦手な私にはめちゃくちゃしんどかったです…。
ブログはこの振り返り以外は全然書けなかったので、3月は何か書きたいなぁとも思いますが、無理せずという気持ちです。

生活

太りました。笑
リモートワークを覚え運動量がとても少ないです。
でもFBCのころから全然運動していないので、ある意味変わっていません。
3月はさらに家全体の生活サイクルが大きく変わるので、いいかんじにしていきたいです。

  • 仕事スタイルを確立する　→　△
  • 運動習慣をつける　→　×
  • 胃腸を労わる　→　×
  • 飲みすぎない　→　×

気持ち的な話

人生のリスタートだったこの1ヶ月は思っていた以上にしんどかったです。
慣れない仕事に落ち込んだときもありましたが、たくさんのエンジニア仲間に助けていただきました。
色々話せる仲間が周りにいてくれて本当に感謝しています。
FBCをはじめとするコミュニティ・仲間のありがたさを感じた1ヶ月でした。

おわりに

3月は肩の力を抜いて気張りすぎず、でもやりたいことをやっていきたいなと思っています！
自分らしさを忘れず頑張ります！

2025年の目標

雑記

あけました、motohiroです。
遅くなりましたが、今回は2025年の目標を書きたいと思います。
かなり緩い感じで箇条書きで書いていきます。
よろしくお願いします！

プログラミング

仕事

内定をいただき、2月からWebエンジニアとして働くことになりました！
新しい仕事に不安だらけですが、以下の目標は達成できるようにしたいです。

  • 一人である程度のことをできるようにする
    • 半年でメンターから独り立ちするので、その状態でも仕事を問題なく進められるようにする
    • 適切な人に適切なタイミングで的確に質問できるようにする
  • 評価が下がらないようにする
    • C評価をとらないようにする
    • 理想は良い評価が取れるようにしたいけど気張りすぎない

仕事以外

今まではフィヨルドブートキャンプのプラクティスに追われていたので、仕事以外にも無理のない範囲で自分でやりたいと思ったことをやってみようと思います👀

  • 自作サービスに月に1つはissueをこなす
    • 機能追加、アップグレード、バグあれば改善でもなんでも
    • とにかく何かしら手を加え続けて維持する
  • 競プロを再開する
    • できる限りABCコンテスト出る
    • ちょっとでも時間を確保して勉強したい
  • 仕事の本も含めて2ヶ月に1冊は本を読む
    • 本読むのが苦手なので無理はしないけど、何かしら読む
  • ブログを月に1回は書く
    • 雑記でもいいから何かしら書く

生活

仕事が始まることで生活もガラッと変わると思うので、自分なりのスタイルを確立したいです！

  • 仕事スタイルを確立する
    • 初フレックス制＆初リモートワーク&久しぶりのフルタイム勤務なので、自分に合う生活スタイルを今年一年で見つける
    • 家族との生活スタイル調整もする
      • 何時から何時勤務する、何時に起きて何時に寝る、とか
  • 運動習慣をつける
    • 家から出る習慣をつける
    • とりあえず歩く
    • 歩くのに慣れたら走る
    • 毎年痩せたいって言って痩せる努力をしないから、とりあえず運動習慣をつける
  • 胃腸を労わる
    • 食べすぎない、特に油物とか
    • 理想は腸活したい
  • 飲みすぎない　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
    • 満足してちゃんと帰る大人な飲み方を覚える

おわりに

ハードル低めな目標を立てたつもりです。
12月末にできたか振り返りたいと思います！
今年もよろしくお願いします🐻‍❄️

自作サービス開発の振り返り

学習のあれこれ ごはんサミット

この記事は、フィヨルドブートキャンプ Part1 Advent Calendar 2024の14日目の記事です！
昨日はうにおさんの「フィヨルドブートキャンプで『🍅もくもくポモドーロ会』というゆるイベントをやってみた」でした。
また、フィヨルドブートキャンプ Part2 Advent Calendar 2024もあります。
昨日はまっぴーさんの「Reactで脱出ゲームを作ってみた」でした。

「ごはんサミット」をリリースしました、もとひろ(@motohiromm)です！
やっとフィヨルドブートキャンプ卒業できました！やったー！！
今回の記事は、自作サービス開発の振り返りを勢いだけで書いていきます！
技術的な話はありません！よろしくお願いします！
（技術に関してはリリースブログをお読みいただければと思います）
まだ宣伝ポストをいいね＆リポストしてない方はぜひそちらもお願いします！🙏
ぜひ「ごはんサミット」触ってみてください！

振り返りの概要

「自作サービス開発は本当にしんどかったけどなんとかなった」
という話をします。

自作サービス開発でかかった期間

大体4ヶ月くらい
（エレベーターピッチ除く）

長いと感じるかたもいるかと思いますが、私としてはけっこう早くリリースできたなと思っています…！今までのプラクティスの時間のかかり具合を考えたら、自分なりに最大スピードで頑張りました。

9月15日から12月10日までの86日間

  • 学習時間：467.5時間
  • 平均：5.7時間
  • 全くやらなかった日：7日

rails newした頃はチーム開発は終わっていて自作サービスに注力していたので、rails newした9月15日から計算してみました。
正直かなり追い込んでやっていた気持ちだったので、計算してみたら思っていたよりも少なかったです…悲しい。苦笑
すこしですがアルバイトしていたので、その割には時間を確保できたほうだと思うようにします！

各プラクティスの割合

  • エレベーターピッチ：6月〜7月頭（ぼんやり考え始めたのは3月頃から）
  • ペーパープロトタイプ：8月中旬の1週間
  • カンバン・リポジトリ：1日
  • 技術検証：2週間
  • リソース・データ設計：8日（4日+レビューでのやりとり4日）
  • Webサービスを作る：rails newが9月15日〜リリースまで約3ヶ月
    • デプロイ：10月17日

自作サービスの最初のころはチーム開発の終盤と同時並行で作業していました。技術検証とかプロトタイプを作ったりしていたように思います。

開発中しんどかったこと

アイデアが全然出てこなかった

自作npmを作成した際に、自分はアイデアを出すことがとても苦手であることは分かっていました。フィヨルドブートキャンプでは自作サービス案も用意してくれていますが、私が気になっていた案はすでに他の人が着手していて選択できなかったので自分でアイデアを捻り出すしかありませんでした。
以来少しでもヒントになりそうなものがあったらメモする、ということを続けてアイデアを出す習慣をつけるようにしました。なかなかアイデアを見つけることができなくてしんどかったです。メモし忘れたものも含めて20個くらいアイデアを出したように思います。

ボツ案を書いておきます。

  • FBCのプラクティスをクリアするとなんかもらえるゲームっぽいもの
    プラクティスをクリアした時にもっと褒めて欲しい、喜びが欲しい
    プラクティスをクリアすると友達が増えて最後に卒業式映像がでるみたいな

  • 目覚まし時計のアラームにRubyのクイズを答えないとアラームがとまらないもの
    アラームの機能は作れるが、スマホのアプリとかにしないとスリープ状態でアラームかけるとかができなそう
    むずかしい

  • マッチングアプリで会った人を記録していく
    自分のチェックしたい項目を入れて点数をつけていく
    優先したいものをえらぶとそのランキングがすぐみれる
    人をランキングするのはポートフォリオ的によくなさそう
    ただのランキングサイト作成アプリは他にもある、特徴がないとむずかしい

  • 友達の子供の名前が覚えられない
    自分の相関図・家系図っぽいものが記録できたらいいかも
    相関図・家系図つくるサイトはけっこうある
    他人の個人情報を保持するのは危険そう

  • お盆の時期や、やることなどをすぐ忘れちゃう
    それを通知してくれるアプリ
    地域や宗派によって時期もやることも違うので難しそう

  • 参加した外部イベントを記録する
    イベントの名称・開催日時・場所・リンクをアプリケーション内に自動で登録できればよさそう
    connpassAPI有料、スクレイピングが禁止になるのでこの案はボツ

  • 名言を記録するアプリ
    教えてもらったことや覚えておきたいことをその名言を言ったユーザーごとに記録できる
    →すでに案出てて却下なってるからダメそう

  • 料理のレシピを家族間で共有できる
    作ってみて美味しかったやつを家族で共有してみられるようにしたい
    Cookpadやクラシル等からレシピを簡単に取得できるようにしたいところ
    レピモというアプリが全部まかなってそう

  • chrome拡張機能でわからない単語をドラッグしてなにかコマンドうつと登録した意味がでてくるもの
    プログラミング言語などで意味がぱっとでてこないときにつかいたい、意味の登録も拡張機能でぱぱっとできるようにしたい
    単語帳系は厳しいか

  • 積読している本を読むように促す
    買った時に登録して定期的に通知が来る的なもの
    読み始めたら通知をなくして、予定する読み終わり日を過ぎると再度通知がくる
    読書促進のアプリは他にもある

  • Youtubeの検索をもっと詳細にしたい
    APIの検索回数が100回/日なのできびしそう
    履歴はAPIからはとれない

  • 場所の混み具合を見るアプリ
    すでにあった

  • お土産を誰に買うのか、何買ったか忘れてしまう、問題
    リスト化して写真つける
    それを一緒に旅している人と共有もできるし個人のリストも作れる

  • 家から出ることを促すアプリ
    自分家から○○m離れると動物が育つ、花が育つ
    家から出ないと落ち込む、枯れる
    自宅の位置情報をもつのは危険？

  • 筋肉を特定してストレッチ情報をピックアップするアプリ
    ここ、が痛いときにどういうストレッチがいいか、を視覚的に選択して検索してくれる

  • カラオケの原曲キーのメロディラインを表示し、キー変更をするとそれにあわせてメロディーラインの表示も変わる

  • Googleドキュメントの変更履歴が日付単位ではなく、文章や段落単位内の差分で見たい

ごはんサミットのアイデアは一番最後に思い浮かんだものだったので、はやいうちからアイデア出しをして苦しんでおいて良かったなと今は思います。

想定外のエラーに苦しんだ

リリースブログにも書きましたが、想定外のエラーがどうしても起こります。
当たり前ですが「ログを見る」が本当に大事ということもよくわかりました。
エラーへの対応はとても勉強になりましたが、精神的にかなりすり減ったのも事実でした。
今なら「そんなに落ち込まなくても…」と思えるのですが、当時の自分は本当に落ち込んでいました。

思っていたよりも体力がなかった

数年に1回くらいしか風邪を引かなかったはずなのですが、rails newしてからの3ヶ月で2回発熱し風邪をひきました。
この期間あきらかに体調を崩すことが多かったです。体力も免疫もあきらかに低下していて、完全に運動不足だなと思っています。

思っていたよりも孤独に感じた

自作サービスを作り始めると、自分で仕様を考えissueをたて実装しPRをたててマージして…をひたすらに繰り返していきます。
今まではプラクティスごとにメンターさんからのレビューがあるので色々チェックしてもらえるのですが、自作サービスは完成まで作り上げて初めてレビュー依頼を出すので今までと全く感覚が違いました。自分で正しいと思って実装しているけれど、どうしても「これで本当に良いのだろうか…」という不安が途中途中で出てきたりして、それが孤独なように感じられました。
また、今までのプラクティスではみんな同じ課題に取り組んでいるため、受講生同士で悩みなども共有しやすく「あるある〜」みたいな話がしやすかったのですが、自作サービスになってからは完全に同じ悩みというのは少ないので共有しづらく、そのあたりも孤独感につながっていたように思います。

開発で良かったこと

良かったなと思えることもあったので書きます！

自分がまだまだ何も知らないことがわかった

今まで自分が学んできたことはRuby・Rails・JavaScriptなどのほんの一部であって、1つのサービスをリリースするためにはたくさんの要素が関わっていることがわかりました。sessionとかデプロイとかmachineとかリージョンとかドメインとかDNSとかSSLとかPWAとかレスポンシブデザインとかmetaタグとか、まだまだ理解が足りていない、というかなんだそれ？と思うことがたくさんありました。
でもリリースまでこれたからこそ知らないということを知れたので、マイナスな感情ではなくプラスに考えています！正直まだまだわかっていないことが大半なので、理解が足りていない分野は今後学習していきたいと思います！

エラーの個数が思っていたよりも少なかった

エラー自体は数え切れないほど出たのですが、解決に数日費やしたエラーはたぶん3つくらいかと思います。思ってたよりは少なかったなと今は思っています。
エラーが出た当時は全くそんなことは思わず全部必死でしたが、ハマったポイントがそれほど多くなかったのもこのスピードで頑張れた一因かなと思います。

長時間プログラミングしてても全然苦痛じゃないことがわかった

今までのプラクティスでもプログラミングの楽しさは感じていましたが、やはり自分で一から考えたアイデアができあがっていくのは嬉しかったですし、自分でやりたい実装がうまくいった時の脳汁が出る感じは最高でした。（伝わってますかね…？）
しんどい中でも、やっぱりプログラミングは面白い、楽しいと思えたのは本当に良かったと思っています。

家族をかなり巻き込んだことで喜んでくれた

エレベーターピッチの時点で、家族には相当相談していました。理由は家族と一緒に使うアプリだからです。
私のアプリの第一優先は「家族に使ってもらう」だったので、ペーパープロトタイプは紙に考えていく過程を家族に全部見てもらって意見をもらったし、動物のアイコンが嫌だと家族が言うのでなだめつつ12種類の動物を全部好きに選んでもらったりしました。
私は意外と優柔不断(？)なので、家族という軸があったことで意見ももらえたし踏ん切りがつくところがたくさんあったので、結果として家族を巻き込んでとても良かったです。
今回のリリースも私以上に家族が喜んでくれています。笑

たくさんの人が支えてくれた

しんどかったことで「孤独」の話をしましたが、それを解消してくれていたのはフィヨルドブートキャンプのみなさんでした。
同じ自作サービス開発をしている受講生同士で情報交換したり悩みを相談したりペアプロしたり、他の受講生の方々も実際にアプリの検証に協力してくださったり、卒業生の方が悩みを聞いてくださったりコードを見てアドバイスをくださったりデプロイしたアプリを触ってみて感想をくださったり、メンターさんが一緒にログを見てくださったりしました。直接お話ししていなくても、日報にリアクションしてくださってた方々もたくさんいて本当に励まされていました。
本当にしんどかったので、本当に助けられました。
ありがとうございました！

開発を終えて思うこと

今回の自作サービスの開発を通して感じたことを書きます。

「悩んでいる」とアウトプットしたほうが良い

自分が今何を悩んでいるのか、声をあげた方がいいということです。
今までのプラクティスに比べて自作サービスはスタートからレビューまでとても長丁場です。そのあいだずっと自分一人での作業になるので、自分から悩みや不安をアウトプットしないと誰も気づいてくれません。自分一人で解決できればいいですが全部が全部解決できるわけではないし、時間もかかると思います。
私は「困っている」「悩んでいる」と声をあげられたことで孤独の解消につながって、結果として開発スピードを保つ一因になったと思っています。

アウトプットする場所は、質問タイムでも自作サービス進捗報告会でも日報でも良いと思います。私は日報で現状やわからないことを書いたりしていたのと、Discord上でよく相談させてもらっていました。悩んでいるタイミングと合う時は自作サービス進捗報告会で相談させてもらったりもしました。日報は開発に熱中してくるとどうしても疎かになってくるので、自分の気持ちを気軽にアウトプットできる場の1つとして気軽に書けたら良いかなと思っています。

目標設定は大事

フィヨルドブートキャンプの良いところとして「自分のペースで学習できる」ことがありますが、自作サービス開発は長丁場なので、目標設定が大事だと感じました。具体的には、明確な期日の設定と、ファーストリリースにどこまでの仕様を含めるかです。
私は10月末のKaigi on Railsまでにアプリをみなさんに見せられる状態まで作ること、１２月中旬までにリリースすることを期日とし、ファーストリリースにはリアルタイム通信は含め通知機能は見送ることにしていました。開発していくうちに色々いれたい機能がでてきたりしたのですが、私の最終目標は卒業して就職することでありそれを見失わずに開発を進められたので、目標を先に設定して良かったと今思っています。

健康は本当に大事

これにつきます！！
いくらやる気があっても健康じゃなければ開発できません。
元気があればなんでもできる！元気がなければなんにもできない！

今後のWebエンジニア人生を楽しく謳歌するためにも、運動習慣をつけることと、食生活を整えることが私の今後の課題です！

サービス＆開発の余談

サービス名をとても悩んだ

サービス名はずっとずっと悩んでいて、たくさんの人に相談させていただきました。
みなさんに良いねって言われていた「ごはん会議」にしようと思っていたのですが、既に名前を使ってらっしゃる方がいたので断念しました。
そんななか輪読会で一緒に学習している@sugiweさんが私の悩み(愚痴)を聞いてたくさんの案を出してくださいました。そのうちの1つだった「ごはんサミット」に惹かれて、家族も良いねと言ってくれたのでサービス名を「ごはんサミット」に決定しました。
親身にたくさんアイデアを出してくださったsugiweさんには本当に感謝しています！ありがとうございました！「ごはんサミットって良いネーミングですね」ってけっこう受講生から言われたので、毎回sugiweさんに感謝の念を送っています。笑

テスト駆動開発(TDD)をしたかったけどできなかった

TDDをしたかったのですが、RSpecの書き方に全く慣れていない状態でさらに慣れていないTDDは私にはできませんでした。最初のテストとかで挫折した気がします。今回で少しはRSpecの書き方に慣れたので、もしまた一から開発する機会があったら次こそはTDDでやっていきたいです。

あんなにかわいくなる予定ではなかった

私はかわいいもの好きとかでは全くないので、こんなかわいいサービスを作る予定は全くありませんでした。笑
サービスのカラーはオレンジ＆ベージュ系と決めてデザインを大まかに入れたあと、ユーザーアイコンを何パターンも試して一番しっくりきたのがあの動物たちでした。そしたらなんかかわいい感じになって「自分の思っていたサービスと違う…」と思ってしまい正直ちょっと萎えてました。それを自作サービス進捗報告会で報告したときに、machidaさんに「ごはんや家族のあたたかい雰囲気と一致していて良いと思いますよ〜」と言っていただいて、machidaさんがそう言うならそれで良いな！と思えて萎えてた気持ちがなくなってかわいい方向に気持ちをシフトして開発を続けられました。
結果としてみなさんにデザインかわいいと言っていただけてとても満足しています！

おわりに

思うところを全部書きました〜。満足です。笑
本当にたくさんの人に支えられてリリース＆卒業できました！
本当にありがとうございました！

「ごはんサミット」を触ってくださった方々から感想やご意見をいただいています。とても嬉しいです！本当にありがとうございます！
まだ触ったことのない方はぜひ触ってみていただいて感想やご意見をいただけたら幸いです！
今後も改善を続けていきたいと思います。

長文になりましたが、お読みいただきありがとうございました！


明日のアドカレはPart1：reckyさん、Part2：Yuki Watanabeさんです！

献立の相談と献立表の共有ができるアプリ「ごはんサミット」をリリースしました！

ごはんサミット

はじめに

フィヨルドブートキャンプでプログラミングの学習をしています、もとひろ(@motohiromm)と申します。

献立の相談と献立表の共有ができるアプリ「ごはんサミット」をリリースしました！
本記事では「ごはんサミット」の使い方や開発の振り返りなどを書きたいと思います。

ごはんサミットについて

概要

ごはんサミットは、家族で献立の相談と献立表の共有ができるアプリです。

作った経緯

我が家では、食事のたびに何を食べるかを先に家族で相談し、献立が決定してから食材を買いに行きます。
家族それぞれ好き嫌いが多いこと、食事の時間を楽しく過ごしたいこと、が献立を先に決める理由です。
今までは、献立の相談は対面かLINE、献立の記録は紙のカレンダーに記載して行っていました。
この「献立の相談」と「献立の記録」を１つにまとめて簡単に確認できるようにしたいと思い、「ごはんサミット」を作成しました。

使い方

家族を招待する

ログインすると献立表が作成されます。
献立表ごとに招待用URLを取得できるので、このURLを招待したい家族に教えてください。
初回ログイン時に表示されるウィンドウ、もしくはメニューから「家族を招待する」を開くとURLをコピーできます。

   


招待された家族は招待用URLにアクセスし、初回ログインをすることで家族の献立表に参加することができます。

献立会議をする

会議室は、献立表のそれぞれの日付にある右側の表から入れます。


食べたい料理が浮かんだら「提案する」、その他は「コメントする」で相談していきます。
リロードしなくてもリアルタイムで家族とやりとりができます。

youtu.be

献立を登録する

献立の登録方法は2パターンあります。

会議で提案した料理をそのまま献立表に登録する

「献立へ登録」から、食事タイミングを選択して献立表へ登録できます。

youtu.be
会議をせずに直接献立表に登録する

献立表から献立部分をクリックすることで直接献立を登録することもできます。

   

献立表を見る

トップページで週毎の献立表を確認できます。
メニューの「カレンダー表示する」から、月毎の献立表を確認できます。

   

技術スタック

工夫したところ

サービスに関して

献立の登録方法を2パターン設けた

献立の登録が全て「会議」を経由しないといけないのは、対面で献立を話し合い決定したときにとても不便だと思ったので、直接登録できるようにして登録方法を2パターン設けています。
これにより、献立の記録だけつけたい人にも使っていただけるようになっています。

会議室をリアルタイム通信にした

Action CableとTubo Streamsを使ってリアルタイム通信に挑戦しました。
Hotwireを学習していた際に、「こんなに簡単にリアルタイム通信が設定できるんだ！」と感動し、ぜひ取り入れたいと思いました。
実際、少ない設定で取り入れることができました。
まだまだ理解が足りない部分があると思いますが、挑戦して良かったなと思っています。

ユーザーアイコンを選択制にした

今回はユーザーアイコンをこちらで準備し、選択してもらう方法をとりました。
画像を保存する機能をファーストリリースでは含めないようにしようと考えていたのでその方法にしたのですが、結果としてサービスの雰囲気が統一されてかわいくなったので良かったと思っています。
12種類の動物から選択できます。

開発に関して

自作サービス進捗報告会に参加した

週に一回、自作サービス開発中の受講生とkomagataさんmachidaさんで進捗を報告するミーティングがあります。
用事がない限り、かならず参加するようにしていました。
他の受講生の報告は自分のサービスの参考になることがかなり多かったですし、APIとの連携など自分にはない機能を見ていてとても興味深かったです。
また、自分より先に進んでいる受講生の画面を見て「自分もはやく動くものを見せられるようにしたい」とやる気をもらっていました。

家族に使ってもらった

デプロイ直後から「ごはんサミット」を家族でずっと使っています。
１番のユーザーである家族からの意見を反映させることができて良かったですし、自分が今取り組んでいることを家族に見せることができて今まで以上に応援してもらえて励みにもなりました。

苦労したところ

新しい技術を取り入れたこと

特にHotwireとRSpecは完全に一から学習したので、なかなか大変でした。

Hotwireは、こちら（Hotwireかんたん入門）にあるように、まずHotwire: The Demoを視聴し、Hotrails、猫でもわかるHotwire入門 Turbo編、そして追加ではじめてのHotwire 〜Railsで作るSPA風チャットアプリ〜の3つのアプリケーションを写経して作りました。
結構時間はかかりましたが、基本の実装方法や挙動が分かったので時間をとってやって良かったと思っています。自分のサービスでもHotwireがうまく動いたときは嬉しかったです。

RSpecは、今までminitestしか書いたことがなかったのでEveryday Railsで学習しました。
テストが8割くらい書き終わったあたりでちょっと慣れたなと感じるくらいで、ずっと苦戦していたように思います。最後までRSpecで書き切れて良かったです。

デザイン

デザインと聞くだけでちょっと苦手意識があったので、最低限のデザインをいれるだけでもかなり時間がかかりました。今まで習ってきたCSSをTailwindCSSの書き方に置き換えて書くのも慣れるまでは大変でした。
試行錯誤してやっと入れたデザインも、次の日には文字サイズや位置が気になってきて直す、などなかなか納得いくものにならず進まなかったです。
デザインレビューでmachidaさんと直接お話しさせていただいて、たくさんのアイデアとアドバイスをいただきました。サービスのデザインもとても良くなりましたし、デザインの苦手意識が少しなくなって面白いなと思うようになりました。今後、機会があればデザインの勉強もしてみたいなと思っています。

Flakyなテスト

会議室画面でのテストで、ファイル単体では通るのに全体で回すと落ちるテストができてしまいました。
原因は、Action Cableが接続される前に投稿がされてしまっていたために投稿が反映されていないことでした。
対策として、接続が完了されてから画面を表示するようにChannelの設定とJavaScriptを追加しました。
Action CableとTurbo Streamsを使用して細かい設定をせずにリアルタイム通信ができてしまっていたので、これらの設定を追加するのに苦労しました。

開発者ツールでのエラー

デザインレビュー時にmachidaさんから、「500エラーが出る」と報告をいただき、devツールでデバイスを変更して操作するとエラーが出ていることに気がつきました。（私は406エラー画面を削除していたので500エラーになっていました）
エラーの原因・詳細は以下の記事に書きました。
Rails7.2でChromeDevToolsのデバイスモードを変更して操作するとエラーが出る［Ruby on Rails］ - motohiLog
machidaさんがおっしゃっていたエラーにたどり着くまでに時間がかかってしまったので、エラーの状況をもっと詳細に聴取できていればもっと早く解決できたのではないか、と反省しています。

今後取り組みたいこと

ファーストリリースの期限を自分で設定していたため実装できていない機能があるので、今後もサービスが良くなるように改善を続けていきたいと思います。

通知機能をつけたい

会議室のチャット機能には通知機能がついていないため、家族からの提案・コメントに気づけるようWebプッシュ通知を飛ばせるようにしたいと思っています。Rails7.2でWebプッシュ通知をするためのWebPush gemやService Workerのことなども学習してみようと思います。

買うものリストをつくりたい

献立に必要な買う食材をチェックリスト化する機能を追加したいです。

Railsをアップグレードしたい

Rails8.0から、Solid Cableがデフォルトで入っていることで、Action Cableを使用する際に必要なredisが不要になります。現在私のサービスではredisを使用しており、それによるデプロイ先の制限（redisの費用面など）があったりしたので、Rails8.0にアップグレードしてSolid Cableを使ってみようと思っています。
また、Rails8.1からはWebプッシュ通知のフレームワーク「Action Notifier」が実装予定だそうです。Railsの機能の一部としてWebプッシュ通知がとばせるようになるのは非常に興味深いので、Rails8.1がリリースされたらそちらもチェックしたいと思います。

おわりに

アイデア出しからデザインまでサービスを通してたくさんのアドバイスをくださったmachidaさん、リソース・DB設計からコードレビューまで丁寧にレビューしてくださったyuuuさん、困った時に的確にアドバイスをくださったkomagataさん、アイデアから実装に関する疑問までたくさんペアプロしてお話ししてくださったtadaakiさん、悩みをたくさん聞いてくださった受講生・卒業生のみなさん、本当にありがとうございました！

お使いいただいてお気づきの点があれば、ご意見や感想などをいただけると嬉しいです。

Rails7.2でChromeDevToolsのデバイスモードを変更して操作するとエラーが出る［Ruby on Rails］

Ruby on Rails

はじめに

フィヨルドブートキャンプで学習しています、もとひろです！
今回は、Rails7.2で起こるGoogleChromeの開発者ツール（以下devツール）でのエラーについて書きたいと思います。

フィヨルドブートキャンプで実施しているAdventCalendarの記事です。
「フィヨルドブートキャンプ Advent Calendar 2024 Part2」の8日目を担当しています。

Part1→フィヨルドブートキャンプ Part 1 Advent Calendar 2024 - Adventar
昨日はkyokucho1989さんの「時間とたたかうフィヨルドブートキャンプ 」でした。
Part2→フィヨルドブートキャンプ Part 2 Advent Calendar 2024 - Adventar
昨日はsugiweさんの「bootcampアプリにissueを立てるのが楽しい話」でした。

概要

Chrome のdevツールでデバイスモードを変更して操作しようとすると406エラーが出ます。
Rails7.2でデフォルトで設定されているallow_browser versions: :modernによるものです。

環境

Rails：7.2.2
Ruby：3.3.5
Chrome：131.0.6778.108

詳細

状況

Rails7.2で$ rails newしたアプリケーションを起動します。
（rails new、scaffold、migrateのみ実行し、作成されたコードをそのままサンプルとしています）
通常のChromeの画面では問題なく操作できています。

youtu.be

devツールでデバイスモードを設定します。
今回の動画では、iPhone14 Pro Maxに設定しました。
この状態で操作しようとすると、406エラーが表示されます。
リロードしてもエラーが変わりません。

youtu.be

原因

Rails7.2で$ rails newを実行すると、デフォルトでブラウザのバージョン保護機能が追加されています。
Ruby on Rails 7.2 リリースノート - Railsガイド

# app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  # Only allow modern browsers supporting webp images, web push, badges, import maps, CSS nesting, and CSS :has.
  allow_browser versions: :modern  ←これです
end


allow_browser versions:で設定されているバージョン未満のブラウザでサービスにアクセスした場合、406エラーを返すようになっています。
406エラーに関してはこちらを参考にしてください↓
406 Not Acceptable - HTTP | MDN

:modernで設定されるバージョンは以下のとおりです。
ActionController::AllowBrowser::ClassMethods

Chromeのdevツールでデバイスを変更してサービスを表示すると、例えばiPhoneであればSafariでアクセスすることになります。
Chromeのdevツール内のSafariやChromeのバージョンは低いです。

現時点でのChromeのdevツールで確認できる代表的なデバイスでバージョンを調べました。
devツールのコンソールでconsole.log(navigator.userAgent);と入力すると調べることができます。
（2024/12/7　Chrome： 131.0.6778.108）

iPhone14 Pro Max：Safari 16.6 Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1

iPhoneSE：Safari 16.6Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1

Pixel 7：Chrome 116.0.0.0Mozilla/5.0 (Linux; Android 13; Pixel 7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Mobile Safari/537.36

Samsung Galaxy S20 Ultra：Chrome 116.0.0.0Mozilla/5.0 (Linux; Android 13; SM-G981B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Mobile Safari/537.36

:mordenの基準に達していないのでサービス対象外となり、操作時に406エラーが表示されていました。

$ rails newした時点でデフォルトで406エラーページが作成されています↓
/public/406-unsupported-browser.html
406-unsupported-browser.htmlを削除していると500エラーでページが表示されます。

ちなみに、細かい調査はしていませんが、
FireFoxでもdevツールでデバイスを変更し操作すると同じように406エラーが表示されます。

私が行った対応

今回私がこのエラーに遭遇したのは、FBCのプラクティスにある自作サービスを作成している際だったので、メンターさんと相談し、開発作業中は一旦allow_browser versions: :modernをコメントアウトし、リリース前にコメントアウトを外して設定をONにする、という対応をすることになりました。
allow_browser versions: :modernをコメントアウトすると、devツールでデバイスを変えて操作できるようになります。

youtu.be

そのプロジェクトごとに開発・本番環境が異なると思いますので、それに合わせた対応が必要かと思われます。

参考リンク

余談

Rails8.0でもデフォルトで同じ設定が含まれるので406エラーが出ます。
ですが、406エラーページのレイアウトが違いました。

Rails7.2の406エラー画面
Rails8.0の406エラー画面
個人的にRails8.0の406ページがかわいいなと思ったのですが、みなさんはどう思いますか？😄

おわりに

間違い・ご意見等ありましたらコメントいただけたら幸いです。

アドカレこのあとも楽しみにしています！

Kaigi on Rails 2024に参加しました！

イベント

自己紹介

フィヨルドブートキャンプで学習しています、motohiroと申します。
完全未経験（元医療職）から学習を開始し、現在自作サービスのプラクティスに着手しています。

Kaigi on Rails 2024に参加しました！

2024/10/25~26で有明に行ってきました！
初めてのKaigi on Railsでとても楽しみにしていました🙌

kaigionrails.org

scrapbox.io

発表全体について

頑張ったらちょっとだけ理解できそうな発表があったりとか、そこまでいかないにしても単語は聞いたことがある発表があって、少しでも自分が分かるものがあって嬉しかったです！
それでもまだまだ難しかったですが、来年自分もWebエンジニアとしてパワーアップして聞きたいなと思える発表ばかりでした。

発表全体として、当たり前ですが、「Rails wayにのる」ことをとても重視されていたように思いました。
Rails wayの話を聞くたびに、今自分が作っているサービスがRails wayから外れていないかと不安になってコード確認しようか悩んだのを覚えています。
（確認し出すと止まらないのでその場で確認するのはやめました笑）

印象的だった発表

以下に印象に残った発表と感想を書きました。
初学者で、理解違いなどもあるかと思いますがご了承ください。
今の自分にはレベルが高かった発表や聞きそびれてしまった発表もあったので、またアーカイブを見つつ復習したいなぁと思っています！

10/25 基調講演 Palkanさん　Rails Way, or the highway

speakerdeck.com

まずスライドがおしゃれでかっこよかったです！見入ってしまいました。
Railsは、０（rails new）から１（最初の動作（リリース））までRails wayにのっていけば問題なく進められて、そのあと１からIPO（上場）までいくには？という始まりでした。
元々のRails wayのMVCから、どのように拡張していくのがよいのか、それは何かを混ぜるのではなく他と担当分野を分離したものを追加するということのようでした。
担当分野の分離には新しい抽象化が必要で、その新しい抽象化の4つのルールはちょっと難しかったです。
Formオブジェクトが最後に例ででていて、UIの画面もあったのでわかりやすかったです。
Rails wayから外れず正しく拡張していけば１から成長していくことができる、ということだったのかなと思いました。

igaigaさん　Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -

speakerdeck.com

フィヨルドブートキャンプ内でもお世話になっているigaigaさんの発表でした！
お昼休みに初めてご挨拶できたのが嬉しかったです！

行為を記録するモデル＝イベント型モデルであり、このイベント型モデルが適切に探し出せると責務が適切になって処理も適切に書けるし、そのモデルはRails wayにのった設計になっているとのことでした。ただ、責務がしっくりくるモデルが作れないときやテーブルに保存はしなくて良いけどモデルっぽいオブジェクトがあるときは、PORO（Plain Old Ruby Object）をつくることもあるそうです。ActiveRecordを継承せずテーブルと紐づかない、Rubyの素のクラス、がPOROなのですが、なんか聞いたことあるなと思ってたら、ぱRailsの467~477Pでやっていました。ぱRails。読んでてよかったです。
FatModelについて、私はコードの行数が判断基準なのかと思っていたので、「書き続けるとしんどい」かつ「いい分割方法がある」とき、という判断基準は良い知見でした。自作サービスで、自作バリデーションも条件分岐しているし、updateも条件分岐していて、それってFormオブジェクトが使えるのでは…？というモデルがあるので、Formオブジェクトを実装するのが適しているのかどうかはまだわかりませんが、今回のスライドとぱRailsなどをもう一度読んで必要ありそうであれば検討してみようと思いました！

kotatsuさん　推し活としてのrails new

speakerdeck.com

Ruby Kaigiで同じyada houseに宿泊したkotatsuさん！発表自体とても面白くあっという間に終わってしまいました！
最低限動くものを！最短でリリースを！という部分が我々のプラクティスの自作サービスにおいても一番大事な部分な気がして、そういう意味でRailsは本当に適しているしRails wayは大事で、基調講演で言ってた通り（０→１）だなって思いました。うまく言語化できないんですがとにかくかっこよかったです。kotatsuさん最高！
必要なものを最低限取り入れ、不要なものはいれない、の取捨選択が私のような初学者にはかなり難しいんですが、本当に大事な部分だと思ったので丁寧に見極めつつ、まずは最低限のリリースを目指して私も頑張ろうと思いました！

yana-giさん カスタムしながら理解するGraphQL Connection

speakerdeck.com

GraphQLのお話でした！GraphQLは以前少しだけ勉強したときに本当によくわからなかったのですが、 yana-giさんが最初にGraphQLについての説明をしてくださっていたので、なんとなくのイメージはできるようになりました！
1つのページを取得するときに、REST APIだとリソース1つに対して1リクエスト（GET）なのでproducts,categories,cart,viewerと４回APIを実行する必要がある＋不要なデータのattributesも含めて取得してしまうのに対し、GraphQLでは1つのリクエストで複数のデータ（products,categories,cart,viewer）を取得できる＋必要なattributesのみ取得できる、というメリットがあるそうです。
またページネーションの種類に、「オフセットページネーション」と「カーソルページネーション」があることを初めて知りました。
オフセット：ある地点から何個分、と指定してデータを取得
カーソル：ある地点からある地点まで、と指定してデータを取得
そしてGraphQLでのページネーションはカーソルページネーションはConnectionパターンというもので実装できるようですが、今回はオフセットページネーションで実装しなければならず、その実装方法がCustomConnection、というお話しだったのかなと思います。

卒業して頑張ったらあんなに難しいことができるようになれるのかな…👀✨すごいな…！！という気持ちで発表を聞かせていただきました！
CustomConnectionの具体的な実装は難しかったのですが、以前は理解できなかったGraphQLをminneのページで具体的に説明していただいたことでイメージできたことと、ページネーションの取得方法に種類があることを知れて学びになりました！

katty0324さん　リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果

speakerdeck.com

始まってすぐに「N organicじゃん！！！！！」って思いました笑
有名ですよね！すごい〜

ViewComponentのメリットがとても分かりやすかったです！
複雑なロジックがviewに入ってしまっていたり、条件分岐があったり、あちこちで使われている（再利用）場合に良いそうです。テストもviewのパーシャルではコンポーネント単位のテストはできますが、view vomponentならメソッド単位でのテストもできてテストもしやすく保守性が増すとのこと。
私の自作サービスで、現時点ではたとえばmodalは使用箇所が1箇所でそのままコードをベタ書きしてしまっていたりするので他でmodalを使う箇所が増えるようであればview componentで分離しても良いのかも知れないなと思いましたし、そういえばflashもパーシャルにしているけど条件分岐してけっこう煩雑な感じもするので、どちらも確認してみようと思いました。

TAKEYUWEBさん 現実のRuby/Railsアップグレード

speakerdeck.com

Ruby・Railsのアップグレードのお話でした！
アップグレードをするのに、思っていた以上の準備が必要で驚きました。
アップグレード自体もその具体的な手順やそのとき注意することなど細かく解説してくださり、元々「1つずつ順番に上げていく」というイメージはできていたものの、実際にこうやってやっていくんだ、というイメージがしやすかったです。
個人的には、「非推奨警告は将来壊れることがわかっているのですぐ対処する」とおっしゃっていたのが印象的でした。おっしゃっていることは当たり前なんだけれども、自分は正直（気をつけなきゃな〜）くらいしか思っていなかったので、今まで自分の認識が甘かったなと思わされました。
今まで同じサービスを運用保守していくという経験がないこともあるかもしれません。
今回のお話は今後働くときにはきちんと覚えておこうと思いました！
このご本人のZennの記事がお話ししてくださった内容も書いてあってとてもわかりやすかったです！！！

haruna-tsujitaさん　Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜

speakerdeck.com

Hotwire、TurboとStimulusのお話でした！
「Web紙芝居」の考え方は以前から知っていましたが、最初のボタンで画面遷移を考えているところになんの疑問も感じずお話を聞いていました。
その後見方を変えてCRUD操作による画面の切り替えはHotwireのTurbo、録画機能はStimulus、となったときに、たしかに👀！！！！！と腹落ちしたというか、なるほど！とめっちゃ脳汁出た感じがしました。笑
私の自作サービスはメインががっつりCRUD操作なのでそこはTurbo、その中でmodalを出したりとかをstimulusを使うようにしたので、考え方的に合ってたようで安心しました。
あと、何をどのように考えてどのように上司に相談して、という時系列順に発表してくださったことで、みなさんこうやって建設的に業務をされてるんだな、自分もこうやって働いていきたいな、とイメージできたのもとてもよかったです！
スライドの終盤の、Hotwire or React ?のまとめ部分はとてもわかりやすくまとめてくださっているので、自作サービスでHotwireがいいのかReactがいいのか、どの部分にどれを使えば良いのか悩んでいるフィヨルドブートキャンプ生にはとても良い判断基準になると思います！！ぜひ見てもらいたいです！！！

kozy4324さん　ActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)

speakerdeck.com

SQLインジェクションをクイズ形式で答えたりしましたが、がっつり間違えました。
SQLインジェクションの一般的な対策と、Rails側がやってくれている対策の説明がわかりやすかったです。
自分の自作サービスでは、いろんなところでいろんなparamsの受け渡しをしているので、paramsを雑に渡してしまっていないか、適切に対策しているかきちんと確認しようと思いました。
自作サービスはRails7.2なのでBrakemanはデフォルトで入っていたけれど、どの程度脆弱性を検出してくれるのか全然わかっていませんでしたが、むしろ偽陽性が多いくらい検出してくれるとのことで上手に使えば便利なことがわかって良かったです！

ykpythemindさん　OmniAuthから学ぶOAuth 2.0

speakerdeck.com

そもそもの認証と認可の違いから解説があり、自分が認証認可をあまり理解せずにいたことがわかりました。
認証は個人を識別すること（誰であるか）、認可は権限を与えること、だそうです。
自作サービスでOmniAuthを使ってGoogleログインを実装していますが、おまじないをそのまま書いているような状態だったのでどういったことが中で行われているのかの説明は興味深かったです。
OAuth2.0（認可）を拡張して作られているOpenID Connect（認証）というプロトコル（OpenID Connectの解説）があって、それを理解しておくとOmniAuthなしで自分でサードパーティログインが実装できるそうです。
自分の現在の知識では実装を理解することは難しかったので、具体的な実装の手順は、アーカイブで再度解説を聞こうと思っています。
今までOmniAuthに丸投げしていたのが、中身に興味をもてて良かったなと思いました！

ohbaryeさん　Data Migration on Rails

speakerdeck.com

data migrationのお話でした！
私はチーム開発のissueで小さいものですがdata migration用のファイルを書いていたので、あれか〜って思いながらお話を聞きました。（そのときのPR）
（フィヨルドのdata migrateについてはこちらを参考）

いろんな方法があるのだけれど、rake task,ruby scriptで行うのがアンケートによると一番多いらしいです。
たしかにBootCampアプリでも最初はrake taskでやってたという経緯が載っていました。
今回個々のやり方の特徴を聞いたことで、BootCampアプリがなぜ他の方法ではなくdata-migrate gemを使っていたのかの理由に納得がいったように思います。
BootCampアプリがdata-migrateというgemを使う理由として幾つか書いてありますが、PRで実装する人（例：私）とデプロイする人（例：komagataさん）が異なる場合がほとんどなので、PRをデプロイする前にrake taskを実行しなければいけないのにそれが忘れられることが起きやすい状況にあるため、との理由があって納得でした。デプロイ時に含まれるPRの数もその時々で結構多かったりするので、だったらデプロイする時に一緒にrake taskを実行してくれるほうがたしかに便利だな、と思いました。
自分がフィヨルドで学習しているとフィヨルドのやり方が最初に覚えるものだからその方法（今回だとgem）に固執してしまいがちなので、いろんなやり方があることが知れて良かったです！
DHHはBasecampではruby scriptを実行しているそうで、Rails8ではrails g scriptコマンドが入ってくるそうです。
アンケート結果でもrake task,ruby scriptでやっている企業が多いようだし、そちらの書き方も勉強したいなと思いました！

expajpさん　omakaseしないためのrubocop.yml のつくりかた

speakerdeck.com

私はRails7.2で自作サービスを作成しているので、rubocop-omakase gemが入っていることは知っていましたが（結局自分で設定しているので削除してしまいました）、有効に設定されている数が46/554と結構少ないということを知りませんでした。
実際にチームでrubocopのルールを作成していく上での苦悩とか、それを乗り越えるための対策工夫が、自分はやったことのないことなので聞いていて興味深かったです！
特に「表明の幅は広く、採決ルールは細かく」の説明にあったの具体的な対策（意見が割れたときのルールを設定、「気にしない」選択肢をいれる、希望のオプションを表明できるようにする）は、確かにこの対策がなされていたら話し合いしやすそう〜と思えましたし、実際それを実践してうまくいっていたのですごいなぁと思いました。
自分もいざ働くとなった時には、そのようなルールが整備されているチームで働きたいと思いました！

moroさん　Identifying User Identity

speakerdeck.com

「ユーザーがいること」という哲学の話のようなテーマが、しっかり技術で解説されていて、面白かったし聞いていて引き込まれました。
idだけをもつusersテーブルは、どのようなときに便利なんだろうと思っていたのですが、「たとえば無料ゲームとかログインいらないもののときはテーブルを分けておいたほうがいい」とおっしゃっていました。サービス利用時点でログインをしなくて良いということは、ログイン自体を障壁と思っているユーザーが離れることを防ぐことができる、という視点もなるほどと思いました。自分が使う側だったらどう考えてもログインしない方が気軽に始められて便利なのに、いざ自分が作るとなるとログインして当たり前というか何でもかんでもログインさせようとしてるかもしれない、と思ったりして視野が狭くならないように気をつけようと思います。
また、個人情報のテーブルをわけておくことで、ユーザーの退会時に個人情報だけ消すことができて、そのユーザーが存在した事実のみ残すことができる、という部分は目から鱗でした。私の自作サービスはチャット風の機能があり自分がユーザー削除しても自分が書いた文章はそのまま残るようになっていて、でも私のusersテーブルは1つに全部まとまっているので、ユーザー削除されてしまったらその人がしたコメントはそのまま残して退会者用のアイコン画像を出すようにしています。家族という小さい規模でのチャットなのでそれでも良いかなと思ってはいますが、usersテーブルから個人情報を分けておくことでユーザー削除時に個人情報だけ消してユーザーのアイコン情報は残しておけるので、そうするとその人がいた事実は残せるんだな、なるほどな、と思いました。
userはuserだから1つのテーブル、という盲目的な考えから新しい視点をいただけて勉強になりました！

10/26 基調講演 島田浩二さん　WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

speakerdeck.com

最初にソフトウェアを設計する際に大事だと考えていることとして2つのテーマをお話ししてくださいました。
１つめは、全体が機能するように設計する、というテーマでした。
アプリケーションを綺麗に作れたら終わりではなく、システム全体が機能して、システムとしてユーザーに価値を提供するという意識が大切とおっしゃっていました。データベースは円柱じゃないしサーバーはただの四角じゃない、とおっしゃってたときは思わずくすっと笑いましたが、あらい解像度でシステムを見てしまうというのはやってしまっているなぁと思いました。システムの構成要素と設計のパターンを知ることで適切なシステム構成ができアプリケーションをユーザーに届けられるともおっしゃっていて、自作サービスを作成していく上で、サーバーとかCDNとかのシステムのコンポーネントを全然よくわからない（そして正直今もよくわかっていない）なと思いながらもそのまま進めている部分があって、本来はきちんとそれらも学習してやっていくべきなんだなと反省もしましたし、でもそんなすぐわかるものではないし深いものだと思うので今後地道に学習していこう、とも思いました。
２つめは、変化に向けて設計する、というテーマでした。
設計開始時は一番何もわからない状態な訳でそこから今後の変化に対応してにはどうしたらよいか、ということで、オプションを手に入れるということでした。オプションは「将来的な選択肢を買う権利」で、どんな選択でもできるようにする、ということなのかなと思いました。そのとき「選択肢を広げて構えるということは、実際にはその選択肢の範囲になってしまうので狭めて待ち構えることになる。だからこそ、どの方向にも進めるようにシンプルに作る」とおっしゃっていたのが印象的でした。
たしかに、闇雲に走り出す（まだよくわかってないのにその選択肢を選んで実装しちゃう）わけじゃないにしても、左足を前に出して走り出す姿勢にしちゃってたら、いざ走る（変化に対応する）ってときには右足しか前に出せない（範囲が狭い）から、運動できる格好で運動靴でまっすぐ立てる状態にする（標準の道具で標準の方法で必要十分にシンプルに作る）ことでどの方向にも進める、ってことなのかな〜と思いました。
（思いついたので書きましたがわかりづらい例えになってしまいました…苦笑）
つまりはRails wayでRailsを使いこなすことが設計のポイントだそうです。
その上で、変化に向けてシンプルさを維持し続けることが難しいのであって、変化に適応し続けるには修復を続ける必要とのことで、修復とは、元に戻すということではなく、いろんな変化がそうあるべきで変化していったものなのだから変わった後の状態と調和し続けるようにすることだとおっしゃっていました。Railsもその時代その時代に合わせて変化していっている、修正され続けているとおっしゃっていて、確かにと思いました。
修復をする上ではProcess Feel（直感的に感じろ）が大事で、それを養うためには我々の認知負荷を減らすことが必要で、Railsは概念圧縮だったりOnePersonFrameworkだったりで認知負荷を減らすように作られているので、Rails wayに沿うことで修復箇所を感知する能力を高められるということでした。

今まではRailsでアプリケーションを作る、コードを書くということに集中して学習してきましたが、Railsはシステム全体の中の一部分に過ぎずシステムの構成要素それぞれに関しても勉強したいと思いましたし、Railsの考え方や思想的な部分も知りたいなと思いました！
そして今後も楽しむことを忘れないようにしたいです😄

会場＆懇親会

いつもフィヨルドでお世話になっているmoegiさんのデザインがあちこちにあって、とてもテンションがあがりました！🙌
会場ではたくさんの企業ブースが出ていて賑わっていてお祭りみたいで楽しかったです！
フィヨルドで普段お世話になっている方から初めましての方までいろんな方とお話ができて、みんな頑張っているんだなぁ私も頑張ろうって思えました！
また会場や懇親会の時にRuby Kaigiのときにお世話になったみなさんにもご挨拶できてよかったです！

まとめ

初参加でしたが、とても充実してたし楽しかったです！！！
来年は自分もWebエンジニアになってもっとパワーアップして、より有意義に参加できるようになりたいなと思いました！💪

発表者のみなさん、スタッフのみなさん、スポンサーのみなさん、本当にありがとうございました！

2024.7.4~2024.7.17【週報】2週分

週報

2週分の振り返り

目標と成果

目標 成果 反省・感想
Issue #7837のPR作成 ○ 1週内でできた
レビュー依頼がきているPRのレビューを全部する ○ レビューした

やったこと

2週分の学習時間

7/4 ~ 7/10

学習時間：29時間30分
学習日数：7日

7/11 ~ 7/17

学習時間：32時間15分
学習日数：5日

2週間にあった出来事＆感情

こうやってみると飲み会が多かったな…🍺

  • 前職の上司同僚との飲み会に参加した！
    人生で一番充実していた職場の方との飲み会でした！
    みなさん相変わらずで最高だったし、感極まって泣いちゃったし、ちゃんと二次会でカラオケも行ったし楽しかった〜！
    久しぶりに二日酔いになりました…

  • 夫の元上司の誕生会に参加した！
    いつもよくしていただいている上司の誕生会でした！
    久しぶりにお会いしたみなさん優しくて本当感謝です🙏

  • 夫の友人と鍋パした
    楽しく話せてよかった〜🙌

  • 髪を切った
    すっきり！

  • バイトにあけくれる
    半日ですが平日に追加出勤を多く入れています…暑いのつらい

今週の目標

今週の予定

  • バイト三昧
    がんばれ自分！