DEV Community: Boyan Iliev

Does Your AI Agent Have a Kill Switch?

Boyan Iliev — Mon, 03 Aug 2026 06:00:00 +0000

The agent believed it was working inside a simulation. The systems it reached were real. Anthropic's report shows why a prompt cannot carry the whole safety boundary for an autonomous task.

An engineer should know what the agent is doing, what it can reach and how to stop it.

On 30 July 2026, Anthropic published a review of 141,006 cybersecurity evaluation runs. It found three incidents, across six runs, where Claude reached the internet and gained unauthorised access to real organisations.

The models were running capture-the-flag exercises. Their prompts said the environment was simulated and had no internet access. A misunderstanding with the evaluation partner left live internet access available, so the models often treated real systems as part of the exercise.

The models followed their task with a false picture of the environment. The runtime allowed actions that the prompt said were impossible, and the activity was found later through transcript review.

An engineer should understand the task before it begins, see its progress and be able to stop it immediately. The platform must enforce those controls even when the model misunderstands the situation.

The agent had the wrong picture of its environment.

Anthropic's evaluation prompt told Claude that it had no internet access. The machines used for the exercise could reach the internet because of a misconfiguration. The agent trusted the description in the prompt and treated reachable systems as part of the simulated challenge.

The incidents had real effects. One reached production infrastructure and a database. Another published a malicious Python package to PyPI. It was available for roughly one hour and ran on 15 real systems. A third scanned thousands of targets before compromising an internet-facing application.

The models reacted differently to signs that the targets were real. An older model continued. Another convinced itself that it was still in a simulation. Anthropic's latest research model stopped after recognising the real environment.

Anthropic describes this as closer to a harness and operational failure than a model alignment failure. Normal production safeguards were absent because the evaluations measured the underlying models. Containment and monitoring therefore carried more responsibility.

The prompt described the intended world. The infrastructure exposed the real one.

Make the environment prove what the agent can reach.

A prompt can name the approved environment, resources and goal. It cannot close a network route, remove an IAM permission or prevent a tool from calling an unapproved endpoint.

Build the smallest working environment for the task. Give the agent a separate identity, short-lived credentials, an allowlist of tools and resources, a network policy and a time limit. Check those controls from inside the runtime it will use.

Name the account, cluster, repository, namespace, service and environment. Describe which systems are real, simulated or outside scope. If the runtime disagrees with that description, stop before the first action.

Review third-party execution environments as well. The team needs to know who owns the network, identity, logs, emergency stop and incident response. An assumption between two organisations can become a live access path.

Verify outbound network access from inside the agent runtime.
Issue one short-lived identity for one task and one environment.
Allow only the tools, resources and actions required for the approved goal.
Record the expected account, cluster, repository and service before execution.
Stop when the observed environment differs from the approved context.
Confirm who owns monitoring and incident response across every vendor boundary.

Controls should still hold when the agent's understanding is wrong.

Give the engineer a live view of the task.

Before the run, the responsible engineer should see the goal, plan, environment, identity, tools, access boundary, time limit and stop conditions. A broad instruction such as investigate the cluster leaves too much room for interpretation.

During the run, show the current step, tool call, target resource, network destination, command, proposed change and evidence. Highlight denied requests, repeated attempts, new destinations and actions outside the plan.

Keep the important state above the raw transcript: the goal, current action, completed changes, remaining access and failed policy checks. Preserve the full trace underneath for audit.

Alert the named owner when the agent approaches a boundary. The owner can follow normal reads through the activity view and receive a clear signal when approval is required or the task changes shape.

Keep the plan, live work and stop path together

The engineer should be able to understand and control the task from one place.

Approved goal: Name the owner, environment, result and time limit.
Bounded identity: Issue short-lived access for the approved tools and resources.
Live activity: Show actions, targets, evidence, retries and denied requests.
Policy checks: Compare every action with the approved scope before the tool runs it.
Engineer checkpoint: Pause before a production change, new destination or high-risk action.
External stop: End the task and remove its access through a control the agent cannot change.
Preserved evidence: Keep the plan, tool calls, logs, diffs and reason for stopping.
Verified recovery: Check the desired state and let the engineer decide the next step.

Awareness means seeing the plan, the current action and the remaining authority.

A kill switch must stop access as well as reasoning.

Industries that use machinery design an emergency stop into the system. An infrastructure agent can cross networks, use credentials and change real resources quickly. Design its stop before it starts.

Ending the model response leaves other work running. Tool calls, CI jobs, cloud operations, retries and scheduled tasks may continue after the visible conversation ends.

Place the kill switch in the orchestrator or a separate control service. The agent cannot disable it, edit its policy or issue itself a new identity. Engineers and automatic policy controls should both be able to trigger it.

Stopping also needs a recovery choice. Preserve the evidence, compare the running system with the approved state and let the engineer choose whether to reconcile, revert or investigate further.

Stop the active run: End new calls, then terminate active sessions and jobs where possible.
Remove authority: Revoke the task identity, expire tokens and block its network and tool access.
Cancel future work: Clear queued jobs, retries, schedules and child tasks created by the run.
Preserve the record: Store the plan, prompts, actions, destinations, responses, diffs, logs and stop reason.
Check the real state: Compare Git, GitOps, Kubernetes and cloud state with the last approved result.
Return ownership: Give the responsible engineer the evidence and recovery choices before any restart.

The stop control must remain available when the agent, model or runtime behaves unexpectedly.

Keep engineers close to actions that change the system.

Engineers should see the plan, the live activity and every point where approval is needed. Routine reads can continue inside the approved boundary.

Read-only evidence gathering can publish a report for review. Infrastructure changes should arrive as a diff or pull request. Git records the proposal, CI checks it and an engineer approves it before GitOps applies the accepted state.

Identity, networking, data, deletion and security changes deserve explicit approval. Small reversible actions may gain more automation after the team tests the limits, recovery and stop path with real runs.

For Atomsized workflows, AI reads and prepares. Engineers decide and approve. Git records the accepted change. GitOps applies it. AWS and monitoring report the result.

The engineer owns the decision, the boundary and the recovery.

Begin with one task and rehearse the stop.

Choose one repeated task with a known owner and clear result. Read-only investigation lets the team compare the agent's work with an engineer's process before giving it change access.

Write down the scope and pause conditions. Build the live view and kill switch, then replay earlier incidents where the correct outcome was to ask for help or stop.

Run beside an engineer. Review the actions, access, weak context and alerts. Expand only after the team trusts the monitoring and has rehearsed recovery.

1. Choose the task: Name one owner, one environment, one expected result and one maximum runtime.
2. Map every action: List the tools, resources, destinations, permissions and data the task may use.
3. Build the boundary: Create the task identity, allowlists, network rules and automatic stop conditions.
4. Show the live state: Put the plan, current action, evidence, changes and policy decisions in one view.
5. Test the kill switch: Stop an active tool call, revoke access, cancel queued work and confirm the evidence remains available.
6. Run in shadow mode: Use real work with no change authority, compare results and fix gaps before adding another action.

