Dondon Developments

Journal Review #1

[ ] Start making zines
- [ ] Make one about Edward Bernays because that guy is terrible and relevant to current terribleness
[ ] draw more
Fuck YouTube
[ ] #seed Make content about being a Staff+ Software Developer/Engineer
[ ] Make more videos -> which is to say make ANY videos
[ ] #seed What exactly is TLS?
[ ] #project Add fake advertising to this website
- This seems like a fun idea and a good way to make fun/silly art
[ ] #seed Core Web Vitals
Calisthenics is awesome
"Bias For Action" is a term I heard that I like and I think sounds like a Street Wear brand
Being a Renaissance Man does not mean being a Jack of all trades
- Figure out what hobbies you actually enjoy and where you want to dedicate your time so that you actually make progress
At the end of January, I moved down 75lbs -> 60lbs on assisted dips/chin-ups
- I promptly moved back up when I started doing actual pull-ups instead
I have been using notebooks more and it's fantastic
- Less "polished content", more thinking on paper
"My home office is just an elaborate anti-productivity machine"
- This is a realization I had before I Marie Kondoed my office
- It probably still has some room to be improved but I've actually been much more productive in this space since realizing I manifested ADHD in a room
I am realizing that I never developed healthy work habits
- This sucks to realize at 38yo
- But better late than never
The Dissect Podcast is phenomenal
- Especially the season dedicated to MF DOOM
- Listen to it again whenever you see this
MF DOOM is a fucking genius
Spending is a problem for me
- I really like stuff I already have a lot of like multitools and knives
I remembered a blog that I used to frequent: Them Thangs
There is intrinsic value in making art, even if it just makes you smile
Taking photos just to compose a good shot is so rewarding
Consume higher quality media
- Cheap dopamine is bullshit
- Fuck social media
- Fuck YouTube
I've been on a journey to make my phone dumber
- One area that was silently still sapping attention was having a search engine literally at my finger tips
- Make using the internet on your phone clunky if you also have this problem
- You don't need to answer every question that you have when you have it -> sometimes not at all
[ ] Read more books about telling stories
[ ] Listen to the Moth again
[ ] Journal when you find yourself mindlessly navigating to YT
- [ ] talk about the stuff you would click on and then reflect on how stupid that is
Peanut Butter Wolf
#seed binaries + spectra
Mndsgn is a musician I found that is v good
Library of Esoterica -> SO GOOD
- The website is awesome too!
[ ] #seed write longform on my personal thoughts on religion
YT is a content machine
- it turns attention into revenue
- It is NOT inspiration
- it IS an entertainment product
I very much want to make stickers and t-shirts and "merch" again
- I used to have a screen printer and make stupid t-shirts in college
- I want to do this again in some capacity
Learn how to be a photographer again
- My degree is in photography and I don't do anything with it anymore
- I miss how I used to use a camera to understand things

Components, Data Layers, and the Adapter Pattern

Rambling Thesis Statement

Recently I've been thinking about the importance of Component Design with regard to React/NextJS projects. But I think conceptually, this extends to any project that is component based. When you are developing components for an app, there is almost always some data layer that is providing you content. Usually This comes in the form of some REST API request that returns you some JSON shape that you then plug into a component. What I have very recently conceptually considered, with respect to this relationship, is the Adapter Pattern. This should, in my opinion, ALWAYS come into play when building in this fashion. You should always be thinking of the props of your component as a public interface. The props should describe what the component can do, the component should not be altered to accommodate the props. There should be a layer between the data coming in and the component itself that should be doing the job of making the data fit the component. This is the Adapter Pattern.

The Adapter Pattern

Instead of giving an in depth explanation on my own, I encourage you to dig into this article instead that does a fantastic job of explaining the Adapter Pattern: Geeks For Geeks: Adapter Design Pattern.

Example

Q: This all sounds like you know a whole lot about tech Donny. But what the fuck are you talking about?

I'm glad I asked! I captured this thought so that I would later elaborate on it and now I am just 5 short months later. Let's organize the problem a bit more and hopefully make more sense of this word soup.

The Problem

It is really easy to take the type of an API response and plug it directly into a given component as the props:

// ❌ BEFORE: Component tightly coupled to the API response shape

// The API response — you don't own this, it can change
type ApiProduct = {
  product_id: string;
  display_name: string;
  base_price_cents: number;
  discount_bps: number;        // basis points, e.g. 500 = 5%
  media: { src: string; alt_text: string }[];
  inventory: { in_stock: boolean; qty_remaining: number };
};

// The component consumes the API shape directly — now they're glued together
function ProductBanner({ product_id, display_name, base_price_cents, discount_bps, media, inventory }: ApiProduct) {
  const price = (base_price_cents / 100).toFixed(2);
  const discount = (discount_bps / 100).toFixed(0);
  const image = media[0];

  return (
    <div>
      <img src={image.src} alt={image.alt_text} />
      <h2>{display_name}</h2>
      <p>${price} — {discount}% off</p>
      {!inventory.in_stock && <span>Out of stock</span>}
    </div>
  );
}

// The problem: if the API renames `display_name` to `title`, or changes
// `base_price_cents` to `price_usd`, your component breaks. The business
// logic (cents → dollars, basis points → %) is also leaking into the UI.

As outlined, this is bad because we have a contract in our codebase that relies on code that we don't maintain. This is a gigantic red flag.

The Solution

Instead, we should implement the Adapter Pattern, add a mutation layer to our code, and create a solid interface that describes our component as we expect it to be used.

// ✅ AFTER: Adapter pattern decouples the API from the component

// 1. The API contract — models exactly what the API returns
type ApiProduct = {
  product_id: string;
  display_name: string;
  base_price_cents: number;
  discount_bps: number;
  media: { src: string; alt_text: string }[];
  inventory: { in_stock: boolean; qty_remaining: number };
};

// 2. The component contract — models what the UI actually needs
type ProductBannerProps = {
  id: string;
  name: string;
  formattedPrice: string;       // "$49.99"
  discountPercent: number;      // 5
  image: { src: string; alt: string };
  availability: "in_stock" | "out_of_stock";
};

// 3. The adapter — owns the mutation logic between the two contracts
function adaptApiProductToBannerProps(product: ApiProduct): ProductBannerProps {
  return {
    id: product.product_id,
    name: product.display_name,
    formattedPrice: `$${(product.base_price_cents / 100).toFixed(2)}`,
    discountPercent: product.discount_bps / 100,
    image: {
      src: product.media[0].src,
      alt: product.media[0].alt_text,
    },
    availability: product.inventory.in_stock ? "in_stock" : "out_of_stock",
  };
}

// 4. The component — clean, readable, knows nothing about the API
function ProductBanner({ name, formattedPrice, discountPercent, image, availability }: ProductBannerProps) {
  return (
    <div>
      <img src={image.src} alt={image.alt} />
      <h2>{name}</h2>
      <p>{formattedPrice} — {discountPercent}% off</p>
      {availability === "out_of_stock" && <span>Out of stock</span>}
    </div>
  );
}

// 5. The call site — adapter runs at the boundary, right after the fetch
async function Page() {
  const data: ApiProduct = await fetch("/api/products/1").then(r => r.json());
  const props = adaptApiProductToBannerProps(data);
  return <ProductBanner {...props} />;
}

Hopefully this now makes more sense! And now you have a real world example that you can use to discuss a design pattern!

Tmux: Getting Started

What is a TMUX?

Tmux is pretty awesome, I've heard about it for a long time, and I finally am taking an hour to learn it. If I would have known it was this quick, I would have just learned it forever ago because it is really useful. Tmux is a multiplexer which means nothing because nobody knows what a multiplexer is so it doesn't give you any reference for what it does. What is a multiplexer? The internet (AI bot) says this:

A multiplexer (often abbreviated mux) is a digital circuit that selects one of several input signals and forwards the chosen input to a single output line.

In essence, it works like a multiple‑to‑single switch controlled by a set of select lines (also called address or control bits). The number of select lines determines how many inputs can be addressed:

This is actually helpful with regard to Tmux since Tmux essentially allows you to work with multiple sessions, windows, and panes inside of your terminal environment. So instead of having one terminal window and a bunch of tabs that are hard to navigate around, Tmux gives you a similar performance, allowing you to manage multiple windows, with some really useful commands that make it really easy to do so. The concept of sessions is really cool too because you could do something like run a server, exit (close) the window, and still have access to your running server. This is cool and you should do it.

Tmux Elements

Sessions

The relationship between sessions, windows, and panes is pretty simple, but here's a general overview. Sessions are top level. Anything you do in Tmux is gonna happen in a session. These are similar to browser sessions. It's essentially the 5W's of whatever you're doing. Who: you, What: typing stuff: When: now (and later maybe), Where: some file system, Why: Because your life is dope and you do dope shit. Windows

Windows

Windows are where work actually happens. You can think of windows as individual terminal windows since that is what they are. If you didn't use Tmux, these would be tabs or multiple terminal windows.

Panes

Panes are windows inside of windows. Panes allow you to split a screen (window) and perform multiple tasks. I can see where this might be useful, but I think just having multiple windows is gonna suffice for me.

Keyboard Shortcuts

There are a bunch of cool shortcuts in Tmux because, obviously there are. That's what makes it useful. Here are some of the really useful ones based on what they correspond to.

One important thing to note, Tmux relies on a "prefix" for it's keyboard shortcuts. This is to prevent collision between Tmux's shortcuts and other terminal shortcuts. The default prefix is ctrl + b but you can change this if you would like. I don't like so it's just ctrl + b for me.

Windows

Create a new window - <prefix> + c
Cycle between previous and next windows respectively - <prefix> + p/n
Choose a specific window - <prefix> + [index]
The index will be next to the name of the window in the bottom bar
List all windows - <prefix> + w
Rename a window - <prefix> + ,

Panes

Split screen horizontal - <prefix> + "
Split screen vertically - <prefix> + %
Move around panes - <prefix> + [arrow keys]
Cycle through panes - <prefix> + o
close a pane - <prefix> + x or type exit
rearrange panes - <prefix> + SPACE

Commands

Tmux also has built in commands. These are really useful for scripting. Scripting is awesome. You should do that too. Also use NeoVim with Lua. Anyway, to start command mode, type <prefix> + : then you can type stuff like list-windows and Tmux will list all windows in this session or split-windows with the -v/-h flag for vertical or horizontal. There are more. I will not list them.

Configuration

You can add a Tmux configuration file and you want to do this. Add a configuration file at ~/.config/tmux/tmux.conf.

NeoVim Thoughtz

Inserting Characters with Visual Block

I recently wanted to prepended dashes to a couple of lines to turn this:

Structure and Interpretation of Computer Programs by Gerald Jay Sussman
Computer Systems: A Programmer’s Perspective by Randal E. Bryant
Designing Data-Intensive Applications by Martin Kleppmann

into this:

- Structure and Interpretation of Computer Programs by Gerald Jay Sussman
- Computer Systems: A Programmer’s Perspective by Randal E. Bryant
- Designing Data-Intensive Applications by Martin Kleppmann

And I super forgot how. Here's a quick guide for when I forget again.

Enter VISUAL BLOCK - ctrl + v
select rows - j/k
Enter VB INSERT - shift + I (THIS IS WHAT GOT ME! CAPITAL I!)
Enter characters - - in this case
Indicate that you are finished - esc

That's it! Your prepend is applied to all lines!

TypeScript Patterns

I recently read a very good article discussing TypeScript Patterns that "self-document" your code. There is some really good stuff here and this is definitely something that I'll be digging deeper into. One of the concepts that really stood out is the idea of "branding" types in TS. This is not something that I have seen before but I think it is a really good idea. It doesn't do much for the code itself but it makes things more readable as far as intent for developers.

Branded Types

This is largely superfluous as it doesn't change anything about how the code functions. But it labels things better. The article does a good job of illustrating exactly how this works so I will give a quick example but then talk more about what is happening.

type UserBirthdate = Date & { readonly __brand: 'UserBirthdate' };
type UserEmail = string & { readonly __brand: 'UserEmail' };
type UserName = string & { readonly __brand: 'UserName' };

interface User {
  birthdate: UserBirthdate;
  email: UserEmail;
  name: UserName;
}

const user1: User = {
  birthdate: new Date('3056-08-08'),
  email: 'me@dondon.dev',
  name: 'Dondon',
};

Thought Work Organization Strategy

I have been feeling a lot more productive lately. I feel like that is thanks to nailing down a more structured approach to thinking externally. Both on paper and in digital spaces. I wanted to get a seed started for this because I think that it is going to continue to grow as it gets more use.

I've been actively trying to make my daily notebooks more useful instead of just being a glorified journal. I can't overstate how much I value journaling. So even if that was the only use for it, it's still plenty valuable. But I've gotten a lot better in recent months about making various lists and taking fleeting notes just to get thoughts out of my head and on paper. This has proved to be crazy useful just in and of itself. Writing, I'm learning, has so many benefits even if the only thing you do is write the things that you're thinking. But, by following the process that I'll describe next, it becomes infinitely more useful.

My current process is as follows:

Fleeting Note Capture - For this I have two notebooks. One is a big A4 sized notebook that I take active time to sit down and write in. The second is a pocket-sized notebook that doubles as a wallet. I use both of these to varying degrees to write down pretty much anything that comes into my head. Even if it's just something that I want to remember to do later. Sometimes the things that I write in either of these books is valuable and I either expand on whatever I wrote right there in the notebook or I migrate it to step two immediately. Either way, when I find value in a fleeting note, it eventually makes it's way to step 2. A lot of fleeting notes never make it past step 1 though and that's ok. I've learned that most of this process is about revising and removing.
Permanent Notes - I'm very much in the beginnings of adoption with this step. But once you start doing it, you see the benefits immediately. Once I can really visualize a fleeting note in the context of other notes from my day, especially if that note is about a book or an article or with relevance to something important, I can distill it and rewrite it into something more permanent. In this step, I can also relate it to other notes by linking it. This step is made way easier by using a digital counterpart. I use Obsidian but there are other tools out there. I prefer Obsidian because I watched a bunch of videos about Zettelkasten before I had any sort of structure or practice with taking notes and I wanted to be cool and use what all of the other cool people were using to take notes. Having used it for a while now, though, I really do appreciate the way that it works. I think the biggest caveat for me for a digital note system is Markdown though. I use markdown for every piece of digital writing I do unless I am absolutely forced to use something else. Markdown is awesome because, as a software developer, it follows me everywhere. I can use it in Git and GitHub, Obsidian, my personal website, Slack, Confluence, NextCloud, etc. You get the picture. It really is a write once, use everywhere solution for me. The more I can avoid context switching, the more I can focus on the information instead of the process.
Artifact Creation - One issue that I ran into with Obsidian in my early attempts at note taking was digital clutter. Now as a high-level concept, good luck with removing the cluttered feeling entirely. If you are writing and recording enough to make anything useful, you are almost definitely going to have a bunch of notes and artifacts in various stages of complete. I'm honestly starting to embrace that as part of the process. Figuring out how to organize the things that I make helps me organize how I think about them a lot of times. This is actually kind of a core tenet of the Zettelkasten system. Anyway, the problem I needed to solve for this step was removing artifacts that aren't notes from Obsidian thus giving me a clear boundary for resources to aid in writing and the written assets themselves. For this I'm using NextCloud. Bonus nerd points because I self-host my NextCloud instance (Long Live Digital Autonomy).
Dissemination - Some stuff actually is functional enough that I want to share it. At this point, I'm using the thing that you're looking at right now if you are not me and you are reading this, my personal website. This is where using markdown through the whole process really shines. I use AstroJS (at least as of the time I'm writing this) to host my content. AstroJS uses markdown to process content. I'm sure I could make my site way more complicated and add an API layer and a data layer and make expensive fetches to get my assets but I'm a simple man with simple taste. I like markdown and you can go fuck yourself if you think I need all of that other business to maintain a successful digital presence.

I'm really happy to have a system in place to help me manage the things that I think about because I have a lot of different topics that I really enjoy pursuing and for far too long I have just forgotten things that I think are really cool and probably could have proved to be useful in some way. With this sort of a system in place, I can literally work with my thoughts in a more tangible way and that helps me feel better. I hope that if you are reading this, I have given you a path to do the same and hopefully saved you some measure of time because I think it is important to know what you think and to do something with it. I wasted far too much time keeping everything in the fleeting step one phase and I think I probably lost a lot of good ideas to time. But now I don't lose track of the things that I care about and you don't have to either. So best of luck. And if this isn't something that interests you, thanks for reading! Just forget that you read it anyway. Just kidding sort of...

Working With AI Tools

I've recently been working a lot more with Claude Sonnet 4. I have a lot of conflicting feelings about AI. But I have been working with this tool in an effort to understand exactly what it does well and see if there is anything beneficial that I can incorporate into my workflow. It turns out, I have definitely found useful applications. I'm going to list anything I find useful here.

I have been using Claude Sonnet 4 as sort of a glorified search engine. Most recently, I have been trying to use Obsidian more effectively. I have been trying to use Obsidian as a complementary tool to my analog notebooks. I ran up against an issue where Obsidian was becoming more of a hindrance than a helper. I was using the daily notes feature of Obsidian. The problem is that I started to feel obligated to fill out my daily note, which had grown quite lengthy with "helpful" sections. It got to the point that I was taking time away from more productive efforts to keep my daily note streak going. Once I realized that this is what I was actually doing, I abandoned the digital note platform all together. I was actually able to have a conversation with Claude and develop a new strategy for using Obsidian along side my analog notes system as well as an all new Obsidian daily note template. I count this as a beneficial use case.

Artifacts

My Obsidian + Analog Journal Methodology

New Obsidian Daily Note Template

# <% tp.date.now("YYYY-MM-DD") %> - <% tp.date.now("dddd") %>

## 📊 Habits

| Habit             | ✓   | Notes |
| ----------------- | --- | ----- |
| Exercise          |     |       |
| Reading           |     |       |
| Water (8 glasses) |     |       |
| Sleep (7+ hours)  |     |       |
| Zettelkasten work |     |       |

## 🔗 Digital Thoughts

_Quick captures when I'm already here_

## 📝 From My Journal

## _Key insights worth linking/connecting later_

## 🎯 Today's Intention

_One simple focus_

## 📋 Logs

- _Notes started today_

---

**Quick Links:** [[Yesterday|←]] | [[Tomorrow|→]] | [[Weekly Review]]

<% tp.date.now("yyyyMMDDHHmmss") %>

AI is also really helpful with mundane tasks like writing K8S Kustomize files and corresponding manifests. You do need to know what they should look like so that you can verify that they are correct. It is unadvisable to trust any AI tool to just write you something and then just use it in your infrastructure. But it generally does a good job. I have noticed that it can hallucinate with larger jobs though. But I built out a whole projects Kustomize infra with Claude:

Project Acorn

base/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: project-acorn
  namespace: project-acorn
  annotations:
    argocd-image-updater.argoproj.io/image-list: website=ghcr.io/donhamiltoniii/project-acorn
    argocd-image-updater.argoproj.io/write-back-method: git
    argocd-image-updater.argoproj.io/git-branch: main
spec:
  replicas: 2
  selector:
    matchLabels:
      app: project-acorn
  template:
    metadata:
      labels:
        app: project-acorn
    spec:
      imagePullSecrets:
        - name: ghcr-secret
      containers:
        - name: website
          image: project-acorn-image # This will be replaced by Kustomize
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: '64Mi'
              cpu: '100m'
            limits:
              memory: '128Mi'
              cpu: '200m'
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5

base/ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: project-acorn-ingress
  namespace: project-acorn
  annotations:
    kubernetes.io/ingress.class: 'traefik'
spec:
  rules:
    - host: project-acorn.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: project-acorn-service
                port:
                  number: 80

base/namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: project-acorn

base/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: project-acorn-service
  namespace: project-acorn
spec:
  selector:
    app: project-acorn
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

base/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - namespace.yaml
  - deployment.yaml
  - service.yaml
  - ingress.yaml

commonLabels:
  app: project-acorn
  version: v1.0.0

images:
  - name: project-acorn-image
    newName: ghcr.io/donhamiltoniii/project-acorn
    newTag: latest

overlays/dev/deployment-patch.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: project-acorn
  namespace: project-acorn
spec:
  template:
    spec:
      containers:
        - name: website
          resources:
            requests:
              memory: '32Mi'
              cpu: '50m'
            limits:
              memory: '64Mi'
              cpu: '100m'
          env:
            - name: ENVIRONMENT
              value: 'development'

overlays/dev/ingress-patch.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: project-acorn-ingress
  namespace: project-acorn
spec:
  rules:
    - host: dev.project-acorn.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: project-acorn-service # Kustomize will transform this
                port:
                  number: 80

overlays/dev/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: project-acorn-dev

resources:
  - ../../base

namePrefix: dev-
nameSuffix: -dev

commonLabels:
  environment: dev

patchesStrategicMerge:
  - deployment-patch.yaml
  - ingress-patch.yaml

images:
  - name: project-acorn-image
    newTag: dev-latest

replicas:
  - name: project-acorn
    count: 1

overlays/prod/deployment-patch.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: project-acorn
  namespace: project-acorn
spec:
  template:
    spec:
      containers:
        - name: website
          resources:
            requests:
              memory: '128Mi'
              cpu: '200m'
            limits:
              memory: '256Mi'
              cpu: '500m'
          env:
            - name: ENVIRONMENT
              value: 'production'

overlays/prod/ingress-patch.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: project-acorn-ingress
  namespace: project-acorn
spec:
  rules:
    - host: project-acorn.k3s.syntaxandsymbols.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: project-acorn-service # Kustomize will transform this
                port:
                  number: 80

overlays/prod/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: project-acorn-prod

resources:
  - ../../base

namePrefix: prod-
nameSuffix: -prod

commonLabels:
  environment: prod

patchesStrategicMerge:
  - deployment-patch.yaml
  - ingress-patch.yaml

images:
  - name: project-acorn-image
    newTag: latest

replicas:
  - name: project-acorn
    count: 3

My Obsidian + Analog Journal Methodology

The Problem I Solved

I was using Obsidian daily notes that required too much maintenance - I found myself serving the system instead of it serving me. This led me to abandon Obsidian entirely and return to pure analog journaling.

The Solution: Obsidian as Digital Companion

Core Principle

Obsidian complements my analog journal, it doesn't replace it. My physical notebook remains my primary thinking space. Obsidian handles what digital does best while respecting my analog workflow.

What Each System Handles

Analog Journal (Primary Thinking Space)

Ad hoc thoughts and ideas
Deep thinking and reflection
Daily journaling
Free-form creativity
Problem-solving

Obsidian (Digital Companion)

Linking and Connections - Connect ideas across time and topics
Habit Tracking - Digital excels at patterns and data
Portable Reference - Access knowledge from any device
Knowledge Synthesis - Distill and organize key insights
Research Hub - Store articles, literature notes, references

Daily Note Philosophy

What It's NOT

A comprehensive life management system
A replacement for journaling
Something that demands daily attention
A productivity guilt machine

What It IS

A 30-second habit tracker
A landing pad for digital thoughts when I'm already in Obsidian
A bridge to capture analog insights worth digitizing
A simple intention setter (when it feels natural)

The Workflow

Morning (Optional)

Set simple daily intention if it feels natural
Skip if analog journal feels more appropriate

Throughout the Day

Physical journal for all real thinking
Obsidian only when already on computer and something occurs to me

Evening (30 seconds)

Quick habit checkbox update
Note any analog insights worth linking later

Weekly/Monthly Reviews

Review habit patterns and trends
Create permanent notes from recurring insights
Build knowledge graph based on what's actually important
Connect themes across daily notes

Key Rules

No obligation - If I don't feel like updating Obsidian, I don't
Analog first - When in doubt, reach for pen and paper
Digital enhancement - Obsidian amplifies my thinking, doesn't drive it
Connection focus - Use Obsidian's linking power to see patterns over time
Data over diary - Daily notes capture data points, not narratives

Success Metrics

I know this system is working when:

I'm not feeling guilty about "incomplete" daily notes
Obsidian feels like a helpful tool, not a demanding master
I'm naturally making connections between ideas across time
My habit data is helping me see patterns
The system supports rather than interrupts my thinking flow

Remember

The goal isn't perfect digital capture - it's having a digital companion that enhances my analog thinking practice without disrupting its natural flow.

20250821184951

How to Approach New Topics

I've been listening to the audio version of How to Take Smart Notes as I do chores around my house and take care of my newborn daughter. Really just as a way to keep my sanity. I didn't have any expectation of really getting the full value of this book on this first listen/read (depending on how you view the process of listening to an audiobook). But one observation had a profound impact on me immediately.

In chapter 10, section 3, there is a quote about Richard Feynman and how he considered himself to be understanding a new topic when he could give an introductory lecture on it. That hit me hard.

For a long time, I've been trying to recapture a feeling that I had since I was a Software Development Boot Camp Instructor at We Can Code IT. I thought that it is a passion for teaching, and that may very well be present. But this quote made me realize that what I really miss is the opportunity to make content with the intent of teaching others. That was what was really rewarding and fun about that job.

The key take away, approach every new topic like you are going to teach it to a class:

Take notes
Refine the notes
Build outlines
Make slide decks
Build example projects

Looking forward to exploring this more!

Linux Directory Structure Reference Guide

* AI Generated

Overview

The Linux filesystem follows a hierarchical structure defined by the Filesystem Hierarchy Standard (FHS). Understanding this structure is essential for system administration, software deployment, and general Linux usage.

Root Directory Structure

`/` (Root Directory)

The top-level directory that contains all other directories and files in the system.

Essential System Directories

`/bin` - Essential User Binaries

Purpose: Contains essential command-line utilities needed by all users
Availability: Must be available even in single-user mode
Examples: ls, cp, mv, cat, bash, grep
Note: These are commands you'd expect to work on any Linux system

`/sbin` - System Binaries

Purpose: Essential system administration commands
Access: Typically used by root/administrators
Examples: mount, umount, fsck, iptables, systemctl
Note: "s" stands for "system" or "superuser"

`/lib` - Essential Libraries

Purpose: Shared libraries required by programs in /bin and /sbin
Contents: Dynamic linking libraries (.so files)
Importance: Critical for system boot and basic functionality

User and Application Directories

`/usr` - User System Resources

Secondary hierarchy containing the majority of user utilities and applications.

Key subdirectories:

/usr/bin - Non-essential user commands and applications
/usr/sbin - Non-essential system administration binaries
/usr/lib - Libraries for /usr/bin and /usr/sbin programs
/usr/local - Local software installations (not from package manager)
/usr/share - Architecture-independent shared data

`/opt` - Optional Software Packages

Purpose: Self-contained third-party software packages
Structure: Each package gets its own subdirectory (e.g., /opt/google/chrome)
Use Cases:
- Commercial software
- Large application suites
- Proprietary applications
- Software that prefers to keep all files together
Examples: Oracle Database, VMware, Google Chrome, custom enterprise applications

`/home` - User Home Directories

Purpose: Personal directories for regular users
Structure: /home/username
Contents: User files, personal configurations, documents

`/root` - Root User Home

Purpose: Home directory specifically for the root user
Location: Separate from /home for security and availability reasons

Configuration and Data Directories

`/etc` - System Configuration

Purpose: System-wide configuration files
Format: Text-based configuration files
Examples: /etc/passwd, /etc/hosts, /etc/apache2/, /etc/ssh/
Scope: Affects entire system, not individual users

`/var` - Variable Data

Purpose: Files that change during normal system operation
Key subdirectories:
- /var/log - System and application log files
- /var/mail - User mailboxes
- /var/tmp - Temporary files preserved between reboots
- /var/lib - Application state data
- /var/cache - Application cache data

Temporary and Runtime Directories

`/tmp` - Temporary Files

Purpose: Temporary files for applications and users
Cleanup: Often cleared on system reboot
Access: World-writable with sticky bit set
Usage: Short-term storage during program execution

Boot and Hardware Directories

`/boot` - Boot Files

Purpose: Files required for system startup
Contents: Kernel images, initial RAM disk, bootloader configuration
Examples: vmlinuz, initrd.img, GRUB configuration

`/dev` - Device Files

Purpose: Special files representing hardware devices
Type: Character and block device files
Examples: /dev/sda (hard drive), /dev/null, /dev/random
Management: Usually managed automatically by udev

Virtual Filesystems

`/proc` - Process Information

Purpose: Virtual filesystem exposing kernel and process information
Contents: Process directories (numbered by PID), system information
Examples: /proc/cpuinfo, /proc/meminfo, /proc/1/ (init process)
Note: Files exist only in memory, not on disk

`/sys` - System Information

Purpose: Virtual filesystem for modern kernel object information
Contents: Hardware device information, kernel modules, power management
Usage: Used by modern system management tools
Note: More structured than /proc

Mount Point Directories

`/mnt` - Manual Mount Point

Purpose: Temporary mount point for manually mounted filesystems
Usage: System administrators mount filesystems here temporarily
Examples: Mounting external drives for maintenance

`/media` - Removable Media

Purpose: Automatic mount points for removable media
Management: Usually handled by desktop environments
Examples: /media/usb-drive, /media/cdrom

Quick Reference Summary

Directory	Primary Purpose	Key Characteristics
`/bin`	Essential user commands	Available in single-user mode
`/sbin`	System administration	Root/admin tools
`/usr`	User programs and data	Secondary hierarchy
`/opt`	Third-party packages	Self-contained installations
`/etc`	System configuration	Text-based config files
`/var`	Changing data	Logs, mail, temporary files
`/home`	User directories	Personal user spaces
`/tmp`	Temporary files	Often cleared on boot

Best Practices for Students

Exploration: Use ls -la to explore directory contents and permissions
Documentation: Check man hier for detailed filesystem hierarchy information
Respect: Be cautious when working in system directories (especially as root)
Understanding: Learn the logic behind the structure - it makes navigation intuitive
Practice: Set up a virtual machine to safely explore the filesystem structure

Common Confusion Points

/usr vs /usr/local: /usr is for package-managed software, /usr/local is for manually compiled/installed software
/bin vs /usr/bin: /bin is for essential commands, /usr/bin is for additional user programs
/tmp vs /var/tmp: /tmp may be cleared on reboot, /var/tmp should persist across reboots
/opt vs /usr/local: Both for additional software, but /opt is for packaged applications, /usr/local follows standard hierarchy

This structure has evolved over decades and represents a balance between organization, tradition, and practical system administration needs.

Dad Thoughtz

Be the person you want to raise your child to be, don't dictate it. Enforcing rules is certainly important. Telling your kid no is gonna happen. But don't become a voice of discouragement. Offer explanations and alternatives instead of 'no'. Lead by example not orders.
Your kids (or really anyone you love) don't need to "make you proud"
- Don't ever use that as motivation
- Don't be a parental tyrant
- Don't CONTROL your kids -> they will hate you
- Don't dictate to them
- Instill values, show them how to be good people, trust them to make the right decisions, and teach them when they inevitably don't make the right decision
- Work with them

Seeds, Not Articles

So I think I had a breakthrough with digital gardening today. I was talking about my personal site with a friend and I was talking about being frustrated with my lack of content. I realized that I'm struggling with something adjacent to perfectionism. It's not necessarily that I feel like I need to have a perfectly polished essay or anything to be able to write. But I've been trying to make these big posts. Something that I spend a lot of time on. Something that is complete.

That's not the point of digital gardening!

I'm supposed to come back to these things! Grow them! Like plants in a garden! Maybe that should've been more obvious... But I eventually found myself here! So now I'm gonna do my best to post often and revisit the stuff I post. This is where I imagine most of my content will live until it grows enough to fit somewhere else.

2025 Quarter Two Goals

Previous Quarter Review

Fitness Goal

I think that I did well here. I wish that I would've started Strength Side one fucking week earlier so that I would've finished the program with the quarter. But that's fine. I'm going to continue doing this program for the next quarter anyway. So this time, I actually will end with the quarter. But as far as progress, I've made quite a bit. I'm pretty excited for how my push ups are looking and my pull ups are coming along too

Artistic Goal

This was a fail. Straight up and down. There's no way around it. Insofar as I did not even approach my goal of "actively and intentionally capturing images in my day to day". I did, however, learn a lot about my process through the other goals that I made for myself. So I think I have a good plan for this coming quarter. I need to play into the things that I'm inherentlt driven to do. So if I can make a self-hosting project out of photography and build hardware around it (like a dedicated work station for photo editing), I'm going to be more successful. I think this is going to be a good way to combine both of these efforts.

Creative Goal

I crushed this shit. I'm so fucking passionate about this part. Learning to self host and use server environments more efficiently to the point that I can actually build tools that I can use in personal projects is awesome. I have a K8S homelab setup that I built following MVDB's Skool course. I'm in the process of going through another, in-depth Docker/Kubernetes course. And then, once I have a better handle on K8S itself, I'm gonna go through another course (or maybe courses? IDR) for K8S and FluxCD. So I can get more hands on experience with working with K8S with YAML manifests. But I think working more hands on first is going to be beneficial. Learn the tool before you automate the boring stuff. Oh yea: My self-hosted LinkDing instance

This Quarter

Scope

Week 14 to Week 26 of 2025. So from [[2025-03-30]] - [[2025-06-28]].

Areas of Focus

Body:: Do Strength Side again Right Brain:: Setup a workstation for photo editing and document the rest of this pregnancy Left Brain:: Be better at Docker and Kubernetes

Body

Last quarter, Strength Side went so well that I am going to continue down this calisthenics path this quarter as well. I may start trying to lift again in Q3 but we'll see what happens. That's a conversation with myself that will need to be had later. Similar goal though, try to go through the whole Strength Side 3 months and do the harder variations of each exercise. I feel way better and I definitely feel like I'm moving around better.

DoD

I will consider this goal complete if I do at least 3 workouts a week for this quarter and document my findings.

Right Brain

Last quarter I fell flat on my face with this goal. But in trying to pursue it, I learned a lot about myself and my process. I am fully into self-hosting and trying to make my own services on my home network. I need to incorporate that into my Art goal. Not let it steal the show or anything. But play into my current interests. I broke down and spent money in a way that I was trying to avoid doing. But, tbh, I think it's gonna be good for me as it applies to this goal. I bought myself a Ricoh GR III Street Edition. I do not need a new camera but I really do think this is gonna help me take more photos. Because of the size of this camera as well as the settings available in such a small package, I think I'm gonna be able to have this camera with me in more scenarios than my Nikon Z5. And that's definitely a lesson I've learned about myself over time. I need to have tools available to use them. I am inherently lazy and I will actively not do something if there are too many barriers to entry. So while this is a superfluous purchase, I think it's gonna end up being really worthwhile.

DoD

This goal will be complete if I am taking photos more regularly and publishing them to a self-hosted blog or something similar. I don't want to constrain myself too much here as my next goal will inform what my publishing platform will be

Left Brain

So I feel like I was REALLY taken by Chris Ferdinandi's post about digital gardening. This shit speaks to me like viscerally. This is what excites me about the web. This is what made me want to be a designer and illustrator as a kid, it's what gave me any interest in "building web sites" and later programming. In a lot of ways, this sort of early web mentality of like the DIY or punk web or whatever you want to call it, shaped me as a person. And I want so badly to get back to that. Just build shit because it makes me happy and it gives me a creative way to interact with the people around me. And it gives me a reason to learn different technologies and processes. So I want to continue on this journey that I'm on to learn and use Docker and Kubernetes more so that I can build whatever I want and deliver it to the people that I care about.

Definition of Done

I have done more learning on Docker and K8S, I have a more robust homelab/home network, and I am self-hosting more services for my own consumption, thereby reducing the number of services I use from large toxic tech companies, but also serving my own digital spaces for my own creative work.

20250330055219

How to set up an SSH connection between machines

generate an ssh key from the work station machine: ssh-keygen -f ~/.ssh/<your-key-name>
copy the new key from the work station machine to the agent machine: ssh-copy-id -i ~/.ssh/<your-key-name> <ip addr of agent machine>
1. example: ssh-copy-id -i ~/.ssh/home-lab-key 192.168.0.10
make sure ssh-agent is running on workstation machine: eval $(ssh-agent -s)
add ssh key to registry for use: ssh-add ~/.ssh/<your-key-name>
1. example: ssh-add ~/.ssh/home-lab-key
you should now be able to run: ssh <ip addr of agent machine> and connect to that machine
1. example: ssh 192.168.0.10

Adding Last Modified Support to Astro Blog Posts

This morning I set out to update my Personal Blog powered by Astro. In an effort to do more writing, I am trying to make sure the platform that I'm using for said writing is as accommodating as possible. My posts have had a "Last Updated" field for a while and it's just been the same as the publish date. So I looked into automating the process so that any time I make an update to a post, the "Last Updated" field is programmatically updated. This way I don't have to trust myself to do it as I've proven incredibly unreliable for this task.

Since I took the time to do it, I figured I'd recap the process. To begin, I actually found that Astro includes a "Recipe" for this in their docs. This actually made me super happy because the other solutions that I came across involved pre-commit hooks and shell scripts and a bunch of other config that is definitely interesting and fun. But it's also a giant pain in the ass when you just want one specific outcome.

I won't bog down this post with code examples as I pretty much just followed the recipe from Astro. But what is really cool to learn is that I can make my own plugins for the purposes of pre-processing. Being able to programmatically manipulate data like this open up some pretty cool doors because it allows me to let the computer do the jobs that the computer does well and allows me to focus on what I really care about which is building cool shit and writing about it.

My 2025 Quarter One Goals

Scope

Week 1 to Week 13 of 2025. So from 2024-12-29 - 2025-03-29.

Areas of Focus

For this quarter, I want to focus on narrowing the scope of my focus to a fitness goal, an artistic goal, and a creative goal. I will also start writing weekly updates of my progress and maybe publishing them?

Fitness Goal

For my fitness goal, I want to go through the Strength Side course that I bought. I will keep track of each day by writing about my progress in my daily note and then writing a comprehensive summary of my experience at the end. I plan to stop lifting weights for this period and see how it affects my body. At the end of this 90 days, I can assess if this is working better or worse for me and go from there.

Definition of Done

I will consider this goal complete if I do at least 3 workouts a week for this quarter and document my findings.

Artistic Goal

For my artistic goal, I want to get back into actively photographing things again. Maybe this means getting outside and shooting images for an hour. Maybe it means editing photos I've taken for an hour. It could be reading photo theory and applying it to my process. Either way, make some art and put it somewhere. If you make prints, hang them in the house or give them away as gifts. I would like to come up with a project or two in this quarter but I would like to let that happen more organically. Maybe that will be my sort of quarterly thesis project or something like that. Spend the last month or so focused on a project and make something specific to show.

Definition of Done

I will consider this goal complete if I am more actively and intentionally capturing images in my day to day and if I have produced something that I am proud of in a way that I make prints and present it as a project by the end of the quarter.

Creative Goal

I struggled with classifying this goal because creative feels like a cop out. I was gonna call this a logic goal or a computer goal but I realized it encompasses more than that. I want to get better at Linux administration. Ultimately this is going to be part of a larger goal of working with Kubernetes in a more regular capacity. Also this is the foundation of my homelab and knowledge base therein. So I feel like this goal is a bit more ambiguous. I want to finish this Udemy course: Linux Sysadmin:Build 5 Hands-On Linux Projects for Real Jobs. But my Goal is to use what I learn in this course to host something on my existing server environment and make it accessible from the public internet. I think everything in this course will cover that and get me to that end. But if it doesn't, I will still use the skills from this course to build the things I am going to host and then explore past it to figure out how to successfully expose my apps to the internet at large without making myself vulnerable to attacks.

Definition of Done

I will consider this goal complete if I have completed the course and have at least one application running and hosted on my local server that I can somehow access from any device via the public internet.

Running Docker Containers Locally

In an effort to learn more about Linux for the purposes of running a homelab and self hosting applications built by me as well as others, I am going through this wonderful course on Udemy. In an effort to better remember everything I learned, I'm documenting some of the processes that I learned to implement a custom Astro application.

Initial Setup

The first thing you need to do is provision a server. There are a whole bunch of ways to achieve this goal and I will leave that to you to decide. My existing home lab environment is running Proxmox which I highly recommend. Especially if you are new to virtualization. Proxmox is a hypervisor that makes provisioning new servers simple and easy. The biggest benefit of a hypervisor like Proxmox is that you can create and delete servers at will without having to re-provision the same machine over and over and over. This is super convenient if you're learning and will be creating lots of short lived servers frequently for the purposes of learning something new.

Setup Ubuntu

After installing Ubuntu (by following the docs), you should setup a static IP address. This is an important step because it gives you a reliable IP by which you can reach your server. It's also a good idea to go to your router settings a restrict the range of IP addresses that your router can use to assign to new devices. Your static IP should exist outside of the range you set in your router to avoid duplicate assignments. Now it's time to install some stuff!

Setup SSH

First, make sure that OpenSSH is installed. Run the following to check the status:

service ssh status

If you see something that looks like the following, you're all set:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; disabled; preset: enabled)
     Active: active (running) since Sun 2024-12-29 20:47:38 UTC; 3 days ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1442 (sshd)
      Tasks: 1 (limit: 2276)
     Memory: 2.8M (peak: 4.5M swap: 608.0K swap peak: 608.0K)
        CPU: 267ms
     CGroup: /system.slice/ssh.service
             └─1442 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

If you see a message indicating that there is no SSH service, then run the following commands to get it installed and running:

sudo apt update && sudo apt install ssh
service ssh start
service ssh status

After running those commands you should see that the service is indeed active.

Install Docker

Next we need to have Docker running in order to have an environment to run containers. As a prerequisite, we need to make sure there are a couple of other packages we need to make sure are installed. Run the following commands:

sudo apt update
sudo apt install apt-transport-https curl

This ensures that we can download the next piece that will actually allow us to download and install Docker.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Now run the following command to add the docker repository to our system:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Finally, we can run the last command that will install docker on our Ubuntu server:

sudo apt update && sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Once everything is installed we can check first to make sure that the service is running

service docker status

You should see something that looks similar to the following:

● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-12-29 21:21:54 UTC; 3 days ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 3035 (dockerd)
      Tasks: 17
     Memory: 673.7M (peak: 722.1M swap: 3.9M swap peak: 3.9M)
        CPU: 59.400s
     CGroup: /system.slice/docker.service
             └─3035 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

BONUS: To run docker without having to type sudo all of the time, run the following command:

sudo usermod -aG docker ${USER}

Once docker is running, run the following to make sure that everything is functioning correctly and then we're good to move on!

docker container run hello-world

Install NVM and Node

The next step is to install support for NVM, Node, and Git to pass projects back and forth so that we can develop them on a work machine and then pull them on this server environment for deployment. So let's get started. First, we need to install Node Version Manager.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Then start NVM with the following:

export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

You should be able to run nvm -v now and see v0.39.7 printed back to you.

Next, it's time to install Node. This is super easy with NVM.

nvm install --lts

Once NVM finishes up, run node -v and you should see a version printed out. So long as you do, Node is installed properly.

Create new Astro app and push to git

Now that our server is setup to handle Node applications, let's bootstrap an example application that you can work with and grow as you see fit.

npm create astro@latest -- --template satnaing/astro-paper

In this example, we are using the astro-paper theme, but feel free to pick whatever you would like. I like starting with a blog. Even if you don't publish what you write, having a place to record and document the things you build is a good thing to have.

Once you have your project setup, push it up to git so that you can pull it down on your work machine and develop.

Create Docker file

One of the reasons we are using the astro-paper theme is that we get a static build from it. This is helpful for the actual deployment process because it makes it easier to stand up a proper web server like NGINX to serve our app. This isn't a necessity, but it is recommended. First, let's create a Dockerfile so that we can build an image of our application to soon run it in our docker instance. At the root of your project, create a new file called Dockerfile and paste the following values:

FROM node:lts AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine AS runtime
COPY ./nginx/nginx.conf /etc/nginx/nginx.conf
COPY --from=build /app/dist /usr/share/nginx/html
EXPOSE 8080

Since we are using NGINX, we will need to include a configuration file for it. At the root of your project, add a directory called nginx and then create a new file nginx/nginx.conf and inside of that new file, paste the following:

worker_processes  1;

events {
  worker_connections  1024;
}

http {
  server {
    listen 8080;
    server_name   _;

    root   /usr/share/nginx/html;
    index  index.html index.htm;
    include /etc/nginx/mime.types;

    gzip on;
    gzip_min_length 1000;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    error_page 404 /404.html;
    location = /404.html {
            root /usr/share/nginx/html;
            internal;
    }

    location / {
            try_files $uri $uri/index.html =404;
    }
  }
}

With these files added, we have all pieces in place to build our application for production deployment. At this point it would be a good idea to make sure that we can see a functional version of our application. The following steps will make that happen.

Build Docker Image

In order to run our application, we'll need a Docker image. One simple command will provide that for us from the existing application code. Run the following to generate the Docker image.

docker build . -t application-name:latest

In the previous command, replace application-name with whatever you want to call your application. This is how you will reference it to run it in Docker. If you plan to push this image up to DockerHub you should amend the previous command slightly.

docker build . -t dockerhub-username/application-name:latest

In this case, substitute dockerhub-username with your actual DockerHub username. If you just plan to run your application in this singular location, you can forgo that extended name. If you decide later that you want to push your image to DockerHub, you can always build a new image with a new tag.

If you want to copy-pasta the exact command, use the following:

docker build . -t astro-blog-example:latest

Run Docker Image

With our new Docker image built, let's run it and make sure that it works.

docker container run -d -p port-on-server:port-exposed-from-image tag-name

Replace these values with values that actually make sense for your specific application:

port-on-server: The port number that you this application will be accessible from on your actual server.
port-exposed-from-image: The port exposed in the Dockerfile. In this example, 8080.
tag-name: Whatever you named your application in the previous step.

Again, if you want to copy-pasta directly, use the following command:

docker container run -d -p 80:8080 astro-blog-example:latest

That command will run an instance of our application on port 80 of our server. Run the following command to confirm that this new instance is running without error:

docker container ls -a

You should see an output similar to the following:

CONTAINER ID   IMAGE                       COMMAND                  CREATED         STATUS         PORTS                                   NAMES
20ad93fe6224   astro-blog-example:latest   "/docker-entrypoint.…"   6 seconds ago   Up 6 seconds   0.0.0.0:80->8080/tcp, :::80->8080/tcp   pedantic_clarke

So long as your output looks similar to that, your application should be running. You should be able to go to your favorite browser on your dev machine, type the ip address of your server, and see the landing page of your application running! Congrats!

Dev vs Prod

Now that we know that our application is capable of getting all the way to our production environment, we can start making it our own! It's a real challenge to develop in this environment though. Now there are certainly ways that we could develop this application here on the server, but it's not the best idea. Mixing your production environment and development environment can get messy really quickly as you can make changes to one that may affect the other.

For this reason, the net step is to use git to commit all of the existing changes (at this point just the initialization of the app), connect to a remote repository on GitHub, and push. For that, I will assume that you are familiar with this process and have a GitHub account.

Make updates to Astro app

With your application pushed to GitHub, you can now pull the repository down to any machine on which you would like to develop. Astro provides a rich developer experience out of the box but I encourage you to explore and see what you can make!

Push to GitHub

Once you have your application in a state that you feel comfortable with and are ready to deploy, push this new version of your code up to GitHub from your dev environment.

Deploy!

The final step is to deploy again! You can repeat this process ad infinitum. Any time you make a new version of your application, go to your server environment, pull the version you wish to deploy, rebuild your docker image (or build with a new version tag), stop your previous example, and run the new one!

At this point, you have a running application! Congratulations! You have deployed an application in your local network completely from scratch! This is a huge accomplishment. But this can also be just another starting point if you'd like. There are plenty of improvements that can be made to this process.

Challenges

If you want to take this a step further, here are a couple of suggestions:

Look into setting up a CI/CD pipeline with something like Jenkins or Github Actions. This will eliminate the need for you to manually pull new versions of your app and make new deploys in Docker.
Use Docker Compose to make more complex deploys. For example you could run another container alongside this application with a database so that you can manage persistent data in your application.
Add authentication so that your application can support multiple users.
Use a service like DuckDNS or some other DNS provider to get a static IP, or some other similar solution, and expose your application to the public internet.

Conclusion

Hopefully this walkthrough has been beneficial and you have a running application somewhere other than your development machine. This is a huge step toward understanding full-stack development. The process and environment that you've just put in place exists as the foundation for many web applications. Granted, most processes are more complex than this. But the general principles remain the same. Continue to make changes and test the limits of Docker to see all of possibilities that exist!

Bash Terminal Shortcuts

ctrl + L - Clears the terminal
ctrl + D - Closes the terminal. Same as the exit command
ctrl + A - Returns cursor to the beginning of the terminal line
ctrl + E - Move the cursor to the end of the line
ctrl + U - Cuts everything before the cursor. This is a great way to clear the line if you've written something that you want to delete
ctrl + C - Stops the current command
ctrl + Z - Puts the current running program to sleep
ctrl + alt + T - Opens a new terminal

Learning in Public: Implementing Signals

In this post, I'll be going through this article to understand creating signals.

What I build will live in this repository. Feel free to check it out if you would like!

Findings

Signals are really cool and are going to be a big part of the web moving forward I think. This sort of pub/sub architecture has always been a big part of the web. So it's increasingly important to be familiar with it. So let's dive into some of what I found interesting and applicable on a broader scale as well as some things that I will do differently in the future.

The `Signal` Class

class Signal {
  constructor(value) {
    this.value = value;
    this.subscribers = [];
  }

  getValue() {
    return this.value;
  }

  setValue(newValue) {
    this.value = newValue;
    this.emit();
  }

  emit() {
    this.subscribers.forEach(subscriber => subscriber(this.value));
  }

  subscribe(callback) {
    this.subscribers.push(callback);
  }
}

Encapsulating this logic into it's own class is a great idea. The real meat of what's happening here though is in that subscribers property.

`createSignal`

export const createSignal = value => {
  const signal = new Signal(value);

  return [
    function value() {
      if (effectCallback) {
        signal.subscribe(effectCallback);
      }
      return signal.getValue();
    },
    function setValue(newVal) {
      signal.setValue(newVal);
    },
  ];
};

`createEffect`

export const createEffect = callback => {
  effectCallback = callback;
  callback();
  effectCallback = null;
};

I am starting a series on building a reactive frontend framework similar to React and probably based more heavily on Chris Ferdinandi's Reef than I want it to be. But that is the matrerial through which I am going to be learning. So that's wont to happen.

VS Code Balance Out

This article is more of a reminder than anything. This video explains everything about this command and how to implement it.

Essentially this is a way to select an entire HTML element with a key binding instead of having to hunt through the document on your own for an opening and closing tag. Super useful.

How to Structure a React Project

One of the biggest problems we face as developers is project or directory structure. It's important to have a set structure for your projects so that as they grow, your code is well organized and easy to navigate. I recently found a way to organize React projects that I personally believe is so good that I want to share it.

Disclaimer: This sort of organization can be used in pretty much any project with minor changes based on the project.

Here is the repo if you want to explore everything.

Components

Starting at the component level, what I like to do is continue to use principles of OOP in all of my JS/TS applications. But This doesn't mean we have to use Classes, Methods, and Properties. If you would like to do that and create instances in a more traditional way, that's fine. But I think that it ignores all of the great things that we get from modern JS/TS. We can still follow SOLID principles without Classes.

component
  |-- component.tsx
  |-- hooks.ts
  |-- index.ts
  |-- styles.css
  |-- test.tsx
  |-- utils.ts

What do each of these files do?

`component.tsx`

Houses everything that is going to be rendered on screen by React. This file should contain as little logic as possible. If you can eliminate it entirely, all the better. Obviously that's not always popular but it should be the goal to keep the component as close to just markup as possible.

`hooks.ts`

For any hooks in the component that are only used in this component. Any hooks that are shared with other components should be pulled up higher into a hooks directory at the root directory or src depending on how your project is structured.

`index.ts`

Is solely our public interface for our component. Anything meant to be exported from this component gets exported from here. For example:

export * from './component';

Those sorts of exports are all that we include here

`styles.css`

Should be fairly self explanitory. This is where we keep styles related to our component. This can also be a JS/TS file if you're using styled components or SASS or anything else so long as it's related to styling.

`test.tsx`

Is where we house the unit tests for our component.

`utils.ts`

Should contain utility functions related specifically to this component. Similar to the hooks file, anything that would be shared between components should be hoisted higher.

Conclusion

This is by no means doctrine and if your codebase dictates something different, go for it. But the idea of encapsulating component logic into a single directory has proven to be extremely helpful in many codebases that I've worked in. The big takeaway here is that OOP doesn't mean Classes. It is a paradigm of the craft of writing code and should be practiced to keep code clean.

Proper (Re)Factoring

Don't factor your code too early! There are plenty of organizational patterns that are essentially universal in an application.

Having a src directory
components - React/Next
utils - every project
routes/views - web anything

These will probably exist in all of your applications/projects/whatever. Dont be afraid of using them. But let your applicaiton be abstract in the beginning. Don't rush to set a structure for how things should be organized, what should constitues a module, what should be a class (or shouldn't), making hooks, making utilities, etc. Just write the code, make the application work, WRITE THE TESTS (re-read that 1000x, get it tattooed on your body, paint it on the walls. Please. Write. Tests.), write documentation, know what it all does.

🚨🚨🚨 BEFORE YOU COMMIT YOUR CODE!, REFACTOR!!! 🚨🚨🚨

Or, when you do it the first time, factor. This is why testing is sooooo important. If you have tests in place for your application, you know that your code functions. If you break tests, you messed up. That's ok. You should mess up. That means you're making progress. Just make sure you don't leave anything messed up.

This is the stage in the development process where you make sure things are organized properly. This is the part where you focus on CODE READABILITY.

Split logic out into the tiniest possible pieces. Make new functions/methods, organize modules differently, split things into utilities. But only in a way that makes sense. And let your code tell you what makes sense. Things to consider:

WTF is this code doing? - Can you answer that quickly? Can you make a TikTok that would allow someone to confidently implement your function?
Is this repetative? - Is this logic (Or similar logic) happening anywhere else? If so, combine it. Pull it into a function. Move that function up the directory tree wherever it makes sense.
Is it verbose? - Can you clean it up at all? Are you over-engineering?
Do my tests still reflect what I want them to? - This is sort of an after refactoring thing. I say sort of because it very much IS refactoring. But, refactoring your tests tend to happen after you refactor the corresponding code. For example:

// Code
function camelCaseToCapitalSnakeCase(str: string): string {
  return str.replace(/[A-Z]/g, letter => `_${letter}`).toUpperCase();
}

// Test
describe('camelCaseToCapitalSnakeCase', () => {
  test('should convert string to capital snake case', () => {
    const testString = 'hereIsMyCamelCaseString';
    const expected = expect('HERE_IS_MY_CAMEL_CASE_STRING');
    const result = camelCaseToCapitalSnakeCase(testString);

    expected.toBe(result);
  });
});

REFACTOR

// Code
function camelToSnakeCase(str: string): string {
  return str.replace(/[A-Z]/g, letter => `_${letter}`);
}

function capitalize(str: string): string {
  return str.toUpperCAse();
}

// Test
describe('camelToSnakeCase', () => {
  test('should convert camel to snake case', () => {
    const testString = 'hereIsMyCamelCaseString';
    const expected = expect('here_is_my_camel_case_string');
    const result = camelToSnakeCase(testString);

    expected.toBe(result);
  });
});

describe('capitalize', () => {
  test('should capitalize given string', () => {
    const testString = 'example';
    const expected = expect('EXAMPLE');
    const result = capitalize(testString);

    expected.toBe(result);
  });
});

While this refactoring essentially happens at the same time (or should), usually the work to the code is done, the initial test fails, the tests are updated to reflect the change to the code.

Refactoring is such an important step in the development of a code base. Mostly because tech debt has a strange way of going unpaid. There are so many minor things that we convince ourselves as devs that we will come back to, or someone will, to "clean up" or "clarify". But that rarely happens. The reality of writing code, especially new code, is that you have more context right now than anyone else, including yourself in a month, is ever going to have again. You know exactly what problem you're trying to solve and why you're doing it the way that you are. So it is your responsibility to try to capture that as much as possible for people in the future, including you. So don't let deadlines get in the way of doing the right thing. Take the extra hour or 4 or 8 to make sure this step happens. Because if you're in an environment that tracks tech debt, great. But the harsh reality is that those tickets will probably get stale before they get played. So do the work now.

Accessing Next Data in Browser

Today's is just a quick post of a discovery from a colleague. On the project that I'm currently assigned to, we are using NextJS to build some pretty amazing tech. One thing that we are constantly running up against is checking the data that we are receiving from one of the handful of APIs from which we are sourcing.

Usually this involves all sorts of looking around inside of the network tab or console logging or all kinds of other work-around, hacky shit to see wtf we're getting. Which is both just bad form and, in most cases, ineffective.

Until this wonderful, beautiful, simple, little one line of code came into all of our lives.

JSON.parse(document.getElementById('__NEXT_DATA__'));

It turns out that next provides you the data that is being provided as props to the page in a serialized JSON object. Just another reason to love tf out of this framework. Here's an example payload that I get from my recipe site:

{
  "props": {
    "pageProps": {
      "recipes": [
        {
          "title": "Bacon Wrapped Jalapeño Poppers",
          "prepTime": "15 minutes",
          "cookTime": "15 minutes",
          "servings": 8,
          "imgUrl": "/img/jalapeno-poppers.jpg",
          "description": "Jalapeños stuffed with cheese and wrapped with bacon.",
          "notes": "Mad easy. Mad delicious. Perfect side dish.",
          "tags": ["keto", "jalapeño", "cheese", "cream cheese", "bacon", "appetizer", "side dish"],
          "content": "\n### Ingredients\n\n- 8 Jalapeños, hollowed\n- 8oz Cream Cheese\n- 8oz shredded cheese of your choice\n- 8 slices bacon\n\n### Instructions\n\n1. Cut a \"T\" into one side of your Jalapeños and scoop out the seeds.\n1. In a bowl, mix cream cheese and shredded cheese until throughly mixed.\n1. Preheat air frier for 10 minutes at 400°\n1. Stuff each pepper with cheese mixture and wrap with one slice of bacon. Wrap the ends of the bacon underneath so they stay together.\n1. Cook for 15 minutes at 350°\n1. Eat them all in one sitting.\n",
          "slug": "bacon-wrapped-jalapeño-poppers"
        }
      ]
    },
    "__N_SSG": true
  },
  "page": "/",
  "query": {},
  "buildId": "development",
  "isFallback": false,
  "gsp": true,
  "scriptLoader": []
}

I truncated the recipe list for readability but you get the idea. Look at how easy and pretty that is! Keep this in mind whenever you're dealing with Next data. This is a game changer folx.

React 18 Third Party Component Rendering Issue

If you ever run into a build error with any package that looks like this:

12:06:28 PM: $ yarn build
12:06:28 PM: yarn run v1.22.10
12:06:28 PM: $ next build
12:06:28 PM: info  - Checking validity of types...
12:06:32 PM: Failed to compile.
12:06:32 PM:
12:06:32 PM: ./pages/_app.tsx:6:11
12:06:32 PM: Type error: 'Component' cannot be used as a JSX component.
12:06:32 PM:   Its element type 'ReactElement<any, any> | Component<{}, any, any> | null' is not a valid JSX element.
12:06:32 PM:     Type 'Component<{}, any, any>' is not assignable to type 'Element | ElementClass | null'.
12:06:32 PM:       Type 'Component<{}, any, any>' is not assignable to type 'ElementClass'.
12:06:32 PM:         The types returned by 'render()' are incompatible between these types.
12:06:32 PM:           Type 'React.ReactNode' is not assignable to type 'import("/opt/build/repo/node_modules/@types/react-syntax-highlighter/node_modules/@types/react/index").ReactNode'.
12:06:32 PM:             Type '{}' is not assignable to type 'ReactNode'.
12:06:32 PM:   4 |
12:06:32 PM:   5 | export default function MyApp({ Component, pageProps }: AppProps) {
12:06:32 PM: > 6 |   return <Component {...pageProps} />;
12:06:32 PM:     |           ^
12:06:32 PM:   7 | }
12:06:32 PM:   8 |
12:06:32 PM: error Command failed with exit code 1. (https://ntl.fyi/exit-code-1)
12:06:32 PM: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The current fix is to add the following to your package.json

}
  // ...
  "resolutions": {
    "@types/react": "17.0.40"
  }
}

Base Path in TypeScript

Whenever working in TypeScript, we deal with importing and exporting modules in our project. This quick post is just a reminder/tutorial for how to set up a base path so that we may reference these modules in a more organized fashion.

Let's begin by creating a new project. We could just create a basic TypeScript app but let's create something a little more practical. We'll be creating a simple NextJS app that uses TypeScript. This is a pretty popular stack these days since it provides a full stack environment with the (current) most popular view library.

To start, let's navigate to a directory to make our project and run the following command.

npx create-next-app base-path-example --ts

This will build out a new Next app called base-path-example with a directory structure that looks like this:

Inside of this project, we're going to include a deeply nested path by adding a few directories inside of pages.

This is going to illustrate what happens when we have to bring in a component from way higher up in the directory tree. Here's what our deeply nested page looks like:

import { Counter } from '../../../../components/counter';

export default function CounterPage() {
  return (
    <div>
      <Counter />
    </div>
  );
}

Notice that we're bringing in this Counter component from the components directory which is four levels up. While this certainly works, it's a little difficult to read and in an app with dozens, or even hundreds of pages, these ../ pieces get annoying to deal with.

To solve this issue, we can make a quick and easy update to our tsconfig.json file which will simplify our imports throughout our entire app. Inside of tsconfig.json, add the following:

// tsconfig.json

"compilerOptions": {
  // ...
  "baseUrl": ".",
  "paths": {
      "@/*": ["./src/*"]
  }
}

This gives us a shorthand to reference the src directory. So now on any of our imports, we can just start with @. Now we can revisit that deeply nested page and make the following change:

import { Counter } from '@/components/counter';

export default function CounterPage() {
  return (
    <div>
      <Counter />
    </div>
  );
}

Now we can reference all directories and files relative to the src directory! This avoids all of the backtracking with ../! As small of a change as this may be, it will save TONS of time with imports and help your code look a lot cleaner in the process.

SIDE NOTE FOR FULL-STACK/API PROJECTS

If you are building something with ts-node or nodemon, you also need to follow this section of the ts-node docs.

CSS Centering

Today we're going to be looking at the different ways in which you can center content in CSS. We're gonna go through a bit of a history lesson as well to illustrate just how amazing modern tools are in comparison to the shit we used to have to write as developers to achieve the same goal. We are going to be looking at examples of centering both horizontally and vertically but all of these examples can be used to accomplish each task individually.

* Only the SCSS related to positioning is included. You will see more in the CodePen.

See the Pen <a href="https://codepen.io/donhamiltoniii/pen/bGpxQKd"> Centering Content in CSS </a> by Don Hamilton III ( <a href="https://codepen.io/donhamiltoniii">@donhamiltoniii</a>) on <a href="https://codepen.io">CodePen</a>. </iframe>

Centering using `display: table`

Let's take a look at the code:

HTML:

<table class="table-centering">
  <tr class="table-centering__row">
    <td class="table-centering__content">:( why?</td>
  </tr>
</table>

SCSS:

.table-centering {
  &__row {
    text-align: center;
    vertical-align: center;
  }
}

As we can see, this achieves what we want. But this is clunky and it violates a few golden rules. First of all, this isn't tabular data so our markup (HTML) isn't semantic. It's also violating separation of concerns as we're using our content layer to handle styling. In older web infrastructure, this method of styling isn't uncommon to see. Though it is INCREDIBLY frowned upon. So, moving on to better options.

Centering using `transform`

Now we'll explore a better (still not best) option. This one came about once we got the transform property available in browsers (2009ish). This is definitely a better way to achieve our centered goal than the previous as it allows us to semantically markup our content as well as abide by separation of concerns by keeping the positioning solely to the style (SCSS) layer. Let's take a look at the code and then go over the pros and cons:

HTML:

<section class="transform-centering">
  <p class="transform-centering__content">:| slightly less why?</p>
</section>

SASS:

.transform-centering {
  position: relative;

  &__content {
    left: 50%;
    position: absolute;
    top: 50%;
    transform: translateX(-50%) translateY(-50%);
  }
}

The first notable difference here is the markup. We only have a containing element and a contained element. Honestly, this is all we should have since we're centering one thing inside of something else. Second, it's semantic. We have a section, which is properly descriptive of what it is/does and the content is enclosed in a p tag which also accurtately describes what we're dealing with. These might seem like trivial details, but I assure you, for many reasons, they are not. This will be beneficial to other developers looking at your code and it will be much more descriptive for screen readers and robots (read Google bots) crawling your page to index it inside of their search algorithms.

Next, let's examine the styling. There are a few more lines of code here to achieve our goal, but what is better about this solution is that everything about the positioning is encapsulated in the style layer.

What I personally dislike (you should too) about this method is that it forces us to alter the position attribute of both of these elements. While this isn't strictly taboo, it can cause unforeseen consequences with other style rules. It is general best practice to avoid manipulating position, BUT, this does work. The quick explanation is that we are pushing the paragraph 50% the width and height of the container. The problem is we are pushing relative to the top left corner of the contained element. So then we are manipulating the contained element to move half of its own width and height up and to the left respectively. In so doing, we center the paragraph in the section.

Centering using `flex`

Finally, we arrive at THE definitive answer for centering in modern web development. The answer is for sure using Flexbox. We need look no further than the code to understand why:

HTML:

<section class="flexbox-centering">
  <p class="flexbox-centering__content">:) very much zero why?</p>
</section>

SCSS:

.flexbox-centering {
  align-items: center;
  display: flex;
  justify-content: center;
}

So this technique combines all of the good parts of the previous examples while omitting all of the bad parts. First, our markup is succinct and semantic. Next, our styling is encapsulated and only needs 3 lines of code to work.

This is partially why flexbox exists. It's all about positioning and ordering elements without having to worry about the content layer. This is exactly how we want our code to work. That is textbook definition of proper separation of concerns.

BONUS Centering using `grid`

It is possible to center content inside of grid containers as well. Though, I would argue that you should use flex by default, sometimes that adds superfluous code which should ALWAYS be avoided if possible. So let's take a look at how we can achieve our goal in grid.

HTML:

<section class="grid-centering">
  <p class="grid-centering__content">:) very much zero why? #2</p>
</section>

SCSS:

.grid-centering {
  align-content: center;
  display: grid;
  justify-items: center;
}

Not much more to review here aside from the fact that we're using a different display value. The only notable difference here is the usage of align-content and justify-items as opposed to their Flexbox counterparts.

Conclusion

We've gone through a bit of a history lesson as far as how we deal with layout and positioning in our web sites/applications. The first two are here for historical reference only. Going forward, we should all be using Flexbox and Grid whenever we're dealing with layout and positioning.

Dondon Developments

Journal Review #1

Components, Data Layers, and the Adapter Pattern

Rambling Thesis Statement

The Adapter Pattern

Example

The Problem

The Solution

Tmux: Getting Started

What is a TMUX?

Tmux Elements

Sessions

Windows

Panes

Keyboard Shortcuts

Windows

Panes

Commands

Configuration

NeoVim Thoughtz

Inserting Characters with Visual Block

TypeScript Patterns

Branded Types

Thought Work Organization Strategy

Working With AI Tools

My Obsidian + Analog Journal Methodology

The Problem I Solved

The Solution: Obsidian as Digital Companion

Core Principle

What Each System Handles

Analog Journal (Primary Thinking Space)

Obsidian (Digital Companion)

Daily Note Philosophy

What It's NOT

What It IS

The Workflow

Morning (Optional)

Throughout the Day

Evening (30 seconds)

Weekly/Monthly Reviews

Key Rules

Success Metrics

Remember

How to Approach New Topics

Linux Directory Structure Reference Guide

Overview

Root Directory Structure

/ (Root Directory)

Essential System Directories

/bin - Essential User Binaries

/sbin - System Binaries

/lib - Essential Libraries

User and Application Directories

/usr - User System Resources

/opt - Optional Software Packages

/home - User Home Directories

/root - Root User Home

Configuration and Data Directories

/etc - System Configuration

/var - Variable Data

Temporary and Runtime Directories

/tmp - Temporary Files

Boot and Hardware Directories

/boot - Boot Files

/dev - Device Files

Virtual Filesystems

/proc - Process Information

/sys - System Information

Mount Point Directories

/mnt - Manual Mount Point

/media - Removable Media

Quick Reference Summary

Best Practices for Students

Common Confusion Points

Dad Thoughtz

Seeds, Not Articles

2025 Quarter Two Goals

Previous Quarter Review

Fitness Goal

Artistic Goal

`/` (Root Directory)

`/bin` - Essential User Binaries

`/sbin` - System Binaries

`/lib` - Essential Libraries

`/usr` - User System Resources

`/opt` - Optional Software Packages

`/home` - User Home Directories

`/root` - Root User Home

`/etc` - System Configuration

`/var` - Variable Data

`/tmp` - Temporary Files

`/boot` - Boot Files

`/dev` - Device Files

`/proc` - Process Information

`/sys` - System Information

`/mnt` - Manual Mount Point

`/media` - Removable Media

The `Signal` Class

`createSignal`

`createEffect`

`component.tsx`

`hooks.ts`

`index.ts`

`styles.css`

`test.tsx`

`utils.ts`

Centering using `display: table`

Centering using `transform`

Centering using `flex`

BONUS Centering using `grid`