DEV Community: Rodrigo De Lascio

From Diagram to Cloud: Designing a Real Cloud Architecture Without Melting My Brain

Rodrigo De Lascio — Fri, 30 Jan 2026 19:46:17 +0000

After building a full PHP web application for my Web Application Development module, my Distributed and Cloud Computing module decided it was time to zoom out.

Instead of writing code, I had to design the entire infrastructure that would host a real-world system. Servers, networks, security, storage, monitoring, backups. The whole thing.

The system in question was an online discussion forum for a fictional organisation called Nutriworld.

The Problem to Solve

The forum needed to be publicly accessible, secure, scalable, and cost-aware. This was not about building a global platform on day one. It was about designing a proof of concept that could grow safely over time.

High-Level Architecture

The system follows a layered cloud architecture:

Public entry point via an Application Gateway
Private application tier
Managed database
Object storage for user content
Monitoring and backup services

Traffic flows through a single controlled ingress point before reaching any application resources.

Platform and Deployment Choices

Microsoft Azure was used as the cloud platform.

The design combines Infrastructure as a Service for the application server with managed services for data storage. This balances control and operational simplicity.

Networking and Security

All resources live inside a Virtual Network with dedicated subnets for the gateway, application server, and database.

The application server has no public IP address. Access is restricted through the gateway and reinforced using Network Security Groups with a default deny approach.

Application Gateway and WAF

The Application Gateway provides HTTPS termination, routing, and Web Application Firewall capabilities.

For the prototype, the WAF operates in detection mode, logging suspicious traffic without blocking it. This allows observation without disrupting legitimate users.

Application Tier

The forum application runs on a Linux virtual machine using Ubuntu Server LTS.

The VM size is intentionally modest, sufficient for a prototype and easy to scale later if required.

Data Layer

Forum data is stored in Azure Database for MySQL Flexible Server.

Using a managed database reduces operational overhead while providing built-in patching, backups, and resilience.

Storage for User Content

User uploads are stored in Azure Blob Storage, keeping large files separate from the application server and allowing independent scaling.

Monitoring and Backups

Azure Monitor is used for metrics and alerting.

Database backups are enabled by default, and virtual machine backups are identified as a future enhancement once provisioning constraints are removed.

Constraints and Reality

Some resources could not be fully provisioned due to subscription limitations. These constraints are documented clearly, with intended configurations explained.

Architecture is about intent as much as implementation.

What This Assignment Taught Me

This project reinforced the importance of system thinking, trade-offs, and documentation.

It pushed me to think beyond code and focus on reliability, security, and evolution over time.

Final Thoughts

This architecture is not flashy, but it is sensible, secure, and realistic.

And that feels like the right direction to be heading in.

RodFlix Deep Dive: The PHP App That Taught Me Patience

Rodrigo De Lascio — Sun, 18 Jan 2026 20:06:26 +0000

This week’s blog is a technical deep dive into my Web Application Development assignment, where I built RodFlix, a TV series catalogue web app in PHP, backed by MySQL, with an admin panel and an import flow using the TVmaze API.

It is basically IMDb’s smaller cousin, the one who does not go to the gym but has great database design and tries really hard.

What RodFlix Does

RodFlix is a database-driven TV series catalogue where users can browse series, explore seasons and episodes, and view people involved in each show. Pagination and filtering help manage larger datasets.

There is also a protected admin area that supports full CRUD over series and allows importing data directly from the TVmaze API.

Architecture and Structure

The app uses a lightweight, layered structure with server-rendered PHP, MySQL for data storage, and clean separation between public pages, admin pages, and API endpoints.

Key directories include:

/includes for configuration, authentication, database connection, and helpers
/admin for dashboard and CRUD interfaces
/api for JSON endpoints used by the admin UI
/assets for CSS, JavaScript, and images

No frameworks, no magic, just disciplined PHP.

Database Design

