I ended up using Garage to replace MinIO, which I was using in CI for my DD Photos project. I found out MinIO was gone when my scheduled CI failed this morning.
515 karma · joined August 30, 2013
So I built DD Photos, an open-source, self-hosted publishing tool. Example: https://ddphotos.donohoe.info/.
It worked great. The sites are fast, but it was developer-heavy (Go, Node, libvips), so I Dockerized it.
It was still tech-heavy (requiring typing in the Terminal and familiarity with unix commands), so I decided to build a friendly front-end that tries to remove the biggest barriers (e.g., editing YAML, CLI, etc.).
I built it in Java/Swing, leveraging the app engine I built 20+ years ago for DD Poker (https://www.ddpoker.com / https://github.com/dougdonohoe/ddpoker). Not surprisingly, it required a tiny bit of modernization :-)
But I got it done and I think (hope?) it is actually easy enough for non-techies to use it. It's also helpful to techies too (I mean who loves editing YAML?). I use it now (eat/dogfood).
I'm seeking feedback and anyone willing to give it a spin. Works on Mac/Linux/Windows.
Thanks!
Doug
"Huh, could you build my functionality using Hugo [link to repo]? I mean I'm using dynamic JS features"
And the above was the response. I didn't put more than 10 seconds thought into it. The commenter claimed I could build the site with less code with a tool I had never heard of and I was curious if I had missed something.
Short answer: technically yes, but it would be a worse fit and require real workarounds.
Here's why your project strains Hugo's model:
The core mismatch — client-side JSON fetching. Your architecture has photogen generate static JSON index files, and then the SvelteKit frontend fetches those at runtime in the browser. This is intentional — it means the HTML shell is pre-built and tiny, and photo data loads dynamically. Hugo assumes it will have all content at build time and bake it into HTML. Your approach of loading JSON client-side is fundamentally at odds with Hugo's philosophy.
PhotoSwipe lightbox + swipe gestures. This is a JavaScript-heavy component for the full-screen photo viewer with swipe, keyboard navigation, and captions. Hugo doesn't prevent you from using JS, but you'd be bolting it on rather than having it as a first-class part of your component model. Managing that in Svelte components vs. Hugo templates is a real quality-of-life difference.
Shareable photo permalinks (e.g. /albums/patagonia/5) that resolve client-side — this kind of dynamic routing within a static shell is SvelteKit's bread and butter. In Hugo you'd have to either pre-generate a page per photo (slow builds, lots of files) or do ugly JS hacks.
Dark/light theme toggle, justified grid layout, OpenGraph tags — these are all doable in Hugo, but you'd essentially be writing a SvelteKit app inside Hugo's templating language, which is less ergonomic.
The bottom line: Hugo shines when your content is known at build time and the interactivity needs are minimal. Your site has a static shell but runtime-dynamic data loading and a rich JS-driven UI. That's exactly the gap SvelteKit fills. Hugo looks applicable at a glance — but once you look at what the site actually does, SvelteKit is the right call.
I think gamification triggers some innate feature of our brain, just like TikTok or Reels or mobile games, etc. It is designed to be hard to ignore.
I took Spanish in high school and college, so had a rudimentary understanding of verb tenses and some vocabulary. Before I walked the Camino de Santiago el Norte (45+ days in Spain), I used Duolingo to brush up on my Spanish.
It helped my reading most, my speaking a fair amount and my listening/conversation the least. I was able to ask questions, but was often flummoxed at any reply that wasn't the most basic.
I grew to hate the gamification, but was addicted to my "streak' also ... using math lessons when I didn't feel like doing a Spanish lesson. The so-called "leagues" were kind of useless since the same people weren't in the league from week to week. Any friendly competitiveness to "learn more" was lost when randomly assigned to a different group each week.
I finally abandoned the app this spring.
I'm trying Babbel now since I'm going back to Spain for a month and Patagonia next year.
I wouldn't want to be in charge of regression testing an LLM-based enterprise software app when bumping the underlying model.
Fun story!
https://medium.com/@DougDonohoe/ce45d56c8773
Writing well is hard and takes time. Was it Mark Twain that said "If I had more time, I would have written a shorter letter."? I can totally relate to that this month. Getting your point across without being long winded is challenging.
My goal was to get whatever I was working on not just "done", but "done-done". To a state where, if I walked away, it could live on in a working manner and be easily maintained by someone else. That meant having good test coverage, up-to-date documentation, instructions on how to get started with the repo, notes on dependencies, etc. Sometimes that someone else is future me, six months or six years later.
I experienced burnout early in my career, in the dot-com era, and it became especially acute when then the bubble burst. All those long hours (mostly) for naught.
The best times were at companies where everyone was all-in and we each had each-others back. Rare, but amazing when it happens. These were all at startups.