Today I found a story on the Internet about how someone named James Fend learned Ruby on Rails for 12 weeks. Below you can read a relatively accurate translation of this story, and hopefully be inspired to explore this wonderful framework (and wonderful language).

Before I begin, I'd like to introduce Josh Crews (http://joshcrews.com) and thank him for convincing me to start learning Ruby on Rails; without him, his help, and without the hours he spent being my mentor, I would not be writing this today. Thank you.

On January 23rd, I launched my dream idea, Freelancify.com. Exactly 12 weeks ago, I was a tech entrepreneur spending thousands of dollars to create a decent MVP (minimum viable product) because I lacked knowledge. One of the reasons (I thought at the time) was that the training was too difficult for me or would take an inordinately long time. I thought (like many others) that programmers are (and some are) born with a set of magical problem-solving and math skills that make them programming geniuses. And exactly 12 weeks ago I made the best decision I've made in a long, really long time.. No longer will any of my ideas remain anything more than an idea. Now I have the opportunity to launch production versions, spending money only on hosting and putting in some effort. Today, this skill set is akin to pulling a bunch of tractors during the California Gold Rush while everyone else was using simple shovels. I suggest everyone learn to write code. Here I would like to add a clarification: earlier, I called the post “How I learned Rails in 8 weeks”, however, to be precise, given the launch date, it turns out to be 12 weeks. However, within 8 weeks I felt I knew enough, and the next four weeks were spent more on putting the knowledge I'd gained to work rather than learning.

What skills did I have before I started learning Rails?

I was a web designer with knowledge of HTML and CSS and mainly focused on UI and UX design. The hardest thing I've done with actual code (not counting HTML) is being able to customize Wordpress. In short, I had absolutely no idea what an MVC framework was or how databases work in general. The design, layout and HTML for Freelancify were created by me in two weeks in June 2011.

Why did I decide to study?

Going back to June 2011, when the layout was ready, I began searching for a coder who would make the layout functional. The layout was almost ready: I ​​had text fields, drop-down menus, forms, buttons, links leading to where needed, and so on. I found a developer, and, in a nutshell, the guy didn’t suit me. I was left with a ton of debt and no product even close to being completed. So I contacted Josh Krius (I met him at a Ruby on Rails meetup he organized in Nashville) and met with him to see if I could make something of what I had left as a developer . Unfortunately, fixing and modifying the code would take no less time than developing it from scratch by a competent programmer. I became disheartened, realizing that I could not afford to spend thousands of dollars again on development from scratch. And then Josh said... “ Why don't you just learn how to handle Ruby on Rails, this project would be a great way" and then " I can even meet with you twice a week and help you with your studies" I spent the whole night thinking about it. My options were: find a comfortable job and pay the bills OR risk everything to learn Rails and ultimately feast on the best ramen Italy has to offer. I decided. I called Josh the next morning. I put everything. I allocated money from the remaining savings and divided it over three months (for a single guy living alone and without children, one thousand dollars per month is enough). Time to get to work, I am now a full time apprentice. Keeping in mind that Google search, Stackoverflow, IRC #RubyOnRails and the Rails community will have my back when I get stuck, I'm sure there will be plenty of them.

My next three months - Mission: Get an MVP, get enough to work, but not “suck-enough” to leave a terrible first impression.

Weeks 1 - 3

It was probably the biggest learning curve, but I did NOT give up.

Walls are made for people who don't really want to leave them.

Setting up a working Rails environment for a complete newbie can be incredibly annoying. Tip #1: Get a Mac. Tip #2: Use Homebrew, RVM, Git and Heroku (that's really all you need to get started). I spent a couple of days installing, then uninstalled everything and installed again. Just repeat it a few times and you will get used to using it. command line terminal (console) and understand why things work the way they do. Then, the first thing I took up was TryRuby, Rails for Zombies, and Michael Hartle's Rails Tutorial. Don't worry about understanding the material 120%, it won't happen until you actually start studying. I finished the Rails Tutorial and created this Twitter-like app in about a week, without really understanding what I had done. Later, as I progressed, I began to realize that everything was starting to make sense.

Weeks 3 - 6

With a Twitter app built using the Rails Tutorial, I gained some confidence. Management didn't make me a developer, but now I know general steps in creating applications, from creating the application itself to installing it on Heroku. Everything that happened in between remained blurry. How can I REALLY start studying now? Working on a real project that means something to me. Josh and I decided that I should freely work on Freelancify and see what I could do. The first thing I did was move all the HTML from the framework and organize it into views and partials files. I have created scaffolded template platforms for Users and Projects. Then I started learning my first real gem, Devise. Then, the ability to have relationships, for example, each User will have a portfolio. But Users can have multiple portfolios, while each portfolio can only belong to one User. Once you understand how relationships between models work and how to call/display things that belong to something else, life will become much easier. If you get stuck on a part and can't move, skip it, chances are that while you're developing another feature, you'll also figure out how to implement what you missed.

Weeks 6 - 9

Step by step, I continued to learn, copying and repeating. I would make some things work, and then - bam - and I would hit a wall and have absolutely no idea what to do next. Whether going on Stackoverflow, IRC chat #RubyOnRails, RailsCasts, or tugging at Josh, I eventually figured out how to proceed. Do the same thing over and over again and you'll get the hang of it pretty quickly. Spending annoying hours testing someone's answer on Stackoverflow only to realize it doesn't work is actually useful. You understand what not to do. And when you find the answer you will begin to understand WHY the latter didn't work. It was around this time that I began to realize how big the picture was of things and to truly understand WHY everything works exactly the way it works. I felt like an idiot and went back and refactored the code I had written earlier to make it more efficient. And at some point I reached a stage where everything started to fall into place.

Weeks 9 - 12

I was in incredible energy mode getting Freelancify to the launch stage. At this stage I felt as if I was flying, putting the functions into action. The last week was spent debugging various bugs and blunders. This Monday I launched the site. But I'm still far from completing my studies... That's it. I have omitted (in the name of brevity of the post) small details and technical points. However, feel free to ask questions in the comments, I will definitely try to answer. James Fend.

P.S. - While it helped a lot to have a mentor I could meet with, you can definitely learn Rails without one. Or try to find yourself such a person, many Rails developers love to contribute to the community. Look for local conferences and meetups.

