ねこものがたり

こちらはRails Girls Japan Advent Calendar 2020 24日目の記事です。前回は@ericgpksさんのRails Girlsに助けてもらった1年でした。

自分の中の”私は教わる側”意識

私がガールズとして参加したのは2017年のRails Girls Tokyo 8thでした。

その後現在に至るまで、Rails Girls後の継続的な支援の場として開催していただいている Rails Girls Tokyo, More! に参加しています。

Rails Girlsにもガールズとかコーチという役割はあるんですが、本編と異なり「私はガールズに申し込みました」という形ではなくて、Facebookの出席登録で参加表明になるという仕組みになっています。

プログラマーとしてお仕事についてしばらくしたあたりから、「私は今日ガールズか？？？」と薄ら違和感を抱きはするものの「コーチです！」ともいえない自分がいて、「自分の中の”私は教わる側”意識が消えないな」ともやっと感じるようになりました。

私にとってのコーチと自分

自分がガールズとして参加したRails GirlsやRails Girls Tokyo, More!では、コーチがこんなふうに見えていました。

なんでもすぐに教えてくれる
なんだか自信に満ちている
もう何年もプログラマーとしてやっている
とにかく経験も知識もある

実際、あとで話を聞いたりいろいろな方と直接お会いしたりするようになって「あの時のあの人はこんなにすごい人だったのか」と知るパターンばかりだったんですが、「コーチってそういう人がやるものなんだ」というハードルの高さのような、自分はまだまだすべての要素が及ばなさすぎるという気持ちがありました。

今の自分にあるものを値踏みしないこと

よく「いい質問が成長の鍵だ」というような記事をみます。それは本当にそうだと思います。私も良い質問を怖じずにやっていきたいと日頃から心がけています。

それと同時に、自分の中の”私は教わる側”意識に気付いて以降周りを見渡していて気付きました。「質問を怖じないのと同じくらい、自分の経験や知識をオープンにしすることを怖じなくてもいいし構えなくてもいい」と。

知識や理解ではなくても、ちょっとした疑問とそれに対する自分の考えも、アウトプットをすることを惜しまない方がみんなが良い方向に向かうことが多いかなというのは仕事でもよく感じています。

そういう日々を過ごしているうちに、アウトプットの延長に、教えるという行為もあるのかなと思うようになりました。

Rails Girls Tokyo 12thではコーチをしました

私が初めてコーチをしたのは、Rails Girlsに参加してからは2年後、2019年に開催されたRails Girls Tokyo 12th。プログラマーに転職して半年強の頃でした。

当初コーチに応募するかどうかとても迷っていたけれど「”誰かの背中を押したい”という思いがある人にコーチをやって欲しいんだよ」という言葉を聞いて応募して、コーチとしてRails Girls Tokyoに参加することになりました。

実際当日は、ガールズーコーチの間だけではなくコーチ間でも助け合いがあって、slackなどで「こんなふうに詰まってて困っているのだけどわかる人いませんか？」とか「ここってどうですかね？」というやりとりがあったので、自分でもなんとかやれたかなと思います。

そんなこんなでもちろんコーチとして十分役割を全う出来るよう事前準備は頑張るんですが、「教えなきゃ！」と思いすぎなくてもいいなと肩の力が抜けたのを覚えています。(でも次やったらその時よりはうまくやりたい！とは思っています。)

まとめ

唐突にまとめますが、これまでの日々を経て、今では「教える側ー教わる側」とバッサリ二分する必要はないなと思っています。

もちろん圧倒的に学ぶことが多いことは自覚しています。でもだからと言って「自分には教えられること・伝えられることはない」とは思わなくていいし、自分が何気なく当たり前のように思っていることも、話してみると意外と「えーそうだったんだ！」という反応だったりします。なのでそういうオープンで自由なやりとりをしていけばいいかなというのが今の気持ちです。

今はオンラインで開催されているRails GirlsTokyo, More!ですが、次回参加する際も「ガールズかな？コーチかな？」な感じで参加して、「教えてください！」って言ったり「あーそれってきっとこうですよ」と言ったりしていれたらいいかなと思っています。

そしてコロナ禍が明け、次にRails Girlsが開催できる時にはコーチに応募するぞと思っているので、来年は安穏な一年になるよう心から願いを込めて、Rails Girlsも開催できますようにと祈りながらこのエントリーを締めさせていただきます。

みなさま、今年も一年間ありがとうございました。

このエントリのきっかけ

