2006-10-24

Stylistic Perfection

We had a strict style-guide. In the general case, this was a Good Thing. If you have a style-guide you can open a file anywhere in a system and you have a familiar environment, variables are named the right way,

But we also had a strict style that meant a 'normal' PHP source file looked like this (this is an 'include' file, not a PHP script that is accessable via a url).

<?php

include_once($LIB_INC.'stylesheet.inc');

function MainTable()
{
   global $ColC;

   echo "<center>";
   echo "<table>";
   echo "<tr>";
   $ColC->StartTD();
   echo "This is the contents of the table";
   $ColC->FinishTD();
   echo "</tr>";
   echo "</table>";
   echo "</center>";
}

// This line must be the last line in the file with no following whitespace
?>

Well, yes. That's the code. God. I wish that was a joke. Let me walk through a few of the 'interesting' bits here...

<?php was the start of every file. No file used PHP interpolated with HTML code. Ever.

Yes, all HTML was printed using 'echo'. All of it.

Now, $ColC is the doozy. I couldn't make this up. In a database there was a table that included every CSS class we had created, the idea was that you could through a web based form maintain the CSS stylesheets. Every CSS class had styles for things like Table Cells, Headers and Paragraphs. In order to make this easier to use, each CSS class was inserted into the global namespace as a PHP class instance.

'$ColC' was a name that came out of a database and was dynamically assigned to a global variable in order to make things easier.

I had a vim macro that would produce the 25ish style classes that I would put at the top of every function, it saved programmer time in the long run not having to worry about changing 'global $ShadeL;' to 'global $ShadeR' to the top of a function when I wanted to have a shaded table cell that was Right aligned as well as the Left aligned one.

When we had a new employee start in 2003 who had actually used PHP before, he asked, "Why don't we use a templating engine" and was given one of those responses along the lines of, "Be quiet, don't ask questions like that, you don't understand how we do things around here."

He whipped up a system that used a templating engine anyway. He didn't believe that that kind of response really mattered in the long run. Templating systems are just how you write code so that it's not entirely unmaintainable. But no, he was told to rewrite the system to follow the coding standards.

Going back to the example cited above, The last two lines are verbatim what you would expect to see in the codebase. There was a really good reason for this. PHP, if you included a file that output any data, such as a blank line, it would start output to the browser. Once output to the browser was started, then methods like 'header()' which set apache headers don't work anymore, they print an error to the screen (yes, readable by the user of the web application, it was configured so that the error was visible to the user).

If you had a PHP file that ended in "?>\n\n" instead of"?>\n", it would screw up any code that set HTTP headers.

It was 2004 before the innovation of omitting the optional ?> tag was introduced into the codebase. When the unnecesery closing tag was removed the issue was mooted.

So to conclude. You could be satisfied that if you opened any file in the codebase, you were guaranteed to be shown a consistent style, methods named in ways you recognise, HTML generated in the same manner everywhere, and you knew that if anyone deviated from this style, then management would pull them up on it.

And that you'd never be faced with anything newfangled like a template.

2006-10-21

The new critically acclaimed series

Yikes. I'm writing this series on my experiences in hell for myself. It's part of the healing process that's required after living through terrible experiences.

But yow. The response I've received from my readership is incredible:
I want to read more of that.
I figure it's okay to derive satisfaction from your past suffering.
Your blog post is terrifying
Dear sweet lord, i would have killed myself
Oh boy i can tell you've got some doozy entries coming along.
I'm keen to see it, so hurry up with the therapy!
... You are getting therapy, aren't you?

I guess I should start making a few notes and improve my quality of work. My first post was just a ramble about the generalities. There really are some 'doozy' entries in the pipeline.

2006-10-20

First of the Horror Stories

Okay. It's time. I've decided to talk about it.

It's been a long time coming, and some friends of mine have been waiting with bated breath. I'm going to talk about my time at my previous job. I should make it clear to my readers that this is a an accurate depiction of what I was doing. There's no hyperbole, and while I am not going to anonymise anything, I'm also not going to be naming any names that I don't have to.

I really hate PHP. I don't really hate PHP because I read a few lines once and I didn't like the punctuation marks used by the language, I really hate PHP for some really good reasons. The language stinks and I used it for a number of years. Since I started my job in mid 2001 as a casual programmer to when I finished up in Janurary 2005. That's 4.5 years.

I'm going to be writing a series of articles on my time at that job, so I'm going to start with the basics: What was I doing? I was working for a credit reporting agency as a programmer working on their internal and customer-facing web systems. It wouldn't be accurate to call that an 'Intranet' and an 'Extranet' because they were all pointed to the same single webserver.

As a developer, I had a login on that linux webserver, and a series of linux MySQL database servers. There was an Oracle box running SCO unix. I worked on source code using ''vi''. All my coworkers at the time of my employment in '01 were using ''vi'' for all their development because it provided file locking. We all crawled around the same sourcetree simultaneously, and we knew not to edit a file because ''vi'' would warn us.

Of course, no one was using vi, we were all using vim and had been since forever. Redhat ships with a minimal, cut down, version of vim without syntax highlighting or anything useful for software develompent enabled. It was a month or two before I broke down and compiled my own version in my home directory so I could access modern innovations like colour in my editor.

Now, you might be curious as to what we used for source control, or horrified that we would edit code on a live webserver. No, sir reader, we didn't edit code live on the webserver, that would be silly. Each module had a path like /src/modulename/live and a /src/modulename/test and a /src/modulename/dev. Allowing us to edit out code in 'dev', test it, and then copy it to the live tree.

And now, my reader, here is the kicker. CVS was not used. Nor was RCS. No, no source control at all was used. If you needed to revert a file because you fatfingered an rm, you had to go to the IT manager, who was also the sole sysadmin, and ask him to restore it from tape.

I asked repeatedly for ''permission'' to use CVS, and that was repeatedly denied, because the benefit(!?) couldn't be seen, and it was too hard(!?!).

By mid 2004, we had 15 developers, 1 million lines of code in the dev trees, and 800 thousand lines of code in production. Where source control and change management amounted to "Writing your name and a comment about what you did".

I had a few safeguards in place - that is to say, whenever I moved a sourcefile to the live system from the dev system I had a system for doing diffs of the files, unifying them, and when I finally did the copy, I kept a verbatim copy of the live and dev versions, in order to allow me to revert changes. This was of course frowned upon because it meant I had hundreds of megs of data in my home directory and space on the webserver was at a premium.

Blarg. That's the intro.

2006-10-07

I feel my ears burning

It seems there have been a fair number of submissions to LCA about the kind of cat that my submission was about. I have this feeling that my submission won't be accepted.

Not that I mind. I'm not going to LCA to hear myself talk about stuff I know about - I'm going to hear other people talk about stuff I don't know about yet.