DEV Community: Collins Kiplimo

Java Stack: Unveiling LIFO Magic

Collins Kiplimo — Tue, 15 Aug 2023 09:28:07 +0000

A stack is a linear data structure that follows the principle of Last In First Out (LIFO). This means the last element inserted inside the stack is removed first.

Concepts and Principles:
Visualize a stack as a vertical arrangement of elements, where you can:

Push:
Add an element to the top of the stack.
Pop:
Remove an element from the top of the stack.
IsEmpty:
Check if the stack is empty.
IsFull:
Check if the stack is full.
Peek:
View the value of the top element without removal.

Working of the Stack:
In Java programming, we use a pointer called top to keep track of the top element. Upon initialization, top is set to -1 to indicate an empty stack. When an element is pushed, top is incremented, and for popping, it is decremented. These operations are carried out with checks to avoid overflow or underflow.

Stack Implementation in Java:
Below is a practical implementation of a stack in Java:


public class Stack {
    private int maxSize;
    private int[] stackArray;
    private int top;

    public Stack(int size) {
        maxSize = size;
        stackArray = new int[maxSize];
        top = -1;
    }

    public boolean isEmpty() {
        return top == -1;
    }

    public boolean isFull() {
        return top == maxSize - 1;
    }

    public void push(int value) {
        if (!isFull()) {
            stackArray[++top] = value;
            System.out.println("Pushed item: " + value);
        } else {
            System.out.println("Stack is full. Cannot push.");
        }
    }

    public int pop() {
        if (!isEmpty()) {
            return stackArray[top--];
        } else {
            System.out.println("Stack is empty. Cannot pop.");
            return -1; 
        }
    }

    public int peek() {
        if (!isEmpty()) {
            return stackArray[top];
        } else {
            System.out.println("Stack is empty. Cannot peek.");
            return -1; 
        }
    }
}

Time Complexity:
Stack operations using arrays have a constant time complexity (O(1)) for both push and pop, making them efficient and suitable for various applications.

Applications:
Stacks prove their versatility across various domains:

Expression Evaluation:
Stacks assist compilers in evaluating expressions by converting them into postfix notation for efficient processing.
Function Calls:
Method calls and recursion in programming languages often utilize stacks to manage execution contexts.
Browser History:
Browsers utilize stacks to facilitate backward navigation through visited URLs.

Optimizing API Performance: Exploring Effective Rate Limiting Algorithms

Collins Kiplimo — Wed, 28 Jun 2023 14:28:01 +0000

Introduction:
In the realm of API rate limiting, choosing the right algorithm is crucial for maintaining system stability, preventing abuse, and ensuring fair resource distribution. This article delves into several popular rate limiting algorithms and highlights their advantages and disadvantages. By understanding these algorithms, developers can make informed decisions to implement effective rate limiting strategies.

Leaky Bucket: Managing Requests with a Queue

The Leaky Bucket algorithm offers a straightforward and intuitive approach to rate limiting. By utilizing a queue, incoming requests are appended to the end of the queue and processed at a regular interval or through first-in, first-out (FIFO) processing. This algorithm provides control over the request rate by discarding or "leaking" additional requests when the queue is full. We explore the simplicity and limitations of the Leaky Bucket algorithm.

Token Bucket: Controlling Access with Tokens

The Token Bucket algorithm employs the concept of a bucket filled with tokens. Each incoming request requires the consumption of a token from the bucket to proceed. If no tokens are available, the request is refused, and the requester must retry later. This algorithm allows for the refreshing of tokens over a defined time period, ensuring fair distribution of resources. We examine the Token Bucket algorithm's token-based approach and its effectiveness in rate limiting scenarios.

Fixed Window: Rate Limiting within Fixed Time Windows

The Fixed Window algorithm tracks request rates within fixed time windows. By using a window size of n seconds, each incoming request increments a counter for the respective window. If the counter exceeds a predefined threshold, the request is discarded. We explore the simplicity and limitations of the Fixed Window algorithm and its ability to handle bursty traffic.

Sliding Log: Dynamic Rate Limiting with Time-stamped Logs

The Sliding Log algorithm employs time-stamped logs to track and enforce rate limits. These logs are stored in a time-sorted hash set or table, with older logs discarded beyond a threshold. When a new request arrives, the algorithm calculates the sum of logs within a specified time range to determine the request rate. If the request exceeds the threshold rate, it is held. We delve into the flexibility and considerations of the Sliding Log algorithm.

Sliding Window: Balancing Performance and Precision

The Sliding Window algorithm combines elements of both the Fixed Window and Sliding Log algorithms to achieve a balance between processing cost and precise rate limiting. Similar to the Fixed Window algorithm, it tracks a counter for each fixed window. Additionally, it accounts for the weighted value of the previous window's request rate based on the current timestamp, enabling a smoother handling of traffic bursts. We analyze the advantages and trade-offs of the Sliding Window algorithm.

Exploring Commonly Used Routing Algorithms for Efficient Network Traffic Distribution

Collins Kiplimo — Wed, 28 Jun 2023 13:21:59 +0000

Introduction:
Routing algorithms play a crucial role in efficiently distributing network traffic across various servers in a system. By intelligently selecting the most appropriate server for each request, these algorithms help optimize performance, improve resource utilization, and ensure a seamless user experience. In this article, we will explore several commonly used routing algorithms and delve into their key characteristics and applications.

Round-robin Routing Algorithm:

The round-robin algorithm is a simple and widely adopted approach for load balancing. In this method, requests are distributed to application servers in a sequential manner, following a rotating pattern. Each subsequent request is directed to the next server in the sequence, ensuring an equal distribution of traffic among all available servers. Round-robin routing works well when the servers have similar capabilities and workload requirements.

Weighted Round-robin Routing Algorithm:

Building upon the basic round-robin technique, the weighted round-robin algorithm introduces the concept of assigning weights to servers. These weights reflect the varying compute and traffic handling capacities of different servers. By adjusting the weights, administrators can influence the distribution of traffic, ensuring that more capable servers handle a higher proportion of requests. This algorithm is often implemented through DNS records, allowing for dynamic adjustments as server capacities change.

Least Connections Routing Algorithm:

The least connections algorithm takes into account the current number of active connections on each server when making routing decisions. When a new request arrives, it is directed to the server with the fewest active connections at that moment. By considering the relative computing capacities of servers, this algorithm aims to evenly distribute traffic and prevent any single server from becoming overloaded.

Least Response Time Routing Algorithm:

The least response time algorithm focuses on selecting the server with the fastest response time and the fewest active connections. This approach combines two crucial factors to ensure optimal performance and minimal latency. By considering response times and connection loads simultaneously, the algorithm intelligently routes requests to the most efficient server at any given moment.

Least Bandwidth Routing Algorithm:

In scenarios where network bandwidth is a critical factor, the least bandwidth routing algorithm becomes relevant. This method evaluates the traffic load in terms of megabits per second (Mbps) on each server. The request is then directed to the server with the least amount of traffic, aiming to balance the bandwidth utilization across the server pool. This algorithm is particularly useful in environments where data-intensive applications or media streaming services are involved.

Hashing Routing Algorithm:

The hashing algorithm utilizes a predefined key, such as the client's IP address or the request URL, to distribute requests across servers. By applying a hashing function to the key, a consistent mapping is established between the key and a specific server. This approach ensures that requests with the same key are always directed to the same server, which can be advantageous in scenarios where session persistence or caching strategies are essential.

Decoding Run Levels in Linux

Collins Kiplimo — Wed, 17 May 2023 13:19:54 +0000

Introduction:
In the realm of Linux, run levels serve as vital tools for managing the operating system's behavior during startup and daily operations. They dictate which services and processes are active at different stages of the boot process. This beginner's guide aims to demystify run levels in Linux, unraveling their significance and practical usage.

What are Run Levels?
Run levels in Linux represent distinct operating states of the system. Each run level encompasses a specific configuration of services and processes that should be active at a given time. By controlling the run level, you can manage how your system behaves during startup and regular usage.

Understanding Common Run Levels:
In Linux, run levels are typically denoted by numbers ranging from 0 to 6, each indicating a specific state. Here's an overview of the commonly used run levels:

Run Level 0 (Halt): This run level completely shuts down the system, powering off the machine.
Run Level 1 (Single User): In this minimal state, only one user has access, providing a basic command-line interface for essential system maintenance tasks.
Run Level 2 (Multi-User without Networking): Similar to run level 3 but without network services enabled.
Run Level 3 (Multi-User with Networking): This run level allows multi-user mode with full network capabilities, facilitating simultaneous login for multiple users.
Run Level 5 (Graphical User Interface): Activating this run level brings forth a visually appealing graphical desktop environment, offering an interactive interface for users to engage with the system.
Run Level 6 (Reboot): This run level restarts the system, shutting down all processes and initiating a system reboot.
Changing Run Levels:
To switch between run levels on a Linux system, you can leverage commands like init or systemctl depending on your Linux distribution. For instance, to transition to run level 3 (multi-user with networking), employ the command sudo init 3 or sudo systemctl isolate multi-user.target.

Configuration Files:
Each run level's behavior is influenced by configuration files housed in specific directories. On older Linux systems, run level configurations are defined in the /etc/inittab file. On modern Linux distributions employing systemd, run levels are managed via systemd targets and unit files located in /etc/systemd/system/.

Customizing Run Levels:
System administrators possess the liberty to customize run levels to suit specific requirements. By modifying the run level configuration files, you can enable/disable specific services or even define new run levels featuring custom configurations.

Run Levels vs. systemd Targets:
Recent Linux distributions have transitioned to systemd as the default initialization system. systemd replaces traditional run levels with the concept of targets, which provide more fine-grained control over the system's behavior. However, understanding run levels remains crucial for service management and troubleshooting system issues.

How to Create a Docker MySQL Container and Link it with a Spring Boot Application

Collins Kiplimo — Thu, 23 Mar 2023 10:23:37 +0000

Step 1: Create a Docker Network

Create a Docker network to allow the containers to communicate with each other. You can create a network using the following command:

docker network create --subnet=172.18.0.0/16 mynetwork

This command creates a Docker network named "mynetwork" with a subnet of 172.18.0.0/16.

Step 2: Create a MySQL Container

Create a MySQL container using the following command:

docker run -d --name mysql-db --ip 172.18.0.2 --network mynetwork -e MYSQL_ROOT_PASSWORD=root mysql:latest

This command creates a MySQL container named "mysql-db" with an IP address of 172.18.0.2 and attaches it to the "mynetwork" network. It also sets the root password for the MySQL server.

Step 3: Create a Spring Boot Application

Create a Spring Boot application using your preferred IDE or text editor. You can use the Spring Initializr to generate a new Spring Boot project with the necessary dependencies.

Step 4: Configure Spring Boot Application

In your Spring Boot application, add the following configuration to your application.properties file:

spring.datasource.url=jdbc:mysql://mysql-db:3306/testdb
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

The above configuration sets the database URL, username, password, and driver class name for the MySQL server.

Step 5: Build and Run the Spring Boot Application

Build your Spring Boot application using Maven or Gradle. Then, run the application using the following command:


docker run -p 8080:8080 --name spring-app --network mynetwork <image-name>

This command runs your Spring Boot application in a Docker container named "spring-app" and maps port 8080 of the container to port 8080 of the host machine.

Note that you will need to replace with the name of the Docker image you built for your Spring Boot application.


Step 6: Test the Application

Open your web browser and navigate to http://localhost:8080. If everything is configured correctly, you should see your Spring Boot application running and connected to the MySQL container.

Harnessing the Power of QueryDSL for Data Filtering in Spring Boot

Collins Kiplimo — Thu, 23 Mar 2023 08:34:06 +0000

Introduction

QueryDSL is a framework that provides a type-safe way of writing queries for various data stores, including databases and search engines. Spring Boot is a popular framework for building web applications that integrates well with QueryDSL. In this article, we'll explore how to use QueryDSL with Spring Boot, including how to set up the necessary dependencies and plugins.

Setting up the Project

To get started, we'll need to create a new Spring Boot project and add the necessary dependencies and plugins. We'll use Maven for this, but you could also use Gradle if you prefer.
Next, open the pom.xml file and add the following dependencies:

        <dependency>
        <dependency>
            <groupId>com.querydsl</groupId>
            <artifactId>querydsl-apt</artifactId>
        </dependency>
        <dependency>
            <groupId>com.querydsl</groupId>
            <artifactId>querydsl-jpa</artifactId>
        </dependency>
        </dependency>

Next, we need to add the QueryDSL Maven plugin to our pom.xml file. This plugin generates Q classes for our JPA entities, which we can then use to write type-safe queries with QueryDSL. Add the following plugin configuration to the build section of your pom.xml:

           <plugin>
                <groupId>com.mysema.maven</groupId>
                <artifactId>apt-maven-plugin</artifactId>
                <version>1.1.3</version>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>process</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>target/generated-sources/java</outputDirectory>
                            <processor>com.querydsl.apt.jpa.JPAAnnotationProcessor</processor>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

This plugin configuration tells Maven to generate Q classes for our JPA entities using the JPAAnnotationProcessor. The generated classes will be placed in the target/generated-sources/java directory.

Writing a Query with QueryDSL

Suppose we have a Spring Boot application that manages deliveries for a group of farmers. We want to write a query that filters deliveries based on various criteria such as transaction type, date range, farmer name, and cooperative ID.

Here is an example of a method that uses QueryDSL to filter deliveries:

public ListResponse filterDeliveries(TransactionType transactionType, LocalDate start, LocalDate end, String name,Long cooperativeId,int page,int perPage) {
    page = page - 1;
    Sort sort = Sort.by(Sort.Direction.ASC, "createdAt");
    Pageable pageable = PageRequest.of(page, perPage, sort);
    Page<DeliveryDto> deliveryPage=null;

    if (transactionType != null && name !=null && start != null && end != null ) {
        QAccountTransaction qAccountTransaction = QAccountTransaction.accountTransaction;
        deliveryPage=transactionRepository.findBy(qAccountTransaction.transactionType.eq(transactionType).
                and(qAccountTransaction.farmer.name.containsIgnoreCase(name)).
                and(qAccountTransaction.createdAt.between(start.atStartOfDay(),
                        LocalTime.MAX.atDate(end))), q -> q.sortBy(sort).as(DeliveryDto.class).page(pageable));

        log.info("This is a list of  deliveries found {}", deliveryPage.getContent());
        return new ListResponse(deliveryPage.getContent(), deliveryPage.getTotalPages(), deliveryPage.getNumberOfElements(),
                deliveryPage.getTotalElements());
    }

}

In this example, we first create a Pageable object to define the pagination and sorting parameters for our query. We then use the QAccountTransaction class, which is a QueryDSL-generated class based on our entity AccountTransaction, to define our query criteria. We can chain multiple conditions using the and operator. We then use the transactionRepository to execute the query and return the results as a Page object.

QueryDSL provides a type-safe, fluent API for building complex queries with ease. With QueryDSL, we can easily build dynamic queries that can be used with any database