Monthly Archives: May 2014

Puzzling it Out: What is Middleware? What is Rack?

Yes I know You All Know This

As a newbie to development I always feel like there are a zillion things to learn, and I need to learn them all at once. So far, I have focussed on practical coding – Ruby, HTML, Javascript, etc.  I also expanded out to get my head around coding concepts by doing a couple of CS101 courses (Stanford and Udacity).

However, there are some things which get mentioned over and over again, which I don’t understand, and which aren’t explained in any of my ‘beginner’ courses.

For example. Middleware. Rack. I’m not sure exactly where to get this kind of knowledge, but I keep stumbling across little pieces of the puzzle. Here, I’m putting my pieces together, so I don’t forget them, and so they can start painting the picture.

What is Middleware?

Reference: Rails Middleware Walkthrough on Rails Cast #319

This Rails Cast gives a breakdown on the middleware that is in place with normal Rails apps, and even though what each of those pieces of middleware does was pretty much over my head, a few basic concepts came through, which I didn’t understand before watching this:

Middleware is what goes on between receiving a request from a browser and sending the response from your app.

  • The list of the middleware will be different according to the framework you use, as well as your environment (e.g. development vs production)
  • You can see the middleware in a rails app by going $ rake middleware
  • This will give you a list of classes (and unexpectedly to the Rails Casts guy, also an object in one case)
  • A request will run through each of these classes and then at the end finally run your applications routes
  • Pieces of middleware might do things like “set the HTTP request method based on _method parameter” or “capture the remote IP address for later use”

Middleware and Rack

Again, I don’t know exactly why these things are necessary, but I guess they are necessary to make your app run as expected.

Now, having said all that, the next thing to understand is “Rack”. For which I have these pieces of the puzzle:

What is Rack?

  •  “With Rack, you are officially leaving the world of web sites and entering the world of web apps. No longer are you sending static HTML files to the browser; you are programmatically building HTML on-the-fly to send to the browser.” Techiferous
  • “Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks” http://rack.github.io/ 
  • It contains a full stack of Middleware components
  • “Using Rack Middleware you can build applications that directly interact with a HTTP requests environment and can be plugged in Rails, Sinatra, and many other Ruby based Frameworks.” A Rack Introduction
  • Rack is one of those ‘bare minimum components’ that you need for creating modular web applications. A Rails app is actually a collection of Rack and Rails middleware components that work together to form the completed whole.
  • In rails a .ru file is a rackup file

I can’t find one individual resource on understanding these things because I don’t understand a lot of what is said in those casts/blogs. However, I’ve rummaged around and found out enough for now to satisfy my curiosity.

Leave a reply

My Git Workflow – Beginners

So for a year, I’ve been trying to learn to use Git and Github effectively. It hasn’t been easy for me. It seemed like my brain just wouldn’t work that way. However, I feel a lot more confident recently, and I’d say the biggest steps to my improvement in Git usage (apart from just not giving up) was reading “The Git Book”. Something about this really helped things click with me, and I can’t recommend it highly enough. I’m not even finished reading it, but already I am using a work flow in Git and not being so scared.

It also helped to keep at it, using it in a few different ways with a few different people – yet again the super helpful and patient Ruby community in Sydney comes to the rescue.

Here I am just going to record the current steps I am using in my Git workflow, so as not to forget.

Branch Structure

I am having ‘master’, and not doing anything on it.

I have a ‘develop’ branch, from which I branch to do each little bit of work, and then merge each one into ‘develop’ before I move on.

My branches off ‘develop’ are called things like ‘feature/view-refactor’.

Git Steps

Starting on ‘develop’ branch

  1. $ git branch feature/feature-name #create new branch
  2. $ git checkout feature/feature-name # move to new branch
  3. $ git push -u origin feature/feature-nam #this makes sure my remote has this branch to track
  4. Do some work
  5. $ git diff # Look at the work I’ve been doing.
  6. $ git add
  7. $ git commit -m “try not to leave a useless message”
  8. $ git push
  9.  Then in GitHub I did a pull request from that feature branch to develop
  10. Merge  while in Github
  11. Github lets you delete the remote branch
  12. $ git checkout develop #On my machine, switch to the ‘develop’ branch
  13. $ git pull #pull changes from origin
  14. $ git branch -d feature/feature-name #deletes the branch on my computer
  15. $ git fetch –prune # so that on my machine it removes mention of the old branches on the remote

 

Leave a reply