I had planned to share this earlier in the month, but ended up writing and posting Using AI and Awareness to Break the Bias Loop instead. This draft sat quietly for a bit. Then I had a conversation with Rachel that reminded me that these kinds of reflections are still worth sharing, even if they come a little later than planned.

So here it is: not a resolution, but a handful of small shifts I'm hoping to make in 2026 to feel a little more clear, focused, and grounded in both work and life.

The Morning Reset

One shift I'm hoping to make this year is treating my morning dog walk as more than just a routine. It's already part of my day, but I want it to become a real mental reset—something that helps me start work with clarity instead of stress. Too often, I go straight from bed to laptop, especially when early meetings or messages are waiting. But I'm realizing there's value in building a buffer—something calm, consistent, and intentional.

What I want is to use that walk as a way to center myself. No podcasts, no inboxes, just a chance to breathe and think about how I want the day to unfold. It's a small window of time, but I think it could help me shift from reactive mode into something more grounded. I haven't figured it out yet, but that's the direction I'm moving toward.

Standing Focus

I've had a standing desk for a while, but I've only used it in bursts. This year, I want to use it more consistently. I think small physical changes might help me stay more present in long stretches of work.

I'm planning to pair it with the Pomodoro Technique: 25-minute sprints with 5-minute breaks. During those breaks, I want to stand, stretch, maybe switch my desk height, or just move a little. I'm hoping that rhythm can bring some energy and intentionality back into my workdays. Especially on the ones that feel like a wall of meetings.

I'm currently looking for a good Pomodoro timer app — if you've got one you like, let me know on BlueSky!

Mental Buffering

One habit I'd like to build is giving myself more mental space between tasks. Right now, I tend to jump from code to meetings to emails without a pause, and it leaves my brain feeling scattered. I'm learning that even a few minutes of transition time can make a difference.

What I want to try is using small buffers (a short walk, a quick personal task, or knocking out an easy five-minute win) before switching gears. These tiny resets could help me bring more focus and calm into the next thing, instead of dragging the last task's residue with me. It's a work in progress, but it feels like a shift worth making.

Eating for Energy

With time zone overlap and short lunch windows, meals during the workday tend to get minimized or rushed. I want to change that. I'm trying to be more intentional about what I eat. I want to prioritize protein to stay steady through the afternoon.

I'm not following a strict plan, just trying to be smarter about prep. I use my myrecipes.com account to collect high-protein recipes that are quick to prep or batch friendly. That site makes it easy to save and organize the meals I actually want to eat. I'll occasionally scroll through on a slow weekend day and add a few more so I'm not defaulting to the same meals over and over. Having solid options ready makes it easier to get back to work feeling focused, not foggy.

Cutting Back, Thinking Clearer

I've been reflecting on how alcohol fits into my day-to-day. While I'm not cutting it out completely, I do want to be more mindful. Even a single drink can mess with sleep, and lately, I've realized how much that impacts my focus, mood, and energy the next day.

So I'm hoping to experiment with cutting back and seeing how it feels over time. I'm also trying to get to bed a little earlier, with the goal of making mornings easier to show up for. This isn't about rigid rules; it's more about building a better foundation and giving myself the chance to feel clearer and more focused when I need it most.

Final Thoughts on a Healthier 2026

I'm not aiming to do all of this perfectly. The real goal is to build habits that help me feel more present, more clear headed, and more grounded; even on the busiest days. Some of these shifts might stick, others might evolve, but they're all pointed in the direction I want to grow.

What small changes are you making this year to stay healthy while working in tech? I'd love to hear your strategies and tips. Feel free to share them with me on BlueSky!

Is this true?
Who benefits from this narrative?
Is this feeding my confirmation bias?

Before we repost, we should slow down just enough to ask better questions. AI can help us do that.

The Power of a Post

This TikTok really hit me in the gut: TikTok by @obriengoespotatoes. It's raw, emotional, and speaks to a very real fear many of us feel. I've been thinking about it a lot lately. It has made me want to reflect on my own feelings about safety, community, and change.

Emotional content sticks. It bypasses our rational brain and appeals straight to our identity. Even though I empathize with the underlying feeling in the video, I also recognize it has a bias: in tone, in framing, and in what it leaves out. That doesn't make it invalid. It makes it powerful and potentially dangerous if consumed without critical thought.

Same goes for this Facebook post, which has been reshared by some people I know. It reinforces a perspective that's already popular with my friends; but how much of it is fact, and how much of it is narrative?

Engagement Amplifies

It's not just resharing that boosts a post's reach. commenting, reacting, quote-posting, or even clicking all feed the algorithm data. Every interaction; whether you agree, disagree, or are simply outraged; teaches the platform that this content is engaging.

That means:

• Commenting "This is wrong!" still counts as a signal to promote the post.
• Clicking to "read the comments" helps the post get pushed further.
• Arguing under a post you hate still boosts its visibility to people who might not disagree with it.

Social media algorithms don't care what you think. It only needs to know that you're thinking about it and staying engaged. The outrage economy thrives on this.

Sometimes, not engaging at all is the wiser path; not out of avoidance, but as an act of intentional non-amplification. I've personally learned this the hard way. I was defriended by a family member because of how I was baiting them on some of the content they reshared. I disagreed with the post. I was outraged, and instead of stepping away, I leaned into that outrage. I wanted a reaction. And I got one.

That moment forced me to confront something uncomfortable: engaging from anger doesn't just feed the algorithm, it damages relationships. It didn't change his mind. It didn't make the situation better. It only added more heat; and more visibility; to something that was already divisive.

If you're truly trying to reduce the spread of misinformation or inflammatory content, the most powerful move might be no engagement at all. Or better yet, engaging with something constructive instead. Starve the drama. Feed the dialogue.

What You Share, Shapes What You See

Algorithms are reflection machines. When you interact with content that aligns with your worldview, platforms learn: Ah, more of that please. And then, that's what you see. Again and again.

This is how confirmation bias becomes an echo chamber. Over time, it's not that people don't want to "do their own research"; it's that they don't even see the other side anymore. The algorithm has trained them not to.

I've seen this happen firsthand in my own social feeds. The longer I interact with something on TikTok; the more often similar content shows up. The more I engage with a post that aligns with my beliefs; the more my feed fills with that perspective.

Start With AI Before You Repost

I've started thinking of AI as a pause button. It is something that creates just enough space between reaction and response. Here's an easy process to check yourself before you hit share:

1. Do a Sentiment Analysis

I've found that noticing the emotional tone of a post is often the fastest way to see how it's trying to influence me. Before deciding what to believe or how to respond, identify the emotional signals at play.

Use a tool like ChatGPT (or any AI with natural language understanding) to ask:

• What is the emotional tone of this post?
• What emotional response is it trying to evoke?

Paste the post into ChatGPT and prompt it with: “Can you do a sentiment analysis of this text?”
“What emotional language is used, and what feelings might it provoke?”

2. Ask About Bias (Including Your Own)

Bias isn't always obvious and it's not always bad. Recognizing bias helps you see the assumptions shaping the message (and your reaction to it). Before accepting or rejecting a post, ask: Whose perspective is being centered and whose is missing?

Use a tool like ChatGPT to ask:

• Does this post show signs of political, cultural, or ideological bias?
• What assumptions does the author make?
• What perspectives are not represented?

Paste the post into ChatGPT and prompt it with:
“Can you identify any biases in this text?”
“What worldview or position is this post coming from?”
“Who might disagree with this, and why?”

3. Follow the Money

Understanding who funds a message, or who stands to gain from it, can reveal motivations that aren't obvious at first glance. Ask yourself: Is this post truly grassroots, or is there a financial or political engine behind it?

Use a tool like ChatGPT to ask:

• Who owns or funds the outlet or creator behind this post?
• Are there financial, political, or ideological incentives influencing the message?
• Is the content sponsored, monetized, or aligned with a larger agenda?

Paste the post or its source into ChatGPT and prompt it with:
“Who funds or owns this media outlet or creator?”
“Does this platform have known political or commercial affiliations?”
“Is there any conflict of interest that could shape this message?”

4. Ask Who It Helps or Harms

Every post, even if unintentionally, serves a purpose. It supports a narrative, shapes perception, or influences behavior. Ask yourself: Who benefits if I believe this? Who could be hurt by it being shared or taken out of context?

Use a tool like ChatGPT to ask:

• Who is portrayed positively or negatively in this post?
• What action or belief is the post encouraging?
• Could this harm individuals or groups — especially if the information is misleading or incomplete?

Paste the post into ChatGPT and prompt it with:
“Who is this post positioning as the 'hero' or 'villain'?”
“What behavior or emotion is this message trying to drive?”
“Could this content reinforce harmful stereotypes or misinformation?”

Putting This Into Practice

The screenshot above, showing damaged solar panels, came from a recent repost in a Facebook group I'm part of. My first instinct was to jump into the comments.

Instead, this is where theory becomes habit. I spent just a few minutes asking a couple of questions from section four.

• Who funds or owns this media outlet?
• Is there any conflict of interest?

I don't do this every time. We have a motto in our house: Practice over Perfection. The more often I ask these questions, the more natural that pause becomes.

What follows is a simple framework for evaluating content before reacting or resharing.

You can write this out by hand, journal-style. Or you can paste the post into ChatGPT and work through each section there.

If you do this often, consider creating a simple custom GPT or saving a reusable prompt template.

Post Analysis Template

Platform:
Where did you see it? (e.g., Facebook, TikTok, X, Instagram)

Outlet or Creator:
Who posted or published this content?

Emotional Sentiment:
What emotional tone is being used? Is it angry, fearful, hopeful, mocking, etc.?

Observed Bias (if any):
Is there a clear political, cultural, or ideological slant? What perspectives are not being represented?

Funding or Incentives Behind the Source:
Is this person or outlet supported by ad clicks, political donors, or a specific community? Who benefits from this message?

What This Encourages the Viewer to Feel or Do:
Is the post trying to stir outrage? Urge action? Reinforce a belief?

What Context Might Be Missing:
Does the post simplify complex issues? Leave out important facts? Has the story been fact-checked elsewhere?

Browser Extensions That Can Help You Do This

While no tool does it all, here are a few browser extensions that can support this kind of thinking:

Chrome Extensions

• Media Bias / Fact Check
• Bias Finder

Firefox Add-Ons

• Truthly
• LNK Media Bias Analyzer

Tip: I have not personally vetted any of these extensions. Always read reviews before installing any tool, especially those claiming to "detect fake news." No tool is perfect, and some may have their own biases or limitations.

We Need Better Reflexes, Not Just Better Opinions

The problem isn't that people care too much. It's that we often don't stop long enough to care wisely. Sharing emotional content without context is like handing out torches in a dry forest. It feels like action. But it can cause real harm.

I want us to be better than that. I want us to use the tools we now have - AI, transparency tools, even just questions - to check ourselves, and each other.

Not because we want to be "neutral." But because we want to be honest. So the next time something hits your feed and your first reaction is "YES, THIS!!" — pause.

• Breathe.
• Paste it into a tool like ChatGPT.
• Ask some questions.
• Sit with the answers.

Then decide if you want to be part of amplifying it.

And if something hits your feed and your first reaction is "Absolutely not!" or "This is infuriating". Pause there too. That knee-jerk urge to quote-tweet it with outrage, to drop a sarcastic comment, or to drag it into your stories? That's still engagement. Still amplification. Still fuel for the feed. Ask yourself:

• Is this worth engaging with?
• Will it change minds, or just deepen divisions?
• Am I reacting to disinformation; and if so, do I really want to help spread it, even in protest?

We can't control everything about this country or this moment, but we can control how we show up for the conversation — and what we choose to elevate.

The algorithm isn't neutral. But our awareness can be powerful.

A Final Reminder: Be Human First

While AI can help us analyze content, it can't replace our empathy.

Before you repost, take a moment to imagine yourself as the subject of the video, article, or post. Or imagine it is about someone you love; a friend, a sibling, a parent. What would it feel like to read that headline or see that comment? Would it still seem fair? Would it still feel true?

Whether it's a post that confirms something you already believe, or one that makes the 'other side' look awful, we are all human. And that means we owe each other kindness, compassion, and respect; especially when we disagree. Leading with empathy is not weakness. It is strength. It's not perfect and it's slower than outrage. But it is a way forward that doesn't leave us worse off.

Before You Move On...

What is one post you reshared recently that you wish you had looked into more deeply? What did it teach you?

What we share trains the world, and ourselves, on what matters.

As work has shifted toward remote and async-first collaboration, written communication has become the primary interface between humans. Pull requests, issue comments, and Slack threads are more than just artifacts. They are the work. Written text is a lossy medium. It strips away tone, intent, urgency, and emotional nuance. Signals humans rely on to collaborate effectively.

