DEV Community: Jackline Kaunda

How to Install Homebrew on Ubuntu (Step-by-Step Guide)

Jackline Kaunda — Tue, 17 Mar 2026 20:16:30 +0000

TL;DR

Install Homebrew on Ubuntu in these steps:

sudo apt-get install build-essential procps curl file git

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

echo >> /home/pc/.bashrc
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)"' >> /home/pc/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)"

Then verify:

brew doctor

If you see:

Your system is ready to brew.

You’re all set.

Introduction

If you have used macOS before, you’ve probably come across brew (Homebrew). It’s a simple and powerful package manager that makes installing developer tools much easier.

I previously used brew on macOS and really liked the experience, so I decided to try it on Ubuntu as well. My goal was to use both Homebrew and the native Ubuntu package manager apt in my development.

In this guide, I’ll walk through how to install Homebrew on Ubuntu.

Throughout this installation, we’ll reference the official Homebrew documentation:

GitHub Repository

Official Website

Let’s get started.

1: Install the prerequisite packages

Homebrew requires a few system packages before installation.
Run the following command in your terminal:

sudo apt-get install build-essential procps curl file git

These packages provide the basic tools needed to compile and manage software.

You can find the full requirements in the official guide:
https://docs.brew.sh/Homebrew-on-Linux#requirements

Step 2: Run the Homebrew installation script

Next, run the official Homebrew installation script:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

The script will:

Show the packages that will be installed
Display the directories that will be created
Pause and ask whether you want to continue

At this point, press Enter/Return to continue the installation.

The installation will proceed automatically, and once it finishes, the terminal will display the next steps required to configure Homebrew.

Step 3: Configure Homebrew after installation

After installation, Homebrew needs to be added to your shell environment.

Add Homebrew to your PATH
If you are using bash, run:

echo >> /home/pc/.bashrc
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)"' >> /home/pc/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv bash)"

If you are using zsh, add the same command to ~/.zshrc.

Test the installation

To confirm everything is working, run:

brew doctor

If everything is set up correctly, you should see:

Your system is ready to brew.

Possible errors

You might encounter an error like this:

/home/pc/.linuxbrew/Library/brew.sh: line 177: exec: : not found

This usually indicates a missing dependency, often Ruby.

First, check whether Ruby is installed:

which -a ruby

If Ruby is missing, install it with:

sudo apt-get install ruby

Alternatively, you can install all common Homebrew dependencies with:

sudo apt-get install build-essential curl git m4 ruby texinfo libbz2-dev libcurl4-openssl-dev libexpat-dev libncurses-dev zlib1g

👩‍💻 Phoenix LiveView: Bringing Real-Time Magic to the Web

Jackline Kaunda — Wed, 19 Nov 2025 08:38:39 +0000

A Blog Post Based on the ElixirKenya Webinar #001 by Jackline Kaunda

Introduction

Phoenix LiveView has been around for some time, but it was officially announced last year (2019) by Chris McCord. Many of us have already used it to do amazing stuff, moving much of our client-side work, which we initially used to do in GitHub versions, into a finalized, published dependency.

What is Phoenix LiveView?

Phoenix LiveView is a powerful library that provides rich, real-time user experiences with server-rendered HTML.

For a long time, building rich, real-time interfaces meant relying heavily on JavaScript frameworks like React, Angular, or Vue.js. These are majorly client-side architectures. However, LiveView proposes that it might be wiser and simpler to handle this on the server side.

Here are the key takeaways:

Server-Side State: LiveView is stateful in the server. This is the core difference.
Bi-directional Communication: It achieves interactivity using WebSockets for bi-directional communication between the client and the server.
Minimal JavaScript: As Chris McCord said, LiveView enables you to write your UI code without really having to write JavaScript code. While the framework is built on top of JavaScript (for managing the WebSocket connection and DOM updates), the JavaScript you, the application developer, write is minimal.

