Continuous Integration Gotcha: NAnt empty elements
Posted by Brett Veenstra
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" />
Gotcha of inline Document Ready function for JQuery
Posted by Brett Veenstra
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.
PhotoWalking - Metro Detroit - September 21
Posted by Brett Veenstra
Mark your calendars for Sunday, September 21 from 4:00 - 8:00pm. We’ll be meeting in Ann Arbor at “The QuadDiag”. The QuadDiag is the large walk area just in front of the main library. Grab parking where you can find it and meet up with us. We’ll start walking at 4:15, and we should have a sunset around 7:00pm.
I’ve posted a central page with full details here.
UPDATE: Ashamed as a U of M Alumn that I mixed up my Quad and Diag terms. We’re meeting in the Diag (don’t step on the M!).
Response to Readability
Posted by Brett Veenstra
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.
Resharper 4.0 Release Candidate Available
Posted by Brett Veenstra
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.