MiguelPimentel.do

The Adopt-a-Drain Dashboard

Miguel Pimentel — Tue, 23 Dec 2025 00:00:00 GMT

Every year, the City of Crystal, Minnesota, pays dues to participate in the Clean Water MN and Adopt-a-Drain programs. Recently, I was asked to justify these expenses to my manager, the City Engineer and Public Works Director. These programs are vital for our community outreach requirements under the MS4 (Municipal Separate Storm Sewer System) permit process, but it can be difficult to quantify their value during a budget review.

The data exists in the form of CSV exports, but raw spreadsheets rarely tell a compelling story. To defend the program, I built a dashboard as a proof of concept (PoC). My goal was to demonstrate how we can turn static rows of volunteer data into a clear narrative of community impact.

The Tooling: Why Streamlit?

When building a PoC, the priority is speed. I chose Python because of its robust data ecosystem, specifically using Streamlit for the interface. Streamlit allowed me to turn a Python script into a functional web app without the overhead of traditional frontend development.

Why use a PoC?

This wasn't meant for production. By choosing Streamlit, I could focus on data logic rather than server management, allowing me to present a working prototype to stakeholders in a matter of days.

Managing the Environment with `uv`

For this project, I used uv by Astral for package management. For the dev community, the draw here is speed and the elimination of "dependency hell."

With uv, I don't have to manually manage a .venv folder. I can run the project with a single command:

uv run streamlit run main.py

uv handles the environment in the background, ensuring that Pandas, Plotly, and Streamlit are all synced. This makes the transition from a local script to a shareable dashboard significantly smoother.

Processing the Data with Pandas

The Adopt-a-Drain data consists of two primary CSV files: adoption records and cleaning logs. Using Pandas, I cleaned and aggregated this data to look for trends. One of the most effective tools for this was the resample method.

@st.cache_data
def get_monthly_cleanings(cleanings_df: pd.DataFrame) -> pd.Series:
    """Group cleaning events by month to see seasonal trends."""
    return cleanings_df.set_index("Cleaning Date").resample("ME").size()

This allowed me to see exactly when our volunteers are most active. Unsurprisingly, activity spikes in the spring and fall, but seeing it on a chart helps us plan our outreach efforts and our MS4 reporting more effectively.

Visualizing Impact

To justify the program's cost, I used Streamlit's metric components to highlight three key numbers: total adoptions, total cleaning events, and the total weight of debris collected.

Seeing that residents have prevented over 2,800 lbs of debris from entering our local waterways was an "aha" moment. While it felt incredible to see that number, I realized it wasn't about the code; it was about the power of a community working together. The dashboard simply made that collective effort visible.

I also included a simple geographic visualization using Plotly's scatter_map. By mapping the coordinates of every cleaning, we can see exactly which neighborhoods are most engaged and which watersheds are being protected.

fig = px.scatter_map(
    cleanings,
    lat="Latitude",
    lon="Longitude",
    hover_name="User Display Name",
    color_discrete_sequence=["fuchsia"],
    zoom=12,
    height=550,
)

Handling Sparse Data

Users often filter by year or watershed. I included defensive checks to ensure that if a filter returned no results, the app would display an st.warning rather than a generic Python error. This keeps the demo professional when presenting to leadership.

Looking Ahead

This dashboard was a practical exercise in turning data into a tool for advocacy. It provided the visual evidence needed to support our continued participation in these clean water programs and simplified our permit reporting.

Because this prototype successfully bridged the gap between raw data and city leadership, I've been exploring more ways to use Python for civic data. This is the first of several projects I'm working on, and I look forward to sharing more as they develop.

You can visit the Adopt-a-Drain Dashboard. The complete source code is available on GitHub. If you're working with civic or environmental data, I hope this provides a useful starting point for your own visualizations.

Adding Snow, Keeping Warm: Using Responsibly

Miguel Pimentel — Wed, 17 Dec 2025 00:00:00 GMT

The Digital Paradox

I just finished deploying a new feature on my website: snow. Digital, gentle, simulated snowfall. This is a strange project, because few things make me feel more physically taxed than the cold reality of winter.

I grew up in the Dominican Republic. I know the feeling of humid, embracing air, where my lungs never hurt. But I've lived in Minnesota for over ten years, and every winter, the sharp, dry air and intense cold bring a familiar sadness. It keeps me indoors and weighs me down.

Knowing all that, why would I use code to invite this season onto my website?

The answer is simple: Code is a powerful tool for building your own reality. The act of coding this snow is a digital coping mechanism—a way to engage with the beauty of the season on terms I create and fully control.

I can't change the climate outside, but in my digital space, I can ensure the snow is serene, non-intrusive, and most important of all, predictable.

The best part? This digital flurry allows me to finally appreciate the stunning aesthetic of a snowfall—the quiet, the movement—without having to zip up three layers of clothes. Since snow wasn't part of my upbringing, the novelty is still exciting. This is me, designing my own winter experience.

Note

I chose @zachleat/snow-fall because my site is built on Eleventy, and I highly respect and trust Zach Leatherman's work. Read their blog post.

Respectful Flurry: Accessibility and `<is-land>`

The snow might be serene, but the implementation had to be rigorous. If my code is meant to bring me comfort, I must ensure it causes no discomfort for my visitors.

Accessibility is always a priority for me, and this project gave me a great excuse to try out some modern deferral techniques.

The snow must be optional and respectful! The snow is not worth slowing the site down.

I had two main points to tackle: performance and accessibility. Luckily, the awesome <is-land> plugin for Eleventy allows you to smartly defer and initialize client-side components.

I chose to follow Zach's excellent accessibility recommendation, tying the entire component to the user's motion preference:

<is-land on:media="(prefers-reduced-motion: no-preference)">
    <snow-fall></snow-fall>
</is-land>

This ensures that if you struggle with motion on screens, the digital flurry never appears. This code isn't just technical compliance; it's an act of empathy. I know what it feels like to be overwhelmed by the environment, and I'd like to respect your choice to control your digital space as well.

My Winter, Coded on My Own Terms

The cold reality of winter still pushes me indoors. But the digital snow allows me to engage with the season's aesthetic joy from the warmth of my computer.

This is a small, satisfying project that warms me internally. It's a way to acknowledge and transform the season's challenge through code. This is my winter, coded on my own terms.

Solving Blinking View Transitions (Featured on Piccalilli)

Miguel Pimentel — Thu, 11 Dec 2025 00:00:00 GMT

I am humbled to share that my first article is now live on Piccalilli.

I’ve been a long-time reader of Andy Bell's work, so contributing to the platform is a genuine milestone for me. In this article, I tackle a specific, frustrating issue I ran into while working with the View Transitions API.

Read the full article

If you are experimenting with view transitions and seeing unexpected flashes or stutters, I wrote this breakdown to help you smooth them out.

Read "Why are my view transitions blinking?" on Piccalilli →

When Gratitude Rings

Miguel Pimentel — Tue, 09 Dec 2025 00:00:00 GMT

I took time off work that morning to be home for a house inspection. Not the fun kind of time off where you do something you've been looking forward to, but the necessary kind where you're managing adult responsibilities that only happen during work hours.

The inspection revealed problems I wasn't expecting. Nothing catastrophic, but enough new issues to shift my mental budget calculations—like the bedroom window needing new hardware, or potentially an entire unit replacement. By the time I got to work, I was in that particular flavor of bad mood where everything feels slightly harder than it should be.

Then my phone rang. A resident had called City Hall asking specifically to speak with me. They left only a callback number.

My brain immediately went to complaint mode. Of course someone was calling with another problem. That's how these days go, right? One thing goes wrong and suddenly everything piles on. I picked up the phone to call back, bracing for whatever issue was about to land on my desk.

"I just wanted to call and thank you."

That was not what I expected.

The Small Gesture That Landed

The resident explained that they'd reported an issue a few weeks ago—specifically about recurring backyard flooding involving a utility easement. They'd been worried it would just disappear into the void of municipal bureaucracy. But I'd responded, explained what we were doing about it, and kept them updated on the timeline.

They called specifically to tell me they felt better knowing someone was actually working on their problem. They weren't calling because it was fixed. They weren't even calling because significant progress had been made. They called because they felt heard.

That phone call completely shifted my day. Not because it solved any of my morning's problems, but because it reminded me to be grateful for work that actually connects with people. It's easy to forget that when you're stuck in administrative tasks and project management. But moments like this pull you back to why municipal work matters in the first place.

It was a powerful reminder that connection doesn't require a formal title or a paycheck. That gratitude can show up in the places you least expect it. But what happens when you actually seek out those positive interactions? Do they feel less valuable simply because you were already anticipating them?

Anticipating Connection, Still Finding Surprise

A few weeks ago, I was volunteering as a driver for Meals-on-Wheels, doing my usual route. I always look forward to these deliveries because the people are genuinely the kindest you'll meet. I knew the interactions would be positive.

I handed over the meal to one of my regulars and was starting to turn away when they stopped me:

"What's your name?"

That was it. They just wanted to know about me. Such a simple question, but I wasn't expecting it at all. Even when you're anticipating a good interaction, there are these small moments that catch you off guard. They didn't just want their meal. They wanted to know who I was.

I'm grateful for moments like that. They remind me that volunteering isn't just about delivering meals or checking boxes. It's about the brief connections you make with people who genuinely see you as more than just the person at the door.

It's funny how that works. Sometimes you brace yourself for the worst and get surprised by kindness. Other times you're already expecting good and still get blown away by the smallest gestures. Both deserve equal appreciation.

Recognizing What Actually Counts

We tend to only count the big wins. The completed projects. The major milestones. The things that make good headlines or look impressive on a resume.

But I'm learning to be more grateful for the other stuff. The phone call that makes someone's day better. The simple act of asking someone's name because you genuinely want to know. Following through on something small when it would've been easy to let it slide.

These moments don't show up in project completion reports. They don't get quantified anywhere. But they're often what people remember and what actually makes the work meaningful.

The resident who called took time out of their day to express gratitude for something I'd honestly forgotten about. The person receiving their meal delivery didn't just accept their food and close the door. They paused to make a human connection.

I'm grateful they did. Those small acknowledgments matter more than formal recognition ever could.

VS Code Regex: Conditional Find and Replace

Miguel Pimentel — Sun, 07 Dec 2025 00:00:00 GMT

I recently hit a wall optimizing an older Shopify theme. To fix our CLS score, I needed to inject width and height attributes into thousands of specific image tags. The catch? I had to target only the legacy placeholder images that hadn't been fixed yet, ignoring everything else.

I needed a surgical solution. I needed VS Code Regex. But like most developers, I only really "know" Regex for about 48 hours after I use it. The rest of the time, I have to re-learn it from scratch.

If you are currently in that "re-learning" phase and just want the code, I respect your time. Here's the TL;DR:

TL;DR:

Find all <img tags containing the specific Liquid placeholder string (ignoring messy whitespace), but exclude those that already have width="1024" height="1024".

Enable Regex Mode (.* icon) in VS Code Search (Ctrl+Shift+F).
Find Pattern:

(<img(?![^>]*width="1024" height="1024"))([^>]*?\|\s*image_url:\s*width:\s*1024,\s*height:\s*1024\s*\}\}[^"]*")([^>]*?)(\/?>)

Replace Pattern:

$1$2 width="1024" height="1024"$3$4

The Prerequisites

To pull this off without corrupting your HTML, we rely on two fundamental regex concepts.

1. Capture Groups and Backreferences

We use parentheses () to capture specific parts of the image tag. In our replacement, we use $1, $2, etc., to paste those pieces back exactly where they were. This ensures we don't accidentally delete your alt text or classes while injecting the new attributes.

2. Non-Greedy Matching

Standard regex is "greedy." If you search for src=".*", it matches everything from the first quote to the last quote on the line. Adding a question mark (.*?) makes it "non-greedy," forcing it to stop at the first closing quote. This is vital when parsing HTML.

Solving the Exclusion Puzzle

The hardest part isn't finding the image tags. It's excluding the ones you've already fixed. We need to tell VS Code: "Find this image tag, but stop immediately if you see width="1024" height="1024" anywhere inside it."

This requires a Negative Lookahead (?!…). This logic acts as a bouncer. It stands at the door of your search match, peeks inside, and if it sees the forbidden string, it excludes the whole match.

Breaking Down The Pattern

Here is how the regex works, broken down by its Capture Groups.

(<img(?![^>]*width="1024" height="1024"))([^>]*?\|\s*image_url:\s*width:\s*1024,\s*height:\s*1024\s*\}\}[^"]*")([^>]*?)(\/?>)

Why \s* instead of spaces?

You'll notice the pattern uses \s* extensively. This token matches "zero or more whitespace characters" (including spaces, tabs, and newlines).

Since legacy code often has inconsistent formatting—sometimes tight, sometimes loose—using \s* ensures we catch the tag regardless of how the previous developer hit the spacebar. Ask me how I know…

Group	Pattern Segment	What it does
`$1`	`(<img(?![…]))`	The Bouncer: Captures `<img` and checks the exclusion rule. It scans until the closing bracket `>` (`[^>]*`) to ensure the attributes aren't already there.
`$2`	`([^>]?\|\simage_url…[^"]*")`	The Anchor: This looks for the Liquid placeholder. It captures the entire `src` attribute, including any trailing characters (like query strings) via `[^"]*`, so we can safely append after it.
`$3`	`([^>]*?)`	The Remainder: Captures any other attributes (like `alt` or `class`) that might appear later in the tag.
`$4`	`(\/?>)`	The Closer: Captures the closing `>` (or self-closing `/>`) so we can close the tag properly.

The Result

We reconstruct the tag using the captured groups, injecting the new attributes exactly between the anchor ($2) and the remainder ($3).

Replace Pattern:

$1$2 width="1024" height="1024"$3$4

Scenario	Input Tag Example	Outcome/Description
Needs Fixing	`<img src="file.jpg \| image_url: … }}" alt="x">`	MATCH: New attributes inserted properly.
Messy Spaces	`<img src="f.jpg \|image_url:width:1024…}}?v=1">`	MATCH: The pattern handles inconsistent spacing and query parameters (\s* and [^"]*).
Already Fixed	`<img width="1024" height="1024" src="file.jpg \| ...">`	IGNORED: The negative lookahead prevents the match.

Safety First

Regex is powerful, but it's also excellent at destroying codebases in milliseconds.

Before you hit "Replace All," commit your changes to Git. If you make a mistake with your pattern, a simple git checkout . is instant. If you don't have version control, you are stuck pressing Ctrl+Z on 50 different files.

Review Before You Commit

Regex is precise but blind. It doesn't understand context.

Don't just trust the "Replace All" button. Open your Source Control tab in VS Code and review the file diffs line-by-line. It is much easier to catch a stray matching character or a broken tag now than it is to revert a broken commit later.

Verify your matches, ensure your git status is clean, and then let the regex do the heavy lifting.

When Being Wrong Goes Right

Miguel Pimentel — Mon, 15 Sep 2025 00:00:00 GMT

A few weeks ago, I got the kind of news that should've made me feel great but instead left me with a familiar knot in my stomach. The bids for our 2025 Sewer Rehabilitation Project had come in, and my estimates were high. Way high.

I'd estimated $65 per linear foot for the sewer liner work. The winning contractor came in at $42.90. The second-place bid was $51.31. In the project management world, being off by that much feels like failure, even when it's not.

But here's the thing that took me a while to process: being "wrong" in this case created something amazing. Because my estimates were conservative, we suddenly had enough budget to add 1,395 additional feet of sewer rehabilitation work. The same project budget that I thought would cover 1,855 feet could now handle 3,250 feet. The city got significantly more infrastructure improvement for the same money.

So why did I feel like I'd messed up instead of celebrating a win?

The Project Details

Let me back up and explain what actually happened, because the numbers tell a story that's bigger than just one municipal project.

The City of Crystal needed to rehabilitate aging sewer lines – the kind of invisible infrastructure work that keeps cities functioning but never makes headlines. We were planning to install 1,855 linear feet of 8-inch sewer liner to fix deteriorating vitrified clay pipes that were decades old.

This was also Crystal's first major sewer rehabilitation project in years, which meant I needed to create the framework from scratch. I spent weeks consulting the City Engineers Association of Minnesota guidelines and working with colleagues from Le Sueur and Champlin to write new Standard Detail Specifications for Sewer Rehabilitation Procedures. It was important to get this right – not just for this project, but to establish standards for future work.

As the project manager, I had to estimate costs for budgeting and to set a baseline for evaluating contractor bids. I researched similar projects, talked to other municipalities, and landed on $65 per linear foot. It felt reasonable – maybe even slightly conservative, but I wanted to make sure we had adequate budget.

The project also included adding 550 feet of storm sewer liner work after we discovered a sinkhole near the original scope. This last-minute addition created some time pressure as we rushed to incorporate the additional work before the bid opening, but it didn't affect my core sewer rehabilitation estimates.

When the bids opened, reality hit differently. The winning contractor bid $42.90 per linear foot. The runner-up was $51.31. Both were significantly lower than my estimate, and both were qualified, reputable contractors.

The result? Instead of feeling constrained by budget, we could suddenly afford to add another 1,395 feet of sewer rehabilitation work that the city desperately needed. What started as one project became a much more comprehensive infrastructure improvement.

The Pressure to Be Perfect

Here's what I couldn't shake, though: the voice in my head that kept saying I should've known better. That a good project manager would've hit closer to the actual market price. That being off by 30-50% meant I wasn't doing my job well enough.

This kind of thinking isn't unique to municipal engineering. There's this culture in project management – maybe in professional life generally – that treats precision as the ultimate goal. You're supposed to nail your estimates, predict outcomes accurately, and demonstrate that you truly understand your field through exact forecasting.

For someone with rejection sensitive dysphoria, this pressure hits differently. RSD is this intense fear of being criticized or perceived as incompetent, and it's common with ADHD. It's not just feeling bad about mistakes – it's the overwhelming certainty that any error proves you don't belong in your role. When my estimates came in high, RSD whispered that everyone would think I didn't know what I was doing.

The irony is almost funny: my "mistake" delivered objectively better outcomes for the city. More infrastructure repair, better use of taxpayer money, and the flexibility to address additional needs that emerged during the project. But my brain was stuck on the fact that I'd been "wrong" about the market pricing.

Redefining Success

What if I've been thinking about this all wrong, though? What if conservative estimates aren't character flaws but strategic wisdom?

The truth is, I wasn't trying to predict the exact market price down to the penny. I was trying to ensure the city had adequate budget to complete necessary infrastructure work. Mission accomplished, in a bigger way than originally planned.

There's a difference between being precise and being prepared. Precision aims to hit exact targets. Preparation builds in buffers for the unknown variables that always show up in real projects. Maybe my ADHD brain, which tends to think about worst-case scenarios and plan for multiple contingencies, actually serves me well in this context.

This applies way beyond municipal engineering, too. How often do we beat ourselves up for overestimating how long a project will take, how much money we'll need, or how challenging something will be? We treat these "errors" as personal failings instead of recognizing them as useful caution.

When I plan extra time for a task and finish early, that's not poor time management – that's creating space for unexpected complications or higher-quality work. When I budget more money than I end up spending, that's not wasteful planning – that's building financial flexibility for opportunities or emergencies.

The fear of being wrong can actually prevent us from being usefully wrong. If I'd tried to estimate exactly what contractors would bid, I might've aimed for $45 per linear foot and left no room for additional work when the opportunity arose. The "mistake" of overestimating created possibilities that precision would've eliminated.

Sometimes the best thing you can be is strategically, beneficially wrong. Sometimes building in buffers serves everyone better than trying to hit bullseyes. And sometimes the thing that makes you feel like you failed is actually the thing that made everything work.

My Actual Problem-Solving Rituals

Miguel Pimentel — Tue, 09 Sep 2025 00:00:00 GMT

Picture this: I'm staring at a stubborn piece of code that won't work, my browser has twelve tabs open, and I'm genuinely stuck. What do I do? I put on my noise-canceling headphones and blast "Psychosocial" by Slipknot.

Most productivity advice would tell you that's exactly wrong. Aggressive metal music while trying to solve complex problems? That sounds like a recipe for distraction, not focus. But here's the thing I've learned about my brain since my ADHD diagnosis: what works for me doesn't always match what's supposed to work.

I've spent years figuring out my actual problem-solving rituals, the weird collection of habits that genuinely help me think through challenges. Some of them make sense, others probably look strange from the outside. All of them work better than the generic productivity advice I used to force myself to follow.

Fidgeting as Focus

When I'm stuck on something, my body knows before my brain does. I start unconsciously cracking my fingers, petting my beard, or playing with my hair. For the longest time, I thought these were bad habits I should stop. Turns out, they're part of how I think.

There's something about that physical fidgeting that helps my brain work through problems. It's not nervous energy, it's thinking energy! When I try to sit perfectly still and focus, I actually get more distracted. But when I let myself fidget, my mind settles into a better thinking rhythm.

The real breakthrough came when I noticed that productive procrastination actually works for me. When I'm stuck on a work problem, sometimes the best thing I can do is fold laundry or clean the house. There's something about the repetitive, simple, physical tasks that lets my subconscious work on the real problem. I'll be organizing a closet and suddenly the solution to a Python function I've been wrestling with just appears in my head.

Environment Tweaks

I have a headphone hierarchy for different types of thinking. Regular earphones are for when I need a soft disconnect. I remain aware of my surroundings but creating a small bubble of focus. Noise-canceling headphones are for when I need to disappear into deeper work.

And then there's the music choice that surprises most people. When I need to concentrate or solve problems, I reach for Slipknot, System of a Down, All That Remains, Muse, Thirty Seconds to Mars. The more "aggressive" music actually helps me focus. I think it's because the intensity matches the mental effort I'm putting in. Calm, ambient music makes my brain wander. But what others would consider "too much" seems to keep me locked in.

I know it sounds counterintuitive. Friends have asked how I can think clearly with heavy music playing. But my ADHD brain craves stimulation, and the aggressive music provides just enough background intensity to keep me engaged without being distracting.

When Problems Get Too Big

Sometimes a problem feels bigger than what I can hold in my head all at once. That's when I switch from trying to think my way through it to getting it out of my brain entirely.

If I have too much swirling around mentally, I do a brain dump straight into Obsidian. No organization, no structure – just everything that's bouncing around in my head gets typed out in my daily journal. Once external, I can see patterns and priorities that were invisible when everything was just competing for mental space.

For complex technical problems or big decisions, I still reach for pen and paper. There's something about the physical act of writing that slows down my thinking in a good way. Digital tools are great for capturing and organizing, but when I really need to work through something step by step, handwriting forces me to be more deliberate.

When I'm procrastinating or jumping between tasks without making progress, I use pomodoro timers to create structure. I actually built PomoBar as an Obsidian plugin because I needed a timer that stayed out of my way but was available when natural flow breaks down. Pen and paper is my backup plan when everything else stops working.

What Doesn't Work

Here's what I've learned about my ADHD brain and traditional productivity advice: most of it assumes a neurotypical brain that operates on predictable schedules and consistent motivation levels.

My motivation fluctuates throughout the day in ways I can't predict or control. Some mornings I wake up with laser focus and can tackle complex problems for hours. Other days, I struggle to concentrate on simple tasks until later in the day. The emotional rollercoaster is real! Rigid scheduling that doesn't account for these natural fluctuations just sets me up for failure and frustration.

Time blocking is something I'm experimenting with, but it only works when I build in flexibility. I can't schedule "deep work" from 9-11 AM and expect my brain to cooperate just because it's on the calendar. Instead, I try to match my planned tasks to whatever mental energy I actually have in the moment. Sometimes that means the task scheduled for the afternoon gets done in the morning, or vice versa.

Final Thoughts

The biggest lesson I've learned about problem-solving so far, is that the rituals that work for your specific brain matter more than following someone else's system. My combo can look chaotic from the outside, but it consistently helps me work through challenges better than any productivity methodology I've tried to force myself into.

Your problem-solving rituals might be completely different. Maybe you need silence and stillness. Maybe you think best while cooking or in the shower. Maybe you need collaborative conversation or complete isolation. The point isn't to copy what works for someone else, it's to pay attention to what actually works for you, even if it sounds weird to other people.

PomoBar for Obsidian

Miguel Pimentel — Sun, 17 Aug 2025 00:00:00 GMT

After my ADHD diagnosis, the Pomodoro Technique became essential for managing my focus. As someone who spends most of my day in Obsidian, I wanted a timer that lived seamlessly within my note-taking environment without cluttering my workspace.

That's how PomoBar was born: a minimalist Pomodoro timer that sits quietly in Obsidian's status bar, ready when I need it but invisible when I don't.

PomoBar was one of those projects I built during my year of silence, focused on solving a real problem I faced daily, but never taking the time to document the process. Looking back, that was a mistake. The development journey taught me lessons about constraints, user experience, and the value of building tools you actually use.

From HTML Prototype to Production Plugin

Before diving into Obsidian plugin development, I built a standalone HTML version in CodePen to test the concept. Working with familiar HTML, CSS, and JavaScript let me focus on the user experience without learning new APIs. The prototype had a full visual interface with buttons and progress rings – essentially a traditional web app.

But when I moved to create the Obsidian plugin, everything changed. This was my first plugin and my first real TypeScript project. I was suddenly wrestling with type definitions, Obsidian's API patterns, and figuring out how to cram a full timer interface into a tiny status bar element.

The Problem with Existing Solutions

Before building PomoBar, I tried several Pomodoro apps and browser extensions. They all shared similar problems:

Context switching: Alt+tabbing to external apps broke my concentration when I was finally focused
Visual clutter: Most timers demanded screen real estate I couldn't spare
Over-engineering: Complex features I never used made simple tasks unnecessarily complicated

I needed something that followed the Unix philosophy: do one thing and do it well. A timer that would stay out of my way but be instantly accessible when needed.

Architecture Decisions: Building for Maintainability

What started as a single-file experiment evolved into a properly structured project. I learned the hard way that even simple plugins benefit from clean architecture.

The current structure separates concerns clearly:

main.ts: Plugin lifecycle and Obsidian integration
timer.ts: All timer logic and state management
SettingsTab.ts: Configuration interface
types.ts: TypeScript interfaces and type definitions
constants.ts: Application constants and enums

This modular approach made the codebase easier to test, debug, and extend. When I needed to add features like optional status bar icons or improved memory management, I could modify individual components without touching the core timer logic.

Design Philosophy: Flexible Minimalism

The core design principle for PomoBar remained radical simplicity, but with thoughtful flexibility:

A soft timer display in the status bar showing MM:SS
Optional icon that changes based on timer state
Left click to start/pause
Middle click to cycle between work, short break, and long break
Right click to reset (when paused)

The interface stays minimal, but users can customize duration settings and choose whether to show the timer icon. Smart defaults (25/5/15 minutes) work for most people, but the plugin adapts to different workflows.

Technical Deep Dives

Building something simple sounds easy until you actually try it. What seemed like "just put a timer in the status bar" quickly revealed layers of complexity I hadn't anticipated.

State Management and Memory Safety

The timer tracks multiple pieces of state: current mode, remaining time, work interval count, and running status. Getting this right required careful attention to cleanup:

cleanup() {
    // Clean up any remaining intervals
    this.registeredIntervals.forEach(intervalId => {
        window.clearInterval(intervalId);
    });
    this.registeredIntervals.clear();
}

JavaScript's setInterval can create memory leaks if not handled correctly, especially in a plugin environment where code gets reloaded frequently during development. Obsidian's registerInterval method helps, but proper manual cleanup ensures reliability.

User Feedback Integration

Early feedback taught me important lessons about user expectations. A GitHub issue pointed out that users wanted the plugin to automatically cycle through the traditional Pomodoro sequence: work → short break → work → short break → work → long break. The user noted they were using "25/5 cycles with the occasional 15 extended break" and wanted the timer to default to 5-minute breaks instead of requiring manual selection each time.

This feedback was really helpful. It highlighted a core workflow need I hadn't fully considered. Instead of adding buttons or dropdowns, I implemented automatic cycling while keeping the same three-click interaction model.

TypeScript in Practice

Moving from vanilla JavaScript to TypeScript added complexity I hadn't expected, but the benefits became clear quickly:

interface PomodoroSettings {
  workTime: number;
  shortBreakTime: number;
  longBreakTime: number;
  intervalsBeforeLongBreak: number;
  showIcon: boolean;
}

TypeScript caught several bugs during development that would have been runtime errors in JavaScript. The type safety made refactoring safer and the code more self-documenting.

Modern Development Practices

Building PomoBar taught me the value of proper development tooling, even for small projects.

Build System and Tooling

I experimented with different build systems before settling on esbuild. While I briefly tried Vite for its development features, esbuild proved more stable and performant for an Obsidian plugin. The build process handles TypeScript compilation, bundling, and development hot-reloading.

ESLint and proper TypeScript configuration catch issues before they reach users. The development experience improved dramatically once I had reliable linting and type checking in place.

Testing and Validation

I added a Jest test suite to verify timer logic, settings validation, and plugin lifecycle management. Testing Obsidian plugins requires mocking the API, but the effort pays off in confidence and easier refactoring.

The settings validation alone prevented several user-facing bugs:

private validateAndUpdateSetting(
    value: string,
    settingProperty: 'workTime' | 'shortBreakTime' | 'longBreakTime',
    resetAction: 'resetTimer' | 'resetPomodoroSession'
): boolean {
    const numValue = parseInt(value.trim());
    if (!isNaN(numValue) && numValue > 0 && Number.isInteger(Number(value.trim()))) {
        this.plugin.settings[settingProperty] = numValue;
        return true;
    }
    return false;
}

Documentation as Development Practice

One lesson from my year of building in silence: document as you build, not after. PomoBar now includes:

README: Clear installation and usage instructions
CHANGELOG: Detailed release notes for every version
CONTRIBUTING: Short guide on how to contribute to the project
Documentation site: Built with MkDocs for comprehensive user guides

Writing documentation forces you to think clearly about user experience and API design. It also makes the project more welcoming to contributors and users.

Current State and Lessons Learned

PomoBar today is a robust, well-tested plugin that hundreds of users use daily. What started as a simple timer evolved into a thoughtful tool that balances simplicity with reliability.

The biggest lessons weren't about TypeScript syntax or Obsidian APIs. They were about building software people actually use:

Start with real problems: Build something you need, not something that sounds interesting
User feedback shapes everything: GitHub issues taught me more about user needs than any amount of planning
Simple interfaces can hide complex implementations: The three-click interaction model required careful state management underneath
Architecture matters even for small projects: Clean separation of concerns makes everything easier

Building Your Own Plugin

If you're interested in building Obsidian plugins, here's what I wish I'd known starting out:

Start with a real need: Build something you'll actually use daily
Learn TypeScript properly: Don't just get by with @ts-ignore comments
Set up proper tooling early: ESLint, testing, and build processes pay off quickly
Document as you build: Future you will thank present you
Listen to user feedback: GitHub issues contain valuable insights about real workflows

The complete source code for PomoBar is available on GitHub, along with comprehensive documentation. If you decide to build your own plugin, I'd love to hear what problems you're solving. Sometimes the best ideas come from scratching your own itch.

Final Thoughts

Building PomoBar taught me that effective tools don't need complex interfaces. Sometimes the software you forget you're using is exactly what you need.

This project also taught me something about the value of writing alongside building. I shipped PomoBar months ago, but only now am I capturing the lessons learned and design decisions made. The technical details are still fresh, but some of the emotional journey – the frustration with existing tools, the satisfaction of solving my own problem – has already faded.

Writing about projects after the fact is harder than writing during development, but it's still valuable. The technical lessons remain clear even if some of the emotional journey has faded. This is my reminder to document the process, not just the results.

Building in Silence

Miguel Pimentel — Thu, 31 Jul 2025 00:00:00 GMT

Acknowledging the Gap

I haven't published a blog post in almost a year. Not because I stopped learning or stopped building – quite the opposite, actually. I've been deep in project mode, head down, solving problems and shipping code. Somewhere along the way, I forgot that building without writing is like learning without teaching. You miss half the value.

The last year has been about creating rather than documenting. While that focus led to some projects I'm genuinely proud of, it also created documentation debt that I'm only now realizing I need to pay back.

What I've Been Building

PomoBar came first. After an ADHD diagnosis, I needed better focus tools. The Pomodoro Technique worked, existing timers felt clunky and broke my concentration. So I built a minimalist timer that lives in Obsidian's status bar – my first real TypeScript project and first published Obsidian plugin.

The Adopt-a-Drain and Traffic Studies Dashboards came from a bigger change – switching jobs in August 2024. After four years as an Assistant Contract Administrator at Metro Transit, I moved to the City of Crystal as an Engineering Project Manager. Better work-life balance, shorter commute, and the chance to work directly with residents rather than just high-level stakeholders.

The new role gave me something I hadn't expected: flexibility to propose solutions. When I saw CSV files full of volunteer cleaning data and traffic study spreadsheets that nobody had time to analyze, I built demos on my own time. Python, Streamlit, and Plotly turned those proof-of-concepts into approved work projects. Suddenly I was the person responsible for all traffic studies reporting in the city, armed with dashboards that actually made the data useful.

It's been validating – proving to myself that I can be an effective Project Manager without the college degree I never finished. The technical skills I'd been developing as a hobby became genuinely valuable tools for municipal work.

Meanwhile, my Digital Garden evolved. I've been rethinking my approach to personal knowledge management – not just what tools I use, how I structure and connect ideas. Less collecting, more connecting.

Lessons From the Silence

When you're deep in creation mode, writing about projects feels like a distraction from making progress. That's exactly backward. Writing forces you to clarify your thinking, identify what you actually learned, and solidify those lessons before moving to the next shiny problem.

I fell into perfectionist thinking without realizing it. Every project felt like it needed a comprehensive technical deep dive, complete with code samples and detailed tutorials. So I wrote nothing instead of writing something.

Projects without accompanying writing lose their teaching value – both for others and for future me. I can barely remember why I made certain architectural decisions in PomoBar, and it's only been a few months.

Starting a new role while deep in project mode created intense learning – new systems, new responsibilities, new technical challenges. The mental energy required to establish myself professionally while pursuing Python projects was helpful overall, more taxing than expected. The building focus became both an escape and a way to prove my capabilities in a new environment.

The biggest lesson: shorter posts are perfectly fine. Not everything needs to be a 3,000-word technical tutorial. Sometimes a brief reflection or a quick tip is exactly what's needed.

Getting Back to Writing

This post is intentionally shorter than what I had in mind. It's my reminder that consistency beats perfection every time. I'd rather publish brief, useful thoughts regularly than comprehensive pieces never.

Explaining a project to others forces you to understand it differently. Teaching clarifies your own thinking. The act of putting ideas into words reveals gaps in your logic and surfaces your actual insights.

Building in public isn't just about the code – it's about the process, the decisions, the dead ends, and the small wins. Those stories often matter more than the final implementation details.

Moving Forward

The restless curiosity that drove me to start blogging in the first place is still there. Still generating ideas, still jumping between interests, still needing an outlet for scattered thoughts. The transition from regional transit projects to municipal data work hasn't slowed this down – working directly with residents and being involved with generational projects like the Blue Line Extension has given me even more to process.

The goal isn't to write about every project or document every learning experience. It's to maintain the habit of reflection, of turning experience into insight, of sharing the process rather than just the results.

Sometimes that means short posts. Sometimes longer technical dives. Either way, it means showing up and putting words on the page.

I'm back to writing. Not because I have everything figured out – writing is how I figure things out.

10 Fun Facts About the Dominican Republic

Miguel Pimentel — Thu, 12 Sep 2024 00:00:00 GMT

After eight years away from the Dominican Republic, I returned in winter 2023. Walking through familiar streets in my hometown of Bonao, sitting in Santo Domingo's colonial plazas, and hearing the sounds I'd grown up with felt like rediscovering a country I thought I knew completely. That visit reminded me how much of my homeland's story remains untold to the outside world.

These facts come from a country I lived in for most of my life, experienced firsthand, and want to share with those who've never been there.

1. Cigua Palmera: Our National Bird

Growing up in Bonao, my friends and I would spot Cigua Palmeras in our school courtyard. These small, chattering birds build massive communal nests that look like apartment complexes wedged into palm trees. The scientific name is Dulus dominicus, and they exist nowhere else on Earth except on the island of Hispaniola.

Cigua Palmeras (known in English as Palmchats) are intensely social, building nests that can house dozens of families. Their nests can weigh hundreds of pounds and last for years, passed down through bird generations like family homes. When hurricanes come through, these communal structures often survive better than individual nests.

2. Larimar: Found Only Here

Larimar exists only in the Dominican Republic, specifically in the southwestern province of Barahona. This blue variety of pectolite ranges from pale sky blue to deep ocean blue, and Dominicans discovered it in 1974. The name combines "Lari" (from the discoverer's daughter Larissa) and "mar" (sea in Spanish).

The stone forms in volcanic cavities and requires hand-mining from mountainous terrain. Dominican miners rappel into cave systems to extract the mineral. The blue coloration comes from copper substitution, and no two pieces are identical. In jewelry shops across the country, you'll find Larimar set in gold, worn by locals and sold to visitors.

3. Taíno Petroglyphs in Cave Systems

I first entered the Cueva de las Maravillas (Cave of Wonders) on a school trip as a kid. Walking into that cave system for the first time meant seeing stalactites and stalagmites, but more importantly, seeing the drawings left by the Taíno people who lived on our island centuries before Columbus.

The Taíno petroglyphs and pictographs show faces, ceremonial scenes, and symbols that archaeologists believe represent their spiritual beliefs and daily life. The cave stays cool year-round, protected from hurricanes and time.

4. Hispaniolan Solenodon: An Ancient Mammal

The Hispaniolan solenodon (Solenodon paradoxus) looks like something from another era because it has remained virtually unchanged for millions of years. This nocturnal mammal is one of the few venomous mammals on Earth. Its saliva contains toxins that help it hunt insects and small prey.

Most Dominicans never see solenodons because they're nocturnal and increasingly rare due to habitat loss and predation by introduced species like cats and dogs. They survive in the mountain forests of the Dominican Republic and Haiti.

5. First European Settlement: La Isabela

The Dominican Republic hosted the first permanent European settlement in the Americas. La Isabela, established by Christopher Columbus in 1493, predates Jamestown by over a century.

When Columbus established La Isabela on the northern coast, the Taíno people already had sophisticated societies, agriculture, and trade networks. La Isabela failed as a settlement due to disease, poor planning, and conflicts with indigenous populations, leading to its abandonment. Its establishment marked the beginning of Spanish colonization in the Americas.

6. Santo Domingo: Oldest Continuously Inhabited European City

Santo Domingo, founded in 1498, is the oldest continuously inhabited European-established city in the Americas. Walking through its colonial zone, you're moving through 500+ years of continuous history.

The city contains the first cathedral, first hospital, first university, and first palace built by Europeans in the New World. The Cathedral of Santo Domingo, completed in 1540, is where many Dominicans mark important life events. Santo Domingo was a major Spanish colonial capital, governing territories that extended far beyond the island.

7. Pico Duarte: The Caribbean's Highest Peak

At 3,098 meters (10,164 feet), Pico Duarte is the tallest mountain in the Caribbean. The climb takes you through multiple climate zones, from tropical lowlands to pine forests to alpine conditions at the summit. During December and January, temperatures at the peak can drop below freezing.

The peak is named after Juan Pablo Duarte, one of the founding fathers of Dominican independence. The Dominican Republic contains mountains, valleys, deserts, and forests alongside its coastline.

8. Lake Enriquillo: Below Sea Level

Lake Enriquillo sits 44 meters (144 feet) below sea level, making it the lowest point in the Caribbean. This hypersaline lake, three times saltier than the ocean, supports a unique ecosystem.

American crocodiles live in Lake Enriquillo. Flamingos feed in its salty waters. The lake expands and contracts based on rainfall, sometimes growing large enough to threaten nearby communities, sometimes shrinking to expose vast salt flats. Within a few hours' drive, you can go from the Caribbean's highest peak to its lowest point.

9. Carnaval: February Celebrations

Dominican Carnaval happens every February, climaxing on Independence Day (February 27th). Growing up in Bonao, Carnaval came to our doorstep. The parade route ran right in front of my grandparents' house, so we'd sit on the sidewalk and watch the entire spectacle unfold.

The masks are the centerpiece. Diablos Cojuelos (limping devils) are the most iconic characters, with elaborate horned masks and colorful costumes. Each region has distinct characters: Roba la Gallina (steals the chicken), La Ciguapa (a mythical woman from Dominican folklore), and Los Taínos (representing our indigenous heritage).

The Diablos Cojuelos carry vejigas (inflated bladders) to playfully hit spectators. Dominican Carnaval blends African, Spanish, and Taíno influences. For Dominican families, Carnaval is cultural transmission. Children learn about Dominican mythology and history through these characters.

10. Humpback Whales in Samaná Bay

Every year from January to March, humpback whales migrate to Samaná Bay's warm, shallow waters to mate and give birth. This migration is one of the longest animal journeys on Earth. These whales travel from feeding grounds near Greenland and Iceland to breed in Dominican waters.

Samaná Bay provides warm, shallow, and protected conditions for whale calves to be born and gain strength before the journey north. The whale watching industry in Samaná employs hundreds of Dominicans. Local boat operators, many of whom grew up fishing these same waters, now guide visitors to observe whales.

Coming Home

Returning to the Dominican Republic after eight years away, I found much infrastructure development alongside things that remained unchanged: the sound of nature in the morning, the taste of mangoes from trees I remembered as a child, family gatherings that stretch late into the night, and lots of dancing.

The Dominican Republic contains Caribbean beaches and mountain peaks, ancient Taíno caves and colonial cathedrals, endemic birds and migrating whales. For those who've never been there, these facts offer a glimpse into a country beyond any single image. For those of us who call it home, they're reminders of why part of us always remains Dominican.

Publish a Logseq Graph to GitHub Pages

Miguel Pimentel — Mon, 22 Jul 2024 00:00:00 GMT

Logseq is a powerful open-source knowledge management tool that emphasizes bidirectional linking and block-level editing. Sharing your graph publicly can be a great way to showcase your knowledge or collaborate with others.

What You'll Build/Achieve

You'll publish your Logseq graph as a live website accessible to anyone on the internet using GitHub Pages and automated workflows.

Prerequisites

GitHub account
Logseq graph in a GitHub repository

1. Open Repository Settings

Navigate to your repository on GitHub and click the Settings tab at the top.

2. Configure GitHub Pages

In the left sidebar, click Pages under the Code and automation section.

3. Set Build Source

Under Build and deployment, change the Source from "Deploy from a branch" to "GitHub Actions". This enables automated publishing whenever you update your graph.

4. Access GitHub Actions

Click the Actions tab at the top of your repository.

5. Run the Publishing Workflow

In the left sidebar, click your workflow (e.g., "Validate and Publish Logseq Graph to GitHub Pages"). Click Run workflow on the right, then click the blue Run workflow button.

6. Wait for Completion

The first run takes several minutes (10+ minutes) as it sets up the publishing environment. Subsequent runs will be much faster (1-2 minutes).

7. Set Repository Website URL

Return to your repository's main page and click the ⚙ (gear) icon next to "About". Under Website, click "Use your GitHub Pages website" to auto-populate your site URL.

Note

This is a good time to add a description to your project if you haven't already.

Verification

You'll know it worked when you can visit your GitHub Pages URL (typically https://your-username.github.io/repository-name/) and see your published Logseq graph.

Common Issues

If your workflow fails on first run, check that your workflow has proper permissions.
If the site shows 404 error, wait a few more minutes after workflow completion - GitHub Pages can take time to propagate.
If changes to graph don't appear on website, make sure to push your changes to GitHub and re-run the workflow.

Comparing SSD and NVMe Technologies

Miguel Pimentel — Thu, 27 Jul 2023 00:00:00 GMT

The main goal of this post was to aid in selecting SSD, and NVMe drives during a Micro Center sale. But I'll try to give an overview of what to look for next time you find yourself in the same position.

Storage Technologies

MLC V-NAND is the best option.
TLC is equivalent to V-NAND, and viceversa.
QLC is cheap but a little less reliable.
3D NAND is your basic entry point to SSDs.

3D NAND

The most basic of modern SSD technologies. Great for throwing on cheap systems, home servers, anything non-critical really.
It is not recommended to host your Operating System on 3D NAND, or QLC.

Quad Level Cell (QLC)

QLC (Quad Level Cell) is cheaper to manufacture than TLC (Triple Level Cell).
QLC is much slower and less durable to constant writing than TLC.
It is not recommended to host your Operating System on 3D NAND, or QLC.

Triple Level Cell (TLC)

TLC is more reliable when compared to QLC.
MLC is a Triple Level Cell based Samsung technology.

Multi Level Cell (MLC)

MLC is a Triple Level Cell based Samsung technology.

How Are SSDs Scored

Storage

1 point per GB
- Less accurate the bigger the SSD
- 3 TB and higher drives scale exp/log instead of linearly.

Price

Based on price per $1. Selected $0.10 as the baseline after averaging some calculations.

1 point for every $0.01 / GB below $0.10

Technology Coefficient

3D NAND Coefficient = 0.5 (Big Penalty)
QLC Coefficient = 0.75 (Small Penalty)
TLC Coefficient = 1.0 (No Change)
MLC V-NAND coefficient = 1.25 (Small Advantage)

NVMe M.2 2280 M Key

Brand	Storage	Price	Notes
970 EVO Plus	500 GB	$35	MLC V-NAND
970 EVO Plus	2 TB	$100	MLC V-NAND
970 EVO Plus	1 TB	$50	V-NAND
980	1 TB	$50	MLC V-NAND
980 Pro	2 TB	$120	MLC V-NAND
980 Pro	1 TB	$70	V-NAND
990 PRO	1 TB	$80	MLC V-NAND
Crucial P3	1 TB	$40	3D NAND
Inland	500 GB	$23	QLC
Inland	1 TB	$40	QLC
Inland	2 TB	$70	QLC
Performance	1 TB	$55	TLC
Prime	500 GB	$30	TLC
Prime	1 TB	$50	TLC

SSD

Brand	Storage	Price	Notes
Inland	1 TB	$50	TLC
Inland	512 GB	$25	TLC
Platinum	2 TB	$80	TLC
Platinum	1 TB	$43	TLC
Professional	256 GB	$20	3D NAND
Professional	125 GB	$15	TLC
870 EVO	1 TB	$50	MLC V-NAND
870 EVO	4 TB	$220	MLC V-NAND
870 EVO	500 GB	$40	MLC V-NAND
870 QVO	1 TB	$70	QLC V-NAND

Final Scores

NVMe

Description	$ / GB	Coef	Score
970 500 GB $35 MLC	0.070	1.25	629
970 2 TB $100 MLC	0.050	1.25	2506
970 1 TB $100 MLC	0.103	1.25	1250
980 1 TB $50 V	0.050	1	1005
980P 2 TB $120 MLC	0.060	1.25	2505
980P 1 TB $70 V	0.070	1	1003
990P 1 TB $80 MLC	0.080	1.25	1253
Crucial 1 TB $40 3D	0.040	0.5	503
Inland 500 GB $23 QLC	0.046	0.75	379
Inland 1 TB $40 QLC	0.040	0.75	755
Inland 2 TB $70 QLC	0.035	0.75	1505
Performance 1 TB $55 TLC	0.055	1	1005
Prime 500 GB $30 TLC	0.060	1	504
Prime 1 TB $50 TLC	0.050	1	1005

*Higher is better.

SSD

Description	$ / GB	Coef	Score
Inland 1TB $50 TLC	0.050	1	1005
Inland 512GB $25 TLC	0.049	1	517
Platinum 2TB $80 TLC	0.040	1	2006
Platinum 1TB $43 TLC	0.043	1	1006
Professional 256GB $20 3D	0.078	0.5	129
Professional 125GB $15 3D	0.120	0.5	63
970 500 GB $35 MLC	0.070	1.25	629
970 2 TB $100 MLC	0.050	1.25	2506
970 1 TB $100 MLC	0.103	1.25	1250
980 1 TB $50 V	0.050	1	1005
980P 2 TB $120 MLC	0.060	1.25	2505
980P 1 TB $70 V	0.070	1	1003
990P 1 TB $80 MLC	0.080	1.25	1253

*Higher is better.

Conclusions

Cheap system? Get any of these.
Secondary drive? Get any QLC or better.
OS Drive? Get any TLC or better.
Extra cash? Premium for reliability? Get any Samsung from the list.

Aurora Borealis Reference Guide

Miguel Pimentel — Tue, 11 Jul 2023 00:00:00 GMT

Wednesday, July 12th, 2023, was supposed to feature high solar activity, allowing for an incredibly large area of the northern United States to witness the Auroras as long as the light pollution was low enough.

Solar activity stayed at normal levels, so only the usual locations were able to see the lights, causing me to cancel my plans. Nevertheless, I wanted to share them here.

Light Pollution

Take a look at these locations sorted by distance.

Location	Distance	Travel Time	Rank*
Minneapolis	16 miles	25 minutes	0
Bloomington	2 miles	5 minutes	1
Chaska	15 miles	20 minutes	2
Farmington	24 miles	35 minutes	3
Jordan	22 miles	25 minutes	4
Norwood	35 miles	40 minutes	5
Gaylord	55 miles	60 minutes	6
Rapidan	75 miles	75 minutes	7
Chengwatana	95 miles	90 minutes	8
Sacred Heart	105 miles	120 minutes	9

* Higher Rank is considered better.

Tips to Get a Better Look

Viewing the aurora depends on four important factors.

1. Geomagnetic Activity

If the geomagnetic field is active, then the aurora will be brighter and further from the poles. Geomagnetic activity is driven by solar activity and solar coronal holes and thus it waxes and wanes with time. The level of geomagnetic activity is indicated by the planetary K index or Kp. The Kp index ranges from 0 to 9.

For Kp in the range 0 to 2, the aurora will be far north, quite dim in intensity, and not very active.
For Kp in the range of 3 to 5, the aurora will move further from the poles, it will become brighter and there will be more auroral activity (motion and formations). If you are in the right place, these aurora can be quite pleasing to look at.
For Kp in the range 6 to 7, the aurora will move even further from the poles and will become quite bright and active. At this geomagnetic activity level, it might be possible to see the aurora from the northern edge of the United States.
For Kp in the range 8 to 9, the aurora will move even further towards the equator and it will become very bright and very active. These are the events that create the best aurora and the extended auroral oval will be observable by the most people. At these levels, aurora may be seen directly overhead from the northern states of the USA.

It should be noted that the relationship between Kp and auroral latitude are approximate and represent averages. There will be times when these relationships do not hold up exactly.

There is an approximate relationship between Kp and the equatorward extent of the auroral oval. This relationship holds true in geomagnetic latitude, not geographic. At Kp = 0, the equator ward edge of the auroral oval is approximately 66 degrees. And it moves equatorward about 2 degrees for each level of Kp. So for Kp = 1, the aurora would move down to 64 degrees, for Kp=2, it would move to 62 degrees, etc… until reaching Kp of 9 at 48 degrees magnetic latitude.

2. Location

Go towards the magnetic poles. The north magnetic pole is currently about 400 km (250 miles) from the geographic pole and is located in the islands of north east Canada. Find a place where you can see to the north ( or south if you are in the southern hemisphere). Given the right vantage point, say for example on top of a hill in the northern hemisphere with an unobstructed view toward the north, a person can see aurora even when it is 1000 km (600 miles) further north. It should be noted that if you are in the right place under the aurora, you can see very nice auroral displays even with low geomagnetic activity (Kp = 3 or 4).

3. It Must Be Dark

Go out at night. Get away from city lights. The full moon will also diminish the apparent brightness of the aurora (not the actual brightness). One caveat that people often neglect to think of is that the high latitudes where aurora occur are also latitudes where it doesn't get dark in the summer. So combining a summer vacation to the arctic with aurora watching usually doesn't work. The aurora may still be there but it is only visible when it is dark.

4. Timing

Best aurora is usually within an hour or two of midnight (between 10 PM and 2 AM local time). These hours of active aurora expand towards evening and morning as the level of geomagnetic activity increases. There may be aurora in the evening and morning but it is usually not as active and therefore, not as visually appealing.

The best Seasons for aurora watching are around the spring and fall equinoxes. Due to subtleties in the way the solar wind interacts with Earth's magnetosphere, there is a tendency towards larger geomagnetic storms, and thus better auroras, to occur near the equinoxes. However, the number of hours of darkness decreases (increases) rapidly near the spring (fall) equinox so this caveat must be considered for those traveling to see the aurora.

Below are maps showing the most southern extent of where aurora might be observable for different levels of the geomagnetic Kp index (and the NOAA G scale). It should be noted that the aurora can often be observed hundreds of kilometers (miles) equatorward of the actual aurora so these figures do not indicate where the aurora may be but rather the point from which it may be observed.

Aurora Forecast

July 12th, 2023

G is NOAA Geomagnetic Storm Index (0–5)
Kp is Planetary K Index (0–9)

September 18th, 2023

Additional Resources

Being a Firefighter Does Not Save You From Burnout

Miguel Pimentel — Wed, 05 Jul 2023 00:00:00 GMT

My life took a sharp turn early last year. I am a very private person. You will not find me sharing my personal life on social media. That said, these last 18 months have changed me profoundly, and I feel like I need to write these feelings down. This post's threshold of success is helping one other person navigate difficult times.

Burning out is something I had little experience with. A mental image of what it looks like when you burn out was all I had. My only context coming from watching online influencers post articles/videos about how bad it can be. I never really learned what it looks like before you burn out, how you get to there, what the signs are. After three and a half years of being a volunteer firefighter, I burned out. It did not catch me by surprise; I had been struggling mentally for some time. Every day, telling myself that it would be different, that it would change. That feeling went away eventually, leaving me with too much to handle.

What Being a Volunteer Firefighter Means

Depends on where the question is being asked. Volunteer, or sometimes paid-on-call firefighters make up more than 70% of registered fire departments. Minnesota sits at more than 85% volunteer fire departments, according to the National Fire Department Registry. Our setting is Bloomington, Minnesota in the US.

Here are some quick facts on being a volunteer/paid-on-call firefighter for the fourth-largest city (by population) in Minnesota a few of years before:

Bloomington has 6 fire stations spread somewhat evenly over the city.
To be eligible, you need to live within 4 minutes of your nearest fire station.
You carry a pager around, when specific tones play, you are being asked to respond. This meant stopping anything you were doing, driving to the station, and responding to the incident in a fire vehicle.
Depending on incident time, one, two, three, or all six stations can be paged together to respond. For example, medicals calls involve 1 station responding with 1 truck, while residential fire calls start a 3 station response immediately.
You need to respond to at least 30% of the calls that were assigned to your station. These meant emergency calls during your work hours, weekends, holidays count against you.

Learning What Being Homesick Was All About

During the pandemic, the emergency medical calls went through the roof. The Police Department was unable to keep up with the large number of incidents, so the city came to rely on the approximate 100 volunteer Fire Department to pick up the slack. This meant those working normal 8 to 5 jobs had a harder time keeping up with their 30% minimum. Without going into details, it was difficult.

At the time, I was not in a good place mentally. Lots of things were lingering in the back of my mind. Everything has been made worse since I became woefully aware that I was homesick. I had planned to go visit for winter in 2020, but that option was quickly taken off the table. For context, I moved to the United States in Summer 2015, and to this day, due to one reason or another, I have yet to return.

The later half of 2021 overwhelmed me. Several things accumulated over time, some went under the radar and were never addressed until it was too late, and others were willfully ignored. Struggling to maintain my sanity and mental health, I decided to take a 90-day leave of absence from the fire department. My plans were to spend the extra time looking after my mental health. Unfortunately, nothing improved.

When the time came to rejoin, I opted to extend my leave as much as I could. I opted for another 90-day leave of absence, the maximum time allowed before needing to rejoin or separate. Again, nothing improved. I was just not in a good place mentally. A few days before needing to rejoin after 6 months of leave, I broke a bone in my hand.

How Did This Happen

Distracted, I went to move a glass/ceramic base from my desk to the kitchen. It made it a good foot before I accidentally dropped it on a dog bowl on the floor. (we fed the dogs in weird places back them) It slipped from my hands and fell on the bowl and shattered. This was not the first time this had happened. I… struggle to describe what my feelings at the time were. My brain approved the decision to punch something. When tasked with finding something to punch, once again, my regretful train of thought took me outside, to the patio where I proceeded to turn around and punch the side of the house. The factors considered at the time were overwritten by rage.

Being Stubborn is Not the Same as Being Naive

So it happened. I punched the side of the house. Pain. Broke a bone in my hand, unbeknownst to me, of course. I managed to convince myself that it was a minor injury and I didn't need to be seen by a doctor. The hand hurt, but I chose to ignore it because my pride was in danger! (it wasn't) I went about my business for three days before the pain overtook my pride. After the initial triage, and x-rays were completed, the doctor returned to the room with x-rays of my hand and informed me that I had a boxer's fracture in my right hand. My brain could no longer hold the spell it had me under. I wasn't being naive, I was being stubborn.

Unfortunately, having used all the time permitted for a leave of absence, and lacking the ability to rejoin due to my right hand being broken, I quit the fire department.

Accepting Help is the Hardest Part

It does get tough sometimes, life can weight a lot more than what you can handle. What we often forget is to look around, to look for the people that are willing and lovingly ready to help. My biggest mistake was thinking I had no support, when it really was the complete opposite. I am in a much better place now. I have others to thank for that. The road back is long, but I have friends and family right beside me. It has been a long time, but I finally feel like I am moving forward.

Unlock the Sidebar Width in Firefox

Miguel Pimentel — Sun, 25 Jun 2023 00:00:00 GMT

This post will guide you through unlocking the sidebar width in Firefox. It will let you resize it beyond what is possible by default. We will be setting both the maximum, and the minimum width. You will have a chance to customize these values once at the right step.

Why Would Anyone Want to Do This?

To enhance the use of the Firefox Side View extension.
To compliment the use of one of my Firefox sidebar extensions.

TL;DR:

Open about:support.
Locate your Profile Folder.
Open your Profile Folder.
Create a new folder called chrome.
Inside the chrome folder, create a new file called userChrome.css (includes the file extension).
Copy and paste this in it: #sidebar-box { max-width: 40% !important; min-width: 300px !important; }.
Customize the width to your preference.
Open about:config.
Find toolkit.legacyUserProfileCustomizations.stylesheets and change its value to true.
Restart Firefox.

Step-by-Step Instructions

1. Open `about:support`

In a new tab, navigate to about:support.

2. Locate the Profile Folder

Under Application Basics, find Profile Folder.

3. Open Profile Folder

Locate and click the Open Folder button next to it. You'll find it next to an address similar to:^[1]

%appdata%\Mozilla\Firefox\Profiles\your-profile-id.default-release

Note

In Windows, %appdata% is equivalent to:
C:\Users\your-username\AppData\Roaming.

4. Create New Folder `chrome`

Inside your Firefox Profile Folder, create a new folder named chrome.

5. Create `userChrome.css`

Inside the newly created chrome folder, create a new file named userChrome.css.

6. Copy and Paste Its Contents

Copy the following code, and paste as content inside useChrome.css and save:

#sidebar-box {
  max-width: 40% !important;
  min-width: 300px !important;
}

7. Customize the Width

You may change the units to any length you find more convenient.

Tip

You should take the time to play around with these units to find what fits your use case better.

8. Open `about:config`

In a new tab, navigate to about:config, and search for:

toolkit.legacyUserProfileCustomizations.stylesheets

9. Change the Value

Change its value from false to true.

10. Restart Firefox

Finally, restart Firefox for the changes to take effect.

In Windows, %appdata% is equivalent to: C:\Users\your-username\AppData\Roaming. ↩︎

Blogging to Tame the Monkey Mind

Miguel Pimentel — Tue, 11 Apr 2023 00:00:00 GMT

Last week, I came across Danny Guo’s Why I Blog post, and it inspired me to write this.

The term monkey mind is a Buddhist term meaning: restless, unsettled, incontrollable. The original analogy comes from describing the human mind as being full of drunken monkeys, constantly screeching, fighting, distracting, and creating general mental chaos. I’ll go over what helps me keep the monkeys at bay. I hope some of this resonates with you and your monkeys as well.

Clear My Mind

My brain seems to always find distractions for me to tangent off to. Sitting down and making an effort to write everything rushing through my head has been an important mechanism to reduce my stress levels. This concept of dumping your brain by writing isn’t new, but it was to me.

It took me some time to mold the raw output into something I could use. In my case, it started within my journal. Using the left page for brain dump, and the right page to process it down to simple tasks, references, and other tagged entries. Small details like leaving space between entries allow me to go back and add an entry in a much closer position relative to other similar ones.

When I think of sharing knowledge, the image of me boring my friends to death on a topic they aren’t interested in comes to mind. It is my goal to minimize those kinds of situations. I find it easier to talk about a topic in person if I have already “talked” about it on the blog. I can actually debate the idea, without feeling the need to interject at every interaction.

A sure way to tell whether you know a topic, comes from being able to teach it to someone else. I am horrible at keeping explanations simple. I am terrible at controlling my impulse to talk when engaged in conversation. Sharing knowledge via these posts helps my overall mental state. It reduces the amount of fleeting ideas going back and forth, and provides me with an opportunity to turn those into actionable ideas instead of letting them grow old and irrelevant.

Document My Learning

Recently, I have been down the rabbit-hole that is Personal Knowledge Management (PKM) tools and apps. Jumping from app to app, looking for something that “works” for you. It’s fun! But, it is stupid easy to lose sight of your initial goal and turn that curiosity into wasted efforts.

By making a public commitment (even if nobody reads it), I am imposing a healthy amount of pressure on myself to be more open and honest about how I use my time. Keeping yourself accountable is hard work. Any amount of effort to curb “mindless wonder” helps tremendously.

Starting a Blog

Blogging pushes me to refine my better ideas. Expanding a fleeting thought into a blog post has a liberating feeling. It’s not even related to others reading your post. You don’t need an audience to start. The same way you should just journal, you should just blog.

Comes from the same idea that producing content is and should be a priority over consuming it. Find what topics make you want to write. Compile your reference material. List articles you’ve read, blogs you have enjoyed, reference that weird website you know and talk about why.

Avoid getting stuck on details. You can change your hosting provider later. The first thing you’d need to consider is whether you’ll be using a custom domain. I highly suggest you do so, as it makes for easier platform changes. My personal recommendation is to start writing anywhere. Pick a platform and focus on writing about things you are interested in.

Here are a few places to start:

MiguelPimentel.do

The Adopt-a-Drain Dashboard

The Tooling: Why Streamlit?

Managing the Environment with uv

Processing the Data with Pandas

Visualizing Impact

Looking Ahead

Adding Snow, Keeping Warm: Using Responsibly

The Digital Paradox

Respectful Flurry: Accessibility and <is-land>

My Winter, Coded on My Own Terms

Solving Blinking View Transitions (Featured on Piccalilli)

When Gratitude Rings

The Small Gesture That Landed

Anticipating Connection, Still Finding Surprise

Recognizing What Actually Counts

VS Code Regex: Conditional Find and Replace

The Prerequisites

1. Capture Groups and Backreferences

2. Non-Greedy Matching

Solving the Exclusion Puzzle

Breaking Down The Pattern

The Result

Safety First

When Being Wrong Goes Right

The Project Details

The Pressure to Be Perfect

Redefining Success

My Actual Problem-Solving Rituals

Fidgeting as Focus

Environment Tweaks

When Problems Get Too Big

What Doesn't Work

Final Thoughts

PomoBar for Obsidian

From HTML Prototype to Production Plugin

The Problem with Existing Solutions

Architecture Decisions: Building for Maintainability

Design Philosophy: Flexible Minimalism

Technical Deep Dives

State Management and Memory Safety

User Feedback Integration

TypeScript in Practice

Modern Development Practices

Build System and Tooling

Testing and Validation

Documentation as Development Practice

Current State and Lessons Learned

Building Your Own Plugin

Final Thoughts

Building in Silence

Acknowledging the Gap

What I've Been Building

Lessons From the Silence

Getting Back to Writing

Moving Forward

10 Fun Facts About the Dominican Republic

1. Cigua Palmera: Our National Bird

2. Larimar: Found Only Here

3. Taíno Petroglyphs in Cave Systems

4. Hispaniolan Solenodon: An Ancient Mammal

5. First European Settlement: La Isabela

6. Santo Domingo: Oldest Continuously Inhabited European City

7. Pico Duarte: The Caribbean's Highest Peak

8. Lake Enriquillo: Below Sea Level

9. Carnaval: February Celebrations

10. Humpback Whales in Samaná Bay

Coming Home

Publish a Logseq Graph to GitHub Pages

What You'll Build/Achieve

Prerequisites

1. Open Repository Settings

2. Configure GitHub Pages

3. Set Build Source

4. Access GitHub Actions

5. Run the Publishing Workflow

6. Wait for Completion

7. Set Repository Website URL

Verification

Common Issues

Managing the Environment with `uv`

Respectful Flurry: Accessibility and `<is-land>`

1. Open `about:support`

4. Create New Folder `chrome`

5. Create `userChrome.css`

8. Open `about:config`