LinLog

This year's birthday post is a few weeks late because...well, I just didn't feel like writing it.

There's not much to say anyway.  We spent the week on vacation in Cape Cod.  We rented the same place in Hyannis that we stay every two or three years.  It's a nice spot, about a mile from main street and a two-minute walk from the beach, and the weather was very nice this year.

I had a fairly restful and uneventful birthday.  It was kind of a re-run of 2019, which is the last time we were in Cape Cod.  I spent a while wandering around Parnassus Books, though nothing really struck my fancy - all I got was a couple of Zane Grey novels.  We followed that up with a family lunch at the Flashback retro arcade and bar and then some mini-golf and a tasting at Barnstable Brewing (which are actually right next to each other).  We finished the day off with a delicious taco dinner at Añejo Mexican Bistro and some cupcakes from Little Miss Cupcape.

That's about it.  Just some good food and some fun activities with the family.  Nothing terribly exciting, but a good day none the less.  

As somebody who does a lot of work in a Linux environment, WSL (the Windows Subsystem for Linux) has become almost a required too for me.  A while back, I looked up ways to share files between native Windows and WSL.  For various reasons, the most convenient workflow for me is to do much of my work on the code from within Windows, but then run various tests and parts of the build process in Linux.  So I wanted to see what my options were.

The option I had been using was to use the mount point that WSL sets up in Linux for the Windows filesystem.  In addition to that, it turns out there are a couple of ways to go the other direction and read Linux files from Windows.  There's the direct, unsupported way or the the supported way using a network share.  Sadly, it turns out none of these are really good for me.

My main problem and motivation for looking into this was simple: performance.  When crossing container boundaries, filesystem performance takes a nose-dive.  And I'm not just talking about an "I notice it and it's annoying" performance hit, I'm talking "this is actively reducing my productivity" hit.  For filesystem-intensive processes, on a conservative estimate, when running a process in Linux, things take at least 2 to 3 times as long when the files are hosted in Windows compared to when they're hosted in Linux.  And it's frequently much worse than that.  For one project I was working on, the build process took upwards of 20 minutes when the files were on Windows, but when I moved them to Linux it was around 3 minutes.  And it's not just that project.  Even for smaller jobs, like running PHPStan over a different project, the difference is still on the order of several minutes vs. 30 seconds or so.  Perhaps this has improved in more recent versions, but I'm still stuck on Windows 10 and this is seriously painful.

My solution?  Go old-school: I wrote a quick script to rsync my project code from Windows to Linux.  Not that rsync is super-fast either, but it's not bad after the initial sync.  I just set it up to skip external dependencies and run NPM et al. on Linux, so even when there's "a lot of files", it's not nearly as many as it could be.  Of course, then I need to remember to sync the code before running my commands, which is not idea.  But still, the time difference is enough that I can run the command, realize I forgot to sync, do the sync, and run the command again in less time than just running it once on the Windows-hosted code.

So I'm getting up to speed on go-lang for a project I'm working on.  Since my company provides us with access to PluralSight, I've been going through the courses and projects in their Go pathway.

So far most of the courses have been pretty decent.  However, the projects are a different story.  The first one I did was fine - not particularly enlightening, but OK.  The second one, the Go CLI playbook, to be perfectly frank, is garbage.  At least, the first module is garbage.  I can't really speak to the rest because I can't get past the first module.

Now, in my own defense, it's not like the first module is hard.  In fact, it's completely trivial.  It basically comes down to "run go env > module1.txt ; go env -json > module1.json and then submit the result.  It even comes with a test file you can run locally.  So far so good.

The problem is, it doesn't work on Windows.  Like, doesn't work at all.  For starters, if you're running Powershell, output redirected to a file defaults to UTF-16 encoding, which is standard for Windows, but not for Go apparently.  Second, the go env command generates environment variables in an OS-specific format.  On Windows, that means it generates a file that can be consumed by cmd.exe.  Which is fine, except the project test file blithely assumes that the environment file is going to be in UNIX shell format, so the "set" at the start of each line makes it choke.

Well, that sucks.  Guess I'll just use WSL.  When I run the commands there and run the tests, they pass.  Great!  Let's upload the result and get on with our lives.  Except that doesn't work, because the tests fail when run in PluralSight's validator.  I don't know why.  My best guess is that something in the upload process is mangling the encoding.  I do know that it apparently doesn't run the test file you upload, so you can't hack around whatever the bug is.

The worst part is that you can't progress to the rest of the project until you "pass" that section.  So I'm pretty much just out of luck.  Maybe the rest of the course has some great material.  Or maybe it's equally useless.  Who knows?  Maybe it's just this project - so far the others I've tried have been OK.  Although I did have one other module where all the tests passed locally, but failed on upload.  But in that case, I at least had a legitimate bug in my code.  Why the tests passed locally is a different problem, though....