最近まとまった時間ができたので、Web開発手法の勉強をしていました。
Ruby on Railsチュートリアルが体系的に学べて良いという話を聞いていたので、これを軸にしながら自分のWeb知識の穴を埋めていくことにしました。
Ruby on Rails チュートリアル:実例を使って Rails を学ぼう
一区切りついたのでまとめておきたいと思います。
前提知識
以下は勉強を始める前の私の知識です。
Webフレームワークを使ったことがない
Rubyを一行も書いたことがない
- CS的なインフラの基本技術は知っているが、IaaSやPaaSなどにはあまり明るくない
参考書
Railsチュートリアルをやる前に、参考書でWeb技術に基礎を固めました。
最初にWebを支える技術を読みました。
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者: 山本陽平
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 単行本(ソフトカバー)
- 購入: 143人 クリック: 4,320回
- この商品を含むブログ (183件) を見る
RESTの基本を学ぶのに非常に役立ちました。またステートレスやリソースなど、「なんとなく意味はわかるけど正確には知らない」知識を得ることができたり、実践的なAPI設計などが書かれていて非常に良い本だと思います。途中microformatsやAtomなど、今ではあまり使われていない技術に多くのページが割かれているので、興味がない人は適当に読み飛ばせばいいと思います。(Webの栄枯盛衰を感じる歴史としては面白いと思います。)
- 作者: 竹下隆史,村山公保,荒井透,苅田幸雄
- 出版社/メーカー: オーム社
- 発売日: 2012/02/25
- メディア: 単行本(ソフトカバー)
- 購入: 4人 クリック: 34回
- この商品を含むブログ (36件) を見る
名著だと言われていますが、教科書的で結構退屈です。また既に知っている知識が多かったので、私は適当に読み流しました。
低レイヤーを学んだので、次は高レイヤーのIaaSやPaaSを学ぶことにしました。今回はAWSを選択しました。
Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく (Informatics&IDEA)
- 作者: NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2016/04/20
- メディア: 単行本
- この商品を含むブログ (1件) を見る
評判が良くて比較的出版が新しかったのでこの本を選びました*2。スクリーンショットなども多く、手を動かしながらサービスを満遍なく学習できて面白かったです。無料枠で十分遊べます。
AWSはRailsチュートリアルにはあまり関係ないかと思っていましたが、一部ストレージサービスのS3を使う部分などがあり、学んだ知識を生かすことができました。
Rubyの学習
RailsチュートリアルではRubyの前提知識を求めていませんでしたが、さすがにHello Worldも書けない状態で特攻するのは嫌だったので、簡単に言語仕様をさらいます。
まずは公式ドキュメントを読みました。
公式ドキュメントは量が少なく、あまりにもあっさりとしているので他の資料にもあたりました。
[Ruby]他言語使用者のためのRuby入門知識まとめ - Qiita
ASCII.jp:Ruby超入門(前編)|Rubyで学ぶRuby
特にRubyで学ぶRubyは面白かったです。(Rubyで自作インタプリタを作る連載で、正直文法やイディオムの書き方を学ぶのには適していませんけど…)
Ruby on Railsチュートリアル
ここまでやった段階でRuby on Railsチュートリアルに取り掛かりました。基本的には演習問題に取り組み、erb(HTML)とCSS以外はコピペしない方針で進めました。
Twitterライクなアプリを作る中でGitの使い方からマイグレーション、PaaSへのデプロイ、テスト駆動開発などを実践的に学ぶことがでます。 思っていたよりもにWebの広範囲な知識が得られてやってよかったと思います。
またGitのコミットの粒度やコメントの書き方などは普段の開発にも活かせる部分があり、Masterブランチ一本で開発していた自分のプロジェクトを見直すきっかけにもなりました。
たくさんのことが学べる素晴らしいチュートリアルですが、それは裏を返せば非常に長大なチュートリアルであるということです。 電子書籍版のPDFに換算すると800ページ以上あるので*3、結構挫折感は強いです。個人的には勢いに任せて一気にやるといいと思います。
補足:Ruby on Railsチュートリアルのメモ
以下はチュートリアルを進めながらのTipsやエラー回避、感想です。
進めながらメモをとっているので、適当なことを言っている可能性があります。
1章
- Cloud9が推奨されているが、小回りがきいて便利だと思ったのでローカル環境を作成
- JetBrainsのIDEが使いたいとうモチベーションが大きい
- nokogiriでインストールエラーが発生
- Command Line Toolsをいれておく必要がある
2章
Viewを表示しようとしたら
ArgumentError: key must be 32 bytes
のエラーRailsはRESTfulを採用した先駆者らしい
- Webを支える技術を読んでおいてよかった感ある
3章
4章
- 言語仕様
- ここはサラッと流せそう
- Railsの拡張も結構ある
単なるRubyのコードを書くのであれば、モジュールを作成するたびに明示的にインクルードして使用するのが普通ですが、Railsでは自動的にヘルパーモジュールをインクルードしてくれるので、include行をわざわざ書く必要がありません。 つまり、このfull_titleメソッドは自動的にすべてのビューで利用できるようになっている、ということです。
- メソッドが破壊的かどうかを表現するために
!
をつけるルール、すごく良さそう 必ずしも守られているわけではなさそうだけど http://qiita.com/tadsan/items/7baab2605a4d8ac1858e
pythonのスライスとrubyのスライスは仕様が違うので注意
- [0..7]としたときに、7自体も含まれる
5章
CSSを書くのが結構めんどくさい
- 自分が普段書かないからサラサラかけなくてストレスなのかも
HTTP技術の話
これは、HTTP標準では技術的にリダイレクト後に完全なURLが要求されるためです。ただし、ほとんどのブラウザではどちらの方法でも動作します。
Webを支える技術にそんなようなことが書いてあったなあ
6章
- 名前だけ知ってたActive Recordの概念が出てきた
- SQLの操作を抽象化している
ここでRails console内で生成されるTime Stampの値がおかしいことに気付く
- デフォルトではUTCになっている。気持ちわるいので変更
http://qiita.com/norifumi-y@github/items/fbc89daa2206cd6f75d1
config.time_zone = 'Tokyo' config.active_record.default_timezone = :local
正規表現がでてきた
- 読むのがめんどくさくて、たぶんあってるだろうと思ってコピペする
- 普段から正規表現に対してはこのスタンス。良くない癖だ…。
- 読むのがめんどくさくて、たぶんあってるだろうと思ってコピペする
passwordはハッシュ化して保存する
- なぜ世の中のWebサービスはたまにパスワードを流出させてしまうのか
- 平文でパスワードを保持していないのであれば、流出は起こり得ないのではないか
- どうやらハッシュを解読しているらしい
- http://www.itmedia.co.jp/enterprise/articles/1509/11/news050.html
7章
RESTに従ってデータベースを取得したサービスを設計し始めた
- Resourceとしてデータを扱う
debugger
メソッド、とても便利。ブレイクポイントだ- POSTで送ることのできる要素を限定させる(Strong Params)
- すべての要素を送ろうとするとエラーが発生する
pluralize
- 英語を複数形にするメソッド。言われてみればめっちゃ需要ある
- configを一行変更するだけで簡単にSSL通信ができてすごい
- というよりもHerokuが簡単にSSLを無料で扱えるのが使えるのがすごい
8章
rails routes
でルーティングが表示できる- コンソールで対話的にwebアプリを作れるメリットを感じる
残念ながらヘルパーメソッドはテストから呼び出せない
- これ少しめんどくさい
9章
- XSSの対策をしなくていいの?と思いながら進めていたけど、railsが自動的にやっていたみたい
- やっぱり標準で対応するべきだよなー
- 生PHPだと明示的にescapeしないといけないし、世の中を良くするためにはデフォルトで対策したほうがよい
- 記憶トークンの使用はセッションハイジャックの対策にもなって一石二鳥
- PythonのselfとRubyのselfは似たような感じ?
署名と暗号化を同時に行う。合理的
0も1もRubyの論理値ではtrue
- if文を書くときに他言語に慣れてると罠に嵌りそう
- チェックボックスとかの分岐のテストはなかなか大変
10章
- そういえばテストでは
post
じゃなくてpatch
が使われている機会が多いことに気づいた- 冪等でない更新はPATCHを使う?
- http://d.hatena.ne.jp/tkawa/20120325/p1
has_secure_password
はオブジェクト生成時に存在性を検証する- ユーザ登録時にnilが有効にならない
log_in_as
ヘルパーがすごく強力であることがわかってきたunless @user == current_user
よりもunless current_user?(@user)
のほうがわかりやすいという説明、いまいちピンとこない- 前者のほうが何をしているか明確でいいと思う
- Python的な考え方かもしれない
- 前者のほうが何をしているか明確でいいと思う
- Cookieをユーザが手動で削除してフォームを送信する場合を考慮してテストされてて、なかなか細かい
- ブラウザはネイティブではDELETEリクエストを送信できないらしい
- 知らなかった…。
11章
- このへんでようやく
edit_account_activation_url
の意味がわかってきた- @がURLで使えないということを初めて知った
どうやってメール受信のテストをやるのかなあと思いながら読み進めていたけど、簡単にプレビューする方法がRailsで提供されているらしい。
- この仕組、テストが行いやすくするための工夫だよなあ
- これがないとTDDはしにくそう
- この仕組、テストが行いやすくするための工夫だよなあ
assert_match
めっちゃ便利テストがあるとリファクタリングしたときの安心感があって良い
- ところでコントローラからモデルに操作を移したい理論的な動機について書かれていないんじゃないか?
- 感覚としてなんとなくわかるけど
- ところでコントローラからモデルに操作を移したい理論的な動機について書かれていないんじゃないか?
本番環境でメールのテストを行うためのプラグインをHerokuで使うためにクレジットカード登録が必要
- 先延ばしにしていた登録をここで終わらせる
- Vプリカが使えるのでセキュリティ的にも安心
- 本番環境でメールがなかなか届かなくて失敗してるかと思ったけど、時間がかかっているだけだった。
12章
- この章の序盤は本当に11章とやっていることの本質は変わらないっぽい
- チュートリアルで一番難しいのは、漏れがないようにテストを書く演習な気がしてきた
- ようやくこの章でログインの管理が終わった。結構しんどかった。
13章
- PostgresQLではStringとTextではパフォーマンスの差が出ないのは初めて知った
- intとlongでパフォーマンスが変わらないといっているようなものだと思うので驚き
- Reference型よい
- 今自分は間違いなくmigrationのメリットを享受している
- 状況に応じて生のSQLが読み書きできないと処理ができない部分がまだたくさんある
- pluralizeがまた出てきた
- 中身は泥臭いルールベースのコードなのかな
if object.errors.any?
objectにするだけで抽象度が高くコードが書けて楽しい- 文字列をescapeする必要がなくても、とりあえずescapeしておく癖をつける
- 画像のファイル名にはStringを使うのか
- 全部Textにするのはだめなのか?
- この章で初めてvalidationのメソッドを自分で書くことになった
- railsの機能が豊富なのか、それともいままでの課題が基礎的なものだったのか
- たぶん両方だと思う
- railsの機能が豊富なのか、それともいままでの課題が基礎的なものだったのか
14章
- 冒頭のデータベース設計、すごく参考になる
- データベース正規化を実際のサービスに当てはめて、パフォーマンスと保守性を考慮しながら設計している
foreign_key: "follower_id"
という記述- ActiveRecordはDBを操作しているということを思い出させてくれる
- HTMLを構造的にテストしていくのは複雑で難しい
- 現実ではさらにデザイナーとバックエンドを書く人が別れているケースもあるから、もっと難しくなりそう
- RailsにおけるAjax、JSをまったく意識せずに使える
各行の末尾にセミコロン ; があることに注目してください。 これはプログラミング言語によくある文法で、古くは1950年代中ごろに開発されたALGOLまで遡ります。
;
を使わない言語をはじめに使う人達も増えてきたんだろうな…。(老害感)アプリ完成
- 長かったけどすっごく面白かった