“Faith is precisely the paradox that the single individual as the single individual is higher than the universal, is justified before it, not as inferior to it but superior—yet in such a way, please note, that it is the single individual who, after being subordinate as the single individual to the universal, now by means of the universal becomes the single individual who as the single individual is superior, that the single individual as the single individual stands in an absolute relation to the absolute. This position cannot be mediated, for all mediation takes place only by virtue of the universal; it is and remains for all eternity a paradox, impervious to thought. And yet faith is this paradox…”

From Fear and Trembling by Søren Kierkegaard.

I’ve managed to improve the speed substantially now, so I thought it was worth recording here the changes that seemed to make the biggest difference. I knew the problem wasn’t a heavy theme, uncompressed CSS (it’s compressed but it really doesn’t need to be), too many images or any of that, so I knew it had to be all those pointless database queries (see here, here and here for details).

Well, it was partly that: removing them made a big difference. But the biggest difference I noticed after a single change (not from rigorous testing, I should add) was when I removed the WP Spam Free plugin. Looking at what the plugin was actually doing on every page load (even with caching), I did have a feeling it would help to get rid of it. That it’s known to be slow is confirmed in a few places online, including here.

I guess the lesson of this is that if you’re using particularly slow plugins, you might not see the gains from WP Super Cache that you’d hoped for.

Greedy for speed, I also removed a few things from the theme, including the Cufon text-replacement JavaScript that drew the headings in the Diavlo font. It wasn’t working very well (there was always a delay) and, although it’s a beautiful font, I don’t think it was right for me or this blog. Nothing wrong with Georgia.

Anyway, soon I’ll be moving this blog to my new host, WebFaction, and it’ll be getting a redesign, along with the rest of my site. I’m at the stage where I’ve designed an HTML/CSS template that I’m very happy with, but now’s when I have to commit to the software, and I’m avoiding facing up to it. Realistically, though, I can’t see myself choosing anything but Wordpress.

“Refining his architecture? What does he mean?” For me, learning to use MODx well has been about working out how to combine templates, template variables, chunks and snippets in a logical and efficient structure. A good application – a small one, at least – should have a shape that you can envision (if you’re the kind of person who envisions shapes, that is). The shape should be pleasing, natural and economical. In my first two MODx sites I fashioned a few butt-ugly shapes that would certainly have sullied the pages of Euclid’s Elements.

They worked, and they were clever in their ways, but I feel I’ve moved past all that now, that I’m approaching the gleaming heavenly realm of the Platonic solids, of perfect dodecahedrons and icosahedrons.

Maybe I make it difficult for myself. Two components that are mentioned so often in the MODx forum and documentation that you could be forgiven for assuming were part of the core itself, are the snippets Ditto and Jot – but I’ve never used them. And then there’s Wayfinder. I used it once, and it was great, but I didn’t really know what I was doing and I wasn’t comfortable with it, and it was a hassle to learn how to use it. In the project I’m on now I’ve just done it myself, with a “menu” snippet and a couple of chunks. I know the boundaries of the project so I can decide to avoid complication by battening things down; and there’s so little code that changing it will be easy in the event that the structure of the navigation needs to change in the future.

Incidentally, Jot and Ditto are often mentioned in connection with blogs, for which they appear to be indispensable in MODx. Well, say what you like about Wordpress but it does blogging pretty damn well and is equally customizable. I fear if I try putting a blog together with MODx, things might get pretty sticky. Even if I was successful I’d still end up with something far inferior to Wordpress. This is a tricky situation, because I really do want to be able to use MODx for blogs – the templating system is close to perfection, and Wordpress’s is horrible. But this is all by the way.

I really appreciate the work that people put in to writing freely available, open-source code. Wonders abound. But I have to confess: I don’t have much patience when it comes to using plugins, widgets, modules or whatever. If I’m looking for one it’s to save time, so 1. I want it to behave roughly as I’m expecting, and 2. I want good documentation, i.e. documentation I don’t have to spend much time with. Otherwise, I’d rather just do it myself, gaining into the bargain the extra advantage of avoiding the overhead of features I don’t need.

In this last project I’ve been working on, the most common type of page required an image gallery to go underneath the main content, and a main image in the body of the content text. Any page of this type could have photos added to it, and they should appear in the gallery in the same format. For the solution I needed: an easy way for editors to add photos without any resizing woes; auto-generated thumbnails; a way of outputting the gallery HTML; some good HTML and CSS; and a nice Lightbox on the client-side.

I had a look around for a plugin or module but it really wasn’t worth the hassle and nothing I found seemed like a good fit, so here’s what I did. If anyone spots a problem in the code or in the concept itself, let me know.

UPDATES & THINGS TO NOTE:

• I’m not aiming here to provide full site-wide image management. For that, something like MaxiGallery might be a good choice, and certainly provides loads more features.
• The plugin might not work in the 0.9.x versions of MODx. I’m using 1.0.2. Thanks to Dimmy for pointing this out in the comments
• The plugin doesn’t seem to work correctly when using the front-end editor
• It’s not included here but I’d recommend checking the size of the uploaded photos in the first place, and you might want to actually resize all uploaded images so as to standardize the “full-size” photos that are displayed in the lightbox.
• The code here doesn’t check for the existence of files, or handle exceptions

What we’re aiming for

Above is an example of the page type in question, with the portion of the page we’re interested in highlighted. By the way, the photos are not at all relevant to the website – this is just for illustration.

This is not particularly relevant to the MODx side of things, but for the sake of completion the image above shows the lightbox that pops up when you click on a thumbnail.

To achieve all this we need:

• A template for this kind of page
• Template variables for the photos, to apply to this template
• A chunk for the outer HTML of the gallery: gallery
• A chunk for the inner HTML: gallery_item, to be repeated for each photo
• A snippet for the body photo: body_photo
• A snippet for the gallery: gallery
• A plugin: thumbnailer, which generates thumbnails, and runs when a document is saved
• Some CSS to style the gallery HTML
• Some javascript to display the full-size images in a lightbox – I’ll use jQuery

Although it might make sense to explain the thumbnail generation first, I’m going to start with the template, template variables, snippets and chunks to demonstrate the output we’re aiming to produce, and from there move backwards to the plugin. Finally, with the MODx side dealt with I’ll say a bit about the client-side, specifically the lightbox for viewing the full-size photos.

The Template

The template itself can be whatever you like, just so long as there is one that you can target the template variables to and which you can use for all pages of this type. The relevant portion looks like this:

It’s not important that I’m using HTML5 (see the <section> tag). But if you haven’t coded in HTML5 before I heartily recommend it – you can even get it to work in IE with the inclusion of a wee javascript file. This is the first line of an HTML5 document:

Beautiful.

The Template Variables

We need some template variables, one for the main body image and one for each photo in the gallery, and the latter variables need to go in a new category, which I’ve called “Gallery.”

In the editor, this gives you something like this:

You may pick up on a crucial implication of this, namely that the number of photos an editor can add to a page is limited, almost hard-coded. I think this is probably fairly standard practice in the world of CMSs, but it went against my instincts: it’s natural to want to provide the flexibility of being able to add limitless photos. But ultimate flexibility is mostly a complete waste of time, and often holds its own problems. So editors will only be able to add eight photos to a gallery. So what? Looking at the requirements, eight was plenty. To paraphrase 37 Signals in Getting Real, it just didn’t matter. It’s amazing the time you can save by making decisions like this.

Anyway, providing for more photos per page at some point in the future would be a simple matter of the developer/administrator adding more template variables.

The Chunks

We need an outer and an inner chunk.

gallery

gallery_item

The Snippets

First of all, some configuration values to be used both by the snippets and by the plugin.

config.php

It’s not very important where this config file lives. Somewhere in “assets” is good. (And if you’re a big fan of config files you could put other things in here, such as the chunk names. Or, now that I think of it, you could pass in the chunk names in the snippet calls.)

The body_photo snippet is pretty basic, and it’s not crucial to do it this way. As usual with snippets I just include a separate file:

body_photo

body_photo.php

All this does is echo out an image tag to the page if there’s a value for the body_photo template variable, and nothing if there isn’t. Crucially, though, the image is not the one uploaded but a resized version held in a folder for the medium-sized images. More on the resizing later.

By the way, get_tv_value is just a helper function which I’ve got in utility.php:

Now for the gallery. Again, in the MODx manager we need to just include our snippet code:

gallery

gallery.php

In gallery.php, line 12 shows why we put the template variables for the gallery in a new category: we can get a MySQL result for the eight variables. Immediately afterwards we loop through that result to build a bunch of list items, each time injecting values into the gallery_item chunk, which is the inner, repeated chunk of the gallery HTML. Each iteration will replace the various placeholders, [+big+], [+title+] and so on, producing something like this:

Notice that the actual image for the image tag is the thumbnail version, and the surrounding anchor links to the original. Also notice the rel=”lightbox” value, which will be used by the JavaScript.

When we’ve got all the list items it’s time (line 41) to inject them into the outer chunk, gallery, by replacing the placeholder [+gallery_items+]. The end result is something like this:

