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.

Moving To California

Hey guys, so it's been a while since I've been active on here. I've been going through some changes in my life/career and thought I would take the opportunity to update everyone.

My girlfriend and I decided to take a jump forward in our careers and move to Silicon Valley. Both being software engineers, we knew that it would lead to very interesting opportunities and would help us grow our careers much quicker then we would be able to back home in Montreal.

We've been here now for several months, and I must say that it's been great! It was a little bit of a rough start, and we are still at the tail end of settling in our new place, but it's been a fun ride so far.

Rainbows and Unicorns

If you're in the tech industry, this place really is the mecca of the industry. The amount of opportunities around is almost overwhelming. I've heard from some that the average time for an engineer to find a job in the valley is roughly 20 min. While I'm not entirely sure how accurate that number is, I can say that it's not very difficult as the demand is very high.

That being said, this also means that the space here is very saturated and as a result, very competitive. While I had heard about it before moving, I must say it feels somewhat surreal to be sitting on the train or at a restaurant and hearing people nearby debating Java vs PHP or why they should move to cloud services. I mean, this just doesn't happen anywhere else - especially in Montreal. Don't get me wrong, Montreal has a great tech community and is really starting to grow as a tech hub. And there are plenty of other major tech hubs in North America (which I haven't yet been to) but I can't imagine the being close to what it's like here.



I'm sure everyone by now knows about the insane costs the bay area incurs for housing. It was actually one of the biggest factors for us when we were debating whether to come here. I mean making more money doesn't mean anything if you have to spend most of it on living expenses. And we both decided that we did not want to sacrifice our quality of life just to live here. But, we found that with both of us working as engineers, we are able to make it worth our while.


To the readers who are thinking of making a similar move in your lives/careers, I will share with you a checklist that I used to know the difficulty level of the move:

  • Do you, or can you qualify for a Visa (TN is easiest, but there are other options)
  • Can you move in with someone to share living costs. A lot of people do this here in order to be more cost effective. You can essentially rent a room/bed/couch/floor – all depends what your comfortable with.
  • See where you stand as far as qualifications and estimate what your salary should be. (Good article here on hackernews on this)

After going through all that, you should have a better idea of what it would actually take for you to make the move. And for what it's worth, if it's a realistic move for you, then I would definitely suggest it. In the short time that my girlfriend and I have been here, I can't say we regret it at all.

The Java Experience

Over the past year, I've gone through some interesting changes. I started working at a company called ViralNinjas as a full stack php web developer. Most of my strengths being on backend development. Over the years, the company has gone through a lot of changes. We merged with a US company in San Francisco - called Sociable Labs. We created a brand new product as a SaaS using a Service Oriented Architecture (SOA). So, we essentially moved away from the LAMP stack to a SOA consisting of: Java, Kafka, Hadoop/HBase, Redis, PSQL for customer configurations with JS and OjectiveC for the clients. Not to mention all the changes we went through in the work force. While all were fun and exciting, the biggest for me - as an engineer - was the move in tech stack.

New and different

Moving to Java was a little intimidating at first. I haven't done any Java since some CLI programs I did back in college. Working on a large and scalable web system would be a whole new adventure. One that I was very interested in experiencing. Coming from years of PHP development would mean that I would have to change my train of thought from a loosely typed interpreted language to a strict/strong type compiled one.

Strong VS Loose Typing


public static int minFunction(int n1, int n2) {
    int min;
   if (n1 > n2) {
      min = n2;
   } else {
      min = n1;
   return min; 


function minFunction($n1, $n2) {
   if ($n1 > $n2) {
      return $n2;
   } else {
      return $n1;

There are obvious arguments for both sides. Strong gives more reliability and generally leads to better code that is easier to maintain and tends to be less buggy. Whereas loose allows for more flexibility and can be easier to write – as you don't have to worry about converting types in order to make things work. While I was coming into the static world from the dynamic one, I immediately noticed the benefit of something as simple as a return type. I found that knowing the types of the input and output of functions was extremely useful. Also, knowing what the types are allows you, as a programmer, to understand what state everything is in at any given point in time. Without it, data can come in as different types (which happens often) and can throw you in a different state - forcing you to have to put type checks everywhere.

There are many other advantages to strongly typed languages which we will touch in a little later, but for me this was a huge positive in favor of Java. At this point, I had decided that I was done with loosely typed languages.

Interpreted VS Compiled

Another advantage of using a strongly typed language is that a compiler can run through it and compile it down to machine code. Meaning execution of your program will be much faster as there is no conversion needed and the computer knows what to expect from the execution of your program. On the other hand, an interpreted language needs an interpreter to run through the code as it is being executed, it evaluates and compiles down to machine code on-the-fly. This generally means slower processing time, but the flexibility of executing different code without having to re-compile.

Aside from the pain of having to wait for compilation (which can take a while depending on the size of the project + dependencies), I still favor the speed and simplicity of deploying a compiled binary file versus an entire code-base to remote server(s).


Here is where my appreciation of Java started to wear thin. Because everything in Java is an object, you start to start to see things like:

Logger logger = Logger.getLogger(loggerName);

Which is fine, but when you keep seeing all these design patterns being used that start to make programming a simple program more obtuse and yield code that is harder to read, I feel like it starts to get more in the way of the programmer then to help them. I had found a really good response to this on Stack Overflow:

What it really boils down to is that verbosity is good when it clarifies the programmer’s intentions, but bad when it just adds noise to a construct that has nothing to do with the programmer’s intentions. I believe that Java has plenty of the latter kind of verbosity.

That is exactly how I feel about Java and it's verbosity.


In conclusion, I must say that working on this project has matured me as a web engineer. Working with SOA and the new tech stack has allowed me to learn about how to build reliable, scalable and better performing web systems for modern applications. It also made me realize how much I prefer strongly typed languages over loosely types ones. Although Java seemed promising at the beginning, I still found some things about it that I did not like. Interestingly enough, during this project, I had also stumbled on Golang. Ironically, it seemed to have all the things that I love about both languages, and none of the bad stuff. It might have been the timing, but once I discovered Go, I immediately felt that it was the language to rule them all!

Take time to design

Taking the time to understand a problem and design a proper solution is the best first thing you can do. During this process, you are essentially defining your program's logic and requirements. This will help you – and any other developer – a great deal when having to develop or use the software. It serves as a map, illustrating a high level picture of how your software works. Also, by exposing a design document before implementation, you will uncover any errors or mis-conceptions that you would have otherwise found during your implementation.

Read More

Time for a change

DISCLAIMER: This article isn't an attempt to start a flame war with php enthusiasts, this is just my honest opinion.

I've been developing in PHP for the better part of 5 years now. Yes, I have touched other languages in my career, but most of my development has been in PHP because there was more of a demand for it.

After five years I've come to a conclusion: I don't like it.

Yes PHP has an easy syntax and a small learning curve. And I know you can quickly build big and complex applications. It's resemblance to C makes it a good language for learning as well. Hell, if you've done even a little bit of C, you can hack up some web app in PHP. But I found that it's strengths are also some of its weaknesses. Because it's so easy to pick up, you end up finding a lot of projects without and proper development style/pattern. Those end up being some of the hardest and worst ones to work on.

Furthermore, as I'm maturing as a hacker, I'm starting to see the beauty in strong typed languages. I've been hacking with Go lately (if you haven't tried it yet, I suggest you give it go - ha!). After working with a strong typed && compiled language, going back to PHP is like going from Tolkien to Seuss. It just feels so much better reading/writing code that tells you what everything is and is supposed to be. Not to mention the speed difference between a compiled language and an interpreted one is un-comparable.

So it's clear to me now that I'm in search of a new fast, strong typed web language to master. My problem is, I don't know which one to choose. Go is really cool so far, but it's still fairly young - although being backed by Google does have its advantages. Another language I was thinking of picking up is Scala. Even though it runs on the JVM, I've heard great things about it.

So I turn to you, my fellow developers. What language do you suggest I try?

Technical Debt (Re-post)

I recently came across a blog post on a very popular topic in software development:

Technical Debt 101 by Maiz Lulkin

Most of the developers I know (myself included) would be the first to advise for a re-write of a legacy application. Likewise, most of the managers that I've worked with are always there to advise against it. They would say things along the lines of "This would take too long, we need this new feature yesterday" or "We don't have the funds or resources to support this right now".

While both sides have valid points (and are probably exaggerating their points for their own cause) the truth lies somewhere in the intersection of both circles in a venn diagram. This article - in my opinion - gives a description of what the venn diagram looks like. Maiz paints a detailed picture of what both sides argue and then goes on to explain what that intersection area contains. After reading his post, my doubts or uncertainness about re-writes have been silenced. A required reading for developers and managers alike.