30 Days of Machine Learning & AI: Day 1 — Building Like the Industry

Today marks the beginning of my 30-Day Machine Learning & AI Sprint, where my goal isn't just to train models but to learn how to build production-ready machine learning systems the way they're built in real companies.

One thing I've noticed is that many ML tutorials jump straight into importing datasets and training models. While that's great for learning algorithms, it often skips the engineering practices that make machine learning projects maintainable, scalable, and deployable.

For this challenge, I want to learn both Machine Learning and Machine Learning Engineering (MLOps). That means every day I'll be documenting not only what I build, but also why things are done a certain way.

Day 1 Goal

The objective for today was simple:

Set up the development environment
Initialize a Git repository
Connect to our first data source
Build the project using an industry-inspired structure

Instead of creating dozens of folders from the start, I chose to create only what I need. This mirrors how many engineering teams work—projects evolve naturally rather than being over-engineered on day one.

Our project structure for Day 1 looks like this:

30_days_of_ML:AI/
└── climatebase-ml-sprint/
    ├── .gitignore
    ├── .env.example
    ├── requirements.txt
    ├── config.py
    └── ingestion/
        ├── __init__.py
        └── api_client.py

It might look small, but every file has a specific purpose.

Why These Files Exist

`.gitignore`

One of the first files I created was .gitignore.

.env
__pycache__/
*.pyc
.venv/

Although it doesn't contribute directly to the application, it's one of the most important files in any software project.

Why ignore `.env`?

The .env file stores sensitive information such as:

API keys
Database credentials
Authentication tokens
Secret configuration values

These should never be pushed to GitHub because anyone with access to the repository could potentially use them.

Instead, we commit a template (.env.example) while keeping the actual secrets local.

Why ignore `pycache/` and `*.pyc`?

When Python executes your code, it automatically compiles it into bytecode files ending in .pyc.

These files are stored inside the __pycache__ folder to speed up future executions.

Since Python generates them automatically, they don't belong in version control and only create unnecessary noise.

Why ignore `.venv/`?

A virtual environment keeps your project's dependencies isolated from your system Python.

This means:

every project can use different package versions
installations won't conflict with one another
anyone can recreate the exact same environment later

Because virtual environments can be recreated at any time, there's no reason to upload them to GitHub.

`requirements.txt`

Every Python project depends on external libraries.

Instead of expecting everyone to install packages manually, we record every dependency inside requirements.txt.

For Day 1 I installed only two packages:

requests
python-dotenv

Then generated the requirements file using:

pip freeze > requirements.txt

Now anyone can reproduce my environment simply by running:

pip install -r requirements.txt

This small file makes projects reproducible across different computers.

`.env.example`

Rather than committing the actual .env file, I created an example version.

OPEN_METEO_BASE_URL=https://api.open-meteo.com/v1
STATION_LATITUDE=9.92
STATION_LONGITUDE=8.89

This tells other developers exactly which environment variables they need without exposing any sensitive information.

It's a simple practice, but one that's used in almost every professional software project.

`config.py`

One thing I wanted to avoid from the beginning was scattering configuration values throughout the codebase.

Instead, I created a single configuration file.

from dotenv import load_dotenv
import os

load_dotenv()

BASE_URL = os.getenv("OPEN_METEO_BASE_URL")
LATITUDE = float(os.getenv("STATION_LATITUDE"))
LONGITUDE = float(os.getenv("STATION_LONGITUDE"))

Now every part of the project imports configuration from one place instead of hardcoding values repeatedly.

As the project grows, this will make maintenance much easier.

The First Module: Data Ingestion

Machine learning begins with data.

To keep things organized, I created an ingestion package.

ingestion/
├── __init__.py
└── api_client.py

The __init__.py file tells Python that this directory should be treated as a package, making it easier to import modules throughout the project.

Inside api_client.py, I wrote my first API client to fetch weather data from the Open-Meteo API.

The client:

connects to the API
sends latitude and longitude
requests hourly weather data
validates the response
returns structured JSON ready for processing

Although it's only a few lines of code, as this is the first code of the machine learning pipeline.

Why I Didn't Create Every Folder Today

Initially, I considered generating the complete project structure with folders for models, APIs, monitoring, dashboards, tests, deployment, and more.

After researching how production teams typically work, I realized something important:

Create folders when you actually need them.

Overbuilding on Day 1 only adds clutter.

Tomorrow's task involves storing data, so that's when folders like data/raw/ and the database modules will naturally be introduced.

The project grows alongside the problem it's solving.

My Biggest Takeaway

Today wasn't about training a machine learning model.

It was about building a solid foundation.

A good project structure won't make your model more accurate, but it will make your code easier to understand, easier to test, easier to deploy, and much easier to maintain months from now.

As this challenge progresses, this small repository will gradually evolve into a complete, end-to-end machine learning system with:

automated data ingestion
feature engineering
model training
experiment tracking
APIs
Docker
CI/CD
monitoring
drift detection
automated retraining
AI agents
Evaluation and testing

Lets see how much it grows over the next 29 days.

What's Next?

Tomorrow's focus is on data ingestion and storage.

We'll connect the weather data pipeline to a database, create our data/raw/ structure, and begin building the data layer that every machine learning system depends on.

catch you all tomorrow.

see you!

Day -01