And then it’s echoed out to the page. With all the template parsing done, the HTML that’s sent to the browser will look something like this:

That’s it for the output side of things. But how do we get those thumbnails, and the medium image, where they’re meant to be?

The Plugin

I’ve called the plugin thumbnailer, but it actually does one other thing, which is generate a medium-sized version of the body photo, which is exactly the size required for the page.

As with the snippets I include an external file:

thumbnailer

Notice the lack of PHP opening and closing tags. In plugins, unlike snippets, you always exclude them (and you always forget to.)

The one other thing to do to set up the plugin in the manager is check the OnDocFormSave System Event, as shown below.

thumbnailer.php

My first instinct when writing this was to use the MODx API to get the template variable values, but when the plugin runs it’s too early to do that, so we have to use $_REQUEST to get the form values directly from the editor. The naming scheme for template variable input elements is “tv[template variable id],” e.g. in my case it was tv9 to tv17 for the gallery variables.

For the thumbnails, we can get the same MySQL result that we used for the snippet (line 21), and then in the loop, concatenate the input name using the template variable IDs (line 28). For the body photo, we can get the name for the input by first getting the ID of the body_photo template variable based on its name (line 37).

For the resizing itself, I’ve used a small class called ImageHelper, which is kindly provided here at Tips for Twits. I’ll include the code here for completeness:

ImageHelper.php

It takes care of cropping and resizing very nicely, and is the simplest and most effective code for this kind of circumstance that I’ve found.

So let’s say an editor has their document looking like this:

In the file system, the result of saving this document will be the following (with all other files excluded).

Client-Side

It’s a simple job to style the HTML output with CSS, so I won’t cover that. So, let’s briefly cover the lightbox. First it needs some CSS like this:

Recall that in the gallery each list item’s image link has rel=”lightbox”. We can use this in following code, which, aside from its dependence on jquery, is the entirety of the lightbox script (it doesn’t work in IE6 though, last time I checked – some tweaking required for that).

Click on the photo below for a demo.

So there you have it. I hope you find it shapely, pleasingly simple, and easy to maintain.

My first MODx-powered website went live today (Pinnacle Telecom Group plc), and my intention now is to share some of my experiences. From a development point of view MODx is so flexible that there are several ways of doing most things, so if like me you constantly fret about your architecture and constantly refactor your code for re-usability, you might be confused about just what is the best way of doing things, especially if you’re just starting out. So in this and forthcoming posts I’ll be discussing some of my development techniques.

This post is mainly an introduction to the ManagerManager plugin written by Nick Crossland. In my opinion it is absolutely indispensable, unless you’ve come up with your own way of doing the same thing. But it took me a while to get it. It’s possible I was just having a stupid day, but on my first encounter with it I was puzzled and frustrated for a while about how and when to use it, so maybe I can plug some gaps here. Let me just say again that this plugin is absolutely indispensable. Well, I guess you could get by without it, but at the very least it’s very excellent.

Essentially, it allows you to control how resources (also referred to as “documents,” mostly corresponding to web pages) are edited, depending on the role of the user and/or the template used by the resource. Using it you can customize and control the user-experience for content editors by changing, in several ways, the document fields and template variables that are available to users editing a resource. And you do all this by defining “rules” in a single rules file or chunk.

Install

Before I go into what exactly you can do with it, here’s how to set it up. ManagerManager came bundled with my MODx 1.0.2 installation, but you can also get the package from the MODx website. The two things to look out for in the download are plugin.txt and the managermanager folder. Put that folder in yoursite.com/assets/plugins and go to yoursite.com/assets/plugins/managermanager/docs in a browser to read the documentation (you can also see it here on my site if you haven’t downloaded it yet).

In the documentation you get details on installing and setting up, but I’ll briefly go over the steps here. Basically all that’s left to do at this point is to create the plugin in MODx with the contents of plugin.txt. Go to Elements > Manage Elements > Plugins > New Plugin and paste in the code, then check the System Events described in the docs, and then paste in the configuration string in the Configuration tab. The string looks like this:

By the way, if you’re not aware, configuration parameters are defined like this:

So in the configuration string for ManagerManager given above, it sets up a text-field parameter called config_chunk but leaves it blank. If you want to use a chunk to manage your rules, put the name of it in here. My MODx installation already had the chunk mm_demo_rules.

When the plugin runs, it looks for rules in the chunk that you’ve defined in the configuration tab, but if that chunk is empty or nonexistent or not defined in the configuration tab (as in my case), then it looks in the file managermanager/mm_rules.inc.php. I use this file for my rules rather than a chunk, but it’s a matter of taste. Note that if there’s something in the chunk (and the chunk is defined in the configuration), none of the rules in the file will be applied, because the file won’t even be included.

