Information can also be found at these pages: and are hosted at on shared servers where each server hosts dozens of websites that are owned by others. The sites use the Apache web server.

I’m using Amazon Web Services to manage I bought the domain name through AWS, and I use Route 53 to manage DNS. For the server, I created an EC2 instance, which uses the Nginx web server, and it hosts one of my web publishing apps. After creates and updates, my app copies files to an S3 bucket. I use CloudFront for edge caching. If an HTML file is not cached, then it’s retrieved from S3.

All of my other projects are hosted on a Digital Ocean virtual server Droplet. For these sites, I also use the Nginx web server. I purchased most of my domain names through Network Solutions.

I use Linux at all three hosting providers. and Grebe

Baby University is a non-profit that helps families in South Toledo prepare their children for school. I built its website, using a customized version of my Grebe app.

I also use Grebe to manage my blog sites and

Grebe uses a REST API. I created “client” versions in Node.js and Perl.

Grebe uses MySQL, and optionally, the homepage and each post that was created and updated gets stored in Memcached to speed up access.

For the Baby University website, I use Google Apps for Work (now called G-Suite) to create custom email addresses that use the domain name.

ToledoWX consists of numerous small programs that execute in batch. These scripts access XMl, JSON, and HTML files, produced by the National Weather Service. The program also consumes JSON data, offered by, using their simple API. ToledoWX uses jQuery mobile to format the simple HTML pages.

My phone contains the Yo app. I receive notifications on my phone, regarding heavy precipitation, by combining data with the Yo API. For this simple notification setup, I rely on my ForecastIO and Yo modules.

In the fall of 2017, I created a Flash Briefing Skill that is read by Alexa on Amazon’s Echo smart home speaker. An HTML version of the briefing exist, and it can be accessed from the homepage. For Alexa, the ToledoWX code creates a JSON feed that uses info culled from other ToledoWX-related pages.

Soupmode and Kinglet is a private, web-based messaging app that I use mainly to communicate with family members. Soupmode Help page.

Soupmode uses SSL. In 2014 and 2015, I acquired free certificates from In 2016, I acquired the certificate from Let’s Encrypt.

Soupmode was built with my Kinglet code, which uses a REST API. The app is part microblog, part e-mail, and part message board.

Messages can be sent and received to users who have agreed to be on each others’ approved list. A user can reject another user’s request to be added to the approved list. Users can start new message threads that involve only one other person or several people.


Waxwing is an image uploading website that offers a stream view of posts with tagging and searching. I wanted a simple way to upload photos from phone and desktop/laptop where I can then embed the photos within a blog post.

Client-side JavaScript reduces the image size to a max of 640 pixels on either the width and/or the length, depending upon which one is the longest. The resolution is reduced some too. This descreases the size of the image, which leads to a faster upload.

The images are stored on the server’s file system. Other info related to the image post is stored in CouchDB. Hashtag search exists, using a view that’s added to CouchDB. Elasticsearch provides the string searching.

I use Waxwing at Another Waxwing install is attached to Soupmode for private usage.


Junco is as a web-based community app with social features, such as following users, following tags, and replies. It can also be setup as a personal publishing site. Junco also contains wiki-like features.

Junco can be configured to display a stream view or a blog view on the home page. Junco maintains a version history for each updated post, which allows for diffs and reverting to an old version.

Junco supports Textile, Markdown, and MultiMarkdown, and it contains the most custom formatting options of any of my web publishing apps. Each web publishing app that I have created since contains a smaller set of features.

Junco powers, but it’s used as a personal publishing site and not a community site. The test site exists at


Scaup is a small, single-user web publishing app. Posts are displayed in a stream views by updated date. Long posts are automatically truncated for the stream views.

When logged-in, a small text area box exists at the top of the site to allow fast posting of articles, notes, and links. This was my first attempt at using a NoSQL database. Scaup uses CouchDB.

For string searches, it uses Elasticsearch. Post pages and the homepage are cached with Memcached.

A test site exists at I use Scaup to store my crochet notes at


Veery is similar to Scaup. It’s a single-user web publishing app where the home page is a stream view of articles and notes, sorted by updated date. It also uses Memcached.

Like some of my other projects, Veery uses a no-password login mechanism. Only an email address is submitted, and if it matches the author’s info stored on the server, then a login link is emailed. The author only needs to click the link to activate a login session.

Instead of remembering yet another password, the author can focus on securing the email account. My apps that support a no-password login rely on the MailGun service to send the email messages.

