Diekema.io

I've had various personal projects and sites over the years. Some were created just to try a new technology, others were actual projects that I spent many months iterating on until I was happy with them. Inevitably though, work or life would catch up to me and the time and money required to maintain those projects would be shifted elsewhere.

Sometimes it would be a surprisingly large AWS bill on my personal credit card that would remind me that I had started an ambitious or resource heavy project and forgotten to shut it off. Other times it was that there were just more interesting things to tackle outside the world of software development and internet technology. When it's your job, it's not always easy to keep it as a hobby.

So this is my lazy way of sharing personal and professional experience. It's HTML5 and CSS, there's minimal JavaScript, no NodeJS, no CMS to forget about patching. There's a domain name, an S3 bucket, and some static files.

I won't be publishing a tutorial on how to write a blog engine, because frankly you don't need one.

How It's Made - Content

2023-05-07T13:30:00-04:00

This is how I add a new article.

The first step is to add a new <li> with an <a> element. The is how you navigate to different articles, articles are anchored by an id attribute. The href attribute value is a pound (#) symbol and the timestamp of when I start writing a new article, no magic, I just look at the clock and type out the current time ISO8601 format. This creates a named anchor, it's a reference to a position within the scope of the current document.

I'll dive a bit deeper into the Document Object Model, or DOM, later on. For now, it's good to know now that within an HTML page there's an underlying data structure. There are a few attributes like id and class that are used extensively to identify HTML elements within a page. An id is special in that it may only be used once on a single HTML element in a given document. Ids are just strings, you can use any meaningful value that uniquely identifies an element in your page. Which is why a timestamp string makes a good candidate for this use case, I'm not likely to be publishing multiple articles within the same second.

Once the navigation is set, I utilize an <h2> and <h4> for the article heading and timestamp subheading, I copy and paste the timestamp for the subheading.

After that's in place, I add content. <p> elements create new paragraphs which break up the text into digestible chunks.

In order to display code content with highlighting, I use the <pre> and <code> tags which are hooked into by the javascript code highlighting library. The only downside to this approach for documenting HTML in an HTML document is that you have to type out the html entities &lt; and &gt; for the < and > symbols respectively. Without using the html entity representations, the browser can't tell the difference between text intended for display and HTML markup that needs to be rendered.

So that's about it, as simple as I can get. Ironically I started writing this article almost a year ago. In that time I got engaged, married, and had a honeymoon in Costa Rica. Time flies, it's a good demonstration of how priorities and attention can shift wildly year to year. I started writing these in 2021 when the pandemic was a much larger concern, we were still being cautious about going out, so I had an abundance of free time.

Post twitter meltdown and the proliferation of federated social media, I think it's important to revisit what online presence means and what you're getting out of it. When it comes to putting your own content online, there are lots of ways to go about it, some are free, some cost money, and others turn you into the product. 


<nav>
    <h3 id="articles">Articles</h3>
    <ul>
        <li>
            <a href="#2023-05-07T13:30:00-04:00">How It's Made - Content</a>
        </li>
        <li>
            <a href="#2021-11-10T17:45:00-05:00">How It's Made</a>
        </li>
        <li>
            <a href="#2021-11-09T22:21:00-05:00">Simplicity</a>
        </li>
    </ul>
</nav>
<article id="2023-05-07T13:30:00-04:00">
    <h2>How It's Made - Content</h2>
    <h4>2023-05-07T13:30:00-04:00</h4>
    <p>
        This is a new article.
    </p>
    <p>
        <pre class="code-snippet">
            <code class="language-html">

            </code>
        </pre>
    </p>
</article>

How It's Made

2021-11-10T17:45:00-05:00

Right click, hit inspect, view the page source in the Elements tab or Inspector for Chrome and FireFox respectively.

The base for the page comes from HTML5 Boilerplate, but stripped down further still. The benefit to using it as the base is the CSS does come with some common cross-browser styling fixes you may or may not get bitten by.

This is the bulk of the page, I'll expand on the ellipses later, but there's 3 stylesheets and one script, the script is used to format code blocks with syntax hightlighting to improve readability you can grab it here highlight.js. 


<!doctype html>
<html class="no-js" lang="en">
    <head>
        <meta charset="utf-8">
        <title>Diekema.io - Richard Diekema</title>
        <meta http-equiv="Content-Security-Policy" content="script-src 'self'">
        <meta name="description" content="Personal site of a professional programmer writing about old and new technologies. Java AWS CDK JavaScript NodeJS Backend">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <link rel="stylesheet" href="css/normalize.css" type="text/css">
        <link rel="stylesheet" href="css/main.css" type="text/css">
        <link rel="stylesheet" href="css/solarized-dark.min.css" type="text/css">
    </head>
    <body>
    ...
    <script src="/highlight.min.js"></script>
    <script src="/index.js"></script>
</html>

We chuck the rest of the included JavaScript, since we won't be using it and our project folder looks like this: 


- css/
-   main.css
-   normalize.css
-   solarized-dark.min.css
- index.html
- index.js
- highlight.min.js

Now when it comes to structuring your page, how you lay out the document itself, it helps to stop and think about what it is exactly you're trying to accomplish. If the bulk of your content is your writing and code samples, you can get by on very little. Most of the tools you need are already provided by the HTML spec.

In HTML Semantic Elements are elements that have meaning in a document, the element had a use case in mind when it was created. Granted with styling you can turn a <span/> into something that looks like an <h1/> element, but why not just use an <h1/> element?

There's a lot of reasons why you might find pages that don't use semantic elements for page structures, and usually it's because what you're seeing was not generated by a human. <div> soup is usually what you'll find in most pages generated by a front-end framework.

This isn't necessarily bad, but it can be hard to figure out what the page is actually doing and if you're curious about reverse engineering something, it can take a significant amount of work to find the element(s) responsible for what you're seeing on the screen.

If you're writing for yourself though, and want to keep things clean and organized in terms of markup and styling, semantic elements can help. Semantic elements have default styles, you don't need to specify a style for <h1/> through <h6/> if the default styles work for you.

Additionally <p> tags provide a built-in way to separate text into paragraphs.

<s>It's almost as if HTML is a document oriented language</s>.

Articles

Simplicity

2021-11-09T22:21:00-05:00

For information to be useful, it has to be accessible. If I were to use an off the self blogging tool or build one from scratch, it would probably work just fine. I'd publish articles, people would read them, and everything would be great. But a few weeks go by, I haven't checked on it in a while, and there's a vulnerability discovered in my off the shelf platform. Maybe my comments section was being used to propagate malicious and fraudulent links and I was not around to moderate and clean it up. Maybe I had built my blogging engine in such a way that it was vulnerable to SQL injection, XSS, or XSRF attacks. I don't need that kind of headache in my life, and so instead of fixing it, I just shut it off entirely, not worth the hassle.

Now the information that I published and those that may have read it and reference it from time to time, no longer can. So was the effort worth it in the first place? Why spend the time and effort to build something that is eventually fragile?

It might seem cool at first to build and manage your own services, because you can, but what value is derived from the time spent on continual maintenance versus writing and publishing content. Is all of that work really providing a better and more useful experience, or is it another example of focusing on how something is done instead of what it is you want to do.

So that's my goal here, make this process as simple as possible. If I run into something where I need to add additional complexity to enhance usability or accessibility of the content, then I'll do it when the time comes.

Articles