CreatingCode

Introducing GitCV - Show off your programming awesomeness.

2012-02-15T00:00:00-08:00

Programmers, did you ever wish you could add an executive summary of your github awesomeness on your resume? Managers, did you ever wish you had a better way to evaluate the contributions and programming skills of a candidate before they come in for an interview? Well, now you can.

GitCV will display an up-to-the-minute summary of a github user's account in a clean and readable format. Here's a quick example of my profile to give you a feel of what it looks like. If you would like to add a link to your GitCV profile on your resume, simply add the following link http://gitcv.com/YourGithubUsername

There are still a few more features and graphs I want to add in the future, but I feel like this is a really good start. GitCV pulls your current public information every time the page loads, so you don't have to worry about stale data.

GitCV is free to use and extend. Are there any features you would like added? Leave a comment!

[Ratcheting] The First Few Heuristics

2012-01-24T00:00:00-08:00

It looks like we finally nailed down the first five heuristics to implement in Tipster. I will follow up this post with a more in-depth introduction into each heuristic and how we think it will add value to our radiator.

Test Baseline - Does the commit contain at least one line of test code? This is the dumbest, most simple, heuristic to implement, but you'd be surprised how many commits get flagged here. If developers are not writing any test code, we can't even think about discussing other aspects of quality.
Churn - How often is the file modified? Are large chunks of a file getting changed in a single commit? Are large chunks of the file getting deleted in a single commit? These are all red flags that can lead to risky code.
Cyclomatic Complexity - The number of linearly independent paths through code. In layman's terms, the more if statements you add to a method, the higher the cyclomatic complexity.
Contributor Diversity - It has been shown that the number of different teams (not people in a team, or geographic distance between people in a team) working on a file directly correlates to defect density.
Code Coverage - We will use a mixture of line and branch coverage to gain insight to how well covered the source file is from a unit-test perspective.

I think this is a really good start and it will give us some good insight into each commit. As time goes on, these heuristics will be fine-tuned to give the best results possible and additional heuristics can be added after we are comfortable with the list above.

[Ratcheting] Introducing Tipster

2012-01-24T00:00:00-08:00

Tipster is a ruby gem that will generate an HTML report of your most recent git commit and let you know if it is risky on one of the risk-heuristics we are implementing with Ratcheting. As we continue to refine existing heuristics and implement new ones, Tipster will give you a clearer picture of how risky your code is before you commit it!

Here's a quick look at the risk report that Tipster generates, it's still in the early stages, and should be more eye appealing and contain more robust information in the following weeks.

Tipster is available under the MIT license on Github. Feel free to contribute or use it in your own project.

End Piracy, Not Liberty

2012-01-18T00:00:00-08:00

I can't say it any better than google can.

Get involved.

[Ratcheting] Tweaking Heuristics for Better Results

2012-01-06T00:00:00-08:00

Lately we've been noticing fewer and fewer commits getting flagged as risky with each passing week. After doing some analysis we realized, for the most part, we have increased quality awareness across the organization and as a result more people are checking in test code with each commit. As a rule of thumb, we hope to see around 40% of commits flagged as risky. This number seems appropriate for now since the goal is to code review all risky commits and the value of code reviews has diminishing returns.

In our case the issue of having too few commits flagged as risky is a good thing but we still have to do something about it to ensure we are getting the most out of our efforts. Once you get to this point, there are three options that can be taken to move forward:

Introduce a new heuristic - If your current set of risk heuristics are giving you the kind of information you want, maybe it's time to add a new one. For instance, measuring cyclomatic complexity can be a nice compliment to an existing code coverage metric.
Dial-up one or more existing heuristics - Once the development organization improves to a new level, dial it up a notch and see if you can't get them to improve even more.
Make your existing heuristics smarter - One thing we've been toying around with is trying to identify files that get checked in without tests. For instance, if a developer commits three source files, but only updates two different test files, then they likely neglected to add tests for one of the files. This commit should still be flagged as risky, even if overall code coverage increased.

Ratcheting is very much an experimental process that requires constant tweaking to ensure we are tactically striking risky code in areas that provide the most value while minimizing the amount of distractions to other developers.

[Ratcheting] Lessons Learned: How Do I Run This Locally?

2012-01-05T00:00:00-08:00

Typically, when we tell developers at work about Ratcheting the reaction is generally positive. However, the one question that everyone seems to have is "How can I run this locally?" This is a really important question, one that we have somewhat neglected over the past few weeks while we have been focusing on delivering functionality for our risk metrics.

Developer communication and rapid feedback are paramount in any project and it is vital to give developers the tools they need to succeed. After all, the success of your project depends on it.

When you are doing a project that will generate some level of visibility into a developer's work, it is important to give them something that lets them know what they are getting in to before each commit. In the future we will try to do a better job of delivering the feedback tools our developers need to stay informed.

Ideally, we will roll out the changes to the local check-in script before we make the changes in the radiator. This way we can treat our developers as partners and beta-testers for new functionality instead of a user-base that is largely kept in the dark until changes are made.

How much do you bill per hour as a freelancer?

2012-01-04T00:00:00-08:00

I've always wondered what other software development freelancers set as their hourly rate as so I could use it a comparable for my own rates. Surprisingly, this information is not as straightforward to find as you might think. Thanks to a recent poll on HackerNews I now have a little clearer picture of how much my fellow developers are charging for freelance work.

Personally, this data surprised me a little. I always thought that the hourly rates for most freelancers would be significantly lower, but this data may be negatively skewed due to the fact that most of the folks on Hacker News are some of the best and brightest in our field.

On a parting note, I think it's best to set a slightly higher rate and not have to rely on billing your customers for every little thing you do. This way, you can focus on delivering quality work, and not on how much time you should bill for thinking about your client's problem on the drive to lunch.

[Ratcheting] A Typical Development Workflow

2012-01-04T00:00:00-08:00

Part of the problem we encounter when trying to implement a new policy, procedure, or even software architecture is that the people making the rules are seldom the ones that have to live with the consequences. That is not the case with the Ratcheting project. We are all, first and foremost, programmers here and will very much feel the pain of eating our own dogfood. That being said, it is in our best interest to ensure Ratcheting really does provide quality and does not end up burdening our fellow developers.

As we continue to define and refine exactly what Ratcheting is, an idea of how it might be used starts to emerge. Here is what a developer's workflow might look like during her day-to-day activities.

A developer is ready to commit code changes to the repository
The project is built and unit tests are run*
Calculate check-in risk locally*
Static quality analysis is executed*
Review risk and quality report
Improve code based on report guidelines
Re-run check-in script
Commit!
A risky commit will be flagged by the build radiator
A code review will then be generated automatically
The code review is assigned randomly to a person who has modified the file recently
Make improvements based on code review feedback

* = automated by check-in script.

Most of the things on this list we are already doing anyway, the addition of Ratcheting provides rapid feedback of code quality and risk around the time of commit, not during a post-mortem of the project done long after the project has been completed.

[Ratcheting] Intro to Ratcheting Presentation Slides

2012-01-03T00:00:00-08:00

Here are a few Powerpoint slides we put together that attempts to introduce the concept of Ratcheting and incremental code improvement. We'd love some feedback if you have any to give. Enjoy.

Code Quality and Tipster

View more presentations from Robert Greiner

[Ratcheting] Assessing Which Risk Heuristics to Implement in the Radiator

2012-01-02T00:00:00-08:00

In short, a risk heuristic should not be added to the radiator unless it meets the following criteria:

The heuristic should identify an aspect of risk - The heuristics applied in Ratcheting should give us the ability to tactically identify which commits are risky and offer an opportunity to mitigate that risk. We need to identify heuristics that are really good at identifying risk and start with those.
It should be obvious how to mitigate the risk identified by the heuristic - Once we have identified a risky commit, we need to be able to do something about it.
The heuristic's sensitivity should be configurable - As time goes on, we might need to tweak the threshold of a heuristic to better identify what is risky. For our first heuristic, test lines of code added, we might want to tweak the ratio of test lines of code to production lines of code over the life of the project to reduce the chances of flagging files that are not risky.
The heuristic should make sense in a historical context - We need to know how each heuristic will behave against prior recent commits. Are we getting enough information from the heuristic? Is it providing the right level of information? If the heuristic is flagging too many or too few commits, it might not be worth adding.
The heuristic should provide pre-commit feedback - Developers need to know what they are getting in to before they issue their commit. This feedback should be part of a check-in script and run in the same relative amount of time as your unit test suite.
The heuristic should be able to be introduced at a minimal stage - Some of these heuristics can get very complex quickly. The key here is to start small by finding the easiest possible point of entry and improve the smartness of the risk analysis over time.

This provides a good lens with which to look at individual risk heuristics. It is important to establish this rule-of-thumb early and stick to it in order to fight feature creep.

Continuous Code Improvement Using Ratcheting

2012-01-01T00:00:00-08:00

I read a great article over the weekend dealing with the concept of ~~ratcheting~~ (sorry, this website has been shut down) a legacy codebase in order to achieve the ultimate goal of quality code using incremental improvements over time.

I must admit that reading this article was a bit of a revelation for me. On the surface, the concept of ratcheting in and of itself is nothing new. After all, We were taught from a very young age that the best way to handle a complex problem is to break it down into composite pieces and attack the problem on a smaller scale (i.e. How do you eat a whale? One bite at a time.) However, the idea of implementing ratcheting in a code base was something that I had never thought of before and it seems to be a great way to help cultivate a culture of quality within a software project, especially a large software project.

At its core, ratcheting is nothing more than a check-in script that developers will run locally before being allowed to push to the central repository. This script will create a gated check-in that will ensure each push meets a minimum set of code cleanliness requirements. In order to do this, we can leverage different types of static code analysis tools to create a good baseline to measure against.

It is important to point out that ratcheting is not intended to replace unit testing. Ratcheting serves a different purpose altogether and can be used in conjunction with tried-and-true development practices that have allowed our software projects to succeed for so long.

Why do we need ratcheting?

The main problem with any code base is entropy. Simply put, entropy means that your code will inevitably trend towards chaos (or complexity) over time by default. This effect is magnified exponentially as you add more developers to the project. As a result, what ends up happening is, our once-tidy code base gets transformed into a cave of despair that is full of defects and takes incrementally longer to add new features release after release.

We've all seen it. Maybe Joe the Programmer has a tight deadline and ends up tacking a few extra lines on a method in a class that he's familiar with that "gets the job done ". Now, Joe's excuse for committing this crime will be; "hey bro, it's only five lines, who cares?" The problem with Joe's attitude is that over the course of three years and a few hundred commits on the file, our once innocent class will have morphed into a monster filled with defects and high complexity.

This common scenario is where ratcheting can really show its value. Joe wouldn't be able to check in his five-line-hack as-is because he likely would have violated one of the quality metrics the build script will be checking for (in this case, it would likely be something along the lines of cyclomatic complexity or a method that is too long).

Finally, ratcheting protects us from ourselves. Even in an ideal development situation with teams full of really smart programmers who truly care about quality code, ratcheting can help protect us from the simple little mistakes we all are guilty of committing from time to time.

What metrics should we be ratcheting against?

To be completely honest, I'm not 100% sure. What is important for my project now might not be what is important for your project which also won't be what is important to my project in a year or two.

For my project I am going to start with code coverage and likely move on to cyclomatic complexity, dead code, and duplicate code.

Ratcheting scales up well

Ratcheting also seems to be a natural remedy to the exponentially increasing overhead costs incurred by adding more developers to a project. The more developers you have incrementally improving a code base, the faster the code base becomes the awesomeness it was intended to be.

Since ratcheting is fair and unbiased, it will work especially well with teams that span across multiple continents with different levels of training, motivation, and professionalism.

The two simple rules of ratcheting

Your commit must not make the existing code base worse on aggregate - Sorry Joe, but your five-line-hack from earlier won't cut it anymore and you'll have to find a cleaner solution before you are allowed to check in.
Your commit must improve the code base in one or more areas - Oh, and by the way, I hope you added some test coverage to the code you just fixed.

The first rule is absolutely vital to ensure the code base does not get any worse. The second rule is the only way to ensure that the code actually improves over time.

Putting ratcheting into action

Over the next few months, I'm going to start implementing ratcheting in my pod at work and will document my findings on this blog.

One important question I aim to answer is What shape will ratcheting take? Ratcheting can only enforce improvement along the lines of static metrics and is unable to determine whether or not a change or refactoring is good. This being said, will ratcheting merely result in a tidy codebase with the same underlying issues? Or, will ratcheting help empower developers to fearlessly make the kind of improvements that will benefit the system a long time in the future? Hopefully, we'll be able to answer this question and many more as we delve deeper into the practice of ratcheting.

A new blog for the new year

2011-12-29T00:00:00-08:00

I thought I'd start the new year off right (and early! For those of you on Google Reader however, this post will show up late, sorry about that) by moving from Wordpress to a Github hosted blog. I also moved my domain name from GoDaddy to dnsimple (which, I really like by the way.)

I had a chance to test-drive a Github hosted blog when I created Ratcheting and I really like it. I've always kind of wished CreatingCode was a Github blog, and I figured since I'm already going through the hassle of migrating all of my domains from GoDaddy, I might as well move my blog in time for the new year.

So, please excuse the residual mess that comes from switching blog platforms, I promise to get all of the kinks worked out as quickly as possible.

And finally, for my favorite readers, those of you on Google Reader. Please excuse the duplicate posts as Google Reader syncs up with the new atom feed on this site.

I hope you all have a fantastic new year and I'll see you in January!

Unit Testing JavaScript using BDD and Jasmine

2011-12-01T00:00:00-08:00

JavaScript has been treated like a second class citizen for too long. It needs the same level of care and attention as our production code. This presentation gives a very basic introduction to unit testing JavaScript and tries to convince the audience that unit testing JavaScript is a good idea.

Testing javascript

View more presentations from robertgreiner

Creating Item Recommendations by Finding Users with Similar Taste

2011-11-15T00:00:00-08:00

Let's say you have bought some books on programming (nerd), read them, and then rated them. Now, let's say a few other people have done the same thing. As an online bookstore owner it would be in my best interest to find the users who have reviewed books similar to you (i.e. they have the same taste as you) and recommend items that you haven't read yet.

A really simple way to find how similar your reviews are to another person is to essentially graph your reviews against Reviewer X's reviews and calculate the Euclidean Distance between your numerical review scores and the other reviewer's. With Euclidean Distance, the closer the distance between the two points is, the more similar your taste is to the other user.

The key here is to take a list of reviews and calculate a numerical score, which can be called a Similarity Score that you can use to measure how the reviews of other users stacks up to your reviews.

This code will calculate the Similarity Score between two users.

Once you have calculated the Similarity Score of the rest of the users in the system, you can use those scores to weight and average the reviews of items that you haven't read in order to attempt to make the best possible recommendation. This will work with any type of item or review as long as two reviewers have something in common, a score will be calculated.

This is a really simple example of machine learning. Using a simple algorithm (or more complex one if you actually have a site that makes money) we can intelligently guess at what our customers are looking for based on data from other customers. Building intelligence into applications can significantly improve the user's experience by turning advertisement or recommendation space into something that can benefit the user. Which, will in turn improve your bank account.

This is just the tip of the iceberg, you can find the rest of the project on Github.

Notes From the Field: Breaking Down User Stories

2011-11-10T00:00:00-08:00

We had a little talk today at work discussing stories and how to effectively break them down.

Here's some of the basic points of the talk I captured with my Livescribe Echo.

There were four key points I got from the discussion:

Stories should be broken down until they fit in a single unit of work.
INVEST in good stories
Stories only need to be detailed enough for you to start work. They are designed to facilitate a discussion and do not require a huge amount of detail up front.
And finally, we discussed some Patterns of splitting stores.

Random Friday Thoughts: Leaving a Legacy Online is Free

2011-11-04T00:00:00-07:00

I was thinking about the internet this morning. I want you to go ahead and try to imagine all of the famous authors, painters, inventors, composers, and theorists that lived before, say, the 1980's. There's a ton of great ones. Leonardo da Vinci, Thomas Edison, J.S. Bach, Vincent van Gogh and the list goes on an on from famous to not-so-famous and popular to relatively unknown.

Now, think, at some point in their lives, they had to come to the realization that all of the wonderful things they were creating were likely going to be lost shortly after their death. After all, a good amount of famous artists weren't even appreciated until well after they were gone all the while plagued with the fear thet they won't be remembered after they die, uncertain about the legacy they will be leaving behind.

Fast forward a few short decades to present day. For $0 a month, I can have my own blog and github account. Everything I create is instantly shared with the entire world. My web content is archived by Google (which I'm pretty sure would survive a nuclear apocalypse) and my code is stored, replicated, and backed-up all across Github's data-centers. Everything I create and put on-line will hang around this earth far longer than I will and it was all free.

The fact that the things we create and put online never die is both invigorating and scary at the same time but we never have to worry about losing the work we create, even after we're gone. So go ahead artist, composers, and inventors. Keep creating awesome things and sharing them with the world. After all, creating a legacy is free.

Image source: USA Today

Using LINQ to sum up a list of numbers

2011-11-01T00:00:00-07:00

I don't really like foreach loops. They are difficult to read and easy to abuse.

Let's say, for example that we want to sum up the following list of numbers:

Conventional programming wisdom says that we should do the following to find the sum of the above list:

While this code does exactly what we need, it is not very expressive in its form. foreach loops end up looking the same whether you are trying to find the sum of a set of numbers or searching through a list of users to find a random contest winner.

Luckily for us, .NET provides a easier and more readable way to accomplish the same functionality as the foreach loop above.

We will sum the same list of numbers using both a foreach loop and a LINQ expression. First, let's start off with some tests so we know what we can set up our expectations early.

Now that we have our tests set up, we can move on to the actual code.

See how much easier the LINQ expression is to read? In fact, you don't even need to put anything in the parenthesis.

Taking it to the next level

The above example was a bit simple, so let's solve a problem that is a little more complex to help drive the point home. Let's say that we want to sum the squares of each item in numberList.

Just as before, we can manually find our expected answer given the same list of integers and set up our expectation before writing our production code.

Now, we can use the same methods as above which becomes more readable and succinct.

You can find the project files for this example on Github under the Open Source Public License.

Happy Halloween at Southwest Airlines

2011-10-31T00:00:00-07:00

Here's a little glimpse into the festivities going on today at Southwest. It's really nice working for a place that promotes such a laid back and fun loving atmosphere.

New Ratcheting.org Post Up

2011-10-18T00:00:00-07:00

My new post is up on ratcheting.org about three steps you can take when you aren't flagging enough commits as risky. Check it out if you are interested.

How to get a temp directory in any OS with Ruby

2011-10-18T00:00:00-07:00

I needed this over the weekend and the existing online help is less than helpful. As it turns out, just like with everything I try to do in Ruby, the solution is simple.

This is all built into Ruby, you don't need to install any gems or anything.