あるある！？ web開発初心者がやらかしたこと7選

この記事は Sun* Advent Calendar 2024 10日目の記事です。

はじめに

こんにちは、Sun* という会社で Backend Engineer をやっております、2024年度新卒の Campanule と申します！

今年から本格的に web 開発に取り組み始めましたが、その際にいろいろなやらかしをしてしまいました。ちょっとしたことから大惨事に繋がりかねないことまで、様々です。
そのため、今後同じことを起こさないよう、備忘録として残しておこうと思います。

なお、筆者の使用言語・フレームワークが Ruby on Rails（以下 Rails）であるため、Rails を使用していない方には馴染みのない概念も取り扱います。あらかじめご了承ください。

想定読者

• 個人 or チームかかわらず、web 開発を始めて間もない方
• 新人時代を思い出したい方
• 新人が引っかかりやすいポイントを知りたい方

目次

• やらかし1. .env の更新に気づかず時間を溶かした話
• やらかし2. master.key がなくて詰みかけた話
• やらかし3. main への直 push を止めていなかった話
• やらかし4. パラメータが長すぎて Cookie が溢れた話
• やらかし5. GitHub Actions とローカル環境の構成の差異に気づかなかった話
• やらかし6. GitHub Actions の無料枠を使い切ってしまった話
• やらかし7. GUI 信者すぎて、CLI がまったくわからなかった人の話

やらかし1. .env の更新に気づかず時間を溶かした話

これは慣れてきた人でもけっこうあると思っています。開発環境上で環境変数をいじる際には .env ファイルを使うことが多いと思いますが、これをそのままリポジトリに push してしまうと機密情報がリポジトリ内に入ってしまう可能性があります。

これを回避する手法としては、たとえば .env.example といったファイル名にしたうえで、アクセスキーなどの機密情報を blank にしておくなどといったものが挙げられます。

ここで、この .env を誰かが更新し、その情報を必須とするような機能が追加された場合どうなるでしょうか。

簡単なものだと、たとえば以下のようになると思います。

.env

UNANNOUNCED_CONSTANT="required"

上記のファイルがない状態で、以下のコードを実行しようとすると…

example.rb

unannounced_constant = ENV.fetch('UNANNOUNCED_CONSTANT')

KeyError が発生してしまい、処理が止まってしまう

そうですね。エラーが起きます。

エラー画面が出るならまだしも、エラーハンドリングが適当な場合「不明なエラーが発生しました。」しか出てこないこともあり、原因の特定に苦労します。

また、ENV.fetch を用いる場合は第二引数にデフォルト値を入れることもできますが、これに気づかずバグの原因を見つけられないことも多々あります。

筆者の場合、外部 API へのアクセスキーをもらっておらず、そのまま API を叩こうとした結果エラーが発生したこともあります。つらい。

.env を更新する際には、特に大事な情報の場合はチームで共有するようにしておきましょう。レビューの際には特に忘れてはいけません。時間を溶かします。

やらかし2. master.key がなくて詰みかけた話

これは Rails を使っている人に限る話ですが、Rails では新しいプロジェクトを作成したときに master.key というファイルが生成されます。

これは credentials などを使用する際に使われ、これがないと秘密鍵の生成および使用ができないなど、不利益を被ります。

こちらも credentials.yml.enc に関してはリポジトリに push されることがほとんどですが、一方で master.key がそのまま push されることはまずないでしょう。機密情報ですから。

master.key がないとどうなるか。たとえば、Rails.application.credentials.secret_key_base を用いた暗号化ができなくなってしまいます。

secret_key_base の値を確認してみましょう。

対応した master.key がないとき

secret_key_base が取得できず、返り値は nil になる

対応した master.key があるとき

secret_key_base を正常に取得できる

このように、鍵となるファイルがあるかどうかで credentials が使えるかが変わってきてしまいます。

たとえば以下のような認証・認可に使用することもあり、これでは開発が進まなくなってしまいます。
筆者はこれで3日無駄にしました。

example.rb

def create_token
  payload = {user_id: @user.id, exp: 1.week.from_now.to_i}
  secret_key = Rails.application.credentials.secret_key_base
  token = JWT.encode(payload, secret_key)
  token
end

チームで開発する際には、Rails プロジェクトを作成した人は責任を持ってメンバーに master.key を渡すようにしましょう。忘れてはなりません。

やらかし3. main への直 push を止めていなかった話

Git をいじっているとき、作業するブランチを間違えてしまうことがよくあります。

例えばバグの原因を探す際に、main branch の状態を見たいとします。ここで、main から ブランチを切ることを忘れて、main で作業したとしましょう。

