DEV Community: horlartundhey

Week 3 at DMI — When Linux Stopped Being Theory

horlartundhey — Mon, 20 Jul 2026 16:04:19 +0000

Week 3 of DevOps Micro Internship was the week Linux stopped being something I read about and became something I broke, diagnosed, and fixed on a real Ubuntu VM.

It started with spinning up an AWS Free Tier account and provisioning the EC2 instance I'd be operating on for the rest of the week. From there, I deployed two real applications through Nginx: a React app built with Node.js and npm, and a personal portfolio site, EpicReads. Both drills covered the same core loop — install the runtime, clone the code, build it, move the build into Nginx's web root, and configure the server block to serve it correctly. Small details mattered more than I expected: file permissions, the right root path, and a working reverse-proxy config were the difference between a blank page and a live site.

The most valuable part of the week was the Production Maintenance Drill, where I deliberately broke things in order to learn how to recover them. In one simulation, two semicolons went missing from my Nginx config. nginx -t caught the syntax error before I restarted anything, I restored the missing semicolons, re-validated, and restarted the service — confirming recovery with an external curl -I check for a clean 200 OK. In a second simulation, the entire web root was emptied out, and the app started returning 500s even though Nginx itself stayed healthy. Because I'd backed up the deployment beforehand, recovery was just restoring the backup and re-verifying — a small preview of why atomic, versioned deployments matter in real production systems.

Alongside that, I worked through Bash scripting fundamentals — variables, arrays, loops, conditionals, and functions — building up to a small automation script. That groundwork paid off immediately in the week's capstone: building an AI-assisted Linux health-check skill with Claude Code. I wrote a triage script, wired it into a Claude Code skill, then simulated a real incident (nginx stopped, port 80 down, HTTP checks failing). The skill correctly gathered evidence and diagnosed the cause from the logs — but it was restricted to read-only analysis by design. Per the project's safety rules, only I, the human, could approve and run the actual fix (sudo systemctl start nginx).

That distinction — AI that investigates and recommends, but doesn't execute — is the same "guardrails, not autopilot" lesson from Week 2, and it's the one I keep relearning: the tooling should make me faster at making decisions, not replace the decision.

P.S. This post is a part of DevOps Micro Internship with Agentic AI Cohort-3 by Pravin Mishra. You can start your DevOps journey by joining the DMI waiting list: https://forms.gle/3hvrWJBDzsDeJoPs6

DMIByPravinMishra

You can follow my graded progress throughout the cohort.

Week 0 at DMI: Relearning the Internet From First Principles

horlartundhey — Mon, 20 Jul 2026 15:59:53 +0000

Before I touched a single cloud console, DevOps Micro Internship Cohort 3 sent me back to the internet's plumbing — and it turned out I needed the refresher more than I expected.

Task one asked me to use ChatGPT as a learning assistant, prompting it to explain "What is a protocol in networking?" with a real-life example. The answer stuck with me in the simplest possible way: a protocol is just a set of rules devices agree on before they talk, the same way two people agree on a shared language before a conversation makes sense. That framing carried me through everything else that week.

The core exercise put me in the shoes of a friend launching an online bookstore called EpicReads, hosted on a server in Finland, and asked me to explain to him how someone on the other side of the world would actually reach his site. Walking through packet switching, IP addressing, TCP/IP, and HTTP/HTTPS forced me to stop treating "the internet" as a black box. A request doesn't travel as one block of data — it's broken into packets, routed independently, addressed to a specific IP, and reassembled at the other end, all wrapped in TCP/IP's reliability guarantees and delivered over HTTP or HTTPS.

From there, I mapped out two-tier and three-tier application architecture (frontend/database vs. frontend/backend/database), which made it obvious why EpicReads would eventually need a backend layer once it outgrew a simple storefront. Then came DNS: understanding that epicreads.com is really just a friendly alias for 52.172.142.222, resolved through an A record, was the moment the whole stack finally clicked together — domain name, DNS, IP, and server all pointing at the same thing from different angles.

The hardest part wasn't any single concept — it was holding TCP/IP, DNS, and architecture in my head at the same time as one connected flow instead of four separate facts. That's the habit I'm carrying into the rest of the internship: build the mental model first, then layer in the tools.

DMIByPravinMishra

You can follow my graded progress throughout the cohort.

Week 2 of my reflections from the DevOps Micro Internship: Guardrails, Not Autopilot

horlartundhey — Fri, 10 Jul 2026 13:42:20 +0000

Learning to trust an AI coding agent with real infrastructure, one permission at a time

Going into Week 2 of the DMI DevOps Micro Internship, I assumed I already understood what an AI coding assistant does: you type a prompt, it writes some code, you review it. What I actually learned this week is that Claude Code isn't a text generator you talk to; it's an agent operating inside a system of guardrails, and understanding those guardrails turned out to be the real curriculum.

1. Biggest technical insight I got this week

The concept that reframed everything for me was the agentic loop: read context, plan, call a tool, observe the result, decide the next step, repeat until done. That loop is powerful, but it's only safe because of what wraps around it.

In the project I worked on, CLAUDE.md tells the agent upfront that the site is pure HTML/CSS with no JavaScript and no build step, so it doesn't waste a turn inventing a bundler or npm scripts that were never there. Layered on top of that are skills: reusable slash commands like /scaffold-terraform and /tf-plan that turn a long, easy-to-forget prompt into a single, repeatable action, each with its own declared allowed-tools.

That's where tool restrictions stopped being an abstract "best practice" and became something I could point to. The tf-plan skill is scoped to Bash, Read, Grep, deliberately no Write, because a plan should only observe infrastructure, never change it. settings.json reinforces the same philosophy at the project level: it explicitly allows read-only Terraform and AWS calls (terraform plan, aws s3 ls, aws sts get-caller-identity) and explicitly denies destructive ones (rm -rf *, aws iam *). Permissions, I realized, aren't bureaucracy bolted onto AI, they're the actual mechanism that makes it safe to hand an agent something as consequential as real cloud infrastructure.

2. Biggest insight I got about myself this week

I learn better while doing a video guide that helps people, which surprisingly makes the learning and doing more interesting.

3. My biggest weakness or loop I noticed

The loop I kept catching myself in was trusting documentation over the actual state of the repo. This project's own CLAUDE.md includes a candid note that earlier commits referenced .claude/skills/, a GitHub Actions workflow, and a terraform/ directory, but those were later deleted from the working tree, meaning the "documented" pipeline was aspirational, not real. More than once I found myself reasoning about a file as if it existed because a description said it should, instead of running git status or listing the directory first. It's a small habit gap, but in DevOps, where "what's documented" and "what's actually deployed" can quietly diverge, it's exactly the kind of gap that causes real incidents.

4. One system I will implement this week

Before running any skill or command that touches infrastructure, like /scaffold-terraform or /tf-plan, I will first run git status and check the relevant directory to confirm what actually exists on disk, rather than trusting CLAUDE.md or a skill description alone. I'll do this at the start of every task, not just once per session, so I stop building on assumptions about files that were deleted, renamed, or never committed in the first place.

5. What I learned about Agentic AI and DevOps

Before this internship, "AI" meant a chat window that answered questions. This week reframed it as an operator with guardrails. An agentic AI can follow a structured workflow end-to-end, scaffold Terraform, run a plan, hand the output to a security-auditor or cost-optimizer subagent, and only then wait for a human to approve tf-apply, instead of producing a single disconnected answer.

What stood out most is that the safety doesn't come from the model being well-behaved; it comes from design. tf-plan physically cannot write files. Destructive commands are denied at the settings level, not just discouraged in a prompt. Hooks fire before and after every shell command to check and log what's happening, whether the model "intended" to be careful or not. Reusable skills cut the repetitive typing, which is nice, but the real lesson is that DevOps engineers now have to design two things at once: the automation, and the control layer that keeps it honest. Human review before apply isn't a leftover step from the pre-AI era. It's still the last line of defense.

6. My Week 2 highlight

Highlight of this week will be understanding and actually creating skills and sub-agents, using claude.md as a guide to make sure my agent has the correct context to work with.

I had a bit of an issue with Terraform, but this made me understand the flow better.

This is Week 2 of my reflections from the DevOps Micro Internship. If you're on a similar path, I'd love to hear what clicked for you this week too.

Introduction to the Document Object Model(DOM): The Foundation of Frontend Development

horlartundhey — Thu, 12 Jun 2025 13:32:11 +0000

What's this article about?

Introduction
What is the DOM?
Why is the DOM Important in Frontend Development?
Understanding the DOM Tree Structure
Interacting with the DOM using JavaScript
Events and the DOM
Common Mistakes Beginners Make with the DOM
Tools and Browser DevTools for DOM Exploration
Best Practices for DOM Manipulation
Conclusion

1. Introduction

When you open a website in your browser, you see buttons, text, images, and various interactive elements. But have you ever wondered how your browser understands and organizes all these parts of a webpage? The answer lies in something called the Document Object Model (DOM).

The DOM serves as the foundation of frontend development. It’s a programming interface that allows developers to structure, access, and modify the content and appearance of a webpage dynamically. Without the DOM, modern interactive websites as we know them would not exist.

For beginners starting in frontend development, understanding the DOM is one of the most crucial first steps. Once you grasp how the DOM works, you’ll be able to:

Dynamically update content on a webpage.

Handle user interactions like clicks, form submissions, and keyboard events.

Build more interactive and responsive user experiences.

In this article, we’ll break down the DOM in a beginner-friendly way, explore its structure, show you how to interact with it using JavaScript, and highlight best practices along the way.

2. What is the DOM?

The Document Object Model (DOM) is a structured representation of an HTML or XML document. Think of it as a live map of your webpage that your browser creates when it loads a page.

When you write HTML code like this:

<!DOCTYPE html>
<html>
  <head>
    <title>My First Webpage</title>
  </head>
  <body>
    <h1>Hello, World!</h1>
    <p>This is my first webpage.</p>
  </body>
</html>

Your browser takes this code and builds a tree-like structure that represents every element, attribute, and piece of text. This structure is the DOM.

At its core, the DOM:

Represents the document as a tree of objects.

Allows programming languages (like JavaScript) to interact with and manipulate the document’s content, structure, and style.

Updates automatically when changes are made, allowing for dynamic content.

In simple terms: HTML is the source, the DOM is the live version your browser uses.

Key Characteristics of the DOM:

Object-Oriented: Everything in the DOM is represented as an object (elements, attributes, text).

Hierarchical: Elements are nested inside one another, forming a tree.

Dynamic: The DOM can be changed in real-time using JavaScript.

3. Why is the DOM Important in Frontend Development?

The DOM is at the heart of almost everything you do as a frontend developer. It bridges the gap between your code and what the user sees and interacts with on the screen. Let’s explore why it's so important:

3.1. Dynamic User Interfaces

Without the DOM, webpages would be static, once loaded, they would never change. But thanks to the DOM, developers can:

Add or remove elements.

Update content without reloading the page.

Show or hide parts of the page based on user actions.

Example:

document.getElementById("greeting").innerText = "Welcome back!";

The above code changes the text content of an element dynamically.

3.2. User Interaction Handling

When users interact with a webpage (clicking buttons, submitting forms, hovering over elements), the DOM allows developers to capture these events and respond accordingly.

For example:

Show a message when a button is clicked.
Validate a form before submission.
Animate elements on user actions.

3.3. Powering Modern Web Frameworks

Modern frontend frameworks like React, Angular, and Vue work heavily with the DOM (or even virtual DOMs) to create smooth, efficient updates to the user interface.

Understanding the DOM is essential even if you plan to work with these frameworks, because:

They build upon DOM principles.
You’ll often need to work directly with the DOM for custom behaviors.

3.4. Debugging and Browser DevTools

When debugging your frontend code, most of your work involves inspecting and manipulating the DOM via browser developer tools. A solid understanding of the DOM helps you:

Diagnose layout problems.
Understand how CSS applies to elements.
Verify event bindings.

4. Understanding the DOM Tree Structure

The DOM is often visualized as a tree, where every part of your HTML document becomes a node in the tree. Understanding this tree structure makes it easier to navigate, select, and manipulate elements using JavaScript.

Let’s break it down:

4.1. The Tree Analogy

Root Node: The very top of the tree is the document object. Everything starts here.
Element Nodes: Each HTML tag (like , ,
,

) becomes an element node.
Text Nodes: The actual text inside elements becomes text nodes.
Attribute Nodes: Attributes (like class, id, and src) are nodes attached to their respective elements.

4.2. A Simple Example

Consider this HTML code:

<!DOCTYPE html>
<html>
  <head>
    <title>DOM Example</title>
  </head>
  <body>
    <h1>Hello World</h1>
    <p>This is a paragraph.</p>
  </body>
</html>

The DOM tree would look something like this:
Document
└── html
├── head
│ └── title
│ └── "DOM Example"
└── body
├── h1
│ └── "Hello World"
└── p
└── "This is a paragraph."

4.3. Why is the Tree Important?

You can move up and down the tree using JavaScript.
You can select parent, child, or sibling elements.
You can add or remove branches (nodes) dynamically.

4.4. The Parent-Child Relationship

The <body> is a child of <html>.
The <h1> and <p> are children of <body>.
The text "Hello World" is a child of <h1>.

4.5. Visualizing the DOM

Visualizing the DOM tree is extremely helpful for beginners because it helps you understand how elements are connected.

5. Interacting with the DOM using JavaScript

Now that you understand what the DOM is and how it’s structured, let’s dive into how you can interact with it using JavaScript. This is where the DOM truly becomes powerful, allowing you to make your webpage dynamic and interactive.

5.1 Accessing Elements

To manipulate an element, you first need to select it. JavaScript provides several ways to do this:

getElementById()
Selects an element by its ID.

<p id="greeting">Hello!</p>

let greeting = document.getElementById("greeting");
console.log(greeting.innerText); // Outputs: Hello!

getElementsByClassName()
Selects elements by class name (returns a collection).

<p class="message">First message</p>
<p class="message">Second message</p>

let messages = document.getElementsByClassName("message");
console.log(messages[0].innerText); // Outputs: First message

querySelector()
Selects the first element that matches a CSS selector.

let heading = document.querySelector("h1");

querySelectorAll()
Selects all elements that match a CSS selector.
let paragraphs = document.querySelectorAll("p");

5.2 Modifying Elements

Once you’ve selected an element, you can modify its content, style, and attributes.

Change Text Content

document.getElementById("greeting").innerText = "Welcome!";

Change HTML Content

document.getElementById("greeting").innerHTML = "<strong>Welcome!</strong>";

Change Style

document.getElementById("greeting").style.color = "blue";

5.3 Adding and Removing Elements

You can also create, append, or remove elements dynamically.

Create and Append

let newParagraph = document.createElement("p");
newParagraph.innerText = "This is a new paragraph.";
document.body.appendChild(newParagraph);

Remove Element

let element = document.getElementById("greeting");
element.remove();

6. Events and the DOM

While manipulating the DOM allows you to change the webpage structure and content, events are what make your webpage interactive. An event occurs when the user or the browser does something, like clicking a button, moving the mouse, submitting a form, or pressing a key.

The DOM allows you to listen for these events and execute JavaScript code in response.

6.1 Common DOM Events

Event	Description
`click`	When an element is clicked
`mouseover`	When the mouse hovers over an element
`mouseout`	When the mouse leaves an element
`keydown`	When a keyboard key is pressed
`submit`	When a form is submitted
`load`	When the page has finished loading

6.2 Adding Event Listeners

The most common way to handle events is by using the addEventListener() method.

Example: Button Click

<button id="myButton">Click Me!</button>
<p id="result"></p>

let button = document.getElementById("myButton");
let result = document.getElementById("result");

button.addEventListener("click", function() {
  result.innerText = "Button was clicked!";
});

When the user clicks the button, the text inside the <p> tag updates dynamically.

6.3 Why Use Event Listeners?

Separation of Concerns: Keeps HTML and JavaScript code separate.
Multiple Handlers: You can attach multiple listeners to the same element.
Flexibility: Allows better control over complex user interactions.

6.4 Other Example: Form Submission

<form id="myForm">
  <input type="text" id="nameInput" />
  <button type="submit">Submit</button>
</form>
<p id="displayName"></p>

let form = document.getElementById("myForm");
let display = document.getElementById("displayName");

form.addEventListener("submit", function(e) {
  e.preventDefault(); // Prevents page reload
  let name = document.getElementById("nameInput").value;
  display.innerText = `Hello, ${name}!`;
});

7.Common Mistakes Beginners Make with the DOM

As you start working with the DOM, it’s natural to run into a few pitfalls. Let’s go over some of the most common mistakes and how to avoid them.

7.1 Trying to Access DOM Elements Before the Page Loads

Problem:
If you try to select or modify DOM elements before they exist in the browser, your code may fail.

Example:

let heading = document.getElementById("heading");
heading.innerText = "Hello!";
If this code runs before the DOM has fully loaded, heading will be null, causing an error.

Solution:
Use the DOMContentLoaded event to ensure your code runs after the DOM is ready.

document.addEventListener("DOMContentLoaded", function() {
  let heading = document.getElementById("heading");
  heading.innerText = "Hello!";
});

7.2 Overusing innerHTML

While innerHTML is powerful, it’s easy to misuse it and accidentally introduce bugs or security vulnerabilities like Cross-Site Scripting (XSS).

Better practice: Use textContent or DOM methods to modify elements.

element.textContent = "Safe Text";

7.3 Forgetting to Remove Event Listeners

When dynamically adding and removing elements, forgetting to remove event listeners can cause memory leaks and unexpected behavior.

button.removeEventListener("click", myFunction);

7.4 Mixing Inline JavaScript with DOM Manipulation

While it’s possible to use inline onclick attributes:

<button onclick="alert('Hello!')">Click Me</button>

Best practice:
Separate your JavaScript code from HTML by using addEventListener(). This makes your code more maintainable and scalable.

7.5 Not Using Efficient Selectors

Using getElementById() is faster and more specific.

Avoid using overly broad selectors that may select multiple unintended elements.

8. Tools and Browser DevTools for DOM Exploration

One of the best ways to learn and work with the DOM is by using the powerful tools built into modern web browsers. These tools allow you to inspect, edit, and experiment with the DOM in real-time.

8.1 The Browser Developer Tools (DevTools)

Almost every modern browser (Chrome, Firefox, Edge, Safari) includes DevTools. You can usually open them by:

Right-click on any element on the page and select Inspect.

Or press F12 or Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac).

8.1.1 Elements Panel

Displays the live DOM tree of the current webpage.

You can expand and collapse elements to see the structure.

You can edit HTML directly to see instant changes.

8.1.2 Console Panel

Allows you to run JavaScript directly in the context of the webpage.

Great for testing DOM manipulations quickly.

Example:

document.querySelector("h1").innerText = "Changed via Console!";

8.1.3 Other Useful Panels

Network: See how resources load.
Sources: Debug JavaScript.
Performance: Analyze page speed.
Accessibility: Review accessibility issues.

8.2 Online Playground Tools

Many online tools allow you to experiment with the DOM:

These are great for practicing DOM manipulation without having to set up files on your computer.

9. Best Practices for DOM Manipulation

As you grow more comfortable working with the DOM, following best practices will help you write more efficient, maintainable, and secure code. Let’s cover some important tips:

9.1 Access Elements Efficiently

Use getElementById() when possible — it’s the fastest.

Minimize repeated DOM queries — store elements in variables if used multiple times.

Example:

let button = document.getElementById("submitBtn");

// reuse `button` instead of querying again
button.addEventListener("click", handleSubmit);

9.2 Avoid Unnecessary Reflows and Repaints

Manipulating the DOM excessively or inefficiently can slow down your page. If you're making multiple changes, try:

Modifying elements outside of the visible document (using DocumentFragment).

Minimizing layout calculations in loops.

9.3 Sanitize User Input

Never directly insert user input into the DOM using innerHTML. This can lead to security issues like Cross-Site Scripting (XSS).

Instead:

element.textContent = userInput;

9.4 Use Event Delegation

Instead of attaching multiple event listeners to many child elements, attach one listener to a parent element.

Example:

document.getElementById("list").addEventListener("click", function(e) {
  if (e.target.tagName === "LI") {
    console.log(e.target.innerText);
  }
});

This approach is more efficient, especially for dynamic content.

9.5 Separate Concerns

Keep your HTML, CSS, and JavaScript separate.

Avoid mixing inline JavaScript (onclick="...") with your HTML.

This leads to cleaner, more maintainable code.

9.6 Use DOMContentLoaded

Make sure the DOM is fully loaded before manipulating it.

document.addEventListener("DOMContentLoaded", function() {
  // Safe DOM manipulation here
});

9.7 Clean Up Event Listeners

When removing elements dynamically, ensure you also remove any event listeners to prevent memory leaks.

element.removeEventListener("click", myFunction);

10. Conclusion

The Document Object Model (DOM) is truly the foundation of frontend development. Every time you build a webpage, you're essentially creating a DOM structure that your browser understands and renders.

For beginners, mastering the DOM unlocks the ability to:

✅ Create dynamic, interactive webpages
✅ Respond to user actions with JavaScript
✅ Modify page content on the fly
✅ Build confidence for learning modern frontend frameworks like React, Vue, or Angular

Key Takeaways:

The DOM represents your HTML as a live tree structure.
JavaScript allows you to interact with and manipulate the DOM.
Events are key to making webpages interactive.
Browser DevTools are your best friend for exploring and debugging the DOM.
Always follow best practices for efficient, safe, and maintainable code.

👉 Next Steps for You as a Beginner:

Practice manipulating the DOM using simple projects (to-do list, calculator, form validation).

Experiment using DevTools on existing websites.

Gradually move on to understanding Virtual DOM (used by modern frameworks).

💡 Always remember:

If you master the DOM, you're already halfway to becoming a great frontend developer!