DEV Community: Theo Millard

Data Passing in iOS Apps - UI Kit

Theo Millard — Mon, 02 Jun 2025 15:05:43 +0000

Passing data to between view controllers is crucial in your application flows.
There are 2 types of passing data:

Passing Data to Another ViewController
- when creating new view controller
Returning Data to Previous Activity
- when closing current view controller

There will be more detailed explanation with example below.

Passing Data to Another ViewController

Property Access

Detail View Controller

class DetailViewController: UIViewController {
    var gameTitle: String?

    override func viewDidLoad() {
        super.viewDidLoad()
        print("Selected Game: \(gameTitle)")
    }
}

Main View Controller

class MainViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        print("Game List: ")

        let Button = UIButton()
        // Add Event Listener - FOR EXAMPLE
        Button.addTarget(self, action: #selector(navigateToDetail),for: .touchUpInside)
    }
    @objc func navigateToDetail() {
        // Create view controler page object 
        let otherViewController = DetailViewController()
        otherViewController.gameTitle = "Black Myth Wukong"
        // push new detail page
        navigationController?.pushViewController(otherViewController, animated: true)
    }
}

Even though it seems much simpler, it also can introduce new bugs. Here, using variable provide no documentation.
Let's say we want to call the detail in another view controller, we simply can forgot to modify the variables.

Or we have many variables, we can easily skip one of them and only can caught it when testing or applications are running.

Benefits

Easy to Implement

Drawbacks

No Documentation on what's variable need to be filled
No compile-time safety: Any forgotten passes only be caught after testing or running the app

init Function

Detail View Controller

class DetailViewController: UIViewController {
    private let gameTitle: String

    init(gameTitle: String) {
        self.gameTitle = gameTitle
        // Need to implement if creating init
        super.init(nibName: nil, bundle: nil)
    }

    // Need to implement if creating init on storyboard 
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        print("Selected Game: \(gameTitle)")
    }
}

Main View Controller

class MainViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        print("Game List: ")

        let Button = UIButton()
        // Add Event Listener - FOR EXAMPLE
        Button.addTarget(self, action: #selector(navigateToDetail),for: .touchUpInside)
    }
    @objc func navigateToDetail() {
        // Create view controler page object 
        let otherViewController = DetailViewController(gameTitle: "Black Myth Wukong")
        // push new detail page
        navigationController?.pushViewController(otherViewController, animated: true)
    }
}

Here, using init can provide more clear and documentations. If we want to call the detail view controller in other places, we can just init it with arguments.

Also, if we add more variables, other class that init this will have compile error and must adapt to new init function.

Benefits

Extra safety on compile-time: If you add new params, all the functions call need to adapt
Extra documentation on what arguments needed
More clean
More scalable

Drawbacks

Custom initializer

Returning Data to Previous Activity

Closure

Detail View Controller

class DetailViewController: UIViewController {
    private let gameTitle: String
    private let onSubmitHandler: (String) -> Void

    init(
        gameTitle: String,
        onSubmitHandler: @escaping (String) -> Void
    ) {
        self.gameTitle = gameTitle
        self.onSubmitHandler = onSubmitHandler
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func submitTapped() {
        onSubmitHandler("Game: \(gameTitle)")
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        print("Selected Game: \(gameTitle)")
        // EXAMPLE - Directly calling the onSubmitHandler
        submitTapped()
    }
}

Main View Controller

func navigateToDetail() {
    /// Create demo `ClosureViewController` page object
    let viewController = DetailViewController(
        gameTitle: "Black Myth Wukong",
        // weak self explanation below
        onSubmitHandler: { [weak self] result in
            // got result and can do anything
            print(result)
        }
    }

    /// Push detail page into navigation controller
    navigationController?.pushViewController(viewController, animated: true)
}

Here, passing the closure function can use both of the method that is given on the first part. In the example we use the init one.

Passing weak self in closure, making sure there is no memory leaks. If Parent got cleaned or get deinitialized, if the Child doesn't have other reference count,
memory will be freed.

Benefits

No boilerplate (Protocol)
Easy to implement, just pass the closure

Drawbacks

Harder to digest (Closure)
Not common practices
Hard to test

Delegate

Detail View Controller

protocol PrinterDelegate: AnyObject {
    func printInfo(gameTitle: String) -> Void
}

class DetailViewController: UIViewController {
    private let gameTitle: String
    // weak var same explanation with above
    weak var printerDelegate: PrinterDelegate 

