Blogs @ Beautiful Code

Refactoring is essential

Team Phoenix — Tue, 20 Feb 2024 04:20:37 GMT

Introduction

What is refactoring?

// Before refactoring
package main

import "fmt"

func main() {
    fmt.Println(add(2, 3))
    fmt.Println(subtract(5, 2))
}

func add(x int, y int) int {
    return x + y
}

func subtract(x int, y int) int {
    return x - y
}

// After refactoring
package main

import "fmt"

func main() {
    fmt.Println(calculate(2, 3, add))
    fmt.Println(calculate(5, 2, subtract))
}

func add(x int, y int) int {
    return x + y
}

func subtract(x int, y int) int {
    return x - y
}

func calculate(x int, y int, operation func(int, int) int) int {
    return operation(x, y)
}

This article presents a simple refactoring example in Go language. It starts with two basic functions for addition and subtraction. The code is then refactored to include a new function 'calculate' which accepts the operation as a parameter. This demonstrates how to make the code more flexible and reusable by abstracting the operation.

This is a block quote

Implementing a Go-based Microservices Architecture on AWS

Team Phoenix — Tue, 20 Feb 2024 04:19:42 GMT

Introduction

What is a microservice? - is a small, autonomous, and independently deployable unit of a software application designed to perform a specific function

Scalability, Flexibility, and Agility: Microservices are designed to be easily scaled, allowing for the efficient handling of increased workloads. Their small, focused nature enables rapid development and deployment, which in turn promotes flexibility and agility in responding to changing requirements or market conditions.

Stability and Trustworthiness: Because microservices work separately and independently, they can make a software application more stable and reliable. If one microservice has a problem, it won't likely affect the whole system since each part works on its own. This separation helps to find and fix issues faster, making the application more dependable and steady.

What is etcd?

Introduction

Overview of AWS services

package main

import (
    "fmt"
    "net/http"
    "github.com/gorilla/mux" // A powerful URL router and dispatcher
)

// Handler for the Hello service
func HelloHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, Microservices!")
}

func main() {
    // Create a new router
    router := mux.NewRouter()

    // Define the route for the Hello service
    router.HandleFunc("/hello", HelloHandler).Methods("GET")

    // Start the server on port 8080
    http.ListenAndServe(":8080", router)
}

package main

import ( "fmt" "net/http" "github.com/gorilla/mux" // A powerful URL router and dispatcher )

// Handler for the Hello service func HelloHandler(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hello, Microservices!") }

func main() { // Create a new router router := mux.NewRouter()

// Define the route for the Hello service router.HandleFunc("/hello", HelloHandler).Methods("GET")

// Start the server on port 8080 http.ListenAndServe(":8080", router) }

These are the reasons why I like Golang

Simplicity and Efficiency

write what i want

Introduction

Sky is blue. -- Ravi

console.log 'Hello, World!'

Optimized for Brand Centric App Development

NG Sai Prasanth — Mon, 19 Feb 2024 06:34:08 GMT

How does this thinking help our clients?

Makes it easy to maintain the Brand Recognition and Brand Consistency

Brand-centric development goes beyond aesthetics; it's about creating a seamless and consistent user experience that aligns with the brand's values, mission, and visual identity. A well-executed brand-centric app not only enhances user engagement and satisfaction but also strengthens brand loyalty and recognition.

FlutterFlow provides a central hub for managing the brand

Central theme management system allows to define and apply a consistent theme across the entire app. This includes colors, fonts, typography, and other design elements. By centralizing brand management, we can ensure that all screens and components adhere to the brand's visual guidelines, creating a cohesive and unified user experience.

FlutterFlow supports importing brand kit from design tools

We can easily import brand styles, including colors, fonts, and other design elements from popular design tools such as Figma. This eliminates the need for manual entry and ensures that the app's design accurately reflects the brand's visual identity.

FlutterFlow's Custom Widgets/Component help with maintaining brand consistency

Custom components/widgets enable us to create reusable UI elements that encapsulate the brand's design principles. These components can be easily integrated into different parts of the app, ensuring consistency and reducing development time.

FlutterFlow supports Rapid Prototyping and Iteration

Rapid prototyping capabilities of FlutterFlow allow us to quickly create and test different design iterations. This iterative approach enables us to refine the app's design and ensure it aligns perfectly with the brand identity.

Clean Arch is a must

Team Phoenix — Wed, 14 Feb 2024 16:23:33 GMT

How does this thinking help our clients?

Readily adapts to new and evolving technologies, ensuring long-term relevance.
The distinct boundaries in Clean Architecture simplify understanding and maintaining the code.

In the dynamic world of software development, the choices we make regarding programming languages and architectural paradigms have profound implications for the scalability, maintainability, and success of our projects. Let's explore why this combination clicks.

It heavily advocates the usage of interfaces

By defining our logic through interfaces, Clean Architecture reduce dependencies between various layers of our application. This makes our code far more flexible and resilient to changes, as implementations can be swapped without disrupting the overall system. Ex: switch frameworks (like web frameworks) or databases (like MySQL to PostgreSQL) without rewriting significant portions of your code. This flexibility is particularly valuable in Golang's ever-evolving ecosystem, ensuring your code stays relevant and adaptable in the long run.

In the following illustration, core business logic is independent of the database layer as captured in UserService. It is easy to switch from one implementation of database storage to another without affecting the UserService business logic.

type UserService struct {
    UserRepository IUserRepository
}

func NewUserService(repo IUserRepository) UserService {
    return UserService{UserRepository: repo}
}

func (s *UserService) GetUserByID(id int64) (*User, error) {
    return s.UserRepository.GetByID(id)
}

// IUserRepository defines CRUD operations for users
type IUserRepository interface {
   GetByID(int64) (*User, error)
   Create(*User) error
   Update(*User) error
   Delete(int64) error
}

It sets you up to achieve 100% code test coverage for core business logic.

Clean Architecture advocates for a clear separation of concerns, preventing high-level business logic from depending on low-level details like databases.

By defining interfaces within our core domain layer and letting dependencies flow outwards, we create a distinct zone for our core logic. This isolated zone, free from dependencies on databases, frameworks, or external services, becomes the perfect candidate for achieving 100% unit test coverage. This translates into several benefits: thorough verification of business rules, a safety net for future evolution and new features, and reduced debugging thanks to well-tested code.

In the below example, the UpdateUserEmail use case contains the essential business logic for changing a user's email. The unit test concentrates exclusively on validating the use case logic, employing a mock user repository to isolate it from external interactions.

// UpdateUserEmail Usecase
func (uc *UpdateUserEmail) Execute(id int64, newEmail string) error {
    user, err := uc.repo.GetByID(id)
    if err != nil {
        return err
    }

    // Business logic to validate and update email (e.g., unique email check)
    if !validateEmail(newEmail) {
        return errors.New("invalid email format")
    }
    user.Email = newEmail
    return uc.repo.Update(user)
}

// Unit test for UpdateUserEmail Usecase
func TestUpdateUserEmail(t *testing.T) {
    mockRepo := new(mock.Mock)
    defer mockRepo.AssertExpectations(t)

    mockRepo.On("GetByID", 1).Return(&domain.User{ID: 1, Username: "user1", Email: "user1@example.com"}, nil)
    mockRepo.On("Update", &domain.User{ID: 1, Username: "user1", Email: "new_email@example.com"}).Return(nil)

    uc := domain.NewUpdateUserEmail(mockRepo)

    err := uc.Execute(1, "new_email@example.com")

    assert.NoError(t, err)
    mockRepo.Verify(t)
}

DIP is applied well in practice.

One of the core strengths of Clean Architecture is its strong adherence to the Dependency Inversion Principle (DIP). This principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions, and abstractions should not depend on details. We translate this principle into clear separation of concerns within our applications. Our core business logic resides in the inner domain layer, free from dependencies. This layer interacts with the outside world through well-defined interfaces.

Applying DIP through Clean Architecture unlocks several advantages such as Enhanced Security and Unparalleled Adaptability.

RSpec over MiniTest for writing test cases

NG Sai Prasanth — Wed, 14 Feb 2024 16:09:08 GMT

How does this thinking help our clients?

Expressive syntax enables the developers to write what they think naturally resulting in less time to write behavior tests.
Alignment between Product Manager and Engineers gets established early on as RSpec promotes writing tests w.r.t the behavior of the system.

We prefer RSpec over MiniTest due to its expressive DSL, comprehensive mocking capabilities, support for writing BDD test cases and extensive community support.

RSpec has a Expressive DSL which improves test readability and maintainability

RSpec employs a concise and expressive Domain-Specific Language (DSL) that makes writing tests easy. The DSL's intuitive syntax mirrors natural language, resulting in test cases that are easy to read, understand, and maintain. This clarity promotes collaboration and facilitates effective communication among developers, testers, and stakeholders.

# Expressive DSL with RSpec
describe "ShoppingCart" do
  describe "#total_price_with_taxes" do
    it "calculates the total price with taxes" do

# MiniTest DSL is not so expressive
def test_calculates_total_price_with_taxes

RSpec advocates Behavior Driven Development

RSpec supports a behavior-driven approach to testing. This means that tests can be written from the perspective of the user. This can help to ensure that the tests are focused on the actual behavior of the application.

# Behavior test for user creation workflow
RSpec.describe "User", type: :feature do
  it "requires a name" do
    visit new_user_path

    fill_in "Name", with: ""
    click_on "Create User"

    expect(page).to have_content("Name can't be blank")
  end
end

Rspec supports instance doubles

Instance doubles allow developers to create fake objects that mimic the behavior of real objects, enabling them to isolate and test specific components of the codebase.

# Rspec snippet for a double that stands in for a specific instance of a User
user_double = instance_double("User", name: "John Doe", email: "johndoe@example.com")

# Minitest creates a generic mock object that does not have the behavior of the real object (via methods)
user_double = Minitest::Mock.new
user_double.expect(:name, "John Doe")
user_double.expect(:email, "johndoe@example.com")