A recent post from Mark Shuttleworth seems to show that some foundations also have interesting ideas when it comes to financing projects :

“The model of the Foundation is unusual: we identify interesting change agents, like Mark, who are articulating powerful ideas that seem like the offer a hint of the future, and we fund them to work on those for a year. We also offer them an investment multiplier: if they put their personal money into a project, we multiply that by 10x or more, up to a maximum amount. In short, find good people, back them when they put skin in the game.”

Now, I am wondering about something : could incubators be a model for managing companies ?

• What would happen if you created a company that was merely a kind of aggregate of smaller companies sharing a common vision but running mostly independantly ?
• Could the Politics of Switzerland be an inspiration  for creating such an ecosystem ?
• How much federal government do you need to have inside a company to have the perfect balance between “feeling like a single company” and “feeling empowered enough to do things without any bureaucracy” ? (do-ers hate bureaucracy, so if you want doers in your company, you’d better find a way to systematically fight it if you want to keep these people)
• Is is possible for people to feel part of their community without neglecting the rest of the ecosystem, the same way Texas inhabitants feel both texan and american ?  (Have you noticed that people have both the texan flag and the american one in their garden over there ?)

“I used to write the code, own the domain names, run the mailing list(s), run the servers, evangelize, talk to the press and so on. I’ve successively and successfully given up those rights to very capable individuals. However this has led to a power vacuum when it comes to making some key decisions because nobody, for example and in a sense, is “in charge” of everything. For the most part I’ve enjoyed giving up control and seeing the project blossom, because it wouldn’t have if I hadn’t.”

“Uncle bob completly misses the point by assuming that professionalism is about doing TDD”.

“Dynamic languages got popular for the wrong reasons

“people get religious about details that don’t matter, and very very few people are talking about the big picture”

“scrum is all about common sense, but common sense is really uncommon”

“teams are effective, and to be effective they have to be small. 3 is better than 5″

The less the median developer on a software project team is paid, the more the project will cost to complete.

Is that the solution to all the problems we are facing in the software industry ? Is a full week training going to change anything to the current situation ? The answer is clearly a big NO, but what I find extremely important with this new trend is that people are slowly realizing that if you want to develop software, you’d rather invest in your developers !

So long live to Scrum.org developer course, and let’s hope to see more initiatives like that!

1. Slashoid : Android news: stuff that matters
2. Phandroid: Android Phone Fans
3. Android Central : Android Central
4. MobileCrunch : Techcrunh’s mobile spin-off
5. mobile.slashdot.org : Slashdot’s mobile spin-off

Which ones do you often use ?

After a month of activity, things seem to go well. We average something like 60 unique visitors and about 150 page views per day. This is a good start, and will continue to rise as we get some visibility (From a SEO point of view, we are practically invisible). Any idea on how to improve this ?

In Scrum, there is no mechanism to show the bottlenecks of a process. You can only see that the realization of a task takes a long time or that the task is blocked. You have no idea why or where it is stuck unless you ask the team members. The burndown chart doesn’t help in that matter, when there is a bottleneck you can see some bumps on the graphs but the chart doesn’t capture any information on where is the delay is coming from. “

If you are using the dojo toolkit and are looking for a clean, customizable file uploader, that works pretty much the same way as gmail file attachment mechanism (demo here), then please check it out !

The most important features include :

• Cross-browser compliance: MFU has been successfully tested on IE6, IE7, Firefox, Safari, Chrome, and Opera. Moreover, it builds on top of dojo abstractions which provide a cross-browser compatiblity layer
• Ease of use: MFU either comes as an easy-to-use standalone, striped-down, optimized version, or as a module that can be plugged into any dojo-based application. MFU distribution comes bundled with a set of sample HTML/JavaScript templates as well as a sample PHP-based server-side implementation. See the Quickstart for more information.
• Customizable look: MFU takes advantage of dojo’s Template mechanism. As a matter of fact, the layout, links, and general appearance are completly configurable through an html template. This is particularly handy in situations where you need to customize MFU for your site’s look and feel.
• Internationalizable (i18n): All links and error messages take advantage of dojo’s internationalization support. You are more than welcome to fork the code on github to provide additional translations.
• Free Software: MFU is liberally dual-licensed under the New BSD license and the Academic Free License v2.1 (same license terms as dojo). Feel free to either contribute to or fork the source code on github

Please do not hesitate to drop me an email if you have trouble using MFU.

And of course, the project is hosted on github, so contributing is a breeze Just fork to provide additional code or translations, and we’ll be thrilled to include your enhancements in the next release.

BOZO Consulting

BOZO is a place with well-intentioned people who really want to please their clients. The only downside to BOZO is it doesn’t have the slightest clue about how to achieve that goal. BOZO says yes to everything: “Yes, of course we will cut the estimate.” “Yes, of course, we will lower our bill rate.” The idea is to get the deal at all costs. To summarize, BOZO has a sales-driven culture that lacks the ability to leverage any sort of delivery capability it accidentally hires (thought from Skorks: that would have to be one of the most buzzword driven sentences ever, how can we “leverage” that).

• Lessons learnt from Devver.net
• Startup lessons learnt from Warren Buffer
• My co-founder took my company and my girlfriend

There are many benefits to having a distributed team, but two stood out in our experience. First, we could hire top talent without having to worry about location (in fact, our flexibility regarding location was very attractive to most candidates we interviewed). Secondly, being in different locations allowed every team member to work with minimal distractions, which is invaluable when it comes to efficiently writing good code.

—-

We would rather suffer the visible costs of a few bad decisions than incur the many invisible costs that come from decisions made too slowly – or not at all – because of a stifling bureaucracy.

Warren Buffett excerpted in “Startup lessons learned from Warren Buffett” [thx Derick]

—-

And yes, a partnership is never really equal.  There has to be someone who is somewhat more equal than others. There is nothing more devastating than a partnership were all the members have exactly equal rights and votes. This just does not work. Human society and all monkeys always have a single individual at the top  and with all others, even though they are almost equal, being not quite equal.

• Too much clutter before being able to publish a scoop (tags, ..)
• Article publishing date/time does not work correctly
• Impossible to delete scoops

These issues are all related to Drigg/Drupal, but we will take a look at them whenever we get some time, to check wether things can be easily fixed.

So who in the hell should you hire? Hire the best. Hire people that can leave your startup at any minute if they wanted to because they’re so kick ass that they’re constantly getting contacted by interested parties. Then it becomes your job to ensure that you’re creating an environment that is equally as good as your people. Create a company that gives your people the most room for growth, creativity, a sense of ownership, and fun. And if you can’t hire the best then hire people with any level of experience (novice, intermediate, advanced) that have promise. Then help them become the best so that they can leave any time they want. Hint: they won’t. They’ll be loyal because you helped them become the best. Your goal should be to help every single employee get to the point where they’re the best in their field and are constantly getting job offers.

“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.”

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.

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

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.

• 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 ?

“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 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.

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.”

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.

• 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.

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.

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 !

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

“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.

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 !

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.

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 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 !

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.

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.

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).

“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.

• Wikipedia : Usability and Experience Study
• OpenStreetMap: UX Review
• any other ?

Usability reviews are of uttermost importance if you want to learn how your end users use your product. I initially thought that conducting usability reviews was complex, and involved lots of steps, but Jean-Francois Proulx definitely convinced me of the approach when I attended one of his usability talks a few months ago.

To me, this is clearly a better investment than having your market-team meet during long hours in front of screenshots trying to shape the next version of your website

Of course, you still love Java (it pays more) and think it is still the best way to write serious applications (currently waiting for Scala to get decent IDE support ?). You do not want to hear about this over-hyped language that is supposedly perfect because you simply don’t like languages that use half of the keyboard’s non-letter keys as metacharacters.  But you definitely want to hack a little bit using some dynamic language (maybe because you feel like an idiot when these dynamic-language lovers tell you they get a 10x productivity boost by using XXX instead of Java – replace XXX by whatever trendy, over-hyped popular language of the moment).

