There were also a couple larger improvements that just went live that are worth explaining.

As always, if you run into any issues, don’t hesitate to reach out to erv@ewal.net

New Authentication Provider

The previous authentication system was from Supabase. It mostly worked. Except for two problems:

• People kept getting kicked out and forced to log in again. This was driving me personally crazy.

• A small number of people couldn’t log in at all for some unknown reason

It turns out that maybe Supabase’s authenticaiton system is just not quite mature yet. So I replaced it. TrendWeight now uses Clerk which has a better reputation and a more traditional approach. This should be mostly transparent to those that used the system in the first week (although you will have to log in one more time per device). The new system will let you stay logged in as long as you visit the site once every 90 days or so.

Legacy Data

It turns out that a few users had a lot of historical data in the old site that doesn’t actually live in Withings/Fitbit anymore for whatever reason. So while the new site did re-download all their weight data from Withings/Fitbit, they were seeing less than they were used to. The good news is that the old site’s database still exists.

There is now a feature for those that had accounts at the old site that will pull over whatever data existed there and that data will be merged with what Withings and/or Fitbit have going forward. If for whatever reason, you decide you don’t want that old data in your charts, you can disable the legacy data in your settings.

Start Date Improvements

The final addition is an improvement to Start Dates. The new onboarding UI didn’t prompt people to pick a start date and most people probably never bothered to visit the Settings and so weren’t aware of it. So now, new accounts get asked up front if they want to pick a start date (users of the old site had their previous Start Date copied over automatically).

Additionally, the new site behaves a bit differently than the old site in a way that wasn’t what everyone wanted. The old site only showed you data from your Start Date onward. However the new site gets everything that Withings and/or Fitbit have for you. That’s often useful, but in some circumstances it you may want to focus only on weight data from your Start Date forward, so there is a new setting that lets you hide data from before your start date, which will make the weight chart behave like the old site did:

What You Need to Know

Logging In

You'll need to log in again using your email address. When you log in with the same email you used before, your existing account and all your data will automatically transfer over.

Don't remember which email you used? No problem—just create a new account and connect it to your Withings or Fitbit account. TrendWeight will load all your historical data from your scale.

Also note, the old site used to let you login with a username only (not an email). That isn’t possible anymore. In the interest of improving security, the new TrendWeight doesn’t use passwords and relies on one-time login links via email or using Google, Microsoft, or Apple logins.

What's New

Connect Multiple Scales

You can now connect both Withings AND Fitbit to the same account. If you switch scale brands, there's no need to worry about losing historical data—just connect both and TrendWeight will combine everything into one continuous chart.

Better Mobile Experience

The weight charts on phones now show more than just the last 4 weeks. You can finally see your longer-term progress without switching to a computer.

Easy Data Export

Want to analyze your data in Excel or another app? There's now a simple way to download all your weight data from the settings page.

What's Gone

The chart image sharing feature has been removed since it was rarely used. Though you can still share a link to your dashboard with others—you'll find your sharing URL in the settings.

Technical Note

For those interested, TrendWeight is now open source. You can find the code on GitHub or read about the saga at Rebuilding TrendWeight.

Questions or Issues?

If you notice anything not working quite right, please let me know at erv@ewal.net.

Thanks for being a TrendWeight user!

What unstuck this project? AI coding tools, specifically Claude Code.

AI coding tools make tedious tasks easier. Plus, playing with new AI coding assistants is genuinely fun—they're like new toys. Sure, they're not perfect and sometimes generate questionable code, but they transform grunt work into something more engaging. The project stopped feeling like a chore.

I decided to not just finish the in-progress Next.js rewrite as is, and instead I decided to adjust the tech stack (again). My 2021 perspective on Next.js was overly optimistic. It's solid for content sites, but for interactive applications like TrendWeight, the server-side complexity adds up quickly. I also fell out of love with Chakra UI, and I wanted to move to Supabase instead of Firebase.

Current stack:

• Frontend: Vite (stable, fast, minimal configuration)

• Backend: ASP.NET Core (Vite SPAs need a backend, and I know C#/.NET well)

• Styling: Tailwind (utility classes over opinionated components)

• Authentication/Database: Supabase (self-hostable, Postgres compatible)

Claude Code handled the implementation well, particularly in dealing with grunt work:

• The entire authentication stack (social logins, email magic link)

• Migrating from Next.js to Vite + C#

• Migrating from Chakra UI to Tailwind

Of course, AI coding tools still make a bunch of mistakes, and TrendWeight is complicated enough that you can’t really vibe code and get away with it. I definitely had to pay close attention to what Claude was doing (and in not a few places had to go back and clean up questionable choices after the fact), but I still enjoyed the process.

The rewrite is almost done. Just testing and polish remain, primarily around user migration UX. If things go smoothly, you can expect a follow-up post in the next couple weeks announcing the launch of the new site, so stay tuned!

They ascended cautiously, weapons ready. In a chamber on the upper floor, they found her - an emaciated figure kneeling within a circle of power. On either side stood skeletal guardians, each bearing six arms laden with ancient weapons. They turned toward the party with terrible purpose as the woman raised her hollow eyes.

"You've made it here," she rasped. "Perhaps for good or ill, you now share my fate. If we are to survive this place, it will take all of us."

I’m in a gaming group that plays a weekly in-person Pathfinder 2e game. Tabletop roleplaying games like Pathfinder 2e thrive on collaboration and creativity, but keeping track of every twist, turn, and NPC encounter can feel like a chore. In my group, no one is really interested in taking detailed notes, even though we all have laptops at the table.

I'm a tech nerd who likes to play with new tools, so I decided to see if AI could help.

For our current mini-campaign, Sands of Yore, I’ve adopted a workflow that uses audio recordings, transcription tools, and AI language models to generate session notes and weave an ongoing narrative. In this post, I’ll walk you through how I set this up, from the hardware to the software to the AI processing. It’s changed how we keep track of everything without disrupting the play at the table.

At the end of the post, you'll find links to the prompts and other tools I use, as well as the full campaign narrative as it exists today.

The Setup

Hardware: Recording the Session

I started out simple: just recording our sessions with the built-in mic on my MacBook Pro. It worked, but not well. Audio quality was sketchy, especially for players sitting farther from the laptop which led to sketchy transcripts. Over time, I upgraded to two flat condenser microphones designed for conference tables (Shure CVB-B/O). These are zip-tied to the ceiling in the dedicated game room we play in, keeping the table clear while capturing great audio. The mics connect to a TASCAM Portacapture X6 audio interface that plugs into the MacBook via USB-C. This audio hardware is overkill, but if you have seen my other posts, you’ll probably not be surprised.

Transcription: Turning Audio into Text

I’ve tried several transcription tools and am still iterating on this process:

• Whisper: Open-source and free, Whisper processes audio locally. It’s decent but doesn’t have speaker recognition and occasionally has weird issues, like looping errors in the transcript. It also requires several manual steps to process the audio after each session.

• Apple Notes: The new Apple Intelligence transcription let's you add an audio recording to a Note and it will generate a transcript from this audio when you stop recording. It's on par with Whisper. It’s local and free (as long as you’re in the Apple ecosystem), but it makes my laptop grind to a halt for several minutes when processing audio from a four-hour session and doesn’t identify speakers either.

• Otter AI: This cloud-based tool was the best by far for transcript quality. It’s accurate, identifies speakers, and even transcribes live during the session. The downside? It’s not free, and you’re uploading your audio to a third-party service, which raises privacy concerns.

Interestingly, even the lower-quality transcripts worked fine for our next step, but Otter made things easier by avoiding having to manually process audio files. I think the speaker identification (diarization) might help the LLM understand the transcript so I want to find a way to get that without relying on a cloud too. I’m looking at automating Whisper with a separate speaker diarization tool via n8n to get similar results without the privacy trade-off and with more automation. That’s still a work in progress.

The AI

Once I have a transcript, this is where the AI comes in. I’ve tried both ChatGPT and Claude for this process, and Claude is the current winner for our workflow, both because Sonnet 3.5 seems to be better at this kind of text processing but also because of the power of Claude "Projects". Here’s what we do:

1. Create the Transcript: Process the session audio into a text file and save it to our shared Google Drive.

2. Summarize the Session: Using a generic summary generation prompt, I paste the transcript into Claude and let it work its magic. If something important gets missed, I ask for tweaks to ensure nothing critical is left out. The prompt is generic, and campaign specific details come from reference documents that are part of the project (see below)

3. Generate the Narrative: A second generic prompt turns the same transcript into a more creative narrative, fleshing out character moments, world details, and story arcs. Again, I’ll ask Claude to refine it if needed.

4. Save and Share: Both the summary and narrative go into shared Google Docs. Everyone in the group can review them before the next session, and Claude uses them to keep continuity week-to-week.

The Claude project is tied to our Google Drive, so the LLM can reference background details to improve accuracy and depth:

• World-building notes from our GM that detail the setting, deities, and lore.

• A reference doc with PCs and key NPCs, including descriptions, motivations, and relationships.

• Previous session summaries and the ongoing narrative.

Storing everything in a shared Google Drive (including prompts) helps keep it organized and easy for everyone to access. And when you add a document to a Claude Project from Google Drive, Claude monitors it for changes over time and so the AI always have the latest content even as people make changes outside of Claude.

Conclusion

I'm very happy with this workflow.

• Imperfect is fine: Transcripts don’t need to be perfect. No one reads the raw transcripts, so their quality only needs to be good enough for the AI to work with. The AI can handle a lot of cleanup and still generate great results.

• Context limits: Claude’s project context capacity grows with each session. And 4-hour transcripts are big. If it becomes an issue, we might need to split the project into separate narratives and summaries or trim the background details.

We’re using this system for a short campaign of 5-8 sessions, but it’s been so effective that we’ll definitely bring it into our next long-term campaign. Having AI handle note-taking and storytelling not only saves time but also adds a richer narrative layer to the game. It’s like having an extra player at the table whose sole job is to record and enhance the story.

If you’re struggling with keeping notes or want to try something new with your Pathfinder or Dungeons & Dragons game, give it a shot. AI may be able to take the responsibility for tracking your sessions—and you’ll have some amazing stories to show for it.

References

• These are the two prompts I use: Summaries and Narratives

• Our full current campaign narrative: The Sands of Yore, an Adventure

• Our session summaries: Session Summaries

• Audio hardware used is two of these microphones: Shure CVB-B/O, and this audio interface: TASCAM Portacapture X6

• Audio transcription apps tried: Whisper Transcription, Apple Notes, Otter.ai

• AI platform: Claude

CephFS has the concept of File Layouts. Essentially, these are extended attributes on files or directories that give CephFS hints about how it should handle file storage. One of the available fields indicates which data pool should be used to store a file. If you add that field to a directory, it applies to any files within that directory tree (unless an individual file or subfolder overrides the field).

So I did this when I started out, separating my terabytes of media files from my smaller amount of more performance-sensitive container data files.

But I didn't get it right. Oops.

After I had populated the file system with 20+ TB of files, I changed my mind about which pools I wanted to use. It's easy to change those extended attributes anytime you want, but that doesn't affect existing files—only new ones.

To get existing files to move to the newly assigned pools, you essentially have to recreate them so that CephFS sees them as new files and puts them in the right place.

I wanted to migrate files from their current pool to the newly assigned pool, and I didn't want to do it by hand.

After some searching for solutions, I found a piece of Python code written by Peter Woodman that sort of did this, but it didn't work exactly how I wanted. However, it was good inspiration.

I'm not usually a Python programmer, so I turned to ChatGPT, and it helped me create a similar standalone script that systematically processes a directory tree to move existing files to a new pool.

The code I ultimately ended up with and used is here: Migrate files in cephfs to a new file layout pool recursively (github.com)

In simple terms, the script does the following:

• Recursively loops through all files and folders, starting with the current folder

• For each file, checks if it is already in the desired pool by reading the virtual attribute. If it's already where it is supposed to be, skips it

• If the file is not correct and is a normal file, copies it to a scratch folder, then moves it back to the original location. This essentially moves the file to the new pool

• Restores file ownership and permissions after the copy/move

• Handles symlinks and hard links appropriately as well

All of this is parallelized so that the Ceph backend can be kept busy, by default processing 4 files simultaneously. Since every file copy essentially reads and rewrites the entire file, this is expensive on I/O. The parallelization helps ensure there is always something being copied, even during brief gaps where metadata is being checked, etc.

Ultimately, this worked even though it was slow (reading and rewriting 20+ TB of data takes a while). But it was automatic and happened in the background, and I didn't have to manually re-populate my file system from scratch, which is what I wanted to avoid.

tldr: I started with a modest NAS setup in my homelab, but my curiosity led me to build an 8-node Ceph distributed storage cluster. Ceph, though overkill for a home environment, offers scalable, resilient storage by distributing data across multiple servers. It supports various storage types like block, file, and object storage, making it versatile for different needs. My current setup includes management nodes and storage nodes with NVMe and SATA SSDs, providing high performance and capacity. I use CephFS for Docker containers, RBD for Proxmox VMs, and maintain backups with TrueNAS and Unraid. This journey has transformed my homelab into a robust, interesting playground for storage technologies.

Storage in my homelab started modest and pretty typical: A NAS appliance and some PCs/Macs that connected to it. Fast forward to today and I have an 8-node Ceph distributed storage cluster and multiple NAS servers. This is the story of my Ceph rabbit hole.

In the beginning...

The beginning was unremarkable. I have historically used a variety of NAS appliances from Synology, TrueNAS, and others. Storage was just a thing that I had. It sat in the background and was uninteresting.

But my homelab is a hobby. I mess with it because I have fun messing with it. The thing that triggered my journey into "let's play with storage" was actually a desire for non-NFS shared storage. I was using NFS mounts on my NAS to provide shared storage for VM virtual disks on my Proxmox cluster. But when I started playing with Kubernetes and Docker Swarm, I found myself wanting shared storage for containers that wasn't simply an NFS mount—if only for the fun of it.

I was already using Proxmox, and the Proxmox console has this tab for "Ceph." So naturally, I started to read about it, and it intrigued me.

Ceph

Ceph is overkill for a homelab of my size. A NAS is more cost-effective and straightforward. And boring. Ok, that's out of the way.

Ceph is a distributed storage system designed to scale out by combining a bunch of commodity hardware into one big storage cluster. What's cool about Ceph is that instead of storing data on single-purpose storage appliances like a traditional NAS, Ceph spreads the data across many regular servers, automatically keeping multiple copies so that everything keeps working even if some hardware fails.

So in my homelab, instead of having one big NAS box, I've got a whole bunch of small servers with Ceph installed that all work together to provide one big distributed storage system that's more resilient and scalable than a normal NAS. And not boring.

With Ceph, I just add hard drives (SSDs in my case) to the cluster, and their storage capacity is assimilated into the cluster. I define "pools" to store different kinds of data, and each pool has its own replication rules that determine how data in that pool is spread across devices.

In a traditional NAS with some variation of RAID, things work at the array level. That has a couple of interesting aspects. If you have a drive failure, you replace the drive and the array rebuilds itself to ensure you have protection. Until the drive is replaced, your array is degraded.

Also, if you need more space, you generally can't just add another drive. The array was built with a specific set of drives, and you can't just turn a 5-drive RAID 5 array into a 6-drive RAID 6 array. There are NAS solutions like Unraid that get around this. There are also solutions like ZFS that let you essentially combine multiple "sub arrays" into a larger pool of data. Of course, each has pros and cons.

With Ceph, data is not managed in "arrays" or at the level of drives. Instead, data in the cluster is broken down into blocks of data (called objects by Ceph), and those objects are distributed across available drives. Objects are replicated according to the rules you specify, either with simple "make multiple copies" replication or with erasure coding, which is a parity-like approach similar in concept to RAID5/6 but at the object level instead of at the drive level.

When a drive fails, the pools that have data on that drive become degraded, but Ceph immediately starts making new copies of the lost data on available space elsewhere in the cluster. Usually, within a short period of time (relative to a RAID array rebuild), your cluster is automatically back to a healthy state.

All you need to make this viable is enough free space in your cluster to accommodate one or more drives failing, and that free space can be small amounts across multiple nodes. You can replace the drive that died at your leisure so that you once again have spare capacity in the cluster for future failures.

Adding more capacity is as easy as adding a drive. Ceph will assimilate that new drive into the appropriate pools (based on rules), and behind the scenes, it will start rebalancing where data is stored so that the new drive takes on a share of the responsibility for the existing data.

When it comes to making this pool of storage available to clients, Ceph provides multiple options. Block storage (called RBD) is ideal for things like Proxmox virtual disk images. File storage (CephFS) lets remote servers mount folders similarly to how they do NFS shares, and this is what I use for the shared storage needs of my Docker cluster. Ceph also has S3-compatible object storage for cases where that is needed, but I don't currently have a use case for that in my own lab.

The other aspect I found really interesting was how the distribution of data actually works. In a distributed storage system, you might imagine that any time a client needs data, it first goes to some central server and asks, "Where can I find data X?" The central server then looks up the location and directs the client to the actual node that has the data. But Ceph does data distribution with math.

CRUSH (Controlled Replication Under Scalable Hashing) is the secret sauce that allows any Ceph client to calculate where a particular piece of data is stored in the cluster without having to ask a central lookup table. It does this by using a deterministic hashing function that takes into account factors like the cluster topology and desired replication level.

This means that clients can read and write data directly to the right places without a centralized bottleneck, which is a big part of what allows Ceph to scale out so well in real-world scenarios much larger than my lab.

Sorry. I think Ceph is really cool, and I got to rambling there a bit.

My Ceph Cluster

As I mentioned, I originally heard about Ceph because of Proxmox, and in fact, my original cluster was a Proxmox-managed Ceph cluster. That was cool and worked okay, but it meant anytime I wanted to add a new node to the cluster, it had to be a full-blown Proxmox node even if it was never going to perform any VM compute duties.

So recently, I transitioned to a standalone Ceph cluster managed by cephadm, one of the official orchestration engines available for Ceph. I now have a nice little cluster that can be centrally managed either from the built-in dashboard or from the command line on any of the three management nodes.

The orchestration engine makes sure that required services are deployed appropriately, including a monitoring suite. And anytime I add a new drive to any of the nodes, the orchestration engine notices it and adds it to the pool of available storage.

• 3x Minisforum MS-01 boxes (Intel i9-12900H, 64GB RAM, 10GbE, Ubuntu 22.04)

  • These are essentially management nodes. They run the mon, mgr, and mds services as well as things like Prometheus, Grafana, Alertmanager, and other cluster support services.

  • Each also has 2x NVMe M.2 SSDs (on top of the drive used for the OS) that back NVMe-specific storage pools for performance-sensitive workloads.

• 5x general "storage" nodes (misc Intel CPUs, 32GB RAM, 10GbE, Ubuntu 22.04)

  • These are mini-ITX tower PCs that were originally used as NAS boxes, so they have plenty of SATA connectivity. These don't run any Ceph services except OSDs.

  • Each currently has 5x SATA SSDs that are the default storage for pools and certainly for the pool that contains most of my media files.

I have allocated storage as follows:

• A CephFS file system that is mounted by my Docker VMs and serves as shared storage for container data so that a container can start up on any node and have access to its data. The filesystem is backed by two pools depending on the subfolder:

  • An NVMe pool that is used for Docker application files by default. This pool uses 3:1 replication.

  • A higher capacity but slower SATA SSD pool that is used for media files (photos, movies, TV shows, audiobooks). This pool uses 2+2 erasure coding to minimize additional storage costs versus 3:1 replication.

  • Individual folder trees are mapped to specific backend pools using CephFS File Layouts

• An RBD pool that is used by Proxmox to store VM virtual disks. This pool is backed by the NVMe drives for performance reasons and also uses 3:1 replication.

All nodes in the cluster have 10 GbE connections to each other and to the Proxmox hosts and VMs that connect to the cluster.

Backups

Ceph is now my primary storage mechanism, but I still have my old NAS servers. They are effectively used as backup targets at this point. One is currently running TrueNAS, and the other I am experimenting with Unraid.

The reason I have two NAS servers is because one of them used to be offsite (3-2-1 backups), but I had to bring it back to rebuild it. Once I decide if I like Unraid more than TrueNAS as a backup NAS, I will probably move one of them offsite again.

The data in the CephFS file system is backed up to each NAS. The TrueNAS server runs rsync tasks hourly to get any changes. For the Unraid server, I am experimenting with Borg Backup. I am not sure which I will standardize on in the long term.

Proxmox does its nightly VM backups of virtual disks to the Unraid server currently.

Additionally, I still have offsite backups for the most valuable files (family photos, important documents) via a nightly rclone task on the TrueNAS server that pushes an encrypted backup to Storj. Depending on how my experiments with Borg Backup go, I may use it to do remote backups to something like BorgBase, but that's TBD.

Wrapping Up

So that's my journey into the world of Ceph. What started as a simple curiosity has turned into a pretty cool distributed storage setup that keeps my homelab both functional and interesting. Sure, it's overkill for a home environment, and not inexpensive, but it's not boring!

The main parts of the lab are:

• A 3-node Proxmox cluster that runs VMs

• An 8-node Ceph cluster that provides primary storage

• Two separate NAS appliances that serve as backup targets (one of which I plan to move off-site)

• A Ubiquiti network with an OPNsense firewall/router and a Tailscale overlay network connecting most servers

• A Unifi Protect security camera system combined with Scrypted in a VM to make cameras available to Apple HomeKit

• Home Assistant in a VM

• A VM dedicated to Generative AI tinkering

• Many containerized applications in a 3-node Docker Swarm cluster

This is the start of a series of posts where I will dig into the details a few of these and give some perspective on why I ended up with the current state. In the meantime, here is a general overview diagram of what things look like as of May 2024:

The new TrendWeight was always going to be created with React. That was a given. I fell in love with the core idea of React years ago (given state -> render a UI), and am a drinking-all-the-koolaid fan at this point.

But there are parts of the React ecosystem that are not fun. I don't want to have to figure out bundling. I don't ever want to configure webpack by hand. That's fun for some people, but not me. I just want it to work. And keep in mind that bundling is just *one *of the things you need to figure out to create a production-ready app with React.

Fortunately, there are many "meta frameworks" these days that abstract all of the stuff away and just give you a clean development experience.

For the new TrendWeight, I had to choose one.

Create React App

Create React App (CRA) has been around for a long time. It was created by Facebook (who also made React), so surely it knows how to do React "the right way". Even though it sometimes positions itself as a quick prototyping tool, I have made real apps with it in the past. I have also maintained apps for years that were based on CRA. It works.

But... It feels like it's nearing the end of its prime (if it hasn't already ended).

• The dev experience is ok, but subpar compared to the alternatives.

• It can only make client-side SPA apps (vs server-rendered apps or hybrid apps)

• One of the creators of CRA explained recently that he's not sure CRA is the right long term path for React apps.

CRA does what it does really well, but it just doesn't feel like the right framework to start a new project in if I want to stick with something for years to come and be able to take advantage of future improvements to React.

Next.js

Next.js describes itself as the React framework for production. It has a lot going for it...

• It does everything that CRA does and then a lot more.

• It can build client-side-only apps but can also build full stack apps that do server-side rendering (SSR), entirely statically generated sites (SSG), or a sort of mix between the two with incremental static regeneration (ISR).

• Excellent SEO. Since pages can be either server rendered at runtime or statically rendered at build time. Search engines see the full contents of pages without having to load and run JavaScript.

• It handles routing out of the box (normally would use React Router by hand in a CRA or similar framework)

• It does code splitting by page automatically

• It has a lot of focus on production performance and includes optimizations for image handling, third party script loading, and font loading.

• It has a company (Vercel) and a professional team behind it that is committed to continuing to improve it over time.

• The Next.js team appears to be collaborating effectively with both the core React team on things like React Server Components and with the Google web team on optimizing apps for the best user experiences.

Sounds great. There are some possible complications that should be noted, though.

• Because it's not just a client-side app building framework, most of it's coolest features need a backend server (or a serverless platform, which ultimately still runs on servers).

• Many would arguably the "best" place to host a Next.js app is at Vercel. The devops experience is top notch, and everything just works on the day that a new feature is added to Next.js. But Vercel's pricing isn't great if you have a large team or if you use a lot of bandwidth. You can host it elsewhere, but you usually lose some of the magic Vercel brings.

The downsides of Vercel's hosting pricing aren't likely to be an issue for me (I'm a one-person team and TrendWeight isn't popular enough to use more than 1TB of bandwidth in a month).

I really like Next.js. I played with it and fell in love. I'm probably biased at this point, to be fair. The beta version of the new TrendWeight is currently a Next.js app.

Vite

Vite is a relative newcomer for React apps. By the time the chatter about Vite got loud enough for me to look at it, I had already started building the new TrendWeight with Next.js, so this didn't get a super serious look.

• It aims to have a blazing fast developer experience while also making all the hard things easy (similar goes to CRA).

• It's very new. I can't point to something specific, but it just "feels" not quite as mature as CRA or Next.js.

• I've recently used Vite for a small project at work and I was impressed with the speed of starting up the dev server. It was really nice.

I think it's likely that Vite could be a contender as a long term replacement for CRA for those that are looking for the same kinds of dev and build tooling that CRA provides, but with newer techniques.

Even if I had looked at this before picking Next.js, I probably wouldn't have picked it because I want more than just a client-side app. Vite has some SSR support, but it's still experimental.

Remix

Remix *was *around when I started looking at frameworks but it was in a closed beta available only to people willing to pay for it. The launch was... weird. Much of the messaging came across as a bit like, "Good news, we've finally figured out how to build good web apps. You're welcome!" The perceived smugness turned off a lot of people. That and the fact that it was closed made it uninteresting to me at the time.

Fast forward to November 2021 and Remix is now open source and people have been able to start looking at what it could actually do, and parts of it are very interesting.

• It's more like Next.js than CRA or Vite in that it is a full stack framework with a server.

• The server can run on lots more types of hosts than Next.js including both Cloudflare Workers and Fly.io meaning your "server" can run fully on the "edge" right next to your users.

• It presents a different (for React apps, at least) way of thinking about the boundary between client and server. For example, you write functions that are responsible for loading data and that sit beside your components. The Remix server seamlessly uses these functions when rendering your UI without you having to write typical code to call an API to get data. The Remix team asserts that this is a better way.

It's interesting, but similar to the Vite situation, it because interesting well after I had already started building with Next.js. I'm still watching it carefully though.

I'm inclined to build something with it at some point just to get some hands on experience. My games site is due for a refresh, and I may try Remix for that.

Conclusion

As I mentioned above, for TrendWeight I picked Next.js. I've been pretty happy with the choice so far. It's been easy to get up and running, the dev experience and the devops experiences have been great. I haven't run into any major roadblocks, so I'm feeling pretty good about the choice.

If Next.js worked out-of-the-box on Cloudflare Workers (CloudFlare is killing it with their Edge Compute services), I think it would be a slam dunk choice for most of my projects. I'm not sure how motivated Vercel is to make Next.js work on a competitive hosting service though.

First, I should be clear that TrendWeight works fine. The picture I chose for this article is an exaggeration. TrendWeight is not broken. I doesn't have meaningful scalability problems. It's fine.

So why bother with a rewrite? It's just old.

There are a number of improvements that people have asked for over the years, and I've avoided tackling them because I don't enjoy working in that old tech stack anymore. I could, but it's just not fun.

So the biggest reason to rewrite it is that rewriting it will be fun. Not only does the app get freshened up, but I also get to play with new tech!

TrendWeight Tech Stack

So what is the old tech behind the current TrendWeight?

• The web framework is ASP.NET MVC (version 3).
• The frontend uses vanilla JavaScript and several old libraries, notably including jQuery (!) and Knockout.js 2.1. The capabilities of Knockout were pretty great, and in a way, they were ahead of their time.
• The core chart component that renders the main weight graph is Highcharts Stocks. This is still a great component and I plan to keep using it, though I will move to the latest version.
• Styling is Bootstrap v2.0.4
• Data is stored in a SQL Server database with nothing weird with how it is used.
• User management / authentication uses ASP.NET Membership (the precursor to ASP.NET Identity). Essentially it's a series of SQL tables in the same SQL database along with a set of C# classes that manage the gross parts of securely managing passwords, etc.
• The site is hosted in Microsoft Azure App Service

TrendWeight just hasn't gotten the care and feeding it probably deserved over the past decade and so lots of its dependencies are woefully out of date. Some days I'm surprised that it still actually works in modern browsers 10 years after it was initially created.

So something needs to be done to bring the app up to date and to make it maintainable. Instead of incrementally updating things piece by piece, I decided a while ago that it would be easier to just start fresh using a modern tech stack.

A new, clean code base will also let me make the source code available without being embarrassed by how clunky everything is.

I'll talk more about the planned tech stack in another article...

Will this time be different? Probably not. Am I going to start a new cycle anyway? Yes!

Anyway, there are a few things bouncing around in my head that I want to capture and share with others that generally fall into these categories...

• Building apps with Next.js
• React and its ecosystem (Next.js, Remix, etc.)
• Smart Stuff, Home Assistant, and Node Red

This cycle will be done with Hashnode because I'm at a point where I don't want to spend time maintaining a blog platform. I've done that in the past. This time I'm going to let someone else manage it.

Let's do it...

A common question on various weight loss forums I see is, "How often should I weigh myself?" There are lots of reasonable answers to that question, but I tend to favor "Every Day" as the best answer, but there is a catch! If you don't want to go insane, you absolutely must ignore what the scale says each day and only look at the trend over time. What does that mean?

Normal Daily Weight Fluctuations

John Walker talks about this in much more detail in his book, The Hacker's Diet, but I'll summarize the key point here. A lot goes into your body every day and a lot comes out. The food you eat, the liquids you drink, the air you breath, etc all come in. And in general, an equal amount of those things come back out as well. For a typical person, these add up to 13.5 pounds of "stuff" coming in and out of your body each day:

But keep in mind that that balance of 13.5 pounds in and 13.5 pounds out is only an average over time. On any given day, at any given time of the day, your intake may be more or less than your outputs often by as much as 1-2 pounds. Keep this in mind: Even if you are not gaining or losing weight (i.e. fat or muscle), if you weigh yourself every day, the scale will still show your weight going up and down each day, often by as much as 1-2 pounds. That's just the way it is. What matters is that, in that example, the fluctuations will be consistently around a particular weight.

Mental Stress

Losing weight is hard. Really hard. And a good portion of it is mental. It takes real mental effort to really change your lifestyle or behavior in order to lose weight. I you are trying to lose weight and you step on the scale tomorrow morning and it says you gained half a pound, that may psychologically crush you and make you question your resolve, not to mention how it would feel to see that happen 5 out of every 10 days. But as I just explained, if you weigh yourself every day, the scale is going to go up on some days.

The solution is to focus on the weight trend and not any individual day's weight. By focusing on the weight trend, the random day-to-day fluctuations will fade into the background and you can focus on the fact that you're making consistent progress towards your goal. Figuring out your weight trend is pretty easy to do, but I'll come back to that in a minute.

Wait, if weighing yourself every day has all these issues, why do it? Why not just weigh your self less often? That is an alternative option, but remember that if random day-to-day changes may often be as much as 1-2 pounds and you want to make sure that real weight loss isn't hidden by these, they you may have to weigh yourself really infrequently.

If you are trying to lose 1 pound per week, you'd have to weigh yourself only once every 2-3 weeks in order to make sure that your real weight loss always shows through the "noise" of random daily fluctuation. That's a long time to go without any positive feedback. By weighing yourself every day and focusing on the trend instead of the number on scale, I get daily reinforcement that I am slowly but surely making progress. That helps. A lot.

Focusing on the Trend

Let me show you in pictures what this really means. I have been weighing myself nearly every day for the past year. First let's look at what my day-to-day weight changes have been over the past year. In this picture, the green arrows are days where the scale showed a lower number than the day before (yay! I lost weight), and the red arrows are days where the scale showed a higher number than the day before (oops! I gained weight):

So how did I do? Over the long term, if you looked at the actual numbers, it would be obvious that I lost weight, but in the trenches, day-to-day, if I was focusing on the number on the scale, I would have felt like I was on a crazy roller-coaster and likely I would have been highly frustrated:

Ok, so that sucks. But what kind of difference does it make if I look at the weight trend each day instead of the number on the scale? Let's say each day I figure out what my average weight was over the past 10 days (let's call that my "trend weight"). Because this trend weight is an average of many days, the random day-to-day fluctuations will mostly cancel each other out, and the trend weight will slowly go down each day if my weight is decreasing over time. You may commonly hear this idea of a trend weight referred to as a "moving average".

But let's not worry about the math right now, and let's just see what this does to my day to day mental stress. If I take my daily weight data for the last year and look at trend weights instead of what the scale said on any given day, here is the result:

What a difference! For the first two thirds of that time range, I was pretty happy almost every day because almost every day, the trend weight got a little smaller day after day. I can tell you that this reinforcement was a huge help, especially at the beginning when I was not sure I had it in me to lose the weight I needed to lose.

In the last third of this time range, I had some hiccups. I really was gaining weight, so the trend weight wasn't lying. If you are curious, the first long stretch of weight gain was the result of a change to my blood pressure medications that affected how much water I retained and as a result, I gained 10 pounds over the course of two weeks. And the second long stretch was a family vacation where I fell off the wagon, so to speak. The good news is that I'm back on track and have re-lost all the pounds I gained over the summer.

Ignore the specifics of my situation for a moment and look at the two pictures again. I hope you can see what a difference looking at the weight trend makes. I think the daily, positive reinforcement was key to my really getting over the initial mental hurdle at the start.

How?

Ok, so I think you get my point that I am a huge fan of daily weight measurement combined with the use of a moving average to look at the weight trend instead of any individual scale reading. Doing this is not as hard as you might imagine and doesn't require you to be a math wiz either.

In my opinion, the best actual technique to monitor your weight trend over time is the one that John Walker describes in The Hacker's Diet in the "Signal and Noise" chapter. There are lots of free tools available that handle all the math that John talks about so that you don't have to worry about it.

First, is the web application I built, initially just for myself, to do this kind of tracking for people that have Fitbit or Withings WiFi scales. If you have one of those scales, TrendWeight is free and will automatically pull your weight readings each day and show you your weight trend. Note, you actually don't need a WiFi scale to use TrendWeight. It works just as well even if you just have a FitBit.com account and are using their iPhone app to manually enter your weight each day.

But there are lots of other options if you don't have a fancy electronic scale as well. There are both iPhone apps and Android apps that have this approach baked in. You manually enter your weight each day, and they do all the math for you.

If you don't want to use your smartphone, there are websites that will let you manually enter your weight each day and will also do all the math. John Walker created the Hacker's Diet Online to do this, and Physics Diet is another popular choice.

And last but not least, you don't even need a computer to do this. John Walker also explains how you can do this yourself with a sheet of paper and a pencil you keep next to your bathroom scale and all you need is basic addition and subtraction (no calculator needed). You can read about it in the Paper and Pencil chapter of his book.

If you are trying to lose weight, first, good for you! Second, I hope I have convinced you to at least try weighing yourself daily and calculating your trend weight. I honestly believe this approach will help you see your daily successes without getting distracted by random day-to-day fluctuations.