djsipe.com | Web Development

Over the years I’ve used a number of different PHP IDEs.  Some were great some were “meh”.  One of the things I look for in an IDE is if it really does make my life easier.  When I have things to do, I can’t afford to spend days getting my IDE to work as advertised it just needs to work.

Zend Studio

I’ve used Zend Studio from versions 5 to 8 and with the exception of 5, they all…well…kinda sucked.  Ever since Zend decided to adopt Eclipse, it’s been slow a nightmare.  There’s the potential to be great, but as with all things Eclipse, you have to spend a lot of time upfront configuring the IDE to do whatever it is you want it to do—and it’s ridiculously slow.  I can remember spending no less than an hour fumbling around with plugin dependencies before ultimately giving up and swearing off Zend Studio (until the next version came out with all the promise of a new dawn).  Cost: $299

Komodo

Admittedly, I haven’t used Komodo for years but I remember it was also a solid IDE.  I do remember the interface being a little clunky and hard to navigate around, but the folks at ActiveState may have addressed that in later versions.  Cost: $382

Eclipse PDT

Eclipse PDT is the core IDE for PHP from the open source Eclipse project.  It’s pretty much the same as Zend Studio these days except that it’s free and doesn’t tie in with Zend’s proprietary products.  Being free, it’s hard to speak too ill of it, so in some ways I like it better than Zend Studio.  But when it comes down to it it’s even less pre-configured for out of the box development than Zend Studio.  This means it took even longer to get it into a condition where I could use it.  I ultimately uninstalled it and never looked back.  But if you have the patience and expertise to stick with it, PDT can do great things for you.  Cost: Free!

Aptana

Aptana is a really good IDE.  It has great PHP and JavaScript support.  Also based on Eclipse, but somehow not as slow as PDT or Zend Studio.  Aptana also has great out-of-the-box usability to it.  It’s a great choice if you want a free IDE that handles both PHP and JavaScript reasonably well.  One down side it that it comes with a lot of obnoxious “ads” (links to) for their integrated hosting services.  Cost: Free! 

PHP Storm

In my opinion, PHP Storm is the absolute best PHP IDE.  It is extremely well thought out and makes programming a pleasure with its code assist auto-completions.  I don’t know how they did it, but it seems like it always knows what I am about to type.  As with most other IDEs it has support for Git, SVN, and everything else you’d need.  There’s also Phing, Xdebug, PHPUnit, and more.  I do remember it didn’t come with out-of-the-box support for MySQL and I had to fumble around with an ODBC driver and buggy Java modules to get MySQL working in it.  Cost: $99

PHPDesigner

PHPDesigner is good workhorse IDE.  It doesn’t have a lot of the slickness of some others, but it is fast and it just works.   It also supports true remote projects where your code is saved on a remote server.  Being able to work on remote files directly without having to download them is a godsend in situations where your codebase can’t be easily configured to run on your local computer.  But, understandably, when working on remote files the support for code assist options is limited to only those files you have opened.  PHPDesigner also has some annoying quirks with the way it handles the auto-pairing of opening quotes, parentheses, and HTML tags—but again the support for remote projects outweighs all of these minor problems.  Cost: $37

If I’ve missed any others, and I’m sure I have, just let me know which ones and what you think about them.

In PHP, there are two broad ways you can solve most complex problems.  The first is to “hack” away at the code until you’ve finally crafted a gigantic mass of mangled loops and if statements that ultimately produce the results you’re looking for.  The second, is to hack together code in smaller, self-contained units.  These units may be functions, they may be classes, or they may be programming frameworks.  Obviously, my preference is the latter. Yet in my time I’ve been guilty of more than one mangled briar patch of bemusing control structures.

Now, I know the concept of using functions and classes isn’t ground-breaking to anyone but what I’m talking about is a little more than just using them—it’s using them correctly, or at least more correctly. To put this another way: it is always better to solve a problem by combining many simple solutions, than employing any one catch-all solution no matter how clever it may be. This is true of code and, I would argue, of most problems in general.

They key to this approach is being able to develop an effective strategy for whittling a problem down into manageable chunks.  You could write functions until your blue in the face and still not be any closer to an efficient solution.  To be more precise, here are a couple strategies you might employ to streamline your code into a simpler form:

1. Never copy and paste blocks of code
   If you find yourself doing this, stop.  You’ll probably need this code again later on too right?  Try moving it to a function.
2. Beware of loops
   If you find yourself using a loop structure, especially one that spans more than 10 lines, you might consider moving your loop to a separate function.  A loop is a tell-tale sign that you have a tricky problem you are trying to work your way through.
3. Database queries
   9 times out of 10, if you have a database query rubbing elbows with the rest of your business logic, that sucker should get booted out to a function.  Abstracting any and all database queries inside simple functions gives you the ability to completely change the way you’re generating that particular subset of data in the future.  Freeing you up to employ whatever clever caching mechanism you’d like down the line.

What tips do you have for simplifying your code?

A common problem in complex database systems is an over-abundance of tables, columns, procedures, functions, and the databases that hold them.  Trying to figure out the right columns to use in that reporting query your boss wants by the end of the day can get just a little overwhelming.  Thankfully, there is an easy way to drill down into the structure of your database so you can find just what you’re looking for.

Behold, your information_schema database… The information_schema database is a special database that MySQL uses to keep track of its own internal plumbling.  It holds meta information on every field, column, table, and database on your MySQL server.  For this reason you must treat this database like royalty.  No inserting, updating, or deleting anything unless you want to have to rebuild all your tables.  That said, running selects is harmless enough and if you keep it to that you should be just fine.

Searching For a Column

Here’s a quick way to search for columns in any database by column name:

-- Search for column name containing "bar"
SELECT *
FROM information_schema.COLUMNS
WHERE
COLUMN_NAME LIKE '%bar%';

Searching For a Table

Need to narrow it down? Search by column name and table name.

-- Search only in tables beginning with "foo" for columns with "bar" in it
SELECT *
FROM information_schema.COLUMNS
WHERE
COLUMN_NAME LIKE '%bar%' AND
TABLE_NAME LIKE 'foo%';

Find Columns Used in Stored Procedures or Triggers

Being able to quickly track down all the places a given column can be updated in your database is extremely useful when it comes time to hunt down an illusive bug. Here’s how you can quickly narrow your search to only the stored procedures, functions, and triggers that actually mention your column somewhere in their code:

-- Search all stored procedures and functions for "foobar_column"
SELECT *
FROM information_schema.ROUTINES
WHERE
ROUTINE_DEFINITION LIKE '%foobar_column%';

-- Search all triggers for "foobar_column"
SELECT *
FROM information_schema.TRIGGERS
WHERE
ACTION_STATEMENT LIKE '%foobar_column%';

There’s a whole bunch of other tables to play with in the information_schema table, so dig in… but remember look, don’t touch.

Until about 3 weeks ago, I had almost no idea what “polymorphism” meant—although I knew exactly how to do it. It’s one of those things you’re just going to eventually pick up if you play around with object oriented programming enough, whether you know that’s what it’s called or not. I remember bumping into the term a couple times but the nerd-power behind the lengthy volumes describing it defeated me time and again. Here’s stab at a crude explanation in terms I know I could have understood.

The basic premise of polymorphism, one might argue, can be likened to Plato’s theory of Forms. Plato believed that everything in the world was an imperfect representation of its true Form. A rock on the ground could be thought of as an inexact approximation of its true Form: “Rock”. Likewise, that chair in your room is merely mimicking the perfect, idealized form of a chair. So somewhere—perhaps not in physical form—there exists a pure, perfect, and authoritative version of a chair that all chairs here on Earth mimic, but never quite get 100% right.

It may sound a bit existential, but what Plato was really talking about (from a computer science point of view) was methods of categorization. Think about it. How hard would it be to get a computer to recognize that chair in your room as a chair and not a lamp? By the same token, it’s very easy for us to classify it as a chair. When we classify things on the spot like this, we’re comparing what we see with our own mental vision of what a chair’s “true Form” is.

What is its true Form? What makes a chair a chair, or a door a door? Well, a chair will typically have 3 or more legs, a place to rest your bum, and a back you can lean against. Doors are harder to pin down, but they are generally embedded in walls, and will open somehow to let you go through that wall.

For now, let’s take the example of a door and try to point this ship back towards the topic at hand: polymorphism. Suppose we wanted to build some code to mimic a door. What would it need to do? Ideally it would open. It should probably also be in a wall of some kind. Some basic height and width dimensions might be handy too. So, if I may, this might be your pseudo-code for a door:

door {
action: open();
property: wallType;
property: width;
property: height;
}

What we just pseudo-created is, arguably, the “perfect” Form of a door. Really, we just created a door that’s so generalized it’s pretty much useless. What we really need is an instance of this door, that we can use and go through:

supermarketDoor is-a door {
action: open(
action: slideOpen();
);
property: wallType = "glass";
property: width = "12 feet";
property: height = "8 feet";
}

And that’s it. We just polymorphed. Did you feel it? We can now use our supermarketDoor object. But, from a programming point of view, what allows us to use this door is not that we know how it works. Rather, we can use this door because we know it is a door, and as such has certain characteristics that we know about. We know this door, or any other door for that matter, will be a predicable variation of our original “true Form” of a door. It will open, it will be in a wall of some type, and it will have height and width dimensions. The fact that this door slides open isn’t important, we just want it to open when we tell it to.

So now we can write a quick bit of code that tells a given door to open. And since we know all doors mimic the Form of a door, we can rest assured that our code will always work—no matter what kind of door it’s presented with. This allows us to create a million different types of doors, and never have to touch our original code that opens a door again. That’s the power of polymorphism.