Wednesday, November 30, 2016

November Cycling

Up to 14,349.4, 4,113.0, 122.0, meaning 20.4 + 71.4 + 12.2 = 104.4 miles, a real collapse as I tried to maximise daylight hours in the garden, and also attend meetings ending at 3pm. That's 3219.6 miles YTD, and maybe 3350 at year end at most, depending on weather.


Tuesday, November 29, 2016

Winter is coming

The car was telling me it was -4C this morning at a quarter to seven, dipping to -6C in the country lanes, and only recovering to -3C by the time I got to the office. Brrr!

Sunday, November 27, 2016

Fixing SMB access in recent Windows 10 updates

One of the updates that came down the wire to the machine I'm running on the insider slow ring in the last few weeks had the effect that trying to access the SMB share on my router gave a message like

\\Remote-Server\Path is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. etc.

Breaking out Wireshark and comparing a machine still on build 1607 (local account login) with the test machine (MSFT login) showed that the SMB handshake would perform the initial exchange of Session Setup AndX Request, NTLMSSP_NEGOTIATE and Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED, but the test machine would not then emit a Session Setup AndX Request, NTLMSSP_AUTH, User: Machine\User packet. Further experiment would be needed to tell whether this is because I'm running that machine with a MSFT login rather than a local account, rather than it being an insider build, but in the end, the fix turned out to be going to Control Panel\User Accounts\Credential Manager and creating a new Windows credential just for the Remote-Server address, with username and password sufficient to log on to the share (so for a wide-open read-only share, any username and an empty password will do).

Friday, November 25, 2016

Down Under Comes Up LIVE

Fifty years ago today, due to a launch malfunction of a communications satellite, the BBC ran an opportunistic program with the first live TV broadcast from the UK to the Satellite Tracking Station in Carnarvon, WA. And so I got to appear on live TV.

Me third from left in the front row.

UPDATE: More at honeysucklecreek.net, including a tidied up summary video. I'm on screen about the 3:50 mark.

UPDATE 2: Now in colour, me in the middle with the shadow of the microphone on my chest.

Tuesday, November 01, 2016

October cycling

Up to 14,329.0, 4,041.6, 109.8, meaning 104.9 + 11.7 = 116.6 miles, a real collapse as I tried to maximise daylight hours in the garden. That's 3115.6 miles YTD, and maybe 3500 at year end, depending on weather. And no late cycle holiday this year, as I had kittens to look after as well.

Friday, September 30, 2016

September Cycling

Up to 14,329.0, 3,936.7, 98.1 and 1.7 off meter, meaning 86.9 + 116.2 + 11.6 + 1.7 = 216.4 (2999.0 YTD, well behind last year) after a month where extremes of heat and wet, and the closing in of the evenings, meant more incentive to drive early to work, and, more importantly, get home early, after a full day's work done. And as the days get shorter, and remembering how draining cycling through last winter was, I suspect I shall drive more, and will probably fall well short of 4000 miles this year.

What I didn't realise until totting the numbers up this evening, was how few miles this month, the Cycle Challenge website having vanished at the end of August, and so no daily logs.

Wednesday, August 31, 2016

August Cycling

Up to 14,242.1, 3,820.5 and 128.8 off meter, meaning 19.3 + 183.4 + 128.8 = 331.5 miles (2782.6 YTD -- slightly up on last year, with its dreadful summer, but behind the pace for 4200 whole year, even at a steady rate).

I did manage a cycling break over the Bank Holiday weekend, with no worse than a few spots of rain on the Sunday, and glorious weather thereafter. No really long days, 50 miles being the longest, from Framlingham, up Route 1 to Beccles, then Route 31 to a very busy Southwold, a stop for rehydration, and then the last leg to Westleton, taking advantage of the dry weather to use the by-way from Walberswick where I came a cropper a few years ago -- only this time with only sand to worry about.

Town sign

I even managed to do a fair amount of new terrain, like the Route 1 off-road into Halesworth (which ought to have been the first day's destination, but once again there was no room at the inn), then everything north of Brampton on the Monday, then on the homeward leg, crossing the A12 just north of Saxmundham. OTOH, some bits I thought would have been new, near Gt Glemham, I had in fact already covered, even if only once and as recently this spring, taking a long route back from Framlingham to Woodbridge -- but this time the weather was glorious.

Saturday, August 13, 2016

A cycling anniversary

Today concludes my second year logging my journeys on the Cambridgeshire Cycle Challenge website, over which span I've logged 1137 (up from 601 = 538) journeys covering 8166 (up from 4204 = 3962) miles; supposedly 1302 kg CO2 saved (ignoring my increased respiration when burning the 147, 556 calories it tells me I have spent doing so) and saving £910.03 on fuel (ignoring the costs of fuelling me or running through consumables like chains).

Those wet spring and summer months are really showing on the numbers, now; as does an increasing dislike of the cycling conditions (= other road users) on any route to the Science Park.

Sunday, July 31, 2016

July Cycling

Up to 14,222.8, 3637.1 and 86.5, meaning 4.4 + 288.0 + 64.2 = 356.6 miles (2451.1 YTD -- and slightly behind where I was last year at this time).


The month started better than June had been, so inspiring me to start the month by filling in the wedge at Burwell, but was overall somewhat so-so, despite the real heatwave around the 20th. A week away at the end of the month meant no commuting miles, but just a few shortish rides for pub lunches, on the folding bike, around what became disappointingly wet weather.

Sunday, July 24, 2016

Another little MSVC Rust gotcha.

I've now set up VSCode with Rust on three machines -- the first two went without a hitch; the latest simply refused when running cargo install racer to compile kernel32-sys, with a x86/x64 mismatch.

And running dumpbin /headers on the system libraries mentioned in the dump of the failing link command, sure enough the x86 versions were being picked up by default. Now, going in and doing environment surgery started to unblock the system, but I wanted to figure out why this machine was giving problems.

Much scratching of head later, I realised that the first machine I'd run the command in a PowerShell window without running the Visual Studio VSVARS32.BAT, and that on the second, though I had run that environment set-up as part of my PowerShell profile, that one was running WinX/x86.

Moral of the story -- don't run cargo install from a Visual Studio prompt.

Monday, July 04, 2016

Rain brings on the Rust

One thing that the wet weather in recent weeks accomplished was to give me some time to play with Rust again, after a go-round a couple of years back, when it still needed to run in an mingw prompt, the code was full of sigils, and I couldn't get an executable to link against advapi32.dll; then again towards the end of 2014 when I migrated a fork of the rust-windows project to the then-current version.

Last year was a bit of a wash all over, coding for fun being one of the major casualties of the year, so it was pretty much a start anew, to build myself a simple "hello world", porting a simple Win32 program to the new language.

It was reasonably easy to find useful samples and fragments from which to Frankenstein together a working program. What I did not find, however, was any good guide to adding resources to the project using the native (rather than the foreign) tool-chain. So I cast around a bit and hacked this together:


It's hacky, since it builds the .rc file to a .res file that actually calls itself a .lib, so that the cargo tool will add the extensionless name as a .lib to the linker, and the linker, fortunately, ignores the file extension and just looks at the file content. It's also hacky in that it hard-codes the path to a local rc.exe, and works around the fact that that tool does not offer an output directory parameter by tree-walking from the directory where we want to place the output to where the source resides.

I'm sure there must be a better way, but this works. Apart from the fact that a VERSIONINFO compiles OK into the resulting .exe (as can be seen by opening it in Visual Studio), but doesn't show in the file properties. Application icons work just fine, though.

June Cycling

The rainy season that usually wipes out April/May cycling waited until the Late Spring Bank Holiday. This means that the totals for the month are 14218.4/3349.1 + 10.7 off-meter -- meaning 90.4 + 196.2 + 10.7 = 297.3 miles, or 2094.5 YTD, only slightly shy of my 2100 target for the half-year, even so. That is to say, despite logging the fewest miles of any month this year, even February, and 2/3 what I did in the same month last year, I'm still just ahead of last year's total.

Monday, June 06, 2016

May Cycling

Up to 14,126.0, 3152.9 and 16.8, plus 2.8 off-meter meaning 30.6 + 286.7 + 0.0 + 2.8 = 320.1 miles (1797.2 YTD -- so more miles than last May, despite having taken both Bank Holiday weeks off work, thereby removing the commuting baseload, and also ahead in aggregate).


The month started in a blaze of summer, encouraging me out on a long ride to loop around Grafham Water on the far side, where I could see the bluebell woods at their finest; and it remained summer long enough for the first T-shirt commutes to work. It was the end of the month when the weather took a turn for the worse, with no cycling getting done on the wet, cool and windy late holiday week.

Wednesday, May 18, 2016

Log literacy -- a sadly neglected skill

People who come to this blog for the technical posts may have noticed that those rather dried up over the last couple of years. There was a highly boring reason for this -- having built a little guerilla build server with one of my colleagues, it suddenly took over the world, despite our best intentions. This meant an unexpected amount of DevOps work keeping it running, and continuing to develop what had been first intended to be just a system for our team into one that covered multiple sites in different geos.

Fortunately, success was eventually rewarded by another team writing a competing system, to which my response was "Thank you, very much!" and I have at last been able to shed that particular monkey from my back. In time, that period will become a source of many war stories, but there is one particular thing that I did notice.

The key "new thing" in this system was to chain together the individual component builds that were the elements provided to the formal build process, so we could get to system-testable outputs more quickly, in a manner that could work equally on the build server and the developer's local machine. This, of course, meant that developers would at times see their builds fail in components which they were not familiar with, and then come to the two of us juggling the server (and who might be equally unfamiliar with the failing component) for a resolution.

Some of the time it turned out to be some corner case we hadn't considered in our orchestration process, but often enough it was something environmental that precipitated an otherwise normal failure in the MSBuild based process. It's just that a normal failure ends up with yards of error messages, redoubled by being screaming red text when it's in a console window on your desktop. Something like:

D:\Source\Feature\path\to\component\Library4
\Library4.csproj(##, #): error XXX####: Something went wrong
Done Building Project "D:\Source\Feature\path\to\component\Library4
\Library4.csproj" (default targets) -- FAILED.
Done Building Project "D:\Source\Feature\path\to\component\Library3
\Library3.csproj" (default targets) -- FAILED.
Done Building Project "D:\Source\Feature\path\to\component\Library2a
\Library2a.csproj" (default targets) -- FAILED.
Done Building Project "D:\Source\Feature\path\to\component\Library2
\Library2.csproj" (default targets) -- FAILED.
Done Building Project "D:\Source\Feature\path\to\component\Library1
\Library1.csproj.metaproj" (default targets) -- FAILED.
Done Building Project "D:\Source\Feature\path\to\component\Component
.sln" (default targets) -- FAILED.
Done Building Project "D:\Source\Feature\path\to\component\Build\Buil
dAll.proj" (FullBuild target(s)) -- FAILED.

Build FAILED.

[105 lines of other errors omitted]

"D:\Source\Feature\path\to\component\Build\BuildAll.proj" (FullB
uild target) (1) ->
"D:\Source\Feature\path\to\component\Component.sln
" (default target) (2) ->
"D:\Source\Feature\path\to\component\Library1\Library1.
csproj.metaproj" (default target) (15) ->
"D:\Source\Feature\path\to\component\L
ibrary2\Library2.csproj" (default target) (16) ->
"D:\Source\Feature\path\to\component\L
ibrary.2a\Library2a.csproj" (default target) (18) ->
"D:\Source\Feature\path\to\component\Library3
\Library3.csproj" (default target) (20) ->
"D:\Source\Feature\path\to\component\Library4
\Library4" (default target) (19:2) ->
  D:\Source\Feature\path\to\component\Library4
\Library4.csproj(##, #): error XXX####: Something went wrong

    0 Warning(s)
    7 Error(s)

This, it turns out, is enough to make even many quite senior developers throw their hands up in horror, when it happens in an unfamiliar piece of code -- even though, a few hundred lines earlier, there will usually be an obvious root cause, maybe something quite blatant, like:

PreBuildEvent:
  PowerShell.exe -File "D:\Source\Feature\Path\to
\component\Scripts\Do-Something.ps1" [arguments]
  The argument 'D:\Source\Feature\Path\to\component\Scripts\Do-
Something.ps1' to the -File parameter does not exist. Provide the path to an existing '.ps1' file as an argument
to the -File parameter.

which simply wasn't emitted as an error or warning in the MSBuild meaning of the terms, and so wasn't highlighted, or re-iterated, but which would be the start of what would become a cascade of FAILED and Error red text.

This phenomenon of a failure log ending with things going horribly wrong, but with a seemingly innocuous line much earlier that indicates when things started to go bad is not just restricted to MSBuild logs, or even build logs in general.

And that is the nice case. There can be worse. Sometimes the error messages at the end may be entirely unrelated to what actually failed or at best be only tangentially related (e.g. tidying operations failing when what they are supposed to tidy didn't get created) -- so trying to reason from them can be a hiding to nothing.


So when confronted by a failure log that seems to conclude with notification that the sky is falling for no good reason, take a deep breath, refuse to panic, and just start at the top. You might not always be able to resolve the issue personally, but you'll most likely be able to provide a better problem report to the person who can.

Sunday, May 01, 2016

April Cycling

Up to 14,095.4, 2866.2 and 16.8, plus 47.7 on cycling holiday meaning 162.1 + 176.5 + 0.7 + 47.7 = 387 miles (1477.1 YTD -- so fewer miles than last April, but still ahead in aggregate) having cycled at least a kilometer every day this month -- #30daysofbiking. That despite rather wet, often cold, usually windy weather, especially in the latter part of the month -- I've not yet had a day when it was nice enough to commute home in a T-shirt.