オリジナルステッカー作り〜会社選び編〜
さて、前回、ステッカーぺたぺた環境を構築した訳ですが、
ステッカーぺたぺたエンジニアに憧れて - おれろぐ #z_a_ki3
Java(Duke)関連のステッカーが手に入っておらず、手に入れる機会も無いので・・・
「無いのなら 作ってしまおう ステッカー」
という事で、オリジナルDukeステッカーを作りたいと思います!!
(今年はJava生誕20周年なのでJava Day TokyoやJJUG CCCで手に入るといいなぁ〜)
前提
- 初めてのステッカー作り。
- 印刷会社にコネがない。
- デザイナーではない、普段はコード書いたりしているエンジニア(自称)
会社選び
まずはじめに、作ってくれる会社を探す必要があります。
[ シール 印刷 ] 【検索】
とりあえず、検索してみます。
世の中にはたくさん印刷会社があるので、どこの会社にするか悩みますが、
判断基準はこんな感じでしょうかね。
- 価格
- 納期
- 入稿データの形式
- 同人関連の取り扱いの有無
- サイトの雰囲気
「同人関連の取り扱い」については、同人グッツは小ロットであったり、
印刷に関する知識が少なくても対応してもらえるかどうかを判断する為です。
そんなこんなでお願いする会社を絞り込んで、印刷の通販グラフィックさんに
お願いすることにしました。
印刷通販のグラフィック|各種印刷やオリジナルネットプリント作成の決定版!
会社が絞り込めたら、サンプル請求をして届くのを待ちます。
サンプルで印刷の質を確認するのは非常に重要です。
サンプルを見て、あ、コレは・・・と思ったらまた振り出しに戻ります。
サンプル請求が出来ない会社だったら・・・
残念ですが、もう一度、会社を選び直しましょう。
次回
素材選び編
ステッカーぺたぺたエンジニアに憧れて
この業界に入って、いろいろな勉強会に参加するようになって目についたのが
ステッカーぺたぺたエンジニアでした。
ただ、ステッカーを貼り付けたら修理の時にどうなるんだろう、フォーマルな場に
持って行きたいときは・・・等と考えたりして、ちょっと日和ってました。
でも、やっぱりいいなーステッカー貼り付けたいなーなんて思っていたところで
天板にクリアのハードカバー付けてそこにステッカー付ければ良いじゃん!と
小学生並みの思いつきでカバーを探してみました。
まずはパワーサポートのエアージャケットセット!
パワーサポート エアージャケットセット for Macbook Pro 15inch Retinaディスプレイ(クリア) PMC-41
- 出版社/メーカー: パワーサポート
- 発売日: 2013/01/30
- メディア: Personal Computers
- クリック: 1回
- この商品を含むブログを見る
うん、高い!
品質はそれなりなんだろうけど、単にステッカー貼り付けたいだけなので5千円は高い!!
で、カラーバリエーションが豊富(12色)で、安価だったMS factoryのコレにしました。
パッケージはこんな感じ
カバーは光沢ギラギラなので、この辺は好みが分かれるかも。
でも、ステッカーぺたぺた貼るので気にしない(・∀・)
ストッパーはこんな感じ。
ツメでぱっちんしてるだけなので、簡単に外せるかな。
とりあえず、カバーは付けたので、これからステッカーぺたぺたしていきます!
あと、Javaというか、Dukeのステッカーが手持ちでない&もらう機会が無いので、
ちょっと自作しようかなと思っています。
こんな感じで・・・
ビックリマンシール風Duke pic.twitter.com/GsgvBoW2rj
— ざきやま@IDEA試用中 (@z_a_ki3) 2015, 3月 13
あ、この記事書くときに見つけた、こっちの方が(紹介によると)金型の痕が
無いらしいので神経質な人にはいいかもです。
[NEXARY] MacBook Pro Retina 15 インチ クリスタル ハードケース / 金型跡無し、ACアダプタポーチ セット (透明 PR15 クリア)
- 出版社/メーカー: NEXARY
- メディア: エレクトロニクス
- この商品を含むブログを見る
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年春アニメで気になる作品
【復習】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
この実装だけだと、バリデーションエラーになったら + 投稿する + コメントの詳細画面に飛ぶ + エラー詳細が表示される
な流れでいちいち画面遷移するの気持ち悪いからコメント入力しているエントリの詳細画面に
パーシャルで埋め込んだコメントのフォーム部分でエラー詳細を出したいんだけど、、、
コントローラを修正するんだろうなと当たりはついているけど、どう直せば良いか
わからない、、、0(:3 )~ =͟͟͞͞(’、3)_ヽ)_
おまけ:Railsのモデルを可視化する。
Graphvizパッケージをインストールする
sudo yum install graphviz
Gemfile
に rails-erd を追加する。
gem 'rails-erd'
rake erd
を実行する。
$ bundle exec rake erd
実行するとカレントディレクトにpdfファイルができます。
文字化けは気にしないでください。
今回のcommentモデル作成時点
モデルに関連性(has_many, belongs_to)追加時
ちゃんと関連性がついたのがわかります。便利ですね。
オススメ書籍
紹介されてました電車本です。
RailsによるアジャイルWebアプリケーション開発 第4版
- 作者: Sam Ruby,Dave Thomas,David Heinemeier Hansson,前田修吾
- 出版社/メーカー: オーム社
- 発売日: 2011/12/01
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 206回
- この商品を含むブログ (40件) を見る
ただ、Rails3.2対応と古いですし、常にRailsは変化していくので
先生もおっしゃられていましたが Ruby on 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メソッド)を受けたRailsは routes.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の基本
RailsのMVCディレクトリ構造
./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.rb
はdef index
を呼び出す。 - #で始まるコメントに対応するURLが記載されている。(コマンドで作成した場合)
Entry.all
は一覧画面用にモデルから全てのデータを取得する処理。- @entriesはインスタンス変数で、インスタンス変数の値はViewに渡すことができる。
def
からend
までの間にViewを呼び出す処理がないが、railsが対応するViewを呼び出す。
HTTPメソッドとControllerの対応付けは以下が参考になります。
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つに役割を分担することで、開発しやすくメンテナンスしやすいアプリケーションになる。
MVCはRailsでもJava、ASP.NETなどでも当たり前になっているデザインパターンなので、
MVC何それおいしいの?状態にならないように基本的なことは押さえておいた方が良いと思います。
ただ、MVCは"こう実装するのがジャスティス!"なものが無いのでここは経験を積みましょう。
HTTPメソッドの種類
HTTPメソッド | 処理内容 |
---|---|
GET | データを取得する |
POST | 作成 |
PUT(PATCH) | 更新 |
DELETE | 削除 |
このなかで更新はPUTとPATCHで多重定義されています。
授業の中では仕様が揺れていると言うことでしたが、Rails4で更新はPATCHとされたようです。
なので、新しいRailsを使うのであれば"更新はPATCH"と考えても良いかもしれません。
また、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を使わないとダメですね。
編集前 <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(プロパティ名 [, ラベル配下のコンテンツ] [, オプション])
個別のviewと共通のview(パーシャル)
/entries/new
と entries/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
で指定するときは""を外す。
次回以降の内容
宿題
- 自分で個別のviewファイルとレイアウトのファイルを書き換えてみて、その変更を見てみましょう
- 全ページに共通のフッターをつけてみましょう
application.html.erb
を修正
変更前 <%= yield %> 変更後 <%= yield %> <footer>© Copyright 2015, @z_a_ki3.</footer>
単純に足しただけ・・・
- /entries/ ページの "Name" と "Body" を日本語に書き換えてみましょう。
index.html.erb
を修正
変更前 <th>Name</th> <th>Body</th> 変更後 <th>名前</th> <th>本文</th>
単純に変えただけ・・・
質疑応答
オススメのサイト
AppleCare Protection Plan に入った
今、メインで使ってるMacBookProは去年の3月に購入したもので、先月、Appleさんから
そろそろ通常保証切れるでー、延長プラン買うなら今のうちやでーってメールが来てて
使わなかったら払い損だしなー、でも、もし持ち運んだり、普通に使ってて壊れたとき、
お金かかるしなーなんて保険に入るとき特有の葛藤がありつつも、とりあえず加入しました。
最初は地元のビックカメラに行って、探したものの"店頭登録用"という同時購入を対象とした
ものしか取り扱っておらず、無駄に駐車料金を払う羽目に٩(๑`ȏ´๑)۶
気を取り直して、有楽町ビックまで出向いて無事にパッケージ版を購入することができました。
ちなみに受けられるサポートは
- Appleの専任スペシャリストへのダイレクトアクセス
- グローバルでの修理サービス
- デスクトップコンピュータの出張修理
- ノートブックコンピュータとApple製ディスプレイのピックアップ&デリバリー修理
- 持ち込み修理
修理の対象は
- Mac本体
- 電源アダプタなどの付属品
- Apple純正メモリ(RAM)
- AirMac
- Apple USB SuperDrive (MacBook Air、MacBook Pro Retinaディスプレイモデル、iMac、Mac mini用)
- Macと同時購入のApple製ディスプレイ1台
この中で実際使いそうなのはノートPCのピックアップ&デリバリー修理か、持ち込み修理、
対象はMac本体、電源アダプタくらいかなと。
ディスプレイは同時購入していないので対象外、AirMacとSuperDriveはこれから購入して、
対象になるのか分からないので、使えないと考えた方がいいでしょう。
そう考えるとディスプレイや周辺機器もはMacと同時購入した方がお得かなと思ってしまいますね。
[2015/3/4 追記]
AirMac Extreme Card、AirMac Express、もしくはAirMac Extreme Base Station、Time Capsule、AppleブランドのDVI-ADC ディスプレイアダプタ、Apple RAMモジュールおよびMacBook Air SuperDriveが対象機器とともに使用され、お客様がこれらの製品を対象機器の購入前の2年以内の間に最初に購入された場合、これらの製品が「対象機器」に含まれます。
"対象機器の購入前の2年以内の間に最初に購入された場合"とあるので、契約期間中に
購入したこれらの周辺機器も保証対応になるんですね。
日本語の読解力の無さが辛いです。
また規約中で範囲対象外として液体接触と書かれてるので飲み物こぼしたりとかは
保証されないので気をつけないといけないですね。
そう考えると使う場面あるのかなーと改めて思ってしまうのですが・・・(๑•́ω•̀)
これからは積極的に持ち出すぞー⁽⁽٩(๑˃̶͈̀ ᗨ ˂̶͈́)۶⁾⁾