rubyspikeのブログ

Railsの魔法を解明します（6）

Sat, 13 Jan 2018 19:15:40 +0900

レコードの一覧表示

私たちの投稿を掲載する

私たちのブログアプリでは、最初にすべての投稿タイトルのリストを表示したいと考えています。そして、ここにいくつかの記事があるデータベースがあるので、実際にここに表示するものがあります！

開始するには、hello_worldアクションで3つのことが必要であることを思い出してください：

1 a route
2 an action
3 view

ここにもそれぞれのものが必要ですので、/ list_postsのルートを定義して物事を説明しましょう：

config/routes.rb

Rails.application.routes.draw do
get '/list_posts' => 'application#list_posts'
end
application＃list_postsアクションは次を指します：

app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
def list_posts
connection = SQLite3::Database.new 'db/development.sqlite3'
connection.results_as_hash = true
posts = connection.execute("SELECT * FROM posts")
render 'application/list_posts', locals: { posts: posts }
end
end

私たちのlist_postsアクションの中には、以前のDB初期化ロジックが表示され、次にSELECTクエリがあり、すべての投稿をハッシュとして取得します。その後、localsとして一緒にそれらをビューに渡すだけです。

ビューはまだ定義されていないなので、次にそれをしましょう：

<% posts.each do |post| %>

<%= post['title'] %>

by <%= post['author'] %> -
<%= post['created_at'] %>

<% end %>

ここにはかなりのマークアップがありますが、その大半はこれを除いてよく知られているはずです：

<% posts.each do |post| %>

<% end %>

ここでは、ERBビュー内で配列をどのように反復処理できるかを確認します。上記では、posts.eachを使用してポストをループし、各ポストに対して

を作成します。（このポスト変数はブロックの<％end％>の前のどこでも利用できます）。

ここで注意すべき重要なことは、<％=>とは対照的に<=％>（=を除く）を使用することです。これにより、戻り値をページに配置せずにRubyを実行することができます。

それ以外にも、<％= post [‘title’]％>のような行で適切なポスト値をポスト

の別の場所に配置するだけです。

そして、/ list_postsにアクセスすると、3つの投稿のタイトルと、それぞれの著者の名前と作成日が表示されます。

ユーザーに投稿を表示する

これで/ list_postsが動作するようになったので、/ show_post /：idのために何かを実装してみましょう。これはユーザーが特定の投稿を読むために行く場所です。

まず、ルートが必要です。

### config/routes.rb ###
Rails.application.routes.draw do
get '/list_posts' => 'application#list_posts'
get '/show_post/:id' => 'application#show_post'
end

ここでは、コントローラーアクションで使用するパラメータとしてIDを取得するためのURLパターンを設定することができます。

それから、show_postアクションが必要になります：

### app/controllers/application_controller.rb ###
class ApplicationController < ActionController::Base
# ...
def show_post
connection = SQLite3::Database.new 'db/development.sqlite3'
connection.results_as_hash = true
post = connection.execute("SELECT * FROM posts WHERE posts.id = ? LIMIT 1", params['id']).first
render 'application/show_post', locals: { post: post }
end
end

このshow_postアクションでは、まず特定のIDでデータベースから投稿を取得する必要があります。connection.executeでもう一度SQLをDBに対して実行しますが、今回は.firstを呼び出します。その理由は、LIMIT 1の場合のように、connection.executeは常に単一の要素を含むことになっても、配列を返すためです。

これをデータベースで使用する方法は面白いですが、見てみましょう：

connection.execute("SELECT * FROM posts WHERE posts.id = ? LIMIT 1", params['id'])
私たちの目的には、次の行と同じ効果があります：

connection.execute("SELECT * FROM posts WHERE posts.id = #{params['id']} LIMIT 1")

オリジナルのステートメントの？文字は、2番目のパラメータの値で置き換えられるプレースホルダです（params [‘id’]）。これは、ユーザーの入力（この場合はURLからの）をSQLステートメントに含めるより安全な方法です。Railsはステートメントが安全であることを確認します。 2番目のステートメントは安全ではありません。ユーザーの入力を直接ステートメントに含めたからです。この技術は、SQLインジェクション攻撃に対する保護と呼ばれています。このシリーズの後半でこのトピックに着きます。

しかし、私たちのアクションの最後の行に戻ると、私たちは私たちの投稿をshow_postビューに渡すだけであることがわかります。言えば、今ここでそれを定義しましょう：

<%= post['title'] %>

by <%= post['author'] %> -
<%= post['created_at'] %>

<%= post['body'] %>

このビューは基本的にlist_postsビューと同じですが、ループを持たず、ポストボディをレンダリングします。

/ show_post / 1にアクセスと、投稿の詳細と投稿の本文が表示されます。

リンク

最後に、これらの2つのページの間にいくつかのリンクを作ってみましょう：

Back to Posts

<% posts.each do |post| %>

<%= post['title'] %>

<% end %>

showビューからlistビューへのリンクは単純で静的なリンクです：

Back to Posts
listビューのリンクはループの中にあったので、少し複雑になります：

<%= post['title'] %>
ここでは、投稿IDを使用してhrefを動的に作成し、リンクテキストを各投稿の投稿のタイトルに設定します。

DB接続用の共有ロジックの抽出

show_postで、list_postsで使用したデータベースに接続するために同じ2行を繰り返していることに気づいたかもしれません。このロジックをコントローラー内の独自の接続メソッドに移して、両方のアクションを調整して使用してみましょう。

class ApplicationController < ActionController::Base
def list_posts
posts = connection.execute("SELECT * FROM posts")
render 'application/list_posts', locals: { posts: posts }
end
def show_post
post = connection.execute("SELECT * FROM posts WHERE posts.id = ? LIMIT 1", params['id']).first
render 'application/show_post', locals: { post: post }
end
private
def connection
db_connection = SQLite3::Database.new 'db/development.sqlite3'
db_connection.results_as_hash = true
db_connection
end
end

これは素晴らしいことです。なぜなら、後でデータベース接続について変更する必要がある場合、変更をただちに行うことができるからです。さらに、他のアクションでデータベース接続を使用する必要がある場合は、connectionを使用することもできます。

Railsの魔法を解明します（5）

Sat, 23 Dec 2017 15:13:02 +0900

アプリケーションでデータを持続させる

データベースバックアップアプリケーション

URLを介してデータを渡すことは、Webアプリケーションに動的コンテンツを応答させるための1つの方法ですが、動的Webの最も一般的なパラダイムは「データベースバックアップアプリケーション」です。サーバーはクライアントにレスポンスを返すため、バックエンドデータベースにクエリを行います。

このユースケースでは、レスポンスの動的性質はリクエスト内のデータからではなく、バックエンドデータベースの「状態」から得られます。

これは大きな話題で、いくつかのセクションを使って説明します。私たちは、このパラダイムとのやりとりを歩くために、実際のWebアプリケーション、ブログを作成します。

データベースの準備

まずは、作業するブログ記事のデータベースを用意しましょう。 Railsに組み込まれている軽量データベースであるSQLite3を使用します。

データベースの記事を扱う際には、以下について考える必要があります：

１データベースの構造（テーブルとその列）

２データそのもの（個々の投稿を表す行）

構造については、投稿テーブルに各投稿の詳細を保持する必要があります。各投稿には次の属性があります：

id (integer)
title (string)
body (text)
author (string)
created_at (datetime)

これらはそれぞれ、データベース内のpostsテーブルの列になります。

このテーブルを作成するには、次のSQLファイルを使用します。

db/posts.sql

CREATE TABLE "posts" (  "id"         INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,  "title"      varchar,  "body"       text,  "author"     varchar,  "created_at" datetime NOT NULL);

postsテーブルに、次のCSV（Comma-Separated Value）ファイルを使用してダミーポストをいくつか挿入します。

db/posts.csv

1,Blog 1,Lorem ipsum dolor sit amet.,Brad,2014-12-072,Blog 2,Lorem ipsum dolor sit amet.,Chris,2014-12-083,Blog 3,Lorem ipsum dolor sit amet.,Kevin,2014-12-09

したがって、データベースを作成し、それに対してSQLを実行し、内部に投稿テーブルを作成するには、「Railsルートディレクトリ」、つまりapp とdbのようなディレクトリを含むRailsアプリケーションの最上位ディレクトリで以下の命令を実行します：

sqlite3 db/development.sqlite3 < db/posts.sql

このプロジェクトでは、DBMS（データベース管理システム）としてSQLite3を使用します。そこには他にはるかに強力なDBMSがありますが、SQLite3はRailsのデフォルトの開発データベースであり、うまく機能するため、これを使用します。

このコマンドの結果、db / development.sqlite3ファイルが作成されます。このファイルには、SQLite3データベースが含まれています。そして、私たちはそれに対してposts.sqlファイルを実行したので、postsテーブルを持ちます。

SQLite3コンソールを実行して見てみましょう：

$ sqlite3 db/development.sqlite3

sqlite> .tablesposts

sqlite> SELECT * FROM posts;sqlite>

私たちの投稿テーブルはありますが、そのSELECTからの空白の返信からわかるように、まだテーブルに投稿行はありません。

CSVファイルをインポートすることで、この問題を解決できます。まずSQLite3にCSVファイルをインポートしていることを伝える必要があります。次に、このようにインポートを実行できます：

sqlite> .mode csvsqlite> .import db/posts.csv posts

さて、私たちが持っているものを見てみましょう：

sqlite> SELECT * FROM posts;1,"Blog 1","Lorem ipsum dolor sit amet.",Brad,2014-12-072,"Blog 2","Lorem ipsum dolor sit amet.",Chris,2014-12-083,"Blog 3","Lorem ipsum dolor sit amet.",Kevin,2014-12-09

sqlite> SELECT title FROM posts;"Blog 1""Blog 2""Blog 3"

sqlite> SELECT created_at FROM posts WHERE id=1;2014-12-07

.quitコマンドを使用してsqlite REPLを終了することができます。これでいくつかの記事データを持っているので、色々な試しに行きましょう。

データベースと対話する

このデータベースをRailsで扱う方法について説明する前に、純粋なRubyを使ってこのデータベースとやりとりする方法を見てみましょう。

RubyのSQLite3データベースに接続する方法が必要です。幸いなことは、Rubyライブラリsqlite3があります。

$ irb

> require 'sqlite3'=> true

# setup db connection> connection = SQLite3::Database.new 'db/development.sqlite3'=> #

ここでは、ライブラリを利用できるようにするためにライブラリを用意する必要があります。次に、dbite.sqlite3データベースに問い合わせるためのSQLite3 :: Databaseオブジェクトをインスタンス化します。

これで、Rubyを使用してデータベースに対してSQLを実行するようになりました。

> post_arrays = connection.execute 'SELECT * FROM posts'=> [     [1, "Blog 1", "Lorem ipsum dolor sit amet.", "Brad", "2014-12-07"],     [2, "Blog 2", "Lorem ipsum dolor sit amet.", "Chris", "2014-12-08"],     [3, "Blog 3", "Lorem ipsum dolor sit amet.", "Kevin", "2014-12-09"]   ]

connection.executeにSQL文字列を渡してデータベースに対して実行させます。このconnection.executeコールからの戻り値は配列の配列であり、それぞれがテーブル行を表します。

ポストローを表す配列は、次の形式で値を保持します。

[id, title, body, author, created_at]

テーブルの列を宣言した順序なので意味がありますが、特に便利ではありません。

たとえば、投稿のタイトルが必要な場合、タイトルはこれらの配列のインデックス1にあることを知っておく必要があります。その後、post [1]を使用してタイトル文字列を取得します。代わりに、これらの投稿をハッシュとしてGoogleに返すことはうれしいので、投稿のタイトルが必要な場合は、post [‘title’]を使用して取得することができます。

便利なことに、これらの行をハッシュとして返すように接続を宣言することができます。

> connection.results_as_hash = true=> true

> connection.execute('SELECT * FROM posts').first=> {     "id"         => 1,     "title"      => "Blog 1",     "body"       => "Lorem ipsum dolor sit amet.",     "author"     => "Brad",     "created_at" => "2014-12-07",     0 => 1,     1 => "Blog 1",     2 => "Lorem ipsum dolor sit amet.",     3 => "Brad",     4 => "2014-12-07"   }

今度はSELECTから返された配列の最初の要素を見ると、post [title]というポストタイトルを得ることができるハッシュが戻ってくることがわかります。

ちなみに、タイトルは整数キー1でハッシュにも格納されているので、post [1]でタイトルを見つけることはできます。

これらのキーは、配列がもはや配列でなくても、ハッシュが前の配列とまったく同じように動作することを可能にします（少なくとも[]を使った値アクセスに関して）。

賢いですね！

データベースにいくつかの投稿があり、Rubyでそれらを手に入れることができるようになった今、私たちのWebアプリケーションを構築し始めましょう。

Railsの魔法を解明します（4）

Sat, 16 Dec 2017 18:43:11 +0900

アプリケーションを動的にします

動的サーバーの応答

これで、リクエストをアクションに送信するルートが得られました。アクションをビューに表示しましたが、これまでのすべてのコンテンツは静的でした。

私たちのRailsアプリケーションは本質的に、HTML文書を取り出しHTTPレスポンスにラップしてクライアントに返すファイルサーバです。

これは初期のWebの主なパラダイムで、Webサーバーがリクエストに応答して静的なドキュメントを返送します。しかし、現代のウェブは、リクエストに応答するために即座に応答を集めることができるウェブの「アプリケーション」を生み出しました。

Webアプリケーションの動的な性質は、主に次の2つのソースから来ています：

１クライアントは、サーバーが応答するURL内にデータを埋め込みます。たとえば、ブラウザ「https://www.google.com/search?q=robots」を入力すると、「ロボット」の検索結果のみを含むウェブページを動的に組み立てるよう、Googleに求めています。

２サーバーは、サーバーのデータベース内のデータの内部状態に基づいてデータに応答します。たとえば、ブログを訪問すると、サーバーはデータベースに格納されているブログ投稿を取得し、このデータに基づいてWebページを動的に組み立てます。

この2つのシナリオを次のトピックで詳しく見ていきます。

動的ドキュメントと組み込みRuby

ERBは「組み込みRuby」の略です。 Rubyコードをテキスト文書に埋め込んで動的な文書を作成できるテンプレートエンジンです。

ERBテンプレートでは、識別するためにRubyコードを<％…％>タグの内側に配置する必要があります。さらに、<％= ruby_expression％>構文を使用して、ルビコードの値をHTMLドキュメントに入れることができます。

テンプレートをHTMLドキュメントに「レンダリング」するときは、「レンダリングエンジン」（この場合はERBレンダリングエンジン）を使用してテンプレートを実行してから、埋め込まれたRubyコードを実行して出力します。

たとえば、このERBテンプレート

<% name = "John" %>

Hello, <%= name %>!

以下にレンダーします

Hello, John!

この例では、ERBテンプレート内の変数名に値「John」を割り当ててから、HTML文書のレンダリングに使用しました。テンプレートは常に同じ結果にレンダリングされるので、これは面白くないです。

テンプレートを以下のように残すでけで

Hello, <%= name %>!

テンプレートの外側から変数名前の値を渡します。変数名前の値が “John”の場合、このテンプレートは同じ結果にレンダリングされます。

クエリパラメータに応答します

これで、ERBテンプレートを使用して動的ドキュメントをレンダリングする方法がわかったので、リクエストURLに名前を渡して、 “Hello、John！”のようなカスタム挨拶に応答させます。

これを行うために、HTML文書の名前をhello_world.html.erbに変更します。 Railsでは、この規約は、最終的にHTML文書にレンダリングされるERBテンプレートであることを意味します。