Veery also uses CouchDB and Elasticsearch. But Veery differs from Scaup by containing an API.

Veery client versions exist in Perl and NodeJS.

API versions also exist in Perl and NodeJS.

Test sites:


Wren is a lightweight, web publishing app that does not use a database. It’s a static site generator. It stores markup in plain text files, and it creates static HTML pages.

At the moment, Wren is a single-user tool. Wren is API-based, using REST and JSON.

Most of my web publishing apps support Textile and Markdown/MultiMarkdown, but Wren only supports Markdown/MultiMarkdown.

From the summer of 2014 to May 2016, was powered by my Grebe code, but in May 2016, I converted the site to use Wren.

I also use Wren at (test site for code development site) and Wren created the content that’s used at gopher:// and zwdqwr2p2xwkpbyv.onion. And Wren manages my new website, which will replace

The .onion site runs on my home Linux computer, when the computer is powered on. I used the site to test the Tor service. I created the gopher site to test the gopher protocol.

To view the onion and gopher sites, special browser clients are required. The gopher site, however, can be viewed with a normal web browser through this proxy.

Article Preview

Article Preview is a quick way to test the format of single web pages. The test site exists at, and here’s sample markup to try.

Using a browser, markup is submitted, and formatted HTML is returned. It supports Markdown, MultiMarkdown, Textile, and HTML. Numerous custom formatting commands exist too.

It also contains a one-command API where JSON is submitted that contains the markup, and then JSON is returned, which contains the formatted post, along with other information, such as word count, reading time, etc.

I created this simple tool to test my ramblings about article page design.


Parula is the name of the code that powers my small, local message board, but I do not have the code committed to GitHub.

I bought the domain name in September 2001. In the fall of 2002, I started building the first version of TT, which was patterned after in look and functionality. TT launched in January 2003. Back 2003-2004, I used this codebase to manage two other community sites/message boards: and

In 2005, I created the Parula code, which was/is wiki-based. I wanted a wiki to run alongside the message board. Parula supports Textile. (I’ve been writing in Textile since 2005, but I also like Markdown.)

I liked the Parula code better than the original TT code, and in August 2007, I switched the main site to be powered by Parula. Over the years since, I have continued to make small changes, but TT is still powered by the Parula code from 2005.

Map mashups

Last decade on the server, I created a few map mashups that combined data with Google maps.

I built my first map mashup in 2005 that mapped Lucas County registered sex offenders, using data from the sheriff’s department.

I maintained this mapping project for a few years, but it became too much of a legal hassle, even though I didn’t do anything wrong. I’ve disabled viewing of that map app.

The others map mashups don’t display content anymore because of tech changes by Google.

GitHub Pages

In 2016, I read this 2012 article by Development Seed, titled How We Build CMS-Free Websites, which inspired me to create (at GitHub) and (at GitHub) by using Jekyll, GitHub Pages, and

No local installs of Jekyll and git are used. All editing is done through the browser via and GitHub’s web editor.

I forked a theme at, and I followed advice from this 2014 article titled Build A Blog With Jekyll And GitHub Pages.

I’m using my site to test replicating If all goes well, I may consider converting from using my Grebe publishing app at Digital Ocean to using Jekyll and GitHub Pages.

For the look of, I adopted aspects of Brian Gardner’s free Minimalist Pro theme.


Tanager - My Junco, Grebe, Scaup, Veery, and Wren web publishing apps have the option to use a simple, JavaScript-based “editor” for creating and updating posts.

In 2013, I started with this person’s code It’s a live-preview editor that supports Textile, but didn’t like the flashing of the formatted text in the right window pane.

I modified the original code significantly to support my needs. I removed the live-preview, since my web apps also support Markdown and my own custom commands. I prefer to let the server code do all of the formatting.

My version accesses the API code in my apps. Using REST and JSON, the editor sends markup to the server, and it receives HTML within JSON.

Other functions that I added include a single-screen view to create a larger writing area, keyboard shortcuts, and auto-save.

My 2013 version relied on multiiple JavaScript frameworks. In January 2017, I created Tanager to be a pure, vanilla JavaScript editor. No frameworks. I use the Tanager version with Wren.

My preferred writing environment is to use Textile or Markdown with Tanager or my modified JavaScript editor, along with one of my web publishing apps.


Warbler is a message board where all thread starter posts and comments are Webmentions. A Webmention is a cross-site communication idea, espoused by the IndieWeb community. It may remind some of the trackback and pingback functionality that many blog sites offered back in the aught years.

