My Projects

My current projects include:

Delphi, a tool for iterative refining lists of priorities: a web app fronting a cute algorithm for merging lists of priorities. But the real jewel here is using node.js on the server side, which gives me validation code shared by the server and client, no more duplicating that logic; and, by structuring code as a pipeline and exposing different pipeline entry points on the server I can migrate processing between the client and server.

AudioTools.js: an audio synthesis library, following the model of generating wave forms in the client and dynamically embedding them as Base64 encoded data URIs. In it's heart of hearts this is a hack because the audio support of browser clients is sadly neglected.

The Guitarist's Ear Trainer: one of the key musical skills is being able to identify the sounds you hear, but most of the very good software is about naming the sounds, I want to make the naming of sounds a secondary concern, going directly from sound to identifying where fingers go on the guitar neck is my priority. And I want it to work on mobile phones so I can get some practice in while I'm travelling to work.

And some code I've cobbled together from various sources that I may put out there, (I'm reluctant because I'm relying on cut and paste from jQuery, prototype, and underscore):

patch.js: a library that extends the standard classes of earlier versions of JavaScript with the basic functions you find in the most up to date versions. I depend on good list processing functions, and they are part of the latest versions of the language, but there are dozens of names given to them in various libraries, and a philosophical reluctance to extend the core classes. Generally I don't like polluting the core classes and the global object, but I'm comfortable with extending the core classes the now established standard names.

Looking into the future:

GA-FLRB: a fuzzy logic rule base with a genetic algorithm system. My honours year project involved writing a cellular automata system with an FLRB as the automata, and neat little language to describe the FL rules, still have a soft spot for such systems.

JavaScript

Love it or hate it JavaScript is one of the big languages.

I like the Tomas Fuchs paraphrase of Bruce Sterling: "JavaScript is the duct tape of the internet". With CommonJS and the growth of server side JavaScript, it will be much more.

It's a language that quietly accepts laziness and ignorance, saving up the pain so that it can all rain down on you at some unforeseeable moment in the future. It's a language that rewards discipline: I recommend developing discipline.

JavaScript has become my language of choice, for all it's imperfections, because:

• It's the only language that's available on all the platforms I want to target: major mobile phones and desktops.
• It's remarkably simple, scheme in C-drag, so I focus on getting things done rather than fooling around with the language and tools.
• I like the forward facing side of development, it's a language that's frequently used to tune the user experience and that plays to my motivations.

Of course there are essential tools, work flows that need to be optimised, and developers skills that haven't been widely applied to JavaScript that should be:

• Editors and IDEs; test frameworks facilitating the writing of tests and the execution of tests; debuggers and profilers; libraries and toolkits; command line JavaScript implementations.
• Isolation of dependencies: the chief dependency is with the DOM, the second is with DOM wrapping libraries, the third is with widget libraries, all of which should be wrapped so that you're working with logical elements rather than (other people's) stuff on your page.

Thoughts on a Portfolio

I was screening a candidate today, an international phone call and a review of some of his code on github.com, he made a solid showing. For myself I've never presented my code as a portfolio although I've often said that I think a good professional should. That got me to thinking about what I would like to have in a public repository of my work, how I would like to be judged. What do I want my portfolio to say about me?

• I should want to work for a company that writes code like my portfolio.
• It should be the sort of code I would like to be paid to write.

It's about looking professional, and it's code, so I'd aim to get people actually playing with my work. There's no better advert for a programmer than the quality of their working programs.

A few things come to mind regarding the presentation in the repository:

• It should look real, like you were genuinely using it or it's been made for someone.
• Any reasonably experienced person should be able to click through and figure out what it's about without any wrong steps.
• The tests should be an obvious and effective first place to look, (I'm always impressed when I can figure out the motivation and typical use of open source by scanning through some tests).
• If you're one of many contributors then your contribution needs to be substantial and easy to find.
• It should be relatively easy to deploy and run for anyone who takes a look at it, ideally both a launch script and instructions.
• If it's a web application then consider hosting it somewhere, if it's a stand alone application make it downloadable and installable (and removable).
• Don't present non-functioning work in progress in your portfolio (maybe you need a separate repository for that).
• Don't present old school work unless you are a recent graduate.

And in terms of the code, (some of these points are my responses to code I've read while reviewing various portfolios):

• It should be clever without being obscure.
• It should in general follow the common idioms of the languages, be obvious and relatively future proof.
• The code should speak for itself, comments that just repeat function names or similarly obvious information are redundant; good file, module, class, function and variable names are better.
• Comments should explain what isn't obvious in code, like larger scale motivations or algorithms, or expected patterns of use. Although tests should also carry that information.
• As a portfolio it shouldn't just repeat the same thing, so variety in languages:
  • Something in the Java/C++/C# vein,
  • Something in the Python/Ruby vein,
  • Perhaps something in the emerging languages vein like Scala/Closjure/F#
  • Perhaps a restricted environment tool like JavaFX/Flex/JavaScript.
• At least two different types of applications:
• A retained state stand alone application,
• Plus a web app,
• Perhaps a smart phone trinket,
• A library or some utility scripts could also be worthwhile.

It's a portfolio, put your best foot forward.

By Way Of Introduction

Thanks for dropping by! This is a first foray for me into the world of topical blogging.

I'm starting this more or less midway in working life: my first job was at MacDonalds which I started just before I turned fifteen, and if I retire at sixty-five then I'm just a year or so shy of half way there.

A few years ago I went through a professional mid life crisis of sorts, left a good job in R&D at Canon and went to teach English overseas. I leant Spanish well enough to make good friends and to get back into IT while living in Madrid, I ended up working in a large bank, a job that made Dilbert's world look positively functional, I learnt a lot.

I saved some pennies and headed to London a took a job based on how I wanted to work and what I wanted to learn. I've been here a year and half, and it's still a good job. A lot of this blog will be about the priorities I've developed through those experiences.

It's about the profession of software development, the developers toolkit I use and the way we work. It's also about technology in my day to day, the toys and tools that I want for myself.

Right now I'm not looking at being team lead or any senior role, although I actively take on any load to help the folks who do have those roles, so the perspective will be of a largely content senior developer. It's part of me learning to be a better developer, pulling knowledge from different sources, being conscious of my own character: a tendency to think of developers as humans with human motivations; conscious of the balancing act between ideal solutions and effective compromise; drawing on experiences that include academic research, name brand hardware development, big bank back office, and super-agile small-company web applications.

My own hobby programming will enter the picture. Right now that includes a web based tools, things that can work on mobiles phones as well as the desktop: delphi method tool for capturing requirements, particularly for becoming conscious about "forgotten" legacy requirements, and an ear trainer for guitarists that I want to run on smart phones.

I daily use a very pretty little MacBook at home, and have a thumping great big Linux box under my desk at work. I'm still tossing up between Android and iPhone . I've spent years working with Microsoft Windows. Ultimately I'm technologically agnostic, I've been around long enough to know it'll change, and that's it's good enough to be mostly satisfied, and better not to be too attached to specifics and details.