DEV Community: Yannis Rizos

Two Hours to Find a Swapped String

Yannis Rizos — Fri, 14 Nov 2025 02:16:25 +0000

Early in my career, I landed a job where I was finally writing production code that mattered. The company had an ERP system and an e-commerce platform, and needed them to communicate with each other. My job was to build the integration layer that would keep product data flowing between them.

The requirements seemed straightforward enough. The ERP would send product information, my system would translate it, and the store would receive it. Both systems used product codes to identify items, and since those codes looked like ordinary strings, I treated them as ordinary strings. That's what the rest of the codebase did, and it felt like the natural choice.

function bridgeItem(erpCode: string, storeCode: string) {
  const record = readErp(erpCode)
  return writeStore(storeCode, record)
}

The function signatures looked clean. The calls looked reasonable.

bridgeItem(
  product.code,
  mapping.targetCode
)

As a sidenote, TypeScript didn't exist back then. The actual code was Java, but I really don't love Java.

For a While, Everything Worked Fine

Then, one afternoon, a product stopped appearing in the store. It should have been a quick fix. I expected to find some data validation issue or maybe a network timeout. Instead, I spent nearly two hours jumping between files trying to understand what had gone wrong. The system had multiple layers (controllers, services, helpers, integration adapters) and every function accepted plain strings. Nothing in the signatures gave me any hint about which string represented which concept.

By the time I traced the problem to its source, I discovered I'd passed the store code where the ERP code should have been. The function had accepted both values without complaint because they were both strings. The type system had nothing to say about it. I fixed the bug in about thirty seconds. Then I sat there feeling annoyed that I'd wasted two hours on something so trivial.

I remember thinking there had to be a better way to write this kind of code. Not some grand revelation. Just frustration mixed with the feeling that my tools should have caught this.

The Pattern Kept Appearing

Once I noticed the problem, I started seeing it everywhere in the codebase. We had product codes from the ERP, internal codes used only within our system, and store codes required by the e-commerce platform. Each type of code followed different validation rules and represented a completely different concept, but they all looked identical to TypeScript's type system.

type ProductCode = string
type InternalCode = string
type StoreCode = string

These type aliases were essentially documentation. They described intent without enforcing anything. The compiler treated them all as interchangeable strings, which meant I could accidentally pass one where another belonged, and the code would compile without warnings.

Boolean flags created similar confusion. One boolean meant the product was ready for sync. Another suggested it was active in the store. Another indicated whether the last sync had completed successfully. The names tried to communicate meaning, but the function signatures offered no protection.

if (isReady && isActive && isSynced) {
  runSync()
}

Numbers presented their own challenges. Some represented milliseconds, others represented seconds, and others represented retry attempts. Without examining the implementation, you couldn't tell which unit a function expected.

function scheduleRetry(delay: number) {
  setTimeout(runRetry, delay)
}

Calling this function with the wrong unit would compile successfully and fail at runtime.

scheduleRetry(5)

The pattern was consistent. I was using primitive types to represent domain concepts, and then compensating by scattering validation logic throughout the codebase.

Learning It Had a Name

A few years later, I was reading about common code smells when I came across an article on Refactoring Guru that described exactly what I'd been doing. It seems I was obsessed with primitives:

Primitive Obsession is a code smell that arises when simple primitive types are used instead of small objects for simple tasks

Reading that article felt like finding out other people had been dealing with the same problem. I hadn't invented a new way to write confusing code. I'd been following a well-documented antipattern. The validation checks I'd scattered everywhere, the confusion about which string meant what, the hours spent tracing values through multiple files: all of it was a predictable consequence of representing meaningful domain concepts as primitive types.

What I Would Do Differently Now

If I were building that old system today, I'd give each domain concept its own type. A product code wouldn't just be a string. It would be a class that knew how to validate itself and made its purpose explicit. In Domain-Driven Design, these are called Value Objects: small types defined by their attributes rather than any identity.

class ProductCode {
  private readonly value: string

  constructor(value: string) {
    if (value.trim() === "") {
      throw new Error("Invalid product code")
    }
    this.value = value
  }

  raw(): string {
    return this.value
  }
}

With this structure, the function signature communicates much more clearly what it expects.

function bridgeItem(
  erpProductCode: ProductCode,
  storeProductCode: ProductCode
) {
  const record = readErp(erpProductCode.raw())
  return writeStore(storeProductCode.raw(), record)
}

If I tried to pass a store code where an ERP code belonged, TypeScript would catch it immediately. The type system could finally help instead of staying silent.

The same approach works for other domain concepts. Time values become clearer when they carry their unit with them.

class Milliseconds {
  private readonly value: number

  constructor(value: number) {
    if (value < 0) throw new Error("Negative time not allowed")
    this.value = value
  }

