thomasnguyen.com blog

“What Agile really means to the future of software development“
Martin will call upon his more than 20 years of software industry experience to talk about how the history of the software also serves as a roadmap for what to expect in the future.

Martin had three very drastically different mini talks rather than a single long presentation. I really liked this approach since it helped keep my short attention span.

I. Continuous Integration and Continuous Deployment
His presentation comparing Feature Branching and Continuous Integration was just a regurjitation from his older articles, discussions from other presenters at other events, and a book he recommended by Paul M. Duvall. I won’t bore you with it.

Something that caught my eye was Continuous Deployment and what he called the “build pipeline.” He had an awesome flowchart/diagram to explain this, but I’ll try and do it with a list. I’ll include the tools I currently use in our development environment at work, if they apply.

• Commit Task – usually kicks off a full build of the main stream on a build server, not a local machine
  • Compile: Visual Studio
  • Tests: NUnit
  • Assemble: NAnt
  • Code Analysis: NCover and FxCop
• Artifact Repository – this can be a file share to maintain each build version from the Commit task above
  • Binaries: CruiseControl.NET
  • Reports: NUnit, NCover, and FxCop
  • Metadata: I have no idea what this is, any ideas?
• Acceptance Task – of a specific version in the Artifact Repository
  • Configure Environment
  • Deploy Binaries
  • Smoke Test
  • Acceptance Tests (customer focused)
• Performance Task – of a specific version in the Artifact Repository
  • Configure Environment
  • Deploy Binaries
  • Smoke Test
  • Performance Tests
• Deploy Task – of a specific version in the Artifact Repository
  • Configure Environment
  • Deploy Binaries
  • Smoke Test
  • Run

I’ve got the Commit Task and Artifact Repository down to a science at my job and it’s a good reassurance that I’m doing this right! I’m going to see what it’s going to take to get the rest of the “build pipeline” implemented. I’ll also see if Cruise is something that will work for us.

I already have so many books I’ve started reading and not finished, but Martin recommended another interesting one that’s still classified as a “Rough Cut”: Continuous Delivery by Dave Farley & Jez Humble.

II. Domain Specific Languages
I forgot my Hydrocodone in the car and my right-bottom part of my mouth was throbbing. The last time I took a pill was lunch and it’s been the longest stretch. I was a little distracted by that, so sorry for the significantly reduced notes.

Martin had an awesome explanation (in his book) about how to get from code configuration to XML configuration and then finally to a DSL configuration represented in Ruby. SO CLEAN! I really need to finish reading my books instead of starting new ones.

“XML is like violence. If it’s not working, you’re not using enough.”

Martin as also quite impressed about the possibilities of DSLs and the impact of Language Workbenches. He recommended us to watch this video from Intentional Software.

“If you try to solve a problem with regular expressions, you end up with two problems”

III. Controversial Topic: Diversity, Women & African American in Software Development
Although there were no slides, I didn’t really like this talk and I found it quite inappropriate. It is definitely a heated topic and should be discussed, but I don’t think this is the right forum. I’ll leave this topic alone.

No, not an AssemblyInfo.cs file, that’s really straightforward. C’mon it’s a task that does what it says, easy.

Something I was trying to do is update the version number in, for all simple purposes, a text file – something that’s not xmlpoke-able. So I have the property ready to go and the file I want to update!

My first thoughts were to use the loadfile to get the file into a property and replace it with the version.

Awesome, just like the sample and it echos out just fine…so now, how do I save my changes? After some digging around, I looked into the filterchain and read up on the copy task.

Seriously, copying a file now has the ability to modify the internals? Does not compute! Maybe copy, then modify. Anyway, its works now, so I can’t really complain anymore besides the hassle of finding the right task to do the job.

Now I know why James keeps telling me to get out of the XML HELL. Coding tasks in XML is just ass backwards.

Before attending the ALT.NET Houston Open Spaces Conference, I really didn’t know what to expect besides learning something. What did I want to learn? I had absolutely no idea. I just heard read good things about this event from many others at the Austin and Seattle ones. The sessions I went to were totally great and best of all, I bumped into a few familiar faces I totally didn’t expect to ever see again, hehe.

Now that I have been refreshed with a completely new eagerness to get caught up with the latest and greatest, I’m hoping to be able to contribute at the next ALT.NET conference. Ben, chop-chop, get on it! =)

Here is my main take away from the conference that I just finished.

Starting Point (x86 only): NAnt that kicks off MSBuild, runs tests, and copies to a package folder.

The problem I was running into is that I didn’t fully understand Visual Studio 2008′s Configuration Manager and how to integrate/mimic it with NAnt. I had to set the target platforms x86/x64 and it automatically configured the output paths:

Remember, these are defaults after you add solution configurations and solution platform. When you build, set the proper targets, F5 and you’re done. As for NAnt, I also had to target the proper configuration/platform:

The tricky part here for me was to get NAnt to find the x64 Framework by parsing out the x86 path and do a string replace. Unfortunately, I’m using 0.85 and it seems to have a bug when trying to pass in a variable as the input string. Currently, I have to specify the directory, UGLY.

After reorganizing a few targets and adding more to specify x86 and x64 builds, it worked perfectly. The last step I did was to ensure the builds were targeting separate platform output folders.

Now, my next step is to automate the WiX build…