DEV Community: Aditya Raj

Day 6: Same Logic, Different Syntax — and Finally Talking to a Database

Aditya Raj — Tue, 28 Jul 2026 18:26:37 +0000

28-07-2026

What I Did

Three rooms today, opening up the programming side of Module 4: Python: Simple Demo, JavaScript: Simple Demo, and Database SQL Basics.

Python: Simple Demo

This room builds a Guess the Number game gradually — v1 handles input, v2 adds decisions, v3 adds a loop, v4 adds validation — and that structure was the biggest thing that clicked. Variables, conditionals, and loops stopped feeling like three separate topics and started looking like one system: variables remember state (the secret, the guess, how many tries), conditionals decide what a guess means, and the loop controls whether the whole thing repeats.

The other useful realization: input() always returns text, even if someone types a number, so the program has to explicitly convert it with int() before comparing it to anything numeric. And the final else in the if/elif/else chain doesn't need its own check — by the time execution reaches it, every other possibility (out of range, too low, too high) has already been ruled out, so equality is the only option left.

What needed a second look: why initialize guess = 0 at the start. The secret is always between 1 and 20, so starting guess at 0 guarantees it can't accidentally already equal the secret — which is exactly what lets the while guess != secret loop actually begin.

JavaScript: Simple Demo

This room rebuilds the exact same Guess the Number game in JavaScript, which made the biggest lesson obvious: Python and JavaScript can look completely different while expressing identical logic. print() becomes console.log(), int(text) becomes parseInt(text, 10), elif becomes else if, != becomes !== — but underneath, it's still variables remembering, conditionals deciding, loops repeating. That reframed learning a second language as learning new syntax for ideas I already had, not starting over.

let vs const also clicked once I stopped treating them as arbitrary keyword choices: if a value needs to change (tries, guess), use let; if it shouldn't be reassigned after being set (secret), use const.

The one thing that took real unpacking: Math.floor(Math.random() * 20) + 1. Reading it as a pipeline made it click — Math.random() gives a decimal between 0 and 1, multiplying by 20 stretches that to 0–20, Math.floor() rounds down to a whole number 0–19, and adding 1 shifts the range to 1–20.

Database SQL Basics

The café notebook example made the whole point of databases obvious immediately: a notebook means searching page by page by hand, while a database means the computer searches instantly, even across millions of records. From there, tables/rows/columns stopped being definitions to memorize and became one mental picture — a spreadsheet where each column is one type of information and each row is one complete record.

Writing actual SQL queries clicked once I saw that each keyword just answers a different question: SELECT asks what you want, FROM asks where it lives, WHERE asks which rows qualify, ORDER BY asks how to sort what's left. Combining WHERE and ORDER BY in one query showed that SQL is built like building blocks — a few keywords stacked together to ask increasingly specific questions, not a huge list of separate commands to memorize.

The part worth double-checking: WHERE and ORDER BY do genuinely different jobs. WHERE filters — it reduces which rows show up at all. ORDER BY only changes the order of whatever rows are already there. Mixing those up leads to expecting a query to filter when it's actually just re-sorting the exact same set of rows.

Visuals

The shared logic behind both programming demos, regardless of language:

How a SQL query actually gets answered:

What's Next

That closes out all five rooms of Module 4: Software Basics. Module 5: Network Fundamentals is next.

Day 5: Catching Up — CLI Investigation, OS Security, and How Computers Represent Data

Aditya Raj — Mon, 27 Jul 2026 19:13:13 +0000

27-07-2026

What I Did

Catching up on five rooms that didn't make it into a post yet: Linux CLI Basics, Windows CLI Basics, and Operating System Security (closing out Module 3), plus Data Representation and Data Encoding, the first two rooms of Module 4: Software Basics.

Linux CLI Basics

What clicked was realizing the terminal isn't a pile of commands to memorize — it's a repeatable investigation workflow. Finding a specific file broke down into a natural sequence: pwd to figure out where I am, ls/ls -al to see what's around me, find to actually locate the file, cd to get to it, cat to read it. Beyond navigation, commands like whoami, uname -a, df -h, and cat /etc/os-release build a quick picture of the machine itself — exactly the kind of thing you'd want first when investigating any system.

The one thing that needed a second look: Linux is case-sensitive, so cd documents fails silently if the real folder is Documents. A small detail, but the kind of thing that makes an otherwise-correct command just not work.

Windows CLI Basics

The big realization here was that Windows CMD and Linux solve almost the exact same problems with different command names. The same workflow — locate yourself, explore, search, navigate, read, investigate — just uses dir, cd, type, whoami, hostname, systeminfo, and ipconfig instead. That meant learning Windows CLI wasn't starting from zero; the investigative mindset carried straight over.

Two things needed sorting out: cd on its own shows the current directory, while cd moves into one — same command, two jobs depending on how it's used. And whoami vs hostname answer genuinely different questions (who I'm logged in as, vs. which computer I'm actually on), which matters once you're enumerating a system you don't fully know yet.

Operating System Security

This room made it click that OS security isn't one feature — it's the fact that the OS sits between every application and the hardware, so compromising it exposes everything. The CIA triad became much easier to hold onto with a simple framing: confidentiality is who can see something, integrity is who can change it, availability is whether it can actually be used when needed.

The lab's real lesson was watching a chain of small, individually unremarkable mistakes — weak credentials, more exposed credentials, sensitive data sitting in shell history — compound step by step into full root access. Authentication vs privilege was the one distinction worth slowing down on: getting into a normal account doesn't mean getting full control — that only happens once access actually escalates to root.

Data Representation

The core shift here was realizing binary, decimal, hex, and octal aren't different values — they're different ways of writing the exact same value. Once that clicked, base conversion stopped feeling like four separate skills and became one idea viewed through different lenses. The RGB example made it concrete: three 8-bit channels, each with 256 possible levels, multiplying out to 16,777,216 colors. And hexadecimal's usefulness finally made sense too — 4 bits per hex digit means a full byte compresses neatly into just 2 hex characters, which is exactly why hex shows up everywhere data gets displayed compactly.

The confusing part: 8 bits gives 256 possible values, but the actual range is 0–255 — easy to mix up until you remember zero counts as one of those 256 values.

Data Encoding

This room separated two ideas I'd been quietly merging: representation (how numbers are stored) and encoding (what those numbers actually mean). 01000001 in binary is 65 in decimal, and ASCII is the standard that says "65 means the letter A." The computer never stores the shape of a letter — just a number, with a meaning attached by an agreed-upon standard.

The other piece that clicked: Unicode and UTF aren't the same layer. Unicode assigns a character its universal code point (like U+0041 for "A"); UTF-8, UTF-16, and UTF-32 are just different ways of actually encoding that code point into bytes. Seeing a webpage render as garbled Arabic text was a good reminder that the underlying data usually isn't gone — it's just being interpreted through the wrong encoding.

The mix-up worth flagging: UTF-8 and UTF-16 are variable-length (1–4 bytes, and 2 or 4 bytes respectively), while only UTF-32 is a fixed 4 bytes per character — the names make all three sound like fixed-width systems, and only one actually is.

Visuals

The investigation workflow shared across Linux and Windows CLI:

How a character actually becomes stored bytes:

What's Next

Python: Simple Demo, JavaScript: Simple Demo, and Database SQL Basics to close out Module 4.

Day 4: What's Actually Running Under Windows

Aditya Raj — Sat, 25 Jul 2026 18:37:50 +0000

25-07-2026

What I Did

Completed two rooms in Module 3 (Operating Systems Basics): Operating Systems: Introduction, then Windows Basics, which applies those same concepts to a real Windows Server 2019 environment.

What I Learned

The biggest shift from Operating Systems: Introduction was realizing the OS isn't just the desktop I see when I turn a computer on — it's the manager sitting between every application and the actual hardware, deciding who gets CPU time, RAM, and file access. The airport analogy made this click: applications are airlines competing for runway time, and the OS is air traffic control making sure they don't all grab the same resources at once.

The other big piece was kernel space versus user space. Regular applications run in a restricted user space and can't just reach out and touch hardware directly — they make a system call and let the kernel handle it. That's not just an organizational detail, it's a security boundary. Permissions, process isolation, and user accounts are already security mechanisms before any extra security tool ever gets installed.

Windows Basics took all of that and made it concrete. The Desktop, Start Menu, and File Explorer stopped feeling like separate, unrelated tools and started looking like different interfaces to that same underlying OS. Opening a folder through File Explorer and knowing its actual path (C:\Users\Administrator\Desktop...) made the connection between what I click and where the data actually lives feel real for the first time. Account type mattered too — being logged in as Administrator explained exactly why I could install software and change system configuration without hitting permission walls.

The clearest cybersecurity moment was the Windows Security custom scan. Scanning a folder, watching it detect a test file (EICAR), and quarantining it turned "endpoint protection" from an abstract term into an actual workflow: scan, detect, classify, investigate, quarantine.

Problems and How I Solved Them

In Operating Systems: Introduction, kernel space vs user space needed a second look — it's easy to misread as "kernel = the OS, user space = the human user," which isn't quite right. Reframing user space as the restricted execution environment for applications, not a literal "user's space," fixed that.

In Windows Basics, two things needed sorting out. Windows Settings vs Control Panel look like they do the same job, since Windows has been gradually moving functionality from the older Control Panel into the newer Settings app — so the overlap is real, not a misunderstanding on my part. Windows Security vs Windows Defender Firewall also needed separating: Windows Security is the broader dashboard, and the firewall is just one specific control inside it, not a competing product.

Visuals

The OS sitting between applications and hardware:

The Windows Security scan workflow from the lab:

What's Next

Linux CLI Basics and Windows CLI Basics to round out Module 3, moving from GUI-based navigation into the command line directly.

Day 3: Virtualisation, and a Detour into AI Threat Modelling

Aditya Raj — Fri, 24 Jul 2026 03:30:00 +0000

23-07-2026

What I Did

Finished Virtualisation Basics, the last room I still had left in Module 2 before Cloud Computing Fundamentals. I also went off the standard roadmap for a bit and completed an extra room: AI Threat Modelling Assessment.

What I Learned

The biggest shift from Virtualisation Basics was realizing it isn't really about "running another OS inside your OS." It's about not wasting hardware. Running one application per physical server is like building a separate house for every guest who visits — most of each house sits empty most of the time. Virtualization is building one apartment building instead, with a hypervisor as the building manager dividing it into separate, secure units.

Once that clicked, the rest of the hierarchy fell into place: the hypervisor manages the hardware and hands out virtual machines, each VM is a complete computer with its own OS, and containers go a step lighter by sharing the host's kernel to run just one application instead of a whole separate system. Seeing an actual host monitoring dashboard tied this to real sysadmin work — it's not just about creating VMs, it's about checking whether a given physical server actually has the CPU, memory, and storage headroom for another one before you create it.

AI Threat Modelling Assessment ended up connecting to the same underlying idea, just applied somewhere completely different. The big takeaway there was that AI security isn't about memorizing attack names — it's about identifying which specific component of the AI pipeline (the prompt, the LLM, the retrieval system, the database) is actually exposed, and placing the defense at that exact layer. A Prompt Injection attack targets the prompt and the LLM directly. Sensitive Data Leakage can involve the retrieval system, the database, and the LLM. Data Poisoning happens further upstream, corrupting the database and retrieval system before poisoned data ever reaches the model at all.

Problems and How I Solved Them

In Virtualisation Basics, the one thing that needed a second read was the difference between a VM and a container — both isolate applications, so at first they looked like they solved the same problem. The architecture diagram made it click: a VM includes a full separate operating system, while a container shares the host's existing kernel, which is what makes it lighter but less flexible.

The AI Threat Modelling room had a similar kind of confusion, just with attack names instead of infrastructure terms. Prompt Injection versus Sensitive Information Disclosure looked interchangeable at first, and so did Data Poisoning versus Feature Manipulation. What actually resolved both pairs was asking a single question: where in the AI lifecycle does this attack actually happen — training, inference, or retrieval? Once I started sorting by that instead of by how the attack sounded, picking the right answer got a lot easier.

Visuals

The virtualization hierarchy, from physical hardware down to an individual containerized app:

The AI pipeline, and where each major attack actually lands:

What's Next

Cloud Computing Fundamentals to actually close out Module 2, then on to Operating Systems Basics in Module 3.

Day 1–2: My First Steps into Cybersecurity

Aditya Raj — Wed, 22 Jul 2026 09:40:32 +0000

I'm a final-year Computer Science student aiming for a SOC Analyst or Network Security Engineer role after graduation, and I'm logging the process of actually getting there. I missed posting yesterday, so this entry covers two days at once.

20-07-2026

What I Did

Completed Module 1: Introduction to Cyber Security on TryHackMe's Pre Security path — three rooms: Offensive Security Intro, Defensive Security Intro, and Careers in Cyber.

What I Learned

This is the first time I've studied security in a structured way rather than picking things up in scattered pieces, and I wasn't sure how it would go. What made it click was how each room pairs theory with an actual hands-on lab, so a concept doesn't stay abstract for long. Offensive Security Intro, for instance, has you find a hidden page on a practice banking site yourself instead of just reading a definition of ethical hacking. By the end of the module, I'd also turned what I'd learned into a project of my own — a structured set of study notes, built room by room as I go.

Problems and How I Solved Them

Nothing major tripped me up. This is the first module of a beginner path, so it's built to ease you in rather than overwhelm you. If there was a challenge at all, it was just the general uncertainty of starting something new — and having a lab right after the theory cut a lot of that down.

21-07-2026

What I Did

Moved into Module 2: Computer Fundamentals and completed three rooms — Inside a Computer System, Computer Types, and Client-Server Basics. Virtualisation Basics is next, still in progress.

What I Learned

What actually clicked today was realizing how much happens the instant you press a computer's power button. It's not one action, it's a short chain of events: the firmware starts, POST runs, a boot device gets selected, and only then does the bootloader take over. Something as simple as turning a computer on suddenly felt a lot less simple.

The other big piece was HTTP(S). I learned it's technically a stateless protocol — it doesn't remember anything between requests — but modern applications work around that by attaching a cookie or token to each request instead. I went through all nine HTTP methods (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE, CONNECT) and took a proper deep dive into GET specifically, inspecting a real webpage's request to see its scheme, host, filename, address, and status for myself. On the response side, I learned it splits into two parts: a response header (metadata) and a response body (the actual content).

The restaurant analogy from Client-Server Basics tied a lot of this together — the client is you placing an order, the protocol is the friend who knows how to phrase it correctly, the server is the kitchen preparing it, ports are separate doors for separate services, and DNS is what turns a name into an actual address in the first place.

Problems and How I Solved Them

The one thing that threw me off was opening the Network tab in browser dev tools for the first time. There's a lot more going on there than the single, clean request example from the theory made it look like. I didn't fully untangle it today, but having just learned what a request's scheme, host, and status are supposed to mean gives me an actual reference point for next time I open it.

Visuals

How Module 1 broke down into its three rooms:

What happens when you press the power button:

How an HTTP request and response actually move between client and server:

What's Next

Finishing Virtualisation Basics, then Cloud Computing Fundamentals to close out Module 2. The Network tab is on my list to revisit once I'm further into the networking-focused rooms later in the path.

Thanks for reading!

If you're also learning cybersecurity, I'd love to hear about your journey or any suggestions in the comments.

Follow along for future entries in the Cyber Chronicles series.