Codesion free Subversion hosting: Fail

I thought I’d try cloud hosting for source code version control. I’ve been using version control on my local box, but figured it’d be better to have that stuff stored offsite so that I can get to it from wherever I am.

Codesion came highly recommended, and I was pleased with the ease of setting up a new trial account. At least, I was impressed until I tried to access my new repository. If I try to access it from my Subversion command line client, I get this message:

svn: E175002: Unable to connect to a repository at URL ''
svn: E175002: The OPTIONS request returned invalid XML in the response: XML parse error at line 1: no element found (

I get a similar error if I try to access it with the TortoiseSVN GUI client.

So I thought maybe I misread the terms of the free trial. I went to the Codesion site and tried to view the repository with their ViewVC browser. The result is a browser window containing this information:

An Exception Has Occurred

Python Traceback


Traceback (most recent call last):
  File "/services/viewvc_template/lib/", line 4396, in main
  File "/services/viewvc_template/lib/", line 268, in run_viewvc
  File "/services/viewvc_template/lib/vclib/svn/", line 204, in open
  File "/usr/local/python/lib/python2.5/site-packages/libsvn/", line 518, in svn_ra_open
    return apply(_ra.svn_ra_open, args)
SubversionException: 175002 - Unable to connect to a repository at URL ''
175002 - The OPTIONS request returned invalid XML in the response: XML parse error at line 1: no element found (

Checking their online forums, it looks as though others have had similar issues in the past few weeks. Sorry, Codesion. If you can’t get a simple free trial to work, I’m not going to trust you with my source code.

There are dozens of sites that offer free or inexpensive Subversion hosting. I don’t have the time or inclination to try every one of them. Anybody have a recommendation?

And, no, I’m not interested in using GIT. Please don’t suggest it.

Purpleheart heart

Debra’s Valentine’s Day present from me this year was this stylized heart, carved from Purpleheart. The rough cutout was about 2-3/4 inches tall, 2-1/2 inches wide, and 1 inch thick. I cut it from a 6″ x 12″ x 1″ piece of Purpleheart that a friend gave me some time ago.

I did the cutout on the bandsaw, of course, and shaping with the Foredom power carver. After that, a lot of sanding with 100, 120, 220, 400, 600, 800, and 1,200 grit paper. Finish is Howard Feed ‘n Wax.

The heart is just the right size to fit in the hand, and it’s very pleasant to hold or to rub absently, similar to a worry stone.

FizzBuzz as a litmus test

In The White Board Inquisition, I mentioned the FizzBuzz program as a minimum standard for identifying programmers. It’s a simple test that any programmer should be able to write in just a few minutes.

Write a program that outputs the numbers from 1 to N on the console, with these exceptions. If the number is divisible by three, then instead of outputting the number, output the string “Fizz.” If the number is divisible by five, then output “Buzz.” And if the number is divisible by three and five, output “FizzBuzz.” So the first part of your output should be:


Writing the numbers one per line is fine. I wrote them as comma separated values here in the interest of saving space.

If you can’t write that program, you aren’t a programmer. If you can’t write that program, you’re no good to me as a programmer and your degrees, work experience, and ability to spout buzzwords aren’t going to impress me. If you fail this simple test, I will terminate the interview early.

I am completely flabbergasted at the number of people who claim to be “senior programmers” who can’t even write that simple program.

Some people have told me that I expect too much. “After all,” they say, “we’re not trying to find real programmers, just people who can hook up some Web pages.” That’s crazy. “Hooking up Web pages,” at least in the applications I’ve seen, requires real programming. Increasingly so, in fact, what with the profusion of JavaScript. FizzBuzz tests basic programming knowledge: the use of loops, conditional statements, and simple math. I guarantee that those things are required in even the simplest of interactive Web applications.

Understand, FizzBuzz is just the first test. And don’t expect me to give exactly that problem. I might change it around a bit to see if you really understand it or if you just memorized some code for the interview. You’d be surprised at how many people can write a flawless FizzBuzz, but are totally mystified when asked to modify the program so that it counts down from 100 to 1. It’s frightening.

Years ago, I laughed at the idea of the singularity occurring within my lifetime. Reaching that milestone will require systems that are orders of magnitude more complex than anything we’ve been able to build reliably. I did, however, agree that it could happen sometime in the future. Now, I’m not so sure. Even if we get enough smart people to design such a system, there’s no way a bunch of mush-for-brains “programmers” will ever be able to implement it.

PowerShell parameter parsing

PowerShell has some nice built-in command line parameter parsing. I’ve only been wishing for something like this for … well, forever.

Imagine you have a script that accepts four parameters:

-EnvironmentName (or -e), which is mandatory
-DestinationDir (or -d), which is mandatory
-UserName (or -u), which is optional
-Password (or -p), which is optional

Usage would be:

myscript -e testing -d c:\test -u username -p password

Writing code to parse and verify those parameters is just busy work. But because we haven’t had a good alternative (at least, not on the Windows platform), we’ve been doing it for years, writing new argument parsing code for every program. Sure, there’ve been some attempts at building a generalized argument parser and validator for particular languages or platforms (like .NET), but not one of those has really caught on.

Until now. PowerShell makes quick work of parameter parsing and validation. You can describe the arguments for the script mentioned above with just a few lines of code.

# ParamTest.ps1 - Show some parameter features
# Param statement must be first non-comment, non-blank line in the script

Write-Host "EnvironmentName = $EnvironmentName"
Write-Host "Destination = $Destination"
Write-Host "UserName = $UserName"
Write-Host "Password = $Password"

At a PowerShell prompt, run that script with this command:

.\ParamTest -EnvironmentName MyEnvironment -Destination c:\logs\MyEnvironment

The script will output the parameters as you entered them. The UserName and Password arguments are optional, so the output for them will be blank. If you want, you can include default values for those optional arguments.

I like that you can specify aliases for the parameters. So -e MyEnvironment is the same as -EnvironmentName MyEnvironment.

Note also that -d dest -e env will do the rational thing. That is, the order that you specify arguments doesn’t matter. Well, it does matter if you don’t name the parameters on the command line. That is, .\ParamTest MyEnvironment c:\logs\MyEnvironment will assign the value “MyEnvironment” to $EnvironmentName, and “c:\logs\MyEnvironment” to $Destination.

Unfortunately, there seems to be a bug in the positional parameters stuff. According to the documentation, if you have a parameter attribute on a parameter, then the default is that the parameter can’t be positional. If you use a parameter attribute, you’re supposed to include a Position argument if you want it to support positional processing. That is, in the above code, you should have:

    [parameter(Mandatory=$true, Position=1)]
    [parameter(Mandatory=$true, Position=2)]

Conversely, if you don’t want any positional parameters, you should be able to write:


That doesn’t seem to work. The code above will still support positional parameters. I haven’t yet seen a good way to completely eliminate positional processing.

You can try parameter(Position=-1), but then you’ll get an exception if you try to run get-help on your script. I’ve also seen a hack of using Position=0 on all of the parameters, but that results in some unhelpful error messages if you forget to name your command line parameters.

Even with the oddities having to do with positional parameters, the Param statement is a welcome feature in any programming language.

What I’ve shown above barely scratches the surface of what you can do with Param. You can include a help message with each parameter, create parameter sets, and specify some basic argument validation, all with some simple syntax in the Param statement. If you’re writing scripts or cmdlets, you should study the Param statement.

If, like me, you’re relatively new to PowerShell, it can be difficult to find information about this stuff. A good place to start is the MSDN Windows PowerShell topic. I’ve been unable to find a PowerShell reference on MSDN. For reference material, I start at the TechNet PowerShell page. For information about Param, see about_Functions and about_Functions_Advanced, or type help about_Functions (or help about_Functions_Advanced) at a PowerShell command line.

The documentation I’ve seen lacks good examples, but a little searching and experimenting can yield good results.

With PowerShell, there’s simply no reason to write another batch file. And if you find yourself making large modifications to an existing batch file, you should think very seriously about just rewriting it to use PowerShell. It really is worth your time to learn and use it. I think you’ll find, as I have, that many of those little C# programs you’ve been writing to do various things can be replaced with simple PowerShell scripts.



A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.