DEV Community: Sherif sani

100 Days of devops

Sherif sani — Thu, 09 Apr 2026 17:02:17 +0000

Day 1 of 100 Days of DevOps: Securing Service Accounts

So, I’ve officially started the 100 Days of DevOps on KodeKloud Engineer.

My goal is simple:

Solidify what I already know
Bridge the gaps in what I don’t

Before diving into the technical logs, I want to share a bit about where I’m coming from.

My Background

I’m currently a Computer Science student and working as a Software Engineer.

For a long time, I’ve had my sights set on becoming a Solutions Architect.

I’m already quite comfortable with:

Cloud technologies
System architectures
The standard DevOps toolkit

But if I’m being honest… I’ve been playing it safe.

I stayed in my comfort zone instead of fully chasing that goal.

This challenge is my way of breaking that cycle and intentionally moving toward the career I actually want.

Day 1: Securing Service Accounts

Today’s task was simple, but very fundamental:

Create a service user on a remote server without allowing interactive login

The Scenario

SSH into a remote instance
Create a user called app-service
Ensure:
- No home directory
- No interactive login

This user is meant for background processes — not humans — so security is key.

✅ The Solution

After connecting via SSH, I ran:

sudo useradd -r -M -s /usr/sbin/nologin app-service

Breakdown

-r (System User)
Creates a system account with a lower UID.
These accounts are typically hidden from login screens and reserved for services.

-M (No Home Directory)
No need to create /home/app-service.
This keeps the filesystem clean and reduces risk if the account is compromised.

-s /usr/sbin/nologin (Non-interactive Shell)
This is the security lock 🔒
Even if someone gets access to this account, they cannot start a shell session.
The system simply denies login attempts.

Key Takeaway

This is a perfect example of the Principle of Least Privilege:
Give a user exactly what they need — and nothing more.

Closing Thoughts

It’s a simple one-liner, but it reinforces a critical DevOps mindset:
security and intentional design at every level.

Day 1 done. Thank you for reading

A tiny Spring Boot 'profile' microservice — Stage‑0 HNG backend

Sherif sani — Wed, 22 Oct 2025 19:46:26 +0000

I built a minimal Spring Boot service for my HNG Stage‑0 backend task that returns a profile object plus a fun cat fact. The goal was to deliver a clear, runnable microservice in a few files so reviewers can quickly run and inspect the code.

What it does

Exposes GET /me
Returns a JSON payload with status, a small user profile (name, role, links), a timestamp, and a cat fact fetched from https://catfact.ninja/fact

Architecture (short)

ProfileController — handles /me and returns a ProfileResponse DTO.
ProfileService — builds the profile and fetches the external cat fact using Java HttpClient.
Profile (domain) and ProfileResponse (DTO) — simple POJOs for shape and serialization.
Spring Boot entrypoint and a single minimal unit test to ensure application context loads.

Why this shape?

Minimal surface area: reviewers can audit the domain, controller, and service quickly.
External call isolated in the service so it’s easy to mock or replace.
Small codebase is ideal for early-stage tasks and focused feedback.

How to run locally

From the project root (uses the included Maven wrapper):

./mvnw spring-boot:run

Then open: http://localhost:8080/me

What I learned / next steps

Keep services focused and small for fast review cycles.
Inject HttpClient (or a wrapper) to make the external API call testable and mockable.
Add structured error handling and logging for robustness.
Add unit tests that mock the cat-fact API and an integration test for the controller.

check the repository: here

Turning My Notes Into Audio with AWS (Serverless + Terraform)

Sherif sani — Sat, 09 Aug 2025 22:26:40 +0000

About a month ago, I had this random thought while on the bus to school:

“What if I could just listen to my handwritten notes instead of reading them?”

I wanted something simple, cost-effective, and since I already spend a lot of time working with AWS, it made sense to build it there.

After a bit of brainstorming, I landed on the perfect stack:

Amazon Textract → Extract text from my images.
Amazon Polly → Turn that text into natural-sounding speech.
AWS Lambda + API Gateway → Keep it serverless and cost-friendly.
Amazon S3 → Store my uploaded images and generated audio files.

And because I’m all about infrastructure-as-code, I deployed the whole thing with Terraform.

The Architecture

Here’s a high-level look at how it works:

Simple, serverless, and cheap to run, which is exactly what I needed.

Why These Services?

Amazon S3 – Stores images and audio files.
Amazon Textract – Extracts text from scanned or photographed documents.
Amazon Polly – Turns text into speech.
AWS Lambda – Runs the logic without managing servers.
API Gateway – Provides a REST API endpoint for the client.
Terraform – Automates the entire setup so it’s reproducible.

Provisioning with Terraform

Instead of manually clicking around in the AWS Console, I used Terraform to define everything:

S3 buckets for images and audio
Lambda function with IAM permissions
API Gateway endpoint
Access for Textract and Polly

Deployment was as simple as:

terraform init
terraform apply

A few minutes later, everything was live. No console clicking. No missed resources.

How the App Works

The user uploads an image via the API Gateway endpoint.
The image is stored in S3.
Textract extracts the text from the image.
Polly converts the extracted text into an MP3.
The MP3 is saved to another S3 bucket.
A pre-signed URL is generated so the user can listen or download it.

When I tested it with a snapshot of my lecture notes, I got an audio file back in seconds. The best part? Since it’s all serverless, I only pay for what I use — perfect for a student budget.

Final Thoughts

This was a fun way to mix AWS AI services, serverless architecture, and Terraform into a single project. Now I can “read” my notes while walking, commuting, or even cooking — and it costs just a few cents per use.

That said… Polly’s voice still sounds a bit robotic at times. But for this use case, it works well enough, and the build was worth it.

If you want to try it out or see how it’s built:

Code & Terraform → GitHub Repo
Live Demo → audio-notes-client.vercel.app

Deploying a Full-Stack App on AWS ECS with Docker: From Code to Cloud

Sherif sani — Wed, 14 May 2025 20:53:28 +0000

In the ever-evolving world of web development, one of the most empowering things you can do is take your application from local development all the way to the cloud — and that’s exactly what I did.

Over the past few days, I built and deployed a full-stack application consisting of a React frontend and an Express.js backend, fully containerized and hosted on AWS ECS using Fargate. Here’s a look behind the scenes of how I transformed lines of code into a cloud-native, production-grade deployment.

The Stack

Frontend: React (built with Vite) repo
Backend: Node.js + Express repo
Containerization: Docker
Cloud Hosting: Amazon ECS with Fargate
Container Registry: Amazon ECR

Building the Application

The architecture was simple but effective: a React frontend communicating with an Express backend. I began by developing both apps locally and testing them with Docker to ensure container compatibility.

Frontend Setup Highlights

Built using Vite for lightning-fast bundling
Dockerized into a lightweight Nginx container
Served static files from /usr/share/nginx/html

Backend Setup Highlights

RESTful API built with Express
Dockerized using a minimal Node Alpine base image
Exposed port 3000 for requests

Dockerization

Each app was placed in its own Docker container with production-ready configurations.

# Build images
docker build -t doot-frontend .
docker build -t doot-backend .

# Authenticate to ECR
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin <account-id>.dkr.ecr.us-east-1.amazonaws.com

# Tag and push
docker tag doot-backend <account-id>.dkr.ecr.us-east-1.amazonaws.com/doot-backend
docker push <account-id>.dkr.ecr.us-east-1.amazonaws.com/doot-backend

☁️ Deploying with Amazon ECS + Fargate

Here’s where the magic happened:

🔹 Step 1: Create ECS Cluster

Created a new cluster using Fargate launch type. No EC2 instances needed!

🔹 Step 2: Task Definitions

Defined a task for both the frontend and backend:

ECR container image
Port mappings
Memory/CPU settings

🔹 Step 3: ECS Services

Deployed tasks as services, enabling auto-restarts, load balancing (optional), and easier scaling.

🔹 Step 4: Networking & Security

Placed tasks in public subnets
Enabled auto-assign public IP
Allowed traffic on ports 80 (frontend) and 3000 (backend) using security groups

Going Live

Once deployed, I could access the React frontend via the public IP of the ECS task. It successfully made API calls to the backend.

The satisfaction of seeing everything work together — no server to maintain, fully cloud-native — was amazing.

Key Takeaways

Fargate removes the burden of server management.
Properly configuring networking and security groups is crucial.
Dockerizing both frontend and backend simplifies deployment.
Amazon ECR is a reliable and scalable container registry.
You don't have to be a cloud expert to get started — just patient and persistent.

Final Thoughts

This project was more than just deploying an app — it was about leveling up.

I bridged the gap between development and DevOps, and it deepened my confidence in building, shipping, and scaling full-stack applications in a modern, cloud-native way.

Automating NBA Game Results Delivery with AWS Lambda, EventBridge, and SNS

Sherif sani — Sat, 25 Jan 2025 15:59:24 +0000

Introduction

Are you a basketball fan who doesn’t want to miss out on NBA game results? In this blog post, I’ll walk you through how I automated the process of fetching NBA game results using SportsAPI, AWS Lambda, EventBridge, and SNS to deliver the results via email or SMS.

By the end, you’ll learn how to set up a serverless solution with AWS services and schedule it to run daily.

Overview of the Solution

Here’s how the system works:

Data Source: Fetching NBA game results using SportsAPI.
AWS Lambda: Running the Python script to fetch data and send notifications.
Amazon EventBridge: Scheduling the script to run daily.
Amazon SNS: Delivering the results via email/SMS.

Requirements

An AWS account with access to Lambda, SNS, and EventBridge.
A SportsAPI API key (create one here).

Step-by-step Implementation

Creating the SNS Topic

Navigate to SNS, then Topics
Create a Topic
- Topic type: Standard
- Name: Any name of your choice
- Leave other fields blank or default, and click Create
Create a Subscription
- Navigate to the newly created topic and click Create subscription

Fill in these details:

 Topic ARN: The ARN of the created topic
 Protocol: Email (or SMS)
 Endpoint: Your email address

A confirmation email will be sent. Open it and hit Confirm.

Creating a Policy and Role for the Lambda Function

Navigate to the IAM Dashboard
Create a Policy
- Click Policies → Create policy

Choose Lambda as the service and add the following JSON under Policy Editor. Replace arn:aws:sns:REGION:ACCOUNT_ID:topic-name with your topic ARN:

 {
     "Version": "2012-10-17",
     "Statement": [
         {
             "Effect": "Allow",
             "Action": "sns:Publish",
             "Resource": "arn:aws:sns:REGION:ACCOUNT_ID:topic-name"
         }
     ]
 }

Review, name it (e.g., sns_publish), and create it.

Create a Role
- Go to Roles → Create role

Select AWS Service → Lambda as the trusted entity.
Attach the previously created policy (sns_publish).
Name the role (e.g., nba_function_role) and create it.

Creating the Lambda Function

Navigate to Lambda → Create function
Function Details
- Name: nba_function
- Runtime: Python
- Execution Role: Select the previously created role (nba_function_role).
Add the Code

Replace the default code with the provided Python script.

import json
import urllib.request
import boto3
import datetime
import os
from botocore.config import Config

def lambda_handler(event, context):
    # Configure boto3 with shorter timeout
    config = Config(
        connect_timeout=2,
        read_timeout=2
    )
    sns = boto3.client('sns', config=config)

    # Get environment variables
    API_KEY = os.getenv('API_KEY')
    SNS_TOPIC_ARN = os.getenv('SNS_TOPIC_ARN')

    today_date = datetime.datetime.now().strftime("%Y-%m-%d")
    print(f"fetching games for {today_date}")

    api_url = f"https://v1.basketball.api-sports.io/games?league=12&season=2024-2025&date={today_date}"
    headers = {
        'x-rapidapi-host': "v1.basketball.api-sports.io",
        'x-rapidapi-key': API_KEY
    }

    # Set timeout for the HTTP request
    req = urllib.request.Request(api_url, headers=headers, method="GET")

    try:
        # Send the HTTP request with timeout
        with urllib.request.urlopen(req, timeout=2) as response:
            response_data = response.read().decode('utf-8')
            data = json.loads(response_data)

            # Process games more efficiently using list comprehension
            messages = [
                f"{game['teams']['home']['name']} ({game['scores']['home']['total']}) vs "
                f"{game['teams']['away']['name']} ({game['scores']['away']['total']})"
                for game in data.get('response', [])
            ]

            if messages:
                final_message = "\n".join(messages)
                sns.publish(
                    TopicArn=SNS_TOPIC_ARN,
                    Message=final_message,
                    Subject=f"Games for {today_date}"
                )
                return {
                    'statusCode': 200,
                    'body': json.dumps({'message': 'Successfully processed games'})
                }
            else:
                return {
                    'statusCode': 200,
                    'body': json.dumps({'message': 'No games found for today'})
                }

    except urllib.error.URLError as e:
        error_message = f"Error fetching games: {e.reason}"
        print(error_message)
        return {
            'statusCode': 500,
            'body': json.dumps({'error': error_message})
        }
    except urllib.error.HTTPError as e:
        error_message = f"HTTP error: {e.code} - {e.reason}"
        print(error_message)
        return {
            'statusCode': e.code,
            'body': json.dumps({'error': error_message})
        }
    except Exception as e:
        error_message = f"Unexpected error: {str(e)}"
        print(error_message)
        return {
            'statusCode': 500,
            'body': json.dumps({'error': error_message})
        }

Add Environment Variables
- API_KEY: Your SportsAPI key
- SNS_TOPIC_ARN: The ARN of the created topic
Deploy the Function
- Click Deploy or use the shortcut Ctrl+Shift+U.

Creating the EventBridge Schedule

Navigate to EventBridge
Create a Rule
- Name: Any name of your choice
- Rule type: Schedule
- Cron expression: 0 * * * ? * (runs hourly)
Select the Target
- Target type: Lambda Function
- Lambda function: nba_function
Create the Schedule

With these steps, your automated solution will fetch NBA game results daily and send them to you via email or SMS!

Conclusion

This project demonstrates how AWS services like Lambda, EventBridge, and SNS can work seamlessly together to create a fully automated, serverless solution. By leveraging SportsAPI, we automated the process of fetching NBA game results and delivering them directly to your inbox or phone, saving you time and ensuring you never miss a moment.

Whether you’re a sports enthusiast or just exploring serverless architectures, this project showcases the versatility of AWS for building practical, real-world applications. I encourage you to try it out, customize it further, and even extend it to other use cases like weather updates or stock market alerts.

Feel free to share your thoughts or ask questions in the comments! Happy coding! 🏀✨

Building a Weather reports Dashboard with python, S3 and Openweather API

Sherif sani — Sun, 19 Jan 2025 11:56:53 +0000

Introduction

Have you ever wanted to build an application that fetches real-time weather data and securely stores it for later use? In this article, I'll walk you through how I developed a weather reporting app using Python, the OpenWeather API, and AWS S3.

This app:

Fetches current weather information for selected cities.
Displays the weather data on the console.
Stores the data in JSON format in an S3 bucket for archival purposes.

This is my first project in the 30-days DevOps challenge series.

Setting Up the Project

Requirements

Python 3.x
AWS CLI configured with credentials and permissions

   aws configure
   aws s3 mb s3://your_s3_bucket_name

OpenWeather API key
A .env file to store environment variables:

   OPENWEATHER_API_KEY=your_openweather_api_key  
   AWS_BUCKET_NAME=your_s3_bucket_name

Installing Required Libraries

Install the necessary libraries:

pip install python-dotenv requests boto3

Alternatively, use a requirements.txt file:

touch requirements.txt  
echo "python-dotenv" >> requirements.txt  
echo "requests" >> requirements.txt  
echo "boto3" >> requirements.txt  
pip install -r requirements.txt

The App

1. Importing Packages

import os  
import json  
import boto3  
import requests  
from datetime import datetime  
from dotenv import load_dotenv

2. Environment Setup

Initialize the app to interact with the API and AWS S3:

load_dotenv()  

class WeatherDashboard:  
    def __init__(self):  
        self.api_key = os.getenv('OPENWEATHER_API_KEY')  
        self.bucket_name = os.getenv('AWS_BUCKET_NAME')  
        self.s3_client = boto3.client('s3')  

    def create_bucket_if_not_exists(self):  
        try:  
            self.s3_client.head_bucket(Bucket=self.bucket_name)  
            print(f"Bucket {self.bucket_name} exists")  
        except:  
            print(f"Creating bucket {self.bucket_name}")  
            try:  
                self.s3_client.create_bucket(Bucket=self.bucket_name)  
                print(f"Successfully created bucket {self.bucket_name}")  
            except Exception as e:  
                print(f"Error creating bucket: {e}")

3. Fetching Weather Data

def fetch_weather(self, city):  
    base_url = "http://api.openweathermap.org/data/2.5/weather"  
    params = {  
        "q": city,  
        "appid": self.api_key,  
        "units": "imperial"  
    }  

    try:  
        response = requests.get(base_url, params=params)  
        response.raise_for_status()  
        return response.json()  
    except requests.exceptions.RequestException as e:  
        print(f"Error fetching weather data: {e}")  
        return None

4. Saving Data to S3

def save_to_s3(self, weather_data, city):  
    if not weather_data:  
        return False  

    timestamp = datetime.now().strftime('%Y%m%d-%H%M%S')  
    file_name = f"weather-data/{city}-{timestamp}.json"  

    try:  
        weather_data['timestamp'] = timestamp  
        self.s3_client.put_object(  
            Bucket=self.bucket_name,  
            Key=file_name,  
            Body=json.dumps(weather_data),  
            ContentType='application/json'  
        )  
        print(f"Successfully saved data for {city} to S3")  
        return True  
    except Exception as e:  
        print(f"Error saving to S3: {e}")  
        return False

5. Main Function

def main():  
    dashboard = WeatherDashboard()  

    # Create bucket if needed  
    dashboard.create_bucket_if_not_exists()  

    cities = ["Philadelphia", "Seattle", "New York"]  

    for city in cities:  
        print(f"\nFetching weather for {city}...")  
        weather_data = dashboard.fetch_weather(city)  
        if weather_data:  
            temp = weather_data['main']['temp']  
            feels_like = weather_data['main']['feels_like']  
            humidity = weather_data['main']['humidity']  
            description = weather_data['weather'][0]['description']  

            print(f"Temperature: {temp}°F")  
            print(f"Feels like: {feels_like}°F")  
            print(f"Humidity: {humidity}%")  
            print(f"Conditions: {description}")  

            # Save to S3  
            success = dashboard.save_to_s3(weather_data, city)  
            if success:  
                print(f"Weather data for {city} saved to S3!")  
        else:  
            print(f"Failed to fetch weather data for {city}")  

if __name__ == "__main__":  
    main()

Check your s3 bucket

aws s3 ls s3://your_s3_bucket_name

alternatively, you could use the console to the see the content of your bucket

Conclusion

Building a weather reporting app that integrates with AWS S3 demonstrates the power of combining APIs, cloud storage, and Python automation. This project retrieves live weather data using the OpenWeather API, processes it, and securely stores it in S3 for future use.

Further Enhancements:

Add a web interface.
Integrate data visualization tools.
Set up scheduled updates with AWS Lambda.

This project is a great way to sharpen your Python skills while exploring cloud technologies. Happy coding!

GitHub Repository

From Internal Server Error to Success: Debugging AWS Lambda and API Gateway

Sherif sani — Sat, 23 Nov 2024 17:10:40 +0000

Building a serverless application is exciting—until you hit a roadblock like the dreaded "Internal Server Error." Recently, I encountered this while creating a simple API with AWS Lambda and API Gateway to process query parameters and return a structured response. This post breaks down my debugging journey, what went wrong, and how I fixed it.

The Problem

My goal was straightforward:

Accept transactionId, type, and amount as query parameters.
Log the parameters and return them in a JSON response.

Here’s the Lambda function I wrote initially:

import json

def lambda_handler(event, context):
    transactionId = event['queryStringParameters']['transactionId']
    transactionType = event['queryStringParameters']['type']
    transactionAmount = event['queryStringParameters']['amount']

    print(f"TransactionId = {transactionId}")
    print(f"TransactionType = {transactionType}")
    print(f"TransactionAmount = {transactionAmount}")

    response = {
        'transactionId': transactionId,
        'type': transactionType,
        'amount': transactionAmount,
        'message': "Hello from lambda land"
    }

    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json',
        },
        'body': json.dumps(response)
    }

But when I tested the API through the browser, I kept getting:

500 Internal Server Error
CORS errors when calling the API from my frontend.

What Went Wrong?

Missing Query Parameters:

If any query parameter was missing, the code would throw a KeyError. This caused Lambda to fail and returned a generic error message without any details.
No Error Handling:

