May 29 2015

7 reasons why Java developer should consider learning Groovy

Groovy is a dynamic, object-oriented programming language for the Java platform. Its name comes from slang, where “groovy” means “cool”, “amazing” or “fashionable”. This programming language was designed to be so, but is it still groovy nowadays? Creator of Groovy, James Strachan, admitted that he wouldn’t have created Groovy if he had known anything about Scala. But his project started living its own life. Let’s take a look at what it has to offer us now.


May 26 2015

Is overmocking bad? And if it is, then why?

The first question is — what is overmocking? There are a couple of answers. When you mock something that you can leave or even should use as it is — this is overmocking. An example of this is a POJO object. Other way to overmock your test is to mock all the dependencies and rely only on verifying interactions with mock objects. You will see that in my examples. Overmocking can also happen when you mock something that you don’t own like an external library.


May 20 2015

An introduction to thread pools in Java

According to Moore’s law the number of transistors in an integrated circuit doubles approximately every two years. However, the exponential processor transistor growth does not always translate into exponentially greater practical CPU performance. Processor manufacturers for years delivered processors with higher clock rates and instruction parallelism. As a result, single-threaded code executed faster on newer generations of processors. Of course, it is impossible to speed up clock rates infinitely and processors like AMD FX-9590 with turbo clock speed at 5 GHz are rather unique. Today, processor manufacturers favour multi-core processors. It is common to have a quad-core CPU in smartphones, not to mention laptops or even desktop PCs. Consequently, software has to be written in a multi-threaded manner to take full advantage of the hardware. Thread pools can help programmers harness multi-core CPUs.


May 13 2015

How to write JAX-RS Client fast

According to best practices, when developing a service, one should provide a client for it. If your service API undergoes changes quite often, constant client updates may become troublesome. In this article, I will show you how to develop (quickly and effortlessly!) a JAX-RS client that handles all API changes smoothly.



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.

Prev Showing 8 of 10 Pages Next