DEV Community: Sandeep Sangu

S3 Bucket Names Just Got Simpler — Here's What Actually Changed

Sandeep Sangu — Sun, 05 Apr 2026 07:13:38 +0000

If you've worked with S3 for a while, you know the drill.

You go to create a bucket, pick a name that makes sense for your project, and AWS tells you it's already taken. Not by you. Not by anyone in your org. Just — taken. Because S3 bucket names have always been globally unique across every account, every region, worldwide.

So over time, most of us started appending things manually.

Account IDs. Region names. Random strings. Whatever it took to avoid collisions. It worked, but everyone solved it differently, and it made naming messy and hard to standardize — especially across teams or in automation.

What AWS introduced

AWS recently released account and regional namespaces for S3 general purpose buckets.

In practical terms — bucket names are no longer fighting for global uniqueness. They're now scoped to your AWS account and region. A bucket created under this model gets a suffix like:

mybucket-123456789012-us-east-1-an

The -an suffix indicates the account + regional namespace — AWS appends the full suffix automatically.

What's interesting here is AWS didn't invent a new pattern. They looked at what engineers were already doing — appending account IDs and regions — and formalized it. Same idea, now built in and enforced.

How this changes day-to-day work

The biggest shift is in predictability.

Before, you couldn't be sure a name was available until you tried to create the bucket. In automation or IaC, that meant handling failures, adding retries, or generating random suffixes just to be safe.

Now with CloudFormation, you can directly reference:

${AWS::AccountId}-${AWS::Region}

And get a deterministic name that won't collide. No guessing, no workarounds, no surprise failures mid-pipeline.

For teams managing multiple environments — dev, test, prod — or running multi-account setups, this removes a small but persistent source of friction. Naming becomes consistent, automation becomes cleaner, and onboarding new environments gets a bit more straightforward.

There's also a governance angle worth mentioning. With IAM and SCPs, you can now enforce that buckets are only created within your account's namespace. That means teams across a large org follow the same pattern by default — not by convention, but by policy.

What to keep in mind

This doesn't replace all naming discipline.

Existing buckets stay as they are — no migration path, no renaming. The suffix also takes up characters, so if you're working close to the 63-character limit, that's something to account for. Cross-account workflows still benefit from clear conventions on top of this. And any tooling that assumes global uniqueness may need a second look.

It's a meaningful improvement, not a complete overhaul.

Worth knowing about

This is the kind of change that doesn't make headlines but quietly improves how you work — especially if you're deep in IaC, managing multiple accounts, or building platform tooling for other teams.

AWS formalized something the community was already doing. And that's often where the most useful improvements come from.

If you're setting up new buckets or revisiting your naming conventions, worth giving this a look.

Read more

Interested in the AWS Community Builders program?

Sandeep Sangu — Wed, 31 Dec 2025 13:15:46 +0000

As we head into 2️⃣0️⃣2️⃣6️⃣, thought I’d share something that might help if you’re building on AWS.

Almost a year ago, I was selected as an AWS Community Builder. https://lnkd.in/gDDwKE5j

What stood out most: the program isn't about posting everywhere or chasing visibility - it's about being consistent with what you build, learn, and share.

In practice, that means:

Building and learning at your own pace
Focusing on understanding, not just outcomes
Sharing learnings that are practical and honest

Yes, there are benefits:

$500 AWS Credits - freedom to experiment, learn, and build without cost being the first constraint
Free certification vouchers - validate skills you're already applying
Premium learning access - valuable if used with intent
Direct access to AWS experts and teams - practical conversations and feedback
Exclusive events, early access, and yes… swag

