DEV Community: Pooyan Razian

#1 GitHub Ninja goolakh contributor in Armenia!

Pooyan Razian — Fri, 07 Aug 2026 07:30:44 +0000

Big news.

committers.top says I'm the #1 public GitHub contributor in Armenia. 🏆

Hold the applause. Hold the job offers. Hold the "do you even sleep?" questions. (Sometimes. In theory.)

committers.top, Armenia public contributors

Managers: you found a unicorn. A legend. A goolakh force of nature. Stop reading. Send LinkedIn DM: "Need 10x ninja ASAP."

Developers: hi. Inside joke time. Grab coffee. ☕

Certified goolakh ninja 💪
Path to 10x goolakh-ness
Am I a goolakh ninja now?
The #1 badge is real (sort of)
Dashboards vs reality
The goolakh secret: automation
Note to hiring managers
Secret truth 👇
More reading

Certified goolakh ninja 💪

I am a "certified" 10x code Ninja goolakh software developer.

Proof on GitHub: the blockchain of developer ego (everyone can fork your delusions):

github.com/prazian/how_to_become_10x_developer

Absolute 10x code ninja

Not satire.

Okay, satire.

Enterprise-grade satire. Counts in 2026.

Path to 10x goolakh-ness

Official curriculum:

No docs. (Job security max!)
No tests. Prod only.
No knowledge sharing. Ever.
No life. Code on holidays.
Messy git history? Who cares.
More LOC = more metrics.
"Yes boss!" to every Scrum Master.
Memorize syntax. Type fast.
Commit. Commit. Pushhhhhh.

More commits = more money. Science. Same science as horoscopes and quarterly OKRs.

"But 10x0 = 0!" Sure. But 0x10 = 16 = 2x Pizza Team Developer. 🍕🍕

Feel like 10x0=0 today? Reorder the operands. Management loves that.

Am I a goolakh ninja now?

Yes. No. Both.

Depends who asks, and if they know what git push means.

The #1 badge is real (sort of)

committers.top counts public GitHub activity. Not a joke.

What's funny/sad is how people read it:

Managers: "Ships non-stop. Hire now."
Devs: "Ah. Bots, CI, deps, automation, one typo fix at 2am."

Both valid. One group reads the diff.

Dashboards vs reality

Shiny badge. Shinier 10x cert. Uncomfortable truth:

Dashboards love	Teams need
Commits	Impact
LOC added	Problems removed
Story points	Value
PR count	Fewer PRs
"Velocity"	Sustainable pace
Hours online	Hours saved by automation

Vanity metrics = easy.

Real engineering = hard to slide-deck. Did we:

Kill toil?
Automate boring stuff?
Make things safer?
Help another dev ship faster?
Delete code?

Deleting code doesn't rank on leaderboards. Tragic.

The goolakh secret: automation

High on the chart ≠ typing like a caffeinated piano player.

Deep allergy to doing the same thing twice.

CI. Lint. Tests. Release scripts. Small bots. Sensible commits. Tools do tedious work; humans think.

That's the real multiplier.

Not 10x mythology. Not hero culture. Not weekend martyrdom.

Automation + consistency + code the next person can read (yes, docs, sorry 10x gospel).

Want busy-looking team? Count commits.

Want forward-moving team? Count outcomes.

Note to hiring managers

Big number on a leaderboard? Ask one thing before the "rescue our 47 microservices" email:

Maybe:

Automated half the release ✅
400 bot dependency PRs ✅
Force-pushed main 12x on Friday ❌ (different genre)

All look "active" from far away. One actually helps.

Secret truth 👇

You scrolled for the punchline. Here it is:

Don't rank by commits.
Don't rank by LOC.
Impact > quantity.
Quality is hard to measure, so lazy dashboards pick quantity.
Quantity can be faked.

Proud to build from Armenia. Happy if public activity nudges others to ship, share, automate.

Just not the "no tests, no docs, push prod" part. That bit is a joke.

Someone will quote it in a perf review without reading the rest. I had to say it.

Ops Ops everywhere

Pooyan Razian — Thu, 06 Aug 2026 07:30:45 +0000

Give a term like "system administrator" to the marketing-loving, "buzzword-loving" non-technical managers; then you'll get:

#DevOps
#DevSecOps
#GitOps
#AIOps
#MLOps
#LLMOps
#PlatformOps
#CloudOps
#DataOps
#FinOps
#SecOps
#NetOps
#SysOps
#ITOps

... and even #NoOps 🤣

wow

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

The age of AI and the rise of addicted digital sheep

Pooyan Razian — Wed, 05 Aug 2026 07:30:45 +0000

Most people have traded independent thought for endless scrolling.

Just because social media rewards polished fiction over substance...

A quick dopamine hit...

But people with real ideas? Those who read, think, and challenge all these new engineered "norms"? Those who can guide societies to free themselves from modern slavary? Ignored by the majority of f**ls who prefer the constant stream of shallow entertainment; like a bunch of drug addicts, who'll end up on the side of a shallow joooogh...

A Persian proverb, translated into English, says: "If you don't want to be disgraced, become the color of the crowd"; a poetic indirect criticism of conformity. Most people have followed this path throughout history, and they still do today. The crowd keeps applauding distractions while ignoring those who could actually make a difference.

Age of Artificial Intelligence and human stup*dity.

The rise of addicted digital sheep...

Sheep? Feeling insulted?

Okay then, next time you take a bus, go to a concert, or sit near people at a clinic wating to see the doctor, look around and see their faces: all heads down, looking at their phones, some laughing weiredly like psychopaths...

Sheeps also, heads down, all moving the same way, and not even one of them asking why...

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

AI vs philosophers of the 21st century

Pooyan Razian — Tue, 04 Aug 2026 07:30:45 +0000

Software development used to be fun when we had the chance to think, make mistakes, and learn from them...

Now, it's just "AI AI AI" and it feels like we are back to those "Wordpress developers" jokes or the generation of "drag-and-drop experts" that Adobe/salesforce/Microsoft created for us in the past 25 years...

I used to say "programmers are the philosophers of the 21st century" because we don't "just code"

Understanding the needs and building a solution is like writing a poem; writing code is like "speaking a language"

That's why, for example, Linux was built to solve specific types of problems in a way that most people used to call "stupid and difficult" but turned out to become the backbone of the internet

Everyone can "learn to speak a language"

AI can "write code"

Yes,

But the philosophy behind things?

That's why we need more people who have the balls to criticize things in strategic positions, but unfortunately, those are filled with managers who have no idea... Mostly, a bunch of apple polishers who tend to only satisfy their higher-level managers.

We need open-minded people in these fields who are brave enough to challenge things so that the philosophies behind things can mature, instead of those who follow hypes: one day, oh let's use k8s k8s k8s for everything, next day, oh blockchain blockchain blochchain, and now oh AI AI AI ¯\_(ツ)_/¯

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Quiet browsing? Tabby keeps you company

Pooyan Razian — Mon, 03 Aug 2026 07:30:45 +0000

Long stretches in the browser can feel oddly empty. You hop from a recipe blog to your notes, then a news site, and the only company is more tabs. Students grinding through research, remote workers between calls, and anyone who lives in Chrome know that quiet.

Tabby is a free, open-source Google Chrome extension I built for that. She is a virtual pet cat who floats on the pages you visit, reacts from the tab title and web address only, and grows from a newborn kitten into an adult cat over real calendar days. Pet her, feed her, play with her. Everything stays on your device: no account, no cloud, no data sent anywhere.

Install from the Chrome Web Store · Source on GitHub

Who is it for?
How to use it
What makes her different
Privacy
Open source

Who is it for?

Anyone who wants a gentle companion while browsing
Remote workers and students who spend hours in tabs
Cat lovers who want something fun that still respects privacy

How to use it

1. Meet Tabby

Install Tabby and open any page. On first install she appears in the bottom-left with a short three-step tour: who she is, that she stays local, and how to feed or play with her.

Tap Next to walk through, Got it on the last step, or I already know Tabby to skip. Skip keeps her on screen and quiet. She does not read page text.

First-meeting tour on a page

2. Browse with Tabby

Drag her anywhere. She is a Lottie-animated cat with gold eyes and a purple collar.

Most of the time she stays out of the way. Now and then she may peek in from the edge, say a quiet line, or ask for food when she is hungry. Tap × on the bubble to dismiss speech without opening the menu.

Tabby asking for food while you browse

Her mood can shift gently after you stay on a page for about a minute. She never reads what is on the page, only the tab title and web address.

3. Tap Tabby to interact

Click the cat to open her care menu. Pick Pet, Play, Feed Tabby, or What's up? Her reply appears in a speech bubble.

Tap More for do not disturb (30 minutes, 1 hour, or until end of today) or hide her on this page.

Care menu and speech after petting

When she is hungry, feeding starts a short munching moment. Play can turn into a wild paw moment with jokes.

Feeding moment

4. Open settings

Click the Tabby icon in the toolbar.

Do not disturb hides her on every tab until the timer ends. Tabby on your page lets you show or hide her on this tab or on all tabs.

Settings: do not disturb, visibility, quiet hours

Quiet hours keep unprompted speech off at night. When Tabby speaks up sets how often she may check in while you browse.

Settings: privacy and speech limits

That's it. Meet her once, browse, tap to care, open the toolbar for settings.

What makes her different

Floating companion you can drag anywhere on the page
Moods and needs: hungry, happy, stressed, sleepy, and more
Three life stages: newborn kitten, playful kitten, then adult cat
Memories: places you visit together can echo back in what she says later
Show / hide per page, on every page, or do not disturb for a while

Privacy

Tabby uses only the active tab's title and URL. She never reads page text, never looks through your history, and never sends data anywhere. Permissions are tabs, storage, alarms, and scripting. No host permissions. No backend. State lives in IndexedDB and chrome.storage.local on your device.

Open source

MIT licensed. Built with WXT, TypeScript, Lottie animations, and Vitest. Full tutorial: tutorial on GitHub.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

To test or not to test, "How" is the question!

Pooyan Razian — Sun, 02 Aug 2026 07:30:45 +0000

Have you ever joined a project without test coverage and wanted to add a new feature or fix a bug? Then, you spent some time, committed the fix, and deployed. Amazing! Five minutes later, bam, ten more bugs!
If you've experienced that, you're not alone! In this session, I will explain various types of testing, both for your application layer and infrastructure, and how they can help your tech staff understand what you have and reduce the risk of change.
Then, we will dive into writing fast-enough isolated automated integration tests with the help of containers without the need to spin up a long-lasting shared test environment.

Event details can be found on the 3C's Meetup page.

Note: Recording and the presentation (PDF) are available at the end of this article.
👇

Article
1. Why Test
2. Our First Test
3. Types of Tests
4. Common Problems
5. Can Containers Help
The event
Recording (YouTube)

Article

Today, I'm going to tell you a story to explain why we need tests. Hopefully, by the end of this story, it will
illuminate a path in front of you. After that, we will "write" our first test, and then I will share with you
different types of tests and some common problems in this area. Finally, we will see if containers can help!

1. Why Test

Let's begin with a story about a hypothetical company named "AmazingLargeCorporate.com," where Lisa is an engineering manager. A while ago, she hired Peter as a programmer. A few days after Peter joined the company, he received his first task: to give all customers a 10% discount!

Like many of us, he was curious, so he dived into the code. After a bit, he found this order class and the "calculateTotalPrice" method. It simply goes through all the items in the basket, gets the price for each, and multiplies it by the number of items in the basket. Then, it sums to calculate the total price. Then he says, "Maybe that's where I should add the discount!"

The code that Peter changed

So, he directly adds the "discount logic" there, commits the code, pushes his changes to the repository, and, with
their existing simple CI/CD pipeline, this new change goes directly to production!

He is happy! His manager is happy, and everyone is happy!

The simple CI/CD pipeline

A few days later, Lisa shows up in front of his desk and says, "Tax calculations are incorrect! Finance asked me
why suddenly we are calculating gross revenue based on the discounted amount instead of the original value!?!
By the way, popular items should never be discounted!
Now, we also want to give different types of discounts!"

Peter looks into the code again and finds this "Item class". Of course, naming is difficult! 🙃
Then he finds this getter method for price and says maybe this is where I should do something! Or I don't know.
Maybe I should add a global configuration or something.
Uh, I remember from school time that we had these "design patterns".
Can I use any of these patterns to give different types of discounts?
Maybe the strategy pattern? Who knows!

The item class

He looks further into the code and finds the "Invoice class." There, he finds a method to calculate tax.
It uses the same method to calculate the tax based on the discounted amount!

The invoice class

He looks further, finds this "Analytics class," and then finds this "recordOrder" method.
As you can see, we calculate the revenue difference based on the exact same method that he himself changed to
return the discounted amount!

The analytics class

He thinks out loud again and says, maybe I should revert the previous one back and probably create another method.
But still... How can I give different types of discounts!? He starts coding again.
Pushing to production... Finding another error. Again, fixing it!
Finding another error! Fixing it! Pushing it to production...

Debugging in production

If this sounds familiar to you, you're not alone!
In fact, if you have even checked your LinkedIn profiles around the 20th of July this year (2024), you have probably
seen everyone talking about this Blue Screen of Death, caused by just a few lines of code, in an update that
CloudStrike pushed to their customers globally—an update that caused hundreds of million dollars of loss!

You are not alone

2. Our First Test

Now that we know why testing is essential let's see if we can write our first test. Imagine you join a gaming company, and your first task is to create a test for their arcade game named RamboCats!

Rambo Cats

In this arcade game, you have a builder method (builder method to build a bodybuilder cat 😅) to create
different creatures based on the parameters you pass to it. Now, you want to ensure that it "builds" cats correctly.

Then you start thinking, "What is a cat?"
A cat is an object that has two eyes, one nose, and whiskers. Right?

So, you write your test and say whatever has two eyes, one nose, and whiskers is a cat. Your test correctly asserts
that these three cats are cats because they pass all the criteria. These two men are not cats because they
don't have whiskers.

Congratulations! You wrote your first test.

Rambo Cats - condition

Then, you think a bit more and say,
"Okay, but if whatever with two eyes, one nose, and whiskers is a cat, then this seal is also a cat!" Right?
It has two eyes, one nose, and whiskers.

That means your test will assume this white seal is also a cat! Which is incorrect.

Rambo Cats

3. Types of Tests

Let's see what type of options we have for testing software.
We have two general categories:

Functional testing
Non-functional testing

Let's begin with 1. functional testing.

Functional testing checks the application's processes against a set of requirements or specifications.
This is what people usually call "test".

Functional testing

The main types of functional testing are unit tests, integration tests, and end-to-end tests. Unit test is usually
called "the test"! Some folks even say, "I have written some unit tests," while they just meant some tests in general.
With unit tests, you check individual and small parts of your code to ensure they work how they are supposed to.
End-to-end testing, conversely, ensures that the entire system does what it is supposed to do. For example, if I buy
something from your store, you get your money, and I get my item. Also, if I look at my order history a few months
later, I should see that specific order there.

Integration testing is something between these two. You don't need to test the whole system; you don't just want to
test a small part of your code. You want to see if these small parts can work together. For example, you might have
an API and want to see when it is called with this payload; it creates this item in the database, and when it is
called with another payload, it deletes it.

As it sounds, end-to-end testing is much more complex than unit tests because you need to have the whole system up
and running.
That means you have to spend a lot of resources and prepare the system in the state that every single test wants it to be.
You don't have to prepare the whole system for the integration testing, but you still need to run a few parts of it.

Imagine you want to check if an API responds with a 200 HTTP code when called with this payload, 201 with another HTTP
verb, and 401 when the user is unauthorized. On top of that, you also want to see if it creates/deletes an item in the
database or if it will block the user when she is unauthorized. That means, in the integration test, depending on what
you test, sometimes you consider the system as a black box and check the interface. On the other hand, sometimes you
want to check if something has changed in the database, message bus, etc.

We also have UI testing. If you have a web application, a mobile application, or even a system that sends marketing
emails, you want to see not only how they look but also how they function when someone presses a button, etc.

Now, you might say, "Okay, but how many of these tests should I have?!"

This is not set in stone, but if you think about it as a business, you don't want to spend too much time/money/resources
on something that will not bring much back to you. Remember, time is money, and complexity needs time.
So, as a general practice, most projects end up having a lot of unit tests, a few integration tests, and fewer E2E and UI tests.

Okay, now how to run these tests?

You need to know what is happening in your system for the unit and integration tests, so your tooling depends on your
programming language. For E2E and UI testing, you don't care about the program language. All you care is that if I
press on this button or call this API this way, blah blah workflow will be triggered or not. So you use automation
tools like Selenium, Playwright, etc.

You can also manually test your APIs using Wget if you are a CLI geek or Postman if you prefer a nice UI. This way,
you can also "kind of automate" them.

Good news! Even though we talked about software, you can treat your infrastructure definition as software if you use the
new generation of Infrastructure as Code, which is called Infrastructure as Software, like CDK or Pulumi.
Then, you can write unit tests, snapshot tests, etc., to ensure your infrastructure is created how you expect it to be.

In the talk, I asked the audience to answer a poll about what types of testing they have in their projects.
The result is as follows:

Survey result

Now that we know, at least two or three people write unit tests without integration tests...

Next time you write a unit test and think we don't need integration tests, remember this:

Your browser does not support the video tag.

Other types of functional testing:

- Sanity test (Smoke testing)

Smoke testing is a quick test to see if the application can be built and run after each small change.
We do this to quickly check if these small changes don't break the whole thing.

- Regression testing

Regression testing ensures that when you fix a bug, you don't open another one.

- Beta/User Acceptance testing (UAT)

We also have UAT testing. You send your application to a limited number of either users or testers to hopefully test
everything.
This is a bit tricky because a limited number of users/testers might be unable to test every single scenario that
everyone using your application will face.

- Data Race detection & concurrency testing

Your code might have data race issues in programming languages that support concurrency, like Go.
What is data race?
Data race happens when you have a variable that two different threads have write access to, and accessing it needs to
be sequenced.
For example, imagine having an integer variable shared between two threads.
The first thread reads the value, which is 4, and then adds 1. It becomes 5. Then it writes 5 to it.
The second thread reads the value simultaneously, which is still 4, and then adds 1.
It becomes 5. Then it writes 5 to it. Now, instead of 6, we got 5.

Data Race

Input strategies

Example-based testing is basically what we usually call "testing"! It is when we provide a pre-defined input and assert
that blah blah will happen.

In addition, we have random testing, hypothesis testing, and property-based testing. For example, if my API accepts an
email address or first name, instead of providing my name and email address, I use a faker that randomly gives a name,
email, etc.
I can configure it to provide values from different locales and see if something fails.

Input strategies

I used to think this was redundant, and no one needed it until it showed me cases I'd never even considered!
This can help you find edge cases that you might not have thought about before they happen in production.
These kinds of tests are usually used to avoid our biases in choosing test data.

Now, 2. Non-Functional testing.

Non-functional tests asses the application properties that aren't critical to the functionality but contribute to the
end-user experience.
What it means is that your system works fine, probably even with no errors!, while your end-users are crying!
These tests reduce the chance of this happening.

What it means is that, your system works fine with no error, but your users are crying!
These tests, reduce the chance of this happening.

We have one big category of "reliability under load" that checks if your solution works well under expected, unexpected,
or peak load over a short period or an extended period.

Reliability under load

We also have security testing, usability testing, compatibility testing, and other related activities.
For example, we use static code analysis to determine whether the application's codebase is vulnerable or whether
the infrastructure definition exposes security issues.

Other non-functional tests

4. Common Problems

Now that we have discussed the different types of testing, let's examine the common problems. If you have worked with legacy code, you know how difficult it is to test a legacy system—especially if it is from the Dinosaur era of the 1990s! Because there was no framework to help automate tests back then.

So, now you say I'm happy that we live in the modern era! Right? But testing modern software architecture is also hard! Why?

Even though we have all these tools, the problem is that with the new types of distributed architectures, instead
of just testing one system, we have to check different parts of the whole solution.

For example, what if something goes wrong with the message bus? Or what if the message queue sends the same message
multiple times? Can my software handle it idempotently? What if it sends the messages in a different order?
What if we have one request to block all transactions from this malicious user and another one to command giving
away $1 million? Will it give the $1 million first and then block? Or will it wait to receive the previous message
first?

We also have challenges with eventual consistency in modern, scalable databases. For example, what if I use DynamoDB
and my application writes into it? When 4 out of 6 nodes write the data, it says, "Okay, I'm done!" But then you
read it, and it's not there!

Thanks to "Agile" and hundreds of misunderstandings around "Scrum," we usually have rapid changes in the
requirements, which leads to a high volume of taste maintenance. When you write a test, you have to maintain it like
you maintain your code. So, every time the logic changes, you have to check all your related unit tests, integration
tests, etc., and update them all. Imagine this happens 10 times a month!

This usually happens because, unfortunately, many non-technical managers see Agile as "fast, fast, fast" -- which is
incorrect! Agile is about being able to adapt to changes, not about being fast by constantly making random changes!

It is also difficult to test nonfunctional requirements.

For example, what is secure? I might say this beautiful app is highly secure because I cannot hack into it, but will
a hacker say the same? So, how can I say I've tested it to be safe? Also, I might check an application and say this
one works fine when five users work with it, so I can say that it is highly scalable! Five users!
On the other hand, should your application from a newly established startup be able to scale up to the Google level?
So, what is scalability? How many users should it be able to serve, and with what response time?

It is also difficult to provide data for all these different scenarios. For each test, I should probably change the
requester user, the system state, etc.

Test coverage is also a big question. Should I aim for a 100% test coverage? How many happy and unhappy paths should
I cover? Still, can I be 100% confident that nothing will go wrong?

Flaky tests are also a big problem. If a test sometimes passes and sometimes fails, you cannot trust it. This
usually happens when your tests depend on a third-party system or its APIs.

Inconsistency between environments is also a big problem. For example, my tests pass in Dev and Staging, but the
whole solution fails in production! Why? I created a new IAM role in my Dev and Staging environments, but I could
not do it in production as I didn't have access and we didn't have Infrastructure as Code.

Tests can also potentially affect each other. This happens when you use a shared environment and multiple tests run
in parallel.

Over-reliance on unit tests and avoiding other types of tests is also a problem, especially when non-technical
managers push teams to skip them with excuses like "we don't have time or resources."

Also, it is quite common for folks to skip a test when it fails the shared pipeline.
What if we forget to add it back?

No test meme

So, shall we avoid testing?
Then, we are back to the first step! 😏

5. Can Containers Help

Let's see if containers can help! Now, imagine you have joined a company and you own this "my service" service and the database it has. You also have a few downstream services, for example, another service, a message bus, and a few AWS services like S3 for object storage.

You need all these resources in your local environment and for your integration tests.

What are the challenges?

Before running tests, you have to run an environment. You have to ensure it is up and running and everything is
pre-configured in a desired state. What user should be presented in the database? What order should exist in the
database, etc.

We should also avoid non-deterministic tests, data corruption, and configuration drift.

One common way is to use a shared environment (UAT, test, etc.), but the problem with non-deterministic tests still
exists.

A better alternative is to run your test in separate Docker containers so that you will have reliable and repeatable
tests. That means that every time you run your tests in the "setup" phase, it will start all the downstream services
for you, configure them, initialize data, and make everything ready for your test to run. Then, it will run the test
and clean up everything. That means you will create an isolated environment on-demand, so you will have consistent
experience everywhere. Locally, in the CI, or even someone else's machine! Also, you probably want to run these
tests in parallel, so your tooling should be able to assign different random ports to these containers and wait for
them to be ready.
Note that if you use share containers, you will still have the same problem as running your tests in any other
shared environments.

These tools should also be able to automatically clean up; otherwise, you will end up with many containers staying
up and running on my machine after each test, wasting your resources!

Container test workflow

As far as I'm aware, in 2024, we have two options: DockerTest and TestContainers.
Dockertest is Golang-specific, while test containers are the new ones and support many different programming
languages.

Let's talk again about the hypothetical company "AmazingLargeCorporate.com". Like many other companies, they started
with a monolith solution with Java. Why Java? Because it has a fantastic ecosystem and is an OOP language. Then,
with the hype of microservices, they eventually changed their architecture, but still with Java. Why? Because they
were a Java company. But builds were too slow, and now they had the complexity in each of their services and the
distribution! So, they said, "Okay, let's try Golang!" Peter put on his Go hat and built a few services.

Java to Golang

Then, he wanted to add integration tests. He used Dockertest, added random ports to different services at the setup stage, and then ran the test. Then, he wrote his tests in a Table-driven way, so he could run the same test under different conditions.

He ended up with a large CI/CD pipeline in which he tested everything.
If you are interested in reading more about CI/CD Pipeline Best Practices, check out this article.

Big pipeline

What options do I have?

Currently, in 2024, you have two options: DockerTest and TestContainers.

Options comparison

Thank you!

Thank you for reading all the way through!
If you liked the talk or this article, please share it with your friends and colleagues. If you have any questions
or feedback,
please feel free to connect and reach out to me on LinkedIn.

Who am I?

I'm a programmer and a Solution Architect consultant at my current employer.

This is my face when I debug my code!

That's my laser, but sometimes it doesn't work...

About me

I'm a curious person who happens to like hiking, especially hiking above the clouds!
That's probably why I chose to work with the Cloud!

I love Linux and support the GNU and open-source movements.
I've been a programmer for many years, working with different programming languages, including, but not limited to,
Python, typescript, and Golang.
I've been working with AWS Cloud for 5-6 years now.

Before then, a long long long time ago, I used to be a Linux admin. I'm' one of those lucky guys who could go to a
Data Center and see what's happening there, which is something I'm very proud of.

These days, I'm more of a Hands-On Solutions Architect.
I join different projects to see what the problem is (hopefully 😀), come up with a few possible Solutions, and help
the client by building PoCs, evaluating different options, and then helping them implement the solution.
I draw architectural diagrams, but that's not the only thing I do.

If you are interested in learning more about me, please check out my portfolio at
pooyan.info.

The event

How the event looked like

Recording (YouTube)

Presentation file (PDF)

If the file is not loaded here, please check out this post on my LinkedIn.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Cloud vendor lock-in! How much should I be scared of? 😱

Pooyan Razian — Sat, 01 Aug 2026 07:30:44 +0000

What is vendor lock-in?
Some examples?
Why this approach is dangerous?
Vendor lock-in only in choosing the public cloud provider?
What should I do then?

What is vendor lock-in?

Vendor lock-in refers to a situation where an organization becomes overly dependent on a specific vendor's products or services, making switching to alternatives costly, time-consuming, or technically difficult.

Over the years, many companies have experienced frustration when trying to move away from large vendors like IBM, Microsoft, or Oracle due to contractual constraints, proprietary technologies, and sudden pricing changes.

A recent example is VMware's acquisition by Broadcom, followed by significant pricing changes that disrupted many businesses.

Some examples?

In startup environments, it's common to hear voices urging multi-cloud strategies or insisting on only using "cloud-agnostic" tools to avoid a potential lock-in that might never materialize. Some even advocate picking tools that must remain relevant for the next 10–20 years—a nearly impossible task. 🙃

Here are some example you too might have heard:

Self-managed Kubernetes

Some teams insist on managing their own Kubernetes clusters because:

"Big companies use Kubernetes", so we should too.
It's open-source.
We should be cloud-agnostic and avoid vendor lock-in at all costs.
Se-managed appears to be cheaper than using a managed alternative.

While these reasons seem valid on the surface, managing Kubernetes introduces significant operational complexity.

Cloud providers offer fully managed services like Amazon EKS, Google GKE, Azure AKS, or even serverless options like AWS Fargate, which significantly reduce this burden. But still, some prefer self-hosting just to avoid a perceived lock-in. 🫠

Let's build our "own" datacenter!

Although less common today, some businesses still believe running on-premises is more cost-effective and provides more control. Reasons typically include:

Public cloud is too expensive compared to owning hardware.
"Once you're in the cloud, you're stuck."
Physically owning the infrastructure seems safer.
Fear of cloud providers "stealing" their ideas. 😂

Recently, influencers like David Heinemeier promote the idea of "let's build our own datacenters" by focusing only on hardware costs. But building and maintaining a datacenter requires considering total cost of ownership (TCO), which includes staffing, the knowledge that is not common anymore, upgrades, security, including physical security, availability, and much more.

We should only use open-source!

Open-source software has been a major driver of innovation and collaboration. It enables transparency, reusability, and often better security insights. However, an overcommitment to open-source can sometimes prevent teams from using excellent managed solutions just because they're proprietary. I'm a big fan of OSS, so don't get me wrong.

For example, preferring PostgreSQL or MySQL over managed solutions like Amazon RDS or Google Cloud SQL might lead to higher operational overhead, especially for teams without strong DevOps support.

Why this approach is dangerous?

Making strategic tech decisions based solely on the fear of vendor lock-in often leads to unnecessary complexity.
Imagine building software without any libraries or frameworks because they're "opinionated." That logic, if taken to the extreme, leads to teams reinventing the wheel while convincing themselves their startup is building something truly unique.
Some leaders boast about being "cloud-portable" and ready to switch providers overnight. In theory, that sounds great. In practice, it's a costly abstraction.

All decisions in engineering are trade-offs:

Should you master multiple programming languages to be vendor-agnostic or pick one that fits your use case well?

Is it practical to use a universal ORM for every database engine or choose one tailored to your stack?

Does it make sense to pay cloud providers for managing repetitive operational tasks?

Is simplicity more valuable than the power of customization and flexibility?

Do you really need every advanced feature of a tool or only a reliable subset?

Is it wise to invest team time in debugging and maintaining infrastructure?

Vendor lock-in only in choosing the public cloud provider?

Vendor lock-in isn't limited to cloud providers. The moment you select a programming language, framework, database, or third-party service, you are accepting a level of dependency.
The more deeply you integrate a technology, the harder it becomes to replace.

You may find yourself locked into:

– A specific programming language.

– A database with custom schemas and stored procedures. (DB? logic? Hmm...)

– Custom internal platforms built by someone who left last year. OOPS! We have no documentation either.

– Third-party services for billing, auth, or analytics.

Cloud providers are just one among many dependencies. The key is to choose wisely and be deliberate—not paralyzed by hypothetical future migrations.

What should I do then?

Aim for pragmatic simplicity. Embrace managed services where they make sense, and minimize complexity where possible. The real danger isn't vendor lock-in—it's complexity lock-in.

Combining too many tools or customizing every layer of your stack increases system entropy. Over time, the culture of "don't touch it, it works" takes hold. Eventually, systems become so convoluted that nobody understands them—let alone migrates them.

Stay flexible, stay curious—but don't fear lock-in so much that you lock yourself into choosing over-engineering complexity (when it is not needed yet) or indecision.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Have ADHD? Try Why Am I Here

Pooyan Razian — Fri, 31 Jul 2026 07:30:44 +0000

You open Chrome to look up AWS pricing. Twenty minutes later you are on Reddit, email, and three unrelated tabs. Or the opposite: you stay on topic, but suddenly you have 40 AWS tabs open and no idea what you came for. Developers, students, and researchers know both patterns. People with ADHD know them especially well.

Why Am I Here? is a free, open-source Google Chrome extension I built to help. Set a goal in the popup, browse normally, and get a gentle nudge when you drift off task or stay on topic too long. No blocking, no shame, no system notifications. Just a ! badge on the icon and a check-in in the popup.

Install from the Chrome Web Store · Source on GitHub

Two problems, two nudges
How to use it
Privacy
Important disclaimer
Open source
Related research

Two problems, two nudges

Problem	What it feels like	What the extension does
Distraction	You came for AWS pricing but ended up on random tabs	Focus nudge when off-goal time adds up and off-goal tabs outnumber on-goal ones
Rabbit hole	You are on topic but lost in 40 related tabs	Rabbit-hole check-in when you have spent a long time on-goal with many tabs open

Most tools catch only one. Blockers punish off-task browsing but ignore deep dives on the right topic. Timers do not know whether your tabs match your intent. This extension tracks both time and tab alignment against the goal you set.

How to use it

1. Set a goal

Click the ? icon in your toolbar. Type what you came to do, for example AWS pricing, and press Set goal (or Enter). The extension starts counting which tabs match and how long you spend on them.

Set a goal while you browse

2. Browse like normal

Keep working. Open the popup anytime to see minutes on-goal vs distracted, and how many tabs are on-goal vs off-goal. Tracking runs in the background while Chrome is focused. Switching tasks? Set a new goal anytime. No need to end the old one first.

Live stats: on-goal vs distracted time and tabs

3. Answer when it nudges you

When the icon shows !, open the popup.

Focus nudge: you drifted to off-goal tabs. Get back on task or tap Back on track to snooze.
Rabbit-hole check-in: you stayed on topic a long time with many tabs. Tap Done, Keep going, or Dismiss.

Rabbit-hole check-in when you have gone deep on a topic

Optional: adjust thresholds

Click the gear in the popup. Change distraction and rabbit-hole thresholds, then Save settings.

Configure when nudges fire

Privacy

Local-only storage. No accounts, analytics, or remote servers. Permissions are tabs, storage, and alarms only. No host permissions, no notification permission, no network access.

Important disclaimer

This is a personal productivity tool, not a medical device. It is not FDA approved, not a diagnostic tool, and not a substitute for professional care. I built it from publicly known ideas about focus, tab switching, and self-regulation while browsing. It may help some people with ADHD or anyone who loses track online, but your experience will vary.

Open source

MIT licensed. Built with WXT, TypeScript, and Vitest. Full tutorial: tutorial on GitHub.

Related research

If you want to read what researchers say about focus, tabs, and ADHD online, these are worth a look:

Nagel, J. et al. (2025). "Too Many Tabs Open? Using Everyday Computer Data to Support Focus for adults with ADHD" (RMIT University). A proof-of-concept study showing that tab switching, idle time, and task relevance can estimate attention in real time.
KIT researchers (2025). "FocusUp: A Browser Extension for Enhancing Online Attention and Productivity for ADHD Individuals". Describes a Chrome extension that tracks tasks and reading progress to reduce cognitive overload while browsing.
NIMH: Attention-Deficit/Hyperactivity Disorder (ADHD). Overview of ADHD symptoms, diagnosis, and treatment from the U.S. National Institute of Mental Health.

These sources informed the general idea behind the extension. They do not endorse or validate this specific tool.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Forget what you read? Breadcrumb helps

Pooyan Razian — Thu, 30 Jul 2026 07:30:44 +0000

You read a great article about Kubernetes autoscaling in March. In July you remember the idea, but not the URL, the title, or even the exact words. You try Google again and hope you find the same page. Developers, students, and researchers hit this constantly: valuable knowledge disappears into browser history.

Breadcrumb is a free, open-source Google Chrome extension I built to fix that. Highlight text on any page, save it in one click, and find it again months later with plain-language search. Everything stays on your device. No account, no cloud upload.

Install from the Chrome Web Store · Source on GitHub

Who is it for?
How to use it
What makes it different
Privacy and permissions
Open source

Who is it for?

Developers saving AWS docs, GitHub issues, Stack Overflow answers, blog posts
Students and researchers collecting notes across papers, courses, and articles
AI power users keeping insights from ChatGPT, Claude, or Gemini that would otherwise vanish

Breadcrumb does not try to change how you work. It captures value from what you already do: read, research, learn.

How to use it

1. Save a highlight

Select text on any page. Right-click and choose Save to Breadcrumb. The extension stores the text, page title, link, and timestamp locally.

Save a highlight from the right-click menu

2. Open the popup

Click the Breadcrumb icon in your toolbar. Recent saves appear immediately. Search from here, or click Open library for the full view.

Turn on Semantic (AI) search in settings if you want meaning-based search, not just keywords. The AI runs on your device via Transformers.js. Nothing is uploaded.

Recent saves and quick search in the popup

Enable on-device semantic search in settings

3. Search your library

In the library, type what you remember, like aws or kubernetes autoscaling. Breadcrumb finds matching notes even when you do not recall the exact words. Use filters, tags, and the timeline on the right to see what you have been learning over time.

Search results in the library

That's it. Highlight, save, search. Your notes stay in your browser only.

What makes it different

Hybrid search blends keyword matching with semantic similarity in one ranked list
On-device AI using a small all-MiniLM-L6-v2 model. Works offline. No inference server
Similar notes shown when you save something related to an earlier highlight
Learning timeline with month-by-month breakdown and auto topic tags (AWS, Kubernetes, AI, Rust, and more)
Export and delete your data as JSON anytime

Privacy and permissions

Breadcrumb requests only storage, contextMenus, and activeTab. No host permissions, no browsing history tracking, no backend. Notes live in IndexedDB on your machine.

Open source

The project is MIT licensed. Built with WXT, TypeScript, Vitest, and GitHub Actions CI. Full tutorial: tutorial on GitHub.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Make dependency updates boring again

Pooyan Razian — Wed, 29 Jul 2026 07:30:45 +0000

Dependency updates are one of those things teams keep postponing. Not because they do not care, but because every update feels like a risk. A small version bump can break a build, fail tests, or create unexpected issues in production.

That is why I built Update Dependencies, a GitHub Action that keeps dependencies up to date automatically and opens a pull request, gated on your checks passing when you give it any to run.

Get it on GitHub Marketplace · Source on GitHub

What it does
It also protects you from freshly published attacks
Supported package managers
Example workflow
Main inputs
What the pull request looks like
Permissions and tokens
Where it sits next to the bigger names

What it does

It scans every package manager in your repo, in one run, across every path in a monorepo, not just the root. Every change lands in a pull request that is labeled breaking or non-breaking based on the actual version jump, not just the mode you ran it in.

If you give it check-commands (tests, lint, build), a failing update never opens a pull request in the first place. Leave that empty and it will still open one, letting your repo's own pull request CI check the update the same way it checks everything else.

It also protects you from freshly published attacks

A version that was published an hour ago is not automatically safe just because the version number is higher. A good chunk of recent supply chain attacks worked by publishing a compromised release and letting update bots pick it up within minutes, before anyone noticed. Dependabot addressed this with a minimum release age setting, and Update Dependencies does the same thing.

min-release-age-days (default 3) waits out a version's first few days before updating to it. That gives the community a window to catch a bad release before it reaches you. If the newest version is too young, the Action walks back to the newest one that is old enough, skipping any candidate that turns out to itself be vulnerable.

The one exception: a version that fixes a disclosed vulnerability, checked against the OSV.dev database, always bypasses the wait. Getting a real security fix should never be held up by a policy meant to stop bad ones.

This check fails open on purpose. If a registry or OSV.dev lookup does not come back in time, the update still goes through, just marked "Unverified" in the pull request instead of blocking the whole run over one slow API. Every pull request gets a "Release-age policy" section explaining exactly why each package was held back, allowed early, or left unverified.

Supported package managers

Ecosystem	Language	What it updates
npm, Yarn, pnpm	JavaScript/TypeScript	package.json + lockfile
pip	Python	requirements.txt
Cargo	Rust	Cargo.toml + Cargo.lock
Go	Go	go.mod + go.sum
Maven	Java/JVM	pom.xml
Gradle	Java/JVM	version catalog or build.gradle(.kts)
Bundler	Ruby	Gemfile + Gemfile.lock
Composer	PHP	composer.json + composer.lock
NuGet	C#/.NET	*.csproj

Example workflow

Save this as .github/workflows/update-dependencies.yml. This is the recommended setup: no check-commands, a personal access token for github-token so your repo's own pull request CI runs on the update, and no trigger on pull_request (the FAQ in the repo explains why).

name: Update Dependencies

on:
  schedule:
    - cron: '0 2 * * 1' # every Monday at 02:00 UTC
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: yanovian/update-dependencies-action@v1
        with:
          update-strategy: non-breaking
          create-pull-request: true
          github-token: ${{ secrets.PAT_TOKEN }}

Main inputs

Input	Default	Description
`update-strategy`	`non-breaking`	keep every package within its current major version, or allow major jumps
`check-commands`	(empty)	commands to run after updating, one per line; all must exit 0 or no pull request opens
`min-release-age-days`	`3`	minimum days a version must have been published before updating to it; a fix for a known vulnerability always bypasses this
`create-pull-request`	`true`	whether to open a pull request when updates are available and checks pass
`base-branch`	repo default branch	branch the pull request is opened against
`branch-name`	`chore/update-deps/<update-strategy>`	prefix for the branch; the actual branch is `<branch-name>/<run-date>`
`config-path`	`.github/update-dependencies.yml`	path to a config file to skip an ecosystem or a path; missing is fine
`working-directory`	`.`	directory to scan, relative to the repo root
`github-token`	`${{ github.token }}`	token used to push the branch and open the pull request; a PAT is recommended

What the pull request looks like

For every path in your repo where something changed, the description lists the package, the path, the version it moved from and to, and whether that change was breaking. It also lists every command that ran and passed, and explains why keeping dependencies current matters for security, while making clear that testing the change is still on you.

A pull request opened by Update Dependencies

Running it again the same day updates that same pull request instead of opening a new one. A run on a later date opens a new one, and if an earlier one from this Action is still open, the new pull request points to it and recommends closing it.

Permissions and tokens

Your workflow needs contents: write and pull-requests: write either way. For github-token, a PAT is recommended so your repo's own pull request CI runs on the update automatically; the default GITHUB_TOKEN also works, paired with check-commands.

If it can open a pull request only once your commands all pass, that is a real signal, but not a guarantee. Review the diff yourself before merging, especially for a breaking update.

The goal is simple: make dependency updates a regular habit instead of a stressful emergency task. Run it on a schedule, review the changes, and most of the time simply merge. Keep dependencies fresh, reduce security risks, and avoid months of accumulated updates.

Where it sits next to the bigger names

On the specific problem of updating a version without opening the door to a supply chain attack, this is doing what Dependabot does with its own minimum release age, plus a vulnerability check that decides when it is safe to skip the wait.

	Update Dependencies	Dependabot	Renovate	Paid SCA tools (Snyk, Mend)
Minimum release age gate	Yes, configurable	Yes	No	No
Vulnerability-aware bypass	Yes (OSV.dev)	No	No	Yes (proprietary feeds)
Cost	Free	Free	Free self-hosted / paid hosted	Paid
License and reachability scanning	No	No	No	Yes

It is not a replacement for a full paid SCA product, it does not do license scanning or reachability analysis. But for the one job it is built for, it is not missing the security feature that actually matters here.

For the license part specifically, pair it with Open License Auditor, another Action I built, which scans your dependency tree for risky and unidentified licenses on every pull request.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

Clean up years of GitHub Actions runs automatically

Pooyan Razian — Tue, 28 Jul 2026 07:30:45 +0000

Every workflow run stays in your Actions history forever, unless you clean it up yourself. After a year or two of CI, that history turns into thousands of runs nobody will ever open again. Scrolling through them to find anything useful becomes painful.

That is why I built Prune Old GitHub Actions Runs, a GitHub Action that deletes workflow runs older than a number of days you choose, on a schedule.

Get it on GitHub Marketplace · Source on GitHub

What it does
Inputs
Example workflow
Permissions and tokens
Why it matters

What it does

You give it a token and a number of days. Anything older than that gets deleted. You can also tell it to always keep the N most recent runs, regardless of age, so a workflow you rarely trigger does not lose its entire history. A dry-run mode lists what it would delete without deleting anything, which is worth running once before you trust it with the real thing.

Deletion is permanent and cannot be undone, so start with dry-run.

Inputs

Input	Required	Default	Description
`token`	Yes	-	GitHub token for authentication (use `${{ secrets.GITHUB_TOKEN }}`)
`days-ago`	Yes	-	number of days to look back when identifying old runs
`dry-run`	No	`false`	when true, lists runs without deleting them
`keep-latest`	No	`0`	preserves the most recent N runs; `0` disables this

Example workflow

Save this as a scheduled workflow, for example .github/workflows/prune-old-actions.yml. Test with dry-run first:

on:
  schedule:
    - cron: '0 0 * * *'

permissions:
  actions: write

jobs:
  prune-old-actions:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: yanovian/prune-old-actions@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          days-ago: 30
          dry-run: true
          keep-latest: 5

Once you have checked the dry-run output and it deletes what you expect, drop dry-run (or set it to false) and let it run for real on the same schedule.

Permissions and tokens

Deleting workflow runs needs a token with write access to the Actions scope. The default GITHUB_TOKEN works if your workflow grants actions: write; a scoped personal access token or a GitHub App token are the more locked-down alternatives if you would rather not give the default token that reach.

Why it matters

The goal is simple: keep your Actions history relevant and your repository light, without spending time deleting runs by hand every few months. Set the retention window once, run it on a schedule, and forget about it.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

From "spaghetti code" to "spaghetti architecture" 🍝

Pooyan Razian — Mon, 27 Jul 2026 07:30:44 +0000

Note: All the names and events in this story are fictional, and any resemblance to real people or events is purely coincidental.
The story is completely made-up but is inspired by a mix of a few common patterns I have either seen myself or heard from others in the past few years.
The purpose of this story is to share a common trending scenario and a few mistakes that can cause IT-based startups to fail.

Spoiler alert: This article might refer to some 100x delicious dependencies in different layers. 😋

OK, here the story begins ✨

Seven years ago, during the IT hype, Mark took a few courses to learn web development using HTML, CSS, JavaScript, PHP, and MySQL.
Then he was hired by a startup as a web developer. His main task was building the application's frontend using jQuery and later with React. Gradually, he also learned how to build backend APIs using Node.js and Express. He was the company's full-stack developer at this point. 🥳

Back then, they had one extensive "old" application that no one dared to touch and a new one built with a cleaner approach. The old code had files containing thousands of lines of code. A mix of backend logic, database queries, jQuery, HTML, and CSS. A small fix or a single change in one part of the code could break 10 more things! 🍝
He could easily see how difficult it was to maintain and extend the old application, and he always wanted to avoid making the same mistakes as the previous developers had made. It is always "others" that make mistakes, right? 😉
He studied and practiced design patterns to write cleaner code.

Don't know what it does - My code - programmer's joke

A few years later, he was approached by a recruiter on LinkedIn for a CTO position in a retailer startup. He was living in a small country and knew that companies are desperate to find technical staff in that region, but he was not expecting to be offered a CTO position. He was unsure if he was ready for that, but after a few interviews, he was hired for the position. He was surprised and excited at the same time! The company was in its initial stage and did not have enough money to hire more developers, so he had to do everything by himself.

He knew that he had to learn a lot to build the product. Mark had a friend named Alex, a technical manager at another startup. He asked him for advice. Alex told him that in their company, they were using TypeScript for frontend, backend, and even for writing their Infrastructure as Code (IaC). To Mark, this sounded great because then he could do everything by just learning one programming language that was not even very different from the JavaScript that he already knew!
This felt like "the answer" to everything he was expected to do in this new position. 🎉 Alex also said that recently in a technical meetup, he had heard about a new thing called "serverless computing" and "serverless architecture" that could apparently simplify things.
He also mentioned things like lambda functions and API Gateway that Mark had never used before.

Soon after, Mark learned TypeScript basics and tried AWS CDK (Cloud Development Kit) to build a few simple lambda functions. He was amazed by how easy it was to build and deploy a lambda function on AWS. He then learned to use API Gateway to create REST APIs and connect them together. He also learned how to start an RDS instance (MySQL) and connect it to these lambda functions using CDK. He could build his first simple CRUD application in a very short time!

Time passed, and the company grew. They hired more developers, and Mark taught them how to use these technologies.
Also, one of the new seniors shared with the team how to use unit tests, and then they added a check in their pipeline to run all these tests before deploying the code.
The company could not afford to hire architects, DevOps engineers, or SysAdmins because they thought a) they were too expensive and b) a small company like that doesn't need such skills.

In the beginning, everything was fine. They could build the MVP in a few years and successfully deliver it to their first 1,000 customers. Developers were happy because they could build things quickly, and the management was happy about the overall price and development speed.

After a while, now that they were using one database shared with all lambda functions, they realized even a small change in one of the services could sometimes break everything else! They were also facing some random connection issues with the database. After consulting with a few people, they decided to make these services less dependent and split the database. By then, they had hundreds of lambda functions and a couple of API Gateways, so having one RDS instance for each service was not an option. Mark spoke with his friend Alex again, and he suggested DynamoDB. Mark didn't know much about the difference between relational and NoSQL databases, or even if there are different types of such databases, but it was quite easy for him to create DynamoDB tables using CDK and use the new query syntax in his code. He mainly liked DynamoDB because he could easily create new tables without having to instantiate a database engine, define the schema, or deal with VPC, Security Groups, etc. Everything seemed very simple. To simplify things a bit more, he even used non-VPC lambda functions. At this point, they were still in the early stages and had no strict compliance requirements. At least, that's what they thought.

Even though it took a while to migrate all the data and change the queries in the code, after the migration, everyone was happy not having to deal with database-level relations of data, VPC, Security Groups, and other networking and security stuff anymore.

Meanwhile, they had hired a data scientist, Anna, to help business have a better overview. Unlike the dev team, she was mainly using Python, and she could not use AWS the way that the team was using it through CDK and TypeScript.
She had to ask the dev team to create her databases and other tools that she needed. But still, she had to do everything from her laptop, because the dev team didn't want to see Python as an option and wanted everyone to use the same programming language and promote the "lovely framework" they had already built. (lambda functions, TypeScript, and their smart set of customizations to enable logging, etc.)

When the pile of poo started to smell 💩

The team was small, so they could not afford to separate the codebase for every single lambda function, so they decided to put all the code in one repository and reuse different parts of the code and libraries for convenience.
They were using TypeScript, so they could easily import and reuse different parts of the code (modules) in different lambda functions.

In order to reduce the size of lambda functions, they decided to use standard Step Functions (State Machines) to split the logic into smaller parts and move some of the decision makings out of lambda functions. Soon they realized different people on the same team needed a lot of coordination and communication to make sure they are not breaking each other's code because in designing a workflow, the concept of "interface" simply doesn't exist. That means a simple change in the data structure in one layer could easily break the next ones in the chain.

After a while, they realized different parts of their system have silently become dependent on each other. At this point, they had a few lambda layers that almost every lambda function was using and CloudFormation stacks that were dependent on each other. Long-lasting state-aware Step Functions could not be easily modified or removed. Even though Mark wanted to avoid the maintenance hell of a tightly-coupled monolith that he had experienced in his previous jobs, soon, a single change in one lambda function or a lambda layer could break the whole thing!

Don't know what it does - lambda function - programmer's joke

Mark was not happy with the situation, but he didn't want to admit the mistake and find a solution for it, so he simply quit his job and went to another company. Later, the company, now a scaleup, hired a new CTO named Juliet.

At this time, the company had enough money to hire a manager who had worked for a few large companies and a few more managers to help her lead their IT. None of them had hands-on IT experience, but most had a good reputation in the industry and were quite good at people management.

The new CTO, Juliet, was a nice person but had no hands-on background in software development and was not aware of the practical and architectural challenges in this field. So she was not experienced enough to see the existing problems and was not confident enough to guide the existing team to make the strategic changes that were necessary at this point. The company continued with the same practices and habits, but the solution became increasingly slow and even exponentially complex. For each task, multiple services had to communicate with each other and wait for the response synchronously. The system was very slow, and sometimes requests were timing out. Having an overview of services and their dependencies and data flow was almost impossible. Error handling was very complex, and debugging was a nightmare... To fix errors, sometimes they were manually invoking failed lambda functions again to see if the error would be gone, but soon they realized due to not having thought about the idempotency of functions, they had ended up with some unwanted double payments or double item shipping!
Fortunately, the damage was not too big, but it was still a big problem in the eyes of customers and business.
At this point, it was even becoming more and more difficult to identify potential fraudulent activities from thousands of common system errors.
Also, they could see some wired scenarios where a dynamically-typed language like JavaScript could cause random bugs in financial calculations that were sometimes difficult to identify or reproduce.

This led to frustration in the management and technical staff. The company started to lose its best developers. They had difficulties hiring new senior staff willing to continue building on top of this. Even though developers mostly had to work overtime, unlike the good old days, they could not meet their deadlines. Also, the quality of their product was so bad that they started to lose key customers. The business was not going well, and the owners decided to sell the company for cheap.

To save the business, the new owner had to hire an expensive team of external consultants to redesign and re-architect the solution and even build some parts of it from scratch.
Juliet also left the company and soon joined another medium-sized company as a VP of engineering.

Key takeaways

It is good to remember and remind each other that:

✅ Communication over the network is slower, less reliable, and is also considered to be less secure.

✅ Serverless computing does not necessarily mean FaaS or "Lambda functions"! It is a much broader concept.

✅ Thanks to the initial misunderstanding around AWS SAM (Serverless Application Model), these days, "extensively using Lambda functions for building everything" is commonly thought to be the "serverless architecture".

✅ There are other serverless options in AWS, like AWS Fargate, that can help you use your software frameworks of choice (instead of ending up building your own framework) with more standard tooling like containers (ECS, with the least effort, or EKS, with more customization and a wider ecosystem - CNCF)

✅ In a microservice architecture, the size (of each service) matters! You might want to call them micro-service, nano-service, or whatever, but that has a huge impact on data flow, the amount of duplicated data, network traffic, service communication rates, etc.

✅ It is important to remember that you can split complexity to make it easier for different teams to work on them independently (only if you can manage to reduce dependency), but it never dies! It might even grow 10x somewhere else, so then you need to hire people to deal with that.

✅ Remember, debugging a distributed system is usually much more complex than looking at a single stack trace.

✅ Remember, achieving data consistency is a big challenge in distributed systems.

✅ Remember, things look great when you only hear about the benefits and success stories. Let's avoid marketing traps and fancy buzzwords when we are supposed to build important systems for our customers and societies.

✅ Remember, handling "distributed transactions" can be quite challenging. Using a single transactional database, you can simply roll back the whole transaction if something fails or is invalid, right?
But what if you have 10+ services writing into their own databases, and then the 11th fails?
What pattern should you use? Saga? Two phase commit? Compensating transaction? ... or just have an exponential retry mechanism? etc.

✅ Remember, microservice architecture was initiated to solve the problem for large companies and corporations with hundreds, not if thousands, of developers having had to work on a single giant monolith.
It is not necessarily the best option for small startups with a few junior developers.

✅ Remember, microservice architecture is supposed to help you reduce the complexity by reducing the size and dependencies and moving it to another layer for someone else in your team/organization with a different set of skills to deal with, so if you still have a single shared database or a single codebase where all the services are dependent on each other, you are probably only getting the disadvantages of both worlds!

✅ Remember, hundreds of smart developers might have spent years to build secure software frameworks with a lot of tooling out of the box for you, and you are probably not going to build something better than that in a few months.

✅ In order to build a skyscraper or even a tall building, you first need to design the architecture, and then you should consult with construction engineers to verify that, and then begin by building a strong foundation.
You can't start the project from the penthouse! The same applies to software.

Let's use the tools for what they are built for. Lambda and any other FaaS solutions are great for many use cases, but they are not "the answer to everything!" and are not the only serverless options.

You can leverage the power of serverless by choosing the right tools based on the use-case. Lambda, ECS (+Fargate), EKS (+Fargate), ... depending on the size of your organization, the size and complexity of your solutions, etc.

If you liked the article, feel free to share it with your friends, family, or colleagues. You can also follow me on LinkedIn.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.

DEV Community: Pooyan Razian

#1 GitHub Ninja goolakh contributor in Armenia!

Certified goolakh ninja 💪

Path to 10x goolakh-ness

Am I a goolakh ninja now?

The #1 badge is real (sort of)

Dashboards vs reality

The goolakh secret: automation

Note to hiring managers

Secret truth 👇

More reading

Copyright & Disclaimer

Ops Ops everywhere

Copyright & Disclaimer

The age of AI and the rise of addicted digital sheep

Copyright & Disclaimer

AI vs philosophers of the 21st century

Copyright & Disclaimer

Quiet browsing? Tabby keeps you company

Who is it for?

How to use it

1. Meet Tabby

2. Browse with Tabby

3. Tap Tabby to interact

4. Open settings

What makes her different

Privacy

Open source

Copyright & Disclaimer

To test or not to test, "How" is the question!

Article

1. Why Test

2. Our First Test

3. Types of Tests

4. Common Problems

5. Can Containers Help

The event

Recording (YouTube)

Presentation file (PDF)

Copyright & Disclaimer

Cloud vendor lock-in! How much should I be scared of? 😱

What is vendor lock-in?

Some examples?

Why this approach is dangerous?

Vendor lock-in only in choosing the public cloud provider?

What should I do then?

Copyright & Disclaimer

Have ADHD? Try Why Am I Here

Two problems, two nudges

How to use it

1. Set a goal

2. Browse like normal

3. Answer when it nudges you

Optional: adjust thresholds

Privacy

Important disclaimer

Open source

Related research

Copyright & Disclaimer

Forget what you read? Breadcrumb helps

Who is it for?

How to use it

1. Save a highlight

2. Open the popup

3. Search your library

What makes it different

Privacy and permissions

Open source

Copyright & Disclaimer

Make dependency updates boring again

What it does

It also protects you from freshly published attacks

Supported package managers

Example workflow

Main inputs

What the pull request looks like

Permissions and tokens

Where it sits next to the bigger names

Copyright & Disclaimer

Clean up years of GitHub Actions runs automatically