Total Blue System Ecommerce

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.