php

There are 3 posts tagged php (this is page 1 of 1).

the problem with frameworks

I love frameworks. You love frameworks. We ALL love frameworks. As web developers we just can’t get enough of these things. They’re everywhere: from Rails, to MS MVC, to CakePHP, to Django, and so on. I’m so obssessed with frameworks that I spend more time thinking about what one to use than actually using it. But this is not the only problem, as after choosing one, your problems can really start.

On a project that I have been intermitently working on for a little while now I chose to use CakePHP. The reason for this choice? Well first, I had a pretty good knowledge of PHP as I wrote my own little PHP framework when web frameworks were a mere twingle in their daddies eyes. Second, PHP is widely supported on shared hosting – though Ruby is catching up (that said, I’ve experienced some horrors with Ruby hosting). The widespread availability of PHP also means that PHP hosting tends to be cheaper.

Anyway, this is all beside the point. My real issue is with the size and complexity of these frameworks. Just the other day I was looking to do something as simple as validate an input that was supplied as an HTML POST parameter. Pretty simple right? Well it ended up taking me a disproportionate amount of time to do this task.

The first port of call was to find out if the framework itself supported this, which to my delight CakePHP (1.2) delivered on. Now it was down to the trawl/skim through the documentation trying to figure out how to actually do it. I found what I presumed done the task – basically I was required to add the appropriate validation rules to my model. Thus I added the following:

1
2
3
4
5
6
7
8
9

<?php
class Section extends AppModel {
    var $name = 'Section';
    var $actsAs = array('Tree');
    var $validate = array( 'name' => array('rule' => alphaNumeric,
                                           'required' => false,
                                           'message' => 'Alpha numerics only'));
}
?>

Then in my controller I simply called the validate method:

1
2
3
4

if(!$this->Section->validates()) {
    parent::handleAJAXError($this->Section->validationErrors);
    return;
}

What happened? NOTHING! I passed data that should have failed and it passed. SHIT! I then decided to check to see that the rules were getting parsed so changed the required key in the rules to true, and passed nothing in. Now it worked – it asked me to specify the parameter. My logic was therefore it can see the data and the rules are getting parsed so what the hell is happening!

By this point I had spent quite some time trying to figure this all out. To be honest, I could have written the validation code quicker. So that’s what I decided to do. Yes I reinvented the wheel, it took me around 5 mins, dwarfing the hours I had spent trying to get the stupid library validation code to work. Not only that, much of the supposed benefits offered by using the built in validation code was of no use to me – it wasn’t built around AJAX requests. So what is the moral of this story?

Well it’s read the documentation better, don’t run the most stupid tests, and don’t charge-in thinking you know how everything works! WHAT I hear you say?!

If only I had taken more care when reading, eh the first paragraph, in the documentation I would have observed this:

First, set the data to the model:

$this->ModelName->set( $this->data );

Whoops I never done this. Basically I wasn’t EVER passing in any data to validate, which makes my shocking test of changing the required to true to convince myself the rules and data were being parsed an absolute joke. Rushing in to write my hand crafted code is as bad as the other old chestnut of complaining “there is a bug in the compiler” – c’mon we have all said it 😉 The only thing I can credit myself with here is that after a recent 4 week holiday I was stubborn enough to not give up and go back an look at it. Therefore, if there is anything to learn from this experience it’s that before starting something make sure you have taken the time to either read the documentation or listen to those trying to guide you. Oh and have a certain amount of stubbornness about you – not too much though.

programming language obsession makes you look stupid

It appears that many people seem to have too much of their life wrapped up in a particular programming language.  You only need to look over at dZone, Reddit or Digg to see this fandom in all its glory.  All too often we find articles about why such and such a programming language sucks.  However, just because a language sucks for one (or a couple) of particular reasons, it doesn’t mean it is not useful in general.  It’s like me saying computers suck because they crash.  However, just because my computer crashes from time to time doesn’t mean it’s not useful.

I just find the whole religious aspect to a language rather pathetic.  The result often leads to the inappropriate choice of language for development of an application, simply because the individual’s voice that is heard the loudest makes the decision.  Ok, if any language will do then just go with whatever you are comfortable with, but stop yourself bitching about other people’s choice of language.

For example, the number of times you hear people saying dynamic languages are no use, for a plethora of reasons, is stunning.  You would think that no one had ever developed anything of reasonable size and scale in these languages.  It’s not as if most of the largest websites on this planet have not been written in PHP/Python/Ruby, yet you still read articles where people are saying where such a feat is likely to lead to catastrophe.  Stop doing this it makes you look stupid.

The same can be said for those that diss Java.  OK, I think it’s possibly a poor choice for those considering a startup web business (basically if you are going to be considering shared hosting Java as an option on this platform is nonexistent), but there are many places where the use of existing libraries written in Java make it the ideal choice for an application.  An example of this can be seen in what I’m currently working on, which is an application that uses constraint programming techniques.  There are a few such libraries in other languages but the most mature and feature rich (and free) are in Java so sense dictates you use Java.

Essentially my bug bear boils down to people choosing a language for the wrong reasons, more often than not due to blind faith rather than education.  Don’t just use a language because it is popular, use it because it best fits the job needing done.  Popularity can come into it though, because at the end of the day you might wish to tap into a large set of existing programmers, or you may want to attract the brightest young talent who want to work in what’s popular/new.  Just don’t let it be the only thing that dictates your choice.

Unfortunately, regardless of however many blog post or articles people read and write, I feel that we are never going to remove this inherent language evangelism.  Maybe the industry would be in a far better position if we were all language agnostic.  Can you imagine how much more work would get done if people spent the first two months of a project actually doing work rather than arguing about what language it should all be written in.

being dynamic is overrated

I was going to post about a little problem that I experienced while undertaking a project I’m involved with but canned it thinking it was of limited interest. That was, however, until I made the same mistake again yesterday, so I thought I would document it to save my own sanity, even if there is no-one else who cares – not that anyone reads this anyway.

So to my faux pas, and believe it or not this cost me a few hours! The problem: well as part of my project (a bike shop website for those who really want to know – www.cyclewize.com) I’m programming in PHP using cakePHP. The advantages/disadvantages of PHP can be debated from dusk till dawn if that is your thing – just remember though, while you are debating all those smart people are just getting on with doing stuff. That said, my problem was, in a sense, due to the use of PHP or dynamic languages in particular.

Anyway, back on track, so the component I was working on simply uploads a set of photos and scales them accordingly. Simple as that. The problem that I kept seeing was that although the photographs were being uploaded ok, i.e no errors were being reported, I was unable to copy the files from their temporary directory over to their new home. Since no errors were being returned I was stuck as to what was happening. I battled away putting print_r’s in here there and everywhere to no avail. Then I just happened to check my call to move_uploaded_file. On inspection, I noticed I had a slight misspelling of a variable name in one of the functions arguments, thus only at that point did the variable come into existence. Therefore what was getting passed to the function was the empty string and hence move_uploaded_file could not copy the file – you would have thought it should have raised an error but no. However, as it turns out, even if it had raised an error it wouldn’t have helped me much. Why? Because straight after the call to move_uploaded_file I was doing a redirect to a new page. Therefore, any errors related to the problem http request were output to a screen which flashed by too quickly for me to notice.

So what is the root of this problem? Well if I was using a complied language it is likely that the compiler would have warned me that the variable I was passing to move_uploaded_file was either not declared or at least never been initialised. I’m pretty sure that a warning message would have been output (which I missed) by PHP’s interpreter but this is no substitute for a compile-time message. As much as I love the freedom of dynamic languages you have to be aware of this significant drawback, and people can go on about how this stuff gets picked up through thorough testing but I’m not sure that’s good enough. Also, the page redirect was a killer, as it made me miss all the output messages. It’s probably worth while not performing redirects if you find something isn’t working, just to ensure that you are seeing all the messages output by the interpreter (you can always switch it back on later). Finally, some sort of lint check should have picked this up. So from now on I think I will be running things through php –l to check that my syntax is good.

There you have it, a nice root cause analysis! I probably missed out the fact that it was my rather inane programming that was the main problem, but bugger it, I’m not really into damaging my ego.