Meet our Geeks: the Coding Freaks

We threw a couple of questions to our website developers (a.k.a The Nerd Herd) to pick their brains on how it was working on TrafficDito. Of course, they insisted that they have a Q&A… boy band style. Yeahhh.

Here are some snippets from our imaginary press conference:

Q1: Give me a quick rundown of the role you played in building TrafficDito.

Padi: Aside from cleaning tables and computer desks, I program from front to back end (well, everyone in the team does). That means I’ll code for a while in JavaScript, then hop on down the stack to do some Ruby, making sure everything works. When I have extra time, I test the app by running along EDSA to report traffic. :D

Mil: We all share the responsibility of working on new features, fixing bugs, and maintaining the server. Personally, I’m in charge of setting up the Jenga tower, dealing cards for Pusoy Dos and doodling on the white board.

Patrick: As the others said, everything’s a shared responsibility. Other than that, I’m pretty good at keeping my chair extra warm.

Gerald: I’m also the demolition guy when we play Call of Duty. :) 

Q2: Given there are four of you, how did you work on it all together? (As a side note, who has the messiest workstation?)

Padi: We all sit next to each other in an open workspace, so we can just hop from one workstation to another to check each others’ code, ask questions, or just have general fooling around. As for messy workstations, I quote my good pal Albert Einstein: “If a cluttered desk is a sign of a cluttered mind, what’s an empty desk a sign of?”

 Mil: Our team practices agile development. We specifically practice XP (or Extreme Programming for our non-geek audience) software development methodology. This means we work in short development cycles, called “iterations”, each lasting a week. Every start of the iteration, we plan on which features or bugs to work on. We call these “stories” and we give each of them a point value, depending on the amount of effort that is needed to complete the story. The point value of the stories will determine how many stories we can comfortably fit inside an iteration. Once we have all that planning done, we then program in pairs for stories with high points and we work individually on the stories with low points. Regarding the messiest workstation, I won’t name names but let’s just say someone was able to build a tower out of Coke Zero cans on his desk.

 Patrick: When it comes to pair programming, one of us would code, and the other would be analyzing how the code would work. We also check each other on Github using pull requests to make sure that everything’s ready for production. I also think that I have the cleanest desk (sarcasm).

Gerald: As an agile team, it is very important for us to work closely together. This means sitting together at only one workstation, discussing stuff at the whiteboard, and talking to one another a lot. We’ll even get the product team in on our discussions to make sure that what we decide is the best decision for the product, not just for us developers.

Q3: How different is the website today from how you envisioned it on day 1?

Padi: TD’s pretty different now compared to the initial design. As we were building the site, a lot of different challenges came up that we had to react to. But as agile ninjas, addressing the challenges and subsequent changes was easy.

Mil: The UI design has changed a lot from when we first started, mostly because of the change in business needs and a bunch of other factors. But we were able to adapt pretty well without having spilled too many Coke Zeros.

Patrick: We decided to postpone many of the original features to polish our report filtering algorithm and make it even more useful for gathering reports.

Gerald: In an agile environment, it is rarely the case that the first plan of action is also the final. During development, we often had to take into consideration changes but all them were directed towards one goal: to make it easy for people to save themselves from Manila traffic. :)

Q4: What programming languages or frameworks did you use for the development of the TrafficDito website?

Padi: Ruby, Rails 3, JavaScript, jQuery, HTML5, and CSS3. Just to name a couple, teehee. :D

Mil: TrafficDito was written in Ruby 1.9 using Rails 3. The frontend voodoo magic was written in JavaScript using the jQuery framework.

Patrick: It’s important to mention testing tools too, right? We used RSpec for unit testing our Ruby code and Jasmine for testing our JavaScript code. To make sure it all plays nice together, we used Cucumber for acceptance and integration testing.

Gerald: Rails made it a piece of cake to start the project and and quickly iterate out our features. Testing and throwing in Jasmine in the mix to cover all sorts of JavaScript scenarios… that was a big help. 

Q5: What were the technologies involved in the development of TrafficDito? Also, what tools/software would you guys use on a daily basis?

