Discover how Dungeons and Dragons (DnD) transformed the team dynamics at Showmax, fostering collaboration, camaraderie, and strong interpersonal connections. Join us on this journey as we delve into the incredible power of tabletop gaming for team building.

Unleashing the Power of Teamwork Through DnD: The Ultimate Team-Building Experience at Showmax

At Showmax, we're no strangers to the world of online video streaming, code, and cutting-edge technology. But sometimes, the best way to build a strong team isn't through Teams conference calls or Slack messages – it's through good old-fashioned tabletop gaming. For more than two years, a group of us have been embarking on epic Dungeons and Dragons adventures, and we've discovered that this fantastical pastime has had a profound impact on our teamwork, collaboration, and interpersonal connections. So, grab your d20 and join us on this journey as we reveal how our weekly DnD sessions became the best team-building experience we've ever had!

Imagine a group of dedicated developers and team leaders, exhausted after a day of debugging and brainstorming, suddenly finding themselves transported to a world of swords, sorcery, and epic quests. Guided by our exceptional Dungeon Master (and skilled developer, Tomáš Heger), we navigate this fantastical realm as a bard, a druid, a rogue, and more, learning a thing or two about teamwork and camaraderie along the way.

Staying Connected and Accelerating Onboarding

Amidst the COVID lockdowns, our DnD sessions became crucial for staying connected, maintaining morale, and preserving team spirit. These virtual gatherings offered a sense of normalcy and companionship during unpredictable times.

When I joined the company two years ago, we were operating entirely remotely due to the pandemic. It took me over two months to meet my team members in person for the first time! When I joined the DnD sessions I felt immediately closer to my colleagues with the added bonus of having an excellent opportunity to practice my English, which helped me feel more confident speaking my second language. João Pampanini (a.k.a. Jony), one of our colleagues, experienced a similar benefit when he joined our DnD sessions during this first week at the company. Having relocated from Brazil to the Czech Republic, Jony quickly felt welcome and supported by the team, thanks to our shared adventures.

For both newcomers and relocated team members, our DnD sessions have proven to be engaging icebreakers that expedite onboarding and cultivate a sense of belonging. By cultivating camaraderie and creating memorable experiences, these sessions have become an invaluable tool in connecting and integrating team members.

Our weekly DnD sessions have even helped nurture strong relationships with colleagues who have moved to other teams. Despite two of our players transferring to different teams, we still gather around the table (or screen) to share in the excitement, keeping our connections intact and strengthening our bonds.

Building Character(s) and Questing Together

So, what's the secret sauce that makes it such a fantastic team-building experience? DnD allows our team to step into the shoes of unique characters, improving empathy, understanding, and adaptability while exploring different perspectives and problem-solving styles. In each session, we rely on one another to overcome obstacles and achieve goals, which makes a powerful parallel with the essential teamwork we need at our daily work at Showmax in order to deliver the best experience possible to our users. Plus, it doesn't hurt that the memories of epic battles, daring rescues, and hilarious misfortunes make for great coffee break conversation!

DnD is nothing if not entertaining, and our weekly sessions have become a much-anticipated opportunity to unwind, laugh, and share in some lighthearted fun. This shared sense of humor and excitement has made its way back to the office, creating a fun, supportive atmosphere where even the most daunting deadlines seem conquerable. After all, if we can defeat a Goddess of Winter, we can certainly tackle a few lines of code!

Our weekly Dungeons and Dragons sessions have become more than just a hobby – they're a testament to the power of play in developing strong, collaborative teams. As we continue to explore new realms, slay fearsome foes, and weave tales of adventure, we all feel like we couldn’t hope for a better team-building experience at Showmax! So, whether you're an experienced adventurer or just starting your journey, don't be afraid to take a leap into the unknown and embrace the team-building power of play. You never know – your own epic saga of collaboration and adventure might just be waiting for the roll of a die!

Critical Success: Unleashing the Power of Teamwork Through DnD

Learn about the technical challenges and solutions involved in delivering a smooth 4K live stream of the FIFA World Cup on Showmax Pro, including the use of a specialised live streaming infrastructure, construction of an ABR ladder, and disaster plans. Discover how the team overcame issues related to codecs, FPS, and DASH format, and why they chose to use SDR instead of HDR.

Delivering a Smooth 4K Live Stream of the FIFA World Cup: Technical Aspects and Challenges