A team should prove that it can stop the agent before asking the agent to do more.

Test what happens after the button is pressed.

A kill switch can report success while external work continues. Confirm that credentials fail, network paths close, active jobs end where possible and queued work disappears.

Inspect the running state next. GitOps may restore an approved configuration, while data operations and external API calls can need a separate recovery. Show what completed, stopped halfway and still needs attention.

Keep these tests in the evaluation set. Include wrong context, unexpected internet access, new destinations, repeated denied actions, lost monitoring and a failed stop attempt.

The manual stop remains available outside the agent runtime.
Automatic policy checks can stop the task without model cooperation.
Credentials, network paths, active jobs, queues and retries are checked separately.
The full activity record remains available after access is removed.
The running system is compared with the last approved state.
An engineer confirms recovery before the agent can start again.

Pressing stop begins the recovery. Verified state finishes it.

Design the stop before the agent starts.

Anthropic's report shows how reasonable assumptions can line up badly. The agent believed the prompt, the environment exposed more than intended and monitoring found the activity after real systems had been reached.

Give every task a named owner, accurate context, limited access, live monitoring, checkpoints and a stop control the agent cannot reach.

Start with one read-only workflow. Make its work visible, rehearse the kill switch and verify recovery. Add authority from evidence gathered during real runs.

An engineer should always know what the agent is trying to do, what it can touch and how to stop it.

How Can You Trust AI Agents With Your Infrastructure? — The context, operating experience, permission boundary and recovery path an infrastructure agent needs before it prepares a change.
How Should AI Monitor Your Infrastructure? — How an AI monitoring agent can gather evidence, report useful findings and keep the responsible engineer in control.

Give the agent a visible task and an external stop.

We can map one AI-assisted workflow, limit its access, show engineers what it is doing and build the stop and recovery path before it reaches production.

Schedule a platform call

How Should AI Monitor Your Infrastructure?

Boyan Iliev — Thu, 30 Jul 2026 06:00:00 +0000

An alert tells you that something changed. It rarely says why, who is affected or what to do next. The on-call engineer still opens several tools and pieces the story together. AI can help when it understands the platform around the alert.

The agent collects the evidence and reports the finding. Engineers decide what to do.

Imagine an API latency alert. It identifies the graph that moved. It does not explain whether users are blocked, what changed ten minutes earlier or which dependency is slow.

We have worked through incidents where a deployment looked healthy while a dependency was failing. We have also seen the largest movement on a dashboard lead away from the real user problem. The answer came from connecting the signals to the platform around them.

An agent that opens dashboards faster saves a few clicks. A useful one follows the incident like an experienced engineer. It knows how the service should behave, how the parts connect, what changed and who owns the response.

Start with one incident your team already understands. Write down how the investigation works, connect the information it needs and let the agent follow that path in read-only mode.

The agent should join the investigation early.

Monitoring rules tell the team when a known signal crosses a limit. Someone still works out whether users are affected, which services are involved, what changed and what can be done safely.

The agent can begin when the alert arrives. It can update the incident notes, collect evidence and prepare a clear summary for the responsible engineer.

The first guess will often be incomplete. One service may recover while another starts to fail. A recent deployment may look related and turn out to be harmless. The agent should keep checking its explanation as the situation changes.

What we want is simple: a shorter path from the first signal to a useful understanding of the problem. The engineer should see who is affected, what changed, which dependencies matter, what evidence is missing and what to check next.

The agent keeps the incident picture updated. The engineer decides what to do.

Give the agent a clear map of the platform.

A large collection of metrics and logs is only the starting point. The agent needs to know how those signals relate to the system the team runs.

Start with what the user is trying to do. Follow that path through the applications, databases, queues, networks, cloud resources and external services involved. Connect each part to its owner, expected state, deployment source and recovery steps.

Then add what changed. Git commits, CI runs, Argo CD syncs, Terraform changes, Kubernetes events, AWS activity, feature releases, maintenance and traffic shifts can all change how an alert should be read.

Add the team's experience as well. Runbooks show the usual response. Incident reviews show what happened here before. Maintenance notes explain temporary conditions. Confirmed results show which clues helped and which guesses were wrong.

Connect the user problem to the recovery

Each part answers a different question during the incident.

What healthy looks like: Describe what users and business processes should be able to complete.
How the system connects: Map the applications, data, networks, cloud resources and external services involved.
What is happening: Collect metrics, logs, traces, events and checks with clear names and timestamps.
What changed: Connect deployments, configuration, infrastructure changes and planned work.
What the team knows: Add owners, runbooks, maintenance, known exceptions and earlier incidents.
Agent investigation: Build the timeline, test possible causes, show gaps and prepare the next check.
Engineer decision: The responsible engineer reviews the evidence and chooses the response.
Check the recovery: Watch the result, record what happened and improve the next investigation.

The map should show how a user problem connects to the systems underneath it.

The agent can only use the context you prepare.

Most of the information probably exists already. The problem is that each tool describes the platform differently. A repository may use one service name, Kubernetes another and the cloud account a third. Timestamps may use different zones. The team may know the owner even though the tools do not.

Connect those sources while keeping a link to the original data. The agent should be able to move from a user-facing check to the service, current deployment, related infrastructure, recent change and owner without guessing what names mean.

Access also needs care. The agent may read from several systems, but each source still needs its own permissions and audit record. Secrets and unrelated customer data should stay outside the investigation.

What healthy looks like: Record the user result, expected service behaviour, safe limits and checks that confirm recovery.
One name for each thing: Match services, environments, clusters, accounts, resources and deployments across the tools that use them.
Service connections: Keep the upstream and downstream links across applications, data, network, cloud and external services.
Monitoring data: Collect user checks, metrics, logs, traces and events with clear timestamps and source labels.
History of changes: Put code, configuration, infrastructure, feature, maintenance and traffic changes on one timeline.
Team knowledge: Connect owners, escalation paths, runbooks, known exceptions and incident results confirmed by engineers.
Safe access: Use a separate machine identity, permissions for each source and a record of what the agent reads or proposes.

A stronger model cannot fix missing names, broken timestamps or an old service map.

Let the agent write the first investigation draft.

This is the approach behind the Atomsized Observability Agent. It reads the approved environment context, then checks Kubernetes workloads, pod status, events, logs, Prometheus alerts, selected AWS resources and spend signals on a schedule.

Most checks should stay quiet. Normal deployment churn, short pod restarts and spot node rotation only need a report when the behaviour persists or affects a real workload.

When it finds something worth investigating, the agent writes a short Markdown report in the observability repository and posts it to Slack for review. The report states what happened, why it may matter, which evidence supports it and where the engineer should check next.

That level of automation removes repeated collection work and keeps the team informed. The responsible engineer reviews the finding, decides whether action is needed and owns the response through recovery.

