05.18.09
Linux is not ready for the desktop
Take look at : Why Linux is not (yet) ready for the desktop.
This is the first article I read on this subject that is actually giving strong, valid points. I totally agree!
04.28.09
Looks like .NET has a long way to go…
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..
04.25.09
Error handling in REST applications : best practices
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
04.23.09
To go a little further in abstracting conditions
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.
On using IoC for initializing dispatchers
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 !
04.22.09
Nobody’s interested in “agility”
Very nice post from Martin proulx called Personne n’est interessé par l’agilité. (french)
Something that I would add to his article is that programmers themselves are NOT INTERESTED in agility, really !
For the sake of explaining my point, let’s consider two types of developers :
- Joe the programmer, who doesn’t care about code quality
- Scott, the more advanced developer, who works as hard as possible to produce good code quality
It’s pretty easy to realize that Joe doesn’t care about agility, scrum, and whatever, as he just works on whatever his hierarchy wants him to work on. Give him scrum, give him waterfall, he just won’t see a difference anyways. Code is about copy-pasting, and google is your friend !
Now, let’s see the case of Scott, the “elite” developer. He wants to focus on code. He likes code, he dreams about code, he wants to refactor, and he will do anything that allows him to produce better code. And usually, he just _hates_ politics. When Scott first heard of agility, what he thought was “yeahhhhhhh great!!! FINALLY something that allows me to just focus on my code”. yeah.. that was a few years ago.
That was true, at least for some time, because agility used to be about good developers trying to find a way to just work.
But now, things have changed. Agile is nearly mainstream, and most developers who claim they do agile development are just instances of Joe() who learnt how to create crappy, unmaintainable tests. The good developers have already moved to the latest bleeding edge methodology which is called “Common Sense Politic-Less Programming (CSPLP)“. That’s what allows them to get away from the religious debates brought by the scrum and agile masses. (they prefer technical religious debates.. but that’s another problem.. )
Once again, what they want is to produce code, not debate forever about “how long should a daily scrum last”, “what kind of clown tricks could we do to build a better team”, or “how to teach the monkeys how to produce good code without affecting their ego “. Have you heard of google developers applying Scrum ? Have you heard of Linus torvalds bringing agile to improve Linux ? All of them just don’t care, because they already produce good, working software, that they release iteratively. And they did not need agile for that, they had their skills, and their common sense. It’s the developers who are producing the code, not the methodology ! And the successful companies have understood one thing : “if you hire the good guys, you’re gonna make great things”. It’s as simple as that.
To put it in a nutshell, nobody cares about agile and scrum. While the average joe doesn’t care or hasn’t even heard about it, the elite scott is skilled-enough to apply the CSPLP methodology, which stands for Common Sense Politics-Less Programming.
04.16.09
How to learn faster in an agile development process ?
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 ?
04.17.07
Acegi and AppFuse 2.0 Captcha
Just a few words to give my opinion about this post on Acegi and AppFuse 2.0.
ACEGI
1. If you use composition, your domain objects don’t have to implement the UserDetails interface, so you don’t have to “pollute” them.
1′. Even if you do not use composition, implementing an interface doesn’t mean your domain objects are not POJOs anymore. However, having to inherit some base class makes them not POJO, which is not the case with Acegi.
2. There is no concrete provider, but once again, if you wrap your AccountDao (or whatever JPA/Hibernate Dao ), implementing the provider takes 2 or 3 lines of code….
3. Yes, indeed the documentation is not easy to deal with…
APPFUSE
1. Annotations vs XML debate… I guess it’s a matter of taste.. XML is definitely more powerful, etc, but you don’t generally need this power, and ease of maintenance can be considered as more important that theoretical flexibility…
2. I agree.
03.03.07
Re-inventing the wheel vs Integrating many libraries..
I happened to read this blog entry about NOT reinventing the wheel. I 100% agree with the author. However, I would like to add something important : Reinventing the wheel is bad, but integrating too much stuff together will necessarily cause headaches about version incompatibilities, subtle problems, etc..
For instance… Let’s say you want to display AJAX-pages that will query the server asynchronously for some stuff, and display the result to the user. One of the best alternatives is DWR, so let’s say you use version 2, because it supports annotations, etc..
Now, you want to create AJAX-validation of your forms. You don’t want to reinvent the wheel, so you use something like Struts2, with the ajax theme. Bad luck ! Struts2 seems to work fine with DWR1, but one will have problems with DWR2… How do you solve the issue ? Patching, patching, patching, if you have the time.
The problem is that this kind of headaches constantly happens whenever you use a few frameworks and libraries, which completly kills the productivity… Another real headache would be the use of Spring 2 + AspectJ + Hibernate to Dependency-inject POJOs… The problem + solution is described on this post…
Another example I came accross would be the incompatibility between some prior ActiveMQ version (before 4.x was released) and Spring 2.0, whereas everything was working fine in 2.0 RC4… The problem came from Xbean 2.6 which was incompatible with Spring 2.0 final….
And I could post hundreds of framework-headaches … I am not saying frameworks and libraries are bad (otherwise, I wouldn’t use them), but they’re not paradise either…
Maven2 for Debian ?
I came accross this blog entry which is a mini “howto install maven2 under debian”. Thanks for the hint, and thanks to the Debian Java team for working on official Debian packages for maven2.
However, I think we have a deeper problem than just the lack of maven2 package.. Just take a look at the number of jars in Maven2 repository. And this doesn’t take into consideration the jars offered on Java.net repository, or Apache Incubating one.
So, what is the problem exactly ? Well, it is going to be IMPOSSIBLE for Debian to keep up with the crazy and constantly increasing amount of Java jars available. So, instead of trying to re-package Java libraries once again (mainstream developers already have to package them for maven1 and maven2), why not work on some integration between Debian Packages and Maven2 ones ? And when you think a bit about it, Debian has the same problem with PHP PEAR and and Perl CPAN.
Maven2 is a full-blown java package system that expresses dependencies, etc. So, to my opinion, what Debian should do is the following :
- Create a notion of a “soft-depencency”. Basically, this would mean that any Package can have hard dependencies (the current deb dependencies), and soft dependencies which could be resolved by a soft-dependency subsystem.
- In order to deal with Java, CPAN and PEAR’s case, a soft-dependency could be expressed as prefix:dependency. A soft-dependency manager could register a prefix, and the dependency string would be subsystem-specific. So, for instance, if I need freemarker, the dependency could be maven2:freemarker/freemarker/2.3.8
Now, the question is whether Debian is ready to accept such a shift in its concept ?