Padi: We mostly use Macs for development for their simplicity. Plus the Ruby community loves them like chocolate cake. Our text editor of choice is either Vim or TextMate, depending on how hardcore we feel that day.

Mil: We used any POSIX system that we can use but most of the time we’re on Macs. For version control, we use Git, which really helps in a team enviroment. That way our changes don’t interfere what another pair is working on for that day. Plus it’s decentralized, meaning we don’t need internet to use it. And our internet goes down. A lot. Huhuhu.

Patrick: Since we were handling thousands of tweets every hour, performance was a primary concern, so we chose MongoDB over other database technologies. It lets us quickly process tweets and other reports coming from our iPhone app without much overhead. And if we needed to scale later, it will be less difficult to do.

Gerald: We use a lot of online collaboration tools in our daily work. Github is a big help, letting us comment on each others code and review others’ changes. Campfire is the place you’ll find us posting silly images to one another. We also IM our seatmates just for fun. :D

Q6: What design/programming philosophies did you follow while developing the website?

Padi: We ALWAYS write tests first before we start writing any production code. This practice is called Test Driven Development or TDD (very awesome!) The premise is to ensure that all production code is working as expected and will never break. Manual testing is VERY time consuming and can be tedious work. To solve this, we write automated tests that we run with every change. We also use a continuous integration (CI) server to ensure that the current code is always production ready, even as the team makes changes. Never leave home without your tests!

Mil: We also follow the YAGNI principle. YAGNI means “You Ain’t Gonna Need It”. This principle tells us to code only for features and functionality that is currently needed. The goal is to focus and deliver, which too much complexity can hinder.

Patrick: That test driven development thing makes it easier for us to sleep at night, not having to worry something will explode in our server room.

Q7: Can you name a particular instance that turned out being harder than you thought it would be?

Gerald: We encountered a bug wherein Firefox and our other browsers were rendering fonts differently. After hours of searching, I later found out that Firefox attempts to make a false bold font when there isn’t any provided. This led to the bad typography. It was the first time I had encountered a bug in Firefox that was not present in IE!

Q8: What were the most valuable learning resources you would refer to while developing the website?

Padi: Google, Stack Overflow, The Rails 3 Way, The RSpec Book

Mil: Google, Teammates, Stack Overflow, Rails 3 Way, RSpec Book, Beginning Ruby and other books about Ruby programming.

Patrick: Throughout the project, we have all out support from our teammates. We also us a lot of books, tutorial videos and online resources.

Gerald: Google and programming cookbooks.

Q9: If you could describe yourself as a line or two of code, what would it be?

Padi: %w(Padi Marc Rendl).each { |name| puts “Hi! I’m #{name}!” }

Mil: #mil.ninja { color: #000; visibility: hidden; }

Patrick: [80, 97, 116, 114, 105, 99, 107].pack(‘c*’)

Gerald: Factory(:awesome_developer, :username => “Gerald”) 

Q10: Anything you want to say to new/aspiring developers out there? What about the legion of adoring TrafficDito fans?

Padi: Code with simplicity and eloquence. Solve your problems in the most simple way possible so you don’t have such a complex code base. As Albert Einstein said, “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.”

Mil: At whatever you really love doing, just be sure to give it your all and aim to be the best at it. It may need some time and a lot of courage but it will be fruitful at the end.

Patrick: “The scientific man does not aim at an immediate result. He does not expect that his advanced ideas will be readily taken up. His work is like that of the planter — for the future. His duty is to lay the foundation for those who are to come, and point the way. He lives and labors and hopes.” - Nikola Tesla 

Gerald: For TrafficDito fans: Don’t report that you’re stuck in a traffic jam along Ped Xing.

I tried to get more out of the guys but apparently they had scheduled a Call of Duty deathmatch an extremely important meeting and had to cut the interview short. These guys play around a lot but when crunch time comes around, count on them to do whatever it takes to get the job done.

Now if you’d excuse me, I’m being called for that, uhhhh… meeting.

-EJ, Product Marketing Padawan