バグの原因が見つかり、修正するための Pull Request を投げるために一旦 origin に push します。すると…

main branch に push したことを知らせる通知が届いてしまった

あ。やべ。

作業ブランチを切っていなかったがために、main に直接 push してしまったのです。

幸いすぐ異常に気づき、チームメンバーに報告のうえ revert 作業を行うことで事なきを得ましたが、誰も気づかずに作業が進んでしまうと大惨事になり得ます。

場合によっては、数千・数万行単位の進捗が失われてしまうこともあるでしょう。

そうならないよう、大事なブランチには誤 push を防ぐための Ruleset を設けておくことを強くお勧めします。

Settings（Project の場合は管理者権限がないと進めません） -> Rules -> Ruleset から設定できます。

直 push を防ぎたいだけなら、最低限 Require a pull request before merging にチェックをつけましょう。

大事なブランチには Ruleset をつけて守ろう

Ruleset による main branch の保護についてもっと知りたい方はこちらの記事をご参照ください！

やらかし4. パラメータが長すぎて Cookie が溢れた話

Rails のセッション管理はデフォルトでは Cookie になっています。

ここで、長い文章をセッションで保持したい…となるとどうなるでしょうか。

送る文章の例としては以下のようになります。

lorem_ipsum.txt

"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras convallis et sapien a facilisis. Donec diam diam, consectetur at egestas sit amet, pretium ac nunc. Donec sit amet purus ipsum. Pellentesque eget hendrerit eros, ut sodales velit. Curabitur a mi maximus orci gravida sodales. Etiam vel porta justo. Integer aliquam, dui quis egestas hendrerit, nibh augue vehicula urna, ut fermentum est tortor at quam. Cras nec ligula ut erat luctus laoreet. Aliquam vel eros felis. Suspendisse non quam venenatis, rutrum dui eget, interdum ipsum. Praesent risus risus, convallis quis odio id, iaculis dapibus elit. Fusce non urna lacus. Nulla sagittis convallis lacus ac dictum. Mauris ultrices, ex sit amet auctor imperdiet, mauris nulla semper turpis, id tristique erat odio non ipsum. Proin fringilla posuere neque sit amet auctor. Nulla mattis mattis bibendum.

Sed pellentesque imperdiet erat sed fringilla. Quisque quis cursus risus. Ut suscipit quam at sapien efficitur consequat. Quisque eu convallis justo. In eget est ut lacus auctor posuere at nec sem. Quisque dictum massa id ante tristique, posuere ornare erat fermentum. Aliquam ac libero non massa blandit pretium. Donec nec fringilla magna. Suspendisse purus mi, mollis vel scelerisque vitae, rutrum ac sem. Nunc semper massa a leo molestie, in vestibulum odio blandit. Nam vel dui et justo lacinia posuere.

Etiam sit amet nisi vestibulum, pellentesque tortor non, pulvinar magna. Morbi quis urna fermentum, mollis massa sed, congue felis. Etiam lectus nunc, congue ac ante venenatis, porta volutpat nisl. Ut pharetra nunc in metus congue tempus. Donec at ultrices massa. Sed viverra felis in odio laoreet fringilla. Donec pulvinar nulla et aliquam facilisis. Ut varius non felis eget viverra. Etiam in convallis sapien. Maecenas ante purus, scelerisque sed hendrerit eu, laoreet a magna. Nullam a malesuada ante. Praesent porttitor tellus congue ipsum faucibus, vitae elementum quam pharetra. Cras semper sem nec eleifend aliquet. Sed at metus in augue egestas feugiat. Aliquam eros nibh, convallis non hendrerit vitae, scelerisque non dolor.

Donec et felis mollis, fringilla nisi non, ullamcorper sem. Nullam eget erat interdum, facilisis nisl suscipit, pulvinar felis. Praesent non condimentum est. Vestibulum tincidunt risus nunc, imperdiet tristique diam dictum vel. Etiam congue auctor neque, eget vulputate enim auctor id. Cras sed posuere ante. Curabitur in iaculis enim. Curabitur auctor nisi ut enim mattis dictum. Ut non viverra ipsum, ut eleifend risus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam a enim quis ligula tincidunt sollicitudin a consectetur erat. Cras bibendum augue non nulla tristique efficitur. Morbi aliquet velit a augue efficitur volutpat."

これを保持するために Cookie を使うと、以下のようなエラーが発生します。

CookieOverflow というエラーが発生してしまった

なぜなのか。

そう。Cookie には 4KB の容量制限があるのです。

こんなクソデカパラメータを保存しようとしてしまっては、4KB 制限を越えてしまい、Cookie が溢れてしまっても仕方ないです。

