blogZero

WordPress: Whoa!

dwclifton@gmail.com (Douglas Clifton) — 2008-11-23T13:42:00Z

After my incredibly frustrating experience installing and configuring Textpattern, I decided to give WordPress a shot. Talk about night and day. You would either have to have years of experience working with Textpattern, or be a complete masochist, to even consider going with that package.

Neither of which includes me. After downloading the archive, creating a directory for it, unpacking the software, creating a MySQL database complete with credentials, running the installer, a little fiddling with rewrite rules—I had WordPress up and running with friendly URLs in 10 minutes. Okay, maybe not the famous 5-minute install, but I'm cautious and don't like to make mistakes that come back to haunt me later.

Themes

The default theme is okay, or you can go with the "classic" interface via the base install. Both one of which are a big improvement over Textpattern's default (boy, TP sure is the whipping boy around here lately). Anyway, I shopped around for a nice theme and quickly settled on iNove which is slick out of the box, and I discovered later really easy to tweak. Right off the bat I was impressed with this guy's skills. Little things like using Sprites for icons and other imagery, make a big difference.

Plugins

Plugins are a joy to work with. They're easy to install, and if you go with crowd favorites you're bound to find one that is well-documented, smartly coded and doesn't interfere with WordPress itself or other plugins. Thus far I've installed:

Ajax Calendar — replaces WP calendar with one that doesn't page refresh
Akismet — blocks trackback and comment spam
Dagon Sitemap Generator — fully customizable sitemaps
Google XML Sitemaps — for Google indexing, not users as above
Highslide — zoom image thumbnails with many options
Markdown — lightweight markup language for easier authoring of posts
Page Links To — easily create links that are external to WP or offsite
PageNavi — advanced paging navigation
RecentComments — display recent comments in your sidebar
Related Posts — create related posts links via tags
SRG Clean Archives — search engine friendly archive listings
WP-Syntax — source code syntax highlighting via GeSHi

Administration

Like any admin interface, it takes some getting used to. But I found the learning curve fairly shallow and was soon up to speed. Configuring your sidebar is really nice. You select items on the left side to place on the right, and using Ajax you can order them however you want by drag and drop. One thing that had me puzzled at first was the four sidebar sections: north, south, east and west. At first I pictured the entire page, but then realized your sidebar is dived into top, middle and bottom, with the middle having a left (west) and a right (east). Makes perfect sense now.

Configuring the menu bar was also a little strange. These are referred to as "pages" rather than "posts." You can put anything you want into them or use a plugin such as the sitemap generator mentioned above. The interface for adding content to these pages is almost the same as regular posts, but you can disable things like commenting and such so they appear as, well, normal content. Or you can "perma" link any of them to some other page, as I did in the case of my Contact option.

I fiddled with the theme stylesheet quite a bit to get things the way I wanted. It's easy to do right from the admin interface by selecting the Design tab then the Theme Editor. I also added a Blogroll OPML link next to my RSS feed at the top of the sidebar. But that involved a little PHP coding, adding a third icon to the feeds Sprite and again, modifying the CSS. I also fiddled with some other icon sprites, but I won't go into that here.

Conclusion

There are still a few little things that perturb me, for instance, when WordPress magically reformats my raw content when I select "Edit post" from the public side. My advice is to use the admin interface for fixing typos and such. I would also prefer a post preview that doesn't involve opening a new window (or tab if you have your browser configured that way). I can understand the rationale behind it, and I'm sure I could come up with a better solution. That really is the power of open-source software, if you have the skills you can make it do anything you want. Plus, using a scripting language like PHP makes it all that much easier. Especially when the code is well written and documented. Serendipity is a nightmare, at least this old version I'm still using.

But not for long! I will announce when I plan on moving over to the new blog permanently.

Texpattern: D'oh!

dwclifton@gmail.com (Douglas Clifton) — 2008-11-21T16:13:00Z

I had such high hopes for Textpattern, I really did. I was sold on the slick looking admin interface, the tons of templates to choose from (or themes or whatever they call them). The nice, clean layout of the Web site. The tons of resources—an almost complete MediaWiki documentation site—plenty of users. Bloody wankers! I was duped!

