Patrik L�wendahl's shout

Registered at the PDC

Mon, 7 Jul 2008 22:00:07 GMT

I just registered me and my colleague Fredrik Norm�n to this years PDC in Los Angeles. The flights aren't booked yet but we'll be staying at Westin Bonaventure a little bit from the conference center but still on walking distance.

And yeah, they got a spiral running track smack in the middle of the hotel. Check it out: http://www.starwoodhotels.com/pub/media/1004/wes1004fc.14807_md.jpg

For any Swedes going there, have you booked hotels? When and where are you leaving from? Send me an email to patrik.lowendahl {at} cornerstone.se so we can try coordinate.

Anyway's, I'll hope to see as many as possible over there :)

A default architecture – without stored Procedures

Fri, 27 Jun 2008 15:15:27 GMT

I'm aware that this is a very heated debate, I'm also aware that however I form this post there will always be opinions that are opposite from mine. But never the less I would like to write a little about why I put stored procedures on the substitutions bench and only call them in where something can't be solved in any other way.

To be clear; My position is not that stored procedures are "evil" or have no use at all, my position is that stored procedures usually forces me to abstain other technologies and techniques I value more. Furthermore, there are will always be scenarios where stored procedures is the preferred solution, I just don't believe in making them my default choice.

So let's get to it, first my main pain points:

Pain point #1: Stored Procedures lack proper version management

Sprocs don't version easily. There are a lot of challenges with version management and sprocs the database can only have exactly one version of the sproc at any given time. If I want to support two versions I need two separate sprocs. This might seem trivial but when you build multi-tenant systems where versions aren't just about bug fixes and new features, but slight nuances in the way they should behave for different tenants (customer Acme's business differs from customer Mechanics business), it becomes a bit more messy.

Additionally, for a long long time there hasn't been a good source control story around sprocs. That have change now with the new database role in Visual Studio 2008 Team System and the database project type (which rocks btw). Even though I like the database role I still feel that the story around code versions and version control isn't strong enough and therefor pains me.

Pain point #2: Stored procedures forces me to maintain two code bases

Having code in the database forces me to maintain two different code bases and maintain two different skill sets. It also moves me out of my environment with the tools I'm used to have like ReSharper, a proper debugging environment and all the other nice things I use when writing C# code. Maintaining two code bases also makes me less flexible, less agile if you will, and I just don't like it.

Pain point #3: T-SQL Doesn't express business logic well

I can't say I'm an expert on T-SQL, but I'm fairly good at it. My view on T-SQL is that it's really good at querying but for expressing business logic it lacks a lot of constructs that I get from a good solid OO language. I can't use well known patterns like the strategy pattern to vary calculations or other parts of the business logic, it's much harder to take other factors then pure data from the database in account when working out the logic. And frankly it is ugly and have very poor readability. Which in terms means that it will be much harder to maintain.

Pain point #4: Stored procedures are hard to test

It's impossible to test sprocs in isolation. It's also impossible to test sprocs without firing up a database. Testing with a database takes a lot of time and a lot of effort. Microsoft has, again, improved this area a bit with their Database role in Visual Studio 2008, but it's not really enough for me. My testing requirements go past the functionality I get from Visual Studio. Sure, for testing database interaction it works like a charm but for proper unit testing it just doesn't cut it. Also since sprocs often look like transaction scripts, they are usually these big things and it's very hard to test parts of the sproc in isolation, you have to test everything or nothing.

Pain point #5: Stored procedures forces me to write T-SQL for trivial tasks

Why should I have to write trivial T-SQL queries myself when I can have a tool do it for me? No doubt that if I'm really, really good at writing queries for my scenario and stick them into a sproc that I might get a little better performance then something auto-generated and generic. But is it worth the time you have to put in? I don't think it is. If I got a serious performance problem I will address it when it arises, not before. Premature optimization being the root to all evil and all that. I really believe that the gain I get in productivity is worth the loss in performance (if any; putting a query in a sproc doesn't guarantee better performance). It might even be that the tool generates better queries then those that I can write myself (and that probably goes for some of your queries as well ;)

Edit @ 16:13, forgot one :)

Pain point #6: Stored procedures are static

Stored procedures are not flexible around parameters and for every variation of parameters, joins, orders or other differences I might want; I need a separate sproc to support it. This means that if I want a query that is slightly different I need to copy and paste the sproc, change what differs and now maintain two similar sprocs, remember to change them both. Again, maintenance suffers.

So what do I suggest instead?

My last pain point kind of reveals where I'm going with this. I prefer dynamic SQL generated by a tool. I prefer it because it lacks the above pain points and makes me much more productive.

That's why my default architecture always starts out with an ORM and dynamic SQL if I need to talk to a database, it will generate all the trivial SQL, it will enable me to test in isolation, there will only be one code base to maintain, versioning works a lot better and all my favorite tools will help me write good and solid code.

Does that mean I don't use sprocs at all? Certainly not, but dynamic SQL is my default and I call sprocs in when I think I need them, which these days are very very rare.

The coming weeks I'll try to explain some of the misunderstandings around dynamic SQL in comparison to sprocs and also talk a little bit on particular solutions and how I go about them.

More information on ...

... visual studio team system database role: http://msdn.microsoft.com/en-us/vsts2008/products/bb933747.aspx
... ReSharper: http://www.jetbrains.com
... Object Relational Mapping: http://en.wikipedia.org/wiki/Object-relational_mapping

... Transaction Script: http://www.martinfowler.com/eaaCatalog/transactionScript.html

HYPER-V Is Live

Fri, 27 Jun 2008 09:23:27 GMT

Microsofts biggest investment in Virtualization Technology has finally arrived. For various reason I've been using VM-Ware the last year or so instead of VPC / Virtual Server but it's going to be interesting to really try HYPER-V out. I just installed my new laptop with 64-bit Windows Server 2008, time to activate and install the virtualization role :)

