codeRambler Ramblings on code, the web, and technology

Tips on converting strings into numbers
Monday August 06th 2007, 10:29 am
Filed under: Javascript, Web development

When you are reading a value from a text input, the value is returned as a string. This is not really a problem for Javascript in that it’s loosely typed and converting the string into a number is really straightforward.

As with most things, there are several ways to do this conversion. I’ve used parseInt() a lot in the past to convert a string into a number (although strictly speaking I am converting to an Integer rather than just a Number when using parseInt()), but recently ran into some strange behaviour that I wanted to understand.

var l_sValue = "07";
alert(parseInt(l_sValue)); // alerts 7

This seems to work fine, the string represents the number 7, and the parseInt() correctly parses it into the integer 7. Now we change the string value and something strange occurs:

var l_sValue = "08";
alert(parseInt(l_sValue)); // alerts 0

This is obviously not the expected result! The solution is to use parseInt() correctly, and pass through both parameters (the second parameter is the number base to use).

If you do not pass in the second parameter (the base, or radix) then Javascript will default to base 10, unless:

  • the string starts with ‘0′, then it will default to base 8 (octal)
  • the string starts with ‘0x’, then it will default to base 16 (hexadecimal)

Because the string we used above started with ‘0′, Javascript defaulted to use base 8. The reason we see 0 being returned from parseInt(’08′) is because 8 is not a valid number in octal (we would count in octal 0, 1, 2, … 6, 7, 10, 11, 12, … 17, 20, 21, …).

Now look what happens when we pass in the second parameter and use (the more familiar) base 10:

var l_sValue = "08";
alert(parseInt(l_sValue, 10)); // alerts 8

Lesson for the day: always pass in the base when using parseInt() to parse a string into an integer.



Memory leaks and closures in Javascript
Thursday August 02nd 2007, 11:57 am
Filed under: Javascript, Web development

The topic of memory leaks reared it’s ugly head again recently and I tracked down several good articles and tutorials that discuss and explain some of their causes (and how to prevent them) quite well.

One of the main symptoms of memory leaking is performance slowdown in the browser (this affects all browser, some to a greater degree than others). Investigations of this type of problem invariably lead to Javascript closures – a very powerful feature of Javascript that is very easy to abuse.

For those looking for an explaination of what closures (aka. continuation by some) are and how they are so important to Javascript, take a look at this informative article at jibbering.com.

There is a working account of one person’s battle with closure related memory leaks titled IE: where’s my memory?. This article links to many good resources, and has a very well thought out explaination as to why closures are so useful in the first place.

Of course there is a formal description at the MSDN Library as well (complete with diagrams, code examples and patterns).

There is a good tutorial on how to avoid Javascript memory leaks at Jack Slocum’s Blog. This specifically mentions problems experienced with the Dojo Toolkit, Script.aculo.us (along with Prototype) and even WordPress (used to power this blog).

After reading all those articles, no doubt you will be itching to refactor your existing code!



When is a task considered to be Done?
Tuesday July 31st 2007, 9:57 am
Filed under: Agile, Javascript, Web development

In recent Agile projects I have been involved with, we often talk about the word “Done”. Specifically we are talking about when a task/story that you are working on is finished.

I heard someone in my team say that “it isn’t Done until it’s in the green column” – referring to the colour-coded columns we move story/task card through as we take them from the “holding pen” through “development” (red), “ui review” (black), “customer preview” (orange) and “qa” (blue) to “done” (green).

So when is something considered to be Done? Is it Done when you have finished writing the code? When you have finished testing the code? What has to happen to a story/task before it is allowed to make the green column and be called Done?

My definition of Done:

  • All code has been developed using Pair Programming or Peer Review
  • The acceptance criteria for the story/task have all been met to the customer’s satisfaction
  • Unit tests have been written that test the code and document it’s functionality
  • Supporting acceptance tests that support the acceptance criteria
  • The code is checked in to the build server – and all the tests continue to pass
  • Any QA issues are resolved (which may necessitate returning the story/task to development again)

Of course each story/task will have a different path to Done, and some will take a shorter route than others – but the definition criteria above should remain constant for all. If you make sure your stories/tasks follow this prescribed course to Done, you will have less “returns” later on and produce better quality code from day one.

You will! Try it and see.



It doesn’t smell right!
Thursday July 05th 2007, 2:38 pm
Filed under: Agile, Javascript, Web development

How often do you refactor your code so that it works better or is easier to understand? Hopefully this is a constant process where you are refining and adapting on a regular basis (note that this is not quite the same as just rewriting code for the sake of it). Recognising that a section of code “smells” and needs to be refactored is not a particularly straight-forward task, some of the signs I use to spot “smelly” code include:

  • repeated blocks of the same code in different areas of the code base
  • huge long “if...else if” blocks
  • variable names that have no meaning or description of their contents
  • function names that are not descriptive of their purpose
  • code that doesn’t have supporting unit tests

Of course there will be different “smells” for different programming environments, I’m a Javascript developer and my “nose” is focussed on how my javascript code performs within web applications.

Have you sniffed your code recently to check that it doesn’t smell?