Category: Technology

JIRA OnDemand CSV Import – Rough Edges

We just went through a surprising amount of effort to import projects in to Atlassian’s JIRA OnDemand, using their CSV importer. Here are some tricky bits we hit along the way; this is accurate as of November 2012. If you are reading this well after that date, hopefully JIRA’s newer JSON-based import option is supported and documented by now.

  1. JIRA CSV import can import attachments. It fetches them from URLs. Beware though that it won’t accept alternate ports. http://host/whatever is OK, http://host:nnn/whatever is broken. Moreover, is broken with a completely incorrect (403) error. (Undocumented.)
  2. CSV import can import comments. The format is documented on their site, and arcane, and permanently leaves a trail of extra data in the comment text(!). But it works.
  3. CSV import will import events as of date-time as imported. Only one date format is supported for comments; though it date format can be changed for  issue-level fields. The date format does not include a time zone. By trial and error we learned that the datetime is interpreted as the time zone which the JIRA server (at the OS level) is set to. (Undocumented.)
  4. JIRA OnDemand servers are set to the US Central time zone, or at least they pretend to be for us. YMMV. (Undocumented.)
  5. JIRA CSV import will automatically create-as-needed users if they are mentioned at the issue level (as an issue creator etc.)… but will only generate an error about missing users at the comment level.
  6. CSV import can import parent-child relationships, but not other kinds of relationships.
  7. The JIRA REST API is tempting – but it can’t assign correct historical date-times to anything, so it’s generally not useful for importing data.

In spite of those rough edges, we were able to get the job done, and are happy with JIRA.

 

Yet Another Github Issues to JIRA Export Tool

A few weeks ago I posted about the various Github Issues export tools to prepare data for import to Atlassian JIRA. Unsurprisingly, none of them worked sufficiently well for my needs. I thought about adapting and improving one of them; I know Ruby, Python, and (barely) enough Perl. But none was all that appealing; some used an obsolete Github API version, one didn’t handle comments at all (!), and so on.

Instead I wrote a new tool, in Clojure. The following tools and documentation moved things along quickly:

Download the GHI -> JIRA CSV tool now:

https://github.com/kylecordes/ghijira

A very irritating caveat is that as of June 2012, the resulting file works great with the current downloadable JIRA, but fails with JIRA OnDemand (the SaaS version). JIRA support confirmed the import problem is due to a slightly older version of the import tool used in the SaaS offering – by the time you read this, it might already have been upgraded and fixed.

Update: To help those who aren’t here for the Clojure but just to solve their GHI->JIRA problem, I added more instructions to the README file (see github project link above) explaining how to use the software.

Further Update: Several readers have contacted me with minor question, and excited success reports, in moving large project from Github Issues to JIRA with this code. Here are recent examples:

The ghijira script does exactly what it says it will do, and it does it well! I was looking for a (simple) way to move our over 600 issues from Github issue tracker to our Jira (OnDemand) project for better tracking, and this did the trick. Simple to set up your system to run the necessary bits (thanks to the easy to follow readme), and very thorough in moving comments, links, references, etc. I’ll be using this for several projects, and I could not be more thankful to Kyle for creating and sharing it. Kyle was tremendously helpful to boot!
-TJ Baker

The CTO of a 200-person engineering group in Chicago, IL writes, “I used your application to migrate thousands of issues from GitHub into a JIRA project.  There were a few tweaks, but it works far better than anything else I’ve found.”

Github Issues to JIRA – What Works?

Today I looked for a way to import issues (including history) from Github Issues to JIRA. I was delighted and disappointed to find at least four different implementations of a Github Issues to JIRA-CSV exporter – all honestly described as rough one-off efforts.

It seems likely that I’ll adapt (add minor improvements to) one of the above to yield yet another solution for this, and perhaps publish it here, so there will then be at least four choices for the next person to find.

A lot of small problems end up in this condition: many semi-solutions, no clarity on which to use. Is that what meet users’ needs best? Certainly not. Perhaps Atlassian will step in eventually with a broad, well-tested set of issue importers for JIRA. JIRA appears to be a market leader, this is an opportunity to step up and earn that role.

UPDATE: I made a new export tool, available now.

Basics: Formatting Numbers for Tabular Display

Here is the first, in hopefully a series, of posts about basic software design. Though not nearly as sexy as a location-based mobile social network with behavioral profiling for ad optimization (probably a real thing), doing basic software design well is one of our “secrets” at Oasis Digital. So here goes.

Today’s topic is how numbers should be formatted for tabular display. This comes up quite frequently in data-centric applications. For an example, consider this mockup of a working-hours-per-person display screen, example 1:

It looks quite nice with the numbers formatted trivially as whole numbers. What if someone worked 4.56 hours, though? How would that appear? To accomodate that possibility, you might always show two digits to the right of the decimal point like so, example 2:

… which is OK, but not great – all those extra zeros distract the viewer from the essence of the data. One thing you should never do, though, is something like this:

This is horrible. If you feel tempted to write software that displays data like this intentionally, please step away from the computer now. This breaks the rules of writing numbers that we all learned in primary school, probably before the age of 10: always line up the decimal point. Instead, for that particular set of numbers, the is reasonable:

So is the answer to always display as many decimal digits as the data could possibly have? Perhaps, but only if you are unable to dynamically change the format based on the contents of the data. Examples 2 and 4 show a safe but unimpressive approach.

If you have the tools and skills to create a high quality solution, aim higher: dynamically choose the right number of decimal digits, to fit the specific data in question, then apply that same format uniformly to all the numbers. The output will therefore look like #1 if the data permits, and like #4 if the data requires it, but will not needlessly fill a column with 0s as in #3. This is more work, but is a more polished, professional result.

Group Programming, Projectors, and Big Screen HDTV

I’ve done a fair amount of pair programming over the years. My “Ward Number” is 1, if anyone recognizes the reference. But we pair only occasionally at Oasis Digital. Like Jeff Atwood, we don’t live the pair programming lifestyle. For our particular mix of people and problem spaces, we’ve found the sufficient amount of pairing is roughly a couple of times per week, a couple hours at a time. We’re a partially distributed team, so this often occurs via screen-sharing tools instead of at the same desk.

However, we do something perhaps even more “extreme” than pair programming: we spend a few hours every week programming in larger groups, sometimes as many as three of us in person and a couple more remotely. Why would anyone do that?

  • To attack particularly hard problems
  • To resolve important detailed design issues
  • To share our programming style and culture
  • To freshen old skills
  • To build new skills
  • To efficiently pass knowledge 1->N, rather than 1->1

I don’t quite know what to call this. Group programming? Cluster programming? N-tuple programming?

Regardless, we encounter an unavoidable issue: it is not pleasant for several people to cram in front of a PC monitor, even a large one, closely enough to read it. We’d rather spread out, particularly for sessions lasting a couple of hours straight.

In the past at other firms I’ve solved this by working in a conference room with a projector. This doesn’t work very well. Most projectors have a maximum native resolution of 1024×768, or occasionally a bit higher, and those with reasonably high resolution are quite expensive. The reward for spending that money is continuous fan noise and an exhaust heat plume blowing on someone sitting on the unlucky side of the table.

This time we went a different direction: our group programming lair features:

  • 40-inch LED-LCD HDTV, with a native resolution of 1920×1080, which generates no noise or heat, at less cost than a mediocre projector
  • A dedicated computer, so noone’e development laptop is occupied
  • wireless keyboard and mouse can be easily passed around
  • Speakers and a standalone mic, for very clear Skype audio
  • Nearby tables to accomodate everyone’s laptops, with 22/23 inch extra displays available

It isn’t pretty:

It is very effective. We can comfortably work together in this area for hours, easily reading the screen from 6-8 feet away. (As I write this, I note that the room needs better chairs, a less beige color scheme, a printer that isn’t older than my teenager, and more Apple hardware.)

This approach isn’t for everyone; it requires a willingness to move furniture and buy non-standard equipment. I’d love to hear from anyone else doing something similar. In particular, I wonder how it compares to Pivotal’s setup.