DEV Community: Onatade Abdulmajeed

Week 14 of #100DaysOfCode: Completing JUnit 5 and Starting a New Portfolio

Onatade Abdulmajeed — Sun, 20 Sep 2026 21:11:30 +0000

Introduction

This week was another productive part of my #100DaysOfCode journey, with a mix of learning, revision, and building.

I started the week by going deeper into software testing with JUnit 5, exploring advanced features such as dynamic tests, parameterized tests, test templates, dependency injection, and JUnit's Extension Model. I also learned how JUnit 5 integrates with tools and frameworks like Mockito, Spring, Selenium, and Cucumber.

I then spent time revising test case design and testing management, covering topics such as test planning, test fixtures, equivalence partitioning, boundary value analysis, code coverage, TDD, BDD, continuous integration, and testing pipelines.

One of the biggest highlights of the week was completing my Mastering Software Testing with JUnit 5 exam, where I scored 70%. It was a valuable learning experience, and I'm taking the lessons from the course forward as I continue improving my Java and backend development skills.

After completing the course, I shifted my focus toward building. I started a new portfolio from scratch using Next.js, Tailwind CSS, and Motion, where I worked on the Hero and About sections.

Alongside the portfolio work, I also started reading Introduction to Docker and began refreshing my understanding of containerization.

This week reminded me that growth as a developer isn't only about learning new technologies. It's also about revising what I've learned, putting it into practice, and continuing to build.

With only a few days left in the challenge, I'm focused on making the most of them.

"Great things are done by a series of small things brought together."

— Vincent van Gogh

Day 87: Going Deeper into JUnit 5

As part of my #100DaysOfCode journey, I continued learning JUnit 5 and went deeper into how testing works and how JUnit helps developers write, organize, and maintain tests.

At first, testing can seem straightforward: write some code, create a test, run it, and check whether it passes. But as applications grow, tests also need to be properly organized and managed.

This was one of the things I started understanding better during this part of my JUnit 5 learning.

Understanding the Test Lifecycle

One of the topics I explored was the JUnit 5 test lifecycle.

JUnit provides annotations that allow us to run specific pieces of code before and after tests.

Some of the annotations I worked with include:

@BeforeEach — runs before each test method.
@AfterEach — runs after each test method.
@BeforeAll — runs once before all tests in a test class.
@AfterAll — runs once after all tests in a test class.

These annotations are useful when a test needs some setup or cleanup.

For example, if multiple tests require a particular object or resource, instead of repeating the setup inside every test, the setup can be handled using @BeforeEach.

This helps keep the tests cleaner and easier to maintain.

Test Instance Lifecycle

I also learned about the test instance lifecycle and the @TestInstance annotation.

JUnit 5 normally creates a new instance of the test class for each test method. However, @TestInstance can be used to change this behavior.

This becomes particularly useful when working with shared test state or when using lifecycle methods such as @BeforeAll and @AfterAll in certain situations.

It was another example of how JUnit 5 gives developers more control over how their tests are executed.

Working with Assertions

Assertions are one of the most important parts of writing tests because they allow us to verify whether the actual result matches what we expect.

I worked with several JUnit 5 assertions, including:

assertEquals
assertThrows
assertAll
assertTimeout

For example, assertEquals can be used to check whether two values are equal, while assertThrows allows us to verify that a particular piece of code throws the expected exception.

I found assertAll particularly useful because it allows multiple assertions to be grouped together, while assertTimeout can be used when the execution time of a test is important.

Understanding these assertions helped me see that testing isn't only about checking whether a method returns the expected value. We can also test exceptions, multiple conditions, and execution time.

Organizing Tests with `@Nested` and `@Tag`

As the number of tests in a project increases, organization becomes important.

JUnit 5 provides annotations such as @Nested and @Tag to help with this.

@Nested allows related tests to be grouped together inside nested test classes. This can make larger test classes easier to understand.

@Tag, on the other hand, allows tests to be categorized.

For example, tests could be tagged as:

@Tag("unit")

or:

@Tag("integration")

This makes it possible to organize tests based on their purpose and selectively run certain groups of tests.

Conditional Test Execution and Assumptions

Another interesting area was conditional test execution.

Sometimes, a test should only run under certain conditions. JUnit 5 provides ways to control this using conditions and assumptions.

Assumptions are useful when a test depends on something that may not always be available.

For example, a test might only make sense when a particular environment variable is present or when the application is running under a specific condition.

Instead of simply allowing the test to fail, assumptions can tell JUnit that the test should be skipped when the required condition isn't met.

Repeated Tests

I also learned about @RepeatedTest.

As the name suggests, this allows a test to be executed multiple times.

@RepeatedTest(5)
void testSomething() {
    // test logic
}

In this example, JUnit will execute the test five times.

This can be useful when we want to verify that a piece of functionality consistently produces the expected result across multiple executions.

Disabling Tests

JUnit 5 also provides the @Disabled annotation for temporarily disabling a test.

@Disabled
@Test
void testSomething() {
    // test logic
}

There can be situations where a test is not ready, needs to be investigated, or should temporarily be excluded from execution.

Rather than deleting the test completely, it can be disabled and revisited later.

JUnit 4 Migration Support

Another topic I explored was JUnit 4 migration support.

JUnit 5 introduced several changes compared to JUnit 4, so understanding how existing JUnit 4 tests can work with newer versions is important, especially when working on existing applications.

This gave me a better understanding of how developers can gradually move from older testing approaches to JUnit 5 without necessarily having to rewrite everything at once.

What I Learned

This part of my JUnit 5 learning helped me understand that writing tests is not just about creating assertions.

There is also a lot that goes into managing a test suite:

Setting up and cleaning up test resources
Controlling the test lifecycle
Writing different types of assertions
Grouping and organizing tests
Running tests conditionally
Repeating tests when necessary
Temporarily disabling tests
Supporting migration from older versions of JUnit

JUnit 5 provides a lot of flexibility for handling these situations, and I'm starting to understand why having a well-organized testing strategy becomes increasingly important as a project grows.

Day 88: Exploring Advanced JUnit 5 Features

After going deeper into JUnit 5's testing fundamentals, I continued with Chapter 4: Simplifying Testing With Advanced JUnit Features.

This chapter introduced me to several features that make JUnit 5 more flexible and powerful, especially when tests need to be reused, generated dynamically, or executed with different sets of data.

Dependency Injection in JUnit 5

One of the first concepts I explored was Dependency Injection in JUnit 5.

JUnit 5 supports dependency injection through its built-in parameter resolvers.

Instead of manually creating everything a test method needs, JUnit can provide certain parameters automatically when the test is executed.

This was interesting to learn because dependency injection is something I've already encountered in backend development, particularly when working with frameworks like Spring.

Seeing a similar concept being used within JUnit helped me understand how the framework manages test execution and dependencies.

Dynamic Tests

One of the topics that stood out to me the most was Dynamic Tests.

JUnit 5 provides the @TestFactory annotation for creating dynamic tests.

A @TestFactory method is different from a normal test method. It isn't itself a test. Instead, it acts as a factory that produces tests at runtime.

For example:

@TestFactory
Collection<DynamicTest> dynamicTests() {
    return Arrays.asList(
        DynamicTest.dynamicTest("Test 1", () -> {
            // test logic
        }),
        DynamicTest.dynamicTest("Test 2", () -> {
            // test logic
        })
    );
}

This approach can be useful when the tests need to be generated based on data or conditions that aren't known until runtime.

It was one of those features that made me realize how much control JUnit 5 gives developers over test creation and execution.

Sharing Test Semantics with Java Interfaces

I also explored how Java interfaces can be used to share JUnit test semantics.

JUnit 5 allows test-related annotations and behavior to be defined in interfaces and then reused by implementing classes.

This can help reduce duplication when multiple test classes need to follow the same testing structure or conventions.

It was another example of how Java's existing features can work together with JUnit to create reusable testing approaches.

Test Templates

Another feature I learned about was Test Templates.

A test template provides a way to define a test structure that can be invoked multiple times with different contexts or configurations.

Unlike a normal test that runs in a fixed way, a test template provides a more reusable structure for tests that need to be executed under different conditions.

This becomes especially useful when the same testing logic needs to be applied across different scenarios.

Parameterized Tests

I also spent time learning about Parameterized Tests.

Parameterized tests allow the same test logic to be executed multiple times using different input values.

Instead of writing separate test methods for every input, we can write one test and provide multiple arguments.

For example:

@ParameterizedTest
@ValueSource(strings = {"Java", "JUnit", "Spring"})
void testSomething(String value) {
    // test logic
}

The test can then be executed using each value provided by @ValueSource.

This can significantly reduce duplicated test code.

Argument Providers

JUnit 5 provides several ways to supply arguments to parameterized tests.

Some of the argument sources I explored include:

@ValueSource
@EnumSource
@MethodSource
@CsvSource
@CsvFileSource
@ArgumentsSource

Each one provides a different way of supplying test data.

For simple values, @ValueSource can be enough.

For more complex or reusable data, @MethodSource or a custom @ArgumentsSource can be useful.

@CsvSource and @CsvFileSource also make it possible to provide multiple values in a CSV-style format.

Understanding these different options helped me see how parameterized tests can make a test suite much more concise while still covering many different scenarios.

Argument Conversion

Another area I explored was argument conversion.

When using parameterized tests, the values provided to a test don't always have to be the exact same type as the method parameters.

JUnit 5 can perform certain conversions automatically, and developers can also define custom conversions when necessary.

This makes parameterized tests more flexible when working with different types of test data.

Custom Parameterized Test Names

I also learned that parameterized tests can have custom display names.

This is useful because when many parameterized tests are executed, the output can become difficult to understand.

Custom names can make it clearer which input values were used for a particular test execution.

For example, instead of seeing several executions with a generic test name, we can include the supplied arguments in the display name.

This makes test reports easier to read and understand.

What I Learned

Day 88 introduced me to some of the more advanced features of JUnit 5.

The biggest takeaway for me was that JUnit isn't just about writing simple test methods and assertions. It provides tools for creating flexible, reusable, data-driven, and dynamic tests.

The features I explored included:

Dependency Injection and parameter resolvers
Dynamic Tests with @TestFactory
Sharing test semantics through Java interfaces
Test Templates
Parameterized Tests
Different argument providers
Argument conversion
Custom parameterized test names

I'm gradually getting a better understanding of how these features can be applied when building larger and more maintainable test suites.

There is still more to learn, but each chapter is making JUnit 5 feel a lot less unfamiliar.

Day 89: Integrating JUnit 5 with External Frameworks

After exploring JUnit 5's advanced testing features, I continued with Mastering Software Testing with JUnit 5, focusing on how JUnit 5 integrates with external frameworks and tools.

This part was interesting because it showed me that JUnit 5 doesn't have to work alone. Its Extension Model allows it to integrate with different frameworks and provide additional functionality depending on what we're testing.

Understanding the JUnit 5 Extension Model

One of the main concepts I explored was the JUnit 5 Extension Model.

Extensions provide a way to extend JUnit's behavior without modifying the JUnit framework itself.

This allows external tools and frameworks to hook into the test lifecycle and provide additional features.

Instead of having JUnit handle every testing requirement on its own, extensions allow other frameworks to work alongside it.

This makes JUnit 5 flexible enough to support different testing scenarios.

Mockito and Mocking

I also learned about integrating JUnit 5 with Mockito.

Mockito is commonly used for mocking and stubbing when testing Java applications.

Mocking allows us to create fake versions of dependencies so that we can test a particular component without relying on its actual dependencies.

For example, if a service depends on a database repository, we can mock the repository and control what it returns during a test.

This allows us to focus on testing the service itself rather than involving the database every time the test runs.

I also explored stubbing, which allows us to define how a mocked dependency should behave when certain methods are called.

This helped me better understand how unit tests can isolate the component being tested.

JUnit 5 and Spring

Another important integration I explored was Spring's testing support.

Since I've been working with Spring and Spring Boot on the backend side, this was particularly useful for me.

Spring provides testing features that allow JUnit tests to work with the Spring application context.

This makes it possible to test components within an environment that is closer to how the actual application runs.

It also showed me how JUnit and Spring complement each other rather than treating testing as a completely separate part of application development.

Selenium and UI Testing

I also looked at how JUnit 5 can work with Selenium.

Selenium is used for browser automation and testing web applications.

JUnit can be used to organize and execute these tests while Selenium handles the browser interaction.

This combination allows developers to automate scenarios such as opening a webpage, interacting with elements, submitting forms, and verifying results.

It was interesting to see how the same testing framework can be used alongside tools that operate at different levels of an application.

Cucumber Integration

Another framework I explored was Cucumber.

Cucumber supports behavior-driven development (BDD), where application behavior can be described in a more human-readable format.

JUnit 5 can integrate with Cucumber, allowing these scenarios to be executed as part of the testing process.

This highlighted another important aspect of testing: tests don't always have to focus only on individual methods or classes. They can also describe and verify application behavior from a broader perspective.

Testing REST APIs

I also explored different approaches to testing REST APIs.

For backend development, API testing is particularly important because APIs are often the main way that different parts of an application communicate.

JUnit can be used alongside other tools and libraries to verify things such as:

HTTP status codes
Request and response data
API behavior
Error handling
Different input scenarios

This is especially relevant to the kind of backend development I'm working toward, where building and testing reliable APIs is an important part of the job.

Testing Docker Containers

Another area covered was testing applications running in Docker containers.

Docker makes it possible to package an application and its dependencies into a consistent environment.

Testing containerized applications introduces additional considerations because we're no longer testing only the application code. We may also need to verify how the application behaves within its containerized environment.

Learning about this connection between testing and Docker was useful as I'm also gradually learning more about containerization and deployment.

Android Application Testing

The chapter also introduced testing approaches for Android applications.

Although Android development isn't my primary focus at the moment, it was useful to see that JUnit 5 and its testing concepts can be applied across different types of software and environments.

It reinforced the idea that testing principles aren't limited to backend applications.

