It has been quite a while since I did any hardcore coding. Since that time, I have dabbled in various web projects, but programmers who don’t practice tend to get stuck in ruts. Most of the time, I would use my skills to solve small problems using methods and technologies I knew worked. If you want examples of that, go check out Brando Labs. Why do I continually pull tools like Perl, PHP, sed, Bash, and Python out to solve problems? Because I know how they work, and the learning curve to get back into the swing of things is relatively shallow.

Hands on: "MacBook Air"

Hands on: “MacBook Air”

Back in the Stone days, I ended up taking a week long Java class that had me coding in JSP and servlets for a time. Object Oriented Programming was a struggle for me. I was taught Top-down procedural programming starting in Pascal & C/C++, but it took this class to get the object thing to click. I am bringing this up because I have decided to re-visit a technology I saw in its 1.0 iteration, Rails. Or more specifically, Ruby on Rails.

WOW it has come a long way since 2005!

In the last eight years, it seems to have become the standard for rapid web development. After completing the fabulous tutorial by Michael Hartl, I’m recognizing the constructs everywhere (especially with the Twitter Bootstrap paintbrush). But that’s not the point of this post. There were two things very interesting to me that I observed in the Hartl tutorial that I hope will trickle down into other development courses. Maybe I’ve never been exposed to them because I’ve been out of the professional dev world for so long, or maybe it’s just a fluke, but I think both of these will go a long way to improving the quality and security of software for the developers who follow them.

The first observation was the discussion of security in application code. In a number of instances, Michael specifically calls out tweaks to a rails configuration and the specific code to promote a secure application. He even takes it a step further and makes the faithful reader perform several exercises to promote security. I hope this pushes itself down into the colleges and schools that offer courses on development. Thinking about secure development starts from the first printf(“Hello world.”).

The second observation was the notion of Test-Driven Development (TDD). In nearly all of my development experience, we rushed to get functionality out the door and hastily tested it, passing the builds along to another group to test and tell us what we missed. This is a horribly broken way to build software and requires excess manual effort to complete the testing process which gets more complex with every build. Repeatedly testing the same things over and over again gets monotonous and human nature all but guarantees mistakes.

Patched Tube, by Morten Liebach

Patched Tube, by Morten Liebach

In TDD, you write the test before you write the code. It sounds strange, and seems counter intuitive to every fiber in our body that says “STAY PRODUCTIVE,” but it’s one of those long term benefits that pays massive dividends as your application gets bigger and crazier. For example, let’s say you have an application that has users, but you want to add blog items (or microposts in Michael’s tutorial), you first write a test to see if the blog table exists with all the properties you would expect it to have. You run your tests, they fail of course, and then you write the code to make the tests pass (thus adding the functionality you are looking for in the first place!). Now, every time you run your larger application tests, this test will run and you will quickly learn if you break something that makes part or all of your functionality disappear. The same thing goes for displaying information. Write a test to see if the information is displayed (it will fail), then add code to make that test pass.

So while this may be old hat to some of you out there, I found it interesting enough to pass it along to the larger audience. There are tremendous implicaitions for PCI DSS related applications in using both of these methods. Building security tests in will ensure that you don’t introduce bugs that disclose payment card data, logins, or introduce SQL injection vulnerabilities. Going back and building these tests can be a pain, but it’s already a big part of the technical debt your application is carrying. Consider this preventative work—or good work to prioritize in the system even if it causes new features to be pushed down the road.

This post originally appeared on BrandenWilliams.com.

Possibly Related Posts:


Tagged with: , ,

0