    init(
        gameTitle: String,
        printerDelegate: PrinterDelegate
    ) {
        self.gameTitle = gameTitle
        self.printerDelegate = printerDelegate
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func submitTapped() {
        // calling delegate's function
        printerDelegate.printInfo(self.gameTitle)
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        print("Selected Game: \(gameTitle)")
        // EXAMPLE - Directly calling the onSubmitHandler
        submitTapped()
    }
}

Main View Controller

class MainViewController: UIViewController, SelectionDelegate {
    func navigateToDetail() {
        // Conforms to delegate
        func printInfo(gameTitle: String) -> Void {
            // Can do anything we want
        }
        /// Create demo `ClosureViewController` page object
        let viewController = DetailViewController(
            gameTitle: "Black Myth Wukong",
            // Pass self
            printerDelegate: self
        }

        /// Push detail page into navigation controller
        navigationController?.pushViewController(viewController, animated: true)
    }
}

Here, by using protocol, each class that want's to create detail view controller needs to conform to the protocol. creating more separation.

Benefits

Scalable and Reusable
Easier only need to create normal function not closure
More common and easy to test

Drawbacks

Boilerplate

References

Swift Passing Data Between View Controllers

Swift Basics: Enums

Theo Millard — Mon, 02 Jun 2025 02:20:50 +0000

An enumeration defines a common type for a group of related values and enables you to work with those values in a type-safe way within your code.

Basic Enum Example

enum CompassPoint {
    case north
    case south
    case east
    case west
}

// Initiation can be done like this
let currentState = CompassPoint.east

// or like this
let direction:CompassPoint = .east

Switch in Enum

switch directionToHead {
case .north:
    print("Lots of planets have a north")
case .south:
    print("Watch out for penguins")
case .east:
    print("Where the sun rises")
case .west:
    print("Where the skies are blue")
}

Iterable Enum

Here, we can check the count and loop over the enums

enum Beverage: CaseIterable {
    case coffee, tea, juice
}
let numberOfChoices = Beverage.allCases.count
print("\(numberOfChoices) beverages available")

for beverage in Beverage.allCases {
    print(beverage)
}

By using enums, the variable can easily checked and compared.

Other things about enums is, you can use it to specify the error type that you want to return

enum FileError: Error {
    case notFound
    case permissionDenied(reason: String)
}

func readFile(named name: String) throws {
    if name.isEmpty {
        throw FileError.notFound
    }
    if name == "secret.txt" {
        throw FileError.permissionDenied(reason: "User lacks read access")
    }
    print("File '\(name)' read successfully.")
}

do {
    try readFile(named: "TEXT.txt")
} catch let error as FileError {
    switch error {
    case .notFound:
        print("Error: File not found.")
    case .permissionDenied(let reason):
        print("Error: Permission denied - \(reason)")
    }
} catch {
    print("An unknown error occurred: \(error)")
}

Coroutine - Kotlin

Theo Millard — Tue, 27 May 2025 02:05:15 +0000

Coroutine - Kotlin

A coroutine is a programming construct that allows a function to suspend its execution and resume it later, enabling cooperative multitasking and asynchronous programming

Key Characteristics of Coroutines

Cooperative Multitasking:

Coroutines don't preemptively switch between tasks; they voluntarily yield control (suspend) to allow other tasks to run.

Non-Blocking Operations:

This cooperative nature enables coroutines to perform tasks without blocking the main thread or other operations, making them suitable for UI-related tasks and I/O operations.

State Preservation:

Coroutines maintain their state between suspensions, allowing them to resume where they left off.

Suspension and Resumption:

Coroutines use special keywords or mechanisms (like await in Python or yield in Unity) to suspend their execution and resume later when needed.

Benefits of Using Coroutines

Simplified Async Programming:

Coroutines provide a cleaner and more readable way to handle asynchronous operations compared to traditional callbacks or promises.

Improved Code Structure:

Coroutines can help organize complex asynchronous logic, making it easier to understand and maintain.

Resource Efficiency:

Coroutines are lightweight and don't require the overhead of creating and managing multiple threads.

Concurrency Without Threads:

In some cases, coroutines can provide the illusion of concurrency without the need for actual threads, improving efficiency.

Examples

import kotlinx.coroutines.*

fun main() = runBlocking {
    println("Main starts: ${Thread.currentThread().name}")

    // Launching a coroutine
    val job = launch {
        delay(1000) // Non-blocking delay (suspends coroutine)
        println("Coroutine says hello from: ${Thread.currentThread().name}")
    }

    println("Main continues...")
    job.join() // Wait for the coroutine to finish

    println("Main ends: ${Thread.currentThread().name}")
}

Higher-Order Functions

Theo Millard — Mon, 26 May 2025 02:58:37 +0000

Kotlin functions are first-class

Can be stored in variables or data structures
Can be passed as arguments
Can be returned from higher-order-functions (functions that returns a function)

Functions

Kotlin functions are declared using fun keyword.
Function parameters are defined name: type, separated using commas.

fun add(x: Int, y: Int): Int {
    return x + y
}

Kotlin functions can have default arguments

import kotlin.random.Random

fun getRandomPercentage(start: Int = 0, end: Int = 100): Int {
    return Random.nextInt(start, end)
}

getRandomPercentage() // Random number from 0-100
getRandomPercentage(20,30) // Random number from 20-30
getRandomPercentage(end = 50) // Random number from 0-50

Higher-Order Functions

A function that takes functions as parameters, or returns a function

Here, fold takes a combine function which takes params (acc and next num) and returns new acc.
The operations can be anything, as long returning same acc value.

fun <T, R> Collection<T>.fold(
    initial: R,
    combine: (acc: R, nextElement: T) -> R
): R {
    var accumulator: R = initial
    for (element: T in this) {
        accumulator = combine(accumulator, element)
    }
    return accumulator
}

val items = listOf(1, 2, 3, 4, 5)

items.fold(0, { 
    acc: Int, i: Int -> 
    val result = acc + i
    result
})

Example on projects:
Here I have setupOperatorButton to receive a functions with params (2 doubles) and return String.
Here I only need to pass the calculator functions.

class MainActivity : AppCompatActivity() {
    private lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        val view = binding.root
        setContentView(view)
        setupBtnListener()
    }