Anyways.. for some reason, your choice is Python (if not, then the rest of this post is of no interest to you). You have read a book or two online, and since you’re not an idiot, you already know how to code basic stuff (still need to lookup some stuff here and there, not sure of what is idiomatic yet, but you have definitely grasped the basic concepts). However, you feel a little bit alone in this new world, wondering what the best practices are, which tools are generally used.. etc.  And nobody on the internet really helps you because when it comes to giving technological advice, people are either of the “mine is bigger than yours” type, or the “everything depends on your needs/preference/[...]” BS.

So, here are a few things I learned while developping pymager, a RESTful image conversion/rescaling service (hopefully, it will help you to find your way):

• The equivalent of jars is eggs.
• The equivalent of maven dependency resolution/download system is easy_install or the newer pip that is even better.
• The equivalent of ibiblio main repository is Pypi.
• the equivalent of maven is either distutils or setuptools. distutils is the default tool shipped with python, and setuptools is an alternative, that is simply superior. This is what runs your unit tests and creates source/egg packages for you.
• Installing dependencies can be done using several ways : using easy_install / pip (pollutes your system), using your system package manager (e.g. debian/ubuntu apt-get :  super-clean, but does not install the most up to date packages), and easy_install / pip inside a virtualenv sandbox . See Tools for the modern Python hacker for some help regarding virtualenv.
• There are mainly 2 decent stacks for creating web applications : Django and TurboGears 2. Django is for people who like monolithic frameworks that reinvent the wheel, and TurboGears 2.0 is for people who favor integrating best-of-the-breed components. (TG2 gives you this integration for free, so you can see it as an equivalent of Spring ROO ).
• The equivalent of Hibernate is SQLAlchemy. In addition to what hibernate gives you, SQLAlchemy provides you with some lower-level utilities (such as SQL manipulation, DB-agnostic way to create a connection, ..). However, the transaction management is clearly inferior to what you get with Spring/Hibernate and their ThreadLocal implementation is just a hack that is clearly not suited to anything else than using from a web framework.  If you need to do anything more serious, you will need to reinvent the wheel (See pymager’s reimplementation of ThreadLocal’s transaction management ).
• There are a dozen ways to expose a python webapp including nasty CGI-related techniques. All of them are either hacks or legacy stuff except the newer WSGI approach. Most websites use fancy names for describing what WSGi does, but it is mostly an equivalent of the servlet API.
• Cherrypy is a wonderful embedded web server that supports WSGi (and that can be used as a WSGi application itself behind apache, pretty much like tomcat can serve applications behind mod_jk).  It used to be the one shipped with TurboGears, but they switched to Paste for some political reasons. (that was necessary for the merge with pylons)
• Naming conventions are a joke in python, as nobody seems to follow the same rules. Even some modules in the python standard library (e.g.: unittest module) seem to adopt different conventions than what looks like the python coding standard. I guess that too many ex-java developers program in python without being able to let away their java naming conventions..
• As a Java developer, there is some OO purity that you will need to forget about. It seems to be the “python way” to use module-wide variables, and you feel like you are fighting the platform / frameworks if you insist on applying your IoC best practices…
• nose is the way to go for running tests. (it integrates well with setuptools)
• there is no really manipulable classpath, and the default python mechanisms for discovering / handling files/data the equivalent of the classpath is pkg_resources.  (an additional reason to use setuptools)

Who wrote 2.6.33 reminds us how much the open source world (and in particular the linux kernel community) excels in this area. For the single 2.6.33 release that was developed in about 3 months :

“As of this writing, 10,500 non-merge commits have found their way into 2.6.33 – fairly normal by recent standards. These changes added almost 900,000 lines while deleting almost 520,000 others; as a result, the kernel grew by a mere 380,000 lines this time around.”

So, if you happen to struggle to scale your team past the 10-people mark using your usual development habits, then there are maybe a few things you could learn from the open source world.

My personal understanding of why it works so well :

• good elite developers
• top-notch, distributed, super-fast and merge-friendly version control tools (e.g. git)
• Fault-proof and compromise-free (though sometimes not politically-correct) ways of enforcing software quality and architecture. Examples showing the disagreement-proof nature of the kernel development process include last summer’s Alan Cox vs Linus Torvalds dispute regarding the tty subsystem, or Linus Torvalds vs Hans Reiser argument regarding Reiser4’s plugin system that does not fit well into linux architecture
• result-oriented and meritocracy-driven way of managing the project
• decentralized development (made possible thanks to distributed SCM tools). To quote Linus Torvalds : “Centralized _works_. It’s just *inferior*.“
• modular architecture supporting the collaboration of many developers.  “The large number of developers and the fact that they are volunteers has an impact on how the system should be architected. With such a large number of geographically dispersed developers, a tightly coupled system would be quite difficult to develop — developers would be constantly treading on each others code.“

You might disagree on the reasons why it works so well (after all, that’s just my analysis based on my understanding of the situation), but the success is a reality, a fact.

Also, if you are tempted to think that it could not work in the corporate world, please think about that twice by taking another look at who wrote 2.6.33, where contributing companies are listed.

“”Open source does not mean anarchy. Somebody has to have a vision and the perseverance to see that through. The open source community can then create their own versions if they wish, but it is best if there is a main line, stable version with a consistent architecture with a guiding force behind it,” Gordon said.”

• Gisgraphy Java client : a Java library that gives access to gisgraphy City and GIS features search engine.
• Pymager Java client : a simple Java wrapper on top of the RESTful interface provided by pymager, an image service that provides simple conversion and thumbnailing / resizing features.

• Unofficial versions of the linux kernel, where specific patches are applied (e.g. Xen kernel, openvz kernel, ..) and need to be constantly forward-ported to the latest kernel when it is released
• Distribution-specific changes (e.g. Ubuntu-specific changes to debian packages).

Maintaining one big diff file for all changes would clearly quickly become unmaintanable, so it looks like different approaches are now widely used instead :

• Maintaining stacks of patches, using specialized tools such as quilt.
• Using distributed VCS tools such as git.

How to survive with many patches describes the use of quilt. Here is some background :

“Andrew Morton originally developed a set of scripts for
maintaining kernel patches outside of any SCM tool. Others extended these into a suite called quilt.

It looks like distributed VCS tools have now superceded quilt, as far as pure software development is concerned (linux kernel, etc.). But quilt remains very popular for maintaining distribution-specific changes to packages. Indeed, as distribution packages live outside a SCM tree, it is important to have mechanisms to apply distribution-specific changes to the upstream source packages. And this is where quilt comes to the rescue.

Ubuntu packaging guide describes the use of quilt in debian’s packaging system. Such a simple system is clearly awesome, and the more I understand how the Open Source communities organize themselves, the more it makes me realize how technically advanced the Open Source world  is compared to the corporate world !

No matter how much you might have heard that tooling is unimportant, the reality is that tools are important. Tools enable complex collaboration, and this is clearly an area where Open Source excels.

IMHO, it is simply wrong to assume that every single task can be split into small fragments that are then iteratively incorporated into the mainline. The author calls this kind of task a “technically complex story”, and I have yet to see a successful example of migrating frameworks or doing technical migrations like that without resorting to branching. This is what the whole open source community does, and it is high time the “enterprise” world catches with these practices.

Branching then comes to the rescue ! Let the “technically complex story” evolve in its own branch, and make sure to conduct in-depth QA BEFORE the merge. Same thing for code reviews and going through the DONE checklist : make sure to do it BEFORE the merge so that you do not end up with non production-quality code in the mainline, which is then pretty hard to get rid of.

BTW, Version Control Tools gives an overview of the differences between git and mercurial, which are two wonderful SCM tools that are very branch-friendly.

Heh, and I’ll continue to be an ass in all future responses to “John Smith”s who tell talented guys who worked on my projects for years that they aren’t “team player”s, “have an attitude” and are “prima donna”s. I’ll be the judge of that, not some asshole anonymous blog comment poster who has never met or worked with Norm. I’m protective of my team. That’s not going to change. Sorry if you don’t like it.

YES, Gavin King is an ass, but most of the time, this category of ass is right, and people should just listen to them instead of complaining.. ah ah ah love it !

PS: for those who don’t already know it, Gavin King is the founder of Hibernate…

However, there are still a few things bugging me :

• Why insist on keeping the neat features (IoC, ..) server-side only ? Why can’t I just use the same mechanisms for in-container server-side code  and other kind of code ? Do I still need to revert to using Spring for everything that is not running inside the JEE6 container ? What about integrated tests ?
• How come we still don’t have any equivalent to Spring templates, that take care of creating standardized, runtime exceptions and handling opening/closing resources automatically ?

So for now, when working in non-spring environments, I need to create my own Templates to avoid creating clumsy code…

I agree that Spring Framework is a patch, and should eventually disappear. But for it to disappear, the underlying technologies need to start being half-decent…

These data storage systems have a number of features in common:
•   a call level interface (in contrast to a SQL binding)
•   fast indexes on large amounts of data,
•   ability to horizontally scale throughput over many servers, and
•   ability to dynamically define attributes or data schema.

NoSQL explained correctly gives an idea of what these datastores are useful for, and how they complement the current RDBMS offering.

High performance scalable datastores compares the technical  characteristics, maturity and licenses of the  NoSQL offering.

Other links on the subject that might be of interest :

• Twitter is switching to Cassandra
• Common principles and patterns for building scalable systems
• Seeking a database that does not suck

I take the official Oracle website to be rather … official ?

Lets recap, shall we ?

a) Almost every trace of OpenSolaris Support subscriptions vanished from
the official website within the last 14 days.

b) An Oracle sales rep informed me personally last week that I could no
longer purchase support subscriptions for OpenSolaris.

More information available on this thread.

Why is that important? Because each time you fix something in OSM your brain gives you a little drop of seratonin, or something, that makes you feel good. And that comes from a quick feedback loop. With traditional companies your feedback loop is far, far too long. Anything more than a couple of minutes is too long because there’s no association of the act of fixing something with the good feeling. More often than not, you help fix something and it drops in to a black hole.

[...]

The logistical costs of producing maps in a top-down fashion pretty much levelled out at having fleets of cars driving around North America and Europe. Increasing the detail with footpaths would cost far more than the benefit any company could leverage if they tried to do it a similar way. Crowd sourcing this from customers and others is simply inevitable – there is no other way to do it. But many will likely try to add quality assurance in between their contributors and the map and thus limit the scope and depth of the contributions.

[...]

Those maps will, at times and in certain areas, be better than OSM. But the growth of OSM is inexorable and like a freight train will ultimately roll over everything in its path. It may even happen before traditional companies figure this out and try to start seriously crowd sourcing data.

Is OSM the next wikipedia of mapping data ?

• Failure to Preserve Web Page Structure (‘Cross-site Scripting‘)
• Improper Sanitization of Special Elements used in an SQL Command (‘SQL Injection’)
• Cross-Site Request Forgery (CSRF)
• Reliance on untrusted input in a security decision
• …

What he says on git :

Git certainly seems to be liked for its power. Folks go ga-ga over it’s near-magical ability to do textual merges automatically and correctly, even in the face of file renames. I haven’t seen any objective tests comparing merge capabilities, but the subjective opinion favors git.

[...]

For many git’s biggest downside was its oft-cryptic commands and mental model. Ben Butler-Cole phrased it beautifully: “there is this amazingly powerful thing writhing around in there that will basically do everything I could possibly ask of it if only I knew how.” To its detractors, git lacks discoverability – the ability to gradual infer what it does from it’s apparent design. Git’s advocates say that much of this is because it uses a different mental model to other VCSs, so you have to do more unlearn your knowledge of VCS to appreciate git. Whatever the reason git seems to be attractive more to those who enjoy learning the internals while mercurial seems to appeal more to those who just want to do version control.

[..]

People generally find that git handles branching better than Mercurial, particular for short-lived branches for experimentation and check-pointing. Mercurial encourages other mechanisms, such as fast cloning of separate repository directories and queue patching, but git’s branching is a simpler and better model.