Cut and Paste?

Oh, at first everything seemed honky-dory. A straightforward install, if a little strange (that's when it started to dawn on me). First, you create a MySQL database, assign a user CREATE, READ, WRITE, etc., privileges. Okay, I've got no problem with that. Next, run the installer. It checks to make sure it can connect to the database, okay, then it spits out this code into a <textarea> and tells you to cut-and-paste the code into a file called config.php. Cut-and-paste? Why not just create the damn file and write the settings to it? That's when the hair on my neck started to crawl. Oh, there would be more, much, much more cutting and pasting to come.

First Post

Okay, I get the sucker up and running. I fiddle with the settings to name my blog and so forth. I fix a few permissions problems on directories, no big deal. I create a quick dummy post, I click "View site" and what does it do? Tries to open another browser window. Ack! But of course I have my browser configured do redirect such nonsense to a new tab. Oh, there will be many more tabs in my future.

The first problem I run into are "friendly URLs." Which I prefer, so do users, so to search engines. Only I'm getting 404 errors. Oh god, here we go, I know what's next. Sure enough, there's an .htaccess file sitting in the root of the install. I cannot stand application packages that blindly assume you have mod_rewrite installed and .htaccess enabled. Which I do, and I don't. The latter for a very good reason that I won't go into here. At any rate, I know what to do, I create a <Directory> container for the package and set the rewrite rules in my Apache config file, then restart the daemon. Viola, friendly URLs! I promptly delete the .htaccess file regardless of "Diagnostics" telling me it's missing.

So off I go to my "View site" tab. The presentation is basic, really basic. But I'm not worried about it, I can choose from one of the hundreds of themes out there or learn how to design one myself, right? I decide to go with the former. I find one, I download the archive. The documentation Wiki tells me to follow the instructions in the archive. Why this isn't standardized is a complete mystery to me.

Zip Files?

Who uses zip files? Folks, I knew Phil Katz. He died a lonely, pathetic alcoholic in a grubby motel room at the ripe old age of 37. Okay, okay, XPInstall files (.xpi) are zipped, JAR files, almost all Unix-like OSs have open-source zip and unzip... Actually, at the time, PKZIP was a pretty revolutionary piece of software, even if Katz stole most of his original code from SEA. At any rate, this was before you could even lay hands on a 56k modem so...

Anyway, I open this archive with my trusty GUI interface for such things and after looking through the contents I find what must be the install instructions since the file is called Instructions.rtf. RTF? How about INSTALL.txt, or how about RTFM? Anyway, I'm reading the "instructions" and they tell me to cut-and-paste the contents of such-and-such a file into such-and-such "folder" (pages, styles, forms). What folders pages, styles, forms? Oh, dear lord, I think, it's time to study the database. Sure enough, CSS, forms and pages are all stored in the database instead of the filesystem. Worse, there seems to be no admin interface to deal with these things. So I open another tab to Google and start searching...and find a plugin called mcw_templates which adds the ability to import and export pages, forms, and stylesheets to/from the database. Why this isn't built-in to the functionality of Textpattern to begin with is a compete mystery to me.

It turns out the "mcw" in the plugin name is the author's initials, so I visit his Web site and promptly discover that he no longer maintains the plugin and it is now on GitHub. The former is a little unnerving, but the latter give me hope. But before I go traipsing off to GitHub I take the time to read over the instructions on installing and using it. Not encouraging: "This plugin is beta in every sense of the word, as its only been tested on my 4.03 installation. It might work on other versions, but no promises!" I have the latest Textpattern, v4.0.6, but hey, I'm a masochist so this doesn't stop me. He also states "Regardless of where its been tested, this plugin messes around with your database. Do not use it without backing up your database." Oh god, what have I gotten myself into? So I promptly back-up the DB, create the _templates directory and make it world writable, then continue on to GitHub.

Uuencoded plugins?

When I get to the repository I find Mike's blurb on installing the plugin. I read it. It says to "cut-and-paste the following data into the 'Install plugin' box" under admin->plugins. The data looks suspiciously like it's uuencoded to me (actually, it turns out to be base64 encoded which is rife in this package). According to the Wiki, this technique is justified because it "reduces the possibility of errors during transport," or some such nonsense. What transport? You mean between my clipboard and the plugins form? If anything, neophyte user error would be the biggest problem. Okay, so I paste in the data and click the submit button, which is labelled "Upload." What upload? Oh god, my head is starting to pound. At any rate, the data is decoded then you can actually view the source before clicking "Install" to add the plugin. And don't forget, you then have to enable the damn thing by going back to your admin interface, clicking on the Plugins tab, finding it in the list (if you have more than one) and clicking "No" from the Active column. All very intuitive, not!

Speaking of error-prone, does anyone remember the days when PCMag would publish those little debug .COM utilities? I sure do. In order to build them you had to painstakingly type in the data, byte by byte by byte, and then feed it to debug which would spit out the program (written in DOS assembler). Oh god, I haven't thought about that in years. You can even get the damn book from an Amazon reseller for less than a dime (plus $4 shipping of course) if you want. Sigh, I digress.

Okay, so the plugin is now installed. Now what? It turns out the semantics have magically changed and now the plugin (once active) is under the Extensions tab (much fist pounding...) and there it is, has its own tab and everything: "Template Files." Great, now I can back-up the default template and (cough) install the new one. The former works pretty well, I name it "default" (go figure) and head back to my shell to see the results. Sure enough, under the _templates directory is "default" with pages, forms and css folders. Great, I take a look at these to comprehend what's next. It helps some, but this is when things get really ugly. I back up to the _templates directory and create a new folder for the theme that still sits waiting with baited breath over in my archive application. I continue to read the instructions, which go something like "cut-and-paste the contents of this-and-that file into the other file..." Which, like an idiot, I do: 3 stylesheets, 9 forms and 5 pages.

Then, I am told to create a folder for the images used by this theme in the images directory. Which images directory? At the root? Or the txp_img directory in the textpattern folder? I'm hoping that images is the correct place so I upload away. But the instructions aren't complete yet. I have to create two new sections (search and archives). Done. Next, the theme requires two additional plugins. Being an old hat at this already I install away. After several hours, it appears, I'm ready to install the theme. Crossing my sore fingers after this tedious, error-prone process is complete, I go back to the admin interface to the Template Files extension tab. I check the dropdown and sure enough, there is the theme I labored so hard to create, and I import it. What does the plugin do first? Promptly backs up the old template theme once again and names it "preimport-data." Sigh, now I have two copies of the default theme. But what the hell, you can never have enough back-ups, right?

Deprecated tags

So now I head back to my "View blog" tab and refresh. All seems well, until I start getting errors and warning from the engine about "Textpattern Notice: tag is deprecated" and "Article tags cannot be used outside an article context." It turns out "tags," and the pseudo-namespace txp: are Textpattern's method of including dynamic content into your templates. Reminded me way too much of Smarty. The first example, it turned out, was simply a matter of changing the sitename tag to site_name. Only not so simple really, because you have to edit the goddamn source code then reimport the templates back into the database. The second example I never found a fix for because after searching for it all I found were a shitload of sites that Google had indexed with the same exact error message.

All Your Desktop are Belong to Us

When I have a half dozen tabs running in my browser, one for my blog, one for my blog admin, one to the main Textpattern site, one to the documentation Wiki, one to the templates site, one to a forum site, one for GitHub, another for searching Google...you get the idea, there is something terribly wrong. On top of that, a shell window, a text editor window, a GUI zip file archiver app...you need a 40" monitor just to install this damn thing.

Textpattern, I've got one word for you: disappointed.

app> rm -rf tp
app> mysql
mysql> drop database tp

Bye-bye Texpattern.

PHP Specificity Part VI: High Performance PHP

dwclifton@gmail.com (Douglas Clifton) — 2008-11-20T11:23:00Z

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

MediaWiki Installation: Friendly URLs

dwclifton@gmail.com (Douglas Clifton) — 2008-11-18T16:06:00Z

Last week, while researching and evaluating open-source software packages written in PHP, I naturally took the time to install some of them to see how difficult it was and note any problems I might encounter. One of these was of particular interest. MediaWiki is the software that drives Wikipedia and the rest of the projects under the Wikimedia Foundation umbrella.

Goals

Some of the goals I had in mind when I set out on this little project were:

Follow best practices.
Virtualize the install so PHP scripts and other resources visitors should not have access to are hidden.
Friendly URLs—I don't want to see any .php extensions while browsing.
Customize the install for my particular needs.

Root

For security reasons, and the threat of downtime from customers who don't know what they're doing, most hosting companies severely limit what you're capable of doing in a shared environment—and of all things they're not going to give you root access or sudo(8) privileges. Even on a dedicated server this can be a sticky situation. In order to follow the instructions below, at some point you're going to need that capability to, for example, restart you're Web server daemon. If you're running Ubuntu or another Linux distribution, or Mac OS X, on a local development box, you should be all set. You should also be comfortable using a shell and know how to edit text files.

Download

First you need to grab the source code from the MediaWiki Web site. You'll find it on the Downloading MediaWiki page. It comes in a tarball—make sure you get the latest stable version. Also make sure you meet all the requirements before attempting the install. It helps to know which versions of PHP and MySQL you're running beforehand.

Upload and unpack

After you download the file, upload it to your Web server into the docroot of your site. At the time I did this the MediaWiki latest stable version was 1.13.2 (released 10-2-2008), and the name of the compressed archive reflects this: mediawiki-1.13.2.tar.gz.

Fire-up your shell client and visit docroot. You can decompress and extract the source in one command:

$ tar xzvf mediawiki-1.13.2.tar.gz

You'll see a whole flurry of activity as the package is creating its source tree and populating the directories with files. You'll be left with a directory, just off docroot, with the same basename as the archive. The first thing I did was rename it to something more manageable:

$ mv mediawiki-1.13.2 w

There's no need for the archive any longer so get rid of it.

$ rm mediawiki-1.13.2.tar.gz

Then change into the w directory.

$ cd w

Configuration

The browser-based installer will want to write out a file called LocalSettings.php in the config directory. To forestall any permission problems make that directory world writable:

$ chmod a+w config

Now point your browser at the directory off docroot you just created: example.com/w/ and follow the instructions to set some basic options and create the database. In a bit you won't access the w folder directly, since we are going to virtualize it and create friendly URLs. Two things to keep in mind: the virtual directory does not really exist in the sense you create it in your filesystem, and (this is important), do not use the same name for both. By MediaWiki convention this virtual directory is called "wiki," which you should be familiar with from browsing around Wikipedia.

When the installation is complete, copy the config file down to the w directory and add a few lines.

$ cp config/LocalSettings.php .

// docroot/w/LocalSettings.php

$wgScriptPath  = '/w';        // real path
$wgArticlePath = '/wiki/$1';  // virtual path
$wgUsePathInfo = true;

These settings, and one more task with your Apache config file, will take care of ever having to access the w path directly, and will give you the nice URLs we're after.

Apache

You're going to need to be root on the box to do at least one of the following steps. Since I have a virtual.conf file for this site there was no need to edit httpd.conf directly. Your mileage may vary. Either way, in the <VirtualHost> container for your site you need to add an Alias to finish this job:

Alias /wiki /real/path/on/your/server/docroot/w/index.php

It's probably a good idea to make sure your config file(s) have no errors, then restart Apache:

$ apachectl configtest
Syntax OK
$ sudo apachectl graceful
Apache gracefully restarted

Then point your browser at: example.com/wiki/ and if everything went well you'll see the MediaWiki "Installed successfully" message on the Main_Page. An even cleaner set-up would be to create a sub-domain of your site, say: wiki.example.com, and install everything in the docroot. But I'm not going to get into that here.

mod_rewrite

There are a number of other solutions out there, many of them involving mod_rewrite. Unless you understand regular expressions and have some experience using mod_rewrite, or enjoy pain of the voodoo variety, I recommend going the Alias route. Why hit a tack with a sledgehammer?

Conclusion

MediaWiki is a large program and it uses lots of system resources. If you're in the market for a simple Wiki and one only you will be using then consider shopping around for something less complicated. I went for Big Daddy for a couple of reasons. One, I wanted to gain the experience of installing it, and two, I wanted to have my own sandbox, so to speak, to better understand the system, and in particular, to improve my skills editing Wiki documents using their markup language. With that said, it was worth the effort.

Although there is little to see or do, you can visit wikiZero to see the results of a fairly fresh install. Also, if you're really planning on diving into this, and you're a dead-tree fan like me, O'Reilly published MediaWiki just last month. I took a look at it and read some third-party reviews. It's a keeper if you plan on using this software to any great extent.

PHP Specificity Part V: Blogware

dwclifton@gmail.com (Douglas Clifton) — 2008-11-17T18:35:00Z

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

PHP Specificity Part IV: Debugging

dwclifton@gmail.com (Douglas Clifton) — 2008-11-15T15:37:00Z

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

PHP Specificity Part III: Content Management Systems

dwclifton@gmail.com (Douglas Clifton) — 2008-11-15T12:01:00Z

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

PHP Specificity Part II: Wikis

dwclifton@gmail.com (Douglas Clifton) — 2008-11-15T11:45:00Z

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

PHP Specificity Part I: Frameworks

dwclifton@gmail.com (Douglas Clifton) — 2008-11-14T17:00:00Z

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

JavaScript Libraries

dwclifton@gmail.com (Douglas Clifton) — 2008-11-12T09:00:00Z

What's this, no multi-page post today—complete with code examples and links all over the place? Instead, I did some house cleaning, and added a new wing. JavaScript has been such a hot topic around here of late, and in the Web development community in general, that I took a look at my growing list of resources and discovered that indeed, the JavaScript category was in need of some pruning. Amongst the list, and in particular by studying the most popular tags, I found that JavaScript libraries would make an excellent category to splinter off and reduce the weight in the parent folder. I know, I know, I need to implement paging. PHP is another one that grew out of its clothes.

Speaking of implementing paging (and caching and a lot of other things on my todo list), I have been really busy behind the scenes fixing bugs and making other improvements to both this blog and loadaverageZero in general. Some of them my visitors may have noticed, some may not. But things are definitely on the upswing around here since health has improved.

One thing that really has me puzzled is what to do with this blog. I'm running a rather old, and hacked to pieces, version of Serendipity. I don't want to let go of the design, which I spent a lot of time on, yet on the same token it bothers me that my only recourse to block spammers and other miscreants was to disable comments and trackbacks. I'm not a big fan of Captchas, I would prefer to go the OpenID route.

Anyway, I'm starved and I haven't been to the diner for some good old eggs and bacon in ages...

Open-source Server-side Web Application Frameworks

dwclifton@gmail.com (Douglas Clifton) — 2008-11-11T04:33:24Z

It just wouldn't be fair after my last post to ignore the tried-and-true server-side Web application frameworks. I am certainly familiar with all of them, though I haven't necessarily used every one in a production environment. PHP seems to be the best represented, or maybe it's just my bias considering I've spent more time using it as a Web development platform than some of the other languages. Python has several options, one of which is very popular and the other I find interesting. Perl only seems to have one viable Web framework, if there are others then I'm simply not aware of them. And of course we have Ruby, with Rails being perhaps the the most hyped out of the entire list. Would you expect anything less from the folks at 37signals?

PHP

Being a Web scripting language from the get-go, there are countless PHP frameworks to choose from. I'll concentrate on three, and list some others that I'm at least aware of.

Drupal is the big daddy of PHP frameworks, or is it a CMS? You decide. This extremely popular (insert your one word description here) "system" has features galore, and a whole network of developers have grown up devoted to working with it. In my neck of the woods at least, being a skilled Drupal developer is gold.

CodeIgniter is definitely up my alley. It's light weight, fast, and stays out of your way. There are any number of class modules to choose from, and you can discard what you don't need to lighten the load even more. After seeing a presentation at the DC PHP Developers group a few months back I was intrigued and took a closer look at the package. The presentation, from two developers at Forum One, showcased the work they did on the CARMA Web site, and in particular the database backend that drives the mapping of global power plant emissions. PPT slides are available if you're interested. Plus, if Rasmus endorses CodeIgniter, I'm all ears.

CakePHP is another popular MVC application framework. Conceptually, it's similar to Ruby on Rails.

Other PHP frameworks include:

And there are more. I'm not writing a book here folks!

Python

If PHP is more specific to Web development (some people consider it little more than a templating language), then Python, like Perl, is more general purpose. In terms of Web frameworks, there is one standout, with a loyal—some might say rabid—following.

Django, first developed at Lawrence Journal-World (I lived in Lawrence, Kansas for many years!), and released to the public under a BSD license in 2005, has since become the Web application framework of choice in the Python community. Django, like everything Python, is based on the DRY principle, and everything is an object. You begin your project by defining a set of data models (which are Python classes of course), and build from there. The number of features are only limited by everything Python has to offer, which is a lot: an embedded HTTP server, friendly URLs based on regular expressions, an ORM connection to your database, page caching, input validation and sanitizing, tools to prevent XSS and CSRF attacks, authentication and sessions, RSS feeds, and much more.

CherryPy is another option for the Python developer. Like Django, it has a built-in HTTP server, or you can connect it to any WSGI compliant server (such as Apache 2). It has tools for caching, encoding, sessions, authorization, and lots more. Once again, anything Python can do...

Perl

The Swiss Army knife of scripting languages. Perl has a long history and a large user base. Where PHP tends to be monolithic, Perl, like Python, is built from a core language with a countless number of callable modules (aka CPAN). Like many other programmers, this is the language I started out with developing dynamic Web pages back in the days of CGI. Then mod_perl came along, and we have Mason and many other templating solutions. Whatever happened to eperl I wonder?

If Perl rules your world and you're shopping for a Web application framework, then look no further that Catalyst. Like Django, the feature-set is only limited by what's available in the form of CPAN modules. In other words, go nuts. Given the opportunity to work with this framework, I would jump right in.

There are no other viable Perl frameworks for developing Web applications. At least that I'm aware of. Drop me a note if you disagree.

Ruby

The Ruby language itself I am not that familiar with, many people like to compare it to Python. You be the judge. But when it comes to Web application frameworks, if you haven't heard of Rails then you've had your head in a bucket of sand.

The hype surrounding the release of this framework, which continues to this day, is astonishing. RoR began life as the backbone of the popular Basecamp Web-based project management tool from 37signals. The author released the framework to the development community in 2005. Like many modern frameworks, it is centered around the DRY principle and a MVC architecture. It also supports JavaScript/Ajax libraries which users of all 37signals products rave about. Simple, easy to use, rapid development and simple, easy to use results are the hallmarks of this system. Many of these same philosophies have been the basis of frameworks that followed.

Client-Server JavaScript Hosted Web Application Platforms

dwclifton@gmail.com (Douglas Clifton) — 2008-11-10T01:57:22Z

A few years back I mentioned being surprised that more developers weren't jumping on the Mozilla framework RIA bandwagon. The same technologies (HTML, JavaScript, Ajax, DOM, XBL, XPCOM, XUL, RDF, RSS, Chrome...) have been a boon when it comes to the plethora of Firefox extensions, but very few full-blown applications ever surfaced. MAB was one I always pointed out as a good example. I felt there was huge potential there, but for whatever reason it never took off (MAB has been discontinued due to changes in the Amazon Web Services backend).

Hosted Applications

In the past year, it seems the latest rage in JavaScript development are so-called hosted JavaScript application frameworks. The general idea being you use the same language both in the client and on the server-side. On the server-side you have access to SQLite, MySQL and other data sources such as XML stored on disk (or generated), and other resources—just like you're used to with languages like PHP, Python, Perl, or Ruby—and on the client-side you have access to the browser DOM, CSS, and so on, then glue it all together with XHR/JSON. Most of the offerings in this genre include browser-based IDEs for rapid application development, and you can fork off someone else's code to quickly generate a morphed version using your own concept. Though the technologies are open-source, most of these companies monetize their investment by hosting (and charging consumers for) the application, much like the cloud computing models (e.g. EC2, S3) that are becoming increasingly popular.

Although there are many similar RIA frameworks, some of them open-source and some of them not (see below), I'm going to concentrate on the two that I found most interesting—both of which are open-source.

Jaxer

Jaxer is an open-source, client-server Ajax framework built from Mozilla's SpiderMonkey JavaScript engine. With it you can access data using built-in SQLite, or externally through a DB connection to MySQL. I'm not sure whether they have or are planning on supporting other RDBMSs such as PostgreSQL. I would think a database abstraction layer would be handy. Naturally you also have file I/O and access to everything on the server end. On the client-side you have everything the browser has to offer: markup, DOM, CSS, and finally asynchronous XHR using JSON, or whatever you prefer, for sending data back in your response to the client.

A really slick feature of Jaxer is the ability to code JavaScript that runs on both sides of the equation. In other words, things like form input validation in the same language so you don't have to repeat the same functionality. Also of interest is their choice of going with SpiderMonkey, which supports JavaScript through version 1.8. Think you'll miss your favorite JavaScript library? Think again, you can easily access jQuery, prototype, and the many effects libraries. Does the SOP restriction on Ajax between client and server frustrate you? Not any more, since the server-side code can access data from anywhere before transporting it back to the client. Only you can trust it. Because you know what you're doing, right?

I have not seen any benchmarking done on the system, but when TraceMonkey rolls out performance should go way up. In case you can't tell, I'm pretty excited about this framework and the technology behind it.

Acre

Acre is a similar offering from the folks at Freebase. Just out of developer preview status is this new integrated Web application and hosting environment. Using a simple JavaScript templating language and their IDE (the app editor) you can create applications using templates, scripts, queries and static (e.g. CSS) files.

Unlike Jaxer, I was not able to find much in the way of details on how they implemented the system. However, to see what's possible I recommend taking a look at FMDB. My impression thus far is it has potential, but they need to beef up the documentation and offer more examples and tutorials.

Similar RIA Frameworks

If these guys are the new kids on the block, they certainly aren't alone. Offerings in the RIA arena have been around for a while. However, most of those listed below do not fit into the hosted application model.

OpenLaszlo

Adobe Flex

Silverlight

AppJet

Other Interesting Links

As I find them, I will add more.

Back to the Server: Server-Side JavaScript on the Rise

GUIMark

Cachegrind your Web apps

dwclifton@gmail.com (Douglas Clifton) — 2008-11-09T08:00:00Z

Valgrind is a entire suite of open-source tools, including basic debugging, profiling, and more advanced techniques such as threading, memory management, and leak detection. For the purposes of this article, I will focus on Cachegrind, and in particular within the domain of Web applications. Although there are a number of developers contributing to Valgrind, Julian Seward is the original designer and author.

Out of the three server-side languages I am most familiar with, PHP seems to be the one that is best represented, with some Python—but I found very little if any information on Perl.

What is Cachegrind?

Cachegrind is an Intel CPU emulator and cache profiler that performs detailed simulations of the onboard I1, D1 and L2 caches and can accurately pinpoint the sources of cache misses in your code. It identifies the number of cache misses, memory references, and instructions executed for each line of source code. (paraphrased)

Xdebug

Xdebug is the tool of choice for PHP developers when it comes to standard debugging, and the built-in profiler with Cachegrind output is also maturing. Typically the output is in a file named cachegrind.out.pid, which is plain text, but be careful with large, complex applications as it can grow to on the order of 500MB. The raw data is almost useless, to really analyze and visualize the results you need a parsing/graphing tool. There are several available depending on your platform and needs.

Viewers

Once you have your output you need an application to make sense of it. Listed below are solutions for Linux (or any Unix-like OS running KDE), Mac OS X, Windows, and even a browser-based solution from Google Code.

KCachegrind

MacCallGrind

WinCacheGrind

Webgrind

Related Reading

Debugging Questions and Xdebug Answers

Cachegrind-less profiling with Xdebug 2.0

Understanding PHP code better with Xdebug

How to cachegrind a tested Drupal

CherryPy: Cachegrind

Debugging PHP

Spectator

Useful in-browser development tools for PHP

FirePHP

gist.github.git

dwclifton@gmail.com (Douglas Clifton) — 2008-11-08T02:30:00Z

After being introduced to Git at a BarCampDC2 presentation I found the system intriguing and worthy of a closer look—and in particular as an alternative to SVN.

Git

Git is a distributed open-source version control system designed to handle large to small projects with speed and efficiency. It is especially popular within the open-source community, serving as a development platform for projects such as the Linux kernel, RoR and X.org.

GitHub

GitHub provides pre-rolled, post-commit hooks with Lighthouse and Campfire integration, as well as an innovative Web hook system for writing your own. Every repository comes with SSH support for pushing and pulling. Private repositories enjoy full SSL support.

Gist

Gist is a GitHub hosted pastebin service with the usual features, including source code syntax highlighting, shared URLs, plus all the goodies you'd expect from a version control system. Pastes can be set to public or private, you can edit them both online and off, and you can fork them—in essence treating each snippet as its own versioned project.

The downside of allowing anyone to post to Gist is the usual assortment of spamming, robots, and phishing scams. One look at the recent gist list is all you need to find "really cheap drugs." Sigh.

Since Git uses SHA1 as a checksum on files, one of the first things I did was write a simple PHP command-line script which either generates the hash for a file, or compares the file to an existing hash. So I thought, what better snippet of code (even though it is a complete program) to use as my first Gist? Update: now in Perl and Python too!

Resources

Forked Git

Git CheatSheet

GitHub Blog

GitHub Public Code Search

GitHub Google Group

Google Code Git Development Community

GitHub Company Profile

Gist Product Profile

Related Reading

Here's the Gist of it

Fork you very much: Gist brings revision tracking to pastes

GitHub unites Version Control with the Pastie

GitHub Gist is Pastie on Steroids

GitHub Swag

Oh, I almost forgot:—

Python 2.6

dwclifton@gmail.com (Douglas Clifton) — 2008-11-07T01:43:00Z

For someone with many moons of writing code in C and C-like languages, making the transition to Python was indeed a paradigm shift. But we're only human and as humans it's natural to be resistant to change. For instance, when I first started to study Python in earnest I found the notion of indentation as syntax rather odd. And where oh where are my parenthesis? What's this, no line termination semicolons? No curly braces around blocks of code? This is insanity!

A Bit of History

Of the five programming languages I refer to most often, Python stands out as being unique in many regards. It's interesting to compare and contrast the why and the how they were developed—and by whom.

C (and its descendants) ca. 1970 — the oldest of the four, developed by computer scientists at Bell Labs during the early stages of the evolution of Unix

Perl ca. 1986 — developed by a lingust turned system administrator (now a researcher and developer at O'Reilly).

Python ca. 1990 — developed by a mathematician turned programmer (now working at Google).

PHP ca. 1995 — developed by a systems design engineer turned programmer (now an infrastructure architecture engineer at Yahoo!).

JavaScript ca. 1995 — developed by a programmer turned CTO at Mozilla.

Sitting on the Fence

Last month brought Python developers a step closer to the up-and-coming version 3.0, with the final production-ready release of Python 2.6. It adds plenty of new features, modules, improvements and bug fixes. For the Python 2.6 and 3.0 release schedule, visit PEP 361.

So what's the big deal? Developers are both excited and concerned—3.0 promises to bring great things—but Guido has made it clear that the new version will likely break some older scripts. It reminds me of PHP 4.x to 5, although, at least for me, the impact was minimal. And version 5, once it stabilized, was a big improvement in terms of OOP.

By adding compatibility functions in the future_builtins module, and a -3 switch which warns about usages that will become obsolete, Python 2.6 should mitigate the migration to version 3.0.

Related Reading

Why Python 2.6 and 3.0 compatibility would be a Very Good Thing (Lennart Regebro)

Python 2.6 to Smooth the Way for 3.0, Coming Next Month (Slashdot)

Python language slithers into the future with 2.6 release (Ars Technica)

Python 3.0 makes a big break (Linux.com)