「現場で使える Ruby on Rails 5速習実践ガイド」を読んだ感想

こんにちは！

今回は「現場で使える Ruby on Rails 5速習実践ガイド」を読んだ感想についてまとめます。

現場で使える Ruby on Rails 5速習実践ガイド

現場で使える Ruby on Rails 5速習実践ガイド

Amazon

対象読者

  • 何か他の本や動画でRailsの全体像を学んだ人
  • 実際にRailsで開発してみたことがある人

良かったところ

  • 基礎知識を深掘りしていくのに最適
    • 最初の一冊にするには基礎知識の説明が不足しているが、その分発展的な内容が多い
  • テスト技法について学べる
  • チーム開発に向けた必要事項を学べる
  • MVCに則った設計技法を学べる
    • 初学者向けのRailsの本とは思えないほど詳しく学べる

悪かったところ

  • Rubyの入門知識は対象読者には不要と感じる
  • slimで書かれているので慣れるまで認知的負荷がかかる

学んだこと

  • マイグレーション
    • バージョンを上げて終わりではなく、確実に下げられるように記述する
    • db:migrate:redoでバージョンを下げても問題ないか確認する習慣をつける
  • JavaScriptとの連携
    • AjaxとRailsを組み合わせた動作
    • Turbolinks時の注意点（<script>の記述位置など）
  • MVCでのコードの書き方
    • ビジネスロジックをコントローラからモデルに移す方法
      • 複雑なparamsは一括代入できるようにして対応する
      • オブジェクトの代入や処理の呼び出しはコールバックや統合的なメソッドで対応する
    • ビジネスロジックをビューからモデルに移す方法
      • モデルの状態を判断するロジックは～?のような名前のメソッドを作ると扱いやすい
    • モデル、コントローラ、ビューそれぞれの共通化の方法
      • 共通化の前提は、コードがあるべき場所に書かれていること
      • 共通化の方法：モジュール、継承、サービスオブジェクト
    • サービスオブジェクトの作り方、使い方
      • 意味のまとまりで処理を集約し、別オブジェクトとして独立させる
      • 複数のモデルを扱う処理では、コントローラに処理を書くのではなく、独立したサービスオブジェクトを作る
      • モデルに書くべき処理は書かない。ドメインモデル貧血症を避ける

難しかったこと

  • CSVの扱い、Jobスケジューリング、webpacker
    • 実際に使ったことがないのでイメージが掴みにくかった

おわりに

今回は「現場で使える Ruby on Rails 5速習実践ガイド」を読んだ感想についてまとめました。

本書はRailsの3冊目ぐらいの本に最適だと思います。

特に設計についての章が良かったです。実際に開発してみるとどうしてもコントローラにロジックを書いてしまったり、ビューにロジックを書いてしまったり、モデルが空っぽだったりしてしまっていたので、それらの具体的な対処方法が書かれていて参考になりました。早くこの内容を生かしてコードを書いていきたいと思います。

REST APIとは

こんにちは！

今回はREST APIについてまとめます。

REST APIはRESTの原則に則ったWeb APIのことです。 では、それぞれの用語についてみていきましょう。

APIとは

Web APIとは

  • Webサービスを外部から利用するためのインターフェース

RESTとは

  • REpresentational State Transferの略
    • 2000年にRoy Fieldingが論文で発表
    • Webサービスを設計する際の原則
  • 原則として次の6つが挙げられる
    • クライアント/サーバー
    • ステートレス
    • キャッシュ制御
    • 統一インターフェース
    • 階層化システム
    • コードオンデマンド

クライアント/サーバー

  • クライアントとサーバーで役割を分担する
    • クライアントが画面（UI）を表示
    • サーバーがデータを処理

メリット

  • それぞれの役割を分離することで、片方だけの変更を可能にする
    • クライアントだけの変更や、サーバーだけの変更を可能にする

ステートレス

  • メッセージのやり取りにおいて、前回メッセージの内容を保持しない
    • 一つのリクエストに全ての情報が含まれる
    • 状態はクライアントが保持する

メリット

  • サーバーはリクエストだけで必要な情報を取得できる
  • 呼び出し順序を気にする必要がない

キャッシュ制御

  • ステートレスなAPIではリクエスト量が多くなるため、サーバーからのレスポンスをクライアントが保存して再利用する

メリット

  • ユーザーの体験が向上する
  • 同じデータを何度も返す必要がなくなる

統一インターフェース

  • サーバーとクライアントが共通の言語で通信することが出来るようにする
    • URIやCRUDなどが挙げられる

メリット

  • 統一インターフェースを守る限りにおいて、サーバーとクライアントを独自に開発することができる

階層システム

  • 特定の機能と役割を持つサーバー（コンポーネント）が階層を構成するような設計

メリット

コードオンデマンド

  • クライアントがコードをダウンロードして実行する

メリット

  • リリース後にコードの更新が可能
  • クライアントが処理をするため、サーバーの負荷が下がる

REST APIとは

  • RESTの原則を適用した（RESTfulな)Web APIのこと
    • REST APIはあくまでも原則であり実装ではない

メリット

  • URIとCRUDを用いた場合のようなシンプルな設計になる
  • ステートレスな設計により、サーバー側の処理を簡単に分散させることができる

おわりに

今回はREST APIについてまとめました。

あくまでも論文の中で提案された設計の考え方なので、6つの原則でなく、4つの原則として紹介する人もいますね。どちらにしても、現在ではほとんどのWebAPIの基礎となっている考え方のようです。Railsで開発する際にもRESTの考え方がベースになっているので、しっかりとイメージを掴んでおきたいですね。

「達人に学ぶDB設計 徹底指南書」を読んだ感想

こんにちは！

今回は「達人に学ぶDB設計　徹底指南書」を読んだ感想についてまとめます。

達人に学ぶDB設計徹底指南書: 初級者で終わりたくないあなたへ

達人に学ぶDB設計徹底指南書: 初級者で終わりたくないあなたへ

Amazon

良かったところ

  • DB設計について論理設計と物理設計の両側面から学べる
  • 「勘どころ」というワンポイントアドバイスがたくさんある
  • 第一正規形～第三正規形のほかに、ボイスｰコッド正規形や、第四正規形、第五正規形についても学べる
  • DB設計を通して、技術を学ぶ姿勢についても学べる
    • 「概念の有効性がわからなかったら、『それがなかったらどうなるか』を考えてみよう。」など
  • コラムでDB設計に関する素朴な疑問などを取り上げている
    • 「バッドノウハウのどこが悪いのか？」
    • 「主キーはなぜ必要か？」
    • 「（正規化について）わざわざ理論として教えられなくても、そのぐらいのことは論理設計をやる人は常識的にやっていることではないか？」など

悪かったところ

  • エンティティの抽出 、エンティティの定義、ER図の作成といったテーマについては、それほど演習があるわけでもないので自分で経験を積むか別の本にあたった方が良い

学んだこと

  • DB設計はデータの整合性とパフォーマンスのトレードオフである
  • バックアップおよびリカバリの設計をおろそかにすると”新聞に載る”
  • 複数形で書けないテーブルにはどこか間違いがある
  • 正規化は可能な限り高次にする
  • 非正規化は最後の手段（劇薬）である

難しかったこと

  • インデックス、統計情報、入れ子集合モデルといったテーマについてはDBの運用経験が乏しく理解が難しかった

おわりに

今回は「達人に学ぶDB設計　徹底指南書」を読んだ感想についてまとめました。

この本の著者のミックさんは他にもSQL基礎の本などDB関連の本をたくさん書いています。どれもDBへの深い理解を元に書いていることが感じられるので、他の本についてもまた機会を見て読んでいきたいと思います。

スッキリわかるSQL入門を読んだ感想

こんにちは！

今回はスッキリわかるSQL入門を読んだ感想をまとめます。

スッキリわかるSQL入門 第3版 ドリル256問付き! (スッキリわかる入門シリーズ)

スッキリわかるSQL入門 第3版 ドリル256問付き! (スッキリわかる入門シリーズ)

Amazon

良かったところ

  • 最初の1冊に最適
    • 図解が豊富
    • キャラクターと一緒に学ぶので敷居が低い
    • 簡単な内容から説明するように順番が工夫されている
    • SQLを使ってみるところから、表計算ソフトとの違い、データベース設計まで基礎知識を幅広く扱っている
  • 章ごとに練習問題があり復習しやすい
    • 講義、まとめ、章の内容の練習問題という構成なので復習しやすい
    • 解答も問題の次のページについているので確認しやすい
  • ポイントを押さえた解説
    • SELECT、UPDATE、DELETE、INSERTの4大命令を分類して覚えやすくしている
    • SQL文のおすすめの記載順序など覚えやすくするための工夫がある
  • ボリュームたっぷりなドリル256問
    • 章末の練習問題とは別に本の最後にドリルがある
    • こちらのドリルは章末の練習問題よりもさらに手強い

