Cowboy No More

Visual Studio has a handy "publish" feature for web sites. One piece that's really handy is the ability to publish to a folder -- just right click the project, choose Publish, click a few buttons, and you're all set.

msbuild /t:Build;PipelinePreDeployCopyAllFilesToOneFolder /p:Configuration=Release;_PackageTempDir=C:\temp\somelocation MyProject.csproj

Somehow, this time it's all started to click for me. Is it the new version of Ubuntu making everything so usable?  Was it forcing myself to learn how to get around emacs?  Or because our assignments required writing Makefiles?  Did Google make the OS irrelevant?

All I know is that I just wrote a perl script. For fun. Stand back, I know regular expressions!

Since the target system is Linux, I had to find a port.  This one seems like it will fit the bill.  So it's from 1997, who cares?  If it works, it works.  Except, of course, that the executable won't run.  The ancient INFO-ZIP self-extracting archive gives a message saying that the zip file is incomplete and that its final bytes perhaps reside on another floppy disk.  And I start feeling a little old.

Amazingly, I managed to find an answer for this on a reference for another language, BBC Basic.  Apparently the file is corrupted -- the last byte is missing. So I had to download a Hex editor and add a zero to the end of the file.  Amazingly, that allowed it to extract.  Somehow that made me feel even older.

Now if you'll excuse me, I have to go find a copy of Jumpman to play for a few minutes.

I pity the poor Java coders, really I do.  (Of course at night I am one, but that's another matter.)

Teardown logic in test code can be a pain point, as described by Gerard Meszaros in his book xUnit Test Patterns.

Suppose you have code like this:

teardown1();
teardown2();
teardown3();

If teardown1() fails, then teardown2() and teardown3() are not executed.

So you might write something like this...

try {
    teardown1();
}
finally {
    try {
        teardown2();
    }
    finally {
        teardown3();
    }
}

Which doesn't scale at all when you have a lot of teardown code.

Enter lambdas -- specifically, Action<T>.  This guy gives you a quick syntax for defining a method that returns void.  So now you can aggregate your teardowns in a list, then call each of them one at a time.

// Behold a beauteous delegated teardown.
List<Action> tearDowns = new List<Action>
                             {
                                 () => teardown1(),
                                 () => teardown2(),
                                 () => teardown3()
                             };

foreach (var teardownAction in tearDowns)
{
    try
    {
         teardownAction();
    }
    finally
    {
    }
}

Actually, since the methods being called are themselves all void in this example, you can just use them like so:

 // Behold a beauteous delegated teardown.
 List<Action> tearDowns = new List<Action>
                              {
                                  teardown1,
                                  teardown2,
                                  teardown3
                              };
 
 foreach (var teardownAction in tearDowns)
 {
     try
     {
         teardownAction();
     }
    finally 
    {
    }
 }
 
 

Now when we want to add a teardown, instead of hunting through a nasty indented set of existing ones we can just tack another lambda onto the end of the list.  And with the time you save, you can write a blog post about it. :-)

Today, after a bungled branch/merge session involving unversioned code, a class went missing.  I thought "well, at least I have my TDD unit test to inform me of my specifications!"

And then I saw some var statements.  So I have no idea what return type I was supposed to emit.

I'm gonna chalk this up as an "edge case" and keep on trucking, but if it happens again... bang zoom, to the moon!

• Have a first sprint meeting
  
• Determine how many hours we actually each have per week to accomplish stuff
  
• Create a prioritized backlog of things we need to do
• Do T-Shirt sizing on each item
• Choose the most important things to do in our sprint
• Place items on 3x5 cards and place on a Scrum board
• Every day have a daily stand-up to discuss what we did yesterday, what we're doing today and what's getting in our way of our tasks
• As we complete items, move them to "To Be Verified" on the scrum board, and write on the card how long it took
  
• Every week have a sprint meeting
• Move all verified items to done (if they can be verified)
• Quick retrospective: what went well? what didn't? how do we fix what didn't work?  how were our estimates?
  
• Take the next hunk of items off the backlog and move them to the board

If we actually do this, I'm going to log our progress here.  It seems like the appropriate spot.

Seriously.  I don't know how I ever used LINQ-to-SQL before I found the L2S T4 Generator.  It actually makes the thing usable.

Today I had to turn off optimistic concurrency checks.  I've been getting spurious errors as a result of some datetime fields that is well-documented on the Internet.  Instead of trying to find and fix each one, I've decided that this application really doesn't need to protect users from each other.  If two people happen to be updating the exact same thing, no worries.  The last one wins. 

If I wanted to do this with the L2S designer, I'd have to click on each column, then go to the properties window and change the desired concurrency level. Instead, I can add the following to the T4 template:

var options = new {
    DbmlFileName = Host.TemplateFile.Replace(".tt",".dbml"), // Which DBML file to operate on (same filename as template)
    SerializeDataContractSP1 = false, // Emit SP1 DataContract serializer attributes
    FilePerEntity = true, // Put each class into a separate file
    StoredProcedureConcurrency = false, // Table updates via an SP require @@rowcount to be returned to enable concurrency
    DisableOptimisticConcurrencyChecks = true, // Remove any UpdateCheck statements, so the last run statement wins.
};

// ... //

if (options.DisableOptimisticConcurrencyChecks) {
    #>, UpdateCheck=UpdateCheck.Never<#
}
else {
    if (column.UpdateCheck != UpdateCheck.Always) {#>, UpdateCheck=UpdateCheck.<#=column.UpdateCheck.ToString()#><#}
}

And my generated code now has "UpdateCheck.Never" set on every single column, so my updates are all performed against the primary key ONLY. 

Ahhhhhhhhhhh.

The disadvantage to this technique is that it is quite a bit more opaque.  The designer still says "Always" instead of "Never" as the T4 template is completely disconnected from it.  I've left a text file in the same folder to explain my changes to the template in hopes of helping out the poor future maintainer.