DEV Community: Gervin Guevarra

Event Streaming and Event Sourcing: which one do you use?

Gervin Guevarra — Wed, 31 Jan 2024 01:48:55 +0000

A couple of months back, I read this article explaining that event streaming != event sourcing

The understanding of these two has eluded me for years.

I first heard of it back in 2017 when my mentor was introducing DDD to me. In my head, I oversimplified it as a pub-sub pattern but with flair 😆

That mental model remained useful as I worked on a few event-driven applications. Some utilized it on the application tier while some applied it as a way to orchestrate microservices.

The “leitmotiv” article cited by the article above is something I’ve seen several times, and one I find myself agreeing with when I was working with architectures employing such. It is fancy. It seems elegant but it also introduces a lot of drawbacks. Add to that, it’s also a bit unintuitive versus a simple “let me handle that request, process it, write it to the database, here’s your response, and voila we’re done” -- very CRUD-y I suppose.

But it turns out, I was conflating the two terms 🤦
Looks like I’ve never tried event sourcing yet, and it's probably something I won’t be able to try anytime soon.
I’m a little skeptical about how replaying the events will scale. Granted, I didn’t read the additional articles the author shared (he has one for modelling event sourcing streams and keeping them short).

How about you? Have you tried event sourcing before? How was it?

And if not, will you ever try event sourcing?

Newbie Anew

Gervin Guevarra — Wed, 27 Dec 2023 13:48:08 +0000

I always tell people that “new things” make working in software development constantly exciting. And when I say new things, I just don’t mean bleeding-edge technology. I mean new problems, new approaches, or new patterns - even if they are just new to the person. What I have not told them is that with these exciting opportunities comes the nerve-wracking ordeal of facing unknowns.

When I was writing my 5th-year retrospect, I felt like I knew a lot. I thought I had already reached a certain level of mastery that would make me qualified to share my knowledge and experiences. And it was around the same time last year when I started a new job . That’s when I realized that I don’t know sh*t.

It was overwhelming, to say the least: different domain, tech stack, people, and culture. There were times when I felt dumb and undeserving to be there. Impostor syndrome perhaps? But…

Artist: Gemma Correll

And since it's time for a "year in review" post anyway, I sat down and look back at the struggles I had and the steps I’ve taken so far.

Unfamiliar Domain

I previously worked for a digital bank for 3 years, and I more or less became the de facto subject matter expert on a few of our microservices. While I did enjoy being the go-to person, I eventually hit a point where I began wanting to try something different.

Which brought me to my current job at an HR tech company.

I was excited of course, but I was not prepared to be hit like a truck. Many foreign concepts were being discussed during meetings and I found myself there sitting clueless.

What we devs rarely talk about is that half of our job is actually understanding the business domain. We would often talk about the latest, fastest, or most elegant tech stacks and patterns. But at the end of the day, what we really want is simply a software that delivers value to our users. And we can’t do that if we do not understand the contexts it will be used in.

To fill in these gaps, I had to ask a lot of who, what, where, when, and whys. Fortunately, my team was very understanding and welcoming. It took me some time until I gained some confidence. Until now, I don’t think I’ve already understood everything yet, but it was a significant progress from where I was a year ago.

The Mystery That Is Frontend

I was of the opinion that fullstack devs don’t exist (might be a good topic for a future post). Yet I am now working as a fullstack dev.

I have been a (mostly) backend developer since the start of my career and the last time I touched frontend code was back in 2018. Even then, I was only exposed to JavaScript and a bit of JQuery. I know nothing about all these frameworks, tools, etc. What’s NodeJS? What’s NPM? What’s Babel? Webpack? What is this React thing? What’s with React vs Angular? ECMAScript? Typescript?

… and the list goes on. The landscape of front-end development is truly intimidating.

I’ve heard these things before, but I never had to learn any of them because I don’t need them for work. I am passionate about my career, but I don’t really like spending weekends learning things I probably won’t need. Do I regret it? Yeah, a bit. I may have unintentionally limited my “horizons” so to speak. But I am relatively quick to learn things when I have something I need them for. If I had studied these technologies in the past and not used them, I probably would’ve forgotten them anyway.

Another paradigm shift I had is the mental model for states. In backend, services are stateless - things go in, and things go out. The services themselves don’t get mutated nor do they have to “remember” what they did previously (well, technically they do with the help of the persistence layer but that’s not my point). In contrast, frontend components maintain states: Is the drawer open? Should I show the popover? Does the color change if ? These are things that I can’t simply think of as input → output models.

Luckily, I was able to get by after learning React hooks and a fairly easy-to-use state manager called Zustand. I think I understand them well enough to deliver features or issue fixes, but I do know for a fact that I haven’t really grasped React’s component lifecycle. Maybe I’ll seriously study it one of these days.

CSS, however, remains to be the bane of my existence.

Cloud isn’t about rain

It is somewhat annoying when a new tech is hyped and rapidly gains a following. I don’t hate the tech, but I hate it when people throw around buzzwords all the time. It does the opposite effect on me, and I very quickly lose interest in it.

Cloud is one of them. I was still in college when I first heard about it. To me, it was just a marketing ploy. Just another term for servers you’re renting. That metaphor still kinda stands, but my arrogance kept me from understanding how much the tech has matured.

Like in the case of front end, it just stayed in my periphery. I had experience with some cloud-native technologies, but a lot of the nitty-gritty details were abstracted to me because we had a dedicated DevOps/SRE team in my previous job. I never really had my hands dirty in writing infra definitions from scratch (I shamelessly copied YAMLs from existing projects) much less in deploying resources to the cloud (CI/CD pipeline has already been setup; everything is magic).

Enter: AWS - one of the most popular cloud service providers. It’s the platform that we’re currently using.

And I don’t know sh*t about it.

Periodic Table of AWS by AWS Geek

The number of available services is just mind-blowing. What the heck are all these? Which one do I pick?

Luckily, we already have some existing in-house tooling that helps us use AWS and spin up our own services (for development purposes). It abstracts some stuff too so learning how to deploy an infra becomes a little less intimidating. I’ve also developed a rough mental model on how different services are connected to one another. Gotta give props to Amazon for making their suite of services cohesive (CDK docs are kinda bad though).

On hazy thoughts, accents, and stutters

We, Filipinos, always had a weird relationship with the English language.

It’s taught to us since kindergarten and we’re exposed to it in media. Despite the expectation of fluency, only a few regularly speak it outside of academic institutions or corporate settings.

I still struggle a lot. I get very conscious and anxious about my grammar and word choices. I find it very difficult to express what’s in my head clearly and succinctly. Even more so now that I have teammates who are of different nationalities, some of which has English as their native language. Add to that the differences in accents which I don’t have the ear for yet.

It’s quite ironic that our work, whose requirement is to have expertise talking to computers, is also very collaborative in nature. We have no choice but to communicate with our teammates and stakeholders regularly. You see, talking to a computer is very precise. It does exactly what you tell it to do. The intricacies of human conversations, like idioms, slang, and tone, are not present in programming languages. I don’t have to think about my or their emotions. Nobody has to assume intent behind the words. And certainly, no one has to guess what will happen if they say one thing and not the other.

Being an introvert, I blamed my personality for the gaps in my communication skills. But lately, I have been thinking maybe that’s not the case.

Recently, I’ve met my teammates and a few others in the office (oh hell yeah, I finally touched some grass after 3 years of working from home). Our interactions made me realize that I just needed something that would pique my interest then I would start pouring out everything from my mind, asking questions, and talking endlessly.

One feedback that stuck with me is that I need to be more confident in articulating my ideas. I think that hit the bull’s eye. It takes me a long time to arrange my thoughts, and I feel very uncomfortable with the silence in between. Because of that, I get thrown off and I start speaking even when the things I like to say haven’t been formed yet. The result: stutters.

I don’t think I’ll get over this wall anytime soon, but I’ll keep trying anyway.

AI craze

Of course, this blog post won’t end without a single mention of this year’s AI craze that captured the attention of everyone, may they be in tech or not.

While most people are busy arguing whether AI will take our jobs or not (they won’t at least not anytime soon, but that’s a topic for another day), I am more concerned about how I am going to utilize it to speed up my work.

I was reluctant at first because I thought it was just another overly hyped technology. But there’s also a very strong “fear of missing out” feeling as I see my colleagues rave about it. To my surprise, it really gave me useful answers. Though they aren’t perfect and by no means you could start a multimillion-dollar startup company by just copying code from ChatGPT, it did help reduce the head scratching and typing for boilerplate code.

Fast forward to a couple of months, I find myself using it a handful of times in a month. Not quite sure if that’s too much or too few. It seems very useful when you’re too lazy to read the docs or when your google-fu isn’t enough to get you the right answer quickly.

And since I suck at closing paragraphs, here’s one written by ChatGPT:

In reflecting upon this transformative year as a software engineer, I've navigated through uncharted territories, from delving into unfamiliar business domains to grappling with frontend technologies and cloud services. Each challenge became an opportunity for growth, and while I initially stumbled through the intricacies of communication, I've learned to adapt and improve. This retrospective journey underscores not just the hurdles but the continuous strides forward. Embracing the discomfort, I've cultivated a resilience that fuels my passion for learning. As I stand at the intersection of challenges conquered and those yet to be faced, I am reminded that the essence of this journey lies not just in overcoming hurdles but in the relentless pursuit of knowledge and progress. The coming year holds the promise of further evolution, and I am eager to embrace it with the same curiosity and determination that defined this transformative chapter

That sounds like a student trying to reach the minimum word count. I guess I’m not the only one struggling with communicating, eh?

Cover photo by Mick Haupt on Unsplash

P.S. I had this in drafts for a long time and had already lost the source of the image. So I reverse image searched this and found an interesting interpretation of the image. I think that kinda fits with this post's theme

Test-Driven Development isn't about Unit Tests

Gervin Guevarra — Thu, 29 Dec 2022 16:24:45 +0000

I've met quite a number of people excitedly talking about how they wanted to adopt TDD (test-driven development), citing its ability to “catch bugs before you make them” or something about improving the code quality. While that is not entirely wrong, I think it's a bit misguided and overlooks TDD’s foremost benefit.

Worse, some of them seemingly take TDD as if it's an interchangeable term with unit testing. I am not being pedantic - unit testing is an art of its own and you can write effective tests without doing TDD. Unit test's responsibility is to ensure that your code works as intended; TDD's job is to help you get your code working as intended. See the difference, no? Okay, let's first talk about unit tests.

Everyone loves unit tests

Devs hate meetings. But what do devs love? Writing code, of course! So much so that we're also writing code to test code. The most common of which are unit tests.

Unit tests help us slice our programs into smaller individual pieces (units) and test them independently. They're cheaper to write (relative to integration/end-to-end testing) and they provide very quick feedback to the developer. With just a quick run on the CLI or IDE, a dev can easily find out if something broke. Unit tests are your first line of defence against defects. Martin Fowler describes how it serves as the foundation of your testing pyramid.

When you write unit tests, your objective is to test and ensure that your production code works as expected. Now let's move to TDD…

Driven by Tests

There are A LOT of other X-driven Development: BDD, DDD, FDD, etc.

I'm starting to think the industry sometimes just loves to formalize processes and slap them with -driven development on its name. Kidding aside, let's take our focus back on TDD.

I believe there's a subtle problem with the name “test-driven”. Not that I think I can do a better job than Kent Beck, but it seems that the name led people to conflate testing with TDD.

But the operative word here is “driven”. TDD is a development technique driven by tests. Tests are the means not the goal. The goal is still to write functioning production code and you're just leveraging the power of tests while doing so.

F*ck around and Find out

Have you seen this meme?

It's a funny, perhaps oversimplified, overview of the scientific method. But I think it's a very good analogy to what TDD is meant for in software development.

Writing unit tests in TDD is similar to coming up with a hypothesis and preparing the workbench in a lab. You have an idea in your head, and you verify it with an experiment. Oh, the idea didn't work - tweak some variables and run the test again. Did it work this time? See if it can still be improved… the cycle repeats. Red-Green-Refactor is exactly that!

TDD is for times when you don't have a clear path ahead yet. It's for discovering the solution and refinement. It is a design activity. Take for example, a method signature. When writing tests, you think about the signature first but not yet the implementation details. How do you want it to look like? Inputs? Outputs? Is it easy to wield? And so forth.

TDD is a technique meant to help you iteratively reach your objective: a working software. So maybe, we can call it experiment-driven. But after a quick Google search, that name is already taken. Gosh darn, naming is indeed hard.

Quality is a by-product

Let's talk about quality on two fronts: correctness and maintainability.

When you do TDD, you write tests (duh). These in turn cover a huge chunk of your code base. While code coverage is not necessarily indicative of good quality, the tests created through TDD gives some confidence that your production code works based on the assumptions you've established. These tests also create a safety net, guaranteeing that existing behaviours will not be accidentally changed when modifying the production code.

TDD also levels up maintainability by producing testable code. Sometimes when writing tests after production code, you might find yourself having to deal with a lot of coupling between different parts. This makes it hard to test them independently. TDD inverts that process hence you end up with code that is surely testable.

So yes, TDD helps improve quality. But it is not the quality gate, tests are, regardless if you write them before or after.

Musings on my 5th year as a Software Engineer

Gervin Guevarra — Sun, 17 Jul 2022 09:57:48 +0000

I still remember my first day on the job. From the bus stop, I walked under the summer’s day heat dripping with sweat in my button-up shirt. And as I reach the surrounding buildings, I had hoped to seek comfort in the shade and breeze. But I was instead welcomed with what felt like a hot humid breath. Finally, there I was at the office door looking like I overcame an hour of trekking - not the first impression I wish to make. At that point, I’m no longer sure if I was sweating because of the weather or because of nervousness.

You see, I never planned to be a software engineer (but that’s a story for another day). Heck, I don’t even know what “software engineering” was. All I knew was that these were people writing code for a living. So I wasn’t really confident I could stay in this field for a long time.

But few months ago, I hit a milestone - I’m now in my 5th year in the industry working as a software engineer. While that may not seem much in the grander scheme of things, I still would like to take this opportunity to look back and share my experiences. Since I don’t think I can exhaustively list all my learnings in a single post, I just decided to make a summary of my thoughts, opinions, and probably some bits of wisdom I picked up in the past 5 years. I divided them into three categories as follows:

Career - general stuff that I have learned so far in my career progression
Way of Working - the nuances of working with other people and the software development process
Software craftsmanship - the tacit knowledge that influences me on how I write software

The bullet points below are not written in any particular order. You may simply skim through them and pick up whichever you think interests (or intrigues?) you.

On Career

The university where you graduated from no longer matters after your first job.
Education and skill development does not stop once you leave the four corners of the classroom - it’s a life-long commitment.
Be updated on the trending technologies but no need to dive deep into each one of them. Just-in-time learning is enough
Just because you love building software doesn’t mean you need to be the next big technopreneur. It doesn’t hurt if you really want to be one but it’s not the only path you can take.
Job titles didn't matter as much as I thought they would and are not always indicative of one’s experience/talent.
Debating about the difference between engineer, developer, programmer, coder, etc. is a moot point. Each person will have varying specializations and level of experience.
Learn the market average for the position you are applying for.
Do not overly boast your accomplishments as they may come off as annoying if not rude, but do not undersell your contributions either. Brag responsibly as I would say.
Don’t accept jobs without a formal contract or working agreement, and carefully read the clauses.
If you have the time and resources to get them, certificates are nice.
You don’t need to write code on weekends just to tell yourself that you’re a good developer.
Create healthy relationships with your colleagues and build your network.
Join and engage with software development communities
Good performance at work is a by product of good personal development - don’t stop learning stuff may it be technical or soft skills.
Soft skills are just as important as technical skills.
Do not be afraid of finding new opportunities for career growth. But also do not jump so frequently as you will not experience how to handle a maturing product or service.

On Way of Working

That I won't be writing code all the time. Software engineering is multi-faceted and its art goes beyond just programming
- much of the work involves talking with the stakeholders and decision-makers
- managing work for yourself and sometimes even for your team
- negotiating the scope, forecasting work, managing expectations
- designing the system such that it is maintainable, scalable, secure, etc.
- supporting what you release in production
Agile is an ideal, but the journey to it is an arduous and sometimes disruptive one
- it requires conceptual integrity on what it means to be "agile"
- the whole organization has to be on board and supportive
- it is not a single defined process but an exploration of what works best for your team
  - but change can be difficult to adapt and may initially slow down progress
A team is not just a bunch of individuals working on different parts of a single system. A healthy team is one whose members are willing to go beyond the self mentality and are mutually committed to a common purpose or goal. It should be no silos.
Software development is a collaborative effort rather than a mere collection of individual contributions. The stereotype that developers are lone wolves is not true.
Estimations are effin hard, especially in the face of the unknown. Oftentimes, you’d find yourself not knowing what you don’t know about a particular problem - worse you may not know what the problem is at all.
Software engineers are passionate and strongly opinionated people
- We care so much about how to do it the right that disagreements have become a natural part of the process. It doesn’t mean it’s toxic though.
- Software engineering requires careful assessment of pros and cons - there will be no single correct answer
Pull requests should be egoless. It is an opportunity for discussion and knowledge sharing.
Explicitly advocate for safe space. This will help empower team members to share ideas, ask questions (even if they’re silly), or try new things while also leaving ample margin for errors.
Maximize the tools (i.e. a ticket tracking/project management system) you have in your team for documenting stuff. This will help give context to what a particular item is and is useful for asynchronous communication.
If your process involves a lot of grunt work, look for ways to automate it so you or your team can focus on other stuff.

Software Craftsmanship

Software development is a web of unknowns and possibilities - there will always be scenarios you’ve never anticipated and trade-offs you never accounted for.
No software is bug-free
The best tool is often one that you already know how to use. Conversely, if all you have is a hammer, everything will look like a nail. Therefore, don’t just learn the tool. Understand the specific problems it is trying to solve.
Code style depends on the team and the language conventions. What's easy to write or read for me may not be the same for everyone. When working with a team, it is important to establish this as early on and enforce it (i.e. linters, hooks, static code analysis tools, etc.). This will help improve consistency throughout the code base and possibly reduce cognitive load as everyone will know where and how to look for something.
Code is read much more than it is written. Remember that you are writing code for another person to read later.
Familiarize yourself with some of the popular language paradigms and type systems. It would make switching easier. And when writing, you may also start borrowing elegant concepts from one language to another
Learn a version control system. Git gud (pun intended)
Learn your editor/IDE. It’s your most important tool. Customize/configure it to your liking to improve your workflow
Debugger is your best friend
Logs are essential but overdoing it may create too much noise. Investigation of issues may feel like looking for a needle in a haystack.
You will never have dedicated time to refactor something. If you can safely and timely refactor something, refactor it now
- easier said than done especially in legacy systems that can sometimes be too fragile
On writing tests:
- Tests are akin to mathematical proof. If you declare that something behaves as such, then you have to prove it
- Tests are safety net for the next developer that will change something. This will ensure that the previous behavior of your system remained intact
- Tests can also serve as a form of documentation as it is a collection of facts about a system
- Writing tests can be expensive, but the bug fix turnaround time can be more expensive. Write tests whenever you can and wherever
- TDD is a powerful design tool, but it is not about unit testing
- You don’t always need to do TDD especially when you already have a clear idea of the design and what steps to take to implement it
- Mocks are helpful but are also easily misused. Use them sparingly
Knowledge and application of design patterns can be a chicken and egg problem. Learning a design pattern might make you apply it to problems it doesn’t fit in. On the other end of the spectrum, not knowing any design patterns will likely make your code less organized and less maintainable. A possible solution is to work with your team, discuss the pros and cons, and let a design emerge.
Premature optimization is bad, but that does not mean you’ll willingly write an obviously slow code. Do not let it be an afterthought. As mentioned earlier, conduct timely refactoring and make it sufficiently performant.
Do not cling to popular conventions or approaches if it doesn’t work for your team lest you be a victim of cargo cult. And that includes this blog post - don’t just believe everything I say. Critical thinking is necessary in order to achieve solutions that fit the context of your problem. There is no silver bullet

Cover photo by Greg Rakozy on Unsplash

How to Think in Object-Oriented Way

Gervin Guevarra — Tue, 28 Jun 2022 16:22:00 +0000

A gentle introduction to Object-Oriented Design

Who is this for?
Things I won't cover
What the heck is OOP?
Concepts and Uses
- 1. Categorization
- 2. Blueprints and Construction
- 3. Grouping of Data
- 4. Segregation of Responsibility
- 5. Boundaries or Layers
Notes and Further Reading

Who is this for?

If you are any of the following:

Someone who already has a decent understanding of any structured programming language. The examples are written in Java but it should be easy to follow as long as you already have a programming background
Someone who is struggling to understand OOP
Someone who didn’t study their entire semester and now wants to do a crash course (kidding)
Or just curious about what this 3 letter acronym is

…then this guide is for you.

Otherwise, you might still get a thing or two here. Maybe this serves a good refresher. Perhaps, you’d notice some mistakes as well, in which case please let me know and I’ll be more than happy to make the correction and credit you :)

Things I won’t cover

This is not meant to be a comprehensive guide on OOP. There are already hundreds of books and videos for that. Instead, this is a primer for those who are just starting to get their feet wet with OOP. I will try my best to limit the jargon and terminologies to avoid bogging you down, or else I’ll be defeating the very purpose of this guide.

As such, I won’t be discussing things here like the 4 pillars of OOP, GoF design patterns, SOLID, or other software development principles rooted in OOP. Some of these topics will be (sneakily) touched upon as it is impossible not to do so, but I won’t go into detail to avoid information overload.

With that out of the way, let’s jump right into it.

What the heck is OOP?

OOP stands for Object-Oriented Programming, sometimes referred to as OO when used as an adjective. As the name suggests, it is an approach wherein you model parts of your code as if they are individual objects with specific characteristics, states, or behaviors.

✅ OOP is all about thinking and modeling your code like it’s an actual real-world object

You can think of your program as an actual piece of hardware with individual components that when combined together works as a single unit. Each component would have their own characteristics, their own behavior, and their own state at a given time.

A good analogy is a desktop computer. Within the system unit, it contains many parts each with their own responsibility (i.e. memory/disk for storage, CPU for all the processing needs, etc.). Then you’ll also have peripherals like keyboard, mouse, or display devices, which serve as your bridge to the external world - accepting inputs or giving outputs.

Your program, in a way, can also be modeled like that. It can be divided into multiple logical parts then combine them together. If you’ve modeled it properly, you can should also be able to easily swap out same type of parts but with probably different characteristics like how you can switch out a graphics card for another that has better specs and performs differently.

Concepts and Uses

1. Categorization

One of the first things that you’ll learn in programming is the data type or simply type. You’ve probably already encountered this when declaring or assigning variables like so



int age = 20;

What this basically does is that it tells your computer that the data you are storing is of type integer, denoted by int keyword, and should be treated as such. Its category is an integer and not a floating-point number, boolean, nor a string, etc.

In OOP, you have the power to create your own type. In most OO languages, this comes in the form of a class. To demonstrate, let’s have a simple Box



class Box {
    //fields here
}

There can be many types of box:

shoe box
jewelry box
music box
mail box

to name a few.

These are all wildly different but they all fit our basic idea of what a box should be: some sort of an enclosure to store something.

Assorted Boxes. Image by Chuttersnap on Unsplash

If we were to play a Bring Me game and I say “bring me a box”, I can accept any of those boxes we’ve mentioned.



void accept(Box box) {    //any box will be accepted
    //do some action here
}

But if I said “bring me a lunch box”, then I won’t accept a shoe box or any other kind of box.



class LunchBox extends Box {
    //fields here
}



void accept(LunchBox lunchBox) {    //will only accept a LunchBox
    //do some action here
}

This gives us the option to be either very specific or more generic depending on our expectations or use-cases.

2. Blueprints and Construction

When houses or buildings are made, they don’t just magically appear out of thin air (duh). It starts with a careful plan detailing its structure and contents - the blueprint. The blueprint then becomes the basis when the construction begins.

Blueprint. Image by Damon McCullough on Unsplash

In OOP, it’s the same. You start with a class that defines how your object is going to behave and look like.



class House {
    int floors;
    int doors;
    String color;
    //other characteristics here
}

This is your object’s blueprint but it doesn’t necessarily mean that your object already exists. That’s why you need to instantiate or create it using the constructor. Think of your constructors as the actual workers and heavy machinery that helps build your brand new house.



House aBrandNewHouse = new House();

💡 What is a constructor?
In class-based OOP languages, a constructor is the a special method of a class whose sole purpose is to create an object instance for that class.

By default, every class has a public (accessible by anyone) no-args constructor. You can change that by having an explicit private constructor but that’s already beyond the scope of this guide.

This is neat because you have the ability to create multiple independent instances. If you need to, you may change one House without affecting the other. But even then, they are still considered to houses because that is their type.



House aBrandNewHouse = new House();
aBrandNewHouse.color = "red"; //A red house

House anotherBrandNewHouse = new House();
anotherBrandNewHouse.color = "blue"; //A blue house

3. Grouping of Data

