Latest articles

We all have been there, done that. You want to build an API that allows you to manipulate your entities so you start checking which specification to use. Maybe REST or JSON API or maybe no specification.

At trivago, we use a Cucumber based framework for end-to-end tests of our most important web applications. Cucumber stores test result as JSON files which can be turned into human-readable test reports.

We're a data-driven company. At trivago we love measuring everything. Collecting metrics and making decisions based on them comes naturally to all our engineers. This workflow also applies to performance, which is key to succeed in the modern Internet.

When I joined trivago a year ago, we had problems with our releases. The traffic was increasing each day. When we put the server back into the load balancer without warming up the OPcache it would die. From time to time the warmup failed silently. Our DCO (data center operations) crew had to log into the servers and restart a few processes manually. During this time every release was very intense.

Accessibility is an important topic for anyone who builds things for the web, and one that is neglected far too often. We at trivago have also been guilty of this, but we are slowly making changes with the aim of improving the accessibility of our site. Identifying and implementing these changes has not been easy. We have faced a number of challenges along the way, and we continue to do so. But we are committed to improving our site so that anyone can access and use the service we provide, regardless of how they do so.

Sometimes advertisements just have to be bold.

You might have found, that most job ads are quite generic. They lack a personal note. Why apply at a company, when even the job description sounds boring?

Education.

It's not only a topic that is very dear to our CEO Rolf Schrömgens, but that trivago as an entire organization cares about. Without good education, we will not be able to continue to add great people to our teams, or advance as a society.

You do not run a successful, stable software project over several years without some amount of automated testing. If several dozens of developers are working on the same code base, the need for test automation becomes even greater. After all, their changes might have unintended effects on other people's code, or on certain edge cases that will not be noticed until the changes go live — and maybe not even then.

For the past few years, Webpack has played a central and important role at trivago. We use it for handling SVG icons and to improve our startup time for the benefit of our users by loading resources on demand. We run a highly complicated build with plenty of custom plugins which perform all sorts of optimisations for us that no other tool would allow us to do. And because we truly love open source we’ve also open sourced our solution to speed up multi-compiler builds, which we rely on heavily to deliver ideal bundles to our users.

Our first right-to-left platform was released in 2014. We had developed a solution to generate right-to-left CSS with Sass mixins and variables as we have described in a blog article. We used this approach for nearly 3 years but recently migrated the right-to-left generation from pre-processing to post-processing with RTLCSS. With this article I would like to share the reasons for the migration as well as our experiences and lessons learned.

At trivago, we are using an in-house developed Selenium framework based on cucumber-jvm to run automated browser tests. As the test suite increased (the time exceeded 45 minutes for a full run), we were looking for ways to move away from sequential towards parallel execution. For Cucumber, there are actually not that many options available:

We, Marcos Pacheco and Marcus Tannerfalk, work as Agile Coaches in the Palma office for the hotel search company trivago. This is our experience in working with a development team in daily sprints with the goal of delivering a MVP (minimum viable product).

I love to take complex and tedious processes and automate the pain out of them until they are reduced to three or four steps!

As part of the release team of trivago, one of our roles is to create tools that make the lives of our developers easier so that they can create amazing features for our website.

Concepts like separation of concerns, logic decoupling or dependency injection are things we developers have heard more than a couple of times. At trivago, the Android app is developed using the Model View ViewModel (MVVM) architecture, aiming for views as dumb as possible, leaving the decision making to the view models. This leads to an increased test coverage since testing logic in views is something we can’t do that easily.

For our products, like the trivago hotel search, we are using Redis a lot. The use cases vary: Caching, temporary storage of data before moving those into another storage or a typical database for hotel meta data including persistence.