More info about the Webmention can be found at:

Users create their Webmention posts on their own public websites or web presences. Then they copy the URLs for their posts and paste them into Warbler.

If the authors’ CMS supports sending Webmentions, then their code can access the Warbler Webmention API endpoint.

A user’s Webmention post is considered the source URL. This post must contain the URL of the Warbler post that the author is responding to, which is called the target URL.

New posts are displayed immediately. To limit the possibility for spam, Warbler implements throttling for the entire website and for each author’s domain name. A post from any domain name is accepted at most once every 60 seconds. A post from any specific author’s domain name is accepted at most once every five minutes.

At Warbler, only the first 300 characters of a Webmention post are displayed, if the post is that long. And at Warbler, HTML is removed. The display of each post at Warbler contains a link to the original post, hosted on the author’s website.

The test website exists at For the test content displayed, I disabled the target URL check to test other aspectes of the code.

Production website exists at

Lightweight Article Design

LAD - Lightweight Article Design. I’m still collecting CSS and thoughts about the ideal web page for displaying text. Test HTML page.


Slide - A small, web-based slideshow for text-based posts. I liked the concept of the “tap essay” mobile app, except that I wanted to use it for the web. Here are a couple examples of my slideshow posts, along with the original web articles.


ToledoWX-Lua is copy of my ToledoWX weather web app, except this version was created with the Lua programming language. This version uses the Mustache template system.

ToledoWX-Lua displays Toledo, Ohio weather information that is pulled from National Weather Serivce XML files, JSON files, plain text files, and HTML pages. The code also fetches JSON data from

The ToledoWX-Lua test website is located at


Dark-Sky-API-Lua containas a Lua-based wrapper and utilities to access and format data from, formerly called It functions similar to my Perl version called ForcastIO.

Here’s the Dark Sky section of my ToledoWX-Lua web app/site.


Sora is a web-based static site generator, written in Lua. I based Sora off of my Wren code.

Test site:

Like Wren, Sora contains a REST-JSON API. Sora supports Markdown markup.

At the moment, Sora lacks several features that exist in Wren. Sora does not support the Multimarkdown and Textile markup languages, and Sora does not support IndieWeb functions, such as Webmentions, IndieAuth, and Micropub.

I kept Sora simple, but it’s a fully functional web pub app, and it probably does 99 percent of what I do with Wren that powers my main website

Some day, I may move to its own Digital Ocean droplet, and instead of using a normal Nginx web server, I’ll use OpenResty, which is an Nginx web server with Lua bult into it. Then I would use Sora to power


cgilua-wsapi-mods - In the spring of 2018, I used Lua to create a simple, web-based, static site generator, called Sora that relies on the old fashioned Common Gateway Interface. I needed to make a few file changes to make the dynamic, server-side Lua web code work the way that I desired.

I had to install two modules to enable CGI programming in Lua: cgilua and wsapi. I made small changes to two files in the cgilua module and one small file change in wsapi. I needed to return different HTTP status values, send/receive content type JSON, and handle PUT requests.


Nuthatch - This REST API web publishing app was written in Lua. It’s similar to Scaup and Veery. It relies on CouchDB and Elasticsearch. Optionally, it can use Redis or Memcached. Nuthatch uses the Mustache templating system. The API matches or is similar to Veery’s. Test site exists at


Finch - Bare minimum feed reader utility created with Lua and HTML. A text file contains the URLs of the feeds. A Lua script executes in cron twice a day. The script reads the feeds file, accesses the feeds, creates an HTML file for each feed, and creates a homepage HTML file with the links to each feed HTML file.

I’m an occasional consumer/reader of feeds. Over the past few years, I’ve relied on the web-based feed reader The Old Reader. But after creating Finch, I rarely use The Old Reader. I have never been that interested in consuming feeds. That’s why I like to choose to follow sites that update only a few times a week or even less often.

My test site

Lua Memcached Mods

lua-memcached-mods - I should fork the repos when making small changes. The primary Lua Memcached module was last updated around 2010, and I could not make it work with Lua version 5.3. The Open Resty project has its own Memcached module, but I wanted my code to execute separately from Open Resty, which is a modified version of the Nginx web server that contains Lua and its own web framework.

I rewrote Memcached, but I also used some code or ideas from the original module. I’m using my Memcached version with my Nuthatch web publishing app to cache web pages that Nginx accesses.

My top-level domain websites

My test/development sites

My other sites

I use these sites. These are not test sites.