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.

Filtering by Tag: web dev

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.

TDD and clean development

Definition:

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.

Wikipedia

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!

Overview

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.

Conclusion

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.

The Evolution of Web Applications

I have been developing web sites/apps for almost a decade now. The thing I love most about web development is that it's universal. The majority of web applications are supported on almost any platform. In a world where people are more openly using their platform of choice, this is a huge advantage. It ultimately allows us to have one code base that be executed on any platform. This is the general idea behind things like PhoneGap. All a web app needs to run is a decent and recent browser.

The Modern Web Application

Web applications have come a long way in recent years. In the beginning, applications only had interface with one client - the web client. This meant that developers only handling web requests that came from the views they developed (usually in the same framework). These days however, it's all about applications interfacing with other applications. And with the addition of mobile, web applications are more in demand as ever!

To adapt to this change, web applications are now broken up into two parts: an API and a Web Client. This modularization exposes a generic server-side application that can essentially communicate with any client-side application. I call this a service/client model. When I first started to develop with this model, I began to appreciate web applications a whole lot more. These days, if I'm making a web application, I try my best to fit the application in the service/client model.

The Move To JavaScript

Most of the web applications that I have written have been in PHP with frameworks like CakePHP, CodeIgniter and Laravel 4. The issue with these frameworks is that while the server-side scripting is all in PHP, the client-side scripting is done in JavaScript. This forces developers to either learn both languages, or leave the JS part to developers that are stronger in it (which is where the front-end/back-end developer division starts). I personally believe that any good web application developer should be able to work in both.

What would be great is if web applications used the same language throughout the stack. Well, if you're a JS developer, you're in luck!

With a server side application running on node.js and client-side applications running in frameworks such as backbone or angular you can now switch between back-end and front-end development without changing languages. Furthermore, if you use MongoDB as your data store, you can now have a full stack running on JS!

On top of that, node also introduced something else to web applications that wasn't really possible before (or at least not as easily achieved) Web Sockets! This allows for full duplex communication between the clients and server (no more polling!). Web sockets takes web applications to a whole new level. With it, it's now possible for clients to get updates in real time.

To further on this, I came across Meteor - which essentially is a web application platform that allows real-time communication between clients and the server. When I saw this, it furthered my belief that this is the future of web applications. The age of clients polling the web server for updates will soon be a thing of the past.

Another example of this is emberjs. Man, there are so many new JavaScript platforms it's a little overwhelming lol.


Further Reading

This blog post goes through the evolution of web applications as I tried to depict in this blog post.

Pushing for change: why the old way might not always be the best way.

If you’re looking to start a new application – let’s say a web app; you have one major decision to make before you start developing: what will your app be written in? 

There are many answers to this question, eg: PHP, Ruby on Rails, Backbone.js, Node.js, Pearl,  Java, ASP and many more. Each have their pros and cons, so ideally you’d like to chose the one that best suits your needs. I’m not going to go through each of the platforms because that would take forever. However, I will separate them into two general categories: Legacy and New-Age.

Legacy (PHP, Pearl, Java, ASP etc.)

These are the languages that have been around since the beginning of web development. They’re tried, tested and true. Most large companies tend to use them because they generally have tons of documentation or are very well supported. I’d like to think of these are the well rounded and safe solutions because they can do anything in a “good enough” manner.

New-Age (Rails, Backbone.js, Node.js, Closure etc.)

These are the languages that have been created as a result of the web application age. They aren’t as well documented or supported as their legacy counter-parts because they just haven’t been around long enough. They are generally used with companies that like to innovate and push the envelope by creating cutting-edge products. These platforms, however, are not as well rounded as the former solutions. These each have some flaws, however, what they do well, they do exceptionally well. 

I’ve been in both of these situations. I’ve seen the pros and cons for both sides and have had to deal with the development of both kinds of products. As a result, I have made some observations that I’d like to share:

Playing it safe is generally a good idea if you want to create something fast and use existing products. If you’re looking to release as fast as possible and don’t care about creating cutting-edge software, this is your best bet. A plethora of documentation is just a google query away and you can probably even find most of the code that you would need already done. Also, because most programmers post or release a lot of open-source code, you have years of R&D from others at your fingertips that will help you finish your product.

However, if you’re not scared to learn new technologies and are comfortable with finding new ways of doing old things then New-Age is the way to go. 

Personally, I lean towards the latter. The world we programmers live in is one that is always expanding and where we crave to use the latest and greatest technologies. These technologies wouldn’t get any better if no one used them. In-fact, the legacy platforms wouldn’t be where they are today if nobody used them and, as a result, improved them. Therefore, I like to use the newest stuff whenever possible. Obviously I’ll use the solution that best fits my needs, but if there is at least one viable solution in the New-Age pile, I’ll take it.