DREWspective

Just now, at work, I received a "bug" (read: feature request) to add those "are you sure" dialogue boxes to a script.

(If you’re unaware, at the place I’m currently working everything is a "bug". You might work in such a company.)

The prompts would come up when moving and removing items from a category, and it got me thinking;

When are these prompts necessary?

For example, one thing I do straight away on a fresh installation of Windows (after getting the prompt) is to disable the prompt for deleting items to the Recycle Bin. If you delete files one at a time, or in different locations, seeing messages come up frequently can annoy you. When I say delete, I mean delete damnit!

However, there is always a prompt for when I want to delete items permanently; a very critical move, and where I want to be absolutely sure I haven’t made a mistake.

Often, it can feel condescending to be asked if you’re sure you want to close a program or save a file. One good example is in Word, Excel, Photoshop or Illustrator, when you’ve saved a file before printing it - and then get asked if you want to save it again if you close it.

There are some programs that allow you to disable certain prompts, but in my opinion not enough.

I say, when a dialogue box is necessary is mostly up to the user; sometimes they’d just like to get on with things and take responsibility for their actions, while others want to - or have to - be hand held. Either way, there will be those critical occasions where a prompt is necessary.

In contrast to my unfinished rant about Propel, I just love Subversion.

It is, however, a bit of a bitch to get working how I wanted it. Actually, that’s not quite fair; the problem lay with TortoiseSVN, which I shall explain later.

For the uninitiated, Subversion is what’s called a version control program: it keeps track of the different versions of files you manage. Think of it as a kind of incremental backup system, or the Reviewing feature in Word. It’s mostly used for developing programs, and because of the nature of the app, it’s widely used for developing web sites and web applications.

I’m using it for building my project Foley, and so far I haven’t done much with it except try to set it up. It’s primarily a Unix resource, but there are (not very many) ways of setting it up on Windows, provided you have an NT-based operating system (Windows 2000 upwards).

Recently I set up a testing server on my laptop, and wanted to use my main computer as an SVN server. Having installed Subversion and TortoiseSVN on both computers, I thought it would be a straightforward process.

Not fucking so.

I won’t bore you with all the details, but basically the only way of connecting to the repository on the main computer that worked was using SVN from the command line; TortoiseSVN refused to do the work. I’m still not sure why.

The only thing to do now is move the repository to somewhere other than the testing server’s document root. Is this possible?

I’ve wasted the best part of three days, and valuable developmnt time, trying to get Propel to work on my local web server (read: installation of AppServ on a partition other than C:).

For those not in the know, Propel is supposed to be a "object relational mapping" framework, which basically means you can access databases using objects instead of typing SQL. My current workplace uses it in their e-commerce solution, managed by some Unix geeks.

I was particularly excited about using it in my own project: I’ve embarked on a mission to create a portfolio solution, codenamed Foley. I was also thrilled that I’d finally been able to install and use the mysterious PEAR, though there was next to no information about how to do it in AppServ. I wasn’t too happy, however, with the business of trying to find where things had been copied to and how to use them.

Along came Propel, with its shitty documentation, and the horror began. (The documentation wasn’t entirely shitty, but bad enough.)

First and foremost, they mention having to build a build.properties file for your project. Rather awkwardly, they don’t have any.documentation on other, equally bits of important information you could include in the file. Eventually, I found out that there were default definitions lurking in some other folder.

You have to enable a couple of DLLs in php.ini (pdo and xsl). Only after messing around with the configuration files and some frantic searching did I find out that you have to add another one to the list (php_pdo_mysql, if you use MySQL databases) as well. Finally, my schema was turned into classes.

Then came the final nail in the coffin; trying to use the damn thing,

Initially the example given on the Propel Quickstart page didn’t work for me: I had an error message saying that the Propel class wasn’t found. It turns out that giving the right paths to the scripts was so important, it required using set_include_path(). So I added the relevant path to the function (the path to Propel.php) and included it as required.
On the next try, it told me that ‘Clss Item not found)…

Couldn’t be bothered to finish this rant. I’m using something else now.

I’m sat here at work, doing my thing of producing CSS very quickly. It suddenly dawned on me, having looked through a 1300+ line CSS file that I previously created, that even I get confused by the style names I use. In different situations I tend to mix camelcase and lowercase, and the result is usually confusion (and at some point, guilt).

Wanting to be consistent and code in a specific way, I did a quick search on the Internet for established CSS naming conventions. There are none.

I did, however, find an interesting weblog post by Andy Clarke that offered suggestions for common situations. Theoretically it’s very similar to how I name elements on the pages I build, though I use different names:

#wrapper

#header

#logo

#search

#middle

#sidebar

#content

#footer

Basically I usually reserve IDs for layout elements, like the header and footer; everything else is unstyled as much as possible, and uses classes when it’s not.

For consistency, I’ve decided to follow ‘the norm’ (you’ll never hear me say that again!) by using lowercase names with hyphens for spacing. I’ve started to do it now with this CSS, and it already looks a lot more legible.