phipster

Kevin Yank opins on the effect services like Google’s App Engine may have on web hosting choices. By abstracting away the details of configuring and deploying web apps for a particular host system, services like App Engine and Heroku may give developers more time to concentrate on providing business value (creating applications instead of fighting with servers). The greatest benefit may accrue to independent developers, students and hobby developers, who haven’t the time, money or server-fu to set up and administer their own dedicated server, virtual or otherwise.

Koen deWitters published an article on game loop design that should be of interest to anyone who designs software. He explains not only how to design a game loop, but why one technique is better than another, with simple, clear examples.

I’m taking COMP 2617 C++ for Object Oriented Software Development at BCIT, and using Microsoft Visual C++ 2008 Express Edition to do my homework. Pretty sweet little IDE, lots of Pro VS 2005 goodness for free!

But - why does the .ncb file (Intellisense parser database) for my dinky little C++ program, all of 160 lines in one 5Kb .cpp file, weigh in at over 2Mb?! According to Li Shao in this thread on the MSDN forum, “In VS2005, we have made change to remove this prebuilt ncb and dynamically parsed the files including the system headers into project ncb.”, in response to the original poster, who complained that “… an NCB file of 50KB under VS 2003 now has 500-600 KB, a 200 KB NCB under VS 2003 now has about 2 MB. And NCB files that used to have a size of 2-3MB now have 25-30 MB.” Sheesh! This is progress?

I use WinMerge a lot for general interactive file diff/merge/munging. It’s great, free, etc. But what I’d really like is a diff tool that a) lets *me* decide which bits in each buffer match up as the starting point, and b) let me compare two sections of the same file. Does this exist? Please let me know. Please.

On a recent project at work, developing a test automation system on top of TestComplete, we tried two ways to store machine-specific configuration data:

1. One file, shared by all installations, containing a section per machine
2. One file per machine

At first I had set up a single config file specific to my development PC. When my team mate Alan picked up on the idea, to put some machine-specific data on his system, he created a global config file containing a section per machine. His reasoned that one file, with some common and some machine-specific sections, was more efficient than a collection of files with high redundancy.

The config files contained data specific to each developer or test instance, such as usernames and passwords on the system under test. We needed this data in first place to prevent clashes between developers as we exercised the system.

What we ultimately settled on was separating the single global config file back into one-per-machine. Even though we were following good development practice by using a svn repository, so no-one’s edits would get lost or forgotten, we realized that once the project ramped up to 3 or 4 development machines, plus a couple of production servers, that config file would become a pumpkin.