DEV Community: Stipe

Epoch - Ethereum 2.0

Stipe — Mon, 10 Jun 2024 15:44:28 +0000

Greetings!! This is the first article that I plan to publish about random things Ethereum 2.0. In this article boss of the hour is Epoch. You will find out what is epoch in Ethereum 2.0 proof of stake, and what role does it play.

Ethereum Epoch is a time frame during a set of validators activities are happening.

Activities:

Validators propose blocks
Validators attest blocks proposed by others

Each epoch is divided into smaller time units, called slots. One epoch has 32 slots. Each slot lasts 12 seconds. Meaning each epoch lasts approximately 6.4 minutes.
One epoch therefore will have 32 blocks, and each slot will have one block.

In each slot there is one validator that is assigned to propose a new block, and a committee of validators that attest validity of that block.

Imagine a hotel named "The Grand Ethereum hotel". Each night, the hotel's kitchen team of chefs works together in a organised way to prepare a set of dishes for buffet dinner for hotel guests. Kitchen operates on a precise schedule to ensure fairness, efficiency, and culinary excellence.

Let us imagine one epoch is one night, or one dinner service. Therefore each epoch represents one dinner service over entire year.

For each slot, a team of chefs is involved. Among them, one chef is randomly chosen to be the Lead Chef for that slot. Selection process is fair, unpredictable and random, ensuring every chef has the opportunity to lead.

The chosen Lead Chef for that slot is responsible for making key decisions, coordinating the team's actions, and creating a dish (proposing a block).

Supporting Chefs' Role: The other chefs act as committee (attesting validators). They assist the Lead Chef by checking and supporting their decisions and actions, making sure everything is cooked perfectly. They attest the dish before it is given to hotel guests.

To summarise once again, In Ethereum 2.0, epoch consists of maximum 32 blocks. This means every epoch is composed of 32 slots, with each slot potentially holding one block. Slots occur every 12 seconds, making each epoch approximately 6.4 minutes long. Validators work within these epochs to propose and attest to blocks, ensuring the security and consensus of the network.

Distributed validator technology with Obol Labs

Stipe — Thu, 30 May 2024 10:35:51 +0000

Recently I was reading about Obol Labs and found intriguing what they are offering to the world. If you are into proof of stake I think you should read this one and check out their official docs

Obol team is working on Distributed Validator Technology. Their mission is to preserve decentralization, make validators more fault-tolerant, and even give opportunity for smaller individuals to participate as validator.

Quote from their documentation:

The Obol Network will become an open, community governed, self-sustaining project over the coming months and years. Together we will incentivize, build, and maintain distributed validator technology that makes public networks a more secure and resilient foundation to build on top of.

One word is enough. Beautiful.

If you are familiar with Ethereum 2.0, in proof of stake validators get punished for malicious activity. But sometimes validators get penalty without malicious intent. It can happen due to errors or misconfiguration. For example you can have 2 nodes and by mistake use same validator key on both, which would result in double voting or double proposing. Or your validator goes offline for longer than allowed, will result in inactivity penalty. Obol jumps to solve this as well. Lets find out how.

DVT - Distributed Validator Technology is a Ethereum proof of stake validator that consists of multiple entities forming one validator. Not all validators need to be online 100% of the time in order to continue participating in the network. More info on that in here

Charon is a distributed validator client designed to work as part of the Ethereum proof-of-stake protocol. It forms a cluster of nodes that collectively act as a single validator. Meaning they allow multiple entities to join into one group and act as one validator in Ethereum network.

Each node in the cluster is responsible for contributing to the validation process, ensuring high availability and fault tolerance.

Traditionally when you were setting up a node you needed to generate public/private key. Now you probably are already wondering, how will multiple entities who have joined to form one validator keep this trustless. Solution is called key sharing.

Entities who agreed to form a group and act as one validator, will collaboratively generate and share a distributed key without any single participant knowing the complete key. This process enhances security and fault tolerance for operating distributed validators by ensuring that no individual entity holds complete control over the key. You can find out more in official docs

Benefits of Using Charon

Resiliency: The distributed nature ensures that validator operations continue even if some nodes go offline.

Security: Distributed shared key mechanism enhances the security of the staking process.

Decentralization: Helps broader goal of Ethereum’s decentralization by enabling more participants to run validators in distributed way.

Setting up Charon involves coordination and careful configuration but results in a robust and secure validation setup for Ethereum staking. For more detailed steps and technical specifics, refer to the Charon documentation provided by Obol Labs.

Testing Pyramid

Stipe — Sun, 19 May 2024 12:19:40 +0000

Hey developers and CEOs, this article is for you.

Im going to explain you five different types of software testing that you need to know as a software developer or a CEO of an IT company.

You have probably heard of the testing pyramid. Chances are you probably haven't thought much about why the pyramid is a pyramid to start off with.

Unit Tests

Tests at the bottom of the pyramid should make up the majority of the tests in your test suite. This is where you should be focusing most of your efforts on. As we move up the pyramid, the tests become more complex and slower and they take more time to maintain. At the base of our pyramid, we have the unit tests.
Now, most developers are aware of what unit tests are and the importance of them. Developers are the one who are writing unit tests and they are responsible for that part of quality assurance. Developer writes unit tests for all the methods and functions in the code, to ensure that the program is working correctly at the lowest level.
You may wonder on the number of unit tests you have to write. That really depends on what the goal is for your testing strategy. You should aim for and test every single line of your code in your methods. If for some reason something is preventing you, then that should be a sign that your function is doing too much or you haven't written it with testability in mind.
100% testing coverage means to have test coverage of every single line of code.

Unit tests are not enough to ensure that your software is working and looking as expected. You should not assume anything if it is working at the lowest level, that it's all going to work when you put it together. That is often not the case. For that reason we introduce next level of testing in the testing pyramid.

API Automated Tests

The next level up in our testing pyramid is what we call API tests.
This is where we test each endpoint in isolation, to cover expected and unexpected behaviour. Error messages, response body, json schema, http status codes, etc.
API tests are very fast, and we should when scenario allows us aim for writing end to end tests. To ensure that feature workflows are working exactly as we expect them.

You would run them in dev environment which should be a mirror of your prod environment.

Unit tests and API tests are all generally run as part of the build process, before a release, after each git push to your working branch, after each git push to master branch or you have them scheduled to run at certain time. Depending on how your process is defined.

Frontend Automated Tests

If you're writing a web application, then these will typically be in the form of automated UI tests.
And we generally use tools such as selenium, playwright and such, to mimic user action in the UI through a web browser. The goal here is to test that everything is working as expected end-to-end, is clickable, typeable and such. These tests typically include a mix between functional testing, such as making sure that you can signup/login or a form is populated correctly, And acceptance testing, which makes sure that your application is meeting business requirements. I tend to write end-to-end tests in style what is called a Gherkin language, which follows the given-when-then pattern. Frameworks such as Cucumber or any other BDD framework allow us to execute code in this format while still having the tests non-technical-human-eye-readable.
These type of tests are significantly slower than unit and API tests and can take really really really long time to run, and typically they're not run on every single git push. Imagine you have hundreds of these tests, they can take several hours to run, so you generally need to run them overnight.

Frontend automated tests are not ideal if you want to be releasing very often in a startup style. Most QA teams split up their tests into multiple groups tagging scenarios by critical group that they can run before each deployment.
For example, most essential tests can be tagged as @smoke and you can setup to run only subset of those tests tagged with that tag after given action. This would save you time, and you would run only what you need. While full suite of tests you could schedule overnight.

It is important to note that these tests need all the components working together, and therefore they're typically run on an environment such as QA or UAT. It can take a while to have a stable set of end-to-end tests. Subtle things such as your application taking a little longer to load, or someone accidentally breaking QA or UAT environment can cause your tests to break, and therefore you generally need someone working full time on your automation tests. Maintenance is absolutely crucial, in both API and Frontend tests. Especially in Frontend tests, as they are most dependent and most fragile.

Manual Tests

As cherry on top of our pyramid, we have manual tests. These are the tests that either need human eye, human exploratory mind, or they are not worth the time in trying to automate them. Manual testing even though unfairly not respected enough play important part in the last final piece of functional and visual side of the software application.

There are certain bugs you can only find by executing manual testing.
Manual testing should be executed in various phases. While feature is developing, you want to test new things, but you also want to make sure you are executing entire suite of tests you have from before, to ensure that new code did not break existing features. That is also called regression testing.

When you find a bug in your application, it is always better to find it lower down the pyramid than near the top. Each bug found in manual testing phase makes you to run application, reproduce the issue and search for logs and try and work out where exactly your application failed. Compare that to finding a bug in your unit tests and you will be given a stack trace that shows you the exact line where the problem occurred.

Testing is...

Stipe — Thu, 16 May 2024 09:54:10 +0000

Testing involves conducting a variety of experiments to understand the product's actual behaviour, capabilities, and limitations, revealing insights beyond initial expectations or documentation.

Testing is:

Ensure everything works as expected
Identifying potential risks
Uncover edge cases
Promote culture of quality
Be the client (Put yourself in shoes of clients)

The main objective of testing is to uncover risks that could affect the product's success, including vulnerabilities, performance issues, and other factors that might lead to failures in production.

When we talk about edge cases, there are testers that will seem efficient in the eyes of project managers but they will never add extra layer that might cover potential risk. Testing seeks to find those rare but critical scenarios that occur at the extremes, they cover what can happen in rare situation. Rare does not mean less risky. One "hole" can be very expensive if discovered in production.

Testing is not:

Just writing test plan and test cases
Only finding and reporting bugs
Automate every single thing
One time thing

While documenting test plan and test cases is necessary, effective testing goes beyond this, requiring critical thinking, creativity, and adaptability to new information and evolving requirements.

Testing isn't about assigning blame for defects. It's a collaborative effort to improve the product. A blame-free environment encourages open communication and teamwork, which are crucial for successful testing and quality assurance.

Having automated tests is a super useful, but it cannot replace exploratory testing and human judgment. Some scenarios necessitate manual testing to uncover issues that automated scripts might miss.

Testing should be integrated into every phase of development, from initial design to post-release maintenance. It’s not just a final checkpoint but an non-stop process contributing to the product's continuous evolution and standard of quality.

The Graph Demystified - Fetching Data From The Limitless Blockchain Bookshelves

Stipe — Wed, 13 Mar 2024 14:45:32 +0000

As a curious man I was reading about the graph protocol. Since I am not a blockchain developer I wasn't aware of challenges when you are in need of grabbing certain data from a particular location on the blockchain. I found it interesting how Graph works and I think it is a good idea to share with others what I have learned and how I understood it. So let's get started.

Standard definition:
The Graph enables indexing and querying of data from various blockchains. It facilitates efficient and performant access to complex data sets, such as those from smart contracts and NFTs. These APIs(subgraphs) are queried with GraphQL.
More in official docs: https://thegraph.com/docs/en/about/

All humans common language definition:
Finding needle in the Blockchain data haystack, this is what Graph let's you to do in quick and easy way.

The Graph is not Google of blockchains. However, unlike Google where users directly type in search queries to find information, The Graph is used by developers. They integrate The Graph into their applications (web3 or Dapp) to query blockchain data efficiently. So, it's like Google's powerful indexing and data retrieval capabilities, but specialised for the world of blockchain data, accessible through a developer's toolkit rather than a simple search bar.

There are 3 roles in the system:

Indexor
Delegator
Curator

I will use analogy to explain each role in the system, so it's easier to understand.

Imagine Graph is gigantic library. Library is full of book. Someone needs to maintain those books, keep them in order, suggest new books that should be added to the library, add new books, and keep entire library running smoothly and safely. So lets get started.

Librarian = Indexor
Helper/Investor = Delegator 
Book Scout = Curator
Library user = Graph user
------------------------
Graph    = Library
Subgraph = Book

Now imagine a scenario, you are a research student/library user and you need to find certain information for your thesis. Next day you decide to visit library and see if they have a book that contains data that you need.

It's Monday, 08:00h in the morning, library just opened, inside the library are librarian (indexor) and the book scout (curator).

Book Scout (Curator) has been very busy. He has been exploring various sources, looking for Books that contain unique, valuable, or particularly relevant data. When he finds a Book that meets these criteria, he signals its value to the Library with a "recommendation" tag, which effectively is communicated to the Librarians (Indexors). It then is prioritised for acquisition.
This is how books (Subgraphs) are added to the library (Graph)

At roughly 08:30h, you (the student) are entering the library. Inside the library you are welcomed by the librarian (indexor), a knowledgeable individual, who manages the organisation and accessibility of the books (subgraphs).

In a short chat, you explain what kind of topic you are searching, and librarian (indexor) points you (graph user) to a particularly well-regarded book (subgraph) that covers exactly what they need.

Now when I have found the book I need, I am ready to borrow it but I only need one piece of information from the book. Good old librarian explains me that there is a new technique where I can take with me a particular piece of the book if I want. That new technique seems like a great idea, he explains that I can specify a "list of data" (GraphQL query) of certain chapters (fields) and he will service me with exact info that I chose. So this is what I did. I submitted a list to the librarian (sent a query to indexor), who found data in that book (subgraph) and delivered me exactly what I wanted. Wow, super nice!!!

It's important to note that Library's vast collection of books and its organised state are partially thanks to Helper/Investor (Delegator) who, although not actively participating in the day-to-day management, has invested resources into the Library. His support enables the Librarian to maintain and expand the Library's collection, ensuring that it remains a valuable resource for all library users.
In return Helper/Investor (Delegator) is rewarded with a portion of the profit.

Library user is amazed with how good the library ecosystem is functioning. Helper/Investor helps with his resources (GRT token), book scout (curator) busy as a bee searching and suggesting new great books (subgraphs), while good old librarian (indexor) is always there to serve in best possible way. Therefore in this harmony of collaborative effort they are providing library users (graph users) with access to exact data they need in efficient and accurate way.

If you have thoughts on how you see the Graph ecosystem, or you would like to add to this analogy, make sure to comment.

User should understand blockchain technology?

Stipe — Thu, 29 Feb 2024 16:54:57 +0000

Blockchain has been around since 1991. A lot of people relate blockchain to Bitcoin and think Satoshi Nakamoto invented it. What Satoshi did was he combined several existing technologies into one masterpiece, as no one had done before.

In the 1980s at BellCore, there were two colleagues, Stuart Haber and W. Scott Stornetta, who realized that everything was going to become digital, and digital records can be easily changed. So, the idea of having a need to have immutable records was born. In 1991, they finished their work, but it showed the world and its current technology development was not yet ready for it. So, it waited for many years to get picked up.

Blockchain technology is more than crypto. Important thing to know is it can be used not only in cryptocurrencies world, but almost everywhere. Why it's not already used in all other aspects of our digital services is another pair of shoes.

This technology is often thrown out there as buzzword in regular conversations by the business people who may not understand it, but they want to be part of the train that might acquire them some earnings. That is ok, not everyone should be a technologist.

There are two sides: those who create it and those who use it.

Those who create it are engineers, and they should know how it works. But should user know how it works?

Today you are using internet, tv, mobile phone, but do you bother to understand the foundation technology behind the internet, TCP/IP. Do you wonder how your tv converts a digital signal into an image? A tech called DSP. Or have you ever questioned your mobile phone and how the tech behind it enables you to talk and receive messages, GSM/4G/5G, probably no, and you are still an everyday user of all of these three. It's so common and easy to use that you now take it for granted, as if you are entitled to them.

That should be the goal of engineers: To implement blockchain technology into products that are useful for you, and the only thing that should matter is that the product you are using is useful and easy to use.

The assumption that understanding the technical details of a technology is essential for its adoption is misleading. Lack of technical knowledge has not stopped the mass adoption of tv/computer/internet/mobile phone. People are generally indifferent to the mechanics of technologies as long as they serve their needs effectively.

Therefore, leave the details of the problematics to those who are working on finding solutions, everyone else should wait to see if there will be a useful product that they would use.

Docker explained for non-technical people

Stipe — Thu, 22 Feb 2024 17:09:22 +0000

Over the years working in software testing I came to realise that there are keywords thrown out there as if everyone understands them. If I know how to use Docker it does not mean everyone else knows it, and to show respect we should always know the audience with who are speaking with and adjust the language so that everyone can understand. Goal is NOT to play smart, but person on the other side to actually understand you. That is also a form of respect.

Let's imagine a conversation inside a company between QA and Recruiter. Recruiter received a task to hire new QA, and we/company gave him a list of tools a new candidate should have. Recruiter received the info and that's were it usually ends.
Recruiter is left to find a person based on keywords, which is ok, but what if I, you or your colleague actually take a bit of time and help your recruiter to better understand what certain tool does for us.
Now, you can say: "OK, let recruiter google it, I don't have time". Fine, thats what everyone has been doing since Google is founded.

Remember this old wisdom:

Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime.

To show some respect, take a bit of your time and explain in real life examples a certain tool so that anyone who heard about that tool can understand what it does. High level is enough.

What is the goal? Why would you waste your time?
Sharing knowledge is never wasted time. It's called help. Helping someone to understand, will help him to do his job better, and ultimately find a better colleague who will work with you everyday.

Sharing knowledge is something you should be excited about. It should give you a feeling of satisfaction/accomplishment.

Let's write this in a dialog between me and recruiter.
Imagine a video call between two colleagues in the company. Recruiter Marco and QA Stipe :-)

Recruiter: Ok, amigo. Tell me what is Docker
Stipe: Docker is a platform. There are buzz words such as container and image. But don't worry too much about them.
Imagine a container as your own virtual machine where you can install OS (such as Ubuntu, Windows, ...), libraries, programming languages, applications, etc.

Recruiter: OK, and?
Stipe: And now you can use that container and run your application on it, or you can run automated tests.

Recruiter: Hmm, interesting. Can you tell me more but use some kind of real-life analogy
Stipe: Sure, imagine there is a chef who works in portable kitchen on various venues and events to cook meals.
Before event each portable kitchen is equipped with all the chef's tools, ingredients, and recipes. No matter the location of the event chef always has same conditions for cooking his meals. So he can cook meal in the same way each time, without any external factors as disturbance.

Recruiter: Mmmm, I'm listening
Stipe: You can look at portable kitchen as Docker container, while ingredients/tools/recipe inside his portable kitchen are libraries/tools/os. You see where I am getting?
This means Docker delivers to your entire team one environment for working. Their local computer, different versions of this and that are irrelevant, they can now bring that container up spin their application in it, deploy, run, test. And with that, a legendary headache of "it works on my machine" is resolved, because everyone has same versions of everything.

Recruiter: Oh, now I get it. Docker is brilliant
Stipe: It sure is. I'm glad you understand it better now :-)

Selenium/Playwright explained to non-technical person

Stipe — Sun, 18 Feb 2024 22:52:34 +0000

Aimed to non-technical audience, this post explains what is automation tool selenium and playwright, in everyday analogy.

Imagine Selenium or Playwright as professional bodyguard assigned to protect bustling metropolis called "About YOU webshop"

This web metropolis is filled with various items, offering various clothing, shoes, accessories, etc. And quite often it has discounts, and best deals. This marketplace is constantly evolving, and the traffic is insane. To keep lifeline of the system running a good old bodyguard Selenium-Playwright is on his constant watch.

This digital metropolis consists of:

citizens (aboutyou users)
storefronts (webshop pages)
store item barcode (element locator)
and much more

Mission of Mr. Selenium-Playwright is to make sure daily flow, and functionality of the metropolis is working seamlessly.

Just as bodyguard protects and prevents certain problems, Mr. Selenium-Playwright mimicks user interaction to ensure every part of the metropolis works as expected. He can blend in using different disguises(browser) to ensure his employer understands the experience of every citizen(user).

Wanna find out how does a normal day look like for bodyguard Mr. Selenium-Playwright?

Ok let's dive into it.

1. Patrolling metropolis

Every day, mimicking citizen behaviour he goes through every storefront, including store items all through the cash register, where he confirms he can purchase items without any issues. He executes all actions citizens would normally do.

Therefore, he regularly walks through the digital streets(executing automated tests) and ensures all storefronts(webshop pages) are working and makes sure citizens(users) can use them without experiencing any faulty(bugs) behaviour that may cause metropolis to close down or repel user from entering once again.

2. Catching and identifying

Each time he executes a list of scenarios citizen(user) would do, there is a result at the end of each scenario. Sometimes those scenarios result in finding bugs/issues. He gathers evidence, and gives exact location of faulty(bug) behaviour, and a screenshot.

3. Reporting

At the end of each run of citizen behaviour test, he gives a nice report. This report is delivered to his boss. In that report he displays how many scenarios he executed, how many of them passed and how many are with faulty behaviour.

For what is Mr. Selenium-Playwright useful?

In the narrative of "AboutYou Webshop" Selenium and Playwright automation tools stand as the guardian of the digital city, working tirelessly behind the scenes to ensure that every user action, application functionality, elements is as smooth as a well-oiled machine. Magic of how Selenium or Playwright can execute all of these tests lays in hands of your software tester aka QA Engineer. That individual will write code for each scenario and add that to a continuous integration job, where those tests will be run on a certain schedule

Facts about automated tests:

they run faster then any other manual testing
reports are delivered after each test run
repetitive regression testing is no longer boring
find out if new features blend in with existing ones perfectly or they break something
saves time which gives QA Engineer more time to focus on complex testing scenarios that may require human judgment
win on the long run (the more automated tests you have the bigger ROI)
more time for exploratory testing
more time for writing new automated tests
covers more combinations than any human can in given time
eliminates human error

How you find this article? Let me know in the comments.

Can IT company survive without QA?

Stipe — Mon, 12 Feb 2024 11:42:55 +0000

In always fast-developing technological world, the question whether an IT company can survive without having a Quality Assurance (QA) team or not seems to be actual as never before.

Being small private IT company or big, pace is always the same, speed in delivery is important. Competition is big, customers are nowadays having less patience. Every detail matters, from UX to quality of the product. If you want to succeed, having smooth user experience is the key. When you signup to the service, if experience at first minute is not good, your potential customer is gone to the competitor. Same goes for every feature you have inside. Everything matters. Some more than other, but ultimately quality is the key.

If you are super small company, a startup, you might want to cut expenses and live on the edge for a while. That is understandable. In such case when you get on your feet, and you decide that flying in a non-tested brand new airplane is still good idea, it is your legitimate right. That airplane can have malfunction and crash any second now, however with lots of good luck it may be success. Question is, do you want to invest your time/money into a company that is basing its success on luck?

In software delivery cycle, quality assurance is very important process to quality development, it is ensuring that product attains certain levels of quality before it lands in the hands of the user. One thing we all need to accept, is that we are humans and we all make mistakes. That is normal. Some make more, some make less. Without QA, companies release their products with bugs, security gaps, and risk having their reputation and financial base collapsed.

QA is not only about finding bugs but more about proving the product is reliable, user-friendly, and meeting the expectations of its users. Those are the goals. If the company wants to attain high level of quality, entire company needs to be more educated in quality assurance. Mindset is the key. Being safe is always better then being fastest.

Would you rather buy nicest looking fast car with highest speed and newest tech but you know it is not tested for safety, or would you drive competitors car who released slightly later but it passed all the safety and quality tests?
I presume decision would be on the latter

If you run a IT company, and you don't have a QA, you should consider adding testing into your delivery process.

There are different types of testing, and depending on what QA resources you have, QA team covers an all-round check of the product as far as its functionality, happy-path covering, negative-path covering, edge-case covering, usability, frontend manual and automated testing, api manual and
automated testing, etc.

All of this will depend on the developers to find and fix all the problems without any QA. That will only slow down the development pace and remove resources from innovative work.
Also mindset of a developer and QA is very different oriented.
In my experience, QA can find 10 bug where dev can not see 1 bug looking at his code.

In conclusion, theoretically, an IT company might manage without the QA team, but practically, without it, the quality of products would be more likely compromised, and satisfaction of the customers on the long run, its in great danger. There is no overstating the importance of quality assurance in the software development life cycle because it is an indispensable part of the cycle.

Idempotency explained in restaurant analogy

Stipe — Sat, 03 Feb 2024 21:32:21 +0000

In a bustling city of New York, there was a renowned restaurant named "Giovanni". This restaurant was unique for it's traditional meals from south of Italy, and they served meals in the same concept of idempotency in API development.

In the sphere of APIs, idempotency means that regardless of how many times one makes identical request, the outcome remains unchanged after the first request is made. This principle is ingeniously applied in the old Giovanni's restaurant.

Enter our protagonist, a chef named Marco, culinary virtuoso. Marco's kitchen was the heart of idempotency magic. Each dish was like a unique response to the API request made by the customer. Made with love, taste and never duplicated.

One summer evening, a couple on their first date arrived at "Giovanni" restaurant. Arthur and Brenda.

Arthur ordered a nice stake, while Brenda ordered a dish called "Palermo delight". Order went to kitchen with unique identifier "table #6 - order 130". Arthur was a rascal and always ready for some misdeeds. He called waiter and ordered same meals again, hoping to see if they would end up with two dishes instead of one.

Back in the kitchen chef Marco received again identical order with same unique identifier "table #6 - order 130".

Marco immediately recognized the duplicate. He informed entire team in the kitchen that this is idempotent request and they should prepare only one stake and one Palermo delight. In any other restaurant this would resulted with duplicate order, but not in Giovanni's.

Rascal Arthur and Brenda were served with one order, corresponding to their first order.

Let's break down the process from order to serving of the meal.

1. MEAL ORDER = POST REQUEST

Arthur and Brenda's first order of stake and Palermo delight equals to a POST request to an API.
When POST request is made, it sends data to the server, ordering to cook meals.

2. ORDER NUMBER = UNIQUE IDENTIFIER

Once Arthur and Brenda told what they want to eat, waiter assigned a table number and order number to it. Order was taken to the kitchen. This unique identifier is crucial.
It ensures that even if same order is placed 20 times, it will be recognized as duplicate.

This means, when api request is made, we assign it a unique identifier, ensuring server recognizes it and prevents duplications, server overload and poor user experience.

3. KITCHEN PROCESSING ORDER = SERVER PROCESSING THE REQUEST

Kitchen took the order with unique identifier, and places it into schedule of cooking. Arthur thought he is clever, but chef Marco's idempotent system is without flaw.

You can look at this as user making same api request again and again, perhaps due to network issue or serial clicking mania :-)
All of these requests will be recognized to who they belong, they will then be ignored, and only first request will be executed.

User is unaware of checks that occur behind the scenes, and he is served with what he requested in the first place. And that is most important.

How do you look at idempotency? Share your view.

APIs à la Carte: Understanding API Requests Through a Restaurant Analogy

Stipe — Mon, 04 Dec 2023 10:00:32 +0000

Understanding APIs:

Before we can even plan testing we need to know what are APIs and what they are used for. Simply said APIs allow different parts of the software system to communicate with each other.

Imagine software application is a restaurant. You enter a restaurant, sit by the table, waiter brings you the menu and you tell the waiter what meal you are ordering to eat. Waiter goes with this request to a restaurant chef and initiates order. Once a meal is ready, waiter brings it to you and order is completed. This is how software applications work. Let me explain you more in detail, but from a restaurant perspective.

Roles defined:
Restaurant role: Software application role

Restaurant: Entire software application
Restaurant Customer: Software application user
Kitchen: Server
Chef: Backend System
Waiter: API

There are several API requests that user can make in software application:

GET
POST
PUT
PATCH
DELETE

Short explanation about what each request does:

GET:
Retrieves data from a server. You don't change anything, you just request to view available data from a certain endpoint.
POST:
Send data to the server. With it, we are sending new information to the server. In so called _body_ we send all the data.
PUT:
This method is commonly used to update an entire resource. You are essentially saying to the system: "Hey here is the entire new version of this resource, make an update." Important to note is when making a PUT request we must provide entire resource data in the _body_

PATCH:
This method is also as PUT used for making updates, but this time we only provide those fields in the _body_ that we want to change. This makes PATCH more efficient than PUT.
DELETE:
As the name describes, it is used to request the server to remove the resource. Important to note is that this request is irreversible. Once a resource is deleted it cannot be recovered via HTTP protocol.

Explained GET request:

In restaurant world, a restaurant customer makes a GET request when he/she opens the menu and reads a list of meals, drinks and desserts. Another example would be, customer asking waiter: "Can I see the best red wine you have?" This is like a GET request. You are not ordering yet, you are just asking to see what's available. The waiter goes to kitchen (kitchen is like the server in software application) and brings you best red wine that they have, for you to see.

Another words, when you look at the menu or ask waiter about the menu, it is like making a GET request in software application. You are asking to see the information they have, without making an order or changing anything.

Explained POST request:

This will occur when restaurant customer decides on what he/she wants to eat/drink and places and order with the waiter.

Once you told to waiter what you want to order, for example Chicken quesadilla. In software terms, this is like when you fill out a form on the website and hit the submit button. In this moment you are sending a request(order) to the server.

Waiter(API) takes your order(request) to the kitchen(server) for meal preparation(processing).

Chef(Backend System) takes order and starts preparing the meal. Once meal is prepared, waiter(API) will bring it to your table. In software application, once the server has processed your POST request, it sends back the response to indicate that your request has been successfully processed.

Another words, when you order a meal, it's like making a POST request in software application. You are sending new information to the system, which get processed and after processing is completed you get the confirmation.

Explained PUT request:

Imagine you have ordered Chicken quesadilla but after 5mins you decide you want something else instead. So, you call the waiter over and tell him to replace the chicken quesadilla with calzone.

Waiter(API) takes your new order to kitchen(server). Kitchen(server) will understand difference between previous order and new one.

Chef(Backend system) prepares new order(calzone) from scratch, disregards the initial order of chicken quesadilla.
In software, a PUT request replaces existing data with the new data you provide.

Once the meal is prepared, waiter brings it to your table. In other terms, server has updated resource with new data provided, and the server has processed it successfully.

Explained PATCH request:

PUT and PATCH are very similar in it's nature. Key difference is that PATCH can make partial updates, while PUT is replacing entire resource with all data provided.

In so called body we send only those fields we are aiming to update. In our restaurant, a PATCH request is like when you want to make a small change to your order that you have already placed, without changing the entire order.

Let's say you have ordered calzone and after a while, you decide you want to add mushrooms in it. You call the waiter over and request just this one addition. This is like a PATCH request in a software application.

Waiter(API) takes order to kitchen(server), kitchen understands you are not changing entire order, just adding something to it. Chef(Backend system) then adds mushrooms to your calzone, without changing the rest of your order. Once order is processed successfully, waiter will bring it to your table.

Explained DELETE request:

This one is rather simple. A DELETE request is when you decide to cancel an order that you have already placed.

Imagine you have ordered calzone, but then you change your mind and decide that you don't want it anymore. You call the waiter over and him that you are cancelling your calzone order.

Waiter acting as API will go to the kitchen(server) and leave this request. Chef(Backend system) will pick it up and will remove this order. At the end, waiter will come to your table and confirm that your order has been successfully removed.

Conclusion:

In this restaurant analogy, each type of request customer makes represents a different way of interacting with the kitchen(server). Whether you are just looking at the menu, making an order, changing it completely, adding to it, or cancelling it altogether, each action has parallel in how software application communicates via API. Just as in a restaurant where your requests are handled with care to ensure satisfying experience, in software applications these requests are handled by APIs to ensure smooth and effective communication between different parts of the application, serving you with good experience.

Geeks: Silent Heroes of the Digital Age

Stipe — Mon, 23 Oct 2023 12:41:24 +0000

There are countless shy "heroes" in the rapidly changing field of technology who toil away behind the scenes to mould the world into what it is today. These people, who are frequently referred to as "geeks," represent a wide range of professions in IT, such as SDETs, QA engineers, software developers, DevOps and Ethical Hackers, who are all bound together by an unyielding passion for what they do. They have brought the globe into the digital era with their shared enthusiasm for innovation and advancement, and they keep pushing the limits every day.

It's remarkable to reflect on the transformation of the term "geek" over the years. Once considered an insult, it has now evolved into a badge of honor. These geeks are not merely individuals who tinker with computers in dark basements; they are the architects of the digital future. They are the ones responsible for developing the software and applications that have become an integral part of our daily lives.

In today's tech-driven society, we frequently find ourselves surrounded by an abundance of software and programmes that seem pointless and are made exclusively for financial gain. It's true that there are a gazillion tech business "sharks" in this huge ocean waiting to create and sell you an application that brings no value to your life. But assuming that every tech business worker is the same is a mistake. Most of these people are like gorgeous creatures swimming with the sharks; they are committed to adding value to society as a whole, not just to themselves.

The IT industry is a place of clever and dedicated minds, a collection of beautiful brains. These geeks aren't motivated merely by monetary gain; they want to innovate and enhance the world around them. Their work is a labour of love, and they approach each day with a hunger for knowledge and true pleasure in developing or testing code. They recognise that their efforts are critical to the advancement of human society. Of course, not every individual is this much in love with technology, some are in it because there is enough work, and money is good.

Think about this: without the contribution of tech enthusiasts aka geeks, we would still be using horses and donkeys for transportation. The notion of entire cities being powered by electricity would be unthinkable, as would the convenience of warm water and the global connectivity provided by the internet. If my grandfather for one minute is able to see me today working from home with people from entire world, chatting, having video meetings with someone from another continent, laughing as they are right beside me I believe he would not be able to comprehend how far we have developed in just last 20 years. Modern comfort that we often take for granted is the result of the relentless pursuit of knowledge and the unrelenting passion of tech enthusiasts.

The tech industry is not just a source of employment; it is a force of advancement. When you combine moral values, intelligence, and a passion to create something new or better, you get genuine progress. Geeks are not only skilled professionals but also innovators, who's aim is to enrich society, and they enjoy in the creation process.

In conclusion, the world is indebted to the geeks who stay behind the computers, faces that you never saw, tirelessly contributing to create new better things and make our everyday lives better through technology. They are the unsung heroes, the silent workers of the digital realm, and they have played a pivotal role in forming the world over the last 40 years. As we enjoy the comforts of modern life, let us not forget the beautiful brains who have made it all possible, one line of code at a time.