Lukas Murdock
Subscribe for updates and more.

About This Site and I

Target Audience

The content on this website is for my future self, who is intelligent and interested, but has forgotten. So I hope to remember why I decided something by noting down everything I found interesting about it for future reference. I hope you might find some topics as interesting as I have, and the essay useful or at least entertaining–but the intended audience is my future self.

Long Site

I’m looking for more ways to apply the idea of Long Now. If you worked on something for the next 60 years, what sort of writing could you create? What could you do if you started now?

The great French Marshall Lyautey once asked his gardener to plant a tree. The gardner objected that the tree was slow growing and wouldn’t reach maturity for 100 years. The Marshall replied, “In that case, there is no time to lose; plant it this afternoon!
― John F. Kennedy

This is reflected later on in the development of this website.

Long Content

I hope to work on projects that are too big to work on normally or too tedious. Thinking Long Now gives you a better perspective to tackle long-term tasks like gathering information for years. If one persists in collecting glimmers of genius for years, then even the dullest person may look a bit like a genius himself.

Starting is hard. One solution is to never start. Have perpetual drafts tweaked from time to time. And the rest takes care of itself.

I wish to create works that persist through time. Works in which the more time passes, the more they improve.

One such approach is the monograph, but Long Content is any content that gets better over time.

So a goal is to actively think about how to write material that improves with time, and work on writings that will not be finished for years, if at all.

About Me

I elevator pitch myself as a Designer, Developer, and Marketer, but here I try to give a more extensive view of who I am by taking a look at things I’ve spent my time learning. These are all things where I understand the joys and pains of using them, but I wouldn’t call myself a master of anything.

Technical Things I’ve Learned

Various technologies I dove into before I started tracking when I learned them. (Before I turned 20)

Technical Things I Learned in 2020

Technical Things I Don’t Know

Companies I’ve Worked For

I am a freelance writer, designer, developer, and marketer.

August 2020 – Present
Loganix • Content Strategist • Remote

January 2020 – April 2020
ABB • Marketing Consultant • Remote

July 2018 – August 2019
Infinite Smiles • Product Designer • 7500 Sawmill Pkwy Powell, OH 43065

August 2017 – May 2018
Cinemark @ 1071 Gemini Pl Columbus, OH 43240

December 2015 – July 2017
Chick-fil-a @ 8787 Sancus Blvd Columbus, OH 43240

Places I Want to Visit

In no particular order

Websites

Daily Software

See the other applications I use

Hardware

Hardware that goes with me everywhere

Other Hardware

Mailing Lists

Big 5 Personality Inventory

Contact

About The Development of This Website

The first commit to this site was on July 3, 2019.

(This is a better version of the About this website I posted April 17, 2020.)

This website is built on two principles: As little dependencies as possible and minimizing vendor lock-in. I guess a third would be to make it as simple as possible and as complex as needed, taking into account technical overhead.

This has currently materialized in:

Why not use vendors like Squarespace or Webflow? In the long term, all non-Free software is a dead end. The utility of all non-Free software always approaches zero.

Why not use WordPress? Honestly, WordPress is a good option here. But while it’s free, the server isn’t and the technical overhead that comes with it seems too annoying, especially compared to my free “low-tech” stack used here. Also I like the benefits that come from static sites.

Data Sources

Markdown, JSON, and YAML files.

Posts are Markdown, data like booklist, want-to-read, knowledge, principles, and alivetime are YAML as JSON isn’t as readable by humans.

Using these data formats prevent me from any lock-in and give me control over all the files. To have a setup like this means that content edits are Git-based.

Git-based means that changes made on a local machine are pushed to the Git repository which then triggers a new build of your site. Compared to API-based where the content is held on a different server and your site needs to pull the content from an API.

I’ve been getting more comfortable using Ruby build scripts that run on Jekyll Build time to streamline some operations:

So currently I use Ruby to pull API (JSON) data and turn it into YAML.

Note: Jekyll supports loading data from YAML, JSON, CSV, and TSV files located in the _data directory.

Build

Jekyll. “Markdown, Liquid, HTML & CSS go in. Static sites come out ready for deployment.”

Jekyll uses HTML layouts that are extensible through the Liquid template language. Both Jekyll and Liquid are written in Ruby.

Jekyll also provides a number of useful Liquid additions to help you build.

The more I use it, the more I see how powerful it is. The next step of things that I want to do, (which may be possible in liquid, I’m still learning), is create a collective changelog of dated tasks, books, and resources added by date. May possibly utilize SQLite.

Deploy and CDN

Currently hosting on Github Pages as that’s what I started on. All my other projects use Netlify and I imagine I’ll move over once they improve some things.

Github Pages doesn’t support custom _plugins but my build scripts don’t need to run on every build, and I typically preview by building locally anyways so it’s currently not an issue.

With this stack my entire website is currently free, aside from paying for the domain name and email.