Railsチュートリアル6章 前半まとめ と見せかけて...
その前に、
と て も 難 し い
ので、正直薄っぺらいアウトプットをするよりは何度か見てからひとつづつ咀嚼してたいので、先の章には進みますがアウトプットは次の機会にしようと思います。
モデルの生成、Userの作成・検索・更新、バリデーション 、正規表現、一意性の検証
をやったのですが、バリデーションのテストコード辺りから「？？」となり、正規表現で「？？？」となりました。
その前や一意性についてはなんとなく、なんとなくですが理解はできました。
なので、こちらはリベンジさせてください。後半も含めてです。
メールアドレスの有効性をテストする時のコードとか本当にちんぷんかんぷんです。
とりあえず後半を終えたら、7章に進みます。
先に進むのが目的なのか、理解することが目的なのかと言われたら両方なのですが
マーク・ザッカーバーグの言葉
「完璧であることより、まず終わらせることが重要だ」
を自分に言い聞かせてとりあえず完遂します。
Railsチュートリアル5章 後半まとめ
さあいこか！！！！！！
ルーティング、名前付きルート、統合テストを学ぶ。
■ポイント
・3章の復習だが、rails testはこまめに行う。
・名前付きルート
<%= link_to "About", about_path %>
記法がまた新しくなったので、こっちを覚えていく。
・リファクタリングの根底
コードもデザインだと思って縦と横の軸を揃えること。
それにより、コードを見たときの理解度スピードが変わり、タイポも気付きやすくなる。
自分のためもあるが、チームのため、人のためにそういうことを意識していく。
・統合テスト（Integration Test）
人間の代わりにブラウザを立ち上げてテストをしてもらう。
アプリケーションの動作を端から端までシミュレートしてテストをしてくれる。
$ rails g integration_test site_layout
(結果）
invoke test_unit
create test/integration/site_layout_test_rb
ここに色々書いていく。
test "layout links" do get root_path assert_template 'static_pages/home' assert_select "a[href=?]", root_path, count: 2 assert_select "a[href=?]", help_path assert_select "a[href=?]", about_path assert_select "a[href=?]", contact_path get contact_path assert_select "title", full_title("Contact") end
このテストコードはかけるようになることが理想だが、まず読めるようになる。
読めるようになるためになぜこのコードを書くのかなど根本を理解する。
$ rails test: integrtion
インテグレーションだけテストできる。
最後、herokuにデプロイまでして終了。
（記述時間： 5分2秒）
■まとめ
とにかく新しい記法に焦らないこと。
link_toを書くときはシングルクォーテーションを誤って付けないようにしっかり確認！！（チュートリアル中2回やった）
あとは、やはりテストが肝心で後々エラーが出て時間を食ったりしないように全体を通して効率よく遂行させることを念頭に置いていこうと思う。
Railsチュートリアル5章 前半まとめ
いよいよフロント部分の実装へ
基本的なレイアウトを作成
ーBootstralを使ったデザイン
ーPartialを使ったリファクタリング
ーAsset Pipeline機能、Sassについて紹介
■ポイント
・記法メモ
<%= link_to"sample app", '#', id: "logo" %>
（訳）
<a id = 'logo' href = '#' >sample app</a>
<a class='' ">の場合も同じ記法になる。
・画像の場合
<%= link_to image_tag("rails.svg", alt: "Rails logo", width: "200px"),
"https://rb.org/" %>
画像の場所
画像がなかったらロゴを表示
幅
画像のリンク
・Asset NotFoundエラーはHTML/CSSdで何かが起こっている
・Bootstrap導入メモ
gem 'bootstrap-sass', '3.4.1'
bundle install
SCSSファイルを作成
@import "bootstrap";
@import "bootstrap";
これをSCSSファイルへ追加
・サイトの評価には機能もそうだが、デザインも大きく関わってくる。
とにかくまずはタイポグラフィーを意識することを大事にしろとのこと。（フォント、見栄え）
・Partial
リファクタリングの一環。
用いることでよりDRYでコードになる。
Partialの場合は、アンダーバーつけよう。
（例）app/views/layouts/_shim.html.erb
・SassとAsset Pipeline
Sass ・・・CSSの拡張言語で、共通パターンがあればネストできたり、冗長なコードを短くできたり、パッケージングをして、複数利用できるので超便利。(@includeなど)
Asset Pipeline ・・・CSS/JavaScript/Imageなどを管理する機能
1.アセットディレクトリ
→静的ファイルを目的別に分類
2.マニフェストファイル
→1つのファイルにまとめる方法をRailsに指示
3.プリプロセッサエンジン
→指示に従ってブラウザに配信できるように結合
記述時間：18分47秒
■まとめ
色々と細かいところは出てきましたが、一週目なので全てをインプットしようとはしてません。
とりあえず大枠は理解してるのでどんどん進みます！
しかしどれも時期に理解できる、コードが書けないといけないものなので着実に段階を踏んで行きます。
ひたすらくん（Ruby勉強中）
引き続きRubyの着手に入り、足りない知識をインプットしてました。
Progate、ドットインストールが王道だと思っていましたが、paizaがめちゃくちゃいいことに気がつきました。
これ本当に最高の学習ツールだと思います！
Progateとドットインストールにない、痒い部分に手が届いている感じ。
しかもプランが色々あって長期プランなら上記サイトの月額よりお得。
勢いで半年間プラン加入しました。 なんと4400円也！
しかも何がいいかって、動画学習なのでやっぱり声があるわけです。
ドットインストールも有料プランに加入すれば、女性ボイスを選べたりしますよね。ただ、なんというか台本を読んでいる感じが頭に入ってきづらいというか。。
そこらへんは人にもよるとは思いますが、paizaのあの感じ好きです！
言葉では表現しづらいので、是非お試しください。笑
あと突出している部分は、講座一項目ごとにちゃんと演習問題が用意されていること。
Progateって三項目やって、じゃあ演習してみよう！みたいな感じだけどpaizaは一項目ごとに演習できるので、インプットして即アウトプットが可能なんですね。最高です。
というわけでRubyの勉強法が確立できたので、並行してRailsチュートリアルも再開します。
とにかく努力。俺は負けない！
Railsチュートリアル3章 後半まとめ
どうも、ベイビーステップ大久保です。
必ず毎日半章はやろうと思っています。（他の勉強もしていますが必ず時間作ってやる、やるんだ！）
では3章後半まとめ！
静的なページの生成、テスト駆動開発、少しだけ動的なページ
自分がわかるようにアウトプットをさせてもらいますね、すみません。見ている方なんていないと思いますがすみません！こればっかりは自己満足です。
■ポイント
・コントローラー内でコードの書いていないアクションや、引数の渡されていないyieldなどはどういうページを描写するかというと、「デフォルト」が走る。
例えば、
def home
end
のアクションがあった場合、/homeにアクセスしたときに表示されるURLはhome.html.erbであり、中身もテンプレコードが表示される。
やってきました。これは言葉で聞いていましたが、実際にするのは初めて。
コードを書きつつテストをさせてくれたので、理解が深まった。
けれど、初心に帰りテストって何？そもそもテストってする意味あるの？と思った為、ぐぐりました。
チュートリアルではそこらへんの説明は特になかったので。
〜テストとは〜
Railsにおいてのテストとは、制作したアプリケーションが想定通りの動きをするかどうかを確認する為のものです。これは、テストの為のファイルに期待する動作を記述し、テスト実行コマンドを使用するという方法で行われます。
そして、制作したアプリが、その記述通りに動作する仕様になっていればテストは成功となります。逆に、コードにミスがあり期待する動作が実現しない仕様になっていれば、テストは失敗という結果が返ってきます。
〜必要性〜
開発環境やステージング環境などで、実際にアプリを動かして画面で確認を行えば良いという風に、テストの必要性が感じられない方がいるかもしれません。もちろん、デザイン面などの崩れも確認する必要があるので画面での確認も必要です。
ですが、この方法だけでは、機能面の確認を行う場合一つ一つの動かして確認しなければならないので時間がかかってしまいます。
その点テストは、ファイル内に期待する動作がまとめて書かれていて、テスト実行のコマンド一つでこれらの動作確認が行えるので、制作スピードをあげる事が出来ます。
また、テストを実行して失敗した場合、どの動作がうまくいかないのかを知ることが出来ます。これにより、コードミスなどの特定を容易に行う事が出来るのです。
冗長的ですが、自分であとで見返したりする時に具体的に書いてあると非常に助かるので許してくだちい。
つまり開発の現場においては、必要不可欠ということですね。
Railsチュートリアルでは、積極的にテストを行っていくそうなのでいっぱい書いて慣れたいと思います！
・新しい言葉 TDD
テスト駆動開発のことをTDDという。
Test-Driven Development: 略してTDD。
実装したい機能のプログラムよりもテストコードを先に書く為、初めはテストに失敗するが、プログラムの実装と修正を短いサイクルで何度も繰り返してバグをなくし、正しく動作するコードが書けたらリファクタリングをする。
・冗長さがある物をDRYな仕上がりに。
provideやyieldを使って、コードを短くまとめる方法を学んだ。
チーム開発をする時は、いろんな人がコードを見るので見やすくすることで効率化にも繋がっていくと思いました。
1.テスト作成
2.とりあえずテストを通す
3.冗長さをERBで共通化
という流れでテストを通しながら、コードをまとめました。
・そして最後にしっかりとでデプロイまで！
だんだん手順やコマンドを覚えてきました。マージも行った。マージした後もテストをしていたので、ここは本当に慎重〜〜〜にやるべきところだなと感じました。
（記述時間: 13:33）
アウトプットまでを考えると大事なところはしっかりメモをとるのでいいですね！時間を測ってみましたが、紙に書いてあることを文章にしながらタイピングするだけなので時間ももうちょっと短縮できるかな。
でも紙→タイピングとすることで理解度を深められる！
次の4章はRubyについてなので、理解を深めるいいきっかけ！ベイビーステップで自分のものにしていきます。継続は力なり。継続は力なり。
まだまだ基礎だけど、基礎を固めないと応用がペラペラになってしまうのでしっかりやっていこう！
アウトプットの仕方について模索中
個人的には自分のためのアウトプットなので、スタイルとかも当てずにやってますが
色とかちゃんと使っていった方がいいのだろうか・・・？
アウトプットはメモや記憶を元にひたすら頭で考えて書き殴りたいと思ってしまう・・・。
もちろんQiitaとかであれば見易さも考えなければいけないと思うけど、完全に自己満足でアウトプットの機会を作るために始めたので気にしてません。笑
あとアウトプットも時間決めて書き上げた方がいいのかな。効率を考えるならそっちの方が良さそう。
おそらく実務に入ったらものすごく早いスピードで物事が進んでいくと思うので、スピード感には慣れておきたいところ！
今後は時間計測しますかー！いいですね！それやりましょう！
あとは、前後半で分けるから記事が多くなってしまうけど、それもまた一興ということで。。
とりあえず色々と探り探りやっていきます！アウトプットを制するものはプログラミングを制する！（はず！笑）
