DEV Community: Kudzai Tsapo

More features? Bad idea!

Kudzai Tsapo — Tue, 15 Feb 2022 09:05:24 +0000

Very funny thing happened at this other fictional tech company called SomeCrazyTechCompany LLC. The project manager and business analysts always sat down and discussed requirements, as well as client changes. As usual, the client wanted more features, and as usual, the BAs obliged.
One day, the developer who worked on the system quit, and the company hired another poor soul to take over. Everything went as you would expect. The developer struggled heavily to maintain the system. Let's not talk about bugs, and more requests for features.

A friend of mine seems to have the same issue. Her problem is not the client; in fact, I could say she is the problem. Clients always request more features and changes, but in this case, she's the one who more or less asks the developers to make the changes without consulting with the client. And also add more features. And as you would expect, once the system goes into production, it's a mess of bugs and more bugs... and even more bugs.

For a small system, it's very easy to maintain, discover bugs, and test thoroughly. However, as the system becomes larger and larger, it becomes more difficult and time consuming, to test thoroughly. So, most people usually check to see if it's working, and then update the feature/bug card on the project management tool. However, the issue is, a few minutes later, the same problem will resurface. Or even worse, something will explode ... and it will be related to this problem.

Unfortunately, as much as it might be great to make a small system, it's very much impossible to keep the system small. What I'm saying is, due to some unfortunate circumstances, that have absolutely nothing to do with the scope of the article, everything will explode at some point.

There's a wise dude who once said, where there's a possibility of things going wrong, they will go wrong. He was right. And this can be seen in the Software Development sector. If there's a chance that your system will explode, then everything will go haywire. If it's a smaller system, then it's easier to manage. What about when it's a giganticous (not a real word, I know) monolith? Good luck.

That brings me to something else. Solutions to this issue, if there are any.

A group of people realized that having a large system was a recipe for disaster, or a disaster waiting to happen, or something worse. Being as clever as they are, they decided to break their system into multiple smaller systems. Someone went so far as to give it a name: Microservices Architecture. It was awesome, because if something breaks, you know exactly what broke, possibly why it broke, when it broke, and very much possibly how it broke. It would take a few minutes to fix it, if you're that good. And a few years, if you aren't.

The problem with this approach, since everything has a problem at some point, is that when you have 200 small systems to maintain, and there's only one of you, how do you do it? Or maybe there's 2 of you ... or 5 ... either way, how do you do it? Do you go and clone yourself and then assign your clones to maintain the systems?

Well, I just thought I should put it out there for people to think about, if they weren't already thinking about it. Next time your client wants you to create another feature, make sure you know exactly what problems you'll encounter. Once you've managed to somehow do it, make sure you test thoroughly, whatever that means. And make sure to cover all angles, including the ones you think don't matter. When you've exhausted all possibilities, then you should know that once the monster is in production, you might have issues maintaining it a few months from now (if you're lucky). If you're very unlucky, the monster will blow up the moment it hits production, and the users start using the system.

Life's great. Bugs aren't. So, before you develop more of those, or ask someone to, think twice or three times. Or four, just for good measure.

Tale of the Snake Charmer: Why you should learn Python.

Kudzai Tsapo — Mon, 24 Jan 2022 10:59:46 +0000

It has been several decades since a wise Sage went to the Amazon rain forest. After getting lost, he was found by the natives, who taught him how to speak their language. When he returned to his civilization, he decided to teach the machines how to speak the language.
Fast forward several decades later, Python is one of the most popular programming languages, being used for a variety of tasks which include but are not limited to Machine learning, web development, and mobile app development.
Fast forward a hundred years later,the robots are taking over the planet. There's wanton destruction everywhere, shopping malls are collapsing, and cars are being burnt. An old man peers from a glass office, watching all the events unfold. With tearful eyes, he sighs and says, "If only I hadn't built that damn model with Python!"

...

In case you hadn't noticed, I made up most of the events written up there. There's no moral of the story, if you're wondering.
So, what's the purpose of the article? Basically, it's to give advice to those who need it, and for those who don't, you can click the back button on your browser.

To be fair, Python is one of the awesome programming languages I've used. It's so easy to learn, compresses a lot of lines of code into a single line. It can also be used for a variety of tasks, from developing mobile apps, to web apps, to machine learning models.

Just like how there are huge fans of the language (e.g. me), there are also haters. They'll be quick to point out its flaws, but as far as you and I are concerned, they can go and f ... eh ... sleep.

So, why should you, an awesome person, learn this awesome language?

1. Because you can.

First rule of life, there are no rules ... eh ... apart from the laws of your country, laws of physics etc, but you get the point. Nothing restricts you from learning something, except if you don't want to. In fact, open your browser, download Python and get started right away!

2. You want to get into data science

One of the reasons why I love python, is the fact that we can prophesy the future using code! (I'm lying of course ... lol) What I mean to say is that, as human beings, we can notice repeating patterns, and try to predict when the next event is going to happen (Think the stock market, wanna try and predict when Tesla stock is going to fall, or rise?). We can come up with statistical models of these events, and Python makes it easy to do so. It has a snake-skin bag of libraries that you can use to achieve whatever goals you want in this field.

So, if you want to get into data science, you should learn python! There are no negotiations (unless you want to learn Matlab and R, in which case, be my guest).

3. AI will take over the world some day

When this happens, you'd want to cash out on it, right? You'll be one of the wizards who developed Skynet, and caused the apocalypse ... Just kidding! When flying, self-piloting cars and robots have been developed, wouldn't you like to puff out your chest with pride, and say, "I contributed one line of code to this future" ?

4. You want to be a tech billionaire?

Ah yes, one of the primary motivations of why people do anything at all! Money! 🤑 So, let's say, you've heard that it's now easy to become a billionaire. The person who told you this said you just had to create a web app, launch, and in a few years you'd be one. Well, I'm sure the person who would've said this would be joking, but jokes aside, using django, it is easy to develop prototypes and it cuts development time by like 50% (I might be lying but 🤷‍♂️). There's also flask, which is so light-weight, you'd wonder if it no bones will break upon deployment. Not forgetting FastAPI, which is awesome for developing APIs apparently (haven't used it much so I dunno).

Anyways, when you become the tech billionaire you've always wanted to be, don't forget to remember this article 🤣 .

So, the key take away points are:

You're awesome
Python is really awesome.

There are many reasons why people do things, and I don't know why you want to learn Python. However, I can safely say you're making the right decision 👍 , unless you're planning on taking over the earth with your droids, in which case no! It's a really bad idea!

What I learnt developing a system in a couple of days.

Kudzai Tsapo — Sun, 24 Oct 2021 17:05:23 +0000

So, being as bored as I was this weekend ( not really ), I saw a picture of a database schema while browsing the net. I then asked myself, how long would it take me to implement that thing as an entire system? 🤔
Considering I'm totally notorious with not finishing projects, I decided to give myself the Ultimate deadline of two days ... (lol), just to make sure I wouldn't spend anymore unnecessary time on it.
You know what the funny thing is? I actually managed to finish the project this time 😅. I mean, that's the purpose of the article 😅.

Anyways, for the curious, the project can be found on github, the user interface here and the API here.

I made the API using Asp.net core, and the user interface, I used react + tailwind (an awesome combo apparently). I tried to make the system as simple as I could, but then stuff happened and it ended up being somewhat ... complex.

After meeting my weekend deadline, there are a couple of things I learnt:

As you approach the deadline, code quality decreases

Some times, when you're about to reach a deadline, and there's still a ton of features left to develop, you start saying "SCREW IT" to some of the coding conventions. You start copy/pasting code, completely violating D.R.Y. principles. Readability? Who cares when there's a deadline approaching?

Thanks to pressure, some features get left out

I was giving myself so much pressure, I ended up leaving out a lot of features undeveloped. I know what you're thinking, how did I finish the project if I left out some features? 🤔

...

Anyways, I ended up prioritizing some features over others, and hey, who can blame me? 🤷‍♂️

Bugs

The only code without bugs ... is code that hasn't been written yet. In reality, every code has bugs, and as you approach a deadline, the pressure makes you to introduce more bugs. Some are noticeable, and some of them you only notice them when in production ... and something is burning.

Performance

What's that?
....

Just kidding. As you approach the deadline, you stop caring about performance. Of course, the code can be refactored later when all the servers are on fire, the client is yelling, and the users are calling non-stop.

I know most of these things are probably common, a lot of you have experienced them beforehand. That doesn't mean of course, that there isn't anyone who hasn't.

Here are some of the screenshots of what the system looks like:

Right, I know what you might be thinking ... What's with this guy and HR funny systems? Who knows?
...
Anyways, Just thought I could share what I learnt during the weekend, for the benefit of others who haven't.

Spring security, CORS and Axios!

Kudzai Tsapo — Fri, 12 Mar 2021 15:34:47 +0000

Right, I was happily enjoying my day, doing awesome stuff ( not really ), when I got a message that my API was causing CORS issues!

Now, I thought this was weird, considering I had fixed those issues at the beginning. Last time we faced CORS issues, it was because someone was using an incorrect URL ( which of course didn't exist ), so the preflight request got a 404 error, resulting in the blasted CORS error.

Today, I thought it was the same issue. And boy, was I super wrong! After spending the whole day debugging why axios was being a ~~bitch~~ pain-in-the-somewhere, I totally realized something funny was going on. The URL was correct, meaning something else was going on.

So, what I finally realized was that Spring Security, by default validates OPTIONS requests, which are sent by Axios in a preflight request. And that's when it hit me, I had forgotten to disable that. 😅

All I had to do, was to go inside my WebSecurityConfig class, and inside the configure, put a http.cors(). Simple, right? Ah well, give me a break!

JPA, MySQL and UUIDs are not friends, apparently...

Kudzai Tsapo — Tue, 02 Mar 2021 22:53:36 +0000

Today I was being myself as usual, creating an API with a UUID as a primary key. All was well, until JPA decided it wasn't. 😑

I had created a OneToOne relationship between one entity, and my User entity ( which had a UUID as Id ). In my defense ( before you start judging ) everything was working well. However, I started getting inconsistencies.

I had a method for retrieving paginated entities, and this method started throwing some EntityNotFound exception! After some hours of googling what was the problem, I found a work around, which was putting a @NotFound on the relationship. This is ... eh ... not quite a good idea, so I decided to screw it.

That's when I discovered the problem was that JPA could handle UUIDs, but MySQL had issues. Apparently, mysql stored UUIDs as binary, and JPA was trying to search using the UUID as a string, and that wasn't working.

What I didn't get though, was why on one method it was working perfectly, but on another, being inconsistent. If there's anyone who can explain to me WTF caused this issue, please feel free to say something.

Spring boot error messages disabled!

Kudzai Tsapo — Sun, 28 Feb 2021 22:03:42 +0000

So, I went through a lot of hell trying to figure out why the f-word my messages weren't showing. Guess what? Apparently, the are now disabled by default! 😑

After spending a few hours wondering why my code wasn't working, I finally stumbled upon the reason.

Apparently, the default value for server.error.include-message is "never".

So, I went into my code (application.properties) and had to do the following:



server.servlet.context-path=/api/v1
server.error.include-message=always
server.error.include-binding-errors=always

...
What's that? It's non-standard, you say?
Well, get off my back! It works, doesn't it?

In case someone is having the same issue and like me they're wondering wtf is going on, this should be able to help.

Making an HR software with Spring Boot Part V

Kudzai Tsapo — Tue, 20 Oct 2020 08:00:37 +0000

Now, let's talk about a topic that's not so near and dear to my heart: relationships 😬. Of course, I'm talking about the only relationships that programmers are really good at ... database relationships!

Anyway, before we go into that, there's something I forgot to put at the end of the application.properties. Copy paste this line:

spring.jpa.database-platform=org.hibernate.dialect.MySQL5Dialect

I'll not be explaining what this line does (I'm lazy lol). Now that we're done, let's continue on to relationships... (cough cough). Right, we know that an Employee has a Job, and is under a Department, is allowed to take many LeaveDays, and can misbehave multiple times. From this alone, we now have our database relationships...

Open the Employee.java and paste the following code (which of course I won't be explaining...):

...

@OneToOne
@JoinColumn(name = "job_id")
private Job job;

@OneToOne
@JoinColumn(name = "department_id")
private Department department;

@ManyToMany
@JoinTable(name = "employee_misconducts", 
joinColumns = @JoinColumn(name = "employee_id"),
    inverseJoinColumns = @JoinColumn(name = "misconduct_id"))
private List<Misconduct> misconducts;

@OneToMany(mappedBy = "employee")
private List<LeaveDay> leaveDays;

...

Open Job.java and put the following code:


...

@OneToMany
private List<Employee> employees;

...

When you're done with that, put the following code inside LeaveDay.java:


...

@ManyToOne
@JoinColumn(name = "employees_ecnumber")
private Employee employee;
...

Afterwards, put the following code inside Misconduct.java:


...

@ManyToMany(mappedBy = "misconducts")
private List<Employee> employees;

...

And with that, we can say we're done-ish. Obviously, there are a lot of things that can be improved, but then again, we're not perfectionists ( I know I'm not! ). Anyway, in the next tutorial, we are going to finish up on the API by making repositories, controllers and DTOs. Enjoy your day ... or night ... chao 👋

Making an HR software with Spring Boot Part IV

Kudzai Tsapo — Thu, 15 Oct 2020 06:54:14 +0000

Welcome back ...eh ... if you're still following this tutorial. Anyway, I'm going to start by explaining what happened in the last tutorial and why ...ish.

So, I'll start with explaining the application.properties thing which I told you to do. First the line spring.jpa.hibernate.ddl-auto=update is a spring configuration which is used by Hibernate for DDL generation. I'm not going into more details, since the tutorials would span for 100 parts ... which ... isn't really a good idea. Anyway, spring.datasource.url is a configuration for specifying the database host, port, name and type. As for the rest of the configs, they're just the database credentials.

Welp, now we're done with the configs, let's move on to the code. Instead of writing getters and setters for the class, I used Lombok, which does that for me. That's why there are the @Getter and @Setter annotations. Again, I'm going to skip the entire explanation for how they work.

@Entity annotation is used to tell JPA that we're going to be persisting the Employee objects into the database. In most cases, the name of the table in the database and the name of the entity will not be the same. This is why I used the @Table annotation, so that I can specify the name of the table. Of course, there are more things I could have specified, but for now, this explanation suffices.

And then there are the column attributes. Honestly, I'm gonna skip explaining those because I feel like I'm running out of space.

Now, let's go back to work. Where was I? Right, we have the employee model defined. Let's define the rest of them. For the record, I'm going to be posting the code here ... if you have any questions, I'm sure you can post them in the comments. Now, the Project Manager is angry because he believes you're wasting time. So, let's get back to work!!

First, we'll start with jobs ... So, create a file under models, with the name Job.java and paste the following code ...

package com.dull.piqued.models;

import lombok.Getter;
import lombok.Setter;
import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import javax.persistence.*;
import java.util.Date;

@Getter
@Setter
@Entity
@Table(name = "jobs")
public class Job {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private long id;

    @Column(nullable = false)
    private String title;

    @Column
    private double minSalary;

    @Column
    private double maxSalary;

    @CreationTimestamp
    private Date createdAt;

    @UpdateTimestamp
    private Date updatedAt;
}

After the Job model, we have the Department model.

package com.dull.piqued.models;

import lombok.Getter;
import lombok.Setter;
import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import javax.persistence.*;
import java.util.Date;

@Getter
@Setter
@Entity
@Table(name = "departments")
public class Department {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private long departmentId;

    @Column(nullable = false)
    private String name;

    @CreationTimestamp
    private Date createdAt;

    @UpdateTimestamp
    private Date updatedAt;
}

And then leave days:

package com.dull.piqued.models;

import lombok.Getter;
import lombok.Setter;
import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import javax.persistence.*;
import java.util.Date;

@Getter
@Setter
@Entity
@Table(name = "leave_days")
public class LeaveDay {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private long id;

    @Column(nullable = false)
    private Date startDate;

    @Column(nullable = false)
    private Date endDate;

    @Column
    private Date dateApproved;

    @Column
    private String leaveType;

    @Column
    private String description;

    @Column
    private String leaveStatus;

    @CreationTimestamp
    private Date createdAt;

    @UpdateTimestamp
    private Date updatedAt;
}

Following that, we have misconducts. Remember, HR is supposed to record all misconducts that an employee does, and then if they are suspended for eternity, that is supposed to be recorded as well.

package com.dull.piqued.models;

import lombok.Getter;
import lombok.Setter;
import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import javax.persistence.*;
import java.util.Date;

@Getter
@Setter
@Entity
@Table(name = "misconducts")
public class Misconduct {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private long id;

    @Column(nullable = false)
    private String name;

    @Column
    private String description;

    @Column
    private Date dateOccurred;

    @Column
    private String punishment;

    @Column
    private String punishmentDate;

    @CreationTimestamp
    private Date createdAt;

    @UpdateTimestamp
    private Date updatedAt;
}

I know the punishment could probably have gone into a different model, but since I'm too lazy to do that, we'll leave it there ... Now that we are done with the models, we are now going to be implementing relationships 😬 in the next tutorial ... chao 👋

Making an HR software with Spring Boot Part III

Kudzai Tsapo — Mon, 12 Oct 2020 14:04:49 +0000

Right, now we have managed to come up with a database of sorts. What we need to do is to initiate the project, and implement the database, correct? So, we'll head over to start.spring.io to initialize our project.

Let me say something in a bit.
First off, I really don't like gradle so I'll use maven instead. Another thing, please do pay attention to the java version down there. Use Java 8, it works ...

After clicking generate, the project should be downloaded as a zip file. Open the project using your favorite editor ( mine is intellij idea )

The project should like this:

Last time I had an argument of sorts with a workmate/acquaintance of mine over project folder structures. To be fairly honest, at the end of the day, it depends on your preference. If you feel like my folder structure is weird ... then good for you!

Anyway, I normally use the following structure:

I love this structure because it creates a separation of concerns. Models have their own folder, DTOs have their own folder and controllers have their own folders ... and so on. Like I said earlier, it's just a matter of preference.

Anyway, stupid things aside, now we are going to be implementing the models. First, we'll start with the Employee model. Java is object oriented, which means that everything is an object ... eh ... I'm sure you understand.

To be honest, I'm very lazy. As most lazy people do, I'm going to use lombok instead of defining getters and setters manually.

Anyway, before we get into that, we need to open the application.properties under src > main > resources and put the database configurations there.

When done with that, let's get into defining the model. Under the models package, create a new file called Employee.java. The initial code, before defining the relationships, looks like the following:


package com.dull.piqued.models;

import lombok.Getter;
import lombok.Setter;
import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import javax.persistence.*;
import java.util.Date;

@Getter
@Setter
@Entity
@Table(name = "employees")
public class Employee {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(nullable = false, updatable = false)
    private long ecNumber;

    @Column(nullable = false)
    private String firstname;

    @Column(nullable = false)
    private String lastname;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false, unique = true)
    private String phone;

    @Column(nullable = false)
    private String physicalAddress;

    @Column
    private double salary;

    @Column
    private Date hireDate;

    @CreationTimestamp
    private Date createdAt;

    @UpdateTimestamp
    private Date updatedAt;

}

Now, I'll explain what the code does in the next tutorial... chao 👋

Making an HR software with Spring Boot Part II

Kudzai Tsapo — Sun, 11 Oct 2020 10:49:05 +0000

Welcome to the second part of this not really awesome tutorial, on how to make an employee management system in java. In the last tutorial, we decided ... actually, I decided to describe what we are going to be doing, and why ...ish.

Now, I know I unilaterally decided on the technology stack, so let me go back to that for a bit. The Dull Company makes underground bunkers for presidents and rich people (umm ... yes). It has been operational for a few decades, and it employs a a few hundred people. Since Aware is a Java based software, the new IT Director is convinced that Java is the best language for developing software (don't ask me...). Therefore, all IT based systems, even the once they have outsourced, are all Java systems. With his bias, he told you to use Java with MySQL, hence the Spring Boot unilateral declaration. Anyway, there are other technology stacks included in the entire package, and these include but are not limited to Elastic Search and Apache Kafka, and for DevOps, there's Jenkins, Docker and Kubernetes. However, I will not be covering these technologies in this tutorial series. (Because I'm too lazy lol)

So, in this tutorial, we are going to design the database of the system. Actually, scratch that. I'm going to post an already made database design, and I'll try my best to explain how I came up with it. The software I used to make the database design is draw.io.

Of course, the database could be better, and of course, there's a better way of doing things. However, this way works, and it's for educational purposes. Therefore, it'd be nice if someone could give me a break.

Anyway, continuing with our scenario, as the software engineer, you have managed to sit down with HR, and they've given you the requirements. The requirements are as vague as they can be, and someone even had the decency to draft a "requirements specification document". Don't ask me who!

However, you, being smarter than everyone, manage to figure out what the company needs. And yes, scratch what they want ... (ahem). So, going through the SRS, you know that every employee is under a department. Each department has a manager, and this is a job title given to privileged individuals (ahem). There are different job titles, for example, you being a Software Engineer, means that is your job title under the IT department.

Every employee is entitled to leave days, and if an employee misbehaves, it must be recorded in the system.

So, above is the diagram I've drawn using draw.io, and that's what we're going to be using for the database. Now that we're done with database design, we're going to start implementing the database in the next tutorials.

Yes, I know the database diagram can be better, and some parts might be total BS (ummm), but then again ... it works! (I know it does) Let's continue in the next tutorial...

Making an HR software with Spring Boot Part I

Kudzai Tsapo — Sun, 11 Oct 2020 10:38:32 +0000

So, this other day I decided to start learning Spring Boot, and I really grew to despise the todo list tutorials people made. Of course, for beginners, they are okay. But when you're done, the question will be now what? Hey, at least you know how to make a todo list, right?

We are going to be making an employee management system. Why you ask? Just because!

Anyway, using Spring Boot with MySQL, we are going to build an employee management system. This system will be for managing employees and their leave days, salaries and all of that nonsense. It's also going to be keeping track of all their suspensions, misconducts ... etc.

The technologies we are going to use include but are not limited to:

Java (Spring Boot) for the API
MySQL (Database)
VueJs (for the front-end dashboard)
Probably Bootstrap for the UI

Who is this tutorial for? I don't know! I just decided to make a tutorial to show how awesome I am ... or maybe how terrible I am at software development. It's up to you to pick one at the end. By the way, I'm a complete noob when it comes to Vue, so if you know a better way of doing things ...eh ... good for you!

For the lazy ones, the code is available on github, here. And if you see the code incomplete, then hold your horses... it's still a work in progress after all.

So, where do we begin?

First, we'll start by describing a scenario. What problem are we solving, and why? (the why might be a little fuzzy but hey...at least it's there) By the way, all names specified in the scenario are purely fictional (I made them up), and any resemblance to actual people and organizations is purely coincidental (it wasn't planned!).

Congratulations, you've managed to land a job as a software engineer at the Dull Company (Pvt) Ltd. Now, before you came along, the Dull Company was spending millions of dollars annually on a crappy outsourced software called Aware. The system didn't work 99% of the time, and when it did, it was mostly due to a bug. However, because it was recommended by a previous manager, the company stuck with it. The CEO was outraged when he realized that they were spending that much money on a stupid, non-working program. Being the genius that he's not, he told the company to hire a software engineer to develop and manage internal systems. This is where you come in.

We are not going into the details of how you got the job, but after you come in, your first project is to develop a system for managing employees. This software is supposed to replace Aware.

Now, we are not going to go through the entire SDLC, and of course we are going to assume that you're given all the requirements. (Don't ask me why?) Anyway, we are going to jump in head first and develop the darn system for Dull Company (Pvt) Ltd. The first thing we are going to do is to design the database, and we are going to do this in the next article. So, go ahead and prepare your mind, it's going to be a long journey ahead.