Entries tagged with ‘Development’:
On platforms
One of the things I've been toying with as of late is moving the distinctPixel.com hosting from their (*ahem* bloody expensive *ahem*) dedicated Windows 2000 server(s) to a more budget level unix hosting solution. $300/mo vs. $9/mo is an amazing difference—and one that I just can't quite seem to overlook. Of course, the big hurdle in doing this is that I completely lose the ability to run ASPNET, ColdFusion, and MSSQL Server 2000… the three platforms that I've always written to.
"But Barclay!", you cry, "You're forgetting about PHP, MySQL (it's got stored procedures now) and RubyOnRails! And hell, all the cool web 2.0 kids are using ROR!"
Alright… Alright. I'll take a sip of your koolade.
So, I took the plunge. I installed PHP5, MySQL5, and ROR 1.2 on my aging 12" powerbook.
First, let's start by talking about the distinctPixel.com site. It is is extremely simple: mainly an exercise in templating, with a small amount of DB access (the news section on the home page—which is 4 years old, and the portfolio section), then a little disk access and session handling (for client downloads) and reading and writing a signed cookie (when you're logged in). Not rocket science.
So, I decided to rewrite it in PHP and MySQL.
First thing out of the gate: The interaction with the MySQL class was so fucking ridiculous that I ended up writing a wrapper object to make MySQL operations a little cleaner and more object oriented (not to mention readable). Of course, once I finished writing this, I stumbled up a whole separate MySQL Improved class… what the fuck? This was starting off on a bad way.
So, I did what any good little developer would do, and I went to the documentation. Now, perhaps comparing PHP's documentation to C# is unfair. Microsoft has a gizillion dollars, and can pay lots and lots of professional techwriters to come in and do really solid docs. PHP's documentation, however, seems downright amateur. Often times the threads at the bottom become exercises in pissing contests. I actually found myself using google rather than their docs, where I would find the answer that I was looking for squirreled away in someone's blog.
The rest of my implementation went about the same way. And don't even get me started on session handling in PHP. Seriously. It's fucking retarded.
It feels like they've (Zend, the PHP contributors, or whomever) crammed so much into PHP that they've forgotten to make sure the platform makes sense. It has support for sockets, but the XML parsing is ridiculously lame. How does that work?
Someone needs to come in with a pretty sharp knife, and take a serious look at what needs to be depreciated, and then just start cutting old shit out. Short tag syntax () shouldn't be an option, it should just be. Make A MySQL class, and kill both the old lame one AND the MySQLi class. Yes, it's gonna break people's form applications, but so it goes. Cruft is nobody's friend.
They should also seriously take a look at all of those string methods, and their terrible naming conventions. A bunch of them are str_foo() while the rest are strfoo(). Come on, guys… this screams rookie!
Anyway. Enough of my bitching. It's written… it's done… And it's unlikely that I'd ever choose PHP as a platform again.
I'll attempt in the next week or two to start porting this site (distinctPixel.org) in ROR, and will let you know how that goes…
Programmatically removing a page from ASP.NET’s output cache
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.
Rails: paying for convenience.
So I’ve been tinkering for the last couple of days with adding a commenting feature to this blog. One of the things that I’m really starting to notice with rails (and perhaps this is terribly obvious) is that while a lot of stuff is really great, you sure do pay for convenience.
Having gone through the Agile Web Development with Rails book as an intro to rails, I had been working based on some of the patterns discussed there. It’s quite possible that I’m the idiot in this situation, but all the same, it’s a bit frustrating. For example in building comments, there are comments, which belong to entries. There’s also a commenter, which belongs to each comment—a simple enough set of relationships.
However as I’m building this, it appears that rails is going SQL crazy. First, it’s making the initial SELECT query to get the entry… that’s fine. And then another query to get the comments for that entry… also fine. But after that, rails decides to make an additional SELECT * query for each comment’s commenter (that's a mouthful).
I sure would have hoped that by using the has_many and belongs_to statements in the models, rails would have been smart enough to have seen this should be a join. Being the rails newbie that I am, I don’t seem to see any real way of making rails do that (outside of writing my own SQL—which isn’t not writing the point of using rails?).
I’ve finally decided to wrap a little of my own logic around it and specifically work with the commenter_id field in the comments table to avoid the extra SELECT statements which (frankly) seems like a bit of a hack.
Let me say flat out: I am no DBA or rails guru. So, maybe none of this really matters since the queries are small (I’ve always played by the rule of thumb to make your DB queries as efficient as possible, and count for as much as possible)…
Maybe the answer is that you can solve all of this by caching, so don’t worry about what kind of SQL rails is using…
And, then again, maybe I’m the idiot who’s missing something really obvious.
Working with PHP
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.
barclay loftus