DEV Community: meenachan

Code Quest: Taming the Request Beast with Spliterator Magic! 🧙‍♂️✨

meenachan — Sun, 22 Sep 2024 16:31:43 +0000

In the realm of development, every day can feel like an epic adventure. One fateful Tuesday, I found myself facing a formidable beast: a tidal wave of urgent user requests threatening to overwhelm my code. With deadlines looming and the clock ticking, I needed a hero’s strategy to conquer this chaos.

As the number of user requests surged, I realized that my initial approach—a simple filtering loop—was insufficient for managing the diverse types of requests pouring in. Urgent requests mixed with complex and incomplete ones created a tangled mess that slowed down processing and left users impatiently waiting. I needed a solution that could efficiently handle this variety while ensuring that urgent requests were prioritised.

What began as a simple filtering task quickly morphed into a high-stakes race against time, pushing my coding skills to their limits.

The Initial Struggle

I started simply, filtering requests with a basic loop:

List<Person> urgentRequests = new ArrayList<>();
for (Person person : people) {
    if (person.isUrgent()) {
        urgentRequests.add(person);
    }
}

This worked well for a manageable list, but as the requests soared from hundreds to thousands, my code crawled, leaving users impatiently waiting.

The Parallel Stream Hail Mary

Desperate for speed, I turned to parallel streams, hoping to unleash some serious processing power:

List<Person> urgentRequests = people.parallelStream()
    .filter(Person::isUrgent)
    .collect(Collectors.toList());

While I felt like a coding hero, soon I realized that the varying request types—simple, complex, incomplete, and nested—overwhelmed my newfound speed. The chaos continued, and users were still in limbo.

The Spliterator Revelation 💡

In a moment of clarity, I discovered Spliterator.

What is Spliterator?

A Spliterator (short for "splittable iterator") is a Java interface introduced in Java 8 that allows you to traverse and partition elements of a data structure. Unlike a standard iterator, which processes elements sequentially, a Spliterator can divide a collection into smaller parts, enabling parallel processing. This is particularly useful for collections that have diverse or nested structures.

Key Characteristics of Spliterator

Splitting: It can break down a data structure into smaller chunks, which can then be processed concurrently.
Characteristics: It provides information about the data, such as whether it is SIZED, SUBSIZED, ORDERED, or CONCURRENT.
Efficiency: It allows for efficient traversal and can adapt to various data types and structures.

Key Methods of Spliterator

tryAdvance(Consumer<? super T> action): Performs the given action on the next element if one exists, returning true if an element was processed.
trySplit(): Attempts to split the spliterator into two parts, returning a new spliterator for the first part and leaving the second part for the original.
estimateSize(): Returns an estimate of the number of elements that remain to be processed.
characteristics(): Returns a set of characteristics for this spliterator.

When to Use Spliterator

Complex Data Structures: When working with collections that have diverse or nested structures, Spliterator can handle each element more intelligently.
Custom Processing Logic: If you need specific handling for different types of elements, Spliterator allows for that flexibility.
Parallel Processing Needs: When you want fine control over how elements are processed in parallel, Spliterator shines.

The New Adventure: Spliterator Code 🛠️

I revamped my code to use Spliterator, ready to tackle each request type head-on:

List<Person> urgentRequests = new ArrayList<>();
List<Person> incompleteRequests = new ArrayList<>();

Spliterator<Person> spliterator = people.spliterator();
spliterator.forEachRemaining(person -> processRequest(person, urgentRequests, incompleteRequests));

In this code, I created two lists: one for urgent requests and another for incomplete ones. The spliterator.forEachRemaining() method processes each Person, applying tailored logic to each request.

Processing Different Requests

I defined the processRequest method to handle the various types:

private static void processRequest(Person person, List<Person> urgentRequests, List<Person> incompleteRequests) {
    if (person.isUrgent()) {
        if (person.isSimpleRequest()) {
            urgentRequests.add(person); // Quick and easy
        } else if (person.isComplexRequest()) {
            handleComplexRequest(person); // Handle complex scenarios
        } else if (person.isIncompleteRequest()) {
            incompleteRequests.add(person); // Log for later
        } else if (person.isNestedRequest()) {
            handleNestedRequest(person); // Address nested issues
        }
    }
}