学んだこと

  • SELECT、UPDATE、DELETE、INSERTの分類方法
  • SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BYの記載順序
  • 集約関数
  • サブクエリ
  • データベースの設計

難しかったこと

  • テーブルの結合
    • ONの結合条件を指定するのがややこしい
  • 連番の取得（採番テーブル、シーケンス）
    • DBによって方法が異なったりしたり、実際に使ったことがないという点で難しかった

おわりに

今回はスッキリわかるSQLを読んだ感想についてまとめました。

3か月ほど前に読んだ本の再読です。今勉強中のRailsだと素のSQLはあまり操作しないので、SQLを忘れかけていた部分がありますが思い出すことが出来ました。

本自体が分かりやすく、練習問題も豊富なのでSQLを始めようという方にはとてもおすすめな本でした。

Rubyのoptparseの使い方

こんにちは！

今回はRubyのoptparseの使い方についてまとめます。

optparseとは

  • コマンドラインのオプションを取り扱うライブラリ
    • opt -> オプション
    • parse -> 解析

使用例

require 'optparse' # optparseの読み込み
opt = OptionParse.new # OptionParserオブジェクトを生成

opt.on('-a') # オプション -a を受け付ける

opt.parse!(ARGV) # オプションの解析
  • ARGV: Rubyスクリプトに与えられた引数を表す配列
    • 組み込み変数$*の別名

parse!/parseメソッド

  • ARGVの解析を行う
  • onメソッドにブロックが指定されている場合、parse!/parseが呼ばれたときに実行される

parse!とparseの違い

  • 例: ruby sample.rb -a foo bar

parse!の場合

  • parse!はARGVから-aなどのオプションを削除する
    • ARGV自体を書き換える
p ARGV # => ["-a", "foo", "bar"]
opt.parse!(ARGV)
p ARGV # => ["foo", "bar"]

parseの場合

  • parseはオプションを残す
p ARGV # => ["-a", "foo", "bar"]
opt.parse(ARGV)
p ARGV # => ["-a", "foo", "bar"]

どのオプションが呼ばれたか記憶する

  • 例: ruby sample.rb -a foo bar -b baz

    方法1

params = {}

opt.on('-a') { |v| params[:a] = v }
opt.on('-b') { |v| params[:b] = v }

opt.parse!(ARGV)
p ARGV # => ["foo", "bar", "baz"]
p params #=> {:a=>true, :b=>true}
  • ブロックパラメータvには、オプションが存在するかどうかの真偽値が入る

方法2

params = {}

opt.on('-a') { |v| v }
opt.on('-b') { |v| v }

opt.parse!(ARGV, into: params)
p ARGV # => ["foo", "bar", "baz"]
p params # => {:a=>true, :b=>true}

引数を受け取る

方法1

  • 例: ruby sample.rb -a foo bar -b baz
params = {}

opt.on('-a VAL') { |v| v }
opt.on('-b VAL') { |v| v }

opt.parse!(ARGV, into: params)
p ARGV # => ["bar"]
p params # => {:a=>"foo", :b=>"baz"}
  • onメソッドのオプション定義の末尾に文字列を書くと、そのオプションが引数を受け取ることの指定になる
    • 文字列はなんでもよい
      • ヘルプの見栄えが良くなるように書く
    • 引数を省略すると例外が発生する
      • オプションが必須でないときはon('-a [VAL]')と[ ]をつける

方法2

params = ARGV.getopts("a:b:")
p params # => {:a=>"foo", :b=>"baz"}
  • optparseをrequireすると、ARGV.getoptsが使えるようになる
    • 引数を受け取る場合は文字列:
    • 引数を受け取らない場合は文字列

おわりに

今回はRubyのoptparseの使い方についてまとめました。リファレンスマニュアルにはほかにも詳細な指定方法などが乗っていますが、細かい指定が必要ない場合はgetoptsを使うのがお手軽ですね。

100/100

「プロを目指す人のためのRuby入門」を読んだ感想

こんにちは！

今回は「プロを目指す人のためのRuby入門」を読んだ感想をまとめます。

プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus)

プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus)

Amazon

良かったところ

  • 内容が網羅的
    • 文字列や数値、真偽値など一つ一つの項目に対してそんなに色々あるのかと驚くほど細かい知識まで教えてくれる
    • メソッドや書き方をたくさん知ることができるので、実際に実装しようとしたときに「あれが使えそうだな～」と引き出すことができる
    • 逆に全然思いつかないときは、やり方自体が全然違うのではと疑えるほど一つの項目に対して網羅している感じがある
  • 文章がわかりやすい
    • 難しい内容をわかりやすく伝えようとしてくれている
    • 技術書などでありがちな、「この文章はどっちの意味なんだろう？」といった疑問を抱かせないようなわかりやすく明確な文章
  • テスト技法を教えてくれる

悪かったところ

  • 特になし
    • 本自体の問題ではないが、強いて言うなら題名通り「プロを目指す」ようなレベル感の本なので、Rubyを学び始めてすぐに読むと挫折する
    • Rubyの入門書を数冊こなして、本書の目次を見て大体内容が分かるぐらいで読み始めると丁度良いのではないか

学んだこと

難しかったこと

  • Comparableモジュールと<=>演算子
  • ラムダ
  • パターンマッチ などはまだ理解しきれていない

おわりに

今回は「プロを目指す人のためのRuby入門」を読んだ感想をまとめました。

実は最初に読んだのは4か月ほど前で、今回は改めて例題を自分で解きながら読んでみました。前回は例題は0からでは歯が立たず、解答を見ながら進めましたが、今回は大体自分で解くことが出来たので成長を感じることが出来ました。

本書は、初心者がステップアップするために必要だと思われる知識を詰め込んだ本になっています。一見重箱の隅をつつく様な内容に感じるかもしれませんが、それぞれの知識を学ぶことで出来ること出来ないことがわかるようになり、実装の方法を考えやすくなるというメリットがあると思います。

Rubyに慣れてきたと思うぐらいの時期にやると最適な本だと思いますので、該当すると思われる方は是非一度じっくり腰を据えて読んでみてください。

99/100

RailsをDockerで構築した際に引っかかったエラー

こんにちは！

今回はRailsをDockerで構築した際に引っかかったエラーについてまとめます。

環境

エラー① ActiveRecord::ConnectionNotEstablished

エラー発生タイミング

  • docker compose up後、ブラウザからlocalhost:3000へ接続

エラー文

connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
Is the server running locally and accepting connections on that socket?

エラー内容

解決策

  • config/database.ymlにhost: dbの指定を入れ忘れていた
    • dbはdocker-composeでpostgresqlのコンテナにつけた名前

エラー② ActiveRecord::DatabaseConnectionError

エラー発生タイミング

  • docker compose up後、ブラウザからlocalhost:3000へ接続

エラー文

There is an issue connecting to your database with your username/password, username: "ユーザー名".
Please check your database configuration to ensure the username/password are valid.

エラー内容

  • username/passwordで接続できない
  • username/passwordを再確認せよ

解決策

  1. docker-compose.ymlのenvironmentで指定しているuser/passwordと、config/database.ymlのusername/passwordが一致しているか確認

  2. 一致させた上で、以前のdbを削除し、再度ビルドすることで新しいusername/passwordを登録する

    • volume mountをしている場合
      • docker container , image, volumeの中でpostgresqlを含むものを全て削除する
    • bind mountをしている場合
      • ホストの該当ディレクトリを削除する
      • ./tmp/db:/var/lib/postgresql/dataであれば、/tmp/dbを削除

エラー③ ERROR [web internal] load build context

エラー発生タイミング

  • docker compose upでビルド中

エラー文

------
 > [web internal] load build context:
------
failed to solve: error from sender: open /mnt/c/Code/rails-docker/tmp/db: permission denied

エラー内容

  • build contextを読み込めない
  • /tmp/dbが開けない

解決策

  • カレントディレクトリに.dockerignoreファイルを作成し、該当フォルダをbuild contextに含めないようにする

.dockerignoreの中身

tmp/db

エラーの原因

  • docker-compose.ymlにbuild: .と記載している場合、dockerはカレントディレクトリのすべてのファイルをbuild contextとして送信しようとするが、該当のフォルダがdocker composeの実行ユーザーの権限で読み込めずにパーミッションエラーになっている

参考:

teratail.com

エラー④ActiveRecord::ConnectionNotEstablished

　エラー文

connection to server at "IPアドレス", port 5432 failed: FATAL: password authentication failed for user "root"

エラー内容

  • rootユーザーのパスワードが一致しない

解決策

  • docker-compose.ymlのenvironmentに、POSTGRES_USER: ユーザー名を追記し、ユーザーを作成する

エラーの原因

  • ユーザーを作成していないのでrootユーザーで認証しようとしている

おわりに

今回はRailsをDockerで構築した際に引っかかったエラーについてまとめました。Dockerにも大分慣れてきたところでしたが、思いがけずエラーにたくさん遭遇しました。ただ、これらの対処を通して更にDockerの理解が深まったので良い経験になりました。

98/100