The Rules

So what do the rules actually look like? Basically they’re function calls. All of them are described in the documentation, in the Fields, Tabs, Widgets and Sections pages, and the names to use to refer to the fields are described in Field names. Note that the although these field names mostly correspond to the MODx database field names, not all of them do.

Here’s an example rule:

Your rules file or chunk is just a bunch of these calls, and every time somebody edits a resource, they will be applied. Easy.

Hiding Fields

You may want to hide fields from users who are editing certain resources, because you don’t want those values to be changed. Say you want to fix the value of the parent resource, or you want to ensure that Show in menu is always set to true and can’t be changed. Or maybe you just don’t want to confuse users with too many fields (if there’s no need for them to see the URL alias or Link Attributes fields, why not hide them?).

One of my uses for this is hiding the resource content editor for templates that contain only dynamic data such as tables, feeds, blog post excerpts, and so on. For these pages, all the content is generated by snippets, in combination with chunks, and anything entered as content by the user will not show up (because in the templates and chunks I’m not using the [*content*] field at all) – so it makes sense to remove that functionality.

Setting Default Values

You may want to ensure that certain resources always have the same default value for particular fields. I used this recently when I wanted to set the value of content-type to application/pdf by default. I saw this as a must-have feature, rather than a nice-to-have, because one of the main ongoing actions of editors of this site was to add new PDF documents, the links to which would then be displayed by a snippet in various parts of the site.

Incidentally, this only made sense if I could make sure that the resources in question had a specific default template, so I also used my own plugin to automatically set the template for these resources. I didn’t realize at the time, but I probably could have used an MM rule for that too, namely mm_hideTemplates (see below).

Renaming Fields

Renaming fields changes their labels. One way that I used this was to change “Long title” to “Page heading,” because that’s how I was using [*longtitle*], i.e. as the <h1> heading (in other words, in the relevant chunk I had <h1>[*longtitle*]</h1>). Changing the label just made it clearer for users. The flexibility of MODx means that, by default, fields are named in a fairly abstract way, because you can use them however you want, so more meaningful labels are often better, once you’ve settled on how you’re going to use them.

Changing the Help Text

This way you can help to tailor the user’s experience to the specific functionality of your implementation. If you’ve customized things to a great extent, some of the help text will begin to be useless or even misleading, so it’s good to keep things tight by paying attention to stuff like this.

Synching Fields

Use this to ensure that fields always have the same value. I haven’t used this myself, but I’m sure I will.

Inheriting Values From the Parent Resource

Does what it says on the tin.

Hiding Templates

The above example removes the (blank) template from the Uses Template drop-down. As I noted above, it looks like I could have used this when I needed to set a default template by hiding all the other templates from the drop-down list, instead of using my own plugin. I haven’t tried it though.

Tabs, Widgets and Sections

There are also a number of functions for changing the tabs and sections. For example, if you want to restrict users to editing the content field and nothing else, hide the Settings tab as well as hiding fields in the General tab. Sections, by the way, are a MODx way of grouping fields together in the edit screen. Common ones you’ll see are “Resource content” and “Template variables.” As for widgets, ManagerManager provides a few functions for changing the widget that is rendered for a field, eg. colour-picker or image preview.

With careful combinations of rules, and any logic you fancy putting in the rules file, you can get as clever as you like.

For more information on ManagerManager have a look at the dedicated board on the MODx forum.

For the next MODx-related post…I’m not sure. One thing I’ve found interesting: I struggled for a while to find a satisfying way of combining two requirements regarding javascript. 1) How to manage and maintain my javascript files easily and avoid any duplicated code; and 2) also ensure that the resulting page is optimized for speed (sometimes I find it quite hard to settle for a YSlow grade of B). I’d love to see how other developers manage this in MODx.

This javascript/jQuery code gets the contents of your cart (which is in the variable fc_json, made available by foxycart_includes.js), removes any item whose name matches a certain string, and then adds your new item. It looks so obvious now, but it took a while for me to get it.

I’m working on a shopping cart at the moment, and it’s my first day with FoxyCart, which is a really nice solution for a common but pretty badly-catered-for requirement (ie. online shopping carts and checkouts). I wanted to just plug and play: just set up a few templates for the cart, checkout and email receipt, and go with that, because FoxyCart is pretty nice without too much customization. But things are rarely so simple. The website will be selling not only products in a shop, but registrations to an event. Yep, that’s still easy, but a registration can be for multiple attendees, and the registrant needs to fill in the same information about each of them as he did for himself, and some of that information determines the price.

