DEV Community: Caelora

What I Check Before Deploying a Website to Production

Caelora — Tue, 29 Sep 2026 02:53:28 +0000

What I Check Before Deploying a Website to Production

Deploying a website can feel like the finish line.

The code works.
The pages look right.
The buttons respond.
The tests are passing.

Then you deploy it and discover that something important was missed.

Maybe an environment variable wasn't configured. Maybe the production database is using the wrong connection. Maybe a redirect is broken. Or maybe the website works perfectly on your machine but behaves differently on the server.

Over time, I've found that a simple pre-deployment checklist can prevent a lot of unnecessary problems.

Here are some of the things worth checking before pushing a website into production.

1. Check Environment Variables

Never assume the production environment is identical to your local machine.

Things like these should be checked before deployment:

DATABASE_URL
API_KEY
APP_URL
NODE_ENV
SECRET_KEY

Make sure production values are actually configured and that sensitive credentials aren't accidentally committed to Git.

A .env file sitting inside a repository is an easy mistake to make.

Before committing, check:

git status
git diff

It's also worth reviewing .gitignore and making sure environment files are excluded when appropriate.

2. Test the Production Build

A development environment can hide problems.

For example, a JavaScript application may work perfectly with:

npm run dev

but fail during the production build.

Run the actual build process locally:

npm run build

Then test the generated application as close to the production environment as possible.

This can reveal issues involving:

Missing dependencies
Invalid imports
Environment variables
Build configuration
Case-sensitive file paths
Unused or incompatible packages

Finding these problems before deployment is much easier than finding them from a user's report.

3. Check Database Changes

Database migrations deserve extra attention.

If the application requires a new column, table, index, or constraint, make sure the migration is included in the deployment process.

For example:

Application v1
    ↓
Database v1

Application v2
    ↓
Database v2

Deploying the new application without applying the corresponding database changes can cause unexpected errors.

It's also important to think about backwards compatibility.

During a deployment, there may be a short period where old application code and new database structures interact.

A migration strategy should account for that.

4. Don't Forget Error Handling

Users shouldn't see raw exceptions or database errors.

Instead of exposing something like:

SQLSTATE[HY000]: General error...

the application should provide a useful response while logging the technical details internally.

For example:

Something went wrong.

Please try again in a few moments.

At the same time, developers should still have enough information in the logs to diagnose the actual problem.

Good error handling has two audiences:

Users need clarity.

Developers need details.

Those don't have to be the same message.

5. Check Logs

A deployment isn't finished just because the server says it succeeded.

Check the logs afterward.

Depending on your stack, that could mean looking at:

docker logs

or:

journalctl

or application-specific logs.

Look for:

Repeated errors
Database connection failures
Authentication problems
Missing environment variables
Timeout errors
Unexpected HTTP status codes

A successful deployment pipeline only tells you that the deployment process completed.

It doesn't necessarily tell you that users are having a good experience.

6. Test Important User Flows

Don't test every tiny detail manually.

Instead, identify the flows that would cause the biggest problems if they stopped working.

For example:

Homepage
   ↓
Login
   ↓
Dashboard
   ↓
Create item
   ↓
Save
   ↓
Logout

For an e-commerce website, that might be:

Product
   ↓
Cart
   ↓
Checkout
   ↓
Payment
   ↓
Confirmation

These critical paths deserve extra attention after deployment.

7. Check HTTPS

Make sure the production website is actually using HTTPS.

Open the website manually and check:

https://example.com

Then test the HTTP version:

http://example.com

If HTTP is supposed to redirect to HTTPS, verify that it actually does.

Also check for mixed-content problems where an HTTPS page attempts to load insecure HTTP resources.

Browsers may block those resources or display security warnings.

8. Check DNS

DNS problems can make a perfectly deployed website appear completely broken.

Before or immediately after deployment, verify:

A record
AAAA record
CNAME
MX records
TXT records

depending on what the project requires.

For example, if you're moving a website to a new server, the web server might be configured correctly while the domain still points to the old IP address.

That's not an application bug.

It's simply a DNS issue.

9. Test From Outside Your Network

Something working on your own computer doesn't necessarily mean it's working globally.

If possible, test the website using:

Mobile data
Another Wi-Fi connection
A different device
An external monitoring service

This can expose DNS caching issues, firewall rules, CDN configuration problems, or IP restrictions that aren't visible from your development environment.

10. Check Permissions

File and directory permissions can cause strange production-only problems.

The application may need access to:

uploads/
cache/
storage/
logs/

But giving everything 777 isn't a proper solution.

Instead, understand which user actually runs the application and grant only the permissions it needs.

The principle is simple:

Give the application enough permission to work, but not more than necessary.

This becomes especially important when the application handles uploaded files or user-generated content.

11. Test Backups

Having a backup system is different from having a backup system that actually works.

Before relying on backups, verify that you can restore them.

For a database, a backup might look like:

mysqldump database_name > backup.sql

But the important question isn't whether the file exists.

The important question is:

Can you restore the application from it?

A backup that has never been tested is still an assumption.

12. Check Monitoring

Once the website is live, you need a way to know when something breaks.

At minimum, monitor important things such as:

Uptime
HTTP errors
Server resources
Database availability
Disk usage
Application errors

You don't necessarily need an elaborate monitoring stack for a small project.

Even a simple uptime monitor can be useful.

The goal is to discover problems before users start reporting them.

13. Have a Rollback Plan

This is one of the most overlooked parts of deployment.

Before deploying a significant change, know how you would go back.

For example:

Current version
      ↓
Backup
      ↓
Deploy new version
      ↓
Something breaks
      ↓
Rollback

Without a rollback plan, a small production bug can turn into a long debugging session.

With a rollback plan, you can restore the previous working version first and investigate the problem afterward.

14. Keep the Checklist Small

A deployment checklist doesn't need to contain 100 items.

If it's too complicated, people eventually stop using it.

A small project might only need:

[ ] Production build works
[ ] Environment variables checked
[ ] Database migration completed
[ ] HTTPS working
[ ] Critical user flow tested
[ ] Logs checked
[ ] Backup available
[ ] Rollback available

The exact checklist should depend on the project.

A personal side project doesn't need the same process as a financial application serving millions of users.

Final Thoughts

Deployment is not just the moment when code moves from your computer to a server.

It's a transition from an environment you control completely to an environment where real users, real data, network problems, unexpected traffic, and unexpected behavior become part of the equation.

A short checklist can catch many problems before they become incidents.

The goal isn't to make deployment complicated.

It's to make deployment predictable.

When you know what needs to be checked, you can spend less time worrying about what might have gone wrong and more time building the next thing.

Why Technical SEO Still Matters for Developer-Built Websites

Caelora — Tue, 29 Sep 2026 02:50:03 +0000

When developers build a website, the first priorities are usually performance, functionality, security, and user experience.

Search engines often come later.

That is understandable. A website can work perfectly from a developer's perspective while still having problems that make it difficult for search engines to discover, crawl, understand, or index its content.

This is where technical SEO becomes useful.

Technical SEO isn't about stuffing keywords into a page or writing content specifically for search engines. At its core, it's about making sure a website can be properly accessed and understood by both users and search engine crawlers.

A Fast Website Isn't Automatically SEO-Friendly

Performance matters, but speed is only one part of the equation.

A website can load quickly and still have problems such as:

Important pages aren't internally linked.
Pages are blocked by robots.txt.
Canonical URLs are incorrect.
The sitemap contains URLs that shouldn't be indexed.
JavaScript prevents important content from being rendered properly.
Multiple URL versions point to the same content.
Pages return unexpected HTTP status codes.

These problems aren't always obvious when you're browsing the website manually.

For example, you might open a page in Chrome and everything looks completely normal. However, a crawler could encounter a different experience depending on how the site delivers its HTML, JavaScript, redirects, and metadata.

That's why technical SEO should be considered part of website development rather than something added after launch.

Start With Crawlability

Before worrying about rankings, make sure search engines can actually discover your pages.

One of the simplest things to check is the robots.txt file.

A basic example might look like this:

User-agent: *
Disallow:

Sitemap: https://example.com/sitemap.xml

The exact configuration depends on the website.

The important thing is understanding what you're allowing and blocking.

An accidental rule such as:

User-agent: *
Disallow: /

can prevent crawlers from accessing the entire website.

This kind of mistake is surprisingly easy to make during development or when migrating a website.

Don't Ignore Internal Linking

Internal links are useful for users, but they also help crawlers discover relationships between pages.

Imagine a website with 500 articles.

If most of those articles aren't connected through internal links, some pages may be difficult to discover even though they're technically published.

A simple structure might look like:

Homepage
   |
   +-- Category
         |
         +-- Article A
         +-- Article B
         +-- Article C

You can then connect related articles where it makes sense:

Article A → Article B
Article B → Article C
Article C → Article A

This doesn't mean every page needs dozens of links.

The goal is to create a logical navigation structure where important content isn't isolated.

Use Canonical URLs Carefully

Duplicate or near-duplicate URLs can create unnecessary confusion.

For example, a website might accidentally expose the same content through:

https://example.com/article
https://example.com/article/
https://www.example.com/article
http://example.com/article

Not every URL variation will necessarily be indexed, but having a clear preferred version makes the site's structure easier to manage.

A canonical tag can communicate the preferred URL:

<link rel="canonical" href="https://example.com/article">

However, canonical tags aren't magic.

They should match the actual URL structure and should be implemented consistently.

If your site has complicated URL rules, it's worth testing them instead of assuming everything is working correctly.

XML Sitemaps Are Simple but Useful

An XML sitemap provides search engines with a list of URLs that you consider important.

