After several years of maintaining this rather neglected blog at dotnetjunkies.com, I've decided to try and inject some new life into by upgrading to WordPress and moving it onto my own site: http://exortech.com/blog.
Coming back here and making this post reminds me of how much I dislike CommunityServer (or at least the version that is running on this site). There's no support for FireFox in the HTML editor, the navigation system is unintuitive, and there's relatively little support for plugins, images and code snippets. Moving is the right thing to do...
We recently converted CCNet to .NET 2.0, and I've been changing the code to start to take advantage of some of the changes in the .NET 2.0 release. One area of the framework that seems to have undergone a bit of a facelift is System.Xml as is evident by the number of obsolete classes and methods. The biggest apparent change is the recommendation to instantiate all XmlReaders via a factory method. I certainly support the intention behind this as the plethora of different XmlReaders all optimized for different tasks is something that should be encapsulated. However, I think that it is a bit of a shame that they decided to implement this through a factory method on XmlReader rather than more cleanly via separate factory class.
The biggest problem that I've found with this change is that not all of the different reader configurations are specifiable via the XmlReaderSettings. For CCNet, we allow users to set up DTD entities within the CCNet configuration files in order to minimize duplication. Under .NET 2, to instruct a reader to expand these entities, you need to set the EntityHandling property to EntityHandling.ExpandEntities (this required some digging to figure out as it just happened automatically in .NET 1.x). Unfortunately, this property is only delcared on XmlTextReader and not on the XmlReader base class. This means that you need to downcast the XmlReader that you get from XmlReader.Create() in order to set this property explicitly, which defeats the purpose of encapsulating the type of the reader behind the factory method. It seems to me to be an oversight to have neglected to include this property on the XmlReaderSettings class.
Often when working with Windows services, I've wanted to have the ability to log in as the LocalSystem user in order to try to diagnose problems. For example, one recent problem that I was experiencing is on ccnetlive we run CruiseControl.NET as a Windows service under the LocalSystem account. The problem was that when accessing a Subversion repository over SSL, you are required to accept the certificate from the remote host. Accepting the certificate requires responding to a command-line prompt. Once accepted, this certificate can then be cached permanently, so it is not necessary to re-accept the certificate -- at least until it expires. Unfortunately, there is no way to log in directly as the LocalSystem user -- so the runas command will not work. In trying to find a solution to this problem, I came across a very useful blog post that describes creating a Windows service that simply opens a new command shell. As Windows services, by default, run under the LocalSystem account, this command shell window is open under the LocalSystem account.
One of the less enjoyable things about Subversion is that it is quite picky about linefeed consistency in committed files. Are you using CRLF or just LF? Personally I don't really care as most editors can handle this. I'm sure that there is a perfectly good reason for Subversion's enforcing this, but it is a hassle when you have a bunch of modifications to process and the commit keeps failing part way through telling you that yet another file is inconsistent. I came across a little free utility called
ToFroWin CR/LF converter that has saved me hours of tedious effort to ensure that line feeds are set consistently for a set of files. It plugs into Windows Explorer allowing you to easily convert selected files back and forth between different linefeed formats.
CruiseControl.NET has been registered on OLOH, a repository of statistics and information on different popular open source projects. If you are using CCNet and you feel so inclined, please check out the site and give CCNet a review or a rating and stack it.
According to the collected statistics, we've expended an estimated 22 person years on this project (based primarily on code changes), which at a (low) salary of $55000USD puts the cost of replacing the project at a cool $1.2M. *sigh*
Today, minority government leader Stephen Harper announced that he would be reshuffling his cabinet. One of the key ministers who will be moving is embattled Environment Minister Rona Ambrose. Stating that she found the environment ministry "too challenging", Ms. Ambrose will likely be moved off into another ministry such as Indian Affairs where she can spread her uninformed and narrow-minded views amongst Canada's aboriginal communities.
Despite her claims of finding the post to be too challenging, Ms. Ambrose has acheived a great deal during her tenure. For those unfamiliar with her accomplishments, think of Ambrose as Canada's equivalent to Christine Whitman, the neo-con appointee to head the EPA. Under her leadership Ambrose has skyrocketed the environment as the number one issue of concern to Canadians, ranking above even health care and Canada's ill-considered role in Afghanistan. Through her Clean Air Act, which attempted to befuddle the issues of global warming and air quality, to her displays of parochialism and aggression at the recent climate change meetings, Ambrose has done a tremendous amount to generate antipathy both at home and abroad. Through her actions, Ambrose has made a generous contribution to Stephane Dion's pro-environment Liberal leadership victory, paving the way for the Liberal party to return to government in the forthcoming election. In short, she has helped make the environment one of the galvanizing issues that could sink her government. Most environment ministers would consider these achievements to be a hallmark of success; though Ambrose seems too humble to stand up and accept the credit.
Not in recent memory has a politican done so much for raising public support for environmental issues, other than George W. Bush who, if not for the larger boondoogle in Iraq might have more of the American public paying attention to the environmental super-villains that they've become. Farewell Ms. Ambrose, we will miss you.
| On Thursday November 9th at 8.30pm, my wife gave birth to our beautiful new daughter, Faro Desiree Rosalie. We have been home now from the hospital for a couple of weeks, and mother and daughter are both doing very well -- apart from a general lack of sleep. Faro is feeding well and gaining weight (about 60g per day) and growing quickly (she's already grown out of a couple of her outfits). Now we're just looking forward to the time when she can sleep through the night. I'm heading back to work today after a couple of weeks of parental leave; it has been fascinating to have the privilege of watching her grow and develop so quickly already. |
 |
From Fast Company:
Media accounts often report that a typical Toyota assembly line in the United States makes thousands of operational changes in the course of a single year. That number is not just large, it's arresting, it's mind-boggling. How much have you changed your work routine in the past decade? Toyota's line employees change the way they work dozens of times a year.
Now that's something to aspire to within software teams.
On November 15th and 16th, Vancouver will be hosting its first conference on Agile Software Development. The conference will be a great opportunity for local newbies and practitioners to meet up and learn from each other. We have lined up a great array of local and imported speakers, including Linda Rising, Mary Poppendieck, Scott Ambler, and many others. The conference will be held at the Plaza 500 (Cambie and 12th Ave), near Vancouver City Hall. Visit the web site at www.AgileVancouver.ca for registration and further details.
Jamie Cansdale's added support for executing unit tests via NCover in the latest builds on
TestDriven.NET. Running the
Test With ... Coverage context menu option pops up an
NCoverExplorer window using colour coding to show which lines have been covered by your tests.
It's definitely a nice feature and it helps reduce the analysis tool feedback loop that I've
blogged about previously.
My only criticism is that the NCoverExplorer treeview doesn't open up
to the class-under-test. Maybe this would be hard to divine.
I'm also pretty excited about the support that Jamie has added to add
custom tools to the TestDriven.NET context menu to run against the
assembly-under-test. I tried adding the necessary registry entries in
order to get Simian to execute, but I didn't have much luck getting
this entry to show up in the context menu. I think that this kind of
integration has huge potential and hopefully TestDriven.NET will
continue to build support for this.
Scott Hanselman has put together a podcast on Continuous Integration and CruiseControl.NET.
Check it out.
Reading the coverage of the Canadian election in the american media
makes me sick. The unabashed support for Harper would make you
think that the Conservatives would be the obvious choice of any
"thinking" Canadian. I especially like the frequent dismissal of the
NDP as "left-wing" -- as if this appendage was sufficient to relegate
Jack Layout to the outer reaches of the political spectrum with the
commie-pinko terrorist party. And I especially cringe when I read
how Canadians apparently turned their backs on the Liberals because
they wanted to select a leader who could "repair the relationship with
the US". Hello? Canada-American relations didn't factor as
an issue in the campaign -- other than that all leaders went to great
lengths to distance themselves from it. Even Stephen Harper wrote
a pointed letter to a Boston paper that tried to paint him as GW's new
best friend. Somehow this belief that Harper was swept into an
underwhelmingly tiny minority on a wave of pro-American sentiment has
stuck. I can't help but think that there's this pathetic little
hope that "maybe the new guy will like us more now that the rest of the
world has stopped coming over to play". There's only one way to
improve Canadian-American relations: regime change.
With a Conservative sweep across the prairies in last night's election,
Alberta is starting to look like the new Bloc. With this
collective turn against the scandal-laden Liberals, one might think
that Albertans believe that there's no corruption in the oil patch.
I'll speaking at the next Agile Vancouver meeting (Jan 30th) on
agile estimation.
In the same way that the US swung to the right to express their
disapproval of Bill Clinton's sexual indiscretions, Canada is poised to
make the same mistake by rallying behind Steven Harper and the
Conservatives as a punishment for the Liberal government's sponsorship
scandals. Like many Canadians, I'm left wondering at what cost.
The scandal and subsequent inquiries have already come at considerable
public expense -- to say nothing about the cost to national
pride. Corruption in politics is systemic, especially where
separatist dealings are concerned, so evidence of it should come as
little surprise. I'm certainly suspicious of any party that tries
to preach from moral high ground. Witnessing the flagrant
cronyism and backroom dealings in the current Republic administration
hardly lends support to the belief that the right is immune from
corruption. More the opposite and to the extreme. And in
this quest for retributive voter justice, many Canadians seem to be
prepared to compromise their values, our values, to get a crack at
seeing Chretien on the stand by electing a leader who is
anti-environment, anti-gay rights, anti-abortion and anti-social
programs; a leader and a party who have built their platform on
appealing to greed and spectacle. Like many American friends who
have spent time out of the US and seen how their country's image has
been tarnished under the Bush regime, I'm fearful, for the first time,
of becoming ashamed of my country.
I've just been to the end of the world and back. For our belated
honeymoon, Fiona and I spent 2.5 weeks travelling to Patagonia and
Easter Island. Pictures from our trip are up on
flickr.
One of the main limitations of most code analysis tools is that their feedback cycle is too slow. Generally I have my code analysis tools, such as FxCop, or NCover or Simian run in my build process -- either locally before I check in or on the integration server after I've checked in. The problem is that the feedback from these tools generally comes too late for me to want to do anything about it. If I run it before my check in then I don't really want to mess with the files that I'm about to commit as I've made enough changes already. And if I run it after the check in then I'm generally ready to move onto something else -- I don't really want to go and start working on the same files again.
In my opinion, the right time to get feedback from code analysis tools is when you're working on the files in the IDE. This is where ReSharper's little green box in the right hand corner of the screen is a thing of beauty. If my class contains compilation errors this box is red. If it contains unused using statements or unused code statement then the box is orange. This provides me with all the feedback I need to realise that the code is not yet done. ReSharper's analysis engine runs asynchronously in the background, analysing my code as I change it and providing feedback on the results. It would be lovely to be able to integrate new rules, validations or other analysis tools into this feature, but I have no idea how to do this or if it is even possible (knowing JetBrains, they've probably already thought of this).
So I started thinking about what simple things I could do right now to work towards this goal. External tools provide a simple way to hook applications into the Visual Studio IDE. Pairing with my colleague Alex, we created a simple External Tool reference to run Simian to detect duplicated code in the currently open file. This proved to be very easy; here is the configuration that we used:
- Command: \simian-2.2.2.exe
- Arguments: $(ItemFileName)$(ItemExt)
- Initial directory: $(ItemDir)
- Select "Use Output window"
Once you set up an External Tool, you can then attach a keyboard short cut to it. I've now got Simian running over the current file every time I press Crtl-Alt-1. Pretty sweet.
I also looked at doing the same thing with FxCop:
- Command: \FxCopCmd.exe
- Arguments: /console /f:$(TargetName)$(TargetExt) /t:$(ItemFileName)
- Initial directory: $(TargetDir)
- Select "Use Output window"
This works fairly well, but it is not as nice as the Simian integration. Simian works from source files, whereas FxCop works using binaries; this means that you need to recompile each time before you run the analysis. You can also use the "/p" argument to specify a FxCop project, so that you can customise the rules that you want to run; though this does require setting up the project and maintaining the rules through the FxCop client. FxCopCmd also produces a lot of header output that it would be great to strip out and ignore. Maybe I'll try creating a stylesheet so that I can limit it to just include the results.
The next step would be to build some kind of a Visual Studio add-in, but that's a much larger proposition. External tools provide a simple mechanism that I can leverage right now to integrate code analysis tools into the IDE so as to shorten my feedback cycle.
When a bug is found in production, who's to blame? Is it the tester for letting the defect slip through? Is it the developer for introducing the bug into the code into the first place? Is it the analyst who neglected to anticipate the myriad ways in which the system could be used? Or is it the project manager who did not allocate enough time for testing?
Clearing trying to find fault is going to be neither helpful nor accurate. Once the blame game starts, everyone starts ducking and pointing the finger. On waterfall projects, too often the blame ends up focussed on whoever was last caught holding the bag, which is usually the testing team. Clearly there is an element of accountability on behalf of the entire team, but this fact is too often obscured by the need to find fault.
I've just started reading Michael Feathers' Working Effectively With Legacy Code. One of the points that Mike makes at the start of the book is the impact that the fear of changing code has in degrading the quality of design -- specifically, how this fear is heightened in areas of high code reuse. Developers working on complicated legacy (aka untested) code engage in what he calls cheekily calls Edit and Pray.
At ThoughtWorks, I get to read a lot of code from different sources: code submission are a part of our interview process and, as a consultant, I've moved between a variety of different projects. One common code smell is long methods. This always struck me as odd as the advantages of small methods seem readily apparent. I previously chalked this up bad habit up to laziness or inexperience or lack of adequate tool support; however, reading Mike's book has given me a different perspective:
Many people regard introducing methods primarily as a form of code reuse (rather than as an aid to readability). Reused code is code that is scarier to change because it is much harder to tell what the impact is of changing it. On the other hand, when your code is all in one long method, it is clear from the scope that the code can be used in that method alone. Therefore, the fear of changing potentially reused code can be a disincentive to introducing new methods (especially in languages without access modifiers). I don't know if any of the writers of these long methods actually think this way, but it is an interesting perspective.
I've just put the finishing touches on the new release of CCNet. As I'm now back in Toronto after 1.5 years of living in India, I've had a bit of time on my hands between projects to get the release out. A fairly good set of new features: you can check out the release notes here.