    private fun setupBtnListener() {
        setupOperatorButton(binding.plusBtn) { a, b -> Calculator.add(a, b) }
        setupOperatorButton(binding.minBtn) { a, b -> Calculator.subtract(a, b) }
        setupOperatorButton(binding.mulBtn) { a, b -> Calculator.multiply(a, b) }
        setupOperatorButton(binding.divBtn) { a, b -> Calculator.divide(a, b) }
    }

    private fun setupOperatorButton(button: View, operation: (Double, Double) -> String) {
        button.setOnClickListener {
            val a = binding.numberOneEt.text.toString().toDoubleOrNull()
            val b = binding.numberTwoEt.text.toString().toDoubleOrNull()
            val result = operation(a, b)
            binding.resultTv.text = result
        }
    }
}

object Calculator {
    fun add(a: Double, b: Double): String {
        val result = a + b
        return result.toString()
    }

    fun subtract(a: Double, b: Double): String {
        val result = a - b
        return result.toString()
    }

    fun multiply(a: Double, b: Double): String {
        val result = a * b
        return result.toString()
    }

    fun divide(a: Double, b: Double): String {
        if (b == 0.0) return "NaN" // or handle division by zero separately
        val result = a / b
        return result.toString()
    }
}

References

higher-order functions by Kotlin

Adapter Pattern in Kotlin

Theo Millard — Mon, 26 May 2025 01:10:57 +0000

Structural design pattern
Allow two or more different interfaces to work together
Bridge between two classes with different interfaces, allowing the two work together seamlessly.

Problems

You want to use some functionality.
There are so many services that have different interfaces.
Various inputs that only match with one of the interfaces.

Real-life Example

We can see Adapter pattern in literally memory card adapter,
we can read different type of cards (miniSD, microSD) and able to read them all using single adapter

Adapter Pattern

Most of the adapter pattern will have 3 components:

Client - Needs to use adaptee, but incompatible
Adapter - bridge client and adaptee
Adaptee - More than 1 Class, needs to be implemented but doesn't share same interfaces or incompatible with each other.

For Example:

We will be building card reader:

Client - Class MediaReader
Adapter - Class MediaAdapter
Adaptee - MicroSDdReader, MiniSDReader, FlashdiskReader

Kotlin Example

// Interface for adapter class implementation and functionality to be used
// Adapter will implement this
interface CardReader {
    fun read(cardType: String, fileName: String)
}

interface SpecificMediaReader {
    fun read(fileName: String)
}

class MicroSDReader : SpecificMediaReader {
    override fun read(fileName: String) {
        println("Reading from MicroSD: $fileName")
    }
}

class MiniSDReader : SpecificMediaReader {
    override fun read(fileName: String) {
        println("Reading from MiniSD: $fileName")
    }
}

class FlashdiskReader : SpecificMediaReader {
    override fun read(fileName: String) {
        println("Reading from Flashdisk: $fileName")
    }
}

class CardReaderAdapter : CardReaderInterface {
    override fun read(cardType: String, fileName: String) {
        val reader: SpecificMediaReader? = when (cardType.lowercase()) {
            "microsd" -> MicroSDReader()
            "minisd" -> MiniSDReader()
            "flashdisk" -> FlashdiskReader()
            else -> null
        }

        if (reader != null) {
            reader.read(fileName)
        } else {
            println("Unsupported card type: $cardType")
        }
    }
}

// Usage Example
fun main() {
    val cardReader = CardReaderAdapter()

    cardReader.read("MicroSD", "data.txt")
    cardReader.read("MiniSD", "photo.jpg")
    cardReader.read("Flashdisk", "video.mp4")
    cardReader.read("BluRay", "movie.mkv") // Unsupported
}

Common Uses in Android Practices

RecyclerView Adapters: Convert data into ViewHolder items for efficient display in a RecyclerView.
ListView Adapters: Adapt data for ListView and GridView components.
ViewPager Adapters: Adapt pages for ViewPager to display a series of fragments or views.

Here raw data will be translated to what RecylerView(RV) Understand which is UI elements, so that RV can render

// Data class representing an item
data class User(val name: String, val age: Int)

// ViewHolder class
class UserViewHolder(view: View) : RecyclerView.ViewHolder(view) {
    val nameTextView: TextView = view.findViewById(R.id.nameTextView)
    val ageTextView: TextView = view.findViewById(R.id.ageTextView)
}

// Adapter class
class UserAdapter(private val userList: List<User>) : RecyclerView.Adapter<UserViewHolder>() {

    // Specify layout
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): UserViewHolder {
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.item_user, parent, false)
        return UserViewHolder(view)
    }

    // Translating data to each view will be easier, can easily be customized here
    override fun onBindViewHolder(holder: UserViewHolder, position: Int) {
        val user = userList[position]
        holder.nameTextView.text = user.name
        holder.ageTextView.text = user.age.toString()
    }

    override fun getItemCount(): Int {
        return userList.size
    }
}

Pros

Allows incompatible interfaces/class to work together
Save time and effort, eliminating needs to modify existing code
Promotes reusability
Adapter handles translation logic, and other can focus on their own functionality
Can add new adaptee and only touch the adapter layer
Create ways to works with legacy code to match our needs

Cons

Adding complexity, translating each classes to fit to the interfaces
Overhead, since it needs to be instantiated and maintained
More layers
Adapter will be rigid because use hardcoded branching

References

Overdraw, Memory Leaks, ANR and Slow Rendering in Android Apps

Theo Millard — Fri, 23 May 2025 02:05:21 +0000

Overdraw

Any jerks or lag or performance or slowness may antagonize a user from using the App. Overdraw might be one of the causes.

Overdraw is when a pixel on the screen drawn multiple times.
Represented in four stages, which are 1x, 2x, 3x, and 4x.