But the real value is the people - builders who are practical, curious, and open about what worked (and what didn't).

If you're already building on AWS, documenting what you learn, or helping others in small but meaningful ways - you're already aligned with what this program looks for.

Interested in the next cohort?
Join the waitlist 👉 https://pulse.aws/application/BM2AKLSX

Amazon Nova, Explained the Way I Wish Someone Had

Sandeep Sangu — Wed, 16 Jul 2025 09:05:41 +0000

I’ve seen a few articles and docs about Amazon Nova already, but I wanted to try it myself and understand it in a way that actually clicks.

This write-up is just my take — the kind of explanation I wish I had when I first came across it.

Hopefully, it helps someone else too🤞

A Quick Look at Nova Models — In Simple Terms

Before diving deeper, here's a simple breakdown of the different Nova models.

Nova isn't just one model — it's a family built for different kinds of tasks.

🧠 Understanding Models — Text, image, or video in → Text out

Great for reasoning, summarizing, answering questions, or writing code.

Nova Micro – Lightweight, cost-efficient
Nova Lite – Balanced speed and quality
Nova Pro – More capable, handles complex prompts better
Nova Premier – Most advanced, highest accuracy

🎨 Creative Models — Text or image in → Image or video out

Used for generating banners, visuals, or animated content.

Nova Canvas – Creates images from prompts
Nova Reel – Generates short videos

🎤 Speech Model — Speech in → Speech + text out

Useful for real-time, human-like voice conversations.

Nova Sonic – You speak to it, and it replies back with speech — while also giving you the text version of the response.

📌 All of these models run inside Amazon Bedrock — no setup required.

What Even is `Amazon Nova`? (And No, It’s Not Just Another Chatbot)

When I first heard about Nova, I honestly thought — Okay, maybe AWS finally made their version of ChatGPT.

But once I actually started using it, that idea didn’t hold up.

Nova isn’t just another chatbot.

It’s Amazon’s own foundation model — built by AWS, not licensed from OpenAI or Anthropic.

Think of it like this:

🛠️ If other Bedrock models are rented engines, Nova is the one AWS built in-house.

Just like Google has Gemini and OpenAI has GPT, Amazon now has Nova — and it's their own stack, optimized to run well within AWS environments.

It runs inside Amazon Bedrock — no setup needed. Just open the playground and start asking.

Nova isn’t trying to be a friendly chat assistant like GPT-4 — it’s built for focus, clarity, and AWS-native tasks.

🛠 What I Tried — Real Prompts, Real Results

I wanted to test something practical — not just chatting or generating summaries, but something an SRE or DevOps engineer might actually run into on the job.

So I asked Nova:

“Write a CloudWatch Logs Insights query to find all failed login attempts from IPs starting with 192.168. over the past 24 hours.”

Here’s what Nova gave back:

fields @timestamp, @message, ipAddress, eventType
| filter eventType = 'failed_login'
| filter ipAddress like /^192\.168\./
| sort @timestamp desc
| limit 20

And it didn’t stop there — it explained what each part of the query did, including a reminder to adjust field names based on how your logs are structured.

This output felt on point. It wasn’t overexplained. It wasn’t vague. It was just… useful. The kind of thing you could actually copy into CloudWatch and run — and that’s exactly what I wanted from Nova.

🎬 But That’s Not All — I Couldn’t Resist Trying the Others

Once I saw how well Nova handled a real-world prompt, I got curious.

After all, Nova isn’t just one model — it’s a whole family designed for different kinds of tasks. So I naturally wandered into the Video and Image playgrounds to explore a few more.

Here’s what I explored next 👇

I did try a few prompts — the outputs were interesting, some even quite impressive. That said, the best results come when you really understand the model, follow the documentation, and craft precise prompts tailored to its strengths.

I couldn’t grab the exact one I generated, but the exploration itself was eye-opening — and here are a few links that can guide you through your own.

🔗 Helpful Links to Explore Nova Further:

📘 Nova Reel Overview – AWS Docs
🎬 Nova Reel Examples – Amazon Science
🧠 Prompting for Image Generation – Nova Docs
🎯 Prompting with Precision – Nova Docs
🧾 What is Nova? – Main Docs
🧪 Nova Playground – Explore Available Models

🧭 Explore, experiment, and see where your creativity (and Nova) can take you. That’s Nova for you.

Nova feels especially suited for creative generation — like I mentioned earlier, when used right, it delivers.
🎨 Creative Models — Text or image in → Image or video out
Perfect for banners, visuals, or short video storytelling.

Nova Canvas → Creates high-quality images from text prompts
Nova Reel → Generates short cinematic videos

Whether you're in marketing, advertising, or just like exploring creative tech — Nova gives you that starting spark.

That’s the kind of simple starting point I wish I had — and hopefully, it gives you that same spark to dive in.

My Profile Is Now Live on the New AWS Builder Center 🚀

Sandeep Sangu — Sun, 13 Jul 2025 13:50:18 +0000

Finally, my name is now live in the global AWS Community Builders directory — a much-awaited moment!

The new AWS Builder Center is officially live 🚀

I’ve updated my profile: @sandeepsangu

🤝 Let’s connect, keep building, and keep learning together!

👉 Curious about the AWS Community Builders program?
Learn more here

Going Serverless — Automating PDF Parsing with S3, Lambda & DynamoDB (Part 2)

Sandeep Sangu — Sat, 24 May 2025 06:37:01 +0000

🧭 Introduction

In Part 1, I walked through a local-first approach to extract text from patient PDFs using AWS Textract and Python. The flow was straightforward place a PDF into a folder, run a script, and save the extracted content to a .txt file. It helped validate Textract’s capabilities and gave a hands-on feel for the API — but everything was manual.

This project wasn’t built for perfection, but for practice, learning, and getting real with AWS services.

In this second part, I wanted to push it a step further, simulating how such a process might work in a real backend environment by introducing automation, triggers, and storage. The goal: automate the entire PDF parsing flow using serverless AWS services.

📌 Note: The PDF upload step is still manual in this setup. In real-world applications, scanned PDFs are usually sent to cloud storage (like S3) automatically — through connected devices, backend apps, or scheduled jobs. For this hands-on practice, I’ve intentionally kept the upload step manual. But once a PDF lands in the bucket, everything else — processing, extraction, and storage — is fully automated.

⚙️ What This Part Covers

In this article, I’ll walk through how I used the following AWS services to automate the document extraction pipeline:

Amazon S3 — to hold the uploaded PDFs and trigger the processing flow
AWS Lambda — to extract content from PDFs using Textract
Amazon DynamoDB — to store structured patient records in a NoSQL format
CloudWatch Logs — to track execution flow and debug when needed

The result is a working example of a lightweight, event-driven backend that reacts to PDF uploads and processes them automatically — no scripts to run, no manual parsing.

🏥 Real-World Scenario: Why Automating PDF Processing Matters

In industries like healthcare, insurance, and legal, documents often arrive in the form of scanned PDFs — visit summaries, claim forms, contracts — all packed with valuable information that needs to be extracted, stored, and used downstream.

Take hospitals for example: they deal with dozens or hundreds of patient summaries daily. Manually opening each file, reading the content, and entering it into a database isn’t just tedious — it’s error-prone and impossible to scale.

That’s where automation comes in.

Instead of treating PDFs as static files, the idea is to turn them into event-driven inputs. As soon as a document is uploaded, a backend system takes over — extracting key fields, storing them in structured formats like DynamoDB, and making them available for future use (like reporting, analysis, or alerts).

📌 This project simulates exactly that — using AWS services to mimic how such a backend might work. It's a hands-on demonstration of how automation bridges the gap between unstructured input and structured output.

By the end of this flow, what would’ve taken minutes per file happens in seconds, without manual intervention (aside from the initial upload, which we kept manual here for simplicity).

🗺️ Architecture Overview

To automate the document extraction flow, I used a combination of AWS services that work together in an event-driven pipeline.

Here's how it works at a high level:

Amazon S3 acts as the dropzone — when a new PDF is uploaded, it automatically triggers the next step.
AWS Lambda is triggered by the S3 event and uses Amazon Textract to extract text from the PDF.
The extracted text is then parsed into structured fields (like patient ID, diagnosis, etc.).
These records are stored in Amazon DynamoDB — one item per patient.
Amazon CloudWatch Logs captures logs throughout the flow to help monitor and debug.
IAM roles are used to allow services to communicate securely and perform their actions.

🛠️ Step-by-Step Implementation

Here’s a quick walkthrough of how I set things up, in the order I tackled each piece. Nothing overly complex — just enough to get a fully working flow from upload to database entry.

📁 1. S3 Setup — Upload as a Trigger

I started by creating an S3 bucket to act as the dropzone for incoming PDFs. Every time a file is uploaded, it automatically triggers the next step.

To do that, I added an S3 event trigger to my Lambda function — specifically, an event of type ObjectCreated. No folder structure or file filters for now, just a basic setup to keep it simple.

⚠️ FYI: In production, you'd usually narrow this to a folder (prefix) or file type filter. For now, keeping it wide open helped test faster.

⚙️ 2. Lambda Function — Extract and Parse on the Fly

Once a new PDF lands in the bucket, Lambda takes over.

The function:

Pulls the PDF from S3
Sends it to Amazon Textract
Parses the returned lines into structured fields
Stores each parsed record into DynamoDB

Amazon Textract offers different operations depending on your document type.
In this case, I used the detect_document_text API — it’s fast, synchronous, and works well for clean printed documents like summaries or forms.

For other use cases (like extracting forms or tables), you can explore Textract’s available operations here.

🧾 3. Textract Output Processing — Turning Lines Into Records

Textract returns blocks of text as separate lines. I looped through each line and looked for patterns like Patient Name:, Diagnosis:, Next Visit: etc.

Whenever a new Patient Name appeared, I considered that the start of a new record.

This basic parsing logic worked well for my structured PDFs — and it gave me clean, key-value entries ready to store.

✍️ The format of your source PDF matters. If you're working with messy scans or inconsistent layouts, you’ll likely need a smarter parser or post-processing.

🗂️ 4. DynamoDB Storage — Saving Each Record

Each parsed patient record is stored as a new item in my DynamoDB table called PatientRecords.

I used PatientID as the partition key. So before inserting each item, I made sure to normalize the field (Patient ID → PatientID) and skip any record that didn't include it.

This way, only valid patient records are saved.

📜 5. Monitoring with CloudWatch Logs

Every step — from event trigger to Textract response to final record insert — is logged automatically in CloudWatch Logs.

This was super helpful during testing. For example, I could easily see:

If Textract succeeded
What records were parsed
If anything failed validation (like missing a Patient ID)

Just head to the Lambda > Monitor tab to view the logs in context.

🔐 6. IAM Roles — Permissions That Make It Work

To connect all these services securely, I created an IAM role for the Lambda function.

This role had the following policies attached:

AmazonS3ReadOnlyAccess
AmazonTextractFullAccess
AmazonDynamoDBFullAccess
AWSLambdaBasicExecutionRole

⚠️ For this project, I also used an IAM user with broad access to set things up.
But in real-world scenarios, always follow the principle of least privilege — give only the permissions that are needed for the task, and nothing more.

📸 Demo Output & Screenshots

Let’s walk through what happens when the workflow runs end-to-end.

Once a PDF is uploaded, the automation kicks in — AWS Lambda gets triggered, calls Textract to extract text, parses the extracted lines, and writes structured patient records into DynamoDB.

Here’s the architecture diagram that visually represents this flow:

Below, you’ll see a sample view of the PatientRecords DynamoDB table — confirming that our extracted fields like patient name, ID, diagnosis, and next visit date have been stored properly:

You can also view the detailed execution logs in CloudWatch, which helps confirm the flow — from trigger to text extraction and database insertion. This is especially useful during debugging or validation in real-time scenarios.

Finally, here’s the raw output file that was extracted and stored locally during testing:

🧠 Lessons Learned Along the Way

Like most hands-on projects, this one came with a few surprises and learning moments.

Lambda Timeouts:
Initially, the Lambda function timed out while waiting for Textract to finish. Increasing the timeout duration solved it, but it reminded me to always plan for longer-running tasks when calling asynchronous services.
Parsing Gotchas:
While Textract extracted text just fine, breaking it into structured records required some tweaking — especially for lines that didn’t follow a perfect format (like a missing Patient ID). Adding logic to skip incomplete entries helped keep things clean.
IAM Permissions:
The setup was smoother by assigning full access policies to the IAM user and Lambda role, but in real-world scenarios, we’d follow the least privilege principle to secure each component properly.

✅ Final Thoughts

This project helped me explore how to bring automation into document parsing using AWS's serverless services. By combining S3, Lambda, Textract, and DynamoDB, I was able to simulate a lightweight backend workflow — one that reflects how real-world systems might handle scanned documents, such as patient summaries.

While the initial PDF upload and script execution were still done manually for simplicity, everything that followed — from text extraction to structured storage — was event-driven and fully automated.

This setup lays the groundwork for more advanced ideas, like:

Adding search or filter capabilities on top of DynamoDB
Integrating analytics dashboards
Using generative AI to summarize or classify extracted content

Thanks for following along! 🙌
I hope this gives you a practical feel for how serverless workflows can streamline everyday processes.

Feel free to share your thoughts, ask questions, or fork the repo to try it out yourself!

Local PDF Parsing with AWS Textract & Python (Part 1)

Sandeep Sangu — Sat, 10 May 2025 13:06:52 +0000

✍️ Introduction

Throughout my experience working with clients from domains like healthcare, insurance, and legal, I often found myself curious about how certain backend document workflows functioned, especially in healthcare. While supporting these systems, I’d often get paged for incidents related to PDF pipelines: upload failures, script errors, or extraction gaps. At that stage, like many in support roles, we’re limited to handling outcomes rather than building or understanding the full solution.

Over time, as we gain more experience, build trust, and make people feel confident in our abilities, we gradually get the opportunity to be part of architecture discussions and solution design conversations. But that curiosity about how these pipelines actually work — from PDF upload to raw text extraction — always stayed with me.

So I decided to finally explore this from scratch, hands-on, and document it as a small weekend project. This repository reflects that journey — one that started with a question and ended with deeper insights, hands-on practice, and a working prototype. My hope is that others who share this curiosity will find this just as helpful.

🔍 What This Project Is

This project focuses on extracting structured data from scanned or uploaded PDFs using AWS Textract, starting with a local Python-based flow.

It simulates real-world use cases commonly seen in healthcare, legal, and insurance sectors — where physical documents like visit summaries or forms need to be digitized and stored in structured formats like databases.

The goal?
To break down what typically happens behind the scenes — from raw scanned input to clean, queryable output — using AWS-native services.

📄 Why Document Parsing Matters

In many industries, large volumes of information are still locked inside unstructured files, like PDFs or images.

For example:

A hospital stores patient visit summaries scanned from handwritten or printed forms.
An insurance company receives thousands of claim forms uploaded as PDFs every week.
A legal team scans documents, contracts, and evidence that need to be searchable.

Without parsing, this data remains buried and unusable.

Document parsing — especially automated parsing — allows organizations to:

Extract critical fields (like patient name, ID, diagnosis)
Store them in structured systems (like DynamoDB)
Enable downstream use (dashboards, alerts, summaries, etc.)

This project is a hands-on way to explore how that all comes together.

🧪 Local First: Why I Didn’t Start with Automation

While it’s tempting to jump straight into Lambda functions and triggers, I deliberately started with a local-first mindset.

Why?

It helps build intuition: you understand exactly what Textract returns and how the parsing logic works.
Easier to test and debug before handing things off to automation.
You stay in control, tweaking and improving the logic before putting it behind an event trigger.

This mirrors how real-world teams prototype internally before scaling.

In my case:

Took a sample patient visit summary in PDF format.
Wrote a simple Python script to call AWS Textract.
Parsed the returned lines into structured fields.
The script automatically saved the extracted text as a .txt file inside output-texts/. I opened it to manually check if Textract returned the expected content.

That local foundation made automation smoother and more predictable.

🧱 Prerequisites

To follow along or replicate this project, ensure the following are in place:

An AWS account (root access only used for visual verification)
A dedicated IAM user with the following permission:
- AmazonTextractFullAccess
AWS CLI installed and configured with the IAM user credentials
Python 3.9+ installed
virtualenv installed
VS Code (or any preferred IDE)

You should also:

Create a virtual environment (python -m venv venv) and activate it.
Install boto3 (pip install boto3) and freeze dependencies into requirements.txt

📂 Project Structure

pdf-to-text-extractor/
├── input-pdfs/                # Local test PDFs
├── output-texts/              # Extracted raw text output
├── scripts/                   # Python scripts
│   └── extract_textract.py
├── venv/                      # Virtual environment (ignored in git)
├── requirements.txt
├── .gitignore
└── README.md                  # Project Documentation

Why venv and requirements.txt matter:

Using a venv/ keeps dependencies isolated — it’s a clean, repeatable habit in Python workflows.
The requirements.txt file lists all the packages I used, so anyone can recreate the same environment instantly.

🧪 What the Local Script Does

In this phase, wrote a simple Python script to:

Load a PDF from the input-pdfs/ folder
Send it to Textract for text extraction
Save the output to output-texts/ as a .txt file

This helped validate if Textract could read and extract meaningful content, before jumping into parsing or automation.

✅ Outcome and What’s Next

By the end of this phase, I had a working local prototype that:

Pulled a PDF from input-pdfs/
Extracted raw text using AWS Textract
Saved it to output-texts/
Gave me a chance to test and fine-tune the logic manually

This local-first phase gave me the space to deeply understand what each piece does before scaling up.

🔗 References

📂 Explore the Full Codebase

All the files used in this local setup are available here:

🔗 GitHub Repo → pdf-to-text-extractor/local

🔜 Coming Up in Part 2:

We’ll build on this by:

Triggering Textract via AWS Lambda
Parsing and storing results in DynamoDB
We’ll automate everything after the upload — using AWS services to handle extraction, parsing, and storage — just like a real-world backend system would.

📘 Read Part 2 here: Building a Serverless PDF Ingestion Flow

Agile Methodology

Sandeep Sangu — Wed, 24 Jul 2024 09:38:27 +0000

Introduction to Agile 🚀

Agile is an iterative and incremental approach to software development that emphasizes flexibility, collaboration, and customer satisfaction. It's a mindset shift from traditional methods, allowing for changes even late in the development process.

Agile Principles 🌟

The Agile methodology is based on 4 core values and 12 principles. The 4 core values are:

Individuals and Interactions 🤝 over processes and tools
Working Software 💻 over comprehensive documentation
Customer Collaboration 🗣️ over contract negotiation
Responding to Change 🔄 over following a plan

These values guide the 12 principles of Agile, which are:

Our highest priority is to satisfy the customer by delivering valuable software early and continuously. 👍
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 🔄
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. 🗓️
Close, daily cooperation between business people and developers. 🤝
Projects are built around motivated individuals, who should be trusted to get the job done. 💪
Face-to-face conversation is the most efficient and effective method of conveying information within a development team. 💬
Working software is the primary measure of progress. 📈
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 🌱
Continuous attention to technical excellence and good design enhances agility. 🛠️
Simplicity—the art of maximizing the amount of work not done—is essential. 🎨
The best architectures, requirements, and designs emerge from self-organizing teams. 🌟
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 🔍

Agile Methodologies 🌐

Agile is not a single methodology, but rather a set of values and principles that can be applied in various ways. Some popular Agile methodologies include:

1. Scrum 🏉

Framework for managing and completing complex projects
Emphasizes teamwork, accountability, and iterative progress

2. Kanban 📊

Visual system for managing work, emphasizing continuous flow
Focuses on lead time, cycle time, and throughput

Scrum Framework 🏉

The Scrum framework consists of three roles, five ceremonies, and artifacts.

Roles 👥

1. Product Owner 📋

Responsible for defining and prioritizing the product backlog
Ensures the backlog is visible, transparent, and clear

2. Scrum Master 🧑‍🏫

Facilitates Scrum and removes impediments
Ensures the team follows Scrum principles and practices

3. Development Team 💻

Cross-functional team that develops the product increment
Self-organizing and responsible for meeting sprint goals

Ceremonies ⏰

1. Sprint Planning 🗓️

Time-boxed event to plan the upcoming sprint
Team commits to delivering a specific set of work

2. Daily Scrum 🕒

Time-boxed event for the team to synchronize and plan
Each team member shares progress, plans, and impediments

3. Sprint Review 📝

Time-boxed event to review the product increment
Stakeholders provide feedback, and the team adapts

4. Sprint Retrospective 🔄

Time-boxed event to reflect on the sprint and identify improvements
Team discusses what went well, what didn't, and how to improve

5. Backlog Refinement 📋

Ongoing process to keep the product backlog updated
Team reviews and revises items in the backlog to ensure they are ready for future sprints

Artifacts 📦

1. Product Backlog 📃

Prioritized list of features or user stories
Refined and updated regularly by the Product Owner

2. Sprint Backlog 🗂️

Set of tasks to be completed during the sprint
Created during Sprint Planning and updated daily

3. Increment 📈

Sum of all product backlog items completed during a sprint
Reviewed during the Sprint Review ceremony

FYI: There are additional extended artifacts in Scrum, such as the Definition of Done and Burn-Down Chart. For more information, check the further reading section.

Example 🏠

Imagine building a house using Scrum principles. You start by working with an architect (Product Owner) to create a blueprint of your dream home. The architect prioritizes the features, such as the foundation, walls, roof, and interior design.

The construction team (Development Team) takes on a set of tasks for the first phase (Sprint), such as building the foundation and framing the walls. They work together to complete the tasks, and at the end of the phase, they review their progress with you (Sprint Review). You provide feedback, and the team adjusts their plan for the next phase.

As the construction progresses, the team continues to work in phases, reviewing progress and making adjustments along the way. The architect ensures that the team is on track to meet the project timeline and budget. Finally, the team delivers a fully built and functional home (Product Increment).

This example illustrates how the Scrum framework can be applied to a complex project, with iterative progress, continuous feedback, and flexibility to adapt to changing requirements.

Advantages of Agile 🚀

Flexibility and Adaptability 🌟: Agile allows for changes at any stage of the project, making it ideal for projects with evolving requirements.
Customer Satisfaction 😊: Continuous customer involvement ensures the final product meets their needs and expectations, leading to higher customer satisfaction.
Faster Delivery 🚀: Frequent releases provide quick delivery of functional software, providing value to customers sooner.
Improved Quality 🔍: Continuous testing, feedback, and refinement improve the overall quality of the product, reducing defects and bugs.
Enhanced Collaboration 🤝: Agile promotes cross-functional teams and encourages collaboration among team members, stakeholders, and customers, fostering a sense of ownership and teamwork.
Increased Transparency 🔎: Agile's emphasis on regular progress updates and open communication ensures that stakeholders are informed and aligned throughout the project.
Risk Reduction ⚠️: Agile's iterative approach helps identify and mitigate risks earlier in the project, reducing the likelihood of project failures.
Improved Team Morale 💪: Agile's focus on teamwork, recognition, and continuous improvement boosts team morale and motivation, leading to a more productive and engaged team.

Popular Agile-Scrum Tools 🛠️

Jira by Atlassian - Agile project management tool
Confluence by Atlassian - Documentation
Trello - Visual collaboration tool for planning tasks and projects

SDLC - Waterfall Model

Sandeep Sangu — Mon, 22 Jul 2024 08:37:43 +0000

The Waterfall model is a linear and sequential approach to software development where each phase must be completed before the next one begins. This means that each phase depends on the previous one, and making changes or revisions later can be difficult and costly.

Phases 📅

The phases of the Waterfall model are the same as those in the SDLC, with a strong emphasis on their sequential nature.

Example 🍰

Imagine ordering a custom cake. You first give the bakery your order (requirements), then they design the cake (design), followed by baking and decorating (implementation), tasting and quality control (testing), and finally, delivering the cake to you (deployment). If you want to change the cake's flavor or design after it's been baked, it's too late and would require starting over from scratch.

Advantages ✅

Simplicity and Ease of Use: The linear nature makes it straightforward.
Clear Milestones and Deliverables: Each phase has specific goals and outputs.

Disadvantages ❌

Inflexibility in Handling Changes: Difficult to make changes once a phase is completed.
Difficulty in Accommodating New Requirements: New requirements are hard to integrate mid-process.

Software Development Life Cycle

Sandeep Sangu — Mon, 22 Jul 2024 08:14:52 +0000

The Software Development Life Cycle (SDLC) is a structured process used for developing software applications. This methodical approach ensures that software is built efficiently and meets user requirements.

SDLC typically involves a series of phases, which I'll discuss below, to ensure that software is developed on time, within budget, and to the required quality standards.

Why SDLC? 🤔

SDLC is essential in software development as it helps teams deliver high-quality software products on time, within budget, and with minimal errors. It provides a framework for managing and controlling the development process, ensuring that the final product meets the required standards and user expectations.

Phases of SDLC 📅

The SDLC process consists of seven distinct phases that help ensure software development is done efficiently and effectively.

Let's see what the phases in the Software Development Life Cycle (SDLC) are all about:

1. Planning 📝

In this phase, we determine the project's goals, scope, and feasibility. This phase sets the foundation for the entire project, so it's crucial to get it right.

Example: Project managers define the project objectives and decide whether the project is feasible.

2. Requirements Analysis 🔍

Here, we gather and analyze user requirements to ensure the software will meet user needs.

Example: Business analysts gather detailed requirements from stakeholders and document them.

3. Design 🖌️

This phase involves creating architectural and detailed designs. These designs serve as blueprints for the development team.

Example: Architects and developers create system designs and detailed specifications.

4. Implementation (Coding) 💻

Now, it's time to write and compile the code. Developers must adhere to the design specifications to ensure the code meets the required standards.

Example: Developers start writing code based on the design documents.

5. Testing 🧪

We verify that the software works as intended in this phase. This helps catch and fix any bugs or issues before deployment.

Example: Testers run various tests to ensure the software is bug-free and meets requirements.

6. Deployment 🚀

Deploying the software to the production environment happens here. This makes the software available for users.

Example: The software is deployed to production and made available to users.

7. Maintenance 🔧

Finally, we perform updates and bug fixes post-deployment. This ensures the software continues to function properly and remains up-to-date.

Example: Ongoing maintenance and support ensure the software continues to function properly.

Unlocking Efficiency: CI/CD

Sandeep Sangu — Fri, 19 Jul 2024 12:50:48 +0000

Hello, everyone! 👋

In the fast-paced world of software development, speed and quality are crucial. Continuous Integration (CI) and Continuous Delivery (CD) are two practices that have revolutionized the way teams work together to deliver high-quality software products. In this post, we'll explore the definitions, benefits, and some of the best practices of CI/CD, as well as introduce some popular tools that can help you get started.

🤖 Continuous Integration (CI)

Definition: Continuous Integration is a software development practice where team members integrate their work frequently, usually at least daily, leading to multiple integrations per day.

Goal: Ensure that the software is working correctly and catch errors early in the development cycle.

Key Activities:

🧪 Write and run automated tests
🛠️ Build the software
📂 Integrate code changes into a central repository
✔️ Run automated tests to validate the build

🚀 Continuous Deployment (CD)

Definition: Continuous Deployment is the practice of automatically building, testing, and deploying code changes to production after they pass automated tests.

Goal: Ensure that code changes are quickly and safely deployed to production, allowing for faster time-to-market and reduced risk.

Key Activities:

🔧 Automatically build and test code changes
📦 Deploy code changes to production if tests pass
🔍 Monitor production for errors or issues

🏭 Continuous Delivery (CD)

Definition: Continuous Delivery is the practice of building, testing, and preparing code changes for release to production, allowing for quick and safe deployment at any time.

Goal: Ensure that code changes are ready for release to production at any time, and can be deployed quickly and safely.

Key Activities:

🛠️ Build and test code changes
📦 Prepare code changes for release to production
🚀 Release code changes to production manually or automatically

🎉 Benefits of CI/CD

🏁 Here are some of the benefits of implementing CI/CD:

Faster Time-to-Market ⏱️: CI/CD helps teams to deliver software products faster, allowing them to stay ahead of the competition.
Improved Quality 💯: CI/CD ensures that code changes are thoroughly tested, reducing the likelihood of errors and bugs.
Reduced Risk 🚨: CI/CD helps teams to identify and fix errors early, reducing the risk of downstream problems.
Increased Efficiency 💪: CI/CD automates repetitive tasks, freeing up teams to focus on more important tasks.

🌟 Best Practices for CI/CD

Here are some of the best practices for implementing CI/CD in your project:

Automate Everything 🤖: Automate as much of the build, test, and deployment process as possible.
Use Version Control 🗂️: Utilize version control systems like Git to track code changes.
Test Thoroughly 🧪: Write comprehensive tests to ensure that code changes are thoroughly tested.
Monitor and Analyze 📈: Continuously monitor and analyze the performance of your CI/CD pipeline to identify areas for improvement.

🛠️ CI/CD Tools

Here are some popular tools to help you implement CI/CD in your projects:

Jenkins 🤖: An open-source automation server that helps teams automate the build, test, and deployment of code changes.
Travis CI 🚀: A hosted continuous integration service that helps teams automate the build and test of code changes.
CircleCI 🌈: A cloud-based platform that helps teams automate the build, test, and deployment of code changes.
GitHub Actions 🦸‍♂️: Integrated with GitHub repositories, it allows you to automate workflows, including CI/CD, directly from your repository.
GitLab CI/CD 🦊: Part of GitLab, it provides a complete CI/CD pipeline solution integrated with GitLab's version control.

🎉 Conclusion

Thanks for reading! If you found this post helpful, please share it with your network. If you have any questions or thoughts about CI/CD, feel free to share them in the comments below.

By breaking down complex concepts into smaller chunks and using relatable examples, I hope to have made it easier for you to understand and learn about Continuous Integration, Continuous Deployment, and Continuous Delivery.

📚 References for Further Reading

Happy learning, and I wish you all the best in your journey! 📘✨

Understanding CI/CD

Sandeep Sangu — Fri, 19 Jul 2024 12:50:30 +0000

🚀 Understanding CI/CD: Continuous Integration & Continuous Deployment

Hello, everyone! 👋

Today, I'm sharing a simplified guide to CI/CD, covering the essentials of Continuous Integration and Continuous Deployment. But, there's more to CD than meets the eye - we'll also touch on the often-overlooked aspect of Continuous Delivery. Whether you're new to the concept or looking to brush up, this post will help you understand CI/CD in an easy-to-grasp way. Let's get started! 🌟

🤖 Continuous Integration (CI)

Imagine a Library 📚:

Multiple authors (developers) write books (code) and submit them to the library (repository).
A librarian (CI tool) collects all the books, checks for errors, and ensures they are properly formatted.
If a book has errors, the librarian sends it back to the author for corrections.
Once all books are error-free, the librarian creates a master copy (build) and stores it in the library.

Key Takeaway: CI ensures that individual code changes are integrated into a central repository, and automated processes verify that the code is correct and functional.

🚀 Continuous Deployment (CD)

Imagine a Restaurant 🍽️:

Chefs (developers) prepare dishes (code) and pass them to the kitchen staff (CD tool).
The kitchen staff checks the dishes for quality and presentation and then serves them directly to customers (production).
If a dish is not up to standard, the kitchen staff sends it back to the chef for rework.
Once a dish is approved, it's immediately served to customers.

Key Takeaway: CD automates the deployment of code changes to production, ensuring that only validated and tested code reaches the end-users.

🏭 Continuous Delivery (CD)

Imagine a Factory 🏭:

Workers (developers) build components (code) and pass them to the quality control team (CD tool).
The quality control team checks the components, assembles them into a final product, and packages it for delivery.
The packaged product is then stored in a warehouse (repository) until it's ready to be shipped to customers (production).
When the product is shipped, the factory receives feedback from customers, which is used to improve the production process.

Key Takeaway: CD ensures that code changes are built, tested, and packaged into a releasable product, which can be deployed to production at any time. It's a bridge between CI and CD.

🎉 Conclusion

I hope these analogies have helped you understand the basics of CI/CD. My goal is to make complex concepts simple and easy to grasp. 😊

Thanks for reading! If you found this post helpful, please share it with your network. If you have any questions or thoughts about CI/CD, feel free to share them in the comments below. Happy learning! 👨‍💻👩‍💻

Now that we've explored the world of CI/CD through analogies, you should have a solid grasp of what these concepts entail.

In the next post, let's dive into the actual definitions, benefits, and best practices of CI/CD.

I'll also introduce some popular CI/CD tools. Stay tuned! 📘🔧✨

Part 2: Activating the Event Relay in Salesforce and AWS

Sandeep Sangu — Sun, 18 Feb 2024 12:44:06 +0000

Welcome back to our event-driven journey with Salesforce and AWS. This chapter focuses on activating the Salesforce Event Relay and connecting it with Amazon EventBridge, a key step to achieving a seamless data flow and leveraging the full capabilities of our integrated setup.

Taking a streamlined approach, we'll utilize the straightforward instructions from the official Salesforce documentation, ensuring clarity and direct access to essential steps without unecessary elaboration.

Let's continue our adventure, where we'll activate the Partner Event Source in Amazon EventBridge and kick-start the event relay in Salesforce. Ready for the next leap? Let's dive in.

Initial Setup: Begin by ensuring you are logged into both your Salesforce and AWS free tier consoles. This foundational step is crucial for the tasks ahead.

Before Activating:

In acknowledgment of Salesforce’s detailed documentation, I recommend consulting their official guide to activate the Partner Event Source in Amazon EventBridge. Visit Activate the Partner Event Source in Amazon EventBridge for comprehensive steps on completing the setup, including the event bus association. Successfully doing so will change the event source status to Active.

Following the association of the partner event source with the event bus, your setup should resemble the snapshot below:

Continuing with the momentum, initiating the event relay is our next objective. Salesforce offers clear instructions that facilitate this process effortlessly. For a step-by-step guide, consult Start the Event Relay.

Completing these tasks marks a significant milestone in our journey, successfully concluding the initial half of our adventure.

Setting Up Our Log Group 📝

Let's quickly set up a log group in AWS CloudWatch. This log group will play a crucial role later on. I’ve named mine SF-Employee-CDC-Logs as a nod to its purpose. For this demo, I named it with a specific focus. I encourage you to choose a name that aligns with your setup, capturing the essence of your demo.

EventBridge Rule

As we delve deeper into integrating Salesforce with AWS, our next pivotal task is to establish an EventBridge rule 🛠️. This rule is designed to capture events from any Salesforce custom object enabled for Change Data Capture (CDC), relaying them through our configured AWS partner event source and into the CloudWatch log group we've prepared.

Salesforce's documentation offers a clear, step-by-step guide for both setting up this EventBridge rule and ensuring it's correctly linked to the event bus and the designated log group. For comprehensive instructions on configuring the rule to capture and store events as intended, please refer to Create an EventBridge Rule for Logging Events in a CloudWatch Log. This resource provides all the details you need to successfully navigate this critical step, ensuring a seamless flow of data within our integrated cloud environment.

In customizing our integration, I've assigned the rule a specific identifier, SF-CDC-EmployeeChange-Rule, to clearly reflect its function. Feel inspired to select a name that aligns with what you’ve established so far in this demo, truly making it your own.

Adding a Personal Touch from Step 6 Onwards:

Following Salesforce's guide closely until step 5 was helpful, but from step 6, I introduced some personal tweaks to better fit our scenario:

Event Source: Select Others to broaden our event capture scope.
Sample Event: Skipping this is optional, though it may simplify your setup.
Creation Method: Use the Custom pattern option in the JSON editor for more control.
Event Pattern: Craft your event capture criteria with this JSON structure:

{
  "source": ["aws.partner/salesforce.com/xxxxxxxxxxxxxxxxA0/0YLIS000000KyjB4AS"],
  "detail-type": ["Employee__ChangeEvent"]
}

⚠️ Important Note: The ID in the event source is intentionally obscured for privacy. Please ensure you substitute this with the complete ID of your event bus, which was generated when you associated/activated the partner event source.

Continue by clicking 'Next', guiding you to the 'Select target(s)' page:

Target 1: Within the AWS Service section, select CloudWatch log group from the dropdown.
Log Group: Enter the name of the log group you created earlier, SF-Employee-CDC-Logs.

Upon successfully configuring your rule, inspecting your event bus will display a setup similar to what's illustrated below, confirming that your configuration is on point and operational:

And just like that, we're almost at the finish line 🏁! The last piece of our setup puzzle is to enable CDC on our custom object. Let's dive into that:

From the Setup page in Salesforce, use the quick find box to search for Change Data Capture. You'll see a page similar to what's shown below. From the available entities, type in the name of the custom object you created, select it, and use the arrow to move it from the available to the selected entities, then click on "Save."

🎉 Voila! We've now wrapped up the essential setup, ready to witness our creation spring into action.

Before we proceed, let's do a quick recap ⚡ of what we've accomplished in Part 1 and Part 2:

AWS and Salesforce Setup: Checked and done!
Within Salesforce:
- Crafted a custom object and populated it with sample records.
- Set up Named Credentials and CORS with the required URLs of Postman in the allowed origin list.
- Created a channel for a change event using Postman, and added a channel member.
- Ended Part 1 by setting up the event relay.
In Part 2, focusing on AWS:
- Navigated to AWS and activated the partner event source by selecting it and clicking on "Associate with event bus," then confirmed that the status is "Active."
- Created a log group in AWS CloudWatch.
Back in Salesforce to wrap up:
- Changed the status of the Event Relay from "Stopped" to "Running."
- Enabled CDC on the custom object to catch those changes.

With our setup complete, what's next on the horizon? 🌅

Coming Up in Part 3: Visualization with Grafana

In our grand finale, we'll turn raw data into visual insights. We'll guide you through integrating CloudWatch logs with Grafana and setting up dashboards that vividly display our event data. Get ready for a visual feast as we explore Create, Delete, and Update operations, tracing the journey of events to our log group, and finally, to Grafana for the ultimate visualization.

Stay tuned for the thrilling conclusion of our series, where data meets design! 📊🎨

Disclaimer: This series is based on my personal experiences and insights gained from various resources and documentation. The aim is to share knowledge and foster learning within the community. Any resemblance to other materials is coincidental, and I acknowledge the contributions of the broader tech community in advancing our understanding of these topics.

#CommunityContributions

DEV Community: Sandeep Sangu

S3 Bucket Names Just Got Simpler — Here's What Actually Changed

Interested in the AWS Community Builders program?

Amazon Nova, Explained the Way I Wish Someone Had

A Quick Look at Nova Models — In Simple Terms

🧠 Understanding Models — Text, image, or video in → Text out

🎨 Creative Models — Text or image in → Image or video out

🎤 Speech Model — Speech in → Speech + text out

What Even is Amazon Nova? (And No, It’s Not Just Another Chatbot)

🛠 What I Tried — Real Prompts, Real Results

🎬 But That’s Not All — I Couldn’t Resist Trying the Others

My Profile Is Now Live on the New AWS Builder Center 🚀

Going Serverless — Automating PDF Parsing with S3, Lambda & DynamoDB (Part 2)

🧭 Introduction

⚙️ What This Part Covers

🏥 Real-World Scenario: Why Automating PDF Processing Matters

🗺️ Architecture Overview

🛠️ Step-by-Step Implementation

📁 1. S3 Setup — Upload as a Trigger

⚙️ 2. Lambda Function — Extract and Parse on the Fly

🧾 3. Textract Output Processing — Turning Lines Into Records

🗂️ 4. DynamoDB Storage — Saving Each Record

📜 5. Monitoring with CloudWatch Logs

🔐 6. IAM Roles — Permissions That Make It Work

📸 Demo Output & Screenshots

🧠 Lessons Learned Along the Way

✅ Final Thoughts

Local PDF Parsing with AWS Textract & Python (Part 1)

✍️ Introduction

🔍 What This Project Is

📄 Why Document Parsing Matters

🧪 Local First: Why I Didn’t Start with Automation

🧱 Prerequisites

📂 Project Structure

🧪 What the Local Script Does

✅ Outcome and What’s Next

🔗 References

🔜 Coming Up in Part 2:

Agile Methodology

Introduction to Agile 🚀

Agile Principles 🌟

Agile Methodologies 🌐

1. Scrum 🏉

2. Kanban 📊

Scrum Framework 🏉

Roles 👥

1. Product Owner 📋

2. Scrum Master 🧑‍🏫

3. Development Team 💻

Ceremonies ⏰

1. Sprint Planning 🗓️

2. Daily Scrum 🕒

3. Sprint Review 📝

4. Sprint Retrospective 🔄

5. Backlog Refinement 📋

Artifacts 📦

1. Product Backlog 📃

2. Sprint Backlog 🗂️

3. Increment 📈

Example 🏠

Advantages of Agile 🚀

Popular Agile-Scrum Tools 🛠️

Further Reading 📚

SDLC - Waterfall Model

Phases 📅

Example 🍰

Advantages ✅

Disadvantages ❌

Further Reading 📚

Software Development Life Cycle

Why SDLC? 🤔

Phases of SDLC 📅

1. Planning 📝

2. Requirements Analysis 🔍

3. Design 🖌️

4. Implementation (Coding) 💻

5. Testing 🧪

6. Deployment 🚀

7. Maintenance 🔧

Further Reading 📚

What Even is `Amazon Nova`? (And No, It’s Not Just Another Chatbot)