<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Stephanie Ebolue</title>
    <description>The latest articles on DEV Community by Stephanie Ebolue (@stephanie_ebolue_323ca8d3).</description>
    <link>https://dev.to/stephanie_ebolue_323ca8d3</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3985284%2Fb1caa54e-b4ac-4549-b5e6-b7ac3271bfd5.png</url>
      <title>DEV Community: Stephanie Ebolue</title>
      <link>https://dev.to/stephanie_ebolue_323ca8d3</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/stephanie_ebolue_323ca8d3"/>
    <language>en</language>
    <item>
      <title>I Lost My Cloud Resume to a Corrupted File — Here’s the GitHub Lesson I Needed</title>
      <dc:creator>Stephanie Ebolue</dc:creator>
      <pubDate>Fri, 19 Jun 2026 09:32:39 +0000</pubDate>
      <link>https://dev.to/stephanie_ebolue_323ca8d3/i-lost-my-cloud-resume-to-a-corrupted-file-heres-the-github-lesson-i-needed-5060</link>
      <guid>https://dev.to/stephanie_ebolue_323ca8d3/i-lost-my-cloud-resume-to-a-corrupted-file-heres-the-github-lesson-i-needed-5060</guid>
      <description>&lt;p&gt;I’ll be direct about what happened.&lt;br&gt;
While building my Cloud Resume on AWS, I lost several hours of work to a corrupted local file. My HTML was structured. My CSS was clean. My GitHub repository was completely empty — because I hadn’t prioritized pushing to it.&lt;br&gt;
I’m writing this not as a cautionary tale, but as a practical argument for something I now consider non-negotiable: version control as a discipline, not an afterthought.&lt;/p&gt;

</description>
      <category>github</category>
      <category>cloudresume</category>
      <category>devops</category>
    </item>
    <item>
      <title>Set an AWS Billing Alarm Right Now — Before You Do Anything Else</title>
      <dc:creator>Stephanie Ebolue</dc:creator>
      <pubDate>Fri, 19 Jun 2026 09:29:16 +0000</pubDate>
      <link>https://dev.to/stephanie_ebolue_323ca8d3/set-an-aws-billing-alarm-right-now-before-you-do-anything-else-1dbn</link>
      <guid>https://dev.to/stephanie_ebolue_323ca8d3/set-an-aws-billing-alarm-right-now-before-you-do-anything-else-1dbn</guid>
      <description>&lt;p&gt;Hey devs 👋&lt;br&gt;
Quick one today — if you’re new to AWS (or even if you’re not), this is your reminder to set a billing alarm if you haven’t already.&lt;br&gt;
AWS is pay-as-you-go, which means every running service is potentially adding to your bill. A billing alarm through CloudWatch + SNS will email you the moment your charges cross a threshold you define. Think of it as a smoke detector for your AWS account.&lt;br&gt;
Steps:&lt;br&gt;
    1.  AWS Console → search CloudWatch&lt;br&gt;
    2.  Alarms → Create Alarm&lt;br&gt;
    3.  Select Metric → Billing → Total Estimated Charge → USD&lt;br&gt;
    4.  Set threshold (I use $5 as a starting point)&lt;br&gt;
    5.  Create SNS topic → enter your email&lt;br&gt;
    6.  Confirm the subscription email from AWS ← CRITICAL STEP&lt;br&gt;
    7.  Name the alarm → Create&lt;br&gt;
The trap everyone falls into: AWS sends a confirmation email for the SNS subscription. If you don’t click that link, the alarm exists but will never notify you. Check spam. Confirm it. Then you’re good.&lt;br&gt;
Total time: ~5 minutes.&lt;br&gt;
Total peace of mind: immeasurable.&lt;br&gt;
Go set it up. Your wallet is counting on you. 💸☁️&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
