Older blog entries for Judas (starting at number 14)

Read this on slashdot today. Although its bloody obvious stuff anyone nods when they hear, lately I've come across people that just learned .net and seem to think its the holy grail, replacing and beating any other system in every possible way.

So therefore, everyone repeat after Angst Badger (the guy on slashdot who wrote the obvious):

Until you understand the weaknesses as well as the strengths of your favorite language, you either haven't explored it fully or you don't know enough languages well enough to have a basis for comparison. (C|C++|Java|Perl|AWK|Python|COBOL|RPG|Fortran|BASI C|PHP|Forth|6502 Assembly|Forth) all suck if you're only looking at their flaws, and they all rock if you're only looking at their strengths. If you're not looking at both, you're not getting it.

Just read starch's Jul 2003 diary post (yeah we post seldomly here, hehe) about the problems of project management.

An interesting observation: If estimating the time it takes to complete a feature or prioritizing the right features to create is so important, why is it usually the coders that have trouble abstracting and designing things that ends up getting those positions? At least so it seems to me.

Part of the answer to the above problem is that there are generally two types of coders in this world: those good at it, and those not good at it. :) Those less good at thinking abstract and handling complex things, they often tend to try instead reach to management positions. Yes, there are probably exceptions, and yes I'm probably over generalizing here, but I seem to notice a pattern. :)

But anyways, thats not really what I wanted to write about. :)

The trick to good professional project management, avoiding feature-creep and keeping deadlines is having the right tools. And its probably the thing that is most tricky to get people to use. And the list of tools you could choose between is long.

Three things you need:

1. Good quality version control system.

By this I don't mean just installing your favorite version control system (ie CVS). No I'm talking about using these tools as they are intended to be used: do version control.

Version control doesnt mean "we can share files, I change things and commit, my coworkers change things and commit". No it means having a standardized structured system to keep track of all your different projects that involve changing the code base.

Lets say you got 4 bug reports and 7 feature requests. You should be able to individually develop on all those 11 issues at the same time. And not until a test has confirmed that the issue indeed is resolved should it be allowed into the main trunk.

The version control system should also keep track of all previously released versions, so you at any given time is able to go back and work or test from that version forward. This means tagging and keeping built executables around for each release.

The point of all this is to allow management to change their idea when they figure out that a cookie is sour, that they would rather prioritize another issue over the current one you are working, and punt issues to later scheduled releases.

Featurecreep can only be solved by making it obvious to the management what the time is spent on in the development department.

2. Issue (feature/bug) database.

This is a tool very important for the management. To be able to prioritize things correctly, it must be appearent and clearly visible what things are pending to be addressed. A issue database will do this for you.

Ideally the issue database and the version control system should be linked together, so that the versions available in the VCS is illustrating what issues there are open and closed in the issue database.

3. Automated build system.

There exist many tools for doing this; one I can recommend is Visual Build. Basically this is a way to setup scripts to hit the "F7" button or whatever is needed to build your product.

Automating this process is important to make it more easy for project managers, testers and coders to work on all the different issues in the system. Most version control systems are a bitch to use if you insist on doing it all manually, so its really a nice thing to have things just working nicely using a few scripts on an intranet server; or doing nightly builds or whatever.

Ok think I've written enough for now. :)

Today fabio wanted to play a multiplayer clanlib game with dark as server.

Couldn't show him any.

Ok, bored again. So why not update my advogato profile? :)

I noticed another guy rated me master here at advogato, thanks for the support. :) Next one that comes along thinking I deserve such a vote, please place it on sphair instead - he deserve as much credit as I when it comes to clanlib development.

Been playing around with Nokia's new java enabled mobile phones. Wrote a small IRC client that used GPRS to stay online on irc - ended up crashing both the emulator and the JVM running on the phone - so much for nokia QA. But it looked cool to see my phone connect to IRC, join a channel and display everything ppl wrote, only paying MB transfer prices. :) Its going to rock when nokia sort out those damn bugs - so maybe in next generation phones it will really allow you to do awesome stuff with your phone.

Oh oh, months have passed again.. :)

It is summer and in denmark, that means you are expected to take three weeks of holiday. People frequently ask me when I'm going have mine, and I really don't know what to say. I really dont feel up for doing anything these days, so using three weeks doing nothing seem like a total waste.

Its as if I've simply run completely out of inspiration.

If I really wanted to, I could finish up ClanLib-0.7's display part up in a weeks time, but there's no motivation to do so. Sure there are people that would like to have it to play with, but it more feels like work than a hobby for me.

I got the same problem at work. There are lots of stuff I could finish up fairly easilly, but it seems like it will bring me nowhere if I do, so why bother? Been wondering if I should quit because of that, or if I will just be trying to fix the symptons instead of the real cause of it.

I've lost the ability to dream. :|

I have come to learn today that Harry have great plans on how to take over the world.

Months have passed - better update my advogato page. :)

Things are progressing well with ClanLib. clanDisplay2 is reaching a state where it can be used to create real games - my Pacman game has already been ported. Its not feature complete, but it gives an idea of what direction I'd like the new display component of ClanLib to end up.

I recently read an article called It's STILL loading? from the Game Development Conference (GDC). Normally I'm way too lazy to read these kind of articles, but lately sphair have been complaining about ClanLib being slow at loading resources. So I decided to give it a try and see if there was something interesting in the article that wasn't just plain obvious. :)

