Let’s say (hypothetically, of course, since this thing never happens in practice) that you wrote some code in a non-TDD way.  Let’s say it was a straightforward line extension of some working code, but with a new mode that caused the line to go from this:

A –> B –> C –> D

to include this:

A –> B’ –> C’ –> D’

so, in your hypothetical pre-coffee poor-decision-making state, you just pounded out B’, C’, and D’ without first writing tests.

Now, having written a few hundred lines of code, you feel that nagging twinge that tells you that you really would love to see test harnesses around this new code.  Do you:

a) use a coverage tool to tell you what is untested, and dutifully go back and write unit tests until you get to your desired coverage threshold?  (Mine is 85%, by the way).

b) Actually run the new code, and find out what breaks and start writing tests at the breaking points, because that’s empirical evidence of either faulty assumptions or poor execution

What would you do?  I (again, hypothetically), will would start with b), because empirical evidence is always superior, and I might get pulled AFK by the sound of an ice cream truck or something, and I’d hate to have written tests for the easy stuff but left the hard stuff out because I didn’t have time.

I was diagnosing a problem with some SVN scripts today and came across an error: the batch file that called svn up was failing silently, and so the build that depended on the local files was not working properly either.

I figured it might be a problem running SVN in a batch file – perhaps interactive mode was on?  No, that wasn’t it.  I tried svn up from the /trunk/ and it worked as expected. Hmmm.

Turns out I should have tried svn up from the branch that was failing silently: when I did, I got this error:

svn: This client is too old to work with working copy
'/path/to/your/working/copy'; please get a newer Subversion client

This is all explained in the SVN FAQ.  You just have to update your SVN client and you’ll be OK.

However, my script should not have failed silently.  Always check your exit codes!  Actually, I’m not sure if checking the exit code would have worked in this case, but I’m assuming the Subversion developers are returning a nonzero result if there are problems like the one above.

In this listing of all the various tool and technologies that Facebook uses to serve up one gazillion requests per second, I found the following paragraph very interesting:

Gatekeeper also lets Facebook do something called “dark launches”, which is to activate elements of a certain feature behind the scenes before it goes live (without users noticing since there will be no corresponding UI elements). This acts as a real-world stress test and helps expose bottlenecks and other problem areas before a feature is officially launched. Dark launches are usually done two weeks before the actual launch.

This is a great idea.  Launch functionality behind the scenes, but don’t launch the corresponding UI elements.

Why is this great?

1. Forces your team to get good at a deploying
2. Forces your team to think about separating UI and business processing during architecture meetings
3. Allows you to start exercising the functionality in the real world (perhaps through hidden URLs or something) before users get to it
4. Exposes naughty integration failures

I like it.

I got this note from Joe Heitzeberg at WhitePages and thought I’d pass it along.  The idea of “distributed work” as a business strategy (or is it a tactic? Does it matter?) is really interesting to me.  I’ve often wondered if Crowdify could benefit from the use of Mechanical Turk or something similar, perhaps as a way to baseline a non-segmented opinion about a given brand.

WhitePages is hosting a Distributed Work Meetup at our offices on Monday, May 10th at 5pm.  If you’re interested in learning more about leveraging crowdsourcing plaforms like mTurk in your ventures, then please join us.   This time there will be 4 cities connected over streaming video to bring together some great speakers, including Seattle’s own Brent Frei.

Here’s the link with details like our address:  http://bit.ly/dpaLHq

Maybe see you there?

Were I to write some SQL to see if an element was not present in a set, I’d write something like:

SELECT T.*
FROM [table] T
WHERE T.[name] NOT IN (“foo”, “bar”, “bat”)

How to do the same type of thing in PowerShell 2.0?  Well, you can’t – not the same way.  But flip it on its head, and you get exactly the same thing:

$myvalue = “something” #this is the T.[name] from the SQL example
$arr = “foo”, “bar”, “bat”
($arr –contains $myvalue) -eq $false

You have an additional tweak available to you: a case-sensitive comparison.  To do this, use –ccontains (note the extra “c”) instead of –contains:

$arr –ccontains $myvalue

To find out more about comparison operators in PowerShell 2.0, type:

get-help about_comparison_operators

in the IDE.

Finally, a neat trick: if you know that there’s an “about_” topic, but are not sure what it is?  get-help accepts partial matches:

get-help about_

… will return all the help topics that start with the string “about_”.  Pretty neat.

I’m running some scripts against the YouMail API to post audio.  I’m seeing HTTP 417 Expectation Failed messages, which The Google has led me to believe are due to the Expect: 100-Continue header present in the post.

Fiddler tells me that yes indeedy, I’m passing the Expect: 100-Continue header:

So, back in PowerShell, I add the following line of code:

[System.Net.ServicePointManager]::Expect100Continue = $false

… but I see the same problem.

Checking the ServicePointManager and the HttpWebRequest object for their properties gives me two different results:

§ anthonys-m1330 {C:\s\C\Test-YouMail} [System.Net.ServicePointManager]::Expect100Continue
False
______________________________________________________________________________________________
§ anthonys-m1330 {C:\s\C\Test-YouMail} $req.Expect
100-continue

So what’s the deal?  Turns out that you have to set the Expect header property on the HttpWebRequest object directly:

$req.Expect = ""

…which clears out the Expect: 100-Continue header.

This begs the question, what does the System.Net.ServicePointManager have to do with anything?  Dunno.

I was dinking around with the System.Xml namespace in PowerShell this morning and came across an interesting encoding bug.  Here’s the PowerShell function to read XML data from a file and return a System.Xml.XmlDocument object:

function Get-XmlDocumentFromFile() {
param([string]$file)
Write-Host("Reading the file {0} for XML content..." -f $file)
if ((Test-Path $file) -eq $false) {
throw(("ERROR: File not found! '{0}'" -f $file))
}
[xml]$xml = new-object System.Xml.XmlDocument
try
{
$xml.Load($file)
$xml
}
catch [System.Exception]
{
$_ | fl * -Force
}
}

When I call this function with this XML file as input:

<?xml version="1.0" encoding=”UTF-8” ?>
<entry>
</entry>

I get this error:

Cannot convert value "System.Object[]" to type "System.Xml.XmlDocument". Error: "Data at the root level is invalid. Line
1, position 1."
At line:1 char:3

However, if I change the XML declaration in the file to this:

<?xml version="1.0" ?>
<entry>
</entry>

…it works.  So what is it about the “UTF-8” encoding attribute that causes it to barf in PowerShell?  Dunno.  Will investigate more later.  But that “Data at the root level is invalid” error is what pointed me at the problem.  My first cut at the PS function didn’t include the exception handler and I got this unhelpful and misleading error:

Root element is missing

… which was obviously incorrect on its face.  So, moral: always include exception handlers in your PS functions.

This little function may be useful to you long-tail Google searchers:

function Get-BytesFromWav(){
param([string]$wavFile)
Write-Host ("Getting bytes from the file {0}..." -f $wavFile)
if ((Test-Path $wavFile) -eq $false) {
throw("File not found!")
}
[System.IO.FileStream]$stream = [System.IO.File]::OpenRead($wavFile)
[byte[]]$b = @($null) * 1024
[System.Text.StringBuilder]$sb = new-object System.Text.StringBuilder
while ($stream.Read($b,0,$b.Length) -gt 0)
{
$b64 = [Convert]::ToBase64String($b)
#make sure to handle the return value
$temp = $sb.Append($b64)
}
$sb.ToString()
}

One thing about PowerShell that tends to bite me fairly often is the handling of return values from functions. PowerShell doesn’t have an explicit RETURN statement, so functions will return anything that’s not handled. Consider the following:

function Foo() {
[System.Text.StringBuilder]$sb = new-object System.Text.StringBuilder
$sb.AppendLine("foo")
$sb.AppendLine("bar")
$sb.AppendLine("bat")
$sb.ToString()
}

What’s the return value of this function? One might at first suspect that it is:

foo
bar
bat

…but you’d be wrong. What it actually outputs is a bunch of duplicates, because each .AppendLine() call returns SOMETHING, and that something happens to be the StringBuilder instance. And you may run into an implicit .ToString() if you’re using the return value, so…it’s just bad news all around.

The solution is to explictly handle anything you don’t want to return:

function Foo() {
[System.Text.StringBuilder]$sb = new-object System.Text.StringBuilder
$temp = $sb.AppendLine("foo")
$temp = $sb.AppendLine("bar")
$temp = $sb.AppendLine("bat")
$sb.ToString()
}

It’s a little gnarly, but workable.

You know of a .NET enum enumerated type.  You want to know what its values are.  Pretty common.

[System.IO.FileOptions] | gm –static –membertype Property