Unexpected cold put me on bed but I managed to produce my first web game app
The 3rd week at Makers was not as smooth as I expected, and I blame that on an October cold which I might have caught randomly on a tube trip. I was on bed for two days, thinking of all the workshops and progress I was missing. But negativity doesn’t help, so I finally decided to give this to myself as a special holiday, which turned out to be very helpful for recovering. So Friday, there I was, back to the classroom and back on track again.
This week we mainly focused on two perspectives of the web, the theory part and the practical part:
- Explain the basics of how the web works (client-server relationship, HTTP, request/response,URL, )
- Build a simple web app using Sinatra and test using Capybara(Model-View-Controller, Erb, html forms, rack and middleware, sinatra, capybara, Post/Redirect/Get)
Have to say, except for the unwelcoming cold, I really enjoyed this week’s curriculum. It’s the first time I’m learning something so close to my daily browsing experience! Well the first two weeks ruby was also fun, but that sits closer with backend, while the web — while I still have to think about backend and middle-stack all the time, I could at least beautify the visual effect of my little web game!
Reading, tons of reading this week, and most of them relates to the structure of HTTP (request or response). Who could have known the complexity behind a simple click on the web?
Other than that, it all comes down to building a simple web game. It is also the first time the (SoC) Separate of Concerns was introduced to us, as well as the famous MVC (Model-View-Controller). Well, I did come across the (SRP) Single Responsibility Principle quite often in the first two weeks, and I feel it’s all about making the code chunk only mange one thing and one thing well. Still, SoC is a bit more complex. At the beginning I was struggling to make the view as light as possible, as I tend to incorporate some logic in there to reduce burden of the model. Then I learnt about the Rule of thumb: view logic should be limited to:
- Light Conditionals (i.e.
- Light Iterators (i.e.
As a rule of thumb, logic should be ‘pushed down the stack’ wherever possible. ‘Views’ are for lightweight logical lifting, and controllers are for middleweight stuff.
In general, I give myself a 8 out of 10 for this week. Hopefully I will be fully recovered next week and get a productivity boost.
Something that I wish I could have more time to dig into is the Google DevTool, obviously this is an essential tool for web developers, but for now I don’t have many opportunities to explore it yet.
That’s all for this week. See you around next week：）
==========Highlights of the Week=============
A. Web Basics
Client-Server Model and World Wide Web
It’s quite amazing that after being an Internet surfer for about 15 years, it’s the first time I know about WWW- World Wide Web and the client-server model behind it.
So based on Wiki, the WWW is an information space made up of two chief components: resources (mostly stored on servers), and the entities that request those resources (usually called clients). For example, when you visit a website, such as http://www.google.com, your browser (e.g. Firefox, Chrome, Safari) acts as a client. It requests a resource — in this case, the Google homepage — from a server. The server returns the requested resource.
Hypertext Transfer Protocol (HTTP)
Usually, clients and servers talk to each other using the HyperText Transfer Protocol. A client makes a request to a server and gets back a response. It is called a “protocol” because it has a defined structure for requests and responses.
HTTP Request Structure
The first line of the HTTP request is called the request line and consists of 3 parts:
- The “method” indicates what kind of request this is. Most common methods are GET, POST and HEAD.
- The “path” is generally the part of the url that comes after the host (domain). For example, when requesting “https://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/" , the path portion is “/tutorials/other/top-20-mysql-best-practices/”.
- The “protocol” part contains “HTTP” and the version, which is usually 1.1 in modern browsers.
The remainder of the request contains HTTP headers as “Name: Value” pairs on each line. These contain various information about the HTTP request and your browser. For example, the “User-Agent” line provides information on the browser version and the Operating System you are using.
HTTP Response Structure
After the browser sends the HTTP request, the server responds with an HTTP response. The first piece of data is the protocol. This is again usually HTTP/1.x or HTTP/1.1 on modern servers. The next part is the status code followed by a short message.
HTTP Status Codes
- 200’s are used for successful requests.
- 300’s are for redirections.
- 400’s are used if there was a problem with the request.
- 500’s are used if there was a problem with the server.
URL stands for Uniform Resource Locator, or in other words, the web address of an online resource, i.e. a web site or document.
The protocol: The scheme identifies the type of protocol and URL you are linking to and therefore, how the resource should be retrieved.
The Host Address/Domain: The host address is where a website can be found, either the IP address (four sets of numbers between 0 and 255, for example 188.8.131.52 ) or more commonly the domain name for a site such as www.tutorialspoint.com.
Port: The port number is rarely visible in URLs but always required. When declared in a URL it comes right after the TLD, separated by a colon. When it’s not declared and in most cases where the protocol is http, port 80 is used. For https (secure) requests port 443 is used
Path: The path typically refers to a file or directory on the web server, e.g.
Query: A query is commonly found in the URL of dynamic pages (ones which are generated from database or user-generated content) and is represented by a question mark followed by one or more parameters. The query directly follows the domain name, path or port number.
Parameters: Parameters are snippets of information found in the query string of a URL. With reference to the Google query above, the parameters follow the question mark and are separated by an ampersand (&) character so they can be understood individually and used to display content on that page.
HTTP Request Methods
The two most commonly used request methods are: GET, and POST.
GET: Retrieve a Document
GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1 .
POST: Send Data to the Server
Even though you can send data to the server using GET and the query string, in many cases POST will be preferable. Sending large amounts of data using GET is not practical and has limitations.
The other request verbs are
PUT: update an existing resource. The payload may contain the updated data for the resource.
DELETE: delete an existing resource.
NOte that PUT and
DELETE are sometimes considered specialized versions of the
HEAD: this is similar to GET, but without the message body. It’s used to retrieve the server headers for a particular resource, generally to check if the resource has changed, via timestamps.
TRACE: used to retrieve the hops that a request takes to round trip from the server. Each intermediate proxy or gateway would inject its IP or DNS name into the
Via header field. This can be used for diagnostic purposes.The TRACE method is used to echo the contents of an HTTP Request back to the requester which can be used for debugging purpose at the time of development.
OPTIONS: used to retrieve the server capabilities. On the client-side, it can be used to modify the request based on what the server can support, e.g.HTTP methods and other options supported by a web server. The client can specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server.
B. Web App Basics
One of the big challenge during the weekly exercise was to use views to separate the Ruby and HTML code. This is the first time I encounter the concept of separation of concerns.
In my case,
app.rb will be for routing (or controlling) concerns, and I have to use another file for my presentation (or view) concerns. In which case, when I’m calling
erb, a method from the templating system that ships with Ruby, I’m asking it to render a file called index.erb from the folder views.
erb is very powerful. Its full name is embedded ruby. It is part of the Ruby Standard Library. Erb provides an easy to use but powerful templating system for Ruby. Using Erb, actual Ruby code can be added to any plain text document for the purposes of generating document information details and/or flow control.
A very simple example from the ruby official doc looks like this:
require 'erb'x = 42
template = ERB.new <<-EOF
The value of x is: <%= x %>
Prints: The value of x is: 42
- When passed a regular string,
erbwill do nothing: in Sinatra, running
erb("a string")will simply return
- A tag with an equals sign indicates that enclosed code is an expression, and that the renderer should substitute the code element with the result of the code (as a string) when it renders the template. Use an expression to embed a line of code into the template, or to display the contents of a variable:
Hello, <%= @name %>.
Today is <%= Time.now.strftime('%A') %>.
- Tags without the equals sign denote that the enclosed code is a scriptlet. Each scriptlet is caught and executed, and the final result of the code is then injected in to the output at the point of the scriptlet. Scriptlets are most commonly used for embedding loops or conditional logic into templates:
<% for @item in @shopping_list %>
<%= @item %>
<% end %>
HTML Forms are one of the main points of interaction between a user and a web site or application. Forms allow users to enter data, generally sending that data to the web server, but a web page can also use form data client side.
An HTML Form is made of one or more widgets. Those widgets can be single or multi-line text fields, select boxes, buttons, checkboxes, or radio buttons.
<% if @name %>
<h1>My name is <%= @name %></h1>
<% end %>
<input type="text" name="name">
<input type="submit" value="Submit">
<div style='border: 3px dashed red'>
when you click the submit button, your browser:
- Constructs a request to the path specified in the
actionattribute of the form tag
- Constructs a query string depending on the inputs within the form, and appends this to the request
- Sends the request to the server.
Each row of the Network Log represents a resource. By default the resources are listed chronologically. The top resource is usually the main HTML document. The bottom resource is whatever was requested last.
Each column represents information about a resource.
- Status. The HTTP response code.
- Type. The resource type.
- Initiator. What caused a resource to be requested. Clicking a link in the Initiator column takes you to the source code that caused the request.
- Time. How long the request took.
- Waterfall. A graphical representation of the different stages of the request. Hover over a Waterfall to see a breakdown
Test with automated browser and Capybara
Selenium automates browsers.
Capybara helps you test web applications by simulating how a real user would interact with your app. It is agnostic about the driver running your tests and comes with Rack::Test and Selenium support built in.
Capybara can be classified as a tool in the “Testing Frameworks” category, while Selenium is grouped under “Browser Testing”.
Capybara isn’t what actually interacts with the website — rather, it’s a layer that sits between you and the actual web driver. This could be Selenium, PhantomJS, or any of the other drivers that Capybara supports. It provides a common interface and a large number of helper methods for extracting information, inputting data, testing, or clicking around.
Capybara integrates really nicely with all of the common test frameworks used with Rails. It has extensions for RSpec, Cucumber, Test::Unit, and Minitest. It’s used mostly with integration (or feature) tests, which test not so much a single piece of functionality but rather an entire user flow.
describe “the signin process”, type: :feature do
before :each do
User.make(email: ‘firstname.lastname@example.org’, password: ‘password’)
endit “signs me in” do
fill_in ‘Email’, with: ‘email@example.com’
fill_in ‘Password’, with: ‘password’
click_button ‘Sign in’
expect(page).to have_content ‘Success’
Middleware and Rack
Rack is a modular interface between web servers and web applications developed in the Ruby programming language. With Rack, application programming interfaces (API) for web frameworks and middleware are wrapped into a single method call handling HTTP requests and responses.
Rack defines a very simple interface. Rack compliant code must have the following three characteristics:
- It must respond to
callmethod must accept a single argument - This argument is typically called
environment, and it bundles all of the data about the request.
callmethod must return an array of three elements These elements are, in order,
statusfor the HTTP status code,
bodyfor the actual content of the response.
Middleware is a dreadful term which refers to any software component/library which assists with but is not directly involved in the execution of some task. Very common examples are logging, authentication and the other common, horizontal processing components. These tend to be the things that everyone needs across multiple applications but not too many people are interested (or should be) in building themselves.
Middleware in racks
Rack makes it easy to add a chain of middleware components between the application and the web server. Multiple middleware components can be used in the rack which modifies the request/response before handing it over to the next component. This is called middleware stack.
The Rack server adds multiple middle middleware by default for the functionalities like showing exception with all the details, validating the request and responses according to the Rack spec etc.
RSpec Directory Structure
Specs are usually placed in a canonical directory structure that describes
their purpose. It is suggested that the
spec/ directory structure generally mirror both
lib/. This makes it easy to locate corresponding code and spec files.
│ ├── application_controller.rb
│ └── books_controller.rb
│ ├── application_helper.rb
│ └── books_helper.rb
│ ├── author.rb
│ ├── book.rb
│ ├── books_controller_spec.rb
│ ├── tracking_book_delivery_spec.rb
│ └── books_helper_spec.rb
│ ├── author_spec.rb
│ ├── book_spec.rb
│ ├── books_spec.rb
│ └── books_routing_spec.rb
│ ├── irc_spec.rb
(PRG) is a web development design pattern that allows for the page shown to the user after a form submission to be reloaded, shared or bookmarked without certain ill effects such as submitting the form another time.
When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.
To avoid this problem, many web developers use the PRG pattern — instead of returning a web page directly, the POST operation returns a redirection command.
It has a method
redirect for that:
post "/monstas" do
@name = params[:name]
redirect method will make sure our application responds with the status code
303 and add a
location header to the response with the value
http://localhost:4567/monstas (since we have passed the path
/monstas, but the
location header needs a full URL).