Web Applications

Developing web applications is difficult and chaotic without strict process and enforcement. Through many trials and tribulations, Ruby Skills has carved out a process from which successful web applications are implemented on target.

Prototyping

It is essential to define and capture the requirements of a project before and during development. To engage in the initial thought process, micro meetings are set with the project manager and our customers to establish the initial scope. Just as if you were creating a model of a building before you built it, the project manager and customer will work together to create a prototype of what is desired. The specifics are left out, but the bigger picture is established, and goals can be set.

Agile Development

Defining iterations for release on a weekly interval allows for quick feedback loops during development and have proven to be wildly successful at delivering the intended result quickly. From experience, trying to clarify every specification up front will run you into problems in the future. Isolating a small, manageable portion of the specification to complete on an iterative basis produces results far better and will leave room for the changes that inevitably come up as the project scope is fully realized during development. After iterations are completed, decisions can be made quickly to problems that arise.

Pair programming is also a practice of agile development followed religiously on teams at Ruby Skills. Having a second pair of eyes spot checking and planning the code that is written actually increases productivity significantly and brings a whole new level of communication amongst the team. As the old saying goes, two brains are better than one.

Test Driven Development

After specifications are set, it's time to program. In traditional development shops, the programmer would sit and program the specification in whatever programming language they knew and pieced functionality together based on their experience with solving problems in that language. As the project scope continues to get bigger and bigger, the code gets more complex and functionality that once worked, is now broken. All of a sudden a QA team is required and tests are getting written. This process is inefficient and time consuming.

Test Driven Development is a completely different approach. Rather than testing after the code has been written, the test is written first. Here is a very simple example:

Say you want to create a sum function that takes two parameters (1 and 2) and adds them together. Writing the test first as a specification clarifies the intent of the code that needs to be written:

sum(1, 2).should == 3

Now code is written to make this test pass. As long as this test passes, one can be sure that the intent of the code is functioning as it should. This also allows the programmer breathing room for refactoring if necessary. This test should still pass even if the underlying code is different. Test Driven Development practices improve code quality dramatically and act as a deterrent from future bugs.

Continuous Integration

As specifications get broader, and more tests are written, projects start to accumulate a large test suite. In order to ensure that the code developers write is doing what it was intended to do, a continuous integration server must be setup. The role of this server is to run the entire suite after a developer has contributed code to the version control system. If any tests fail, all of the developers on the team are emailed right away. The developer that contributed the faulty code will then be responsible for fixing the problem and contributing a new release. This keeps everyone on the team honest and constantly thinking about code quality.

Deployment

At least two environments need to be established before the application can see the light of day. A production environment where the application will be accessed from the outside world, and a staging environment which closely mirrors that production environment. This process allows you to anticipate problems that may occur after the application is deployed to the Internet. When it is verified that the staging environment is acting as intended, the code is then deployed to production.

Utilization of automated tools makes deployment a snap. Once configured, the deployment process is automated and the latest code can be sent to the staging or production environment. Versions can even be rolled back!