Dev on Ricardo Dantas

Building LowfiTimer: A Focus App That Runs Everywhere

Thu, 26 Mar 2026 06:00:00 +0100

I’ve tried every focus timer out there. And I mean every one. They’re either too simple (just a countdown), too bloated (social features, gamification, AI coaching), or too expensive ($40/year for a timer?). The ones that actually worked well always came with a subscription attached.

That bothered me.

A timer doesn’t need a server. Sounds don’t expire. There’s no reason a focus app should cost more per year than some people pay for music streaming. So I decided to build my own.

The Idea

The core concept was simple: combine the Pomodoro technique with ambient sound mixing. I’ve always used background sounds to focus. Rain, coffee shop noise, brown noise. But I’d have one app for the timer and another for the sounds, and they never worked together.

I wanted one app that handled both. Set your timer, pick your sounds, and go.

What I didn’t anticipate was how far I’d take it.

Going Universal

I started with iOS. That’s the natural starting point for most people. But once the architecture was in place, I kept thinking: why not the Mac? I already sit in front of one all day. A menu bar timer with ambient sounds would be perfect for work sessions.

Then watchOS. Being able to glance at your wrist and see how much focus time is left, without reaching for your phone, felt like a genuine quality-of-life improvement.

And then, honestly just because I could, tvOS. The idea of turning your living room into an ambient focus environment was too fun to pass up.

The result is a single codebase (with platform-specific adaptations) running on iPhone, iPad, Mac, Apple Watch, and Apple TV. One purchase covers everything.

The Sound Engine

This was the part I enjoyed building the most. LowfiTimer ships with 25 ambient sounds, all CC0 field recordings. Rain on a window, a crackling campfire, forest birds, coffee shop chatter, ocean waves. Plus generated noise types: white, brown, pink, gray, and blue.

You can layer up to 5 sounds simultaneously on iOS/macOS/tvOS (3 on watchOS), each with independent volume control. The mixing happens in real-time with AVFoundation.

Finding the right sounds took longer than writing the audio code. I spent days listening to rain recordings, trying to find ones that looped naturally without obvious seams. The campfire sound went through four iterations before it felt right. Subtle things matter when you’re going to hear them for hours.

I also added distinct transition sounds: a singing bowl ding when focus resumes, and a deep breath (inhale/exhale) when a break starts. Small touches, but they make the transitions feel intentional rather than jarring.

watchOS Was the Hardest Part

Building for the watch taught me things I didn’t expect. The biggest constraint? No audio files. Bundling 25 sound files on watchOS would bloat the app beyond what’s reasonable for a watch.

So I went a different route: procedural synthesis. The watchOS sound engine generates all 16 available sounds mathematically in real-time. Rain is filtered noise with random amplitude modulation. A campfire is layered crackling patterns. It’s not identical to the recorded versions on iPhone, but it’s surprisingly close, and it uses almost no storage.

The other challenge was background execution. watchOS is aggressive about suspending apps. To keep the timer running while your wrist is down, I used WKExtendedRuntimeSession, which gives you up to 30 minutes of background time. For longer sessions, the app re-requests the session before it expires.

Digital Crown integration for volume control was a nice win. Twist the crown to adjust your mix volume without looking at the screen. It’s one of those details that makes the watch version feel native rather than a shrunken phone app.

13 Presets (and Unlimited Custom Ones)

I knew not everyone wants to build their own sound mix from scratch. So I created 13 built-in presets: Deep Focus, Cafe Writer, Library Study, Rainy Cabin, Forest Morning, and more. Each one is a curated combination that I actually use.

But the real feature is custom presets. Build your perfect mix, save it with a name and emoji, and it syncs across all your devices via CloudKit. Your “Late Night Coding” preset on your iPhone is already there on your Mac.

The Stats I Actually Wanted

I’ve always found that tracking focus time motivates me to do more of it. But most apps either show you nothing or drown you in charts you’ll never look at.

I kept it focused (pun intended): a daily progress ring, a weekly bar chart, streak tracking with a flame that grows the longer you maintain it, and a GitHub-style heatmap. Enough to see patterns and feel progress, not so much that the stats screen becomes its own distraction.

Sessions also log as mindful minutes in Apple Health if you opt in, so your focus time counts toward your overall wellness tracking.

Siri, Widgets, and the Little Things

Seven App Intents power the Siri integration. “Hey Siri, start a focus session.” “Load my Rainy Cabin preset.” “How much have I focused today?” No setup required, they just work once you install the app.

Widgets show your daily progress and streak on the home screen and lock screen. On watchOS, Smart Stack widgets put your focus stats right in the watch face complications.

Focus Filters let LowfiTimer respond to iOS Focus modes. When you switch to your “Work” focus, the app can automatically adjust. These are the kinds of platform integrations that make an app feel like it belongs on Apple devices rather than just running on them.

No Server, No Tracking, No Excuses

This is the part I care about most. LowfiTimer has no backend. Zero. There’s no analytics SDK, no crash reporter phoning home, no “anonymous” usage data. The app literally doesn’t have networking code beyond iCloud sync.

Your focus sessions, presets, and settings live on your device and in your private iCloud account. I never see them. I can’t see them. That’s by design.

The business model is aligned with this: a one-time purchase, and it’s yours forever. All platforms included. I don’t need to track you because I’m not selling your attention to advertisers. I don’t need a subscription because there’s no server to pay for.

What I’d Do Differently

If I started over, I’d extract the shared models into a Swift package earlier. I did it eventually (SharedModels target), but the initial approach of duplicating model code across platforms created merge headaches.

I’d also prototype the watchOS audio engine first instead of last. The constraints of that platform forced architectural decisions that would have been easier to make at the beginning.

And I’d spend less time on the mesh background animation. It looks beautiful, and it shifts colors based on your timer state, but the amount of time I spent tweaking gradient control points was… excessive. Sometimes you have to ship.

Try It

If you’re someone who uses background sounds to focus, or if you’ve been looking for a Pomodoro timer that doesn’t try to be a social network, give LowfiTimer a look.

Download on the App Store | Website

Building BragLog: Turning Daily Wins Into Brag Documents

Mon, 16 Mar 2026 06:00:00 +0100

Performance review season is universally dreaded. Not because people don’t do great work, but because nobody remembers what they did six months ago. You sit down with a blank document, try to recall that critical bug you fixed in July, that feature you shipped under pressure in September, and end up writing something generic that undersells everything.

I’ve been there too many times.

The Problem

The advice is always the same: “keep a brag document.” Write down your wins as they happen. Julia Evans wrote a great post about it years ago, and the concept stuck with me. But every time I tried, I’d keep it up for a week, forget about it, and find myself back at square one come review time.

The friction was the problem. Opening a text file, context-switching from whatever I was working on, writing something coherent. It’s just enough resistance that you skip it on busy days, which are exactly the days worth documenting.

What I Built

BragLog is a native app for iPhone, iPad, and Mac. The core loop is simple: log a quick win (takes seconds), and when review time comes, tap a button and get an AI-generated brag document ready to paste into whatever form your company uses.

Six categories keep things organized: Shipped, Led, Fixed, Learned, Mentored, Improved. They map roughly to the things managers care about in reviews. The app suggests a category as you type using on-device AI, so you don’t even have to think about it.

On-Device AI With Tool Calling

The brag document generation is the feature I’m most proud of, and also the one that caused the most headaches.

I used Apple’s FoundationModels framework, which runs entirely on-device. No API keys, no cloud calls, no data leaving the phone. The model generates structured brag documents using Tool Calling: it can fetch entries for a specific period, get category breakdowns, and pull streak information, then weave it all into a coherent narrative.

You can choose a tone (professional, confident, or modest) and the AI adapts accordingly. The output comes as structured sections that you can export as Markdown, plain text, or HTML compatible with Word, Pages, and Google Docs.

The catch? FoundationModels requires Apple Silicon. On older devices, the AI features gracefully degrade. You can still log, organize, and export everything manually. The AI is a convenience layer, not a hard dependency.

One lesson I learned the hard way: the @Generable macro and Tool Calling have quirks. You can’t capture SwiftData @Model objects in tool closures because they’re not Sendable. I had to create a SendableEntry pattern where I extract plain data from model objects before passing them to the AI pipeline. Not complicated once you know, but it cost me a few hours of confusing compiler errors.

Intelligent Search

Standard text search feels limiting once you have hundreds of entries. “I know I fixed something related to database performance, but I didn’t use the word ‘database’ in the entry.”

BragLog’s search uses FoundationModels for semantic matching. Search “database” and it’ll surface entries about SQL migrations, query optimization, and PostgreSQL tuning even if those exact words aren’t in the query. There’s a debounce (0.8 seconds) and a cap at 200 entries to keep it responsive.

The Streak Game

I added streak tracking because I know myself. A GitHub-style contribution heatmap, daily progress, and milestone celebrations at 7, 30, and 100 days. It’s a small psychological trick, but it works. There’s a grace period built into the streak calculator so missing a weekend doesn’t break a work-week streak.

The streak also shows as a Live Activity on the Lock Screen and Dynamic Island on iOS. It’s a subtle reminder throughout the day. “You’ve logged for 23 days straight. Don’t break the chain.”

17 Tips and an Animated Onboarding

I went deep on TipKit. Seventeen contextual tips that appear progressively as you use the app. First-time composing? You get a tip about AI category suggestions. Hit 10 entries? A tip about generating your first brag doc. Reach the insights screen? Tips about the heatmap and streak tracking.

The onboarding is a 4-page animated flow with MeshGradient backgrounds, floating particles, and spring animations. I probably spent more time on this than I should have, but first impressions matter, and I wanted the app to feel polished from the moment you open it.

Making It Feel Native Everywhere

The iOS version uses an adaptive tab bar with Liquid Glass styling on iOS 26. On iPad, it switches to a sidebar. On Mac, it’s a full NavigationSplitView with a menu bar extra for quick capture. You can log a win from the menu bar without switching away from your code editor.

Widgets cover Home Screen, Lock Screen, StandBy, and Control Center. Seven Siri Shortcuts let you log wins, check your streak, or generate summaries by voice. Handoff lets you start composing on your iPhone and continue on your Mac. Spotlight indexes all entries so you can find them from system search.

None of these integrations are individually complex, but together they make the app feel like it belongs on the platform rather than just running on it. That’s the goal.

Zero Dependencies

BragLog is built entirely with Apple frameworks. No SPM packages, no CocoaPods, nothing. Swift 6 with strict concurrency, SwiftUI, SwiftData, CloudKit, FoundationModels, TipKit, WidgetKit, AppIntents, CoreSpotlight, ActivityKit. About 7,700 lines across 48 Swift files.

I chose this constraint deliberately. Every third-party dependency is a maintenance burden and a potential privacy concern. For an app that handles people’s work accomplishments, I wanted to be able to say with certainty: nothing in this app talks to anyone except Apple’s iCloud, and only if you have it enabled.

What I’d Do Differently

The @Generable struct wrappers for FoundationModels output were clunky at first. I’d design the model layer around the AI output format from the start instead of retrofitting it.

I’d also invest in screenshot automation earlier. I built a DebugDataSeeder that generates realistic sample data for App Store screenshots, but I added it late in the process. Having it from day one would have made design iteration faster.

And the 17 TipKit tips? I’d still do all of them, but I’d define the milestone triggers in a configuration file rather than scattering them across views. They work great, but they’re harder to maintain than they should be.

Try It

If you’ve ever stared at a blank self-review form trying to remember what you did last quarter, BragLog might help. Log your wins as they happen, let AI do the heavy lifting at review time.

Download on the App Store | Website

Launching Calometric: A Nutrition Tracker That Respects Your Privacy

Thu, 05 Mar 2026 10:00:00 +0100

I’ve never been great at tracking what I eat. I’d download a calorie tracker, spend five minutes manually searching for “grilled chicken breast 150g,” give up after three days, and delete the app. The friction was always too high.

Most nutrition apps want you to weigh everything, type everything, and subscribe to everything. And in return, they collect your data and sell it to advertisers. That never sat well with me.

So I built something different.

Introducing Calometric

Calometric is a nutrition tracker for iPhone and Apple Watch. Take a photo of your meal, and it tells you the calories and macros. That’s the core idea.

What makes it different is where the AI runs: entirely on your device. The food recognition uses Core ML, and the portion estimation uses Apple’s Foundation Models. Nothing gets sent to a server. There’s no account to create. No data to leak.

Five Ways to Log

Not every meal is a photo opportunity. Sometimes you’re eating a protein bar with a barcode. Sometimes you’re driving and just want to say “two eggs and toast.” So I built five input methods:

Photo scan for when you can snap a picture
Barcode scanner for packaged foods (via Open Food Facts)
Voice logging for hands-free moments
Food search against a local USDA database with 177+ foods
Nutrition label OCR for when you want exact numbers from the package

Each one feeds into the same pipeline and saves consistently to SwiftData, HealthKit, Spotlight, and widgets.

Why On-Device AI?

Privacy was a hard requirement from day one. I didn’t want to build something that phones home every time you eat lunch. But beyond privacy, there’s a practical benefit: it works offline. On a plane, in the mountains, in your kitchen with spotty Wi-Fi. It just works.

The trade-off is that on-device models aren’t as powerful as cloud models. The AI portion estimation requires an iPhone 15 Pro or newer with Apple Intelligence enabled. On older devices, everything still works, you just get default portion sizes instead of smart estimates.

Apple Watch Too

I wanted to log meals from my wrist. The watchOS app is fully independent, with voice logging, a quick-add menu of common foods, and complication widgets showing your daily progress. It syncs with the iPhone via WatchConnectivity.

The Business Model

One-time purchase. That’s it. No subscriptions, no ads, no in-app purchases. One price covers iPhone and Apple Watch.

I keep coming back to this model because I believe in it. If you’re building a tool that respects people’s privacy, charging them a recurring fee to keep accessing their own data feels contradictory.

Try It

If you’re looking for a nutrition tracker that stays out of your way and keeps your data on your device, give Calometric a look.

Download on the App Store | Website

ratatui-themes: Building a Theme Library and Finding a Community

Mon, 02 Mar 2026 10:00:00 +0100

There’s a moment in every side project where you push your code to the world and think, “Well, that’s done.” You close the laptop, maybe feel a brief spark of accomplishment, and move on. Nobody’s going to notice. It’s just another crate in a sea of crates.

And then someone opens an issue.

The Backstory

While building Perch, Feedo, and Hazelnut, I kept running into the same problem: theming. Every ratatui application handles colors differently. Some hardcode hex values. Others define their own theme structs. There’s no shared vocabulary for “give me a Dracula theme” or “switch to Catppuccin.”

I wanted a simple, reusable library. Define a theme by name, get consistent semantic colors (foreground, background, accent, error, warning, success) that any ratatui app could use. No runtime overhead. No complex configuration. Just Theme::new(ThemeName::Dracula) and you’re done.

So I built ratatui-themes.

What It Does

The crate is deliberately minimal. It gives you:

15+ popular themes - Dracula, Nord, Catppuccin (all four flavors), Gruvbox, Tokyo Night, Solarized, One Dark, Kanagawa, Everforest, Rosé Pine, and a few originals
Semantic colors - Every theme maps to the same set of named colors, so your app looks consistent regardless of which theme the user picks
Theme cycling - Built-in next() and prev() methods, because every TUI app needs a “press T to switch theme” feature
Light/dark detection - Programmatically check if a theme is light or dark, useful for adapting UI elements
Optional serde support - For persisting the user’s theme choice in a config file

Zero dependencies beyond ratatui itself. The whole thing compiles in seconds.

Publishing to crates.io

Publishing a crate is oddly nerve-wracking every time. You run cargo publish, watch the progress bar, and suddenly your code is on crates.io for anyone to install. There’s no review process, no gatekeeper. Just you and the Rust ecosystem’s trust model.

I wrote thorough documentation: rustdoc with examples for every public function, a detailed README, a changelog. Partly because good docs matter. Partly because if someone was actually going to use this, I didn’t want them to have to read my source code to figure out how.

Then I waited. Not expectantly. I genuinely assumed the crate would sit there with maybe a handful of downloads from bots and search indexers.

The First Issue

A few days later, I got a GitHub notification. Someone had opened an issue. My first reaction was a small adrenaline spike, the kind you get when your phone rings unexpectedly. Is it a bug report? Did I break something?

It wasn’t a bug. It was a feature request. And not just any feature request, but a thoughtful, well-structured proposal for “associated colors.” The idea was to add extended color palettes (reds, greens, blues, etc.) that go beyond the core semantic colors, useful for things like charts, graphs, and data visualization.

The message opened with: “I was just looking for something like this three days ago when you published it. Amazing timing!”

I read that line three times. Someone had been looking for exactly what I built. The timing was coincidental, but the validation was real. This wasn’t a theoretical exercise anymore. Someone had a concrete use case, and my crate was close enough to what they needed that they wanted to help shape it.

The First Pull Request

Then came the pull request. They’d built a theme gallery example, a visual picker that renders all available themes side by side so you can see what they look like before choosing one. 192 lines of additions, cleanly written, with a new ThemePicker widget.

I reviewed the code, left some comments, we discussed the approach, and I merged it. The whole interaction was respectful, constructive, and genuinely fun. This is open source at its best: a stranger on the internet saw something they liked, made it better, and shared the improvement with everyone.

Why This Matters

I’ve contributed to open source projects before. I’ve opened PRs, filed issues, and reviewed code on other people’s repos. But being on the receiving end is a completely different experience.

When someone uses your library, they’re trusting your decisions. Your API design, your color choices, your documentation. When they open an issue, they’re investing their time to make your project better. When they submit a PR, they’re saying “I believe in this enough to write code for it.”

That’s a powerful thing. And it’s easy to take for granted if you’ve been in the open source world for a while. But with ratatui-themes, it hit differently.

What I Learned

If you’re sitting on a library or tool that you built for yourself, consider publishing it. Here’s what I learned:

Someone needs what you built. You wrote it to solve your problem. Chances are, someone else has the same problem. The timing might just line up.
Documentation is your first impression. Good docs with real examples lower the barrier to adoption. People will judge your crate by its README before they ever read a line of source code.
Start small. ratatui-themes does one thing. It doesn’t try to be a full UI framework or a design system. Focused libraries are easier to maintain and easier for others to adopt.
Be responsive. When that first issue comes in, engage with it. The early contributors are the ones who’ll shape your project’s direction. Treat their input with respect.
It doesn’t have to be perfect. Version 0.1.0 had rough edges. That’s fine. Ship it, iterate, improve. The crate is on 0.2.0 now, and each version is better because of real-world feedback.

What’s Next

The “associated colors” proposal from that first issue is still being discussed. We’re figuring out the right API. I suggested a HashMap<String, Vec<Color>> approach instead of fixed fields, which would be more flexible and future-proof.

The crate is integrated into Feedo, Perch, and my other TUI apps. It’s doing exactly what I built it to do: making theming consistent and easy across projects. But now it’s also doing something I didn’t plan for: connecting me with other developers who care about making terminal apps look beautiful.

And honestly? That’s better than any download count.

Check it out: crates.io/crates/ratatui-themes | GitHub | Docs

PRs and new theme suggestions are always welcome. 🎨

Perch: Social Media from the Terminal

Fri, 27 Feb 2026 10:00:00 +0100

I’ve been on a bit of a streak with Rust and terminal apps. After Feedo and Hazelnut, I kept looking for things I do daily that could live in the terminal. Social media was an obvious one, and an interesting challenge.

The thing about social media clients is that they’re either overwhelming web apps with infinite scroll and algorithmic noise, or they’re bare-bones API wrappers that feel like work. I wanted something in between: a beautiful, keyboard-driven interface that makes social media feel intentional instead of addictive.

Why a Terminal Client?

I spend most of my day in the terminal. Between coding, managing files with Hazelnut, reading feeds with Feedo, and everything else, the terminal is home. Opening a browser tab for Mastodon or Bluesky always felt like a context switch. And context switches are expensive.

There’s also something philosophical about using social media in a terminal. It strips away the visual manipulation: the infinite scroll, the notifications badge, the algorithmic feed. You see the content, you engage with it, and you move on. It’s social media on your terms.

What Perch Does

Perch supports both Mastodon and Bluesky, which covers the decentralized social networks I actually use. You authenticate once, and then everything works through either the TUI (text user interface) or the CLI.

The TUI is a three-panel layout: accounts on the left, timeline in the center, and post detail on the right. It’s navigated entirely with vim keybindings, which at this point feels as natural as breathing. You can browse your home timeline, like and boost posts, reply, compose new posts, everything you’d do in a web client.

But the part I’m most proud of is cross-posting. Write a post once, and Perch sends it to both Mastodon and Bluesky simultaneously. I’ve been maintaining a presence on both networks, and doing it manually was getting old. Now it’s one command or one keystroke.

The CLI side is equally useful. You can script your social media: schedule posts, fetch timelines, manage accounts, all from shell scripts or cron jobs. It composes nicely with other tools.

The Technical Bits

Building a multi-network social client in Rust was more complex than my previous projects. Mastodon uses OAuth and a REST API, while Bluesky uses the AT Protocol with app passwords. Abstracting these behind a unified SocialApi trait took some careful design, but the result is clean. Adding a new network in the future would be straightforward.

Credentials are stored in the system keyring (via the keyring crate), so no plaintext tokens lying around in config files. There’s also a SQLite-backed cache for offline reading, which means Perch works even when your connection doesn’t.

For theming, I integrated ratatui-themes, a theme library I built separately. Perch ships with 15 themes out of the box, from Dracula to Catppuccin to a neon Cyberpunk theme that’s entirely too fun.

What I Learned This Time

Each Rust project teaches me something different:

Trait-based abstraction pays off. The SocialApi trait let me treat Mastodon and Bluesky uniformly throughout the app. When I added cross-posting, it was trivial because the abstraction was already there.
OAuth in Rust is painful. Not because of Rust itself, but because OAuth flows involve HTTP redirects, local servers, token exchange… it’s inherently messy. Getting it right took more time than I’d like to admit.
SQLite is the right default. Every time I reach for SQLite in a desktop/CLI app, I’m reminded how good it is. Zero configuration, embedded, fast. The rusqlite crate makes it feel native to Rust.
People care about themes. I added theming almost as an afterthought in Feedo, and it was the most commented-on feature. For Perch, I made it a first-class concern from day one.

Try It

Perch is open source and available now:

Website: perch.ricardodantas.me
GitHub: github.com/ricardodantas/perch
Install: brew install ricardodantas/tap/perch or cargo install perch

If you use Mastodon, Bluesky, or both, give it a try. It might change how you think about social media. Or at least save you from opening another browser tab. 🐦

Launching Pikr: A Color Picker for Accessibility-Minded Developers

Tue, 17 Feb 2026 16:00:00 +0100

If you’ve ever worked on a UI, whether as a developer or designer, you know the dance. Pick a color. Check if it’s accessible. Open another tool. Paste the hex code. Check the contrast ratio. Realize it fails AA. Go back. Adjust. Repeat.

It’s tedious. And it’s a workflow I’ve done hundreds of times.

So I built something to fix it.

Introducing Pikr

Pikr is a color picker with built-in WCAG accessibility contrast checking. Pick any color from your screen, and instantly see if it meets AA or AAA compliance standards. No switching between apps. No copy-pasting hex codes into web tools. Just pick and know.

It sounds simple because it should be simple. That’s the whole point.

The Problem It Solves

Accessibility isn’t optional anymore, and it shouldn’t be. But the tooling around it has always felt fragmented. You have your design tool, your color picker, and then some separate contrast checker (usually a website). Every time you want to verify a color choice, you’re context-switching.

I wanted something integrated. Pick a color, see the contrast ratio against your background, know immediately if it passes. All in one place.

What It Does

Pikr keeps things focused:

Pick colors from anywhere on screen - Works system-wide, not locked to any specific app
Instant WCAG contrast checking - See AA and AAA compliance as you pick
Multiple color formats - Hex, RGB, HSB, HSL, LAB, and OpenGL
Clean, minimal interface - It stays out of your way until you need it

Nothing more than necessary. I’ve grown to appreciate tools that do one thing well.

Why Tauri?

After spending time with Rust building Feedo and Hazelnut, I wanted to apply what I learned to a desktop app with an actual GUI. Tauri was the natural choice. It combines a Rust backend with a web-based frontend, resulting in small, fast, native applications.

The development experience was smooth. Tauri handles the cross-platform complexity (system tray, global shortcuts, native dialogs) while letting me use familiar web technologies for the interface. The final binary is tiny compared to Electron-based alternatives, and it feels snappy.

Pikr currently runs on macOS and Linux, with Windows support coming soon.

Shipping Something

There’s something satisfying about taking a personal frustration and turning it into a tool others can use. Pikr started as a solution to my own workflow problem, but accessibility affects everyone building interfaces. If it saves someone else from the tab-switching dance, that’s a win.

The app is available at getpikr.app for $5, or $3 right now with a 40% launch discount. It’s not free, but it’s also not trying to be a subscription or harvest your data. Just a small tool that does its job.

What’s Next?

I’ll keep refining Pikr based on feedback and my own usage. Windows support is the immediate priority. Beyond that, I have some ideas for features, but I want to be careful not to bloat it. The simplicity is intentional.

If you’re a developer or designer who cares about accessibility (and you should), give it a look. And if you have feedback, I’d love to hear it.

Let’s see where this one goes. 🎨

Building TUI Apps with Rust: Feedo and Hazelnut

Wed, 04 Feb 2026 17:00:00 +0100

My family traveled abroad for a month, and suddenly I had something rare: free time. Instead of binge-watching series or scrolling endlessly, I decided to channel that energy into something I’ve been curious about for a while: Rust development.

I’ve been watching Rust from the sidelines for years. The language always intrigued me: its focus on memory safety, the passionate community, the promise of “fearless concurrency.” But between work and family life, I never found the right moment to dive in properly.

Well, the moment arrived.

Why Rust?

As a software developer, I’ve worked with many languages over the years. JavaScript and TypeScript dominate my day job, and I’ve dabbled in Python, Go, and others. But Rust felt different. The learning curve is famously steep, but the payoff (fast, safe, reliable code) seemed worth it.

What really drew me in was the terminal ecosystem. Rust has incredible libraries for building command-line and TUI (Text User Interface) applications. Tools like ratatui make it surprisingly pleasant to create rich terminal interfaces.

Feedo: A TUI RSS Reader

The first project I tackled was Feedo, a terminal-based RSS feed reader.

I’ve always liked RSS. It’s the antidote to algorithm-driven feeds: you choose what you want to read, and that’s what you get. But most RSS readers are either web-based or clunky desktop apps. I wanted something fast, keyboard-driven, and integrated into my terminal workflow.

Feedo lets you:

Add and organize RSS/Atom feeds
Browse articles with vim-like keybindings
Open articles in your browser
Search through your feeds
Choose from multiple themes

Building it taught me a lot about async Rust, HTTP clients, and XML parsing. The ratatui library made the UI work enjoyable, and I’m genuinely happy with how it turned out.

Check it out: feedo.ricardodantas.me | GitHub

Hazelnut: Automated File Organization

The second project, Hazelnut, scratches a different itch. It’s inspired by Hazel, the popular macOS file automation tool.

I’ve always wanted something like Hazel, but cross-platform and terminal-based. Hazelnut watches folders and automatically organizes files based on rules you define. Downloaded a PDF? Move it to Documents. Old screenshots? Archive them. Temporary files older than 30 days? Delete them.

The architecture is split into two parts:

hazelnut - The TUI for managing rules and watches
hazelnutd - The background daemon that does the actual work

Building the daemon was particularly interesting. It uses the notify crate for cross-platform file watching (inotify on Linux, kqueue on macOS) and supports hot-reloading configuration via Unix signals.

Check it out: hazelnut.ricardodantas.me | GitHub

What I Learned

This month of intense Rust development taught me more than I expected:

The compiler is your friend. Yes, it’s strict. Yes, it will reject your code often. But when it compiles, it usually works. The confidence that brings is remarkable.
TUI development is fun. There’s something deeply satisfying about building interfaces that run in the terminal. It feels efficient and focused.
Side projects need deadlines. Having a month with clear free time created natural pressure to ship something. Without that, these projects might have lingered in “someday” territory forever.
Rust is worth the investment. The learning curve is real, but the language’s design makes you think more carefully about your code. That translates to better habits in other languages too.

What’s Next?

Both projects are open source and available on GitHub. I’ve already published them on crates.io and set up Homebrew formulas, so you can install them with a simple brew install ricardodantas/tap/feedo or brew install ricardodantas/tap/hazelnut.

There’s still plenty to improve: better documentation, more features, and refinements based on real-world usage. But for now, I’m happy to have shipped two actual tools that I use daily.

If you’re curious about Rust or TUI development, I encourage you to try building something small. The ecosystem is welcoming, the tooling is excellent, and there’s something special about seeing your creation run in the terminal.

Now I just need to figure out what to build next. 🦀

Leveling up my dotfiles

Fri, 23 Jan 2026 23:54:21 +0100

For months, I have sought better ways to automate reinstalling my work tools when switching to a new laptop. Years ago, I began using dotfiles. Initially, I used some tooling I wasn’t entirely happy with, but given the options at the time, it was what I had. After a few months, I simplified my approach, adopting only Stow and a Bash Script for managing my dotfiles. This made the setup process much faster and easier, significantly reducing overhead. However, I was concerned about the security of my secrets, since they were stored in plain text in the config files. Although my repository was private and I used a password manager via a Bash Script, I didn’t feel comfortable with unencrypted passwords in the configs.

Mise (or “mise-en-place”) is an open-source development environment setup tool designed to make local dev environments easy, consistent, and reproducible across projects and languages.
Fnox is a developer-focused secret management CLI tool that helps you securely manage and use sensitive configuration values (like API keys, database passwords, tokens) across development, CI/CD, and production workflows. It combines encrypted storage in version control with support for remote secret providers into a single workflow.

I don’t like giving other apps permission to integrate with my password manager, and that is non-negotiable. This was one of the main problems in integrating my secrets with my old workflow. With Fnox and Mise, I can pull the secrets from my password manager during the setup script, encrypt them with a disposable key, and that is it. No secrets exposed in the config files.

Maintaining my Bash scripts became much easier thanks to Mise Tasks. It reminded me of Makefiles, but easier to use. Additionally, with support for managing versions of Node.js, Rust, Ruby, and many other packages (since it also functions as a package manager), along with integration for idiomatic version files like .ruby-version, Gemfile, .nvmrc, environment variable management, and CI/CD integration, it fulfilled all my needs.

As a result, my dotfiles are now easier to maintain, more secure, and quicker to install. I might consider making my dotfiles public at some point. Yeah… maybe. 🤔

And, Yes! I rotated all my secrets while refactoring my dotfiles and recreated my repo from scratch. 😎

My first Micro.blog contribution: Instagram plugin

Mon, 14 Jul 2025 21:51:49 +0100

This is my first contribution to the Micro.blog community. I’ve created a simple plugin that lets you embed Instagram posts and reels right into your Micro.blog posts.

To install it, just search for Instagram in the plugins directory.

Code available on Github.