differentpla.net

This is related to “Can you make a build in one step?” on The Joel Test. But it’s not the same.

Joel is asking whether a complete build can be made in a single step. By pressing one button, do I get an installer containing my latest release?

This is about ensuring that a new developer (or an existing developer at a new machine) can be productive as soon as possible. If it takes even an experienced developer all afternoon and a bunch of manual steps before they can start working with the code, you’ve got a problem.

Since your code signing certificate probably lasts for two years, you’ll have forgotten what to do with it when you receive your new one.

If you’re using Verisign, they’ll send you the certificate and key as two separate files named AcmeCertificate.spc and AcmePrivateKey.pvk (or similar).

One of the cool things you can do with the Microsoft Debugging Tools is set up a source server. This works by embedding source control details in your PDB files. Once you've published these to a symbol server, and set that up properly, you should be able to load a minidump file in Visual Studio (or WinDbg) and be taken to the correct line of the correct revision of the source file where the crash happened.

Which is pretty cool.

One of the many things that my former company, 1E, does well is its build and release process. That got me thinking: what makes a good build process?

The Joel Test touches on this in item #2 (Can you make a build in one step?) and item #3 (Do you make daily builds?), and – to a lesser extent – item #1 (Do you use source control?). But he doesn’t go into any detail about why...

I think that there are 4 goals to keep in mind when designing a build and release process:

I’m messing around with writing yet another a blog engine, as a way to learn ASP.NET MVC. One of the things that I’d like to do is have it support uploading from Windows Live Writer. This means that it needs to support XML-RPC and Really Simple Discovery (RSD). More on the XML-RPC stuff later.

When you use P4INDEX (or SSINDEX -System=P4), you might see "zero source files found". Check that your workspace doesn't have forward slashes in the name (e.g. D:/Source/depot/).

Why is this a problem? Well, P4INDEX runs p4 have ..., which returns, for example //depot/whatever/file.cpp#42 - D:/Source/depot\whatever\file.cpp.

The PDB contains files of the form D:\Source\depot\whatever\file.cpp. Note the backslashes. P4INDEX doesn't consider these equivalent, and so it can't get the revision details for the files named in the PDB.

The key used for signing your releases should be kept secure. It should be impossible for a rogue developer or 3rd party to use this key unofficially.

You should be pragmatic about this: You could keep the key in a secured location (e.g. on a computer that’s not connected to the network). Depending on your threat model, however, this might be overkill. It also adds overhead to your release process, including a manual step (and manual steps are often a bad thing).

This is just a minor rant:

In C++, const references are useful for parameters, because they avoid copying the arguments to a method. Non-const references, on the other hand, are pure evil, because there’s no way (at the call site) to immediately see that a method might change a variable:

These are the extensions that I have to install whenever I set up a new copy of Google Chrome.

NBehave depends on NUnit 2.5.2. To get it to work with NUnit 2.5.5, you can create an NBehave-Console.exe.config file containing the following: