Making it easier to maintain JIRA workflows

This is one for JIRA admins.

I've had to track down a few problems recently that were related to fields not appearing on screens, especially when issues were changing their status. The cause turned out to be customized Transition Screens. A Transition Screen is the screen that is shown while you are moving from one status to another, and it's easy to forget which screen goes with each transition.

Sure, you can click on each transition and look for which screen is being used, or you can look at the list of screens and see which transitions used each screen. However, as the number of transitions and screens begins to grow, workflows become harder to maintain. The precision hack shown here helps with this. Click on the image to enlarge and look at the "Transitions" column. Each line has had the text "with the screen "added.




When you view any JIRA workflow with the "View Workflow Steps" screen, the transitions between steps (statuses) now have their screen information shown as well. At a glance, you can now look at a single workflow and see which of your transitions have those troublesome custom transition screens.

The file to change is

atlassian-jira/secure/admin/views/workflow/viewworkflowsteps.jsp

and the modified version can be found here. This was tested with JIRA 3.13.2 and is also a good example of what you can do with JSP if you have to.

Remedy - free the attachments!

I've inspected a lot of issue tracking databases in the last few months - JIRA, Bugzilla, TeamTrack, ClearQuest, Trac, GNATS and Remedy¹ - but the one I want to consider in this post is Remedy (a.k.a. the "Remedy Action Request System", part of BMC Remedy Service Management from BMC).

Remedy stores attached files in the database and compresses them to save space. That's fine, and they provide a compiled API library to talk to the running server application and extract and decompress the files. But if you're trying to get the data straight from the database, you're out of luck. Searching suggests that the file compression is some proprietary form of zlib but that's it. No source, no algorithm, nothing!

If you're providing an API to extract the data, why not show the customers the source? I suppose they might want to hide changes in the compression algorithm from users, but I can handle seeing that. I'm all for using carefully constructed APIs but not at the cost of the data being locked into one database.

¹ I know, I know, you're thinking "wow, those toolsmiths sure do live life in the large!"

I found a bolt-hole

I finally rented an office near home. The main things I needed were:

* an internet connection
* reasonable airconditioning and heating
* peace and quiet

The last item is why working at home isn't always as easy as one might imagine. And it's not just the kids!

~Matt

Names for Bug States

There is an interesting discussion going on over in a Bugzilla group about changing the default workflow (Open, Fixed, Closed etc) that comes with Bugzilla. My thoughts are that whatever they choose, everyone will want to change it to match their own thoughts on what states a bug should have.

What is really needed are some state names to guide users on how to use a workflow. So in the spirit of the day, I propose doing away with those vague and language-specific words such as "Open" and "Closed" and using integers instead. The first state that a bug starts in would be 0 (or perhaps 1 for non-engineering groups), then the next state should be 1, and then 2, and so on. Next, remove all transitions between states except to the next state and the possibly the previous state.

We now have a simple measure of the state of a bug, acceptable to all!

Tracking Those Personal Issues

Geek Hero Comic

I suspect that some people use bug trackers for even odder things. JIRA has a personal license for just those sort of, well, personal, things.

I'm off to the summit!

I went to the San Jose Atlassian User Group yesterday in the San Jose Museum of Art (great place for a meeting). And I won the drawing for a ticket to the Atlassian Summit!

Hope to see you there.

Neat solution for CSS footers

When navigating a website, it's a bit disconcerting to see the text at the bottom of the page moving up and down the screen as the amount of text on each screen changes.

There's a neat fix using CSS over at http://www.cssstickyfooter.com. It apparently works on every browser I could think of.

~Matt

JIRA Customization Guidelines

These are a few slides written at AtlasCamp today. The slides contain some general guidelines for customizing JIRA.

Braille typos

I was on Caltrain recently and noticed that the Braille for many of the signs must either have typos, or uses some other version of Braille than I've heard of. How can I tell? Well, the places where the same letter occurs have different symbols in each place. The picture above is of a similar sign, and I notice that it also has errors, though different from ones on Caltrain's signs.

