A lot has already been written about WebP, a new image format created by Google that provides both lossy and lossless compression of images displayed on the web. However, this solution is still not popular in web development.
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.
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.
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.
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.
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 Elasticsearch reindex tool — a tool that provides an easy way to rebuild indexes in elasticsearch.
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.
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.
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.
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:
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.
So you have created a brand new and shiny Node.js based app. And now, how would you like it deployed? How to pack it and deliver to a production environment? In this post we’ll describe this process (we assume some familiarity with the concepts of Node.js and npm).
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.
Several month ago, we thought about taking part in an interesting experiment. We decided to grab all the equipment we need at work and to go outside the office for one sprint, i.e. for a week. During the planning stage, we listed some assumptions we wanted to test:
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”.
