Sami Dalouche

I’ve long been convinced that the best way to choose between the different languages is to consider their respective communities, and this article definitely confirms my perception.

Relying on the technical merits of whatever platform is mostly religion. However, considering the surrounding community and environment totally makes sense. If you pick PHP as a language, no matter what you think of it from a technical point of view, you’re going to have to deal with (or even hire) PHP developers, who have been deeply affected by the hacker syndrome. If you pick the .NET platform, you’re going to work with religious people who do not consider anything which is not an official Microsoft BestPractice. If you pick the Java platform, you’re going to deal with framework-ill people who focus more on the infrastructure than the target application. and so on….
Everything is about choice!  So, just consider this when you start your next project, I feel like it’s as important as other technical considerations..

RESTful error handling gives a nice overview of the miscellaneous ways of handling errors in a RESTful web application. To me, the following criteria need to be met to provide decent REST error handling :

• Be simple to implement (or at least, be simple for simple cases)
• Be machine-parseable (so that intelligent REST clients can be built)
• Be human-readable (so you don’t have to fire up your HTTP sniffer to understand what went wront, when you’re developping a client)
• Follows HTTP semantics, so proxies, caching, etc continues to work correctly

None of the ideas suggested in the article match all of my criteria, so here is the solution I would suggest :

• ALWAYS return the most appropriate HTTP error code whenever an application error happens. Sure, it might not map perfectly, but choose the one that expresses the concept correctly. It is totally absurd to always use 200 error codes, even the SOAP guys have not made that mistake ! Also make sure to use a server-side REST framework that will automatically handle common errors for you (405 for unsupported methods, etc..)
• When the same HTTP error code maps to several application errors, add an ADDITIONAL X-Application-Error-Code : header that provides a simple string allowing to remove ambiguity (choose a simple all-ASCII exception name). This will allow creating simple clients that can easily parse exceptions without too much burden for simple cases
• Add a body that allows a human being (for instance, the developer of a REST client for your service) to instantly understand what went wrong. This can take the form of either a free-form response, or a fully-parseable (XML, JSON, whatever) response body that contains a message field.
• Only implement the fully-parseable response body when your application has matured. Do it smartly, avoid working weeks on your service before even displaying the first feature to your user

on the smallest possible conditions talks about abstracting conditions behind meaninful method names. Now, let’s say we want to go a step further, and want to reuse the same condition in different parts of the project….

I wish I would explain my super-great-idea about achieving this goal, but as usual, Martin Fowler & Eric Evans have thought about it before me, so here’s just the link to the wonderful pattern called Specification.  You could also buy the Domain Driven Design book, as Evans speaks about it in his book.

This post is in response to On using containers as objects.

First of all, dispatching calls to different services based on runtime conditions is something that is needed all the time. The example explained on the code reef might not speak to everybody, though. Example scenarios of every-day use include :

• You need to change the behavior of a payment system depending on the environment. Obviously, you cannot use the real bank service for development, so you need to switch between a DevelopmentPaymentFakeSystem and a RealWorldBankPaymentSystem implementation depending on a runtime condition (the environment on which the application is deployed)
• You need to activate debug features (IE browser check pass-through in development mode, etc)

Obviously, every programming problem can be solved by adding spaghetti code that adds a few conditions here and there in your real services. But the rest of this post assumes that for testability and maintainability reasons, you are implementing the features as different services : the fake payment system, and the real world payment system

The idea suggested by the aforementionned blog post is to use a front-service that will deleguate to the right implementation (real vs fake) based on a runtime condition (deployment). Even though the idea of doing that is brilliant,  I would tend to think that the provided implementation is assuming a broken, half-implemented IoC container.

Indeed, by using a framework such as Spring :

• The Spring container can directly be used as a service locator (just implement ApplicationContextAware, and spring will inject you the service locator). So, no need to create your own implementation of the container (you could always implement ApplicationContextAware later if you need to switch to a different container, as this is just an interface)
• There is actually no need to use the IoC container as a service locator: the dispatcher service can be declared in the IoC container and one can inject it the different implementations using the IoC mechanisms. This can be accomplished using several techniques : name-based wiring (or the @Autowired annotation coupled with @Qualifier), tag-based wiring (you can now tag implementations based on some logical semantic, and then use @Autowired complemented with @Qualifier to get the right instance), or you can just have all implementations of a given interface directly injected to you so you can do your runtime logic to determine the right object (once again, the magical  @Autowired annotation is your friend, just declare an array of the given type and @Autowired it! )

Sure, there are advantages of abstracting the container, but sping provides so much goodness that it’s pretty sad to avoid making use of it, or mirroring its features in custom code !

Agile software development methodologies highlight the importance of continuous learning.

Teams can take advantage of having small iterations followed by retrospectives in order to progressively get better, smarter, and learn from their errors.

And theoretically eventually, the team will get to a point where its members can efficiently work together, where every team member can produce high quality and maintainable code, where the sky is perfectly blue, and the sun is shining.

Yeah.. eventually, we will live in a perfect world…

However, there is something that bugs me with this approach: by letting the team “auto-organize itself to discover its own solutions to its highly specific issues”, we actually end up having the team re-invent the wheel to solve the always-same problems that every development team faces. Yes, guess what ? At some point, sometime in the future, the team will discover that it needs to write decent OO code, that it needs to have a decent coverage of carefully written tests or executable specifications (TDD, BDD), that the domain needs to be properly externalized from the technical code (DDD), that it needs decent modelling skills, that IoC enhances the testability of their code,that it needs to decouple the code with small modules and services, that junior developers need to be coached by senior ones, and so on…. Or.. the team won’t discover it, because the project will lack money at some point, and everything will need to start from scratch again.. Wao! so productive !

So, the question is.. What can we do to reduce the duration of the learning curve ? How can we make sure new projects can benefit from the experience of previous ones ? That’s exactly the debate we have had with a few guys from Pyxis Technologies (http://www.pyxis-tech.ca).

When dealing with organizational coaching (Scrum, Agile), the idea of imposing engineering practices (XP, DDD, ..) was totally rejected by a few people that had concrete examples of failures. Most developers have a great ego and still haven’t learned enough of programming to just admit they can learn more from others.

So, what are the other ideas that were thrown ? Everyone seemed to agree that most of the problem lies in the beginning of the contract: every Scrum/development contract should start with an initial diagnostic, that states the technical debt accumulated by the team. This can then serve as the basis of an execution plan. Most of the challenge lies in linking the technical recommendations with business objectives, and clearly explaining the value of these engineering practices to the product owner and stake holders.
Once the product owner (PO) agrees with the values and the vision, most of the job is done. The team is supposed to work on the PO’s priorities, and the technical coaching will be seen as a wonderful help to meet the business objectives.

Of course, in order to achieve this, a few things will need to be sorted out such as compiling the list of the best practices that we embrace. But nothing impossible here, I guess.

Is that enough to learn faster ? probabably. Is that enough to learn wayy faster ? probably not ! We will still see crappy code being produced for months (years ?), and projects failing because of that. So, what can we do to DRASTICALLY improve the quality of code that is produced by those teams ?