GUI versus PUI
Although having failed to stick to my one week old first-thing-Friday-morning blogging routine, I have managed to sit down and start this. If you're reading this on Friday evening (and what else would anyone want to do?) then I'm probably patting myself on the back.
Today I started implementing a new Drupal site. I have some frustrations with Drupal ("Here have a poorly documented associative array. No, really, take one. There's plenty more where that came from.") but I'd be a fool if I denied that it's a very fast way of getting content managed sites done. The main aim at this stage was to get the basic elements together so that the designer could easily see the workflow in action and start thinking about how he could make it look pretty.
So I install some modules. They don't immediately solve my problem. That's not surprising. Module authors are not mind readers. So I try configuring the modules to do what I want. Soon I find I'm wading through admin screens with help from Google. Sometimes I'm really not sure what admin screen I should be looking at. Then it dawns on me that I'm trying to program through a GUI (graphical user interface) and whenever I have that realisation I feel a bit nauseous. I feel disconnected from what's happening in my website and have no clear idea of how long it will take me to resolve the problem.
After a couple of hours I stopped. I couldn't help mentally coding what I'd need in order to accomplish the same thing in Ruby and Sinatra. I've done a couple of webapps in Sinatra recently and it was a joy to use. I felt like a programmer. Mainly I felt like a programmer because I was in charge of the data. In the Ruby world, the majority of gems (the conventional package type, as modules are in Drupal) won't inject markup in to your web page and won't touch a database. Gems are basically tools for input, output, and transformation of, data. By using them, you are using what I now think of as a PUI (programmer's user interface.) Or if you insist on being conventional about it, an API (application programming interface.)
I guess what it comes down to is that I prefer programming to configuring an existing, albeit highly modular and extensible, application. I think in future I'll look for more work that lets me stick with the PUI.