ERBテンプレートはよく見かけがあります。

app/views/application/hello_world.html.erb

Hello, <%= name %>!

クライアントからサーバーに値を渡す方法はいくつかありますが、最も基本的なのはURLのクエリパラメータ（http：// localhost：3000 / hello_world？name = Johnなど）を使用することです。パスの？後ろの部分name = Johnは、サーバーによって解釈されるクエリ文字列です。

アクションでこれらのパラメータにアクセスする方法を見てみましょう：

app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
def hello_world
name = params['name']
render 'application/hello_world', locals: { name: name }
end
end

Railsはクエリパラメータをparamsというハッシュに解析します。この処理では、名前クエリパラメータの値を取得し、ERBレンダリングエンジンに渡してhello_world.html.erbテンプレートをレンダリングします。

もし前のコード行が混乱しているように見える場合は、以下のように書くこともできます。

render('application/hello_world', { locals: { name: name } })

これは実際には2つの引数を持つメソッド呼び出しであり、2番目の引数はキー/値のペアを持つハッシュです。キーはlocalsで、値は別のハッシュです。ERBエンジンでハッシュの：localsキーが見つかると、そのキーの値を使用してテンプレートがレンダリングされます。

Now if you type into your browser http://localhost:3000/hello_world?name=John you will see "Hello, John!".

これはうまくいきますが、我々はまた少し問題を導入しました。つまり、/ hello_worldを単独で打つと、次のようになります：

Hello, !

その理由は、nameはここにはnilであります。キーnameで渡されるクエリパラメータはありません。これはテンプレートがレンダリングされるときに上記のメッセージが不鮮明になることがあります。

これをいくつかの方法で修正することができますが、アクション内で名前をデフォルト値に設定しましょう：

app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
def hello_world
name = params['name'] || "World"
render 'application/hello_world', locals: { name: name }
end
end

これでクエリ文字列にnameを渡さなければ、hello, wolrd!をみることができます。
params [‘name’] || 上の ‘world’の行、|| （論理OR）は、何かがparams [‘name’]にあるかどうかを調べるためのチェックとして機能します。その値がtruthy（falseまたはnil以外の値）の場合、単に値を返します。それ以外の場合（「OR」）、「World」を返します。

URL取得パターンにレスポンス

クエリパラメータは、サーバーにデータを渡すのに便利ですが、それだけではありません。ルーティングとデーターキャプチャのためのURLマッチングパターンを指定することもできます。

たとえば、routes.rbファイルに新しい行を追加します。

config/routes.rb
Rails.application.routes.draw do
get '/hello_world/' => 'application#hello_world'
get '/hello/:name' => 'application#hello_world'
end

/ hello / Johnを訪問すると Hello、John！も表示されます。

パターン / hello /：nameは、/ hello / JohnのようなURLを持つリクエストをApplicationControllerのhello_worldアクションにルーティングするようにRailsに指示します。nameのプレースホルダーにマッチングする値、この場合、Johnはコントローラ内でparams [‘name’]を使用してアクセス可能になります。

上記の私たちのルートについて最後に気づくべきことは、同じアクションを指す2つのルートがあることです。これには何も問題はありません.Railsは単にURLパターンに一致する最初のルートを使用します。

Railsの魔法を解明します（3）

Wed, 13 Dec 2017 13:05:43 +0900

私たちの最初のアプリ

アプリをセットアップする

このシリーズの最初の2つのセクションでは、読者はRuby on Railsを学ぶためのブログアプリを構築するように求められます。これを開始するには、以下のコマンドを実行してスターターアプリをクローンします。

# make sure to use ruby version 2.2
$ git clone // wait for edit
$ cd demystifying_rails_app_template
$ bundle exec bundle install
$ bundle exec rails server
$ bundle exec railsサーバが起動したら、ブラウザでhttp：// localhost：3000 /にアクセスするだけでアプリケーションを使用できます。

このRailsアプリを起動して実行したら、HTTPリクエストに応答させましょう。

具体的には、ブラウザから/ hello_worldへのリクエストで、Hello、worldというテキストがブラウザに表示されるようにしたいとします。

Railsでは、本質的にと見るとこれは2つのステップのプロセスです。

１リクエストの送信先を定義します
２この種のリクエストを処理するコードを定義します
これらの1つ目は、ルートを宣言することによって実現されます。
２つ目は、コントローラに定義されたメソッドによって実現されます。このようなリクエストを処理するロジックを含む、コントローラにあるメソッドをアクションと呼びます。

次のいくつかの章では、最初のRailsアプリケーションを構築するための手順を説明します。

リクエストと応答の送信

ルートの定義

Railsアプリケーションの「入り口」は、Railsアプリケーションに着信リクエストを処理するコードの場所を知らせる「ルート」です。

ルートの必要性を証明するために、先にパスをアクセスしましょう。

http：// localhost：3000 / hello_worldにアクセスし、何が起こるかを見てください。

Routing Error
No route matches [GET] “/hello_world”

まだルートを定義していないため、このエラーが出てしまうんです。

このようなリクエストを、新しいアクションにポイントするルートを定義することでこのようなエラーが修正できます。

Railsルートファイルには、アプリのルートリストが含まれています。

