Forem: Bridget Amana

The Challenges Threatening Open Source

Bridget Amana — Wed, 25 Feb 2026 20:33:12 +0000

Open source software (OSS) serves as the digital backbone of modern society, providing the foundation for the applications and services we rely on daily. However, the same openness that drives innovation also introduces significant risks. As our dependence on shared code grows, the obstacles facing the ecosystem become more complex. Understanding these challenges is the first step toward building a more resilient future for software.

Security vulnerabilities

Many open source initiatives are maintained by small groups of volunteers or even a single individual. While this grassroots approach is a testament to the community's spirit, it creates a "single point of failure." Inactive or abandoned repositories can harbor known vulnerabilities that remain unpatched for years, leaving any system that uses them exposed.

It gets messier when you factor in dependency chains. Most open source software relies on other open source software, and those chains can get long and hard to track. One weak link in that chain and suddenly you've got a security problem that ripples outward. The transparency that makes open source so powerful is also what makes it vulnerable here. Attackers can see the same code that the community uses to fix things, and sometimes they get there first. That's why regular auditing and automated scanning have become so critical, not just a nice-to-have.

Sustainability

Every open source project has people behind it, and keeping those people around is one of the trickiest parts of the whole thing. These projects need funding, they need resources, and most of all they need contributors who stick around. When a project becomes essential to global industry but lacks a support structure, the burden often falls on a few individuals.

This leads to maintainer burnout—a state where the pressure of fixing bugs and managing requests outweighs the joy of contributing. Sustainability is not just a financial issue; it is about creating a culture where contributors feel supported. If the software that millions of companies depend on is treated as a "free" resource without reinvestment, the very people who build it may eventually stop showing up.

Maintaining code quality

Open source invites anyone to contribute, and that's one of its greatest strengths. You get people with all kinds of backgrounds, skill levels, and ideas jumping in, and that kind of diversity makes projects genuinely better. But it also makes keeping the code tight and consistent a real challenge.

When contributions are coming in from all over the place, without solid review processes or clear guidelines, things can start to slip. Small issues add up, and before long you've got a codebase that's harder to maintain and trust. It's one of those problems that doesn't announce itself loudly. It just quietly builds up until someone notices something is off.

Looking ahead

Open source has never been just about code. It's about curiosity, generosity, and the belief that collaboration makes better things and better people. The next few years will test that belief like never before. But if we do what we've always done best, show up, share the work, and care for each other, we won't just sustain open source. We'll sustain the spirit that started it and ensure the success we've built continues for the good of the modern world.

Getting Your First Open Source Contributors

Bridget Amana — Mon, 16 Feb 2026 10:49:12 +0000

I have built a number of open source projects, including snippet shot, tailwindcss migrator, and pixlated. After building, I shared it on forums and communities, made it clear in the readme that 'contributions are welcome,' but still got zero contributions. It made me wonder what exactly I was doing wrong. I looked at these repos from outsider's perspective. I noticed that, aside from the big “contributors are welcome” message, nothing else was inviting me to contribute. From there, I discovered a few more issues as to why my project wasn’t receiving contributors.

Show how to use and setup your project

When I first shared the repo, there was nothing guiding users on how to set up the project. I had a README but it was missing installation instructions. Without this, potential contributors face unnecessary friction. If you can't get a project running, how can you contribute to it? Good installation instructions aren't just 'npm install.' They should walk through the complete setup: prerequisites, installation steps, how to run locally, and what success looks like.

Keep your project active

I have scrolled past repos countless times simply because the last activity was months ago. It subtly signals that this project isn’t active so why waste my time contributing. When I looked at my projects from that perspective, I realized I wouldn't even contribute to them if they weren't mine. You don't need daily commits, but aim for visible activity at least once a month. This could be merging a PR, updating a dependency, adding an example to your docs, or even just triaging issues. The goal isn't busywork, it's showing the project has a pulse. On Pixlated, I set a reminder to review and update something small monthly, even during quiet periods. That consistent timestamp matters more than you'd think.

Open up a few issues first.

Sometimes, people don't know how they can contribute. Be their guide. Opening a few issues paves the way for more contributors. I looked at the project and it seemed dry—maybe people didn't know where to start. Contributions on pPxlated started coming in when I opened up a few good first issues. The first issue I opened was to 'convert all project images to .webp format'. This was after running the site on page speed insights and it pointed out that performance issue. I could have done this instantly by myself but I thought, this is a good simple first issue for someone just getting started with open source contributions. Within a couple of hours, someone commented asking to be assigned. After that, I used the same strategy. I opened simple issues that wouldn't take more than 5 minutes to do. With this constant interaction, other people started opening issues. A few issues were ignored till they were further broken down in the issue description.

It shows that people want to contribute but are confused about what they can do.

Show appreciation to your previous contributors.

Contributors aren't paid for their work, so recognition matters. Seeing your GitHub profile on a project gives contributors that dopamine hit that makes them want to return. Give people reasons to be excited: thank contributors after a successful merge or add a contributors section to your README. This appreciates past contributors and signals to new ones that their efforts will be valued.

Publicize your work

You can't contribute to what you don't know about. Contributions aren't coming in because your project is still very much hidden. Share your project on communities and social media. Announce what you're building, that it's open for contributions, and when you open new issues. I posted on Reddit and created an article on Dev.to to share the project. Neither got much traction. What actually kickstarted contributions was a Twitter post announcing good first issues. Don't constrain yourself to one platform. Twitter worked for me because I was already consistent and had followers there. It might not work for you if you're just starting out. So, go where your audience is. I didn't just stop at one post but continued giving updates regularly.

Get your project up and running first

People won't contribute to what isn't working. Project owners might think building together is part of the open source spirit, but contributors want to improve something functional, not debug a broken foundation. Get the project started on your own and show that crucial features are working. Don't build halfway with nothing visibly working and expect people to join. This doesn't mean your project needs to be feature-complete, but there should be a working core that people can clone, run, and see in action. For Pixlated, I made sure the basic image pixelation worked and the site was deployed before asking for contributions. Contributors could visit the live site, understand what it does, then look at the code to improve it. Starting with a half-built project where nothing runs yet means contributors spend their time figuring out your vision instead of improving it.

Conclusion

If your project hasn't had contributions, the first step is to audit your readme. Make sure someone can understand what it does and how to run it within 30 seconds. Then work on sharing your project to get eyes on it. The more eyes you get on it, the greater your chances of getting a contributor. The contributors are out there, you just need to make it easy for them to find and join you

Exploring The Career Of A Technical Writer

Bridget Amana — Mon, 16 Feb 2026 10:45:29 +0000

Who a Technical writer is

A technical writer (sometimes called a tech writer) is someone who takes complicated technical concepts and makes it easy for people to understand. They translate jargons to easy-to-understand documentation. While many people think technical writers just write "guides", their role is more expansive than that:

Information Design: They determine how to structure information so users can find what they need quickly.
User Advocacy: They represent the end-user, often testing products to identify points of confusion before the documentation is even written.
User Advocacy: They speak up for you, the end-user. They'll test products and spot confusing parts before the documentation is even written.
Content Creation: They create all sorts of materials, including:
- API Documentation: Instructions that help developers use software tools.
- Help Systems: Those searchable knowledge bases you use when you're stuck.
- Standard Operating Procedures (SOPs): Internal guides that show employees how to do their jobs.
- White Papers: Deep-dive reports that explain specific technologies or solutions.

Skills Needed to Be a Technical Writer

Technical Proficiency

You don't need to be a programmer, but you'll need some basic technical knowledge. If you're documenting a Python tool, for example, understanding basic Python concepts helps you ask better questions and catch mistakes.

Research

Research is at the core of what a technical writer do. Writers dig into unfamiliar topics, interview subject matter experts, and test products themselves to truly understand what they're explaining. Good research means you can explain something clearly even if you weren't the one who built it.

Communication and Collaboration

Technical writers work with developers, product managers, designers, and customer support teams. You need to ask the right questions and build good relationships with stakeholders.

Writing and Editing

This might seem obvious, but it's about more than just grammar. You need to write clearly, cut unnecessary jargon, and know when to use a diagram instead of a paragraph. You're always thinking: "What's the simplest way to say this?"

Role of A Technical Writer

Create Documentation
Translate Technical Information
Research & Understand Products
Organize Information
Maintain and Update Content

Your guide to getting started

If you're interested in becoming a technical writer, here's the good news: you don't need a specific degree. Many technical writers come from writing backgrounds, while others transition from technical roles like software development or IT support. The key is being curious, willing to learn, and able to explain things clearly.

Improve Site Performance by Auditing Unused Code

Bridget Amana — Mon, 08 Dec 2025 16:47:52 +0000

Overview

Shipping unused CSS and JavaScript does more than clutter your codebase. It directly affects your site's performance. Every unused rule or function is extra data the browser has to download and parse before the page becomes interactive. While you could manually compare your styles against your HTML, modern browsers provide a more easier solution: the Coverage tool.

What the Coverage tool does

The Coverage panel in developer tools analyzes every CSS and JavaScript resource loaded on a page. It calculates which parts of each file are actually used during rendering and highlights the unused sections. This gives you a clear view of what can be safely removed.

How it works

Open DevTools (Cmd+Option+I on Mac or Ctrl+Shift+I on Windows).
Open the Command Menu (Cmd+Shift+P or Ctrl+Shift+P).
Type Coverage and select Show Coverage.
In the Coverage tab, click the reload icon to start recording.

The panel lists all CSS and JavaScript files, along with the percentage of code executed. Red highlights indicate unused sections. You can also filter the results to show all resources or only CSS or only JavaScript.

Analyzing Results

Once the page reloads, the Coverage tab displays the used and unused portions of each file. These results are helpful but require proper interpretation.

Pseudo classes such as hover or active appear unused when they are not triggered.
Media query rules appear unused if your current viewport does not match the query.
Interaction based styles and animations will not register unless activated during recording.
JavaScript that runs only after specific actions will appear unused until those actions occur.

Conclusion

Performance improvements do not always require complex changes. Identifying and removing unused CSS and JavaScript is a simple and effective way to reduce page weight. The Coverage tool helps you find what is no longer used on the page, and removing that results in a faster site.

Understanding why 100vh behaves differently on mobile

Bridget Amana — Mon, 08 Dec 2025 16:38:09 +0000

The expected behavior of 100vh is simple. When you apply it to an element, it should take up the full visible height of the screen so no scrolling is required. This works perfectly on desktop. On mobile browsers, especially Chrome and Safari, the behavior is different. The bottom part of the page sits behind the browser interface, so the content appears cut off unless you scroll. This article focuses on understanding why this happens and how to fix it.

The problem

100vh has always been the quick way to create a full height layout. The issue is that mobile browsers do not calculate 100vh using the actual visible space. The browser address bar and tab bar are not included in that calculation. When those bars expand or collapse, the visual viewport changes, but 100vh does not adjust.

Here is a simple example.

<div class="app-shell">
  <header>
    <h1>My App</h1>
  </header>
  <main>
    <p>This is the main content area.</p>
  </main>
  <footer>
    <p>Footer content here.</p>
  </footer>
</div>

.app-shell {   
  display: flex;     
  flex-direction: column;     
  min-height: 100vh; 
}  

main {     
  flex: 1; 
}

On mobile, part of the layout will sit behind the browser bar. When you scroll, the bar collapses and the layout suddenly fits. This is the inconsistency developers run into.

Many older articles suggest using webkit-fill-available. This used to work in certain contexts but is unreliable today and does not solve the root issue.

100dvh as the fix

A more accurate way to handle full height layouts on mobile is to use the new dynamic viewport unit: dvh.

Dvh stands for dynamic viewport height. It is one of three new viewport units (svh, lvh, dvh). The dynamic version adjusts based on the current visible viewport. If the browser address bar collapses or expands, dvh updates in real time.

Using our earlier example, the fix looks like this:

.app-shell {     
  display: flex;     
  flex-direction: column;     
  min-height: 100vh;     
  min-height: 100dvh; 
}

Setting the height to 100dvh tells the browser to size the element using the actual visible viewport height. This prevents the layout from slipping behind the browser UI on mobile.

Conclusion

Dvh provides a practical and reliable fix for the long standing 100vh issue on mobile browsers. It responds to changes in the viewport and keeps your layout visible without relying on outdated workarounds. While browser behavior may continue to evolve, dvh is currently the most accurate way to create full height layouts on mobile.

A Practical Guide to Color Contrast for Web Developers

Bridget Amana — Mon, 08 Dec 2025 12:09:58 +0000

Color contrast determines the readability of your interface in real-world conditions, affecting everything from quick button taps to long-form reading. You notice this impact most when you are outside with low screen brightness or using a device with a weaker display.

This is why contrast is not just a design concern; it is a core part of front-end engineering. You already invest time in performance, layout, and stable interactions. Contrast belongs in that same category because it dictates how reliably your UI performs across different environments.

What Contrast Actually Measures

The Web Content Accessibility Guidelines (WCAG) use a formula comparing the relative luminance of two colors to determine visibility. While you do not need to calculate this manually, you must know the targets.

Normal text requires a ratio of at least 4.5:1.
Large text requires a ratio of at least 3:1.

These values sit on a scale from 1 to 21, where higher numbers represent stronger contrast. Black text on a white background is 21:1, while white on white is 1:1. Most readable color pairs in modern web projects land between 5 and 14.

These ratios are not arbitrary numbers chosen at random. They are based on how people with different visual acuities perceive brightness. Even users with typical vision lose clarity in low light or outdoor glare, so a pair that passes at 4.5:1 will survive more environmental factors than a pair hovering at 3:1. This is why aiming for the bare minimum works for headlines but often causes readability issues for smaller body text.

Checking Contrast While You Work

For immediate feedback, your browser is the fastest tool. By opening DevTools and inspecting a text element, you can view the contrast ratio directly within the accessibility or styles panel. This allows you to catch accessibility bugs early in the process, particularly when you are blocking out layouts or experimenting with new theme colors.

However, browser DevTools are most accurate for text on flat, solid backgrounds. If your text sits on top of a gradient or a complex image, the browser cannot always calculate the background color reliably, so you will need a dedicated tool.

Using Dedicated Contrast Checkers

Small color swatches can be misleading because some combinations technically meet the math requirements but still look weak in a real interface. Tools like colourcontrast.cc are valuable here because they update the entire page preview based on your selection.

This approach lets you see titles, paragraphs, and UI components using the color pair at different scales. It gives you a realistic sense of stability that a simple calculator cannot provide. Sometimes a ratio of 4.7:1 looks fine in isolation but feels too thin once placed inside a dense layout, and seeing it in context helps you make the right judgment call.

Automating the Workflow

To reduce guesswork across your team, you should integrate automated checks. While linting plugins like eslint-plugin-jsx-a11y help catch missing labels, they sometimes struggle to calculate color contrast since they cannot always see your CSS files.

People often treat accessibility as a separate compliance requirement, but in practice, contrast improves basic usability for everyone. It makes text easier to scan, reduces eye strain, and keeps interfaces clear on older hardware. By treating contrast as a technical constraint rather than just an aesthetic choice, you help make the web a better place.

Finding Open Source Projects to Contribute To

Bridget Amana — Mon, 08 Dec 2025 11:46:02 +0000

Finding open source projects to contribute to is usually harder than people make it sound. Most articles give the same standard advice which tells you to search for “good first issues” and filter by labels. In reality, this does not always work because maintainers often forget to label issues. Many of the “good first issues” you find belong to old or inactive projects, so you end up wasting time trying to contribute to something no one maintains anymore.

From my experience, there are much more effective ways to find active work.

Follow Active Contributors

A better approach is to follow active open source people rather than just staring at repositories. When you follow contributors and maintainers you trust, your GitHub feed becomes a powerful tool. You start seeing the pull requests they open, the issues they interact with, and the new projects they star.

This gives you visibility into living projects instead of abandoned ones. It is much easier to join projects this way because you are walking into a space that already has activity around it.

Contribute by Testing, Not Just Coding

Most people overlook the fact that contributing is not limited to opening pull requests. For my first year in open source, I mostly contributed by testing projects. I would run the project locally, use the features, and actively look for problems.

These problems could be anything from an accessibility issue or a broken UI on mobile screens to small performance lags or grammar errors in the documentation. All of these details matter. When you find them, open an issue. You can take on a few of them yourself or leave them for other beginners to tackle. This helps maintainers more than you think, and it gets you familiar with the codebase at the same time.

Use Curated Discovery Channels

Another reliable way to find active projects is through trusted Twitter accounts that share open source opportunities. These are the verified accounts I follow:

-GitHub Projects
-Open Source Projects
-Meta Open Source
-Tom Doerr

They post a wide range of projects with different tech stacks, so you can choose something that matches your current skill level or interests.

Don't Ignore Small Projects

I always tell beginners not to ignore small projects. Many people only want to contribute to popular repositories with thousands of stars, but those projects started small too.

Smaller projects are usually more open to beginners and have maintainers who respond faster. You often learn the most in places where you are not competing with hundreds of other contributors. Start small to build your experience, and then move into larger communities when you feel ready.

Finding projects is not always straightforward, but there are better ways than relying on labels. Follow active contributors, test real projects, open issues, and do not overlook the smaller repos. This approach keeps you in the flow of active work and leads to more meaningful contributions.

Soft skills can be learned too

Bridget Amana — Sun, 07 Dec 2025 02:01:53 +0000

There is nothing more frustrating than watching someone who seems naturally good with people. You see them enter a room and everything shifts a little. They connect easily, they say the right things without forcing it. It feels almost like they have access to a script the rest of us never got.

When we see this, it feels unfair. It feels like something they were born with. So we tell ourselves a story. We say, "That’s just who they are" or "I’m not wired like that." We act as if personality is fixed, like a gift only a few people have.

But the more I pay attention, the more that idea stops making sense.

Most of the things we are good at today were once things we knew nothing about. We learned them slowly, by trying, failing, and adjusting. We accept this in almost every part of our life, yet when it comes to social skills, confidence, or communication, we convince ourselves it is different.

The people who look "natural" have just been practicing longer, even if they didn’t realize it. They paid attention to how others responded to them, they corrected themselves, they tried again. Over time, those efforts blended into habits that look effortless from the outside.

What we call charisma or confidence is usually a collection of small behaviors. Making eye contact, listening fully, speaking with intention instead of rushing, showing genuine curiosity. These are not personality traits. They are skills, and skills can be learned.

Once you stop treating your personality like something you were handed at birth, you gain control. You can notice the parts of yourself you want to strengthen and work on them piece by piece. You can model people you admire. You can improve without trying to become someone else.

If you treat growth as something you participate in, not something that happens to you, things change. The gap between you and the people you think are miles ahead becomes smaller and far less intimidating.

I still catch myself comparing and thinking others are just "born that way." But then I remember the small habits I’ve quietly developed and I see that the gap isn’t unbridgeable.

Exploring native Browser/Web APIs

Bridget Amana — Tue, 02 Dec 2025 19:44:44 +0000

Most frontend projects rely heavily on REST APIs. We fetch data, handle the loading state, and display lists. While this is an essential skill, it ignores a large part of what the browser can do.

I recently saw a tweet about using native Browser APIs to build more interesting projects. I wanted to try this myself, but I found it difficult to find good project ideas. Most documentation provides syntax examples but rarely explains what you can actually build with them.

I created a site to solve this. It serves as a collection of browser APIs, resources, and specific project ideas for each one.

You can view it here

What is inside

For each API, I included the MDN documentation, a couple of resources and a few project ideas. This will be updated as I find more project ideas.

Why use Browser APIs

Focusing on these APIs requires a different approach than standard data fetching. You have to manage permissions, handle real-time events, and interact with device hardware. Asides from it being fun, it is a practical way to understand the web better.

I am using this list to guide my own learning. I plan to update it as I discover more APIs and use cases.

If you are looking for a new project to build, you can check out the full list here.

Introducing SnippetShot – A VS Code Extension for Clean Code Screenshots

Bridget Amana — Thu, 11 Sep 2025 23:25:39 +0000

As someone who tweets often and builds in public, I regularly need to show a part or snippet of my code. I’ve always done this by copying the code and using tools like ray.so or Polacode.

For those who don’t know, Polacode is a Visual Studio Code extension for creating code screenshots. I love the tool, but it’s a bit buggy, and since the maintainer is no longer active, those bugs remain. So I decided to build my own.

What is SnippetShot?

SnippetShot is a free VS Code extension that lets you turn code into clean, shareable images in seconds. Copy your code, open SnippetShot, and export a styled PNG without leaving your editor. That’s how easy it is.

SnippetShot is an updated version of Polacode, so if you were a fan of Polacode, this is the tool for you.

Features

Customizable background. Pick any color to match your style or branding.
Line numbers toggle. Show or hide line numbers as you please.
Add custom credits or text to your screenshot.
Twitter/X sharing. Instantly copy your image and share it.

How it works

To install the extension, click the Extensions icon on the left sidebar of your editor to open the marketplace, then search for SnippetShot.
After installing, open the command palette. On Windows, use Ctrl+P. On Mac, use Cmd+Shift+P.
Open any file with code. Select the code, and it will appear in the editor’s right panel where SnippetShot is open.
From there, you can change the background color, toggle line numbers, and add your name.
Click Save or Share to Twitter.

SnippetShot also supports gradient backgrounds for more flexibility in styling.

Note: There’s another tool out there with a similar name, but mine is a pure VS Code extension.

Download the extension here. I also just launched on Product Hunt. If you find it useful, please give it an upvote there and a star on GitHub.

[Boost]

Bridget Amana — Fri, 05 Sep 2025 11:46:26 +0000

n8n and Bright Challenge: Unstoppable Workflow

Bridget Amana

Aug 31 '25

AI Agent for Google Play Review Monitoring

#devchallenge #n8nbrightdatachallenge #ai #webdev

Comments 1

3 min read

AI Agent for Google Play Review Monitoring

Bridget Amana — Sun, 31 Aug 2025 08:24:10 +0000

This is a submission for the AI Agents Challenge powered by n8n and Bright Data

What I Built

I built a workflow that takes reviews of an app from Google Play, runs sentiment analysis on them, and routes them based on the results. Positive reviews get logged for tracking, while negative ones are flagged so they can be acted on. The whole point was to create an automated system that helps teams quickly understand how users feel about their app without going through hundreds of reviews manually. To make it practical, I used Temu as the app for testing

Demo

n8n Workflow

Github Gist

Technical Implementation

I started by connecting Bright Data’s Web Scraper node in n8n to Google Play. My first challenge was figuring out the correct URL setup to fetch reviews. I realized I needed to scrape by the app’s URL and then create a dataset node to structure the review data.

Once the reviews came in, I needed a way to handle them individually. I used n8n’s Split Out Items node to break the dataset into separate review objects. At first, I struggled with which fields to split, but including only the review text solved the problem. Later on, I discovered a feature inside Bright Data’s actions: Split snapshots data to parts by snapshot id, which would have done exactly what I did with split out.

For sentiment analysis, I connected n8n’s AI Agent node with OpenAI GPT-4.1-MINI. The prompt I used was:

Given the following review {{ $json.review }}, return a JSON with: {sentiment: ..., summary: ..., key_issue: ...}

It worked, but I had to tweak the output handling to make sure it returned proper JSON that n8n could actually parse.

Next came the routing logic. I wanted negative reviews to go to the team for action and positive ones to just be logged. Using an IF node, I set the condition:

{{ $json["message"]["content"]["sentiment"] }} == "Negative"

At first I ran into false branches because I wasn’t using expressions correctly, but once I switched to using proper expressions, it started working as expected.

Finally, I logged everything into Google Sheets. Each row had the Sentiment, Summary, and Key Issue fields.

Bright Data Verified Node

Bright Data’s verified node is what made this workflow possible. At first, I wasn’t fully clear on what Bright Data was or how to really use it. I joined the live demo session and got a few pointers, but I was still confused until I stumbled on a video that broke it all down. That video is what unlocked things for me, so if you’re new to Bright Data, I recommend watching it first.

Once I had the node running, it was straightforward to fetch reviews directly from the Google Play page. The dataset it produced was clean enough to connect with other parts of n8n, which made the later steps; splitting, analysis, and routing, much easier to manage.

Journey

This was my first real attempt at using Bright Data with n8n, and it didn’t go perfectly at first. I spent time figuring out URL structures, how datasets worked, and how to properly handle outputs from AI. There were moments where I thought I had broken the workflow entirely, but each roadblock helped me learn how n8n’s nodes actually work in practice.

The biggest lightbulb moment was discovering Bright Data’s snapshot split feature, which made structuring data far simpler. Another one was realizing how much expressions matter inside n8n. Without setting them correctly, conditions and mappings just don’t behave the way you expect.

If I were to redo this, I’d start by setting up a proper schema for how I wanted the data to flow before building the workflow itself. That would have saved me a lot of time. Still, the process taught me how powerful Bright Data and n8n can be together when you use them right.