So here’s an interesting thing I thought I should mention. In working on some of the code for this blog engine, I’ve been using the ASP.NET OutputCache directive on some of the .aspx pages to help speed things up. This way, in the event of a slashdotting, or some other sudden increase in traffic, you’re not rebuilding the page or hitting the DB for each request. Nice, huh?
So that’s all fine and good, but what about when you want to blow the page out of the cache? Case in point, in adding comments to the blog engine, the user will expect to see the comment posted immediately, not in 3 minutes.
Sure, I could go in and just make sections of the page cacheable, but… eh… that’s a lot of work. I want to be lazy and just blow the cache away. Sounds simple enough, right? But, for the life of me, I just could not get it to work.
After doing some googleing on the topic, playing around with both the Cache.Remove() as well as the HttpResponse.RemoveOutputCacheItem() methods just seemed to not work.
After several hours of pulling my hair out, I realized the mistake was in the OutputCache directive on the page. I had been using:
<%@ OutputCache Duration="60" VaryByParam="*"%>
What I was missing, was adding the Location parameter to the statement. By changing it to
<%@ OutputCache Duration="60" VaryByParam ="*" Location="Server" %>
the HttpResponse.RemoveOutputCacheItem() method would now work. Woo-hoo!
The other trick I found was when calling the HttpResponse.RemoveOutputCacheItem() method, for the path parameter should be the full virtual path to the page. So, for some site: http://foo.com/somedir/somepage.aspx the path param would be "/somedir/somepage.aspx". Also, it shoud not include any QueryString information.
Recently, I've come across a number of articles talking about problems with the LAMP talent pool, and some of the future predicaments of PHP. Since I recently started a new job that works entirely in PHP, I thought I might add my 2¢.
Many of these articles talk seem to point to academia as part of the problem. That the CS courses are all teaching Java/C++/C# (and not PHP), and they correlate that to a lack of genuine talented PHP devs out there. But I don't think that's entirely it.
A commenter on one of these posts says:
PHP has a good learning curve. I think most Java people can do PHP within 3 weeks. PHP people can't do JAVA in 3 weeks (most of them).
Which I think comes closer to it. Most Java, or traditional CS trained devs should be able to pick up PHP pretty quickly. The language and constructs in PHP aren't anything different or new; it's just a matter of remembering the names and signatures of the methods, and keeping track of the syntax subtleties. As an average C# guy, I was able to whip together a small web application over a weekend (before interviewing with the new gig).
But here's the thing… and I think this is the bit that the above comment almost hit: as a C# developer, there would be no reason for me to ever want to build anything in PHP—when given the choice. For me, there's no itch that it would scratch. To kill a metaphor: the grass doesn't even appear greener on that side of the fence.
If, left up to my own devices, I decided I wanted to work with something open source (and not pay the dreaded microsoft tax), I'd be much more apt to look into Python, or another language that's different, interesting, or had a lot to offer (Ruby, Smalltalk, etc). PHP, while light weight and absolutely functional, comes across as downright sloppy. And, since I'm just a developer (not an architect, CTO, or ops guy), writing good, clean, or interesting code is what really gets me off, not arguments of TCO, or scalability (all of which may be where PHP wins the most).
And I think that's the crux of it. There are plenty of talented devs out there that could work just fine in PHP (I am)… but PHP's biggest obstacle is the language, itself.