Name the environment, service, affected user result and current owner.
Describe the finding and show what normal looked like before it.
Attach the useful evidence with clear sources and timestamps.
Connect recent deployments, configuration and infrastructure changes.
Show possible causes, weak links and missing information.
Suggest the next useful check for the responsible engineer.
Update the report when the evidence or affected service path changes.
Record whether the response restored the expected result.

Automate evidence collection and reporting. Keep production decisions with the responsible engineer.

Keep the response inside the usual delivery and recovery process.

The agent may need to read from monitoring, delivery and cloud systems. Changing those systems needs a much smaller set of permissions.

For Atomsized workflows, AI reads and prepares. Engineers decide and approve. Git records the accepted change. GitOps applies and reconciles it. AWS reports what happened in the running environment.

The incident summary should name the service owner, incident owner, proposed action, expected result, stop condition and recovery check. If the evidence changes before approval, the proposal should be updated.

Later, the team may allow one small and reversible response to run automatically. The identity, action limits, retries, time limit and stop conditions should be enforced outside the model. Changes to data, identity and networking should keep a stronger review.

The agent prepares the evidence and response. The responsible engineer owns the change and recovery.

Start with one incident your team already understands.

Trying to monitor the whole platform with AI creates too much scope for the first version. Choose one service path and one type of incident that experienced engineers already know how to investigate.

A good starting case has clear user impact, several useful data sources, a known owner and enough past incidents to test against. It should be safe to run with read-only access.

Write down the investigation before connecting the agent. Follow an engineer from the first alert to the confirmed recovery. Record the tools they open, the questions they ask and the points where missing information slows them down.

That path becomes the first monitoring skill. In read-only mode, the agent can run the checks on a schedule, prepare the report and show when the evidence points somewhere else.

1. Choose the incident: Choose the service, type of incident, affected user result, owner and evidence that confirms recovery.
2. Map the steps: List the tools, data sources, questions and decisions used during the investigation.
3. Connect the data: Give services stable names, align timestamps and provide read-only access to the evidence the agent needs.
4. Replay past incidents: Test the workflow with real incidents and near misses, including cases where the right answer is to wait or ask another owner.
5. Run reports beside the engineer: Let the agent publish live findings for the on-call engineer without changing production or paging more people.
6. Expand from results: Fix missing context and add another type of incident only after the first investigation path is dependable.

One person who owns the monitoring workflow and one owner for the service.
A written description of what healthy looks like for users, the service and its dependencies.
A service map connected to current ownership and escalation.
One timeline for monitoring data, application changes and infrastructure changes.
A read-only agent identity with limited access and an audit trail.
A set of real incidents with results confirmed by engineers.
One incident-summary format that shows evidence, missing information and other possible causes.
A review after the shadow period with a clear choice to improve, expand or stop.

One complete incident path teaches the team more than a broad monitoring demo.

Check whether the agent makes the investigation easier.

A clear explanation can still send the engineer in the wrong direction. Judge the agent by the help it provides during the investigation and by the evidence attached to its conclusions.

During replays and live shadow mode, compare its incident picture with the one built by the engineer. Record where it found useful information sooner, where it followed a weak link and where missing ownership or an old service map blocked it.

After each incident, the engineer confirms the cause, useful evidence, chosen response and recovery. Add those confirmed facts to the runbook, incident history and tests used by the monitoring skill.

Time from the first alert to a useful incident summary.
Conclusions that include a source, timestamp and affected service path.
Missing information found before the agent recommends a response.
Weak links or confident guesses the engineer needs to correct.
Checks and responses accepted, changed or rejected by the owner.
Recovery confirmed and recorded after the response.

The agent should learn from what the team confirmed after the incident.

Build useful context first.

AI monitoring becomes useful when the agent can see the platform around the alert. It needs to know what healthy looks like, how services connect, what changed, who owns the response and what happened in similar incidents.

It should keep one clear incident picture from the first signal to recovery. Engineers can see what is happening, which possible causes fit the evidence, what remains unknown and what to check next.

Start with one repeated investigation and run the agent beside the on-call engineer. Let it automate evidence gathering and reports while the team fixes the missing context that real incidents expose. Add another incident type when the first one is dependable.

Engineers remain responsible for decisions and production changes. The agent helps them reach those decisions with better information and less searching.

How Can You Trust AI Agents With Your Infrastructure? — The context, operating experience, permission boundary and recovery path an infrastructure agent needs before it prepares a change.
Why GitOps is so hard to explain and automate. — A practical operating model for proposals, engineer approval, reconciliation and evidence across AWS and Kubernetes.

Start the Observability Agent with one useful report.

We can map what healthy looks like, connect the evidence and automate a report your engineers can review before deciding what to do.

Schedule a platform call

From Shared Staging to Reviewable Environments

Boyan Iliev — Mon, 27 Jul 2026 06:00:00 +0000

One team deploys a feature for QA. Another needs to test a migration. Product wants a stable demo. Each request makes sense. A single shared environment forces them into the same queue.

Shared staging becomes a queue when several teams need it at the same time.

We have seen one deployment overwrite another, testers wait for a stable slot, demos block development work and teams lose track of which revision is running.

The name varies between teams: staging, stage, dev, test or UAT. We use shared staging to mean any environment where several changes have to take turns.

When several decisions wait for the same environment, they have to happen one after another. Engineering, QA and product repeat tests, screenshots and approvals, coordinate deployment windows and wait longer to move a change forward.

Extra permanent environments rarely clear that queue. A reviewable environment has one job: help someone make a specific decision about a known version of a change.

Shared staging slows down when reviews run in parallel.

Waiting and unclear targets cause the delay. A team loses confidence in a review when the target changes underneath it.

Changes collide: A newer deployment replaces the version somebody else is still testing.
Review waits: QA, product and engineering negotiate for a stable window instead of reviewing the work.
Results become unclear: A test result or screenshot may no longer match what is currently deployed.

Measure the wait as part of delivery time.

A staging queue often starts before the deployment metrics begin. We look at how long a change waits for its first useful review, how much work is repeated and how often a newer deployment makes earlier results out of date.

Review delay: Track the median time from ready for review to the first useful validation.
Time spent waiting: Record engineering, QA and product hours spent waiting, coordinating or repeating work.
Repeated review work: Count tests, demos and approvals that need to be repeated after a newer deployment.

Measure one application or service for two weeks. Compare its results over time instead of combining data from teams that work in different ways.

Build the smallest environment the review needs.

A reviewable environment has a clear purpose, a known source revision, an owner, clear rules for test data, visible health and a cleanup rule. It only needs the parts required for that decision.

A preview environment gives developers, testers, product teams and stakeholders their own reviewable version of a change. They can develop, test and demonstrate it without competing for shared staging.

When previews reuse existing Kubernetes capacity and shared platform services, the extra running cost can stay low. A short-lived namespace uses the cluster and services that are already running.

That changes when a preview needs dedicated nodes, databases, load balancers, large data sets or a long lifetime. Clear resource limits and automatic cleanup after a set time help keep costs under control.

Keep staging production-like. Preview environments should use the same built application versions, configuration patterns and deployment path, while scaling down safely and keeping production data out.

Preview, UAT and shared staging answer different questions.

Each stage supports a different kind of review.

Preview environment: Review one meaningful change quickly and in isolation.
Coordinated UAT: Test a fixed combination of services, repositories or business flows.
Shared staging: Keep it for final release checks and tests that need the full system in a common state.

Record each step from creation to deletion.

A pull request records the change. CI builds a fixed application version. Git records how the environment should be set up. Argo CD applies that setup and keeps it in sync. The URL, version, health and test results return to the pull request.

When the change is merged, closed or reaches its time limit, the environment definition is removed and the environment is cleaned up. Git history and review results remain available.

Start with the workflow that waits for shared staging most often.
Build one complete create, update, review and delete lifecycle.
Measure waiting time, failed environments and old environments that were not removed before adding more teams or services.

Fund one review path, then decide from the results.

Choose one staging bottleneck where work regularly waits or needs to be repeated. Run a 30-day pilot, then decide whether the team should spend more time and money on it.

Baseline: Measure the current wait, repeated work and environment cost for one review path.
Pilot: Build one complete create, update, review and delete lifecycle using the existing delivery controls.
Decide: After 30 days, extend, adjust or stop based on review delay, repeated work, stability and AWS spend.

After 30 days, ask whether reviews moved sooner and whether the workflow kept stability and AWS spend under control.

Start with a review that regularly waits.

Find the change that repeatedly waits for staging, give it one controlled review path and measure whether the queue gets shorter.

Shared staging keeps a clear job: final release validation and shared checks. Preview and UAT paths handle review work that needs isolation.

Preview environments for a monorepo team of five or more. - A practical GitOps design for isolated, disposable application states when one repository contains the complete source state.
Preview environments for a microservice architecture with 10+ repositories. - A GitOps operating model for single-service and coordinated previews across multiple repositories.

Turn one blocked review path into a controlled workflow.

We can map the smallest useful preview or UAT workflow around your repositories, GitOps controls and current AWS platform.

Schedule a platform call

What is HTTP, HTTPS, and SSL

Boyan Iliev — Mon, 08 Nov 2021 13:19:34 +0000

Introduction

If you are a developer, you probably know what an SSL certificate is. If you don't know what it is, don't worry. An SSL certificate is a must-have on any website. It lets your web browser connect to a web server securely. SSL stands for Secure Sockets Layer, and it is a digital certificate that allows for an encrypted connection.

But let's back it up a bit. First, we need to know what lets a web browser and a webserver connect. To connect with a website, we need HTTP.

What is `HTTP`?

HTTP stands for Hypertext Transfer Protocol and this protocol is used to transfer data from the web servers to web browsers. So if you ever visit a website you can notice the protocol being added at the beginning of the web address. So for example http://www.website.com. This protocol is used to view different web pages on the internet.

By default in standard HTTP, all of the information is sent in clear text. What this means is when you type something, it gets sent over the public internet which means that hackers can view it, because it's all sent over in clear text.

This isn't a problem, that is if you only browse a website, but if there are any passwords involved, or any other personal information, such as credit card information, then a hacker could easily get that info. Due to the fact it's being sent over the public internet, a hacker could listen in as the data is being transferred and could steal it.

If you ever have to type in personal information, you should always check if you have a secure connection. And for you to have a secure connection, you would need to use HTTPS.

What is `HTTPS`?

HTTPS is HTTP, but secure. That's why there is an S added. Hypertext Transfer Protocol Secure. What this does is encrypt the data that is being retrieved by HTTP. It lets all of the data that is being transferred between the server and the computer secure. The way it does that is by making the data impossible to read by encryption algorithms that mix up the data that's being transferred.

So whenever you are on a site and you have to enter a password or some credit card information, make sure the web address looks like this - https://www.website.com. This means that the data that you pass in will be protected. You can also notice a padlock to the left of the web address, which also indicates you are using a secure HTTP.

Thanks to the encryption algorithms the data we put in comes out all scrambled up so that hackers can't understand and decrypt it.

HTTPS secures the data thanks to a protocol called:

`SSL`

SSL stands for Secure Sockets Layer and it is a protocol that's used to establish security on the internet. But how exactly does SSL work? Well, it uses public-key encryption to secure data.

What this means is when a computer connects with a website that is using SSL, the computer's web browser will ask the website to say who it is or identify itself. Then the webserver will send the computer a copy of the SSL certificate it has.

An SSL certificate is a small digital certificate that is used to validate the identity of a website. Or in other words, this lets your computer know that the website you're visiting is reliable and trustworthy.

So then the browser of the computer can check if it trusts the certificate and if it does it will send a message to the web server, to which then the web server will respond with a response so that an SSL session can begin.

Most SSL certificates have to be paid for, but there are also some free ones, for example:

Let's Encrypt

Let’s Encrypt is a Certificate Authority (CA) that provides an easy way to obtain and install free SSL certificates, thereby enabling encrypted HTTPS on web servers. You could check this post out on How To Secure Nginx with Let's Encrypt on Ubuntu so that you can get a little bit more familiar with Let's Encrypt.

Conclusion

This may seem confusing at first, but it's best to get to know how the internet actually works and the different protocols that are out there. If you notice almost all of the sites nowadays have HTTPS instead of HTTP, even though there isn't any data to be transferred between servers, and that's because Google has started flagging websites as Not Secure because they aren't protected with SSL.

I hope that this post has helped you learn a little bit more about these protocols that you use daily and how they work.

How to get the size of a directory in Linux

Boyan Iliev — Thu, 04 Nov 2021 09:17:37 +0000

Introduction

Linux is one of the most popular operating systems in the world. It is Unix-like, and it is also open-source. Quite a big percentage of developers use Linux because it can be customized in so many ways.

What's cool about Linux is its command line. Every 'hackers' paradise. There are a ton of commands. If you aren't familiar with any Linux commands, be sure to check out this post on the 8 Linux Commands Everyone Should Know.

There is probably a command for almost anything that you want to do. For example what if you wanted to get the size of a directory? Well luckily for you there is a command for that. In this post, we are going to talk about that command and see what it can offer.

The `du` command

This command lets the user get a quick view of the disk usage. The best way to use it is by giving it the directory you want to see the size of. It should look a little something like this:

du directory_name

// output
2314    directory_name

This will give you the size of all the files and at the very end, it will give you the size of the directory itself. You could point out the full path, or you could just give the name of the directory you want to see if you are already on the same path.

But we could make this even easier just b adding 2 flags. Flags help the command change its behavior. For the du command we could add the flags -s and -h.

-s stands for summarize and it will show you only the total size of the directory, without all those files popping up on your screen.

-h stands for human-readable and it will convert the size so that you can read it easier. Just by running the command without the -h flag doesn't specify you a unit of measurement.

So now to get the best of this command, you should run it like this with the -s and -h flags:

du -sh directory_name

// output
44.5M   directory_name

And if you wanted to see all of the directories sizes, you could just run this:

du -sh ./*

// output
12.2M   dir1
 2.5M   dir2
  55M   dir3

Another thing you can do is use pipe(|) and sort them by size, which will make it even easier for you to see their sizes. What | does is get the output from the command behind it and add it into the input of the command after it. So to sort the directories by size just run the following command:

du -sh ./* | sort -h

// output
  55M   dir3
12.2M   dir1
 2.5M   dir2

Conclusion

This is a pretty useful command that I think everybody should know, just because of how short and easy it is. I hope that this post has helped you and I wish you happy coding.

How to Replace All Occurrences of a String

Boyan Iliev — Thu, 08 Jul 2021 17:33:02 +0000

Introduction

One of the main data types in JavaScript is strings. These data types are used for storing and manipulating text. And luckily for us, there are quite a few methods that help us in manipulating these data types.

These methods are one of the many built-in methods of JavaScript. This is because JS has some built-in objects. Some of them are: Array, Math and String. And for each object, some properties and methods are associated with them.

In this post we are going to see How to Replace All Occurrences of a String with the replaceAll() method.

`replaceAll()` Method

In order to use this method, we first have to create our string. Let's add randomly ! inside this strong so that we can remove it.

let intro = 'My! n!ame! i!s Bo!yan!';

Now to remove it, we have to write the strings name, then add the replaceAll method next to it, and pass in the first argument which element we want to be replaced or removed. An important thing is to remember that you have to save the new string into a new variable. It should look something like this:

let newIntro = intro.replaceAll('!', '')
console.log(newIntro);

<- My name is Boyan

Now if you want to replace the elements, just pass in the second argument as what you want it replaced with. Let's replace the whitespace with -.

let newerIntro =newIntro.replaceAll(' ', '-');
console.log(newerIntro)

<- My-name-is-Boyan

Conclusion

This is pretty much it to the replaceAll() method. It is the main method used, if not the only method, that replaces all occurrences of a string.

I hope that this post has helped you and I would love to hear some feedback in the comments below.

Introduction To MongoDB and How To Use It

Boyan Iliev — Tue, 29 Jun 2021 14:08:16 +0000

Introduction

MongoDB is a NoSQL (not only SQL) database. In NoSQL databases, we store our data in a collection of documents. These documents are very similar to JavaScript objects or JSON objects. So if you are familiar with JavaScript, then you are going to like Mongo, because it will be easier to get the hang of it.

MongoDB is very scalable. It has built-in replication and sharding. It's performant, it's fast, and mostly, it's very flexible. Because the data structure is like a JavaScript object, you don't have to map out your entire data structure beforehand as you do with relational databases. Unlike a relational database like MySQL, where you have to create all your tables and all your columns, Mongo gives you the freedom to structure your data however we want through our application. This doesn't mean it's better than relational databases, it all depends on how you need to use your database.

Installing MongoDB

We are going to install MongoDB through Homebrew. If you don't have Homebrew installed, just run the code below in your terminal and that will install Homebrew.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once you get Homebrew installed on your Mac, just run the three following commands. First, we run:

brew tap mongodb/brew

Then run:

brew install mongodb-community@4.4

Then after that, we will want to run it as a service with the following command:

brew services start mongodb-community@4.4

And finally, we need to run the following command so that we can connect and start using MongoDB.

mongo

This is what you should see after running the command:

Now that we have Mongo installed and ready, let's start with some of the main commands that you should know

Commands

Show Current Database

The command for seeing the current database is:

db

Show All Databases

In order to see all of the databases just run the following command:

show dbs

Switching and Creating Databases

If you want to switch which database you are using, just type in use followed by the database name.

use db_name

If you want to create a DB, just type in the use command again, followed by your new DBs name.

use new_db_name

If you run show dbs after creating a DB, the new DB won't show because it doesn't have anything in it, so don't worry when it doesn't show up after running the show dbs.

Dropping a Database

In order to drop a database, or in other words, delete it, you first need to switch to the database with the use command, and after that, you need to type in the following command:

db.dropDatabase()

Creating and Viewing Collections

To create a collection in the DB that you are using, you just have to run the following command and set the name of your collection:

db.createCollection('collection_name')

And if you want to view the collection, just run the show command followed by collections and that should print out the collections in your DB.

show collections

Inserting Rows

Now in order to insert a row, just type in the db followed by the name of the collection that you want to insert the row in, and then by insert, which is then followed by parentheses(). And in those parentheses, you pass in an object with whatever you want.

Here is an example of how this should look like:

db.users.insert({
    username: 'Batman_fan_44',
    followers: 3,
    following: [
        'Alred',
        'Robin'
    ],
    status: {
        name: 'Bruce Wayne',
        status: 'active'
    }
})

As you can see this looks just like a normal JavaScript object. You can store strings, numbers, arrays and can also have embedded objects inside. This is why Mongo is liked by so many, because of how similar it is to JS and how easy it is to use.

If you want to insert more than one row, instead of typing insert after the collections name, type in insertMany and then insert your rows in an array like this:

db.users.insertMany([
    {
        username: 'Tony Montana',
        followers: 1234
    },
    {
        username: 'Hannibal Lecter',
        followers: 5
    },
    {
        username: 'Rick Grimes',
        followers: 21
    }
])

These rows don't have as many stuff like likes or status. which our first row has, but that doesn't matter. Unlike relational databases, in Mongo, we don't have that strict data model that we have to follow. We can put whatever we want wherever we want, which is awesome!

Viewing Rows

To view the rows of a certain collection, just run the following command.

db.collection_name.find()

This will print out the data, but it will be hard to read. Luckily there is a method called pretty(), which formats all the rows.

db.collection_name.find().pretty()

And now it will be much easier to read.

These are some of the main commands that you should know. I recommend that you check out this MongoDB Cheat Sheet and have a look at some other commands that might be useful to you:

https://gist.github.com/bradtraversy/f407d642bdc3b31681bc7e56d95485b6

Conclusion

As you can see MongoDB looks identical to JavaScript. They have similar syntax and are pretty easy to get the hang of.

If you want to have a MongoDB database cluster production-ready, I strongly recommend using the new DigitalOcean managed MongoDB clusters which you can deploy with just the click of a button so that you won't have to worry about server maintenance, which can be very challenging sometimes.

If you want you can use this referral code which gives you free $100 DigitalOcean credit.

If you also want to learn more about SQL and how to use it, I highly recommend that you check out this Introduction to SQL opensource ebook. It helped me understand how to use SQL and I highly recommend it.

I hope that this post has helped you get more comfortable with using MongoDB and getting the hang of it.

How To Write Your First Node.js Script

Boyan Iliev — Tue, 08 Jun 2021 12:31:50 +0000

Introduction

Until recently(if you think that 2009 is recently), we could only run JS code in a web browser. Node is a JavaScript runtime that executes code outside of the browser. We can use the same JS syntax we know and love to write server-side code, instead of relying on other languages like Python or Ruby. You can build Web Servers, Command Line Tools, Native Apps(VSCode is a Node app!), Video Games, Drone Software, and a whole lot more.

In this post, I am going to show you how to write your first little Node script which will make you a directory with an HTML, CSS, and JavaScript file in it.

Getting Started

First, you need to check if you have Node installed on your machine. If you don't know if you have it, just go to the terminal and write:

node -v

This will print out the Node.js version which is currently installed. If you see an error and nothing prints, then you don't have Node installed.

In order to install Node, go to the node website and just press the download button.

https://nodejs.org/en/

After installing Node, we need to create a JavaScript file. Let's call this file script.js. In this file, we are going to write our script.

Now that we have Node installed and our file created, it's time to write our script. For this script, we are going to need to know what the process object is and how the fs module works.

How To Run Node Files

In order to run Node files, you just need to write node and then the file name next to it in the terminal. Th file must be in the same folder that you're in, or you need to reference that full path relative to where you are at the moment.

node script.js

`process` & `argv`

process is an object that's available which is in the global scope. It provides information about, and control over, the current Node.js process. It has a bunch of methods and properties. For example, we can see our current working directory.

process.cwd()

There is a method called process.argv. It returns an array containing the command line arguments passed when the Node.js process was launched. The first element will be the path where the node executable is, and the second will be the path to the JS file being executed. To call this method you need to go to your JS file and console.log() it.

console.log(process.argv);

Then after running your file, you should see this:

node script.js
[ '/usr/local/bin/node', '/Users/ghostman/scripts/script.js' ]

Any remaining element will be additional command-line arguments. We can pass them as arguments into a script. Not a function, but it's a similar idea. I can pass in arguments to a script.

Here is an example of a little script that prints out the additional command-line arguments:

const args = process.argv.slice(2)  -> slice to remove first two items.

for(let arg of args){
    console.log(`Hello ${arg}`)
}

Then when we run the file like this:

node script.js Batman Superman

Ou output should look like this:

Hello Batman
Hello Superman

This is a fun little script to help you understand how the file and node work together and how they can be used.

Now let's get to the fun part.

`fs` Module

The fs module enables interacting with the file system. It has hundreds of methods that you can use. Here is a list so you can see how much they are.

https://nodejs.org/dist/latest-v14.x/docs/api/fs.html

In order for us to use the fs module, we have to require it. We have to save it in a variable.

const fs = require('fs')

Now that we have our fs module, here are the methods that we will be needing for our script.

`fs.mkdirSync`

This method creates a directory in our current working directory. There is also an fs.mkdir method, but we will be using the synchronous method because it will not execute anything else until this method is completed. Here is an example of our method:

fs.mkdirSync('dirName')

`fs.writeFileSync`

This method creates files for us. Just like fs.mkdirSync, this method will not let anything else run until it has finished its process.

fs.writeFileSync('fileName')

You can check for errors with the try..catch statements if your code doesn't seem to work.

try {
    fs.writeFileSync('fileName')
} catch (e){
    console.log(e)
}

Writting Our Node Script

Now that you have a basic knowledge of Node, try writing a script that creates a directory with three files inside it on your own. If you can't, that OK. Here is how to write your script:

First, you need to require the fs module. Then you must use process.argv to set the name of your directory. After that, you need to use the fs.mkdirSync method and the fs.writeFileSync method to create the directory and the files:

const fs = require('fs')
const folderName = process.argv[2] || 'Project'

try {
    fs.mkdirSync(folderName);
    fs.writeFileSync(`${folderName}/index.html`);
    fs.writeFileSync(`${folderName}/style.css`);
    fs.writeFileSync(`${folderName}/app.js`);
} catch (err) {
    console.log(`Error!`);
console.log(err)
}

After writing the code for the script, we can run it like this:

node script.js SecretProject

If we don't give an additional command-line argument, it will automatically set the directory name to Project.

Consclusion

I hope that this post has helped you understand Node.js a little bit more and made you more comfortable with it. Don't be scared to try some new stuff and experiment with all those fs module methods.

Let me know if this has been of help to you through Twitter. You can follow me here.

8 Linux Commands Everyone Should Know

Boyan Iliev — Thu, 06 May 2021 07:25:17 +0000

Introduciton

It's a well-known fact that developers use terminals. And using a terminal is something that everybody should know. It is a good thing to know and do because it will help you in so many ways. It will help you in that job interview, or just in your everyday life. You must at least have the basic knowledge of how to use a terminal. For example how to change directories and view them and how to create a file.

In this post, I am going to show you some of the basic commands and how to get around in a terminal and not be completely lost.

1. `pwd`

pwd means Print Working Directory. It shows you the full path to your current directory. This is used so you don't get lost in all those directories that you have. If you don't know what a directory is, it is pretty much like a folder. It stores other folders and files in it.

pwd
/Users/user1

2. `ls`

The ls stands for List Files. It will show you the files and directories that are in your current directory.

ls
xmen avengers justiceLeague

3. `cd`

Now that you know how to list your files in your working directory and how to print the path to it, you will need to Change Directory. This is done by typing the cd command. You just have to type it and then next to it type the directory you want to visit. But this command only moves forward and backward. This means you can't just type a directory name that is deep inside your files just by typing its name. You have to type the full path to that dir.

cd avengers

If you want to go in multiple dirs, you need to use / after every dir, and then type the directory you want to visit inside the previous one.

cd ironMan/suitMark85

If you want to go back one dir, you need to type cd ... You could mix this with other dir like this:

cd ../../captainAmerica/steveRogers

Or if you just type cd by itself, it will send you to the home directory.

4. `mkdir`

Now that we know how to go to a directory and how to view what's inside them, we need to learn how to make one. It is done through the mkdir command. You just type the command and add the new directory name next to it.

mkdir secretDir

If you want to create multiple dir at once, just type all of them next to each other.

mkdir secretDir1 secretDir2 secretDir3

When doing these kinds of things be sure to use the pwd command so you know in which dir you are so that you don't create the new dirs in the wrong one.

5. `man`

The man command is used to check the manuals of a certain command. When you are not sure what a command does and what to have a detailed look at it, just type the man command and add the other command next to it.

man ls

When you are done viewing the manual, press q so that you can leave the file.

6. `touch`

The touch command creates a file (or multiple). It is almost the same as mkdir, but it's not used for making directories but for files with an extension(.txt, .html, .css ...).

touch index.html style.css app.js

7. `nano`

nano is a text editor using a command-line interface. When you create a file and want to add something small to it, just use nano to add it.

In order to edit a file, just type nano and the file name next to it.

nano index.html

Note that if there isn't such a file in your directory, for example, the index.html one, it will create a new one. So this means that you wouldn't need to use the touch command. bUt it's best to create a file with touch and then go to your code editor and do your coding there. nano is best used for those minor changes like for example a typo.

There are some shortcuts that would be nice for you to know. I would recommend checking this post out on some of those shortcuts.

11 Nano shortcuts that you should know

8. `rm`

Now that we know how to view dirs, create them, create files and edit them, we need to learn how to delete them. Deleting a dir or file is done with the rm command. You definitely want to be careful with this, because if you delete a file or dir, you won't be able to get it back. So if you want to delete a file just type rm and then the file name. Or if you want to remove multiple files, just type their names next to each other

rm index.html style.css app.js

Now if you want to remove a directory you can use rmdir, but this will only remove a dir that is empty. In order to delete a dir that is not empty, use the rm command with the flags -rf. If you don't know what flags are, think of them as extra options for your command. The ls command has lots of flags. I would recommend that you check the manual of the ls command so that you can see all its available flags.

So deleting a directory with other dirs or files inside should be done like this:

rm -rf avengers

Be very careful with these commands because if you delete a file or dir by accident, you won't be able to get them back

If you want to see some examples and a more detailed explanation for some of these commands be sure to check out this video:

Conclusion

Knowing how to use a terminal is crucial. It is. a huge bonus to know at least these commands, which will help you a lot.

I hope that this post has helped you and that you will be a little bit more confident the next time you see a terminal.

Introduction To JavaScript Promises

Boyan Iliev — Tue, 27 Apr 2021 15:23:09 +0000

Introduction

A Promise is an object representing the eventual completion or failure of an async operation. A promise is a returned object to which you attach callbacks, instead of passing callback into a function.

`new Promise`

In order to make a new Promise you need to write new Promise and then it will expect you to pass in a function with two arguments which are functions. The first one represents the resolution of this promise and the second one the rejection of this promise.

const requestPromise = (url) => {
    return new Promise((resolve, rejects) => {
        const delay = Math.floor(Math.random() * (4500)) + 500;
        setTimeout(() => {
            if(delay > 4000) {
                reject('Connection Timeout :(')
            } else {
                resolve(`Here is your fake data from ${url}`)
            }
        }, delay)
    })
}

Now in order to call the function multiple times with different URLs, we need to use the then method. The then method returns data if the async request is returned. But if the operation is failed, we must use the catch method. This is how it should look like:

requestPromise('reddit.com/api/chicken/page1')
    .then(() => {
        console.log('PAGE1 WORKED!!');
        requestPromise('reddit.com/api/chicken/page2')
            .then(() => {
                console.log('PAGE2 WORKED!!');
                requestPromise('reddit.com/api/chicken/page3')
                    .then(() => {
                        console.log('PAGE3 WORKED!!');
                    })
                    .catch(() => {
                        console.log('PAGE3 ERROR!!');
                    })
                    .catch(() => {
                        console.log('PAGE2 ERROR!!');
                    })
            })
            .catch(() => {
                console.log('PAGE1 ERROR!!');
            })
    })

As you can notice this is very long and repetitive. We can make it shorter and cleaner by using only one catch. In order for this to work, we need to return a promise from within our callback.

requestPromise('reddit.com/api/chicken/page1')
    .then(() => {
      console.log('PAGE1 WORKED!!');
      return requestPromise('reddit.com/api/chicken/page2')
    })
    .then(() => {
    console.log('PAGE2 WORKED!!');
    return requestPromise('reddit.com/api/chicken/page3')
    })
    .then(() => {
        console.log('PAGE3 WORKED!!');
    })
    .catch(() => {
        console.log('REQUEST FAILED!');
    })

Promises are resolved and rejected with values.

requestPromise('reddit.com/api/chicken/page1')
    .then((data) => {
      console.log('PAGE1 WORKED!!');
        console.log(data);           
      return requestPromise('reddit.com/api/chicken/page2')
    })
    .catch((err) => {
        console.log('REQUEST FAILED!');
        console.log(err);
    })


// IF IT WORKS IT WILL PRINT:
// PAGE 1 WORKED!!
// Here is your fake data from reddit.com/api/chicken/page1

// IF IT DOESN'T WORK:
// REQUEST FAILED!
// Connection Timeout :(

This is coming from a function.

`async` Functions

A newer and cleaner syntax for working with async code! It's still the same thing as a promise, but it's "prettier". There are two keywords that you need to know.

`async` keyword

1. Async functions always return a promise

2. If the function returns a value. the promise will be resolved with that value.

3. If the function throws an exception, the promise will be rejected.

async function hello(){   
}
//-> returns a promise even if empty


const sing = async () => {  
}
// -> we can use async arrow functions

Here are some examples:

const login = async (username, password) => {
    if(!username || !password) 
    throw 'Missing Credentials'
    if(password === 'password') 
    return 'Welcome!'
    throw 'Invalid Password'
}

login('demonslayer64')
    .then(msg => {
        console.log('LOGGED IN!')
        console.log(msg)
    })
    .catch(err => {
        console.log('ERROR!')
        console.log(err)
    })

//Returns:
ERROR!
Missing Credentials

login('demonslayer64', 'slayerdemon46')
    .then(msg => {
        console.log('LOGGED IN!')
        console.log(msg)
    })
    .catch(err => {
        console.log('ERROR!')
        console.log(err)
    })

//Returns:
ERROR!
Invalid Password

login('demonslayer64', 'password')
    .then(msg => {
        console.log('LOGGED IN!')
        console.log(msg)
    })
    .catch(err => {
        console.log('ERROR!')
        console.log(err)
    })

//Returns:
LOGGED IN!
WELCOME!

`await` keyword

1. The `await` keyword is used inside of functions declared with async.

2. `await` will pause the execution of the function, waiting for a promise to be resolved.

Here is an example with our function from earlier:

async function makeTwoRequests() {
    let data1 = await requestPromise('/page1');
    console.log(data1);
}

//Returns
<- >Promise {<pending>}
Here is your fake data from /page1

Conclusion

This is pretty much the basics of JavaScript promises. Let me know if this has helped you at all. Any feedback will be greatly appreciated!

How To Write A Good README File

Boyan Iliev — Thu, 22 Apr 2021 07:20:31 +0000

Introduction

If you're familiar with GitHub, then you know what a README file is. But if you don't know what it is, you can think of it as the introduction to your repository. It's very helpful that while looking at someone's repo you can just scroll down to their README file and have a look at what their project is all about.

It's crucial that your project gets introduced properly because if it isn't, the chances of someone pressing on the repo are low. That's why having a good README file shouldn't be overlooked and you should spend a good amount of your time on it.

In this post, I am going to share some tips with you about how you can improve your README file, and hopefully, it can help you with your repos.

Choose an easy name for your project

Before we dive into the README.md file let's quickly mention the name of the project itself.

When people search for different projects, the last thing they will want to see is:

"cool-javascript-game-about-colors-and-rgb-colors-and-even-more-colors"

Now I know that this example is a little over-exaggerated, but you get the point. No one is going to press on a repo with such a long name. It's best if you try to have a simple and short name for your project that gets right to the point.

So for the example, above we could just use:

"javascript-color-game"

A name like this has a higher chance of getting clicked on and taken a look at. So make sure that your repos name is simple and straight to the point.

Give a descriptive summary of your project

Now that we have the repo name cleared out, let's focus on the README.md file!

When someone visits your repo they can scroll down and read the README file. It should have a description of what your project is. But you wouldn't want it to be too short. And neither should it be too long. Now if it's a very big project then by all means you should give a proper explanation of what it is and what it does. But in most cases, it should be a well-written and structured text. There are five steps that I would recommend you follow while writing your README file.

Step #1

Write a quick introduction to what the project is about. For example, if you made a to-do list using JavaScript, write about that. But don't get into too much depth.

Step #2

Write what your code uses. For example HTML, CSS and JavaScript.

Step #3

Write a few more details about the project. Write things that would make you take interest in the project.

Step #4

Write something about yourself. You could say where you work, what your goals are, or share some of your previous projects. It's okay to share what you have created or what you are trying to accomplish

Step #5

And finally, use images. Show the reader what exactly the project is. Just by reading about it isn't going to get their full interest. But by seeing an image of it, they will be more likely to get more into it.

Conclusion

And these are some tips about writing a good README file. It's very important that you get comfortable writing these things. It could help you change the level of interaction your GitHub repo gets.

I hope that this post has helped you in improving your README files and I hope to see some great repos with great README files out on GitHub soon.

5 Tips On How To Stay Motivated And Productive As A Developer

Boyan Iliev — Tue, 13 Apr 2021 08:00:15 +0000

Introduction

Whether you are a senior developer, or you have just started getting into code, there comes a time when you start losing motivation. It is normal to lose motivation and that lack of motivation can sometimes stick for a long time. Unfortunately, there can be hundreds of reasons that can make you lose motivation. For example, you can't get your code to run the way you want it to. This happens to a lot of us and it can be hard to get back to being productive.

In this post, I would like to share with you some tips that you can try to help you stay motivated or get that motivation back.

Stay off your phone

It's no secret that our mobile devices are very addictive. Of course, some people can't afford to stay off their phone because it is connected with their work. But for most of us, it is a big waste of time. When we surf the internet we can really lose motivation. Spending way too much time on social media, YouTube, or Netflix can make us lose motivation and even make us depressed. This is why when you start feeling down and feel that you are getting a little unproductive, just leave your phone at the other end of the room. Or just try to stay off of it for as long as you can.

I noticed that this really helped me to be more concentrated and made me enjoy much more the time I spent coding.

Set mini-goals for you to complete

If you don't have a daily to-do list, I highly recommend that you make one. You can add in it all the stuff that you want to achieve the next day. So the night before you go to bed make a list and add a few small tasks to it. Some that will be helpful for you, but at the same time not that hard. When you finish one of those tasks and see the progress that you've done when crossing it out from your list will give you a boost of motivation.

Also, I would recommend that you try to complete the hardest tasks first. I personally prefer to get them out of the way first and then do the other stuff.

Wake up properly

The worst thing to do when you wake up is to get straight away on your phone. You've just slept 7-10 hours and you're body is dehydrated and your brain is confused. And it's not the best idea for your eyes to be staring at a screen before they have even opened up yet.

I would recommend that you lay in bed for 5 minutes so that you can fully wake up. Then go drink as much water as you can so that you can hydrate after a night of sleeping. Try to stay off any screens for as long as you can in the morning so that your body and mind can get ready for the day. You will feel much more energetic and will have all the power to do all of the stuff that you have to.

Surround yourself with tech-related stuff

Try to make the stuff you do during the day as connected to web development as possible. Seeing what other people create and the knowledge their share on all the different web dev community websites really makes you feel like you are a part of something big and lift you up. Try to chat with as many developers as you can. We have such an amazing community that just by getting surrounded by it can give you the motivation you need. Some of these sites are the DevDojo website and DEV. Also, another cool thing is the daily.dev extension.

Try sharing some of your knowledge or share a project your working on. See all the feedback you get. You can learn so many things that way. Or you can help someone else learn something. It's really fun and it can really boost your motivation and productivity when you see other developers that have the same interests as you.

And finally:

Look back at the things you have accomplished

When you think that you are stuck and can't get anywhere, for example, if you don't know how to get your code to run properly, just sit for a moment and think of how you used to be when you started programming. Think of all the progress that you have made in the last couple of months. This can boost your motivation and productivity by seeing how far you've come.

Conclusion

These things have really helped me stay motivated and productive. I kept losing motivation because I had to study for my exams and then I couldn't get motivated to code. When I started using these tips, I became more motivated than I have ever been.

I hope that this post has helped you get more productive and motivated!

DEV Community: Boyan Iliev

Does Your AI Agent Have a Kill Switch?

The agent had the wrong picture of its environment.

Make the environment prove what the agent can reach.

Give the engineer a live view of the task.

Keep the plan, live work and stop path together

A kill switch must stop access as well as reasoning.

Keep engineers close to actions that change the system.

Begin with one task and rehearse the stop.

Test what happens after the button is pressed.

Design the stop before the agent starts.

Related articles

How Should AI Monitor Your Infrastructure?

The agent should join the investigation early.

Give the agent a clear map of the platform.

Connect the user problem to the recovery

The agent can only use the context you prepare.

Let the agent write the first investigation draft.

Keep the response inside the usual delivery and recovery process.

Start with one incident your team already understands.

Check whether the agent makes the investigation easier.

Build useful context first.

Related articles

From Shared Staging to Reviewable Environments

Shared staging slows down when reviews run in parallel.

Measure the wait as part of delivery time.

Build the smallest environment the review needs.

Preview, UAT and shared staging answer different questions.

Record each step from creation to deletion.

Fund one review path, then decide from the results.

Start with a review that regularly waits.

Related articles

What is HTTP, HTTPS, and SSL

Introduction

What is HTTP?

What is HTTPS?

SSL

Let's Encrypt

Conclusion

How to get the size of a directory in Linux

Introduction

The du command

Conclusion

How to Replace All Occurrences of a String

Introduction

replaceAll() Method

Conclusion

Introduction To MongoDB and How To Use It

Introduction

Installing MongoDB

Commands

Show Current Database

Show All Databases

Switching and Creating Databases

Dropping a Database

Creating and Viewing Collections

Inserting Rows

Viewing Rows

Conclusion

How To Write Your First Node.js Script

Introduction

Getting Started

How To Run Node Files

process & argv

fs Module

fs.mkdirSync

fs.writeFileSync

Writting Our Node Script

Consclusion

8 Linux Commands Everyone Should Know

Introduciton

1. pwd

2. ls

3. cd

4. mkdir

5. man

6. touch

7. nano

8. rm

Conclusion

What is `HTTP`?

What is `HTTPS`?

`SSL`

The `du` command

`replaceAll()` Method

`process` & `argv`

`fs` Module

`fs.mkdirSync`

`fs.writeFileSync`

1. `pwd`

2. `ls`

3. `cd`

4. `mkdir`

5. `man`

6. `touch`

7. `nano`

8. `rm`

`new Promise`

`async` Functions

`async` keyword

`await` keyword

1. The `await` keyword is used inside of functions declared with async.

2. `await` will pause the execution of the function, waiting for a promise to be resolved.