Next we’ll look at the API to get information about a board. Boards are fundamentally broken, in my opinion, because they aren’t a real thing in Jira. They’re a view into issues at a point in time, which means that they don’t show up anywhere in the history. You can’t tell what board an issue was on when a status change happened, and you can’t assign an issue to a board.

The issue history gives us both the name and id of any statuses that the ticket has moved through. Sometimes that’s enough but often we then need to know more about that status, such as what status category it belongs to and for that, we need to call a different API.

If you want metrics out of Jira, the single most important thing you need to access is the issue history and it’s not obvious how to get that. Just about all the metrics you’ll want to collect will need data from the history - you might need to know when an item started or when it entered a certain priority or when the flag was set or cleared.

I’m the primary author of the jirametrics tool that extracts data from Jira and generates reports. This tool evolved to satisfy my own pain of not being able to get useful data out of Jira with the built-in reports and along the way, I’ve learned more about Jira internals than I ever wanted to know.

Over my career, I’ve noticed that a significant number of programmers ignore compiler and linter warnings. They either turn the warning levels down or just ignore the output. I’ve worked with teams using SonarQube that would have tens of thousands of warnings that they wouldn’t even look at.

A linguistic antipattern is a place in the code where the naming implies that it does one thing and in fact, it does something different. For example, the method void isEmpty() suggests that it will return a boolean reflecting whether or not the object is empty, yet the method does not return anything.

Technical debt is made up of all those things in our system (architecture, code, documentation, etc) that are working but are of sufficiently poor quality that they cause us to move slower when implementing new functionality. Perhaps we need to do additional testing before we can add something new or we need to refactor the code to make it cleaner or more extensible. Perhaps it’s just hard to read or understand and therefore difficult to know how to add the new functionality.

Test Driven Development (TDD) is often though of as a testing activity but it really isn’t. It’s a design activity that leaves a bunch of automated tests behind in its wake. The basic idea is that we write a test first and then write the production code that allows that test to pass. It sounds simple, and it really is, but there are some important subtleties.

This article will show how to “test drive” the prime factors kata in Elixir with ESpec, a spec style unit testing framework.

This article will show how to “test drive” the prime factors kata in Ruby with RSpec, a spec style unit testing framework.