Eva Podbrdská in the winning team at the Showmax offsite

Frequently on Slack, we sometimes get to hear fun stories she tells us about her dog, but more often we benefit from her devotion to her job and correct those mistakes of ours which she politely points out. She is an absolute professional and founder of the Showmax testers community, where members can share knowledge over a cup of coffee. Meet Eva Podbrdská, celebrating 4 years at Showmax this year. 

People tend to simplify things so we could say Eva is a tester, but she would explain to you that there is much more to it than just testing the software, so read on…

You have been working for Showmax for almost 4 years now, solely focused on testing. What thrills you about testing and why is it the best job for you personally?

I love when I get to do investigative work. The thrill of tracking down errors, searching for clues, digging in logs, gathering tiny bits of information until the culprit emerges – it's like a treasure hunt. Other people pay for this experience – and I'm lucky enough to get paid for it!

Another thing that intrigues me about the QA field is how diverse and varied the job is and how much there is to learn. I get to work within all layers of the tech stack, so I have the opportunity to play with many different tools and technologies. I get to cooperate with a very diverse group of people from a variety of teams. I get to do all kinds of things – sometimes my job is just figuring out who needs to talk to whom in order to make things work, and then facilitating that meeting :-) So I wouldn't exactly say I'm “solely focused on testing.” I'm focused on software quality and testing is just a part of that. 

How did you become a tester? Was it a coincidence or a well-thought-through choice?

It was a very pragmatic choice originally. Just like many other new moms, when my parental leave was nearing its end, I knew I didn't want to go back to my previous job in telecommunications where I'd had to work twelve-hour shifts, day and night. I needed a more flexible working arrangement to be able to combine work with caring for our kid. And I knew that jobs in IT tend to have this flexibility. At first, I was thinking of becoming a programmer - but I quickly realised it would take me more than a few weeks to learn coding on a level that would get me a job. Fortunately I found out that there is such a thing as testing, which I'd never heard of before. That sounded like something I could do! I was incredibly lucky to land a part-time job at Showmax almost straight away. And I quickly fell in love with my work. I think I've finally figured out what I want to do when I grow up! :-) 

Have you ever had a mentor at Showmax helping you grow the tester's skill set? 

I haven't had a dedicated mentor at Showmax but I have learned a lot from everybody I've cooperated with, regardless of their role. Showmax is an amazing place that has enabled me to learn and grow on a scale I'd never expected to be possible. In a sense, the whole company is my mentor! And being a backend tester, I am often acting as a hub connecting many different people and teams across the company. I get to work with developers, product owners, project managers, data engineers, and also with people from other companies we cooperate with. So many opportunities to learn new things every day!
Another community that has supported me a lot in my learning is the Ministry of Testing. It's without exaggeration the best testing community in the observable universe and I feel very fortunate to be a part of it and learn from my fellow testers all around the world.

How many testers do you cooperate with on a daily basis?

Being the only tester on our team, I don't cooperate with other testers at Showmax very often. To be honest, that's something that's been bugging me for quite some time – that testers from different teams don't get to learn from each other all that much. I have recently started running regular “coffee” sessions where we share knowledge together. We'll see how it goes.

What does your typical day look like? (Is there a week day you like the most, e.g. because of regular testing loads?)

In the backend we don't have scheduled releases, we release on a continuous basis. That means there are no typical days for me – every day is different. Scheduled meetings, ad-hoc meetings, pairing, deep solo work or just jumping here and there on Slack to help people out… I never know what the day will bring.

So no favourite day because of its schedule? 
I enjoy Thursdays – I've recently gone back to working part-time, I'm working only four days a week and have Fridays off. So Thursday is my Friday before a three-day weekend :-D I can't recommend this arrangement enough, it has been doing wonders for my mental health. It's absolutely worth the pay cut for me.

In December last year, you finished Femme Palette mentoring and Black-Box Software Testing (BBST) Foundations course levelling up your skills. What would you say the Femme Palette mentor helped you with the most?

My mentor was Lewis Prescott and I couldn't have wished for a better one. Not only is Lewis extremely experienced as a tester and test lead, he's also one of the kindest and most supportive people I've ever met. It's priceless to be able to talk things through with somebody who has gone through the exact same challenges and knows how to deal with them.

The main topic we've been discussing was implementing change. It's one thing to identify issues and inefficiencies in the current ways we work as a team and know what we want to change, but actually making the change happen is a whole new animal. People are naturally resistant to change – the force of habit is a very powerful one. Lewis has helped me a lot with figuring out how to split a change into tiny steps and then find out ways to achieve each of those steps. Every now and then I find myself referring back to my notes from our sessions. 
And I haven't only gained a mentor, I've gained a friend.

And what has the BBST course brought you? 

Oh, lots of things :-) It was a very intense course that took basically all of my free time during a period of four weeks and covered a lot of topics – for example, there was a module on computer science fundamentals, another one on test strategy… But my main takeaway from this course was probably how it changed my mindset about testing oracles. A testing oracle is something that gives you a definite answer to the question “is this a feature, or a bug?” Previously, if I didn't have a clear and unambiguous oracle, I would always be looking for somebody to make that decision for me. The BBST course has empowered me to make the call myself and given me tools to support it – not only to say “I think this is a bug,” but also to give a powerful argument for “why is it a bug?” I'm very much looking forward to the next course, BBST Test Design, which I'll be taking in April. 

Last year you also visited the TestBash conference in the UK. This year you are coming back as a speaker. What will your talk be about?