  raw(): number {
    return this.value
  }
}

Now the scheduling function's signature tells you exactly what it needs.

function scheduleRetry(delay: Milliseconds) {
  setTimeout(runRetry, delay.raw())
}

You can't accidentally pass seconds or retry counts. The compiler won't allow it.

Some domain concepts benefit from carrying behavior alongside their data. A dimensions class can validate its inputs and calculate derived values.

class Dimensions {
  constructor(
    public readonly width: number,
    public readonly height: number
  ) {
    if (width <= 0 || height <= 0) {
      throw new Error("Invalid dimensions")
    }
  }

  area(): number {
    return this.width * this.height
  }
}

Each class enforces its own invariants. The validation logic lives in one place instead of being duplicated across the codebase.

Why This Approach Helps

Once you start wrapping primitives in domain-specific types, several things improve. You stop writing the same validation checks in multiple places. You stop worrying about mixing up parameters. Function signatures become self-documenting. The type system starts working with you instead of being indifferent to your mistakes.

Martin Fowler discusses Value Objects in his summary of the Evans classification. The key insight is that Value Objects are defined by their attributes rather than their identity. Two ProductCode instances with the same internal value are functionally equivalent, which is exactly what you want for this kind of domain modeling.

A monetary value makes a good example of this pattern in action.

class Money {
  private readonly amount: number

  constructor(amount: number) {
    if (amount < 0) throw new Error("Invalid amount")
    this.amount = amount
  }

  raw(): number {
    return this.amount
  }
}

Functions that work with money become more explicit about their contracts.

function publish(price: Money, discount: Money) {
  return applyRules(price, discount)
}

The signatures tell you what's expected. The classes enforce the rules. The compiler catches mismatches.

Where This Pattern Fits

This approach scales well across different types of systems. It works in integration layers where data crosses boundaries. It works in domain-rich applications where business rules matter. It works anywhere the cost of confusion exceeds the cost of creating a few extra classes.

Rico Fritzsche demonstrates these patterns in realistic scenarios in his example-driven walkthrough. His examples show how small domain types compose together in more complex flows.

Here's another example that keeps validation close to the data.

class EmailAddress {
  private readonly value: string

  constructor(value: string) {
    if (!value.includes("@")) throw new Error("Invalid email")
    this.value = value
  }

  raw(): string {
    return this.value
  }
}

Each type makes its constraints explicit. Each type protects its own invariants. The result is code where intent is visible and mistakes are harder to make.

What I Took From the Experience

I never went back and rewrote that old integration system. By the time I understood the pattern well enough to know how I'd fix it, the project had moved on, and so had I. But the experience stuck with me. Those two hours I spent tracking down a swapped parameter taught me more than any blog post could have.

These days, I try to use Value Objects by default. Not because of some architectural dogma. Not because Domain-Driven Design says so, though that's where they come from. Because the work becomes easier when domain concepts have an explicit structure. The code reads better. The compiler helps more. The bugs show up earlier.

Domain-Driven Design gave Value Objects their formal name and placed them within a larger framework, but the practical benefit stands on its own. When you stop representing meaningful concepts as primitive types, the code becomes easier to reason about.

That's worth the extra few lines of class definition.

Building a Chess Game with Python and OpenAI

Yannis Rizos — Sun, 24 Nov 2024 13:25:10 +0000

I enjoy coding small, silly things whenever I have some free time over the weekend. One such idea turned into a command-line chess game where you can play against OpenAI. I called it "SkakiBot," inspired by "Skaki," the Greek word for chess.

The excellent python-chess library takes care of all the chess mechanics. The goal isn’t to build a chess engine from scratch but to demonstrate how easily OpenAI can be integrated into a project like this.

Let’s delve into the code and see how it all comes together!

The Entry Point

We’ll start by setting up a basic game loop that takes user input and prepares the foundation for the chess logic.

def main():
    while True:
        user_input = input("Enter your next move: ").strip()

        if user_input.lower() == 'exit':
            print("Thanks for playing SkakiBot. Goodbye!")
            break

        if not user_input:
            print("Move cannot be empty. Please try again.")
            continue

        print(f"You entered: {user_input}")

At this point, the code doesn't do much. It just prompts the user for input, validates it, and prints it:

Enter your next move: e2e4
You entered: e2e4
Enter your next move: exit
Thanks for playing SkakiBot. Goodbye!

Adding the Chess Library

Next, we bring in python-chess, which will handle board management, move validation, and game-ending scenarios.

pip install chess

With the library installed, we can initialize a chessboard and print it before prompting for user input:

import chess

def main():
    board = chess.Board()

    while not board.is_game_over():
        print(board)

        user_input = input("Enter your next move (e.g., e2e4): ").strip()

        if user_input.lower() == 'exit':
            print("Thanks for playing SkakiBot. Goodbye!")
            break

Adding Move Validation

To make the game functional, we need to validate user input and apply legal moves to the board. UCI (Universal Chess Interface) format is used for moves, where you specify the starting and ending square (e.g., e2e4).

def main():
    board = chess.Board()

    while not board.is_game_over():
        # ...

        try:
            move = chess.Move.from_uci(user_input)
            if move in board.legal_moves:
                board.push(move)
                print(f"Move '{user_input}' played.")
            else:
                print("Invalid move. Please enter a valid move.")
        except ValueError:
            print("Invalid move format. Use UCI format like 'e2e4'.")

Handling Endgames

We can now handle game-ending scenarios like checkmate or stalemate:

def main():
    board = chess.Board()

    while not board.is_game_over():
        # ...

    if board.is_checkmate():
        print("Checkmate! The game is over.")
    elif board.is_stalemate():
        print("Stalemate! The game is a draw.")
    elif board.is_insufficient_material():
        print("Draw due to insufficient material.")
    elif board.is_seventyfive_moves():
        print("Draw due to the seventy-five-move rule.")
    else:
        print("Game ended.")

At this stage, you play for both sides. You can test it out by attempting Fool's Mate with the following moves in UCI format:

f2f3
e7e5
g2g4
d8h4

This results in a quick checkmate.

Integrating OpenAI

Now it’s time to let AI take over one side. OpenAI will evaluate the state of the board and suggest the best move.

Fetching the OpenAI Key

We start by fetching the OpenAI API key from the environment:

# config.py

import os

def get_openai_key() -> str:
    key = os.getenv("OPENAI_API_KEY")
    if not key:
        raise EnvironmentError("OpenAI API key is not set. Please set 'OPENAI_API_KEY' in the environment.")
    return key

AI Move Generation

Next, we write a function to send the board state - in Forsyth-Edwards Notation (FEN) format - to OpenAI and retrieve a suggested move:

def get_openai_move(board):
    import openai
    openai.api_key = get_openai_key()
    board_fen = board.fen()

    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "system", "content": (
                "You are an expert chess player and assistant. Your task is to "
                "analyse chess positions and suggest the best move in UCI format."
            )},
            {"role": "user", "content": (
                "The current chess board is given in FEN notation:\n"
                f"{board_fen}\n\n"
                "Analyse the position and suggest the best possible move. Respond "
                "with a single UCI move, such as 'e2e4'. Do not provide any explanations."
            )}
        ])

    suggested_move = response.choices[0].message.content.strip()
    return suggested_move

The prompt is simple, but it works well to generate valid moves. It provides enough context for OpenAI to understand the board state and respond with a legal move in UCI format.

The board state is sent in FEN format, which gives a complete snapshot of the game, including piece positions, whose turn it is, castling rights, and other details. This is ideal because OpenAI's API is stateless and doesn’t retain information between requests, so each request must include all necessary context.

For now, the model is hardcoded as gpt-3.5-turbo for simplicity, but it would be better to fetch it from the environment, as we did for the API key. This would make it easier to update or test with different models later.

The Final Game Loop

Finally, we can integrate the AI into the main game loop. The AI evaluates the board after each user move and plays its response.

def main():
    board = chess.Board()

    while not board.is_game_over():
        clear_display()
        print(board)

        user_input = input("Enter your next move (e.g., e2e4): ").strip()

        if user_input.lower() == 'exit':
            print("Thanks for playing SkakiBot. Goodbye!")
            break

        try:
            move = chess.Move.from_uci(user_input)
            if move in board.legal_moves:
                board.push(move)
                print(f"Move '{user_input}' played.")
            else:
                print("Invalid move. Please enter a valid move.")
                continue
        except ValueError:
            print("Invalid move format. Use UCI format like 'e2e4'.")
            continue

        if not board.is_game_over():
            try:
                ai_move_uci = get_openai_move(board)
                ai_move = chess.Move.from_uci(ai_move_uci)
            except Exception as e:
                print(f"Error with OpenAI: {str(e)}")
                break

            if ai_move in board.legal_moves:
                board.push(ai_move)
                print(f"OpenAI played '{ai_move_uci}'.")
            else:
                print(f"OpenAI suggested an invalid move: '{ai_move_uci}'.")
                break

That’s it! You now have a functional chess game where you can play against OpenAI. There’s plenty of room for improvement in the code, but it’s already playable. A fun next step would be to pit two AIs against each other and let them battle it out.

The code is available at GitHub. Have fun experimenting!

The Mars Rover Challenge in Rust: Houston, Do You Copy?

Yannis Rizos — Mon, 18 Nov 2024 11:59:45 +0000

Our rover navigation system is ready for its maiden voyage, but first, it needs to know where to go! The mission parameters have provided specific test scenarios to validate our implementation. My rover needs to interpret these commands:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

And respond with precise positional data:

1 3 N
5 1 E

Establishing Communication: Receiving User Input

My first challenge was creating a communication channel with Mission Control. I turned to Rust's powerful std::io module to establish this vital link:

// src/main.rs
mod direction;
mod instruction;
mod plateau;
mod rover;

use std::io::{self, BufRead};

fn main() {
    let stdin = io::stdin();
    let lines = stdin.lock().lines();

    for line in lines {
        match line {
            Ok(content) => println!("{}", content),
            Err(error) => eprintln!("Error reading line: {}", error),
        }
    }
}

This foundational setup acts as our mission control interface. Think of it as a radio receiver - it picks up incoming transmissions (user input) and echoes them back for confirmation. The std::io module serves as our communications array, carefully monitoring each incoming signal and reporting any transmission errors.

To verify our communication systems, I ran some basic diagnostic tests:

cargo build

Followed by:

cargo run

Perfect clarity - the system faithfully relays every message it receives, confirming our communication link is operational.

Mapping the Terrain: Parsing Plateau Dimensions

A rover without terrain data is like a ship without a map. I needed to interpret the first transmission - the dimensions of our Martian plateau:

// src/main.rs

// ...

fn main() {
    let stdin = io::stdin();
    let mut lines = stdin.lock().lines();

    if let Some(Ok(plateau_dimensions)) = lines.next() {
        let plateau_parts: Vec<i32> = plateau_dimensions
            .split_whitespace()
            .map(|s| s.parse().unwrap())
            .collect();
        println!("Plateau dimensions: {:?}", plateau_parts);
    }
}

The process here is like a surveyor reading coordinates. When Mission Control transmits the plateau dimensions, my code acts as a digital cartographer. It takes the raw input string, splits it at the spaces (like separating latitude and longitude), and converts each piece into a numerical value our rover can understand. The result? A precise digital map of our operational territory.

Setting the Scene: Parsing Rover's Initial State

With our terrain mapped, it's time to establish our rover's starting position. Each rover deployment needs three crucial pieces of information - its x and y coordinates on our digital map, and which way it's facing when it touches down:

// src/main.rs

// ...

fn main() {
    // ...

    if let Some(Ok(rover_initial)) = lines.next() {
        let rover_parts: Vec<&str> = rover_initial.split_whitespace().collect();
        let x: i32 = rover_parts[0].parse().unwrap();
        let y: i32 = rover_parts[1].parse().unwrap();
        let direction = match rover_parts[2] {
            "N" => Direction::NORTH,
            "E" => Direction::EAST,
            "S" => Direction::SOUTH,
            "W" => Direction::WEST,
            _ => panic!("Invalid direction"),
        };
        println!("Rover initial position: ({}, {}), Direction: {:?}", x, y, direction);
    }
}

This setup phase is like a pre-launch checklist. The code carefully parses the deployment coordinates, treating them like a spacecraft's landing coordinates. The direction indicator - N, E, S, or W - gets translated into our rover's internal compass, ensuring it knows exactly which way it's facing when it begins its mission.

Commanding the Rover: Parsing Movement Instructions

Next came the most critical part of our mission control interface - interpreting the sequence of movement commands. Each instruction is like a carefully choreographed dance move, telling our rover to pirouette left (L), right (R), or march forward (M):

// src/main.rs

// ...

fn main() {
    // ...

    if let Some(Ok(instructions_line)) = lines.next() {
        let instructions: Vec<Instruction> = instructions_line
            .chars()
            .filter_map(Instruction::from_char)
            .collect();
        println!("Rover instructions: {:?}", instructions);
    }
}

Think of this as our rover's mission sequence - each character in the instruction line represents a specific maneuver. The code transforms these simple letters into actionable commands our rover can understand, like translating Morse code into clear instructions.

Synchronizing the Mission: Integrating Components

With all our systems ready, it was time to bring everything together into a coordinated mission control center. Like launching a space mission, every component needs to work in perfect harmony:

// src/main.rs

mod direction;
mod instruction;
mod plateau;
mod rover;

use direction::Direction;
use instruction::Instruction;
use plateau::Plateau;
use rover::Rover;
use std::io::{self, BufRead};