A basic sitemap might contain:

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

  <url>
    <loc>https://example.com/</loc>
  </url>

  <url>
    <loc>https://example.com/about/</loc>
  </url>

  <url>
    <loc>https://example.com/article/</loc>
  </url>

</urlset>

A sitemap doesn't guarantee indexing.

It simply makes URL discovery easier.

This distinction is important.

Submitting thousands of URLs to a sitemap doesn't mean all of them deserve to be indexed. A sitemap should generally contain URLs that are useful, accessible, canonical, and intended for search visibility.

Watch Your HTTP Status Codes

Developers already know that HTTP status codes matter.

SEO adds another reason to pay attention to them.

A page that has permanently moved should generally use a 301 redirect.

A page that doesn't exist should normally return a 404.

A temporary problem might result in a 5xx response.

Problems appear when a website accidentally returns the wrong status.

For example, a custom "Page Not Found" page that returns HTTP 200 can create what's commonly called a soft 404.

The browser may display a friendly error message, but technically the server is telling crawlers:

This page exists.

That mismatch can create unnecessary crawling and indexing issues.

JavaScript Can Change the Equation

Modern websites increasingly rely on JavaScript frameworks.

React, Vue, Angular, and other technologies can produce excellent user experiences.

But developers should still consider how important content is delivered to crawlers.

For critical content, it's useful to understand whether the content exists in the initial HTML, requires JavaScript execution, or is loaded later through API requests.

This doesn't mean JavaScript websites can't perform well in search.

It means developers should understand the rendering process.

A useful test is to inspect the actual HTML delivered to the browser rather than looking only at the final visual result.

Don't Forget Mobile

Most modern websites are designed with mobile users in mind, but responsive design alone isn't enough.

Check things such as:

Text readability
Navigation
Button spacing
Horizontal scrolling
Page performance
Images
Layout shifts
Forms and interactive elements

A page can technically be responsive while still being frustrating to use on a small screen.

Good technical SEO and good UX often overlap here.

SEO Tools Are Useful for Developers

You don't need to spend hours staring at search results to find technical problems.

Tools such as Google Search Console can reveal useful information about indexing, crawling, search queries, and page issues.

For larger websites, automated crawlers can also help identify broken links, redirect chains, duplicate metadata, missing tags, and other structural problems.

Third-party SEO services can be useful when a project needs a broader audit or when the development team doesn't have time to investigate every technical detail. For example, a service such as seoservices1.com can be considered when you need external SEO support rather than handling every part of the process internally.

The important part is knowing what problem you're trying to solve before choosing a tool or service.

SEO Should Be Part of the Development Process

One of the easiest mistakes is treating SEO as a final checklist.

Build the website.

Launch it.

Then think about SEO.

A better approach is to include basic SEO considerations during development.

Before launch, check:

[ ] HTTPS works correctly
[ ] Preferred domain is consistent
[ ] Robots.txt is configured
[ ] XML sitemap exists
[ ] Important pages are crawlable
[ ] Canonical URLs are correct
[ ] Internal links work
[ ] Broken links have been checked
[ ] Redirects work correctly
[ ] 404 pages return the correct status
[ ] Mobile layout works
[ ] Important content is accessible
[ ] Page performance has been tested

None of these steps guarantees high rankings.

That's not what technical SEO is supposed to do.

The purpose is to remove unnecessary technical obstacles so that useful content has a better chance of being discovered, processed, and presented to users.

Final Thoughts

Developers don't need to become full-time SEO specialists.

But understanding the technical side of search can prevent a lot of avoidable problems.

A well-built website should not only work when someone opens it in a browser. Its structure should also make sense to crawlers, users, and future developers who have to maintain it.

The best SEO implementation is often the one you barely notice because it has been built into the website from the beginning.

Performance, accessibility, clean URLs, logical navigation, crawlability, and useful content are not separate worlds.

They are all parts of building a website that works well.

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

What I Check Before Deploying a Website to Production

What I Check Before Deploying a Website to Production

1. Check Environment Variables

2. Test the Production Build

3. Check Database Changes

4. Don't Forget Error Handling

5. Check Logs

6. Test Important User Flows

7. Check HTTPS

8. Check DNS

9. Test From Outside Your Network

10. Check Permissions

11. Test Backups

12. Check Monitoring

13. Have a Rollback Plan

14. Keep the Checklist Small

Final Thoughts

Why Technical SEO Still Matters for Developer-Built Websites

A Fast Website Isn't Automatically SEO-Friendly

Start With Crawlability

Don't Ignore Internal Linking

Use Canonical URLs Carefully

XML Sitemaps Are Simple but Useful

Watch Your HTTP Status Codes

JavaScript Can Change the Equation

Don't Forget Mobile

SEO Tools Are Useful for Developers

SEO Should Be Part of the Development Process

Final Thoughts

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

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()`