Ruby on Rails 5 速習実践ガイドを読んで

Ruby on Railsでのアウトプット課題の前にRuby on Rails 5 速習実践ガイドを読みました。
内容を覚えているうちに感想をまとめてみます。

良かったところ

Railsのタスク管理サービスを最初はシンプルに動くように、後半になるにつれ認証機能や他ユーザーが勝手にタスクを消せないような設定など実用的な機能を実装していく流れになっています。実用的な部分は普段自分が使うサイトの裏側の設計の大変さがよくわかりました。
また、Railsでの設計を始める前に必要なRubyの基礎知識、RESTfullな設計の考え方などRailsを使うための前提知識も少し載っているので書いてある通りに作ったらできた、という感じではなく知識を積み上げながら進められます。Railsの頻出コマンド一覧も載っていて分からなくなった時便利です。

学んだこと

Railsを使うとき作られるファイルの役割がよくわかっていなかったのですが一覧で役割が載っていたのでProgateやUdemyでは触れられないファイルの存在理由が分かりました。
また、実用的な部分で学んだこととして個人情報の入力した後に内容確認画面を表示する設定を作る場面があるのですが設計が複雑でありメンテナンスが大変、なお且つユーザー側も確認画面があってもあまり見ないなど必ずしも管理者、ユーザーともにwinwinにならないと知れて勉強時はこう学んだから、参考にしたサイトはこう作られているからという理由で何も考えずに作るのは良くないと知りました。

難しかったこと

書籍のGemfileのバージョンと現在のものが違う関係でGemfileの設定を変えないと動かない部分がありしばらく原因が分からず焦りました。また、RubyやDockerを学びはしたのですが編集するところが多く全ては覚えていません。
10章ではバージョンアップしやすいような書き方とバージョンアップへの対応とについて書かれていたのですが対応したことがないので参考になりましたが全ては理解できてないです。

まだアウトプットを始めるのはこれからなので何度も読み返すことになりそうです。
ここまでご覧くださりありがとうございました！

RESTについてまとめてみました

RESTの学習を行ったので一度まとめておきたいと思います。

参考にしたUdemy講座はこちらです

RESTとは

アメリカの学者が2000年に定義したもので、REpresentational State Transferの頭文字から取ってRESTといいます。
日本語に訳すと「分散型システムにおける設計原則群」といいます。 もう少し分かりやすくすると「設計をする上でのルール」といった意味です。
分散型システムとはクライアントとサーバーのことを指します。クライアントはサーバーにリクエストを送り、サーバーはレスポンスを返すというクライアントがトリガーとなりサーバーは受け身とされていました。
2000年頃にできた概念なので現在はその限りではありません。REST原則という分散型システムを定義するうえでの基準となる原則があり、この原則に則り作られたシステムをREST API(RESTfull API)と呼びます。

階層化システム

web API DBが多数存在する構成のシステムのことです。その中のある一つのサーバーをコンポーネントといいます。
メリットは各システムに役割を持たせることで進化と再利用が促進されます。近年でいうマイクロサービスに近い概念といえます。
デメリットはデータ処理にオーバーヘッドが発生することでユーザー（クライアント）側から見ると動きが遅く反応が悪く感じます。

コードオンデマンド

クライアントコードをダウンロードして実行できることです。
例えば、HTML、Java Scriptなど内容の更新があった時、クライアント側は自動で新しい内容を見ることができます。このようにリリース後にクライアントコードを変更できます。
メリットはリリース済みのクライアントに対して機能が追加できること、クライアント側に処理が移譲できた分、サーバーの処理が軽くなることです。
デメリットは評価環境がChrome,safariなどブラウザアプリがたくさんある分複雑になります。

統一インターフェイス

リソースの識別、表現を用いたリソース操作、自己記述メッセージ、アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)の4つの制約で成り立っています。
メリットはシステムアーキテクチャが簡素化されてわかりやすい、提供するサービスに集中でき、独自の進化ができる、HTMLという取り決めが共通なので異なるブラウザでも同じような表示ができることです。
デメリットは標準化によって効率が犠牲になり、冗長になることです。それぞれの詳細を以下に紹介します。

