I tend to be a very thorough and detail-oriented person… at least I hope so (there are other words for it, but we’ll leave it at that). So naturally, when I’m writing code - whether it’s xhtml, CSS, ActionScript etc - I try and keep things neat, clean and easy to read. I indent like it’s going out of style, I strive for consistent naming conventions, and I use descriptive variable and function names.

Read the rest of this entry »

In an effort to simplify audio visualization experiments with ActionScript 3.0, I’ve developed a SoundData class. The class’s main attraction is centered around the flash.media.SoundMixer.computeSpectrum() method, but it also provides additional control over playback, including startSound(), stopSound() and toggle() methods. The class also allows manipulation over volume and panning.

Read the rest of this entry »

‘Twas the night before Christmas, when all through the house, just my keyboard was stirring, along side the mouse … Read the rest of this entry »

We’re getting soooo close to our Wonderfile beta launch….

An old salty dog programmer (also very successful money-wise) once told me. “A software application isn’t really done until it’s been rewritten from scratch at least five times.”

We’re on our fourth rewrite of Wonderfile. It doesn’t encapsulate our complete vision for the app, but we feel that it’s quite useful as it is, and definitely good enough to publically beta test.

What is Wonderfile? It is a completely new way to think about organizing electronic files. We’re done with the nested folders of the 80’s and have created a hierarchical tag-based framework for managing files. This is really different stuff - a paradigm shift. Comments from experienced IT pros we’ve shown early demos to…

* “Why hasn’t anyone else done this?”

* “I can use this in a ton of different ways.”

* “How can I invest?”

We’ll be posting the access code for our limited beta on this blog October 15th. We’ll let 250 testers in to the system - first come first serve. They’ll be given privileged account status (i.e. less expensive after the test is over) and will be able to influence future development of the system.

For a sneak preview, come see us demo Wonderfile to our peers at Minnedemo Oct. 11 (free beer for the first 200 attendees). Minnedemo is held at O’Gara’s in St. Paul - the demo’s start at 7:30 and we’re the fourth company on stage…

Visit - http://minnedemo.org to register.

I have a theory.

A web application will be at least 100% better if the developers who create it also actively use it.

It is akin to a meal prepared by an expert chef. The best chefs constantly sample their creations as they prepare a meal. When it is ready, they’ll serve it to their patrons and then sit down themselves to enjoy what they have lovingly created.

Like a chef, expert developers need to actively sample (test and use) their software while working on it, then sit down and consume their own code as a user would.

QA provided by testing experts definitely has its place - but I fear that sometimes developers (even good ones) miss significant opportunities to write better applications because they rely too heavily on testers / users to catch bugs and provide interface feedback. This reliance costs time - but even more significantly, we lose opportunities to improve the user experience because those who know how to change the code don’t take the time to actively engage and use the application. This lost opportunity for creative improvement could be avoided if developers spent an hour actively using the application for every 10 hours spent coding.

When I say using - I don’t mean quick tests, scripted testing, a little demo or anything like that - I mean actively using the application like their users will have to. I’m talking really, really use it and engage. A good chef will sit down and eat the meals he prepares - from that he draws inspiration for improvement. Programmers who consume the applications they write will create better software - hands down.

One of my biggest complaints about PHP5 is that you can’t do genuine object overloading, you can only fake it using the __call() method and its brethren. The crappy part about __call() is that if you want to do anything complex, you end up reinventing the wheel in a big if, elseif… else block, or maybe a switch statement. It’s not well suited for real overloading, Java style. We’re better off just using func_get_args() at the top of a method and choosing different paths based on what we find in the function arguments. But that too can get overwhelming. I thought of a solution which I find interesting. I’m not saying it’s right, or even a good idea, but it comes as close to real overloading as anything, is quick enough to use, and demands strict variable typing. Read the rest of this entry »