CFBlog Administrator Blog

Well that's certainly one way to look at the subject of building an app for scalability. And probably very true to a certain degree as well...

The truth is that almost all web ventures never become big enough to even need a separate database server, let alone a farm of memcached servers, file servers, and enough computing power to plan a trip to Orion. That doesn?t mean they won?t become profitable. You can be extremely profitable with relatively low traffic. So don?t worry about scaling ? scaling is for nerds. By the time you hit pain points, you can bring in someone who really knows what they?re doing. Most importantly, by the time you hit pain points, you should be profitable enough to not worry about bringing in someone who knows what they?re doing. And no, just because your site goes down for an hour while on the home page of digg.com doesn?t mean that you need to worry about scaling.

I'm still going to take a bit of a contrarian approach in that building any system with an eye towards scalability never hurts and nearly always helps. An eye toward scalability, IMHO, forces a developer to pay attention to some of the small details in the code and architecture that might otherwise be allowed to slide.

One of the big advantages that we have as Coldfusion developers is that we program in a language that scales well and in which the server technology is designed to do the same. While it's true that none of us may ever build an app big enough to inhabit it's own server farm, it doesn't hurt to think big.

Since I switched to a Mac a couple of years ago, I've found that, for most of my development work, my productivity has increased or remained the same between the applications I was familiar with on Windows and those available for the Mac.

One exception to this, however, has been the lack of a solid file/folder comparison utility. Beyond Compare for Windows, is IMHO the best file and folder comparison utility bar none and it's been sorely missed as a Mac convert. When I've got a particularly complex series of files which need to be merged, I'll often open up a Parallels virtual machine just to use BC.

I've tried several decent utilities on the Mac, including Guiffy and ZSCompare. Both are very adequate for basic, single file, comparisons but fall short when dealing with complex directory structures and significant differences in whitespace between files.

Today I stumbled on a post over at Ranchero today cross-linking to a new Leopard-native file comparison utility for the Mac, just released, called Changes.

After downloading and running some test comparisons, I'm mightily impressed. It may not be Beyond Compare just yet, but it has some very, very nice features - including a very robust exclusion filter which excludes .svn,.cvs, and .DS_Store files from the directory merging process - and a great deal of potential. It also has adjustable code coloring and a customizable interface.

The price is also right - free to download and try and $35 for a license. It's also lightning fast compared to the Java-based diff utilities.

I've been working on an update for a client site which involves the cleanup of a bunch of unnecessary files in scores of directories under subversion control. In order to ensure the files were deleted properly, I used CFDIRECTORY, along with CFEXECUTE, to safely remove those files from both my development machine and from the SVN repository like this:

<cfloop list="#uselessFiles#" index="i">
<cfif fileExists(directoryPath & "/" & i)>
<cfexecute name="svn" arguments="delete --force #directoryPath#/#i#"></cfexecute>
</cfif>
</cfloop>

My machine was running on SVN version 1.4.1, however the JavaHL bindings (which are used by Subeclipse) which were distributed for that version were only compatible up to Subversion 1.2. This meant that when I used the terminal or CFEXECUTE to manipulate files under SVN control, Subeclipse compatibility on the directories with affected files was lost.

One potential solution for this problem was modifying the Workspace Preferences > Team > SVN preferences to select SVNKit as it's interface rather than the JavaHL bindings. On Leopard, however the SVNKit uses the Keychain for SVN authentication. This would be fine for most, however I use password protection on my OS X Keychain, however, which meant that SVNKit required me to enter my keychain password whenever a connection to the SVN server was made. While not critical, this solution made working with Subeclipse cumbersome - unless I chose to remove the keychain password.

It turns out, however, that the most recent Subversion binary for OSX, 1.4.4 (full list of binaries for Win/Linux), includes an updated version of the JavaHL bindings.

After downloading and installing the 1.4.4 update Subeclipse, using JavaHL as it's SVN interface, now has full compatibility with Subversion 1.4. This means I can use the command line again, and in this particular case CFEXECUTE, without fear of breaking compatibility with Subeclipse, which is definintely worth the upgrade!

The web design and development communities at large have an ongoing debate regarding the benefits and drawbacks of the long form. If completion and participation percentages are the "end in mind" of the interface you are designing, an overly long or complex form served to the user can be it's kiss of death.

The good folks over at Yahoo have spent quite a bit of time on the subject and in addition to their excellent User Interface Library one of their Senior Principals, Luke Wroblewski, is quite possibly the definitive expert on Web Application Form Design - he even has a book on the subject.

In short, the way in which developers and designers approach elements of a form has a direct impact on both it's usability and the percentage of completion. Label placement is a critical factor in quick scanning and completion of forms. It can also be used to slow down the user to ensure higher levels of accuracy. Items like font-size, length of labels, and the clarity of what actions the buttons on the page perform are all critical elements which can make huge differences in the success of your forms and the quality of their submitted content.

Theory and practice go head to head, however when the goal is to capture a large amount of information, while providing the impression for the user that their own investment is minimal. A common solution is to break the information up into a series of steps, which combine the data across requests for final submission. In the case of a blog or a CMS such as FarCry, which I also have built sites on previously, this limits the simplicity of the user interface. In addition, as features are continually added through subsequent release cycles of the application, it is the user who suffers.

It was with this in mind that, as we re-designed the admin interface for Version 6 of Blogfusion, we elected to throw out the existing, overly complex, administrative interface and start from scratch. The previous design featured a two column layout which placed more items "above the fold" but also added to the users impression that writing an entry is a complex process, suited only to those who are technically inclined. Here's an example of the interface from an existing Blogfusion 5 site (CFBlog.com):

A two-column interface is a very popular design when click-through and length of visit are the primary concern (i.e. blogs and commercial sites). The problem is, however, they tend to increase - rather than decrease - the complexity of the page. In addition, while most readers of this blog can parse and complete this form without any questions, for the non-technical user, the labels and form elements of this design pose far more questions than they solve.

What we elected instead was bring the entire admin interface into a single-column layout and then, in the case of the entry form use javascript to manipulate the non-essential elements. A user with javascript disabled gets the full meal deal in a structured and semantic order. The javascript-enabled browser sees this (we still have some touchup of the CSS and an inline preview function to add - using the users own CSS - but you get the general idea):

The fieldsets containing advanced entry options such as trackbacks ("Make Your Entry Public"), delayed publishing ("Advanced Publishing Options") and podcast files ("Media/Podcast Options") are contained in an accordian interface which is created and hidden during the "onload" event of the document with javascript. Other key elements are:

1. A large, graphical menu across the top which leads to task-specific templates for common entry actions. Most of these forms post data into the same table, but are formatted differently with data combined/manipulated on post to produce the HTML submitted. CSS selectors are also added at this time to allow for different formating for different types of content (e.g. class="photo-entry")
2. A single horizontal bar across the top which opens an accordian menu with descriptive links to other areas of the admin interface (i.e. - settings, design, plugins, etc.)

We left tagging and category selection out in the open, though it's always debatable whether these elements could be deemed "essential" (categories are hidden on edit - visibile on add). Since this version of Blogfusion converts all of the existing, and in so many cases incompatible, javascript libraries accumulated in previous version to use the JQuery javascript framework, it is now possible to perform advanced and sequential manipulations of the DOM with very few lines of code and much less debugging time - in this case the manipulation of the non-essential <fieldset> and <legend> elements to create an accordian interface.

While none of these design modifications are particularly groundbreaking or even new in practice, it's provided me with an opportunity to reconsider my own ideas of interface and long form layout and is already reaping benefits for other client projects on which I work.

As developers, we spend more than our fair share of time dealing with forms and post processing of the data. We owe it to our selves, from time to time, to explore new and better ways to build that same old mousetrap.

The in-laws arrived last night for a Thanksgiving visit and this morning the house smells wonderful as my wife is in the kitchen. It's been a good year and there are so many things I have to be thankful for. In no particular order, here's a few big ones that come to mind:

• My beautiful daughter
• My beautiful, smart, and funny wife who never lets me take myself too seriously (a good thing in my case)
• The physical, mental, and financial resources to pursue my interests, passions, and hobbies for another fantastic year in the outdoors.
• A nice, comfortable home in a great town, which just happens to be within an easy drive of much of the finest smallmouth bass fishing in the U.S.
• My mother, a cancer survivor and not a cancer patient for another year.
• My father, still one of my best friends, a wonderful dad and (unsurprisingly) an excellent grandpa to my daughter.
• A job that provides me with both the flexibility to pursue my numerous interests and yet continually challenges me and

There is one thing I'm especially thankful for that is beyond my scope of influence and experience, but which I humbly give thanks to and for:

The men and women of our armed forces who have made the commitment to serve this great country, even when those things which they are asked to do may be fraught with controversy or unpopular. They are my heroes, and I am eternally grateful for their sacrifice. On that note, AmericaSupportsYou.mil has a text messaging (and email campaign) to help let our troops know how much we appreciate them this holiday season. Take a moment to send a text message to 89279 or head over to their site to send an email of thanks to the troops.

My warmest wishes for a happy Thanksgiving to you and your loved ones.