DEV Community: Adrian Paul Nutiu

🏎️ When Bots Play Better: The One and Only Bot for KartWars.io

Adrian Paul Nutiu — Wed, 27 Nov 2024 19:09:03 +0000

📚 Intro

It was that day which found me wandering through multiplayer online browser games, just to stumble upon KartWars.io.

For those of you who don’t know, KartWars.io was a fast-paced multiplayer game where players controlled karts in an arena. The goal was simple: collect power-ups, outmaneuver your opponents, and survive for as long as possible while climbing the leaderboard.

I quickly got hooked, but as I played, an intriguing question popped into my mind:

What if I could create a bot to play this game for me?

Not because I didn’t enjoy the gameplay, but because the challenge of building something capable of navigating this chaotic digital battlefield seemed too fun to resist.

⚠️ Photosensitivity Warning

The following video involves fast-changing visuals that may trigger discomfort. Please proceed with caution.

Source code time 💪

kmataru / kartwars.io-bot

🚗 Intelligent self-control and fighting system of karts in the Kartwars.io multiplayer game.

Kartwars.io Bot Championship Edition

aka "Intelligent self-control and fighting system of karts in the Kartwars.io multiplayer game".

Welcome to the kartwars.io bot!

Goals

No global pollution
Easy to use
Easy to create and embed any strategy and tactic
Clean and well structured source code

Features

Easy installable
Easy customizable
Unlock all skins
Multiple tactics
Strong documentation
Visual debugging
Real time customization through dat.GUI

Installation instructions

If you are on chrome, download the TamperMonkey extension.

On other browsers, use the GreaseMonkey extension.

Once installed, click on this, and choose Install.

Go to kartwars.io, and enjoy !

Hotkeys

Key	Result
Ctrl + B	Toggle Bot enabled/disabled
Mouse wheel	Zoom in/out

Directory Contents

├── build                         # Compiled source code
├── doc                           # Generated documentation.
└── src                           # Source files.
    └── DracoolaArt.Bot.Kartwars  # Main VS project.
        ├── lib                   # Bot

…

View on GitHub

🧐 Reverse Engineering the Game

The first step in creating my bot was understanding how KartWars.io worked under the hood. The game communicated with the server using WebSockets - a technology for real-time data exchange.

Using the browser's developer tools, I tapped into and monitored WebSocket traffic and identified key messages that revealed the kart's position, velocity, nearby power-ups, and other players' movements. It was like peeking behind the curtain of the game mechanics - a fascinating insight into how the arena operated.

🏎️ Teaching the Bot to Drive

Armed with this information, I wrote a basic JavaScript to control the kart’s movement. Initially, it was clumsy - the kart zigzagged, fell out of the arena, and failed spectacularly. 🥲

I called that "AI", but we all know what it actually means. 🤣

As I refined the logic, the bot grew smarter. It prioritized moving toward power-ups and clusters of food, avoided enemies, and steered away from collisions just in time. Watching it make strategic moves was incredibly rewarding.

🎮 In-Game Power-Ups

Power-ups were the heart of KartWars.io, making the gameplay unpredictable and thrilling.

Programming the bot to use these effectively added layers of strategy to the project.

🛠️ Debugging with Visual Cues

To better understand the bot’s decisions, I added visual overlays directly into the game. These overlays included lines for the bot’s current path, enemy trajectories, and avoidance zones. This real-time feedback made debugging much easier and helped fine-tune the bot’s logic.

🎛️ Adding a Control Panel

To dynamically adjust the bot’s behavior, I embedded a control panel using dat.GUI. This lightweight library allowed me to modify parameters like speed, aggression, and strategy thresholds on the fly. It also enabled toggling strategies without editing the code, speeding up experimentation.

🧠 Used Techniques

Creating a bot capable of surviving and thriving in KartWars.io required several core techniques:

🛡️ Enemy Surrounding Detection

The bot analyzed enemy positions and trajectories to detect when it was surrounded.

It calculated escape routes and accelerated toward safety, steering clear of threats.

