LaunchSchool - An Online School for Developers /


Growing Your Own Web Framework With Rack Part 4

In part 3 of this series, we focused on isolating our view related code to a views directory, and moving it out of our main application code. In this post, we’ll continue to separate out the view related code for our other routes, and then finally, we’ll extract some more general purpose methods to a framework. This is the last step in our work to “grow” a web development framework. Let’s get started.

Growing Your Own Web Framework With Rack Part 3

Part 2 of this series focused on routing and expanding our application to serve back HTML responses. In this post, we’ll start to think about separation of responsibilities between our core routing logic and our views. We’ll introduce a library ERB that will help us turn Ruby code into HTML. Finally, we’ll update our application code to include view templates.

Growing Your Own Web Framework With Rack Part 2

In part 1 of this series, we explained what Rack is and how to use it to build a simple web application. In this post, we’ll be expanding on that by adding in different URL endpoints. To do this we’ll also have to delve a bit deeper into how Rack keeps track of request data via headers.

Growing Your Own Web Framework With Rack Part 1

This post is the first part in a four part series on how to build your own web framework with Rack. The 4-part series will cover what rack is, how to use it to handle incoming requests, how to use templating techniques to return a response, and finally, how to extract common code to plant the seeds for your very own web application development framework. Here in part 1, we’ll give a short introduction on what Rack is and how to use it. We’ll end things by building a simple Rack application.

Meet a Student: Darren Burgess

Darren Burgess stopped by the podcast to talk about his experience at Launch School. Before starting at Launch School, he spent many years as a Filemaker Pro developer and even attended a different coding “bootcamp”. We talked about the learning process he’s been on and why he almost left Launch School. Subscribe to the Launch School Podcast on iTunes, or just play this episode below.

Meet a Student: Rachel Minto

Rachel is currently in the “Advanced” phase of the program, having completed all back end and front end courses. She stopped by to share her experience so far at Launch School. We talked about:

  • her art and philosophy background and how that’s affected her programming journey
  • balancing Launch School with a fulltime job
  • Women Who Code and women in tech
  • her experience going through the Advanced courses
  • the importance of gaining confidence in what you do

Subscribe to the Launch School Podcast on iTunes, or just play this episode below.

Meet a Student: Tommy Caruso

In this interview, Tommy Caruso shares with us his strategy of balancing a family, kids, finishing up his Computer Science degree, and Launch School all at the same time. Oh, and he’s also interning in his spare time. We had a great time chatting about time management, study habits, and the sacrifice it takes to really learn things to depth. Listeners may also be interested in his take on comparing his Computer Science courses with that of Launch School.

Subscribe to the Launch School Podcast on iTunes, or just play this episode below.

Meet a Student: Karl Lingiah

One of our students, Karl Lingiah, took time to answer some questions and talk about his journey so far at Launch School. He shares his ideas on learning in general, and specifically what his experience has been so far at Launch School.

Note: we had a sub-optimal internet connection, so the audio is not the best, but the full talk is still worth a listen.

Subscribe to the Launch School Podcast on iTunes, or just play this episode below.

Assert Yourself: An Introduction to Minitest

One of the biggest keys to producing quality software is properly testing your program under a wide variety of conditions. Doing this manually is tedious and error-prone, and frequently doesn’t get done at all. This leads to buggy software, and sometimes software that doesn’t work at all.

Fortunately, modern programming environments support automated tests. Such tests can be run repeatedly with minimal effort: it’s even possible to run them automatically prior to every commit or release. While automated testing doesn’t guarantee that your code will be bug free — the tests are only as good you make them — it can certainly reduce the number of bugs your users will encounter. Automated testing can also help you find and fix bugs earlier in the development cycle, and prevent a lot of needless debugging trying to track down a particularly nasty bug.

In this post, we will talk about Minitest, the standard software testing framework provided with Ruby. It isn’t the only software testing framework available, but being supplied automatically with Ruby is a major advantage.

In particular, we will discuss how to use Minitest assertions to test your software. We aren’t interested so much in the theory of automated testing, but in how to use Minitest.

Object Passing in Ruby - Pass by Reference or Pass by Value

This is the last in a series of three articles that discuss how ruby manipulates variables and objects, and, in particular, how objects are passed around in a ruby program. If you haven’t read the first two articles, you may want to check them out first: Understand Variable References and Mutability and Ruby’s Mutating and Non-Mutating Methods.

We now have a good grip on how ruby uses variables to reference objects, what the terms mutability and immutability mean, and what it means for a method to be mutating or non-mutating. We’ve also been briefly introduced to the concept of object passing, and have established an initial mental model that states that ruby appears to use pass by value for immutable objects, and pass by reference for mutable objects. We’ve also established that assignment does not mutate objects but instead binds variables to new objects, while setter methods and indexed assignment do mutate objects.

You might have noticed that we’ve been careful to say “appears to use” instead of “uses”; there’s a good reason for this, which we’ll illuminate below.