Bug Tracking Work Flow with Git

At TrackJumper, one of our goals is to create bug tracking software that allows teams to work the way they want to while providing the structure that helps keep them organized. It's not always an easy task. The more helpful and specific we get with the features we add, the more TrackJumper becomes "opinionated".

That's why our "priority" field is really a generic "status" field that you can change to suit your needs. It's why we don't encourage any preconceived notions about how you split your project up - we just give you "buckets". You can assign your buckets to users, releases, types of bugs, or anything else you come up with. We use Git, so we create a bucket for each Git branch.

It's simple, but effective. We create a git branch to try out some UI experiments, implement a new feature, or fix a complex bug. As soon as we create that branch in git, we create a corresponding bucket in TrackJumper. When the bucket is empty, we can be pretty sure it's about time to merge it back into the master branch. We then merge, delete the old branch (if appropriate) and it's bucket (if appropriate). 

We'd love to hear how you prefer to organize your bugs. Email us at info@trackjumper.com  or leave a comment below.

In Defense of Chargify

Chargify, the company who makes a clean and powerful API to help companies with their billing, has just upped their prices - a lot. Gone is the free plan, and in its place a $99/month option. (Also available to small existing customers is a $39/month plan).

When we built TrackJumper, we looked at Chargify. We even implemented it into an early version of the product. In the end, we decided not to use it because Braintree's API got us the basics for free. Not going with Chargify slowed us down, and limits our ability to rapidly change our billing system. But that's a trade-off we were comfortable with, and it's been working for us.

The reactions to the price increase on Hacker News, for example, are pretty much universally negative. Some going as far as to accuse Chargify's leadership of strong arming their customers or just generally not doing "the right thing". 

But lets look at this in what I think is a more reasonable light:

Chargify was underpriced.
Chargify has a great product. The intricacies of billing schemes are not trivial to implement and I don't think it's unreasonable to say that using Chargify can save companies thousands of dollars in development cost at a point where cash is likely to be in short supply.

Chargify offers great service.
Customer service is not free - and you want good customer service for your billing system. Chargify was/is offering outstanding customer service. I know this because I had some questions about their Braintree integration. I opened a ticket and the next thing I knew, I received a phone call from their CEO, Lance Walley. We couldn't fix the problem (that Chargify doesn't yet support Braintree's V2 API), but he sure as heck tried to find a solution.

Chargify has been very transparent.
Lance routinely tweets about how many customers Chargify has and what their business is up to. He's all over the customer support tickets. As I said before, he will call you and tell you all about what they're doing if you make the slightest effort to contact them. This leads to the crux of my argument:

You must do your own due diligence.
Spending even a little time investigating Chargify would have told you that they are not making tons of money yet. That their product is free for almost all of their users. That they haven't raised significant amounts of money (at least not publicly). Is it surprising that a new CEO would come in and increase prices in this situation? Of course not. And if you'd checked, it think it's pretty likely that they'd have told you as much. I know I was told exactly that.

If this price increase was a surprise, you weren't paying attention. If your business depends on Chargify, and you can't afford a price increase, shame on you for not doing your homework.

On the other hand...
I'm not going to let them off scott free. Going from zero to $99 per month is a pretty drastic step - especially for businesses who aren't yet profitable. They could probably have done a better job at actively communicating their plans (rather than just telling those those who asked). This transition will cause a lot of cost and problems for their existing customers. Chargify owes it to them to help smooth that transition.

And the list of benefits they touted as they announced the price increase was weak -very, very weak. I'd have preferred that they said, "Hey, we're undercharging for our fantastic product, and we need to focus on our core business, so we're raising prices".

Bottom line - don't overlook Chargify because of a poorly handled transition. There is a bigger picture - look at all of it.

Show the Current Git Branch in Your Unix Prompt

I picked this tip up from Xavier Shay (who happens to be a phenomenal instructor on all things database related). It's a simple function that will save you the hassle of continually typing "git status" to see what branch you're on. I've added a slight modification to keep it quiet when not in a git repo.

Add this code to your .bash_login (or whichever config file it is that you use):

function parse_git_dirty {
  git diff --quiet  2> /dev/null || echo " *"
}
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/(\1$(parse_git_dirty))/"
}

export PS1='\[\033[33;40m\]\@ \u@\h: \w$(parse_git_branch)>\[\033[0m\]'

Then restart your terminal and you'll see the name of your curent git branch in parentheses after the path. It even adds a * to show that you're in a "dirty" state.

This

01:27 PM damoncali@macbookpro: ~/apps/ninthyard>

becomes

01:27 PM damoncali@macbookpro: ~/apps/ninthyard(master)>

or this, if you're in a dirty state

01:27 PM damoncali@macbookpro: ~/apps/ninthyard(master *)>

Sometimes it's the little things that make your day.

Using TextMate Syntax Highlighting in your Blogger Blog

When writing about code in your Blogger blog, it's helpful to be able to highlight the syntax to keep things readable. Doing this in CSS is a chore, but luckly, TextMate will do it for you.

Turning

@ideas = Idea.think_something
@ideas.each do |idea|
    idea.build
    idea.try
    if idea.good?
        idea.keep
    else
        idea.trash
    end
end

into

@ideas = Idea.think_something

@ideas.each do |idea|
  idea.build
  idea.try
  if idea.good?
    idea.keep
  else
    idea.trash
  end
end

makes things a little more readable, right?

Here's how to do it. Open a new TextMate file and cut/paste/input the code you want to be in your blog. Make sure you've selected the TextMate theme and syntax highlighting options you want to use. Also make sure you haven't selected any of the text in your file.

Go to Bundles > TextMate > Create HTML From Document

Instantly, TextMate will create a new HTML file, but with automatically generated CSS that matches your TextMate theme. Just cut and paste the entire style tag and its contents and the contents of the body tag (but not the body tags themselves) into your blog post. You'll need to do this with your Blogger editor set to "Edit HTML".

If you'll be writing about code a lot, you might want to cut and paste your TextMate CSS into your Blogger template. Just put tack it onto the existing CSS in your template (go to the "Edit HTML" page on the "Design" tab). That way, you don't need to copy the CSS every time you have some code in your blog.

Track the Source of Goal Completions with Google Analytics

It's perhaps the most basic of questions for a internet based business:

Where are my customers coming from?

So it's a little odd that you can't tell this in Google Analytics without a little (and I mean little) work. Most everyone knows about goals in Google Analytics. You set them up, and a little script to your "goal page" and then every time someone hits that page, Google Analytics records a Goal. For example, you may have a "thank you" page that shows up after someone signs up for your web app. That's your goal page. There are a few more custom options, but that's really the meat of it.

But how do you tell where the users who hit your goal page came from? Thankfully, it's pretty easy.

Once you have a goal set up, click the "Custom Reporting" link in the sidebar:

Then click the "manage custom reports" link, which will take you to a list of your reports (you have none). Click the link in the top right corner labeled "+ Create New Custom Report".

Now you're on the report creation page, which uses a nice drag and drop interface to make reports. 

First, find the blue "metric" called "Goal 1 Completions" (or the metric for whichever goal you want to track). Drag it from the  sidebar over to the first dashed blue box on the report.

Next, find the green "dimension" labeled "Source"and drag it into the first dashed green box on the report.

Edit the name of the report (there's a link next to the title), and you're done!

The First 1,000 Visitors: Part 1 - Web Application Directories

Many TrackJumper customers are building web applications for one reason or another. Most are businesses, and some of those are run by developers who are scraping the bottom of the bootstrapping barrel trying to get their efforts off the ground.

TrackJumper was born the same way - and we'd like to give back to the web community in the form of knowledge. The first 1,000 visitors can tell you a lot about your web application - your conversion rates, your bounce rates, where you get traffic, and what sorts of visitors are apt to find your offering interesting.

This post is the first in a series in which we'll expose some details about how TrackJumper got it's first 1,000 visitors. We hope you find it helpful.

App Directory Submissions
It's an oldie but a goodie - there are plenty of people on the web who aggregate information about web applications and publish that info for the world to see. These range, of course, from outright spam to legitimate publications with millions of readers.

The best part about these sites is that they're free. The worst part is that submitting your app can take a bit of time, and you may or may not get any traffic out of it. Some of these sites use do-follow links (!), some use nofollows, and some use oddball javascripty redirect schemes - presumably to mess with Google and/or for internal stats tracking.

To ease this burden, here are the application directory sites that sent us at least a small amount of traffic.

The clear winner, Feedmyapp, sent us a significant number of engaged users. In fact, one of our first customers came from this traffic. On top of that, their listing gets a nice do-follow link. Can't complain about that.

KillerStartups also sent a substantial slug of traffic. On the plus side, they wrote up an original (although slightly forced) piece of content about our app. The links are nofollow, so that's a downer.

This site is well put together, and seems to have an enterprise focus. Unfortunately, it's a pain to search, so I'm amazed that it sent any traffic at all. But it did. The link you get out of it redirects to another site first, and that's about all I cared to investigate. I assume it's worthless for SEO.

This is a nice directory of "Web 2.0" apps, and is actually useful for finding apps. Although the traffic it sent was minimal, I'd keep an eye on this one just because it's clearly useful to actual people. Unfortunately, you get no link juice from listio.

AppUseful is another web app directory - similar to, but less polished than listio. We didn't get much traffic, but we did get a do-follow link.

Billed as the "Business Software App Store", which I wish were true. Unfortunately, GetApp provides a weak user experience, no do-follow, and not much traffic.

NetWebApp is your bread and butter web app directory. Nothing fancy, and is easily searchable. Maybe they could use a little more fancy, though, because they didn't send much traffic. Got a good do-follow link out of it, though.

WebBasedSoftware
It's not hard to see why this one sent almost no traffic. Their listings are just one line text descriptions next to a text link (which is a redirect, of course). Needs a little more effort.

The Numbers
Each of these sites sent the majority of their traffic immediately after we submitted our app. All had trailed off to pretty much nothing after a few weeks. What resulted is summarized below:

384 visitors down, 616 to go.

Takeaways
Submitting to these directories will bring you a good bit of interested traffic, and some will give you a nice do-follow link. All are free. At the very least, submit to Feedmmyapp and KillerStartups. They drove a about 300 quality visitors between the two fo them. There is a rapidly diminishing return with these sorts of sites, however, so I wouldn't spend too much time on them.

Did we miss any? What other good free traffic drivers are out there?

Freelancers Need Different Bug Tracking Tools

What's the biggest difference between working as a freelance web developer and working for say, a startup? Both environments tend to involve small teams. Both are very much product oriented. Both are at the mercy of their customers.  So although the businesses are quite similar in many ways, there is one difference - in a freelance operation, the customer is involved in building the product - literally.

There's a bid difference between taking a bunch of feedback from UserVoice or GetSatisfaction and having a client tell you exactly where to put that button. The average startup (if there is such a thing) is generally fueled by people who live and breathe technology. Even the marketing guys live in their computers and know the difference between CSS, HTML, and Ruby. As a result, startups can tolerate some complexity in their bug tracking process (although we would suggest that they do not have to!).

That is not necessarily the situation for the freelancer. Have you ever tried to get a client to use Rally? Of course not - it's just not going to happen so you'd be a fool to try. But what are the alternatives? Email is usually what wins. And email, we all know, is where bugs go to die. But we dont' think it has to be this way. There is a way to keep freelancers and their clients working happily and efficiently. There are just some specific requirements.

Simple: This is crucial. A good freelance bug tracking tool should not require training or knowledge of agile processes. It should be intuitive and obvious. "Just give me a place to type the problem in". If it's more complicated than email, guess where the bugs will wind up: in your email.

Separate Projects: Freelancers have lots of projects for lots of clients. They should remain thoroughly separated for obvious reasons. Nobody wants to see other people's bugs mixed in with their own.

Multi-User: Along with those projects come clients. A bug tracker is no good to a freelancer if adding additional user accounts is cost prohibitive. Many bug trackers ramp up their price tag as you add even a few users.

SAAS: A freelancer's time is his or her currency. Every minute you spend working on something else is cutting into your hourly rate, which means you make less money and enjoy less of your time off. If you can find a simple one (good luck!), you can set up and maintain your own open source bug tracking app - you have the skills. But this is a false economy. What do you charge per hour? How much time do you spend on it? What about hosting costs. In the end, there's a reason that there is a a healthy market for bug and issue trackers. They make good financial sense.

Freelancers, don't give up on keeping your projects' bugs organized. It can be done. You just need the right tools. We like to think we've made a good one. Try it for free to find out for yourself.