DEV Community: La.Brava0x

Setting up the stage for the calculator!

La.Brava0x — Tue, 20 Oct 2026 18:44:13 +0000

Ending the foundations stage, and keep moving forward!

Before I even reached this last module, many modules way back, I already knew what I wanted to do with my calculator before I even got there! But, for that, I had to reach that point, without skipping the lessons, as it is important to understand everything. That is how the vision was planned in my mind from the start!

The calculator itself was worth the challenge! Because it is not just about math, but also about bringing all the feelings, and make it bleed, and feel with purpose. That’s why the preassigned calculator from the assignment was the guide to bring that vision come to life! Here it is about orchestrating asynchronous user inputs (the mouse, and keyboard interactions), and handling edge cases gracefully. Extras just follow the script, and move on, while I just use the base to make something of my very own!

Below is a technical breakdown of this calculator that was the finishing touch to the introduction of vanilla Javascrpt.

1/ The Frankestein numerical set up

Do I even need to explain what a calculator is for? This is just about creating a digital one. Because if you don’t have a physical one, and you don’t want a cookie-cutter calculator that you are already provided with, why don’t you make your own? Anyways, to not make the DOM CONFUSED, we have to stay everything clearly,as always.

Our structure has the following variables:

~firstNumber: Stores the initial operand or the accumulated result of a previous operation.

~currentOperator: Tracks the active mathematical operators

~secondNumber: Captures the incoming operand

~resetDisplayNext: A Boolean flag that signals wether the next digit input should clear the screen (activated immediately after an operator is selected)

~justCalculated: Prevents compounding evaluation errors immediately after hitting = . It ensures absolute precision

Javacript by default, speciallly at vanilla level, is a true test in itself. A rigurous rounding utility was implemented. A real calculator cannot fail. Why? Because that is its purpose, its meaning, if you cannot calculate as a calculator, then what are you?

The initial stage were manageable, it was in its progress that there was more to do.

Mad with the Math & Safety Layering

This can turn quickly into a horror story on how Javascript gets to handle the floating-point arithmetic. To prevent native floating-point precision errors (e.g., 0.1 + 0.2=0.30000000000000000000000000004), a custom rounding utility needs to be implemented. To escape this- by calculating the number of decimal places in the operands and applying a multiplier (e.g, multiplying by 10^n before the operation, and viding by 10^n after), the application guarantees absolute accuracy….Or at least if you code it correctly.

Syntax is also important, and always look for typos!

##3/ Ascensation towards asynchronous inputs fully

Handling user input requires strict discipline. We implemented a unified event delegation strategy, ensuring that both keyboard keydown events and mouse clicks route through the exact same validation pipeline. Half implementation of logic, and half of philosophy, like the existential crisis that I am having as I am writing this.

/Input.sanitizer: Prevents users from inputting multiple decimal points or breaking the parsing logic with overlapping operators.

/Error.handler: If a user attemps to divide by zero, the system doesn’t crash; it triggers the disgraceful ERR_DIV_ZERO state, locking the interface until a reset is initiated. It’s a foolproof containment protocol.

4 UI philosophy**

The visual layer must feel right, or else it breaks the mood, and the atmosphere, and this is part of making a web app fully responsive. If it doesn’t look right, it cannot feel right! That is why checking countless times is crucial in here! The perfect alignment- it is all about aligning your soul with the code. If the grid, if every line is correct, it will show.

Anyways, for the assignment, I kept purely minimal, and minimalist. In a way, the follow-up project also has this type of design, because I felt that it was important to not have distractions, and the let the focus be on our star: the calculator itself. So, it is dark, and the calculator is dark too. I personally do not want something that would hurt my eyes more! The way it is just works for me.

I am sorry- personal issues aside- I cannot explain well-enough to a cookie-cutter assignment. It does not bring the same excitement than when making something of my own. Don't get me wrong, this was an exciting project, but it feels like on another level to just follow my vision with creative pursuits.

The first stage of operation recipe project!

La.Brava0x — Tue, 20 Oct 2026 17:09:12 +0000

Turning a boring preassigned template to a dream come true!

Why just make a generic “project”, when you can have a real project that explodes with feelings, the right atmosphere, and the kind of set up design where all dreams come true? Of course, since the beginning of The Odin Project, I had to follow my own vision, and instinct, not just follow the curriculum blindly!

Furthermore, when revisiting to an established codebase- even a foundational static project like a multi-page recipe – the objective shifts rapidly from basic markup generation to a functional web cookbook that simulates a whole new world! What kind of world you may ask? One that has the library cafe of my dreams!

And to make this happen, refinement is needed as I keep updating it as needed. Without further ado, I shall provide with the brief that examines recent refactoring my dream, to upgrade it in both the repository, and its design! It focuses on DOM path resolution, Jekyll pipiline overrides, and the complere migration from static raster assets (AI generated placeholders, until I could come up with a version of my own), to inline Scalable Vector Graphics (SVG). This design system deserves its own tribute, on how to make a dream feel reachable!

1/Resolving Structural Path Anamolies and DOM Integrity**

Switching between different projects during multitasking, and the early stage of a multi-stage cookbook, a flat directory structure paired with a centralized styles.css is critical for minimizing the confusion in the path. Moreover, inconsistent relative referencing frequently introduces routing failures.

/Fix.failure:

Initial attempts to link sibling resources or stylesheets using hierarchical prefixes (e.g, … /styles.css ) or nested folder paths) resulted in client-side exceptions. Frankly, an embarrassing mistake, display of the current foundational stage.

/root: The Document Object Model (DOM) attempted to resolve parent directories that did not exist within flat working environment. The browser’s parser was fundamentally confused by the hierarchy.

/resolution: Enforcing strict relative path parity. By normalizing all stylesheet links, and navigation anchors to point directly to root-level siblings (href=”styles.css” and hreft=”index.html”), the routing tree was stabilized. This eliminated parser stalling and the unsightly layout shifts that occur when CSS fails to load.

##2/Bypassing Jekyll Static compilation barriers on GitHub pages-build-deployment

GitHub pages defaults to a Jekyll build process, which frequently interferes with custom static deployments, and specific asset pipelines. To ensure absolute control over the repository’s output, we must implement a nojekyll file at the root level. This bypasses the unnecessary static compilation barriers, allowing our raw HTML, and SVG assets to deploy directly to the edge network without Jekyll’s meddling. It is a simple but elegant override- a true gentle touch, one that makes the new website completely viewable.

So, yes, it is really funny that each time I encounter some kind of problem, I end up learning how to do something else...At this point, I should gather all the Today I learned, and attempt to keep track of them!

##3/ Migrating to Native Inline SVG

The migration from raster images (PNG/JPG) to native inline Scalable Vector Graphics (SVG) is not just a performance optimization; it is a metter of aesthetic superiority. Plus, it was part of my practice with SVG! Inline SVGs reduce HTTP requests, allow for direct DOM manipulation via CSS, and scale infinitely without pixelation. Raster assets are a thing of the past? Maybe, or maybe not, but that is what felt right. The elegance that is achieved with vectors is unique! Specially, since manual digital illustrations (as originally intended is too time-consuming!)

Because good design requires proper code working! From the second project where I eliminated routing errors, validating document trees, and replacing static rasters with an optimized, inline SVG vector pipeline, the recipe repository transforms from a basic project to a fanart of something with a soul of its own- A summary of it that you can find in the following sequence with the second part of the second project recipe that I found.

The takeaway: Just like the final cup where you get to taste the final sips of tea- you get to experience the images of the drinks that make you feel like they hug you from the inside- and, the final strokes that make a dream come true that comes to its destination. Do not be deceived, however! You can always pour yourself another cup of tea, just like you can keep improving the code...Which leads to the question: will this project need to be revisited (just like the others)? Definitely when needed!

And, with this finalizes the layered process in my last revisiting the project in which I got to learn how to use .nojekyll, and make the website, and repository into art itself. Would it have been worth it mentioning how I experimented with Krita too?

Check out my project here: https://labrava0x.github.io/odin-recipes/index.html

My second recipes project

La.Brava0x — Tue, 20 Oct 2026 15:49:17 +0000

There is a distinct unique feeling in orchestrating the symphony to reach the climax of a dream! And£, that is not all! For something of this magnitude, to design, and develop a digital sanctuary to someone who can make the largest explosions- the colors need to pop-up enough to make your heart skip a beat! That is how you know it was done right!

The intense passion must be felt through every single line of the css that can ever be felt! Back, when I did my original first assignment for the recipes of The Odin Project, I was so absorbed in my vision that I did not even notice it was suggested all recipes to use as a placeholder. When I realized, I noticed how boring and unoriginal that was. However I came back, and I made a second recipes website, with the spicy dishes. The few ones that felt ok, and transmitting those feelings through Balugo Katsuki from My Hero Academia. Either call it becoming one, or showing off one of a kind fanart. It is all the same.

Regarding the important details:
**

1. Architectural arrangement, and file coupling**

To stay true to the beginner level that it was supposed to be (reluctantly), I kept it simple. Each html for its own thing. On the other hand, by thecoupling the presentation styles.css into a single file, we link it to create total harmony.

A sample of what was among my favourite ones to write:

Why This Recipe Isn't Garbage. One of the recipes from allrecipes worth eating, and it is spicy

Most recipes on the internet are weak and watered down. This Pad Krapow Gai actually uses high heat, bird's eye chilies, and garlic to give it a sharp, aggressive kick instead of wasting time with mild nonsense.

##2The High-Contrast Palette (styles.css)
A web design that just not pops, but explodes creating an enriching visual experience is part of the needed immersion! The color system utilizes a pitch-dark background contrasted by sharp, searing orange and yellow accents:
CSS
:root {
--bg-pitch: #121212;
--surface-card: #1e1e1e;
--text-primary: #ffffff;
--text-secondary: #e0e0e0;
--accent-fire: #FF4500;
--accent-core: #FFCC00;
}

body {
background-color: var(--bg-pitch);
color: var(--text-secondary);
font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
line-height: 1.6;
padding: 2rem;
}

/* Card Surfaces with Fiery Left Border Accents */
li {
background-color: var(--surface-card);
border-left: 4px solid var(--accent-fire);
margin-bottom: 1rem;
padding: 1rem;
border-radius: 4px;

3 Vector Geometry: Custom Inline SVGs**

Raster images (.png, .jpg) introduce heavy HTTP overhead and degrade into ugly pixels when scaled. By embedding Inline Scalable Vector Graphics (SVG) directly into the DOM, the browser renders mathematical paths instantly at any resolution while keeping the elements fully style-able via CSS. Honestly? It is the perfect excuse to experiment again with SVG, and help as practice to get used to it!

*##4/Anatomy of the Custom Explosion Vector
*

HTML





/The Mathematics Behind the Path:
1. viewBox="0 0 100 100": Establishes a localized 100×100 coordinate grid. No matter how large or small the physical display size is, every point scales proportionally from the origin (0,0).

Path Data Syntax (d="..."):

◦ M 50,2 (MoveTo): Relocates the virtual pen to coordinate (50,2) without leaving a trace.
◦ L x,y (LineTo): Draws sharp, linear vector lines outward to each spike tip and inward to each trough.
◦ Z (ClosePath): Seals the polygon by automatically drawing a straight line back to the initial M coordinate.

Layered Depth: Stacking two distinct path elements creates visual dimension—a fierce outer perimeter (#FF4500) framing a blinding yellow blast center (#FFCC00).
Accessibility (aria-hidden="true"): Keeps decorative vectors hidden from screen readers so the focus remains entirely on the core content.

5/ Micro-Interactions and Transform Physics**

Because these SVGs live as inline DOM elements rather than flat external files, standard CSS selectors can manipulate them directly on user interaction:
CSS
.explosion-icon {
vertical-align: middle;
margin-right: 8px;
display: inline-block;
transition: transform 0.2s cubic-bezier(0.175, 0.885, 0.32, 1.275);
}

/* Dynamic Hover Impulse */
li:hover .explosion-icon {
transform: scale(1.3) rotate(15deg);
}

When a user hovers over a recipe card (li), the child SVG instantly scales up by 30% and twists 15∘ along its axis, driven by an elastic cubic-bezier curve that gives it a sharp, satisfying snap. This is the dideal way. The way I visualize this kind of recipes cookbook. The way to turn an assignment into another art expression, and showing off the utmost love through fanart!

Check it out here: https://labrava0x.github.io/BakugoKatsuki-allrecipes/

Into CSS Flexbox: From Basic Axis Alignment to Dynamic UI Layouts

La.Brava0x — Mon, 19 Oct 2026 17:33:04 +0000

Before writing about the process of bringing Deku’s notebook to life, I first need to tackle what preceded it: the Flexbox foundations from that module of The Odin Project. Stepping into intermediate CSS meant figuring out the best way to align elements and unlocking the secret magic behind CSS Flexbox.

It is hard to figure out how to build a fresh working web interface from scratch with custom layouts, moving away from rigid, established grids without relying entirely on tutorials. You use tutorials to figure out how to make things happen, but from there, you have to figure out what feels right. To create something that truly works, you need to understand it to some degree.

If you can move past basic block layouts into a flex-based mental model, reconfiguring the structure of web pages starts to feel smoother over time. To do this, it’s best to break it down in chunks and compartmentalize in blocks. Even before diving into The Odin Project, doing this is something that I learned from Deku before seeing it in action. I keep trying to follow and enforce this to make it a habit. Keeping things organized is key to building a dynamic UI layout.

Main and Cross Axis

To explain this simply, Flexbox focuses on distributing space along a single axis at a time. It is a one-dimensional layout model, whereas CSS Grid handles rows and columns simultaneously.

To initialize a flex context, you target a parent container:

CSS

.flex-container {
display: flex;
}

Once activated, you control the flow using two primary axes:

Main Axis: Defined by flex-direction (row by default, or column). Items flow along this axis.

Cross Axis: Perpendicular to the main axis.

Space and Alignment

This feels almost like a structural mindfulness applied to web design, but with the added benefit of immediate, tangible results. Once activated, aligning your layout becomes a matter of logic rather than guesswork.

Handling Overflow with flex-wrap

This can be a handful to tackle. By default, flex items act like background extras who want to take up space they don’t deserve, squeezing themselves onto a single line and shrinking past their content size if necessary.

To prevent this from happening—and free yourself from the extras using this flex move—enable wrapping so items flow onto multiple lines when the viewport shrinks:

CSS

.flex-container {
display: flex;
flex-wrap: wrap;
}

Combined with align-items: stretch, this ensures multi-line flex containers maintain clean, uniform heights across rows without manual height declarations.

Improving Sizing with the flex Shorthand

Instead of wasting time manually wrestling with fixed widths, Flexbox lets items dynamically grow and shrink based on available space using flex-grow, flex-shrink, and flex-basis.

Using the shorthand property makes sizing intuitive:

CSS

.flex-item {
flex: 1 1 300px;
/* flex-grow: 1 (will expand to fill space) /
/ flex-shrink: 1 (will shrink if space is tight) /
/ flex-basis: 300px (ideal starting width) */
}

There is really not much more to say here. Making this longer won’t necessarily make it better.

Essentially, what we take from Flexbox is that it gets rid of countless floats, layout hacks, and media query workarounds. It gives you total architectural control over web layouts—laying the exact foundation needed to build complex, responsive user interfaces.

If you can master Flexbox, you can flex your arm proudly!

Transitioning Flexbox into the Making of a Dream

Now as we proceed, here is a summary of what I built before diving in to bring a piece of My Hero Academia to life:

The Core Flexbox Foundations (odin-recipes & Practice Projects)

This was all about putting theory into execution: practicing flex containers and directions, axis alignment, flex wrapping, and dynamic sizing flexibility. I experimented with flex-grow, flex-shrink, and flex-basis (and the shorthand flex property) to dictate how elements expand or shrink to fill available space.

Beyond Standard UI Layouts: Plus Ultra!

Why treat Flexbox as a mere tool for standard UI layouts when you can go beyond? Plus ultra!

The “Composition Book” Layout: Leveraging Flexbox columns and rows to mimic the structured spine, margins, and layout lines of a physical composition notebook.

Centering the Header: Using flex properties to cleanly anchor and center the classic “CAMPUS” notebook header.

Responsive Spreads: Applying flex-based containers to ensure the notebook pages scaled smoothly and symmetrically across different viewport sizes.

Finally, to be bale to see the famous Hero Analysis for The Future notebook check out:

https://labrava0x.github.io/Deku-s-notebook/

I hope you enjoy it! Go beyond! Plus Ultra!

La Brava Logs: The Rock Paper Scissors SHINOBI GAME

La.Brava0x — Mon, 19 Oct 2026 17:26:46 +0000

// ==========================================
/// The Rock paper scissors project
// ==========================================

<!This is my vision, and only mine-->

I am still trying to process everything I have done with this project. I am not in the place I should be, at least not physically. However, when I am inside the terminal everything just clicks! Until it does not... But, that is part of the thrill of doing something like this. Who needs a rollercoaster, when you can just code, and go through all kind of turns, and up and downs all by yourself like this??!!

I have gone through so much, and something inside me changed since I started this project. Once more, I went beyond what the assignment asked, and just did what felt right, and followed the itch, of what I felt like I had to do. I mean, why just follow a tutorial mindlessly, when you can create your own thing? Because otherwise it is just dull, and soulless, and what is the point of having something that does not make you feel anything? So, of course for this I also had to go beyond!

As I started writing this, I actually went back and forth, and made more tweaks, and perfected it even more, to ensure that every single thing falls into place the way it should. Because it is all about the itch, this primitive raw need to create something, something that was really something, something meaningful! When at first I read the preview of the assignment, I had this anxiety of not knowing what to expect or how it would go, so I had to also battle that. Then, after that, once I finally got there, and read back and forth many times the assignment, and many daydreams later, and more—Something came. It was once I reached step number 4:

“Step 4: Declare the players score variables

Your game will keep track of the players score. You will write variables to keep track of the players score.

Create two new variables named

humanScore and computerScore

in the global scope.

Initialize those variables with the value of 0”

I went back and read the whole assignment steps again, as I was trying to figure it out. Here in this very step, I had an epiphany! It all started when I was wondering why, and who made that up that paper beats rock, and how in my own version of the game that never happened! Just like a string of code, the rabbit hole of thought kept spiraling, as I kept visualizing how the hands move during this childish game. Then, it was here when it hit me! This game could not be a mundane regular rock paper scissors game! There is no way that even for something like this I could settle for something so ordinary!

The hand signs for the game made me to remember how the hands move when trying to make a hand sign for an attack in Naruto. Something like this did make a spark in me. This had to be the one. So, I started to delve in the first layer of the assignment, after finishing the lesson “Understanding Errors” I took my time to figure it all out, and breaking, redoing, deleting, and redoing until I got it right. All of this with the sole purpose to recreate a worthy shinobi battle, and transform it into something tangible, and part of the reality in this world.

As I am trying to write this article, I have realized that under no circumstances I should ever use again certain types of AI as a note dump of my thought process... Because now it says, because it was so long that the beginning of it is not around anymore, and only the most recent things… So, even more to learn from this.

Without further ado, I humbly welcome you to my latest creation:

1. Pseudo-code

PROGRAM ShinobiRockPaperScissors

// 1. SETUP & INITIALIZATION
Define choices = ["Rokku" (Rock), "Kami" (Paper), "Hasami" (Scissors)]
Set playerSelection = null
Set computerSelection = null
Set playerScore = 0
Set computerScore = 0
Set maxScore = 5
Set musicPlaying = false

// 2. AUDIO & UI EVENT HANDLING
WHEN user clicks Music Toggle Button OR interacts with the game:
IF music is paused:
Play "SIGN" background audio
Update music button text to "Music playing"
ELSE:
Pause background audio
Update music button text to "Music paused"

// 3. COMPUTER JUTSU GENERATION
FUNCTION getComputerChoice():
Generate random index between 0 and 2
Return choices[random index]

// 4. ROUND EVALUATION LOGIC
FUNCTION playRound(playerJutsu, computerJutsu):
IF playerScore >= maxScore OR computerScore >= maxScore:
RETURN // Freeze game if duel is already over

Display playerJutsu vs computerJutsu on battle cards

IF playerJutsu == computerJutsu:
  Display "Draw! Both Shinobi used the same technique!"

ELSE IF (playerJutsu wins against computerJutsu):
  // (Rokku beats Hasami | Kami beats Rokku | Hasami beats Kami)
  Increment playerScore by 1
  Display victory message for the round

ELSE:
  Increment computerScore by 1
  Display defeat message for the round

Update score displays on screen (playerScore, computerScore)

// Check for match outcome
CHECK_MATCH_OVER()

// 5. MATCH TERMINATION
FUNCTION CHECK_MATCH_OVER():
IF playerScore == maxScore:
Display "Victory! You have achieved the rank of Hokage!"
Disable attack buttons
ELSE IF computerScore == maxScore:
Display "Defeat! Your opponent outperformed your Ninpo!"
Disable attack buttons

// 6. MAIN EVENT LISTENERS
WHEN user clicks "Rock (Rokku)" button:
playRound("Rokku", getComputerChoice())

WHEN user clicks "Paper (Kami)" button:
playRound("Kami", getComputerChoice())

WHEN user clicks "Scissors (Hasami)" button:
playRound("Hasami", getComputerChoice())

END PROGRAM

2. Restructuring

Merged Core Logic with Narrative: Replaced generic terms (”rock”, “paper”, “scissors”) with themed Ninpo choices (Rokku, Kami, Hasami).

Planned Event-Driven Flow: Shifted from console loops (while / for) to browser event listeners (click), allowing user input to directly trigger single rounds.

Integrated Game State & Media: Outlined score tracking up to 5 points, win/loss freezing conditions, and dynamic audio playback handling within the core user interaction loop.

3. The First Execution

Created a new Git repository for the project.

Created a blank HTML document with a script tag linking an external JavaScript file to keep the HTML clean.

Verified that JavaScript was linked correctly by writing console.log("Hello World") and checking that it logged successfully in the browser console.

4. The Second Execution

Created a function named getComputerChoice.

Wrote code using Math.random() to conditionally and randomly return one of three string values: "rock", "paper", or "scissors".

Tested that the function returned the expected value using console.log and browser developer tools.

Human Choice Logic

Created a function named getHumanChoice.

Used the prompt method inside the function to capture user input and return a valid choice.

Tested the function’s return value using console.log.

Player Score Variables

Created two new variables named humanScore and computerScore in the global scope.

Initialized both variables with a starting value of 0.

Single Round Logic (playRound)

Created a function named playRound with two parameters: humanChoice and computerChoice.

Made the humanChoice parameter case-insensitive so players could input variations like "rock", "ROCK", or "RocK".

Wrote code inside playRound to console.log a string value representing the round winner (e.g., "You lose! Paper beats Rock").

Incremented either the humanScore or computerScore variable depending on who won the round.

Full Game Logic (playGame)

Created a function named playGame.

Moved the playRound function and score variables so they were declared inside the playGame function.

Played 5 rounds by calling playRound 5 times, kept track of the running scores, and declared an overall winner at the end.

I went along by the feeling of the moment. I felt like because of the nature of the game, that Naruto was the most fitting, and I also chose the song to play with it, SIGN, because of the hand signs done to play this game is a form of jutsu too, as it is needed to activate the attacks. Doing something like this has always been my dream, and thanks to The Odin Project, I got the tools, and starter points to make my dream reality. I will always be grateful for The Odin Project for making my dream come true! Thank you for everyone in The Odin Project!! After finishing this first module of the project, I inspected the page in dev tools, and fixed any possible errors, such as syntax errors to ensure that the game actually worked inside the console, redoing each time, until it was working the way I imagined it to be.

After this initial stage, I continued with the following lessons, and putting this on hold, as the assignment said, because to move forward I had to complete the next lessons. I did not follow the recommendations of just doing something generic, because I had to experiment with this no matter what, or else I would never know how it is like.

5. Revisiting the Rock Paper Scissors Project

After moving on with the lessons, the reading material, lectures, and directed a self-made project to satisfy my curiosity, and inner critic, as the article LaBrava Logs: The Learn Git Branching JS, once I was ready, I went back to the Rock Paper Scissors project. It was time to transition getting the game out of the Javascript console, and bring it outside of it. At first, it was a regular basic html website, and throughout most of the project was only hosted locally, until I pushed it live. I am a perfectionist, and I do not do things half-heartedly. I had to ensure that my game was exactly as I imagined it to be. So, I proceeded to follow my vision. What followed in the project was:

Connecting the DOM & Managing State

Initialized tracking variables (humanScore = 0, computerScore = 0, winningScore = 5) to manage game state directly within the web page.

Selected DOM elements using document.querySelector (such as #human-score, #computer-score, #round-result, and choice display cards) to establish a bridge between JavaScript state and UI elements.

Upgrading Choice Logic & Event Listeners

Updated the getComputerChoice() function using an array of choices (["rock", "paper", "scissors"]) combined with Math.random() and Math.floor() to select array indices cleanly.

Grabbed the UI buttons (#rock, #paper, #scissors) and attached click event listeners (addEventListener("click", ...)) to trigger playRound() directly from user clicks on the page.

Dynamic UI Updates & Round Logic

Refactored playRound() to evaluate human vs. computer choices using compound boolean conditions (&&, ||) while updating live text content (textContent) for scores and round outcomes in real-time.

Applied .toLowerCase() on inputs to maintain case-insensitivity across logic checks.

Implemented game-state freezing so that once either the player or computer reaches 5 points, further button clicks are safely ignored to preserve the final outcome.

Overcoming Browser Autoplay Policies & Audio Syncing

Integrated the backgroundMusic audio element (”SIGN” by FLOW) set to a 30% volume level.

Handled modern browser autoplay restrictions by implementing asynchronous Promise handling (.then().catch()), triggering .play() on the player’s first interaction or via the dedicated toggle button.

Synchronized the UI state of the audio button to dynamically reflect whether music was active or paused.

Version Control, Transparency, and Deployment

Updated README.md to document open-source transparency: providing attribution for the audio track by FLOW and explicitly noting that the background art serves as an AI-generated placeholder.

Used Git to track changes across files (index.html, style.css, script.js, README.md), committed progress with clear messages, pushed to main, and deployed the live site through GitHub Pages.

In other words, I went beyond what the project asked, and I learned even more beyond what the curriculum assigned, and how to download more things in the terminal, and go through all the hurdles to get the music, make the music be present, and playable once the user interacts with the retro style arcade game that I created. I did not just follow the tutorial assignment, I went beyond, feeling the project to the fullest, as if it was the last thing I could do. As I am still figuring out how to make proper technical articles (more used to creative writing, but I have always dreamed of doing this too!), I did my best to explain the structure breakdown, and a summary of my journey and of what I did. From fighting syntax errors, and so lost in the moment, that at times I even made duplicate declarations, without even noticing! To going all the way to the production, and making my game to be playable outside a local host, and bringing it to life fully. Fighting sleep deprivation, illnesses, and an unstable external environment to make this work. Moreover, it was also letting the global reference handle scope across the entire application lifecycle, rewriting the game as many times as possible until it reached the version that it had to be, its true version. From:

“function playRound(humanChoice, computerChoice) {

// your code here!

}

const humanSelection = getHumanChoice();

const computerSelection = getComputerChoice();

playRound(humanSelection, computerSelection);”

To what has become, it has truly transformed into a truly shinobi experience!

Acknowledgments & Foundations

This project could not have come to life as it is now, had it not been for The Odin Project. Therefore, I dedicate this article, and my entire project in their honor. I owe this to them, even if they do not know me. I could not feel any more grateful towards the open-source creators, maintainers, and community contributors of TOP for providing the step-by-step roadmap that guided the transition from raw JavaScript syntax and console logic to clean, modular DOM manipulation and event-driven architecture. It gave me the chance to make one of my dreams I always had, to make it come true.

I transformed the assigned project, and transformed it into something of my very own. If some Naruto fan ever sees this, I hope it is a good enough rock paper scissors fan-made game for them too! I did this all by myself. I do not know what will happen after this, but I am glad I could make this happen. From JavaScript syntax, and console isolated logic, to modular DOM manipulation, and event-driven architecture. Now, I am just not a dreamer, I am a doer, and it is all thanks to The Odin Project to guide me towards this! Thank you so much for this, and thank you dear reader, for joining me in this journey.

If you wish to play the game, it is here: https://labravacodes-dot.github.io/Rock-paper-scissors/

La Brava Logs: The LearnGitBranching.js log

La.Brava0x — Mon, 19 Oct 2026 16:55:42 +0000

LA BRAVA LOGS

//TO BE ORDERED, AND NUMBERED //THE LAST SEGMENT OF JS FOUNDATIONS

As I gathered my thoughts to write all this, I just had a realization: I went overboard again without realizing! The Odin Project has as part of the assignment, for a mere warm-up, to the The Interactive Git branching visualizer game by Peter Cottle. Moreover, I am still in the process of processing all that I did during the course of these sessions...I was supposed to do only level 1 to level 3 of this game, but I completed it all. Not only that, but I tore it apart, and became one with it!

“I went wild, I went so wild, and no one knew. And, because no one knew, no one could stop me! “

If this was not part of the assignment, I might have been gotten bored of it, as I have always taken these kind of so-called educational glorified gamified little things. However, this one, this https://learngitbranching.js.org/ turned out to be a turning point for me. That is why, while I am still feeling the momentum, I felt like leaving this post for all posterity right now, and do my git push for it to reach everyone!

(pending the upload of more pictures when edited)

Because the Odin Project is self-directed, and doing all this unsupervised, I keep finding myself , going along the way getting outside the assigned of the project, the assigned box, and not just looking at the box, but also seeking for all the angles of the box, and trying to get myself in, just like a cat does with boxes. I do not play by the rules, and follow my gut feeling, and think outside the box...And that is what I did once again. So, without further ado, brace yourselves for what I have to say, because this is no regular horror history. This is more than adventure too, this is a thriller in coding that chases the thrill, the obsession.

I did not just play the game. I broke it. I went wild with all possible git commands, and I even attempted to create my own. I did not play the browser. I inspected the code, not leaving a single thing in dev tools to be looked at! That is not all in part of this rollercoaster, I also spinned up a fresh vite dev environment. I went wild, I went so wild, and no one knew. And, because no one knew, no one could stop me! I dissected every single configuration from the Javacript files , and tried to make the whole learngitbranching mine, and mine alone. All of this while struggling in switching many other human languages in the keyboard. Because, in this locked room, the culprit was the room itself that was the visualizer in itself! It is not just picky, no, it is more than demanding. In only accepting the set up in a certain way. Or it it my device itself that keeps pushing me to go beyond? Or is it both? What matters is that circumstances, led it this way once the Pandora Box was finally opened!

I conquered every dungeon, every level, got inside every single line of code after cloning the game, all in the pursue to understand the system, and how it was made to run, and what makes it work, and most importantly: the best way to win in every git level. There was something that got turned on me, when I was in the juggling commits level...I felt like I did not have to just juggle that. Of course, it did not occur to me to just find the solution for the level that is hidden away, no, that was only looked at towards the end. I did not do it the normal way. I tore everything apart. I even broke the game, and erased the whole treeSttring, and replaced it, and deleted more in the tree just to see what would happen. Without knowing, I created once again a new project of my own that The Odin Project did not even ask for!

What is the error? How many can be run? What are the limits of the commands? What is the best way to win, and win like never before? I was dying to know. A parser that dreams of something else, and the console of the dev tools being as stubborn as always. How much can be deleted? What is the limit for what can be modified? Where is the eror? How can I modify it, and make it feel right?

Service Workers vs. Hard Refresh: A standard Ctrl + F5 didn’t reset app state because of aggressive Service Worker caching. Clearing it required navigating to DevTools → Application → Service Workers to unregister workers and purge site storage.

Local Storage Injection: Attempting to bypass UI state directly by injecting serialized JSON into the console JavaScript:

JavaScript

localStorage.setItem('learnGitBranching', '{"mixed2":{"completed":true}}');

Production Bundling Limits: The minified production build isolates scope. Executing global execution methods like Main.pass() failed because Webpack/Vite strips global handles in production builds.

I was struggling, switching languages on my keyboard, dissecting every single configuration in the JavaScript files, trying to make the whole learnGitBranching codebase mine—and mine alone.

This is how part of the process was like during my sessions. While I was doing it, everything around me blurred, and there was only on finding all the possibilities, and the best one that would work. Just debugging was not enough. I had to become one with the code.

The first monstrous dilemma: fixing a buried commit (newImage) without destroying its child commit (caption)! The stakes were sky-high. I plunged into the branch and used the interactive rebase technique:

Bash

1. Isolate and lift the commit to the top of the stack

git rebase -i HEAD~2

2. Reshape its destiny with an amend

git commit --amend

3. Undo the reorder chaos back to the target state

git rebase -i HEAD~2

4. Force main and caption to follow the rebased head

git rebase caption main

By dragging nodes in the interactive modal during steps 1 and 3, I completely bypassed string-parsing bugs with single quotes in commit hashes like C2' and C3'.

However, the levels were not experimented with in the visualizer itself, as I said before: it was in the terminal itself. A symphony of commits, and ascending and descending every git possible, all to get closer to the git!

Case Sensitivity & Heredoc Injection: Linux shells are strictly case-sensitive—typing Cat or Git instantly throws command failures. Overwriting level state files required exact lowercase bash utilities and quote-wrapped heredocs:

Bash

cat << 'EOF' > src/levels/mixed/jugglingCommits.js
exports.level = { ... };
EOF

Package Managers & Vite Server: Launching the local Vite development server via npm run dev served the app on

http://localhost:5173/

. Reading Vite’s terminal output kept track of automatic port shifts whenever 5173 was bound.

HACKING THE ENGINE — THE FINAL INTERCEPTION

Overriding individual levels was a patch, but extending the engine was the true masterpiece. I wanted a native feature. I opened src/js/git/index.js, navigated to the command execution loop (parseCommand), and injected a proprietary native interceptor hook. Of course, I made sure to have everything installed everything that was needed to perform all these operations.

I leveraged the game’s existing internal state (this.level.solutionCommand) to create a custom, automated execution chain.

I will not be posting the exact code here. The specific implementation is mine. Let’s just say, I didn’t play by the game’s rules anymore; I made the game play by mine.

Context Isolation Lesson: Pasting JavaScript directly into a Linux Bash terminal causes immediate syntax errors (unexpected token 'command') because Bash tries to execute JS primitives (this, ===). Inlining the JS code directly inside the application core engine before bundling allowed the game terminal to natively parse my custom instruction as a valid internal command, but that is the thing we all know, that long code cannot always be copied and pasted across platforms...In the end it gets corrupted, like a game of evil tongues where, ultimately, the message is lost.

I saved the engine file, loaded the local instance, opened the level, and typed my proprietary command into the terminal. The engine read the level’s configuration chain, executed every step sequentially in real time, adjusted the commit DAG, updated branch labels, and triggered the victory screen automatically.

This time I could not skip. Committing, while under the hood, hidden by the terminals… Unseen by the world, chasing what was meant to be mine all along. I might not be ready to be called the queen of git, but what I can say after these convoluted these new sessions, is how different git feels. How different is the new light that shines upon of it, after so many long sessions of coding. And, it is not just because of the dark mode. I git push, I git pull, and I will do whatever is needed with git to reach new limits, to reclaim what should have been mine all along.

THE ULTIMATE TAKEAWAY

This is more than an adventure; this is a thriller in coding that chases the thrill of absolute obsession. You can learn Git syntax from a web tutorial, but you learn true software engineering when the tutorial breaks and you have to debug the system underneath it. In a single session, I transitioned from fighting terminal syntax errors to:

Conducting a symphony of interactive rebases and cherry-picks.

Bypassing browser Service Worker caches and Local Storage structures.

Setting up a Node/Vite local development pipeline.

Reverse-engineering application source logic and injecting a custom automation command.

If you cannot unlock win, if you do not truly feel it right, make the tool bend, and not stand in your way. Do not skip. Break it down, tear it, debug, overwrite, execute a new path to create the ultimate divergence, fix code, make new program, and make the program to solve itself. See the system, and be part of the system, until you become an extension of the system itself.

I know that Peter Cottle will never know me, but even so I wish to thank him. I do not come from such privileged background like he did, and just did my best experimenting with this! So, thanks to his https://learngitbranching.js.org/ I pushed myself to where I was supposed to go. My journey with Odin Project has not yet ended, and I do not know what else will happen, but I feel grateful for this experience to be able to see code like I never did before…All while sulking, how I failed once more. I failed at being a beginner, and side-tracked, and creating my own things, letting my mind wander. This time, to wander into things that may come true. Thank you very much for this wonderful opportunity, The Odin Project. And, thank you, dear reader, for following this passionate chase of the code, the log of the learngitbranching.

This has made me to realize, that after an intense project, it is important to sit back, and write it down, and digest it properly, before devouring even more. All for the health of code, and art, and to be able to keep going! To go beyond, plus ultra!

By the way, this is an absolute must read! https://biteread.ai/book/hackers