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.
At trivago we have been using code reviews as a part of our process for a good while now. In the beginning they weren't used by many teams but as word of their positive impact spread, more and more teams started adopting this practice, benefiting every day from its many advantages. Like any new practice it has been a learning process from the start. In this blog post I will cover why code reviews are incredibly beneficial when done right and will share what we have learned and which best practices we employ.
It has been about a year since we started the guilds in trivago Software Engineering department in Düsseldorf. You can read about the time when we started here.
Configuration management tools have recently gained a lot of popularity. At trivago we use SaltStack to automate our infrastructure. As the complexity of configuration files and formulas is increasing, we need a fast, reliable way to test our changes.
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.
When thinking about design patterns and architectures in iOS development, MVC might be the first thing that comes to mind for most of you.
But throughout the last years, MVC got a really bad reputation. Probably a lot of you heard about MVC as the massive view controller. Due to Cocoa Touch's
UIViewController it becomes really hard to separate concerns and implement a clean MVC-Architecture. Normally you want your controller separated from your view but as soon as you use a
UIViewController these two get mixed up.
Since this leads us to treating the
UIViewController as just another view, it becomes crucial to define another layer to handle our business logic. This is where MVVM kicks in. If your are not familiar with this design pattern I recommend you to read the post by obic.io.
With engineers spread across four offices, collaboration and communication in trivago's IT is a challenge. Additionally, new engineers join the company all the time, which makes it even harder to figure out who to talk to about certain products, packages, and technologies.