Fuse Fabric installation options

If you want to play a bit with the Fuse Fabric, you can start the fun by choosing one of the following options:

• download the Fuse Fabric bundle (which is basically a FuseESB distribution with the pre-installed Fabric support)
• install Fuse Fabric on vanilla Karaf (or ServiceMix) container via OSGI feature

Although installing Fabric on the vanilla container is very temping, this option doesn't work well in the latest stable Karaf/ServiceMix/Fabric releases. Keep in mind however that, according to the information I've found on the mailing lists, the latest development versions of the Karaf/ServiceMix/Fabric work like a charm.

Since deploying snapshot versions of containers to the production is not an option, at this moment I would recommend to stick to the bundled version of the Fuse Fabric. If you want to use this fine piece of software, you need to migrate your configuration to so called Fabric profiles anyway. With created profiles, migrating from vanilla ServiceMix to Fabric bundle is not a big deal.

Kosher Ubuntu 12.10 - Full media support

Ubuntu comes with almost ready-to-go Desktop operating system. Almost, because my favorite Linux distribution separates free and non-free software packages. This is especially visible when comes to the media codecs support, since the latter are often released under restrictive licenses.

In practice, you need to add additional bundles repository and explicitly install some packages from it. Also some of the restricted packages you would like to download are available in the standard repository.

Start with adding Medibuntu repository to your system...

sudo -E wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list
sudo apt-get --quiet update
sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring
sudo apt-get --quiet update

The command below will integrate Medibuntu packages with your Desktop even tighter (by adding Unity lauchers and so forth).

sudo apt-get install app-install-data-medibuntu apport-hooks-medibuntu

Now install codecs with closed licenses...

sudo apt-get install w32codecs win64codecs ubuntu-restricted-extras

If you watch movies from DVDs on your computer, you would like to have installed support for the encrypted ones (i.e. the majority of the positions available on the market).

sudo apt-get install libdvdread4
sudo /usr/share/doc/libdvdread4/install-css.sh

After applying all the steps above, non-free media and Ubuntu will become friends again.

Kosher Ubuntu 12.10 - Broken wireless network

After you install Ubuntu 12.10 and update the installed packages to the latest version, your machine will stop to find wireless networks. Unfortunately the latest kernel update for Ubuntu doesn't work well with Broadcom (BCM) wireless network chipsets.

What you need to do is connect your computer to the wired network, download kernel headers...

sudo apt-get install linux-headers-generic

...rebuild and reinstall your wireless network chipset module...

sudo apt-get install --reinstall bcmwl-kernel-source

...and finally reload the mentioned module.

sudo modprobe wl

Now do enjoy your wireless network again.

Design consensus - the Apache way

The ways to lead the team

There are basically two extreme ways of leading the team of software engineers.

• Supervision. You control people in your team. You tell them what to do. You make a decisions for them, which you order to execute.
• Democracy. You are equal to the others engineers in your team. Your voice in design and architectural issues is equal to the voices of the others in the team.

As we well know, the bad team leads supervise their team. Good team leads serve their team and help them to perform.

The flaws of democracy

Let's face it - democracy is not always the best option.

Democracy in a team is good as long as all the team members are equally motivated, experienced and mature software professionals.

And what about new team members? They don't know the culture of your team yet. They need time to learn how people in the team works and what are the standards within in.

What about the responsibility? Your team works for somebody. Who should take the responsibility in the front of the business holder in the case of the failure? Who approves the critical decisions and takes responsibility for them?

The Apache way to lead the team

In Apache, all design decisions are based on the consensus between team members (committers). Voices of the project leaders (PMCs) are stronger than votes of regular committers.

However PMCs don't give the orders to the committers. They work with the committers on regular basis instead.  But in the case of design or architectural disagreement, PMCs are the ones who decide.

In order to become a committer, you need to work with the project team as a contributor. While being a one, you got no decision voice in the discussion. The is the time you learn the project and the way the Apache works.

I like to think of the good team as of the little Apache project. With a tech lead being the PMC, regular team members being the committers and team newcomers being the contributors.

Choose your weapon - wiki tools

So you feel bad about not using wiki, as you ought to? You wanna change it? You need a recommendation for the great wiki tools? I can recommend two of them.

• Google Sites - free wiki from Google. Perfect choice if you need to save some money and can keep your data in the cloud (people in corporations not always can).
• Confluence - great product from the great company named Atlassian. We use it at the Apache Camel. Can can host private instance of Confluence starting from 10$ per year (or pay Atlassian 10$ per month to use their cloud).

I've also worked with Alfresco and JSP Wiki, however I don't recommend them. Too complicated and unintuitive comparing to the Google Sites and Confluence.

I'm curious about your experiences with wiki tools. Any feedback will be highly appreciated. :)

Team hive mind

I'm always surprised how many developers don't got the habit of using company wiki. Wiki is a must-have for any development team that wants to be productive in the long run.

• If you don't share the details of your system's architecture on the wiki, how can you expect your team to understand the application they are working on?
• If you don't share the description of your development process, how can you expect your team to follow it?
• If you don't describe your coding practices and standards on shared wiki page, how can you expect your team to apply them?
• If you don't document the results of the research that took you a week, how can you expect your team not to loose another week on reinventing the wheel?
• If you don't share your knowledge and keep it in a single place, how can you even think about leaving the company for a week of a holiday?

Whenever somebody within your team asks you a project-related question, ask yourself why this information is not documented in the wiki in the first place.

Camel Extra available in Maven Central

I'm very happy to announce in the name of the Camel team that starting from today Camel Extra will be available to download from Maven central repository. The very first version of Camel Extra published to the Central is 2.10.0.

That basically means that starting from version 2.10.0 you don't need to include the ugly Camel Extra repository in your Maven POM configuration anymore. All you need to do is to specify the Maven dependency and it will be automagically downloaded from the Maven Central repository.

<dependency>
  <groupId>org.apache-extras.camel-extra</groupId>
  <artifactId>camel-hibernate</artifactId>
  <version>2.10.0</version>
</dependency>

This is the first step to keep Camel Extra in sync with its bigger brother. Many people complained about the quality of releases of the Camel Extra (if I got a dollar for every complaint about Hibernate integration I've heard...). Our goal is to make Camel Extra as reliable as "regular" Camel.

PS The major change we introduced in the 2.10.0 release is changing the Java package name from org.apachextras.camel to org.apacheextras.camel (please note the double "e"). We decided that releasing to Maven Central is a good moment for this kind of aggressive refactoring. Remember then to update Java package in your existing routing code.