RodFlix uses a relational schema with tables for series, seasons, episodes, genres, people, and junction tables to model many-to-many relationships. Foreign keys and cascading deletes help maintain data integrity.

This approach avoids duplication and keeps queries readable and scalable.

Data Access and Security

Database access is handled via PDO with prepared statements. This protects against SQL injection and keeps queries consistent across the application.

A shared database helper returns a single PDO instance, avoiding unnecessary reconnections.

Authentication and Sessions

The admin area is protected using session-based authentication. Session IDs are regenerated on login, admin routes are protected server-side, and navigation adapts based on authentication state.

Simple, predictable, and secure.

The TVmaze Import Flow

One of the strongest features is the ability to search for series via the TVmaze API, preview results, and import them into the local database.

This is handled through dedicated API endpoints and JavaScript fetch calls, keeping the UI responsive while maintaining server-side control.

Helpers and Reusability

Helper functions centralise common tasks like escaping output, redirects, query parameter validation, and formatting.

These small utilities reduce repetition and improve long-term maintainability.

What This Project Taught Me

This project went beyond learning PHP. It reinforced real-world skills like:

Designing relational databases
Writing safe SQL queries
Structuring maintainable projects
Managing authentication and access control
Integrating external APIs responsibly

It also taught me that server-side debugging is a special kind of endurance sport.

Final Thoughts

RodFlix started as an assignment but became a solid foundation project. It is not flashy, but it is structured, secure, and realistic.

And honestly, that feels like a good metaphor for my journey into software development.

Back From the Deadlines: What I’ve Been Up To

Rodrigo De Lascio — Sat, 10 Jan 2026 20:36:33 +0000

So. It has been a while.

If this blog had a heartbeat monitor, it probably flatlined for a bit. Not because I disappeared or lost motivation, but because life decided to turn every dial up at once.

Short version: I have been very busy.

Long version: keep reading.

University: The Final-Year Olympics

I am now officially in my last year at university, which sounds exciting and terrifying in equal measure.

Since my last post, I have completed two modules:

Data Mining
Managing Innovation and Change

On top of that, I am in the final week of two more modules:

Web Application Development
Distributed and Cloud Computing

For Web Application Development, I built a TV series database application using PHP for the first time. PHP and I are now on speaking terms. Not best friends yet, but we no longer avoid eye contact. That project also came with a long report.

For Distributed and Cloud Computing, I designed a cloud architecture for a forum system in Azure. Virtual machines, storage, networking, security considerations, scalability, and many diagrams. The design was challenging, but the report writing is where the real endurance sport lives.

The Final Project: Football Meets Code

I have also released my Final Project module, been assigned a supervisor, submitted a proposal, revised it, and finally got it approved.

The project is a football attendance tracker app aimed at helping community football organisers manage attendance and allocate spaces automatically using an algorithm. It is still in its infancy, but it is exciting to build something that improves something I genuinely love.

Work and Late Nights

Work has also levelled up. Since mid last year, I have taken on more responsibility, which means study time now lives almost entirely at night.

Work during the day. Family in the evening. University at night.

Coffee has become less of a beverage and more of a strategy.

Family and Two Labs

Family life is great. My wife and kids are doing well, and we added two labrador puppies, Beca and Lola. They are five months old, full of energy, and completely uninterested in study schedules.

They are adorable chaos.

Why the Blog Went Quiet

The blog went quiet not because I stopped caring, but because sometimes progress looks like meeting deadlines, finishing assignments, and keeping everything running without breaking.

This blog has always been about honesty, humour, and the long game. That has not changed.

Back at It

I am back now. Still tired. Still learning. Still motivated.

There is more to come. More reflections, more tutorials, and more stories from the intersection of career change, study, and building meaningful things with code.

Glad to be back.

The Developer’s Dictionary: Workplace Edition

Rodrigo De Lascio — Fri, 12 Sep 2025 13:44:20 +0000

