blogZero

Okay, now we're getting somewhere! Still dissatisfied at my attempt to reduce the glut in the parent PHP category page, I took yet another look. Wouldn't you know it? There was a definite thread of resources in there relating to improving the performance of applications written in PHP. Not surprising given the growing complexity of the language itself, the applications written in it, and the myriad of Frameworks available these days. The latter is especially critical, because with abstraction, underlying complexity, and growing feature sets, before you even start a project your code base is large. Very large. I'm not going to name names, you know who you are.

Frameworks

I prefer the simple over the complex, the modular over the monolithic. Given the opportunity, I would go with something like CodeIgnitor, which allows you to use the pieces you want and eliminate the rest. The same is true for templating engines. I've used Smarty of course, but it puzzles me why the developers would reinvent the wheel, so to speak, by adding an entirely new dynamic language syntax for templates, when PHP already is a templating language (and a whole lot more). I'm a Savant man, call me an idiot.

Web Publishing

Now we're getting into that gray area I've mentioned before. Is Drupal a framework, a CMS or an application? In my mind, some of each. Wikis and blogware packages I consider applications. It certainly helps to be a developer to get the most out of them, but it isn't strictly necessary.

User or Developer?

And this is also the point where I change my stance on complexity and features. There are certainly faster and easier to use Wiki packages than MediaWiki, but do they have all the power? As always there is a trade-off. I get frustrated with Firefox for instance, because it has become rather bloated and I have bloated it even more with lots of extensions. But as a developer, and a bit of a designer, I could not live without FireBug, Web Developer, ColorZilla, and countless other tools. Christ, I'm not even sure how the hell I managed back in the bad old days of using telnet to test HTTP requests.

Simple vs. Complex

My own philosophy on programming goes like this, start with primitives and build complexity as you move up towards the more abstract and powerful—without going too far. We can see this in the OSI layer model, and an even better example, the early days of Unix. When Dennis Ritchie got tired of working on the kernel in PDP assembler, he took the time to build the more abstract language C. Funny how all the scripting languages, tools, hell, pretty much everything, is written in C, but now days how many of us code in C anymore? Even many of the extensions written for languages like Perl, Python, and of course PHP, are written in C. And there is a damn good reason for this: Performance.

Extensibility

This concept, to me, is absolutely key to good software. Use a high-performance compiled language to build the tools and you're left with solutions that are both easy to apply and responsive. The best of both worlds.

Results

Okay, and now for the final tally. After fragmenting the PHP category into "general" (now around 50 resources) there are six sub-categories (for a total of around 50 also). Divide and conquer my friends.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

This is the fifth and final installment of the Specificity series. In it I'll be taking a look at open-source blogging systems written in PHP. The last post on debugging PHP was a bit of a departure, this one lands squarely back in the realm of targeted CMS applications.

What do I mean by targeted? Well, there are general-purpose CMS packages, and there are ones that are designed for a more specific role. But this gets confusing, because many cross over into other territory. Take for example Trac. Is it a software documentation Wiki, a front end to Subversion, or an issue tracking package? Well, all three.

Blogware

But we should get back on track. The number of features in a sophisticated blogging platform is remarkable. The guys who build these packages are very talented (for the most part) and work their butts off. And users new to blogging may find that the jargon alone is overwhelming. But the cool thing about these packages is you can start with a simple one, and work your way up as you get comfortable. Lots of them have import/export features that allow you to move data from one to the other.

If you're in the market for any of this software, take the time to do your homework. And remember you can always try before you install, or go with a hosted solution so there's nothing to do except tweak your blog until you're satisfied. And if you're not, try something else!

Conclusion

There is no conclusion. I succeeded in nothing I set out to do. Instead of making any headway towards trimming the number of reviews in the PHP category, I more or less only moved a handful and added a bunch of additional ones to the newly created sub-categories. I will probably take a closer look and do some more segmenting. At the very least I learned a lot about the topics covered in this series.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

Yes, I'm aware that a spider isn't technically a bug, but the cool thing about spiders is they eat bugs. This mechanical spider by Belgian sculptor Stephane Halleux looks especially menacing.

But we're not here to talk about spiders, we're here to talk about software bugs, and more specifically, debugging PHP code. In this fourth installment of the PHP Specificity series I'm going to break from the theme of content management packages momentarily and get into a topic that is not so dear to the programmer's heart. Debugging is a necessary evil and can be painful at times. But the reward, when it happens, is that eureka moment when you find the bug and squash it.

Options

I'm not sure what ever happened to DBG. The author seems to have abandoned the project, or at least stopped updating his Web site several years back. I know the product was rolled into the commercial NuSphere PhpED PHP IDE—whether they took over the code base I'm not really sure. Another option is, or rather was, the PECL package APD by George Schlossnagle (of APC fame). But again, it seems to be dead in the water (the last update was in 2004).

Xdebug

Fortunately we have Xdebug, by Derick Rethans. It has all the features you'd expect from an advanced debugger, and a built-in profiler to help you tackle performance issues. With output in Cachegrind format, once you're done running the profiler on your code, you can fire up your favorite viewer to analyze the results.

If you are an IDE fan, you might want to try the Eclipse PDT, which supports both Xdebug and the Zend Debugger. Or, if you're old-school like me and a Vim user, you can configure the editor to use Xdebug with the DBGp plugin.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

The third PHP sub-category I selected was Content Management Systems, abbreviated CMS. There is a bit of a gray area between software that is considered a CMS, a Wiki or Blogware. The whole genre is often referred to as Web publishing software, which makes sense. The one thing they all have in common is the ability to quickly and easily add content to a Web site without needing to understand every gory detail of a markup language like HTML. It certainly helps, but it isn't a requirement.

CMSs are generally more sophisticated than Wiki or Blogware packages. They typically target the newspaper industry or some other publishing organization with multiple employees that serve various roles. For instance writers, copy editors and on up the ladder.

Content

In all cases, the user normally adds content through a Web browser form in what is known affectionately as a sandbox. I'm actually doing so right now as I create this blog post. Most offer a lightweight markup language making it easy to create links, headings, text formatting, and so on. Other features include content metadata and automatic indexing of content making the entire site searchable by its readers. High-end, commercial CMS packages also allow the same content to go to print as well as the organization's Web site.

With that said, I'm only going to list open-source packages—the best-known of which is probably Drupal.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

The second sub-category I decided on to sub-divide my many PHP resources was Wikis. I love wikis, they're easy to use, they're a great tool for documenting just about anything, and most of all, they're organic. Organic, as in always changing and growing, not as in food—although I do eat lots of organic food. Hey, it's a lot better than eating your own dog food.

The WikiWikiWeb

It's been over 10 since Ward Cunningham came up with the wiki concept, and if you ask me, the guy was a genius. Ward, with co-author Bo Leuf, built the very first Web-based wiki called WikiWikiWeb—go figure!

Wikipedia

Despite the controversy, and probably because of it, Wikipedia consistently ranks in the top 10 most visited Web properties. I use it constantly, almost as much as Google. Hell, when you're searching for something one of the first links usually is to Wikipedia (note the dog food link above). Although rarely, I'm even a contributor myself.

MediaWiki

After submitting this post I took the time to install MediaWiki on my own server. To share the love, I wrote up an article on my experiences doing so, and added some tips on how to create Friendly URLs.

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

I'm not a big fan of either really long pages, or the paging of results. Who goes past the first SERP on Google? I do fairly often when drilling down, plus you can find some real gems if you don't give up so easily. But there is a damn good reason why Web site owners want to land on the first page given a certain set of keywords—because most people don't even bother looking past the first five links.

In my case, the PHP category of my Web Developer Resource Index was getting ginourmous . I mean out of control, practically unusable. Not to mention the download time. Which is a real shame, considering it is one of the most popular pages on my site. Something had to be done I tell you!

But rather than spending the time and effort to implement paging, I took another approach. And that was to get down to specifics. This was really a taxonomy problem, and the key was to break the page up into a top-level (general) category, and then divide the rest into sub-categories.

