Archive for the ‘FogBugz’ Category

FogBugz and Raygun Integration

August 7th, 2013 by Adam Wishneusky

If you’re reading this, there is a good chance you track your bugs in FogBugz. Maintaining a bug database is important if you want to produce high quality software, but are you also collecting automatic crash reports from your application? FogBugz has a super-simple built-in API called BugzScout to help you do it, but it’s purposefully quite basic. If shiny graphs are more your style, take a look at Raygun, which just launched FogBugz integration!

Raygun supports most popular languages and frameworks, including Ruby/Rails, .NET, Java, Node.js, PHP, Python, JavaScript, Xamarin, and many more. When you receive a crash report in Raygun, you can cross-link it with your FogBugz case to make sure it gets fixed. For more details, head over to Raygun’s blog.

Wait, you’re not tracking your bugs? Sign up for a free trial of FogBugz today!

Introducing the FogBugz Service for Zapier

July 15th, 2013 by Sonny Kim

Zapier is a service that lets you automate tasks between different online services. Although FogBugz already integrates really well with Kiln and email, it doesn’t integrate with most of the other online services out there. For example, there’s no simple way to automatically create cases in FogBugz when there are tweets mentioning our products, or to automate card creation in Trello when new cases are created in FogBugz. But now that we added the FogBugz Service to Zapier, you can easily trigger actions between FogBugz and any of the 200+ services that Zapier supports.

One way we can use the FogBugz Service on Zapier is by creating a *zap* between Twitter and FogBugz. A *zap* consists of two things: a trigger and an action. The simple idea behind Zapier is that one service triggers an action by another service. For this particular *zap*, a tweet that mentions one of our products on Twitter will trigger a case to be created automatically in FogBugz so that we can assign the tweet to someone on the support team to respond. This *zap* can also help maintain a history of tweets within our FogBugz instance.

Automatically turn the tweets you care about into FogBugz cases!

Another use case is to integrate FogBugz and Trello. A formal FogBugz-Trello integration has been highly desired for some time now, but since there are many different ways in which development teams can use FogBugz in conjunction with Trello, just implementing a rigid case-to-card and project-to-board relationship doesn’t work for most teams. But with Zapier, you’re free to create your own relationships between the entities in your custom FogBugz-to-Trello workflow. Here are some pre-baked *zap*s between FogBugz and Trello:

A custom integration with FogBugz used to require getting your hands dirty while digging into another service’s API. Well, not anymore. With the FogBugz Service on Zapier, you won’t be bothered to learn the intricacies of another service’s API. So go check it out and start zapping it up!

Sign Up For the FogBugz Beta (Closed)!

March 26th, 2013 by Aaron Maenpaa

Update: The beta is now closed. A big “Thank You!” to everyone who signed up.


Want to see what’s coming in the next version of FogBugz? Now you can! The FogBugz team has been hard at work on a project we’ve code-named “Ocelot” for the past several months. We’ve rebuilt the core pages of FogBugz to use a completely new architecture that’s significantly faster. Like, seriously fast. And now we’re ready to start sharing it with you!


What’s shiny and new?

The new version of FogBugz is a single page app when it comes to the list page and the case page. What’s that mean exactly?

  • a super fast list page for listing and filtering your cases
  • a wicked fast case page for viewing and editing individual cases
  • blazing fast search for finding the cases you’re interested in
  • and blink-of-an-eye fast transitions between these pages

We’ve been dogfooding the new UI internally for a couple of months now and it has really improved our own experience of using FogBugz. We hope you’ll like it!

Riding the Ocelot


A Word of Caution

This is a beta, so there will be bugs. If you find one, please contact our customer service team and let them know. Furthermore, since we’re trying to get this into your hands as soon as is humanly possible, there are some caveats to the beta:

  • The beta is for FogBugz On Demand accounts only.
  • The beta UI has only been tested in Firefox and Chrome. Support for IE10 and Safari are on our TODO list and they should mostly work, but they might not and you will probably run into cosmetic issues.
  • Customizations from the BugMonkey Plugin will not apply to the beta UI.
  • With a few exceptions, existing plugins will not interact with the beta UI.
  • A number of features have not yet been implemented including:
    • Custom fields
    • Quick case add on the list page
    • Graceful handling of concurrent case editing
    • Similar speed improvements and single-page-appification to Wikis, Discussion Groups, Reporting, Admin pages, etc.
    • The Working On menu
    • Searching Wiki Pages and Discussion Groups from the main search box
  • With the exception of some specific text used in outgoing emails, the beta UI is not localized


Share your Feedback

We’re looking for feedback on: How the application feels, your general impressions, any missing features that impact your day-to-day workflow, and of course any bugs you find. Once you’ve started using the beta, please contact our customer service team and let them know what you think!

Once your account is enabled for the FogBugz Beta, you can enable and disable the beta UI on a per user basis from a link in the top right corner. If you later decide that you’d like your entire account taken off of the Beta, just let us know and we’ll be happy to take care of that for you.

Sign Up!

Dogfooding Until It Hurts

February 26th, 2013 by Rich Armstrong

Dogfooding. Also called “eating your own dog food.” It’s pretty simple, right? If you work at Uber, maybe take an Uber car ride from time to time. If you work at Khan Academy, you’re probably pretty good at math by now.

In this video from 2009, Joel talks about dogfooding as being more than just using your own product. It’s about using your own product for everything you can imagine, even if that usage is a little uncomfortable.

We dogfood Trello, FogBugz, and Kiln in a ton of different ways.

We’re a software company, so we generate a lot of code. Kiln helps with that. But we even use it to hold things that aren’t “code” per se, such as backups of non-sensitive databases. We don’t have any real crazy use cases, like using code reviews to plan parties or the electric DAG to create subway maps, but that’s just because Kiln has only been around a few years.

FogBugz, on the other hand, we use for tons of off-label stuff. We use FogBugz’s crash reporting ability to read RSS and Twitter feeds and create cases when new items appear. We use its customer email capabilities to receive faxes. And we have a panoply of API scripts automating a bunch of different business processes.

Trello is a natural for dogfooding, of course, because it’s so flexible. We keep kitchen snack requests and lunch menus on boards. We keep track of who’s going to what conferences, and use it to plan their travel. Trello really shines in setting the agenda for and running our bi-weekly company all-hands meeting. Because Trello is so flexible, it invites a lot of different use cases. We’re still figuring out which ones really work, and it’s great to see a fast-growing user base figuring that out alongside us.

So, that’s all well and good, but if you really want to see “dogfooding until it hurts” in action, check out Beeminder, a tool for setting “goals with a sting.” You set up your goals, and if you stray from them, the service fines you an escalating amount of real money until you’re back on track. Beeminder is dogfooding heavily and publicly to keep their development goals on track. These folks are  literally giving away cold hard cash to users as a pre-commitment to do things like delivering user-visible enhancements or blog posts on a regular basis. Amazing. Even better, they have a Trello integration that’ll keep you moving those cards to the Done column regularly (or else).


BugzScout: Simple Free Crash Reporting

February 11th, 2013 by Rich Armstrong

BugzScout helps you improve software quality by aggregating stack traces under the version, file and line they occurred on.  Here’s Joel and Tyler explaining it a few years back.



BugzScout certainly isn’t the only crash reporting solution out there. It’s not even the most full-featured (and, shhhh, that’s often why we like it). Crashlytics is a good one. Airbrake has traction in the Rails community. For mobile app development, we’ve found Crittercism invaluable. But BugzScout is simple and flexible, comes free with FogBugz and Kiln, and actually has many uses beyond crash reporting. (We use it as an RSS feed reader! Ping us to learn how.) No matter how many times the crash occurs, only a single case is created. It’s much more civilized than, say, flooding your inbox with a zillion dupe crash reports.

Have FogBugz and want help implementing BugzScout for your project? There’s a BugzScout section in our online webinar. Or, if you need personalized help, let us know!

Interested in making your software better through crash reporting, but don’t have FogBugz? Start a trial and get in touch!

IFTTT Notifications in FogBugz Cases

January 17th, 2013 by Max Kramer

With Ben M firing off useful, pithy blog posts faster than Rick Moranis traveling in space, there sure is a lot to keep track of on the Fog Creek blog these days. To make sure our Sales team stays abreast of new posts, I threw together a simple IFTTT mashup that activates reminder cases within their normal FogBugz workflow any time a new post comes out.

While IFTTT doesn’t currently have a FogBugz channel, it was easy to set up a recipe that monitors our blog’s RSS feed and emails a FogBugz mailbox after any feed activity. Here’s the cool part: when sending an email into FogBugz, you can seamlessly route it to a specific case by including the case number in the email’s subject line. So, all I had to do was create an IFTTT recipe and corresponding FogBugz case for each team member, include the respective case number in the IFTTT action’s subject line, and voilà! Now each Sales member is notified within FogBugz any time a new blog post comes out, and they’re free to close the case, set a Do Later task, forward it to their weird uncle, or do anything else they see fit.

Linear Workflow in FogBugz

September 21st, 2012 by Ben McCormack

The default workflow in FogBugz is pretty simple:

  1. Assign a case to someone.
  2. When they resolve the case, it gets assigned back to you.
  3. Verify & Close the case or Reactivate it.
  4. Rinse and repeat.

You can customize the default workflow using the Workflow Plugin, which will let you change the person who gets assigned a case for a particular status. However, sometimes you want to be able to move a case between various steps, e.g.

Dev  →  QA  →  Production

We wanted to make it easier for FogBugz users to visualize this kind of linear workflow, so we wrote a simple BugMonkey script that shows you the workflow at the top of the case and gives you a button to click to go directly to the next step. Here’s a quick video walkthrough:

This is a really simple way to add workflow to your cases and shows how powerful BugMonkey can be to customize FogBugz. Get the script and add it to FogBugz via My Settings > Customizations.

FogBugz and Trello Homebrew

September 6th, 2012 by Ben McCormack

When we launched Trello last year, we immediately heard from customers that they wanted Trello integration with FogBugz. It’s a reasonable request:

Fog Creek made FogBugz.

Fog Creek made Trello.

Fog Creek should make them play nicely together.

So over lunch, I asked one of the FogBugz developers, Why haven’t you made a Trello Plugin yet?” And he responded, “We would love to make a FogBugz plugin that integrates with Trello! What do you want to see?”

I drew a blank.

The solution wasn’t immediately obvious to me and I couldn’t think of a good design off the top of my head—certainly there is a good solution; it just wasn’t obvious to me what it should be. There are a billion different ways you might present FogBugz data in Trello. Plus, Trello is still maturing and (currently) lacks web hooks. Both of these things make integration with FogBugz a bit challenging at the moment.

There’s not a FogBugz-Trello integration plugin yet, but several customers expressed an interest, and I was sure I could help them out. We recently talked to a FogBugz customer who uses multiple Active statuses in their workflow and uses Milestones to break up sprints. Something like this:

FogBugz: All Cases in Sample Project Broken Down by Milestone

Given their workflow, their request seemed pretty reasonable. For a given project:

  • FogBugz Milestones as Trello Boards
  • FogBugz Active Statuses as Trello Lists
  • FogBugz Cases as Trello Cards, with a link back to the original case.

I decided to use the FogBugz XML API and the Trello API to see if we could make that view possible. Turns out it’s not that hard and this is what you get as a result:

Trello view of FogBugz Cases

Each card even has a little Kiwi icon that you can click to go right to the case in FogBugz (On Demand only). The script only updates one way (FogBugz => Trello), but I think it’s a nice visualization for this particular workflow. You can get the script here: Milestones to Trello.

Of course, you should modify the script to fit your needs. Would you prefer to see Projects as Boards with Milestones as Lists? Areas as Lists? Edit the script any way you like, and if you come up with something you want to share, send us an email and we’ll add it to our FogBugz recipes.

Do you have an idea for how FogBugz and Trello should play together? Let us know what’d you like to see by leaving an answer on our Trello Integration post.

At Long Last: The Case Merge Plugin!

August 30th, 2012 by Quentin Schroeder

We have a variety of methods for tracking what features our users are looking for, and by every measurement available, the ability to Merge Cases was at the top of the list! In fact, this has been a top feature request for quite some time.

We’ve had our eyes on this feature for a while now and even drafted a feature specification for it, but while we were drafting ideas, a user from the FogBugz Developer Community contacted us with a fully functional plugin that solved the problem! So, without further ado, may I present the Case Event Merge Plugin, written and generously shared by the developers at Quarantainenet:

“The FogBugz Case Event Merge plugin adds the functionality to display the case events of a duplicate case in the original case…. We have tried to overcome the design problem of merging by not merging at all: we just display the events of one case in the history of the other, keeping the workflow of cases intact.”

Here’s a quick video that goes over how it works:

The Case Event Merge Plugin is available for both FogBugz On Demand and customers running FogBugz on their own server. Follow the installation instructions to get started, and check out the full documentation to see what the authors have to say about it. Read on for a bit of history on the development of this plugin.


Why was this feature so hard to add?

After Quarantainenet knocked the ball out of the park with this plugin, it is easy to look at it and wonder why Fog Creek didn’t deliver it earlier. The answer lies in the details, or to be more accurate, the lack of details.

The solution that Quarantainenet devised is simple because it does not manipulate the existing rows in the database. In the feature specification draft that we were working on at FogCreek for merging cases, we were looking at it from the opposite perspective and dealing with the repercussions of trying to move the bug events from one case to the other within the database. In this scenario we had a lot of corner cases and questions that weren’t trivial to deal with.

For example:

  • Once a case is merged to another, does the system delete it?
  • What happens with new incoming emails that have the case number for the now-closed duplicate case?
  • Do we try to merge the attributes of the two cases together?
  • How do you seamlessly transition the conversation to the new case and discourage updates to the old one?

Each of these questions has valid possible solutions that we considered, but would lock the users into a specific workflow, which was something we were trying to avoid. The ability to merge cases had to make life easier for users who kept getting emails with the Case keyword stripped from it, or those infamous CC chains that seem to spawn an endless number of new cases. The solutions we were batting around made life easier in about eight out of ten scenarios, but made life a lot more confusing in those last two cases. The net gain was teetering on the edge of positive, which meant producing it just wasn’t worthwhile.


A Fresh Approach

The genius of the Case Event Merge Plugin is that the only data it requires is a marker for the duplicate cases whose events we want to display in the other case. The real work comes when FogBugz goes to render a case view page; the plugin interacts with the rendering process and creates a bunch of “pseudo bug events” from the duplicate cases. (The Kiln plugin uses the same pseudo bug event mechanism to show changesets inline with the rest of the case). These events are read from the database just as they would be if the user went to view the closed duplicate case. What this means is that the Plugin can crash, fail, be deleted, mucked with and otherwise abused and your original data is left completely intact.

Because Quarantainenet was never thinking about manipulating the existing Bug and BugEvent tables, their solution exclusively utilizes the rendering of the case view. This means that all of the core FogBugz code gets to keep chugging happily along, completely oblivious to the fact that these two cases are anything but “Resolved as Duplicates”! It’s simple, elegant, and it just works.

This plugin is already being used heavily at Fog Creek and we know many of our customers are excited about its release as well. Several years after the feature request first appeared, we’re glad that we can finally mark it as Resolved (Implemented).

How to Make a Local Copy of Your FogBugz Data

August 27th, 2012 by Ben McCormack

If you’re using FogBugz On Demand, we’re already regularly backing up your database. However, we do occasionally bring the system down for periodic maintenance, and one of our customers wanted to know how they could maintain a local copy of their important FogBugz data just in case our services were unavailable. They didn’t necessarily want the database itself, but just a way to look at case data in a pinch.

While we never plan downtime during your productive work hours, we can empathize with always wanting a local copy—just in case—in order to stay productive (for your source code, we of course offer a distributed version control solution, which promises exactly that).

To solve this problem, we added a simple script called ‘Backup FogBugz’ to the recipes section of the FogBugz XML API Development wiki. It checks FogBugz for unread cases, then saves the updated case info to a local HTML file. It doesn’t save everything—you wouldn’t be able to e.g. restore FogBugz with this data—but it does give you a relatively fresh copy of the data on your local machine.

Here’s a quick video overview of how it works:

Looking for more?

Visit the Archives or subscribe via RSS.