Might the creative application of Plants and Lands as a means of exchange present a fresh and potent strategy for alleviating the repercussions of Global warming?

 

Photo by Sawyer Bengtson on Unsplash

Last week, as I looked out from my office in Bangalore, I saw a city that had changed a lot over the years. It used to have more greenery and a beautiful appearance, quite different from how it looks now with all the tall buildings and concrete.

Thinking about this, I started wondering about the effects of the city growing so much in terms of real estate. This growth was meant to make the economy better and help the city progress, but it ended up making the natural beauty disappear.

Still, it's important to recognize that development is necessary to create jobs and make the economy strong. It keeps things moving forward, especially in competitions like GDP and GMV. But how can we find a solution to this problem? How can we bring nature back?

These thoughts kept coming to my mind, and they led me to think of a different way to solve this issue: changing the way we think about trading things. In the past, people used to exchange things like Gold, forests, and land as currency. I started thinking about how this could help.

What if we saw wealth not just as money but also as the land we own? Or the number of trees we take care of? What if precious metals were seen as something very valuable? This new way of thinking might help us bring back the environment and stop using nature so much just for development. Of course, this idea might have problems in practice, but I believe we can find ways to solve them.

This idea reminds me of the 1980s when people used to take pride in having a lot of land or many trees. Even marriages were sometimes based on how much property the groom and their family had.

Basically, if we change how we think about wealth, it could make us treat the environment better. It makes me wonder: Could this different way of thinking help us have a future where development and nature work together? I'd love to hear your thoughts on this idea.

Acquired Wisdom from Agile Methodologies

 

Photo by Daria Nepriakhina 🇺🇦 on Unsplash

For more than ten years, I’ve been using one of the many methodologies of Agile, called the Sprint model, to develop software. 

Over time, it has become easier for me to manage after managing many rounds of these Sprints. However, the journey wasn’t always smooth.

I still remember the day when we initially considered using this approach. 

Back then, terms like “sprint,” “backlog,” “daily scrum,” and “scrum of scrum” seemed peculiar and unfamiliar, as if they hailed from another realm. Picture attempting to shift from a customary method of working, akin to following a detailed plan (as in a Waterfall model) with four primary steps (generating the concept, designing, coding, and testing), each demanding a significant chunk of time. However, in this novel Sprint approach, the pace is considerably swifter.

It requires a considerable amount of self-discipline and effort to facilitate effective collaboration among various teams in a scrum, all working harmoniously toward a specific component of a larger objective.

 At times, challenges arise in ensuring timely preparedness for development tasks, including obtaining requirements promptly, acquiring the necessary designs/mock-ups and models for web pages, as well as ensuring that the QA team possesses the essential resources. 

Furthermore, promptly addressing issues is essential — this includes fixing problems swiftly and efficiently, encompassing a diverse array of potential concerns.

Here are the key lessons I’ve learned:

• Sticking to the plan and maintaining discipline is of utmost importance
• Each member of the scrum team should dedicate at least 5 minutes before beginning the day to update the accurate status of their assigned tasks
• The individual overseeing the process (known as the Scrum master) should assist in resolving any issues that arise among the teams
• The daily meeting, where we discuss our current work, is crucial as it aids in planning the day and identifying significant challenges
• Planning ahead for sprints is essential to provide the development team with sufficient time to prepare for the next cycle
• Swiftly addressing problems and being prepared for unforeseen issues is vital
• The Scrum master should collaborate closely with the team responsible for determining the software’s purpose (the product team) to gain a comprehensive understanding of early requirements. This collaboration helps prevent conflicts between teams
• Implementing automation, such as using tools like Slack bot, can reduce the time needed for daily standup meetings, streamlining the process
• Use Jira Automation: Link
• In an ideal scenario, the product and design phases should be at least one sprint ahead in terms of requirements, mock-ups, and so on. However, this rarely occurs in the real world :)
• Conducting a mid-sprint review to recalibrate for tasks that overflowed
• Structured retrospective meetings yielding actionable tasks aimed at enhancing processes
• Instead of designing for the future, focus on the current use case and then expand it for future scenarios
• Each task should have a corresponding Jira ticket for tracking purposes

As a Scrum Master, your responsibilities include:

• Vigilantly track individual and team velocity
• Routinely assess Burn-down/up charts, Velocity Charts, and Release/Epic Burn-down reports
• Strictly adhere to the escalation matrix
• Ensure active participation from all departments in the retrospective meeting
• Oversee a comprehensive range of delay metrics, extending beyond Engineering
• Acknowledge that delays may arise in various stages, yet Engineering often faces undue pressure and blame
• Assume leadership to steer the ship; avoid being at the receiving end
• Implement a well-structured release calendar
• Manage the team’s leave calendar

Key dates to monitor:

• Individual ticket’s Dev to QA release date
• QA sign-off date for each ticket
• User Acceptance Testing (UAT) and demo date
• Release notes sign-off date
• Production release date

As I explained above, good planning is really important in this Sprint approach. Among all the planning we do, like estimating how long a sprint will take, deciding what to do first, planning when to test, and getting ready to release the software, one of the most important parts is planning when to test (Dev to QA release planning).

In this kind of planning, the team in charge of creating the software decides when each part of the software will be tested. It’s important to keep the promises we make about when things will be ready and to spread out the testing times. If we put too many things to test all at once, the team testing might get overwhelmed and the chance of something going wrong becomes bigger.

By spreading out the testing times and making sure things are tested at regular times, the first round of testing for each part of the software can be done quickly in the next week, especially if we release new versions every two weeks. But this isn’t always easy. Sometimes unexpected things happen, like really important problems that need fixing, things we didn’t plan for, or even technical issues. This is when someone experienced in the Sprint approach (the Scrum master) can help a lot.

A skilled Scrum master knows how to handle these unexpected challenges. They might give a task to a different team member who has time, or they might ask for help from the whole team, or they might talk to the people in charge to find a way to solve the problem. Their role becomes very important in guiding the team through these tough times.

So, when we talk about planning in the Sprint approach, it’s not just about setting dates. It’s also about being flexible, taking action when things go wrong, and making sure everyone works well together to keep the promises we’ve made, even when things get complicated.

A Tribute to Writers of Unorganized Test Code

Photo by Scott Graham on Unsplash

When you inquire with a Developer about how thoroughly they’ve tested their code, you might receive a series of explanations for why they haven’t written many Unit Tests. Sometimes they’ll mention challenges in creating the tests, or they might debate whether the benefits are worth the work required.

The issue here is that the code for Unit Tests, Functional Tests, and Regression Tests isn’t given as much importance. Usually, the time and work needed for these tests aren’t taken into account when planning the development work for a sprint.

As the code becomes bigger over time and when we add new features, they can sometimes cause existing things to stop working correctly. But usually, people don’t consider spending time to write tests for these changes.

Sometimes, even if we write test code just to meet the requirements, it might not follow the good coding rules (like SOLID principles). I’ve noticed that test code is often untidy, and I’ve told the developers responsible to clean it up. However, there’s a common belief that since the messy code only runs tests, not the real system, it’s okay for it to be messy.

For those who write messy tests, there’s a rule called “FIRST” that should be kept in mind when creating test code:

• Fast
• Isolated/Independent
• Repeatable
• Self-validating
• Timely

---

Fast: Make sure your tests complete quickly. I’ve observed situations where test suites take hours to finish, which can sometimes become quite frustrating.

Here’s a simple example where you’re testing a function that adds two numbers:

@Test
public void testAddition() {
 int result = Calculator.add(3, 5);
 assertEquals(8, result);
}

---

Isolated/Independent: Ensure that every test is self-contained and doesn’t depend on or influence the results of other tests. This approach allows you to run different tests separately and autonomously.

Here’s an example testing a class that simulates a stack:

@Test
public void testPush() {
    Stack stack = new Stack();
    stack.push(42);
    assertEquals(1, stack.size());
}

@Test
public void testPop() {
    Stack stack = new Stack();
    stack.push(42);
    int poppedValue = stack.pop();
    assertEquals(42, poppedValue);
    assertEquals(0, stack.size());
}

---

Repeatable: Make certain that tests always generate consistent outcomes, meaning they yield the same results whether run once or a hundred times. The output should remain unchanged.

Here’s an example testing a sorting method:

@Test
public void testSort() {
    int[] unsorted = {3, 1, 4, 1, 5};
    int[] sorted = {1, 1, 3, 4, 5};
    
    Arrays.sort(unsorted);
    
    assertArrayEquals(sorted, unsorted);
}

---

Self-validating: Tests should possess distinct criteria for passing or failing. This entails including both positive and negative scenarios within the test code.

Here’s an example testing a method to check if a number is prime:

@Test
public void testIsPrime() {
    assertTrue(MathUtil.isPrime(17));
    assertFalse(MathUtil.isPrime(6));
}

---

Timely: Start writing tests early in the process of developing your code. This principle is incredibly important. Before you even start writing your actual code, take time to consider the test cases and begin crafting test code as soon as you can. Delaying writing test code often means you’ll never find the time to do it later.

Here’s an example testing a method that calculates the Fibonacci sequence:

@Test
public void testFibonacci() {
    assertEquals(0, MathUtil.fibonacci(0));
    assertEquals(1, MathUtil.fibonacci(1));
    assertEquals(55, MathUtil.fibonacci(10));
}

Happy coding :)

Innovating Financial Inclusion: The e-RUPI Initiative in India

 

---

e-RUPI is a targeted electronic voucher created to ensure that the designated funds are delivered to the intended recipient and can solely be utilized for the precise purpose it was intended for. It operates as a cashless system, making it person and purpose-specific.

The objective is to establish an efficient and secure delivery system with minimal logistics for various government Direct Benefit Transfer (DBT) programs nationwide. The digital e-voucher platform can also serve organizations seeking to contribute to welfare services by using e-RUPI instead of cash, ensuring a leak-proof and accountable process.

---

What sets apart the normal rupee used in cash transactions from digital transactions?

The primary distinction lies in the utilization of e-RUPI by a designated individual for a particular purpose, ensuring the funds are directed solely for that specific use.

For instance, if a farmer is provided with an e-RUPI voucher to purchase fertilizer for their crops, the voucher’s usage is restricted solely to acquiring fertilizer, and it cannot be utilized for any other purpose.

The implementation of e-RUPI enhances security against potential misuse by middlemen in DBT. Nevertheless, there remains a possibility of middlemen resorting to covert arrangements to illicitly benefit from the system.

---

Below are the entities engaged in the creation and redemption of e-RUPI vouchers:

Issuer Bank/Payer PSP: The issuing bank or payment service provider (PSP) is responsible for initiating the request to create an e-RUPI voucher with NPCI.

Sponsor: The sponsor refers to a corporate entity, a State or Union Government department, or a business customer of the bank who requests the bank for the creation of an e-RUPI voucher.

e-RUPI beneficiary: The person who receives the e-RUPI voucher is known as the e-RUPI beneficiary. It's important to note that an e-RUPI beneficiary may not have a UPI (Unified Payments Interface) account or be a bank account holder.

Designated Merchant: Designated merchant are specific voucher acceptance points where e-RUPI voucher can be redeemed/used.

Acquiring Bank/Payee PSP: Acquiring bank/Payee PSP shall be providing facility/capability to designated merchants to accept the e-RUPI voucher for redemption.

NPCI: NPCI is the owner, network operator, service provider, and coordinator of the UPI Network.

---

e-RUPI Work Flow:

---

You can go through: https://www.npci.org.in/what-we-do/e-rupi/product-overview

An overview of the Open Network for Digital Commerce (ONDC) from a bird's-eye perspective

In this article, we're delving into the government's recent initiative to democratize digital ecommerce – the Open Network for Digital Commerce (ONDC). Traditional ecommerce involves four main entities: Buyers, Sellers/Merchants, E-commerce Platforms (e.g., Bigbasket, Swiggy, Amazon), and Payment Service Providers. The typical flow of an ecommerce transaction follows this structure:

In this setup, buyers are freed from the need to know about sellers' identities or product delivery specifics. This is all managed by the e-commerce platform. However, there's a challenge when it comes to product discovery for smaller merchants. Wealthier merchants can make their products more visible by establishing special agreements with the platform. This results in fewer transactions and revenue for smaller players. Additionally, buyers might have limited options since not all merchants offering a product might be on the platform they're using.

This approach brings three problems:

1. Limited Visibility for Smaller Merchants: Smaller players struggle to get noticed among bigger ones dominating the platform.
2. Fewer Options for Buyers: Buyers have limited product choices as not all merchants are available on their chosen platform.
3. Monopoly of E-commerce Players: A single dominant player can lead to issues like unfair competition and limited consumer choice.

So, how does ONDC address this? ONDC offers solutions like:

1. Enhanced Visibility for Smaller Merchants: ONDC maintains a central repository of merchants and their catalog information, ensuring their discoverability.
2. Expanded Choices for Buyers: ONDC's search API provides access to a global catalog, allowing buyers to find similar items across multiple catalogs.
3. Decentralized Collaboration: ONDC promotes a decentralized ecosystem where various stakeholders collaborate to create an inclusive and competitive marketplace. This prevents excessive power concentration in one player's hands and encourages diversity and innovation.

Key Entities within ONDC:

• Buyer: The individual/entity making purchases through the platform.
• Buyer Applications: Apps enabling buyers to search product catalogs.
• Seller Applications: Apps for sellers to manage orders, logistics, etc.
• Sellers: Merchants using the platform to sell products.
• ONDC Ecosystem: Includes gateway and centralized services. The gateway authenticates participants like Business Process Partners (BPPs) and Buyer Application Partners (BAPs).

ONDC API Architecture:

ONDC's API structure follows an asynchronous model where each action triggers a callback. The requester initiates a request, and the target entity sends back a callback. Some key actions and their corresponding APIs include:

1. Search: Find products in the catalog.
2. Select: Choose products for purchase.
3. Initialize: Start an order.
4. Confirm: Confirm and finalize an order.
5. Status: Check order status.
6. Track: Track order progress.
7. Cancel: Cancel an order.

For more detailed API information, visit the ONDC API Documentation.

Feel free to share your thoughts and questions on this exciting initiative!

Unified Payment Interface(UPI) Architecture

---

Unified Payment Interface(UPI) Architecture

In the digital age, where convenience and speed are very very important, the Unified Payments Interface (UPI) has emerged as a game-changer in the realm of financial transactions in India. UPI, introduced by the National Payments Corporation of India (NPCI), has revolutionized the way people send and receive money, making it as simple as a few taps on their smartphones. With its seamless integration across multiple banking platforms and widespread adoption by various payment apps, UPI has become the go-to solution for instant, secure, and cashless transactions.

In this tech blog, we will delve into the world of UPI and explore its inner workings, advantages, and the impact it has had on the Indian digital payments landscape. Whether you are a tech enthusiast, a curious user, or a business owner looking to embrace UPI for your enterprise, this comprehensive guide will provide you with the insights you need to navigate the exciting world of UPI.

Transactions stats for Year 2023:

Transactions in Million

If you compare month on month between May 2022 vs 2023 — (9415–5955/5955) * 100 ~ 59% increase, this is really huge.

9415*1000k/24*60*60*30 ~ 4k transactions/s, this is very high QPS. How does UPI system is able to handle such load?

First let’s start with the basic flow diagram of any UPI transaction and later we will deep dive into the detailed architecture of it.

---

UPI high level transaction flow

---

Here are the entities involved in above transaction:

1. User :Initiates a transaction for another UPI ID after login to his/her PSP app account.
2. PSP — Payer: Validate the user(with the help of NPCI) and forwards request to NPCI for the further processing of the transaction.
3. NPCI UPI ecosystem: Forwards the request to PSP(Payee) for further address resolution and processing.
4. PSP — Payee: Uses NPCI APIs to find out the account details/address of the Payer’s bank/Remitter Bank.
5. Remitter Bank: Validate and confirms the account deduction request raised by the Beneficiary Bank. Sends the confirmation back to NPCI.
6. Beneficiary Bank: Validate and confirms the account credit request raised by the Remitter Bank. Sends the confirmation back to NPCI.

Finally NPCI notifies about the successful or failed transaction request back to all involved PSP. This notification may be push/pull type based on the configuration.

References:

How Does UPI Work? - GeeksforGeeks
A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and…www.geeksforgeeks.org

Monthly Metrics
UPI Daily Product Statistics Trended Aug 2021 No data available for the selected filters UPI Monthy Product Statistics…www.npci.org.in

Statistics of NPCI - National Payments Corporation of India
Know more about the Statistics of NPCI - National Payments Corporation of India.www.npci.org.in

UPI: Unified Payments Interface - Instant Mobile Payments | NPCI
UPI - Unified Payments Interface is an instant real-time payment system developed by NPCI to facilitate inter-bank…www.npci.org.in

https://www.youtube.com/watch?v=QpLy0_c_RXk