おれろぐ #z_a_ki3

(・∀・) オイ!

オリジナルステッカー作り〜会社選び編〜

さて、前回、ステッカーぺたぺた環境を構築した訳ですが、

ステッカーぺたぺたエンジニアに憧れて - おれろぐ #z_a_ki3

JavaDuke)関連のステッカーが手に入っておらず、手に入れる機会も無いので・・・

「無いのなら 作ってしまおう ステッカー」

という事で、オリジナルDukeステッカーを作りたいと思います!!

(今年はJava生誕20周年なのでJava Day TokyoやJJUG CCCで手に入るといいなぁ〜)

前提

  • 初めてのステッカー作り。
  • 印刷会社にコネがない。
  • デザイナーではない、普段はコード書いたりしているエンジニア(自称)

会社選び

まずはじめに、作ってくれる会社を探す必要があります。

[ シール 印刷 ] 【検索】

とりあえず、検索してみます。

世の中にはたくさん印刷会社があるので、どこの会社にするか悩みますが、
判断基準はこんな感じでしょうかね。

  • 価格
  • 納期
  • 入稿データの形式
  • 同人関連の取り扱いの有無
  • サイトの雰囲気

「同人関連の取り扱い」については、同人グッツは小ロットであったり、
印刷に関する知識が少なくても対応してもらえるかどうかを判断する為です。

そんなこんなでお願いする会社を絞り込んで、印刷の通販グラフィックさんに
お願いすることにしました。

印刷通販のグラフィック|各種印刷やオリジナルネットプリント作成の決定版!

会社が絞り込めたら、サンプル請求をして届くのを待ちます。
サンプルで印刷の質を確認するのは非常に重要です。

サンプルを見て、あ、コレは・・・と思ったらまた振り出しに戻ります。

サンプル請求が出来ない会社だったら・・・

残念ですが、もう一度、会社を選び直しましょう。

次回

素材選び編

ステッカーぺたぺたエンジニアに憧れて

この業界に入って、いろいろな勉強会に参加するようになって目についたのが
ステッカーぺたぺたエンジニアでした。

ステッカー エンジニア - Google 検索

ただ、ステッカーを貼り付けたら修理の時にどうなるんだろう、フォーマルな場に
持って行きたいときは・・・等と考えたりして、ちょっと日和ってました。

でも、やっぱりいいなーステッカー貼り付けたいなーなんて思っていたところで
天板にクリアのハードカバー付けてそこにステッカー付ければ良いじゃん!と
小学生並みの思いつきでカバーを探してみました。

まずはパワーサポートのエアージャケットセット!

うん、高い!

品質はそれなりなんだろうけど、単にステッカー貼り付けたいだけなので5千円は高い!!

で、カラーバリエーションが豊富(12色)で、安価だったMS factoryのコレにしました。

パッケージはこんな感じ

f:id:z_a_ki3:20150314110833j:plain

カバーは光沢ギラギラなので、この辺は好みが分かれるかも。
でも、ステッカーぺたぺた貼るので気にしない(・∀・)

f:id:z_a_ki3:20150314111430j:plain

f:id:z_a_ki3:20150314111456j:plain

ストッパーはこんな感じ。

f:id:z_a_ki3:20150314111546j:plain

ツメでぱっちんしてるだけなので、簡単に外せるかな。

とりあえず、カバーは付けたので、これからステッカーぺたぺたしていきます!

あと、Javaというか、Dukeのステッカーが手持ちでない&もらう機会が無いので、
ちょっと自作しようかなと思っています。

こんな感じで・・・

あ、この記事書くときに見つけた、こっちの方が(紹介によると)金型の痕が
無いらしいので神経質な人にはいいかもです。

MacにbrewでPostgreSQL

ローカルの開発環境にPostgreSQLをインストールしたので備忘録として。

インストール

パッケージ管理ツールbrew でインストールしました。

$ brew install postgres
==> Downloading https://homebrew.bintray.com/bottles/postgresql-9.4.1.yosemite.bottle.1.tar.gz
######################################################################## 100.0%
==> Pouring postgresql-9.4.1.yosemite.bottle.1.tar.gz
==> Caveats
If builds of PostgreSQL 9 are failing and you have version 8.x installed,
you may need to remove the previous version first. See:
  https://github.com/Homebrew/homebrew/issues/2510

