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 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.

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.

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?

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.

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.

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.

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()
}

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.

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