This isn't a new observation. What is new is the scale at which we experience it.

Async by Default, Ambiguity by Accident

Async communication breaks in boring, predictable ways. Without real-time feedback loops, small ambiguities in tone and intent balloon into larger misunderstandings:

• Feedback that reads harsher than intended
• Unclear intent (“Is this a suggestion or a blocker?”)
• Increased cognitive load for readers trying to infer subtext

At staff+ levels, like Staff Engineer or Principal Engineer roles where influence extends beyond a single team, these issues compound fast because your comments travel further than you do. You're often reviewing work across teams, time zones, and domains. You don't always have the luxury of synchronous clarification. Every extra ounce of ambiguity slows decision-making and chips away at trust.

This is where emojis began to matter, not as decoration but as contextual signals.

Emojis as Social and Emotional Metadata

I've come to think of emojis as a kind of shorthand for tone—the stuff you'd normally get from a raised eyebrow or a pause. Linguists and communication researchers increasingly describe emojis as a form of paralinguistic information, the digital equivalent of facial expressions, gestures, and tone of voice. In other words, they don't replace words; they help shape how those words are interpreted.

That framing matches my own experience, and research backs it up:

• Studies of developer communication on GitHub show that emojis are most often used to express sentiment or soften critique—especially in comments where tone matters most. [^1]
• More broadly, research has found that emojis act as emotional signposts, helping readers more accurately interpret a writer's attitude. [^2]
• In longer-running communities, emoji usage also correlates with higher engagement and lower dropout rates. [^3]

They function a bit like log levels for conversation: small signals that help the reader calibrate how much weight or urgency to assign to what follows.

They quietly answer questions like:

• How should I read this?
• How strongly does the author feel about this point?
• Is this encouragement, concern, or caution?

All without adding another paragraph.

Why This Matters for Engineering Leaders

For staff+ engineers, communication isn't just about correctness. It's about keeping work moving and people aligned.

In async environments:

• Small misunderstandings can stall progress for hours or days
• Review feedback that feels sharp—even unintentionally—can discourage contribution
• A lack of visible acknowledgment can make collaborators feel unseen

I've spent months trying to push a plan forward after a request for discussion that never quite landed. In an async environment, silence is rarely neutral. Used intentionally, emojis can help close these gaps by restoring some of the human context that text-only communication strips away.

Emojis didn't become important because teams became more casual. They became important because teams became more distributed, more async, and more dependent on written communication to carry both technical and social meaning.

Emojis in Pull Request Comments

Pull request comments sit at an uncomfortable intersection. They are technical, evaluative, and often time-constrained, but they are also deeply human. This is where people give feedback, challenge decisions, acknowledge effort, and negotiate trade-offs—all without the benefit of tone, timing, or immediate clarification.

At scale, PR comments become one of the highest-risk surfaces for miscommunication in an async workflow.

The Hidden Cost of Ambiguity in Code Review

Most teams understand the mechanics of good code review: be clear, be respectful, focus on the code, not the person. What's harder is managing how feedback is received when it's read hours later, out of context, and often alongside other competing priorities.

A short comment like:

“This logic is unnecessary.”

may be intended as a neutral observation. Without additional signals, it can easily read as dismissive or overly sharp. Engineers—especially those earlier in their careers or working outside their primary domain—tend to fill in missing context pessimistically.

This is where emojis become useful—not as decoration, but as intent markers.

Emojis as Intent and Tone Signals

Research into developer communication shows that emojis are most frequently used to convey sentiment, soften critique, or reinforce intent—particularly in comments where tone matters most. [^1]

Rather than replacing written feedback, they help shape how that feedback is received.

In practice, this shows up in small but meaningful ways:

• 💡 signals a suggestion, not a blocker
• 👍 acknowledges understanding or agreement without adding noise
• 👀 indicates active review, reducing uncertainty during longer feedback cycles

These cues help answer an unspoken question every reader has: How should I read this comment?

Studies outside software engineering support this effect. Research on emoji interpretation shows that emojis function as emotional signposts, helping readers more accurately infer a writer's attitude and reducing the likelihood of negative misinterpretation. [^2] In technical discussions, where precision matters and emotional context is sparse, that additional signal carries disproportionate value.

The Risk of Unshared Meaning

Emojis are not self-documenting. The same emoji can mean different things to different people, teams, or cultures. A 👀 may read as “I'm reviewing” to one person and “I'm skeptical” to another. A 🔥 might signal enthusiasm, urgency, or risk, depending on context.

Without shared expectations, emojis can introduce a new layer of ambiguity rather than removing one.

At higher levels, this matters even more. Your comments carry more perceived weight, and small signals can be over-interpreted.

Why Shared Conventions Matter

The value of emojis in pull request comments doesn't come from the symbols themselves. It comes from shared understanding.

When teams align on what certain emojis mean, they become a lightweight vocabulary for intent, tone, and status. Research suggests that consistent emoji usage correlates with higher engagement and lower dropout rates in remote communities—benefits that depend on predictability and shared norms. [^3]

Used this way, emojis function like any other engineering convention: they reduce cognitive load by making intent explicit.

Making the Convention Part of the Workflow

On my team, we adopted an existing, community-maintained reference: the Code Review Emoji Guide.

https://github.com/erikthedeveloper/code-review-emoji-guide

What makes this guide useful isn't the emojis themselves, but the clarity of intent behind them. A 🔧 signals a required change. A ❓ marks a clarifying question. A ⛏ identifies a non-blocking nit.

Rather than relying on tribal knowledge, we linked the guide directly from our pull request template:

## Code Review Guidance

We use a shared emoji legend to clarify intent in review comments.
Please refer to the Code Review Emoji Guide:
https://github.com/erikthedeveloper/code-review-emoji-guide

Common signals:

- :wrench: — Change requested
- :question: — Clarifying question
- :pick: — Minor nitpick
- :seedling: — Suggestion for future consideration
- :smiley: — Positive feedback or acknowledgment

Embedding this guidance directly into the PR flow made emoji usage intentional rather than performative. Over time, it became part of the team's review culture.

Small Signals, Durable Teams

As engineering teams continue to operate asynchronously, the quality of our written communication matters as much as the quality of our code. Pull requests are no longer just a review mechanism; they are a primary place where trust, shared understanding, and technical judgment are built.

Emojis, used intentionally, help carry context that plain text often loses. They are not a substitute for clear writing or thoughtful feedback. They are small signals that shape how feedback is received and acted upon.

The emojis I reach for most often reflect that mindset. The 🌱 seedling, 🏕️ camping, and 📌 pushpin let me suggest cleanup, refactoring, or future improvements without turning every observation into a required change. That distinction matters. It keeps reviews focused. It respects momentum. And it creates space for improvement without blocking delivery.

At this level, it's not really about emojis. It's about building systems where feedback moves without friction, preserves clarity, and helps teams move forward with confidence. Emojis just happen to be a lightweight, human tool that supports those goals when used with care.

Small conventions, applied consistently, can materially improve how teams collaborate. Emojis are one such convention. Used well, they help make async work not just tolerable, but sustainable.

[^1]: Cao, J., Lu, J., Guo, Z., Li, S., & Chen, X.
A First Look at Emoji Usage on GitHub: An Empirical Study.
https://arxiv.org/pdf/1812.04863.pdf

[^2]: Miller, H., Thebault-Spieker, J., Chang, S., Johnson, I., Terveen, L., & Hecht, B.
“Blissfully Happy” or “Ready to Fight”: Varying Interpretations of Emoji.
https://dl.acm.org/doi/10.1145/2858036.2858380

[^3]: Riordan, M. A.
Emojis as Tools for Emotion Work in Computer-Mediated Communication.
Summary: Emojis help remote workers stay engaged and reduce dropout.
https://www.eurekalert.org/news-releases/940515

The examples in this article come from a real planning session with ChatGPT to find a family vacation spot for the fall.

Use Clear and Specific Language

Avoid vague or ambiguous terms in your prompts. The clearer and more specific you are, the better the AI can understand what you're asking for. Instead of saying "Tell me about vacation spots," try to be more specific: "List five vacation destinations."

Set the Tone or Style You Want

If you're looking for responses in a particular tone (professional, friendly, casual, or funny) just say so. The AI will adapt its wording to match.

Write your response in a casual tone, like you're talking to a friend.

Employ the CARE Method

I wanted to have a little fun with this article, so I had ChatGPT created a CARE Bear to help illustrate the CARE method. The CARE method is a mnemonic to help you remember how to structure your prompts. It stands for: Context, Ask, Rules, and Examples.

The bear is here to remind you to be clear, ask specific questions, set rules, and provide examples when crafting your prompts.

Context

Give background information that sets the scene. This gives the AI a better understanding of what you're looking for. Include giving the AI a specific job title or role to play. So, instead of just asking "Where can my family go on vacation?", you could set up the context by saying:

You are a travel agent specializing in vacation destinations in the United States.

Ask

Clearly state what you want the AI to do or answer. Be direct and specific in your request. For example, instead of saying "Tell me about vacation spots," you could ask:

What are five vacation destinations for a family trip? include details about the drive time, weather, and activities.

Rules

Add any requirements or limitations. This helps narrow down the options and ensures the AI's response aligns with your needs. For my vacation planning prompt, I added:

The destination should be around a 10-hour drive from Iowa. A stop in Rolla, MO should not extend the drive time beyond an additional hour. The weather should be warmer than Iowa in late November. The destination should be family-friendly and have activities for a 15-year-old and two young adults.

Examples

Include sample inputs or outputs to illustrate what you're looking for. These help the AI tailor its answers to your needs.

An example of a suitable destination is Austin, Texas. It has warm weather in late November, is family-friendly, and has activities for teenagers and young adults.

Iterate and Refine

If the AI doesn't give you exactly what you need, don't worry. Rephrase your prompt, add more detail, or ask follow-up questions to guide the conversation.

Can you provide more details about the activities available?

Ask the AI to Improve Your Prompt

You can even ask the AI for help crafting better prompts! Try asking:

• "How can I rephrase this prompt to get better results?"
• "What additional information should I include to make this clearer?"

This is a great way to learn what the AI needs in order to give more helpful answers.

Reuse Prompts That Work

If you find a prompt that gives you great results, save it! You can reuse good prompts for similar tasks or adapt them slightly for new situations. Think of them as templates for future conversations.

Bonus Tip: Start a running document of your best prompts for common tasks such as writing emails, planning events, or summarizing documents.

Conclusion

You don't need to be an AI expert to get great results. By using clear language, setting the tone, and applying the CARE method, you'll get more accurate and useful responses from AI tools like ChatGPT. Treat it like a conversation by asking follow-up questions and clarify your needs. When you find prompts that work well, save them and reuse them as templates.

The key is to be thoughtful and specific. And don't be afraid to experiment.

Happy prompting!

Git is the backbone of modern software development, providing a powerful way to track, manage, and collaborate on code. Whether you're working solo on a passion project, contributing to open-source, or juggling multiple enterprise repositories, Git keeps everything versioned and organized. Like many developers, I use Git both at work and for personal projects. This site is developed using Git and hosted on github.com.

But let's be honest—Git repositories can get messy. Old stashes, merged-but-forgotten branches, and lingering references accumulate, making it harder to navigate and manage your work efficiently.

To tackle this problem, I built git-cleanup, a lightweight bash script designed to keep your repositories neat and clutter-free. It automates the removal of outdated references, so you can focus on writing great code instead of cleaning up after yourself.

Why Git Repositories Get Messy

Over time, repositories accumulate digital debris that can slow you down. Here's what typically happens:

• Forgotten Stashes: Stashed changes often get left behind, creating unnecessary clutter.
• Merged but Undeleted Branches: Once a branch is merged, it's easy to forget about it.
• Detached References: Temporary commit references linger longer than they should.
• Multiple Repositories: If you manage multiple projects, keeping everything tidy can be overwhelming.

If you're like me, all your repositories probably live in a single projects directory, and manually cleaning them up is not how you want to spend your time.

Automating the Cleanup Process

The git-cleanup script automates this tedious process by removing unnecessary references in your Git repositories. It will:

• Fetch updates from remote repositories and prunes any remote-tracking references that no longer exist on the remote.
• Remove local branches that have been deleted on the remote.
• Remove local branches that have been merged into the main branch.
• Prune orphaned objects from the local repository.
• Check for old stashes and notifies if any are found.
• Optionally removes any untracked branches.

How to Use It

You can run the script with the following options:

Usage: ./git_cleanup.sh [-d directory] [-u]

• -d directory: Specify the directory to clean up. Defaults to the current directory (.).
• -u: Removes untracked branches.

If the specified directory contains a .git file, the script will clean up just that directory. This is useful when working in a specific project and you notice things have gotten unwieldy. Otherwise, the script will recurse into child directories to find and clean up any Git repositories.

Making it easier with an Alias

Since I run this cleanup regularly, I made it even simpler with a shell alias. Adding this to your .bashrc or .zshrc file saves even more time:

alias cleanup="sh $PROJECTS/git-cleanup/git_cleanup.sh -d $PROJECTS"

The $PROJECTS is an environment variable that I have set to the directory containing all my projects. This alias will run the git_cleanup.sh script from its checked-out location against the directory specified by $PROJECTS.

Now, cleaning all repositories is just one command away:

> cleanup

Why I’m Sharing This

I know many developers have their own Git cleanup scripts, but I wanted to share mine in a structured, reusable format. *git-cleanup** is open-source, free to use, and available for anyone to enhance.

If you find it useful, give it a try and let me know how it works for you. You can also contribute improvements or suggestions on the git-cleanup repository.

Keeping your Git environment clean doesn't have to be a hassle. Automate it once, and spend more time writing code instead of managing clutter.

Happy coding!

I wanted to bring that same spirit to this site. Sharing those chalkboard quotes online felt like a way to extend our kitchen beyond its walls, letting others connect with the moments and meaning that shaped our family. Sometimes, I imagine visitors reading those quotes and trying to guess what's going on in our lives — what event, challenge, or joy might have inspired the words that week.

The virtual quote board is officially live. You'll find it just below the lead article, featuring the most recent quote pulled straight from our kitchen chalkboard. Clicking on it will take you to a page with past quotes—a growing collection of the words we've shared here. These don't go all the way back to when I first started jotting them down on the board, but they do go back to when I first decided to share them online. It's a small but meaningful step in capturing the moments that shape us.

So how did the Virtual Quote Board come to life?

Upgrading to the Latest Astro Framework

This site is built using the Astro framework, which initially had a somewhat rigid content layer for defining data. Originally, I would have needed a separate file for each quote—something I wanted to avoid. Fortunately, Astro 5.0 introduced updated content APIs that allowed me to consolidate all the data into a single file, making the process far more efficient. I've mentioned before that major version updates can be risky, and the upgrade from Astro 4.x to 5.x was no exception. It required modifying 49 files along the way, but the end result was worth the effort.

Defining the Quote Content Collection

The Astro defineCollection method is used to define a content collection. It requires a loader function to load the data and a schema function to define the structure of the data within the collection. For this, the Zod library is used to define and validate the schema.

const quote = defineCollection({
  loader: file('src/content/data/quote.json'),
  schema: () =>
    z.object({
      text: z.string().min(1, 'Quote text cannot be empty'),
      author: z.string().min(1, 'Author name cannot be empty').default('Anonymous'),
      chalked: z
        .string()
        .date()
        .transform((val) => new Date(val)),
    }),
})

The schema above represents the structure I created for the quotes. The data is stored in an array within a single JSON file, where each entry contains a quote. Each quote consists of the text, the author's name, and the date it was written on the chalkboard. If the author's name is left out, it defaults to "Anonymous," ensuring that the entry is still valid without requiring additional edits.

I chose the property name "chalked" because it felt most representative of the context. Initially, I considered "published," but that seemed ambiguous—it could imply the date the original author published the quote or the date it was published on this site. "Chalked" captures the essence of when the quote first appeared on our kitchen chalkboard.

I considered adding a source citation property, but much of the time, I'm unfamiliar with the origins of the quote.

Designing the Quote Card Components

When displaying quotes, I wanted to use the most semantically correct HTML tags to ensure both accessibility and proper structure. I based my approach on the CSS-Tricks article about quoting in HTML. Following this guidance, I structured the quote text inside a <blockquote> element nested within a <figure>. The author is included in a <figcaption> for proper attribution, and the "chalked" date is displayed using a <time> element for semantic clarity.

Here's an example of the markup:

<figure>
  <blockquote class:list={['text-3xl tracking-wide']}>
    {quote.data.text}
  </blockquote>
  <figcaption>&mdash;&nbsp;{quote.data.author}</figcaption>
</figure>

<time datetime={quote.data.chalked.toISOString()} class:list={['mt-4 block']}>
  {formatDate(quote.data.chalked)}
</time>

This structure ensures the content is both visually appealing and easy to interpret for assistive technologies. By combining semantic HTML with thoughtful styling, the quotes are presented in a way that feels intentional and polished.

I settled on two variations for displaying quotes, both using the same semantic markup as shown above. On the historic quotes page, the design takes a simple approach with a card outline, utilizing the standard fonts and colors consistent with the rest of the site. For the lead variation displayed on the home page, I wanted it to evoke the feel of an actual chalkboard and link to the historic page. To achieve this, I incorporated a chalkboard background image, a thick yellow border, and a font styled to resemble chalk.

<div
  id="quote-card-lead"
  class:list={[
    'bg-black bg-[url("../content/image/chalkboard.jpg")] bg-cover bg-top-left',
    'font-chalk text-base text-slate-300',
    'rounded-md border-4 border-yellow-600',
    'flex h-full min-h-40 flex-col justify-between p-4',
    className,
  ]}
>
</div>

The font-chalk class specifies a custom font family defined in my Tailwind configuration:

chalk: ['Walter Turncoat', ...defaultTheme.fontFamily.sans],

The font, Walter Turncoat, was downloaded and installed from fontsource.org. It is a playful, chalk-like style that adds the perfect touch to bringing the chalkboard theme to life.

Integrating Quote Components Across the Site

I integrated the quote components into two key pages: the home page and the historic quotes page. The home page highlights the most recent quote, while the historic page lists all quotes in descending order based on their chalked dates. To manage this functionality, I created two utility methods to retrieve and sort the quote data.

export const getQuotes = async (limit?: number, exclude?: string): QuotesResponse => {
  const quotes = await getCollection('quote')
  return quotes
    .filter((quote: CollectionEntry<'quote'>) => quote.id != exclude)
    .sort(
      (a: CollectionEntry<'quote'>, b: CollectionEntry<'quote'>) =>
        b.data.chalked.valueOf() - a.data.chalked.valueOf()
    )
    .slice(0, limit)
}

export const getLatestQuote = async (): Promise<CollectionEntry<'quote'>> => {
  const [latest] = await getQuotes(1)
  return latest
}

• getQuotes Method: This retrieves all quote entries from the collection and sorts them by their chalked dates in descending order. It can accept an optional limit parameter to specify the maximum number of quotes to return and an exclude parameter to filter out a specific quote by ID. The method returns an array of quotes based on these parameters.

• getLatestQuote Method: This leverages the getQuotes method with a limit of one, returning the most recent quote as a single entry.

With those two methods defined, wiring up the components becomes straightforward. Below is an example of how the lead quote component is integrated into the home page:

---
/**
 * The home page with a lead article and most recent.
 */
import ArticleCardLead from '@components/ArticleCardLead.astro'
import ArticleGrid from '@components/ArticleGrid.astro'
import BackLink from '@components/BackLink.astro'
import QuoteCardLead from '@components/QuoteCardLead.astro'
import Layout from '@layouts/Layout.astro'
import { getArticles } from '@utils/article'
import { getLatestQuote } from '@utils/quote'
import { getDefaultSite } from '@utils/site'

const articles = await getArticles(9)
const site = await getDefaultSite()
const data = site.data
const lead = articles.shift()
const latest = await getLatestQuote()
---

<Layout site={site}>
  {lead ? <ArticleCardLead article={lead} /> : null}
  <QuoteCardLead quote={latest} class:list={['mt-4']} />
  <ArticleGrid articles={articles} foldCount={4} class:list={['mt-4']} />
  <BackLink name="articles" to={'/article/archive-1'} class:list={['mt-4']} />
</Layout>

Bringing Quotes to Life Online

Developing this feature was both fun and meaningful, offering a little glimpse into the moments that shape life in our house. By sharing these quotes online, I hope to capture some of the spirit behind our family's kitchen chalkboard while making the content easy to explore.

If you're curious about the technical details, the site's code is open source and available online. You can check out the pull request for this feature, along with this article, at the project's repository: agingdeveloper on GitHub.

I had the chance to create a proof-of-concept using Umami, and I thought it would be valuable to share my experience. To demonstrate the usage of Umami, I'm going to replace this sites current analytics implementation with one based on Umami.

Server Setup

The first step is setting up a server to collect analytics. Umami offers a cloud version with various pricing options, including a free tier for hobby sites. Alternatively, you can host Umami on your own server; all you need is a database and server. There are several guides available for self-hosting. Since this is just a demonstration, I'll be running the database and Node.js server locally using Docker.

Step 1: Clone the Umami Repository

To get started, pull the latest source code from the Umami repository using Git:

git clone https://github.com/umami-software/umami.git

Step 2: Start the Docker Containers

Next, use Docker Compose to start the Docker containers with PostgreSQL support:

docker compose up -d

Step 3: Access the Umami Dashboard

Once the Docker containers are up and running, navigate to the local address where the server is running, http://localhost:3000. Log in with the default credentials:

• Username: admin
• Password: umami

Step 4: Add a Website to Track

After logging in, create a website by navigating to Settings > Website and clicking the "Add Website" button. For this example, I'm using The Aging Developer as the site name and localhost as the domain, since this is a local demonstration. Be sure to enter your actual domain if you're setting this up for a live site.

Step 5: Retrieve the Tracking Code

Once the website is saved, click the "Edit" button next to it, then go to the Tracking Code tab. This tab contains a script that needs to be inserted into the site’s HTML to start tracking visits. I'll modify this script in the next section to work with the Astro framework this site is built on.

<script
  defer
  src="http://localhost:3000/script.js"
  data-website-id="46903d23-08ec-4519-9bb2-d6594f1110fa"
></script>

Start Tracking

In Astro components, scripts are hoisted and loaded as JS modules by default. To ensure that our tracking script runs inline and does not get hoisted, we need to modify it accordingly. This script will be placed in the <head> of the page, which is located in the Layout component. In a production environment, I recommend moving the "website-id" into an environment variable and using that in the data-website-id property.

<script
  is:inline
  async
  src="http://localhost:3000/script.js"
  data-website-id="46903d23-08ec-4519-9bb2-d6594f1110fa"
></script>

With that script in place, Umami will automatically start capturing page views. After starting the Astro local development server with npx astro dev and navigating to this article in progress, I received two page view events.

Custom Events

In addition to basic page views, I also want to track clicks on outbound links and instances when a user utilizes the action button to scroll back to the top of the page, using two different techniques.

Scroll Top

The ScrollTop component is a button wrapped in a custom HTML element. This button already has a click listener attached to it. To implement custom tracking, I simply added a call to the tracking function within the listener.

const button = this.querySelector('button')
button?.addEventListener('click', () => {
  window.umami.track('scroll-top')
  window.clearTimeout(timer)
  window.scrollTo({ top: 0, left: 0, behavior: 'smooth' })
})

Outbound Links

Another powerful way Umami allows you to track events is by using a data property that specifies the event name. I created an Astro component called LinkExternal, which serves as a wrapper for all links to external sites. This component includes some default properties already set.

<a
  data-link="external"
  data-umami-event="external-link"
  target="_blank"
  rel="noopener noreferrer"
  href={to}
  class:list={[className]}
  title={title}
>
  <slot />
</a>

If I wanted to track additional dimensions for this event, such as the URL being navigated to, I could use a click handler in conjunction with the tracking function.

Conclusion

As you can see, it is relatively quick and straightforward to start collecting metrics for your site while utilizing an open-source library that helps you stay privacy-focused.

Gatsby Concerns

I believe it's important to carefully manage any changes that could disrupt existing systems. However, I've become increasingly concerned about the future of the Gatsby framework. According to their long term support policy, each version of Gatsby is only supported for one year. The latest major version was released on November 8th, 2022, and since then, there hasn't been any significant feature development. In fact, there's an ongoing discussion within the Gatsby community questioning whether the project has been discontinued. Jared Scott, a member of the community, provided a detailed analysis of recent commits, showing that no substantial updates have been made.

Additionally, Gatsby was acquired by Netlify in February 2023. Shortly after, Netlify experienced a round of layoffs in July 2023, which adds to the uncertainty surrounding Gatsby's future.

Astro Exploration

Given my concerns about Gatsby, I began exploring Astro as an alternative about three weeks ago. Since then, I've made significant changes behind the scenes: transitioning from JavaScript to TypeScript, replacing React components with Astro components, and switching from Material UI to Tailwind for styling. I'll dive deeper into these changes throughout this article. Today, I'm excited to celebrate the launch of The Aging Developer, now completely rewritten using the Astro framework.

Typescript

TypeScript is a version of JavaScript that includes extra features to help developers write more reliable code. One of its key benefits is adding "types" to variables, which means the code can check for certain errors before it even runs. I’ve attempted to switch my site to TypeScript a few times in the past, but it required a lot of setup, and I could never get it quite right. What’s great about Astro is that it comes with built-in TypeScript support, making the transition much smoother. The documentation provided clear instructions, and I was able to get everything set up without much hassle. Previously, with Gatsby, I used a package called prop-types to define the types for my components. Now, with TypeScript, I can easily do this using an interface, which is both simpler and more powerful.

interface Props {
  image: ImageMetadata
  imageAlt?: string
  site: CollectionEntry<'site'>
}

Astro includes a handy check function that automatically scans your code for errors, such as type mismatches, ensuring everything works smoothly before building the site.

Components

Astro components are made up of two main parts. The first part, known as the "frontmatter," contains the component’s script, which runs during the website's build process. The second part is the HTML template, which uses a mix of standard HTML and JSX-like syntax to structure the content. If you need to add interactivity on the client side (like responding to user clicks), you can do this with script tags within the component. Since I only need a small amount of client-side interaction, I opted to use web components for those tasks. For example, I created a component that displays a floating action button (FAB) that lets users quickly scroll back to the top of the page.

<scroll-top class:list={['fixed bottom-8 right-8']}>
  <button
    class:list={[
      'rounded-full bg-secondary-main p-2 text-secondary-contrast opacity-0 shadow-xl',
      'hover:bg-secondary-dark focus:bg-secondary-dark'
    ]}
  >
    <Icon title="Scroll to Top" name="mdi:keyboard-arrow-up" class:list={['h-6 w-6 ']} />
  </button>
</scroll-top>

<script>
  // Define the behaviour for our new type of HTML element.
  class ScrollTop extends HTMLElement {
    constructor() {
      super()

      let timer: number
      const button = this.querySelector('button')
      button?.addEventListener('click', () => {
        window.clearTimeout(timer)
        window.scrollTo({ top: 0, left: 0, behavior: 'smooth' })
      })

      const showButton = () => {
        window.clearTimeout(timer)
        timer = window.setTimeout(() => {
          if (document.body.scrollTop > 100 || document.documentElement.scrollTop > 100) {
            button?.classList.remove('fade-out')
            button?.classList.add('fade-in')
          } else {
            button?.classList.remove('fade-in')
            button?.classList.add('fade-out')
          }
        }, 2.5)
      }

      window.onscroll = () => {
        showButton()
      }
    }
  }

  // Tell the browser to use our ScrollTop class for <scroll-top> elements.
  customElements.define('scroll-top', ScrollTop)
</script>

Astro is compatible with various component libraries, including React, Vue, Svelte, and more. This site initially used React components along with the Material UI component library.

However, as I transitioned to Astro components, I decided to replace the React components entirely. Since Material UI is specifically designed for React, I needed a new approach to styling. I opted for Tailwind CSS, a utility-first CSS framework. Tailwind doesn’t provide pre-made components like Material UI, but it is great in building custom designs. I used TailwindFlex, as a valuable guide for creating the components for the site. The ScrollTop component above demonstrates how Tailwind CSS can be used to achieve the desired look.

  <button
    class:list={[
      'rounded-full bg-secondary-main p-2 text-secondary-contrast opacity-0 shadow-xl',
      'hover:bg-secondary-dark focus:bg-secondary-dark'
    ]}
  >

Content

While Gatsby uses GraphQL to provide data for generating pages, Astro takes a different approach. In Astro, content collections are defined in a configuration file, with Zod used to define the schema for each collection.

const site = defineCollection({
  type: 'data',
  schema: ({ image }) =>
    z.object({
      title: z.string(),
      tagline: z.string(),
      category: z.string(),
      repository: z.string(),
      avatar: image(),
      icon: image(),
      background: z.string(),
      theme: z.string(),
      displayLimit: z.number(),
    }),
})

JSON files in the src/content/site directory are then converted into entries in the collection, which can be retrieved by the filename as their ID:

const site = await getEntry('site', 'agingdeveloper')

Alternatively, a collection can be iterated over as a whole:

export const getArticles = async (limit?: number) => {
  const articles = await getCollection('article')
  return articles
    .sort((a, b) => b.data.published.valueOf() - a.data.published.valueOf())
    .slice(0, limit)
}

Issues

I've encountered a few challenges and limitations. Manipulating image sizes has been difficult when working with endpoint APIs compared to standard pages. Additionally, the site has lost the blurred image placeholders that were easily implemented in Gatsby. Since Astro uses Sharp as its default image service, I believe these issues can be resolved, but they do require some additional effort.

Astro components currently fall short in terms of documentation support, though this is on the roadmap for future updates. Another challenge has been the need to rely on an experimental feature to write unit tests for my components, which isn’t ideal for stability or long-term maintenance.

Impressions

Overall, I have a positive impression of the framework. The speed at which the development server runs and builds is impressive. I can build the entire site with image optimizations from a cold start in under 30 seconds—a significant improvement over the previous setup, where just starting the dev server took longer. Astro delivers the static HTML and CSS generation I had been hoping for, making it a strong choice for content focused projects.

<iframe width="560" height="315" src="https://www.youtube.com/embed/IRFGZpP04MQ?si=lbEt5v6q0TmvDBIw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen

</iframe>

Date Issues

I've had an annoying issue with my GoPro though. Any time a camera isn't used for an extended period of time the date and time can get off. If I haven't used my GoPro in a while and then use it before either manually setting the time or syncing the camera with my phone then the date embedded in the video are off. The date on the camera and the recorded video is something like January 1, 2016 at 12:00 PM.

This happens with lots of different cameras not just this brand. A lot of people probably just live with it or aren't bothered by it. When I go back to look at vacations we've taken, those videos are not listed with the others making them hard to find.

When I first realized I had some files with this problem I started searching for a solution. At that time editing the created date in the GoPro Quick application changed it only in that one application. Changing the file created timestamp in the file system worked for some libraries, but not all of them. Our media library has been spread out over various devices and cloud services over the years and each library has a little bit different algorithm for figuring out timelines. So I needed to figure out a way to fix the created date everywhere we store media.

EXIF Data

All modern devices that take photos or video embed metadata in the those files. That metadata is in a format called EXIF which stands for "Exchangeable image file format". The metadata that is embedded usually includes things like: the camera model, lens, resolution, geolocation, and created timestamp.

Changing those embedded dates is the only way I've found that fixes where these videos show up in timelines across all our media libraries.

The Solution

There is a great command line application exiftool that can be use to view and update the EXIF data in various media file types. For example:

exiftool -d "%Y-%m-%d %H:%M:%S" -CreateDate -s -S GH014479.MP4

Outputs the create date tag using the passed in datetime format "2022-02-19 09:39:21" for the passed in file. It is super powerful, but not very practical for manipulating batches of files.

I wrote a python script that you can find in the exif-dates repo that wraps exiftool specifically for updating batches of GoPro videos and photos all at once.

The script scans the passed in directory finding all mp4, lrv, jpg, and thm files. It extracts the CreateDate from the EXIF metadata of the found files and pulls the timestamp from the date. The time delta that is passed in gets added to the extracted time. Finally, multiple metadata dates get set to the new date with the updated timestamp.

The dates that get set are: CreateDate, TrackCreateDate, TrackModifyDate, MediaCreateDate, and MediaModifyDate.

So for example if you wanted to set all the files in a directory to January 10, 2024 and shift all the times by 4 hours you call the script like:

python exif_dates.py "/Users/richard/copy" --date="2024-01-10" --delta=240

The output of the script lists the file being changed along with the old timestamp and the new timestamp.

The exif-dates script has a dry argument that you can be used to see what will be changed without actually making the change.

To be safe I put all the files I want to update in a separate directory making a backup of them. Then I call the script from the command line with the dry argument to see what the new dates will be. Once I'm satisfied with the output I remove the dry argument and let it run for real. After all the files are updated I move them back to their original locations.

Valid arguments to the script are:

• directory: Full path to the directory to process.
• date: New date in the YYYY-MM-DD format.
• delta: Time delta in minutes.
• dry: Execute as a dry run with no updates.

Conclusion

I wrote the exif-dates script to scratch my own itch and fix a problem that I was having. It has come in handy a few different times when I've figured out I had videos in the wrong spot. It is a little bit technical, but the script is publicly available if you think it might help you fix your own photos and videos.

In some cases, like gatsby-remark-prismjs, it makes more sense to use a library like prism-react-renderer to render codeblocks using a React component.

The Aging Developer was previously using the gatsby-remark-prismjs plugin so I created a Github issue to replace it. I tackled that issue this week. There is a wonderful article that I used as a guide while I did it. That article got me most of the way there, but there were a couple of gotchas that had to be figured while I was doing it. I'm sure others will run into the same issues, so I thought it worthwhile for me to write about it.

To write a custom component that uses the prism-react-renderer package, I first installed the prism-react-renderer package.

npm install prism-react-render

Associating the Component with an MDX Shortcode

The MDXProvider that is used in this site's article template needs to know that a custom component should be used when rendering code blocks. This is done by associating the component with an mdx shortcode.

import MDXCode from '../components/MDXCode'
import MDXLink from '../components/MDXLink'

const components = {
  pre: MDXCode,
  a: MDXLink,
}

;<Grid item md={9} sm={12} xs={12}>
  <MDXProvider components={components}>{children}</MDXProvider>
</Grid>

Here is where this site's setup is a little different from the original article I was using. That article replaces the <pre> tag with a <div> then uses the custom component for <code> tags. What I found is that setup caused the new component to be used for inline code blocks as well. I possibly could have made that work by looking at the type of the children prop being passed in and handling a string differently than a react component. Instead I followed this hashicorp bug comment and matched the component with the <pre> tag instead.

To handle inline code blocks I added some basic css to style it.

code {
  border-radius: 0.3em;
  padding: 0.15em 0.25em;
  /* colors taken from the vsDark them */
  color: rgb(156, 220, 254);
  background-color: rgb(30, 30, 30);
}

Writing the Code Block Component

The MDXProvider will use the MDXCode component when rendering any <pre> tags. So we have to define that component.

export const MDXCode = ({ children }) => {
  if (children.type != 'code') {
    return <pre>{children}</pre>
  }

  const {
    props: { className, children: code },
  } = children
  const language = className?.replace(/language-/, '').trim() || ''

  return (
    <Highlight theme={themes.vsDark} code={code.trim()} language={language}>
      {({ className, style, tokens, getLineProps, getTokenProps }) => (
        <pre className={className} style={{ ...style }}>
          {tokens.map((line, index) => {
            const lineProps = getLineProps({ line, key: index })
            return (
              <div key={index} {...lineProps}>
                {line.map((token, key) => (
                  <span key={key} {...getTokenProps({ token, key })} />
                ))}
              </div>
            )
          })}
        </pre>
      )}
    </Highlight>
  )
}

export default MDXCode

The html <pre> tag defines preformatted text. The MDX outputs that around our code block. There is still a slim chance that tag may be used for something other than code. The first thing our new component does is check that the child react element is of a "type" code. If not the component just wraps the children in a <pre> so that it would have behaved similar to if the site wasn't using a custom component at all.

if (children.type != 'code') {
  return <pre>{children}</pre>
}

Next the component gets the className and the children of the children (which is the actual code). The component then pulls the language from the className. These are then used by the <Highlight> component that prism-react-renderer provides.

const {
  props: { className, children: code },
} = children
const language = className?.replace(/language-/, '').trim() || ''

The rest of the component is pretty much the same as all the examples for using the <Highlight> component including those on the article I was following along with. I am using the vsDark theme and added a little css to add some padding and a border radius.

pre[class*='language-'] {
  border-radius: 0.3em;
  padding: 0.2em 0.6em;
}

The other thing that the component does is trim the code string so as to remove any trailing new lines or spaces. A trailing new line was another issue that I was running into.

I added a snapshot test to make sure the component was rendering like I wanted and a test that made this component wraps a non-code children in a <pre> and return it. With those tests the component was complete and was being used for the MDX.

Removing gatsby-plugin-prismjs

The prismjs package had been installed directly so that one of the built-in themes could be used. I remove the reference to that theme from the PageLayout component. Uninstalled the old plugin and remove the reference to it from the gatsby-config.mjs

-          {
-            resolve: "gatsby-remark-prismjs",
-            options: {
-              classPrefix: "language-",
-              showLineNumbers: false,
-              noInlineHighlight: false,
-            },
-          },

Done

That is it. The gatsby-remark-prismjs package has been removed and the site is now using the prism-react-renderer component instead. The code inside that component is pretty verbose, but it does give my a lot of flexible to how I want to render it. In the future I can add things like line numbers and code highlighting pretty easily if I want.

Gatsby continues to be a set of technologies that are interesting to me and it was announced there is a new feature called Partial Hydration. Since partial hydration seemed like it may fulfill what I was looking for, I rebuilt the site with the most recent version of Gatsby.

This article chronicles my experience in going from the existing Gatsby 2.* based site to a Gatsby 5.* site. I used the original code as guidance, but it is a few years old so I have mainly rebuilt from scratch.

Timeline

I started this endeavor on October 7th, 2023. My hope was to work on this on the weekends when I had time available. Silly me thought I could relaunch fairly quickly but, I have had to scramble to get it out the door prior to the new year.

Partial Hydration

Hydration or re-hydration is the process of using client-side JavaScript to add application state and interactivity to server-rendered HTML. Gatsby apps were always fully hydrated on the client. Gatsby 5 added support for partial hydration. Gatsby uses React server components as the backbone of it's partial hydration implementation. It marks all components as server components starting from the top level pages. Unless specified with the “use client” directive. Gatsby generates RSC files for each page. Instead of fetching page component JavaScript files in the browser now, page-data-rsc.json files are requested. See this article for the details.

After doing some more reading the partial hydration feature there were some caveats that I had to evaluate. It required using an experimental version of react and react-dom. It may not work well with some other new features that improve performance like Slices. It also didn't really seem like what I was looking. I continued the rebuild anyway and hoped there were no show stoppers.

Testing

The first time creating this site, I didn't bother creating unit tests. It was a personal project being built in my spare time. It didn't feel worthwhile to create them. This time around, I've started adding unit tests for at least the components. Each component has a snapshot test and additional tests for branching logic. These will give me some assurance that dependency version bumps have automated testing on them.

Part of the hesitancy with creating tests before was around all the scaffolding needed to stand up basic unit tests. That is still a complaint. I needed to install 7 dev packages, 4 configuration files, and two mock files just to get some very basic testing going. Along with the Gatsby documentation The following articles were a huge help in setting these up.

• Get started with Gatsby and Unit Testing
• How to Test React Components: the Complete Guide

Stumbling Blocks

I hit a few stumbling blocks along the way which made / makes development more difficult than it needed to be. I couldn't get the site to build locally with those experimental react components so the rebuild was done using the long term releases instead which meant no partial hydration.

Module not found: Error: Can't resolve '@mdx-js/react'

Material UI Upgrade

Doing this upgrade I went up a major version of Material UI. Between the versions the import paths all changed. The paths went from "@material-ui" to "@mui/material/". Another big change to deal with was going from JSS to Emotion for the default styling. This meant a whole new syntax when wanting to override the theme.

I had to switch from doing something like:

const useStyles = makeStyles((theme) => ({
  cardContent: {
    margin: 0,
    paddingTop: theme.spacing(1),
  },
});

const classes = useStyles();
<CardContent className={classes.cardContent}>

to the sx syntax:

<CardContent component="p"
  sx={{
    m: 0,
    pt: 1,
    "&:last-child": {
      pb: 1.5,
    },
  }}>

Common JS vs ES Modules

I started out with the react components for this build using the ES modules syntax for imports and exports. I also started to switch over Gatsby files to that format as well. The eslint configuration is setup using the module syntax. I then started to run into some import problems with the slugify library in my unit tests. This lead me down a rabbit hole where I learned Jest only has experimental support for ES Modules and Gatsby also only has partial support. If I specify "module" as the type in my package.json then the gatsby develop command starts failing trying to load a file from cache without an extension on it.

I ended up sticking with using the ES Module syntax where possible. I have the type set in package.json to commonjs, to act as the default syntax, but I used the ES Module syntax in .mjs files for Gatsby and in the .jsx files for React.

NPM Segfault

While working, I usually run gatsby develop from the command line to view updates to the site in real time. When I need to stop the process, I use Ctrl+C to send a SIGINT. Whenever I try to run either the build or develop commands after that I get a segfault exception. At first I would quit the terminal and restart it, which took a long time. Eventually, I figured out I could run gatsby clean in between and it would avoid the failure. Because of this, I now run the below command every time.

npm run clean && npm run develop

The Results

There were a few stumbling blocks that slowed development, but I feel like the code is to the stage where I can replace the current deploy. I've made a fair amount of improvements to the site and code health along the way. I've also removed some features. Some of those trims are likely to be permanent where others are only going to be temporary.

Improvements

The front page of the site has been tweaked to have a new hero image component on the top, and then a grid of horizontal article cards below it. This replaces the vertical cards with badging on the new articles. The badge was some of the client-side interactions that I thought would be used with partial hydration. Instead this new layout freshens up the site a little bit.

The article pages have the author byline and time to read moved around with some space added for a related articles feature that I'm planning in the future. The hero / featured image on the article has been wrapped in a <figure> tag with credits for the image now in a <figcaption>.

I have added JSDoc strings to all the react components. Those can be generated via npm run docs. I am going to continue to make improvements to that documentation and look to see if I can use something like a github action to automatically generate new documentation when merging pull requests into master.

Almost all the components now have prop-type validation. There are a few tests that break the validation, but the deployed site has all console errors taken care of. I had to comment out some lint rules and not provide prop-types for the Head hook that Gatsby provides as that caused problems during the build.

I previously had support for guest authors. When I was first looking to rebuild I thought that might be a feature that hit the cutting room floor. The mappings in the gatsby-config file was not very robust and honestly no one else is going to publish to this thing. However, getting author support re-added was pretty easy, and I like the way I did it. Instead of an author subdirectory in the data folder, I have a single author.yaml file now. The file contains a list of author nodes. I then added some schema customization to the gatsby-node file that maps the author in the mdx frontmatter to the AuthorYaml node via a "slug" property in the yaml.

export const createSchemaCustomization = ({ actions, schema }) => {
  const { createTypes } = actions
  const typeDefs = [
    'type Mdx implements Node { frontmatter: Frontmatter }',
    schema.buildObjectType({
      name: 'Frontmatter',
      fields: {
        author: {
          type: 'AuthorYaml',
          resolve: (source, args, context, info) => {
            return context.nodeModel.findOne({
              type: 'AuthorYaml',
              query: {
                filter: { slug: { eq: source.author } },
              },
            })
          },
        },
      },
    }),
  ]
  createTypes(typeDefs)
}

Before the rebuild all links in the mdx content files were rendered as regular anchors tags. I was able to replace those anchors with a new MDXLink component. This component tests the href. If the href is a relative url then the internal Gatsby link component is used. If the url starts out with the same host as the site then the href is converted to a relative link. Otherwise, an external link is used. This is done by using the components property of the MDXProvider.

const components = {
  a: MDXLink,
};
...
<MDXProvider components={components}>
  {children}
</MDXProvider>

Trims

These are things that did not make the rebuild. Some of them are coming back shortly, but others are likely gone for good.

• RSS Support: this will be re-added shortly via issue #580.
• Comments: I have an issue to re-evaluate this, but they are probably gone for good.
• Top Level Navigation: These links are not how people interact with the site. They are being replaced with a searchbox instead.

Take Aways

All-in-all I think the site is in pretty good shape now and should be easier to maintain. I have some immediate improvements that I want to make. I also have a few article ideas floating around (including the distributed authorization series I previously promised). Doing this rework has also rekindled some of the enjoyment I use to have doing this kind of development. That joy has been lacking a little bit lately so this rebuild was worth it just for that.

I have spent large portions of my career on authorization related development and it is something that I can put a spotlight on here. This article explores some of the basics of authorization, what it means, and a few ways to do authorization in microservice environments. Subsequent articles will follow-up with some more concrete examples using different libraries and frameworks.

Authentication is not Authorization

Authorization, abbreviated as Authz, is the act of granting or denying access to a resource. This is often confused with Authentication (Authn) which is the process of confirming the identity of a user or service. These two "Auths" are often intertwined and get easily confused with one another. Frequently, the first step in authorizing a request is making sure that it originates from someone who has been authenticated. However, just being authenticated is often not enough to prove that you are authorized. The Authn and Authz systems can be highly coupled or can be completely separate from one another.

This article will not really go into the mechanics of authentication. Authentication is not as implementation dependent as authorization and there are lots of off the shelf solutions for authentication that can be integrated fairly easily.

Common Access Control Models

An access control model is the method used in authorization systems to determine who or what should be granted or denied access to a resource. When talking about the "who or what", I will refer to them as a principal. Regardless of the system that is being used for authorization one of these five "Access Control" models will likely be used. I have the most experience with discretionary and role based access control and those will be used as examples in the follow-up articles.

Mandatory Access Control

<abbr title="Mandatory Access Control">MAC</abbr> is a static access control method. Resources are classified using labels or levels. Users are also classified with the same labels. A user can access a resource if they have the same or greater label. When you hear someone has been granted "Top Secret" clearance that is an example of a MAC implementation.

Discretionary Access Control

When using the <abbr title="Discretinary Access Control">DAC</abbr> method the owner of the resource decides who can access it. An <abbr title="Access Control List">ACL</abbr> controls who has access to the resource and the data owner sets the permissions. The permissions identify what actions the principal can perform on the resource. The file system is a classic example of a DAC. The permissions in that case are "read", "write", and "execute".

Role Based Access Control

When using <abbr title="Role Based Access Control">RBAC</abbr> access is determined based on the role a principal is given. The role may be a job position, group membership, or security level. The role is granted or denied access to the resource.

Rule-Based Access Control

<abbr title="Rule based access control">RB-AC</abbr> is based on rules to deny or allow access to resources. This is typically seen most often in thing like network devices where ACLs determine which IPs or port numbers are allowed through, and this is done using rules.

Attribute-Based Access Control (ABAC) Model

<abbr title="Attribute Based Access Control">ABAC</abbr> allows or denies access based on attributes. These can be the attributes of a particular person, of a resource, or of an environment. Attributes may be the Subject (height of a person in an amusement park), Resource (software that only runs on a particular operating system or website), or Environmental (time of day or length of activity time passed).

The Parts of an Authorization System

I've spent a lot of time thinking about and working with authorization systems, but it wasn't until the last few years that I internalized the parts involved in authorization. Regardless of the system being used or if you have a single or multiple services, these parts make up an authorization system. When deciding on an authorization system these parts should be kept in mind.

<dl> <dt>Enforcement Point</dt> <dd> The <em>Enforcement Point</em> is the spot in your software where you are going to enforce an authorization decision. In a client server application there would likely be two enforcement points. In the client when deciding to show or hide elements based on an authorization decision. For example disabling a create button if a user doesn't have permission to create an object. The other point would be on the server, usually at the control or service layer. You must always double check authorization at the service layer as someone could simply craft the request without actually using the UI elements. </dd> <dt>Decision Point</dt> <dd> The <em>Decision Point</em> is the spot where the decision is made to grant access to a resource. This may be the same place as enforcement or it could be somewhere completely different. The decision point is responsible for gathering all the information required to make an authorization decision, making that decision, and returning the results to the enforcement point so that the decision can be enforced. </dd> <dt>Information Point</dt> <dd> The <em>Information Point</em> is where all the information that is needed to make an authorization decision are gathered. It can be co-located with other points in the authorization process or it can be separate. In a MAC control system the information needed would be the access level of the resource being accessed and the level of the principal doing the action. </dd> <dt>Administration Point</dt> <dd> The <em>Administration Point</em> is the place where the policies for an access control method are authored and/or managed. This may also be the point where the information to make a decision is managed. </dd> </dl>

These terms were popularized by the <abbr title="eXtensible Access Control Markup Language">XACML</abbr> standard that was first ratified in 2003 and last updated in 2017. Below is a diagram from axiomatic showing off these parts.

If any of the above authorization points is not co-located it is important that the communication between them is secured. It is also critical that if the communication fails between the points that the enforcement fails in the way that is most important to your application. In a lot of applications this would mean to deny access by default.

Authorization System Patterns

When doing authorization in microservices there are a few approaches that emerge. It's worth spending a little bit of time on each approach since they have various pros and cons. It also allows us to examine where each part of the authorization system is implemented.

Local Authorization

In the local authorization pattern the individual resource services are responsible for developing their own authentication and authorization of a principal. The resource service is responsible for making all it's authorization decisions.

Pros:

• Each service can implement the authorization mechanisms best suited for that service.
• There is no communication overhead or dependency on other services.

Cons:

• It's hard to understand why a principal has access to one resource and not another.
• Each team needs to know and understand the access controls for the system.
• Changing the access control system globally becomes extremely difficult.

Centralized Authorization

In the centralized authorization pattern then the resource services hands off all responsibility for authentication and authorization to a centralized service. The access control decision is made at the centralized service and returned.

Pros

• There is less duplicate code.
• It's easier to determine why a principal was given access to a resource.
• It's easier to make global changes to those mechanisms.

Cons

• There is an extra network request involved in accessing a resource.
• Resource services are dependent on another service.

Local Decision / Centralized Policy

This is a hybrid approach that combines the strengths of the previous two patterns. In this pattern the decision to allow access to a resource is made at the resource service, yet the access control mechanisms are defined and maintained at a central service.

Pros

• There is no network request when making decisions.
• There is less duplicate code.
• It's easier to determine why a principal was given access to a resource.
• It's easier to make global changes to those mechanisms.

Cons

• All information for authorization needs to be present at the resource service.

Local Decision / Centralized Policy systems have been a growing trend in recent years. These types of authorization systems have a meta-model that is used to describe what access control mechanisms are in use by your resource services (policies). Information can then be applied against the meta-model to make an authorization decision.

I believe these policy systems will be the most common pattern for doing authorization in microservices moving forward.

Follow Up

In my next article in this series I am going to explore what it looks like to do authorization using some policy based authorization systems: Casbin and Open Policy Agent.

I'll demonstrate what it looks like to model some of the various forms of access control and how you might gather the information that needs to be supplied to the authz system so that it can produce an access control decision.

Cost

As a family of five we knew that this experience was not going to be cheap. The cost of the tickets to get into the park vary based on the day. Our cost was roughly $140 per person per day. That meant the upfront cost to walk through the gates was around $1,400. Since this was an expected cost, it really wasn't one of our main issues. The systemic additional expenses the park charges for virtually everything was an issue. It is a reoccurring theme you will see running throughout the rest of this article.

Lightning Lanes

There are two basic types of queues / lanes available for attractions at the parks: "Standby" and "Lightning Lanes". Standby lanes are your traditional queues where you just wait in line for the ride. The Lightning Lanes bypass large sections of the Standby lane, but you must first get a pass and wait in a virtual queue until it is your time for the attraction. The Disney app shows the lane information for each ride.

The "Lightning Lanes" can save you a lot of time, but you can't just access them. There are two types of passes available to gain access to these queues, Genie+ is the replacement for the old Fast Pass system. The Genie+ service is $15 per person per day and gives you Lightning Lane access to a selection of attractions per park (excluding all the tent pole ones that you really want access to). A major caveat and drawback of the service is you can only have one Genie+ pass active at a time. That means that if it is 9am and a select a pass that is for 1pm then you can not make another selection until after 1 o'clock. The time slots for these passes fill up fast as well.

The only way to gain lightning lane access to the crowd favorite rides like "Star Wars Rise of the Resistance" or "Seven Dwarfs Mine Train" is to pay for individual passes.

We were going to be at the parks the weekend prior to presidents day weekend. The forecasted crowds were not suppose to be that bad, 5 and 6 on a scale of 1 to 10. Since we were only going to be at the parks for two days, we knew that we would have to minimize our wait times if we were going to be able to ride the most iconic rides. We opted into purchasing Genie+ for everybody ($150). The initial plan was to not buy any of the individual passes.

The lightning lanes require scanning your admission ticket to make sure it is your turn to enter the attraction. Our tickets were emailed to us, which we could then access through the Disney app on the phone. If we were to use the app to scan the tickets at each of the Lightning Lanes I would have had to swipe through 5 different tickets each time and we would not have been able to split up. We opted into purchasing magic bands, roughly $30 each, for everyone instead. These bands could be used at the gate and at each attraction for the Lightning Lanes.

I don't really feel like Genie+ was worth it for us. We were only able to use it twice each day. The second day we had hoped to book a pass through Genie+ for Tower of Terror, but by 10 o'clock in the morning the time for the ride was already late at night. Although, we hadn't planned on purchasing individual Lightning Lanes, the crowd levels were much high than anticipated so we did end up buying them for three rides (another $285).

Temporarily Closed

Splash mountain closed in January and it was suppose to open back up on the day that we were going to be at Magic Kingdom. It did eventually open that day; one hour before park close. That was a foreshadowing of the problems with attraction availability. We decided to take the Monorail in when we first got to the park. The train we decided to take was sitting on the track when we got up to it, but they wouldn't let us on right away. Eventually the operators did let us on just to ask us to get back off again. Apparently there was a problem with that particular train and they had to remove it from the rail and bring in a new one. So we started the day with about a 30 minute delay just getting into the park. Space mountain is an iconic ride that we had wanted to do as a family. It is Temporarily Closed right now as I write this article. It was maybe open for a couple of hours that day. We even paid for a Lightning Lane to ride it, but when our time came around the ride was down again and it wasn't going open back up before park close. At one point while we were at Magic Kingdom the following rides were all temporarily closed at the same time.

• Splash Mountain
• Space Mountain
• Big Thunder Mountain
• Pirates of the Caribbean
• Jungle Cruise

According to Touring Plans a full 10% of the attractions were unavailable that day.

The attraction availability issues pushed crowds to the other areas of the park making it super crowded. Hollywood Studios was not immune to these issues either. Rise of the Resistance did not open in the morning when it was suppose to and it shut down for around three hours in the middle of the day. When that ride did reopen so many people had Lightning Lane passes, including us, that it made the standby line irrelevant. Similar to this Disney Fanatic article.

Crowds

The forecasted crowd level for the day we were to be at Magic Kingdom was a 5. Attendance was measured at a 9 based on actual attendance and attraction closures. This made it very hard to get around and made the lines for everything longer than usual (2 hours was pretty common). The attraction operators on more than one occasion ask people to scoot closer together and "we would get on faster". I don't think they know how ride capacity actually works …

Online Food Ordering

Disney really advertises and pushes for you to use the app to order the food online. We did this for the majority of our food, but we had some gift cards to use so we didn't do it for all of them. It was a disappointment that we couldn't load the gift card into the app and use those for the payment and it was sometimes a hassle to go to an actual cashier. The whole mobile food ordering is just another queueing system in disguise. After entering your order, the app asks you to press a button when you are close to the venue. Your order isn't actually submitted until that point. The app will then give you a time to come back when your order will be ready. It also notifies you of the line to get into when that time comes. Your order isn't actually ready when you are notified. When you get to the window / person you were directed to is when your order is actually put together.

Aloha Isle is the only place in Magic Kingdom where you can get a Dole whip. It is also a spot in the park with terrible mobile and wifi reception. When trying to order the Dole whips we spent over an hour from order to pick up time.

Return

If you look online, you will find a growing list of people unhappy with the way Disney is handling their parks. I think overall our family has enjoyed Universal Studios much more. So I think we would be more inclined to return there instead of Disney. I would go back to Disney again, but I would first like to see them make some changes first. The Genie+, individual Lightning Lane purchases, and mobile food ordering all feel like broken experiences that need to improve.

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

These rules allow people to reason about the kinds of changes that occurred between one release and the next one. A MAJOR version change implies some sort of breaking change. Breaking changes are disruptive and should be considered "harmful".

Harmful Major Release

Gatsby is the underlying framework used to power this site. It and all it's dependencies follow this SemVer pattern. There has been a fair amount of time, as you can tell, that has elapsed since the last time the site has been updated. Gatsby had put out a major release going from 2.x to 3.x (It is above 4.0.0 now). These releases have had backward incompatible changes.

I've spent some time trying to move up to a more recent major version. The changes are disruptive enough that it has taken me more time and energy than I was willing or able to spend to make the upgrade. I am still planning on keeping this site going and up to date, but at this point I think the easiest path is to going to be to rebuild from scratch. I haven't decided yet if I'll stick with Gatsby or try something else at this point.

This situation is not unique. I've seen it countless times in my software development career. A major release of a dependency causes such problems for it's consumers that the consumers either have to spend a large amount of time forward fixing or they may find it easier to just replace the dependency with something else.

Mitigation Techniques

A major release does not have to be painful. There are some strategies by both the dependency producer and consumer that can help mitigate these kinds of problems.

Dependency Producer

As the producer of APIs or libraries that others rely on, you have an obligation to make updating that dependency as easy as possible.

• When making a breaking change then take a long time to consider the reason why. Any breaking change causes significant disruption to downstream developers and should be avoided when possible. There are some legitimate reasons why you must have a breaking change, for example mitigating a security issue.

• Avoid "Big Bang" releases. A “Big Bang” release is when many different features, bug fixes, improvements, or any type of changes go out in the same release. These types of releases almost always cause problems. Consider limiting the number of breaking changes allowed for any single major release.

• Limit how often you cut a major release. You do not want to include too many breaking change in any one major release. You also do not want to have major releases too often. Every major release requires some level of effort on your consumers. The more burden you put on them to keep up to date the less likely they are to continue using your software.

• A companion strategy may be to provide a "Long Term Support" (LTS) release. These are major releases that will continue to get security and maintenance for a long period of time. The LTS versions are considered to be the most stable releases which undergoes extensive testing and mostly includes years of improvements along the way. This gives your consumers confidence to use your software without having to worry about keeping up with every new feature release you put out there.

• Gradually replace or remove APIs. Introduce a new API to be used as a replacement in one release, marking the old API as deprecated, then remove the deprecated API in a future later release. Deprecation should include meaningful warnings about the usage of the deprecated API, what replaces it, and when you need to stop using it by. This gives consumers some time to make the switch over without introducing an instant failure.

• Provide clear and easy to find documentation (outside of the runtime) around a breaking change being made. You should include details like: Why is the change being made, instructions on how to update usage, and timelines as to when usage must be updated by.

• Try not to introduce breaking changes accidentally. I've seen in both major and minor versions where a change was introduced that was breaking, but not marked as such. When and what type of exception being thrown is part of an API's contract and is a common cause of these kinds of accidental breakage.

Dependency Consumer

As a consumer of a library, framework, or API; you have less control in mitigating breaking changes. There are still a few things that can be done to lessen these issues.

• Know your direct and transitive dependencies. Every project and package ecosystem is a little bit different. It is best to at least have some basic knowledge of what your dependencies are. As well as what the release schedule tends to look like for those dependencies. Every package manager has some way to view your dependency tree. npm has the list command where the depth argument lets you specify how deep down the dependency tree to go.

npm list --depth=4

• Automate dependency updates. There are automatic tools to help keep your dependencies up to date. One example of this is Dependabot on github. You can specify on a per repo basis what package manager is being used, number of open pull requests allowed, the update frequency, and more. This will automatically create pull requests when a new version of a dependency is release. It does not help resolve any breaking changes that may be in the release.

• If your dependency provides an LTS release and you are mildly averse to having to keep up with someone elses release schedule then pin to that LTS release. This will allow you to have a much more controlled updated schedule. You usually only see these supported for Operating Systems and programming languages, but those are dependencies too.

• Read the documentation. Regardless of how your projects dependencies are kept up to date there will be times where you will need to fix breaking changes. If the dependencies is a major one then they may provide an upgrade guide similar to this Gatsby v2 to v3 guide. When a migration guide isn't provided then you will likely have to read through a changelog or individual commits.

Real World

Your major version strategy may be great, but there are always complications in the real world. Here are just a few examples:

python 3.x was largely incompatible with 2.x, especially in the handling of strings. Python 3 was first released in 2008 and the 2.x line of Python was deprecated with 2.7 being the LTS release in 2010. December of 2020 was the end of life for the Python 2.x release line. That is 10 years of long term support and companies are still spending millions of man hours making there codebases 3.x compatible. One could argue 10 years is too long even for an LTS release.

The popular Java logging library log4j had a remote code execution vulnerability discovered in December of last year. The vulnerability related to the handling of LDAP and JNDI urls. One of the maintainers tweeted

Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.

The key takeaway from that tweet being the second sentence. It is not worth keeping a bad feature or API just for the sake of "backward compatibility".

Conclusion

Major releases are always some form of disruption and can be considered harmful. Everyone should seriously weigh the need for a new major release against the effort required by the downstream developers.

RSS, RDF Site Summary, Really Simple Syndication, Rich Site Syndication, etc... is a computer readable file format that websites publish to notify systems that there has been an update to the site. A link element is placed in the head of the site to allow the auto-discovery of these files. The "feeds" could then be used for various purposes one of which is that they were often aggregated in a news aggregator/reader.

RSS was at it's height in popularity during the early Web 2.0 days prior to walled gardens such as Facebook taking over. During this time the Chrome & Firefox browsers built in support for these feeds. Google, Digg, and Mac had very popular feed readers. It was all the rage.

The Death spiral

With the rise of non-rss based feeds in Facebook and Twitter, as well as the increase of advertisements on sites, companies no longer wanted you to experience their content outside of their site. Usage of these tools declined. This produced what looked like a death spiral for the format. Firefox dropped its RSS button in 2011, Apple dropped RSS out of OS X Mountain Lion, and Google pulled its Reader in 2013.

The RSS Advisory Board latest news is from 2014.

Continued use

People are still using RSS, and publishing of the format has actually seen an upward trend in the last couple of years. Some people have become increasingly disenfranchised by the way social platforms use their algorithms to decide which news should show up in your feed. These people are turning back to RSS and feed readers as a way to control their own content consumption.

I have personally never stopped using an news reader. I use Feedly for the local news as well as to stay up to date on specific categories of content that I'm interested in.

Because of this, I thought it was important to include feed support on this site.

Adding support

There are several plugins to add feed support to gatsby based sites. I tried to use one of these, but there were a few drawbacks. I use MDX which is markdown with JSX and not all the plugins support it. Several of them also require using graphql in the gatsby-config file to customize what is shown in the feed. That in and of itself isn't too bad, but I'm trying to keep code out of configuration files. So instead of using one of the pre-built plugins, I rolled my own support.

The first thing I did was add the feed library as a dependency. It does all the heavy lifting for creating RSS 2.0, JSON Feed 1.0, and Atom 1.0 formats.

npm install --save feed

Code in the gatsby-node.js file is run as part of the process of building the site. At the end of the production build process the onPostBuild method is called. This is the callback I used to create the feed files. You can see the full implementation here.

The posts are sorted in the graphql by date then title.

      allMdx(
        sort: { order: DESC, fields: [frontmatter___date, frontmatter___title] }
      )
  `);

The feed library does most of the heavy lifting here. I just pass the properties the mdx nodes in the graph into it.

articles.map(({ node }) => {
  const { title, slug, description, date } = node.frontmatter
  const author = node.frontmatter.author
  const image = node.frontmatter.image.childImageSharp.fixed
  const asDate = moment(date).toDate()

  return feed.addItem({
    title: title,
    id: slug,
    link: `${metadata.siteUrl}/article/${slug}`,
    description: description,
    published: asDate,
    published: asDate,
    content: node.html,
    author: {
      name: author.name,
      email: author.email,
      link: `${metadata.siteUrl}/author/${author.id}`,
    },
    image: {
      url: `${metadata.siteUrl}${image.src}`,
    },
  })
})

I created a FeedLinks component that is used for the auto-discovery links that go in the head of the site.

const FeedLinks = ({ siteName, siteUrl }) => {
  return (
    <Helmet>
      {feedData.map(({ postFix, type, path }) => {
        return (
          <link
            rel="alternate"
            type={type}
            title={`${siteName} ${postFix}`}
            href={`${siteUrl}${path}`}
            key={path}
          />
        )
      })}
    </Helmet>
  )
}

To ease discovery I also placed an RSS icon in the bottom bar on the site which links to the rss feed file.

<Grid item sm={12} md={4}>
  <IconButton component={ExternalLink} title={`${title} RSS`} to={'/rss.xml'}>
    <RssFeed color="secondary" />
  </IconButton>
</Grid>

So now you can use your favorite news aggregator/reader to catch up on agingdeveloper whenever I have new content.

Why Sign Git Commits

When you make a commit in Git the author information is sent along in the form of a name and email address. This information by itself is not verified in anyway. It is just a way to see who you are collaborating with. It is easy to impersonate someone by simply providing the same name and email address since that author information is not vetted in any way. The impersonation could happen in any repo regardless of your knowledge. In the worst case scenario someone could do this in one of the repositories that you regularly work in which would be extremely difficult to detect.

Git commit signing is a way to put a signature on a commit to show that the commit is actually coming from you.

How Commit Signing Works

Commit signing uses a public/private key pair to verify where the commit comes from. When making the commit you sign it with your private key. Others can then use your public key to verify the signature on the commit.

Getting it Setup

These instructions will be for macOS, but it should be pretty similar to set this up on other Operating Systems.

1. Git uses GPG for signing. I use GPGTools for this, but you can choose your own command line tool.

2. Generate a GPG Pair from the command line.

% gpg --full-generate-key

• RSA and RSA is the default key pair. You can just select that one.
• Select the key size (4096 is a minimum for github).
• Select how long the key should be valid for. The default is to never expire. *. Provide your Name, Email Address, and a Comment. The email address must be the same as your github account.
• Supply a passphrase. You could leave this blank, but I would supply it. You can always store it in the GPG Keychain so that you will not have to supply it on every commit.

1. List out your keys and select the key id of the one you just generated. It will be the string after the / on the sec line.

% gpg --list-secret-keys --keyid-format LONG

gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/Users/richard/.gnupg/pubring.kbx
---------------------------------
sec   rsa4096/0QB348777C85D1CC 2021-02-05 [SC]
      453372F6E3A6E764B2EC8EFB0BB938777C85D1CC
uid                 [ultimate] Rich Klein (Git Signing) <richwklein@gmail.com>
ssb   rsa4096/EC054AC0385BCD63 2021-02-05 [E]

1. Configure git with your signing key

% git config --global user.signingkey 0QB348777C85D1CC

Now you should be able to sign individual commits by supplying the -S to your git commit command. I prefer to have all my commits signed, so I configure git to always do this.

% git config --global commit.gpgsign true
% git config --global tag.gpgSign true

After making a commit you can verify it was signed using the log command.

% git log --show-signature -1

1. Export your public key

Signing your commits is only part of the process. Others can not verify the commit until they have your public key. So next you'll need to export it.

% gpg --armor --export 0QB348777C85D1CC

This will print out the ASCII version of your key. If you are using github then this is what you upload to your user profile so that they can verify your signatures.

1. Upload your public key.

• Go to the github keys page.
• Click on the New GPG key button.
• Paste your key from the previous step in the box.
• Click on the Add GPG key button.
• Fill in your password.

Your commits are now signed and you can see the verified badge on commits in github.

Official Documentation

I used the following documentation to set up my signing and create this article.

• Git Tools - Signing Your Work
• Github - Generating a new GPG key

The episode I was listening to was Sing Gently. It is an updated interview with composer Eric Whitacre. I was so moved by the episode that I wanted to write about it to urge others to listen to what it is about.

Eric Whitacre is a pioneer of "Virtual Choirs". He creates a composer track that people sing along with. People then submit recording of themselves back to him over social media. He compiles those recordings into these beautiful choir recording.

Prior to 2020 he had created five of these virtual choirs. Starting at about the 28 minute mark in the podcast they start discussing the Covid-19 pandemic, how singing is said to help spread the disease, and what that meant for choirs to get together.

This lead him to creating the sixth virtual choir, "Sing Gently". The idea behind the song originated from the current climate where the composer saw a great potential for people to be angry with each other and distance themselves from each other, not just physical distance. The idea in the song is to be gentle with each other, to be compassionate to each other, to show empathy, and to do that together.

The piece starts out: May we sing together always. May our voices be soft. 17,572 singers from 129 countries came together to perform "Sing Gently". A song with a message we should all take to heart this year. Please take a few minutes and listen.

Sing Gently

<iframe width="560" height="315" src="https://www.youtube.com/embed/InULYfJHKI0" frameborder="0" title="Sing Gently Virtual Choir Song" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen

</iframe>

If you enjoyed that, I've included the previous five virtual choir recordings so that you could listen to them.

Deep Field: The Impossible Magnitude of our Universe

<iframe width="560" height="315" src="https://www.youtube.com/embed/yDiD8F9ItX0" frameborder="0" title="Deep Field Virtual Choir Song" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen

</iframe>

Fly to Paradise

<iframe width="560" height="315" src="https://www.youtube.com/embed/Y8oDnUga0JU" frameborder="0" title="Fly to Paradise Virtual Choir Song" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen

</iframe>

Water Night

<iframe width="560" height="315" src="https://www.youtube.com/embed/V3rRaL-Czxw" frameborder="0" title="Water Night Virtual Choir Song" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen

</iframe>

Sleep

<iframe width="560" height="315" src="https://www.youtube.com/embed/6WhWDCw3Mng" frameborder="0" title="Sleep Virtual Choir Song" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen

</iframe>

Lux Aurumque

<iframe width="560" height="315" src="https://www.youtube.com/embed/D7o7BrlbaDs" frameborder="0" title="Lux Aurumque Virtual Choir Song" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen

</iframe>

I have a Samsung S8+ phone and a Samsung Gear Fit watch. About a year ago I started to look for a replacement for my Gear Fit because I wanted something a little bit newer with some more features. I was originally sticking with Android Watch OS and Samsung Tizen based devices for my initial search. However, Samsung's advertising practices pushed me over to Apple products.

I've own Samsung phones and tablets for close to 10 years. I've always felt that they were well built. The design and functionality of the products were great. It has only been in the last few years that the advertisements have become so pervasive throughout the user experience that it is now a problem.

Advertisements show up as push notifications whenever they want you to buy one of their new products.

All of the default apps now devote some real estate to advertising. A full third of the above the fold screen is devoted to ads in the Health app compared to no advertising in Google's Fit app.

There is no way to turn these ads off. There are options that looks like it might allow you to. They don't though. You can only opt out of ad customization.

I would expect free or low cost goods or services to be subsidized through advertising. That includes devices. These ads are on a phone that I paid over $1,200 for. This is not to offset the cost of the device in any way shape or form.

These ads have finally pushed me over the edge and forced my to re-evaluate who we buy all our devices from.

Why Apple?

Apple is not without flaws. I think some of their app store practices are down right monopolistic or at the very least anti-competitive. So why switch to Apple products instead of sticking with something Android based.

I was spurred on to make this decision largely because I wanted to replace my aging Samsung Gear Fit. Looking at the fitness trackers and watches on the market today, the only serious replacement is the Apple Watch.

Apple charges a premium price for their products and services; in exchange they take a harder stance on privacy. Evidenced by their recent changes to limit how other companies can access your data. This gives me some level of comfort that they will not be selling my data or placing intrusive ads anytime soon.

How does Amazon get a pass?

We have some Amazon devices (mainly tablets and Echos) that we will not be getting rid of any time soon. Amazon advertises on the devices that they make. Why take a stand against Samsung yet give Amazon a pass?

• The Amazon Fire 7 tablets starts out at $50 and regularly is on sale for less.
• It states clearly on the product page that the price point is with ads.
• The ads are just on the lock screen and not very intrusive.
• If you do not want the ads, you can pay an extra $15 to opt out of their "Special Offers".

Making a change

Others are taking notice of the way Samsung is treating it's customers and are not happy about it either. Their TV customers are being treated in much the same way.

They even boast about their advertising platform on a site used to attract advertisers.

Privacy has always been important; especially so in this digital age. It is becoming increasing clear that some companies have no qualms about invading that privacy just to get a few eyeballs on their ads and try to make some sales.

I'm taking a stand against this with my wallet by taking my business somewhere else. Losing a single families business will probably not break Samsung, but if more people do the same maybe they will take notice and it will drive some change.

I came to a career in software, specifically product R&D, in a round-about way. I did not go to school for software engineering or computer programming. I did not intern for a software company. I had some basic computer training in middle & high school. My intro engineering class used Fortran, and I took the odd RPG or Microsoft access class through continuing education. Development was not my original focus, but I had always had an interest in it.

Shortly after leaving college, I didn't really have any kind of career lined up. I had been working physical temp jobs and landed steady work at Tone's Spices in inventory control. After a few years there, I was able to use my skills somewhat by hacking MS Office with VBA.

Through continuing education and self learning I was able to move into an IT position. This is when I started to get interested and involved in the open source community, more specifically Mozilla. I was participating regularly in that community, including writing extensions. It was that extension writing that got me noticed by the Netscape division of AOL. I was hired there to develop Netscape Navigator 9. It was a big leap of faith that I would be able to do it. And that is when my career in software development really took off.

Once I had landed in R&D for a while, it became obvious to me that I was older than my colleagues. First at AOL then subsequently at Workiva. It was not by a lot, but by enough for me to notice. I am often the senior in the room by around ten years. My assumption is that my career start was a contributing factor in this.

The software industry skews much younger. The median age of Google and Amazon employees is 30. A 2018 Stack Overflow survey of 100,000 programmers around the world found that three-quarters of them were under 35.

Meanwhile, the median age of American workers is 42, and I just turned 44...

The age difference makes you wonder what happens to those older developers. From my experience there is a constant push towards management. Until recent history a lot of software companies did not have career paths for developers that did not want to move into management. This has been changing for larger software companies like Microsoft, Apple, Google, and others. Workiva is one of these companies that now has career tracks that stays technical.

I was one of those engineers that had ended up on a management path without really giving it a lot of thought. Some internal restructuring and a new manager gave me the space I needed to reevaluate what I wanted for my career. That led me back to a technical focused path. I did not mind managing people and I really liked the relationships, especially being able to be a mentor to the people that reported to me. I just always enjoyed the code more.

Being largely self taught, already older than a lot of my colleagues, and in a career that does not have many older people does produce a fair bit of anxiety.

• Is this something I can do until I retire?
• Can I stay technically proficient?
• Can I keep a relevant skill set?
• Does it make sense for the company to replace me with someone younger?
• ...

Some of the doubts that I have can be chaulked up to imposter syndrome. Impostor syndrome is doubt in your accomplishments or talents and a fear of being exposed as a "fraud". Despite all evidence to the contrary. But it could be legitimate fears.

I started this site as a way to keep updating my skills. The tech stack that I picked was one I'm not familiar with so that it allows me to broaden my knowledge. This helps ensure that my skill set does not get outdated.

I chose a public site to be visible. I wanted to do some work that others outside of large enterprises would see again. It allows me to engage with the general public and network with other.

It is open source so that if others feel like they could contribute to the discussion; they are free to do so with little hindrance. It can also be a platform where you, as a developer, can be seen and heard. Although, I don't have a large audience yet ;)

The Aging Developer can be a place for others going through the same sorts of worries and feeling to realize they aren't alone. That others share the same fears and hopefully the act of sharing can diminish those fears.

That is why "The Aging Developer".

Reference:

• Ctrl-Alt-Delete: The Planned Obsolescence of Old Coders
• Hacker News: What happens to older developers?
• No place for the old? Is software development a young person's game?
• Where do all the old programmers go?
• As A Software Developer, How Can I Ensure I Remain Employable After Age 50?
• Software Development Career Paths
• Job Titles & Levels: What Every Software Engineer Needs to Know

If you've previously been on the site you may have noticed that there was stubbed in navigation for an "Authors" page. This weekend I've finally been able to implemented support for multiple authors.

This article will explain how you can contribute content if you want and also how I went about building support for multiple authors.

Contributing Content

If you feel like you have some content that relates to the theme of the site you can create and submit a pull request for me to review and accept or reject.

If this is your first time contributing there are two things you'll need to supply. The article itself, including any images, and an author file.

The article goes in the /content/article directory. There is not a required layout for that directory, but I've been creating a subfolder with the slug of the article as the name. The folder contains both the article as well as any images in the article. This makes it easier to get the links between working correctly. The articles are written in mdx (Markdown + JSX) and should include a section of front matter at the top of the file. The code block below shows the front matter for this article.

---
title: Support for Guest Authors
author: richwklein
image: aaron-burden-y02jEX_B0O0-unsplash.jpg
tags:
  - gatsbyjs
  - material-ui
  - public
  - react
  - code
  - author
  - support
  - yaml
category: site
published: '2020-08-22'
---

The value of the author key in the front matter gets mapped to the id of an author node in Gatsby's graph during the build process. The author nodes are provided by creating an yaml file in the /content/author directory. That file contains information about the author including: email address, name, a short biography, avatar image, and social media links. Below is a sample of my file.

id: richwklein
name: Richard Klein
---
social:
  twitter: https://twitter.com/richwklein
  facebook: https://www.facebook.com/richwklein
  linkedIn: https://www.linkedin.com/in/richwklein/
  github: https://github.com/richwklein
  instagram: https://www.instagram.com/richwklein/

How it was implemented

Now on to how I implemented support for authors on the site. Gatsby has a few tutorials around how to implement this, but I found some of the tutorials on doing the linking between article and author nodes overly difficult to implement. Hopefully, this example can help others who might be trying to accomplish the same thing without the struggles I originally had.

In my gatsby-config.js file I have my file source set up to point at the /content directory. This allows just a single source plugin to supply both the article and author data. If you want to serve author information out of a different directory than the article information, you can set up a copy of the file source plugin with a path set to a different directory.

plugins: [
  {
    resolve: "gatsby-source-filesystem",
    options: {
    path: `${__dirname}/content`,
  },
]

There are a few file formats you could choose to supply the author information from. I've seen examples including json and markdown. I decided that I wanted to supply author data via YAML.

To accomplish this I first had to install and configure a transformer. A transformer is a type of Gatsby plugin that takes raw content from a source plugin and transforms it into something more useful. I used the gatsby-transformer-yaml plugin to transform the author file content into a node in the graph with the appropriate attributes from the YAML data.

npm install --save gatsby-transformer-yaml

plugins: [
  "gatsby-transformer-yaml",
  {
    resolve: "gatsby-source-filesystem",
    options: {
    path: `${__dirname}/content`,
  },
]

After creating my YAML file, /content/author/richwklein.yaml, and starting a local development server, the content was available by looking at the graphql ide in the browser.

Once I had the author information in the graph, I needed to provide a way to link that information with the articles that the author wrote. I did this by adding an "author" key to the front matter of the article files. The key contains the id of the author to link back to. I then added a "mapping" configuration to the gatsby-config.js file.

mapping: {
  "Mdx.frontmatter.author": "AuthorYaml",
},

The full information of the author could then be queried as part of the front matter of the individual articles.

It was pretty straight forward to create a byline section on the article pages as well as the various author related pages once the configuration was done.

The byline contains the author's avatar, a link to the author's page, along with the date the article was published and how long it should take you to read the article.

The Authors page contains a grid of all the authors that have contributed to the site with an avatar button to each author's individual page.

The author's individual page has their name, bio, social links, and articles they have written. the page is built from a template via gatsby-node.js. This is done by including the author in the graphql query that runs as part of the build. It outputs a page for each node in the author section of the graph.

exports.createPages = async ({ actions, graphql, reporter }) => {
  const { createPage } = actions

  const result = await graphql(`
    ...
    authors: allAuthorYaml(sort: { fields: name, order: DESC }) {
      edges {
        node {
          id
        }
      }
    }
`)

  createAuthorPages(createPage, result.data.authors.edges)
}

const createAuthorPages = (createPage, authors) => {
  const template = path.resolve('src/templates/author.js')
  const prefix = '/author'

  authors.map(({ node }, index) => {
    const currentPath = node.id

    return createPage({
      path: `${prefix}/${currentPath}`,
      component: template,
      context: {
        currentPath: currentPath,
      },
    })
  })
}

Once I figured out how to get the mappings working between the article front matter and the author's information, it was not difficult to implement the rest.

It is still probably the biggest change I've made to the site since launching it. So if you find any issues please submit a github issue.

Also, if you like what I'm doing and would like me to continue try getting a hold of me using one of the social links on my author page.

Remember if you would like to contribute feel free to open a pull request.

Java DNS Caching

When the JVM resolves hostnames to ip addresses it caches those lookups. Depending on the configuration this might not be refreshed until the JVM is restarted. This can especially be an issue if you are using AWS services where the IP Address may change for a service. I've seen this occurs with aurora failovers and other scenarios. You can prevent this by setting networkaddress.cache.ttl in the $JAVA_HOME/jre/lib/security/java.security file to some low number of seconds. Amazon recommends no more than 60 seconds.

networkaddress.cache.ttl = 5

Maximum Connections Per Route

Creating a tcp connection between services is a time consuming process and consumes lots of resources. This is especially true when TLS is involved. Because of this popular http clients try and reuse the same connection if they are going to the same route. The OkHttp library keeps only a single connection. The Apache HttpClient defaults to two. The Go http package also defaults to two.

This is fine when you are communicating over HTTP/2 because that protocol allows for multiple concurrent requests over a single connection.

Http/1.1 however, can only have a single request over the connection at a time. This can create a Head-of-line (HOL) blocking issue if you have to make multiple concurrent requests to the same dependency. The result of which may cause your service's requests to back up and cause a cascading failure. The most basic way to mitigated this is by increasing the maximum connections per route.

HttpClientBuilder builder = HttpClients.custom()
builder.setMaxConnPerRoute(20)
return builder.build()

Request Timeout

A lot of clients by default use the timeout set by the OS. This is true for clients in both Java and Go. This is another possible way to cause cascading failures. The best advice is to configure your client with something other than the default. The example below does this globally for the client, but you can also set these on a per request basis.

RequestConfig requestConfig = RequestConfig.custom()
        .setConnectTimeout(5000)
        .setSocketTimeout(5000)
        .build();
SocketConfig socketConfig = SocketConfig.custom()
        .setSoTimeout(5000)
        .build();
HttpClientBuilder builder = HttpClients.custom()
        .setMaxConnPerRoute(20)
        .setDefaultRequestConfig(requestConfig)
        .setDefaultSocketConfig(socketConfig);

return builder.build()

Other Best Practices

By following the practices above, you can help keep your service healthy. A few other best practices that I'm not going to go into, but can keep your service resilient include: using circuit breakers to prevent cascading failures, using retry designs for those temporary intermittent failures, and using thread pools or executor services for bulk heading and fault isolation.

In this example I'm going to assume you already have a domain registered. I went and registered agingdeveloper.net as part of this exercise just to remind myself how to do it. My False Starts Article explained how I had previously set up hosting and registered the domain agingdeveloper.com with BlueHost. That is the registrar I'm going to be using here. You may have to do something different with other registrars. The screenshots are from setting up a second domain, They will look different then when setting up your first domain.

In Netlify go to your site's Settings › Domain management. Select Add custom domain at the bottom of the Custom domains panel, enter your domain name, and select Verify.

Confirm you are the owner of the domain then select Yes, add domain. We are going to choose to delegate the domain Netlify. Make a copy of Netlify's nameservers. These are listed directly below the custom domain panel.

On your Bluehost's domain page, select the domain that you want to delegate. Then select the name servers tab. Choose the option to Use Custom Nameservers and input the previously copied list.

Select save nameserver settings. It may take just a minute for the setting to take effect, but that is all you have to do. Your site should now show up at the new domain name. Pretty easy, right!!!

The first thing I did was went out and found the agingdeveloper.com domain and registered it at bluehost along with a hosting plan. This was the service provider I had previously used. That became my first false start. I should have waited to figure out hosting until after I had the framework and deploy pipeline figured out.

I next set up a repo and went about trying to figure out which frameworks I wanted to use. I've used Pelican before, but that wasn't what I was looking for since it is written in Python and not really a new framework for me. I enlisted the help of StaticGen, a great resource that compares various static site generators. It helped me narrow my choices. My second false start came when I started out with Eleventy. I actually had a branch building with it. In the end the templating felt too similar to what I had used in the past.

I finally landed on Gatsby a Javascript framework that uses React for templating and is powered by GraphQL. I wanted to learn more about both React and GraphQL so it was a perfect fit for me to use.

I had my hosting and my framework now I just had to find my deploy pipeline. This is where that first false start comes into play. The only way I could deploy my site to bluehost was via FTP. I tried to get this working with Travis CI for a while, but I never really got it working and it just didn't feel right. I then went out looking for either a new CI/CD system or a new host. I landed with Netlify which is built for a "git based developer workflow" (exactly what I wanted) and includes CI/CD, DNS & Domain management, and hosting.

I first started putting things together by coding all my own React components from scratch. That was my last false start. I realized it was silly to be reinventing the wheel when there are lots of component libraries out there. Just because I was using a component library did not mean I wouldn't be learn React as I went along. I settled on using material-ui as my component library.

There are some other interesting bits that make this site tick and are worth mentioning. I'm using Let's Encrypt to get a free SSL cert. Almost of the images I'm using on here are from Unsplash which provides free to use photos for anyone.

In my previous post I mentioned that it was about a year ago that I started to want to re-engage in the online community. It didn't take a year to go from the idea germinating until it was something that was visible to share. I am a passionate developer, but I went for long stretches without putting any effort toward this as you can tell by the code frequency graph.

It took me a few false starts and some long stretches of down time, but I've landed on a workflow and a tech stack that I think will suite this "Aging Developer".

As the online landscape shifted and my career and personal life evolved, I found myself particpating online less and less frequently. My work became more enterprise focused and less available to the general public. I've got an active family life with a wonderful wife and 3 boys that keeps us busy. I just didn't have the time, desire, or energy to spend a lot of time engaging in the general public.

About a year ago I started to feel nostalgic for the level of engagement I had during those earlier years. I hadn't had any real active involvement with the general public in years. My work is not something that most people would see and I was rusty on the skill sets that had given me my initial career path. It had been years since I had done any real front-end development. I not only wanted to go back to participating more, but I also wanted to do work that was seen again by a larger audience.

At the same time I also started to realize that I have a unique perspective. A lot of software development careers shift to a management focus as you ascend the career track. I was a manager for a while, but I took a step back and decided that I wanted to stay focused on development and engineering. My real passion was building software and not managing people so I changed career paths and went back to development. This means I'm now a mid forty year old developer in an industry that is well known for skewing towards youth. This was an avenue I could explore and share my own personal experiences.

This site will not be soley dedicated to this "Aging Developer" perspective, but it will color everything that I do with it. The Aging Developer is a vehicle for me to re-engage and actively participate more. It also provides a way for me to go back and learn the latest trends in front-end development.

Fair warning: The site is an active development and a learning location. It will be broken and have missing features for large portions of the time.