TestBash UK (run by the Ministry of Testing) was absolutely incredible and I can't thank Showmax enough for funding our trip. The format of this conference is pretty unique – each speaker gives not only a talk, but also facilitates a hands-on workshop and an “activity” (a short, bite-sized workshop) which together make for a very intense and enjoyable learning experience.

I was very surprised when my abstract for this year's TestBash UK was accepted. I have never spoken at an in-person conference before so this is a whole new challenge for me – I'm equally exhilarated and terrified :-) The workshops will be especially demanding for me, as I don't have much experience with interactive teaching. Fortunately the MoT team is very supportive and I know I can ask them for help when I need it. My talk and workshops will be on the topic of learning – strategies for making learning more effective and persistent. My boss John is really the one to “blame” here because it was him who once suggested the book “Make it Stick” to me. That sparked my interest and sent me into a deep rabbit hole of learning about learning. I hope to empower other members of the community in their learning efforts and also to learn a lot myself in the process. Teaching others is the best way to learn after all!

What is your goal now, what do you want to achieve next?

I have just gotten the news that my submission for yet another conference, DevConf in South Africa, has been accepted as well! This time it will be a completely different talk – I'll be analysing the software bug that caused the crash of a rocket (Ariane 5 flight 501) from the point of view of a quality engineer. It will basically be an Air Crash Investigations episode but about a software failure. Fun!

It sounds like you have many interests – what do you want to focus on learning next?

There is so much to learn and so little time! 

Apart from upskilling myself in testing tools and other technical topics such as coding and test automation, I definitely want to be more actively involved in the testing community. I'm working on resurrecting the Ministry of Testing Prague meetups – one small meetup has already taken place (many thanks to Showmax for sponsoring us!) and I hope that together we can make the local community grow, thrive, and learn from each other.

Eva at the Ministry of Testing meetup at Showmax

Some could also hear your engaging talks about autism. Why is it an important topic for you?

It's a topic that is close to my heart – it was just a couple years ago that I found out that I'm autistic and the knowledge has changed my life in very profound ways. It has enabled me to accept myself for who I am and to finally get the tools and support I need. And that is what originally got me into public speaking despite being absolutely terrified of it. I have given online talks about autism and neurodiversity on several occasions: at TestBash Leadership (Ministry of Testing's online conference), at Showmax and at several other companies. I felt driven to pass the knowledge forward, share my personal story and what I've learned about myself with the hope it might help somebody else. If I've made just one other person's life better it was worth it.

Showmax CMS team attended DjangoCon 2022 in Porto where they learnt about Django and the things you can do with it, about the developer community around Django and how Django can be used in a wide variety of ways, from giving opportunities to get into coding with Django Girls to how to use hidden features of the framework to do things you didn’t even know you wanted to do! We share a list of recordings of very interesting and insightful talks from Django 2022. conference that we liked.

Experiences from DjangoCon 2022 in Porto

After a year of just virtual events taking place due to the COVID-19 pandemic outbreak, the Django community finally gathered in person for the DjangoCon 2022 conference and chose a very beautiful site – the city of Porto. Located in northwest Portugal, Porto is known for its rich history, stunning architecture, and thriving startup scene. Needless to say, we were excited to attend the conference and learn from the experts behind the Django framework, which has been a crucial tool in building Showmax's Content Management System (CMS).

During our visit to Porto, we were able to explore the city's famous landmarks and attractions, such as the iconic Clérigos Tower and the Cais da Ribeira. We were also treated to the city's famous golden sunset views and sampled its delicious seafood and world-renowned port wine. It was a wonderful learning opportunity and a chance to network with our peers, but also a moment of exploring the rich culture and history of this vibrant and dynamic city.

The event was held in The Super Bock Arena (Pavilhão Rosa Mota) which was definitely a good choice. The venue provided ample space for attendees to network and enjoy the talks and workshops. One of the unique features that stood out was the roof tour, which was a great opportunity for attendees to take a break from the conference and experience a different perspective of the city. The tour finished with a tasting of traditional port wine poured into a cup made out of chocolate!

The conference was full of amazing speakers, which were not only talking about Django and the magic things you can do with it but also about our developer community and how Django can be used in a wide variety of ways, from giving opportunities to get into coding with Django Girls to how to use hidden features of the framework to do things you didn’t even know you wanted to do!

One of the most interesting talks was done by Daniel Roy Greenfeld (@pydanny), the legend behind the series of books called Two Scoops of Django, which every Django developer has used, directly or indirectly, to learn how to build things with the framework at some point in their career. During his talk on Scaling from one to Billions, Daniel delved into the fundamental aspects of being a good developer and how to translate these skills into projects that can impact billions of people while keeping in mind the ethical considerations that arise from such influential work. In the end, Daniel’s talk had little to do with Django itself, but left us with a lot to think about regarding our daily job and how it affects people around the world.

Another speaker, Katie Mclaughlin, made us think "What should you have to worry about?” She presented her view about the multiple trends we have popping up all the time on our daily job as developers and how to identify the ones that are actually worth our attention or even our time. In the talk she described in detail three main topics: Stable and Scalable Infrastructure, Reliable and Resilient Code, and Thoughtful and Thriving Community. We really recommend you watch her talk as it was not only very informative but also presented in a very playful and fun way.

On a more technical side, we had a lot of amazing speakers talking about different topics, but the ones who stand out the most for us were:

Add Multi-Factor Authentication (MFA) to Django in Mere Minutes: we had the opportunity to learn from Justin Mayer (@Jmayer) about the importance of Multi-factor Authentication (MFA), what are the types available and, of course, how to add it to Django in mere minutes!

Introducing Django Ninja: presented by Vitaliy Kucheryaviy, who walked us through a new way of building REST APIs in Django that uses python type hints in a clever way to validate, convert and serialize the endpoints’ inputs and outputs, and also automate API documentation!

“Observe!”: Honza Král (@honzakral) covered many useful tips and tricks to help improve monitoring, observability, and debugging of the running Django applications, such as logging, APM (application performance monitoring), distributed tracing, error tracking, and other things which are essential for any production Django app.

Handling Django in highly concurrent & scale environment: Tarun Garg told us about his journey toward trying to improve the performance of such things as Django admin pagination, text search, and Django models caching in a highly concurrent environment, which was a very educational experience for us!

	By the end of every conference day there was a chance for people to participate in the Lightning Talks, giving five minutes to each speaker to talk about a topic of their choice. This was a really nice opportunity for those who wanted to have their first talk in a less strict format. That doesn’t mean that the talks were not serious or anything like that. We listened to multiple speakers talking about various interesting topics. For example, we listened to a talk about the maintainer of django-upgrade, which quickly presented a tool to us which will make the upgrade of Django major versions easier. It was a major announcement which the Django community has been waiting quite a while for.

In conclusion, the Django Conference is a testament to the thriving and dedicated community of developers using the Django framework. From all around the world, individuals and teams are utilizing Django to build impressive and innovative projects. The community of Django users is a major factor in the continued success and popularity of the framework within the Python ecosystem. The conference was very well organized – the great venue, interesting talks, and inspirational networking were wrapped up with an excellent final party and the extra addition of a free boat trip around the city of Porto. It was a very nice addition to switch the focus from the conference and get to know and enjoy this wonderful city from an unusual angle.

We are already looking forward to DjangoCon 2023, which this time will be in yet another amazing city: Edinburgh! Hopefully this time we might even be one of the speakers telling the world about the crazy things we do with this amazing technology in order to bring moments of joy to our users!

Thanks Bogdan Bodnar for co-writing this post!

DjangoCon 2022 in Porto: Insights from the World’s Biggest Django Conference

This article provides a comprehensive guide to developing a design system for marketing landing pages using the Ruby on Rails framework. We'll look at the different components of a design system, how to integrate them into the Ruby on Rails framework using view_component libraries, and the benefits of using a design system for marketing landing pages. We'll also discuss how to leverage a Lookbook to create a visually appealing landing page experience. We'll provide an in-depth exploration of the different features of Ruby on Rails and how to use them to build a design system. Finally, we'll offer some tips and best practices for integrating design system components into your Ruby on Rails application. With this article, you will gain the knowledge you need to create an effective and visually appealing design system for your marketing landing pages.

Implementation of the Design System with View_component Libraries

A design system is a tool to simplify design creation as well as software development. Its creation for the Showmax platform was a true challenge and you can read more about it in Showmax Design System: The Precious. Our Precious introduces the roots of all the designs, including logos, icons, or foundations like colours, spacing, borders, and more. The design system also states which elements arise from the roots. And for each of the Showmax platforms we have a specific library including elements like buttons, containers, status messages, input fields, and others. Anybody creating a new design or developing it in the code can easily find the right element in the library and focus on the problem instead of redesigning the basics from scratch. To put the Design System into practice, we had to find a way to transfer the libraries from Figma to coders' screens.

Implementation in the Backend-Alpha team 

In my team (that is focused on user acquisition) we maintain and build upon those crucial first steps of a Showmax user's journey. Our team's jurisdiction is over what we call "the Landing Pages" and "the Secure Pages". The Landing Pages are a huge array of static HTML pages. They all link the user to our authorization service and eventually the authorization service links them to the payments journey. We refer to the auth and payments journey as "the Secure Pages".

In the marketing pages, the tech stack consists of the NextJS framework (a React based framework that enables server-side rendering and the generation of static websites). The secure pages are several standalone Ruby on Rails applications.

We knew from the very beginning that no matter what the design system's code would be written in, both the Marketing pages and the Secure pages would be using identical CSS. We needed to find a clever way to share this style code. The obstacle was the significant difference in environments between a modern next-js app written in typescript, bundled with Webpack and a few several-years-old Rails apps running Sprockets to bundle their assets.

Before I get into the code sharing, let's quickly talk about UI components and what form we think they are most effective in.

I would define UI components as simple functions or classes that spit out styled html. Nothing more. They should follow the single responsibility principle and be void of any business logic. Essentially they should be "dumb" and they shouldn't do much with their input other than displaying it however you tell them to display it i.e with various CSS class modifiers or simple arguments like “dark” or “light” to indicate what style the component should be.

If you're familiar with some of the React/Redux design patterns there is a concept of "container components" and "presentation components". Container components are all rendered higher in the state tree and are therefore closer to the data source. They make decisions about what will be rendered (some text string for example) while the presentation components will take that text string no matter what the content is and style it in the way that they're told to. If they take any arguments on initialization the arguments should only be about style, nothing else.

We were really only concerned with presentation components in this project and a vanilla Rails project leaves a lot to be desired in this department. If you want to stick with the default libraries you can split your views up into partials for instance, but partials don’t have a method signature so we can’t just glance at the file and know exactly what data is required to render a partial correctly. Furthermore, partials and views know too much about the controllers that render them. Because they have access to the controllers’ instance variables it's tempting to access this data in the partial. If you are accessing an instance variable in a partial, you tend to lose the reusability. The partial is now coupled to this controller action. If you want to reuse it, you need to make sure that same instance variable exists wherever else you need the partial.

In my opinion, the best way to easily add UI components to a Rails project without worrying about javascript is ViewComponent. It's fairly simple and easy to wrap your head around. You don’t need to think about “global state” or “redux” or  “hooks”. In the end you get a ViewComponent::Base class that simply allows you to write a ruby class that renders html.

Container components and higher-level business logic would be implemented as the UI Components would start to become used in production, with more context.

So we left them as open and flexible as possible.

For example, here is our Ruby CheckBox component:

#ruby#
ruby
# ruby class description
module BeDesignSystem
  class CheckboxComponent < ViewComponent::Base

    def initialize(label_text: nil, id: nil, name: nil, value: nil, checked: false, html_options: {})
      super
      @id = id
      @name = name
      @value = value
      @label_text = label_text
      @checked = checked
      @html_options = html_options.merge({ id: @id, class: 'smFormCheck_input' })
    end
  end
end

#ruby#
<% # the erb template for BeDesignSystem::CheckboxComponent %>
<label class="smFormCheck">
  <%= check_box_tag @name, @value, @checked, @html_options %>
  <span class="smFormCheck_label"><%= @label_text %></span>
</label>

And the related React component for the landing pages:

#typescript#
type CheckboxProps = {
  text: string;
  id?: string;
};

const Checkbox = ({ text, id }: CheckboxProps): JSX.Element => (
  <label htmlFor={id} className={styles.smFormCheck}>
    <input className={styles.smFormCheck_input} id={id} type="checkbox" />
    <span className={styles.smFormCheck_label}>{text}</span>
  </label>
);

export default Checkbox;

The important thing is that you can call these with whatever arguments you want but in the end the html structure is the same in both environments:

#html#
 <label for="check-id" class="smFormCheck">
    <input type="checkbox" name="name" id="check-id" value="value" class="smFormCheck_input" />
    <span class="smFormCheck_label">First checkbox</span>
</label>

So as a team of two, one working in React, the other in view_component, we would be able to share styles as long as we kept the html structured the same and used classes only as CSS selectors.

Which was easy to do for us as we already use the BEM model for our CSS. https://getbem.com/introduction/

The challenging part – Rails apps with Sprockets

If you're familiar with Rails, you might wonder why sharing CSS between Rails and any other web based framework would be worth writing a blog about. They both speak the universal language of Javascript and you can easily bundle CSS using a bundler like webpack! But this wasn't so easy for us because our Rails apps we were working with Sprockets. Sprockets is old fashioned and handles everything much differently than webpacker. Without webpacker we had no package.json or any way to consume npm modules in the Rails apps. 

So we couldn't create an npm module that would just allow the marketing pages and the secure pages to

#typescript#
import styles from "be_design_system/form_check.module.scss";


We needed a way to do that and feed the styles to Sprockets.

In one repo we wrote an npm package and a Ruby gem. We separated the ruby and javascript code at the top level into separate directories.

be_design_system is where we had our SCSS files

app is where our gem code is. It's a Rails engine, which helped us tremendously as Rails engines can contain a miniature sub Rails app in their test directory. This gives us the ability to run another engine called Lookbook (more on this later) where we can prototype, document, and show off our new UI components in real time as we develop them.

In the Ruby engine I was able to import the SCSS and process the files by sprockets:

#ruby#
 config.assets.paths   << File.expand_path('../../be_design_system', __dir__)


Sprockets can then just be used like this to include our assets:

#scss#
*= require be_design_system/form_check

#ruby#
spec.files         = `git ls-files -- '*.rb' '*.scss' '*.erb'`.split("\n")

We can exclude any non-npm packages from our final gem build. It was an unconventional way to cut out code duplication. While it did cause a mild headache in the beginning due to sprockets not being out of the box configured to consume SCSS module files i.e. “button.module.scss” The end result is quite nice. We have all our design system code relating to our team in one place and when we need to jump into the different worlds (e.g. TypeScript vs Ruby), we have this one place that helps make the context switching a little easier.

Now that we have made these UI components available to any of our Rails apps, they are still useful to anyone other than me and my teammate who built this with me. I know what they all look like but how does another team member really know if "Primary Button" will work for them in their project?

https://github.com/ViewComponent/lookbook

Lookbook started out as a pet project of Mark Perkins. If you are familiar with a component gallery called Story Book, this is very similar but much simpler.

When you create a new ViewComponent class you have the option to generate a "preview" file. These are just erb|slim|haml templates where we can render our components with test data. You can even set up a controller class to serve up these files with some data fetched over the http, for instance, or you can just use the controller to parse some fixture files to hydrate your preview classes.

What's so cool about lookbook is how little effort is required to get it working. Even for someone working without webpack. It doesn't need any fancy javascript (it works with or without js precompilers).

To get it up and running you only need to install the gem and navigate to localhost:3000/lookbook. If you already have some preview files, they will be there in all their glory:

You might have noticed that there is a source code button. There you can see the ruby / template that is rendering this preview. When you make changes to this ruby file, lookbook has a websockets connection setup that refetches this page (lookbook renders your component in an Iframe and that Iframe is dynamically refreshed).

What I find even more helpful is the html view. It's extremely handy to have a quick way of flipping back and forth between html and rendered html without all the clutter of chrome dev tools. Many of our components render various data-something attributes for data transfer between the server and the client. This allows you to quickly test that your changes are working properly and debug any weirdness.

So we have components, we have a way to share them and so far we've done all of this with sprockets as our js transpiler. What more could we want?

As you can see above we have blocks of code, a summary, and a little window where the button is rendered so you can see everything you need to render this component. Lookbook renders these by parsing button.md.erb so it's an erb-ified markdown doc. Enhancing this beyond just a basic markdown document actually gives you a ton of power. For instance, each one of these files (called a page) has a page, next_page, previous_page, and pages variable. This allows you to intricately reference and interlink them. You can use ruby to dynamically write docs.

#erb#
<%= 10.times do %>
  something repetitive
<% end =%>


So I hope you got something out of this article. If nothing else, just the curiosity to think about adding a design system to your project. Be sure to checkout Lookbook and ViewComponent

Using view_component for Design System Implementation in Rails Projects

Tomorrow, we are migrating our website to the Showmax.Engineering  domain. We are changing hosting, administrative framework, and the overall look & feel. To make the website easy to manage for our back office and talent acquisition teams, we chose to build it on Prismic.

For RSS subscribers, just change the link to: https://showmax.engineering/feed/ (the original link https://tech.showmax.com/feed.xml will be redirected to the new one).

In the past two years, we have relocated several people from various countries to work with Showmax Engineering in Prague. The decision to leave your home country to work elsewhere and the process itself are both hard

In the past two years, we have relocated several people from various countries to work with Showmax Engineering in Prague. The decision to leave your home country to work elsewhere and the process itself are both hard, so we wanted to investigate the background and offer a sneak peek into a relocation from Curitiba, Brazil to the Czech Republic and maybe inspire more people to consider relocating here. It seems Diego, João, and Juliano are happy working with us :) 

You are all with Showmax Engineering, but in two different teams: Diego works in the (media) Encoding team; Juliano and João work in the CMS team. What is your background or field you specialize in?

Diego: I studied high performance computing for my bachelor’s, bioinformatics for my master’s, and briefly databases for a PhD (just before I decided to run away to Prague).

João: I have a bachelor’s in computer science focused on embedded systems and computer architecture, the same field I started my master's degree in but didn’t manage to finish before coming to Prague.

Juliano: I studied network caching using openflow in my bachelor's, but it made me decide to never touch anything related to networks in my life again! I’ve started my master’s in Machine Learning Security but decided to stop and move to Prague.

I wonder why you wanted to leave Brazil. What is your home country like in terms of career options and why were you willing to leave to work elsewhere?

Diego: Brazil offers good opportunities in terms of IT, and moneywise it can also be interesting to take advantage of the currency exchange rates and work remotely for north american or european companies. I was, however, looking for more than just a bigger paycheck, and wanted to experience living somewhere else, a safer place with more travel possibilities.

João: If you have experience there are plenty of opportunities for IT, but they are not that great moneywise if you don’t choose to work remotely for a foreigner company. For why I’m willing to leave, I always had a desire to live abroad and to experience new cultures and lifestyles, the political situation in Brazil was one more push for me to do so.

