DEV Community: Caelora

When the Network Breaks: A Developer’s View of Mobile and Internet Support

Caelora — Fri, 18 Sep 2026 06:38:08 +0000

When an application stops responding, developers rarely start by saying, "The internet is broken."

They usually ask a series of more specific questions:

Is DNS working? Is the device connected to the network? Can the server be reached? Is the request being rejected? Is there packet loss? Did the service itself fail?

The same mindset can be applied to everyday mobile and internet problems.

From a user's perspective, a failed connection may simply look like "no internet." Technically, however, there are several layers between a device and the service it is trying to reach. Understanding those layers can make troubleshooting much more systematic.

Think in Layers

A useful way to troubleshoot connectivity is to work from the lowest layer upward.

Consider a smartphone trying to access a website.

First, the device needs a connection to a mobile network or Wi-Fi network. The network then needs to provide an IP configuration. DNS may be required to translate a domain name into an IP address. Finally, the device needs to establish a connection to the destination server.

A failure at any one of these stages can produce a similar symptom: the website does not load.

This is why randomly changing settings is usually less effective than testing each layer independently.

Start With the Client

The client device should normally be the first thing to investigate.

Check whether Wi-Fi or mobile data is enabled. Verify that the device recognizes the SIM card or wireless network. Restarting the network interface, enabling Airplane Mode temporarily, or rebooting the device can eliminate temporary state-related problems.

Developers use a similar principle when debugging applications: establish whether the problem can be reproduced consistently.

If one device cannot connect while another device on the same network works normally, the problem is less likely to be a complete network outage.

That distinction is valuable.

Separate Connectivity From Service Availability

A common troubleshooting mistake is assuming that an application failure automatically means the network is down.

Imagine a phone connected to Wi-Fi but unable to open one particular website. Other websites work normally.

The network connection itself may be fine.

The problem could instead involve DNS resolution, the destination server, TLS negotiation, routing, or the application service.

The same logic applies to mobile networks.

If calls work but mobile data does not, the problem is different from a complete loss of cellular connectivity. If only one application fails while everything else works, investigating the application may make more sense than changing network settings.

Use Observable Symptoms

In software engineering, observability is built around signals such as logs, metrics, and traces.

Users do not normally have access to infrastructure-level telemetry, but they can still collect useful observations.

For example:

When did the failure start?
Does it happen continuously or intermittently?
Does it affect one device or multiple devices?
Does switching between Wi-Fi and mobile data change the result?
Are calls and SMS still working?
Does restarting the device temporarily fix it?

These observations effectively become a small incident report.

Instead of reporting "my internet is broken," a user can provide information that helps narrow down the failure domain.

When Self-Service Is Not Enough

Technical troubleshooting eventually reaches a boundary where the user cannot inspect the underlying infrastructure.

A mobile customer cannot directly inspect a carrier's radio network, subscriber database, or backend provisioning system. A home internet customer cannot access the provider's access network or authentication infrastructure.

This is where customer support becomes an important part of the technical workflow.

For example, someone searching for information about how to contact Indosat may simply need the correct support channel after local troubleshooting has failed.

The same applies to home broadband services. A user experiencing a persistent connection failure can check information about how to contact IndiHome 147 before reporting the incident.

For IM3 users, a reference covering how to contact an IM3 operator can serve a similar purpose.

The links are not the troubleshooting process itself. They are the next step when the failure moves beyond what can be diagnosed from the client side.

Treat Support Tickets Like Incident Reports

There is an interesting similarity between customer support and incident management.

A good support request contains enough information for another person to reproduce or investigate the problem.

A useful report might look like this:

Issue: Mobile data unavailable

Started: 10:30 UTC
Device: Android smartphone
Network: Mobile data
Calls: Working
SMS: Working
Data: Not working
Location: Same location where service normally works
Restarted: Yes
Airplane Mode test: Yes
SIM tested in another device: Yes

This is much more useful than a vague description.

The support team can now investigate specific possibilities instead of starting from zero.

Build a Troubleshooting Decision Tree

The entire process can be simplified into a decision tree:

Connection unavailable
        |
        v
Is the device connected?
   /             \
 No               Yes
 |                 |
Check Wi-Fi/     Test another
mobile settings  service
                   |
                   v
          Is everything affected?
             /            \
           Yes             No
            |               |
      Check network       Check the
      or provider         application

The exact decision tree will vary depending on the technology, but the principle remains the same: eliminate possibilities one at a time.

Final Thoughts

Connectivity problems are often treated as simple consumer issues, but they can be surprisingly complex underneath the surface.

