-
-
A few weeks back, Bob Flanders (a fellow consultant) and I gave an interview to SD Times reporter, Jennifer deJong on our experiences with C# and the features we were anxious for in the Whidbey release.
Here is the article based on the interview. The actual interview was about 30 minutes long so it is really scary to see it distilled down to one or two quotes (the dreaded sound byte!) but I think Jennifer did a great job of covering the bases.
A summary of my thoughts on new features in C# and VS.NET 2005
I am not as interested in the language changes as I am in improvements in the IDE. C# is already incredibly powerful with all the required semantics of a modern OO language and the power of the framework. It will be very exciting to see it progress but the greatest benefits for me will be improvements in VS.NET 2005. The pain mentioned in the article has been relieved for the time being by Resharper which is making automated refactorings possible. I am especially interested in customizing the IDE with more personalized colors/layouts/themes, further keyboard shortcuts, sharing settings and other productivity enhancements (expansions, etc). The idea of built-in coverage analysis in the IDE also sounds intriguing. I was really looking forward to one C#/Framework enhancement - ObjectSpaces - but it doesn't appear to be ready for release yet. A mature object persistence framework for .NET to eliminate all the crazy O/R mapping would be a big productivity (and application design) improvement.
-
-
Jeff Schoolcraft has recently joined Thycotic Software Ltd as a Senior Technology Consultant specializing in .NET and TDD practices. I am very pleased to welcome Jeff to the company. Jeff is also the president of the WinProTeam Vienna User Group which helps to further expand our activities in the community.
Jeff brings his expertise in .NET, ASP.NET, C#, Microsoft SQL Server, Regular Expressions and various other technologies to the team.
Jeff's new blog is here.
-
-
Setting the scene...
You are building your second large TDD project for a new client. Some of the requirements are almost identical to the last TDD project. Management is aware of this and expects some form of code reuse to occur that will save budget and time. The functionality required is separated well in the code and design but is still tied to the business tier in deployment and cannot be easily isolated in binary form.
Options tried to date:
- Copy and paste all tests and production code of interest. Then tweak the code till everything runs green. Run ... 15 tests fail ... tweak ... run ... 14 tests fail ... etc.
Pros: Simple to copy
Cons: Very negative process - lots and lots of failures - start doing anything to make it pass. Feels like the haphazard development of old. You can easily miss a requirement or add something unnecessary. Test quality tends to be low and tests are poorly understood. Takes a long time to get to green.
- Copy and paste one test, fail, paste production code, pass. Repeat and stir.
Pros: Simple process.
Cons: Test order might not match original development and therefore may not flow with available functionality. Difficult to isolate relevant production code each time. Process does not always flow logically.
- Start from scratch! Write a test, fail, add code, pass, refactor. Check old tests for ideas and check old production code for implementation when stumped. Learn from the old, improve with the new.
Pros: Our beloved TDD process with all the benefits of the process. Gives an opportunity to review the old code while flowing through the new. Feels quicker and has a definite sense of moving forward.
Cons: Should be slower and could suffer from "reinventing the wheel".
Discussion
The biggest benefit of TDD is the process. Reusing past successes while deviating from the TDD process appears to be counter productive since the process *is* the benefit. It helps to keep the pair moving forward and helps them to stay focused. The copy and paste techniques quickly returned to the hack it without a technique ways of old. Worse still, they did not bring the confidence of the red/green cycle.
(Better separation of the logic into deployable units may have made the process easier but would have involved more setup and deployment work for the initial client.)
Conclusion
This was a surprising exercise and did not produce the results that one would probably expect. Perhaps "copy and paste" reuse in TDD is like trying to eat the elephant all at once? (HowDoYouEatAnElephant)
Have you had similar experiences? How did you tackle them? What would you do differently?
-
-
The local DC and surrounding area .NET community leaders came together last night courtesy of Microsoft's local Developer Community Champion, Geoff Snowman and our new Developer Evangelist, Andrew Duthie.
Amongst all the wonderful people I met for the first time at the event was Darrell Norton whose TDD interest was especially exciting. Unfortunately with all the activity we didn't get to exchange TDD notes but I did agree to come down to speak at the WeProgram.NET UG next year.
It is wonderful to put faces to names and realize how many exciting things are happening in your local area.
Big thanks and kudos to Geoff and Andrew for organizing and there will be lots more excitement in the community if some of the discussed proposals are implemented!
Ps. Darrell beat me to the punch.
-
-
Thycotic.Data (our free, open source, database independent DAL) has finally reached the point of requiring some documentation! (The project was spawned as a result of a presentation on late binding ADO.NET Providers back in early 2003). We use it at Thycotic Software on all our projects but others in the community appear to be using it too.
Please contribute to the wiki if you are using the product.
The new wiki is here.
I did feel a little treacherous putting up a Perl-based Wiki for a .NET API but our current webhost is Linux based. We are using UseModWiki and it was wonderfully easy to install and configure. Besides I think I will always have a soft spot for Perl. :-)
UPDATE: 12/28/2004 Changed over to use FlexWiki on ASP.NET.
-
-
I will be presenting at the Inner DC .NET User Group today (11/16) on Customizing WebControls. The session will be very "hands on" with lots of code and plenty of time for Q & A. The focus will be on all the things people seem to be missing in *current* (pre 2.0) ASP.NET development.
Do all your ASP.NET pages derive from your own intermediate class derived from System.Web.UI.Page?
Have you derived from other controls such as the DataGrid for customization?
Do you have your own YourCompany.WebControls project?
Do you unit test your custom WebControls with NUnitAsp?
If not, then you are missing out. Stop along, pose your questions and share your tricks!
(Directions here, starts at 6:30pm)
-
-
I presented on "Build and Deploy with NAnt" (slides/code available) at the WinProTeam Rockville .NET User Group on 11/4.
The following are some of the questions (and my answers) from the event:
- Can NAnt be used to compile projects in any .NET language? (particularly C++ projects)
The <solution> task in NAnt appears to definitely support both C# and VB.NET project. John Lam has posted about compiling C++ with NAnt here and here.
Tracing the source code for the <solution> task in NAnt.VSNet.ProjectFactory (which appears to control the derived ProjectBase class that actually does the compilation) shows that only C#, VB.NET and C++ projects are currently supported.
if (projectExt == ".vbproj" || projectExt == ".csproj")
{
Project p = new Project(slnTask, tfc, outputDir);
p.Load(sln, path); _cachedProjects[projectFileName] = p;
}
else if (projectExt == ".vcproj")
{
VcProject p = new VcProject(slnTask, tfc, outputDir);
p.Load(sln, path);
_cachedProjects[projectFileName] = p;
}
else
{
throw new BuildException(string.Format(CultureInfo.InvariantCulture,
"Unknown project file extension {0}.", projectExt),
Location.UnknownLocation);
} |
- How does the build and deploy cycle work with multiple developers?
This technique thrives in the multiple developer environment since it provides an isolated predictable place (your integration server) to do all builds, tests, etc. This guarantees that the build is easily reproducible and independent of your development team. Your build should come directly from the source repository which then is the interface for concurrency issues on your team. Certain protocols are still necessary such as don't check in code that doesn't compile or doesn't pass tests.
While the technique works well for teams, a single developer can still take advantage of a build and deploy technique. The developer will gain many of the same advantages by always putting the build together in a predictable reproducible manner (even if he doesn't have a dedicated integration server). It also allows new versions to be quickly deployed by automating the process.
- How do you manage versions and configuration across your QA environment (test, stage, prod)?
Configuration can be managed by either using the <include> task or subnanting. Configuration within the application can be handled in a number of ways (file driven, database driven, etc) with NAnt copying over configuration files however necessary.
Versions should be moved across your QA environment using the idea of a "lastknowngood" build. This "lastknowngood" version would be a successful build that has passed all tests. It would be deployed to test then tested by the QA team then onto stage (then tested) and then production and so on ... The idea is to move your build through each stage ensuring quality at each step.
Please note these ideas are just one way to do it. NAnt provides a wealth of options and you can always choose the best set that meets your needs, environment and customer.
-
-
On our current project we have been running our NAnt build script using a Windows Scheduled Task. While this never seemed particularly sophisticated, it did the job especially given that our build (plus all test suites) takes around 2 hours to run! Today, I installed CruiseControl.NET for a dabble - my last experience was many moons ago - when SourceGear Vault support was still a do-it-yourself affair.
The SourceGear Vault support was flawless - very easy to configure and worked perfectly. Getting the ccnet.config file to work was a little confusing (firstly, realizing that the <cruisecontrol> tag does actually go into ccnet.config not somewhere in ccnet.exe.config as a .NET developer might expect), then the silly hassle with the merge task exception because the docs show the wrong element name (files/file) and that the CruiseControl.NET website with the latest documentation kept going down with proxy errors. (end of rant!) But the persistence was worth it, it monitors the source repository and automatically kicks off builds - then tracking the changes and viewing them in the ASP.NET app that comes bundled.
My initial concerns about CruiseControl.NET was what advantage it would give to kick off builds from source file checkins when your build time is 2 hours anyway! It seems that the secret is to limit your essential build tasks to a manageable timely set and then have your longer test suites (typically integration tests) run on a different periodic schedule.
One thing I did notice was that the ASP.NET portion of CruiseControl.NET seems a little slow since it appears to parse the log file on every request to display summary information. This seems inefficient since the log files do not change after the build. Adding a simple OutputCache directive to the Default.aspx page causes the pages to be cached and made the clicking around the UI a much more pleasant experience.
The key benefits that CruiseControl.NET provides over our scheduled task approach are:
- Doesn't wastelessly spin the integration server unless code is being changed
- Quicker feedback to developers when the build goes wrong (tieing it back to the offending checkin)
- Easy visibility into the build process which otherwise is a little complicated to debug
- Summary information on unit test suites
- Simplified build versioning
If you haven't tried CruiseControl.NET yet, take it for a whirl!