Tuesday, 29 January 2013

Mount Taranaki

This (long) weekend our family took advantage of the perfect weather to take a road trip to Taranaki with the goal of me and the kids climbing Mt Taranaki. We did it, but it was very tough!

My kids are quite young and I knew this would be the most challenging hike we've ever done. In the interests of safety we took a lot of gear (more accurately, I did :-) ) --- including clothes for wet weather and for cold weather, lots of food and water, first aid kit, headlamps, and locator beacon. We started early around 7:15am and gave ourselves plenty of time.

The ascent went pretty well for a while. We made the Tahurangi Hut in about 1.5 hours, which is at the low end of the expected time. After that there's a path through a ravine (Hongi Valley) followed by some steps, which were no problem, but then there's a long scree slope and about halfway up it the kids started getting upset and wanting to turn back. I cajoled them through that section without too much fuss but the last section is a rock climb that took us about an hour and half, and they were really unhappy all the way up. It was tough enough for me with my fairly large pack, and coaxing the kids up as well was quite a struggle.

Once we reached the crater area everyone cheered up immediately. It was cold up there, but there was snow and lunch and knowing we'd made it made a big difference. From the hut to the crater had taken us a bit over three and a half hours, which was actually not bad at all (nominal times are from three to four and a half hours). I clambered the short distance to the actual summit which was great, but a bit anticlimactic since clouds covered most of the land around the mountain.

I had been nervously anticipating the descent: I don't like heights and I was not enjoying the thought of looking down the mountain all the time. Nevertheless once we got into it, it wasn't a problem. Our descent was very slow --- slower than the climb --- but steady and safe. It took us about four hours to work our way back to Tahurangi Hut, which was a lot longer than nominal, but not a problem. We got back to the visitor's centre car park at 6:45pm for a total of just under eleven and a half hours --- tired but happy!

If I had known exactly how challenging it would be, I'm not sure I would have had the nerve to do it. The encouraging comments of the trampers around me, both to me and the kids, really helped keep us going on the way up, and I'm very grateful for them. Honestly I was wondering on the way up whether I was doing the right thing by forcing the kids to carry on; fortunately now we all agree that I did :-). (I never thought we were in any kind of danger, other than the danger of regretting the entire trip.) Apart from enjoying the day, the kids are proud of their achievement, and rightfully so. I'm a big believer in earned self-esteem.

Friday, 11 January 2013

Optimizing Bugzilla Usage

I spend a lot of time processing bugmail and looking at bugs. Interacting with bugzilla.mozilla.org is pretty slow, but I think it could be greatly improved, potentially saving me 15 minutes a day or more. Multiplied across our Bugzilla-using engineers and managers, that could be a large return on investment.

Every day (ideally) I read my bugmail using GMail. This is actually pretty fast. However I often need to load a bug's bugzilla page in the browser, either to re-read the context of a bugmail (earlier comments, or the contents of attachments or patches, etc), or to make changes to the bug --- usually add a comment, but sometimes change flags or other fields. I get bugmail on more than 50 bugs a day usually, and given I often scan my bugmail more than once a day, I reckon I might spend up to an hour on this on many days.

The problem is that loading a Bugzilla bug takes me about 5 seconds under the best circumstances and a lot longer for large bugs or busier networks. Also, every time I commit modifications to a bug I have to wait for about that much time for it to be acknowledged (one has to wait to ensure there wasn't a dreaded "mid-air collision").

Pretty much all that wait time is unnecessary and could be avoided with a different client. For example, we could have a Web app that does the following:

  • Tracks which bugs have been modified since I last viewed them
  • Preloads the complete data for those bugs
  • Lets me instantly move from one bug to the next
  • When displaying an updated bug, scrolls automatically to the first update that I haven't already seen
  • Lets me make changes in situ
  • When committing changes, instantly move to the next bug
  • If there's a mid-air collision, alert me even if I happen to be looking at some other bug at the time
  • Try to avoid mid-air collisions by receiving notifications of updates by other users while I'm viewing the bug
As far as I know, all of these features except perhaps the very last could be implemented using existing Bugzilla API, without changing the server side.

A client like this could make us a lot more efficient in the way we currently work. We'd probably also use Bugzilla differently and more effectively.