In the process of developing and refining our CMS, the question occasionally arises whether or not we should convert text inputs from format X to format Y. These questions range from the innocuous and straightforward (should we convert curly quotes to straight quotes? or vice versa?) to the more insidious (should we correct a misspelling? should we move close quotes to outside a period?).
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?
Read more »
Tags: code, development, livewhale, lwblog, php, Title Case, whitewhale
Comments: One comment »
Optimization is one of the most enjoyable parts of software design, but unfortunately it does not claim a high percentage of development time. Generally speaking, it is not a task to consider until the time spent is justified, which is often toward the end of the development cycle (but not always!) Still, it is an important step, especially with products like LiveWhale, which has to perform well under high traffic spikes. I’ve already talked about general page caching before, but fine-tuning a PHP application for speed when something is not cached is also important. Here are some thoughts on how to do just that.
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. Read more »
Tags: application, cms, development, livewhale, optimization, performance, php, speed, whitewhale
Comments: None »
It’s hard to imagine how this industry would operate without open source software. The PHP language that I use to write software for the web is itself free software. Unfortunately, the quality of open source code written with PHP is relatively poor and inflexible compared to the quality of open source libraries that can be compiled into PHP as extensions. Consequentially my personal relationship to open source software is a hybrid scenario of, on the one hand, being deeply invested in open source tools that expand the language I program in, as well as having a commitment to turning out open source projects of my own to the community, and on the other hand, a healthy skepticism toward the bulk of open source software written in PHP. Part of this is due to the fact that, being the chief server side programming language of the web, freely available PHP code could well have been written by your grandmother (apologies to my GM, who happens to be a very savvy user). Read more »
Tags: development, open source, php
Comments: None »
After four years of using XPHP successfully in a wide variety of applications for White Whale, we have released it to the public!
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.
Tags: development, framework, php, xml
Comments: None »
At White Whale I maintain several libraries of code which involve performing tasks over FTP. PHP has an FTP extension that works pretty well for FTP-related code. The major flaw with it is that it only supports FTP and FTP+SSL. As we start working more and more with SFTP servers, many of these libraries needed to add SFTP support.
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. Read more »
Tags: code, development, ftp, php, sftp, ssh
Comments: One comment »