🛡️ Weapon-Based Enemy Avoidance

By identifying enemies equipped with specific power-ups, the bot created avoidance zones (polygons) around them. It avoided these zones unless it had a shield or a strong counterattack strategy.

🎯 Enemy Trajectory Prediction

The bot predicted enemy movements to dodge attacks or intercept projectiles.

For offense, it calculated precise interception paths to maximize missile hits.

⚔️ Dodge, Defend, Attack

The bot’s ability to dodge, defend, and attack made it a formidable player. It activated shields under attack, fired missiles at vulnerable opponents, and evaded dangerous zones. With trajectory prediction and strategic power-up usage, it was able to outmaneuver human players frequently.

🤖 The Joy of Watching It Work

The most satisfying moment came when the bot began outperforming me. Watching it survive longer, climb the leaderboard, and execute strategies in real time was exhilarating. While it occasionally exhibited “bot-like” quirks, its ability to compete with real players made the effort worthwhile.

📚 Lessons Learned

Building this bot wasn’t just fun - it was an invaluable learning experience. From reverse-engineering WebSocket communications to implementing real-time decision-making, I gained skills in problem-solving, debugging, and AI logic.

Though KartWars.io is no longer available, the lessons I learned continue to shape my projects. Whether it’s a game or a complex system at work, the thrill of breaking down problems and building innovative solutions remains unmatched.

📝 Closing Note

In competitive games, we generally dislike other players cheating by using bots.
That said, I have no excuse to offer in my defense - it's likely I ruined someone else's gameplay. 🙈

If you’ve ever tinkered with bots or automated something just for the fun of it, share your story—I’d love to hear about your experiences!

🎯 The Great CMS Migration Challenge: Tackling Complexity with Ingenuity and Automation

Adrian Paul Nutiu — Mon, 18 Nov 2024 19:58:02 +0000

📚 Intro

As I mentioned in my first article, 🦸‍♂️ Nobody Dreamed of Becoming a DevOps Engineer, today I'm going to share with you just how lazy I am - and how that trait turned into something remarkable.

About more than ten years ago, at my first company, I found myself working on a project that involved migrating a massive live website into Sitecore CMS. The task was far from simple, and it quickly turned into a significant challenge with moments of trial and error.

This is the story of how we navigated through a maze of technical hurdles, limited tools, and budget constraints to deliver a successful solution.

⚡ How It Started: From Manual Labor to Automation

Before diving into building a robust migration solution, my journey began with a simpler and, frankly, more exhausting task - manual content migration. 😭

Alongside my work on implementing the new website, I was also tasked with migrating content by hand. Day after day, I found myself copying and pasting text, images, and other assets. It didn't take long to realize that I despised this repetitive, draining work. 😨

Determined to break free from this mundane cycle, I began experimenting with automation.

Some might view it as laziness, but this laziness can evolve into a drive to envision automations. 🚀

🧗 Challenges

But first, let's see some of the challenges we faced.

🔒 Challenge 1: The Encrypted Database

One of our first challenges was dealing with an Adobe CMS database that had limited access and encrypted content. With no available documentation or Adobe CMS SDK to guide us, we had to gave up on doing any reverse-engineering to migrate content between CMS-es. 🤔

🕸️ Challenge 2: Static Crawling Is Not Enough