To migrate existing data from a previous major version (pre-9.4) of PostgreSQL, see:
  http://www.postgresql.org/docs/9.4/static/upgrading.html

To have launchd start postgresql at login:
    ln -sfv /usr/local/opt/postgresql/*.plist ~/Library/LaunchAgents
Then to load postgresql now:
    launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
Or, if you don't want/need launchctl, you can just run:
    postgres -D /usr/local/var/postgres
==> /usr/local/Cellar/postgresql/9.4.1/bin/initdb /usr/local/var/postgres
==> Summary
🍺  /usr/local/Cellar/postgresql/9.4.1: 2996 files,  40M

自動起動の設定

ln -sfv /usr/local/opt/postgresql/*.plist ~/Library/LaunchAgents

実行結果

$ ln -sfv /usr/local/opt/postgresql/*.plist ~/Library/LaunchAgents
/Users/hoge/Library/LaunchAgents/homebrew.mxcl.postgresql.plist -> /usr/local/opt/postgresql/homebrew.mxcl.postgresql.plist

ln コマンドでシンボリックリンクを作成しています。

オプション 意味
-s シンボリックリンクを作成する。
-f リンク先ファイルが既に存在する場合、上書きする。
-v 実際にリンクを作成するファイル名を表示する。

~/Library/LaunchAgents はlaunchd*で各ユーザが管理するユーザごとに実行するエージェントの設定ファイルを置くディレクトリとなっています。

launchdはデーモン、アプリケーション、プロセス、スクリプトの起動・停止・管理を行う、オープンソースのサービス管理フレームワークである

設定ファイル homebrew.mxcl.postgresql.plist を覗いてみるとこんな感じ

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>KeepAlive</key>
  <true/>
  <key>Label</key>
  <string>homebrew.mxcl.postgresql</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/opt/postgresql/bin/postgres</string>
    <string>-D</string>
    <string>/usr/local/var/postgres</string>
    <string>-r</string>
    <string>/usr/local/var/postgres/server.log</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/usr/local</string>
  <key>StandardErrorPath</key>
  <string>/usr/local/var/postgres/server.log</string>
</dict>
</plist>
キー 意味
KeepAlive 1度起動したら継続的に実行されるのか、あるいはリクエストの度ごとに起動されるのかといった情報を定義する。 true
Lavel ジョブの名称 homebrew.mxcl.postgresql
ProgramArguments 実行するプログラムおよびオプション、引数など /usr/local/opt/postgresql/bin/postgres -D /usr/local/var/postgres -r /usr/local/var/postgres/server.log
RunAtLoad launchdにジョブがロードされたときすぐにタスクを起動するか true
WorkingDirectory ジョブを実行するまえにこのディレクトリにchdirする。 /usr/local
StandardErrorPath 立ち上げたプロセスのための入出力ファイルを定義 /usr/local/var/postgres/server.log

起動する

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

launchctl load で指定した設定ファイル(homebrew.mxcl.postgresql.plist)を読み込みます。

ログは /usr/local/var/postgres/server.log に出力されます。

$ cat /usr/local/var/postgres/server.log
LOG:  database system was shut down at 2015-03-12 21:35:58 JST
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

※停止する場合

launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

※launchdで自動起動の設定をしない場合

postgres -D /usr/local/var/postgres

とりあえず、これで起動まで出来ました。

参考

Mac(OS X)ではcronじゃなくてlaunchdでやる - Furudateのブログ
launchd - Wikipedia
launchd.plist(5) Mac OS X Manual Page

クール

数年前からいわゆる深夜アニメを見るようになりましたが、たびたびクールの定義が
分からなくなるので再確認しました。

1月から12月までの1年間は4クールに分けられ、それぞれ、第1・第2・第3・第4クール、冬・春・夏・秋クール、1月・4月・7月・10月クールなどと呼ばれる。 クール (放送) - Wikipedia

  • 1〜3月:冬
  • 4〜6月:春
  • 7〜9月:夏
  • 10〜12月:秋

今(3月)放送されているのは冬アニメってことですね。

以下、2015年春アニメで気になる作品

TVアニメ「パンチライン」

アニメ「浦和の調ちゃん」- 公式ホームページ -

TVアニメ「えとたま」公式サイト

TVアニメ「ハロー!!きんいろモザイク」公式サイト

てさぐれ!部活もの すぴんおふ プルプルんシャルムと遊ぼう|てさぐれ!部活もの|日本テレビ

【復習】Ruby on Rails入門 ~ミニブログを作りながら学ぶWebアプリケーション制作 第3回~

無料動画のオンライン学習サイトのスクーで鳥井 雪(@yotii23)先生が教えてくださる
RoR入門第3回を復習します。

Ruby on Rails入門 ~ミニブログを作りながら学ぶWebアプリケーション制作 第3回~ 鳥井 雪 先生 - 無料動画学習|schoo(スクー)

ゴール

  • Modelの役割、拡張のしかたを身につける
  • 1:多の「リレーション」の考え方を理解する

バリデーション:入力値に制約をつけてみよう

バリデーションとは(Railsとしての)

Railsがリクエストを受けて、コントローラからモデルに渡された値が、
保存(処理?)する条件にふさわしいか検証するModelの機能。

例えば)電話番号がすべて数字であるか?郵便番号の桁数があっているか?

やってみること

  • 「本文(body)」を必須項目にする(ないとエラー)
  • 「名前(name)」に文字数制限をつける(15文字以内)

「本文(body)」を必須項目にする

entry.rb にバリデーションの処理を追加する。

#修正前
class Entry < ActiveRecord::Base
end

#修正後
class Entry < ActiveRecord::Base
  validates :body, presence: true
end

詳細

http://railsguides.jp/active_record_validations.html#presence

「名前(name)」に文字数制限をつける

#修正前
class Entry < ActiveRecord::Base
  validates :body, presence: true
end

#修正後
class Entry < ActiveRecord::Base
  validates :body, presence: true
  validates :name, length: { maximum: 15 }
end

詳細

http://railsguides.jp/active_record_validations.html#length

他にも様々なバリデーションの設定が使えるので、実装しながら調べながら覚えるしかないですね。

http://railsguides.jp/active_record_validations.html

コメント機能を追加してみよう

作りたいものを考える

  • 投稿詳細画面(Showを押下し、遷移する画面)
  • もともとの投稿表示の下に投稿に対する複数のコメントのリスト
  • 新規コメントフォーム

データの名前と種類、関係性を考える

コメントというモデルはcommentという名前とします。
名前(投稿者名)はnameという名前で短い文字列、本文はbodyという名前で長いテキストとします。

短い文字列の形式はstring、長いテキストはtextという形式です。

Model同士の関係性を実現する

データの構造

entriesテーブル

id name body
1 hoge 本文1
2 foo 本文2
3 bar 本文3

commentsテーブル

id name body entry_id
1 hoge 本文1に対するコメント1 1
2 foo 本文1に対するコメント2 1
3 bar 本文2に対するコメント3 2

※関係性を表すデータは、Model名_idというカラムに相手のidを保存する。

commentモデルを生成する

$ rails generate scaffold comment name:string body:text entry_id:integer
$ rake db:migrate

Model同士の関係性をModelに書く

Entryモデル entry.rb

class Entry < ActiveRecord::Base
    has_many :comments
  (中略)
end

Commentモデル comment.rb

class Comment < ActiveRecord::Base
    belongs_to :entry
end

「今回時間が無いので言うとおりにやってください!」

今回はモデルの授業なのでコントローラやビューに関する実装はさくさく進みました。

コントローラ:Entry entries_controller.rb に追加。

# 修正前
def show
end

# 修正後
def show
    @comment = @entry.comments.build
end

entryに属するcommentを用意するメソッドを呼び出している。

この時点ではまだDBに保存されていない。

ビュー:entriesの詳細(show) /entries/show.html.erb に追加。

<h3>コメント</h3>

<% @entry.comments.each do |comment| %>

  <div>

    <strong><%= comment.name %></strong>

    <br />

    <p><%= comment.body %></p>

    <% if comment.persisted? %>

      <p><%= link_to 'Delete', comment_path(comment), method: :delete, data: { confirm: '削除してもよろしいですか?' } %></p>

    <% end %>

  </div>

<% end %>

<%= render 'comments/form' %>

<% @entry.comments.each do |comment| %> でentryに属するcommentを1つずつ取得して、
コメント毎の<div>ブロックを組み立ててます。

<%= render 'comments/form' %>はコメント投稿用のフォームをパーシャルで組み込んでるんですね。

<% if comment.persisted? %>persisted?は保存済みかどうかチェックするメソッドなので、
対象のコメントデータがDBに保存されていればコメントを削除する為のリンクを表示します。

ビュー:commentsのフォーム用パーシャル /comments/_form.html.erb を変更

変更前
<div class="field">
  <%= f.label :entry_id %><br>
  <%= f.number_field :entry_id %>
</div>

変更後
<%= f.hidden_field :entry_id %>

一般的にコメントを投稿するときにどのエントリーに属しているかを投稿者が入力することがないので、
ここでは関連づけの entry_id をhidden(隠し)項目に変更しています。

投稿者が関連づけを変更できてしまうとリレーションがめちゃめちゃになります。

コントローラ:Entry comments_controller.rb を修正。

# POST /comments
# POST /comments.json
def create
  @comment = Comment.new(comment_params)

  respond_to do |format|
    if @comment.save
      # 修正前
      format.html { redirect_to @comment, notice: 'Comment was successfully created.' }
      # 修正後
      format.html { redirect_to @comment.entry, notice: 'Comment was successfully created.' }

投稿完了後のリダイレクト先を @comment.entry でコメントが属しているエントリを取得し、設定している。

※このままだと削除したときにcomment一覧にリダイレクトしてしまうので、destroyも変更すると
完璧だと思います。

# DELETE /comments/1
# DELETE /comments/1.json
def destroy
  @comment.destroy
  respond_to do |format|
    # 変更前
    format.html { redirect_to comments_url, notice: 'Comment was successfully destroyed.' }
    # 変更後
    format.html { redirect_to @comment.entry, notice: 'Comment was successfully destroyed.' }

リレーション:has_many, belongs_to について

直訳すると

A has many B : Aは、多くのBを所有する。

Entry has_many comments(EntryはたくさんのCommentsを持っている)

A belongs to B : Aは、Bに属する。

Commentは(ひとつの)Entryに属している。

Comment belongs_to entry(Commentは(ひとつの)Entryに属している。)

has_many <-> belongs_to は対になって1:多の関係性を表す。

宿題

  • Commentモデルにバリデーションを追加してみよう
  • 名前に15文字制限
  • 本文に必須項目制限、140文字制限

これまで宿題はすっぽかしてきたので、しっかりやります。

# 変更前
class Comment < ActiveRecord::Base
  belongs_to :entry
end

# 変更後
class Comment < ActiveRecord::Base
  belongs_to :entry
  validates :name, length: { maximum: 15 }
  validates :body, presence: true
  validates :body, length: { maximum: 140 }
end

この実装だけだと、バリデーションエラーになったら + 投稿する + コメントの詳細画面に飛ぶ + エラー詳細が表示される

な流れでいちいち画面遷移するの気持ち悪いからコメント入力しているエントリの詳細画面に
パーシャルで埋め込んだコメントのフォーム部分でエラー詳細を出したいんだけど、、、

f:id:z_a_ki3:20150304171443p:plain

コントローラを修正するんだろうなと当たりはついているけど、どう直せば良いか
わからない、、、0(:3 )~ =͟͟͞͞(’、3)_ヽ)_

おまけ:Railsのモデルを可視化する。

Graphvizパッケージをインストールする

sudo yum install graphviz

Gemfilerails-erd を追加する。

gem 'rails-erd'

rake erd を実行する。

$ bundle exec rake erd

実行するとカレントディレクトにpdfファイルができます。
文字化けは気にしないでください。

今回のcommentモデル作成時点

f:id:z_a_ki3:20150304171632p:plain

モデルに関連性(has_many, belongs_to)追加時

f:id:z_a_ki3:20150304171726p:plain

ちゃんと関連性がついたのがわかります。便利ですね。

オススメ書籍

紹介されてました電車本です。

RailsによるアジャイルWebアプリケーション開発 第4版

RailsによるアジャイルWebアプリケーション開発 第4版

ただ、Rails3.2対応と古いですし、常にRailsは変化していくので
先生もおっしゃられていましたが Ruby on Rails チュートリアル で 学んだ方がいいと思います。

Ruby on Rails チュートリアル:実例を使って Rails を学ぼう

【復習】Ruby on Rails入門 ~ミニブログを作りながら学ぶWebアプリケーション制作 第2回~

無料動画のオンライン学習サイトのスクーで鳥井 雪(@yotii23)先生が教えてくださる
RoR入門第2回を復習します。

Ruby on Rails入門 ~ミニブログを作りながら学ぶWebアプリケーション制作 第2回~ 鳥井 雪 先生 - 無料動画学習|schoo(スクー)

ゴール

  • リクエストからレスポンスまでの、Rails内部での処理の流れを理解する。
  • View(表示)のカスタマイズができるようになる。

リクエストからレスポンスまでのRailsの処理の流れ

1.routes.rbで処理を分岐する。

URL+HTTPメソッドでどの処理を実行するかは ./config/routes.rb で定義する。

前回scaffoldで生成したentriesは以下のように定義されている。

Rails.application.routes.draw do
  resources :entries

リクエスト(URL+HTTPメソッド)を受けたRailsroutes.rb でどの処理を
呼び出すかを、決定し、その"処理"を実行してレスポンスを返す。

※同じURLでもHTTPメソッドが違っていれば異なる処理を実行することもある。

処理を構成する三要素:MVC

"処理"は3つの要素に分かれていて、それをMVCと呼ぶ。

  • M:Model(モデル)
  • V:View(ビュー)
  • C:Controller(コントローラ)

2.MVCでレスポンスをつくる

  • routes.rbからどのControllerのどの処理を実行するか決定する。*
  • Controllerを呼び出す。*
  • ControllerがModelを呼び出す
  • Modelがデータを用意し、Controllerに返す
  • ControllerがデータをViewに渡す
  • Viewがレスポンスを用意する

※処理の流れの理解は大事

MVCの基本

RailsMVCディレクトリ構造

./my_app/app/ の下にmodels,controllers,viewsが配置されている。

 my_app
    ├── app
    │   ├── assets
    │   ├── controllers *
    │   ├── helpers
    │   ├── mailers
    │   ├── models      *
    │   └── views       *

Controllerの主な役割

  • routes.rb から一番最初に呼ばれる
  • Modelを呼び出してデータを揃える(揃えさせる)
  • 揃えた(Modelから受け取った)データをViewに渡す

前回、scaffoldで生成したentryのコントローラはentries_controller.rb

class EntriesController < ApplicationController
  before_action :set_entry, only: [:show, :edit, :update, :destroy]

  # GET /entries
  # GET /entries.json
  def index
    @entries = Entry.all
  end
  ~略~
  • URLで /entries を指定してアクセスした場合、routes.rbdef index を呼び出す。
  • #で始まるコメントに対応するURLが記載されている。(コマンドで作成した場合)
  • Entry.all は一覧画面用にモデルから全てのデータを取得する処理。
  • @entriesはインスタンス変数で、インスタンス変数の値はViewに渡すことができる。
  • def から end までの間にViewを呼び出す処理がないが、railsが対応するViewを呼び出す。

HTTPメソッドとControllerの対応付けは以下が参考になります。

Rails のルーティング — Rails ガイド

Modelの主な役割

  • データのやり取りを担当する
  • ActiveRecode::Baseに基本の機能が用意されている
  • クラスの名前からテーブル名を推測する

前回、scaffoldで生成したentryのモデルはentry.rb

class Entry < ActiveRecord::Base
end
  • クラスをみると空だが、Railsが用意している ActiveRecode::Base を継承している。
  • モデルに対応するテーブル名は命名規則(テーブル名;モデル名の複数形)から推論している。
  • ここにはモデル固有の処理(文字数制限をしたり他のデータとの関係性などをつけたり)を書いていく。

Viewの主な役割

  • 渡されたデータに基づいてHTML(など)を組み立てる
  • 「画面」ごとに対応する1ファイルがある

前回、scaffoldで生成したentryのビューは/views/entries配下の複数ファイル

サンプルは index.html.erb

<p id="notice"><%= notice %></p>

<h1>Listing Entries</h1>

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Body</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody>
    <% @entries.each do |entry| %>
      <tr>
        <td><%= entry.name %></td>
        <td><%= entry.body %></td>
        <td><%= link_to 'Show', entry %></td>
        <td><%= link_to 'Edit', edit_entry_path(entry) %></td>
        <td><%= link_to 'Destroy', entry, method: :delete, data: { confirm: 'Are you sure?' } %></td>
      </tr>
    <% end %>
  </tbody>
</table>

<br>

<%= link_to 'New Entry', new_entry_path %>
  • <% @entries.each do |entry| %>@entries はControllerに登場したインスタンス変数。
  • <% code %> は中に記載したRubyコードを実行する。(実行のみ)
  • <%= code %> は中に記載したRubyコードを実行し、その実行結果を埋め込む。
  • <td><%= entry.name %></td>entry.name を実行し、その実行結果がもし z_a_ki3 であれば
    <td>z_a_ki3</td> となる。

ちなみに link_to は良い感じにリンクを生成してくれるヘルパーと呼ばれるものなんですが、詳細は別途・・・

MVCのメリット

MVCと3つに役割を分担することで、開発しやすくメンテナンスしやすいアプリケーションになる。

MVCRailsでもJavaASP.NETなどでも当たり前になっているデザインパターンなので、
MVC何それおいしいの?状態にならないように基本的なことは押さえておいた方が良いと思います。

ただ、MVCは"こう実装するのがジャスティス!"なものが無いのでここは経験を積みましょう。

やはりお前らのMVCは間違っている

ぼくがかんがえたさいきょうのMvc

HTTPメソッドの種類

HTTPメソッド 処理内容
GET データを取得する
POST 作成
PUT(PATCH) 更新
DELETE 削除

このなかで更新はPUTとPATCHで多重定義されています。

授業の中では仕様が揺れていると言うことでしたが、Rails4で更新はPATCHとされたようです。
なので、新しいRailsを使うのであれば"更新はPATCH"と考えても良いかもしれません。

Rails アップグレードガイド — Rails ガイド

また、PUTとPATCHの違いについては以下のページに詳細があります。

次期RailsがPATCHメソッドを採用 - ぶろぐ。@はてな

CRUDとHTTPメソッドの対応

CRUD HTTPメソッド
CREATE POST
READ GET
UPDATE PUT(PATCH)
DELETE DELETE

Viewをカスタマイズしよう!

アンケート:HTMLとCSSの関係が説明できますか?

  • HTMLは文章を構造化する為の言語
  • CSSはHTMLなどの構造に対する修飾の定義

Viewの役割

  • レスポンスの最終的な形を整形する
  • HTML+Rubyのプログラム+RailsでHTMLを便利に書くヘルパー
  • <% %>で囲まれた部分はRubyのプログラムを書ける
  • <%= %>で囲まれた部分はRubyのプログラムを使って書き出される内容がかける

app/views/entries.index.html.erbを編集する

まずは表示を日本語に変更します。

編集前

編集前
<h1>Listing Entries</h1>

編集後
<h1>投稿一覧</h1>

一覧画面以外のタイトルは当然、影響を受けていません。

app/views/layouts/application.index.html.erbを編集する

編集前
<%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track' => true %>

編集後
<link rel="stylesheet" href="//railsgirls.com/assets/bootstrap.css" />
<link rel="stylesheet" href="//railsgirls.com/assets/bootstrap-theme.css" />
<%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track' => true %>
変更前
<%= yield %>

変更後
<div class="container">
    <%= yield %>
</div>

※これはRails Girlsのサイトで配備されてるcssファイルを拝借してる感じなので、実際の自分のアプリを使う場合は、
自分でダウンロードしたファイルを使うか、Bootstrap CDNを使わないとダメですね。

Getting started · Bootstrap

編集前
<link rel="stylesheet" href="//railsgirls.com/assets/bootstrap.css" />
<link rel="stylesheet" href="//railsgirls.com/assets/bootstrap-theme.css" />

編集後
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.2/css/bootstrap.min.css" />
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.2/css/bootstrap-theme.min.css" />

これで一覧画面、詳細画面、作成画面等を見ると全ての画面で追加したスタイルシートが適用されてます。

ここで登場している <%= yield %> の裏にある処理がとっても気になるんですが、とりあえず、
関連しそうなリンクを張り逃げして、再復習の時にまた追っていきたいと思います。

yield を理解できるまで寝ないスレッド · Issue #336 · yochiyochirb/meetups · GitHub

レイアウトと個別のview

  • headerやfooterなどの共有部分:application.index.html.erb
  • 個別のページの内容:index.html.erb

app/views/entries/_form.html.erbを編集する

変更前
<%= f.label :name %><br>

変更後
<%= f.label :name,"名前" %><br>
変更前
<%= f.label :body %><br>

変更後
<%= f.label :body,"本文" %><br>

今回、修正した f.label は次のような構文になっていて、ラベル配下のコンテンツを追加しています。

f.label(プロパティ名 [, ラベル配下のコンテンツ] [, オプション])

label - リファレンス - Railsドキュメント

個別のviewと共通のview(パーシャル)

/entries/newentries/1/edit の画面を見てみると非常に似た構造になっています。
ここで views/entries 配下の new.html.erb を見てみると、

new.html.erb

<h1>New Entry</h1>

<%= render 'form' %>

<%= link_to 'Back', entries_path %>

<%= render 'form' %><%= link_to 〜 %> しかありません。
次に edit.html.erb を見てみると、

edit.html.erb

<h1>Editing Entry</h1>

<%= render 'form' %>

<%= link_to 'Show', @entry %> |
<%= link_to 'Back', entries_path %>

同じく <%= render 'form' %><%= link_to 〜 %> しかありません。

この中で <%= render 'form' %> が、先ほど編集した _form.html.erb に対応しています。

個別のViewの中で共通している部分をパーシャルという仕組みでまとめる事ができます。
パーシャルのファイル名は""(アンダーバー)からはじめ、renderで指定するときは""を外す。

次回以降の内容

  • Railsが作ってくれた今の機能に、自分のやりたいことを足してゆく
  • 新しい情報を付け加える
  • Railsの構造、モデルの機能追加を理解する

宿題

  • 自分で個別のviewファイルとレイアウトのファイルを書き換えてみて、その変更を見てみましょう
  • 全ページに共通のフッターをつけてみましょう

application.html.erb を修正

変更前
<%= yield %>

変更後
<%= yield %>
<footer>&copy; Copyright 2015, @z_a_ki3.</footer>

単純に足しただけ・・・

  • /entries/ ページの "Name" と "Body" を日本語に書き換えてみましょう。

index.html.erb を修正

変更前
<th>Name</th>
<th>Body</th>

変更後
<th>名前</th>
<th>本文</th>

単純に変えただけ・・・

質疑応答

オススメのサイト

第1章 ゼロからデプロイまで | Rails チュートリアル

AppleCare Protection Plan に入った

今、メインで使ってるMacBookProは去年の3月に購入したもので、先月、Appleさんから
そろそろ通常保証切れるでー、延長プラン買うなら今のうちやでーってメールが来てて

f:id:z_a_ki3:20150303211910p:plain

使わなかったら払い損だしなー、でも、もし持ち運んだり、普通に使ってて壊れたとき、
お金かかるしなーなんて保険に入るとき特有の葛藤がありつつも、とりあえず加入しました。

f:id:z_a_ki3:20150303211925p:plain

最初は地元のビックカメラに行って、探したものの"店頭登録用"という同時購入を対象とした
ものしか取り扱っておらず、無駄に駐車料金を払う羽目に٩(๑`ȏ´๑)۶

気を取り直して、有楽町ビックまで出向いて無事にパッケージ版を購入することができました。

ちなみに受けられるサポートは

  • Appleの専任スペシャリストへのダイレクトアクセス
  • グローバルでの修理サービス
  • デスクトップコンピュータの出張修理
  • ノートブックコンピュータとApple製ディスプレイのピックアップ&デリバリー修理
  • 持ち込み修理

修理の対象は

この中で実際使いそうなのはノートPCのピックアップ&デリバリー修理か、持ち込み修理、
対象はMac本体、電源アダプタくらいかなと。

ディスプレイは同時購入していないので対象外、AirMacSuperDriveはこれから購入して、
対象になるのか分からないので、使えないと考えた方がいいでしょう。

そう考えるとディスプレイや周辺機器もMacと同時購入した方がお得かなと思ってしまいますね。


[2015/3/4 追記]

AirMac Extreme Card、AirMac Express、もしくはAirMac Extreme Base Station、Time CapsuleAppleブランドのDVI-ADC ディスプレイアダプタ、Apple RAMモジュールおよびMacBook Air SuperDriveが対象機器とともに使用され、お客様がこれらの製品を対象機器の購入前の2年以内の間に最初に購入された場合、これらの製品が「対象機器」に含まれます。

"対象機器の購入前の2年以内の間に最初に購入された場合"とあるので、契約期間中に
購入したこれらの周辺機器も保証対応になるんですね。

日本語の読解力の無さが辛いです。


また規約中で範囲対象外として液体接触と書かれてるので飲み物こぼしたりとかは
保証されないので気をつけないといけないですね。

そう考えると使う場面あるのかなーと改めて思ってしまうのですが・・・(๑•́ω•̀)

これからは積極的に持ち出すぞー⁽⁽٩(๑˃̶͈̀ ᗨ ˂̶͈́)۶⁾⁾