Posts

In my previous post I mentioned productivity gains from AI. I think this is one of the most interesting topics in our industry right now. There is a lot of discussion about AI in software engineering nowadays, and it often goes to various extremes. I do not want to go into those extremes here, but I do have one thought that keeps coming back to me. I think we are in an interesting state today. On one side, AI is clearly helping us move much quicker than before. I am speaking from my own experience, but there is plenty of other evidence around as well. On the other side, we can also see quality going down globally. Just look at the status pages of some services. They look like decorated Christmas trees, and that is not a compliment. ...

AWS just announced Lambda MicroVMs https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-microvms. It’s interesting to see how many different people came to the same idea at the same time: that in the age of AI, the ability to run “who-knows-what’s-inside” workloads with proper isolation is becoming more and more important. I’ve been playing with this in my free time too and ended up with https://github.com/artemnikitin/firework. The funny thing is that Firecracker has been sitting right there since 2018. Waiting for its prime time to get out of its niche. And we can safely assume that the amount of its usage (and similar tech) will only grow further from now. ...

AWS is the biggest public cloud out there. You could do almost everything with it except for running x86 Android emulator. Things were like that in the past. It all changed on May 17 when bare metal instances became GA. New instances type allows access to the underlying hardware which means running x86 Android emulators on AWS is now possible. Now you can scale your Android tests until exceeding limits on i3.metal instances or your money run out. ...

There a lot of different services, offering automated testing on real mobile devices and/or emulators in the cloud. In this post, we will not talk about how to choose one of these services. If you are interested in choosing a service which fits you, then you can start from this article. Instead, we will talk about some issues and workarounds what you may face using AWS Device Farm. In general, such issues may be split into two categories: project specific and common ones. This post is about common ones and only for some of them. We will look at issues specific to “Pay as You Go” model. ...

My previous post about creators of Go ended with a phrase Does it mean that they were right again? I don’t know, we will see…. And now we can say for sure that they won. They were right again. If you didn’t hear it, then you should read this post. It’s about an incident from Cloudflare regarding significant vulnerability discovered in their service. But they didn’t mention the most important part, about how it was found. ...

I named this post after a very well-known slogan from Apple advertising. But we will not talk about Apple, we will talk about Go, the programming language that was created by exactly that type of people. The landscape of programming languages is huge. But there is something common for almost all of them. They all trying to put a lot of new features with every release. Sometimes, they broke compatibility between different versions, like Scala did or broke their community into 2 parts, like Python. Sometimes, they just bloat language, like Java. ...

In previous post I tried to describe why I started to look into Go. Today I want to share a small example of Go power. Some time ago we had a tiny Python script for monitoring purposes that runs into CI. Setup was simple: download script from Git repo download and run Docker container with Python environment run monitoring script. The whole execution time in CI was around 10 seconds. From that point of view, everything was ok with this task. There was no reason to rewrite it in Go. ...

I looked at Go in early 2015. Of course, I heard about this language earlier, but at those moments he wasn’t very interesting for me. Things changed after I joined Russian-speaking Go community in Slack (golang-ru.slack.com). I found very interesting and skilled people there. And this was the main point that forced me to look at the language. I went on golang.org and read the documentation. After that, I tried to write a small CLI tool, which used for authentication via HTTP on some internal service. I’ve done it in a couple of hours with the help of Google search and StackOverflow. And it worked. But the main thing was that all this was done after lunch during a single day! Just several hours from reading docs to building something that works. It was really quick. It was fascinating! ...

It finally happened! After several attempts, I finally moved from Jekyll to Hugo. I’m also moved from Github Pages back to Amazon S3. If you’re looking for a guide, try this one. It mentioned some things that weren’t clear in the process.

I found a nice article on twitter https://www.usenix.org/conference/osdi14/technical-sessions/presentation/yuan Some ideas from it looks very obvious, but they are important. Authors told us that “Catastrophic failures are caused by incorrect error handling”. Recently, I fall in love with Go. There are lot of different opinions about this language. One of heavily discussed points of language it’s a feature of language that forces developers to process any error in their code. Obviously, lots of people don’t like to do that. But this article clearly demonstrate why this is so important.