thinking-out-loud

TestDriven.net and VS 2005

I wrote a while back about the Visual Studio-integrated test-first development tool, TestDriven.net.  Unfortunately, the main site still leads you to the v1.0 download.  But, if you're using VisualStudio 2005, you'll need this improved 1.1 version.

Patterns for SOA and the Enterprise Library

I was recently sent a copy of Ron Jacobs' presentation on Patterns for Service Oriented Architecture.  It's not too deep, but I agree with it completely.  And, clients who went to see him present it at the local DNUG said it helped them better understand how SOA is relevant to their enterprise.  Every little bit helps.

A couple of days later I had the pleasure of meeting Ron and hearing him present on the Enterprise Library.  While it's been around a little while, many still haven't heard of or at least used this collection of "application blocks".  These components simultaneous add architecturally significant capabilities to enterprise apps easily while exemplifying via open source the MS way to structure code.  Version 1.1 was recently released for compatibility with .Net v2.0.  A new version of the library (v2.0?) is due out in a few months, implemented in .Net v2.0 and exemplifying its use.

Ron's a fun presenter and apparently shares a disdain for Typed DataSets being used in all MS developer tool presentations.  "They have their uses", he allows, implying not many.  My question is, when will the rest of MS start evangelizing good architecture instead of just binding user controls straight to SQL queries or Typed DataSets?  Layers, people!  Layers!

On the (sort-of) cutting edge, Ron very briefly showed the practices and patterns team's up-coming Guided Automation Tool (GAT, as in "I got my GAT and I'm not afraid to use it").  Didn't see much other than yet-another-code-generator for Table Data Gateways, yawn.  When I inquired about the now defunct ObjectSpaces he said, "This is infinitely more flexible."  Uh-huh.... Infinity is a very big number.  Guess we'll just have to wait and see. 

WaitHandle trivia

I learned a couple of things about WaitHandles this morning (8/14/2005) that I didn't know before:

1. WaitHandle.WaitAll doesn't work on STAThreads.
2. WaitHandle.WaitAll and WaitHandle.WaitAny are limited to 64 handles.

I found this out in the context of some testing. I wanted to write a class to encapsulate piping data from one stream to the next using the asynchronous read/write methods on stream. I added a ManualResetEvent to the class so that I could tell when the process was complete. After getting it to work for one, I kicked up about 100 of them and then called WaitAll to see what would happen.

First, I got the STAThread-related exception. This one was interesting to me, because I was running my test via TestDriven.Net's "test with debugger." Normally, I love "test with debugger."  Oh well.

So, I create a console driver app, newed up a Test instance, SetUp, Test method, Wham! 64 handle limit. OK, so a little arithmetic can help out with that.

Then I set the number of pipes to 1000. The test read the file into a memory stream, converted to a string, and compared to a string obtained by reading the file via StreamReader.ReadToEnd(). It blew up with an OutOfMemoryException. It wasn't obvious to me why that was true at the time, but CLR Profiler impressed upon me the reason. I had been increasing the size of the file to try to get the system to require more threads, but I wasn't having much luck, so I made the file bigger until I noticed a non-negligible difference in the amount of time the program actually ran.

The test file that I was reading in was ~3MB.

3MB *1000 = 3GB. D'oh.

How could I overcome this??? Another way would be to throttle the number of concurrent pipes. One way would be to meter my usage of internal memory buffers, i.e. create a pooled set of byte buffers. Finally, I could make a test stream that verifies the values byte-by-byte, in hopes of minimizing the memory consumption. This would be closer to the usage model that I intend, at least initially. Haven't gotten there yet, but I will do that next. I will probably end up with a solution that uses a combination of all three approaches, or at least the last two.

Sidebar: What happens when you enter http://testdriven.net into your browser? 400 - Bad Request. It is 2005. I shouldn't have to type "www," should I? I need to create a hall of shame web page of site that require www. Of course, int TD.NET's case, I love the ide integration so much that I am willing to dismiss both the STA and www issues as nuetron-sized nits.

More: Agile vs. Formal

Greg Vaughn piped in on the Agile vs. Formal question I had yesterday, suggesting 'delayed validation' as a contrast to agile (borrowed from Alan Francis.) Alan links to an image on wikpedia showing The SLDC (as opposed to a SLDC), and how things get validated -- and it is a beautiful, beautiful diagram.

Formal vs Agile?

I have been reviewing the MSF lately, and it would seem that the MSF distinguishes non-Agile processes as "formal" processes. I am wondering out loud whether that is a good choice of terms? It seems to imply, by comparison that an Agile process is an informal approach to software development. If that is an intended distinction, then I think that the MSF is missing the point.

Stealing the following definitions from answers.com (via google, tyvm),

1. 1. Relating to or involving outward form or structure.
   2. Being or relating to essential form or constitution: a formal principle.
2. 1. Following or being in accord with accepted forms, conventions, or regulations: had little formal education; went to a formal party.
   2. Executed, carried out, or done in proper or regular form: a formal reprimand; a formal document.
3. 1. Characterized by strict or meticulous observation of forms; methodical: very formal in their business transactions.
   2. Stiffly ceremonious: a formal manner; a formal greeting; a formal bow to the monarch.
4. Having the outward appearance but lacking in substance: a formal requirement that is usually ignored

I think that 1, 2, and 3a can all apply equally well to Agile methods. You might agree if you have ever:

• had a scrum master that calls you into line for straying from the daily scrum format
• executed (or tried to execute) test-driven design
• refactored in the way that Martin Fowler suggests -- baby steps, always getting back to a working system as soon as possible.

I cynically think of waterfall as 3b or 4.

If I were trying to distinguish, I would choose agile vs. rigid.

IBM EJB: Both

Oh, and did I also mention that IBM WebSphere is an exemplar of why EJB is a giant PoS? IBM, you get the award. WSAD+WebSphere+EJBs: a magical combination of suck and blow.

EJB: Suck or Blow?

Don't know whether I ever mentioned it or not, but I have always considered EJBs to be a huge pile of shit. One question I could never answer, though. Do they suck, or do they blow?