The first of these was, as you might have guessed, PHP Frameworks. Now I'm not listing every PHP framework on the planet, there are some pretty good ones and there are some really bad ones. In addition, the page has links to articles and other resources. And I can add more without thinking "oh crap, yet another PHP resource to add to a page that already has close to 100 of them!"

Specific Navigation

• Part I: Frameworks
• Part II: Wikis
• Part III: Content Management Systems
• Part IV: Debugging
• Part V: Blogware
• Part VI: Performance

The DC PHP Developers Group didn't meet last month since our old venue at the National Press Building is no longer available. After a long thread on the group's mailing list, the new location we settled on is the MLK Library at 9th and G Streets, NW. As you can see from the photo, the library is right across the street from the Gallery Place/Chinatown Metro Station (use the 9th Street exit) which services the Red, Blue and Orange lines. It's also a short walk from Metro Center (use the 11th Street exit), so all lines are covered. Not only does this make the location convenient, there are also a ton of bars and restaurants in the area for those who might want a pint or a bite (or both) after the meeting. The library closes at 8:30, so the meeting time has been rolled back to 6:30 PM. For folks who normally drive, the library has an underground garage. To find the entrance, drive to the interesection of H and 10th Streets, then turn south onto 10th. Turn left onto G Place, the ramp down to the garage will be on your right.

I am told the new room is quite a bit larger than we've been used to at the Press Building. This is good news as we were packed in there like sardines at the January meeting. No more standing for two hours if you arrive late! This month's meeting (tomorrow, Wednesday, March 14th) features not one, but two presentations. Ray Paseur will present Learning Algorithm for Popular Search Terms, and Ben Colombini will present A Basic Drupal Module. Details are available at the group's Web site.

I'm still waiting on Robyn to find out what the actual meeting room number is, I'll post an update when I find out.

Update: The meeting will be held in room A5, one level below the main entrance.

In my second visit to the DC PHP Developers group meeting I joined yet another over-crowded room of local programmers for this month's presentation. I really appreciate Robyn Wyrick's efforts to put these meetings together, but it's becoming clear that the venues provided by the National Press Building are faltering—a testament to the growing popularity of the group.

Jonathan Modell was tonight's presenter. A DC local, recently returning from a 10 year stint in Colorado (my home state, or more accurately I was born in Durango and then lived in Boulder for a year), Jon has extensive experience in many aspects of Web development.

His presentation focused on how he learned to integrate Ajax technology within a core PHP system. Obviously this is a hot topic, if somewhat too hot in my opinion. In a nutshell, Ajax allows you to create an HTTP request back to a server-side script, and then dynamically insert the results into your page via the DOM—all without having to POST or GET a new page (something most PHP programmers are well versed in).

Web-based applications that quietly introduced this technique are most famously associated with Google. First was "suggest" a sort of search as you type, and then Gmail and many others that began to reinvent how Web pages could improve interactivity. In truth, it was Microsoft (circa 2000) who first implemented the XMLHttpRequest (XHR) object in their version of JavaScript (jscript). Later browsers (Firefox, Safari, et al.) followed suit.

As the function implies, the traditional payload of a server-side script called by an XHR request is XML. I know of very few people that continue to do this. By far the simplest method of dynamically insterting results into your page is to use a element with a unique id, initially hidden via CSS, then grab the data returned as normal markup (for instance a set of unordered list elements), then use innerHTML to update the DOM, and finally "unhide" the element (typically a <div>). This technique is sometimes referred to as AHAH.

JSON is another lightweight technique for returning data to the requestor. It's basically serialized JavaScript in the form of name/value pairs that you eval() on the client-side for parsing and insertion into your page. In addition to JSON, the Yahoo! Developer Network set of Web services are able to return serialized PHP. Although not as applicable to an Ajax implementation, it is none-the-less an interesting method worth investigating. If there is such a beast as a JavaScript unserialize PHP function or class out there, by all means drop me a comment. For PHP developers interested in available packages for encoding and decoding JSON data, visit this comparison of PHP libraries. As of PHP version 5.2.0, JSON support is native.

In the early stages of his presentation, Jon confessed to having tested many of the Ajax JavaScript libraries that are floating around out there, and then spoke highly of his choice to use Sam Stephenson's Prototype. He is not alone, not by a long shot. There are a number of frameworks that are built on top of Prototype: RoR, Rico, and "effects" libraries that include script.aculo.us and moo.fx. PHP frameworks with built-in Ajax support include CakePHP and ModX.

If you are doing this sort of development work, I cannot emphasize enough how much Joe Hewitt's fantastic FireBug Firefox extension will save you hours of headaches.

To conclude his presentation, Jon demoed a social networking application that displays a calendar of events and the members who are attending, locations, dates, and so on. I came away with the feeling that traditionalists in the audience were impressed how the page would update without the need to refresh it. But keep in mind that is the nature of asynchronous requests. There is nothing particularly new going on here, these are normal HTTP requests, they just happen to occur in the background via JavaScript and a little DOM magic to alter the page on the fly.

I was way overdue and finally made it down to the National Press Building (map) for my first DC PHP Developers group meeting, and I was pleasantly surprised by the turnout. The conference room (#495) was close to standing room only and additional chairs had to be brought down so everyone had a seat. I'm not sure if this was atypical, maybe it had something to do with the presentation. This, in contrast to the Washington Web Standards group meetings, which are very informal and only a handful of people (at best) regularly show up.

I suspect the reason for the strong showing was Keith Casey's presentation on the Smarty templating engine. He was obviously enthusiastic about his recent experiences working with it, and went beyond simple include/if/foreach constructs in your markup, or the "view" side of separating your application into data/code and presentation. Smarty also allows you to create custom filters, or plugins, which boil down to PHP functions that can be used in your templates to deal with special situations.

As ever, I will not mince words. I still cannot see how a "designer" would be any less intimidated by editing templates over markup embedded in a PHP module using here document syntax. I had the same impression I've been seeing for years, being this separation of the "progammer" camp and the frontend designer. To me, Web development is the whole ball of wax. You should understand everything from Internet protocols, server configuration, valid and semantic markup, CSS/presentation, database design, efficiency, security, and so on, or you pigeonhole yourself into one role.

And I didn't even mention client-side stuff like JavaScript/DOM scripting, or XHR.

Another thing that puzzles me are constant references to the MVC paradigm. "This is not a new idea," one that predates the Mac and DOS/Windows, not to mention Linux, by a long shot. MVC is rooted in the research done on GUI design at Xerox/PARC. For a generic overview, MVC is composed of:

• Model — Data and the logic to access it (the backend).
• View — Presentation or user interface (the frontend).
• Controller — Event handlers (most of which is already done by the browser unless you are using scripting).

I admit the latter isn't quite that simple. Server-side code (other than preemptive client-side validation) would include such things as processing form inputs and the security baggage that goes along with it.

My design and development philosophy has always been deeply rooted in the original principles of Unix and KISS. How many layers of abstraction are necessary? Or worse, layer after layer after layer...when does the developer lose all sense of the underlying system? I'm not advocating coding server-side HTTP responses in assembler or C/C++ (which I have done), but when I see programmers writing classes using methods that are nothing but wrappers around PHP functions, which are themselves wrappers around library calls that then make system calls...I hope you see the point of this rant.

However, it was a good presentation and Keith's strongest assertion, one I happen to agree with, is this: If you are going to use a templating engine Smarty is worth considering. It is mature, has a strong and loyal userbase, and is well maintained and documented.

Related reading: PHP Templating Engines.

Although I won't be attending the 2006 DC PHP Conference, since I am a local and a PHP developer, decorum states I should post an announcement about the gathering. The 2-day conference begins next Thursday, October 19th at the L'Enfant Plaza Hotel. The reason I'm not going? Partially because of the focus on the Federal sector, which doesn't interest me, and partially because of the expense. Now if I had an employer willing to foot the bill, I definitely would attend.

Assuming I was going to be there, I wouldn't want to miss Rasmus Lerdorf's keynote Getting Rich With PHP 5, and presentations by Laura Thomson and Chris Shiflett (both of OmniTI). It would also be interesting to meet Ben Ramsey and some local PHPers that I have only talked with via email.

For more information on who will be appearing, have a look at the conference schedule.