So the registrant’s gone through the whole process of filling in the forms for each attendee, and they get to their registration summary page, and there’s a list of the names of the attendees with the cost for each one (which depends on what information was supplied, what boxes were ticked), and a grand total at the bottom. This is all before they get to the shopping cart. It’s true that when adding to the FoxyCart cart you can supply it with options and corresponding prices, and this would have been good for allowing for the selection of multiple attendees; but it wouldn’t have allowed for the entry of all the attendee-specific details and their corresponding prices.

A Problem

So they hit “Add to cart” and then “Checkout” and everything’s great – if that’s the only thing they do. But what if, after adding the registration to the cart, they go back and change the details for an attendee, thereby changing the price? First of all I set the quantity_max parameter to 1 to prevent them adding it twice. But if what you’re adding has a different price, it’s treated as a different item. If they click to update the cart with a registration that comes to a different price from the one they previously added, the amended registration is added as a new product, so that they now have two in the cart.

It seems odd that FoxyCart gets stuck on this, and I thought there must be some parameter I could use, but I couldn’t find it. The solution had to be to either somehow update the price of the item in the cart, or remove any registration in the cart before adding the amended one. I ended up using the latter. To do it requires JSON AJAX requests, which you can do in jQuery with $.getJSON or $.ajax. Anyway, I quickly arrived at the essential logic on which the above code is based. But I couldn’t get it to work.

I was led first of all to use the fc_PreProcess() function. From reading the documentation it seemed that I should define a function called fc_PreProcess, put all the code inside that, and then the included FoxyCart javascript file would find my function definition and execute it prior to adding anything to the cart. Sounds perfect, I thought.

Here’s how it didn’t work. You add a registration to the cart, close the cart, amend your registration so that it now has a new price, and then add to the cart again (although as far as the user is concerned they are updating the cart), at which point the new one should be substituted for the old. And at first it seemed to work: only one registration item in the cart, and with the new price too! I cheered at the time, until I clicked “checkout” to find that the item had just fallen out. And doing it all again I saw that in the cart itself the item would disappear if you refreshed it.

What seemed to be happening was that even though the item was displayed in the cart, it had since disappeared. The item was being removed after it was added; more precisely: a new one was added, making a total of two items; the cart was displayed; and then my code found and removed both items. I’m still not quite sure how this happened, but blame may lie in the asynchronous nature of the JSON calls, mixed use of http and https, sessions, or in my lack of sleep.

A Solution

So what you see above is the hand-made solution. The “add to cart” or “update cart” button on my registration summary page doesn’t submit the form, it just executes the function add_pre_process(), which looks for an existing registration and removes any it finds; and then adds the new one. There is a separate “View cart” button.

Ideally I would have liked to use the success callback of the ajax request in add_item(), but it doesn’t fire.

So, the problem seems to be solved, but not properly solved. The question now is do I spend time investigating what the problem was and delve deep into the workings of FoxyCart, or move on to the next stage, which is the shop. Well, I’ve got two websites going live in the first week of January, so it’s no contest. Onwards!

Anyway, my first intention was to stick with PHP, so I was led to have a look at the CodeIgniter framework after I watched a couple of excellent tutorial screencasts by Jeffrey Way on nettuts. But then I discovered Kohana, originally a fork of CodeIgniter but apparently better in several ways. Last time I checked, CodeIgniter was very PHP4-centric, whereas Kohana is most definitely a PHP5 beast, with all the OO stuff that entails.

I haven’t been able to use it in anger yet, but I’ve set a few things up with it, and it gives me a nice warm feeling. It seems really lean and simple and built in the right spirit, and it didn’t take me as long to get my head around the MVC pattern as I’d expected.

The thing is, now I find my thoughts drifting into alien territory…

This goes back to my previous post about web development choices. The more I look, the more confused I become. I wouldn’t consider anything Java or .NET, so in the area I’m looking at the big [puts on suit and pulls a sombre, earnest expression] SERIOUS frameworks seem to be Ruby on Rails and Django. I’ve been trying out Python with the Google App Engine, and I forgot how great it was to learn a new programming language, so Django – a Python framework – looks like a good way to go. But something in me cries out NO – do I really need all that stuff? Look, there’s this guy over here says Django’s too big and bloated; but wait, there’s that guy over there says with Django he can spit out ten amazing websites every day.

But coalescing out of my confusion is the perception of a contrast in the community, and for those who build websites and web apps it’s good to be aware of this. On the one hand there are those whose overriding concerns arise from their work in creating and maintaining the frameworks themselves; and on the other hand there are those who just want to make websites. This became obvious to me after watching two video talks from DjangoCon 2008 (yes, I’m still catching up with all this), one by Mark Ramm, one of the guys behind TurboGears (another Python framework), and the other by James Bennett, one of the Django guys.

