No more algorithm-driven feed. No more personalised clickbaits. No more dubious facts from sites I never visited. No more articles purposefully fed to me to please the ad-sense lords. Control and intention over my content consumption. Embracing the simplicity and efficiency of RSS, and taking back the joy of a self-curated web experience.

I can’t help but feel that RSS is one of the most underrated tools on the web. And there’s so much more we can do with it!

Starting with web syndication, as a way to distribute content from one website to another, letting people subscribe to updates without visiting the original site. It allows decentralized content sharing, consumption, and access to desired content from multiple sources in a single place. While a conerstone of the searchable web, somewhere in the recent decade we took a wrong turn and started to rely on algorithms to decide what we want to read. This is where RSS comes in to save the day, as a simple and effective way to syndicate content across the web.

RSS (Really Simple Syndication) is a consolidated popular (old!) format for web syndication. RSS feeds are machine readable XML files that contain a summary of the content, including titles, descriptions, and links to the full articles. It is indeed really simple! These elements are typically updated whenever new content is published.

RSS feeds can be found on many websites, including this one. One can subscribe to RSS feeds using feed readers or aggregators, which automatically check for updates and display new content in a user-friendly format. RSS is particularly useful for people who want to stay updated on multiple websites without having to visit or refresh each one individually or fill your inbox with newsletters (ahem). It allows easy content discovery and online reading without distractions. There are many popular feed readers out there. Lately, I use feeder for its slim features. You can pick the one you like and are never locked in to any platform, pretty much every service and app supports exporting/importing RSS feeds.

RSS works well for blogs or news sites; but it also works for for any website that publishes content regularly. This includes podcasts, YouTube channels, and even social media accounts^{2 3}. Having your own RSS feed lets you receive updates on your favorite content without relying on algorithms or notifications from individual platforms.

If you haven’t already, consider subscribing to your favorite websites’ RSS feeds. Streamline your online reading experience and take control of your content consumption. The internet is an infinite ad-space forever in expansion. While we work on a consolidated federated and syndicated⁴ search for ourselves. Do what you can to skip the algorithm, and spend your (limited) time on the web on the things you actually care about. As a reward you get an intentional ad-free experience by default, and privacy-friendly too!

If you are already reading this article in an RSS reader, send me your website or RSS feed, and I will add it to my reader. Long live RSS!

Worthy readings:

Developing code in a team can feel like a full on campaign, as the projects goes on phases, new levels mean different ways to deal with different challenges. The party can grow and the way you collaborate changes. How to keep a smooth workflow on a evolving scenario?

Well, behold adventurers, because today we’re diving into some practical ways to polish your existing GitHub workflow and make your team’s development journey even more delightful!

Branching Out (in a Good Way!)

We all love our feature branches, right? They keep our main codebase clean and full of purpose. But have you ever felt the need to take your branching game to the next level?

• More than just main: Depending on your team’s rhythm, exploring models like Gitflow (with its develop and release branches) or the simpler GitHub Flow (deploying directly from main or short-lived branches) can bring more structure. Try exploring those, highlight their pros and cons for your team and project. It’s like choosing the right dance steps for your team – find the one that makes you groove!
  [ Ideal antidote for unstructured workflows in a small but growing team. ]

• Short and Sweet Always: Tiny, focused feature branches are a trusted allies. They’re easier to review, less likely to have merge conflicts, facilitate more frequent integration with the main codebase and generally just happier to work with.
  [ Ideal antidote for long-lived forgotten branches with way too many changes. ]

• Explore Feature Flags: This is new to me but it has the potential to be a wild magic. Imagine being able to release code to a small group of users before unleashing it on everyone. Or even being able to work on new features in their own branches and merge them into the main codebase without making the incomplete or potentially unstable feature visible to users. Feature flags are like little toggles that will allow you do just that. Combine them with your branching strategy for safer and more controlled rollouts and you get a perfectly placed on/off switch for features.
  [ Ideal antidote for coupled deployment/release cycles. ]

Pull Requests: Fancy a touch of radiance?

Pull requests are where the magic of collaboration truly happens. Let’s focus on making them more effective!

• Tell a Story: A pull request is like meeting your reviewers back at the tavern and telling them what you’ve been through on your adventure. Forget those vague “Fixes bug” descriptions, you want to tell where you went and which bug you killed. Craft pull request descriptions that explain why you made the changes, what problem they solve, and maybe even a little “how.”

• Templates Are Formulas for Success: Having a consistent pull request template ensures everyone knows what to expect during a review. Include checklists for testing, documentation updates, or any other crucial steps. Everyone loves a helpful checklist.

• Reviewing Like a Wizard: This is a longer topic but, to cut things short, code review isn’t just about catching bugs; it’s about sharing knowledge and improving code quality together.

  • Focus on the “Why”: Ask clarifying questions about the approach and methodology, not just the syntax.

  • Suggest Changes Directly: GitHub’s “suggested changes” feature is a lifesaver. It makes it super easy for authors to incorporate feedback directly avoiding ambiguity.

  • Automate the Boring Stuff: Tools like linters and static analysis can catch many common issues automatically. Integrate them with GitHub Actions to keep your codebase consistent and following the style guide, so you can skip the “line break here” type of comments.

GitHub Actions: An Automation NPC

Github Actions can also be a very attentive robot assistant! Take advantage of that on your repository.

• Further Than CI/CD: Sure, automated testing and deployment are amazing, but Actions can do so much more! Think about automatically generating documentation, updating dependencies, checking for security vulnerabilities, or even sending Slack notifications when a pull request is merged. Browse the marketplace. Maybe you can make a game out of it? The possibilities are endless!

• Small and Mighty Workflows: Elturel wasn’t built in a day! Don’t feel like you need to build huge workflows right away. Start small. Automate one repetitive task and build from there. See if it makes sense. Iterate. Every. little. bit. helps.

• Share the Knowledge! If you create a particularly useful Action, consider sharing it within your team or even with the wider community. Sharing is caring!

Teamwork Makes the Perfect Party!

Ultimately, a great GitHub workflow is about how well your team collaborates.

• Code Ownership: Who’s Responsible for this Dragon? Defining clear code ownership (using CODEOWNERS files) can streamline the review process by automatically assigning the right people to review changes in specific areas. It’s great to know the designated experts for different parts of your codebase.

• Talk it Out: Sometimes, complex changes are easier to discuss in a quick call or a pair-programming session rather than just through comments on a pull request. Don’t be afraid to hop on a call. Find the time, hash things out and summarize the discussion in a comment.

• Retrospectives: Learn From Your Encounters! Regularly reflect on your workflow as a team and have a team huddle to strategize your next move. What’s working well? What could be better? What do you dislike doing on regular basis? Use retrospectives to identify bottlenecks and experiment with new approaches. Make it periodic, consistent and structured; it keeps everyone isn the loop in the long-game.

Keep on levelling-up!

Optimizing your GitHub workflow isn’t a one-time thing; it’s an ongoing campaign. It will change according to the team and the nature of the work. Keep experimenting, keep learning, and most importantly, keep talking to your team! Find what works best for you and have fun along the way.

I feel pipeline failures are similar to unexploded WWII bombs in your DevOps workflow: they often frustrate the team, slow you down and stem from sneaky, overlooked issues.

Before rage-quitting, rm -rf an entire setup and never seeing a sweet terminal again, I got the habit to run a quick sanity check on the usual suspects.

1. The Obvious Culprit: Our Code

• Failing tests? Check the logs! Flaky tests, race conditions, or bad assertions love to sneak in.
• Syntax errors? Linters and IDE checks help, but CI systems don’t forgive typos. Mirror the pipeline linter on your IDE, hold it close.
• Dependency hell? npm install, pip, or go mod can break overnight. Lock your versions.
• New failure? Write a test for it. If something breaks in CI, it’ll break again. Capture the bug with a test now instead of future-you debugging it twice.

Quick sanity check (e.g.) :

# Reproduce locally, then lock it down with a test
pytest tests/test_fixed_bug.py -k "test_thing_that_failed_in_ci"

2. The Silent Killer: Pipeline Configs

Your .gitlab-ci.yml, Jenkinsfile, or GitHub Actions workflow might be:

• Misconfigured (indentation, wrong keys, missing steps).
• Using outdated syntax (CI tools evolve fast).
• Assuming wrong environments (“But it works on my machine!”).

Quick sanity check (e.g.) :

# Validate your configs (e.g., GitHub Actions)
gh workflow lint .github/workflows/deploy.yml

3. The Phantom Menace: Environment Variables

Secrets vs. Variables:

• Secrets (API keys, tokens) should never be hardcoded. Use your CI’s secret store.
• Configs (e.g., ENV=staging) can be plain variables but should still be version-controlled.

Common fails:

• Missing vars: Your local .env isn’t magically in CI. List required vars in your README.
• Typos: DATABASE_URL ≠ DB_URL (case sensitivity matters!).
• Scope issues: Does the variable exist in this job/stage?

Quick sanity check (e.g.) :

# Debug env vars in CI (GitHub Actions example)
- name: Log env vars
  run: printenv | sort

4. The Empire Strikes Back: Permissions

• Missing secrets? AWS keys, SSH tokens, or database URLs must exist in CI variables.
• Wrong permissions? Can your runner access the registry, repo, or deployment target?
• Resource limits? OOM kills, slow runners, or Docker rate limits can fail builds.

Quick sanity check (e.g.) :

# Debug permissions in a CI step
- name: Check AWS access
  run: aws sts get-caller-identity

5. The Hidden Time Bomb: External Dependencies

• APIs down? Tests calling https://some-unreliable-api.com will fail randomly. Mock these as much as possible without compromising your tests.
• Package registry issues? npm, PyPI, or Maven outages do break builds. Breathe. Cache if possible.
• Race conditions? Parallel jobs might conflict (e.g., DB migrations vs. tests). These deserve their own place in hell but also another chance. Quick sanity check (e.g.) :

# Retry flaky steps in GitHub Actions
- name: Test
  run: pytest
  retry-on-error: true

6. The Human Factor

• “It worked yesterday!” → Someone changed a config, test, or dependency. Check those.
• Manual hotfixes? Untracked changes in production can desync with CI. I know there’s no time to run a pipeline, run it anyway.
• Stale branches? Merging old code without rebasing = 💥. Run pipelines on every bit of code. Fail in a PR, always merge with a pass and live a happy life.

Quick sanity check (e.g.) :

# Enforce "test before merge"
git push origin HEAD --force-with-lease  # (Just kidding, don't.)

Main Quest: Make Your Pipeline Resilient

• Fail fast: Put cheap checks (lint, unit tests) early. Run pipelines as soon as you can, either on branches or PRs, avoid breaking main.
• Log everything: Debugging without logs is like fixing a car blindfolded while holding a hyperactive hamster. If a riddle appears in the form of an error message, add some logs to help the next tortured soul (might be future-you).
• Automate recovery: Auto-retry flaky steps, but always with limits.

Next time your pipeline fails, don’t panic – run this checklist. And if all else fails, blame Docker. (Kidding… mostly.)

During testing, I noticed that whenever my application received more than 4 requests at once, they would ‘wait’ and take longer to respond. The access logs looked something like this:

[2024-10-29 17:04:15] [pid-worker0] GET /io
[2024-10-29 17:04:15] [pid-worker1] GET /io
[2024-10-29 17:04:15] [pid-worker2] GET /io
[2024-10-29 17:04:15] [pid-worker3] GET /io
[2024-10-29 17:04:16] [pid-worker0] GET /io
[2024-10-29 17:04:16] [pid-worker1] GET /io
[2024-10-29 17:04:16] [pid-worker2] GET /io
[2024-10-29 17:04:16] [pid-worker3] GET /io
[2024-10-29 17:04:17] [pid-worker0] GET /io
[2024-10-29 17:04:17] [pid-worker1] GET /io
[2024-10-29 17:04:17] [pid-worker2] GET /io
[2024-10-29 17:04:17] [pid-worker3] GET /io
[2024-10-29 17:04:18] [pid-worker0] GET /io
[2024-10-29 17:04:18] [pid-worker1] GET /io
[2024-10-29 17:04:18] [pid-worker2] GET /io
[2024-10-29 17:04:18] [pid-worker3] GET /io

In this example, /io is an endpoint with an IO-bound task that took 1 second to be completed. So, sending 16 requests at once to this route, Flask would handle a batch of 4 requests concurrently, taking a total time of 4 seconds to process all of them. As you can see from the timestamps, even though all requests were sent concurrently, the request n takes ⌊n/number_workers⌋*task_time to respond.

That was happening because of two reasons:

1. Flask is by default a synchronous framework
2. Flask is based on WSGI, and WSGI uses one worker to handle one request/response cycle

I had this issue a while ago. Since then, Flask 2.0 was released with support for async views, adding a more support for asynchronous tasks. Even though I was no longer working with Flask when this feature was released, I wanted to try the new async views and experience some wild gains.

I created an async route for a similar, now asynchronous task, and the access logs looked like this:

[2024-10-29 17:37:30] [pid-worker0] GET /async-io
[2024-10-29 17:37:30] [pid-worker1] GET /async-io
[2024-10-29 17:37:30] [pid-worker2] GET /async-io
[2024-10-29 17:37:30] [pid-worker3] GET /async-io
[2024-10-29 17:37:31] [pid-worker0] GET /async-io
[2024-10-29 17:37:31] [pid-worker1] GET /async-io
[2024-10-29 17:37:31] [pid-worker3] GET /async-io
[2024-10-29 17:37:31] [pid-worker2] GET /async-io
[2024-10-29 17:37:32] [pid-worker1] GET /async-io
[2024-10-29 17:37:32] [pid-worker0] GET /async-io
[2024-10-29 17:37:32] [pid-worker2] GET /async-io
[2024-10-29 17:37:32] [pid-worker3] GET /async-io
[2024-10-29 17:37:33] [pid-worker1] GET /async-io
[2024-10-29 17:37:33] [pid-worker2] GET /async-io
[2024-10-29 17:37:33] [pid-worker3] GET /async-io
[2024-10-29 17:37:33] [pid-worker0] GET /async-io

And… it was exactly the same! It still took 4 seconds for all 16 requests to be completed.

After the initial disappointment, I looked for answers in the Flask documentation, and this very helpful performance section clarified my troubles.

Even though my request was now asynchronous, Flask is still using WSGI, which means that one worker handling one request/response cycle is still the case. The request is assigned to an available worker, if the route is an async view, Flask initializes an event loop in a thread, runs the task there, and returns the result.

Here is Worker0 processing a request to a synchronous route:

              ┌──────────────────────────┐
   Request    │        ┌───────────────┐ │
──────────────► Worker0│/io            │ │
◄─────────────┬────────┤def ...        │ │
   Response   │        └───────────────┘ │
              └──────────────────────────┘

And here is Worker1 processing a request to an asynchronous route:

              ┌──────────────────────────┐
   Request    │        ┌───────────────┐ │       ┌───────────────┐
──────────────► Worker1│/async-io      │ │       │  Event Loop   │
◄─────────────┼────────┤async def ...  ~~~~~~~~~~►   └run Task0  │
   Response   │        └────────▲──────┘ │Thread └───────────────┘
              └─────────────────┼────────┘            │
                                │                     │
                                └─────────────────────┘
                                          Result

while Worker2 is processing a request to an asynchronous route with multiple concurrent tasks:

              ┌──────────────────────────┐
   Request    │        ┌───────────────┐ │       ┌───────────────┐
──────────────► Worker2│/async-io-multi│ │       │  Event Loop   │
◄─────────────┬────────│async def ...  ~~~~~~~~~~►   └run Task0  │
   Response   │        └────────▲──────┘ │Thread │   └run Task1  │
              └─────────────────┼────────┘       └───────────────┘
                                │                     │
                                └─────────────────────┘
                                          Result

Since I had a single asynchronous task per request, the worker being idle instead of switching to other incoming requests, makes the asynchronous benefit invisible.

If my IO-bound task could be divided in multiple concurrent tasks, then I would benefit from the async view feature.

For example, a scenario where you need to fetch data from multiple external APIs for a single request. If each API call takes 1 second and if you handle them either synchronously or asynchronously, your app might take several seconds to respond. But, if you split those requests into smaller concurrent tasks using async views, those can handled in parallel and respond much quicker.

With that in mind, I created another route to try that out, and the access logs for this case looked like:

[2024-10-29 18:14:15] [pid-worker0] GET /async-io-multi
[2024-10-29 18:14:15] [pid-worker1] GET /async-io-multi
[2024-10-29 18:14:15] [pid-worker2] GET /async-io-multi
[2024-10-29 18:14:15] [pid-worker3] GET /async-io-multi
[2024-10-29 18:14:15] [pid-worker0] GET /async-io-multi
[2024-10-29 18:14:15] [pid-worker1] GET /async-io-multi
[2024-10-29 18:14:15] [pid-worker2] GET /async-io-multi
[2024-10-29 18:14:15] [pid-worker3] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker0] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker1] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker2] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker3] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker0] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker1] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker2] GET /async-io-multi
[2024-10-29 18:14:16] [pid-worker3] GET /async-io-multi

As you can see, dividing the task into two concurrent tasks, each taking 0.5 seconds, and using the same 4 workers. It processed 16 requests in 2 seconds, giving a 2x speed-up. In similar fashion, the request n for multiple concurrent tasks takes ⌊n/number_workers⌋*slowest_task_time to return. If the task workload could be divided in even more tasks, there would be a benefit as well.

The real limitation lies with WSGI, which ties one worker to a request, limiting throughput due to the lack of an asynchronous request stack. An alternative, implemented by other fully asynchronous interfaces like ASGI, allows workers to handle multiple concurrent requests at once. Where, when an asynchronous task is blocked waiting for an IO-Bound operation, the worker can immediately switch to another request, optimizing resource usage and reducing latency. This approach favours frameworks based on ASGI, FastAPI for example.

To be able to visualize that, here’s a simple comparison of response times for 100 requests to each framework, both using 4 workers, with the same tasks and similar routes based on the previous examples:

As you can see, FastAPI consistently performs better due to its ASGI foundation, while Flask’s async views still face limitations due to WSGI. FastAPI, in comparison to Flask, the synchronous endpoint /io is already blazing fast, taking less than 10% of the time Flask takes.

On the asynchronous endpoint with a single task /async-io, FastAPI is almost twice as fast than its own synchronous-self, and for the asychronous with multiple concurrent tasks /async-io-multi FastAPI is again almost twice as fast than its single-task-self.

Indeed, async is not inherently faster than sync code, even in a strictly IO-bound context and, that’s specially true with Flask. Between all considerations, Flask does offer an interface for multiple concurrent IO-bound tasks, in which can be useful if you are able to subdivide your tasks in smaller chunks and optimize a few endpoints that are being slow. However, if you are doing mainly asynchronous tasks, it’s worth considering other ASGI based frameworks.

Both frameworks were run with 4 workers, using Gunicorn as the WSGI server for Flask and Uvicorn as the ASGI server for FastAPI;

You can find the code for this post on GitHub.

As we know, the regular rise and fall of sea levels are caused primarily by the gravitational pull of the moon and, to a lesser extent, the sun. The moon’s gravity exerts a force on Earth, pulling water towards it. This pull creates a bulge in the ocean, resulting in high tide.

Interestingly, the moon’s phases also impact the strength of the tides. During a full moon and new moon, the sun, moon, and Earth align, leading to what are known as “spring tides.” These tides are characterized by higher high tides and lower low tides, resulting in a more significant difference between high and low water levels.

However, when you look at the line in a tide chart, it can hardly make you think about the moon or its current phase. This visualization is an attempt to show the gravitational force of the moon orchestrating the rhythmic dance of the tides—an alternate way to see our very distant neighbor relating to us in our everyday lives.

Check it out here. Fullscreen recommended! 🌝

This was made with PixiJS. I drew each individual moon phase with a cutout, varying the radius of each moon phase according to a fictional “tide level.” You can find the source code here.🌚

This small visual project is the first in a series (at least I hope it will be!) under the umbrella of experiments that I now call “Visual Catalog”. Several years after SensePi, I wanted to continue doing similar experiments. Not being quite sure of where this is going is part of the destination, and I expect it to lead me through several rounds of short explorations in a similar vein.

At the initial sketch, I wanted the app to:

• display the current location;
• provide a quick glimpse of the weather conditions and temperature;
• offer a short description of how the day might feel for me;
• show wind and humidity levels;
• include a forecast for the next few hours;
• highlight any potential hazards, like ice and snow.

I kept the layout minimal and a bit boring —just enough information to help me decide whether it was a good day to head out. I didn’t want too much data or too many details. I was after something that would be quick to read and would make the decision easier, not harder. The least straightforward logic was the helper text, I wanted a single sentence to remind me how I personally feel under those conditions.

For the design, I kept it simple: just two contrasting colors, a technical font with a bit of roughness to it, and simple, outlined icons.

I ended up using OpenWeather to pull the essential weather data, as it’s accurate enough for my use case. The app itself was built with TypeScript, and I wanted to give Next.js another try. The middleware was useful for data fetching, and deploying with Vercel was straightforward. For the “next few hours” line graph, I used Airbnb’s visx/curve, which had the exact look and shape I was going for, and was easy to use.

The final(current) version and my initial lousy sketch

You can check it out or install the app here. The source code is available on github.

This app was made in less than a week in February, and I’ve been using it ever since, it’s simple and it gets me out there. While I could add more detailed information, I’ve realized that too much data just leads to overthinking. After all, I’m not looking for perfect weather; I’m just looking for a window when it’s good enough to get outside.

Living in Scotland, you quickly realize that the “perfect” time to get out is a myth. The perfect time to get out is the time you do get out, with the right precautions in place to not get caught in a sticky situation.

That said, I’m considering adding a feature highlighting visibility and sunset times, especially for the months when the sun is setting quickly and earlier. This could be useful for planning when the sunsets overlaps with the “next few hours” forecast.

Overall, Fairweather has been exactly what I needed. It does just enough to help me get outside without overwhelming me with unnecessary data. It’s not a fancy weather app—it’s a no-frills way to get a quick snapshot of the weather and make a decision about getting out. And for now, that’s all I need.

Of course you can try yourself by opening your terminal and carefully typing:

$ curl hypntd.belinhacbr.xyz

You should be able to see something like this:

– ALL THE GLORY TO THE HYPNOTOAD!!! 🐸

Check it out here. If you need some help, just tell me.