Hello, I'm Russ, and this is my website. I'm a software engineer who programs for the love of the craft in an age of tech disillusionment. The purpose of this site is to give me a place to publish my thoughts in general and on programming, personal projects, and professional developments.

Hit Counter

Publish Date: 2026-06-13

One staple of the old web was the humble hit counter. Counters are a number presented on a site in text or graphic form which represent the count of visits. They still exist today, especially on the "indie web" (Indie Web, Neocities, Wiby), but in the early-to-mid 2000s, they were mostly replaced by more comprehensive systems like Google Analytics which tracked many metrics: browser, geolocation, language, timezone, referrer, etc. Systems like GA are in many ways superior to hit counters except in their reliance on a corporate, third-party system.

For those who've never seen them, here's an example I made in GIMP (I tried very hard not to use any 3s or 7s in the example):

Web counters are a simple concept: each time the counter is accessed, increase count by 1. This post seeks to design a simple web counter for the site.

Properties

Here are some desired properties:

1. Current Count
2. Date Created
3. Text or Graphical Representation - for now let's stick with graphics for that 'old web' feel
4. Server-side Persistence Layer
5. Encounter Definition: A user accesses the counter resource
6. Encounter Properties:
• IP
• Referrer
• User Agent
• Visited Resource
• Date/Time
7. Visit Definition: An Encounter that has an IP that's the first of the day
8. Counter Incrementation Rule: Once for each Visit

The Encounter properties might be useful or interesting for later analysis and can answer questions like:

• Which resource is most visited?
• Where are visitors most located?
• Which browsers are favored?
• Are visit rates changing over time?

Model

Let's persist the model in a relational database.

I would like to avoid utilizing cookies because nobody likes those and because I'd like to avoid a GDPR cookie prompt if possible.

Many encounter entities to one counter entity. Pretty straightforward.

I considered having a resource entity which represents the URI that's accessed when an encounter occurs. However, I felt this was duplicating the presence of the counter on the resource's landing. Said another way, the counter's relationship to a URI is defined by its presence on the landing, not by configuration in the database. This allows the front-end to move a counter from one location to another without changing the database.

For the initial version, we'll hard code references to the digit graphics. This will eliminate the need for configuration, for now.

API

Only one operation is needed:

1. Operation 1: Visit & Display URI
• Build the Encounter
• If the Encounter, for IP, has been recorded less than N times today, then record it today (prevents a bad actor from filling up the database)
• If the Encounter, for IP, has been recorded less than 1 times today, then increment the counter
• Access the counter's current count
• Output image

In today's age, there are lots of great font libraries out there, but I would like to build my counter graphic server-side, the way they used to be built long ago.

There could be other operations like registering a new counter, resetting a counter, deleting a counter, etc. This is too much for now and each would require an authentication mechanism.

End

Ok, it's time to get to work! I've already started building out the database model, but this week I'm aiming to finish the implementation and put a shiny new counter on each page of the site.

What is this site?

Publish Date: 2026-06-06

Today's project is to start this site and establish it's initial goals. Before publishing, let's walk through some topics.

Publish anonymously?

Should this blog be published under my real life name or under a nickname? I struggle with this one for a number of reasons.

For starters, my opinions change over time and I don't want to be defined by something I wrote 10 years ago which is now controversial. I think of myself as a well-rounded individual, but any take can potentially turn sour over the years.

Also, some things I might write could be unpopular with potential employers. For example, at the moment, employers have a cult-like obsession with "AI". Any criticism could be bad for my work reputation and employment prospects.

OTOH, I'm a professional in it for the love of the craft. I would like credit for my own thoughts and work. And, publishing anonymously is almost a form of self-censorship. Goodness, it's a free country, after all.

So, let's do what's only reasonable: Publish objective content, use opinion sparingly, stay civil, ask reader for grace.

Update frequency?

How often shall it receive updates?

Let's go with weekly as a goal. Daily is too much for me to keep up with, monthly may not be enough to establish a habit.

Content topics?

I program in my spare time for learning and fun, and I often wish to have a medium to write down my ideas. I could, and do, write these ideas on paper or in a text editor, but there's some value in preparing an idea for a reader. The act of explaining the idea often refines it.

Sometimes I may want to explore software engineering topics such as specific technologies, APIs, frameworks, or "AI".

Stack?

I would like this site to be minimalist in nature. This is not a rejection of modern tech, but a celebration of the Internet's roots, a topic I'd like to explore in more detail later.

For now, let's use HTML5 and minimal Javascript and CSS. This should ensure that minimalist search engines like Wiby will index it.

I would also like to have some back end application to facilitate "fun" demos and to store basic information like traffic statistics--let's not go overboard, though.

Conclusion

The above basics should provide some ground rules to keep me producing at a sustainable pace.

I've published a summary of this planning exercise under the "spec" link above.