・ Le tutoriel Rails est la 4ème édition ・ Cette étude est le 3e tour (2e tour après le chapitre 9) ・ L'auteur est un débutant qui a fait tout Progate
・ Si vous le lisez, vous ne le comprendrez pas. ・ Recherchez et résumez les termes que vous ne comprenez pas (en bas de l'article, glossaire). ・ Plongez dans ce que vous ne comprenez pas. ・ Travaillez sur tous les exercices. ・ Ne copiez pas le code autant que possible.
Chapitre 3 où le sample_app principal commence enfin. À partir de ce chapitre, j'ajouterai la BGM d'aujourd'hui pour accompagner mon apprentissage. S'il vous plaît pour un changement. La littérature ovine "était humaine"
Lorsque j'installe le fichier gem, j'obtiens immédiatement une erreur de déficit, mais si je regroupe la mise à jour et l'installe à nouveau, elle sera résolue. Et il y a une autre erreur lors du déploiement sur heroku. ** Échec de la précompilation des éléments ** est en rouge. Puisqu'il est pré-compilé, est-ce une erreur avant la compilation? Même si vous suivez le journal et vérifiez la partie où l'erreur est générée, ** NoMethodError: méthode non définie ʻaction_mailer '**? Après tout, je ne pouvais pas le savoir même après l'avoir vérifié, alors j'ai réécrit le fichier gem et le bundle l'a mis à jour, et j'ai pu le déployer en toute sécurité.
Vérifiez si Bitbucket restitue correctement la notation Markdown README (Liste 3.3) au format HTML. → Dans mon cas, c'était Github, mais il a été dessiné correctement (image omise).
Accédez à l'URL racine de l'environnement de production (Heroku) et vérifiez si le déploiement a réussi. → bonjour, monde! A été affiché.
Mémo 1: ** Colonne 3.1 Comment restaurer ** Le code généré et comment restaurer la migration sont publiés. Remarque 2: Quatre opérations HTTP de base ⇨ GET, POST, PATCH, DELETE
$ rails g controller Foo bar baz
$ rails destroy controller Foo bar baz
Le test qui est finalement venu. Au début, je ne l'ai pas compris, mais maintenant je peux le comprendre un peu. Le but est d'écrire et de confirmer d'abord le mouvement attendu, "Cela fonctionne, non ?? (Ou, cela ne fonctionne pas, non ??)". Pour écrire un test, vous devez d'abord dessiner le dessin de conception de l'application (ce qui peut être évident). Si vous écrivez «plus tard» dans la colonne 3.3, c'est uniquement pour le code dont les spécifications comportementales ne sont pas réglées ou sont susceptibles de changer à nouveau bientôt. Fondamentalement, il semble être basé sur l'écriture «d'abord». Pour plus d'informations sur le test, vous pouvez consulter le Guide de test du guide Rails. C'est un montant énorme, alors je vais l'examiner un par un. Certains types d'assertions sont également répertoriés. Je vais résumer ce qui apparaît dans ce tutoriel dans le glossaire ci-dessous l'article. Je pense que je m'en souviens mieux.
static_pages_controller_test.rb
test "should get contact" do
get static_pages_contact_url
assert_response :success
assert_select 'title', "Contact | #{@base_title}"
end
Ajoutez un contact au routage, ajoutez l'action de contact au contrôleur, créez une page de vue et entrez le Listing 3.40 pour réussir le test.
routes.rb
Rails.application.routes.draw do
get 'static_pages/home'
get 'static_pages/help'
get 'static_pages/about'
get 'static_pages/contact'
root 'application#hello'
end
static_pages_controller
def contact
end
ruby:contact.html.erb
<% provide(:title, "Contact") %>
<h1>Contact</h1>
<p>
Contact the Ruby on Rails Tutorial about the sample app at the
<a href="https://railstutorial.jp/contact">contact page</a>.
</p>
static_pages_controller_test.rb
test "should get root" do
get root_url
assert_response :success
end
2. En fait, depuis que j'ai écrit le code dans l'extrait 3.41, le test de la tâche précédente devrait déjà être vert. Dans de tels cas, il est difficile de déterminer si le test a réussi avant le changement ou s'il a réussi après le changement. Pour voir si le code du Listing 3.41 affecte les résultats du test, commentons le routage racine comme indiqué dans le Listing 3.43 et voyons s'il devient rouge (notez que la fonction de commentaire de Ruby). Sera expliqué en 4.2.1). Enfin, annulons la partie commentée (c'est-à-dire revenons à l'extrait 3.41) et assurons-nous que le test devient vert. → Les résultats des tests changeront certainement avant et après les commentaires.
-Créer une série de pages (presque) statiques qui sont à la base des applications Web. Puisqu'il n'est pas RESTful, chaque routage est défini individuellement. ・ En gros, écrivez d'abord le test. Il est important de dessiner fermement le mouvement attendu dans votre esprit. ・ Si vous maintenez le test, vous pouvez être assuré lors de la refactorisation. -Les parties communes de la vue peuvent être résumées dans /layouts/application.html.erb. -Les variations définies dans le contrôleur peuvent être utilisées dans le fichier ERB.
Ensuite, passons au chapitre 4
⇨ Allez au chapitre 4! ⇦ Cliquez ici pour le chapitre 2 Cliquez ici pour les conditions préalables et le statut de l'auteur pour l'apprentissage
· Compiler Traduire de l'humain à la machine. Il semble que le programme que nous avons écrit doit être converti pour pouvoir être compris car il ne peut pas être compris directement du côté ordinateur.
・ Refactoring Organisez la structure interne du code source sans changer le comportement vu de l'extérieur du programme. Il est important de tester à chaque refactorisation.
・ SEO (optimisation des moteurs de recherche) Mesures SEO = Affichage en haut des résultats de recherche. Important dans le marketing Web.
・ Assert_response Affirmez que la réponse a un code d'état spécifique. Si vous spécifiez: succès, vous avez spécifié le code d'état 200-299. (Liste des codes d'état)
・ Assert_select Vérifie si un élément donné répond aux critères. Ce pourrait être une affirmation commode. Il existe deux formats. Pour plus d'informations, consultez le Guide des rails. ](Https://railsguides.jp/testing.html)
Recommended Posts