This blog has had a variety of homes over the past few years although you wouldn’t know it by looking at it. Initially it was hosted on a Windows 2008 server I built myself, sitting behind the tenuous link of my ADSL connection. Don’t get me wrong this is a great way to get started if you’ve got admin roots like me but inevitably my ADSL connection would go down or people would just plain give up waiting for it to load, what with my upstream only able to handle 100KB/s. Still for most of its life the blog remained in that configuration as I couldn’t find a hosting provider I was happy with.
Of course the day came when WordPress decided to stop playing nice with IIS and started returning internal server 500 errors. Thankfully it would usually right itself after a reboot but it was always a count down to the time when it would start erroring out again and being the busy man that I am I never had the time to troubleshoot it. Eventually I caved and set up an Ubuntu box to host it, figuring that all my woes would be solved by switching to the platform that everyone expects WordPress to run on. I’ll be honest it was a good change as I could finally use all the caching plugins, and traffic took an upward trend thanks to the faster loading times.
Unfortunately that didn’t last particularly long either as whilst the blog was particularly zippy the Linux VM would sometimes stop responding to requests and would only start behaving itself after a reboot. The cause of this I’m still not sure of as the VM was still up but it just refused to keep on serving web pages, including all the funky admin tools my PHPMyAdmin and Webmin. It was around this time I found myself in possession of a shiny new VPS that was only hosting my fledgling app Lobaco so I figured a small time WordPress blog wouldn’t be too much for it to handle. Indeed it wasn’t and the blog has been steaming along on it ever since.
However the unfortunate internal server errors returned eventually and whilst I was able to get around them with the trusty old reboot a couple times they became more persistent until I eventually couldn’t get rid of them. After digging around in the event logs for a while I eventually stumbled across references to php_wincache.dll which upon googling lead me to posts like these, showing I wasn’t alone in this internal server error hell. Disabling the plugin fixed the problem and all was well with the world. Of course many months later I found myself trying to optimize my blog again and I started looking at the things I had removed in order to keep this thing up and running.
The first was the caching plug-ins which are unequivocally the best thing for performance on a dynamic PHP site. The vast majority of WordPress caching plug-ins don’t play nice with Windows as they make the assumption they’re on Linux and attempt to write files in all sorts of whacky locations that simply don’t exist. WP-SuperCache, although still suffering from some Linux based assumptions, can be wrangled into working properly with IIS and has been doing so for the past couple months. I also found that WinCache had been updated since I had unceremoniously removed it from my php.ini file so I decided to give it another try. Again everything was rosy for a time, that was until last weekend.
I fired up my blog on Saturday to find the home page coming up fine but I was logged out for some reason. This happens from time to time so I wasn’t worried but trying to login left me with the dreaded internal server 500 error. Poking around it looked like any non-cached page was failing meaning the majority of my site was unavailable. The event logs showed the dreaded WinCache dll failing again and disabling it brought my website back around again. It seems, at least for now, that I’ll have to give WinCache a miss as the last update to it was almost 3 months ago and its past performance has led me to believe that it’s not entirely stable.
So if you’re crazy like me, trying to run WordPress on IIS and all, and you’re WordPress blog seems to take a dive more often than not make sure to get rid of WinCache at least until they get their act together. I haven’t delved into my previous VMs to see if it was the culprit back then but my most recent set of problems can be traced directly back to WinCache wrecking havoc by attempting to cache PHP objects and if this post can save 1 person the headache of trying to track it down I’ll consider it a huge success.
The multiple years of experience that came prior to it.
It’s no secret that whilst I’ve been developing for a long time I’m no rockstar when it comes to the world of web programming. Indeed my first foray into this world was a bastard of a page that was lucky not to fall on its face constantly and the experience had me running to find better solutions, eventually falling to Silverlight. The reason for this was obvious, it allowed me to leverage my desktop development experience into a new platform. Sure I struggled with the ideas that just couldn’t be boiled down into the desktop world (like that whole REST thing) but it was a quick way to get myself into this world and expand from there.
So of course when I saw people saying they built this incredible website in only a weekend when it took me several months worth of weekends just to get mine working I was intrigued. I even made the foolish mistake of reading up on some of their “how I did it” posts on Hacker News and saw all these wonderful frameworks that they had been using, assuming this would make me a master overnight. Stepping through some of the tutorials and looking at the tools available started to raise some eyebrows since they were unlike anything I had seen before, and this is where I got suspicious.
You see I could whip up a simple desktop app or PowerShell script in minutes that would do some function using the tools I have in front of me, but that doesn’t mean you should be using those tools to create your site. Neither does that mean you would be able to whip up the same thing using the same tools in the same amount of time, no matter how skilled you were in other languages. The simple reason for this is that whilst you might be a rockstar in ruby or an expert in PHP your experience is confined to the environment to which you’re most accustomed and should you need to retool and reskill for a new language it’s going to be several months before you’re at your maximum competency again.
Sure good developers are able to adapt much faster than so-so developers but there’s a significant opportunity cost in switching away from your current knowledge comfort zone in order to try and emulate those who you idolize. I came to this realization a couple months back after staring at so many Ruby/Python/SomeDynamicLanguage web sites, wondering at how the heck they got them looking and functioning so well. In truth the platform they were using had little to do with it, these guys had just been in the game for so much longer than me that they knew how to get these things done. With me still in the grok stage of my first really truly web framework I really shouldn’t be comparing myself to them just yet, not at least until I can get my new application functioning the way it should.
It’s so easy to get disillusioned with what you’re doing when you see others progressing so much faster than you ever thought you could. My new application was supposed to be a testament to my coming of age as a web developer, having giving myself only a short time to get it off the ground before actually launching it. Since my deadline for that has come and past I’ve been forced to change the way I view myself as a developer and have come to realize that unless I’m working in something I’ve developed with before I shouldn’t expect myself to be a rockstar from day one, instead recognizing that I’m still learning and pushing through the pain barrier until I become the rockstar I thought I was.
¹If you’re interested, what’s hot right now is photo sharing apps. What’s not? Location apps, go figure.