Simple Requests go straight to the urgent list.
Complex Requests are handled in detail.
Incomplete Requests are logged for follow-up.
Nested Requests require specialized logic.

Victory!🚀

As I executed the updated code, it felt like crossing the finish line of a marathon. Spliterator handled the chaos beautifully, ensuring urgent requests were prioritized while incomplete ones were noted for future attention.

Final Thoughts: Conquer Your Coding Challenges! 🏆

To all you coding sorcerers out there, remember: with tools like Spliterator, you can transform chaos into clarity. Embrace the magic, and may your code thrive!

The Power of Small Tweaks: Java 17's Flow Scoping and Pattern Matching Unveiled

meenachan — Sun, 11 Aug 2024 17:10:58 +0000

A Day in the Life of a Java Developer: The Subtle Power of Java 17

It was one of those mornings where the coffee was just right, and the code seemed to flow as smoothly as the brew in your cup. You sat down at your desk, ready to tackle a particularly gnarly piece of your project—a module that had been giving you trouble for days. It wasn’t the complexity of the logic that was the problem, but rather the clunky, repetitive code that seemed to go on and on, line after line.

You sighed and leaned back in your chair. There must be a better way, you thought.

The First Problem: Scope Creep

Your mind drifted back to a bug that had kept you up late the previous night. It was one of those insidious, hard-to-track bugs—an error caused by a variable that had been declared too broadly. The culprit was if else statement you had written weeks ago, with a variable that lingered in the outer scope long after it was needed.

Object obj = 123;
String result;

if (obj instanceof String) {
    result = (String) obj;
} else {
    result = obj.toString();
}

System.out.println(result);

The code was functional, sure. But something about it bothered you. The variable result was hanging out in the broader scope like a ghost from a previous flow, ready to cause confusion or worse—another bug.

But then you remembered something you’d read about Java 17: a little feature called flow scoping. It was one of those seemingly small changes that could make a big difference. With flow scoping, variables could be confined to the specific block where they’re needed, keeping the rest of your code clean and focused.

You decided to give it a try.

Object obj = 123;

if (obj instanceof String str) {
    System.out.println(str);
} else {
    System.out.println(obj.toString());
}

It was as if a weight had been lifted. The code was tighter, more elegant. The unnecessary variable was gone, leaving behind a flow that made perfect sense. You couldn’t help but smile—a small victory, but a satisfying one nonetheless.

The Second Problem: The Type-Checking Grind

Encouraged by your success, you turned to another section of code that had been nagging at you. It was a classic scenario: an Object that could be anything—a String, an Integer, a Double—and you had to check its type before you could do anything with it.

The old way was clunky, involving multiple steps just to get to the good part:

Object obj = "Hello, World!";
if (obj instanceof String) {
    String str = (String) obj;
    System.out.println(str.toUpperCase());
}

You groaned as you looked at it. Sure, it worked, but why did you need to check the type and then cast it? Why couldn’t it be simpler?

That’s when you remembered another little gem from Java 17: pattern matching for instanceof. This wasn’t just a syntactical sugar—this was a way to streamline your code, to make it more readable and less error-prone.

You refactored the code, eager to see the difference:

Object obj = "Hello, World!";
if (obj instanceof String str) {
    System.out.println(str.toUpperCase());
}

The effect was immediate. The code was cleaner, more concise. The type check and cast were now one and the same, all in a single line. It was as if the code was speaking your language, doing exactly what you wanted it to do without all the extra noise.

The Magic of Java 17: Putting It All Together

As the day went on, you found yourself using these features more and more, weaving them into your code like a skilled craftsman. You began to see the beauty in these small changes—the way they worked together to create something greater than the sum of their parts.

By the afternoon, you were deep into refactoring an old piece of code that had always felt a little clunky. It was a loop processing an array of mixed types, each element needing its own special handling. Before, the code had been verbose, with each type check followed by an explicit cast.

But now, with Java 17’s flow scoping and pattern matching, you saw a better way:

public class PatternMatchingDemo {
    public static void main(String[] args) {
        Object[] elements = {"Java", 17, 3.14, "Pattern Matching"};

        for (Object element : elements) {
            if (element instanceof String str) {
                System.out.println("String: " + str.toUpperCase());
            } else if (element instanceof Integer i) {
                System.out.println("Integer: " + (i * 2));
            } else if (element instanceof Double d) {
                System.out.println("Double: " + (d * 2));
            } else {
                System.out.println("Unknown type");
            }
        }
    }
}

The code was streamlined, each block of logic contained within its own scope, with variables neatly tied to their specific flow. You marveled at how such small changes could have such a big impact. The repetitive boilerplate was gone, replaced with a clarity and simplicity that felt right.

Conclusion: The Quiet Revolution

As you packed up for the day, you couldn’t help but reflect on how much Java 17 had transformed your code. These weren’t flashy new features, but they were powerful in their own quiet way. Flow scoping and pattern matching had helped you write code that was not only more efficient but also easier to read and maintain.

In the world of software development, it’s often the small things that make the biggest difference. And today, you had discovered that Java 17’s small tricks—flow scoping and pattern matching—were just what you needed to make your code better, one line at a time.

Git Worktree: Your Ticket to Parallel Development Paradise

meenachan — Sun, 28 Apr 2024 11:51:54 +0000

Introduction

We've all been there: deep in the zone, crafting that perfect feature, when suddenly—bam!—a bug report comes crashing in, demanding immediate attention. The frustration of having to switch gears from feature development to bug fixing is enough to make any developer want to hurl their keyboard out the window. But fear not, dear developer, for Git Worktree 🌳 is here to save the day!

The Struggle

Picture this: you're knee-deep in code, crafting the next killer feature for your app. Every line of code is a masterpiece, and you're on fire. But just as you're about to unleash your creation upon the world, a bug report comes swooping in like a pesky mosquito on a summer night.

Now, you're faced with the dreaded task of stashing your current changes, switching branches, fixing the bug, and then trying to remember where you left off with your feature. It's enough to make you want to pull your hair out!

The Old Way

Frantically type git stash into your terminal, hoping it'll save your precious changes.
Switch to the branch for the bug fix with git checkout bug-fix-branch.
Fix the bug, test, commit, and push your changes.
Return to your feature branch with git checkout feature-branch.
Pray to the demo gods that everything still works.

The Solution: Git Worktree to the Rescue!
Enter Git Worktree, the hero we never knew we needed. With Git Worktree, you can create separate working trees for different branches, allowing you to switch between tasks seamlessly without the hassle of stashing and switching.

Git Worktree in Action

Creating a Worktree:

git worktree add ../bug-fix bug-fix-branch

This command creates a new working directory called bug-fix with the bug-fix-branch checked out.
Fixing the Bug:Head over to the bug-fix directory, fix that pesky bug, and commit your changes like a boss.
Returning to Your Feature:

cd ../feature

You're back in your feature branch, right where you left off, ready to conquer the world once again!
Additional Git Worktree Commands:

Listing Worktree

git worktree list

This command lists all the active worktrees along with their associated branches.
Removing Worktrees

git worktree remove <path-to-worktree>

This command removes the specified worktree and its associated directory.
Moving Worktrees

git worktree move <path-to-worktree> <new-path>

This command moves a worktree to a new location.

Conclusion

With Git Worktree, the days of context switching woes are behind us. Say goodbye to stash pop nightmares and hello to seamless task switching. So go forth, dear developer, and conquer the coding world with confidence, knowing that Git Worktree has your back!

A Little Dev Humor

And to all the bugs out there that love to crash our parties uninvited: Git Worktree 🌳 is our secret weapon, and we're not afraid to use it! So bug off, because we've got code to ship!🚀

A Magical Guide to Building Your Own Web Server - For Budding Coders! 🚀✨

meenachan — Sun, 10 Dec 2023 13:28:55 +0000

Introduction:
Hello, little coding wizards!
Today, we're embarking on a magical journey to create our very own web server. It's like having a magic wand that makes the internet dance to our tunes! 🌐✨

Section 1: Setting Up Your Enchanted Castle 🏰
In the coding kingdom, every wizard needs a castle! Our castle is a special folder called "www," where we keep treasures to share with our friends. Let's start by creating this magical castle.

// Enchanted Castle Setup
private static String ROOT_DIRECTORY = "www";

Imagine your computer as a magical castle. We're creating a folder called "www" inside the castle. This is where we'll keep all our magical web treasures!

Section 2: Magical Portal - Starting Your Adventure 🚀
Now, let's create a magical portal (server socket) on port 80. This portal will help us communicate with friends on the internet.

// Magical Portal - Starting Your Adventure
public static void main(String[] args) {
    // ... (Allow specifying the location of the www folder)
    ServerSocket serverSocket = new ServerSocket(80);
    while (true) {
        Socket clientSocket = serverSocket.accept();
        new Thread(() -> handleRequest(clientSocket)).start();
    }
}

Think of the internet as a magical world. We're creating a portal (like a door) on our computer that listens on port 80. When a friend knocks on this door (client connects), we welcome them and handle their requests!

Section 3: Welcoming Magical Creatures - Handling Requests 🌟
When a magical creature (client) knocks, we welcome them and handle their requests in a new thread.

// Welcoming Magical Creatures - Handling Requests
private static void handleRequest(Socket clientSocket) {
    // ... (Opening scrolls for communication with the magical creature)
    String request = in.readLine();
    String requestedPath = getRequestPath(request);

    if (requestedPath.endsWith(".cgi")) {
        serveCgiScript(requestedPath, writer);
    } else {
        serveHtmlFile(requestedPath, writer);
    }
    clientSocket.close();
}

When a friend (client) comes to visit, we read their request on a magical scroll. Depending on what they ask for, we decide whether to share a magical tale (HTML file) or perform a special spell (CGI script)!

Section 4: Extracting Desires - Getting the Requested Path 🧭
Let's create a magical function to extract the desired path from the creature's request.

// Extracting Desires - Getting the Requested Path
private static String getRequestPath(String request) {
    String[] parts = request.split(" ");
    return (parts.length >= 2) ? parts[1] : "/";
}

We use a magical function to understand what our friend is asking for. The function extracts the path from their request, like telling us which book they want from our magical library!

****Section 5: Sharing Magical Tales - HTML Files 📖
We can share magical tales (HTML files) from our enchanted castle. If a friend asks for a specific tale, we find it and share the wonder!

// Sharing Magical Tales - HTML Files
private static void serveHtmlFile(String requestedPath, PrintWriter writer) throws IOException {
    // ... (Constructing the magical path to the tale based on the creature's request)
    try (BufferedReader fileReader = new BufferedReader(new FileReader(file))) {
        writer.println("HTTP/1.1 200 OK");
        writer.println("Content-Type: text/html");
        writer.println();

        // Sending the magical content of the tale to the creature
        String line;
        while ((line = fileReader.readLine()) != null) {
            writer.println(line);
        }
    }
}

When a friend asks for a magical tale, we find the tale in our enchanted library (HTML file) and share it with them. The friend can now see the magical content in their browser!

Section 6: Special Spells - CGI Scripts! 🧙‍♂️
For friends who love special spells (CGI scripts), we take them to a secret room and perform magical spells to create something special!

// Special Spells - CGI Scripts
private static void serveCgiScript(String requestedPath, PrintWriter writer) throws IOException {
    // ... (Constructing the magical path to the script based on the creature's request)
    try {
        // Performing the special spell by executing the CGI script
        // ... (Sending the magical output of the special spell to the creature)
    } catch (IOException e) {
        // If there is an issue with the special spell, sending a message of internal error to the creature
        writer.println("HTTP/1.1 500 Internal Server Error");
        writer.println("Content-Type: text/plain");
        writer.println();
        writer.println("500 Internal Server Error");
    }
}

Some friends want more than just tales—they want special spells! CGI (Common Gateway Interface) scripts are like magical spells that can do amazing things. In our enchanted castle, we have a special room for these spells. When a friend asks for a special spell by requesting a path that ends with ".cgi," we perform the spell by executing the CGI script. The result is a magical output that we share with our friend.

What is CGI?
CGI is like a magic spellbook for web servers. It allows us to perform special actions on the server and create dynamic content. Instead of just sharing fixed tales (HTML files), CGI lets us perform spells (scripts) that can do calculations, show the current time, or even interact with other magical beings (databases). However, it's essential to know that CGI, while once widely used, is like an old spellbook that has been replaced by more modern magic (web frameworks and technologies). So, while we're learning about it for fun, many wizards now use different, more powerful spells for their web adventures! 🌟

Conclusion: You're a Coding Wizard! 🌟Congratulations!

Once Upon a Code Adventure: IoC and DI in the Land of Spring

meenachan — Sun, 19 Nov 2023 13:50:28 +0000

Hello👋✨, little coders! Today, let's dive into a magical coding story where we meet two special friends: IoC (Inversion of Control) and DI (Dependency Injection). Picture it like a fairy tale where coding toys come to life in the Spring kingdom.

What Is Inversion of Control?

Imagine you have a magical friend named IoC. Normally, you decide which toys to play with and when. But IoC flips the story! Now, IoC decides when it's playtime and how the toys play together. It's like a magical friend taking charge of the toy party schedule.

Magic Words: Decoupling, Switching Toys Easily, Neat Toy Rooms, Testing Toys Easily

How We Achieve This Magic:

Strategy: Planning playtime strategies.
Service Locator: Asking a special friend where toys are.
Factory: A magical factory creating toys.
Dependency Injection (DI): Toys are given as gifts!

What Is Dependency Injection?

Now, let's talk about the magic of Dependency Injection (DI). Imagine your mom or dad giving you a special toy as a gift. DI is like receiving toys without making them yourself. Someone injects, or gives, toys into your toy box for you to play with.

Magic Words: Getting Toy Gifts, No Toy-Making Stress, Playful Assembly

Storytime in Code:

// Traditional Way: Making a toy
public class Store {
    private Item item;

    public Store() {
        item = new ItemImpl1();
    }
}

// Magic Way: Receiving a toy gift
public class Store {
    private Item item;

    public Store(Item item) {
        this.item = item;
    }
}

The Spring Toy Kingdom

In the Spring kingdom, there's a special toy organizer called the IoC Container. It's like the king of toys, managing everything from creating to organizing the toys (beans). The Spring kingdom has different areas for toys (ApplicationContexts): one for regular toys, one for toys that like to play alone, and one for web toys!

Magical Words: ApplicationContext, King of Toys, Magical Toy Rooms

How Toys Are Assembled:

// Manually creating a toy room
ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");

Constructor-Based Dependency Injection

Now, let's talk about Constructor-Based Dependency Injection. It's like getting toys with specific instructions on how to play.

Magic Words: Magic Instructions, Special Play Plans

Storytime in Code:

// Magic Instructions in Code
@Configuration
public class ToyPlans {

    @Bean
    public Item item1() {
        return new ItemImpl1();
    }

    @Bean
    public Store store() {
        return new Store(item1());
    }
}

Setter-Based Dependency Injection

Next up is Setter-Based Dependency Injection. It's like getting toys and deciding how to play with them later.

Magic Words: Play Plans Can Change, Decorating Toys Later

Storytime in Code:

// Changing play plans later
@Bean
public Store store() {
    Store store = new Store();
    store.setItem(item1());
    return store;
}

Field-Based Dependency Injection

Now, let's talk about Field-Based Dependency Injection. It's like placing toys directly where they need to be.

Magic Words: Toys Find Their Spots

Storytime in Code:

// Placing toys in their spots
public class Store {
    @Autowired
    private Item item; 
}

Autowiring Toys

