Monthly Archives: November 2011

Hobart’s Top 10 Climbs, #9: Nelson Rd

Bend 3 of the 7 famous hairpins.

This is the second post of a series on some of the great road cycling climbs around Hobart. You can be notified of new posts in the series by following me on Twitter.  I have ordered these climbs according to my own preference.  No doubt you’ll disagree with me: just tell me in the comments!  I hope this will inspire you to go and ride these climbs 🙂

Enough blather, what about the climb?  I was in two minds as to whether or not I’d include Nelson Rd in this catalogue of climbs. It is quite a suburban road, and doesn’t have the quiet back road feel of most of the other climbs around Hobart that I’ve chosen for my top 10. However, the road has some unique and fun features, particularly 7 hairpin bends, and it is also well suited to a tempo style climb for each straight. This allows you to build up a nice rhythm with a high tempo run to each corner, out of the saddle to power around the hairpin, and then back on the seat and into your previous cadence on the next straight. Unfortunately, the lumpy road surface does throw your rhythm as you bump over driveway ramps, but I guess that’s all part of the fun!

I mark the start of this climb at the intersection between Churchill Ave and Nelson Rd, although Nelson Rd does start down at the Casino at sea level. The section of the climb between the Casino and Churchill Ave has a lot of traffic and the intersection with Churchill Ave is a hassle because of the traffic, so I’ve excluded that from the climb.

As I said above, the best features of Nelson Rd are the seven hairpin bends, which make great waypoints on the climb. Although after Bend 4 one starts to lose track and there’s always a bend or two more than you hope!  In future years, no doubt these will be commemorated with the names of famous cyclists who have conquered this climb.  I think I’d like to have Bend 3 (pictured above); you can claim one of the other ones.

After the seventh bend, marked by two big water tanks, you crest onto the “plateau” of the hill and follow the climb, which continues at the same gradient, albeit without all the zigzagging, to the finish at the intersection with Olinda Grove. This section of the climb is not very interesting but you will need to keep the power on all the way to the very end if you want to take the KOM in Strava!  (I should mention that the KOM is currently mine and I’d like to keep it that way, okay?)

Take a left at the end to ride to Mt Nelson Signal Station for incredible views over south eastern Tasmania (definitely recommended) and coffee. Turn right to take the quick way down on Proctor’s Rd. Or if you are crazy, down the Southern Outlet.

Your Challenge: ride 3 repeats in a lunch break

The next post describes a climb with a very different feel

Nelson Rd
Distance 3.9km
Category 3
Elevation 232m
Gradient 6%
Maximum Gradient 10%
Time from city 10 minutes
Traffic medium (watch for buses)
Strava http://app.strava.com/segments/628934

How to get to the climb: Take Davey St south, and turn left onto Antill St, and follow Antill St/Regent St/Churchill Ave through the University. Nelson Rd is on your right just after the University.
Nelson Rd: the climb starts here.  Bend 1 is immediately ahead

Nelson Rd is made up of long straights, and …

… Hairpin bends.  This is Bend 2

Lumpy driveways to negotiate ahead

Pleasant scenes on the climb

Bend 3

And another long straight!  Keep that tempo going

Bend 4!

More trees provide some shade

Bend 5…  Two to go.

Bend 6 ahead

Gardens to distract from the pain

Bend 7, no more hairpins after this, just a slog to the top

And here’s the top

You can ride back down Proctor’s Rd — take it easy though, it’s busy!

Other posts in this series:

Hobart’s Top 10 Climbs, #10: The Domain (Carriage Drive)

Carriage Drive on The Domain

This is the first post of a series on some of the great road cycling climbs around Hobart. You can be notified of new posts in the series by following me on Twitter.  I have ordered these climbs according to my own preference.  No doubt you’ll disagree with me: just tell me in the comments!  I hope this will inspire you to go and ride these climbs 🙂

Onto the climb!  The Domain is a great little climb within 5 minutes ride of the city centre. My friends and I use it for doing repeats. The climb starts at the bottom of Carriage Drive, a smooth little one way road that winds its way up the Domain. Be aware that the road becomes two-way half way up the climb.  Initially a gentle gradient, the climb lures you into a pace of up to or even over 30 km/h, until you round a bend half way up and the gradient triples! This is guaranteed to pour that lactate pain in as you drop through the gears.

But immediately after the steep pinch, the road levels out for a couple hundred metres, where no doubt you’ll work hard to put the pace back on again. On reaching a 4 way intersection, turn right (don’t forget traffic in your pain-induced haze), and follow the curves in the second half of the climb around to the summit of the hill. Keep following the road straight round the circle at the top, and back down the hill, then roll round to the bottom of Carriage Drive to do it all again!

See if you can fit in 5 repeats in a lunch break!  Coming up in my next post, a climb that zigs and zags…

The Domain
Distance 2.2km
Category 4
Elevation 102m
Gradient 4.6%
Maximum Gradient 15%
Time from city 5 minutes
Traffic low
Strava http://app.strava.com/segments/634467

How to get to the climb: From the Cenotaph, ride under the highway, turn right, and immediately after entering the highway, exit left. Carriage Drive is 50m ahead on your left.

Your climb starts here

Continuing up the hill

Governor’s digs on your right

Watch for traffic as you fly through this intersection

Round past the sports grounds

Turn right here

Road surface is a bit rougher now

Almost there!

The top of the climb

Other posts in this series:

Weird filename globbing in Windows

Can anyone explain this result?  (note: folder name has been obscured)

D:\...\exe\tds>dir *337*
 Volume in drive D has no label.
Volume Serial Number is 4279-DECE

Directory of D:\...\exe\tds

05/12/2011  02:39 PM        12,432,384 tds-8.0.324.0.exe
11/04/2011  02:41 PM        13,268,480 tds-8.0.337.0.exe
2 File(s)     25,700,864 bytes
0 Dir(s)  129,676,939,264 bytes free
D:\...\exe\tds>dir *337.0.exe
Volume in drive D has no label.
Volume Serial Number is 4279-DECE

Directory of D:\...\exe\tds

11/04/2011  02:41 PM        13,268,480 tds-8.0.337.0.exe
1 File(s)     13,268,480 bytes
0 Dir(s)  129,676,324,864 bytes free

I can’t figure out why tds-8.0.324.0.exe is matching *337*, in this folder.  There are lots of other files in the folder with similar names that don’t match.  chkdsk returned no errors.  Any ideas?

Update 4:45pm: I did a little more investigation.  The error can be reproduced on other computers, so it is not related to the state of the filesystem, or the path name.  The following command narrowed down the match a little:

c:\temp\tds>dir *d337*
Volume in drive C is OS
Volume Serial Number is 8036-7CEB

Directory of c:\temp\tds

12/05/2011  02:39 PM        12,432,384 tds-8.0.324.0.exe
1 File(s)     12,432,384 bytes
0 Dir(s)  12,700,200,960 bytes free

But the following did not match:

c:\temp\tds>dir td337*
Volume in drive C is OS
Volume Serial Number is 8036-7CEB

Directory of c:\temp\tds

File Not Found

Curiouser and curiouser.  Procmon did not provide much insight into the issue:

procmon

Where to now?  It’s Sunday afternoon, and I don’t feel like breaking out a kernel debugger to trace that any further right now.

Update 7:30pm: Well, I was puzzled so I did a little more research.  And ran across a mention of 8.3 filenames.  All of a sudden everything clicked into place.

D:\...\exe\tds>dir /x *337*
Volume in drive D has no label.
Volume Serial Number is 4279-DECE

Directory of D:\...\exe\tds

05/12/2011  02:39 PM        12,432,384 TDD337~1.EXE tds-8.0.324.0.exe
11/04/2011  02:41 PM        13,268,480 TDD938~1.EXE tds-8.0.337.0.exe
2 File(s)     25,700,864 bytes
0 Dir(s)  129,670,885,376 bytes free

Yes, even today DOS comes back to bite us.  So just beware when doing wildcard matches — especially with that old favourite del.

Phone Slamming Again

I wrote a couple of months ago about a phone slamming attempt.  I contacted Telstra via Twitter and they responded that they’d follow it up.  Unfortunately, Twitter’s history is a little poor so I cannot find the full conversation now… (Updated: found it in my RSS archives)

Today we got another phone slamming attempt, and I was a bit better prepared.  Again this conversation is not verbatim, but the gist is as follows:

Caller: Natasha from SimplyTel

Natasha: “I’m calling about your Telstra business line.  Can I speak with the account holder please.”
Me: “Are you calling from Telstra?”
Natasha: “I’m calling from Telstra wholesale division.”

I then asked some more questions to collect some more details, including website, and got the actual company name and contact details, before letting her know that I’d be reporting the call because she identified herself as operating on behalf of Telstra.

Workaround for the "AllowDocumentFunction constraint violated" error with Delphi XE2 apps

I have been reading discussions online about an EOleException error we were getting when calling TransformNode from a Delphi XE2 application: "Operation Aborted: AllowDocumentFunction constraint violated". The problem arises because Delphi XE2 now uses MSXML 6.0, which has made some changes to default settings for security reasons.

