In previous post we defined ADTs as

Algebraic Data Types (or ADTs) model the flow of a program (or a system) in terms of data & functions that describe the complete behaviour and states the data can go through.

In this post, we will work through defining ADTs for an API service.

API service will return User's Information by:

• Extracting user id & password from the request
• Checks them against an authorization service
• Retrieves User's Information from database
• Returns User Information in response

Read more…

Algebraic Data Types (or ADTs) model the flow of a program (or a system) in terms of data & functions that describe the complete behaviour and states the data can go through.

Let's take an example to grok the concept better.

Example: Area of a rectangle

Calculate the area of a rectangle from a list of positive integers

Here's a possible algorithm:

• Take a list of integers (positive & negative)
• Filter for positive integers ie., remove negative integers
• Create pairs from the filtered list
• Apply equation for area of rectangle

Read more…

Functional programming has many interesting concepts but it can be hard to find practical applications for it in everyday work. In this post, I will explain how Monadic Composition can be used write elegant and easy to understand code.

Consider an API Donatron that accepts donations. The API's algorithm is as follows:

1. Accepts donations as list of strings
2. Should have a few valid integer donations
   • Else goto 6. Response: No Valid Ints
3. Should have a few donations of value 10 or above
   • Else goto 6. Response: No Acceptable Donations Found
4. Valid donations to external service should succeed
   • Else RuntimeException
5. Log all accepted submissions
6. Log Response
7. Return Response

End goal is to be able to execute Donatron.donate function and get correct response.

Read more…

Rules of Software Engineering

There are three important rules in Software Engineering.

• Rule 1: Easy to understand. Anyone should be able to pick up the code and start working on it.
• Rule 2: Easy to debug. If the code breaks, it should be easy to quickly investigate & identify where is the issue.
• Rule 3: Shipping is the most important feature. No matter how correct or elegant your code is, if you can't ship working code on time then why bother?

Having said that, Rule 3 should rarely be in opposition to Rule 1 & 2. If you have to veto Rule 1 & 2 to ship your feature, then something's horribly wrong in your code & process. Complexity in code is a given and it is an engineer's responsibility to figure out how best to contain the damage and stop it from affecting the rest of the system.

Less elegant yet easy to understand & easier to debug should be the minimum expectation from all code shipped.

Read more…

Introduction

In our project workflow, we break down features to implement into tickets and developers pick them off one by one; Pretty standard & typical Agile/Kanban workflow. However while working on a feature recently, we came across on an interesting problem where our standard workflow didn't work out. Rather than trying to explain it in vague terms, I am going to start with a story.

TLDR

In case you don't want to dive in just yet, here is the idea we will cover in this post.

Think about the behaviour of your program in terms of data types & functions signatures. Next step is to prove or derive a function that composes all of the types & signatures to implement the feature. Then carry on to implement each of the individual functions with the guarantee that all functions will compose together.

Read more…

Cats Effect's Fibers/IOs run on a thread pool created over VM. They are essentially Green Threads that are created over the thread pool. Unlike async frameworks, IO.flatmaps does not include _asynchronous boundary. This means that essentially all of nested flatmaps are run within a single fiber. IO has mechanism to introduce asynchronous boundary but this has to be done manually by the developer via IO.shift. Operations such as race, parMapN or parTraverse inherently introduce asynchronous boundary.

~ 14th May, 22:11

Companies are interested in keeping the risk of their operations to a minimum. Software Developers want to learn and hone their craft. (This is not true for all developers and I don't speak for them.)

These two motivations don't align well with each other. Learning requies failure and unpredicability; Neither of which is good for company. Also, if you have employees who like to learn and experiment, they are more likely to innovate. The knee jerk reaction to this might be, "Yes! We WANT our employees to innovate!" But the reality is that not all innovation is good. More often than not, innovation can lead to creating silos and requiring special skills for developers to operate the tools. Tools that are unique and idosyncratic. This is not in company's best interest, because they want the cogs (Developers) in their machine to be replaceable. This is not malicious intent on the company's part, it just means that in case you want to leave the job for greener pastures then the company shouldn't get crippled and be able to move on and work efficently.

~ 5th May, 2AM & 11:30 AM

In general people like to say that one should not be bound to any particular language and instead should be able to switch languages as and when required. However it is also common to see that programmers, especially those with many years of experience, loathe this concept.

We tend to dismiss this by saying that they are set in their ways and that they are being stubborn & don't want to make the effort. However that might not be true in all cases, what a younger developer tends to not understand is that a veteran developer has spent an insurmountable amount of time understanding and mastering their craft. They have gained command over their tools of trade that allows them to bend the world to their will. Indeed it is a frightening thought to ask someone to abandon their previous knowledge and start from the beginning because they will always be conscious of the vast disparity between their skills of the old and the skill level they have now.

To a developer who still hasn't learned more than a few techniques, this is of little consequence. However, this becomes a very painful handicap for those who lose a lot by making such a transition.

~ 5th May, 1:25AM