What I Learned

Day 89 helped me understand the importance of JUnit 5's ability to work with other tools and frameworks.

The Extension Model provides a foundation for integrating JUnit with different technologies, while frameworks such as Mockito, Spring, Selenium, and Cucumber can address specific testing requirements.

Some of the areas I explored included:

JUnit 5's Extension Model
Mocking and stubbing with Mockito
Spring testing support
Selenium integration
Cucumber and BDD
REST API testing
Docker container testing
Android application testing

The biggest takeaway for me is that testing doesn't happen in isolation.

Depending on the application, developers may need different tools to test different parts of the system. JUnit 5 provides a foundation that can work with these tools and help bring the different testing approaches together.

I'm getting closer to the end of this JUnit 5 learning journey, and I'm starting to see how the concepts I've learned can fit into real backend development.

Day 90: Revising Test Case Design and Testing Management

As I got closer to completing my Mastering Software Testing with JUnit 5 course, Day 90 was focused mainly on revision.

I went back through Chapters 6 and 7 to strengthen my understanding of the concepts before taking the exam the following day.

The revision covered two major areas: test case design and testing management.

Revisiting Test Case Design

The first part of my revision focused on test case design.

Writing tests isn't simply about creating a test method and checking whether it passes. A good testing process starts with understanding what needs to be tested and designing test cases that can effectively identify potential problems.

Test Planning

I revisited the importance of test planning.

Before writing tests, it's important to understand the requirements, identify what needs to be tested, determine the appropriate testing approach, and consider the resources and conditions required.

Good planning provides a foundation for the testing process and helps ensure that important scenarios aren't overlooked.

Test Fixtures

I also reviewed test fixtures.

A test fixture refers to the setup and state required for a test to run.

This includes things such as creating objects, preparing test data, initializing resources, and cleaning up after tests.

This connected nicely with some of the JUnit 5 concepts I had already learned, particularly the test lifecycle annotations such as @BeforeEach and @AfterEach.

Equivalence Partitioning

Another test case design technique I revisited was equivalence partitioning.

The idea is to divide input data into groups, or partitions, where the values in each group are expected to behave similarly.

Instead of testing every possible input, we can select representative values from each partition.

For example, if an application accepts ages from 18 to 60, we could divide the inputs into categories such as:

Below 18
18–60
Above 60

Rather than testing every possible age, we can select representative values from each group.

This can help reduce the number of test cases while still providing useful coverage.

Boundary Value Analysis

I also revisited boundary value analysis.

This technique focuses on the edges of valid and invalid input ranges.

Using the same example of an age range from 18 to 60, instead of only testing values in the middle of the range, we would pay particular attention to values such as:

Boundary values are important because errors often occur around the limits of accepted input.

This was a good reminder that choosing test data carefully can be just as important as writing the test itself.

Code Coverage

Another topic I reviewed was code coverage.

Code coverage helps us understand how much of our code is being executed by our tests.

There are different types of coverage, including:

Line coverage
Branch coverage
Method coverage
Condition coverage

However, high code coverage doesn't automatically mean that an application is well tested.

A test suite could execute a large percentage of the code while still failing to properly verify important behaviors.

For me, this was an important distinction: coverage is a useful measurement, but it isn't the same thing as test quality.

Testing Management

The second major area I revised was testing management.

This section moved beyond individual test cases and looked at how testing fits into the wider software development process.

Test-Driven Development

I revisited Test-Driven Development (TDD).

TDD follows a cycle commonly described as:

Red → Green → Refactor

The developer first writes a test that fails, then writes enough code to make the test pass, and finally improves the implementation while keeping the tests passing.

The idea isn't simply to write more tests. It's about using tests as part of the development process itself.

Behavior-Driven Development

I also reviewed Behavior-Driven Development (BDD).

BDD focuses more on describing how a system should behave from a user's or business perspective.

This can make requirements easier for developers, testers, and non-technical stakeholders to understand and discuss.

It also connected with what I learned earlier about Cucumber and its approach to describing application behavior.

Continuous Integration

Another important topic was Continuous Integration (CI).

Instead of waiting until the end of development to run tests, CI allows tests to be executed automatically whenever changes are integrated into a shared codebase.

This can help developers detect problems earlier.

For example, a typical pipeline might:

Pull the latest code.
Build the application.
Run automated tests.
Generate test reports.
Report failures.

This connects testing directly with the development workflow rather than treating it as a separate final step.

Testing Pipelines

I also revised testing pipelines and how automated testing can become part of a larger software delivery process.

A testing pipeline can include different stages depending on the project, such as unit tests, integration tests, API tests, and other automated checks.

The goal is to provide continuous feedback about the health of the application as changes are introduced.

This is particularly relevant to backend development and deployment, where automated testing can help catch problems before new code reaches production.

Test Reporting and Defect Tracking

Finally, I looked at tools and practices for test reporting and defect tracking.

Writing and running tests is only part of the testing process. Teams also need ways to understand test results, document failures, and track defects through to resolution.

Test reports can provide useful information about what passed, what failed, and where problems occurred.

Defect tracking systems then help teams record and manage those issues as part of the development workflow.

What I Learned

Day 90 was less about learning completely new concepts and more about connecting everything I had already studied.

I revisited:

Test planning
Test fixtures
Equivalence partitioning
Boundary value analysis
Code coverage
TDD
BDD
Continuous integration
Testing pipelines
Test reporting
Defect tracking

One of my biggest takeaways from the revision was that effective software testing involves much more than writing assertions.

There is the design of the test cases, the quality of the test data, the development process, automation, reporting, and how testing fits into the overall software delivery lifecycle.

After spending the previous days exploring JUnit 5 and its integrations, this revision helped bring many of the concepts together.

Day 91: Completing My JUnit 5 Journey

After several days of learning, practicing, and revising, I finally completed my Mastering Software Testing with JUnit 5 exam.

I scored 70%. 🎉

It was a good way to wrap up the learning experience and see how much I had picked up throughout the course.

What I Learned

Throughout the course, I explored different areas of software testing, starting from the fundamentals and gradually moving into more advanced JUnit 5 concepts.

Some of the major topics I covered include:

Software testing fundamentals
Test case design
JUnit 5 features and test lifecycle
Assertions and parameterized tests
Dynamic tests and test templates
JUnit 5's Extension Model
Mocking and stubbing with Mockito
Spring testing support
REST API testing
Testing management
TDD and BDD
Continuous integration and testing pipelines
Test reporting and defect tracking

One thing I appreciated about the course was that it went beyond simply teaching me how to write JUnit tests.

It helped me understand where testing fits into the software development lifecycle and how different testing tools and practices can work together.

Moving Forward

Although the course is now completed, I don't see this as the end of learning about software testing.

There are still concepts I want to practice through real projects, especially writing meaningful tests for backend applications and APIs.

I'm taking what I've learned forward as I continue improving my Java and backend development skills.

With the exam completed, I can now shift more of my attention toward building and applying what I've learned.

And with 9 days left in the #100DaysOfCode challenge, there's still more work to do.

Day 92: Starting a New Portfolio

With my JUnit 5 learning journey completed, I decided to shift my focus back toward building.

For Day 92, I started working on a new portfolio website from scratch using Next.js, Tailwind CSS, and Motion.

I've built a portfolio before, but this time I wanted to start fresh and create something that better represents my current skills, projects, and growth as a developer.

Starting with the Foundation

I started by setting up the project and working on the first major sections of the portfolio.

The first sections I worked on were:

Hero Section
About Section

The Hero section is the first thing visitors will see, so I wanted it to clearly communicate who I am and what I do.

For the About section, I'm working on presenting my background and development journey in a simple way.

I'm still early in the build, so there is a lot more to come.

Next.js and Tailwind CSS

For this portfolio, I'm using Next.js as the main framework and Tailwind CSS for styling.

I've worked with React before, but using Next.js for the project gives me another opportunity to strengthen my understanding of the framework while building something I'll actually use.

Tailwind CSS is also helping me move quickly while keeping the styling within the components.

Adding Motion

I'm also using Motion to add animations and interactions to the portfolio.

I don't want the animations to simply exist for the sake of animation. I'm experimenting with how subtle movement can make sections feel more interactive without taking attention away from the actual content.

This is something I'll continue refining as the portfolio develops.

Starting Docker

Alongside the portfolio work, I also started reading Introduction to Docker.

After spending so much time learning about backend development, testing, and different parts of the software development lifecycle, I want to become more comfortable with containerization and deployment.

Docker is an important part of modern development workflows, so I'm taking some time to understand the fundamentals before moving into more practical usage.

For now, I'm focusing on understanding the concepts rather than trying to rush through everything.

What's Next?

The portfolio is still a work in progress.

There are several sections I still want to build, improve, and connect before I consider it finished.

I'll also continue learning Docker alongside the development work.

One thing I've noticed throughout this challenge is that learning doesn't always happen through one activity.

Sometimes I'm reading.

Sometimes I'm building.

Sometimes I'm debugging.

And sometimes I'm going back to something I've already learned and applying it in a different way.

Day 92 was a combination of all three.

8 days left in the challenge.

Goals for Week 15

As I move into Week 15, my focus will shift toward building, improving my portfolio, and strengthening my understanding of Docker, while continuing to develop my backend engineering skills.

Here are my goals for Week 15:

Continue building my new portfolio with Next.js, Tailwind CSS, and Motion
Complete and improve the main sections of my portfolio website
Continue learning the fundamentals of Docker and containerization
Strengthen my understanding of Java and backend development
Apply what I've learned through practical projects and hands-on development
Practice LeetCode when I have available time
Continue applying for backend engineering opportunities
Stay consistent with #100DaysOfCode and continue documenting my progress

With the challenge getting closer to the finish line, I want to make the most of this week by building more, applying what I've learned, and strengthening the skills I need as a backend-focused full-stack developer.

I'm looking forward to making progress on my portfolio while continuing to learn Docker and improve my development workflow.

Connect With Me

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

Week 13 of #100DaysOfCode: Completing Spring Microservices and Starting JUnit 5

Onatade Abdulmajeed — Sun, 13 Sep 2026 23:09:04 +0000

Introduction

This week was another challenging but rewarding part of my #100DaysOfCode journey.

I started the week by learning about Docker and containerized Microservices, exploring how containers differ from Virtual Machines, how Docker images and containers work, and how Docker helps package applications and their dependencies consistently.

I then moved into scaling Dockerized Microservices, where I learned about autoscaling, container orchestration, Apache Mesos, Marathon, resource allocation, and managing Microservices at scale.

One of the biggest highlights of the week was completing my Building Spring with Microservices course and writing the exam. After months of learning topics such as Spring Boot, Spring Cloud, Microservices, reactive programming, service discovery, API gateways, logging, monitoring, Docker, and scaling, I was happy to finish the course with a score of 85%.

After completing the course, I started a new chapter by learning software testing with JUnit 5. I began with the fundamentals of software quality, Verification and Validation, software defects, testing levels, static analysis, and the role of JUnit in Java testing.

This week reminded me that backend engineering goes beyond writing code. It also involves understanding how applications are packaged, deployed, scaled, tested, and maintained reliably.

I'm glad to have completed one major learning milestone and started another area that will help me become a better engineer.

Still learning. Still building. Still showing up. 💙

"Great things are done by a series of small things brought together."

— Vincent van Gogh

Day 80: Beginning Docker and Containerized Microservices

On Day 80, I started Chapter 14, Containerizing Microservices with Docker.

What I Learned

What containers are and how they provide operating system virtualization
The difference between Virtual Machines (VMs) and containers
The benefits of containers, including scalability, portability, reusability, and immutability
How containers support Microservices architecture
An introduction to Docker as a platform for building, shipping, and running containers
The two main Docker components: the Docker Daemon and the Docker Client

One thing that became much clearer to me was the difference between VMs and containers. While VMs provide isolation through a guest operating system, containers are much lighter because they share the host operating system. This makes them faster to start and more efficient for running Microservices.

I also started to understand why containers are useful when working with Microservices. Instead of worrying about differences between environments, applications and their dependencies can be packaged together and run consistently.

Day 81: Containerizing Microservices with Docker

On Day 81, I continued learning about Docker and completed the chapter on Containerizing Microservices with Docker.

What I Learned

Docker Images — read-only templates containing the OS libraries, applications, and their dependencies
Docker Containers — running instances of Docker images
Docker Registry — where Docker images are published and downloaded
Docker Hub — Docker's central registry
Docker Trusted Registry (DTR) — used for setting up local or on-premise registries
Dockerfiles — files containing instructions for building Docker images

Understanding these fundamentals is helping me see how Docker packages applications and their dependencies so they can be built, shipped, and run consistently.

With this chapter completed, I now have a better understanding of the role Docker plays in containerizing and deploying Microservices.

Day 82: Scaling Dockerized Microservices with Mesos and Marathon

On Day 82, I started Chapter 15, Scaling Dockerized Microservices with Mesos and Marathon.

What I Learned

Different approaches to autoscaling
Scaling based on resource usage, time periods, queue length, and business parameters
Predictive autoscaling
Why Docker alone isn't enough for managing Microservices at scale
The importance of container orchestration
How orchestration helps with resource allocation, deployments, scalability, health, and service availability
Different orchestration tools, including Docker Swarm, Kubernetes, Mesos, Marathon, Nomad, and Fleet
Apache Mesos architecture and its Master, Agents, ZooKeeper, Scheduler, and Executor
Marathon and how it manages long-running applications and Docker containers

One thing that stood out to me is that as the number of Microservices grows, manually managing containers becomes difficult. Container orchestration provides the abstraction and automation needed to manage these systems more efficiently.

This chapter also helped me understand that scaling isn't only about running more containers. There needs to be a system that can manage resources, monitor services, handle failures, and make sure the required number of instances are running.

Day 83/100

Today, I officially completed my Building Spring with Microservices course and wrote my exam.

I scored 85%.

A few months ago, when I started learning and practicing Spring concepts, I thought there was too much for me to know. Microservices, Spring Boot, Spring Cloud, reactive programming, service discovery, API gateways, logging, monitoring, Docker, scaling, and a lot more.

There were days when learning felt tiring. I had to go back, reread concepts, practice them, fix bugs, and prepare seriously for the exam.

Today, seeing 85% on that result reminded me that the effort was worth it.

I’m really happy to finally say that I’m done with the course.

I'm grateful to Habibulah Oyero and everyone following along for the support, guidance, and encouragement throughout this journey. Your push to keep learning, building, and sharing my progress has made a real difference.

This is another milestone in my journey to becoming a better backend engineer.

I'm not stopping here. There are still plenty of things I need to learn, build, break, fix, and improve.

Day 84/100

New chapter, new area to learn.

Today, I started Mastering Software Testing with JUnit 5.

I started with the basics of software quality, quality engineering, Verification and Validation, software defects, and software testing.

What I Learned

Quality Planning, Quality Assurance, and Post-QA
Verification & Validation
The software defect chain: Error → Fault → Failure → Incidence
Testing levels: Unit, Integration, System, and Acceptance
Black-box, White-box, and Grey-box testing

After spending the last few weeks learning about Microservices and distributed systems, I'm looking forward to getting deeper into software testing and understanding how to write better and more reliable code.

Day 85: Going Deeper into Software Testing with JUnit 5

On Day 85, I continued learning Mastering Software Testing with JUnit 5.

I went deeper into the first chapter, focusing on software quality, Verification and Validation (V&V), software testing, static analysis, and the role of JUnit in Java testing.

I also took a quiz on the chapter to test how well I understood what I had studied.

What I Learned

Software quality
Verification and Validation (V&V)
Software testing
Static analysis
The role of JUnit in Java testing
The importance of testing software against its requirements and expected behavior

One thing that stood out to me is that software testing isn't just about finding bugs. It's part of the bigger process of building software that actually meets its requirements and user expectations.

I'm gradually getting a deeper understanding of software testing and how it fits into the software development process.

Goals for Week 14

As I move into Week 14, my main focus will be on continuing my learning journey with software testing and JUnit 5, while also strengthening the backend concepts I have already covered.

Here are my goals for Week 14:

Continue learning Software Testing with JUnit 5
Deepen my understanding of software quality, testing concepts, and test automation
Start applying JUnit 5 concepts through practical examples
Continue reviewing and strengthening my Java and backend development knowledge
Practice LeetCode when I have available time
Continue applying for backend engineering opportunities
Stay consistent with #100DaysOfCode and continue documenting my progress

This week, I want to focus on building a stronger understanding of software testing and writing better, more reliable Java code.

After completing my Microservices course, I'm looking forward to applying what I've learned while continuing to develop the skills I need to become a better backend engineer.

Still learning. Still building. Still showing up. 💙

Connect With Me

LinkedIn:

https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):

https://x.com/spider337761

Week 12 of #100DaysOfCode: Exploring Spring Cloud and Microservices Infrastructure

Onatade Abdulmajeed — Sun, 06 Sep 2026 22:08:38 +0000

Introduction

This week was another challenging but rewarding part of my #100DaysOfCode journey.

I continued going deeper into Microservices with Spring Boot, this time exploring how different Spring Cloud components help manage distributed systems.

I learned about Spring Cloud Config, Eureka, Zuul, Spring Cloud Stream, RabbitMQ, security, and JUnit testing. I also started exploring logging and monitoring Microservices, including centralized logging, distributed tracing, Prometheus, Spring Boot Actuator, and fault-tolerance concepts like the Circuit Breaker pattern.

These topics helped me understand that building Microservices is not just about creating separate services. You also need to think about configuration, service discovery, communication, security, monitoring, and reliability.

Some of the concepts were challenging, but I'm gradually connecting the different pieces and getting a better understanding of how modern backend systems are designed and managed.

Still learning. Still building. Still showing up. 💙

"Great things are done by a series of small things brought together."

— Vincent van Gogh

Day 73: Starting Spring Cloud

On day 73, I started the Scale Microservices with Spring Cloud Components chapter and began exploring how Spring Cloud helps handle common challenges in distributed systems.

What I Learned

Spring Cloud and how it provides tools for working with distributed systems
Spring Cloud Config and how it helps externalize and manage configuration across different services and environments
How profiles can be used to manage different configurations for different environments
How to set up a Config Server

This chapter is taking me deeper into the practical side of building and scaling Microservices. Instead of only learning what Microservices are, I'm now getting into the tools that help manage them in real-world systems.

Another day of learning and getting a better understanding of how these architectural components work together.

Day 74: Exploring Spring Cloud Config and Service Discovery

On Day 74, I continued learning about Spring Cloud Config and how configuration can be managed across Microservices.

What I Learned

Understanding the Config Server URL using application name, profile, and label
Accessing the Config Server from clients
Handling configuration changes using /refresh
Using Spring Cloud Bus to propagate configuration changes across multiple instances
Setting up high availability for the Config Server
Monitoring Config Server health
Using Eureka for service registration and discovery
Understanding how Ribbon can dynamically change service instances

I'm starting to see how Spring Cloud helps solve some of the challenges that come with managing, communicating with, and scaling distributed systems.

Another day of learning and getting a deeper understanding of how Microservices work in real-world environments.

Day 75: Exploring Service Discovery and API Gateways

On Day 75, I continued learning about Microservices with Spring Cloud, focusing on service discovery, API gateways, and testing.

What I Learned

Dynamic service registration and discovery with Eureka
Setting up a Eureka Server
Configuring high availability for Eureka
Using Zuul as an API Gateway
Started learning JUnit testing

I'm beginning to understand how tools like Eureka and Zuul help Microservices communicate, discover services, and manage requests in distributed systems.

I also started exploring JUnit, which is helping me understand the importance of testing when building reliable backend applications.

Another day of learning and getting closer to building more reliable and maintainable backend systems.

Day 76: Completing Spring Cloud Components

On Day 76, I completed the Spring Cloud Components chapter and learned how different Spring Cloud tools work together to build, communicate, and secure distributed systems.

What I Learned

Zuul as an API Gateway and its different filters
High availability with Zuul and Eureka
Spring Cloud Stream with RabbitMQ, Redis, and Kafka
The concept of Sources and Sinks in messaging
Protecting Microservices with Spring Cloud Security
Consumer-driven gateways

This chapter gave me a better understanding of how different Spring Cloud components work together to build and secure distributed applications.

Day 77: Exploring Logging and Monitoring Microservices

On Day 77, I started Chapter 13: Logging and Monitoring Microservices.

What I Learned

What logs are and the challenges of managing them across Microservices
Popular Java logging frameworks: Log4j, Logback, and SLF4J
Why centralized logging is important
Collecting and analyzing logs from multiple sources
Tracking transactions end-to-end
Keeping logs for long-term analysis and forecasting
Reducing dependency on local disk storage

As Microservices grow, managing logs across multiple services becomes more challenging. Centralized logging helps bring everything together and makes it easier to understand what's happening across the system.

Day 78: Completing Logging and Monitoring Microservices

On Day 78, I completed Chapter 13: Logging and Monitoring Microservices.

This chapter covered a lot around keeping distributed systems observable and reliable.

What I Learned

Selecting and designing logging solutions
Log shippers, stream processors, storage, and dashboards
Distributed tracing with Spring Cloud Sleuth
Monitoring challenges in Microservices
APM, Synthetic Monitoring, and Real User Monitoring
Monitoring tools like Prometheus and Spring Boot Actuator
Hystrix and the Circuit Breaker pattern for fault tolerance
Aggregating Hystrix streams with Turbine
Using Data Lakes to handle fragmented data

One thing that stood out to me is that building Microservices isn't enough. You also need to understand what's happening across the entire system and be able to detect, trace, and respond to problems.

Goals for Week 13

As I move into Week 13, my main focus will be on preparing for my exams while maintaining my #100DaysOfCode progress.

Here are my goals for Week 13:

Prepare thoroughly for my exams
Review the Microservices and Spring Cloud concepts I've covered so far
Continue with my current Spring Boot and Microservices studies where possible
Review Java and key backend concepts for my exams
Continue practicing LeetCode when I have available time
Keep applying for backend engineering opportunities
Stay consistent with #100DaysOfCode and continue documenting my journey

This week, my priority is balance. With exams coming up, I don't want to overload myself with too many new topics or projects.

Instead, I want to focus on understanding what I've already learned, preparing well for my exams, and maintaining steady progress.

After the exams, I can return to deeper practice and building with the Microservices concepts I've been learning.

Still learning. Still building. Still showing up.

Connect With Me

LinkedIn:

https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):

https://x.com/spider337761

Week 11 of #100DaysOfCode: Learning and Building Microservices with Spring Boot

Onatade Abdulmajeed — Sun, 30 Aug 2026 19:12:54 +0000

Introduction

This week has been another challenging but rewarding part of my #100DaysOfCode journey.

I moved from learning Microservices Architecture and related architectural styles into the more practical side of building Microservices with Spring Boot.

I explored Spring WebFlux, Reactive Streams, RabbitMQ, OAuth2, CORS, Swagger, and Spring Boot Actuator, while also learning about security, messaging, monitoring, and asynchronous communication.

I also started building and testing a simple Spring Boot Microservice, which helped me connect the theory I had been learning with practical implementation.

Some of these concepts were challenging, but they are helping me understand that backend engineering is not just about writing code. It's also about understanding architecture, scalability, security, communication, and monitoring.

I'm still learning, building, applying, and looking for opportunities to grow. One step at a time. 💙

"Great things are done by a series of small things brought together."

— Vincent van Gogh

Day 66: Exploring Related Architecture Styles

On day 66, I continued the Related Architecture Styles and Use Cases chapter and explored how different architectural approaches are used in modern software systems.

What I Learned

Lambda Architecture and its applications in Big Data and IoT
How DevOps, Cloud, and Containers work together with Microservices
Reactive Microservices
Conway's Law and the connection between organizational structure and software architecture
Monolithic migration as a common Microservices use case

One concept that stood out to me was Conway's Law. It made me think about how the way teams and organizations are structured can influence the architecture of the software they build.

This section helped me understand that software architecture isn't only about technology. Organizational structure, development practices, and the way systems are deployed can also have a major influence on how applications are designed.

Another day of learning and getting a better understanding of how these architectural concepts connect in real-world systems.

Day 67: Starting Microservices with Spring Boot

On day 67, I started a new chapter: Building Microservices with Spring Boot.

This chapter moves from the Microservices theory I've been learning into more practical implementation using Spring Boot.

I didn't get to do much today, but I went through the beginning of the chapter and looked at what I'll be covering, including:

What I Learned

Building RESTful Microservices with Spring Boot
Spring WebFlux and reactive Microservices
Securing Microservices with Spring Security and OAuth2
Documenting Microservices with Swagger
Using Spring Boot Actuator for production-ready applications

I've already worked with some of these technologies before, so I'm looking forward to seeing how they come together when building actual Microservices.

This chapter feels like a shift from simply understanding what Microservices are to actually learning how to build them with Spring Boot.

Day 68: Building My First Spring Boot Microservice

On day 68, I continued the Building Microservices with Spring Boot chapter and started getting more hands-on.

I set up my Spring Boot development environment and started building and testing a simple Spring Boot microservice.

What I Learned

How @SpringBootApplication brings together configuration, auto-configuration, and component scanning
How to test a Spring Boot microservice using tools such as curl and Postman
HATEOAS and how it can be used to include navigation links in REST responses
HAL, a JSON-based format for representing hyperlinks between resources

This was a good step from the Microservices theory I've been learning into actually building with Spring Boot.

I'm looking forward to going deeper into the practical side of Microservices as I continue through the chapter.

Day 69: Exploring Reactive Microservices

On day 69, I continued the Building Microservices with Spring Boot chapter, focusing on Reactive Spring Boot Microservices.

What I Learned

How reactive principles can improve resource efficiency and scalability
Building reactive microservices with Spring WebFlux
Using messaging servers such as RabbitMQ
WebFlux's annotation-based and functional programming approaches
How Mono fits into reactive request handling

This gave me a better understanding of how modern backend systems can handle asynchronous and non-blocking operations.

I'm continuing to connect the concepts I've learned about reactive systems with practical Microservices development.

Day 70: Reactive Streams and Microservice Security

On day 70, I continued the Building Microservices with Spring Boot chapter, focusing on Reactive Streams and securing Microservices.

What I Learned

The four Reactive Streams interfaces: Publisher, Subscriber, Subscription, and Processor
How RabbitMQ can be used for messaging in Microservices
Securing Microservices with Basic Security
Using OAuth2 to secure protected resources

One thing that stood out to me was how OAuth2 separates the responsibility of authenticating clients from protecting resources.

I'm gradually getting a better understanding of how reactive communication and security fit into Microservices architecture.

Day 71: CORS, Actuator, and Monitoring

On day 71, I continued the Building Microservices with Spring Boot chapter and focused on CORS and monitoring Microservices.

What I Learned

Enabling CORS for cross-origin communication using @CrossOrigin
Using Spring Boot Actuator to monitor and manage Microservices
Exploring Actuator endpoints such as health, metrics, mappings, info, and dump
Monitoring applications using JConsole and SSH
Creating custom health checks and metrics

This section helped me understand that building an application is only part of the job. Monitoring its health, performance, and behavior is also important, especially when running services in production.

Another step forward in understanding the practical side of building and managing Microservices.

Goals for Week 12

As I move into Week 12, I want to focus more on turning the Microservices concepts I've been learning into practical skills.

Here are my goals for Week 12:

Continue building and practicing Spring Boot Microservices
Deepen my understanding of Spring Security and OAuth2
Practice Reactive Programming with Spring WebFlux
Learn more about RabbitMQ and asynchronous communication
Practice using Spring Boot Actuator for monitoring and observability
Continue practicing LeetCode and improving my problem-solving skills
Continue with mock technical interviews and improve how I explain my solutions
Keep applying for backend engineering opportunities
Review Java, Data Structures, and Algorithms for technical interviews
Continue improving and revisiting my existing projects
Stay consistent with #100DaysOfCode and continue documenting my journey

This past week, I moved further from understanding Microservices only from an architectural perspective to exploring how they can actually be built and managed with Spring Boot.

I worked with concepts around reactive programming, messaging, security, CORS, and monitoring, while also getting hands-on with building a simple Spring Boot Microservice.

There's still a lot for me to understand, but I'm gradually connecting the different pieces and becoming more comfortable with backend system design.

Going forward, I want to focus more on building, practicing, and applying what I learn.

Still learning. Still building. Still showing up.

Let's keep building. 💙

Connect With Me

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

Week 10 of #100DaysOfCode: Exploring Microservices and Modern Architecture

Onatade Abdulmajeed — Sun, 23 Aug 2026 16:27:11 +0000

Introduction

This has been one of the toughest weeks I've experienced since starting this challenge.

There were moments when I doubted myself, questioned my progress, and wondered whether all the effort and consistency would eventually pay off.

While I was trying to keep learning, improving my skills, and looking for new opportunities, my phone also got damaged, making things even more difficult. For a while, I couldn't properly connect to the internet or keep up with everything I needed to do.

I found myself asking:

Will I ever get an opportunity? Will all this effort and consistency eventually pay off?

Despite those thoughts, I kept going.

On the learning side, I continued going deeper into software architecture and backend system design. This week, I completed Concurrency Design Patterns and started exploring Microservices Architecture and related concepts such as SOA, Twelve-Factor Apps, Cloud-Native Applications, Serverless Computing, DevOps, and Reactive Microservices.

These topics challenged me technically, but the challenges outside of learning also reminded me why consistency matters.

I'm learning that #100DaysOfCode isn't just about writing code every day. It's also about showing up when things don't go according to plan, continuing when progress feels slow, and trusting the process even when the outcome isn't clear.

I'm leaving the rest in God's hands and praying that everything works out for the best.

For now, I'll keep learning, keep applying, keep improving, and keep showing up. 💙

"Success is the sum of small efforts, repeated day in and day out."

— Robert Collier

Day 59: Completing Concurrency Patterns

On day 59, I completed the remaining parts of the Implementing Concurrency Patterns chapter.

What I Learned

The Half-Sync/Half-Async Pattern
The Leader/Follower Pattern
The Reactor Pattern
Thread-Specific Storage
Using ExecutorService and thread pools
Best practices for building concurrent applications

One thing that became clearer to me was how concurrency patterns help structure applications that need to handle multiple tasks or requests at the same time.

I also learned that concurrency isn't just about creating multiple threads. Different patterns exist to manage how tasks are scheduled, synchronized, and executed while keeping applications efficient and reliable.

Another chapter completed, and another step toward understanding how multithreaded applications are designed and managed.

Day 60: Starting Microservices

On Day 60, I started Chapter 9: Demystifying Microservices.

What I Learned

What Microservices are
The business demands that contributed to their evolution
How technology influenced the evolution of Microservices
The evolution of imperative architecture
How Microservices organize applications around autonomous, self-contained, and loosely coupled business capabilities

This was the beginning of my journey into Microservices, and it helped me start understanding why this architectural style evolved and the problems it aims to solve in modern software systems.

There was still a lot more to explore, but this gave me a foundation for the sections that followed.

Day 61: Understanding Microservices Architecture

On Day 61, I continued learning about Microservices Architecture and went deeper into what makes a microservice different from simply splitting an application into smaller services.

What I Learned

The honeycomb analogy for understanding Microservices
Single responsibility and service autonomy
Key characteristics of Microservices
Lightweight and polyglot architecture
The importance of automation and supporting ecosystems
How services can be distributed and dynamic
Antifragility, fail-fast, and self-healing systems

This section helped me understand that Microservices is not simply about having many small services. The services need to be autonomous, loosely coupled, resilient, and capable of evolving independently.

It also made me realize that designing distributed systems involves many considerations beyond writing the actual business logic.

Day 62: Understanding the Benefits of Microservices

On Day 62, I continued learning about Microservices and focused on the benefits of adopting a microservices architecture.

What I Learned

Supporting polyglot architecture
Enabling experimentation and innovation
Selective and elastic scalability
Allowing substitution of services
Helping manage technology debt
Supporting different versions of services
Supporting self-organizing systems
Enabling event-driven architecture
Enabling DevOps practices

I also learned about the Scale Cube, which describes three approaches to scaling:

X-axis: Horizontally cloning the application
Y-axis: Splitting different functionality
Z-axis: Partitioning or sharding data

Microservices isn't just about breaking an application into smaller services. There are specific architectural benefits and trade-offs behind the approach, especially when it comes to scalability, flexibility, and independent evolution.

I'm continuing to build my understanding of not just what Microservices are, but why organizations choose this architecture.

Day 63: Exploring Related Architecture Styles

On Day 63, I started a new chapter: Related Architecture Styles and Use Cases.

What I Learned

I was introduced to several architecture styles and concepts, including:

Service-Oriented Architecture (SOA)
Twelve-Factor Apps
Serverless Computing
Lambda Architectures
DevOps
Cloud & Containers
Reactive Microservices

I also started learning about Service-Oriented Architecture (SOA) and how it approaches software development through services and business capabilities.

It's still early in the chapter, but I'm looking forward to understanding how these different architectural approaches relate to modern software systems.

Day 64: Exploring Related Architecture Styles and Use Cases

On day 64, I continued learning about Related Architecture Styles and Use Cases, exploring how different architectural approaches support modern software systems.

What I Learned

Service-oriented integration
Legacy modernization
Service-oriented applications
Monolithic migration using SOA
The Twelve-Factor App methodology
Cloud-native applications
Serverless computing

I also explored several Twelve-Factor App principles, including:

Single codebase
Bundled dependencies
Externalized configuration
Addressable backing services
Separation of build, release, and run
Stateless processes
Port binding
Concurrency for scaling
Disposability
Development/production parity
Externalized logs
Admin processes

I'm beginning to understand how these principles help make applications more scalable, maintainable, and suitable for modern cloud environments.

Goals for Week 11

As I move into Week 11, I want to become more intentional about turning the concepts I've been learning into practical skills.

Here are my goals for Week 11:

Practice LeetCode consistently and improve my problem-solving skills
Continue doing mock technical interviews and work on explaining my thought process
Keep applying for backend engineering opportunities
Continue learning and practicing Spring Security
Build practical examples using the Spring concepts I've studied
Review Java, Data Structures, and Algorithms for technical interviews
Continue learning Python for scripting and fast prototyping
Improve and revisit some of my existing projects
Stay consistent with #100DaysOfCode and continue documenting my journey

This past week, I continued going deeper into software architecture and backend system design.

I completed Concurrency Design Patterns and started exploring Microservices Architecture, learning about its evolution, characteristics, benefits, scalability, and the principles behind building autonomous and loosely coupled services.

I also began exploring related architecture styles and concepts, including Service-Oriented Architecture (SOA), Twelve-Factor Apps, Cloud-Native Applications, Serverless Computing, DevOps, and Reactive Microservices.

A lot of these topics challenged me to think beyond simply writing code and start understanding how larger systems are structured, scaled, modernized, and designed to evolve independently.

Going forward, I want to spend more time building practical projects, applying the architectural concepts I'm learning, and testing my understanding instead of only consuming information. I also want to continue improving my problem-solving skills, preparing for technical interviews, and actively looking for backend engineering opportunities.

I'm still working toward becoming a stronger backend engineer, and there's still a lot to learn. But I'm taking it one step at a time and continuing to show up. 💙

Let's keep building. 💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

Week 9 of #100DaysOfCode: A Week of Deep Spring Learning

Onatade Abdulmajeed — Sun, 16 Aug 2026 19:23:22 +0000

Introduction

This week, I decided to slow down and go deeper into the Spring Framework.

Instead of focusing heavily on building new features, I spent most of my time understanding what happens behind the scenes in the framework I use to build backend applications.

I explored concepts around Spring AOP, JDBC, Caching, Reactive Programming, and Concurrency, learning not just how to use these features, but the problems they are designed to solve.

Alongside my learning, I continued applying for backend engineering opportunities, preparing myself for technical interviews, and staying consistent with my #100DaysOfCode journey.

Some of these topics were challenging and unfamiliar, but they gave me a much better perspective on how modern backend applications can be designed to be more efficient, responsive, scalable, and maintainable.

Here’s a look at what I learned throughout the week.

"Success is the sum of small efforts, repeated day in and day out."

— Robert Collier

Day 52: Understanding Spring Caching

Today, I started learning Spring Caching and how caching can be used to improve application performance.

What I Learned

What caching is and where it can be used
How Spring's Cache Abstraction works
The role of Cache and CacheManager
Different cache providers
How caching can reduce repeated executions and unnecessary database calls
How Spring uses the Proxy Pattern to apply caching behavior
How caching can be enabled using annotations or XML configuration
The different caching annotations, including @Cacheable, @CachePut, @CacheEvict, @Caching, and @CacheConfig
How Spring uses AOP and Around Advice to implement caching

One thing that stood out to me was that caching is another example of how Spring uses AOP to separate cross-cutting concerns from business logic. Instead of putting caching logic directly inside my business methods, Spring can apply it around those methods through proxies.

I'm also beginning to understand that caching isn't simply about storing data. The application needs to decide what should be cached, how the cache should be configured, and when cached data should be updated or removed.

Challenges I Faced

The main challenge was understanding how the different parts of Spring's caching abstraction work together, especially the relationship between the cache, CacheManager, proxies, and AOP.

I also had to differentiate between the responsibilities of annotations such as @Cacheable, @CachePut, and @CacheEvict.

Day 53: Complete reading Spring Caching

Today, I continued learning Spring Caching, building on what I learned the previous day.

What I Learned

How to enable Spring's caching abstraction using @EnableCaching
The roles of @Cacheable, @CachePut, and @CacheEvict
How to configure cache storage
Caching best practices
How Spring uses AOP and Around Advice to apply caching behavior

One thing that became clearer to me was how Spring handles caching behind the scenes. Instead of adding caching logic directly into business methods, Spring uses AOP to apply the caching behavior through proxies.

This helped me connect caching with what I previously learned about cross-cutting concerns and Spring AOP.

Day 54: Getting Started with Reactive Design Patterns

Today, I started learning Reactive Design Patterns in Spring and focused on why reactive programming has become important for modern applications.

What I Learned

Why reactive programming is needed
The difference between blocking and non-blocking calls
The principles of reactive systems
Responsiveness, resilience, scalability, and message-driven architecture
How reactive systems are designed to handle large numbers of concurrent requests

What stood out to me was that modern applications need to handle much higher traffic and concurrency than traditional systems were designed for. Reactive programming provides an approach for building systems that can remain responsive and efficient under these conditions.

This was mainly an introduction to the reactive programming model, and it gave me a foundation for understanding how Spring supports reactive applications.

Day 55: Understanding Reactive Streams and Spring Web Reactive

Today, I continued learning Reactive Programming with Spring, going deeper into how reactive applications handle asynchronous data and concurrent requests.

What I Learned

What Reactive Streams are
The concept of back-pressure
The Reactor framework
The four Reactive Streams interfaces: Publisher, Subscriber, Subscription, and Processor
Spring's Web Reactive module
The differences between Spring MVC and Spring Web Reactive
How blocking and non-blocking request handling differ

One concept that stood out to me was back-pressure. It allows a consumer to control how much data it can handle from a producer, helping prevent the system from becoming overloaded.

I also learned that Spring Web Reactive is designed around non-blocking request processing, which makes it suitable for applications that need to handle many concurrent operations efficiently.

Day 56: Completing Reactive Design Patterns

Today, I completed the Reactive Design Patterns chapter and went deeper into how Spring builds reactive web applications.

What I Learned

The functional programming model for reactive applications
RouterFunction and HandlerFunction
Working with Mono and Flux
Creating reactive servers using Reactor and Tomcat
Using Spring WebClient for reactive client-side communication
Reactive request and response body conversion using Encoder and Decoder
How Spring supports both annotation-based and functional programming models
How reactive applications handle data using non-blocking streams

Completing this chapter helped me connect the different concepts I had learned over the past few days, from reactive systems and back-pressure to Reactive Streams, Reactor, and Spring Web Reactive.

It was one of the more unfamiliar areas I've studied so far, but I now have a much better understanding of how Spring approaches asynchronous and non-blocking applications.

Day 57: Getting Started with Concurrency Design Patterns

Today, I started learning Concurrency Design Patterns in Spring, focusing on how these patterns help applications handle multiple tasks and requests concurrently.

What I Learned

What concurrency means in software development
How concurrency patterns relate to multithreaded applications
The Active Object Pattern
The Monitor Object Pattern
How concurrency patterns help manage concurrent method execution

The Active Object and Monitor Object patterns introduced me to different approaches for managing concurrent operations and synchronizing access to objects.

This was just the beginning of the chapter, but it gave me a foundation for understanding how applications can handle multiple operations at the same time.

Goals for Week 10

As I move into Week 10, I want to become more intentional about turning the concepts I've been learning into practical skills.

Here are my goals for Week 10:

Practice LeetCode consistently and improve my problem-solving skills
Continue doing mock technical interviews and work on explaining my thought process
Keep applying for backend engineering opportunities
Continue learning and practicing Spring Security
Build practical examples using the Spring concepts I've studied
Review Java, Data Structures, and Algorithms for technical interviews
Continue learning Python for scripting and fast prototyping
Improve and revisit some of my existing projects
Stay consistent with #100DaysOfCode and continue documenting my journey

This past week, I continued my Spring learning by studying Spring Caching, Reactive Design Patterns, and Concurrency Design Patterns. I also completed the Reactive Design Patterns chapter and started exploring how concurrency patterns help applications handle multiple operations and requests.

A lot of these topics have challenged me to think beyond simply writing code and start understanding what happens behind the scenes in modern applications.

Going forward, I want to spend more time building, practicing, and testing my understanding instead of only consuming information. I also want to use active recall more consistently so I can actually remember and explain the concepts I'm learning.

I'm still working toward becoming a stronger backend engineer, improving my problem-solving skills, and becoming more confident when facing technical interviews.

There is still a lot to learn, but I'm taking it one step at a time.

Let's keep building. 💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

Week 8 of #100DaysOfCode: Grinding for Exams

Onatade Abdulmajeed — Sun, 09 Aug 2026 20:41:25 +0000

Introduction

Instead of building a new project, I decided to go back to the fundamentals. I spent most of the week learning more about the Spring Framework, especially concepts like Spring AOP, Dependency Injection, the IoC Container, Spring Security, logging, and software design principles.

I also spent a good part of the week preparing for my upcoming exams while staying consistent with my #100DaysOfCode challenge. Alongside that, I updated my CV, continued applying for backend roles, and even tried an AI-powered mock interview. Let's just say it was a good reminder that I still have a lot to improve when it comes to technical interviews.

Although I didn't ship a new project this week, I don't see it as a slow week. Understanding the concepts behind the framework I use every day is just as important as writing code. The better I understand how Spring works, the better I'll be able to build secure, scalable, and maintainable applications.

This week was less about showing what I built and more about strengthening the foundation I'm building on.

"The more I learn, the more I realize how much I don't know."

— Albert Einstein

Day 45: Moving from In-Memory to Database Authentication

On day 45, I continued learning Spring Security by moving from in-memory authentication to database-backed authentication.

What I Learned

Created a user database for authentication
Implemented a custom UserDetailsService
Created a custom UserPrincipal by implementing the UserDetails interface
Configured a DaoAuthenticationProvider
Connected Spring Security to my user repository
Learned more about how Spring Security retrieves user information and authenticates users behind the scenes

I'm still following a tutorial, but I'm trying to understand what is happening under the hood instead of simply getting the code to work.

Challenges I Faced

I ran into some issues while configuring Spring Security, particularly around version compatibility and the changes in newer versions of Spring Security. This helped me understand that the way Spring Security is configured can change between versions.

snippet of the code.

Day 46: Learning Spring AOP

Today, I learned how Spring AOP (Aspect-Oriented Programming) helps keep applications clean and maintainable.

What I Learned

What Spring AOP is and why it is useful
How cross-cutting concerns can be separated from business logic
The Proxy Pattern in Spring
The Decorator Pattern and how it relates to Spring AOP
How Spring uses proxies to apply concerns such as logging, security, and transaction management without directly modifying business logic

The main idea I took away today is that not every piece of code belongs inside business logic. Concerns like logging, security, and transaction management can be handled separately using AOP, making applications easier to maintain and extend.

Today was mostly focused on understanding the concepts and design patterns behind Spring AOP. I didn't build anything practical yet, but understanding these concepts is helping me see how Spring works behind the scenes.

AOP process diagram

Day 47: Understanding Spring AOP Proxies

Today, I continued learning Spring AOP and explored how Spring uses proxies to implement Aspect-Oriented Programming behind the scenes.

What I Learned

The difference between JDK Dynamic Proxy and CGLIB Proxy
When Spring uses JDK proxies and when it uses CGLIB proxies
How AOP helps solve code tangling
How AOP helps solve code scattering
How Spring AOP uses proxies to separate cross-cutting concerns from business logic

One thing I found particularly interesting is that Spring doesn't modify the original classes directly. Instead, it creates proxy objects that can intercept method calls and apply cross-cutting concerns such as logging, security, and transaction management without changing the business logic itself.

Challenges I Faced

I didn't encounter any major technical errors today. The main challenge was understanding how JDK Dynamic Proxies and CGLIB proxies work and how they fit into Spring AOP.

Day 48: Understanding Spring AOP

Today, I continued learning Spring AOP (Aspect-Oriented Programming) and gained a much better understanding of how Spring handles cross-cutting concerns behind the scenes while preparing for my exam.

What I Learned

Why Spring AOP exists and the problems it solves
Cross-cutting concerns, code tangling, and code scattering
The five types of Spring AOP advice:
- Before
- After
- After Returning
- After Throwing
- Around
The relationship between Advice, Join Points, Pointcuts, and Aspects
How weaving combines aspects with business logic using proxies
How to define pointcuts with annotations to determine where advice should be applied

One thing I've realized is that Spring AOP isn't just about logging or security. It's about keeping business logic clean by separating concerns that would otherwise be repeated throughout an application.

Understanding what's happening behind the scenes has given me a much greater appreciation for how the Spring Framework is designed.

Challenges I Faced

I didn't encounter any major technical errors today. The main challenge was remembering how the different AOP concepts—especially advice, join points, pointcuts, aspects, and weaving—fit together.

Day 49: Getting Started with Spring JDBC

Today, I continued learning Spring JDBC and JdbcTemplate, focusing on how Spring simplifies database access.

What I Learned

How Spring approaches data persistence
The Template Design Pattern
Problems with traditional JDBC
How JdbcTemplate reduces boilerplate code
How Spring handles data-access exceptions
Different DataSource implementations
The importance of database connection pooling
Using the Builder Pattern to create an embedded data source

One thing I'm starting to understand is that Spring's abstractions aren't just there to make development easier. They help remove repetitive work and allow developers to focus more on the actual application logic.

Understanding the patterns behind these features is also helping me see how many of Spring's tools are designed.

Challenges I Faced

I didn't encounter any major technical errors today. The main challenge was understanding how the Template and Builder patterns fit into Spring's approach to database access.

Day 50: Halfway There

50 days down. 50 to go. 💙

Honestly, reaching Day 50 feels different.

When I started this challenge, I knew I wanted to learn, build, and become better at software engineering. But I don't think I fully understood how much work, confusion, frustration, and self-doubt would come with it.

There have been days when things made sense, days when I felt completely lost, and days when I wondered if I was actually improving. But somehow, I kept showing up.

What I Learned

How the DAO pattern abstracts database access
How JdbcTemplate simplifies database operations
How RowMapper, RowCallbackHandler, and ResultSetExtractor are used when working with query results
Best practices for configuring and using Spring JDBC

Challenges I Faced

I didn't encounter any major technical errors today. The main focus was understanding how these different components work together and why Spring provides these abstractions in the first place.

Halfway Reflection

More than anything, Day 50 is a reminder that I'm still on the journey.

I still have a lot to learn. There are things I struggle to remember, concepts I have to revisit, and areas where I don't feel confident yet. But I'm beginning to understand more than I did when I started.

I'm also really grateful for the people who have supported me along the way.

To everyone who has liked my posts, commented, shared them, encouraged me, or simply followed my journey—thank you. I genuinely appreciate it.

And a special thank you to my mentor, Habibulah Oyero, for the guidance, encouragement, and support that have helped me get this far. I'm truly grateful for everything you've done for me.

I'm halfway through the challenge, but the journey is far from over.

I pray God continues to guide me, give me strength, and lead me to the right opportunities as I keep putting in the work.

For now, I'll keep learning, building, making mistakes, and trying again.

50 days down. 50 more to go. Let's keep building. 💙

Goals for Week 9

With my exams almost behind me, I'm looking forward to shifting some of my focus back to building, improving my technical skills, and preparing for backend engineering opportunities.

Here are my goals for Week 9:

Practice LeetCode consistently to improve my problem-solving skills
Do more mock technical interviews to build my confidence
Continue applying for backend engineering roles
Continue learning Spring Security and complete database-backed authentication
Build practical examples around the Spring concepts I've been studying
Review core Data Structures and Algorithms for coding interviews
Resume learning Python alongside my Java backend journey
Improve my existing projects whenever I have the time
Stay consistent with #100DaysOfCode and continue documenting what I learn

This week, I went deeper into Spring AOP, dependency injection, Spring Security, logging, and Spring JDBC. A lot of what I learned wasn't immediately visible in an application, but it helped me understand more about what happens behind the scenes.

As my exams come to an end, I'm excited to get back to building and also start putting more effort into interview preparation.

I want to become better at solving problems, writing clean code, understanding the systems I build, and most importantly, being able to explain my thought process when I'm in an interview.

I'm still learning. I'm still figuring things out. But I'm making progress, one day at a time.

If you're also learning, building, or growing in tech, I'd love to connect and follow your journey too.

Let's keep building. 💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

Week 7 of #100DaysOfCode: Back to the Fundamentals

Onatade Abdulmajeed — Sun, 02 Aug 2026 20:31:34 +0000

Introduction

After two busy weeks of building VeriFund, deploying projects, participating in my first hackathon, and attending APIConf 2026, this week was much quieter.

I also started preparing for my upcoming exams while staying consistent with my #100DaysOfCode challenge. Alongside that, I updated my CV, continued applying for backend roles, and even tried an AI-powered mock interview. Let's just say it was a reminder that I still have a lot to improve when it comes to technical interviews.

"The more I learn, the more I realize how much I don't know."

— Albert Einstein

Day 38: Exploring Core Spring Concepts

With my exams approaching, I shifted my focus from building projects to strengthening my understanding of the Spring Framework. I revised core concepts such as POJOs, Dependency Injection, Programming to Interfaces, Spring AOP, the major Spring modules, and some of the improvements introduced in Spring 5, including WebFlux. It reminded me that understanding the ideas behind the framework is just as important as knowing how to use it.

Day 39: Learning Logging in Spring Boot

As I continued strengthening my understanding of the Spring Framework, I spent the day learning how logging works in Spring Boot.

What I Learned

What a Logger is and why it's important
Using LoggerFactory to create loggers
Logging application events instead of relying on System.out.println()
Why logging is essential for debugging, monitoring, and maintaining applications

Most of my time was spent reading my Spring notes and understanding how Spring Boot handles logging behind the scenes. Although I didn't build anything new, I gained a much better appreciation for why proper logging is considered a best practice in production applications.

Challenges I Faced

There weren't any major technical challenges today.

Day 40: Exploring Spring Security and Software Design Principles

I continued learning the concepts that make Spring Boot applications more secure, maintainable, and scalable.

What I Learned

Different types of AOP advice:
- @AfterReturning
- @AfterThrowing
- @After (Finally)
An introduction to Spring Security
Authentication vs Authorization
Password hashing with BCrypt
An overview of OAuth2
The Gang of Four (GoF) Design Patterns
Dependency Injection
The SOLID Principles

Most of the day was spent studying these concepts and putting some of them into practice with small code examples. Writing code alongside the theory helped me understand how concepts like AOP advice, Spring Security, and Dependency Injection are actually applied in Spring Boot applications. It reinforced the idea that understanding the principles behind the framework makes it much easier to build secure, maintainable, and scalable applications.

Challenges I Faced

The biggest challenge today was understanding how all these concepts relate to one another. Topics like Spring Security, OAuth2, GoF Design Patterns, and the SOLID Principles are broad on their own, and it took time to connect the theory with the small examples I was writing. Even though I was able to practice some of them in code, I know there's still a lot more to explore before I can confidently apply them in larger real-world projects.

Day 41: Understanding Dependency Injection in Spring

I continued learning about Dependency Injection in Spring and gained a better understanding of how the framework manages objects behind the scenes.

What I Learned

Constructor-based Dependency Injection
Setter-based Dependency Injection
Advantages and disadvantages of each approach
Best practices for constructor and setter injection
A high-level overview of the Spring IoC Container
Different ways to configure Spring applications:
- Java-based configuration
- Annotation-based configuration
- XML-based configuration

This was another theory-focused day. I spent time understanding the different approaches to Dependency Injection and why constructor injection is generally preferred in modern Spring applications. Learning how the IoC container creates and manages beans gave me a much clearer picture of what happens behind the scenes whenever I use Spring.

Challenges I Faced

The biggest challenge today was comparing the different configuration approaches and understanding when each one is appropriate. Although annotation-based configuration is the most common today, learning about Java-based and XML-based configuration helped me appreciate how Spring has evolved over time.

Day 42: Learning Spring Annotations and Preparing for Opportunities

Today was a mix of learning and career growth.

What I Worked On

Updated and improved my CV
Followed up on a previous job application
Continued learning Dependency Injection in Spring
Explored Annotation-based Configuration in more depth
Learned how annotations such as:
- @Component
- @Service
- @Repository
- @Controller
- @Autowired
- @Qualifier help Spring create, manage, and inject beans automatically

I also spent time understanding the role each stereotype annotation plays within a Spring Boot application. Before now, I had been using many of these annotations without fully understanding why they existed or what happened behind the scenes. Learning how Spring scans classes, creates beans, and injects dependencies gave me a much clearer picture of how the framework works internally.

Outside of studying, I updated my CV to better reflect the projects and experience I've gained over the past few weeks and followed up on one of my job applications. As much as I'm focused on learning, I'm also actively preparing myself for backend engineering opportunities.

Challenges I Faced

There weren't any major technical challenges today, but understanding how all the different annotations work together required careful reading and experimentation. It was easy to memorize what each annotation does, but my goal was to understand when and why each one should be used in a real Spring Boot application.

Day 43: Practicing Spring Security

After spending the previous few days learning the theory behind Spring Security and Dependency Injection, I decided it was time to put those concepts into practice.

Rather than just reading, I followed a Spring Security tutorial and built the application alongside the instructor. As I worked through it, I adapted it to the newer Spring Security approach, replacing some of the older implementation with the modern configuration style.

What I Worked On

Built a Spring Security application by following a hands-on tutorial
Learned how UserDetailsService is used to load users during authentication
Explored how Spring Security performs in-memory authentication
Practiced using @Autowired with:
- Field Injection
- Setter Injection
Understood how Spring automatically injects dependencies into managed beans
Updated parts of the tutorial code to use the newer Spring Security configuration instead of the older approach

Writing the code myself made a huge difference. Reading about Spring Security helped me understand the concepts, but actually implementing them showed me how all the pieces fit together during the authentication process.

Challenges I Faced

The biggest challenge was understanding the differences between the instructor's implementation and the newer version of Spring Security. Some parts of the tutorial had changed because newer versions of Spring recommend different approaches. Instead of following the old code exactly, I spent time understanding the changes and updating the implementation to match the current best practices.

I wasn't able to complete the database integration for custom authentication yet, but I now have a much clearer understanding of how Spring Security authenticates users before connecting it to a real database. That will be my next step.

Goals for Week 8

With my exams almost behind me, it's time to shift my focus back to building, improving my technical skills, and preparing for backend engineering opportunities.

Here are my goals for Week 8:

Practice LeetCode consistently to strengthen my problem-solving skills
Take more mock technical interviews to improve my interview confidence
Continue applying for backend engineering roles
Continue learning Spring Security and complete database-backed authentication
Build practical examples using the Spring concepts I've been studying
Review core Data Structures and Algorithms for coding interviews
Resume learning Python alongside my Java backend journey
Continue improving my existing projects whenever I have the time
Stay consistent with #100DaysOfCode and keep documenting what I learn

Week 7 reminded me that progress isn't always measured by the number of features you build or projects you deploy. Sometimes, the biggest growth comes from slowing down, revisiting the fundamentals, and understanding how the technologies you use actually work.

From Spring AOP and Dependency Injection to Spring Security, logging, and software design principles, this week helped me build a stronger foundation that I'll carry into future projects.

As my exams come to an end, I'm excited to get back to building while also preparing myself for technical interviews. My goal is not just to become a better backend engineer, but also to become more confident in solving problems, writing clean code, and communicating my thought process during interviews.

If you're also learning, building, or growing in tech, I'd love to connect and follow your journey too.

Let's keep building. 💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

# Week 5 & 6 of #100DaysOfCode: Shipping Projects, Building VeriFund, and Lessons from My First Hackathon

Onatade Abdulmajeed — Sun, 26 Jul 2026 19:50:00 +0000

Introduction

Weeks 5 and 6 have been the busiest and most rewarding weeks since I started my #100DaysOfCode challenge.

I couldn't publish my Week 5 recap because I was completely focused on the APIConf × Monnify Hackathon. My teammate and I were trying to get everything done before the submission deadline, spending most of our time building features, fixing bugs, integrating APIs, deploying the application, and preparing our demo. By the time we submitted, there wasn't enough time to sit down and write an article.

Now that the hackathon is over, I want to look back at everything I accomplished over the past two weeks.

During Weeks 5 and 6, I started and completed my first hackathon project, VeriFund, deployed my JobPost application, continued learning Spring by exploring Aspect-Oriented Programming (AOP) , and attended APIConf 2026.

Here's how the last two weeks went.

Day 23: Improving My Job Posting Application

Before the hackathon began, I continued improving my Job Posting Application.

I focused on refining the frontend by improving the overall user interface and spacing, adding a loading spinner for a smoother user experience, and implementing an empty search state to handle cases where no jobs matched a user's search. I also made several smaller UI improvements to make the application feel more polished.

I also deployed the React frontend to Netlify. Although the backend hadn't been deployed yet, it was a big step toward turning the project into a fully functional full-stack application.

Seeing the frontend live motivated me to keep working toward connecting it with the backend, which I completed later during these two weeks.

Day 25: Completing My Job Posting Application

I continued working on my Job Posting Application with the goal of getting it ready for deployment.

One of the biggest improvements was completing the Job Details page, allowing users to view complete information about each job posting. I also added an Apply Now feature that supports both external application links and email addresses, making the application more practical for real-world use.

On the backend, I extended my Spring Boot API by adding an applicationLink field to the JobPost model and updated the React frontend to consume the new data correctly. I also refactored parts of the frontend to pass complete job objects between components instead of individual props, making the codebase cleaner and easier to maintain.

A good part of the day was spent debugging integration issues between the frontend and backend. After fixing request validation problems and testing the complete workflow, I successfully verified that users could create job posts, search for jobs, and view job details seamlessly.

By the end of the day, the application was functioning as a complete full-stack project and was finally ready for deployment.

Demo: https://jobposting-app.netlify.app/

Source Code Frontend: https://github.com/Spider1201/job-post

Day 26: Preparing for My First Hackathon

After wrapping up my Job Posting Application, I shifted my focus to the APIConf Lagos 2026 × Monnify Developer Challenge.

Since it was my first hackathon, I wanted to understand what I was getting myself into before writing any code.

I spent the day reading through the information on the official APIConf website, going through the challenge requirements and judging criteria, joining the hackathon community, and introducing myself to other participants. I also spent some time researching ideas that could solve real problems using Monnify's APIs.

One thing I also did was read a few articles on how to prepare for hackathons. A piece of advice that stayed with me was to build something simple that you can actually finish instead of trying to build everything at once.

I didn't have a final project idea by the end of the day, but I felt much more confident about how I wanted to approach the challenge.

Looking back now, this was the day the journey that eventually became VeriFund started.

Official Event Website: https://apiconf.net/

Day 27: Planning VeriFund

With the research out of the way, it was finally time to start planning our hackathon project.

My teammate and I officially began working on what would later become VeriFund.

We spent time discussing the problem we wanted to solve and how we wanted the application to work. We talked through different ideas before settling on a crowdfunding platform that would make fundraising more transparent through campaign verification.

Most of the day was spent planning the backend. We identified the core features we wanted to build, including user authentication, campaign creation and verification, donations, payment processing with Monnify, and email notifications. We also discussed how the Spring Boot backend would communicate with the Next.js frontend and sketched out the API endpoints we would need.

We spent the entire day planning. No code, just conversations about the product, the features we wanted, and how we would build them.

By the end of the day, we had a solid roadmap and were ready to start building VeriFund.

Day 28: Integrating Monnify into VeriFund

With our project plan in place, I decided to start with the Monnify integration before building the rest of the donation workflow.

I intentionally chose to tackle authentication first because I knew payment gateway integrations usually require a fair amount of setup and debugging. My thinking was simple: if I could get authentication and payment initialization working early, I'd have enough time to resolve any issues before connecting the rest of the application.

That decision turned out to be the right one.

One of the biggest milestones was successfully authenticating with Monnify, implementing payment initialization, and generating my very first checkout URL from the backend. Seeing a real payment gateway respond to my API instead of just returning dummy data was a great feeling.

What I Worked On

Set up Monnify Sandbox authentication
Implemented payment initialization in the Spring Boot backend
Successfully generated my first Monnify checkout URL
Configured Spring Security for the payment flow
Tested the payment initialization endpoint using Swagger

Challenges I Faced

The integration definitely wasn't straightforward.

The first issue I ran into was Maven and JDK configuration problems, which prevented the project from building correctly. Once that was fixed, Spring Security kept returning 403 Forbidden responses while I was testing my endpoints.

After resolving that, I discovered that my Monnify requests were still failing because my request payload and configuration weren't right. I spent a lot of time comparing my implementation with the Monnify documentation, checking my environment variables, authentication headers, and API requests until I finally got a successful response.

Getting that first checkout URL felt like a huge win because it meant the backend was finally communicating with Monnify successfully.

By the end of the day, payment initialization was working, and I had a much better understanding of Spring Security, REST API integration, and how payment gateways work behind the scenes.

Day 29: Building Authentication for VeriFund

After getting Monnify integration working, my next focus was authentication.

Since VeriFund would have different types of users, I wanted to build authentication before moving on to campaign management and authorization.

What I Worked On

Implemented user registration
Added BCrypt password hashing for secure password storage
Built JWT authentication from scratch
Implemented user login with JWT token generation
Tested registration and login endpoints using Swagger
Continued improving the backend architecture of VeriFund

Challenges I Faced

Building authentication involved more than just generating a JWT.

I spent a good amount of time configuring Spring Security correctly, making sure requests were authenticated as expected, and verifying that JWTs were being generated and returned after a successful login.

There were a few configuration issues along the way, and I had to repeatedly test my endpoints in Swagger until registration, password hashing, and login all worked together correctly.

By the end of the day, users could register successfully, passwords were securely stored using BCrypt, and a valid JWT was returned after authentication—a major milestone for VeriFund.

Day 30: Completing the Donation Module

The Donation Module was one of the biggest features in VeriFund, and today I finally completed it.

What I Worked On

Implemented the complete donation workflow
Restricted donations to approved campaigns only
Automatically updated each campaign's amount raised after a successful donation
Generated a unique payment reference for every donation
Added endpoints to retrieve donations for a campaign
Added an admin endpoint to retrieve all donations

Challenges I Faced

Most of the donation functionality worked as expected, but I ran into an issue with JWT authentication while testing protected endpoints in Swagger.

Even with a valid token, some endpoints weren't being authorized correctly. After tracing through the security configuration and testing different requests, I was able to identify the problem and update the JWT authentication flow so the protected endpoints worked as expected in Swagger.

With that resolved, I was finally able to test the complete donation workflow from end to end.

Day 31: Deploying VeriFund

After Implementing the core features in place, I decided to put VeriFund online.

What I Worked On

Deployed the Spring Boot backend to Render
Connected the application to MongoDB Atlas
Configured production environment variables
Tested the live API using Swagger
Shared the deployed backend with my teammate so frontend integration could begin

Challenges I Faced

Deploying the application wasn't as simple as pushing the code to Render.

I ran into a few issues along the way, including build failures, missing environment variables, and problems connecting to MongoDB Atlas from the deployed application. At one point, the application deployed successfully but still couldn't communicate with the database because of configuration issues.

I spent a good amount of time checking deployment logs, verifying my environment variables, and updating the MongoDB network settings until everything finally worked.

Seeing the API come online and successfully respond to requests from the deployed environment made all the debugging worth it. It was my first time deploying a backend for a hackathon project, and it gave me a much better understanding of what it takes to move an application from local development to production.

Live API: https://verifund-mmwl.onrender.com/swagger-ui/index.html

Day 32: Frontend Integration and Deployment Fixes

With the backend deployed, the next step was making sure everything worked together.

My teammate and I spent the day connecting the frontend to the live backend and fixing the issues that came up during integration. Most of the work wasn't about building new features, it was about making the existing ones work reliably in a deployed environment.

What I Worked On

Updated and redeployed the Spring Boot backend after fixing integration issues
Configured CORS to allow communication between the frontend and backend
Worked with my teammate to connect the frontend to the live APIs
Fixed the Monnify payment verification flow
Resolved authentication and API access issues
Completed the backend README documentation
Tested the application with my teammate to make sure the core features worked as expected

Challenges I Faced

Once the frontend started communicating with the deployed backend, a few issues that didn't appear during local development started showing up.

I had to update my backend configuration, redeploy the application a couple of times, and troubleshoot CORS, authentication, and payment verification until everything worked correctly.

By the end of the day, the frontend and backend were communicating successfully, and VeriFund felt much closer to being ready for the hackathon submission.

Day 33: Submitting VeriFund

Submission day had finally arrived.

Before submitting the project, I spent some time making sure everything was ready.

What I Worked On

Finalized the backend API documentation
Recorded the project demo
Reviewed the deployed application one final time
Completed the hackathon submission form
Submitted VeriFund for the APIConf × Monnify Hackathon

Challenges I Faced

The biggest challenge on submission day was recording the demo video.

Our original plan was to demonstrate the application through the frontend, but we ran into frontend issues close to the submission deadline. Instead of spending more time trying to fix everything, I decided to record the demo using the backend APIs in Swagger so we could still showcase the core functionality of VeriFund.

Preparing the demo, making last-minute checks, and recording everything took longer than we expected, and because of that, we ended up submitting our project later than we had planned.

Even though things didn't go exactly as we hoped, we still managed to submit a working project.

Live Demo: https://verifund-f.vercel.app/

Day 34: Shipping My JobPost Application

After submitting VeriFund for the hackathon, I decided to return to one of my personal projects and finally ship it.

I had been working on my JobPost application for a while, and this felt like the perfect time to deploy it and make it accessible online.

What I Worked On

Deployed the Spring Boot backend to Render
Connected the backend to MongoDB Atlas
Deployed the React frontend
Configured CORS for seamless frontend-backend communication
Added Docker support
Wrote professional README files for both the frontend and backend repositories

Challenges I Faced

Deploying the application wasn't completely straightforward.

I had to configure production environment variables, update my MongoDB Atlas settings, and fix CORS issues before the frontend could communicate with the deployed backend successfully. I also Dockerized the backend to make it easier to run and deploy consistently.

By the end of the day, the application was fully deployed and available online. It felt good to finally ship another project after spending the previous week focused on the hackathon.

Live Demo: https://jobposting-app.netlify.app/

Backend API: https://job-post-api.onrender.com/swagger-ui/index.html

Day 35: Learning Spring AOP

After spending the past few days building and deploying projects, I decided to slow down and focus on learning something.

Today's focus was Spring AOP (Aspect-Oriented Programming).

I wanted to understand how Spring keeps business logic clean by separating concerns like logging, security, validation, and exception handling instead of scattering the same code throughout an application.

What I Learned

What Aspect-Oriented Programming (AOP) is
Cross-cutting concerns
Aspects
Advice and the different annotations:
- @Before
- @After
- @AfterReturning
- @AfterThrowing
- @Around

My Thoughts

One thing I enjoyed while learning AOP was realizing that many of the features I've already used in Spring Boot are powered by concepts like this behind the scenes.

The more I understand how Spring works internally, the more comfortable I become using it. Instead of just knowing what Spring does, I'm starting to understand how it does it, and that makes learning the framework much more interesting.

The next step is to stop reading and start writing my own aspects so I can see these concepts in action.

Day 36: Attending APIConf 2026

After weeks of building, debugging, deploying, and submitting VeriFund, it was finally time for APIConf 2026.

This was my first time attending a tech conference, and I genuinely enjoyed the experience. The event was well organized, and it was exciting to be surrounded by developers and engineers.

One of my favorite sessions was "Software Is Going Headless: What the API Becomes When Agents Run Everything" by Joel Olawanle. One statement that really stayed with me was the idea that APIs are no longer just a feature they're becoming the product itself. That completely changed the way I think about backend development and API design.

I also attended sessions on AI, agent-ready APIs, and Kubernetes, including:

Software Is Going Headless: What the API Becomes When Agents Run Everything — Joel Olawanle
AI Can Write Code. But It Doesn't Know Your System — Chigozie Madubuko
Are Your APIs Ready for Agents? — Auwal MS
What API Designers Can Learn from the Kubernetes API — Somtochi Onyekwere

Listening to these talks made me realize that while AI can generate code, understanding systems, APIs, architecture, and how everything works together is what makes someone a good software engineer.

Last night, the hackathon results were finally released.

Out of 105 project submissions, only 72 projects were ranked, and VeriFund finished 22nd.

Honestly, I was really happy with that result.

Looking back, I know our project wasn't complete. We still had features we wanted to implement, like the disbursement workflow, and we also ran into frontend issues before submission, which meant I had to record the demo using Swagger instead of the frontend we originally planned to showcase. On top of that, I was balancing school while preparing for my first hackathon, so time wasn't exactly on our side.

Even with those challenges, finishing 22nd gave me a lot of confidence. It showed me that our idea had potential and that the work we put into building the backend was recognized.

More importantly, it taught me an important lesson: it's better to have a few features working perfectly than many features that are only partially complete. That's something I'll definitely carry into my next hackathon.

APIConf also introduced me to technologies and ideas I want to explore further. One of my goals after the conference is to spend more time learning Python alongside my backend journey.

One thing I wish I had done better was networking. I was only able to interact with one person during the event. Next time, I want to meet more developers, have more conversations, and build stronger connections within the tech community.

Looking back, attending APIConf made me feel like a real developer.

Sitting in the same room with experienced engineers, One of the special guests at the event had 24 years of experience, it made me realize how much there is still to learn. It motivated me, and made me feel like I'm finally on the path I've always wanted to be on.

I'm already looking forward to attending APIConf again, participating in another hackathon, meeting more people, and coming back with an even better project.

Images:

Goals for Week 7

With the hackathon behind me, it's time to balance learning with preparing for my upcoming exams.

Here are my goals for Week 7:

Start preparing for my exams while maintaining consistency with #100DaysOfCode
Continue learning Spring AOP by building practical examples
Explore more advanced Spring Boot concepts
Begin learning Python alongside my Java backend journey
Improve my existing projects whenever I have the time
Keep documenting my progress and sharing what I learn

The past two weeks were some of the busiest of my journey so far. I built VeriFund for my first hackathon, deployed multiple applications, attended my first tech conference, and learned a lot about building, deploying, and presenting real-world software. Those experiences pushed me outside my comfort zone and gave me a clearer picture of the kind of engineer I want to become.

For now, my priority is preparing for my exams while continuing to learn consistently. Progress may be a little slower, but I don't intend to stop showing up every day.

If you're also learning, building, or growing in tech, I'd love to connect and follow your journey too.

Let's keep building. 💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

My Fourth Week of #100DaysOfCode: Turning a Backend Project into a Full-Stack Application

Onatade Abdulmajeed — Sun, 12 Jul 2026 19:28:49 +0000

Introduction

I'm currently in the fourth week of my #100DaysOfCode challenge, and this week has been one of the most exciting so far.

After spending the previous weeks strengthening my backend skills with Spring Boot and MongoDB, this week was all about bringing everything together by building the frontend of my Job Posting Application with React.

I focused on building the user interface one component at a time instead of rushing through it. From designing the navigation bar and hero section to building the job cards, job list, and search functionality, every step helped me understand React better and how it communicates with a Spring Boot backend.

Of course, it wasn't without challenges. I spent time debugging integration issues, dealing with MongoDB Atlas connection problems, and figuring out how to connect the frontend to the backend properly. But after working through those issues, I was finally able to fetch and display real job data from MongoDB in my React application.

Looking back, this week reminded me that building software isn't just about writing code. It's about connecting different pieces together, solving unexpected problems, and staying patient until everything finally works.

The only way to do great work is to love what you do.

– Steve Jobs

Day 17: A Day of Debugging, Not Building

I had planned to continue working on my Job Posting API, but the day turned out very differently from what I expected.

I spent most of the day debugging issues that had started the previous day. One of my school projects suddenly stopped working as well, so the entire day became a debugging session.

Although I wasn't able to make visible progress on the application itself, Every problem solved improves my understanding of how the technologies actually work.

What I Learnt and Explored

Troubleshooting MongoDB Atlas SSL connection issues
Debugging Spring Boot and MongoDB integration
Understanding the difference between IDE warnings and actual runtime errors
Comparing Spring Boot 3.x and 4.x while investigating dependency compatibility
Restoring MongoDB Atlas Search functionality

Challenges I Faced

The biggest challenge wasn't writing code—it was identifying the real source of the problem.

At first, IntelliJ's warning that MongoTemplate couldn't be autowired made it seem like my configuration was incorrect. However, after testing the application and examining the stack traces, I realized that the warning was unrelated to the actual failure. The application itself was fine; the connection to MongoDB Atlas was the real issue.

While troubleshooting, I also compared Spring Boot 3.x and 4.x to understand whether dependency compatibility was contributing to the issue. After several hours of testing different possibilities, checking configurations, and verifying my dependencies, I eventually restored the connection and got MongoDB Atlas Search working again.

This experience reminded me that error messages and IDE warnings should always be investigated carefully instead of accepted at face value. Sometimes the first thing that looks wrong isn't the actual cause of the problem.

Although I didn't build any new features that day, I walked away with a much better understanding of Spring Boot, MongoDB Atlas, SSL connections, and the debugging process itself.

By the end of the day, the application was running again, MongoDB Atlas Search was working, and I had gained valuable experience that I know will help me solve similar problems much faster in the future.

Day 18: Started the Frontend of My Job Posting Application

After spending the previous days building the backend of my Job Posting Application with Spring Boot and MongoDB, I finally started the frontend.

I decided to build the frontend with React because I wanted to strengthen my frontend skills while learning how a React application communicates with a Spring Boot backend through REST APIs.

Instead of jumping straight into building the user interface, I spent the day setting up the project properly and understanding how the frontend would consume data from the backend. I wanted to build the application on a solid foundation before adding features.

What I Learnt and Explored

Creating a React project with Vite
Organizing a React project structure for scalability
Understanding how React consumes REST APIs
Learning how the frontend communicates with a Spring Boot backend
Preparing the application for backend integration

Day 19: School Presentation Day

On Day 19, I had the opportunity to present my team's Air Reservation Application at school.

The application was built using React Native (Expo), Spring Boot, PostgreSQL, and Supabase, and was designed to make searching, booking, and managing flight reservations easier.

Although the presentation itself went well, I was able to explain what the application does, how it solves a problem, and how users interact with it.

Watching people ask questions and engage with the project also gave me a better appreciation for communicating technical ideas to different audiences.

What I Learnt and Explored

Presenting a software project to an audience
Explaining the purpose and value of an application
Communicating technical concepts in a simple way
Observing how people interact with a software product during a presentation

After the presentation, it was time to shift my focus back to my Job Posting Application and continue building.

Day 20: Building the Foundation of My React Frontend

After learning how React communicates with a Spring Boot backend, it was finally time to start building the frontend of my Job Posting Application.

Rather than rushing into creating every page, I decided to take my time and build the application one component at a time. I wanted the project to have a clean structure that would be easy to maintain as more features were added.

What I Built

Created the React project using Vite
Organized the project structure
Built a responsive navigation bar using React Icons
Designed and implemented the hero section
Improved the overall layout and styling using plain CSS
Planned the component structure to make the application easier to scale

I also spent some time improving my interview skills by reading an article by Wes Kao about telling better stories during interviews. One lesson that stood out to me was to keep the Situation in the STAR method short so you have more time to explain your actions, results, and the impact you made.

Article: https://newsletter.weskao.com/p/in-job-interviews-keep-your-backstory

By the end of the day, I had the foundation of the frontend in place and a clear plan for the remaining components before connecting everything to my Spring Boot backend.

Day 21: Building the Core of the Frontend

I continued working on the frontend of my Job Posting Application by focusing on the components that users will interact with the most.

Instead of trying to build every section at once, I concentrated on creating reusable components that will make the application easier to maintain and extend as development continues.

What I Built

Designed the Job Card component
Built the Job List component
Continued improving the overall frontend structure
Focused on creating reusable UI components for future features

Although I couldn't spend as much time coding as I had planned because of other commitments, I still made steady progress.

One thing I've come to appreciate while building this project is that frontend development isn't just about making an application look good. It's also about organizing components in a way that keeps the codebase clean and makes adding new features much easier.

By the end of the day, the foundation of the application's user interface was taking shape, and I was ready to begin connecting the React frontend to my Spring Boot backend.

Day 22: Connected the Frontend to the Backend

After spending the previous days building the user interface, it was finally time to connect everything together.

I replace dummy data with real data from my Spring Boot backend and MongoDB database.

What I Built

Connected the React frontend to my Spring Boot backend
Fetched and displayed real job data from MongoDB
Connected the search functionality to the backend
Fixed integration issues that came up during development
Made improvements to the user interface

Seeing the application display real data instead of hardcoded information completely changed how the project felt. It was no longer just a collection of frontend components—it had become a working full-stack application.

Like every integration, there were a few issues to work through before everything functioned correctly, but solving them gave me a much better understanding of how React, Spring Boot, and MongoDB communicate with each other.

By the end of the day, I had a working frontend connected to a real backend. The remaining work was to polish the application, implement the job application feature, and deploy it so other people could use it.

Based on what you've completed in Week 4, your Week 5 goals should naturally build on it.

Goals for Week 5

As I head into Week 5 of this journey, these are the goals I've set for myself:

Complete the remaining features of my Job Posting Application
Implement the job application functionality
Polish the user interface and improve the overall user experience
Deploy the frontend and backend so the application is live
Learn more about deploying Spring Boot and React applications
Continue strengthening my skills
Keep documenting my journey and sharing what I learn

Week 4 showed me what it takes to bring a full-stack application together. From building the frontend with React to connecting it to my Spring Boot backend and MongoDB database, every step helped me understand how different parts of an application work together.

There's still plenty to improve, but seeing the project evolve from an idea into a working application has been incredibly motivating.

I know there's still a long way to go, but I'll keep building, learning, and improving one day at a time.

If you're also learning, building, or growing in tech, I'd love to connect and follow your journey too.

Let's keep building. 💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

My Third Week of #100DaysOfCode: Learning, Building, and Trusting the Process

Onatade Abdulmajeed — Sun, 05 Jul 2026 22:19:35 +0000

Introduction

I'm currently in the third week of my #100DaysOfCode challenge, and this week has been different from the previous ones.

When I started this challenge, I had one goal: to become a better software engineer by showing up every day, learning consistently, and building real projects that would prepare me for opportunities.

I spent part of the week applying for jobs but didn't receive any responses. For a moment, I found myself questioning whether all the time and effort I was investing in learning, building, and improving myself would eventually lead to the opportunities I was hoping for.

But after thinking about it, I realized that giving up wouldn't change anything. So I kept building, kept learning, and I will keep on showing up.

Looking back now, I'm beginning to understand that this journey is about more than becoming a better software engineer. It's teaching me patience, resilience, consistency, and the importance of trusting the process, even when the results aren't immediate.

"Make it work, make it right, make it fast."

— Kent Beck

Day 10: Turning My Product Management App into a REST API

I continued working on my Product Management Console App. The project started as a plain Java application, and I decided to convert it into a Maven project to prepare it for development with the traditional Spring Framework.

At this point, the application could already manage products and search for them by name, brand, and type. I then created a PostgreSQL database, designed the product table, and successfully stored my product data using JDBC.

After connecting the application to the database, I exposed its functionality through REST endpoints, making it possible to interact with the application over HTTP instead of running everything directly from the console.

What I Learnt and Explored

Connecting a Java application to PostgreSQL using JDBC
Creating and configuring a PostgreSQL database
Designing a relational database table for products
Storing application data in a database instead of memory
Understanding how Java applications communicate with relational databases

Challenges I Faced

One of the biggest adjustments was moving from storing data in memory to persisting it in a real database. This required setting up the database correctly, creating the product table, and ensuring the application could establish a successful connection through JDBC.

Although I had just returned to school and couldn't spend as much time coding as I had planned, I was able to complete the database setup and successfully store product records in PostgreSQL.

Seeing the application save data in a real database instead of memory was a satisfying milestone because it made the project feel much closer to a real-world application.

Application Successfully Connected to PostgreSQL

Day 11: Rebuilding My Product Management App with Spring Boot

On Day 11, I took another big step in my backend journey by rebuilding my Product Management App with Spring Boot.

Instead of continuing with the console-based Java application, I created a new Spring Boot project and began migrating the application's functionality.

What I Learnt and Explored

Setting up a Spring Boot project
Connecting Spring Boot to PostgreSQL
Configuring Spring Data JPA
Using JpaRepository to retrieve data without writing SQL queries manually
Understanding how Spring Data JPA simplifies database interactions

Challenges I Faced

While testing the application, I ran into a bug that prevented my data from being retrieved correctly.

After checking the issue, I realized my database column was named Id while my entity expected id. Since PostgreSQL is case-sensitive when identifiers are quoted, this mismatch caused the problem.

Renaming the column resolved the issue immediately, and I was able to fetch all product records successfully.

This experience reminded me that sometimes the smallest details can cause the biggest headaches.

By the end of the day, I had successfully transformed the project from a plain Java application using JDBC into a Spring Boot application powered by Spring Data JPA. More importantly, I started to understand not just how Spring Boot works, but why it makes backend development much more efficient.

Day 12: Transforming My Product Management App into a Spring Boot MVC Application

On Day 12, I continued rebuilding my Product Management App by transforming it into a Spring Boot MVC application. This was an important milestone because the application was no longer limited to running from the console—it could now respond to HTTP requests through REST endpoints.

What I Learnt and Explored

Implementing the Spring Boot MVC architecture using the Controller, Service, and Repository layers
Connecting the application to PostgreSQL through Spring Data JPA
Building REST endpoints to retrieve and search products
Understanding how Spring processes HTTP requests and responses
Using Lombok to reduce boilerplate code and improve readability

Challenges I Faced

While working on the project, I spent time understanding how Spring Boot processes HTTP requests and responses, how the different layers of the application communicate, and why a Java web application needs a servlet container like Tomcat.

One idea that stayed with me throughout the day was:

"If debugging is removing bugs, then coding is adding bugs."

It reminded me that every line of code is another opportunity for bugs to appear. One thing I've come to appreciate about Spring Boot is how much repetitive code it removes. Less boilerplate means cleaner code, easier maintenance, and fewer places for bugs to hide.

Fortunately, the issues I encountered were relatively small, and I was able to debug and resolve them on my own.

By the end of the day, my Product Management App had evolved from a console-based application into a Spring Boot application exposing RESTful APIs, backed by a cleaner MVC architecture.

Day 13: Starting My Job Posting Application

After completing the core features of my Product Management App by implementing the Update and Delete operations, I decided it was time to start my next project—a Job Posting Application.

The application will use React for the frontend, Spring Boot for the backend, and MongoDB as the database. The idea is to build a platform where companies can post job opportunities and job seekers can browse and search for available positions.

Since I'm more backend-focused, I started with the backend by setting up the Job Posting API. Before writing the application's core features, I focused on preparing the project structure and laying the foundation that I'll continue building on in the coming days.

What I Learnt and Explored

Completing the Update and Delete operations in my Product Management App
Creating a new Spring Boot project for the Job Posting API
Setting up MongoDB Atlas for cloud database management
Preparing the project structure for future development
Populating the database with sample job data

Why This Day Was Important

Although I didn't build many features, I spent time preparing the project's foundation. I've learned that starting a project properly choosing the right technologies, organizing the structure, and setting up the database—makes development much smoother later on.

By the end of the day, the project was ready, and I was excited to begin building the API features over the following days.

Day 14: Laying the Foundation for My Job Posting Application

On Day 14, I laid a strong foundation for my Job Posting Application by focusing on the backend. I spent the day setting up the project structure and preparing everything needed for the application.

What I Explored

Created the application's core layers
Connected my application to MongoDB Atlas
Integrated Swagger (OpenAPI) for API documentation and testing
Built the endpoint to retrieve all job posts
Configured MongoDB Atlas Search Index in preparation for implementing search

Challenges I Faced

Most of my time was spent troubleshooting.

While integrating Swagger for API documentation, I initially experimented with Spring Boot 4.1.0. However, I later discovered that some of the libraries and examples I was following weren't fully compatible with the newer version.

After investigating the issue, I decided to use this Springdoc OpenAPI dependency:

<dependency>
    <groupId>org.springdoc</groupId>
    <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
    <version>2.8.9</version>
</dependency>

After making that change, the Swagger UI loaded successfully and I was able to continue developing the application.

I also encountered a routing issue while trying to redirect the application's home page to the Swagger UI. Initially, the redirect wasn't working because the routing logic was mixed with my API endpoints.

The fix was to move the routing logic into a dedicated HomeController and annotate it with @Controller instead of @RestController. This allowed Spring MVC to process the redirect correctly and display the Swagger UI as intended.

Although these issues slowed my progress, they helped me better understand dependency compatibility, request mapping, and how Spring MVC handles page navigation. By the end of the day, I had a much stronger understanding of how the framework works behind the scenes.

Application Running Successfully

Day 15: Implementing Search with MongoDB Atlas Search

On Day 15, I continued building the backend for my Job Posting Application by implementing search functionality using MongoDB Atlas Search. This was my first time working with Atlas Search, and it gave me a better understanding of how modern search features are built in NoSQL applications.

What I Learnt and Explored

Implementing search using MongoDB Atlas Search
Sorting search results
Limiting search results for better performance
Understanding where Client-Side Field Encryption fits into MongoDB applications
Working with MongoDB aggregation pipelines

Challenges I Faced

Before I could continue implementing the search feature, I discovered that my project had stopped working because of changes I had made while experimenting with different configurations.

Instead of trying to fix everything blindly, I decided to use Git to roll the project back to my last stable commit. This allowed me to compare my changes, identify what had gone wrong, and continue development from a working version.

After restoring the project, I encountered a few integration issues while implementing MongoDB Atlas Search. Most of them were related to configuring the search query correctly and making sure my application communicated properly with MongoDB.

Although I spent more time debugging than expected, the experience reinforced an important lesson: version control isn't just for collaborating with others—it's also one of the best debugging tools a developer can have.

By the end of the day, I had successfully implemented search, sorting, and result limiting, giving my Job Posting Application a much more practical search experience.

Goals for Week 4

As I head into Week 4 of this journey, these are the goals I've set for myself:

Complete the core features of my Job Posting Application
Build a fully functional search experience using MongoDB Atlas Search
Develop the frontend with React and connect it to the backend
Continue strengthening my understanding of Spring Boot and MongoDB
Learn more about securing backend applications and API best practices
Keep documenting my journey and sharing what I learn

Week 3 reminded me that software engineering is just as much about solving problems as it is about writing code. From debugging Spring Boot issues to learning MongoDB Atlas Search and starting a brand-new project, every challenge made me a more confident developer.

I hope the work I'm putting in today eventually leads to the opportunities I'm working so hard for. Until then, I'll keep building, learning, and improving every day.

If you're also learning, building, or growing in tech, I'd love to connect and follow your journey too.

Let's keep building. 💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

My Second Week of #100DaysOfCode: Learning, Building, and Creating Opportunities

Onatade Abdulmajeed — Sun, 28 Jun 2026 20:42:09 +0000

Introduction

A few weeks ago, I started the #100DaysOfCode challenge, and I'm beginning to understand why so many developers recommend it.

Week 1 was all about laying the foundation. I spent hours debugging my Spring MVC application, fixing configuration issues, and realizing that progress in software engineering often comes from solving problems rather than writing new code.

As I stepped into Week 2, things started to shift. I spent less time fighting bugs and more time learning new concepts, building projects, and being intentional about my growth. Instead of simply following tutorials, I found myself thinking more about how everything fits together and how I can become a better software engineer.

"Make it work, make it right, make it fast."

— Kent Beck

Day 4: Applied for a Job Role

One of the biggest moments of Week 2 happened on Day 4.

My mentor shared the Junior Backend Engineer opening at Chowdeck and encouraged me to apply. I submitted my application, but I didn't stop there.

I wanted to give myself a better chance of being noticed, so I decided to go the extra mile. I recorded a short introduction video where I talked about who I am, what I've been learning, and why I believed I would be a good fit for the role.

After that, I reached out directly to the CEO, CTO, and a Technical Lead with a personalized email and included the video as part of my introduction.

Although I haven’t gotten a response yet and don’t know what the outcome will be, I’m proud that I took the initiative. I just hope they reply soon.

Day 5: Exploring Spring Boot Data JPA

On Day 5, I focused on Spring Boot Data JPA and started understanding how it simplifies working with databases compared to the traditional Spring Framework.

What i Learnt and Explored

Spring Boot Data JPA configuration
JPA Repositories for saving and retrieving data
Query DSL (findBy...) for generating queries automatically
Custom queries using the @Query annotation
REST fundamentals and how applications communicate through APIs

Challenges I Faced

Although I spent less time debugging this week, I still ran into one issue while configuring Spring Boot Data JPA.

When I tried running the application, Hibernate failed to start and threw the following error:

Caused by: java.lang.ClassNotFoundException:
Could not load requested class: org.hibernate.dialect.MySQL5Dialect

I initially configured the application to use org.hibernate.dialect.MySQL5Dialect. After checking the Hibernate documentation, I realized that this dialect is no longer recommended for newer Hibernate versions.

The fix was simply to update the configuration to use the generic MySQL dialect instead:

spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQLDialect

After making that change, the application started successfully and I was able to continue learning.

Application Running Successfully

Day 6: Learning Docker

Day 6 didn't go exactly as planned because there was no electricity till the end of the day. Even so, I didn't want to break my streak of posting.

Since I couldn't spend much time coding, I decided to continue learning Docker and strengthen my understanding of containerization.

Some of the concepts I explored:

Image tagging
Docker Hub
The difference between docker run and docker compose
Commonly used Docker commands

Challenges I Faced

There weren't any major technical challenges today. The biggest obstacle was simply not having enough time due to the power outage.

Instead of calling the day a loss, I decided to focused on learning concepts that didn't require me to build a full project.

Day 7: Understanding REST APIs

On Day 7, I dived my focus to understanding how Spring Boot handles data in REST APIs more.

Some of the concepts I explored:

REST methods (GET, POST, PUT, and DELETE)
Using Jackson to convert Java objects into JSON
Working with @PathVariable to capture values from the URL
Returning XML responses with Jackson XML
Understanding the produces attribute
Using @RequestBody and the consumes attribute to handle request data

Challenges I Faced

Unlike on Day 5, I didn't run into any major issues while following along.

I was able to understand the concepts, implement them successfully, and spend more time learning. This made me realize that the hours I spent debugging in Week 1 are starting to pay off.

The Result

By the end of the day, I had more understanding of how Spring Boot handles requests and responses in REST APIs.

Learning how JSON conversion, request handling, and HTTP methods work together gave me a better picture of how backend applications communicate with clients, and it's another step toward becoming a more confident backend developer.

Application Running Successfully

Day 8: Learning from the Spring Community

While scrolling through LinkedIn, I came across a post from Naija JUG announcing a live Spring Boot session featuring Josh Long, Spring's first Developer Advocate. Since I'm currently learning Spring Boot, I knew I couldn't miss the opportunity to hear directly from someone who has contributed so much to the Spring ecosystem.

Naija JUG Announcement

The session covered the Spring ecosystem, some of the latest features in Spring Boot, and included a live coding demonstration that was both insightful and inspiring.

Josh Long During the Session

Some of the things I learned:

A broader view of the Spring ecosystem
New features and improvements in Spring Boot
An introduction to GraalVM and its role in Spring applications
Best practices from an experienced Spring Developer Advocate

It was inspiring to hear directly from someone who has contributed so much to the Spring ecosystem. Watching him code live reminded me how much there is still to learn, and it motivated me to keep improving one day at a time.

Challenges I Faced

There weren't any technical challenges. The only challenge was simply keeping up with the live coding session because Josh Long moved incredibly fast 😅.

Even though I couldn't follow every line of code in real time, I learned a lot by watching how he approached problems and explained different concepts.

One day, I hope to code with that level of confidence and speed too.

Goals for Week 3

As I head into Week 3 of this journey, these are the goals I've set for myself:

Continue strengthening my Java and Spring Boot fundamentals
Complete my Product Management Console App and rebuild it as a Spring Boot application
Build more backend projects with less reliance on tutorials
Continue learning Docker and deployment concepts
Keep improving my problem-solving skills by building consistently
Continue documenting my journey and sharing what I learn

Week 2 taught me that growth isn't just about writing more code. It's about staying consistent, learning from others, putting yourself out there, and building one step at a time.

I'm excited to see what Week 3 has in store.

If you're also learning, building, or growing in tech, I'd love to connect and learn from your journey too.

Let's keep building.💙

LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/

X (Twitter):
https://x.com/spider337761

DEV Community: Onatade Abdulmajeed

Week 14 of #100DaysOfCode: Completing JUnit 5 and Starting a New Portfolio

Introduction

Day 87: Going Deeper into JUnit 5

Understanding the Test Lifecycle

Test Instance Lifecycle

Working with Assertions

Organizing Tests with @Nested and @Tag

Conditional Test Execution and Assumptions

Repeated Tests

Disabling Tests

JUnit 4 Migration Support

What I Learned

Day 88: Exploring Advanced JUnit 5 Features

Dependency Injection in JUnit 5

Dynamic Tests

Sharing Test Semantics with Java Interfaces

Test Templates

Parameterized Tests

Argument Providers

Argument Conversion

Custom Parameterized Test Names

What I Learned

Day 89: Integrating JUnit 5 with External Frameworks

Understanding the JUnit 5 Extension Model

Mockito and Mocking

JUnit 5 and Spring

Selenium and UI Testing

Cucumber Integration

Testing REST APIs

Testing Docker Containers

Android Application Testing

What I Learned

Day 90: Revising Test Case Design and Testing Management

Revisiting Test Case Design

Test Planning

Test Fixtures

Equivalence Partitioning

Boundary Value Analysis

Code Coverage

Testing Management

Test-Driven Development

Behavior-Driven Development

Continuous Integration

Testing Pipelines

Test Reporting and Defect Tracking

What I Learned

Day 91: Completing My JUnit 5 Journey

What I Learned

Moving Forward

Day 92: Starting a New Portfolio

Starting with the Foundation

Next.js and Tailwind CSS

Adding Motion

Starting Docker

What's Next?

Goals for Week 15

Connect With Me

Week 13 of #100DaysOfCode: Completing Spring Microservices and Starting JUnit 5

Introduction

Day 80: Beginning Docker and Containerized Microservices

What I Learned

Day 81: Containerizing Microservices with Docker

What I Learned

Day 82: Scaling Dockerized Microservices with Mesos and Marathon

What I Learned

Day 83/100

Day 84/100

What I Learned

Day 85: Going Deeper into Software Testing with JUnit 5

What I Learned

Goals for Week 14

Connect With Me

Week 12 of #100DaysOfCode: Exploring Spring Cloud and Microservices Infrastructure

Introduction

Day 73: Starting Spring Cloud

What I Learned

Day 74: Exploring Spring Cloud Config and Service Discovery

What I Learned

Day 75: Exploring Service Discovery and API Gateways

Organizing Tests with `@Nested` and `@Tag`