What is AWS?

From the horse's mouth himself, Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

Yes, that kinda sounds like bragging. It is however true.

AWS, is the cloud services division of Amazon, providing on-demand computing resources and services in the cloud, on a pay-as-you-go basis. Introduced in 2006, AWS began with the simple idea of selling compute power and storage space on the Internet, eliminating the need for businesses and individuals to own and maintain their own physical servers and data centers.

AWS's global infrastructure is built around regions and availability zones. Each region is a separate geographic location, and within each region, there are multiple isolated availability zones (AZs) — essentially data centers. This design ensures data redundancy, fault tolerance, and high availability, making it a reliable choice for businesses of all sizes.

Why AWS?

Amazon Web Services has firmly established itself as a frontrunner in the cloud computing world. But what factors contribute to its widespread adoption? why is it often the preferred choice amongst developers?

1. Pioneering Advantage: While AWS was made public as a cloud platform in 2006,it's jouney really began in 2002 primarily providing a few Web solutions and services designed specifically for developers and website owners. It wasn't just one of the first players in the cloud market; it essentially defined what cloud computing is today. AWS paved the way for the cloud revolution, enabling countless businesses to transform their operations and scale like never before.

2. A vast array of Service Offerings: With over 200 fully featured services, No other provider can boast of offering that many services. the advantage of this is that businesses of all sizes and all sectors can definitely find tools that are specifically tailored to their needs.

3. Security: AWS is built and maintained with a core focus on security. It provides tools and guidelines/practices for ensuring data protection, Identity Management (IAM), and compliance. if you have ever been hacked, you will understand the importance of this.

4. Community and support: I love this one. The reason why Javascript seems easy is because of its popularity and huge community, you need to learn anything in javascript? someone has made a tutorial about it. You need to carry out a daunting task? best believe someone has made a library that makes your job way easier.
   AWS has a vibrant community of users, developers, and advocates. The vast array of documentation, tutorials, and training programs like AWS Certifications ensures continuous learning and support.

5. Flexible Pricing: With its pay-as-you-go pricing model, you can start small, scale resources based on demand, and only pay for what you use thus avoiding hefty upfront costs.

6. Global: their infrastructure spans multiple regions across the globe, ensuring high availability and fault tolerance. Each region has multiple availability zones (AZs), effectively reducing latency and enhancing the user experience for global audiences. Low latency in itself is very important as, despite a well-optimized website, high latency can reduce page loading speed, potentially increasing churn rates.

   

In essence, while there are several cloud providers offering valuable services, AWS's combination of breadth, depth, security, and innovation positions it uniquely in the cloud ecosystem. Whether you're a budding startup, a tech giant, or somewhere in between, AWS provides the tools and flexibility to build, innovate, and scale.

Looking Ahead

With the expansive nature of AWS, this introduction merely scratches the surface. As we venture deeper into the AWS universe in this series, we'll break down its vast offerings, making them digestible and relatable. Stay tuned as we embark on this cloud journey together, unraveling the complexities of AWS and making the most of its vast potential.