This means you, as an Elixir developer, do not have to learn all the current trending JavaScript frameworks. Instead, you just have to focus on your Elixir code to make good, real-time applications, maximizing your time and resources.

🧱 The Pillars of LiveView

LiveView is built on three core systems that were already part of the Phoenix Framework:

1. Phoenix Channels

Channels have been a foundational system since the beginning of Phoenix. They use WebSockets to ensure bi-directional communication between the client (like a browser) and the server.

A key challenge that channels help solve is connection density. The beauty of Channels is that they leverage the BEAM (Erlang VM) to allow so many connections on the same node without the application crashing. This makes real-time communication robust and scalable.

2. LiveView Templates (LEx)

LiveView uses the LEx (Live EEx) template engine, which was created to achieve two main goals:

Initial Rendering: To render the template initially.
Diff Tracking: To track differences in the content of an HTML page.

When LEx renders your template to the browser, it splits the resulting HTML into two parts:

Static Part: Content that will never change (e.g., HTML tags).
Dynamic Part: Content that changes with time (e.g., a variable assigned to a time value).

This split is essential for efficient updates. LEx calculates the minimal difference—the "diff"—between the old and new dynamic content, optimizing the payload sent over the WebSocket.

3. JavaScript

While we write minimal JS, a file called phoenix_live_view.js contains all the necessary scripts for LiveView to manage the connection and attain the rich user experience. It plays a major part in handling the client-server communication.

🚀 The LiveView Lifecycle: From Stateless to Stateful

The life cycle of a LiveView begins with a two-step process:

1. Initial Stateless HTTP Request (Mount to the DOM)

When you first load a LiveView page (e.g., navigating to /messenger):

A GET request is sent to the server.
The server calls the mount function, which gets all the data needed (e.g., from a database or API) and puts it into the assigns of the socket.
The data is passed to the render function, which sends back a full HTML response to the client.

This first step ensures a fast, SEO-friendly initial page load.

2. Stateful WebSocket Connection

After the HTML is rendered:

The client uses a small piece of JavaScript code to connect to the server via a WebSocket.
The server then spawns a new Phoenix LiveView Process for that connection.
This process calls the mount function again (this time, the stateful version), gets the data, and passes it to the render function.

From this point on, the connection is stateful.

How Updates Happen

When an event is triggered (a click, a keypress, etc.):

The message is sent over the WebSocket to the LiveView process.
The server calls the appropriate handle_event callback.
The server updates the socket assigns (@changes).
The server renders the new template and calculates the minimal diff (using LEx).
This small patch is sent back to the client.
The client uses morphdom.js (a lightweight library) to patch the existing DOM, not a virtual DOM.

This is how LiveView maintains its own state throughout the session and updates the UI in real-time efficiently.

Demo: A Real-Time To-Do Application

In a short demo, we saw a simple to-do application built with LiveView. The power was immediately visible:

When typing in a new to-do item, the list of to-dos updated immediately below the input field, demonstrating the real-time feedback loop.

By inspecting the WebSocket traffic, we saw the transparency of LiveView:

The event was triggered.
The message included the topic (lv:*subtopic*) and the actual content typed.
The server sent back an updated render event, complete with the list of to-dos updated in the socket assigns.

This shows that with very few lines of code, you can achieve powerful, real-time interactivity.

Conclusion

Phoenix LiveView is a game-changer. It enables Elixir developers to build highly interactive, real-time web applications without the overhead and complexity of traditional client-side frameworks. By leveraging Channels, LEx, and the power of the BEAM, LiveView offers an incredibly efficient and developer-friendly path to modern web development.

Things I Wish I Knew Before Getting Into Tech

Jackline Kaunda — Sun, 21 Sep 2025 16:47:21 +0000

Getting into tech is thrilling, but the reality often comes with surprises no one warns you about. I recently had the chance to share my journey, the lessons I’ve learned, the missteps along the way, and the things I wish I knew earlier. It was an empowering space to connect, reflect, and grow alongside other incredible women in tech

Here are the twelve key insights I shared in my talk.

You Will Fail ... A Lot
The first thing you have to accept in tech is that you will encounter failure. Those red error messages aren't a reflection of your ability; they are a fundamental part of the development process. Learning to see these failures as puzzles to be solved will build your resilience and make you a much stronger problem-solver.
Tech is a Journey of Continuous Learning
The tech landscape is in constant motion. New technologies like AI and prompt engineering emerge, and the tools you use today will continuously evolve. A commitment to lifelong learning isn't just a good idea, it's essential for survival. It can be challenging, but it’s also what keeps this field so exciting.
Not All Solutions Solve a Problem
It’s incredibly easy to get swept up in the thrill of building something new. But our purpose is to add value, not complexity. I've seen teams pour resources into features no one uses or optimizations that don't matter. Before you build, always ask why. Collaborate closely with your team and focus on the real needs of the user. Just because you can make it, doesn’t mean you should.
Documentation is Your Best Friend
While AI assistants and Stack Overflow have their place, your first stop for answers should always be the official documentation. It’s written by the people who built the tool, it's always the most up-to-date, and it covers crucial edge cases you won't find anywhere else. Make it a habit, not an afterthought.
You Don’t Need to Know Everything
No one has all the answers, not even senior engineers, who, I promise you, do research like googling things every single day. What’s more important than knowing everything is having a growth mindset. Cultivate your curiosity, become resourceful in finding answers, and stay consistent in your efforts to learn and improve.
Your Career Path Wont Be a Straight Line
It’s okay if your path doesn’t follow the traditional roadmap. It's common to start in one specialty and discover a passion for another. We see developers become Solutions Architects, QA Engineers move into DevOps, and Data Analysts transition into AI. Embrace the journey, it can take you to exciting and unexpected places.
Please, Let's Stop Over-engineering
Engineering should solve real problems, not imaginary future ones. Don't build a system for 10 million users when you only have 10. Avoid adding unnecessary complexity in the name of future-proofing. Solve the problem at hand with the simplest, most effective solution.

Make it work. Make it right. Then make it fast. - Kent Beck
You Are Your Own Biggest Advocate
No one can tell your story better than you. Make your work visible. Do not assume your hard work will speak for itself. You must be proactive in communicating your accomplishments and advocating for your career growth. Schedule regular check-ins with your manager to get feedback and meticulously track your achievements. I highly recommend keeping a brag document, a concept I learned from Julia Evans, to record your successes. It's an invaluable tool for performance reviews and promotion discussions.

💡 Check out Julia Evans’ blog on brag documents
Company Culture Truly Matters
The environment you work in has a direct impact on your mental health, career growth, and job satisfaction. A negative culture where blame is common and people fear asking questions will lead to burnout and stifle your potential. When you're interviewing, always ask about the culture. Ask how the team handles failure, how junior developers are supported, and what growth looks like there.
Work-Life Balance Isn't a Luxury, It's a Necessity
Hustle culture is a recipe for burnout. To build a sustainable and joyful career, you must set clear boundaries. This means defining your work hours, actually using your vacation days, and scheduling time for your life outside of tech. My most practical tip? Keep work email and Slack off your personal phone.
Be Intentional About Your Career Progression
Take active ownership of your career path. Think about what your next role is and what you need to do to get there. Work with your manager to create a timeline and identify the small, focused steps to achieve your goals. And remember, you don't have to do it alone. Find mentors who can offer guidance along the way.
Coding is Only Part of the Job
Writing code is a core skill, but it's far from the only one. To truly excel, you must also master:

Problem-solving: Understanding the business logic and user needs behind the code.
Communication: Clearly explaining complex ideas to both technical and non-technical colleagues.
Collaboration: Working effectively with designers, QA engineers, and product managers.
Reading and Maintaining Code: Understanding and improving upon the work of others is just as vital as writing your own