Forem: Gabriel Peixoto

How I Passed the AWS Exam in 10 Days(no bs)

Gabriel Peixoto — Thu, 15 May 2025 01:59:46 +0000

How I passed the 𝐀𝐖𝐒 𝐂𝐋𝐎𝐔𝐃 𝐏𝐑𝐀𝐂𝐓𝐈𝐓𝐈𝐎𝐍𝐄𝐑 exam in 10 days 🥇

IN SHORT, I STUDIED A LOT..

Jokes aside, I created a challenge in my mind to pass in just 10 days, I made the payment for the test on April 21st at 11:22 pm and scheduled the test for April 26th, a Saturday.

So I joined Udemy and started studying Stéphane Maarek's course, it covers everything you need to pass the AWS exam in a cohesive and concise way. I work 8 hours a day but whenever I had some free time, even at lunch, I would watch classes and 𝐈 𝐖𝐑𝐎𝐓𝐄 𝐈𝐓 𝐃𝐎𝐖𝐍 𝐈𝐍 𝐀 𝐍𝐎𝐓𝐄𝐁𝐎𝐎𝐊 𝐀𝐍𝐃 𝐒𝐏𝐎𝐊𝐄 𝐈𝐓 𝐎𝐔𝐓 𝐋𝐎𝐔𝐃 (In my head, writing down and talking about the topic was the difference).

Even though I studied whenever I had time, I wasn't confident enough to take the test on April 26th, so I rescheduled the test for May 1st, a Thursday.

After finishing Stéphane Maarek's course and doing 8 mock exams with 65 questions each, I felt confident. In the last 2 mock exams, I scored 860-890, so I felt I was ready.

🤝 The biggest lessons I learned:

𝐇𝐚𝐯𝐞 𝐚 𝐠𝐨𝐨𝐝 𝐦𝐞𝐧𝐭𝐨𝐫 𝐭𝐨 𝐭𝐞𝐚𝐜𝐡 𝐲𝐨𝐮, 𝐈 𝐫𝐞𝐜𝐨𝐦𝐦𝐞𝐧𝐝 𝐒𝐭é𝐩𝐡𝐚𝐧𝐞
𝐁𝐮𝐲 𝐚 𝐧𝐨𝐭𝐞𝐛𝐨𝐨𝐤 𝐚𝐧𝐝 𝐭𝐚𝐤𝐞 𝐧𝐨𝐭𝐞𝐬, 𝐰𝐫𝐢𝐭𝐢𝐧𝐠 𝐝𝐨𝐰𝐧 𝐦𝐚𝐤𝐞𝐬 𝐚 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞
𝐄𝐱𝐩𝐥𝐚𝐢𝐧 𝐭𝐡𝐞 𝐬𝐞𝐫𝐯𝐢𝐜𝐞𝐬 𝐨𝐮𝐭 𝐥𝐨𝐮𝐝 𝐚𝐬 𝐢𝐟 𝐲𝐨𝐮 𝐰𝐞𝐫𝐞 𝐭𝐚𝐥𝐤𝐢𝐧𝐠 𝐭𝐨 𝐬𝐨𝐦𝐞𝐨𝐧𝐞
𝐂𝐫𝐞𝐚𝐭𝐞 𝐚 𝐜𝐡𝐚𝐥𝐥𝐞𝐧𝐠𝐞, 𝐚 𝐠𝐨𝐚𝐥, 𝐚𝐧 𝐨𝐛𝐣𝐞𝐜𝐭𝐢𝐯𝐞 𝐚𝐧𝐝 𝐩𝐮𝐫𝐬𝐮𝐞 𝐢𝐭
𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞 𝐀𝐖𝐒 𝐬𝐞𝐫𝐯𝐢𝐜𝐞𝐬, 𝐞𝐚𝐜𝐡 𝐨𝐟 𝐭𝐡𝐞𝐦 𝐬𝐨𝐥𝐯𝐞𝐬 𝐬𝐨𝐦𝐞𝐨𝐧𝐞’𝐬 𝐩𝐫𝐨𝐛𝐥𝐞𝐦

The challenge was what made me anxious but at the same time wanting to study and get there, as well as when I received the information that I passed on, happiness came and I thought at the time that the days studying were rewarded.

On my LinkedIn I posted the proof where I show the date I paid for the exam and the appointments.

Clean, Fast, and Efficient: 4 PHP Tips to Supercharge Your Code

Gabriel Peixoto — Thu, 20 Mar 2025 01:33:57 +0000

Hey, PHP folks! Want cleaner, faster code without breaking a sweat? Here are four practical tips to sharpen your skills. I’ll keep it short but juicy, with examples and a peek at why they work—spoiler: some are turbo-charged by C optimizations. Let’s roll!

Tip 1: Use `empty()` for Smarter Variable Checks

The empty() function is your go-to for checking if a variable exists and has a meaningful value (not '', 0, null). It’s not just handy—it’s a language construct baked into PHP’s core, optimized in C for speed.

Before:

if (isset($var) && $var !== '' && $var !== 0) {
    echo "It’s got something!";
}

After:

if (!empty($var)) {
    echo "It’s got something!";
}

Why it’s better:

empty() combines multiple checks into one sleek call. Since it’s written in C, it’s faster than stacking isset() and comparisons. Plus, it’s easier to read—less clutter, more clarity.

Tip 2: Lean on Built-in Functions

PHP’s built-in functions, like str_replace() or array_sum(), aren’t just convenient—they’re coded in C, making them lightning-fast compared to DIY solutions.

Before:

$str = "Hello, world!";
$search = "world";
$replace = "PHP";
$result = "";
for ($i = 0; $i < strlen($str); $i++) {
    if (substr($str, $i, strlen($search)) == $search) {
        $result .= $replace;
        $i += strlen($search) - 1;
    } else {
        $result .= $str[$i];
    }
}

After:

$str = "Hello, world!";
$result = str_replace("world", "PHP", $str);

Why it’s better:

Built-ins like str_replace() are optimized at the C level, so they outpace manual loops by a mile. They’re also battle-tested, reducing bugs and boosting readability. Why reinvent the wheel when PHP’s got a turbo version?

Tip 3: Swap Loops for Array Functions

Need to process arrays? Skip the foreach grind and use array_map() or array_filter(). These functions are designed for arrays and come with internal optimizations that traditional loops can’t match.

Before:

$numbers = [1, 2, 3, 4];
$squares = [];
foreach ($numbers as $num) {
    $squares[] = $num * $num;
}

After:

$numbers = [1, 2, 3, 4];
$squares = array_map(fn($num) => $num * $num, $numbers);

Why it’s better:

array_map() is slicker and faster, thanks to PHP’s array-handling optimizations. It cuts out loop overhead and keeps your code concise—perfect for big datasets or just showing off your modern PHP chops.

Tip 4: Cache Smarter with Static Variables

Got a function doing heavy lifting, like a database call? Use static variables to cache results inside the function. It’s a simple trick that leverages PHP’s memory management to skip redundant work.

Before:

function getUserData($id) {
    // Imagine a slow DB query here
    return ['id' => $id, 'name' => 'User ' . $id];
}

$user1 = getUserData(1);
$user2 = getUserData(1); // Repeats the work

After:

function getUserData($id) {
    static $cache = [];
    if (!isset($cache[$id])) {
        $cache[$id] = ['id' => $id, 'name' => 'User ' . $id];
    }
    return $cache[$id];
}

$user1 = getUserData(1);
$user2 = getUserData(1); // Pulls from cache

Why it’s better:

Static vars stick around between calls, storing results in memory. This avoids re-running expensive operations, making your app snappier—especially in loops or high-traffic scenarios.

Wrap-Up

There you go—four PHP tips to make your code faster, cleaner, and smarter: empty() for checks, built-ins for speed, array functions for style, and static caching for efficiency. Many of these tap into C-level optimizations baked into PHP, so you’re getting performance boosts for free. Try them out, tweak them, and let me know your own tricks in the comments. Happy coding!

Simplify Your PHP Code with KISS, YAGNI, and DRY

Gabriel Peixoto — Wed, 12 Mar 2025 00:19:48 +0000

Simplify Your PHP Code with KISS, YAGNI, and DRY

Good code doesn’t need to be complicated. Principles like KISS, YAGNI, and DRY help you write cleaner, more maintainable PHP code without changing what it does. In this article, we’ll take a super simple example and improve it using these ideas, showing how they make your code better—step by step.

What Are These Principles?

KISS (Keep It Simple, Stupid): Avoid unnecessary complexity. Simple code is easier to read and less prone to bugs.

YAGNI (You Ain’t Gonna Need It): Don’t add features you don’t need right now. Keep your code focused.