やむを得ずセッション管理に Cookie を使用する際には、容量制限に気をつけましょう。

大きいパラメータを保持しておきたい際や Cookie の使用にこだわりがない場合には、Redis を用いるほうがよいでしょう。

Redis 導入における参考記事

やらかし5. GitHub Actions とローカル環境の構成の差異に気づかなかった話

上記のとおり、セッションの管理方法を Cookie から Redis に変更し、GitHub に投げようとしました。

このとき CI/CD (GitHub Actions) により自動テストを行ってくれるのですが…

なんか RSpec でコケてる…

なぜなのか。ローカル環境では †ALL GREEN† なのに。

何度やってもだめ。エラーメッセージを見てみると、redis://redis:6379 に接続できないとのこと。
ローカルでは接続できるのになんでうまくいかないの？

おそるおそる workflow を見てみると…（一部のみ掲載）

workflow.yml

jobs:
  rspec:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    services:
      redis:
        image: redis:latest
        ports:
          - 6379:6379
        options: --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 10

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0.5

…なんだこれ。構成がローカル環境と違う。
でも redis://redis:6379 に繋がらないのは意味がわからないが…？

調べてみました。

ホスト名について、VM ベースでは localhost になり、container ベースでは redis になるとのこと。

知らなかった…こんなことになっているとは…

このように混乱の原因になりうるため、環境構成は基本的に大きく変更しないか、するとしたら環境に依存する箇所を把握しておいたほうがよいでしょう。

特に筆者のような新人は詰みます。詰まずとも5時間は溶かします。

やらかし6. GitHub Actions の無料枠を使い切ってしまった話

慣れてきて開発スピードが上がる中、あるとき急に GitHub Actions が使えなくなってしまいました。

デプロイ時に急にエラーを吐き出した

なんでや…今まで普通に動いてたじゃん…

エラーメッセージを読むと、「利用枠を増やす必要があります。」 とのこと。
はて…？と思いながらエラーメッセージで調べてみると…

ほんまや。というか無料枠とかいう概念あるんだ…

実際に利用枠を確認してみると…

利用枠を使い切った旨のメールが届いていた

ほんとだ…使い切ってる…

何を隠そう、開発スピードの向上に伴い、GitHub Actions の無料枠 2000分 を使い切ってしまっていたのです。

こうなると、追加課金をしないと開発を継続できず、チームは1日間まともに動くことができなくなりました。

使用状況は Billing から見ることができるのですが、権限が足りないと見ることができない模様。

使用量が利用枠の 75%, 90%, 100% になったタイミングでメールによる通知が届くため、たとえば使用量が 75% に到達してメールが届いたタイミングで、開発スピードなどを考慮して制限解除の検討を行うのがよいでしょう。

やらかし7. GUI 信者すぎて、CLI がまったくわからなかった人の話

唐突な自分語りになりますが、筆者は GUI 信者です。
幼少期から PC を使い始め、ずっと GUI を使い続けてきました。
CLI なんて見た日には、泣きながら親に「なにこれ…なんかバグった…？」って相談しに行っていました。

そんな筆者が terminal を見るとどうなるでしょう。

そうですね、アレルギーを起こしてしまいます。

今でこそ少しはマシになりましたが、それでも Git に関しては未だに GitHub Desktop に頼っている状況。

そんな筆者がチームメンバーとコミュニケーションをすると…

筆者「今起こってる不具合の特定をしたいんですけど…！たぶんここなんですけど…！」
Aさん「じゃあとりあえず git checkout <commit hash> してください」
筆者「あぇ…？なにそれ…？」

…話が通じなくなります。 CLI 派と GUI 派で戦争が起きます。

Git は CLI で使う人がほとんどだと思うため、こうならないためにも普段から CLI を触っておくべきでしょう。

クラウド開発環境を構築したり SSH 接続でサーバを動かしたりして、CLI に触れる機会を増やしてみるとよいです。

GUI に頼りたくなることはよくありますが、少しずつ矯正していきましょう。（自戒）
…という筆者は、未だに GUI から離れられないのですが…

おわりに

最後までお読みいただき、ありがとうございました！

今回は筆者がやってしまったやらかしと、その対策方法について述べました。

初心者のうちは、知らず知らずのうちにやってしまうこともたくさんあります。
細かいミスも含めれば、本当に数え切れないほどのミスをすることでしょう。

ただ、ミスをしてしまってもそこからのリカバリを考えることで、新たな気づきを得て人は成長していきます。

新人だからといってやらかしを恐れず、たくさん挑戦してみましょう！ 後の糧になります！

明日は和泉さんのリードエンジニアについての記事です！お楽しみに！