DEV Community: Amin Rashidbeigi

My Thoughts on The Clean Coder Book

Amin Rashidbeigi — Wed, 30 Oct 2024 18:16:43 +0000

Introduction

Some time ago, I was searching for a book related to software but not purely technical, making it easier for me to read. I was looking for something I could enjoy even with a busy mind after work.

After checking my Goodreads to-read list, I decided to read The Clean Coder and started right away. The book's introduction hooked me, and I ended up reading it to the end.

To clarify, this post is not a review. There are already plenty of reviews for this book. This post is simply some of my thoughts on topics that were particularly interesting or debatable for me.

Saying No, at Any Cost

For a software engineer or a manager, it's common to face situations where a product manager or stakeholders ask to meet a deadline without enough time or resources. In these situations, many of us, including myself before reading this book, respond with “I will try.”

But this response creates an expectation that might not align with the reality that the task may not meet the deadline. By saying this, we often work overtime or on weekends, accepting significant risks, which I written in more details in the post Managing Overdue Tasks.

Uncle Bob states in Chapter 2 that you have to say no at any cost. It is not reasonable to say, “Okay, I will try.” However, sometimes the decision is already made, and you cannot alter it. In this scenario, I believe it's more pragmatic to communicate the situation to your manager or stakeholders as much as possible. They might have some incorrect assumptions about the technical details. After that, as engineers, we should try to find and offer alternatives to meet the deadline, even if it means cutting some corners. And to make it clear, by saying cutting corners I don’t mean reducing writing unit tests or deploying carelessly.

Know the Basics

Over time, the abstraction in software engineering has increased. With higher abstraction, there's much less need to know the basics of our field. If you have a computer science background, you've already studied most of them, but if you're from another field, you're likely to miss some.

Even though I studied computer engineering, I've forgotten a lot and sometimes only remember the titles.

But it's still important to read or review them. Despite hundreds of new ideas in our field each year, we can still improve our thinking and creativity by strengthening our computer knowledge muscles. Maybe there's no need to implement a merge sort for the rest of your life (except in interviews) with new AI tools, but the idea behind merge sort is still valid.

Uncle Bob recommends a list of areas that every software professional should be familiar with:

Design patterns. You ought to be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns in the POSA books.

Design principles. You should know the SOLID principles and have a good understanding of the component principles.

Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.

Disciplines. You should practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming.

Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.

By doing these kinds of exercises, our computer muscles become more powerful, and I believe that at some points in our careers, this will help us.

Practice at Home, Perform at Your Job

I remember periods in my career when I didn't learn much at work. I got upset and thought it had to be a short-term issue, so I tried to learn on my own. I read books and did some side projects like the Expedition Diaries. Although I might not have been wrong, the idea of "Practice at Home, Perform at Your Job" changed my mindset.

Uncle Bob compares programmers to musicians. A musician always practices to learn new things during training and at home, and when performing in a concert, they use their knowledge and skills without expecting to learn new things. As programmers, we should use our knowledge at work and not expect our employer to provide learning opportunities. If they do, that's great. But we shouldn't expect it because they already pay us for doing our job, and it's not their responsibility to teach us.

This changed my mind because now, if I find myself in a situation where I can't learn from my current job, I know it's not my employer’s responsibility. It's mine. By accepting this, I can make better decisions without complaining. I can do side projects, read books, or even change my job.

Know the Domain of Your Product

Another interesting topic the book discusses, and one that was a reminder for me, is knowing the domain of our team, project, and company. Developers write code for a product. By understanding the product domain and its metrics, it’s easier to collaborate with product people and stakeholders. It gives us the power to make better trade-offs and long-term decisions for the product.

Uncle Bob recommends that when joining a team, you should read some books, talk to experts, or talk to customers to get a better understanding of the domain.

In my experience, product owners and managers prefer to work with developers who understand the domain and help them make better decisions rather than those who just accept everything and act like coding machines. This is a huge benefit for every product team.

Conclusion

"The Clean Coder" is a simple and easy-to-read book that I enjoyed a lot. Although there were some parts I didn't fully agree with, it offered new and helpful content for me.

If you are a beginner in your career, reading this book can definitely help you. If you are an experienced coder, there are topics that may still interest you.

This post was originally published at My Thoughts on The Clean Coder Book. If you liked this post and want to see more, follow me at X/Twitter.

When to Start Secret Rotation

Amin Rashidbeigi — Wed, 30 Oct 2024 18:13:23 +0000

Have you ever accidentally pushed a sensitive password and realized how difficult it is to ensure no one gains access to it? Or have you mistakenly logged an API token, and now it's scattered across your logging system?

In these cases, the first thing you'd do is change the secret. But what if you never caught the log in the first place? Or how can you be sure no one else has pushed sensitive data? This is where Secret Rotation comes in.

What is Secret Rotation?

Secret rotation is the practice of regularly updating or replacing sensitive credentials used in applications and systems. These credentials could be anything from passwords and API keys to encryption keys, certificates, or other authentication tokens. The process can be either manual or automated using secret management tools like AWS Secrets Manager.

When Should You Start Secret Rotation?

You might think secret rotation is something only big companies with many employees or years of experience need to worry about. However, waiting too long to implement it can make it too expensive to adopt. Secrets often spread across different projects and teams, making it costly and complicated to change a single secret.

Once, while working on a project, I was given a key with high-level access to modify data I didn't need. When I communicated it with my manager, I discovered that many others used the same key across multiple projects. Changing it became a considerable challenge because not only did every user need to update their keys, but we also had to identify all the projects using this key. If we disabled it, many things could stop working. The complexity and risk made it challenging to take action, forcing the team to explore other out-of-the-box solutions.

Why Start Secret Rotation Early?

We've realized that starting secret rotation late can make it hard to change. But there are other benefits to starting early as well.

If a team starts using secret rotation early, it becomes part of the culture. The idea that secrets should be easy to change gets built into the development process. The team will always keep in mind that the product should allow for easy secret changes. This makes automation easier, and developers feel more comfortable admitting they accidentally committed sensitive data because it can be changed easily.

While no system can ever be 100% secure, secret rotation helps reduce the risk of data leaks, especially when they go unnoticed.

This post was originally published at When to Start Secret Rotation
. If you liked this post and want to see more, follow me at X/Twitter.

Run Llama 3 Locally

Amin Rashidbeigi — Wed, 30 Oct 2024 18:08:37 +0000

In the generative AI era and with large language models, they say the only limitation is your imagination. So, as maybe you, I had some ideas to implement with LLMs, but I didn’t want to spend a lot on testing and validating my prototypes. So, I decided to run Llama, the Meta open-source LLM, on my machine or a VM to implement my prototypes with a free and self-hosted LLM.

This post is a guide on how to run Llama locally, step by step.

What You Need to Get Started

At first, you need some computational power, which I assume you already have. You could use your MacBook or any other laptop or PC. Or you could host it somewhere else with more computational power. GPUs are more suitable for running these tasks, so if you need to get results faster, hosting it on a machine with a GPU would be better.

Then, all you need is a tool called Ollama. Ollama is a tool to set up, download, and run large language models more easily than before. I tested it, and it was super easy to use and convenient, so I decided to introduce it here.

Setting Up and Running Ollama

Now, we want to run Ollama on our machine. The whole process is straightforward.

Step 1: Download and Install Ollama

First, you need to download Ollama. You can download it through their website.

You can choose the version that is most convenient for you. As a general rule, the more parameters, the bigger the download and the more time and resources it will take to provide the result.

Once it is installed, you can run the serve command to ensure that it works and is ready to be served:

ollama serve

Step 2: Pull the Llama3 Model

Now, you must select a model and download it to your local. You can check models here. For example, we want to download the llama3.2. You can download it with the ollama pull command:

ollama pull llama3.2

It will take a while based on the model size.

Step 3: Generate Your First Self-Hosted LLM Result

Now everything is ready! you can use ollama command line tool by this command:

ollama run llama3.2

You either can send requests to the locolhost with your desired tool! like curl, postman, or within a python script or any other tools.

Note: for writing the post, I am using the latest version of ollama as of now which is v0.3.14. Maybe contributors change some of those commands or even workflows. In this case, check their documentation for the latest changes, and please let me know in the comments to make this post up to date.

This post originally published at Run Llama 3 Locally. If you liked this post and want to see more, follow me at X/Twitter.

Managing Overdue Tasks

Amin Rashidbeigi — Mon, 25 Mar 2024 15:04:36 +0000

Introduction

Getting better at estimating how long tasks will take is a skill that develops as you gain more experience in your career, especially when working with a team or company for a long time. However, even with careful planning, unexpected challenges can pop up, causing delays and potentially missing deadlines.

A Common Approach: Finish It at All Costs

When faced with a deadline, the first solution many of us consider is to work extra hours or through the weekend. We might think that failing to complete the task on time means we've let others down, broken a promise, or even fear it could reflect negatively on our next performance review.

But this strategy, even if it helps in the short term, isn't healthy and leads to several problems:

Higher Chances of Mistakes: Rushing to finish and working without enough rest increases the likelihood of errors. I'm sure that most people will create more bugs when they haven't had a good night's sleep compared to those who have.
Reduced Quality and Higher Costs: To meet deadlines, we might skip necessary steps such as writing good tests, doing enough manual testing, or making quick fixes that don't align with the project's overall design. These "technical debts" can lead to potential problems and costs in the future.
Missed Learning Opportunities: Failing to meet an estimate is a chance to learn and improve. However, if we just work longer hours without discussing the issue with the team, we miss out on this learning. Plus, it sets unrealistic expectations for future projects, leaving us in a similar situation again.

A Better Strategy: Communicate

The most effective way to handle these situations is to talk to your team or project manager as soon as you realize the task might not meet the deadline. This could be during a daily check-in, a message, or the next scheduled meeting. Communicate the challenges clearly and make sure everyone understands the situation.

Next steps can include:

Adjusting the Plan: The manager may agree to extend the deadline once they understand the situation, allowing you to complete the work without undue stress.
Addressing Immediate Deadlines: If the deadline can't be moved, you can discuss the issues highlighted earlier (like the risk of errors and lower quality) to help decide the best course of action together.

Conclusion

Meeting deadlines is important, but we should also think about how our choices affect things in the long run. Trying to finish things fast or working too hard might seem like good ideas at first, but they can lead to more mistakes, lower-quality work, and missed chances for the team to learn and grow.

Talking openly about any problems and being clear about delays help make a better work environment and lead to a more lasting way of managing projects.

Originally published at Managing Overdue Tasks

Go Test Doubles by Example

Amin Rashidbeigi — Tue, 02 Jan 2024 07:27:56 +0000

Introduction

When writing tests for a program, we often need to consider dependencies and external APIs that we prefer not to call every time the test runs. Calling these external dependencies not only adds complexity to our tests but also incurs costs. To address this issue, we can use test doubles.

What Are Test Doubles?

Test doubles offer an alternative to real dependencies. While we commonly refer to all of them as mocks, there are various test doubles, each serving different purposes.

Let's briefly review each type of test double:

Fake: Fakes are actual implementations of dependencies, in a simpler and chipper way. Consider a scenario where we have a database dependency. We can create a fake in-memory database that implements the database interface, allowing us to use it as a substitute for the actual database.
Dummy: Dummies act as placeholder objects. We don't utilize their functionalities; instead, we pass parameters just to fulfill test requirements. We don't want to test their logic or behavior.
Mock: Sometimes we want to test the behavior of our logic rather than the implementation or output. Mocks are for this purpose. For instance, ensuring a specific API called only once per request can be achieved by mocking that API.
Stub: When testing particular logic, we might need to assess the program's state rather than its behavior. Stubs come into play by generating predefined responses for specific parameters.
Spy: Spies, similar to stubs, offer dynamic behavior based on how they're invoked, providing a more interactive aspect. We can say that spies inherit from both stubs and mocks.

If you're unfamiliar with test doubles and want to read more about them, check the resources I've referenced at the end of the post.

Test Doubles by an Example

Now that we've reviewed all test doubles, let's explain each of them using a real-world Go example.

Imagine we have a Payment service that depends on a payment gateway and contains a ProcessPayment method implementing logic when a user submits a payment. We want to write some test double for the payment package.

Payment Gateway Dependency

First of all, let's define a simple implementation of an example gateway:

package gateway

import "errors"

type RealPaymentGateway struct{}

func (r *RealPaymentGateway) ProcessPayment(amount float64) error {
    if amount <= 0 {
        return errors.New("invalid payment amount")
    }
    return nil
}

Payment Processor

Now, let's create a simple implementation of the PaymentProcessor. A gateway is as an input for this processor, and it includes a Process function that calls the ProcessPayment method of the gateway.

package payment

type PaymentGateway interface {
    ProcessPayment(amount float64) error
}

type PaymentProcessor struct {
    gateway PaymentGateway
}

func NewPaymentProcessor(gateway PaymentGateway) *PaymentProcessor {
    return &PaymentProcessor{
        gateway: gateway,
    }
}

func (p *PaymentProcessor) Process(amount float64) error {
    return p.gateway.ProcessPayment(amount)
}

Now, let's initialize our program with the main function:

package main

import (
    "fmt"

    "github.com/aminrashidbeigi/go-test-doubles/gateway"
    "github.com/aminrashidbeigi/go-test-doubles/payment"
)

func main() {
    realPaymentGateway := &gateway.RealPaymentGateway{} 
    paymentProcessor := payment.NewPaymentProcessor(realPaymentGateway)

    amount := 100.0

    err := paymentProcessor.Process(amount)
    if err != nil {
        fmt.Println("Payment failed:", err)
        return
    }

    fmt.Println("Payment processed successfully!")
}

When we run this program we get this output:

Payment processed successfully!

So, our program works well. Now, we've reached the fun part – writing tests!

Test Doubles Implementations

Dummy

As I said, dummy just pass parameters to initialize a dependency and we don’t expect anything from them. In this example, the PaymentGatewayDummy satisfies the PaymentGateway interface by implementing the ProcessPayment method but does nothing inside the method. It's simply there to fulfill the requirement of a PaymentGateway object for the tests that rely on this interface.

type PaymentGatewayDummy struct{}

func (d *PaymentGatewayDummy) ProcessPayment(amount float64) error {
    return nil
}

func TestPaymentProcessor_WithDummy(t *testing.T) {
    paymentProcessor := payment.NewPaymentProcessor(&PaymentGatewayDummy{})

    err := paymentProcessor.Process(100.0)

    if err != nil {
        t.Errorf("Expected no error, got %v", err)
    }
}

Fake

In the payment system example, the PaymentGatewayFake provides an alternative implementation with simpler logic. Here's the fake implementation:

type PaymentGatewayFake struct{}

func (f *PaymentGatewayFake) ProcessPayment(amount float64) error {
    if amount <= 0 {
        return errors.New("invalid amount")
    }
    return nil
}

func TestPaymentProcessor_WithFake(t *testing.T) {
    paymentProcessor := payment.NewPaymentProcessor(&PaymentGatewayFake{})

    err := paymentProcessor.Process(0)

    if err == nil {
        t.Error("Expected an error for zero amount, got none")
    }

    errNegative := paymentProcessor.Process(-10)

    if errNegative == nil {
        t.Error("Expected an error for negative amount, got none")
    }
}

Mock

Mocks are used to define and enforce expectations on interactions with an object. They specify certain method calls with specific parameters and help verify that these interactions occur as expected during tests. In this example, the mock records each call made to ProcessPayment, allowing later verification to ensure that the expected method calls happened in the specified order and with the correct parameters.

type PaymentGatewayMock struct {
    calls      []string
    callAmount float64
}

func (m *PaymentGatewayMock) ProcessPayment(amount float64) error {
    m.calls = append(m.calls, "ProcessPayment")
    m.callAmount = amount

    return nil
}

func (m *PaymentGatewayMock) VerifyCalls(expectedCalls []string) bool {
    if len(expectedCalls) != len(m.calls) {
        return false
    }
    for i, call := range expectedCalls {
        if call != m.calls[i] {
            return false
        }
    }
    return true
}

func TestPaymentProcessor_WithMock(t *testing.T) {
    paymentGatewayMock := &PaymentGatewayMock{}
    paymentProcessor := payment.NewPaymentProcessor(paymentGatewayMock)

    amount := 75.0
    _ = paymentProcessor.Process(amount)

    expectedCalls := []string{"ProcessPayment"}
    if !paymentGatewayMock.VerifyCalls(expectedCalls) {
        t.Errorf("Expected calls %v, got %v", expectedCalls, paymentGatewayMock.calls)
    }
    if paymentGatewayMock.callAmount != amount {
        t.Errorf("Expected call amount %f, got %f", amount, paymentGatewayMock.callAmount)
    }
}

Stub

The stub here represents a simplified version of the PaymentGateway. It has a success boolean field that determines whether the payment should be successful or fail. The ProcessPayment method of the stub checks the success field and returns an error if success is set to false, simulating a failed payment.

type PaymentGatewayStub struct {
    success bool
}

func (s *PaymentGatewayStub) ProcessPayment(amount float64) error {
    if !s.success {
        return errors.New("payment failed")
    }
    return nil
}

func TestPaymentProcessor_WithStub_SuccessfulPayment(t *testing.T) {
    paymentProcessor := payment.NewPaymentProcessor(&PaymentGatewayStub{success: true})

    err := paymentProcessor.Process(100.0)

    if err != nil {
        t.Errorf("Expected no error, got %v", err)
    }
}

func TestPaymentProcessor_WithStub_FailedPayment(t *testing.T) {
    paymentProcessor := payment.NewPaymentProcessor(&PaymentGatewayStub{success: false})

    err := paymentProcessor.Process(50.0)

    if err == nil {
        t.Error("Expected an error, got none")
    }
}

Spy

The spy here is used to track and record information about interactions with the PaymentGateway. It has called and amount fields to record whether the ProcessPayment method has been called and the amount passed to it. During testing, the spy captures and records this information, allowing tests to assert whether certain interactions have occurred.

type PaymentGatewaySpy struct {
    called bool
    amount float64
}

func (s *PaymentGatewaySpy) ProcessPayment(amount float64) error {
    s.called = true
    s.amount = amount
    return nil
}

func TestPaymentProcessor_WithSpy(t *testing.T) {
    paymentGatewaySpy := &PaymentGatewaySpy{}
    paymentProcessor := payment.NewPaymentProcessor(paymentGatewaySpy)

    amount := 75.0
    _ = paymentProcessor.Process(amount)

    if !paymentGatewaySpy.called {
        t.Error("Expected PaymentGatewaySpy to be called")
    }
    if paymentGatewaySpy.amount != amount {
        t.Errorf("Expected amount %f, got %f", amount, paymentGatewaySpy.amount)
    }
}

Wrapping up

Each type of test double—dummies, stubs, spies, mocks, and fakes—has its unique role in testing of our code. They help us check if our code works correctly, create specific situations for testing, and make sure our tests happen in a safe space with reduced complexity and cost.

I've placed all this code in a GitHub repository. You can check it here: Go Test Double.

Additionally, you can follow my Twitter for future posts.

DEV Community: Amin Rashidbeigi

My Thoughts on The Clean Coder Book

Introduction

Saying No, at Any Cost

Know the Basics

Practice at Home, Perform at Your Job

Know the Domain of Your Product

Conclusion

When to Start Secret Rotation

What is Secret Rotation?

When Should You Start Secret Rotation?

Why Start Secret Rotation Early?

Run Llama 3 Locally

What You Need to Get Started

Setting Up and Running Ollama

Step 1: Download and Install Ollama

Step 2: Pull the Llama3 Model

Step 3: Generate Your First Self-Hosted LLM Result

Managing Overdue Tasks

Introduction

A Common Approach: Finish It at All Costs

A Better Strategy: Communicate

Conclusion

Go Test Doubles by Example

Introduction

What Are Test Doubles?

Test Doubles by an Example

Payment Gateway Dependency

Payment Processor

Test Doubles Implementations

Dummy

Fake

Mock

Stub

Spy

Wrapping up

Further Reading