More information ...

on the announcment: http://blogs.technet.com/stbnewsbytes/archive/2008/06/26/it-s-here-windows-server-2008-hyper-v-is-available-for-download.aspx

on Hyper-V: http://www.microsoft.com/windowsserver2008/en/us/virtualization-consolidation.aspx

Having A point of view – Not as easy as It might seem

Thu, 26 Jun 2008 22:36:26 GMT

The last couple of months I've been in several positions where I've had the opportunity to talk to a lot people and express my point of view on things. I base my position on discussions with other people, theory, experiments and past experiences from projects. More then once now I've heard those view points come back to me in through back channels where they've taken wide loops and gotten somewhat twisted. It?s funny how people pick up the small details and nuances in the way you express those opinions and base the experience of the whole talk on those. It's funny because I didn?t think much of it when I said it and I was really focusing on giving another message.

This makes me think.

I've done several hours of presentation training, weeks of pedagogic training and years invested in helping people understand technology. But all this time I've been focusing on the the message I've tried to communicate, never reflecting over that what's a big picture for me might be a small picture for some one else and what I consider a simple detail might turn up as a big picture for another developer.

It surely makes me think.

Even with all this communication training I still seem to miss the target sometimes when formulating and delivering a message I want to share. What's even worse, that message get's distorted through filtering and "value" is added based on someone else's background and opinions.

Communication is really, really hard.

I think I've finished thinking and ready to take action.

From now on I'll be a little more careful on the messages I send out and I will try to explain all my view points in detail on this blog. This will make sure that there will always be a solid written source to refer to and if my opinions get twisted you know where to find the original.

I'll start of by explaining where my position on stored procedures come from. Why my default architecture and design lacks stored procedures and why I feel that the projects I build is much healthier without them.

Oh and yes, my opinions are my opinions if I don't reference someone else I'm not speaking for them in any message I'm giving.

The news of this year!

Wed, 11 Jun 2008 21:19:11 GMT

The Data Programmability team has set up a council of advisories to influence the future of EF, EDM, Linq to SQL and Data Services.

Looking at the members in the council, I must say that I couldn't wish for anyone else (well except for myself but that's because I really want to be a fly on the wall in these discussions :).

The members? Well recognize any of these names?

Eric Evans - http://www.domainlanguage.com/about/ericevans.html
Stephen Forte - http://www.stephenforte.net/
Martin Fowler - http://martinfowler.com/
Pavel Hruby - http://www.phruby.com/
Jimmy Nilsson - http://jimmynilsson.com/

I thought you might :) This is really the news of the year and I'm very excited to see what the future of the DP team will hold.

