Stupid Git tricks: Undoing a stash pop

Here's a handy little Git nugget I learned the other day: if you get conflicts trying to apply a popped stash, it doesn't get removed from the stack.  I didn't actually know this, but it's a very handy piece of information.

In this case, I was trying to stash my changes so I could switch to a different branch.  Normally this is as easy as git stash ; git co develop ; git stash pop, but I failed to account for conflicts.  And this time it wasn't the "nice" kind of conflict, where you just fix it and move on with your life.  Noooooo.  This time, I realized that I actually needed to base my changes on the branch I was originally on.  (That branch was due to be merged into develop, but it just hadn't happened yet.)  So fixing the conflicts would have been a waste of time because I'd just have the same conflicts in reverse when I switched back.

But it turns out you can just do a git reset --hard whatever and because of the conflicts, the stashed changes will still be on the top of the stack.  Very handy!  This little nugget saved me a bunch of time.

I don't get NFT

I only recently learned about the existence of NFTs as a "thing".  If you are also unfamiliar, NFT stands for "Non-Fungible Token".  CNN has an explanation here, but t's essentially a unique digital token, stored on a blockchain, that represents some digital asset.  Apparently NFTs have recently become the latest hot trend, with some of them selling for hundreds of thousands of dollars.  

However, this Slashdot post points out that there are some potential issues with NFTs.  Basically, NFTs don't actually store the asset you're purchasing.  So if you buy an NFT for an image, the image doesn't actually live on the blockchain.  You've only bought a reference to the image, which is actually hosted someplace else.  So if whatever server or service is hosting that image goes away, you will no longer be able to access it, regardless of owning the NFT.

So I guess what I'm confused about is: what's the point?  I mean, what are you really getting when you buy an NFT?  In a theoretical sense, I can see how an NFT is better than "conventional" digital assets in that it's not tied to a particular service.  Your ownership of that item is recorded in you crypto wallet which is independent of any particular service an can be used with multiple NFT marketplaces.  And that's a good thing. 

But when you look at it functionally, there's not really much difference.  The actual asset still exists completely independent of the blockchain, so it's not like a physical asset - there might only be one token, but you can still infinitely duplicate the asset.  And as far as I can tell, buying an NFT doesn't actually mean you're purchasing the copyright for the asset.  So you're just buying a copy and there's nothing to stop anyone from making other copies.  And because the asset isn't stored on the blockchain, if you want to ensure you always have access then you need to download a copy of it.  So...how is this different from buying a service-specific digital asset?

It seems like the point is less the actual asset and more that NFT is the same thing as Bitcoin - that it's just a different way to speculate on blockchain stuff.  Especially when you're talking about something like spending $2.5 million for jack Dorsey's first tweet, it's hard to see any other rational explanation.  But even for less absurd cases, it's not clear to me what the practical benefit is.  The main reason that blockchain "works" for cryptocurrency is because the thing on the blockchain is the thing you're transferring.  As soon as you introduce a disconnect between the thing being traded and the thing on the blockchain, it seems like you lose a lot of the benefit of the blockchain.  

Handy comparison pictures

So here's a random fitness-related link.  It's a handy page I found for doing visual body fat comparisons.  I particularly like this one because (at least for the men's section) a bunch of the pictures are of the same guy.  Apparently he must have lost a bunch of weight and kept good track of it.  That makes it much easier to see the differences in physique than when you're looking at different people with different sizes and shapes.

If you're not into fitness, you might not be familiar with body fat measurement.  Body fat percentage is one of those metrics that are handy for gauging your fitness level.  It's basically just the percentage of your body weight that consists of fat.  If you don't train, then just tracking your weight is fine, but once you're lifting weights or doing other strength training, you're going to build muscle.  Since muscle is more dense than fat, it makes weight tracking less reliable - you can get into a situation where you're getting thinner, but are actually gaining weight because you're burning fat and building muscle.

There are a number of ways to measure body fat: there's the DEXA scan, which stands for dual energy X-ray absorptiometry and is considered the "gold standard"; there are multiple techniques using calipers to measure skin folds; and there's the seriously low-tech method of eyeballing it, i.e. using comparison pictures. Of course, none of these measurement techniques is exact.  Even the DEXA scan is just an estimate that can be influenced by a variety of factors.  The only 100% accurate way to determine your body fat percentage is to excise every gram of fat from your body, weigh it, and compare that to your total weight - which can't be done without killing you.

Looking at pictures is the method I use.  It's obviously the least accurate and the least precise, but it has the benefit of being by far the cheapest and easiest.  I mean, you're just looking at pictures on the internet, for crying out loud!  And for my purposes, the exact number doesn't really matter anyway.  It's more a reference point for helping to figure out what weight changes mean and where my general fitness level is.  It's nice to have a general idea, but it's not important enough to me to spend significant time or money on it.  It's just one metric among many.  How useful it is depends on your needs and goals.

Conference talks

The other day I decided to go back to something I did when I was still working in the office: putting tech conference talks on in the background while I work.  Sometimes it's nice to have a little background noise if I'm not trying to concentrate too deeply on something (what I'm currently working on involved a lot of waiting for CI pipelines to run).  Of course, sometimes I my concentration level ramps up and I totally tune out the entire talk, but sometimes I don't and it ends up being interesting.

This particular afternoon I was listening to some talks from the GOTOpia Europe 2020 virtual conference.  This one had an especially good lineup, including talks from Dave Thomas, Kevlin Henney, and Allen Holub, who are some of my favorite presenters.  Cat Swetel, who I'd never seen speak before, also had a very interesting presentation on metrics that I would heartily recommend.

It might not be the same vibe as the live conferences, but it's at least nice to be reminded that the entire world hasn't been canceled due to the pandemic.  And there are always some interesting discussions at GOTO, so it's worth a watch.

Composer autoload annoyances

Note to self: Sometimes you need to run composer du -o to make things work.

I'm not entirely sure why.  But it's a pain in the butt.

This has come up a couple of times in working on one of our projects for work.  This particular one is an internal command-line application written in PHP and using the command-line components from the Symfony framework.  I won't get into the details, but the point is that it glues together the various steps required to configure and run certain things on Linux-based servers.  So to test it, I have to put the code on my test server and make sure it works there.

The problem that I ran into today was that I tried to add a new command class to the application and it barfed all over itself.  The Symfony DI container complained that it couldn't find a certain class name in a certain file. The PSR-4 autoloader requires that the class name and namespace match the filesystem path, so usually this indicates a typo in one of those.  But in this case, everything was fine.  The app worked fine on my laptop, and if I deleted the new command, it worked again.

Well, it turns out that running composer du -o fixed it.  I suspect, based on the composer documentation, that the issue was that the class map was being cached by the opcache.  The Symfony cache was empty, so that's about the only one left.  Unfortunately, this is pretty opaque when it comes to trouble-shooting.  I would have expected it to fall back to reading the filesystem, but apparently there's more to it than that.  Perhaps it's related to how Symfony collects the commands - I haven't put in the time to investigate it.

But in any case, that's something to look out for.  Gotta love those weird errors that give you absolutely no indication of the solution.