Jeff Triplett

Moving My Websites from Jekyll and Hugo to Django

2026-10-12T22:00:00+00:00

I have two websites: my main site, jefftriplett.com, and my micro.blog, micro.webology.dev. Back in July, I moved jefftriplett.com from Jekyll to Django. A few weeks ago, I moved my micro.blog posts, which ran on Hugo, into the same Django site and added a banner to give everyone a heads-up. I backed up both sites first, and for now, everything lives in one stream on jefftriplett.com.

Jekyll served me well for close to a decade. I used it on dozens of websites, and it was great. Over time, though, I stopped making quick commits and small updates. No matter how I updated, it was too hard to open my website, type something, and hit publish.

Micro.blog is what finally got me comfortable hitting publish, so it will always have a place in my heart. But it was the same story. Too often, I worked around the platform instead of it working for me.

With agents, it is now much easier to customize software until it works exactly how I want. So I built my own, and since I am a Django developer, Django was the obvious choice.

Getting my posts and feeds across

A couple of people have asked how the move worked. My Jekyll site was Markdown files with front matter in GitHub, so importing everything was easy.

The hard part was making sure nothing broke. I ran a few rounds with an agent to compare my old sitemap.xml and feeds against the new Django site. I wanted the feeds to line up exactly so I would not dump a pile of duplicate posts into people’s feed readers. Apologies if I accidently did that.

Once everything was in the right place, the rest went quickly.

Micro.blog was easy to export, too. It gives you a JSON file of all your posts, which I appreciated. I used the same sitemap and feed checks for that move, so the new URLs match the old ones as closely as possible for both search engines and people following links.

Everything from my micro.blog is now mirrored on jefftriplett.com. micro.webology.dev will stay up as a static archive for now, though I might rethink that later. I have not set up redirects yet, but I plan to point the old links to the right places.

Visually, not much has changed. I ported the same layouts and design over as-is. I want to start on a refresh, but my first goal was to move everything over, then make small changes over time.

Software that works the way I do

The new site uses collections, an idea I borrowed from Jekyll, so I can add any content type I want.

Images were always a pain on both micro.blog and my old blog. Now I can drag and drop them in. I am also experimenting with something like Wagtail’s StreamFields so I can mix images and other blocks into a post.

A dynamic site also opens the door to features that are hard to pull off on a static one, like Webmentions and really good Open Graph images. I wrote a service that generates Open Graph images, and I already use it on several of my other sites. Now I can test it here and control exactly how each article looks when someone shares it. That is not fully set up yet, but I am excited that I no longer have to work within Jekyll or Hugo's limits every time I want to add a feature.

Writing from anywhere with MCP

I now have two ways to create and edit posts: the Django admin or MCP. The site is plain Django, and I added MCP with django-mcpz. My content items, blog models, categories, and collections are all exposed through a custom MCP server so that I can read and edit any of them.

That means I can write from whatever tool I happen to be in: Claude Code, Codex, the ChatGPT app, or the Claude app. A few of those work on my phone, and I can even use them through CarPlay. With voice mode, I can dictate a post while driving, save it as a draft, and clean it up later. I can also write something in Obsidian and tell Claude to publish it.

I have not used it much yet, but MCP already changes where and how I write. It feels less restrictive, which makes writing more fun.

Maximum control

Now that agents make it so quick to create and change things, I want the system that gives me maximum control. A static site generator used to feel like the safe choice for performance, but that tradeoff no longer worries me. With a CDN like Cloudflare or Fastly in front of Django, I can cache nearly everything, which makes performance a non-issue.

That is the whole point of this move: less friction between having an idea and publishing it. I no longer have to stop and figure out how I am going to blog or get a post onto my website. I can write, and I am looking forward to getting back into blogging.

Talking Cloud: Managing Agents, Not Writing Code

2026-09-30T05:00:00+00:00

Episode 62 of Talking Cloud with Brett Gillett and Travers Annan on what a workday looks like when almost all of the code comes from agents. Topics include running client app upgrades and bug-fix cycles with agents, how consulting changes when clients pay for outcomes, why domain expertise still decides who catches the agent's mistakes, software factories versus one-shots, llms.txt files for fast-moving libraries like Pydantic AI, working from anywhere with Tailscale, Herder, and Moshi, personal software, and why local models stalled as hardware prices climbed.

How I Work From Anywhere Without Losing My Place

2026-06-13T16:04:52+00:00

I’ve been running a new remote development setup for the last month or so, and the goal is simple: move between all of my devices without losing my place.

The way I think about it, I have three default states:

At my desk on my Mac Studio
Home or out somewhere with my laptop or an iPad and a portable keyboard
Only my phone, at practice or running errands

I wanted a setup that works across all three without rebuilding anything when I switch. I’d rather grab my iPhone or iPad with a portable keyboard than lug a laptop everywhere. If I’m at one of my kids’ practices and want to quickly follow up on something or implement an idea, I always have my phone with me.

The stack is basically:

Tailscale - glues all of my devices onto one secure network
tmux - keeps my dev environment alive so I can leave and come back without rebuilding
Mosh - keeps remote connections resilient across flaky WiFi and network changes
cmux - Ghostty + Workspaces for macOS, the desktop side of this
Moshi - the best iPhone and iPad shell I have found

The first three are the foundation. They work the same no matter which device I’m sitting at. cmux is how I connect from a desktop or laptop, and Moshi is how I connect from my phone or iPad.

Tailscale ties the machines together

Start with Tailscale. I’ve used Tailscale for almost a decade because it’s free, has clients for everything like my phone, iPads, Macs, Linux boxes, and even routers and TVs. It’s a low-friction way to access all of your devices from anywhere securely and privately.

Tailscale gives me a private network across my devices, so I can connect to my Mac Studio at the office, my Mac Mini at home, my MacBook Air, and Linux boxes without opening SSH to the public internet.

That’s a big part of why I’m comfortable with this setup.

These machines are not sitting there with public SSH ports open. They’re only reachable from my tailnet. Tailscale handles the secure network piece, and I don’t have to mess with WireGuard directly.

It just works.

tmux keeps the work alive

tmux is the core of the setup. I’ve been running it for the last couple of months because I wanted something I could reconnect to later, similar to screen, but better suited to the way I actually work.

A lot of the time, I have something running for work, a client, or one of my own projects. I might have Django in one pane, logs in another, and Claude Code or Codex running somewhere else. With tmux, I can leave that entire development environment in place and come back to it later. Being able to do that has been worth the switch on its own.

I’m probably not using 90% of what tmux was built for. Mostly I’m using it to create sessions, connect to them, and disconnect without losing my place. I can split panes and move between them when I need to, but I find myself doing that less and less. The persistence is the part that actually matters to me.

Some alternatives to tmux are Zellij and Herdr. I attempted to use Zellij, but struggled with the basics, so I bailed and went back to tmux. I haven’t tried Herdr, but I’ve seen people talking about it and wanted to include it.

Mosh makes remote sessions feel less fragile

The bigger improvement came when I added Mosh.

Before I left for PyCon US, I decided I didn’t want to spend the week fighting flaky hotel, airport, and conference WiFi.

I remembered that Mosh solves a lot of the disconnect problems SSH has, so I installed it on my server, my work Mac Studio, my home Mac Mini, and my MacBook Air before I left (Homebrew on macOS, your package manager of choice on Linux).

I connected to a session before getting on the plane. About an hour into the flight, I opened my laptop, and the session resumed automatically. I didn’t have to rebuild anything or start over. It worked better than I thought it would.

Mosh and tmux make a great pair. Mosh keeps the connection resilient, and tmux keeps the actual working state alive.

On a desktop or laptop, cmux ties it together

When I’m at a real keyboard, cmux is how I connect. It gives me Ghostty terminals and workspaces on macOS, which makes it easy to keep several machines and sessions organized at once.

Where cmux really earns its place is how it handles agents and shared sessions. One workflow I’ve come to rely on: I’ll start a tmux session on a remote machine, then connect to it in a second terminal window in cmux. Then I’ll have Claude or Codex connect to that same machine and attach to the same tmux session to do the actual work, like setting up a new Linux box or installing packages.

The nice part is that when Claude hits an interactive prompt, I can just take over the tmux session directly. I’m already attached. I can paste in API keys, answer prompts, or make changes that I wouldn’t want to hand off to an agent. Claude normally tries to handle those moments itself, and it doesn’t always do it well. This way I stay in control of the sensitive parts without losing the automation for everything else.

On my phone or iPad, Moshi is the missing piece

When I only have my phone or iPad with me, the part I was missing was a good way to connect to my remote sessions.

I had tried Termius before, and it was decent, but I kept running into small UI issues. CLI apps are not really designed for phones and tablets, so little things like getting to the right key at the right time can become annoying fast.

Then I tried Moshi.

Moshi is an iOS and iPad app for remote terminal connections. It also runs on Apple Silicon Macs as an iPad app, which is a nice bonus.

Moshi has really good tmux support, and probably other multiplexers I haven’t tried yet. When I connect to a server that has tmux sessions running, Moshi prompts me with a list of those sessions before I even get to a shell. I don’t have to remember the command or go hunting around. I just pick the session and I’m back where I left off. That’s the feature that made the whole setup click.

Moshi also has a good mobile UI for this kind of work. I created a couple of shortcuts, one for space and one for enter, and that gets me through most of what I need when I’m using Claude Code or Codex from my phone.

Codex still has a few spots where it wants escape, and I haven’t fully figured that out yet. That may have been a connection issue, or it may be something I need to configure better.

But for most of what I’m doing, it works shockingly well. I can open my phone, connect to an existing tmux session, check logs, nudge an agent, review what changed, or keep something moving without opening my laptop.

Setup was easier than expected

Moshi also handles setup nicely.

When you connect to a server, it can show a QR code. You scan that from your phone, and it handles creating and copying the SSH key for you.

That makes setup about as easy as I think it can be.

On Apple devices, Moshi can also share connection settings across devices on the same Apple account. Once I had it set up, connecting from my iPad was painless. I hit the button, picked my session, and I was in.

There is an Android version too. I haven’t tested it because I don’t have an Android device, but it’s there if you need it.

Moshi is a paid app, unlike the rest of this stack, which is free or open source. It runs around $30 a year or around $80 for lifetime access, which felt reasonable given how much I’m using it.

Voice input

Moshi also supports voice input, which ended up being a bigger deal than I expected.

On my Mac, I already use voice input a lot. I use tools like MacWhisper because voice to text has become a really good input method for me.

Moshi brings that same idea to my phone and iPad.

It can use Apple’s voice to text, and it can also run a Whisper model. That means I can connect to a remote session from my phone and use voice input to interact with the tools I already have running.

Claude Code has voice support on the Mac, but that doesn’t really help when I’m remotely connected into another machine. Moshi having voice support built in makes the whole thing much more useful.

Where I’m using it

So far, I’ve been using this setup on Django TV, my job board, client work, and a bunch of one-off projects.

I have a Mac Studio at the office and a Mac Mini at home, and I’m constantly moving between them from my MacBook Air. I’ve also been playing with direnv so I can jump into a project and have the right environment load on the right machine. It’s not really part of this stack, but it pairs well with it.

The split helps me keep things organized. Client work lives on the Mac Studio at the office. Side projects and personal work live on the Mac Mini at home. I can connect to whichever one I need without mixing everything together on my laptop. It also helps my MacBook Air battery, because the heavier work is happening somewhere else.

And because the sessions are always running, I don’t have to worry about rebooting my MacBook Air or losing a Claude Code or Codex session mid-task. If one machine is having a problem, I can exit and switch to the other one while everything I care about stays up and running.

Review has also gotten easier. I can pull up GitHub’s web interface or the GitHub desktop app from wherever I am and review pull requests without needing my full dev environment in front of me. The work is already staged. I just need a browser.

I can still work locally when I want to. There’s nothing wrong with that. But keeping these remote sessions open all the time has been a much better experience.

The databases are already connected. The processes are already running. The agents are already in context. I can leave things in progress and come back later without rebuilding the whole setup.

The glue code

I’ve also been writing some shell aliases and scripts to smooth over the rough edges, because I don’t want to memorize tmux’s command flags.

I have a set of tmux-* aliases that handle the things I actually do: create a new session, resume an existing one, and kill one when I’m done. That covers most of what I need without having to look anything up.

On the cmux side, I’ve been experimenting with its CLI and API. I wrote cmux-dump and cmux-restore commands to save and reload workspace layouts. The idea is to build out profiles for each project so I can get everything running the way I want it with one command. That might mean starting a tmux session on a remote machine and connecting to it over Mosh, all from a single alias.

All of this lives in my dotfiles repo and will keep changing as I figure out what actually works. I’m still early in this part of the setup.

When and why you need each tool

You don’t have to adopt all five of these at once. Each one solves a specific problem, and you can add them as you hit that problem.

Tailscale is the one to start with if your machines aren’t already on a shared network. You need it the moment you want to reach a machine that isn’t sitting in front of you without exposing SSH to the public internet. If all of your work happens on one machine, you can skip it for now.
tmux is what you need when losing your terminal state hurts. If closing a laptop lid or dropping a connection means rebuilding your dev environment, restarting servers, or losing an agent session mid-task, tmux fixes that. It’s also the piece that lets two terminals, or you and an agent, share the same session.
Mosh matters when your network is unreliable. Hotel WiFi, airports, conferences, tethering, or just moving between home and office. If you only ever connect over a stable wired network, plain SSH is fine. The moment you roam, Mosh is the difference between a session that survives and one you have to reconnect constantly.
cmux is for the desktop side, when you’re juggling several machines and sessions and want them organized into workspaces instead of a pile of terminal windows. Any terminal works here, but cmux makes the multi-machine setup easier to live in.
Moshi is for the phone and iPad side. You need it when you want to check on or nudge work from wherever you are. Its tmux session picker, key shortcuts, and voice input are what make a phone a usable terminal instead of a frustrating one.

The short version: Tailscale gets you to the machine, tmux keeps the work alive on it, Mosh keeps the connection from breaking, and cmux and Moshi are the front doors from a desk and from a phone.

This is not about working all the time

The real reason I like this setup is not because I want to maximize every spare minute of my life.

It’s almost the opposite.

This setup gives me more flexibility.

If I have 15 minutes at my son’s track meets or baseball practice, I can pull out my phone and reconnect to something already in progress. If I’m waiting on slow tests, client feedback, or a deploy, I don’t have to sit glued to my desk.

I can make dinner. I can pack lunch. I can pick up one of my kids. I can run an errand.

Then, when something is ready, I can check in, make the next change, and keep moving.

It makes the work less jarring. I don’t have to reset everything on my laptop just to make one small change or direct an agent for two minutes.

The best part is that I can just close my laptop or walk away from my desk and know that my Claude and Codex sessions are going to keep running. When I come back, whether it’s on my phone or back at my desk, I can resume right where I left off without worrying about a disconnected session or a timed-out agent.

Why this feels different

The built-in remote options from tools like Claude Code and Codex work sometimes, but I kept running into connection weirdness when one laptop was trying to coordinate across multiple machines.

What I wanted was something that didn’t require rebuilding context every time I moved. This stack gives me that. The connection doesn’t break. The session doesn’t disappear. The agents don’t lose their place.

That’s a different kind of flexibility than I had before. It’s not about squeezing more work into more hours. It’s about not paying a tax every time I pick up where I left off.

This is what’s working well for me right now, but I’m genuinely curious what you’re using. If you have a tool that replaces one of these or collapses a few layers into one, I want to hear about it. If you try any of this and it works for you, let me know. And if I’m holding one of these tools wrong and there’s a better way, I’m all ears for that too.

Written by Jeff via a mix of voice transcription and typed notes. Edited with Claude Code.

Originally posted on: https://micro.webology.dev/2026/06/13/how-i-work-from-anywhere/

Django Chat Podcast: E201

2026-04-30T18:10:04+00:00

This week, I joined Will Vincent and Carlton Gibson on the Django Chat podcast for DjangoCon Europe Recap + Other News. You can also watch it on DjangoTV via YouTube.

On this episode, we discussed DjangoCon Europe, which Carlton had attended. We caught up on what’s going on with Django News and the Django Software Foundation. We also spent a good chunk of time on AI workflows and tooling. And I got to have a little soapbox rant at the end, which is always fun for me.

Projects I Recommended

Pydantic AI is the Django ORM for accessing LLM providers
CodexBar - If you are on a Mac, CodexBar will let you easily track and see your token usage across 20+ providers
Ghostty - After almost two decades of using iTerm2, I switched.
cmux - Built on Ghostty but a nice UX to switch between Agent sessions
MacWhisper - Still my favorite voice to text Mac app

Books I Recommended

At the end of the episode, I recommended these two books:

The Greatest Bedtime Story Ever by Jessie Sima
Enshittification: Why Everything Suddenly Got Worse and What to Do About It by Cory Doctorow (I recommended this one, but maybe not for the reasons you might think)

Conclusion

I’m always excited and honored to be invited on the show, and I always enjoy it. I hope it was a good listen, and I especially appreciated getting to step on the soapbox one more time at the end.

Originally posted on: https://micro.webology.dev/2026/04/30/djangochat-podcast-e/

DjangoCon US Talks I'd Like to See 2026 Edition

2026-03-19T20:54:26+00:00

This is my annual list of DjangoCon US talks I’d like to see. I have been doing this since 2015, and it’s one of my favorite traditions.

DjangoCon US 2026 is in Chicago this year, August 24-28.

The CFP is open. The deadline is March 23, 2026 at 11 AM CDT. Submit a talk!

Past editions

Drew’s Topics

Drew Winstel published a great list of talk ideas for DCUS ‘26 with over 20 ideas. Here are some of my favorites from his list. Any of these would make good talk ideas, so check out Drew’s full list too.

GPTs, LLMs, and AIs, oh my!
Deployment at any size
Unexpected use cases, especially ones that make the world better
Clever hacks (such as Carlton Gibson’s single-file Django project)
Using Django in machine learning projects
New features in Django 6.x
Development and testing techniques that help you build better code
Convincing product management that you don’t need a SPA or yet another mobile app
Personal growth: how the community helped you in some way and you’d like to pay it forward
Adapting communities to changes in life

My Topics

Here are some topics that I’d personally like to see this year.

What’s coming in Python and Django

With some big shifts coming in Python 3.15 and 3.16, it would be really interesting to see more about what Django developers would benefit from knowing about what’s coming up. Something a little more core to Python would be interesting.

I’d also love to see more Django talks, whether it’s from the Steering Council or anybody working on features for the Django 7 series. What’s coming? What are the big features being tackled?

Django’s deployment story

Last year I was on a panel called Two Decades of Django: The Past, Present, and Future. During that panel, I challenged people to really look into Django’s deployment story and find ways to improve it. If we can remove one or two steps along the way, we can make the deployment story better.

A couple of projects came out of that conversation that I really liked, including Django Prod Server. Anything that makes deployments better and reduces the number of steps is worth exploring. If anybody has topics around improving Django’s deployment experience, that would be a great one to discuss.

Rust in our ecosystem

I’d like to hear more about Rust in our ecosystem. Tools like uv, Ruff, and Pydantic are all built with Rust. Pydantic led to Django Ninja and other applications built around it. Are you using Rust in your Django applications? Why? Where are you building with it? How is it improving your workflow? Is it for linters? Code formatters? Are you solving performance bottlenecks with Rust? What should Django learn from Rust? Which parts of Django would be better if rewritten in Rust? That story is really fascinating to me.

LLMs and Django

I’d like to see more LLM talks about the amazing things people are building. This could be with Pydantic AI, creating model agents, or things you’re building that either run Django websites or help people do amazing things with agents. What does it look like to give a functional brain to a Django app? That would be an interesting talk idea.

Agent skills and productivity

I’d also like to hear about agent skills. How are you improving your productivity? How are you taking some of the drudge work out of working with Django? What skills do you use? What problems are you solving that a skill helps you with? What should Django learn from LLMs, skills, and agents? That would be another interesting topic.

Real talk about LLMs and team productivity

There are a lot of talks about the negative things about LLMs and AI, and I think that is respectable and understandable. But it has become taboo for some weird reason that people who use LLMs every day aren’t speaking out about it and aren’t talking about the productivity gains they get. Especially if you’re on a small team doing a lot of stuff.

If you’re working with a bigger team and everybody’s using these tools, how are you managing it? How are you getting through pull review processes? How are you making your code better? What’s working? What didn’t work? What’s scaled up for you?

Everything is changing in our industry whether we like it or not. Agents are here. The companies as of today are not going anywhere and the bubble hasn’t burst. I’m really curious about team productivity. What do you like? What don’t you like?

Defending and embracing LLM traffic

On the flip side with LLMs, so many things have changed in the last year that we have to be a little more defensive with our websites, whether that’s using CDNs like Cloudflare or Fastly. I’m really interested in what people are doing to scale their servers now with LLMs in mind.

Some people may or may not want to make their websites more LLM friendly. There are definitely advantages and disadvantages to doing that. Writing a website to be consumed by LLMs is an interesting topic, both defensively and in terms of how you take advantage of it.

Submit a talk

You can always go back to my 2024 list and of course there’s Drew’s list too. Some of the best topics that will be submitted will be things that don’t fit either of our lists. The whole idea is just to give people a starting point for things we’d both personally like to see, but that shouldn’t limit your imagination.

Outside opinions are great. Not everything needs to be about Django. We always get a bunch of community talks and talks that don’t have to be about the tech. But I think it’s an exciting year to really dig deeper into some of the tech because so much is changing on a weekly basis.

Submit your talk for DjangoCon US 2026!

Originally posted on: https://micro.webology.dev/2026/03/19/djangocon-us-talks-id-like/

How I Use django-simple-nav for Dashboards, Command Palettes, and More

2026-02-27T02:56:51+00:00

I first got exposed to django-simple-nav while working with Josh Thomas at the Westervelt Corporation over the last two or three years. It quickly became a go-to library in my toolkit. django-simple-nav lets you define nav items and groupings in Python, then hand them off to a Django template to render. I use it for sidebars, headers, dashboards, and other spots where I need a menu.

Since then, I have also started using it on a lot of personal projects. It has been a great fit every time.

Defining nav items once and reusing them everywhere

Recently I wanted to reuse parts of a menu nav without having to update a bunch of different files. I had a dashboard with a sidebar full of links, and I also wanted a command palette that could search across all those same options when you hit Command-K from any page. django-simple-nav was a natural fit because you define your items once in Python and render them with whatever template you want.

Here is an example of what that looks like in Python:

from django_simple_nav.nav import Nav
from django_simple_nav.nav import NavGroup
from django_simple_nav.nav import NavItem

NAV_ITEMS = [
    NavItem(title="Home", url="home"),
    NavItem(title="Dashboard", url="dashboard"),
    NavGroup(
        title="Admin & Tools",
        items=[
            NavItem(title="Admin", url="admin:index", permissions=["is_staff"]),
        ],
    ),
    NavItem(title="Login", url="login"),
    NavItem(title="Logout", url="logout"),
]


class DashboardNav(Nav):
    template_name = "nav/dashboard.html"
    items = NAV_ITEMS


class CommandPaletteNav(Nav):
    template_name = "nav/command_palette.html"
    items = NAV_ITEMS

Flexible URLs and named routes

A few things to notice here. When you create a nav item and you have a URL, you can either use the URL’s name or you can give it the path to it and it will figure out what it is. So if I want a nav item for the Django admin, I can use "admin:index" as the URL.

Handling permissions without template logic

Another nice feature is the permissions parameter. The Admin link uses permissions=["is_staff"], which means it only shows up for staff users. You can use this to hide things based on whether someone is staff, a superuser, or has specific Django permissions. This makes it nice to keep all of your nav options in one place without having to write special conditional logic in your templates to show or hide items for different users.

Rendering a dashboard nav with Django templates

The other thing to notice is the two Nav classes at the bottom: DashboardNav and CommandPaletteNav. They both use the same NAV_ITEMS list but point to different templates. This is where the reuse really shines.

Here is an example nav template at templates/nav/dashboard.html:

<nav>
  {% for item in items %}
    {% if item.items %}
      <span>{{ item.title }}:
        {% for subitem in item.items %}
          <a href="{{ subitem.url }}"{% if subitem.active %} class="active"{% endif %}>
            {{ subitem.title }}
          a>
        {% endfor %}
      span>
    {% else %}
      <a href="{{ item.url }}"{% if item.active %} class="active"{% endif %}>
        {{ item.title }}
      a>
    {% endif %}
  {% endfor %}
nav>

Then in your base template, you can render it with the template tag:

{% load django_simple_nav %}

{% django_simple_nav "myapp.nav.DashboardNav" %}

Building a command palette from the same nav items

Because the CommandPaletteNav class uses the same NAV_ITEMS list but with a different template, we can render the same nav data as JSON for a command palette. Here is an example template at templates/nav/command_palette.html:

{% load django_simple_nav %}

<script type="application/json" id="command-palette-data">
[{% for item in items %}{% if item.items %}{% for subitem in item.items %}
  {"title": "{{ subitem.title }}", "url": "{{ subitem.url }}", "group": "{{ item.title }}"}{% if not forloop.last or not forloop.parentloop.last %},{% endif %}{% endfor %}{% else %}
  {"title": "{{ item.title }}", "url": "{{ item.url }}"}{% if not forloop.last %},{% endif %}{% endif %}{% endfor %}
]
script>

This also lent itself well when I was trying to do something quickly with Claude. I don’t know how to build a command palette, but I was able to just have Claude create one. I asked it to use HTMX to keep everything pretty lightweight.

Final thoughts

All in all, django-simple-nav is a nice library to have in your toolkit. I like using it for headers, menus, dashboard navigation links, and even footer text. If you need flexible, reusable navigation in Django, give it a look.

Written by Jeff. Edited with Grammarly and Claude Code.

Originally posted on: https://micro.webology.dev/2026/02/26/how-i-use-djangosimplenav-for/

Jordan Baird's Ice beta fixed my macOS Tahoe menu bar issues

2026-02-19T14:00:00+00:00

If you use a Mac, you’ve probably noticed that the menu bar fills up with icons pretty quickly. Bartender and Ice (sadly, now an unfortunate name) are apps that let you manage and hide unwanted icons from your macOS menu bar so it stays clean and uncluttered.

About a year ago, I switched from Bartender to Ice, which just happens to be open source, because there was some drama. Since then, I’ve been very happy with Ice.

A couple of months ago, I upgraded to macOS Tahoe, and my menu bar stopped working correctly. The icon colors were all this weird shade of blue, so I couldn’t customize anything. After months of trying to figure it out, I noticed that it had been a while since Ice released a new version. That’s how open source goes sometimes.

I was getting to the point of deciding whether to go back to Bartender or stick with Ice. Today, I noticed that there’s a Homebrew package for jordanbaird-ice@beta. I decided to give it a try, removed the old version, installed the beta, and to my surprise and delight, the problem was fixed.

# remove the stable version
brew remove jordanbaird-ice

# install the beta
brew install jordanbaird-ice@beta

I’m hoping there’s a more official release soon. The new Bartender looks good too, so if Ice doesn’t keep getting updated, I might switch back. If you’ve run into this same issue, give the beta a try and let me know how it goes. And if you know of any alternatives to Bartender and Ice, I’d love to hear about those too.

Originally posted on: https://micro.webology.dev/2026/02/19/jordan-bairds-ice-beta-fixed/

My displays keep rearranging and displayplacer fixed it

2026-02-18T22:54:47+00:00

Today I learned about displayplacer - “macOS command line utility to configure multi-display resolutions and arrangements.”

In December, I upgraded to MacOS Tahoe and picked up the TS4 dock for my work machine.

While my upgrade was painless, the biggest issue I’ve had is with my displays. Every time my displays go to sleep and then I come back from lunch or come back the next day to work, my orientation of my displays changes and it puts them in a random order.

My displays should be arranged like this:

[1] [2]
[3] [4]

But after waking from sleep, they end up like this:

[2] [1]
[3] [4]

It’s really annoying. It takes a minute to fix and it’s just frustrating.

I tried displayplacer today. I had Claude Code actually run the displayplacer list command. It figured out which displays and which settings needed to be changed. I had it record that and then I tried it out a few times where I manually dragged my displays around, put them in the wrong order, then ran the command, and it just magically worked.

I saved the working configuration to a shell script:

#!/usr/bin/env bash
# Restore display layout: 4 monitors (2x 16" 1920x1080, 2x 73" 2048x1280)

displayplacer \
  "id:F4AB0D6C-8E85-4E84-B5AB-C5B388536E3D res:1920x1080 hz:60 color_depth:8 enabled:true scaling:off origin:(0,0) degree:0" \
  "id:C9240C8E-A9D2-418A-89AC-28D3B5DEE5FC res:1920x1080 hz:60 color_depth:8 enabled:true scaling:off origin:(-1920,0) degree:0" \
  "id:B43E3352-ACB7-4163-A25B-2DDAE0174571 res:2048x1280 hz:60 color_depth:8 enabled:true scaling:off origin:(0,-1280) degree:0" \
  "id:B32F530C-62CF-4F0D-9997-80BF2B812AC8 res:2048x1280 hz:60 color_depth:8 enabled:true scaling:off origin:(-2048,-1280) degree:0"

I also tried setting it up as a Stream Deck key and for some reason I couldn’t get that to work. But it’s fine. I can run a shell script and that takes a lot less time to get it in the right order.

Originally posted on: https://micro.webology.dev/2026/02/18/my-displays-keep-rearranging-and/

Talk Python: Web Frameworks in Prod by Their Creators

2026-01-05T00:00:00+00:00

Framework creators from FastAPI, Flask, Django, Quart, and Litestar discuss practical production deployment strategies. Topics include WSGI vs. ASGI servers, database optimization, async/await patterns, containerization, CDN strategies, background task processing, and framework selection criteria.

Django Chat: Django Survey 2025 - Jeff Triplett

2025-12-18T00:00:00+00:00

Django Board Member Jeff Triplett joins the podcast to discuss the results from the Django Survey, highlighting key trends, packages, and actionable ideas.