php

One of my projects in the past few weeks has been to put together a SOAP server for a client. So suddenly I've had to learn a lot of the nitty gritty details about what works and what doesn't...

While they're fresh, let me jot them down here. WARNING: Extremely technical content ahead.

I've been struggling to get Project Auriga to set HTTP Auth from a nice pretty login form, and think I have it working.

What follows is a very technical discussion--if you're a business reader, you should probably skip this post...

HTTP Auth is a specific mechanism for handling authentication. HTTP Auth is built into Apache and IIS, and so the server can handle authentication purely through configuration, offering many different back ends for storing the data.

PHP development is one of our specialties at Freelock Computing. I've written quite a few PHP applications, some from scratch, some starting with other people's code, some as extensions for open source projects. I've also read a lot of criticism of PHP, and while some of it comes from knowledgeable programmers expert at PHP, most of it is uninformed hogwash. So in this post, I'm going to dispel many of the myths about PHP code, and identify its real strengths and weaknesses.

There are thousands of languages out there, but only a couple handfuls are used for web applications. Of these, PHP is a runaway success. Yet I constantly see it criticized by developers of other languages, often for completely untrue reasons. PHP has a bad rap, and while it certainly has its pitfalls, there's many good reasons it has become such a popular language for web applications.

I consider there to be three major sets of languages currently used for web development.

Ok. Last post on the quality code series. One of the downsides of getting older is realizing you do have shortcomings. You know how when you're young, going into a job interview, the toughest question is the one about your weaknesses? We're all quite blind to our weaknesses, until experience comes up and forces you to realize you're not perfect. Sometimes this happens early, sometimes late, but it happens to everyone sometime.

My coding weakness, it turns out, is reliability. I'm terrible at handling errors, building test frameworks, doing unit testing.

Before code can be customizable, it must be clear. But clarity is not enough, if you're going to be using a codebase in multiple places.

Many open source projects excel at customization. People have enough different uses for an application that very few work perfectly out of the box for everybody. Most companies want to apply their branding to the software we use. Some people need an application localized and translated for their audience.

Programming is an exercise in understanding a problem. To program effectively, you need to fully understand, in intricate detail, the problem your program is solving. Sometimes as a programmer you don't fully understand the problem until you've wrestled with it a few times in code.

Most experienced programmers will tell you that when creating a large program, you almost always have to scrap your work at least once. At some point, you find that you've programmed your way into a dead end, that you just can't quite get where you're trying to go without doing it again.

Programming borrows a lot from the construction industry. Many programming terms derive from construction: hacking, builds, development, architecture, scaffolding, frameworks, and dozens of others. But in some ways, programming has an element of power beyond construction.

Take, for example, a building. When you build a building, you start by pouring a foundation. On top of that, you construct a skeleton, add walls, a roof, sheetrock, siding, and all the plumbing and electrical.

Continuing on the series, the next item on the list seems to be the mistake I see the most--putting slow code in loops, loading up things that don't need to be loaded, making simple requests expensive.

In terms of processing time, it's expensive to open a database connection. It's expensive to connect to another computer. It's expensive to load up a big framework to respond to a single request. It's relatively cheap to retrieve a pre-constructed page out of a cache.

The single biggest mistake I see that kills performance in code is putting database calls inside a loop.

There are many articles that cover PHP vulnerabilities, but I've run across a lot of programmers and code that seems oblivious to them. When interviewing programmers, I look for an understanding of these types of vulnerabilities, and how to prevent their programs from being vulnerable to them.

Aside from register globals issues, most of these attacks are not specific to PHP.

Register Globals issues
From early on, the developers of PHP had this great idea: accept any parameters passed from the browser, and automatically turn them into variables available in the code.