A picture is worth a thousand words — see for yourself how this unique Agile team learns BASIC from their Product Owner.

The attack on Ukraine has shocked the entire world, but in Poland it is making especially big waves. Not just due to geographical proximity - Ukrainians are one of the largest minorities in Poland and simply put it is affecting people we know personally.

It’s easy to find resources about improving Elasticsearch performance, but what if you wanted to reduce it? In Part I of this two-part series we looked under the hood in order to learn how ES works internally. Now, in Part II, is the time to apply this knowledge in practice and ruin our ES performance. Most tips should also be applicable to Solr, raw Lucene, or, for that matter, to any other full-text search engine as well.

It’s easy to find resources about improving Elasticsearch performance, but what if you wanted to reduce it? This is Part I of a two-post series, and will present some ES internals. In Part II we’ll deduce from them a collection of select tips which can help you ruin your ES performance in no time. Most should also be applicable to Solr, raw Lucene, or, for that matter, to any other full-text search engine as well.

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.