Live sports streaming from SuperSport sets Showmax apart from other VoD services on the African market and offers our customers a valuable addition to general entertainment. Live sporting events are included in a subscription tier Showmax Pro. We wrote more about Sports Streaming at Showmax back in 2020 when we launched it. 

This time we want to talk about how we got the opportunity to stream Qatar's FIFA World Cup (FWC) in 4K resolution. It’s one of the biggest sporting events in the world and delivering it in 4K completely exceeded our expectations. 

For many engineers it was just another kind of content, because they simply see football as a game where 22 sweaty humans are chasing a ball to get it into the goal. But we have a few Brazilian colleagues, and they felt differently 🙂 

Juliano Medieta said, “I was always excited about watching FiFA World Cups in general (as you might expect from a Brazilian), but this time it was really special for me working at Showmax. It is awesome when something you enjoy is mixed in your work. I wish I could go back to tell twenty-year-old me that one day I would be in the Czech Republic working in a streaming company broadcasting the World Cup to South Africa just to see my face of total confusion.”

But let’s go back to our story and focus on the technical aspect of delivering a smooth 4K live football stream to all supported devices. 

Our live streaming infrastructure shared between Showmax and DStv (live and catch-up added-value service for satellite receivers) is significantly different from our VoD encoding pipeline. First of all, unlike VoD encoded by FFmpeg, for live streaming we use specialised on-premise AWS Elemental encoders, where we run more than 500 live channels 24/7. The stream is pushed to a Unified Origin packager, which applies DRM encryption on-the-fly and transforms the streams to formats supported by our devices and applications. As a primary CDN for live streaming we use Akamai, which has a decent presence of their edges in South Africa, but in Nigeria you may end up streaming from edges located in Europe. The source of live channels comes from the inputs for the satellite broadcasting and it’s interlaced 50 frames per second. So deinterlacing into progressive is a must have. This limits max frame rates to 25 which is not ideal for sports content but it is what it is. Luckily the source from Qatar was progressive in 50 FPS, which is great for fast action scenes or slow motion as it brings smoother movements.

The 4K UHD has a resolution of 3840 × 2160 pixels. But it’s not just about more pixels, it may bring killer features like High Dynamic Range (HDR), which provides a broader range of contrast and colours. As usual in IT we don’t have just one HDR format. Devices which do not support the given format may display pictures in dull colours. Also, using HDR for lower resolutions does not make much sense – switching between Standard Dynamic Range (SDR) profiles and HDR profiles can be tricky and the switching could be visible and disruptive. Due to this and the lack of previous experience with 4K UHD live streaming before (as well as in VoD), we decided to stay with SDR for all profiles and bring our customers higher picture resolution and smoother motions with a higher frame rate. 

It was the right decision, because we only had the opportunity to do production tests during several live English Premier League (EPL) matches a few weekends prior to the FWC kick-off. Not enough time and events to get sufficient samples and confidence for HDR.

For 4K streaming we decided to add HEVC/H.265 codec into the live stack, where we had only used AVC/H.264 so far. So when creating an ABR ladder for 4K live streaming, we recycled our experience from VoD, where we’d already been using HEVC codec for several years. From experience, we know that HEVC requires around 66% of the bit-rate of relevant profiles in AVC/H.264. We could confirm the same for live streaming.

In order to add new resolutions into the ABR ladder, we used common rules for projecting the ladder like the Power of .75 Rule and the Power of .5 Rule for higher resolutions. It helps to estimate bit-rates proportionally across profiles. You add an additional constant into the equation to cover the increase for doubling the FPS. Compared to what you would expect it does not mean doubling the bit-rate but only a 25% increase. 

We also added 1440p resolution to halve the gap between 1080p and 2160p. 

In this section, we want to share a few issues with you which we encountered during the implementation of 4K UHD live streaming and how we mitigated them. 

This is not exactly related to 4K streaming, but we noticed that some of the live streams became delayed by 5 minutes on the Exoplayer/Shaka player. These players are using the DASH format and 5 minutes is the exact length of our DVR window. By looking further into the DASH manifest we noticed that even though publishTime="2022-11-11T11:56:23.773789Z" looked correct, timestamps of chunks were shifted by 1 day ahead . So when the player tried to find the closest point to real-time, it considered the oldest one based on shifted timestamps. As we found out later, this was caused by a bug in AWS Elementals, when encoding is started/restarted around midnight.

The switching between profiles using different FPS on some Android TV decoders (e.g. Philips 55OLED806/12 model year using the OMX.MTK.VIDEO.DECODER.HEVC.secure decoder) was not smooth but a black frame was displayed for a fraction of a second, when switching profiles. 

Unfortunately, we did not find any mitigation for this.

For the games we got 2 sources, one as usual from satellite broadcast in 1080p resolution coming from the usual flow and one ad-hoc stream in 2160p coming from the new 4K flow. It would be possible to use the 2160p source for every device, take advantage of adaptive streaming, and let players select the best quality in the given conditions. However, we decided to provide both streams and let users explicitly switch to the 4K stream. It was unclear if the 4K stream would contain studio programs during half break, which is very popular among customers. Also, the new 4K flow was not battle-proven and any outage would cause playback issues for all customers. The option to switch between fullHD and 4K UHD was displayed only on devices which we detected as capable of 4K playback.

Of course, not everything was well received. The selection of 4K streams differed during the production test and final release for the World Cup. Mainly this caused some confusion, which we realised, but the tournament was too short for any further experiments, which could cause even more confusion.  

So we officially communicated instructions and customer care was ready to navigate users having troubles.

Customers were very pleased with the 4K quality and smoothness of 50FPS. Many of them just appreciated the possibility of watching the World Cup anywhere despite the struggles they have in ordinary life.

The chart below shows the users watching a 4K stream whose device and connectivity was sufficient to watch it in 4K vs. users watching a 4K stream who did not reach 4K resolution. This could be caused by either false-positive detection of 4K capability or insufficient internet connectivity.

As we explained, we had limited time to get ready for the FIFA World Cup and had a chance to conduct only a few tests during several live English Premier League matches a few weekends prior to the FWC kick-off. Nevertheless, we found a setup that worked amazingly great. There are numerous technical aspects of delivering a smooth 4K stream that we needed to consider and deal with. In this blog post, for example, we shared why we decided to go for SDR combined with a higher frame rate for all profiles instead of using HDR, or how we constructed an ABR ladder and mitigated several issues. 

There is definitely more to reveal about 4K streams. If you want to hear more, come to our next WeStream meetup in Prague on April 26th in Showmax Offices on Bucharova 2657/12, 15800 Prague 5.

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

Learn about the most popular JSON libraries for Python such as orjson, ujson, simplejson, rapidjson, and nujson. This article provides an overview of each library's purpose and history, and then compares their performance, features, and use cases to help you choose the best option for your needs. Also, includes a benchmark comparison for encoding and decoding operations of different JSON libraries.

JSON Python Libraries Overview: A Comparison of Performance and Features

JSON has become one of the most popular formats for encoding structured data, particularly when building RESTful APIs that exchange data with clients or between services. It can also be used in other contexts, such as data processing or machine learning, where structured data needs to be stored or transmitted in a standardized format. 

While Python's built-in json module provides a simple and reliable way to work with JSON data, it is useful to know that there are several other libraries available that offer better performance and additional features. 

In this article, let’s compare some of the most popular JSON libraries for Python such as `orjson`, `ujson`, `simplejson`, rapidjson, and `nujson`. We will do a brief overview of each library's purpose and history, and then compare their performance, features, and use cases to help you choose the best option for your needs.

First of all let’s take a look at JSON itself. JSON (JavaScript Object Notation) is a lightweight data interchange format. The main purpose of JSON is to be easily writable and readable for humans and easily parsable for machines at the same time.

JSON is suitable for a variety of purposes, including transferring data between a client and a server in web applications and APIs and storing data in databases or files (MongoDB, Elasticsearch, etc.).

It’s not necessary to have a root object by specification, although it’s widely used. A JSON object is represented as a collection of key-value pairs, enclosed in curly braces. 

Each key-value pair consists of a key (enclosed in double quotes) followed by a colon and a value. Multiple key-value pairs are separated by commas.

Values can be of several types, including strings (enclosed in double quotes), numbers (integers or floating-point), booleans (true or false), null value (null), arrays (ordered collections of values enclosed in square brackets), and objects (collections of key-value pairs enclosed in curly braces).

Here is an example of a JSON object for the movie Shrek (we will use it later for our benchmark part):

If you aren't familiar with the syntax of JSON or want to investigate how it is defined in detail, there are two main resources worth checking: json.org or ECMA-404.

Serialization of JSON is the process of converting structured data, such as Python objects or database records, into a JSON-formatted string that can be transmitted or stored. This serialized JSON data can then be deserialized, or converted back into its original format, when needed.

Serialization of JSON is a common task in web development, particularly when building RESTful APIs that exchange data with clients. It can also be used in other contexts, such as data processing or machine learning, where structured data needs to be stored or transmitted in a standardized format.

JSON serialization has several potential disadvantages, including limited support for data types, lack of schema validation (which can be solved by using JSON Schema), large file sizes, and performance overhead.

As we embark on this delightful journey through the world of Python JSON libraries, let's take a closer look at their unique flavors and characteristics:

What was originally called simplejson was added as json to the Python standard library starting from version 2.6. It was written by Bob Ippolito. The built-in json library is included with Python. While it may not be the most performance-oriented choice, it's perfect for simple use cases and quick JSON encoding and decoding tasks. For many developers, this library is the go-to choice for everyday JSON handling.

simplejson follows its own development path, separate from the standard json module, while still maintaining compatibility. This allows simplejson to cater to the needs of users who require support for older Python versions.

ujson is a high-performance JSON library, written in pure C, designed for speed without sacrificing compatibility with the built-in json library's API. For applications that require rapid JSON encoding and decoding, particularly when dealing with large data sets, ujson is an excellent choice to elevate your JSON processing capabilities. It is compatible with Python 3.7 and above.

`nujson`: A fork of the high-performance `ujson` library, nujson specializes in handling NumPy objects, particularly arrays, by providing native serialization support. It's an excellent choice for projects that involve scientific or numerical data and require efficient processing of NumPy objects alongside standard JSON data types.

RapidJSON is a high-performance library, written in C++. It’s fast, doesn’t have additional dependencies, is memory-friendly, and it also has validation support based on JSON Schema. While RapidJSON itself is a C++ library, there are Python bindings available, such as python-rapidjson, that allow you to use its functionality within Python projects. It’s compatible with Python 3.

orjson is a high-performance JSON library implemented in Rust, offering Python bindings and focusing on speed and JSON specification compliance. Its unique features include serialization of non-string keys in dictionaries and improved handling of datetime objects. It’s suitable for projects where performance is critical and non-traditional data types are frequently used.

The usage of these JSON libraries in Python is quite similar due to their compatibility with the built-in json library's API. The primary functions for encoding and decoding JSON data, dumps() and loads(), are consistent across these libraries. It allows you to simply replace the built-in json library with an alternative by importing it as json.

# Built-in json
import json

# simplejson
import simplejson as json

# ujson
import ujson as json

# python-rapidjson
import rapidjson as json

# orjson
import orjson as json

# nujson
import nujson as json


Then, the usage of each of the mentioned libraries will look the same:

# Serialization
encoded_data = json.dumps(data)

# Deserialization
decoded_data = json.loads(encoded_data)


Thus, since the usage of these libraries is quite similar, let's proceed to the pinnacle of our exploration journey and evaluate the performance of these JSON libraries in terms of speed.

First of all we need to install all those libraries:

pip install numpy simplejson ujson python-rapidjson orjson nujson

We will use a previously mentioned sample JSON dataset derived from the movie Shrek. This dataset will be stored in a file named shrek.json for our testing purposes.

The code for our benchmarking function will appear as follows:

def benchmark(library):
    encoded_data = library.dumps(data)
    decoding = lambda: library.loads(encoded_data)
    encoding = lambda: library.dumps(data)

    encode_time = timeit.timeit(encoding, number=10000)
    decode_time = timeit.timeit(decoding, number=10000)

    return encode_time, decode_time

Whereas data is already loaded `shrek.json` into the python dictionary:

with open('shrek.json', 'r') as f:
data = json.load(f)


Here are the results of the benchmark tests for the JSON libraries, displaying the time taken for encoding and decoding operations:

Based on these results, we can observe the following:

Built-in json: This library shows moderate performance in both encoding and decoding operations.

simplejson: The results indicate that this library is slower in encoding compared to the built-in json, and has approximately the same decoding times.

ujson: This library demonstrates better performance in both encoding and decoding operations than the built-in json and simplejson.

nujson: Tailored for handling NumPy objects, nujson demonstrates competitive performance in both encoding and decoding operations compared to ujson. While its primary focus is on NumPy serialization, it remains a viable option for standard JSON data types.

