コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

他愛もないことでも書くということ

雑記

RailsのTipsとか書いていると 他のブログでも書いてるじゃん とか そんなん本腰入れて調べれば出てくるじゃん みたいな部分はあるんですが、これは自分自身の反省があって 他愛でもないことでも書こうかな と思った次第です

記憶のindexとして

5営業日あったときに…

  • 月曜日 :Aアプリの Bigqueryで集計用のクエリをつくる
  • 火曜日: Aアプリの集計用のデータサマリをRailsタスクでつくる
  • 水曜日: BスマホアプリのAPI設計をswaggerで書く、Androidコードレビューをする
  • 木曜日: Bスマホアプリ用APIサーバのterraform設計を読む、AMIを作るPackerを直す
  • 金曜日: Cアプリの大きな機能のコードレビュー（フロントのJS込み）、BスマホアプリAPIの実装

みたいなことがあったりするんです。コンテキストスイッチ切り替えられまくりなんですよ。

これだけ切り替わると細かなTipsとか調べられることは結構抜け落ちることが多くて、それこそ「 Terraform の workspace を変えたいときってどうするんだっけ？」みたいになるわけです。(実はQiitaの記事も結構その側面が多い）

なのでこのブログはある種のindexとして使っていきたいなという意味も込めてどーでもいいことを書いて行きたいと思っている次第です。

この時点では使えるTipsなんだよ、という記録として

こと技術のTipsというのはバージョンなどで情報は陳腐化して、ときには間違いになってしまうことさえあります。

そのため日付付きのブログと書くことで「この時点では有効な手段であった」という証左になるかなと思い、それもいいのかなと思った話です。

関連リンク

Railsでエラーページ表示の確認をdevelopmentでしたいときに変えるconfig

Tips

エラーページって何がでるんだっけ、という確認をしたい時に。

デフォルトでは

# config/environments/development.rb
# Show full error reports.
config.consider_all_requests_local = true

developmentだとこの設定がtrueになっているのでfalseにする

この設定の意味は？

このフラグがtrueの場合、どのような種類のエラーが発生した場合にも詳細なデバッグ情報がHTTPレスポンスに出力され、アプリケーションの実行時コンテキストがRails::Infoコントローラによって/rails/info/propertiesに出力されます。このフラグはdevelopmentモードとtestモードではtrue、productionモードではfalseに設定されます。もっと細かく制御したい場合は、このフラグをfalseに設定してから、コントローラでlocal_request?メソッドを実装し、エラー時にどのデバッグ情報を出力するかをそこで指定してください。

Railsのconfig/enviroments配下を読んでみる - Qiita

参考ページ

Railsのコンソールをいちいちexitせずに再読込する。

Tips

bin/rails c でコードの挙動を見ながら直すときに、逐一 exit をして再読込するのはめんどくさい。

そのときに使うのが reload!

[1] pry(main)> reload!
Reloading...
=> true

みたいになって再読込される。 ただし reload! 以前に変数代入したオブジェクトやインスタンスは変更前の状態なのでその点は注意。

参考サイト

あとだいたい pry-rails を入れていたので忘れがちだったんですがこれは pry-rails の拡張だとあとで知る

既に三日坊主になりつつある

雑記

技術的なことメインで書こうとするとなかなかネタが続かないのと、書く時間がとれない（今も翌日に前日分書いている始末）

日頃からネタをためておかないとダメだなということで今日の記事は箸休め的なもので、明日分はちゃんと書きます。。

今日書きたいことはそんなところです。

Docker for Macがつらいので開発はローカルでやることにした

雑記

最近の開発はもっぱらRuby On Railsなんですが、Docker化したほうが便利だろうという大雑把な考えから導入を頑張ってみた。

頑張った結果、起動出来るまでには至ったのだが凄まじく重い。どうやらホストマシンであるMacをマウントをすると重いらしい。

ただ、Webサイトを動かして、デバッグする分にはなんとかなるんだけど、rubocop とか rspec を手元で動かそうとすると途端に辛くなる、iOSアプリのビルドかよというレベルで待たされる。

しかたなくとりあえずローカルマシンでも動かせるように書き換えたけど、これってDockerをVagrantで動かす選択をしない限りはダメな話なんだろうか…

参考にしたサイト

Terraform の workspace を変えたい

Tips

terraformで環境切り替えで使われる workspace の機能 新しくつくるとかはわりと乗っているんだけど、既存の切り替えに関しては言及されていない。

切り替える方法は以下

$ terraform workspace select {{workspace名}}

Qiitaに書くほどじゃないし、だけど日本語情報が全然ないし、公式ページにも言及されてないし -h しないと出てこないので.

そもそものworkspaceに関して

1日1記事書こうという宣言

雑記

良質なインプットはアウトプットが伴って成立する、というような言葉を耳にして ちゃんと定常的にアウトプットしないとなという気持ちになる。

ただ

・時間的にとれない
・どうしても質を意識してしまう

というところがあるのでそこらへんのルールをゆるくして

・割りと質が微妙な話やポエミーな話はブログに
・かっちりとした技術記事はまとまったらQiitaに

というコンセプトで今日からやっていこうと思う。 三日坊主にならないように頑張ろう…。