業務で開発してるRailsアプリケーションにRails.envがたくさんあって、「環境を整理したい」「デフォルトに寄せたい」という話が沸いています。「それはそう」って思ってしばらく過ごしていたんですが、あるときふと「何故？」って聞かれたら自分は説明できないなと気付いたので、これを機によく理解しておこうと思いました。この記事は"備忘録"と言うやつですね！（私の場合備忘録じゃないブログエントリほとんどないですが）

デフォルトのRails.env

デフォルトのRails.envはdevelopment, test, productionです。rails new したらこの3つの環境が備わっています。それぞれどう言うものかという詳細は productionやdevelopment、stagingという言葉の使い分けについて｜TechRacho by BPS株式会社がまとまっていてわかりやすいと思いました。

productionモード
本番モードで、動作中にソースコードが編集されない前提が取れるため、クラスキャッシュなどをアグレッシブに保持して効率化ができる（config.cache_classesやconfig.eager_load）
静的ファイル配信はRailsサーバーからではなくnginxなどの手前Webサーバーから配信させる前提の設定（config.public_file_server.enabled = false）がされている

developmentモード
起動中にソースコードが編集されてもRailsサーバーの再起動不要で変更結果が反映される（config.file_watcherやconfig.cache_classesの無効化など）
開発者のローカル環境ではいちいちnginxなどを立ち上げなくても良いように、public以下の静的ファイルもRailsサーバーが配信する（config.public_file_server.enabled = true）

testモード
developmentモードに近いが、さらにCIやターミナル前提の設定などが付く（consider_all_requests_local = :stderr）

新しい環境を作る方法

Rails アプリケーションを設定する - Railsガイド

config/environments/staging.rb を作ればstagingができます。 staging.rbの中には必要な設定項目を記載します。

stagingを作らない方がいい理由

Rails が標準として環境追加の機能を備えているのに、どうして「それはダメです」と言う声が多いんだろう？ここから先は私が調べたり、現場で体感したりしたことのまとめです。

そもそもステージング環境とはなんだ

「検証環境」と言う言葉でさもそれらしい認識はしていた私ですが「ちゃんと説明して」と自問してみるとどうやら理解が浅いぞと気付いたので調べてみました。

ステージング環境 (staging environment)がとってもわかりやすかったので拝借します。

できるだけ実際に使うときの状況（本番環境）に似せて作った動作確認用の場所（テスト環境）のこと

できるだけ実際に使うときの状況（本番環境）に似せていると言うのがstagingのポイントのようです。

config/environments/staging.rb でステージング環境を作成するデメリット

上述のように config/environments/staging.rb を config/environments/production.rb と同じ設定内容で作成すると名前は別だけれど設定は同じになります。では何故ダメなのか？内容同じにすれば本番環境と同じになるならよくない？という気も（ほんの少し）してきました。

でも長期的な運用を考えたときに「設定内容の同期が不確実」と言う懸念点が挙げられますそれはつまり、production.rbを変更をしたときstaging.rbも変更しないといけない（逆もまた然り）で、「本当にこの環境は十分本番に似せ切れているのか？」を担保し切れなくなってしまうかもしれません。本番にリリースして問題ないか確認するためのステージング環境なのに前提が崩れてしまう可能性をはらんでいます。

どのようにステージング環境を用意すると良いか

思い切って（？）ステージング環境もconfig/environments/production.rbを使いましょう。でもconfig/environments/staging.rbをそのまま使っているだけではそれはただの本番環境なのでステージングになりません。どうすれば？？

本番とステージングで環境で同じにするもの・差分が必要なもの

どうすればいいんだろう整理する為に、何を使い分けると良いのか考えてみると以下のようになるのかなと理解しています。

同じにするもの：基本的に全て

変えるもの：本番と同じにしてはいけない値

本番環境と同じであることを基本として、本番と同じものは使えない値だけを変えると良いようです。アプリケーション全体で言うとDBの接続先を本番用じゃないDBにする等、config/environments/production.rbファイル以外のconfigの値の方が注意を払わないといけない対象が多いように思います。

config/environments/production.rbを共有しながら値を使い分ける方法

production.rbの設定値を環境変数の参照にすると良さそうです。 rails sに何かフラグを渡せるようにして、それによって参照先も変える方法があります。

まとめ

stagingを追加するのがよくない理由は、要するに本番環境同等の環境の担保の問題だと理解しました。

この記事を書いていて、production.rbの設定でステージング環境も動かすためにも、秘匿情報やAPIやDBの参照先、何かの通知設定など本番と同じにしてないけないこと・分けておきたいことは何かを整理して事故のない運用と品質の担保をしていきたいと思いました。