My God, I made it. It was a little close at times but damnit, I made it. Week 1 was so unbelievably jam packed that it is all a little bit hazy. As I write this I am drinking a glass of wine and lounging in bed before going out for the night – it is Friday night and I have just now successfully completed my first full week of Launch Academy!
I will save all of the logistics and first impressions of week 1 for other separate posts that way I can keep this post ‘scoped‘ to the content we were taught to give you a better idea of the curriculum that Launch Academy offers. So, let’s do it…
- What is HTTP?
HyperText Transfer Protocol – HTTP is a protocol that is used in the web as a way of requesting, posting, transferring and receiving data. A URL can be broken up into 3 simple components: The Scheme, The Hostname and The Path.
- https://reddit.com/r/gifs : In this instance,
httpsis the scheme,
reddit.comis the hostname and
/r/gifs/is the path
Why is this important? Well, when you go to ‘http://www.reddit.com‘ you are making a request to the server. More specifically, you are making a ‘GET‘ request to the server. There are 4 types of ‘VERBS‘ that are associated with HTTP and they have corresponding ‘CRUD‘ definitions:
What do these do? Keep in mind that, as a user (client) all of this is happening in the background and you interact with a web page. It is only the developer that has to worry about making these specific requests.
- POST: This request is used when the client (user) wants to add information to the server. Think forms or personal informations like credit card numbers or shipping addresses.
- GET: This request is used when the client (user) wants to view the contents of the page (specified by the file path e.g
localhost:4567/dogs/puppies). In this case, the user is not adding anything, they are merely viewing what already exists.
- PUT/PATCH: This request is similar to POST in that the client (user) is adding information to the server but it is more focused in that that only allows for smaller pieces to be altered. For instance, you may have inputted your shipping address, but now you want to change the name to ‘Dr. Emmit Brown’, this is a PUT/PATCH request.
- DELETE: Go ahead, take a guess. Yep. This is used to delete information, pretty straightforward.
Now, based on how the server is set up and what exactly the user (client) is requesting of the server, the server will then respond with anyone of a number of codes ranging from
100-599. Each block of codes designate specific errors or functions. For instance, if you were to right click this page right now and head over to the ‘Network‘ tab, you would see that the server responded with a code of 200. This is good! It means that everything that you requested was found and returned to your computer without any issues!
In keeping with the pace of Launch Academy, let’s just dive right into Sinatra. Think of Sinatra as the younger brother of Rails (Ruby on Rails). The way it has been explained to me is that Sinatra is a lightweight framework used for quickly getting a website up and running. To this extent it is good but ultimately we will not be using this in the future in any kind of professional setting because it doesn’t have all of the tools we will be needing on larger more scaled projects but it does work well for learning.
To get us started, they wanted to really hammer home the idea that Sinatra is to be used to make our web pages more dynamic. What does that mean? Well, we don’t want static HTML just being thrown all over the place, we want our users to be able to manipulate what it is that they are interacting with.
For instance, we could have a page that consists of a form, used for inputting 2 values –
URL. What we want is for the page to dynamically update after the form is submitted without reloading the page. This will provide a far more seamless user experience. Here is a quick example of something I worked on this morning:
I am totally biased towards German Shepherds, I absolutely love em – my family has 2 of them, Maggie and Stella. Putting that pet plug to the side for a moment, focus your attention to the image above. We have a simple page that displays a Name and Image based on user input in a form at the bottom. If you were to type in ‘Husky & http://www.husky.com/images/dog‘ and click submit, you would simply see the page update automatically without having to refresh.
This is a good example of structuring your website to be tailored in such a way that user experience and ease of use is prioritized over other potential features and for that it is a very valuable lesson indeed.
Embedded Ruby: In the world of web development, we want to stay away from having our static html files become to cluttered with information. The best approach would be to have a boilerplate html file. A boilerplate is basically a template, so you would have all of your most necessary information, you
<body> tags but you would keep your other tags in separate file and call on them only when needed, this way you can keep your pages both dynamic for the user and clutter free for the developers working on that project.
Enter ERB. This is a really cool coding tool in that it, like I mentioned previously, allows us to essentially write in logic and code into our HTML files. How? Let’s take a look…
Ok, so there is a lot going on here for someone new to this so we will tackle it one piece at a time. First off, this little piece of code is stored in a file called
index.erbwhich is different from our main
html file. Why is this? Well, let’s look at one more image first.
In this image we can see that we have something called a template layout. In Fact, the name of this file is called
layout.erb why is this important? Look at the
<%= yield %>in the middle there. That is basically saying, whatever files you want to run, run them in this spot right here.
<%= yield %>is a placeholder for other files. This allows us to break up our code into multiple files. This is super useful if you have a webpage that has several pages, that way you can create the HTML for that individual page in its own file and only call it in your main html file when needed.
In terms of syntax, we need ‘snow cones‘ whenever we are using ERB inside of what will ultimately be rendered as HTML. There are two types though, snow cones with equals and snow cones without. With equals means that whatever is inside the snow cones will be rendered as plain text whereas without equals means it is logic. Let’s look at an example:
<% my_loop.each do |item| %>This example (plus the additional logic of
end) will be read by the ERB interpreter but not printed.
<%= item %>will print to the screen as HTML. If
itemequaled hamburger than you would see hamburger printed to the screen in HTML.
Writing this blog post has been really difficult. I am trying to condense the entire week into a simple blog post but I don’t want it to be a fill on novel – which it would be had I included everything we learned this week. Launch On-Campus, so far and from my estimation, appears to be about 2-2.5x the material of Ignition per week. So, basically we are doing 2 days worth of work in one day.
The mornings are spent reviewing the previous night’s homework and reading, while the afternoons are spent on even newer material and then before being let go for the night we are AGAIN given yet more material to be reviewed and completed for the following morning.
This week was freakin NUTS. I have learned so much and it was super difficult but I knew what I signed up for when I applied to Launch Academy and I certainly got it. I will make a separate post to cover my own impressions of the staff, curriculum and over day-to-day operations of being a Bootcamp student at Launch Academy. For anyone interested, here is a more comprehensive breakdown of the material we covered this week:
- The HTTP Request/Response Cycle
- Server Codes
- URI (uri.parse)
- Page Redirects
- Directory Breakdown (views, server, public)
- Dynamic Routing
- Updating Pages based on Form Input
- Acceptance Testing
- Feature Testing
- Promise API
- Callback Functions
- Chaining Promises
- FETCH API
- Asynchronous Programming
- Response Object