I’ve been working on a make script that extracts the files it needs to build from a Microsoft Visual Studio project file. The .vcxproj file format is XML so I imagined it would be easy to use a command line XML processor to do the job. However because the project file declares a default namespace this was not as easy as it first looked.
I’ve recently noticed that I frequently hold nonsensical ideas in my mind. Often these are pure contradictions. Merely attempting to describe these is enough to discover the problems. But there are also times where only the realisation of the ideas can break the illusion.
I found a link to an OSCON 2007 lecture on Haskell by one of its authors. It offers a good introduction to the language and an insight into its creation and development. The lecture also references a paper about the history of the language.
I’ve recently been watching the Structure and Interpretation of Computer Programs video lectures. These are a boon to the programming community. I wish my school had just used these videos rather than attempting to teach Lisp themselves.
I’ve long favoured self-documenting code over code comments. But I’ve recently reconsidered the issue. After years of dealing with self-documenting code I’m beginning to see problems. With hindsight I’m less sure that self-documenting code is always the best way to go.
I recently read a paper on confirmation bias: the tendency to focus on information that corroborates theories and dismiss information that contradicts them. It explained a general problem that I’ve noticed with many scientific studies (particularly in the field of software development) but I hadn’t been able to identify.
A post on one of the game developer newsgroups suggested that I got myself LinkedIn. It’s only when you do something like this that you realise just how many contacts you have in the business.
Reading an entry on James Bach’s blog reminded me of the best tester I ever worked with. It got me thinking about how he did it.
My recent study of the defects that slipped through reviews but were found during testing show an interesting pattern: they were almost all due to timing issues. Could a change of programming style reduce those errors?
Since reading about the PSP, I have continued to collect statistics. However, last week I decided to collect additional statistics related the the practice of reviewing code before compilation. The goal of this practice is to catch 100% of your compile errors before compilation by reading through the code. I was unsure about the wisdom of putting this responsibility on the programmer so I decided to gather some statistics to see if that doubt was justified.