I'm happy to let you know that we are releasing trivago/babel-plugin-cloudinary to the open source community! Throughout this article I will explain to you the motivation behind this project and how it works in detail.
I’m Behrang Yarahmadi from Iran and I’m a 3rd-year Computer Engineering student at the University of Duisburg-Essen.
Sometimes, when I look back over the time I have spent working at trivago, I see how it changed my life and how lucky I’ve been to have the chance to work with this amazing community, to live and to learn with them. I look back and see a younger version of myself looking desperately for something different and, through sheer luck, getting it.
Test, test, test. If you don’t, an issue is bound to crop up in production sooner or later.
We’ve all heard this mantra in one form or another. The importance of testing your software has been covered by countless articles, books and conferences. You worked hard on your code coverage and your downtime due to regression-related bugs has severely decreased.
Imagine a world without open source software. Pretty scary, isn't it?
There would be no free operating systems that let you take full control of your computer.
As we all adventure around this space that we call the Internet, consuming content is often on our minds. Naturally with the vast amount of data, filtering out what’s not interesting is a huge time saver. In order to help you find your ideal hotel at the best price, trivago’s filters are one of the best ways to do so. Sadly, some visitors couldn’t even access them due to poor accessibility and performance.
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.
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.
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:
Around a year ago, in our large scale refactoring project also known as Project Ironman, we stepped away from image sprites that we used for our icons. In this post we will explain our reasoning behind this decision and how it improved maintainability and website performance.