The interesting point here, assuming WeTab OS is actually a customised MeeGo version, would be that it is capable of runnning Android applications. It was tried before for Ubuntu, but they faced some problems because Google was not open sourcing crucial Android components.

But the WeTab is not restricted to Android apps; instead, it uses a meta-store, supporting native, Java, Linux, Adobe AIR® and Android Apps.

WeTab is also based on Intel Atom, so another distinctive point is that would be the first commercial contender fulfilling fundamental Android x86 project goals: port vanilla Android, which has important ARM dependencies in core services and libraries (e.g. instruction set architecture optimizations), to Intel Architecture platforms and its streaming SIMD instructions.

These facts, and the customized UI (showed in the above video), may be interpreted as side-effects of platform commodization: differentiation efforts and value-added proposals. I bet the future deserves us these sort of offers, at least from the heavy-weight contenders in the mobile arena.

And, while I am writing these lines, the WeTab has already become the best selling Tablet-PC in Amazon.de!

"To use something other than TextViews for the array display, for instance, ImageViews, or to have some of data besides toString() results fill the views, override getView(int, View, ViewGroup) to return the type of view you want".

And then you have an insightful and extensive method description like:

public View getView (int position, View convertView, ViewGroup parent)

So… how do I override getView to make everything work as expected?

The best answer lies, as usual, in the Android Framework’s Java implementation. Using the getView original code as a template, it is really easy to figure out the details of your reimplementation:

    public View getView(int position, View convertView, ViewGroup parent) {
        return createViewFromResource(position, convertView, parent, mResource);
    }

    private View createViewFromResource(int position, View convertView, ViewGroup parent,
            int resource) {
        View view;
        TextView text;

        if (convertView == null) {
            view = mInflater.inflate(resource, parent, false);
        } else {
            view = convertView;
        }

        try {
            if (mFieldId == 0) {
                //  If no custom field is assigned, assume the whole resource is a TextView
                text = (TextView) view;
            } else {
                //  Otherwise, find the TextView field within the layout
                text = (TextView) view.findViewById(mFieldId);
            }
        } catch (ClassCastException e) {
            Log.e("ArrayAdapter", "You must supply a resource ID for a TextView");
            throw new IllegalStateException(
                    "ArrayAdapter requires the resource ID to be a TextView", e);
        }

        T item = getItem(position);
        if (item instanceof CharSequence) {
            text.setText((CharSequence)item);
        } else {
            text.setText(item.toString());
        }

        return view;
    }

To search and browse Android Framework’s code, a very useful tool is Google’s codesearch. For instance searching for "android arrayadapter getview" points us directly to the ArrayAdapter.java getView code, and there we can use the left-hand "Outline" tab to browse the different methods… (Of course, real men grep -r their local git)

To generate the bootchart, you just need to mic-chroot and install these two packages (the default kernel has process accounting enabled):

yum install bootchart acct

Then, just copy the image to the boot media, and turn the power on Your chart will be stored in /var/log/bootchart-YYYYMMDD-HHMM.svg

(Click to enlarge)

I used to spend hours and hours dissecting different live cd systems, or setting up network boot scenarios, so it was likely that I would end up doing the same with this lovely Aava Mobile running MeeGo Handset

In this post, I will explain just the first stages of its boot sequence, involving the boot loader, the kernel and the initial ramdisk. Details about the system and the graphic session initializations will be presented in next posts.

Boot loader

MeeGo Handheld uses kboot as bootloader, and a two-step boot sequence. Basically, it involves booting the kernel, and then running an intermediate, ramdisk based system, before loading the root filesystem and letting the classic UNIX system init process start.

Kernel

MeeGo Handheld kernel’s default parameters are:

ro pci=noearly console=tty1 console=ttyS0 earlyprintk=mrst loglevel=8 nosplash s0ix_latency=160

An brief explanation for each parameter is included below:

• ro: mount root device read-only on boot.
• pci=noearly: skip any early type 1 scanning.
• console=tty1: set tty1 as output console device.
• console=ttyS0: set ttyS0 (serial) as output console device.
• earlyprintk=mrst: early printk feature (mrst => Moorestown) for debugging during the early stages of the bootup. It allows to use printks even before the real console drivers are available.
• loglevel=8: full debug. Any kernel message will be printed to the console.
• nosplash: not used by the kernel, but forwarded to the root filesystem’s system init.
• s0ix_latency=160: related with the advanced power management capabilites of the Moorestown platform.

Ramdisk

Once the kernel is loaded, it enters the ramdisk initialization sequence. Its main goal is finding and mounting a suitable root partition, so you don’t need to hardcode it, and the same image can be reused regardless you are storing the root partition on an SD, USB or NAND device.

MeeGo Handheld ramdisk is based on Fedora’s. It includes a basic selection of early user space commands, but -surprisingly for an embedded environment-, it is not Busybox based, sporting a complete bash shell and the full-fledged version of these tools.

Filesystem layout

The ramdisk contents are a bare bones UNIX system, stripped down to contain just the basic stuff:

├── bin
│   ├── bash
│   ├── cat
│   ├── chmod
│   ├── cut
│   ├── dd
│   ├── dmesg
│   ├── echo
│   ├── env
│   ├── grep
│   ├── kill
│   ├── less
│   ├── ln
│   ├── ls
│   ├── mkdir
│   ├── mknod
│   ├── mount
│   ├── rm
│   ├── sed
│   ├── sh -> bash
│   ├── sleep
│   └── umount
├── dev
├── etc
│   ├── fstab
│   └── udev
│       └── rules.d
├── init
├── lib
│   ├── ld-linux.so.2
│   ├── libacl.so.1
│   ├── libattr.so.1
│   ├── libcap.so.2
│   ├── libc.so.6
│   ├── libdl.so.2
│   ├── libpcre.so.0
│   ├── libpthread.so.0
│   ├── librt.so.1
│   ├── libtinfo.so.5
│   ├── terminfo
│   │   ├── a
│   │   │   └── ansi
│   │   ├── d
│   │   │   └── dumb
│   │   ├── l
│   │   │   └── linux
│   │   └── v
│   │       ├── vt100
│   │       ├── vt100-am
│   │       ├── vt100-nav
│   │       ├── vt102
│   │       ├── vt200
│   │       ├── vt220
│   │       └── vt52
│   └── udev
│       └── rules.d
├── proc
├── sbin
│   ├── blkid
│   ├── blockdev
│   ├── chroot
│   ├── dmsetup
│   ├── insmod
│   ├── killall5
│   ├── losetup
│   ├── lsmod
│   ├── modprobe
│   ├── pidof
│   ├── run-init
│   ├── udevadm
│   └── udevd
├── sys
├── sysroot
└── usr
    └── lib
        ├── libblkid.so.1
        ├── libdevmapper.so.1.02
        └── libuuid.so.1

/init script

Once the kernel loads, it starts executing the /init script, that:

1. Sets up the basic environment
2. Parses kernel command line options
3. Sets up root filesystem
4. Transfers control to the root filesystem’s init

We are going to walk through this small piece of code, skipping some setup and debug sections for clarity’s sake.

1. Set up the basic environment

First, it redirects standard output and error to /dev/console. This is important for debugging, as the console device /dev/console is handled by the kernel, and we can change it using boot params, e.g. to access display-less devices using a serial interface.

Then, the minimal facilities are set up. An initramdisk is a very early, almost "naked" user-space, so we need a way to interact with the operating system: some device files and the Linux kernel’s pseudo filesystems. From this point on, any executable on the ramdisk has a way to perceive and interact with the system. Basically, this stage involves:

• Setting up udev’s basic environment under /dev (mount udev and create basic device files under /dev: console, null, kmsg, pts, shm, fd, stdin, stdout, stderr)
• Mounting pseudo filesystems (/proc and /sys)
• Disable the usermode helper hotplug mechanism (it relies on udevd instead)