Juliano: I wanted to become a university teacher but the Brazilian political situation was really bad at the time with several cuts in Education and the current president of Brazil was clearly gonna make things even worse in that area (by his campaign promises) so the day he got elected I started to look for a job outside Brazil to be able to get some experience living abroad with a good quality of life. Luckily for me Diego was working here and recommended me to our former company.

Diego at the Showmax's Fun Games back in 2021

Diego: I'm personally more aligned with the European lifestyle, more easy going and with a functioning social system.

João: From what I know about USA culture and lifestyle it is one of the last countries I would choose to live in. Europe has a richer history and better quality of life in my opinion and I have a bunch of friends here that I knew would be really helpful to my adaptation.

Juliano: Honestly? Because the USA is the core of capitalism and individualism. Quality of life and focus on the social rather than on the individual benefit/profit are the main reasons to choose Europe. Also, as someone who almost studied history, living in Europe is much more interesting with the opportunities to travel to a lot of historically relevant places.

What was the most difficult part of the relocation?

Diego: Saying farewell to the loved ones was a challenge of course, and the visa process in the Czech Republic could definitely have been smoother. I didn't know Showmax yet when I came to Prague and the first company I worked for didn't have a relocation package, so I had to deal with everything by myself.

João: For sure leaving family and friends behind and the anxiety of what's to come. The whole process from visa to when I started working was quite smooth because Showmax and CzechRelocate helped me.

Juliano: The visa process in the Czech Republic is designed to make you give up and that was the most difficult part for me. My former company didn’t offer a relocation package and I had to deal with everything by myself for both me and my wife, which was an extremely expensive and frustrating process.

How long did the process take and what steps were necessary?

Diego: It was about 5 months between accepting the offer and landing in the Czech Republic, mostly due to complications and delays during the visa process. When I wanted to change companies and start working at Showmax, Showmax offered to help me with changing the company on the visa, something that can be as painful as applying for the first time. Thankfully then all I had to do was to go to the immigration office and sign some papers.

João: I had my first interview in the middle of December 2021 and received an offer about one month later. Showmax then made the arrangements with CzechRelocate to handle my visa process at the end of January, paid for the service, and then everything started in February. Most of February was spent gathering documents and proof of accommodation, all the translations needed, and insurance. At the end of February, I had a meeting at the consulate to deliver all the documents and less than a month after that my visa was approved so I spent the rest of March and the start of April preparing my things to leave Brazil, finishing my notice period with my previous company, and saying my farewells to family and friends. I arrived on the 16th of April in the Czech Republic. It took me roughly 3 months from accepting the offer to arriving in the Czech Republic but if it wasn’t for my notice period it would have been around 2.

