Stuart's Soliloquy to the void

Highly hydrated doughs

Saturday, April 17th, 2010 | Cooking | 2 Comments

Since the time I started baking I have read copious amounts of information on baking, primarily perusing titles from master bakers here and there, and some successful owners of bakeries in Denmark, Sweden and the United States. Some give good advice, others not so good, but the main thing I’ve taken away from having read all this is… it’s food, experiment and find something you like (though do be accurate about what you do so you can recreate it).

In some peoples’ opinion (and mine too for that matter), you should try to master the plain bread before you start adding all sorts of extra things to it. In a basic bread there are four ingredients: flour, water, salt, and yeast (or sourdough). That is it. No seeds, no additives, no lard, no herbs. Just four plain ingredients. I use organic flour and Maldon sea salt, mainly because I do not fancy eating flour with all kinds of remnants of artificial fertilisers, and Maldon sea salt because I like their salt taste the best (but do try a bunch of different salts and find the one you like best).

The amount of flour you put into this thing mainly controls how much bread you will have once the process is done (this is an over-simplification, each ingredient influences the final outcome in a lot of surprising and complex ways, so take the following with a grain of salt), the amount of salt will control the taste (and to some degree how well the gluten strands develop), and the yeast will control how quickly the fermentation process will happen (more yeast, faster bread and less taste, less yeast, slower bread and more taste), and finally there is the water. This is usually the ingredient you turn up and down to control the handling characteristics of the bread. The lower water rate, the more manageable the dough is, the higher it is, the more you will feel like you’re battling some sticky monster from hell as you try to shape everything up into loaves of bread.

So for a while I have been giving the breads very low amounts of yeast (around 1–5 grams), rather long time to ferment (from 5 to 18 hours depending on how busy our daily schedule is), and very high amounts of water (around 90% the weight of the flour) a try. This has given me a very open and creamy crumb with a soft crust the first few hours after baking, which hardens into a denser crust after 6–12 hours and a superb taste. In order for such a wet dough to stick together, it is necessary for the gluten to be able to keep it all together, which is what the long fermentation will help you achieve. For a brief few illustrations I have taken some photos of a 5 hour fermentation followed by 10 hours retardation (placing the dough in the fridge).

The lighting is a tad shoddy. It is surprisingly difficult to pour dough, handle a camera and get the lighting just right around 7 am after having stumbled out of bed. There is some nice gluten strands here, but without the retardation they are typically longer and tougher. You can tell how strong they are by how long they can get before they snap if you pull at the dough.

Next, there are more fun ways to influence the result of your bread: how you bake it. With steam? without steam? at what temperature? for how long? I usually pour a bit of water over the loaves just before I put them in the oven, which will create enough steam to keep the crust from setting too quickly. Since the dough is highly hydrated, the loaves need to bake for a good while (usually around 40 minutes in my oven), and I start out at the high end of the temperature range at 250°C for 15 minutes, then I vent the oven (open the hatch for a few seconds to let out the steam), then I finish baking over the next 25 minutes, slowly reducing the heat once in a while to keep the crust from scorching.

After baking, you will have a nice, creamy, open crumb and a wafer thin crust that flakes like it does with plain bread from a good bakery. Flour, water, salt, and yeast. That is it.

Tags: baking, bread, white bread

X.509 certificates and Mercurial

Friday, April 9th, 2010 | Development | 2 Comments

As one of the primary developers touching certificates in the Mercurial world, I am often asked how they work, what people need to do to use them and how they can work well with Mercurial.

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"
            oneToOneCertificateMappingEnabled="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!

Tags: distributed version control, Mercurial, programming

Chocolate cupcakes

Saturday, November 14th, 2009 | Cooking | 3 Comments

Recently, my youngest sister wanted to bake these ‘advanced’ cupcakes, so she asked whether I would bake them with her. Never avoiding a chance to bake with others, I immediately agreed, and we had a lot of fun preparing, decorating, and not least eating the cakes.

It’s a fairly standard chocolate cake with whipped egg whites carefully folded into the chocolate batter. After a good bake we piped butter frosting over the cupcakes and drizzled candied violet over it.

Looking closely we can see the small pieces of candied violet better:

Normally I don’t fancy cupcakes too much as I think they have a tendency to become a bit too dry, but these were very good. Yummy.

Tags: baking, cake

Slow durum bread

Saturday, November 14th, 2009 | Cooking | No Comments

