Thursday, May 31, 2012

So I was remarking to a coworker today that the HTML Canvas API is very low level and hard to use, and his reaction to that was actually positive (and he had a point). By being very low level, it means that pretty much everything is exposed and going forward you won't have to wait for browser vendors to update their libraries in order to get the latest features. Basically, the browser vendors are removing themselves from the equation.

However, application developers are left with a bit of a dilemma. Do we really want to reinvent the wheel every time we build an app? Why is it that you have to redraw everything every frame? Wouldn't it be easier to work with objects rather than pushing pixels?

Well, while the browser vendors might have removed themselves from the library equation, fortunately a number of other people are stepping in. It looks like there are a myriad of 3rd party libraries out there now for manipulating the HTML 5 Canvas, some of which are more sophisticated than others.

I haven't had time to delve into any of them for real yet, but from what I have seen so far, these seem to be the most advanced (as far as being Adobe Flash replacements).

CreateJs - http://www.createjs.com/#!/CreateJS
This looks to be the most complete library out of all the ones I have seen with support not only for Canvas, but also tweening, sounds, and preloading. It also supports a stage object. EaselJs is the part that manipulates the canvas.

oCanvas - http://ocanvas.org/
This also looks good, and the code samples I have seen look very similar to ActionScript. The "o" in oCanvas stands for Object.

Paper.js - http://paperjs.org/
This one also looks interesting. I need to look at it more. They also created a superset of JavaScript called PaperScript for handling objects more easily. Not sure if this is a good or bad thing.

There are a myriad more as well. The only problem with having so many libraries out there is that you need to make sure you choose the right one when you start your project. I am not sure how inter-operable they all are and what would happen to you if you chose the wrong library.

Saturday, May 12, 2012

There are many pluses when working on a side project. You get to work with the latest technology. You get to decide what features go in and what doesn't. You can show it off to potential employers. The list is endless. However there are some tips to remember as well. We will cover these here.

Time management

Unless you are unemployed, your time is now a precious resource, which means that you are now a resource to your own project. Try and organize blocks of time during the week when you can work (i.e. a few hours on Saturday or an hour on Thursday night) and stick to them. Try to break up your work into small chunks and aim to have a feature done in that block. This will help motivate you.

Feature Management

Related to time management, it's important to maintain a list of what you want to do and be able to check items off this list. Ask friends for feature ideas and add them to the list. Save anything that's a large feature for the weekend and try and do the smaller features during the week.

Also while developing your site.app, try and maintain a list of every little thing that is bugging you. If it bugs you, it is sure to bug the user.

You also have to be judicious when you are not actually working on the site in figuring out which features really add value. Remember, your time is not limitless...

Site/App Design

I am not a designer, but I know my way around CSS pretty well. I found Twitter Bootstrap to be a good framework to help me get started. There are tons of resources online as well. You probably won't get the design done in one go so it's important to remember that you will iterate on it repeatedly.

Friends

Your friends are your best resource. Invite them early and get feedback ASAP. They will give you ideas for improvements and features and also help you determine which features to implement first (if everyone asks for the same feature, it must be important). At the end of the day though, you are in charge.

Tests

It is tempting at first to leave out automated unit tests (because, hey, you are having fun right?) and that is fine for a little while, but don't let it drag on too long. Remember that you may be showing this side project to a potential employer, and you wouldn't hire someone that doesn't write tests would you?

That's all I can think of for now, but I will probably add to this as I continue working on my project. Happy coding!

Thursday, May 10, 2012

Ok, this was going to be called "Who do you write code for?" but I was told never to end a sentence with a preposition.

Anyways, I was thinking the other day about who the audience is for the code I write and I came up with the following. Bear in mind I live by the principles of KISS (Keep It Simple, Stupid) and YAGNI (You Ain't Gonna Need It). I developed these attitudes after reading tons of other people's code (as well as my own code 6-12 months down the line.

So in descending order...

1. The User

Obviously you are writing code for someone to use (or a service to consume). I am not going to go into UX or HCI at this stage, just that as far as priority goes, this guy is the top. Make sure the user gets good and timely feedback for everything he does and that the steps he has to take make sense to him.

2. The Compiler/Interpreter

The code you write has to be compiled or interpreted by a computer before the user can use it. Don't worry too much about optimization at first (YAGNI, remember?) but don't write code that you know will perform badly off the bat. Try and stay away of O of N types of loops which could blow up in complexity, follow good OO techniques, and write tests where possible.

3. Your coworkers (or you, 6+ months down the line)

Whenever I come up with a "clever" solution, I ask myself, "Will someone else understand this code without me explaining it to them?". Of course the caveat is that that someone else is also a coder and not a plumber, but I normally think of the most junior developer in the team (in terms of experience, not necessarily age) and whether or not he will comprehend it. Sometimes that person is me (ok, most of the time). The other thing I learnt is that code you wrote 6 months ago, is no longer yours. Someone else who looks a lot like you wrote it, but for all practical purposes it was not you.

4. (and finally...) You

You are at the bottom of the list, but face it, you were really at the top all along. You write code because it's interesting, it's exciting, and it's fun. You like brain teasers and you like solving new and interesting problems and you never wanted to be an accountant (not that there is anything wrong with accountancy, you also get to work with number and you get paid more). So write code for yourself, but remember that you are also at the bottom of the list.

Tuesday, May 08, 2012

So today I have been looking into getting our enormous battery of tests to run faster. I have yet to find anything that works for Cucumber, but I did find an interesting way to speed up RSpec which is detailed here.

Basically, it seems that by not collecting garbage too frequently, you can make your tests run much faster (at the expense of memory management of course). We observed a 30% reduction in the time it takes to run an RSpec test suite.

I did try to implement this on Cucumber, however because we need to store much more in memory to set up and tear down our objects, it meant that I kept running out of memory when I wasn't using the default Garbage Collection and the tests took even longer (so, buyer beware). I suppose if you had a small set of features though you might see some benefit.