Good job Danny and the rest at DP!

Read Danny's post here: http://blogs.msdn.com/dsimmons/archive/2008/06/03/dp-advisory-council.aspx?CommentPosted=true#commentmessage

Implementing Domain Driven Design with Jimmy Nilsson at Cornerstone

Wed, 28 May 2008 19:21:28 GMT

As a additional puzzle jigsaw in our effort to bring deep competence to developers in the community, we've set up a partnership with factor10 where they will provide classes in deep development methodology.

First out is a Domain Driven Design course with the world-known Jimmy Nilsson. Jimmy has written the second most read book on DDD (hard to beat Evans who invented the term ;) and is a well known speaker, mentor, consultant and a Microsoft Architect MVP.

15th of September he will be doing his course in Stockholm and 16th of October he'll be doing a repeat in Gothenburg. Seating is limited so book well ahead.

To reserve your seat if your Swedish speaking, go to: http://www.cornerstone.se/Web/Templates/CoursePage.aspx?id=2513&course=COUR2007121911330802408597&epslanguage=SV

If you speak English, use Google translator: http://shrinkster.com/yic

Jimmy's DDD book (check out the customer ratings!); http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1211994837&sr=8-1

--
More on Jimmy; http://jimmynilsson.com/blog/
More on factor10; www.factor10.com
More on DDD; www.domaindrivendesign.org

PDC 2008 announced

Wed, 28 May 2008 19:00:28 GMT

I'll be there, http://www.microsoftpdc.com/ will you?

For Swedes: We've talked about coordinating our travels and hotel visits for all Swedish attendees. We'll be putting up a post in the forums at SWENUG's website: http://www.swenug.com so look out for that.

Why and when to use the Entity Framework

Tue, 20 May 2008 18:21:20 GMT

I don't know if anyone missed the great push Microsoft is doing towards moving their data access stack towards a more O/R-mapping kind of solution. LINQ is part of that but also the implementations of LINQ to SQL and the latest addition the Entity Framework.

Danny Simmons, a PM on the ADO.NET team, posted earlier this week about where in the software puzzle the Entity Framework fits.

You can read his views on the matter over here: http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx

The last section of that post has stirred up quite some emotions in the .NET community and I can agree with some of the objections that have been raised, yes EF is still intrusive and yes it's data centric rather then domain centric.

But come on, would you rather that Microsoft continues down the Typed Dataset path? EF is in V1 (or well, sort of) and the team is still learning the basic principles around ORM and Domain Centric applications. Most of them have lived in the world where SQL server has been dominant. I'm just really glad that they've woken up out of the Data-centric world and have seen that there is actually a lot of other challenges around building applications that's not about storing data in a database.

I'm certain that if we continue to give valuable, sensible and sane feedback the team will continue to develop the framework in the right direction.

I also think that the effort they are doing is great, it will make the .NET community more mature when it comes to OO principles and it will drive .NET developers to start think about application/domain based views of their information. I've already gotten a lot of customers that are interested in learning ORM, some starts out by wanting to learn about EF and stays there, for some EF is an eye opener and they move on to frameworks like NHibernate et al.

This is a good thing, as in every market Microsoft heads in to, the total market share will increase.

Btw, on the note to re-use the conceptual model everywhere, One Model To Rule Them all: http://www.lowendahl.net/showShout.aspx?id=203

REST And RSS Syndication with WCF

Thu, 15 May 2008 22:51:15 GMT

A week or so ago I put up a web cast in Swedish on how WCF 3.5 supports REST and how the Syndication API's work. The demo shows of a little service that exposes the event-log via RSS.

If you understand Swedish, have a look over here: http://www.cornerstone.se/sv/Roller/Systemutvecklare/Systemutveckling/Demo-Tv-Utveckling/Demo-Tv-Windows-Communication-Foundation-RSS-och-Restbaserade-tjanster/

What is a "Trainer" and do they have any real Life experience?

Wed, 7 May 2008 10:52:07 GMT

In my day job my title, most days, says "Instructor" or "Trainer". The last couple of weeks I've gotten really fed up with the attitude from some, far from all, uninitiated people on what me and my colleagues actually do for a living. Comments like, "trainers have no real-life experience" and "isn't a consultant really the better trainer then someone hired as a full time trainer?" really annoys me.

So I would like to explain what it means to be an Instructor for Sweden's largest Certified Learning Center and counter both those very common misunderstandings.

"Trainers have no real-life experience"
This is one of the most irritating misunderstandings in my line of work. The one where we as trainers should be some kind of theoretical person that never wrote a single line of production code or never been in a real project. Let's think for a moment, would anyone of the readers in this blog think that someone without real-life experience could teach you particular much? Most would say no, heck I would say no. Yes some things for certain, but building insight and competence, not at all.

So how can I even last a day at this job, and if I might say even get some rep, if I don't have any "real-life" experience.We just concluded that developers tend to not listen to that particular kind of trainers?

Because this is a misconception of the trainer role.

As a trainer I work constantly to enhance teams to do better and to break new technology barriers. One of the tools to do that is "class-room training", the pedagogic model we use is far different from the grade-school type but it is still in a "class-room". This is only one of many tools we use, we also use team coaching and mentoring where we bring specialist competence into "real life" live projects. Another tool is to inject oneself inside a customers projects like troubleshooters or concept-developers for project startups, helping to start up "real-life" projects.

In addition, since our goal is put 60% of our time into our core business of building competence for teams and developers, we got a lot of time to sit down and crunch interesting problems, learn new technologies and find challenges that will build our own competence further.

We're also very passionate about the things we teach, the average trainer has a lot more passion for their topic then the average developer. Passion is what drives us to want to share with every other developer how great our technology or methodology really is. With passion comes the will to get really deep knowledge and hands-on experience. So if you disregard the work we do with customers, you will find most of us working on some kind of pet-project in our spare time.

All in all, we touch projects, code and real challenges on an almost daily basis while still having time to work on developing our own competence and deepen our knowledge of the technology we're supposed to be experts in.

That is why developers really do listen to us trainers.

"isn't a consultant really the better trainer then someone hired as a full time trainer?"
This assumption probably springs from the first one, that consultants do "real-work" and therefor should have more value to spread. Now that myth I think I just crushed, we trainers do real development work constantly.

But I would like to take it one step further and say that while some consultants could be really good trainers, "full-time" trainers has the opportunity to become excellent trainers.

To begin with we touch far more types of projects and sees the methods and technology we're supposed to be experts on in many more types of environments and challenges. This gives us a unique understanding and broad insight of the challenges with our methods and technology; which the average consultant seldom gets, they are usually stuck in the same kind of project for years.

