gnu.misc.discuss
The post above from me in August 1994 asking for help with gnumake reminds me that I never did learn how to use a build tool in college. Fifteen years later, I still don't know the answer to the question that I asked, but I do know that make is still not my favourite build tool.
Still, at least the books about Make have improved with John Graham-Cumming's GNU Make Unleashed and Robert Mecklenburg's Managing Projects with GNU Make, Third Edition. That "Third Edition" part is important.
~Matt
Friday, October 9, 2009
My first build tool question
Posted by
Matt Doar
at
12:21 PM
0
comments
Wednesday, September 23, 2009
Should you go to AtlasCamp? Hint: yes!
This post is a friendly sales job for AtlasCamp, the Atlassian developers get-together that's happening October 21-23 in Half Moon Bay, California.
Cons
- Costs a bit of money this year ($200 instead of free)
- er ...
- that's it!
Pros
+ If your company depends on JIRA or Confluence and you've changed them somehow, this is the best place I've found for technical questions
+ Friendly people who write useful code at this conference, not just vapid schmoozing
+ Good presentations about what's changing in the products you depend on
+ Plenty of opportunities to tell the core Atlassian developers and top management exactly what you think of their products
See you there.
~Matt
Posted by
Matt Doar
at
10:31 AM
0
comments
Labels: atlascamp, atlassian, confluence, jira
Thursday, September 3, 2009
She found it 13 years later
Some stuff from old web pages when "Lizi", aka Elizabeth Shardon Baginski Doar, was first born. And indeed she did find them, all by herself, just the other day. I'm not sure she exactly loved it, but it was certainly a surprise!
I was born October 14th 1996 and am much loved by my parents. I like not sitting still and asking "why?". Below is an excerpt from my first email.
>fuukyiki7z x z>8jlj .l[
>'00 uyjkklglylewl;ghju7j
An interesting graph of contraction times during our daughter's birth. I think she'll love this page one day.
Posted by
Matt Doar
at
10:41 AM
0
comments
Labels: personal
Thursday, August 27, 2009
Does this bug tracker make me look whiny?
I submitted a bug about JIRA to Atlassian recently and wondered who reported most of the bugs in their very public database. No surprise, about half of the ones in the last year are from Atlassian employees.
Over the last three years, it's a tie between Neal Applebaum and Sergiy Lizenko (ILS-Ukraine) who each submitted 81 issues, and myself trailing in third place with 39 issues.
~Matt
Posted by
Matt Doar
at
5:22 PM
1 comments
Tuesday, August 4, 2009
AtlasCamp 2009
AtlasCamp is back, and it's moved to Half Moon Bay. It also costs something this year, but after the great time I had last year I'm looking forward to it.
Posted by
Matt Doar
at
11:35 AM
1 comments
Wednesday, July 22, 2009
Python Unicode oddness
If you have a Python string with an invalid character for the current character set, then other characters may get removed unexpectedly. For instance:
>>> a = 'FOO\xe0BAR'
>>> print '%r' % a
'FOO\xe0BAR'
>>> print '%r' % unicode(a, 'utf8')
Traceback (most recent call last):
File "", line 1, in
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 3-5: invalid data
Fair enough, \xe0 isn't a valid utf8 character. But if I tell the decoder to just ignore any characters it doesn't understand, it also eats the "B" and "A" characters!
>>> print '%r' % unicode(a, 'utf8', 'replace')
u'FOO\ufffdR'
>>> print '%r' % unicode(a, 'utf8', 'ignore')
u'FOOR'
That was unexpected. One day I'm sure someone will explain why it happens to me.
Posted by
Matt Doar
at
3:11 PM
3
comments
Wednesday, July 1, 2009
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.jspand 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.
Posted by
Matt Doar
at
4:43 PM
1 comments
Tuesday, June 23, 2009
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 Remedy1 - 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.
1 I know, I know, you're thinking "wow, those toolsmiths sure do live life in the large!"
Posted by
Matt Doar
at
10:27 AM
2
comments
Labels: bugs, remedy, software development
Wednesday, April 29, 2009
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
Posted by
Matt Doar
at
12:39 PM
1 comments
Labels: consulting, personal
Wednesday, April 1, 2009
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!
Posted by
Matt Doar
at
10:06 AM
2
comments
Thursday, March 26, 2009
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.
Posted by
Matt Doar
at
9:55 AM
0
comments
Friday, March 20, 2009
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.
Posted by
Matt Doar
at
10:37 AM
0
comments
Labels: atlassian
Friday, January 23, 2009
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
Posted by
Matt Doar
at
1:01 PM
1 comments
Labels: web applications
Saturday, November 8, 2008
JIRA Customization Guidelines
These are a few slides written at AtlasCamp today. The slides contain some general guidelines for customizing JIRA.
Posted by
Matt Doar
at
10:30 AM
0
comments
Friday, October 31, 2008
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?
Posted by
Matt Doar
at
1:36 PM
0
comments
Tuesday, October 21, 2008
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.
Posted by
Matt Doar
at
10:18 AM
0
comments
Labels: personal, software development
Monday, October 20, 2008
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
Posted by
Matt Doar
at
10:19 AM
0
comments
Thursday, October 16, 2008
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)
Posted by
Matt Doar
at
4:32 PM
0
comments
Tuesday, October 7, 2008
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"
Posted by
Matt Doar
at
11:07 AM
0
comments
Labels: pragmatics, preprocessor, software development, version control
Tuesday, September 9, 2008
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
Posted by
Matt Doar
at
10:07 AM
0
comments
Labels: atlassian, bugs, confluence, consulting, jira, software development
