I’ve only been programming professionally for 6 years or so, and for most of that time I was sheltered on my own dedicated server with my own on-call brilliant and hilarious sysadmin whenever I needed software installations and upgrades. Most of the code I wrote was never intended to be distributed. Life was easy.
Over the last year things have changed. I’ve got open source software out in the wild. I’m doing a lot of work for a company with an aging and brittle PHP codebase, and I’ve been deploying a wide array of shared, dedicated and local web hosts. Suddenly portability has unpleasantly forced its way into my life.
Lessons from PHP
Let’s start with magic_quotes_gpc. Even under the assumption that all input from the browser is going directly into a database, it’s still only a marginal productivity gain. The idea that we can protect users from themselves is silly. This is a programming language. You may not be able to shoot yourself in the foot as easy as with C++, but it can still be done, so don’t think you can stop it with a silly hack like this. SQL injections aren’t something that can ’magic’ally be abstracted out of a beginning programmer’s life.
The real evil of magic quotes is that it’s globally configurable. In practice you often don’t have access to the PHP configuration, or you are running multiple applications under the same PHP instance, so portable code must detect the configuration and somehow standardize the data before usage. If magic_quotes_gpc could only be set by an application, this problem would virtually disappear. Developers who valued the functionality could use it, but the rest of us wouldn’t be forced to deal with it. Of course the page-oriented paradigm of PHP kind of breaks this solution down, because you could be including libraries that change the configuration and otherwise pollute the global environment… so really magic_quotes_gpc is just broken within the PHP environment and needs to be gotten rid of entirely. Thankfully that looks to be the plan for PHP 6.
Magic quotes are just an easy target, however. The general issue here is one of global configuration in a shared environment. PHP is the worst because it has the potential to have hundreds of discreet applications and scripts in a single environment (website, web server, whatever). Global configuration options should relate to the environment functionality, not application level details. For instance, options like safe_mode that help secure PHP in a shared environment are sensible. Things like register_globals that just shuffle things around are not.
Lessons from Ruby on Rails
One of the beautiful things about young projects is that they haven’t had a chance to fork or develop a lot of historical incompatibilities. The flip side is a lot of things just aren’t readily available. Sometimes its a library lacking Ruby bindings. Sometimes its basic functionality that has to be installed as RubyGem or Rails plugin. PHP has attempted to solve this by including more and more functionality in the core. But you still run into problems when you need to install an extension or, worse yet, recompile PHP.
A lot of times I’ll be developing on my local box and won’t hesitate to install this or that library to make my work easier. But then all of a sudden I may be faced with the inability to deploy to the chosen environment (shared hosting). Do I give up the functionality? Hack around the problem in my own code? Put in an installation request to the host?
I don’t have any recommendations or solutions to any of these problems. I guess it just goes with the territory. When I can’t choose my own tools it makes me want to give up on client work and just do a web startup. Something with a dedicated server where I can tweak every detail. There’s a lot more pressure to be successful when everything is riding on one app, but I think it could be a lot more rewarding.
Subscribe
Portability
I’ve only been programming professionally for 6 years or so, and for most of that time I was sheltered on my own dedicated server with my own on-call brilliant and hilarious sysadmin whenever I needed software installations and upgrades. Most of the code I wrote was never intended to be distributed. Life was easy.
Over the last year things have changed. I’ve got open source software out in the wild. I’m doing a lot of work for a company with an aging and brittle PHP codebase, and I’ve been deploying a wide array of shared, dedicated and local web hosts. Suddenly portability has unpleasantly forced its way into my life.
Lessons from PHP
Let’s start with magic_quotes_gpc. Even under the assumption that all input from the browser is going directly into a database, it’s still only a marginal productivity gain. The idea that we can protect users from themselves is silly. This is a programming language. You may not be able to shoot yourself in the foot as easy as with C++, but it can still be done, so don’t think you can stop it with a silly hack like this. SQL injections aren’t something that can ’magic’ally be abstracted out of a beginning programmer’s life.
The real evil of magic quotes is that it’s globally configurable. In practice you often don’t have access to the PHP configuration, or you are running multiple applications under the same PHP instance, so portable code must detect the configuration and somehow standardize the data before usage. If magic_quotes_gpc could only be set by an application, this problem would virtually disappear. Developers who valued the functionality could use it, but the rest of us wouldn’t be forced to deal with it. Of course the page-oriented paradigm of PHP kind of breaks this solution down, because you could be including libraries that change the configuration and otherwise pollute the global environment… so really magic_quotes_gpc is just broken within the PHP environment and needs to be gotten rid of entirely. Thankfully that looks to be the plan for PHP 6.
Magic quotes are just an easy target, however. The general issue here is one of global configuration in a shared environment. PHP is the worst because it has the potential to have hundreds of discreet applications and scripts in a single environment (website, web server, whatever). Global configuration options should relate to the environment functionality, not application level details. For instance, options like safe_mode that help secure PHP in a shared environment are sensible. Things like register_globals that just shuffle things around are not.
Lessons from Ruby on Rails
One of the beautiful things about young projects is that they haven’t had a chance to fork or develop a lot of historical incompatibilities. The flip side is a lot of things just aren’t readily available. Sometimes its a library lacking Ruby bindings. Sometimes its basic functionality that has to be installed as RubyGem or Rails plugin. PHP has attempted to solve this by including more and more functionality in the core. But you still run into problems when you need to install an extension or, worse yet, recompile PHP.
A lot of times I’ll be developing on my local box and won’t hesitate to install this or that library to make my work easier. But then all of a sudden I may be faced with the inability to deploy to the chosen environment (shared hosting). Do I give up the functionality? Hack around the problem in my own code? Put in an installation request to the host?
I don’t have any recommendations or solutions to any of these problems. I guess it just goes with the territory. When I can’t choose my own tools it makes me want to give up on client work and just do a web startup. Something with a dedicated server where I can tweak every detail. There’s a lot more pressure to be successful when everything is riding on one app, but I think it could be a lot more rewarding.