Tag Archives: ORM

Delusion: A firm belief despite contradiction in the face of reality

Posted on by
DevDays 2010 in Cape Town yesterday was slick.  Very slick.  It’s always slick.  Those guys really know how to put an a good show.
Most of the speakers are good.  Most demos were good.  Most jokes were funny.  The food was mostly good. The mood was mostly good too.   And the MS fan club was mostly impressed.  And most noobs were converted for ever.  And the improvements were mostly apologetic of the earlier short comings.  And code that you were promised you would write was mostly minimal.  And most absent was the word design.  Most ignored was TDD.  And most content presumed that we are dumb ass developers that don’t care about good code, good tools, good software.
If it was not for Bart de Smet’s two sessions on Core .NET 4.0 Enhancements and Language Enhancements in .NET 4.0, the day would have been mostly wasted.  Bart gave me a glimmer of hope, not for MS but for the manner in which he assumed we are not moron developers that can’t think.
The EF4 code first demo was explained completely as if the classes in the model are no different from entities in a table.  You may be have slides with the words “code first models”, but if you don’t actually do it for real, then you’re just leading dataset happy, marginally object oriented developers further away from the truth.
I understand that it’s a marketing game but, come on, MS South Africa, at least pretend that we are capable developers that care about being professional.  We care mostly about design. Mostly about clean code. Mostly about quality.  Mostly about getting projects done on time, within budget and mostly maintenance free.  We care mostly about being agile, being able to refactor code continuously, being able to test first, and not tossing code downstream.
Ahmed’s ping-pong of bugs is so irrelevant, when the developer is test-first infected and the tester is actually your continuous integration server.  Mostly we are developers that test our own code.
Glimmers of hope
– IE9 has developer support in mind
– EF4 has code first, but still so far from being a decent ORM
– DLR has a potential sweet spot

DevDays 2010 in Cape Town was slick.  Very slick.  You guys really know how to put an a good show.

Most of the speakers were good.  Most demos were good.  Most jokes were funny.  The food was mostly good. The mood was mostly good too.   And the fan club was mostly impressed.  And most noobs were converted forever.  And the new features were mostly so good, apparently, you won’t have to write so much code anymore.  And the most underused word was design.  Most absent words were TDD, refactoring, quality, and clean!!

I understand that DevDays is a product showcase but, come on, MS South Africa, at least cater for the entire spectrum of developers, just a little bit, and in a responsible manner.  How about pitching content that shows that you do care about design, about clean code and quality.  How pitching the new features in a way that shows a trend towards agility, to being able to refactor code continuously,  to test first and other vital aspects of professional software development.

Let me give you just an example to illustrate what I mean.  The EF4 code first demo was explained completely as if the classes in the model are no different from entities in a table.  Even the language used was “entities” and “keys”.  I don’t think I heard the word “class” or “object” once!  You may have slides with the words “Code First Model”, but if you don’t actually do it for real, then you’re just leading dataset-happy developers that are marginally object-oriented further away from good code and good architecture.  You need to explain why it’s better:  that it promotes better object orientation, that POCO models disconnected from an ORM can be done test-first, and you can evolve your model, instead of designing up-front, blah, blah, blah.

Another time there was a ping-pong table with a developer at one end and tester at another with a bug being batted between them.  That pulled quite a laugh from just about everyone.  While that is reality in many organisations, there are many of us that test our own code and deal with our own bugs.  The tester that we toss our code to is our automated continuous integration server.  Tossing code downstream when it’s too late for reprise is not very professional.  How about focusing on the testing tool, as opposed to pitching it in a manner that makes everyone believe that dealing with the bug downstream is just the way its meant to be.

Sure, I know that you need to show off the latest cool things and evangelise your products, but there is a sector of developers that you are blatantly ignoring.  It is the sector that is, perhaps, the most influential amongst other developers. We are those developers that value our craft of software development.  We evangelise the craft and the value that it brings to our lives, our teams, our projects, our clients and our organisations.

Perhaps I am just delusional.

Oh well, so long and thanks for the fish.

The optimistic concurrency gotcha

Posted on by

In my current project, I have a group of about 7 budding young developers none of whom have done any significant web development.  This includes hitching up to a database and using object relational mappers.  The one thing that always gets first-timers is stateless nature of the web.  And the first solution they come up with is session based statefulness which eventually leads to a scalability bottleneck.  The ripple effect of lack of state is that you need to have optimistic concurrency at the data access level.  Now most of us just assume that our OR Mapper will solve that for us.  And, yes, they do offer optimistic concurrency out of the box, be it with a version column or without.  But Mats Helander makes a strong point that optimistic concurrency in most (maybe all) OR Mappers actually kicks for really short durations (milliseconds).  In that case, you might as well be using good old fashioned database transactions.  Mats suggests that a way to solve the problem is to store original values in the view.  Check out Mats’ post and you’ll see why you should be storing, at the very least, your Hibernate version column/property on your view as well.