Liam McLennan

October 2010 Entries

JavaScript Functional Programming Support

JavaScript was created to add interactivity to Netscape 2.0 back in 1995. A consequence of this limited scope is that the language was given only a minimal standard library.

Should you ever try to solve a significant problem with JavaScript you will quickly feel the need for more advanced library methods than what JavaScript provides.

Underscore.js

Underscore.js is a library of utility functions for JavaScript. Most of the functions add functional capabilities to JavaScript. Simply add a script reference to the underscore.js library and then access the functions directly off the _ variable (the functional style) or by wrapping a collection (array or object) with the _ function (the object oriented style).

Here are some examples:

// find the largest number. Functional style.
var largest = _.max([4,3,1,-9]);

// sort by relevance. OO style
var sorted = _([
  {name: "result 1", relevance: 7},
  {name: "result 2", relevance: 3}
]).sortBy(function(result) { 
  return result.relevance;
});

// count the words in a song. From 
// http://documentcloud.github.com/underscore/
var lyrics = [
  {line : 1, words : "I'm a lumberjack and I'm okay"},
  {line : 2, words : "I sleep all night and I work all day"},
  {line : 3, words : "He's a lumberjack and he's okay"},
  {line : 4, words : "He sleeps all night and he works all day"}
];

_(lyrics).chain()
  .map(function(line) { return line.words.split(' '); })
  .flatten()
  .reduce(function(counts, word) {
    counts[word] = (counts[word] || 0) + 1;
    return counts;
}, {}).value();


HTC Desire vs HTC Wildfire

desire_v_wildfire I had a HTC Desire for nearly six months. Sadly, about a week ago, it passed away. The desire was my first smart phone and I think it’s true what they say; the first love is the deepest.

HTC-DesireThe desire was an excellent phone, I have no complaints, but it was a mistake for me. I like to jump off boats, walk in the rain and generally not have to obsess about protecting an expensive electronic device. The desire was my business phone so once the autopsy was complete it needed a replacement quickly. I called my carrier and they told me I could have a new phone for $720. No thanks. So I went looking for a cheaper alternative that still has all of the features I require.

In the end I settled on the Desire’s kid brother, the HTC Wildfire. The wildfire is currently selling for less than half the price of the Desire. It is another Android/HTC Sense phone but with less memory, a slower processor, and an inferior screen.

The Good News About The Wildfire

1279650634-35Apart from 3d graphics and high-res video the Wildfire can do everything that the Desire can do; the Desire just does it better.

It can run apps, manage my email, surf the web, watch flash movies, make phone calls, use SMS and provide high speed internet access to my laptop. Also, the wildfire is a slightly more comfortable size, has significantly better battery life and a superior power button (the power button on the Desire is too easy to activate accidentally). For the price ($350) the Wildfire is a terrific smart phone.

Why I Wish I Still Had A HTC Desire

The wildfire’s interface is noticeably slower, the text rendering is awful and the reduced screen area occasionally causes problems on interfaces that were clearly designed for a larger screen. Of all the inferiorities of the wildfire it is the screen that bothers me the most. It simply looks terrible in comparison to the Desire.

Summary

With my current carrier both of these phones are available on a $49 plan, so you would be insane to chose the Wildfire. However, if I had to pay for the phone I’d get the Wildfire and give my wife the spare $450 to spend on something pretty.

Code from my Ruby Presentation

These days it seems that everyone has a crush on Ruby. I presented two sessions at this year’s Adelaide Code Camp: BDD with StoryQ and I Am IronRuby. After the standard IronRuby demonstration (creating a new project and scaffolding) I showed off some of what I like about Ruby. I started with a file containing Ruby comments describing nice features of the language. Then I worked my way through the script writing the Ruby to demonstrate each feature. The result is similar to my JavaScript Koans, but without the executable tests.

I hereby invite you to publish something similar in your language of choice.

# ruby is a scripting language

# code in a file is executed when it is parsed
puts "I am alive world"

# variable declaration
person = 'liam'

# string interpolation
puts "#{person} is alive"

# class definition
class Person
	
	#constructor
	def initialize
		# member variables
		@name = 'liam'
	end
	
	def name
		# implicit returns
		@name
	end 

	# method definition
	def do_something
		yield self
	end

end

# blocks 
liam = Person.new
liam.do_something do |person|
	puts person.name
end

# dynamic
def liam.age
	27
end

puts liam.age
puts liam.send('age')

# destructuring assignment
a,b = 1,2

puts a
puts b

# arrays
trolls = ['Ted', 'Bill', 'Bert']
trolls.each do |troll|
	puts troll
end

# other functional methods
big_trolls = trolls.map {|troll| troll.upcase}

# methods defined directly
def print_trolls(trolls)
	trolls.each do |troll|
		puts troll
	end
end

# optional parenthesis
print_trolls big_trolls

# all statements return a value
odd = true
print(if odd 
			"3"
		else
			"4"
		end)

# ranges
(1..5).each {|number| puts number}
('a'..'z').each {|letter| puts letter.upcase}

# first class regular expressions
if  /fox/.match "quick brown fox jumps"
	puts 'contains fox'
end

# substitution
puts("I am a cat person".gsub /cat/, 'dog')

# inverse conditionals
six_equals_nine = false
puts "6 is not nine" unless six_equals_nine

# OO style null checking
you_got = nil
puts you_got.nil?

Startup Idea #9274: Personal Accounts Payable

Manage Your Bills Better

For some reason I have a strong desire to be involved in a startup. Ok, I know the reason. It’s a game, with winners, and loser. Like Monopoly, or gambling. And games are fun!

The internet is littered with my failed attempts; from intelligent email marketing for real estate agents, to a route planner that solves the travelling salesman problem. And don’t forget my twitter customer sentiment analyser. That one was surprisingly simple to build and a lot of fun, but it could not deal with sarcasm. The application processes at tweets like:

Thanks ACME for setting my face on fire

and because sarcasm pretty well defeats bayesian classification that tweet is interpreted as a positive recommendation. I digress.

I can build software but I’m missing two important pieces of the puzzle. I don’t know what to build, and I don’t know how to sell it.

What To Build?