There was no mechanism to catch and log errors. This made debugging harder because the API Gateway logs only showed "Internal Server Error."
CORS Issues:

The response didn’t include Access-Control-Allow-Origin, which is required to enable communication between the frontend and the API Gateway endpoint.

The Fix

I rewrote the Lambda function with robust error handling, validation, and proper CORS configuration.

import json

def lambda_handler(event, context):
    try:
        # Extract query string parameters
        params = event.get('queryStringParameters', {})
        transactionId = params.get('transactionId', 'N/A')
        transactionType = params.get('type', 'N/A')
        transactionAmount = params.get('amount', 'N/A')

        # Validate parameters
        if transactionId == 'N/A' or transactionType == 'N/A' or transactionAmount == 'N/A':
            raise ValueError("Missing required query parameters")

        # Log parameters
        print(f"TransactionId = {transactionId}")
        print(f"TransactionType = {transactionType}")
        print(f"TransactionAmount = {transactionAmount}")

        # Create response
        transactionResponse = {
            'transactionId': transactionId,
            'type': transactionType,
            'amount': transactionAmount,
            'message': "Hello from lambda land"
        }
        return {
            'statusCode': 200,
            'headers': {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Origin': '*'
            },
            'body': json.dumps(transactionResponse)
        }
    except Exception as e:
        print(f"Error: {e}")
        return {
            'statusCode': 500,
            'headers': {'Access-Control-Allow-Origin': '*'},
            'body': json.dumps({'message': 'Internal Server Error', 'error': str(e)})
        }

Key Changes and Why They Work

Safe Parameter Extraction:

Instead of directly accessing event['queryStringParameters'], I used .get() with default values to prevent KeyError exceptions.
Validation:

The code now checks if required parameters are missing and raises a ValueError. This ensures we only process valid inputs.
Error Handling with Try-Except:

Wrapping the logic in try...except allows us to catch errors and return a detailed response while logging the issue for debugging in CloudWatch.
CORS Headers:

Adding Access-Control-Allow-Origin enables the frontend to communicate with the API successfully.

The Final Test

API Request

curl -X GET "https://<your-api-id>.execute-api.us-east-1.amazonaws.com/test/transactions?transactionId=123&type=credit&amount=1000"

Response

{
    "transactionId": "123",
    "type": "credit",
    "amount": "1000",
    "message": "Hello from lambda land"
}

Takeaways

Validation is Crucial: Always validate inputs to ensure your application works as expected.
Error Handling Simplifies Debugging: Wrapping your logic in try...except helps identify issues quickly.
CORS Configuration Matters: If your API serves a frontend, always include CORS headers in the response.
Logs Are Your Friend: Use print statements to log details in CloudWatch and understand what’s happening.

What’s Next?

Now that I’ve successfully implemented and tested this API, I’m moving on to integrating it with my S3 bucket for file uploads. This will involve:

Generating pre-signed URLs in Lambda.
Updating the frontend to handle file uploads.

Have you encountered similar challenges while working with serverless applications? Let’s discuss in the comments!

Effortlessly Copy Files Between AWS S3 Buckets with a Simple Bash Script

Sherif sani — Thu, 03 Oct 2024 17:53:02 +0000

In today's cloud-centric world, efficient data management is crucial, especially when working with AWS S3 buckets. AWS S3 is a powerful object storage service that allows you to store and retrieve any amount of data at any time, making it ideal for a variety of use cases such as backups, migrations, and data synchronization. Automating the process of copying files between S3 buckets can save you time and reduce the potential for errors. In this article, I’ll walk you through a straightforward Bash script that facilitates this process while ensuring that AWS credentials are configured correctly.

Overview of the Project

The goal of this project is to create a Bash script that:

Prompts the user to configure their AWS credentials if they are not already set.
Lists all available S3 buckets.
Asks the user for the source and destination bucket names.
Copies files recursively from the source bucket to the destination bucket.

Prerequisites

Before diving into the script, ensure you have:

A Linux machine.
AWS CLI installed and configured on your machine.
Valid AWS credentials with the necessary permissions to access S3 services.

The Script

Here’s the complete Bash script:

#!/bin/bash