Now, I’m aware that the subjects of these talks were quite different, and pitched at different levels, but nevertheless I do think it’s fruitful to compare them.

Mark Ramm seemed most interested in guiding the philosophy of the Python community, about the future of Python frameworks and how they should be taken forward. In particular he criticized the “monolithic,” all-things-to-all-people approach of Django, opposing it to the Turbogears/Pylons approach, which is to open things up, to make it easy (even necessary) for developers to grab this bit here and that bit there and carefully craft an optimal whole. His standpoint reflected his immersion in developing for – or the development of – web app frameworks.

James Bennett’s focus was on developing with frameworks – that is, building web applications – rather than on how best to build the frameworks themselves. He talked about the most efficient ways to approach the development of an application using Django, for maximum code re-use and maintainability.

Of course, these are not implacably opposed positions: it’s just a difference of focus. Both may be right in their own ways, but as a freelance developer of – currently – small to medium websites, I naturally find James Bennett’s focus on the day-to-day business of making a web app much more appealing.

It might be true, as Mark Ramm says, that you don’t get perfection by installing everything in one bundle and just running with it, but to me that’s rather academic. Everyone is agreed that the purpose of frameworks is to free us from the boring repetitive tasks of this line of work. We shouldn’t have to even think about admin interfaces, form-handling, nice URLs, templating, or ORM data-mapping. But further, I just want some one thing that does all that pretty well. If I have to pick and choose between different combinations, and try to get all the bits working nicely together, then I’m thinking about it: I’m wasting my time. I don’t want to think about the optimal key set-up of a saxophone – I just want to make music (is that a cheesy analogy?)

Before I realized this I struggled to stay a course through the choices facing me, taken first in one direction and then another, each with its own passionate and persuasive adherents. But now, even if the two approaches I’ve perceived are just sides of the same coin, I can use this idea of a dichotomy to sort and prioritize the opinions I find.

However, I now find myself considering having a go at building a web app with Haskell, a functional programming language beloved of geniuses, hippies, mad scientists and my good friend Paul Keir (who might fall in all three of those categories). The introductory message at haskell.org has the words ADVANCED, PURE, CUTTING EDGE, RESEARCH, CORRECT, and PARALLELISM (eh?). That’s all a bit scary to me.

Much of the pleasure is the spectacle of all these Viennese doctors revelling in the exciting new theories of psychoanalysis, sharing their little anecdotes. Writing about inadvertent actions and how they can reveal unconscious motives, he quotes another psychologist:

“I entered someone’s home, and gave the lady of the house my right hand. Oddly enough, in the process I untied the bow holding her loose morning dress together. I was not aware of any dishonourable intentions, yet I had performed this unskilful movement with a conjuror’s sleight of hand.”

For years I would sometimes have bad moods of a particular kind, and during those moods my thoughts would turn to violence. Sometimes while walking in town on my way to or from work I would slip into a self-righteous rage, but lacking a very good reason for it I would fantasize about people offending me more than anyone in fact was doing, and about what I would do to them if this happened (normally involving a beating of some kind, but nothing so bad as murder or the inflicting of permanent injuries).

Occasionally I would get a nasty look from a driver as I crossed a road too slowly for their liking, and that would set me off on an internal rant about arrogant BMW drivers. I would imagine that they had been much more obnoxious than they had been, and fantasize about causing damage to their car by kicking it or launching my umbrella, like a javelin, through the back window as he drove away.

It never occurred to me in those moments that my thoughts were unreasonable, and later, when I had calmed down, I would not think about it again. Such was my lack of self-awareness that I didn’t even begin to look for reasons, and thus missed the obvious. Over the past few years I have pinned down the cause of these moods: nicotine withdrawal. I felt those feelings when I hadn’t had a cigarette for a while.

The realization began when I gave up and used nicotine gum as a replacement, after initial scepticism about its efficacy. Varying the amount of gum I chewed in one day, I began to see how my moods were changing. It’s old news, but I had not appreciated, or not believed, that my addiction was mainly chemical. I imagined that I somehow transcended chemistry, controlling my moods and behaviour with conscious mastery, that until then I had chosen to keep on smoking, free of any base animal influences.*

I honestly never understood what people meant when they talked about the effects of coffee or sugary foods. I thought that I was always in control, and I didn’t notice how my body and mind changed with the action of these substances. The main exception is alcohol, the effect of which is so overwhelming that it cannot be ignored even by me; but I suppose I always viewed it as something special, something extraordinary. I completely failed to notice the more subtle changes.