This, along with the ProhibitDTD property, has caused some grief. The recommended fix is to make changes to the VCL unit xml.win.msxmldom.pas. I found an alternative which appears to work without side-effects and requires no changes to the VCL source code: set the MSXMLDOMDocumentCreate to your own custom implementation which sets the AllowDocumentFunction (and ProhibitDTD or AllowXsltScript if you wanted) property after creating the object.

unit msxml_transformnode_fix;

interface

implementation

uses
  Winapi.ActiveX, Winapi.Windows, System.Variants, System.Win.ComObj, Winapi.msxml, Xml.xmldom, System.Classes,
  Xml.Win.msxmldom, Xml.XMLConst;

function TryObjectCreate(const GuidList: array of TGuid): IUnknown;
var
  I: Integer;
  Status: HResult;
begin
  Status := S_OK;
  for I := Low(GuidList) to High(GuidList) do
  begin
    Status := CoCreateInstance(GuidList[I], nil, CLSCTX_INPROC_SERVER or
      CLSCTX_LOCAL_SERVER, IDispatch, Result);
    if Status = S_OK then Exit;
  end;
  OleCheck(Status);
end;

function CreateDOMDocument: IXMLDOMDocument;
begin
  Result := TryObjectCreate([CLASS_DOMDocument60, CLASS_DOMDocument40, CLASS_DOMDocument30,
    CLASS_DOMDocument26, Winapi.msxml.CLASS_DOMDocument]) as IXMLDOMDocument;
  if not Assigned(Result) then
    raise DOMException.Create(SMSDOMNotInstalled);

  try
    (Result as IXMLDOMDocument2).SetProperty('AllowDocumentFunction', True);
  except on E: EOleError do
    ;
  end;
end;

initialization
  MSXMLDOMDocumentCreate := msxml_transformnode_fix.CreateDOMDocument;
end.

Delphi’s ongoing problem with "with"

Delphi has long included a scoping construct called with which can be used to increase the readability and efficiency of code.  From Delphi’s documentation:

A with statement is a shorthand for referencing the fields of a record or the fields, properties, and methods of an object. The syntax of a with statement is:
  with obj do statement
or:
  with obj1, …, objn do statement
where obj is an expression yielding a reference to a record, object instance, class instance, interface or class type (metaclass) instance, and statement is any simple or structured statement. Within the statement, you can refer to fields, properties, and methods of obj using their identifiers alone, that is, without qualifiers.

However, with has a really big gotcha: scope ambiguity.  Scope ambiguity came back to bite us yet again today: I am currently upgrading a major project (over 1 million SLoC) from an older version of Delphi to Delphi XE2. One component of this project is a legacy third party component package which is no longer supported.  We have full source and the cost of replacing it would be too high, so we are patching the source where needed.

While tracing a reported window sizing bug, I found the following line of code (on line 12880, yes it’s a big source file):

with vprGetTranspBorderSize(BorderStyle) do
  R := Rect(Left,Top,Width-Right,Height-Bottom);

vprGetTranspBorderSize returns a TRect.  In the earlier version of Delphi, the Width and Height properties were not members of TRect, so were found in the parent scope, being the component itself in this case.  All good.

But now in Delphi XE2, records can now have functions and properties just like a class.  So TRect has a bunch of additional properties, including Width and Height.  Handy to have, until you throw in some code that was written before these new properties existed.  One fix here is simply to qualify the scope:

with vprGetTranspBorderSize(BorderStyle) do
  R := Rect(Left,Top,Self.Width-Right,Self.Height-Bottom);

Or, you could declare a second variable, and eliminate the with statement entirely:

R2 := vprGetTranspBorderSize(BorderStyle);
R := Rect(R2.Left,R2.Top,Width-R2.Right,Height-R2.Bottom);

The problem with the second approach is it makes the code less readable and the introduction of the second variable R2 widens its scope to the whole function, rather than just the block where its needed.  This tends to lead to reuse of variables, which is a frequent source of bugs.

Many developers (including myself) have argued that adding support for aliases to with would avoid these scope problems.  Some others argue that one simply shouldn’t use with, and instead declare variables.  But with does make code much cleaner and easier to read, especially when used with try/finally blocks.

with R2 := vprGetTranspBorderSize(BorderStyle) do
  R := Rect(R2.Left,R2.Top,Width-R2.Right,Height-R2.Bottom);

Given that this issue was reported to Borland as far back as 2002, and since that time many, many complex language constructs have been added to Delphi, I think it’s a real crying shame that Borland/Inprise/CodeGear/Embarcadero have chosen to ignore this problem for so long.