Monday, October 29, 2007

Quickies

I have a number of presents for you all.

First off is a little file manager that I wrote several months ago. It is called Ambit and is pretty much a weekend clone of OS X's Finder.
http://github.com/icefox/ambit/tree/master

Robero's wrote a kick ass C++ parser and code model. With it you can quickly and easily parse C++ and walk it sources to be able to do all sorts of cool things. Older versions of Roberto's parser can be found in various places in KDE, but they don't compile with just QtCore (the one in KDevelop require kate!) so I pulled this one out of the Qt Jambi sources and bounbled it up, added an example and put it up online where others can easily get at it to make their own tools such as those I talked about in making testing enjoyable with parsers.
http://github.com/icefox/rpp/tree/master

I have begun learning Lisp (or more exactly Common Lisp). Rather then just trying to make something and read tutorials as I need them I am slowly going through some Lisp books I own, working through the problems and exercises. I started a blog with the notes as I learn Lisp. http://takentheredpill.blogspot.com/

Wednesday, October 17, 2007

Why working for Trolltech kicks ass

  1. An office with a door and window!
    Do you find open air office cubes help you get in the zone for programming? Neither do I. Many people have written why offices are more productive then cubes so it is surprising that places like Google still use cubes. What is better then an office with a door? How about a window the size of the wall with a nice view. Not a view of another building twenty feet away, but hills, trees, and the occasional bird sitting on the ledge. At Trolltech there are two developers in every office (photo was taken during a move when there was only one desk in it).

  2. Smart developers
    Walking down the hall you will find many smart developers. They aren't just smart, they like what they do and many work on open source projects such as KDE and Webkit. How about putting Qt on the dreambox, hosting KDE hackathons on Sunday's, contributing to Git and much more. We love what we do and it shows.

  3. Release source code
    Go work for Google and there is a good chance you will never get to release your source code and perhaps never even be allowed to talk about it! Qt is released under the GPL license. Qtopia is released under the GPL. QScript, Qt-jambi, etc all GPL. We put up nightly snapshots for both our stable branch and main branch and host a matching git repository with them. We encourage releasing the source to our projects under a open source license. We put the source for our projects, neat ideas, and components up on labs.trolltech.com before they go in Qt so you can check them out. As a developer when you hack on code in Qt it doesn't end up in an internal black hole or locked in a binary, but is available for you to look at years later and reminisce or show off*.

    *Of course that also means that everyone else reads your code too so customers that catch your bugs will often send in useful patches so remember to write full test coverage.

  4. Company trips
    In the fall the developers head off for a cabin trip. Those in the Berlin office drive up and bring some excellent German beer and food. We rent some cabins for a weekend and have a lot of fun. In the spring the entire company heads off for a fantastic ski trip. Trips often include many other events such as bike rides, hikes, snow man contests and on one occasion a sleigh ride.

  5. labs.trolltech.com is a place where we can blog about what we are working on, put up code, projects and ideas. We get input on API and features and users get to mess around with what is coming down the pipeline and get solid information about where Qt and Trolltech is headed. As a developer you can talk about what you are working on, you can show of API and get feedback to make your product better.

  6. Creative Fridays
    You have probably heard of Googles 20% rule. At Trolltech we have creative Friday where you get to work on a creative project. Many of these end up labs.trolltech.com so even if they don't end up succeeding or not put in Qt they will still be on labs. Got an idea or itch to make something better that is outside of your day to day project then this is a perfect fit and many excellent improvements and features in Qt have come about because of this.

Monday, October 08, 2007

What I learned from Qt that made me a better programmer in C++

Reginald Braithwaite says he would love to hear stories about how programmers learned from X that makes me a better programmer in Y. So here are a few quick thoughts on how the Qt library made me a better C++ programmer.

1) The API matters, a lot


In a way Trolltech is in the business of selling good API's. By making their API consistent across Qt, it is easier as developers to understand how the class works and one can often guess correctly what an API will be without having to look it up. You wont find functions that take six bool arguments or function names that are overly vague when a better one will do. Each new function gets multiple API reviews and before every release all new functions and classes get a final review. Check out this excellent article on designing C++ APIs for some good examples.

Every time you add a new class or function you are introducing new API. Even if that API is only for yourself it is something that you will have to use and later read. On personal projects taking two minutes to step back and cleanup the API will payoff in the long run. Your code will be more consistent and when someone else comes along to check it out they will not only be happier with the cleaner API, but have an easier time getting up to speed and more likely to contribute back.

2) How to hide your private data (or working around one of c++'s flaws)


When building libaries in C++ there are a lot of rules you have to follow to make sure that you do not break binary compatibility.

The first and best step you can take is to make sure that your API is good (see #1). This goes a long way in fixing design issues before you can't anymore. Walk though use cases and make sure that the class provides what is needed. Hopefully most of the time you should be able to get away with just adding a new function or two, but the core of the class will be stable.

But behind the public API there are tricks you can used to hide all of the internals of the class in a way that lets you change them at will without breaking binary compatibility. One of them is the private class:

class FooPrivate;
class Foo {
public:
Foo();
private:
FooPrivate *d;
};


A technique that is used in Qt and KDE each class has a private class (with its own header). Data, implementation and private functions are moved into the private object. This provides a number of very positive benefits.
- You can add internal virtual functions, change function names, and generally do whatever you want.
- The implemenation can be completly changed without worrying about breaking binary compatibility.
- Users of the class don't need to include all the headers for private objects, reducing compile time.

Popular Posts