Tuesday, 26 August 2008

Loweswater Lake

It rained almost all of yesterday, but we still managed to get out for a decent walk, this time alongside Loweswater Lake which is one of the smaller lakes up here, but in a pretty setting, almost joined to the next lake, Crummock Water.

The walk we took takes you along a good path which lies about half way up the ridge overlooking Loweswater, eventually descending to a farm at the end of the lake, then back along the lakeside, past the National Trust bothy and the rowing boats for hire, which looked rather forlorn in this weather. We saw very few other people walking today, not surprisingly. The tops of the hills were hidden in cloud a lot of the time, but in true Lake District fashion they would suddenly clear, yielding glorious views.

Slightly annoyed to discover that my supposedly waterproof Berghaus jacket, isn't. You discover the meaning of 'waterproof' in this rain!

Sunday, 24 August 2008

Lake District Break

We're enjoying a very welcome week off, away from it all in the Lake District. We are staying in a really special place, Winder Hall in Low Lorton. Originally a Jacobean manor house, it looks like the Victorians had a hand in updating the interior, and much more recently the owners have created a magnificent place to relax. In the grounds there is even a hot-tub, and a summer-house containing a sauna! We've taken advantage of both - fantastic. The food is good, too - if you ever stay here, then be sure to have some of Clodagh's home-made seville-orange and lemon marmalade, it's epic!

There are some great pictures of Lorton Hall (before it became the Winder Hall hotel) on the Visit Cumbria website. Scroll down about half way to see the house and grounds, and the Pele Tower which forms part of the hall.

The surrounding area is simply outstanding. Today we walked up to the top of Barrow, close to Braithwaite, which is a short drive from Low Lorton. Barrow is not that high (around 1500 feet) but you get one of the best views in the Lake District from the top. The weather has been kind, so it was possible to see all the surrounding fells and a long way further out. This was a warmup for longer, higher walks later in the week - I'd like to get to the top of Great Gable, about twice the height of Barrow.

Thursday, 21 August 2008

NetBeans 6.5 Unusable?

I recently installed NetBeans 6.5 Beta on both OSs on my laptop (Acer 2GHz dual-core, 2GB, dual-booting Win XP and LinuxMint) and I almost immediately uninstalled it. What is going on? Some of the UI appears to be broken: controls not lining up correctly, some dialogs displaying completely blank contents, some the wrong size (e.g. far too big). Sometimes the last two could be fixed by closing/re-opening, but not every time. It also felt a lot slower than 6.1.

Seems other people have been having the same experience. A lot of what Casper wrote in his piece resonated with me, as I also come from the Visual Studio / C# background. I do hope the NetBeans team pays attention because this is an important product which is already good, and deserves to be better. I really don't want to use Eclipse, and I'd prefer not to pay for IntelliJ. Come on Sun!

97 Things Every Software Architect Should Know

Ran across another one of those 'things every architect should know' sites, via Michael Nygard's blog. I haven't read every single one yet, but my unscientific selection yielded a few really good ones, and one or two I felt were less worthy (and not really architecture-specific anyway). I found myself using the titles to select which ones to read in detail, and this proved a pretty reliable guide to the value of the idea and the quality of the writing.

A side-effect of looking at this list was being asked to sign-up to Near-Time. I haven't yet figured out exactly what this is, but it appears to be a public, Web-2.0 collaborative workspace thingy. As usual, I'm probably way behind everyone else on this.

Tuesday, 12 August 2008

When Google Owns You

I must admit I do sometimes wonder how I would cope if Google decided to pull the plug on my account. For me, I would find life without Google (especially GMail, Google Docs, Google Reader and Google Maps) very hard indeed. It's happened to Chris Brogan. Read his post When Google Owns You | chrisbrogan.com.

Finding a replacement which doesn't suck would be hard right now. I just don't really like Yahoo or Microsoft Live much (though I have accounts on both), and even with a replacement service I'd still not have access to the giant heap of old email and documents which Google does such a great job of storing and searching for me. And, despite other peoples' suspicions that Google no longer lives according to its founding principle ("Don't be evil"), I instinctively trust Google much, much more than Microsoft or Yahoo.

All this great Google stuff is completely free, so it's very difficult for any of us to complain if it does get withdrawn. I don't for one moment think that Google is likely to do that without good reason, but it puts all of us in a position of having little or no leverage. Personally, I'd be more than happy to pay a nominal amount for my Google services (by which I mean almost everything except search), to ensure continuity of access, security of my data and a contract which means I'm owed the services. How much? I don't know - what about 30 USD a year? That's unlikely to upset anyone who really wants or needs the service, but if enough people paid it could provide Google with a ton of additional money they could use to invest in making those services even better.

Will Google ever transition to a paid model? The Picasa photo service has a free and paid service already, probably because Flickr and others do this as well as to cover storage costs. But for the rest of Google, I'm not sure. You can imagine how administrative overhead might soar with paid accounts: not only would they be obliged to keep track of everyone's identity, account and payments, but armed with a contract, the kind of people who are intolerant of even occasional outages would feel entitled to complain loudly. I wonder if the folks at Google have 'done the math' and decided that any additional revenue would be eaten up by this sort of thing?

