From August 2011 until today, this site has been running under WordPress. During this time, we have done many experiments with several other blog platforms, but none of them made it to the “import all the old stuff from this one - this is what we're looking for!” stage. As you may have already guessed, though, this is no longer the case. WordPress does what it does very well. However, the last post before this one was August… of 2014! That means that, every page served from this site, a script was run on the server that accessed a database and dynamically assembled the page. This content did not need to be dynamic - even when there is a new post, there is very little in the way of dynamic content here.

Jekyll is a static site generator; these types of applications generate static sites based on a collection of templates and content files, that can then be served with no backing data store. Now, we can utilize the blazing fast nginx web server to push these files as quick as people can request them, where the request does not even have to escape the process.

There will be more to come on Jekyll; there are at least two posts to be written, one on automating the build process and another on the migration from WordPress. Until then, though, there are redirects that ensure the RSS feeds for both the main blog and the xine RPMs require no changes, and the category pages have redirects as well. If something does not look right, let us know via either of the social media accounts linked above.

The WordPress plugin for the 40/40 Prayer Vigil has just been published! You can download it from your plugin menu, or by visiting its home on the WordPress Plugin Directory.

The plugin provides a widget that utilizes the web service about which we previously wrote to display the prayer guide for each day. You can configure whether you want it to display 40 days or 40 hours; what language to retrieve; the translation version for the Scripture links displayed with each day's guide; and the number of overlap days (it will display a “Coming Soon” entry before and a “Thanks for Praying” entry after). Use is pretty simple; just drop it into a widgetized area of your theme. It will probably look best with at least 200 horizontal pixels, although it will wrap to any sort of narrowness.

Version 2012.0 is the version that's up there now. The Spanish translations of the options menu is not done yet, but you can specify Spanish prayer guides. Version 2012.1 will contain the localized options menu. If you run into any problems using it, you can submit issues against it at its WordPress Plugin Directory page.

After a nearly four-year run at version 2, the HCSB Verse of the Day plug-in has been updated to version 3. The latest version available is 3.0.1, which contains a quick fix that was found just after I had released version 3. When you see that “.0.1,” just think, “Oh, this was written by a human!”

Major changes in this version include:

• The addition of “(Plus)” to the name, as this version supports five different translations - in addition to the Holman Christian Standard Bible (HCSB), it now supports the English Standard Version (ESV), the New King James Version (NKJV), the New International Version (NIV), and the King James Version (KJV).
• A new settings page, where you can select the version.
• A widget, that will drop right in any widget zone.
• The replacement of several function calls that have been deprecated in the WordPress API over the past 3 years and 8 months.
• Formal dropping of support for PHP 4, following WordPress's lead in 3.2.

While a lot of the code is different, if you only used the template tags, you should notice nothing different with this release. You can download HCSB Verse of the Day (Plus) 3.0.1 at the WordPress Plug-In Directory, or upgrade on the WordPress Plug-In Administration Page in your blog.

After a little over a year running on Tech Blog 2.0, you are now viewing version 3.0. For this version, we've returned to WordPress from BlogEngine. There are several issues that colluded to drive this change, most of which surrounded PHP and its crazy behavior. (Geeky details follow - skip to the paragraph starting with “Bottom line:” if you don't want the geek stuff. I bolded it so it would be easy to spot.)

PHP's recommended configuration is to run under Apache using the pre-fork multi-processing module (MPM). The advantage to this is that Apache does not have to spin off another process to handle each request; it handles it in the same thread. However, this means that each instance of the server must have all enabled modules loaded. This means that each instance of the server (AKA “thread”) is very large, so the number of threads run is lower (typically 5-15 in a server the size we're on). Also, this means that each thread can only handle one request at a time; if you have 7 threads configured, each serving one of 7 requests, and an 8th request comes it, it has to wait for one to finish. If the requests are served quickly, this may not be a problem; however, the avalanche of request that follow the typical front-page mention on mega-blogs can easily overwhelm it.

To fix this problem, there is another MPM, this one called worker. In this scenario, there are spare thread waiting to fill requests, and these can spawn other threads to do further work if required. So, the Apache threads would realize that a request needs to be handled by PHP, and pass it off to that process to be completed. The Apache memory footprint is much smaller; it serves the images, scripts, and other static files, and passes off the requests that require heavy lifting. PHP, then, has a (FastCGI) process where it receives these requests, processes them, and returns the response to the caller. Because each of these threads only has to load the PHP requirements, they are smaller too, so you can have more threads processing at the same time; you just might survive that front-page mention! (This is the same technique applied by LightTPD and Nginx, two other servers I tried at various times.)

It is in this scenario where PHP fails to live up to its expectations. These PHP processes would simply stop responding, but the controller thinks they're still there. The end result to the user is a site that just sits and waits for output that will never come. Eventually, they may receive a Gateway Timeout or Bad Gateway error. The problem is worse on slower sites, but even popular sites seemed to fall victim to this from time to time. This was also a problem whether PHP controlled its threads, or Apache controlled them.

The one thing that really perturbs me is instability. If something is broken, I can fix it; if it works, I can fix it 'til it's broke. :) But something that works sometimes, and other times doesn't, simply won't fly. I was able to introduce some stability by restarting the server 4 times a day, but that's a band-aid, not a long term solution. I was tired of fighting.

Bottom line: the configuration required for a stable server is in opposition to a lean-and-mean configuration. So, I installed the required Apache modules, and will continue to run my PHP-serving server at a configuration twice as large as it needs to be. I'll eventually move the Mono (.NET) processes to another machine, where the fast configuration won't cause stability problems.

But, PHP isn't all bad. While I would still heartily recommend BlogEngine.NET to someone who was going to serve the blog from a Windows machine, but I had some issues getting upgrades to go smoothly under Mono. It also is optimized for fast serving, at the expense of RAM. At this point, that's not the tradeoff we need.

Finally, with this update, the blog has received its first new theme. It's a clean, clear theme that should serve the content well. Plus, the social media icons up in the corner are just too cool, IMO. I've also applied tags to all posts except the “My Linux Adventure” series, and this theme displays them. (Comments are not here now, but will be migrated shortly.)

So, there you have it. Enjoy!

After three years on WordPress, The Bit Badger Blog has moved to BlogEngine.NET. There are several reasons for this change, some technical and some not.

• PHP's Fast CGI processor has a problem where, if all of the processes are busy, the server will simply time out. While this hasn't afflicted my server as much as others, it has caused problems; when this problem occurred, none of the PHP sites were accessible.
• Through experience with a very heavily-used site, I became less enamored of WordPress's “read from the database every time” way of doing business. I also found that various caching plug-ins for WordPress, on this particular site, did very little to ease the load.
• Since I first looked at Mono (Linux's implementation of the .NET framework), it has matured significantly. It supports most of C# 4.0 already, which was released earlier this year.
• BlogEngine.NET is a rapidly-maturing blog platform, and the project has a stated goal of 100% compatibility with Mono. This is good, because you can mention Mono problems to the team, and you're not dismissed because you're running Linux.

As part of the move, the URL has changed; the new link is https://blog.bitbadger.solutions. I have implemented redirection for each post, the category and category feed links, and the main blog feed and home page from the old URL, so you may not have even realized that you're looking at the new site. The Bit Badger Solutions Software Repository remains at https://hosted.djs-consulting.com/software/.

I'm looking forward to this new setup!

(NOTE: The next-to-last paragraph was updated with correct links as of February 2017.)

Version 2.1 of Daniel's DropDowns has been released. This fixes a problem introduced with the 2.5-series of WordPress - the output of the WordPress tag changed, so the search-and-replace portion that added a “Select Category” entry didn't work. This has been fixed in version 2.1. I also corrected a small bug that caused the first entry in the category list to be selected if a default wasn't specified.

It can be downloaded from the WordPress Plug-In Directory. Enjoy!

(UPDATE: This plug-in is inactive, as its functionality is now part of WordPress core.)