Pizza in a box. Image by [Lukas Bee](https://unsplash.com/@lukasbee) on [Unsplash](https://unsplash.com/photos/T-SkHm-18qQ)

Suppose we want to create an app for a pizza shop. One may write Pizza as follows:



class Pizza {
    String[] toppings;
    String size;
    int slices;
    BigDecimal price;
}

This is not necessarily wrong. But going back to our earlier definition, OOP is about modelling our code like it’s a real-world object. If you think about it, price isn’t part of an actual pizza. Otherwise, we’ll being eating pizzas with price tag.

Instead, we can have a separate class that can contain that information. And in doing so, we can even add more details that’s not part of the pizza itself!



class PizzaOrder {
    Pizza pizza;
    BigDecimal price;
    ServingType servingType;    //enum - DineIn, Delivery, or TakeOut
}

In the future, if we needed to change Pizza , say we wanted to offer different kinds of Crust, we can do so without affecting PizzaOrder.



class Pizza {
    String[] toppings;
    Crust crust;
    String size;
    int slices;
}

Whenever you write classes, ask which goes with which. Remember that the members (e.g. fields, methods, etc.) in a class should have high cohesion - meaning they should be closely related and should be part of the enclosing class. In this example, we created a new PizzaOrder which can group the information in a more sensible way.

4. Segregation of Responsibility

A physical system like a machine would usually be composed of different parts each with their own purpose. Let’s take for example a car.

For the purposes of this discussion, we’re going to oversimplify the parts of a car, namely:

Engine - provides power
Wheels - translates that engine power to a rolling motion
Brakes - slows down the car
Steering - points the car to a certain direction

With just this basic parts, maybe our car would look something like this:

The first automobile. I don’t even know if this thing has brakes. Source: Mercedez-Benz Group

Notice how each of the parts have their distinct purpose? So instead of just dumping every behavior in a single class called Car , we can opt to a separate each part into their own classes and assemble together later.



class Engine {
    void generatePower() {
        // some implementation here
    }
}



class Wheels {
    void roll() {
        //some implementation here
    }
}



class Brakes {
    void reduceSpeed() {
        //some implementation
    }
}



class Steering {
    void steer(Direction direction) {
        //some implementation
    }
}



class Car {
    Engine engine;
    Wheels wheels;
    Brakes brakes;
    Steering steering;

    //constructor here
}

This seems to be a lot of code. But why do we have to do this?
Much like in the real world, software components can be swapped out for something else that has a more desired characteristic or behavior.

Suppose we wanted to have a faster car and we’d want to swap the engine. We can easily do so by giving the car a different engine.



class SuperPowerfulEngine extends Engine {
    // some fields here
}



// in some other class, we instantiate a Car

SuperPowerfulEngine engine = new SuperPowerfulEngine();
Wheels wheels = new Wheels();
Brakes brakes = new Brakes();
Steering steering = new Steering();

//then we give our super powerful engine to our car
Car car = new Car(engine, wheels, brakes, steering);

Imagine our modern day cars if the parts are not distinct from the car itself and could not be replaced, shall we buy an entire car every time something breaks?

5. Boundaries or Layers

Now we know how we can categorize things, group relevant information together, and separate responsibilities, we can take it up a notch and create divisions **between two distinct parts so they become independent of each other.

Take a look at your phone. See that hole below? That’s your charging port, right? That’s also where you plug the cable in case you want to make file transfers to and from your computer.

If you’re using an Android phone, then that’s a USB-C port you’re looking at. If you have an iPhone, then that’s a Lightning port.

USB-C and Lightning are types of interfaces. They allow you to connect different things to your phone as long as they follow the form factor. You can think of that form factor as the contract between your phone and whatever cable or device you’re connecting to it.

In OOP, we do this with… guess what? An interface.



interface UsbCPort {
    void charge();
    void transferFile();
}



interface LightningPort {
    void charge();
    void transferFile();
}



class AndroidPhone {
    UsbCPort port;

    //some methods here
}



class IPhone {
    LightningPort port;

    //some methods here
}

Remember the Bring Me Example earlier? This is exactly the same except that the we’re looking at interfaces instead of classes. What this tells us is that an Android phone wouldn’t care whatever you connect to its port, may it be a charger or a computer, as long as it fits the contract - a USB-C. The same is true for iPhone but with Lightning.

The port creates a physical boundary between the phone and the external device. And this allows us to easily swap out the device we’re connecting to it.

💡 Agnostic and loose coupling
The phone port is a good demonstration of how components should be agnostic and loosely coupled to one another.
Agnostic refers to a component being ignorant of the thing being plugged to it as long as it fits certain characteristics. In this case, the phone can handle either charging or file transfer as long as you use the designated connector for its port.
Loosely coupled means you can attach or detach something from a component and the component can still act independently without the other. When you disconnect your charger from your phone, your phone still functions normally (as long as you have battery of course!)
In significantly large projects, software components are designed to be loosely coupled so they can be easier to modify, fix, or test in isolation. One example is the database access. With interfaces, we can connect our application to a different database i.e. an in-memory database which only stores data temporarily. This can serve as a fake database where we can conduct our tests safely instead of connecting directly to a real persistent one.

Notes and Further Reading

Alan Kay, who coined the term object-oriented, said that the real big idea in OOP is messaging rather than objects. I dare not question his authority on the proper definition of OOP. But I also think that there is value to what it has become and how it is being used today even though it may have deviated from the original intent. If you want to read more about Alan Kay’s clarifications on OOP, check these out:
- Alan Kay On Messaging (c2.com)
- Dr. Alan Kay on the Meaning of "Object-Oriented Programming" (fu-berlin.de)
While writing about using types to categorize things, I couldn’t help but remember the existence of category theory. While OOP may have its roots in mathematics, I did not mean category in that sense. I won’t dare use that in my explanation since I don’t have sufficient knowledge for it. I simply felt that category may be an easier word than type but I failed to consider that it might imply another thing. But in case you want to read more, you may check out Category Theory for Programmers by Bartosz Mileweski. It’s on my reading list as well. Here’s a free copy:
- https://github.com/hmemcpy/milewski-ctfp-pdf
Earlier I mentioned “GoF Design Patterns”. This refers to the the book Design Patterns: Elements of Reusable Object-Oriented Software written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides aka the Gang of Four (GoF). It’s considered a classic among OO programmers. Here’s a summary I frequent to whenever I need a refresher:
- https://github.com/kamranahmedse/design-patterns-for-humans
SOLID is a set of design principles which helps you write elegant and maintainable code. It is formally introduced by Robert Martin aka Uncle Bob, the author of Clean Code book - also a classic. Personally, I only appreciated OOP after I learned SOLID. That may or may not be the case for you but SOLID is still an indispensable knowledge. There are a lot of great resources about this topic but here’s one that I found straight from the man himself:
- Getting a SOLID start. - Clean Coder
The examples written here are in Java, a class-based OOP language. But there is another kind which is the prototype-based OOP e.g. used by Javascript.
- Prototype-based programming - MDN Web Docs Glossary

Cover photo by Robin Glauser on Unsplash

Fluent If-Else statements?

Gervin Guevarra — Fri, 15 Oct 2021 06:49:54 +0000

Some showerthoughts for the day:

I think it would have been nice if languages support fluent conditional statements.

So instead of

if(condition) {
    someFunction();
} else if (anotherCondition) {
    anotherFunction()
} else {
    doSomething()
}

Maybe have something like

if(condition, someFunction)
    .elseIf(anotherCondition, anotherFunction)
    .else(doSomething)

or go further and make it return a value

var someVar = if(condition, someFunction)
                    .elseIf(anotherCondition, anotherFunction)
                    .else(defaultValue)

Pros:

you get a more succinct and arguably more expressive statement
if used properly, it may read like a prose

Cons:

it's probably unnatural or unintuitive to some people; more cognitive load perhaps?

I'm not actually sure if this already exists elsewhere and I'm too lazy to find out if it does.
But what do you guys think? Is this useful or am I just overthinking it? 😆

My Experiences in Writing and Publishing My First Java Library

Gervin Guevarra — Sat, 07 Aug 2021 08:01:40 +0000

More than a year ago, a friend introduced me to the concept of Railway-Oriented Programming (ROP). I liked the idea and the fluency that comes with it, but it was a style born out of functional programming - something that is not fully embraced in Java despite the introduction of lambdas and streams in Java 8.

Though there were already a few existing Java libraries for this, I thought it might be a good idea to write one myself as it was a good opportunity for me to:

understand what ROP is
practice TDD
learn how to publish a Java library to a publicly available package repository (i.e. Sonatype Nexus)
try to use GitHub actions to setup a pipeline and automatically publish the library to the package repository

After a couple of months and tons of procrastination, I was able to came up with something usable albeit not production-ready (that wasn't the goal anyway).

Gerv-G / jrail

Railway-oriented Programming with Java

If you're curious, you can get the snapshot here.

I'm planning to do a write up on what JRail is, what it can do and what I think are its shortcomings (though I think what I've made is not a true ROP). But that's not what this post is all about. For now, here are some thoughts and highlights from the journey:

Naming is (still) hard
I suck at GitHub
I don't think I truly understood Monads
Spock is great but it didn't fit my needs
Open-source Licensing Options
Dipping my toes on GitHub Actions
Creating and approving my own PR
Publishing the library

Naming is (still) hard

As clichéd as it may be but naming is really hard. I've been mulling over the name for almost a week before I settled for JRail, since most Java things either starts or ends with "J". It was only after the creation of the repository that I realized it looks like a name for Japan Rail. But hey, it has already been created and I don't wanna spend another week thinking for a name.

I suck at GitHub

Prior to this, I don't have any serious repositories in my Github account. Most of what I have were more like scratch paper scribbles rather than showcase-worthy projects. So yeah, that's a pretty lengthy way to say I don't code outside of work.

Look at that contribution calendar. So impressive /s

It also took me an embarrassing amount of time to setup my SSH keys and the repository which should have only taken a few minutes if not seconds. This is a nice refresher, I guess.

I don't think I truly understood Monads

And at this point, I don't think anyone does.

Kidding aside, I really wanted to understand the underlying theory in this. I believe it's perilous to simply do something without understanding why it is done in such a way. I remember consuming a lot of materials about category theory and functional programming when I first ventured into this project, but wasn't able to retain much information (my brain isn't great).

The closest I got to understanding it is with this explanation.

So I tried explaining it my own words to a friend, because "the best way to learn is to teach", right? But I couldn't answer his questions, so perhaps I really didn't get monads after all.

Like a normal person, I gave up. I may come back to it later if I ever had the motivation again but for now I think I've learned enough to proceed. I then shifted my focus on how I can make the API intuitive enough to use, of course with the help of tests.

Spock is great but it didn't fit my needs

You've probably heard of the testing framework called Spock, which is written in Groovy. It's great and I love using it everyday for work. So I initially wrote all my tests using it.

But I realized that having a dynamically-typed language doesn't help me that much in designing the APIs (the not-so-strict Java generics isn't helping either). I also wanted to know what it's like to use the APIs I've made. So to avoid shooting myself on the foot, I decided to rewrite the tests with JUnit instead.

Another reason is that I wanted to let my tests serve as a documentation or a compilation of examples. I wrote this library with Java devs in mind, and having tests in Groovy is sort of a step towards a different direction. One of the few differences is Groovy closures where the syntax for lambda expressions uses curly braces instead of parentheses.

{ closureParameters ->  statements }

While that may not be so significant for an experienced dev, I didn't want to add any additional cognitive load to the readers anymore. Writing the tests in Java made the "examples" clearer and consistent.

Open-source Licensing Options

Why the heck are there too many of them? Thankfully, GitHub created https://choosealicense.com/ to help noobs like me pick the proper license.

It's unlikely that people are gonna use this anyway. But just in case, I wanted to let them know that I don't care what they want to do with it and I'm not liable whatever chaos they caused.

Dipping my toes on GitHub Actions

It's my first time to setup my own CI and it was actually easier than it is to type this whole blog post. GitHub has already provided some workflow templates to get you started so it really is just a matter of clicking. It's also fairly easy to play around with since it's just YAML (as most DevOps things are).

Creating and approving my own PR

I don't think I need to explain this. This is the best part of this project

Publishing the library

This is the most exciting yet frustrating part of the project. I was only able to publish a snapshot, but I couldn't sign it properly. After multiple failures in my CI, I decided to skip the signing and just publish a snapshot. I didn't want to publish an unsigned package but I was too lazy to continue. I felt like I've already done what I ought to do so this is already enough of an achievement for me.

Yup, I'm lazy. I know.

Final Thoughts

Building JRail was a pretty fun exercise despite my failure to complete it. I may comeback to it later to improve it and to revisit its paradigm since I don't think I've followed ROP. But realistically speaking, I'll probably just leave it as it is because I usually prefer to stay away from coding after work hours. It's just my own way of balancing things and taking the time to enjoy some other stuff.

Nonetheless, it's still a nice reminder for myself to always practice the basics and to sometimes explore what else I can do other than those that I learn on the job. I think I'll borrow some principles in ROP and apply them to our code.

In Defense of the Spaghetti Code

Gervin Guevarra — Sun, 01 Aug 2021 05:50:07 +0000

Anyone working in software would have probably seen a piece of code they wish was never written. Or at least was not written like it was meant to summon creatures from the underworld.

Funny enough that this tangled ball of mess is so common that we gave it a name: spaghetti code. And there are probably hundreds of articles, books, and memes about it - yes, we all love to hate it. Dealing with bad unmaintainable code is never fun. No one likes to touch a program that feels like a disaster waiting to happen.

So why defend it then?

Well folks, spaghetti code is still spaghetti.

Everybody Cooks Pasta

When I started my career as a junior software engineer, I was surprised to learn about the rate at which our code changes. Before that, I've only worked with school assignments and projects. Once I've written it and it works, that's final. That's the product of my work.

The real world isn't as nice though. Requirements will always change yet the product is expected to adapt as quickly possible. It is interesting that we, as an industry, has created subject areas, or a disciplines if you will, about making changes to software again and again - agile, refactoring, CI/CD, and a slew of other jargons. I don't know much about civil works, but it's probably crazy to think if they do have something similar to how we do software. Can you imagine bridges getting restructured on a daily or weekly basis?

But that's just the nature of software - nothing is ever permanent. Unlike a bridge, it is soft in a way that you can mold it in any way you want. It can change and be shaped to fit the ever changing requirements. You know, kinda like a dough.

Pasta Dough. Image by Alex Lau via Bonappetit

But what starts as a simple chunk of dough soon becomes pasta noodles. Cook it, add some sauce, meat, basil on top and voila!

I'm pretty convinced that spaghetti code (or its variants) exist everywhere, c'est la vie. That wouldn't stop me from checking git blame , but I at least have grown to understand that most are just accidental chefs.

A little empathy to the Accidental Chef

I don't think that anyone have intended to write code that looks and feels cursed from the get go. Maybe at the time that was the best way the authors knew how to implement it. Maybe their technical and/or domain knowledge is not ripe enough. Maybe they have limited resources and it was their conscious decision to cut corners. Maybe, maybe...

My point really is that software projects don't always go our way. We have to accept that it will grow over time and we have to weed out things that we don't like.

And the spaghetti authors? I'm not gonna jump my gun and call them incompetent or evil. I am pretty sure that I unknowingly have been in their shoes, and those who have to work with my code written months/years ago are probably cursing me right now.

It's edible (and can be delicious)

So is it okay to write spaghetti code? No, it is not but mistakes are always bound to happen and this is one of the few things I'd treat as excusable and remediable (easier said than done, I know).

At the end of the day, we write code to create solutions. That spaghetti legacy code may be shitty as it can be. But if it works, provides value for the users, and generates income for you then it's still great.

"We can write clean code and still provide value to our users", you'll probably say. Then that's even better! Good for you. And that should be everyone's goal. Clean code improves developer experience and can improve turnaround time. But the reality is that not everyone may be capable of reaching that ideal state right away.

So I'd rather take baby steps with a little bowl of pasta than rush, trip over, and plant my face to a cake.

Cover photo by Dario at Unsplash

Step by Step Introduction to Unit Testing in Java

Gervin Guevarra — Sat, 10 Apr 2021 07:02:50 +0000

Table of Contents
Introduction
Naive way of testing code
What is Unit testing?
- An analogy
Getting your feet wet
- Prerequisites
- A sample existing code
- Setting up the testing framework
- Separating source code and test code
- Writing your first unit test
- Running the test and using the results to debug
Final notes
Further Reading

Introduction

Hey folks! So I kinda promised to someone I forgot who that I'll write a unit testing guide for this group. There must be hundreds of similar guides out there in the wild, but I feel like most of those I've seen are too short and doesn't really explain the rationale behind unit testing. I think unit testing is one of the most underrated skill that a programmer should learn and sadly it isn't taught in schools (in our country, at least). So here's my take on a (hopefully) gentle introduction to the world of automated testing.

Anyway, enough with my babbling. Let's get right into it.

Naive way of testing code

When we first started learning programming, what we'd normally do is write code, run the program. Then conduct tests by entering some inputs hoping that the output is as we desired. If not, we go back writing our code again and fixing bugs.

Well, there's nothing wrong with that. In fact, for your entire life as a programmer you'd be doing all these three things:

1) write code

2) run the program

3) test the behavior of your program

Then repeat again

But you won't always be writing simple console applications. Sooner or later, you'll find yourself doing repetitive tests with slightly varying inputs.

In the real world where you'd be dealing with much much bigger and more complex software, doing those three things every time will be very time consuming. There will also be cases where you need to isolate your changes and just test a specific part rather than the whole system.

What is Unit testing?

So instead of running and testing your entire program every time you have to a change in your code, we can automate it by writing code to test our code. More specifically, write code that would test a single part of the system isolated from everything else. That's unit testing.

An analogy

For example, you are building a house and you need some light bulbs. So you go to the store and buy a light bulb. In order to make sure that the light bulb you just bought works, you need to test it.

But the good thing about it is that it's independent of your house. You can test it by itself. No need to actually install it in your house and see if it lights up. Instead, you or the sales assistant can install it to a test bulb socket (found in most hardware or appliance stores) and see if it lights up. You are essentially testing a single unit of a light bulb which is meant to be part of your house (i.e. the entire system) under construction.

Imagine if it wasn't possible to test the light bulb alone. You have to go back to your house first, finish building it, install the light bulbs and test if it actually switches on. Quite a hassle, isn't it?

Getting your feet wet

Prerequisites

Before taking this guide, be sure that you are already familiar with Java language as I will not be going through the detail of compiling and running your Java program. Also be sure to have an internet connection as we will be downloading some tools, and libraries. This guide also assumes that you have an existing project where you want to add unit testing. If not, you can just copy-paste the Java files below and follow along.

It's also worth noting that the guide, for now, is also written to suit MacOS or Linux users. But experienced Windows users may also want to try anyway (and let me know where it gets difficult! I'll make updates on this guide where necessary).

Below is short list of everything you need:

Java 8 or higher (I'm using Java 8. But to follow this guide, it doesn't matter if you're using a newer version)
Favorite Code editor or IDE (I use IntelliJ IDEA myself, but you're free to use whatever you want)
Gradle build tool (download and follow the guide here)
- in case you are already using Gradle, you may want to skip to this step and just add JUnit to your dependencies
Command Line (Shell or Command Prompt)
- we'll be doing things from scratch, so having familiarity working in terminal is a great plus
- this also makes this guide IDE-agnostic, meaning you don't have to be very dependent on a specific IDE just to make this work
- if you're on Windows, you may opt to use WSL or the bash prompt that comes with Git (if you are already using one).

A sample existing code

Say we have an existing console application which accepts input of any length from the user and then our program outputs the reverse of the input. Classic problem.

So we can implement this by writing the following:

You might notice a "bug" here. That's intentional. We'll delve into that later

At this point, your project structure should look similar to this. It's alright if you don't have the .idea folder or the *.iml file. Those are just IntelliJ IDEA generated files.

Setting up the testing framework

The testing framework that we're gonna use is JUnit. To add it in our project, we need a dependency manager such as Gradle.

💡 Dependency Manager
The great thing about OOP is that it allows us to reuse somebody else's code. Those reusable pieces of code often mature enough that they can be standalone libraries or frameworks. They then get redistributed by various means, either by downloading the JAR files, as in the case of Java, or getting the source code and building it by yourself. These libraries or frameworks become the dependencies of your project. Some of these libraries/frameworks have dependencies of their own, so you also have to take care of them and add them to your project.

But doing so multiple times over the duration of your project can be time-consuming, entails difficulties, and is a very repetitive processes. This is where dependency manager comes in.

A dependency manager is a tool that helps you download libraries and/or frameworks, as well as their dependencies, to add to your project; while also keeping track of the version you are using for each. Some examples of popular dependency managers for Java projects are Gradle and Maven (which also functions as build tools).

For further reading about dependency managers and what they can do, check out this article by Seun Matt in Medium

If you have prepared the prerequisites listed earlier, you should have Gradle already installed in your system. To check, enter the following in your terminal and it should output a directory where you installed Gradle.

$ which gradle

Next, we need to turn our existing console application project into a Gradle project. Expand each step by clicking the drop-down then follow the instructions

Go to your project directory

In my case, my project is saved in Users/gerv/Source/HelloUnitTesting. I can use ~ as short hand for my User home directory.
```
$ cd ~/Source/HelloUnitTesting
```
Initialize a Gradle project

Simple enter the following command and follow the on-screen instructions to setup gradle for your project
```
$ gradle init
```
If you're confused, you can just follow the screenshot below.

You might notice that my shell prompt is different. That's because I'm using zsh with oh-my-zsh, but that's a topic for another day. For now, think of that fancy arrow as the $ sign you normally see.
Run your first Gradle build
```
$ gradle build
```
Then you should see an output similar to this:

You might notice that there are a bunch of files added to your project folder. These are files that are generated by gradle init and will be used by Gradle when building your project. You may happily ignore them for now, but I want to quickly introduce you to one of them, the build.gradle file. This is the file that contains the list of your dependencies and repositories (from which your dependencies will be downloaded). Take a quick look at it and notice that JUnit is already added; this because we picked JUnit earlier when we ran gradle init .

You may also notice that main and test folders are added to the project. We will use them to reorganize our code.

Separating source code and test code

Gradle isn't smart enough to know that you already have existing code in your project, and assumes that you are starting a Gradle project from scratch. So it creates its own folders, package, the class named App.java with the main() method.

After running gradle init , your project directory should look like this.

But we already have ConsoleApplication.java and that serves as the main entry point of our application so we can just get rid of App.java. We also don't need the package HelloUnitTesting since we already have an existing one from before. Delete them as you normally would, or if you're like me and you like doing everything in terminal

$ rm -r src/main/java/HelloUnitTesting

$ rm -r src/test/java/HelloUnitTesting

Project directory after deleting some files

Then we need to reorganize our code and put them inside the main/java/ folder. To do this, you can either drag the com.gerv.guev (or whatever your existing package name is) to main/java/ or do it via terminal again

$ mv src/com src/main/java/com

If you're also using IntelliJ IDEA, you might notice that main/java is marked like a package even though it isn't. To make them appear like normal folders, simply right click on the src then point to Mark Directory As and pick Unmark as Sources Root. Then right click on java folder under main then Mark Directory As and pick Sources Root. Do the same thing with the java folder under test, but pick Test Sources Root. For the resources folder, mark them as Resources Root and Test Resources Root for main and test respectively.

If you've carefully followed the instructions, your project directory should now look something like this:

To quickly check if everything still works, run this and it should tell you "Build Successful". You may also want to try and run your program if it still works as before.

$ gradle build

If your gradle build is successful but your IDE is complaining (i.e. squiggly red lines, you can just reimport/reopen your project and hopefully your IDE recognizes that it's now a Gradle project.

Quick Recap!
That's a lot of things we've already covered. Here's what we've done so far:

turn our project into a Gradle project
add JUnit to our dependencies
Reorganize our project folders

Writing your first unit test

Now that we have finished setting up our project and its dependencies, we are now ready to write our unit test!

Under the test/java folder, create a package com.gerv.guev or whatever package name you already used in your project. Then create a file named MyStringUtilitiesTest.java. You may copy the contents of the class for now, I'll explain what it does along the way.

Then we are going to add a test method that actually does nothing. We're taking very small steps to make sure we're not making mistakes and everything is still working as it is.

In the code above, @Test is an annotation that tells our compiler that the method that we just wrote is a test method. @Test annotation is located under the org.junit package (notice the import statement above).

A method marked as a test method will be checked by the test runner if it satisfies some conditions we are expecting. In this case, the test should always pass because we told it to assert true which will always be true no matter what. The point of writing this the first time is to check if our unit testing framework was really set up correctly. After you've written one or if you're already familiar with the testing framework your are using, there's no need to write this one every time.

To run the test, type in this command

$ gradle test --tests="com.gerv.guev.MyStringUtilitiesTest.someUselessTest"

In the command above, we are telling Gradle to run the test found in a fully qualified name. In this case we're telling it to specifically run someUselessTest() test method.

A fully qualified name consists of the package name, class name, and method name. It represents the hierarchical location of your file or folder and should always be unique.

But if you have multiple tests inside a class or package, you can just replace it with an asterisk (*) and it should still run

$ gradle test --tests="com.gerv.guev.MyStringUtilitiesTest.*"

Running the test and using the results to debug

Now, let's replace that useless test with a real one to test our earlier code for reversing a string.

Go ahead and run the test using the command mentioned earlier, and you should see an error similar to this

> Task :test FAILED

com.gerv.guev.MyStringUtilitiesTest > shouldReturn_ReverseString FAILED
    org.junit.ComparisonFailure at MyStringUtilitiesTest.java:14

1 test completed, 1 failed

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':test'.
> There were failing tests. See the report at: file:///Users/gerv/Source/HelloUnitTesting/build/reports/tests/test/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1s
3 actionable tasks: 1 executed, 2 up-to-date

This tells us that our test failed. Gradle has a pretty neat way of telling this to us and generates an HTML report. Copy that file path and open it using your browser.

From here it says: org.junit.ComparisonFailure: expected:<[olleh]> but was:<[????o]> on the first line of the stack trace. It tells us many things:

our input string was not reversed hence it is not equal to our expected output "olleh"
the actual result does not contain the correct characters or is probably empty. Instead, it's displaying multiple question marks.
The actual output has the same length as our expected output. It has 5 characters.
The last character "o" is still the last character in the actual output

Don't fear the stack trace!
Most beginners find the error messages in the stack trace intimidating, but it's actually quite easy to decipher. All you have to do is to read the first line to have a general idea of what caused the failure. If you still don't know at first glance what the error was, skim through the lines and look for your package and class ****then check the line number.

In our example, it says:
org.junit.ComparisonFailure: expected:<[olleh]> but was:<[????o]>

then I skip lines until I see a familiar package name:
at com.gerv.guev.MyStringUtilitiesTest.shouldReturn_ReverseString(MyStringUtilitiesTest.java:14)

That tells us that there was a ComparisonFailure at line 14 of our MyStringUtilitiesTest class.

Given those findings, we can check back our code to see what was wrong. Here's the current code now with comments. Can you spot what's wrong?

From our original code, what we did is we took each letter of the input from left to right then transferring it to the new character array from right to left but we did not move the index. To fix this, we have to decrement the index for it to move from right to left.

Now run your test again and it should give that sweet success

gradle test --tests="com.gerv.guev.MyStringUtilitiesTest.*"

BUILD SUCCESSFUL in 1s
3 actionable tasks: 2 executed, 1 up-to-date

Suppose we are going to add features in our string utilities class, like detection of palindrome

Then all we have to do is to write another unit test and run all of them. The beauty of unit tests is that you'll always have a proof that your older features are still working even after adding new ones. And there's no need to run your console application every time just to do a manual test.

You may continue adding other tests, say a different input word or maybe an entirely different test, then run it as usual. I am leaving that as an exercise for you.

Final notes

We've barely scratched the surface of unit testing and there's a lot more to it than just testing inputs and outputs. We haven't even discussed yet its best practices but that's enough for now. I hope that you get the rough idea of how to use unit testing to your advantage.

On Trunk-based Development

Gervin Guevarra — Fri, 09 Apr 2021 14:16:12 +0000

Observation and insights on our team's attempt at Trunk-based development

Background
Here comes the Trunk-based
- What's not comfortable?
- The transition
- Our experience and some insights
Verdict
Notes and Tangential Thoughts
Sources and further reading

Background

Earlier last year, our team was asked to switch from GitFlow to Trunk-based development. The change of course didn't happen without receiving opposition, complaints, and whatnots. But it is worth noting that using GitFlow has its own fair share of pain points, which is likely the reason why our engineering leads decided to try Trunk-based development instead.

Trunk-based development was introduced to us using the Microsoft's Release Flow, which admittedly I still don't know the difference versus the generic trunk-based development. Given that Microsoft have hundreds of developers (and at the time of writing, our IT engineering department is well over 200) and we are also using Azure DevOps, most thought it is probably a good idea that we also use the same strategy that Microsoft has.

But changing our process for the sake of imitating a model organization or fitting ourselves around a tool seems like a lame excuse. So what exactly needs fixing?

The GitFlow problem

One of my observations in using GitFlow is that it tends to have a lot and I mean A LOT of branches, some which are long-living, just to release a feature or issue fixes. Just take a look at this diagram:

Fig1. GitFlow branching strategy. Source

Having multiple branches isn't bad per se. In fact, GitFlow is great for simultaneously managing multiple versions, such as in our case, where we have different versions in production, UAT, and DevTest environments. I think GitFlow is really good at enabling developer independence and isolation of changes. That way, you can work with one version without worrying that the other versions will be affected.

But as our team and repositories grow, it became quite difficult to have a mental model of it. There were also occasions when our team forgot to merge the release branches back to master and develop. There is also a latency (for the lack of a better term) before the fixes issued in the release branches becomes available in the develop branch, where other developers are already working.

Here comes the Trunk-based

If using GitFlow has become difficult, then why are we not willing to try a different strategy? Well, there's a couple of reasons but everything probably boils down to comfort.

What's not comfortable?

Since we started migrating from monorepo to service repo (that's one repository per microservice), different squads can have their own branching strategy especially those that work exclusively with the backend services. Our squad decided to use GitFlow because we wanted to clearly separate the branch we are working on (develop) and those that are in different environments (release, prod/master).

This was not the case with our front-end teams as they have been using trunk-based development ever since (as what I've been told). And from different anecdotes around the office, we hear that they often have issues with some commits getting removed or replaced by accident. That's like reading bad user reviews on Amazon or [insert your favorite online marketplace here]. Can't expect us to be happy knowing that we're going to move to something that messy.

We also expect that there will be a learning curve in every adoption of a process or technology. While we welcome learning opportunities, at that time we were in the middle of multiple releases. Given the time that we have, inserting steps or modifying our existing processes doesn't sound justifiable if we just going to do it for the sake of compliance.

Then there's the notion of cherry-picking, which seems to be norm in trunk-based development. We are wary of using cherry-pick as it feels hacky and probably prone to mistakes. We also rarely use cherry-pick so again this is about the team not being comfortable with our level of knowledge on something.

The transition

We merged our feature and release branches to develop, then merged develop to master. Develop is now deprecated and we will now be merging only back to master as it is now the trunkline.

The change wasn't sudden, and it took as weeks if not months before completely shifting to it. This is due to several releases at the time that has to be completed and merged back to master first. The sad thing was, as far as I know, that there was no concrete plan for the transition. Looking back, it probably was a good thing that we were left to do it at our own pace. With delivery deadlines approaching, we're probably more concerned with how the change would disrupt our timelines rather than the strategy itself.

Our squad at the time was managing about 7 repositories and they all have to switch to trunk-based. A bit inconvenient, yes, but something we are willing to take on in hopes of having a better workflow.

It probably won't be fair if I judge it just after a few weeks of use. So I'm gonna stop here for now and come back to this write-up after a few months...

(I actually forgot I was writing this, so it took longer than it should haha)

Our experience and some insights

It was not as chaotic as I expected, but it's definitely not the promise land we hoped it would be. One advantage that I see is that all of us can confidently pull from master every time, knowing that all the changes are always merged first to it. This solves the above mentioned problem where we sometimes forget to merge the release branch back to master.

The trade-off, however, seems a little too much than the benefits we're reaping. In the absence of feature flags, it's quite hard to manage which gets to production and which doesn't. Suppose there are 3 sets of code changes and let's call them FeatureA, FeatureB, BugFixC. FeatureA and FeatureB are independent features, while BugFixC is a fix issued to address the bugs found during [manual] testing. After applying the fix, FeatureA+BugFixC is ready to reach production but FeatureB isn't (i.e. because it hasn't gone through QA yet or some other sort of manual testing).

What happens is that we checkout a branch from FeatureA merge commit then we cherry-pick BugFixC to it. Perhaps not an elegant way, but this is the only option we know so far given that we haven't invested time to learn and develop our features around feature flags.

Verdict

The truth is I still don't know.

This might be rather disappointing after the lengthy blabber but my knowledge of trunk-based development is severely limited to what we are currently doing in our squad. While some of my peers are convinced that trunk-based development is another cargo cult, I think that it is our own execution and development process that is failing us. I've talked with friends, former colleagues from other organizations who are currently using trunk-based development and they are finding success with it. So I'm leaning towards the possibility that we are really just not using it correctly and were unable to maximize its potential.

So are we going to continue using it? Yup, and I don't see us changing it anytime soon. Doing so will be another learning-curve that we have to overcome.

And we haven't even climbed this trunk yet.

Notes and Tangential Thoughts

Resistance to change might actually be a good thing. It makes us think about the implications thoroughly and it also shows that we really care about what we do.
You may have noticed my usage of the term "squad". We are trying to adopt the Spotify-flavored agile. Whether that's a good idea or another cargo cult destined to fail is still subject for observation. Currently, there are a lot of difficulties and there seems to be a relapse to non-agile methodologies. I don't think we are doing it right (yet), which perhaps is the reason why we are also having difficulties with our branching strategy. Maybe our processes should mature first, then hopefully our branching strategy will soon evolve to fit our needs.

Sources and further reading

Disclaimer: views, thoughts, and opinions expressed in this text belong solely to the author, and not necessarily to the author's employer, organization, committee or other group or individual

Cover photo by niko photos on Unsplash

Finally starting a blog

Gervin Guevarra — Fri, 09 Apr 2021 11:43:20 +0000

Cover photo by Glenn Carstens-Peters on Unsplash

Hello World, Hello Dev! I'm Gervin and I have been a lurker here in dev.to since 2017 (I think it was still called Practical Dev back then?), around the same time I started my career as a software engineer.

Fresh from college, I was hungry for knowledge and immersion. I was really glad when I found this community. I never knew that there's so much more in software development than just knowing how to write code, and dev.to helped me realize that.

As one former colleague puts it:

Oh how wrong are you, my sweet summer child

Aside from reading lots and lots of articles here, I always dreamt of writing my own blog and sharing my thoughts with the rest of the world. I always enjoy discussing with my friends and colleagues about crafting software, so I thought maybe it would be fun too if I put them down in writing.

And so I made multiple drafts about different topics here and there but I ended up not publishing anything for 3 years. Most of which either went to the bin or were stuck in the eternal drafts folder haha!

What's stopping me?

Well I think there are two things: I'm lazy and there's this paralyzing fear of a blank canvas (or paper/editor, I guess)

Though I'm not proud, I'm not denying that I'm lazy as f*ck. I would always find some good alibi not to start something or avoid it altogether. Taking "minimizing the work that needs to be done" to the next level except in a bad way.

Then every time I get a sliver of inspiration to get things done, I feel like the blank editor is staring back at me pressuring me to write something perfect - words flowing with wisdom and expertise. But boy, I'm not a prolific writer and English isn't even my native language. How am I supposed to do this and do it well?

Yup, there's the alibi.

Getting over perfectionism

I've been called a perfectionist a handful of times, but never took them seriously as I always felt that I'm not doing good enough or perhaps they were just sarcastic. It was not until I came across this article (which was stuck in my reading list for so long, by the way), that I tried reevaluating myself.

Laziness Does Not Exist. Psychological research is clear: when… | by Devon Price | Human Parts

Devon Price ・ Jul 15, 2020 ・
humanparts.Medium

And to quote:

When a person fails to begin a project that they care about, it’s typically due to either a) anxiety about their attempts not being “good enough” or b) confusion about what the first steps of the task are. Not laziness. In fact, procrastination is more likely when the task is meaningful and the individual cares about doing it well.

Maybe it's in the nature of writing that you have to expose yourself and be vulnerable, for your thoughts are no longer only yours. So you'd want to put enough effort to it to make it factual and enjoyable to read. It's a part of you after all.

Perhaps, I have just been overthinking. And in my pursuit of writing good essays and articles, I forgot that all I really wanted is to share, discuss, and learn ideas with everyone else.

YOLO

So here's me attempting to get it going, starting to setup my profile and writing my first post. I'll try to stop being overly conscious and just put it out there no matter how short or long, good or bad.

Maybe I'll make mistakes, but those will also be precious learning opportunities.

Maybe I don't and everything goes well. Then I guess I'll just have fun writing again.

Relevant articles