Since that time the site has evolved into a comprehensive resource for people to find true meaning and happiness in their lives, and Caxiam Group’s relationship with Paul has evolved into that of a true friend to the team. We are grateful for the opportunity to work with Paul, and are proud to present some of the results of our relationship.

Custom Design

It was important for us to create a design that matched Paul’s message. We shot for a look that was calm, light and uplifting, while at the same time remaining clean and easy to navigate. Here are a few screenshots of some key areas:

Paul’s Home Page acts as a portal directing new and existing visitors
to the areas they are looking for.

The “What Is It?” page sums up the purpose of the site to new visitors.

We created a custom Flash assessment to help new visitors determine
where they are in the Sacred Path, Joyful Journey process.

WordPress Integration

Working on Dr. Paul Dyer’s site has presented some unique challenges that motivated us to learn the inner workings of WordPress’s API. Much of the site is driven on custom programming elements that we feel really stretch the capabilities of WordPress as a CMS platform. Here are a couple examples:

In addition to a custom, tabloid-style layout, custom queries were relied up heavily
to pull supporting content in from other areas of the site.

Paul offers tools to help users along with their Sacred Path, Joyful Journey process. These tools are categorized under one of the three stages of the process, then further categorized by type of tool. Each type is marked by an icon, offering users a clear visual indicator.

Admin Interface

As the project evolved, it was clear that in order for WordPress to continue to be an effective solution, we needed to expand the capabilities of the platform – content no longer fell into the simple post vs. page model. In this regard, the More Fields plugin has been vital. Here’s how we were able to leverage it:

Custom Post Types

More Fields allowed us to create additional categories to organize content. No need to wade through hundreds of posts – Paul’s content is neatly separated into a set a several categories:

Custom Content Boxes and Fields

WordPress’s support for custom fields is a nice addition, but it’s out-of-the-box interface tends to be unwieldy and unintuitive for client use. More Fields allowed us to present custom fields in a clean interface with professional-looking fields that could be logically grouped into collapsible boxes. Additionally, it allowed us to hide WordPress elements Paul didn’t need to use, keeping things uncluttered and relevant:

To top things of, we also made use of the Admin Menu Editor plugin to more logically rearrange and organize the WordPress admin links.

It has been announced that WordPress 3.0 will offer support for custom post types out of the box, so we look forward to trying it out and seeing how the two solutions compare.

Wireframing is a big part of our documentation process, but finding the right tool to create wireframes with has been a long and ongoing process.

Visio

Microsoft Visio was one of the first tools that I put into my wireframing belt.  I started out here because I was already familiar with Visio for documenting process flows and I liked the simplicity that it had for quickly mocking up basic page layouts and step-throughs of process flows.  I still think Visio is a great tool for quick mockups, but it has limitations that prevent it from being a tool we can all use.  For one, licensing would get expensive quickly for more than a handful of users.  Any wireframes that I created in Visio I could only share with clients or other team members by exporting an image format, or somehow convincing them to install the Visio reader plugin on their workstations.  Visio also did not support any interactive features and although I could save a grouping of shapes, say for a “header”, if I needed to make updates to the grouping the changes where not communicated out to the other pages of the wireframe without me manually copying/pasting.  Not incredibly efficient.

Axure

We purhased an Axure license to try and circumvent the problem of non-interactivity with our wireframes, which somewhat crosses the line into Simulation.  Axure was (and still is) a great product for creating interactive wireframe simulations of web pages/applications and allowing client review by providing the wireframe as a click-thru experience.   One of the best redeeming qualities of Axure was the ability to create re-usable “includes” for common page elements (like headers and footers) that would automatically propogate updates to the master includes out to the wireframes that referenced them.   The frustrating thing with Axure was that one of its greatest assets; the ability to export an HTML simulation, made it frustrating to use for pure wireframing and offline reference.  The wireframe/simulations that Axure creates have to zipped into a multi-file folder for distribution, and the end user must unzip them and know to click the index.html file to bring up the simluation.  It is not the most intuitive experience for the non-technically savvy.

And so, the journey continued…

iRise

I will be honest and say that I didn’t spend a lot of time with iRise beyond a few hours of evalution.  The software is vast and seemingly without end!  My one impression from the time I spent with it was that it was not the right tool for the job. Where I needed a simple phillips screwdriver, iRise was an entire store full of tools.  Perhaps I will revisit iRise in the future as needs dictate.

Balsamiq

Balsamiq has been an outstanding wireframing tool.  The interface is simple, the shapes available are logical and appropriate to web application development.  One of the great advantages of Balsamiq is that it is so easy to build wireframes with I can use it in real-time during a client meeting and still participate.  For this same reason, the entire team can use the same tool and the licensing is very reasonable.

Pencil and Paper

