Price of learning in an unrestricted environment

This may or may not be an allegory about teaching methods.

Here’s the story:

If there is anything that I’ve learned about developing applications with PHP, it is that when developing an application in PHP, there are a multitude of factors to take into account not only about the programming language itself, but also the operating environment. These can create hazards and bad habits when someone is learning PHP at the same time. It can also severely affect the ability for an application to be “portable” even though your not really porting anything. You would think that PHP is PHP, and if a web application works on one web server with PHP, then it should work seamlessly on another server.

It’s the same language on both machines after all.

At work, when we decided to start developing web applications, we decided that the easiest and fastest way to start developing was to purchase some web-hosting offsite so that we could start coding, while leaving the major decisions (purchasing a server, where to put the server, who would administer it, et cetera) to be hammered out. This was a good idea, because it allowed us to start right away, rather than getting bogged down in red tape.

The problem was that a lot of the PHP environment that we developed in that was offsite was very unrestricted. Things in the PHP environment were turned on, such as register_globals and session handling. The upside was that these settings allow people to quickly write PHP code and not worry about a restrictive environment, as well as allowing new customers to bring older PHP applications over without worrying about going back and having to rewrite old (possibly bad) code.

By time we got our own server and began installing the necessary tools to run our PHP application onsite, we realized that there had been some serious problems with the way we had designed our code. We had taken the unrestricted PHP environment offsite for granted, and the default PHP installation and environment was much more restricted compared to the offsite. So in addition to learning PHP as a language, I needed to quickly get a grasp of the PHP environment and how the entire system interacts. I wasn’t able to be insulated from the server environment and concentrate fully on the code. I had to simultaneously improve the code, as well as attempt to configure our own server so that the code would work.

Lots of dependencies (was it the code that was wrong? was it the server configuration? was it both? was it neither? am I going INSANE?) but I didn’t want to just unlock everything in the PHP environment because that would create plenty of security risks, that we didn’t need to take. The downside of this whole situation was that there was no expert to rely upon to help our group out. We had to learn as we progressed, and much of that learning was based upon trial and error.

The immediate lesson is that it’s much better to start with a very strict PHP environment because it teaches you good programming practices and prevents you from relying on crutches like register_globals that could come back to really make life difficult when you attempt to move your code.