The initial idea was to scrape the website statically, crawling through all available pages and extracting the content... using PHP. The programming language I mastered at that time.
I can still hear my team leader's voice mocking the same words I'd been telling myself: I can do it faster in PHP. Just wait and see. 🤣🤣
(If you're reading this, I just want to tell "Thank you!" 🙇‍♂️)

Well, as it often goes with the best-laid plans, it quickly became apparent that static crawling wasn't enough. While PHP could handle scraping the static content, it wasn't designed to capture dynamically loaded data - like images, videos, and other media fetched through JavaScript, Flash (Is Flash Dead Yet? 😱 Yes, it is.) and other techniques. We were scratching the surface, but we needed something far more sophisticated to get the full picture of the website's content.

First trial and error - accomplished! 😅😅

This was only the beginning of what would become a much larger and more intricate challenge.

The good part in this small automation project is that it provided a bird's-eye view of the number of pages and assets we needed to migrate, helping us gauge the scope of the work.

🌐 Challenge 3: The Multilingual Nightmare

The multilingual migration became challenging due to inconsistent content structures across languages. Variants often had missing, misaligned, or differently formatted content, requiring custom logic to ensure accurate mapping and maintain integrity across all languages.

And personally, I don't know 30 languages to be able and tell for sure that I am copying the right Chinese content - for example - without passing it through Google Translate. 😅

🧠 Stepping Back: Designing the Solution

While working in parallel to implement the core functionalities for the website using ASP.NET with the Sitecore SDK, creating a foundation for the new CMS-driven system I got to the realization that static crawling was inadequate, it was time to take a step back and reconsider the approach. I needed to think through the requirements and architect a solution that would tackle the challenges of migrating dynamic content.
This process began only in my mind - an outline of what the solution would look like, how the components might fit together, and what new hurdles we might encounter.

Next came research, digging through resources, looking up technologies, and thinking about ways to stitch everything together. I also tested the field with my colleagues for each potential component and explored what might work, without telling them about the bigger picture. In those early stages, fear held me back from sharing it outright; I was unsure if my vision would work or be received well.

So, I built an initial proof of concept (POC) to start small and show it in action. It wasn't fancy - just a simple setup that navigated a web page using a custom browser component built on Internet Explorer (yes, not even Chromium). This POC could highlight elements, extract content, and output the data to the console.

Nevertheless the POC had success. And it was also the point when it clicked for everyone why I was asking all my question and test the field with them 🤯.

It started to be a dual effort: building a migration solution and ensuring Sitecore integration worked seamlessly.

🛠️ Building the Solution in `C#`

Codename: Octopussy
(Yes! Like the 007 movie with Roger Moore, from 1983 😅)

To get the content migrated properly, I had to develop several custom components, many of them from scratch, all in C#. Each of these components played a crucial role in making sure the migration was as seamless as possible.

🌐 Custom Browser for Navigation

The heart of our solution was a custom browser, built to navigate the website. This browser allowed us to manually or automatically navigate through pages, ensuring that we could capture not just static content but also dynamically loaded elements like images, videos, and other media.

🛡️ Reverse Proxy for Catching Dynamic Assets

To capture dynamically loaded content like Flash assets, images, and videos, I used a custom reverse proxy in combination with Fiddler, a web debugging tool.

Fiddler helped us monitor HTTP/HTTPS traffic, revealing how assets were loaded asynchronously. The reverse proxy acted as an intermediary, ensuring that all dynamic content, not just static pages, was captured and migrated into Sitecore CMS. This approach ensured we didn't miss any assets and kept the integrity of the original site intact during migration.

🌍 Translation with Google Translate API

Given that the website was multilingual, one of the trivial but necessary components we built was a translation feature. I integrated the Google Translate API to automatically translate page titles and content across different languages. But here's the tricky part: the structure and content were not consistent across languages. So, I had to add a text similarity check to match the correct content items for each language variant. This way, I ensured the translated titles corresponded to the right content in each language.

📦 Sitecore SDK Integration

Once we had the content, the next challenge was pushing it into Sitecore CMS. Using the Sitecore SDK, I built a service that handled the loading and saving of content into the CMS database. This service also ensured that the content was correctly mapped to the relevant Sitecore templates, ensuring everything from text to media had the appropriate structure.

⚙️ Dynamically Generated Assemblies

To make the system flexible and avoid constant restarts during development, I implemented a mechanism for dynamically building and versioning assemblies on the fly. These assemblies were required for templates, which were strongly typed. This was a game changer as it allowed us to add new templates or modify existing ones without restarting the service, making the entire process much more efficient.

🔍 XPath Rules for Content Extraction*

Given the complexity of the site's structure, I couldn't simply rely on traditional scraping techniques. Instead, I used XPath-like rules to match specific elements on each page - whether they were articles, images, or media files - and map that content into Sitecore's CMS. This was crucial for ensuring that content was categorized and saved properly.

💸 Why No Use of Expensive Tools?

At the time, there were other solutions available—powerful, "enterprise-level" (question mark) tools designed specifically for content migration. But those tools came with a hefty price tag of around €30k per month.
(Kapow! No! Really! That's how it's called. 😃)

The client, on the other hand, was only willing to invest €30k for the entire project migration. That's right, the budget for several months was the same as one month of using these premium tools. So, we had no choice but to roll up our sleeves and build our solution.

📦 The Sitecore CMS: Why Sitecore?

Sitecore, a powerful CMS platform, was not my decision but rather the result of a sales deal. Sitecore brought features that were essential for this project: multilingual support, robust templating, and an efficient publishing mechanism. Sitecore also allows organizations to customize their content based on language, which was critical for this project, given its global reach. We had to ensure all the content was migrated in multiple languages - a task made easier with Sitecore's multilingual capabilities.

Another key feature was Sitecore's template system. This allowed us to define the structure of content upfront, ensuring consistency across different types of content like articles, news items, and images. The ability to create and publish content quickly, while ensuring it was structured correctly, was invaluable.

🙋‍♂️ Lessons Learned: Asking for Help

One of the most important lessons I learned from this project wasn't technical. My team leader reminded me that I didn't have to do everything myself. There were moments where I felt overwhelmed by the complexity of the task, but knowing when to ask for help, and rely on others, was key. This mindset carried me through not just this project but many others down the line.

📈 Rate of Success: Automation and Content Fillers

In terms of the overall success rate, we achieved about 80% coverage through automation. The custom components I developed - such as the browser, reverse proxy, and integration with the Sitecore SDK - were effective at handling the bulk of the migration work. This meant that most of the content, including text, images, and media, was seamlessly transferred into the CMS.

However, there was still about 20% of the content that required manual intervention, which we covered using content fillers. This portion of the work involved sections of the website where content structures were too varied or complex to automate efficiently. Rather than spending additional time creating overly elaborate logic for these edge cases, we opted for a more pragmatic approach. The content fillers allowed us to populate those areas without going too deep into custom code for content that was often inconsistent across languages and formats.

This hybrid approach of automation and manual content filling struck the right balance, enabling us to meet the project's goals within the given time and budget.

🏆 Conclusion: A Journey Worth Remembering

Looking back, the migration project was challenging, full of unexpected roadblocks, but also incredibly rewarding. We built a custom solution from the ground up, integrated it with one of the most powerful CMS platforms available, and delivered a multilingual content migration that met the client's expectations - without breaking the bank.

This project remains one of the most technically challenging I've worked on, but it's also one of the most satisfying. From reverse proxies to dynamic assembly generation, we navigated a maze of technical problems, learning a lot along the way. And most importantly, we came out the other side with a system that worked.

💬 *Confession

The XPath rules weren't exactly XPath. 🙄 I used a custom syntax that resembled XPath, which worked for a while but became cumbersome over time. It was only months or years later that I realized using XPath would have been much better, especially if I had known about the HTML Agility Pack and its ability to fix broken HTML, allowing XPath to function properly.

Who knows... Having that in place might have significantly boosted the success rate, potentially raising it to 99%. Probably!

Even though Flash is no longer supported - and back then, it wasn't even on the deprecation radar - and the entire website has since been redesigned and rewritten, I'm still proud of what we accomplished. 💪

I think that anyone who has tackled a major migration considers it a milestone in their career. 🤔

Let me know in the comments if you've tackled any migration.
How did it go? What tools did you use?

🦸‍♂️ Nobody Dreamed of Becoming a DevOps Engineer

Adrian Paul Nutiu — Fri, 08 Nov 2024 15:01:02 +0000

"Hello World" 👋

Here we are, at the start of what I hope will be the first of many articles talking about my journey, not only as a DevOps engineer, but also as Developer.

Like many others in this field, I never dreamed of becoming a DevOps Engineer (and a Technical Lead, on top of it, but I don't want to brag about that 😇), but the path here was inevitable, almost like solving a puzzle I didn't know I had been assembling all along. 🧩

Nobody Dreamed of Becoming a DevOps Engineer

Let's be honest - nobody dreamed of becoming a DevOps engineer when they were a child 💭.
When I first began my journey in tech, DevOps wasn't even on my radar. My love for tech started when I learned my first "programming" language: HTML (pun intended) 😅. At the time, it felt like programming, and the thrill of building my first web page was unmatched. As a kid, I was amazed about what can be rendered from a simple HTML and a bit of CSS 😮.
But as I moved from static web pages to dynamic applications, things started to shift.

I began learning backend development, starting with PHP, then expanding into more structured programming languages like Pascal, C++, C# (Pascal? I already feel like a fossil by just saying that word 😆).
This opened doors to full-stack development, allowing me to work on both the frontend and backend of applications. But as my applications grew, so did the need to deploy them efficiently. That's when I stumbled into the world of pipelines, CI/CD, and cloud infrastructure management.

Suddenly, managing deployments manually wasn't enough. I needed to automate processes, manage infrastructure effectively, and deliver code seamlessly. This realization pushed me toward DevOps - and once I discovered the power of automations, I was hooked to it. ⚙️💻☁️

PS: C# is still my #1 programming language. 💗
Whenever I have some spare time I still play, experiment or implement something new with it. Why not!?? 🙂

Why DevOps? The Power of Automation

For me, DevOps was all about automation. ⚙️⚙️ I've never been a fan of ClickOps - the process of manually managing infrastructure through web portals. Clicking through the Azure portal to configure resources felt repetitive and draining, not to mention prone to human error. Every task I repeated manually seemed like a waste of time and energy. That's when the allure of DevOps clicked.

Automating infrastructure and deployments allowed me to focus on what really mattered - delivering value quickly and efficiently. DevOps gave me the tools to streamline repetitive tasks, reduce errors, and scale infrastructure effortlessly. Automation was, and still is, my main driver in this space. 🚀

Avoid the trap of trying to automate every tiny detail, as it can lead to losing sight of what's truly important. Attempting to automate the last 20% of processes may consume 80% of your time and energy, potentially derailing your overall progress.

PS: I'll tell you in another article about how lazy I am and how that thing drove to build an entire ecosystem of applications and services to automate tasks, saving me 1 MILION clicks and likely an equal amount of Ctrl + C / Ctrl + V actions. 🥴😵

Some of you might have already guest what this could be about, but Stay Tuned!

The DevOps Toolbelt: CLI, Scripting and Pipelines

One of the most exciting aspects of being a DevOps engineer is the variety of tools at your disposal. Whether you're automating infrastructure, managing deployments, or integrating security into your pipelines, you need a robust toolbelt to get the job done.

CLI Tools

As a DevOps engineer, you'll become best friends with command-line interfaces. From managing infrastructure with Terraform to interacting with cloud services through Azure CLI or AWS CLI and why not GitHub CLI, everything revolves around the command line. Automating these interactions is where the magic happens.

Sometimes, to be honest, CLIs can feel like an uphill battle - they can be daunting foes, especially when you're learning their quirks. But hey! There's always room for improvement everywhere.

Scripting

Knowing how to script is the bedrock of DevOps. Whether it's PowerShell, Bash or Python (did I really said that!? Python… 😨), scripting gives you the freedom to customize and automate just about anything. Think about those repetitive tasks that slow down your day-to-day operations - scripting can automate them away. For example, using PowerShell to configure environments or Bash to manage server tasks saves you hours of manual work. It's not just a time-saver; scripting offers flexibility to solve unique problems that a simple GUI can't address. You'll soon realize that scripts aren't just for local tasks - they're a vital part of CI/CD pipelines as well.

However, this doesn't mean you're limited just to scripting languages. For an instance, I'd like to see all my automations written in C# one day. Whether it's implementing functionalities in Terraform or CI/CD pipelines, you can use too C# for various tasks. There's a whole horizon.

CI/CD

Don't be afraid to use scripts in your CI/CD pipelines; and I'm telling you this because I was... I really was "afraid" to use scripting for a reason I cannot remember.

In fact, many aspects of continuous integration and delivery rely on scripting, from custom build steps to deployment automation. Tools like Jenkins, GitHub Actions, and Azure Pipelines allow you to embed your scripts directly into the pipeline or run them from separate files, giving you full control over the process. I suggest storing scripts in separate files to enhance testability, even within local development environments. If you're managing infrastructure, for instance, Terraform scripts can automatically provision resources as part of your deployment flow. With scripting, you can ensure consistency, automate rollbacks, and even integrate testing into every step of the pipeline. Once you get the hang of it, scripting in CI/CD becomes second nature, and the benefits in terms of reliability and speed are undeniable.

Automate Everything: NoOps

"NoOps" - (not) just another buzzword.
While still in its infancy, NoOps envisions a future where infrastructure management is fully automated - so much so that developers no longer need to worry about operations.

I envision building our internal tools and core components in a way that developers would genuinely "love" to use: Pipeline Templates, Configurations as Code, Infrastructure as Code—you name it. I see this concept as similar to an SDK.

While we aren't quite at NoOps yet, the concept illustrates just how far automation can go.

And remember! GitOps goes hand in hand with NoOps.
(Uuugh! Do I need to explain GitOps as well!?? 😩🙈)

Ok! I'll be quick: GitOps - Make sure you keep everything in repository(es). 😇

Different Faces of DevOps Engineers

Throughout my career, I've encountered many different types of DevOps engineers. Each comes from a unique background, and each has their own strengths and challenges. Let me introduce you to a few:

The Ops-Heavy Engineer: Lacking the "Dev" in DevOps

These engineers typically come from traditional IT operations. They are experts at managing servers, networks, and cloud resources but often rely on manual processes through GUIs and dashboards. They may be proficient at ClickOps but lack the coding skills needed to automate these processes. Their DevOps journey starts with learning scripting languages like PowerShell, Bash, or Python and mastering tools like Terraform or Ansible to automate their work.

The Dev-Heavy Engineer: Experiencing Ops for the First Time

On the other end of the spectrum, you'll find developers who are diving into the world of operations for the first time. They're skilled at writing clean code and building applications, but managing infrastructure, deploying applications, and troubleshooting cloud environments is new to them. Their challenge is learning how to integrate deployment pipelines and monitor infrastructure while maintaining the quality of their code.

The Balanced DevOps Engineer

The ideal DevOps engineer balances both development and operations
(🤚 Yep! That's me 😁). These engineers can write scripts, manage infrastructure, automate processes, and troubleshoot issues in production. This type of engineer represents the essence of DevOps: combining the development skills to build software with the operational know-how to deploy and maintain it seamlessly.

No matter where you start, each path is a valid entry point into the world of DevOps. Whether you're an ops-heavy engineer learning to code or a developer stepping into the world of infrastructure, there's room for everyone in this journey.

Getting Started in DevOps

Learn Coding: Pick up Python, Bash, or PowerShell to automate tasks.
Know the Cloud: Familiarize yourself with AWS, Azure, and/or GCP basics.
Master Git: Understand version control—branching, merging, and pull requests.
CI/CD Pipelines: Automate testing, building, and deploying code.
Infrastructure as Code: Use tools like Terraform to manage infrastructure via code.
Collaboration: Work closely with different teams for smooth delivery.

What to Expect from DevOps

Automation Focus: Replace manual tasks with scripts.
Always Learning: New tools and tech appear fast.
Problem Solving: Troubleshoot and scale infrastructure.
Teamwork: Work with developers, testers, and IT.
Process Ownership: Oversee software delivery.
Security: Integrate security into workflows.

Conclusion: Starting Your DevOps Journey

Whether you're an ops expert learning to code or a developer stepping into operations for the first time, the world of DevOps is vast and full of opportunities. The key is to embrace automation, continuously learn, and always be looking for ways to improve efficiency and scalability.
Whether you're targeting Azure, AWS, Google Cloud, Alibaba Cloud or other cloud provider, the concepts are the same.

This is just the beginning of my journey in writing articles, and there's much more to come. In future articles, I'll talk about different experiences I had along the way, dive deeper into specific tools, automations, and probably some other tips and tricks that can be used in the DevOps world. 🙏

So, stay tuned - there's a lot more to explore! 👀

Credits

Thanks to @koladev for the nice article that kickstarted in me the whole idea of writing articles.
🔗 How to Build Your Online Presence as a Developer

Thanks to @birghi for the persistence he showed by asking once in a while Hey! Did you publish your article? 😇
(Now it's my turn 😈)

Thanks to @dumebii for the nice article that pushed me to stop overthinking the writing of this article and just publish it 😉.
🔗 🚀 How to become a Technical Writer

Your first article is probably the hardest article you'd write

If you enjoyed this article and want to stay updated with my journey and future posts, consider giving me a follow! I'd love to connect and keep exploring DevOps, automation, and more together. 😊🚀

DEV Community: Adrian Paul Nutiu

🏎️ When Bots Play Better: The One and Only Bot for KartWars.io

📚 Intro

kmataru / kartwars.io-bot

🚗 Intelligent self-control and fighting system of karts in the Kartwars.io multiplayer game.

Kartwars.io Bot Championship Edition

Welcome to the kartwars.io bot!

Table of Contents

Goals

Features

Installation instructions

Hotkeys

Directory Contents

🧐 Reverse Engineering the Game

🏎️ Teaching the Bot to Drive

🎮 In-Game Power-Ups

🛠️ Debugging with Visual Cues

🎛️ Adding a Control Panel

🧠 Used Techniques

🛡️ Enemy Surrounding Detection

🛡️ Weapon-Based Enemy Avoidance

🎯 Enemy Trajectory Prediction

⚔️ Dodge, Defend, Attack

🤖 The Joy of Watching It Work

📚 Lessons Learned

📝 Closing Note

🎯 The Great CMS Migration Challenge: Tackling Complexity with Ingenuity and Automation

📚 Intro

⚡ How It Started: From Manual Labor to Automation

🧗 Challenges

🔒 Challenge 1: The Encrypted Database

🕸️ Challenge 2: Static Crawling Is Not Enough

🌐 Challenge 3: The Multilingual Nightmare

🧠 Stepping Back: Designing the Solution

🛠️ Building the Solution in C#

🌐 Custom Browser for Navigation

🛡️ Reverse Proxy for Catching Dynamic Assets

🌍 Translation with Google Translate API

📦 Sitecore SDK Integration

⚙️ Dynamically Generated Assemblies

🔍 XPath Rules for Content Extraction*

💸 Why No Use of Expensive Tools?

📦 The Sitecore CMS: Why Sitecore?

🙋‍♂️ Lessons Learned: Asking for Help

📈 Rate of Success: Automation and Content Fillers

🏆 Conclusion: A Journey Worth Remembering

💬 *Confession

🦸‍♂️ Nobody Dreamed of Becoming a DevOps Engineer

"Hello World" 👋

Nobody Dreamed of Becoming a DevOps Engineer

Why DevOps? The Power of Automation

The DevOps Toolbelt: CLI, Scripting and Pipelines

CLI Tools

Scripting

CI/CD

Automate Everything: NoOps

Different Faces of DevOps Engineers

The Ops-Heavy Engineer: Lacking the "Dev" in DevOps

The Dev-Heavy Engineer: Experiencing Ops for the First Time

The Balanced DevOps Engineer

Getting Started in DevOps

What to Expect from DevOps

Conclusion: Starting Your DevOps Journey

Credits

🛠️ Building the Solution in `C#`