Certification Roadmap

I’m finally sick of a few too many things:

  • Having certificates that are older than most of my children
  • Seeing the following Roadmap on my cube wall
  • Not moving forward on any of this

You may ask why of course, but I’ll leave that justification for another post.

So, the ultimate goal is MCPD: Enterprise Developer and MCITP: Database Developer 2008.

First, I must attain MCAD.NET status by passing:

Then, a “simple” All-In-One upgrade exam to attain MCPD: Enterprise Developer:

Then, I need two more exams:

If I have any energy left in the year, I’ll try to get my MCPD up to v2008 level by taking:

[del.icio.us] [Digg] [dzone] [Technorati] [Twitter] More »


Author: Brett Veenstra | Category: Programmer | Comments Off March 2009

Continuous Integration Gotcha: NAnt empty elements

For those of us using the TeamCity continuous integration tool, I ran across a gotcha this morning that I will forget very soon.

The problem

When running NAnt script on my local machine “in developer mode”, everything runs fine. However, once it goes to TeamCity, it puts up a general error:

Could not include build file ‘X:\teamcity-BuildAgent\work\684ab6ff82f1a29a\build\foo.core.build’. Object reference not set to an instance of an object.

In the end, my offending entry was:

<fileset id="cube.load.files">
  <!-- <include name="${build.mxl.dml.dir}\foo.mxl" asis="true"/> -->
</fileset>

Here’s my NAnt file pattern. I use a set of local.properties.xml for a development machine. I also create a buildserver.properties.xml for the TeamCity run. Then I create a “wrapper” NAnt file that includes both the CORE build script as well as the *.properties.xml file for the given environment.

This has worked very smoothly in the past so this morning it was rather frustrating to receive the error. The inspiration for this methodology was inspired by Jean-Paul’s excellent NAnt series. I highly encourage you to check it out.

Back to the problem… When running under TeamCity, I get a failure to include a build file, but everything works when running on a development machine.

The Solution

Remove EMPTY elements from the XML-formatted NAnt file (or close them using shorthand). For some reason, it looks as if TeamCity’s NAnt runner is parsing those files before sending them over to NAnt (guessing here).

And once I cleaned up this empty element, it worked! Interesting how this yet another reason why XML is the bane of developers.

<fileset id="cube.load.files" />

[del.icio.us] [Digg] [dzone] [Technorati] [Twitter] More »


Author: Brett Veenstra | Category: Programmer | Comments Off October 2008

Gotcha of inline Document Ready function for JQuery

I’ve had some reasons to use JQuery this week, and you should believe whatever good rumors and hype you’ve heard about this library. It’s amazing.

There are many benefits to a Javascript framework, particularly JQuery. Take this example that I put inside my <head> element:

<script type="text/javascript">
    $(document).ready(function(){

        $('#deliciouslogin').submit(function(){
            alert("This to authenticate with Delicious and start retrieving Bookmarks into Google Gears  database");
        })

    });
</script>

This is the “Document Ready” function. This solves the problem of running your Javascript code before your page is done rendering on the browser. Also note how easy it is to hookup an “onsubmit” event handler. You use CSS-selectors to identify what HTML element(s) to apply to, and JQuery does the rest, figuring out the best way to accomplish that regardless of your browser. Great fun.

My elation quickly disappeared when I fired this sample up in FireFox 3, nothing happened when my <form>’s submit button was triggered. Frustrated, I quickly tried it in Safari (Mac), it worked fine. I switched to the PC and grumpy IE6, and again, no luck. So what’s going on?

It turns out that the inline JavaScript will be ignored if you close the element just prior in your <head> section with the shorthand closetag “/>”.

This doesn’t work:

<script type="text/javascript" src="lib/jquery/jquery.js" />
<script type="text/javascript">
    $(document).ready(function(){
        // blah
        })
    });
</script>

This does work:

<script type="text/javascript" src="lib/jquery/jquery.js"></script>
<script type="text/javascript">
    $(document).ready(function(){
        // blah
        })
    });
</script>

Hopefully I will remember this in the future, as this is now the second time in two days I’ve wasted an hour or more wondering why my Javascript wasn’t activated.

[del.icio.us] [Digg] [dzone] [Technorati] [Twitter] More »


Author: Brett Veenstra | Category: Programmer | Comments Off September 2008

Response to Readability

JP put out another post requesting comments on a Readable (Fluent) approach he’s currently using. I tried to leave a comment, but the system wouldn’t accept anything I used for the captcha… so here goes:

JP writes:


  Run.the<wire_up_global_error_handling>()
   .then<initialize_the_container_for_the_user_interface>()
   .then<initialize_the_user_interface_registry>()
   .then<initialize_the_ui_images_registry>()
   .then<initialize_the_main_menus>()
   .execute();

Here are my humble comments: + “Run” & “execute” seems redundant + The underscores are nice to look at but CamelCasing is also easy to read (for me), and easier to type … I suppose if you’re using your AutoHotKey ninja tricks like JP does, this would be minimum overhead.

So, for the full comparison in code: 


  Start.by<wireUpGlobalErrorHandling>()
   .and<initializeTheContainerForTheUserInterface>()
   .and<initializeTheUserInterfaceRegistry>()
   .and<initializeTheUiImagesRegistry>()
   .finally<initializeTheMainMenus>();

Hopefully JP gets this via a trackback.


Author: Brett Veenstra | Category: Programmer | Comments Off August 2008

Resharper 4.0 Release Candidate Available

JetBrains has just posted their Release Candidate for Resharper 4.0.

I’m excited to see this and already have my C# tax ($99) lined up for it’s official release!

I’m officially a convert from the CodeRush/Refactor Pro camp… I just found Resharper more discoverable than CodeRush.  CodeRush definitely has a slicker UI, but Resharper lets me work more like myself (renames/namespaces/interface-based architecture) in Visual Studio.


Author: Brett Veenstra | Category: Programmer | Comments(0) June 2008