Some of my more noteworthy contributions around the Mercurial eco-system during the sprint were:

• Release RepoMan, the repository forest manager that we have developed at Edlund A/S for managing a complex multi-repository setup where some modules are individually co-dependent but we want to be able to modify all of them coherently at the same time. We’re hoping that other people out there will find it useful and/or interesting.
• Proof-of-concept, hg-deadkeys, written with Martin Geisler from Aragost Trifork, which is an extension for marking changesets ‘dead’ (which includes a slightly hacky misuse of the phases concept) so they aren’t propagated across the client/server boundary – requires that the extension is enabled on both client and server. Eventually this should be able to garbage collect changesets (e.g. strip them) that the user considers permanently dead.
• Bit more polished proof-of-concept, hg-multiundo, written with Jason F. Harris, for supporting automatical snapshot-based backups of your repository and working copy state whenever you modify files. The extension allows you to undo/redo in multiple levels the last things you have done in the repository. No more ‘Oh no, I did hg up -C and now all my changes are gone!’ – they’re just an ‘hg undo’ away. Disk space performance improvements will probably be introduced later on.

Apart from that we had a lot of good discussions on the project and things around it. I’m looking forward to the next sprint.

A principal thing to remember here is that Mercurial will not work as a complete server out of the box, requesting authentication information, in the form of basic, digest, or certificates, at all. This means that in order to use X.509 certificates with Mercurial, one needs to place a web server that knows of these authentication mechanisms in front of it.

This guide is written at the existence of Mercurial version 1.5.1 and touches on many newer features, so if your distribution is old or lacks these features, perhaps it’s time to upgrade to the latest and greatest.

X.509 certificates and SSL/TLS

The most commonly known aspect of X.509 are the certificates. At some level, one can think of a X.509 certificate as having a public and a private key. The public key is the one that secure websites present to you when you, for instance, visit Gmail. You can encrypt data to the intended recipient using this key and only with the corresponding private key can this information be decrypted. In reality, the actual public/private key pair is only used to compute a shared secret, and this is the secret used to communicate securely for the remainder of the conversation.

A X.509 certificate is issued by a certificate authority—some of the commonly known certificate authorities, i.e. that are trusted by a lot of people, can be seen in your browser’s certificate settings—however, a certificate authority can be anybody you trust, e.g. yourself. This certificate authority can then issue server certificates (that represent a server’s identity), and client certificates (that represent a client’s identity). As long as you control the ecosystem of your environment, e.g. you know who your clients are, they know who you are, there is no reason to give out money to some third-party certificate authority, you can accomplish everything you need to on your own.

In order to become your own certificate authority and certificate issuer, you need one of two tools: OpenSSL or makecert.exe, the latter only being available on Windows (there are probably countless other tools as well, to be fair, but I do not cover them here). Below I will cover how to use each of these to set up everything, but before we delve into the details, we will look very briefly at what a certificate authority certificate is, and what ‘normal’ certificates are.

Certificate authority: A certificate authority is basically just a certificate that has signed itself. If you trust this certificate’s public key, you will also trust any certificate that has been issued by this certificate authority.

Normal certificates: A normal certificate is just a certificate that has been signed by a certificate authority (or in reality a certificate authority or an intermediate certificate—you can have a full chain of certificates signing each other if needed).

Now, there are a lot of weird details in these certificates. You may hear terms thrown around such as OU (Organisational Units) and whatnot. The only important part for our purposes is the CN (Common Name). This is the name of the certificate holder, e.g. the server’s name, or the user’s name. So if you access your server as ‘hg.my.cool.server’, your server certificate’s CN must be ‘hg.my.cool.server’.

OpenSSL

Like everything else in the X.509 certificate landscape, OpenSSL has a lot of options, switches and strange voodoo attached to it. Lest this post be turned into a really boring tutorial on certificates, I will just give a few very cursory examples of how you can generate the different certificates. There are plenty of different tutorials on this topic already. Note that Microsoft’s IIS is a tad weird in how exactly it requires the certificate to be constructed, so we will not cover this for OpenSSL, but only for makecert.exe (inquiring minds can figure out all the details of generating certificate requests and processing these in OpenSSL if they prefer).