各ルートは、HTTPメソッド（GET、POSTなど）とURLパターンの組み合わせで、コントローラーとアクションの組み合わせにマッピングされます。

このエラーは、GETリクエストとURLパターン/ hello_worldの組み合わせのルートがないことを示しています。

configディレクトリのroutes.rbファイルにルートを定義しましょう。

config/routes.rb
Rails.application.routes.draw do
get ‘/hello_world’ => ‘application#hello_world’
end

route.rbの中のブロックで、それぞれのHTTPメソットの後に、自分で名前をつけるメソッドが利用できます。

次に、URLパターンを定義し、コントローラと、このタイプのリクエストの処理コードが存在するアクションの組み合わせを定義します。

ここでは、このリクエストを処理するコードがApplicationControllerのhello_worldアクションに存在することを定義していますが、まだそれらを定義していないので、次にそれを行います。

ここで、http：// localhost：3000 / hello_worldページを更新すると、次のエラーが発生します。

Unknown action
The action ‘hello_world’ could not be found for ApplicationController

次のセクションでは、このルートのアクションをApplicationControllerで定義することで、この問題に取り組んでいきます。

アクションの定義

最初の指定ルートとして、ApplicationControllerに存在すべきhello_worldアクションを定義する時間です。

app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
def hello_world
render plain: 'Hello, World!'
end
end

コントローラーアクションの目的は、HTTPリクエストに応答し、適切なHTTP応答を構築することです。このアクションの場合、私たちはリクエストの詳細に完全に気を配らず、単にHello、World！何の関係もないメッセージを構築します。ここでは、renderメソッドの呼び出しはHTTP応答を設定するためであります。上記のrenderの呼び出しでは、「Hello、World！」を引き数として渡しました。したがって、生成されたレスポンスはtext / plainのコンテンツタイプとHello！World！の本文を持ちます。

レスポンスは次のようになります。

Cache-Control:max-age=0, private, must-revalidate
Connection:Keep-Alive
Date:Tue, 23 Feb 2016 01:21:23 GMT
Etag:W/"65a8e27d8879283831b664bd8b7f0ad4"
Server:WEBrick/1.3.1 (Ruby/2.3.0/2015-12-25)
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:24c23eec-8a37-49d9-bcaf-4f5b3f18aaaa
X-Runtime:0.021203
X-Xss-Protection:1; mode=block
Hello, World!

Rails内の応答を見ると、デバッガを使ってレスポンスを調べることができます。

render plain: 'Hello, World!'
binding.pry
### in Pry's console ###
response.body # => "Hello, World!"
response.content_type # => "text/plain"
response.status # => 200

これからいろいろなrenderの使い方を見ていきますが、今はrenderの仕事がコントローラのアクションの中核的な役割の1つ、つまりHTTPレスポンスの構築を達成することであることを認識すれば十分です。

さらに、上のApplicationControllerクラスはActionController :: Baseから継承しています。レンダリングメソッド（他にも多数）は、この継承のおかげで利用可能になりました。

ビューを使ってHTMLをレンダーする

私たちのルートがaction / hello_worldへのリクエストを適切に処理することができました。アクションをHTMLをレンダーするを変更するにしましょう。

app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
def hello_world
render inline: 'Hello, World!'
end
end

ここでは、plain：の代わりにinline：を使用して、レスポンスのコンテンツタイプをHTMLに設定して、レスポンスボディ文字列をレンダーに渡します。
レスポンスは次のようになります。

HTTP/1.1 200 OK
Cache-Control: max-age=0, private, must-revalidate
Connection: Keep-Alive
Content-Length: 22
Content-Type: text/html; charset=utf-8
Date: Tue, 23 Feb 2016 02:44:36 GMT
Etag: W/"1e401bc81108cb3e3dba191111bf9059"
Server: WEBrick/1.3.1 (Ruby/2.3.0/2015-12-25)
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: a2eac900-60da-460d-9757-94d8c41c4624
X-Runtime: 0.252767
X-Xss-Protection: 1; mode=block
Hello, World!

上記のほとんどは、前回のリスポンスは非常に似ています。いくつかの違いがありますが、その違いの1つはレスポンス本文にemタグがラップされていることです。

Rails内のレスポンスオブジェクトも調べてみましょう：
# assuming we're inside the hello_world action above...
render inline: 'Hello, World!'
binding.pry
### inside Pry ###
response.body # => "Hello, World!"
response.content_type # => "text/html"
response.status # => 200

ここでは、plain：の代わりにinline：を使用することで、コンテンツタイプがtext / htmlに適切に設定されていることがわかります。

今ページを更新すると、Hello、World！が表示されます。 text / htmlコンテンツタイプとHTMLレスポンス本文文字列のタグのおかげで、ブラウザのイタリック体でメッセージが表示されます。

ビューを使用したコンテンツ

今のアクションによってリクエストが処理されていますが、それには間違いがあります。私たちのアクションにはコンテンツがあります。

ここでの問題は、コントローラの仕事はコンテンツを保持することではなく、それは…まあ、制御することです。

きれいに書かれたコントローラアクションは、アプリケーションの他の部分の呼び出しを調整したり、必要なときにそれらの結果をまとめたりすることを除いて、それ自体はほとんど行いません。

コントローラアクションは単にリクエスト処理のディレクターに過ぎず、アプリケーションの他の部分に他の責任を委任する必要があります。

