GDPR 🌎, Access Modifiers 🔒, Access control 🕹️ Design Patterns 🧩 , SDE for 2 years 🧑🏻‍💻

Techletter #71 | May 4, 2024

What is GDPR?

GDPR, or the General Data Protection Regulation, is a comprehensive data privacy law in the European Union that aims to give individuals more control over their data.

It applies to any organization that processes the personal data of individuals in the EU, regardless of where the organization is based. This includes companies outside the EU that offer goods or services to people in the EU.

It establishes several key rights for individuals, including the right to access their data, the right to be forgotten, the right to data portability, and the right to know when their data has been hacked.

Violations of GDPR can result in significant fines of up to 4% of a company’s global annual revenue or €20 million, whichever is higher.

So, if you are building software that is GDPR compliant, make sure to go through all docs, before your release.

What are access modifiers in TypeScript?

Access modifiers are keywords that control the visibility and accessibility of class members, such as properties and methods.

There are three main access modifiers:

• Public: Public members can be accessed from anywhere, both inside and outside the class. This is the default access modifier if none is specified.
• Private: Private members can only be accessed within the class they are defined in. They are not accessible outside the class.
• Protected: Protected members can be accessed within the class they are defined in, as well as in any derived (child) classes.

class Animal {
    protected name: string;

    constructor(name: string) {
        this.name = name;
    }

    protected makeSound(): void {
        console.log('Sound made by the animal');
    }
}

class Dog extends Animal {
    private breed: string;

    constructor(name: string, breed: string) {
        super(name);
        this.breed = breed;
    }

    public introduce(): void {
        console.log('Introduce');
        this.makeSound(); // Accessing protected method from base class
    }
}

Access control design patterns

1. Discretionary Access Control (DAC) Pattern: This pattern uses an Access Control List (ACL) to define which subjects (users, processes) have what permissions on objects (files, resources).
2. Role-Based Access Control (RBAC) Pattern: This pattern introduces the concept of roles, where permissions are assigned to roles rather than directly to subjects.
3. Attribute-Based Access Control (ABAC) Pattern: This is a more flexible pattern where access decisions are based on attributes of the subject, object, and environment, rather than just the subject’s identity or role.
4. Metadata-Based Access Control (MBAC) Pattern: This is a variation of ABAC where metadata about the subject, object, and environment is used to make access control decisions.
5. History-Based Access Control (HBAC) Pattern: This pattern takes into account the past actions and behavior of a subject when making access control decisions, in addition to the subject’s identity, role, or attributes.

My 2 years of software engineering experience

After working as a software engineer for 2 years I did learn a few things. Here is the list of the top 8 out of many.

➡ Software is valuable only if it adds value, else is just a piece of junk. The same applies to the features inside the software.

➡ The main advantage of being a software engineer is that you will learn something new every single day. It’s not something compulsory, you may not learn new things as well, but the problems you face will put you in a situation where you don’t have any other choice other than learning and solving the issue at hand.

➡ Programming is a wonderful skill to have. But, at the same time, you need to have a great understanding of the business context, as well as the users who are going to use your software.

➡ User experience is very important. Users don’t care how good is your backend code, they just need the work to be done quickly and efficiently.

➡ What to build and why to build is more important and must be dealt with first. Then ask the question of “how to build”.

➡ There is no such thing as perfect software. Sometimes building for 80% of the use cases will solve 99% of the user problems.

➡ Sit with users, and see how they use what you have built (maybe the initial prototype) and then tweak what you have built. (Usually, companies have PM for doing such things, but it would be great if we as developers do it).

➡ It is not just about building software you need to consider database, server, and development costs as well. It is this factor that decides whether should we really build it or buy it.

What is ‘static’ keyword used for in TypeScript?

The static keyword is used to define properties and methods that belong to the class itself, rather than to instances of the class.

This means that static members are shared among all instances of the class and can be accessed directly through the class name without the need to create an instance.

class MathUtility {
    static PI: number = 3.14;

    static calculateArea(radius: number): number {
        return this.PI * radius * radius;
    }
}

// Accessing static property
console.log(MathUtility.PI); // Output: 3.14

// Accessing static method
const radius = 5;
const area = MathUtility.calculateArea(radius);
console.log(`Area of the circle with radius ${radius} is ${area}`);