E-business Coach Commerce

Agility in software development improves decision making

In the course of delivering a hosted e-commerce software package, we have more development ideas than we have the time or programmers to act on. Our clients are a constant source of feature requests. Likewise we generate a lot of ideas internally in the course of supporting our clients. The challenge is making sure we spend our limited resources on implementing the "right" ideas.

To help us with this, several months ago we moved to an Agile software development process. Specifically, we incorporated a light-weight implementation of Scrum into our existing development processes. While our Montana-based software company has seen a variety of benefits of moving to Scrum, the programmers among us quickly appreciated the clarity that came from creating and sustaining a "product backlog".

So what is a product backlog? The product backlog in Scrum is simply a to-do list for software changes, in priority order. Note that it is a single list. Before we created our product backlog we worked from several to-do lists. We have feature requests coming into our support queue from clients. We have task lists in our project management tool. Each of us has our personal to-do list. And some to-dos are email threads that hadn't yet found their way into a more permanent list. So the challenge was knowing which to-dos to do next.

By putting all product changes in a single list it becomes much easier to make informed decisions about what to do next. Choosing among the ideas still isn't easy. But by having all these ideas in one place, and knowing there is only so much we can do in a week, we are able, if fact, required to make conscious, deliberate decisions about how to spend our limited development resources. It becomes obvious that if we decide to invest time in project A this week, project B will have to wait.

Because the product backlog forces us to constantly evaluate projects in terms of relative value, the features or projects that have the greatest value naturally float to the top. The end result is a single to-do list in priority order. This is a win-win (-win) situation. Developers gain focus instead of wondering which task on which list they should work on next. The company gets the most efficient allocation of resources. And the client receives the highest value system enhancements. 

Next time I will introduce the idea of user stories and describe how we batch stories into software development iterations, known as "sprints" in a Scrum shop like ours.

Ruby on Rails 2.0 upgrade accelerates software rewrite

With the latest System Update to Total Blue System, clients' e-commerce websites are now running on Ruby on Rails Version 2. Ruby on Rails is the framework on which much of Total Blue is built. Version 2 of Ruby on Rails provides performance improvements as well as new functionality that will serve us well as we continue to enhance Total Blue System.

The Ruby rewrite, replacing the legacy PHP code, is a project now into it's 2nd year. In this upgrade, the original reasons for rewriting in Ruby on Rails are showing their merits.

Here's a quick list for the technical minds among our readers -- be they clients or future colleagues:

• HTTP Basic Authentication is how Total Blue System authenticates the API over SSL. There's a new module that supports this.
• All of the web files requested by a browser when loading a web page can slow down the rendering of the page. Now there's a way to consolidate multiple .js javascript or .css stylesheet files into a single request.
• Security improvements for dealing with cross-site scripting attacks, and securing the AJAX user interfaces that communicate back to the server without reloading the entire page.
• Exception handling is better. When there's a problem with the software that powers your e-commerce website, we ought be alerted as soon as or before you are. This continues to be a priority for the product's ability to be self-monitoring and, ultimately, self-healing.
• Secure session handling with better cookie management abilities. This also affects performance of the website, for a more responsive page load.
• Rails 2 provides a lot of new functionality for creating RESTful resources, making even stronger the resource focus of Total Blue's e-commerce order API.

That's enough details to describe for now. In summary, this Ruby on Rails upgrade helps us build off the open-source framework of Ruby on Rails, and in so doing deliver compelling features to the growth-minded e-commerce merchant.

Minimize risk of denial-of-service hosting attacks

If there's a risk to an e-commerce website's up-time or performance that's hard to eliminate, it's the periodic instance of what's known as a denial of service attack (DOS). (In short, it means someone floods your server with so many requests that it chokes -- and prevents your site visitors from viewing your pages.) Refinements of Total Blue System's hosting infrastructure released this week ought improve your e-commerce site's ability to weather such an attack.

We'll spare the details, suffice to say there are configurations at the Linux kernel level (we use Red Hat Enterprise as our Linux distribution), as well as tuning of our connection management for our database, MySQL. And more.

The DOS attack, if even inadvertent, represents the majority of instances recorded in our Status blog which identifies our server cluster's unscheduled hosting downtime.

"Feature" code plus "test" code means few surprises

An important appeal to our e-commerce software product's migration to Ruby on Rails is the built-in testing framework. For e-commerce merchants, it means you can enjoy a continuously updated software product without wincing before each upgrade cycle. New features and functionality, like the product detail page template, can be released with confidence when tests are built into the code.

There's many related features and improvements and dependencies for this new page template. The implications go beyond a new teaser spot, advanced product option matrices, and easier-to-collect product reviews. A great many components to this page are dynamic and conditional. Because there are units tests, functional tests, and integration tests, there are fewer surprises after the new features are released to the live production web site. Nobody likes surprises.

Here's a quick example of what's going on behind the scenes of the product detail page template:

• There are 50 tests with 312 assertions at last count, and that's specific to the product "controller" used on this page template.
• Another 6 tests and 29 assertions, at last count, give confidence to the product controller helper methods.
• A great many more tests are embedded within the models that the product detail page uses to construct the data displayed on the page.

Overall the big gain to be realized is the confidence that comes with each feature upgrade. This means that even heading into a crucial end of year holiday sales period, new features can be released. Conventional wisdom says "no functionality updates after October." Not anymore. Or at least not because of a fear of technology surprises. Improve and optimize your e-commerce feature set right up until Christmas.

Built-in testing integral to Ruby on Rails' appeal

Our rewrite of Total Blue System in Ruby on Rails proceeded for many reasons, but among the most important was the built-in testing framework that comes with it. Perhaps e-commerce isn't the most exacting science in the world, but for our clients, there's very, very little margin for error. When your e-commerce site is a 24 x 7 x 365 cash register accounting for up to 2/3's or more of your revenue, well, it matters to get the details right.

Ruby on Rails gives us the opportunity for automated or scripted testing in ways that PHP just didn't deliver, at least with the ease and elegance we're achieving today in Ruby. There are a couple kinds of test, and each can be important in their own way:

• Unit tests, which examine the integrity of data models. At last count, we'd developed 149 tests with 398 assertions.
• Functional tests, which ensure the proper functioning of what you might think of as a web page. At last count, we'd developed 344 such tests, with 1,717 assertions. wow.
• Integration tests, which analyze a sequence of pages for calculation and display continuity and accuracy. So far in our rewrite, we've completed one such integration test, with 50 assertions of accuracy.

This integration of software-driven testing delivers these benefits to our clients:

1. When a new feature rolls out, as it does frequently as part of our continually updated software product, you don't have to wince, waiting for something to break or a new bug to be discovered. Sure, it still happens once in a while. But it's a more rare occurence all the time, and we're all glad the trend is going in the right direction.
2. When certain peak sales periods roll around, merchants can become very sensitive to any disruption to their e-commerce site. With tests in place verifying the accuracy of the software, we can roll out bug fixes or even new features during critical times with confidence.
3. Our software development team can spend more time introducing features, improving performance, or correcting bugs (fixing it the first time), because we're spending less time manually testing our code, or less time putting out fires that bad code introduced. It's a smoother, more confident process for all.

As a final note, there's much that's been said about the speed that Ruby on Rails affords in software development. Compared to PHP and other choices, we'd have to agree. However, we find the extra time we save ends up being reinvested in writing tests for the code. So the net time is the sime, but the code that is completed exhibits a solidity that our clients can count on.

Ruby on Rails software rewrite well underway

Total Blue System's capabilities manifest a new vigor and resiliency as they are remade using the Ruby on Rails web application framework. Yes, it's a rewrite and one that's been underway since summer 2006.

Our software application was coded in PHP, and runs on top of a Linux operating system with a ubiquitous MySQL database. But after a year of thinking about it, we stepped slowly into a rewrite of the product in 2006 that is continuing to this day. We're pleased with the decision to go to Ruby on Rails.

The reasons are many as to why this major decision benefits our clients and our company. For the sake of this post, we'll point to an example that explains a similar kind of thinking as our own, as they've already summarized many reasons nicely:

• Explanation of why a software application is moving from Java to Ruby on Rails.

Suffice to say, we're moving forward and picking up momentum. We've chosen an incremental refactoring approach, and shunned the idea of a Big Bang upgrade after considering our pacing and need for website stability. That means many pages, especially within the Admin Area for site owners, are already operating under a Ruby on Rails framework. Yes, we're using Mongrel, too.

An outside observer might call E-business Coach a fast follower, looking to learn from others what's working and then imitate the successes while avoiding the early mistakes of others. That's not necessarily the modus operandi of our professional services team, as that work can be experimental and innovative, but it's mostly true about our software. It's interesting that respected contributors to the Java community and other notables in the software development world are finding similar reasons to go to Ruby on Rails.

Of course, fast followers must be rapid in their execution to succeed. And among many other benefits, that's one of the nice things about working with Ruby on Rails. It speeds software development efforts, so we can keep feature development apace with the best Internet marketing and sales tactics.

PS. If Ruby on Rails is news to you, and you're technically inclined, check out this explanation of Ruby on Rails for the rest of us.