Railsの学習(ROUTING INTO DARKNESS)
最後のLevel5のROUTING INTO DARKNESS です。
Level5 ROUTING INTO DARKNESS
Resources
問題1 Resouce Route
Create a resouces route for zombies
解答例
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
| 3 | Jim | My Fathers Basement |
問題2 Route Matching
Create a custom route so that /undead will go to the undead action on the ZombiesController
解答例
問題3 Route Redirecting
Create redirect /undead to /zombies
解答例
問題4 Root Route
Create a root route to ZombiesController index action
解答例
問題5 Named Route
Create a named route. It should generate a path like '/zombies/:name' where :name is a parameter, and points to the index action in ZombiesController. Name the route 'graveyard'
解答例
感想
とりあえずRails for Zombiesが終わったんでどんどん次にいきたいと思います。次はtestを見ていきます。
git-dojo参加ブログ
ちょっと遅くなったけどgit-dojoの参加ブログです。
前半は@iwamatsuによるgitの説明で、後半は複数名でチームを組んでgitの使い方を学びました。特に「rebaseは怖くない！」ということを学べる構成になっていました。以下で講演の内容とやったことをまとめていきます。
講演内容まとめ
gitは分散バージョン管理システムである。
リモートリポジトリと複数のローカルリポジトリから構成されていて、チェックアウト、コミットは手元にあるローカルリポジトリで行う。
そして、他のサーバーに存在するリモートリポジトリにプッシュする。
履歴の参照や差分の確認、コミット、マージ、などを行うとき、ローカルで作業でき、リモートにアクセスしなくても作業できるので、動作が早い。
プッシュして初めて履歴などを共有することができる。
過去のコミットの履歴を全てハッシュで持っていて、時間的な変遷を管理することができる。
そしてgit reflogで作業履歴を確認することができる。
git-reflogを使えば、自分がこれまでHEADとして参照してきたコミット、つまり自分の過去の操作を一覧できる。これを利用して操作ミス直前の時点（コミット）を特定できれば、git-resetでその時点に――それがたとえgit-logに出てこない時点であっても――戻ることができる。つまり、この二つを覚えておけば大抵の操作ミスから回復できる。
90日以内なら取り戻すことができる。
git config --global gc.auto 0 # で90日たっても消えないようになる。
検索が遅いと感じたらgcする。
題材
Numbersファイルをチームで編集。
同じ人が連続でpushしないように順番を決める。
コミット、リモートにあげることを全員が５回以上する。
ルール
コミットごとに、自分で選んだ適当な数値の後ろに記号を追加削除する。
コミットメッセージに追加した記号や数値に関する情報を記載。
題材２
基本は題材１と同じ。追加事項はpullするときに--rebaseを必ずすることだけ。
.git/confug 以下にrebase = trueを書くことで必ずrebaseになる。
または、git config branch.master.rebase trueで勝手にgit pull --rebaseになる。
rebaseすることによる違い
rebaseすることでmergeのポイントをずらすことができる。
rebaseしなければクローンした時点、rebaseすれば最新のところにmergeすることになる。
以下で図を使って簡単に説明。
- 状況
originと並行に作業しているとします。
- rebaseなし
コンフリクトを解消してマージします。
すると、a,b,cの作業情報は残るがこれが続くとネットワーク図が複雑になっていきます
- rebaseあり
一番最新のところにコンフリクトを解消したa',b',c'がマージされます。a,b,cの情報はa',b',c'に変わってしまうがネットワーク図が見やすくなります。(履歴として残るコミットの数がrebaseなしより一回少ない)
手順
git clone git@github.com:git-dojo/team10.git
# 編集して
git add Numers
git commit -m 'コミットメッセージ' # コミットメッセージを書いてコミット。
git push origin master #でコンフリクトが起きたら
#最新バージョンをローカルに入れる
git pull --rebase origin master
#コンフリクトを解消してもう一度
git add Numbers
git rebase --continue
git push origin master
題材１のように普通にマージしたときにコンフリクトを起こすとmasterに戻るが、
git pull --rebaseでコンフリクトが起こると無名ブランチにはじかれる。
そこで、コンフリクトを解消してaddしたあとにgit rebaseをしてmasterに戻る必要がありcommitしてはいけない。commitがいらないのでコンフリクト前のコメントが反映される。
間違えて、無名branchにコミットしてしまった場合は以下のようして戻る。
git checkout -b hoge # 新たにブランチを切って移動。
git checkout master # masterに戻って
git merge hoge # 作成したブランチをマージする。
もしくは以下のいずれかのコマンドを打つ
git rebase --skip
git rebase --abort
小ネタ
- git config --global color.ui auto # 文字がカラーになる
- tig # を打つとコミット履歴が見れる。tigをインストールする必要がある
- git_box, towerっていうGUIもある
- git pull --rebase #（二回目以降はorigin masterを省略できる）
- git pullしてmergeコミットが入った場合の戻し方
git reset --hard ORIG_HEAD #でmergeされる前の状態に戻せる
最後に
mergeとrebaseの違いを学びました。今回使用した以下のリポジトリのネットワーク図を見るとわかりますが、前半はrebaseしていなかったのでネットワーク図がぐちゃぐちゃです。しかし、後半はrebaseをしていたのでまっすぐで綺麗なネットワーク図になっています。
今回使用したリポジトリ
http:github.com/git-dojo/team10
このようにrebaseをするとネットワーク図がわかりやすくなるが、上で説明したように情報が失われてしまいまいます。どちらが優れているかという質問に対して、「どちらも一長一短であるが私は必ずrebaseしています」という回答でしたので、とりあえず私もrebaseすることにします。
今回はブランチを切って作業をしなかったので次回はブランチを切った場合について詳しく学びたいです。
railsの学習(CONTROLLERS MUST BE EATEN)
続いて、Level 4 のTHE VIEW AIN'T ALWAYS PRETTYです。
Level 4 Challenges
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
| 3 | Jim | My Fathers Basement |
params = { :id => 1 }
/zombies/show.html.erb
問題1 Show Action
Create the show action for a Zombies Controller which finds a Zombie based on params[:id].
解答例
問題2 Respond To
Finish the respond_to block so the action returns xml format
解答例
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
| 3 | Jim | My Fathers Basement |
params = { :zombie => {:name => 'Gregg', :graveyard => 'TBA'} }
問題3 Controller Create Action
Write a create action that will create a new Zombie from the params and then redirect to the created zombie's show page
解答例
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
| 3 | Jim | My Fathers Basement |
tweets
| id | status | zombie_id |
| 1 | Where can I get a good bite to eat? | 1 |
| 2 | My left arm is missing, but I don't care | 2 |
| 3 | I just ate some delicious brains | 3 |
| 4 | OMG, my fingers turned green. #FML | 1 |
params = { :id => 4 }
/zombies/show.html.erb
問題4 Controller Before Filter
Add a before filter which calls a method to check if a zombie has no tweets. Redirect to zombies_path if they dont have tweets. Only on show.
解答例
Railsの学習(THE VIEW AIN'T ALWAYS PRETTY)
続いて、Level 3 のTHE VIEW AIN'T ALWAYS PRETTYです。
Level 3 Challenges
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
| 3 | Jim | My Fathers Basement |
問題1 Views Simple
Print out the Zombie's name and graveyard
解答例
問題2 Linking
Link to show the zombie. Use the zombie's name as the anchor text
解答例
問題3 Each Blocks
Use an each block to print the names of all the Zombies.
解答例
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
| 3 | Jim | My Fathers Basement |
tweets
| id | status | zombie_id |
| 1 | Where can I get a good bite to eat? | 1 |
| 2 | My left arm is missing, but I don't care | 2 |
| 3 | I just ate some delicious brains | 3 |
| 4 | OMG, my fingers turned green. #FML | 1 |
問題4 If
In the each block, if a Zombie has more than 1 tweet, print out SMART ZOMBIE
解答例
問題5 Linking In Blocks
In the each block, make the Zombie's name link to its edit page
解答例
Railsの学習(MODELS TASTE LIKE CHICKEN)
前回に引き続き、RailsForZombies(http://railsforzombies.org/)をやりました。
今回は、Level２のMODELS TASTE LIKE CHICKENです。
Level 2 Challenges
問題1 Create Model
Define a Zombie model
解答例
問題2 Validations 1
Add a validation that checks for the presence of a Zombie's name
解答例
問題3 Validations 2
Add a validation that checks for the uniqueness of a Zombie's name
解答例
問題4 Validations 3
Do both uniqueness and presence validation on a Zombie's name on a single line, using the new syntax
解答例
問題5 Belongs To
A Weapon should belong to a Zombie. Create that relationship
解答例
問題6 Relationship Find
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
weapons
| id | name | strength | zombie_id |
| 1 | Hammer | 1 | 1 |
| 2 | Chainsaw | 3 | 2 |
Assuming the models and relationships are properly defined, find all the weapons that belong to Zombie Ash
解答例
Railsの学習(Deep in CRUD)
久しぶりにブログ書きました。これからはどんどん更新を増やしていきたいと思います。
今回は、RailsForZombies(http://railsforzombies.org/)の紹介と、各エピソードの最後に出てくる確認問題の解答例を書いていきたいと思います。
まずRailsForZombiesとは、Ruby on Railsの初心者向け学習サイトのことです。Railsの基本的な操作をビデオで説明してくれます。説明は全て英語です。スライドがわかりやすいので英語が苦手でも問題ないと思います。これからRailsを学びたい人にはおすすめです。
ビデオの終わりには簡単なプログラミングの問題が出題されます。
Levelは1から5まであるみたいで、まずはLevel1のDeep in CRUDに挑戦したいと思います。
Level 1 Challenges
Resources
zombies
| id | name | graveyard |
| 1 | Ash | Glen Haven Memorial Cemetary |
| 2 | Bob | Chapel Hill Cemetary |
| 3 | Jim | My Fathers Basement |
問題1 Find
Find Zombie where id = 1 and store it in a variable
解答例
問題2 Create
Create a new Zombie
解答例
問題3 Find2
Find the last zombie in the database, but don't use ID's
解答例
問題4 Query
Find all Zombies ordered by their names
解答例
問題5 Update
Update Zombie 3's graveyard to 'Benny Hills Memorial'
解答例
問題6 Destroy
Destroy Zombie where ID = 3
解答例
デザインパターンについて2(Builderパターン)
続いて、Builderパターンについて調べました。同じく以下のURLからサンプルコードを実装した。
http://www.ceres.dti.ne.jp/~kaga/frame.html
サンプルコード
クラス図
出力
コードを見てみると、BuilderクラスではmakeTitleメソッドなどのインターフェイスを定めている。そして、DirectorクラスではBuilderクラスで定めたインターフェイスを使ってconstructメソッドを構成している。つまり、Directorクラスがインターフェイスを使ってBuilderクラスに指示している。インターフェイスを呼び出したときの中身は、継承しているTextBuilderクラスとHTMLBuilderクラスで実装しているので、インターフェイスが変わらなければ中身をいくら変更しても、Builderクラスを継承した他のクラスをいくら追加しても、インターフェイスを呼び出すだけのDirectorクラスには影響がないことがわかった。
使い方としては、Directorクラスの初期化時の引数として、TextBuilderクラスかHTMLBuilderクラスのインスタンスを選択する。そして、constructメソッドを呼び出すだけである。初期化時の引数を変えてもconstructメソッドの呼び出し方は変わらないが、出力は引数に応じて変更していることがわかる。
ここで、実際に影響がないことを、Builderクラスを継承しているStringBuilderクラスを追加して確かめてみた。
コード
クラス図
出力
StringBuilderクラスはBuilderクラスを継承していてインターフェイスは決まっているので、それに合わせてmakeTitleメソッドなどの中身を実装していきます。そして、Directorクラス初期化時の引数に指定して、同じようにconstructメソッドを呼び出すだけ。
このように、Builderクラスのメリットは
- インターフェイスが変わらなければ、Builderクラスを継承しているクラスの中身を変更してもDirectorクラスに影響がない。
- Builderクラスを継承しているクラスをいくら追加してもDirectorクラスに影響がない。そして、追加が容易である。
次は、Factory Methodパターンについて調べます。
