White Whale Web Services: Programming practices

Alex

Alex Romanovich
alex@whitewhale.net

Typically White Whale works with LAMP (Linux, Apache, MySQL, PHP) environments. We make regular use of object-oriented programming (PHP 5 is highly preferred on all projects) on a regular basis, and increasingly involve XML in the deployment of our projects.

Every client brings with it a different set of circumstances in terms of server requirements and philosophies. White Whale has had the opportunity to work with a range of scenarios through the years, affected by the unique scale and desired functionality that each project dictates. While we understand the specific political and philosophical criteria that any IT department has to negotiate in regards to the challenges posed by each project they undertake, White Whale is always ready to lend our ideas and experience to server and software configuration.

No software architect worth his or her salt does not refine their programming approaches throughout the lifetime of their career, always looking for improvements, optimizations, and opportunities for innovation. White Whale is no exception. We bring programming approaches and tried-and-true code to every one of our jobs. That means addressing the latest security exploit, as well as securing the well-established issues ranging from session hijacking/fixation, to SQL injection, to form spoofing and input filtering. Sensitive data is stored in its proper place, and access to it is appropriately restricted. Security features are firmly established on a careful opt-out basis only.

We routinely think about how our code performs, considering caching techniques, stress testing/benchmarking, including Apache benchmark and XDebug profiling, minimizing database connections and queries, as well as the usual debugging and testing requirements. We always consider the clients' expected bottlenecks and general concerns given the environment we have to work with, so that we can ensure that we have examined every possible issue before launch.

All code in its final form is fully documented and, wherever necessary, will come with buildout guides so that continued content management maintains the cohesiveness and integrity of the site we delivered. We are happy to work with our clients to establish appropriate backup mechanisms, and are also friendly toward sensible approval processes in regards to continued development on code post-launch.

White Whale is strongly in support of popular programming policies which keep backend PHP code distinctly separate from (X)HTML/JS/CSS as much as possible. This means that we prefer to keep all application logic strictly within the bounds of the web application, and not dispersed throughout site files which are continually being revised by the design team.

In general, we approach dynamic web sites as unified web applications wherever possible. A web app consists of a PHP class (or classes) which, when instantiated, represents a complete and logically organized server-side application. The benefits of this approach include having a simple, streamlined location for all backend development to take place, easy staging of alternate versions, the design team can feel free to manipulate site files without overwriting or damaging server-side code, and archival revisions of the web app itself do not require copying many site files.

Our applications generally use the MVC (model-view-controller) approach to design. Each application defines a variety of constants (magic numbers) used throughout the code for easy site-wide adjustments. The main application controller is generally responsible for performing all functions of the web app, whether that be processing an input request, generating dynamic page content, providing a centralized approach to form processing, intercepting AJAX requests, and the like. This is done in an organized manner, such that one can always see a clear overview of the application structure and logic without delving into the nitty-gritty of each individual class method. Class methods are organized and abstracted into layers, such as database routines or display functions.

In keeping with the desire to maintain software abstraction and a unified place for application code, we generally prefer to use a simple tag-replacing routine to insert fully-formatted dynamic (X)HTML content into the styled template files. While our approaches do allow for some important flexibility and conditional templating, we do not admire unintelligent and messy CMS systems or templating engines that distribute application-specific logic throughout the site. With our methods, a designer can easily deploy a single piece of dynamic content (such as a list of news headlines) on any given template page and have it appear and operate as expected, without any risk of altering sensitive PHP code.

Our applications often make use of XML-based coding procedures to programmatically construct dynamic content to ensure validity and proper formatting of XHTML code for presentation on the front end. In terms of database development, we make regular use of phpMyAdmin (www.phpmyadmin.net), a standard in addressing database architecture. We have plenty of experience with a range of modules that can greatly enhance the work that we produce, from GD, to DOM, to APC, LDAP, mod_rewrite, and so forth. We routinely have to integrate smoothly with authentication schemes such as WebAuth and are more than ready for the task.

We're also geeks, let's face it. We read the forums, we talk to the developers of the software we use, examine their presentations, we monitor PHP, MySQL, and browser bugs and submit them ourselves on occasion. For this reason we have extensive knowledge when it comes to backwards and cross-browser compatibility but also forward compatibility as well. Our past projects have been subjected to major software upgrades on their servers without a single issue cropping up given the new environment. We also possess a great deal of familiarity with software configuration options (such as PHP ini options) which always make critical differences in the speed, security, and optimal functionality of our clients' web sites.

We are more than happy to engage in a dialogue about all these concerns, so... questions? E-mail me.

Alex Romanovich
alex@whitewhale.net

White Whale Web Services

White Whale Web Services, Inc.   •   1904 Franklin Street, Suite 500  •  Oakland, CA 94612  •  510-808-4028  •  web@whitewhale.net