The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Thursday, Debtember 01, 2022

Minimum support for webmentions

I just now realized I've released a version of mod_blog during the holiday season going back as far as 2016. With that in mind, and with the fact that I finally received my first webmention on my blog couple of days ago, I have just released the latest version for this Christmas season. The big change this release is that I now show webmentions per post, even though I've only so far received one.

Hey, it's a start with the webmentions.

You can also see from the sidebar list I have, that I changed versioning schemes a few years back. I used to use semantic versioning but upon reflection, I didn't feel it's not really fit for applications and instead switched to a monotonic version number. While the code has changed dramatically over the past 23 years (come this Debtember 4th) the data format has not changed one bit. It's still the “one HTML file per entry, using the file system as database” scheme, which has worked quite well for me over the years.

Wednesday, November 30, 2022

Pink bedsheets, for very non-existant values of “pink”

The “pink” bamboo sheets finally arrived at Chez Boca. These are the ones I paid $325 for because we “stained” them acidentally with some bed clothes. Bunny and I are both puzzled over these, because they certainly don't appear pink in any meaningful, or unmeaningful, way. We looked at them in both dim light and exceedingly bright light, (thanks to some old-school 8mm movie lights I still have) and they look white to us.

Yes, there were a few spots on the sheets, that, maybe, could be pink? Or grey? A more accurate color may be “definitely not white,” but what color, exactly, is hard to tell.

So, there it is. $325 non-pink pink bedsheets made out of bamboo.

Woot.

Tuesday, November 29, 2022

Adventures in updating

Before I go to the trouble of installing the latest version of Apache, I want to ensure my updates to mod_litbook will compile on the lastest version of Apache. I've been developing it using Apache 2.4.38, a version from 2019 (and because I'm using mod_lua it's vulnerable to CVE-2021-44790). So I pull down the latest version (as of this writing, the latest stable version is 2.4.54) and start compiling.

I then got a compilation error about a missing field in a structure definition. Great! I think. Just how much of my system will I have to have to upgrade? I start investigating and find something odd—said field not only exists, it exists in the source code for Apache! The very codebase I'm compiling. Yet, for some reason, the compiler thinks the field doesn't exist.

At this point, I was reminded of Sherlock Holmes: “When you have eliminated the impossible, whatever remains, however improbable, must be the truth.” So the compiler must be picking up the incorrect header from somewhere. And “somewhere” ended up being the normal location of all system wide headers. The Apache 2.4.38 versions must have been installed such that such that one could compile Apache modules outside of the Apache source code directories.

It was a matter of identifying all such headers and removing them. Once I did that, Apache 2.5.54 compiled cleanly, along with mod_litbook, and it's now running fine on my development system.

So that's something else to keep in mind.

Sigh.

Monday, November 28, 2022

This update took a bit longer than I expected

I once mentioned updating mod_litbook to run under a later version of Apache. I wanted to do that because I've been running two instances of Apache—a later version that reverse proxies back to Apache 1.3 which just runs mod_litbook and nothing else, just to save me the agony of porting the code at the time. It only took me twelve years to locate the round tuit on my desk, but hey, better late than never.

I did do a mod_lua version of mod_litbook first, based on the version running on my Gemini server. With that (twelve years after I first played with mod_lua) and two hours of time, I was able to match the output from the original version (nice!). But it should be easy to update the actual mod_litbook source code to the latest version of Apache, right?

Right?

Yeah, kind of. it took two days, but I got it updated. I wasted the better part of a few hours trying to follow the instructions in the modules/examples directory which turns out to be laughably out of date. Once I found the proper guide things went much more smoothly—mostly function name changes and removing calls to obsolete functions. I also decided to go ahead and use the Apache Portable Runtime API instead of standard C functions as long as I was updating the code.

Now I just have to install the latest version of Apache on my server.

Just.

Yeah.

Friday, November 25, 2022

You can program functionally in any computer language

A few days ago I wrote a comment on The Orange Site that seemed to strike a chord there. The comment was about applying a few principles of functional programming in any language (well, maybe not BASIC from the 70s or 80s, but these versions of BASIC aren't used much these days). There's no need for functional application, functional composition, first class functions, monads, (“Monads! How do they work?”) or even currying. No, I feel like you can get about 85% of the way to functional programming by following three simple principles.

Don't use global variables

This has the biggest effect on programming and it's been a well known principle for a long time, even before functional programming was a thing. Globals make it difficult to reason about code, since some function elsewhere can make an arbitrary change to a variable that can affect code called later on (or “spooky action at a distance” as Uncle Albert used to say).

While no global variables is the desirable goal, I realize that it's not always possible to achieve and that threading global state through a program might be difficult, but it does make for an interesting excersize to attempt it. I recently went through the motions of removing all global variables from mod_blog. I've always wanted to reduce the number of global variables and in late August I felt it was finally time to do so (the fact that I was frustrated by the micromanagement style of the Enterprise Agile system that was being forced on us at work had nothing at all to do with the sweeping and rapid changes. Nothing at all <cough> <cough>). Yes, I had to snake a bit of state information throughout the code, but it wasn't nearly as bad as I thought it would be.

And as a side effect, it does make it easier to test individual functions as there is no more global state to worry about (although I do need to finish talking about unit testing at some point).

Treat function parameters as immutable

This is the extreme take. A less extreme take is “treat reference parameters as immutable.” If the language you use passes variables by value, then there's less need to keep the parameters immutable as they won't change data from the function caller's perspective. But reference variables? Or variables passed by pointer in C/C++? Those you want to treat as constant data as much as possible. This again, makes it easier to reason about a function as it will only work on the values given to it, and not change them (that “spooky action at a distance” thing again).

If you can't avoid mutating parameters, at least try to indicate any possible mutation in either the function name or it's signature to let another programmer know what to expect.

Separate I/O from processing

Of the three principles, this is probably the easiest to implement. Gather the data, process the data, send the results. And if you can't do so for reasons (like there's too much data to fit into memory) there are are a few methods to keep them logically separated, for instance:

  1. input as much as you can handle, process that batch, send it out, repeat;
  2. have the processing code call a (possibly configurable) function for input and output (admittedly, this may be easy or hard depending upon the language);
  3. get more memory.

Even if you don't need the flexibility of accepting different input or output methods, keeping the processing separate makes it easier to test the processing. Lord knows I would have loved it if “Project: Lumbergh” had a single entry point for dealing with the “business logic”—it would have made testing so much easier than it was (but that's no longer my concern).


So even if you can't switch to a functional programming langauge, that doesn't mean you can't apply the principles above and get most of the benefits of functional programming in a non-functional language. And the more that you can apply the principles above, not only will it make it easier to reason about code ina non-functional language, I think it will make learning an actual functional programming language easier. You might also want to read “Writing Video Games in a Functional Style. This is where I picked up on these principles in the first place (and it's sad that James Hague isn't writing anymore, but perhaps he said all he needed to).


Discussions about this page

Thursday, November 24, 2022

Check out this check mate on Gobble Gobble Day

My friend Smirk is a Chess fiend. I'm not sure how good he is, but he does like Chess and I've played several odd variations on the game with him back in our college days. As such, I think he would really love this chess variant played on a sphere. It's kind of mind blowing how the game changes and the check mate at the end is incredible to see. It's quite the mental challege on this day of tryptophan overdosing.

Have a great gobble gobble day everybody!

Wednesday, November 23, 2022

A rabbit hole of webmentions

Webmentions.

How hard could it be?

It's relatively straightforward, or so I thought until I started going down this particular rabbit hole yesterday. The first stumbling block is sending a webmention. The protocol itself isn't that tough—just send a POST to an endpoint with the URL of my post, and the URL of the post I mentioned and that's pretty much it. But the issue I have is that I tend to link freely. This one paragraph post has six links in it! When I exclude links back to my own blog, there are still three external links. Do I check each one? There are plenty of posts (like this one) where sending a webmention isn't something I want to do. So I'm having a bit of analysis paralysis on how exactly I want to handle this. For now, it's a manual process.

The second issue is one of handling incoming webmentions. I get the incoming request, I make a bunch of checks, then I have to actually fetch a web page and therein lies the hook—HTTP is rather involved these days, what with three separate and largely incompatible versions and TLS to contend with and … well, I have some stuff I need to update before I can do all that. So for now, my webmention endpoint will just accept requests and email me the information. Maybe if I see just how much this is used in the wild will inform me of how much work would be involved. I don't know.

Obligatory Picture

[It's the most wonderful time of the year!]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: http://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

http://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2022 by Sean Conner. All Rights Reserved.