Chemaclass - software-design

Bitcoin with Rigor

2025-01-18T00:00:00+00:00

Bitcoin with Rigor goes beyond a basic explanation of Bitcoin, offering a detailed analysis of how Bitcoin works. It breaks down its components clearly, helping readers understand both the parts and the system as a whole. This deep dive explores Bitcoin’s potential and risks, recognizing it as a decade-old monetary experiment that hasn’t yet stood the test of time like gold or silver. Despite this, its innovative design makes it a promising system for the present and future.

Bitcoin’s novelty makes it challenging to grasp fully. It requires knowledge of computing, economics, and finance while also being a digital asset with no historical precedent to guide understanding. Yet, much like the Internet (also relatively young but undeniably transformative), Bitcoin has the potential to redefine systems and leave a lasting impact.

This book aims to equip readers with the tools to understand how Bitcoin works, empowering them to form their own well-informed opinions about its role in society or, if they choose, to begin a professional journey in this evolving sector. Written with rigor but without excessive technicality, the content is designed to be concise, accessible, and engaging, providing the foundation needed to truly comprehend Bitcoin.

Content #

1. Basic Computer Concepts #

Information and Communication
How Computers Work
Languages and Protocols
The OSI Model: The Onion of Computing
Logic Gates: Fundamental Computing Functions
Client-Server and P2P Networks

2. Basic Cryptographic Concepts #

Asymmetric Complexity
Ciphers, Keys, and Symmetric Cryptography
Asymmetric Cryptography
The Cypherpunk Movement
Cryptographic Hash Functions

3. The Basics of Bitcoin and Cryptocurrencies #

Key Generators and Randomness
Cryptographic Signatures
The Discrete Logarithm Problem
Elliptic Curve Cryptography
Merkle Tree
Traditional Digital Money
Distributed Consensus Algorithms
Proof of Work (PoW)

4. Bitcoin Piece by Piece #

Blockchain or Hashchain?
Block Synchronization
The Headerchain
Keys and Signatures in Bitcoin
Transactions and the UTXO Model
Bitcoin Script and Opcodes
P2PKH (Pay to Public Key Hash) and P2PK
Multi signatures and P2SH (Pay to Script Hash)

5. Nodes and Blockchain in Detail #

Transaction Size and Frequency
Initializing a Full Network Node
Databases and Pruning
How a Wallet Works
Wallets, SPV Nodes, and Others
From Mempool to Blockchain
Forks and Consensus Criticality
Hard Fork vs. Soft Fork

6. Bitcoin Updates and Applications #

Much Work Ahead
Transaction Malleability
Segregated Witness (SegWit)
P2WPKH and P2WSH
Unilateral Payment Channels
Lightning Channels
Multi-channel Payments and HTLCs
Lightning Network
Discreet Log Contracts (DLCs)
MAST, P2SMR, and P2CH
Taproot and Grafroot

Book presentation #

Related links

Book website: www.bitcoinconrigor.com

Bitcoin: A Work in Progress

2024-08-02T00:00:00+00:00

With thousands of “crypto” projects out there, they say Bitcoin is old and boring, but nothing could be further from the truth. This book will guide you through the latest developments in Bitcoin, as seen through the eyes of one of its many developers.

You’ll learn about the latest soft fork known as Taproot, the challenges of keeping open source software free of money-stealing bugs and malware, new ways to protect nodes against evildoers on the internet, how to deal with the ever-growing blockchain, and more!

The book links to more than two hundred articles, videos, podcasts, and even the source code. And thanks to a tiny QR code next to every link, you’ll never have to type long URLs.

Contents #

The basics #

1. Bitcoin Addresses
2. DNS Bootstrap and Tor V3
3. SegWit
4. libsecp256k1

Resource usage #

5. Sync Time and AssumeUTXO
6. Utreexo

Attacking Bitcoin #

7. Eclipse Attacks
8. Fake Nodes
9. Guix

Better Wallets #

10. Script, P2SH, and Miniscript

Taproot #

11. Taproot and Schnorr
12. Activation Options

Appendix #

A. More Episodes
B. A crime on Testnet
C. Bitcoin White Paper

Related links

Book source code: GitHub/Sjors
Book website: www.btcwip.com

What Is Waterfall?

2024-08-01T00:00:00+00:00

Waterfall is like following a straight path where you move from one step to the next in a defined order, like water flowing down a waterfall through different stages.

The problem is that each step can take a lot of time and resources to complete. Plus, you don’t get feedback until the entire stage is finished, which can lead to a lot of wasted time. This is especially tricky in software development, where things are always changing and evolving.

It usually follows a straightforward sequence like this:

The reality of Waterfall #

Waterfall can be like communism in theory, it seems perfect on paper but doesn’t work in the real world.

Clients often don’t know exactly what they want.
Requirements are constantly changing.
Businesses need to quickly adapt to market shifts and client needs.
Software needs to be flexible to keep up with these changes.

So, in a constantly changing world, Waterfall can really hurt a business. It tends to frustrate developers and teams, and it can also annoy clients and the businesses paying for the software. This usually leads to delays and extra costs.

Why companies still use Waterfall #

Even with its problems, a lot of companies still use Waterfall because it seems straightforward and logical. This makes them reluctant to take the time to learn Agile. Plus, getting management to agree to switch to Agile can be a tough sell, especially since it requires an investment in time and learning.

The big issue is when higher-ups dictate exactly how teams should work, leading to micromanagement. This messes up the flexibility that Agile brings. From what I’ve seen, this is a common problem.

Looking back, switching to Agile could have fixed a lot of issues.

Why Agile was created #

Agile was created to overcome the limits of the Waterfall method. It focuses on constant interaction with clients and teams.

Agile builds autonomous and responsible teams that handle tasks from start to finish, reducing wasted time and resources. It emphasizes flexibility, collaboration, and customer feedback.

Unlike Waterfall, Agile uses iterative development, breaking projects into small, manageable sprints or iterations that last 1-4 weeks. Each cycle includes planning, development, testing, and review, aiming to deliver value quickly and gather feedback to improve.

Key aspects of Agile #

Iterative Development: Work in small chunks and adjust as you go.
Customer Collaboration: Keep talking with clients to make sure they’re happy.
Cross-Functional Teams: Teams with different skills working together.
Adaptive Planning: Stay flexible and tweak plans based on feedback.
Continuous Improvement: Always look for ways to get better.

Read the original Agile Manifesto.

Where can you start? #

As a developer, you can boost your agility by diving into pair programming and TDD.

With pair programming, two developers work side by side, which means you get instant feedback and shared problem-solving, leading to better code.
TDD, on the other hand, involves writing tests before the code, which help specifying what you want to do, focusing on baby steps.

Together, these practices make your development process more flexible, collaborative, and high-quality, fitting right in with Agile’s focus on quick adjustments and continuous improvement. See more practices here.

The key is collaboration, baby steps, and quick feedback on everything you work on.

My experience with Agile #

I’ve talked about Agile at various tech events and explored it in depth because I’m passionate about how it can supercharge software teams. When done right, Agile can completely change how teams work, making them faster, more efficient, and better at delivering what clients and businesses really need.

2022-06-26 | International PHP Conference [Berlin, Germany] (EN)
2022-09-16 | Code Talks [Hamburg, Germany] (EN)
2022-10-26 | International PHP Conference [Munich, Germany] (EN)
2022-12-21 | IES Ginés Pérez Chirinos [Murcia, Spain] (ES)
2023-01-19 | devm.io [Remote] (EN)
2023-07-28 | WeAreDeveloper World Congress [Berlin, Germany] (EN)

WeAreDevelopers World Congress in Berlin #

Mastering Bitcoin

2024-07-05T00:00:00+00:00

This book covers everything from the basics to the most profound technical aspects of Bitcoin. It is an excellent guide through this complex world, providing the knowledge you need to participate in the Internet of money.

The first edition of this book was published in December 2014. Ten years later, a third edition with up-to-date knowledge just came out. It is highly recommended to all people interested in this outstanding topic and the tech behind it.

A broad introduction to Bitcoin and its underlying blockchain, ideal for nontechnical users, investors, and business executives.
An explanation of Bitcoin’s technical foundation and cryptographic currency for developers, engineers, and software and systems architects.
Details of the Bitcoin decentralized network, peer-to-peer architecture, transaction lifecycle, and security principles.
New developments such as Taproot, Tapscript, Schnorr signatures, and the Lightning Network.
A deep dive into Bitcoin applications, including how to combine the building blocks this platform offers into powerful new tools.
User stories, analogies, examples, and code snippets illustrating key technical concepts.

Contents #

Introduction
How Bitcoin Works
Bitcoin Core: The Reference Implementation
Keys and Addresses
Wallet recovery
Transactions
Authorization and Authentication
Digital Signatures
Transaction Fees
The Bitcoin Network
The Blockchain
Mining and Consensus
Bitcoin Security
Second-Layer Applications

Full book also on GitHub.

Key takeaways #

Your wallet doesn’t store any bitcoins, only the keys to access them. The coins are stored in the blockchain.
Understanding UTXOs is crucial to understanding how transactions work.
- These are outputs from previous transactions that have not yet been spent
A transaction needs:
- inputs: UTXOs and an unlocking script (scriptSig) which proves ownership.
- outputs: the recipient’s address and the amount to send.
The unlocking script is written in a custom language called Script.
- Transaction validation is achieved through the execution of a script.
- This allows for a nearly infinite variety of conditions to be expressed.
- Script is a stack-based lang, processed from left to right.
Bitcoin is often referred to as “programmable money” because it allows: Multisignature, timelocking and conditional spending.
- Extends Bitcoin’s functionality beyond simple value transfers.
Common Bitcoin address types:
- P2PKH: Begins with 1. Standard transactions using public key hashes.
- P2SH: Begins with 3. Encapsulates complex scripts like multisig.
- P2WPKH: Begins with bc1. Native SegWit, more efficient transactions.
- P2WSH: Begins with bc1. SegWit for complex scripts.
- P2TR: Begins with bc1p. Taproot, enhanced privacy and efficiency.
- Bech32: Starts with bc1. Human-readable, designed for SegWit and Taproot.
Digital signatures serve three purposes in Bitcoin transactions:
- First, it proves that the controller of a private key has authorized the spending of those funds.
- Secondly, the proof of authorization is undeniable.
- Thirdly, the authorized transaction cannot be changed by unauthenticated third parties.
Schnorr’s signatures aren’t specific to the elliptic curve cryptography (ECC) that Bitcoin uses, although it is most associated with ECC today. They have a number of nice properties:
- Provable security: strong security guarantees based on the hardness of the discrete logarithm problem, with formal proofs ensuring their robustness against attacks.
- Linearity: allows for efficient aggregation of multiple signatures into a single compact signature, simplifying verification processes.
- Batch verification: enabling multiple signatures to be verified simultaneously in a more computationally efficient manner.
The best known secure secret sharing algorithm is Shamir’s Secret Sharing.
Running a full node gives you the pure Bitcoin experience: independent verification of all transactions without trusting any other system.
Merkle tres are used to summarize all transactions in a block, producing an overall commitment to the entire set of transactions and permitting a very efficient process to verify whether a transaction is included in a block.
Mining is one of the inventions that make Bitcoin special, a decentralized consensus mechanism that is the basis for P2P digital cash.
- It secures the Bitcoin system and enables the emergence of network-wide consensus without a central authority.
A soft-fork is a forward-compatible change to the consensus rules that allows unupgraded clients to continue to operate in consensus with the new rules.

Learning Concurrency in Golang

2024-04-02T00:00:00+00:00

I wanted to learn a new language, so after trying some, I ended up with Golang as one of my favorites for its simplicity and capabilities. It has features I haven’t used in years, like multithreading and concurrency.

Golang (or Go) supports concurrency through lightweight threads called goroutines. These are different from traditional multithreading, like in Java, where you have to handle sync and coordination to manage shared resources safely. In contrast, Go’s goroutines are lightweight, managed by the Go runtime, and cheaper to create and manage.

While parallelism is doing several things simultaneously, concurrency is about dealing with several things at the same time. When we talk about concurrency and parallelism, we don’t know the order of things. We don’t know what’s going to happen first or what’s going to end first. There is an undefined order of execution.

Imagine you cooking: preparing a soup, a salad and an omelet. You would be one single unit, but you are preparing different dishes. You might finish the salad first or the soup or the omelet… We cannot guarantee that! This would be concurrency, as you are alone dealing with several things. As soon as your partner comes and helps you cook, then we will be talking about parallelism.

I remember building a similar game in Java when I was learning multithreading ten years ago… let’s use this opportunity to do it again with modern Go.

I built a terminal game emulator that mimics one horse racing. Each horse is a goroutine that runs in a shared bidimensional matrix. Once a horse reaches the end, it notifies the shared channel between all other horses (running in different processes) and they all stop, showing in the terminal the winner of the race.

I separated the code into four areas to help visualize it:

Entry point
Generating the board
Rendering the game
Moving the horses

Entry point #

The struct Horse represents each Horse in the race. The game consists of a list of lines, in which each Horse is running.

type Horse struct {
 Name string // The name of the horse
 Line int // The competition line
}

func (h Horse) Letter() string {
 return fmt.Sprintf("%c", h.Name[0])
}

func (h Horse) Equals(other *Horse) bool {
 return other != nil &&
 h.Line == other.Line &&
 h.Name == other.Name
}

func (h Horse) String() string {
 return fmt.Sprintf("%s (line:%d)", h.Name, h.Line)
}

You can spawn a new process using the keyword go when invoking any function. In this game, this is used 1) to render the game RenderGame() and 2) for each horse’s movement startRuningHorseInLine(). The goal is to keep the “rendering” and “movement logic” working in parallel.

func main() {
 const lines, lineLength = 12, 30

 board := NewRaceBoard(lines, lineLength)
 go RenderGame(board)

 winnerChan := make(chan Horse)
 for line := range board {
 // each horse will be moved in different processes
 go startRunningHorseInLine(board, line, winnerChan)
 }

 // wait until one horse reaches the end
 winner := <-winnerChan
 // render one last time to ensure the latest board state
 RenderRaceBoard(board, &winner)

 fmt.Println("Race finished!")
 fmt.Printf("# Winner: %s\n", winner)
}

Generating the board #

The race board is a bidimensional matrix of pointers to Horses. Each line “contains” only one Horse; aka only one pointer will point to an actual Horse, the rest will be pointers to nil. During the generation of the Board, we will create one Horse at the first position of each line.

func NewRaceBoard(lines, lineLength int) [][]*Horse {
 board := make([][]*Horse, lines)
 for line := range board {
 board[line] = make([]*Horse, lineLength)
 board[line][0] = &Horse{
 Name: generateHorseName(),
 Line: line,
 }
 }
 return board
}

The names are randomly generated using HorseNames.

var HorseNames = [][2]string{
 {"Alloping", "Giggles"},
 {"A-lot", "Gallop"},
 {"BoJack", "Jack"},
 {"Baroness", "Belle"},
 // ...
}

func generateHorseName() string {
 name := HorseNames[rand.Intn(len(HorseNames))][0]
 surname := HorseNames[rand.Intn(len(HorseNames))][1]

 return name + " " + surname
}

Rendering the game #

Then RenderGame(), renderRaceBoard(), renderRaceLine() and renderRacePosition() are separated to help focus on each method’s responsibility, identifying what is the subject to be rendered.

RenderGame() is being executed in another process using go.

func RenderGame(board [][]*Horse) {
 for {
 time.Sleep(renderDelay * time.Millisecond)
 RenderRaceBoard(board, nil)
 }
}

func RenderRaceBoard(board [][]*Horse, winner *Horse) {
 // use a "string buffer" to save the whole board state
 // so we can later use one IO call to render it
 var buffer bytes.Buffer
 buffer.WriteString("\n")
 for line := range board {
 renderRaceLine(board, line, &buffer, winner)
 }
 clearScreen()
 fmt.Println(buffer.String())
}

func clearScreen() {
 cmd := exec.Command("clear")
 cmd.Stdout = os.Stdout
 cmd.Run()
}

func renderRaceLine(
 board [][]*Horse,
 line int,
 buffer *bytes.Buffer,
 winner *Horse,
) {
 buffer.WriteString(fmt.Sprintf(" %.2d | ", line))
 var current Horse
 for col := range board[line] {
 h := renderRacePosition(board, line, col, buffer, winner)
 if h != nil {
 current = *h
 }
 }
 buffer.WriteString(fmt.Sprintf("| %s", current.Name))

 if current.Equals(winner) {
 buffer.WriteString(" [Won!]")
 }
 buffer.WriteString("\n")
}

func renderRacePosition(
 board [][]*Horse,
 line, col int,
 buffer *bytes.Buffer,
 winner *Horse,
) *Horse {
 if board[line][col] == nil {
 buffer.WriteString(" ")
 return nil
 }

 current := board[line][col]

 if current.Equals(winner) {
 removeChars(buffer, col+1)
 for range board[line] {
 buffer.WriteString("-")
 }
 }

 buffer.WriteString(current.Letter())

 return current
}

Moving the horses #

In main(...), the winnerChan is a shared channel that will be used by the first Horse reaching the last position in their line.

Each Horse will run a loop until reaching the end of the line OR receiving (via the shared channel winnerChan) the message that another Horse already won the race. Until then, each horse will move independently by randomly sleeping milliseconds before moving to the next position in their line.

startRuningHorseInLine() runs in another process using go.

func main() {
 //...
 winnerChan := make(chan Horse)
 for line := range board {
 // each horse will be moved in different processes
 go startHorseRunning(board, line, winnerChan)
 }
 // wait until one horse reaches the end
 winner := <-winnerChan
 //...
}

func startRunningHorseInLine(board [][]*Horse, line int, winnerChan chan Horse) {
 for {
 select {
 case <-winnerChan: // check if another horse finished
 return // in such a case, then stop the for loop
 default:
 time.Sleep(time.Millisecond * time.Duration(rand.Intn(maxSleepDelay)))
 moveHorseOnePos(board, line, winnerChan)
 }
 }
}

func moveHorseOnePos(board [][]*Horse, line int, winnerChan chan Horse) {
 cols := len(board[line])
 for col := cols - 1; col > 0; col-- {
 if board[line][col-1] == nil {
 continue
 }
 // here we identify that there is a horse in
 // the following column, so we move it to the
 // current column, and we set `nil` the other one
 board[line][col] = board[line][col-1]
 board[line][col-1] = nil

 if col+1 == cols {
 winnerChan <- *board[line][col]
 }
 break
 }
}

Source code #

The code displayed in this post is a simplified version, so if you would like to check the working source, you can do it here: Chemaclass/go-horse-racing.

Great Engineering

2023-12-30T00:00:00+00:00

Coding is not just another job. Writing software can be really fun and, even more, it can be your personal hobby as well! You might be focused on coding, coding and more coding to level up your own career skills.

That itself is not bad at all! Practice makes the master, so a lot of coding will inevitably help you improve your coding skills… but there are other aspects that you need to keep in mind in order to help you grow into a great engineer.

As a software engineer, your job is not “just to write software” for its own sake, but to use software to solve actual business problems. To make that happen there are plenty of different methodologies out there, for sure. However, we must agree that you need to identify and understand your customer’s needs in order to know what to actually build.

You need to know your product, at least until certain level, so you can design your software using a similar language closer to the business, which will help its evolution and overall quality. This will be beneficial for the future (and present) maintenance of the product.

IT, Software, Product and People topics are highly interconnected, and having at least a common ground of understanding the relation between these can help the overall goal of every single individual.

The result of a great team work is not equal as the sum of the individual parts, as it’s multiplying the created value among their peers. To that, great communication skills are a key part of it in order to create as much clarity as possible from any different abstraction level.

That’s why a great engineer is a knowledgeable person about business, customer, product, and coding. Understanding these points have a strong impact on your daily work as it creates a difference between the average and the great engineer.

Image original by Nicola Ballotta.

How to Test Private Methods?

2023-10-20T00:00:00+00:00

This is a question that I have encountered with some frequency for a long time. So I thought I would put together my thoughts on the subject here.

Short answer #

Never.

Long answer #

Never ever.

What if…? #

If you really want to test a private method, consider extracting that private method logic into a separate class, and write a unit test for that class’ behavior.

For this one, I was inspired by Fran Iglesias’ original post.

Introducing a New Tech Stack

2023-04-14T00:00:00+00:00

To introduce a new tech stack for the entire team, it’s important to bring “why?” and a strategy to make it happen among the team because it will affect everyone.

Why that new tech stack? #

To decide whether to use a new tech stack or not, remember that it is a team decision, according to the standardization and maintainability of the project when introducing such a new tech stack. But, most importantly, what problem do you want to solve by introducing it? Is it because it is “cool”? Or is there an actual “necessity” that this tech helps you with?

The direction of the technology #

When proposing adopting a new library, framework, or entire new technology, an important aspect to consider is to be aware of its background and the direction where they are moving forward.

What is the motivation for that tech, and why are you considering introducing it in your current stack?

Coupling and dependencies #

When adopting new technologies in our daily business, it’s not rare that we tend to couple ourselves with them. This makes it harder later to roll back if, after a while, we regret that decision.

Don’t get me wrong, learning and experimenting with new technologies is great, but introducing it in your daily work is another story because it will affect the whole team. So we need to be more careful with this.

The focus of the conversation #

What does this new tech contribute to the project?
What problem do we want to solve by introducing it?
Can we solve that problem with our current tech?
If we already have a similar tech, do we want to have a mix of both?
What are the tradeoffs when using it vs. not using it?
Is it worth the incremental complexity over time?
What is the team strategy to onboard everyone if we aim to use it?

Architectural Decision Records (ADRs) #

Whatever the outcome, you should write it down as an ADR to revisit it as time passes. An ADR will record your team’s decisions regarding the pros and cons, among any other arguments you have found together, to decide what to do and why.

ADRs are useful to understand old decisions and keep them in the version control, in the same project if possible. They are helpful for the current team, but also for new joiners.

Accelerate

2023-03-19T00:00:00+00:00

Accelerate explores how software development teams using Lean Software and DevOps can measure their performance and the performance of software engineering teams impacts the overall performance of an organization.

Note: DevOps is about integrating and automating software development (Dev) and IT operations (Ops), focusing on improving (and shortening) the systems development life cycle.

Key Capabilities #

Continuous Delivery #

Use Version Control for all Production Artifacts
Automate Your Deployment Process
Implement Continuous Integration
Use Trunk-Based Development Methods
Implement Test Automation
Continuous Delivery (CD)

Architecture #

Use a Loosely Coupled Architecture

Product and Process #

Gather and Implement Customer Feedback
Make the Flow of Work Visible through the Value Stream
Work in Small Batches
Foster and Enable Team Experimentation

Lean Management and Monitoring #

Have a Lightweight Change Approval Processes
Monitor across Application and Infrastructure to Inform Business Decisions
Check System Health Proactively
Improve Processes and Manage Work with WIP (Work-In-Process) Limits
Visualize Work to Monitor Quality and Communicate throughout the Team

Cultural #

Support a Generative Culture
Encourage and Support Learning
Support and Facilitate Collaboration among Teams
Provide Resources and Tools that Make Work Meaningful
Support or Embody Transformational Leadership

Four Key Metrics #

Change Lead Time
- Time to implement, test, and deliver code for a feature
Deployment Frequency
- Number of deployments in a given duration of time
Change Failure Rate
- Percentage of failed changes over all changes (regardless of success)
Mean Time to Recovery
- Time it takes to restore service after production failure

Recipes for Decoupling

2022-11-28T00:00:00+00:00

What is coupling, and why is it bad? What is decoupling, and how to do it efficiently? This book is a compilation of strategies to decouple your domain code from those infrastructure details, so you can enjoy a healthier system in the long run.

This book will teach you how to create PHPStan rules from no knowledge, and then it will guide you across many decoupling opportunities like, for example:

web framework
cli frameworks
form validation
orm and database
test framework

Read more about the book: matthiasnoback.nl/book/recipes-for-decoupling/

Buy it here: leanpub.com/recipes-for-decoupling

Modern Software Engineering

2022-06-29T00:00:00+00:00

This book presents software development as an engineering practice at every level. To master software engineering, we must become experts at learning and managing complexity.

Optimize for learning #

To optimize for learning, the book presents five behaviors to consider:

Working iteratively
Feedback
Incrementalism
Empiricism
Being Experimental

The main idea is to work on small steps, collect feedback, and adjust.

Optimize for managing complexity #

The book presents other five ideas to manage complexity:

Modularity
Cohesion
Separation of Concerns
Information Hiding and Abstraction
Managing Coupling

We need to manage the complexity of our systems.

Tools to support engineering in software #

Going deeper into some ideas that were already discussed in the book, like:

Testability
Deployability
Controlling the variables
Continuous Delivery

A great video explaining the core ideas behind this book by his author:

Modern CTO

2022-01-23T00:00:00+00:00

Developers are not CTOs, but developers can learn how to be CTOs.

In Modern CTO, Joel Beasley provides readers with an in-depth road map on how to successfully navigate the unexplored and jagged transition between these two roles. Drawing from personal experience, Joel gives a refreshing take on the challenges, lessons, and things to avoid on this journey.

These are the topics you’ll find in the book:

A Modern CTO knows… #

Developers are not CTOs
The spaghetti code MVP epidemic
Over-engineering is a problem
Whether to hire, buy, or out-build their competitor
How not to scale prematurely
How to solve any problem
How to work with programers when you aren’t one
UX mistakes to watch out for
When to speak up
When to hire & fire consultants
How to analyze failure
How to bounce back from unforeseen constraints
Answer the question: “How difficult is it to code…?”
How to avoid the “bottom of the ninth” guy
When to respond to feedback
How to validate an expert in any field
How to effectively communicate complex ideas

Favorite quotes #

If I rest on past achievements, I’ll never grow.

LEVERAGE OTHERS’ EXPERIENCE Books condense a lifetime of experience into a few hours’ read. Powerful right?

There are only two reasons you write bad code:

1)You know how to write good code, but you choose to write bad code. 2)You don’t know how to write good code. And both suck.

As the CTO, you must have a business focus.

Always return to your core goals. […] I make sure each core goal has a clearly defined “why?” behind it, this way if I ever get lost, I go back to my “why.”

Reference to “Start with Why” by Simon Sinek.

When you’re the boss, remember this golden rule: Ask people what they think instead of telling them what to do.

If I can’t asses the human component, I can’t lead a team. […] Team composition carries as much or perhaps even greater weight than programming expertise.

As CTO, if you can’t explain value simply, it means you don’t understand the business value behind your technology.

London vs Chicago

2021-11-20T00:00:00+00:00

There are two known schools in TDD: the mockist school (aka Outside-in) and the classicist school (aka Inside-out).

Why London and Chicago? #

Two companies, one from London and another from Chicago, claimed to do TDD, but they were focused on different aspects. The London company was building software from outside-in, while the Chicago company from inside-out. Let’s see them in more detail.

Outside-in: London School #

It provides a behavior-driven approach to TDD. Starting from the outside of the application and working inwards to lower layers. For example, starting from the API/Controllers down to the application or domain layers.

PROS #

Behavioral Focused: this requires a lot of test doubles because you will test a lot of abstractions that don’t exist yet as you are creating a high level of logic first. You aren’t going to write dead-code but it will be easy to create tests highly coupled to the logic and therefore making refactoring a difficult task.
Command-Query separation: is a discipline for managing side effects. Either you perform an action (command) or you ask for a value (query).

CONS #

Fragile Tests: it tends to create tests that break easily because they are usually too coupled to the production code.
Difficult Refactoring: for the same reason as “Fragile Tests”, having tests coupled to production code make continuous refactoring very difficult and time-consuming.

Inside-out: Chicago School #

It’s an informal, exploratory, state-based approach of TDD. Starting from the inside of the application (usually the domain) and working out towards the APIs.

PROS #

Strong Safety Net: it tends to produce tests that are decoupled from the implementation. Enabling you to adopt a more experimental style of changing software without fear of breaking it. This is desired for continuous refactoring.
High Cohesion: as tests become more general, the production code becomes more specific. This promotes high cohesion, and with high cohesion comes loose coupling. Something that promotes high code quality: extensibility, maintainability, and testability.
Minimizes Test Doubles: building from the inside out requires fewer test doubles since you are building on top of the previously written tests. This helps to develop less fragile tests.

CONS #

YAGNI: it’s often over-engineering solutions, with code that is not really needed (or even used!) in the end.

London and Chicago work better together #

It’s not about choosing one over the other. It’s about understanding your context and driving optimization towards those qualities that need to be optimized. London and Chicago each have their pros and cons. The best approach to TDD is an integrated adoption of these two schools.

References #

TDD vs BDD

2021-09-25T00:00:00+00:00

These are two different techniques. The key to each of them is about the mindset and context of what you want to achieve.

BDD is a “test-driven feature” #

Basically, it’s a test-first driven development, where the main focus is ensuring the expected final behavior, and therefore the result of the software logic that you want to have at the end.

In BDD the main focus is the behavior of your domain logic that doesn’t exist yet. It is, from an abstract point of view, about the whole functionality and domain requirements.

TDD is about the rhythm #

Specify what you want.
Make it work.
Make it better.

TDD is not just about the already known “red-green-refactor” mentality, but mostly about the workflow that helps you understand the constant design decisions you are doing every time for every logic you are designing.

TDD is about constant feedback about your decisions.

In the context of OOP (to make the examples clearer), there are always tons of different ways to design your class:

What’s the name of this method’s class?
What are the dependencies or collaborators for this class?
How will this class behave when I use this other class inside it?
What’s the expected outcome of this method when I give these arguments?
etc, etc…

We ask these questions (and many more) every time, and we do give them an answer as well, but usually without any rational thinking or feedback about it. We just do what we think is “the best” at that particular time focusing on making something work, but is it enough to make it work?

The constant feedback loop #

Testing is not just a great tool because it gives you some safety-net so you can refactor with confidence, but also because it helps design a better system. How is that? Because before going for any solution, it makes you think about the decisions that you need to do. You are challenging yourself to understand the arguments of your decisions, and why A and not B is a better solution in a particular context.

BDD and TDD aren’t mutually exclusive, in fact, they can and should coexist. It depends mostly on the context of what you want to build and test.

BDD is about Test-First feature development. The goal is not how but what. The feedback loop is long because you will get “green” feedback once the feature is implemented and working as expected.

TDD is also another Test-First driven but, unlike BDD, it is about a shorter and quicker feedback loop.

First, you specify what you want. You think about the design of your class or method. Its name or signature. Its dependencies. But all of this by baby steps, one at a time.
Second, you make that little thing work in the simplest possible way.
Finally, you make it better. Because software is hard and complicated enough to make it right on the first try, so refactoring is a must to keep a system healthy. At this point, with a “green running test”, you can refactor and improve your logic safely.

The above is basically TDD, right, but… what’s so special about it? The constant feedback loop and design decisions that you need to make before you are actually writing the solution. This is the power of TDD.

Why so small steps in TDD? #

Theoretically you “must” write little steps for every iteration, but why? It’s all about the feedback loop. This is up to you, your expectations, and your experience with testing.

Resources #

Test-Driven (Development)

2021-08-01T00:00:00+00:00

The complexity here is not about writing tests itself, but the habits that we have to change to create software that is easy to be tested.

The root of the problem #

Without (a solid) experience in testing, developers can have a hard time while trying to apply testing in general as part of their daily job. It’s not simply because of the topic’s complexity, but because they are used to writing code that is hard to test.

Writing tests for already working software (mainly when it was done without considering testing at all) translates as something boring, next to useless, usually accompanied by a lack of motivation, blaming the wrong subject in this context: “the tests itself are reducing my speed”.

In a domain context, if a piece of software logic is hard to be tested, the problem is not the test, but the code which wasn’t well written.

There are already hundreds of tutorials, books, and documentation about testing, but I can share my experience and how I do apply this great (and mandatory) philosophy in my daily work.

Test-Driven is based on this simple rule #

Instead of: design code -> develop code -> write tests.

It’s about: write failing automated test -> run failing test -> develop code to make test pass -> run test -> repeat.

The idea of driving your code by testing can be understood depending on the abstraction level of what you’re writing at the moment. You don’t want to create a wrong coupling between the tests and the code being tested. You want to test the behavior of your logic.

TDD is based on a loop of baby steps that helps you find patterns and guide your software design every little iteration with constant refactorings. It’s the best choice if you want to ensure the expected behavior of all possible paths of your logic.

The beauty of this is that you don’t need to know the full algorithm from the very beginning. Instead, you are discovering how your logic should be by expressing the desired implementation, step by step, on automated tests.

Considering writing tests for your software at the same time you’re writing it, will irremediably force you to write better software. Because you want to write software which has to be easy to be tested, and therefore it will end up with higher quality.

I already wrote another post about the relation between software quality and testing: The Art of Testing: where design meets quality.

Improve your Test-Driven skills #

The best way to learn Test-Driven is doing software katas. Try them alone and with others. Both are equally important.

Alone: to challenge your inner self without any distraction but yourself.
With others: pair-programming is essential in our job. Katas are the best tools to train our communication skills and learn together from each other.

What’s a Code Kata? #

Software developers don’t practice enough. Most of our learning takes place on the job, which means that most of our mistakes get made there as well.

Other creative professions practice: musicians play technical pieces, poets constantly rewrite works. In karate, most of a student’s time is spent learning and refining basic moves. These are katas.

What is the goal of a kata? What should we have at the end? #

Katas exist to help developers get the same benefits as practicing in any other profession. There are simple, artificial exercises that let you experiment and learn without the pressure of a production environment.

There are no right or wrong answers in any software kata: the benefit comes from the process, not from the result.

Tips #

Once you have resolved a kata, try it again in a few weeks or months.
Try to explore new solutions. Be creative in the process and do not rush.
When doing them in groups, they are not a competition to see who will accomplish more of the exercise.
The focus should be on the process, never on the result.
The true valuable outcome of any kata is the learnings that you (and your team) will get after talking about it and sharing your experiences.

You can find a lot of katas on the Internet. For example:

TDD is more as a workflow than a design #

“TDD is a design tool.” That’s what Sandro has said for years. But not anymore. After working with different teams and in different organisations, and also carefully inspecting how he works, Sandro changed his mind about the role of TDD in software design.

TDD in a nutshell; it’s about the rhythm.

Specify what you want.
Make it work.
Make it better.

Kent Beck #

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— Kent Beck 🌻 (@KentBeck) July 30, 2021

Images original by Emmanuel Valverde Ramos.

Phel: The Lisp That Compiles to PHP

2021-02-01T00:00:00+00:00

A new Functional Programming language built-in on the PHP ecosystem.

The Phel Language #

Phel is a Functional Programming (FP) language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet.

Features #

Built on PHP’s ecosystem
Good error reporting
Different Datastructures (Arrays, Tables, and Tuples)
Macros
Recursive functions
Powerful but simple Syntax
REPL

Why Phel? #

Phel is a creation of Jens Haase, and as he mentions on the website, “it is the result of many failed attempts to do functional programming in PHP”. He was looking for something with these characteristics:

A LISP-inspired
Functional Programming language
That runs on cheap hosting providers
It is easy to write and debug

From my point, it was ending May 2020 when I finished the book Seven Languages in Seven Weeks, in which I learned the basics of Prolog, Erlang, Clojure, Haskell… I even created a repository in GitHub to store my progress over the weeks with these learnings.

Suddenly, one day beginning of June 2020, I saw a post in Reddit’s PHP official channel, with a message of someone mentioning this “Phel” project, claiming to be a “functional programming language” written in PHP!

I’ve worked with PHP for around 8 years so far, and I always try to combine OOP with FP as much as possible (because I believe both paradigms are better combined; they are not necessarily exclusive), and a new dialect of Lisp fully written in native PHP 7.4 sounded really exciting. I decided to take a look at it. I wanted to see the code.

The fresh readings from Mathias NoBack books such as Object Design Style Guide, and Advanced Web Application Architecture, gave me the courage to try out what I learned and put it for real in a project. This was (and still is) a beautiful challenge, which helps me to test myself and grow professionally at the same time.

My first commit was done on 6 June 2020, and since then I’ve been dedicating a little time each day during my free hours to its development. It helps me to learn more about FP, languages’ internal design, and best practices on testing and software design architecture in general.

I started applying minor changes until I ended refactoring the whole compiler structure (among other things) in order to make the modules easier to read and understand. Psalm, strict types, good test coverage, unifying code style… These were some of my favorite topics.

Example of Phel code #

The following example gives a short impression of how Phel looks like:

# Define a namespace
(ns my\example)
# Define a variable with name "my-name" and value "world"
(def my-name "world")
# Define a func with name "print-name" and one argument
(defn print-name [your-name]
 (print "hello" your-name))
# Call the function
(print-name my-name)

Current status of Phel #

We prepared an easy Getting Started Guide
We prepared an easy GitHub Repository with a Phel Scaffolding Template
We just released the first official version: 0.1.0

Check out the official website with all documentation: https://phel-lang.org/

Also recommended #

Functional Programming with Phel - JesusValera

To Mock or Not to Mock

2021-01-11T00:00:00+00:00

Mocking is useful, but “what to mock” usually turns out to be more complicated than expected if you don’t treat this carefully.

How to escape the mocking hell #

What is actually happening when we create a mock? Which types of mocks are there? Is mocking good or bad? Well, as always, everything depends on the context. And here we will consider some of the main situations about when to mock and when not to mock, but especially why.

What happens when you mock something? #

First, we should define what is a mock:

In a unit test, mock objects can simulate the behavior of complex, real objects and are therefore useful when it is impractical or impossible to incorporate a real object into a unit test.

Mocking makes sense in a unit testing context. An integration test should go through the real implementation checking the integration between multiple units, which are even allowed to talk to the DB or File IO: infrastructure code. Therefore we should agree that a unit test is a fast and deterministic test that doesn’t rely on external dependencies and doesn’t require any special context to run.

Mock objects meet the interface requirements. In consequence, they allow us to write and unit-test functionality without calling complex underlying or collaborating classes.

A mock is a test double that stands in for real implementation code during the unit testing process. It is also capable of producing assertions about how it was manipulated by the test subject during the test run.

I strongly recommend you to read this post if you want to get into the details of why Mocking is a code smell (Topics like these: What is a mock? What is a unit test? What is test coverage? What is tight coupling? What causes tight coupling? What does composition have to do with mocking? How do we remove coupling? and more!)

The problem with mocking #

When you mock you are overriding the logic of the mocked class. The real logic is getting hidden behind the scenes and there is actually where bugs love to live. Consider that:

The mock may have attributes, methods, or arguments that the real object doesn’t.
The mock’s return values may differ from the real objects’ return values. For example, it may return a different type of object that has different attributes.
The mock’s side effects and behavior may differ from the real objects’ ones. For example, maybe the mock fails to raise an exception when the real object would raise it.

Alternatives to mocking #

“Are you saying that mocking is bad and we shouldn’t mock?!” No.

It depends on what you are “overriding”.

Is your business domain logic what you are mocking? Then it’s wrong.
Is the connection to the DB what you are mocking? Then it’s right.

It depends on the context of the logic and where that logic belongs.

Is it part of your business domain logic? Then you shouldn’t mock it but instantiate it.

Is it part of any infrastructure dependency like DB connection, IO file system, Network, or any external service that has nothing to do directly with your business domain? Then mock it using abstractions/interfaces.

The interface should be the contract between your business domain logic and its external infrastructure dependencies. Imagine how easy it would be to unit test your domain logic by instantiating it and calling their methods with different arguments expecting different inputs under your entire control.

Some tricks #

When you are writing a unit test:

Try to instantiate your classes first.
Avoid mocking concrete classes. I wrote an article exclusively about this: encouraging final classes and interfaces.

Mock interfaces. Instantiate concrete classes.

“Excessive use of mocks leads to legacy code.” - Philippe Boargau

How can we avoid excessive mocking? #

Favor immutable state over a mutable state.
Make dependencies explicit.
Program to an interface, not to an implementation.

References #

Mocking is a code smell - Eric Elliott
When to mock & Test Definitions - Uncle Bob
Final classes by default - Matthias Noback
The problem with mocks - Sean Hammond
A Set of Unit Testing Rules - Michael Feathers

Principles of package design

2020-11-12T00:00:00+00:00

Apply design principles to your classes, preparing them for reuse. You will use package design principles to create packages that are just right in terms of cohesion and coupling, and are user- and maintainer-friendly at the same time.

The first part of this book walks you through the five SOLID principles that will help you improve the design of your classes. The second part introduces you to the best practices of package design, and covers both package cohesion principles and package coupling principles. Cohesion principles show you which classes should be put together in a package, when to split packages, and if a combination of classes may be considered a “package” in the first place. Package coupling principles help you choose the right dependencies and prevent wrong directions in the dependency graph of your packages.

What You’ll Learn #

Apply the SOLID principles of class design
Determine if classes belong in the same package
Know whether it is safe for packages to depend on each other

Typed Arrays in PHP

2020-10-13T00:00:00+00:00

Argument unpacking, function variable argument list, and variadics function.

The perfect combination #

Argument unpacking: Instead of passing the argument itself to the function, the elements it contains will be passed (as individual arguments).
Function variable argument list: The arguments will be passed into the given variable as an array.
Variadics function: Types can be checked with a type-hint.

We will use this snippet for our examples. Having a class, Customer:

<?php
/** 
 * @psalm-immutable 
 */
final class Customer
{
 // Using PHP 8 constructor property promotion
 // https://wiki.php.net/rfc/constructor_promotion
 public function __construct(
 public string $name,
 ) {}
}
// We create a list of 6 customers
$customers = array_map(
 fn(int $i): Customer => new Customer("name-{$i}"),
 range(1, 6)
);

Whenever we want to manipulate a list of Customers, we can pass as an argument: …$customers.

How we used to do it #

We define the array type using the PHPDoc param comment block above. But we cannot define the real type of the item. The code will still run without any problem passing any type on that argument array $customers:

<?php
/** 
 * @param Customer[] 
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 // ... some irrelevant logic for this example
 }
}

The code below would work at “compile-time”. But it might fail at “runtime”.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]);

An alternative (recommended!) might be to extract that logic and ask for the particular type in order to “check it” at runtime in that particular moment, failing if one of the items wasn’t really a Customer:

<?php
/** 
 * @param Customer[] 
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}
function createInvoice(Customer $customer): void
{
 // ... some irrelevant logic for this example
}

Everything here below would work at “compile-time”. It will for sure break during “runtime” if the createInvoice(Customer $customer) receives something different than a Customer.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]); // won't work

By doing that createInvoice(Customer $customer) we are ensuring the type of the argument, which is good! But, what about going one step further. Could we check the types of the elements when calling the function createInvoiceForCustomers(array $customers), even making the IDE complain when the types are not right?

Well, that’s actually what Generics are for, but sadly, they are not yet in PHP. Not even in the upcoming PHP 8. Hopefully in a near future, but we cannot predict that for now. Luckily, we have currently an alternative nowadays, but it’s not that popular. It has its own “pros” and “cons”, so let’s take a look at an example first:

<?php
function createInvoiceForCustomers(Customer ...$customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}

Everything here below would work at “compile-time”. It will for sure break during “runtime” if the createInvoice() receives something different than a Customer.

<?php
createInvoiceForCustomers(...$customers); // OK
createInvoiceForCustomers(
 new Customer('any name'), 
 new Customer('any name'),
); // OK
// This is not even possible to write. The IDE will yell at you. 
// It's expecting a `Customer`, but `AnyOtherType` is given:
createInvoiceForCustomers(new AnyOtherType());

PROS #

We can easily type a list of any concrete type.

CONS #

We better define our functions with one or two arguments max. Otherwise, it would be too complicated to read.

Important remarks #

It needs to be the last taken argument of a function.
It helps to minimize the number of arguments that we use in a function.

Variadics simulate typed arrays, use them wisely #

Argument unpacking is a great feature that, in combination with variadic functions, can help us to simulate typed arrays. With great power comes great responsibility, and this is no exception. We need to learn about our toolbox in order to use it wisely.

References #

Object design style guide

2020-10-10T00:00:00+00:00

Objects are the central concept of languages like Java, Python, C#. Applying best practices for object design means that your code will be easy to read, write, and maintain.

This book captures dozens of techniques for creating pro-quality OO code that can stand the test of time.

Examples are in an instantly-familiar pseudocode, teaching techniques you can apply to any OO language, from C++ to PHP.

Domain-Driven Design Distilled

2020-09-10T00:00:00+00:00

Domain-Driven Design Distilled brings DDD to life. Whether you’re a developer, consultant, or customer, it will help you understand it, so you can benefit from its power.

This book delivers powerful results in practice, which is why developers worldwide are rapidly moving to adopt it. This is an accessible guide to the basics:

What is DDD?
What problems does it solve?
How does it work?
How to quickly gain value from it?

You’ll learn how to segregate domain models using the powerful Bounded Contexts pattern, to develop a Ubiquitous Language within an explicitly bounded context and help domain experts and developers work together to create that language.

How to use Subdomains to handle legacy systems and integrate multiple Bounded Contexts to define team relationships and technical mechanisms.

Domain-Driven Design Distilled brings DDD to life.

Advanced Web Application Architecture

2020-08-16T00:00:00+00:00

This book helps you get your web applications back in shape. It contains many techniques for decoupling from infrastructure (like the framework or the database).

“The best guide that brings your coding and architecture skills a level up. All the modern PHP features combined with the elegance of a well-designed modular design.”

In Part 1 we unlock a collection of design patterns which help you establish a clean separation between core and infrastructure code. Part 2 shows how these design patterns resonate at a higher level with architectural concepts like layers, ports and adapters (a.k.a. Hexagonal architecture). The book finishes with a discussion of testing strategies and design trade-offs.

What you’ll learn #

Separating mixed code into core and infrastructure code by refactoring into patterns.
Dividing your code into layers, and making a clear distinction between an application’s ports and adapters.
Testing decoupled applications.

Buy the book: https://leanpub.com/web-application-architecture

Design patterns for modernizing legacy code bases #

Strict Types in PHP

2020-08-09T00:00:00+00:00

In December 2015, PHP 7 introduced scalar type declarations and with it the strict types flag. What is this new feature?

The good thing about declaring a PHP file as strict is that it actually applies to ONLY the current file. It ensures that this file has strict types, but it doesn’t apply to any other file in the whole project. It allows you to do, step by step, this migration from non-strict code to strict code, especially for new files or projects.

To enable the strict mode, a single declare directive must be placed at the top of the file. This means that the strictness of typing for scalars is configured on a per-file basis. This directive not only affects the type declarations of parameters, but also a function’s return type.

Strict types affect coercion types #

Using a type hint without strict_types may lead to subtle bugs.

Without this, int $x meant $x must have a value coercible to an int. Any value that could be coerced to an int would pass the hint type, including:

a proper int (example: 42 -> 42)
a float (example: 13.1459 -> 13)
a bool (example: true -> 1)
a null (example: null -> 0)
a string with leading digits (example: “15 Trees” -> 15)

By setting strict_types=1, you tell the engine that int $x means $x must only be an int proper, no type coercion allowed. You have the great assurance you’re getting exactly and only what was given, without any conversion or potential loss.

Who should care about this “strict type” line? #

Actually, declare(strict_types=1); is more for the reader than for the writer. Why? Because it will explicitly tell the reader:

The types in this current scope (file/class) are treated strictly.

‘strict_types=1’ is more for the reader than for the writer

The writer just needs to maintain such strictness while writing the expected behavior. That said, as a writer, you should care about your readers, which also includes your future self. Because you are going to be one of them.

References #

The Art of Refactoring

2020-06-28T00:00:00+00:00

If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask.

What is refactoring? #

Refactoring means improving your code. It can go from making a variable name more readable, extract some lines of code into a private method, or separate the responsibilities of a class into subclasses, for example.

Refactoring is the action of showing that you care about what you do as a professional. It can be a controversial topic; it is indeed one of the major controversial topics since a long time ago. But we shouldn’t stop trying our best in order to improve the quality of the system just because of that controversiality.

When and how should we refactor? #

Always. In the scope of your current task unless it is an already planned task, something like “architecture refactoring” or similar, where the scope of the task is actually to do refactoring.

Refactoring should be part of our daily job, not a separate task by default.

We do not need to ask permission to refactor. Or do we ask our managers for permission to do our best job?

In order to do proper refactoring, the intention of such refactoring needs to be clear. What is intended to achieve and how? Pair programming (or even pair thinking!) certainly helps in this topic because it syncs two brains on the same topic and that encourages team building and a better understanding of them.

Applying refactoring in a collaborative way, in a “bidirectional channel”, is fundamental when working within a team. Refactoring shouldn’t be a taboo topic, on the contrary: it will be helpful in order to unify the goals and the direction of the team code quality.

Some personal advice about the “how” #

Continuous improvement is what we’re looking for within this topic, but…

If you realize your changes are generating more noise than help, stop immediately and think again if your changes are worth it in the current system status.

Maybe it’s not the right moment for that refactoring.

Maybe you are polluting your current diff with out-scoped changes.

Or, maybe, your refactoring idea is too big to be applied in your current task. In such a case, a follow-up task (in order to apply the refactoring) would be a better idea.

If you see that refactoring is perhaps needed even before starting your current task, do the refactoring first.

We usually refactor in order to increase our productivity, making the code more readable and therefore easier to understand.

Testing #

Be aware that you should have a pretty good suite of tests covering the logic that you might have changed. Without tests, refactoring can be really risky. Usually, the easier something is to be tested, the easier it is to be replaced or removed.

You can read more about how testing is related to quality here.

Why should we do it? #

Wouldn’t you want to have a better system as time goes by?

Software isn’t like wine: it doesn’t get better as time passes by. Therefore, if you want to have a better system you must work for it.

Final Classes in PHP | Java | Any

2020-06-06T00:00:00+00:00

Clear contracts, isolated side effects, testability, low complexity and cognitive load, code fluidity, and confidence in yourself.

Motivation #

Reduce the scope visibility to the minimum #

When you see a class prefixed with final you will prevent a particular class to be extended by any other, which not only makes it more readable but also makes you be sure that the scope of the logic where you are is limited to that particular class.

Encourage “composition over inheritance” mentality #

The Open-Close Principle states: open for extension but closed for modification.

If for any reason, a good one you should be completely aware of, you decide to create an inheritance there, well, then just drop the final keyword and you are good to go.

When you “by default” can’t extend from a class (because it’s final), you will help yourself by thinking about using composition instead of inheritance.

Why isn’t this class final? #

If we aim for composition over inheritance, then we should try to avoid inheritance as much as possible, and use it only when it’s really necessary. Inheritance is often misused in OOP.

Misconception #

When we first taught OOP, we usually introduced the classic inheritance example.

Nonetheless, when Alan Kay created Smalltalk, the inheritance was never the main concept of it. The main concept was messaging, which is that you can send messages to objects and they encapsulate the data and logic in it, and you can change their behavior by using different objects, which is actually composition. But the concept of inheritance is so popular that it eventually overshadows composition.

Benefits #

Clear contracts. Using interfaces will force you to think in terms of communication between objects.
Isolated, side effect free code units. Injecting interfaces only as dependencies will remove every nasty side effect around the code you are working on.
Testability. Mocking dependencies is extremely easy when they are interfaces.
Low, manageable complexity. Since everything is isolated, you won’t need to worry about rippling changes. This dramatically decreases the complexity of your code.
Low cognitive load. With decreased complexity, your brain will be free to focus on what matters.
Code fluidity. By removing any unnecessary coupling, you will be able to move things around way more easily than before.
Confidence in yourself. Being able to test your code in isolation so well will give you a wonderful sense of confidence in changing it.

Composition over inheritance #

If you feel the need to reconfigure an object, to change parts of an algorithm, or to rewrite part of the implementation, consider creating a new class instead of overriding an existing class. If you need to represent a hierarchy of classes, where subclasses are proper substitutes for their parent classes. This would be the classic situation where you may still consider inheritance. However, the result may even be better if you don’t inherit from concrete parent classes but from abstract interfaces.

What you should start doing instead #

Use interfaces to define the contracts between your classes.
Use final classes to implement behavior for those interfaces.
Use composition (using dependency injection through constructor) to put things together and prevent complexity.

Interfaces -> Final classes -> Composition

7 languages in 7 weeks

2020-05-21T00:00:00+00:00

You should learn a programming language every year, as recommended by The Pragmatic Programmer. But if one per year is good, how about Seven Languages in Seven Weeks? In this book you’ll get a hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Whether your favorite language is on that list, you’ll broaden your perspective of programming by examining these languages side-by-side. You’ll learn something new from each, and best of all, you’ll learn how to learn a language quickly.

I created this repository with all my learnings while I was reading and playing aroung with the languages from this book https://github.com/Chemaclass/7LangIn7Weeks

The Art of Testing: Where Design Meets Quality

2020-04-07T00:00:00+00:00

Why you should consider testing as part of your daily development habit and how it’s directly linked to the software quality.

This post intends not to explain the different testing techniques that we can use. I’m not going to tell you the differences between unit, integration, feature, or end-to-end testing.

I’m still amazed by the lack of experience with testing in software in general. Common ignorance in this world about best testing practices for us as developers. Inexperience that you can easily see if you have already worked on different projects and teams.

Software testing #

Some horrible patterns I’ve seen (and done):

Testing for the sake of testing: testing every single file, sometimes wrongly considered a unit.
Mocking every class we intend to test, overriding the actual implementation, and creating a fake behavior, providing a false coverage perception.
Coupling production code with tests everywhere, so it’s impossible to change anything without breaking some tests, even if the feature itself it’s working as intended.
Not testing at all because “why should we even test anything if the feature is done, and it works? Why should we spend more time on this if it’s done?.”

One of the main reasons for software testing is actually verifying a suite of proofs for the expected behavior of the final software piece. However, testing can (and should) be more than that.

Software design #

Software design goes from algorithm to architecture design. Even when I believe these two levels of components have different needs and requirements, they still share some common patterns. For example, testing, and this is what we are going to talk about right now:

If it’s easy to test, it will likely be because of good design.

Software quality #

Is quality hard to measure out? Indeed. There are different measurement keys that we should take while considering quality for any piece of software. Still, I’m sure we could agree on this:

If you aim for quality in your software, you better seek a good design.

Testing by itself means “proving,” as we all know. That said… how difficult it sometimes turns to prove some logic that we finally give up because of its complexity itself?

The art of testing is about using testing itself to help and contribute to the final result. To encourage good design, suppose we’re able to use testing (of any kind) in our favor, depending on the context of what we want to prove. In that case, it will undoubtedly help us increase the product’s end quality.

Therefore, testing should be used not only to prove the behavior of our software but also to guide our software to a better design.

Should we test everything? Well, that’s the million-dollar question. In my opinion, everything depends on the context. We might encounter situations where tests might not be beneficial. Even in those situations, we should write our code as if it could be tested anyway.

Testable code tends to better design and, therefore, better quality.

Clean Agile

2020-03-12T00:00:00+00:00

Clean Agile comes from Uncle Bob, one of the founding fathers of Agile, one of the seventeen people who authored the Agile Manifesto back in 2001.

This talk is about Agile. What it was, what it is, and what it will be. This is a back-to-basics talk that covers the history of Agile, what motivated it, and what has happened to it since. The talk covers the basic practices of Agile, and compares and contrasts those practices with the current menagerie of Agile processes.

Working Effectively with Legacy Code

2019-07-01T00:00:00+00:00

What is legacy code? #

Legacy code is simply code without tests.

Benefits of tests #

Behavior is central to understanding the benefits of testing:

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.

How to get tests in place in legacy codebases #

When we change code, we should have tests in place. To put the tests in place, we often have to change code.

The suggested approach:

Identify change points.
Find test points.
Break dependencies.
Write tests.
Make changes and refactor.

Another useful term is a “seam.” A seam, in this context, is “a place where you can alter behavior in your program without editing in that place”. The analogy is to a seam in clothing, the place where two parts are stitched together. In software, these places are generally places where there are well-defined interfaces. This can be leveraged to change the implementation using techniques such as dependency injection or mocking interfaces in the case of writing tests.

Clean Architecture

2018-06-04T00:00:00+00:00

Code design principles (SOLID) #

Single Responsibility: a class should have one, and only one, reason to change. Or the new version: a module should be responsible to one, and only one, actor.
Open-closed: a class should be open for extension but closed for modification.
Liskov’s Substitution: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Interface Segregation: many client-specific interfaces are better than one general-purpose interface.
Dependency Inversion : one should depend upon abstractions, not concretions.

Component principles #

Component cohesion #

Reuse/Release Equivalence Principle: classes and modules (i.e. a component) reused together should be released together. They should have the same version number and there should be proper documentation such as changelogs.
Common Closure Principle: classes that change together should be grouped together, and vice versa. The single responsibility principle at component-level.
Common Reuse Principle: don’t force users of a component to depend on things they don’t need. The Interface Segregation Principle at component-level.

Component coupling #

Acyclic Dependencies Principle: no cycle in the dependency graph. Cycles couple components and, among other things, force them to be to released together. Use the dependency inversion principle to break cycles.
The Stable Dependency Principle: less stable components should depend on more stable components. Depend on the direction of stability.
Stable Abstractions Principle: stable components should be abstract, and vice versa. An example of an abstract stable component is a high-level policy which is changed by extension following the open-closed principle.

Architecture principles #

Setting boundaries #

Boundaries are lines that separate software elements. They separate things that matter from things that don’t, i.e. high-level components from low-level components. If a high-level component depends on a low-level component at the source level, changes in the low-level components will spread to the high-level component. Therefore, we place a boundary between the two, using polymorphism to invert the logic flow. This is the Dependency Inversion Principle in the SOLID principles.

Separating layers #

We can identify four main layers, although the number may vary:

Entities: objects containing critical business logic. For example, a bank could establish that no loans are granted to customers not satisfying some credit score requirements. Entities may be shared across apps in the same enterprise.
Use-cases: app-specific business rules. For example, the sequence of screens to execute a bank transfer.
Interface adapters: Gateways, presenters and controllers. For example, this layer will contain the MVC architecture of the GUI and also objects that transform data between the format of the database and the use-cases.
Frameworks and drivers: web frameworks, database, the view of MVC.

The Pragmatic Programmer

2016-10-01T00:00:00+00:00

Takeaways #

Don’t Repeat Yourself.
Mindset is as important as knowledge.
Good code is easier to change than bad design.
Choose great tools and become fluent with them.

Don’t Repeat Yourself (DRY) #

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.

Mindset is as important as knowledge #

Some important aspects of this mindset include:

Taking responsibility for your work by not making excuses or passing blame when things go wrong.
Writing software that’s good enough. This means not wasting time on things that are better than they need to be to make the product successful.
Not ignoring technical debt. The authors use the analogy of broken windows:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead.

97 Things Every Programmer Should Know

2016-07-15T00:00:00+00:00

Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you’ll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice.

My main key takeaways #

01.- Pay off technical debt as soon as possible.

02.- Learn and master functional programming.

It makes your code less prone to error and easier to debug.

03.- Don’t guess what a user would do; get users to do things and watch them.

04.- Automate coding standards.

05.- Write simple code, simple descriptive names, simple relationships.

06.- Before you refactor: consider the existing tests and code.

Work in increments, make sure the tests still pass after every change.

08.- Always leave code cleaner than you found it, even if you didn’t write it.

10.- Choose your libraries/frameworks carefully to avoid unnecessary complexity.

11.- Make your code easy to understand using domain terms.

13.- The layout of the code is also important.

14.- Use code reviews focusing on knowledge-sharing among team members.

15.- Objects immutable whenever relevant. Each variable should have the smallest possible scope. Never include more than four function arguments.

18.- Take responsibility for your own education and never stop learning.

That can be done with just a bit of time each week and there are many ways to go about it (e.g. podcasts, lessons, books, etc.).

19.- When designing an API, aim to make it easy to use, not convenient to code.

20.- Deploy early and often. Do not leave it until the end of the project.

22.- Improving your skills should be on your daily basis.

23.- Adapt the technical level of your domain-specific language to your audience.

24.- Don’t be afraid to break things if that’s what’s necessary to fix things.

25.- Careful with your test data because that might go public accidentally.

26.- Handle your errors as they appear, don’t leave it for later.

27.- Learn different programming languages.

Learn their own “culture” or way of doing things.
It’ll make you definitely a better programmer.

28.- Don’t just catch your errors, really handle them.

29.- Understand at least some complexities of your business, not just programming.

30.- DRY: Don’t Repeat Yourself.

32.- Encapsulate behavior, not just state.

33.- Floating point numbers inevitably can create errors in calculations.

34.- Open source is a great opportunity to do interesting work and develop programming skills.

36.- Give proper context when asking for help, because people can’t just guess what’s going on.

37.- It’s not about the long hours. Learn to work effectively.

Dedicate time to continuous learning and to think about what you’re doing.

38.- Write proper bug reports:

Precisely how to reproduce the bug,
how often it appears,
what should have happened,
what actually happened.

39.- Don’t write unnecessary code.

Only write code that adds value and is needed right now.
Remove dead code.

41.- The main cause of delays in application response time is a high number of remote interprocess communications, not the algorithm.

DB connections, for example.

42.- If a compiler warning shows up in your build, fix it.

Don’t leave it for later. Even if it’s not going to be a problem in production.
Compiler == any static code analysis for non compiled languages.

43.- Learning to use command line tools is a valuable educational experience, and you might end up preferring them.

44.- Learn (at least) two different languages and paradigms well.

45.- Invest some time to master the IDE you’re using.

It’ll make your life easier and save you time in the long run.

46.- Know and work with your limitations: budget, resources, time, etc.

47.- Work in small tasks, don’t be afraid to throw away changes.

You’ll still have the insight you gained from the experience.
Know what you need to accomplish beforehand.

48.- Use a relational DB if your application is going to handle a large, persistent, interconnected set of data.

49.- Learn to communicate well in many “languages”: not just to your machine, but also to business partners, and maybe even pick up a foreign language too.

It’s good for connections and for life.

54.- Think twice before implementing “temporary solutions”.

55.- Make GUI easy to use correctly and hard to use incorrectly.

Anticipate errors and find ways to prevent them.
It’s about the user’s experience, not your own.

56.- In projects, find ways to make the invisible visible.

57.- Message passing leads to better scalability in parallel systems.

58.- Write code that other people can easily understand.

59.- Using polymorphism in your classes and objects reduces the need for if/else statements, which results in smaller, safer code.

60.- QA is your friend, not your enemy.

61.- Version your releases.

62.- Make sure your source code clearly states what the program is doing.

63.- Learn about the build process. It’s an important part of development.

64.- Practice pair programming.

65.- Prefer domain-specific types over primitive types.

They make the code more readable and less prone to errors in development.

67.- A professional takes personal responsibility for their career and their code.

68.- Use version control.

69.- Sometimes the best way to solve a problem is to step away from the computer and let the solution magically appear in your mind.

70.- Reading code is a good way to learn. Other people’s or your old code.

72.- Reinventing the wheel is a great way to develop your skills.

75.- If the code you wrote is truly horrifying, don’t try to fix. Delete it and start again.

76.- Apply the Single Responsibility Principle (SRP).

77.- If a client or team member requests a product change, don’t dismiss it outright even if you don’t agree. Ask why instead.

That will lead to a more productive conversation and better results.

78.- If you’re doing the same thing over and over, try to find a way to automate it.

79.- Take advantage of code analysis tools.

80.- Write tests based on the desired functionality of your program, not incidental behavior.

83.- Testing takes time, but it ensures the quality of the end product. Do it.

85.- There are many benefits to collaborative work and pair programming.

86.- Sometimes fixing a mistake in the code leads to uncovering a hidden error.

87.- Write code with other programmers in mind.

88.- Learn to use Unix tools. Learn how to use the terminal.

89.- Use the right algorithm and data structure for the job.

To do that, you need to understand them well.

90.- Have a good logging policy.

91.- Using the DRY principle helps you identify and repair performance bottlenecks.

92.- Testers and programmers should collaborate.

93.- Write code as if you had to support it for the rest of your life.

94.- Try to write “small” functions.

Good tests act as documentation for the code they’re testing.

They describe how the code works.

To be a good programmer, you have to care about the quality of the code.
Really, really discuss things with your customers before assuming you understand what they want.

Clean Code

2016-05-01T00:00:00+00:00

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Summary #

Chapter 1: What Is Clean Code? #

The code can be measured with either “good” or “bad” in the code review or by how many minutes it takes you to talk about it.
A clean code should be elegant, efficient, readable, simple, without duplications, and well-written.
You should add value to the business with your code.
Clean code offers quality and understanding when we open the source file.
It is necessary that your code is clean and readable for anyone to find and easily understand. Avoid wasting others’ time.

Chapter 2: Meaningful Names #

Names of the classes, variables, and methods must be meaningful and clearly indicate what a method does or what an attribute is.
Create pronounceable names to facilitate communication.
Avoid acronyms and avoid confusing names, which may bring anyone who reads the code to the wrong conclusions.
Use names that reflect the system domain, the context, and the problems that must be solved.

Chapter 3: Functions #

Methods should be easy to read and understand.
Methods should convey its intention.
Methods should be small.
They must have up to 20 lines.
Methods should only do one thing.
You should use names with words that say what it really does.
The optimal number of parameters of a method is zero, after one and two.
Three should be avoided, but if you think it should be used, have a justification.
Boolean type as a parameter already states that it does more than one thing.
Avoid duplication.

Chapter 4: Comments #

One of the common reasons for comments is because the code is bad.
If you’re thinking about writing a comment, then the code should be refactored.
Comments do not save a bad code.
Try to explain what the code causes happening.
Comments can be useful when placed in certain places.
Don’t explain your code with comments. Use informative vars/method names.
Comments can be used to express the importance of certain points.
Do not write comments with redundant, useless, or false information.
They shouldn’t be used to indicate who changed or why, use versioning.
Don’t comment code that will not be used. Remove it instead.

Chapter 5: Formatting #

Formatting should indicate things of importance since it is a developer of communication form.
A messy code is hard to read.
The readability of the code will take effect on all the changes that will be made.
Smaller classes are easier to understand.
Set a limit of characters per line of code. For example 120.
Try to keep more next related concepts vertically to create a code stream.
Use spaces between operators, parameters, and commas.

Chapter 6: Objects and Data Structure #

Follow the Law of Demeter:
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends.
Do not make dumb objects.
Objects hide the data abstraction and expose methods that operate the data.
Data structures expose your data and do not have significant methods.

Chapter 7: Error Handling #

Error handling should be planned carefully by all programmers.
When wrong things occur, we have to get it to do the right things.
Give preference to launching an exception than treating it just to hide.
Create messages with information about the error.
Mention that it failed. Where was this failure? If possible, mention why it failed.
Look at separate business rules for errors and error handling.
Avoid returning a NULL in methods, preferably to return an empty object.
Avoid passing NULL to the methods; this can generate NullPointerExceptions.

Chapter 8: Boundary #

In third-party code, to avoid passing objects, APIs look forward in order to keep things in the same class.
Perform tests on the API’s third party.
Study the documentation and test the third API before you start using it.
Check well the features you will use.

Chapter 9: Unit Tests #

Make sure each piece of code is doing what you expect it to do.
Follow the TDDs law:
- Don’t create code before you have a failing test.
- Don’t create more tests than necessary to fail.
- You cannot write more code than enough to pass the test that is failing.
Keep your test clean.
The tests must undergo changes in the same way that the code.
The dirtier the code, the more difficult test will be to maintain.
Use the F.I.R.S.T rule for testing:
- The test is fast-running.
- The tests are independent of others.
- The test is repeatable in various environments.
- The test is self-validating.
- The test is timely.
The test is as important as the production code.

Chapter 10: Classes #

By default, classes should start with the variables:
- Static and constants public.
- Static and variable private.
- Instances and variables privates.
- Soon after comes the functions.
- The class name should represent its responsibility.
The class must have only one responsibility: one reason to change.
You should try to make a brief description of the class.
The methods should be small and one responsibility.

This interview is based on Uncle Bob’s book “Clean Code”. They cover some existing guides that can help you become a better programmer and explore how books and current trends are shaping the software landscape.