python-rapidjson: The performance of this library is quite similar to that of ujson and nujson, with slightly faster encoding times but marginally slower decoding times.

orjson: This library shows the best performance in both encoding and decoding operations among all the tested libraries.

As mentioned earlier, these results provide a general idea of the performance differences between the JSON libraries. Although, some JSON libraries are more suitable for handling NumPy objects, such as arrays, thanks to their specialized support for these data types. One such library is `nujson`. Let’s perform a separate benchmark for these libraries and check how they hold NumPy data.

Instead of Shrek our data will be generated with the NumPy library:

data = np.random.rand(1000, 1000).tolist()

Built-in `json`: This library shows moderate performance in both encoding and decoding operations. It is suitable for simple use cases and general-purpose JSON handling, even when dealing with NumPy arrays.

`simplejson`: The results indicate that this library is slower in both encoding and decoding operations compared to other libraries.

`ujson`: This library demonstrates better performance in both encoding and decoding operations than the built-in json and simplejson. It is a great choice for applications that require faster JSON processing, including handling NumPy arrays.

`nujson`: Surprisingly, its encoding performance is slightly slower than ujson, but it is still twice as fast at decoding.

`python-rapidjson`: The performance of this library is quite similar to that of `ujson` and `nujson`. It can be considered an alternative for handling JSON data, including NumPy arrays.

`orjson`: This library shows the best performance in both encoding and decoding operations among all the tested libraries. Seems to be an excellent choice for projects that require high-performance JSON handling, especially when dealing with NumPy arrays.

To summarize, `orjson` stands out as the top performer, but the built-in json library remains a practical and convenient option for many projects. When choosing a JSON library, consider your specific requirements and weigh the benefits of each library against your needs.

If you seek further optimization, non-JSON serialization alternatives can offer enhanced performance and storage efficiency. Understanding their benefits and use cases allows you to make informed decisions for your project's data handling needs. Let’s briefly take a look at some of them:

Protocol Buffers (protobuf): Developed by Google, Protocol Buffers are a language-agnostic binary serialization format. They are designed to be compact, efficient, and fast. The advantages of protobuf include smaller message sizes, faster encoding and decoding, and a strongly-typed schema. They are especially useful for communication between microservices or distributed systems.

MessagePack: This binary serialization format is an efficient alternative to JSON. MessagePack is designed to be compact and fast, with support for many programming languages. It offers smaller payload sizes compared to JSON and better performance in encoding and decoding. However, it might not be as human-readable as JSON.

Apache Avro: Avro is a binary serialization format developed by the Apache Software Foundation. It is especially suitable for big data and distributed systems like Hadoop. Avro is schema-based, which ensures compatibility between different versions of data structures. It offers compact data representation, fast encoding and decoding, and supports many programming languages.

Apache Thrift: Originally developed by Facebook, Apache Thrift is a binary serialization format that supports a wide range of programming languages. It provides a compact and efficient binary format, a strongly-typed schema, and enables cross-language communication. Thrift is suitable for microservices and distributed systems.

These alternatives offer various advantages, such as improved performance, smaller message sizes, and support for type safety and schema evolution. However, they may not be as human-readable or as widely supported as JSON. It's important to consider the specific requirements of your project when choosing a serialization format.

In this article, we have explored various Python JSON libraries, comparing their features and performance. While the built-in json library is suitable for many use cases, several alternative libraries offer unique characteristics that may cater to specific requirements, such as nujson can be a good choice for working with NumPy data. We have also discussed non-JSON serialization alternatives, which can provide further performance improvements and storage efficiency. The choice of a serialization library or format will depend on your project's needs, and conducting thorough benchmark tests will help you determine the most suitable solution.

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).

Boosting App Performance with Baseline Profiles: A Comprehensive Guide for Android Developers

Critical Success: Unleashing the Power of Teamwork Through DnD

4K UHD Experience During FIFA World Cup

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

JSON Python libraries overview

WE ARE MIGRATING THE WEBSITE

Why Did Our Brazilian Colleagues Relocate to the Czech Republic?

Boosting App Performance with Baseline Profiles: A Comprehensive Guide for Android Developers

Backend Developer’s Guide to Monorepos

How We Migrated the Whole Content Delivery and Encoding Infrastructure from Debian to Ubuntu

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