​​Seva from UkrOps has started an English version of his blog with the first post about handling concurrency in Bash!

Bash still does a lot of heavy-lifting inside automation tools, task managers, and "CI/CD" systems, as well as for automating mundane ad-hoc tasks. So, you can easily apply ideas from this article in your setup.

#bash #programming

One of the strengths of Go is the existence of default helper tools such as gofmt and goimport. Thus, you don't have to worry about formatting, for example. These tools can also be easily integrated into your editor of choice.

For quite some time now, I have to write Python code in professional setting and an automated import is one of the things I miss the most. There are tools to achieve that, ofc, but still.

Another thing about such helper tools is that we often take them for granted, especially when they are default. But you don't have to!

This article describes on a high level how goimport works. While it is kinda intuitive, it's always nice to see a bit deeper perspective. And if you want to dive even deeper, you can always just read the code yourself.

#go #programming

How hard could it be to write a calculator app?

This article tells the story of the Android’s calculator app and shows that building a calculator is not as trivial as it may seem.

Honestly, I love articles like this one! They truly remind me why I like engineering.

#programming

Today, I'd like to share with you a nice YouTube channel Polylog, that does short explainer videos about the computer science concepts.

https://www.youtube.com/@PolylogCS

#programming #cs #youtube

Some books on programming and software architecture on Humble Bundle.

#books #programming

According to DOU, Python is the most popular programming language among the DevOps-related specialists who understand Ukrainian.

Pydantic is a popular library for configuration validation, including the configuration that comes from the environment. However, it can break the unit tests, if the required environment variables are not present.

However, you can create a fixture for your Pydantic configuration that patches the environment, so your tests are isolated. Here's an article that describes, how to do that.

#python #programming

Today, I'd like to share with you a thing I've worked on for quite some time. Well, the majority of the time I was procrastinating it, but still.

This small project is called Cost Exporter. It's designed to fetch metrics from AWS Cost Explorer API and present them as Prometheus metrics on an HTTP endpoint.

In theory, it's extensible. So, other cloud providers and formats could be added.

It may have some rough edges, since I haven't tested it in real production, only in my test account. Also, this is a classical pet-project: its main goal is to refresh some knowledge and play with some new technologies - not necessarily provide a production-grade solution. Still, I think it may be a useful tool. At least, the idea itself is definitely useful.

Cost Exporter is written in Go, has a Helm chart, everything is stored in GHCR, and automated using GitHub Actions. I have some other ideas on how to improve it, but I cannot guarantee that I do that.

Hope, you'll find this project interesting!

#go #programming #aws #kubernetes

A bundle of book bundles for you today. There were a couple of bundles released recently, so I just grouped them together.

1. ML/AI books by O'Reilly
2. Learn to program by Pearson
3. Cybersecurity and forensics by Pearson

Just keep in mind that often Humble Bundle shares reoccurring bundles. So, always check your library before the purchase :)

#books #ml #ai #security #programming

Under daily routine, it's easy sometimes to forget, why we've gotten into the industry in the first place.

This is where pet-projects come in handy. Also, they are great for learning! Unfortunately, the "pet-project" term got a commercialized a bit. However, this article gave me a new term - "toy software"! I'm gonna use it from now on.

There are a few examples of such toy software that the author wrote through the years. Almost all those examples look super-complex to me. However, one need to understand that each of us has different expertise, and thus different things look easy or hard to each of us. I can easily think of a couple of examples of such platform-related toy software one could build. For example, Cost Exporter really took maybe a week, if I don't account for all the procrastination time.

#programming

A small article about software development in the time of AI -
Writing Code Was Never The Bottleneck.

As the name suggests, this article is about the fact that although many vendors try to sell their AI coding tools as a "replacement for the developers", the blockers that those tools remove were never the biggest ones.

There are companies that understand that and encourage their employees to do "assisted" development, which in turn can yield great results, if people are not afraid of being fired. What a surprise...

#ai #programming

Some time ago, I shared an article from Honeycomb that had a notion of the "durable vs disposable" code. The gist is that there are two fundamental types of code bases: durable (OSes, databases, compilers, etc.) - those that should be predictable and stable; and disposable (PoCs, experiments, etc.).

In her new article, Charity Majors elaborates on this concept. There are some insightful things there. For example, that the cost of software is defined not by how hard is to write the code, but what degree do you need to maintain it. Also:

If I had to guess, I suspect it [writing the code\] won’t be a profession at all so much as a skill set, much like typing or spreadsheets, that any tech-literate modern worker is expected to pick up in order to perform the functions of their job in marketing, sales, product, design, etc.

However

Anything that can be done with disposable code probably will be, because as we all know, durable software is expensive and hard. But disposable software is a skill set; durable code is a profession.

Anyway, this is an interesting read.

#culture #programming #ai

Some new features of Go 1.25 regarding WaitGroups. Now, there's a new function wg.Go that simplifies the goroutine management, so you can omit wg.Add(1) and wg.Done() calls. Therefore, there's less possibility that you'll forget about those.

#go #programming

A small article about goroutines leaks in Go and the ways to detect that.

Another tip is from Dave Cheney himself: never start a goroutine without knowing how it will stop.

#programming #go

I like it, when people talk about definitions, especially for some common / widely use terms. The more common a term is, the more one is "afraid" to ask about it. And since we cannot glimpse into other people's minds, we can talk about completely different things using the same words.

Availability Models talks about the definitions of "high availability" - incredibly popular term in computer science! It doesn't examine all the availability models, despite its name. Rather, this article brings up a question: so, what the heck is "high availability" and how can we define that based on our actual needs?

P.S. Also, I didn't know about the PACELC theorem. It always feels so cool to learn something new!

#databases #programming #system_design

A bundle of Python programming books by Pearson.

While Python won't be my first choice, sometimes it's inevitable. Also, Pearson usually have great books!

#books #programming #humblebundle

An article from OpenAI on how they created a complete project without any human-written code.

This is, of course, kind of marketing material for OpenAI, but it also has interesting points:

 code throughput increased, our bottleneck became human QA capacity.

 management is one of the biggest challenges in making agents effective at large and complex tasks. One of the earliest lessons we learned was simple: give Codex a map, not a 1,000-page instruction manual.

 the agent’s point of view, anything it can’t access in-context while running effectively doesn’t exist. Knowledge that lives in Google Docs, chat threads, or people’s heads are not accessible to the system. Repository-local, versioned artifacts (e.g., code, markdown, schemas, executable plans) are all it can see.

And the most important point, in my opinion:

 kind of architecture you usually postpone until you have hundreds of engineers. With coding agents, it’s an early prerequisite: the constraints are what allows speed without decay or architectural drift.
...
In a human-first workflow, these rules might feel pedantic or constraining. With agents, they become multipliers: once encoded, they apply everywhere at once.

In any case, it's an interesting read. Obviously, it's all related to a completely green field project. So, your mileage for decade-old monoliths may vary.

P.S. Also, according to the diagrams in this article, OpenAI uses VictoriaMetrics, which is also cool :)

#ai #programming

A former colleague of mine wrote an article on how to write better tests with AI.

I recall, there were debates, what should a human write: tests or the implementation. Now, there are debates on whether a human should open their IDE at all.

This article is front-end focused, but it has some actionable and more or less universal advice on how to make AI do tests better. At the end of the day, AI is just another tool and the whole trick is in how good do you apply it.

#ai #programming

Do you trust your colleagues?

An article Stop Using Pull Requests from the same author as the previous article in the channel, argues that they may be not ideal.

The core argument is that pull requests were originally created for low trust open source environment, in which contributors may have never seen each other, and often do not know each other at all. Development teams in the corporate world operate on another set of assumptions.

It's interesting that this article also builds up on the ideas of Thierry de Pauw. IIRC, I already posted his talk "Non blocking Pull Requests" on the channel, but in any case, I can do it again.

The main premise of the article is that you need to adopt T*D practices: test-driven development, trunk-based development, and another made-up T*D practice that basically means pair-programming.

From my experience I can say, that eliminating pull requests is probably not something you can do in a short run, but measuring the waiting time before PRs are merged is a good practice. Another good practice is to team-up on tasks or projects. So, basically pair-programming, but several people can still work on different tasks within a project, share context on this project, and thus be able to review each other's work almost immediately without much context switching.

T*D practices are also nice. Honestly, I have an impression that the majority of people are using the trunk-based merge model and continuous deployment these days. Also, it's interesting how AI can facilitate test-driven development: spec (by human) => test (by a machine) => tests review (by humans) => coding (by a machine).

#culture #programming

You may have heard already that Mitchell Hashimoto plans to move Ghostty away from GitHub.

It could be that you plan such a move yourself for whatever reason, but you're not sure yet. Here's a guide on how to push changes to GitHub and Codeberg simultaneously, so you could still keep the door open.

Codeberg is a non-profit European Git hosting. Although, this guide should work for any provider as long as you can use SSH keys for auth.

#programming #github

Consistent Hashing in 1 diagram and 198 words is a nice primer on the consistent hashing technique. Obviously, it doesn't go deep on the implementation or examples.

That Substack has some other nice primers as well. Some are good, others are not so much, but all of them could be a good start for a new topic.

#programming #primer