Scott Hanselman just posted this: http://www.hanselman.com/blog/FizzBinTheTechnicalSupportSecretHandshake.aspx

My powershell profile for Tridion and general .Net development

# http://www.leastprivilege.com/MyMonadCommandPrompt.aspx
function prompt { "PS " + (get-location).Path + "`n> " }
# http://www.interact-sw.co.uk/iangblog/2007/02/09/pshdetectelevation
& {
  $wid=[System.Security.Principal.WindowsIdentity]::GetCurrent()
  $prp=new-object System.Security.Principal.WindowsPrincipal($wid)
  $adm=[System.Security.Principal.WindowsBuiltInRole]::Administrator 
  $IsAdmin=$prp.IsInRole($adm)
    if ($IsAdmin)
    {
      (get-host).UI.RawUI.Backgroundcolor="DarkRed"
      clear-host
    }
  }
  
  # http://www.leastprivilege.com/AdminTitleBarForPowerShell.aspx
  $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
  }
  # http://www.tavaresstudios.com/Blog/post/The-last-vsvars32ps1-Ill-ever-need.aspx
  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
  kt
  "Doing an IISRESET"
  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]
  }

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

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?

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

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.

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

I'm sorry. This blog and all my web sites have been off the air for about a week. I got overconfident and decided that recompiling my linux kernel would be safe enough to risk. After all - I wanted to enable some features that need to be baked in to the kernel; specifically, support for some virtualisation that would get me out of the open source equivalent of dll hell. In theory, I should have been able to build the new kernel, add it to my boot loader configuration, and reboot the machine. If anything went wrong, well I still had the old kernel, and I could reboot using that in another few minutes.

That's the theory. In practice, I ended up spending whatever-spare-time-a-father-of-three-has for the last week relearning half of what I knew about the gentoo boot process, and then learning some more, and then eventually solving it all by just blindly updating everything and hoping.

I got quite some help from people on the relevant IRC channels (#gentoo and #gentoo-chat on freenode) and in the process ended up explaining to them that I don't believe Windows, Linux, MacOs or any such thing to be superior to the others. It's mostly about what you are familiar with, and I have maybe five years on linux, compared to three or four times that on Windows as a professional. To be fair, such places aren't the sweaty hotbeds of rabid linux-advocacy that you might imagine. Most people have solid time on Windows too, but it's a really hard sell to suggest that usability is even vaguely important. If you can't take the heat, stay out of the kitchen, I suppose....

This one is going round again after Steve McConnell recently posted his regular re-issue of Software's classic mistakes, in which "noisy, crowded offices" is ranked 8th. Jurgen Appelo picks this up and riffs on it a bit in Tear down your cubicle walls, and makes a few nice points. In general, he's on the side of the angels but I disagree with him on a few things.

Firstly, he argues against the claim in Peopleware that open offices are bad for productivity. He's following the fairly standard agilist line about war-rooms; people working on the same project should all sit together. I've had some recent experience of a project war-room proving to be a success, and I've openly advocated this approach, but let us not forget that this is second best. Best - by a long way, is private or double rooms combined with suitable team spaces to allow for collaboration. That's how it's done at the most successful software company on the planet, and they ain't hippies; Microsoft's approach is based on solid psychological analysis of people's work requirements, and computer programmers are classified as "concentrators".  Having said that, their Workplace Advantage programme does seem to include moving non-concentrators out of private offices.

The other point I'd like to pick up on is his "rules" which apparently are intended to make open-plan working bearable:

"No yelling. No running. No meetings (except for 15-minute stand-ups). And no disturbing of people when they're wearing headphones. (Many of us like listening to their favorite music while working.)"

You see this so often. People are forced into working in open-plan offices, and they compensate by wearing headphones and listening to music. It doesn't solve the problem  - it only masks it, and it only works for the people who can put up with the stupidity of it for long enough. Listening to music while working actually steals thinking cycles. You aren't as smart listening to music as you are in silence. Having said that, you are probably smarter listening to music than listening to the hubbub of your colleagues.

In the past, I've tried using white-noise in place of music, but that also has a pretty high vacuum rating.

Bottom line. Rooms are more expensive than open space. Highly valued employees tend to be given rooms. The rest have to suffer the rhetoric of rationalisation.