Is this sort of thing common with Braille transliterations? Or perhaps this is Grade 2 Braille?

Can you see what I see?

Can you see anything in the pattern of this image?

If you choose colors for a software application, then make sure you print out a screen-shot of every screen on a regular black and white printer. If you can't understand something from looking at the printout, then you've used only colors to indicate something, and this will be a problem for up to 10% of your target audience.

The image above is part of a reverse colorblindness test. The image embedded in it is supposedly only visible to color blind people. I can see a circle very clearly but it would obviously be foolish to rely on color-typical people being able to see it.

USS Pampanito is a Steampunk Submarine

I had forgotten that the USS Pampanito was built at a time closer to Queen Victoria's reign than to today. Polished brass, great big chains, hydraulic lines and knobs everywhere!
There is also a great set of 360-views at http://www.maritime.org/tour/tatrvr.htm

Scientific Computing Survey

-----------------------------------------------------------------
Interesting looking survey from Greg Wilson and others. If you're a scientist, I'd encourage you to add your information.

~Matt

Computers are as important to modern scientists as test tubes,
but we know surprisingly little about how scientists develop
and use software in their research. To find out, the University
of Toronto, Simula Research Laboratory, and the National Research
Council of Canada have launched an online survey in conjunction
with "American Scientist" magazine. If you have 20 minutes to take
part, please go to:

http://softwareresearch.ca/seg/SCS/scientific-computing-survey.html

Thanks in advance for your help!

Jo Hannay (Simula Research Laboratory)
Hans Petter Langtangen (Simula Research Laboratory)
Dietmar Pfahl (Simula Research Laboratory)
Janice Singer (National Research Council of Canada)
Greg Wilson (University of Toronto)

Preprocessor Warning Signs

Using #if 0 makes searching hard

Some symbol is not defined so you grep for it and you find it in a file. But you've forgotten that you commented that part of the file out. So the symbol exists in the source but not in the .o file, leading to puzzled head-scratching. A better idea is to delete the unwanted lines since you can find them in your version control whenever you want them, and perhaps even leave a message about what they were.

Try this to see how many times you've done this:

[mdoar]$ find . -name \*.[ch] | xargs grep '#if 0' | wc

#ifdefs for unit tests mean that the code tested differs from the code used in the product


If #ifdef has to be used to make a function testable, then perhaps the function needs refactoring? If possible, use the build tool to create the tests, not the preprocessor. Some sample quotes at random from the web:

"I don't ever use ifdefs for unit testing because code should never know it's being unit tested."

"Tests must be non-invasive. I don't want to have to add #ifdef UNIT_TEST declarations into my production codebase as it'll end up making a mess and worse, could actually change behaviours. The framework and test code will be in an externally compiled project"

AtlasCamp

So I've booked my place at AtlasCamp, Atlassian's first customer/developer love-in happening this November up in Marin County, CA. I'm not really sure what to expect except lots of product discussions, and I suspect a drink or two. Maybe we'll write some code, I don't know. I'm looking forward to it.

Anyway, if you're also going and would like to carpool from around San Jose, I'll have a couple of places in my car.

~Matt

Response to "What is it like to write a technical book?"

This is a fair and honest summary by Baron Schwartz of what it's really like. I wrote a book (and proof-read it better than this post) in 2005 and probably won't get a chance to do it again ("at least not with this wife!" says my dearest).

What a well-established publisher brought to the table for me was a guaranteed outlet for the book, more marketing than I would have had the energy or time to do, and a US$6K advance. They also provided high-quality images, indexing and copy-editing.

There's a nice progress chart of my work shown above and here with the total word count and words/day over time. If I were ever to do it again, I would estimate an overall rate of 500 words/day requiring at least 200 7-hour sessions, so 1400 hours. For comparison, my 120-page doctoral thesis took about 4 months of 6 day weeks with 10 to 12 hours/day, so about 1000 hours.

