DAILY NEWS

Stay Ahead, Stay Informed – Every Day

Advertisement
TECH & AI
I got tired of rebuilding my diagnostic USB on every machine, so I fixed it once
jackminion 0



very IT tech I know has the same ritual. New machine lands on the bench, or you’re at a client site, and before you can actually fix anything you spend twenty minutes assembling the same handful of tools. Download this. Extract that. Oh, this one wants .NET. Oh, this box has no internet. Oh, the client’s policy blocks installs.

I did that dance for years. Then I got tired of it and built a portable kit that lives on one USB stick and installs nothing. This post is mostly about what belongs on that stick — because whether you build your own or grab a packaged one, the thinking is the same, and I wish someone had just laid it out for me years ago.

Why “no install” is the whole game

The constraint that shapes everything is this: the machine you’re diagnosing is often the machine you can’t install software on.

Locked-down corporate profiles block installers.A dying machine can’t afford the disk writes or the reboot an installer wants.You don’t want to leave residue on a client’s PC that isn’t yours.Half the time there’s no internet to download anything anyway.

So the rule I settled on: everything runs from the USB, writes nothing to the host, and leaves no trace when I pull the drive. Portable executables and scripts only. If a tool needs to be installed, it doesn’t make the cut.

That one rule kills a lot of otherwise-good tools and forces you toward the portable ecosystem. It’s worth it.

What actually goes on the stick

I think about a diagnostic USB in three buckets. Same three problems, every single call:

System health — “is this machine actually okay?”

Before anything else, you want a fast read on the hardware and OS state:

Disk health — SMART status, because a failing drive explains a lot of “random” symptoms. Catch it before you spend an hour chasing software ghosts.Memory + CPU + temps — a quick snapshot so you know if you’re looking at a resource problem vs. a config problem.Boot and startup bloat — what’s loading at login and dragging the thing down.Windows integrity — a quick way to check for corruption (sfc /scannow and DISM are built in and free, but knowing when to reach for them is the skill).

The goal of this bucket is a 60-second answer to “hardware problem or software problem?” — because that split decides everything you do next.

Network diagnostics — “why won’t this thing connect?”

Half of all tickets are really network tickets wearing a costume. Portable tools I want on hand:

Adapter + IP config at a glance — faster than typing ipconfig /all and squinting.DNS resolution testing — because “the internet is down” is usually “DNS is down.”Connectivity + latency — ping, traceroute, port checks, packaged so you’re not building command lines by hand under pressure.Wi-Fi signal / channel info — for the “it’s slow in this room” calls that are really RF problems.

Built-in Windows commands cover a surprising amount of this (ipconfig, nslookup, ping, tracert, netsh wlan show). The value of a kit is having them wrapped so you’re reading answers, not typing syntax while the client watches.

Profile & user management — “the account is the problem”

This is the bucket people forget until they’re stuck. So much Windows weirdness is really a broken or bloated user profile:

Corrupt profile causing login loops or vanished settings.Profile bloat quietly eating the disk.Needing to move or reset a user’s environment without nuking their data.

Having a portable way to inspect and manage profiles turns a “reimage the whole machine” afternoon into a ten-minute fix more often than you’d think.

Put it on the right USB

Small thing that matters: use a decent USB 3.0+ drive. A slow stick makes portable tools feel broken when they’re just I/O-starved. Label it. Keep a second copy — the day your only diagnostic USB dies is always the day you need it most.

The honest part

You can absolutely build this yourself. Everything I described is assemblable from free portable tools plus commands already baked into Windows. If you enjoy curating your own kit, do that — you’ll learn more.

I got tired of maintaining mine and packaged it up so I stop rebuilding it every time I switch machines: three tools (system health, network diagnostics, profile manager) on one USB, Windows 11, no install, nothing left behind. If you’d rather not assemble your own, it’s here: Portable Windows IT Toolkit ($34, one-time, instant download).

Either way — build it or buy it — the lesson is the same one that took me too long to learn: decide your kit once, standardize on “no install,” and stop rebuilding it on every machine. Your future self, standing at a locked-down PC with no internet, will thank you.



Source link

TECH & AI
Part 2 Building an Authentication System from Scratch – Backend Setup
jackminion 0


User Registration & Secure Password Hashing with bcrypt

In the previous article, we built the backend foundation by setting up Express.js, PostgreSQL, environment variables, and a clean layered architecture.

With the backend ready, it’s time to implement the first authentication feature—User Registration.

Although registration appears straightforward, it involves much more than simply storing user details in a database. A secure registration system must validate user input, prevent duplicate accounts, protect passwords, and ensure that sensitive information is never exposed.

In this article, we’ll build the complete registration workflow while following security best practices.

The registration process follows a layered architecture, where each layer has a single responsibility.

Client
│
▼
Routes
│
▼
Controller
│
▼
Service
│
▼
Repository
│
▼
PostgreSQL

Enter fullscreen mode

Exit fullscreen mode

The overall workflow is:

The client submits the registration form.
The controller receives the request.
The service validates the data.
The repository checks whether the email already exists.
The password is securely hashed using bcrypt.
The user is stored in PostgreSQL.
A success response is returned to the client.

Instead of placing all the registration logic inside the controller, I divided the implementation into three layers.

Controller

Responsible only for:

Receiving the HTTP request
Calling the service layer
Returning the HTTP response

The controller should never contain business logic or database queries.

Service

The service contains the application’s business logic.

For registration, it is responsible for:

Validating the request
Checking whether the email already exists
Hashing the password
Calling the repository to save the user

This layer acts as the brain of the application.

Repository

The repository communicates directly with PostgreSQL.

Its responsibilities include:

Checking if a user already exists
Creating a new user
Executing SQL queries

Keeping SQL isolated inside repositories makes the application easier to maintain and test.

The controller receives the registration request and forwards the data to the service layer.

// Register Controller Screenshot Here

Enter fullscreen mode

Exit fullscreen mode

The controller itself performs very little work.

Its responsibility is simply to:

Extract the request body
Call the service
Return either a success or an error response

This keeps controllers lightweight and easy to understand.

The service contains the actual registration workflow.

// Register Service Screenshot Here

Enter fullscreen mode

Exit fullscreen mode

The registration service performs the following steps:

Check whether the email already exists.
Generate a secure password hash.
Create the user in PostgreSQL.
Return the newly created user.

Because all business rules live inside the service layer, future changes become much easier.

For example, adding email verification later would require changes only inside the service, without affecting controllers or repositories.

The repository is responsible only for database communication.

// Repository Screenshot Here

Enter fullscreen mode

Exit fullscreen mode

Typical repository functions include:

findByEmail()
createUser()

Keeping SQL queries isolated improves readability and keeps the service layer database-agnostic.

One of the biggest mistakes an application can make is storing passwords in plain text.

Imagine a database leak.

If passwords are stored as plain text, every user’s credentials become immediately visible.

Instead, passwords should always be transformed into a secure one-way hash before being stored.

This is exactly why we use bcrypt.

bcrypt is one of the most trusted password hashing libraries available for Node.js.

Unlike encryption, hashing is a one-way operation.

This means:

The original password cannot be recovered.
Even the application itself cannot view the user’s password.
Only password verification is possible.

When a user registers, bcrypt performs several operations internally.

Password
│
▼
Generate Random Salt
│
▼
Password + Salt
│
▼
Multiple Hashing Rounds
│
▼
Store Hash in Database

Enter fullscreen mode

Exit fullscreen mode

Each password receives its own randomly generated salt before hashing.

Because of this:

Two users with the same password will have completely different hashes.
Rainbow table attacks become ineffective.
Brute-force attacks become significantly slower due to bcrypt’s configurable cost factor.

During login, the user enters their password as plain text.

bcrypt then:

Reads the stored hash.
Extracts the embedded salt.
Hashes the entered password using the same salt.
Compares the generated hash with the stored hash.

If both hashes match, the user is successfully authenticated.

const isMatch = await bcrypt.compare(
enteredPassword,
storedHash
);

Enter fullscreen mode

Exit fullscreen mode

One of bcrypt’s biggest advantages is that developers never need to manually manage salts or compare hashes—the library handles the entire verification process securely.

Using bcrypt provides several important security advantages.

✅ Passwords are never stored in plain text.

✅ Every password uses a unique random salt.

✅ Identical passwords generate different hashes.

✅ Brute-force attacks become significantly slower.

✅ Rainbow table attacks are mitigated.

These features make bcrypt one of the industry standards for password protection.

Once the backend implementation was complete, I verified the registration API using Postman.

Request

POST /api/auth/register

Enter fullscreen mode

Exit fullscreen mode

{
“username”: “Sriya”,
“email”: “sriya@gmail.com”,
“password”: “Password123”
}

Enter fullscreen mode

Exit fullscreen mode

Response

{
“success”: true,
“user”: {
“id”: 1,
“username”: “Sriya”,
“email”: “sriya@gmail.com”
}
}

Enter fullscreen mode

Exit fullscreen mode

Notice that the response never includes the password or its hash.

Only non-sensitive user information is returned to the client.

Now that users can securely register and their passwords are safely stored, the next step is allowing them to authenticate.

In the next article, we’ll build the Login Flow, where we’ll:

Verify user credentials
Compare passwords using bcrypt
Generate JWT Access Tokens
Generate Refresh Tokens
Understand how JWT authentication works internally



Source link

TECH & AI
Codex – a.k.a. ChatGPT’s AI Agent
jackminion 0



Codex is OpenAI’s AI coding agent, and ChatGPT is the interface you can use to interact with it. That’s the difference.

As a software engineer, software development has gone through drastic shifts over the decades. We moved from assembly language to high-level programming languages, from waterfall to Agile, from on-premise infrastructure to cloud computing, and from manual deployments to DevOps and continuous delivery.

The next major shift is the emergence of AI coding agents.

Rather than simply generating code snippets, modern coding agents can understand an entire codebase, plan changes, execute them, run tests, fix issues, and explain their reasoning. One of the leading tools in this space is Codex.

What is Codex?

Codex is an AI-powered software engineering agent designed to help developers work directly with their source code.

Unlike traditional AI assistants that answer questions or generate isolated functions, Codex operates much more like another engineer on your team. It can:

Explore an existing repository
Understand project architecture
Make changes across multiple files
Execute commands
Run tests
Fix compilation errors
Refactor code
Generate documentation
Create pull-request-ready changes

Instead of asking “How do I implement JWT authentication?”, you can ask Codex:

“Implement JWT authentication across this Express application using our existing middleware patterns.”

Codex then performs the work inside your repository rather than simply describing how it could be done.

From AI Assistant to AI Engineer

Many developers have used AI chatbots to generate code snippets.

That workflow typically looks like this:

Developer
│
▼
Copy code into ChatGPT
│
▼
Receive code
│
▼
Paste into IDE
│
▼
Fix compilation errors
│
▼
Repeat

Enter fullscreen mode

Exit fullscreen mode

Codex changes the workflow entirely.

Developer
│
▼
Describe the task
│
▼
Codex explores repository
│
▼
Implements changes
│
▼
Runs tests
│
▼
Fixes issues
│
▼
Produces ready-to-review changes

Enter fullscreen mode

Exit fullscreen mode

The interaction becomes goal-oriented instead of code-oriented.

Understanding the Entire Codebase

One of Codex’s biggest strengths is repository awareness.

Rather than treating every prompt independently, Codex understands:

project structure
frameworks
existing coding conventions
dependency management
architecture
naming conventions
testing framework
deployment configuration

For example, in a large Node.js monorepo, Codex can recognize:

apps/
packages/
shared/
infra/
docs/
.github/

Enter fullscreen mode

Exit fullscreen mode

It understands how these components interact and modifies only the areas relevant to the requested task.

This dramatically reduces the amount of context developers need to manually provide.

Working Like a Real Engineer

A typical software task rarely involves writing one function.

Consider a request such as:

“Add audit logging whenever an invoice is approved.”

A human engineer would likely:

locate the approval endpoint
identify the service layer
update the database model
modify unit tests
update integration tests
document the API
verify linting
run the test suite

Codex follows a remarkably similar workflow. Rather than generating a single function, it works through the complete implementation.

Skills and Project Memory

One of the most useful capabilities of Codex is its support for project-specific guidance.

Teams can provide instructions that describe:

coding standards
architectural principles
testing requirements
security practices
repository structure
naming conventions

This allows Codex to behave consistently across an organization.

For example, instructions may specify:

Always use dependency injection.
Never access the database directly from controllers.
Write unit tests before integration tests.
Use repository pattern.
Follow Domain-Driven Design boundaries.
Never commit generated files.

Instead of repeating these instructions in every prompt, Codex learns them from project configuration.

What is an AGENTS.md

Many teams create an AGENTS.md file that acts as an operating manual for AI coding agents. An AGENTS.md file can include:

project overview
architecture
folder structure
coding conventions
build commands
testing commands
deployment process
common pitfalls
review checklist

For example:

# Project Rules

– Node.js 22
– TypeScript only
– Use Prisma ORM
– No direct SQL
– Unit tests required
– Follow Clean Architecture
– Run npm test before completion

Enter fullscreen mode

Exit fullscreen mode

The better this document is maintained, the more consistently Codex performs.

Practical Use Cases

Codex excels at repetitive and complex engineering tasks.

Some examples I’ve used Codex for include:

Feature development

REST APIs
GraphQL resolvers
UI components
database migrations

Refactoring

rename services
split large classes
introduce dependency injection
improve architecture

Bug fixing

investigate failing tests
locate regressions
repair compilation errors
resolve lint issues

Documentation

generate API documentation
update README files
explain complex modules
document infrastructure

Testing

create unit tests
generate mocks
improve coverage
fix broken test suites

Infrastructure

AWS CDK
Terraform
GitHub Actions
Docker
Kubernetes

Strengths

Codex offers several advantages over traditional AI-assisted coding.

1. Repository Awareness

It understands your project’s structure instead of treating every prompt in isolation.

2. Multi-file Editing

Real-world features often require coordinated changes across many files. Codex can handle those changes in one workflow.

3. Command Execution

Codex can build projects, execute tests, run linters, and validate its own work.

4. Consistency

When provided with project instructions, it follows the team’s engineering standards.

5. Reduced Context Switching

Developers spend less time copying code into chat windows and more time reviewing completed work.

Am Not trusting AI Agents 100%

I am discussing the uses of Codex and yet, I still don’t trust it. Conflicting? Probably. Despite its capabilities, Codex (and all AI Agents) is not a replacement for seasoned software engineers.

Human judgment remains essential for:

system architecture
product design
business requirements
security decisions
trade-off analysis
stakeholder communication
technical leadership

The best results come from treating Codex as an engineering partner rather than an autonomous replacement.

AI coding agents represent a significant evolution in software development.

Just as integrated development environments replaced text editors, and CI/CD transformed software delivery, AI agents are reshaping how engineers interact with code.

Rather than focusing on writing every line manually, developers increasingly define objectives, review implementations, and guide architectural decisions while AI handles much of the repetitive engineering work.

Codex exemplifies this shift. It combines repository understanding, code generation, automated validation, and project-specific guidance into a workflow that feels less like using an autocomplete tool and more like collaborating with another engineer.

For organizations willing to invest in clear architecture, strong engineering practices, and well-maintained project documentation, AI coding agents like Codex can significantly accelerate development while allowing engineers to concentrate on solving the problems that require human creativity, judgment, and experience.

Best Practices

Teams adopting Codex tend to achieve better results when they:

Keep repositories well organized.
Maintain clear documentation.
Define coding standards.
Write comprehensive tests.
Provide architectural guidance through AGENTS.md.
Review AI-generated changes before merging.
Use small, well-defined tasks.
Encourage iterative collaboration rather than one-shot prompts.

These practices improve not only AI-generated code but also the overall quality of the software project.



Source link