LinLog

A while back I came upon this article on using Vim as a PHP IDE.  It's got some very good pointers, although the author may have gone a little over the top on trying to mimic the behavior of PHPStorm.  I haven't tried all of those plugins, but quite a few of them are in my Vim config.

If nothing else, the article gives you a good sense for just how powerful Vim is when it comes to extending its behavior.  It's actually pretty impressive.

Earlier this year,  finally read through The Pragmatic Programmer.  It's been sitting on my bookshelf for...at least 15 years now.  I'd read parts of it before, but never went through the whole thing.  Anyway, it contains a section on choosing an editor, and one of the things they stress is extension.  You need to be able to customize your editor to extend its functionality to suit your workflow.  The idea is that the editor is one of your primary tools of code-craft and you need to make it truly yours.  You need to learn to use it well and completely, to make it an extension of your hand.

So far I'm finding Vim to be a pretty good choice in that regard.  Partly this is due to its raw power, but to a large extent it's also due to its age and the ecosystem around it.  Vim is a very old tool and it's very mature and stable.  This is a very good thing, because it means that there are lots of examples and documentation for how to use and customize it.  If you want do do something new with Vim, there's a good change that someone already wrote a plugin to do it.  And if not, there are plenty of plugins out there that you can use as examples. 

Being mature and stable also means that things are unlikely to change out from underneath you.  Sure, new features are still being added, but the basic functionality has been largely unchanged for a while.  This is what you want from a good tool.  If you're going to invest a lot of time and effort to get good at using a tool, you want that investment to retain its value.  You don't want to spend three months every couple of years re-learning because the tool vendor decided to re-architect their product or switch to the latest trendy programming language.

So while Vim may be old and boring, there's something to be said for being old and boring.  When was the last time you saw an old, boring person on The Jerry Springer Show?  Doesn't happen.  New and interesting may be exciting, but there's a reason why telling someone "may you live in interesting times" is supposed to be a curse.

A few months ago, the DropBox blog had an interesting article on code sharing in their mobile apps.  It was a good reminder that developers should be mindful of not fetishizing code re-use.  Like so many things in engineering, re-use is generally good, but still involves trade-offs.

The short-short version of the article is that DropBox originally had the idea to share code between their iOS and Android mobile applications.  After all, why write the same app twice when you can do it once?  Well, it turned out to be a really bad idea.  Because they were doing things for both platforms in a custom, non-standard way, they ended up taking on a lot of extra work just for the sake of re-using the code.  And not just in the amount of extra code they had to write in terms of custom libraries and tools - there's the extra effort of bringing new developers up to speed.  In fact, they eventually realized that it would actually be less work to just write everything twice and ended up abandoning their code-sharing approach.

Of course, this is an extreme case.  Trying to share code between two radically different platforms with different native implementation languages is bound to generate some issues.  A more prosaic example is the left-pad debacle.  You know, the one where a developer removed an 11-line JavaScript "library" from NPM and broke half the internet's deployment scripts.  But in that case, the scale was reversed - instead of trying to share a significant amount of code between a couple of projects, the left-pad package shared a completely trivial amount of code between an absurdly huge number of packages.  But the underlying problem is similar.  By trying to share that 11 lines of JavaScript "the right way", you end up taking on an external dependency that now has to be managed and probably generates more long-term maintenance effort than you saved from not writing the code yourself.  (I mean, seriously, why use a library for something that any half-competent programmer could write in less than 15 minutes?)

On the same theme, I've seen similar problems in client-side JavaScript.  I've worked on a codebase or two where large portions of the front-end were essentially cobbled together out of jQuery plugins that sorta-kinda work together, but not really.  Clearly the intention was to save effort by re-using existing components, but it didn't quite work out.  Sometimes it was because they didn't play well together, other times it was just that one of the components was not very well written.  In a couple of cases, after examining the plugins and the desired behavior, it became apparent that I could just write a version that did work cleanly in an hour or so - less time than it would take to debug the third-party plugin.

Of course, that's not to say that re-using code, whether your own or someone else's, is a bad idea.  It's clearly not.  Sometimes you find yourself writing nearly identical components for multiple projects, in which case it probably makes sense to abstract that into a shared library.  Or maybe there's a third-party library that already does more or less exactly what you need, in which case it probably makes sense to just use it.  That's all fine.

My point is just that "re-use some existing code," like any other idea in engineering, comes with trade-offs.  Sometimes those trade-offs are minor, such as the cost of managing a dependency that buys you a really big chunk of functionality.  Other times, they're pretty major, like the opportunity cost to DropBox of breaking all of the standard platform tooling.  Either way, the important thing is to think about those trade-offs and evaluate them honestly, not just jump to an "easy" answer.

This year, we spent our son's spring break in Florida.  My parents rented an apartment down there for a few weeks and invited us to come stay with them for the week.  It was a very nice week and we enjoyed some good family time and lots of unseasonably warm weather (it was in the 80's most of the week, which I'm told is a good 10 to 15 degrees higher than normal).

One of our outings for the week was a trip to Universal Studios in Orlando.  It turned out to be a beautiful day (despite predictions of rain) and we had a good time.  My son was especially excited about the Harry Potter areas.  We got the "park hopper" tickets, so we were able to visit both their "Adventure Island" park, which had a Hogsmeade area, and then take the Hogwarts' Express to the main Universal Studios park, which had Diagon Alley.  We didn't do many rides, since he's still a little young for most of the ones they have at Universal, but we had fun shopping and doing some of the non-ride activities.

