Archive

Archive for July, 2009

XP-Dev.com : Free Subversion Hosting & Project Tracking

July 31st, 2009 josh.tucholski 3 comments

xp-dev A few months ago I started working on a new home project that I wanted to keep under source control. My only requirement was that it be closed-source as I wasn’t ready to share my idea with the world yet. I am cheap, and I decided to look for a free alternative first before I decided to pay someone. I stumbled upon XP-Dev.com.

What I get with XP-Dev Free:

  • Subversion Hosting up to 500 MB
  • Unlimited number of Projects
  • Wiki Pages
  • Blogs & Forums

XP-Dev.com has only suffered one outage since I’ve been with them, and the owner of the site was very vocal with what the status was for getting back online.  For any new projects that you are working on, or if you want to have something under version control, I definitely suggest using XP-Dev.com.

Categories: Shout Out Tags:

Are You Writing Baby Proof Software?

July 27th, 2009 Josh No comments

The other day while eating lunch the topic of newborns came up. We discussed that when parents prepared for a newborn to enter their home, they gave their best effort to ensure that the home was “baby proof”. Outlets were covered, stairway gates were in place, and cabinets locked to stop the little one from getting into trouble with anything in reach. Now they look back as their children become mobile, and say a whole new can of worms is opened. Cabinets are not locked to protect what is inside. They are locked to prevent them being turned into steps to get other items originally out of reach.

christmas-tree

Baby proofing your home serves as a solid analogy to writing software. As much as we wish it were not true, we unintentionally write buggy software. If you are lucky, the bugs are never found once the software goes out the door. Try as much as you wish to hide the errors and gracefully recover, there is always some way to work around the system. Users are just like babies in that they just putter around in the application trying different things until they find what works. They may not be expect to find these issues, but once they find them, watch out because they’ll remember how to get back and exploit what you hoped was "safe software". The Twilight Hack for example allowed Wii users to exploit a buffer overflow just by changing the name of the character’s horse.

It is very difficult to try and prevent this seeing how you cannot really tell exactly what you are looking for. Keep in mind though that software development is a lot more forgiving than raising a child. You cannot run usability tests in your house to see how safe it is. The only solution that I have to getting around this is to draw from past experiences. Focus on thorough testing and make sure past issues are no longer a problem.

Below is a refresher on the types of software testing that most products should undergo:

  • Unit Testing – validate that individual units of your code work for a given input and expected output. Never rely on external factors to write your unit tests (e.g. Database Engine having correct data and up to date)
  • Integration Testing – ensure that you are clear of your expectations and what you expect when working in multiple distributed environments or systems
  • Performance/Load Testing – you will want to try and avoid being surprised when you get a call on Cyber Monday telling you that your site is offline due to heavy load
  • Usability Testing – before you go live, do some testing on your application to make sure that you see how well subjects can perform tasks and respond to errors
  • Regression Testing – remember that feature that you added in last month’s release? Yeah well now the user cannot update their profile ever since then. Regression test to ensure that updates you make do not cause existing functionality to break.
  • Security Testing – is your software capable of SQL Injection? Do you follow correct authorization rules for your users and does your data retain its integrity?
Categories: Testing Tags:

Five Steps to Making Fellow Developers Miserable

July 23rd, 2009 Josh No comments

1. Long Method

Short methods specific to single units are bad. Try to limit the number of methods in each class. This will ensure that each method is as long as possible.

Workaround: In order to prevent long method from happening, I recommend limiting the length of your functions to 30 lines or less (40 including exceptions).  Focus on keeping your functions less then one screen’s length.  Try bumping up the font-size of your IDE so that a lot less code fits on the screen.

2. Out of Sync Comments

Just like you learned in college, comments are the best form of documentation. Comment blocks are better. Provide details about every line of code and include pre-conditions, post-conditions, and expected exceptions. Comments are important because they help other developers calling the code understand how it works.

/// <summary>

/// Saves data into database

/// </summary>

/// <remarks>

/// Save Data opens up a SqlCommand object and calls the

/// sp_SaveUsers stored procedure to save a user object.

/// </remarks>

/// <preconditions>

/// User object must be created. sp_SaveUsers must exist in SQL server

/// </preconditions>

public void SaveData()

{

//Get Connection String

string connectionString;

SqlConnection connection = new SqlConnection(connectionString);

//Open Connection

connection.Open();

//Create Sql Command call “sp_SaveUsers”

SqlCommand cmd = new SqlCommand();

cmd.Connection = connection;

cmd.CommandText = “INSERT INTO USERS (userId, userName) VALUES (?,?)”;

cmd.CommandType = System.Data.CommandType.TableDirect;

//Add Parameters for Stored Proc

cmd.Parameters.Add(u.ID);

cmd.Parameters.Add(u.Name);

//Execute Command

cmd.ExecuteNonQuery();

//Close connection

connection.Close();

}

Workaround: If you are going to write comments, specify the problem that your code solves, not how it solves it. Think of the last time you picked up a book at the store and read the back. Would you have wanted it to tell you what the story is about, or how the plot is laid out? If you change the implementation (bug, refactor, etc.), the comments can remain the same. Try and get away from code commenting all together by writing self-documenting code. For examples read Jeff Atwood’s Coding Without Comments.

3. Bloated Class

Enforce a limit to the number of classes allowed in the codebase. To reinforce this, place all logic into one big blob class.  With this class you are the ultimate tool that can do anything. The more classes you have, the more source files you maintain. More source files increase the compile time of your project.

Blob Class

Workaround: Follow the Single Responsibility Principle (SRP) to keep the implementation of your class specific to its’ purpose. Classes should only have one reason to change, and no other components of that class should be affected during that change.

4. Classes that are “involved”

The more that each class knows and relies on another class, the better your code is as a single unit. New developers will need to understand every class in your solution because one change creates a ripple effect throughout the system. Dependency hell is much nicer than it sounds.

dominos

Workaround: Develop code that is loosely coupled. Loosely coupled code is attained by making each class units that do not have knowledge of how other classes work. This creates more flexible design. Do not overkill as too much can lead to unneeded code complexity.

5. Developer Ego

The smarter a developer and the better coder that they believe they are, the better the code output. The only one capable of creating awesome code is one who looks at the world as one complex problem. Try to avoid breaking it down into simple smaller problems, otherwise any regular programmer is capable of doing your job.

Workaround: Give the developer the smack-down.

* DISCLAIMER * Please note that my views are that of the Workaround type method and this article is meant to prove humor at what can go wrong when unsafe practices are used. Also keep in mind, I’ve probably done each and one of these plenty of times in my career.

Categories: Series, Unmaintainable Code Tags: