Beware Phony Model Objects!

While I am refactoring huge amounts of code out of EJB2 (and trying not to break too much things), I have noticed a bad design pattern that is so noxious I thought I should blog about it.

I call this the Phony Model Objects (PMO) antipattern.

It basically amounts to sharing as first class model objects entities that should never be publicly exposed. These bad citizens may look inocuous at first glance. In fact, they oftentimes carry a deep functional dependency on the technical framework they depend from or are subject to change at a different pace than actual domain objects would do it.

Interestingly I have found that all these PMOs are generated: whether they are EJB2 artifacts (home interfaces, entity beans, value objects, primary keys...) or web service client stubs. This re-enforces the idea that they are by-products and should be treated as such.

So, if you return or accept this kind of PMOs in public methods, do not wait and immediately refactor your code to share only proper domain model objects and keep the phony ones hidden behind the surface of your API.

This will eventually save you a lot of pain and efforts when the technical framework to which your PMOs happen to be coupled to will disappear and you will have to move away from them. Trust me on that one!

MuleCast: A Conversation with the creator of the JCR Transport

Ross Mason has interviewed me (again) about the JCR transport for Mule. I also had a chance to give a few words about the brand new Common Retry Policies module.

Enjoy!

A month of e-reading

After months of procrastination, I have decided to give a try to e-ink and go paperless as much as I can. I have been using a Sony PRS-700 for a month now and I must say I am really happy with it.

This picture does not render the actual contrast and precision of the e-ink surface.

I opted for the Sony reader because of its openness: you plug it in an USB port and voila! You are free to drag and drop files into the reader.

I used it in all sorts of lighting and places: in the dim light and shaky environment of public transportation to the comfort of a sun lit office. So far I successfully used it for:

• Paperless meetings: instead of printing meetings' material, I now upload them to my reader.
  
• Long blog entries: I simply can not read long articles on a computer screen so I use the reader for long blog posts.
  
• Reference guides: the search feature of the reader is convenient to find passages of reference guides or technical books (like Mule in Action).
• Book reviews: instead of printing the books I am reviewing, I now upload them to the reader. The annotation feature is a little too slow to take long notes on pages but fast enough to attach a few words that are reminders for building the final review.
  
• Full fledged e-book of course! So far, I have only read a few technical e-books from InfoQ. Hundreds of pages later, I can tell it is really a great reading experience. I sometimes have to zoom on a schema, but most of the time using the landscape orientation guarantees a seamless reading.
  

Despite wishing a bigger screen for a smaller price (it's Christmas time after all), my only concrete suggestion to Sony would be the addition of a smart zoom mode that would automatically trim all the useless white margins that oftentimes waste PDFs' page estate.

How To Guarantee That Your Software Will Suck

You may have recently read two eponymic blog posts about this crucial subject, so I won't give you ten more ways to suck at programming but just one.

Here it is:

Don't critique your code.

If you never ever have a critique view of your code, you are on your way to write software that sucks.

People who pair program may chuckle: they already have a continuous critique process that helps producing high quality code. People who practice code reviews may chuckle too: they already have a process (and, often, tools) for ensuring code is properly discussed.

So what is left for those who do not pair program or practice code review? The same applies: whenever you come back to your own code, critique it. Oftentimes, while adding a new feature, you will realize that a particular design is convoluted, a class is ill named or a method is hard to read.

Do not fall into complacency with your own code: love it, hate it, critique it, refactor it!

Software That Kills

In the latest installment of his monthly IEEE Software column, Philippe Kruchten asks about the relevance of licensing software engineers. In this article, he states:

The only purpose of licensing software engineers is to protect the public.

He then details the reasons why it makes sense to license people who write or certify “software-that-kills”.

Even if I am not licensed (and may never be), I fully agree with his positions. In fact, I feel compelled to ask why limiting licensing only to software that kills people. What about software that kills businesses? What about software that kills privacy?

Except when human lives are in jeopardy, software developers are basically free to do whatever they want when they build an application. Businesses and end users are left to goodwill and luck when it comes to receiving from software developers the professional standards they can legitimately expect from them.

Should licensed software engineers be engaged to at least review the design and architecture of software that can kill businesses or privacy? Would it be enough to restore trust in a profession from which the common wisdom is to expect so few?

A new module for Mule!

I am happy to announce the very first release of the Common Retry Policies module for Mule 2.

The goal of this project is to encourage the Mule community to nurture a set of production grade retry policies. At this point, the available policies have been tested only with a limited set of transports (JCR with JBossMQ and ActiveMQ).

I expect the feedback of the community under several forms:

• Configuration samples that worked for you,
• Bug reports, fixes and improvement patches,
• Features requests.

Visit the project page for configuration samples, links to the downloadable artifacts (Maven, standalone distribution) and to JIRA.

Hope in hardship?

Hard times provide opportunity for change. Can't afford for a project to fail? Applying agile development principles can help. Doing projects with fewer people? Applying agile development principles can help. Limited resources throw options in sharp relief where a surfeit of resources makes putting off change easier.

Kent Beck, posted in Agile Interest Group Luxembourg

Right now every organisation is assessing all their costs (most companies have cut between 10-30% of their workforce). In this process, CIO and Managers are being asked to do more with less, to keep the engine running with half the budget. This means they have to look to open source.

Ross Mason, from his blog.

These sound like there is a future for agile minded open source addicted developers out there. Time will tell...