🇯🇵🇧🇷🇺🇸Edson Yanaga

Your CI/CD bill is not exploding because of “expensive runners,” it is bleeding out through flaky tests, over-parallelized jobs, and slow feedback loops that quietly tax every deploy This piece shows you how to redesign pipelines so you cut compute waste, shrink queues, and speed up developer flow without adding yet another approval gate or YAML religion Full breakdown in the comments. #DevOps #CICD #PlatformEngineering

8

1 Comment

I don’t remember any BDFL-led open-source project changing its license aside from Redis. Well… that wouldn’t be exactly true because Redis’ BDFL stepped down (who knew it’s possible!). Last year, Redis, the company, took over the project and ended up changing it to a dual-license making it “source available”. Now Redis, the company, changed Redis license to AGPLv3. While I think that business-wise this is a good move - it’s a pretty dirty trick to pull from an open-source trust perspective. The license change from a pure open-source perspective is too little too late - trust is already broken. I think the biggest win of Valkey over Redis is that it’s backed by the Linux Foundation which essentially makes it a “forever” open-source project. Here is an year old interesting blog post from a competitor to Redis:

25

1 Comment

Tech and software absolutely are political. Any request to leave politics out of tech is either coming from a very privileged naïve position, a very very exhausted one, or actively disingenuous (in the interest of profits or actively wanting to build an oppressive system, often both). Especially when it comes to Free and Open Source - whom we choose to be in communities with is the most impactful decision we make. #OpenSource

51

6 Comments

Maintaining an open source project is hard. Most maintainers are managing globally distributed contributors who are largely working for free, while companies build products and profit on top of their work. At the same time, those same companies expect bug fixes, features, and security updates on timelines that work for them, not for us. When something goes wrong, the blame usually lands on the maintainers. If your business relies on open source, helping maintain it isn’t optional. It isn’t charity. It’s part of a secure software supply chain. The health of these projects doesn’t just affect maintainers, it affects every company and product that depends on them. I spend a lot of my time at work contributing upstream as a Kubernetes maintainer and supporting the broader ecosystem. I’m very lucky to work at Minimus, a company that recognizes the importance of that work and considers it a large part of my job as a Developer Advocate. It’s so rare to see that in a smaller company. I wrote more about this here: https://lnkd.in/geZBAVXV

215

7 Comments

Mob FAQ: What happens when there are one or two extroverts on the team? Will they push the other team members aside? What if I am shy and introverted? How can I fit in with the team and be able to give my input? ‘This indeed will be a problem if it isn’t recognized and addressed. One of the first things to note here is that we can all benefit by being more thoughtful when sharing our ideas. In the enthusiasm of the moment, it is easy to blurt out a thought and in so doing interrupt someone else who is already speaking. If the person who was speaking is introverted it is possible they will stop sharing and allow the other person to speak, thus gaining one voice but losing another. We can help alleviate this by choosing to listen before we speak. This takes practice and mindfulness because it often doesn’t come naturally. As teams, we need to allow the more introverted members to have their say. Otherwise, it can be easy for the extroverts to dominate the conversation and thereby accidentally silence the introverts. Teams will benefit if they learn to listen for the more quiet voices. For example, after a discussion has finished it can be helpful for one team member to say to another “I noticed you started to say something Jane, do you still want to express that idea?” At this point, the rest of the team will listen while Jane expresses her idea. Perhaps they may hear something that advances the solution. Of course, Jane is also free to say “no, my idea is covered in the solution we have” or “not now, perhaps later”. Either way, the team must find a way to allow everyone an equal voice. All voices have the right to be heard but equality, like freedom, requires eternal vigilance.’ ― Woody Zuill, Kevin Meadows https://lnkd.in/gptmBTE #MobProgramming

6

The real bottleneck in modern engineering isn't writing code, it's reviewing it. Every team I have worked with has felt this. AI-assisted coding keeps raising output, but review capacity stays flat. The result: longer queues, fatigued reviewers, and things slipping through that shouldn't. This is an interesting approach to that problem. The numbers are worth paying attention to: substantive review comments jumping from 16% to 54%, with under 1% flagged as incorrect. And critically, approval stays human. This is the pattern I expect to see more of: AI handling the heavy lifting on analysis, humans staying in the decision seat.

9

If coding agents struggle to work with your code so will humans. Agent friendly code bases, are also human friendly. Human co-pilots use agents to make your code base more agent and human friendly.

44

2 Comments

In a world where writing prompts is called 'engineering' and running few blocks of copy pasted code in a notebook is called 'building' its refreshing to see what real engineers build. I was fascinated listening to Dr. Werner Vogels at his keynote at re:Invent last year explaining about how they handle transaction based workloads at virtually limitless scale and how they solve key challenges around time sync. This blog post is defnitely worth your time if you are interested to learn more about what goes on under the hood in a database which can do ACID at multi region scale.

20

So today I discovered that it’s very much not trivial to have a GitHub gate that runs elsewhere and doesn’t burn GitHub Actions quota in the meantime. Long story short: if your GitHub gate action runs for an hour, that’s an hour deducted from your extremely limited supply of, well, hours. Even if all it’s doing is waiting for a job to finish elsewhere. Because you can’t just “sleep” or “poll” from a GitHub Action. Well, you can — but you’ll pay for it. The “official” workaround is to use a GitHub Workflow, not a single Action. The workflow has two steps, and the second step is triggered from the outside. Perfectly fine in theory. In practice, it doesn’t work. As in, the external trigger works — but it doesn’t trigger the specific instance of the Action that was launched as part of the workflow run tied to the original PR. So if your goal is to have this externally-run slow gate job be the thing that blocks a pull request from merging, you’re out of luck. You simply can’t have two loosely coupled Actions where the second one marks the PR as ready to merge. You can have that external workflow post comments on the PR. You can even have it approve the PR! But the catch is that it can’t be yourself. And now I’m doubly lost. Because the most naïve yet intuitive idea would be to create another GitHub user to serve as the “external approver.” Wonderful idea — except it might, just maybe, contradict GitHub’s terms of service. Why isn’t there a “sleep until” operation inside an Action — as a step — that doesn’t burn quota? It’s literally just await, and cooperative multitasking already is a big thing for well over a decade. Or maybe I can do a “while loop” that polls the gate-completion service every minute and only burns ~1 second of billable time per minute. Anyway. This is probably the first time I’m seriously questioning whether GitHub is truly designed for the 21st century. As more agents enter workflows, and as more gates rely on external LLMs, long-running gates will matter more and more. On the other hand, with powerful cloud-first models, the gate ideally shouldn’t run for more than a few minutes. And if it does, maybe it should just comment on the PR and call it a day. And there’s always the option of protecting a branch except for a specific GitHub username — a branch that follows main, but only when all tests pass. Although if we’re creating a new GitHub user for this task, we might as well let that user “approve” PRs too. Go figure what the intended usage pattern is.

4

4 Comments