Bianca Correia

How I Researched My Way to a Mobile App Idea

Bianca Correia — Sun, 04 Oct 2026 04:02:21 GMT

Most people pick an app idea the way they pick a takeaway: whatever they happen to be craving that evening. I wanted to do it differently. Before writing a line of code, I decided to treat the idea itself as the most important thing to get right, and to spend real time researching before building anything.

This post walks through that research in three parts. First, the process I borrowed from a founder who has done it well. Second, the two ideas that came out of my own digging, each with the diagrams and working code I used to test whether it had substance. Third, what I learned about choosing between them. The code is deliberately small. The point of writing it was to find out whether each idea could stand on its own logic, not to ship it.

Starting with someone else's journey

The spark was an article I came across on Twitter, written by a founder who built a consumer health app to a substantial annual recurring revenue figure, largely on his own with AI doing much of the building. What stayed with me was not the revenue but the order of his process. He picked the idea carefully, tested whether people cared through short videos, and only then built the product. His argument was that now AI has made building cheap, the scarce skill is choosing the right thing to build.

His method for choosing was refreshingly practical. Spend time where real consumers spend theirs, on TikTok, Instagram and Reddit. Check keyword demand in the App Store with a tool such as Astro, looking for a market with some existing demand but not overwhelming competition. Then take a proven app and narrow its appeal to a smaller group of people, the way a meditation app might become a manifesting app, or a language app might become a chess teaching app. Only after that does the building start, and he says it should take a week or two rather than months. Figure 1 shows the routine I took from it.

flowchart LR
  A([1. Observe]) --> B([2. Measure]) --> C([3. Narrow]) --> D([4. Validate]) --> E([5. Build])

Turning the advice into a scorecard

Advice is easy to nod along to and hard to apply, so I made it concrete. For each candidate idea I rated five things from one to five: how much demand I could see, how big the gap in the market looked, how strongly I personally cared about the problem, how buildable it was for a very small team, and how clearly it could earn revenue. Demand and gap carry the most weight, because an idea nobody wants, or one that a dozen products already solve well, is dead on arrival however much I like it.

The ratings below are my own rough judgements, so treat them as a thinking tool rather than a measurement. Writing the weights down was the useful part, because it forced me to say out loud what I actually valued.

The two scores landed within a couple of points of each other, which told me something useful straight away: no amount of spreadsheet thinking would separate them. I would need evidence from real people. Before I get to how I plan to gather it, here are the two ideas themselves.

Idea one: a personal shopping layer that belongs to the customer

The first concept is a shopping account that belongs to the user rather than to Amazon, Google, TikTok or any single retailer. Think of it as a personal shopping brain across the entire internet. Instead of fifteen scattered wishlists on fifteen different sites, there is one intelligent home for everything you want, everything you already own, what you can afford and what you are waiting on.

What excites me is the shift from search results to decisions. Imagine telling the app you have £250 for a week in Paris in October, and that you already own a black trench coat, white trainers and dark jeans. Rather than fifty jumpers under £100, it returns a small capsule of pieces that work with what you own, combine into several outfits and stay under budget, and then explains its reasoning.

The architecture in one picture

Products arrive from wherever the user finds them, whether that is a pasted link, a screenshot, a typed name or a share from TikTok. They are turned into a clean product card, then filed into one account that the user owns. The decisions the user actually pays for sit on the right, and every one of them draws on the same personal data in the middle.

Shopping DNA as a data model

The real value is not in AI recommendations, which are quickly becoming commoditised. It is in a persistent profile that I have been calling Shopping DNA. It holds a typical spending range, a ceiling for spontaneous purchases and a threshold for investment pieces. It also holds style, the brands the user loves or avoids, fabric and sizing preferences, and habits such as waiting for sales or never being shown a duplicate of something already owned. Writing it as types made me notice how much of it is simple, structured data rather than anything mysterious.

Every item has a status

A universal list becomes far stickier once every product carries a status: want, waiting for a price drop, ready to buy, purchased, repurchase or no longer interested. Those states are really a small state machine, shown in Figure 3, and writing the allowed moves down stops the app from ever doing something nonsensical, such as offering to repurchase something the user never bought.

Turning a wishlist into a verdict

Take the example of a £120 serum spotted on TikTok. The user shares it to the app, which knows the lowest tracked price was £89, that the user's budget for this kind of product is £100, and that they already own two similar serums. The answer should be a plain word, not a score: buy now, consider, wait or remove.

Spending a budget wisely

The most useful feature in the whole concept is the question it answers: what should I buy first? That is a small optimisation problem. Each item has a price and a priority, the user has a budget, and the app should pick the combination that delivers the most priority without overspending.

Starting smaller

A simpler starting point came out of this research too. It is a wishlist where you add items by link, screenshot or name, set a monthly budget, and the app tells you what to buy now, what to wait for and what to save towards. Think of it as a budgeting app for shopping decisions rather than a rival to Amazon. Beginning in a single category such as beauty keeps it focused, since beauty combines frequent purchases, impulse buying, overlapping products and discovery driven by influencers. I also like the idea of missions, where you describe a need and the app assembles it within your budget and tastes.

Idea two: a research to task workspace

The second idea is a SaaS product rather than a consumer app, and it came from a frustration I recognise in my own work. Research and task management usually live in separate tools, so you end up switching between them and cross referencing by hand. The concept is built around a task tree rather than documents or folders. A project breaks into tasks and subtasks, and every saved web page, PDF, screenshot, quote or file attaches to the exact node where it matters.

flowchart LR
  P["Project: Launch beta"] --> CR["Competitor research"]
  P --> PR["Pricing"]
  P --> ON["Onboarding"]
  CR --> C4["Compare 4 rivals"] --> PP["Page: pricing page"] --> PDF["PDF: market report"]
  CR --> IN["Interview notes"] --> QU["Quote: user says"]
  PR --> TP["Test price points"] --> BM["Page: benchmark"] --> SP["Shot: paywall"]
  ON --> DQ["Draft questions"] --> UX["Page: UX article"]
  ON --> RP["Review prompt"] --> SR["Quote: store rules"]

The data model

A tree sounds exotic until you write it down. A single table of nodes, each pointing at its parent, covers projects, tasks and subtasks alike. Sources hang off any node, and tags sit alongside so that a topic can be pulled up across the whole tree. The tables below are everything the first version needs.

CREATE TABLE task (
  id         BIGSERIAL PRIMARY KEY,
  project_id BIGINT NOT NULL,
  parent_id  BIGINT REFERENCES task(id) ON DELETE CASCADE,
  title      TEXT NOT NULL,
  done       BOOLEAN NOT NULL DEFAULT FALSE,
  position   INT NOT NULL DEFAULT 0
);

CREATE TABLE source (
  id         BIGSERIAL PRIMARY KEY,
  task_id    BIGINT NOT NULL REFERENCES task(id) ON DELETE CASCADE,
  kind       TEXT NOT NULL,
  url        TEXT,
  excerpt    TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE tag (
  id   BIGSERIAL PRIMARY KEY,
  name TEXT UNIQUE NOT NULL
);

CREATE TABLE task_tag (
  task_id BIGINT REFERENCES task(id) ON DELETE CASCADE,
  tag_id  BIGINT REFERENCES tag(id) ON DELETE CASCADE,
  PRIMARY KEY (task_id, tag_id)
);

Opening a task shows everything at once

The promise of the product is that you never search two tools to reconstruct why a task exists. In database terms that is one recursive query: start at a task, walk down through its subtasks, and gather every source attached along the way.

Capture at the moment of saving

The behaviour that makes the whole idea work is that the user is asked which task a clip belongs to at the moment of saving, not later. That removes the inbox that every other tool leaves you to sort. A lightweight browser extension would send the page address, title and any highlighted passage, along with the chosen task, to the server.

Where it sits in the market

What convinced me this was worth considering was the gap analysis. Tools such as ONES and Draft lean towards general team task management, while Raindrop and Fabric lean towards general knowledge capture. Nobody I found combines both around a strict task hierarchy, which leaves a narrower but underserved audience.

Choosing between them

The scorecard gave me a near tie, and that matches how it feels. The shopping idea has the larger audience and the clearer consumer habit, but it also faces giants and needs data from many retailers. The workspace has a smaller audience and a visible gap, and it comes from a problem I feel myself, which makes it much easier to talk to the right users. Neither is obviously wrong, so the next step is not more thinking. It is the founder's own test: post about each idea as content, build a tiny mock up of the killer feature, and see which one makes people ask for the link.

What the research taught me

Four lessons stand out. First, spend as much time choosing as building, because a carefully researched idea saves months of wasted effort. Second, narrow the audience, since a clear problem for a specific group is easier to explain, build and test than a general solution. Third, validate before you commit, using content and conversations with real people to see whether anyone actually wants it. Fourth, and the one that surprised me, write the core logic down as code or diagrams early. Twenty lines of planner or a single recursive query showed me which parts of each idea were solid and which were wishful thinking, and it cost an afternoon rather than a month.

I am still weighing these ideas, but the process has already paid off, because I now know why I would choose one over another, not just which one I like best.

Building Scentfolio: A Full-Stack Fragrance Tracking Platform with Ruby on Rails

Bianca Correia — Tue, 09 Jun 2026 22:40:22 GMT

The Problem

It was time to put all I have learnt throughout my time at Le Wagon to the test. Hearing about how to build a full stack website was sounding easier than ever. However, I wanted to put myself to the test to build something outside of the construct of Le Wagon. No challenges that I had to follow broken down by steps nor being spoon fed what the code would be to decipher whether I pass a challenge.

I chose a niche that I find exciting: fragrances. Throughout the years I have been using websites hanging on by their last html line of code to gather my knowledge about fragrances. This interest came randomly but intensely. I was curious about the notes, the perfumer, and mostly excited to share my reviews on said fragrances.

However, I found the websites visually unappealing and underwhelming So for my first website, I wanted to collate and put to the test if I could create a full stack website for fragrance lovers such as myself, that was actually interesting to navigate. In turn, I would ultimately end up using what I have learned to create such.

Fragrance lovers often own multiple perfumes, sample new scents regularly, and develop preferences that evolve over time as your nose changes as we call it. Yet most people rely on memory, notes apps, or spreadsheets to track their fragrance journey. I wanted a better solution. That's why I built Scentfolio, a web application designed to help users track, discover, and cherish their fragrance experiences in one place.

From Idea to Application

The original vision was simple: create a digital fragrance diary web app, where users could record the scents they own and their impressions of each fragrance.

As development progressed, the project evolved into a full-stack web application featuring user accounts, fragrance collections, personal scent entries and analytics dashboards.

Technology Stack - Ruby on Rails

In Le Wagon we used Ruby on Rails because it provides a robust framework for rapidly building database-driven applications. Rails allowed me to focus on solving user problems instead of spending excessive time on configuration.

Database Design

The website app stores fragrance entries and user data in a structured database, enabling users to create fragrance entries, update scent notes, tack personal ratings and maintain a fragrance history over time.

Using Active Record made managing relationships and data persistence straightforward. Authentication and personalisation A fragrance journal is personal. To support this, I implemented user registration and login functionality, allowing users to securely manage their own collections and entries.

The User model uses Rails' built-in authentication framework.

has_secure_password

Email addresses are normalized before storage:

normalizes :email, 
with: ->(e) { e.strip.downcase }

This prevents duplicate accounts. Additional validations were used to ensure unique email addresses, minimum password length and proper email formatting.

Once the user is signed in, they are able to create fragrance diary, edit existing diary entries, view the analytics and maintain a unique fragrance hsitory. I ensured that the user data and fragrance data would remain separate.

The central model in the web app is the Entry model. Each entry represents a fragrance experience rather than simply a perfume bottle. This design allows users to record details such as fragrance name, brand, notes, personal rating, date worn, longevity and personal notes.

class Entry < ApplicationRecord
  OCCASIONS = [ "Work", "Evening Out", "Special Event", "Casual", "Date Night", "Sport", "Travel" ].freeze

  validates :fragrance_name, presence: true,
                             length: { maximum: 100 },
                             format: { without: /<[^>]+>/, message: "must not contain HTML" }

  validates :brand, length: { maximum: 100 },
                    format: { without: /<[^>]+>/, message: "must not contain HTML" },
                    allow_blank: true

  validates :notes, length: { maximum: 1000 },
                    format: { without: /<[^>]+>/, message: "must not contain HTML" },
                    allow_blank: true

  validates :occasion, inclusion: { in: OCCASIONS, message: "is not a valid occasion" },
                       allow_blank: true

  validates :strength, presence: true, inclusion: { in: 1..10 }

  validates :worn_on, presence: true

  scope :recent, -> { order(worn_on: :desc) }
  scope :this_week, -> { where(worn_on: 1.week.ago..) }

  def self.favorite_occasion
    where.not(occasion: [ nil, "" ])
      .group(:occasion)
      .order("count_all DESC")
      .count
      .first&.first
  end

  def self.avg_strength
    average(:strength)&.round(1)
  end
end

Treating entries as experiences rather than products creates a richer dataset and allows users to build a true fragrance journey overtime. The relationship structure is intentionally simple:

User has_many: entries 
Entry belongs _to user

This means the user can maintain hundreds of fragrance entries which preserving clear ownership and data integrity.

Data Validation

One of my priorities during development was ensuring that the database only stores meaningful and clean data.

Rails validations are used extensively throughout the Entry model. I made sure that data validations would be necessary when inputting the fragrance name, strength rating must fall between 1 and 10, dates the fragrance was worn would be mandatory, text fields would have length restrictions and finally HTML input would be blocked to rpecent malicious content and maintain data integrity.

validates :strength, 
presence: true, 
inclusion: { in: 1..10 }

To improve data consistency, fragrance occasions were restricted to a predefined list and to avoid duplicates. Rather than repeatedly writing database queries throughout the application, I used Active Record scopes to encapsulate common filters. This keeps controllers clean while making the code easier to maintain.

The web app followed Rails' RESTful conventions through the Entries Controller.

class EntriesController < ApplicationController
  def index
    @entries = Entry.order(worn_on: :desc)
  end

  def show
  end

  def new
    @entry = Entry.new(worn_on: Date.today)
  end

  def create
    @entry = Entry.new(entry_params)
    if @entry.save
      redirect_to root_path, notice: "Entry added successfully!"
    else
      render :new, status: :unprocessable_entity
    end
  end

  def edit
  end

  def update
    if @entry.update(entry_params)
      redirect_to entries_path, notice: "Entry updated!"
    else
      render :edit, status: :unprocessable_entity
    end
  end

  def destroy
    @entry.destroy
    redirect_to entries_path, notice: "Entry deleted."
  end

For routes, I used clean RESTful routing

: resources :entries

which automatically generated routes for index, show, new, create, edit, update and delete. Then I added custom routes for the analytics dashboard, user registration and user login.

Rails.application.routes.draw do
  root "pages#home"
  get "analytics", to: "pages#analytics", as: :analytics
  resources :entries

  get "sign-up", to: "sessions#new_signup", as: :sign_up
  post "sign-up", to: "users#create"
  get "log-in", to: "sessions#new_login", as: :log_in
end

Key feature was the fragrance collection management

Users can maintain a digital inventory of their fragrances, making it easy to organise and revisit their collection. One of the most interesting aspects of the project is the analytics section. Instead of simply storing fragrance data, the application helps users understand patterns in their preferences and usage habits.

Challenges Along the Way

Building a full-stack application introduced challenges beyond front-end development. Displaying fragrance data is easy. Turning that data into useful insights for users required additional thought around dashboard design. Because the data is stored in structured tables rather than unstructured notes, these insights can be generated efficiently through database queries.

What I Learned

This project helped me strengthen my understanding of Ruby on rails architecture, MVC design patterns, database design, authentication systems and full-stack application development. Most importantly, it reinforced the value of building software around a genuine passion.

Final Thoughts

Scentfolio began as a simple idea and grew into a full-stack web platform that combines technology with a personal passion for fragrance.

The project continues to evolve, but it has already become one of the most rewarding applications I've built because it solves a real problem for a community I care about.

Building software is always more enjoyable when it's connected to something meaningful, and for me, fragrance was the perfect place to start.

From Static HTML to Smart Templates: A beginner's guide

Bianca Correia — Wed, 18 Mar 2026 15:03:11 GMT

When I first started learning frontend development, I thought building a webpage meant writing a lot of HTML. If I wanted to show a list of movies, products, or anything repetitive, my instinct was simple: copy, paste, change the text, repeat.

It worked… until it didn’t. Recently, I learned something that completely changed how I think about building web pages, most web pages are really just data and a template processed by code to produce a document (usually HTML). Once this clicked, a lot of things suddenly made sense.

The Three Ingredients of a Web Page

At a high level, many modern web pages are built using three key pieces. Data, a template and processing logic.

Data can come from many places, such as a database, CSV, an API returning JSON . For example, a product API might return something like this:

{
  "product_name": "Coffee Beans",
  "product_description": "Origin: Burundi | Roasting: Light",
  "product_picture": "https://example.com/coffee.jpg",
  "product_price": "12 EUR"
}

When working with APIs, one of the first things you learn is to always inspect the structure of the data. Your code needs to know the exact keys available (product_name, product_picture, etc.) so you can display them correctly.

My First Instinct: Static HTML

Let’s say we want to display a list of movies. My beginner instinct would be something like this:

<div class="card">
  <img src="movie-poster.jpg">
  <h2>Harry Potter and the Sorcerer's Stone</h2>
  <p>2001</p>
</div>

Now imagine doing that 10 times. Or 1000 times. Suddenly we run into problems if we want to redesign the card layout or change the movies, would entail updating every single card or updating each block.

This approach breaks one of the first principles developers learn, to not repeat yourself (DRY). Clearly, we need a better way.

Making HTML Dynamic with JavaScript

Instead of writing every movie manually, we can fetch data from an API and generate the HTML automatically. For example, using the OMDB movie API:

fetch("http://www.omdbapi.com/?s=harry potter&apikey=YOUR_KEY")
  .then(response => response.json())
  .then((data) => {
    console.log(data);
  });

This gives us structured movie data like:

{
  "Title": "Harry Potter and the Deathly Hallows: Part 2",
  "Year": "2011",
  "Poster": "...",
  "imdbID": "tt1201607"
}

Now we can dynamically generate HTML using string interpolation.

const movieCard = `
<div class="card">
  <img src="${movie.Poster}">
  <h2>${movie.Title}</h2>
  <p>${movie.Year}</p>
</div>
`;

Then insert it into the page:

results.insertAdjacentHTML("beforeend", movieCard);

This already solves a huge problem, now we can display hundreds of movies automatically. The layout only needs to be written once but there’s still a downside. Now our HTML lives inside JavaScript, which gets messy quickly.

A Cleaner Solution: The `<template>` Element

One solution I learned about is the HTML <template> tag. It lets you store reusable HTML inside the page without rendering it immediately.

<template id="movieCardTemplate">
  <div class="card">
    <img src="">
    <h2>Movie Title</h2>
    <p>Year</p>
  </div>
</template>

JavaScript can then clone the template, inject the data, and render it.

const template = document.querySelector("#movieCardTemplate");

const clone = template.content.cloneNode(true);
clone.querySelector("h2").textContent = movie.Title;

This is already a big improvement because HTML stays in HTML. JavaScript handles the logic, the two concerns are separated but if the template grows bigger, we end up writing lots of querySelectors.

Enter MustacheJS

The next thing I learned about was MustacheJS, a templating library. Instead of manually filling every field, Mustache lets you insert data directly into the template using double curly brackets.

<h2>{{Title}}</h2>
<p>{{Year}}</p>

When rendered with data, it becomes:

<h2>Harry Potter and the Deathly Hallows: Part 2</h2>
<p>2011</p>

The magic happens with one line:

const output = Mustache.render(template, movie);

Mustache takes: the template, the data and produces the final HTML.

Rendering Lists Automatically

One feature I found especially cool is list rendering. Instead of looping in JavaScript, the template itself can handle iteration. For example:

{{#movies}}
  <h2>{{Title}}</h2>
  <p>{{Year}}</p>
{{/movies}}

Mustache will repeat that block for every movie in the list. Which means our JavaScript becomes incredibly simple:

const output = Mustache.render(template, { 
  movies: data.Search }
);
results.innerHTML = output;

Cleaner code, less logic, easier maintenance.

And Then There Are Frameworks

At their core, frameworks are just an evolution of the same idea, to take data, bind it to a template which keeps everything is sync automatically.

Frameworks also introduce components, which are like reusable mini-templates with their own logic. For example, instead of writing a movie card 100 times, you define it once:

<MovieCard :title="movie.title" :year="movie.year" />

Each has its own template, receives data and can be reused anywhere. This is basically templating, but scaled up in a really clean way. Frameworks combine a lot of things we've seen, such as templating, data binding and events handling. So instead of stitching together multiple tools, you get a structured way to build interactive apps.

Why This Feels Like a Turning Point

For me, this is where frontend development started to feel less like “editing HTML” and more like building systems. You’re no longer just rendering static pages, you're creating interfaces that update in real time, respond to user actions and stay in sync with data.

Final Thought (From a Beginner)

One thing I’m learning as a beginner is that there’s rarely a single “best” solution. Sometimes, static HTMP is perfectly fine. Sometimes, JavaScript interpolation is enough. Other times, you need templating libraries or a full framework. The key is understanding the trade-offs and choosing the right tool for the problem. And honestly, that’s one of the most exciting parts of learning to build software. You start seeing how the pieces fit together.

Learning Stimulus JS as a New Developer: My First Impressions

Bianca Correia — Thu, 12 Mar 2026 14:12:03 GMT

When you're learning web development, JavaScript frameworks can feel… intimidating. At least they did for me.

When I first started exploring frontend tools, I kept hearing about frameworks that required entire application architectures, build tools, component systems, and a bunch of concepts that felt overwhelming as a new developer.

Then I came across Stimulus, and it honestly felt like a breath of fresh air. Instead of replacing your html.erb, Stimulus does something much simpler. It adds Javascript behavior to the html.erb you already have.

As someone still learning the ropes, this approach made things click much faster. So here’s a quick walkthrough of what I’ve been learning about Stimulus and why I think it’s such a great tool for beginner developers.

The Problem I Kept Running Into

While learning backend development with Ruby on Rails, I noticed something. Rails is great at generating pages and handling server logic, but sometimes you just want small interactive features. My first instinct was to reach for plain JavaScript and start using things like :

document.querySelector()
 addEventListener()

Which works… but quickly becomes messy when your page grows. That’s where Stimulus comes in.

What Stimulus Actually Is

Stimulus is a lightweight JavaScript framework created by the team behind Basecamp. Instead of controlling your entire UI, it focuses on injecting behavior onto your html.erb. Stimulus works by connecting JavaScript to html.erb using data attributes.

At first this looked strange to me, but once I understood it, it actually felt really clean.

The Core Idea: Controllers

In Stimulus, JavaScript behavior lives inside something called a controller. A controller is just a JavaScript class.

When the page loads, Stimulus automatically connects this controller to any html.erb element that declares it, for example:

<div data-controller="example"></div>

That data-controller attribute is what links your HTML to your JavaScript. Once I understood that connection, everything else started making more sense.

Actions: Listening for Events

Stimulus also gives you a really clean way to handle events. Instead of writing JavaScript like this:

button.addEventListener("click", ...)

You define the event directly in your html.erb. For example:

<button data-action="click->disable-button#disable"> 
Click me 
</button>

This code is saying that we are listening for a click, using a disable-button controller and running the disable method.

When I first saw this syntax it looked weird, but after using it a few times it actually makes your html.erb very self-explanatory.

Targets: Accessing Elements Easily

One thing I struggled with early in JavaScript was selecting elements correctly. Stimulus solves this with targets. For example:

<div data-controller="disable-button">
 <button data-disable-button-target="button"> 
    Click me 
</button> 

 <a data-disable-button-target="link" class="d-none"> 
   Reset
 </a> 
</div>

Then inside the controller you simply declare:

static targets = ["button", "link"]

Now Stimulus automatically gives you: this.buttonTarget ; this.linkTarget. No querySelector needed. As someone still getting comfortable with DOM manipulation, this felt like a really nice abstraction.

My First Stimulus Feature

One of the first things I built was a button that disables itself and reveals a reset link.

import { Controller } from "@hotwired/stimulus"

export default class extends Controller { 
  static targets = ["button", "link"] 

  disable() { 
    this.buttonTarget.innerText = "Bingo!" 
    this.buttonTarget.setAttribute("disabled", "")
    this.linkTarget.classList.remove("d-none")
  }

  reset() {
    this.buttonTarget.innerText = "Click me!"
    this.buttonTarget.removeAttribute("disabled")
    this.linkTarget.classList.add("d-none")
  }
}

Stimulus + APIs

Another thing I tried was using Stimulus with an API to search for movies. The controller fetches data and inserts results into the page.

fetch(`http://www.omdbapi.com/?s=${query}&apikey=YOUR_KEY`)
  .then(response => response.json())
  .then(data => { 
    data.Search.forEach(movie => { 
      const movieTag = `
        <li> 
           <img src="\({movie.Poster}" alt="\){movie.Title}">
        </li> `
      this.resultsTarget.insertAdjacentHTML("beforeend", movieTag)
    })
})

Seeing real data appear dynamically on the page was one of those “okay this is cool” moments.

Why I Think Stimulus Is Great for Beginners

As a new developer, I think Stimulus is great because it:

builds on basic HTML and JavaScript concepts
avoids overwhelming frameworks
keeps JavaScript organised

Instead of forcing you to learn an entire frontend ecosystem, it helps you improve your existing JavaScript skills.

Final Thoughts

Learning web development sometimes feels like trying to drink from a firehose. There are so many frameworks, tools, and patterns that it’s easy to feel behind. What I like about Stimulus is that it doesn’t try to reinvent everything. It simply helps you write cleaner, more structured JavaScript on top of the HTML you already understand. And as someone still early in their software engineering journey, that approach makes learning feel a lot more manageable.

HTTP & API's

Bianca Correia — Mon, 09 Mar 2026 22:03:53 GMT

Making Things Clickable

If you’ve ever clicked something on a webpage that looks clickable… but absolutely nothing happens, you know that weird moment of confusion.

You hover. The cursor changes.
You click again.
Still nothing.

That was me recently while working through some front-end exercises. And weirdly enough, that tiny frustration ended up teaching me a lot about how the browser actually works.

I’m currently learning software engineering and documenting what I build along the way. Two exercises recently helped a bunch of things “click” (literally and figuratively):

building a multi-select sports picker using DOM events
building a geocoding tool that talks to a real external API

Both sound small, but they forced me to understand two really important pieces of web development, how to make a page respond to user actions and how to fetch real data from the internet and use it inside your app

Picture this: a grid of 6 sports cards. They look clickable. When you hover, the cursor changes. But when you click... nothing. Crickets. The fix sounds simple, but it taught me something fundamental about how the browser works.

Before writing a single line of JavaScript, I learned to ask: what actually needs to happen?

const sports = document.querySelectorAll('.sport');
 sports.forEach((sport) => { 
 sport.addEventListener('click', (event) => {                                    
  event.currentTarget.classList.toggle('active'
   ); 
 }); 
});

querySelectorAll grabs all matching elements as a NodeList

forEach loops over each one
addEventListener('click', ...) attaches a listener that fires on click
event.currentTarget the specific element that was clicked
classList.toggle('active') adds the class if absent, removes it if present

The CSS already had .active styles defined. My job was just to wire up the toggle.

One thing that surprised me early on: in JavaScript, functions are values. You can store them in variables and pass them around without calling them. This is huge for cleaning up nested code. The original code had 3 levels of indentation, not ideal. Here's the refactored version:

const toggleActiveClass = (event) => { event.currentTarget.classList.toggle('active'); };

const bindSportToClick = (sport) => { sport.addEventListener('click', toggleActiveClass); };

const sports = document.querySelectorAll('.sport'); sports.forEach(bindSportToClick);

Notice: forEach(bindSportToClick) ,no parentheses after bindSportToClick. We're passing the function itself as a callback, not calling it. This tripped me up the first time, but once it clicked , it felt like a superpower.

Talking to the Internet

An API (Application Programming Interface) is basically a door into someone else's server. You send a request in a specific format, they send data back. In web development, this usually means HTTP requests , the same protocol your browser uses to load every web page you've ever visited. The most common type for fetching data is a GET request. You're not sending anything new to the server, you're asking it to give you something.

In one of the challenges, I had to build a form where a user types an address, hits submit, and sees the GPS coordinates returned , using the Mapbox Geocoding API.

After signing up for a free Mapbox account and getting an API key, the documentation told me I can call:

"https://api.mapbox.com/search/geocode/v6/forward?q=Los%20Angeles&access_token=YOUR-API-KEY"

const form = document.querySelector('form');

form.addEventListener('submit', (event) => { event.preventDefault();
  event.preventDefault();

const address = event.currentTarget.querySelector('input[type="text"]').value; fetchCoordinates(address); 
});

Event.preventDefault() was a revelation. Without it, submitting a form causes a full page reload and wipes all your JavaScript state. To fetch the data, I wrote:

const fetchCoordinates = (address) => { 
 const apiKey = 'YOUR-API-KEY'; 
 const url = `https://api.mapbox.com/search/geocode/v6/forward?            q=\({address}&access_token=\){apiKey}`; 
 fetch(url) 
  .then(response => response.json()) 
  .then(data => { 
    console.log(data); 

    const coordinates = data.features[0].geometry.coordinates; 
    const longitude = coordinates[0]; 
    const latitude = coordinates[1];

    document.querySelector('#coordinates')
     .innerText = `Latitude: \({latitude}, Longitude: \){longitude}`; 
  }); 
};

A few things worth noting:

fetch() returns a promise, asynchronous code that resolves when the server responds
.then(response => response.json () ), parses the raw HTTP response into a JavaScript object
The data is deeply nested, data.features[0].gemetry.coordinates, always console.long(data) first and explore the shape of the response
Mapbox returns longitude first, latitude second

Going from "user types an address" to "here's a live map with a pin on it" using around 20 lines of code felt genuinely magical the first time it worked. The browser is an event-driven machine. Once that clicked for me, everything started making more sense.

Last Thoughts

Write pseudo-code first. It forces you to think before you type. Functions are values in JavaScript. Pass them around without calling them for cleaner callbacks. Always console log API responses first . I got to see how web pages go from static HTML… to something that actually reacts to users and pulls live data from external services.

JavaScript & the DOM

Bianca Correia — Tue, 17 Feb 2026 09:00:23 GMT

When I first started learning JavaScript, most of what I wrote lived in the console.

Variables changed.
Functions ran.
Numbers updated.

But the page itself?
It just… sat there. Frozen in time.

Then I started working with the DOM, and suddenly JavaScript stopped being just logic and started becoming interaction. Buttons responded. Lists grew. Content appeared out of nowhere. The page felt alive.

This article is about how a set of DOM challenges taught me what JavaScript is really for, changing what the user sees, without refreshing the page.

The DOM Is Not Your HTML File

One of the biggest mindset shifts was understanding what the DOM actually is. The Document Object Model is the browser’s internal representation of your HTML. It’s not the file you wrote — it’s the tree the browser builds from it. Which means your page is no longer static.

DOM Manipulation with Selectors

One of the challenges focused on using CSS selectors inside JavaScript to manipulate the page. The instructions were simple, to use our knowledge of CSS selectors to dynamically manipulate the page using JavaScript.

Learning JavaScript with the DOM helped me understand that web pages are not fixed once they load. Instead of JavaScript just changing numbers or running logic in the background, it can change what the user actually sees on the screen. The browser turns HTML into a structure called the DOM, and JavaScript can move through it, change it, remove parts of it, or add new content at any time.

The setup felt very “developer real-life”:

Run a local server:

serve

Open localhost:8000
Edit lib/dom.js
Refresh the browser
Watch tests turn green one by one

So instead of editing markup directly, I was doing things like selecting elements with querySelector,

const title = document.querySelector("h1"); 
const items = document.querySelectorAll("li");

Once elements were selected, I could change their content:

title.innerText = "DOM Manipulation in Action";

Traversing parents and children, I also learned how to add new elements to the page by creating nodes and inserting them into the DOM:

const newItem = document.createElement("li"); 
newItem.innerText = "New list item"; 
document.querySelector("ul").appendChild(newItem);

Removing elements was just as important, and showed how flexible the DOM really is:

const itemToRemove = document.querySelector(".old-item");
itemToRemove.remove();

Every refresh was feedback.

By practicing with challenges that involved selecting elements and updating them, I could see my code immediately affect the page. Building a fake email inbox made this even clearer, because new messages could appear without refreshing the page, just like in real apps such as Gmail. These exercises showed me that interactive websites work by using JavaScript to update the DOM again and again over time, turning simple code into real user experiences.

Building a Responsive Signup Form with Bootstrap (Without Losing Your Mind)

Bianca Correia — Thu, 12 Feb 2026 20:59:40 GMT

Forms are everywhere. Login forms, signup forms, checkout forms, newsletter forms… and yet, they’re one of the easiest things to mess up. Too wide on desktop, too cramped on mobile, ugly labels, confusing layout — we’ve all suffered through bad forms.

So today, I built a responsive signup form using Bootstrap, and along the way I learned how powerful (and friendly) Bootstrap’s grid system really is.

Let’s break it down.

Objective

The goal was simple:
Build a responsive signup form that looks good on all screen sizes. That means full width on mobile, centered and nicely sized on tablets and laptops, easy to read , easy to use and accessible. Sounds basic… but the trick is how you place the form on the page.

The Grid Offset Technique

Bootstrap’s grid system is built on flexbox. That means we can use alignment utilities to position our form exactly where we want it.

Here’s the layout:

<div class="container">

<div class="row justify-content-center">

<div class="col-12 col-sm-4">

<form action=""> <!-- Your form content --> </form>

</div>

</div>

</div>

What’s happening here?

.row is a flexbox

justify-content-center centers the form horizontally

col-12 → full width on mobile

col-sm-4 → takes 33% of the screen on tablets and larger

Bootstrap lets you scale your layout without writing complicated CSS.

Understanding HTML Forms

At its core, a form is just a collection of inputs:

<form action="#">
<label for="your-email">Your email</label>

<input type="email" id="your-email" placeholder="ana@gmail.com">

<input type="submit" value="Sign In">

</form>

Because when labels are linked properly, users can click the label and jump straight into the input, which is good accessibility.

Dropdown Lists

Dropdowns use <select> and <option>.

They work just like inputs — they just give the user predefined choices.

Styling with Bootstrap Form Classes

Bootstrap gives us ready-made form styles:

.form-control -> styles inputs and selects

.form-label -> styles labels

.mb-3 -> adds spacing between fields

.form-text -> small hint text

.btn & .btn-primary -> button styling

<form action="#">
<div class="mb-3">

<label for="email" class="form-label">Your email</label>

<input type="email" id="email" class="form-control">

</div>

<div class="mb-3">

<label for="password" class="form-label">Your password</label>

<input type="password" id="password" class="form-control">

<div id="password" class="form-text">Your password must be at least 6 characters long and contain letters and numbers.</div>

</div>

<input type="submit" value="Sign In" class="btn btn-primary">

</form>

This already looked professional with almost no CSS.

Accessibility: Hidden but Not Forgotten

Sometimes you want minimalist design with no visible labels. Bootstrap lets you hide labels visually but keep them readable by screen readers:

<form action="#">
<div class="mb-3">

<label for="email-simple" class="visually-hidden">Email</label> <input type="email" id="email-simple" class="form-control" placeholder="Email">

</div>

<div class="mb-3">

<label for="password-simple" class="visually-hidden">Password</label> <input type="password" id="password-simple" class="form-control" placeholder="Password">

</div> <input type="submit" value="Sign In" class="btn btn-primary"> </form>

This keeps your form clean, accessible and user-friendly. Never remove labels completely — just hide them properly.

Inline Forms (Side by Side Layout)

Want your inputs to appear on one line on desktop but stack on mobile? Bootstrap’s grid handles that too:

<form action="#" class="row row-cols-lg-auto">
<div class="col-12">

<label for="email-inline" class="visually-hidden">Email</label>

<input type="email" id="email-inline" class="form-control" placeholder="Email">

</div>

<div class="col-12">

<label for="password-inline" class="visually-hidden">Password</label>

<input type="password" id="password-inline" class="form-control" placeholder="Password">

</div>

<div class="col-12">

<input type="submit" value="Sign In" class="btn btn-primary">

</div>

</form>

On mobile: stacked. On large screens: inline. Zero media queries needed.

Final Thoughts

Bootstrap turns form-building from a painful chore into a design puzzle you can actually enjoy. With just a few classes, you get:

responsiveness
accessibility
clean layout
professional look

Forms might be “just inputs”, but when done right, they feel smooth, intuitive, and modern — and that’s exactly what users expect today.

Learning HTML & CSS Selectors by Building A Profile Page

Bianca Correia — Tue, 10 Feb 2026 21:24:24 GMT

When I started learning HTML and CSS, I quickly realised that writing content is only half the story. The real magic happens when you learn how to select elements and style them properly. To practise this, I built a simple profile page using semantic HTML and CSS selectors, while running everything on a local server.

This project helped me understand how structure (HTML) and design (CSS) work together.

Project Setup

Before writing any code, I had to organise my project properly. Inside my profile folder, I created a directory for images:

cd profile

mkdir images

code.

This keeps my project clean and makes it easier to manage assets like profile pictures and icons.

Running a Local Server

To preview my page in the browser, I used a local web server: serve

This command was already set up as an alias. Once it was running, I could visit my project at: http://localhost:8000

This showed my HTML page exactly as a real website would appear.

Dealing with Browser Cache

Modern browsers cache files to load them faster. This includes:

HTML files
CSS stylesheets
Images

Sometimes this means my changes didn’t appear straight away. To fix this, I used:

Cmd + Shift + R

This forces a hard refresh and clears the cache so the newest version of my code is loaded.

Building the HTML Structure

The goal was to build a simple profile page containing:

An image of myself
A header and sub-header with my name and job title
A short description
A button
A list of social links

I used proper semantic HTML tags instead of generic <div> elements:

<header> for the top section
<main> for the main content
<section> for grouped content

I also added useful metadata inside the <head>:

<meta charset=”utf-8”>
<title> My Profile </title>

This makes sure the browser understands the character encoding and displays the correct page title.

Accessibility Matters

One important thing I learned was how to write accessible HTML. For example, images should always include descriptive alt text for accessibility.

Instead of describing the purpose (“profile photo”), the alt text explains what is actually visible in the image. This helps screen readers and improves accessibility scores.

Styling with CSS Selectors

CSS selectors are how we tell the browser which HTML elements to style. This project helped me understand several important types of selectors:

1. Element selectors

These target all elements of a certain type such as body and h1.

2. Class selectors

These target elements with a specific class, such as .profile.card

3. Descendant selectors

These target elements inside other elements such as header h1

This only styles <h1> elements that are inside a <header>.

4. Attribute selectors

Useful for links and buttons such as a[target=”_blank”], this only styles links that open in a new tab.

Adding Icons with Font Awesome

To make the social links look nicer, I used Font Awesome icons by adding this to my <head>:

<link rel="stylesheet" href="filepath">

This allowed me to write:

<i class="fab fa-twitter">Twitter</i>

Because icons are fonts, I could style them easily using CSS (change size, color, or add hover effects).

The Importance of Indentation

One of the most valuable habits I learned is proper indentation. HTML has a lot of nested elements, and messy indentation makes code hard to read and debug. Clean indentation makes the structure obvious and prevents mistakes.

Finishing and Saving My Work

Once my profile page was complete, I pushed it to GitHub. Then I copied it into the next exercise folder:This let me reuse my work and build on top of it instead of starting from scratch.

Adding Fonts and Colors with CSS

After building the structure of my profile page with HTML, the next step was to bring it to life using CSS. This stage focused on choosing fonts and colors that make the page readable, visually balanced, and more personal.

To begin, I copied my existing profile into the new challenge folder and created a CSS file, I then linked this style.css file to my HTML document so the browser could apply my styles.

Styling the Body

I started by styling the <body> element. Since most text is inside the body, these rules affect paragraphs, list items, and general content.

body {
background-color: #f7f7f7;

font-family: 'Open Sans', sans-serif;

color: #333;

font-size: 16px;

line-height: 1.6; }

This showed me that:

font-family controls the typeface

font-size controls how big the text is

line-height controls spacing between lines

color sets the text color

background-color sets the page background

I also learned about color contrast, which is important for accessibility. Text must be easy to read against the background. Tools like the WebAIM contrast checker helped me test my color choices.

Styling Headers

Next, I styled the headings (h1, h2, h3) separately from the body text. This showed me how grouping selectors works. Instead of writing separate rules for each heading, I could apply the same style to all of them in one line. I also learned that modern websites usually use smaller headers than I expected. Looking at sites like Medium and Airbnb helped me understand that elegant design often comes from subtle sizing, not huge text.

Styling Links and Hover Effects

Links were another important part of the design. This introduced me to pseudo-classes, especially :hover, which lets CSS react to user interaction. I also learned about motion sensitivity. If animations or transitions are added, they should respect users who prefer reduced motion.

Choosing Fonts and Color Schemes

To make the page look better, I explored:

Google Fonts for typography
Coolors and Color Hunt for color palettes

For example, I imported fonts directly into my CSS file:

@import url("https://fonts.googleapis.com/css2family=Open+Sans:wght@300;400;700&family=Poppins:wght@300;400;500;700");

Then applied them, this taught me how external resources can be integrated into a project and controlled through CSS.

Working with the Box Model

The next step was to structure the page visually using the CSS box model. I reorganised my HTML into grouped sections:

<div class="container">
<div class="card"></div>

<div class="card">

</div> </div>

The container keeps the page content centred, while each card groups related information.

I styled the container like this:

.container {
width: 500px;

margin: 0 auto; }

This showed me how width controls the size of the layout and margin: 0 auto centres the content horizontally.

Designing Cards

Each card became a white box with padding, rounded corners, and a soft shadow:

.card {
background: white;

padding: 30px; border-radius:

5px; box-shadow: 0 0 10px rgba(0,0,0,0.1);

margin-bottom: 20px;

}

Here I learned how padding creates space inside an element, border-radius softens edges, box-shadow adds depth margin creates space between cards. This made the page look more like a real modern website instead of plain text on a background.

Learning Better CSS Selectors

A major lesson in this stage was learning how to name and organise CSS classes properly. It’s a better approach to use reusable classes. Therefore, we should use classes instead of IDs when styles can be reused. Choose names based on what the class does, not where it is and split styles into small reusable pieces instead of one giant rule.

Using the Browser Inspector

From this point onward, the browser inspector became essential. By right-clicking and choosing inspect, I could test CSS changes live, see which rules applied to which elements and experiment before writing final code. This made debugging and design much faster and helped me understand how CSS is actually interpreted by the browser.

Saving and Moving Forward

Once everything was styled and structured, I pushed my work to GitHub:

git add .

git commit -m "Added fonts & colors to my profile page"

git push origin master

Then I copied the project into the next exercise folder: cp -r profile ../filepath

Later, after finishing the box model and selector improvements, I repeated the process.

Final Thoughts

Building and styling my profile page step by step helped me understand how HTML and CSS work together in practice. What started as a simple page with text and images gradually became a structured and styled layout using fonts, colors, the box model, and well-chosen selectors. This process taught me that good web design is not about adding as much styling as possible, but about making thoughtful choices that improve readability, accessibility, and reuse. Learning to organise my CSS with reusable classes, centre content with containers, and group information into cards gave me a much clearer idea of how real websites are built. Overall, this project showed me that even a small page can teach big lessons about structure, design, and maintainability, and it gave me the confidence to keep experimenting with CSS as I move on to more responsive and dynamic layouts.

What I Learned About Active Record Migrations in Ruby

Bianca Correia — Mon, 09 Feb 2026 23:43:25 GMT

In this exercise, I learned how to use Active Record migrations to build the structure of a database using Ruby. Instead of writing SQL directly, migrations allow us to describe our database tables and columns with Ruby code.

I needed to create a poststable that can store links shared by users. The table needed a title, a URL, and timestamps.

I also learned that migrations are only used to change the structure of the database, not the data inside it.

Migration files must follow a specific naming format:

yyyymmddhhmmss_migration_name.rb

For example:

20260202152200_create_posts.rb

The timestamp in the filename is important because it tells Active Record which migrations have already been run and which ones still need to run.

Creating the Posts Table

To create the posts table, I wrote the following migration:

class CreatePosts < ActiveRecord::Migration[8.1]
def change create_table :posts do |t|

t.string :title

t.string :url

t.timestamps

end

This migration creates: a title column, a url column, created_at and update_at column using t.timestamps.

The timestamp columns are useful because they record when a post is created and when it is updated.

After writing the migration, I ran: rake db:migrate. Then I checked the database with: sqlite3 db/development.sqlite3 .schema.

I noticed there were more tables than just my posts table. These extra tables are created by Active Record and are used to keep track of migrations and manage the database internally.

Updating the Posts Table

Next, I created another migration to update the posts table. I added a new column called votes.

I created a new migration file with a new timestamp and wrote the following code:

class AddVotesToPosts < ActiveRecord::Migration[8.1]
def change add_column :posts, :votes, :integer, default: 0

This migration added a votes column, with a type integer and a default value of 0.

his means a post starts with zero votes when it is created.

I then ran the migration again: rake db:migrate

Now the posts table contains title, url, created_at, updated_at and votes.

In this exercise, I learned how to use Active Record migrations in Ruby to create and change the structure of a database. I created a posts table for a Hacker News clone with columns for a title, a URL, and timestamp fields for created_at and updated_at. I also learned that migration files must be named using a timestamp so Active Record knows which migrations to run and in what order. After running rake db:migrate, I checked the database schema and saw extra tables created by Active Record, which showed me that it also manages internal information about the database. Finally, I wrote another migration to update the table by adding a votes column with a default value of 0, which helped me understand that migrations are used to change the database structure, not to insert data.

How To Build a Store Interface Program

Bianca Correia — Mon, 02 Feb 2026 23:53:30 GMT

After the completion of one week, we were requested to build a store interface program that was the culmination of all we had learned throughout the first week. This included arrays, hashes, loops,blocks, conditionals, variables, gets.chomp and puts for output.

These on their own are quite straightforward but incorporating them all did present more of a challenge. The challenge was broken down in numerous steps which made it a little bit more digestible and enabled me to keep in top of the flow of the code and to better.

In this blog, I’ll walk through how to build a very simple supermarket-style program in Ruby. Something that lets a user see items for sale, choose what they want, and then get a total bill at the end. More importantly, it helped me understand how real systems (like online shops) might work behind the scenes, just in a much simpler way.

Displaying a welcome message

puts "> --------------------"
puts "> Welcome to Instacart"
puts "> --------------------"

Here we use puts to print text to the terminal.

This is purely for user experience. It makes the program feel like a real shop instead of just raw code. It also helps the user understand that the program has started. At first glance, this just looks like a list of items and prices. But conceptually, it acts like a tiny database. Each key is a product name, and each value is its price.

Creating the Shopping Cart

cart = []

The cart is an empty array.

Why an array?
Because we want to store multiple items that the user chooses, like:

["banana", "banana", "kiwi"]

Each time the user selects something, we will push it into this cart array.

Defining the Store with a Hash

store = {
"kiwi" => 1.25,
"banana" => 0.5,
"mango" => 4,
"asparagus" => 9
}

This is a hash, which stores key–value pairs:

Key → item name (string)

Value → price (number)

For example:

"banana" is the key

0.5 is the value

This makes it easy to look up prices later using:

store["banana"]

Which would return: 0.5. It means: “Take the user’s input and use it as a key to fetch the price.” That’s a big conceptual leap as a beginner — I’m no longer just printing values, I’m now connecting user input to data structures. This also means all the prices live in one place. If I want to change the price of mango, I only need to change it in the hash, and the rest of the program still works. That’s something real systems rely on heavily.

Displaying Items for Sale

store.each do |item, price|
puts "> #{item}: £#{price}"
end

Here we use .each to loop through the hash.

For every item in the store, item holds the name (e.g. "kiwi") and price holds the price (e.g. 1.25). This prints something like:

kiwi: £1.25

banana: £0.5

mango: £4

asparagus: £9

So now the user can see what’s available before shopping.

Preparing for User Input

item = nil

We initialised item so it exists before the loop starts. This is important because we are about to use it in a loop condition.

Creating the Shopping Loop

until item == “quit”

This line is what makes the program feel “alive”.
Instead of running once and stopping, the program keeps going until the user decides to quit.

This taught me that loops aren’t just for repeating actions — they allow the user to control the flow of the program. The code is waiting for human input and reacting to it. In a way, the program becomes a conversation. This helped me understand that software is often built around user behaviour, not just calculations.

Asking the User for an Item

puts "> Which item? (or 'quit' to checkout)"
item = gets.chomp

gets reads input from the user

.chomp removes the newline character at the end.

Checking If the Item Exists

if store.keys?(item)

This checks, is the user’s input one of the keys in the store hash?

For example: “banana” —> true, “pizza” —→ false

This prevents users from buying things that don’t exist.

Adding Valid Items to the Cart

cart < < items

If the item exists, we add it to the cart array. So the cart might look like:

[“banana”, “mango”, “banana” ]

This allows duplicates, which is realistic for shopping.

Handling Invalid Items

elsif item != 'quit'
puts "sorry we don't have any #{item} today."
end

If the user types something that is not in the store and is not "quit", then we print an apology message. This introduces the idea of validation: never blindly trust user input. Instead of assuming the user will always type a valid product, the program verifies it against the data. So learning to guard against misspellings, unexpected values or mistakes that may be inputted early on is really useful.

Printing the Bill

puts '> -------BILL---------'

This marks the checkout stage of the program.

Calculating the Total Price

total_price = 0
cart.each do |item|

total_price += store[item]

end

We start with total_price = 0, we loop through every item in the cart and for each item we look up the price in the store hash and add it to the total.

for example, —→ ["banana", "mango"] becomes 0 + 0.5 + 4 = 4.5.

This taught me that loops aren’t just for printing — they’re for transforming data.
Here, an array of strings becomes one meaningful number: the total cost. It also connects multiple concepts at once: looping through an array, accessing a hash and updating a variable. Which makes it a good mental workout as a beginner.

Displaying the Final Total

puts "> TOTAL: #{total_price} £"
puts "> --------------------"rub

This prints the final amount the user owes.

Example output: Total: 4.5£

This gives the program a proper ending and makes it feel complete.

I found that this store interface was a great beginner project because it felt practical and real. It simulates how real systems work: choosing products, validating input, and calculating totals. Beyond syntax,t his project taught me how arrays and hashes work together, user input connects to program login, data drives decisions and small programs can model real systems.

It was a great way to practice thinking in terms of data and flow rather than just individual lines of code.

What I Learned About Hashes and Symbols in Ruby

Bianca Correia — Mon, 26 Jan 2026 23:08:17 GMT

As I continue learning Ruby, one of the most important concepts I have encountered is the use of hashes and symbols. At first, these ideas felt confusing, particularly because of the unfamiliar syntax and the different ways data could be accessed. However, with practice and repeated exposure, I have come to understand how essential they are for organising and managing information within a Ruby program.

Over time (and after breaking my code a few times ), I realised that hashes and symbols are actually some of the most useful tools in Ruby. They help organise data in a clean way and make code easier to read once you understand them.

What is a Hash?

A hash is a way to store data using key values.
I like to think of it like a mini database or a dictionary inside my program.This structure is especially useful when working with related pieces of data that need to be accessed by name rather than by position, as is the case with arrays.

Here, “name” and “age” are keys, “Ana” and 25 are values.

person = {
“name” => “Ana”,

“age” => 25
}

Instead of remembering positions like in an array, I can just ask for what I want by name:

person [“name”]

This returns “Ana”,

At first, I used strings as keys in my hashes. Then I started seeing this everywhere:

person = {
name: “Ana”,

age: 25
}

I didn’t understand why there was no arrow (=>) and why the keys didn’t have quotes.
This is when I learned about symbols. A symbol is a lightweight, immutable identifier that is often used in place of strings, particularly as hash keys.

A symbol looks like this, and it’s different from a string:

:name
:age

Even though they look similar, Ruby treats them differently. Although they appear similar, strings and symbols are not interchangeable. If a hash uses symbols as keys, the values must be accessed using symbols as well. A big lesson for me was realising that this will not work:

person [“name”]

if the key is a symbol, that small detail caused me a lot of nil errors until it finally clicked.

Hashes in Ruby are mutable, meaning that their contents can be changed after creation.

Adding new data:

person[:job] = “Accountant”

Updating existing data:

person[:age] = 26

This made hashes feel more realistic to me, like real user data that can change.

One mistake I kept making was mixing up symbols and strings:

user = { name: “Ana” }
user[”name”] # nil

The correct way:

user[:name]

Hashes can be iterated over using the .each method, which provides access to both the key and the value:

person.each do |key, value|
puts “The #{key} is #{value}”
end

Iteration makes it possible to process or display all the data stored in a hash in a structured manner.

The main points I have learned is that symbols are faster than strings, more memory efficient and meant for things that don’t change (like keys).

Hashes and symbols were confusing at first, but now they feel like one of the most useful parts of Ruby. They helped me move from writing very simple programs to working with structured data. They still take practice, but now when I see a hash full of symbols, it doesn’t feel scary anymore — it feels familiar. And that, for me, is progress.

What I Learned From My First Ruby Backend Challenge

Bianca Correia — Mon, 26 Jan 2026 23:04:04 GMT

Starting my first backend coding challenge with Ruby was honestly a mix of excitement, confusion, and a lot of “wait… what?” moments . As a complete beginner, this was my first real experience writing backend code, and while it felt intimidating at times, it was also incredibly rewarding. This challenge helped me understand the basics of Ruby and reminded me that learning to code is all about taking things one step at a time.

Here’s what I learned from my very first Ruby backend challenge.

One of the first things I learned is that in Ruby we use the # symbol to write comments. Comments don’t affect how the code runs, but they are super helpful for us as beginners. I quickly started using them like a little to-do list or reminders to explain what my code was supposed to do.

I also learned about Ruby keycodes which tell the computer what action to take. One of the first ones I used being ‘puts’ which prints information to the terminal.Seeing my code actually print something on the screen felt like a small win, but a win nonetheless.

I learned that data types describe the data type we’re working with. Some I came across were integers, float, strings booleans mainly. At first, this was a bit confusing, but understanding data types helped me make sense of errors and understand why my code behaved the way it did.

I also learned that Ruby can handle basic maths like addition, subtraction, multiplication and division.

As soon as my programs started growing, I realised I needed a way to store more than one piece of data at a time. That’s where data structures come in. The main one I have learnt so far is array.

The challenge included experimenting with built‑in methods for different data types and then we had to also find other methods that were not built in.

This first Ruby backend challenge taught me that it’s okay not to understand everything straight away. I learned that backend development isn’t about being perfect — it’s about practising, making mistakes, and slowly improving.

I’m still very much a beginner, but this challenge made Ruby feel a little less scary and a lot more exciting. I’m looking forward to learning more, writing more code, and trusting the process — one line at a time

Early Days

Bianca Correia — Mon, 26 Jan 2026 22:58:46 GMT

I’m excited to share that I’ve officially joined Le Wagon and have started working through the prep work ahead of the course. This marks the beginning of a new chapter for me. One that is focused on learning, buildings and pushing myself outside my comfort zone. which historically, has always paid off, in new experiences, growth and lessons.

Before the bootcamp officially kicks off, I was provided by Le Wagon a set or prep exercises to get comfortable with he basics. It seems that early curiosity with writing code has paid off, as everything I have leant a few summers ago have come in handy,

One of the first tasks at the end of the first module was to create a personal profile about myself from scratch. Seeing how headings, paragraphs , images and sections come together made my page feel a lot more approachable and alive.

Another key part of the task was using an unordered lis. I used this to highlight things like my interests, It was a simple feature, but it really showed me how HTML helps organize content in a clean and readable way. I also added a link which was cool to add a little of interconnectivity to the profile.

This prep work has already taught my a lot:

How HTML provides structure to web content
How small elements like lists and links improve usability
How satisfying it is to build something from scratch
Learning to code is much about experimenting as it s about the rules

Even though the page was simple, it gave me a real sense of progress and confidence. I wasn’t just following instructions, I was creating something as a result of taking in that knowledge from the module.

This is only the beginning of my journey with Le Wagon, I’m looking forward to diving deeper int o web development, learning new languages and continuing to build projects that challenge me. For now, I’m proud of my first HTML page and excited for what is next. Onward and upward!✌🏽

Bianca Correia

How I Researched My Way to a Mobile App Idea

Starting with someone else's journey

Turning the advice into a scorecard

Idea one: a personal shopping layer that belongs to the customer

The architecture in one picture

Shopping DNA as a data model

Every item has a status

Turning a wishlist into a verdict

Spending a budget wisely

Starting smaller

Idea two: a research to task workspace

The data model

Opening a task shows everything at once

Capture at the moment of saving

Where it sits in the market

Choosing between them

What the research taught me

Building Scentfolio: A Full-Stack Fragrance Tracking Platform with Ruby on Rails

The Problem

From Idea to Application

Technology Stack - Ruby on Rails

Database Design

Data Validation

Key feature was the fragrance collection management

Challenges Along the Way

What I Learned

From Static HTML to Smart Templates: A beginner's guide

The Three Ingredients of a Web Page

My First Instinct: Static HTML

Making HTML Dynamic with JavaScript

A Cleaner Solution: The <template> Element

Enter MustacheJS

Rendering Lists Automatically

And Then There Are Frameworks

Why This Feels Like a Turning Point

Final Thought (From a Beginner)

Learning Stimulus JS as a New Developer: My First Impressions

The Problem I Kept Running Into

What Stimulus Actually Is

The Core Idea: Controllers

Actions: Listening for Events

Targets: Accessing Elements Easily

My First Stimulus Feature

Stimulus + APIs

Why I Think Stimulus Is Great for Beginners

Final Thoughts

HTTP & API's

Making Things Clickable

querySelectorAll grabs all matching elements as a NodeList

Talking to the Internet

Last Thoughts

JavaScript & the DOM

The DOM Is Not Your HTML File

DOM Manipulation with Selectors

Building a Responsive Signup Form with Bootstrap (Without Losing Your Mind)

Objective

The Grid Offset Technique

What’s happening here?

Understanding HTML Forms

Dropdown Lists

Styling with Bootstrap Form Classes

Accessibility: Hidden but Not Forgotten

Inline Forms (Side by Side Layout)

Final Thoughts

Learning HTML & CSS Selectors by Building A Profile Page

Project Setup

Running a Local Server

Dealing with Browser Cache

Cmd + Shift + R

Building the HTML Structure

Accessibility Matters

Styling with CSS Selectors

1. Element selectors

2. Class selectors

3. Descendant selectors

4. Attribute selectors

Adding Icons with Font Awesome

The Importance of Indentation

Finishing and Saving My Work

A Cleaner Solution: The `<template>` Element