Last week, Bunny and I ate at the Twin Dragons Grand Buffet (and if there was a website, I'd have linked to it). After dinner I checked my fortune cookie and lo:
This is the first time I've gotten a non-English Chinese fortune cookie fortune. Perhaps it says “Please savor your choosen bell appetizer” or something like that—I took German as a foreign language, not French.
Not much to report other than we made it home. I-95S in South Carolina was a horror show, what with a segment where it took us nearly an hour to travel 3 miles, and the I-95 exit to our house was closed off, but other than that, it was a long and gruelling trip.
The owners are new to the bed-and-breakfast business, having bought The Bromfield Inn just a few months ago (and after we had made reservations with the previous owners). The owners are a mother and daughter team, and thus, I will refer to them as Mother and Daughter. Mother lives on site and currently manages the inn, while Daughter is still in Florida closing up her real estate business there.
Anyway, as Bunny wrote in a follow-up email to The Bromfield Inn:
- Bunny <XXXXXXXXXXXXXXXXXXXXXX>
- The Bromfield Inn <XXXXXXXXXXXXXXXXXXXXXXXX>
- Re: Thank you for your stay
- Thur, 3 Nov 2022 16:01:00 -0400
We did indeed enjoy most of our stay at your beautiful inn. However, we will have to seriously consider our options for future visits. The deal breaker is the lack of heat in the room. Neither of us is wired for being cold, and we were very cold most of the time. Except when we were in a hot, steamy shower! I would imagine that even in July, the temperature on our floor would be set for A/C, 70 degrees [21°C —Editor] or so, which would mean we would have the same problem then as we did in October. Not sure this is a good fit for us.
Other things include the lack of access to a microwave to reheat what we would bring home from our dinners. We also use a great deal of ice every day for our water and soft drinks. You have no ice machine for your guests. That matters to us.
Our suite was lovely, especially the dressing room area and the roomy shower. However we would trade all of that for temperature control in our room. We have never stayed anywhere in our 15 years together where we could not control our room temp. We were quite surprised. We would not have decided to stay at your inn, had we known there was no heat in the room. It never entered our minds.
We appreciate your proximity to downtown, and Sean enjoyed sitting outside by the fountain, as long as it was sunny. As soon as the sun went behind the trees, he came inside. It was lovely for him to be able to have his bi-weekly game at your dining table in front of the fireplace. Heavenly. But you can see the problem. He was comfortable by the fire. We aren't wired for these temps, and we acknowledge that people come to Brevard precisely for these cool days and nights. We are the exception. We realize that. But, again, we have never experienced a room with no heat.
Mother's hospitality was beyond belief. She is a jewel. We tried to work with her as much as possible. You probably don't have many guests who spend most of their visit in their rooms, and we tailored our activities to correspond with her schedule whenever we could. We especially appreciated that she printed my NYT crossword puzzles.
We will keep you in mind! Thanks, again!
Bunny and Sean
Bunny felt bad about not wanting to stay there and felt it necessary to info The Bromfield Inn as to our decision. Explanatory feedback like this is more important than a good review. For someone to take the time to write about the difficulties shows they really care about the service (or stay, or product or whatever). How you reply to such crticism is important. For example, this is not the reply you want to send back:
- The Bromfield Inn <XXXXXXXXXXXXXXXXXXXXXXXX>
- Bunny <XXXXXXXXXXXXXXXXXXXXXX>
- RE: Thank you for your stay
- Fri, Nov 4 2022 09:47:45 -0400
So sorry to hear this. Maybe Key West, FL temperature would be better for your trips and an air bnb seems more to your style.
We follow hotel industry standards to keep a building temperature with multi-guests. We set our units at 70 degrees [21°C —Editor] in the winter and 76 degrees [24°C —Editor] in the summer months. The U.S. Department of Energy suggests thermostat settings be 68 degrees F [20°C —Editor] or lower in the winter and 78 degrees F [26°C —Editor] or higher in the summer. I know everything was done to keep you and Sean comfortable. We have rooms that have fireplaces so that might be an option as well.
We won’t ever have microwaves in any rooms or common areas. The smell of food thru out the Inn that is not controlled via our kitchen isn’t something other guests want to experience. We also don’t want to attract ants, etc. from food being in the rooms.
Unfortunately, on our end, you had a red pj set that bleed on to our sheets. Our sheets are bamboo and a set costs $325, which I will need to charge back to you. Let me know if you have a different credit card you want charged? I am happy to mail you the now pink king size sheet set but clearly they can’t be used anymore.
The Bromfield Inn
Bunny took offense at the Key West line, and was livid at the addtional $325 charge for the ruined bedsheets (an accident, and certainly was not intentional).
I realize that it may be difficult and expensive to retrofit a house to have separate climate control for each room, but even at The Red House Inn (another formerly private residence turned bed-and-breakfast) they were able to provide us with some spot heaters to take the edge off the temperature. And they had ice.
Also not mentioned was the one-ply toilet paper. At the prices we were paying to stay there I would have expected better, but I'm sure that it too, was “hotel industry standards” to use such rolls. If you are going for an up-scale ambiance, it's a weird thing to pinch pennies on.
Suffice to say, we won't be staying there again, and we won't be recommending it to anyone either. Sad, because aside from a few issues that could be easily addressed, it is a nice place.
It's political season. Not to be confused with deer season (or rabbit season, or duck season or even gator season, much to the dismay of many). And it's the second Tuesday of November on an even year, so it's also Federal political season.
The sun was out, the weather was cool (for Florida, which means the asphalt is only slightly soft from the heat) and as usual, I walked to the polling station. It wasn't crowded at all and it only took a few moments to fill out the ballot.
And while this should mean I no longer get SMS from politicians slinging mud at each other, there are still a few days of dire SMS warnings about the end of the world.
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.
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.
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!
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
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>).
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:
- input as much as you can handle, process that batch, send it out, repeat;
- have the processing code call a (possibly configurable) function for input and output (admittedly, this may be easy or hard depending upon the language);
- 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 entry
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,
better late than never.
I did do a
mod_lua version of
based on the version running on my Gemini server.
(twelve years after I first played with
and two hours of time,
I was able to match the output from the original version
But it should be easy to update the actual
mod_litbook source code to the latest version of Apache,
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.
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,
and it's now running fine on my development system.
So that's something else to keep in mind.
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.