Consulting is like waiting for a bus

Every few weeks I am contacted by people wanting help with their development environments. This is a Good Thing for a consultant, but I've started to notice something very odd; the new contacts always come in groups, just like buses. I never get one new contact in a day, it's always either none, two or three.

Now this might be explained if I did more public talks, or groups of colleagues recommended me, but I haven't been able to spot a pattern yet. It's not related to the day of the week either, though I know the budget cycle in companies affects when consultants are hired and fired. Anyone got any ideas? I wondered about synchronization theory but it seems like a stretch.

Making Bugzilla Read-only

I finally got this working after a few frustrating attempts. So, what not to do first.

Change database-level user permissions

I actually got this working once but it took three or four iterations since Bugzilla needs to be able to write to some tables to let you log in. Also, once you have messed with the permissions, I find restoring them to the prior state to be fiddly. This approach is really at the wrong level.


The editbugs group

There's a system level group in Bugzilla named "editbugs" that is apparently related to allowing a user to edit bugs. However removing a user from the group does nothing that I could see.

What Worked For Me

1. For each product, check the Closed checkbox so that the product does not appear in the list of products where bugs can be created. This effectively stops new bugs from being created, though perhaps using the right URL might still work.

2. Define a new group named something like "CanStillEdit" that can be used for bugs and add it to all products. Don't add anyone to the new group yet.

3. For each product, edit the group memberships at the end of the configuration page and set the "Can Edit" checkbox for just the CanStillEdit group. Leave all of the other groups unchanged. Now only members of the CanStillEdit group can edit bugs. It took a few passes through the documentation about this feature to see what they meant.

I fall goes well then trying to save a change to a bug will produce a big red box with an error message in it. Usually the error message is helpful ("you do not have permission to do that"), but sometimes it says things like "you tried to update X from to 123" which is confusing but harmless. Search works just as before.

Other details:

1. The other settings for the groups I was working with were Shown/NA.
2. Administrators can also still edit issues.
3. All this is for Bugzilla 2.x - I would hope that there are better ways to do this in the latest versions.

Big Red Button as a Psych Test

In a recent post Raymond Chen talks about Big Red Switches and various people weigh in with recollections about pressing such things. Well, I have in my possession a Big Red Button that I found at the excellent Triangle Machinery & Tool Co in San Jose. When I had a desk, I used to have it mounted with a thick cable running from it to under my desk. It wasn't connected to anything but it told me lots about the people around me.

Most people would ask "what's that for?" or "is it connected?", but occasionally there would be someone who would press the button and then ask the same questions. Those are the people you should never let into a server room!

Emacs, OS X and the EDITOR variable

This took a bit of fiddling to get right, so I offer it up to the Great Google Index with the hope that it may save someone else some time. The EDITOR environment variable is what is used by Unix applications (such as Subversion and git) when they want to start an editor for input. Starting emacs from the command line in OS X uses the open command.

To get this working with emacs and OS X Leopard I had to make the file /usr/bin/emacs contain:

#!/bin/sh
open -nWa /Applications/Emacs.app/Contents/MacOS/Emacs "$@"

This opens a file using a new instance of emacs and waits until emacs exits.

Three Hard Lessons in Consulting

1. Don't start the project until everything is ready. If a machine needs more memory to run the next version of an application, wait for the memory.

2. Stop working after the agreed period of time. It's better to disappoint a client and renegoiate than to surprise them with unexpected billable hours.

3. Windows infrastructure has a price. Locked directories, having to use Notepad, Wordpad or install Emacs, debugging complex service configurations: all of these things add up to about 25% more time taken during major tasks such as upgrades.

I'm officially and practically platform-independent in the services I provide. Linux, Unix, Windows, OS X, I do them all. But from now on I'm going to start charging different rates for Windows environments. Not a lot, just enough to offset the extra time and effort that they require.