If I were to list the reasons that I can still maintain CoasterBuzz and PointBuzz, it's not the part where I fanatically tried to make the performance of those sites high. The top reason is that, after 20 plus years, I've never let them get too crusty. The amount of change in the underlying technologies is pretty staggering, with endless frameworks and platforms along the way. I never thought it would all run on Linux now, let alone on virtualized everything.
I took a break at the start of the year from recreational coding. I haven't written code at work in quite a few years now, and really it has been intermittent at best in the last ten years, because I've done more managing and "architecting" (whatever that even means anymore in software development) than anything else. But I actually enjoy it when I'm not being held to some kind of delivery, and I do think it lends credibility to you in the eyes of people you lead.
This year, I'd like to finally shake the forums free of their ancient jQuery dependencies, which is obtainable now because Bootstrap, the base style framework I use, has also ditched it. Later this year, .NET, the platform I've been leaning on for the backend for most of the years (with many frameworks on top of that), will turn to v6, a consolidated, run-everywhere version, and I'd like to get everything up to speed there. Most of what the sites ran on two decades ago has long since been deprecated and isn't supported, and I've seen at many jobs what happens when you don't keep up. The code gets super crusty, and no one wants to update or maintain it. I did go almost four years between updates to PointBuzz once, and that was pretty painful.
For all of the change, there is one strange thing that has never changed: I've been using SQL Server as my database the whole time. It has changed over the years, but the data itself has barely changed. There are other persistence technologies at play since then, of course, including Redis, ElasticSearch, Azure queues and storage, and probably other things, but there's still SQL under there. It's pretty flat in terms of schema, so that may be why it has mostly aged well.
That said, we went through a period in .NET circles where we tried to use object-relational mapping frameworks to abstract away all of the SQL. For me, it started with flirtation, something called LINQ to SQL, which translated method chains into queries. There were others, too, including NHibernate (we inherited its use on the MSDN Forums at Microsoft, and it was a mess). The thing that really started to catch on though was Entity Framework, I think in 2010-ish. And within a year, they added what they called "code first" support, meaning that you could define your entities in code, then let EF turn it into a database schema, along with magical schema updating.
Here's the problem with ORM's: They're leaky abstractions. There just isn't a universe where you can get away with not understanding what's going on under the covers. If that weren't enough, the various control libraries that started springing up "worked" with EF to do things that maybe you didn't expect. I inherited a project once where one of these tables aggregated totals three different ways, which resulted in total scans of the database every single time someone viewed the page, which is bad. But the biggest problem is that these frameworks inevitably produce queries that are inefficient when your data set gets large. For that reason, you end up trying to tweak your code to get the underlying queries to be better formed, which leaves you in the place where you're better off just using SQL directly, which has barely changed in decades.
Getting back to my sites, CoasterBuzz is using EF to this day, and I hate it. The worst part is that when .NET went full open source, with the "Core" moniker the last half-dozen years, EF changed significantly and in breaking ways. I played along and figured out all of the things that broke. What a waste of time. There is so much awkwardness in the code. My little project this weekend was to purge it all, and I got about 80% of the way there.
There is a useful level of object mapping though. For a number of years I've been using Dapper in various projects, which maps your query results to objects, and objects to parameters. I even adopted it in the forums a couple of years ago. I love me some Dapper.
I wanted to get the crusty stuff out so I can enable a few new things, and this will make life easier.
No comments yet.