This time around (startup idea #9274) I decided to focus on the clichéd advice to solve a problem you have.  As a small business owner and human being one of the things I dislike, and sometimes struggle with, is managing my bills. I could have bought a new car with the amount of money I have spent on overdue payment fees. To manage my cashflow I often need to delay payment until close to the due date, but that relies on me keeping track of the due dates and remembering to pay on time.

No. This aggression… will not stand.

For my own use, as an individual and as a small business, I want an application to help me keep track of my bills. Building a startup on this idea is making a bet that other people want that too.

The features that I have in mind for a first release are:

  • track bills – both recurring and one off
  • provide notification when bills are coming due

the next priority after that:

  • provide notification of time periods where large amounts are due, to help with cash flow forecasting

Some progressive organisations already offer bill delivery via email. Eventually, I would like bills to be delivered with a qr code that describes the bill. Users could then scan the code to avoid data entry. That is a win all-round because it helps the supplier to get paid on time.

How to Sell It

Still don’t know this one.

Teamwork

Paul Graham says that statistically, startups with a single founder almost always fail. My own back catalogue supports this conclusion. Therefore, I want to find a co-founder for this project. Mr Graham suggests that “finance software for individuals and business” is a cracking good market, so we are practically guaranteed to succeed.

Why Server-Side JavaScript?

Chris Nicola left this excellent comment on Justin Etheredge’s blog:

Even with a competitive way to do SSJS [(server-side JavaScript)] on the Windows platform, I just have to ask... why would anyone?

Server-side JavaScript means that the server portion of a web application is written in JavaScript. Personally, I believe that server-side JavaScript will be the next big advance in web development.

If I were Microsoft I would be looking to hit a touchdown out of the ball park with server-side JavaScript, to win back the respect of the more advanced web development community.

Here are some of the reasons why server-side JavaScript will win.

Homogenous Programming Experience

With server-side JavaScript (SSJS) you can use the same language on the server, on the client and over the wire (JSON). JavaScript is even deeply integrated into a number of database platforms. This lowers the concept count for web development and reduces the need for context switching.

JavaScript Runtime Engines

There is a large and ever expanding list of quality, cross-platform JavaScript engines. Every browser contains a JS runtime and there is currently a gold rush on JS performance improvements.

Performance

If you have ever seen IE6 I know you will have your doubts, but JavaScript is fast. Not fast relative to C, but fast relative to languages with comparable features, and it is getting faster.

Interpreted Language

You are too old for training wheels, and programming is too old for a compilation step. Now that we know the benefits of agile, and TDD, and rapid feedback loops, an interpreted language is a big advantage.

Easy Metaprogramming

Dang!! The JS array type doesn’t have a filter/where method. Let’s add one:

// predicate is a function that accepts one parameter and returns a boolean.
Array.prototype.where = function(predicate) {
    var derivedArray = [];
    for (i = 0; i < this.length; i += 1) {
        if (predicate(this[i])) {
            derivedArray.push(this[i]);
        }
    }
    return derivedArray;
};

Now I can filter to my hearts content:

var numbers = [1,2,3,4,5,6];

var evens = numbers.where(function (number) {
  return number % 2 === 0;
});

// evens = [2,4,6]

or, I can modify an object on the fly.

var person = { 
  name: 'Dave' 
};

// add a method to an existing object
person.isAnonymous = function() { 
  return true;
}

Just like Ruby I can overwrite object properties at will, so mocking frameworks are not necessary:

// overwrite methods for testing
person.isAnonymous = function() {
  return false;
};

Easy Reflection

If metaprogramming is easy then reflection had better be easy too. The JavaScript for loop can enumerate the names of the properties on an object:

for (var key in person) {
 write(key);
}

// output is 'name'  'isAnonymous'

It is also easy to invoke functions on an object:

for (var key in person) {
  if (typeof(person[key]) === 'function') {
     person[key]();
  }
}

I used this technique for my JavaScript Object Builder.

Object Literals

As demonstrated in some of the previous examples JavaScript has a powerful object literal notation:

var movie = {
  actors = [Bob, Jill],
  budget = {
    currency: 'AUD',
    amount: 3000000
  },
  name: 'The White Whale' 
};

JavaScript as a Virtual Machine

I already linked to some information about JavaScript as a Ruby Virtual Machine. There is also scope for JavaScript to host other, prettier languages such as CoffeeScript.

CommonJS

JavaScript has traditionally been confined to the browser and supported by an extremely limited library. To address this issue in a standard way the CommonJS specification was created to define a common set of JavaScript libraries.

The State of Server-Side JavaScript

The language, libraries and the runtime engines are ready to go, but the web development frameworks are currently fragmented and incomplete. There are several which I will be keeping an eye on. Hopefully, within the next 12 months it will be practical to chose JavaScript as your server-side language.

If you are interested in learning the basics of JavaScript try my JavaScript Koans.

.NET Ruby Love

There is a good deal of Ruby envy among the more outspoken .NET developers. This post is an attempt to aggregate the many blog posts from .NET developers expressing their love of ruby.

Rob Conery

Why I Like Ruby

Why I Like Ruby, Part 2: Blocks

Contrasting Ruby and C# Using My College Friends

Scott Bellware

Ruby For .NET Developers

Justin Etheredge

What is so great about Ruby?

Jeremy Miller

Silly thing I want from Ruby in C#

David Tchepak

Essence and ceremony, Ruby and C#

John V. Petersen

Why I Love Ruby

Davy Brion

Why you don’t need dependency injection in ruby

I don’t know how this blog is going to evolve

I know there have been a lot more of these but this is what I could find quickly. If you have a good link that belongs on this list leave it in the comments.

Oz Alt.Net Coding Challenge

Michael Minutillo posted the texas hold ‘em coding challenge to the oz alt.net mailing list. The challenge is to write a program that can take poker cards as input and return information about what hands players have and who is the winner.

Solving this problem in my 9-to-5 language (c#) is not interesting to me, so I chose to do it with my beloved CoffeeScript.

Compiling CoffeeScript

The first challenge I faced was one that I have been working on for months – how to compile CoffeeScript on Windows. CoffeeScript has no runtime, it must be compiled to javascript and the supported engine for doing this is Node.js, which doesn’t work very well on Windows. Following much trial and error I eventually settled on a JavaScript environment based on jslibs put together by Alisey Lebedev. I use a slightly modified version that makes it easier to compile multiple CoffeeScript files at once.

TDD

Exercises like this one lend themselves to TDD. CoffeeScript compiles to JavaScript, and there are many test frameworks available for JavaScript. I chose QUnit because I am familiar with it from my JavaScript Koans work. QUnit allows me to write tests like:

module('card');

test('construction', function() {
  var two_clubs = new Card('2c');
  equals(two_clubs.index, '2');
  equals(two_clubs.suit, 'c');
});

and when I run the tests I can a nice output like:

QUnit output

Publishing

The goal of these challenges is to publish solutions so we can learn from each other. I used this as a motivation to learn git and github. For other windows developers wanting to start down this road my advice is:

I don’t usually like screencasts (except mine ;) but Bobby’s is perfect for git beginners. I literally typed along with Bobby.

My Solution

My solution is available in all its CoffeeScript glory. It’s not entirely complete but this has taken forever and I had to draw the line. If you download the source you can run the tests by opening the file tests.htm in any browser other than IE. If you want to experiment with the solution you can make changes to the CoffeeScript source files and recompile with:

bake compile

To run the application once compiled

bake run

you should see the following output:

Texas Hold em coffeescript output

Testing, huh! What is it good for?

Important-icon

 

IMPORTANT: Before reading this post open this link and let it play.

 

This is my response to the 2nd Developer Blog Banter. The question asked is

How do you organise your tests. Do you separate your unit tests, integration tests and UI tests into separate projects? Do you do anything specific to keep track of your tests? What naming conventions do you use? Do you run them before a check in or is that what the build server is for?

The first developer blog banter was about technology stack.

I organise tests into two groups: slow and fast. That is the only dichotomy that I care about. I try to run the fast tests all the time (using testdriven.net keyboard shortcuts). The slow tests are run less frequently such as when I change something external or when I think there is a chance I may have broken something as well as during the continuous integration build.

The majority of my tests are written as BDD style executable specifications using StoryQ.  I spoke about this at the South Australian code camp and I will be presenting a new and improved version at CodeCampOz. This is obviously a topic close to my heart; I presented similar material at this year’s Seattle Code Camp. I test this way to realise the following benefits:

  • link the tests to the requirements. If the tests pass then the application IS correct.
  • drive the design from the outside in. Like a sculptor.
  • prevent bugs, during development and in regression.

To briefly summarize the storyq approach, you start with a story like:

Story: Customer Complaints
In order to get satisfaction
As a customer
I want to submit a complaint

From which we can derive scenarios to specify the feature by example. We use the familiar given, when, then syntax to separate the context and the observations from the event:

Scenario: Stupid Complaint
Given I am a customer
and my complaints are stupid
when I complain
then my complaint is ignored

Scenario: Valid Complaint
Given I am a customer
and my complaint is valid
when I complain
then my complaint is handled
and the manager contacts me to apologise

StoryQ provides a GUI tool which converts these scenarios into boilerplate code:

[TestFixture]
    public class StoryQTestClass
    {
        [Test]
        public void CustomerComplaints()
        {
            new Story("customer complaints")
                .InOrderTo("get satisfaction")
                .AsA("customer")
                .IWant("to submit a complaint")

                        .WithScenario("stupid complaint")
                            .Given(IAmACustomer)
                                .And(MyComplaintIs, ComplaintValidity.Stupid)
                            .When(IComplain)
                            .Then(MyComplaintIsIgnored)

                        .WithScenario("valid complaint")
                            .Given(IAmACustomer)
                                .And(MyComplaintIsValid)
                            .When(IComplain)
                            .Then(MyComplaintIsHandled)
                                .And(TheManagerContactsMeToApologise)
                .ExecuteWithReport(MethodBase.GetCurrentMethod());
        }

        private void IAmACustomer()
        {
            throw new NotImplementedException();
        }

        private void MyComplaintIs(ComplaintValidity validity)
        {
            throw new NotImplementedException();
        }

        private void IComplain()
        {
            throw new NotImplementedException();
        }

        private void MyComplaintIsHandled()
        {
            throw new NotImplementedException();
        }

        private void TheManagerContactsMeToApologise()
        {
            throw new NotImplementedException();
        }
    }

If we run the tests now the output shows, as expected, that nothing is implemented.

image

The developer’s job is now clear: to get all of the tests to green. When that is done we know that the requirements have been satisfied:

image

Liam’s Final Thoughts

The way of working that I have described is similar to the workflow implemented by many ruby developers using cucumber. Where they typically choose to have their tests interact with their application’s interface I usually try to test against the layer immediately below the user interface. I developed this approach after listening to Hanselminutes episode 151 - Fit and Fitness with Ward Cunningham and James Shore. In that episode Ward says:

what that does is that
separates you from the objects in question.  For
example you can’t ask it anything that isn’t in the
output, whereas when I’m talking to the objects
directly, I can ask the object the question that isn’t
going to be in the output, right?  And  I can get an
answer form it too because I'll just let that object do
that for the sake of testing and that is the power of
objects.  Well, so objects are kind of had their day and
people are on to other things and that’s a technique
that was important to me and I think that it’s
something that was a little bit of my religion that hasn’t
really stuck.

This comment resonated with me because of the pain that I had been experiencing with UI tests. I still do the occasional UI test but I believe that attempting to prove that an application satisfies it’s requirements by testing through the UI is frustrating and ultimately futile.

Until next time, take care of yourselves and each other.

Sydney Startup Camp IV – A New Hope

IMAG0038 As we speak (figuratively) a group of 50 aspiring entrepreneurs are gathered in an abandoned warehouse deep in the heart of the upmarket Sydney suburb Redfern for Sydney Startup Camp IV.

IMAG0039 Their hosts, Bart Jellema and Patrick Driessen, have been guiding the participants through the process of starting a new technology business, accelerated so that the process fits into a weekend. There has been brainstorming, product development, marketing plans and pitches to the press and investors. The atmosphere is overwhelmingly enthusiastic and creative. It is a reminder of what talented people can achieve with the right intrinsic motivation. Conversely, it is a reminder of the spectacular waste present in some large organisations, who could not achieve in a year what the teams here are achieving in a weekend.

IMAG0035 Yesterday, Catherine Eibner presented Microsoft’s startup offering, Biz Spark. It was a tough assignment since only one of the teams had chosen to work with Microsoft tools (other that powerpoint!).

IMAG0036Part of the experience has been to push the physical boundaries – working around the clock. The diet has also suffered. Check out my biscuit smiley face.

If you are here at Startup Camp feel free to add a link to your product to the comments.

CoffeeScript on Windows

I have waged and long and bloody battle to find a way to work with CoffeeScript on Windows – and now I finally have!

The first step is to get CoffeeScript from github. You can either pull the source with git or download an archive after some hardcore archiving action.

The CoffeeScript compiler is written in CoffeeScript and provided in compiled JavaScript form. Therefore, we need a server-side JavaScript environment to execute the compiler and transform our CoffeeScript scripts into JavaScript that a browser can execute. Somehow, in my struggles I missed JSDB, a minimal server-side JavaScript environment. JSDB comes as a zip archive. To access the shell simply unzip and run jsdb.exe. From the shell you can execute any JavaScript that does not rely upon browser objects.

image

The basic steps to compile coffeescript are:

  1. Launch jsdb
  2. Load the CoffeeScript compiler
  3. Pass some CoffeeScript to the CoffeeScript.compile function.

Here is an example:

image

It would be nice to be able to pass a directory to the compiler and have it compile all of the CoffeeScript files to JavaScript. I created the following scripts to do that, based on the work of TBD. Both files should be placed in the CoffeeScript bin directory. When complete a directory can be compiled by calling Coffee.bat and passing the path to jsdb.exe and the directory to be compiled as follows:

coffee.bat “..\jsdb\jsdb.exe” “d:\scripts”

Coffee.bat

@echo off

if "%~1" == "" goto usage
if "%~2" == "" goto usage

%~1 -nojit jsdb.js %~1 %2
goto end

:usage
echo coffee.bat [path_to_jsdb.exe] [directory_containing_coffee_files]
goto end

:end

jsdb.js

load("..\\extras\\coffee-script.js");
writeln(system.arguments[1]);
system.setcwd(system.arguments[1]);
var files = system.files('*.coffee');

function getSource(filename) {
  var sourceStream = new Stream(filename);
  return sourceStream.read(1000000);
}

function getJavaScript(coffee) {
  return CoffeeScript.compile(coffee);
};

function writeJavaScript(javaScript, filename) {
  var javaScriptStream = new Stream(filename.split('.')[0] + ".js",'wt');
  javaScriptStream.write(javaScript);
}

for (var i = 0; i < files.length; i++) {
  var coffee = getSource(files[i]);
  var javaScript = getJavaScript(coffee);
  writeln(javaScript);  
  writeJavaScript(javaScript, files[i]);
}

Here is the result of compiling the examples from the CoffeeScript home page. The output is saved to cs_examples.js:

image

Determining the Process Identifier (PID) of the IIS Worker Process (w3wp.exe)

When working with multiple IIS worker processes it is useful to be able to correspond the processes to application pools. The command to do this in IIS 7 is:

%windir%\system32\inetsrv\appcmd.exe list wp

The output looks like:

WP "3948" (applicationPool:Classic .NET AppPool)

You can see the PID (3984) and the name of the application pool. The PID can be used to find the process in task manager and the Visual Studio Attach to Process dialog.

Javascript Koans Are Available

Following my announcement of a javascript koans project I am pleased to announce that I have published a draft of the project on google code. The topic ‘about prototypal inheritance’ is empty at the moment because I don’t feel that I understand it enough to write the koans.

Please download and play with the draft JavaScript koans. Let me know if you learn something.