Blog of Anders Rune Jensen » Programming

Programming nirvana part 2: be agile

Anders Rune Jensen — Wed, 13 Jan 2010 21:28:29 +0000

In part 1 I made the very brief argument that compiling sucks. I really like that cartoon since there is a lot of truth to it. Compiling sucks mainly because it breaks flow. There has been several tries to fix it by lowering the time it takes to compile but in the end, it’s still the same loop: write, compile, “debug”.

There is another layer to it as well, one that dynamic languages doesn’t necessarily imply: Developing a program should be having a running program that can be used while it is being written. This is one of the pillars of agile programming. Step one in achieving this goal is to separate the UI from the backend. Web is a natural way to do this.

Django comes very close to achieving this with it’s automatic reloading on change, but the biggest problem is that it’s not able to automatically migrate the most basic model changes. On the other hand Django has many other things going for it so it is by no means a bad choice. But there might be a better one lurking in the dark.

Programming nirvana part 1: avoid compilation

Anders Rune Jensen — Mon, 11 Jan 2010 19:53:03 +0000

I have been meaning to write about a new project I have been working on in my spare time for a while now. It’s a project where I wanted to maximize the fun I had doing it, learn something new and to do something that I can use. Sadly I have been putting it off since enumerating all the reasons feels like quite a daunting task. So instead of writing everything in one big blog post I’ll just do shorter posts. One for each argument. First one is pretty simple.

Profiling multithreading applications

Anders Rune Jensen — Fri, 25 Sep 2009 12:16:51 +0000

I’ve written about profiling before in the general case. But when it comes to multithreading, there are a few more factors to consider such as lock contention and cache invalidation that affect performance. And this is where mutrace (mutex profiler) comes into the picture. The profiler has a very low overhead compared (no perceived delay for me) to other solutions and gives quite nice results. I tested it on My Media System (C++) and Nemo (C#) and got interesting results for both. I knew more or less what the results for mms would be, but the results for Nemo was a bit suprising. The lock contention was significantly higher than for mms, even though I didn’t really use a multithreaded design for Nemo. So I guess it comes from the mono platform itself. Sadly it seems that mono programs aren’t compiled with -rdynamic, so the results that one gets are quite hard to decipher.