This entry is already more than two years old (published on January 27, 2012), but, nevertheless, it has not lost its relevance. During this time, James Fend managed to sell Freelancify and invest in a new startup, he left a note about this on February 27, 2013. I believe that this article is an excellent example of how a person can achieve his goal. All you have to do is start. :)

This guide covers installing and running Ruby on Rails.

After reading it, you will learn:

• How to install Rails, create a new Rails application, and attach your application to a database.
• The general structure of a Rails application.
• Basic principles of MVC (Model, View Controller) and RESTful based design.
• How to quickly generate initial code for a Rails application.

Assumptions in this manual

This tutorial is aimed at beginners who want to start a Rails application from scratch. It does not assume that you have worked with Rails before.

Rails is a web development framework written in the Ruby programming language. If you don't have experience with Ruby, you may find it difficult to jump right into learning Rails. There are several good English-language resources dedicated to learning Ruby, for example:

Please note that some of the resources, while still great, still cover older versions of Ruby such as 1.6, and especially 1.8, and do not include some of the syntax you'll see in everyday Rails development.

What is Rails?

Rails is a web development framework written in the Ruby programming language. It is designed to make programming web applications easier by making a number of assumptions about what each developer needs to create a new project. It allows you to write less code during programming compared to other languages ​​and frameworks. Professional Rails developers also note that it makes developing web applications more fun =)

Rails is a wayward piece of software. It makes the assumption that there is a "better" way to do something, and it is designed in such a way that it encourages that way - and in some cases even discourages alternatives. If you learn "The Rails Way" you may discover a significant increase in your productivity. If you persist in bringing old habits from other languages ​​into Rails development, and try to use patterns learned elsewhere, you will have a less happy development experience.

The Rails philosophy includes two important guiding principles:

• Don't Repeat Yourself: DRY is a software development principle that states that “Every piece of information should have a single, non-redundant, authoritative representation in the system.” Don't write the same information over and over again, the code will be easier to maintain and will be more extensible and less buggy.
• Convention Over Configuration: Rails has opinions on the best ways do a lot of things in a web application, and have these conventions set by default, rather than forcing you to tinker with numerous configuration files.

Creating a New Rails Project

The best way to use this guide is to go through it step by step. All steps are essential to running the example application, and no additional code or steps are required.

By following this tutorial, you will create a Rails project called blog, a very simple web blog. Before we start creating an application, we need to make sure that Rails itself is installed.

The following examples use $ to indicate a terminal input line in UNIX-like operating systems ah, although it may be configured differently. If you are using Windows, the line will look something like c:\source_code>

3.1. Installing Rails

Before installing Rails, you must ensure that the required pre-dependencies are installed on your system. These include Ruby and SQLite3.

Open command line applications. On macOS, open Terminal.app, on Windows, select "Run" from the Start menu and write "cmd.exe". Any commands starting with a dollar sign $ must be run on the command line. Make sure you have the current version of Ruby installed:

$ ruby ​​-v ruby ​​2.5.0

Rails requires Ruby version 2.5.0 or later to be installed. If the version number is less than this, you will need to install a new copy of Ruby.

To quickly install Ruby and Ruby on Rails on a system, Windows users can use Rails Installer. Additional installation methods for most operating systems can be seen at ruby-lang.org.

If you are working on Windows, you need to install the Ruby Installer Development Kit.

You will also need an SQLite3 database installation.

Many popular UNIX-like OSes ship with a reasonable version of SQLite3. On Windows, if you installed Rails using the Rails Installer, you already have SQLite installed. Other users may refer to the SQLite3 website for installation instructions. Check that it is installed correctly and is contained in your PATH:

$sqlite3 --version

The program must report its version.

To install Rails, use the gem install command provided by RubyGems:

$ gem install rails

To check that everything is installed correctly, you need to do the following:

$rails --version

If it says something like "Rails 6.0.0", you can continue.

3.2. Creating a Blog Application

Rails comes with a number of scripts, called generators, designed to make a developer's life easier by generating everything needed to get started on a specific task. One of them is the New Application Generator, which gives you the framework of a Rails application so you don't have to write it yourself.

To use this generator, open a terminal, go to a folder where you have permission to create files and write:

$rails new blog

This will create a Rails application named Blog in the blog directory and install the gems whose dependencies are mentioned in the Gemfile when using bundle install .

At using Windows Subsystem for Linux, there are some restrictions on messages file system, indicating that the spring and listen gems should be disabled, which can be done by running rails new blog --skip-spring --skip-listen .

You can see all the possible command line options that the Rails application builder accepts by running rails new -h .

Once you have created the blog application, go to its folder:

The blog directory contains several automatically generated files and folders that define the structure of a Rails application. Most of the work in this tutorial will take place in the app folder, but for now let's go over the functions of each folder that Rails creates in a new application by default:

File/Folder	Purpose
app/	Contains controllers, models, views, helpers, mailers, channels, jobs and assets of your application. We'll look at this folder in more detail next.
bin/	Contains Rails scripts that start your application, and the directory can also contain other scripts that you use to configure, update, deploy, or run.
config/	Route configurations, your application database, etc. This is covered in more detail in Configuring Rails Applications
config.ru	Rack configuration for the Rack-based servers used to run the application. For more information about Rack, visit the Rack website.
db/	Contains your current database schema as well as database migrations.
Gemfile Gemfile.lock	These files allow you to specify which gem dependencies your Rails application needs. These files are used by the Bundler gem. For more information about Bundler, visit the Bundler website.
lib/	External modules for your application.
log/	Application log files.
package.json	This file allows you to specify which npm dependencies are required for your Rails application. This file is used by Yarn. For more information about Yarn, visit the Yarn website.
public/	The only folder that is accessible from the outside as is. Contains static files and compiled assets.
Rakefile	This file finds and loads tasks that can be run on the command line. A specific task is available in all Rails components. Instead of changing the Rakefile, you can add your own tasks by adding files to the application's lib/tasks directory.
README.md	This is an introductory guide to your application. It should be edited to tell others what your application does, how to configure it, etc.
storage/	Active Storage files for the Disk service. This is covered in the Active Storage Overview guide.
test/	Unit tests, fixtures and other testing apparatus. This is covered in the Testing Rails Applications guide.
tmp/	Temporary files (such as cache and pid files)
vendor/	Place for third party code. In a typical Rails application, it includes external gems.
.gitignore	This file tells git which files (explicitly or by design) it should ignore. For more information on ignoring files, see GitHub - Ignoring files.
.ruby-version	This file contains the default version of Ruby.

Hello Rails!

First, let's display some text on the screen. To do this, you need a running server for your Rails application.

4.1. Starting the web server

In fact, you already have a functional Rails application. To be sure, you need to run a web server on your machine. This can be done by running the following command from the blog directory:

If you are using Windows, you should pass scripts from the bin folder directly to the Ruby interpreter, i.e. ruby ​​bin\rails server .

Compressing JavaScript assets requires a JavaScript runtime on your system, and not having one will result in an execjs error during asset compression. Typically, macOS and Windows come with a JavaScript runtime installed. therubyrhino is the recommended runtime for JRuby users and is added to the Gemfile if the application is generated under JRuby. You can learn all about the supported runtimes in ExecJS

This will launch Puma, a web server distributed with Rails by default. To see the application in action, open a browser window and go to http://localhost:3000. You should see the default Rails info page:

To stop the web server, press Ctrl+C in the terminal where it is running. To verify that the server has been stopped, you should see the command line cursor again. For most UNIX-like systems, including macOS, this will be the dollar sign $. In development mode, Rails generally does not require the server to be stopped; all changes you make to files are automatically picked up by the server.

The Welcome Aboard page is a kind of test for a new Rails application: it shows that your programs are configured correctly enough to display the page.

4.2. Say hi to Rails

For Rails to say "Hello", you need to create at least controller And view(performance).

The purpose of the controller is to receive specific requests to the application. Routing decides which controller will receive which requests. There is often more than one route to each controller, and different routes may be handled differently action. The purpose of each action is to collect information to provide it to the view.

The purpose of the view is to display this information in a human-readable format. An important distinction to note is that the place where information is collected is controller, not a view. The view should only display this information. By default, view templates are written in a language called eRuby (Embedded Ruby), which is converted by a Rails request loop before being sent to the user.

To create a new controller, you need to run the "controller" generator and tell it that you want a controller called "Welcome" with an action called "index", like this:

$ rails generate controller Welcome index

Rails will create several files and a route.

Create app/controllers/welcome_controller.rb route get "welcome/index" invoke erb create app/views/welcome create app/views/welcome/index.html.erb invoke test_unit create test/controllers/welcome_controller_test.rb invoke helper create app/ helpers/welcome_helper.rb invoke test_unit invoke assets invoke scss create app/assets/stylesheets/welcome.scss

The most important of them are, of course, the controller, located in app/controllers/welcome_controller.rb, and the view, located in app/views/welcome/index.html.erb.

Open the file app/views/welcome/index.html.erb in a text editor. Remove all existing code in the file and replace it with the following line of code:

If you submit the form again, you will see something like the following:

"First Article!", "text"=>"This is my first article.") permitted: false>

Now this action displays the parameters for the article that came from the form. However, it is still useless. Yes, you see the parameters, but you don't actually do anything with them.

5.4. Creating an Article Model

Models in Rails use a singular name, and their corresponding table in the database uses a plural name. Rails provides a model generator that most Rails developers use to create new models. To create a new model, run this command in your terminal:

$ rails generate model Article title:string text:text

With this command we tell Rails that we want an Article model with the attribute title string type and attribute text text type. These attributes will automatically be added to the articles table and bound to the Article model.

Rails will respond by creating a series of files. Now we are only interested in app/models/article.rb and db/migrate/20140120191729_create_articles.rb (your name may be slightly different). The latter is responsible for creating the database structure, so we will look at it next.

Active Record is smart enough to automatically associate column names with model attributes, which means that inside Rails models there is no need to declare attributes, Active Record will do it automatically.

5.5. Starting a migration

As you have already seen, rails generate model created the file database migration in the db/migrate directory. Migrations is a Ruby class designed to make it easy to create and modify database tables. Rails uses rake commands to run migrations, and it is possible to undo a migration after it has been applied to your database. The migration file name includes a timestamp to ensure that they are executed in the order in which they were created.

If you look in the file db/migrate/YYYYMMDDHHMMSS_create_articles.rb (remember, your file has a slightly different name), this is what you will find there:

Class CreateArticles< ActiveRecord::Migration def change create_table:articles do |t| t.string:title t.text:text t.timestamps end end end

This migration creates a change method that is called when this migration runs. The actions defined in this migration are also reversible, which means that Rails knows how to undo the changes made by this migration in case you decide to undo them later. When you run this migration it will create an articles table with a string column and a text column. It will also create two timestamp fields to track when the article was created and updated.

Now we need to use the rails command to start the migration:

$ rails db:migrate

Rails will run this migration command and report that it has created the Articles table.

CreateArticles: migrating =============================================== === -- create_table(:articles) -> 0.0019s == CreateArticles: migrated (0.0020s) =========================== ==============

Since you are running in the development environment by default, this command will be applied to the database defined in the development section of your config/database.yml file. If you want to perform migrations in another environment, such as production, you must explicitly pass it when calling the command: rails db:migrate RAILS_ENV=production .

5.6. Saving data in the controller

Back to the ArticlesController, we need to change the create action to use the new Article model to save data to the database. Open app/controllers/articles_controller.rb and change the create action to look like this:

Def create @article = Article.new(params[:article]) @article.save redirect_to @article end

Here's what happens here: Each Rails model can be initialized with the appropriate attributes, which will be automatically bound to the corresponding database columns. In the first line we do just that (remember that params[:article] contains the attributes we are interested in). @article.save is then responsible for saving the model to the database. Finally, we redirect the user to the show action, which we will define later.

You may be wondering why the A in Article.new is capitalized when all the other article links in this guide are capitalized. In this context, we are referring to a class called Article, which is defined in app/models/article.rb. Class names in Ruby must begin with a capital letter.

Now that there are validations, calling @article.save on an invalid article will return false . If you open app/controllers/articles_controller.rb again, you'll see that we're not checking the result of the @article.save call in the create action. If @article.save fails in this situation, we need to show the form to the user again. To do this, replace the new and create actions in app/controllers/articles_controller.rb with these:

