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: application

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.

Project update

It's been a while since I announced an update on my project, so here's a small yet important one:

I have finished the first revision of the API and have commenced the development of the iOS client. Furthermore, I have launched a web page for those interested in seeing what the app is about - the link will be at the bottom of this blog post.

As far as the client goes, I'm going to try something new. In my experience, apps run best when written natively for the device. However, I have been hearing of the advancements in HTML5 with application development. While it would be easier for me to make the app in HTML rather then to build it natively, I still want to learn more iOS and objective-c. So, I have decided to do both, concurrently!

One of my friends volunteered to make the HTML5 version of the app while I make the iOS version. We will do a performance comparisons and attempt to gauge which of the two is performing best. I will release our findings on here throughout the development cycle.

If all goes well, I'm hoping to use the HTML5 version for all other platforms (Android, Blackberry, PC, etc) and keep the iOS version done natively. This will allow me to always have a handle on the differences between native and cross platform applications.

Also, from now on I will try to write a new blog post every Sunday with updates from the week. Hopefully it will force me to get more done during the week and also to keep my blog active :)

Be sure to check out Party Stream for the beta sign-up. Once the first version of the client is ready, I will be releasing it to beta subscribers for closed testing.

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.