2. Parse kernel command line options

It parses the command line options, and then:

• Overrides the default values if any specific ones are provided.
• Blacklists any module that may interfere with the system.
• Handles the kernel module options, writing them on the ramdisk’s modprobe.conf

The main variables used by the script are detailed below:

• init: specifies the program which will be executed once the initial ramdisk stage ends.
• ro, rw => root_ro, root_rw variables, control wether the root file system is mounted read-only or read-write.
• quiet: enable or disable boot process debug messages.
• shell: if enabled, drops the user to a shell, just after setting up /dev/root.
• eshell: if enabled, drops the user to a shell, just before init.

Other variables, like live_ram, live_locale, overlay or check, are not used.

3. Set up root filesystem

Most of the /init script code handle setting up the root filesystem.

The detection has two clear execution paths, depending on the "autodetect" variable’s value. This variable is not defined or processed from the kernel’s command line, so it seems it’s just some dead code from another MeeGo initrd.

First, three variables are initialized from the embedded /etc/fstab file, or the related kernel command line options:

• root
• rootflags
• rootfstype

For instance, the default /etc/fstab file, stored inside the ramdisk, holds this root filesystem definition:

/dev/sda1 / ext3 defaults,noatime 0 0

Once these variables are set, if autodetect is enabled, it adds different udev rules, depending on how the root filesystem is specified via the root variable, like /dev/disk/by-label, /dev/disk/by-id, CDLABEL, LABEL, UUID, etc. It just does nothing if root is specified by another /dev/* path.

If autodetect is not enabled (or not defined, which seems the case), it just starts udev, waits for it to be settled, and then searches for a filesystem at:

• SD devices: mmcblk0, mmcblk1, mmcblk2, mmcblk3
• USB devices: sda, sdb, sdc, sdd, sde, sdf
• NAND devices: nda, ndb, ndc

After this process, the thingtomount variable must be set, or an error has occurred.

(At this point, if the "shell" parameter is enabled, the user is dropped on a bash shell)

The final stage of the root filesystem setup involves making sure the device specified by thingtomount holds a suitable root file system, composing mountoptions with rootflags, root_rw and root_ro, and, finally, mounting the root filesystem at /sysroot

4. Transfer control to the root filesystem’s init

Once the new root filesystem is available, the process is almost done. The script just:

• Sets wether or not to pass kernel cmdline to the root filesystem’s init (because init can be overriden by a kernel parameter)
• (At this point, if the "eshell" parameter is enabled, the user is dropped on a bash shell)
• Kills udevd to enable the new system to take control of the plugging events.
• Calls /sbin/run-init "$@", which is in charge of this little piece of black magic:

#!/bin/bash
cd /sysroot
mount --move . /
exec /sbin/chroot . "$init" "$@"

At this point, everything is ready for the system initialization to start…

It’s still a little bigger than a Nexus One, but anyway, it’s amazing how they managed to miniaturize a complete computer into a SOC:

Since mid 2007, a device like a Samsung Q1 Ultra has reduced four times its size, sporting some new goodies like a bunch of sensors (ambient light, proximity, 3D compass, accelerometer…).

MeeGo for Handhelds is under heavy development, and Intel and Nokia efforts for creating a compeling environment for users, but also for developers, are going to be really, really interesting. Exciting times ahead!

The first half of the talk outlined some of the features and practical problems of cloud computing. For instance, the lack of a suitable licensing scheme from some OS/application vendors, the difficulties integrating legacy systems, or the concerns about the security of production environments. This problems, especially the last one, are limiting cloud deployments to development and integration environments, using private cloud technologies.

Then he went on comparing some of the main offerings for the deployment of these sort of clouds:

Ubuntu Enterprise Cloud: excellent EC2 support (using Eucalyptus, hi Mårten! ), easy to setup, good documentation and excellent support. The best option to deploy quickly a private cloud.

Regarding the “for Agile teams” part, unfortunately the talk didn’t delve deeper into development topics, but it mentioned build and test automation, and the need for a good scripting platform/API.

You can find the podcast here.

He talked about how naive some of the Extreme Programming and Agile original principles were, regarding analysis activities. Replacing “the customer” in make the customer always available with a business analyst (a customer proxy) is the way he proposed to deal with this problem. E.g. in an SCRUM team, he proposed a Product Owner role encompassing technical leadership, product management and business analysis duties.

I liked his explanation -with actual data from the MIT Sloan review-, of why, in an organizational improvement context, doing the things right before is better than doing the things right at first. (Slide 18, The Alignment Trap)

When he talked about Just In Time Requirements, I was confronted with the same thoughts I have most of the times I apply this technique: clients, especially top management, are reluctant to this kind of uncertainty. It takes time, and a tactful approach, to convince them.

I don’t agree, at least as a general definition, with his standpoint of SCRUM as a “project management method without a project manager”. Besides pure managerial tasks (like some staffing details), I think a separate person is still needed to have a full (not iteration-centric) management view of projects, and most important, to avoid distractions and cope with unplanned or non-deterministic events (e.g. chasing equipment providers or busy external stakeholders).

The slides and video are available.

1. Commiting to the repository (and thus triggering a new transaction).
2. Using an existing transaction, through the --revision command line option (intended for testing).

In both cases, you must install LanguageTool before.

To create a brand new repository and test it:

# Download dependencies
sudo aptitude install subversion
# Set up local repo, downloading the script to the appropiate directory
mkdir -p /tmp/srv/svn/foobar
svnadmin create /tmp/srv/svn/foobar
wget http://people.warp.es/~xtor/pre-commit-oo.org -O /tmp/srv/svn/foobar/hooks/pre-commit
chmod a+x /tmp/srv/svn/foobar/hooks/pre-commit
# Do a local checkout
mkdir -p /tmp/devel/svn/foobar
svn checkout file:///tmp/srv/svn/foobar /tmp/devel/svn/foobar
cd /tmp/devel/svn/foobar

Now, just copy an odt document to /tmp/devel/svn/foobar, add it to the repo and try to commit… You should see the pre-commit hook fail.

Or, if you have a repository with OpenDocument files commited, you can just call the pre-commit hook as a regular script, with the --revision parameter:

# Usage: pre-commit path/to/repo --revision rev_num
/tmp/srv/svn/foobar/hooks/pre-commit /tmp/srv/svn/foobar/ --revision 1

Enjoy it!

CMMi 2 complements agile methodologies

Agile methodologies focus on development activities, while the first level of the staged CMMi (which in turn is level 2) focus on management. If your team is great developing software, you can still learn a lot of things from CMMi from a management point of view. For example, Measurement and Analysis will help you to define business goals and KPIs.

The model must be interpreted

Theorically, the CMMi model is “methodology-agnostic”, but most of the examples you are going to find trying to explain it are assuming waterfall lifecycles or other heavy-weight process customs. You will need to be creative interpreting the model and the examples.

The model must be fitted to your software lifecycles

For instance, CMMi defines two process areas for project management: Project Planning and Project Monitoring and Control. It is a perfect fit for a predictive methodology with two clear Planning and Implementation phases, but when you are using an agile approach you will have planning and monitoring each iteration, and sometimes an additional planning phase prior to start working.

Your projects should be alike

For processes to be repeatable, and fulfill a lot of the standarization requirements covered by the generic practices, you need to repeat the same kind of projects. For instance, at Warp we do projects that range from ERP/CRM stuff to embedded systems, so we use different requirements and estimation techniques. CMMi wants you to standarize estimation tools and techniques, document every detail, and make sure everybody is aware and uses them. But when the right choice for each project is an ad-hoc technique, you would end up documenting a whole different process for each project!

Quality, but not at any cost

An important fact, especially if you are a small custom software development company with about 20 people, is that you need to find a trade-off between fully implementing some practices, like Process and Product Quality Assurance, and how it translates to your cost structure. For example, you will need to relax some practices to avoid hiring PPQA people. (For those not acquainted with CMMi, PPQA is different from “software testing”).

Implementing CMMi and passing a CMMi appraisal are different things

CMMi appraisals require a lot of extra work (or plain waste), that you simply don’t need if you are just interested in enhancing the way you work. For example, each time you review a project’s deviation, if the project is on track you will need to record that “you have reviewed the project”, and that “the project is on track”. So instead of adopting common sense management rules, you will be focused on creating Muda!

To sum up: avoid judging CMMi beforehand, learn about it and just get the good things which add value and minimize waste.

1. Our pre-commit hook has a transaction as its input.
2. A transaction is composed of changes to different files.
3. For each file changed, we check it against a set of rules.
4. If we found any error, the transaction fails and the commit is aborted.

So our pre-commit hook has two main classes:

There is also a small auxiliary function, create_option_parser which creates the argument parser, feeding SvnTransaction with the required parameters.

So the hook’s main snippet is:

def main():
   "Executes the pre commmit hook program."

   parser = create_option_parser()

   try:
      transaction = SvnTransaction(parser.parse_args())
   except:
      parser.print_help()
      return 1

   errors = transaction.check()
   sys.stderr.write(transaction.message())

   return errors

if __name__ == '__main__':
   import sys
   sys.exit(main())

transaction.check() extracts the files affected and call the actual file checker, storing messages and errors raised to be used afterwards.

   def check(self):
      """"Checks all the files added or changed in the transaction, returning
      the number or errors found."""

      errors = 0

      for file_name in self._files_changed():
         tmp_file = self._dump_file_content(file_name)

         checker = OdtChecker(tmp_file.name)
         errors += checker.check()
         self._message += checker.message()

         tmp_file.close()

      return errors

Each call to checker.check() checks the file handled by the checker object, using the next tools:

Keep in mind that the current version uses Spanish language checks, and also the standard aspell dictionary. For your own usage, you would probably want to create a custom dictionary including terms like VAT, NDA, SPA…

   def check(self):
      "Checks the OpenDocument file, returning the number or errors found."

      self._odt2txt()
      self._check_ortography()
      self._check_grammar()

      return self._n_spelling_err + self._n_grammar_err

   def _odt2txt(self):
      "Converts the OpenDocument Text file into a plain text file."

      odt2txt_cmd = '%s %s --width=-1 --output=%s' \
                    % (ODT2TXT, self._path, self._tmp_file)
      odt2txt_msg = getoutput(odt2txt_cmd)

   def _check_ortography(self):
      "Checks the plain text file looking for spelling errors with aspell."

      check_cmd = 'cat %s | %s --lang=es list | sort | uniq' \
                  % (self._tmp_file, ASPELL)
      self._spelling_err += "\nChecking ortography using %s\n\n" % check_cmd
      self._spelling_err += getoutput(check_cmd) + "\n"
      self._n_spelling_err += len(self._spelling_err)

   def _check_grammar(self):
      "Checks the plain text file looking for grammar errors with LanguageTool."

      check_cmd = '%s -jar %s --language es -d WHITESPACE_RULE %s' \
                  % (JAVA, LANGUAGETOOL, self._tmp_file)
      self._grammar_err += "\nChecking grammar using %s\n\n" % check_cmd
      self._grammar_err += getoutput(check_cmd) + "\n"
      # 2 leading lines + 1 at the end, and 5 per error
      self._n_grammar_err += (len(self._grammar_err)-3) / 5

The paths to the different tools can be customized at the beginning of the file:

ASPELL = '/usr/bin/aspell'
JAVA = '/usr/bin/java'
LANGUAGETOOL = '/tmp/Language/LanguageTool.jar'
ODT2TXT = '/usr/bin/odt2txt'

SVNLOOK = '/usr/bin/svnlook'

In a forthcoming post, I will explain two different ways to test this pre-commit hook, so stay tuned

See also: