Fragmented Development

I ran into a very sticky issue while writing a very complex set of PHP classes: I continually ran into the "Class '[ClassName]' not found" error, even though the classes were clearly defined – sometimes even in the same file. This drove me nuts for hours.

I did some digging into the PHP class documentation, and it turns out that you cannot extend extended classes in PHP, and instead of giving you a helpful error message, it just says that the class cannot be found.

As an example, if you have a BaseClass class, and another class that's defined using NewClass extends BaseClass, you cannot then say ExtendedNewClass extends NewClass: that will throw a "Class 'ExtendedNewClass' not found" error.

I don't think I've found the bottom of this problem, so I'll continue adding any new information that I find.

This weekend I've been able to dedicate some time to revamping the Fragmented Development web site – which really needed it. The layout that has been up since 2005 has served me well, but this one will be much easier to manage.

Also, it is less offensively orange.

I've updated the navigation bar to include some of the new pages, one of which is the blog, which has languished in obscurity for far too long!

More to come...

This is really just a quick piece of trivia, but can cause tremendous problems if you're not expecting it.

PHP does not, by default, call the parent class' constructor when you create an instance of an extended class.

If you would like to have this happen, you must add a manual call to the parent constructor, like so: parent::__construct();.

This caused some very random issues in some of my layout templates, so hopefully I've saved you the trouble of tracking them down. Enjoy!

After recently taking a trip down memory lane with the old DOS-based Id game, Hexen, under Wine. I discovered a very random issue with my installation of Ubuntu 8.10 (Intrepid Ibex): my right alt key didn't really do anything.

I guess I had never used it previously, but in Hexen, alt just happens to be the "strafe" key. This made it extremely difficult to stay alive, which motivated me to find a fix.

It turns out that it's actually a problem with the keyboard layout that was detected automatically. Easily remedied by doing the following:

• Click on the "System" menu
• Select "Preferences"
• Open the "Keyboard" preferences
• Choose the "Layouts" tab
• Select the one you're using - Mine was set to USA automatically
• Click the "Other Options" button
• Expand the "Alt/Win key behavior" category
• Select the "Alt and Meta are on the Alt keys" option

Pretty obscure, and I'm not sure what other side effects it may have, but it did the trick for my particular keyboard/layout combination; I'm using a Kensington K64362 Standard Keyboard with the USA layout.

Hope this helps somebody out there!

Web development is entirely reliant on browsers to display web sites. Without browsers, the large majority of the Internet would cease to be useful – or functional for that matter. So how is it that browsers don't matter?

Each browser has at it's core a layout engine, and this layout engine actually determines what the page displays. While we have dozens of browsers to accommodate, most of them share layout engines. Safari, Konqueror, and Chrome all use Webkit (originally KTHML); Firefox, Camino, and SeaMonkey are all Gecko browsers.

The majority of the layout engines render content according to the W3 standards, and should render your page in a similar fashion. There are very few browser-specific bugs these days, and most of them are pretty obscure.

They have a saying about generalizations, and this one is no exception. Out of all the layout engines, one still remains a thorn in the side of most developers: Trident, the layout engine of Internet Explorer, in use since IE4. I'm not sure if they've actually beaten Trident into shape for IE8 or created a new engine, but it doesn't behave like old Trident. In fact, Trident doesn't always behave like Trident, depending on what version of Internet Explorer you're testing. Each version has their own bugs, some of them show-stoppers, like IE6 's problem with fixed positioning and lack of alpha channel support in PNG images.

Even without IE8, the development landscape is much better than what it was years ago. Instead of checking your page against every major browser available, you can develop a standards-compliant page and make sure it displays correctly in a Webkit-based browser and a Gecko-based browser. Sure, you still have to run it by every version of IE in use, but we're one step closer to forgetting the pain of browser inconsistencies and CSS hacks.

GoDaddy doesn't allow sites to write files to the filesystem using the PHP filesystem functions. This may be due to security concerns, but it put a kink in the comic system. Storing strip images could always be done through the database, but that adds a whole extra layer of complexity and performance drain to the application.

To get around these drawbacks, I ended up using the FTP extension to bypass the Filesystem extensions entirely. GoDaddy allows you to upload your files through FTP, so I created a second account for the site itself to use and funneled all of the files through the FTP functions. I abstracted as much of this as possible, so that if we ever regain the use of the filesystem functions I can switch to those without much hassle.

This method worked incredibly well, considering it was originally meant as a workaround. FTP provides almost all of the basic functionality of the filesystem functions, but it does require the extra overhead of managing a connection and requiring a username and password. I would be interested in seeing if there was any performance cost involved with running through the extra layer of abstraction.

One glaring issue came up while using the FTP functions in place of the filesystem functions: temporary files. The FTP functions (at least in PHP 4) did not really provide a mechanism for creating and working with temporary files. Uploading a file through a form worked flawlessly, and I could manage files that already existed in the filesystem, but creating a new file and then saving it somewhere wasn't really possible. This really interfered with some cool CSS tricks I had planned, and I honestly haven't really figured out a workaround for it just yet.

Again, as someone who manages a server, I can very well see this being a security issue. While I empathize, I also wish there was some way to provide this functionality. If PHP 5 was available, I believe I could have gotten by with some of the newer FTP functionality.

Anyways, if I can get it together to gather the FTP workarounds I came up with into a file that can be included, I may post it here later. Maybe it will be useful to someone?

I haven't posted in quite a while; I've been working on a side project for a couple friends that will manage their new web comic. Feel free to check out the Val'Cielle web comic for yourself.

As with any project like this, I learned some valuable lessons about PHP and techniques for getting things accomplished. I'll be posting these to try to get back into my regular schedule, and hopefully put out some tricks you can use yourself.

One of my neighbors waved hello, and we struck up a conversation. Not an out-of-the-ordinary occurance, but soon the topic swerved to something strange.

"Oh, by the way," she started, "my kids mentioned that they saw a lot of bees around your house when they were getting into their car."

I was rather intrigued - I hadn't seen any bees around, and I tend to notice them pretty quickly. Bees aren't my favorite creature, and I get pretty nervous around them. I asked her if she could point to where they were, and she led me to one of my basement windows. Then she dropped the bomb; "Yeah, they said they've never seen so many bees."

This was not what I wanted to hear, especially not associated with my house. Upon closer investigation, there was a small hole in my foundation, right where the stone met the wood of the house, and every second or so a bee or two would fly in and out. They weren't wasps, and they weren't the angry yellow jackets I'd encountered in the past. They were little brownish bees, that didn't seem to mind that I was standing a couple feet away from them. They looked almost like honey bees... but what did I know?

Not a week later, my apiary ambassador blogged about how she had just gotten a call from someone who had a load of bees in a hollowed-out tree near them. She and a couple others had gone and hauled it off to her house. Since I've heard about how the bee population is on the decline, and gassing the little guys seemed a bit harsh because they had done so little to me, I sent her a message asking if she knew of anyone in my area that did a similar deed.

She responded back with a list of names, and I gave the closest guy - Dan - a call. We discussed the details of what I had, and he concluded that I had a decent-sized hive of honey bees living in my walls. He also let me know that it was important that they pulled out the honeycombs with the hive, because if you killed the bees you'd still have a bunch of dead bees and honey rotting and fermenting in the walls. Not a good idea. He said he'd have to cut open the wall, and that he could be there the next day. He also mentioned that if he said to 'get out' while they were doing their thing, that I shouldn't ask questions. Like he'd have to tell me twice.

That morning, Dan pulled up in a pickup with another beekeeper in the passenger seat. They took a look at the bees coming in and out, and started drilling holes in the siding to see if they could locate the hive. Luckily, the bees had kept pretty close to a single area, so it wasn't too hard. They put on some gear, and started cutting.

Immediately there was a cloud of bees surrounding the guy with the saw, and immediately I was twenty feet away. Like I said, not overly fond of bees, and there were quite a few of them. The picture doesn't really show how many bees were flying around at one time. He started by removing the siding, then a chunk of the exterior wall, and then he started pulling out honeycombs.

Dan brought me over one to show me what they were pulling out. He actually gave me one to keep for myself, so I could get some honey out of this whole operation. This one in particular he rubber-banded into one of his frames for the bees to use. Dan's plan was to set most of the honeycomb into a frame, and let my bees make him some honey over where he lives.

After they pulled out all of the honeycombs, they brought out their - I kid you not - bee vaccum. They sucked up a bunch of them lining the cavity where the hive was, and left it to suck up most of the rest of them while they had a glass of water. Did I mention that this all happened in ninety degree heat?

After they were done vaccuming up most of the bees, they took off the black exterior of their vaccum and revealed a little cage on the inside, filled with bees. "How many do you think are in there?" I asked Dan. "Oh, I dunno, looks to be about ten thousand," he replied cooly.

Holy shiiiit. I had ten thousand honeybees in a two by one foot chunk of my wall, and I didn't notice at all.

With that, they drove off to Sandy's Clam Bar with ten thousand bees in the back of their pickup. I was left with a hole in my wall, and a honeycomb full of honey. Not too bad for a Saturday afternoon.

I browse with an Firefox extension called NoScript, because it's one of the only ways to secure yourself against most of the nasty things that lurk on the internet. Right now, it's almost a silver bullet for web security: it is rather hard to automatically compromise someone's PC without javascript. If you're at all concerned about identity theft or keeping your computer clean, then this extension is for you.

Lately, I've seen a rash of pages that react very strangely in my browser, simply because I have Javascript disabled. Half the styles will dissappear or not be applied at all, the layout will be severely altered, links and navigation are completely broken, etc.

Take FedEx.com for example. With Javascript enabled, you get a reasonably standard web site layout. The navigation, which uses simple drop-down menus, is positioned at the top.

However, when you disable javascript, the menus end up reverting to their obvious unordered list heritage, and overlap themselves quite a bit. Still "useable", but it also pushes the rest of the site off of the first page. You have to scroll down before you can see the rest.

If these items required javascript, then that would be one thing. I can quite understand when an application like Google Maps doesn't work without Javascript or Flash. If possible, I think it's reasonable to degrade gracefully, but that's a topic for another time. Simple drop-down menus do not require javascript and shouldn't use them. It complicates the code behind the page, and slows down the functionality for the client - Javascript is several orders of magnitude slower than CSS.

Xanga is also guilty of this abuse of Javascript. The login box on their main page, a simple HTML form, now requires javascript to submit. A simple HTML submit button can serve the same purpose, yet they feel my browser should have to interpret their client-side scripts every time I log in. I cannot express how irritating this is, and it may cause me to stop using their service.

Please, folks, let's code responsibly. Don't require Javascript to use your page unless it's absolutely necessary. Due to it's malicious possibilities, more and more people will be turning it off in the future. Build your sites so that Javascript isn't a required component, and everyone wins.

Being a web guy in a small government organization, I have limited ammounts of time to put towards each page. The ammount of time I put into a page directly effects how practical it is to create that page; it also effects how much time I have for the next page. The time I take to put up one page has a kind of cascade effect on how much the County can put online. With that taken under consideration, I do not take lightly any technique that saves me time. PsPad, my text editor, has earned a warm place in my heart because of just that: it's full of little time-saving functions that make my life easier.

One of these time-saving functions is an advanced search and replace feature that uses regular expressions (or regex for short). RexEx serves a very specific purpose: it matches patterns in text. Using search and replace with RegEx can make HTML extremely short work, and allow you to convert huge documents into HTML with a couple finely-tuned regular expressions. Who knows, perhaps using this ultra search and replace could even save the day?

This is one way to speed yourself up as a web guy, without growing extra arms or sacrificing sleep. I think I'll post a couple more of these "productivity boosts" a bit later, and hopefully it will help someone out there keep up.

Due to some inescapable conditions we've encountered at our hosting provider at work, we have been cornered into hosting it ourselves. This doesn't bother me one bit, but I wish we weren't trying to do it yesterday.

So, here I am, in the basement, configuring an IIS web server to host multiple virtual sites where once it hosted only one. Not only that, but now we're supporting an additional scripting language (ColdFusion, the rat bastards) in addition to our current ASP.NET and PHP offering. As you can imagine, I'm going to run into lots of problems. I'm going to document them here, so that if there's anyone else stuck in this situation (like me in the future), this might help them along.

Problem 1: "No input file specified" with PHP

I ran into this problem when I tried to change the doc_root value in the php.ini file. Initially, it was set to the web root folder of the main site, because there wasn't anything else. When I tried to move it up one level, I encountered the "No input file specified" error message.

This is probably fixable somehow, but I just commented out the doc_root directive. Works like a charm, no fuss. While this may decrease security some, IIS should enforce directory traversal restrictions. Or so I assume. Or hope, whichever you like. Anyways, cross it off the list!

Problem 2: Connect ColdFusion to a MS SQL Server Express 2005

Since we're a public entity, and because I don't want to pay for the piece of crap that Microsoft's SQL server is, we use MS SQL Server Express 2005 (Extended enterprise deluxe network edition SP3 MMX ...) as our back-end database. Eventually I will convince my boss that a crippled piece of crap software like MS SQL Server Express is not the way to go, and that we should switch to something robust and full-featured like MySQL, PostgreSQL, or anything else really.

Oh yeah, here's how to connect: http://www.fusioncube.net/index.php/coldfusion-sql-server-express. Written for CF7, works for CF8. Make sure to use your server's IP address as the connection string in the ColdFusion settings, not the SERVER/INSTANCE form.

Problem 3: MS SQL Server Development Studio doesn't carry over the "Identity/autonumber" attribute when importing data

Yes, that's right. They don't. I had to enable them manually, which isn't difficult, but takes frickin' forever. Microsoft, get your act together.

This blog, the main site, and many of my other sites are hosted by the "colorful" web host GoDaddy. I use them for several reasons, like reliability (100% uptime on their Linux servers) and their reasonable price. In fact, I have been an extremely happy customer – almost a fanboy – but I have run across a dilemma.

GoDaddy, for some reason, has stuck hard with PHP 4. When I became involved in PHP programming, PHP 5 was still brand new, shiny, and untested. At that time, I would have understood if they chose to stick with PHP 4, because it was the reliable language and PHP 5 was still a tad experimental. But right now, half a decade since I started developing with PHP, version 4 has seen it's last update. We'll be dealing with PHP 6 soon, and it's extremely hard to go backwards. The transition between versions has been such a sea change that you almost need to develop parallel versions of your scripts to offer backwards compatibility.

This is a very specific problem, so I'm going to make an analogy: developing for PHP 4 would be like, in my opinion, running Windows 95 now. Sure, you may be able to do most everything in the old version, but it's like riding your bike backwards and upside down. Possible, but annoying as hell.

To their credit, GoDaddy is planning an upgrade to their platform and I've opted-in to it. However, I'm not sure I can wait for them to catch up. So... do I leave my beloved reliable host or do I stick around and wait?

For now, I'm brushing up on my PHP 4. We'll see how long that flies.

Every once and a while, I allow a page to terminate itself by redirecting the user to another page with the header() function. This effectively stops script execution, because the user is sent to another page, right?

Not always.

If output has been sent to the user ahead of the the header() call, nothing happens. PHP cannot modify headers after output has been sent to the user, so your redirect falls flat. You have two ways to remedy this situation (you can use both if you'd like):

1. Enable output buffering: I haven't tried this one myself, so make sure to verify it works.
2. Explicitly force the script to stop processing using the exit() function

I'm fond of calling exit(), because it stops a script dead in it's tracks without any fuss. If you explicitly tell PHP to quit processing, then there's nothing further to worry about.

Note: Update at the bottom of this post.

After feeling the age of my current PC, I decided it was time for a new build. I built the last couple PCs I've owned, either from salvage or from scrap, and I didn't see any problem with continutng the tradition. After four packages and a couple hours of assembly time, it was complete: my masterful new PC. All that remained was to install the latest version of Kubuntu (8.04 at the time), which was conveniently released that day.

This was a colossal mistake.

I've built half a dozen machines, and more often than not I run into a problem doing so. Something might have been damaged during shipping, the specifications had changed while I wasn't looking - it doesn't matter what it was, but something usually goes wrong. It's part of the territory. You deal with it, and you move on.

The same thing can be said for installing/upgrading to new operating systems, especially Linux flavors. Something usually goes wrong, whether it's a kernel bug or a hardware incompatibility. It's usually best to wait it out, and let the early adopters iron out the bugs.

Apparently, this time around I'm going to have to iron out the bugs. Kubuntu installed, but only after switching to the alternate installation disk. The desktop version kept stalling at the partitioning phase. But with the alternate disk, I was presented with a working system that continued to work until I did something "hard". If I somehow used the processor or memory too much, the system froze solid and eventually had to be manually powered off.

At first, I thought this was a hardware issue. I tried to revert to the previous version of Kubuntu, 7.10, but that wouldn't work correctly with the new video card I was using. As a last resort, I put in Windows XP... which worked after I applied all of the 3rd party motherboard and graphics drivers. I had that ol' sinking feeling... to use my new fancy computer, I was going to have to use Windows.

I have two separate hard-drives in the new system, so the idea was that I would install Windows on the system drive, and keep the data partition formatted in Ext3. I could use the Ext3 driver for Windows until Linux supported my hardware, and then simply format the system drive and install Linux.

So, to format the data partition with Ext3, I decided to install Ubuntu. I'm definitely a KDE guy, but the KDE4 stuff doesn't really do anything for me. I try to take a look at Gnome every once and a while, just to keep up-to-date on it, and thought this would be a great way to do it. Install Ubuntu, fart around a little to get the lay of the land, and then install Windows again when it crashes.

Except it didn't crash. For some unknown reason, Ubuntu is just as stable as can be. I've been working for hours, stressing the system, and it's been fine. I won't have to resort to Windows, but I am somewhat forced into giving Gnome a try. Maybe it's fate (or maybe the LUGradio guys have finally found a way to bring down KDE...)

Update: Ubuntu has also had a nasty habit of restarting the window manager on me every once and a while, completely kicking me out of whatever I'm doing at the time. It looks like, for now, I'll have to run Windows XP on the new PC, and stick to Ubuntu on the old machine for all my work. Now, to try reporting my hardware to the appropriate people...

I've encountered this problem before while writing Javascript, and was recently reminded what a pain it can be to debug. Hopefully these tips will prevent you some strife in your own coding.

Anatomy of the Error

This error occurs when you try and access an object's property, usually with dot notation, when the object does not exist or does not exist yet. For instance, accessing the "status" property of the "window" object looks like this:

var status = window.status;

The problem occurs if the object (in this case, window) doesn't exist for some reason. There are several reasons this might occur.

Mis-spelling

Are you sure you're talking about the right object? If you're trying to write the example above, but accidentally enter the following code...

var status = widnow.status;

...then the browser is going to be unable to find that "widnow" object and will throw that error as a result. Instead of the window object, it thinks you're referencing the widnow variable, which is initialized as NULL and doesn't have a status property.

Page Has Not Loaded

Browsers implement something called "progressive rendering", which means they'll try and display the page as fast as they get it, line by line. If you include your javascript in the head tag, then that code will be run before the browser has a chance to load the body.

If you don't reference any elements specifically, you might be able to get away with this – but you're better off playing it save and having everything run after the page has loaded. Stick all of your scripts in a function or object, and tell them to execute after the page is done loading using something like Dustin Diaz's addEvent() function.

Sneaky Bugs

The bug that got me thinking of all of this was a sneaky one. I had my code wrapped in a function called closeWindow(), that was added at the time of page load using the addEvent() function:

addEvent(window, 'load', closeWindow());

Each time I refreshed the page, I received the "object has no properties" error message. I debugged a little bit, and was able to figure out that the contents of the closeWindow() function was being executed before the page was loaded, even though I went to all the trouble of using the addEvent() function.

The culprit was the extra set of parentheses I added to the addEvent() argument. When you send a function into addEvent() (or any other function, I suppose) as a function argument, do not add parentheses after the function name! Instead of sending the name of that function, I was executing the function as soon as I called addEvent(), before the page had to load. Here's the revised code, that worked like a charm.

addEvent(window, 'load', closeWindow);

I hope this saves some time debugging a similar problem. If you find this useful, let me know!