A new concept for the modern IDE, Code Bubbles allows developers to see and work different fragments of code as one unit. Debugging sessions can be associated with those units save and retrieved later for continued work. Quite impressive! It’s really a departure from the IDEs we’ve been using so far. Of course, this is not mainstream yet. Nevertheless, I would like to try something like that and it would probably be interesting to have the equivalent in the .Net space.

I have to wonder though, what the impact will be on Object Oriented Programming and encapsulation if developers are lead to think of their code as fragments of functionality scattered in their code base…

Errors should never pass describes  the case of AppArmour which fails to follow the Rule of Repair. In this particular case, AppArmor could not make sense of the user (config) input – and thus cannot repair the data-, so it should fail as noisily and as soon as possible to prevent debugging nightmares.

Grails is another example of a framework that fails to follow this rule (at least until v1.1, I cannot speak for v1.2).  I have way too often seen situations where the input was clearly incorrect (e.g. spring builder configuration) and grails was not reporting any error, and was injecting null values instead.

Note: this rule is part of the Art of unix programming, and thus part of the design principles I believe in (previous post).

If you want to hear about a real example of pure meritocracy, you should listen to Tarus Balog on Linux Link Tech Show episode 343. This guy has truly understood how to lead an open source project, and a number of really interesting things such as Open Source Marketing are discussed. (VCs who want to invest $2,000,000 in a company are also welcomed to listen to the podcast episode).

If you have a (possibly good) product that you have open sourced, but without being able to gather a community around it, then I urge you to listen to the episode.

Tarus Balog, keep up the good work, you clearly have understood what a number of supposedly open-source companies totally miss  ! Good work pays in the long run !

Martin Fowler published an informal survey of version control tools among Thoughtworkers. Of course, the big winner is git, and anyone who has been going through the effort of learning it correctly would confirm.

BTW, if you want some help convincing people that git is better, do not hesitate to take a look at why git is better than X.

On a related note, you might want to listen to FLOSS weekly 111 podcast (direct link here), where CMake lead developer talks about his wonder build tool (I’ll never ever use autoconf again if I need to write some C any day) that is now developed using git.

As I explained in a previous post, Domain-driven Design (DDD) is a design principle I strongly believe in.

With more and more evidence of systems/companies switching to NoSQL for scalability reasons, creating a rich  domain model becomes less and less of an option if you don’t want to shoot yourself in the foot. Indeed, while traditional applications sometimes often rely on the database to enforce integrity and referential constraints, this is no longer an option with NoSQL because of the CAP theorem.

So, this means enforcing constraints becomes the sole application’s responsibility, which is, IMHO, a good thing. Validation naturally belongs to the domain layer, and once you go through the trouble of transforming your POJOs/anaemic domain model into a rich domain model, you will certainly start adopting more and more DDD principles.

Responsibilities thus become clear : the storage layer handles the (possibly distributed) persistence, and the domain layer handles the domain-specific business rules and validation.

Sonar 2.0 is just out and adds very interesting stuff. It focuses especially on architecture and OO metrics, which were the missing part of the metrics puzzle in previous releases.

GeoTools developers have released the 2.6.2  version. GeoTools contains an incredible amount of utilities related to GIS and I am totally impressed by the feature set.

To give an example of its use, here is some sample code from gisgraphy-java-client ( a simple Java client I am writing for the open source GISgraphy project).  It calculates the orthodromic distance between two coordinates :

    public double distance(GisFeatureGeography o, Unit unit) {
           Unit targetUnit = (unit != null) ? unit : SI.METER;
           com.vividsolutions.jts.geom.Geometry me = location;
           com.vividsolutions.jts.geom.Geometry other = o.getLocation();
           try {
                   return  SI.METER
                          .getConverterTo(targetUnit)
                          .convert(JTS.orthodromicDistance(
                                 me.getCoordinate(),
                                 other.getCoordinate(),
                                 DefaultGeographicCRS.WGS84));
           } catch (TransformException e) {
                   throw new RuntimeException(e);
           }
   }

Please note that the code makes use of two excellent libraries : JTS for geographical types, and JScience for units. And for your information, WGS84 is a friendly name to refer to the GPS coordinate system (x,y,z).

There is a constant about Software Developers : they love debating and arguing about every single aspect of the development process. Moreover, they will most likely debate forever, because there is usually nothing that can serve as a reference to tell good and bad practices apart. Want to know why ? Well.. everyone is making his own opinion based on his own vision of the truth. There is no axiom that is taken for granted and that serves as the basis for further discussion.

“In traditional logic, an axiom or postulate is a proposition that is not proved or demonstrated but considered to be either self-evident, or subject to necessary decision. Therefore, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths.”

The rest of the mathematical logic is based on these axioms, and given these axioms, everything else can either be proven right or wrong. While it is certainly impossible to create universal axioms and reasoning principles that cover the foundation of software development, I believe we should at least mimic the approach : decide of which design, architectural and coding principles we believe on, and then use these axiomatic principles as the foundation for decision making. Of course, the outcome of your next project will depend on the  quality of these axioms, but at least you will be able to move forward and take consistent decisions throughout the lifecycle of the application.

As far as I am concerned, I tend to base my reasoning on a set of axiomatic principles that are based on the opinion of respected and talented people in the software industry. Even though nothing is perfect, I believe that listening to these experienced people will more likely lead to successes than listening to any lambda developer’s opinion. This is my bet, and the rest of this post is a first draft of the main design and architectural principles that I consider my axioms.

• Domain Driven Design, Specifications pattern, Layered design.
• Principles of OOD, and in particular, the S.O.L.I.D. principles
• Clean code: A Handbook of Agile Software craftmanship.
• Implementation Patterns
• Implementation of the right Enterprise Integration Patterns that best describes a given integration issue
• Defensive Programming (also see Defensive programming in Java) and its derived principles : Design by contract, Assertions,  Immutability, Copy-On-Write, Immutable collections.
• Inversion of Control
• Declarative Programming, and in particular Functional Programming-style collection manipulation and Command/Query separation, side-effect free methods.
• No premature optimization.
• Lessons learnt from UNIX programming.
• Tell don’t ask.
• Robustness principle : Be conservative in what you do, be liberal in what you accept from others.
• Do not reinvent the wheel.

The people behind these principles are smart, experienced, and potentially more intelligent than you and me together. So let’s just follow these principles for now, and once we master every single aspect of them, we will be able to help create the next generation of design and coding principles. In the meanwhile, I take these principles for granted.

J’ai reçu il y a environ une semaine ma copie du premier bouquin au sujet de scrum en français. Scrum : Le guide pratique de la méthode agile la plus populaire a été écrit par Claude Aubry. Claude nous offre un regard pratique et lucide au sujet de scrum et de sa mise en oeuvre dans les organisations.

Ayant été en contact à quelques reprises avec Claude depuis quelques années, c’est avec grand plaisir que j’ai signé la préface du bouquin et fait quelques commentaires lors de la lecture du manuscrit.

À quand le prochain bouquin en français au sujet de l’agilité en développement logiciel?