Recent Updates Page 59

Hiding errors:

• Swallowing informative excpetions
• Returning a magic value instead of the error
• Ignoring errors

I’m sure many can relate this this experience:  I’m using an application or a programming API.  The code runs and returns.  I move on.  I find out later that the code failed, and the work was never done.

This scenario can kill an application’s reliability and reputation.  When this happens, you don’t find out about errors until some time later.  Because of this, you really can’t say that the application is working correctly at any point in time unless you explicitly investigate a log somewhere where errors are stored.

Hiding errors makes life harder.  Finding out about errors when they happen makes for more reliable systems.  I’ll give one quick example from the .Net Framework v2.0.  This example uses C#.
            

This seems simple enough.  We’re using the VirtualPathUtility class to convert a url to it’s application-relative form.  In this case, I’m passing an invalid argument in.  The rule this method uses is that if the url is not a part of the given application path, it’s invalid.  What does VirtualPathUtility do in this case?  It returns NULL!  I passed in an invalid argument, and it returns null.  The more appropriate response would be throwing an ArgumentException.  Because of this error hiding, I have to know the internal rules of this method and code around them.  I can’t afford for this code to continue while appRelativeUrl is null.  The next line would throw a NullReferenceException.

Because of the error hiding, my code ends up like this:

I have to do an explicit check and compensate for the undesirable behavior of the API.

If an error condition happens, I want to know about it.  The term “fail fast” is very popular.  It means that if the application encounters a condition where it can’t continue, stop now and output the exception information.  Don’t have the application limp along until it crashes in flames.  If you break your arm, you stop what you are doing and get a cast put on.  Yes, you _could_ go to work if it’s not your mousing arm, but you cause less damage if you stop right away and address the problem.

A quick google search will reveal a raging debate on the merits of SOA.  It has cooled down a bit from 2005 where every time I turned around, there was another session at Tech Ed on SOA.  The talk about SOA has just started if its landscape is going to be anything like the adoption landscape for OOP.  SOA has not lived up to it’s hype yet, but to be fair, we have to give it another two decades. 

We don’t think about it much, but object-oriented programming began in the 1960’s with the Simula language.  Smalltalk helped the movement, but C++ brought object-oriented development into the mainstream in the late ’80s when the ANSI group was formed.  From 1962 to 1989, OO was a lot of talk and theory with handfuls of folks implementing real systems using the concepts.  When C++ hit, many more programmers came on board.  Java furthered the adoption of object-oriented concepts, and .Net seems to have pulled the remaining part of the programming market into OO.  When I think about how long it has taken for the average programmer to ackowledge OOP, I wonder if it will take that long for other paradigm shifts.

It remains to be seen if SOA really has the merits granted it by all the marketing hype or if it is just a new name for integration.  We won’t really know for at least another decade, I imagine.  Folks have been integrating systems when necessary for years, so it remains to be seen if this new (everything is exposed as a service) strategy works.

I like the way Jeremy Miller puts it:  “The ‘if you build it, they will come’ approach doesn’t work.”  I agree.  As with any part in programming, building something with the wish that someone will use it someday doesn’t work.  If you are adding a service endpoint to a system out of necessity because someone else need to integrate NOW, then the business value is there, and it’s the same kind of integration that has been going on for years.  Some large companies need to integration now, and we see case studies galor: google search.

What we won’t find out until many moons from now is if these SOAs worked.  Every project is declared a success immediately after completion, so we can’t count on reported results right now.  The true test is if these integrated enterprises are maintainable and cost-effective.  Architects from big companies are saying “yes they are” right now, but no one thinks their child is ugly.

This past Saturday, March 4, my user group, ADNUG, hosted its first MSDN Code Camp.  We had some cool sponsors including Microsoft, St. Edward’s Professional Education Center, Wrox Press, 101X radio station, CyberJocks, and Catapult Systems. 

We had 17 unique sessions from local developers on tracks: Web, Smart Client, Data, and Agile.  My talk was “Pragmatic ASP.NET 2.0:  What features do I need?”.  All the sessions got very positive comments on our survey.  We targeted 150 developers, and we hit very close to our goal.  At one point, we thought we were going to be swamped because of the huge number of registrants, but the event went off really well.

Thanks to all our sponsors for helping make this event a success.

I recently came across some sql code that caught me off guard.  Here is is:

select something
from table1, table2
where table1.id = table2.id

