Broken development environment

Author's note: This episode of From The Archives is the stub of an article I wrote on December 10, 2007.  At the time, I was working for eBaum's World (this was back around the time ebaum sold it, but before he was forced out).  It was kind of a weird time because it was my first experience working for an actual tech company.  (It was also a weird place to work, for other reasons, but that's a different story.)  Previously, I'd been stuck in the world of public-sector internal IT which is...not great, by comparison.

This particular post was expressing my annoyance over how our development environment was broken.  Our dev environment, at the time, was literally just a shared server that we all pushed code to. And yes, that means we had plenty of opportunity to step all over each other and things could easily break for non-obvious reasons.

This was obviously terrible, but it's what we had to work with.  We had a four-man development and system administration team with not a huge budget or set of internal resources.  And, of course, there was always something more important to do than improving our dev environment setup.

These days, I still have dev environment issues, but for completely different reasons.  My company has an entire infrastructure for spinning up development VMs, including dedicated host clusters, custom tooling to setup environments, and teams responsible for managing that stuff.  So now I have my own virtual instance of every server I need (which, for reference, is currently about eight VMs).  However, there are still some holes in that infrastructure.

Part of the issue is that we have a lot of teams that share or depend on the same infrastructure and/or services.  For instance, one of the services that my team maintains is also worked on by at least three other teams.  And we all share the same database schema, which doesn't automatically get updated in dev environments when changes are made in production, so when you pull in the develop branch, you frequently get breaking changes that you may not have ever heard of, usually in the form of config or database changes that aren't set in  your environment.  Sure, everything "just works" if you start fresh, but nobody ever starts fresh because it takes too long to spin up all the required pieces and set up the test data.  (However, we are moving toward a Docker/Kubernetes setup for the pieces that don't need test data, so things are moving in the right direction.)

Not that I can complain too much.  Even for my personal projects, which are much simpler, my dev environment is frequently in disarray.  Things get out of date, permissions or services don't get correctly configured after an update, or my setup is out of sync with the production environment.    In fact, I had that problem just the other day - I pushed some code for this blog that worked fine locally, but broke on the live server because it was running a different version of PHP.  Granted, the code in my dev environment was wrong (and I really should have caught it there), but that's not the point.

The point is that environment maintenance is hard and dev environment maintenance doubly so because it changes frequently and is of much lower priority than production.  That's something I hadn't really had to worry about in my internal IT job, because I was writing desktop apps and everybody was running identical Windows desktops.  It was a a simpler time....


This week's installment of "Pete's list of things that suck" features broken development environments.  I spent the last couple of days at work wrestling with one and it really, really sucks.

The thing is, our development environment is...really screwed.  Things went really bad during the production server upgrade a couple of months ago and we had to hack the hell out of the code just to keep the site running.  As a result, we had all kinds of ugly, server-specific hackery in production which just plain broke when we moved it back into devel.  And since, of course, we have a huge backlog of projects that management wants implemented, we've had no time to go back and reconfigure the development servers.

This week, I've been trying to test some changes to our user upload process.  However, due to some NFS misconfiguration and some code problems, uploads just plain don't work in our main development environment.  We do have a new, additional set of development servers (well, one box with a half-dozen virtual machines, but you get the idea), but I couldn't get those to work either.  Part of it was that the configuration on those servers was incomplete, and part of it was that Firefox sucks.  (Note from the present: I no longer remember why that was.)

Obligatory birthday post

It's that time of year again.  I always take the day off for my birthday (unless it's on a weekend, of course).  This year we did sort of a rerun of last year's birthday.  Except this year we went to Sonnenberg Gardens the day before and had a nice picnic at the beach for my actual birthday.

It was a nice, cool day for walking around the gardens.  (My wife always complains that I want to go there on the hottest day of the year.)  Sadly we're far past peak rose season, but the other flowers were looking pretty good thanks to all the rain we've had recently.

IMG_20210815_140134-small.jpg

Likewise, we had a very nice day for the picnic at Hamlin Beach.  It was in the upper 70's and sunny.  It was a little windy at the lake, but not unpleasantly so.  Zane and I played ball a little and went for a nice walk, but mostly we just laid on the sand and relaxed.  I brought my tablet and did some reading - I started Frank Herbert's Dune last week, and I've been blowing through it.

IMG_20210816_124215-small.jpg

And after the beach, we got some nice fancy cake slices from Phillips European.  I got the peanut butter torte.  Their stuff is always delicious and just buying it requires no work.  Also, I don't have to have an entire cake sitting around for the rest of the week.

So nothing fancy this year.  Just a nice, restful weekend with the family.  Which is all I really wanted anyway.

CoC for Vim

A few weeks ago, I was looking into Typescript a bit.  I've heard lots of good things about it, but never had a chance to play with it.  However, I got tasked with some updates to my company's portal site.  (While not technically my team's responsibility, the portal team was swamped, so I agreed to make the required updates to support a  back-end feature my team added.)  And, of course, the portal team uses Typescript.

Naturally, most of the editing recommendations for Typescript are focused on Visual Studio Code.  But I like Vim, so I did a quick search and found this article, which led me to CoC (which I choose to pronounce "coke", like the soda), which stands for the slightly ungrammatical "Conquer of Completion".  It's a plugin for NeoVim and Vim that essentially does Intellisense (code completion, context popups, etc.) using language servers.

If you're not familiar, the Language Server Protocol (abbreviated LSP, though that always makes me think of the Liskov Substitution Principle) was developed by Microsoft for VS Code.  It's essentially a way to make Intellisense work without the editor having to implement support for each language.  It does this by defining a protocol that "clients" like an editor can use to communicate with a "language server".  The language server is a stand-alone program that can provide code intelligence for a particular language, but is not directly tied to any particular editor.  The server can then be called by any client that implements the protocol, which means that the editor itself doesn't actually have to know anything about the language to implement advanced editing features - which is huge.

Anyway, CoC is an LSP client for Vim.  And I have to say, it's awesome!  I've messed with a few code completion and LSP plugins in the past, but I never really got them to work right.  They were either difficult to configure, or required Vim to be built with particular non-standard options.  But CoC was dead-simple to set up.  The only catch is that you have to install the language servers separately, but it turns out that's super-simple as well.  (The ones I've used so far can all be installed through NPM.)

I'm still getting used to it, but having CoC is a game changer for Vim.  I'd given up on having this level of intelligence in my editor.  I mean, for something that supports as many languages as Vim, building it the old-fashioned way just isn't feasible.  But when you can use the same language servers as more modern editors to do the heavy lifting, suddenly it's no longer crazy.

The next step is to look into the available commands and customizations for CoC and see what I can come up with to optimize my experience.  So far it's a pretty cool tool and it definitely makes the development experience nicer.  I want to see what else I can do with it.

 

Maniac Mansion on NES

Unlike most episodes of "From the Archives", this one is just going to be current-day commentary. This was supposed to be a "linkblogging" post from way back on February 22, 2006. (That was probably not long after I added draft support to LnBlog!) However, it only had three links and I no longer care about two of them.

The one that is still good is Douglas Crockford's account of The Expurgation of Maniac Mansion for the Nintendo Entertainment System. (The URL has changed since 2006, but but luckily Doug was considerate enough to keep a redirect. However, this publication date is a little misleading.) It's about the back-and-forth they had with Nintendo when trying to port Maniac Mansion to the NES.

I remember playing Maniac Mansion on the NES. I rented it from Video Entertainment, the video rental store in the next town over, several times. I never finished the game, but I remember liking it. I never played the PC version, but even the NES version was more than a little weird.

This article is Crockford's account of some of the odd things that Nintendo insisted they remove from the NES version. They range from silly to head-scratching. But if you've ever heard anything about Nintendo's approval process for NES games, you know that they were very strict about maintaining a certain image and so were very particular about what kind of content they'd allow. Either way, it's an entertaining read.