Sami Dalouche

Who is preventing the release of Java 1.7 ?

“He said it’s delayed as there are parties who are refusing to sign off JSRs they own and thus preventing the 1.7 release. It apparently has something to do with the cost of determining your Sun compliance.”

“The basis of the problem is the release process itself. The Java Community Process was meant to bring a more democratic process to JDK development, but it’s turned into an awful, bureaucratic mess, with too many people having too much of a say on what happens.”

Take a look at a pretty old email from Linus on cvs/svn vs git.. (2005).

So one of the worst downsides of CVS is _politics_. People, not
technology.
The upside of centralization is that a lot of things are easier. Easier to
think about, easier to get a stupid and straightforward idea working. 

But if you have hundreds of developers, and you have a dynamic trust
network (I trust some people, they trust others, and we all tend to trust
people more or less depending on what they work on), the CVS model is
absolutely HORRID. It just doesn't work.

With a few work collegues from Pyxis-technologies, we have decided we would use our 20% side-project time to launch an Android community.

The first visible part of our work is the launch of the Slashoid.org news website. The Launch of Slashoid post describes the intent of the website, and what we want this to be. Any kind of feedback and suggestions are more than welcome, and you can use our Slashoid Google Groups for this, for instance.

What is the next step ?

Well, we are a small team of motivated developers working from Montreal, and we would be thrilled to find partners in the area of mobile development. We can especially bring a lot of expertise in server-side application development, as well as in the agile stuff (tests, engineering practices, etc.), so we would love to collaborate on creating full-stack, mobile enabled applications. If you like the idea, do not hesitate to contact us to android@pyxis-tech.com

As I mentioned in a previous post, the acquisition of On2 by google was unclear, and nobody really knew what google would do with this.

Well, it is now clear : google will open source the VP8 codec !

You can expect to hear a lot about that in the next few months.

Some interesting links regarding video on the web :

• Google funds TheorARM open source project
• Youtube vs Ogg/Theora video quality comparison : Theora IS competitive (do not listen to the FUD)
• HTML5 video element codec debate explained
• Ogg codecs dropped from HTML5
• Google’s acquisition of On2 : what will they actually do with this ?

Here is a pragmatic experience report of using git by a non-fanboy.

“The transition will work much better if several of your employees are already familiar with Git and can help you evangelize the idea and provide support to reticent users.”

“Looking back, it took me a while to warm up to Git (quite a while), but now that I’m here, I really enjoy using it.”

Additionally, the post includes really useful links to learn more about git.

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.