リソースの識別

URIを用いてサーバーに保存されたドキュメント、画像などのデータを識別できることです。URIのリソースを識別しますが、動作は含みません。

表現を用いたリソース操作

断面情報を利用してサーバー上のデータを操作することです。認証情報のようなメタデータも含みます。
リクエストを送る際に表現（認証情報などの追加情報）を付与してサーバー側にリソースの編集をお願いすること

自己記述メッセージ

データ自身がサーバーにリクエストするデータ、クライアントへのレスポンスデータのように自らのメッセージ内容をヘッダーに記述して説明しています。

アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)

レスポンスに現在の状態を踏まえたハーパーリンクが含まれていることです。2000年頃はよく見られましたが近年は減少しています。

ステートレス

リクエストが保持されず、一つ一つの会話（コンテキスト）が独立していることを指します。
メリットは単一のリクエストを見ていればよいので監視が容易なこと、障害発生したリクエストだけ回復すればよいので障害復旧が容易、リクエスト全体でサーバーのリソースを共有する必要がないのでスケールがコンパクトであることです。
デメリットは単一リクエストで完結させるためにリクエストデータに重複ができてしまい冗長であること、アプリを複数バージョン提供し、状態をクライアント側に置いておく場合はアプリ制御が複雑になってしまいます。

キャッシュ制御

クライアント側でレスポンスをキャッシュします。
メリットとしてユーザー体験、リソース効率、拡張性が向上します。
デメリットとしては古いデータを戻してしまうとそれがユーザーに表示されてしまうことがありシステムの信頼性低下につながる恐れがあります。

REST API成熟モデル

2010年に紹介されたRESTAPI設計レベルにどれだけ準拠しているかを4段階に分類したモデルのことです。

  1. Level0はHTTPを使ったAPIである
  2. Level1はリソースの概念が導入されている
  3. Level2はHTTPの動詞が導入されている
  4. Level3はHATEOASの概念が導入されていること
    以上の4段階が基準となっています。

URI設計で考慮すること

URI設計では以下のことを考慮して設計します

  • 短く入力しやすいこと
  • 人が読んで理解できること
  • 他の人に伝わらないのでversionをvのように省略しない
  • 小文字で統一されていること
  • 単語はハイフンでつなげて書くこと
  • リソースの集合を表すので単語は複数形で書くこと
  • 日本語のようなエンコードが必要な文字を使わない
  • サーバー側のアーキテクチャを記入しない
  • 何を指しているのかわかる単語のみを使い改造しやすくすること
  • 設計はクエリパラメータ指定のみ使用するというようにルールが統一されていること

CRUD操作のURI、HTTPメソッド

URIはリソースを表しますが、HTTPメソッドは操作を表します。
メソッドの種類は

method 説明
GET リソースの取得
POST 名前が決まっていないリソースの新規登録
PUT 既存リソースの更新、名前が特定できている場合のリソースの新規登録
DELETE リソースの削除

これを実際に当てはめてみます。
今回は例としてmovie（映画）をリソースとして CRUD操作のURI、HTTPメソッドを定義してみます

URI HTTPS method 説明
/v1/api/movies GET 登録されている映画を全て取得
/v1/api/movies POST 映画の新規登録
/v1/movies/{id} PUT 既に登録されている映画情報の更新、名前が決まっている映画の新規登録
/v1/movies/{id} DELETE 登録されている映画の削除

URI設計で考慮することにも書いたようにmovie（映画）はたくさん種類があるのでリソースの集合を表すのでmoviesと複数形で書きます。
また、映画は名前が決まっているはずなので新規登録は基本的にPUTを使うことになると思います。

終わりに

