Anyone who is doing TDD with .Net _must_ check out TestRunner from MailFrame.net! It brings the hierarchy of tests into a VS pane and allows you to select and run tests just like NUnit, but from within VS. It uses the NUnit core and frameworks internally. It’s free for personal use, but only $49 for commercial use! Here is a screenshot:
I excited to announce that my “Agile Methodologies with .Net” Birds of a Feather session was accepted for Tech Ed 2005! Thanks to all who voted for it, but more importantly, I’m excited that there are many people interested in doing Agile development with .Net.
Here is a quote from the email I received:
“We’ve heard the feedback loud and clear from previous conferences: a Birds of a Feather session is a discussion; it is not a presentation, lecture or breakout session. Birds of a Feather sessions fill a niche in the conference – it is an opportunity for attendees to connect and interact directly with one another, to be part of their community.”
I hope to be able to facilitate a great discussion where we can all learn from each other.
This session will be on Wednesday, June 8th at 7:45PM.
That’s exactly what I’m doing right now. My development shop used to be MSF waterfall and is now pushing for CMM. This is a push from management. It is very difficult to write good, maintainable software in this fashion. Sure, we can crank out version 1 and maybe 2 without a hitch, but as soon as the developers who intimately know the software leave, or forget, you immediately have legacy code. You don’t know what you can change without breaking other things.
I don’t recall from whom I heard the quote, but I’ve heard it said that:
Legacy code is code for which there are insufficient unit tests.
I could not agree with that more. I’m the pusher for TDD in my work group, so it’s difficult getting there, but there is a significant difference in the code that is written using TDD and the other code that exists (and is being added) without unit tests. The design is different too (TDD is design). It is incredibly obvious that 1) the TDDed code has fewer bugs and can be changed with confidence, and 2) The other code is a ball of mystery (legacy) that you don’t want to touch for fear of unforeseen consequences.
Another Agile practice I’m pushing is automated builds. Our build is scheduled to run twice a day. It does everything to get the new source built an on a development server. It runs the unit tests and reports. I use NAnt for that, and it works very well. I intend to hook up FxCop and CruiseControl.Net to our build process soon.
One thing I’m not sure will change is the manner in which we plan projects. Our project managers _must_ use CMM in their planning, so it’s probably a losing battle right there. The schedule will be set, the features will be planned, the headcount will be assigned, and then it’s expected that the team deliver 100% of the scope on the due date. No incremental releases with requirements verification and reprioritization, but pure waterfall. Plan phase, dev phase, stabilization phase, and deploy. Then 5 years down the road, replace the app because it’s become hard to maintain, but create the new app in the exact same manner. It’s quite confusing.
I also have some more general observations about much of the industry as a whole. I’ve heard when replacing an application that “we’re going to do it right this time”. I firmly believe that the first go-round was not preceded with the thought “let’s do it wrong this time”, yet when we identify that an app has turned out to be unmaintainable, and it needs to be replaced, why don’t we identify the reasons it became unmaintainable? Why don’t we fundamentally change the way the new app is written because just rewriting an app using the same process as the first is going to get the same result as the first.
If an application needs to be replaced, we should analyze why it failed. If it didn’t fail, and we just want to move to a new technology, then pieces of it should be wrapped and leveraged in the new app. If that can’t be done, then I would say the old app failed. It can’t be reused. It’s life is over. Going a step further, if you absolutely want all the code to be in the new technology, then just port the code. If _that_ can’t be done, then the app is a failure. The app is dead.
Agile methods, coupled with able developers, promise (and deliver) maintainable, well-designed software that will never become a rigid legacy application. As the word implies, the application will remain agile.
Jeremy Miller has posted a great list of tools he’s currently using in his Agile shop. I’ve using a few, but I’d like to use more.
http://jeremydmiller.blogspot.com/2005/04/bypass-vsts-and-get-yourself-poor-mans.html
I received some good responses from my initial announcement of a party on Saturday, the day before the PreCons.
We’re only about 5 weeks away, so I need to start getting a list of people who are planning on being there. A comment to this post is adequate.
Also, if anyone would like to help me plan the event, please chime in.
With the .Net implementation of web services, you can design the schema of a web service call without having to author WSDL by hand. I won’t discuss contract first here. I recognize that many are happy with the default .Net implementation of a webservice. It is possible to easily affect the Xml format of the SOAP envelope, however. Mainly, you need to define the Xml structure of the SOAP envelope. By default, .Net makes nodes with your parameter names, like so:
POST /webservicetest/movie.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: “http://palermo.cc/Foo”<?xml version=”1.0″ encoding=”utf-8″?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<Foo xmlns=”http://palermo.cc”>
<firstParam>string</firstParam>
<secondParam>string</secondParam>
</Foo>
</soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length<?xml version=”1.0″ encoding=”utf-8″?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<FooResponse xmlns=”http://palermo.cc”>
<FooResult>int</FooResult>
</FooResponse>
</soap:Body>
</soap:Envelope>
What if I don’t want to expose my naming conventions in my soap message? Moreover, I have specific names that I want for the Soap message. I can add XmlElement attributes to the parameters to customize the Soap message:
Here is the part of the SOAP message that is changed:
<?xml version=”1.0″ encoding=”utf-8″?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<Foo xmlns=”http://palermo.cc”>
<ProductCode>string</ProductCode>
<Quantity>string</Quantity>
</Foo>
</soap:Body>
</soap:Envelope>
Because .Net uses the XmlSerializer for Soap-object conversion, the service Xml schemas can be completely customized. Another one of my favorite things is to return a object from a web service while ensuring the contract is explicit. On my object, I implement ISerializable and define my format.
I’d like to add an extra tip to make you a better ASP.NET developer:
8 Tips to make you better ASP.NET developer
A nice list of tips, plus links to other good resources.
At first glance, the NAnt .build files may seem daunting, especially the really long ones, but the documentation for NAnt is superb!
I wanted to start with a real VS solution instead of the trivial HelloWorld .cs file, so I used my Model-View-Presenter demo solution. Since this was a Visual Studio solution, all I had to do was add a Solution task in the build file.
Here is my build file. Now if that doesn’t convince you that automated builds aren’t that hard, I don’t know what will!
<project name=”Model View Presenter with Repository” default=”rebuild”>
<property name=”configuration” value=”release”/>
<target name=”clean” description=”Delete all previously compiled binaries.”>
<delete>
<fileset>
<include name=”**/bin/**” />
<include name=”**/obj/**” />
<include name=”**/*.suo” />
<include name=”**/*.user” />
</fileset>
</delete>
</target>
<target name=”build” description=”Build all targets.”>
<call target=”build.solution”/>
</target>
<target name=”rebuild” depends=”clean, build” />
<target name=”build.solution”>
<solution configuration=”${configuration}” solutionfile=”MVPWithRepository.sln” />
<property name=”expected.output” value=”View/bin/${configuration}/View.exe”/>
<fail unless=”${file::exists(expected.output)}”>Output file doesn’t exist in ${expected.output}</fail>
</target>
</project>
Last weekend, I participated in the MS 150 bicycle tour from Houston to Austin to raise money for the MS Society. It’s a crippling disease for which there is currently no cure. I’m really sore, but I’m glad I did it. This is the second time I’ve done it, and I averaged 15.3 miles through the full 180 miles in two days.
If you’d like to donate to the MS society in my name, just follow this link: http://ms150.org/edon.cfm?id
This is the first year that there was a Texas A & M riding team, and we had a blast. We had 75 members, and Saturday night in La Grange, we woke up the campgrounds with an Ol’ Army yell practice. I look forward to next year and an even bigger Aggie team.
I’m a bit behind the curve on this one, but I’m now developing with the 30 day trial of ReSharper by JetBrains. I haven’t even tried all of the features. There are keyboard chords and hidden features I need to learn. The obvious ones are code-formatting and general helping you out. It will close your braces, parens, quotes, etc. It color codes different types of members.
As I get more into Agile development methodologies, I’m trying to leverage more tools in order to be more productive.