Last blog I shared my “Developer’s Dictionary” and it hit a nerve. Translating dev jargon into real-life metaphors makes a lot of sense, even outside of code. Someone even told me they were going to start adding one-line translations to tickets and onboarding docs. Honestly, that’s brilliant.

So this week I thought, why stop at code? The workplace has its own dictionary too. It is full of phrases that everyone nods at while secretly translating in their heads. Here’s my attempt at decoding some of them.

It’s a quick fix

Prepare your snacks. This will take all afternoon.

We’ll circle back

Also known as: goodbye forever.

In progress

Currently stuck in Stack Overflow tabs and caffeine dependency.

Low priority

We will rediscover this ticket only when the system is on fire.

Let’s refactor later

We both know this means “never.”

Blocked

Waiting for someone else to do their thing while practising the fine art of pretending to look busy.

End of day

Technically midnight, if you really think about it.

Knowledge transfer

One person explains everything at double speed while the other nods and quietly panics.

As discussed

The polite way of saying “we already argued about this and I won.”

Best practices

What we would do if we had unlimited time, unlimited people, and unlimited coffee.

Action item

A task born in a meeting and destined to die there too.

Dev Team Translations

Works on my machine

Translation: this code is haunted.

We just need to add a small feature

Welcome to scope creep. Please enjoy your stay.

Technical debt

The loan sharks of the coding world. They always collect, with interest.

Hotfix

Code written at the speed of light, usually in production, often regretted immediately.

Code review

Where colleagues politely tell you your baby is ugly.

Production

The sacred environment where everything works perfectly, until you touch it.

Closing Thoughts

The workplace dictionary is just as full of hidden meanings as the code one. The words might sound harmless, but once you have lived through a few sprints, you start to hear the truth behind them.

Maybe we should start adding the real-life translations directly into Jira tickets and PR comments. At least then everyone would finally be on the same page.

The Developer’s Dictionary (Rodrigo Edition)

Rodrigo De Lascio — Fri, 29 Aug 2025 12:27:51 +0000

Every profession has its own jargon. Football has “nutmegs,” marketing has “KPIs,” and developers… well, we have enough strange terms to make a newcomer think we’re summoning code spirits.

Here’s my attempt at translating some of the words we use into real life.

Bug

A feature’s evil twin. Shows up uninvited, often just before a deadline, and somehow multiplies when you try to squash it.

Debugging

Staring at your screen for three hours until you finally notice the missing semicolon that has been mocking you the whole time.

NullPointerException

The universe’s way of saying: “You thought something was there. Surprise, it’s nothing.”

IDE

Your noisy but helpful friend who won’t stop pointing out your mistakes while you’re typing. Annoying, but usually right.

Garbage Collection

Java cleaning up after your messy variables, like a silent roommate who tidies when you’re not looking.

Dependency Hell

When adding one library drags ten others into your project, like inviting one friend to a party and suddenly the whole neighbourhood shows up.

Compile Time vs Run Time

Like rehearsing your lines at home versus performing on stage. Everything seemed fine, until panic sets in.

Encapsulation

Putting your code in little boxes so it behaves. Like packing your kids’ toys away so they don’t take over the living room.

Polymorphism

Objects that can take many forms. Imagine one person being a footballer, a developer, and a coffee drinker all in the same morning.

Stack Overflow

Yes, it’s a real error. But also the site where 90% of developers copy-paste their answers. The other 10% just Google it differently.

Refactoring

Cleaning up code without changing what it does. Basically tidying your room so you can finally find the socks… even though it was technically functional before.

Documentation

The noble art of explaining your code. Sometimes thorough, sometimes cryptic, and often written as if the author was in a hurry to catch a bus.

Closing Thoughts

Developers might speak in jargon, but once you translate it into real-life metaphors, it all makes sense. Sort of. At least until you hit your next bug.

If nothing else, this dictionary proves one thing: coding is a language of its own. And like any language, the best way to learn it is to laugh at the strange words until they finally start to click.

Scanner Class in Java: Making Your Program Listen to You

Rodrigo De Lascio — Fri, 08 Aug 2025 14:40:08 +0000

One of the coolest moments when learning Java is making your program interact with you. Until now, your code has been shouting into the void with System.out.println() statements, and the void (a.k.a. your console) has been silently nodding.

But what if you could make your program listen? Enter the Scanner class, Java’s way of turning your static program into a two way conversation.

Step 1: Import the Scanner Class

Before you can use Scanner, you have to invite it into your code. Think of this as adding someone to the group chat before you start sending them memes.

import java.util.Scanner;

Without this line, your program will stare at you blankly when you try to use Scanner.

Step 2: Create a Scanner Object

To make your program listen, you create a Scanner object. This is like giving your code a pair of ears.

Scanner input = new Scanner(System.in);

Scanner = the type of object you are creating
input = the name you choose (you can call it keyboard, scanner, or even earholes, but maybe keep it professional)
System.in = tells Java you want to take input from your keyboard

Step 3: Ask the User Something

Now your program is ready to listen, but it is polite to ask first. Use System.out.println() to prompt the user.

System.out.println("What is your name?");

Step 4: Capture the Input

When the user types something and presses Enter, you can store it in a variable. For a full line of text, use nextLine().

String name = input.nextLine();

Now whatever the user typed is saved in the variable name. You can use it anywhere in your program.

Step 5: Respond Like a Chatty Friend

Finally, use that input to make your program respond.

System.out.println("Hello, " + name + "! Nice to meet you.");

Full Example

import java.util.Scanner;

public class Greeting {
    public static void main(String[] args) {

        Scanner input = new Scanner(System.in);

        System.out.println("What is your name?");
        String name = input.nextLine();

        System.out.println("Hello, " + name + "! Nice to meet you.");

        input.close();
    }
}

Pro Tips

Always close your Scanner with input.close() when you are done. It is like hanging up the phone politely.
For numbers, use nextInt() or nextDouble() instead of nextLine().
If things get weird (like nextLine() skipping inputs), it is probably because Scanner is still holding on to leftover input from before. It can be clingy, so you might need to add an extra nextLine() to clear the buffer.

Final Thoughts

Scanner is one of the first tools that makes your Java programs feel alive. It lets you collect information, personalise output, and generally be less of a monologue.

Next step? Combine it with conditionals and loops, and suddenly you have a program that not only listens but also makes decisions. Just do not let it get too smart, because that is how sci-fi movies start.

Coding Is Easy (If You Ignore Reality)

Rodrigo De Lascio — Fri, 01 Aug 2025 09:34:00 +0000

There’s this beautiful moment every beginner goes through: the tutorial high. You follow along with someone on YouTube who writes perfect code, everything compiles, and by the end of the video, you’ve built a to-do list app that works flawlessly. You look at your screen and think, “Coding is easy. I’ve got this.”

I did too. For about five minutes.

Then I started coding on my own.

When Tutorials Lie by Omission

No one tells you that tutorials are basically the IKEA manuals of the coding world. They show you what to do but skip the part where you’re on the floor surrounded by errors, wondering if semicolons have feelings and whether your IDE is gaslighting you.

Everything works in tutorial land. The instructor’s code is bug-free, and they never seem to hit the wall of “Why is this not compiling when it’s the same code?!”

The real world, even when you’re not yet working in a dev team, is messier. It’s one thing to copy and paste your way to a working project. It’s another to write something from scratch, debug it, understand what you’re doing, and try not to spiral when nothing makes sense.

Welcome to the Solo Dev Zone

As someone learning to code outside a traditional dev team or tech job, the learning curve is steep and oddly personal. It’s just you, your code, and the occasional existential crisis.

There’s no one to nudge and say, “Hey, does this look right?” You end up talking to your action figure (or in my case, a stressed-out coffee mug) and hope your question makes sense when you read it out loud.

The smallest bugs feel like boss battles. You forget a bracket and Java punishes you like you’ve personally offended it. You fix one thing and suddenly ten other errors show up like they’ve been waiting backstage.

But eventually, something clicks. You understand encapsulation a little better. Your UML diagram starts to resemble less of an abstract painting. You stop avoiding the terminal. Well, mostly.

Not Just Code, But Feelings

Let’s talk about the emotional weight of it all. You scroll through job posts and see “Junior Developer... 3 years experience required” and laugh, but also cry (internally, of course). You open LinkedIn and see someone announcing they’ve built a mobile app, landed a job, took part in a triathlon and somehow also climbed Everest last weekend.

Meanwhile, you’re over here just proud you got your switch statement to behave.

And then there’s the silence. The solo learning journey is full of it. No peers to share victories with. No one to say “yeah, this part is confusing” in real time. Just you and your thoughts, and maybe an overloaded bookmarks folder filled with Stack Overflow threads or distant learning uni lessons to read and lean on.

But Still… Worth It

For all the confusion, the late nights, and the tabs that multiply like gremlins, there’s this undeniable spark when something finally works.

That program that wouldn’t compile for hours? It runs.
That concept that felt like reading ancient Greek? You understand it now.
That feature you thought was too advanced? It’s part of your project.

You realise you’re not stuck. You’re learning. Progress isn’t linear, but it’s happening.

And no, coding isn’t easy. But it gets easier the more you embrace the reality instead of the illusion.

Final Thoughts

Coding might be presented like a walk in the park, but in reality it’s a trek through a jungle with a half-charged phone, a map that updates inconsistently, and a compass that only works if you know trigonometry.

Still, I wouldn’t trade it. Because with each line of code, each bug fixed, and each meltdown survived, I’m getting closer to where I want to be.

Even if the IDE still occasionally tries to ruin the day.

Next week: who knows. Maybe I’ll get back to Java. Or maybe I’ll compare version control to parenting. Either way, bring snacks.

Lessons From Building My Blog (and Finding My Voice)

Rodrigo De Lascio — Wed, 23 Jul 2025 09:50:23 +0000

I have been writing for a long time, not as a journalist despite earning a BA in Journalism back in 2006, but as a content writer. For years, I wrote marketing copy and professional blogs about sports and casinos, the kind of content that had to sound smart, persuasive, and just serious enough to make you click. It paid the bills, but it wasn’t me.

When I started this blog, I realised I wasn’t just documenting my journey as a career-changing developer. I was also rediscovering my own voice, which had been buried under a mountain of corporate jargon and “Top 10 Casino Tips” posts.

Writing for Myself vs. Writing for the Algorithm

For most of my career, I wrote to please someone else: clients, bosses, and the SEO overlords at Google. Every sentence was carefully tuned to hit keywords or a specific tone that wasn’t mine.

This blog has been my way of saying: forget that. I wanted to share my journey in my own words, with my humour, my personality, and sometimes my rants about curly braces. The feedback I’ve had so far? People connect with authenticity, even in tech blogs.

Coding Made My Writing Better (Wait, What?)

Writing a blog about coding has taught me to think like a developer when I write:

Structure first, details second.
Debug your sentences. Cut out the unnecessary fluff.
Iterate. Draft, edit, rewrite, and then rewrite again because the first draft is always messy.

The parallels between writing and coding surprised me. Both are about solving problems and making sure your work is clear enough that someone else can “run it” without asking too many questions.

Humour Is My Secret Weapon

When I was writing sports or casino content, I couldn’t throw in jokes about goalkeepers or slot machines. Everything had to feel polished and professional.

Here, I get to be me. I can write about Java as if it’s a dysfunctional family, or compare debugging to football training drills. And it works. It keeps me engaged, which makes it more fun for anyone reading.

Why I Think Every Dev Should Blog

Not because it will make you famous (spoiler: it won’t), but because writing about your journey forces you to:

Reflect on what you’ve learned.
Explain complex ideas in simple terms, which is a superpower in interviews.
Showcase your personality beyond your GitHub repos.

Plus, when you write in your own voice, you stand out. There are enough soulless coding blogs out there.

The Biggest Lesson: Your Voice Evolves

I didn’t find my tone overnight. The first posts on this blog were stiff and cautious, a ghost of corporate Rodrigo. Over time, I started relaxing, letting my humour and personality seep into my writing. It’s become not just a blog, but a personal development diary and a portfolio of sorts.

I’m not saying I’m the Shakespeare of Java tutorials, but I’ve definitely built something that feels like me.

Closing Thoughts

Building this blog taught me two things:

Writing can be as much about self-discovery as it is about sharing knowledge.
When in doubt, add a joke about coffee. It works every time.

Next week? Maybe I’ll get back to Java. Or maybe I’ll just keep writing about this wild journey of coding, content, and career change. We’ll see.

The Entry-Level Boss Fight: Breaking Into Tech When the Queue's Already Full

Rodrigo De Lascio — Thu, 17 Jul 2025 10:59:17 +0000

There’s something oddly humbling about clicking “Apply” on a junior developer role and seeing that delightful little note:

“100+ applicants.”

Oh good, I love a challenge. Said no one ever while competing with an army of hopefuls all battling for the same entry-level badge.

This week, I’m stepping off our usual blog schedule to reflect on something that’s been on my mind lately: the uphill battle of breaking into the tech industry when everyone and their algorithms seem to be ahead of you.

The Queue at the Door

Every junior, graduate or entry-level tech job I find seems to be hosting a small applicant festival. Whether it’s web development, front-end, back-end, or full-stack, it’s always the same: lots of enthusiasm, not enough chairs.

Post-pandemic, the job market shifted. People with experience found themselves laid off, and naturally, they started applying for roles one rung lower than before. At the same time, a tidal wave of new talent (yes, including myself) emerged from bootcamps, self-study, and university courses, eager to make their mark.

Suddenly, that “entry-level” tag became a bit of a myth, like Bigfoot, or a coffee machine that doesn’t leak.

Enter the Machines

Let’s not forget the growing presence of AI tools. While they can be helpful, they’ve also shifted the landscape. Companies are questioning how many devs they really need, and what tasks can be “prompt engineered” into existence instead.

It adds another flavour to the already spicy stew of competition. But those of us willing to understand, adapt, and use these tools smartly will have an edge over those who don’t. The game may have changed, but there’s still room to win it.

Nearing a Turning Point

Personally, I’m approaching a big milestone: the final year of my university degree. That magical time when those elusive “graduate” jobs start to open their gates. It’s a decisive chapter in my career change journey, one I’ve worked incredibly hard for, balancing family life, a day job, studies, and a healthy amount of coffee.

I’m still applying for roles. Still putting myself out there. Still getting ghosted by job ads that claimed they were “excited to hear from passionate life-long learners.”

But Hope Isn’t a Strategy (So I’m Also Working Hard)

I’m not here to just moan. I knew this wasn’t going to be easy. I chose this path knowing I’d have to prove myself more than once. So I keep learning, building, writing this blog, refining my portfolio, and being active in the community. Hope is the spark, but hard work is the fuel.

And honestly, I’m proud of that. I might not be through the door yet, but I’ve knocked. Loudly. Repeatedly. With increasingly better-looking CVs.

Final Thoughts

If you’re also trying to get in, feeling discouraged or burnt out, I get it. It’s tough out there. But keep going. Keep learning. Keep improving.

Our time will come, and when it does, we’ll be more than ready.

Next time, we’ll jump back into the Java OOP saga with abstraction: that mystical art of telling your code, “Don’t worry about how, just know that it works.”

Interfaces: Job Interviews for Your Classes

Rodrigo De Lascio — Fri, 11 Jul 2025 13:47:03 +0000

This week, we're diving into the elegant, expectation heavy world of interfaces in Java. If you thought classes were demanding, wait until you meet interfaces. They're like job interviewers: they don’t care what you’ve done before, they just want to know if you implement the right methods.

And yes, I know I teased abstraction last week, but let’s be honest, this blog got intercepted by an interface halfway through and demanded I implement this one first. So, here we are.

What Even Is an Interface?

An interface in Java is basically a contract. It says: “If you're going to be this kind of thing, then you must do these things.” It's like your class saying, "Sure, I can be printable," and then Java going, "Prove it. Write the print() method."

Interfaces don't care how you do something, they just demand that you do it. No explanations. No excuses. Just methods.

Real World Analogy: The Interview Panel

Think of an interface like a job description. When your class 'applies' for the job (implements the interface), it has to promise that it can do every task listed in that job spec.

For example:

java
public interface Employable {
    void submitCV();
    void attendInterview();
    void drinkNervousWater();
}

public class JuniorDev implements Employable {
    public void submitCV() {
        System.out.println("CV submitted in Comic Sans");
    }
    public void attendInterview() {
        System.out.println("Nailed it. Sweated slightly");
    }
    public void drinkNervousWater() {
        System.out.println("Accidentally spilled it on the interviewer");
    }
}

How I Used It in My Assignment

In my Media Diary project, I created a Comparer interface to define how different comparison strategies could be plugged in. One implementation (CompareByPurpose) looked at how much time users spent on educational media. That interface basically said, “Hey class, can you compare stuff?” and the class replied, “Absolutely. Hold my curly braces.”

Why Interfaces Are Useful

Flexible design: Classes can implement multiple interfaces. It’s Java’s way of letting you have more than one personality, officially.
Decoupling: You can write code that relies on the interface without knowing the exact class. It’s like trusting someone to cook without knowing whether they use gas or induction.

Quick Notes

Interfaces can't have method bodies (unless you're using default methods, but let’s save that rabbit hole for another post).
A class can implement many interfaces.
Think of them as the opposite of clingy: interfaces tell you what they want, but never how to do it.

Final Thoughts

Interfaces are that polite yet persistent part of Java that remind you to keep your promises. You say you can compare? You’d better write that method. You say you can fly? Better implement takeOff().

Next time: abstraction, the mysterious concept that only shows you the surface, like a duck gliding calmly while paddling like mad underneath.

Until then, keep your methods public, your classes clean, and your nervous water far from the keyboard.

Objectively Speaking: What Building a Media Diary in Java Taught Me (Besides Patience)

Rodrigo De Lascio — Sat, 05 Jul 2025 16:21:30 +0000

This week’s blog is dedicated to the unsung hero of my university life right now: my Object-Oriented Programming (OOP) assignment. I’ve spent a good chunk of the past week inside VS Code (although NetBeans or IntelliJ would the top choice for this one, requirements told me otherwise), slowly sculpting a Media Diary application in Java while also trying not to melt into a puddle of Boolean confusion.

Let’s just say... the caffeine intake was high, the bugs were stubborn, and the victory dances after a successful build were plentiful (if not entirely graceful).

The Assignment

The brief? Design and build a Java application that allows users to track their media consumption across a week. Think TV shows, books, video games, podcasts... basically, all the ways we avoid doing our chores.

The app had to include good class design, proper encapsulation, and thoughtful use of inheritance, interfaces, and abstraction. So, I did what every determined developer does when faced with such a challenge: opened a fresh Java file and whispered “let’s do this” to the void.

Building Blocks

The application is built around several core classes:

User: the person doing the watching/reading/gaming
MediaDiary: a container for that week’s entries
MediaEntry: the abstract parent of various specific entries like BookEntry, TVShowEntry, and GameEntry
TimeTracker: because someone had to do the maths
Comparer: an interface that allows for different comparison strategies (e.g. time spent, purpose of media)

After many UML diagram drafts (some with more arrows than a medieval battle), I finally landed on a structure that made sense and didn’t make my IDE weep.

Features I’m Proud Of

Comparison Logic: I implemented a comparer interface with a concrete class CompareByPurpose that tells you who watched more “Educational” content. Spoiler: it wasn’t me.
Encapsulation Done Right: All the juicy details are private, accessed neatly via getters and setters.
Flexible Design: Thanks to interfaces and abstract classes, adding new media types or comparison strategies won’t break the whole app. Probably. I think. I am confident. Fairly.

Lessons Learned

Planning Matters: The UML diagram wasn’t just for decoration. It helped shape my thinking and structure.
Java is Strict: Forget a semicolon? Java will let you know. Repeatedly.
OOP Principles Work: Encapsulation, inheritance, and polymorphism are more than buzzwords. They’re sanity-saving patterns.
Refactoring is Life: Just when I thought I was done, I wasn’t. But that’s okay. The evolution of the code is part of the process.

In Closing

While I’m still working on the final polish (and, yes, the report), I’ve learned a ton. This project challenged me but also gave me the satisfaction of seeing concepts I’d studied come to life in an actual application.

And don’t worry, I’ll write a proper post-mortem once the grades are in. For now, I’ll leave you with this thought: Java may be verbose, but when it works, it really works.

Next up: abstraction, the mysterious stranger in the OOP party who only tells you what you need to know.

Polymorphism in Java Explained (Or: One Type, Many Behaviours)

Rodrigo De Lascio — Fri, 27 Jun 2025 13:57:50 +0000

Ever felt like your objects needed to express themselves more? Enter: polymorphism in Java.

This week I finally got comfy with one of OOP’s most flexible (and misunderstood) concepts. Also, I’m building a Media Diary app for my uni assignment... 70% done and holding on to hope.

Let’s walk through the “why” and “how” of polymorphism with examples, real code, and the usual dose of developer humour.

What Is Polymorphism, Really?

In the world of object-oriented programming, polymorphism allows you to use a single interface to represent different underlying forms. In plain English? It’s the reason your code can treat different classes in the same way, as long as they share a common parent.

Let’s say you’ve got a few media types:

public class MediaEntry {
    public void displayInfo() {
        System.out.println("Generic media entry");
    }
}

public class BookEntry extends MediaEntry {
    public void displayInfo() {
        System.out.println("This is a book");
    }
}

public class GameEntry extends MediaEntry {
    public void displayInfo() {
        System.out.println("This is a game");
    }
}

Now, if you do this:

MediaEntry entry1 = new BookEntry();
MediaEntry entry2 = new GameEntry();

entry1.displayInfo(); // prints: This is a book
entry2.displayInfo(); // prints: This is a game

Boom. Polymorphism in action. One type, many behaviours.

Quick Uni Update: Media Diary in the Works

My OOP assignment at uni is now about 70% complete. Belief is what we have to hold on to, right? I’ve been building a full-featured Media Diary app using classes, objects, interfaces, and just the right amount of late-night debugging.

You might remember I mentioned the UML diagram a few blogs ago. Since then, I’ve been adding functionality like time tracking, media categorisation, and comparing user habits. It’s still a work in progress. The final post-mortem (I mean, blog post) will come when it’s finished. But for now: progress is being made.

Why Use Polymorphism?

Here’s why polymorphism is worth adding to your toolkit:

You can write flexible and reusable code
You reduce complexity by programming to interfaces
You make your code easier to extend without rewriting the old stuff

It also keeps your methods neat. For example, if you’re looping through a bunch of MediaEntry objects, you don’t need to know if one’s a book or a game. Java will call the right method for each one. Magic.

Final Thoughts

Polymorphism isn’t just a technical term, it’s a vibe. It lets your objects be who they need to be, when they need to be. It’s like method acting, but with less drama and more curly braces.

I’m starting to really appreciate how these OOP principles click together. It’s like assembling IKEA furniture: confusing at first, then suddenly, everything fits.

Next up: abstraction, where Java starts revealing just enough to keep things interesting, like a magician who never shows all their cards.