Sunday, October 17, 2010

Redmine: Creating a new custom query

As I mentioned in the last post, Redmine's documentation isn't very thorough. Here's how to create a new custom query in version 1.0.
  1. Log into your project.
  2. Select the Issues tab.
  3. Open the disclosure triangle for Filters, and set the status and any other filters you want.
  4. Open the disclosure triangle for Options, and set the columns and grouping you want.
  5. Click on the Apply button above the results table.
  6. If you aren't satisfied with what you see, change the filters/columns/grouping, and press the Apply button again.
  7. When you're satisfied with what you have, press the Save button above the results table. This will take you to the New query page.
  8. Enter a name for the query in the Name field. If you like, you can make the query public, and make it available either for the current project or all projects.
  9. Make any changes you want to the sort order. (You can also change the grouping, filters and columns, but presumably you set those up the way you wanted before.
  10. Press the Save button at the bottom of the page.

Subtasks: Dumping FogBugz for Redmine

As you'll note in an earlier post, my wife and I had been using FogBugz for issue tracking – but I was dissatisfied with it. As I remarked in that post, the installation instructions and general support for any server platform other than Windows are mediocre. And in version 6 (which we were running), the wiki didn't support Safari.

But what was really annoying was that FogBugz 6 didn't support subtasks.

I personally find subtasks incredibly useful for organizing work! I like to take a big task – such as a major feature that may take a week or two – and break it down into sub-tasks, and sub-sub-tasks, and so on, to a level of granularity where each bottom-level task is clear and easy to complete in a few hours or less. Then I can just do them, and tick them off, and when all the lower-level tasks are done, the top-level task is done.

So when I upgraded our version-control and issue tracking server to Ubuntu Lucid, I thought, "I can get subtasks by upgrading FogBugz to version 7. Or I can look around and see if there are any alternatives."

But when I started looking around, I was amazed to see that, despite how many requests you'll see for subtask support, few issue tracking systems do it well! Trac doesn't do it at all. And as I found out when working at Kno, Jira only offers one level of subtasks – which isn't enough for me as a lone developer, let alone for what we were trying to do at Kno.

It was particularly astonishing to me because subtasks are a tree, and for a competent computer scientist, trees should be trivial. All I can figure is that the people who originally designed these systems didn't even consider the need for hierarchy, and then found that extending it was difficult. And even that I find odd, because most of them are based on relational databases, and adding a "parent task" column to the "task" table shouldn't be hard. So they must have put some unusual roadblocks in their own way.

And then, like the sun rising after a storm, I found... Redmine. It's open-source (e.g. free as in beer). It has unlimited levels of sub-tasks. It has custom fields. It has a wiki that works with every browser I've tried it with. It has forums. It's easier to install on Ubuntu than FogBugz – even from source (which I did). I just love it.

Well, except that (as of Oct. 1o, 2010) its documentation is very incomplete, and some operations can only be done in a clunky way. But at least you can do them! And I'll explain one thing I figured out how to do in the next post.

Sunday, January 3, 2010

Getting glGetString To Return Something Useful

Here's a small-but-useful factoid.

In OpenGL, glGetString() is the API to query the configuration of the system your code is running on, like the OpenGL version, or which OpenGL extensions are available.

However, if you call glGetString() before you have a current GL connection, no matter which configuration string you're querying, it will just return a NULL (nil) pointer.

If you're working in GLX, the solution is to call glXMakeCurrent() before calling glGetString(). That will open a current GL connection and you'll start getting strings back.

Unfortunately, most GLX tutorials and sample code either assume you know this, or use a utility library like GLUT that solves the problem for you without telling you how. After reading the man pages, this solution seems pretty obvious in retrospect. But as far as I can tell, it's only clearly spelled out in one place on the Net - until now. (That page also tells what to do on Windows.)