Ok guys, it's pretty simple: if you're working in a Turing-complete environment and you've got paths which start with a '/', you're doing it wrong. Very wrong!

Todays offender: WSGI scripts.

Here's the first line of a common WSGI script:

app_path = '/path/to/application'

See a problem there? That's right, the absolute path!

How could this be solved? Simple: put the WSGI script in /path/to/application, then get the app_path using: app_path=os.path.abspath(os.path.dirname(__file__)). Problem solved.

</rant>

A couple of days ago, I complained about FlexUnit's Theories. Well, with a bit of encouragement from @drewbourne, I broke down and wrote a proper parameterized testrunner:

    [RunWith("utils.testrunners.ParameterizedRunner")]
    class AdditionTests {
        public static var numbersToTest:Array = [
            [1, 2, 3],
            [4, 5, 9],
            [-1, 1, 0]
        };

        [Parameterized("numbersToTest")]
        public function testAddition(a:int, b:int, expected:int):void {
            assertEqual(a+b, expected);
        }
    }

And that code will do exactly what you'd expect: run three test cases, one for each of the inputs. If one test fails, the others will still run. Helpful error messages will be provided when a test fails.

The source can be downloaded from: http://gist.github.com/299871 (and it will be getting a new home when ever I get around to releasing all of my AS utilities)

Look useful? Give it a try and tell me what you think – I'd love to know.

I've just been playing around with FlexUnit 4's nifty new "Test Theories"… And I have come to the conclusion that, right now, they are basically worthless.

Here's why:

• They aren't documented. At all. There are approximately two examples on the internet, and the wiki page is a joke. Nothing explains what algorithm is used to calculate which DataPoints are applied to which theories.
• They make test error messages less helpful. If a a theory fails, instead of getting a helpful error message like "Theory `checkUrl("this is a bad url")` failed with message: could not determine protocol", it gives a message like this: "checkUrl urls[1]". Yea, thanks guys.
• They don't do anything "cool". At all. It would be cool if, given five data points, five distinct tests would be generated. It would be cool if one data point could fail while others succeed. Heck, anything which would make them better than a for loop would be cool. But, alas…

So, don't waste your time on Theories just yet. For now, just use a for loop:

[Test]
public function runTestsOnData():void {
    for each (datum in testData)
        doSomeTest(datum);
}

Or, if you want to test the cartesian product of a set of data, use my handy cartesian product function:

[Test]
public function runTestsOnCartesianProduct():void {
    for each (data in cartesian_product(testData0, testData1))
        doSomeTest.apply(this, data);
}

Followup: as Alan (see comments) said, what I really want is a parameterized testrunner. So I've gone ahead and written one. See my post on a Parameterized Testrunner for FlexUnit.

There are a few things I do every time I start a new Django site, and one of those things is add my path lambda to the top of settings.py:

    import os
    ROOT = os.path.abspath(os.path.dirname(__file__))
    path = lambda *args: os.path.join(ROOT, *args)

From then on, it's drop-dead simple to create absolute paths which are relative to the root of the project (or, at least, the directory which contains settings.py). For example:

    >>> path('media/')
    '/Users/wolever/code/review_anywhere/media/

And some other places where it is useful:

    DATABASE_ENGINE = 'sqlite3'
    DATABASE_NAME = path('db.sqlite3')
    ...
    TEMPLATE_DIRS = (
        path('templates/'),
    )
    ...
    DATA_DIR = path('data/')
    ...

I picked up an Arduino yesterday, and I was quite dismayed by how much work it took to build/flash from the command line.

After some hours of Googling, though, I finally found an up-to-date Makefile, and it didn't take too much to make it "just work" with the default install of Arduino.app on the Mac.

To use this Makefile, simply drop it into the project sketch directory, then run make then make upload. You may need to tweak some variables (eg, it assumes Arduino.app is located at /Applications/Arduino.app), but that is fairly straight forward.

Get the Makefile from: http://gist.github.com/273821.

Just a note: I haven't had much time to tinker with this system yet, so it may have some serious issues... If so, drop me a comment below.

Also, leave a comment if you want me to let you know if (when?) I update this.

(alternate title: The "Fail Early, Fail Often" Principle in Action)

I would like to award Adobe the "best ever implementation of indexOf". Ready for it? Here it is:

override flash_proxy function callProperty(name:*, ... rest):* {
    return null;
}

This beauty can be found in mx.collections.ListCollectionView.

And the kicker? The function's documentation:

/**
 *  @private
 *  Any methods that can't be found on this class shouldn't be called,
 *  so return null
 */

The author clearly knew that unknown methods* shouldn't be called… But instead of doing something sensible – like throwing an exception – they do something wholly nonsensical and return null. Or, of course, they could also have left the function unimplemented, which would result in a strange and unhelpful exception… But, of course, I would expect nothing but the best from the Flex standard library.

Next up: why implicit conversions from null to int are always wrong.

</rant>

*: the magic callProperty method is called on subclasses of Proxy when a method can't be found. For example if bar is not a method of foo, executing foo.bar()will call foo.callProperty("bar").

PS: Instead of calling indexOf, I should have been calling getItemIndex.

In my last post, I showed off some normal-mode data from vim-logging. In this (and the next few) posts, I'll go though my most-used commands and describe how I use them.

(Don't use Vim? This post won't be too interesting… Although you may pick up something useful)

g

My logs contain more than 60,000 references to the 'g' command (eight times more than ':', the next most frequently used command). This may seem surprising at first, but stick with me and let me explain: the 'g' command is something of a 'gateway' command - a prefix for a number of common actions which don't have their own single-character command (for example, gd, goto definition and g?, rot13 encode).

Here is a breakdown of the 'g' suffixes I often use:

• gj and gk: cursor to next row, cursor to previous row ("make j and k do the right thing"). The j and k commands are defined as "move to next line" and "move to previous line", not "move to next screen row" and "move to previous screen row". This is an important distinction to make when long lines are wrapped, and I find "move to next/previous screen row" is a more reasonable default. Protip: use noremap j gj and noremap k gk in your vimrc.

• gg: cursor to top of file. After using gg (for example, to edit some import statements or add a shebang line), I often use '' (tick-tick) to jump back to the line I was editing at the time (for example, ggofrom foo import bar<esc>''). Also, I often use ggVG (go to top, enter line-visual-mode, go to bottom) to select the entire file. From there, I can pipe it to something (for example, :!sort), format it (gw) or copy it to the clipboard.

• gt and gT: go tab - move to next/previous tab.

• gf: goto file - edit the file under the cursor. For example, if the cursor is over the 'e' in import "../eventDispatercherImpl.as", the equivalent of :e ../eventDispatercherImpl.as will be executed.

• gw: go wrap. Wrap the selected text (that is, text selected in visual mode). Try selecting a long line (pressing V), then using gw to wrap it.

That's all the 'g' commands I can think of for now... The next version of vim-logging will log the sub-command used, so I will be able to provide better data in the future.

:

The colon command is fairly obvious: enter command-line mode to run commands like :w or :help :.

I'll write more about this later, when I analyze my most-used ex commands.

d

Ah, d - delete - the programmers best friend.

As with g, I do not have detailed information about how I use d, but I'll list the first few combinations that come to mind when I move my left index finger over the d key:

• dd to delete whole lines
• di( to delete everything inside a pair of parenthesise
• dfx to delete everything between the current position and the next occurrence of 'x'
• dj and dk to delete this and the next/previous line
• d$ to delete from the current position to the end of the line
• d in visual mode to delete the selected text.

Remember when I blogged about vim-logging? Well, I've finally gotten around to interpreting the results.

First, I will cover what I believe to be the most important thing to know about vim: the normal mode commands.

Below is a chart of my 39 (why 39? I can't remember - when I created the graph, that's the number I chose) most-frequently-used normal-mode commands: