DEV Community: naibei caleb

How to Publishing and Embedding Power BI Reports on the Web with IFrames

naibei caleb — Mon, 06 Apr 2026 00:30:50 +0000

Introduction

After a succesfull cleaning, analysing and making of report in Power BI, the next step to some Users Is to Embed it to a website or a blog.
In this guide I will walk you through how I :

Created working space in Power BI.
Upload and Published Report
Generate and Embeded Code With IFrame

IFrames involves generating a shareable link or code from the Power BI service and placing that code into the HTML of your website.

Step 1: Creating a Workspace in Power BI Service

A workspace is used to store and manage reports, dashboards, and datasets.

Follow these steps:

Go to Power BI Service: https://app.powerbi.com
Sign in with your account
From the left panel, select Workspaces
Click New Workspace
Enter a name (e.g., Electronics Sales Workspace) Click Save

Step 2: Upload and Publish the Report

After the workspace is created, upload your Power BI report file.

Steps On Power BI:

Click Publish
Select your workspace

Step 3: Understand Embedding Options

Power BI provides two main ways to embed reports:

1. Publish to Web (Public Embed)

Accessible without login
Suitable for public dashboards
Generates a public link

2. Secure Embed

Requires authentication
Suitable for private or organizational use
Keeps data protected

If “Publish to Web” is disabled, use Secure Embed.

After Selecting The Prefered one You Proceed to embed the report, generate an iframe code from Power BI.

Steps:

Open your report in Power BI Service
Click File then Embed report then Website or portal
Copy the generated IFrame code

Step 4: Embed the Report in an HTML Page

Create an HTML file and paste the embed code inside it.

HTML page displaying the dashboard

Here are Common Issues You Might Come Accross and Solutions

Issue 1: Report Not Displaying

Cause: Using a secure embed link without authentication
Solution: Log in or use “Publish to Web” if available

Issue 2: Map Visual Not Working

Cause: Map visuals disabled in settings
Solution:

Go to File then Options then Global then Security
Enable map visuals

Issue 3: Incorrect Calculations

Cause: Improper DAX or data modeling
Solution: Use row-level calculations

Issue 4: Slicers Not Working

Cause: Using fields from the fact table
Solution: Use dimension tables (e.g., Customers, Products)

Best Practices

Use a star schema for data modeling
Create measures using DAX instead of raw columns
Use consistent naming for visuals
Keep the dashboard layout clean and aligned
Use slicers from dimension tables only

Conclusion

Power BI reports Can Be Published and Embeded in Websites using IFrame while following the above steps.

Understanding all the stapes and possible solutions for issues that you might come accross Helps in Smooth Implementation.

Linux Fundamentals Every Beginner Data Engineer Should Know

naibei caleb — Tue, 31 Mar 2026 19:59:39 +0000

Intoduction

In this post, I'm going to share with you on how I handled my first Data Engineering assignment.
It covers important Linux fundamentals that every beginner Data Engineer should know. These included navigating directories, creating files and folders, performing file operations, managing permissions, and reviewing command history.

nothing complex, just a beginner's work

What is Linux?

Linux is a free, open-source operating system (OS) based on Unix, designed for stability, security, and flexibility

click the thumbnail to open a youtube video for more info about linux

Why Linux important to Data Engineer

Data Engineers often work with remote servers, cloud virtual machines, ETL pipelines, and automation scripts. Linux provides the environment where many of these tools and processes run efficiently.

Understanding Linux helps in:

Managing files and directories
Running scripts and automation tasks
Working with remote servers
Organizing datasets
Securing data files with permissions

Here is how I performed the assignment covering key Linux fundamentals

I learned how to navigate directories, create files/folders, perform file operations, manage permissions, and review command history.

Login Verification

First, I logged into the Ubuntu server to confirm I could access my assigned account. The screenshot below shows a successful login and my current working directory

I used the following commands
root is the username
143.110.224.135 is the server IP address
-p 22 specifies the SSH port
whoami username of the currently logged-in user(it's screenshot found in the pdf folder at the end)
pwd I used it to shows the exact directory I was currently working in (it's screenshot found in the pdf folder at the end)

Folder & File Structure

After logging in, I created my main project directory using my name, and added subfolders for raw_data, processed_data, logs, and scripts.

Using mkdir I created "Caleb_data_engineering" as my folder name and mkdir raw_data processed_data logs scripts to create Subfolders

The screenshot below shows the directory structure using the ls -R command, I used it to list all files and folders I had created

The Subfolder Created stored:
raw_data stores original data
processed_data stores cleaned/modified data
logs stores log files
scripts stores shell scripts

nano I used it to open and edit files directly from the command line.(terminal-based text editor)

Raw and Processed Data Files

I created sample CSV files to simulate real data: stock_data.csv in raw_data and cleaned_stock_data.csv in processed_data.

These screenshots show the contents of each file.

raw data

processed data

Scripts and Logs

I also created a simple script and a log file to track operations.
This screenshot shows the process_stock.sh script and the corresponding log file in action.

I used command touch create empty files in each subfolder

Permissions and Navigation

To practice Linux permissions, I restricted access to my main folder and made the script executable.
I also practiced navigating directories and listing hidden files.

At the end, I ran the history command to review all the commands I had executed during the assignment. As shown in the screenshot below

More commands Used in my assignment

For file operations, I used cp to create a backup file, mv to move and rename files, and rm to delete unnecessary files and keep the workspace organized.

For permissions, I used chmod to control access to my files and folders:

chmod 700 ~/Caleb_data_engineering was used to restrict access to my main project folder so that only the owner could access it.
In Linux permission terms, 700 means:
7 = read, write, and execute for the owner
0 = no access for group
0 = no access for others
chmod 600 was used on important files such as the raw data file, cleaned data file, and log file.
This ensures that only the owner can read and write the file.
In this case:
6 = read and write for the owner
0 = no access for group
0 = no access for others

I also used chmod +x to make my shell script executable, allowing it to run directly from the terminal.

To confirm that the permission changes were applied correctly, I used ls -l, which displays file permissions and ownership details.

I then ran ./process_stock.sh to execute my script, ls -la to list all files including hidden ones, and !! to re-run the previous command.

Supporting Evidence

To keep this article concise, I placed the full assignment screenshots in a separate PDF document hosted on GitHub.
Caleb_data_engineering_assignment_screenshot.pdf

Conclusion

This assignment gave me practical exposure to essential Linux fundamentals for beginner Data Engineers.

By creating and organizing files, performing file operations, managing permissions, navigating directories, and reviewing command history, I strengthened my confidence in using the Linux terminal.

Mastering these basic skills is an important first step toward efficiently managing data workflows on remote servers.

Understanding Data Modeling in Power BI: Joins, Relationships, and Schemas Explained.

naibei caleb — Tue, 31 Mar 2026 18:59:29 +0000

1. Introduction

Over the past few days at LuxDevHQ, I’ve been learning Power BI as part of my data engineering journey. In class, we covered how data flows at a high level—but I kept feeling like I understood it… without really understanding it.

So I decided to slow down and build a model myself from scratch.

That’s when I realized something:

Data modeling isn’t just a step—it’s the part that decides whether everything else works or breaks.

This article isn’t a perfect guide. It’s more of a reflection of what started making sense to me after actually trying, failing, and fixing things.

2. Shaping Data

What Joins Actually Mean to Me Now

At first, joins just felt like definitions I had to memorize. But when I started using them in Power Query, they became more practical.

When I use Merge Queries, I’m basically deciding:

“Which data do I trust enough to keep?”

INNER JOIN

I use this when I only want “clean matches.”

When I tried this on my Sales and Product tables, I noticed something:

Some sales just disappeared.

At first, I thought I broke something—but then it hit me:

Those records didn’t have matching Product IDs.

So INNER JOIN isn’t just merging—it’s also filtering out bad or incomplete data.

Visualizing how INNER JOIN only keeps matching records between tables.

LEFT OUTER JOIN (My Default)

This is the one I keep coming back to.

It lets me say:

“Keep everything I started with, and just add what matches.”

When I used this with Customers and Orders, I could still see customers who never bought anything—which actually felt important.

LEFT ANTI JOIN (Unexpected Favorite)

I didn’t expect to like this one, but it turned out to be super useful.

It shows what’s missing.

That helped me find:

Products that were never sold
Records that didn’t match anything

It felt less like analysis and more like debugging my data.

3. Relationships: The Part That Confused Me Most

Joins made sense after a while—but relationships took longer.

At first, I kept thinking:

“Didn’t I already combine these tables?”

But then I realized:

Relationships don’t combine data—they control how tables talk to each other.

That shift in thinking helped a lot.

One-to-Many (1:M)

This is the structure I now try to aim for.

One Product → Many Sales

Simple in theory—but I ran into problems when my data didn’t behave that way.

That’s when I learned:

If this isn’t clean, everything downstream starts acting weird.

Filter Direction (A Small Setting That Caused Big Problems)

I once left cross-filtering on Both… and my visuals started giving confusing results.

Now I stick to:

Dimension → Fact

It just feels more predictable and easier to reason about.

Active vs Inactive Relationships

This one only clicked when I had two date columns.

I remember thinking:

“Why is Power BI ignoring one of my dates?”

Turns out—it wasn’t ignoring it. It just needed me to explicitly choose when to use it.

The solid line shows the active relationship. The dotted line is inactive—this is why one of my dates wasn’t working until I explicitly used it.

4. Fact vs Dimension: How I Simplified It in My Head

To avoid overthinking, I started labeling tables like this:

Facts = what happened
Dimensions = details about what happened

That made things clearer.

Sales table? → Fact

Product table? → Dimension

Once I saw it that way, structuring the model became less confusing.

5. Star Schema: The Structure That Finally Made Things Easier

I tried different ways of organizing tables—but the one that consistently worked was the Star Schema.

It just felt… cleaner.

One central table (Sales), surrounded by supporting tables (Product, Customer, Date).

When I used this:

My relationships made more sense
My calculations became easier
My model looked less chaotic

Snowflake Schema (Looked Nice, Felt Complicated)

Breaking dimensions into smaller tables looked organized at first.

But when I actually used it, I kept losing track of how everything connected.

It felt like too many steps just to answer a simple question.

Compared to a star schema, this felt more complex and harder to follow when I was building my model.

Flat Table (Learned This the Hard Way)

I tried putting everything into one big table.

At first, it seemed easier—no relationships to worry about.

But then:

The file got heavy
Everything slowed down
It became harder to manage

That experiment alone convinced me why structure matters.

6. Mistakes That Taught Me the Most

This is probably where I learned the most.

Many-to-Many Problem

My numbers didn’t make sense. Totals were too high.

This kind of relationship caused my totals to be incorrect because values were being counted multiple times.

I didn’t understand why—until I realized:

I had duplicates on both sides.

Fixing it with a bridge table felt like unlocking something.

Circular Relationships

At one point, my filters were looping—and I didn’t even notice at first.

The model looked fine, but results were off.

Fixing the direction of filters made everything clearer.

Multiple Dates (This One Was Subtle)

Having Order Date and Ship Date in the same table confused me.

Connecting both to the same Date table felt right—but only one worked at a time.

Learning about inactive relationships helped me finally understand why.

7. What I’m Taking Away From This

If there’s one thing this experience taught me, it’s this:

A dashboard isn’t powerful because of visuals—it’s powerful because of the model behind it.

Right now, my approach is simple:

Clean data in Power Query
Keep relationships clear and structured
Stick to a Star Schema whenever possible

Final Thought

I’m still learning—but this process made one thing clear:

Data modeling is less about memorizing concepts and more about understanding how data behaves.

And honestly, most of what I’ve learned so far didn’t come from getting it right—it came from fixing what I got wrong.

How to Set Up a GitHub Profile README Using Markdown (Beginner Guide)

naibei caleb — Sat, 28 Mar 2026 12:08:03 +0000

Introduction

If you're starting out as a data engineer or developer, having a well-structured GitHub profile is a great way to showcase your work.

In this guide, I’ll walk through how to create a GitHub profile README using Markdown—step by step.

📌 What Is a GitHub Profile README?

A GitHub profile README is a special repository that displays information about you at the top of your GitHub profile.

It helps you:

Introduce yourself
Showcase your skills
Highlight your projects

⚙️ Step 1: Create a Special Repository

Go to GitHub and:

Click New Repository
Set the repository name exactly as your username
Make it Public
Check “Add a README file”

👉 Important: GitHub only shows the README if the repo name matches your username.

✍️ Step 2: Edit Your README Using Markdown

Click on your 'README.md' file and start editing.

Markdown is a simple way to format text using symbols.

🧱 Basic Markdown Syntax

Headings

List

Link

👨‍💻 Example Profile README
Here’s a simple template you can use:

Here’s a simple template you can use:

After editing:

Scroll down
Click Commit changes

Your profile will automatically update.

🔥 Tips for a Better Profile

Keep it clean and simple
Update it as you learn
Add projects regularly
Don’t try to be perfect—just be consistent

✅ Conclusion

Setting up a GitHub profile README is one of the easiest ways to start building your online presence as a developer.

As a beginner, even a simple profile can make a big difference.