To Diagnose Overdraw, we can use developer options android and turn on the debug GPU overdraw.

Tutorial on turning on developer options and Debug GPU overdraw:

Enable Developer options. Click on the Build Number multiple times.

Fig 1. Enable Developer Options**

Enable Debug GPU Overdraw.

Fig 2. Enable GPU Overdraw**

Memory Leaks

ANR - Application Not Responding

App in the foreground and is unresponsive, user will get Application Not Responding - ANR.
If not in foreground, then it's silently stopped.

Fig 3. ANR Dialog**

ANR Triggers

Usually when app can't respond to user input on main thread or UI thread.
Preventing system from processing input events from users.

Examples:

Blocking I/O operation. Such as network access
Taking time building in-memory structure
Computing something expensive in Main or UI Thread

Android will trigger ANR when:

No responses to an input event - within 5 seconds
BroadcastReceiver doesn't finish executing within 10-20 seconds

BroadcastReceiver is the one that listens for events either on app or system

Prevention of ANR

Keep the main or UI thread unblocked:

Don't perform blocking or long-running applications
Minimize any lock contention - accessing same resources at the same time
Use threads strategically - worker threads

Usually 100-200ms is the threshold for slowness in an app

References

ANRs by Developer.Android

Slow Rendering

UI rendering is an act of generating a frame from your app and displaying it on the screen.

To Achieve 60fps - frames per second, each frames must be able to be renderd under 16ms

Identify Jank - Stuttering or unsmooth motion in app's UI

Identifying jank can be difficult. Stated from Developer.Android there are 3 method for identifying jank:

Visual inspection - fast
Systrace - more detail, more data which also means more difficult to analyze
Custom performance monitoring

Profile GPU Rendering also can be used to analyze GPU rendering and we can anlyze where is the bottleneck of the application

References

Slow Rendering by Developer.Android

Overdraw, Memory Leaks, ANR and Slow Rendering in Android Apps

Theo Millard — Fri, 23 May 2025 02:05:21 +0000

Overdraw

Any jerks or lag or performance or slowness may antagonize a user from using the App. Overdraw might be one of the causes.

Overdraw is when a pixel on the screen drawn multiple times.
Represented in four stages, which are 1x, 2x, 3x, and 4x.

To Diagnose Overdraw, we can use developer options android and turn on the debug GPU overdraw.

Tutorial on turning on developer options and Debug GPU overdraw:

Enable Developer options. Click on the Build Number multiple times.

Fig 1. Enable Developer Options**

Enable Debug GPU Overdraw.

Fig 2. Enable GPU Overdraw**

Memory Leaks

ANR - Application Not Responding

App in the foreground and is unresponsive, user will get Application Not Responding - ANR.
If not in foreground, then it's silently stopped.

Fig 3. ANR Dialog**

ANR Triggers

Usually when app can't respond to user input on main thread or UI thread.
Preventing system from processing input events from users.

Examples:

Blocking I/O operation. Such as network access
Taking time building in-memory structure
Computing something expensive in Main or UI Thread

Android will trigger ANR when:

No responses to an input event - within 5 seconds
BroadcastReceiver doesn't finish executing within 10-20 seconds

BroadcastReceiver is the one that listens for events either on app or system

Prevention of ANR

Keep the main or UI thread unblocked:

Don't perform blocking or long-running applications
Minimize any lock contention - accessing same resources at the same time
Use threads strategically - worker threads

Usually 100-200ms is the threshold for slowness in an app

References

ANRs by Developer.Android

Slow Rendering

UI rendering is an act of generating a frame from your app and displaying it on the screen.

To Achieve 60fps - frames per second, each frames must be able to be renderd under 16ms

Identify Jank - Stuttering or unsmooth motion in app's UI

Identifying jank can be difficult. Stated from Developer.Android there are 3 method for identifying jank:

Visual inspection - fast
Systrace - more detail, more data which also means more difficult to analyze
Custom performance monitoring

Profile GPU Rendering also can be used to analyze GPU rendering and we can anlyze where is the bottleneck of the application

References

Slow Rendering by Developer.Android

Understanding Activity Lifecycle on Android Apps

Theo Millard — Wed, 21 May 2025 20:11:32 +0000

In android applications, the programs and screens which users can interact are presented by activity.

Every application have at least one activity, but not limited to one.

There are several lifecycle process of activity:

All of these lifecycle of activities are having their own callback methods, to run certain functions when they are reaching certain state:

1. Create - onCreate()

Activity First Created
Initialization and basic setup of the activity
you also need to call what layout to be served to UI

2. Start - onStart()

Activity becoming visible to user
User are able to see the activity, but not yet responsive for user interaction
Preparation before becoming interactive

3. Resume - consume()

Activity starts interacting with user
For example, when you gets called when using your phone and you answer the call, after the call it will give you the resume
Captures user input, usually where the implementations of app core's functionality is done

This First 3 callback function will be created and called when open app

4. Pause - onPause()

System changed focus from the current activity
For example, when you use application and open another app, onPause() will be called.
Application still partially visible.
Indicate activity to enter either stop or resume

5. Stop - onStop()

Activity is no longer visible to user

6. Destroy - onDestroy()

Activity is destroyed
usually used for clean up

7. Restart - onRestart()

Activity is stopped and is starting again
always followed by onStart()

Reference

CI/CD Explained

Theo Millard — Sun, 18 May 2025 16:47:24 +0000

CI/CD stands for continuous integration and continuous delivery/deployment

Aimed to streamline and accelerate the SDLC (Software Development Life Cycle) to ensure faster and more reliable delivery of applications.

Importance of CI/CD ⚠️

CI/CD helps decreasing complexity, increase efficiency and streamlining workflows. CI/CD enables teams to:

Release code faster, while ensuring the quality of the applications. ⏰
Automate repetitive tasks, such as testing, building, and deployment. ✅
Reducing human errors and human intervention. 🤖
Decrease Complexity. 🧠
Increase customer satisfaction through faster feedback loop and frequent update. 🥳

CI - continuous integration

CI is a Practice of :

Integrating all your code changes into main branch early and often
Running automated builds and tests (e.g., unit tests, linting, static analysis) on every commit or pull request.

Benefits of CI:

Early detection of bug, security issue, and integration conflicts 🐞
Minimizing code integration conflict, by merging frequently 💥
Faster issues identification 💨
Verify code changes ✅

CD - Continuous Delivery/Deployment

CD can mean two things:

Continuous Delivery
Continuous Deployment

Continuous Delivery

Ensure that code is in Deployable state ✅
Automate Builds and Tests (e.g., unit tests, integration test) 🤖

Continuous Deployment

Automates release/deployment of application to production 🤖
Reduce manual process by operations 😖
Faster app delivery ⏰

Summary

CI/CD pipeline can streamline the creation, testing, and deployment of applications.
Improving quality and speeds up the delivery.

CI - Continuous Integration
- Minimizing conflicts 💥
- Detect issues faster 💨
CD - Continuous Delivery/Deployment
- Ensuring quality 👍
- Automate application's release 🤖

Benefits:

Faster release cycles 🏎️
Fewer errors and bugs 👾
Shorter feedback loops 🔄
Reduced operational workload 🏋️
Faster recovery from failures ❤️‍🩹
Higher team morale and customer satisfaction 🔥

References

Monitoring & It's 4 Golden Signals 🏆

Theo Millard — Wed, 14 May 2025 15:45:44 +0000

Monitoring is a critical part of SRE practices to manage and ensure systems and services reliability. 4 Golden Signals is key metrics that used to monitor the health of your service and underlying systems effectively.

Monitoring

Monitoring is the process of collecting, processing, aggregating, and displaying real-time quantitative data about a system.
This allows engineers to understand system behavior, detect anomalies, and make informed decisions based on metrics.

Here are few benefits of doing monitoring:

1. Analyzing Long-Term Trends 📈📉

This historical data supports better technical and business decision-making.

Monitoring helps track the growth and usage patterns of applications over time. You can observe metrics like database size or daily active user count.

2. Alerting 🚨‼️

Monitoring enables the system to notify you when something is broken or about to break.

When the system can't self-heal, alerts help engineers investigate the issue, determine the root cause, and take corrective action immediately.

3. Conducting Ad Hoc Retrospective Analysis ⏰📊

Monitoring provides a trail of metrics that can be analyzed after an incident.

For example, if your system experiences a spike in latency, you can correlate this with other metrics collected at that time to debug and find the root cause.

The Four Golden Signals - ⭐️⭐️⭐️⭐️

Foundational building blocks of an effective monitoring strategy. They cover the most essential aspects of system health and performance. Focusing on these core signals helps minimize noise and reduce maintenance overhead.

1. Latency — Request Service Time ⏱️⏳

The time it takes for a system to respond to a request. High latency can directly affect user experience and cause business downfall. It’s critical to monitor both successful and failed request latencies.

By applying monitoring on these metrics, high latency can be alerted and take actions before user's complains

2. Traffic — User Demand 📈📉

Represents the volume of demand on your system, typically measured in requests per second (RPS), transactions per second (TPS), or similar.

Monitoring traffic can helps anticipate scaling needs and detect abnormal usage patterns

3. Errors — Rate of Failed Requests ⚠️‼️

Measures the number of requests that fail either explicitly (e.g., HTTP 500 errors) or implicitly (e.g., timeouts or incorrect responses).

Monitor high error rate can helps indicating abnormalities and wrong in the systems

4. Saturation — System Capacity 💽💾

Indicates how "full" your system is. This can refer to CPU, memory, I/O usage, or any resource that might become a bottleneck.

Saturation metrics help predict and prevent outages caused by overutilization.

By focusing on these golden signals - you gain critical visibility for your system's health and performance.

References

YAGNI - Software Engineering Principle 🖥️

Theo Millard — Sun, 04 May 2025 09:23:52 +0000

YAGNI stands for "You Aren't Gonna Need It". This principle focuses on delivering software with limited time and resources. Focusing on delivering value.

It adheres to simplicity and avoids unnecessary complexity. It encourages developers to focus on delivering the simplest solution that meets current requirements, instead of trying to assume future needs.

Why YAGNI? What Problem Does This Principle Solve?

Deadline for requirements not achieved ⏰
Unused feature or code 😓
Bloated and Complex code 🤯

These problems often comes from assumptions and predictions, that never even needed or happened.

Cost of the Problems

1. Cost of building 🧑‍💻

Time, effort, and resources
Includes everything from planning to coding and testing

2. Cost of delays ⏰

Missed opportunities to deliver features faster or create economic impact

3. Cost of carry 🧳

Carrying unnecessary complexity results in extra difficulty and extra work in adding other features
Bloated and Complex code that is harder to maintain and not adaptable to evolve
Unpredictable bugs due to complexity of the code

4. Cost of repair 🔧

Fixing mistakes, bugs, or poor choices
Re-adjusting features that weren’t needed in the first place

How to Implement

1. Prioritization and limiting scope 🔎

Decide what to build and what not to build
Focus on the importance of each feature

2. Not assuming and predicting future needs 🧙‍♂️

Can lead to unnecessary functionality and increased code complexity
Often results in wasted effort

3. Create simple and minimal codebases 👾

Easily adaptable to future changes
Easy to respond to evolving requirements
Reduces potential risk of bugs
Easier to understand and maintain
Less unused code
Free of assumptions and predictions

4. Know when to refactor 🧹

Refactoring can simplify your code, making it easier to understand and maintain

// Without YAGNI principles
type User struct {
    Name           string
    PreferredTheme string // Not needed yet
}

func renderUserProfile(user User) {
    if PreferredTheme == "Dark" {
        fmt.Println("Applying dark theme...") // Not required now
    }
    fmt.Println("Name:", user.Name)
}

// With YAGNI principles
type User struct {
    Name           string
}

func renderUserProfile(user User) {
    fmt.Println("Name:", user.Name)
}

The Don'ts 🚫

1. Don't become a Sloppy developer 🏖️

Writes unmaintainable code
Neglects necessary refactoring

2. Too focused only on requirements and functionality 🤓

We, as programmers, need to be able to see the broader context
Also consider code quality, maintainability, and long-term adaptability

Summary 📖

YAGNI is a powerful principle that keeps your codebase lean, adaptable, and focused on real-world needs. By resisting the temptation to build speculative features, teams can ship faster, reduce bugs, and save time and resources.

Why I Love Aerospace: A Tiling Window Manager in macOS

Theo Millard — Thu, 24 Apr 2025 17:15:06 +0000

Disclaimer ⚠️

I believe my experience also can be applied on any other tiling window manager and not unique to aerospace. I only share my opinion and experience.

Background

I come from GNOME setup. Configuring some keyboard shortcuts and some settings are just enough for me without needing to switch to window manager.

window+arrow or window+h/j/k/l for resizing window
ctrl+alt+left/right or alt+h/l to switch to next or prev workspace
alt+number to switch to numbered workspace.

MacOS 😕

However when I first switch to macOS, I believe macOS does not really built for keyboard-heavy workflows out of the box. I couldn't easily snap windows side-by-side and felt really mouse or trackpad dependent. I understand I am new to macOS, I might miss something or it is just a problem on my side, but I couldn't even drag windows to corners to resize. fullscreen mode also sometimes confusing.

Still, I am willing to learn the OS properly, So I am going to youtube and going to search tutorial in using macOS. However this video came up. This video explains a little bit about Aerospace functionality and configuration. ....It really catch my attention 🔥.

Aerospace

It's been a week using Aerospace and already loving it. I believe I only need 1-2 days to adapt while configuring everything. Since macOS allows remapping modifier keys, I also configure them to match my needs.

⏱️ No wasting time managing, resizing, and dragging windows
⌨️ Less dependent on trackpad gestures, which forces you to gesture after writing few lines of code.
⚡ Faster switch between application - by using single key tap
💡 Minimal configuration and already intuitive keybinding
🤖 Automation for managing app/workspace - I always want my terminal to be on workspace 1 or workspace labeled 'T'

To make things clear, switching to a window manager is always been my bucket list for a long time and however I am afraid that configuration and adaptation will takes some time, however due to intuitive-out of the box functionality and great documentation by Aerospace convinced me to try it and never really look back.