RESTという言葉を聞くのも初めてでしたが、サーバーの設計上必要なものでありこの設計がうまくいってないと利用するユーザーはとても使いにくくなるというだけではなく、設計後の更新作業をする上でも意味が分からないURIの意味を推測する無駄な工程ができてしまうということが分かりました。まだ設計はしたことがないですがこれからの勉強で必ず必要となる土台の部分であると思うので今後初めて設計する時は間違えて修正が大変にならないよう参考Udemy講座を含め見返して書いていきます。

プログラミングの勉強を始めてから11か月

はじめに

Happiness Chain Advent Calendar 2023、7日目の記事です。 今年の1月20日にHappiness Chain(以下HC)に入って11ヶ月ほど経ちました。
入会時に初めて触ったプログラミングの勉強時間も12月7日現在600時間以上となりました。 今まで書いていませんでしたがアドベントカレンダーの企画をきっかけにHCに入会してから思ったことを紹介していきたいと思います。気づいたら長文になってしまいましたのでご注意ください。

勉強内容

私はRuby on Railsコースなのですがプログラミング言語はもちろん、DockerやGitHubなどWeb開発に必要な知識を幅広く深く学べます。内容自体は難しいですが必ずクリアできます。勉強で間違えてもどうしても分からなくて質問しても実務でそれをするより苦労は少ないはずなので今のうちにたくさん壁にぶつかろうという精神で進めてます。
コードレビューでは、ただ動くだけではなくメンテナンス性を考えること、コードが複数の人の目に触れることを意識したアドバイスをしてくれます。便利なツールやショートカットも教えていただけます。slackやDiscordで質問ができるのですが先生だけでなく生徒の方も優しく答えてくれることがあり、その日の内に大体解決します。

良かったこと

LGTMをもらい勉強が進む度に達成感があります。できることが増えてきてからできないことがあっても勉強の落ち込みを引きずることが減り、気持ちの切り替えに数日かかっていたのが今では数十分～1時間とかなり楽になりました。振り返ると昼寝のしすぎやスマホで時間の使い方を無駄にしていたと気づき家事の手伝いもありますが趣味の時間はあまり減ってないです。
また、せっかくプログラミング特化で勉強しているので特に好きな趣味を極めてみようと思い、月1回通っていた苔テラリウムの教室はお休みし、代わりにハオルチアという見た目が好みな植物をお手入れし、きれいさの維持向上に力を入れるようになりました。
実は女子大出身で男性と話すとかなり緊張するのですがミートアップや雑談でお話したら少し慣れてきました。以前は緊張するだけでしたが生徒同士の雰囲気が良くコミュニケーションが楽しくなってきたところなので今後もっと顔を見せる機会を増やしていく予定です。

悪かったこと

現行ですとさぼったりペースが落ちても先生から最近どう？など聞かれないので自分で自分を管理する必要があります。ただ、こちらは2024年からは体制が変わり以降入会する人から対応が変わるようです。
また、少しずれますが付き合いの長い友達から誘われた旅行を勉強に集中したいので宿泊有りは1年ほど厳しいと断ったら疎遠になってしまいました。1ヶ月くらい落ち込みましたがHCで新しい仲間、友達が出来ていくので過去のことは引きずらず今を生きるのが吉だと思ってます。最近回復してきて勉強すると落ち着くようになりました（笑）

終わりに

PCをフリーズさせるのが得意で英語もテスト前に詰め込む、受験勉強も推薦のためほとんどせず勉強は不得手な私が1年以内でここまで頑張れるとは正直入会時点では想像もつきませんでした。HC生、卒業生と先生方が作ってくださった環境のおかげでここまでこれました。来年は私も他の人に貢献できるくらい知識と実力をつけたいです。これからも卒業目指して地道に積み上げていきます！

最後まで読んでくださりありがとうございます！

達人に学ぶDB設計徹底指南書を読みました

先日のSQL入門に続けて達人に学ぶDB設計徹底指南書も読みましたので感想をまとめていきます 書籍のリンクはこちらです。

良かったところ

以前読んだSQL入門は基本のSQL文の使い方と演習がメインの構成でしたが達人に学ぶDB設計は実例に近い例を挙げてそのDBの課題と課題を解決するための方法が中心に紹介されています。私は実務の経験がないので基本のSQL文を知っているだけでは意図せずアンチパターンのような効率の悪い設計を作ってしまう可能性もあり、それらを予備知識として知ることで手直しの少ない設計を考えられる知識の土台が増えたと感じました。

学んだこと

正規形の種類と違い、非正規形は基本使用しない方がいい理由が詳しく書かれており実際の設計はコストや更新の頻度など考えてこのように折衷するのだという過程を分かりやすく学べました。
また、アンチパターンの例も実際使われているSQLのテーブルは見たことないのでダブルミーニングのように作った人しか訳の分からない設計が起こる理由とどうしたら改善できるかを知ることで実際目にした時の対処に役立つと思いました。

難しかったこと

第9章の木構造、特に入れ子区間について座標が急に出てきたり単語も難しかったりしたので調べて読みましたがあまり飲み込めませんでした。また、演習問題は既に実務でSQLを扱っている方向けなのではと思うくらい難しいものが多かったです。まだ使いこなせるイメージが湧かないのですが将来は内容を理解して使いこなせるようになりたいです。

全体的に難しいと感じるのが多かったのでもっと成長できるようしっかり勉強し続けようと改めて思いました。

最後までご覧くださりありがとうございました！

スッキリわかるSQL入門を読みました

スッキリわかるSQL入門 第3版を読了したので感想を書いていきます。こちら書籍の情報リンクです。電子書籍と紙の本が選べます

良かったところ

SQLについてはprogate完了くらいのレベルでしたがこの本を読んだことでかなりレベルアップできました。
ドリル問題がたくさんあり間違えたところは復習すれば定着しやすくなっています。
dokoQLという環境構築しなくてもPCやスマホがあればすぐに使えるSQLのサービスがあるので初心者でも学習しやすいです。

気になったところ

何か理由があると思うのですがdokoQLはすぐ使えるますが書籍内に登場するテーブルがデフォルトでは入っていないところがあります。また、本文で使うSQL文はQRコードを読み込めばdokoQLに入力した状態にできるのですがQRコードを読むためにスマホを使うのでPCでは完結できないので少し不便と思いました。

学んだこと

  • テーブル内の操作に必要なSELECT INSERT UPDATE DELETEを四大命令と言う
  • テーブル内の操作をする命令はDML,TCLと言い、テーブルを作り設定を操作するのはDDL,DCLと命令の種類が分類されている
  • トランザクションを作りデータの処理が中断された時も不都合が起きないようにする
  • 副問い合わせでSELECTをネストして1つの文でより詳細な検索をする
    などなど知らないと困るような基礎は大体知ることができたと感じます。

難しかったこと

関数、副問い合わせ、ER図の章は難しくて全ては理解できてないです。この3章分もっと手を動かして勉強しないとなと思いました。

500ページほどあるので読むのはかなり大変だろうと予想していたのですがチェリー本よりは短時間で読了できました。1度では覚えられないので必要になる度に読み返してしっかり知識を定着させていく予定です。

ここまでご覧くださりありがとうございました！

Rubyでoptparseを使う方法（初心者向け）

Rubyを勉強していて初めてoptparseを使ったので使い方を整理するためにもブログに書いてみます。間違いなどありましたらご指摘ください。

optparseとは

標準ライブラリの一種でRubyのファイルを実行するときコマンドライン上で-aなどオプションを指定できるようになります。

使い方

Rubyの公式リファレンスマニュアルを参考にしてみます。 まずRubyファイル内にrequire 'optparse'と記述してライブラリからoptparseを呼びます。 その後ファイル内にオプションで出力させたい結果を記述します。Rubyは上に書いた内容から順に読み込まれるのでrequire 'optparse'より上にオプションで出力させたい内容を記述してもエラーが出てしまいます。

