DEV Community: Vinicius Brasil

Programmers Replaced With AI?

Vinicius Brasil — Fri, 12 May 2023 14:19:29 +0000

A few days ago, I came across an intriguing headline on LinkedIn that displayed a bold statement: "Tech Company Aims to Increase Programmers' Productivity by 50% with GitHub Copilot." What made the situation even more curious was that the author of the post was not a programmer. Despite the audacity of the headline, I believe this issue can lead to an interesting analysis and discussion.

There's no denying the impressive capabilities of the AI tools available to the public today. In the field of programming, they are already significantly assisting developers, optimizing their routines and increasing productivity. With the right tools, problems can be solved at a faster pace. However, for those unfamiliar with programming, these AI tools may seem almost mystical, giving the impression that they can quickly and automatically solve any problem. But we know that reality is quite different.

The enthusiasm generated by these tools is fully justified, and before forming a misconception about me, know that I am also one of them. However, I believe that not everyone fully understands what these tools are capable of in reality. On one hand, you have beginners in programming who fear being replaced by machines. On the other hand, you have CEOs seeking magical solutions to reduce costs or increase productivity, perhaps without a clear understanding of the actual work performed by a programmer.

It's not quite like that...

"ChatGPT (or Copilot), create a page to sell tickets for a show in Node.js. The backend should be prepared for an average of 2,000 requests per second and be resilient to failures. Set up a load balancer to distribute requests among distributed servers. Ensure caches are functional and actually reducing server load. Instrument real-time monitoring tools. And of course, the database should be clustered with a good replication strategy."

The example is overly exaggerated, I know. But it illustrates the complexity behind implementing something that may seem simple to someone who is not a programmer. Writing code is only part of a programmer's job, and I'm sure generative AIs excel at that, but it's not everything a programmer does.

We, programmers, spend a significant portion of our day without writing a single line of code. It's necessary to first understand the requirements of new features, engage in conversations and adjustments with stakeholders, design the technical architecture, and finally translate all that information into code. And let's not forget that this code must be written in context, considering how it fits with the rest of the existing codebase.

What I mean is that these AI tools, although very useful, don't do magic. But they can be good assistants to programmers.

AI as a rubber duck

One of the readings that greatly expanded my perspective in software engineering was the classic book "The Pragmatic Programmer" by Dave Thomas and Andrew Hunt. One of the chapters talks about a curious debugging technique: the rubber duck.

The basic idea behind rubber duck programming is to explain the code or problem you're facing out loud, as if you were explaining it to a rubber duck. By verbalizing the problem or describing the code step by step, you often find a solution or gain a new perspective on the problem.

ChatGPT is excellent at conversing, and furthermore, conversing in context. Could this artificial intelligence be the evolution of Dave Thomas and Andrew Hunt's rubber duck? There are already extensions for Visual Studio Code that integrate with ChatGPT, using it as a rubber duck. You can check them out here.

I like how GitHub chose to name its product Copilot, and that aligns with the concept of the rubber duck. The tool aims to be a co-pilot rather than the actual pilot. It is the programmer's assistant, their rubber duck.

The harsh reality

This message is for those who are anxious and concerned about the future of their programming careers: relax! But don't relax that much, because the harsh reality is that it is the fundamentals of software engineering that make a good programmer, not just the code.

With the popularization of computers for the general public in the 70s and 80s, accounting and finance professionals felt threatened by spreadsheet software. A machine that could store thousands of rows and columns and never make calculation errors. Who would reject that?

It is true that spreadsheets were and still are powerful, and they did pose a threat to "spreadsheet writers" jobs. However, those who interpreted the data, understood the business context, and applied accounting concepts certainly knew how to use spreadsheets instead of criticizing them.

Programmers are not mere code writers. Don't fear your new rubber duck, instead, use it. And thank you, ChatGPT, for helping me putting this article together.

A lesser-known vector for XSS attacks: SVG files

Vinicius Brasil — Mon, 20 Feb 2023 01:58:00 +0000

Cross-site scripting (XSS) is a type of security vulnerability commonly found in web applications. Attackers exploit XSS vulnerabilities to inject malicious code into a site, which can then be executed on the server or other users’ browsers. While modern web frameworks like Ruby on Rails and Phoenix offer built-in protections against basic XSS attacks, XSS is still a prevalent threat that can compromise sensitive user data.

The most common type of XSS attack occurs when a web application fails to properly sanitize user input before displaying it to other users. When a site fails to escape user input, attackers can inject HTML code, which can be particularly dangerous if it is malicious JavaScript code. If an attacker successfully injects JavaScript into a site, they can hijack user sessions, steal cookies, and even send passwords to external servers.

SVG files

One lesser-known vector for XSS attacks is the SVG image format. SVGs support JavaScript using the <script> tag, which can be exploited by attackers. Here is an example:

<svg>
  <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
  <script type="text/javascript">alert("xss");</script>
</svg>

For instance, imagine a user uploads an SVG file with a script embedded in it that steals their session cookie when viewed by other users on the same site. If the web application fails to sanitize the uploaded SVG and renders it as-is, the script will execute and the attacker can access the victim’s session.

Similarly, if the application proxies SVGs from an external source, an attacker could inject malicious scripts into the SVG file, and the web application will unwittingly serve the malicious content to its users. This can lead to various types of attacks, such as phishing, data theft, and session hijacking.

Putting shields in place

There are three common ways of preventing XSS attacks via SVGs:

Adding a stricter Content-Security-Policy header on the route that serves the SVG file.
Sanitizing SVG files by removing scripts before rendering.
Or converting SVGs to rasterized formats like PNG and JPG.

I’ve recently fixed this vulnerability on Plausible, an open-source analytics tool. You can check my commit here. The server acted as a proxy and loaded favicons from external sources to be displayed on Plausible’s site. I opted to add the stricter CSP header, meaning that any scripts included in the SVG file will only be executed if they come from the same origin as the webpage that is serving the file. Any attempt to load content from a different origin will be blocked by the browser.

By following best practices for secure coding and staying vigilant for lesser-known attack vectors like SVG, web developers can help protect their users’ data from the threat of XSS attacks.

Don't be protective of your code

Vinicius Brasil — Tue, 19 Jul 2022 15:57:11 +0000

You spent hours and hours writing code. You are ready to submit your changes for code review. *Notification bell rings*. Changes were requested, code suggestions, potential bugs, and clean code issues. You get pissed.

Let's imagine another situation. Your feature gets merged to production. Weeks later you get a message from operations saying something is not working. You get defensive and assume they must be using it wrong.

That is the result of being protective of your code. Even though I love coding, I'm confident the value I deliver is not code. The end of my work is not the code itself, but the product I'm building. However, it doesn't mean my code doesn't need to be clean and easy to read, as those are to make the product extensible in the future. Software engineers that are protective of their code, don't understand that programming is a tool. It's for sure crucial, but not the final work. True problem-solvers use their technical skills as a tool.

Seasoned engineers know code is merely the paintbrush for good art. Being protective of your code slows you down in the following ways:

You get offended when taking feedback
Makes you blind to potential bugs
Prevents you from learning from other developers
Causes you to think code reviews are personal
Closes yourself to criticism and advice

This is the second installment of short reads about common career problems engineers face. If that sounds interesting, I invite you to read "The fear of merging".

The fear of merging

Vinicius Brasil — Fri, 15 Jul 2022 14:43:14 +0000

You just opened a pull request. Wrote a detailed description. Asked for reviews. The notification bell is ringing. It's your colleagues commenting "LGTM". Hit the merge button and 10 minutes later you get error notifications from your code. You broke production.

That starts a cycle with most of your code submissions. You're told by the impostor syndrome you're not qualified for the job. You think you're not as good as other software engineers. Other developers (mostly Twitter stars) seem error-proof.

Let me tell you something you already know: everybody makes mistakes. Senior engineers, junior engineers, CTOs. The difference between a good and an average professional is how you deal with the incident. Good engineers do as follow:

Don't try to find the culprit but focus on solving the issue
Know how to differentiate a critical from a minor problem
Don't fear asking for help from other developers
Warn the team as soon as they notice a production issue (even if they caused it)
They're proactive in documenting post-mortem in written and searchable form for future reference. This includes technical details and potential business outcomes from the incident

You don't need to blame yourself. Production incidents don't happen just because of someone's code. It is a chain of causes that trigger a problem. And these causes aren't technical only. Good engineering environments do as follow:

Strong testing culture (automated and manual)
CI and CD tools integrated with code submissions
Error monitoring tools with real-time notifications
Healthy code review culture
Good communication culture and tools
Expect errors to happen and people to make mistakes

Organizations and teams must be expecting incidents to happen and builds a strong and healthy culture inside the engineering environment. This does not mean that incidents should happen often, but if they're happening, it's an opportunity for the organization to learn how to prepare better when it comes.

Pragmatic programmers ask why

Vinicius Brasil — Tue, 08 Mar 2022 14:18:18 +0000

There is something about progress that hides past decisions into new solutions. Throughout history, problems are solved with tools that generate other problems that are solved with other tools. This keeps looping until we forget the whys. "Why does almost every User-Agent starts with Mozilla? And what the heck is Gecko?", "why do we need Unicode?", "why do we need HTTPS?".

Thanks to open-source software you can be a great programmer without ever asking these questions. I'm not suggesting you solve those problems on your own, but asking why helps you develop a pragmatic critical thinking, which is different from mere curiosity. The bad side of curiosity killed the cat and can drive you unproductive. On the other hand, the pragmatic inquisitiveness results in usable knowledge.

As an example, knowing the decisions that evolved the web into HTTP/3 teaches you high-level software engineering that is not purely theoretical - which has its value - but practical. Bonus: if you're interested in learning this, I recommend you this MDN article about the Evolution of HTTP.

The good news is pragmatic critical thinking is a learned skill. I listed three habits to help you ask why to what matters. You may already be doing things to develop this skill, but being conscious about it accelerates this process.

1. Recognize your assumptions
The definition of assumption is "something that you accept as true without question or proof". If you mainly use object-oriented programming, you might fall into the error of assuming "one always need classes and methods to create a program". Or even "the time 23:59:60 is always invalid". Beware of the words "always", "must" or "should", as they usually indicate an assumption.

2. Debug your assumptions
Before asking why, ask if your assumption is really true. Use your logic to support your assumption, test it, and if it's shown to be false, go to the next step.

3. Seek answers
This is where curiosity gets killed and your good habit of pragmatic inquisitiveness will be established. You're building reusable knowledge that will help you question more and more.

All things considered, it's common to believe in falsehoods. Use it as a cue to support your habit of questioning pragmatically and enjoy the answers you find along the way.

Building a Knowledge Base From Your Notes

Vinicius Brasil — Wed, 27 Oct 2021 13:23:15 +0000

As a software developer, grocery buyer, master procrastinator, and theology student, notetaking is important to me. I have used plenty of tools that helped me keep to-do lists, take notes from my classes, and textbooks. Apple Notes, Evernote, Notion, Bear, Agenda, Notability, OneNote, Google Keep, paper and pen. I have literally tried all these. They are great tools, but when the number of notes starts growing, some problems start to raise:

Notes become hard to find
Even if the app has a #tag feature, you don't remember all of your tags to search
Full-text search does not scale
You can't easily link your notes
Older notes become obsolete
Older parts of your knowledge base go to waste

The main problem does not lie within the app, but the way we take notes. The human brain is non-linear: we jump from idea to idea, all the time. Your notetaking tool should work the same.

Zettelkasten

In my journey to find a solution, I found this strange and old method of taking notes called Zettelkasten, or slip-box in English. Niklas Luhmann, the creator of the method, was a highly productive social scientist with 50 books and over 600 scientific articles published. He could only publish that amount of articles thanks to Zettelkasten.

A Zettelkasten is a personal tool for thinking and writing. It has hypertextual features to make a web of thought possible. The difference to other systems is that you create a web of thoughts instead of notes of arbitrary size and form, and emphasize connection, not a collection. (zettelkasten.de)

Zettelkasten proposes a way of writing connected notes, and not just a collection of notes. Take Wikipedia as an example: it is not just a collection of articles, but a web of connected knowledge.

If you're at the Elixir programming language Wikipedia page, you might find a link pointing to Erlang, that points to Open Telecom Platform, that points to Ericsson, and so on. Luckily someone built a graph view to Wikipedia, and Elixir's graph looks like this:

You can learn more about this method in zettelkasten.de.

Obsidian

After studying the method and tweaking it to my own needs, I found this amazing notetaking tool called Obsidian. It is a powerful knowledge base on top of a local folder of plain text Markdown files that you can organize in whatever way you want.

Obsidian is my current choice for writing and organizing notes on any complicated subject. Feels like the closest anyone has come yet to realizing the promise of hypertext as a tool of thought. (Graydon Hoare, creator of the Rust programming language)

I take notes on almost every content I read or listen to. Podcasts, blogs, articles, books. Links help me to build a solid knowledge base. Everything is saved in Markdown files in my iCloud Drive - but you can use whatever you want, from your local disk to a GitHub repository. This ensures these notes will be with me for a long long time.

This is how the graph view of my notes looks like. A mix of Portuguese and English with links that just work.

And before you ask, here is a sample note I took from an article I read:

This guide helped me start with Obsidian. Hope this helped you in your notetaking journey.

Stupid users or stupid design?

Vinicius Brasil — Fri, 17 Sep 2021 15:33:04 +0000

As a developer, I often have to solve "bugs caused by users". A user mistakenly clicked a button that performed an unintended action a developer had to roll back. One might think the user is stupid but forgot to question the most important thing. Why the user did that in the first place?

This applies not only to digital products but to the real world too. That stupid door that you always push instead of pulling. Or the ketchup packet that you just can't open without tearing apart with your teeth - and sometimes leaving stains in your pants. Stupid things or stupid you?

Even the everyday things are poor in usability. And in the digital world, it is our responsibility to create products people can actually use. And they shouldn't need a manual to do so. The button that shouldn't be clicked was used because the design was bad - as the ketchup, and as the stupid door.

Jakob Nielsen, the guru of Web page usability by The New York Times, wrote 10 general principles for interaction design. They are called "heuristics" as they are broad rules of thumb and not specific usability guidelines. We can use this to create better, easy-to-use, and self-explanatory interfaces to our products.

Visibility of System Status
Match between System and the Real World
User Control and Freedom
Consistency and Standards
Error Prevention
Recognition Rather Than Recall
Flexibility and Efficiency of Use
Aesthetic and Minimalist Design
Recognize, Diagnose, and Recover from Errors
Help and Documentation

Next time blame the design, not the user.

Activating the native spell-checking on Vim

Vinicius Brasil — Thu, 12 Aug 2021 14:16:56 +0000

Developers write not only code but documentation, bug reports, commit messages. As a non-native English speaker, I always find myself using Hemingway App, Grammarly, and other similar tools. They help but it is quite annoying having to switch back and forth from my editor to these tools.

The good news is that Vim ships with a spell-checker. It can check for words that do not exist, wrong capitalization, and even words that were spelled wrong for the selected region.

To turn the spell-checking on, you can use this command:

:setlocal spell spelllang=en_us

You can also hook it to a specific file type, for example:

" this goes into your init.vim/.vimrc file
autocmd FileType gitcommit setlocal spell

Happy Vimming!

Functional Programming Asks For a Mutable Developer

Vinicius Brasil — Wed, 20 Jan 2021 22:28:36 +0000

The class you have been waiting for. It is your programming class in school and the professor offers you plenty of interesting and essential words: objects, classes, constructors, inheritance. You love programming! And that's programming, right? Well, that's one way of structuring your program. And a very thought-provoking way, as object-oriented programming feels quite natural to most people.

Later on, you got a job to work with Erlang, this programming language that you certainly did not learn in your classes. Erlang is a functional programming language. It's not that is better or worse than Java or C++. It's just different as it has a different paradigm. The thing is you have no classes, no constructors, no methods, no inheritance, and all the concepts you had learned as simply "programming". You try to use the same techniques you know but it just seems off.

You have to start thinking functionally. Not imperatively. Not object-oriented. This asks for a mutable mind. A mind that will have to sometimes shift between paradigms and understand fully all the differences between them. Immutability is a central concept of functional programming, but a mutable developer, that is up to change, is essential for learning a new paradigm.

Here are some tips for you to consider when learning FP:

Understand that a different paradigm means problems are solved differently
Master the concepts before jumping into libraries and frameworks. First-class functions, high-order functions, purism, recursion, immutability, type systems
Learn functional languages such as Erlang, F#, Clojure, Haskell to help you apply the concepts into multi-paradigm languages, such as JavaScript
Don't rush to learn the most complex topics as functors, monads, currying
Apply basic concepts to your day-to-day code gradually. Immutability and purism are two functional-thinking concepts that you can use in Ruby or JavaScript. That can make the code more testable, deterministic, and easier to read

The process to learn functional programming can be daunting and slow as new concepts are involved. It is not like learning Ruby from a Java background. It actually is like learning how to sail a boat knowing how to drive a car. It is completely normal to struggle at first, but mutate your mind to resiliency and always keep learning.

How This Art School From 1919 Has Influenced Ruby on Rails?

Vinicius Brasil — Fri, 04 Dec 2020 02:17:53 +0000

Before Ruby on Rails, web development was a different reality. Enterprise languages and frameworks cornered the market. No automated tests, complex solutions to simple problems, and other issues. DHH, a Bauhaus-rebel for its time, has transformed this scenario by thinking design-driven, developer-first, and, simple. Form follows function, they say.

Back to 2004

The birth of Facebook, the rise of Firefox, the iPod, and blogging. The most used web technologies were ASP.NET, JavaServer Faces, ColdFusion, and, PHP 3 with an enterprise mindset.

The Ruby programming language may be significantly known these days, but this Japanese language wasn't globally famous even when Rails was first released in 2004. Not just the language was uncommon, but Ruby on Rails had everything to fail:

Uncommon language
No enterprise database support (MySQL by default)
No Microsoft Windows support

Back to 1920s

At the end of WW2, Staatliches Bauhaus, or simply Bauhaus, the art school that was ahead of its time, was founded. It was one of the single most influential cultural movements of the 20th century.

Bauhaus reached far beyond architecture, but design in general, including graphics, typography, product and, furniture. Even Steve Jobs was influenced by Bauhaus in Apple's minimalist and revolutionary design. The main principles of the movement were:

Form follows function
Minimalism
Smart use of resources
Simplicity and effectiveness
Constant development
Paradigm shift
Uncomplicated beauty

Rails was created inside 37signals, currently Basecamp, a web software company founded in 1999. The company's design-driven philosophy relates to Bauhaus's thinking in many ways.

Simple interfaces are easier to use, easier to understand, more intuitive, faster loading, and easier to maintain than their flashy, image laden counterparts. Our work proves that simplicity doesn't have to look cheap, feel plain, or be downright ugly. (...) We believe usability should take precedence over "cool."

The Rails boom

In 2005 DHH presented "how to build a blog engine in 15 minutes with Ruby on Rails" in a libre software conference in Porto Alegre, Brazil.

Using a MacBook, the terminal, TextMate, and Ruby on Rails, the Danish programmer, David Heinemeier Hansson, creates a blog engine in 15 minutes using Rails generators. Revolutionary, seamless, minimal, simple, paradigm-shifting, uncomplicated. Ruby on Rails' philosophy was introduced to the community. Software development can be simple, minimalist, effective, and without bureaucracies.

In 2006, a year after this video, Ruby was the most popular programming language, according to the TIOBE Index. The mid-1990s Japanese programming language that wasn't planned for this specific use.

I knew Python then. But I didn’t like it, because I didn’t think it was a true object-oriented language—OO features appeared to be an add-on to the language. As a language maniac and OO fan for 15 years, I really wanted a genuine object-oriented, easy-to-use scripting language. I looked for one, but couldn’t find one. (Matz, creator of Ruby)

Ruby's rise is highly related to the Ruby on Rails paradigm shift. The Rails Doctrine, written by DHH in 2016, explains a bit more of the framework philosophy:

Ruby on Rails’ phenomenal rise to prominence owed much of its lift-off to novel technology and timing. But technological advantages erode over time, and good timing doesn’t sustain movements alone over the long term. So a broader explanation of how Rails has continued to not only stay relevant but to grow its impact and community is needed. I propose that the enduring enabler has been and remains its controversial doctrine. (DHH, creator of Ruby on Rails)

Footprints

The Bauhaus was a rebel for its time as Rails. Everything from Apple to Nike has been influenced by the school. Rails' credo has also influenced other programming communities, such as PHP, which now has Laravel, "The PHP Framework For Web Artisans", which was inspired on Rails. Phoenix, a web framework for the Elixir programming language that gives you peace of mind from development to production, was motivated by Rails.

All this strong influence creates a new default on web frameworks that have generators, tests by default, are simple, and adopt convention-by-configuration. Currently, it is expected for a web framework to have all these features that Rails first compiled.

Maturing and staying relevant

The Ruby on Rails web framework powers lots of services out there, including GitHub, Heroku, CodeClimate, TravisCI, and Shopify. It is indeed widely used and popular technology. But what makes Ruby on Rails so special among all the other options nowadays?

Nowadays every language has its Rails-like web framework. PHP with Laravel, Elixir with Pheonix, Java with Spring Framework. Ruby on Rails is not as disruptive as it was back in 2004. Every year Ruby developers have to answer the same question: "Is Rails dead in #{Date.today.year}?". The truth is Rails is still firm in its philosophy and are always improving. The last big releases included:

Action Mailbox, a new way to serve to route incoming emails to controller-like mailboxes for processing in Rails
Action Text, bringing the Trix editor to the framework
Parallel testing, allows you to parallelize your test using forks or threads
Webpack as the default JavaScript bundler
Active Storage, a modern approach of uploading files straight to the cloud
HTTP/2 Early Hints
Credentials, a new and secure way to store secrets

Not to mention Ruby 3 improvements and new features, such as Ractors (Erlang-like actor-model concurrency), typing definitions, and more.

Using Python To Visualize Internet Affordability Worldwide

Vinicius Brasil — Wed, 25 Nov 2020 22:29:24 +0000

vinibrsl / internet-affordability

🌍 Did you know that internet costs >20% of the average income in some countries?

Internet Affordability by Country

Access to the Internet is a basic human right, the United Nations declared in 2016, however, there are many countries that the Internet is still not affordable. In Europe, 87% of families enjoy Internet access, while that figure is only 18% in Africa.

This project shows that there are countries that Internet access costs more than 20% of the average monthly income of a household.

If you want to see the data with more details, here's the link to the full chart.

Why is the Internet so important?

The Internet is so embedded in our lives that sometimes we don't realize that it links to our human rights, such as the right to freedom of speech, the right to development, and the right to freedom of assembly.

The global coronavirus pandemic has revealed how dependent we have become on Internet access. Voting, telemedicine, studying, shopping…

View on GitHub

Using some data from Numbeo, a bit of Python and research I've made this project that shows that there are countries that Internet access costs more than 20% of the average monthly income of a household.

Access to Internet is a basic human right, the United Nations declared in 2016, however there are many countries that Internet is still not affordable. In Europe, 87% of families enjoy Internet access, while that figure is only 18% in Africa.

The global coronavirus pandemic has revealed how dependent we have become on Internet access. Voting, telemedicine, studying, shopping, among other things that we do without even realizing there are people that don't have Internet access.

Check out the project on GitHub and please star and/or contribute!

https://github.com/vnbrs/internet-affordability

Seeking for alternatives when working with bad software

Vinicius Brasil — Tue, 25 Aug 2020 22:59:02 +0000

Inevitably, we'll someday come across legacy software, inconsistent databases, or integration modules that simply don't work. It might sound wise to fix this software, especially if they're crucial to the business. The problem that refactoring costs development and validation time, and the business does not always have this time to invest, but at the same time needs the fix. How can we both deliver the business requirements in time and still not break everything?

In the past weeks, I've been dealing with integration problems that led to an inconsistent database. This database is queried weekly to pay our drivers (I work for a delivery orchestration company). With the discrepant dataset, the output of the report was also inaccurate. I couldn't fix all the integration problems we had to the next weekly payout, so I tried a different approach.

I had to pause my iterative way of working. That works for most of the cases and still works for my team. But we have to be questioners to our modus operandi and not just go with the flow. Some problems will need a special take. I had to break the loop of:

Finding the bug
Fixing the bug
Updating database retroactive data with the fixed bug
Creating another bug by accident
Loop

To gain time, what I did was to create a script that connects to all databases and all external services to generate this report. Instead of fixing the database inconsistency, the script fetched the data it needed to the report from all related services and processes it all in memory. It's not that processing data in memory is a bad practice, it just depends on the problem you have. Question your modus operandi.

The script, written in Elixir, is querying 3 different databases, performing joins in memory, grouping in memory, and getting missing data from 2 external services via HTTP. All of this running concurrently using Elixir streams with Task.async_stream/3, outputting a CSV file. I ran it first on my MacBook, but putting it on GKE (Kubernetes) made it even faster, as most of our infrastructure is on Google Cloud Platform.

The weekly report is solved, but still, we have integration and database inconsistency issues. That's planned to be solved in our iterative workflow, where it should be. Use the right tools, at the right time, in the right process. Change if needed. Loop.