New desk

After working from home for the last two years, I finally broke down and got myself a new desk.  This one is significantly smaller than the one in my previous home office setup.  That one was a larger L-shaped desk.  However, I found that I actually didn't need that much space.  The L extension meant that it was hard to reach and hence use the far corner.  I also didn't really have any need for the extension and it basically turned into a dumping ground for random stuff.

IMG_20220804_150947-small.jpg

This one is much more compact.  That means that, not only do I actually use all of the space, but my office (which is pretty small) feels bigger.

The other big win is that this is a standing desk.  I got a 60-inch by 30-inch Uplift V2 adjustable height desk with the rubberwood surface and I'm very happy with it.  The Uplift desks are fun because there's a lot of customization you can do.  Of course, that also means that the price can vary wildly.  I mean, they start at $600 for a basic 42-inch model, but as you upgrade the size, material, add-ons, etc., it adds up quickly.  The price tag for mine ended up at around $1300.

There are lots of fun add-ons, though.  I got:

  • The casters so I can roll the desk around easily.
  • The bamboo drawer.
  • The upgraded programmable adjustment control.
  • The upgraded cable management system.
  • Three shelves for monitors etc.
  • Two of the powered grommet covers
  • The extra power outlets (so I actually have 2 USB and 6 conventional plugs on the desk).
  • The foot hammock.
  • A standing mat.
  • The bamboo Rocker-X board (with comfort pad), which is surprisingly satisfying.

The assembly took a while, but wasn't too bad.  The main challenge for me was that I had to assemble the desk more or less in-place with the other desk still in the room.  That's because I had no place to put my work setup while I assembled the desk (which I did over a couple of days) and, due to the door and hall size, the new desk couldn't easily be moved into my office after it was assembled (it would have to be turned on one edge, and that's a two-man job).  However, the instructions were fairly clear and the assembly wasn't too difficult.  There were a few steps where I needed to drill holes in the underside of the desktop, but other than that it was pretty much just screw drivers and Allen wrenches.  It takes some time, but it's not especially complicated - though some of it depends on what add-ons you get.

So if you're looking for a standing desk, the Uplift V2 is a good choice.  And if you've never used a standing desk, you might want to look into it.  I find that it really does help.  With my old desk, I sometimes found my legs starting to get stiff or cramped from sitting too long.  But if I get up and walk around frequently, that can sometimes interrupt my flow and make it harder to get things done.  A standing desk is a good compromise, because you can keep working, but still stretch your legs and move around.

I also found that the combination of the standing mat and the Rocker-X board really helps.  Just standing on the hard floor can be better than sitting, but it's still not super comfortable, especially if you're working at home and not wearing shoes.  The standing mat gives you a nice cushion, which makes standing for long periods in socks or bare feet much more comfortable.  And the Rocker-X board, while it looks like a silly gimmick, is awesome, especially if you're a fidgeter like me.  Even when I'm sitting, I'm constantly moving my legs and feet around.  The Rocker-X board lets you shift your weight and move your feet constantly, while still keeping you in a position where you can work.  I highly recommend giving it a try.

Belated birthday post

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.  

On WSL performance

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.

When online courses go wrong

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....

Powering down an old friend

I made bunch of purchases on Prime Day this year.  Among them was a replacement for my old home server, dubbed "Tallgeese".  Yes, I still use the same Gundam Wing naming theme I've had for like 20 years (if it ain't broke, don't fix it).  In fact, I've been using the name "Tallgeese" specifically to refer to my current non-laptop PC, whatever that happens to be, for a very long time.

Front view of the old TallgeeseBack view of the old Tallgeese

This box has served me well for over a decade.  It holds a special place in my heart because I built it myself from parts and upgraded it over many years.  The oldest part, by far, is the case.  I'm not 100% sure when I got that, but I think it might be the replacement for the broken one I referred to in this post from April 2005.  After that, the motherboard and CPU are quite old - I got those in September 2010.  The rest of the pieces are probably newer, but I don't really remember when they were replaced.

Now that I look at it, the specs on this box aren't actually that bad, even by modern standards.  Granted, they're still sub-par for anything made in the last five years, but it's still got enough horse-power to do useful work.  It's got a 4-core processor, the motherboard is maxed out at 8GB of RAM, and it has just over 4TB of storage.  As a media server, it actually works just fine.

The old Tallgeese CPU and motherboard.  It hasn't been cleaned in a while.

But on the other hand, you can also tell its age just by looking at the hardware.  For instance, that PCI card near the bottom is a sound board - a relic from the bad-old-days when Linux users needed to actually care about what kind of sound cards they bought if they wanted audio to work properly.  You can also see an internal media card reader in front with a crap-ton of slots - another relic from before everybody had settled on SD and microSD.  And you can't miss the two DVD drives - a DVD-ROM drive and a DVD+RW drive.  One of them is broken, but they're so irrelevant by this point that I no longer remember which one.  And we can't forget the serial, parallel, and PS/2 ports.  I don't even remember how long it's been since I used a PS/2 mouse or keyboard.  (For those too young to remember: "PS/2" is for the IBM Personal System/2, not PlayStation 2 - though that's old now, too.  And while I still have a PlayStation 2, I never has an IBM PS/2 - we had a PS/1 instead!)  The pictures also don't show the VGA-to-HDMI dongle I had to use for video to get it to connect to my main monitor, which never really worked well anyway.  When everything was plugged in, the back panel was actually kind of a disaster area.

Of course, just "being old" isn't really enough reason to get rid of a perfectly good box.  Like I said, it still works.  At least for now.  But it's been plagued by occasional stability issues, particularly when I tried to do anything that involved graphics (e.g. playing Battle for Wesnoth, which isn't exactly the most graphically demanding game in the world).  It would occasionally just lock up for no obvious reason.  It's also a big, clunky box that's kinda loud and generates a lot of heat.  And most of the components are old enough that it doesn't even make sense to try and mitigate these short-comings.  It's cheaper and easier to just buy a new box and slap my preferred software on it.

The new TallgeeseMkII, with data drive enclosure and some size context.

So I ended up buying this little guy, which I'm dubbing "TallgeeseMkII" - that was the version with the blue trim in the cartoon.  Since it was Prime Day, I actually ended up getting the model with 16GB of RAM and the 512GB disk for about the same price.  It's got considerably more horse-power than the old box and the case is actually smaller than the external 3.5" drive enclosure I'm using to house the 4TB data drive from the old Tallgeese.  The entire setup will fit comfortably under one shelf of my new desk (which is another post).  For context, I included my Huey Games Droid Assault "cassette" (actually a USB drive, but shaped like an old-school cassette tape) and the wood-block panda painting my brother did for me.  For context, he originally started doing them that size because they were being sold out of repurposed vintage cigarette machines.  So yeah, significant space savings here.

But as I said, the old Tallgeese lives on, at least in the form of its data drive, which was relatively new and still perfectly good.  I also pulled out the OS drive, since that was still good and it's easier to just stick that in a USB enclosure to grab any config or files that I need than it is to get them from backups.  I doubt I'll be using it for much else, though - while it is an SSD, it's only 120GB.  But some of the files from it will live on, so I guess that counts for something.