If one has better time, it is, of course, preferable to give the bread a slow rise, which brings out more flavour nuances in the bread. There isn’t that much difference in consistency to the quick durum bread, but it does have better flavour.

The ingredients are:

• 700 g wheat flour
• 300 g durum flour
• 10 g fresh yeast
• 20 g sea salt
• 700 g water

The ingredients are mixed together for 3 minutes at first speed to incorporate the ingredients, and then continuing on first speed for another 7–8 minutes to develop the gluten.

The dough ferments for 3 and a half hours with folds every 50 minutes and then the dough is shaped into pretty loaves.

After 1½–2 hours of proofing, the loaves are slashed and baked. Looking closely after the slashing we can see the bubbly activity inside the bread.

After baking they have a lovely golden durum crust.

And after cooling, the bread is ready for serving, perhaps with a nice variety of seafood.

Bon appetit!

Tags: baking, bread, white bread

Quick durum bread

Friday, October 23rd, 2009 | Cooking | No Comments

Ever since our daughter has started in a nursery, we have more or less been incapacitated with illness, one overtaking the next, so time and energy for baking has been rather scarce. I did, however, succeed in baking a quick bread this past weekend, before I succumbed to another illness (the joy).

I found myself without bread on saturday, and a lacklustre enthusiasm of having to eat the local bakery’s cardboard bread once again. Lunch was few hours away, and the only straight dough recipes that I really like takes at least six hours from start to finish. So what to do, what to do… let us try something crazy and just go with the flow. Let’s try to mix some of the techniques from the slower breads, and the theory of bread baking I’ve been reading up on, with the traditional way for Danish home bakers to bake: quickly and with lots of yeast.

For interested parties, I’ll present to you the ingredients here:

• 700 g wheat flour
• 300 g durum flour
• 28 g fresh yeast
• 24 g sea salt
• 650 g water

This is a bit high percentage of salt given my usual tastes, but the quick fermentation process will yield a rather non-tasty bread (i.e. without as much wheat flavour), so we compensate by adding salt (this is not necessarily a good way to compensate, but when in a rush and all that…).

The ingredients are all weighed into a mixing bowl and gets an improved mix (3 minutes at slow speed for incorporation, and 3 minutes at a higher speed for gluten development). In order to further improve the gluten structure (this was, perhaps, not really necessary as it wasn’t a terribly wet dough, all things considered), I decided to let it ferment 40 minutes, fold, ferment 40 minutes and then divide and shape into loaves.

After the first fermentation, the dough is slightly sticky, but it has a nice structure, a bit like a good Danish dough.

Folding it gives it a very nice, firm, and smooth texture.

And giving it another 40 minutes to divide the loaves and shaping them works nicely.

After this comes the proofing time, letting the loaves rise after you’ve removed a lot of the air when shaping the loaves. I let them proof for about an hour, enough to turn my oven up to 236°C. I let the loaves bake around 30 minutes, but they probably could’ve taken five minutes more.

We were rather in a rush, so waiting for the breads to cool entirely was not really an option either, so we dug into them a bit early, while the crumb was still a wee bit too moist (but that is, for some reason, what most people insist they prefer).

This bread will not win any taste rewards, but it’s a nice, quick(-ish) bread with a comfy feeling (kind of saturday morning, the rain is pouring down, you’ve got a cold and you just need a nice warm slice of bread with jam and a big cup of tea, your comfy chair and a good book and to whittle away the hours). It definitely beats the usual quick breads from the Danish bread cook books, if I have to say so myself. Also, the durum flour gives it that nice, rich yellow tint (although that may be a bit hard to pick up from the photos).

Tags: baking, bread, white bread

Server outage

Thursday, June 18th, 2009 | Uncategorized | No Comments

The server this site is hosted on died rather spectacularly yesterday. Given my lazy attitude to backups it has taken a while to get everything sorted, but most things should be here now, I think. Comments that have been posted to the blog after November 2008 have been lost, but honestly, there aren’t a lot who post comments, so that is not that big a deal.

If you have sent me mail it should arrive here within a day or two, depending on your mail server’s setup, so replies may be slower than usual.

I should probably do something more coherent about taking backups of my site.

If you’re reading my blog through syndication this probably also means that my blog has been spamming you a bit due to changed identifiers on some posts, sorry about that.

Managing online development communities

Monday, June 15th, 2009 | Development | No Comments

A few friendly reminders to people shepherding development efforts:

• 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.

Croissants

Saturday, May 16th, 2009 | Cooking | No Comments

Between having taken up a new job and having a baby daughter there is practically no time left to do anything, and blogging has been prioritised rather low in the little time there has been, and baking only slightly more than that, so it has actually been several months since I have been able to find time to bake anything. So, the day that I actually found time to bake had to be used to its fullest with something non-trivial, and one of the things I have missed dearly has been some of the folded butter doughs like wienerbrød (Danish pastry) and croissants.

The dough has to be rolled out to a rectangle and be fairly thin, then you add a block of butter (or margarine in my case), fold the sides over the margarine, roll it out and make a single fold. Then you refrigerate it for 30 minutes, roll, fold, refrigerate, roll, fold, refrigerate, and then you shape. I would’ve liked to get some photos of the margarine work, but from previous experience everything gets easily ruined when working with margarine if you pause overly long, since it is a lot softer than the butter that is usually used. So we skip forward to shaping the croissants.

Since the margarine is so soft I have had to add more flour to keep it from leaking everywhere, making the dough a good deal firmer than it is supposed to be. At least they are croissant-shaped, but they will most likely be somewhat more dense than what I had hoped for.

Sure enough, not the light flaky croissant you get at a bakery, but a tad heavier, albeit still decent, croissant. They weren’t all bad, though, about 25 of these disappeared within a few hours.

Tags: baking, pastry

Apple medals

Sunday, February 8th, 2009 | Cooking | No Comments

In Denmark we have a range of cakes that are called something with ‘medal’ in them – these are typically shortcrust cake layers around… something. The most traditional ‘medals’ have whipped cream in a layer between two shortcrust layers and with icing on top of the top layer.

A few ‘medals’ are actually closed as in the two shortcrust layers are glued together, typically with egg, a bit like mini-cobblers. This blog post is about one of such ‘medals’, the apple ‘medal’ – I have been unable to find a traditional English name for these cakes, so if you know it, please let me know.

The apple filling in the apple medals are mashed apples that have been cooked for a while to remove the excess moisture. A small amount of this ‘cream’ is then added to each shortcrust bottom.

Using egg to weld each cake shut, a wash of egg is applied and nuts are drizzled on top – traditionally you use almonds, but we only had hazelnuts, so I used those instead.

After baking, the cake is a tad dry, as baked shortcrust often is, but the creaminess of the apple in the interior makes up for this… mostly. (They are still a tad too dry for my tastes).

To make up for the dryness, serve with a nice portion of whipped cream and a few berries.

Tags: baking, dessert, pastry

Sonnenblumenbrot – sunflower seed bread

Wednesday, January 28th, 2009 | Cooking | No Comments

Since I have started working full-time on a new job and have a longer commute, and I like to spend the hours when I am at home with my daughter, I have neglected both this blog and baking for a while.

With a child in the house both my wife and I tend to make recipes we know so they do not require so much focus, but by doing that we risk getting set in our habits, only eating the same kinds of bread, the same kinds of things for dinner, for the next many, many years. So in order to break free of that, we have agreed to make something new each week – my wife will make a new recipe for dinner, and I will bake something I do not usually bake.

For last week I delved into the ‘not entirely white bread’ recipes in Jeffrey Hamelman’s book ‘Bread’ and found this German recipe for sunflower seed bread. I am, personally, a bit so-so with sunflower seeds, but my wife absolutely loves them, so I figured why not. We will need lots and lots of sunflower seeds.

We will also need a rye chop soaker and a pâte fermentée to add to the final dough.

The mixed dough is fairly reminiscent of the white doughs from Hamelman’s book, just a bit less ‘extremely sticky’.

Now, the recipe calls for a good long bake of 40 minutes at 240°C, which seems to be a bit too much, so I would suggest turning the heat about 10–20°C down after 20 minutes (when I look at the recipe again, Hamelman actually also suggests this).

Traditionally, the Sonnenblumenbrot is moistened on top and dipped into non-roasted sunflower seeds, however since I am not too keen on too many sunflower seeds, I opted to skip this part. It is still, all in all, a very wholesome bread with a beautiful crust, and a nice crumb with bite, due to the sunflower seeds, and a slight sweetness, due to the rather large, in my opinion, amount of malt syrup that goes into the dough as well.

Very excellent with jam.

Tags: baking, bread