Sami Dalouche

Consistent hashing is a technique used in some NoSQL implementations. However, for those who try to understand what consistent hashing is, online papers usually talk about abstract stuff that is quite hard to understand for mere mortals. For instance, The wikipedia entry states :

Consistent hashing is a scheme that provides hash table functionality in a way that the addition or removal of one slot does not significantly change the mapping of keys to slots. In contrast, in most traditional hash tables, a change in the number of array slots causes nearly all keys to be remapped. By using consistent hashing, only K/n keys need to be remapped on average, where K is the number of keys, and n is the number of slots.

Add a few acronyms and formulas, and you have everything you need to kill a Buffalo.

The good news is that I came across this blog entry on consistent hashing that makes it really easy to understand what consistent hashing is used for, and how to implement it. It’s actually quite easy in the end

It would be nice if, when a cache machine was added, it took its fair share of objects from all the other cache machines. Equally, when a cache machine was removed, it would be nice if its objects were shared between the remaining machines. This is exactly what consistent hashing does - consistently maps objects to the same cache machine, as far as is possible, at least.

Mark Shuttleworth, the guy behind Ubuntu, shows us once again what an Open Source leader is.

There are some decisions that are necessarily unpopular, but are important to prepare the future. Being unpopular does not necessarily means being bad, but it definitely means going against the opinion of some people, which is quite important if you want to get things done. No wonder that in just a few years, Ubuntu has gone from a _ZERO_ user base to being the most widely used Linux distribution. Compare it with Debian trends, which tries to satisfy everybody and use voting as its main decision tool.

But unlike politics who most often do not have the courage to make the tough calls, most of the successful Open Source projects leaders have the balls to enforce their vision, even if it means being heavily criticized. The reason is quite simple : what counts in the end is not the surrounding politics or perception of the community, but the actual effect of the decisions.  Open Source is a meritocratic environment where the good ideas win in the end.

“On that particular decision, we’ll have to let time tell. For the moment, the decision stands. I’m the first to admit fallibility but I also know that it would be impossible to get consensus around a change like that. If those tooltips are, on balance, really just clutter, then unless someone is willing to take a decision that will be unpopular, they will be clutter forever. And it’s easier for me to make a decision like that in Ubuntu than for virtually anybody else. I apologise in advance for the mistakes that I will certainly make, and which others on the design team may make too, but I think it’s important to defend our willingness to pare things back and let the core, essential goodness shine through.”

Of course, good leaders must also publicly admit when they’re wrong, and Linus Torvalds, another successful open source leader, has shown us his ability to admit it when he made the wrong calls.

“and sometimes make the wrong call, but if so, he’s proved willing to publicly admit his mistakes.”

Pretty interesting read on : You don’t need Math skills To be a Good developer, but you do need them to be a great one.

And yes, the author is right about Math : it should be part of your tooling if you want to do something else than coding stupid web forms all day.

On a related note, I have been working with a team where most people in the team had Phds in various mathematics-related fields. I can tell you that learning how to correctly write tests was a joke for them ! They instantaneously understood :

• the value of testing
• where data-driven tests helps (@DataProvider)
• how unit-testing can complement integrated tests to avoid writing all combinations of integrated tests
• etc… (tons of other things that most teams take months – if not years – to understand)

The reason is quite simple  : people with a decent mathematical background exhibit abstraction skills and can perform abstract thinking and reasoning.

I came across Linux Kernel development, a paper from the Linux Foundation that highlights a few important facts about the kernel development process. This nicely complements a few of my previous posts :

• Maximum numbers of developers on a project
• Surviving with many patches
• What Thoughtworkers think of git
• On real meritocracy
• Open Source is not a democracy

A few interesting quotes from the paper

“Regular 2-3 month releases deliver stable updates to Linux users, each with significant new features, added device support, and improved performance.”

“The rate of change in the kernel is high and increasing, with over 10,000 patches going into each recent kernel release. These releases each contain the work of over 1000 developers representingaround 200 corporations.”

“Since 2005, over 5000 individual developers from nearly 500 different companies have contributed to the kernel”

“We have seen a roughly 10% increase in the number of developers contributing to each kernel release cycle.”

“The kernel code base has grown by over 2.7 million lines”

“Patches do not normally pass directly into the mainline kernel; instead, they pass through one ofone-hundred or so subsystem trees. Each subsystem tree is dedicated to a specific part of the kernel (examples might be SCSI drivers, x86 architecture code, or networking) and is under the control of a specific maintainer.”

Once again, there might be a few things we can learn from Open Source.

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.