But there is another advantage, our job is to train so therefor our companies invest heavy in training for us (we know the value of evolving a persons competence, it's what we do), and not just technical training but also training in how to effectively help others evolve.

With the training companies investing in training our skills for pedagogy, presentation, coaching, mentoring techniques, team building combined with our daily execution of those skills in real-life. Consultants will have a hard time to keep up in being as efficient when it comes to building competence's, their focus is to be as good as they can on their type of work, where training is often a sidebar.

Again, I know some great trainers that are consultants, all of who regularly works on the skills listed above, but working for a training company you will get the company backing your every step to acquire and deepen those skills and the possibility to focus on being excellent in building competence in others.

More information on pedagogy: http://en.wikipedia.org/wiki/Pedagogic

More information on Microsoft Certified Trainers: https://www.microsoft.com/learning/mcp/mct/default.mspx

Should repositories be tested in isolation?

Tue, 6 May 2008 22:09:06 GMT

The last couple of years I've been using TDD as my main philosophy when writing code. In the beginning I was really static in my testing, everything was tested in isolation, but over time I've become more pragmatic and realized that some things are just not meant to be tested isolated.

I've discovered that the Repository is such a thing.

At least my Repositories work a lot with the infrastructure layer and not much else. So to test those in isolation I need to mock the infrastructure used by the repositories. The question the is, what Am I really testing?

Consider this, simple, method in the repository (using LINQ to SQL):

        public List<Product> ListProductsFilteredOnName(string nameFilter) 
        {
            var filteredProductsQuery = from item in context.GetTable<Product>()
                                        where item.Name.IndexOf(nameFilter) > 0
                                        select item;

            return filteredProductsQuery.ToList();
        }

If I mocked the infrastructure in this case, what would I really test?

I would test the usage of the infrastructure exactly as expected, not that the method behaves as expected. Who really cares how the infrastructure is used as long as the function behaves accordingly?

So if I want to test the behavior of this method, I will need to involve the real infrastructure and access the store. E.g I would resort to only test the repository with integration tests, not unit tests.

Now, there is a couple of test I might want to do in these scenarios, like checking that expected exceptions are thrown. But all and all, the behavior of the repository is really based on what it does together with the store.

So in conclusion, make sure that you have enough test coverage. But refrain from taking the isolation to places where it just don't make sense.

More on repositories: http://www.martinfowler.com/eaaCatalog/repository.html
More on TDD: http://en.wikipedia.org/wiki/Test-driven_development

One Model to rule them all

Mon, 28 Apr 2008 09:38:28 GMT

"One Model to rule them all, One Model to find them,
One Model to bring them all in to the darkness and bind them"

The quote comes from the book "The Lord of The Ring" and like the characters in that book many are they in the developer community that awaits "the prrrecious", but I fear that they will wait forever. I firmly believe that "The prrrecious" will never surface in this time and age.

The notion of a model is not new to the software industry; for ages models have described our software. With the models, a simple truth has always been present; every model excels, at its piece of the puzzle. As an example, different parts of UML describe separate aspects of software and solve unique description challenges.

Although always present, this truth seems only to be attached to the description of software, not the implementation of it.

In the Microsoft developer community the introduction of LINQ, LINQ to SQL and the Entity Framework raised a question that has been debated heavily since; "Should I use relational models or domain models to represent my data?"

Another and a bit older question that is also heavily debated is; "Should I use message models or domain models to represent my entities?"

The answers to both the questions are the same; there is no "prrrecious" model, so don?t wait around for it. Instead, follow these two simple design principles:

Use the model that solves the immediate challenge the best.

Make sure that the transitions between different models are as smooth as possible.

This will guarantee that for each piece of your implementation puzzle you will get the best suited model.

In my opinion the relational model (tables, rows, columns and normalizations) are by far the most efficient way of storing information and ensuring its integrity. Domain models are by far the most efficient way of processing data and applying business rules in code. Messages and services excel in creating and sharing loosely coupled and highly agile processes across the enterprise(s).

This makes the different models complement each other, not exclude one or the other.

So therefore I propose that we all chant this mantra:

"I will use the right model for each piece of the software puzzle, even for the implementation"

--
More on Domain Driven Design: http://www.domaindrivendesign.org/
More on Service Design: http://msdn2.microsoft.com/en-us/skyscrapr/ms954638.aspx

Movies from Developer summit

Wed, 23 Apr 2008 19:25:23 GMT

4 of the movies from Developer Summit (3 in English) is up on our website.

Have a peek over here:

Comments from David Chapell on the State of SOA and REST vs SOAP
http://www.cornerstone.se/sv/Roller/Systemutvecklare/Systemutveckling/Event-TV/David-Chappell/

Comments from Tom Rafterty on Web X.0
http://www.cornerstone.se/sv/Roller/Systemutvecklare/Systemutveckling/Event-TV/Tom-Raftery/

Comments on languages and learning with Dan North:
http://www.cornerstone.se/sv/Roller/Systemutvecklare/Systemutveckling/Event-TV/Dan-North/

A summary of the event (In Swedish):
http://www.cornerstone.se/sv/Roller/Systemutvecklare/Systemutveckling/Event-TV/mingel/

More are on the way as they get edited!

Enterprise Architecture and Agile Software development - A Match made in Hell?

Wed, 23 Apr 2008 12:30:23 GMT

- "How does the long-term strategy thinking from an Enterprise Architect match with a short-term iteration based agile developer?"

This is a question that often arises when agile methodology is discussed with enterprise architects and when discussing enterprise architecture with agile developers. At a quick glance it seems like the two isn't compatible, and when listening to some of the arguments from the both roles you could get convinced that it's actually the case.

But I beg to differ.

First let's examine what the collision points are and then I'll explain why I feel the two is indeed compatible.

Different views on architecture, the challenge!

The confusion around what architecture is and is not is complete and total. The definition of an architect and architecture are probably as many as there are people in the business of software. This creates an extreme challenge when communicating and trying to figure out what responsibilities different roles have in every project.

Combine this confusion with the agile statement that "architecture" is defined by the team currently implementing a feature who also limits the "architecture" to support that feature, nothing more and nothing less. It's quite easy to foresee the conflict promptly arriving.

On one side you will have an Enterprise Architect's view on "architecture" with a goal to create a long-term and solid "architecture" that will support the business.

On the other side you have the agile developer who focuses on giving business value one feature at a time; putting the "architecture" in the second room and lets it evolve with each iteration in a short-term fashion.

The lunch discussions are bound to be heated if this is the point of origin the both roles have.

Are they so different after all?

Now when we understand the different viewpoints, let's dig deeper into the definitions and look at what the roles brings into the term "Architecture".

In my experience, when an Enterprise Architect talks about architecture his main concern is the overall architectural strategy of the business she's supporting. Her concerns is usually about Data Management across the enterprise, Single-Sign on solutions for all existing systems, interoperability of all the systems in her care and many more enterprise wide decisions.

An agile developer's main concern is usually in how to implement the feature she's currently working on, being true to YAGNI and not over-engineer the solution. She's usually talking about where to host her code, how to store and access the information needed and what solution/design patterns she could benefit from using.

Are the concerns even remotely the same? I would argue that they are not.

I would argue that the use of the term "Architecture" from the agile developer's perspective is incorrect and that the two roles talk about different things. A more correct definition would be that Enterprise Architect's think about architecture and Software developers think about software design. Now, here's two terms that are compatible in deed;

Software Architecture and Software design.

They are two different responsibilities and two different sets of artifacts to be responsible for. This is probably not news to many of you, but some architects and developers mix these two up. I've heard descriptions of Object Relation Mapping as being an architectural decision and whether or not to use an integration platform for integration as a design decision. This is one of the bases for the confusion and one of the problems when trying to mix Enterprise Architecture with Agile development practices.

Building a bridge

Even though a lot of architects might be the same person that takes decisions about how the software should be designed, for the industries sake, we need to be clear that the two are very different beasts and a person that are responsible for the decisions about both actually fulfills two separate roles in the project.

So Enterprise Architects; don't meddle with the code or design decisions!
Agile Developers; respect architecture decisions as incoming constraints on your projects.

Follow these two simple rules and Agile development methodology will live in peace with Enterprise Architecture even in the same universe.

Merlin's Magic spells in modern projects

Tue, 22 Apr 2008 09:23:22 GMT

Princeton's word dictionary defines a magic spell as being:

"S: (n) spell, magic spell, magical spell, charm (a verbal formula believed to have magical force)" [1]

In many movies and fairy tales these spells have been a central piece of getting things done or moving bad fortune into good fortune, wouldn't it be great if we had those spells to move bad projects into good ones?

Yesterday I attended a talk hosted by Agical [2] a company specializing in helping teams and companies becoming more Agile. They have invited two of the most prominent speakers on Agile retrospectives, Diana Larsen and Esther Derby, to give an hour long talk on their views of the technique.

Listening to the two lady's, reflecting over the many hours of talk with Dan North [3] about teams, and the basic rules of improvisation theater (which I've started to learn recently); I realized what extreme power simple words really can hold. Using the right set of words in the right order will get things done, change the scene and even change the outcome of a discussion.

Consider the difference between saying "you broke the build! why?" and "what was the circumstances around the build breaking?".

The first one will immediately alienate the recipient of the accusation and question, possibly putting the person in defense mode and will be very hard to collaborate with to find a solution. While the second will open for a dialog and are much more friendly.

All this because change of wording, basically the same question but a different outcome.

So to be an effective team member I think we need to learn the modern day spells, we need to invest more time in learning our language and what power a certain word really holds, especially in conjunction with other words. Much like the old ages magical spells.

Putting the words together in the wrong order, the prince will become a frog, but putting them in the right order the kingdom will be filled of wealth and prosperity.

--
References:
[1] http://wordnet.princeton.edu/perl/webwn?s=magic%20spell
[2] http://www.agical.com
[3] http://dannorth.net/

More about retrospectives:
http://en.wikipedia.org/wiki/Retrospective
http://www.agilejournal.com/articles/articles/iteration-and-release-retrospectives:-the-natural-rhythm-for-agile-measurement.html

Esther and Diana's book:
http://www.pragprog.com/titles/dlret