• Certificate authority: openssl req -x509 -nodes -days 365 -subj '/CN=MyCA' -newkey rsa:1024 -keyout ca.key -out ca.pem

  The ‘MyCA’ part specifies the name of your certificate authority, so you will probably want to name it something a bit more descriptive.

  This gives us a certificate authority certificate with a private key stored in ca.key and the public certificate in ca.pem. You will need both of these to issue other certificates. Also, if you do not want to get scary pop-ups with invalid certificate trust models in your browser when you browse the hg repositories through hgweb, you will need to install ca.pem into the trusted root certificate authorities in your browsers.

• Normal certificates:

  • Generate request for signing: openssl req -new -nodes -out name-req.pem -keyout name.key -subj '/CN=name'

    You should, of course, replace name with something more sensible, e.g. your server’s fully qualified domain name (the one people will be entering in their browser to visit it).

  • Signing the request: openssl x509 -req -in name-req.pem -CA ca.pem -CAkey ca.key -out name.pem -CAcreateserial

  Do note that this is the quick-and-dirty way of generating certificates for use in testing/simpler controlled production scenarios. There are a lot more advanced features (like openssl ca) that will allow you to act more like a real certificate authority. If you need these things, go look up some OpenSSL tutorials, then come back here to see how things work with Mercurial.

  The final issue is getting these certificates into a form that your browser will like. They require the certificate to be in a special format, e.g. PKCS#12. To get that we use the openssl tool again like this: openssl pkcs12 -export -in name.pem -inkey name.key -out name.pfx. This file can be imported into your browser in a fitting place.

makecert.exe

makecert.exe is a bit of a different beast from openssl as it interfaces directly with the machine’s or user’s certificate store (the special place where certificates live a happy life in Windows).

• Certificate authority: makecert.exe -pe -r -ss My -m 12 -n "CN=MyCA"

  This will install the root certificate into the current user’s personal certificate store and mark the private key exportable. To see the current user’s certificate store, run certmgr.msc.

  The certificate’s public key will need to be exported and subsequently imported into the ‘Trusted Root Certification Authorities’ on each machine that trusts this certificate to issue other certificates.

• Server certificate: makecert.exe -pe -is My -in "MyCA" -n "CN=name" -sky exchange -ss My -sr LocalMachine -m 12 -eku 1.3.6.1.5.5.7.3.1 -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

  Do note that this certificate is imported into the local machine’s personal certificate store—this is where IIS expects to find server certificates. To see these certificates, start mmc manually and add the certificate snap-in.

• Client certificate: makecert.exe -pe -is My -in "MyCA" -n "CN=name" -sky exchange -ss My -m 12 -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

If the client and server certificates aren’t generated on the machines you need them on, you need to select the certificate in the management snap-in and export it, including the private key. Exporting as PKCS#12 is usually the safest bet.

This should basically cover how we get the actual certificates. Now, to use them.

Configuring a web server to use certificates

There are countless web servers and operating systems to run them on. I will give a very brief guide to running it on two of the most archetypical web server/operating system combinations: Apache 2.2 on Linux (Ubuntu), and IIS7 on Windows Server 2008. In particular, I will assume that you have already got Mercurial running and working just fine on both web servers.

Apache 2.2 on Linux (Ubuntu)

Setting up apache with mod_ssl can be done in a multitude of ways, I’ll just presume you have enabled mod_ssl already and show how to create a really, really skeleton version of a SSL site that serves Mercurial repositories. We will set up a server that serves a few Mercurial repositories using hgwebdir, from the root of the website, and we’ll only define a virtual host for listening on port 443.

Server certificates

The main configuration is as follows:

<VirtualHost *:443>
  SSLEngine on
  SSLCertificateFile /path/to/myserver.pem
  SSLCertificateKeyFile /path/to/myserver.key
  SSLCACertificateFile /path/to/ca.pem
  SSLCACertificatePath /path/to

  ScriptAliasMatch ^(.*) /path/to/hgwebdir.cgi$1
</VirtualHost>

Do note that if you have cloned the Mercurial repository, you should copy hgwebdir.cgi to a different location and make it executable. Furthermore, see HgWebDirStepByStep for further instructions.

This simple solution serves our self-issued server certificate when we access our website using TLS/SSL.

Client certificates

Client certificates do not require much more than that:

<VirtualHost *:443>
  SSLEngine on
  SSLCertificateFile /path/to/myserver.pem
  SSLCertificateKeyFile /path/to/myserver.key
  SSLCACertificateFile /path/to/ca.pem
  SSLCACertificatePath /path/to
  SSLVerifyClient require

  ScriptAliasMatch ^(.*) /path/to/hgwebdir.cgi$1
</VirtualHost>

This allows anyone with a validating certificate to connect, but no other checks are made. In order to restrict which certificates can be used to connect to the server, we can use the built-in fake authentication mechanism of mod_ssl’s.

<VirtualHost *:443>
  SSLEngine on
  SSLCertificateFile /path/to/myserver.pem
  SSLCertificateKeyFile /path/to/myserver.key
  SSLCACertificateFile /path/to/ca.pem
  SSLCACertificatePath /path/to
  SSLVerifyClient require

  <Location />
    SSLRequireSSL
    SSLOptions +FakeBasicAuth
    AuthName "FakeBasicAuth"
    AuthType Basic
    AuthUserFile /path/to/httpd.passwd
    require valid-user
  </Location>

  ScriptAliasMatch ^(.*) /path/to/hgwebdir.cgi$1
</VirtualHost>

The fake basic auth basically means that we will create a file, httpd.passwd that contains the certificate subjects as usernames and password in its hashed form as password. Then mod_ssl takes care of verifying that the certificate is in this file before allowing it to access the remote location. To get the certificate subject to use as username, you can use openssl to get it: openssl x509 -subject -in name.pem. So for our simple client certificate example above, we would have a httpd.passwd file with the following contents:

/CN=name:xxj31ZMTZzkVA

The xxj31ZMTZzkVA part is password that has been hashed. Usually, if you’ve bought your certificate from a real certificate authority, your certificate will also contain country, organisation, and a host of other fancy things. You can also get these by embellishing the subject when you generate the certificate request, thus a real ‘username’ for a certificate might be /C=US/O=My fancy company/OU=West coast offices/CN=John Doe, but for our simple explanation purposes they merely detract from the message.

This is all it takes to set up client certificate authentication and authorization on Apache.

Internet Information Server 7 (Windows Server 2008)

Server certificates

The server certificate part is easy. Make sure the certificate is installed in the local machine’s personal certificate store, then add a HTTPS-binding to the site you want to host and select the relevant certificate in the drop-down list. That’s it.

Client certificates

Under SSL settings, set that the site requires SSL and that client certificates are required (few systems really work well with the optional part). This is the easy part. The hard part is that after IIS6, Microsoft has decided to drop the interface management UI for mapping certificates to Windows accounts completely, so we will have to do all this in an XML configuration file, and change some system XML-files and whatnot to get everything working.

The first file we need to edit is %SystemRoot%\system32\inetsrv\config\applicationHost.config where we need to find a line like this: <section name="iisClientCertificateMappingAuthentication" overrideModeDefault="Deny"> and change the Deny to Allow. This will allow us to configure this setting in the root of each website that your server is hosting. (If you have users who have write access to the file system, then they will also be able to override the setting for their virtual directories; it is up to you to figure out whether this poses a security risk for you).

In the root directory of your website, edit (or create) the file web.config that we can use to configure IIS7 (and ASP.NET for that matter, but that’s probably not terribly relevant here). For each user we want to grant access we want the certificate’s public key in PEM-encoded format (that is Base-64 in Microsoft parlance), formatted as a single string (i.e., you remove the newlines from the text-file and copy-paste the contents of the certificate, excluding the first and last line with the dashes). Below is a brief snippet that illustrates this:

<?xml version="1.0"?>
<configuration>
  <system.webServer>
    <security>
      <authentication>
        <iisClientCertificateMappingAuthentication enabled="true"
            oneToOneCertificateMappingsEnabled="true">
          <oneToOneMappings>
            <add userName="testuser1" password="test" certificate="CERTIFICATE_STRING" />
          </oneToOneMappings>
        </iisClientCertificateMappingAuthentication>
      </authentication>
    </security>
  </system.webServer>
</configuration>

Now we have told IIS that the user with the certificate CERTIFICATE_STRING logs in as the user testuser1 using the password test. However, even though we’ve set the website to require the use of client certificates, anyone presenting an arbitrary certificate can log in, since anonymous access is enabled. To turn this off, and only allow access for the specified users in the authentication section, we will need to modify the authorization rules as well as the authentication rules to disallow anonymous users. Below the /authentication line in the above configuration we add the following:

<authorization>
  <remove users="*" roles="" verbs="" />
  <add accessType="Allow" users="testuser1" />
</authorization>

Unlike the certificate mapping, this can also be handled from inside the IIS configuration manager under authorization. Now, only testuser1 can log on to the site, using his client certificate. In general, you probably want some more users to be able to access your site, so you can go right ahead and add those as well.

Mercurial and X.509 certificates

All this, finally, brings us to how Mercurial interacts with certificates. There are, indeed, several things we need to cover here: how to use server certificates with ‘hg serve’ (the built-in web server), accessing a web server that requires client certificates from the Mercurial client, and how we can use the usual access control methods in Mercurial together with client certificates.

The built-in server, hg serve

Note: For hg serve to use SSL, you must have installed pyopenssl.

hg serve supports a --certificate option where you can specify a certificate file for a certificate that verifies. This detail is important, as right now, with the commands we issued above, we have a certificate file, we have a certificate authority file, and we have a private key file. We need to combine all these into a single file with this command: cat name.key name.pem ca.pem > hgserver.pem. If you have a certificate from a known certificate authority, you do not need to combine the certificate authority certificate into your certificate file.

To use this, you now simply just write hg serve --certificate hgserver.pem and you can access your stand-alone server using HTTPS.

Accessing a web server that requires client certificates

This is, of course, the really interesting part where everything comes together. In order to use client certificates you need them split up into two different files: name.pem and name.key (if you have followed the guide above for OpenSSL, you already have these two files, otherwise you need to generate them). Now we need to set up an auth section in our local hgrc file:

[auth]
something.prefix = my.server.tld
something.cert = name.pem
something.key = name.key

When you try to clone, push, pull, incoming, outgoing to my.server.tld (or any path below that), we will automatically send along the specified certificate file and decrypt stuff using the key file. Also note that the something can really be anything, as long as they are connected. That is, if you have two different client certificates for two different servers you could do something like this:

[auth]
something.prefix = my.server.tld
something.cert = name.pem
something.key = name.key

somethingelse.prefix = my.other.server.tld
somethingelse.cert = othername.pem
somethingelse.key = othername.key

Be aware that the paths to the certificate and keyfile should be absolute (otherwise they’re read relative to your current working directory).

There is currently no way to discern that certificates are included in the request or not (other than the request possibly failing). Also, the error messages that are given back if there are problems with certificates are less than stellar, but that is, unfortunately, the par for OpenSSL (which Mercurial uses by way of Python).

Access control using certificate users

Mercurial contains a number of mechanisms for controlling who can read/push from/to a specific repository. Furthermore, there are extensions such as the acl extension that allows you more fine-grained access control on who may push what files. The usernames that you can specify are delimited with either a space or a comma. See the problem?

A very common certificate username for Apache might be ‘/C=US/S=CA/O=ACME, Inc./OU=Coyote Solutions/CN=John Doe’. This will be parsed as allowing/denying access to the users ‘/C=US/S=CA/O=ACME’, ‘Inc./OU=Coyote’, ‘Solutions/CN=John’, and ‘Doe’. In short, you cannot use these mechanisms with Apache and client certificates right now (this should, of course, be rectified in the Mercurial source code somehow).

With IIS we have no such problem as we have mapped the client certificates to actual Windows account names, and we must just limit based on the Windows account names.

Verifying the server identity

The default for Mercurial (or any Python application for that matter), is to connect to a SSL/TLS server and not check that we actually trust the certificate being served. In fact, it is only possible to make Python do this from Python 2.6 and onward, and only if you specify special flags and special files to some of the SSL/TLS calls. Some kind developer who shall remain unnamed has added the necessary support to Mercurial so that we from Python 2.6 can actually verify the remote party. This is done by specifying a certificate trust file in your hgrc file in the web section:

[web]
cacerts = /path/to/cacerts.pem

This file should contain a list of the certificate authority certificates (PEM encoded), one after the other. If you’re already on a system that has OpenSSL installed, e.g. most GNU/Linux systems, this can be found in the file /etc/ssl/certs/ca-certificates.crt (or wherever your distribution places it). If not, then you will have to construct this file manually.

If verification fails, you will, again, get some cryptic OpenSSL error message.

Conclusion/Summary

These are all the many fancy ways that Mercurial can work together with certificates currently. Some of the ways are cumbersome, but they are hopefully not cumbersome due to Mercurial. We have tried to make them as easy to use as possible (if it can be said that certificates are easy to work with). It is also worth noting that prior to Python 2.6.4 (I believe), it is not possible to use client certificates with Mercurial, if you are also using a HTTP proxy server.

I will try to update this post if/when changes occur to the client and server certificate support in Mercurial. If you have suggestions or issues with using these, please file them on the Mercurial issue tracker, thanks!

Update: Thanks to Claudio for some useful comments and corrections.

• Strike a cordial tone and do not tell people they do not understand the code.
  Doing this repeatedly to frequent contributors is even more silly.
• Do not ignore contributions.
  It’s ok if you are busy, but indicate that by replying to the patch, do not ignore it completely.
• If someone takes the time to go over your bug tracker and fix multiple issues, do not ignore the patches.
  See above.
• If someone tells you that there are issues in your use of transactions, do consider it an option.
  Transactional safety is hard, it’s likely that details might have been overlooked.
• Find a decent working process for reviewing contributions.
  Requiring contributors to bug you until you magnanimously take a look at the contributions gets very tiresome quickly and lessens the odds that said contributor will keep contributing.
• Give constructive feedback.
  Stating ‘This sucks, but I don’t have time to explain right now.’ helps no-one but your own ego. A better approach, in case you really do not have the time, would be to write, ‘I have some concerns over the implementation that I would like to voice. I am, however, travelling for the remainder of the week and will try to reply early next week’.

That is all.

The basic principles of object-oriented languages builds on what in type theory is known as subtyping relationships that are typically expressed σ <: τ, meaning that σ is a subtype of τ. Or expressed in a typical C# manner:

public class τ {}

public class σ : τ {}

So in other words, we have the property that σ inherits from τ, or that σ is a subtype of τ. It is typical of most object-oriented programs (sorry, most well-written object-oriented programs) to allow you to use the type σ in place of the type τ anywhere in the program and still have a correct program. This is what is typically called Liskov’s substitution principle, which can be formulated like this: x : τ ⊢ q(x) ∧ σ <: τ ⇒ y : σ ⊢ q(y). So that is fairly densely looking and what does it really mean? Basically it says: if q(x) is some property that holds on an object x of type τ and if σ is a subtype of τ then if y is an object of type σ then q(y) must also hold. Or in layman’s terms: it must be possible to use a child class instance everywhere a child’s class ancestor is expected, without changes to the program, maintaining correctness of the program. So that is probably a pretty good property to go looking for.

Now, before everything gets lost in theory, let us take a look at the actual problem in C#, using an illustrating example:

public abstract class RandomNumberGenerator {
  public abstract double NextValue();
}

public class DiceResultGenerator : RandomNumberGenerator {
  public DiceResultGenerator(int rolls, int sides) {
    rolls_ = rolls;
    sides_ = sides;
  }

  override public double NextValue() {
    ...
  }

  private int rolls_, sides_;
}

Okay, so this code is a sensible implementation of some random number generator and a dice roller… or is it? When was the last time you got floating point results from rolling a die? Let us fix that up right here and now by changing the double in the DiceResultGenerator to an int. This is a safe operation since int <: double (and because Liskov’s substitution principle otherwise applies here—every time you expect a double you can safely use an int in its place). Ignoring floating point representations and byte sizes this typically holds in most object-oriented languages since the integers are contained in the real numbers. So what happens if we compile the modified source code with the Mono C# compiler (the Microsoft one will give a comparable result)?

`DiceResultGenerator.NextValue()': return type must be `double' to match overridden member `RandomNumberGenerator.NextValue()'

Bummer, we have not got covariance in method return types. This means that whenever we use a DiceResultGenerator, we must get a double out of it, rather than a int, and we will subsequently have to cast it to an int. All this just because the DiceResultGenerator is part of a sensible inheritance hierarchy for different means to obtain random numbers and that most random numbers are floating point values. That is just plain depressing.

So this is exactly what a covariant return type is: when a child class wants to return a subtype of what the overridden function of the ancestor class returns. And it does not work in C#. Of course, it works in C++, but there are so many other things that annoy me with that language.

C# why did you let me down so?! Oh well, it must be time to find the next language I might actually like.

Edit: Astute readers found out that I had switched the subtype relation around in the definition of Liskov’s substitution principle. Sorry.

The plugin I have created is for controlling Winamp from X-Chat 2. Normal plugins for X-Chat 2 are made in C, but I have made a plugin in C++. The source code will illustrate both how to integrate with X-Chat 2 and Winamp using C++.

The plugin will not auto-display what you’re listening to whenever a song in winamp changes, since I find that annoying. In fact this plugin will do nothing at all unless you ask it to. The plugin’s functionality is bound to the WIA command, so to see the help for this thing, just go /help wia. The rest should be fairly self-evident.

I have only tested it on the alternate build I’ve listed above. If it does not work on other builds then try to compile the source on your own. I will not help you with problems with the source, compiling it, your social problems or anything else even remotely related to my X-Chat 2 plugin for controlling Winamp. (You get to figure out how your social problems may or may not be related to that on your own). The plugin is released under the GPL and standard disclaimers are in effect and all that stuff that keeps kind people from sucking (sorry, suing) every last penny out of me. (Not that we have pennies here, but figuratively speaking).

I hope someone, somewhere, sometime, might have some use for this. I haven’t added it to the official plugin repository for a reason. Please, don’t post my plugin there.

Binary files (.zip) – 31.4 kB
Source files (.zip) – 26.8 kB

Of course, prior to this I have already modified web.config to up the max request length like this:

<httpRuntime maxRequestLength="40000" />

So why is it refusing files with an error 400 as soon as they go beyond about 4096KB? Well, it’s obvious, WSE has a built in limit that you must change as well! (In case my sarcasm isn’t showing, it was there. Trust me.)

<microsoft.web.services2>
  <messaging>
    <maxRequestLength>1024</maxRequestLength>

  </messaging>
</microsoft.web.services2>

This example is taken directly from the WSE documentation for the maxRequestLength. Also, you must remember to add the configuration section extension definition for WSE as well – see the documentation link for how to do this.

