Skip to content. | Skip to navigation

Personal tools


You are here: Home / weblog

Dominic Cronin's weblog


Posted by Dominic Cronin at Apr 24, 2009 10:25 PM |

Ingrid's "Where I live" post highlights some of the bizarre perceptions people have of Amsterdam and why a person might choose to live there. When I first came here, I was struck by the number of my countryfolk whose immediate thought was "you'll be stoned all the time then".

For sure, the regulations concerning cannabis are relatively liberal here. For me that mostly means that I know that there may possibly be some in the house, but I have no idea where it might be. Maybe it was the victim of a spring-cleaning frenzy. In less liberal regimes, you damn well know where your stash is at.


Posted by Dominic Cronin at Mar 25, 2009 01:15 AM |

It's a predicate. That's the name of the thing, a predicate. Why can't I remember that?

So there I was, trying to explain some XPath thing to one or two of the guys on the project, and I kept hitting this mental block. The things in the squaredy-brackets; what the heck is that called? You know - those things that denote some sort of truth value that indicates membership in a set. The flippin' WHERE-CLAUSE thingys in an XPath. Jeez - you know what I mean anyway - why is it this hard?

It's called a predicate. I knew that - really!

Some words don't stick in my brain. I used to try to conquer this problem by solving crosswords, but then you end up with crossword compilers with warped minds. I recall being driven to distraction by one crossword clue which used gambolas a synonym for capriole. How can you cope with that?


Posted by Dominic Cronin at Mar 19, 2009 10:40 PM |

Scott Hanselman just posted this:

Tongue-in-cheek or otherwise, the idea makes me smile, and I can't help secretly hoping that it could work. Yeah sure, it's a secret, right! Just don't tell anyone who shouldn't know. And of course, all the support guys will instantly trust you as soon as you say it.

Powershell profile for Tridion development

Posted by Dominic Cronin at Mar 15, 2009 09:50 PM |

My powershell profile for Tridion and general .Net development

I have recently stopped using a local vmware image on my laptop for development work, and instead I now use an image hosted on a proper vmware server at the office. I pretty soon discovered that I needed the vcvars script from my other powershell profile. As it took me ten minutes to load up the old image and copy the profile, I figured I'd post it here for future reference. The good bits nicked from elsewhere are credited inline.

Edit: The aliases for the compound templating uploader didn't really work, so now I have a function for this.


