Railsのredirect_to 〇〇_url , status: :okにしたら動かないという誰得情報の共有
TL;DR
redirectのステータスは3で始まるコード、だから:ok # 200 だとリダイレクトしない！
HTTPのリダイレクトの原理が以下のページに示されています。
リダイレクトレスポンスはステータスコードが 3 で始まり、 Location ヘッダーがリダイレクト先の URL を保持しています。
以下にRailsのredirect_toのstatusで使用できるシンボルと対応するコードと説明が示されています。
備考
201だとredirect_to動きました、 3で始まるコード限定でredirect_to動いているわけではなさそうです。。:bow:
redirect_to, status: で明示的に指定しなかったらdefaultで302 :found が使用されるっぽいです
参考文献、注意喚起
301でユーザーに永久キャッシュさせちまった後の対応方法 knmts.com
MVCのDomain Modelってなんやねんなお話
はじめに
今回は以下のサイトを読んでいる時に感じたことや思ったことを綴っていこうと思います。
The Model layer represents the domain model (such as Account, Product, Person, Post, etc.) and encapsulates the business logic specific to your application.
上記のサイトの引用を見る限りでは抽象度的な名前(具体的な例)のようにdomain modelに対しての説明がなされています。
domain model(アカウント、商品、人、投稿など)がdomain modelの具体的な例として挙げられています。ほうほう、これらがdomain modelなのか、私は今現在domain modelがわからないので具体的なものを知ることでdomain model抽象的なものの概念を掴もうとしています。この具体的なものから法則を見つけることを抽象化または帰納法といいます。
そんな抽象化とかいうめんどくさいことしなくても良くない？と思ったそこのあなた、法則(抽象的なこと)を知っておくと良いことがあります。それは似たような事柄に出くわした時に法則(抽象的なこと)を当てはめることでまだ実際に見たことがない、出会ったことがない、経験したことがない事柄について推測を行うことができます。抽象と具体や帰納や演繹については以下の記事がすごくわかりやすいと思うのでぜひ目を通してみてください。
example: 抽象的なことを知っていると役立つことの例
when: 迷路に迷い込んだ時(前提：入口と出口は繋がっている、迷路の出口と入り口は平面で見た時に外側にある、迷路の壁は全て繋がっている)
case1: 法則(抽象的なこと)を知らない人の場合
実際に無作為にいろんな道を進んでみることで迷路を抜け出そうとする。
case2: 法則(抽象的なこと)を知っている人の場合
壁沿いに進むことでに出口にたどり着きます
こんな感じで知っているか知らないかだけで有利に進むことができます。もちろん出口がないとか出口が迷路の内側にあって迷路の壁が繋がっていない部分があった場合は例え法則を知っていても脱出することはできません(この場合は伊之助みたいな猪突猛進な人が割と早く脱出するかも)が、前提条件が間違っていなければほぼ確実にゴールに辿り着けます。
とまあこんな感じで寄り道をしたのですが結局何がいいたいのかというと、抽象的なこと(domain model)を知っておくと良いことがあるぞ！ってことを言いたいわけです。
現状のDomain Modelに対しての解釈
まずは言葉を見ていきましょう、
Domain(領域)
つまりDomainとはこういうことです。
ああ、そういうことねって理解できちゃった人は後は読み飛ばしてもらっても構いません。
何を言っとるんじゃい！？って人はもう少しお時間頂きたいと思います。
ではここで五条さんが展開したDomainを外から見てみましょう
そうですこれがDomain(領域)の姿です。つまり私たちが住んでいるこの世界のある領域を切り取った(五条さんは丸く切り取っています)ものがDomain(領域)です。
世界におけるある領域のことをDomainと言います。
だけど世界におけるある領域をそのままプログラミングの世界に持っていくことはほぼ不可能です。なぜなら情報量が多すぎるからです。原子とか素粒子とか色々、、
詳しくわよくわからないですが、
プログラミングの世界(なんでも0と1で表す世界)ではDomain(領域,概念や現実世界の対象物, りんご🍎、人👦 etc)をmodeling(簡素化) することで現実世界の対象を表現しています。
domain modelは 現実世界の対象物を簡素化してプログラミングの世界で表現したものをdomain modelというのかなと思っています。
ちょっと時間がなくて最後に急速に雑な解説になってしまいましたが、今のdomain modelに対しての解釈をネット上に共有できたのでよしとしよう。。
また暇があったら最後の方ももっとわかりやすく綴ってみたいと思います。ではまた👋
スッキリわかるSQL入門読んでみた！
はじめに
今回はスッキリわかるSQL入門を読んだ感想を綴っていこうと思います。
挫折した経験
突然なのですが今回の本を読む前にデータベースの基礎を学ぼうと思って以下の書籍を使って学習を始めたのですが、0章の環境構築で挫折してしまいました。
この本も分かりやすそうだったので購入したのですが、環境構築はやはり初学者にとっては大きな関門になると思います。
今回購入したスッキリわかるSQL入門ではその環境構築をほぼ行うことなくSQLについて動かしながら学べるようになっています！
以下のサイトにアクセスするだけですぐにデータベースとやり取りして必要な情報を格納したり引き出したりする言語であるSQLを実行してフィードバックを得ながら学んでいくことができます！
dokoql.jp
よかったところ
本書を読むまではデータベースに直接SQL文を送っていると思っていたのですが、実はそうではないことを知りました！
私達とデータベースの間にはDBMS(database managenent system)がいるのです。
そして本書ではDBMSを擬人化して効率の悪いSQLを私たちがDBMS君に送った時にはDBMS君が非常に辛そうな顔をしています。
そういった絵でSQL文を表現してくれるので非常に分かりやすいなと感じました！
また、データベースの正規化といった難しそうなことも、正規化していく手順を1つずつテーブルの図で具体的な例を用いて表現してくれたのですんなりと理解することができました！
本書を読み終わった今なら、本書を読み返しながら正規化ができると自信を持って言えます！
まとめ
本当に読んでよかった、今ならデータベースの操作、テーブル作成、DB設計、正規化ができるし、トランザクション、ロック、ACID、これらの意味やなぜ存在するのかが説明できるし、何より本書を通してサクサクと実行してSQLたちが手に染み付いてる気がします！初めてのSQL学習はこれで決まりだね！スマホで隙間時間に学べるのは神⭐️
↓Amazonから買えるらしいです
プロを目指す人のためのRuby入門を読んだ感想
- はじめに
- 各章の感想
- 1~13章
- 全体の感想
はじめに
今回はプロを目指す人のためのRuby入門、いわゆるチェリー本🍒を読んだ感想を綴っていこうと思います！
分厚さで読むのにどれくらい時間がかかりそうか判断できるのは紙のいいところだと思います！それにしても分厚すぎます笑
各章の感想
1章-本書を読み進める前に
この章でエディタの設定や参照すべきソース(公式リファレンス)などを知ることができました！
最初にエディタの設定をしたをしたことで効率的にその後の章の実践課題を進めることができました！
私のエディタ(vscode)の設定を下に載せておきます！
エディタ設定
コメントアウト(cmd + /)
一括コメントアウト(cmd + a && cmd + /)
短形選択(始点をクリックしてから、終点を［Shift］［Option］＋左クリック)
タブ移動(ctrl + tab)
右２列レイアウト(ctrl + ¥)
ファイル名検索(cmd + p)
コマンドパレットを開く(cmd + shift + p)
vscodeの背景画像設定拡張機能 ❗️vscodeのcss fileを直接拡張機能で修正しているのでvscodeから少し怒られます。
2章-Rubyの基礎を理解する
この章でRubyの基礎文法、標準ライブラリと組み込むライブラリと外部ライブラリの違い、公式のコーディング規約はないが比較的有名な有志の規約があること、その規約をファイルの保存時に自動で適応してくれる方法があること、式(Expression,値を返す)と文(Statement,値を返さない)の違い、参照の概念、p,ppが開発者向けの出力メソッドであること、自作プログラムはrequire_relativeで読み込むことなんかを知ることができました！
この章を進める中で実際にFizzBuzzプログラムを書いてアウトプットすることで学んだ知識をより定着させることができたなと感じました！
3章-テストを自動化する
この章で「プログラマの三大美徳」
- 怠惰 「全体の労力を減らすために手間を惜しまない気質」
- 短期 「コンピュータの動作が怠慢な時に感じる怒り」
- 傲慢 「自分の書いたプログラムは誰に見せても恥ずかしくないと胸を張って言える自尊心」
を知ることができました！
2章では作成したFizzBuzzプログラムが正常に動いていることを目視で確認していましたが、この章を終える頃にはその目視で確認する手間をコンピュータにやらせることができるようになります！(素晴らしい！これぞ怠慢)
4章-配列や繰り返し処理を理解する
この章で配列やブロックや範囲、Rubyにおけるミュータブルとイミュータブルなオブジェクト、繰り返し処理とその制御構造を学ぶことができました！
この章でも実際に手を動かしてプログラムを作っていくので学んだことが定着していくのを実感しました。
各用語が端的に説明されている点や配列やブロックや繰り返し処理のメソッドがどのように動くかを詳細に説明している点に魅力を感じました！(10人以上のレビューを潜り抜けてきた用語への信頼感は半端ないなと感じました)
本書を読まなかったら、こうやって動くはずだよな〜という曖昧な仮定に基づいてプログラミングを行なってエラーを頻発させることになっていたと思います。(今では実際の挙動に基づいて判断ができるようになっていると感じています)
5章-ハッシュやシンボルを理解する
この章でハッシュやシンボルを学ぶことができました！
この章でも実際に手を動かしてプログラムを作成するので学んだことが定着したなと感じました！
シンボルと文字列の違いなんかも丁寧に解説されてて、なぜ文字列ではなくシンボルを使うのか？といった疑問に答えてくれるような内容となっていました。
こういった質の良い情報をたくさんインプットすることで良質な判断材料が増えて、コードの質が高まっていくのかなと感じました。
6章-正規表現を理解する
この章では正規表現の便利さを実感しそれを実際に使ってみることができました！
この章が終わる頃には今まで避けてきた呪文のような正規表現/(\d{3})-(\d{4})/が読めるようになります！
文字列の操作も自信を持って臨めるようになります！
7章-クラスの作成を理解する
この章でオブジェクト指向の基礎知識を学ぶことで現実にあるものをプログラムを使って表現できるようになりました！
この章を進める中で、改札機と切符をプログラムで表現することができるようになりました！
このプログラムを作る中でシーケンス図(クラスやオブジェクト間のやり取りを時間軸に沿って表現する図)というものを知ることができます。
実際に手を動かしてプログラムを作る前に、プログラムの流れを図で表すのは重要だなと感じました！
8章-モジュールを理解する
この章ではモジュールを学ぶことができます。
小規模なプログラムを作成している間はあまり必要にはならないそうです。
大規模なプログラムやオープンソースライブラリの開発に関わる場合はモジュールの知識が必須になってくるそうです。
軽く目を通してみたのですがすぐに必要にならなかったこともありあまり頭に入ってきませんでした。
Railsなどを学び始めてモジュールが出てきたタイミングでまた本書に戻って読み返してみたいと思っています。
9章-例外処理を理解する
この章では例外処理を学ぶことができました！文法の話だけではなく、例外処理はどのように使うと適切(または不適切か)を学ぶことができました！
他のプログラミング言語でいうExceptionがRubyでいうところのStandartErrorクラスであるという点には驚きました。
こういった知識も本書を読んでいなかったら知らないままだったので本当に読んで良かったなと感じました。
この章あたりからはすごく難しくなってきたので本書の筆者がお勧めしていた読み方(頭の中にインデックスを作る)に切り替えました。
頭の中のインデックス
例外を捕捉して処理を続行する場合 🍒p369
例外処理の流れ🍒p369
例外オブジェクトから情報を取得する 🍒p372
クラスを指定して捕捉する例外を限定する 🍒p373
例外クラスの継承関係を理解する 🍒p374
継承関係とresucue節の順番に注意する 🍒p375
永遠に実行されないrescue節を作らないためにはスーパークラスよりもサブクラスを手前に持ってくるようにする。
StandardErrorとそのサブクラスを捕捉するのであれば
rescueのみで良い(例外クラスを指定しない)例外発生時にもう一度処理をやり直すretry 🍒p378
無条件retryで無限ループを発生させないために、カウンタ変数でretryの回数を制限する。ネットワークエラーなどの一時的に発生している問題が例外の原因であれば何度かやり直すことで正常に実行できる可能性がある
意図的に例外を発生させる 🍒p379
例外処理のベストプラクティス 🍒p381
- 安易にrescueを使わない
- rescueした情報を残す
- 例外処理の対象範囲と対象クラスを極力絞り込む
- 例外処理よりも条件分岐を使う
- 予期しない条件は異常終了させる
- 例外処理も手を抜かずにテストする
プログラミング初心者は「例外が発生したら即座に異常終了させよう」もしくは「フレームワークの共通処理に全部丸投げしよう」と考える方が安全。Railsでは例外発生時の共通処理が最初から組み込まれている
例外をrescueしたらその場で情報を残さないと詳細な情報が失われてしまう、手がかりが多いほど原因調査は楽になる
例外処理を書く場合は、例外が発生しそうな箇所と発生しそうな例外クラスをあらかじめ予測し、その予測を例外処理のコードに反映させる。
例外処理を書く前に公式リファレンスを読んで、問題の有無を事前に確認できるメソッドが用意されていないかチェックすべし
ensure 🍒p392 例外の有無に関わらず実行する処理
ensureの代わりにブロックを使う 🍒p393
ファイル処理のように「使用したら必ずリソースを解放する」という処理はRubyではブロック付きのメソッドを使うことで自動的に処理できるケースが多い。なのでensure説を自分で書く前にそういった便利メソッドが用意されていないか公式リファレンスを確認する癖をつけるべし
例外処理のelse 🍒p393 例外が発生しなかった場合の処理
例外処理と戻り値 🍒p394
begin/endを省略するrescue修飾子 🍒p396
$!と$@に格納される例外情報 🍒p397 可読性を考えると組み込み変数を使わない方が好ましい
例外処理のbegin/endを省略できるケース 🍒p397
rescueした例外を再度発生させる 🍒p399 プログラム自体は異常終了させ、その情報はログに残したい時に使うテクニック
独自の例外クラスを定義する 🍒p399
10章-yieldとProcを理解する
この章ではブロックを利用するメソッドの定義とyield、Procオブジェクトについて学ぶことができるようです。
この章の内容もすぐには頭に入ってこなかったのでRailsの学習を始めてから-> { }やyieldこんな記述が出てきたら本書に戻って読み返してみたいと思います。
11章-パターンマッチを理解する
この章ではパターンマッチの基本や利用パターン、ガード式や１行パターンマッチなどの応用的な使い方を学ぶことができるそうです。
配列やハッシュのデータ構造に着目して条件分岐をさせたいときはパターンマッチが活躍できるそうなので、その際にまた本書に戻って読み返したいと思います。
12章-Rubyのデバッグ技法を身につける
この章ではバックトレース(スタックトレース)の読み方、よく発生する例外クラスとその原因、プログラムの途中経過を確認する方法、汎用的なトラブルシューティング方法を学ぶことができます。
バックトレースとは「プログラムが実行されてエラーが発生するまでのメソッド呼び出し履歴を示した情報のこと」と本書に記されています。
この情報を読み解けるようになることでエラーを早く解決できるようになるそうです。
またよく発生する例外クラスとその原因を知ることでスタックトレースに記されている例外クラスをパッとみただけでどこを修正すれば良いのかが分かるようになりました！
これは本当にすごいことで、何か間違ったことをしてもエラーが実行時に教えてくれるんです！
今までは読む気になれなかったけど読めるようになると逆に今までなんで読んでこなかったんだ〜って思いました。
デバッガを用いて対話的にデバッグすることでデバッグの効率が上がるなと感じました。
汎用的なトラブルシューティングのパートでは小さなパーツがどういう挙動をするのかをirbで確認することであったり、ログを読む大切さ、公式ドキュメントをむべき理由やパソコンの前から離れる大切さなんかを学ぶことができました！
この章は目から鱗のような情報がたくさん詰まっていました！
本書の中の実践課題をやる中でエラーに遭遇し途方に暮れることがあると思うのですが、その時こそこの章を読むべきタイミングなのではないかなと感じました。
13章-Rubyに関するその他のトピック
この章では様々なトピックを「広く・浅く」解説していました。
その中でも印象に残ったのはRailsの中のRubyと素のRubyには違いがあるというトピックです。
Railsの中のRuby独自の挙動があることを事前に知ることができて良かったと感じました。
