【DIVE INTO CODE】第7回授業レポート(デバックの6つの視点)

投稿日:

【Rails】プログラミング初心者の勉強ブログ #72

プログラミングスクールDIC第7回授業レポート。授業内容や様子など。今回はWebアプリケーションの処理の流れの復習とともに、デバックすべき6つの視点について学習しました。Railsアプリケーション開発過程で確認すべきデバックの視点です。

 

目次

 

前回までの授業内容

第6回授業レポート

第6回授業レポート。Webアプリケーションの処理の流れについての学習です。Railsフレームワークで開発に入る前に必ず知っておくべきアプリの流れの概要です。

第5回授業レポート

第5回授業レポート。アイデア創出の手順について。オリジナルWebアプリ作成のために必要な要件定義の方法を学習しました。

第4回授業レポート

第4回授業レポート。オブジェクト指向についての講義です。カプセル化・継承・ポリモーフィズムについて学習しました。

第3回授業レポート

第3回授業レポート。Rubyで二分探索法アルゴリズムを考えた回です。コーディングからフローチャートを作成し、グループワークで理解を深めました。

第2回授業レポート

第2回の授業レポート。事前課題で提出したJavaScriptでコーディングした「成績判定プログラム」のフローチャート作成が抗議内容のメインです。

課題で作成した成績判定アルゴリズムを噛み砕き、個人ワークでフローチャートを作成した後、グループワークで共有・発表といった流れです。

第1回授業レポート

初回授業レポート。こちらも事前課題に沿ってHTML/CSSのアウトプット。

プログラミングスクール「DIVE INTO CODE」の授業の雰囲気なども書いてます。

 

7回目授業はいよいよRailsアプリケーションのグループワーク

今回はWebアプリケーションの処理の流れの復習とともに、デバックすべき6つの視点について学習しました。参加人数は12名。今回もグループワーク中心の講義内容です。事前課題としてRailsで作成したブログアプリの「お問い合わせ機能」を使い、GETとPOSTの通信の流れやパラメーター、データベースとの連携などを、それぞれディベロッパーツールやソースコードを追って確認していきました。デバックすべき6つの視点はどこにあるのか、以下まとめていきます。

 

Railsアプリケーションの処理の流れを6つに分けて考える

デバックの6つの視点

 

Railsは「ディレクトリごとに分担された仕事を実行する」よう、「MVC」構造なるものでディレクトリごとに関連する処理をまとめ、それぞれが連携することでWebアプリが作動する仕組みになっております。ですので、デバックを行う場合「何が原因であるか」を突き止めるべく、上の画像のように処理の流れを6つに分け、それぞれの実行結果や関連性を把握し、ログを確認できる必要があります。

 

ソースコード

今回グループワークで確認したRailsで作成した「お問い合わせ機能」を例に見ていきます。

お問い合わせ画面

この画面のHTMLソースコードはこちらになります。(bodyのみ抜粋)

ソースコード

 

formタグやinputタグが確認できます。今回の場合、これらのタグはRailsの「form_with」を使い作成しております。以下が実際のコードです。

contacts/new.html.erb

 

自分で書いたコードと、実際に通信結果としてブラウザに反映されているHTMLソースコードを照らし合わせ、そもそもどのような違いがあるか、Railsで使用したメソッドは、何のタグを生成しているか等をしっかりと把握するという視点です。

 

ディベロッパーツール

ソースコードで確認した内容よりも、さらに詳細に通信内容を確認するために見るべきものが「ディベロッパーツール」です。

Google Chromeで右クリックし「検証」を開くと表示されます。

検証ツール

 

上の画像は、お問い合わせ画面を開いた直後に、検証ツールで「Network」を確認した際の画面です。左の「Name」の欄にある「new」をクリックして詳細を確認すると、

検証ツール詳細

 

Generalの欄に「Request Method: GET」と書いてあることがわかります。このお問い合わせ画面(/contects/new)を開いた際のHTTP通信がGETによるものだということです。

このように、ディベロッパーツールを確認することで、HTTPリクエストの詳細を確認することができます。

 

rails sログ

「rails s」とは、Railsアプリケーションのサーバーを立ち上げる際のコマンドです。開発環境で実際にWebアプリを試す際にはまず「rails s」を入力します。

サーバーを起動した後は、通信が行われる度に、ターミナル画面上にログが表示されます。

例えば、お問い合わせ画面を表示させる通信が実行されたときのログは、

rails sログ

頭に「Started GET "/contacts/new"」と表示され、GETで「/contacts/new」にリクエストが実行されたことを示します。

先ほどの「ディベロッパーツール」のNetworkで確認したときも「Request Method: GET」と書かれていたことからも、しっかりと連携されていることがわかります。

 

rails routes

GETやPOSTなどのHTML通信のリクエストは、まず「Router」が対応します。銀行でいう受け付け係です。「Router」が内容を確認し、「Controller」という窓口に案内します。

「rails routes」というコマンドを入力すると、その受け付け係の業務マニュアルが確認できます。

rails routes

 

今回の場合、赤枠で示した部分が該当します。上の業務マニュアルによれば、「GET」による「/contacts/new」への通信は、「contactsコントローラーのnewアクションを案内しなさい」というように書かれております。

 

では実際にコントローラーを見てみます。

今回のお問い合わせ機能は、newアクションとcreateアクションの二つから成ります。コード的には、

このような状態です。

「def new」の部分が「newアクション」の定義箇所であり、「@contact = Contact.new」以外には特に設定が書き込まれておりません。この場合、表示されるViewは、「new.html.erb」になります。設定に「render」や「redirect_to」で表示先を指定しない場合、自動で「コントローラのアクション名と同名がつくViewファイル」が表示されます。

したがって、GETで「/contacts/new」のリクエストがあると、Routerが「contactsのnewアクション」を案内し、「/views/contacts/new.html.erb」が表示されるという結果になります。

このように、Routerの案内先が確認できるのが「rails routes」です。

 

rails c

rails c は、「rails console」の略であり、RailsアプリケーションでコーディングしたRubyを実行したり、その結果を確認するために利用するコマンドです。僕の場合「rails c」でデバックする機会がほとんどです。

例えば、お問い合わせが現在何件届いているかを「Contactモデル」から確認できます。

rails c

 

上の画像はターミナルで「rails c」を実行後、「Contact.count」と入力し、データベース内のテーブルのレコードの数(お問い合わせ件数)を表示させています。実行結果が「10」なので、現在お問い合わせは10件あることがわかります。

このように、rails cを用いればModelやControllerで定義したものを確認することができます。

 

rails db

rails dbは、使用しているデータベースに直接アクセスするコマンドです。

rails db

 

入力すると上の画像のように表示され、SQLで直接DBにクエリを発行することで内容を確認できます。「select * from contacts;」はcontactsテーブル内の全てのレコードを取得するSQL文です。

 

 

まとめ

今回はRailsアプリケーションの流れを確認しつつ、処理の過程を6つに分け、デバックの観点を確認する回でした。「rails db」コマンドは初めてで、Active Recordだけに頼らず、少しはSQL使えるように練習するのもありかと思いました。

以上ありがとうございました。

-プログラミング学習
-, ,

Copyright© s u p ? , 2019 All Rights Reserved.