The old standbys are what I started with are still some of the best go-to tools in the belt.  Pencil and paper tend to be less obtrustive in a meeting that sitting and tapping away at a laptop, with the added benefit of being able to scribble random addenda in the margins as the flow of the meeting dictates.  Most of my pencil and paper wireframes end up being rendered out in Balsamiq for final presentation.

Launching installer...

./ColdFusion_9_WWE_linux64.bin: line 2468: /tmp/install.dir.8076/Linux/resource/jre/bin/java: Permission denied
./ColdFusion_9_WWE_linux64.bin: line 2468: /tmp/install.dir.8076/Linux/resource/jre/bin/java: Success

Turns out that the hosting provider set up the /tmp directory to mount “noexec” as a security precaution.

To get around this I could remount the /tmp dir with exec turned on, or I could change the temp directory that the installer uses. That second option seemed like the better solution, but it took a bit of research to figure out how to do it.

Since the ColdFusion installer uses InstallAnywhere, we can set the IATEMPDIR environment variable:

mkdir /root/cf9_install
export IATEMPDIR=/root/cf9_install


You’ll need to do the same thing to run the uninstaller.

Let me explain.

Assume we keep a quick lookup table of product categories sorted by popularity, using an adjacency list model to store the hierarchical relationships. A periodic process reorders the categories based on recent product views or sales. And because the call to determine product popularity has to call out to a legacy ERP system, it could take several seconds for the reorder process to complete.

Before the reorder process runs, the data looks like this:

- Kitchen Appliances
– Ovens
– Refrigerators
– Dishwashers

A recent sale on refrigerators has moved them to the top of the list, so after the reorder process, the data would look like this:

- Kitchen Appliances
– Refrigerators
– Ovens
– Dishwashers

If the periodic process were wrapped in a <cftransaction> tag, any read queries against the quick lookup table while the reorder was in progress would return the following data:

- Kitchen Appliances
– Ovens
– Refrigierators
– Dishwashers

The default isolation mode of most common databases prevents reads of uncommitted data, which means a cflock is usually not necessary for simple operations such as this example. If other processes might attempt to update the lookup table at the same time, a higher isolation level might be necessary for the second process, but a cflock should still not be required, unless you also need to control access to the CFML code.

Something to keep in mind, though, is that a TRUNCATE TABLE call inside of the transaction will skew the results, causing external queries to return an empty recordset, instead of the normal pre-transaction snapshot. However, using a DELETE statement with no WHERE clause has the same effect of removing all rows from the table, but it does not interfere with the transaction, allowing external queries to retrieve the pre-transaction data.

The TRUNCATE TABLE behavior described above was seen with MySQL 5.1.42. Other database servers, or versions of MySQL, may behave differently.

We’re no strangers to frameworks. We were using a front controller driven framework back in 2000, complete with database mappings to tie pages to their drivers and layouts. Of course the mappings were stored in the application scope for quick retrieval. This framework served us well for many years.

Eventually our business needs changed and we created what we felt was an even better framework, similar to our old one, but without all of the hard wiring. That, too, worked great for a while. We still use it today for most of our projects.

As public frameworks become more popular, or at least, more common, we eventually asked the question “should we switch to a community supported framework?”. The most compelling reasons to switch would be:

1. Offload development, support, and testing resources. Someone else is doing the work of fixing issues and developing new features.
2. Easier to find developers who were already familiar with the framework when hiring new employees.
3. Marquee value.

But do these reasons fit our business requirements?

Offload Development Resources

It sounds great to be able to get back some of that time spent on maintaining the framework. But how much time do we really spend on maintaining it? We never actually quantified that before. Looking back, it’s easy to say “not that much”. Our framework was targeted to our business. It was lean. We had added new features to it gradually over time, but these were usually features we needed for the project at hand. Moving to a new framework means that we would probably spend more time than we did before with evaluating and integrating new releases. Sure, you don’t need to take every new release, but the farther behind you fall, the harder it is to update when you finally do need to. It also meant that we would either have to wait for new features, or find some way to integrate them ourselves, hopefully by extending the community framework and not actually having to modify it. Finding ways to incorporate changes via extension often takes longer than if you can just make them natively. And then there is the risk that the framework implements a similar feature, but in a totally different way.

Ready Trained Developers

The idea of hiring employees that are already trained sounds great, if you find yourself constantly turning over employees, or if you need to staff up quickly for a bunch of “churn and burn” projects that you really expect no longevity out of. We do neither. Our attrition rate is basically zero, and on the rare occasion where we do decide to expand our team, it’s for the long haul. Community frameworks may come with lots of fancy documentation, but they usually come with additional features that we don’t need. As I already mentioned, our framework is lean, and it is targeted to our needs, so the ramp up time needed to learn to use it effectively is very small.

Marquee Value

Marquee value? Seriously? We can just as easily give our framework a name and boast to a potential client that we are using “such and such” framework, and here are the benefits it provides. The important thing is that you *are* using a framework. And to be honest, we did give it a name.

Another consideration is the fact that we primarily develop web applications, not websites. I understand that a framework should be able to serve both, but there is something a little more comforting about having full control over what changes are made to this fundamental layer. Especially when other businesses have put such absolute trust in us to service their needs.

Taking the Plunge

We looked at several of the major frameworks, and analyses that people had performed comparing one to the other. We had already come to the revelation years ago that convention suited our needs better than configuration, which helped narrow the list down to a few key contenders.

After careful consideration, we decided to go with ColdBox. It had all of the features we were looking for, and an impressive amount of documentation. There was also something very appealing about the polish of the website itself. It had a great number of features that we didn’t need, but that didn’t seem to be an issue at the time.

Initial development with ColdBox went well, but we quickly recognized that we were going to need a thin “helper” layer on top of the framework to encapsulate some of the common functionality that we would need with each new application. That was a relatively easy task, and it helped set in motion what seemed to be a new and improved work flow.

Things weren’t perfect, though. An occasional scan of the debugging output kept pointing back to the fact that this framework was doing way more than we needed it to do on each request. The template list showed a total count of 519 calls with an execution time of around 65 ms. A similar page in our custom framework would have produced around 40 calls and been around 20 ms. That’s not really comparing apples to apples, though, as this was a different application.

FW/1 showed up on the radar a few months back, and I really liked what I saw. Here was a lean, mean, conventions based framework that did little more than handle the nitty gritty of processing requests. We were going to have a “helper” layer on top of whatever framework we used, so this seemed like the perfect fit.

In a bit of a skunk works project, I set up a sandbox to see what it would take to convert our ColdBox application over to FW/1. Within about 30 minutes I was able to get the basic application initialization and home page loading, with a little bit of abstraction. The results were even better than I was hoping for. The home page loaded with only 11 template calls, and 3 ms of processing time. Wow. Again, this wasn’t a fair comparison because there were a few features that I had stripped out to get the sandbox app running. But it was enough to convince me that the change would be worthwhile.

I sat down late Friday evening, with a fridge full of caffeine and the mindset that I was going to do the entire conversion in one night, no matter how long it took. And I did.

The entire conversion took about 4 hours. I’m not usually one for cutting corners, and one of the major objectives of this conversion was to improve the efficiency of the system, so I tried to minimize how many abstractions I added to make FW/1 more “ColdBoxy”. I also took the opportunity during this time to clean up a few aspects of the helper layer.

After I started browsing around the newly converted app, I discovered a problem. There is no limit to how deep you can nest controllers and views in ColdBox. In addition to the normal “user.edit” actions, we have a few areas of the app that extended into actions like “admin.user.edit”. Either I wasn’t fully comprehending how FW/1 works, or nesting actions deeper than “section.item” isn’t supported.

This was pretty much a deal breaker. I certainly didn’t want to go back and refactor our application to only have one level of nesting, and I didn’t want that to be a design limit for future applications. I didn’t see any easy way to extend the functionality of FW/1 in this regard, without replacing a couple of the key functions, which would basically defeat the whole purpose of using the framework.

Long story short (too late, I know), the final solution was to take what we had learned from several years of using our own custom framework, along with the new experiences of developing under ColdBox and FW/1, and create our own new custom framework.

Revelations

So was it worth all of this just to save a few milliseconds per page request? Well, if that had been the goal, then I would say “no, not really”. But the goal was much bigger than that. We build web applications. That is what we do. It’s why we come to work in the morning, and it’s why we get paid. The framework that our applications sit on is one of our primary development tools. Your choice of framework is almost as important as your choice of language. The support it provides for your particular business, and the direction it allows you to go with future applications, is critical to your success.

The fact that our new framework loads the same 519 template, 65 ms page with 98 templates and 20 ms isn’t too bad of a side effect either.

After the installation finishes, it will try to reboot, which will fail just like it did in the beginning. No problem. Just restart the VM, and press the “a” key as it starts loading the OS. This should bring up a screen where you can edit the grub params. Add the same “vga=0x32D” to the end of the current params.

You can press “a” repeatedly during the early boot process to make sure it hears you, but you will likely end up with a string of “aaaaaaa” displayed if you do. It’s easy enough to delete them, so pressing “a” a couple times avoids having to time it just right.

After that, your VM should boot normally without having to edit the params.

I chose “0x32D” because it worked well on my system. You can use a different mode if you like, or try setting “vga=ask” to have it prompt you for the setting.

Here is a listing of common settings:

http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#VBE_mode_numbers

Apache JMeter was perfect for what I needed. It takes a little bit of research and time to set up a “Test Plan”, but it was worth it. And it’s free!

You can set it up to run any number of simultaneous users, and you can specify how many times to run the test (in loops), or to run in indefinitely until you stop it.

Pretty slick.