iToto's Blog

A Montreal based full-stack web developer who loves learning and trying out new things. This blog is my attempt to document my work as well as a place to discuss ideas or topics that I find interesting. Feel free to follow me on linked social networks.

Fork or Die

For those who use git as their scm, you probably are familiar with the term forking. For those who aren't using git yet, do yourself a favour and learn it, you'll thank me later.

Fork, what?

If you are unfamiliar with the term, all it means is to make a "copy" the repository for your own development. This is very common in the open source community as contributors come and go frequently on projects.


Say you're browsing a project on GitHub. You realize that this project is missing a good encryption function. All you need to do is fork the project, develop your kick-ass encryption function and then submit a Pull Request to the project for the owners to review and merge.

Why should I fork?

When people first come to git from other scm/vcs alternatives, they instinctively think that forking is an un-needed process. This is common from those coming from a centralized scm such as svn or cvs.

There are tons of reasons why you should fork, to name a few:

  • Keep your main repository clean with only main branches containing stable code.
  • Avoid endless merge conflicts from contributors stepping on each other's feet.
  • Contributors feel less intimidated working on their own copies.
  • Setup hooks on main repository for deployment to environments.
  • Added security as you can set tight permissions on the main repository.

As git is a distributed scm, the notion of creating a copy of a repository fits well into it's design. The idea is simple: As a contributor, I work on my changes locally, then push them up to my own private remote. Once I'm done with my feature and feel it's ready to be added to the main project – that all other contributors have access to – I create a Pull Request from my fork to the main project.

What if I'm the only contributor?

As long as your project needs to be deployed to an environment (production/staging/etc.) then you should be forking. The idea is to keep your main repository clean and stable (for your deployments) and use your fork for development. With this, it doesn't matter if you're 1 or 100 contributors.

Sweet! When can I start forking?

There's no better time then now! Head over to GitHub and fork to your heart's content. Once your comfortable with it, be sure to start doing it at your work place. Your colleagues will probably bring you cake!

cake is a lie

Google Chrome's User Switch

I was recently shown the user switcher in Google's Chrome Browser. This feature allows you to have multiple browsers open under different google accounts. We happen to use google for our company accounts and so I now have one browser opened with my work account, and another with my personal one. This allows to keep work and personal stuff separated - which is fantastic!


For those who don't already know about this, you can setup multiple accounts by doing the following:

  • Go into the browser's settings and click "Show advanced settings..."
  • Under "Users" click the button "Add new user..."
  • Enter your credentials

You should now see a profile on the top right of the browser with the active user for that browser instance. To open a new browser under your other accounts, simply click on the user and select the account you'd like to switch to.

Switching Active Users

TDD and clean development


Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.


Why I started doing TDD

There are two reasons why I started doing TDD:

Firstly – like everyone else – I've been noticing the buzz around it and how people rave that "everyone should be doing it". So I figured I'd like to find out what all the fuss was about.

Secondly, I recently started a new job where my team wants to start doing TDD on all new project. Fully supportive of this notion, I was assigned a new project and started my TDD adventure. What better way to start TDD then on a clean slate, right!


The part that attracted me the most to TDD is that it forces the developer to work around unit tests. In my honest opinion, unit tests are a critical part of software development. It gives the developer a sense of security that the code they just added didn't break existing functionality. When working on large projects with other contributors, stepping on people's toes is imminent. In situations like this, unit tests - along with continuous integration – can be like guide rails to help keep you in bounds and prevent you from releasing a new feature that might have inadvertently broken a existing features.

First Impressions

One thing is for sure, getting into the discipline of writing tests before writing any logical code takes some time. Especially for me, as I'm one of those devs that likes to start writing some code as soon as possible. But, once you get the hang of it, it's actually really helpful. It forces you to put some thought into the design of your code before you start writing any. The workflow that I'm currently using is:

  • Start off by drawing a quick high-level data flow diagram.
  • Class design with functions needed (just the stubs).
  • Write my unit tests for each of the functions.
  • Start implementing the functions.
  • Commit on the completion of a passing unit test.

Clean Development

I also started using Grunt for running some general tasks.

Successful Grunt output

Lint and Code Sniff errors

Unit Test Errors

These tasks consist of

  • Running unit tests
  • Checking for syntax errors
  • Code sniffing for PSR2 code style validation

Coupled with a pre-commit hook, I am now sure that each commit is clean and free of careless errors. Code sniffing also allows for the codebase to follow a standard and prevents the project from turning into some scary mishmash of all the developer's preferred coding styles. For those interested, I created a initial Laravel 4 framework with my grunt setup on my GitHub. Feel free to fork it.


I really feel good about working with my new workflow. Knowing that my code is automatically being tested, sniffed and linted before each commit is comforting. Also,TDD keeps me on track with which functions I have to implement and what they should do.

If you're a developer thinking of whether or not you want to jump on the TDD wagon, I suggest you wait for the opportune moment and give it a shot. It might be frustrating in the beginning, but once you get used to it, it's really effective. I find myself becoming more productive as I have become better at writing tests, implementing and re-factoring my code and thinking before coding. It really is an efficient way of writing code.

Jump to Android?

With the recent release of the Nexus 5, I've been really tempted to make the jump to Android. Google seems to be doing a really good job of competing with Apple by releasing their newest phone at half the price. There are two main concerns I have with switching to android from iOS.


With most of my friends and family using iPhones, most of my messaging is in blue instead of green. By switching to Android, I would be losing that convenience. However, with the release of KitKat, they seemed to have integrated hangouts into their SMS app. And hangouts is basically my second most used IM protocol. And with the habgouts app on iOS, I still still get to communicate with all my iPhone friends!

Screen Size

I don't know why, but it seems people like having big phones. I feel like every new phone that comes out is thinner but larger then the previous model. And people like it. It baffles my mind. How can anyone enjoy holding a pad of paper up to their ear. Now with the rumors that the iPhone 6 will most probably be joining the large screen party, the jump to a larger phone is no longer avoidable.

There's not doubting that the top two smartphones on the market today are either running Android or iOS. The only difference is, Android devices offer different flavors of the OS depending on the device. And the reason for this is while Android is open source, Google has been keeping it's cooler features for it's own hardware and left it up to the other Android adopters to implement their own flavors of the functionality. And it seems this will be extremely obvious in the latest KitKat release on the Google Nexus 5.

Ars posted a really good article on this topic: Google’s iron grip on Android: Controlling open source by any means necessary

After reading that article, it seems that the top two phones will eventually be the iPhone and Google's Nexus (as the Android flagship device). That being said, I'm still on the fence about making the switch, but I must say that this is the closest I have ever gotten to making the switch. My girlfriend was lucky enough to get an order in for the Nexus 5 on release day. I'm planing on playing around with it before I make my final decision. I will keep you guys posted on what I decide to do.