Juliano: It was about 6 months between accepting the offer and landing in the Czech Republic. Once I accepted the offer I needed to wait for the contract to be sent to me and needed to find a way to get a proof of accommodation here before even starting the visa process. I was lucky that Diego managed to help me with the proof of accommodation. In the meantime I needed to make some “official international validation” of some of my documents, including my university diploma, and get an official translation in Czech for some of them. Once I got all those documents I was able to apply for my visa at the consulate and really start the process. All of this took almost 2-3 months. After the interview and documentation validation at the consulate it took them 2 months to approve my visa application and only then I was able to book my tickets and come to Prague. It’s important to note that I had issues with the MOI delaying the approval process and Showmax helped me a lot with that regarding communication with the MOI and other things. All of that didn’t include my wife's visa because I couldn’t get a proof of accommodation for her and I needed to come to Prague, find a place to stay, get a document and send it to her so she could even start the process. It took her 6 months after I arrived in Prague to be able to come.

Juliano with CMS team at the 6th Showmax's Anniversary Party in 2021

Looking back, would you go through the process again?

Diego: I love Prague now so it was absolutely worth it. But today I'd look for a company that offers some form of relocation package to help with the transition.

João: It was totally worth it, compared with my friends it was way faster and easier and the short time that I’ve been in Prague has already been amazing.

Juliano: 100% worth it – I’ve learned a lot, got to know amazing people both at work and outside, and Prague is just breathtaking. But I would only do it again if I had a relocation package to assist me with all the inevitable complications imposed by the Czech Republic visa process.

What do you like the most about the Czech Republic?

Diego: Before I set foot here, I already knew that Czech Republic was a beautiful place with a great connection to many regions that I was looking forward to visit, but what really surprised me was how rich the history and culture of this little country is, and after four years I’m still learning a lot and appreciating it. Besides, the general vibe of enjoying the day with friends and beer is exactly what I was looking for when I decided to move overseas.

João: I have been here for just a few months and I haven’t left Prague yet, but I can say that it's amazing how beautiful everywhere I go is. It’s really easy to go from one place to another and the beer is so good.

Juliano: The quality of life in general. An amazing (and cheap) transportation system, easy connections to all of Europe, safety (it's AMAZING to be able to walk at night without fearing for your safety), a good healthcare system and of course… the beer :D

João and Juliano at the 7th Showmax's Anniversary Party in 2022

What rules does Showmax set if you benefit from using the relocation package (any limits, how long you have to stay, etc.)? 

João: The only condition is for me to stay for 2 years at the company.

What keeps you staying at Showmax and working with your team?

Diego: First of all I like our product, and it is very rewarding to enjoy the changes I make in the platform by watching my favorite shows just a bit later. I also appreciate how Showmax cares for its employees, with reasonable deadlines and internal policies such as "no Friday deployments". In other words, a good work-life balance.

João: My team was really welcoming and it was very helpful for me to integrate with everyone. There are a lot of new things to learn and the work-life balance is great so far.

Juliano: Good work-life balance with a lot of support from the company on any issue I’ve faced so far and the people – a lot of amazing people work at Showmax! The product is also something I’m really happy with; for me it's really amazing to think that a change I make impacts hundreds of thousands of people on a different continent.

What are you looking forward to in the near future (any conference, meetup, course/certifications, etc.)?

Diego: I’m currently learning Golang with the support of the company, and always looking for anything related to media encoding and Quality of Experience.

João: I’m learning Java and Golang for upcoming projects.

Juliano: Recently I attended DjangoCon in Porto and liked it very much! In fact, you can read about our experiences in a blog post. I look forward to going there next year and to any similar events too!  Regarding courses/certifications I’m really interested in anything related to leadership-related training, especially with a focus on multicultural teams.

Why Did Our Brazilian Colleagues Relocate to the Czech Republic?

Some time ago, along with the migration of the platform from an on-premises solution to AWS, we migrated almost all of our git repositories (one project, one repository) into one git repository (monorepository/monorepo) that contains everything. As Showmax is built on a microservices architecture, we had a lot of repositories so it was a dramatic change. In this post I'd like to capture in a few lines some of the pros and cons from my perspective as a Ruby backend developer.

To begin with, I would note that when the migration to monorepo was announced, I was skeptical about this change. My first experience with the monorepo approach was from about 13 years ago. Back then it was in SVN, which works a bit differently than git and the workflows were arguably worse. Simply, with SVN, the monorepo approach didn't work very well. Today, I can say that the change to a git monorepo doesn’t differ significantly from the one git repo per project approach. Let’s see the changes:

`git pull` takes a few seconds longer because the repository contains many more tags.

All IDE instances share one underlying source code repository, and so:

it gets more complicated to work on multiple tickets at the same time – you need to stash, shelve, or commit split changes (my colleague pointed out that there is a git-worktree command that could be used to manage multiple working trees in one repository. I personally never worked with this so perhaps I’ll write more about it in the future);

it is necessary to check if there isn't something unfinished in another IDE of another project.

Boundaries of big changes through several services are not obvious and are sometimes so large that when a merge request is created it needs to be split before the code review can start.

Merge requests can contain multiple services and so the code reviewer sees the feature as a whole package.

All changes through multiple services for a given feature can be seen in `git log`.

It only takes one pull for everything to be up-to-date.

Let’s have a practical example of the positive and negative scenarios of creating a merge request through multiple services and how to split a big merge request. This demonstration will be using only standard `git` commands. At the end of the article, I share a simpler solution that uses JetBrains products.

All examples are demonstrated on a simplified monorepository. To create the example repository and simulate the changes, I wrote a quick script mrsc.rb that you can use.

We will use a standard linux distribution with `git` and `tree` commands that should be already available to you. The `tree` command is used to visually display file structure.

#sh#
~$ uname -a
Linux 5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) x86_64 GNU/Linux

#sh#
~$ git --version
git version 2.35.1

#sh#
~$ tree --version
tree v2.0.2 (c) 1996 - 2022 by Steve Baker, Thomas Moore, Francesc Rocher, Florian Sesser, Kyosuke Tokoro

First we create the structure of the future monorepo:

Then we create a git repository from it and stage the created structure:

#sh#
~/monorepo$ git init && git add . && git status && tree .
Initialized empty Git repository in ~/monorepo/.git/
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   gems/gem1/gem_file1.rb
	new file:   services/service0/app/app_file1.rb
	new file:   services/service0/service_file1.rb
	new file:   services/service1/app/app_file1.rb
	new file:   services/service1/service_file1.rb
	new file:   services/service2/app/app_file1.rb
	new file:   services/service2/service_file1.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   └── app_file1.rb
        └── service_file1.rb

9 directories, 7 files

Let’s commit changes and show the change in git:

#sh#
~/monorepo$ git commit -m "init example repo" && git log --stat
[master (root-commit) d96dc0d] init example repo
 7 files changed, 23 insertions(+)
 create mode 100644 gems/gem1/gem_file1.rb
 create mode 100644 services/service0/app/app_file1.rb
 create mode 100644 services/service0/service_file1.rb
 create mode 100644 services/service1/app/app_file1.rb
 create mode 100644 services/service1/service_file1.rb
 create mode 100644 services/service2/app/app_file1.rb
 create mode 100644 services/service2/service_file1.rb

commit d96dc0db07383d25c70414b97223747a98b94a35 (HEAD -> master)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:34:25 2022 +0200

    init example repo

 gems/gem1/gem_file1.rb             | 3 +++
 services/service0/app/app_file1.rb | 5 +++++
 services/service0/service_file1.rb | 5 +++++
 services/service1/app/app_file1.rb | 5 +++++
 services/service1/service_file1.rb | 1 +
 services/service2/app/app_file1.rb | 2 ++
 services/service2/service_file1.rb | 2 ++
 7 files changed, 23 insertions(+)

Now that we have the monorepository prepared, let’s demonstrate the advantage of the monorepo approach. In this example we will make a change across multiple services. Thanks to the monorepo approach, the code reviewer will have a better overview of what has changed across the whole architecture and how it works together.

First we create a feature branch, simulate the changes, stage, and commit:

#sh#
~/monorepo$ git checkout -b feature1
Switched to a new branch 'feature1'

#sh#
~/monorepo$ ruby ../mrsc.rb example1

#sh#
~/monorepo$ git add . && git status && tree .
On branch feature1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service0/app/app_file1.rb
	new file:   services/service0/app/app_file2.rb
	new file:   services/service2/app/app_file2.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   ├── app_file1.rb
    │   │   └── app_file2.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   ├── app_file1.rb
        │   └── app_file2.rb
        └── service_file1.rb

9 directories, 9 files

#sh#
~/monorepo$ git commit -m "feature1" && git log --stat -n 1
[feature1 8913d49] feature1
 3 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service2/app/app_file2.rb

commit 8913d49209d443e3f9a3b3584d52a8ce6a60ed4d (HEAD -> feature1)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:44:40 2022 +0200

    feature1

 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)

We see that the change is small and ideal for one merge request. Let's assume the change has been reviewed and approved, and so we merge it into the master branch and delete the feature branch. Success, everyone is happy.

#sh#
~/monorepo$ git checkout master
Switched to branch 'master'

~/monorepo$ git merge feature1 && git branch -d feature1
Updating d96dc0d..8913d49
Fast-forward
 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service2/app/app_file2.rb

Deleted branch feature1 (was 8913d49).

For the second example, we will demonstrate a disadvantage of the monorepo approach. The starting steps are the same as in the previous example but the change is considerably larger than expected. Since each service is changed as a project in its own instance of the IDE, we may not even realize that it's so big until we actually create the merge request.

It’s very difficult to review big merge requests. Without a “pair code review session” with the one who created the merge request, it may sometimes be simply impossible to correctly understand the overall concept of the change.

In this example we will show how to revert the big commit and split it in a way that every impacted service can have its own merge request.

First we create a new git branch called feature2. Then we stage and create the big commit with all the changes.

#sh#
~/monorepo$ git checkout -b feature2
Switched to a new branch 'feature2'

#sh#
~/monorepo$ ruby ../mrsc.rb example2

#sh#
~/monorepo$ git add . && git status && tree .
On branch feature2
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb
	modified:   services/service1/app/app_file1.rb
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   ├── app_file1.rb
    │   │   └── app_file3.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   ├── app_file1.rb
        │   └── app_file2.rb
        ├── lib
        │   └── lib_file1.rb
        └── service_file1.rb

10 directories, 10 files

#sh#
~/monorepo$ git commit -m "feature2" && git log --stat -n 1
[feature2 b4077d1] feature2
 9 files changed, 130 insertions(+), 9 deletions(-)
 delete mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service0/app/app_file3.rb
 create mode 100644 services/service2/lib/lib_file1.rb

commit b4077d1926a5729911fa9c85ad84f8b8c3442247 (HEAD -> feature2)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 13:42:26 2022 +0200

    feature2

 gems/gem1/gem_file1.rb             |  1 +
 services/service0/app/app_file1.rb | 26 ++++++++++++++++++++++++++
 services/service0/app/app_file2.rb |  4 ----
 services/service0/app/app_file3.rb | 13 +++++++++++++
 services/service1/app/app_file1.rb |  8 +++-----
 services/service2/app/app_file1.rb |  1 +
 services/service2/app/app_file2.rb | 45 +++++++++++++++++++++++++++++++++++++++++++++
 services/service2/lib/lib_file1.rb | 39 +++++++++++++++++++++++++++++++++++++++
 services/service2/service_file1.rb |  2 ++
 9 files changed, 130 insertions(+), 9 deletions(-)

#sh#
~/monorepo$ git status
On branch feature2
nothing to commit, working tree clean

In practice the change can often be even larger, however, for this demonstration it is enough. Every time I create a merge request, I look at it myself before assigning someone to review it for me, and in this case I would notice that it is just too big. It would be better to revert the commit and split it into multiple smaller merge requests. Now that we know what we want to achieve, let’s see how to do it.

First we need to "uncommit" the changes. This is done simply by setting the git HEAD reference to the previous commit with the `git reset` command. In our case we will use a soft reset, which will leave the changes from the last commit as that is exactly what we need. If we used a hard reset, the changes from the last commit would be removed from the working tree.

#sh#
~/monorepo$ git reset --soft HEAD^ && git status
On branch feature2
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb
	modified:   services/service1/app/app_file1.rb
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

Now we have the working tree in its pre-commit state. The `HEAD^` part means we want to go back one commit. It's the same as `HEAD~1`. We can use `HEAD~2` or `HEAD~5` if we want to go back 2 or 5 commits respectively, or we can directly specify the commit hash we want to get to. This can be viewed using the `git reflog` command, which is a log of all the actions that have been performed in git.

#sh#
~/monorepo$ git reflog
8913d49 (HEAD -> feature2, master) HEAD@{0}: reset: moving to HEAD^
b4077d1 HEAD@{1}: commit: feature2
8913d49 (HEAD -> feature2, master) HEAD@{2}: checkout: moving from master to feature2
8913d49 (HEAD -> feature2, master) HEAD@{3}: merge feature1: Fast-forward
d96dc0d HEAD@{4}: checkout: moving from feature1 to master
8913d49 (HEAD -> feature2, master) HEAD@{5}: commit: feature1
d96dc0d HEAD@{6}: checkout: moving from master to feature1
d96dc0d HEAD@{7}: commit (initial): init example repo

In this example, the `git reset --soft HEAD^` command would have the same effect as `git reset --soft b4077d1`. Thanks to the `git reset` and `git reflog` commands, you basically don't have to worry about "screwing up" something in git, like a bad commit or merge, because you can get back to any previous state.

Let’s finally split the big merge request into, let's say, 3 merge requests, service0, service2, and service1 + gem1 because these two were closely related.

First, we `git stash` everything and find out the stash number.

#sh#
~/monorepo$ git stash push -m "feature2" && git stash list
Saved working directory and index state On feature2: feature2

stash@{0}: On feature2: feature2

The stash number is 0. Since we are in the feature2 branch, which is in the same state as the master, we can rename it to feature2_service0. We unstash the changes related to service0 using the `git restore` command and then we stage the changes:

#sh#
~/monorepo$ git branch -m "feature2_service0"

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service0 && git add . && git status
On branch feature2_service0
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb

We then commit and update our big merge request with this change.

#sh#
~/monorepo$ git commit -m "feature2 for service0"
[feature2_service0 ea8057e] feature2 for service0
 3 files changed, 39 insertions(+), 4 deletions(-)
 delete mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service0/app/app_file3.rb

Next, we create a branch and merge request for service1 + gem1 in the same way.

#sh#
~/monorepo$ git checkout master && git checkout -b feature2_service1_gem1
Switched to branch 'master'
Switched to a new branch 'feature2_service1_gem1'

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service1 gems/gem1 && git add . && git status
On branch feature2_service1_gem1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service1/app/app_file1.rb

#sh#
~/monorepo$ git commit -m "feature2 for service1 and gem1"
[feature2_service1_gem1 aca2003] feature2 for service1 and gem1
 2 files changed, 4 insertions(+), 5 deletions(-)

Now we just need to make changes for service2.

Why Did Our Brazilian Colleagues Relocate to the Czech Republic?

Women at Showmax: Eva Podbrdská

DjangoCon 2022 in Porto: Insights from the World’s Biggest Django Conference

Using view_component for Design System Implementation in Rails Projects

WE ARE MIGRATING THE WEBSITE

Why Did Our Brazilian Colleagues Relocate to the Czech Republic?

Backend Developer’s Guide to Monorepos

Showmax Design System: The Precious

Continuous Research: When Non-Researchers Take the Lead

Cross-Functionality in One of our Backend Teams

Project Management Office at Showmax

From iOS Tester to Junior iOS Developer in 2 Years

Air-Pocalypse, and a DATA2022 Conference Amidst Wildfires

Adding Vite to a Sprockets-Based Rails Application

How We Updated the Thumbnail Generator

The Tale of Two Internets and IPv6 @ AWS Lab

IPv6 at Showmax

By Showmaxers, for Showmaxers: Is '{JSONB}' a Silver Bullet?

Our experience with SwiftUI on tvOS

By Showmaxers, for Showmaxers: Linux Containers

Unexpected redrawing in SwiftUI

Showmax for students

Sports streaming at Showmax

Evaluation of Buffering Events on Android devices

Women at Showmax

The Showmax Engineering story, Part III.

Customer centric leadership

“What to watch recommendation” and our Film2vec model

Delivering content the right way, Part III.

Assumption Testing: Don’t Throw Darts in The Dark

Remote testing on Smart TVs

The journey from PHP to Ruby

By Showmaxers, for Showmaxers: PostgreSQL Terminology