This Belgian number really surprised me. It has a hint of lambic sourness, that makes it fresh and interesting and for me separates it from most other standard brunes. It seems that many people don't rate it, but I find it to be an interesting diversion, if only for its subtle sweet and sour novelty. I don't think I'd have more than one of an evening though – it's not that great overall.
This beer is a fruity revelation! At least if you like that sort of thing. Officially described as being flavoured with red fruits, with a hint of spice and wood, even a touch of sourness, the result is very impressive. Like most fruity beers it's not strong at 5% but it really does taste wonderful. To me the main fruit flavour is raspberry with maybe a drop of cherry.
I will be seeking out more of this stuff, and if I don't my wife may not forgive me for drinking most of this one.
When I left a job recently, my Belgian colleagues presented me with a basket filled with a vast and varied array of beers. My arms having recovered from carrying it home, it's now time to sample these fine wares.
First up Affligem Blonde, at 6.8% a relative lightweight in the Belgian canon, but I was impressed by the overall result. A bit like Leffe, but more subtle and probably less cloying if you were to drain a few. It's really smooth and well-balanced, just edging only slightly into the treacly tendencies of classic Belgian brews, but definitely going beyond "straightforward lager". I really liked it – it's a great beer to start an evening of lowland delicacies or for general consumption if you're not feeling like the heavy stuff.
Expect more over the coming weeks, and expect them to be mostly in entirely the wong glasses, as above.
Allow me to wax philosphical for a moment with an observation about where computers and their operating systems are heading.
In the world of software development CQRS = Command Query Responsibility Segregation, which in its simplest sense recognises that it's sometimes better to use a different mechanism for reading data than it is for writing it. See Martin Fowler's exposition of the concept if you want to know more, but this post isn't actually about software development at all!
I reckon that we're at a critical juncture in the evolution of personal computing devices and that the CQRS principle is necessarily coming to the fore to save the human race.
Tablet computers are taking the world by storm, in case you hadn't noticed. Apple could barely make enough iPad Minis for me to be able to get my wife one for Xmas, though I did manage it at the very last minute, and shortly thereafter bagged one for myself too. Frankly it's bloody brilliant, but I use it predominantly for consuming rather than creating and I'm far from alone. This is partly because the human populace is inexorably dumbing down towards being fat blobs with brains wired directly into the 'net, consuming inane banter, amusing picture of cats and the latest celebrity news, 140 characters at a time. But that aside, it's just not very pleasant to write large quantities of text, manipulate images or perform other expansive creative works by prodding a tiny screen. Or even a big screen.
To write software, construct lengthy blog posts (ahem), edit movies, sequence the human genome or design great buildings requires a proper computer! On that basis I posit that there will always be a place for desktops and laptops, or indeed whatever replaces them but which necessarily has a non-trivial input mechanism. I genuinely worry that the market for serious computers will be increasingly neglected by the manufacturers, refocussing as they are on the mass consumer market, inevitably leading to the downfall of humankind. Perhaps I exaggerate – at least I hope so.
Now I've never used Windows 8, indeed I shudder at having to use Windows 7 on a daily basis at work, but I understand it represents something of a chimera. It is best known for its shiny, touchy, slidey 'Metro' UI, beckoning your greasy fingers to caress its tiles. However it also allows you to fall back into the more staid world of traditional Windows where presumably you can get some proper work done, as long as you have a keyboard and a pointing device other than your finger. I understand critics are conflicted about this hybrid approach, but it's CQRS writ large and may therefore be the way forwards. One way or another, at least some people will need to create great works. I do hope to be one of them, and to have the equipment to be able to do it.
I have a fair amount of lawn in my garden, which is looking pretty ropey right now, but I'm working on it! However I'm intending to convert a lot of it to more intriguing beds and paths. This project details one little part of that grand plan. In the picture above, I've removed the turf from a corner, which originally had just a narrow bed at the back against the trellis.
My plan was to put a curving brick path through this new area, leaving an eye-shaped island that will probably host a small tree and other planting high enough and rumbustious enough to make the path a little voyage of discovery. A very little voyage, but adding much-needed intrigue.
I started by using the garden hose to experiment with the shape of the path, using some bricks to get the width right. What a beautiful shape!
Those bricks, and indeed all the bricks I will use, are from the rear chimney on the house, which was removed in a recent loft conversion (the chimney, not the house). They are a mix of old handmade red clay bricks and nasty moulded modern things, but they have some character, including sooty marks, and I think mixed up they're going to look the part.
I'm not sure how well they will survive the harsh winters that seem to be the new normal. I strongly suspect they will suffer from frost damage and it will be interesting to find out whether it's the old or new that perform better. I have plenty left to repair the damage. For the record, ideally you'd use engineering bricks, but I don't have any and I feel it would lack the charm of a crumbling old brick path.
Having established the basic shape and scored a mark in the soil with the edge of a spade along the hosepipe, I dug it out about a brick deep plus a couple of centimetres for the sand. I also added 5cm or so on either side to give room for manoeuvre.
Theoretically I should use pegs in the ground, string and spirit levels to establish a perfectly level, flat path, but that's just not my style, and the two ends are not at the same level anyway. I used a couple of bits of straight wood and my eye to make sure that the soil bed was basically level with no major local bumps or hollows. Again I invoke 'rustic' as an excuse for my slapdashery.
Do you know why sharp sand is called sharp sand? Because the individual grains are all knobbly and 'sharp', compared to non-sharp sand which has smooth, rounded grains. This helps them to lock together and form a firm base. I've used four bags of sharp sand and with the aid of a rake and a piece of wood the width of the path dragged over it, I've turned it into a smooth base ready for my bricks. I spent quite a while trying to get this right, as it will be reflected in the final result.
By the way, I bought six bags of sand from Wickes for the grand total of £10.86, and that was my entire spend on this project. The rest is bricks and tools I already had, and my own labour.
I figured it was best to lay one whole run the length of the path, to establish and tweak the basic curve. Then of course the subsequent runs are a bit longer each time around the curve, so we need half-bricks here and there to keep a good pattern going.
I used a bolster chisel and club hammer to cut the bricks by hand, which takes a bit of technique, a certain amount of practise and a lot of patience, especially when it's raining and you can't see through your goggles (you don't want brick chips in your eye). I think most people would find this the most challenging part of the project if they haven't done it before. You can get machines to do it nicely and with no effort on your part, which would be worthwhile if doing anything much bigger. A straight path would only require half-bricks at the ends of course.
Once I'd got all the bricks down it looked pretty good, but only then did I fork over the beds either side, being very careful not to disturb my new path. I had been agonising over whether to do that first or last. I feared that if I did it first I might loosen the firm bed for my path, compacted nicely as it was under the old lawn. Also, it would have made working around the path and seeing the edges a lot harder, so I'm glad I did it this way around.
Finally, I did that digging of the compacted soil, and packed it up to the edge of my bricks, ready to receive plants. Then I brushed more sharp sand into all of the cracks to finish off the path itself. That took a surprisingly long time and a few goes as the bricks settled and new holes opened up. Using very dry sand really helps it to fall down those cracks so I dried mine out in the sun before using it.
I'm very pleased with the result, but time will tell whether it's really any good. Next project is the planting either side of it.
I do love a Belgian beer. I don't know how they do it, but their strong, sweet creations are the beery equivalent of comfort food to me. But this is a strange creature that I review today.
Bought in the Carrefour Express in Brussels Midi station, it appears to be a slice of Scottishness amid the Belgian fancies, certainly in terms of the branding. But it's 10% by volume and is quite clearly a deliciously sticky Belgian tipple exactly as I would expect, and decidedly un-Scottish. I suppose Barley wine may be the connection. It's described on the bottle as "strong blond and mellow beer" and I can't argue with that.
Is this just a piece of branding silliness, selling a bit of tartan-clad och-aye-the-noo to the rest of the world, who do appear to love that sort of thing? Possibly. But I actually liked it so much that I'd buy it again.
For what it's worth a little delve into its provenance takes us to anthonymartin.com where we find that an English brewer setled in Belgium and started producing beers in 1909 and that this particular brew has been around since 1990 and they own the TImmermans brewery known for Gueuze Lambics.
I see irritating problems. Every tangible thing I use, every service I consume, I can't help but notice all the little things that could have been a bit better. And it really frustrates me when these are details that seem so very simple to fix.
For instance, when I buy a train ticket from FCC's machines at St Pancras I can't actually see the text on the card payment screen unless I squat uncomfortably, because it's low down and inset out of sight. I know it's low down so disabled/short people can use it, but at least provide a direct line of sight for the average sized person standing in front of the machine – i.e. 95% of your customers!
I recently bought a D-Link powerline networking kit on Amazon, which is a wonderful product by the way, that worked straight out of the box with zero configuration. But the Amazon page did not state that there were two ethernet cables in the box – though I suspected there might be and was explicitly looking for this information. Worse than that, it provided a handy link to buy the product along with two separately supplied ethernet cables. So I went with that (better safe than sorry) but lo and behold: two cables in the box and now I have two extras I paid for and don't need. I feel I have been poorly served by Amazon.
Often when travelling by train, announcements are made that are inaudible due to the low volume (compared to background noise) or muffled by unhelpful acoustics. But these are sometimes really very important announcements and there's precious little point making them if they can't be heard.
Whenever I visit the hairdresser they ask me what I want doing, and I struggle to articulate it, especially when it comes to the intricacies of the back of my head. Why don't they take photos and notes (in special hairdresser shorthand) so that they can sort me out consistently every time, even when it's somebody new cutting my hair. As far as I'm concerned this is a no-brainer.
There are many little disappointments just like this that I spot on a daily basis, with physical and virtual products and services and I'm increasingly wondering whether there's a way to turn this into a job: detail consultant. Available for hire by companies small and large, I would tell them what could be improved to give their customers a delightful rather than frustrating experience. It's not rocket science but apparently there's a gap for this sort of common sense supplied from an external viewpoint. Please form an orderly queue!
In fact I'm surprised that larger organisations don't have full time employee roles with exactly this mandate: roving throughout the company and in the field spotting and fixing these subtle issues. In a competitive world where bad publicity is only a Tweet away, this seems like a very good use of resources to my naive mind. If you have any pride at all in what you're doing that is.
I've been doing some trivial benchmarking of Play 2 with ab (Apache Bench) just to get an idea of its raw capabilities for serving simple requests – and because it's what I always do when picking up a new framework so I know what I'm dealing with. In doing so I ran into a bit of a puzzler that had me thinking Play 2 was bugged – but my spidey sense soon kicked in and told me it was more likely to be an OS or ab issue. I had done approximately the following, using Play 2.0.1 on OS X 10.7.3, and I'm pretty certain you'll see the same results if you do this on a Mac:
> play new hello [select option 1 - basic Scala app]
> cd hello
> play start
> ab -c 50 -n 16000 http://localhost:9000/ [Runs fine - about 3700rps]
> ab -c 50 -n 16000 http://localhost:9000/ [Gives up with timeout]
> ab -c 50 -n 16000 http://localhost:9000/ [Runs fine - about 3700rps]
> ab -c 50 -n 16000 http://localhost:9000/ [Gives up with timeout]
It took me a bit of experimentation to establish that it's about 16000 requests that work fine, followed by timeouts, in a reliable pattern. That's a suspicious number, being near enough a power of 2, which is what clued me into it being an OS limit that I was running into. I ran the same ab test (with the same result) against the built in Apache https serving a static file, confirming that Play 2 probably wasn't to blame.
Sure enough, a quick Google turns up the goods. My OS was running out of the approximately 16000 ephemeral ports available and having to wait for them to be released before it could reuse them. So not Play 2 or ab's fault at all. Actually in some senses it is Play 2's fault for being so fast that I've run into this limit.
I'm not going to go into the details of what ephemeral ports really are, as others have done that perfectly well, and there is a good StackOverflow answer with some key ways to work around the problem by modifying parameters of the OS' network stack – but be careful and make sure you understand what you're doing.
However, one very simple way to workaround the issue is to simply pass the -k option to ab, to use HTTP keepalive (assuming the server you're testing supports it). Note that this changes the nature of your test though, as you're no longer really simulating large numbers of separate connections – but for basic sanity check testing it may help. For the record `ab -c 50 -n 100000 -k http://localhost:9000/` benchmarked Play 2 at about 7000 requests per second on my 2.4GHz Core Duo MacBook.
The hype around the Scala programming language just got too much recently and I decided to give it a go. I'm two thirds of the way through Programming in Scala, a massive but very good tome and I've been experimenting with the language and tools, though only a little bit so far. I have also just received the newly published Scala for the Impatient (a deliberately much more compact book) and will be working through that as well.
To put it mildly, Scala is not for the faint hearted, or anyone who just wants to get some stuff done ASAP. There is a big, steep learning curve and the relative immaturity of the language and the small community means you'd better be used to the pains of the bleeding edge. I thought Ruby was hard work, but Scala is frankly more so in my experience so far.
However the language is somewhat addictive – or perhaps I just like the challenge of learning stuff that takes a bit of grokking. It's a big language, with many very clever facilities and features. It's mind-boggling to start with but I think it's starting to sink in. Of course there's the functional paradigm to understand and master, but I did plenty of that at university so it doesn't frighten me.
Enough people have written about the frustrations and wonders of writing code with Scala, so I think I will reflect on a few miscellaneous findings, mostly of a practical bent.
Compiler speed
The Scala compiler is surprisingly slow and it seems to be one of the main bitching points amongst people trying to get up to speed with the language. But seriously, when you're used to instantaneous results with Grails, or even plain old Java (especially with JRebel) then waiting several seconds even for a trivial app is most upsetting. But I'm trying to be Zen about it.
The mailing lists tend to be full of griping about the compiler's speed, usually met with promises that it's getting faster, but the Scala compiler is so much more complicated than the Java compiler that it seems unlikely to do its work in the blink of an eye anytime soon. See Martin Odersky's explanation of why it's slow on Stack Overflow.
Eclipse support
Eclipse supposedly has good Scala support via the Scala-IDE plugin, but I found the out of box experience so terrible that I have given up. Having created a "new Scala project" I still had to manually add the Scala libraries to the project and manually create run configurations, which would very often still not appear in the lists of ways to run the project. I just want to hit "Go" and for my app to run – it should be trivially easy to make this happen. In my experience the best open source projects are the ones that deliver a delightful out-of-box experience and this has disappointed me on that front.
IntelliJ IDEA support
Luckily the Community (i.e. free) edition of IDEA supports Scala. Even though I hadn't used IntelliJ previously, I figured out how to download their Scala plugin and create a Scala app within just a couple of minutes and it was a very smooth experience compared to installing the Scala support into Eclipse (don't get me started).
However compilation of a Hello World app took 7 seconds every time I modified the single file! A bit of Googling led me to discover FSC – the Fast Scala Compiler – which is part of the standard Scala toolset. Support for FSC is built-in to IDEA but that support is turned off by default. Once I turned it on for my project things hotted up and compilation took just 2 seconds. That's still lamentable compared to most other languages, but just about tolerable for now. I have no idea how things go for a big project, though I get the impression from mailing lists that waiting tens of seconds or even minutes for a compile is fairly commonplace. We shall see.
Play 2.0
One of the reasons I decided to try Scala in the first place was the fuss over the Play 2.0 framework, which has just recently been released in its first 'complete' form. I have only messed with a couple of tutorials so far and frankly it's bewildering and strange coming from frameworks like Spring MVC, Grails, and Ramaze (a small Ruby framework).
There is much wailing and gnashing of teeth on the Play mailing list from people upset about its radical new direction, and its emphasis on Scala compared to Play 1. Maybe it's just the pain of change, but there's no doubt Play 2 is hard work to get to grips with.
I get the impression that a lot of people are missing the point though – it's a case of horses for courses. Play 2 is rather exotically architected using cunning non-blocking approaches that require it to abandon the classic Java Servlet container entirely. It also requires you to write obtuse and sometimes verbose code (compared to Grails say – though it's usually less verbose than Java) and partly because of that non-blocking architecture. Reading and understanding the Play 2 docs on Action Composition may very well require a PhD, but Action Composition is a technique that must be used to achieve relatively common ends. It's all a bit overwhelming for newbies.
This clever shenanigans enables it to handle 40,000 requests per second (albeit very very simple requests) using less than 20MB RAM. I saw Guillame Bort demonstrate this at QCon and it's certainly impressive. The point though is that it's all architected for the sort of new-breed web app that's dealing with connected rich-clients rapidly pushing and pulling data. If you want to create a few CRUD pages for a small admin team to look after a database then I very much doubt that Play 2 is for you.
I recently switched from O2 to Three (whilst picking up a new iPhone 4S) and frankly it’s great. It must be great if I'm blogging about it! Key wins are as follows.
- All you can eat data with Three. O2 have recently abandoned unlimited data and charge based on fixed price data packages for paltry amounts – e.g. 500MB for £6 per month. To be fair I should point out that their systems told me I was only using about 200MB per month previously. But read on…
- Tethering! I can turn on Personal Hotspot on my iPhone and connect to it via Bluetooth, USB or WiFi from another computer and get all the wonders of the internet. This has revolutionised my train ride to work with my laptop. Phone stays in pocket and via Bluetooth I’m fully connected to the world. This is technically possible on some other networks but often only at a price, either to turn it on at all, or because you’ll be charged oodles for the data you use up.
- Raw speed. Over 3G I now regularly get 8MBit downstream, 1.5MBit upstream. That’s better than many people’s home broadband and a lot better than I ever got with O2.
It's not all fun and sunshine though. I found a couple of major downsides, which I will just have to live with.
- Visual voicemail doesn’t exist on Three. Frankly I was dumb-founded when I noticed this. I literally couldn't believe it, but apparently it's true. Instead you get a text message telling you that you have a voicemail and then have to phone a voicemail number and painfully navigate through things with the numeric keypad. It’s positively medieval and if I wasn't so smitten with their data service it would definitely be a reason to avoid Three entirely.
Of course you only find this out after you've signed up because it's not something they point out to you. I have had conflicting messages from different Three employees in shops and on the customer service line about whether they ever intend to get with the program here. Alas I fear they won't.
- Customer service can be dodgy. It was a struggle to get my phone up and running in the first place due to some miscommunication and dodgy information from Three. Their customer service line is like a choose your own adventure book – consisting of endless numeric options designed to avoid having to actually talk to you. Once I actually got to speak to somebody it was alright, though I had to fight my way through the number-maze each time – they wouldn't give me a direct number.
Before my phone was activated (which is ironically what I was trying to phone up to arrange) it was literally impossible to talk to someone because the first auto-question asked for your mobile number and then complained that it wasn't activated! Apparently you have to type hash to defeat this particular monster but they didn't tell me that and the prompt doesn't mention it. Apparently it's a secret.