Developing Programmers .com

I was looking for a simple way to delete all subwidgets and layout from a Qt container widget today.

Mark pointed me to a post that suggested a method, and I thought others might benefit from a code example of how I ended up solving this.

void MyWidget::clearSubWidgets()
{
    QObjectList ch = children();
    foreach (QObject *o, ch)
    {
        QObject *todel = qobject_cast<QWidget *>(o);
        if (!todel)
            todel = qobject_cast<QLayout *>(o);
        if (todel)
            delete todel;
    }
}

Feel free email in suggested improvements

I’ve been writing software for others throughout my professional career to date, but this is about to change. I’m starting my own business, writing software aimed at academics.

I’m still working at CollabNet at the moment, however my hours there will be reducing over the next 6 months as I get my own software ready.

I’ve been with CVSDude/Codesion/CollabNet since it was just a few people, and having seen it grow to its current scale has given me a lot of experience that I think will help with starting something on my own. For example, I feel I know the importance of good customer support.

I’m really excited about this move, and I’ll certainly aim to blog any insights that are suitable for Developing Programmers (while maintaining my policy of not just blogging for the sake of blogging when I don’t have something new to say).

See you on the other side! I’ll publish more details as they become available and names are registered etc.

The company I work for (CVSDude which was renamed to Codesion) has now been aquired by CollabNet, creators of Subversion.

For me this is awesome news, and says the work I’ve been doing to get more people onto source control is paying off.

For my independence as a blogger, you’ll have to judge for yourself. If you look at the history here I hope you’ll agree that my message hasn’t changed, I’ve always recommended these tools! Only the company I work for has changed; and the change is completely in line with the message I’ve given all along.

There are several ways to think about software, and it can be useful to consider your software from a few different perspectives.

Object oriented designs can help keep you grounded in what real things your code is representing. Functional approaches (even just in a spec) can help you keep clear about a problem and it’s constraints.

Today I’d like to bring your attention to the perspective that software is a state machine.

In an object oriented program, you can fairly easily imagine member variables in a class as defining state, and methods as state transitions. This model works well in self contained programs. It gets a bit tricky when the state transitions have complex side effects or dependencies.

I’ve been working on large systems that share state across many diverse subsystems, often over a network. The system even manages the installation of other software, according to the state we keep in our database. So updating a partner website with an added user or installing software based on adding a project are examples of states having dependencies that need updating whenever the state changes.

What many people do is code these state based dependencies as “side effects” of state transitions. I can see why – they know what action they want performed and the state transition tells them when it needs to be performed. Easy.

But, this isn’t the most reliable approach. What happens if the network glitches? Or the third party system is down in that moment? You end up not pushing the current state to that system. Worse, if the system doesn’t notice and correct its error, the mismatched data propagates and can even become worse over time, triggering further errors because the dependency is not starting in the state you expect.

The solution is not very difficult.

Do your core state changes as usual, but for dependencies write a kind of “refresh” function instead. This should make as few assumptions about the dependent systems as possible.

In our example, our refresh functions take a look at the actual software installations and take whatever steps will make the installation match our database. If a server is down, we’re already ahead because the next state change will take a look and correct any missing installations. But it gets better. We now have a function that’s safe to call at ANY time, so we can trigger that ourselves if we fix a bug or a sever that was down comes back up.

One simple example of this is a web browser. It updates it’s display when you visit a new URL. But if anything goes wrong you can hit the “refresh” button and it’ll have another go at establishing the consequences of it’s current state (the URL field).

It’s not difficult but this simple principle can make your software a lot more robust. You just need to gear your methods around re-enforcing a state rather than focussing too much on the state transitions. I call this approach “strongly stated” software.

Well, this is actually a post about one of Steve Hayes’ posts, so the question isn’t “who am I?” but “who is he?”.

This post seems to describe a lot of good programmers, and is sounding to some developers I respect that it could, for the most part, describe any of them.

Thanks Korny for pointing it out.