Farewell 2024 Pool Season

Looks like pool season is over for the year. My final swim of the season was September 21, 6 days later than 2023’s final day and 6 days earlier than 2022’s. This year came in third since 2021 in total swims (74), second in total strokes (52,564), and first in average stokes per session (710). This will be the third straight year with no swimming in the month of October. Like last year, the culprit was the onset of a multiple-day period of overcast, humid, drizzly weather. Almost every September features a stretch of this kind of weather, which is why October swimming is so rare around here. Hope springs eternal for next year, though.

I have to figure out how I’m going to winterize the pool this year with the new pump. I plumbed it with unions to give me the option to remove it and store it inside for the winter. However, the wiring will likely make this somewhat of a pain. I may still try it, although I may hate myself for it next spring. I figure I have until around the second week of November to decide, as that’s when I usually finish winterizing the pool. I’m hoping to get the winter cover on it this weekend or shortly thereafter.

After starting it a few months ago, I’ve finally got all of my web infrastructure moved out of AWS RDS, and I shut the RDS instance down this evening, with the intent of deleting it if I don’t see any issues. Also, I’m in the process of switching domain registrars for lpaulriddle.com. When I initially registered the domain (at least 10-15 years ago), I used Yahoo! Small Business, and while slightly pricier than GoDaddy, I was happy with it until it ended up morphing into Turbify. Last year, the registration renewal fee jumped to $45, and this year, they wanted $55, which was enough to motivate me to switch. After some research, I settled on Cloudflare, and the transfer is now in progress, with a pending completion date of 9/29. In the meantime, I moved the DNS over to Cloudflare, which went off without a hitch. If all goes well with moving the registration, I’ll probably move my other domain (currently at GoDaddy) to Cloudflare as well. I’m not doing much with that domain, but I do have email forwarding set up for it, so I’ll need to figure out how to do that with Cloudflare. I will say that their registration fees are much cheaper than GoDaddy’s, let alone Turbify’s.

Edit (9/29) just in case it’s helpful to someone: I got a confirmation email from Turbify/Tucows a few hours after initiating the transfer with Cloudflare. It said that if I took no further action, the transfer would complete at 2024-09-29 01:30:17 UTC. That time came and went and nothing happened, so I revisited the email and noticed that there was also a link to “visit our website” at the end. I clicked the link, and it took me to a page with options to approve the transfer immediately or cancel. I clicked the approve button, and the transfer completed a few minutes later (verified by an email from Cloudflare). Not sure if it would have eventually happened automatically had I not done that, but it’s done now, and reflected in WHOIS. Now to go cancel the Turbify plan…

Swim Notes

I just finished moving the database for this blog off AWS RDS and onto a MariaDB Docker container with the database files hosted on EFS. RDS turned out to be overkill for my use case, and it was costing me more per month than I had expected. By contrast, EFS storage space is cheap, and the EC2 instance I’m running MariaDB on is free until the end of 2024. The trade-off, of course, is that it’s almost surely not going to be as performant as RDS, although I’d be surprised if I notice any difference. We’ll see. If I do, I can always try something like a persistent object cache and/or page cache.

I also wanted to write a quick note about swimming this season. It’s been a good season thus far, and the hot summer has led to a lot of time spent in the pool. As a matter of fact, according to Apple Health, I’m only 7 or 8 swims away from eclipsing last year’s total, and we’re only halfway through August. The best times of day for swimming are mornings before 9:00, and afternoons after 4:00, because that’s when the pool is out of full, direct sunlight. On really hot days, I’ve occasionally done pool running in the mornings in lieu of “real” running, as I have a hard time getting over 3-4 miles on really hot, oppressive days. Most of my swimming has been in the afternoon and evening, with a tether, same as in recent years. In July, I typically swam in the late afternoon before dinner, but this month (August), I’ve been swimming more in the evenings, sometimes going as late as 9:00pm. Usually, I do 3 sets of 60 breast stroke, 60 front crawl, 60 butterfly, and 60 backstroke, for a total of 720 strokes, which takes me about 40 minutes. I’m happy with how my backstroke has progressed this year — I first started doing it regularly about midway through the 2023 season, and it felt awkward and uncoordinated for quite a long time. Lately, it has improved quite a bit.

As with every year, the end of the pool season can be a wild card depending on the weather. In 2022, I was able to swim until October 4, but last year, a persistent bout of cloudy, cool weather brought things to an early end on September 14. We will see what this year brings. We set the record for latest day in the pool (October 9) in 2007, and it still stands. I wonder if it will ever be broken?

lpaulriddle.com re-architecting

I needed to get lpaulriddle.com moved off an old EC2 instance running Ubuntu 16.04, which has been EOL since 2021. About a year ago, I started the process by moving all of the services to Docker containers. Then I moved all of the persistent data (web pages, images, etc) to a EFS filesystem, and I moved my MariaDB database to RDS. After that, I kind of forgot about it until just recently. I saw that AWS was doing a promotion for its new t4g.small instances for 750 free compute hours per month through 2024, so I spun one up and worked on moving the services over. It went more smoothly than I had expected. This is what I did:

  1. Installed Docker and docker-compose on the new instance
  2. Tweaked AWS security groups to allow the new instance to mount the EFS filesystem and connect to the RDS database
  3. Copied my Github ssh credentials over to the new instance
  4. Cloned my Git repo to the new instance
  5. Copied secrets (.env) into the git tree
  6. Built all of my images (docker-compose build)
  7. Started containers (docker-compose up -d) – I actually did these one at a time, but this would have worked as well
  8. Tested everything out by modifying my /etc/hosts file
  9. Disassociated my elastic IP address from the old EC2 instance and assigned it to the new instance

This all went off without a hitch, and everything seems to be working. Functionally, the new instance is ARM vs x64, and the OS is Amazon Linux 2023, which is yum based, vs Ubuntu, which is based on apt/dpkg. This post will serve as a test that I can create blog posts using the new infrastructure.

Next, I think I’m going to move my database off RDS and back onto a MariaDB container with the database in EFS. RDS has turned out to be a little bit pricier than I had expected, and I think it’s overkill for my rather modest needs (basically a single WordPress blog and a MediaWiki instance).

This and That

I’m trying a new WordPress theme out. I had been using “Twenty Twenty” for a long time, but never liked that it didn’t have a widget sidebar. So, I’m trying one out called “Simple Life”. It’s responsive, has a sidebar, and seems fairly lightweight, without a lot of bells and whistles and other stuff I don’t need. So, I’ll probably use it for a while until I get tired of it.

As promised yesterday, I brewed a pourover cup of my medium roast Mexican coffee beans using 18 grams of coffee to 250 grams water (around 1:14) and it was just about the perfect strength. It did have a tiny touch of bitterness that I didn’t notice yesterday, but I think that was because I wandered away and let the coffee sit and drip for a little too long. I’ll fix that tomorrow, and if it’s not perfect, I’ll try it just a tiny bit coarser.

I did my usual Friday morning session at the climbing gym today, and felt pretty good after climbing 8 routes ranging from 5.10- to 5.11-. There definitely is a huge difference in my energy level between my morning and evening climbing sessions. I suspect part of it is because I typically commute 22-25 miles on the bike on the same days as my evening climb sessions, with the 8-mile homeward leg wrapping up an hour or so before I leave for the gym. Something probably needs to give there…

Run Notes

It’s another very un-summer-like day here in central Maryland, with clouds, mist, and temperatures in the low 60s on the day after the solstice. I actually wore long sleeves for my morning run. I ran 6.8 miles, which is a pretty typical distance for me on a work day. My overall pace was around 10:30/mile, which also is about average for me. The first half of the run was great, but the second half felt like a struggle. I’m wondering if I started out trying to run too fast, which has gotten me into trouble in the past. My next run will likely be in two days, and I’m hoping to go 9 miles or so at a more relaxed pace.

My work to move the blog (and a couple other web sites) off my old EC2 instance is moving along. I’ve now moved all of my persistent Docker volumes onto an EFS volume, so there is no more persistent data stored on the EC2. Next step is to start moving containers into EKS/Fargate. I find it kind of amusing that, behind the scenes, the EC2 instance uses NFS to access the EFS volume. As someone who administered systems running NFS back in the 1990s, I remember it as a buggy, insecure system built on Sun RPC. Apparently, though, it has improved in the ensuing 30-odd years. At any rate, it seems to perform pretty well over a AWS VPC connection, at least for my purposes, which aren’t all that demanding.

Anyhow, that’s more than enough acronyms for one post. 😀

Today’s (cold) brew notes

  • Beans: German St Coffee & Candlery Private House Blend
  • Coarse grind (JX: 3 rotations + 4 clicks / 94 total clicks)
  • Recipe: https://www.acouplecooks.com/french-press-cold-brew
  • 140 grams coffee (roughly 2 cups ground), 840 grams water

With summer upon us, I decided to try making some cold brew. The hardest part of this was grinding 140 grams of coffee with the JX. This job would be better suited to a higher capacity electric grinder. Other than that, there’s not much to it: just add the ingredients to the french press, stir, cover with plastic wrap, refrigerate for 24 hours, and strain into a glass jar or pitcher. The resulting brew is concentrated, and the recipe recommends diluting 50/50 with either water or milk. I tried it with milk, and it was pretty good. Now, I need to work on trying to get a good cup of regular hot brew with these beans, but that’s for another day…

On an unrelated note, I just moved the back end database for this blog to a AWS RDS MariaDB instance. It had previously been running in a MariaDB Docker container on my old EC2 instance. This is the first step to getting my stuff off the EC2 instance and into (probably) EKS with Fargate. If you’re reading this, it means that it worked. 😀

I’m baaaack..

A few years back, I set lpaulriddle.com up on Ubuntu Linux running on a AWS EC2 instance. It ran just fine there, but to be honest, was kind of a mess. I was dreading the day when I would eventually have to update it or move it somewhere else, because I didn’t document anything that I did while configuring it, and thus, it would take forever to get everything working again.

Last summer, I decided to bite the bullet and redo everything on the site to run in Docker containers. That way, I’d have a repeatable build/deploy process that I could easily move around independently of the underlying support framework, be it ECS, another EC2 instance running Docker, or whatever. It’s still a work in progress, but it’s inching closer to completion. One of the first things I did was to move the MariaDB instance that hosts this blog’s database tables, into a container. This worked mostly OK: the blog still rendered just fine, and I could click around and read all of the posts the same as always. However, when I logged in at /wp-admin, It gave me a permission error, and I could not get to the dashboard. That effectively locked me out of the blog, preventing me from writing new posts, among other things.

About 4 months later, I finally got around to fixing it. Since I planned to move WordPress into a Docker container anyhow, I decided to start over with a fresh database, and just import all of my original blog content into the new instance. The catch was that I needed to somehow get into my old instance one last time to export the data. After some searching around, I found a snippet of PHP that I could add to my theme to bypass the permissions checks. That did the trick: I finally got back in, exported the data, and brought everything back up in a new, shiny Docker container. The blog is now powered by a Nginx front-end that talks to WordPress over a FPM proxy. Fun stuff.

Now that I can post again, I’ll try to write some more as the spirit moves me. As you can imagine, 2020 has been an interesting year with some pretty big changes to my daily routine.

Blog administrivia

OK.. figured out a somewhat better solution for links to blog posts. Use relative URLs, and use named permalinks. Then, I should be able to move the blog in the future without breaking self-referential links (providing that the new blog either runs WordPress or can support WordPress-style permalinks). I still need to go through and update all my old links, which looks to be a tedious process, but with any luck it’ll be the last time I need to do it.

I discovered the other day that it doesn’t work to set up a CNAME pointing to ‘lpaulriddle.wordpress.com.’ I just end up getting sent to the main wordpress.com homepage. Using an HTTP redirect (or meta refresh) seems to work. However it doesn’t appear that I can set up a redirect with my current domain hosting provider, at least not without signing up for web hosting that I don’t want. However, I’m going to be shopping around for a new home for my domain within the next couple months anyhow, so I’ll check into this as I’m evaluating new providers.

Blogging again…

Hopefully I’ll pick up the blogging pace a bit now that I’ve moved everything over to wordpress.com.  In preparation for un-password-protecting the blog, I’m going through all of my old posts, and the only thing I’ve noticed is that all of my links to other blog entries are broken.  Nothing unexpected, but I wonder if there’s anything that can be done to prevent this from happening every time I move the blog (it’s moved 3 times now, and it’ll probably move again).  Probably not, but right now all my links reference posts by number, and it might help to change them to use named permalinks.

My latest pet project at home is preparing us for the impending cutover to digital TV.  We’re far too cheap to pay for cable or satellite TV (although FiOS may be hard to resist), so I’m concentrating on getting a nice setup for receiving over-the-air digital broadcasts.  Following some instructions I found on the Internet (where else), I built two homemade UHF antennas.  The author of this web page uses a single antenna with a rotator.  At our location, though, we’re smack-dab in the middle of the Baltimore and DC TV markets.  So I can set 2 antennas up in the attic, one aimed at Baltimore, and another aimed at Washington, and pick up pretty much every station within 50 miles, without the hassle of a rotator.  The only issue is combining the signals.  The antennas work great separately, but I haven’t tried using a combiner yet (I try to avoid going up in the attic this time of year..).  Using a combiner in this kind of setup is always going to result in some signal loss, so the question is, will the resulting combined signal be acceptable?  I don’t know, but it’s easy enough to try, which I plan on doing soon.  If the combiner setup doesn’t work well, the other option is to run separate antenna feeds to each TV and then use a switch similar to Radio Shack Cat. No. 15-1968 (each TV would need its own switch).  I know this will work, but it obviously involves extra work and expense.  But it’s still preferable to a rotator, IMO.

Sort of on the same topic, I picked up one of those much ballyhooed digital “converter boxes” awhile back, to use with our old TV.  Total outlay was just over $20, thanks to the $40 coupon from Uncle Sam.  This is an Apex model that is being sold at Best Buy.  It works as expected, and includes all the standard features you would expect from a digital tuner (TV guide, signal strength meter, etc).  However, I kind of wish it had come with a universal remote.  The included remote control works fine, but it’d be a nice touch if I could also turn the TV on/off and adjust the volume with it.  As it is now, I’m stuck with 2 remotes until I can find a cheap universal remote that can also work the converter box.

More later..

That was easy…

Searching for a new home for my blog (and didn’t want to pay for web hosting, at least not yet), and it came down to wordpress.com vs blogger.com.  Blogger.com had the early edge because it works with my existing Google account, and offers free domain name mapping.  WordPress.com charges a nominal annual fee for domain name mapping, and requires a separate account.  However, Blogger.com didn’t have an easy way for me to import my existing WordPress blog.  With wordpress.com, it was as simple as exporting the old and importing the new, and everything came in completely intact.  Other than the URL, I can’t even tell the difference between this and my old self-hosted WordPress blog.

There’s also the question of whether I need domain name mapping in the first place.  It’s not like I expect this to be a high-visibility or high-traffic blog.  I think I’ll just set up a CNAME for this under lpaulriddle.com, and be done with it.

In any case, looks like I’ll be setting up shop here for awhile.