echo -e "\e[32m---------------COPY FILES BETWEEN S3 BUCKETS-----------------\e[0m"

# Check if AWS credentials are configured
aws sts get-caller-identity > /dev/null 2>&1
if [ $? -ne 0 ]; then
  echo -e "\e[31mAWS credentials are not configured. Please configure your credentials:\e[0m"
  aws configure
else
  echo -e "\e[32mAWS credentials are already configured.\e[0m"
fi

echo -e "\e[32m---------------Listing all buckets-----------------\e[0m"
aws s3 ls

read -p "Enter the source bucket name: " source_bucket
read -p "Enter the destination bucket name: " destination_bucket

# Copy files between the buckets
aws s3 cp s3://$source_bucket/ s3://$destination_bucket/ --recursive

if [ $? -eq 0 ]; then
  echo -e "\e[32m---------------Files copied successfully-----------------\e[0m"
else
  echo -e "\e[31m---------------An error occurred while copying files-----------------\e[0m"
fi

How It Works

Greeting and Instructions: The script begins with a greeting and informs the user about the AWS credentials configuration.
AWS Credentials Check: It executes the aws sts get-caller-identity command to verify that the AWS CLI can access the configured credentials.
- If credentials are not set up, the script prompts the user to run aws configure to set them up.
Listing S3 Buckets: After verifying credentials, the script lists all available S3 buckets using aws s3 ls.
User Input for Buckets: The script prompts the user for the source and destination bucket names.
Copying Files: It utilizes the aws s3 cp command with the --recursive flag to copy all files from the source bucket to the destination bucket. Additionally, it checks the success of the copy operation and provides appropriate feedback.
Completion Message: Finally, it confirms whether the files have been copied successfully or if an error occurred.

Benefits of Automation

Automating tasks like copying files between S3 buckets offers several advantages:

Time-saving: Quickly transfer large volumes of data without manual effort.
Error reduction: Minimizes human error in file handling and data migration.
Consistency: Ensures that the same process is followed every time, enhancing reliability.

Conclusion

This simple Bash script demonstrates how to automate the process of copying files between AWS S3 buckets while ensuring your AWS credentials are configured correctly. As you develop more complex AWS solutions, this foundational knowledge will be invaluable in streamlining your workflows.

As you implement this script, consider enhancing it with features like error handling, logging, or scheduling tasks with cron jobs. Reflecting on what I've learned today, I’m excited to explore more automation possibilities within AWS.

Thank you for reading! Have you worked on similar projects? Share your experiences in the comments below, and happy scripting!

My journey into the cloud

Sherif sani — Sat, 14 Sep 2024 15:34:52 +0000

My First Week Learning AWS: S3, S3 CLI, and Lambda Integration

Hi there! This is my first time writing an article, so I’m excited to share what I’ve learned this week on my AWS journey. If you're new to AWS like me, I hope this will be helpful, and maybe even inspire you to dive deeper into cloud technologies!

What I Learned This Week

1. Amazon S3 (Simple Storage Service)

S3 is AWS’s service for storing and retrieving data in the cloud. I found it incredibly versatile. You can store anything from images to large datasets. It’s like a giant cloud-based storage drive, but with some really cool features like versioning, encryption, and fine-grained permissions.

2. S3 CLI (Command Line Interface)

The AWS CLI makes interacting with S3 much easier through the command line. At first, I was a bit intimidated, but after learning the basic commands like aws s3 cp for copying files, and aws s3 ls to list content, I realized how powerful and efficient the CLI can be. It makes managing S3 buckets so much faster than using the console.

3. Integrating S3 with Lambda

Lambda allows you to run code in response to events, without having to manage servers. I spent some time integrating S3 with Lambda to automate tasks, like triggering a Lambda function when a new file is uploaded to an S3 bucket. This opens up so many possibilities, like processing images, validating file uploads, or generating logs.

What’s Next?

Next week, I’m diving deeper into Lambda! I’ll be learning more advanced features and building an image-sharing app that combines S3 and Lambda. I’m really excited about this project and can’t wait to share what I learn!

If you're interested in cloud engineering or AWS, stay tuned for more of my learning journey. Feel free to share your own experiences or ask any questions in the comments!

also, I'd greatly appreciate it if anyone can provide me with a good roadmap to become a cloud engineer.

thanks for reading 🙏

Exploring Frontend Technologies: Svelte vs. Alpine.js

Sherif sani — Thu, 04 Jul 2024 15:43:27 +0000

Introduction

Frontend development has seen a massive evolution over the years, introducing a plethora of frameworks and libraries to enhance user experiences. While giants like ReactJS, Angular, and Vue.js often dominate the conversation, there are some niche players that offer unique advantages. In this article, we'll dive into two such technologies: Svelte and Alpine.js. We'll explore their core principles, use cases, and why they might be better suited for certain projects. Additionally, I'll share my thoughts on using ReactJS during the HNG internship and how I feel about this journey.

Svelte: The Compiler Approach

What is Svelte?

Svelte is a relatively new frontend framework created by Rich Harris. Unlike traditional frameworks that do much of their work in the browser, Svelte shifts that work to compile time. This means that instead of shipping a framework to the client, Svelte applications compile down to highly optimized vanilla JavaScript at build time.

Key Features of Svelte

No Virtual DOM: Svelte eliminates the need for a virtual DOM, which can lead to faster and more efficient updates.
Truly Reactive: With Svelte, reactivity is built into the language itself. You simply declare your state and bindings, and Svelte handles the rest.
Minimal Bundle Size: Since Svelte compiles components down to minimal JavaScript, the bundle sizes are often significantly smaller compared to other frameworks.

Use Cases for Svelte

Svelte is ideal for projects where performance is critical, and bundle size needs to be minimized. It's also great for developers who prefer a more straightforward, less boilerplate-heavy development experience.

Alpine.js: The Lightweight Contender

What is Alpine.js?

Alpine.js is a minimalistic framework designed for adding interactivity to your HTML. It draws inspiration from frameworks like Vue.js but aims to be lightweight and easy to integrate into existing projects without a build step.

Key Features of Alpine.js

Tiny Footprint: With a very small file size, Alpine.js can be included in any project with minimal impact on load times.
Declarative Syntax: Similar to Vue and Angular, Alpine uses a declarative syntax that makes it easy to understand and write.
No Build Process: Alpine.js doesn't require a build step, making it perfect for adding interactivity to static sites or enhancing server-rendered pages.

Use Cases for Alpine.js

Alpine.js shines in scenarios where you need to add a sprinkle of JavaScript interactivity without the overhead of a full-fledged framework. It's perfect for static sites, server-rendered pages, or any project where simplicity and speed are priorities.

Comparing Svelte and Alpine.js

Learning Curve

Svelte: Has a moderate learning curve. If you're familiar with modern JavaScript and frameworks, you'll find Svelte's syntax and reactivity straightforward to grasp.
Alpine.js: Very low learning curve. If you know basic HTML, CSS, and JavaScript, you can start using Alpine.js almost immediately.

Performance

Svelte: Offers superior performance due to its compilation approach, making it ideal for high-performance applications.
Alpine.js: While not as performant as Svelte, Alpine's small size and direct DOM manipulation make it quite efficient for its use cases.

Ecosystem and Community

Svelte: Has a growing ecosystem with tools like SvelteKit, and a vibrant, supportive community.
Alpine.js: Smaller ecosystem but rapidly growing. Its simplicity means you can often use it alongside other tools without conflict.

My Journey with ReactJS in the HNG Internship

During the HNG internship, ReactJS is the primary framework we'll be using. React is a powerful, component-based library that allows developers to build dynamic user interfaces with ease. I'm excited to delve deeper into React, leveraging its rich ecosystem, and state management tools like Redux or Context API.

React's virtual DOM, component-based architecture, and vast community support make it a versatile tool for building scalable applications. I anticipate working on real-world projects, collaborating with other interns, and honing my skills to become proficient in React development.

Conclusion

Both Svelte and Alpine.js offer unique advantages depending on the project's requirements. Svelte is perfect for high-performance applications with its compile-time optimization, while Alpine.js excels in simplicity and ease of integration for lightweight interactive components.

As I embark on my journey with the HNG internship, I'm eager to expand my knowledge and skills in frontend development, particularly with ReactJS. The hands-on experience and mentorship opportunities will undoubtedly be invaluable.

If you're interested in learning more about the HNG Internship program, check out these links: