My RSS » Items by PHP Advent

Items by PHP Advent

1,500 Lines of Code

Posted: December 23rd, 2009, 10:00pm MST by PHP Advent

Even the best of us can only write 1,500 lines of code a day, so we need to make those lines count.

There were so many great articles in PHP Advent this year, I couldn’t think of a good topic — I like to believe my peers stole all the good ideas. :-)

A decade of PHP

This Advent marks the day I’ve been a professional PHP programmer for a decade. Ten years ago, I was consulting for a startup consisting mostly of Asians, which meant a lot of smoke breaks. During one of those particular breaks, a programmer asked me, “Hey, Terry, have you heard of PHP?”

“No, what’s that? Some new designer drug?”

“Haha! No, it’s a web language like ASP 1, but it’s free. You should check it out; you might like it more than Perl.”

Instead of smoking a pack of this in honor of that day, let’s begin with some startup stories spanning that decade.

The John Henry of C++

A few startups ago, I worked with a guy who was a better programmer than you.

One day, we got into an argument over a piece of open source import code — written in Python — that he had ported to C++. He had just finished telling me how much faster he had made it, when I asked, “What’s the point in that? Now that you’ve rewritten it, you own the maintenance of it. (Stoyan would disagree.) There is no evidence this code is even the bottleneck.” 2

The point? The code was crap, and he had fixed it — the massive improvement in efficiency was an added bonus.

“Look you’re right. It’s true I prefer to use a crappy, ugly, underperformant language like PHP, and you crank out C++ like John Henry drives steel. But, while you’re busting code with a hammer in each hand, I’m the guy with the steam-powered jackhammer. Sure, you win, but your heart will burst, and you’ll die.”

“And here’s the thing,” I added with a devilish grin, “There’s only one you; there are a lot of people like me out there.”

1,500 lines of code a day

That philosophy started out with an observation I made while being the director of engineering at an earlier startup. It was the kind of startup that all programmers have to cut their teeth on at some point — the kind where you, like Laura, have to put in 170-hour weeks and program uphill both ways.

— Who would have thought 10 years ago that I’d be writing a PHP Advent article drinking Château d’chatalé?

Although I did not actually put in 170-hour weeks 3, I did sleep under my desk. I also didn’t program uphill both ways, but I did spend my days programming and my nights integrating all my engineers’ daily commits. It was during this nightly integration that I made a startling observation. No matter what the programming language, no engineer — including myself — wrote more than about 1,500 lines of code a day.

This observation affected my engineering judgements and decisions for the next decade. It is a maxim I live by today. If we can only write 1,500 lines of code a day, then a quarter of a million lines of code takes about a year. If we can only write 1,500 lines of code, we had better choose the right language and use it in the best way to maximize the expression of our creativity.

When I told this to a friend, he added, “1,500 lines a day… except in Java. J2EE programmers only write

Truncated by Planet PHP, read more at the original (another 35795 bytes)

PHP in Odd Places

Posted: December 21st, 2009, 10:00pm MST by PHP Advent

PHP has traditionally been used to solve web problems, and for this, it excels. Over the past year and a half, I have been doing some unusual things with PHP in a completely new environment, my phone. In this article, I will explain the perils I encountered while exploring the technical depths of making apps for mobile platforms.

The Phone

My phone — an OpenMoko — consists of open hardware and runs Linux. The phone is just a normal ARM platform; you can even install Debian if you are so inclined. Most of the GUI software is written in PyGTK, although they are moving away from that. The phone’s software is rather unstable and not very user friendly, but because it is a completely open platform, you can run anything you want, including PHP. I set out to see whether it was viable to write my own apps for the phone and turn it into a phone that I can use on a daily basis without problems.

PHP

The first task was to get PHP compiling on the phone. The fastest way to compile something for an embedded device is to use a cross compiler — a compiler running on one platform (usually Linux i386) compiling for a different platform, in my case Linux ARM.

With a complicated cross compiler setup, I managed to get PHP compiled, but extensions were awkward, because PHP’s configure system doesn’t support cross compiling. So, I resorted to compiling extensions on the phone itself.

Compiling on the phone opened a whole new can of worms. Although the phone comes with a compiler, almost none of the other tools for building are available. Tools such as Automake, Libtool, and other compiling and linking tools were either not working or broken.

I also learned that compiling on the phone is very slow. There’s not a lot of memory, and the SD card reading speed isn’t great. It took 3 hours to compile PHP 5.2.6 on the phone, and to achieve this, I had to modify the makefile, because some C files — the PHP language parser and ext/date’s string-to-time parser — require so much memory when optimization levels are enabled that the device runs out of memory. The only solution is to turn off optimizations for those files.

Once PHP is compiled, its performance is quite reasonable for a 400 MHz processor. The result:


php -i | head -n 4
phpinfo()
PHP Version => 5.2.6

System => Linux om-gta02 2.6.29-rc3 #1 PREEMPT Sun Aug 2 12:17:54 CEST 2009 armv4tl

PHP-GTK

Although the OpenMoko has a terminal, using PHP on the command line is not very convenient due to the small size of the on-screen keyboard. The predictive view of the keyboard is good, but the terminal and number views are limited in usability and size, so in order to do something useful with the phone, a GUI toolkit is a must. PHP’s only really workable toolkit is PHP-GTK; luckily, the OpenMoko already has all the GTK libraries available. Compiling PHP-GTK for the phone was a bit tricky, but three hours later, I had a working PHP-GTK extension:


php-gtk

GTK+ support => enabled
GTK+ v => 2.14.2

In order to enable UTF-8 support, I had to set php-gtk.codepage to UTF-8.

My next obstacle was to actually figure out how to use PHP-GTK. Although I have been working with PHP for ages, PHP-GTK was unfamiliar. It’s event-driven, so things are triggered when you click something. PHP-GTK’s approach to interface design also created some obstacles.

After dabbling with some test interfaces and simple apps, I found that PHP-GTK apps were actually faster than similar PyGTK apps.

Interface

Because the phone’s touch screen is the only interface, you need to pay special attention to the size and placement of buttons, else it’s hard to avoid pressing the wrong one. It’s not a problem when you tap the wrong key on the keyboard, but it is when you accidentally tap a submit button instead of a delete button. It’s best to create buttons that are plenty large and place dangerous buttons away from the others. Asking for confirmation can also help users avoid disaster.

Although the predictive keyboard on the phone is pretty good, it is not nearly as fast as my old Nokia’s T9 system. Just for fun, I implemented T9 as a GTK window. There are still a few issues — like the order of letters on the “

Truncated by Planet PHP, read more at the original (another 11378 bytes)

GeoIP Wrangling

Posted: December 20th, 2009, 10:00pm MST by PHP Advent

When making the Analog holding page, we wanted to add a touch of personality to make the experience warmer and more welcoming. One of our ideas was to use IP-based geolocation to create a personalized greeting based on each visitor’s location. The task of making this fell to me, and I wanted to share some tidbits about the implementation and what I discovered along the way.

The source I used for GeoIP data was MaxMind. This company has maintained a comprehensive IP-to-location database for a while, and it offers a number of different versions, some of which are free. The GeoCity database, unfortunately, was “available to established businesses only” and cost $370 per site license, so I decided to go with the free — and less accurate — alternative, GeoLite City.

MaxMind advertises GeoLite City as having the accuracy of “over 99.5% on a country level and 79% on a city level for the US within a 25-mile radius.” What this means is that in the US, 18% of the IPs are resolved inaccurately — more than 25 miles from the true location — and 3% are not covered. For the UK, the numbers are worse; 37% of IPs are resolved inaccurately, and 9% are not covered. I experienced this inaccuracy firsthand after Jon Gibbins’s location was determined to be in London, even though he lives in Barnstaple, about 100 miles away. Surprisingly, less developed countries sometimes have better coverage. In Kazakhstan, for example, only 15% of the IPs are resolved inaccurately, and a mere 1% are not covered. To channel Borat, “much success!”

Regardless, this was “good enough.” The next step was to decide how to handle the data. GeoLite City is available in binary and CSV formats. Using the CSV version requires importing it into some sort of database and performing IP range queries, and this is something I wanted to avoid, both for speed of development and to save memory on the server. The binary version has to be used with the libgeoip library provided by MaxMind. Thankfully, there was already a PHP extension in PECL for this library, complete with documentation. My only concern was performance, because the binary IP data file was 28 MB, and reading it from disk every time would quickly become prohibitive. After perusing the libgeoip source code, I discovered that it supports shared memory caching via mmap(), but the GeoIP extension wasn’t making use of this. So, I patched the extension and built a custom version.

The data provided by GeoLite City contains country, region, area code, metro code, city, and postal code. The region indicates the state (in the US) or the province (in Canada). For other countries, the region is a two-letter code derived from the FIPS 10-4 standard, used by such publications as the CIA’s World Factbook. For example, certain parts of London, UK, will have the region H9. I decided to avoid using the regions outside of the US and Canada, because they don’t necessarily correspond to known geographical boundaries. Imagine greeting someone, “It looks like you're in or near London, H9.” That wouldn’t exactly have the human touch I wanted.

The data also contains the latitude and longitude of the approximate location, and this is what I used for the distance calculations. The easiest way to calculate the distance between two points is via the spherical law of cosines, a well-known formula that gives the distance along the great circle between the points. Just to be sure, I looked up a couple of other formulas. The haversine formula used to be preferred when computational precision was limited, but the simpler cosine one gives good results, even for distances as small as 1 meter. And, although it presumes the Earth is a sphere — it’s not really, of course, varying from 6,378 km at the equator to 6,357 km at the poles — the accuracy is still better than 3 m in 1 km. In other words, good enough. If more precision is needed, Vincenty’s formulae can be used instead.

With distance calculati

Truncated by Planet PHP, read more at the original (another 7515 bytes)

Unmaintainable PHP

Posted: December 19th, 2009, 10:00pm MST by PHP Advent

With the recent unemployment rates, everybody realizes that job security is important. The best way to keep a job is to be irreplaceable. If no one can maintain the code you write, you have a job for life. Writing unmaintainable code is a special skill that seems to come quite naturally to certain developers. For the rest of you, here are some tips and tricks to get you started.

First things first

It all starts with the job posting. You should look for the right company, where you can spread your wings and achieve your unmaintainable potential. You don’t necessarily need to be the PHP guru in the company, but it sure helps. Look for job descriptions that mention migrating to PHP from something else, so you know you’ll be calling the shots. Or, search for misguided jobs posts that require 10 years of PHP 5 experience, plus fluency in FrontPage and Netscape Composer.

Once you land the golden opportunity, be vocal from day one. Speak up at meetings; let your opinion be heard. Talk about object-oriented design architectures, enterprise, shifting paradigms, how “good enough” is not good enough, and, of course, your personal commitment to excellence. Make sure everyone consults your opinion on the important initiatives.

The pillars of unmaintainability

Inspired by the most excellent unmaintainable code — a must-read for anyone interested in keeping their job — here are two important concepts you need to grasp and master:

Make it impossible for someone to easily change something without breaking something else. The maintainer doesn’t have time to understand your code. Maintainable code means being able to quickly find something, understand how it works, and change it without breaking stuff. You can’t have that. No one should be able to simply search for something and find it where they expect.
Your code shouldn’t look unmaintainable, because someone will suspect something. It just has to be unmaintainable. The code should look normal to the poor souls maintaining it, but take them by surprise when they least expect it.

Best practices

Ban coding conventions. Endless flamewars have been fought over coding and naming conventions. You can’t have that in your fine organization. You have awesome projects to build, and you can’t afford to spend countless hours in discussion of tabs versus spaces. Plus, conventions are restrictive. If new hires are not used to your conventions, they’ll be miserable. Unhappy programmers are unproductive programmers; explain that to anyone who asks. Let everybody write in their favorite style du jour. As for your own code, rotate your conventions. Go camelCase on Mondays, all_lowercase on Tuesdays, mix-and-match on Fridays, and Hungarian on every February 29th.

No comments. Your code is beautiful; it doesn’t need comments. If someone can’t understand it, maybe they are not so good after all. If, by any chance, you’re forced to write comments, then simply overdo it. Elaborately describe the most obvious and trivial code, and skip the rest.


// In the following block,
// we add two variables,
// variable a and variable b.
// Both of them are integers.

// Declare variable a,
// and assign it the value 1.
$a = 1;

// Now, declare variable b,
// and assign it the value 2.
$b = 2;

// Add the two variables, a and b,
// declared and initialized above,
// and assign the result to variable c.
$c = $a + $b;

Standardize on Notepad. Let the others suffer and eventually leave the team. You don’t need to listen to them complaining all the time. And, if someone asks why Notepad is the standard, be ready to explain. It comes with Windows — the only OS for today’s productive programmer — and it doesn’t cost anything. I’m sure you’ll find references on the Web that explain how you can use any editor, including Word, to write code for web pages, but Notepad is for real gurus. And, after all, your company hires only gurus.
No unit testing. Explain to anyone who asks that you are hired to write high-quality code that doesn’t have bugs, ergo it needs no testing. (A bit of Latin always makes you sound smarter.) Why would anyone in their right mind spend any time writing useless tests that confirm the obvious, that the code works? Some things in life just are — the sky is blue, the sun rises from the East, and your code works, thank you very much. Move on. (Like with comme

Truncated by Planet PHP, read more at the original (another 6472 bytes)

Performance for Web Apps

Posted: December 18th, 2009, 10:00pm MST by PHP Advent

When it comes to programming, there are two things that I enjoy doing the most: making things faster and improving security. The two sometimes come into conflict, because security often requires validation overhead, and performance often leads to cutting corners. Balancing the two is often loads of “fun.”

That said, when it comes to security, things are relatively straightforward. Filter your input, escape your output, and don’t trust your users. On the performance side, things are not nearly as straightforward, especially when it comes to web apps.

The basic approach is fairly simple; just profile your app, determine the slow areas, optimize them, and voila, things are faster. Alas, even when this approach is followed, the results don’t necessarily eliminate the “your site is slow” feedback.

Browser bottleneck

For any app, the measure of speed is ultimately all about user perception. In a traditional environment where binaries are deployed on a user’s machine, you control the app, so optimizing the interaction is part of the optimization process. If a report screen takes too long to load, your profiling efforts will identify that, and you speed up the rendering function.

For web apps, things are a little different, because the UI is controlled by a web browser — a 3^rd party app that you have no control over — and it is responsible for rendering your data for your users. Even if you output your content in one hundredth of a second, by the time the content is downloaded, parsed, executed, and rendered, a few seconds may have passed, and the user experience is diminished. This is something most web app optimization attempts miss, since they focus almost exclusively on how quickly content is generated.

In fact, for web apps, it is often better to start your optimization efforts from the user side of things rather than the server.

Making things better

Making the user experience better — and by better I mean faster — is not too complicated.

As with any optimization, the first step is to understand the nature of the problem. Good tools include Firebug for Firefox or Google Chrome. Using either, you can understand how big a page is, what additional resources (CSS, JavaScript, images, &c.) it loads — in what order and how quickly. This will give you a base to work with and identify areas of greatest interest. What follows are some easy improvements, ordered by ease of implementation.

Load time optimizations

Enable compression using something like mod_gzip. It’ll speed up page loading by significantly reducing the size of text content. Send caching headers (Expires, Last-Modified, ETag, &c.) for static content (images, CSS, JavaScript, &c.) to reduce redundant requests. Optimize images; in most cases, you can reduce the size of images by up to 30% with non-visible, lossy compression, color reductions, and the like. Compress JavaScript using tools such as JSMin, and compress CSS using YUI Compressor.

Check your cookies

While broadband connections can download hundreds of kilobytes per second, uploading is another matter entirely; most DSL and cable connections can only upload 20 to 30 kilobytes per second. If your page contains 10 resources, and the size of all the cookies is a mere 1 kilobyte, sending the requests alone can still take over half a second. Keep in mind there are also 400 to 500 bytes of headers per request. Therefore, it is important that you reduce your cookie sizes to just the session identifier. A slightly more complex solution is to move your static content to another domain, so your cookies are only sent to the pages that need them instead of all of the static resources as well.

Reduce request count

Merge your images; rather then sending a dozen 1 kilobyte images, combine them into a single image, and use CSS to show parts of the image. If you are loading more than 2 JavaScript or CSS files per page, considering merging them into a single file. This will makes things faster, but don’t merge too much, otherwise you’ll introduce parsing overhead.

Improve JavaScript loading

After you’ve merged your common JavaScript code into a single file, you may still have other JavaScript files that you load in the specific pages that need them. Unfortunately, browsers don’t load JavaScript files in parallel like they do with images. To prevent dependency breakage, most browsers load sequentially. If you hav

Truncated by Planet PHP, read more at the original (another 649 bytes)

You Don’t Need All That

Posted: December 17th, 2009, 10:00pm MST by PHP Advent

I’ve been writing PHP for a long time. I am not one of its dinosaurs, but I’ve been making it do my bidding since PHP 3. I have also seen a lot of trends come and go. As an example, PHP 4 was all the rage for optimizing with references. PHP 3 still had some parts that were so poorly written, it was possible to get 20% performance increases just by changing the way you did something. PHP 5 is obviously trending with object-oriented programming.

Speaking of object-oriented programming, we know the standard drill. A cornucopia of MVC frameworks have rained down on us — some of which actually follow an MVC pattern — and have inundated us thoroughly with the standard request workflow:

The web server initiates the bootstrap.
The bootstrap initiates the front controller.
The front controller initiates the controller method.
The controller uses the model.
The controller prepares view data.
The controller instantiates the view and provides the data.
The request completes.

Et cetera, et cetera, ad infinitum. Mind you, this isn’t a bad workflow at all. We have a nice, clear separation of concerns. We always know where to look. It’s great, right?

Well, the idea is great. Allow me to share something I did the other day. I decided that I would benchmark the difference between traditional, hard require statements, and a clean autoloader. Bah! Micro-optimization, right? Well, I beg you to humor me.

I set up a PHP benchmarking environment with an old server, and I wrote a small set of scripts to generate the following components:

A directory with 100 class files. These classes are simple blanks in the form of class MyClass {}. The actual content of the class wasn’t relevant to what I wanted to benchmark.
A script that performs a hard require statement for each of the 100 classes and then instantiates them: require './classes/MyClass.php'; $myclass = new MyClass();
A script that implements a very simple autoloader, registers it, and then instantiates one of each of the 100 classes.

I tried to think of how to introduce as little bias into my benchmark as possible, and I came to the conclusion that I would run the benchmarks against a stock Ubuntu LAMP installation with a concurrency of 1. This seemed fairest, since it’s a close approximation to what what is provided by many hosting providers. The PHP version was 5.2.9. The test is slightly unrealistic, because an app using hard require statements and multiple entry points would not load 100 different files to perform any given task. You would do tend to bundle things a bit more neatly. However, these files would usually contain some wasted code not used by every request. I figured the balance was fair, and I was satisfied with that. The point is to test how far apart require and an autoloader are, not to test the efficiency of your code organization.

I benchmarked the script with hard require statement and the script with the autoloader by using apachebench. Each run was 1,000 requests with a concurrency of 1. For each script, I performed 4 apachebench runs. The first run was to warm APC, the file system, the moon phases aligning with Venus, et cetera. The requests per second of the next three runs were recorded, and the middle value was chosen. I expected to find a difference in performance. There is no question that autoloading takes more time, but the results astounded me. Specifically, the runs for the script using exclusively hard require statements yielded 46.3% more requests per second than the script using the autoloader. That’s a real performance difference.

The above establishes a significant, quantifiable performance difference for the simple operation of including code. There are, however, observable differences in behavior. I will try to enumerate some of these in as unbiased a fashion as possible:

If your loading mechanism is based on the idea of loading discrete objects one at a time, such as with classes, remember that some objects are very small in size. A number of your class files may not have more than one or two static functions in them. Since the autoload operation is expensive, loading this code becomes an inefficient operation.
If your loading mechanism is based on the idea of loading families of code, such as with include files, you are inclined to group small classes together in a single file. This of course makes the loading operation much chea

Truncated by Planet PHP, read more at the original (another 4335 bytes)

PHP’s Not Just a Language

Posted: December 16th, 2009, 10:00pm MST by PHP Advent

“I did not develop the PHP we know today. Dozens — if not hundreds — of people developed PHP. I was simply the first developer.”

— Rasmus Lerdorf1

Six years ago, I became aware of the PHP community. I joined it three years prior to that.

Communities don’t make languages; languages make communities

I’m not a very chatty person, and I abhor small talk (not the programming language, the empty conversation kind). So, if I don’t say much to you when we see each other at a conference, don’t be offended. When I’m in Europe and my ear happens to capture the unique sound of an American accent, however, I won’t hesitate to say “hi.” I’ll even strike up a short conversation. You might even call it small talk. “Where are you from? How long are you here? What sites have you visited?”

I recall one time when I was in New York and heard the distinct sound of a Southern accent. It turned out that the speaker lived only twenty miles from me in Georgia.

Our languages bring us together and give us identity. When we have nothing else in common, sharing the same language gives us the only commonality we need, and if we don’t share that, we’ll find a way to communicate in other ways. I’m reminded of the Star Trek: The Next Generation episode “Darmok.” It’s one of my favorite episodes of the series, and in it, Captain Picard must learn to communicate with an alien captain who speaks only in metaphors. He succeeds, they overcome a dangerous beast, and the Federation gains a new ally. How? Because of language.

It is a natural human inclination to live among people who speak the same language, to seek them out and fellowship with them. After all, you can understand them, and they can understand you. I am no sociologist, but I submit to you that language is perhaps the fundamental building block of community. Without a common language — a common means of gaining understanding and expressing ideas — there can be no community. After all, the word community is right there in the word communication.2 Community is about language.

In much the same way, programming languages create communities. Programmers seek out support and fellowship from those who use the same programming language. We get together. We talk shop. We’ve encountered a lot of the same problems in our work, and we can help each other become better at our craft by sharing our experiences.

Which came first, the language or the community?

I imagine this is a difficult question to answer. As I said earlier, I am not a sociologist. I am also not a linguist, although I do have some background in the study of the English language.

As I stated earlier, language makes a community, but it is often a need of the community to have a common language. This is how languages evolve and become new languages. Historically, cultures that came in constant contact through trading, for example, would develop pidgin languages. Over time, these pidgin languages became creole languages, as parents taught the language to their children as their first language.3 Still, there are languages, such as English, that evolved over time as it borrowed from other languages, and changed according to common usage. It continues to change today.

So, communities require communication. In order to communicate, there must be some kind of language, and if there isn’t, the community will create one, and the language of a community changes over time.

PHP is a language; PHP is a community

PHP is a lot like the English language. It began its life as a utilitarian language, serving a simple purpose: processing forms on a web page. A diverse community grew up around this language, further evolving it and changing it to suit their needs, to aid in communication. After all, a programming language is just another means of communication. The audience may be different — in this case, the language is for communicating with a server, database, and more — but the end goal is the same.

In fact, taking this analogy a bit further, PHP/FI, created by Rasmus Lerdorf is like Old English, while Andi Gutmans and Zeev Suraski brought about their own Norman conquest of PHP, creating Middle PHP (

Truncated by Planet PHP, read more at the original (another 6532 bytes)

Managing Bob

Posted: December 15th, 2009, 10:00pm MST by PHP Advent

The interaction between technical people and the project sponsor has common patterns regardless of your employment model. Project sponsors — whether consulting or freelance clients, key stake holders within your organization, or potential users from some vaguely-defined demographic — all have similar needs and issues. I’m going to collectively call these people Bob from now on, because “clients, key stake holders, and end users” is very wordy, and pixels are expensive. Also, it helps to put a human face on a role. (Three quarters of the way through a project, it might help to put a human face, specifically Bob’s, on your dart board.)

Technical people tend to think first and foremost of the technical parts of a project. That seems like an obvious truism, right? If they thought first and foremost of the color of the packaging, or the training users will need, or how best to market the end result, they probably would have gravitated toward a different career.

Effectively managing Bob is a key task that directly leads to project success. Sometimes the relationship has obviously adversarial aspects, such as in a fixed-price contract where both sides are likely to disagree over what is within the project scope, but even the friendliest relationship has the same basic conflict between the technical staff and Bob. The sponsor wants more, and wants it on time. The technical staff needs to restrain their enthusiasm, so that a cross between those wants and the constraints of reality is produced.

Regardless of whether Bob is your employer or client, you need the same basic elements to control the process: an upfront plan (recorded in some way), a way of recording all changes, an agreement on who has the authority to make changes, and the power to update the original plan’s time estimates in the event of change.

Overall project success or failure is only sometimes closely tied to technical factors. Right off the bat, you need to think about who decides if the project was a success, and regardless of whether that determination is made based on measurable, objective factors or more commonly just the person paying the bill’s gut reaction, it probably is not made on the basis of a technical evaluation.

The determination is made by Bob. Bob rarely has the knowledge to judge a project on its technical merits, and even more rarely cares. He has his own internal set of criteria, only some of which you have the knowledge to understand, and even fewer of which you care about, and many of them will go unstated until it is too late, unless you are very good at extracting information from uncooperative subjects without the use of pliers or waterboarding.

I’m not saying you should deliver poor quality code. Non-technical people certainly notice the side effects of good code. Even if Bob would not recognize it if a bus — plastered with beautifully-tested code implementing a cool new design pattern that was only invented tomorrow — ran him down in the street, he notices the results. Bob notices uptime, how long seemingly minor change requests take to implement, consistency in the UI, crashes, revenue, and conversion rates. He will notice the symptoms of bad code, even if he does not have the knowledge to diagnose the root cause, or the vocabulary to request the cure.

My point is that technical aspects are only a small part of overall project success. Extracting real, actionable requirements from Bob, setting realistic expectations, and either meeting those original expectations or keeping the project on track as things change is a big part of success. Manage new information, new feature requests, and change requests while either coming in on time or resetting Bob’s expectations in advance. This keeps him informed about what impact his requests, dreams, maternal attachment issues, and crazy ideas he read in this week’s issue of IT Trends For Steam Engine Manufacturers are having on the project.

If your project is to be a success, you need to effectively and proactively manage Bob. You need to keep him happy, which probably means making good overall progress, but specifically making some visible progress in parts of the project he does understand. You need to deny some of his change requests so that the project reaches completion. You need to accept some of his change requests so that he feels that the power dynamic is correct, but you need to either have allowed the right amount of padding in anticipation of change, or make sure that Bob is aware what effect the request has on the timeline.

One of the best and worst things about software is that it is infinitely malleable. If you don’t like change, perhaps steam engine manufacturing would be a better career for you. Change will ha

Truncated by Planet PHP, read more at the original (another 4016 bytes)

Dæmonize Your PHP

Posted: December 14th, 2009, 10:00pm MST by PHP Advent

Despite the haters, I actually really like PHP. Well-written PHP strikes a solid balance between getting things done and getting things done properly. It also lives somewhere comfortably between development time and performance. It’s — at least in my opinion — the best tool for creating web apps.

Sometimes, though, we’re called on to write bits of code that live outside of our arena of the Web: cron jobs, mail processors, Subversion hooks, or even asynchronous workers.

There are often better tools than PHP to accomplish these tasks. For example, if Procmail can solve your problem, you can avoid writing a lot of nasty mail parsing logic — even if you do get a little help. Although PHP does have some ability to perform tasks normally delegated to systems engineers, most developers with a bit of experience in Python will tell you that it’s a better choice for things like forking and creating network dæmons, and I agree.

In my opinion, there are two major reasons to use PHP outside of the Web — and they’re very good reasons when they’re your main reasons:

Familiarity: Many PHP developers will have dabbled in other technologies to pragmatically scratch normal development itches, but — especially at junior- and mid-levels — they’re most comfortable with PHP, because they’re fully immersed in it for their whole professional career. They can crank out PHP code faster than they could even remember the syntax to operate on files.
Code re-use: A side effect of full immersion in PHP is that you’ll have plenty of PHP code laying around, ready to be employed in new and unexpected ways — especially if it’s well-designed. There’s no need to reinvent the wheel for most non-web tasks, and doing so is often detrimental to maintenance and predictability. You wouldn’t want to implement password hashing code in two separate languages, in two places.

One unintended place that I’ve been using PHP lately is in long-running processes. PHP 5.3’s improved garbage collection helps in certain situations, but what I really needed was something that would not only keep my processes running, but would also keep track of logging, concurrency, and crash recovery. When an Apache process crashes, or reaches its maximum number of requests, another one spins up in its place with little negative side effect to users. I wanted something like this, but I certainly didn’t want to write it.

Luckily, I’m not the first person who envisioned such a thing. After toying with the ambiguously-named Daemon (which I wasn’t able to compile and execute properly on OS X) for a work project, my friend Andrei Zmievski inadvertently pointed me in the direction of Supervisord, which was created in part by Mike Naberezny, whose name you might recognize from his past gig as the primary maintainer of Zend Framework.

Supervisord, through a very simple configuration system, allows me to create simple long-running processes without having to worry about the the support infrastructure. It handles the things I mentioned above with ease, and keeps my scripts running without worry.

One such script is a fun little service I’ve attached to Twitter called @beerscore. This bot allows me to DM beer names via Twitter, and within a few seconds, I’ll receive a reply with the percentile rating for the beer I’ve requested. This is particularly useful when I’m traveling and don’t necessarily have web access, but I’ve almost always got SMS coverage. (If you’d like to play with it, you must follow @beerscore in order to send a direct message.)

The code behind @beerscore runs constantly to follow-back users and to serve scores. If it crashes for some reason, a new copy is spawned. Its output is logged, systematicall

Truncated by Planet PHP, read more at the original (another 3158 bytes)

CSS and Other People

Posted: December 13th, 2009, 10:00pm MST by PHP Advent

The road between design and development is fraught with all sorts of peril — as Helgi has already pointed out. Bringing a visual concept to the Web is a group effort that often requires the collaboration of people with different backgrounds and areas of knowledge.

From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of html and CSS that will render properly on browsers that are often at complete odds with one another.

This process is a bit like a wicked game of chess; there are only a small number of fast and set rules, but an almost unlimited numbers of ways (both good and bad) to achieve a goal. Like a game of chess, a player who doesn’t understand the rules can end up in serious trouble, which, in the case of front-end development, can easily roll downhill and affect other people on a project.

I have seen (and experienced) this problem tackled in a number of different ways by different teams; while there’s probably no right solution, here’s how we do it.

Establishing a good process

Front-end development needs to be a collaborative effort from the very beginning. A designer who builds comps blindly, without any input from the people who will have to translate the design into code, is asking for trouble. This can be easily compounded by showing the client a concept only to have to go back to them to let them know that it can’t be done in a way that will look good in a browser.

The first step in producing a design, therefore, needs to be a contract between the designer and the developer aimed at establishing whether the former’s ideas can actually be translated into working code. Typically, this is what a wireframe is for. (Personally, I’m not too keen on showing wireframes to customers, unless they have a high degree of familiarity with web design, because you will otherwise, invariably, have to explain why they are paying your firm to draw a bunch of boxes.)

The interaction between design and development shouldn’t end here, however — I would, in fact, argue that a developer should be allowed to review every comp before it is sent to the customer. This makes it possible to catch design decisions that are very difficult to implement in practice — such as gradients anchored to the bottom of a columnar <div> that needs to expand vertically — before the client becomes too attached to the idea.

As a side note, comps should include more than just the visual look of the page template. For example, the designer should create a specimen of all the styles that apply to the design: headings, paragraphs, lists, and so forth. Naturally, the complexity (and completeness) of the specimen should be proportional to the complexity of the web site; an online brochure is unlikely to have the same requirements as, say, an online encyclopedia.

CSS from the inside out

Once a design has been agreed upon, approved by the customer, and sliced to perfection, the process of transforming the comp into a series of files has three primary goals:

Minimize the use of images
Maximize browser compatibility
Minimize code complexity

The reason I like to minimize the use of images in a design is that it makes managing changes much simpler. Making changes in code requires fewer steps and produces more immediate results, leaving more room for experimentation in the implementation phase. This is particularly true with backgrounds (my least favorite design element), which clients seem to particularly enjoy changing. Naturally, minimizing image usage shouldn’t come at the expense of either maintaining good browser compatibility or writing code that is easy to maintain.

Producing good CSS is also a multi-step process that goes from the generic to the specific:

Start with a reset template (such as Yahoo’s) to ensure that your code will be based on a common starting point across multiple browsers.
Define a grid for your site using either one of the several pre-packaged frameworks — such as the 960 grid system, baseline, or YUI’s — or your own layout, based on your specific needs.
Compile a generic stylesheet of all relevant elements that are common throughout your templates: text, table

Truncated by Planet PHP, read more at the original (another 3298 bytes)

Untitled

Posted: December 12th, 2009, 10:00pm MST by PHP Advent

i. An introduction

No one reads anymore, and you’re not going to read this. You’re going to scan it.

We need to more seriously consider how application design evolves in that context.

ii. A list

PHP succeeded because of 4 reasons, in order:

mod_php, also known as ubiquity
MySQL, and the tight coupling thereof
Cheap shared hosting
Web script installers on cheap web hosts

iii. B list

Terry Chay once wrote, “what I’m saying is look at the top 100 web sites on the Internet. About 40% of them are written in PHP, and 0% of them are written in Rails.” He apparently just made up this statistic, but no one pointed this out in the one hundred and twenty-three comments on the post.

As a form of procrastination, I went through the Quantcast top 100 and attempted to count those using PHP. I got 39. I wonder what the top 100 Facebook apps use. It’s harder to tell what people run these days, because everybody uses cool URIs with logical structure, even though that doesn’t matter anymore, except Walmart, which uses .gsp, which I’ve never seen before. I guessed on a few.

If you were judging PHP by the .php extension, you would think we were extinct by now. That’s okay. PHP is a means to an end; the more invisible we are, the more we’re doing our job.

“Powered by” has lost meaning. 100% of the top 100 sites run more than one language, somewhere.

iv. Stronger, better, faster, shorter

Technorati have maintained a list of the top 100 blogs since they started, but now they only show 25 per page, presumably to garner more page views. Maybe they know something we don’t about people not reading anymore. Maybe it’s hard to make money as a search engine. The list is updated once per day.

v. Two problems

I learned to program from Mastering Regular Expressions by Jeffrey Friedl. Now he blogs, and I’m happier about that than just about any blog other than Zeldman’s.

vi. Twignette

“You’d think T_STRING means a string, right? Pfft. [php.net] ”

— @tellyworth

I attempted to make a T-Pain joke. The actual page is funnier, “You’re supposed to know what T_SR means. For everybody who doesn’t know that, here is a table with those identifiers…”

Twitter doesn’t include years in their timestamps anywhere on the site.

I think the best way to introduce someone to PHP is to take a static html page they have, rename the extension to .php, and put a useful bit of code in it. I wrote an article about this in 2005 with the money snippet telling you how to not have to update the copyright statement on your site every year when you should be sleeping off the celebrations from the night before. I’ve done some neat bits of code in my life, but the most popular page on my site, still, is a random image rotator, which is a glorified array_rand(). People don’t read; they Google.

The API most responsible for the Web’s success is the clipboard. Today’s revolution brought to you by the letters U, C, and V.

viii.

“Don’t tweet about a man crying. Write a tweet that will make a man cry.”

— @zeldman, 2009

We’re spending our time lately on allowing functions and classes to have any Unicode character in their name.

“They’re singing your praises while stealing your phrases.”

— Charles Mingus

MySQL : Drizzle :: PHP : PHP

vi. border-style: dashed;

The PHP.net web site looks — and more important

Truncated by Planet PHP, read more at the original (another 578 bytes)

JSON Gotchas

Posted: December 11th, 2009, 10:00pm MST by PHP Advent

JSON is a subset of the JavaScript language. JavaScript itself is based on ECMAScript, which is standardized in the ECMA-262 standard. Just this month, the 5th edition of the language standard was released. Section 15.12.1.2 gives an overview of the syntactic grammar, which defines values (such as strings and numbers), arrays, and objects. Arrays are delimited by square brackets; objects are delimited by curly braces. Here are a few examples:

var a = [1, 2, "three", true];
var o = {"name1": "value1", "name2": 2};
var mixed = [{"day": 13, "month": "December"}, {"day": 24, "month": "December"}];

JSON is very useful when building RIAs — what we often refer to as Ajax apps. These kinds of apps are constantly communicating with the server, sending and retrieving data. Since bandwidth is scarce, and unresponsiveness due to latency must be avoided, it is vital that data being sent is serialized in a format that is as concise as possible. Here, JSON comes into play, since it is much less bloated than something like XML. Another benefit of JSON is that it is trivial to convert a JSON string back into a JavaScript value:

var a = eval('([1, 2, "three", true])');
var o = eval('({"name1": "value1", "name2": 2})');
var mixed = eval('([{"day": 13, "month": "December"}, {"day": 24, "month": "December"}])');

Note the extra parentheses around the JSON strings. These turn the JSON strings into JavaScript expressions.

Notation or not?

If you have a closer look at the specification regarding the notation of objects, you will see that the keys (the parts on the left of the colons) are of type JSONString. A JSONString is defined in section 15.12.1.1 (Lexical Grammar) as an arbitrary list of string characters, delimited by double quotes. This is a more strict definition than what is supported in the JavvaScript implementations of modern browsers. For example, as far as most browsers are concerned, it is perfectly fine to use single quotes as the string delimiters:

var o = eval("({'name1': 'value1', 'name2': 2})");
var mixed = eval("([{'day': 13, 'month': 'December'}, {'day': 24, 'month': 'December'}])");

If an object member’s key does not contain special characters (and if it also conforms with a few other rules), you can even get rid of its delimiters, saving a few more bytes:

var o = eval("({name1: 'value1', name2: 2})");
var mixed = eval("([{day: 13, month: 'December'}, {day: 24, month: 'December'}])");

There is, however, an issue with this approach: most JSON libraries adhere to the specification, not to the browsers’ behaviors. PHP’s JSON extension (shipped with versions 5.2+), for instance, expects double quotes:

var_dump(json_decode("[1, 2, 'three', true]")); //NULL
var_dump(json_decode("[{'day': 13, 'month': 'December'}, {'day': 24, 'month': 'December'}]")); //NULL
var_dump(json_decode("[{day: 13, month: 'December'}, {day: 24, month: 'December'}]")); //NULL

Most frameworks behave identically, both for decoding and encoding. For example, Zend_Json in the Zend Framework requires double quotes. If you are generate a JSON string in your client app and send it to the server for decoding, make sure to adhere to the specification. If you don’t, json_decode() and Zend_Json::decode() will fail to decode the JSON string.

Security

There is a reason that eval has the same metaphone key as evil. The JSON string is executed in the same JavaScript context as the current page. It is an absolute necessity that you trust the source of the JSON data — if the source is untrusted, another safer and more restrictive parser must be used. The 5th edition of the ECMA-262 standard defines a JSON.parse() method which only accepts JSON text, but does not evaluate script code. Until browsers implement the current ECMAScript version, you can use some of the alternatives listed on the JSON home page. The appropriately named json-sans-eval library is a useful alternative, and it even uses the same method signature as JSON.parse(). If you use a different parser, at least check the source code to see whether or not eval() is used.

There are some scenarios in which you cannot avoid using eval(). For example, JavaScript supports met

Truncated by Planet PHP, read more at the original (another 1322 bytes)

World of PHPCraft

Posted: December 10th, 2009, 10:00pm MST by PHP Advent

Dear Santa,

I’ve been a bad girl this year. I haven’t fixed bugs in my extensions. I’ve barely worked on PHP 6. I only attended a handful of conferences. And, my blogging’s been pretty gay. (I can make that joke; you can’t.) I can explain, though. I was working. Who am I kidding? I was saving orphans from a burning building, barefoot, in the snow, over broken glass. No, that’s overselling it. Fine, I got sucked into World of Warcraft (WoW).

Can I still have my Red Ryder BB gun? I promise not to shoot my eye out.

The world

Forgive my comparison, but I’ve noticed something while wandering around Azeroth and watching the guild: Programming — with PHP especially — is a little like a MMORPG.

I’m sure to suffer the slings and arrows of this outrageous analogy, but hear me out. How good is your code when you’re just starting out and reading the PHP.net tutorial for the first time? It’s crap. You’re a newb, a level 1 paladin with a wooden sword and a fear of bunnies. I hope I don’t belabor the metaphor, because it’ll get tiring fast, but each new programming challenge is a quest to gain experience points and develop your character (career).

Some of us level up slowly, slaying the placid demons of personal web sites while studying walkthroughs to see the pitfalls before they show up. Others charge straight into level 40 enterprise instances, finding themselves respawning in the graveyard of performance bottlenecks, security vulnerabilities, and empty mana potions. All of us learn, albeit at different rates and with different battle scars to show for it.

The ones who advance the quickest are the ones who learn from the more experienced, helpful players (developers) around them. There’s an unexpected non-competitive spirit in WoW1 which, I think, mirrors the PHP community. IRC channels on Freenode, EFnet, and nearly every other major network are a testament to the nature of PHP developers to want to help each other out. The massive amounts of effort continuously poured into the online manual — which is second to none — prove this isn’t just a half-hearted chat phenomenon.

The guild

At the center of this collection of aspiring artisans are the level 80s, DPS mages like Rasmus Lerdorf, Zeev Suraski, Andi Gutmans, Wez Furlong, Andrei Zmievski, and many others who’ve brought us some of PHP’s most useful features. These aren’t the only heroes, though. Other include Jani Taskinen (sniper), who’s been standing on the front lines of triage for as long as I can remember, the many healers who desperately try to keep PHP internals drama to a minimum, and the documentation folks — who I can’t find an analogy for — are part of the rich tapestry that makes the World of PHP so enrapturing. Personally, I always fancied myself a warlock — dark, arcane magicks and all that.

Characters enter this circle and leave it. Some just feed off of the generosity of those who contribute, and that’s okay. Some toss one contribution in and walk away. Some would like to lend their abilities, but are worried that they’ll just get in the way or won’t be able to keep up. It’s this last group that I want to reach out to, because there’s room in the PHP guild for all levels. Yeah, you might make some mistakes, but you’ll gain experience, and that’s what leveling up is all about.

Become a mage Subversion contains everything you need to know to get started with the PHP source code. There are articles on DevZone to give you a solid introduction to extension writing and maintenance, and follow-ups like the technical rants that I sometimes post on my blog — check out the right column, under favorites. If you’ve got a few bucks burning a hole in your pocket, you can tolerate my shameless

Truncated by Planet PHP, read more at the original (another 2081 bytes)

Character Sets: Garbage In, Garbage Out

Posted: December 9th, 2009, 10:00pm MST by PHP Advent

I recently checked on a project, because the developers were having some problems with strange characters displaying on the page. In particular, a number of accented characters were showing up as the Unicode replacement character (). How sad.

A bit of research revealed that their pages were being served in UTF-8, but the data store was using ISO-8859-1. A few patches were applied, and the string in question was fixed. In order to manage character sets correctly, your entire application — from input to database to output — needs to be configured correctly. This can be quite a challenge, and in this article I will introduce some of the problems and provide a few solutions.

Character sets

Character sets are basically sets of symbols that computers use to map numbers to the glyphs you see. You can think of them as tables that contain all of the glyphs you might need — not only letters, but also punctuation, symbols, space, backspace, &c. Here’s an example character set I’ll call Paul’s First Character Set:

	0	1	2	3	4	5	6	7	8	9
0	a	b	c	d	e	f	g	h	i	j
1	k	l	m	n	o	p	q	r	s	t
2	u	v	w	x	y	z	A	B	C	D
3	E	F	G	H	I	J	K	L	M	N
4	O	P	Q	R	S	T	U	V	W	X
5	Y	Z	0	1	2	3	4	5	6	7

To find a character, just look it up in the chart, across then down. For example, h is 07, and i is 08. If you want to look up a word — Hello, for example — look up each character in the chart — 33 04 11 11 14. Of course, there isn’t just one character set in the world; there are quite a few. Here’s another example character set I’ll call Paul’s Second Character Set:

	0	1	2	3	4	5	6	7	8	9
0	0	1	2	3	4	5	6	7	8	9
1	A	B	C	D	E	F	G	H	I	J
2	K	L	M	N	O	P	Q	R	S	T
3	U	V	W	X	Y	Z	a	b	c	d
4	e	f	g	h	i	j	k	l	m	n
5	o	p	q	r	s	t	u	v	w	x

In this new character set, Hello is 17 40 47 47 50. You might already be able to imagine how problems can arise. If your browser tries to display data in the wrong character set, it ends up looking all garbled. Some characters may look right, while others look broken. The reason that garbled text is often mostly right is that many Western character sets put the standard English alphabet — as well as numbers and a few other things — in the same place. (My two fictional examples don’t do this.) So, those characters appear to work fine, but less common characters don’t.

This also reveals another problem. If someone simply tells you that a message is 44 04 02 17 04 19 without identifying the character set, you have a problem. You could decode the message twice and see what you come up with — in this case Secret and i32H4J — then pick whichever one looks best. One is an English word that contextually makes sense, the other could quite conceivably be a password. In the presence of other text you could probably make a decision, but it’s a mess, even when only dealing with two fictional character sets.

In order to avoid generating garbage, character sets must be considered at every step.

"/>

Truncated by Planet PHP, read more at the original (another 5617 bytes)

Testing with PHPT and xUnit

Posted: December 7th, 2009, 10:00pm MST by PHP Advent

Recently, I have been splitting my development time between the PHP extension Phar, the next-generation PEAR installer Pyrus, and related PEAR2 packages. I’ve spent a considerable amount of time developing unit tests. Over time, I’ve noticed that testing is becoming increasingly onerous. Sometimes, just running them can take up to 75% of the development time. Because I don’t like to commit changes before I know they work, my development has begun to stall, and this has resulted in longer periods without testing. Worse, others have stopped running the tests prior to committing. Gradually, the code has gotten out of sync with the tests, and this is a bad thing.

When I began developing PHP extensions, I had to learn about PHPT, the standard way to test them. I had come to a personal impasse with PHPUnit. Among other things, fatal errors would bring down the entire test suite, and this made it difficult to find the source of the error. This was back in the early days when PHPUnit was still a PEAR package. It is also worth noting that continuous integration and solutions like CruiseControl — and the PHP implementation phpUnderControl — were not yet written. If you have full access to a CI server, then by all means, use it! The xUnit-PHPT combination can still be used on the client side, prior to commit, for extra reliability.

It was at this time that I designed the xUnit-PHPT combination that I have been using since. In this article, I’ll introduce this approach and show you how it could help.

What is xUnit?

xUnit is an abstraction that describes testing frameworks that adhere to similar testing patterns. The name comes from the first one, JUnit, and the x refers to the programming language. Many xUnit frameworks follow this naming convention: JUnit, PHPUnit, SUnit, FlexUnit, ASUnit, &c.

xUnit can be considered a design pattern for testing frameworks. These frameworks split up tests into test cases, fixtures, and test suites.

A test case is a single test. It contains assertions that test the correctness of whatever is being tested. The xUnit pattern does not specify what kind of test should be written, thus unit tests, acceptance tests, regression tests, and other forms of testing can all be represented using a test case.

A test fixture provides common setup and teardown procedures for a group of related tests.

A test suite is a group of related tests. Often, test suites combine several test fixtures.

What is PHPT?

PHPT is a dirt-simple PHP testing framework that uses simple markup to delineate test sections. Acquiring PHPT is simple; you can either use the run-tests.php tool included with PHP itself, use the PEAR installer’s run-tests command, or Pyrus’s run-phpt command. In addition, PHPUnit 3.3 supports running PHPT tests as a part of test fixtures, which also allows taking advantage of PHPUnit’s other advanced features. It is important to note that there are subtle but important differences in the support for PHPT. PHPUnit uses the same code as the PEAR installer, which is identical to that supported by Pyrus. The run-tests.php tool included with PHP supports some more arcane features needed by PHP developers, and the PEAR implementation supports a few sections such as --RETURNS-- for testing shell script return values that are not supported by run-tests.php.

A PHPT test is a file that ends in .phpt. Each test contains sections indicated by two dashes, an uppercase section name, and two more dashes. (For example, --TEST-- and --FILE--.) The online documentation provides more details about the format.

PHPT tests can lever more control over the environment that a test runs in, including setting environment variables with --ENV--, setting php.ini configuration directives with --INI--, setting $_GET, $_PO

Truncated by Planet PHP, read more at the original (another 11610 bytes)

Get a Haircut

Posted: December 6th, 2009, 10:00pm MST by PHP Advent

Getting a job can be a harrowing experience. Many companies run candidates through a gauntlet of tests and interviews in the hopes of separating the wheat from the chaff. They want only the best — not just the most knowledgeable person, but also a person who fits in well with the company.

Trust me

Going through the job search process is very similar to dating. In the beginning, there’s a lack of trust that comes from simply not knowing who the candidate is and what they’re capable of. Questions are asked, and multiple dates — or rather, interviews — are necessary to determine if you’re a suitable mate — or applicant. The process is an attempt to develop a rapport and build enough trust to move on to closing the deal.

If you establish a level of trust before you even step foot into the building, you’re already halfway there. Thankfully, for those of us who make our living on the Web, there are some ways to do just that.

Show ’em what you got

Getting involved in the development community has been — for me and for many others — one of the best ways to demonstrate that you know what you’re doing. It helps establish the trust that employers are looking for. It shows that you have a passion for what you do, and can exhibit key skills such as an ability to communicate effectively.

Blog

It may seem cliché, but blogging is an extremely effective tool that can be used to garner clients or land an interview with that great company. The blog acts like a long-form resumé that highlights what you know, and what you think is important in your life as a developer.

Picking a topic to blog about may seem like the hard part. Think it has all been done before? Think again. Technology is continually evolving, and people are constantly on the hunt for tips and tricks on using these new technologies.

Start up a blog about introductory PHP tutorials, and chances are your content will get lost in an ocean of existing content. However, new language features like namespaces and closures can often be prime targets for a new audience.

Breaking out into other technologies also highlights your ability to deal with integration and shows that you’re on the leading edge of new developments. The NoSQL movement, mobile development, html5, and CSS3 are very hot topics right now.

There are plenty of new developments that need knowledgeable people to help explain them. Create a mix of content between new and old technologies, and basic and advanced tutorials, to keep your blog well-rounded.

Write a book

Writing a book provides a huge sense of accomplishment and pride. It’s a long and arduous process, but it’s a great feeling to walk into a bookstore and see your face on the shelves.

Book writing isn’t the only venue that’s available, either. Look to print and online magazines as alternatives for getting you and your knowledge out there.

In my experience, books don’t do much to get your own personal brand out there unless you’re lucky enough to write a successful book that sells well. However, the clout that comes with having written a book is, in my opinion, still worthwhile.

Contribute to a public project

People usually suggest that you contribute to an open source project, but I contend that — while it is certainly advantageous — it isn’t the open source project that is the key. It’s the fact that there’s a public record of contribution to a project that other people use.

I’ve put together cheat sheets, color pickers, web apps, desktop apps, and, yes, I’ve even contributed to open source projects. But each tool that I built offered up the possibility of getting my name out there in front of yet another new audience of people.

Speak at an event

Public speaking has a number of advantages, and there are easy and hard ways to break into it. I readily admit that public speaking isn’t for everyone. It takes a confident person to stand in front of a room of dozens — if not hundreds — of people and to be able to do it with panache and acclaim, or maybe that’s just what I keep hoping for!

Public speaking gets your name and expertise in front of hundreds of like-minded folks. These folks have employers or run their own companies. If you’re on the hunt for a new job, local BarCamps or user groups are great ways to get your feet wet before diving into larger events. Conferences will often have a CFP a number of months before the event takes place. Alternatively, contact the organizers of the conference and submit a talk idea.

Truncated by Planet PHP, read more at the original (another 2119 bytes)

Parenting Versus Programming

Posted: December 5th, 2009, 10:00pm MST by PHP Advent

Advent calendars are about Christmas, and for me Christmas has always been a time for family. This year I have recently joined the ranks of the parents among you. I am taking a short break from work and focusing on being a mother rather than being a programmer. This has led me to reflect on the similarities between parenting and coding. I present these here for your enlightenment, or so you can laugh at me.

Lesson one: smells

Babies, like programs, are associated with a variety of interesting smells. If you try to ignore the smells associated with babies, they only get worse over time. Then the screaming starts.

It was Martin Fowler who popularized the notion of code smells. These are defined as parts of your code that do things in an ugly way, or to put it a different way, they are hacks. Typically, when we find these parts of code, our eyes begin to glaze over, and we enter a strange, zombie-like state. (This will also be familiar to parents.) In this state, we are paralyzed and thus prevented from doing anything about the smell. It is only when we emerge from the cave of code smells into the daylight of clean code that we can again be productive. I am not sure whether it is the horror of the code, a tendency to procrastinate that is endemic among programmers, or simply a fear of breaking things that prevents most people from doing something about the mess. It is always the smelliest parts of the code that are the most fragile.

The lesson programmers can learn from babies, here, is to face your smells and get rid of them as quickly as possible. Then everybody’s happy.

Lesson two: sleep

I have now been programming for mumble years. Not long after I started work at Mozilla, a delightful Canadian journalist asked me what it was like to work with a group of people “so much younger than myself.” While I am not actually that old, I am old enough to have picked up some skills. One of these skills is the ability to survive on 4-to-6 hours of sleep a night for extended periods. Although this is not my favorite hobby, I have gained a certain level of mastery.

Another thing I’ve learned is that surviving on 4-to-6 hours of sleep a night for an extended period makes you mildly deranged. With parenting, as with programming, it is sometimes required. When you achieve a certain level of derangement, you find that very silly things start to sound like good ideas, or they just start to happen, whether you intended them to or not. For example, you find yourself accidentally filing the baby in the filing cabinet or implementing a new framework.

This is a lesson both programmers and parents can learn from the military: sleep when you can do so safely, and as often as possible. If you can snatch a few minutes of nap here and there, it may not make you feel a lot better, but your degraded IQ will recover somewhat.

Lesson three: with great power comes great responsibility

When you set out to implement a new web app or raise a child — and yes, I do realize these things are not quite on the same scale — you have a great responsibility to do a good job. Otherwise, everyone who has to interact with your app or child in the future will curse your name. Repeatedly. Your baby — whether it is human or code — is totally dependent upon you to do a good job.

Lesson four: it takes a village

On that note, it is important to realize that it is very hard to raise a child or write a web app completely on your own. Some things are better done with a little help from your friends. Whether that help is providing a role model, a shoulder to cry on, advice when you just don’t know what to do, or purely someone to vent to, it really helps to surround yourself with people you can rely on.

That summarizes the commonalities between parenting and programming that I have learned over the last 7 weeks. I suspect I have a great deal more to learn.

One final note: If anyone approaches you to work on a web app that will take 18 years, run away as fast as you can, and do not look back.

If you’d like to comment on this article, please visit my corresponding blog post.

Automate Your Deployment

Posted: December 4th, 2009, 10:00pm MST by PHP Advent

Deploying your web site to a server can be an exercise in frustration and fraught with mistakes. There’s a lot to remember during deployment, from using the correct transfer system to ensuring that caches are cleaned. We aren’t very good at doing the same thing twice, in exactly the same way. Computers, however, are. Automation of deployment steps reduces our stress, and fewer mistakes are made.

Getting your house in order

Before we start, there’s a certain amount of housekeeping that needs to be in place to make deployment easy and consistent.

Source code control

It all starts with control of your source code. If you’re not using a version control system such as Subversion or Git, then sort this out, first! These systems add discipline to your development processes. You should use branches for each new feature (and bug fix) that you develop.

The most important reason to branch is that many clients will approve work in a different order than it is requested. You may have multiple features in development, simultaneously, and need to put them live independently of each other, as they are approved. Branching allows this to happen without accidentally releasing features that are not yet ready.

You also need to be able to handle an urgent bug fix for the live site. This situation always seems to occur when you are in the middle of a significant block of work that has dramatically changed the code in question. A bug that is noticed on the live site needs to be fixed, immediately. If you are not using branches, then you have to separate the work you have been doing, which is not fun and is prone to mistakes.

Using branches ensures that you can always have a version of the site ready to go live. There are two approaches that can be used to organize your source code repository to achieve this: trunk-based deployment, where trunk is always ready to go live, and live-based deployment, where you create a branch called live that is always ready to go live.

With trunk-based deployment, you use branches for integration work that may be required between features. With live-based deployment, you create a branch called live and use trunk for integration work. The latter allows you to cherry-pick and merge just the wanted code into the live branch, and then deploy. In general, for smaller teams, trunk-based deployment works well, and for larger teams, the additional control provided by live-based deployment is very beneficial.

Database considerations

While you are making deployment of the source code easier, you should also pay some attention to your database management strategies. Specifically, you need to control the schema across your live, staging, test, and development servers. As you develop new features on your web site, you will find that you need to change the database schema. The best way to handle this is to version your database with a special table in the schema containing the current version number. You can then write the schema changes that describe how to change to the next version. These are known as up deltas and you should write a corresponding down delta for each of these that describes how to revert to the previous version of the schema.

There are a number of tools that will manage this type of database migration for you. The most commonly used projects are DbDeploy, LiquiBase, and the migration code in Doctrine. Of course, you could also write your own scripts in PHP.

Code considerations

You need to ensure that your source code is prepared for automatic deployment. This means that you need to be aware that the same source is running in different environments, and the code must be able to handle this. Usually, this means that you need to control your configuration, and you should load the correct settings based on where the code is deployed. One mechanism is to automatically detect the environment, based on the URL being used to access the site. This usually means that you have specific keywords in the URL for development, testing, and staging, and then assume that you are loading the live configuration if none of these are present. Another option is to set an environment variable (using SetEnv) within the Apache VirtualHost definition, and then use the getenv() function to retrieve it within your source code.

Automation strategies

When deploying to a server, there are a number of things that you need to consider when planning your strategy. The most importa

Truncated by Planet PHP, read more at the original (another 7362 bytes)

One Step at a Time

Posted: December 3rd, 2009, 10:00pm MST by PHP Advent

I have the privilege, in my current line of work, to be able to attend quite a number of conferences and other technical events throughout the year. At every event, I meet people for whom this is their first experience at a technical gathering; sometimes they make contact through the pre-conference channels and have many questions about what to expect. For these people, everything is novel; the talks, speakers, and content are all new and often make a big impression on these new attendees. I always advise people not to think that the event finishes when the schedule says it does, and often they will take the opportunity to hang out with the community and make discoveries there as well.

When I chat with these new — or relatively new — additions to our community, I ask them how they enjoyed the event. Almost without exception, they tell me how much they learned, and how much they learned they have to learn! This is the experience I have at every event I attend, and it’s a feeling that fills me with enthusiasm for knowledge and improvement. I have noticed, however, that others take this quite differently.

They tell me that, yesterday, they thought their applications were pretty good, they met their deadlines, their applications worked, and their clients paid their bills. For me, this is a pretty good definition of success, but they will earnestly tell me that they now know this is not the case. After all they see at the conference, they realize there is so much to learn, and their reaction is to be utterly overwhelmed and feel as if “best practice” is something unattainable by mere mortals. (I’m generalizing, in case that isn’t obvious.)

Earlier this year, I was involved in organising the PHPNW conference — the conference of my local user group — where I gave my talk entitled Passing the Joel Test in the PHP World. The Joel Test is a series of 12 criteria that, according to software guru Joel Spolsky, all good software teams should meet. In reality, there are some changes to make to the test, and the original points plus the suggested changes are the features of this talk. I found that after the talk, people came to me and told me that their organizations were only scoring 2 or 3 points out of 12, and many felt that their teams were out of reach of the standards set by the highest-scoring organizations.

This perspective strikes me as being slightly defeatist. The mountain is too high to climb, so the attempt is to be avoided, and the mountain’s existence denied? Nobody who speaks at a conference does so to put people in their place or discourage anyone. Another approach is to take a look at all these new ideas and decide where to begin. Many of the concepts presented at conferences aren’t applicable to every scenario. Some things that you see will rely upon development processes that aren’t currently in use within your team, or may not fit in well. Other things are too advanced to pick up immediately and should instead stay in your mind as ideas to keep reading about, look out for tutorials on, and implement… eventually. “Rome wasn’t built in a day.” This is true of best practices, too.

Improvement is an incremental process, and the next step might be starting to use source control or unit testing or continuous integration or any of a huge raft of other things which would improve our development process or make our lives easier. Making a change like this in an existing development team, which already has deadlines to meet, can be difficult for a number of reasons. One hurdle is that new tools and processes need multiple iterations to select, set up, and implement, and it can be hard to quantify at the outset how much time that will be. New infrastructure may also be needed, which is another barrier. But, perhaps the most frustrating of all is how difficult it can be to implement changes with an existing team. Although we all know that source control (or whatever improvement is under discussion) will make our lives easier in the long run, getting everyone to buy in to the short-term disruption can be truly difficult. Taken altogether, these difficulties can make improvements and better practice seem unattainable.

I’m a firm believer that you can do a lot with only a little. Implementing a new tool is a long and arduous process, or can be, but how do you think those experts got to where they are today? What do you really need to get started with the new improvements? You could install it on your development machine, see how easy (or not) it is to get set up. You could trial it for your own development, or invite a couple of people to try it out for an internal project. Make sure you know where t

Truncated by Planet PHP, read more at the original (another 1952 bytes)

Do URLs Matter?

Posted: December 2nd, 2009, 10:00pm MST by PHP Advent

I liked how Chris and Sean describe their role as curating PHP Advent, so I thought I’d do a little sub-curation of my own. This entry is a point-counterpoint on the topic Do URLs Matter? The contributors’ thoughts are below, followed by my conclusion.

Of Course!

— J. Random Programmer

Of course URLs matter! Without clean URLs, it wouldn’t be obvious where you are just by looking at the URL displayed in the address bar. Who can remember long strings of jumbled letters and digits to type in compared to something elegant like http://pants.com/blog/my-dinner-with-barack‽

Plus, I’m always noodling around with the URLs I see, so it’s nice when they’re easily hackable. If I see a page like http://pants.com/forum/topic/23, it’s easy enough to swap in 24 or 22 for the 23, and browse around.

It sure does bug me when those URL shortening services transform my beautiful URLs into tiny garbled squibs. How do people even know where they’re going to end up when they click on one of those things? It’s almost as if the URL itself is just a means to an end to those people.

What?

— A. Normal Person

I’m not really sure what a “URL” is but when David asked me to write this, he said something about the way to find Internet web pages, so here’s how I look at them:

People send me emails with blogs to read or YouTubes to watch, so I click on the blue part of the message to see the blog or the YouTube.
Sometimes, I’ll make a bookmark when I’m looking at something I want to see later, so I can visit it from the bookmarks menu on the computer. Also, my computer came with a bunch of bookmarks already on there.
Occasionally, I see one of those .com web page addresses printed somewhere, maybe in an ad on TV or on the side of a bus. If I type that address into the Google, then I get to see the Internet web page that the ad was for.

Conclusion

People don’t care about URLs. The few normal humans who still occasionally type in a URL are going to stop doing that once their iPhones get better at reading 2-D barcodes.

If you’re designing a web service to be used by programmers, then URLs matter as much as function names matter in a well-designed library. Would you rather call strlen() or func_73d3a702db472629f27b06ac8f056476()? This is not something salient about URLs, but just a general principle of human mental capacity. It is easier to refer to 7000 + 14 as “7,014” than as “Máximo Pérez.” (To read more about that, visit this URL: [www.amazon.com] .)

A grumpy “SEO Professional” is reading this right now and saying “No, he’s missing the point! The clients for URLs aren’t humans, they’re search engines! I need to tell Google what my page is about in the URL.”

Mr. Grumps is not entirely wrong, but SEO-friendliness is orthogonal to human-readability. That Amazon URL up there works just as well (from a loading-the-right-page perspective) written as http://amazon.com/dp/0140286802. The rest is just fluff to make some automated system (a search engine, clickstream analysis processing, &tc.) happy.

There are a variety of reasons to structure your URLs a certain way, such as making search engines happy, making developers using your service happy, or keeping yourself sane when you build a web site. Providing utility or aesthetic pleasure to regular people who use your web site, however, is not one of them.

You Really Need to Learn JavaScript

Posted: December 1st, 2009, 10:00pm MST by PHP Advent

PHP developers have typically worn a few hats. Few of us are “pure” PHP developers, where we only write PHP and don’t scribble together some html at least once in a while, or paste and edit some JavaScript on occasion. A lot of us — myself included — came to PHP as a way of adding new functionality to our flat html web sites, and PHP’s roots as a language that intermingles with html are a big reason for its popularity. It’s likely that PHP wouldn’t be as useful as it is on the web if it wasn’t driven by the practical needs of front-end developers.

For the most part, these skills have suited us well. Web apps have typically been focused on the server side. The web pages we view have been static results of computation done on the server, parsed for presentation purposes on the client side. We might have some flashes of dynamic html (remember that?) here or there. But with few exceptions, all of the real work is done on the server.

In the past few years, this has started to change. Clients are becoming richer, more complex, and are responsible for more aspects of the app. Web apps are becoming more balanced, with more heavy lifting on the client side. The server side is increasingly becoming a service to be called upon when the client needs more data or wants to save something for access elsewhere. Fewer and fewer server-side apps will follow the model PHP has excelled at, where it generates all of the code that’s then parsed and presented by the client. footnote 1

Yeah, you know all that. Ajax, web APIs, Twitter, etc. It’s all very exciting, and you can just have your framework generate that junk for you. You’ll be awesome, right?

Probably not. How well does auto-generated PHP work for you? Not so well. You know how you make fun of PHP “developers” who just copy and paste code, or let a tool write it for them? Well, if you don’t know JavaScript, you’re in danger of becoming that person.

When I say “you need to learn JavaScript,” I don’t mean “learn how to copy and paste an example,” or “learn how to generate JavaScript with PHP.” I mean learn it as well as you already know PHP — or better.

Why? Because JavaScript drives rich clients, and all indications are that clients will be getting richer. You won’t be able to get away with just adding small snippets of JS to add tooltips and simple animations. Complex processing and UI management will require real knowledge of how to write JS, and how in interacts with the client’s APIs — the DOM, local storage, networking, OS features, and more.

The bad news is that this will take a bit of effort. JavaScript’s syntax is fairly similar to PHP’s, but some fundamental stuff is quite different. The object model will probably confuse you at first. The scoping is very different from PHP. The malleability — how you can change fundamental behavior of built-in language constructs at will — is going to freak you out a little.

The good news is this: you will be a smarter, better, and more in-demand developer because of it. Browser makers are investing plenty of time to create better tools for client-side developers. JavaScript runs orders of magnitude faster in most browsers than it did just 3 years ago. footnote 2 Local storage APIs, WebWorker APIs (for spawning JS processes), native JSON encoding and decoding: all of these things are recent additions to most browser engines, and all of them add significant speed and/or capability for developers.

What’s been more interesting to me, beyond browser-based rich clients, is the introduction of Web Runtime platforms (WRTs). These are platforms for building desktop and mobile apps with traditionally web-oriented technologies, like html, CSS, and JavaScript. This approach has some significant advantages over deployment in the browser, mostly related to consistency of rendering and additional APIs. Titanium Desktop from Appcelerator is especially interesting to the PHP developer, as it allows you to develop in PHP (as well as in Python and Ruby) in addition to JavaScript.

Mobile apps seem to be gaining dramatically in popularity as their devices gain market share. WRTs are available for many major mobile platforms, such as:

iPhone

Truncated by Planet PHP, read more at the original (another 3726 bytes)

Comprehensible Code

Posted: November 30th, 2009, 10:00pm MST by PHP Advent

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

— Refactoring: Improving the Design of Existing Code, by Martin Fowler.

Reading of any sort is a difficult and high-effort task. Human beings need years of training to learn the basics of reading, and more years after that to master comprehension of the written word. Once you have learned how to read, it’s easy to take it for granted, but it remains a difficult task, one that requires effort and concentrated attention. Reading for retention and comprehension is especially hard work.

Now, think of what it takes to read code. Not only do you need to understand the programming language, you also need to understand the commonly-used patterns and structures of that language. Every programmer is an author, potentially with his own idioms and expressions and almost certainly with his own style. Programming languages are not as nuanced and interwoven as natural languages, but they still require effort to interpret and understand.

Effort vs. Reward

Reading code feels unproductive. In reading, you may be gaining knowledge about a program, but you are not creating anything new. At best, you are comprehending the previous work of someone else. To a developer, especially one who thinks he is being paid just to write code, the level of effort involved in understanding the work of another developer seems like a horrific waste of time. The high-effort, low-reward feedback loop is frustrating.

Alternatively, the effort-to-reward feedback loop for writing new code is very short and feels very positive. It’s much less frustrating than trying to understand the work from another developer, because you are the developer. It feels immediately productive, because every line you write is something new you can point to as the result of your efforts. This kind of instant gratification is hard to resist.

Code as Communication

A large part of the problem in reading code is that most programs are written in the moment, not thinking ahead, and not thinking of the other developers who will have to read the program. It is natural to think of the program as being for the computer, but this is not entirely the case. As a developer, you have to deal with two readers: the computer, and other developers. Your programs are a medium for communicating, indirectly, with other developers. Code is a conversation between you and the developers who have to work with it.

For other developers, reading your code is hard work. To them, reading your code is a learning exercise. They have to figure out what problem you are trying to solve, what you are doing to solve it, and why you are taking a particular approach. Once you realize that reading code is a learning exercise, you can begin to appreciate that you should write your code as a teaching exercise so they can learn more quickly. This may be more work for you, but it is the high-reward kind of work that developers like.

In short: when writing code, remember the poor bastard who will have to read your program. That poor bastard may be you, six months from now.

Toward Better Communication

What can we do to make our programs easier to comprehend? There are many volumes on this subject, such as Code Complete. There is little I can add to these technical treasures.

However, in addition to the technicalities of code organization, there are many softer guidelines that make a great difference in comprehensibility. Think of these softer styles as making the difference between reading an Army technical manual and a good tutorial. The technical manual may have perfect grammar and structure, but lacks comprehensibility, whereas the tutorial has good grammar and good style.

Here are three communication measures you can adopt to improve readability and ease-of-understanding in your own work:

Adopt a coding style standard already in use by others.

I have long been a proponent of shared coding standards. In a way, using a shared standard is a variation on Jakob’s Law: “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.” The same thing applies to code; if your code is styled and organized in a common fashion, you (and other developers) can read it with much less cognitive load.

I am a fan of the PEAR style guide; I gave up my own style long ago in favor of it. When comparing the PEA

Truncated by Planet PHP, read more at the original (another 3003 bytes)

	0	1	2	3	4	5	6	7	8	9
0	a	b	c	d	e	f	g	h	i	j
1	k	l	m	n	o	p	q	r	s	t
2	u	v	w	x	y	z	A	B	C	D
3	E	F	G	H	I	J	K	L	M	N
4	O	P	Q	R	S	T	U	V	W	X
5	Y	Z	0	1	2	3	4	5	6	7

	0	1	2	3	4	5	6	7	8	9
0	0	1	2	3	4	5	6	7	8	9
1	A	B	C	D	E	F	G	H	I	J
2	K	L	M	N	O	P	Q	R	S	T
3	U	V	W	X	Y	Z	a	b	c	d
4	e	f	g	h	i	j	k	l	m	n
5	o	p	q	r	s	t	u	v	w	x

	0	1	2	3	4	5	6	7	8	9
0	a	b	c	d	e	f	g	h	i	j
1	k	l	m	n	o	p	q	r	s	t
2	u	v	w	x	y	z	A	B	C	D
3	E	F	G	H	I	J	K	L	M	N
4	O	P	Q	R	S	T	U	V	W	X
5	Y	Z	0	1	2	3	4	5	6	7

	0	1	2	3	4	5	6	7	8	9
0	0	1	2	3	4	5	6	7	8	9
1	A	B	C	D	E	F	G	H	I	J
2	K	L	M	N	O	P	Q	R	S	T
3	U	V	W	X	Y	Z	a	b	c	d
4	e	f	g	h	i	j	k	l	m	n
5	o	p	q	r	s	t	u	v	w	x