A single failed webpage request can involve the device, wireless network, IP configuration, DNS, routing, security protocols, and the destination service.

Thinking like a developer helps turn an unclear problem into a sequence of testable questions.

And when the failure exists beyond the client side, good customer support provides the bridge between the user's observations and the provider's infrastructure.

That combination—structured troubleshooting, useful observations, and reliable support channels—is what makes technical problems easier to diagnose and resolve.

7 Git Commands I Use Every Single Day

Caelora — Tue, 28 Jul 2026 03:50:33 +0000

Git has hundreds of commands, but honestly, I only use a handful of them every day. These commands cover almost everything I need—from checking changes to syncing with remote repositories.

Here are my daily essentials.

1. `git status`

This is probably the command I run the most.

Before doing anything, I always check the current state of my repository.

git status

It tells me:

Which files have changed
What's staged
What's untracked
Which branch I'm on

2. `git diff`

One habit that has saved me from countless mistakes is reviewing the actual changes before committing.

git diff

If I've already staged files, I'll use:

git diff --staged

Seeing the exact lines that changed helps catch accidental edits before they become part of the commit history.

3. `git add`

Once everything looks good, I stage the files.

git add .

Or, if I only want specific files:

git add src/app.js

4. `git commit`

Every commit should explain why the change exists.

git commit -m "Fix login validation"

Small, focused commits make debugging and code reviews much easier.

5. `git pull`

Before starting new work, I make sure my local branch is up to date.

git pull

This reduces merge conflicts later.

6. `git push`

Once everything is ready:

git push

Simple, but one of the most satisfying commands after finishing a feature.

7. `git log --oneline`

Need to quickly review recent commits?

git log --oneline

It's much cleaner than the default log and gives a quick overview of project history.

Final Thoughts

You don't need to memorize every Git command to be productive.

For me, these seven commands handle about 95% of my day-to-day Git workflow:

git status
git diff
git diff --staged
git add
git commit
git pull
git push
git log --oneline

I'm always curious to learn new workflows, though.

What's one Git command you use every day that you think more developers should know?

Pls find me at callcenterno.vip

My Side Projects Started Growing After I Stopped Waiting for "Perfect"

Caelora — Sun, 26 Jul 2026 01:31:20 +0000

I used to spend more time planning projects than actually building them.

I'd think about the tech stack.

The database.

Authentication.

Folder structure.

CI/CD.

Docker.

Kubernetes.

Monitoring.

By the time I finished planning...

I was already tired.

The project never even started.

Then I tried something different

One weekend I gave myself a simple rule.

Build something that works in one day.

No fancy architecture.

No microservices.

No "future-proof" decisions.

Just make it work.

That project was ugly.

The UI wasn't great.

The code wasn't perfect.

But people actually used it.

Shipping teaches things tutorials don't

When real users start clicking your app, you notice problems that never appear in toy projects.

Your loading state is confusing.

Your error messages make no sense.

Someone tries something you never expected.

And suddenly you're solving real problems instead of imaginary ones.

Perfection is expensive

I've realized perfection has a hidden cost.

Every extra day polishing an unreleased project is another day without feedback.

You don't know if people even want your idea.

You're optimizing for users that don't exist yet.

My new workflow

Now I ask myself only three questions before starting:

Does it solve one problem?
Can I build it this weekend?
Can someone use it on Monday?

If the answer is yes...

I start coding.

Everything else can wait.

Funny enough...

The projects I spent months planning never launched.

The projects I built in a weekend are the ones still online today.

Not because they're better.

Because they actually exist.

Final thoughts

Your first version isn't supposed to impress people.

It's supposed to teach you something.

You can always improve software that exists.

You can't improve software that's still inside your notebook.

I Stopped Chasing AI Frameworks and Started Building with Plain APIs

Caelora — Sun, 26 Jul 2026 01:26:45 +0000

When I first got into AI development, I thought I needed to learn every new framework that appeared on GitHub.

LangChain.
CrewAI.
AutoGen.
LangGraph.
LlamaIndex.

Every week, there seemed to be another library promising to make AI agents easier.

I kept bookmarking repositories instead of actually building anything.

Eventually, I decided to ignore all of them for a weekend.

Instead, I opened the OpenAI API documentation and started from scratch.

The surprising part

The first chatbot I built was around 60 lines of code.

Adding conversation history wasn't difficult.

Calling a weather API wasn't difficult.

Generating structured JSON wasn't difficult either.

Suddenly I realized something:

Most AI frameworks aren't introducing new capabilities—they're packaging patterns that you can learn yourself.

That realization completely changed how I approached AI projects.

Frameworks aren't the enemy

Don't get me wrong.

Frameworks are useful.

They solve repetitive problems.

They standardize workflows.

They save time once your project grows.

The problem is when beginners mistake the framework for the technology.

It's like learning React before understanding JavaScript.

Or learning Kubernetes before understanding Docker.

You'll eventually hit a wall because you never learned the fundamentals.

What every beginner should build first

Before touching any AI framework, I'd recommend building these yourself:

A basic chatbot
Conversation memory
Function/tool calling
Streaming responses
JSON structured outputs
A simple RAG app
A tiny agent loop

None of these require thousands of lines of code.

Most can be built in an afternoon.

Why this matters

When something breaks inside a framework, you'll know why.

When a model behaves strangely, you'll understand where the prompt lives.

When tokens get expensive, you'll know exactly what's consuming them.

And when a new framework becomes popular next month...

...you'll learn it in hours instead of weeks.

Final thought

The AI ecosystem moves incredibly fast.

Frameworks will come and go.

APIs will change.

Model names will change.

But understanding the fundamentals will always be valuable.

Sometimes the fastest way to learn isn't by installing another dependency.

It's by writing one more file from scratch.

Why Every Developer Should Learn Docker (Even for Small Projects)

Caelora — Fri, 24 Jul 2026 07:17:26 +0000

Why Every Developer Should Learn Docker (Even for Small Projects)

If you've ever heard someone say, "It works on my machine," you've already encountered one of the biggest problems in software development.

Different operating systems, dependency versions, and local configurations can make the same project behave differently across computers.

That's exactly the problem Docker was built to solve.

What Is Docker?

Docker is a platform that packages your application together with everything it needs to run:

Programming language runtime
Dependencies
Libraries
Environment variables
System tools

Instead of telling someone how to set up your project, you simply share a Docker image or a Docker Compose file.

If Docker runs, your application runs too.

Why I Started Using Docker

When I first learned web development, setting up a new project was frustrating.

Sometimes I needed:

Node.js 18
PostgreSQL 15
Redis
MongoDB

Installing everything manually often caused version conflicts.

After switching to Docker, setting up a project became much easier.

Instead of spending 30 minutes configuring my environment, I could start everything with one command.

docker compose up

That's it.

A Simple Example

Imagine you're building a Node.js API.

Without Docker, every team member has to install:

Node.js
npm
PostgreSQL
Environment variables

With Docker, everyone uses the same environment.

A basic Dockerfile looks like this:

FROM node:20

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Now anyone can run the application without worrying about different Node.js versions.

Docker Compose Makes It Better

Real applications usually need more than one service.

For example:

Backend API
Database
Redis cache

Docker Compose lets you start everything together.

services:
  app:
    build: .

  database:
    image: postgres:16

Instead of opening multiple terminals and starting services manually, one command launches the entire stack.

Benefits I've Noticed

After using Docker regularly, I noticed several improvements.

Faster onboarding

New developers can run a project within minutes.

Fewer environment issues

No more "works on my machine" conversations.

Cleaner computer

I don't have dozens of database installations and conflicting versions anymore.

Easier deployment

The same container used during development can often be deployed to production with minimal changes.

Is Docker Difficult?

At first, yes.

The documentation introduces many concepts:

Images
Containers
Volumes
Networks
Compose

It can feel overwhelming.

But once you understand the difference between an image and a container, everything starts to make sense.

You don't need to master every Docker feature on day one.

Learn the basics first.

Should Beginners Learn Docker?

Absolutely—but not immediately.

If you're just starting programming, focus on learning:

Variables
Functions
Loops
APIs
Databases

Once you've built a few projects, Docker becomes much easier to appreciate because you'll understand the problems it solves.

Final Thoughts

Docker isn't just for large companies or DevOps engineers.

Even small personal projects benefit from having a consistent development environment.

If you're tired of installation issues, dependency conflicts, or spending too much time configuring projects, Docker is worth learning.

It may have a learning curve, but it's one of the best investments you can make as a developer.

Are you already using Docker in your projects, or are you planning to learn it? I'd love to hear your experience in the comments.

5 Git Commands Every Developer Should Know

Caelora — Fri, 24 Jul 2026 07:13:49 +0000

5 Git Commands Every Developer Should Know

Git is one of the most important tools every developer uses, yet many people only know a few basic commands.

Learning a handful of additional Git commands can save time, reduce mistakes, and make collaboration much easier.

Here are five Git commands I use almost every day.

1. Check What Changed

Before committing anything, always check your changes.

git status

This command shows:

Modified files
New files
Deleted files
Files ready to commit

Running git status before every commit is a good habit.

2. View Your Commit History

Need to know what happened recently?

git log --oneline

Instead of showing long commit details, this command displays a clean, compact history.

Example:

f82d4f1 Fix login bug
1ab8c72 Update README
8ce44f0 Add authentication

It's much easier to read than the default output.

3. Create a New Branch

Never work directly on the main branch.

Create a feature branch instead.

git checkout -b feature/login

Or, with newer Git versions:

git switch -c feature/login

This keeps your work isolated until it's ready to merge.

4. Undo Staged Changes

Accidentally added the wrong file?

git restore --staged filename.js

This removes the file from the staging area without deleting your changes.

It's much safer than trying to fix mistakes later.

5. Pull Before You Push

Before pushing your code, make sure your local branch is up to date.

git pull origin main

This helps avoid unnecessary merge conflicts and ensures you're working with the latest code.

Bonus Tip

If you forget a command, Git has built-in help.

git help <command>

For example:

git help commit

The documentation is surprisingly helpful.

Final Thoughts

You don't need to memorize every Git command.

Mastering a small set of frequently used commands will make your daily workflow smoother and reduce common mistakes.

The five commands I recommend every beginner learns are:

git status
git log --oneline
git switch -c
git restore --staged
git pull

Once you're comfortable with these, learning more advanced Git features becomes much easier.

Which Git command do you use the most? Let me know in the comments!

Stop Using console.log Everywhere: Better Ways to Debug JavaScript

Caelora — Fri, 24 Jul 2026 07:03:37 +0000

Stop Using `console.log()` Everywhere: Better Ways to Debug JavaScript

If you're learning JavaScript, you've probably written something like this hundreds of times:

console.log(data);
console.log(user);
console.log(response);
console.log(error);

There's absolutely nothing wrong with using console.log(). Every developer starts there, and even experienced developers still use it.

However, as your application grows, relying only on console.log() can make debugging slower and your code harder to maintain.

Here are several debugging techniques that can save you time and make your development workflow much more efficient.

1. Use the Browser Debugger

Instead of printing every variable, use the built-in JavaScript debugger.

function calculateTotal(items) {
  debugger;

  return items.reduce((sum, item) => sum + item.price, 0);
}

When execution reaches the debugger statement, the browser pauses your application. You can inspect variables, check the call stack, and execute code step by step.

This is much more powerful than printing dozens of log statements.

2. Display Objects with `console.table()`

Large arrays of objects quickly become difficult to read.

Instead of:

console.log(users);

Use:

console.table(users);

The output becomes a clean table that's much easier to understand.

This works especially well for:

API responses
Product lists
User records
Database results

3. Organize Logs with `console.group()`

If your application produces many log messages, grouping them makes the console much cleaner.

console.group("Login Process");

console.log("Checking credentials...");
console.log("Loading user...");
console.log("Authentication successful");

console.groupEnd();

Now related messages stay together, making debugging much easier.

4. Measure Performance

Need to know how long a function takes?

console.time("fetchUsers");

await fetchUsers();

console.timeEnd("fetchUsers");

This instantly tells you how long an operation required without installing additional tools.

5. Take Advantage of Breakpoints

Modern browsers include excellent debugging tools.

Simply click beside a line number in Chrome or Firefox DevTools to create a breakpoint.

When execution stops, you can:

Inspect variables
View the call stack
Execute code manually
Step through your application line by line

For complex bugs, breakpoints are often much faster than adding dozens of log statements.

6. Read Error Messages Carefully

Many developers immediately search Google after seeing an error.

Instead, spend a few seconds reading it.

Most JavaScript errors already tell you:

Which file caused the problem
The line number
The type of error
The function where it happened

Understanding error messages is a skill that will dramatically improve your debugging speed.

7. Clean Up Before Deploying

We've all forgotten to remove debugging code.

console.log("HERE");
console.log("TEST");
console.log("WHY IS THIS UNDEFINED?");

Before pushing your code to production:

Remove unnecessary console.log() calls.
Delete forgotten debugger statements.
Keep only meaningful error logging where appropriate.

A clean codebase is much easier to maintain.

Final Thoughts

console.log() isn't bad—it remains one of the simplest and fastest debugging tools available.

But combining it with browser DevTools, breakpoints, console.table(), and performance timers can significantly improve your workflow.

As your projects become larger and more complex, learning these debugging techniques will save you hours of frustration.

What debugging technique do you use most often? Share your favorite tips in the comments!

7 VS Code Extensions I Install on Every New Computer

Caelora — Fri, 24 Jul 2026 06:57:51 +0000

7 VS Code Extensions I Install on Every New Computer

Every time I reinstall Windows or buy a new laptop, the first application I install is Visual Studio Code. But VS Code alone isn't enough. The real productivity boost comes from its extensions.

After years of web development, I've narrowed my list down to seven extensions that I install immediately. These extensions save time, improve code quality, and make development much more enjoyable.

1. Prettier

Nobody likes arguing about code formatting.

Prettier automatically formats your code every time you save, keeping your project clean and consistent.

Why I use it

Consistent formatting
Works with almost every language
Saves time during code reviews

"editor.formatOnSave": true

2. ESLint

ESLint catches mistakes before they become bugs.

Instead of discovering issues after deployment, you'll see warnings directly in your editor.

It also helps enforce coding standards across your team.

3. GitLens

GitLens makes Git much easier to understand.

With one hover, you can instantly see:

Who changed a line
When it was changed
Why it was changed

This is incredibly useful when working on large projects.

4. Error Lens

Normally, VS Code shows errors at the bottom of the screen.

Error Lens displays them directly beside your code, making debugging much faster.

Small extension, huge productivity boost.

5. Auto Rename Tag

If you're working with HTML, React, or Vue, this extension is a lifesaver.

Rename an opening tag...

<div>

...and the closing tag updates automatically.

</div>

No more broken markup.

6. Path Intellisense

Import paths can become annoying in large projects.

Instead of typing long file paths manually, this extension autocompletes them for you.

It's simple but saves countless keystrokes every day.

7. Thunder Client

Sometimes you don't want to open Postman just to test one API endpoint.

Thunder Client lives inside VS Code and lets you:

Send HTTP requests
Test REST APIs
Organize collections

Perfect for backend developers.

Final Thoughts

VS Code is already a fantastic editor, but the right extensions can dramatically improve your workflow.

If I had to choose only three, they would be:

Prettier
ESLint
GitLens

Those three alone eliminate many common development headaches.

What VS Code extension can't you live without? Let me know in the comments!

DEV Community: Caelora

When the Network Breaks: A Developer’s View of Mobile and Internet Support

Think in Layers

Start With the Client

Separate Connectivity From Service Availability

Use Observable Symptoms

When Self-Service Is Not Enough

Treat Support Tickets Like Incident Reports

Build a Troubleshooting Decision Tree

Final Thoughts

7 Git Commands I Use Every Single Day

1. git status

2. git diff

3. git add

4. git commit

5. git pull

6. git push

7. git log --oneline

Final Thoughts

My Side Projects Started Growing After I Stopped Waiting for "Perfect"

Then I tried something different

Shipping teaches things tutorials don't

Perfection is expensive

My new workflow

Funny enough...

Final thoughts

I Stopped Chasing AI Frameworks and Started Building with Plain APIs

The surprising part

Frameworks aren't the enemy

What every beginner should build first

Why this matters

Final thought

Why Every Developer Should Learn Docker (Even for Small Projects)

Why Every Developer Should Learn Docker (Even for Small Projects)

What Is Docker?

Why I Started Using Docker

A Simple Example

Docker Compose Makes It Better

Benefits I've Noticed

Faster onboarding

Fewer environment issues

Cleaner computer

Easier deployment

Is Docker Difficult?

Should Beginners Learn Docker?

Final Thoughts

5 Git Commands Every Developer Should Know

5 Git Commands Every Developer Should Know

1. Check What Changed

2. View Your Commit History

3. Create a New Branch

4. Undo Staged Changes

5. Pull Before You Push

Bonus Tip

Final Thoughts

Stop Using console.log Everywhere: Better Ways to Debug JavaScript

Stop Using console.log() Everywhere: Better Ways to Debug JavaScript

1. Use the Browser Debugger

2. Display Objects with console.table()

3. Organize Logs with console.group()

4. Measure Performance

5. Take Advantage of Breakpoints

6. Read Error Messages Carefully

7. Clean Up Before Deploying

Final Thoughts

7 VS Code Extensions I Install on Every New Computer

7 VS Code Extensions I Install on Every New Computer

1. Prettier

2. ESLint

3. GitLens

4. Error Lens

5. Auto Rename Tag

6. Path Intellisense

7. Thunder Client

Final Thoughts

1. `git status`

2. `git diff`

3. `git add`

4. `git commit`

5. `git pull`

6. `git push`

7. `git log --oneline`

Stop Using `console.log()` Everywhere: Better Ways to Debug JavaScript

2. Display Objects with `console.table()`

3. Organize Logs with `console.group()`