In this article, we tackle Leet2038 here like Casemiro tackled Bruno Fernandes two weeks ago (or years ago depending on when you're reading this 😂😂😂). The problem presents a gaming scenario where we're given a sequence of game pieces/items, each colored either 'A' or 'B'. Imagine a board game between Alice and Bob, where they take turns removing pieces based on certain rules. The goal of Leet2038 is simple: determine who wins this delightful game! Alice? Bob?
The problem is a kind of weird one. Weird because it is actually quite easy to implement. It does not build on any complex algorithmic pattern or data structures. I think, literally the barest minimum of programming knowledge is required to solve this. However, it is very easy to overcomplicate the problem and get stuck especially since it is tagged a medium difficulty. I know I did.

Problem Statement

There are n pieces arranged in a line and each piece is colored either by 'A' or by 'B'. You are given a string colors of length n where colors[i] is the color of the i<sup>th</sup> piece.

Alice and Bob are playing a game where they take alternating turns removing pieces from the line. In this game, Alice moves first.

• Alice is only allowed to remove a piece colored 'A' if both its neighbors are also colored 'A'. She is not allowed to remove pieces that are colored 'B'.

• Bob is only allowed to remove a piece colored 'B' if both its neighbors are also colored 'B'. He is not allowed to remove pieces that are colored 'A'.

• Alice and Bob cannot remove pieces from the edge of the line.

• If a player cannot make a move on their turn, that player loses and the other player wins.

Assuming Alice and Bob play optimally, return true if Alice wins, or return false if Bob wins.

Initial Thought

We will skip this, it's embarrassing. I was actually stuck because I started thinking of how to track how many times Bob can possibly win individually (i.e how many times we have a substring of 3 consecutive Bs, and what happens when have 4, 5,...+ Bs), and how many times Alice can possibly win individually. maybe that could work but It was evident after some minutes that it was after all an overkill and would be tricky to implement even if it could work.
how do we solve it then?
1. I reread and tried to simplify the question so I could completely understand it.
2. I walked through the test cases manually without writing down any code
3. I realized it has a lot to do with sequencing. so, I decided; solve an easy Leet whatever that implements sequencing, let's call that a detour.

The Detour

Problem Statement:
Given a binary array nums, return the maximum number of consecutive 1's in the array.

Example

Input: nums = [1,1,0,1,1,1]
Output: 3
Explanation: The first two digits or the last three digits are 
consecutive 1s. The maximum number of consecutive 1s is 3.

Solution:

import "math"

func findMaxConsecutiveOnes(nums []int) int {
  /**
    * who would have thought the problem was this easy. 
    * so, you mean that I only have to count ones.
    * loop though, if it is a one, add it to the curr
    * else, reset curr to zero until we find a one again 
    */
    max ,curr := 0,0;

    for _,num := range nums{
        if num == 1{
            curr++
        }else{
            max = int(math.Max(float64(max), float64(curr)))
            curr=0
        }
    }
    max = int(math.Max(float64(max), float64(curr)))
    return max;    
}

this problem had to do with counting number of similar elements except this problem is even a little more complex because now, we have to know when to reset the current counts

My Approach

Let's read the problem again because really, that is the only difficult part.
Givens:
1. Alice can only remove a piece provided both its neighbors are the same. I.E 'AAA'
2. Bob can only remove a piece if both its neighbors are the same. I.E 'BBB'

what the above might tell us is that we have to loop through the string and check at every point in time if we have 3 consecutive colors. (think of what that logic will look like in your head. i-1 , i and i+1 right? yh, you might be right.)
but.....

3. What if we have an instance where we have 4 consecutive? ('AAAA').
hmmm. well, it barely matters because we only need to know and worry about checking that there will be 3 consecutive AAA, and if we move to the next iteration, We verify this condition AGAIN, which signals that we can perform two removals consecutively from that position. and that is accurate for 4 consecutive As. The same logic works if there are even more.
Counting the occurrences essentially tells us how many times a player can make a move in the game, independently of whether there's another player or not.

4. A player cannot remove pieces at the edge, sweet. I guess we better start counting from index 1 and end at (index array.length -2). This also tells us the least length of the array we can possibly get us 2. I guess 🤡.

1. Alice plays first. so, if they both end up with an equal number of moves, Alice loses. I really should not have to explain that part.

Implementation

solving this in go since it is quite straightforward

func winnerOfGame(colors string) bool {
     aCount := 0  // Count of consecutive 'A's
    bCount := 0  // Count of consecutive 'B's
    n := len(colors)

    // Iterate through the colors and count consecutive 'A's and 'B's
    // we start iteration from 1 and end at i == len(colors)-2;
    for i := 1; i < n-1; i++ {
        if colors[i] == 'A' {
            if colors[i-1] == 'A' && colors[i+1] == 'A' {
                aCount++
            }
        } else if colors[i] == 'B' {
            if colors[i-1] == 'B' && colors[i+1] == 'B' {
                bCount++
            }
        }
    }

    // Alice wins if she can make more moves than Bob
    return aCount > bCount
}

Complexity Analysis

Nothing to analyze here
Time complexity: O(n) ~ Linear
Space Complexity: O(1) Constant

Takeaways/ Lessons

This question really tests how you can convert business logic into code and simplify problems. It really is a simple problem and you would easily be wasting company's time and resources if you are unable to see that
Also, don't jump heading into solving questions. when stuck, try to solve manually with test cases and not programmatically.

Conclusion

In tackling Leet2038, we've learned that even seemingly simple problems can test our ability to simplify and implement business logic effectively. The key is recognizing the essence of the problem and avoiding unnecessary complexity. The essence was simply who wins. every other variable (E.G how many times a player can remove from a consecutive subsequence) is unnecessary if they do not help us achieve our result.

You very likely missed the intro article A.K.A disclaimer, to this series but here goes. This is the first actual article with real content (for this series) and, we are tackling an easy leetcode problem, I attempted the champagne glass that was the "problem of the day" prior. Let's just say it didn't go as planned 😄. #chucklingEmoji.

While today's problem might have real-world applications, I don't know what they are yet so, we'll focus on understanding and solving it for now. Grab your favorite bodysuit and let's dive in.

Problem Statement

You are given two strings s and t.

String t is generated by randomly shuffling string s and then adding one more letter at a random position.

Return the letter that was added to t.

Initial Thought

Clearly, this is a problem where you have to iterate through a string and try to decipher if you have seen that string before. we all know, at least I know, that the general approach to that, that will lead to a linear time complexity is to introduce a hash map data structure. (Because well, fast lookup).
That part is obvious. where you might start to go wrong is using a test case of short strings. that way, it won't be obvious that you only have 26 alphabets in the English language and you might need to track the frequency of appearance,
my initial approach was to use the hash map and map a key of the alphabet to true showing that I had seen it before.
what happens when an alphabet shows up the 2nd, or 3rd..... time? Now you can see how that approach is wrong right?

Actual Approach

Givens:
1. we need to use an hash map to keep track of the letters.
2. We need to also record the frequency of seeing it. How many times Have I seen this letter?
you might start to wake up now, if we were given a string s that has 10 letters, and t with 11 letters, clearly if we store both in separate maps and compare, whatever key in the map that has 1 more than the same key in the other map is the answer.

Arrgh, I didn't want to have to illustrate this but...

s= "abcdefde" t= "cdeabdzef" //you can see that we added z right?
//now, the map looks something like this
sMap ={a:1,b:1,c:1,d:2,e:2,}
tMap={a:1,b:1,c:1,d:2,e:2, z:1}

looking at the map, the answer is obvious right ?Z. but getting the answer programmatically might be a bit tricky. so, instead of using 2 separate maps, why not 1 right? and as we have populated the tMap using the string t, we can depopulate it in the same vain as the s string until everything defaults back to 0, and z becomes 1. Now, we can loop through the object and look for the key that has a value of 1. There goes our answer. we can do it the other way round too.

Implementation

function findTheDifference(s: string, t: string): string {
    const map = {};
    for(const char of t){
        map[char] = (map[char]?? 0)+1
    }
    for(const char of s){
        // I expect to always have at least 1 map[char]
        map[char] = map[char] -1;
    }
    for(const key in map){
        if(map[key] ===1)return key
    }
};

Perhaps, we should solve this in go too. flexing my beginner go-lang skills. (I don't like yet that there is strings and there is byte in Go. can't we just stick with strings only? I'll get to understand the benefits later though). at least, I definitely love that for loops and while loops have the same syntax.

func findTheDifference(s string, t string) byte {
   myMap := make(map[rune]int) 
//here, we used a type of rune instead of string or byte.
// why? that is a task for the reader

   for _,char := range t{
    //unlike JS, we can do this in go because it will default the value 
    //to zero since it knows it is to be an integer. 
    //we don't have to manually default it ourselves. 
      myMap[char] = myMap[char]+ 1
   }

   for _,char := range s{
       myMap[char] =  myMap[char] -1
   }

   for key, val := range myMap{
       if val == 1{
           return byte(key)
       }
   }

   return 'a'
}

Complexity Analysis

in our approach, the maximum size of our map is 26. since we are only dealing with 26 English alphabets. that is constant space.
for time, we iterate through the s and t strings once each and once through the map, that is 0(n+m) + 0(1). simplified to 0(n).
Time complexity: linear
space complexity: Constant

Lesson Learned

Well, I learned why you use a rune type instead of string or byte for situations like when I initialized myMap in the go solution. myMap := make(map[rune]int)
It is the reader's responsibility to find out why

Other Approaches

There is the Ascii method where you convert the letters to Ascii numbers and add them all up. s is added separately, and so is t. then, subtracted from each other. the difference gives a corresponding English alphabet. however, I do not like this approach, it is certainly faster because working with numbers is faster for computers, but imagine a scenario where 2 letters were added, you can see the ASCII method might become useless or more difficult to implement. exactly. stick with the mapping method.

Real World Applications.

I think it is very similar to ceaser cipher which is a very old method of encryption.
That is all I know

Conclusion

You can already start to notice the problem. While it might not be that hard to put your thoughts in an article, it can be daunting and time-consuming to create one that you consider satisfactory. oui oui?

Still, that's not exactly a problem that can't be dealt with. After all, Whatever is worth doing at all is worth doing well. Well, Except, I do NOT own that kind of time.🤡

Hehehe!!! This series is strictly a learning process for me. It's to reinforce new ideas and concepts I've learned by re-explaining them and putting them down so I can think more deeply about them as I do so. Hence, the quality of the write-ups will very likely be subpar, but they will achieve their purpose: [ME!].

What to Expect

I aim to publish a new article every day, (Don't be surprised if I'm only able to write one each week though). stay tuned for daily updates anyway!

Your Feedback Matters

Feel free to leave comments or questions. Your input can help me correct mistakes for myself and fill knowledge gaps. it will also help me refine the series and make it more useful for everyone.

If you've ever felt puzzled by closures in JavaScript, you're in good company. You could be using closures every day in your code and not even know it! Yep, true story. Believe it or not, I once aced a closure-based interview question without fully understanding what closures were. However, understanding closures can significantly elevate your coding skills.

#What is Closure in Javascript ?

MDN says "A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function's scope from an inner function."

Maybe we still can't define what closure is yet. We can at least agree that it is enclosed in some form of container called the Lexical environment, it also has something to do with functions bundled together with something about references.

What then is a lexical environment?
Clearly, we have to understand some basic concepts first before delving into closure itself as a concept.

Concepts around closure

Concept #1: Scoping / Lexical scoping.
Scoping simply means the locations a declared variable has "access" to and the lexical behind it tells you that the scope of a variable is determined based on its location in the source code.
In JavaScript, especially modern javascript, where you declare your variables matter. like, a lot! Variables defined in a function are not accessible outside of it, but they are accessible to functions nested/ inside that function.

const bookName = "readings";

function getAuthorName(){
const author = "Ajayi";
console.log(author, bookName); //"Ajayi readings"

function nestedFunction(){
    //has access to variable declared in the parent function
    // also has acess to global variables. E.G bookName
}
return author;
}

console.log(bookName) //"readings"
console.log(author) //Uncaught ReferenceError: author is not defined

As explained earlier, where you declare your variables matter in JavaScript because the scopes of these variables are created based on their location in the source code.
The rule is simple.

Variables defined with "let" or "const" within a block of code are only accessible within that block.

Hence, it is easy to understand why author and bookname in the example above are accessible within the function getAuthorName but trying to access author outside of the function throws an error.

Concept #2: Block Scoping, Functional Scoping, Global Scoping, and the Story of const ,let and var.
This is a topic that deserves its own stage, but let's do a quick fly-by.

• Block Scoping: Variables declared with let and const stick to their block. It's just the modern way of doing things.

• Functional Scoping: var is the OG here and it lives within the function it's declared in. It transcends the block scoping.

• Global Scoping: Variables in the global scope are not declared within any block or functions, they can be accessed anywhere in the code.

• const vs let vs var: Use const for constants, let for reassignable variables, and var... well, mostly avoid. 🤷‍♂️

For a deep dive into this, check out this article that explains it all. Don't worry, I'll tackle this head-on in a future article!

Concept #3: Lexical environment
This is the tricky bit and it is quite theoretical in its own right. let me try to explain with a simple analogy.

Imagine you're a detective, and you're trying to find clues to solve a case. The place you'd look for these clues first is where the incident has happened (the crime scene), then you might find clues that lead you to look outside of that immediate environment. somewhere outside of the scene. The scene is the lexical environment. In JavaScript, a Lexical Environment exists for each block of code, each function, and yes, even for the global context that runs. Each lexical environment has two parts:

1. Environment Record: This is the abstract location in which something has happened in code. E.G. a function call. It stores all the variables and declarations in that function.

2. Reference to Outer Environment: Don't you love it when you're not confined within your space? same for our environment too. The environment likes to keep a reference to the Lexical Environment of the parent scope, parent parent scope, or global scope. You get the idea. It keeps a reference to the outer environments it will have access to.
   Here's a quick example to quench your cravings for some lines of code.

let city = "Gotham";

function batSignal() {
  let message = "Bat Signal activated in " + city;
  function displaySignal() {
    console.log(message); // "Bat Signal activated in Gotham"
  }
  displaySignal();
}

batSignal();

In this example, the function displaySignal() is nested inside batSignal() making it a Lexical Environment within another Lexical Environment - remember every function has its own Lexical Environment? When displaySignal() wants to print message, it first checks its own Environment Record (nope, not here!), and then the Reference to the Outer Environment kicks in, leading it to find message in batSignal()'s environment, a parent environment. 🦇 Kapish!!!

Perhaps now, MDN's definition will start to make sense. A closure, being a combination of a function with reference to.....

Concept #4: The Beast; Closures.
Remember when we talked about Lexical Environments? Good, because closures are like little minions that carry their own Lexical Environment wherever they go. Let me spill the tea.

A closure is a JavaScript function that remembers its outer variables even after the outer function has "returned" or after it has been "dissipated". In simpler terms, closures are functions that "remember" the environment in which they were created. 🤔
Let's take our next illustration from Leetcode. The createCounter question.

//Given an integer n, return a counter function. This counter function 
//initially returns n and then returns 1 more than the previous
//value every subsequent time it is called (n, n + 1, n + 2, etc).
function createCounter(n) {
  return function() {
    return n++;
  };
}

// Example usage
const counter = createCounter(10);
console.log(counter()); // 10
console.log(counter()); // 11
console.log(counter()); // 12

Here, counter is a closure because every time you call it, it still knows the latest value of n and still has the ability to update it

How It Works 🧙‍♀️

1. createCounter(n) returns a function (anonymous function). That function remembers the state of n even after createCounter has finished its execution. why? reference to outer lexical environments.

2. Each time the returned function counter is called, it returns the current value of n and then increments it by 1 using the post-increment operator (n++)
   and that my friends, is how closures work. The returned function, which is the closure is like a minion that goes about with its own suitcase containing its own lexical environment and references to outer environments that scoping has allowed it access to.

The Nitty-Gritty: Specific Use-Cases for Closures

Use-Case #1: The Vault
JavaScript objects are wide open by default and can be manipulated at will. but you don't always want that. Sometimes, you want to create a vault that not everyone has access to and then keep your secret variables there. You see, before the introduction of classes and private variables in Javascript, Closures were a way of keeping variables private within a function so that only methods within that function have access to retrieving or changing their value.

function createBankAccount(initialDeposit) {
  let balance = initialDeposit;
  return {
    deposit: function(amount) {
      balance += amount;
      console.log(`Deposited ${amount}. Current balance: ${balance}`);
    },
    withdraw: function(amount) {
      if (amount > balance) {
        console.log('Insufficient funds');
      } else {
        balance -= amount;
        console.log(`Withdrew ${amount}. Current balance: ${balance}`);
      }
    }
  };
}

const myAccount = createBankAccount(1000);
myAccount.deposit(200); // You can do this!
myAccount.withdraw(500); // And this!
console.log(myAccount.balance); // But not this, Error!

In the code above, balance is a private variable that can't be accessed directly from outside the createBankAccount function. It can only be modified using the deposit and withdraw methods. why? aha! You should already know. because deposit and withdraw are closures. They are the only ones who still remember the value of balance even after the function createBankAccount has been executed and forgotten about.

Use-Case #2: Time Traveller; the secure timekeeper.

function launchSequence(start) {
  let count = start;
  return function() {
    console.log("T-minus " + count);
    count--;
  }
}

const countdown = launchSequence(10);

for (let i = 0; i <= 10; i++) {
  setTimeout(() => {
    countdown();
  }, i * 1000);
}

You can use closures to create timekeeping functions that cannot be tampered with from the outside world.
Here, countdown is a closure. It's carrying count from launchSequence() with it. Every time you call countdown(), it still knows what count is and updates it. countdown() carries its own supply of reference to count in its little briefcase

use-case #3: The Function Industry. We make food and we make functions.
Imagine you're operating a food truck. You've got your menu, but you also allow customers to customize their sandwiches. You need a way to easily produce variations of your menu items.

function sandwichMaker(fillings) {
  return function(breadType) {
    return `Here's your ${fillings} sandwich on ${breadType} bread!`;
  }
}

const makeChickenSandwich = sandwichMaker("chicken");
const makeVeggieSandwich = sandwichMaker("veggie");

console.log(makeChickenSandwich("sourdough")); // "Here's your chicken sandwich on sourdough bread!"
console.log(makeVeggieSandwich("rye")); // "Here's your veggie sandwich on rye bread!"

here, sandwichMaker is a function that takes a filling (like "chicken" or "veggie") and returns another function. The returned function then takes a type of bread, completes the sandwich, and serves it up!

So, every time a customer comes, you just have to call your pre-configured makeChickenSandwich or makeVeggieSandwich function with their choice of bread. Each function can be attached to its custom button. Now, you only have to hit the chicken or veggie button without having to worry about what could have been if you had only one sandwich button.

Use-Case #4: left Hook, right Hook, southpaw, useState Hook.
This is easily my favorite use case. I have been using the React's useState hook for years. I never cared about its implementation details. still don't.
however, you might begin to wonder, perhaps, the useState hook uses closure under the hood.

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

What is going on here?

• State Preservation: useState gives you a variable (state) and a function to update it (setState). This state variable is preserved between function calls, much like a closure!

• Functional Updates: This is where closures really kick in. When you update the state based on the previous state, you do something like this:

    setCounter(prevCounter => prevCounter + 1);
  

  Notice prevCounter? That's the previous state captured and passed into the function. setCounter must be a closure, folks!

Closing Prayer

Understanding closures in JavaScript is crucial for anyone looking to master the language. Closures offer a way to preserve state, encapsulate private variables, and enable dynamic function generation. Even if you're not keeping closures in your pocket for everyday use, knowing how they work demystifies a whole bunch of JavaScript quirks. Think of it as being able to see The Matrix. This understanding will prove invaluable across various JavaScript frameworks and libraries.