How many team leaders do you think there are at Allegro? Earlier this year, about a hundred of us
had the chance to meet in person for two days. We tackled company-wide technical challenges, exchanged experiences
and discussed the way we and our teams work. We encourage you to read our story since it offers a glimpse
at the inner workings of our company and its culture.
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.
Michał is interested in all things high-performance, whether it be low-level stuff like analyzing how OS caches affect I/O operations or high-level like proper application design and functional programming. At Allegro, he works in a team which develops a Pay-per-Click (PPC) advertising system.