Anyway, on a vaguely geeky note, they had kind of a neat drink package at Universal.  We went to Sea World two days before and they had a similar thing, but more manual (I assume it must be common for theme parks now).  Basically, rather than spend $3 or $4 per bottle of soda or water, you can spend $16 on a souvenir cup and get unlimited refills all day.  This was actually a pretty good deal, because it was unseasonably hot and we wanted to do the park all in one day (both because we were staying an hour away and because we didn't want to pay for multiple tickets).  At Sea World, you could just take our cup to any concession stand to get it filled.  At Universal, you could take it to a concession stand, but there were also free-standing Coke Freestyle machines throughout the park that you could use.  You're allowed to refill your cup every ten minutes until 2:00am the morning after you buy it.

Of course, this immediately raised the question "how do they enforce this?"  You don't have to show a receipt or talk to anyone to use the Freestyle machines.  What's to stop you from just bringing your own cup and not paying for anything?

Well, it turns out the souvenir cups actually have a microchip in the bottom.  If you look closely, you can see it in the bottom.  You can test this by not actually fully placing the cup down on the Freestyle machine.  We know this because somebody had dumped their slushie on the cup holder of one of the machines and just tipping your cup under the dispenser didn't work, presumably because it couldn't read the cup's chip.

I found this both kinda cool and kinda weird.  It was convenient, but at the same time it seems weird to have a computerized soda cup.  It's just one of those applications that I wouldn't have thought of.  Although it does explain why the Universal drink cups cost the same as the ones at Sea World despite the Sea World ones being way nicer.

Trivia entry for the week: Yesterday this blog apparently celebrated its 15th year of existence.  It looks like the first entry was February 18th, 2005.

I say "looks like" because the publication date actually says December 14th, 2006.  But that's almost certainly an artifact of the way the first versions of LnBlog stored date metadata - they didn't.  The date at which an entry was "published" depended on the file path.  Since storage is file-based, each entry goes in a folder like entries/2005/02/18_1200/, which corresponds to the date and time that I hit the "publish" button.  That part of the system actually hasn't changed in the last 15 years, but what has changed is that the publication date is now stored in the entry metadata, along with everything else.  At some point (presumably in 2006) when I added the date to the metadata, there was apparently a bug in the code such that it didn't properly fetch the publication date from the path.  So a bunch of early entries actually show the wrong publication date.  I should probably fix that at some point.

Despite the fact that I have few to no regular readers, I'm slightly proud of myself for sticking with this blog this long.  My level of posting consistency has varied radically over the years, but I've always come back to it, for at least a few posts a year.  There's something to be said for that, though I'm not sure exactly what.

I'm also slightly proud of myself for keeping this blog more-or-less working that long.  It's powered by LnBlog, which is the first real PHP program I wrote, starting in late 2004 to early 2005.  I wrote the entire thing myself, from scratch with no framework, starting in PHP 4 and now evolving into PHP 7.  And it's actually got a fairly decent feature set, so I consider it a minor accomplishment that it's still working.

For the last couple of months, I've been trying to do the weekly post thing, taking advantage of the "scheduled publication" feature to write things in advance and automatically spread out the publication.  This week is actually the first one in a couple of months that hasn't had a Saturday post (mostly because I was getting ready for vacation and didn't get around to writing anything).  We'll see how long we can keep that up.  But hopefully I'll be able to keep some level of consistency going for another 15 years.

In my review of Star Wars: The Rise of Skywalker a few weeks ago, I mentioned that I'd enjoyed the other new Star Wars movies, with the exception of Solo: A Star Wars Story, which I hadn't seen yet.

Well, I saw it.  And...yeah.

On the up side, it was definitely better than The Rise of Skywalker.  But that doesn't make it good.  That would be like saying that Anders Breivik wasn't such a bad guy because he killed fewer people that Stalin.  It doesn't work that way.  So it was pretty bad.  I'd rank it as the second worst Star Wars movie so far.

The disappointing part was that for the first third to half of the movie, I was enjoying it.  It wasn't fantastic, but is seemed like a decent, straight-forward action/adventure movie.  I distinctly remember thinking, "I don't know what people were complaining about.  This is actually not bad." 

Then in the second half the story started going down hill.  They started throwing in plot twists and flipping the "good guys" and the "bad guys" and it just didn't really work.  Especially since a lot of the "good guys" were career criminals - are we really surprised they're not so good?  Come on.  Add in the corny dialog and some iffy acting that left the characters feeling unrelatable and that just killed it for me.

And then there were the parts that seemed like they were supposed to be some form of ham-handed social commentary.  For instance, Lando's droid that was constantly agitating for droid rights.  That could have been an interesting sub-plot.  Are droids really sentient?  What does sentience actually mean?  And if they are, why doesn't galactic civilization have a problem with basically enslaving them?  And for that matter, why don't they seem to have a problem with enslaving humans or other humanoids?  How do the characters relate to these questions?

But no - they don't even try to explore any of that.  They just have the droid assert that droids are sentient and need to be liberated and then walk around ranting about it like that friend who spends way too much time on Twitter and won't stop talking about politics.  "Yeah, we get it Bob, the patriarch is bad.  Now what do you want on your damn pizza?"  It ends up just being a punchline.

Bottom line: if you haven't seen Solo, don't bother.  My only consolation was that I was cleaning the house while I watched it, so at least the time wasn't wasted.  If you want a good Star Wars story, go watch season 1 of The Mandalorian.