Of course, the story doesn’t end here. That would be too easy, because the file upload still has a tendency to fail. Hmm. What if we try to sync the value between httpRuntime’s maxRequestLength and WSE2′s maxRequestLength? Bonus! So, knowing that these two have to be identical for everything to go well it seems a bit… ridiculous to have to require the WSE2 field instead of WSE2 just using the httpRuntime value for the maximum request length. I’m sure there’s a brilliant reason for not doing this, however, that someone at Microsoft may know, but one could at least have it be equal to httpRuntime’s maxRequestLength, no? pretty please? Ah well. I’m sure I’m not the last to run into this problem.

So, now we have taken care of large attachments. Let’s add a bit of security so we can safely validate the sender of these large attachments. Stage left enter X.509 and SSL certificates. Stage right enter more troubles, a lot more troubles. So let’s look at a fresh start of IIS and the client, let’s upload a big file, let’s say 20 MB: 413: Request Entity too Large. I will have to be frank, this surprised me. How can the request be too large on HTTPS with client certificates when it isn’t too large on HTTPS without client certificates or on HTTP?

My science background teaches me to experiment in this case, so let’s try it first with a small attachment, say 4 KB, and then let’s try it with a big attachment, say 20 MB: 200 OK. Hmm. Not only does this seem to indicate a bug in IIS6 (which was the IIS I was working against), but it seems to indicate that there is some non-trivial state sharing going on between disparate connects from the same client. Unfortunately I haven’t had time to work more on this problem, but if I ever get around to fixing it I’ll make an update about it. For now I have just created a system that takes a temporary “session” variable that is fetched using a certificate call and then the file is uploading using this without certificate. Seems to work.

Gotta love obvious, transparent technology.

LINQ correspond to Haskell’s monad comprehensions, in case you know what those are, and I think it will be interesting to see how people put it to use, but I could fear that it will create a tendency to put even more data-layer specific code into the business aspects of application. The added expressitivity, however, seems like a great thing and I look forward to play with it.

Meijer also presented a couple of the new things coming in VB9, among these is late-late binding, which allows you to try to access fields on a type Object regardless of whether you know they exist at compile-time or not, so in some sense VB9 is now a complete bastardisation between statically and dynamically typed languages and you get to be able to do some truly nasty things:

  Dim z As Object = {Name := "Test", ID := 20}
  Console.WriteLine(z.(Console.ReadLine()))

This allows you to specify the field in the anonymous struct to access at runtime, no more static typing, there be monsters here! What does this mean for Visual Basic programmers? I would guess that the group of programmers that are currently programming Visual Basic aren’t exactly, in general, those who know what type erasure, type inference and monad comprehensions mean. I wonder whether Microsoft may be letting their developer base walk the plank in some sense, but only time can tell.

Erik Meijer has been teaching as an assistant professor at the University of Utrecht prior to being with Microsoft and one of the most refreshing things in the presentation was to see a theoretical person using all his theory and knowledge of paradigms, semantics and whatnot to improve (I hope) production environments. All in all a great presentation, I’m still spaced-out about being able to access a lot of my functional programming things in C#.

Finally the fun anecdote Meijer gave during his presentation: Originally LINQ was called LIQ, but marketing changed it to LINQ as Language Integrated Query Object Relations would’ve become LIQOR otherwise. Can’t have that, nope.

The book takes you through the object-oriented terms, strategies for evolving good designs, bringing the users into the process, and guiding everything along nicely by role-playing use cases, etc. While the ideas seem sound, psychologically speaking, I cannot help but feel that the described test cases work out just a bit too well. However, I am hoping to be pleasantly surprised and see that it can indeed work in a setting where people’s understanding of object-oriented design is rather rudimentary.

For the interested parties, there’s a photo of the shirt on my floor, here…

We managed to create, within the 48 hours, a lovely game in style with the games of the 80s that we have both grown up on and loved, so without further ado, we bring Atomic Cellular Dysfunction to the world. We hope you will enjoy it as much as we enjoyed PacMan and the other great games of our time.