Sinatra is a web framework with an emphasis of getting a working prototype quickly.
A group of related technologies packaged together to speed up and enhance web development. Basically, an environment of tools that work together to get things on the web.
In terms of Ruby, you can think of it as a bunch of gems working together to make web development easier, more powerful, and less buggy.
- HTTP server software
- Engines to render templates to HTML
- Why don't we write straight-up HTML?
- Database communication
We started with SQL directly in order to understand the magic behind ActiveRecord.
We start with Sinatra in order to understand the magic behind Rails.
Rails automates lots of boilerplate code for us; it's important to know what that boilerplate is before we hide it away in a single command.
Let's look at an example URL: https://king-james-b.com/about
The root domain is: https://king-james-b.com
The 'route' is: GET '/about'
Another example: http://seba-banana.org/fruits/5/articles/6
The root domain is: http://seba-banana.org
The 'route' (could look) like this: GET '/fruits/:fruit_id/articles/:id'
So a route is the part of the URL that comes after the root name of the website, alongside what we call its HTTP method, aka the GET. We then use routes in order to execute specific commands on our server, such as:
- returning a specific webpage to the user
- submitting user data to our server.
GET, POST, PATCH, PUT, DELETE, etc. etc. These keywords indicate 'this route will perform an action within a general category of actions'
It's best to illustrate this with some examples:
GET translates to "I'm going to give you some information from our server!" This is how we serve our webpages.
POST translates to "I'm going to take some information from you and save it to our database!" This is how we get information from our users.
- Helps with documentation and readability.
- Two routes may be the exact same (both could be '/users/:id') except in HTTP methods (GET '/users/:id' vs POST '/users/:id')
- Their purpose will become clearer with the intro to CRUD and RESTful routes.
Let's look back at this URL: http://seba-banana.org/fruits/5/articles/6
The root domain is: http://seba-banana.org
The 'route' (could look) like this: GET '/fruits/:fruit_id/articles/:id'
Why does the route look like :fruit_id and :id rather than 5 and 6 in something like: GET '/fruits/5/articles/6'
These parts of the route can be considered wildcards. Hard coding every single route for every single fruit and article attached to those fruits would get tedious. Thus, we use something called parameters in our routes.
These are wildcards that attach whatever is in the :fruit_id and :id spots and stores them in a special hash called params.
To access them in Sinatra, we call params[:fruit_id] and params[:id] respectively, returning us the numbers 5 and 6 respectively.
This way, we are able to return specific instances of fruits and articles, using one route in order to do so.
To be painfully specific, erb is an implementation of eRuby, which allows us to embed ruby code (and most importantly, its output) into text documents. It stands for "Embedded RuBy".
This way, we can use those params we got earlier and put them into our HTML pages and/or influence what is shown!
.erb files compile down to plain text files like this:
- Ruby code is executed
- Any HTML or output from your Ruby code that was inside of the embedded Ruby gets inserted into your file as text.
- The text is then rendered as a regular HTML file.
Take for instance a variable I pass into my erb like this within a route:
get '/example/:var' do
@var = params[:var]
erb :test
end
I call this route with localhost:4000/example/Hello
and pass it into test.erb, which looks like this
<% if @var %>
<div><%= @var %></div>
<% end %>
<div>I'll display no matter what!</div>
After the embedded ruby code executes, the file test.erb looks like this:
<div>Hello</div>
<div>I'll display no matter what!</div>
Notice how the
This is the power of embedded Ruby in HTML files.
Assign them to "instance variables" with the @var syntax. Your parameters are not immediately available to your erb files directly and must be assigned to instance variables.
<% and <%= both execute your ruby code inside of a document, but only <%= actually will output something into the document itself.
I like to think about it this way: whenever you'd normally put a "return", "puts", "print", or "p" to output something to the console, use <%=. For all other cases, use <%. Primarily avoid them for your conditional logic, since if and else statements shouldn't output anything!
Absolutely. Consider this case here.
get '/:catch' do
"I've caught you, #{params[:catch]}!"
end
get '/about' do
"We made it to the about page."
end
If our root domain is localhost:4567 and we type into our address bar 'localhost:4567/about', we'll get caught by the first route rather than the intended second, outputting something like:
I've caught you, about!
To avoid this, switching the order usually suffices, with more specific non-wildcard routes placed higher in the list of routes.
- Make sure that you've installed all the gems for the ruby version you're running at that instance. Installing a new ruby version means installing the gems for that version AGAIN.
- If you've run a server before and closed the terminal window running it, you may have a 'zombie server' running. All instances of web servers will take up one port when run, so if you didn't properly shut down one server, it will continue to block the port until killed. To do this, perform the following commands:
- ps ax | grep shotgun
- ps ax | grep ruby sinatra.rb
- px ax | grep thin
For any of these, if anything WITHOUT a grep pops up, kill it as such:
kill -9 [process number]
Where you replace [process number] with the number at the beginning of the line listing the process.
See this for an example: https://gist.github.com/ryandeussing/5667094