fn main() {
    let stdin = io::stdin();
    let mut lines = stdin.lock().lines();

    let plateau_dimensions = lines.next().unwrap().unwrap();
    let plateau_parts: Vec<i32> = plateau_dimensions
        .split_whitespace()
        .map(|s| s.parse().unwrap())
        .collect();

    let rover_initial = lines.next().unwrap().unwrap();
    let rover_parts: Vec<&str> = rover_initial.split_whitespace().collect();
    let x: i32 = rover_parts[0].parse().unwrap();
    let y: i32 = rover_parts[1].parse().unwrap();
    let direction = match rover_parts[2] {
        "N" => Direction::NORTH,
        "E" => Direction::EAST,
        "S" => Direction::SOUTH,
        "W" => Direction::WEST,
        _ => panic!("Invalid direction"),
    };

    let instructions_line = lines.next().unwrap().unwrap();
    let instructions: Vec<Instruction> = instructions_line
        .chars()
        .filter_map(Instruction::from_char)
        .collect();

    let plateau = Plateau::new(plateau_parts[0], plateau_parts[1]);
    let mut rover = Rover::new(x, y, direction, &plateau);

    rover.execute_instructions(&instructions);
}

Like a well-orchestrated space mission, each piece plays its crucial role. First, we establish our terrain parameters, then position our rover, and finally load its mission instructions. Every component - from the plateau dimensions to the rover's directional systems - comes together in a seamless integration.

Broadcasting the Results: Sharing Rover Outcomes

After each successful mission, Mission Control needs accurate position reports. I added some eyes to our rover:

// src/main.rs

// ...

fn main() {
    // ...

    println!("{} {} {:?}", rover.x(), rover.y(), rover.direction());
}

When I put this to the test with a sample mission:

5 5
1 2 N
LMLMLMLMM

The rover reported back:

1 3 NORTH

Tuning the Details: Refining Output Format

Mission Control protocols are strict - they expect position reports in a specific format. 1 3 NORTH wouldn't do - they need 1 3 N. Time for some message formatting:

// src/direction.rs
#[derive(Debug, PartialEq)]
pub enum Direction {
    NORTH,
    EAST,
    SOUTH,
    WEST,
}

impl Direction {
    pub fn as_char(&self) -> char {
        match self {
            Direction::NORTH => 'N',
            Direction::EAST => 'E',
            Direction::SOUTH => 'S',
            Direction::WEST => 'W',
        }
    }
}

A quick update to our transmission format:

// src/main.rs

// ...

fn main() {
    // ...

    println!("{} {} {}", rover.x(), rover.y(), rover.direction().as_char());
}

Final Touches: Managing Multiple Rovers

The real challenge emerged when Mission Control revealed their master plan - coordinating multiple rovers! Each rover would receive its own set of instructions:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Like an air traffic controller managing multiple aircraft, I needed to coordinate multiple rover operations:

// src/main.rs

// ...

fn main() {
    // ...

    let mut i = 1;
    while i < lines.len() {
        if i + 1 >= lines.len() {
            break;
        }

        let rover_initial = &lines[i];
        let rover_parts: Vec<&str> = rover_initial.split_whitespace().collect();
        let x: i32 = rover_parts[0].parse().unwrap();
        let y: i32 = rover_parts[1].parse().unwrap();
        let direction = match rover_parts[2] {
            "N" => Direction::NORTH,
            "E" => Direction::EAST,
            "S" => Direction::SOUTH,
            "W" => Direction::WEST,
            _ => panic!("Invalid direction"),
        };

        let instructions_line = &lines[i + 1];
        let instructions: Vec<Instruction> = instructions_line
            .chars()
            .filter_map(Instruction::from_char)
            .collect();

        let mut rover = Rover::new(x, y, direction, &plateau);
        rover.execute_instructions(&instructions);

        println!("{} {} {}", rover.x(), rover.y(), rover.direction().as_char());

        i += 2;
    }
}

When put to the test with our multi-rover scenario:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Mission accomplished! Each rover reported its position perfectly:

1 3 N
5 1 E

Verifying the Expedition: Writing Integration Tests

Success is great, but in space exploration, we verify everything twice. I needed comprehensive tests to ensure our multi-rover coordination system worked flawlessly under all conditions:

// tests/integration_test.rs
use std::process::{Command, Stdio};
use std::io::Write;

#[test]
fn test_multiple_rovers() {
    let mut child = Command::new("cargo")
        .arg("run")
        .stdin(Stdio::piped())
        .stdout(Stdio::piped())
        .spawn()
        .expect("Failed to start cargo run");

    {
        let stdin = child.stdin.as_mut().expect("Failed to open stdin");
        let input = b"5 5\n1 2 N\nLMLMLMLMM\n3 3 E\nMMRMMRMRRM\n";
        stdin.write_all(input).expect("Failed to write to stdin");
    }

    let output = child.wait_with_output().expect("Failed to read stdout");

    let expected_output = "1 3 N\n5 1 E\n";
    let actual_output = String::from_utf8_lossy(&output.stdout);

    assert_eq!(actual_output, expected_output);
}

This test suite acts like a mission simulator. It sends commands just like Mission Control would and verifies that our rovers respond exactly as expected. Think of it as a dress rehearsal for the real Mars mission - every command must execute perfectly, every position report must be precise.

I run the full battery of tests with:

cargo test

When every test passes, I know our rovers are ready for their Martian adventure. The integration tests confirm that our entire command and control system - from receiving instructions to coordinating multiple rovers to reporting positions - works in perfect harmony. This comprehensive testing approach ensures that when our rovers touch down on Mars, they'll execute their missions flawlessly, navigating the red planet's terrain with precision and reliability.

The journey through this challenge has finally reached its conclusion, and what a gratifying experience it turned out to be. While Rust Analyzer flags a couple of minor issues, the robust test suite provides confidence that these will be straightforward fixes.

The code is available for perusal on Github, marking the end of this rewarding coding adventure.

The Mars Rover Challenge in Rust: Let's Get Moving!

Yannis Rizos — Mon, 18 Nov 2024 11:52:37 +0000

Now that the challenge is clear, it's time to start coding.

To kick things off, I got my project set up using Cargo – nothing fancy, just the basics:

cargo new mars-rover-rust
cd mars-rover-rust

Charting the Course: Defining Directions

First up, I needed to figure out how our little rover would know which way it's facing. I went with the classics here – good old North, East, South, and West. Here's how I set that up in Rust:

// src/direction.rs
#[derive(Debug, PartialEq)]
pub enum Direction {
    NORTH,
    EAST,
    SOUTH,
    WEST,
}

Pretty straightforward, right? I added those Debug and PartialEq traits since I knew we'd want to peek at these values during debugging and compare them in our tests.

Steering the Rover: Implementing Turns

Now for the fun part – teaching our rover how to turn! I created a Rover struct and gave it some basic turning abilities:

// src/rover.rs
use crate::direction::Direction;

#[derive(Debug, PartialEq)]
pub struct Rover {
    x: i32,
    y: i32,
    direction: Direction,
}

impl Rover {
    pub fn new(x: i32, y: i32, direction: Direction) -> Self {
        Rover { x, y, direction }
    }

    pub fn turn_left(&mut self) {
        self.direction = match self.direction {
            Direction::NORTH => Direction::WEST,
            Direction::WEST => Direction::SOUTH,
            Direction::SOUTH => Direction::EAST,
            Direction::EAST => Direction::NORTH,
        };
    }

    pub fn turn_right(&mut self) {
        self.direction = match self.direction {
            Direction::NORTH => Direction::EAST,
            Direction::EAST => Direction::SOUTH,
            Direction::SOUTH => Direction::WEST,
            Direction::WEST => Direction::NORTH,
        };
    }
}

Of course, I had to make sure our rover could actually turn properly, so I wrote some tests to put it through its paces:

// src/rover.rs
#[cfg(test)]
mod tests {
    use super::*;
    use crate::direction::Direction;

    #[test]
    fn test_turn_left() {
        let mut rover = Rover::new(0, 0, Direction::NORTH);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::WEST);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::SOUTH);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::EAST);
        rover.turn_left();
        assert_eq!(rover.direction, Direction::NORTH);
    }

    #[test]
    fn test_turn_right() {
        let mut rover = Rover::new(0, 0, Direction::NORTH);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::EAST);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::SOUTH);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::WEST);
        rover.turn_right();
        assert_eq!(rover.direction, Direction::NORTH);
    }
}

A quick cargo test lets us know if everything's working as planned.

Mapping the Terrain: Setting Up the Plateau

Here's where things got interesting – I realized our rover needed some boundaries to roam within. Can't have it wandering off into space! So I created a Plateau to keep it in check:

// src/plateau.rs
#[derive(Debug, PartialEq)]
pub struct Plateau {
    width: i32,
    height: i32,
}

impl Plateau {
    pub fn new(width: i32, height: i32) -> Self {
        Plateau { width, height }
    }

    pub fn is_within_bounds(&self, x: i32, y: i32) -> bool {
        x >= 0 && x <= self.width && y >= 0 && y <= self.height
    }
}

Advancing the Rover: Moving Forward

With our playground set up, it was time to teach our rover how to actually move around:

// src/rover.rs
use crate::plateau::Plateau;

impl Rover {
    pub fn move_forward(&mut self, plateau: &Plateau) {
        let (new_x, new_y) = match self.direction {
            Direction::NORTH => (self.x, self.y + 1),
            Direction::EAST => (self.x + 1, self.y),
            Direction::SOUTH => (self.x, self.y - 1),
            Direction::WEST => (self.x - 1, self.y),
        };

        if plateau.is_within_bounds(new_x, new_y) {
            self.x = new_x;
            self.y = new_y;
        }
    }
}

And naturally, we needed to make sure it behaves:

// src/rover.rs
#[cfg(test)]
mod tests {
    use super::*;
    use crate::plateau::Plateau;

    #[test]
    fn test_move_forward_within_bounds() {
        let plateau = Plateau::new(5, 5);
        let mut rover = Rover::new(0, 0, Direction::NORTH);
        rover.move_forward(&plateau);
        assert_eq!(rover.x, 0);
        assert_eq!(rover.y, 1);
    }

    #[test]
    fn test_move_forward_out_of_bounds() {
        let plateau = Plateau::new(5, 5);
        let mut rover = Rover::new(0, 0, Direction::SOUTH);
        rover.move_forward(&plateau);
        assert_eq!(rover.x, 0);
        assert_eq!(rover.y, 0);
    }
}

Commanding the Rover: Processing Instructions

Finally, the piece that brings it all together – teaching our rover to follow commands:

// src/rover.rs
impl Rover {
    pub fn execute_commands(&mut self, commands: &str, plateau: &Plateau) {
        for command in commands.chars() {
            match command {
                'L' => self.turn_left(),
                'R' => self.turn_right(),
                'M' => self.move_forward(plateau),
                _ => {},
            }
        }
    }
}

And here's the grand finale of our test suite:

// src/rover.rs
#[cfg(test)]
mod tests {
    use super::*;
    use crate::direction::Direction;
    use crate::plateau::Plateau;
    use crate::instruction::Instruction;

    // Existing tests...

    #[test]
    fn test_execute_instructions() {
        let plateau = Plateau::new(5, 5);
        let mut rover = Rover::new(1, 2, Direction::NORTH, &plateau);
        let instructions = [
            Instruction::LEFT, Instruction::MOVE, Instruction::LEFT, Instruction::MOVE,
            Instruction::LEFT, Instruction::MOVE, Instruction::LEFT, Instruction::MOVE,
            Instruction::MOVE
        ];
        rover.execute_instructions(&instructions);
        assert_eq!(rover.x, 1);
        assert_eq!(rover.y, 3);
        assert_eq!(rover.direction, Direction::NORTH);

        let mut rover = Rover::new(3, 3, Direction::EAST, &plateau);
        let instructions = [
            Instruction::MOVE, Instruction::MOVE, Instruction::RIGHT, Instruction::MOVE,
            Instruction::MOVE, Instruction::RIGHT, Instruction::MOVE, Instruction::RIGHT,
            Instruction::RIGHT, Instruction::MOVE
        ];
        rover.execute_instructions(&instructions);
        assert_eq!(rover.x, 5);
        assert_eq!(rover.y, 1);
        assert_eq!(rover.direction, Direction::EAST);
    }
}

And there you have it! Our Mars Rover is now ready to explore its virtual plateau. I've got to say, as someone still getting their feet wet with Rust, seeing this all come together has been incredibly satisfying. The code might not be perfect by Rust standards, but hey, it works!

Next up on my list is handling user input and prettifying the output. But that's a story for another day!

The Mars Rover Challenge in Rust: Setting the Scene

Yannis Rizos — Mon, 18 Nov 2024 11:52:03 +0000

As a Rust beginner, I was looking for a project that would both teach me the language fundamentals and keep me engaged. The Mars Rover Challenge fits perfectly - it's an intriguing problem that simulates robotic exploration of Mars while introducing key programming concepts.

Setting the Scene

Imagine controlling rovers tasked with exploring the Martian terrain. These rovers need to navigate a rectangular plateau while sending visual data back to Earth. The challenge involves translating simple commands into precise rover movements, and dealing with positioning, orientation, and grid-based navigation.

The Challenge

A squad of robotic rovers is to be landed by NASA on a plateau on Mars.

This plateau, which is curiously rectangular, must be navigated by the rovers so that their onboard cameras can get a complete view of the surrounding terrain to send back to Earth. A rover's position is represented by a combination of x and y co-ordinates and a letter representing one of the four cardinal compass points. The plateau is divided up into a grid to simplify navigation. An example position might be 0, 0, N, which means the rover is in the bottom left corner and facing North.

In order to control a rover, NASA sends a simple string of letters. The possible letters are L, R, and M. L and R make the rover spin 90 degrees left or right respectively, without moving from its current spot.

M means move forward one grid point and maintain the same heading.

Assume that the square directly North from (x, y) is (x, y+1).

Input:

The first line of input is the upper-right coordinates of the plateau. The lower-left coordinates are assumed to be 0,0.
The rest of the input is information pertaining to the rovers that have been deployed. Each rover has two lines of input. The first line gives the rover's position, and the second line is a series of instructions telling the rover how to explore the plateau.
The position is made up of two integers and a letter separated by spaces, corresponding to the x and y coordinates and the rover's orientation.

