Update: Are you looking for my old article about version control? It can be found here: Version Control: Why pessimistic locking of source code is a very bad idea

In the last weeks I have been thinking a lot about framework design. I will give a talk called “Framework Design Principles” at Mathema Campus. While preparing the slides I found out that when thinking about framework design, I care a lot about 5 topics:

This year at the Mathem Campus, I will give a talk about “Framework Design”. I will also host a day long scrum workshop together with Daniel Haslinger from Objectbay.

The scrum workshop, called “Hands-on scrum”, is something we never did before, but we are pretty sure it will be great fun for everybody. Also, there’s a lot to learn there. It will be really hands-on for everybody - we have only 6 slides, everything else will be done by the participants. I think there are still places left - contact Mathema (see link above) if you are interested.

Some time ago I wrote an article about how I dislike fancy job titles. I wrote there that often I call myself “software developer” or “programmer”. In the last few weeks I found some other articles about whether you should call yourself a programmer or not. For example, Patrick McKenzie writes Don’t call yourself a programmer. He argues that engineers are hired to create business value, not to program things:

In my series about how I work on my side projects, I already wrote about interaction design and software design. This post is about graphics design.

Knowing how to realize a given design in a piece of software is part of my job. I have picked up enough HTML, CSS and JavaScript in the past few years to be able to do that (but I still have a lot to learn). For me, the big question is: How do I get to a good design that I can realize in code afterwards?

This article is the last part of the “Side Projects” mini-series I started quite some time ago.

Last week I was working a lot on my side projects. I was at home for almost the whole week because I was sick. On the days where I felt better I coded. And after a few days I noticed: I take a break really often. Still I get more done than on an average day in my day job.

Update 2012-08-25: At the moment I am working on a somewhat related mini-series about Offline Web Applications.

I have disabled comments on this blog (again). Enabling them was an experiment, and it did now work as expected. There are very little useful comments, but lots of spam that get past the CAPTCHA. So, almost every day when I go through the approval queue I delete all the comments in there. This is not how I want this to work. I hope you all understand it.

This article is part of the “Side Projects” mini-series I started quite some time ago.

I am not sure if it was a good idea to include this topic in my original list because I don’t do much formal software design when working on a fun project. Again, I do things completely different when working for a client, where I am part of a team and everybody has to understand the design. But in this case there’s only me. When designing some part of the system I usually do the following:

This article is part of the “Side Projects” mini-series I started quite some time ago.

As everything I do for my side projects, I keep interaction design as simple as possible and try to do the absolute minimum possible. I really only perform two steps:

Now that I’m back from my honeymoon and christmas is over it’s time to think about next year. I have some ideas and plan to do some (hopefully) interesting things. Of course I’ll blog about them, so stay tuned - I plan to return to a weekly posting schedule in January.