On the one hand, it’s probably best to let users make mistakes, or format as they wish, and depend on human communication to clear things up— instead of trying to build in a bunch of extra structure designed to cover for mistakes.  It’s our view that the latter approach leads to bloated, overbuilt CMS systems that discourage accountability.  But at the same time, consistency and coherence of communication across a Web site is a really, really important thing— it is what distinguishes sites that serve as good vehicles for an institution’s messaging from sites that are just decorated Web pages.

We’re thinking about this right now because we are considering automatically converting the titles of news items in LiveWhale to Title Case.  The following three news headlines, though identical in content, send very different messages:

1.  White Whale Web Services to Release New Content Management System, Revolutionize CMS Industry
 

2.  White Whale Web Services to release new content management system, revolutionize CMS industry
 

3.  WHITE WHALE WEB SERVICES TO RELEASE NEW CONTENT MANAGEMENT SYSTEM, REVOLUTIONIZE CMS INDUSTRY
 

Although there might be a justification for #3 in a particular Web design, it’s clear that you wouldn’t want a user to enter news headlines that way.  For one thing, caps are just hard to read in many contexts; but on top of that, it’s always easy to {text-transform:uppercase} if you need caps.  My general preference as a design snob would be for #2, but that’s clearly not common practice— as much as I enjoy headlines like this (or this), that style is much more common in European news than American.

It’s also the case that styles #1 and #2 look terrible next to each other:

• White Whale Web Services to Release New Content Management System, Revolutionize CMS Industry
• Other CMS providers cower in fear

So.  Should we let users do what they will, and enter headlines according to any system they prefer?  Or should we legislate something?  It seems pretty clear from the above examples that— at least in the particular case of news headlines— legislating is the way to go.  And if you’re going to require a particular format for headlines, it seems pretty clear that Title Case Is Your Only Option.

So what’s the best way to do it?

You could, for example, simply ask the user to format the headline a particular way:

___________________________________________________
Please use Title Case for headlines.

Or, a bit more diplomatically, you could provide an example:

___________________________________________________
Example: Stock Market Soars on Rumors of Bailout

Alternatively, we could let users enter any headlines they want, and control the front end display with CSS’s text-transform property.  But that’s not going to work either, because these are the only options we have:

Title Case Is Great, But Not If You Capitalize Every Word In The Sentence.  Otherwise It Looks Hacky.  The text-transform property doesn’t have the kind of sensitivity you’d want in a good Title Case headline.  I am personally big on punctuation and capitalization styles that reflect spoken rhythms— that’s why, no matter what Douglas says, I always put a space after an em dash— and capitalizing “the,” “and,” etc. ruins the spoken rhythm of a headline.

So the only approach left— assuming you want to engage this issue at all!— is to automatically convert headlines into Title Case on the back end.  And that’s the whole reason I started this post in the first place.

It turns out that converting to Title Case is nowhere near as simple as you’d imagine.  Sure, we know that you don’t capitalize “the” or “a” or prepositions, etc.  But how about sentences like these?

Read markdown_rules.txt to Find Out How _Underscores Around Words_ Will Be Interpreted

Notes and Observations Regarding Apple’s Announcements From ‘The Beat Goes On’ Special Event

These sentences are from a suite of test cases for a Title Case script originally created by John Gruber of Daring Fireball.  We are planning to use the PHP version of the script to convert some of Southwestern’s old news headlines (originally entered with uppercase headlines) to a thoughtful Title Case, and are considering using it when headlines are created in LiveWhale in the first place.  In the process we discovered yet another odd, fascinating corner of the world of CMS development to geek out in.

At the code level, LiveWhale is a framework, which means the same codebase is hit for many different types of requests. The question is then: how to achieve high performance with a codebase that has to perform so many tasks and is therefore code heavy. It makes sense to divide code across a handful of files. The objective here is to only load libraries when you need them. A typical request will only use a tiny percentage of the entire codebase, so there’s no need to read a great deal of code from the filesystem and eat up RAM per PHP request. Also, with a modular system like LiveWhale, it is not explicitly known what modules exist that will need to be loaded. An important optimization is one where only the first request to the server has to perform logic to determine what to load. The results of this expensive operation are cached, and all subsequent LiveWhale requests enjoy dramatic savings in the module loader.