Now I’m reading Freud, and the explorations into my self continue. Not only does he reveal another hidden influence that I had never taken seriously, partly controlling my behaviour and thoughts, namely the unconscious mind; but this also prompts me to ask why I, normally an introspective and thoughtful person, would fail to see the obvious chemical agencies causing my mood swings. And this leads me to the idea that there is some combination of complexes within me that obliges me to ignore the evidence. For some reason, I do not want to face the facts of my biology. Related to this is my complete lack of interest in epilepsy, despite the fact that 1. I have had it since adolescence, and 2. I am normally very interested in neuroscience.

Before reading The Psychopathology of Everyday Life I was quite unfamiliar with Freud, except for the more or less vague references that appear throughout our culture. I had read an excerpt from Civilization and Its Discontents, and I was fascinated by it, but I didn’t really understand it because all the theory was out of context.

The honesty and humanity of the man shine through in his writing, and he has pretty much won me over. It was just the same with Ernst Gombrich and Jacob Bronowski. The experience of reading Freud is similar, because of the serious, unpatronizing, liberal and rational attitudes that they all share.

Over the past few days I have bashed my hand on a particular door handle in my flat, on two separate occasions, never having done it before. Wasn’t it just simple clumsiness? I do sometimes have difficulty resisting the temptation to pronounce “oh come on Sigmund, that’s a bit far-fetched,” but on the whole I’m beginning to appreciate how great he was, and I plan to go into this more in later posts.

*Another surprising thing I discovered when I began to chew nicotine gum was that the dominant taste in cigarettes, and the slight feeling of burning in your mouth, is not, as I had presumed, from the hot smoke. It is the nicotine itself.

1. My observations on Freud’s Psychopathology of Everyday Life (boiling down to my realization that I’m a tangle of complexes, but also that I’m actually doing alright and won’t be running to an analyst any time soon)

2. A vague and geeky ramble over the broken, scarred and unstable terrain of web development.

Since moving this blog over to my website, I’m conscious I may be losing those who enjoyed such posts as Sweaty Rectangle and My 25-year-old Earworm, but the geeky ramble won out this time. Bear with me though: I am large, I contain multitudes.

Though I’ve been doing web development off and on for ten years, I’ve never been as enthusiastic about it as I am now, having begun several months ago to work for myself. After a couple of years gripped by saxophone and camera obsessions, I’ve now succeeded in bringing my web knowledge up-to-date, and it’s dawning on me how many choices I have about which path to follow. Faced with these I ask myself: what is it that drives my enthusiasm for web development, and how should that influence my choices?

With quite a few projects on the go or about to start, recently I’ve been having to choose between different tools. If we assume that all these tools are, potentially, equally powerful, still there are other considerations beyond economics, development time and learning time. There is the consideration of how much a particular tool fits well in my hand and allows me to work as well as I can, that is to say, allows me to enjoy my work. But I’m getting ahead of myself…

Guided by Mother Microsoft

In 1998 I started out with classic ASP, and just when I’d built up a nice collection of functions and snippets and settled down to an efficient way of working, ASP.NET came along. I’d like to say that it rocked my world, but it was more like upsetting the apple cart. It all seemed so unnecessary, so restrictive, so complicated, yet so unavoidable for a web developer using Microsoft. I didn’t really get it. True, I did some cool stuff, such as a system combining a Windows mobile app and a web app, with MS Exchange integration and XML web services and signature capture and GPRS and all that – but I was never comfortable with the framework. I yearned to get back to the freedom of scripting with notepad, without all the junk.

Now I won’t claim that my distaste for .NET was purely technical or aesthetic: for me it still has associations of the corporate world that I’m very glad to have left. It always represented a straightjacket to me.

Personal Home Page, I mean, PHP: Hypertext Preprocessor

So when I discovered PHP in my spare time a year or two ago, I smelled the fresh clean air of freedom.*

But things were pretty messy to begin with. Seeking more efficiency and tidiness, but repulsed by the baggage and complexity of many of the feature-laden templating engines and CMSs (not only sledgehammers to crack nuts, but sledgehammers that are very difficult to hold and which fall apart for no apparent reason if you don’t hold them in a certain way), I began using a templating system called TinyButStrong. I was very happy with that (and I’m still very fond of it) until a few months ago, when I began to pay more attention to all the web technologies that were popping up (or which had popped up without my noticing.)

Coming of Age

In my work I was being faced with the same tedious tasks again and again, such as forms and validation, administration interfaces, and content management; and coming from ASP.NET I knew that there were tools out there that would help me with all that, that there had been a whole movement towards frameworks going on for years, which aimed at relieving developers of all the hassle.