function prompt { "PS " + (get-location).Path + "`n> " }
& {
  $prp=new-object System.Security.Principal.WindowsPrincipal($wid)
    if ($IsAdmin)
  $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
  $p = New-Object System.Security.Principal.WindowsPrincipal($id)
  if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
   $Host.UI.RawUI.WindowTitle = "Administrator: " + $Host.UI.RawUI.WindowTitle
  function VsVars32($version = "8.0")
      $key = "HKLM:SOFTWARE\Microsoft\VisualStudio\" + $version
      $VsKey = get-ItemProperty $key
      $VsInstallPath = [System.IO.Path]::GetDirectoryName($VsKey.InstallDir)
      $VsToolsDir = [System.IO.Path]::GetDirectoryName($VsInstallPath)
      $VsToolsDir = [System.IO.Path]::Combine($VsToolsDir, "Tools")
      $BatchFile = [System.IO.Path]::Combine($VsToolsDir, "vsvars32.bat")
      Get-Batchfile $BatchFile
      [System.Console]::Title = "Visual Studio " + $version + " Windows Powershell"
  function Get-Batchfile ($file) {
      $cmd = "`"$file`" & set"
      cmd /c $cmd | Foreach-Object {
          $p, $v = $_.split('=')
          Set-Item -path env:$p -value $v
  set-alias -name rat -value RestartAllTridion
  function RestartAllTridion
  "### Restart All Tridion ###"
  "Stopping All Tridion services"
  service TC*, Tri* | stop-service -force
  "Doing an IISRESET"
  "Starting all Tridion services"
  service TC*, Tri* | start-service
  "### Done ###"
  set-alias -name kt -value killTridion
  function KillTridion
  "Shutting down Tridion COM+ Application
  $COMAdminCatalog = new-object -com COMAdmin.COMAdminCatalog
  $COMAdminCatalog.ShutdownApplication("Tridion Content Manager")
  set-alias -name upta -value uploadTridionAssembly
  function uploadTridionAssembly {
    & 'C:\Program Files\Tridion\bin\client\TcmUploadAssembly.exe' /verbose config.xml $args[0]

HTML Validation: does it matter?

Posted by Dominic Cronin at Mar 07, 2009 08:25 PM |

Jeff Atwood doesn't think we care if his site validates. Is he right?

In a recent blog post, Jeff Atwood of Coding Horror gives this advice:

  1. Validate your HTML. Know what it means to have valid HTML markup. Understand the tooling. More information is always better than less information. Why fly blind?
  2. Nobody cares if your HTML is valid. Except you. If you want to. Don't think for a second that producing perfectly valid HTML is more important than running your website, delivering features that delight your users, or getting the job done.

It's something of a geek disease to obsess about valid markup, but what does do you get for the effort that it takes to achieve it?

On my current project, we started with a requirement from the customer that the site should validate as XHTML strict. There was some discussion about how much effort this would take to achieve, but in the end we agreed to begin work on this basis, and to take the various difficulties and issues as they came. At the time of writing, we're just about to go into acceptance testing, and the site still validates completely as 'strict'. What has this meant in practice?

Firstly, there have been compromises. Well actually, one compromise of note: the abandonment of using the target attribute to control the types of window used when following different kinds of links. This means that we've resorted to using javascript to open new windows when necessary, and that the small minority of non-javascript visitors will simply find that their browser navigates to the new link in the same window. (Personally, I don't mind that; it simply means that we're regarding popup windows as part of our progressive enhancement strategy. This is reasonable - the native behaviour of web browsers is that links open in the same window - get over it!) The only other thing I can think of is that we're still not sure what the mime-type of an XHTML page should be.

That's the sum total of the differences it's caused from an external point of view. As Jeff says: Nobody cares.

Internally though, as a development practice, it's been pretty useful. Jeff's reasons are good, but I'd add one specific point. Your CSS relies very heavily on the browser being able to validate the DOM correctly. Building in a practice that the developers doing the HTML templating have to validate their output has had a direct impact on the number of CSS bugs and problems that we've seen. This is particularly true when you have cross-browser issues to deal with. The guys are supposed to test on IE and Firefox, but mostly we work in Firefox, and sometimes IE gets forgotten, which usually ends up ten minutes later with someone noticing that the visual output in IE is broken. Validating the HTML from the Web developer plug-in in Firefox is very easy ("Tools-> Validate Local HTML" works very well, as the site isn't currently visible to the w3c validator)

Whenever any issue comes up that's connected with the visual display or layout of the page, the first thing we do is validate it again. Most of the time, the HTML turns out to be broken, and at that point we turn our attention to fixing it. Previously, we might well have invested unnecessary effort on trying to debug the CSS. So in this sense, validating your HTML is akin to paying attention to your compiler warnings. Disciplined developers who keep their output free of warnings, are immediately alerted to real issues because they aren't swamped in the warnings generated by all those things that weren't important enough to fix.

In the grand scheme of things, standards generally help. Long term, and over time, that is. In the short term, well the history of the web has shown that if you need to get results today, well don't wait for the standards to be widely adopted. The downside is that we have to live in a world of browser incompatibilities and just accept the extra work that this causes. So yes, I want to be standards compliant, but only once the standards support the functionality I want to create. Validation matters, in that it without standards, nothing ever gets better, but it costs us effort that may not give us a personal short-term payback. A classic tragedy of the commons.

It's easy to make things bigger; it's harder to make things better.

Posted by Dominic Cronin at Mar 01, 2009 01:10 AM |

Doug Crockford recently said: "It's easy to make things bigger; it's harder to make things better.". I agree.

Read More…

Architects and programmers

Posted by Dominic Cronin at Oct 29, 2008 11:35 PM |

I spoke briefly yesterday with a colleague who is busy setting up a team whose focus will be developing architectural competences within the company. During our conversation, I expressed my view that architecture is a basic core competence for a software developer. I hope I managed to make it clear to him that I do regard architectural concerns as a valid and valuable field of enterprise within the development of software systems, but just in case, and for the record, I'll try to write down what I believe to be the truth about this subject.

Firstly, let's talk about the problem, which is that in the world of computer software, architecture has become rather a loaded term, and is perhaps abused by various interest groups to suit their own ends. This isn't new: for as long as I can remember there has been a sort of job title inflation in our business. These days, it's not enough to be a programmer any more, although once we might have regarded all sorts of capabilities as being implied by the term. (Perhaps programmer just means lowly coder, as though there ever was such a thing. Surely, there are competent programmers and those who are less so.) Then we had to be analyst-programmers (APs), and perhaps the invention of that title meant that programmer didn't imply analyst any more. At some point, people seemed to get the point that unless a programmer was an analyst too, you shouldn't hire him, and the whole AP thing dropped out of fashion.

Nowadays, you have to say software developer, which apparently implies analyst, while maybe 'programmer' didn't. Strangely though, it doesn't seem to imply that you need to understand architecture. That's kind of funny, because the technical career path sort of goes, junior developer, developer, senior developer, architect... Did you notice that? You suddenly transmute from programmer to architect - funny, eh? I can see why this might be. After all - once you are a senior, where do you go from there. Where's your career development path?

In the world of bricks and mortar, no-one calls a bricklayer an architect, but the person who designed the house you live in is almost certainly an architect. In general, the architect is responsible for taking the customer's requirements and transforming them into a concrete (!) building or other such developement. This means discussing the customer's needs, understanding the available materials, techniques, etc., creating a design, and overseeing the construction to ensure correct construction in line with that design. The notion of architecture also implies an overview, and a sense of aesthetics applied to the construction as a whole in the context of its environment.

A bricklayer by contrast, is more of a craftsman. Bricklayers understand things like bonds and cement and gravity and straight edges and so forth. They have technique, but people don't see them as designers, even though they are probably responsible for design in the small. Of course, a computer programmer is a craftsman too; he must wield his programming languages in an artful way, and choose among possible implementations of a larger design.

That's about where the analogy breaks down though. Learning a few programming languages and being able to write in them probably fits the job description of a junior programmer.  Most of the work of a journeyman programmer is far more involved. He talks to end-users, customers or product managers. He understands the requirements and produces designs which reflect the available techniques. This includes far more than simply coding. If we take the example of a programmer working on a typical web application, he may very well produce and implement designs which require knowledge of relational databases and how to produce an abstraction layer to access them, (including perhaps the use of object-relational mapping tools). Then there's probably an application server, transaction management and issues regarding state (or the lack of it). Then there's presumably a web server to deal with, and more choices about statefulness, including session management, and perhaps the need to cluster. Onwards to the network layers, where he'll need to understand TCP/IP, firewalls, proxies of various kinds, DNS, HTTP, encryption and certificate infrastructures, Web services, REST..... We're getting somewhere near the browser now, so there'll be AJAX, Comet, HTML, XHTML, Javascript and CSS browser hacks.

Well I'm sure you get the picture. My putative programmer probably not only has to understand this all on paper, but needs to know how to put all the pieces together with his own bare hands, and we haven't even started on development techniques and methodologies from waterfall to agile, version control, continuous integration, project management, design patterns and how to tell snake-oil from cargo-cult lunacy and both of them from the real deal.

And now after all that, when he finally takes the career step to pick up a business card that says "architect" on it, we shouldn't be surprised that he begins with at least some small clue about what's going on. The strange thing is that when I baldly state my view that architecture is a core skill for programmers, well you wouldn't believe the number of times I get contradicted.

Without a solid understanding of architectural concerns, you are not a programmer. Any real architect understands this, but unfortunately, I've seen far too often the kind of conversation that goes like this:

Programmer: Let's discuss the architecture.

Architect: I'm the architect, why would there be a discussion?

Over the years I have known several software architects who could and did write code to express their ideas and prove their concepts. For these people, a discussion of architecture with a programmer was not a threat, because when the programmer inevitably asked "How does it work?", they would be able to demonstrate,.

Unfortunately, the other kind of "architect" in this scenario usually doesn't have the ability or the inclination to express his proposed architecture in working code. Unless you have the ability to express your proposed architecture in working code, it is supremely unlikely to work. I'd go further than that and say that the best way for an architect to convey his design to a programmer is exactly that; working code. This may be just a basic proof of concept, but unless the architect has written the proof of concept code, he hasn't  done his part of the job yet, and if he has written it, why shouldn't it be a deliverable? You may laugh, but I've observed so-called architects in the wild, and seen technologies selected from a brochure without so much as a trial run, and foisted on programmers, who then had to get everything to work.

You learn software architecture by being a programmer. Becoming the architect doesn't absolve you from maintaining the ability to get it and keep it working. Far from it.

Before anyone goes running off with any strange ideas, let me be very clear. I don't have any problem with software architects. (Some aspects of my work are fairly accurately described by the term.) What I'm railing against is the way that the job title has been assumed by large numbers of people who seem to think that this puts them above the need for achieving technical consensus about what will work and what constitutes good practice.

Am I talking about you? Ask yourself this simple question: Is architecture a core skill for a software developer?

Dam tot dam loop

Posted by Dominic Cronin at Sep 21, 2008 10:05 PM |

As I had hoped, I survived Amsterdam's annual ten-miler, but without being able to claim. as you might say. flying colours. I came in just under 1:28, which is, I suppose, respectable, but still slower than my time from 2005. I'm happy enough with this, as I had back trouble a couple of weeks ago which pretty much torpedoed my final preparations. Better luck next time, eh? Apart from that, the Dam tot Dam lived up to its reputation as a friendly and enjoyable event. The organisation seemed faultless - which is a huge credit to those responsible. The event was won by the Kenyan runner Sammy Kitwara in 45:17.

Here's the record in full, with the official splits at 5km. 10km and 15km

10 miles (16.1 km) - 1:27:57

15km - 1:22:31

10 km - 55:02

5 km - 26:53

Position: 2517 / 7837

The Dam tot Dam Loop is this Sunday

Posted by Dominic Cronin at Sep 19, 2008 05:40 PM |

On Sunday, I'll be taking part in the "Dam tot Dam loop" which is a 10 mile run from Amsterdam to Zaandam. I think it's the biggest running event in the Netherlands. Anyway - I did it once before back in 2005. I've just looked up my result from then on the web site - apparently I did it in 1:24:28. (Isn't that great - that your results from three years ago are just there on the Internet?)

I'll go for my last training run this evening, and then hopefully I'll be ready. I don't expect to do 1:25 this year though. I had back trouble a couple of weeks ago, and I'm just now easing myself back into the running. A nice steady run will be good enough for me.

There will be lots of other good, clean, healthy fun on Sunday too. It's national no car day, and various sporting events will be taking advantage of the fact that some major roads (such as the Amsterdam ring) will be closed.

Listening well - does it come easily to you?

Posted by Dominic Cronin at Jul 16, 2008 10:00 PM |

Ingrid says  "I'm trying to listen better because listening isn't about me. It's about you. And I'm sorry. Does anyone else struggle with this?"

Um... Ingrid - it's not just you.

We're all different. Some people have super-empathy-power and some of us just have to hope we're nice enough as people without that. It's OK.

(Funny though. I'd never noticed.)