First Few Weeks: Lots of frontend, HAML, Sass and Pair Programming.

The first few weeks, sure enough, have been mostly about frontend. Our client wanted to deploy a version of the site that will mostly only display some information - managed by an improvised and fairly cool CMS - and sign up people so that we can let them know when the official launch takes place.

 So yey! first impressions time on real world frontend technologies!

on HAML:

    The templating system favored in Cubox is HAML, which stands for Haiku Markup Language and has a strong focus on clear and simple syntax. Coming from a Python background I loved the concept of haml, it is brief and pretty! Indentation awareness! Gotta love it, right? Surely everybody feels the same way!

Well, much to my surprise there's people (a LOT of people) discouraging the use of HAML in favor of alternatives like Rails native ERB or Slim, flamewars ensued, benchmarks were run time and time again, and a number of interesting discussions where had, at the end of the day.. I still like HAML :).

 Most haml discouragers pointed angry fingers at the fact that it uses significant whitespace and that is apparently somehow evil. While I disagree with this there was another point that *did* make sense and that I can get behind when choosing a templating system: haml is supposed to compile to HTML, yet it doesn't look remotely like it, as opposed to, say, erb. 

While I agree with this and feel that both are valid options, coming from a non-web python-oriented background I am inclined towards haml's simplicity over erb, but I know that haml being a layer of abstraction above html WILL have it's downsides and I've already encountered some situation where its dependance on indentation limits what I can do with it, that sucks but it's a price I'm willing to pay for a pretty templating system :)

Sass (.scss syntax):

 Sass, unlike haml, appears to be unchallenged - or, at least accepted as standard - as far as styles are concerned on the Rails world. Having little to no experience with regular CSS I can only say that sass .scss format appears to be a sane and generally good approach to styles. It is pretty, straightforward, similar to regular CSS thus making it intuitive while adding a number of features that make it significantly more powerful, I am happy with it.

On Pair Programming: 

   The first time I heard about Pair Programming was during a lightning talk by Leo Soto from HashRocket, they really promoted it as "the best way" of developing software, admittedly I wasn't too impressed, or to be more precise: I didn't like the idea at all.

 You see:  I'm the kind of person that needs to repeatedly poke whatever they are learning to see its behavior and to get a good grasp of it, and I do not feel at all comfortable doing this while being closely watched.

 Having said that I have to clarify on two things.

First: Pair Programming is not even close to what I thought it was during that presentation.  It's more like just discussing about your project and the tasks you have ahead of you with a coworker over a cup of coffee, only you do it in front of a computer and actually writing the code that you are talking about, it's really a lot less stressful than what I initially thought it would be, or rather: it's not stressful at all, given a good pair. :)

Second: Pair Programming is not in any way forced on us, the developers on a project (usually two,  in bigger projects up to four) are more or less free to decide how to tackle the project and are basically in charge of it. Sure, we need to be in constant communication with our clients, but (again: given a good client) this tends to make things work smoothly and allows us to organize our workload in whatever way we feel more comfortable given the circumstances, these days I am mostly working on my own, but of course sitting next to my pair and in constant communication with him.


All in all:

 It has been fun learning front end basics and actually finishing a sprint with a delivered product - even if it is a first release, route management in Rails has been mostly easy except for some models that used STI and broke horribly the path helpers,  but all in all routing was not difficult to handle at all and Rails hasn't blocked me from doing my work once I got used to its overly compartmented directory tree.  This next two weeks we will be focusing on  backend features - which promises to be far more fun and educational. We are apparently implementing interaction with a RESTful API and installing Resque into our application for background jobs management. More on that later  :)