Unfortantly the article doesn't really do a good job at focusing on a specific topic. It uses most of the text on explaining why having things as a package (datafile) is better than as raw files, how files should be modified while game is still running, and all kinds of similar abstract ideas.

Its a lot of claims without numbers. For instance, the article mentions how opening stuff from your own home-made datafile index hash table is quicker than opening files using the operating system - and of course it can be faster. But how much faster? How many resources do you need before it becomes a real issue anyway? He mentions how many resources a whole game contains - but thats not really fair, since they aren't all loaded simultaneously.

Its not like I dont think all those things wouldn't be cool to have in a resource system - its more a question if its worth the efford. I could imagine that its far more important if the individual resource loaders are fast - and he does mention converting common formats to game specific formats, but its not what the article is focusing on.

The article also touches the concept of loading stuff using mmap, and even mentions how the emulation layer of mmap in Windows 9x totally sucks. But again, there are no numbers, so its hard to tell if memory mapping a resource will give a 10% boost, a 50% boost or triple the loading speed. He obviously gave it a little thought, since his API allows resources to be specified as random accessed, block or streamed. Just need some numbers to know if its worth the efford. :)

My point here is that it could just as well be smart resource loaders/savers that make his games load fast, as much as its the file system structure itself. Its probably a combination, but its pure guessing until you got that profiling of the system. :)

Yes, so it is christmas... what a lovely time of the year, right mstarch? ;-)

(Whom am I kidding? I bloody hate christmas. I hate the fact that everyone seem to be having a great time, except me...)

Ermn... never mind that little rambling, talking about christmas gets me sidetracked. :) What I really wanted to comment in my diary today, is mstarch's little comment about we building railroad tracks:

Yes, I suppose you're right to a certain extent. But dont worry, there is still a long time to anything remotely like that will happen. It may seem like even Microsoft are having a hard time figuring out what to add to their operating system these days. Been running with WinXP here for a week now alomst, and yet, I've not seen one single really good reason to upgrade from Win2k. All that seem to be new in WinXP, besides minors like faster booting and other finetuning, is bundling of misc. new markets Microsoft desire to capture (eg. the IM market).

Hardware companies like Intel also seem somewhat screwed these days. It doesn't make much of a difference wether you have a 1 ghz machine or a 2 ghz machine. Both are 'fast enough', just like Windows 2000 is 'good enough' as an operating system (at least for the most common tasks).

So does this mean we're at the end of the railroad? That we've built every track worth building? No, luckily not. The problem for Intel, as well as for Microsoft's OS department, is that our hardware and OS is more than good enough for the classic 'office' usage. But it is still not fast enough for really bandwidth requiring things - eg. television over internet. We may embrace how gigantic our discs are these days, but think about it, how big are they really, if we want to store DVDs on them? Our ADSL is pretty pathetic if you try to stream live video in DVD quality, not to mention the bandwidth required for the server, if only 100 people were watching it.

You also do not have to worry too much about productivity tools getting completely done. While the basic packages might end up like that (eg. the Office package. I'd settle for a Office 95. It more than covers all my needs), you'll always see management screw up. See them spend tons of money on some AMANDA project, just to realize it will not do. Or the system might actually work just fine, but then management changes their mind on how everything should be structured, and the system renders useless.

But... let's assume I'm wrong. Then there will always be one thing left to code, that will render old and useless over and over again: games. :)

So why not turn this fear into an advantage? Start coding on ClanLib again! :)) Lets make ourselves famous and known in the gaming industry, so when the mass layoffs of coders start, we can quickly plant our boots in some game company, where code never grows old. :)

(Sorry, couldn't resist the temptation... hehehe)

Hmm, its been a long long time since I posted a diary entry here. I probably wouldnt have done so again, if it wasnt because I'm pretty much dead bored, and nobody seemed to comment on my latest overview stuff, so this seemed like the best 'waste my time' thing I could do right now. :]

As people following clanlib development close might have noticed, I've been mostly working on writing a completely new version of the networking classes in clanlib. I'm rather proud at how nice they have formed to be, and I really think its a huge improvement over the previous networking stuff.

In fact, I'm pretty excited these days about how all of clanlib is shaping up. There was a very long period of time where the only reason I even coded at clanlib at all, was because I had managed to get a userbase (althoguh somewaht limited) and felt that I shouldnt cancel the project, only because then it would hurt those projects.

The cool thing about clanlib these days is, that a lot of the core APIs are beginning to be feature complete and cleaned up enough for my early clanlib design faults. ClanCore is pretty solid, despite the I/O Data stuff is a bit too primitive, and our string class could be far better than it is.

ClanGUI is shaping up really nicely. It was a pleasure to experience at work, how I'd rather have clanGUI in certain situations than Qt's GUI library. Not generally, Qt is far more maturized than clanGUI, but there was places where I missed clanGUI specific features. :)

With the new networking API almost ready, and with a new display API on the drawing board and even half way implemented, it really looks like ClanLib is almost going to become what I originally dreamt it to be: A nice and feature complete game SDK.

So if you had been wondering why I've been so active on ClanLib lately, then its because I have started to believe that I can fix the flaws in ClanLib and make it an attractive SDK that I might even want to use myself. :)

I just want to say that I totally agree with Starch. I too hate hardware. :)

PS. Thank You for removing that butt-ugly background image from your homepage Starch. Now also please remove the butt- ugly text :P