Def new @article = Article.new end def create @article = Article.new(article_params) if @article.save redirect_to @article else render "new" end end private def article_params params.require(:article).permit(:title , :text) end

The new action now creates a new instance variable called @article , and you'll see why in a couple of paragraphs.

Note that in the create action we used render instead of redirect_to when save returns false. The render method is used to ensure that the @article object is passed back to the new template when it is rendered. This rendering is done within the same request as the form submission, while redirect_to tells the browser to make a different request.

5.11. Article Updates

We've expanded on the "CR" part of CRUD. Now let's focus on the "U" part, updating articles.

The first step is to add an edit action to the ArticlesController, typically between the new and create actions, as shown.

Def new @article = Article.new end def edit @article = Article.find(params[:id]) end def create @article = Article.new(article_params) if @article.save redirect_to @article else render "new" end end

The view will contain a form similar to the one we used when creating new articles. Create a file called app/views/articles/edit.html.erb and add the following to it:

Editing article

<%= form_with(model: @article, local: true) do |form| %> <% if @article.errors.any? %> <% end %>

<%= form.label:title %>
<%= form.text_field:title %>

<%= form.label:text %>
<%= form.text_area:text %>

<%= form.submit %>

<% end %> <%= link_to "Back", articles_path %>

Right now we're pointing the form to an update action, which hasn't been defined yet, but we'll do that soon.

Passing the article object to the form_with method will automatically set the URL to submit the edited article form. This option tells Rails that we want this form to be submitted using PATCH , an HTTP method that is expected to be used for updates resources in accordance with the REST protocol.

Then you need to create an update action in app/controllers/articles_controller.rb . Add it between the create action and the private method:

Def create @article = Article.new(article_params) if @article.save redirect_to @article else render "new" end end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render "edit" end end private def article_params params.require(:article).permit(:title, :text) end

The new method, update , is used when you want to update a record that already exists, and it takes a hash containing the attributes you want to update. As before, if there is an error updating the article, we want to show the form to the user again.

We reused the article_params method that we defined earlier for the create action.

It is not necessary to pass all attributes to update . For example, if @article.update(title: "A new title") was called, Rails will update only the title attribute, leaving all other attributes untouched.

<% @articles.each do |article| %> <% end %>

Title	Text
<%= article.title %>	<%= article.text %>	<%= link_to "Show", article_path(article) %>	<%= link_to "Edit", edit_article_path(article) %>

And we’ll also add app/views/articles/show.html.erb to the template so that the “Edit” link is also on the article page. Add the following at the end of the template:

... <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>

And this is what our application looks like now:

5.12. Using partials to clean up repetition in views

Our edit page is very similar to the new page, in fact they use the same code to display the form. Let's remove this duplication by using a view partial. By convention, partial files begin with an underscore.

Create a new file app/views/articles/_form.html.erb with the following content:

<%= form_with model: @article, local: true do |form| %> <% if @article.errors.any? %>

<% end %>

<%= form.label:title %>
<%= form.text_field:title %>

<%= form.label:text %>
<%= form.text_area:text %>

<%= form.submit %>

<% end %>

Let's now update the app/views/articles/new.html.erb view to use this new partial by rewriting it completely:

New article

<%= render "form" %> <%= link_to "Back", articles_path %>

And the same for the view app/views/articles/edit.html.erb:

Edit article

<%= render "form" %> <%= link_to "Back", articles_path %>

5.13. Deleting articles

Now we are ready to cover part "D" of CRUD, deleting from the database. Following the REST convention, the route to remove articles in the rails routes output is as follows:

DELETE /articles/:id(.:format) articles#destroy

The delete routing method should be used for routes that destroy resources. If it were left as a normal get route, it would be possible to create the following malicious URLs:

look at this cat!

We use the delete method to destroy resources, and this route is associated with the destroy action in app/controllers/articles_controller.rb, which does not yet exist. The destroy method is usually the last CRUD action in a controller, and like other public CRUD actions, it must be placed before any private or protected methods. Let's add it:

Def destroy @article = Article.find(params[:id]) @article.destroy redirect_to articles_path end

The entire ArticlesController in the app/controllers/articles_controller.rb file should now look like this:

Class ArticlesController< ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new @article = Article.new end def edit @article = Article.find(params[:id]) end def create @article = Article.new(article_params) if @article.save redirect_to @article else render "new" end end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render "edit" end end def destroy @article = Article.find(params[:id]) @article.destroy redirect_to articles_path end private def article_params params.require(:article).permit(:title, :text) end end

You can call destroy on Active Record objects when you want to remove them from the database. Note that we don't need to add a view for this action since we are redirecting to the index action.

Listing Articles

<%= link_to "New article", new_article_path %> <% @articles.each do |article| %> <% end %>

Title	Text
<%= article.title %>	<%= article.text %>	<%= link_to "Show", article_path(article) %>	<%= link_to "Edit", edit_article_path(article) %>	<%= link_to "Destroy", article_path(article), method: :delete, data: { confirm: "Are you sure?" } %>

Here we use link_to in a different way. We pass the named route as the second argument, and the options as another argument. The method: :delete and data: ( confirm: "Are you sure?" ) options are used as html5 attributes, so when a link is clicked, Rails will first show the user a confirmation dialog and then send the link using the delete method. This is done using the rails-ujs JavaScript file, which is automatically included in the application layout (app/views/layouts/application.html.erb) when the application is generated. Without this file, the confirmation dialog will not be shown.

Congratulations, you can now create, view all and individually, update and destroy articles.

Adding a second model

It's time to add a second model to the application. The second model will process comments on articles.

6.1. Generating the model

We intend to use the same generator that we used earlier when creating the Article model. This time we will create a Comment model containing a link to the article. Run the following command in a terminal:

$ rails generate model Comment commenter:string body:text article:references

This command generates four files:

First let's take a look at app/models/comment.rb:

Class Comment< ApplicationRecord belongs_to:article end

This is very similar to the Article model we saw earlier. The difference is in the belongs_to:article line, which sets connection Active Record. You'll learn about connections in the next section of the guide.

The keyword (:references) used in the bash command is a special data type for models. He creates new column in your database with the name of the represented model with an appended _id that can contain numeric values. To better understand, analyze the db/schema.rb file after performing the migration.

In addition to the model, Rails also made a migration to create the corresponding database table:

Class CreateComments< ActiveRecord::Migration def change create_table:comments do |t| t.string:commenter t.text:body t.references:article, null: false, foreign_key: true t.timestamps end end end

The t.references line creates a numeric column named article_id , an index on it, and a foreign key constraint pointing to the id column of the articles table. Next, we start the migration:

$ rails db:migrate

Rails is smart enough to only run migrations that haven't already been run on the current database, in our case you'll see:

CreateComments: migrating =============================================== == -- create_table(:comments) -> 0.0115s == CreateComments: migrated (0.0119s) ============================ ============

6.2. Connecting models

Active Record relationships allow you to easily declare relationships between two models. In the case of comments and articles, you could describe the relationship as follows:

• Each comment belongs to one article.
• One article can have many comments.

In fact, it's very close to the syntax that Rails uses to declare this connection. You've already seen the line of code in the Comment model (app/models/comment.rb) that makes each comment belong to an article:

Class Comment< ApplicationRecord belongs_to:article end

You need to edit app/models/article.rb to add the other side of the link:

Class Article< ApplicationRecord has_many:comments validates:title, presence: true, length: { minimum: 5 } [...] end

These two announcements automatically make a large number of possibilities available. For example, if you have an @article instance variable containing an article, you can get all the comments belonging to that article in an array by calling @article.comments .

6.3. Adding a route for comments

As with the welcome controller, we need to add a route so that Rails knows which address we want to go to in order to see the comments. Open the config/routes.rb file again and edit it as follows:

Resources:articles do resources:comments end

This will create comments like nested resource in articles. This is the other side of capturing the hierarchical relationships that exist between articles and comments.

6.4. Generating a controller

Having the model, let's turn our attention to creating the appropriate controller. We will again use the same generator that we used before:

$ rails generate controller Comments

Four files and an empty directory will be created:

Like any other blog, our readers will create their comments immediately after reading the article, and after adding a comment, they will be directed back to the article display page and see that their comment has already been reflected. In this regard, our CommentsController serves as a means of creating comments and removing spam, if any.

First we'll extend the Article show template (app/views/articles/show.html.erb) to allow a new comment to be added:

Title: <%= @article.title %>

Text: <%= @article.text %>

Add a comment:

<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>

<%= form.label:commenter %>
<%= form.text_field:commenter %>

<%= form.label:body %>
<%= form.text_area:body %>

<%= form.submit %>

<% end %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>

This will add a form to the article display page that creates a new comment when the create action is called on the CommentsController . Here the form_with call uses an array, which will create a nested route such as /articles/1/comments .

Let's write create in app/controllers/comments_controller.rb:

Class CommentsController< ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end

It's a little more complicated than what you saw in the article controller. This is a side effect of the attachment you set up. Each request for a comment keeps track of the article the comment is attached to, so we first resolve the issue of retrieving the article by calling find on the Article model.

In addition, the code takes advantage of some of the methods available for connections. We use the create method on @article.comments to create and save a comment. This automatically links the comment so that it belongs to a specific article.

Once we've created a new comment, we take the user back to the original article using the article_path(@article) helper. As we've already seen, it calls the show action on the ArticlesController, which in turn renders the show.html.erb template. This is where we want to display comments, so let's add the following to app/views/articles/show.html.erb.

Title: <%= @article.title %>

Text: <%= @article.text %>

Comments

<% @article.comments.each do |comment| %>

Commenter: <%= comment.commenter %>

Comment: <%= comment.body %>

<% end %>

Add a comment:

<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>

<%= form.label:commenter %>
<%= form.text_field:commenter %>

<%= form.label:body %>
<%= form.text_area:body %>

<%= form.submit %>

<% end %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>

Now you can add articles and comments to your blog and display them in the right places.

Refactoring

Now that we have working articles and comments, let's take a look at the app/views/articles/show.html.erb template. It became long and uncomfortable. Let's use partials to relieve it.

7.1. Rendering collections of partials

First, we'll make a comment partial showing all the comments for an article. Create a file app/views/comments/_comment.html.erb and put the following in it:

Commenter: <%= comment.commenter %>

Comment: <%= comment.body %>

Then you can change app/views/articles/show.html.erb like this:

Title: <%= @article.title %>

Text: <%= @article.text %>

Comments

<%= render @article.comments %>

Add a comment:

<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>

<%= form.label:commenter %>
<%= form.text_field:commenter %>

<%= form.label:body %>
<%= form.text_area:body %>

<%= form.submit %>

<% end %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>

This will now render the app/views/comments/_comment.html.erb partial once for each comment in the @article.comments collection. Since the render method iterates through the @article.comments collection, it assigns each comment to a local variable named like the partial, in this case comment , which is available to us in the partial for display.

7.2. Rendering a form in a partial

Let's also move the new comment section to our partial. Again, create a file app/views/comments/_form.html.erb containing:

<%= form_with(model: [ @article, @article.comments.build ], local: true) do |form| %>

<%= form.label:commenter %>
<%= form.text_field:commenter %>

<%= form.label:body %>
<%= form.text_area:body %>

<%= form.submit %>

<% end %>

Then change app/views/articles/show.html.erb like this:

Title: <%= @article.title %>

Text: <%= @article.text %>

Comments

<%= render @article.comments %>

Add a comment:

<%= render "comments/form" %> <%= link_to "Edit", edit_article_path(@article) %> | <%= link_to "Back", articles_path %>

The second render just defines the partial template we want to render, comments/form . Rails is smart enough to put an underscore on this line and understand that you meant to render the _form.html.erb file in the app/views/comments directory.

The @article object is available in any partials rendered in the view, since we defined it as an instance variable.

Deleting comments

Another important feature of the blog is the ability to remove spam. To do this, you need to insert some link in the view and a destroy action in the CommentsController.

Commenter: <%= comment.commenter %>

Comment: <%= comment.body %>

<%= link_to "Destroy Comment", , method: :delete, data: { confirm: "Are you sure?" } %>

Pressing this new link"Destroy Comment" will run DELETE /articles/:article_id/comments/:id in our CommentsController, which will then be used to find the comment we want to delete, so let's add a destroy action to our controller (app/controllers/comments_controller.rb) :

Class CommentsController< ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end def destroy @article = Article.find(params[:article_id]) @comment = @article.comments.find(params[:id]) @comment.destroy redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end

The destroy action will find the article we're viewing, find the comment in the @article.comments collection, and then remove it from the database and return us back to viewing the article.

8.1. Deleting Related Objects

If you delete an article, the comments associated with it must also be deleted, otherwise they will simply take up space in the database. Rails allows you to use the dependent option on a link to achieve this. Modify the Article model, app/models/article.rb , as follows:

Class Article< ApplicationRecord has_many:comments, dependent: :destroy validates:title, presence: true, length: { minimum: 5 } [...] end

Safety

9.1. Basic authentication

If you publish your blog online, anyone can add, edit and delete articles or delete comments.

Rails provides a basic HTTP authentication system that works well in this situation.

In ArticlesController we need a way to block access to various actions if the user is not authenticated. Here we can use the Rails http_basic_authenticate_with method to allow access to the required actions, if the method allows it.

To use the authentication system, we'll define it at the top of our ArticlesController in app/controllers/articles_controller.rb. In our case, we want the user to be authenticated for every action except index and show , so we'll write it like this:

Class ArticlesController< ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", except: [:index, :show] def index @articles = Article.all end # пропущено для краткости

We also want to allow only authenticated users to delete comments, so in CommentsController (app/controllers/comments_controller.rb) we'll write:

Class CommentsController< ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", only: :destroy def create @article = Article.find(params[:article_id]) # ... end # пропущено для краткости

Now, if you try to create a new article, you will encounter an HTTP Basic Authentication call:

Other authentication methods are also available for Rails applications. Two popular add-ons for Rails are Devise and Authlogic, among others.

9.2. Other thoughts on safety

Security, especially in web applications, is a broad and detailed area. The security of your Rails application is covered in more detail in the guide Security of Rails Applications The simplest way to work with Rails is to store all external data in UTF-8. If not, the Ruby and Rails libraries will often be able to convert your native data to UTF-8, but this doesn't always work reliably, so it's best to be sure that all external data is UTF-8.

If you make an error in this area, the most common symptom is a black diamond with a question mark inside appearing in the browser. Another common symptom is symbols such as "ü" appearing instead of "ü". Rails takes a number of internal steps to mitigate common cases of problems that can be automatically detected and corrected. However, if there is external data that is not stored in UTF-8, this can lead to these kinds of problems that Rails cannot automatically detect and fix.

The two most common data sources that are not in UTF-8 are:

• Your text editor: Most text editors (such as TextMate) save files as UTF-8 by default. If your text editor doesn't do this, it can cause special characters entered into your patterns (such as é) to appear as a diamond with a question mark in the browser. This also applies to your i18N translation files. Most editors that do not default to UTF-8 (such as some versions of Dreamweaver) offer a way to change the default to UTF-8. Do this.
• Your database: Rails by default converts data from your database to UTF-8 on the edge. However, if your database does not use UTF-8 internally, it may not be able to store all the characters that your user will enter. For example, if your database uses Latin-1 internally, and your user enters Russian, Hebrew, or Japanese characters, the data will be lost as soon as it enters the database. If possible, use UTF-8 as internal storage in your database.

Many of my developer friends spoke highly of Rails, but I couldn't understand why. What is Rails, and how does it differ from Ruby on Rails? How difficult is it to learn? Is this even a programming language? What do I need to know before learning Ruby on Rails?

These and many other questions were constantly spinning in my head, but, as it turned out, I was not the only one. Our readers were also interested in this issue, so to find out more about it, I decided to ask one of my colleagues a few basic questions about Ruby. This is how this article was born.

You are ready? Go!

13 Facts About Ruby on Rails – What You Need to Know?

1. What is Rails?

Rails is a web application framework that is designed for writing code in the Ruby language. Sounds confusing, right?

Let's try again. There is a programming language called Ruby. It's a pleasure to write on it. By the way, the person who created it said that his main goal was to create a language that would make the lives of programmers better. Isn't this wonderful?

Let me give you an example.

If I want to display text on the screen in PHP, I need to write

echo “Hello World”;

See the semicolon? And this “echo” - what does it even mean?

On the other hand, if I needed to do the same thing in Ruby, I would need to write the following:

puts “Hello World”

There's no semicolon, and while "puts" may look a little juvenile, it makes more sense to me than "echo." When you spend hours writing code, little details like this make a BIG difference.

The only problem with Ruby was that it was not designed for creating web applications. That is, you won’t be able to, for example, create a website on it. This was the case before Rails. I'm not sure if Rails was the first web framework for Ruby, but it DEFINITELY became the most popular.

The purpose of Rails is to provide a platform and capabilities that would allow you to create applications, in particular a website, in Ruby. It sounds pretty vague at the moment, so I'll try to explain it like this. If I wrote

puts “Hello World”

then in the HTML document, you would see the entire text. But I want you to see ONLY this:

Hello World

Simply put, Rails allows you to do this. But that's not all.

2. What is Ruby on Rails?

Ruby on Rails is the FULL official name of the Rails framework. But in conversation, developers usually don't say the first part, and just call it Rails. So if you want to be "on" and seem tech savvy, you should definitely call it Rails, but REMEMBER what that first part - "Ruby on" - means.

3. I've heard that Rails is great for beginners. Why?

There are several reasons why Rails is great for beginners. The first one is that the Ruby language itself is really good for beginners, and this is the first plus. Learning to code in Ruby is much easier than in other languages, since the language is quite flexible and liberal, which will save your nerves and allow you to spend more time learning the basics of programming.

Why is Rails so fun for beginners? It's just very stable and does a HUGE amount of work for you.

For me, working on Rails is like driving a truck. It's incredibly powerful, just look at you - you're driving a truck!!! However, how well do you know how the car you drive works?

The fact that Rails takes care of so many more tasks, doing them for you, will allow you to enjoy a lot of cool benefits right away. However, sometimes this can also work against you if sometimes you get ahead of yourself and do not fully learn the basics that you simply must know.

For this reason, it is very important to learn Ruby on Rails from scratch. And most importantly, you must make sure that you are truly comfortable working with Ruby. Otherwise, you'll just step out of that truck halfway and say to yourself, “Wait, was I really driving this thing?”

4. What is the difference between a Rails developer and a Ruby developer?

Formally, the difference is that a pure “Ruby developer” will create applications in Ruby, but not in Rails. Although this, as a rule, does not happen. It's certainly possible to build web applications in Ruby using other frameworks like Sinatra, but I'm willing to bet that 99% of the time you're unlikely to be hired as a Ruby-only programmer. Therefore, you need to learn Rails in any case.

5. How well should I know Ruby? What should I learn before starting my training?

Opinions vary on this, but sticking with the big truck example, I think you need to be comfortable with Ruby to delve into Rails. Just like, say, it is better to first learn to ride a bicycle before switching to a car, and then think about driving a truck.

And here's another thing. A lot of time when working on Rails will be spent writing code in Ruby. For this reason, you need to know this language very well, especially its basics: data types, methods, object orientation, debugging and much more. And you don’t have to be an extremely experienced Ruby programmer - you just need to feel confident when working with it, like a duck to water.

6. Why should I learn Rails? What makes it special?

It's exquisite and simply stunning. What else do you need to know? When Rails first appeared, it became a real discovery and achievement of design art. With best practices in mind when it was created, Rails practically sets you on the path to writing great code, even when you don't want to (or don't know how).

If you want to build robust web applications that will grow as needed while being easy to maintain in the future, Rails is a great option. Plus, it is popular among many cool companies. The last big reason why Rails is so popular among startups is that it's great for rapid prototyping. In just a few hours you can imagine, create and launch the Rails application you need. There are actually very few other frameworks that could handle this.

7. What can you create with Rails?

What do you want to create? Rails is suitable for any web application. To illustrate, check out these great examples of sites built with Rails: Hulu, Airbnb, and Basecamp.

8. Can I create mobile applications using Rails?

Yes and no. You won't be able to create mobile applications with Rails, but with Rails you can definitely create a web application and use it as a back-end for mobile application.

There's also a tool called RubyMotion that makes it very easy to create native iOS and Android apps in Ruby (but not Rails). That is, you won't SPECIFICALLY use Rails to create a mobile application for the App Store, but Rails can definitely be an important component of your mobile project. I hope the picture is now clearer.

9. Ruby on Rails - What kind of work can I get?

Rails is one of the most in-demand skills these days, so there are a lot of companies to choose from to work with. Startups, such as Zearn, especially love Rails. This is a start-up non-profit educational IT company. You can also choose a larger company like Bloomberg and participate in the development of sites and applications that are used by millions of users. Freelancing is also a good option for Rails developers. Being independent, you will be able to choose what projects you want to participate in: small and short-term or serious and long-term.

10. I tried another programming language, but I didn't like it. Should I try Rails?

I want to emphasize again - Rails is, in fact, not a programming language, but a framework. If you've ever wondered whether there's any point in trying to fall in love with any programming language, all I can say is that Ruby is the most revered and user-loved programming language in the world. So I wouldn't write off programming until you've tried Ruby.

11. Should I learn JavaScript together with Rails?

Instead - no. Additionally – UNDOUBTEDLY.

A Rails developer will have to learn JavaScript(). This is not a requirement for learning Rails, but it is a skill that you will need as you learn.

Let's be honest, as you gradually get deeper into the tech field, you'll start to realize that you'll have to have quite a lot of skills (basically, this means that everyone should strive to be a Full-Stack Developer). Luckily, as you gain experience, you'll find it easier to learn both new languages ​​and new frameworks.

As for whether to choose JavaScript or Rails, I’ll tell you straight up that you can’t go wrong either way. I find Ruby much easier to learn than JavaScript. In addition, I know many people who found JavaScript easier after they first learned Ruby. But, as I said above, you definitely can’t go wrong if you study both.

12. How long will the training take?

How much time per day will you have to spend studying? I think a good understanding of Rails requires several months of dedicated training. But like any other skill, you'll need tens of thousands of hours to become a Rails pro, so it's best to get started now.

Your learning speed will be greatly influenced by your level of knowledge in the field of programming in general. But if you're a complete beginner, it's worth trying to start with Ruby and Rails.

13. Ruby on Rails - Where to start?

I recommend starting with the best Ruby on Rails course available today. If you haven't written a line of code in your life, the first thing you should do is take the HTML and CSS course. Luckily, it's quite easy to find courses on HTML and CSS. After that, you'll need to learn Ruby, Git, and the command line.

The training program will typically introduce you to Rails gradually, showing you how to work with Sinatra and ActiveRecord. This doesn't tell you anything yet, but the point is that before you drive that "truck" I mentioned earlier, you should start with some simple Rails driving courses.

The best thing to do when studying is to create your own project, work on something and develop, know that you are moving in the right direction, and also have good support! During the learning process, you will have millions of small questions, and to achieve best result It is important that you have someone who can help you figure it out and give you some advice if difficulties arise.

Alexander is the founder of the “Web Laboratory of Success” website project, created to support beginning and continuing Internet entrepreneurs. He is a convinced workaholic with professional experience in managing the editorial office of an online magazine, creating and managing his own online store. Main occupation: promoting businesses (including online stores) through Facebook and Google Adwords. Main hobby: monetizing websites through affiliate marketing tools and Google Adsense. Personal confirmed records: 3 million blog visitors per month.

The author was prompted to write this text by studying a number of things found in Global Network materials that could well be designated under the same heading/tag: How I learned Ruby(or Ruby on Rails, PHP, JS, C++, etc) for three days.

Or something like that. The author, in turn, immediately recalled (uncontrollable associations) a number of anecdotes, united again by a common theme, which consists in the evaluative characterization of actions that can be performed foolishly... the Russian language is powerful and incredibly aphoristic, but, unfortunately, it does not seem possible to quote these masterpieces here; Accordingly, there is nothing left to do but to offer to the reader’s attention a personally written version of the document from the series How to learn to work in Ruby on Rails with pleasure and relatively quickly.

A working example of the code described in the article, among other Rails Examples, can always be found in the author’s test blog on herokuapp.com, welcome.

The technique is simple, and the author does not at all claim the laurels of a discoverer here: it is necessary that it be interesting, and the results will not keep you waiting. It doesn’t hurt to try to play on your own weaknesses, because sometimes vanity can be beneficial to the cause; the results of the development should be such that they can be proudly presented to readers, friends and colleagues on the Internet, deployed somewhere on Heroku or Amazon, also - so that we can return to them again and again, rebuilding and improving, forums and StackOwerflow help us all. So I say, why not write, first, your blog on Ruby on Rails?

I suggest starting from the excellent Getting Started with Rails docket or its Russian-language adaptation of Rails for beginners, also Build a Blog with Ruby on Rails, and the materials of this blog, links to which are easily found in the left sidebar, can also help. And then - that’s it, then magic, at first everything is laid out as if by notes, open the console - and forward... the author considers it his duty to make only a few explanations and technical recommendations designed to make it easier for the adept to find and acquire the Light Side of the Force, and no more Togo. This is only your battle, move forward boldly and return victorious.

So. The step-by-step of the first manual is perfectly calibrated and, I hope, will not cause you any trouble; all that is required of you is to be attentive, scrupulously repeating the detailed steps... and after an hour your first blog is ready, you can take a break and move on to the second, somewhat more interesting one. And it is here that, perhaps, a few parting words of advice may come in handy, which we will now proceed to.

Let's start with the statement that these methods are quite capable (as an option) of looking like what is shown below, but in no way the same as in the original:

app/controllers/posts_controller.rb

# Update action updates the post with the new information def update if @post.update_attributes(post_params) flash[:notice] = "Successfully updated post!" redirect_to posts_path else flash[:alert] = "Error updating post!" render:edit end end # The show action renders the individual post after retrieving the id def show end # The destroy action removes the post permanently from the database def destroy @post = Post.find(params[:id]) if @post .destroy flash[:notice] = "Successfully deleted post!" redirect_to posts_path else flash[:alert] = "Error updating post!" end end

But try this and that, why not. Let's move on.

Second blog, although more complex (added article editor CKEditor And devise, a flexible tool for authentication in rails applications), for some reason lacks the ability to leave comments in the original. You will have to fill this deficiency yourself: proceed by analogy with the description of creating the first blog, only very minor changes will be required: simply put, instead of article And articles you will have the first blog post And posts in the second blog, that’s basically the difference. Be careful and everything will work out.

Recaptcha You will also have to link to comments yourself: yes, yes, this is not Joomla for you, get used to it. However, titanic efforts are not required; the connection process Recaptcha is described in detail in the article Connecting Recaptcha in Rails application. Next, it’s not superfluous to adjust devise in such a way that the blog works (at least at first!) in single-user mode, allowing numerous of its readers READ ONLY mode, in other words, we will prohibit the registration of new users to begin with. There are quite a variety of recipes on the Internet on how to do this, but, in my opinion, the most competent hack of this kind is in the Wiki devise, in the material called How To: Set up devise as a single user system. Namely: we create a new controller:

app/controllers/registrations_controller.rb:

Class RegistrationsController< Devise::RegistrationsController before_action:one_admin_registered?, only: [:new, :create] protected def one_admin_registered? if ((Admin.count == 1) & (admin_signed_in?)) redirect_to root_path elsif Admin.count == 1 redirect_to new_admin_session_path end end end

then we override it in routes.rb, and that's it:

#devise_for:admins devise_for:admins, controllers: ( registrations: "registrations")

CKEDITOR.editorConfig = function(config) ( // config.enterMode = 2; //disabled

Completely config.enterMode = CKEDITOR.ENTER_BR // pressing the ENTER KEY input
config.shiftEnterMode = CKEDITOR.ENTER_P; //pressing the SHIFT + ENTER KEYS input

Config.autoParagraph = false; // stops automatic insertion of

On focus);

Perhaps, for starters, this is really all... damn, I almost forgot the most important thing. If you are going to deploy your new blog to Heroku- add these three lines to

config/application.rb

Config.assets.precompile += Ckeditor.assets config.assets.precompile += %w(ckeditor/*) config.autoload_paths += %W(#(config.root)/app/models/ckeditor)

Otherwise CKEditor will refuse to work for you in your new place.

One of the first and most detailed Rails training books on the Internet. The main advantage is detailed coverage of the most necessary issues, regular updates and free basic content.

True, the resource is entirely in English. And it is important to understand that this is built in the form of a book - you have to figure out all the issues yourself. Because of this, the duration and complexity of training cannot be predicted.

2. Railcasts

Another well-known educational resource throughout the Internet. More than one generation of Rails developers grew up on it. Also in English.

It is not built as a complete training course, but as a series of screencasts - short lessons on a specific topic. There are a lot of lessons, you can find them on almost any topic.

Unfortunately, the project stopped updating in 2013.

3. Rails for Zombies

A fun introduction to on-rails for beginners in the quest game style with a zombie atmosphere. Very popular among complete beginners.

It’s convenient because you don’t need to install anything on your computer. All problems are solved in the browser. Step by step you go through the game and begin to understand the basics of Ruby on Rails.

If you don't understand programming at all, this is your choice. There are no complex topics in the course, nothing distracts from the basics. In English.

3.Udemy

Large collection of video courses. Among them are many for ruby ​​and ruby ​​on rails. There is no point in providing specific links - choose according to your taste based on price or popularity.

The Udemy format involves fairly short courses with an emphasis on video lessons. Don't expect serious homework or prompt support from teachers.

4. Ruby Bursa

A powerful short course on the basics of Rails development. Experienced teachers, good program.

The student’s personal presence at the course is desirable and it takes place only in large Ukrainian cities.

5. Development in Ruby on Rails from Evil Martians

A three-day intensive course from one of the most experienced Ruby on Rails teams in Russia.

Rarely done. It's expensive (judging by the reviews, it's worth it). Requires personal presence. Suitable only for advanced programmers; beginners have nothing to do there.

6. Ruby on Rails online intensive course from “A Good Programmer”

A fresh project from a team known on Youtube for its Ruby courses for beginners.

The 3-month intensive program is designed for complete beginners and promises to turn you into a junior programmer with a portfolio of no less than 12 smart applications.

The course consists of video lessons, practical assignments, teacher support, and regular webinars.

Judging by youtube channel and user comments - these guys know what they are doing and you won’t be bored with them.