We messed up. On July 18th, 2018, at noon, Allegro went down and was unavailable for twenty minutes. The direct cause was a special offer in which one hundred Honor 7C phones whose regular price is around PLN 850 (about € 200), were offered at a price of PLN 1 (less than € 1). This attracted more traffic than we anticipated and at the same time triggered a configuration error in the way services are scaled out. This caused the site to go down despite there being plenty of CPUs, RAM, and network capacity available in our data centers.
We all make errors, but some errors seem so ridiculous we wonder how anyone, let alone we ourselves, could have done such a thing. This is, of course, easy to notice only after the fact. Below, I describe a series of such errors which we recently made in one of our applications. What makes it interesting is that initial symptoms indicated a completely different kind of problem than the one actually present.
Code reviews play an important role in how we develop software at Allegro. All code we developers write is reviewed by our peers. If you apply for a job with us, we may ask you to review a sample piece of code during your interview. A code review done right carries a lot of value, but if done wrong it can become a waste of time. In this article I will describe what I think makes a good code review, how reviews have evolved over time at the teams I worked with and what you can do in order to make code reviews worthwhile.
Some books on IT topics become outdated right after they are published while others stand the test of time. One of the latter is The Pragmatic Programmer. From Journeyman to Master by Andrew Hunt and David Thomas.
Building a Minimum Viable Product (MVP) is a method of developing new products by validating hypotheses using feedback from real users as soon as possible. This is supposed to reduce risk and to ensure a good return on investment. It is most often used together with Agile development methodologies. But there’s no such thing as a free lunch and while it reduces some types of risk, MVP also introduces some risks of its own.
I certainly do not recommend that you play poker or blackjack at work. However, there are situations where both you as an individual and your company as a whole must gamble. And the stakes are often high.
Even though a lot of software development is high-level stuff which does not require the developer to delve into the details of how things work under the hood, in certain situations it can be very helpful to know what sort of low-level operations an application is performing. Two typical scenarios are performance tuning and debugging.
This post is about migrating a real-world, non-trivial, business-critical application from Java 7 to Java 8. When searching for a JDK 8 migration guide, you can often find blog posts that claim to be helpful but in reality only repeat the list of features found in release notes and offer no insight into issues you may encounter in practice. Having no migration guide during our own migration, we decided to create one. This is a report right from the trenches, no details spared, casualties included.
CPU time and memory are the two primary resources every performance-sensitive application needs to use wisely. Java is now the language of choice for many such systems. While most developers have at least basic understanding of computational complexity, I believe that few, especially among those who primarily use Virtual-Machine based languages such as Java, understand well how their applications manage memory. This is not only a very interesting topic in itself, but can also help in improving performance of Java applications or in understanding better the behavior of common Java-based databases such as Apache Cassandra.