opt = OptionParser.new

opt.on('-a') {|v| p v } #{}の中に処理内容を書く。ここでは引数を取得
opt.on('-b') {|v| p v } 

opt.parse!(ARGV) #引数だけ取り出す
p ARGV #引数を出力

このファイルをオプションを付けて実行すると以下のように引数とオプションが実行できたことを示すtrueが表示されます。ちなみに、オプションを付けずruby sample.rbだけ書いた場合はopt.on('-a') {|v| p v } opt.on('-b') {|v| p v }の内容は実行されません。

 sample.rb -a foo bar -b baz
# => true
     true
     ["foo", "bar", "baz"]

例題以外にどんなことに使えるか

リファレンスマニュアルの例題では引数を取得するオプションが取り上げられていますが条件分岐させてエラーの際に出るエラー文を決めることもできます。

 #もし-aの後に1~10以外の数字を入力したらエラーを出す

if  xxxxx
  puts "error: #{opt['a']} Invalid number, please enter (1..10)" 
  return
end

ruby sample.rb -a 11
# => #{opt['a']} Invalid number, please enter (1..10)

参考ページ

Rubyの公式リファレンスマニュアルです。optparse以外にもオプションをどう条件分岐させたいか？など調べるときにとても参考になります。見慣れない単語があり、リファレンスマニュアルの読み方も調べながら進めていました。 docs.ruby-lang.org

こちらもリファレンスマニュアルの内容が分からないとき参考にさせていただきました。 akng-engineer.hatenablog.com

最後までご覧いただきありがとうございました！

プログラミング超初心者が~プロを目指す人のためのRuby入門<改訂2版>~を読んだ感想

最近少しづつ読み進めていたプロを目指す人のためのRuby入門<改訂2版>を読了したので感想を書いていきたいと思います。なお、このブログはプログラミング未経験で1年も勉強していない人が書いています。間違いなどありましたらご指摘いただくか心の中で突っ込んでくだされば幸いです。

良かったところ

最初は本が厚すぎて内容も分からないことが多く進めるのは大変でしたが、例題で出されるコードの例でどうしてこのような書き方になるのかの説明が詳しくわかりやすかったです。単語の説明もありこの本を読まないでRubyの勉強を続けるのは難しいだろうなと思いました。正規表現も初めて知りましたがQiitaのリンクもあり理解しやすかったです。また、元の説明内容が多いので例題の解答例が1例で、この書き方が正解というのがストレートに書いてあるので初心者にはありがたいなと思いました。
1～6章は基本的な知識が詰まっています。これから必要になった時に読み返したらすぐ使えて知りたいことはかなり網羅できるのではと思う充実した内容でした。

学んだこと

最初読んだときは頭に入りませんでしたが読み進めるにつれて過去の章が何度か取り上げられることがあり、読み返して理解度が上がって大切な内容だったんだ！と気づくケースが多かったです。特に知れてよかったことは12章のRubyのデバック技法を身に着けるです。エラー文の意味やどうするとそのエラーが出るのか全く知らないで勉強していたのですが私でも理解しやすかったしここだけ先に読んでも良かったのではないかと思うくらいでした。

難しかったこと

最初の方はコードを見るのも大変でした。意味が理解できず文字列は顔文字（特に魚 <。)#)))≦ ）に見えてきて本文でさえ内容が頭に入ってこなかったのでこまめに休憩しながら読んでました。6章の正規表現を理解するあたりでやっと内容も集中して読めるようになりました。 内容的には10章のyieldとProcを理解する、11章パターンマッチを理解するはあまり理解できず、？が多かったです。次読んだときに少しは理解できるように更にRubyの勉強頑張りたいなと思います。

最後に

まだまだRubyに関しては理解できていないことも多いのですが少しでもわかることが増えたのでコツコツ勉強を続けていきたいです。最後までご覧いただきありがとうございました！