Sami Dalouche

First, here is an introduction to what OSGi-enterprise means.

Second, here are a set of OSGI-enterprise implementations :

• Apache Aries : sponsored by IBM and SAP
• Eclipse gemini : sponsored by Oracle and SpringSource
• Eclipse virgo : donated by SpringSource (formerly known as spring-DM) – reference implementation of OSGI enterprise)

On a totally unrelated note, please take a look at the “Relationship to existing projects” on Eclipse virgo’s page. This will give you an idea of how decoupled the Open Source world is : each project has its own Project Leader, its commiters, contributors, and even though the projects depend on each other, there is only limited communication between them. Each project can be developed according to its own schedule, and this is the way open source can scale. The limit is the sky !

Once again, there are maybe some things we can learn from Open Source.

A new release of Hibernate validator has been unleashed. It contains interesting features, such as the fact that your constraints will now be visible by the whole Java ecosystem. Finally !

Marc-Andre Thibodeau and Vincent Tence have set-up a sample Petstore project on github that shows how to take advantage of this new release of Hibernate Validator.   Feel free to take a look !

I came across this interesting set of linux/unix one-liners…   (thanks Phil).

Nice brain gymnastics, and it is definitely worth checking out if you want to add a few tricks to your power-user recipes

IT world runs a very interesting article explaining why Open source is not a democracy, and never should. Some interesting quotes :

“No. This is not a democracy. Good feedback, good data, are welcome. But
we are not voting on design decisions.”

“Shuttleworth is in the right here. Ubuntu and a vast majority of free and open source software projects, including the Linux kernel, have never been democracies. They are meritocracies, and any member of a community that thinks otherwise is kidding themselves.”

“too many hands on a project with no consensus of direction leads to a pretty crappy project“

“It’s critical to recognize that open source does not bring complete democracy to software development. It never did, and it never should. Ultimately, someone in the developer chain will have to make the tough calls.”

So, if you run your software development project as a Democracy, there might be some things you can learn from Open Source.

The key to gmail describes what sh*t umbrellas are at google :

as a shit umbrella, the product managers protect the engineers from getting distracted. It’s not enough to be a “shit funnel” where they would pass some of the junk down to engineers, they need to fully protect the engineers.

No wonder google engineers accomplish great things : they just focus on their work !

Slashdot runs a story about Microsoft employees preferring to use the iPhone over Microsoft alternatives.

Even though it might be a good idea to always eat your own dog food, the simple fact that your employees prefer the available alternatives is worth taking into consideration. Indeed, the motivation behind eating your own dogfood is to get feedback ; and the simple fact that even your employees do not want to use the product is exactly the kind of feedback you are looking for.

So, if you are a software editor for a product, and for some reason, your own employees (or worse, the developers of the solution itself) want to use the competitor’s product, then the first thing you should do is welcome them to, and get back to them once the product becomes at least as good as the alternative. No matter whether the reason for not using the product is good or not, it just means there is something to address.

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.