No big success story here. No job, no internship, no client work. Just what I have learned, what I studied recently, and what I plan to do next.

What I know right now

My toolbox is small and I would rather list it plainly:

• Python
• C++
• HTML and CSS
• Microsoft Excel

That is it. I am not going to pad the list with tools I have only heard of.

Four different ways of thinking

Each of these taught me something different, even though I am still early in all of them.

Python reads close to plain English, so you spend more time on the problem than on the syntax. It also has Pandas for data work and Streamlit for quick web apps, which turned out to matter a lot (more on that below).

C++ is stricter. You have to think about types and how things are stored. It feels slower to write at first, but it makes you more careful. If you are deciding between the two, I have a separate post on that: Python vs C++: What Should a College Student Learn First?.

HTML and CSS are not programming languages in the usual sense, but they teach you something the others do not. You write a few lines and see a result in the browser right away. That quick feedback is useful when you are learning.

Excel is easy to underrate. In my assignments I work with formulas, where you change an input and every dependent calculation updates by itself. That idea, a result that follows from inputs, shows up everywhere in programming too. Dashboards are basically that idea with nicer visuals. I wrote about the practical side here: Microsoft Excel for Data Analysis: Useful Formulas and Practical Examples.

The gap between learning and building

Here is the honest part. Knowing a language and building something with it are two separate skills.

When you learn syntax, every exercise is small and the answer is known. A real project is different. You have to decide how to load data, how to clean it, how to organise files, and how to show the result. Nobody gives you the steps in order.

So before attempting a project of my own, I wanted to see what a finished one looks like on the inside.

Studying a real project

So I picked a finished open-source project and went through it properly: a Sales Analytics Dashboard built with Python, Pandas and Streamlit. It was created by Asha Kalavagunta, not by me. Her original repo is at github.com/Ashakalavagunta/sales-analytics-dashboard. I keep a copy on my own GitHub so I can read and run it.

I want to be clear about that. Credit matters, and I would rather say "I studied this" than pretend it is mine.

What did reading it teach me? A few things I could not easily get from short exercises:

• Separate your concerns. The cleaning script and the app are different files. The ETL script cleans the data once, and the app only worries about showing it.
• Check your own data. The ETL script ends with assert checks, for example that sales are positive and there are no duplicate rows. I had not thought of doing that before.
• One filtered DataFrame can drive everything. Six sidebar filters feed a single mask, and every KPI and chart reads from the result.
• Cache expensive work. Streamlit reruns the script on every click, so loading data needs caching.

I wrote up the full walkthrough here: What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas). If you want the Pandas basics behind it, start with Pandas for Beginners: Cleaning and Analysing Real-World Data.

Why I am not stopping at studying

Reading code teaches you a lot, but it is a passive skill. I can follow a groupby when someone else wrote it. Writing one from a blank file, with my own question and my own messy dataset, is harder, and that is exactly why it is worth doing.

I also think there is a line between learning from a project and presenting it as your own work. For a portfolio, that line matters. A repo that is clearly yours, even if it is simple, says more than a polished project you did not write. I go into this in How College Students Can Build a Strong GitHub Portfolio.

What I plan to do next

Nothing fancy, and nothing promised with dates:

1. Build my own project. Probably something in Python with a dataset I pick myself, using what I learned from studying Asha's work.
2. Try the things I would change. While reading the dashboard, I noted a few experiments, like computing insight text from the data instead of typing it in, and splitting one big script into smaller files.
3. Use GitHub properly. A clear README, a clean structure, and commits that make sense. Git and GitHub for College Students: From Local Project to GitHub Repository
4. Look at certifications. I am interested in free, verifiable ones from providers like AWS, Google, Microsoft and Cisco. I have not completed any yet, so I will not claim any. If I finish one, I will say so here with proof.

If you are in the same place

If you are a student who has learned some syntax and feels stuck before the project stage, here is what I would suggest, based on what I am doing myself:

• Pick one finished project and read it slowly. Run it. Change one thing and see what breaks.
• Give credit to whoever wrote it, in your notes and in anything you publish.
• Start your own small project soon, even if it feels too simple.

That is the whole plan. It is not impressive yet, but it is real.

I will keep posting as I go. You can follow my work on GitHub at github.com/Pranaav717, and follow this blog for the next posts. If you have built something small as a student, I would like to hear what you made first.

A portfolio does not need to be big. It needs to be clear. Here is what I think makes a student profile worth opening, and one lesson I took from studying someone else's project.

Why GitHub counts as a portfolio

You are a student, so you probably do not have work experience to list. Your repos fill that gap. They show that you can finish something, explain it, and put it where others can run it.

I am not saying a profile gets you a job. I am saying it gives someone something concrete to look at instead of just a line on a resume.

Pick projects that solve something

Tutorials teach you tools. Projects show you can use them. Some ideas that are small enough for a college semester:

• A tracker for something you actually use. Expenses, attendance, gym log, study hours.
• A data project on a public dataset. Clean it with Pandas, answer a few questions, show charts.
• A small web page or tool. A unit converter, a quiz app, a timetable generator.
• A script that saves you time. Renaming files, merging Excel sheets, scraping a notice board (check the site's rules first).
• A C++ or Python version of a classic. A bank system, a library manager. Fine for fundamentals, but add something of your own so it is not identical to every other one.

Rules of thumb:

1. Choose something you can finish in a few weeks.
2. Choose something you can explain in two sentences.
3. Prefer one finished project over five half-done ones.

If you are unsure where to start, How to Build an Interactive Dashboard Using Python and Streamlit builds a small interactive dashboard step by step.

Keep each repo tidy

A messy repo hides good work. Here is a simple layout for a small Python project:

expense-tracker/
├── README.md
├── requirements.txt
├── .gitignore
├── app.py
├── src/
│   ├── __init__.py
│   └── tracker.py
├── data/
│   └── sample_expenses.csv
└── screenshots/
    ├── home.png
    └── report.png

What each piece is for:

• README.md is the front page of your repo.
• requirements.txt lists the libraries so others can install them.
• .gitignore keeps junk like __pycache__/ and .env out. See Git and GitHub for College Students: From Local Project to GitHub Repository for the basics.
• data/ holds a small sample file, not a huge private dataset.
• screenshots/ holds the images your README shows.

Name repos in plain words: expense-tracker, not project_final_v2. Fill in the one-line description box on GitHub too. It shows up in search and on your profile.

Write a README people can use

The README is the part most visitors read, and often the only part. Assume the reader is in a hurry and has never seen your project.

Include:

1. What it is, in one or two sentences.
2. A screenshot or GIF.
3. Features, as a short list. Only list what actually works.
4. Tech used.
5. How to install and run it. Commands they can copy.
6. What you would improve. Honest and short.
7. Credits and licence, if you used anyone's code or data.

Here is an example you can copy and adapt. The project name and features are made up for illustration.

# Expense Tracker

A small command-line and Streamlit app to log daily expenses and see
monthly totals by category.

![Home screen](screenshots/home.png)

## Features
- Add, edit and delete expenses
- Monthly total per category
- Export to CSV

## Tech
Python 3.10, Pandas, Streamlit

## Run it locally
```bash
git clone https://github.com/your-username/expense-tracker.git
cd expense-tracker
python -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install -r requirements.txt
streamlit run app.py
```

## Sample data
`data/sample_expenses.csv` has 50 made-up rows so you can try it.

## What I would improve
- Add tests
- Support multiple currencies

## Credits
Category icons from [source]. Dataset structure inspired by [link].

Test your install steps on a clean folder, or ask a friend to try them. If the steps fail on someone else's laptop, the project looks broken however good the code is.

Screenshots do a lot of work

Most people will not clone your repo to see what it does. A screenshot answers that in two seconds.

• Take screenshots at normal window size, with sample data (never real personal data).
• Save them in a screenshots/ folder and link them with relative paths.
• For apps with several pages, show two or three of the best, not twelve.
• A short GIF of the main action is even better. Free tools like ScreenToGif (Windows) or Peek (Linux) can record one.

Host it if you can

A live link beats a screenshot. If your project is a web page, GitHub Pages is free. If it is a Streamlit app, Streamlit Community Cloud can run it from your repo. How to Deploy a Python Streamlit Project Online (Free, Step by Step) walks through that.

Put the live link near the top of the README. If a project cannot be hosted, like a desktop or C++ program, a short demo GIF does the same job.

Pin and describe your profile

Your profile page is the front door:

• Pin your best 3 to 6 repos.
• Add a profile photo and a short bio: what you study, what you are learning.
• Create a repo named exactly the same as your username. Its README shows up on your profile. A few lines about you and links to your best work is plenty.
• Commit regularly. You do not need a green square every day, but a profile that went quiet two years ago looks abandoned.

Studying other people's projects, honestly

This part is where I want to be straight with you.

Learning from other people's code is normal. Reading a good project is one of the fastest ways to see how a real app is organised. I did this with an open-source Superstore sales dashboard by Asha Kalavagunta. It is built with Python, Pandas and Streamlit, and I went through its code to understand how the data cleaning, charts and filters fit together. What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas)

What I took from it was a clear lesson about my own portfolio. A copy of someone else's project on my GitHub does not show what I can build. It shows that I found a good project. Those are different things, and a recruiter or teacher can tell the difference in about a minute.

So here is how I think it should be done:

1. Fork or copy it openly. Use GitHub's Fork button. It keeps a visible link back to the original, so nobody has to guess where it came from.
2. Keep the original credit. Leave the licence and the author's name in place. Check the repo's licence for what you are allowed to do. If there is no licence, ask the author before reusing the code.
3. Say what it is in your README. Something like "Forked from X. I studied this to learn Y." Do not describe it as something you made.
4. Keep it out of your pinned repos if it is not your work, or label it clearly as a study fork.
5. Then build your own. Take what you learned and make a different project. Same techniques, new idea, your own code.

This is not about feeling bad. Everyone starts by reading other people's work. The only real mistake is putting that work on your profile as if you wrote it. It is easy to avoid and it keeps your profile believable.

For me, the next step is simple: use what I learned about Pandas, Streamlit and project structure to start projects of my own, and put those up front. From Learning Programming to Building Real Projects: My Student Developer Journey

A quick checklist before you share your profile

• Every pinned repo has a description
• Every pinned repo has a README with a screenshot
• Install steps tested on a fresh folder
• No passwords, API keys or .env files committed
• Borrowed code is credited, forks are labelled
• Repo names are readable
• Profile bio filled in

Wrap-up

A strong student portfolio is a few finished projects that you can explain, with READMEs that someone can follow in five minutes. Pick something useful, keep the repo tidy, add a screenshot, host it if you can, and be clear about which work is yours.

You can see my profile at github.com/Pranaav717. It is a work in progress, and I will be adding my own projects there.

This post uses one small sales table and walks through the formulas I find most useful. I have checked every result below by recalculating it separately in Python, so the numbers match what Excel should show.

I have also done assignments where the sheet is formula-driven: you change an input and everything else updates by itself. That is near the end.

The sample data

Paste this into a blank sheet starting at cell A1.

The Revenue column is not typed in. It is a formula. In F2, enter:

=D2*E2

Then drag the fill handle (the small square at the bottom-right of the cell) down to F9. Each row calculates its own revenue.

The basic five

SUM

Adds up numbers.

=SUM(F2:F9)

Result: 2735. That is total revenue.

AVERAGE

=AVERAGE(F2:F9)

Result: 341.875. Average revenue per order.

COUNT and COUNTA

These look alike but count different things.

=COUNT(D2:D9)
=COUNTA(B2:B9)

COUNT counts cells that contain numbers. COUNTA counts cells that are not empty, including text. Both return 8 here. Try =COUNT(B2:B9) and you get 0, because the Product column is all text. That mistake is easy to make.

IF: make the sheet decide

IF checks a condition and returns one thing if true, another if false.

In G2, add a header "Tier" in G1, then:

=IF(F2>=300,"High","Low")

Fill down. Orders 104, 105, and 106 (revenue 320, 750, 1000) show High. The other five show Low.

The pattern is IF(test, value_if_true, value_if_false).

SUMIF and COUNTIF: totals with a condition

This is where Excel starts to feel like analysis.

=SUMIF(C2:C9,"North",F2:F9)

Result: 1000. It looks at the Region column, picks rows equal to "North", and adds their Revenue. The North orders are 50 + 200 + 750.

The order of arguments is: range to check, criteria, range to add.

=SUMIF(B2:B9,"Pen",F2:F9)

Result: 225 (50 + 100 + 75).

COUNTIF counts rows that meet a condition:

=COUNTIF(C2:C9,"North")
=COUNTIF(F2:F9,">=300")

The first returns 3 orders from North. The second returns 3 orders with revenue of at least 300.

If you need more than one condition, look at SUMIFS and COUNTIFS. For example, =SUMIFS(F2:F9,B2:B9,"Book",C2:C9,"East") returns 240.

Looking things up

Say you want the revenue of order 104 without scanning the table by eye. Put 104 in a cell, for example K2, and use a lookup.

VLOOKUP

=VLOOKUP(K2,A2:F9,6,FALSE)

Result: 320. Breaking it down:

• K2 is what you are looking for.
• A2:F9 is the table. The lookup value must be in the first column of this range.
• 6 means "return the value from the 6th column of the range".
• FALSE means exact match. Use this almost every time. Leaving it out can give wrong answers on unsorted data.

The weak point: that 6 is hard-coded. If someone inserts a column in the middle, the formula may return the wrong thing without any warning.

XLOOKUP

=XLOOKUP(K2,A2:A9,F2:F9)

Result: 320. You give it the column to search and the column to return. No column numbers, and exact match is the default.

One catch: XLOOKUP is available in Excel 2021 and Microsoft 365 (plus Excel for the web). It will not work in Excel 2019 or older. If your college lab machines run an older version, use the next option.

INDEX + MATCH

=INDEX(F2:F9,MATCH(K2,A2:A9,0))

Result: 320. MATCH finds the position of 104 in the Order ID column (position 4). INDEX then returns the 4th item from the Revenue column. The 0 means exact match.

This works in every Excel version, and it can look to the left, which VLOOKUP cannot. For instance, to find the first order ID for "Bag":

=INDEX(A2:A9,MATCH("Bag",B2:B9,0))

Result: 105. It returns the first match only, so if a product appears many times you get the earliest row.

Relative vs absolute references

This is the topic that causes the most confusion, and it matters as soon as you fill formulas down.

A relative reference like F2 changes when you copy the formula. Copy it down one row and it becomes F3. That is what you want for =D2*E2.

An absolute reference uses dollar signs and stays fixed: $F$11.

Say you put the grand total in F11:

=SUM(F2:F9)

Now you want each order's share of the total. In H2:

=F2/$F$11

Fill it down. F2 shifts to F3, F4 and so on, but $F$11 stays pinned to the total. Without the dollar signs, the second row would divide by F12, an empty cell, and you would see a #DIV/0! error.

For order 101 the share is 50 / 2735, about 1.8%. For order 106 it is 1000 / 2735, about 36.6%. Format column H as a percentage.

A quick way to add the dollar signs: click inside the reference in the formula bar and press F4. It cycles through $F$11, F$11, $F11, and F11.

Formula-driven sheets: change an input, everything updates

The real value of Excel is that you do not retype results. You set inputs once, and formulas react.

Extend the same sheet with a bonus rate. In J4 type the label "Bonus rate", and in K4 type 5%. Then add a "Bonus" header in I1 and, in I2:

=F2*$K$4

Fill down to I9. The $K$4 is absolute, so every row points at the same rate cell. Put a total at the bottom of the column:

=SUM(I2:I9)

At 5%, order 106 gets a bonus of 50 and the total bonus is 136.75. Now change K4 to 10%. Every bonus doubles without you touching a formula: order 106 becomes 100 and the total becomes 273.5.

Try changing a price too. Set E2 (the Pen price on order 101) from 5 to 6. Revenue for that row goes from 50 to 60, the grand total in F11 moves from 2735 to 2745, and =SUMIF(B2:B9,"Pen",F2:F9) moves from 225 to 235.

The habit to build: keep inputs in clearly labelled cells, never bury numbers inside formulas, and let everything else be calculated.

Mistakes to avoid

• Numbers stored as text. If a number is left-aligned and SUM ignores it, it is probably text. Convert it or retype it.
• Forgetting FALSE or 0 in lookups. You may get a wrong match instead of an error, which is worse.
• Missing dollar signs. If a filled-down formula gives odd results from row three onward, check your references first.
• Typing results by hand. If a number can be a formula, make it one.
• Extra spaces in text. "North " is not equal to "North", and your SUMIF will quietly skip it.

Where to go next

Once these feel normal, look at SUMIFS, COUNTIFS, IFERROR, and PivotTables.

Excel is also a good place to rehearse ideas before moving to Python. A SUMIF is the same thinking as a groupby in Pandas. If you want to see that side, I will link the Pandas post here: Pandas for Beginners: Cleaning and Analysing Real-World Data.

If this helped, follow the blog for more practical student-level tutorials. You can also find my work on GitHub: https://github.com/Pranaav717

I use both as a student, so this post is a comparison, not a verdict. I'll show the same small programs in each language and then tell you when I'd pick which.

All the code below was compiled with g++ -std=c++17 or run with python3, so you can paste it and try.

The short version

Now the same programs, side by side.

Hello world

Python:

print("Hello, world!")

C++:

#include <iostream>

int main() {
    std::cout << "Hello, world!" << std::endl;
    return 0;
}

Both print Hello, world!. One line versus six. The C++ version isn't pointless, though. #include pulls in the input/output library, and main is where execution starts. Python just starts at the top of the file.

To run them:

python3 hello.py

g++ -std=c++17 -o hello hello.cpp
./hello

Notice the extra compile step in C++. If you have a syntax error, the compiler stops you before anything runs.

Loops

Print the squares of 1 to 5.

Python:

for i in range(1, 6):
    print(i * i)

C++:

#include <iostream>

int main() {
    for (int i = 1; i <= 5; i++) {
        std::cout << i * i << "\n";
    }
    return 0;
}

Output for both:

1
4
9
16
25

Python uses indentation to mark the loop body. C++ uses curly braces and semicolons. Python's range(1, 6) stops before 6, which trips up beginners. The C++ loop spells out start, condition, and step, so you see exactly what is happening. I find C++ loops more verbose but also more explicit.

Reading input

Python:

name = input("Your name: ")
age = int(input("Your age: "))
print(f"Hi {name}, next year you will be {age + 1}.")

C++:

#include <iostream>
#include <string>

int main() {
    std::string name;
    int age;
    std::cout << "Your name: ";
    std::getline(std::cin, name);
    std::cout << "Your age: ";
    std::cin >> age;
    std::cout << "Hi " << name << ", next year you will be " << age + 1 << ".\n";
    return 0;
}

With the input Asha and 20, both programs print Hi Asha, next year you will be 21.

Two things to notice. In Python, input() always gives you text, so you convert with int(). In C++, you declare the type first and cin >> age reads straight into an int. Also, getline reads a whole line, spaces included. Using cin >> name would stop at the first space. This is one of those small C++ details that bites students early.

A list (or vector) and a sum

Python:

marks = [72, 85, 90, 64]
total = sum(marks)
print("Total:", total)
print("Average:", total / len(marks))

C++:

#include <iostream>
#include <numeric>
#include <vector>

int main() {
    std::vector<int> marks = {72, 85, 90, 64};
    int total = std::accumulate(marks.begin(), marks.end(), 0);
    std::cout << "Total: " << total << "\n";
    std::cout << "Average: " << static_cast<double>(total) / marks.size() << "\n";
    return 0;
}

Output for both:

Total: 311
Average: 77.75

A Python list can hold mixed types and grows freely. A C++ std::vector<int> holds only ints, but it also grows when you add items. The cast to double matters. Without it, C++ would do integer division and give you 77. Python's / always gives a float, so you never think about it.

A simple class

Python:

class Student:
    def __init__(self, name, marks):
        self.name = name
        self.marks = marks

    def average(self):
        return sum(self.marks) / len(self.marks)

s = Student("Ravi", [72, 85, 90])
print(s.name, s.average())

C++:

#include <iostream>
#include <numeric>
#include <string>
#include <vector>

class Student {
public:
    std::string name;
    std::vector<int> marks;

    Student(std::string n, std::vector<int> m) : name(n), marks(m) {}

    double average() const {
        int total = std::accumulate(marks.begin(), marks.end(), 0);
        return static_cast<double>(total) / marks.size();
    }
};

int main() {
    Student s("Ravi", {72, 85, 90});
    std::cout << s.name << " " << s.average() << "\n";
    return 0;
}

Python prints Ravi 82.33333333333333. C++ prints Ravi 82.3333, because cout shows about six significant digits by default. Same value, different default formatting.

The C++ version teaches things Python hides: access specifiers (public), constructors with initialiser lists, and const methods that promise not to change the object. If your college covers OOP in C++, this is exactly the material you will see in exams.

Learning curve

Python is easier to start with. You can write something useful in your first hour and spend your energy on logic instead of syntax. Error messages are also friendlier.

C++ asks more up front. Types, headers, compilation, pointers, and references all arrive early. Error messages from the compiler can be long and confusing at first. But the struggle forces you to understand what the computer is doing.

Performance

Python is generally slower for heavy number crunching, because it is interpreted and every value carries extra bookkeeping. C++ compiles to machine code and gives you fine control, so it is the usual choice when speed or tight resource use really matters.

I am not going to quote benchmark numbers here, because they depend on the task, the machine, and how the code is written. The qualitative picture is what a beginner needs. Many popular Python libraries (NumPy, for example) do their heavy work in compiled code underneath, so Python is often fast enough in practice for data work.

Memory management

In Python, you create objects and the runtime cleans them up when nothing refers to them. You rarely think about memory.

In C++, you decide how long things live. Modern C++ makes this much safer than the old textbooks suggest: std::vector and std::string free their own memory, and smart pointers like std::unique_ptr handle manual allocations. Still, understanding stack versus heap and pointers is part of the language, and exam questions on it are common.

Where each one gets used

• Python: data analysis, automation scripts, web backends, machine learning, quick prototypes.
• C++: game engines, operating systems and drivers, embedded software, performance-critical systems, and competitive programming (its standard library is popular there).

Both are widely used.

Fundamentals transfer

Loops, conditions, functions, arrays, recursion, and classes mean the same thing in both. The first language matters less than actually finishing programs in it. Once you know one well, the second takes a fraction of the time.

So which should you learn first?

Here is how I would decide.

Start with Python if:

• You are completely new to programming.
• You are interested in data, automation, or building small projects quickly.
• You want early wins to stay motivated.

Start with C++ if:

• Your syllabus or placement path uses it (many Indian college courses do).
• You want to understand how memory and types work from the start.
• You are into competitive programming or systems-level work.

Or do both: learn the basics in Python, then pick up C++ for a deeper view. There is no single correct order.

If your college has already put C++ on your timetable, don't fight it. Learn it properly, and use Python on the side for projects.

Wrapping up

Python gets you building faster. C++ shows you what is underneath. Pick the one that matches your next six months, not the one that wins internet arguments.

I will keep posting what I learn as a student, so follow along if that is useful. More on practical projects in What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas), and on the tools I use for them in Pandas for Beginners: Cleaning and Analysing Real-World Data.

Streamlit Community Cloud is a free way to fix that. It pulls your code from GitHub, installs your packages and gives you a public URL. This guide walks through the whole thing, and then covers the errors you are most likely to hit.

I have checked the steps below against the official Streamlit docs. The Community Cloud interface changes now and then, so if a button has moved, the docs at docs.streamlit.io are the final word.

Local vs deployed: what actually changes

When you run streamlit run app.py, your app uses your Python, your installed packages and your files. Deployed, it runs on a fresh Linux machine that knows nothing about your laptop. Community Cloud builds a new Python environment from your repository, then starts your app inside it.

So the rule is simple: anything your app needs must be in the repo or listed in a dependency file. Almost every deployment error comes from breaking that rule.

Before you deploy: prepare the project

You need three things.

1. A GitHub repository with your app in it. If you have not pushed your code yet, see Git and GitHub for College Students: From Local Project to GitHub Repository.
2. A requirements.txt file.
3. Every data file the app reads, committed to the repo.

A minimal layout looks like this:

my-dashboard/
├── app.py
├── sales.csv
├── requirements.txt
└── .gitignore

If you want a working app to practise on, How to Build an Interactive Dashboard Using Python and Streamlit gives you one that fits this layout exactly.

Write requirements.txt

Community Cloud checks for dependency files in this order: uv.lock, Pipfile, environment.yml, requirements.txt, then pyproject.toml. It looks next to your main file first, then in the repo root, and uses the first one it finds. Pick one and stick with it. For most student projects, that is requirements.txt.

streamlit>=1.32.0
pandas>=2.0.0
plotly>=5.18.0

Each line works like an argument to pip install. A few rules from the docs:

• Leave out built-in modules like math, json and random. They ship with Python and listing them causes errors.
• Streamlit is preinstalled, so you only need to list it if you want to pin or limit its version.
• If there is no requirements file at all, the app runs with only Streamlit and its own dependencies. That is why a missing file shows up as ModuleNotFoundError.

For a real-world reference, the open-source Superstore dashboard by Asha Kalavagunta (GitHub repo) lists streamlit, pandas, numpy and plotly in its requirements.txt, and is deployed on Community Cloud. That is the same shape of file you need here.

To generate your own list from your environment, run pip freeze, but trim it. The full output includes every sub-dependency pinned to your exact versions, and that can cause conflicts on a different operating system. Writing only the packages you import is cleaner.

Use paths that survive deployment

The docs say the working directory on Community Cloud is always the root of your repository. If your app sits in the root, pd.read_csv("sales.csv") works. If it sits in a subfolder, it won't. A safer habit is to build the path from the script's own location:

from pathlib import Path
import pandas as pd

DATA_PATH = Path(__file__).parent / "sales.csv"
df = pd.read_csv(DATA_PATH)

Two more path rules: use forward slashes (data/sales.csv), because backslashes don't work, and match the file name's capital letters exactly. Windows ignores case, but Linux does not. Sales.csv and sales.csv are different files there.

Keep secrets out of GitHub

If your app uses an API key or password, never hard-code it and never commit it. Keep it in .streamlit/secrets.toml on your machine and add that path to .gitignore:

.streamlit/secrets.toml
venv/
__pycache__/

In your code, read values like this:

import streamlit as st

api_key = st.secrets["api_key"]

The docs are blunt about this: the secrets.toml file should never be committed to your repository. If you pushed a key by mistake, deleting the file in a later commit is not enough, because it stays in Git history. Treat the key as leaked and generate a new one.

Deploy step by step

Push your latest code to GitHub first. Then:

1. Go to share.streamlit.io and sign in. You can sign in with GitHub, which also connects your repositories.
2. Click Create app in the top-right corner.
3. When asked if you already have an app, choose Yup, I have an app.
4. Fill in three fields: Repository, Branch and Main file path. The main file path is the file that starts your app, such as app.py. If it is inside a folder, write folder/app.py. You can also click Paste GitHub URL and drop in a link to the file.
5. Optional: choose a custom subdomain in the App URL field. Leave it blank and you get an automatically generated one. You can change it later.
6. Click Advanced settings if you need to set the Python version or add secrets (next two sections).
7. Click Deploy.