DRY (Don’t Repeat Yourself): Avoid duplicating code. Centralize logic to make updates easier.

Let’s see them in action with a example.

Managing User Discounts and Final Price

Calculating a user’s final price after applying a discount based on their membership status. Both versions will produce the same output, but the "after" version will be cleaner and more maintainable.

Before: Overly Complicated and Redundant

<?php
// Before version: overly complicated

$userType = "premium"; // Can be "premium", "standard", or "guest"
$originalPrice = 200;
$discountRatePremium = 0.20; // 20% discount for premium
$discountRateStandard = 0.10; // 10% discount for standard
$minimumPriceThreshold = 50; 

// Complex discount logic with redundant checks
$discountAmount = 0;
if ($userType === "premium") {
    if ($originalPrice > $minimumPriceThreshold) {
        $discountAmount = $originalPrice * $discountRatePremium;
        if ($discountAmount > 0) {
            $finalPrice = $originalPrice - $discountAmount;
        } else {
            $finalPrice = $originalPrice;
        }
    } else {
        $finalPrice = $originalPrice;
    }
} elseif ($userType === "standard") {
    if ($originalPrice > $minimumPriceThreshold) {
        $discountAmount = $originalPrice * $discountRateStandard;
        if ($discountAmount > 0) {
            $finalPrice = $originalPrice - $discountAmount;
        } else {
            $finalPrice = $originalPrice;
        }
    } else {
        $finalPrice = $originalPrice;
    }
} else {
    $finalPrice = $originalPrice; // No discount for guests
}

// Unnecessary logging feature we don’t use yet
$logMessage = "User type: $userType, Original: $originalPrice, Final: $finalPrice";

// Specific condition tied to a hardcoded value
if ($finalPrice === 160) {
    $status = "Discount applied successfully for premium user.";
} else {
    $status = "No special discount condition met.";
}

echo "Original Price: $originalPrice\n";
echo "Discount Amount: $discountAmount\n";
echo "Final Price: $finalPrice\n";
echo "$status\n";
?>

The output

Original Price: 200
Discount Amount: 40
Final Price: 160
Discount applied successfully for premium user.

What’s Messy Here?

KISS Violation: Nested if statements make the discount logic overly complex. The $discountAmount > 0 check is redundant since the discount rate and price are positive.
YAGNI Violation: The $minimumPriceThreshold check and $logMessage variable suggest future functionality (logging or price validation), but they’re not needed now.
DRY Violation: The discount calculation logic is repeated for "premium" and "standard" users, duplicating code unnecessarily.

After: Simple and Maintainable

<?php
// Refactored version: simple and maintainable

$userType = "premium"; // Can be "premium", "standard", or "guest"
$originalPrice = 200;

// Define discount rates in a simple array
$discountRates = [
    "premium" => 0.20, // 20% discount
    "standard" => 0.10, // 10% discount
    "guest" => 0.0 // No discount
];

// Calculate discount and final price directly
$discountRate = $discountRates[$userType] ?? 0.0; // Default to 0 if user type is invalid
$discountAmount = $originalPrice * $discountRate;
$finalPrice = $originalPrice - $discountAmount;

// Flexible status message using a ternary operator
$status = ($discountAmount > 0) ? "Discount applied successfully." : "No discount applied.";

echo "Original Price: {$originalPrice}\n";
echo "Discount Amount: {$discountAmount}\n";
echo "Final Price: {$finalPrice}\n";
echo "{$status}\n";
?>

The output

Original Price: 200
Discount Amount: 40
Final Price: 160
Discount applied successfully.

Why It’s Better:

KISS: The discount logic is simplified by using an array to store rates and a single calculation ($originalPrice * $discountRate). No nested if statements.
YAGNI: Removed the $minimumPriceThreshold and $logMessage since they’re not required for the current functionality.
DRY: The discount logic is centralized with the $discountRates array, eliminating repetition across user types.

Congratulations—you’ve made it to the end! By sticking with us, you’ve unlocked the power of KISS, YAGNI, and DRY—principles that can transform the way you write code. Try applying them to your next project and see the difference for yourself. Have you used these ideas before? Share your thoughts or success stories in the comments below!

Why You Need SOLID as a Developer

Gabriel Peixoto — Sun, 09 Mar 2025 02:29:00 +0000

Do You Need SOLID to Be a Better Developer?

You don’t need SOLID to write working code—many developers manage without it. But to become a better developer (and potentially earn more by writing high-quality, maintainable software), learning SOLID basics is a smart move. SOLID’s five principles make code more understandable, flexible, and maintainable.

1. Single Responsibility Principle

"Do one thing and do it well"—that’s Uncle Bob’s advice from his book. SRP means a class should have just one responsibility.

SRP Failing

The Book class has two responsibilities:

Managing book details (title, author, description)—its core purpose.
Interacting with a database (saveToDatabase)—unrelated to the book’s properties. That’s a mistake.

SRP Essence

To fix this, separate the responsibilities:

Book focuses solely on book-related tasks.
DatabaseManager handles database operations. Each class now has one reason to change:
Book if book properties change.
DatabaseManager if database logic changes.

2. Open/Closed Principle

The Open/Closed Principle (OCP) means software entities (classes, modules) should be open for extension but closed for modification—add new functionality without altering existing code.

OCP Failing

The ShippingCalculator calculates shipping costs based on book type.
The mistake?
Adding a new type requires modifying it with another elseif, breaking OCP. This opens the class to changes, risking bugs.

OCP Essence

The ShippingCalculator stays closed for modification by using a ShippingType interface. New types (PaperbackShipping, HardcoverShipping) extend it, delegating logic to specific classes. This keeps the system flexible and bug-free.

3. Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that subclass objects should replace parent class objects without breaking the program—substitution should work seamlessly.

LSP Failing

A Bird class assumes all birds can fly(), but a Penguin subclass can’t. This breaks LSP because Penguin isn’t substitutable for Bird without altering behavior.

LSP Essence

An Animal interface with a move() method lets Sparrow and Penguin implement it their way. The makeAnimalMove() function works with any Animal subclass without breaking, satisfying LSP.

4. Interface Segregation Principle

ISP states that classes shouldn’t be forced to implement interfaces they don’t use—keep interfaces small and specific.

ISP Failing

A Worker interface includes work() and manage(). Developer only needs work() but must implement manage() too, breaking ISP by forcing unused methods.

ISP Essence

Workable and Manageable are separate interfaces. Developer implements only Workable; Manager implements both. No unused methods are forced, satisfying ISP.

5. Dependency Inversion Principle

DIP states that high-level modules shouldn’t depend on low-level ones—both should rely on abstractions (interfaces) for flexibility.

DIP Failing

Notification (high-level) directly depends on FileLogger (low-level). Switching to DatabaseLogger requires changing Notification, breaking DIP due to tight coupling.

DIP Essence

A Logger interface defines the contract. Notification depends on Logger, not FileLogger. Swapping FileLogger for DatabaseLogger needs no changes to Notification, following DIP by relying on abstractions.

Final Thoughts

SOLID principles improve code quality and flexibility. Apply them to level up your skills and projects. Thanks for reading!

Forem: Gabriel Peixoto

How I Passed the AWS Exam in 10 Days(no bs)

How I passed the 𝐀𝐖𝐒 𝐂𝐋𝐎𝐔𝐃 𝐏𝐑𝐀𝐂𝐓𝐈𝐓𝐈𝐎𝐍𝐄𝐑 exam in 10 days 🥇

Clean, Fast, and Efficient: 4 PHP Tips to Supercharge Your Code

Tip 1: Use empty() for Smarter Variable Checks

Tip 2: Lean on Built-in Functions

Tip 3: Swap Loops for Array Functions

Tip 4: Cache Smarter with Static Variables

Wrap-Up

Simplify Your PHP Code with KISS, YAGNI, and DRY

Simplify Your PHP Code with KISS, YAGNI, and DRY

What Are These Principles?

Managing User Discounts and Final Price

Before: Overly Complicated and Redundant

The output

What’s Messy Here?

After: Simple and Maintainable

The output

Why It’s Better:

Why You Need SOLID as a Developer

Do You Need SOLID to Be a Better Developer?

1. Single Responsibility Principle

SRP Failing

SRP Essence

2. Open/Closed Principle

OCP Failing

OCP Essence

3. Liskov Substitution Principle

LSP Failing

LSP Essence

4. Interface Segregation Principle

ISP Failing

ISP Essence

5. Dependency Inversion Principle

DIP Failing

DIP Essence

Final Thoughts

Tip 1: Use `empty()` for Smarter Variable Checks