However, my priority was getting my front-end skills up-to-speed with the bleeding edge of CSS, javascript frameworks, AJAX and so on, so until quite recently I carried on as before with the PHP. But now all of a sudden I’m working with (or at least playing with) MODx, Kohana, Wordpress and now Python and Google App Engine.

I’m using the MODx content management system for something right now, and it’s superb. For building websites it’s quick, flexible, limitlessly customizable, and I have almost nothing but praise for it so far. But sometimes it just doesn’t feel like real development. If you’re a coder, you write plain old text in some fancy version of Notepad (or even Notepad itself), and there’s something about having to use a CMS interface that is alienating. Although I can set things up in MODx so that I’m using include files, I still feel removed from the PHP code, the HTML and the CSS.

As for Wordpress, it’s great, but I don’t feel like I’m building something, more hacking something together.

Clients

As an aside I should say that clients don’t care about all this, and neither should they. I’ll continue to use MODx and Wordpress because of the convenience and speed of developing with them, and for the easy content management they provide for clients. But no, what I’m on about here is how it feels to use these tools, and hence about how I can achieve a harmony between my instinctual way of working and the jobs I have to do.

Oh and as it seems to be the fashion these days for web developers to proudly proclaim “I love my clients,” I’d better point out right now that I love my clients. I do, really.

I’m a GAEboy

So I’m strongly drawn to, rather than CMSs, frameworks and new languages. I’ve recently been seduced by the Kohana PHP framework, and by Python on Google App Engine, and they do satisfy my desire for control over, and intimacy with, the code that makes up a site or application. Kohana because for me it’s an introduction to the MVC paradigm, and simplifies those horrible tasks I referred to above; and Python with GAE because not only am I learning a real proper all-purpose language, but I’m entering the world of cloud computing and non-relational datastores, leaving the world of server configuration, architectural compromises and unwieldy file structures. Oh and there’s the one-click deployment.

The question is, what’s the best path to take? But it’s mostly a rhetorical question. Obviously only time will tell. But the conclusion I’m tentatively driving at is that even if the toolbox I choose might not be full of explicitly labour-saving gadgets, I will end up working more efficiently if they feel better in my hands. My girlfriend Laura has a little wheeled gadget to chop garlic. I like using a good sharp heavy knife. For me, it just feels right. I believe that little things like this are important.

Now, if I can actually find the time to get something up and running on GAE beyond this tutorial; and if the project manager in me (who is admittedly quite ineffectual) can resist the temptations of MODx and Wordpress for my next big website project, and choose Kohana instead; well, maybe then I’ll be in a better position to answer all these questions with something other than waffle.

*Incidentally, I happened upon a fight between the .NET and PHP tribes in the comments of a .NET tutorial on nettuts. One of the comments was “PHP is ok for your Mum’s embroidery page or a pointless blog that nobody will read, but if you want to be taken seriously by Corporation X, then it’s got to be .NET” (I’m radically paraphrasing, but he did use the term ‘Corporation X’). I didn’t reply to him because I had nothing to contribute relating to the tutorial, but I did feel like saying, well, yes, if your ambition in life is to work for Corporation X then perhaps .NET is the way to go. For the rest of us, PHP is just fine, thanks. That probably would’ve been childish.

UPDATE: I should point out that ASP.NET has come a long way since I used it. Specifically there is ASP.NET MVC, which I gather is a vast improvement on Web Forms, which I really didn’t take to, to put it mildly. Now I think about it, I was very happy using .NET for Windows and mobile development. So maybe ASP.NET is worth a look now that it’s possible to avoid Web Forms. These days there are some nice free development tools available, and you can even use Python. However, I’m having difficulty enough with the choices I have so I don’t want to complicate matters.

ANOTHER UPDATE (Jan 2010): Never mind Kohana, I’m moving straight to Django!

This is a taster of what’s to come in a few weeks. I’m building this website, for the Scottish Golf Heritage Festival, with an array of incredibly useful components and features: I’m using the MODx content management system, FoxyCart for an integrated shop and registration process, and a wealth of snazzy (I’m certain I can make that word cool again) rich interface components. I’m particularly looking forward to building the graphing functionality for the admin system, for which I’m probably going to use the gRaphael javascript library.

The holding page, two screenshots of which are shown above, is the result of a lot of work in establishing the general layout and style of the forthcoming site. It combines several approaches to web design, having elements of both fixed and fluid styles. Using the background photograph effectively was quite a challenge. It would probably be fruitful to break down the CSS and go through it here, but maybe next time. Ciao!