Each rover will be finished sequentially, which means that the second rover won't start to move until the first one has finished moving.

Output:

The output for each rover should be its final coordinates and heading.

Test Input:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Test Output:

1 3 N
5 1 E

Breaking Down the Requirements

Let's analyze what we're dealing with:

The Environment
- A rectangular plateau defined by coordinates
- Grid-based movement system
- Origin point (0,0) at bottom-left
Rover Capabilities
- Position tracking (x,y coordinates)
- Cardinal direction orientation (N,E,S,W)
- Three basic commands:
  - Rotate left 90° (L)
  - Rotate right 90° (R)
  - Move forward one grid unit (M)
System Behavior
- Sequential rover movement (one at a time)
- Position updates after each move
- Boundary awareness required
- Final position reporting

Why This is Great for Learning

This challenge touches on several fundamental Rust concepts:

Enums (for directions and commands)
Structs (for rover and plateau representation)
Error handling (for boundary violations)
String parsing
Vector operations
Testing

P.S. If you'd like to dive straight into the code, you can find the implementation on GitHub.

Setting Up Visual Studio Code for Rust on macOS

Yannis Rizos — Sun, 17 Nov 2024 11:50:12 +0000

Setting up Visual Studio Code for Rust development is quick and straightforward. While I prefer PHPStorm for larger projects, VS Code is perfect for smaller ones. It’s fast, lightweight, and just works. For this guide, I’m assuming you already have Rust installed via Homebrew.

Step 1: Grab VS Code

Head over to code.visualstudio.com and download VS Code. Follow the installation instructions provided for MacOS to set it up.

Step 2: Create a Hello World Project with cargo

Open Terminal and create a new Rust project:
```
cargo new hello_world
```
Navigate into the project folder:
```
cd hello_world
```
Open the project in VS Code:
```
code .
```

If this command doesn’t work, you may need to add VS Code to your PATH. Open the Command Palette (⇧ + ⌘ + P), type "Shell Command," and select "Install 'code' command in PATH." Then try again.

Step 3: Add the Rust Analyzer Extension

Open VS Code and press ⇧ + ⌘ + X to open the Extensions view.
Search for "Rust Analyzer" and click Install.

Rust Analyzer provides features like syntax highlighting, error checking, and improved code navigation.

Once the extension is installed, open the main.rs file located in the src folder of your project. You should now see:

Syntax highlighting: Keywords, variables, and functions are coloured differently for better readability.
Inline error checking: If there are issues in your code, they will be underlined in red, with detailed error messages displayed when you hover over the issue.
Code completion: Start typing and you’ll see a list of suggestions based on the context.

To test the error checking feature, introduce a simple mistake in your code. For example, change the line:

println!("Hello, world!");

to:

rintln!("Hello, world!");

You’ll immediately see an error indicating that Rust cannot find macro rintln.

Step 4: Set up auto-formatting

Enable auto-formatting in VS Code:
- Open the settings (⌘ + ,).
- Search for "Format On Save."
- Enable the "Editor: Format On Save" option.

This ensures your code is automatically formatted whenever you save. To test auto-formatting, open main.rs and intentionally mess up the formatting. For instance, write:

fn main( ){println!("Hello, world!");}

Save the file. Auto-formatting will fix it immediately, and your code will look like this:

fn main() {
    println!("Hello, world!");
}

Step 5: Run your program with cargo

Open the integrated terminal in VS Code by pressing ⌃ + ` (Control and backtick).
Run the program:
```
cargo run
```
You should see the output:
```
Hello, world!
```

And there you have it. Your setup is ready, and you’re all set to dive into Rust development with VS Code. Time to build something amazing!

Installing Rust on macOS with Homebrew

Yannis Rizos — Sun, 17 Nov 2024 09:28:59 +0000

This Sunday, I had a bit of extra time, so I decided to brush up on Rust. Whether you are a seasoned developer or just starting out, getting your tools set up is always the first step.

While Rust’s official installation tool, rustup, is excellent and versatile, I prefer using Homebrew whenever possible. It is simple, familiar, and keeps everything neatly managed in one place.

Step 1: Install Rust

Launch the terminal and run the following command to install Rust:

brew install rust

This will install both Rust and Cargo, Rust’s package manager and build system. Cargo simplifies managing dependencies, building projects, and running tests in Rust. It is an essential tool for any Rust developer.

Step 2: Verify the Installation

After installation, confirm everything is set up correctly by checking the Rust version:

rustc --version
cargo --version

If the command returns the Rust version number, you are all set!

Step 3: Keeping Rust Updated

Homebrew makes it easy to update Rust when new versions are released. Periodically run the following commands to keep Rust up to date:

brew update
brew upgrade rust

That is it, you are ready to code in Rust! 🎉