The first build takes a few minutes, longer if you have many packages. Logs show up on the right side while it builds. Only people with write access to the repository can see them.

Pick the Python version

Under Advanced settings there is a Python version dropdown. The docs say the default is 3.12. Choose the same version you use locally where you can, because package versions and built-in behaviour differ between releases. You can check yours with python --version.

Also pick a version that still gets security updates. The docs warn that if your version becomes unsupported, it will be forcibly upgraded and may break your app.

Add secrets

In the same Advanced settings dialog, paste the contents of your local secrets.toml into the Secrets field and click Save. For an app that is already live, you can edit secrets later from the app's settings.

Your live app

When the build finishes, your app opens at its own URL. That link is public, so anyone you send it to can use it.

Common errors and how to fix them

Open the logs first. On a running app, click Manage app in the lower-right corner. Most fixes start with reading the last few lines of the log.

ModuleNotFoundError: No module named 'plotly'

The package is missing from your dependency file. Add it to requirements.txt, commit, and push. Community Cloud picks up the change and redeploys. Check spelling too: the install name and import name sometimes differ (scikit-learn installs, sklearn imports).

FileNotFoundError for your CSV

Three usual causes:

• The file never got committed. Run git status and check that it is tracked.
• The path is wrong for a subfolder app. Use the Path(__file__).parent approach shown earlier.
• The file name has different capitalisation on Linux.

Installer errors or version conflicts

If the log shows a failure while installing, suspect a pinned version that doesn't exist for the Python version you chose. Loosen the pin (pandas>=2.0.0 instead of pandas==2.0.1), or try a different Python version under the app settings.

Some libraries also need system-level software, not just Python packages. For those, add a packages.txt file in the repo root, one package name per line. Community Cloud runs Debian Linux and installs them with apt-get. Most beginner apps never need this file.

Two dependency files fighting each other

Only the first dependency file found is used, in the order listed earlier. If you have both a requirements.txt and a pyproject.toml, one of them is being ignored. Keep one.

The app works, then slows down or crashes

Community Cloud gives each app limited resources. The docs list roughly 2.7 GB of memory and 2 CPU cores at the top end, with a lower floor, and note that these numbers are approximate as of February 2024 and may change without notice. Signs you are over the limit are a slow app or a message saying the app has gone over its resource limits.

What helps:

• Cache data loading with @st.cache_data so you don't re-read big files on every click.
• Don't load a huge dataset into memory if you only need a few columns. pd.read_csv(..., usecols=[...]) helps.
• Open Manage app and choose reboot to clear memory.

Edits don't show up

Community Cloud redeploys from GitHub, so a change only goes live after you push it. Commit, push, and refresh. Also check that you pushed to the same branch you selected during deployment. A master versus main mix-up is an easy way to push code the app never sees.

"This app has gone to sleep"

Free apps with no traffic for 12 hours go to sleep. Anyone who visits can click Yes, get this app back up! to wake it, and it takes a short while to start again. You do not need to be the owner to do this.

This matters if you are putting the link on a resume or portfolio. Open the app yourself before you share it, and tell people the first load might be slow. Don't rely on tricks to keep it awake. Just expect the delay.

Other limits to know about

Community Cloud limits updates from GitHub to five per minute, and all apps are hosted in the United States. If your print() output is missing from the logs, call sys.stdout.flush() after printing.

A quick checklist before you click Deploy

• App runs locally from the repo root with streamlit run app.py
• requirements.txt lists every third-party import
• Data files are committed and use relative paths
• secrets.toml is in .gitignore
• Latest code is pushed to the branch you will select

Wrap up

Deployment is mostly housekeeping. Get your dependencies listed, keep your paths relative, keep secrets out of Git, then fill in the three fields on Community Cloud. When something breaks, the logs usually tell you exactly which file or package is missing.

Once your app is live, add the link to your README so people can find it. How College Students Can Build a Strong GitHub Portfolio covers how to present projects properly.

If you want to see a full dashboard that is deployed on Community Cloud, read through Asha Kalavagunta's Sales Analytics Dashboard. You can follow my own learning projects on GitHub.

This post walks through the whole path, from an empty folder to a pushed repo, and then the errors that usually show up on the way. I ran every command below on a real machine (Git 2.43) against a local test remote, so the outputs are what Git actually printed.

Git vs GitHub, in two lines

Git is a tool on your computer. It records snapshots of your project, called commits, so you can go back or see what changed.

GitHub is a website that stores a copy of your Git project online. Git works fine without GitHub. GitHub is just where people put their repos to share them.

A repository (repo) is a project folder that Git is tracking.

One-time setup

Tell Git who you are. This name and email get attached to every commit.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Use the same email as your GitHub account if you want commits linked to your profile.

Step 1: Turn a folder into a repo

mkdir my-project
cd my-project
git init

Output:

Initialized empty Git repository in .../my-project/.git/

On my machine Git also printed a long hint about the default branch name. That hint matters later, so keep it in mind.

Now add a file:

echo 'print("hello git")' > app.py
git status --short

?? app.py

?? means Git sees the file but is not tracking it yet.

Step 2: Stage and commit

Committing is two steps. First you stage the files you want in the snapshot. Then you commit them with a message.

git add app.py
git commit -m "Add first script"

[master (root-commit) 8d064d0] Add first script
 1 file changed, 1 insertion(+)
 create mode 100644 app.py

Look at the first word inside the brackets: master. That is the branch Git created for me. Remember it.

A few habits that help:

• Write messages that say what changed. "Add first script" beats "update".
• Commit small and often.
• Run git status whenever you are unsure what state you are in.

Step 3: Create the repo on GitHub

On github.com, click New repository. Give it a name, leave it empty (no README, no .gitignore, no license), and click Create. GitHub then shows you a URL like https://github.com/your-username/my-project.git.

Leaving it empty matters. If GitHub adds a README, your local repo and the online repo start with different histories and your first push will be rejected.

Step 4: Connect local to remote

A remote is just a saved link to another copy of your repo. By convention the main one is called origin.

git remote add origin https://github.com/your-username/my-project.git
git remote -v

In my test I used a local bare repo as the remote, so my output looked like this:

origin	../remote.git (fetch)
origin	../remote.git (push)

With GitHub you will see your GitHub URL there instead. The behaviour is the same.

Step 5: The push that fails (master vs main)

GitHub's default branch is main. Depending on your Git version and settings, git init may still create master. So you run the push command from GitHub's instructions:

git push -u origin main

And get this:

error: src refspec main does not match any
error: failed to push some refs to '../remote.git'

Read it slowly. It says: you asked me to push a branch called main, but I have no branch with that name. Your branch is master. Check:

git branch

* master

There it is. The mismatch is just a name.

Fix 1: rename your local branch to main

This is what I would do.

git branch -M main
git push -u origin main

To ../remote.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

-M renames the branch even if the name is taken. -u links your local main to origin/main, so later you can type plain git push.

Fix 2: push master into a remote branch called main

If you want to keep master locally:

git push -u origin master:main

To ../remote2.git
 * [new branch]      master -> main
branch 'master' set up to track 'origin/main'.

It works, but now your local master tracks a remote main. That is confusing a month later, so Fix 1 is cleaner.

Stop it happening again

Tell Git to name new repos main from the start:

git config --global init.defaultBranch main

Git 2.28 or newer supports this setting.

Step 6: Branches

A branch is a separate line of work. You try something on a branch, and if it works you merge it back into main. If it does not, you delete the branch and nothing is harmed.

git switch -c add-readme
echo "# My Project" > README.md
git add README.md
git commit -m "Add README"

Switched to a new branch 'add-readme'
[add-readme 495fd55] Add README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Go back to main and merge:

git switch main
git merge add-readme
git push
git branch -d add-readme

Switched to branch 'main'
Your branch is up to date with 'origin/main'.
Updating 8d064d0..495fd55
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
To ../remote.git
   8d064d0..495fd55  main -> main
Deleted branch add-readme (was 495fd55).

"Fast-forward" means main had nothing new of its own, so Git just moved the pointer forward. No extra merge commit.

For solo college projects you can commit straight to main. Branches become useful when you work in a group or want to experiment safely.

Common errors after the first push

Rejected: fetch first / non-fast-forward

You push and get:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '../remote.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.

The online repo has commits you do not have. Maybe a teammate pushed, maybe you edited a file on github.com, maybe you pushed from another laptop. Git refuses to overwrite them.

Fix: pull first, then push.

git pull --no-rebase --no-edit
git push

Merge made by the 'ort' strategy.
 notes.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 notes.txt
To ../remote.git
   e92fe90..f6a0bb1  main -> main

Please do not reach for git push --force to make the error go away. That overwrites the remote's commits, including your teammate's.

Merge conflict

If both sides changed the same lines, the pull stops:

CONFLICT (content): Merge conflict in app.py
Automatic merge failed; fix conflicts and then commit the result.

Open the file. Git marks both versions:

print("hello git")
# my edit
<<<<<<< HEAD
print('bye')
=======
# friend's line
>>>>>>> 19ba3faf8afa0169000c7478eb89b9abf0822b1a

Everything between <<<<<<< and ======= is yours. Everything between ======= and >>>>>>> is theirs. Edit the file to the version you actually want, delete the marker lines, then:

git add app.py
git commit -m "Merge friend's changes"
git push

To ../remote.git
   19ba3fa..f7a1f06  main -> main

Authentication failed

Since August 2021, GitHub does not accept your account password for Git operations over HTTPS. If you type your password, you get an authentication error. Two ways around it:

Option A: GitHub CLI. Install it from cli.github.com, then:

gh auth login

Pick GitHub.com, HTTPS, and log in through the browser. After that, git push just works.

Option B: Personal access token. On GitHub go to Settings, Developer settings, Personal access tokens, and generate one with the repo scope. When Git asks for a password, paste the token instead. Treat it like a password and never commit it into a file.

I could not run the login flows in my test setup because they need a browser, so follow GitHub's current docs for exact screens.

Accidentally committed junk

Things like __pycache__/, .env files, or virtual environments should not be in a repo. Create a file named .gitignore before your first commit:

__pycache__/
.venv/
.env
*.pyc

If a secret like an API key did get pushed, deleting it in a later commit is not enough. It stays in history. Revoke the key and make a new one.

A quick command cheat sheet

What a finished repo looks like

If you want to see a real small project laid out on GitHub, look at Asha Kalavagunta's Sales Analytics Dashboard. It is an open-source Streamlit project that I studied, and it is a good example of a repo with an app file, an ETL script, a requirements file and a README. My GitHub has a copy of it too, but the original is hers, so that is the link to open. What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas)

Wrap-up

The path is short: git init, git add, git commit, git remote add, git push. Nearly every beginner error comes from three things: the branch is master but you pushed main, the remote has commits you lack, or you are logging in with a password instead of a token.

Once you can push, put your next project on GitHub from day one. How College Students Can Build a Strong GitHub Portfolio covers how to make those repos look good. My profile is at github.com/Pranaav717 if you want to follow along as I add projects.

ETL is the standard way to fix that before any charts exist. In this post I will explain what ETL means and build a small pipeline in Pandas, with real outputs from running it. Then I will show how an open-source dashboard follows the same stages.

If Pandas basics are new to you, read Pandas for Beginners: Cleaning and Analysing Real-World Data first.

What is ETL?

ETL stands for Extract, Transform, Load.

• Extract: read the raw data from its source (here, a CSV).
• Transform: clean it and add useful columns.
• Load: save the result somewhere the next step can use it (here, another CSV).

That is all. The word "pipeline" just means these steps run in order, every time, the same way. Running one script is better than fixing a file by hand, because you can rerun it when new data arrives.

The raw file

I made orders_raw.csv, a small file with problems you will meet in real data: a missing sales and profit value, a duplicated order, a date that is not a date, and column names with spaces.

Order ID,Order Date,Ship Date,Region,Category,Sales,Profit,Discount
2001,01/05/2024,01/09/2024,West,Furniture,260.50,41.68,0.0
2002,01/09/2024,01/11/2024,East,Technology,640.00,128.00,0.1
2003,02/14/2024,02/20/2024,West,Office Supplies,18.20,-3.64,0.2
2004,02/20/2024,02/22/2024,Central,Technology,,,0.0
2005,03/02/2024,03/06/2024,East,Furniture,310.00,-31.00,0.3
2005,03/02/2024,03/06/2024,East,Furniture,310.00,-31.00,0.3
2006,03/18/2024,03/19/2024,South,Office Supplies,50.00,12.50,0.0
2007,04/01/2024,04/05/2024,West,Technology,420.00,63.00,0.15
2008,not a date,04/15/2024,Central,Furniture,150.00,9.00,0.1
2009,05/07/2024,05/10/2024,South,Technology,610.00,183.00,0.0
2010,07/21/2024,07/24/2024,East,Office Supplies,21.50,6.45,0.0

Step 1: Extract

import pandas as pd

RAW, OUT = "orders_raw.csv", "orders_clean.csv"

df = pd.read_csv(RAW, encoding="latin1")
print(df.shape)

(11, 8)

The encoding="latin1" part is worth explaining. Files exported from Excel sometimes contain characters that are not valid UTF-8, and read_csv fails with a decode error. latin1 is a forgiving encoding that reads them. My sample file is plain ASCII so it does not need it, but real exports often do.

Step 2: Transform, part one (cleaning)

Clean before you calculate. If you build columns on dirty data, you carry the dirt forward.

df.columns = [c.strip().replace(" ", "_") for c in df.columns]

df["Order_Date"] = pd.to_datetime(df["Order_Date"], format="%m/%d/%Y", errors="coerce")
df["Ship_Date"] = pd.to_datetime(df["Ship_Date"], format="%m/%d/%Y", errors="coerce")

for col in ["Sales", "Profit", "Discount"]:
    df[col] = pd.to_numeric(df[col], errors="coerce")

before = len(df)
df = df.dropna(subset=["Sales", "Profit", "Order_Date"]).drop_duplicates()
print("rows removed:", before - len(df))

rows removed: 3

What happened here:

• Column names lost their spaces, so Order Date became Order_Date.
• errors="coerce" turns anything unparseable into a missing value (NaT for dates, NaN for numbers) instead of crashing. That is how "not a date" became a missing date, and then dropna removed it.
• We also specify format="%m/%d/%Y". Without it, Pandas guesses, and dates like 01/05/2024 can be read as 1 May instead of 5 January.

Three rows went: order 2004 (missing sales and profit), order 2008 (bad date), and the second copy of order 2005.

Step 3: Transform, part two (feature engineering)

Feature engineering means creating new columns from existing ones, so analysis gets easier. We will add five.

df["Year"] = df["Order_Date"].dt.year
df["Quarter"] = "Q" + df["Order_Date"].dt.quarter.astype(str)
df["Days_to_Ship"] = (df["Ship_Date"] - df["Order_Date"]).dt.days.clip(lower=0)
df["Profit_Margin"] = (df["Profit"] / df["Sales"].replace(0, float("nan")) * 100).round(2)
df["Revenue_Band"] = pd.cut(
    df["Sales"],
    bins=[0, 50, 200, 500, df["Sales"].max() + 1],
    labels=["Low", "Medium", "High", "Premium"],
    right=False,
)
print(df[["Order_ID", "Sales", "Year", "Quarter", "Days_to_Ship", "Profit_Margin", "Revenue_Band"]])

    Order_ID  Sales  Year Quarter  Days_to_Ship  Profit_Margin Revenue_Band
0       2001  260.5  2024      Q1             4           16.0         High
1       2002  640.0  2024      Q1             2           20.0      Premium
2       2003   18.2  2024      Q1             6          -20.0          Low
4       2005  310.0  2024      Q1             4          -10.0         High
6       2006   50.0  2024      Q1             1           25.0       Medium
7       2007  420.0  2024      Q2             4           15.0         High
9       2009  610.0  2024      Q2             3           30.0      Premium
10      2010   21.5  2024      Q3             3           30.0          Low

A few notes on each one:

• Year and Quarter come from the .dt accessor on a datetime column. You need real dates first, which is why cleaning came earlier.
• Days_to_Ship subtracts two dates to get a timedelta, and .dt.days turns it into a number. The clip(lower=0) stops negative values from data-entry mistakes.
• Profit_Margin is profit divided by sales, times 100. Replacing a zero sales value with NaN avoids a divide-by-zero.
• Revenue_Band uses pd.cut, which sorts numbers into bins. With right=False, each bin includes its left edge, so a sale of exactly 50 lands in Medium, not Low. Look at order 2006 in the output. It is an easy edge case to get wrong, so test it yourself.

Check the bin behaviour in isolation:

print(pd.cut(pd.Series([49.99, 50, 200]), bins=[0, 50, 200, 500, 1000],
             labels=["L", "M", "H", "P"], right=False).tolist())

['L', 'M', 'H']

Step 4: Validate

Before saving, check your own work. assert stops the script if a condition is false.

assert df["Sales"].min() > 0, "Sales has non-positive values"
assert df["Days_to_Ship"].min() >= 0, "Negative ship days found"
assert df.duplicated().sum() == 0, "Duplicates still present"
assert df["Order_Date"].isnull().sum() == 0, "Null order dates found"
print("all checks passed")

all checks passed

This looks boring when it passes. It earns its place the day a new data file breaks something, because the script fails loudly instead of quietly saving bad data. One honest caveat: some of these checks can never fail given the earlier steps. For example, clip(lower=0) already guarantees no negative ship days. Good checks should be able to fail, so think about what could actually go wrong with your data.

Step 5: Load

df.to_csv(OUT, index=False)
print(pd.read_csv(OUT).shape)
print(df["Revenue_Band"].value_counts().sort_index())

(8, 13)
Revenue_Band
Low        2
Medium     1
High       3
Premium    2
Name: count, dtype: int64

We started with 11 rows and 8 columns. We ended with 8 rows and 13 columns. index=False stops Pandas writing the row numbers as an extra column.

Reading the file back to confirm the shape is a cheap check against silent mistakes.

How a real project does this

I have been reading the code of a Superstore dashboard built by Asha Kalavagunta (I studied it; I did not write it). Its etl_pipeline.py follows the same stages, in a single top-to-bottom script:

The README describes 9,994 rows and 21 raw columns becoming 30 cleaned columns. The app then reads the cleaned file, so charts and filters never touch raw data. That separation is the real lesson. Cleaning happens once, in one place.

Reading it, one thing I would try is making the validation checks able to fail on real problems, for example checking that cleaning actually removed zero-sales rows. That is a suggestion from a learner, not a criticism.

Common ETL mistakes

• Cleaning after feature engineering. Build features on clean data only.
• Letting Pandas guess date formats. Pass format=.
• Overwriting the raw file. Keep the raw CSV untouched and write to a new file. You can always rerun.
• No validation. A pipeline that never complains is not necessarily correct.
• Hardcoding file names deep in the script. Put them at the top, as RAW and OUT are above.

Wrapping up

ETL is just a habit: read, clean, add features, check, save. Pandas gives you everything needed for a small version of it, and the same structure scales to bigger projects.

Want to see the full version? Browse the original project by Asha Kalavagunta on GitHub, and find more of my learning work at github.com/Pranaav717. The next post covers putting a project like this on GitHub: Git and GitHub for College Students: From Local Project to GitHub Repository.

Pandas is the Python library that handles this. In this post we will clean a small sales file and then answer a few questions about it. Every snippet below was run with Pandas 2.3.3, and the outputs are copied from the terminal.

This is part of my series on building real-world projects with Python. If you want to see where Pandas fits in a full project, read What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas) first. Not required, though.

What is Pandas?

Pandas is a Python library for working with tabular data, the kind you see in a spreadsheet. You install it with:

pip install pandas

Then import it with the usual short name:

import pandas as pd

Everything in Pandas revolves around two objects.

Series

A Series is one column of data. It is a list of values with an index (a label for each row).

s = pd.Series([260.5, 640.0, 18.2], name="sales")
print(s)
print(s.mean())

0    260.5
1    640.0
2     18.2
Name: sales, dtype: float64
306.23333333333335

DataFrame

A DataFrame is a table. Each column is a Series, and they all share the same index. Almost everything you do in Pandas happens on a DataFrame, so this is the one to get comfortable with.

The dataset

I made a small file called sales_raw.csv so the outputs fit on screen. It has 11 rows and a few deliberate problems: two missing sales values, one duplicated order, and column names with spaces.

order id,order date,region,category,product,sales,quantity,discount
1001,2024-01-05,West,Furniture,Bookcase,260.5,2,0.0
1002,2024-01-09,East,Technology,Phone,640.0,1,0.1
1003,2024-02-14,West,Office Supplies,Binder,18.2,3,0.2
1004,2024-02-20,Central,Technology,Keyboard,,2,0.0
1005,2024-03-02,East,Furniture,Chair,310.0,1,0.0
1005,2024-03-02,East,Furniture,Chair,310.0,1,0.0
1006,2024-03-18,South,Office Supplies,Paper,24.9,5,0.0
1007,2024-04-01,West,Technology,Monitor,420.0,2,0.15
1008,2024-04-12,Central,Furniture,Table,,1,0.3
1009,2024-05-07,South,Technology,Phone,610.0,1,0.0
1010,2024-05-21,East,Office Supplies,Binder,21.5,4,0.2

Can you spot the problems already? Pandas can find them for you.

Reading the CSV

read_csv loads the file into a DataFrame.

import pandas as pd

pd.set_option("display.width", 200)
pd.set_option("display.max_columns", 20)

df = pd.read_csv("sales_raw.csv")
print(df.head())
print(df.shape)
df.info()

   order id  order date   region         category   product  sales  quantity  discount
0      1001  2024-01-05     West        Furniture  Bookcase  260.5         2       0.0
1      1002  2024-01-09     East       Technology     Phone  640.0         1       0.1
2      1003  2024-02-14     West  Office Supplies    Binder   18.2         3       0.2
3      1004  2024-02-20  Central       Technology  Keyboard    NaN         2       0.0
4      1005  2024-03-02     East        Furniture     Chair  310.0         1       0.0
(11, 8)
<class 'pandas.core.frame.DataFrame'>
RangeIndex: 11 entries, 0 to 10
Data columns (total 8 columns):
 #   Column      Non-Null Count  Dtype  
---  ------      --------------  -----  
 0   order id    11 non-null     int64  
 1   order date  11 non-null     object 
 2   region      11 non-null     object 
 3   category    11 non-null     object 
 4   product     11 non-null     object 
 5   sales       9 non-null      float64
 6   quantity    11 non-null     int64  
 7   discount    11 non-null     float64
dtypes: float64(2), int64(2), object(4)
memory usage: 836.0+ bytes

Three habits worth building here:

• head() shows the first five rows. Always look at your data before touching it.
• shape gives (rows, columns).
• info() shows the type of each column and how many values are not null. Look at sales: 9 non-null out of 11. That is our first clue.

Also notice that order date is object, which means plain text. Pandas has not understood that these are dates yet. We will fix that.

Finding missing values

isna() marks each cell as missing or not. Chain sum() to count them per column.

print(df.isna().sum())

order id      0
order date    0
region        0
category      0
product       0
sales         2
quantity      0
discount      0
dtype: int64

Two missing in sales. To see the actual rows:

print(df[df["sales"].isna()])

   order id  order date   region    category   product  sales  quantity  discount
3      1004  2024-02-20  Central  Technology  Keyboard    NaN         2       0.0
8      1008  2024-04-12  Central   Furniture     Table    NaN         1       0.3

Handling missing values: fillna or dropna

You have two basic choices, and neither is always right.

dropna removes the rows. Use it when the missing value makes the row useless.

print(len(df.dropna(subset=["sales"])))

9

The subset argument matters. Without it, Pandas drops a row if any column is missing.

fillna replaces the gaps with something. Here I use the median, which is not pulled around by one huge order the way the mean is.

print("median:", df["sales"].median())
df["sales"] = df["sales"].fillna(df["sales"].median())

median: 310.0

A word of caution. Filling invents data. For a practice file it is fine. For something that feeds a report, ask whether dropping is more honest. A fair rule: if the missing field is the one you are about to sum, dropping is usually the safer choice.

Removing duplicates

Order 1005 appears twice. Check first, then remove.

print(df.duplicated().sum())
df = df.drop_duplicates()
print(df.shape)

1
(10, 8)

duplicated() flags a row if an identical earlier row exists. drop_duplicates() keeps the first and removes the rest. Going from 11 rows to 10 is what we expected.

Renaming columns and fixing types

Column names with spaces are annoying, because you cannot use df.order_id style access. Rename them with a dictionary:

df = df.rename(columns={"order id": "order_id", "order date": "order_date"})
df["order_date"] = pd.to_datetime(df["order_date"])
print(df.dtypes)

order_id               int64
order_date    datetime64[ns]
region                object
category              object
product               object
sales                float64
quantity               int64
discount             float64
dtype: object

order_date is now a real datetime. That unlocks things like df["order_date"].dt.month, which we will lean on in the next post.

Filtering rows

Filtering uses a boolean condition inside square brackets. Pandas builds a True/False value for every row and keeps the True ones.

Orders over 300:

print(df[df["sales"] > 300])

   order_id order_date   region    category   product  sales  quantity  discount
1      1002 2024-01-09     East  Technology     Phone  640.0         1      0.10
3      1004 2024-02-20  Central  Technology  Keyboard  310.0         2      0.00
4      1005 2024-03-02     East   Furniture     Chair  310.0         1      0.00
7      1007 2024-04-01     West  Technology   Monitor  420.0         2      0.15
8      1008 2024-04-12  Central   Furniture     Table  310.0         1      0.30
9      1009 2024-05-07    South  Technology     Phone  610.0         1      0.00

See the two 310.0 rows for Keyboard and Table? Those are our filled values. A good reminder that fillna changes what your filters return.

Combine conditions with & (and) or | (or). Put each condition in brackets:

print(df[(df["region"] == "West") & (df["category"] == "Technology")])

   order_id order_date region    category  product  sales  quantity  discount
7      1007 2024-04-01   West  Technology  Monitor  420.0         2      0.15

Using Python's and here throws an error. It has to be &. This one catches nearly everyone once.

Grouping and aggregating

This is where analysis starts. groupby splits the data into groups, and then you apply a calculation to each group.

Total sales per region:

print(df.groupby("region")["sales"].sum())

region
Central    620.0
East       971.5
South      634.9
West       698.7
Name: sales, dtype: float64

For several calculations at once, use agg with named outputs:

out = df.groupby("category").agg(
    total_sales=("sales", "sum"),
    avg_discount=("discount", "mean"),
    orders=("order_id", "count"),
).sort_values("total_sales", ascending=False)
print(out)

                 total_sales  avg_discount  orders
category                                          
Technology            1980.0      0.062500       4
Furniture              880.5      0.100000       3
Office Supplies         64.6      0.133333       3

The format is new_name=("column", "function"). Once you understand this pattern, a lot of dashboard-style questions become one short block of code. Technology brings in the most money here, and Office Supplies has the highest average discount while selling the least. That kind of comparison is exactly what a dashboard shows.

The whole thing in one script

Here is the cleaning part together, so you can copy it and run it.

import pandas as pd

df = pd.read_csv("sales_raw.csv")
df["sales"] = df["sales"].fillna(df["sales"].median())
df = df.drop_duplicates()
df = df.rename(columns={"order id": "order_id", "order date": "order_date"})
df["order_date"] = pd.to_datetime(df["order_date"])

print(df.groupby("category")["sales"].sum())

A note on real projects

Real files are bigger and messier than this one. I have been reading an open-source Superstore dashboard by Asha Kalavagunta, and it uses exactly these tools on 9,994 rows: clean column names, parse dates, drop nulls and duplicates. The only difference is scale. The next post walks through how that cleaning is organised as a proper ETL pipeline.

Common beginner mistakes

• Forgetting to assign. df.drop_duplicates() alone does not change df. Write df = df.drop_duplicates().
• Using and instead of & in filters.
• Skipping info(). Dates stored as text will quietly break your month-wise charts.
• Filling without thinking. Decide on purpose, not by habit.

Wrapping up

You now know the core loop: load, inspect, clean, filter, group. That covers a large share of everyday data work in Python.

Next up is ETL: Understanding ETL in Python Through a Practical Project. If you want more tutorials like this, follow the blog. My GitHub is at github.com/Pranaav717.

Streamlit lets you build that page with plain Python. No HTML, no JavaScript. In this tutorial you will build a small sales dashboard from scratch: a CSV file, a few KPI cards, sidebar filters and three Plotly charts. It is about 60 lines of code, and every line is shown below.

What Streamlit actually does

Streamlit is an open-source Python library that turns a script into a web app. You write top-to-bottom Python, call functions like st.title() or st.metric(), and each call puts something on the page.

One thing to understand early: Streamlit reruns your whole script every time someone touches a widget. Change a filter, and the script runs again from line 1. That sounds wasteful, but it keeps the mental model simple. It also explains why we cache the data loading step later.

If you want to see what a bigger finished dashboard looks like, there is an open-source Superstore dashboard by Asha Kalavagunta (GitHub repo) with KPI cards, 14 charts and six filters. I went through its code while learning, and the small app here uses the same building blocks at a much smaller scale. What I Learned Studying a Python Sales Analytics Dashboard (Streamlit + Pandas)

What you need

• Python 3.10 or newer
• A terminal and a code editor (VS Code is fine)
• Streamlit 1.32 or newer, Pandas 2.x and Plotly

The code in this post was run with Streamlit 1.67, Pandas 2.3 and Plotly 7. It uses nothing that is new in those versions, apart from one note about chart width that I mention in the charts section.

Step 1: Set up the project

Make a folder and a virtual environment. A virtual environment keeps this project's packages separate from everything else on your machine.

mkdir sales-dashboard
cd sales-dashboard
python -m venv venv

Activate it. On Windows:

venv\Scripts\activate

On macOS or Linux:

source venv/bin/activate

Now install the three libraries:

pip install streamlit pandas plotly

Check that Streamlit works:

streamlit hello

A demo app opens in your browser. If it does, your setup is fine. Press Ctrl+C in the terminal to stop it.

Step 2: Create the sample data

You need a CSV with five columns: Order Date, Region, Category, Sales, Profit. Instead of pasting 60 rows into this post, here is a short script that generates the file. Save it as make_data.py and run python make_data.py once.

import csv, random
random.seed(7)
regions=["East","West","Central","South"]
cats={"Furniture":(120,500,-0.05,0.18),"Technology":(200,900,0.05,0.30),"Office Supplies":(20,200,0.02,0.25)}
import datetime
rows=[]
d=datetime.date(2023,1,1)
for i in range(60):
    od=datetime.date(2023,1,1)+datetime.timedelta(days=i*12+random.randint(0,6))
    c=random.choice(list(cats)); lo,hi,pl,ph=cats[c]
    s=round(random.uniform(lo,hi),2)
    rows.append([od.isoformat(),random.choice(regions),c,s,round(s*random.uniform(pl,ph),2)])
with open("sales.csv","w",newline="") as f:
    w=csv.writer(f); w.writerow(["Order Date","Region","Category","Sales","Profit"]); w.writerows(rows)

You now have sales.csv. The first rows look like this (your numbers will match mine because of the fixed random seed):

Order Date,Region,Category,Sales,Profit
2023-01-03,East,Furniture,270.03,-9.0
2023-01-17,East,Furniture,258.96,41.23

The data is made up, so don't read anything into the numbers. If you have a real CSV with the same five columns, use that instead. The app works the same way.

Step 3: Write the app

Create app.py in the same folder. Here is the full file. The sections after it explain each part.

import pandas as pd
import plotly.express as px
import streamlit as st

st.set_page_config(page_title="Sales Dashboard", layout="wide")
st.title("Sales Dashboard")

@st.cache_data
def load_data(path: str) -> pd.DataFrame:
    df = pd.read_csv(path, parse_dates=["Order Date"])
    df["Month"] = df["Order Date"].dt.to_period("M").dt.to_timestamp()
    return df

df = load_data("sales.csv")

# Sidebar filters
st.sidebar.header("Filters")
regions = st.sidebar.multiselect(
    "Region", options=sorted(df["Region"].unique()), default=sorted(df["Region"].unique())
)
categories = st.sidebar.multiselect(
    "Category", options=sorted(df["Category"].unique()), default=sorted(df["Category"].unique())
)

filtered = df[df["Region"].isin(regions) & df["Category"].isin(categories)]

if filtered.empty:
    st.warning("No data for these filters. Pick at least one region and one category.")
    st.stop()

# KPI cards
total_sales = filtered["Sales"].sum()
total_profit = filtered["Profit"].sum()
margin = total_profit / total_sales * 100

c1, c2, c3 = st.columns(3)
c1.metric("Total Sales", f"${total_sales:,.0f}")
c2.metric("Total Profit", f"${total_profit:,.0f}")
c3.metric("Profit Margin", f"{margin:.1f}%")

# Charts
monthly = filtered.groupby("Month", as_index=False)[["Sales", "Profit"]].sum()
fig_line = px.line(monthly, x="Month", y=["Sales", "Profit"], markers=True,
                   title="Monthly Sales and Profit")
st.plotly_chart(fig_line)

left, right = st.columns(2)
by_region = filtered.groupby("Region", as_index=False)["Sales"].sum()
left.plotly_chart(px.bar(by_region, x="Region", y="Sales", title="Sales by Region"))
by_cat = filtered.groupby("Category", as_index=False)["Profit"].sum()
right.plotly_chart(px.pie(by_cat, names="Category", values="Profit", hole=0.4,
                          title="Profit by Category"))

with st.expander("See the data"):
    st.dataframe(filtered)

Run it:

streamlit run app.py

Your browser opens at http://localhost:8501.

How the code works

Loading data with caching

@st.cache_data
def load_data(path: str) -> pd.DataFrame:
    df = pd.read_csv(path, parse_dates=["Order Date"])
    df["Month"] = df["Order Date"].dt.to_period("M").dt.to_timestamp()
    return df

Remember that Streamlit reruns the script on every interaction. Without caching, it would re-read the CSV each time you click a filter. @st.cache_data stores the returned DataFrame, so the function body only runs the first time (or when the file path argument changes).

parse_dates=["Order Date"] tells Pandas to read that column as real dates, not text. That matters because the next line, .dt.to_period("M").dt.to_timestamp(), rounds each date down to the first day of its month. We use that Month column to group sales by month later.

One caveat: if you edit sales.csv while the app is running, the cache won't notice, because the function argument (the path) hasn't changed. Press C in the app and choose "Clear cache", or restart it.

Sidebar filters

regions = st.sidebar.multiselect(
    "Region", options=sorted(df["Region"].unique()), default=sorted(df["Region"].unique())
)

st.sidebar.multiselect draws a dropdown in the left panel where people can pick several values. We fill the options from the data itself, so if a new region appears in the CSV, the filter picks it up without code changes. Setting default to all options means the dashboard starts unfiltered.

Then we filter the DataFrame:

filtered = df[df["Region"].isin(regions) & df["Category"].isin(categories)]

.isin() keeps rows whose value is in the selected list. The & joins two conditions, and each one needs to stay in its own comparison. Everything below this line uses filtered, not df, so every number and chart reacts to the filters.

Handling the empty case

if filtered.empty:
    st.warning("No data for these filters. Pick at least one region and one category.")
    st.stop()

If someone clears every option, filtered has zero rows, and the profit margin line would divide by zero. st.stop() ends the script run right there, so nothing below it executes. Try it: remove all regions in the sidebar and you get the warning instead of a crash.

KPI cards with st.metric

c1, c2, c3 = st.columns(3)
c1.metric("Total Sales", f"${total_sales:,.0f}")

st.columns(3) splits the page into three side-by-side containers. st.metric(label, value) shows a big number with a small label above it. The f-string format :,.0f adds thousand separators and drops the decimals. st.metric also accepts a delta argument if you want to show a change, such as vs last month, but we skip it here to keep the app simple.

Charts with Plotly Express

monthly = filtered.groupby("Month", as_index=False)[["Sales", "Profit"]].sum()
fig_line = px.line(monthly, x="Month", y=["Sales", "Profit"], markers=True,
                   title="Monthly Sales and Profit")
st.plotly_chart(fig_line)

The pattern is always the same: summarise with groupby, build a figure with px.something, then hand it to st.plotly_chart. Passing a list to y draws one line per column. as_index=False keeps Month as a normal column, which is what Plotly Express expects.

The bar chart and donut chart follow the same pattern. A donut is just px.pie with hole=0.4.

A note on chart width. In Streamlit 1.42 and later, Plotly charts stretch to the container by default, which is what this code relies on. If you are on 1.32 to 1.41, add use_container_width=True inside each st.plotly_chart() call or the charts will keep Plotly's default width. In the newest releases use_container_width is deprecated in favour of width="stretch", so pick based on your version. The simplest fix is to upgrade Streamlit.

Common beginner mistakes

Forgetting the script reruns. If you put counter = 0 at the top and expect it to grow with clicks, it won't. Every rerun resets it. For values that must survive reruns, look at st.session_state.

Running python app.py. This does not start the web server. You'll get a few warnings and no dashboard. Always use streamlit run app.py.

Wrong working directory. pd.read_csv("sales.csv") looks in the folder you launched the command from. If you see FileNotFoundError, cd into the project folder first. How to Deploy a Python Streamlit Project Online (Free, Step by Step) covers a more robust way to build paths.

Filtering the original DataFrame. If you chart df instead of filtered, the widgets will appear to do nothing. Check which variable each chart uses.

Column name typos. "Order date" and "Order Date" are different to Pandas. A KeyError mentioning a column name almost always means a spelling or case mismatch.

Caching something that should change. @st.cache_data is for loading and heavy calculations. Don't wrap your filter logic in it unless you pass the filter values in as arguments.

Where to go next

Once this runs, try one change at a time:

1. Add a date range filter with st.sidebar.date_input.
2. Add a fourth KPI, like average order value.
3. Swap the donut for a px.scatter of Sales vs Profit and see which orders lose money.
4. Load your own CSV with st.file_uploader.

When you are ready to put it online, push the folder to GitHub and follow How to Deploy a Python Streamlit Project Online (Free, Step by Step). For cleaning messy data before it reaches a dashboard, see Pandas for Beginners: Cleaning and Analysing Real-World Data.

Wrap up

You now have a working dashboard: cached data loading, multiselect filters, KPI cards and three interactive charts, all in one short Python file. The Streamlit docs at docs.streamlit.io are worth bookmarking, since every widget there has a runnable example.

If this was useful, follow the blog for the next posts in this series, and have a look at my GitHub profile. To see a much bigger dashboard built with the same tools, read through Asha Kalavagunta's Sales Analytics Dashboard.

This post is what I took away from that. If you are a student who knows some Python and wants to see what a real Pandas and Streamlit project looks like end to end, this is a good one to study.

What the project is

It is a sales dashboard built on the Kaggle Sample Superstore dataset. The data has 9,994 rows and 21 raw columns, covering January 2014 to December 2017 across four US regions. After cleaning, the table has 30 columns.

The stack is simple:

• Python 3.10+
• Pandas and NumPy for the data work
• Plotly Express and Graph Objects for charts
• Streamlit for the web interface
• Streamlit Community Cloud for hosting

The repo is small. There are four files that matter: app.py, etl_pipeline.py, cleaned_data.csv and requirements.txt.

The structure: two scripts, one clean file

The first thing I liked is the separation. The cleaning logic lives in etl_pipeline.py. It reads the raw CSV and writes cleaned_data.csv. Then app.py reads that cleaned file and draws the dashboard.

So the flow is:

1. Raw Superstore CSV
2. etl_pipeline.py cleans it and adds new columns
3. cleaned_data.csv is saved
4. app.py loads it, applies filters, shows KPIs and charts

Notice that app.py is not fragile about this. Its load_data() function tries cleaned_data.csv first, then falls back to the raw Sample - Superstore.csv. It is wrapped in @st.cache_data(ttl=300), so Streamlit does not re-read the file on every click. That one decorator is worth remembering. Streamlit reruns the whole script on every interaction, and caching is how you keep that fast.

The ETL step, in plain words

ETL means extract, transform, load. The script literally labels its sections that way. Here is what happens.

Extract. The CSV is loaded with latin1 encoding:

df = pd.read_csv(RAW_FILE, encoding='latin1')

The Superstore file has characters that break the default UTF-8 reader, so this encoding argument matters. Good tip if you ever hit a decode error on a downloaded CSV.

Clean. Column names are normalised so spaces and hyphens become underscores. That makes Order Date into Order_Date, which you can access cleanly in code:

df.columns = [c.strip().replace(' ', '_').replace('-', '_') for c in df.columns]

Dates are parsed and the numeric columns (Sales, Profit, Discount, Quantity) are coerced with errors='coerce'. That setting turns anything unparseable into a null instead of crashing. After that, rows missing Sales, Profit or Order_Date are dropped, and duplicates are removed.

Transform. This is where new columns get created. More on that below.

Validate. I think this is the most underrated part. The script ends with a handful of assert checks: sales must be positive, ship days cannot be negative, no duplicates remain, no null order dates. If any of these fail, the script stops. It is a cheap way to trust your own output.

Derived columns (feature engineering)

Raw data rarely has exactly what you want to chart. The ETL script builds these from the existing columns:

• Year, Month, Month_Name, Quarter and YearQuarter, all from Order_Date
• Days_to_Ship, which is Ship_Date minus Order_Date
• Profit_Margin, which is profit divided by sales, times 100
• Revenue_Band, which buckets each order as Low, Medium, High or Premium

Two lines show the style well:

df['Days_to_Ship']  = (df['Ship_Date'] - df['Order_Date']).dt.days.clip(lower=0)
df['Profit_Margin'] = (df['Profit'] / df['Sales'].replace(0, np.nan) * 100).round(2)

What I picked up here: the .clip(lower=0) stops negative ship days, and .replace(0, np.nan) avoids dividing by zero. Small defensive details like these are what separate a script that works once from one that keeps working.

The revenue bands use pd.cut with bins at 0, 50, 200 and 500, so orders fall into Low (under $50), Medium, High or Premium (over $500).

KPI cards

The top of the dashboard shows five numbers: Total Revenue, Net Profit, Total Orders, Unique Customers and Average Discount. They are computed straight from the filtered DataFrame. Total orders, for example, uses nunique() on Order_ID, because one order can have several rows.

That is a good Pandas lesson by itself. Counting rows and counting orders are not the same thing.

The charts

The README counts 14 charts. Reading through app.py, they cover:

• Monthly revenue and profit as a line chart
• Revenue by region as a bar chart
• Category split as a donut
• Segment bar chart
• Top sub-categories
• Profit margin by sub-category
• Ship mode as a donut
• Discount vs profit as a scatter plot
• Yearly revenue and profit as grouped bars
• A US state choropleth map
• Days to ship by mode
• A month by year heatmap
• A top 10 products table

Every one is drawn with Plotly and shown with st.plotly_chart(fig, use_container_width=True). Once you see one chart done, the others are variations. I found that reassuring. The pattern is: group the data with Pandas, pass it to Plotly, hand the figure to Streamlit.

Filters

The sidebar has six filters: year, quarter, region, segment, category and ship mode. There is also an order date range. All are multiselects, and the data is cut down with a single boolean mask:

mask = (
    df['Year'].isin(sel_years) &
    df['Quarter'].isin(sel_quarters) &
    df['Region'].isin(sel_regions) &
    df['Segment'].isin(sel_segments) &
    df['Category'].isin(sel_categories) &
    df['Ship_Mode'].isin(sel_ship)
)

Then fdf = df[mask].copy() becomes the DataFrame every KPI and chart reads from. So changing one filter updates the entire page. This is the core idea of the whole app, and it is just isin() joined with &. There is also a button to download the filtered data as CSV.

What I would try differently

These are my own thoughts as a learner, not criticism of Asha's work.

• Some of the insight card text in the app is typed in as fixed text rather than calculated from the data. I would try generating those lines from the filtered numbers.
• I would experiment with splitting app.py into smaller files, since one script holds all the layout and charts.
• The ETL logic appears twice in a similar form, once in etl_pipeline.py and once in load_data(). I would try to share one function.

I have not built any of these yet. They are on my list for when I start my own project.

Why this was worth studying

Tutorials show you one concept at a time. A finished project shows you how the pieces connect: where cleaning ends, where charts begin, how filters touch everything. Reading someone else's code, with credit, is a fair way to learn.

If you want to explore it, go to Asha's original repository and run the ETL script yourself. If you want to follow what I study and build next, my profile is github.com/Pranaav717.

For a gentler start on the Pandas side, see Pandas for Beginners: Cleaning and Analysing Real-World Data. For the ETL idea in more depth, see Understanding ETL in Python Through a Practical Project.

All code snippets above are from Asha Kalavagunta's project, quoted briefly for learning.