しかし、すでに、私たちのコンテンツは、HTMLメッセージを保持しています。
これを修正するには、そのHTMLをアクションから外しましょう。

単純なビューの作成

HTMLコンテンツはビューに属しています。したがって、HTMLコンテンツを保持するビューを作成してみましょう。

Hello, World!

これは以前と同じHTMLですが、今では独自のビューファイルに保存されています。これが重要なので、どこに配置したのか注意してください。

app/views/application/hello_world.html

すべてのビューはapp / viewsディレクトリにあります。そこから、それらを使用するコントローラとアクションに対応するディレクトリに配置されます。

ここでは、app / views / application / hello_world.htmlファイルが残っています。ビューが定義された状態で、コントローラでそれを利用しましょう：

### app/controllers/application_controller.rb ###
class ApplicationController < ActionController::Base
def hello_world
render 'application/hello_world'
end
end

NOTE：ページを再ロードする前に、Railsサーバを再起動してください。

さて、レンダーはすでに数回使用されていますが、ここでは単に文字列を渡すだけ。さらに、この文字列は、作成したばかりのビューのパスと一致することに注意してください。

その結果、hello_worldアクションは、新しく定義されたapplication / hello_worldビューを使用してHTMLレスポンスボディをレンダリングします。

レンダリングをこの方法で使用することは、以下のことと同じです。

render inline: File.read('app/views/application/hello_world.html')

ビューを指し示しているのか、アクション自体のレスポンスボディを設定しているのかに関わらず、常にHTTPレスポンスボディを設定するのはレンダリングの仕事です。
上で指摘したように、コンテンツをコントローラに置いたままにしておくのは悪い習慣なので、上のようなレンダー呼び出しレンダリングビューが表示されるのは一般的です。

Railsの魔法を解明します（2）

Sun, 10 Dec 2017 14:44:18 +0900

HTTP and Web Apps

いろんな意味では、ウェブアプリの開発に関して全てHTTPに関わっています。この事実はRailsのようなフレームワークを使って開発することにつれ急速に不明瞭になってしまうんです。きちんと覚えていただきたいのは、ウェブアプリの基礎的パラダイムは、あるHTTPリクエストを応答し、相応のHTTPリスポンスを作ることです。数多いのRailsのコンベンションズの存在はただそのプロセスを少し容易にしたいからです。

クライアントサーバーモデル

Railsのウェブアプリにおいては、クライアントはウェブブラウザであり、ウェブアプリはサーバー上で稼働しています。

任意の相互動作はブラウザからHTTPリクエストを送信するはじめ、アプリは以下の動作をとります。

１そのリクエストを処理する場所を特定します。
２事前定義されたロジックでリクエストを処理します。
３応答（リスポンス）を構築する。

これが完了すると、アプリはブラウザにHTTP応答を返します。ブラウザはユーザに応答を表示します。

すべてのクライアントとサーバーとの対話がHTTPリクエストから始まる

HTTPリクエストには3つの部分があります。

1 リクエストライン。
２リクエストヘッダー
３リクエスメッセージ本文

このシリーズでは、私たちはリクエストラインとそれに特に関わる2つの部分だけに注意します：

１リクエストメソッド
２リクエストパス

GETとポストは通常のHTTPメソッド、/hello_worldと/create_postはパスの例です。

パスは、ドメインの後に/があるURLで始まるURLの部分です。したがって、URL http://www.launchschool.com/booksの場合、/ booksはパスです。

以下のようなリクエストがWebアプリに出ます：

GET /hello_world
POST /create_post

そして、メソッドとパスの組み合わせに基づいて、それらと何をするかを決定します。

すべてのクライアント — サーバーインタラクションがHTTP応答で終了します

HTTP応答には3つの部分があります。

１ステータスコード
２ヘッダー
３本文（body）

ステータスコードは、サーバーがどのように処理したかの総体的な結果をクライアントに伝えます。よく出た値は、200（OK）、404（リソースが見つからない）、500（サーバー側エラー）です。

レスポンスのボディセクションは空でもかまいませんが、ほとんどの場合、本文セクションにHTMLドキュメントが入っています。これは、このシリーズで紹介する主要なHTTPレスポンスパターンです。

ウェブアプリは中間位置にある

リクエストと応答の間には、着信リクエストを解釈し、データベースから必要なデータを引き出し、あらかじめ定義されたビジネスルールに従って処理して、ユーザーのブラウザに表示されるHTMLドキュメントを含む応答を生成するのは、実際のウェブアプリであります。

フレームワークなしでゼロからWebアプリを実装することは可能ですが、最新のWebアプリのほとんどは、開発を容易にするRuby on Railsのようなフレームワークで構築されています。

このシリーズでは、Railsを使ってWebアプリケーションを構築する方法の詳細を学習します。

Railsの魔法を解明します（１）

Fri, 08 Dec 2017 18:51:32 +0900

イントロダクション
ウェブアプリ開発のフレームワークとして、ウェブアプリを構築する際に非常に役に立つでしょう。しかし、このことを成立する前提があります。それは、使用者はRailsを解決する問題をよく理解し、どうやって解決するかをきちんと分からなければなりません。

残念なことは、最も多いのガイドの内容は、どうして、それともどうやってRailsをするのかより、Railsをなにしたのかに集中しています。そのようなガイドは役に立つの場合は、開発者がやりたいことはガイドと全く一致するのみです。Railsを活用し、あらゆる課題を解決したいことはほぼ不可能でしょう。

