May 6 2015

Automated tests with Geb, Spock and Groovy

One of the major goals of software development, apart from actually delivering the product, is to guarantee it is of proper quality and not prone to errors. Big modern systems tend to consist of dozens of smaller pieces, often accompanied by some legacy core or part of legacy system. Each of these, often very different pieces of software communicate with each other in some way, in synchronous or asynchronous way, through REST endpoints, SOAP services or a variety of messaging systems. This leads to new challenges. A failure or unexpected change in one place may lead to a misbehaviour in other parts of the system.


Apr 28 2015

Diagnosing a MongoDB issue

You might have read a recent post by our developers concerning performance analysis tools and its follow up concerning sysdig. In the database world these tools come handy almost everyday. In this blog post I will show you a case where I have put tools to action diagnosing a MongoDB issue.


Apr 16 2015

Testing in production... wait, what?

If you are an agile developer who is fluent in multiple languages, you understand the importance of testing. You have several types of tests (unit, integration or behavioural) at your disposal to check your application. The number of available tools, frameworks and even languages is enormous, just to mention a few: Junit, Geb, jBehave, Cucumber, Spock, Selenium. Dozens of other tools can help you verify whether your code is working properly. Besides, I assume you are familiar with TDD and BDD methodologies which are rather standard nowadays. Nevertheless, all of these tools have common limitations – they check your test environment only. Let me show you how one of Allegro teams responsible for the Offer Listing tests the production environment.


Apr 13 2015

How to UX without interface

Allegro is a leading Central European e-commerce platform, offering a vast diversity of new and pre-owned products. Search engine is the main entry point to allegro.pl product stock. Designing a bunch of UX metrics for a SaaS solution or a social networking site is a must. Typically no one would dare discuss whether it is worth our time to measure the effect of changes through an A/B test or a focus group and monitor the impact on metrics. When it came to search engine — a back office product with almost no interface — we had our doubts. We are the search team behind the Allegro search engine. This is the complete interface of our product:


Apr 10 2015

Spring Boot Starter Handlebars

Nowadays, Spring Boot gets more and more popular as it simplifies creating standalone, production-grade Spring based applications. It offers e.g. auto-configuration support for most of the available Java-based template engines such as Velocity, Thymeleaf, etc. Today, we would like to publish the new Spring Boot starter that supports auto-configuration of other popular template engine we have recently got used to — Handlebars. Hopefully you might find this little piece of code useful.



Apr 3 2015

Allegro OpenSource: tradukisto

At Allegro we use many open-source tools that support our work. Sometimes we are not able to find what we want and this is a perfect moment to fill the gap and to share with the community. We are proud to announce an initial release of Tradukisto — a small Java library created to convert numbers to their word representations.




Mar 24 2015

Better coding with coaching

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.


Mar 18 2015

Frontend made simple

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?



Mar 9 2015

Playing with fire — a Scrum experiment

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…


Mar 4 2015

Browser Fingerprinting — introduction

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.


Mar 2 2015

Acceptance testing with JBehave and Gradle

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.




Feb 18 2015

Search Engines at Allegro — Part I — introduction

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.


Feb 13 2015

TDD is not dead yet — GeeCon Poznan 2015

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”.


Feb 11 2015

Evolution of our platform architecture

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.



Feb 3 2015

Using Jersey model processor for supporting edge-service features

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.


Jan 29 2015

Content headers or how to version your API?

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.



Jan 21 2015

Working with legacy architecture

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.

Prev Showing 9 of 10 Pages Next