Autowiring is like letting the toy room organizer (Spring) decide how toys connect.

Magic Words: Organized Toy Connections

Storytime in Code:

// Toy room organizer deciding connections
public class ToyPlans {
    @Bean(autowire = Autowire.BY_TYPE)
    public Store store() {
        return new Store();
    }
}

Lazy Initialized Toys

Lastly, Lazy Initialized Toys are like toys that wake up only when you want to play with them.

Magic Words: Sleeping Toys, Surprise Playtime

Storytime in Code:

// Sleeping toys until playtime
<bean id="item1" class="store.ItemImpl1" lazy-init="true" />

And that, little coders, is our magical coding adventure with IoC and DI in the Spring kingdom! May your coding toy room always be filled with joy and surprises! 🚀✨

SpringBoot101: Configurations

meenachan — Sat, 18 Nov 2023 15:14:45 +0000

Configuring applications can be both exciting and challenging for developers. In this blog post, we'll dive into the intricacies of Spring configurations, exploring practical techniques like the @Value annotation, leveraging Spring Boot's features, YAML files, and more.

Using @Value Annotation:

Injecting properties with the @Value annotation is a common practice. It's a concise way to pull in configuration values directly into our beans.
java

@Value("${jdbc.url}")
private String jdbcUrl;

Properties with Spring Boot:

Spring Boot simplifies configuration, offering conventions that reduce the need for explicit setup. The application.properties file is automatically detected, sparing us from manual registration. Runtime configurations are flexible, allowing alternative files or locations.

java -jar app.jar --spring.config.location=classpath:/another-location.properties

Environment-Specific and Test-Specific Properties:

Spring Boot provides easy ways to handle environment-specific configurations and tests. Special files like application-environment.properties and @TestPropertySource annotations give granular control.

@TestPropertySource(properties = {"foo=bar"})
public class PropertyInjectionUnitTest {
    // Test implementation
}

Hierarchical Properties:

Managing grouped properties is streamlined with the @ConfigurationProperties annotation. It's a developer-friendly way to structure and organize configurations.

@ConfigurationProperties(prefix = "database")
public class Database {
    // Fields and getters/setters
}

YAML Files:

YAML files are a developer's delight for structured configuration. While they handle nested properties elegantly, keep in mind they don't play nice with the @PropertySource annotation.
yaml

database:
  url: jdbc:postgresql:/localhost:5432/instance
  username: foo
  password: bar
secret: foo

Importing Additional Configuration Files:

Spring Boot 2.4.0 introduces the spring.config.import property, enabling easy inclusion of additional configuration files. It's a powerful tool for handling diverse configuration sources.

spring.config.import=classpath:additional-application.properties,
  classpath:additional-application[.yml],
  optional:file:./external.properties,
  classpath:additional-application-properties/

Properties From Command Line Arguments and Environment Variables:

Directly passing properties through the command line or environment variables is a developer's go-to for quick adjustments.

java -jar app.jar --property="value"

export name=value
java -jar app.jar

Randomization of Property Values:

Injecting a bit of randomness into property values is possible with Spring Boot's RandomValuePropertySource. It's a playful feature for scenarios where deterministic values aren't necessary.

random.number=${random.int}
random.long=${random.long}
random.uuid=${random.uuid}

Additional Types of Property Sources:

Spring Boot supports a plethora of property sources, each with its own strengths. Developers looking for specific behavior should refer to the official documentation for a comprehensive understanding.

Configuration Using Raw Beans — the PropertySourcesPlaceholderConfigurer:
For developers who want complete control, manually defining the property configuration bean with PropertySourcesPlaceholderConfigurer provides flexibility.

@Bean
public static PropertySourcesPlaceholderConfigurer properties(){
    // Bean configuration details
}

Conclusion

Configuring properties is a daily task for developers, and mastering Spring's tools makes it a smoother experience. Armed with techniques like @Value, Spring Boot conventions, and YAML files, developers can confidently handle diverse configurations. So, developer comrades, venture forth with Spring configurations and conquer your application's setup challenges!

Keep Coding!!!!