One very important thing that is greatly overlooked is our need to put ourselves out there and be known. More often than not, we don't want people to know our business, what we are up to and what we do. Ask yourself, what good is it to be very good at something if you are not known for it? Even the Bible talks about how unwise it is to light a candle and put it under a bed.

That ancient wisdom applies directly to our modern lives. Whatever we do, whatever we're good at, we should strive so hard to relentlessly publicize it. That's the only way to get others to know what you're into and what you're good at. The goal should be to let people think about you whenever your field, industry, or area of expertise is mentioned. Until people know what you do and what you're good at, you cannot be recommended for anything. People only recommend others based on what they know about them and what they see them to be really good at. Never forget, society pays a lot of attention to whatever you do and put out there.

You should have it in mind: OBSCURITY IS YOUR BIGGEST ENEMY. Do everything you can to dominate the space you are in. When you dominate the space, you will be the first person that comes to mind when the topic is mentioned. You should not want to be in a race, you should be at the top of the list of considerations.

If you are in a field that even pays more attention to skills than to one's level of education, you should even be more crazy about being known. Are you a tailor? Well then put your designs and your work out there. Are you a software engineer? Well then, write about what you do, write on topics, work on projects and put them out there. People may mock you for putting yourself out there, but that is a small price to pay. The alternative is silence and obscurity, and that is a cost no one should be willing to accept.

Wall clock time is the time we see on our clocks. It's the time we are all used to and respond with when someone asks "what time it is?". Monotonic time on the other hand, is one that simply continues to increase since the computer started. When used in programming, it's the time that has passed from the point the timer was started. Monotonic time is mostly used to measure the time that has elapsed between two events.

Monotonic times have two characteristics:

1. They tick forward at a regular rate

2. They are detached from current time of day

The value you get from reading a monotonic clock is typically a long integer. It's usefulness is greatly seen when it's compared with other monotonic times.

The reason why we need to keep track of the two types of time is because, wall clock time does not uniformly increase. It can be affected by the user's manual adjustments to the clock, daylight saving time, and other factors like network time changes. Since it can be affected by these factors, it's not a good idea to use it to measure the time that has elapsed between two events.

Using wall clock time in programming can cause weird bugs where your programs might be thinking a certain duration of time has passed, when in reality, it's been longer or shorter. One major assumptions people make is that "Time difference cannot be negative". Going back to our reason why we need to keep track of the two types of time, we can see why this might be the case. Assuming we have two times, t1 and t2, and we want to find the difference between them, we can do so by subtracting t1 from t2. Should time t1 be before time t2, the result will be negative, which breaks our assumption. Time t1 can always be before time t2 because we learnt that wall clock time can be affected by the user's manual adjustments to the clock, daylight saving time, and other factors like network time changes.

Time difference being negative actually caused a big issue one time for Cloudflare DNS.

In 2017, Cloudflare experienced a significant outage during a leap second adjustment. Their RRDNS software compared timestamps before and after the leap second was inserted, resulting in negative time differences. This violated the code's assumptions and caused the software to crash repeatedly. You can read more about it here

When dealing with time, you should never ever think that time difference cannot be negative, never think that time cannot go backwards. Having these ideas in your mind will help you build programs that are more robust and reliable. Wall clock time is suitable for displaying time to users and scheduling based on the time of day, but it's inappropriate for measuring elapsed time due to its susceptibility to adjustments. Monotonic time, with its steady forward progression, is the correct choice for duration measurements, timeouts, and performance profiling.

So writing a simple mail server means that your server has to run on the appropriate port of SMTP, mostly 25 (these are all well-known ports and should not be changed without reason), and also accept and respond with the appropriate status codes for each and every request that comes to play. For example, if the sending mail server sends the command helo, you must know that the right thing to do is respond with the 250 OK code which is mostly the standard response..

These are all fundamental concepts that are highlighted in the various RFCs proposed for the protocol. Once all these are taken into consideration, the initial exchanges can go through without any hassle.

The only thing about this that becomes quite of a hassle is when it comes to mail delivery. There are lots of barricades on the web that prevent the sending of mail from any mail server due to the potential security risks. Although the sending might go through, it is the matter of deliverability that is of major concern.

There are many ways to mitigate that problem such as using relays to send your email. This simply means relying on other established services to forward your mail since they have all the fundamentals done right to ensure that all your mails is delivered to the receiving mail servers. These relays can be done through services like Mailgun.

Building a simple mail server that actually works is not only dependent on you going by the RFCs but also making sure that you follow the standard procedures, including setting up your domain name and the associated Zone files to include the MX records.

To actually understand the keywords and the various subtle workings of smtp by building your own, you can rely on some libraries to take out a chunk of the work needed to go about it. For example, you can use the sockets library in python to set up the necessary tcp sockets needed in order to listen in for connections and also respond appropriately to those requests. You don't need to build everything from the socket level, as that would be a significant hassle.

There are other important factors that need to be considered to actually build a really solid SMTP server. Since this is mostly a basic overview, detailed insights into protecting your mail server and meeting other necessary criteria have not been covered.

In the next post, we will be looking at how to build a simple smtp server using python and the sockets library. Stay tuned for that, but then, to ensure we are on the same page, you can read up on the SMTP RFCs to get a better understanding of how the protocol works.

Resources

• SMTP RFC

• SMTP Commands

• SMTP Status Codes

• SMTP Overview

• SMTP Relay

• Zone Files

• MX Records

• Python Sockets

• Mailgun

The definition for the IP address above is that of the IPV4 IP address since it was the first variation of IP addresses. IP addresses, however, come in two variants, the IPV4 and the IPV6 addresses.

The reason there are different variations of the IP address is as a result of the growing number of devices that are connected to the internet. Since an IPV4 address is only a 32-bit number, it allows for a maximum of 4 billion IPV4 addresses.

$$\text{Total IPv4 addresses} = 2^{32}=4,294,967,296$$

This led to the introduction of the IPV6 address, which supports even more devices. It is estimated that there can be a total of 340 trillion trillion trillion IP addresses. IPv6 addresses are 128 bits in length and are written as eight groups of four hexadecimal digits separated by colons.
An example of an IPV6 address is this: 2001:db8:3333:4444:5555:6666:7777:8888
They do not only consist of numbers but also letters in general.

$$\text{Total IPv6 addresses} = 2^{128} \approx 3.4 \times 10^{38}$$

Types of IP Addresses

IP addresses are grouped based on the following criteria: the location of the device in a network and the static or dynamic nature of the IP address generated for the device. As a result, there are 4 types of IP addresses:

• Static IP address

• Dynamic IP address

• Private IP address

• Public IP address

PUBLIC IP ADDRESS: Public IP addresses are those that are assigned to a device in order to make it communicate over the internet. These addresses are generated by the ISP for every device, which makes it possible for the devices to be reachable over the internet. You can check your public IP address using this service.

Private IP Address: Private IP addresses are assigned to devices in a network and are not meant to be exposed to the internet. They are assigned by the router and are used to uniquely identify devices that are in the current network of the router. IP addresses that are private are only limited to the current router they are connected to, meaning that outside of the current router network, there can be the same IP address again in another router’s network. That is to say, they are only unique to their current network.

Static IP Address: A static IP address is one that is manually assigned to a device and does not change. These are the typical IP addresses used by servers over the internet. Because they are static, it is easier for clients to resolve their domain names to their IP addresses using a DNS resolver.

Dynamic IP Address: Dynamic IP addresses are those that are assigned by ISPs to devices when they connect to the network. Dynamic IP addresses are only present for some time, after which they expire and have to be reassigned. Dynamic IP addresses are created by the ISPs using the Dynamic Host Configuration Protocol (DHCP).

