Ever heard of Ruby on Rails? If you are interested in web development or have been studying it for a while, chances are that you would have heard about it. It is, simply put, a popular language for web development. If you are a seasoned or budding web developer curious about Ruby on Rails, this could be a good starting point to your journey into this wonderful language.
You may also be familiar with other web development forms like PHP, Perl, Java, Python . Here, you will get an introduction to Ruby on Rails and understand the basics of both: Ruby as well as Rails. Yes, they are two different things and we’ll get to that in a moment.
A history of Ruby on Rails
Ruby on Rails was developed all the way back in 2004, David Heinemeier Hansson, who chose a then relatively obscure programming language called Ruby because he thought that Java and PHP were not flexible or powerful enough. He developed Rails, his own web development framework using Ruby based on simple, existing and proven ideas, instead of using brand new, experimental ones. The success of Ruby on Rails has largely been because it is based on these well-established paradigms.
What is Ruby on Rails?
It is a framework based on the model-view-controller pattern that splits an Application in three parts:
Models are business objects that describe the behaviour or structure of the problem that is being solved by your application. They are typically backed by an object-relational mapping framework persisting your objects to a database in the back.
Views are essentially templates rendering data to the user, and the logic of the presentational parts of your app.
At the heart of it all is the controller, which processes client requests, starts changes in the models and triggers rendering of the templates.
So, simply put, the model is your backend application function, the view is the template and representational aspect that the user sees, and the controller determines what does what and when. Rails is focused on doing things a certain way and streamlines its elements around that way. So if you choose to build on Rails, you have to do it the Rails way. You could do things differently, but it could be a little troublesome. All this makes it seem rather limited in its approach, but the fact is that this way is actually similar to what most programmers do. In fact, Rails was developed for programmer productivity first, rather than outright performance.
Of course, this also means that it can be a little slower than comparable stacks on, say, Python or PHP. Now, to use this you need to have some things already installed:
- The latest version of Ruby
- The RubyGems packaging system, which comes with Ruby
- A working SQLite3 Database installation
A step-by-step guide to making a new Rails project:
Now let’s get to the meat of it all. Follow the steps given below, one by one, to create an example application on Ruby on Rails. The example application here is a simple weblog (blog). Before you begin, you need to have Rails installed on your system. Speaking of your system, the examples given below use $ for representing the terminal prompt. Your system may display it differently. On Windows, the prompt would be C:\source_code>.
Step #1: Installation of Ruby on Rails
There are lots of tools available to quickly install Ruby on Rails or Ruby on your system. If you use Mac OS X, you can use Tokaido. For Windows users, Rails Installer is a good choice.
Start by opening a command line prompt. Select Run from the Start Menu and type cmd.exe if you are on Windows, or open Terminal.app if you use Mac OS X. As for SQLite3, a lot of UNIX-like systems come with an acceptable version. Windows users and others without SQLite3 can get it installed from the SQLite3 website. Now, verify that you have both installed:
$ ruby –v
This should return you the version of Ruby installed.
$ sqlite3 –version
This should return you the version of SQLite3 installed.
Now, it’s time to install Rails using the gem install command by RubyGems:
$ gem install rails
Now, type the following to verify the install:
$ rails –version
This should return the version of Rails installed, and you are ready to continue.
Step #2: Creating the application
Now that you are all set with Ruby on Rails and SQLite3, it’s time to step up and start making the application. Rails has a lot of scripts called ‘generators’, designed to make development much easier. These generators create everything needed to start working on a task. One such generator is the ‘new application generator’. This one provides the necessary foundation for making a fresh Rails application so that you do not have to write one all by yourself.
To use this generator, you need to open a terminal and navigate to a directory where you can create files. Once there, you need to type the following:
$ rails new blog
This creates a Rail application named ‘Blog’ in a blog directory. All the gem dependencies mentioned in the Gemfile will already be installed in the directory using the prepacked bundle. You can see these command line options by running the rails new –h command.
Once the blog application is made, switch to its folder:
$ cd blog
The blog directory has several auto-generated folders and files and that make the structure of the Rails application. Most of this tutorial will happen in the app folder, but here is a quick look at what each folder does:
- App: this contains the controllers, views, models, helpers, assets and mailers for the application
- Bin: this folder has the rails script that starts the app and other scripts to use for setting up, deploying or running the application
- Config: this folder has the application database, routes and more.
- ru: this is the rack configuration for rack-based servers used to start an application
- Db: this one has your database schema and database migrations
- lock: these files enable you to specify the necessary gem dependencies for your Rails application. They are used by the Bundler gem.
- Lib: these are extended application modules
- Log: these are application log files
- Public: The only folder that will be seen by the world, containing compiled assets and static files
- Rakefile: this file loads and locates tasks runnable from the command line, and the tasks are defined through Rails components. You can add your own tasks by adding files to the lib/tasks directory instead of editing existing Rakefiles.
- doc: This is an instructional manual that you can edit for your own application
- Test: it has test apparatus like unit tests and fixtures
- Tmp: they have pid, cache and session files
- Vendor: this is where third-party code goes into
Step #3: Starting off
Let’s start off by putting up some text real quickly. You need to first get your Rails applications server up and running. Here is how you do it:
Starting the web server
You actually already have a functional app set up, but you need to start the web server on your development machine to start it up. To do this, you need to run the following command in the blog directory:
$ bin/rails server
Running ExeJS will start up the web server WEBrick, which is the default distributed server with Ruby. You can see your application in action by opening up a browser and navigating to http://localhost:3000. You would see the Rails default information page here:
Use Ctrl+C on the terminal window to stop the web server. You should be able to see your command prompt cursor if the server has stopped. Rail in development mode does not generally require a server restart. All the changes made in the files are usually picked up automatically by the server.
The information page that you see is the first test for your new application. It ensures that all the necessary tools and software are correctly configured. Everything is in the right place. You can also find a summary of your application environment by selecting the About your application’s environment link.
Step #4: The next Step
The next step now is to get Rails to say ‘Hello’, for which a controller and view are needed. A controller will receive requests for the application, with routing used to determine the controller that gets specific requests. In many cases, there is more than one route for each controller, and routes can serve different actions too to collect information for putting out a view. A view aims to display the information in a format that is easy for the user to understand. Keep in mind that the information is collected in the controller and not the view; the view is just displaying the information. View templates are written in Embedded Ruby or eRuby by default. This language is processed in Rails by the request cycle before it is sent out to the viewer.
To make a new controller, you need to run the controller generator and name it ‘welcome’, with an action named ‘index’. Here is the code for setting this up:
$ bin/rails generate controller welcome index
route get ‘welcome/index’
Keep a note of where the controller and view are located, because that is important information. Now, open the file app/views/welcome/index.html.erb file in your text editor and remove all existing code. Replace it with just this one:
At this stage, you now have to set up Rails to display the Hello message when you want it. In this example, it needs to come up when you visit http://localhost:3000. Next, you have to tell Rails the location of your actual home page. To do this, open the config/routes.rb file in your text editor and type the following:
The file that we opened just now is the routing file for your application, holding entries in a domain-specific language that tells how Rails is to connect requests to actions and controllers. The file has several sample routes on commented lines. Find the line beginning with the root and remove the comment. It should be similar to the following:
Now, relaunch the web server if you stopped it and navigate to the localhost URL. You should see the Hello message that you just wrote.
Step #5: Going forward
Now it’s time to make something a bit more complex. You will now make a new resource in the Blog application. The resource is a collection of similar articles or objects. Creating, reading, updating and destroying items for a resource are called CRUD operations. Rails has a resource method to declare a standard REST resource. Here is how you do it:
if you are running bin/rake routes, you will see that it already has routes for standard REST options. You will also see that Rails has already inferred the form article and made use of the distinctions.
$ bin/rake routes
Prefix Verb URI Pattern Controller#Action
articles GET /articles(.:format) articles#index
POST /articles(.:format) articles#create
new_article GET /articles/new(.:format) articles#new
edit_article GET /articles/:id/edit(.:format) articles#edit
article GET /articles/:id(.:format) articles#show
PATCH /articles/:id(.:format) articles#update
PUT /articles/:id(.:format) articles#update
DELETE /articles/:id(.:format) articles#destroy
root GET / welcome#index
Rails is designed to make web application programming easier by assuming certain things that every developer needs to get started. You can write an application on Rails with fewer coding, all the while accomplishing more than other frameworks or languages. The Rails philosophy has two major principles:
Do not repeat yourself:
Do no repeat yourself or DRY is a software development principle that states ‘Every piece of knowledge must have a single, unambiguous, authoritative representation within a system’. This means not writing the same code over and over again. It makes the overall program less buggy and more extensible and maintainable.
Convention Over Configuration:
Remember when we mentioned the Rails Way? Rails assumes that its own set of conventions on web application function is the best way to do things. It defaults to these conventions, so you do not have to specify each and every thing through configuration files.
The post How to Learn Ruby on Rails - 5 Quick Steps Guide appeared first on eduCBA.
This post first appeared on Free Online CFA Calculator Training Course | EduCB, please read the originial post: here