A common problem with application frameworks is that they perform two very expensive tasks with every single page load: 1) initializing a session and 2) connecting to a database. Neither of these two should be assumed. In LiveWhale, a session is started only when a component requires it. A database connection only occurs when/if the first query to it is performed. Making your application sufficiently “smart” about if and when these initializations take place will also lead to dramatic speed improvements.

Less is more. That means you should optimize out any hit to the file system that you can, or remove extraneous database queries. Also, be wary of OO (object oriented) slowdowns. If something doesn’t need to be a class, don’t use one. Remember that calls to an object’s method are more expensive than global function calls. The same holds true for accessing an object’s properties. An obvious optimization is done when dealing with data from a foreign server. Such content should be cached as much as possible, so that rapid hits to your site don’t rely on the performance (or availability) or an external data source. Another tip would be to use error suppression (@) sparingly. This is a known performance hit. There are a number of similar, simple tips available via a quick Google search for “php optimizations”, and there are slideshows available from PHP developers on the subject.

Analyze how your code operates. If you have a function that uses a lot of logic (if/then, switch), make sure you understand what the “common case” is. In other words, what’s the most likely condition that function will come across? Then determine if the function’s logic is conducive to the fastest possible result under the most common case. For example, I had a function that has to intercept a variety of XML structures and handle them in different ways. One particular XML structure (the simplest possible one) was far and away the most common case. Rather than parsing the XML with simplexml_load_string() as I do with all the chunks of XML I receive, I first do a preg_match() to determine if I have the common case. In this situation, I can immediately return a simple result and skip both the parsing of the XML and the lengthy logic that goes with performing operations with it.

Identify “hot” functions. Functions that are called many times, often within a loop, should get the most attention in terms of optimization. First, make sure the function should be called at all, as opposed to using inline code, otherwise you needlessly acquire function overhead. Second, move any redundant logic outside of the hot function. Perhaps the check can be performed just once before the hot code is executed. There are also situations where a function can potentially be called repeatedly and end up with the same result. It might make sense to declare a static variable inside the function, to locally cache content generated by the function. On a subsequent call, it can first check the static array to see if a result already exists, and simply return that if so. This sort of fine-grained optimization will only help when there is a significant bottleneck with a particular function, but it can make a huge difference if done wisely.

Lastly, use XDebug! XDebug is your friend. Among the many things it can do, it will let you profile your PHP code and generate a report about how much time your script is taking overall and within particular functions. Here’s a mockup of the type of information it provides:

In this example, the function LiveWhale->foo() clearly takes the majority of the time for this request. At 38.3% of request time for a single call, it is a good candidate for serious analysis. LiveWhale->bar() is also expensive compared to other operations, and there may be ways to make this function perform better too. The function do_something() takes 6.3% for a single call, on line 41. Another function, do_something_else(), takes nearly the same amount of time but due to the fact that it was called 15 times (at 17 CPU cycles each, so 252 cycles total). Knowing why each function takes the time that it does, and why it might be called so many times, will help you maximize the performance of your application.

Familiarity with what makes PHP code perform well will only lead to the best decisions being made early on, so that XDebug reveals fewer inefficiencies. In the long run, many of these tips become automatic and part of your coding style, but for the best quality, production ready code, a little bit of analysis and thought goes a long way.

I recently looked at five versions of a free class that provided some relatively trivial functionality that I wanted to include in our CMS, but didn’t want to spend too much time with. Some of them felt like they were the size of our entire core CMS library! I found plenty of frills that we don’t need (bloat which arises when a developer wants to pack their project with features to make it more than it needs to be), inefficient repetition of constants, and long procedures meant to do something that can be done in a few lines of smarter code (often meaning the developer missed some of the basics of the language). The fact that there’s a lot of garbage out there doesn’t imply that there’s nothing to gain by sharing open source code. In this case I had to study the scripts that I saw and develop my own (small) derivative, but if you are selective and critical when choosing to go with packaged code, there’s a lot of milage you can get out of other developers’ work. Fortunately, projects like PEAR (http://pear.php.net/) help to screen and collect useful code libraries and facilitate their distribution. Many other code archives just don’t fare so well.

I find that good PHP code is relatively fast and easy to write for any situation, because PHP comes with a wide range of libraries that automate most desired tasks, and the APIs are usually not very verbose. The places where I think open source software really becomes a feather in PHP’s cap are the multitude of extensions developed for the language as distinct open source projects (whether originally created for use within PHP or not). They are endless, and many of them are perfectly critical to writing a good web application. Nevertheless, there are areas where open sourced PHP code is also useful in the industry. I have felt that templating and caching are good examples of this, and created two open source projects for that. I aim to release another one that is designed to produce a powerful XML toolkit by adding a thin API on top of PHP’s XML foundation that vastly reduces the complexity of XML-generating code, making it more accessible to programmers at all goals and skill levels.

Some of the tools we have developed in-house and make freely available to whomever wants to experiment with them are available at http://technologies.whitewhale.net.

What is XPHP?

XPHP is a free class for PHP which allows for the embedding of dynamic content (web application variables, function output, etc.) in a web page, using a pure XML-based syntax. It is designed to quickly bring application functionality to your web pages, while avoiding the complexity and overhead of a full CMS suite or application scripting framework. It has been deployed on many projects from small-scale sites as a basic templating engine, to powering mid-sized e-commerce applications, to running full-fledged intensive data applications on high profile web sites.

Who’s it for?

XPHP is designed for developers who want to improve the efficiency and structure of their applications without committing to a complicated, bulky framework, or involving disorganized, unsafe, and philosophically questionable pseudo-code in the delivery of dynamic content to a web page.

Basic goals of XPHP development:

• Embracing XML as a powerful programming tool and partner in PHP application development.
• The avoidance of dispersing significant application logic, whether as PHP code or otherwise, throughout individual site files which take focus off the central web application itself.
• Adhering to an extremely simple syntax, while allowing for maximum flexibility.
• Ease of development and fast code execution.

Features of XPHP:

• fast, seamless templating functionality
• ability to execute application components with advanced parameter parsing
• support for nesting/recursion, and output evaluation
• advanced output control, including flexible caching support, basic if/else statements, and variable casting
• fully aware of object-oriented programming techniques
• support for PHP extensions such as XSL, and the popular APC opcode cache
• support for pushing content
• built-in routines for performing common actions
• allows for the registration of user-defined tags and tag types
• simple implementation via output buffering, or manual parsing
• 100% pure XML syntax

System requirements:

• PHP 5.0+
• SimpleXML extension for PHP (enabled by default)

A full tutorial and download link are available at: White Whale Technologies: XPHP.

There is an SSH2 module that requires a little more effort to set up on your web server, but enables support for SFTP servers. The question is then, how can I integrate this extension and its features into an existing FTP codebase in an efficient manner? Furthermore, the SSH2 module’s syntax is not as straightforward for basic FTP tasks as the actual FTP extension is.

The answer is really pretty simple. I created an FTP wrapper class which runs in one of three modes: FTP, SSL, or SFTP. Depending on the mode, the wrapper class reroutes its method calls to the appropriate extension. All the methods for this class exactly match the ones for the FTP extension. In the case of FTP and SSL, it is easy to map the methods from one to the other, because they’re exactly the same. In the case of SFTP, there’s a translation layer which converts FTP commands in the FTP extension’s syntax to the SSH2 extension’s equivalents.

The reason this approach is efficient is because all the existing code can be painlessly converted to the wrapper class, such that SFTP is instantly supported. No alternate SFTP code paths, no significant code rewrites, no new syntax to follow. What it boils down to is one extra step to specify the FTP mode, and then just prefixing each FTP function call with the wrapper object (i.e. ftp_put to $ftp->ftp_put). Done!