| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
![]()
This section:
Blog postings by Operational Dynamics partners and staff
Use the links at top left for a consolidated feed of all the posts made on this
site.
Please note the disclaimer at the bottom of this page.
Mon, 22 Oct 2007
Wonka’s last Golden Ticket found in Greenland
:)
Co-ordinates and photo interpretation from an email by Scott Elcomb on the Toronto Linux User Group mailing list.
AfC
Fri, 19 Oct 2007
Too much typing
According to the BBC, apparently, some people get stressed by email:

It seems a backlash against the always-on workplace has truly begun.
It’s not too much email. It’s too much typing
I have long observed that people in the Open Source movement spend far too much time conversing with each other by IRC, instant messenger, or on widely subscribed email lists when they could just pick up the phone and actually talk to each other. It certainly wouldn’t take as long as all the line by line writing does.
The thing that’s lacking in point-to-point voice calls, of course, is the shared collaborative nature of online text channels and mailing lists where everyone can observe and jump in if they have something to contribute.
I think what we need, therefore, are standing always-up conference voice bridges to ride over and in parallel with the text channels. This way people could listen in casually and chime in when they have something to say.
This would, admittedly, be an entirely new practice for software developers. But it’s long been the way things are done in the operations world. Air traffic control, space mission control, military combat teams, securities trading, business critical IT changes events — all are run with a voice loop as a crucial and driving element co-ordinating activities and providing the focus for dealing with crisis. There are certainly a number of mannerisms and practises that are required to make it work that people in the business world have long taken for granted (ie if you’re on a conference call, you mute unless you’re talking, that sort of thing), but the etiquette for who is talking and who isn’t is usually pretty clear. We’ve learned how to make text channels effective; we can certainly work it out for voice ones.
Since the first thing we do when running a mission critical change event for a client is put voice loops in place, how to use radio circuits effectively is something I’m used to teaching. I do realize that getting the distributed global IT world to use it effectively would indeed take some doing, but nevertheless, it’s something I think we should pursue.
Here’s hoping for less typing and more communicating.
AfC
And then it changed.
It was hot here the other day. And then it wasn’t.
At three in the afternoon on what was otherwise a lovely day in Sydney, it went from 34°C to 17°C in less than half an hour. Yikes.
Most places I’ve lived, this is a front coming through. But here, in the weather forecasts, they say “and then a change expected”. Change. Uh huh.
I suspect this is the result of Sydney being close to the south latitude region where the equatorial low pressure areas mix with the sub-tropical high pressure ones. Depending on which way the winds are slopping around, we’re either in a nice toasty warm tropical air mass or some nasty mess blowing in from the southern Indian Ocean. Same thing happens in Canada, only there it’s the marked difference between the temperate air masses and the arctic polar one.
AfC
Thu, 04 Oct 2007
Draft reports
We’re conducting a code review of a client’s software platform. Although their work is mostly aimed at internal use within their own organization, they made the long term decision that Open Source is the right way to go, and release their code. This is awesome, and turns an otherwise bog standard consulting project helping a team of people improve their processes and practices into an awesome consulting project helping a team of GPL developers write even better software. Nice.
Last week we presented a draft of the report we’ll be submitting as a part of our engagement with them. After a series of meetings, my client asked if I would send him an electronic copy of the draft I had just presented to he could mark it up.
This caused a brief pause:
- ordinarily we would not release the digital form of a draft document;
- our work on this project has a partial audit aspect to it; they want us to review their practices and results to date. And one doesn’t normally submit draft audit reports to the people being audited!
- I had not yet had the opportunity to to make the (very large) number of changes based on feedback from our meetings with the client.
On the other hand:
- they’re the customer, they can have whatever they want;
- it’s not an audit;
- hell of a lot easier for our client to comment in-line rather than having to cut & paste stuff and/or describe it in an email before commenting;
- if the client can do some of the work fixing up terminology, etc, then by all means; indeed
- collaboration is good!
So, deep breath, why not. Record changes on, and send.
It struck me how all this aligned with the usual objections to Open Source. People don’t want to release anything before it’s perfect; the idea of outsiders (clients!) contributing to a the project’s “code” is utterly foreign. And yet. Contribution directly from the people you are working with means more targeted feedback; and people making things more like what they want to see through their own effort is the very essence of Free Software.
Icky icky blobs
Compared to source code, though, office documents are horrible. The change recording and acceptance functionality in OpenOffice Writer leaves a lot to be desired. Its “merge” capability (ie, trying to bring a document two authors have worked on the document in parallel back together again) is incredibly fragile; and if you’re not careful, it’ll decide that it won’t merge anything and will instead sit there and sulk. Better not to risk it. Which means you’re basically stuck having to send off the document and not work on it until you get it back again. Still though, “collaboration is good” (it helps if you keep telling yourself this).
This sort of thing makes me wish Open Document Format text documents were actually text, not binary. (Yes, yes, it’s a compressed zip archive of a bunch of XML documents, but the end result is still a binary blob). You can’t really apply the powerful software version control and external diff and merge techniques we live by in the distributed global Open Source communities to .odt files, which is a shame, because that would be multi-user document collaboration. I’ve speculated that storing an ODF document as uncompressed in a directory, rather than in .zip single file form might make it more amenable to version control, but there’s still the problem that the XML that OpenOffice spits out is … messy. Be interesting to have a tool that whose output was still valid ODF but which was more focused on keeping the XML super clean and human readable. If we had that, then the incredibly capable tools we have for managing parallel development of source code could facilitate collaboration on documents.
Meanwhile, time to put the finishing touches on this report. Back to work.
AfC
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile


