Why should you retry all tests on failure? Why not? This article will not go into details, listing pros and cons of each approach. There are already enough resources on the Web about the topic, listing valid points for both opposing views. As trivago Hotel Search frontend QA team over the last years we tried to stay away from a brute-force retry policy for failures and we rather tried to execute test retries only in selected cases. Recently, when we switched to a Continuous Deployment approach for our new frontend Web application (which empowers developers to merge and release some pull requests autonomously), we faced a greater need than before for understandable and stable test results. Due to that, showing as few “red flags” as possible for the automated checks on pull requests became even more important to ensure enough confidence in test results and to avoid slowing down the software development life cycle. The requirements and the balance between deterministic results and success ratio shifted, at least in some cases.
Over the last few years, we completely refactored what was described in our previous article about how we use the ELK stack for an overview of our test automation results, but some core concepts remain valid and applicable.
Have you ever wondered about how to create components that not only change their appearance according to the viewport’s width but instead also transform according to their parent element’s sizing? This might be the case when you have a card component that has the classical vertical layout on mobile:
When techies hear about email marketing and designing HTML emails, they typically roll their eyes and think of a very boring field of work. In this article, we hopefully can explain to you why this is wrong from our perspective. Our team built a solution that our marketers use to easily design HTML emails with predefined modules within our email marketing platform Salesforce Email Studio, which is part of the Salesforce Marketing Cloud (SFMC). This article gives you an overview of our approach as well as why and how we built such predefined modules for Email Studio on our own.
After almost a decade, we decided to rebuild our in-house Business Intelligence web application to better support the organization. It is always challenging to replace software with a long history and a high degree of complexity. Nevertheless, we successfully completed the project because we fundamentally challenged and re-thought all aspects of the project.
At trivago we are working heavily on the web platform and, based on the scale that we need to serve our users, our applications need to cater for many different kinds of environments and conditions.
Over the past few months, I was given the opportunity to try out the life of a Product Owner (PO), alongside retaining my responsibilities as an engineer. The life of a PO has always intrigued me since I joined trivago 2 years ago, and I always found myself unofficially taking on roles that were traditionally done by them. Things like reaching out to stakeholders for collaboration, thinking about KPIs and impact, and general "aligning". Perhaps it's because I simply love the sound of my own voice, but I've always felt a particularly high level of gratification from contributing in meetings. "Aligning" is an overused word in the workplace, but it is the best to describe where I derive my professional gratification from, outside of building things with code.
trivago open sourced a Prettier plugin for the Twig template language. It is available under the Apache 2.0 license, and you can access it on trivago's Github space.
The trivago core product runs on our own frontend framework Melody. Melody uses a Twig-inspired template language because when it was introduced, it had to be interoperable with our existing codebase, which was based on the Symfony PHP framework with Twig as the default template language.
At the end of last year, to celebrate our continued sponsorship of the Open Source community, we hosted a small conference with special guests at our Düsseldorf campus. We initially hoped to welcome Tobias Koppers and Sean Larkin from Webpack, plus some internal speakers. What we didn't expect was the huge amount of fantastic speakers who wanted to present their projects to the community. In the end, Sean unfortunately couldn't make it but we did have a chance to welcome Marvin Hagemeister, Juan Picado, Norbert de Langen and Pia Mancini as speakers, plus our own amazing talents.
At trivago we live diversity. We have 55 localised platforms and internally you can find talents from around 90 different nationalities all working towards providing a better experience to our customers. We are constantly evolving as we face organisational, societal and industrial challenges. That's why we identify a lot with this year's theme "A New Dawn", as we too explore the meaning and evolution of our approaches and practices. This year we have decided to support IxDA20 through sponsorship for the first time. It reflects our belief and increasing efforts to invest in Design and Research at trivago as we strive for an inclusive world.
We are originally from South Korea and we've been in Germany for about three years.
We often check the Facebook and Instagram posts from Life at trivago, so we could easily find out about trivago Tech Camp 2019 through social media.