I immediately thought that a Cartesian product was happening and the rows were being filtered afterward.  All my database experience has been with Microsoft databases, so I didn’t know that this syntax used to be the way most people did sql..  Like any good engineer, I set out to find out for myself what was really going on.

I used the Northwind database to compare the following two queries:  the first with Sql server syntax, and the second with “old school” syntax (which Sql server 2000 suppports).
SELECT    *
FROM    Orders o
    INNER JOIN Customers c ON o.CustomerID = c.CustomerID
    INNER JOIN [Order Details] od ON o.OrderID = od.OrderID
    INNER JOIN Products p ON od.ProductID = p.ProductID

SELECT    *
FROM Customers c, Orders o, [Order Details] od, Products p
WHERE o.CustomerID = c.CustomerID
    AND o.OrderID = od.OrderID
    AND od.ProductID = p.ProductID

I ran these two queries many, many times together and in isolation, and I examined the execution plans, the client statistics as well as the Sql trace.  It appears that at a lower level, these two operations are identical.  Both queries took the same Duration, CPU cycles, and Reads to execute.  Here is the Execution plan.  Both queries have this same exact exectuion plan:

Personally, I like the INNER JOIN syntax.  It’s very explicit, and it’s easy to add RIGHT and LEFT to dictate OUTER joins.  A plus is that it is the ANSI standard and Microsoft’s recommendation for Sql Server. 

The objective conclusion of this experiment is that the style picked for a query will not affect the speed at which that query runs.  The differences are subjective.  My advice, however, is that a single style be adopted as part of the team’s coding standard. 

The lates Arcast from Ron Jacobs is about NHibernate, and open-source Object-Relational mapping tool.  This podcast was particularly interesting to me because my team is using NHibernate for a project, and we are likely to use it for most data access going forward.  The data access tier is the target of many debates.  My team has weighed the pros and cons, assessed our security and performance requirements, and we have decided that using NHibernate to automate the persistence and loading of our business objects is the direction we want to go.  In has saved so many developer hours of writing boring CRUD sprocs and sql statements.  We use an xml file to map the properties of our business object to the database table, and we’re done.  We have a test-bed of integration tests to ensure that the mapping is correct.

Ron brought up an argument that some inside Microsoft have on OR mappers.  I’m paraphrasing, but this is the idea:  Developers may shoot themselves in the foot if Microsoft provides an OR mapper and endorses it. 

I’ll let that sink in.  I can’t remember a development tool that someone hasn’t managed to abuse.  Hmm.  That doesn’t seem to be a very strong argument.  You obviously don’t give an M1 Abrams tank to a novice, but in the hands of a trained professional soldier, it can be very effective.

Another point discussed was that you no longer have complete control over performance with NHibernate.  That’s true because you would be trusting the component to generate and run the sql for you.  You obviously don’t use the exact same tool for every job, and it was mentioned that the Amazon.com(s) of the world would need more control over data access than most enterprise applications.  Most internal enterprise applications only have a few hundred users (if that).  What performance do they really need?  Now, NHibernate is NOT slow, but  if you need to go 400 MPH instead of a measley 397MPH, then you have some pretty heavy traffic and strict performance requirements.  For the rest of applications, NHibernate probably offers more speed than required.

Another topic of great interest to me:  The cancelled Ojbect Spaces project.  It was mentioned that it was cancelled because of the DLinq project that was developing, and Microsoft didn’t want to have two models for OR mapping.  I’m not sure about the details of this, but it was mentioned on the show.

All in all, I like podcasts from Ron Jacobs.  He’s a great personality for a radio show, and he pulls in some interesting topics.

The FitLibrary has been recently ported to .Net, and I love using the DoFixture.  One problem is that the normal DoRow and DoCell methods of the Fixture class don’t run in the DoFixture.  With other fixtures, I’m used to hooking into to these places in order to spread logic throughout my FIT test.  DoFixture uses two new methods: 
System.Collections.IEnumerable ParameterCells(CellRange theCells)
and
System.Collections.IEnumerable MethodCells(CellRange theCells)

This is how the DoFixture implements it’s special behavior.  For example:
|MyDoFixture|
|Run System|
|Make Sure File|taxes.txt|Was Saved|

This is a simple fixture that makes sure the system saves a file “taxes.txt”.  Here, I’m not using the built-in Check method.  I’m implementing one myself.  Either the file was saved or it wasn’t.

My underlying fixture will look like this:

This works, but will throw an exception instead of failing the test.  I need to register a FIT failure and not an exception.  FIT treats these two differently.  In order to fail a FIT test, I have to use the Wrong(Parse theParse) method.  I have to have the current Parse object in order to call this method.  The Parse object is the current cell/row/table.  The FIT table is composed of a Parse hierarchy.  I don’t really like the way it’s set up, but that’s not the point of this post.

In order to call the Wrong(…) method to fail the test correctly with a reason to output to the screen, I must obtain the current Parse object.  Because the DoFixture doesn’t fire the virtual DoCell or DoRow method, I can’t use these.  Instead, I’ll override a DoFixture method that fires for every row and modify my fixture like this:

With this code, I have my fixture maintain the current Parse (I’m tracking the current row) so that when a line fails, I can properly fail the test with an appropriate message.  This is a much better solution that throwing an exception.  Throwing an exception means that the test environment blew up and needs to be fixed.  Test failures mean the code broke.  An exceptioin means the FitNesse server broke..

It’s done.  I’m booked for Tech Ed 2006.  I attended Tech Ed 2005 where I threw a pre-conference party dubbed “Party with Palermo”, and I’m doing it again this year.  Last year we held it at the Peabody restaurant the day before the conference started.  I haven’t determined this year’s location yet, but it will be the evening before the conference starts (Saturday), so plan now to attend and fly in at least by Saturday morning.  I’m arriving in Boston at 1PM on Saturday, and I’m staying at the Hilton Boston Logan:

Hilton Boston Logan

85 Terminal Road

Boston, MA 02128

Phone: (617) 568-6700

Fax: (617) 568-6800

This hotel is $145/night with the Microsoft rate, so it’s the closest/cheapest combination I went with.  I’d love to know who’s booked at this hotel as well.

If you will be at Tech Ed and would like to help plan Party with Palermo 2006, let me know.  I’ll have an RSVP as the date draws near so that we will know how many people to expect.
Go to the Tech Ed site to see hotels and rates. . . and book at the Hilton Boston Logan. 🙂

If you haven’t been to Tech Ed, I’d highly recommend it as a chance for some 1st-rate developer (and IT pro) training.  Other benefits are huge as well.  I personally love the chances to network with other people in the industry around the country and around the world.  I met so many great people last year, and Party with Palermo served as a great ice-breaker for introductions.  Even if your employer won’t pay for it, I recommend paying for it yourself.  I consider it an investment in my career.

Sam Gentile reminds us of the value of FIT when requirements might be vague _and_ complicated.  His team is using it to help the customer understand what they want.  His post reminded me of the value I’m already starting to take for granted.

My team is still early on in our FIT implementation.  We have a few components covered so far, but recently, we created a new service that runs all the time and does stuff.  Do you love the vague description?  It responds to a queue:  One component drops off some work, and it picks it up and does it’s thing.  We have this implemented as a Windows service, so it would be very difficult to test by manual means.  The tester would have no UI at all, and they would have to arrange for work to be dropped off, wait a bit and check that the work was completed. 

FIT enables a whole new dimension to testing this service.  Our tester has been creating his test cases even while we’ve been creating the FIT fixture for it.  We hashed out what the fixture would look like on the whiteboard, and then started.   We have our first draft of the FIT fixture working, and it’s a big eye-opener to be able to test a component (that has no UI) with a GUI.  These are automated tests as well (that’s FIT’s nature), and we’ll run them forevermore.  Once we have these tests passing, they will serve as a regression tests suite for this component.  When a bug arrises, we’ll create a FIT test to isolate the bug and then fix it. 

We’re using the FitNesse wiki to organize our FIT tests.  We’ve set up a special CC.Net build that detects wiki changes and commits those to Subversion.  Our CC.Net build for the component pushes the latest bits to the FitNesse wiki so the FIT tests are always run against the current build.  Read how we integrated FIT into our build here.  Read how we versioned the wiki here.  Mike Roberts has done something similar as well.
 
For this work, we’re using the newly-ported FitLibrary‘s DoFixture.  The DoFixture allows a very intuitive layout of the test.  For more information, I’d recommend reading the FIT book by Ward Cunningham and Rick Mugridge.

My good friend Blake Caraway has finally started his blog.  Look forward to some great technical content from this guy!

Matt is already on his way to MCPD, wich is Microsoft Certified Professional Developer.  For those who have the MCSD.Net certification, the upgrade requires two exams.  I hadn’t been keeping up with when the upgrade exams would be available, but they are now, so I’d better hustle!

Here’s the MS information on the topic:  http://www.microsoft.com/learning/mcp/mcpd/entapp/