A few weeks ago, I was talking to Eric Willis and he said something I really liked:

Everything that’s easy isn’t if you do a good job.

Take a look at Please Call My Phone.  I used Twilio (my super-easy-to-use obsession), which did most of the heavy lifting.  In fact, I got a “prototype” working in about ten minutes.  So, then, why did it take me a whole day to get the finished product out the door?

It’s the little things that take the time.  The Pareto principle plays a big part in it- 20% of the work always does seem to take up at least 80% of the time.

My original, ten minute version had just a text box that called a phone.  Every little tweak and change took time, though.  Each little addition (scheduling, the design, better error handling, link to my site and Twilio link, JavaScript enhancements, etc) added up quickly.

There are a lot of hidden time sinks, too.  Take a look at scheduling, for example- little things like handling time zones took a ton of time, and nobody will even notice.

People notice when something is done wrong, not when it is done right.

So, remember- if what you’re doing is quick and easy, you’re probably not doing a good enough job.

Lesson #2 and Lesson #3 will be posted soon.

All companies have little (yet important) tasks for developers.  Gathering statistics, setting up ads, doing A/B tests.  And rather than taking one person X amount of time, it takes two people that same X amount of time.  These things are slightly too hard for non developers (HTML? Databases?), but a time-suck for developers working on bigger projects.

With any decent-sized company, everyone has little jobs for the developers.  These jobs pile up- the developers have to spend time doing these tasks, while everyone else loses time waiting for them.

So, why not hire a developer to do that sales, project management, analytics, or marketing in the first place?

Some people will have thought about this thoroughly, and come to a different conclusion than me.  Others will have just a gut reaction to me saying that procedural programming still has a place in PHP.  Either way, a lot of people are going to disagree.

So, with that, here goes my argument that PHP is already MVC-ready.

Views

PHP is unique from many compiled, desktop-centric languages in that all presentation is done using a separate language (a markup language, but a language none the less).  Short of XML output and the like, all PHP needs to be echo‘d and print‘d out among longhand HTML.  Even in my earliest, blissfully-ignorant-to-MVC days, it was apparent that it made more sense to separate the HTML from the PHP.  (Of course, there is a subtle  yet distinct difference between separating the PHP from the HTML, and the logic from the presentation- but remember, I was still MVC-ignorant back then). A simple include does the job.  So, why do we need a framework to do this for us?

Of course, you could argue the merits or disadvantages of using a templating engine like Smarty, but the point is moot- none of the major PHP frameworks really have any templating features beyond what an include can do.

Models

Models are covered by objects- they take care of the data.  More often than not, the job of the model is to convert raw data (often from a database) into something the controller can work with.  Models take care of the tedious business logic, creating a bridge between the data and the code.  Writing out SQL statements in the controller quickly gets messy- models make it easy to keep the data all in sync, across the entire program.

One thing that has always bugged me is that in frameworks, you have to load a model before you can use it.  Why?  With PHP, you can automate this- going through a framework just makes debugging even harder.  That’s not to say that extending a generic Model class can’t help your models- however, we don’t need a full framework for that.

Controller

With me so far?  Well, here is where I will probably lose you.

First, let’s make something clear. I can’t say enough good things about OOP- so I’m not even going to bother trying.  Barring “Hello World,” I can’t think of a single program that would not benefit from OOP.

However, here’s a quote from Rasmus Lerdorf (the creator of PHP):

PHP has traditionally been a procedural language, and OOP features have crept in over the years to the point where PHP can be used as a decent OOP language.

I never understood why we are so fond of using OOP for the controller portion of MVC.  I understand the arguments for it- however, given the bland, generic way frameworks currently utilize OOP in controllers, it seems it is used more for the sake of being object oriented than because it is the right tool for the job.

How about this for an alternative: One index.php file, that takes care of routing.  It can be more flexible, in my opinion, than the regex-based routing implementations in most frameworks.  Yes, I do agree that programming is easier when we can look at a URL and instantly know the class and method the code is in.  However, I also feel there’s merit in dropping the “automagic” that happens when a framework handles our routing. (And honestly, I’ve never worked on a framework based project that had a URL structure that mapped directly to the class-defined structure anyway.)

If we do it this way, we can move the structure from the classes to actual folders.  We can split the PHP up among a bunch of smaller, procedural files.  On top of that, if we commit to mirroring the URL structure, we don’t lose anything in the way of navigating code.

Libraries and Helpers

In the spirit of not reusing code, we can still make liberal use of libraries and helpers- basically, classes or functions that handle any code we may need to use more than once.  These would have to be include‘d on a use-by-use basis, of course- but how hard is that?

In my opinion, the biggest problem with frameworks is they’re not very good at letting you do things your way.  For a team of inexperienced or lazy programmers?  This is great, as it makes sure everyone is on the same page and does things the “right” way.  However, more often than not, I find it annoying that I’m suck doing things the frameworks’ way.

JavaScript framework/libraries have it right- you can use them as much as you want, but if for whatever reason you want to use straight JavaScript?  They stay out of your way.  Why can’t PHP do it this way?  We should worth with PHP libraries, not frameworks.

The Benefits

• Libraries no longer have to be framework-specific.  This opens us up to a lot more prewritten code that we can utilize.
• Faster.  No matter how fast frameworks are, they’re still slower than straight PHP.
• Easier to follow the code, if you don’t have to loop in and out of foreign code to debug it.  Using a frameworks loader will often break most PHP IDEs and debuggers.
• Less things that can go wrong.  If something breaks with just PHP, it’s either PHP or you (and, more than likely, it’s you).  If you are using a framework, there is a third party that could also be at fault.

Conclusion

Model-View-Controller architectures and Object Oriented programming are fundamental to making intelligent, easy to read applications in PHP.  When we start a program, we need to take the time to think about how we can structure the code in a comprehensible way.  However, we don’t necessarily need an MVC framework in order to keep our program separated into models, views and controllers.  PHP is already MVC-ready- so rather than focus on frameworks (which, in my opinion, tend to be lacking), we should create our own well-thought-out architectures and use libraries for the code we want to outsource to open source.

Sure, it’s not as glamorous or trendy as an MVC PHP framework.  But at least one person agrees with me.

I start with a simple regular expression- for example, this:

(.+)@[\w]+\.[a-zA-Z]+

It works great for a majority of email addresses- however, it’s not perfect. It lets through a lot of invalid email addresses. For example, “.name@something.a” is considered a valid email address by this regular expression. So, let’s take a few steps to correct this:

([-a-zA-Z0-9])([-.a-zA-Z0-9])*@[\w]+\.[a-zA-Z]{2,5}

A bit better, right? But what about valid email addresses, such as john+smith@mail.something.com and $A12345@example.mobile? Same goes for the seemingly invalid email addresses such as “Abc\@def”@example.com. But, alas, these are all valid.

No, I’m not going to even attempt a regex that accommodates these. Others have tried. However, it’s futile; email validation ends up either being too strict with what it rejects, or too liberal with what it lets through. Or, in many cases- both.

But for the sake of argument, let’s assume we do create a regex that follows the RFC perfectly. That still doesn’t stop people from getting through with something like youre.bad@validation.com. Sure, we could even go as far as checking to make sure it’s a real, actual email address. But even then, there is no stopping johnsmith@gmail.com- an email address that surely exists, however probably is not owned by the person filling out the form.

Depressing, huh?

Well, what about this one:

(.+)@(.+)

Here’s the secret. This is not a programming problem- it’s a usability issue. If the user benefits from giving you their real email address, they will. If not, you should not be asking for an email address.

It’s that simple, really. Just make sure they at least attempted an email address (otherwise, they may mix up the fields), and throw in a good reason to hand it over- and you will never have a problem.

Thanks to Chancey Matthews for reminding me checking for an @ symbol is good enough, and haacked.com for reading the RTC so I didn’t have to.

Frameworks make it easy to start out- meaning that, when facing a new project, they seem like a good idea.  You don’t have to do all the boring stuff at first- and when you’re starting a new project, that’s a tempting proposition.

This topic deserves a much more thorough analysis (which many before me have done, and I’m sure I someday will), however after spending the weekend struggling with CodeIgniter, I figured I’d mention some CodeIgniter-specific problems I’ve come across.

Debugging

When I started programming, things took me a while.  I didn’t use frameworks- I did everything from scratch.  However, despite the time commitment,  I was making progress- it was time consuming, but it wasn’t frustrating.  It felt rewarding- plugging along in Notepad.exe, making slow but steady progress.  Then, things changed.  I started using frameworks- and things started to go downhill. Rather than investing my time in programming, I started spending more and more time debugging.  And debugging became harder- after all, frameworks tend to break native error reporting to a certain extent.

Here’s the code:

$this->load->model(‘whatever’);

Here’s the problem- IDEs and even PHP itself has a hard time following that.  A lot of times, errors will show up as being in the Load or Model classes- not helpful, when you know the actual problem is in your code.

Like, this error:

Filename: libraries/Model.php

Line Number: 70

The error is in my code, not the file/line given.  Where is it?  Your guess is as good as mine- CodeIgniter isn’t telling.

Conventions

CodeIgniter almost seems to take pride in being illogical when it comes to conventions.  While PHP’s conventions may be laughable, but CodeIgniter’s are prohibitive.

For example, what’s the output of this code? (And, let’s assume these two lines are on separate pages- otherwise, the cookie wouldn’t yet be set.)

set_cookie(‘test’, ‘value’);

echo get_cookie(‘test’);

I know what you’re thinking- and you’re wrong.  It’s not “test.”  For whatever reason (which isn’t documented in the documentation), set_cookie() automatically appends the prefix from the config files, while get_cookie() does not.  So, you would have to do the following to get the expected results:

set_cookie(‘test’, ‘value’);

echo get_cookie(‘prefix_test’);

Great, huh?

Another example is callbacks.  Maybe this is a standard practice, who knows.  But I don’t like it.  In CodeIgniter, for validation, you can specify a rule.  So, something like this:

$rules['email'] = “required|valid_email|unique_email”;

The “unique_email” part is a custom function- and it has to be called unique_email_callback.  I have two problems with this.  One, it’s not easy to figure out unless you read the docs- code should be easy to follow.  And, secondly, why are these callback functions written as strings?  This is code- I shouldn’t be writing out function names as strings.  It makes it much harder to follow.

Attaching Libraries/Models/etc To Everything

Maybe the biggest problem is that if you load any sort of library, view, or model- it’s attached to every single object.  So, let’s say you have an object, with a property called “parent.”

So, this code works:

echo $whatever->parent; // Prints out ’3′

Now, somewhere else on your page, in a completely different object, having nothing to do with $whatever, you do this:

$this->load->model(‘parent’);

Your old code?  No longer works:

echo $whatever->parent; // No longer ’3′

Does this make sense, to a certain extent?  Yes.  Logically, yes.  But, it’s confusing as hell- you can’t have, for example, a model with a ‘section’ attribute and also have a ‘section’ model.  This has caused things to break for me more often that anything else- a perfect example of how changing something in one part of the code can affect something completely unrelated.  Something that doesn’t happen with straight up PHP.

And there’s more

There’s more.  Lots more.  And maybe someday, I’ll document more of the problems I have with frameworks.  Or maybe I’ll try to do something about it, and finish my own framework I started a while ago.  But either way- I hate spending a day programming, and ending feeling frustrated.  Frameworks are bad at getting out of your way (except you, jQuery- I love you).  Before frameworks, a days worth of programming may not have resulted in much, but it went at a steady pace and I knew X hours of programming would equal Y results.  Now, I can spend a whole day trying to get something stupid simple working, with no results.

And I promise- whatever I write for Wednesday, it’ll be more upbeat!