After our successful year of training at Openismus, I thought I’d publish the rough bullet-point list that we used. Whoever we choose for the following year will repeat much the same process, with in-depth critique and a dose of reality.
These were our overall aims:
- Familiarity with the programming languages, toolkits, and tools, beyond the average.
- Good quality habits – documentation, ChangeLogs/commit-messages, bug filing, simple code.
- Good communication – politeness, precision, knowing who/where to contact, tracking progress and following up.
And this is the stuff that we checked off along the way:
Knowledge of C
- Respect for memory. True understanding of pointers.
- Understanding of the many ways to use * and & and , declaring and dereferencing.
- Understanding of state (Such as a widget’s data, or a user_data struct, or a C++ class’s member variables.)
- Understanding function pointers, including their weird syntax, made easier by use of typedefs.
- Basic understanding of object-orientation – Write functions that have a namespaced prefix and that take a first self/this parameter.
- Write init and free functions where appropriate.
- Don’t use a prefix that is used by an existing library.
- Use of enums (or defines if necessary, or static constants if appropriate) instead of magic numbers/strings.
- Breaking code up into small blocks, separated by empty lines, with pseudo-code comments above each block. In small functions, of course.
- Initializing local variables, even if you don’t think it’s necessary.
- The GTK+ coding style, which is common for C.
Knowledge of GTK+
Familiarity with GTK+, to the level of implementing new widgets.
- Reference-counting: Conventions and special cases (gstreamer and tinymail use a different convention, for instance).
- Child widgets don’t really use reference-counting. They are destroyed by parents regardless.
- Glade and GtkBuilder
- Implement a new widget, doing some custom drawing and/or containing some child widgets. Make sure that you understand what the various construct/init/finalize/destroy/etc vfuncs do.
Other C stuff and basic tools
- Tools: gdb, valgrind, svn, git, diff, patch.
- Writing ChangeLog entries or commit messages (mentioning files and functions, and what changed in them and why).
- gtk-doc syntax, and knowing what developers need to see in the documentation. Mention the what, when, why, how, and “see also”.
- Familiarity with Clutter, to the level of implementing new actors. See the Openismus Clutter tutorial.
- Fix some GNOME bugs, submitting patches. Maybe work with the gnome-love group.
- Join the relevant GTK+, GNOME, Maemo, and Qt mailing lists.
- Add Openismus employees to your GNOME bugzilla Users To Watch list. Someone will watch yours too.
- Be repeatedly told to file bugs and patches, and to follow up on them. File bugs about documentation too.
Familiarity with C++ – at least the parts used by gtkmm and Qt
This takes more time than anything else, but its doable with motivation and mentoring from our experts.
- Read a full book, such as Accelerated C++, cover to cover.
- Understanding of classes, constructors, inheritance, polymorphism.
- Understanding of references.
- Understanding of const and mutable.
- Templates. And template specializations.
- Use of std containers.
- Familiarity with gtkmm (easy because they know GTK+ already.)
- The gtkmm coding style, which is common for C++.
- The doxygen/javadoc syntax.
- Wrap some new GTK+ API for gtkmm.
- Fix a Glom bug. For instance, there are some simple Glom gnome-love bugs.
- Familiarity with Qt. Understand what moc does. Do something real-world with it’s (quasi) model/view widgets. Understand QString historical oddities.
- Maybe find a bug to fix in KDE.
- Understanding processing, memory, and IO costs.
- Avoiding premature optimization while avoiding obvious performance errors.
- Using Oprofile, SysProf, system tap, etc.
- Package a new version of an existing package, such as Glom, in the Openismus PPA.
- Package something new for Ubuntu.
- Use of Scratchbox with Maemo.
- Port something to Maemo.
- Package it for maemo-extras.
- Using a BeagleBoard:
- Be aware of differences/pros/cons between Poky and OpenEmbedded.
- Document how a customer might prepare and maintain a custom debian (or Ubuntu) distro for their embedded hardware project. For instance, how to install and use an autobuilder for packages.