On 14 March, at 19.00 the 2nd edition of BrainCode Mobi, i.e. a mobile hackathon organised by Allegro became history. This event was special because it was held in four cities: Poznań, Warsaw, Toruń and Kraków.
We, Scrum Masters at Allegro, undertake actions that facilitate the work of our Developers, Product Owners and the Organization itself. We are working with individuals and teams in a variety of ways to remove impediments, increase their agility, etc. We do not limit ourselves to only following the Scrum Guide as this 16-pager is only a framework — the possibilities of acting as a change agent, facilitator and servant leader seem to be endless.
Hello stranger. It’s your first day as a fronted developer. Here is your brand new desk, computer and stuff. Enjoy your work! Oh, I’ve almost forgotten! You’ll need to read this 500-page Design Manual to know what are we aiming for. Don’t worry, it’s really simple — there are a lot of examples there. It’s written in two languages, every line is commented and we will occasionally ask you about some random padding — just to be sure — that you have learnt everything well… — is there any company still working like this out there?
The story begins two years ago during an excellent TDD training given by Szczepan Faber and Tomek Kaczanowski for a bunch of Allegro developers. Surprisingly, it was a trigger to revolutionize our builds at Allegro.
The aim of this blog post is to summarise an experiment that took place between two scrum teams at the end of 2014 and to share our lessons learned. Have you ever worked in close cooperation with another team? Of course you have. But how close is close? Have you ever wondered what happens when you go one step further than cooperation and you actually mix two teams, stir or even shake? During that time we discovered a lot about team dynamics, sources of inner responsibility that is essential for any team to make commitments and what are the biggest obstacles on the way towards self-organisation. So, without further ado, let the story begin…
Any website finds identification of visitors crucial. Usually, cookie files are used, but they have several drawbacks, as users can delete or block them (e.g. by activating the “incognito” mode in web browsers). Besides, cookies fail to identify a user who uses several different web browsers, even if he or she connects using the same device. Hence the idea of a browser fingerprint — a unique user identifier which does not change between successive sessions and which does not depend on selected web browser.
Typically, applications we develop gain more and more features in each sprint. After a certain time it’s hard to say how a particular functionality should work. No one remembers all the corner cases without looking into the source code. So we write high level acceptance tests that describe expected behavior. Using some example scenarios that the end user could trigger, tests check that the outcome is correct. After the user story is implemented, the test joins a regression suite that will protect the application from bugs introduced in future stories.
This post is an introduction to sysdig — an “open source, system-level exploration” tool that ease the task of performance troubleshooting in Linux operating system.
According to what we were taught at school, you cannot build a perpetual motion machine as it is against the laws of thermodynamics. There is nothing in the world that can generate energy forever, without any energy source. Anyway, I am not going to teach you physics. Instead, I would like to write about the energy that drives us.
There’s no denying that the most important way to reach an offer on Allegro is a search bar. How it works from the user’s point of view everybody knows. You input a search phrase, select some filters when needed, click “search” and you get some results, usually quite fast. What looks like a simple and straightforward process on the surface, inside actually engages really complicated algorithms. In this first post of the series we will try to make you a little bit familiar with the tools we use here at Allegro to make search happen. In an upcoming post, we will describe how to use them, focusing mainly on the analysis process.
On January 30th we made a visit to GeeCon TDD to find out what’s going on in the world of TDD. Allegro was one of the sponsors of the event and our colleague Piotr Betkier appeared as a speaker. The theme of the conference was the broad subject of software testing and TDD. The question for the conference to answer was “Is TDD dead?”. The major stars who came to Poznań were Nat Pryce and Steve Freeman, authors of the book “Growing Object-oriented Software, Guided by Tests”.
Allegro was founded in 1999. As you can imagine, technology was quite different at that time. Small startup of three developers wrote first version of the platform. There was no problem with scalability as there were only hundreds of users. We didn’t even used any sql database. All data were stored in the files. This first few years of Allegro are all almost mythical for current developers as no code or data schema is preserved from these times. Over all those years we have grown up – a small company hiring a few programmers has changed into a corporation with dozens of teams and hundreds of programmers. Everything was much easier back then when people were, literally, working together. But with the growing number of programmers, we faced problems that soon turned into blockers. Our code and its complexity grew along with the company. After some time, we realized that such uncontrolled growth would block us one day. Application maintenance would become expensive, and any change of the system behaviour would be risky. That is why we decided to act and our today’s architecture is the result of that decision. Here is the story of our transition.
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.
In this post I would like to show you how to add a resource programatically in Jersey container. We start from a business use case that needs to be implemented. What we are trying to achieve is to allow external clients to use some resources of internal microservices. I am aware of the fact that the solution we are going to discuss is not the best way to solve the problem. Choosing the best solution lies outside the scope of this post. What is covered in this post are the steps and solutions we tried to use in order to solve the problem.
When you publish your service API it is crucial to make it easy to upgrade. If you forget about it, you might end up in dependency hell. Each attempt to change your API will force you to contact all your clients and tell them to upgrade their software. As a result, both you and your clients will be very unhappy. You can mitigate it by providing multiple versions of your resources. But there is no single way how to manage them. Different companies solve it in different ways. Below you find three most popular approaches.
This is the second part of the article about how, in one of the teams at Allegro Group, we combined the Minimum Viable Product (MVP) and Walking Skeleton concepts with the Story Mapping technique to quickly define the scope of the forthcoming project and eventually built a reliable and valuable product in a limited amount of time.
Any programmer can admit that working with code that has been developed for years by many people is a difficult task. Keeping your own application architecture clean is troublesome, and it gets even more challenging in case of an application that was written by other programmers several years ago. One can enjoy writing new applications and tools that do not carry any burden, but each product evolves together with its business assumptions. Moreover, new features are added and the application needs to be constantly improved.
QCon is one of the most identifiable conferences in IT world. Several times every year it connects IT professionals from the whole world in such a well-known locations like San Francisco, New York, Shanghai, Tokyo, Beijing or London. The main idea of conference is to facilitate the spread of knowledge and innovation in developer community.
At the beginning of December we published our first post about Swift. Today we want to continue the Swift thread and introduce a few interesting facts about functions in Swift language.
On 23rd and 24th October, the Allegro platform suffered a failure of a subsystem responsible for asynchronous distributed task processing. The subsystem consists of several daemon processes, Gearman job server, Redis and Oracle databases. The problem affected many areas, e.g. features such as purchasing numerous offers via cart and bulk offer editing (including price list editing) did not work at all. Moreover, it partially failed to send daily newsletter with new offers. Also some parts of internal administration panel were affected.
Devoxx (formerly JavaPolis) is an annual Java-centric conference organized by BeJUG that takes place in Antwerp, Belgium. Such a big Java event can‘t go unnoticed by Allegro. This year five representatives of our company had a chance to experience five full days of Devoxx.
This post is an introduction to the mysterious and alien world of aspect-oriented programming, or aspects for short. At first sight it is difficult to understand why to use aspects and how a project can benefit from this technology. The simplest use case where we can use an aspect is logging. I believe that everyone saw, or even wrote on their own, a piece of code where the business logic was interweaving with infrastructure code:
In distributed environments it is crucial to have a common, standardized language which services can use to exchange information between each other. At Allegro, to meet this goal, we’ve chosen the REST architecture.
Big Data Spain is an annual conference on Big Data and related topics held in the suburbs of Madrid. This year’s, i.e. third, edition has so far been the biggest; it has attracted more than 500 guests and various speakers including Big Data celebrities like Paco Nathan of Databricks. During two days of the conference, guests could attend many keynotes, speeches and workshops and learn about variuos products, services and specific use-cases, in both English and Spanish. Allegro was represented by two employees with a presentation on Hadoop pitfalls and gotchas.
Two weeks ago, I attended Swift Warsaw as a speaker, holding a presentation on “Swift Runtime — Swift Method Dispatching”. I promised to summarise the talk in an article, so hereby I keep my promise.