私はこのガイドを書く目的は、他のガイドと違って、Railsのできることを全て示すことがなく、その代わりに、Railsのないウェブアプリの世界への旅です。この旅を通じて、読者はなぜフレームワークが存在し、フレームワークなしでウェブアプリを開発する際の痛みを実感することができます。そうすると、Railsのコンベンションを学習する時、それらの背景と理由を既に理解したので、私たちは戸惑いことがないでしょう。

話を短くすると、私は開発者がフレームワークを利用する前に、フレームワークなしでウェブ開発のことを理解すべきだと思います。

もしあなたはRailsに興味があり、あるいは試したことがあり、魔法だらけを感しているなら、このシリーズはおすすめです。同時に、このシリーズは復習のいい材料になるため、熟練者にとってもメリットがあると思います。

このシリーズを理解するの前置き知識は以下通りです。

The Command Line
Ruby
OO Ruby
HTTP
SQL
Basic HTML

このシリーズの読み方：

内容は大きく二つ分けています。

１Railsの魔法を解明する。
２Rails のコアコンベンションズ。

１の内容は、できるだけRailsのコンベンションを使用せず、シンプルなブログアプリを書くことを通してウェブアプリの基礎を直面し、Railsを軽減しようとする痛みを実感します。

後半は、私たちはRailsのコンベンションを利用して、もう一回ブログアプリを開発します。そうすると、前半が得られた知識の理解を一層に上がります。

しかしもっと大切なことは、Railsはただの開発ツールではありません。そのコンベンションにより、ウェブアプリの組織構造と実行方法という考え方をウェブ開発者に提供しました。真のパワーは、フレームワークのメカニズムとその原因を良く理解し、ただ使用するではなく、開発者のリクエストに応じて適応することができます。

このシリーズを読み終わった際、あなたがRailsの最も重要なコンベンションズを理解できます。しかしもっと肝心なのは、あなたがそれらは存在する理由と原因をわかりになっています。もしあなたはそのことも納得なら、このシリーズを読み続きしましょう。

次のステップを踏む前に、HTTPのことについて少し復習します。

なぜプログラミング未経験者がフレームワークから学習するのはダメ？

Wed, 19 Apr 2017 20:15:27 +0900

ソフトウェアエンジニアにとって仕事を通じて成長するのが一番早いと言われるけど、プログラミング未経験者にとって開発関連の仕事を獲得するのがほぼ不可能だと思う。

やはりある程度の知識やスキルを身につけ、自分なりのポートフォリオを持った以上仕事を見つけることが可能になるでしょう。

ここで、プログラミング未経験者にとって、ある程度の知識やスキルを身につけるため、一般的に二つの選択肢がある。一つは独学だ。私も最初はその道を選んだが、なかなか容易ではない。決して独学はだめというつもりはないけど、時間と効率のバランスから考えば、独学は一番良い方法と言えないと僕が思っている。

なぜかというと、一番重要な問題は、独学のリソースは非システムマチクだ。どのトッピクは、どのぐらいまで把握する必要か？また、ある知識点を完全に理解するため、その前提として不可欠なコンセップトなどは、独学者にとって知るはずがないものだ。

では、二番めの方法は、プログラミングbootcampに参加することだ。普通の場合、カリキュラムも体系化していて、プロジェクトに通じて実務経験も多少積んでることが可能だ。しかし、目的によるbootcampを選択する必要がある。そうしないと、大きな金と時間がルースしてしまう。

もし、ただの仕事を見つけるためなら、適当なbootcampを選んで、未経験者が１ヶ月あるいは３ヶ月を通って、ソフトウェアエンジニアの仕事が見つけることが可能だ。少なくとも、こう宣伝するbootcampは結構ある。

しかし、プログラミングを勉強するの目的は、ただの仕事を獲得ではなく、プロのエンジニアになりたい、何十年のもプロのエンジニアとして活躍するキャリアを目指している人にとって、そういうbootcampはあんまり役に立たないでしょう。

なぜなら、それらのbootcampに教えられたのは、フレームワークが中心で、一見は実務に近いや生産力が短時間に飛躍などメリットがあるが、実は致命的なミスは起こした。未経験者にとって、学習するべきなのは、ソルーション（フレームワーク）ではなく、その問題を学習すべきである。単なるソルーションを学んで、そのソルーションを解決する問題はしっかり理解しないなら、もし問題が少し変わって、既存のソルーションをうまく解決できない場合は結構ある。パーフェクトなソルーションは存在しないから、エンジニアとして問題を解決する際、用いたソルーションのトレードオフをしっかり把握した以上、その問題を望む通りに解決できると言える。

では、ウェブ開発において、プロのエンジニアになりたいあるいは何十年も活躍続けるキャリアが欲しいプログラミング未経験者にとって、ruby on rails，jquery、bootstapなどを最初から勉強せず、何を中心で勉強すべきか？

僕の答えは、変わらないものを勉強すべきだ。フレームワークが変わる。新しい技術はどんどん出る。ですが、ウェブ開発の基礎はあまり変わらない。プログラミング基礎、関係型データベース、httpプロトコルなどはあんまり変わらない。フレームワークがレベル高い抽象だ。そのしたの基礎になるものをしっかり分からないなら、フレームワークを精通することがもちろん不可能だと思う。

続きの話は僕の学習軌跡になるものだ。プログラミングの勉強を一年間を経ったので、ここで記録する。

新卒で就活する際、文系の僕がウェブサービスを作りたいと決めて、内定先を辞退して、ウェブ開発を一心に勉強することになった。

ウェブ開発（web application develop）と言えば、主な分野はフロントエンドとバックエンドになる。調べてみると、難易度がバックエンドの方が高い、バックエンドをクリアならフロントエンドもそこまで困難なことではないと考え、まずバックエンドから学習することが決定した。さらにバックエンドを分解し、その中でやはりプログラミング言語が大事だとわかり、MITとHarvardのオーペンコースを独学の教材として選定し、pythonとC言語をある程度触れることができました。この段階と言えば、まさにその学習のハニータイムと言えるでしょう。豊富な教材、新しい知識やスキルを身につける実感だ楽しくてたまらない。特に挫折もあったが、stackoverflowがあるおかけで、よくあった問題をほぼうまく解決した。これで２ヶ月経過した。

MITとHarvardのコースが終わった後、優秀なエンジニアになるためコンピューターサイエンスの理論知識が不可欠だと考え、続きは情報系の必須科目に勉強を着手始めた。離散数学を始め、論理回路、データ構造とアルゴリズム、コンピューターアキーテクチャー、オプレーティングシステムも結構力に入れた。この段階では正直というと、死ぬほど辛いだ。情報系の理論の世界に入ると、文系の僕にとってはまさに地獄のような状況だ。

しかし、F１のレーサーのように、車をうまく運転するため、車の性能やエンジンなどの知識が不可欠だと信じで、諦めずに３ヶ月で一通り目を通った。

この時点で既にプログラミングを勉強してから半年に近いになる。PythonやC言語である程度のonline judgement問題をクリアすることだできた。情報系知識もある程度有している。これから本格的にウェブ開発の学習を始めようと思い、ruby on rails tutorialを勉強始めた。この本を通じてミニバージョンのツィーターが完成できるが、コードは完全にコペーペーのものだ。もちろん、このweb applicationもほぼ理解しておらず、新しい機能を追加しようとしてもできない。このことに気づいたのは、web developにおいて要する知識の範囲は非常に広いのことだ。バックエンドにおいてさらいにダータベース、オブジェクト指向、SQLなどの領域がある。これらの学習リソースはプログラミング基礎と違って、体系化したコースはあんまりなかった。どの知識が必要、どのぐらい理解が必要なのか全然分からない。この段階はいわば迷う時期でした。

解決策としてbootcampを参加することに決めた。IT bootcampを選択する際、トッピク分割、カリキュラムの設計はもちろん重要だが、一番大切なのは、そのbootcampの教育哲学だと思う。

そこで、あるオンラインブートキャンプに惹かれた。

特徴としては主な三つがある。

一つは、完全把握に基づき学習することだ。つまり、あるトッピクを完全に把握する以上、次のトッピクに進むことができる。なぜこういう当たり前のことが大切だというと、もしトッピクA，B両方の習得度が８０％とする、トッピクABの学習度が６４％になってしまうだ。伝統的な教育システムと違って、学習のペースはスゲジュール通りではない。全ての人は学校にこういう経験があると思う：昨日の数学知識がまだ完全に理解していないのに、今日は先生が次のトッピクに進んでしまう。伝統的な教育システムと違って、このbootcampでは、例えばプログラミング基礎を完全に把握しないなら、オベジェクト指向のトピックへ進めないだ。このことを実現するため、審査という仕組みがある。つまり、学習ステージことに審査がある。紙面のテストとSKYPEやCLOUD9を利用して問題を回答しながらコーディングする必要から、コーディング能力だけでなく、コミュニケーション能力も不可欠だ。また、ここのインストラクターはシリコンバレー出身で、英語の会話力もトレーニングできる。

二つの特徴は、基礎重視、変わらないものを中心に教えられた。ruby on railsのことを勉強するために、最低でも６００時間の前置コースを完了する条件がある（もちろん審査がる）。その中で、プログラミング基礎、オベジェクト指向、SQL、HTTPなどの知識を中心に、体系的に教えられる。

三つの特徴は、大量な練習と繰り返す学習哲学だ。音楽家のように、完璧な演出するため、一般人が想像も尽きない練習時間を費やした。プログラミングの習得も似たようなものだ。また、あるトッピクに対して、ただ一回だけ学習するではなく、なんども復習する必要がある。なぜかというと、長期的な記憶形成には、重複しか方法がない。
このbootcampでは、明らかに不向きな人がいる。それは、短時間で仕事を獲得したい人だ。プログラミング未経験者の場合、１日学習時間が１０時間とすると、全てのコースを完成するため約半年が必要だ。通常の場合、卒業するため一年間以上の時間がかかる。

僕は１０月に参加し、今日までも半年になった。毎日の学習時間は平均６時間ぐらい、まだカリキュラムの半分に達しないが、基礎だけはしっかり勉強したという実感がある。ruby言語、SQL、HTTP、HTML、CSSなどに費やしたの何百時間が絶対に無駄ではないと信じている。

未経験の学習者にとって、これはThe Slow Path To Proficiency.