DHCP (Dynamic Host Configuration Protocol)

The Dynamic Host Configuration Protocol is a client-server architecture used in networking to ensure that devices get assigned IP addresses when they connect to a network. The DHCP server maintains a pool of IP addresses that are currently being used and those that are not currently being used. For each request from a DHCP enabled client that comes in, the server leases one of its unused IP addresses to it.

A DHCP client is a piece of software that runs on devices that can connect to the internet, such as mobile phones, laptop, etc. Immediately the device gets connected to the network, the client broadcasts a request for the IP address and other configuration of which the DHCP server responds to with one of the ip addresses from its pool. Clients receive IP addresses for a certain amount of time known as Lease time. Before this time is up, the client can request to renew the IP address, think of it like requesting a new access token with your refresh token in your web applications.

DHCP servers eliminate the need to manually assign IP addresses and reduce the overall risk of making a mistake when assigning IP addresses. Having DHCP servers ensures that devices do not get static IP addresses since static addresses are becoming more and more scarce with the growing number of networked devices.

More details about the DHCP protocol is defined in RFC 1531

IP addresses, in combination with port numbers, ensure that devices over the internet can send and receive information from one device to another.

One of the most important metrics for ensuring that the users of your software are happy with the general service is speed 🏎️. No matter how good your service is, once it is slow, users begin to look out for alternatives that will work much faster.

My URL shortening platform was getting some traction—about 1 signup daily and over 850 redirects per day—but its popularity came at a cost: a skyrocketing number of database read operations. This meant sluggish redirects and frustrated users, which was the exact opposite of what I wanted.

Response times for resolving shortened links were around 1.2 seconds, and it had already made over 44 million row reads 🤯. I got very particular about the row reads because everything is being run on a free tier, and the database has a maximum of 1B row reads. 40 million is very low compared to 1B, but I was still very concerned.

Armed with some system design knowledge, I embarked on making sure that this problem was looked into.

Quickest thoughts: Caching

The first thing that came to mind was Caching. Sitting to reflect, I was wondering why I had not thought about including this before the earliest release. My sole reason was premature optimization; basically, I was thinking I was the only user, so why would I want to spend so much time thinking and implementing this?

The idea of caching made a lot of sense, and it is by far one of the most basic things to include in systems to increase response times and performance. Think about CDNs and domain name resolution caches, among other things.

Before I delve further, you might already have an idea of what the problem statement is, but then let me go ahead and state it once more!

PROBLEM STATEMENT:

We are currently using a free tier database, which has a limit of 1B read operations. We are currently reading every link from the database everytime a new request is made, which is increasing our read operations and thus, getting us closer to the free tier limit. We want to improve response times and also reduce read operations.

Implementation Mechanism

The next thing was how I would go about the implementation. Because getting the implementation wrong can lead to a whole lot of consequences.

• What if a link's destination is updated and the wrong data is being stored in the cache?

• What if a link's alias has changed? Does that mean users are redirected to a 404 page, although the link is really there?

Like I said, getting this wrong will lead to your users having the worst experiences. In the sections below, I will try to explain my thoughts clearly so you understand why I did certain things.

Caching Service Used

I opted for Redis since it is the most common and the one with the most available resources on it, be it platforms offering it as a service or even supporting documentation. Since my site is built around Nextjs, I used Redis through Upstash service.

Caching Strategy

Although there are numerous caching strategies, I stuck to the write-through cache strategy. Here, we write data to both the cache (Redis in this case) and the underlying database (MySQL) simultaneously. With this in place, what essentially happens is that, until a cache is invalidated or evicted, we will not hit cache-miss since the cache is readily pre-populated.

Cache Invalidation Strategy

Cache invalidation is a process in a computer system whereby entries in a cache are replaced or removed. [Wikipedia]

Sometimes, the allowed cache storage sizes might get close to filling up; when it is approaching this instance, we will have to either get rid of some of the items in the cache or clear the whole cache. This also has different ways of being done, and each has its own intention. I will list some below, then talk about the one I settled for.

• Random Replacement: Randomly selects an item for eviction when space is needed.

• Least Frequently Used (LFU): a strategy that prioritizes keeping items in the cache that have been accessed the most often while removing those that have been used the least

• Least Recently Used (LRU): a strategy that removes the data items that have been accessed the least recently.

• Time To Live (TTL): Each item in the cache is assigned a specific expiration time. When the time expires, the item is automatically evicted, regardless of its access history.

I ended up using the LFU (Least Frequently Used) strategy for our cache eviction. This is because we want to keep the most frequently used links in the cache and remove the least frequently used links from the cache. Sometimes a link might only be clicked on once; in that case, it is of no use lying in the cache and taking up precious free-tier space 🥺

General Design

Request -> Cache -> Database -> Cache -> Response

Since we are using the write-through cache approach, every time a user creates a link (probably they are going to share that link in the next instance), so we concurrently write that particular link to both the cache and the database being used.

Once a request for a particular link comes through, for example, ishortn.ink/someAlias I check the cache to see if we have that particular link in there. I used the aliases as the cache keys since they are unique and there will not be more than one of the same aliases in the system.

If the link exists in the cache, we go ahead, retrieve it, and also record some other things that need to be recorded, and the response is sent back to the requester.

In situations where the link is not found in the cache, it is retrieved from the database, written to the cache, and finally returned to the user.

Outcomes

So you will realise that for the current implementation, if a new link is created and the next moment there are 600 clicks on it, it means that the only DB action we did was to just write the link to the table 🤯. Cutting down 600 read operations.

Even if the link is not found in the cache and we have to read from the DB, it means that we will just have one DB read and 599 cache reads 😎.

Not to forget, reading from the cache also means avoiding all the network overhead in retrieving something from the DB, and hence, we are able to respond to requests even much faster.

Initially, a single redirect resolution could take about 1.2s, but with all this implemented, we can literally do the same work in just shy of 200ms 🚀. Over 800 ms of work cut off!

In fact, implementing this and thinking through everything has really been fun and interesting! Now I can save precious free-tier resources and also ensure that my users are still happy with the service, so they keep referring more individuals.

Caching is really a game-changer!!!!

I hope you learned a lot from this and enjoyed reading. If you would like to inquire further, please leave a comment, and I will do my best to answer!

Happy Hacking!

This time around, I had to work with a team of designers and other developers to build a project. The designs weren't really complex, but I managed to mess up a lot of things. Just like my other contributions, I tried to get many things done in a short time. This made me make a lot of mistakes that sometimes made me feel stupid when they were brought forth by the designers and other developers. The period of working with these people made me realize that it is not all about getting things done swiftly but also ensuring you get them done correctly.

You see, user interfaces are not like backend APIs or SQL queries that are mostly not device-specific. Once you write your select statement correctly, it will work on any database. Once you write your API correctly, it will work for any device that requests it correctly. I mean, you get the point. But then, this is not the case with UIs. You have to ensure that your UI works on all devices and that it looks the same on all devices. This is where the problem lies. Measurements are very different here, and there can be several different measurements for different devices, so you have to ensure that you get the measurements right while also getting the interactions right. (I mean, think about the number of Android devices out there; you have to ensure that your UI works on all of them 😅).

Getting into the specifics of the project, I had to build a landing page that was designed in Figma. Every design comes with specific design guides such as spacing, font sizes, user interaction feedback, shadows, and the list goes on.

When I started out, I did not really pay attention to these, my ultimate goal was this: Get it done and get it done extremely fast. It is good to get things done quickly but not at the cost of not producing the right stuff. Every pull request I submitted, there was a little issue, and most of these issues are some of the most obvious things I overlooked. Some of these issues were:

• Using wrong margins and paddings: As an avid tailwindcss user, I was used to using the default utility classes I thought were right based on my Eye test (Eye Driven Development 😂). I did not really pay attention to the design guide and I ended up using the wrong classes. This was a very big issue because it made the UI look slightly different from the design, which obviously the UI designers were not happy about. Having these things pointed out to me all the time really made me feel bad because I knew I could have done better.

• Using wrong font weights: When designing, font sizes are usually not the problem here, but then the weights of the font vary greatly and are not always determined by just looking at the design in the figma file unless that particular element is inspected to see the actual font weight. I made a couple of these mistakes, and in the end, I had to go back and make a lot of changes to the codebase.

This list goes on and on, but then I will stop here.

Making all these mistakes made me realize something, it is good to develop things swiftly but you must not compromise on the quality of the work you are doing. It is better to take your time and get things done correctly than to rush and get things done wrongly. I am not saying you should not be fast, but then, you should not be too fast that you end up making a lot of mistakes. Remember, Quality over Quantity.

Also note that we are all humans no matter how much you and your colleagues try to be perfect, you will still make mistakes. The most important thing is to learn from these mistakes and try not to repeat them again. Too many mistakes can make people question your abilities and that is not a good thing so always try to do your best and pay attention to details.

Before I sign off though, I will share some things I decided to do early in each project to ensure I always produce work that is of high quality. Some might be specific to some tools like TailwindCSS but then, you can always find the equivalent in your own stack.

• Always read the design guide: Quickly go through the design guide and see what the designers have to say about the project. This will give you a good idea of what to expect and what to look out for.

• Setting up the right project configuration: Now, I go through each design and note down all the colors that will used in the project. This I mostly do in the tailwind.config.ts/js file. I also note down the font sizes and font weights that will be used in the project. This will help me to always use the right classes when building the UI. This also makes it much easier to change things later along the line, like when the designers decide to change the font size of a particular element, you can just go to the config file and change it there and it will reflect across the whole project.

• Using the right sizes: In some cases were you might need to design a particular thing at just one point and you did not add the config for that, please do not rush into using the default utility classes that you think are right. It is better to use the exact value in the figma design than to use the wrong utility class. This will save you a lot of time and review stress. Example, say an element used in only one particular section has a font size of 45px. You might be tempted to use the text-4xl class but then, that is not the right class to use. It is better to use the text-[45px] class. This is what TailwindCSS calls the Arbitrary Values. You can read more about it here.

These are some of the things I have learnt and I hope you find them useful. If you have any suggestions, please let me know. I am open to feedback. Thanks for reading.

I encountered this a lot. It makes you start to question a whole lot of things, from whether it's your brain that cannot process much to whether you are not built for this field and a whole lot of other things.

But then, after spending some time questioning my skills and going back and forth between problems, it turned out that I was not really doing some things right from the onset and that had to do with the way I approached the problems I tried to solve.

In this article, I will try and explain why certain things should be avoided or embraced as I go over the 5 steps I used to improve at solving these problems.

1. Understand the problem, like seriously, take time to understand the problem

So for me, one major mistake I made was immediately starting to think about concepts to solve the problem as I read the problem. I believe this was the main ingredient in preventing me from solving these problems correctly. The reason why this is an issue is that you do not get to really get into the ins and outs of the question before you start thinking about implementation.

Note that, understanding the question is also part of the answer.

One time, I rushed into writing code for a problem when I had not even finished reading the problem and instead of returning an array of integers from the function, I was returning a single integer 🤦‍♂️. As you can tell, after countless times questioning why I was failing the test cases, it was going back to reading the problem that made me finally pass them.

As simple as a problem might be from the introductory sentences, please and please refrain from shifting focus to finding the right algorithm or data structure to use. Just take time to read and digest, before doing anything else.

2. Pseudocodes and Paper Solutions Still Rock

The second thing was that I jumped into coding real quick after lazily skimming through the question. This is the biggest mistake you can ever make, once you don't understand how something should work really well or the type of inputs your function will take, you know that you are definitely doomed and you cannot really do anything tangible.

Even if you understand the problem, you should not start with coding from your computer, just try and write some pseudocode on a piece of paper or notebook you have beside you or just say your thought processes out aloud (after all, you'll do this in a real interview). This is really going to improve your overall understanding of the problem and you might catch all the edge cases that come with the problem.

With your plan in place, it's just a matter of transcribing them into code using the correct syntax. Easy Peezy :)

3. Avoid Premature Optimization at all Costs

To add to my already existing stack of wrong approaches, I was also trying to code out the perfect algorithm from the start (Premature Optimization).

Premature Optimization: Trying to improve something especially with the goal of perfecting it when it's too early to do so.

When you start writing the solution to a problem and you start thinking in this way, it becomes a big issue. So rather than moving from the ground up, you try to hit the jackpot on the first try. Everyone knows that this is rarely even the case in casinos.

The best way to start solving a problem is to start off with the most basic and unoptimized approach, what we usually call the "Brute Force" solution, and slowly work your way up because, at this point, you have something that solves the problem but is inefficient that you just have to transform into an efficient solution. This is in contrast to you trying to optimize something you have not even written.

4. It takes time to get things right

Like it was or is in some of your university classes, it is not all the time you get a problem right on the first spot. It takes time and practice to become good at something. Don't get the wrong feeling for failing all the test cases, that is how we end up learning. As you fail these problems, you should spend some time trying to figure out what really went wrong rather than jumping into viewing the solutions that have been posted by other users. I found myself doing that and that really did not make me any better. It is much better to struggle a little bit more, if you still do not get it, you can go on and use the hints from the problem and also, log as much as possible, it is very important to know what is going on at each point in your code.

5. Compare and Contrast

One of the best feelings you can get is the satisfaction of being able to solve a problem correctly. You get really excited and happy, feeling on top of the world, cool right? One thing though is that you should not jump on to the next problem but then, try to always view solutions posted by other developers on the problem. Look, you will really learn a lot by going through it.

This is really something I use to my advantage and I learn a lot of handy handy functions, methods and even parameters to some functions.

This will also make you see the thought process of others and get a complete overview of the problem from other points of view.

To Conclude

I can assure you that fully utilizing this thought process is going to really improve how well you do in solving problems relating to DSA and programming in general. Also, do note that although it will be great to jump into practising problems on algorithms, you should make sure you have really learnt enough and mastered some very necessary foundational algorithms and data structures as these are mostly what other algorithms are based on and problems require you to understand.

All the best in your journey 🎊

A stack is a very important data structure that is used to work on data temporarily. Unlike other data structures that are built into a language, a stack is rather a layer added to an existing data structure, such as an array or linked list. In this tutorial, however, we will focus on the array-based implementation of a stack.

So just like arrays, the data added to a stack is stored in contiguous memory. The main difference between a stack and an array is how operations on data are performed. A stack behaves differently from an array due to a set of rules that are added to the behavior of the array.

Data structures that are built on top of rules from other data structures are called abstract data types. Another type of abstract data type is the queue, which we will discuss in another post.

The stack data structure is a very important data structure used in various areas of computer science, like recursion. A stack helps to implement various things. The undo and redo functionalities of your IDE are based on a stack; your browser navigation, forward and back, is also based on a stack.

How does it differ from an array?

The following rules differentiate how a stack operates from how an array operates.

1. You can only add to the end of the stack.

2. You can only read from the end of the stack.

3. You can only delete from the end of the stack.

In a typical array, one can insert data into any index they want, but in a stack, that is prohibited. If this rule is broken, then it is no longer a stack but something else. (#1)

Reading from a typical array does not restrict where in the array you read from. You can read from the beginning of the array, the middle, or the end, wherever you want to read from. But then, in a stack, it is mandatory to only read from the end of the stack.

The third rule states that you can only delete from the end of the stack. This is a very different behavior from a normal array because, in an array, one can delete at any index they want.

It should be noted that these rules are not pre-written in most languages but are implemented when the stack data structure is built. It is typically not a built-in structure but rather something that the programmer explicitly creates.

The end of the stack is referred to as the top. This is because we look at the stack not like a horizontal array but as a vertical array.

Scenario

You can think of a stack data structure as stones placed on top of each other, like in the preview picture above. To add another stone, you place it on top of the already existing stones, not below or in the middle (Rule #1)

If the stones were colored and you want to see (read) the color of the most recent one, you will obviously look down at the stones. The latest one simply refers to the one you just added to the stack. (Rule #2)

Also, to remove a stone, you would have to remove the one from the top first, as this is the only logical way to go about it if you don't want your stone empire to come crumbling down (Rule #3)

This behaviour of the stack is referred to as the LIFO This is an acronym for Last In, First Out. This basically means that the first thing you add to the array is the last thing that comes out.

Operations Performed on a Stack

The operations performed on a stack are:

• Reading, a.k.a. "Peeking,"

• Adding: AKA "Pushing to the Stack".

• Removing: AKA "Popping from the Stack".

Implementation of a Stack in Python

class Stack:
    def __init__(self):
        self.data = []

    def push(self, value):
        self.data.append(value)
        return len(self.data) - 1 # return the index of the item

    def peek(self):
        # Return the last value if the data array is not empty else
        # return None
        return self.data[-1] if len(self.data) > 0 else None

    def remove(self):
        # Here too when the user tries removing the last item, return
        # it if there are elements in the array else return None
        return self.data.pop() if len(self.data) > 0 else None

Code Explanation

We define the Stack class; as previously stated, the stack is a data structure that you create and does not come pre-built in most programming languages.

In the__init__ method, we create an empty array and attach it to the object. As you can see here, the stack we are implementing is based on the array data structure.

Next, we define the push method, the push method is responsible for inserting a new value onto a stack. This is accomplished by invoking the append method and passing in the user-supplied value. The append method adds to the end of the list, which is referred to as the TOP in a stack. The index of the last item is then returned.

Next, we define the peek method, the peek method simply returns the last item in the array if there are items in it; otherwise, it returns None.

The remove method is next. Here, we return the last item in the array. This is done by calling the pop() method on a list. This will remove the last item in the list and return it.

Let's quickly go through an example of this implementation.

s1 = Stack()
s1.push(1) # This adds 1 to the stack
print(s1.peek()) # This prints out 1, since it's the item at the top
s1.push(2)
s1.push(3)
print(s1.peek()) # This prints out 3, since it's the latest item at the top

s1.remove()
print(s1.peek()) # this prints 2 since 3 has been removed from the stack

As you can see from above, the LIFO behavior is working in full effect. The first item added will be the last item to leave.

Real-world use cases

• Browser Forward and Back Navigation
  Web browsers implement forward and back navigation using two stacks: the undo stack and the redo stack. As the user navigates between pages, the current URL is pushed onto the undo stack. Pressing the back button pops the URL from the undo stack and pushes it onto the redo stack, allowing the user to move backward and forward through their browsing history. This dual-stack system ensures efficient navigation between visited pages. This is a very simple breakdown; a lot gets built on this, though :D

• Function Call Management
  In programming, a call stack is a stack data structure that controls a function call. When a function is called, its parameters, local variables, and return address are pushed onto the call stack. As functions complete execution, they are deleted from the stack, returning the program to the previous execution context. This is mostly used in recursive programming.

• Solving Algorithmic Problems
  Several problems you will encounter will require some comprehension of stacks in order to solve them efficiently. Some include:

  • First-depth search problem

  • Reversing items in a list or string