Northcoders Bootcamp: Week 3

It’s getting scary how fast the weeks are going by. I can still remember looking forward to the course starting like it was yesterday and now We’ve completed a quarter of it in an instant. I guess it’s a good sign, it means I’m enjoying what I’m doing and I’m focused on it. What a difference with my fours years in uni, but that’s a story for another day (or never, it’s not that interesting).

Front-end-y stuff

The first sprint of the week was dedicated to jQuery, a library so ubiquitous you are expected to at least be familiar with it. The exercise consisted of copying the Twitter interface with Bootstrap and its functionality by pulling data from an API with AJAX requests. Having used Bootstrap before it wasn’t too hard to make a half-decent responsive layout with some panels. Making it look exactly like Twitter is another story, and something my pair and I quickly agreed we didn’t want to spend too much time on. After spending two weeks learning about every aspect of JavaScript, it felt weird to work with something as fiddly as CSS. The most enjoyable part of the exercise was to identify different features on actual Twitter and implementing them on our own version. We added nice touches like the tweet length counter turning red and disabling the submit button over 140 characters.

By the end of day two we had a fairly functional fake Twitter and surprisingly un-spaghetti-ish code (I’m in a makeupwords-ey mood today). We were proud that we chose to made our lives difficult by experimenting with templates (god bless Underscore), we stuck with it and made it through to the other side. We ended up saving a lot of jQuery work and our code looked very neat. As we would learn on Thursday, it could have been much neater.

You can’t handle how sassy this grid is

On day three we did a short sprint focused on the Bootstrap and Sass. The goal was to build a responsive grid of boxes, make it responsive, add some interaction with jQuery and learn about automating tasks with Grunt. CSS is definitely not my strongest suit so I tend to keep the looks of my front end projects as minimalist as I can. We struggled with Bootstrap’s default padding for a while, but once we set everything to 0 we started to place things where we wanted them. Once we added some fancy colours we played with some jQuery effects and settled for mouseover events. The result resembled a pointless Candy Crush clone (even more pointless than the original, which has its merit).

I like that we are not spending too much time on HTML and CSS stuff, they are languages that we need to be familiar with but mastering them is optional, especially if you are not planning on going down the full front-end path. I’m happy to leave that job to people with a better sense of aesthetics than me.

Modules for days

The lessons on Thursday and Friday were my favourite of the week. The instructors changed the format of the sprint to have a couple of sessions on refactoring code some new JavaScript patterns. And to my pair and my surprise, they used our implementation of Twitter. Either we did something right and our code was a good starting point or it was such a mess that it needed professional untangling.

The first concept we learned of was the module pattern, a staple of most JavaScript libraries. It’s basically a way of modularising your code by wrapping it in a function and only exposing the parts that the user will need access to (the public API). By making the function immediately invoked, the public API will sit on your application’s namespace as soon as your program loads. This is exactly what jQuery and Underscore do to give you all that $ and _ goodness. We spent the rest of the day separating the entire application into it’s four main modules, and although it was a bit repetitive I learned to appreciate the power of doing something over and over again to hammer it down inside your brain.

The sprint culminated with the concept of loosely coupled code. The idea that your application should be composed of independent modules so that, when you won’t to change or remove one, the rest of your code won’t be affected by it. This led us to the observer pattern, a way of making modules communicate between themselves without depending on each other by emitting and listening for events. I distinctly remember mouthing “that’s so cool” when I saw it working on the projector screen. I could suddenly see the immense utility of these two patterns put together and my mind started racing thinking of ways of including these new tools in my projects.

What did I learn this week?

This week we shifted towards learning more high-level concepts. With the basics out of the way we have a good foundation to start thinking more about why you write code in a certain way than how. I’m excited and proud of myself for my level of understanding. Everything we’ve learned so far makes perfect sense in my head. I can’t wait to start working on projects.