Friday, 8 August 2008

Java and Ruby, C++ and VB

Were you doing Windows development, about 10 years or so ago? If so, then I'm pretty sure you'll recognize the following.

The hard stuff, or more accurately, all the performance-critical stuff and the core components of your product would be written in C++. The functionality in the libraries you and your team created was then composed into COM components, and you designed interfaces, wrote IDL and created type libraries which exposed the component functionality to the outside world.

Lesser mortals could then use COM-aware languages and tools, like Visual Basic (VB), to create sophisticated applications to exploit the power of those components. Component-oriented software development was a reality. UI designers, the subject-matter experts and the VB programmers could get together and build something using your C++ classes, all without having to know about vtables, pointer arithmetic, or what a pure virtual function is.

This was COM (and OLE2) and it was great technology, because it allowed us to do mixed-language development, to compose systems from components without necessarily knowing how they were implemented internally. We could use the right language for the task in hand, which might be C++, Delphi, VB or even JavaScript, knowing the resulting component could be used by any other COM-aware environment.

It wasn't perfect. The COM abstraction was somewhat leaky because even when using 'scripting languages' like VB to combine COM components, you still needed to understand COM's reference counting semantics, and marshaling of data across the COM boundary wasn't always straightforward. But the benefits manifestly outweighed any of the technical difficulties.

With Java and especially .NET we moved away from the idea that we'd build lower-level functionality in one language and use a less formal or type-safe language to 'script' applications on top of it. Microsoft have always claimed that mixed-language development is a cornerstone of .NET and the CLR. It's certainly true that the CLI does explicitly set out to enable multiple languages to target the infrastructure, but this misses the real point, which is that relatively few projects appear to have exploited this. Most .NET solutions are developed in just one language, either C# or VB.Net, the choice usually made early, based more on team culture than on technical grounds.

I haven't heard anyone saying "Well, we used C# for the hairy low-level components, but we built the application itself in VB.Net because it's so much quicker to prototype". Does this happen now? I don't think so, yet back in the C++ / VB world, it really did.

I believe we are in a roughly similar position now, with respect to building complete solutions, as we were when VB and C++ were joined at the hip via COM. We want the big languages and frameworks for building powerful libraries, for high performance and for when we need (or get real benefit from) strong, static typing. But we all want to use these lovely new dynamically-types languages like Ruby, Python or Groovy because they're concise, powerful and fun. Look what I can do in 5 lines of Ruby! It would take 50 lines of Java to do that! And just look at the clever metaprogramming stuff! Wait! These languages are great! Why don't we write everything this way!

Now think back to VB ... who remembers this book ? This was one of those landmark books you recall long past the time you stop consulting it. Part of the charm of this book was the writing of Bruce McKinney, who managed to combine a determination to wring the very most out of VB with an iconoclastic view of Microsoft, the very people who both developed VB and published his book! I liked the book, and I loved the writing. Plus, it really was hardcore: if you paid attention to the book and practised what it preached, you became a better (or at least, more capable) VB developer.

Now, I'm not trying to suggest that Ruby (or Python, or ... etc.) is/are no better than VB6, because that's clearly nonsense. But I am suggesting there are strong parallels between the two situations. With the dynamic, interpreted languages like Ruby and Python we have flexibility, speed (of development) and agility, and we can get something running without all the troublesome attention to detail required by C# or Java. Just as we liked the VARIANT type, we like dynamic (and 'duck') typing, and we like the syntactic economy of not having to use type names everywhere.

So we have a similar situation now to that which existed when VB was at its hardcore height: the evangelists and enthusiasts want to build absolutely everything in Ruby (or Groovy, or Python, or etc...), whether it makes sense to or not. The problem is the 'evangelists'. Or fundamentalists - you decide which term you prefer. Their enthusiasm for their favourite language unfortunately causes them to stray into deeper academic debates concerning type systems. They are so anxious to promote their chosen path, they want to convince the rest of the world that you really don't need static typing, even that static typing cannot save you from anything, so why bother with it? Do everything in <someDynamicLanguage>. Hardcore! I'm not going to wade in to the silly static typing versus unit testing squabble. The essential point is that serious issues are often hijacked, trivialised and misrepresented to serve as ammunition in some language or platform flame-war. Here is an excellent, sane post, as an antidote, discovered as a link in this piece by the equally excellent Tim Bray.

The analogy I'm trying to use is a little strained, I will admit: VB was a fundamentally weak language (see Bruce McKinney's departing missive), whereas Ruby is not. The difference between then and now is that there is no need for a 'Hardcore Ruby' book because you don't need to strain at the boundaries of the language to do powerful things. The similarity rests on the fact that with technologies like JRuby (and IronPython) we have the ability to use a variety of languages and approaches to attack the different layers in our solutions.