Alignment is everything

For many years, managers in the software industry submitted budgets that were unrealistic to Business Unit managers that had no clue as to what to question, what to approve or where to cut. As business has grown up and increased its expectations of IT departments, Development and Infrastructure has also been forced to mature and face the fact that they aren’t an “overhead” cost. This is especially true in eCommerce.

The Best is the enemy of the Good

I’ve never met an Engineer or Manager of Engineers that didn’t see an infrastructure project as vital to the organization’s ongoing health and stability. I’ve seen (and been) that Manager before. They’ve actually been wrong more than they’ve been right. The reason for this is the lack of a complete picture of the goals of the organization as a whole, the priorities for various Development/Infrastructure (DEV-INF) projects, and the fact that budgeting exists because resources are finite. Sometimes an eCommerce site can limp along for years on a code base that is far from the ideal architecturally, but it may cost far less to maintain and extend it than to upgrade it to the “Next Great Killer Platform” at the cost of revenue-driven projects.

The Holistic view of a Budget

While all projects will have some value, it’s important to prioritize projects in alignment with the overall organization’s strategy and objectives. There is no use in a complete re-architecture of the site when current demands of Marketing, Consumer Experience and other various Business Units cannot be met. The goal in eCommerce is simple. Keep the business growing, keep the site in “five nines”, and refine the user experience to increase conversion. DEV-INF budgets must play in this ballpark or, as a development leader, all credibility with Business Units will be lost; ultimately will leding to a breakdown in communications between Engineering and Business, which is a crisis in an eCommerce workplace.

Metrics are the key

Once projects are aligned with Corporate Objectives, it’s vital to show all cost drivers for these expenses. Many times the cost of ongoing maintenance is not factored in, but can be as much as 65% of an overall budget. This is also true for time budgeted for QE/QA. While the individual Engineer writing code may only write 250 lines that finally make it into production in a three-month long project, how many times he/she had to write it, how much time was eaten up managing and checking this code, and finally what documentation, knowledge transfer and future extendibility these 250 lines will have also affect costs. All these things must be taken into consideration.

Budgeting isn’t just all planning. Once the planning is complete, the spending begins. Vital in this aspect is accountability and assessment of performance. Hard, industry-standard metrics exist to gauge the performance of DEV-INF budget items. In eCommerce I’ve found many easily measured values:

1. Actual vs. Proposed Development times.
2. Actual vs. Proposed Resources.
3. Pre-release bugs.
4. Post-release bugs.
5. Effects upon site stability and performance.
6. Did the Project “Do” what the owners said it would do?
7. Were the expectations of Business Units met, and are these stakeholders satisfied with the results?
8. Did any problems that come up get handled in appropriate manners?
9. Were in-place processes broken?

Approaches

Approaches to DEV-INF budgeting should be aligned with the current culture and expectations of the Business. They must have significant buy-in by various business stakeholders. If business drivers have “skin in the game” as to line-items in a DEV-INF budget, this automatically give credibility to it and also act as a check to make sure that I’ve done my homework. Many successful organizations use the Consolidated Projects Approach to budgeting and allocation for DEV-INF projects with outstanding success. In a nutshell:

Consolidated Projects List basic points:

• IT budget planning process starts before the organization’s process.
• IT managers submit summary project data for consolidation into a single spreadsheet
• These projects are then sorted and prioritized by DEV-INF managers before submission to the overall business Prioritization Committee.
• The Prioritization Committee decides how these projects are to be aligned, budgeted and implemented within the entire Organization’s overall Business needs and strategies.

This approach provides Senior Executives with a complete picture of all proposed projects, their costs, and priority ranking; these units will have a “30,000 foot” picture to make a more informed decision. Total project requirements may now be viewed as a single picture to senior management; priorities become a decision factor. No single group can drive pet projects or non-revenue generating development without prioritization or fully understanding what the business impact or opportunity costs involved are.

This process may be extended with Gate Checks to assure relevance to the goals of the company as time changes. This is especially true with larger organizations that may be widely distributed. Projects can often times have huge scope (ah — to de-scope, another topic!) and can take months of development time.? The needs of a business can change over this period, and any project that is underway should have enough flexibility to move with the times or the business stakeholders or group as a whole should have the gumption to kill or suspend development indefinitely or until such time as solid metrics warrant completion.

My attempt here is to show how I used TDD in an Django application. We’ll create a basic project with a single application and use unit testing to figure out an algorithm an implement it in the application’s class.

Why Test at All?

I’ve spoken to many groups about Test Driven Development (TDD). Many experienced engineers don’t do it because they haven’t been indoctrinated into the practice early, and they are established in an organization where they maintain and extend code that they might have been writing for months or even years. The code has been fully tested and it is solid. Why write unit tests?

Newer developers don’t know how to start with tests. They write code, then write tests, then get frustrated because they are continuously writing code twice. Corners get cut, and at best you get the “bare minimum” of coverage, which is basically what the boss sees and reviews.

Both of these scenarios are unfortunate, because there are a few things that TDD gives gives all engineers and the organizations that they work for:

• More efficient QA. QA engineers and testers don’t have to test for functionality, and they get better quality code.?What does this mean? It means that they get to do the part of their job that is more meaningful to the company as a whole. If the basic code and functionality are automatically tested, QA can then find the border conditions and those evil underlying non-obvious bugs that can kill an application, and if large enough, kill a company’s profits.
• Better and more cohesive organizations. Test Driven Development builds confidence throughout the entire organization. Engineers working often in geographically dispersed groups need to “trust” each other, their skills and abilities. If everyone in the organization is using TDD, these groups will know that the quality coming from others will work. This not only creates trust amongst engineers, but throughout the organization, from Marketing and Business resources all the way through QA.
• Professionalism. Being a “Pro” doesn’t mean generating thousands of lines of code.?It means generating efficient, simple to maintain, easily configurable code that “just works” every time. It not only has to work, it has to be tested and documented.
• Peer pressure to “do the right thing”. If the senior members and thought leaders of an engineering group are all using TDD, documenting their code and communicating effectively, this will spread throughout the organization and foment a best practices environment.

Test Driven Development with high unit test coverage creates efficient, spirited and profitable software. The balance of this post will explain just how I use TDD to implement a complex Bank Routing Number (ABN) validation class. I am assuming that the reader is familiar with Django, and has a comfortable understanding with basic Django and Python development principles:

Create the Project and Application

My application’s name is

valid_lib

It is destined to be a Service Platform that allows all kinds of complex financial form data to be validated through a ReSTful interface. At the moment I’m not worried about the Service, the Interfaces or even the Business Model. Currently, I want to get all the validation algorithms and calculations in place. The rest of the stuff is pretty easy. At the command line, in my Django development directory, I type:

django-admin.py startproject valid_lib

To start my project. I cd into the valid_lib directory and then type:

django-admin.py startapp finvs

To create my application and it’s directory. At this point I add the valid_lib.finvs to my INSTALLED_APPS in the the settings.py file, and while I’m there I add my database information, even though I really won’t be using it yet. I also add another folder in the finvs directory that I name util. Run a manage.py syncdb against the application’s root and you should be good to go. Everything should now look like fig 1:

fig 1: Initial TDD validation app structure

(I’m writing this on my MacBook Pro and using Textmate, but you should be getting similar results however you’re doing it)

Notice that there is a test.py file in the finvs directory. This is where we’re going to start. Django’s default unit testing fixture looks for this file and will execute tests within it. We’ll open that file up and begin writing our code there.

ABN Validation

ABA (American Banker’s Association) routing numbers (ABNs) are used to identify financial institutions when making transactions. This number is usually required when setting up a bank account for direct deposits, automated payments, etc. Or when making payments by “paperless” check over the phone or online.

These routing numbers include a checksum digit which can be used to help verify if a given number is valid or not.

The algorithm checks the first second and third number and adds them together, then iterates through every three numbers (total of 9) to return a value. If the resulting sum is an even multiple (think modulus here…) of ten (but not zero), the ABA routing number is good. ?We’ll now write a test with a valid ABN to see if we can get things to work correctly. In the tests.py file, write:

"""
This file tests the finvs application
"""
import unittest
from django.test import TestCase

#Here are some bank numbers that we can run tests against...
SHORT_BAD_ABN_NUM = 1000012
LONG_BAD_ABN_NUM = 255073345999
BAD_ABN_NUM = 255073545
GOOD_ABN_NUM = 255073345

class ValidatorsTestCase(unittest.TestCase):

    def setUp(self):
        self.value = CITY_CODE_FRAUD

    def testAbnAlgorythm(self):
        """Tests the algorythm with a known good bank number.
           This test is here to create the algorythm to be used
             in the validator implementation.  When it's right,
             cut and paste it into the validator class.

           The algorithm checks the first second and third number
            and adds them together, then iterates through every
            three numbers (total of 9) to return a value.

           If the resulting sum is an even multiple of ten
            (but not zero), the ABA routing number is good.
           """
        n=0
        bank_str = str(GOOD_ABN_NUM)
        num_length = len(bank_str)
        if (num_length ==9):
            for j in range(0,num_length,3):
                t = int(bank_str[j]) #this is the first digit
                ti = int(bank_str[j + 1]) #this is the second digit
                tii = int(bank_str[j + 2]) #this is the third digit
                n += (t * 3)+ (ti * 7)+ tii #add them up
            #check for zero and modulus of 10
            print((n != 0) & ((n % 10) == 0))  #we'll take this line out when we get it right.
            self.assertTrue((n != 0) & ((n % 10) == 0))

Now, at the application root, run:

python manage.py test finvs.ValidatorsTestCase

You should get something very similar to this:

$ python manage.py test finvs.ValidatorsTestCase
Creating test database...
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Installing index for auth.Permission model
Installing index for auth.Message model
True
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
Destroying test database...

The True that you see in the output is your print statement. Notice that the system also creates and destroys a test database. This is extremely cool functionality that can be used with Django’s Fixtures, but we’re not going to use it here for this code set. We haven’t written a line of production code, but our test passes, and if you look at the test, it is the basis for the actual implementation!

Implement It!

We’re really close, but we’ll need to make a few changes before we implement it in our “production” code. Seriously, we’re really close!

In the utils directory, create the file validation_formulas.py This is where we’ll add our ABN validation class. In my test code I created a check to ensure that the number sent in had exactly 9 digits. I did this because I didn’t want to have a try / except block, and to keep it clean. Feel free to add this if needed. The other change is that we actually need to return something — True or False in this case. The test code’s def doesn’t return anything, it just makes an assertion. To validate something, we need to insert a parameter into the method and then return a true/false. We also need to give it a name. In the validation_formulas.py file, you can now insert:

class ValidationFormulas:

    def isBankRoutingNumber(self,bankNumber):
        """Parses the bank routing number for purposes of finding a fraudulent entry.
            the algorithm check the first second and third number and adds them together,
            then iterates through every three numbers (total of 9) to return a value.

           If the resulting sum is an even multiple of ten (but not zero), the ABA
            routing number is good.

           param -- bankNumber the 9 digit bank number;

           return boolean true if number is valid, false if not. false is the default
           """
        n=0
        retbool=False
        bank_str = str(bankNumber)
        num_length = len(bank_str)
        if (num_length ==9):
            for j in range(0,num_length,3):
                t = int(bank_str[j])
                ti = int(bank_str[j + 1])
                tii = int(bank_str[j + 2])
                n += (t * 3)+ (ti * 7)+ tii
            retbool = (n != 0) & ((n % 10) == 0)
        #return the value
        return retbool

Notice the added documentation. Some of it is cut and paste from the Test, the rest is information that you’ll want to convey to anyone that is using this code in the future, because hopefully at some point the company you work for will realize just how brilliant you are and promote you to CTO, where you won’t get to write code anymore. You sure as heck don’t want to leave the poor schlep that is hired to take your place in the dark!

Also notice that I have a default return of False some applications may need a different default return, or this return may be handled in a manager class that registers the default returns in some kind of persistence layer that is more dynamic. Your mileage may vary.

Wrapping it Up

There it is. You’ve written a test first. You’ve used the implementation of the test and created a sensible implementation. If there are other ways of refining your code or cleaning things up, you can always go back and make more changes. But your’e not done. You need to write more tests to actually verify that this algorithm works, that it shows false for bad routing numbers, and that it an spot when the length of the number is incorrect without throwing any index out of bounds exceptions or the like. you can then add more test methods to your ValidatorsTestCase class. I’ve also leveraged the setUp method that is provided with the framework to generate my constants for me. The code will then look like this:

"""
This file tests the finvs application
"""
import unittest
from django.test import TestCase
from valid_lib.finvs.utils.validation_formulas import ValidationFormulas

class ValidatorsTestCase(unittest.TestCase):

    def setUp(self):
        self.SHORT_BAD_ABN_NUM = 1000012
        self.LONG_BAD_ABN_NUM = 255073345999
        self.BAD_ABN_NUM = 255073545
        self.GOOD_ABN_NUM = 255073345

    def testAbnAlgorythm(self):
        """Tests the algorythm with a known good bank number.
           This test is here to create the algorythm to be used
             in the validator implementation.  When it's right,
             cut and paste it into the validator class.

           The algorithm checks the first second and third number
            and adds them together, then iterates through every
            three numbers (total of 9) to return a value.

           If the resulting sum is an even multiple of ten
            (but not zero), the ABA routing number is good.
           """
        n=0
        bank_str = str(self.GOOD_ABN_NUM)
        num_length = len(bank_str)
        if (num_length ==9):
            for j in range(0,num_length,3):
                t = int(bank_str[j])
                ti = int(bank_str[j + 1])
                tii = int(bank_str[j + 2])
                n += (t * 3)+ (ti * 7)+ tii
            self.assertTrue((n != 0) & ((n % 10) == 0))

    def testBankRouter(self):
        """Tests the algorythm in the validator against
              known good and bad bank numbers.
           """
        bank_num = self.SHORT_BAD_ABN_NUM
        formt = ValidationFormulas()
        bool = formt.isBankRoutingNumber(bank_num)
        self.assertFalse(bool)

        bank_num = self.LONG_BAD_ABN_NUM
        formt = ValidationFormulas()
        bool = formt.isBankRoutingNumber(bank_num)
        self.assertFalse(bool)

        bank_num = self.BAD_ABN_NUM
        formt = ValidationFormulas()
        bool = formt.isBankRoutingNumber(bank_num)
        self.assertFalse(bool)

        bank_num = self.GOOD_ABN_NUM
        formt = ValidationFormulas()
        bool = formt.isBankRoutingNumber(bank_num)
        self.assertTrue(bool)

I’ve added an import for the “production” class that i’m testing (ValidationFormulas). Finally, I’ve added a new method that implements new tests against the actual methods in this class to check my work. Running the tests now reveal:

Creating test database...
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Installing index for auth.Permission model
Installing index for auth.Message model
..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK
Destroying test database...

If someone in the future messes with the “production” code implementation and things get out of whack, It will break here instead of in front of the user. By combining this with a continuous-build environments, a lot of mistakes can be caught extremely fast, sometimes within seconds of a source control check in!

Enjoy.

I’ve been dancing around Pinax for a few months.  Their philosophy that “there are a few different categories of web applications and they share similar basic functionality – which shouldn’t have to be written from scratch every time something needs to get done,” is congruent with my beliefs. While writing greenfield applications is a source of delight for competent engineers, it is preferable to build on a solid foundation of “super-libraries” and add the functionality that is needed for your particular requirements.Pinax offers this and so much more.  The developers of Pinax have created a set of “standard” platforms that may be used as an extendable base for anyone’s further development. The applications that they have created are:

• sample_group_project: This project demonstrates group functionality with a barebones group?containing no extra content apps as well as two additional group types,?tribes and projects, which show different membership approaches and?content apps.

• intranet_project: This project demonstrates a closed site requiring an invitation to join and?not exposing any information publicly. It provides a top-level task tracking?system, wiki and bookmarks. It is intended to be the starting point of sites?like intranets.

• social_project: This project demonstrates a social networking site. It provides profiles,?friends, photos, blogs, tribes, wikis, tweets, bookmarks, swaps,?locations and user-to-user messaging.?In 0.5 this was called “complete_project”.

• cms_project_holidayhouse: A very simple CMS that lets you set up templates and then edit content, including images, right in the frontend of the site.?The sample media, templates and content including in the project demonstrate?a basic site for holiday house rentals.

• code_project: This project demonstrates group functionality and the tasks, wiki and topics?apps. It is intended to be the starting point for things like code project?management where each code project gets its own wiki, task tracking system?and threaded discussions.

• private_beta_project: This project demonstrates the use of a waiting list and signup codes for?sites in private beta. Otherwise it is the same as basic_project.

• cms_project_company: A very simple CMS that lets you set up templates and then edit content,?including images, right in the frontend of the site. The sample media, templates and content including in the project demonstrate?a basic company website.

• basic_project: This project comes with the bare minimum set of applications and templates?to get you started. It includes no extra tabs, only the profile and notices?tabs are included by default. From here you can add any extra functionality?and applications that you would like.

source – Pinax documentation

These projects are all quite well developed even if they are not at a “1.0″ release.  They all contain registration, email confirmation functionality, profile functionality and other basic “member” web application attributes.  I spent yesterday looking through the documentation and various on-line tutorials and deployed the sample_group_project on my Ubuntu 9.1-powered laptop.

I found that I had to jump between a couple of tutorials and once needed to completely wipe and rebuild to get it right, but the results were quite spectacular once I got it right.  Out of the box, user profiles, photo sharing, blogs, tweets, groups, Yahoo map locations, bookmarks and a “merchandise swapping and trading” application appear with no additional coding.  This application also enjoys Django’s dynamite Admin modules.

In a future post I’ll follow through and show what worked for me and endeavor to explain how easy it can be once you have everything in place.  As I develop the application, I’ll further post what I did to develop, deploy and extend the application for further use.

Is it Ready for the Enterprise?

I’m not sure if I can completely answer this question.  From an engineering/architecture point of view, it’s spot on.  For application maturity and production, that’s another matter.  Are there products using Pinax already?  What size are they?  Have they found, fixed and published bugs?

Quality Assurance in open-source projects can be in-bred amongst the developers and engineers on a project.  While they “know” the product the best and work to ensure functionality and eventual viability, they also make decisions on what needs to be fixed and “what can wait”.  In a strong enterprise environment, QA stands alone as a benevolent antagonist against development; business requirements will expose different issues and eventually make the product stronger.  If, as a technology leader, you are considering the use of Pinax, it would be prudent to add extra Quality Assurance time to the planned schedule to ensure future stability and a great customer experience.

Found a fix after searching for two days; ? in case you’re having the same problem, here it is.

Open a terminal (if you don’t have a mouse hooked up, use Alt+F2). then “su” and give the root password (I tried doing this with?sudo and still didn’t have enough permission. I ? “think” you need to be root). At the prompt, type:

echo options psmouse proto=exps > /etc/modprobe.d/psmouse.modprobe

At the next prompt, type:

reboot

Your touchpad will come back up after rebooting.

Update 11/12/09

I did an apt-get upgrade just after the release was announced.? ?It killed my NVidia driver and would boot up? ?once in awhile? in recovery mode.? ?I finally got frustrated and downloaded and burnt a DVD on my Mac, wiped the disk on my Dell and reinstalled the thing.? ?It?s working fine now; there is no bugginess in the touchpad, etc…

Ubuntu changed a lot of stuff in this release.? ?I find it almost similar to Mac?s move from OS9 to OSX, except that Mac ?warned us? that this was a big move.? ?Ubuntu rushed this release to coincide with Windows 7 and frankly they really dropped the ball on the message, the QA and the overall polish of the product.? ?Thank God I never trusted it enough to leave anything important on the Dell.? ?I?ve got Macs for the critical information over the house that are as stable as the Pyramids.? ?Snow Leopard was a? ?bug fix? release.? ?They?ve come a long way from the pre-Jaguar days, that?s for sure.? ?Ubuntu should take note.

Funny thing is, I actually like using the Ubuntu as much or more than the Mac, but then again, I like writing Python code in front of the TV with a cocktail!

TDD is almost like riding a bike; you really don’t know how easy it is and how much fun you can have with it until you get up and going. When the training wheels are off, Test Driven Development (TDD) becomes a brand new world full of possibilities.

I have been writing unit tests for years, out of necessity to start, but later out of the desire to lead by positive example. Having come to the Computer Sciences later than most of my colleagues, I decided early on to adopt best practices to not only ensure that I wasn’t breaking builds, but I wanted to build the respect of my colleagues. Now, I really like to make sure that everything I commit to my various development communities are well-tested and as clean as possible.

Test Driven Development practices give me the verification necessary to check code in with confidence.? ?Unit testing builds this sense of security in three different ways:

• It guarantees that what I’ve written works, whether it’s new or integrated into existing platforms and applications.
• It makes me keep my code simple. If I start writing a test and it becomes a dependency-driven, closely-coupled “implementation monster”, I can pretty much guarantee that the code is going to be the same. I’ll try to refactor this and use my tests in this manner as a guage for it’s quality.
• In large environments that have continuous-build systems, there is always the inevitable “break” that stirs up panic and finger-pointing. Code with strong test coverage rarely breaks a build. This develops a team’s confidence in an individual’s engineering skills.

So exactly HOW would I begin development by writing a test BEFORE I write any actual code, and WHY would I even want to?

We will address the “why” aspect first. “Old School” developers and my earliest mentors would create “fake” layers and tiers would test the code they were writing. A “fake layer” is defined as some type of data or code that simulates the functionality of an “expected” production-level deployment. Some development communities call these fake layers “tools” or “simulators”.

These ?fake layers? would be similar to tests, but these guys wouldn’t write tests because they never did in the past (and some still don?t!).? ?”Fake layers” can create all sorts of problems.? ?They tend to get passed around as API or Interface points, and as two different groups develop against these simulators, each makes compromises because they “must” integrate with the “tool”.? ?Testing just gives you a better framework for creating fake layers that you can create your code around.? ?It also creates a path of communication between development groups, negating the need for tools and promoting integration environments.

HOW do you start with a test?

Implementing your first Test Driven Development cycle is simple. Let?s say you will be writing an application that talks to a database that currently exists (you could even start without the database and just an ER diagram). Looking at your requirements, you are probably going to implement CRUD operations against it. You start thinking about what the interface for the Data Access Object is going to look like. ?Hmmmm? ?Let?s see? CREATE, READ, UPDATE, DELETE. So your simple Interface has four methods.

Now start with a test. Create a class called MyDAOTestImpl. MyDAOTestImpl will test the ?Implementation Class for the interface?s methods. When we create a method in the test that tests well, we then create the interface method, then the move the test method, with proper modifications, into the a new ?MyDAOImpl class. It makes you create very smart tests that ensure you are ?CRUD-ing? the data you expect. Coding in this way also creates the implementation to your interface at the simultaneously with the test. Finally, it makes you think about the interface and the implementation, and affects your overall design in a very positive light.

Now let?s take it further. You?ve created all the methods in your Impl class and your Interface methods can be extracted and the actual interface is now written and, for the time being, complete. Now let?s write a test that ?calls the Interface and implements a ?new Implementation Class through it. You can now see how clean your Interface is? –? how easy are your methods to use, how are things being cleaned up, and finally, how are exceptions being caught? Are you satisfied with the results so far? If so, proceed to the next layer!

The next layer may possibly involve a creating a Session Facade to allow for user interaction with the database (more complex implementations would have deeper structures). You may create an Object model that translates the Database relationships into some type of presentation-level object gouping, and write tests to reflect this. It becomes very obvious what objects you need when you start writing a test that outputs expected data a conditioned manner.

Your first cut at it may look like horrible code; it may be some type of monolithic monster, but it will give you clarity to understand how things must be split up. You keep refactoring and writing tests, and sooner rather than later, you are suprisingly code-complete, tight and ready for QA!

Do what works for you.

Even after all this I?m sure that some engineers are completely poo-pooing this way of developing applications. Many say that it’s writing “extra code”.? ?I dispute this.? ?Before writing so many tests, I wrote quite a bit of code and refactored it before it was checked in.? ?Sometimes I’d get caught up in a particularly cruel block of logic that would take hours to get to the bottom of, or worse I’d break somebody else’s logic block in another part of the application and it wouldn’t be found for a few days.? ?This was the worst case.? ?A set of unit tests would have found it in seconds, and it would take minutes to fix.? ?Concurrently, a set of tests to track the expected output of a logic block would have ensured that anything I’m stuck on can be worked through quickly.

Still not convinced?? ?That?s fine if it works for you.? ?TDD works for me.? ? I?ve found that as my tested code base and coverage build up, my productivity jumps dramatically as the project continues because I write less and less code as the project nears completion.

Test Driven Development is all about making everything solid. Using TDD, you?ll be writing one line of code to your previous ten, and when your ?business guy? walks in and asks for a change, you?ll be going home at 5 instead of having your car languish in the parking lot after midnight. You?ll also have more confidence in the quality of your check-ins and builds, and when things go wrong and the inevitable finger-pointing starts, you won?t be a pointee!

The Restlet API is a Java framework for the REST architectural style. The Noelios Restlet Engine (NRE) is available as the reference implementation, as well as several extensions to the API and to NRE.

Why is it cool?

To Quote Jérôme Louvel, founder and lead developer of Restlet:

It’s cool because it delivers on this statement.  I love that fact that you can send a request to a Restlet engine, and it will return back this amazing variety of Representations based upon it.  The first exposure to Restlet for me came when I put forth a design for a beacon tracking system that could be triggered via HTML pages, server-side calls, log-file digestion and anything else I could think of.  The lead developer turned me on to Restlet.

I later found ways to hook it up to a JBoss-Rules system, a Low-Latency Data Store for delivering customer demographic information, and a Affiliate Network lead quality validation system.  Each application had completely different requirements except that they needed to be a service.  I decided on REST instead of  SOAP, and the “rest” is in the implementations.  It subscribes to all my basic requirements for an application:

Once you work with Restlet a bit, get an application running, manipulate what you’ve built into other things, and get real expertise around it, you’ll find, like I have, that it just works.

The Jars you need for this application.

To run this application, you’ll need the following jar files:

• com.noelios.restlet.ext.servlet_2.5.jar
• com.noelios.restlet.jar
• org.restlet.jar
• xalan-2.7.0.jar
• xrcesImpl.jar

Running Restlet from Tomcat — Configure the web.xml file.

You’ll want to run Restlet from a WAR file in most production cases, but you really don’t have to.  I like to use it because it creates homogeneous environments for my ITOPs people to work with; nice, similar stacks for maintenance purposes, so we’ll do it this way here. It is my belief that productizing applications with little or no Network Configurations is key to long-term viability. The following is the web.xml file used in the web application that we’re deploying our service through:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
    <display-name>first steps servlet</display-name>
    <!-- Application class name -->
    <context-param>
        <param-name>org.restlet.application</param-name>
        <param-value>
            com.dg.demo.restlet.application.DemoApplication
        </param-value>
    </context-param>

    <!-- Restlet adapter -->
    <servlet>
        <servlet-name>ServerServlet</servlet-name>
        <servlet-class>
            com.noelios.restlet.ext.servlet.ServerServlet
        </servlet-class>
    </servlet>

    <!-- Catch all requests -->
    <servlet-mapping>
        <servlet-name>ServerServlet</servlet-name>
        <url-pattern>/demo/*</url-pattern>
    </servlet-mapping>
</web-app>

Note that com.dg.demo.restlet.application.DemoApplication will be the Application class file that you will write.  ServerServlet comes with the libraries.  Note that the “servlet-mapping” that I’m using here is “/demo/*”.  This means that all URLs directed to the Restlet must have “/demo/” as their root, (i.e. http://localhost:8080/demo/…).

The Application Class

The Application Class is the “manager” for the Restlet Application. This class will find the proper resource with respect to the URL that is presented to it.  In the case of this application, we’ll be mapping incoming URLs to:

• a “System up” Resource that shows that the Restlet is actually running and mapping correctly.
• a “Mapping” Resource that will allow for a list of cities and states to be shown based upon given inputs.
• an “XML” Resource that shows mappings of Cities and States as an XML Representation.

Here is the application Class:

package com.dg.demo.restlet.application;

import com.dg.demo.restlet.resource.CityXMLResource;
import com.dg.demo.restlet.resource.MapResource;
import com.dg.demo.restlet.resource.SystemResource;
import org.restlet.Application;
import org.restlet.Context;
import org.restlet.Restlet;
import org.restlet.Router;
import org.restlet.data.MediaType;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.resource.StringRepresentation;

/**
 * The Application Root Class.  Maps all of the resources.
 */
public class DemoApplication extends Application {

    /**
     * Creates a new DemoApplication object.
     */
    public DemoApplication() {
        //empty
    }

    /**
     * Public Constructor to create an instance of DemoApplication.
     *
     * @param parentContext - the org.restlet.Context instance
     */
    public DemoApplication(Context parentContext) {
        super(parentContext);
    }

    /**
     * The Restlet instance that will call the correct resource
     * depending up on URL mapped to it.
     *
     * @return -- The resource Restlet mapped to the URL.
     */
    @Override
    public Restlet createRoot() {
        Router router = new Router(getContext());

        router.attach("/sys", SystemResource.class);
        router.attach("/{key}/maps", MapResource.class);
        router.attach("/xml", CityXMLResource.class);

        Restlet mainpage = new Restlet() {
            @Override
            public void handle(Request request, Response response) {
                StringBuilder stringBuilder = new StringBuilder();

                stringBuilder.append("<html>");
                stringBuilder.append("<head><title>Sample Application " +
                        "Servlet Page</title></head>");
                stringBuilder.append("<body bgcolor=white>");
                stringBuilder.append("<table border=\"0\">");
                stringBuilder.append("<tr>");
                stringBuilder.append("<td>");
                stringBuilder.append("<h3>available REST calls</h3>");
                stringBuilder.append("<ol><li>/sys --> returns system " +
                        "up and date string</li>");
                stringBuilder.append("<li>/all/maps --> returns a list" +
                        " of all the cities and states</li>");
                stringBuilder.append("<li>/{key}/maps --> returns a list " +
                        "of cities for a particular state (CA,IL,TX)<br/>");
                stringBuilder.append("using one of the keys from the \"all\" " +
                        "call<br/> pasted in place as the {key}.</li>");
                stringBuilder.append("<li>/xml --> POST or GET URL or web " +
                        "form elements as XML to this</li>");
                stringBuilder.append("</ol>");
                stringBuilder.append("</td>");
                stringBuilder.append("</tr>");
                stringBuilder.append("</table>");
                stringBuilder.append("</body>");
                stringBuilder.append("</html>");

                response.setEntity(new StringRepresentation(
                        stringBuilder.toString(),
                        MediaType.TEXT_HTML));
            }
        };
        router.attach("", mainpage);
        return router;
    }
}

With this Application I tried to show a “default”, “servlet-like” page returned by a Restlet created as an anonymous inner class — you can do that with all your URL requests if you like, but creating different Resource implementations is much easier to manage and write tests for. It is also very important to set the Context of the application in the Constructor (calling the superclass).  I forgot to do this and lost about an hour before I finally found it.

Once the Resources are mapped, You’re ready to rock and roll.  We’ll create a simple Model, and then get into the Resource Classes.

A Simple Model to Work From:

We need something to do with our application, so I decided to create a simple “persistence layer” that has a map of cities and states.  I could have done more and it could have been more complex, but I just wanted something that you can bang against and get an idea about how it all works.  I created an implementation class that contains a map of cities and states extending java.util.AbstractMap.  I then exposed various structures of this mapping through an interface class that the application will use to return information by implementing an Interface against it, obfuscating anything that I didn’t want to expose:

package com.dg.demo.model;

import java.util.List;
import java.util.Map;
import java.util.Set;

/**
 * A simple interface to return a map of
 * values for the demonstration.
 */
public interface MappedPersistence {

    // returns a formatted string of the cities
    // mapped to a particular state.
    String getCommonValues(String state);

    // returns a set of cities, which are
    // the map keys.
    Set<String> keys();

    // returns a map of cities <K> with states<V>
    // as the value.
    Map<String, String> proxy();

    // returns a set of states available.
    Set<String> valueSet();

    //returns a List of cities.
    List<String> mappedKeys(String s);

}

The implementation of the Interface above is MappedCityPersistence:

package com.dg.demo.model.impl;

import com.dg.demo.model.MappedPersistence;

import java.util.AbstractMap;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Set;

/**
 * Implementation of MappedPersistence Interface.
 * Extends Abstract Map, but obfuscates the
 * mappings via the MappedPersistence Interface.
 */
public class MappedCityPersistence
        extends AbstractMap<String, String>
        implements MappedPersistence {

    private Map<String, String> proxyMap;

    public MappedCityPersistence() {
        proxyMap = new HashMap<String, String>();
        loadProxy();
    }
    // this class must be implemented...
    public Set<Entry<String, String>> entrySet() {
        return proxyMap.entrySet();
    }
    //the values for persistence.
    private void loadProxy() {
        proxyMap.put("Los Angeles", "CA");
        proxyMap.put("Santa Barbara", "CA");
        proxyMap.put("San Francisco", "CA");
        proxyMap.put("San Diego", "CA");
        proxyMap.put("Dallas", "TX");
        proxyMap.put("Houston", "TX");
        proxyMap.put("Austin", "TX");
        proxyMap.put("El Paso", "TX");
        proxyMap.put("Chicago", "IL");
        proxyMap.put("Joliet", "IL");
        proxyMap.put("Naperville", "IL");
        proxyMap.put("Oak Park", "IL");
    }

    @Override
    public String toString() {
        StringBuilder builder =
                new StringBuilder("City/State values:\n");
        for (String s : proxyMap.keySet()) {
            builder.append(s).append(" => ")
                    .append(proxyMap.get(s)).append("\n");
        }
        return builder.toString();
    }

    public String getCommonValues(String value) {
        StringBuilder builder =
                new StringBuilder("Cities located in "
                        + value + ":\n");
        for (String s : proxyMap.keySet()) {
            if (proxyMap.get(s).equals(value)) {
                builder.append(s).append("\n");
            }
        }
        return builder.toString();
    }

    public Set<String> keys() {
        return proxyMap.keySet();
    }

    public Map<String, String> proxy() {
        return this.proxyMap;
    }

    public Set<String> valueSet() {
        Set<String> quickAndDirtySet = new HashSet<String>();
        for (String s : proxyMap.values()) {
            quickAndDirtySet.add(s);
        }
        return quickAndDirtySet;
    }

    public List<String> mappedKeys(String s) {
        List<String> quickAndDirtyList = new ArrayList<String>();
        for (String key : proxyMap.keySet()) {
            if (proxyMap.get(key).equals(s)) {
                quickAndDirtyList.add(key);
            }
        }
        return quickAndDirtyList;
    }

    public static void main(String[] args) {
        MappedCityPersistence p = new MappedCityPersistence();
        System.out.println(p.getCommonValues("TX"));
    }
}

Note the extra methods that are now obfuscated by the Mapped Persistence Interface.

Building the Resources that are Mapped to URLs

The first, and easiest to implement of the Resources is the SystemResource that I created to show whether or not I got the mappings right and if the system is running or not.  It returns a basic “text” string that says the system is running and what time the JVM says it is:

SystemResource.java

package com.dg.demo.restlet.resource;
import org.restlet.Context;
import org.restlet.data.MediaType;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.resource.Representation;
import org.restlet.resource.Resource;
import org.restlet.resource.StringRepresentation;
import org.restlet.resource.Variant;

import java.util.Calendar;

/**
 * Simple String retrieval to determine whether the system is up
 * and running.  it adds a timestamp for varification that the
 * message isn't cached and allows for identification of
 * the time zone.
 */
public class SystemResource extends Resource {

    /**
     * Creates a new MapResource object.
     *
     * @param context  -- Restlet Context Instance.
     * @param request  -- Restlet Request Instance.
     * @param response -- Restlet Response Instance.
     */
    public SystemResource(Context context,
                          Request request,
                          Response response) {
        super(context, request, response);
        // Here we add the representation variants exposed
        getVariants().add(new Variant(MediaType.TEXT_PLAIN));
    }

    /**
     * Do not allow post to this resource.
     *
     * @return -- always false for this resource.
     */
    public boolean allowPost() {
        return false;
    }

    /**
     * default method for "get" from Client Application.
     *  Returns wheter or not the system is available,
     * and the current time.
     *
     * @param variant -- Available variants.
     *
     * @return -- A String representing whether or
     *            not the demo system is available, etc.
     */
    public Representation represent(Variant variant) {
        //LQSCache.getInstance();
        String message = "hello!, the Demo " +
                "Service is available." +
                " Time of request is:"
                + Calendar.getInstance()
                .getTime().toString();

        return new StringRepresentation(message,
                MediaType.TEXT_PLAIN);
    }
}

The mapping resource shows all of the cities and states mapped, and also shows the cities mapped to a particular state when that state is input within the url (i.e. http://localhost:8080/demo/all/maps — to show all cities and their city mappings, ./demo/TX/maps to get all cities mapped to Texas):

MapResource.java

package com.dg.demo.restlet.resource;

import com.dg.demo.model.MappedPersistence;
import com.dg.demo.model.impl.MappedCityPersistence;
import org.restlet.Context;
import org.restlet.data.MediaType;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.resource.Representation;
import org.restlet.resource.Resource;
import org.restlet.resource.StringRepresentation;
import org.restlet.resource.Variant;

/**
 * Utility Resource to view the various strings
 * mapped in the Persistence.
 */
public class MapResource extends Resource {

    /**
     * The map requested by the client application
     */
    String mapName;

    /**
     * Creates a new MapResource object.
     *
     * @param context  -- The restlet Context instance.
     * @param request  -- The restlet REquest instance.
     * @param response -- The restlet Response instance.
     */
    public MapResource(Context context,
                       Request request,
                       Response response) {
        super(context, request, response);
        this.mapName = (String) request.getAttributes().get("key");

        // Here we add the representation variants exposed
        getVariants().add(new Variant(MediaType.TEXT_PLAIN));
    }

    /**
     * Do not allow post to this resource.
     *
     * @return -- always false for this resource.
     */
    @Override
    public boolean allowPost() {
        return false;
    }

    /**
     * Collect the values for a particular mapping and return
     * a formatted string.  By inputting "all" into the request,
     * it returns a list of the mappings available. When this
     * service returns, substituting "all" for one of the
     * returned values will return the values for that mapping key
     *
     * @param variant -- The variant describing the return mappings.
     *
     * @return -- a formatted string with the map values as a list.
     */
    @Override
    public Representation represent(Variant variant) {
        //UDCAPICache.getInstance();
        MappedPersistence persistence = new MappedCityPersistence();

        //LQSCache.getInstance();
        String message;
        //String mapName = (String) getRequest().getAttributes().get("key");

        if (mapName.equals("all")) {
            message = persistence.toString();
        } else if (persistence.valueSet().contains(mapName)) {
            message = persistence.getCommonValues(mapName);
        } else {
            message = "NO VALUES FOUND FOR: " + mapName;
        }
        return new StringRepresentation(message, MediaType.TEXT_PLAIN);
    }
}

The XML resource returns a list of cities that are mapped to each state as an xml representation.  It allows a post or get, via the “acceptRepresentation()” (POST) and “represent()” (GET) methods.  I’ve put both of these in bold, along with other things that seemed important to me.  Each calls the same private method that creates the XML representation:

package com.dg.demo.restlet.resource;

import com.dg.demo.model.MappedPersistence;
import com.dg.demo.model.impl.MappedCityPersistence;
import org.restlet.Context;
import org.restlet.data.MediaType;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.resource.DomRepresentation;
import org.restlet.resource.Representation;
import org.restlet.resource.Resource;
import org.restlet.resource.Variant;
import org.w3c.dom.Document;
import org.w3c.dom.Element;

import java.io.IOException;

public class CityXMLResource extends Resource {

    /**
     * @param context  -- Restlet Context Instance.
     * @param request  -- Restlet Request Instance.
     * @param response -- Restlet Response Instance.
     */
    public CityXMLResource(Context context,
                           Request request,
                           Response response) {
        super(context, request, response);
        getVariants().add(
                new Variant(MediaType.TEXT_PLAIN));
        getVariants().add(
                new Variant(MediaType.APPLICATION_XML));
        //handle(request,response);
    }

    /**
     * Flag to allow POST via web form.
     *
     * @return true if POST is allowed, false if not.
     */
    public boolean allowPost() {
        return true;
    }

    /**
     * Represent the requested object in the requested format.
     *
     * @param variant -- the requested variant or default.
     *
     * @return an XML representation or an error string.
     */
    public Representation represent(Variant variant) {
        DomRepresentation representation = null;
        try {
            representation = getFraudXMLRepresentation();
        } catch (IOException e) {
            e.printStackTrace();
            getResponse().setEntity("ERROR " + e.getMessage(),
                    MediaType.TEXT_PLAIN);
        }
        return representation;
    }

    /**
     * Handle a POST Http request.
     *
     * @param entity -- the declared entity
     */
    public void acceptRepresentation(Representation entity) {
        System.out.println("USING POST");

        try {
            if (entity.getMediaType()
                    .equals(MediaType.APPLICATION_WWW_FORM, true)) {
                DomRepresentation representation =
                        getFraudXMLRepresentation();
                // Returns the XML representation of this document.
                getResponse().setEntity(representation);
            }
        } catch (IOException e) {
            e.printStackTrace();
            getResponse().setEntity("ERROR " + e.getMessage(),
                    MediaType.TEXT_PLAIN);
        }
    }

    /**
     * Creates the XML that will be returned to the requesting client.
     *
     * @return - The formatted XML Document
     */
    private DomRepresentation getFraudXMLRepresentation() throws IOException {

        DomRepresentation representation =
                new DomRepresentation(MediaType.TEXT_XML);

        MappedPersistence persistence =
                new MappedCityPersistence();

        // Generate a DOM document representing the list of frauds generated..
        Document d = representation.getDocument();

        //The Root Element, with it's corresponding attribute for the total score.
        Element root = d.createElement("citystatemappings");
        root.setAttribute("numberofstates",
                String.valueOf(persistence.valueSet().size()));
        d.appendChild(root);

        //If there are no frauds, then we skip this and just return the root.
        for (String state : persistence.valueSet()) {
            Element stateElement = d.createElement("state");
            stateElement.setAttribute("name", state);

            for (String city : persistence.mappedKeys(state)) {
                Element cityElement = d.createElement("city");
                cityElement.appendChild(d.createTextNode(city));

                stateElement.appendChild(cityElement);
            }
            //tie the frauds to the root.
            root.appendChild(stateElement);
        }
        d.normalizeDocument();
        return representation;
    }
}

Compile these classes into your web application with your lib jars, and make sure the “web.xml” file is configured as shown earlier in this text.  Create a .war file or run from your IDE.  You should be able to use the URLS that have been configured into the DemoApplication class file to view data in different formats.  If your application is configured to run on http://localhost:8080…

• http://localhost:8080/demo — returns the Representation defined in the “anonymous inner class” of the DemoApplication.

• http://localhost:8080/demo/sys   — returns the “system up” resource and it’s information, something like:

hello!, the Demo Service is available. Time of request is:Tue Sep 23 17:53:42 PDT 2008

• http://localhost:8080/demo/all/maps — returns a list of all the states mapped into the persistence layer:

City/State values:
Austin => TX
Chicago => IL
El Paso => TX
Los Angeles => CA
Naperville => IL
Houston => TX
San Diego => CA
Santa Barbara => CA
Dallas => TX
Oak Park => IL
Joliet => IL
San Francisco => CA

• http://localhost:8080/TX/maps — returns a list of cities mapped to TX:

Cities located in TX:
Austin
El Paso
Houston
Dallas

http://localhost:8080/demo/xml — Finally, you want to get an xml representation of all this (view source):

<?xml version="1.0" encoding="UTF-8"?>
<citystatemappings numberofstates="3">
    <state name="CA">
        <city>Los Angeles</city>
        <city>San Diego</city>
        <city>Santa Barbara</city>
        <city>San Francisco</city>
    </state>
    <state name="TX">
        <city>Austin</city>
        <city>El Paso</city>
        <city>Houston</city>
        <city>Dallas</city>
    </state>
    <state name="IL">
        <city>Chicago</city>
        <city>Naperville</city>
        <city>Oak Park</city>
        <city>Joliet</city>
    </state>
</citystatemappings>

From here you’re on your own. You should be able to extrapolate the tasks that you might need for your projects; there are other representations that you can work with, including some very interesting uses of the java.util.nio libraries that allow for blazing fast file retrieval and delivery. You can even send Java Objects around. It’s worth looking through the Restlet API Docs at this point.

As I migrated from basic HTML to JSPs and finally complex Server-Side Java, I became less and less respectful of client-side languages, and most of my colleagues were pretty much in lockstep with me. While working in the view layer, adding JavaScript was a tedious necessity, and most programmers I worked with built well-made, but structural, scripts to handle the needs of the page.  They knew what they wanted it to accomplish and they just wrote it to “do that thing”.  It “wasn’t worth” digging deep into it, because it is just “throw away” code that the view used; not really worthy of Server-Side Programmers’ attention.

A new interest in JavaScript came onto my radar screen when, as a Principal Engineer at E*******k, I was presented with a problem that involved portal pages and their downloaded page weights. there were also many problems with any changes to the page breaking the very large (600 lines at one point) JavaScript that controlled much of the view layer. 

So I looked into it.

What I found was a gigantic script that controlled all sorts of things, looping through the Document Object Model, backwards and forwards; doing some innerHTML calls, and lots of “if this is happening– do this, disable this, and if anything ends in this, make it appear” kind of things.  It worked quite well, but nobody would dare change it, make changes to the basic UI or even allow it to be touched, because it was so complex and undocumented.  Resources were unavailble to keep up with it.

Being a Principal Engineer gave me the chance to take time and solve problems instead of doing hard core, heads-down coding every day.  I decided to take some time and crack this nut.  I started digging into a few articles about Object Oriented JavaScript and did a few exercises to really try and understand how it could work for me.  I discovered that with the page I was looking at, Tabs controlled a lot about what happened on it.  Depending upon which tab was clicked, different values would appear in the box underneath it — form fields would change, be disabled, etc.

Each Tab triggered a different “Mode” on the page.  So the Page has Modes… Well that would make a nice Object. The Mode has various attributes?  Now we’re getting somewhere!  Eventually this 600 line behemoth, tipping the scales at 86K, become a 64 line midget that, condensed, popped through the pipe at 16k.  Nice win.

What I’m demonstrating here isn’t this particular code. It is the basis for it, and not only that, I think its better than what I first wrote.  I’ve tested it on Mac Safari/Firefox — it should work on IE but I wasn’t able to test, so you might need to tweak.  So much for the disclaimer.

Creating a JavaScript Model to Manipulate Tabs on a Page

code reference - version_1_tabs.zip

Let’s start with the Initial Requirement.  Let’s say you have a requirement that orders 5 tabs that change back and forth with the least amount of scripting possible, and at some later date you might have to do more with it, such as add more tabs or add functionality to each tab.  To make it more complex, the Tab has images as background, so you need to manipulate these as well.

All the images will be manipulated through CSS, so we’re not going to clutter up our beautiful HTML markup with it.  Further, we’re going to not bother with “document.write“, because it can get kinda cluttered in the JavaScript code, I’m still not sure about performance hits using it, and you don’t get any Search Engine love with that, either.  Here below is the original HTML mark-up for the initial requirement (tabpage.html):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
    <title>Object Oriented Tabs</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <style type="text/css">
        @import url( "tabMode.css" );
    </style>

</head>
<body>
<table class="tabToggle" cellspacing="0">
    <tr>
        <td><span class="selectstring">Select Category</span></td>
        <td id="dramaTab">
            <div>
               <a class="tab_0" href="#"
                           onclick="changeMode(DRAMA_MODE);return false;">
                <span>Drama</span></a></div>
        </td>
        <td id="comedyTab">
            <div>
               <a class="tab_1" href="#"
                           onclick="changeMode(COMEDY_MODE);return false;">
                <span>Comedy</span></a></div>
        </td>
        <td id="thrillerTab">
            <div>
               <a class="tab_2" href="#"
                           onclick="changeMode(THRILLER_MODE);return false;">
                <span>Thriller</span></a></div>
        </td>
        <td id="mysteryTab">
            <div>
               <a class="tab_3" href="#"
                           onclick="changeMode(MYSTERY_MODE);return false;">
                <span>Mystery</span></a></div>
        </td>
        <td id="fantasyTab">
            <div>
               <a class="tab_4" href="#"
                           onclick="changeMode(FANTASY_MODE);return false;">
                <span>Fantasy</span></a></div>
        </td>
    </tr>
</table>
    <script type="text/javascript" src="tabtoggle.js"></script>
</body>
</html>

You will notice that for each href, there is an “onclick” value that is mapped to a const value (shown in the JavaScript file) in JavaScript.  For those of you that only code in IE, which doesn’t recognize const, it is exactly what you think.  an immutable value that is set and may not be changed.  Why is it cool?  because the browser maps it into memory, and it becomes a reference instead of a variable — faster, like a static final value in Java.  The other cool thing about it is that you can put any strings behind it, and if you’ve written your code properly, you only make a change in one place and can easily adapt your code to various conditions.  Easy to change, faster, and you’re not doing cut and paste everywhere.  Here is the JavaScript that manipulates the page (tabtoggle.js), with the constant values:

/*------------- CONSTANTS -----------------------*/
//Mode names and values
const DRAMA_MODE = "drama";
const COMEDY_MODE = "comedy";
const THRILLER_MODE = "thriller";
const MYSTERY_MODE = "mystery";
const FANTASY_MODE = "fantasy";
//initial modes
const INIT_MODE = DRAMA_MODE;
// The array of Tabs -- establishes the order
// and values used. Pretty much the whole enchilada right here.
var TAB_ARRAY = [DRAMA_MODE,COMEDY_MODE,THRILLER_MODE,MYSTERY_MODE, FANTASY_MODE];

/*-------------MODEL--------------------------*/
/* This section could be separated from the
above as a "standard" library and used against
any set of tabs or arrays with an identical
structure.*/

//Local constants specific to the model.
const TAB_ID_SUFFIX = "Tab";
const EMPTY_STR = "";
// private Tab class values for CSS
const LAST_TAB_CLASS_VALUE = "last ";
const NON_SLCT_TAB_CLASS_VALUE = "engine";
const SLCT_TAB_CLASS_VALUE = " selected";

/**
 * The Class defining the Mode of the Object
 * @param name - The name of the Tab to that
 * will receive the selected state.
 */
function TabMode(name) {
    //public accessors
    this.name = tabModes(name);
    this.modeId = name + TAB_ID_SUFFIX;

    //change all the tabs, privately.
    function tabModes(name) {
        for (var i = 0; i < TAB_ARRAY.length; i++) {
            var tid = TAB_ARRAY[i];
            var tab = new Tab(tid, (name == tid), (i == (TAB_ARRAY.length - 1)));
            document.getElementById(tab.tabId).className = tab.classVal;
        }
        return name;
    }
}

/**
 * A Tab object with needed attributes.
 * @param id -- mapped to the "id" attribute of the HTML.
 * @param selected -- boolean as to whether or not it
 * is in a "selected" state.
 * @param isLast -- boolean as to whether or not it
 * is the last tab of the series.
 */
function Tab(id, selected, isLast) {
    //accessors
    this.tabId = id + TAB_ID_SUFFIX;
    this.classVal = selectCheck();

    function selectCheck() {
        var cval = NON_SLCT_TAB_CLASS_VALUE;
        if (selected) {
            cval += SLCT_TAB_CLASS_VALUE;
        }
        if (isLast) {
            cval = LAST_TAB_CLASS_VALUE + cval;
        }
        return cval;
    }
}

/*------------- page-accessible methods -----------------------*/

//initialize mode object
var mode;

/**
 * "Public" function to change the name of the tab.
 * Accepts any tabname value mapped to the above constants.
 * @param tabname - a legal value within the TAB_ARRAY.
 */
function changeMode(tabname) {
    mode = new TabMode(tabname);
}

/**
 * Load up the initial mode.  Initializes what is
 * Shown on the page first.
 */
changeMode(INIT_MODE);

Ok, it’s more than 64 lines.  Production versions of this might have the comments stripped and some compression. It currently weighs in at 4k. The constants at the top of the file are:

//Mode names and values
const DRAMA_MODE = "drama";
const COMEDY_MODE = "comedy";
const THRILLER_MODE = "thriller";
const MYSTERY_MODE = "mystery";
const FANTASY_MODE = "fantasy";

These are mapped to the tabs, but the tabs all have a “Tab” string-value appended to it in the “id” attribute.  We’ll use this to manipulate the view elements (usually in CSS) by the “getElementByID” method.  There are two objects that are created in the JavaScript file; one is Tab, and the other is TabMode. 

What I’m doing here — the basics of declaring Objects in JavaScript

To declare an Object in JavaScript, create a function, and for best practices-sake, use an initial capital letter, similar to a Java Class Declaration.  Since we’re not dealing with a pure object-oriented language, we’ll need to declare our Object as a function:

function Tab(id, selected, isLast) {

and

function TabMode(name) {

There’s no constructor method in the class.  The function declaration contains the attributes needed to construct the Object.  Tab take three attributes — the id, a boolean for “selected”, and a boolean for “isLast” to delinieate whether or not it is the last Tab in the sequence.  You can use an Object quite easily, so let’s create some basic FooObject and demonstrate a few things.  Here’s an Object assigned to a variable:

var foo = new FooObject("funky","fruity");

This object instance can now be accessed by using foo.  What are “funky” and “fruity”?  How do we associate these to FooObject?

They have been used in the “constructor” to the Object.  The inner methods of the Object will use this information to populate accessors and can even be injected into private functions.  Let’s take a look at the actual FooObject declaration, and create some basic accessors for it:

function FooObject(smell, taste){
          this.smell = smell;
          this.taste = taste;
}

So, using the foo variable from the earlier listing, foo.smell would return “funky”, and foo.taste returns “fruity”.  Go ahead and try it, it’s just that easy. 

The Tab Object

Now back to the tabtoggle.js code. Besides accessors, I added some private functions to return some values.  The reason I made them private as I didn’t want some hackmeister coming in behind me and using these functions outside of the Object, creeping everything out on my page.  Here is the “Tab” Object code snip for discussion purposes:

function Tab(id, selected, isLast) {
    //accessors
    this.tabId = id + TAB_ID_SUFFIX;
    this.classVal = selectCheck();

    function selectCheck() {
        var cval = NON_SLCT_TAB_CLASS_VALUE;
        if (selected) {
            cval += SLCT_TAB_CLASS_VALUE;
        }
        if (isLast) {
            cval = LAST_TAB_CLASS_VALUE + cval;
        }
        return cval;
    }
}

There are two accessors in the Tab Object, created from the three parameters and some of the “constants” that were declared outside of the class and available to the entire Document. The first accessor is the “id” used for the tab, and the second is used to build a CSS class value to alter the corresponding Tab’s view.  

This second accessor, “classVal”, is interesting because it is mapped to an inner function that determines its actual value.  This function could be mapped externally to the Tab, and I’ve done this before, but after some deliberation, I decided to keep it private because I didn’t want to make it available outside of the Object.

The TabMode Object

The TabMode Object defines the Mode of the each tab.  It takes a “name” parameter that iterates through the TAB_ARRAY (Ordered Array of all Tabs) and creates Tab Objects and sets their class value through the document.getElementById() method.  I “cheated” a little here by calling this method while I set the Tab instances-  mainly to ensure that the iteration was complete (it would throw errors at this point if there is a failure).  I highlighted in red the real work that’s getting done.

/**
 * The Class defining the Mode of he Object
 * @param name - The name of the Tab to that
 * will receive the selected state.
 */
function TabMode(name) {
    //public accessors
    this.name = tabModes(name);
    this.modeId = name + TAB_ID_SUFFIX;

    //change all the tabs, privately.
    function tabModes(name) {
        for (var i = 0; i < TAB_ARRAY.length; i++) {
            var tid = TAB_ARRAY[i];
            var tab = new Tab(tid, (name == tid), (i == (TAB_ARRAY.length - 1)));
            document.getElementById(tab.tabId).className = tab.classVal;
        }
        return name;
    }
}

Everything will work now. Go ahead and open up the HTML page and click on the tabs.  We have a very nice and snappy set of tabs with only a little bit of code.  We can change the code in different ways to make it more useful.  In the next two sections, I’ll demonstrate how to use the basic JavaScript file that we’ve already defined against a completely different set of tabs with minimal code change, and then in the last section I’ll add more functionality to show/hide different information boxes when a particular tab is clicked.

Using the Same Basic Code to Populate Different Tabbed Pages

code reference – version_2_tabs.zip

We’re now going to take the code that we just wrote, create another HTML page with the same functionality but completely different tabs using the same structure, only changing the “name” constants and the “array” that they are located in.

The only big change is to separate “Page Attributes” that define a particular page for the “Model” part of the JavaScript Code.  There is no real dependency between them, and as long as there are “names” and an “array” to traverse, the tabs will pretty much work as designed against anything you want.  This allows for any number of different tabs or tab names to be used — you just attach a new file with the constants you want to use for the page, and plug in the same JavaScript Toggle Model.  For this particular exercise, we created a file that only holds the constants that we want to use for the first “tabpage1.html”.

const DRAMA_MODE = "drama";
const COMEDY_MODE = "comedy";
const THRILLER_MODE = "thriller";
const MYSTERY_MODE = "mystery";
const FANTASY_MODE = "fantasy";
//initial modes
const INIT_MODE = DRAMA_MODE;
// The array of Tabs -- establishes the order
// and values used. Pretty much the whole enchilada right here.
var TAB_ARRAY = [DRAMA_MODE,COMEDY_MODE,THRILLER_MODE,
                 MYSTERY_MODE, FANTASY_MODE];

// private Tab class values for CSS
const LAST_TAB_CLASS_VALUE = "last ";
const NON_SLCT_TAB_CLASS_VALUE = "engine";
const SLCT_TAB_CLASS_VALUE = " selected";

No structural code changes were made. I just “cut” the script from the first section in two, putting the constants that are mutable away from all of the code that doesn’t need to change.  If we want to create a different page, we’ll be able to use the exact same “model” code and only change the code in the listing above to suit our needs.  The Model part of the code is still located in the “tabtoggle.js” file. 

Since there’s no change, I’ve truncated the listing below only to provide clarity as to where the “split” occurs.  refer to the version_2_tabs.zip for more granularity.

/*-------------MODEL--------------------------*/

//Local constants specific to the model.
const TAB_ID_SUFFIX = "Tab";
const EMPTY_STR = "";

function TabMode(name) {
  ... (no changes to code -- see details in zipped download)
}

function Tab(id, selected, isLast) {

... (no changes to code -- see details in zipped download)}

/*-------- page-accessible methods -----------*/

//initialize mode object
var mode;

function changeMode(tabname) {
    mode = new TabMode(tabname);
}

changeMode(INIT_MODE);

Again, no changes. We’ve left the “model” part of the code at the bottom of the page to load just before the </body> tag, and the “Page Attributes” are coded to load in the <head> of the document.  Other than that, the HTML is unchanged in the “tabpage1.html”.  The tabs will work and fire identically as they did before.

But now, we get to do something cool.  We create a new HTML file, “tabpage2.html”, and put completely different tab names in them.  Not only are they different names, they are even more of them!  The underlying model code will handle them perfectly, as all it cares about is the array mapped to the constant names.  The array provides the order and a looping mechanism, and the constants provide a way to change things without making changes all over the place.

The new HTML code contains different cartoon shows or characters mapped to the same html pattern as “tabpage1.html”.  Here is the new table with the tabs.  Changes are in red:

</head>
<body>
<table class="tabToggle" cellspacing="0">
    <tr>
        <td><span class="selectstring">Select Category</span></td>
        <td id="bullwinkleTab">
            <div><a class="tab_0" href="#" onclick="changeMode(BULLWINKLE_MODE);return false;">
                <span>Bullwinkle</span></a></div>
        </td>
        <td id="tomandjerryTab">
            <div><a class="tab_1" href="#" onclick="changeMode(TOM_AND_JERRY_MODE);return false;">
                <span>Tom and Jerry</span></a></div>
        </td>
        <td id="simpsonsTab">
            <div><a class="tab_2" href="#" onclick="changeMode(SIMPSONS_MODE);return false;">
                <span>Simpsons</span></a></div>
        </td>
        <td id="futuramaTab">
            <div><a class="tab_3" href="#" onclick="changeMode(FUTURAMA_MODE);return false;">
                <span>Futurama</span></a></div>
        </td>
        <td id="bugsbunnyTab">
            <div><a class="tab_4" href="#" onclick="changeMode(BUGSBUNNY_MODE);return false;">
                <span>Bugs Bunny</span></a></div>
        </td>
        <td id="mickeymouseTab">
            <div><a class="tab_5" href="#" onclick="changeMode(MICKEYMOUSE_MODE);return false;">
                <span>Mickey Mouse</span></a></div>
        </td>
        <td id="barneybearTab">
            <div><a class="tab_6" href="#" onclick="changeMode(BARNEYBEAR_MODE);return false;">
                <span>Barney Bear</span></a></div>
        </td>
        <td id="ScoobyDooTab">
            <div><a class="tab_7" href="#" onclick="changeMode(SCOOBYDOO_MODE);return false;">
                <span>Scooby Doo</span></a></div>
        </td>
    </tr>
</table>
<script type="text/javascript" src="tabtoggle.js"></script>
</body>
</html>

Note the script reference at the bottom of the page.  It only contains the “Model” code.  The new “Page Attributes” are shown below, contained in the file tabpage2.js.  New code is in red.  Although there is some “cut and paste” code in here, it’s because we might want to change the class names of the tabs to vary the view, and this would be the best place to keep it.:

/*
 * Copyright (c) 2008, Your Corporation. All Rights Reserved.
 */
/*------------- CONSTANTS -----------------------*/
//Mode names and values
const BULLWINKLE_MODE = "bullwinkle";
const TOM_AND_JERRY_MODE = "tomandjerry";
const SIMPSONS_MODE = "simpsons";
const FUTURAMA_MODE = "futurama";
const BUGSBUNNY_MODE = "bugsbunny";
const MICKEYMOUSE_MODE = "mickeymouse";
const BARNEYBEAR_MODE = "barneybear";
const SCOOBYDOO_MODE = "ScoobyDoo";
//initial modes
const INIT_MODE = BULLWINKLE_MODE;
// The array of Tabs -- establishes the order
// and values used. Pretty much the whole enchilada right here.
var TAB_ARRAY = [BULLWINKLE_MODE,
    TOM_AND_JERRY_MODE,SIMPSONS_MODE,FUTURAMA_MODE,
    BUGSBUNNY_MODE,MICKEYMOUSE_MODE,BARNEYBEAR_MODE,
    SCOOBYDOO_MODE];

// private Tab class values for CSS
const LAST_TAB_CLASS_VALUE = "last ";
const NON_SLCT_TAB_CLASS_VALUE = "engine";
const SLCT_TAB_CLASS_VALUE = " selected";

When you load the the “tabpage2.html” in the browser, the new tabs will appear, with new names, more of them, but with exactly the same functionality. The underlying model works just as it did with the tabs on the other page, with only the inputs changed. You could put the inputs on the page or load it into a file that is picked up by the page as we did here  I believe either is fine – your decision where to put them is based upon your requirements and judgement.  No wrong answers!

Adding A Content Box Below the Tabs

code reference — version_3_tabs.zip

Finally, we get a requirement to load a different but corresponding content box to the tabs we have created.  Let’s also say that our requirement states that only some of the tabs will have variable content boxes, other functionality may be required elsewhere.  We want to add a content show-hide feature to the boxes, yet make sure that any tabbed page using our code doesn’t throw errors, as we just hate that.   The style attribute we will chose is “visiblity“, and we’ll use the “none” and “inline” values — since “none” will take the object out of formatting and not affect the flow of the page. “inline” will put the box in the flow. To change the style attribute trigger, we’ll use:

document.getElementById("foo").style.display = ...

It is necessary to loop through all of the tabs whenever the page mode is changed to make sure that the right one is “turned on” and the others are invisible.  Arriving at this functionality is actually quite easy.  We’ll just add this to the existing private function in the TabMode Object.

A new HTML page is similar to the others we’ve created, with the changes added in the listing below (changes in red, surrounded by existing code for reference).  The “outer” div for each box is what controls the visibility, the “inner” div with the class attribute “underbox” is for decorating the view, and has the class value mapped into the css file to control it.  Each “id” attribute in the “outer” box maps to a tab “name” attribute, the “Box” is the suffix for this id and is used within the JavaScript code, e.g. dramaBox, comedyBox, etc.

       <td id="fantasyTab">
            <div><a class="tab_4" href="#" onclick="changeMode(FANTASY_MODE);return false;">
                <span>Fantasy</span></a></div>
        </td>
    </tr>
</table>
<!-- Add a Box! -->
<div id="dramaBox">
    <div class="underbox">
        <h2>Drama</h2>
        Lorem ipsum dolor sit amet,...
        zzril delenit augue duis dolore te feugait
        nulla facilisi.
    </div>
</div>
<div id="comedyBox">
    <div class="underbox">
        <h2>Comedy</h2>
        Darkness washed over the Dude, darker than a steer's
        tukus on a moonless night.
    </div>
</div>
<div id="thrillerBox">
    <div class="underbox">
        <h2>Thriller</h2>
        ... So I made a decision, and it
        was... wrong. It was a bad call, Ripley. It was a bad call..
    </div>
</div>
<div id="mysteryBox">
    <div class="underbox">
        <h2>Mystery</h2>
        Some text here
    </div>
</div>
<div id="fantasyBox">
    <div class="underbox">
        <h2>Fantasy</h2>
        Some text here...
    </div>
</div>
<script type="text/javascript" src="tabtoggle.js"></script>
</body>
</html>

Here is the code for the enhanced tabs in the file tabtoggle.js. The only change needed is to add a few constants and a small conditional routine in the TabMode Object.  It will actually detect if the boxes are present to toggle their visibility, otherwise this functionality is ignored. The changed code is in red.

const BOX_ID_SUFFIX = "Box";
//Display box values
const YES_DISPLAY = "inline";
const NO_DISPLAY = "none";

/**
 * The Class defining the Mode of he Object. Alters the tab Selected,
 * and also changes which box should be displayed under it, IF a box exists.
 * @param name - The name of the Tab to that
 * will receive the selected state.
 */
function TabMode(name) {
    //public accessors
    this.name = tabModes(name);
    this.modeId = name + TAB_ID_SUFFIX;

    //change all the tabs, privately.
    function tabModes(name) {
        for (var i = 0; i < TAB_ARRAY.length; i++) {
            var tid = TAB_ARRAY[i];
            var tab = new Tab(tid, (name == tid), (i == (TAB_ARRAY.length - 1)));
            document.getElementById(tab.tabId).className = tab.classVal;
        }
        //This changes out the boxes, if they exist...
        if (document.getElementById(name + BOX_ID_SUFFIX) != null) {
            for (var i = 0; i < TAB_ARRAY.length; i++) {
                var tid = TAB_ARRAY[i];
                if (tid == name) {
      document.getElementById(tid+ BOX_ID_SUFFIX).style.display = YES_DISPLAY;
                } else {
      document.getElementById(tid+ BOX_ID_SUFFIX).style.display = NO_DISPLAY;
                }
            }
        }
        return name;
    }
}

The code above will now allow the choosing of each tab and the display of different boxes below. Not only that, but when applied to our second, “cartoon tabs”, page, no errors will be thrown since there is a “check” as to whether the boxes exist first.  If you want to add boxes to the other page, you just map them to their tab names and use the “Box” instead of “Tab” suffix!

Conclusions:

Using the JavaScript Prototype element can extend the above code in even more directions.  Want to have a form connected to each tab?  Do they have different elements?  You can enable and disable them by extending the above classes to do even more.  A “TabbedForm” class could contain the form elements and keep track of what to enable and disable, different submission urls or even more.  You don’t have to alter the base class, you just extend it using the Prototype Element.

One of the truly wonderful things about JavaScript is the fact that there are many ways to the same result.  What I find interesting is how people can come up with ideas to make their scripts smaller, more re-usable and extendable.  Creating Objects in JavaScript allow for power that many mark-up engineers don’t know about to this day;  a lot of server-side programmers, myself included, begin to take this client side language seriously and realize the power, and fun, of writing this type of code.

Predictable Schedules Create Outstanding Teams

When many eCommerce shops first set up, there are usually a few developers wearing many hats; they have access to everything, develop within specific areas and channels, and check in code for deployment as it becomes ready. While this type of development will work as a business starts, it will soon become unmanageable and will result undesired consequences as changes are not integrated, and business priorities are not addressed, or worse.

Predictability and easily enforced processes set all stakeholders within an application free to do their jobs and collaborate at the highest levels possible. With a strong process, planned changes will be scheduled for deployment with a high degree of accuracy. Engineers enjoy complete and accurate requirements, and know what is expected of them throughout each cycle. Quality Assurance will have time to create plans and fully test changes, and Releases to Production will no longer be a nail-biting, all-hands-on-deck stress-fest.

The following proposed process details the steps necessary for day-to-day development, maintenance and enhancements for the IHO/Offer Channels applications. They are exclusive of longer-term enhancements and development requiring multiple-week pulls. Only those issues that may be completed in short periods will applies here,. This is significant because with most mature applications, nearly 75% of all issues encompass this type of development.

Tracking the status of Issues

An Issue Tracking System is a “blog-like” application that allows issues to be tracked throughout the development/release cycle. Its main features include fields to track:

• Who the Business Stakeholder is for the issue (i.e. owner)
• Who has responsibility for the Issue’s forward progress at a point in time
• The Scheduled Release Date
• An identifier for the issue so that communication may occur around it
• A field to delinieate the Issue’s status
• Attachments to the Issue for requirements or any information needed to proceed in the process
• A “Comments” section that allows all stakeholders to create a chronological and permanent record of what happened to the issue over its lifecycle

Other features of a robust issue tracking system are excellent aggregation and reporting tools, integration with Wiki pages, email notifications and IDE integration. The tool chosen by many, and arguably a “best of breed” is “JIRA” from Atlassian Software.

Assumptions

Many, if not most, of the web applications built in an enterprise are ongoing products that require maintenance, small tweaks and enhancements on an ongoing basis. While larger changes to the system occur on a much more infrequent basis, it is essential that these be separated out into a different schedule and allow for the ongoing implementations to occur on a regular schedule that has no dependencies upon larger, more complex deployments.

There are several assumptions that must be made to completely embrace the Overlapping Schedule Model fully:

1. There will always be more issues and tweaks needed than resources available
2. A method for communicating issues between all stakeholders exists
3. There is a need for predictability and pacing
4. While not perfect, the application has some stability

The Overlapping Schedule Model

An Overlapping Schedule is a very efficient model to keep the all business process stakeholders fully engaged, collaborative and running at peak efficiency. It uses tight structure to coordinate activities in three separate areas, Business, Development, and Release/QA. While Business Stakeholders are planning future releases, the Engineering Team is developing the next release, and the QA and Release Management is readying/deploying the current release for production.

Figure 1 shows the basic development cycle and it’s overlapping steps, creating a never-ending, continuous process that keeps all resources utilized at maximum efficiency:

Main stakeholder activities in the Overlapping Schedule Model.

The Details of the Process

Collaboration exists at various points between all stakeholder groups to allow for seamless transitions and predictable behaviors. Issues planned for release will be vetted between Business and Engineering for resourcing purposes, Developers will interface with Business to demonstrate functionality, and Engineers, Business and QA will collaborate with Release Management in the “Go-No-Go” process gate as final release is set (other collaborations are spelled out in the details below).

An Issue planned in one week will be released on the second Thursday following. Metrics can be attached to every step in the process. Everyone knows what to do and when to do it, and communication between the disparate groups are formalized and clarified. The entire process becomes engrained within the fabric of the company. The team implementing it becomes responsible for the continuous and uninterrupted revenue operations of the application. This “Profit Team” process is outlined:

Single Cycle Process Flow for Overlapping Schedule Model

The Steps

Starting at the End – Release

Time: Thursday, 2pm

Release is scheduled for Thursday at 2pm. This is no arbitrary time. Releases should never occur on Fridays or Mondays because there is no time for Go-No-Go meetings or mitigation in the event of emergencies. Tuesdays and Wednesdays are also out because of the need to QA all issues thoroughly, and this has to happen through unbroken week and not broken up by a weekend. (Mon-Fri).

Thursday becomes the release day by elimination.  It is impossible to release first thing in the morning (the Go-No-Go meeting must occur first), and time must be made for a “burn in” period after release to production. This means that after lunch is the best time, but since preparation must occur immediately before the release, so it can’t be done before lunch  (e.g.Thursday, 2pm).”

The Release of the current, tested and accepted code signifies the very end of the process and the beginning of a new one, so this point is a perfect place to point out the criteria for starting the next cycle — this occurs when new enhancements have been identified and a decision has been made to move them forward into production.

These identified issues are only in their basic state. They have no prioritization. All of their requirements may not be complete, and the majority certainly haven’t been resourced. They are probably known only to the business stakeholders and have no release date.

Adding New Enhancements/Maintenance to the Issue Tracker

Time: Thursday Morning – Friday Morning

Identified Issues are entered into the Issue Tracking System with their status marked as “Prioritization”. Once all the issues are added to the Tracking system, the process can move forward. At this point, the business stakeholders are still the only group actively involved in the process.

Add Supporting Docs

Time: Thursday Morning – Friday Morning
With all the issues in the Tracking System, any supporting documentation that is available at this point is added to the corresponding issue, along with any commentary that will give the prioritization committee enough information to put the issues in the right order for development and eventual release.

Prioritization – The First Big Step

Time: Friday Noon
Lunch is served as Business Stakeholders engage to prioritize the issues in the system for eventual deployment. Still only a Business Stakeholder exercise, the process is now setting up to collaborate with the rest of the stakeholders. Issues are prioritized and prepared to meet the Development Managers for mapping to resources.

Meet the Engineers – Dev/Resource Alignment Meeting

Time: Friday Afternoon
The Program Coordinator for the business generates a report containing all issues prioritized for the next release. Their status at this time should be marked as “Requirements” in the Issue Tracker. The Coordinator and Development Manager(s) should be prepared meet and map each issue to Engineering Resources for Implementation. The Program Coordinator will go through each issue with the Manager(s), and the Managers will assign a resource to each issue. At this point a “contract” is being made between the Business and Development groups, spelling out just what can and will be done for the next release cycle.

It is the Development Manager’s responsibility to carefully look at each Issue and ensure that most, if not all requirements are complete and formatted for maximum understanding with respect to the assigned engineer. All gaps must be pointed out and recorded against each issue for its corresponding business owner’s follow-up.

It is also possible that the prioritized issues may lack the development resources necessary to for completion within the next release cycle (developers may be unavailable, an emergency may have supplanted resources, etc.). When this occurs, they will be re-prioritized and sent back into the queue for the next week. A team can only do so much, and creating situations requiring extraordinary effort will “raise the bar” and eventually burn out the team. Consistency is critical, and this step is the decision gate to ensure that all follow-on processes go smoothly.

Once all issues have been mapped to resources and the Business-to-Development hand-off is complete, all issues that are to be worked on are marked “Ready for Development”.

Finalize Requirements

Time: Friday Afternoon – Monday Morning
At this point, there is an “Engineering Perspective” to the issues. The Program Coordinator has the opportunity to work with the stakeholders of the individual issues and update any requirements and answer any questions that have arisen from the Dev/Resource Alignment meeting. The stakeholders can have some informal contact with their assigned engineer, and set up stakeholder – engineer/developer meeting, also known as a JAD session.

Dev/Biz JAD session – Is This What You Want?

Time: Monday 11am

As soon as possible on the Monday morning of the Development week, the Business Stakeholder and any other interested parties should meet with the assigned developer of the Issue to have an overview of what is to be built and positively identify every unclear detail surrounding it’s development. This is called a Joint Application Design/Developemnt (JAD) session.

The JAD process does for computer systems development what Henry Ford did for the manufacture of automobiles (a method of organizing machinery, materials, and labor so that a car could be put together much faster and cheaper than ever before – the assembly line). The goal in systems development is to identify what the users really need and then set up a system or process that will provide it. Traditional methods have several built-in delay factors that get worse as more people become involved. JAD cures this by addressing four simple assumptions:

• People who actually do a job have the best understanding of that job.
• People who are trained in information technology have the best understanding of the possibilities of that technology.
• Information systems and business processes rarely exist in isolation — they transcend the confines of any single system or office and affect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
• The best information systems are designed when all of these groups work together on a project as equal partners.

The outcome of the JAD session should show in evidence:
   

• Definition of the Issue to the satisfaction of both parties.
• Understanding and translation of all requirements
• Obtained approval from all parties with respect to the forward development of the issue.
• Surety that all decisions and changes are reflected in the Issue Tracker.
• An Agreed upon time for demonstration before the code is checked in for QA

With the completion of this step, the Issue is marked “In Development”.

For more information on a JAD session, consult http://www.umsl.edu/~sauterv/analysis/JAD.html.

Development – Where the Rubber Meets the Road

Time: Monday 11am – Friday 12pm

The Developer will now build what has been set forth in the Issue Tracker and based upon the learnings from the JAD session. If any problems or roadblocks occur, they should log the problem clearly in the Issue Tracker, mark the Issue “Development Problem”, and notify their Manager and the Stakeholder for the Issue.

Development on the issue can continue until the Code Freeze/Check-in time of Friday, 12pm. Any Issues being worked on after that point are at risk for being pushed off to another cycle, and will need to be addressed by stakeholders.

As necessary, a demonstration should take place based upon a time set up in the JAD session. This demonstration should answer the question “is this what you asked me to build?” It is important to have some time left in the Development Week to make any last minute corrections to the implementation.

During the Development Cycle, the QA team will be pulling the Issues that are to be tested from the Reporting System of the Issue Tracker, and setting up their tests. They may be asking any Stakeholders questions based upon the testing needs of the particular issue.

Ready For QA Code Check-in

Time: Friday 12pm

All code is checked into the Source Control System at the Friday deadline. The Release manager will merge the newly developed code into QA Branch. The QA team will begin reviewing issues to set up tests and begin next week’s three-day testing cycle.

Developers will prepare next for the next Development Week. All checked in Issues status is set <em>“Ready for QA”</em> at time of check in.

It is important to check development code in when finished and not wait till the last minute to prevent collisions, over-writing of code and any last minute problems that can surround more than one person trying to check in the same file(s). Check in soon and often should be a mantra.

Sandbox Demo to Business

Time: Friday Afternoon

Developers demonstrate changes to Business Stakeholders on an “as needed basis” . All Business Stakeholders sign off on their particular issues and agree that QA can take over and start testing. This is the Final gate check for Development. Issue Tracker Status is marked <em>“QA”</em> by QA personnel.

Dev/QA process "swim lanes" - blended colors represent collaborations. click to enlarge.

QA Complete, Final Business Check

Time: Wednesday afternoon
The business stakeholder will view the corresponding implementations to their issues served from the QA machines. Any final defects may be addressed, or the Issue may be delayed for another cycle.
If all is ok, the Issue Tracker Status for QA complete is “Ready for Production”. Business has final say. 

Move Code to Head/Staging

Time: Wednesday 4pm
Release manager will take all issues marked “Ready for Production” and merge to the Production Staging Branch. If Staging exists, it is set to staging for final demonstrations, review and any business collaborations on an as-needed basis (sometimes there are outside dependencies that may need to have a “production-level” deployment to expose any final issues, or be observed by external stakeholders. This is the place to do this.

Last Minute Gut Check

Time: Thursday Morning
Final Business reviews. Go-No-Go meeting. Any last minute issues are addressed before launch. Afternoon begins with ITOPS/Release Coordination for Production and launch.

Release – OK, Let’s start at the top!

Time: Thursday, 2pm
Code is launched to production. The deployment must be watched throughout the afternoon for any production/emergency issues. Business stakeholders should review their changes on production sites. Any outside communication with external stakeholders is handled. Issues marked “Production” in Issue Tracker. Issues from previous week marked “Production” are now marked “Closed”.

The Three P Method: P1, P2, P3.

Below is an industry-standard practice of prioritizing issues with respect to their urgency. They are categorized as P1 – P3, the most urgent being P1. Each has impact to issues that are “already” in the queue for development, which must be taken under consideration.

• P1 — when a fix is needed to affect a serious break that will affect the company legally, morally, or for revenue impact over a set value (usually 50k or so). Everything is dropped and a release to production is done ASAP, outside of the schedule. Depending upon the impact, an upcoming release may be delayed for a week or certain issues may not be completed for the next scheduled release. A post-mortem is required to decide what the effect to the normal schedule is.A P1 fix usually requires a VP for “go-forward” approval. Often a meeting of stakeholders must occur to gather information with respect to impact and fixes.
• P2 — when a fix is needed to affect a break within the system. In this scenario, the break is fixed for the very next scheduled release — other issues being worked on may be affected, but no special release is done. Only in the rarest of cases is a Post-Mortem needed. Needs Director-level approval.
• P3 — anything within the normal schedule. Planned for one week, developed for a week, QA’d and released the following week.

The Overlapping Schedule Model Process within the Issue Tracker

The JIRA issue tracking system aligns workflow with Issues to allow for clean and simple end-to-end tracking of issues aligned closely to physical business processes. It employs a “status-transition” method to follow the process. Each “status” may have various “transitions” that allow for different scenarios. By clicking on a particular transition, the workflow will change to a corresponding status, and the path chosen will be reflected in the next available transitions available to the JIRA User.

The Diagram below shows the workflow available to the Team using JIRA and implementing the Overlapping Schedule Model. The workflow has been mapped out and attached to the Schemes available to the IHO. This model can be used or extended for other development channels. Note various paths that do not take a particular Issue into production, and other paths that have various conditions that must be satisfied to move forward. The “straightest” path to production is indicated by bold blue lines, showing the transitions and their corresponding status indicators.

Overlapping Schedule Model Workflow. click to enlarge