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).
- autotools
- 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.
Communication
- 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.
Optimization work
- Understanding processing, memory, and IO costs.
- Avoiding premature optimization while avoiding obvious performance errors.
- Using Oprofile, SysProf, system tap, etc.
Debian/Ubuntu packaging
- Package a new version of an existing package, such as Glom, in the Openismus PPA.
- Package something new for Ubuntu.
Embedded Linux
- Use of Scratchbox with Maemo.
- Port something to Maemo.
- Package it for maemo-extras.
- Using a BeagleBoard:
- Set up the BeagleBoard and get something running.
- Try to install Mer.
- Putting a self-built distro on generic hardware (BeagleBoard), using Poky or OpenEmbedded.
- 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.
Hi Murray!
Nice list, small note:
For C:
“Initializing local variables, even if you don’t think it’s necessary.”
actually, that prevents a useful warning from gcc (‘X may not be initialized’ in some code path),
so I usually do the initialization just before use. There’s a small risk in depending on a gcc for mistakes here,
but in my experience (and in my case), the useful warning helps me more to fix (more subtle) bugs than
the early initialization does.
Very nice post. This kind of makes me want to get into Gnome development. I’m mostly a Windows user but I do play on Linux. But when I use Linux, it is the Gnome desktop. I guess I liked Gnome early on back in 1998 when I discovered it used the gtk+ toolkit that I was already familiar with. Believe it or not, I was introduced to gtk+ as a way to program on Linux via some magazine. I found gtk+ to be much more beautiful than writing something in the Win32 C API.
I would love to read details on what you use to train your developers. These details may help me get more into Linux and Gnome.
hey, djcb, but the compiler doesn’t catch this, I think:
int something;
get_something_but_implementation_forgets_to_set_it_in_some_case(&something)
do_something(something);
?
Yes, we do strongly believe in warnings-as-errors, and wish all our customer projects did too. I also believe that deterministic wrong behaviour is better than random wrong behaviour, so we believe in fixing valgrind warnings too.
> I would love to read details on what you use to train your developers.
We use time and people and the real world. If you don’t have us to train you, just try to get involved in a real project, fixing real bugs.
Great training!
For the general community I think that the “Other C stuff and basic tools” topic is the one that lacks more documentation, good practices and one centralized way to learn it. Those tools are crucial to make a succesfull and good citizen application in the Gnome environment. I’ll love to see some inspired developer to write some lines on this because is something absolutely necesary if you want to share your scratchy code xD
Hi Murray,
Well, the compiler does raise a warning, but *only* when compiling with optimizations (-O1 or higher). It’s a bit of a gotcha.
I like warnings-as-errors too, but only when I can control the compiler. For normal builds, I use
AM_CFLAGS=-Wall -Wextra -Wno-unused-parameter
AM_CXXFLAGS=-Wall -Wextra -Wno-unused-parameter
which keeps me honest. Also, I use some special rules in my Makefiles, again, another automatic check to keep things in order. They are part of the checks that are done before releasing.
# this warns about function that have a cyclomatic complexity of > 10,
# which is a sign that it needs some refactoring. requires the pmccabe
# tool. If all is fine, it outputs nothing
cc10:
@$(PMCCABE) `find -name ‘*.c’ -o -name ‘*.cc’` | sort -nr | awk ‘($$1 > 10)’
# this warns about functions that are over 33 non-comment lines long, which is a
# sign that they need some refactoring. requires the pmccabe tool. if
# all is fine, it outputs nothing
line33:
@$(PMCCABE) -c `find -name ‘*.c’ -o -name ‘*.cc’` | awk ‘($$5 > 33)’