thats.nono

AWS Strands vs LangGraph on Bedrock AgentCore: Lessons from Building an Agentic Platform

Yoonsoo Park — Sat, 28 Feb 2026 00:00:00 +0000

Comparing AWS Strands and LangGraph through hands-on PoC experience on Amazon Bedrock AgentCore — real cold start numbers, a three-tier tool architecture pattern, and the async tool gap that caught us off guard.

AWS Strands Agents SDK | LangGraph Documentation | Amazon Bedrock AgentCore

Most framework comparisons stop at “hello world.” You read them, nod along, then hit a wall that the blog never mentioned. This post is the opposite of that. I want to share what actually happened when we ran both AWS Strands and LangGraph through PoCs on a financial SaaS platform, picked one, and started building a real multi-tool agent with it. Spoiler: we found a gap that made us rethink our confidence level.

The Setup: Why We Needed an Agent Framework

Our platform is 100% AWS-native. The primary execution environment is Amazon Bedrock AgentCore — think of it as a managed runtime for AI agents with built-in memory, tool routing, and IAM-based auth. We needed to build agentic workflows that could handle 51 backend actions (knowledge base search, document extraction, custom AI actions, etc.) for financial domain customers.

Two candidates made the shortlist:

LangGraph (LangChain ecosystem) — explicit state machines, large community, mature docs
AWS Strands (AWS-native) — autonomous agent loop, @tool decorators, minimal boilerplate

We PoC’d both, picked Strands, and started building a real agent with 25+ tools on it. The story isn’t as simple as “X is better.” It’s more like “X works great until you hit this wall.”

What Killed LangGraph in Our PoC

I want to be clear: LangGraph is a solid framework. The state machine model gives you explicit control over every step — when the LLM gets called, when tools execute, how results route. For complex multi-step workflows, that’s powerful. But in our environment, it never got the chance to show that.

The 30-Second Wall

AgentCore Runtimes have a strict 30-second initialization limit. That’s not configurable. LangGraph relies on langchain-core, which pulls in numpy and pydantic-core — packages that need native C-extensions (.so files compiled for Linux ARM64). When you try to pip install these during cold start, you reliably blow past the 30-second limit.

The workaround exists: use Docker-based Lambda build containers (public.ecr.aws/sam/build-python3.11), pre-compile ARM64 wheels, bundle them into your CDK code assets before deployment. It works. But it also means every code change goes through a Docker build step that kills your iteration speed. For a PoC where you’re experimenting rapidly, that friction adds up fast. Trust me, we tried to make it work for a while before moving on.

We confirmed this wasn’t a one-time issue — across our entire PoC period with AgentCore, the 30-second init limit remained the fundamental constraint. LangGraph remains blocked for our use case unless AgentCore lifts this limit or LangGraph dramatically reduces its dependency footprint.

The Ecosystem Advantage is Real Though

I want to acknowledge something: LangGraph has significantly better documentation and community support. It launched earlier, so there are more reference implementations, more Stack Overflow answers, more patterns to copy. When we hit issues with Strands, the answer was often “read the Bedrock docs and figure it out.” With LangGraph, someone had usually already solved it. That gap matters during the learning curve. It just didn’t outweigh the deployment blocker for us.

Strands in Practice: What We Actually Built

Here’s our agent entry point. The whole thing:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# agent.py — 26 lines total
from strands_agents import Agent, BedrockModel

model = BedrockModel(
 model_id="us.anthropic.claude-sonnet-4-20250514-v1:0",
 temperature=0.1,
 streaming=True,
)

agent = Agent(model=model, tools=tools, system_prompt=prompt)
result = agent(user_input) # Autonomous loop handles everything

That’s it. No state machine definition, no node compilation, no conditional edge routing. The agent loop decides when to call tools, when to respond, when to ask for clarification. You hand it tools and a prompt, it figures out the rest.

For comparison, the LangGraph equivalent would need roughly 80-100 lines: state class definition, chatbot node, tools node, conditional edge routing function, graph compilation, and invocation boilerplate.

Cold starts? Under 500ms. We use UV bytecode compilation (UV_COMPILE_BYTECODE=1 in our Dockerfile) which pre-compiles Python files during the Docker build. No numpy, no pydantic-core compilation overhead. CDK deploys directly without Docker pre-compilation tricks.

The Three-Tier Tool Architecture

This is the pattern we landed on through our PoC iterations. It wasn’t planned upfront — it emerged from hitting real constraints around latency, security, and multi-tenant isolation:

┌─────────────────────────────────────────────┐
│ Strands Agent (Claude Sonnet 4) │
└──────────────────┬──────────────────────────┘
│
┌─────────────┼─────────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────────┐
│ Direct │ │ Gateway │ │ Tool │
│ Tools │ │ Tools │ │ Wrappers │
│ (15×) │ │ (10×) │ │ │
└─────────┘ └──────────┘ └──────────────┘
│ @tool │ MCP proto │ Auto-inject
│ decorator │ Lambda │ tenant_id
│ In-process │ backends │ Hidden from
│ execution │ IAM auth │ LLM context
└────────────┴────────────┴───────────────

Why three tiers?

Direct Tools run inside the agent container. They’re simple functions decorated with @tool — Strands auto-extracts the JSON schema from the function signature and docstring. No manual schema definition needed. We have 15 of these for low-latency, same-tenant operations. Average: ~24 lines per tool including docstring and serialization.

Here’s what a direct tool looks like (simplified from our actual implementation):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@tool
def search_knowledge_base(query: str, max_results: int = 5) -> str:
 """Search the knowledge base for relevant documents."""
 client = boto3.client("bedrock-agent-runtime")
 response = client.retrieve(
 knowledgeBaseId=os.environ["KB_ID"],
 retrievalQuery={"text": query},
 retrievalConfiguration={
 "vectorSearchConfiguration": {"numberOfResults": max_results}
 },
 )
 results = [
 {"text": r["content"]["text"], "score": r["score"]}
 for r in response["retrievalResults"]
 ]
 return json.dumps({"results": results, "count": len(results)})

~16 lines. In LangGraph, the same tool needs a state TypedDict, a node function, graph wiring, and compilation — roughly 40-50 lines. Multiply that by 15 tools and the difference is significant.

Gateway Tools go through MCP (Model Context Protocol) to Lambda backends with SigV4 authentication. These handle cross-tenant operations or operations that need their own execution context. We define them in CDK and the MCP client discovers them at runtime.

Tool Wrappers solve a subtle but important problem: tenant isolation. The LLM should never see or manipulate tenant_id directly — that’s a security boundary. Wrappers auto-inject the tenant ID into tool calls before they hit the backend, keeping it invisible to the model:

1
2
3
4
5
6
7


# Simplified wrapper pattern
def wrap_tool_with_tenant(tool_fn, tenant_id):
 @wraps(tool_fn)
 def wrapped(**kwargs):
 kwargs["tenant_id"] = tenant_id # Injected, never from LLM
 return tool_fn(**kwargs)
 return wrapped

This pattern was born from a real security review, not from upfront design. The LLM was occasionally hallucinating tenant IDs in early testing — yeah, it just made up tenant IDs that looked plausible. In a financial platform, that’s a nightmare. Wrappers killed that problem entirely.

The Bedrock Memory Integration

One thing that “just worked” was Bedrock Memory. Our configuration:

Semantic indexing: Auto-retrieve relevant context from past conversations
Summarization: Compress long conversation histories so the context window stays manageable
Retention: 90 days
Last K turns: Load the 10 most recent turns on agent initialization

We use a HookProvider pattern (more on hooks below) to load memory on session start. The agent gets conversation context without any explicit retrieval code — Bedrock handles the vector search and summarization behind the scenes.

This is one of Strands’ strongest selling points compared to LangGraph: the managed infrastructure handles memory, auth, and tool routing. With LangGraph, you’d wire each of these manually.

The Gotchas Nobody Tells You About

Building a real agent teaches you things that docs don’t.

Container Tool Caching (High Impact)

After deploying a new Gateway Lambda function, the running AgentCore container still has stale tool definitions. The MCP client caches tool schemas at container startup. Your only option: wait 60-90 seconds for the container idle timeout to trigger a restart.

This sounds minor. It isn’t. When you’re iterating on a Gateway tool — deploy, test, see wrong behavior, realize it’s stale, wait, test again — you lose 2-3 minutes per cycle. Over a day of active development, that adds up.

Response Format Quirk

agent.result.message returns a dict, not a string:

1
2
3
4
5


# What you might expect
result.message # "Here's the extracted text..."

# What you actually get
result.message # {"role": "assistant", "content": [{"text": "Here's the extracted text..."}]}

Every caller has to extract content[*].text blocks. It’s a small thing, but when you’re debugging at midnight wondering why your response is empty… you remember this one. Wish the SDK just handled it.

boto3 Version Lock-in

Strands with AgentCore requires boto3 >= 1.42.54 for the Data Plane client. If your other services pin an older version, you’ll hit dependency conflicts. We manage this with isolated virtual environments per service, but it’s friction.

The Hard Part: The Async Tool Gap

Now for the finding that changed my confidence level from “high” to “medium.” This is where Strands’ simplicity becomes a real limitation.

The Problem

Our platform has dozens of backend actions. Roughly half are synchronous. The other half are asynchronous — things like Textract document extraction (2-5 minutes for large PDFs), async LLM inference, document intelligence processing. The async ones use a robust infrastructure: job tracking, Step Functions for polling, EventBridge for completion events.

But Strands’ autonomous loop completes in a single conversation turn. When a tool returns {"status": "pending"}, the agent receives it, tells the user “processing…”, and the conversation ends. There’s no built-in mechanism to poll, wait, or resume.

Here’s what actually happens in practice:

User: "Extract text from this document"
Agent: calls extract_document("file_id_123")
→ returns {"status": "pending", "job_id": "abc-def-..."}
Agent: "Text extraction is in progress. Please check back later."
[Agent loop ends — no mechanism to retry or wait]
User: "Is it done yet?"
Agent: calls check_job_status("abc-def-...")
→ returns {"status": "pending"}
Agent: "Still processing..."
User: [waits another minute, asks again]
Agent: calls check_job_status("abc-def-...")
→ returns {"status": "succeeded", "output": "..."}
Agent: "Here's the extracted text!"

The user has to manually poll. That’s not a great experience.

Why This Matters More Than It Seems

During the early PoC, this felt like a minor issue — we mostly exposed sync tools first. But looking at our actual backend, roughly half of our actions are asynchronous. Things like document processing via Textract, async LLM inference, batch data operations — these are all long-running jobs that return pending and complete later.

Most of these aren’t exposed to the Strands agent yet. But as we expand the tool surface toward production, this architectural gap becomes central.

The Architecture Disconnect

Our backend already has great async infrastructure. The pattern is common in AWS: when a tool kicks off a long-running job (e.g., Textract, async inference), it returns immediately with {"status": "pending"} and a job ID. A Step Functions state machine then polls for completion, updates the job status, and stores the result.

Tool invocation
│
├─ Sync job? → execute → status: "succeeded" → return
│
└─ Async job? → validate → status: "pending"
│
▼
Step Functions
├─ Poll every N seconds
├─ Update status: pending → running → succeeded
└─ Store result

The problem is that Strands doesn’t know about any of this. The agent calls the tool, gets back {"status": "pending"}, and moves on. Step Functions completes the job in the background, but the agent is long gone.

┌─────────────────────────────────┐
│ Strands Agent │
│ call tool() │
│ → {"status": "pending"} │
│ → tells user "processing..." │
│ → loop ends ← HERE │
└────────────────┬────────────────┘
│ (disconnected)
┌────────────────▼────────────────┐
│ Backend Async Infrastructure │
│ Step Functions polling │
│ Job: pending → succeeded │
│ (agent is already gone) │
└─────────────────────────────────┘

Where LangGraph Would Shine

This is, honestly, where LangGraph’s state machine model is genuinely superior. You can define a polling loop as a conditional edge:

1
2
3
4
5


workflow.add_conditional_edges("poll_status", route_by_status, {
 "check_again": "poll_status", # ← loops back
 "completed": "summarize",
 "timeout": END,
})

The state machine maintains job_id, retries, status across iterations. One user request, one final result. No manual polling.

Our Workaround Strategy

We’re not switching frameworks over this. Instead, we’re taking a phased approach:

Right now: Accept manual polling for the few async tools we’ve exposed. Not ideal, but the frequency is low enough that users tolerate it.

Next quarter: Implement EventBridge + Bedrock Memory integration. When an async job completes, an EventBridge rule triggers a Lambda that writes the result to Bedrock Memory with a tagged key. When the user asks again, the agent checks Memory first — one follow-up instead of repeated polling.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


@tool
def extract_document_text(file_id: str) -> str:
 """Start async extraction. Results stored in memory on completion."""
 job_id = start_textract_async(file_id)
 # EventBridge: Textract complete → Lambda → save to Memory
 return json.dumps({
 "status": "processing",
 "message": "Extraction started. Ask me again in a minute for results."
 })

@tool
def check_extraction_result(job_id: str) -> str:
 """Check if extraction completed (reads from Memory first)."""
 result = memory_client.search(tag=f"extraction_{job_id}")
 if result:
 return json.dumps({"status": "completed", "text": result["text"]})
 return json.dumps({"status": check_job_status(job_id)})

Before production: If async tool usage looks like it’ll exceed 60-70% of traffic, we’ll re-evaluate LangGraph. By then, maybe AgentCore lifts the 30-second init limit, or maybe we invest in Docker pre-compilation to make LangGraph deployable. We’ll see.

The Numbers

Here’s where the metrics stand so far:

Metric	Value
Agent setup code	26 lines (agent.py) + 79 lines (main.py)
Lines per tool (avg)	~24 lines with `@tool` decorator
Tools implemented	25 (15 direct + 10 Gateway)
Cold start	< 500ms
Full CDK deploy	~8-12 min
Container tool refresh	~60-90 sec after Gateway update
Code reduction vs LangGraph	~3× for tool definitions

So, Which One Should You Pick?

If you’re deploying on Bedrock AgentCore with mostly synchronous tools, Strands is the clear winner. The developer experience is outstanding — 26 lines for an agent, sub-500ms cold starts, and @tool decorator that eliminates boilerplate. The managed infrastructure (memory, auth, tool routing) saves weeks of wiring.

If your workload is async-heavy — lots of long-running jobs, polling, multi-step workflows with state — LangGraph’s state machine model is architecturally better suited. But you’ll need to solve the AgentCore deployment friction first (Docker pre-compilation, dependency bundling).

If you’re somewhere in the middle like us — mostly sync today, growing async tomorrow — start with Strands and plan your async workarounds early. Don’t wait until half your tools are async to discover the gap like we did.

The honest answer is that there’s no perfect framework yet for this space. Strands trades control for simplicity. LangGraph trades simplicity for control. Both trade-offs have consequences that only show up after you’ve been building with them for a while.

If you’re building agentic workflows on AWS and have questions about any of this, feel free to reach out. I’m still learning too, and the landscape is changing fast. Hopefully this post saves you some of that discovery time we had to go through the hard way.

Why You Should Switch to uv for Python Projects

Yoonsoo Park — Sat, 14 Feb 2026 00:00:00 +0000

If you are a Python developer, you are likely familiar with the fragmented ecosystem of tooling. You use pip for installing packages, venv or virtualenv for environments, pyenv for managing Python versions, and maybe poetry or pip-tools for dependency resolution. It’s a lot to manage.

Enter uv.

Created by Astral (the team behind Ruff), uv is an extremely fast Python package and project manager written in Rust. It’s designed to be a drop-in replacement for pip and pip-tools, but it has evolved into a full-fledged project manager that challenges poetry and pdm.

In this post, I’ll explain why uv is a game-changer and why you should consider switching today.

Why `uv` is a Game Changer

1. Blazing Speed

Yup, it is freaking fast. In many benchmarks, uv is 10-100x faster than pip-tools or poetry for resolution.

2. Unified Toolchain

uv consolidates multiple tools into one. You no longer need separate tools for:

Package Installation (pip)
Environment Management (venv, virtualenv)
Python Version Management (pyenv)
Dependency Locking (pip-compile, poetry lock)
Script Running (pipx)

You can do it all with a single binary.

3. Automatic Python Version Management

This is my favorite feature. If a project requires Python 3.12 but you only have 3.11 installed, tools like poetry will complain. You’d have to go to pyenv, install 3.12, and then tell poetry to use it.

With uv, you just define the required python version in your project. uv will automatically download and install the correct Python version for that project if it’s missing, in an isolated manner (in .venv). No more global Python version conflicts!!

Comparison: uv vs Poetry

If you are currently using Poetry, you might wonder if it’s worth the switch.

Feature	Poetry	uv
Language	Python	Rust
Speed	Slow (dependency resolution can take minutes)	Instant (sub-second resolution)
Python Management	Relies on external tools (pyenv/system)	Built-in (installs Python automatically)
Standards	Uses `pyproject.toml` (standard)	Uses `pyproject.toml` (standard)
Lock File	`poetry.lock`	`uv.lock` (cross-platform)

The biggest pain point with Poetry has always been the dependency resolver speed. uv solves this completely.

Migrating from `requirements.txt`

If you have a legacy project using requirements.txt, migrating to uv is EZ. You don’t have to rewrite everything from scratch.

uv supports installing directly from requirements files, and it gives you two ways to do it:

1. Using `uv pip` (The “pip” way)

If you just want to use uv as a faster pip without changing your workflow:

1

uv pip install -r requirements.txt

This installs packages into your current environment exactly like pip install -r requirements.txt, just much faster.

2. Using `uv add` (The “Project” way)

If you are initializing a new uv project (uv init) and want to import your dependencies:

1

uv add -r requirements.txt

This reads your requirements.txt and adds the dependencies to your pyproject.toml file, effectively migrating your project management to uv.

Common Commands Cheat Sheet

Here are the commands you will use 90% of the time:

Initialize a project:
1

uv init
Add a dependency:
1

uv add requests
Run a script:
1

uv run main.py
Note: uv run will automatically create a virtual environment, install dependencies, and run the script in that isolated environment.
Sync environment:
1

uv sync
Ensures the virtual environment matches the uv.lock file.

`uv add` vs `uv pip install`

It’s important to understand the difference between these two commands, as uv supports both “project” and “script” workflows.

uv add <package>:
- Used for managing a project.
- Updates pyproject.toml and uv.lock.
- Ensures reproducible builds for your application.
- Similar to poetry add.
uv pip install <package>:
- Used for low-level environment modification.
- Does NOT update pyproject.toml.
- Useful for CI/CD pipelines or ad-hoc environments where you just need packages installed quickly without tracking them.
- Similar to pip install.

Caveats

While uv is fantastic, it is moving very fast.

It is relatively new, so edge cases with obscure build backends might still exist.
If you rely heavily on Poetry plugins, uv might not have an equivalent yet.

Conclusion

Give it a try on your next project. You won’t want to go back. At least I won’t. Cheers!

Python init.py Explained: Mastering Package Structure and Imports

Yoonsoo Park — Mon, 09 Feb 2026 00:00:00 +0000

If you’ve ever dug into a popular Python library like requests or pandas, you’ve likely stumbled upon a file named __init__.py. Sometimes it’s empty, sometimes it’s packed with imports, but it’s almost always there.

When I first started with Python, I treated __init__.py as a magical ritual—a file I had to create to make my imports work, without really understanding why.

Turns out, __init__.py isn’t just boilerplate. It’s the gateway to your package. It allows you to transform a messy directory of scripts into a easy-to-use library.

Let’s look at a scenario to see how we can use __init__.py to refactor a messy project into something more professional that you love to show off.

Scenario: Building a Notification System

Imagine you’re building a backend service that needs to send notifications via different channels: Email, SMS, and Push Notifications.

A typical beginner’s project structure might look like this:

1
2
3
4
5
6


notifications/
 __init__.py
 email_service.py
 sms_service.py
 push_service.py
main.py

Inside email_service.py, you might have:

1
2
3
4


# notifications/email_service.py
class EmailSender:
 def send(self, message):
 print(f"Sending Email: {message}")

And similarly for SMS and Push.

The Problem: Clunky, “Deep” Imports

Now, when you want to use these classes in your main.py, you must know exactly which file contains which class. Your imports become long and expose internal file structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# main.py (Without proper __init__.py usage)

from notifications.email_service import EmailSender
from notifications.sms_service import SmsSender
from notifications.push_service import PushSender

def notify_user(msg):
 # Usage is fine, but the imports are ugly
 sender = EmailSender()
 sender.send(msg)

I mean it is okay, but it’s annoying.

Verbose: You have to type notifications.filename every time.
Brittle: If you rename email_service.py to email.py later, you break every file that imports it.

The Solution: Expose Classes in `init.py`

We can use __init__.py to create a shortcut.

Let’s modify notifications/__init__.py to import the classes inside the package, so they are available at the top level.

1
2
3
4
5
6
7
8
9


# notifications/__init__.py

# Use relative import (.) to import from the current directory
from .email_service import EmailSender
from .sms_service import SmsSender
from .push_service import PushSender

# Optional: Control what gets imported with 'from notifications import *'
__all__ = ['EmailSender', 'SmsSender', 'PushSender']

The Result: Clean, “Flat” Imports

Now, look at how beautiful and intuitive main.py becomes. The user doesn’t need to know about email_service.py or sms_service.py. They just import from notifications.

1
2
3
4
5
6
7
8


# main.py (With proper __init__.py usage)

# CLEAN! No need to know internal file names
from notifications import EmailSender, SmsSender

def notify_user(msg):
 sender = EmailSender()
 sender.send(msg)

Why is this better?

Abstraction: The user of your package doesn’t need to know that EmailSender lives in a file called email_service.py. It just lives in the notifications package.
Refactoring Safety: You can move EmailSender to backend/legacy/email.py later, and as long as you update the import in __init__.py, your users won’t notice a thing. Their code doesn’t break.

Advanced Tip: Lazy Loading

One downside of importing everything in __init__.py is that it loads all modules when you import the package. If PushSender requires a heavy library (like a specific SDK) that takes time to load, it might slow down your app even if you only wanted to send an SMS.

You can get fancy with “Lazy Loading” inside __init__.py if performance is critical using __getattr__, but for 99% of projects, the pattern above is the gold standard.

Conclusion

The __init__.py file is a tool for encapsulation. It lets you hide the messy details of your file structure and present a clean, flat interface to the world.

Next time you create a folder in Python, don’t just leave __init__.py empty. Ask yourself: “How do I want other developers to import my code?”

Cheers!

Why Do Python Experts Use the @property Decorator?

Yoonsoo Park — Mon, 09 Feb 2026 00:00:00 +0000

If you are learning Python, you might have come across the @property decorator. While many decorators can seem complex to beginners, @property is often confusing for the opposite reason: its behavior is so simple—it allows you to declare a function but access it like a variable—that many wonder why it is necessary at all.

I recently watched a video by 임커밋 that highlighted the importance of @property not just as syntax sugar, but as a tool for better architectural control. Inspired by that, I wanted to share my own take on why experienced developers lean on this feature.

Here are the two main reasons to use @property.

1. Dynamic Attributes (Computed Properties)

The most common use case arises when the external “look” of a value should be a simple attribute, but the internal logic requires calculation.

Consider an e-commerce ShoppingCart class. A cart contains a list of items, each with a price. Naturally, you want to know the total price.

The Problem

If you define total as a standard instance variable, you must remember to update it every time an item is added or removed.

1
2
3
4
5
6
7
8


class ShoppingCart:
 def __init__(self):
 self.items = []
 self.total = 0 # Needs manual updates!

 def add_item(self, price):
 self.items.append(price)
 self.total += price # Easy to forget or get wrong in complex logic

If a developer modifies items directly or forgets to update total, the data becomes inconsistent!

The Function Solution

You could write a method like get_total(), but accessing it requires parentheses (e.g., cart.get_total()). This works, but it exposes the implementation detail that total is calculated, rather than just being a property of the cart. and we all know less code is better. no code no bug. lol

The @property Solution

By using @property, you can define total as a method internally so it calculates the value fresh every time it is called, but you access it externally like a static attribute (e.g., cart.total).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


class ShoppingCart:
 def __init__(self):
 self.items = []

 def add_item(self, price):
 self.items.append(price)

 @property
 def total(self):
 return sum(self.items)

cart = ShoppingCart()
cart.add_item(100)
cart.add_item(50)

print(cart.total) # 150 (Computed on the fly!)

This ensures your data is always consistent—the total can never be out of sync with the items list—without sacrificing attribute-like syntax.

2. Read-Only Protection

The second major reason to use @property is to create “read-only” attributes.

Sometimes you have data that should be visible to the outside world but never modified directly. For example, a User class might have a unique id assigned at creation.

If id were a normal attribute, nothing stops a developer from accidentally overwriting it:

1
2


user = User(id=123)
user.id = 456 # Oops! Data integrity broken.

However, when you define a value using @property without a corresponding setter method, it becomes read-only by default.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


class User:
 def __init__(self, user_id, username):
 self._user_id = user_id
 self.username = username

 @property
 def user_id(self):
 return self._user_id

user = User(101, "python_guru")
print(user.user_id) # 101

# Attempting to modify it raises an error
try:
 user.user_id = 999
except AttributeError as e:
 print(e) # can't set attribute

This behavior allows developers to protect sensitive or critical data (like IDs, timestamps, or derived values) from being accidentally overwritten by external code. It effectively isolates the internal logic from external interference.

Conclusion

While it might seem like a small syntactic sugar, the @property decorator is a something you need to consider for encapsulation. It allows you to maintain the clean interface of simple attributes while keeping the safety of dynamic functions in the background.

Building an Agent Factory with AWS AgentCore

Yoonsoo Park — Sat, 20 Dec 2025 00:00:00 +0000

In the rapidly evolving world of Generative AI, manually deploying agents one by one is no longer sexy. We need systems that can build systems—an Agent Factory.

Today, we will dissect the Agent Factory system I learned at AWS re:Invent 2025. AWS engineers built a system that can build agents using AWS AgentCore, and the repo is https://github.com/mcginnbros/agent-factory.

This platform is designed to bootstrap your personal AWS environment into a fully functional agent ecosystem using AWS AgentCore.

In this post, we’ll peel back the layers and look at the infrastructure that makes this possible: from IAM policies and ECR repositories to the Python tooling that orchestrates it all.

1. The Core Architecture

At the heart of this system lies the concept of a Builder Agent. Instead of writing Terraform or CloudFormation for every new agent you want to experiment with, you talk to the Builder Agent.

The Builder Agent comprises:

Strands Framework: The application logic driving the agent’s reasoning.
AWS AgentCore Runtime: The serverless compute environment hosting the agent container.
Tooling Access: Permissions to call AWS APIs to create other resources.

When you ask the Builder Agent to “Create a weather bot,” it doesn’t just write code; it provisions real infrastructure. 🤯

2. Infrastructure Under the Hood

To enable a safe yet powerful Agent Factory, we lean heavily on AWS native services.

graph TB
subgraph Client ["Client Layer"]
User[User / Developer]
CLI[Python CLI - demo_cli.py]
end
subgraph AWS ["AWS Cloud Account"]
subgraph IAM ["IAM & Security"]
Roles[IAM Roles]
end
subgraph Control ["Control Plane"]
AgentCoreAPI[Bedrock AgentCore API]
Gateway[AgentCore Gateway]
end
subgraph Data ["Data Plane"]
BuilderRuntime[Builder Agent Runtime]
AgentRuntime[Deployed Agent Runtime]
Memory[AgentCore Memory]
end
subgraph Storage ["Artifacts"]
ECR[ECR: reinvent/agents]
end
end
User --> CLI
CLI --> AgentCoreAPI
AgentCoreAPI --> BuilderRuntime
BuilderRuntime --> AgentCoreAPI
AgentCoreAPI --> AgentRuntime
BuilderRuntime --> Memory
AgentRuntime --> Memory
BuilderRuntime -.->|Pulls Image from ECR| ECR
AgentRuntime -.->|Pulls Image from ECR| ECR
style AWS fill:#f9f9f9,stroke:#333,stroke-width:2px

Identity and Access Management (IAM)

Security is paramount when an AI agent has permission to deploy infrastructure. We utilize specific IAM roles with carefully scoped trust policies.

AgentCoreExecutionRole: This is the primary identity for our agents.
- Trust Policy: Allows bedrock-agentcore.amazonaws.com to assume this role.
- Permissions:
  - AgentCoreBradrockAccess: Invoke models (Claude Sonnet/Haiku).
  - AgentCoreECRAccess: Pull Docker images from our private ECR.
  - AgentCoreLambdaInvoke: Call Lambda functions (used for tools).
  - AgentCoreA2AAccess: Communicate with other agents via the A2A protocol.

Elastic Container Registry (ECR)

We use a centralized repository named reinvent/agents to store our agent images.

Base Image: Contains heavy dependencies (Python, Strands, Playwright).
Generic Agent Image: A standardized template that can load specific configurations at runtime.
Builder Image: The specialized image for our factory orchestrator.

AgentCore Memory

We provision a shared AgentCore Memory instance (reinvent_agent_factory-shared) that allows agents to retain context across sessions.

3. Deep Dive: Inside the Builder Agent

The builder_agent directory is the gold mine of this project. It orchestrates the creation of other agents using a “Generic Agent” strategy.

The Generic Agent Pattern

Instead of building a unique Docker image for every new bot (which takes minutes), we use a single Generic Agent Container.

templates/generic_agent.py: This script is the entry point for all deployed agents.
Dynamic Configuration: Behavior is injected at runtime via Environment Variables (SYSTEM_PROMPT, AGENT_MODE, ENABLE_BROWSER).

This allows the Builder Agent to deploy a new agent in seconds by simply pointing a new Runtime to the existing ECR image.

Agent Modes: Server vs. Client

The platform supports two distinct modes of operation:

Server Mode (`AGENT_MODE='server'`)

Purpose: To provide tools or services to other agents.
Mechanism: Starts a FastAPI server on port 9000.
Protocol: Exposed via the Agent-to-Agent (A2A) protocol.
Usage: The AgentCore Gateway routes requests to this port.

Client Mode (`AGENT_MODE='client'`)

Purpose: To consume services and orchestrate tasks.
Mechanism: Runs a loop processing user input; does not listen on a port.
Capabilities: Initialized with KNOWN_AGENT_IDS to call Server agents.

Docker Layering Strategy

We use a FROM ...:base pattern in our Dockerfiles. We verify that a base image (containing heavy libraries like strands, boto3, playwright) exists first. The Builder’s Dockerfile then just copies the lightweight Python scripts on top. This ensures builds are lightning fast.

4. Interacting with the AgentCore SDK

The demo_cli.py provides a practical example of how to interact with the AgentCore service using boto3.

Two Distinct Clients

1
2
3
4
5


# 1. Runtime Client: For invoking agents
self.client = boto3.client("bedrock-agentcore", region_name=REGION)

# 2. Control Plane Client: For managing resources (deploy, list, delete)
self.control_client = boto3.client("bedrock-agentcore-control", region_name=REGION)

Listing and Inspecting Agents

We use the control client to inspect configuration details, such as checking for the A2A protocol and to see what agents are running.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# List all runtimes
response = self.control_client.list_agent_runtimes()

for runtime in response.get("agentRuntimes", []):
 agent_id = runtime["agentRuntimeId"]

 # Get full details to check protocol configuration
 details = self.control_client.get_agent_runtime(agentRuntimeId=agent_id)

 # Check if A2A is enabled
 protocol_config = details.get("protocolConfiguration", {})
 has_a2a_protocol = (protocol_config.get("serverProtocol") == "A2A")

Invoking Agents: Simple vs. JSON-RPC

When sending messages to an agent using the runtime client, the payload format differs based on the agent’s mode:

Standard Agents: Use a simple JSON payload.
A2A Agents: Use the JSON-RPC 2.0 standard.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# Prepare payload based on protocol
if use_jsonrpc:
 # A2A Agents expect JSON-RPC 2.0
 payload = {
 "jsonrpc": "2.0",
 "method": "message/send",
 "params": {
 "message": {
 "kind": "message",
 "role": "user",
 "parts": [{"kind": "text", "text": message}],
 "messageId": f"msg-{uuid.uuid4().hex[:8]}"
 }
 },
 "id": request_id
 }
else:
 # Standard Agents accept simple JSON
 payload = {"prompt": message}

# Invoke the agent
response = self.client.invoke_agent_runtime(
 agentRuntimeArn=agent_arn,
 runtimeSessionId=session_id, # Maintains conversation state
 payload=json.dumps(payload),
 qualifier="DEFAULT"
)

This dual-mode support allows the platform to handle both simple standalone bots and complex, interconnected agent swarms.

5. Developer Experience: Python, uv, and Automation

Managing dependencies in modern Python projects can be complex. One thing I added from the original repo is utilizing uv, an extremely fast Python package installer and resolver.

We leverages uv to ensure reproducible builds. We’ve also automated the entire bootstrapping process with scripts/setup_aws_resources.py, which handles:

Detecting AWS Account/Region.
Creating IAM Roles and ECR Repositories.
Building and pushing Docker images.
Generating the local .env configuration.

6. Getting Started

If you have the repository cloned, setting up your own Agent Factory is straightforward using uv:

1. Configure Credentials

1
2
3
4
5


cd agent-factory
pip install uv
uv --version # check uv is installed
uv init # initializing uv project and adding dependencies
aws configure

2. Initialize Environment

1

uv sync

3. Provision Infrastructure

1

uv run scripts/setup_aws_resources.py

This script acts as your bootstrap “Infrastructure as Code”. It uses boto3 to:

Detect your AWS Account ID and Region.
Check for and create missing IAM Roles.
Create the reinvent/agents ECR repository.
Authenticate Docker with ECR.
Build and push the necessary Docker images.
Generate a local .env file for your client configuration. (do not forget to add it to .gitignore :))

4. Deploy Builder & Run CLI

1
2


uv run scripts/deploy_builder.py
uv run demo_cli.py

You can now chat with the Builder Agent and ask it to create new bots for you!

Securing Agentic AI for Financial Institutions (AWS re:Invent 2025)

Yoonsoo Park — Wed, 17 Dec 2025 00:00:00 +0000

For a bank, an AI agent isn’t just a chatbot; it’s a potential attack vector. If “Agent A” (Customer Support) calls “Agent B” (Transaction Handler), how do we trust that call?

We implement a Zero Trust Mesh using AgentCore Identity.

1. Identity Propagation

In a monolithic app, you check the user’s ID once at the front door. In a multi-agent mesh, that ID must travel with every hop.

The Solution: AgentCore automatically propagates the X-Amzn-Bedrock-AgentCore-Runtime-Session-Id and the User’s OIDC token.

Hop 1: User -> Support Agent (Auth: User JWT)
Hop 2: Support Agent -> Transaction Agent (Auth: User JWT + Agent SigV4)

This allows the Transaction Agent to enforce Row-Level Security (RLS). It knows that even though the “Support Agent” is calling, the actual user is “Alice,” so it only returns Alice’s data.

2. Inbound Auth: AWS SigV4

Every agent-to-agent call is signed using AWS Signature Version 4 (SigV4). This provides cryptographic proof of the caller’s identity (the AWS IAM Role of the calling agent).

sequenceDiagram
participant User
participant AgentA as Support Agent
participant AgentB as Bank DB Agent
User->>AgentA: "Check my balance"
Note right of User: Auth: OAuth Token (Alice)
AgentA->>AgentB: Request Balance
Note right of AgentA: Auth Header 1: SigV4 (Agent A Role)<br/>Auth Header 2: OAuth (Alice)
AgentB->>AgentB: Verify SigV4 (Is this really Agent A?)
AgentB->>AgentB: Verify OAuth (Is Alice allowed?)
AgentB-->>AgentA: $5,000

3. Network Isolation (PrivateLink)

For financial compliance (SOC2, PCI-DSS), traffic must never traverse the public internet.

AgentCore Runtime supports AWS PrivateLink. The entire mesh—Agents, Gateway, and Memory—runs inside your Virtual Private Cloud (VPC).

Conclusion

Security cannot be an afterthought. By utilizing Identity Propagation and PrivateLink, financial institutions can deploy autonomous agents that are as secure as their existing microservices.

Building Responsible AI with Amazon Bedrock (AWS re:Invent 2025)

Yoonsoo Park — Tue, 16 Dec 2025 00:00:00 +0000

The biggest barrier to Enterprise AI adoption is trust. “How do I know the bot won’t promise a refund we can’t give?”

Standard “Prompt Engineering” (e.g., “Please don’t lie”) is probabilistic and fails. Amazon Bedrock Guardrails introduces a deterministic layer: Automated Reasoning.

The Hybrid Approach

This system combines two types of AI:

Neural (The Translator): Reads your policy (“Refunds < 30 days only”) and converts it to math.
Symbolic (The Judge): Uses a logic solver to mathematically prove if the model’s answer violates the rule.

This gives you 100% precision on policy enforcement, unlike the statistical guess of an LLM.

Implementation: The `apply_guardrail` API

You decouple generation from validation. The Guardrail acts as a firewall after the model output but before the user sees it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


import boto3

bedrock_runtime = boto3.client('bedrock-runtime', region_name='us-east-1')

def check_safety(model_response):
 response = bedrock_runtime.apply_guardrail(
 guardrailIdentifier='GUARDRAIL_ID',
 guardrailVersion='DRAFT',
 source='OUTPUT',
 content=[{
 'text': {
 'text': model_response,
 'qualifiers': ['guard_content']
 }
 }]
 )

 action = response['action']

 if action == 'GUARDRAIL_INTERVENED':
 print("VIOLATION: The response was blocked by policy.")
 return False

 return True

The 5 Layers of Protection

Guardrails aren’t just for “toxicity.” They cover:

Denied Topics: “Do not give financial advice.”
Content Filters: Hate speech, violence.
Word Filters: Competitor names, profanity.
Sensitive Information: Auto-redact PII (SSN, Email).
Automated Reasoning: Logical business rule violations.

Conclusion

By moving safety checks out of the prompt and into the infrastructure, you gain explainability. When a response is blocked, the API tells you exactly which policy line was violated, enabling auditing for compliance teams.

AgentCore Overview (AWS re:Invent 2025)

Yoonsoo Park — Mon, 15 Dec 2025 00:00:00 +0000

AWS Bedrock AgentCore is the “Infrastructure-as-Code” layer for AI agents. It wraps your raw python code with enterprise-grade security and scaling, effectively moving AI Agents from “Laptop Experiments” to “Enterprise Production”.

This guide summarizes the key components: Runtime, Identity, Gateway, Memory, and Observability.

1. Introduction: The Shift to Agentic AI

We are moving from simple Generative AI (which just creates text or images) to Agentic AI. Unlike a chatbot that just talks, an Agent can plan, use tools, and complete complex jobs without human help.

However, enterprise agents face difficult challenges:

Scaling: Handling thousands of users at once.
Security: Keeping data safe and private.
Duration: Running tasks that take hours (standard cloud functions often time out after 15 minutes).

AWS Bedrock AgentCore solves this by providing a set of tools that “wraps” your agent code to automatically handle servers, security, and memory.

2. Agent Runtime (Serverless Hosting)

The Runtime is the environment where your agent lives. It solves the “infrastructure” problem. You don’t need to manage servers; AWS scales it for you. You can turn a local python script into a production service with just a few lines of configuration.

How to Implement It

Step 1: Import the Toolkit

1

from bedrock_agentcore_starter_toolkit import Runtime

Step 2: Configure the Runtime

This single block of code sets up the entire infrastructure.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


response = agentcore_runtime.configure(
 entrypoint="app.py", # Where your agent code starts
 auto_create_execution_role=True, # Automatically sets up permission security
 auto_create_ecr=True, # Automatically creates storage for your code
 authorizer_configuration={ # Sets up the security login system
 "customJWTAuthorizer": {
 "discoveryUrl": discovery_url,
 "allowedClients": [client_id]
 }
 }
)

3. Identity & Security

Security is handled in two ways: Inbound (who is talking to the agent?) and Outbound (how does the agent talk to other APIs?).

The system prevents strangers from using your agent via JWT Tokens (digital ID cards). If you try to run the agent without a token, it blocks you with AccessDeniedException. You must log in to get a “Bearer Token” first.

1
2
3
4
5
6


bearer_token = reauthenticate_user(client_id, pool_id)
# Now the call succeeds because we have the ID card
invoke_response = agentcore_runtime.invoke(
 {"prompt": "what is 4 + 4?"},
 bearer_token=bearer_token
)

B. Outbound Security (API Keys)

You should never save passwords (like OpenAI API keys) directly in your code. Agent Core uses a Credential Provider to fetch them safely.

Step 1: Create the Provider

1
2
3
4


api_key_provider = identity_client.create_api_key_credential_provider({
 "name": "openai-apikey-provider",
 "apiKey": api_key
})

Step 2: Use the Decorator This tells AWS: “Only get the password when this specific function runs.”

1
2
3
4
5
6
7


@requires_api_key(
 provider_name="openai-apikey-provider"
)
async def need_api_key(*, api_key: str):
 # The key is injected safely here
 global OPENAI_API_KEY_FROM_CREDS_PROVIDER
 OPENAI_API_KEY_FROM_CREDS_PROVIDER = api_key

4. AgentCore Gateway: Managing Tools

If you have 300 tools (e.g., “Check Inventory,” “Reset Password”), sending them all to an AI model is expensive and confusing. The Gateway acts as a smart librarian using Semantic Search to find the top relevant tools for the user’s specific question.

How to Implement It

Step 1: Create a Flexible Tool (Lambda)

You can write one AWS Lambda function that handles multiple jobs.

1
2
3
4
5
6


def lambda_handler(event, context):
 # The Gateway tells us which tool the agent wanted
 toolName = context.client_context.custom['bedrockAgentCoreToolName']

 if toolName == 'get_order_tool':
 # run get order logic...

Step 2: Register the Tool with MCP

MCP (Model Context Protocol) is a standard way to describe tools.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


lambda_target_config = {
 "mcp": {
 "lambda": {
 "lambdaArn": lambda_arn,
 "toolsSchema": {
 "name": "get_order_tool",
 "description": "Tool to get the order"
 }
 }
 }
}

5. AgentCore Memory: The Brain

Standard agents have “amnesia”. Agent Core gives them persistent memory with two strategies:

Synchronous: Saves immediate chat messages instantly.
Asynchronous: A background process scans the chat to extract Long-Term Memories (like user preferences) without slowing down the conversation.

How to Implement It

Step 1: The “Hook” (Automatic Saving)

Use a Hook to automatically load history when the agent starts and save new messages regarding user preferences.

1
2
3
4


class MemoryHookProvider(HookProvider):
 def on_agent_initialized(self, event):
 # Automatically loads the last 5 messages
 recent_turns = self.memory_client.get_last_k_turns()

Step 2: Retrieve and Use

When the agent starts, it can proactively ask the memory.

1
2
3
4


food_preferences = self.client.retrieve_memories(
 query="food preferences",
 top_k=3
)

Result: The agent might find memories like “User explicitly mentioned enjoying Italian cuisine”.

6. AgentCore Browser: The Eyes

Letting an AI browse the open internet is dangerous. Agent Core provides a Serverless Browser that runs in a secure, isolated virtual machine.

The Workflow:

Command: Agent says “Click the button at X:286, Y:102”.
Action: The cloud browser clicks it.
Result: The browser sends a screenshot back to the agent.

How to Implement It

It is extremely simple to add. You just import the browser tool and give it to the agent.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


from strands_tools.browser import AgentCoreBrowser

# Create the browser tool
agent_core_browser = AgentCoreBrowser(region=self.region)

# Add it to the agent's toolbox
self.agent = Agent(
 tools=[agent_core_browser.browser],
 model="anthropic.claude-3-haiku",
 system_prompt="You are an intelligent web analyst..."
)

7. AgentCore Code Interpreter: The Calculator

LLMs are often bad at math or complex data analysis. The Code Interpreter allows the agent to write code (Python/JS) and run it in a secure sandbox to get the right answer and minimize hallucinations.

The Principles:

When making claims about code or calculations - write code to verify them.
Use execute_python to test mathematical logic.

The Execution: The agent can generate Python code dynamically (e.g., to find prime numbers), run it in the sandbox, and use the proven data to answer the user.

1
2
3
4


# The agent wrote this code dynamically:
def is_prime(n):
 if n < 2: return False
 # ... logic ...

8. AgentCore Observability: Visibility & Debugging

When an agent fails, it is difficult to know if the error happened in the Prompt, the Tool, the Memory, or the LLM. Agent Core provides a comprehensive observability stack built on OpenTelemetry (OTEL) and AWS CloudWatch.

A. Architecture

The framework captures data (traces and logs) from:

Agent Deployed on Runtime
Agent Memory
Tools from Gateway

B. Implementation Steps

Step 1: Add Dependencies

Include aws-opentelemetry-distro in your requirements.txt.

1
2
3
4


strands-agents
bedrock-agentcore
aws-opentelemetry-distro # Required for tracing
opentelemetry-instrumentation

Step 2: Instrument the Container

Wrap the launch command in your Dockerfile.

1
2
3


ENV DOCKER_CONTAINER=1
# Use the full module path with auto-instrumentation
CMD ["opentelemetry-instrument", "python", "-m", "observability_demo_agent"]

Step 3: Console Configuration

In AWS CloudWatch settings, enable:

X-Ray Traces: visual map of requests.
Transaction Search: search logs for specific user actions.

C. Validation

Once deployed, you get access to visual dashboards showing high-level metrics like Sessions & Traces and Token Usage (cost tracking).

Summary

AWS Bedrock Agent Core is not just one tool, but a complete ecosystem for enterprise AI:

Runtime: Makes deployment easy.
Identity: Handles security/login.
Gateway: Manages hundreds of tools intelligently.
Memory: Gives the agent a long-term brain.
Browser & Interpreter: Gives the agent safe eyes and logic capabilities.

Real-Time Voice Agents with AWS Nova Sonic (AWS re:Invent 2025)

Yoonsoo Park — Sun, 14 Dec 2025 00:00:00 +0000

Building a real-time voice agent is hard because of Latency. If the user says “Hello,” and the bot takes 3 seconds to convert Speech-to-Text (STT), then LLM, then Text-to-Speech (TTS), the conversation feels dead.

Amazon Nova Sonic acts as a unified multimodal model that handles audio-in/audio-out in a single stream, cutting latency dramatically.

Architecture: The WebSocket Stream

Unlike a REST API, Nova Sonic requires a persistent connection.

For example, we can build a simple bot using Nova Sonic.

Client (React): Captures microphone audio.
Server (FastAPI): Proxies the stream to Bedrock via HTTP/2.
Model (Nova Sonic): Consumes audio chunks and streams back audio chunks.

The Event Sequence (Speculative Decoding)

To make it feel even faster, Nova Sonic sends text before the audio is fully ready.

User Splits: “What is the weather?”
Speculative Transcript: Server sends generationStage: "SPECULATIVE" text. The UI shows this immediately.
Audio Output: The actual sound bytes arrive.
Final Transcript: The official log.

Handling “Barge-In” (Interruptions)

If the user interrupts the bot (“No, wait—”), Nova Sonic detects this and sends {"interrupted": true}. Critical Implementation Detail: Your client MUST immediately clear its audio buffer when this flag is received.

Defining Tools for Voice

Nova Sonic can call tools just like a text agent.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


"toolConfiguration": {
 "tools": [
 {
 "toolSpec": {
 "name": "get_weather",
 "description": "Get weather for a location",
 "inputSchema": {
 "json": {
 "type": "object",
 "properties": {
 "city": { "type": "string" }
 },
 "required": ["city"]
 }
 }
 }
 }
 ]
}

RAG Integration (Knowledge Base)

You can wrap a Bedrock Knowledge Base query inside a Python function tool.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


def retrieve_kb(query):
 # Call Bedrock Agent Runtime
 response = bedrock_runtime.retrieve(
 knowledgeBaseId=KB_ID,
 retrievalQuery={'text': query},
 retrievalConfiguration={
 'vectorSearchConfiguration': {'numberOfResults': 1}
 }
 )
 return response['retrievalResults'][0]['content']['text']

Strands Integration: The “Brain” Pattern

For complex reasoning (e.g., “Plan a travel itinerary and check budget”), Nova Sonic might struggle. The pattern is to use Nova Sonic as the Router and Strands as the Brain.

Nova Sonic hears the complex request.
It calls a “Meta-Tool” named externalAgent.
The Strands Agent (running Claude 3.5 Sonnet) performs the logic.
The text result is returned to Nova Sonic to speak.

Conclusion: Use Nova Sonic for speed (simple Q&A). Offload to Strands for deep reasoning.

references:

Nova Sonic Documentation

Implementing Multi-Tenancy with AgentCore (AWS re:Invent 2025)

Yoonsoo Park — Sat, 13 Dec 2025 00:00:00 +0000

In a multi-tenant Agent SaaS, sharing the “Brain” (Runtime) saves money, but sharing the “Memory” (Database) risks a massive data breach.

This guide implements the Pool Pattern: A shared runtime with logical isolation enforced by Tenant Context.

The Architecture: Pool Pattern

Every request flows through a chain of validation, carrying a TenantID.

graph TD
subgraph "Shared Infrastructure"
Proxy[Seller App] -->|Inject TenantID| Runtime[Pooled Runtime]
Runtime -->|A2A Call| Gateway[Pooled Gateway]
Gateway -->|Intercept & Check| Registry[Policy Registry]
Registry -->|Allow/Deny| Gateway
Gateway -->|Execute| Tool[Tool / API]
end

1. Tool Access Control (Gateway Interceptors)

You can’t trust the LLM to “not use” a tool. You must block it at the network layer.

The Policy Registry returns a JSON policy that the Gateway enforces.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
 "policyId": "POL-TENANT-A",
 "tenantId": "Tenant-A",
 "rules": [
 {
 "effect": "ALLOW",
 "resourceType": "TOOL",
 "resources": ["agent:tool:order-lookup"]
 },
 {
 "effect": "DENY",
 "resourceType": "TOOL",
 "resources": ["agent:tool:admin-refund"],
 "reason": "Insufficient privileges"
 }
 ]
}

2. Memory Isolation (IAM Trust Policy)

AgentCore Memory requires AWS IAM credentials, not JWTs. The Runtime performs a Token Exchange, swapping the user’s JWT for a temporary IAM Role tagged with the TenantID.

You enforce isolation using Attribute-Based Access Control (ABAC) in your IAM Policy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "EnforceTenantIsolation",
 "Effect": "Allow",
 "Action": ["bedrock:Retrieve"],
 "Resource": "arn:aws:bedrock:knowledge-base/*",
 "Condition": {
 "StringEquals": {
 // The Principal (Agent) Tag MUST match the Resource (Data) Tag
 "aws:ResourceTag/TenantID": "${aws:PrincipalTag/TenantID}"
 }
 }
 }
 ]
}

3. Identity: Act-on-Behalf

Never use “Impersonation” (pretending the Agent is the User). Use Act-on-Behalf (The Agent acts for the User).

Principal: Agent Service
Subject: User Alice
Scope: Read-Only

Implementation Checklist

Registry: Build a DynamoDB table mapping User -> Tenant -> Policy.
Interceptor: Create a Lambda function for the Gateway to check the Registry.
STS Exchange: Configure Runtime to AssumeRole with TenantID tags.
Zero Trust: Ensure TenantID is propagated in every A2A call header.

Designing Robust Multi-Agent Systems (AWS re:Invent 2025)

Yoonsoo Park — Fri, 12 Dec 2025 00:00:00 +0000

Moving from a single agent to a multi-agent system is not just about adding more bots. It’s about structure.

This guide details the four canonical architectures for multi-agent systems and introduces the advanced ReWOO pattern for optimization.

1. Hierarchical (The “Boss and Workers”)

This is the standard for complex business workflows. A Supervisor delelgates tasks to specialized workers.

Best For: Context Hiding. The Supervisor never sees the raw “junk” data (like HTML scraping) from the worker, keeping its memory clean.

graph TD
Supervisor((🧠 Supervisor))
Supervisor -->|Delegates| ManagerA[Manager A]
Supervisor -->|Delegates| ManagerB[Manager B]
ManagerA -->|Task| Worker1[Worker 1]
ManagerA -->|Task| Worker2[Worker 2]

The “Context Hiding” Pattern

One of the biggest advantages of this hierarchy is memory management.

sequenceDiagram
participant Supervisor
participant Researcher as Research Agent
participant Web as Web Tools
Note over Supervisor: Clean Memory
Supervisor->>Researcher: "Find details on Product X"
rect rgb(240, 248, 255)
Note right of Researcher: Dirty Work
Researcher->>Web: Scrape HTML (100k tokens)
Web-->>Researcher: Raw Data
Researcher->>Researcher: Summarize
end
Researcher-->>Supervisor: "It costs $50."
Note over Supervisor: Supervisor never saw the HTML

2. Multi-Agent DAG (The Assembly Line)

A Directed Acyclic Graph (DAG) is a fixed chain.

Best For: Predictable pipelines like document processing.

graph LR
Step1((Step 1)) --> Step2((Step 2)) --> Step3((Step 3)) --> Finish[Done]

3. ReWOO: Reasoning Without Observation

ReWOO decouples the “Planning” from the “Doing.” This reduces token usage and latency.

Planner: Generates a full plan with placeholders (#E1, #E2).
Worker: Executes tools in parallel to fill placeholders.
Solver: Synthesizes the final answer.

graph TD
subgraph "Phase 1: Planning"
Planner[📝 Planner] -->|Plan| Plan[Plan: #E1, #E2]
end
subgraph "Phase 2: Execution"
Plan --> Worker[👷 Worker]
Worker -->|Parallel Tool Call| ToolA[Output #E1]
Worker -->|Parallel Tool Call| ToolB[Output #E2]
end
subgraph "Phase 3: Synthesis"
ToolA --> Solver[🧩 Solver]
ToolB --> Solver
Solver --> Final[Answer]
end

Decision Document: Hierarchical vs. DAG

Feature	Hierarchical	DAG
Flexibility	High (Can change plan mid-flight)	Low (Hardcoded path)
Latency	Higher (Supervisor “thinking” time)	Lower (Immediate routing)
Use Case	Customer Support, Research	Onboarding, Claims Processing

Conclusion: Start with Hierarchical for most “Assistant” type apps. Use DAGs for backend automation.

Architecture Patterns for Strands and MCP (AWS re:Invent 2025)

Yoonsoo Park — Thu, 11 Dec 2025 00:00:00 +0000

In the “Agentic Era,” software architecture is defined by three components:

Strands: The Brain (Orchestration).
MCP: The Hands (Vertical Integration).
A2A: The Voice (Horizontal Collaboration).

This guide explains when to use which protocol and how to implement them.

The Mental Model: MCP vs. A2A

The most common question is: “Why do we need two protocols?”

Feature	MCP (Model Context Protocol)	A2A (Agent-to-Agent)
Direction	Vertical (Agent $\to$ Data)	Horizontal (Agent $\leftrightarrow$ Agent)
Relationship	Master/Slave	Peer-to-Peer
Transport	JSON-RPC (Local/SSE)	JSON-RPC 2.0 (HTTP/Cloud 9000)
State	Stateless	Stateful (Tasks)
Best For	Database access, API calls	Delegation, Negotiation

The Rule of Thumb: Use MCP for deterministic tools (reading a file). Use A2A for probabilistic work (asking another agent to “review this plan”).

Implementation: The Matryoshka Pattern

A production agent is often a “Strands Agent” wrapped in an “A2A Server,” consuming “MCP Clients.”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 1. Define the Core Agent (Strands)
from strands import Agent
from strands_tools.calculator import calculator

strands_agent = Agent(
 model="anthropic.claude-3-5-sonnet-v2:0",
 tools=[calculator] # MCP Tools
)

# 2. Wrap in A2A Server (Horizontal)
from strands.multiagent.a2a import A2AServer

a2a_server = A2AServer(
 agent=strands_agent,
 name="Finance Agent",
 port=9000
)

# 3. Serve
a2a_server.serve()

Discovery: The Agent Card

A2A agents don’t use hardcoded IP addresses. They use Semantic Discovery. Every agent publishes an agent-card.json.

1
2
3
4
5
6
7
8
9


{
 "name": "TravelAgent",
 "description": "I can book flights and hotels.",
 "capabilities": ["book_flight", "check_visa"],
 "auth": {
 "type": "oauth2",
 "scopes": ["travel:write"]
 }
}

When a user asks “I need a flight,” the Orchestrator scans the network for agents with “travel” capabilities, reads their cards, and routes the task dynamically.

Security: Zero Trust Mesh

In a multi-agent system, we use Identity Propagation.

When Agent A calls Agent B, it passes the original user’s specific context (e.g., User: Alice). This ensures that even if Agent B has admin access to a database, it enforces permissions as if Alice were querying it directly.

Conclusion

Stop building monolithic agents. Build a Composable Cognitive Enterprise by using MCP for your data layer and A2A for your collaboration layer.

References:

Model Context Protocol

Agent Factory - Scaling AI Employee Creation (AWS re:Invent 2025)

Yoonsoo Park — Wed, 10 Dec 2025 00:00:00 +0000

Building a single AI agent is easy. Building 100 secure, production-grade agents is an operations nightmare.

The AWS Agent Factory solves this by treating agents as manufactured goods. You don’t hand-code every file; you use a Builder Agent to generate the code, infrastructure, and deployment artifacts for you.

The Factory Architecture

The factory relies on Strands, a model-driven SDK, to dynamically generate Python code for new agents.

graph TD
subgraph "Local / Builder Environment"
User[User Request] --> Builder[Builder Agent]
Builder -- "Writes Code" --> ToolFile[tools/risk_tool.py]
Builder -- "Hot Loads" --> LocalRuntime[Local Test Runtime]
end
subgraph "AWS Production"
Builder -- "Deploys" --> Cloud[Agent Core Runtime]
Cloud --> S3[S3 Artifacts]
Cloud --> IAM[IAM Roles]
end

Step 1: Meta-Tooling (Agents Writing Agents)

The Builder Agent isn’t just a chatbot. It uses the Strands SDK to write actual python code.

For example, if you ask for a “Stock Analyzer,” the Builder Agent generates a new file tools/stock_tool.py using the @add_tool decorator.

1
2
3
4
5
6
7
8


# Generated by Builder Agent
from strands import tool

@tool
def analyze_stock(ticker: str) -> dict:
 """Gets stock data for a given ticker."""
 # ... logic ...
 return {"price": 100, "rating": "BUY"}

The system watches the tools/ directory. When this file appears, it Hot Loads the new capability instantly.

Step 2: Implementation Details

You can customize the underlying model for your agents using BedrockModel.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


from strands.model import BedrockModel
from strands import Agent

# Switch to a faster model for the worker agent
fast_model = BedrockModel(
 model_id="anthropic.claude-3-haiku-20240307-v1:0",
 temperature=0.0
)

worker_agent = Agent(
 model=fast_model,
 tools=[analyze_stock],
 system_prompt="You are a financial analyst..."
)

Step 3: Production Deployment

Once the agent is tested locally, the Factory automates the move to the cloud. It replaces manual Terraform/CDK writing with a single CLI command.

1
2
3
4
5


# Configure AWS resources (S3, ECR, IAM)
agent-core configure

# Run the Builder to deploy the specific agent
python builder_agent.py --deploy

This command:

Containerizes the agent code.
Creates an IAM Execution Role with least-privilege permissions.
Uploads the artifact to Amazon S3.
Updates the Agent Core Gateway.

Conclusion

The Agent Factory shifts the paradigm from “crafting pets” to “manufacturing cattle.” By automating the boilerplate of IAM, S3, and standard tool definitions, you can spin up a dedicated agent for every micro-task in your enterprise.

References:

Agent Factory Repository

Deep Dive into AgentCore Memory Architecture (AWS re:Invent 2025)

Yoonsoo Park — Tue, 09 Dec 2025 00:00:00 +0000

Standard LLM applications suffer from “Party Amnesia.” You have a great conversation, close the window, and 5 minutes later the agent asks, “Who are you?”

AWS AgentCore Memory solves this by moving context out of the ephemeral session and into a persistent, managed layer. This article details the technical architecture of how that works.

The Architecture: Context Orchestrator

The “Context Orchestrator” is the brain that assembles the prompt before the LLM ever sees it. It combines Authoritative Context (what is factually true) with Conversational Context (what is personally relevant).

flowchart TD
UserQuery[User Query] --> Orchestrator[Context Orchestrator]
subgraph Authoritative["What is True?"]
KB[Knowledge Bases]
API[Real-time API Data]
end
subgraph Conversational["What is Personal?"]
STM[Short-term Memory]
LTM[Long-Term Memory]
end
Orchestrator --> AuthContext[Merge Context]
Authoritative --> AuthContext
Conversational --> AuthContext
AuthContext --> LLM[LLM Reasoning]

Short-Term vs. Long-Term Memory

AgentCore splits memory into two distinct pipelines to balance speed and retention.

Short-Term Memory (STM): Synchronous. Stores raw events (User said X, Agent said Y). Accessible immediately.
Long-Term Memory (LTM): Asynchronous. A background process extracts “Insights” and “Summaries” from the STM and stores them in a Vector Store.

flowchart LR
Raw["Raw Chat Events"] -->|Sync| STM["Short Term Memory"]
STM -->|Async Trigger| Extractor[["Memory Extraction/Consolidation"]]
Extractor -->|Write| Vector["Long Term Vector Store"]

Implementation: Memory Strategies

You configure “Strategies” to tell the agent what to remember.

Summary: Condenses the last N messages.
User Preference: Detects and saves likes/dislikes (e.g., “I hate spicy food”).
Semantic: Saves factual statements (e.g., “My user ID is 12345”).

Configuring Strategies (JSON)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
 "strategies": [
 {
 "type": "USER_PREFERENCE",
 "configuration": {
 "topic": "food_preferences",
 "retention_period": 90 // Days
 }
 },
 {
 "type": "SUMMARY",
 "configuration": {
 "max_tokens": 500
 }
 }
 ]
}

The Hook System

For enterprise control, you don’t always want to rely on the LLM to decide when to save. You can use Memory Hooks to force deterministic behavior.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


class MyMemoryHook(MemoryHook):
 def on_message_added(self, event):
 """
 Triggered every time a message is added to the session.
 """
 current_message = event.message.content

 # Deterministic check: If user mentions 'budget', save it explicitly
 if "budget" in current_message.lower():
 self.memory_client.save_insight(
 insight={
 "key": "project_budget",
 "value": extract_budget(current_message),
 "confidence": 1.0
 }
 )

Security and Isolation

AgentCore enforces strict isolation. Data is encrypted at rest and in transit.

Namespace Isolation: Every user’s memory is stored in a separate logical namespace (e.g., user/alice/preferences).
Cross-Agent Interoperability: If configured, the “Sales Agent” can read the user/alice namespace populated by the “Support Agent,” creating a unified customer view.

Conclusion

By decoupling memory from the runtime, AgentCore allows you to build agents that “grow up” with your users, remembering details over months instead of minutes.

References:

AWS Bedrock AgentCore Memory Documentation

Building Long-Running Agents with AgentCore (AWS re:Invent 2025)

Yoonsoo Park — Mon, 08 Dec 2025 00:00:00 +0000

Most AI demos fail in the real world for two reasons: Amnesia and Timeouts.

A standard Lambda function dies after 15 minutes. A standard chat bot forgets context when the session ends. But enterprise workflows—like investigating financial fraud or onboarding a new employee—take days, not minutes.

AWS Bedrock AgentCore is the answer. It provides a managed runtime that supports 8-hour sessions and persistent memory. This guide breaks down the architecture and shows you how to build it.

The Architecture: Supervisor and Workers

We don’t build one giant agent. We build a system.

Imagine that each session manager(agent) in the diagram has a role below:

Supervisor: The “Boss.” It takes the user request (“Investigate TechCorp”) and delegates work.
Retrieval Agent: The “Researcher.” It checks internal databases.
Compliance Agent: The “Lawyer.” It waits for bank data (which might take 3 days) and then files a report.

The Session Lifecycle

Unlike a standard container that spins down immediately, an AgentCore session has a state machine designed for the long running process (up to 8 hours).

stateDiagram-v2
[*] --> SessionActive: Start Request
state SessionActive {
[*] --> SyncRequests
SyncRequests --> AsyncPings: Background Work
}
SessionActive --> SessionIdle: Response Ends / No Pings
state SessionIdle {
[*] --> Waiting
}
SessionIdle --> SessionTerminated: 15 Mins Inactivity
SessionActive --> MaxSessionDuration: 8 Hours Limit Reached
MaxSessionDuration --> SessionTerminated

Active: The agent is processing or waiting for a tool.
Idle: The agent goes to sleep to save money but keeps its state.
Terminated: after 15 minutes of silence (configurable) or 8 hours total.

Configuration Guide

To deploy this, you package your agent code (Python/LangChain) into a Docker container and push it to ECR. Then, you configure the AgentCore Runtime.

1. Dockerfile Setup

Wrap your agent with the bedrock-agentcore-runtime base image.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


FROM public.ecr.aws/bedrock-agentcore/runtime:latest

# Install dependencies
COPY requirements.txt .
RUN pip install -r requirements.txt

# Copy your agent code
COPY src/ .

# The entrypoint is handled by the base image, 
# just ensure your agent exposes the standard interface.

2. Runtime Configuration (Python SDK)

Use the bedrock_agentcore_starter_toolkit to configure the runtime in your app.py.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


from bedrock_agentcore_starter_toolkit import Runtime

def create_app():
 # Define the runtime config
 config = {
 "max_session_duration_seconds": 28800, # 8 Hours
 "idle_timeout_seconds": 900 # 15 Minutes
 }

 # Initialize runtime
 runtime = Runtime(config=config)
 return runtime.start()

if __name__ == "__main__":
 create_app()

Persistent Memory

The “magic” that allows an agent to wake up after 3 days and remember “Day 0” is AgentCore Memory.

It automatically separates storage:

Short Term: Raw chat logs and events (access restricted to the specific actorId).
Long Term: Summarized insights (stored in namespaced “folders”).

flowchart LR
Events["Incoming Events"] -->|Sync Write| STM["Short Term Memory"]
STM -->|Async Read| Extractor[["Automatic Extraction"]] -->|Async Write| LTM["Long Term Memory"]

Security Best Practice

Use Conditional Keys in your IAM policies to ensure Tenant A never reads Tenant B’s memory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": ["bedrock:Retrieve"],
 "Resource": "*",
 "Condition": {
 "StringEquals": {
 "bedrock-agentcore:actorId": "${aws:PrincipalTag/TenantID}"
 }
 }
 }
 ]
}

Conclusion

AgentCore allows you to move from “Prompt Engineering” to “System Engineering.” By handling the infrastructure of long-running sessions and state management, you can focus on the business logic of your agents.

References:

AWS Bedrock AgentCore Documentation

Deploy n8n on AWS Step by Step

Yoonsoo Park — Wed, 20 Aug 2025 00:00:00 +0000

Deploying n8n for personal automation is often as simple as running a Docker container on a VPS. However, when deploying n8n for enterprise use—where reliability, security, and scalability are non-negotiable—a robust cloud architecture is required. The official doc suggests to use EKS with K8s but if you are looking for a more cost-effective solution, you can use ECS Fargate. (plus you also want to avoid the complexity of managing a Kubernetes cluster)

In this article, we will explore how to deploy n8n on AWS using the AWS Cloud Development Kit (CDK). We will replicate a proven architecture that utilizes ECS Fargate, Aurora Serverless, and a unique Dual Load Balancer strategy to separate administrative traffic from high-volume webhook events.

The Goal

By the end of this guide, you will understand how to deploy an n8n service that:

Scales horizontally using a worker-queue architecture.
Isolates traffic by separating the UI from webhook ingestion.
Manages state using Serverless PostgreSQL and Redis.
Automates deployment via a CI/CD pipeline with multi-environment support (QA/Prod).

1. The Architecture: Queue Mode on Fargate

To achieve high availability, we cannot run n8n as a monolithic instance. Instead, we use Queue Mode. This decouples the “Producer” (the main n8n instance handling webhooks and the UI) from the “Consumer” (Workers that execute the workflows).

The Compute Layer

Here is a high-level view of how the traffic and data flow through the system:

graph TD
subgraph Public ["Public Internet"]
User(("User / Admin"))
Webhook(("Third Party App"))
end
subgraph VPC ["AWS VPC"]
subgraph PublicSubnet ["Public Subnet"]
ALB_Main["Main ALB (UI/API)"]
ALB_Hook["Webhook ALB"]
end
subgraph PrivateSubnet ["Private Subnet (App & Data)"]
subgraph Fargate ["ECS Fargate"]
MainService["Main Service (UI)"]
WorkerService["Worker Service (Queue)"]
end
Redis[("ElastiCache Redis")]
Aurora[("Aurora Postgres V2")]
end
end
User -->|HTTPS| ALB_Main
Webhook -->|HTTPS| ALB_Hook
ALB_Main --> MainService
ALB_Hook --> MainService
MainService -->|Push Job| Redis
Redis -->|Pull Job| WorkerService
MainService -->|Read/Write| Aurora
WorkerService -->|Read/Write| Aurora

We utilize AWS ECS Fargate to run containerized tasks without managing servers.

Main Service: Handles the Web UI, API, and incoming Webhooks.
Worker Service: Dedicated solely to executing workflows.

In our configuration, we explicitly set the EXECUTIONS_MODE environment variable to queue. This ensures that when a workflow is triggered, the job is sent to Redis rather than being executed immediately on the web server, allowing the web server to remain responsive during heavy loads.

The Data Layer

State management is handled by two core components defined in our DataStack:

Database: We use Aurora PostgreSQL Serverless v2. This stores workflow definitions, execution history, and user data. It scales capacity units automatically based on demand.
```
engine: DatabaseClusterEngine.auroraPostgres({
version: AuroraPostgresEngineVersion.VER_15_4,
}),
```
Cache/Queue: We use Amazon ElastiCache for Redis. This acts as the message broker between the Main service and the Workers.

Note: Use Valkey if you need to cost effective solution rather than Redis.

2. The Networking Strategy: The Dual ALB Pattern

One of the most distinct features of this architecture is the use of two separate Application Load Balancers (ALBs). While both ALBs target the same ECS Service, they serve different purposes and domains:

Main ALB (n8n.your-domain.com): Serves the n8n Editor UI and authenticated API traffic. This is typically restricted by stricter security groups (e.g., VPN or Office IPs).

Webhook ALB (n8n-webhook.your-domain.com): Dedicated to receiving webhook triggers from external third-party services. This must be publicly accessible.

example

main and webhook alb are in the same vpc.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


const mainAlb = new ApplicationLoadBalancer(this, 'MainAlb', {
 vpc: this.vpc,
 internetFacing: true,
 securityGroups: [this.mainAlbSecurityGroup],
});

const webhookAlb = new ApplicationLoadBalancer(this, 'WebhookAlb', {
 vpc: this.vpc,
 internetFacing: true,
 securityGroups: [this.webhookAlbSecurityGroup],
});

Listeners & Certificates

We are using a Deny by Default strategy here.

You start with a listener that returns 404 for everything. This ensures that only traffic you explicitly configured (e.g., matching n8n.your-domain.com) is forwarded to your containers, while random IP scanners or mismatched requests simply get a generic 404 from the load balancer itself, saving your application resources!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


 // HTTPS Listeners
 const mainHttpsListener = this.mainBalancer.addListener('MainHttps', {
 port: 443,
 open: true,
 certificates: [certificate], // Certificate from ACM
 defaultAction: ListenerAction.fixedResponse(404, {
 contentType: 'text/plain',
 messageBody: 'No routes matched',
 }),
 });

 const webhookHttpsListener = this.webhookBalancer.addListener('WebhookHttps', {
 port: 443,
 open: true,
 certificates: [certificate],
 defaultAction: ListenerAction.fixedResponse(404, {
 contentType: 'text/plain',
 messageBody: 'No routes matched',
 }),
 });

 /*
 Later in your code (typically in the standard ECS Service definition), you call .addTargets() to explicitly attach your ECS Service to this listener.
 */

Why do this?

Security Isolation: You can lock down your Admin UI to internal IP ranges while keeping webhook endpoints open to the world.
Traffic Isolation: Webhook traffic is often bursty. Separating them prevents a flood of webhook events from degrading the performance of the Admin UI.
Fail-Safe Operation: If the Admin UI is undergoing maintenance, webhook ingestion can theoretically continue uninterrupted.

Solving the CORS Challenge

Because the UI and Webhooks live on different domains (e.g., n8n.yopa.cloud vs n8n-webhook.yopa.cloud), the n8n Editor needs to make Cross-Origin Resource Sharing (CORS) requests to test webhooks.

To support this, we configure the ALBs to inject specific CORS headers. We use a custom resource to modify listener attributes, adding headers like Access-Control-Allow-Origin and Access-Control-Allow-Credentials: true. This allows the UI domain to successfully communicate with the Webhook domain during workflow testing.

3. Infrastructure as Code: The CDK Stack

We organize our infrastructure into three primary stacks to manage dependencies and lifecycle:

A. Shared Stack

This stack handles the VPC lookup and foundational security groups. It ensures that our compute resources are placed in private subnets with egress access, while the load balancers sit in public subnets.

B. Data Stack

This initializes the Aurora Cluster and Redis Cluster. Crucially, it manages AWS Secrets Manager entries for the database credentials (DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD) and the n8n encryption key (N8N_ENCRYPTION_KEY). This ensures sensitive keys are never hardcoded in the application configuration.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


// src/stacks/data-stack.ts

// Database credentials
this.dbSecret = new Secret(this, 'PostgresSecret', {
 secretName: this.namingUtility.getFullName('postgres-credentials'),
 generateSecretString: {
 secretStringTemplate: JSON.stringify({ username: 'n8n' }),
 generateStringKey: 'password',
 excludePunctuation: true,
 },
 removalPolicy: this.props.removalPolicy,
});

// n8n Encryption Key (Critical for decrypting workflow credentials)
this.n8nEncryptionKey = new Secret(this, 'N8nEncryptionKey', {
 secretName: this.namingUtility.getFullName('n8n-encryption-key'),
 generateSecretString: {
 excludePunctuation: false,
 includeSpace: false,
 passwordLength: 32,
 },
 removalPolicy: this.props.removalPolicy,
});

C. Compute Stack

This stack defines the ECS Cluster, Task Definitions, and Services. It injects the necessary environment variables into the container environment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101


// src/stacks/compute-stack.ts

import { FargateService, FargateTaskDefinition, ContainerImage, EcsSecret, SubnetType } from 'aws-cdk-lib/aws-ecs';
import { ApplicationProtocol } from 'aws-cdk-lib/aws-elasticloadbalancingv2';
import { Duration } from 'aws-cdk-lib';

// ---------------------------------------------------------
// Shared Configuration
// ---------------------------------------------------------

const commonEnvironment = {
 // Database Configuration
 DB_TYPE: 'postgresdb',
 DB_POSTGRESDB_HOST: dbCluster.clusterEndpoint.hostname,
 DB_POSTGRESDB_PORT: dbCluster.clusterEndpoint.port.toString(),
 DB_POSTGRESDB_DATABASE: 'n8n',

 // Queue Configuration
 EXECUTIONS_MODE: 'queue',
 QUEUE_BULL_REDIS_HOST: redisCluster.attrRedisEndpointAddress,
 QUEUE_BULL_REDIS_PORT: redisCluster.attrRedisEndpointPort,

 // Security Hardening
 NODES_EXCLUDE: '["n8n-nodes-base.executeCommand", "n8n-nodes-base.readWriteFile"]',
 NODE_FUNCTION_ALLOW_BUILTIN: 'path,crypto,url,util,http,https,querystring',

 // Webhook & UI URLs
 N8N_EDITOR_BASE_URL: `https://${mainDomain}/`,
 WEBHOOK_URL: `https://${webhookDomain}/`,
};

const commonSecrets = {
 DB_POSTGRESDB_USER: EcsSecret.fromSecretsManager(dbSecret, 'username'),
 DB_POSTGRESDB_PASSWORD: EcsSecret.fromSecretsManager(dbSecret, 'password'),
 N8N_ENCRYPTION_KEY: EcsSecret.fromSecretsManager(n8nEncryptionKey),
};

// ---------------------------------------------------------
// 1. Main Service (UI & Webhooks)
// ---------------------------------------------------------

const mainTaskDefinition = new FargateTaskDefinition(this, 'MainTaskDefinition', {
 memoryLimitMiB: 2048, cpu: 1024, executionRole, taskRole,
});

mainTaskDefinition.addContainer('n8n-main', {
 // Use the latest n8n image but I recommend to use a specific version in the production environment
 image: ContainerImage.fromRegistry('n8nio/n8n:latest'),
 essential: true,
 environment: commonEnvironment,
 secrets: commonSecrets,
});

const mainService = new FargateService(this, 'MainService', {
 cluster,
 taskDefinition: mainTaskDefinition,
 desiredCount: 1, // High Availability typically handled here
 vpcSubnets: { subnetType: SubnetType.PRIVATE_WITH_EGRESS },
 securityGroups: [DEFINED_SECURITY_GROUPS],
 assignPublicIp: false,
});

// Register Main Service to ALBs
mainHttpsListener.addTargets('MainTarget', {
 port: 5678, protocol: ApplicationProtocol.HTTP, targets: [mainService],
 healthCheck: { path: '/healthz', interval: Duration.seconds(30) },
});

webhookHttpsListener.addTargets('WebhookTarget', {
 port: 5678, protocol: ApplicationProtocol.HTTP, targets: [mainService],
 healthCheck: { path: '/healthz', interval: Duration.seconds(30) },
});

// ---------------------------------------------------------
// 2. Worker Service (Workflow Execution)
// ---------------------------------------------------------

const workerTaskDefinition = new FargateTaskDefinition(this, 'WorkerTaskDefinition', {
 memoryLimitMiB: 2048, cpu: 1024, executionRole, taskRole,
});

workerTaskDefinition.addContainer('n8n-worker', {
 image: ContainerImage.fromRegistry('n8nio/n8n:latest'),
 command: ['n8n', 'worker'], // <--- CRITICAL: Runs purely as a worker
 essential: true,
 environment: commonEnvironment,
 secrets: commonSecrets,
});

const workerService = new FargateService(this, 'WorkerService', {
 cluster,
 taskDefinition: workerTaskDefinition,
 desiredCount: 2, // Scale workers based on load (CPU/Memory)
 vpcSubnets: { subnetType: SubnetType.PRIVATE_WITH_EGRESS },
 securityGroups: [DEFINED_SECURITY_GROUPS],
 assignPublicIp: false,
});

// Optional: Auto-scaling for Workers
const scalableWorker = workerService.autoScaleTaskCount({ minCapacity: 2, maxCapacity: 10 });
scalableWorker.scaleOnCpuUtilization('CpuScaling', { targetUtilizationPercent: 70 });

Note the security hardening: We explicitly exclude nodes that allow command execution or file system access to prevent abuse.

4. The Deployment Pipeline

To deploy this service securely, we utilize an Internal Pipeline built on AWS CodePipeline. This pipeline follows a “Blue/Green” deployment logic based on environment variables.

Environment Detection: The pipeline automatically detects the target region (e.g., us-east-1 or eu-central-1) based on the environment name pattern.
QA Deployment: Changes pushed to the release branch are automatically deployed to the QA environment.
Production Gate: Deployment to Production requires a manual approval step in the pipeline.

CI/CD Steps:

Source: The pipeline pulls code from the repository when changes are detected on the release branch.
Build: CodeBuild compiles the TypeScript CDK code and runs unit tests.
Synth & Deploy: The pipeline synthesizes the CloudFormation templates and deploys the stacks (Data, then Compute) using the specific context for the target environment (e.g., suffix=n8n-prod).

How to Deploy (Summary)

To replicate this setup:

Prerequisites: Ensure you have an AWS account, Node.js installed, and the AWS CLI configured.
Bootstrap: Initialize your CDK environment in your target region.
Configure Context: Set up your cdk.json to define your pipeline shape (environments and regions).
Deploy the Pipeline: Run the deployment command to create the CI/CD infrastructure: e.g. npm run aws:deploy:pipeline
Push to Release: Commit your application code and push to the release branch. The pipeline will pick up the changes, build the containers, and deploy the Data and Compute stacks to your QA environment automatically.

By following this architecture, you move away from a weak single-server instance to a scalable and secure automation platform capable of handling enterprise workloads.

Kiro IDE - The Smart Coding Tool That Plans Before It Builds

Yoonsoo Park — Tue, 22 Jul 2025 00:00:00 +0000

Kiro IDE is Amazon’s new AI coding assistant. It helps you plan your project before writing any code, instead of just generating code quickly. This makes it different from other AI coding tools.

Try Kiro IDE (Public Preview)

What Makes Kiro IDE Different?

Kiro IDE is Amazon’s new AI coding assistant that helps you plan before you code. Unlike other tools that just write code quickly, Kiro focuses on creating clear plans and requirements first.

Kiro IDE launched on July 14, 2025. It’s different from other coding tools because it makes you plan your project before writing any code. Think of it like building a house: most AI tools start building right away, but Kiro wants you to draw up blueprints first.

This method follows Amazon’s own way of building software—always planning before coding. Now, anyone can use this approach with Kiro IDE.

Two Ways to Work: Vibe Mode vs Spec Mode

Kiro gives you two different ways to work:

Vibe Mode - Ask questions, get code samples, or fix bugs through chat. It’s good for learning or trying new ideas.

Spec Mode - Kiro asks you detailed questions about your project before writing any code. Example questions:

What exactly do you want to build?
Who will use it?
What could go wrong?
How should it handle errors?

After you answer, it makes a full plan and then writes the code.

Real Example: Building a Review System

Let’s say you want to add reviews to your product website. Here’s how each mode works:

In Vibe Mode:

You: “Add reviews to products”
Kiro: immediately creates React components for reviews

In Spec Mode:

You: “Add reviews to products”
Kiro: “Let me understand this better. Should users be able to rate with stars? Edit their reviews? What happens with spam reviews?”
After you discuss these details, Kiro creates a complete plan with database designs, user stories, and security considerations
Only then does it write the actual code

The Magic Behind the Scenes

Kiro uses several AI agents:

Planning agents decide what needs to be built.
Code agents write the code.
Quality agents check for good practices.
Integration agents make sure everything works together.

Kiro is powered by Claude Sonnet 4.0, a strong AI model that handles complex projects well. (also you can use Claude 3.5 Sonnet)

Key Features That Make Developers Happy

Smart Project Organization: Keeps all your plans and documents organized in a special folder, .kiro.

Task Management: Breaks work into small tasks you can approve.

AWS Integration: Works with AWS—turn hand-drawn diagrams into real cloud code.

Automatic Documentation: Updates documentation automatically.

Background Helpers: Runs tests and checks code quality in the background.

Developers have mixed opinions:

Enterprise developers like it—they built complex systems quickly with full documentation and security. (I’m one of them)
Startup developers are split. Some like the planning, others find it slow for quick experiments.
Common complaints: repeats suggestions, can be too generic, uses lots of computer power, and sometimes slows down.

Compared to other AI Coding Tools (purely my opinion)

Cursor: Fast code writing and debugging, but messy for big projects.
GitHub Copilot: Great for code completion, but focuses on speed, not planning.
Windsurf: Used to be popular but lost users after business problems.
Kiro: The only tool that requires planning and creates organized code.

Current limits:

Language Support: Best with TypeScript, Python, and Java. Other languages work but not as well.

Learning Curve: Takes time to learn the planning approach but this is where it shines.

Performance Issues: Can be slow or limited during busy times.

Setup Challenges: Can get confused by complex development environments or unusual configurations.

.NET Problems: Doesn’t work well for C# developers due to missing Microsoft tools. (I’m not a C# developer so take this with a grain of salt)

Pricing and Availability

Right now, Kiro is free during the public preview, but there are daily limits on how much you can use it.

Amazon originally announced these prices:

Free: 50 interactions per month
Pro ($19/month): 1,000 interactions
Pro+ ($39/month): 3,000 interactions

But they removed these details due to user confusion about what counts as an “interaction.” New pricing should be announced soon.

The good news: you don’t need an AWS account to use Kiro. You can sign in with Google, GitHub, or AWS credentials.

Should You Try Kiro IDE?

Kiro is perfect if you:

Work on complex, long-term projects
Want to write maintainable code from the start
Like having detailed documentation
Work in a team that values planning (I am in this category)
Build enterprise or production systems

Stick with other tools if you:

Do lots of experimental coding
Need to prototype very quickly (go with Cursor)
Work mostly alone on small projects
Prefer maximum flexibility over structure

Wrapping it up 👏

I believe Kiro is best for people working on complex, long-term projects, teams that care about planning, or anyone who wants maintainable code from the start. If you need to build quick prototypes or work alone on small projects, other tools may be faster (hmmm. Cursor).

Kiro changes how we use AI for coding. Instead of just speeding up code writing, it helps you design better systems. This could become the new standard for building reliable software.

Kiro is still in preview, but its focus on planning and maintainability makes it stand out. As Amazon improves it, Kiro could become a must-have for professional developers. At least I love to see the new direction of AI coding tools in the market.

Cheers! 🍺

AWS Vector Databases for RAG Applications - Your Complete Architectural Decision Guide

Yoonsoo Park — Sun, 25 May 2025 00:00:00 +0000

A comprehensive guide to choosing and implementing AWS native vector database services for RAG applications, covering OpenSearch, RDS PostgreSQL, Neptune Analytics, Bedrock Knowledge Bases, and Kendra with real-world decision frameworks.

The landscape of Retrieval-Augmented Generation (RAG) applications has evolved dramatically, with vector databases becoming the backbone of modern AI systems. As organizations are motivated to implement RAG solutions, the choice of vector database architecture can make or break the success of your application. AWS offers five native services for vector database functionality, each optimized for different use cases and scale requirements. Let’s dive in!

In 2024-2025, these services have made significant enhancements in my opinion. From OpenSearch’s fourfold latency improvements to pgvector 0.8.0’s enhanced query planning capabilities, and Bedrock Knowledge Bases’ new GraphRAG support, these options are far more powerful and production-ready than ever before.

The Five AWS Vector Database Powerhouses

Amazon OpenSearch Service: The Scale Champion

AWS OpenSearch Service Vector database capabilities blog Vector database capabilities revisited k-NN search documentation Cost optimization with quantization Disk-optimized vector engine Serverless vector search Choosing k-NN algorithms

Amazon OpenSearch Service stands as the most robust option for high-scale vector deployments. With OpenSearch 2.17 bringing significant improvements including fourfold latency improvements and 25% better performance through parallelization, it’s designed for organizations that need to handle billions of vectors with sub-second response times.

Key Capabilities:

Massive Scale: Supports up to 16,000 dimensions with proven billion-scale deployments
Multiple Algorithms: Three engine options (NMSLIB, FAISS, Lucene) with HNSW, IVF, and product quantization
Advanced Optimization: Up to 32x compression with binary vectors and 70% cost reduction with disk-optimized ANN
Serverless Option: Auto-scaling with pay-per-OCU pricing model

The service excels when you need maximum flexibility and can invest in the operational complexity. Recent disk-based vector search capabilities reduce memory requirements by up to 66% while maintaining query performance through intelligent rescoring.

Amazon RDS PostgreSQL with pgvector: The Integration Master

AWS RDS PostgreSQL | pgvector 0.8.0 announcement | pgvector 0.7.0 announcement | RAG workflows guidance

For organizations with existing PostgreSQL infrastructure, RDS with pgvector offers the smoothest integration path. The latest pgvector 0.8.0 release includes significant improvements to PostgreSQL’s query planner selection when filters are present, delivering better query performance and search result quality.

Recent Enhancements:

Performance Boost: 30x faster HNSW index builds and improved filtering capabilities
Extended Dimension Support: Up to 4,000 dimensions with halfvec and 64,000 with binary vectors
Advanced Data Types: halfvec (50% memory reduction), sparsevec, and binary vector support
Enhanced Filtering: Iterative index scans help prevent ‘overfiltering’ and ensure sufficient results

This option shines when you need to combine vector search with complex relational queries and maintain ACID compliance across your entire dataset.

Amazon Neptune Analytics: The Relationship Expert

AWS Neptune | AWS Neptune Analytics Documentation | Vector indexing guide | GraphRAG blog post

Neptune Analytics introduces a unique approach by combining vector similarity with graph relationships. With GraphRAG capabilities in preview, it provides more accurate and comprehensive responses by using RAG techniques combined with graphs.

Unique Features:

Highest Dimension Support: Up to 65,535 dimensions, the highest among AWS services
GraphRAG Capabilities: Multi-hop reasoning and relationship-aware retrieval
Complex Query Support: Processes graph + vector queries efficiently
Accuracy Improvements: Up to 35% better answer quality for interconnected queries

Choose Neptune Analytics when your data has rich relationships and you need to understand connections between entities, not just similarity.

Amazon Bedrock Knowledge Bases: The Rapid Deployment Solution

AWS Bedrock Knowledge Bases | AWS Bedrock Knowledge Bases Documentation | AWS Bedrock Knowledge Bases How it works guide | AWS Bedrock Knowledge Bases Launch announcement

Amazon Bedrock Knowledge Bases now supports custom connectors and ingestion of streaming data, allowing developers to add, update, or delete data through direct API calls. This represents the fastest path from concept to production RAG application.

2024-2025 Enhancements:

Multimodal Processing: Parse documents using either Amazon Bedrock Data Automation or foundation models, improving accuracy for documents with both images and text
Structured Data Support: Natural language querying of data warehouses and data lakes through conversational interfaces
Streaming Capabilities: Real-time data ingestion without intermediary storage
Enhanced Data Sources: Web crawler, Confluence, SharePoint, and Salesforce connectors
Built-in Evaluation: RAG evaluation tools in preview for quality assessment

This service eliminates months of development time while providing enterprise-grade features that most custom implementations lack.

Amazon Kendra: The Enterprise Search Specialist

AWS Kendra | AWS Kendra Features Overview | AWS Kendra Index Types Documentation | AWS Kendra GenAI Index announcement

Kendra delivers enterprise-grade semantic search without requiring vector expertise. Its GenAI Index optimizes specifically for RAG workloads with 43 native data connectors and advanced document understanding capabilities.

Enterprise Features:

Zero Vector Expertise Required: Built-in semantic understanding and document processing
Comprehensive Connectors: 43 pre-built connectors for enterprise data sources
Advanced Access Control: Built-in security and compliance features
Document Intelligence: Natural understanding of complex document structures

While limited to English, Kendra excels at complex document comprehension and provides the fastest time-to-value for traditional enterprise search scenarios.

Performance and Scale: Making the Right Choice

High-Throughput Scenarios (>100M Vectors)

For applications handling more than 100 million vectors, OpenSearch Service provides the most proven solution. The service can handle billions of vectors across thousands of dimensions, with serverless options that auto-scale for variable workloads.

Memory Planning for OpenSearch: The memory requirements follow the formula: 1.1 * (4 * d + 8 * m) * num_vectors * (1 + replicas) bytes. For 1 billion vectors of 128 dimensions with default settings, you’d need approximately 1,408 GB of memory.

Recent SIMD optimizations deliver 87% latency reduction for inner product calculations, making it viable for real-time applications at massive scale.

Mid-Scale Deployments (<100M Vectors)

RDS PostgreSQL with pgvector works exceptionally well for sub-100M vector deployments, especially when leveraging Graviton3 instances for 40% better price-performance. HNSW indexes provide 15.5x faster queries than IVFFlat, but require the entire index in memory, making instance sizing critical.

Real-Time Latency Requirements

For sub-millisecond response requirements, consider:

OpenSearch with warm indices and proper caching strategies
MemoryDB with vector search capabilities (emerging option)
Neptune Analytics for complex graph+vector queries (processes in seconds despite scale)

Cost Optimization: Maximizing Your ROI

Storage-Intensive Workloads

OpenSearch’s advanced quantization offers dramatic cost reductions: binary vectors provide 32x compression, product quantization delivers up to 64x compression, and disk-based search reduces costs by 66%.

Quantization Strategy:

Standard vectors (float32): 4 bytes per dimension
Binary quantization: 0.125 bytes per dimension (32x reduction)
Product quantization: Variable compression up to 64x

Variable Workload Patterns

For unpredictable traffic patterns, serverless options provide the best cost efficiency:

OpenSearch Serverless: Pay per OCU-hour with automatic scaling
Aurora Serverless v2: Scale to zero with 15-second resume times
Bedrock Knowledge Bases: No infrastructure charges, only model usage(!)

Development and Testing

Optimize development costs with:

Single-AZ deployments (50% cost savings)
Reserved instances for predictable workloads (up to 70% savings)
Spot instances for batch vector processing (up to 90% savings)

Technical Implementation Deep Dive

Vector Characteristics and Algorithm Selection

Dimensionality Limits by Service:

OpenSearch: 16,000 dimensions (float32)
Neptune Analytics: 65,535 dimensions (highest capacity)
pgvector: 2,000 standard, 4,000 with halfvec, 64,000 with binary
Bedrock/Kendra: Model-dependent (typically 1,536)

Algorithm Availability:

HNSW: Available in OpenSearch (all engines), pgvector, Neptune Analytics
IVF: OpenSearch FAISS engine only
Product Quantization: OpenSearch FAISS exclusive
Exact Search: All services support with performance trade-offs

Multi-Tenancy Strategies

Dedicated Isolation (Recommended for Compliance):

Separate Bedrock Knowledge Bases per tenant
OpenSearch index-per-tenant with routing
PostgreSQL schema separation in Aurora

Shared Infrastructure with Filtering:

OpenSearch metadata filtering integrated with k-NN queries
pgvector WHERE clause optimization in version 0.8.0
Kendra user context filtering
Neptune graph-based access control

Winners by Use Case

Enterprise Document Search with Compliance

Winner: Amazon Kendra GenAI Index

Kendra provides built-in access control, 43 enterprise connectors, and requires no vector expertise. Starting cost around $810/month makes it economical for most enterprise scenarios.

Alternative: Bedrock Knowledge Bases + OpenSearch Serverless

More customization flexibility
Better multimodal support
Requires additional setup complexity

High-Scale Consumer Applications

Winner: OpenSearch Service

Proven at billion-scale deployments with advanced caching, optimization features, and multiple algorithm choices.

Alternative: OpenSearch Serverless

Eliminates capacity planning
Higher per-query costs but automatic scaling
Better for unpredictable traffic patterns

Existing PostgreSQL Environments

Winner: Aurora PostgreSQL with pgvector

Seamless integration with existing relational data, ACID compliance, and familiar tooling make this the obvious choice for PostgreSQL shops.

Considerations:

Memory requirements for HNSW indexes
Performance degradation beyond 1M vectors without proper optimization
Recent 30x performance improvements and enhanced filtering capabilities address previous limitations

Knowledge Graph Applications

Winner: Neptune Analytics

Unique graph + vector capabilities provide 35% accuracy improvement for complex queries through relationship-aware retrieval.

Trade-offs:

Single vector index limitation per graph
Higher complexity than pure vector search
Currently limited regional availability

Rapid Prototyping and MVPs

Winner: Bedrock Knowledge Bases

Days to production versus months, zero infrastructure management, and built-in evaluation tools make this the clear winner for getting started quickly.

Migration Path: Start with Bedrock for validation, then migrate to self-managed options only when you’ve validated specific custom requirements that the managed service cannot meet.

Recent Innovations Reshaping the Landscape

GraphRAG Revolution

The emergence of GraphRAG through Neptune Analytics and Bedrock Knowledge Bases integration fundamentally changes retrieval for relationship-rich data. Organizations with knowledge graphs or complex document relationships should prioritize these services for significantly improved accuracy.

Quantization Maturity

Quantization advances in pgvector 0.7+ and OpenSearch make billion-scale deployments economically viable, with 67x faster index builds removing previous bottlenecks.

Managed Services Production Readiness

Bedrock Knowledge Bases evolution positions it as production-ready for most RAG use cases, not just prototypes. The addition of custom chunking, reranking models, and evaluation frameworks addresses previous limitations that forced organizations toward custom solutions.

Migration Paths and Hybrid Architectures

Many organizations benefit from hybrid approaches rather than forcing all data into a single service:

Effective Hybrid vector database architectures:

Kendra + OpenSearch: Enterprise documents in Kendra, user-generated content in OpenSearch
pgvector + Bedrock: Structured data in PostgreSQL, unstructured in Knowledge Bases
Neptune + OpenSearch: Graph relationships in Neptune, content vectors in OpenSearch

Migration Recommendations:

Start with managed services for faster validation
Migrate to self-managed for specific optimizations only after validating the need
Maintain hybrid architectures for diverse data types rather than forcing uniformity

Common Anti-Patterns to Avoid

Over-Engineering Initial Deployments

Starting with complex custom solutions when Bedrock Knowledge Bases would suffice delays time-to-value without proportional benefits. The service now supports custom connectors and streaming data, addressing most customization needs. I def recommend to start with Bedrock Knowledge Bases and migrate to self-managed options.

Ignoring Quantization Opportunities

Running high-dimensional vectors without compression wastes 32-64x storage and memory costs. Modern quantization techniques maintain quality while reducing infrastructure requirements dramatically!

Single-Service Tunnel Vision

Forcing all data types into one service instead of leveraging each service’s strengths in a hybrid architecture often leads to suboptimal performance and unnecessary complexity.

Cheers! 🍺

AI Agents vs. Agentic AI - Understanding the Key Differences That Matter in 2025

Yoonsoo Park — Wed, 21 May 2025 00:00:00 +0000

Discover the critical distinctions between AI agents and agentic AI systems, their architectural differences, real-world applications, and why understanding these concepts is essential for making smart AI investment decisions in 2025.

IBM’s Guide to Agentic AI vs Generative AI | AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenges

The artificial intelligence landscape is chaged every day or even every hour, and two terms that frequently showing in discussions about the future of AI are “AI agents” and “agentic AI.” While they might sound similar and are often used interchangeably, they are different approaches to building intelligent systems, really. Understanding these differences isn’t just academic—it’s critical for making correct decisions about AI investments and implementations in 2025.

Recent research, including a comprehensive study published in arXiv (2505.10468v1), has explained clear frameworks for distinguishing between these paradigms. Lets dive into the details.

AI Agents: The Specialized Task Masters

Think of AI agents as highly skilled specialists (or systems) designed to conquer specific, well-defined tasks. These are the workhorses and powered by Large Language Models (LLMs) or Large Image Models (LIMs), that deliver focused automation solutions.

Core Characteristics of AI Agents

Modularity and Focus: AI agents are built as distinct, modular components with a clear goal. Unlike GenAI systems, they’re engineered for aiming for a specific task and domain. e.g. A customer service chatbot is designed specifically to handle inquiries, route tickets, and provide support BUT it should not to manage inventory or analyze market trends.

Tool Integration Excellence: One of AI agents’ greatest strengths is in their sophisticated tool integration capabilities. They are good at leveraging external APIs, databases, and software tools through carefully crafted prompt engineering. This allows them to extend their capabilities more than just their base model while maintaining focused goal.

Reactive Intelligence: AI agents work primarily in a reactive mode, in other words, responding to inputs with appropriate actions. They can utlize basic learning mechanisms and feedback loops to refine their performance over time, but their learning is typically confined to their specific domain area.

Bounded Autonomy: Think of AI agents like a well-trained dog (like my dog, Lucy!) on a leash. They can do their job without constant supervision, but they’re designed to stay within certain boundaries. Just as a dog knows not to run into the street, AI agents follow specific rules and limits that make them safe and dependable for their intended tasks.

Real-World Applications

Think of…

Your email’s spam filter uses pattern recognition to automatically categorize unwanted emails.
Document management systems use AI agents to categorize and route files based on content analysis.
E-commerce platforms use recommendation agents that understand your browsing history and purchasing patterns to suggest relevant products for you.

Consider a more sophisticated example:

an executive assistant AI agent integrated with Google Calendar and Slack. When given a command like “Schedule a 45-minute follow-up with the marketing team next week,” the agent understans(more like parse) the request, checks availability for all participants, accounts for time zone differences, and avoids scheduling conflicts. If it encounters a conflict, it autonomously proposes alternative time slots and notifies affected team members through integrated communication tools. Very focused area.

Agentic AI: The Orchestrated Intelligence Networks

Agentic AI represents a paradigmatic shift from individual task automation to collaborative usage of multiple agents. Rather than focusing on single-task excellence, agentic AI systems are designed to tackle complex challenges through orchestrated agent collaboration.

Defining Features of Agentic AI

Multi-Agent Collaboration: The fundamental architecture of agentic AI involves multiple specialized agents working together. Each agent may have distinct capabilities—one might excel at data analysis, another at natural language processing, and a third at decision-making—but they coordinate their efforts toward common objectives. the goal is to solve a complex problem as a team.

Dynamic Task Decomposition: Unlike AI agents that handle predefined tasks, agentic AI systems can break down complex problems into manageable sub-tasks. (e.g. Like we as an engineers breaking down a big Epic into smaller stories) They dynamically assign these sub-tasks to the most appropriate agents within their team, adapting their approach based on the specific requirements of each goal.

Persistent Memory and Context: Agentic AI systems maintain sophisticated memory capabilities that span across multiple agents and interactions. This persistent context enables them to learn from previous experiences and apply insights to new situations, creating a form of institutional knowledge within the system. (e.g. Like we as an engineers, we can learn from previous experiences and apply insights to new situations, creating a form of institutional knowledge within the system.)

Orchestrated Autonomy: The autonomy in agentic AI extends beyond individual agents to make coordinated decision-making across the entire system. Agents don’t just operate independently but they delegate, even negotiate, and collaborate autonomously to achieve challenging goals.

Advanced Applications

Agentic AI excels in scenarios that require complex problem-solving and coordination across multiple domains. In research automation, different AI components handle literature review, data analysis, hypothesis generation, and experiment design, all working together to reach the scientific discovery.

Manufacturing environments showcase agentic AI’s coordination capabilities, where multiple robotic agents collaborate on complex assembly tasks. Each robot may specialize in different aspects of the process—welding, component placement, quality inspection—but they coordinate their actions in real-time to optimize the entire production line. (e.g. Like we as an engineers, we can collaborate on a complex project, each of us specializing in different aspects of the process, and coordinate our actions in real-time to optimize the entire project.)

Healthcare presents another compelling use case, where agentic AI systems integrate data from various sources—electronic health records, diagnostic imaging, laboratory results, and clinical literature—using different analytical agents to provide comprehensive medical decision support. The system might have agents specialized in radiology interpretation, medication interaction analysis, and treatment recommendation, all contributing to a holistic assessment.

The Fundamental Distinction: Architecture and Autonomy

The core difference between AI agents and agentic AI lies in their architectural design and the nature of their autonomy. AI agents are like skilled solo performers—they excel at their specific role but operate primarily in isolation. Agentic AI systems are like bands, where the true beauty happens through coordination and collaboration between multiple specialized performers.

Architectural Evolution

AI agents typically follow a straightforward architecture: perception → processing → action. They receive inputs, process them through their trained models, and produce outputs. While they may integrate with external tools, they remain fundamentally single-entity systems.

Agentic AI represents a more complex architectural setup. It involves agent discovery and selection, dynamic task allocation, inter-agent communication protocols (A2A by Google), conflict resolution mechanisms, and collaborative behavior management. This complexity enables capabilities that individual agents cannot achieve alone but also introduces new challenges around coordination and control.

Autonomy Levels

The autonomy distinction is also important. AI agents operate with “bounded autonomy”—they make decisions within well-defined parameters and established rules. This makes them reliable and predictable, essential qualities for many business applications.

Agentic AI systems show “orchestrated autonomy”—they make complex decisions across multiple domains and can adapt their strategies based on changing circumstances. This higher level of autonomy allows more sophisticated problem-solving but requires careful design to ensure reliability and safety.

Implementation Considerations and Challenges

Each paradigm comes with its own implementation challenges that organizations must consider when choosing their AI strategy to meet their needs.

AI Agent Challenges

AI agents face challenges mainly comes to their reliance on underlying language models. Hallucination remains a significant issue, particularly in high-stakes applications where accuracy is critical (Finance, Healthcare, etc.).

Limited long-horizon planning capabilities also constrain AI agents. While they are good at immediate task execution, they struggle with complex, multi-step processes that require sustained reasoning over extended periods. (very dependent on the underlying model)

Agentic AI Complexities

Agentic AI systems introduce a different set of challenges. Inter-agent coordination failures can lead to system-wide failures. The emergent behavior that makes these systems powerful can also make them unpredictable, requiring close up monitoring and control mechanisms.

Scalability becomes a significant concern as the number of agents increases. Managing communication overhead, preventing coordination bottlenecks, and ensuring system stability at scale can be challenging.

Debugging the reasoning is a challenge. Understanding why an agentic AI system made a particular decision often requires tracing interactions across multiple agents, making it hard to provide clear explanations for system behavior.

Making the Right Choice: When to Use What (this is what we all want, right?)

The decision between AI agents and agentic AI shouldn’t be based on which technology is more advanced, but rather on which approach best fits your specific use case and organizational needs. In other words, you must know your use case clearly then ever.

Choose AI Agents When:

You have well-defined, specific tasks that require automation
Reliability and predictability are paramount
You need cost-effective solutions withiin narrow problem domains
Compliance and audit requirements demand clear decision trails

Choose Agentic AI When:

You’re tackling complex, multi-domain problems
Your use cases require coordination across multiple specialized functions
The potential benefits justify the increased complexity and cost

Wrapping it up 👏

The choice between AI agents and agentic AI must not be about picking the latest technology—it’s about selecting the right tool for your specific goals. AI agents are great choices when you have well-defined, specific tasks that require automation, and you need reliability and predictability. Agentic AI systems shine as orchestrated intelligence networks, capable of tackling complex, multi-faceted challenges through sophisticated agent collaboration.

I am writing this article to enhance my understanding of AI agents and agentic AI but who knows what will be introduced in the future. Knowledge is obsolete very quickly in this era. We just need to keep it up to date. I feel that the winter is coming. no matter we are preparing for it or not.

Cheers 🍺

Setting Up SSO Between AWS Cognito and Salesforce - A Beginner's Guide

Yoonsoo Park — Fri, 11 Apr 2025 00:00:00 +0000

Learn how to implement Single Sign-On between AWS Cognito and Salesforce for a seamless user experience with complete step-by-step instructions.

AWS Cognito Identity Provider Documentation

Introduction

Single Sign-On (SSO) between AWS Cognito and Salesforce can eliminate multiple login prompts. This guide will walk through the complete setup process, core concepts and implementation details for someone dives into the sso setup for the first time.

Understanding AWS Cognito Components

User Pools: The base of authentication

A User Pool is Cognito’s user directory that handles:

User registration and account creation
Authentication (username/password validation)
User attributes storage (email, phone, custom fields)
Security features (MFA, password policies)

Think of a User Pool as your base database of users which answers the “who are you?” part of authentication.

App Clients: The Connectors

Many beginners wonder why App Clients are needed when User Pools already manage users. (at least it was for me) Let’s break it down:

An App Client defines:

Which applications can use your User Pool
What authentication flows are allowed (e.g., user password, refresh tokens)
Token expiration settings
Callback URLs (where users return after authentication)
OAuth scopes (what user information can be accessed)

App Clients act as bridges between your applications and the User Pool that is answering the “how” and “where” authentication happens.

External Identity Providers (IdPs)

When you connect external providers like Google to your User Pool, you’re creating a “federation” where:

Users authenticate with their existing accounts
Cognito receives verification from the external provider
Cognito creates or maps to a user in its User Pool
Cognito issues its own tokens for your applications

Authentication Flow Overview

Step-by-Step Configuration Guide

1. Configuring AWS Cognito

User Pool Setup

Create or use an existing User Pool
Ensure your external IdP (Google) is already configured
Note your User Pool ID (format: region_alphanumeric e.g. us-east-1_1234567890)
Locate and save your User Pool Domain (format: https://your-domain.auth.region.amazoncognito.com e.g. https://my-domain.auth.us-east-1.amazoncognito.com)
- where to find it: your User Pool > Branding > Domain

App Client Configuration

Create a new App Client in your User Pool
Enable the OAuth 2.0 flows (Authorization code grant)
Add Salesforce’s callback URL as an allowed callback (we’ll get this later; I promise :) )
Enable the necessary OAuth scopes:
- openid (required)
- email
- profile
Save your App Client ID
Note the full OAuth Endpoints from the App Integration > App client settings page
- e.g.
- Authorization Endpoint: https://my-domain.auth.us-east-1.amazoncognito.com/oauth2/authorize
- Token Endpoint: https://my-domain.auth.us-east-1.amazoncognito.com/oauth2/token
- User Info Endpoint: https://my-domain.auth.us-east-1.amazoncognito.com/oauth2/userInfo

2. Configuring Salesforce

Create Auth Provider in Salesforce

Go to Setup > Identity > Auth. Providers
Create a new Auth Provider of type OpenID Connect
Name it myFederatedIdP (or your preferred name)
Enter details from Cognito:
- Consumer Key: Your Cognito App Client ID (e.g. 1234567890)
- Consumer Secret: Your Cognito App Client Secret (e.g. 1234567890)
- Authorize Endpoint URL: The OAuth authorization endpoint from Cognito (e.g. https://my-domain.auth.us-east-1.amazoncognito.com/oauth2/authorize)
- Token Endpoint URL: The OAuth token endpoint from Cognito (e.g. https://my-domain.auth.us-east-1.amazoncognito.com/oauth2/token)
- User Info Endpoint URL: The OAuth userinfo endpoint from Cognito (e.g. https://my-domain.auth.us-east-1.amazoncognito.com/oauth2/userInfo)
- Default Scopes: openid email profile
- Custom Error URL: Your error handling page
- Registration Handler: Your custom Apex class (required for Salesforce to register/find users)
  - Salesforce automatically creates a default one for you if you toggle the switch on.
    - You can customize it to your needs!
  - Make sure you have this Apex class by going to Setup > Apex Classes and search for e.g. CognitoRegistrationHandler.
- Execute Registration As: A designated Salesforce user
Save the configuration

Update Cognito with Salesforce Callback URL

After creating the Auth. Provider in Salesforce, it will generate callback URLs. Find the Callback URL (format: https://your-domain.my.salesforce.com/services/authcallback/myFederatedIdP).

Return to AWS Cognito Console
Open your User Pool > App clients
Select your App client
Add this Salesforce callback URL to the “Callback URLs” field
Save the changes

3. Implementing the Redirect in Your Application

Using the redirect service pattern from the WebApp:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// When a user clicks to access Salesforce:
// redirectWithToken is a function that you can implement in your application
RedirectService.redirectWithToken({
 relayState: "https://your-salesforce-domain.my.salesforce.com/lightning/page", // this is where you want to redirect the user after authentication
});

// In the redirect service:
const accessToken = getAccessToken(); // From cookies
const relayStateUrl = new URL(request.relayState);
const sfDomain = relayStateUrl.origin;
const relativePath =
 relayStateUrl.pathname + relayStateUrl.search + relayStateUrl.hash;

// Redirect to Salesforce SSO endpoint
const redirectUrl =
 `${sfDomain}/services/auth/sso/myFederatedIdP` +
 `?startURL=${encodeURIComponent(relativePath)}`;
window.location.href = redirectUrl;

Common Pitfalls and Solutions

Token Format Issues: Ensure your Cognito tokens include required user claims
Callback URL Mismatch: Verify exact match between Salesforce and Cognito URLs
Relative Path Requirements: Salesforce needs relative paths in the startURL parameter (e.g. /lightning/page)
Authorization Scopes: Verify openid scope is enabled for proper OIDC authentication

Wrapping it up 👏

Working on SSO is quite challenging because every bit of information should be correct and match. Even if one of them is off, it won’t work. But the advantage of SSO is that once you set it up, it will improve user experience and reduce the number of login prompts which is huge. I hope this guide helps you to understand the core concepts and implementation details of SSO between AWS Cognito and Salesforce.

Cheers! 🍺

References

Ruby on Rails Tutorial - Essential Syntax and Methods Guide for Beginners

Yoonsoo Park — Fri, 31 Jan 2025 00:00:00 +0000

Getting Started with Ruby on Rails: Syntax and Built-in Methods

A comprehensive guide exploring Ruby’s syntax and built-in methods for common data structures, with helpful comparisons to Python.

📚 Official Ruby on Rails Documentation

Introduction
Class Definitions
Inheritance
Function Definitions
Variables and Scope
Loops and Iteration
Common Default Functions
Built-in Methods

Introduction

If you’re new to Ruby on Rails like me, the initial learning curve might seem steep. However, once you grasp Ruby’s syntax basics, Rails becomes a natural progression. Let’s walk through basic Ruby syntax elements with Python comparisons to help you understand the concepts better. Let’s get started!

Class Definitions

Ruby Syntax

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


class Person
 def initialize(name, age)
 @name = name # Instance variable; note that Ruby uses `@` to denote instance variables
 @age = age
 end

 def introduce
 "Hi, my name is #{@name} and I am #{@age} years old."
 end
end

# Usage
person = Person.new("Alice", 30)
puts person.introduce

Python Equivalent

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class Person:
 def __init__(self, name, age):
 self.name = name
 self.age = age

 def introduce(self):
 return f"Hi, my name is {self.name} and I am {self.age} years old."

# Usage
person = Person("Alice", 30)
print(person.introduce())

💡 Key Difference: Ruby uses @ for instance variables, while Python uses self.

Inheritance

Ruby Implementation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


class Employee < Person
 def initialize(name, age, position)
 super(name, age) # Calls parent class's constructor
 @position = position # then we set the instance variable
 end

 def work
 "#{@name} is working as a #{@position}."
 end
end

Python Implementation

1
2
3
4
5
6
7


class Employee(Person):
 def __init__(self, name, age, position):
 super().__init__(name, age)
 self.position = position

 def work(self):
 return f"{self.name} is working as a {self.position}."

💡 Key Difference: Ruby uses < for inheritance, Python uses parentheses.

Function Definitions

Ruby Methods

1
2
3
4
5
6
7
8
9


class Calculator
 def add(a, b = 0) # Default parameter
 a + b
 end
end

calc = Calculator.new
puts calc.add(5, 10) # => 15
puts calc.add(7) # => 7 (uses default value)

Python Methods

1
2
3
4
5
6
7


class Calculator:
 def add(self, a, b=0): # Default parameter
 return a + b

calc = Calculator()
print(calc.add(5, 10)) # => 15
print(calc.add(7)) # => 7 (uses default value)

Variables and Scope

Ruby Variables

1
2
3
4
5
6


def demonstrate_variables
 local_var = "I am local" # Local variable
 @instance_var = "Instance scope" # Instance variable
 @@class_var = "Class scope" # Class variable
 $global_var = "Global scope" # Global variable
end

Python Variables

1
2
3
4
5


def demonstrate_variables(self):
 local_var = "I am local" # Local variable
 self.instance_var = "Instance scope" # Instance variable
 # Class variables in Python use class namespace
 # Global variables use global keyword

Loops and Iteration

Ruby Loops

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# Each iterator
[1, 2, 3].each do |number|
 puts number
end

# For loop
for number in 1..5
 puts number
end

# While loop
i = 0
while i < 5
 puts i
 i += 1
end

# Until loop (Ruby-specific)
i = 0
until i >= 5
 puts i
 i += 1
end

Built-in Methods

String Methods

1
2
3
4
5
6
7
8


# Common string operations
str = "Hello, World!"
str.length # => 13
str.upcase # => "HELLO, WORLD!"
str.downcase # => "hello, world!"
str.capitalize # => "Hello, world!"
str.reverse # => "!dlroW ,olleH"
str.split(",") # => ["Hello", " World!"]

Array Methods

💡 Note: In Ruby (and Rails), arrays are very flexible and can hold objects of different types simultaneously, similar to Python lists (not tuples, since Python tuples are immutable). This flexibility is one of Ruby’s core principles: “everything is an object” and the language tries to be as permissive as possible to make developers’ lives easier.
1
2
3
4
5
6
7
# Mixed type array examples
mixed_array = [1, "hello", 3.14, true, [1, 2], {name: "John"}]
# You can add different types at any time
mixed_array.push(:symbol) # Adds a Symbol
mixed_array << nil # Adds nil using the shovel operator
mixed_array.unshift(42.0) # Adds a Float at the beginning
# All valid operations!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


# Array operations
arr = [1, 2, 3, 4, 5]
arr.length # => 5
arr.first # => 1
arr.last # => 5
arr.push(6) # => [1, 2, 3, 4, 5, 6]
arr.pop # => 6
arr.include?(3) # => true

# how to insert an element at the beginning of the array
arr.unshift(0) # => [0, 1, 2, 3, 4, 5]

# how to insert an element at the end of the array
arr.push(6) # => [0, 1, 2, 3, 4, 5, 6]

# how to insert an element at a specific index
arr.insert(0, 0) # => [0, 0, 1, 2, 3, 4, 5]

# how to remove an element at a specific index
arr.delete_at(0) # => [0, 1, 2, 3, 4, 5]

# how to remove an element at a specific **value**
arr.delete(0) # => [1, 2, 3, 4, 5]

# how to remove all elements from the array that satisfy the condition
arr.delete_if { |n| n.even? } # => [1, 3, 5] # Removes all elements that satisfy the condition

# how to remove all elements from the array
arr.clear # => []

# how to remove the first element from the array and return the removed element
arr.shift # => [0] # Removes the first element from the array and returns it

# how to insert an element at the beginning of the array
arr.unshift(-1) # => [0, 0, 1, 2, 3, 4, 5]
arr.unshift("a" , "b") # => ["a", "b", 0, 0, 1, 2, 3, 4, 5]

# how to remove the last element from the array and return the removed element
arr.pop # => [5] # Removes the last element from the array and returns it

Hash Methods

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Hash operations
hash = { name: "John", age: 30 }
hash.keys # => [:name, :age]
hash.values # => ["John", 30]
hash[:name] # => "John"
hash.merge(city: "New York") # => {:name=>"John", :age=>30, :city=>"New York"}
hash.delete(:age) # => 30 # Deletes the key-value pair with the specified key and returns the value that was deleted

# Remove key-value pairs based on a condition
hash = { name: "John", age: 30, role: "Developer", level: "Senior" }
hash.delete_if { |k,v| v == "John" } # => {:age=>30, :role=>"Developer", :level=>"Senior"} # Removes all pairs where value is "John"

# Remove nil values from hash
hash = { name: "John", age: 30, title: nil, department: nil }
hash.compact # => {:name=>"John", :age=>30} # Returns new hash with nil values removed
hash.compact! # Removes nil values from original hash permanently

# how to remove all key-value pairs from the hash
hash.clear # => {} # Removes all key-value pairs from the hash

Numeric Methods

1
2
3
4
5
6
7
8


# Numeric operations
num = 42
num.even? # => true
num.odd? # => false
(-num).abs # => 42 # The - operator negates num to -42, then abs returns absolute value back to 42
3.14.round # => 3
3.14.ceil # => 4
3.14.floor # => 3

Enumerable Methods

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


# Collection operations
numbers = [1, 2, 3, 4, 5]

# Map/Collect
numbers.map { |n| n * 2 } # => [2, 4, 6, 8, 10] # |n| is a block parameter, similar to a function parameter
 # It represents each element from 'numbers' as the map iterates
 # You can name it anything, e.g. |num| or |x|

# Select/Filter
numbers.select { |n| n.even? } # => [2, 4]

# Reduce/Inject
numbers.reduce(:+) # => 15 # Adds all numbers in array: 1 + 2 + 3 + 4 + 5 = 15
numbers.inject(:+) # => 15 # Same as reduce
numbers.inject(0) { |result, element| result + element } # => 15 # More explicit version where:
 # - 0 is the initial value
 # - result is always the accumulated value from previous iterations
 # - element is the current array element being processed
 # The block parameters |result, element| follow a convention:
 # - First parameter is always the accumulator/result
 # - Second parameter is always the current element

# Sort
numbers.sort # => [1, 2, 3, 4, 5] # Sorts numbers in ascending order (they are sorted already... but you get the point)
numbers.sort.reverse # => [5, 4, 3, 2, 1] # Sorts numbers in descending order

# Reverse
numbers.reverse # => [5, 4, 3, 2, 1] # Reverses the order of the array

# First/Last
numbers.first # => 1 # Returns the first element of the array

# Any/All
numbers.any? { |n| n > 3 } # => true # Returns true because at least one number (4,5) is greater than 3
numbers.all? { |n| n < 6 } # => true # Returns true because every number (1,2,3,4,5) is less than 6

Cheers! 🍺

Unlocking Meeting Insights with Amazon Transcribe

Yoonsoo Park — Fri, 24 Jan 2025 00:00:00 +0000

Learn how to use Amazon Transcribe and a Python CLI app to extract meeting transcripts, enabling seamless collaboration and brainstorming with GenAI tools.

Amazon Transcribe Pricing

Unlocking Meeting Insights with Amazon Transcribe

Keeping track of critical decisions, action items, and brainstorming outcomes can be overwhelming—especially when meetings pile up and you are not native English speaker lol. Amazon Transcribe simplifies this process for me by converting my audio recordings into searchable, shareable text. In this article, we are going to explore how Amazon Transcribe works and how to automate the workflow using a Python CLI tool.

So… What is Amazon Transcribe?

Amazon Transcribe is a fully managed Automatic Speech Recognition (ASR) service that transcribes spoken audio into text which offers the following features:

Multi-language support for global teams.
Speaker identification to distinguish multiple speakers.
Real-time transcription for instant insights.
Custom vocabulary for domain-specific terms.

Amazon Transcribe supports popular audio formats such as MP3, WAV, FLAC, and M4A (processed as MP4). To better understand the pricing model and potential costs, please check out the official Amazon Transcribe Pricing page.

Why Extract Meeting Transcripts?

We all human and it is impossible to remember everything. Recorded meetings often contain critical information that can get lost if not documented properly. But can we document everything? No, we can’t. By transcribing these recordings, we can:

Capture Key Decisions and Action Points: Ensure accountability by having an exact record of what was agreed upon. (so we can start pointing fingers at each other. ;))
Enhance Team Collaboration: Quickly share meeting outcomes with absent members or stakeholders.
Leverage Transcripts for Brainstorming: Feed transcripts into GenAI or other productivity tools for advanced insights. Use it as a context for your GenAI chatbot!
Maintain a Knowledge Repository: Turn every meeting into a searchable archive for future reference.

Setting Up Amazon Transcribe for Your Needs

To get started, you’ll need:

An AWS Account: Sign up at aws.amazon.com if you haven’t already.
Proper IAM Permissions: Ensure your AWS credentials allow you to access Amazon Transcribe and Amazon S3.
S3 Bucket: Create a bucket to store audio files for transcription.
Audio Recordings in Supported Formats: MP3, WAV, FLAC, or M4A.

Having these components ready? we can start the fun part!

Automating the Workflow with Python

To save time and reduce manual steps, you can use a dedicated Python CLI application.

This is an example CLI app I created for my personal use. You can find the code here.

This app handles:

Uploading Audio: Automated upload to an S3 bucket.
Initiating Transcription Jobs: Start and monitor transcription jobs on AWS.
Saving Transcripts Locally: Retrieve and store final transcripts for easy access.
Error Handling: Simplifies troubleshooting by indicating failed or incomplete jobs.

Real-Life Applications of Meeting Transcripts

Brainstorming with GenAI Feed transcripts into genAI tools for further insights and solutionings.
Creating Summaries for Absent Team Members Keep everyone in the loop by distributing key insights and decisions. No one left behind!
Archiving Decisions for Compliance Many industries require documented evidence of discussions and decisions. Transcripts make compliance like a breeze.

Wrapping it up 👏

Whether you like it or not, we have to join meetings and how to manage the meetings efficiently is another story. But given the fact that we have to join meetings, why not make it efficient and useful? The one of the most efficient way is to transcribe the meetings and use the transcripts for further insights. The information we can get from the transcripts is endless especially when we use genAI tools. Start playing with transcripts! You can thank me later. :)

Cheers! 🍺

Troubleshooting AWS Amplify Authentication - Solving the Mystery of Login Errors

Yoonsoo Park — Mon, 30 Dec 2024 00:00:00 +0000

A detailed guide to resolving common AWS Amplify authentication issues in React Native applications, with practical solutions and code examples.

AWS Amplify Documentation

Have you ever spent days debugging an authentication issue that seemed impossible to solve? I faced a mysterious problem with AWS Amplify authentication in a React Native application built with Expo. While the signup process worked flawlessly, the signin functionality kept throwing a vague error: “Unknown: An unknown error has occurred.” This article will guide you through the process of identifying and resolving this issue.

Understanding the Initial Setup

Before diving into the problem, let’s examine how the authentication was initially configured. The setup began with AWS Cognito integration in the configuration file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


import { Amplify } from "aws-amplify";

export const configureAmplify = () => {
 Amplify.configure({
 Auth: {
 Cognito: {
 userPoolId: process.env.EXPO_PUBLIC_COGNITO_USER_POOL_ID!,
 userPoolClientId: process.env.EXPO_PUBLIC_COGNITO_CLIENT_ID!,
 signUpVerificationMethod: "code",
 },
 },
 });
};

This configuration looks correct at first (we have our user pool ID, client ID, and verification method correctly set up). The saying goes, “The devil is in the details,” highlighting that the small details can often introduce a significant impact.

Unraveling the Mystery

The authentication service implementation seemed straightforward:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


class AuthService {
 async signIn({ email, password }: SignInCredentials) {
 try {
 console.log("Attempting to sign in with:", email);
 const { isSignedIn, nextStep } = await signIn({
 username: email,
 password,
 });

 if (nextStep.signInStep !== "DONE") {
 throw new Error("Additional authentication steps required");
 }

 if (!isSignedIn) {
 throw new Error("Sign in failed");
 }

 return { isSignedIn, nextStep };
 } catch (error) {
 console.error("Sign in error:", error);
 throw this.handleError(error);
 }
 }
}

I could identify the root cause after a long struggle with Googling and reading documentation. The problem was the type of authentication flow was not specified. This leads to a battle to implement the correct authentication method.

The Simple Yet Powerful Solution

The fix required one small but significant change - explicitly specifying the authentication flow type in the signin method:

1
2
3
4
5
6
7


const { isSignedIn, nextStep } = await signIn({
 username: email,
 password,
 options: {
 authFlowType: "USER_PASSWORD_AUTH",
 },
});

The addition points Amplify exactly which authentication flow to use which resolved the vaguous error.

Managing Authentication State

To complete the authentication implementation, we need a robust way to manage the auth state across the application. Here’s how to set up an authentication context:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


import React, { createContext, useContext, useState, useEffect } from "react";
import { getCurrentUser } from "aws-amplify/auth";

const AuthContext = createContext<AuthContextType | undefined>(undefined);

export function AuthProvider({ children }: { children: React.ReactNode }) {
 const [isAuthenticated, setIsAuthenticated] = useState(false);
 const [isLoading, setIsLoading] = useState(true);

 useEffect(() => {
 checkAuthState();
 }, []);

 const checkAuthState = async () => {
 try {
 const user = await getCurrentUser();
 setIsAuthenticated(!!user);
 } catch (err) {
 setIsAuthenticated(false);
 } finally {
 setIsLoading(false);
 }
 };

 // ... rest of the implementation
}

Essential Testing Steps

To ensure your authentication implementation works correctly:

Verify your Amplify configuration has the correct credentials and user pool settings
Test the complete signup flow with a new user
Implement email verification if required
Test signin with the specified authFlowType
Verify the authentication state persists across app reloads

why this does not work… why this works…

Cheers! 🍺

Understanding Terraform Commands Through Real-World Examples

Yoonsoo Park — Tue, 24 Dec 2024 00:00:00 +0000

A practical guide to understanding when and why to use different Terraform commands, illustrated through real-world infrastructure management scenarios.

Have you ever wondered when exactly you need to run terraform init versus terraform plan? Let’s explore these commands through practical, real-world scenarios that every DevOps engineer encounters.

Scenario 1: Setting Up a New Web Application Infrastructure

Imagine you’re tasked with setting up the infrastructure for a new web application. You’ll need an EC2 instance, an RDS database, and an S3 bucket for static assets.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# main.tf
provider "aws" {
 region = "us-west-2"
}

resource "aws_instance" "web_server" {
 ami = "ami-0c55b159cbfafe1f0"
 instance_type = "t2.micro"

 tags = {
 Name = "WebServer"
 }
}

resource "aws_db_instance" "database" {
 identifier = "myapp-database"
 engine = "postgres"
 instance_class = "db.t3.micro"
 allocated_storage = 20
}

resource "aws_s3_bucket" "assets" {
 bucket = "myapp-static-assets"
}

First, you’ll need to run terraform init. Why? Because:

This is a new project directory
You’re using the AWS provider for the first time
Terraform needs to download provider plugins

Scenario 2: Adding Application Load Balancer

A month later, your application grows, and you need to add a load balancer. You create a new file:

1
2
3
4
5
6
7


# loadbalancer.tf
resource "aws_lb" "web_lb" {
 name = "web-lb"
 internal = false
 load_balancer_type = "application"
 subnets = aws_subnet.public[*].id
}

In this case, you don’t need to run terraform init again because you’re not adding any new providers or modules. Instead, start with terraform plan to see what changes will be made:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


$ terraform plan
Terraform will perform the following actions:

 # aws_lb.web_lb will be created
 + resource "aws_lb" "web_lb" {
 + arn = (known after apply)
 + name = "web-lb"
 + internal = false
 + load_balancer_type = "application"
 ...
 }

Scenario 3: Introducing Remote State

As your team grows, you decide to store the Terraform state in an S3 backend. You add:

1
2
3
4
5
6
7
8


# backend.tf
terraform {
 backend "s3" {
 bucket = "company-terraform-state"
 key = "myapp/terraform.tfstate"
 region = "us-west-2"
 }
}

This requires running terraform init again because:

You’re changing the backend configuration
Terraform needs to migrate the state file

When to Use Auto-Approve

While developing locally, you might be tempted to use:

1

terraform apply -auto-approve

However, in production, a safer approach is to use plan files:

1
2
3
4
5
6
7


# Generate and save the plan
terraform plan -out=production.tfplan

# Review the plan with your team

# Apply the exact changes you reviewed
terraform apply production.tfplan

Best Practices Checklist

Always run terraform plan before apply
Use -out flag to save plans for critical environments
Run terraform init when:
- Starting a new project
- Adding/changing providers
- Modifying backend configuration
- Adding new modules
Use workspaces to manage multiple environments
Version your Terraform configurations in git

When to Use Targeted Apply

You might face a situation where you need to manage specific resources rather than your entire infrastructure. This is where terraform apply -target comes in handy. However, use it cautiously as it can lead to state inconsistencies if not used properly.

1

terraform apply -target="aws_instance.web_server"

Good use cases for targeted apply:

Emergency Fixes: When you need to quickly update a specific resource

1
2


# Update only the security group during a security incident
terraform apply -target="aws_security_group.web_sg"

Resource Dependencies: When you need to ensure a specific resource is created first

1
2


# Create the VPC first before other networking resources
terraform apply -target="aws_vpc.main"

Testing Changes: When validating changes to specific resources in a large infrastructure

1
2


# Test changes to RDS instance configuration
terraform apply -target="aws_db_instance.database"

⚠️ Important: Always follow up targeted applies with a full terraform plan and apply to ensure your state is consistent. Using -target should be a temporary measure, not a regular practice.

Common Gotchas

State drift: Always run terraform plan before making changes to catch any manual modifications
Provider versions: Specify versions to ensure consistency across team members
Resource dependencies: Use depends_on when implicit dependencies aren’t enough

Cheers! 🍺

Understanding Common DNS and Email Authentication Terms

Yoonsoo Park — Mon, 25 Nov 2024 00:00:00 +0000

A comprehensive guide to understanding common DNS records and email authentication terms like DKIM, CNAME, MX, and more.

When setting up a domain for your website or email system, you’ll encounter various DNS-related terms and records. Let’s demystify these common terms and understand their significance in modern web infrastructure.

DKIM (DomainKeys Identified Mail)

DKIM serves as your email’s digital signature, acting like a wax seal on traditional letters. This authentication method ensures that emails genuinely come from your claimed domain and haven’t been tampered with during transmission.

How DKIM Works

When you send an email, your email server adds a digital signature to the message header
This signature is created using a private key that only your server knows
The recipient’s server can verify this signature using a public key published in your DNS records
If the verification succeeds, the email is considered authentic

Easy DKIM

AWS has simplified the DKIM implementation through Easy DKIM:

Automatically manages the cryptographic aspects
Creates three DKIM tokens for redundancy
Requires minimal technical knowledge to set up
Handles key rotation and maintenance automatically

CNAME (Canonical Name)

CNAME records are like sophisticated mail forwarding services in the DNS world. They allow you to create an alias from one domain name to another. Common uses include:

Pointing subdomains to content delivery networks (CDNs)
Setting up email authentication records
Creating memorable URLs that redirect to longer, technical ones

MX (Mail Exchange)

MX records are the postal service of the email world. They tell other servers where to deliver emails for your domain. Key aspects include:

Priority numbers (lower = higher priority)
Multiple MX records for redundancy
Different priorities for primary and backup mail servers

Additional Common DNS Terms

SPF (Sender Policy Framework)

Specifies which servers are authorized to send emails from your domain
Helps prevent email spoofing
Works alongside DKIM for better email security

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Tells receiving servers what to do with emails that fail SPF or DKIM checks
Provides reporting capabilities for better insight into email authentication
Helps maintain domain reputation

TXT Records

General-purpose text records in DNS
Often used for domain ownership verification
Can store SPF records and other domain verification data

A Records

Maps a domain directly to an IP address
Most basic type of DNS record
Essential for website hosting

Best Practices

Always maintain proper backup MX records
Implement all three email authentication methods (SPF, DKIM, and DMARC)
Regularly audit your DNS records
Use appropriate TTL (Time To Live) values for different record types
Document all DNS changes and their purposes

Cheers! 🍺

Boost Your Productivity with VS Code Multi-root Workspaces - Complete Guide 2024

Yoonsoo Park — Tue, 05 Nov 2024 00:00:00 +0000

Learn how to efficiently manage multiple project folders in Visual Studio Code using multi-root workspaces. Discover setup tips, best practices, and advanced configurations for improved development workflow and knowledge management.

Visual Studio Code

As developers, juggling multiple projects or working with distributed codebases is a common challenge. Visual Studio Code’s multi-root workspaces feature offers an elegant solution to this problem, allowing you to manage multiple folders within a single editor window. Let’s dive into how this powerful feature can transform your development workflow.

What Makes Multi-root Workspaces Special?

Think of multi-root workspaces as your digital workspace organizer. Instead of cluttering your taskbar with multiple VS Code windows or constantly switching between different project folders, you can have everything you need in one place. This feature is particularly valuable for:

Full-stack developers working with separate frontend and backend codebases
Teams managing microservices architectures
Developers maintaining documentation alongside their code
Anyone working with related projects spread across different locations

The Power of Unified Knowledge Management

Integrating with Obsidian and iCloud

One of the most powerful applications of multi-root workspaces is creating a unified knowledge management system that works seamlessly across all your devices. Here’s why this combination is particularly powerful:

Single Source of Truth:
- Keep your Obsidian vault in iCloud while maintaining direct access through VS Code
- Access the same knowledge base whether you’re on your work laptop, personal computer, or mobile device
- Ensure your documentation and notes are always in sync across all platforms
Enhanced GenAI Interactions:
- Maintain a structured record of your progress and learning
- Use your knowledge base as context when interacting with AI tools
- Avoid repeating yourself in AI conversations by referencing your documented progress
- Create more meaningful and context-aware AI interactions
Progressive Documentation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "folders": [
 {
 "path": "~/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault",
 "name": "Knowledge Base"
 },
 {
 "path": "./current-project",
 "name": "Active Project"
 }
 ]
}

Workflow Integration:
- Track project progress alongside your knowledge base
- Reference and update documentation in real-time as you code
- Maintain project-specific notes that sync across all devices
- Create living documentation that evolves with your understanding
AI-Assisted Knowledge Management:
- Use your documented progress to generate more relevant AI responses
- Maintain context across different AI conversations
- Build upon previous learnings and discoveries
- Create a feedback loop between your code, documentation, and AI interactions

Setting Up Your Multi-root Workspace

There are two main approaches to creating a multi-root workspace:

Quick Setup Method

Launch VS Code with your main project
Navigate to File > Add Folder to Workspace
Select additional folders you want to include
Save your workspace configuration

Professional Setup Method

Create a .code-workspace file with this structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "folders": [
 {
 "path": "/path/to/your/primary/project"
 },
 {
 "path": "/path/to/your/secondary/folder"
 }
 ],
 "settings": {}
}

Advanced Configuration Tips

1. Portable Workspace Configuration

Make your workspace more shareable by using relative paths:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "folders": [
 {
 "path": ".",
 "name": "Main Project"
 },
 {
 "path": "../docs",
 "name": "Documentation"
 }
 ]
}

2. Folder-Specific Settings

Customize settings for different project folders:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


{
 "folders": [
 {
 "path": "./client",
 "name": "Frontend"
 },
 {
 "path": "./server",
 "name": "Backend"
 }
 ],
 "settings": {
 "./client": {
 "editor.tabSize": 2
 },
 "./server": {
 "editor.tabSize": 4
 }
 }
}

3. Knowledge Base Integration

Configure your workspace to include your Obsidian vault:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


{
 "folders": [
 {
 "path": "~/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault",
 "name": "Knowledge Base"
 },
 {
 "path": "./project1",
 "name": "Current Project"
 },
 {
 "path": "../reference-projects",
 "name": "Reference Code"
 }
 ],
 "settings": {
 "files.exclude": {
 "**/.obsidian": true
 }
 }
}

Best Practices for Multi-root Workspaces

Organize Thoughtfully: Group related projects together for logical workflow
Monitor Performance: Keep the number of folders reasonable to maintain VS Code’s responsiveness
Use Clear Naming: Give each folder a descriptive name in the workspace configuration
Version Control: Consider sharing your workspace configuration with team members
Search Smartly: Use the folder: filter in search to target specific projects

Avoiding Common Pitfalls

Search Scope: Be mindful that searches include all workspace folders by default
Extension Compatibility: Verify that your essential extensions work well with multi-root workspaces
Resource Management: Close unused folders to maintain optimal performance

Best Practices for Knowledge-Driven Development

Consistent Documentation: Update your knowledge base as you code
AI-Ready Notes: Structure your documentation to be easily referenced in AI conversations
Progressive Refinement: Regularly review and update your notes based on new learnings
Cross-Platform Sync: Ensure your workspace configuration works across different devices
Context Preservation: Maintain links between related pieces of knowledge

Real-world Applications

Multi-root workspaces excel in scenarios like:

Managing frontend and backend codebases in full-stack applications
Keeping documentation and code in sync
Working with multiple microservices
Maintaining configuration files alongside active projects
Building a personal knowledge management system
Creating AI-ready documentation
Maintaining a learning journal alongside active projects
Tracking project progress across multiple devices

Looking Ahead

As modern development becomes increasingly complex, tools like VS Code’s multi-root workspaces become essential for maintaining productivity. This feature continues to evolve with each VS Code release, offering new capabilities for managing complex development environments.

Cheers! 🍺

Understanding Git Ignore Patterns - .gitignore vs .git/info/exclude

Yoonsoo Park — Sat, 02 Nov 2024 00:00:00 +0000

Learn when to use .git/info/exclude instead of .gitignore for managing ignored files in Git, with practical examples and use cases

Git Documentation

When working with Git, we often need to specify files and directories that should be ignored by source control. While .gitignore is the most commonly used method, Git provides another powerful but lesser-known option: .git/info/exclude. Let’s explore both approaches and understand when to use each one.

The Traditional Approach: .gitignore

The .gitignore file is the standard way to specify which files Git should ignore. It’s:

Committed to the repository
Shared with all collaborators
Part of the project’s source control
Ideal for project-wide ignore patterns

The Hidden Gem: .git/info/exclude

.git/info/exclude serves a similar purpose but with some key differences. This file:

Lives inside the .git directory
Is not committed to the repository
Remains local to your machine
Doesn’t affect other collaborators

When to Use .git/info/exclude

Here are several scenarios where using .git/info/exclude makes more sense than .gitignore:

Personal IDE Settings
- You use a different IDE than your team
- Example: Ignoring VSCode settings while others use IntelliJ
```
.vscode/
```
Local Development Tools
- You have specific development tools that others don’t use
- Example: Local debugging tools or profilers
```
debug-tools/
my-profiler.log
```
Machine-Specific Build Outputs
- Custom build directories that vary by developer
```
my-custom-build/
local-dist/
```
Personal Test Files
- Test files you create for local experimentation
```
my-test-*.js
scratch/
```
Temporary Working Files
- Files you generate during development but don’t want to share
```
temp-*.txt
working-draft/
```

Real-World Example

Let’s say you’re working on a Node.js project where:

The team uses .gitignore for common patterns:
```
node_modules/
dist/
.env
```

But you personally:

Use VSCode for debugging
Have a custom build script
Keep local notes

Instead of polluting the project’s .gitignore, you can add to .git/info/exclude:

# Personal IDE
.vscode/
launch.json
# Custom build output
my-build/
build-*.log
# Personal notes
dev-notes.md
TODO.txt

Benefits of Using .git/info/exclude

Clean Repository
- Keep the project’s .gitignore focused on truly project-wide patterns
- Avoid cluttering with personal preferences
No Conflicts
- Your ignore patterns won’t conflict with other developers’ workflows
- No need for team discussions about personal ignore patterns
Flexibility
- Easily modify ignore patterns without creating commits
- Experiment with different tools without affecting the team
Privacy
- Keep your working methods private
- Don’t expose personal tools or workflows

Best Practices

Use .gitignore for:
- Project-wide ignore patterns
- Framework-specific files
- Common development artifacts
Use .git/info/exclude for:
- Personal tooling
- Local development artifacts
- Machine-specific patterns
- Temporary working files

Creating and Editing .git/info/exclude

To start using .git/info/exclude:

1
2
3
4
5
6


# Open the file in your default editor
git config core.editor "code" # If using VSCode
git config core.excludesfile .git/info/exclude

# Or edit directly
vim .git/info/exclude

Remember that the syntax is identical to .gitignore, so all your existing knowledge transfers over.

Conclusion

While .gitignore remains the primary tool for specifying ignore patterns in Git, .git/info/exclude provides a valuable complement for managing personal ignore patterns. By understanding and using both tools appropriately, you can maintain a cleaner repository while accommodating individual development workflows.

Cheers! 🍺

Master Git - Understanding Branches, Remotes, and HEAD for Better Collaboration

Yoonsoo Park — Tue, 15 Oct 2024 00:00:00 +0000

Demystify key Git concepts like local vs. remote branches, fetching, pulling, pushing, and the HEAD pointer to improve your version control skills and team collaboration.

Git Official Documentation

Demystifying Git: Understanding Branches, Remotes, and HEAD

As developers, we use Git and GitHub daily, but some concepts can still trip us up. Today, we’re going to demystify some common Git scenarios and concepts that often cause confusion. We’ll focus on the relationship between local and remote branches, the git fetch command, and the ever-mysterious HEAD.

The Tale of Two Branches: Local vs. Remote

Imagine you’re working on a feature branch called awesome-feature. You’ve created this branch locally and pushed it to GitHub. Now, both your local machine and GitHub have a branch called awesome-feature. But here’s the kicker: these two branches can diverge!

Real-life scenario:

You create awesome-feature locally and push it to GitHub.
Your colleague, Alice, pulls awesome-feature, makes some changes, and pushes to GitHub.
Now, the awesome-feature on GitHub has changes that your local awesome-feature doesn’t.

This is where the concept of “remote branches” comes in. Your local Git keeps track of the state of branches on GitHub (or any remote) using “remote-tracking branches”. These are usually named origin/branch-name.

Fetching: Updating Your Local Knowledge

When you run git fetch origin, you’re essentially asking Git to update its knowledge about the state of the remote repository. It’s like checking for new emails without actually opening them.

What `git fetch` does:

It communicates with GitHub to see what changes exist on the remote.
It updates your local remote-tracking branches (like origin/awesome-feature).
It doesn’t change your working directory or local branches.

After fetching, you can see what’s new:

1
2


git fetch origin
git diff awesome-feature origin/awesome-feature

This shows you what changes are on GitHub that you don’t have locally.

Pull: Fetch + Merge

The git pull command is actually a combination of two steps: fetch and merge. It’s like checking for new emails and automatically putting them in your inbox.

1

git pull origin awesome-feature

This fetches the latest changes from the awesome-feature branch on GitHub and merges them into your current local branch.

When you try to push your changes, Git checks if your local branch has diverged from the remote branch. If it has, you’ll get an error like:

! [rejected] awesome-feature -> awesome-feature (non-fast-forward)
error: failed to push some refs to 'https://github.com/your-repo.git'

This is Git’s way of protecting you from accidentally overwriting changes on the remote.

How to resolve:

First, pull the latest changes:
1

git pull origin awesome-feature
Resolve any merge conflicts if they occur.
Then push your changes:
1

git push origin awesome-feature

The Mysterious HEAD

HEAD is Git’s way of knowing “where you are” in the history of your project. It’s like a bookmark in a book.

Normal HEAD:

Usually, HEAD points to the latest commit of your current branch. When you make a new commit, HEAD moves forward automatically.

HEAD -> awesome-feature -> Latest Commit

Detached HEAD:

Sometimes, you might checkout a specific commit or a remote branch directly:

1
2
3


git checkout abc123 # Some commit hash
# or
git checkout origin/awesome-feature

Now you’re in a “detached HEAD” state. It’s like you’ve placed your bookmark on a specific page, rather than at the end of a chapter.

In this state:

You can look around and make experimental changes.
If you make commits, they won’t belong to any branch.
To save your work, create a new branch:
1

git checkout -b experimental-idea

Best Practices

Fetch Often: Regularly run git fetch to stay updated with remote changes.
Pull Before Push: Always pull before pushing to avoid rejection.
Use Branches: Create feature branches for new work to keep main/master clean.

Cheers! 🍺

Mastering Git Diff for Efficient Pull Request Analysis - A Developer's Guide

Yoonsoo Park — Mon, 30 Sep 2024 00:00:00 +0000

Learn how to streamline your pull request analysis using advanced Git diff techniques. This guide covers basic and advanced methods to focus on relevant code changes and improve your review process.

Git Documentation

Mastering Git Diff for Efficient Pull Request Analysis: A Developer’s Guide

As a developer, reviewing pull requests is a crucial part of the software development process. While platforms like GitHub and GitLab offer user-friendly interfaces for this task, sometimes we need a more tailored approach. This guide will show you how to leverage the power of git diff to analyze pull requests effectively and efficiently.

Understanding the Basics of Git Diff

Before diving into advanced techniques, let’s cover the fundamental git diff commands for pull request analysis:

Ensure you’re on the target branch (usually main):
1

git checkout main
Fetch the latest changes:
1

git fetch origin
View changes between the current branch and the pull request branch:
1

git diff main..origin/feature-branch
1. e.g. origin/release is the target branch, and story/DX-16597 is the pull request branch.
  1
  
  git diff origin/release..origin/story/DX-16597

For a concise summary of changes:

1

git diff --stat main..origin/feature-branch

To see only changed file names:

1

git diff --name-status main..origin/feature-branch

These commands provide a solid foundation for pull request analysis, but they often include more information than necessary.

Advanced Git Diff Techniques for Focused Analysis

To overcome the limitations of standard git diff output, which often includes irrelevant files like CHANGELOG.md or package-lock.json, we can use a more refined approach:

1
2
3
4
5
6
7
8
9


git fetch origin
git diff origin/main..origin/feature-branch \
 --unified=0 \
 ':!CHANGELOG.md' \
 ':!package-lock.json' \
 ':!yarn.lock' \
 ':!*.lock' \
 ':!*.md' \
 > pr_changes.txt

This command:

Fetches the latest changes
Compares the main branch to the feature branch
Shows only changed lines without context
Excludes specific files and file types
Outputs the result to a file

Warning: if PR does not contain the certain file types, you may need to remove the exclusion patterns or you get an error like fatal: :!yarn.lock: no such path in the working tree.. You need to remove ':!yarn.lock' from the command.

Customizing Your Git Diff Approach

The beauty of this method lies in its flexibility. You can easily modify the exclusion patterns to suit your project’s needs. For example, to exclude all JSON files, add :!*.json to the list.

Implementing the Advanced Git Diff Technique

After running the advanced command, you’ll have a pr_changes.txt file containing a focused diff of your pull request. You can:

Review the changes directly in this file
Share the file with team members for collaborative review
Use the content with AI tools for automated analysis without context limit concerns

For a quick overview, use:

1

head -n 50 pr_changes.txt

This displays the first 50 lines of the diff, giving you a snapshot of the changes.

Conclusion

By mastering these advanced git diff techniques, I see a significant improvement in my pull request analysis process. I can focus on the relevant code changes, ignore unnecessary files, and collaborate more effectively with my team. I hope this guide helps you streamline your pull request reviews and enhances your overall development workflow.

Cheers! 🍺

Essential VS Code Shortcuts for Efficient Coding

Yoonsoo Park — Sat, 21 Sep 2024 00:00:00 +0000

Boost your productivity with these cool VS Code shortcuts that every developer should know.

Visual Studio Code Keyboard Shortcuts Reference

As developers, we’re always obsessed with ways to streamline our workflow and boost productivity. Visual Studio Code (VS Code) offers numerous shortcuts to help us code more efficiently. In this article, we’ll explore some cool VS Code shortcuts that can significantly improve your coding experience.

Quick Reference Table

Function	Mac	Windows/Linux
Jump to Matching Bracket	Cmd + Shift + \	Ctrl + Shift + \
Scroll Without Moving Cursor	Ctrl + Fn + Up/Down Arrow	Ctrl + Up/Down Arrow
Show/Hide Terminal	Cmd + J	Ctrl + J
Expand/Shrink Selection	Ctrl + Shift + Left/Right Arrow	Shift + Alt + Left/Right Arrow
Change Tab	Cmd + Opt + Left/Right Arrow	Ctrl + PgUp/PgDn
Find Symbol	Cmd + T	Ctrl + T
Multi-Cursor (select next occurrence)	Cmd + D	Ctrl + D
Multi-Cursor (add above/below)	Cmd + Option + Up/Down Arrow	Ctrl + Alt + Up/Down Arrow
Quick File Navigation	Cmd + P	Ctrl + P
Toggle Line Comment	Cmd + /	Ctrl + /
Rename Symbol	F2	F2
Open Command Palette	Cmd + Shift + P	Ctrl + Shift + P

Detailed Explanations

Jump to Matching Bracket
- Mac: Cmd + Shift + \
- Windows/Linux: Ctrl + Shift + \
Quickly navigate between opening and closing brackets in nested code structures.

Jump Multiple Lines Vertically (Custom shortcut)

Requires configuration in keybindings.json:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


{
 "key": "ctrl+up",
 "command": "cursorMove",
 "args": {
 "to": "up",
 "by": "line",
 "value": 10
 },
 "when": "editorTextFocus"
},
{
 "key": "ctrl+down",
 "command": "cursorMove",
 "args": {
 "to": "down",
 "by": "line",
 "value": 10
 },
 "when": "editorTextFocus"
},

Move the cursor 10 lines up or down at once for faster navigation in large files.

Scroll Without Moving the Cursor
- Mac: Ctrl + Fn + Up Arrow / Down Arrow
- Windows/Linux: Ctrl + Up Arrow / Down Arrow
Scroll through your code while keeping your cursor in the same position.
Show/Hide Terminal
- Mac: Cmd + J
- Windows/Linux: Ctrl + J
Quickly toggle the integrated terminal for running commands.
Expand/Shrink Selection
- Mac: Ctrl + Shift + Left Arrow / Right Arrow
- Windows/Linux: Shift + Alt + Left Arrow / Right Arrow
Expand or shrink your selection based on code structure.
Change Tab
- Mac: Cmd + Opt + Left / Right Arrow
- Windows/Linux: Ctrl + PgUp / PgDn
Quickly switch between open tabs in your editor.
Find Symbol
- Mac: Cmd + T
- Windows/Linux: Ctrl + T
Find classes, functions, or properties anywhere in your current editor session with fuzzy search.
Multi-Cursor Editing
- Select next occurrence:
  - Mac: Cmd + D
  - Windows/Linux: Ctrl + D
- Add cursor above/below:
  - Mac: Cmd + Option + Up Arrow / Down Arrow
  - Windows/Linux: Ctrl + Alt + Up Arrow / Down Arrow
Edit multiple occurrences of text simultaneously.
Quick File Navigation
- Mac: Cmd + P
- Windows/Linux: Ctrl + P
Open files in your project by typing part of the file name.
Toggle Line Comment
- Mac: Cmd + /
- Windows/Linux: Ctrl + /
Quickly comment or uncomment lines of code.
Rename Symbol
- Mac/Windows/Linux: F2
Rename variables, functions, or classes across your entire project.
Open Command Palette
- Mac: Cmd + Shift + P
- Windows/Linux: Ctrl + Shift + P
Access all of VS Code’s commands quickly.

By mastering these shortcuts, you’ll be able to navigate, edit, and manage your code more efficiently in VS Code. Remember, this allows you to work smarter but also other devs see you as a “pro”. wink wink.

Cheers! 🍺

Transform Your Python Scripts into Global Command-Line Tools

Yoonsoo Park — Sat, 14 Sep 2024 00:00:00 +0000

Learn how to make your Python scripts accessible from anywhere on your system, enhancing convenience and productivity.

Python Official Documentation

Transform Your Python Scripts into Global Command-Line Tools

Have you ever created a useful Python script and wished you could run it from any directory on your computer? In this article, we’ll explore how to transform a Python script into a command-line tool that can be launched from anywhere on your local disk. We’ll use a “Code Collector” tool as an example, but these principles apply to any Python script you want to make more accessible.

Why Make Your Script Globally Accessible?

Before we dive into the how-to, let’s consider why you might want to make your script launchable from anywhere:

Convenience: Run your tool without navigating to its directory.
Integration: Easily incorporate your script into other scripts or workflows.
Professionalism: Transform your script into a proper command-line tool.

Steps to Make Your Script Globally Accessible

1. Make Your Script Executable

First, ensure your script is executable. On Unix-based systems (Linux, macOS), use the following command:

1

chmod +x code_collector.py

This command gives your script execute permissions.

2. Add a Shebang Line

At the very top of your Python script, add this line:

1

#!/usr/bin/env python3

This “shebang” line tells the system to use Python to interpret this file.

3. Create a Symbolic Link

To make your script accessible from anywhere, create a symbolic link in a directory that’s in your system’s PATH. On Unix-based systems:

1

sudo ln -s /path/to/code_collector.py /usr/local/bin/code-collector

Replace /path/to/code_collector.py with the actual path to your script.

4. For Windows Users

On Windows, the process is slightly different:

Add the directory containing your script to the system’s PATH environment variable.
Create a batch file named code-collector.bat in the same directory as your Python script with this content:

1
2


@echo off
python "%~dp0code_collector.py" %*

Using Your Globally Accessible Script

After following these steps, you can run your script from any directory by simply typing:

1

code-collector

You can also add command-line arguments, like:

1

code-collector -p /path/to/repo -o /path/to/output

Common Questions

Q: After updating the Python code, should I run `chmod` and `ln` commands again?

A: No, you don’t need to run these commands every time you update your script. The file permissions and symbolic link remain valid unless explicitly changed or the file is moved.

Q: How do I interpret ‘-rwxr-xr-x’?

A: This string represents file permissions in Unix-like systems:

The first ‘-’ indicates it’s a regular file.
‘rwx’ shows the owner’s permissions (read, write, execute).
‘r-x’ shows the group’s permissions (read, execute, but not write).
‘r-x’ shows everyone else’s permissions (read, execute, but not write).

Conclusion

By following these steps, you’ve transformed your Python script into a globally accessible command-line tool. This approach not only makes your script more convenient to use but also integrates it seamlessly into your system.

Remember, this method isn’t just for the Code Collector tool – you can apply these principles to any Python script you want to access globally.

Cheers! 🍺

Resolving 'No Default Dev Hub' Error When Creating Salesforce Scratch Orgs

Yoonsoo Park — Mon, 26 Aug 2024 00:00:00 +0000

Learn how to fix the ‘No Default Dev Hub’ error when creating Salesforce scratch orgs using Salesforce CLI, with step-by-step solutions and explanations.

Salesforce Developer Documentation

As a Salesforce developer, you’re likely familiar with the power and flexibility of scratch orgs for development and testing. However, you may occasionally encounter errors when trying to create these temporary environments. One common issue is the “No Default Dev Hub” error, which can be frustrating if you’re not sure how to resolve it. In this article, we’ll explore this error and provide two straightforward solutions to get you back on track.

The Problem: No Default Dev Hub Error

Let’s say you’re trying to create a scratch org using the Salesforce CLI with a command like this:

1

sf org create scratch --definition-file=config/project-scratch-def.json --alias=my-scratch --set-default --duration-days=30 --wait=15

But instead of creating your scratch org, you’re met with this error:

Error (NoDefaultDevHubError): No default dev hub found. Use -v or --target-dev-hub to specify an environment.

This error occurs when the Salesforce CLI can’t find a default DevHub to use for creating your scratch org. Even if you have a DevHub set up and can see it when you run sf org list, the CLI may not know which one to use by default.

Solution 1: Set a Default DevHub

The first and most straightforward solution is to set a default DevHub for your Salesforce CLI to use. Here’s how:

First, identify your DevHub username. You can find this by running sf org list. Look for the org with the “DevHub” type.
Once you have the username, set it as the default DevHub with this command:
1

sf config set target-dev-hub your-devhub-username@example.com
Replace your-devhub-username@example.com with your actual DevHub username.
After setting the default, you should be able to run your original scratch org creation command without any issues.

This method is particularly useful if you primarily work with one DevHub, as you won’t need to specify it every time you create a scratch org.

Solution 2: Specify the DevHub in Your Command

If you work with multiple DevHubs or prefer not to set a default, you can explicitly specify which DevHub to use in your scratch org creation command. Here’s how:

Modify your original command to include the -v or --target-dev-hub flag, followed by your DevHub username:
1

sf org create scratch --definition-file=config/project-scratch-def.json --alias=my-scratch --set-default --duration-days=30 --wait=15 -v your-devhub-username@example.com
Again, replace your-devhub-username@example.com with your actual DevHub username.
Run this modified command, and it should create your scratch org without the “No Default Dev Hub” error.

This method gives you more flexibility if you need to switch between different DevHubs for various projects or teams.

Conclusion

The “No Default Dev Hub” error is a common hurdle in Salesforce development, but it’s easily overcome with these simple solutions. Whether you choose to set a default DevHub or specify it in each command, you’ll be able to create scratch orgs smoothly and continue your development work without interruption.

Cheers! 🍺

Mastering Python Package Management - A Guide to Updating and Verifying Your Packages

Yoonsoo Park — Thu, 22 Aug 2024 00:00:00 +0000

Learn how to keep your Python packages up-to-date and verify their versions for secure and efficient development.

Python Package Index (PyPI)

Mastering Python Package Management: A Guide to Updating and Verifying Your Packages

In the fast-paced world of Python development, staying up-to-date with your packages is crucial for maintaining secure, efficient, and bug-free applications. This guide will walk you through the essential steps of updating your Python packages and verifying their versions, ensuring you’re always working with the latest and greatest tools.

Updating Python Packages

Once you’ve installed a Python package using pip, you might wonder how to keep it current. The process is straightforward:

Open your terminal or command prompt.
Use the following command to update a package:
```
pip install --upgrade package_name
```
Replace package_name with the name of the package you want to update.

For example, to update a package called “requests”, you would run:

pip install --upgrade requests

This command fetches the latest version of the package from the Python Package Index (PyPI) and installs it, replacing the older version.

Verifying Package Versions

After updating, it’s a good practice to verify that you’re running the latest version. Here’s how you can do that:

1. Check the Installed Version

To see the currently installed version of a package, use the pip show command:

pip show package_name

This displays information about the package, including its version number.

2. Check the Latest Available Version

To see all available versions of a package, including the latest, use:

pip index versions package_name

The output will show all available versions, with the most recent typically at the top.

3. Compare Versions

Compare the installed version (from step 1) with the latest available version (from step 2) to ensure you’re up-to-date.

4. Automated Check for Outdated Packages

For a quick overview of all installed packages that have updates available, use:

pip list --outdated

This command displays a list of packages with newer versions available, showing both the current and latest versions.

Best Practices

Regularly update your packages to benefit from bug fixes, security patches, and new features.
Before updating packages in a production environment, test the updates in a development or staging environment to ensure compatibility.
Use virtual environments to isolate project dependencies and avoid conflicts between different projects.
- Setting Up Virtual Environments for Multiple Python Versions
Keep an eye on the changelogs or release notes of critical packages to understand what’s new in each update.

Cheers! 🍺

How to Ignore Files Locally in Git Without Modifying .gitignore

Yoonsoo Park — Sun, 18 Aug 2024 00:00:00 +0000

Learn how to use .git/info/exclude to ignore files locally in Git without affecting the shared .gitignore file

Git Documentation

Have you ever needed to ignore certain files or directories in your Git project, but didn’t want to modify the shared .gitignore file? Perhaps you have some local development files or personal IDE settings that you don’t want to track, but also don’t want to burden your team with. There’s a simple solution for this: the .git/info/exclude file.

Using .git/info/exclude

The .git/info/exclude file works just like .gitignore, but it’s not tracked by Git. This means you can add custom ignore rules that apply only to your local repository without affecting other team members or the remote repository.

Here’s how to use it:

Navigate to your project’s root directory.
Open the .git/info/exclude file in your favorite text editor. If it doesn’t exist, create it.
Add your custom ignore rules to this file, one per line.

For example, you might add:

# Ignore local development environment file
.env.local
# Ignore personal IDE settings
.vscode/
# Ignore a specific local directory
local_scripts/

These rules will apply only to your local repository and won’t be committed or pushed to the remote repository.

Benefits of Using .git/info/exclude

Keeps your personal ignore rules separate from the project’s shared rules.
Avoids cluttering the shared .gitignore file with personal preferences.
Prevents conflicts that might arise from different team members having different ignore needs.

When to Use .gitignore vs .git/info/exclude

Use .gitignore for ignore rules that should apply to all copies of the repository.
Use .git/info/exclude for personal ignore rules that are specific to your local setup.

By leveraging .git/info/exclude, you can maintain a clean and personalized local Git environment without affecting your team’s workflow. It’s a simple yet powerful feature that every Git user should know about.

Cheers! 🍺

Mastering Generative AI for Efficient Software Development

Yoonsoo Park — Mon, 12 Aug 2024 00:00:00 +0000

In the dynamic landscape of software development, integrating generative AI tools can revolutionize project workflows. The ability of these AI models to understand context, adapt to roles, and interact in a human-like manner makes them invaluable assets. This article provides a comprehensive guide to embedding generative AI into your software development process, highlighting its role in three key phases: Project Management, Architectural Design, and Software Engineering.

Key Insight: For optimal results, conduct these phases within a single session with your chosen AI tool, as most cannot retain information across sessions.

Phase 1: Project Management

Goal: Establish a robust project framework by precisely defining and refining project scope and requirements.

Method:

Initiation:
- Clearly define your project goals, objectives, and constraints to the AI, instructing it to assume the role of an AI project manager.
- Ensure the AI fully comprehends your project’s vision and requirements, fostering a collaborative relationship.
Requirement Gathering:
- Engage in a fluid discussion with the AI to refine requirements, prompting it to ask for clarifications as a skilled project manager would.
- Leverage the AI’s analytical capabilities to verify that requirements align with business goals and technical feasibility.
Specification Drafting:
- Task the AI with creating a detailed project specification or proposal based on the refined requirements.
- Iteratively refine the document for clarity and actionability.

Project Manager Role Template:

You are an Experienced Software Project Manager
Context: [Brief description of your project]
Tasks:
1. Review and refine the following project requirements:
[List your initial requirements here]
2. Ask clarifying questions to ensure a comprehensive understanding of the project scope.
3. Analyze the requirements for alignment with business goals and technical feasibility.
4. Provide recommendations for requirement improvements or additions.
5. Draft a concise project specification based on our discussion, including:
- Project objectives
- Scope
- Key deliverables
- Resource requirements
- Potential risks and mitigation strategies
Please proceed step by step, starting with reviewing the requirements and asking any necessary questions.

Phase 2: Architectural Design

Goal: Develop a robust and adaptable technical blueprint for the system.

Method:

Architectural Analysis:
- Present the project specifications to the AI, instructing it to adopt the role of a senior software architect.
- Engage the AI in a critical analysis of the plan, encouraging enhancements and questioning based on industry best practices.
Structure & Technology Stack Identification:
- Direct the AI to propose a file structure and identify necessary technologies and libraries, emphasizing scalability and performance.
- Request a thorough documentation of the architecture in a structured format like JSON or YAML.

Senior Software Architect Role Template:

You are a Senior Software Architect with expertise in [specific area, e.g., "automated data retrieval systems"]
Context: [Paste your project specification here]
Tasks:
1. Review the provided project specification and offer a critique based on current industry best practices.
2. Propose enhancements to the architectural plan, focusing on:
- Scalability
- Performance
- Security
- Maintainability
3. Outline a recommended file structure for the project.
4. Identify essential technologies and libraries needed for implementation, justifying each choice.
5. Document the proposed architecture in JSON format, including:
- System components
- Data flow
- Integration points
- Technology stack
- Deployment strategy
Please provide your analysis and recommendations step by step, starting with the review and critique of the project specification.

Phase 3: Software Engineering

Goal: Realize the architectural blueprint through precise coding and implementation.

Method:

Implementation Strategy:
- Introduce the architectural design to the AI, instructing it to assume the role of a senior software engineer.
- Plan the development sequence, prioritizing components as outlined in the architectural plan.
Pseudocode Development:
- Direct the AI to write detailed pseudocode for each module, specifying inputs, processes, and expected outputs.
- Ensure this pseudocode aligns with the overall architectural plan and project requirements.
Code Iteration:
- Progress from pseudocode to actual coding, adhering to best practices and the chosen programming language.
- Continuously refine and optimize the code for performance and functionality.

Senior Software Engineer Role Template:

You are a Senior Software Engineer specializing in [specific area, e.g., "automated data retrieval systems"]
Context: [Paste your architectural design here]
Tasks:
1. Review the provided architectural design and suggest an implementation strategy, including:
- Development sequence
- Priority of components
- Potential challenges and solutions
2. Develop detailed pseudocode for the following key modules:
[List the main modules or functions here]
For each module, include:
- Input parameters
- Process steps
- Expected outputs
- Error handling
3. Provide guidance on:
- Best practices for implementing this system
- Potential optimization techniques
- Testing strategies
4. Outline any additional considerations for ensuring the system aligns with the architectural framework and project requirements.
Please proceed step by step, starting with reviewing the architectural design and suggesting an implementation strategy.

By adopting this structured methodology and using these role-specific templates, you can fully leverage the capabilities of generative AI tools throughout your software development lifecycle.

The key is to provide clear, role-specific instructions that allow the AI to offer professional, context-aware responses. This approach ensures streamlined, innovative, and effective project delivery, harnessing the power of AI to enhance every stage of your software development process.

Cheers! 🍺

Efficient GitHub Cloning in AWS Lambda - Sparse Checkout to the Rescue

Yoonsoo Park — Wed, 31 Jul 2024 00:00:00 +0000

When working with AWS Lambda functions, you might encounter scenarios where you need to clone and analyze GitHub repositories. However, Lambda’s limited storage and execution time can pose challenges when dealing with large repositories. This article explores how to use Git’s sparse checkout feature to efficiently clone only the necessary files and folders, especially when working with specific tags in your GitHub repo.

The Challenge: Large Repositories in AWS Lambda

AWS Lambda functions have constraints on storage (512MB in /tmp) and execution time (15 minutes maximum). When you need to clone a large GitHub repository to analyze its contents, you might quickly hit these limits. This is particularly problematic when you only need a small portion of the repository for your analysis.

Real-Life Example: Analyzing Metadata Changes

Imagine you’re building a Lambda function to analyze metadata changes between different versions of a Salesforce package stored in a GitHub repository. You need to clone the repository, checkout specific tags, and compare the metadata files. However, the repository contains numerous files unrelated to your analysis, making a full clone impractical.

Solution: Sparse Checkout with Specific Tags

Git’s sparse checkout feature allows you to selectively checkout only the files and directories you need. By combining this with the ability to fetch specific tags, we can create an efficient solution for working with large repositories in Lambda functions.

Here’s how we implemented this solution:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


@staticmethod
def efficient_clone_and_checkout(git_url, target_dir, tag):
 try:
 # Initialize a new repository
 repo = git.Repo.init(target_dir)

 # Create the sparse-checkout file directory if it doesn't exist
 sparse_checkout_dir = os.path.join(repo.git_dir, 'info')
 os.makedirs(sparse_checkout_dir, exist_ok=True)

 # Create a remote named 'origin'
 origin = repo.create_remote('origin', git_url)

 # Enable sparse checkout
 repo.git.config('core.sparsecheckout', 'true')

 # Define the files and folders we want
 sparse_checkout_path = os.path.join(sparse_checkout_dir, 'sparse-checkout')
 with open(sparse_checkout_path, 'w') as f:
 f.write('sfdx-project.json\n')
 f.write('src/\n')

 # Fetch only the specific tag
 origin.fetch(f'+refs/tags/{tag}:refs/tags/{tag}', depth=1)

 # Checkout the tag
 repo.git.checkout(f'tags/{tag}')

 # Verify the sfdx-project.json file exists
 sfdx_project_path = os.path.join(target_dir, 'sfdx-project.json')
 if not os.path.exists(sfdx_project_path):
 raise FileNotFoundError(f"sfdx-project.json not found at {sfdx_project_path}")

 return repo

 except Exception as e:
 # Clean up the target directory if something goes wrong
 if os.path.exists(target_dir):
 shutil.rmtree(target_dir)
 raise Exception(f"Failed to clone and checkout repository: {str(e)}")

This function does several key things:

Initializes a new Git repository in the target directory.
Sets up sparse checkout to only fetch the sfdx-project.json file and the src/ directory.
Fetches only the specified tag with a depth of 1, minimizing data transfer.
Checks out the specified tag.
Verifies that the essential sfdx-project.json file exists.

By using this approach, we significantly reduce the amount of data transferred and stored, making it feasible to work with large repositories within Lambda’s constraints.

Implementing the Solution

To use this solution in your Lambda function, you can call the efficient_clone_and_checkout method like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


def lambda_handler(event, context):
 git_url = "https://github.com/your-org/your-repo.git"
 target_dir = "/tmp/repo"
 tag = "v1.0.0"

 try:
 repo = MetamanUtil.efficient_clone_and_checkout(git_url, target_dir, tag)
 # Perform your analysis on the cloned repository
 # ...
 except Exception as e:
 print(f"An error occurred: {str(e)}")
 return {
 'statusCode': 500,
 'body': json.dumps('Error processing repository')
 }

 return {
 'statusCode': 200,
 'body': json.dumps('Successfully processed repository')
 }

This approach allows you to efficiently clone and analyze specific parts of a large repository, even within the constraints of AWS Lambda.

Wrapping it up 👏

Handling large GitHub repositories in AWS Lambda functions can be challenging, but using Git’s sparse checkout feature provides an elegant solution. By cloning only the necessary files and fetching specific tags, we can significantly reduce data transfer and storage requirements.

Keep coding and stay efficient! Cheers! 🍺

Why `forEach` Cannot Handle Async - A Real-Life Example and Solutions

Yoonsoo Park — Sat, 22 Jun 2024 00:00:00 +0000

In JavaScript, handling asynchronous operations can be tricky, especially when dealing with collections of data. One common pitfall is using the forEach method for asynchronous tasks. This article explains why forEach cannot handle async operations properly and presents solutions using for...of loops or the map method combined with Promise.all.

The Problem with `forEach` and Async

The forEach method is great for iterating over arrays, but it doesn’t handle asynchronous operations as you might expect. When you use forEach with an async function, it does not wait for the promises to resolve before moving on to the next iteration. This can lead to unexpected behavior and incomplete operations.

Real-Life Example: Uploading Files

Imagine you are building a file upload feature that processes and uploads multiple files to a server. You might think using forEach with an async function is a good approach. Let’s see what happens when you do this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


async function uploadFiles(filePaths) {
 filePaths.forEach(async (filePath) => {
 const fileContent = await readFile(filePath); // Assume readFile is a function that reads file content
 await uploadToServer(fileContent); // Assume uploadToServer is a function that uploads the file content
 console.log(`Uploaded ${filePath}`);
 });
 console.log("All files uploaded");
}

const files = ["file1.txt", "file2.txt", "file3.txt"];
uploadFiles(files);

You might expect to see log messages for each file upload followed by “All files uploaded”, but instead, you’ll likely see “All files uploaded” before any individual file upload messages. (surprise!) This happens because forEach does not wait for the async operations to complete.

Solution 1: Using `for...of` Loop

A more reliable way to handle asynchronous operations in a loop is using the for...of statement. This approach ensures that each iteration waits for the async operations to finish before moving on to the next one.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


async function uploadFiles(filePaths) {
 for (const filePath of filePaths) {
 const fileContent = await readFile(filePath); // Assume readFile is a function that reads file content
 await uploadToServer(fileContent); // Assume uploadToServer is a function that uploads the file content
 console.log(`Uploaded ${filePath}`);
 }
 console.log("All files uploaded");
}

const files = ["file1.txt", "file2.txt", "file3.txt"];
uploadFiles(files);

With this approach, you will see each file upload log message in sequence, followed by “All files uploaded” at the end, as expected.

Solution 2: Using `map` with `Promise.all`

Another solution is to use the map method to create an array of promises and then wait for all of them to resolve using Promise.all. This approach is useful when you want to perform async operations in parallel.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


async function uploadFiles(filePaths) {
 const uploadPromises = filePaths.map(async (filePath) => {
 const fileContent = await readFile(filePath); // Assume readFile is a function that reads file content
 await uploadToServer(fileContent); // Assume uploadToServer is a function that uploads the file content
 console.log(`Uploaded ${filePath}`);
 });

 await Promise.all(uploadPromises);
 console.log("All files uploaded");
}

const files = ["file1.txt", "file2.txt", "file3.txt"];
uploadFiles(files);

This code will log the upload messages for each file, potentially out of order, but “All files uploaded” will be logged only after all files have been processed.

Wrapping it up 👏

Handling asynchronous operations in JavaScript requires careful consideration, especially when dealing with loops. The forEach method is not suitable for async tasks because it does not wait for promises to resolve. Instead, use for...of loops to handle async operations sequentially or map with Promise.all to handle them in parallel.

Another day to learn another stuff! Life is wonderful. Cheers! 🍺

Automating Salesforce Package Deployment with AWS Code Services - A Comprehensive Guide

Yoonsoo Park — Sat, 15 Jun 2024 00:00:00 +0000

AWS provides a comprehensive suite of services known as AWS Code* for application development and deployment. These services, including AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy, simplify the CI/CD process. In this blog post, we will explore the functionality of each service and demonstrate their usage through a practical example: deploying a Salesforce package.

What is AWS CodePipeline?

AWS CodePipeline is a continuous delivery service that automates the build, test, and deploy phases of your release process. It orchestrates the steps required to release your software changes, integrating with various services like GitHub, CodeBuild, CodeDeploy, and third-party tools.

Key Features

Automated Workflow: Automates steps required to release software changes.
Integration: Integrates seamlessly with AWS services and third-party tools.
Customizable: Allows for custom workflows and stages.

What is AWS CodeBuild?

AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages ready for deployment. It eliminates the need to manage and scale your own build servers.

Key Features

Fully Managed: No need to manage build servers.
Scalable: Handles multiple builds concurrently.
Customizable: Use pre-built environments or create custom ones with Docker images.

What is AWS CodeDeploy?

AWS CodeDeploy automates code deployments to any instance, including Amazon EC2 instances, on-premises servers, or AWS Lambda. It helps ensure that your application is updated with minimal downtime.

Key Features

Automated Deployments: Automates the deployment process.
Minimize Downtime: Supports deployment strategies like rolling updates and blue/green deployments.
Versatile: Works with various deployment targets including EC2, on-premises servers, and Lambda functions.

Automating Salesforce Package Deployment with AWS Code Services: A Step-by-Step Guide

Let’s explore how you can automate the deployment of a Salesforce package using AWS Code services. Follow these steps to streamline your CI/CD process:

Code Update and Merge in GitHub: Developers push code updates to the force-npower repository on GitHub. When changes are merged into the release branch, it triggers a GitHub Action.
GitHub Action Trigger: The GitHub Action starts the CI/CD pipeline by triggering an AWS CodePipeline.
Source Stage (AWS CodePipeline): The pipeline’s source stage detects the code change in the release branch and pulls the latest code from the GitHub repository.
Build Stage (AWS CodeBuild): CodePipeline triggers a build using AWS CodeBuild. CodeBuild compiles the source code, runs tests, and packages the code into a Salesforce package.
Artifact Storage: The generated Salesforce package is stored in an S3 bucket.
Approval Stage (AWS CodePipeline): A manual approval step ensures that a human reviewer checks the build artifacts before deployment.
Deploy Stage (AWS CodeDeploy/AWS Lambda): Once approved, the package is deployed to a Salesforce instance or notified as ready for installation.

Detailed Steps

GitHub Repository (force-npower):
- Developers commit and push changes to branches.
- When changes are merged into the release branch, a GitHub Action triggers the AWS CodePipeline.

GitHub Action:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


name: Trigger AWS CodePipeline
on:
 push:
 branches:
 - release
jobs:
 trigger-pipeline:
 runs-on: ubuntu-latest
 steps:
 - name: Trigger AWS CodePipeline
 uses: aws-actions/aws-codepipeline-action@v1
 with:
 name: your-pipeline-name
 region: us-east-1

AWS CodePipeline:

Source Stage: Configured to detect changes in the release branch of the GitHub repository.
Build Stage: Uses CodeBuild to compile, test, and package the Salesforce code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


const pipeline = new codepipeline.Pipeline(this, "Pipeline", {
 pipelineName: "SalesforcePipeline",
 stages: [
 {
 stageName: "Source",
 actions: [
 new codepipeline_actions.GitHubSourceAction({
 actionName: "GitHub_Source",
 owner: "your-github-username",
 repo: "force-npower",
 branch: "release",
 oauthToken: cdk.SecretValue.secretsManager("github-token"),
 output: sourceOutput,
 }),
 ],
 },
 {
 stageName: "Build",
 actions: [
 new codepipeline_actions.CodeBuildAction({
 actionName: "CodeBuild",
 project: buildProject,
 input: sourceOutput,
 outputs: [buildOutput],
 }),
 ],
 },
 {
 stageName: "Approval",
 actions: [
 new codepipeline_actions.ManualApprovalAction({
 actionName: "ManualApproval",
 }),
 ],
 },
 {
 stageName: "Deploy",
 actions: [
 new codepipeline_actions.LambdaInvokeAction({
 actionName: "DeployToSalesforce",
 lambda: deployLambdaFunction,
 inputs: [buildOutput],
 }),
 ],
 },
 ],
});

AWS CodeBuild:

Build Project: Defines the environment and build specifications for creating the Salesforce package.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


const buildProject = new codebuild.PipelineProject(this, "BuildProject", {
 environment: {
 buildImage: codebuild.LinuxBuildImage.STANDARD_5_0,
 environmentVariables: {
 PACKAGE_NAME: { value: "SalesforcePackage" },
 },
 },
 buildSpec: codebuild.BuildSpec.fromObject({
 version: "0.2",
 phases: {
 install: {
 commands: ["npm install", "sfdx plugins:install salesforcedx"],
 },
 build: {
 commands: [
 "sfdx force:source:convert -d output",
 'sfdx force:package:create --name "MyPackage" --path output',
 ],
 },
 },
 artifacts: {
 files: ["**/*"],
 "base-directory": "output",
 },
 }),
});

Artifact Storage:
- The built package is stored in an S3 bucket, making it accessible for deployment or manual download.
Approval Stage:
- A manual approval action ensures that someone reviews and approves the build before deployment.

Deploy Stage:

AWS Lambda can be used to automate the deployment to Salesforce or to notify stakeholders.

1
2
3
4
5
6
7
8


const deployLambdaFunction = new lambda.Function(this, "DeployFunction", {
 runtime: lambda.Runtime.NODEJS_14_X,
 handler: "index.handler",
 code: lambda.Code.fromAsset("lambda"),
 environment: {
 PACKAGE_NAME: "SalesforcePackage",
 },
});

Wrapping it up 👏

AWS Code* services like CodePipeline, CodeBuild, and CodeDeploy are awesome for automating CI/CD. They integrate smoothly with GitHub and Salesforce, making it easy to test, package, and deploy code changes. Say goodbye to manual work and hello to faster releases and fewer errors. These tools are perfect for modern development practices, whether you’re working on regular apps or Salesforce packages.

Cheers! 🍺

Understanding Record Types and RecordTypeId in Salesforce for Beginners

Yoonsoo Park — Tue, 04 Jun 2024 00:00:00 +0000

In the ecosystem of Salesforce, understanding how to use RecordType and RecordTypeId is key for customizing and managing your CRM to meet the business needs. This article provides a beginner-friendly explanation of these concepts, along with a real-life example to illustrate their practical application.

What are Record Types?

Record Types in Salesforce allows administrators to define different sets of picklist values, page layouts, and business processes for different users within the same object. (within the same object is the key) They are essential for organizations that require the flexibility to cater to various business scenarios using a single Salesforce object, such as Accounts or Opportunities.

Why Use RecordTypeId?

RecordTypeId is a specific field in Salesforce records that links each record to its corresponding Record Type. This link ensures that the appropriate business rules, layouts, and options are applied to the record. Understanding RecordTypeId is important for data management (when importing or exporting data) as it determines how the data conforms to different business processes.

Real-Life Example: Managing Business and Individual Accounts

Scenario

A financial institution(FI) uses Salesforce to manage two types of customer accounts: Business Accounts and Individual Accounts. Each type of account has different processes and requirements:

Business Accounts need fields like Annual Revenue and Industry Type.
Individual Accounts require personal information such as Date of Birth and Personal Income.

Setting Up Record Types

Here’s how a Salesforce administrator might set up record types for these accounts:

Navigate to Setup: Go to the Object Manager in Salesforce Setup and select the Account object.
Create New Record Types:
- Business Account Record Type:
  - Label: Business Account
  - Name: Business_Account
  - Page Layout: Business Account Layout
- Individual Account Record Type:
  - Label: Individual Account
  - Name: Individual_Account
  - Page Layout: Individual Account Layout

Each record type will automatically be assigned a unique RecordTypeId by Salesforce, which is used to identify the record type of specific account records programmatically.

Practical Data Management

CSV Import Example

Suppose the FI wants to import account data from a CSV file. The CSV might include a column for RecordType.DeveloperName to specify which record type each account should have:

1
2
3


Name, Type, Industry, RecordType.DeveloperName
Acme Corp, Business, Manufacturing, Business_Account
John Doe, Individual, Healthcare, Individual_Account

Automating RecordTypeId Conversion

When importing this data, Salesforce admins need to ensure that RecordType.DeveloperName is correctly mapped to the RecordTypeId. Here’s a simplified script that might be used:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


// Sample script to convert RecordType Developer Names to RecordTypeId
const records = [
 {
 Name: "Acme Corp",
 Type: "Business",
 Industry: "Manufacturing",
 RecordTypeDeveloperName: "Business_Account",
 },
 {
 Name: "John Doe",
 Type: "Individual",
 Industry: "Healthcare",
 RecordTypeDeveloperName: "Individual_Account",
 },
];

records.forEach((record) => {
 record.RecordTypeId = resolveRecordTypeId(record.RecordTypeDeveloperName);
 delete record.RecordTypeDeveloperName; // Clean up the original field
});

function resolveRecordTypeId(developerName) {
 // Example function to map developer names to RecordTypeIds
 const idMap = {
 Business_Account: "012XXXX00000XXXX",
 Individual_Account: "012XXXX00000YYYY",
 };
 return idMap[developerName] || null;
}

This script ensures that each record is associated with the correct RecordTypeId, facilitating accurate data import aligned with the designated business processes.

Cheers! 🍺

Understanding Salesforce APIs - Metadata, Tooling, and Bulk

Yoonsoo Park — Sun, 05 May 2024 00:00:00 +0000

Salesforce offers a variety of APIs, each optimized for specific tasks within its ecosystem. It’s vital for developers and administrators to understand the differences and use cases of the Metadata API, Tooling API, and Bulk API for efficient management, customization, development, and integration. This article will explore these APIs with detailed explanations and practical examples.

Metadata API

Overview

The Metadata API is essential for managing the customization and configuration of Salesforce environments. It allows for the manipulation of the structure of data — everything from custom object definitions and page layouts to profiles and workflows.

Use Cases

Deployment of Customizations: Automating the movement of configurations from development environments to production.
Backup and Synchronization: Regularly exporting metadata for backup and ensuring consistency across multiple Salesforce orgs.
Continuous Integration: Facilitating automated deployments as part of CI/CD pipelines.

Real-life Scenarios

Deployment from Test to Production: Imagine a scenario where an enterprise needs to deploy updates from a test environment to production. The Metadata API can automate this process, allowing for seamless and error-free deployment of new fields, workflows, or entire applications, ensuring that all configurations are correctly replicated across environments.
Backup and Recovery: Metadata API can be used to create a backup of the organization’s metadata. In case of any accidental changes or deletions, the Metadata API can help restore the previous state, providing a safety net for your Salesforce configurations.
Scripted Changes: If an organization needs to make bulk changes to metadata (like updating the properties of multiple fields), instead of manually updating each one, a script can be written to use the Metadata API and make these changes all at once, saving time and reducing the chance of errors.
Third-party Integration: Metadata API can be used to integrate Salesforce with third-party tools for various purposes like continuous integration, version control, and change management. This allows for a more streamlined and efficient development process.

Tooling API

Overview

The Tooling API is designed for developers who need advanced capabilities directly related to the Salesforce development lifecycle. It’s particularly useful for interacting with the platform’s development and deployment features, such as source code, metadata during development, and testing frameworks.

Use Cases

Development Tools Integration: Creating plugins or custom tools that interact with the development environment.
Automated Development Tasks: Scripting repetitive tasks like updating Apex classes or compiling code.
Real-time Development Feedback: Providing developers with immediate feedback within IDEs or custom development tools.

Additional Real-life Scenarios

Automated Testing: A developer can use the Tooling API to automate the execution of Apex tests and retrieve the results. This can be integrated into a continuous integration pipeline to ensure code quality and prevent regressions.
Dynamic Code Analysis: The Tooling API can be used to retrieve the code coverage results after running tests. This allows developers to identify areas of the code that are not adequately tested and improve their test coverage.
IDE Integration: Integrated Development Environments (IDEs) like Visual Studio Code or IntelliJ can use the Tooling API to provide features like syntax highlighting, code completion, and real-time error checking for Apex code.
Code Refactoring: The Tooling API can be used to perform bulk changes to Apex code, such as renaming variables or methods across multiple files. This can greatly simplify the process of refactoring and ensure consistency across the codebase.

Bulk API

Overview

The Bulk API is optimized for handling large data sets, ideal for operations that involve loading or deleting vast amounts of data asynchronously. It’s designed to maximize processing speed and efficiency.

Use Cases

Large Data Imports/Exports: Efficiently managing large-scale data migrations or integrations.
Regular Data Synchronization: Syncing massive datasets between Salesforce and external systems regularly.
Data Backup: Conducting full or incremental backups of large data volumes.

Additional Real-life Scenarios

Data Migration: If a company is transitioning to Salesforce from another CRM, they might need to import large amounts of existing data into Salesforce. The Bulk API is designed to handle such large-scale data migrations efficiently.
Periodic Data Sync: A company might have other systems (like ERP or marketing automation) that need to sync data with Salesforce periodically. If the data volumes are large, the Bulk API can be used to perform these sync operations in an efficient manner.
Data Cleaning: If a company needs to perform large-scale data cleaning operations (like updating or deleting multiple records based on certain criteria), the Bulk API can be used to perform these operations in bulk, saving time and reducing the load on the system.
Reporting and Analytics: For generating large reports or performing complex analytics that involve processing large volumes of data, the Bulk API can be used to extract the data from Salesforce efficiently.

Wrapping it up 👏

In conclusion, Salesforce offers a suite of powerful APIs, each designed for specific tasks. The Metadata API is ideal for managing configurations and deployments, the Tooling API enhances the development process with features like automated testing and code refactoring, and the Bulk API is designed for handling large data operations efficiently.

Best practice guidelines include using the Metadata API for deployment and configuration tasks, leveraging the Tooling API for development and testing tasks, and utilizing the Bulk API for large-scale data operations. By aligning the use of these APIs with their intended purposes, you can ensure efficient and robust management of your Salesforce environments.

Cheers! 🍺

Leveraging NPX and NVM for Efficient Backend Development

Yoonsoo Park — Tue, 30 Apr 2024 00:00:00 +0000

The backend dev landscape demands efficiency and adaptability, especially for Node.js devs juggling multiple Node versions and packages. Enter NPX (Node Package Execute) and NVM (Node Version Manager) - a powerful duo streamlining Node env and package execution management. Let’s explore how synergizing NPX and NVM can supercharge your backend workflows, with a real-life example. Let’s go.

Understanding NPX and NVM

NPX is a NPM tool that lets devs run Node packages without global installs. It’s handy for executing binaries from Node modules and running packages that leave no trace after execution.

NVM, on the other hand, is a version manager that lets you install multiple Node.js versions and switch between them effortlessly. It’s crucial for testing apps across Node versions or maintaining projects tied to specific Node versions.

Real-Life Scenario: Streamlined Project Setup

Imagine a backend dev juggling legacy Node.js versions and modern standards for a new microservice. Here’s how NPX and NVM can help:

Setting Up the Development Environment:
- The developer can use nvm to switch between Node versions as needed. For instance, starting with Node 12 for compatibility testing:
  1 2
  
  nvm install 12 nvm use 12
- They then use npx to run a scaffolding tool like express-generator without installing it globally:
  1
  
  npx express-generator my-new-service
Development and Testing:
- As development progresses, testing on newer Node versions is necessary. Here, nvm allows easy switching:
  1
  
  nvm use 14
- Using npx, the developer can run local tests with tools like mocha without permanent installations:
  1
  
  npx mocha
CI/CD Integration:
- In a continuous integration setup, ensuring that the microservice builds and runs tests across all supported Node versions can be scripted using both nvm and npx:
  1 2
  
  nvm exec 12 npx npm test nvm exec 14 npx npm test

This isolates microservices from version conflicts and global deps, ensuring each is tested and deployed with the right Node env.

The Synergy Effect

The combination of NPX and NVM can significantly reduce setup times, avoid conflicts between differing Node module versions, and facilitate a cleaner development environment. Backend developers benefit from:

Flexibility in managing multiple Node.js environments.
Convenience of running any Node.js package executably without prior installation.
Efficiency in testing across different environments with minimal configuration changes.

Cheers! 🍺

How to Debug Salesforce Flows with Asynchronous Apex Methods

Yoonsoo Park — Sun, 28 Apr 2024 00:00:00 +0000

Debugging in Salesforce, especially when dealing with asynchronous operations like @Future methods, can be challenging. Properly setting up and analyzing debug logs is crucial to identify and resolve issues. This article guides you through the steps of debugging Salesforce flows that invoke asynchronous Apex methods, complete with a real-life example.

Step 1: Set Up Debug Logs

To ensure that you capture all relevant data, set up debug logging before you trigger the flow.

e.g.

1

System.debug('Hello, world!');

Navigate to Debug Logs:
- Go to Setup.
- In the Quick Find box, type “Debug Logs”.
- Under “Logs”, select “Debug Logs”.
Add User to Debug Logs:
- Click on “New” next to “User Trace Flags”.
- Select the user for whom you want to collect debug logs. This could be the user running the flow or an automated process.
- Set the “Start Date” and “End Date” to cover your testing period.
- Choose “User” for “Traced Entity Type”.
- Set “Apex Code” to “FINEST” to capture detailed Apex execution logs. Consider setting “System” and “Callout” to “FINE” or “FINEST” for comprehensive system operations and callouts logs.

Step 2: Trigger the Flow

Execute the flow that invokes the Apex method marked with the @Future annotation. Ensure:

Named credentials are properly configured if your HttpRequest relies on them.
The endpoint is reachable from your Salesforce org.

Step 3: Access the Debug Logs

After the flow execution, retrieve the logs:

Return to the Debug Logs menu as before.
View the Logs:
- Refresh the page to see new logs.
- Identify logs generated during your flow execution.
- Open logs in Salesforce Log Inspector or download them for detailed analysis.

Step 4: Analyze the Log

Locate entries linked to your Apex class and method:

Search for your Apex class or a distinctive feature name in the log.
Review System.debug lines to assess the execution of your method.
Check HTTP response details to verify external interactions.

Tips for Log Analysis

Adjust Log Levels: Increase detail level if necessary to capture all relevant data.
Manage Log Volume: High levels of logging can lead to voluminous data, making important details hard to find. Adjust your settings to focus on critical areas like Apex and callouts.

Real-Life Example

Let’s consider a scenario where an Apex method is set to run asynchronously after a specific user action in a Salesforce flow. The method is responsible for making HTTP callouts to an external service for data synchronization.

After setting up the debug logs as described and triggering the flow, you notice that the expected data isn’t syncing. Upon accessing the logs, you discover that the HTTP callout is returning an “Unauthorized” status. By checking the debug levels and ensuring that all settings, including named credentials, are correctly configured, you manage to resolve the authorization issues, leading to successful data synchronization in subsequent tests.

By following these detailed steps, Salesforce administrators and developers can efficiently troubleshoot and ensure their asynchronous processes function as expected.

Wrapping it up 👏 Debugging asynchronous Apex methods in Salesforce flows requires careful setup and analysis of debug logs. Crank up the log levels, analyze those breadcrumbs - watch Salesforce complexities unravel like a bad sweater.

Cheers! 🍺

How to Fork a Repository, Make Changes, and Update a Submodule in Your Main Project

Yoonsoo Park — Sat, 20 Apr 2024 00:00:00 +0000

How to Fork a Repository, Make Changes, and Update a Submodule in Your Main Project

Forking a repository on GitHub allows you to freely experiment with changes without affecting the original project. This is particularly useful in software development where you might want to customize a library, theme, or any other shared project to suit your own needs. In this blog, we will walk through the process of forking a repository, making updates, and then using those changes in a main project by updating a submodule.

Step 1: Forking a Repository

Forking creates a copy of someone else’s repository under your GitHub account, allowing you to make changes without impacting the original repo. Here’s how to fork a repository:

Navigate to the Repository: Go to the GitHub page of the repository you want to fork.
Fork the Repository: Click the “Fork” button usually located at the top right of the page. This action will create a copy of the repository in your GitHub account.

Step 2: Cloning Your Fork

Once you have forked the repository, you will need to clone it to your local machine to make changes:

Copy the Repository URL: On your fork’s GitHub page, click the “Code” button and copy the URL provided.
Clone the Repository: Open a terminal and run git clone [URL], replacing [URL] with the repository URL you copied. This downloads the repository to your local machine.

Step 3: Making Changes in Your Fork

With the repository cloned, you can now navigate into the directory and start making changes:

Navigate to the Repository Directory: cd repository-name
Create a New Branch (optional but recommended): git checkout -b your-new-branch-name
Make Your Changes: Use your favorite code editor to make the changes you desire.
Commit the Changes: Use git add . to stage changes, and git commit -m "your commit message" to save them.

Step 4: Pushing Changes and Updating Your Fork

After committing your changes locally, you need to push them back to your GitHub fork:

Push the Changes: git push origin your-new-branch-name
Create a Pull Request (if you want to contribute back to the original repository): Go to your fork on GitHub, switch to your branch, and click “Pull request”.

Step 5: Updating a Submodule in Your Main Project

If your fork is used as a submodule in another project, update your main project to use the latest changes:

Navigate to the Submodule Directory: cd path-to-main-project/submodule-directory
Pull the Latest Changes: git checkout main (or whichever branch you want), then git pull origin main
Commit the Submodule Changes in the Main Project: Navigate back to the root of your main project, then run git add submodule-directory and git commit -m "Update submodule to latest commit"
Push the Updates: git push origin main

Removing and Re-Adding a Submodule to Use a Fork in Your Main Project

Sometimes you might find it necessary to replace a submodule in your project with a fork that you have customized. This section will guide you through removing the existing submodule and adding your fork as the new submodule. In this example, we will assume that you have forked the hugo-tania theme and want to use it in your project. (the blog you are reading is using this theme).

Step 1: Navigate to Your Main Project

Ensure you are in the root directory of your main project where the submodule is integrated:

1

cd path/to/your/main/project

Step 2: Remove the Existing Submodule Reference

To change the submodule reference, first, remove the existing submodule. This includes deleting the submodule’s entries from .gitmodules, .git/config, and the actual submodule directory:

1
2
3


git submodule deinit -f themes/hugo-tania
rm -rf .git/modules/themes/hugo-tania
git rm -f themes/hugo-tania

Step 3: Commit the Removal of the Submodule

Commit these changes to ensure your repository correctly reflects the removal of the submodule:

1

git commit -m "Remove old submodule reference"

Step 4: Add Your Fork as the New Submodule

Now, add your fork as the new submodule. This step points the submodule reference to your forked repository:

1

git submodule add https://github.com/yourusername/hugo-tania.git themes/hugo-tania

Step 5: Initialize and Update the Submodule

After adding the new submodule, initialize and update it to make sure it’s correctly set up:

1

git submodule update --init --recursive

Step 6: Commit the New Submodule Reference

Once the submodule is added and updated, you need to commit these changes to your project’s repository:

1
2


git add .gitmodules themes/hugo-tania
git commit -m "Update submodule to point to my fork"

Step 7: Push Your Changes

Finally, push the changes to your remote repository to ensure that everything is up-to-date:

1

git push origin main

This procedure ensures that your main project now uses the updated fork as a submodule, allowing you to benefit from your custom changes or enhancements. This approach is ideal for developers who need to modify dependencies while keeping track of their changes separately from the original submodule source.

Cheers! 🍺

Understanding 'Origin' in GitHub

Yoonsoo Park — Sun, 07 Apr 2024 00:00:00 +0000

In the realm of Git and GitHub, grasping the concept of origin is crucial for developers to effectively manage and collaborate on code. The term origin might sound abstract, but it plays a critical role in your interactions with Git repositories. This article demystifies origin, breaking down its importance and functionality in the context of GitHub.

Remote Repository Alias

When you clone a repository from GitHub, Git doesn’t leave you juggling with the full URL of your remote repository every time you need to interact with it. Instead, it kindly sets up a shorthand alias named origin. This alias points directly to the URL of the cloned repository, simplifying your command-line operations.

For instance, pushing changes to the origin means you are updating the remote repository you originally cloned from:

1

git push origin branch-name

This command efficiently communicates your local changes back to the remote repository, tagged under the branch you specify. push your local branch-name to origin(remote repo where you cloned your code from)

Default Remote

The term origin is not a whimsical choice but a standard convention in Git to refer to your primary remote repository. However, this doesn’t mean you are stuck with it. Git is flexible, allowing you to rename origin to something more meaningful to you or even work with multiple remotes by giving each one a unique name.

Independence from the Default Branch

While origin is a constant presence in your Git commands, it’s important to note that it does not tie specifically to any branch, such as the default main or master branch. Instead, origin is your gateway to the entire remote repository, providing access to all its branches. For example, if you need to fetch updates from a develop branch on the remote, you’d use:

1

git fetch origin develop

This command doesn’t care which branch is default; it fetches updates from develop, demonstrating origin’s versatility.

Wrapping it up 👏

The concept of origin in GitHub is a cornerstone for efficient repository management and collaboration. It is essentially a nickname or alias for the remote repository from which you cloned your code!

Cheers! 🍺

Setting Up a Shortcut for GitHub Copilot in VS Code

Yoonsoo Park — Mon, 25 Mar 2024 00:00:00 +0000

GitHub Copilot has become an indispensable tool for many developers, offering AI-powered code suggestions that streamline the coding process. I believe it is the most advantaced AI code assitant at this point. However, constantly navigating through menus to access Copilot can disrupt your workflow. This tutorial will guide you through setting up a keyboard shortcut in Visual Studio Code (VS Code) to quickly open the GitHub Copilot chat panel.

Step-by-Step Guide to Setting Up Your Shortcut

Open the Command Palette in VS Code
Start by opening the Command Palette, which is the hub for accessing various commands in VS Code. You can open it by pressing Cmd + Shift + P on your keyboard.
Access Keyboard Shortcuts File
In the Command Palette, type keyboard shortcuts json. This will bring up a list of options related to keyboard shortcuts. Select Preference: Open Keyboard Shortcuts (JSON) from the list. This action opens the keybindings.json file where you can define custom keyboard shortcuts.

Edit the JSON File
In the keybindings.json file, you will define the shortcut for the GitHub Copilot chat panel. Insert the following code snippet:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "key": "ctrl+alt+cmd+c",
 "command": "workbench.panel.chat.view.copilot.focus",
 "when": "editorFocus"
},
{
 // Move focus back to the Editor
 "key": "ctrl+alt+cmd+c",
 "command": "workbench.action.focusActiveEditorGroup",
 "when": "!editorFocus"
}

This configuration sets up Ctrl + Alt + Command + C as the shortcut to toggle the GitHub Copilot chat panel. The first part focuses on the Copilot chat panel when the editor is focused, and the second part returns focus to the editor if the Copilot panel is focused.

Save and Test Your Shortcut
After adding the code, save your keybindings.json file. Test the new shortcut by pressing Ctrl + Alt + Command + C in the editor. If everything is set up correctly, you should be able to toggle the GitHub Copilot chat panel with this shortcut.

Wrapping it up 👏

By following these simple steps, you’ve successfully configured a custom keyboard shortcut in VS Code to enhance your productivity with GitHub Copilot. This shortcut allows you to swiftly access the Copilot chat panel without navigating through the interface, letting you focus more on coding. Happy coding, and enjoy the efficiency boost!

Cheers! 🍺

Mastering Node.js- In-Depth Guide to package.json and package-lock.json

Yoonsoo Park — Wed, 20 Mar 2024 00:00:00 +0000

In the realm of Node.js development, understanding the nuances of package.json and package-lock.json is crucial for building and maintaining robust applications. These files are not just placeholders in your project; they are pivotal in defining, managing, and ensuring the consistency of your application’s dependencies across different environments. This article delves deep into the anatomy of package.json and package-lock.json, underscores their critical roles, and provides a real-life scenario that showcases their utility.

Understanding `package.json`

The package.json file acts as the backbone of any Node.js project, offering a snapshot of your project’s metadata and dependencies. Here’s a detailed exploration:

Basic Purpose of `package.json`

Project Metadata: It encapsulates essential details like your project’s name, version, and description, which are vital for both documentation and identification purposes.
Dependency Management: This is where package.json truly shines, listing all necessary dependencies and devDependencies, thus allowing Node.js to fetch and install them appropriately.
Scripts: It enables you to define script commands for various tasks such as starting your app or running tests, streamlining your development workflows.
License Information: Indicates the legal licensing under which the project is released.

Advanced Usage of `package.json`

Versioning and npm Workflows: Embracing semantic versioning and utilizing npm’s capabilities for version management can significantly enhance your project’s reliability.
Custom Scripts: Beyond standard scripts, you can introduce custom automation scripts for tasks like linting, building, or deployment.
Package Configuration: Certain npm packages offer the option to be configured directly within package.json, fostering a centralized configuration approach.
Peer Dependencies: Essential for library authors, this section ensures consumers have the compatible dependency versions installed.
Engines: Specify which Node.js engine versions your project is compatible with, ensuring consistency across development and deployment environments.
Private Packages: Mark your package as private to prevent unintentional publishing to npm.

How Node.js Installs Dependencies

When dependencies are declared in package.json, Node.js uses npm to install them as follows:

Parsing package.json: npm examines package.json to identify the required dependencies and their specified versions.
Resolving Dependencies: npm determines the exact versions to install, adhering to the version ranges specified. It ensures that the installed versions meet the version constraints while considering the latest versions available.
Downloading and Installing: npm fetches and installs the dependencies from the npm registry. The dependencies are installed for production, and devDependencies are additionally installed in development environments.
Storing Dependencies: Installed packages are placed in the node_modules directory within your project, allowing Node.js to access and load them as needed.
Version Locking: npm generates a package-lock.json to lock down the exact versions installed, ensuring consistent installs across environments.

Real-Life Example

Imagine a web application project that uses several dependencies, such as Express for the backend and React for the frontend. package.json lists these dependencies with specified version ranges. When setting up the project on a new machine or deployment environment, npm consults package.json to install the exact versions of these libraries, as recorded in package-lock.json, ensuring that the application behaves consistently across different setups and avoiding the “works on my machine” problem.

package-lock.json: Ensuring Consistency

While package.json provides a broad overview and intent of your project’s dependencies, package-lock.json nails down the exact versions of each installed package, ensuring that your project remains consistent and predictable across all installations. It records the specific version of each package that is installed and guarantees that the same version is used every time you (or anyone else) runs npm install.

Best Practices for Maintaining `package-lock.json`

Version Control: Always check in package-lock.json into your version control system. This inclusion ensures that every collaborator or deployment environment uses precisely the same set of dependencies.
Regular Updates: Dependencies should be updated methodically to incorporate critical security patches, bug fixes, or new features. npm update can

be your ally here, modifying package-lock.json to reflect updated versions.

Conflict Resolution: In case of merge conflicts in package-lock.json, it’s generally safe to regenerate it by deleting the existing file and running npm install, ensuring alignment with package.json.
Using npm ci: In continuous integration environments, prefer npm ci over npm install to adhere strictly to the versions defined in package-lock.json, enhancing the reliability of your builds.
Avoid Manual Edits: You should not manually edit package-lock.json as it can lead to inconsistencies. If there’s a need to change a version of a package, do it through package.json and let npm update the lock file accordingly.
Review Changes: When package-lock.json is updated (for instance, when adding a new package), review the changes to ensure that the versions are correct and there are no unexpected modifications.

Wrapping it up 👏

Grasping the intricacies of package.json and package-lock.json is fundamental for any Node.js developer aiming to build reliable, maintainable, and consistent applications. Do not be a developer, just execute npm run all without knowing what it is about. Fundamental matters in every part of life so is this.

Cheers! 🍺

Testing Dependencies in Node.js Projects - A Focus on Package.json

Yoonsoo Park — Tue, 19 Mar 2024 00:00:00 +0000

Dependency management is a critical factor in the development of Node.js projects, significantly influencing the reliability and maintainability of applications. For teams that maintain their own libraries in conjunction with main projects, the task of debugging and testing these dependencies can pose unique challenges. This article explores a situation where a Node.js library, referred to as @yopa/the-library, requires comprehensive testing within a primary project to validate its functionality.

The Challenge: Debugging Internal Libraries

Imagine you’re working on a Node.js project, and your application relies on an internal library you’ve developed and maintained. This library, referred to as @yopa/the-library, is crucial for your application’s functionality. However, when issues arise in your main project, it’s essential to pinpoint whether the problem lies within the project itself or is due to the integrated library.

Traditionally, this library is managed as a npm package and versioned something like @yopa/the-library: ^1.12.10, which introduces complexity when attempting to debug interactions between the library and the main project. This becomes even more challenging when you need to modify the library code and test these changes directly within the main project.

A Strategic Approach to Dependency Testing

To efficiently tackle this challenge, the following steps provide a systematic method for testing and debugging the library within the context of the main project:

Local Packaging of the Library: Begin by making the necessary modifications to your library code. Once the changes are ready for testing, execute npm pack in the library’s root directory. This command generates a .tgz file, essentially a zipped version of your library, which you can then integrate directly into your main project.
Modifying package.json Dependencies: Navigate to the package.json file in your main project. Update the dependency entry for the-library to point to the absolute path of the .tgz file you generated, rather than specifying a version number. This change directs npm to use the local version of the library for installation.
Installation and Deployment: With the dependency path updated, run npm install to integrate the local version of your library into the main project.
Iterative Testing and Debugging: As you continue to refine and test your library, you’ll need to update the .tgz file regularly. This involves running npm run build (assuming your library requires a build step) and npm pack again to create a new package reflecting your latest changes. After updating the package, use npm i ./path/to/tgzfile.tgz in your main project to test the updated library.

By adopting this workflow, you can directly test how changes in your library affect the main project, enabling rapid iteration and more effective debugging.

A Note of Gratitude

In the realm of software development, collaboration and mutual learning are key to overcoming challenges and achieving success. I’d like to extend my sincere gratitude to my team members, Steven and Ryan, for their insights, support, and the collaborative spirit they bring to our projects. Working alongside such dedicated individuals is not only inspiring but also immensely educational.

Wrapping it up 👏

By utilizing local packaging and strategic modifications in package.json, developers can achieve a more integrated and responsive debugging environment.

Cheers! 🍺

Understanding Metadata API vs Tooling API in Salesforce Development

Yoonsoo Park — Mon, 18 Mar 2024 00:00:00 +0000

When developing in Salesforce, understanding the nuanced differences between Metadata API and Tooling API can significantly streamline your workflow. Both are powerful interfaces for interacting with your org’s metadata, but they serve distinct purposes and are suited to different kinds of tasks. Let’s delve into the specifics of each API and explore real-life examples to guide you on when to use one over the other.

Metadata API: The Workhorse for Bulk Operations

The Metadata API is an essential tool in the Salesforce developer’s arsenal, designed for managing large-scale changes to the org’s metadata. It’s the backbone for deploying sets of changes across environments, ideal for operations that need to handle multiple metadata components at once.

Real-Life Example: Full-Scale Deployment

Imagine you’re working on a major update for your Salesforce org, which includes new custom objects, updated page layouts, several new fields, and modified permissions. Here, the Metadata API shines by helping you to package all these changes and deploy them from your sandbox environment to production efficiently. It’s akin to moving an entire library of books from one room to another, ensuring nothing is left behind.

Tooling API: Precision Tooling for Developers

On the flip side, the Tooling API is crafted for developers needing finer control and real-time interaction with the org’s metadata. It’s particularly beneficial for creating and modifying individual metadata components during the development process, providing a more granular approach.

Real-Life Example: Iterative Development

Consider a scenario where you’re developing a new custom application within Salesforce and need to frequently create, test, and modify individual Apex classes and Visualforce pages. The Tooling API is your best friend here, enabling quick iterations and immediate feedback on your changes. It’s like fine-tuning a single book’s layout and content, ensuring every page is perfect before the final print.

Choosing the Right API for Your Task

When to use which API can depend on several factors, including the scale of your changes, the need for real-time feedback, and the complexity of the metadata involved. Here’s a quick guide:

Use Metadata API when:
- You’re deploying or retrieving large sets of metadata.
- Your work involves complex metadata types and dependencies.
- You’re migrating changes across environments (e.g., sandbox to production).
Use Tooling API when:
- You’re developing and testing in real-time.
- Your tasks involve creating or modifying individual metadata components.
- You’re building development tools or automated scripts that require dynamic metadata interaction.

Cheers! 🍺

Mastering SF CLI - In-Depth Guide to sf project convert source and mdapi Commands

Yoonsoo Park — Sun, 17 Mar 2024 00:00:00 +0000

Salesforce CLI (Command Line Interface) continues to evolve, introducing sophisticated tools to enhance the efficiency and structure of Salesforce project management. Among the noteworthy updates are the sf project convert source and sf project convert mdapi commands, crucial for transitioning project formats and aiding developers in their deployment and development workflows. This article explores these commands in depth, examining their features, differences, and strategic importance in the Salesforce development landscape.

Exploring `sf project convert source`

The sf project convert source command, a recent addition to Salesforce CLI, plays a pivotal role in transforming source-formatted files into Metadata API format, a necessity for certain deployment contexts.

Features and Advantages:

Preparation for Deployment: It readies source-formatted files for deployment, ensuring they are compatible with Metadata API–dependent Salesforce environments.
Efficient Workflow Management: By allowing developers to work in the Source format and convert files as needed, it supports a seamless transition from development to deployment.

Practical Examples:

This command allows for flexible directory and package specification, illustrated by these examples:

Converting a source directory to the metadata format: $ sf project convert source --root-dir path/to/source
Defining an output directory and package name: $ sf project convert source --root-dir path/to/source --output-dir path/to/output --package-name 'My Package'

Reevaluating `sf project convert mdapi`

The sf project convert mdapi command complements sf project convert source by converting Metadata API format files back to the Source format, supporting a reverse workflow.

Features and Advantages:

Transition to Source Format: It simplifies the move to Source format, beneficial for version control, collaboration, and CI/CD integration.
Legacy Integration: It’s crucial for developers migrating from Metadata API–based projects to the modular Source format.

These tools underscore Salesforce’s commitment to equipping developers with sophisticated resources for modern development methodologies.

Comparing Metadata API and Source Format Structures

Understanding the structural differences between Metadata API and Source formats is essential for leveraging the full potential of the conversion commands.

Metadata API Format Illustration:

The Metadata API format groups similar types of metadata, potentially complicating detailed version control. An example structure is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


unpackaged/
├── classes
│ ├── MyApexClass.cls
│ └── MyApexClass.cls-meta.xml
├── objects
│ ├── MyCustomObject__c.object
│ └── AnotherObject__c.object
├── pages
│ └── MyVisualforcePage.page
└── package.xml

Source Format Illustration:

The Source format, on the other hand, offers a granular component breakdown, aiding in precise change management and conflict resolution:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


force-app/
├── main/
│ └── default/
│ ├── classes/
│ │ ├── MyApexClass.cls
│ │ └── MyApexClass.cls-meta.xml
│ ├── objects/
│ │ ├── MyCustomObject__c/
│ │ │ ├── fields/
│ │ │ │ └── MyField__c.field-meta.xml
│ │ │ └── MyCustomObject__c.object-meta.xml
│ │ └── AnotherObject__c/
│ │ └── AnotherObject__c.object-meta.xml
│ └── pages/
│ └── MyVisualforcePage.page-meta.xml
└── sfdx-project.json

These distinctions highlight the strategic considerations in choosing the appropriate command based on the project’s phase and requirements.

Wrapping it up 👏

The introduction of sf project convert source alongside sf project convert mdapi signifies Salesforce’s ongoing commitment to refining the developer experience. These commands are not merely about format conversion; they represent a strategic approach to structured, efficient, and collaborative Salesforce development. I am still not sure why they pick the command name in the current way. This is for the another time I guess. Cheer! 🍺

How to Fix Divergent Branch Problems in Git - A Step-by-Step Guide.

Yoonsoo Park — Tue, 12 Mar 2024 00:00:00 +0000

When working with Git, you might encounter a situation where your branches have diverged, leading to confusion and potential merge conflicts. This blog post will delve into what causes divergent branches in Git and how to reconcile them effectively.

Understanding Divergent Branches in Git

Divergent branches occur when your local branch and the corresponding remote branch have different commits. This situation typically arises when multiple people are working on the same branch or when changes are made to the remote branch after you’ve cloned or fetched it but before you try to push your local changes.

When you attempt to git pull, Git may show a message indicating that you have divergent branches and need to specify how to reconcile them. This is because Git wants to prevent unintentional loss of work and ensure that you are making a conscious decision about how to integrate the changes.

Strategies to Reconcile Divergent Branches

There are three main strategies to reconcile divergent branches in Git:

1. Merge

Merging is the most straightforward approach. It combines the histories of the two branches, creating a new merge commit. This approach maintains the full history of both branches but can lead to a more complex commit history.

1
2


git config pull.rebase false
git pull origin <branch-name>

2. Rebase

Rebasing rewrites the commit history by applying your local changes on top of the remote branch’s latest commit. It results in a cleaner, linear history but should be used with caution as it changes commit hashes.

1
2


git config pull.rebase true
git pull origin <branch-name>

The Significance of the Rebase Warning

The warning “but should be used with caution as it changes commit hashes” during a rebase is crucial to understand. When you rebase a branch, Git essentially creates new commits for each commit in your branch since it diverged from the base branch. This process changes the commit hashes, which are the unique identifiers for each commit.

Why is this Important?

Collaboration Impact: If you’ve already pushed your branch and then rebase it, the rebased branch will not align with the remote branch since the commit hashes have changed. If someone else is working on the same branch, they will encounter conflicts when they try to pull your changes.
Data Integrity: Changing commit hashes can also impact any references to those commits, such as in submodules, or when using commit hashes in documentation or issue tracking.
Force Pushing: After a rebase, you’ll need to force push (git push --force) to update the remote branch with the rewritten history. Force pushing can be risky as it can overwrite changes on the remote branch, so it should be done with caution and clear communication among team members.

3. Fast-forward only

The fast-forward only approach refuses to merge if the local branch has diverged from the remote branch, ensuring that your history only ever moves forward linearly from the base.

1
2


git config pull.ff only
git pull origin <branch-name>

Setting a Default Reconciliation Strategy

You can set your preferred strategy globally or per repository, providing flexibility and control over your project’s version control strategy.

1
2
3
4
5


# Set globally
git config --global pull.rebase false

# Set for a specific repository
git config pull.rebase false

You can set this setting globally by adding --global to the git config command, but it’s generally safer to set them per-repository (which I prefer) unless you are certain about this.

Conclusion

Understanding how to manage divergent branches in Git is critical for maintaining a clean workflow in your development. By choosing the appropriate strategy to reconcile branches, you can ensure that your project’s history is manageable, reducing potential integration headaches down the line. (ultimate goal!)

Wrapping it up 👏

Whether you prefer merging, rebasing, or fast-forwarding, Git provides the ways you need to maintain a consistent history in your version control.

Cheers! 🍺

Managing Multiple Versions with Pyenv, venv, and Pipenv

Yoonsoo Park — Mon, 11 Mar 2024 00:00:00 +0000

Introduction to Python Environment Management

When working on multiple Python projects, it’s crucial to manage dependencies and Python versions without conflicts. This guide covers using Pyenv to handle multiple Python versions, venv for creating isolated environments using Python’s built-in module, and Pipenv for an enhanced approach to manage dependencies and virtual environments together.

Installing Python Using Homebrew on macOS

Before setting up virtual environments or using Pyenv, ensure you have the desired versions of Python installed:

Install Homebrew: Use this command to install Homebrew, a package manager for macOS:

1

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

Install Python: Install the latest Python version using Homebrew:
1

brew install python

Managing Multiple Python Versions with pyenv

Pyenv is a popular tool for managing multiple Python versions on your system:

Install pyenv:
1

brew install pyenv

Configure Your Shell:

1
2


eval "$(pyenv init --path)"
eval "$(pyenv init -)"

Install and Manage Python Versions:

1
2
3


pyenv install 3.8.6
pyenv install 2.7.18
pyenv global 3.8.6

Virtual Environments with venv

venv creates isolated Python environments, allowing you to manage packages specific to each project.

Creating a Virtual Environment: In your project directory:
1

python3 -m venv env
Activating the Virtual Environment:
1

source env/bin/activate
Deactivating the Virtual Environment:
1

deactivate

Dependency Management and Environments with Pipenv

Pipenv combines dependency management with virtual environment management, simplifying Python workflow.

Install Pipenv:
1

brew install pipenv
Creating and Activating Environments: Navigate to your project directory and run:
1

pipenv install
This command creates a virtual environment and installs dependencies listed in the Pipfile.

Running Commands Within a Virtual Environment:

1

pipenv run python or pipenv run <command>

Deactivating Pipenv Environment: Exit the environment simply by ending the terminal session, or explicitly with:
1

exit

Conclusion: Choosing Between venv and Pipenv

venv is suitable for simple projects or when minimal dependency management is needed beyond Python’s standard library.
Pipenv offers a higher-level tool that automatically manages a virtual environment for your projects and adds support for dependency management, ideal for more complex project setups.

Extra: Real life Scenario

Imagine an associate developer, YOPA, who has recently joined a Python project team. The project uses Python virtual environments to manage dependencies, but YOPA is not sure which system is in use. After checking with a teammate, YOPA learns that the project uses Python’s built-in venv but wants to transition to using Pipenv for enhanced dependency management and workflow.

Step-by-Step Guide for Transitioning from `venv` to `Pipenv`

Step 1: Check the Current Virtual Environment Setup

First, YOPA needs to confirm that the project is using venv. This can be done by looking for a directory typically named env or venv within the project folder, or checking if there’s an activation script in such a directory.

1

ls -la

If there’s a folder named env, venv, or similar, it likely contains the virtual environment.

Step 2: Deactivate the Current `venv` Environment (if active)

Before transitioning to Pipenv, YOPA should ensure that no virtual environments are active. If YOPA has the environment activated, he can deactivate it by running:

1

deactivate

Step 3: Install Pipenv

If Pipenv is not already installed, YOPA can install it using Homebrew on macOS, or pip on other systems:

On macOS:

1

brew install pipenv

On Windows/Linux:

1

pip install --user pipenv

Step 4: Remove the `venv` Directory (Optional)

To avoid confusion and clean up the project directory, YOPA can remove the old venv directory. This step should only be performed if all necessary dependencies are documented and can be reinstalled with Pipenv.

1

rm -rf venv

Step 5: Initialize Pipenv with Python Version

YOPA should initialize Pipenv specifying the Python version used by the venv to ensure consistency:

1

pipenv --python 3.8

Replace 3.8 with the version YOPA’s project uses.

Step 6: Install Dependencies

YOPA needs to install the project dependencies with Pipenv. If there’s a requirements.txt file, he can use that to install all dependencies at once:

1

pipenv install -r requirements.txt

If there’s no such file, YOPA should manually install necessary packages:

1

pipenv install requests numpy

Step 7: Activate the New Pipenv Environment

To start using the newly created Pipenv environment, YOPA can activate it by running:

1

pipenv shell

Step 8: Update Project Documentation

Finally, YOPA should update any project documentation or scripts that reference the old venv setup to use Pipenv commands instead. This ensures that all team members are aware of the change and know how to activate and use the new environment.

Wrapping up!

With these steps, YOPA has successfully transitioned the project from using venv to Pipenv, enhancing the project’s dependency management and simplifying future environment setups. Great job, YOPA!

Cheers! 🍺

Mastering Update-Notifier in Node.js with TypeScript

Yoonsoo Park — Mon, 26 Feb 2024 00:00:00 +0000

Keeping your Node.js application up-to-date is crucial for security, performance, and feature enhancements. The update-notifier npm package, when used with TypeScript, provides a powerful yet straightforward way to notify users of your application about new updates. This blog delves into the integration of update-notifier within a TypeScript environment, covering both basic and advanced usages with detailed code examples.

Introduction to Update-Notifier with TypeScript

update-notifier is a handy tool for Node.js applications to check for available updates and notify users, ensuring they are always using the latest version. Integrating it with TypeScript adds type safety and enhances code readability and maintainability.

Setting Up Your TypeScript Project

Before diving into update-notifier, ensure your TypeScript environment is set up. You’ll need a tsconfig.json file configured for your project. Here’s a basic setup:

1
2
3
4
5
6
7
8
9


{
 "compilerOptions": {
 "target": "es5",
 "module": "commonjs",
 "strict": true,
 "esModuleInterop": true,
 "resolveJsonModule": true
 }
}

The resolveJsonModule option in compilerOptions allows TypeScript to natively import JSON modules, such as your package.json file. This is crucial for update-notifier to access the current version and package name.

Installing Update-Notifier

To add update-notifier to your project, run:

1
2


npm install update-notifier
npm install @types/update-notifier --save-dev

The second command installs the TypeScript type definitions for update-notifier, allowing for type checking and IntelliSense in your IDE.

Basic Usage in TypeScript

After ensuring your tsconfig.json is properly configured to import JSON modules, you can now easily import your package.json:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import updateNotifier from "update-notifier";
import pkg from "./package.json";

const notifier = updateNotifier({
 pkg,
 updateCheckInterval: 1000 * 60 * 60 * 24,
});

if (notifier.update) {
 notifier.notify();
}

This script will check for updates once a day and notify the user when there’s a new version available.

Advanced Usage Examples

Prompting Users to Update

You can prompt users interactively to update their application using inquirer alongside update-notifier. Here’s a TypeScript example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


import updateNotifier from "update-notifier";
import inquirer from "inquirer";
import pkg from "./package.json";
import { execSync } from "child_process";

const notifier = updateNotifier({ pkg });

if (notifier.update) {
 inquirer
 .prompt([
 {
 type: "confirm",
 name: "update",
 message: `Update available: ${notifier.update.latest}. Do you want to update now?`,
 default: false,
 },
 ])
 .then((answers: any) => {
 if (answers.update) {
 execSync(`npm install -g ${pkg.name}`, { stdio: "inherit" });
 }
 });
}

Custom Notifications Based on Update Type

You can customize the notification message based on the update type (major, minor, patch) using TypeScript’s enum and type checking features:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


import updateNotifier, { UpdateInfo } from "update-notifier";
import pkg from "./package.json";

const notifier = updateNotifier({ pkg });

if (notifier.update) {
 let message: string = "";
 const update: UpdateInfo = notifier.update;

 switch (update.type) {
 case "major":
 message =
 "A new major version is available. Updating is highly recommended!";
 break;
 case "minor":
 message =
 "A new minor version is available. Update to access new features.";
 break;
 case "patch":
 message =
 "A new patch version is available. Update to improve stability.";
 break;
 }

 notifier.notify({ message });
}

Logging Update Details

For more detailed logging, especially useful in debugging or maintaining logs, you can utilize TypeScript to ensure structured and type-safe logging:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


import updateNotifier from "update-notifier";
import pkg from "./package.json";

const notifier = updateNotifier({ pkg });

if (notifier.update) {
 console.log(`Update available: ${notifier.update.latest}`);
 console.log(`Current version: ${pkg.version}`);
 console.log(`Update type: ${notifier.update.type}`);
}

Wrapping it up 👏

Integrating update-notifier with TypeScript in your Node.js applications not only keeps your users informed about new updates but also enhances your code with type safety and modularity. By setting the resolveJsonModule option in your TypeScript configuration, you can import and utilize JSON modules seamlessly, further streamlining your update notification system. Harness the power of update-notifier in TypeScript to provide a superior user experience and maintain an edge in application reliability and user engagement.

Cheers! 🍺

Enhance CLI with Listr - The Node.js Task Manager

Yoonsoo Park — Tue, 20 Feb 2024 00:00:00 +0000

Introduction

Have you ever run a terminal command or a long-running build process, staring at a wall of scrolling text without much clue about progress? Enter Listr, a Node.js library designed to create dynamic, interactive task lists within your command-line interface (CLI). Listr leverages Node.js to transform mundane terminal outputs into a visually appealing, informative experience. This tool is especially valuable for developers, CLI tool creators, and anyone looking to enhance their command-line operations.

Why Listr?

Elegant Task Displays: Unlike traditional CLI outputs, Listr introduces clean layouts, spinners, and status symbols that significantly enhance visual appeal and user comprehension.
Organized Workflows: Listr allows for the breaking down of complex tasks into manageable subtasks, reflecting the logical structure of operations and facilitating easier troubleshooting.
Progress Tracking: Real-time updates provided by Listr foster trust and a sense of responsiveness, keeping users informed about the script’s execution status.

Getting Started (with TypeScript)

Before diving into Listr, ensure you have a compatible Node.js environment. Listr’s TypeScript support offers strong typing benefits, making your task management scripts more maintainable and error-resistant.

Install Listr and types:
1

npm install listr @types/listr

A simple TypeScript example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


import Listr from "listr";
import { Task } from "listr"; // Import for type definitions

// Define a context for your tasks to use
interface MyContext {
 downloadPath: string;
}

const tasks = new Listr<MyContext>([
 {
 title: "Download project assets",
 task: (ctx) => downloadAssets(ctx.downloadPath),
 // Here, downloadAssets is a function you define to download project assets
 },
 {
 title: "Process data",
 task: () => processData(),
 // processData is another function for handling your data
 },
]);

// Run the tasks with a specified context
tasks.run({ downloadPath: "/tmp" }).catch((err) => {
 console.error(err);
});

Listr’s Flexibility in Action

Error Handling: Efficient error management is crucial for resilient script execution. Listr enables specific error handling routines and rollback mechanisms to maintain stability.

1
2
3
4
5
6
7
8


const tasks = new Listr<MyContext>([
 {
 title: "Fetch sensitive data",
 task: () => fetchData(), // fetchData should safely handle sensitive information
 onRollback: (task, ctx) => cleanUpSensitiveFiles(ctx.tempFiles),
 // cleanUpSensitiveFiles is a custom cleanup function
 },
]);

Observability: Tracking task progress is simplified with Listr’s event hooks, offering insights into each step’s execution.

1
2
3
4
5


const tasks = new Listr([...], { rendererOptions: { showSubtasks: false } });

tasks.on('task:start', (task) => {
 console.log(`Starting task: ${task.title}`);
});

Customization: Tailor Listr’s output to meet your needs, whether for a concise summary or detailed logs.
1

const tasks = new Listr([...], { renderer: 'verbose' });

Real-World Use Cases

Deploying Listr in practical scenarios demonstrates its versatility and impact:

Build Script Example: Simplify your build process with structured tasks, making each step transparent and manageable.

1
2
3
4
5


tasks.add([
 { title: "Clean", task: () => runCleanCommand() },
 { title: "Transpile Code (TypeScript)", task: () => transpileCode() },
 { title: "Bundle Assets", task: () => bundleAssets() },
]);

Deployment Workflow Example: Streamline deployments by organizing tasks sequentially, ensuring each step is completed before proceeding.

1
2
3
4
5
6
7
8
9


tasks.add([
 { title: "Test Suite", task: () => runTestSuite() },
 { title: "Push to Staging", task: () => deployToStaging() },
 {
 title: "Monitor",
 task: () => monitorLogs(),
 enabled: (ctx) => ctx.deploySuccess,
 },
]);

Wrapping it up 👏

Listr is an invaluable tool for anyone working with Node.js, TypeScript, and CLI environments, striving for an enhanced user experience. Its flexibility, error handling, and customization options make it suitable for a wide range of applications. For a deeper dive into Listr’s capabilities, visit the “official documentation” and start exploring how it can revolutionize your terminal tasks.

Cheers! 🍺

Mastering Salesforce CLI with Grep - A Guide to Finding Commands Efficiently

Yoonsoo Park — Sun, 11 Feb 2024 00:00:00 +0000

As a Salesforce professional, navigating through the extensive Salesforce Command Line Interface (CLI) can be daunting. The grep command, a staple in Unix-like systems for searching text using patterns, can be your ally in swiftly finding specific commands or options in the Salesforce CLI. This blog post delves into using grep effectively with Salesforce CLI, offering detailed examples for the most common use-cases.

1. Finding Basic Commands

Starting with the basics, let’s say you need to find commands related to organizations (orgs). The Salesforce CLI has various org-related commands, but to find them quickly:

1

sf org --help | grep "org"

This command filters the extensive help information of sf org to lines containing “org”, giving you a quick overview of available org commands.

2. Locating Commands for Data Manipulation

Often, you’ll need to manipulate data, like querying or exporting data. For instance, to find commands related to querying data:

1

sf data --help | grep "query"

This reveals options and subcommands under sf data that are related to querying, making it easier to find the exact syntax or command you need.

3. Searching for Deployment Commands

Deployment is a critical task, and you need to get the commands right. If you’re looking for commands related to deploying metadata:

1

sf deploy metadata --help | grep "deploy"

This filters out the specific options and subcommands for metadata deployment, simplifying the task of finding the right command for your deployment needs.

4. User Management Commands

Managing users is a common task. To find commands related to user creation or management:

1

sf user --help | grep "create"

This command is particularly useful when you’re looking to create new users and need to know the specific command and its options.

5. Environment and Instance Management

For managing your environments or instances, you might need specific commands. To find those:

1

sf env --help | grep "list"

This is helpful to list all environments or instances, providing you with the exact command to use.

Advanced Tips

Case-Insensitive Search: Use grep -i for a case-insensitive search, which is particularly useful if you’re unsure about the casing.
Extended Patterns: Use egrep or grep -E for more complex pattern searches.
Contextual Search: If you need more context around your search, use grep with -B, -A, or -C to display lines before, after, or around the matching line.

Wrapping it up 👏

Mastering the use of grep with the Salesforce CLI can significantly enhance your productivity and efficiency. It allows you to quickly sift through extensive help documents and find exactly what you need. The key to effectively using grep is understanding the basic patterns of commands you are searching for and iteratively refining your search based on the output you get. Happy grepping in your Salesforce CLI adventures!

Cheers! 🍺

Mastering Jest with TypeScript - A Comprehensive Guide

Yoonsoo Park — Sat, 10 Feb 2024 00:00:00 +0000

In the realm of JavaScript and TypeScript development, testing your code is just as important as writing it. Jest, a delightful JavaScript Testing Framework, has gained immense popularity for its simplicity and feature-rich environment. When combined with TypeScript, it brings strong typing and helps catch errors early, leading to more reliable and maintainable code. In this article, we dive deep into how to use Jest with TypeScript, exploring its powerful features through practical examples.

Setting up Jest with TypeScript

Before harnessing the power of Jest in a TypeScript environment, you need to set up your project correctly. Start by installing TypeScript, Jest, and the necessary dependencies:

1

npm install --save-dev typescript jest @types/jest ts-jest

Then, initialize TypeScript in your project:

1

npx tsc --init

Configure Jest to work with TypeScript by editing your Jest configuration file (jest.config.js):

1
2
3
4


module.exports = {
 preset: "ts-jest",
 testEnvironment: "node",
};

Writing Your First Jest Test in TypeScript

With the setup ready, let’s dive into writing a basic test. Consider a simple function in sum.ts:

1
2
3
4


// sum.ts
export function sum(a: number, b: number): number {
 return a + b;
}

You can write a test for this function in sum.test.ts:

1
2
3
4
5
6


// sum.test.ts
import { sum } from "./sum";

test("adds 1 + 2 to equal 3", () => {
 expect(sum(1, 2)).toBe(3);
});

Run your tests using:

1

npx jest

Exploring Matchers in Jest

Matchers are the heart of Jest’s testing power, allowing you to write various assertions.

Common Matchers

Matchers in Jest are methods that let you test values in different ways. These methods are used with the expect function to assert whether a particular value meets certain conditions. Jest offers a wide range of matchers, allowing you to handle various scenarios in your tests, from simple equality checks to more complex checks like testing for exceptions or checking array contents.

toBe and toEqual:

toBe uses Object.is to test exact equality. It’s great for primitive types.
toEqual recursively checks every field of an object or array.

1
2
3
4
5
6
7
8
9


test("two plus two is four", () => {
 expect(2 + 2).toBe(4);
});

test("object assignment", () => {
 const data: { [key: string]: number } = { one: 1 };
 data["two"] = 2;
 expect(data).toEqual({ one: 1, two: 2 });
});

Truthiness:

toBeNull matches only null.
toBeUndefined matches only undefined.
toBeDefined is the opposite of toBeUndefined.
toBeTruthy matches anything that an if statement treats as true.
toBeFalsy matches anything that an if statement treats as false.

1
2
3
4
5
6
7
8


test("null", () => {
 const n: null = null;
 expect(n).toBeNull();
 expect(n).toBeDefined();
 expect(n).not.toBeUndefined();
 expect(n).not.toBeTruthy();
 expect(n).toBeFalsy();
});

Numbers:

Matchers like toBeGreaterThan, toBeLessThan, etc., are used for comparing numbers.

1
2
3
4
5


test("two plus two", () => {
 const value: number = 2 + 2;
 expect(value).toBeGreaterThan(3);
 expect(value).toBeLessThan(5);
});

Strings:

toMatch is used to check strings against regular expressions.

1
2
3


test("there is no I in team", () => {
 expect("team").not.toMatch(/I/);
});

Arrays and Iterables:

toContain checks if an array or iterable contains a particular item.

1
2
3
4
5
6
7
8
9


test("the shopping list has beer on it", () => {
 const shoppingList: string[] = [
 "diapers",
 "kleenex",
 "trash bags",
 "beer",
 ];
 expect(shoppingList).toContain("beer");
});

Exceptions:

toThrow checks if a function throws an error when it’s called.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


function compileAndroidCode(): void {
 throw new Error("you are using the wrong JDK");
}

test("compiling android goes as expected", () => {
 expect(compileAndroidCode).toThrow();
 expect(compileAndroidCode).toThrow(Error);
 expect(compileAndroidCode).toThrow("you are using the wrong JDK");
 expect(compileAndroidCode).toThrow(/JDK/);
});

Custom Matchers

Jest allows you to extend its matchers by using expect.extend to add your custom matchers. This is useful when you want to add reusable test logic, or if you’re testing something specific to your application.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


// Extend the expect type with a custom matcher
declare global {
 namespace jest {
 interface Matchers<R> {
 toBeDivisibleBy(argument: number): R;
 }
 }
}

expect.extend({
 toBeDivisibleBy(received: number, argument: number) {
 const pass = received % argument === 0;
 if (pass) {
 return {
 message: () =>
 `expected ${received} not to be divisible by ${argument}`,
 pass: true,
 };
 } else {
 return {
 message: () => `expected ${received} to be divisible by ${argument}`,
 pass: false,
 };
 }
 },
});

test("even and odd numbers", () => {
 expect(100).toBeDivisibleBy(2);
 expect(101).not.toBeDivisibleBy(2);
});

Matchers are a powerful part of Jest, providing a rich vocabulary for writing tests. They help make your tests expressive and ensure that your code behaves as expected. The variety and extensibility of Jest matchers make them suitable for a wide range of testing scenarios.

Setup and Teardown

Jest offers several functions that allow you to perform setup and teardown tasks in your tests. These functions are beforeAll, beforeEach, afterAll, and afterEach. They are particularly useful for preparing the environment for tests and cleaning up afterward. Here’s a detailed look at each of these functions:

1. `beforeAll`

This function runs once before all the tests in a describe block. It’s useful for setting up something that is needed by all the tests and is expensive to set up, like a database connection or a large dataset.

1
2
3


beforeAll(() => {
 // Setup code that runs once before all tests
});

2. `beforeEach`

beforeEach runs before each test in a describe block. This is useful for resetting conditions to a known state before every test, such as resetting database records or clearing mocks.

1
2
3


beforeEach(() => {
 // Setup code that runs before each test
});

3. `afterAll`

This function is called once after all the tests in a describe block have completed. It is used for cleanup activities that need to happen after all tests have run, like closing database connections or freeing up resources that were used during the tests.

1
2
3


afterAll(() => {
 // Cleanup code that runs once after all tests
});

4. `afterEach`

afterEach is executed after each test in a describe block. It’s often used for cleanup that should be performed after each test, like resetting mock functions or clearing changes made during the individual test.

1
2
3


afterEach(() => {
 // Cleanup code that runs after each test
});

Example Usage

Here’s an example that demonstrates how these functions might be used in a test suite:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


describe("Test Suite", () => {
 beforeAll(() => {
 // This will run once before all the tests in this suite
 // Assuming initializeDatabase is a function you've defined
 initializeDatabase();
 });

 beforeEach(() => {
 // This will run before every test
 // Assuming resetTestData is a function you've defined
 resetTestData();
 });

 test("Test 1", () => {
 // Test code here
 // Example: expect(someFunction()).toBe(someValue);
 });

 test("Test 2", () => {
 // Test code here
 // Example: expect(someOtherFunction()).toEqual(someOtherValue);
 });

 afterEach(() => {
 // This will run after each test
 // Assuming clearMocks is a function you've defined
 clearMocks();
 });

 afterAll(() => {
 // This will run once after all the tests in this suite
 // Assuming closeDatabaseConnection is a function you've defined
 closeDatabaseConnection();
 });
});

In this example, initializeDatabase and closeDatabaseConnection are used for setting up and tearing down the database, which is a relatively heavy operation, so it’s done once. resetTestData and clearMocks are lighter operations needed to ensure each test runs in a clean state, so they are done before and after each test.

These functions help in organizing the test code and managing resources efficiently, making the tests more reliable and maintainable.

Wrapping it up 👏

Jest, when used with TypeScript, provides a robust framework for writing and managing your tests. Its rich set of matchers, combined with TypeScript’s strong typing, ensures that your tests are both powerful and maintainable.

Cheers! 🍺

Understanding Salesforce Packaging - A Comprehensive Comparison of 1GP vs 2GP

Yoonsoo Park — Mon, 05 Feb 2024 00:00:00 +0000

Salesforce’s evolution has always been characterized by its adaptability and forward-thinking approach. This is particularly evident in the realm of application development, where Salesforce 2nd Generation Packaging (2GP) marks a significant leap forward. 2GP, part of the Salesforce DX ecosystem, has transformed how Salesforce applications are developed, deployed, and managed. This article delves into the nuances of 2GP, highlighting its benefits and practical implications through real-world examples.

1GP vs 2GP

The two generations of Salesforce packaging, 1st Generation Packaging (1GP) and 2nd Generation Packaging (2GP), represent different approaches and capabilities in the Salesforce ecosystem. Understanding their key differences is crucial for developers and organizations to choose the right packaging strategy.

1st Generation Packaging (1GP)

Packaging Model: 1GP is based on the original Salesforce packaging model, primarily used for creating managed and unmanaged packages.
Development Org-Based: The package development and versioning are tied to a specific Salesforce org (the packaging org).
Release Process: Updates to a managed package require uploading a new version from the packaging org. Unmanaged packages can’t be updated; a new package must be created for each release.
Namespace: In managed packages, a namespace is permanently tied to the packaging org and is used across all packages created in that org.
Upgrade and Dependency Management: Managing upgrades and dependencies can be more challenging, especially for complex applications.
Metadata Deployment: Uses traditional metadata API deployment methods.
Salesforce DX Compatibility: Limited compatibility with Salesforce DX. It does not support source-driven development and scratch orgs as efficiently as 2GP.

2nd Generation Packaging (2GP)

Packaging Model: 2GP is part of the Salesforce DX ecosystem, designed for a more modular and flexible development experience.
Dev Hub-Based: Package development and lifecycle are managed through the Dev Hub, not tied to a specific development org.
Source-Driven Development: Emphasizes source-driven development, where the source of truth is in a version control system, not an org.
Namespace Flexibility: Offers flexibility in namespace usage. You can create packages without a namespace and opt for promoting them to managed packages later.
Modular Development: Supports more modular development with unlocked packages, allowing different parts of an application to be developed and deployed independently.
Improved Dependency Management: Better handling of dependencies and package upgrades, simplifying the management of complex applications.
Continuous Integration and Delivery: Better suited for CI/CD practices, integrating seamlessly with modern development pipelines.
Scratch Orgs and Isolation: Allows for development and testing in isolated, ephemeral scratch orgs, promoting cleaner development practices.

Source-Driven Development

“Source-Driven Development” refers to a software development approach where the primary focus is on managing and manipulating the source code directly, rather than the final output or the environment where the code runs. In the context of Salesforce, particularly with 2nd Generation Packaging (2GP), this concept plays a pivotal role.

Detail

Traditional Approach vs. Source-Driven Development

In traditional Salesforce development (more aligned with 1st Generation Packaging, or 1GP), the development often takes place directly in the Salesforce org. Developers make changes to the metadata and configurations within the org, and these changes are then retrieved and stored in version control. The Salesforce org, in this case, is often seen as the ‘source of truth’.

In contrast, source-driven development, as emphasized in 2GP, flips this approach:

Version Control as the Source of Truth: The primary ‘source of truth’ is the version control system (like Git). All changes and the current state of the application are stored and managed in version control.
Development in Isolation: Developers work in their local development environment or in isolated, ephemeral environments like scratch orgs. They make changes to the code and metadata locally.
Version Control Operations: Standard version control operations such as branching, merging, and pull requests are used to manage changes.
Continuous Integration/Continuous Deployment (CI/CD): Automated processes for testing and deploying the code changes are integrated, ensuring that changes are tested and deployed systematically and consistently.

Example Scenario

Imagine a team developing a Salesforce application:

Initial Setup: The team sets up a Git repository for their project. This repository will contain all their Salesforce code and configuration metadata.
Feature Development: A developer starts working on a new feature. They create a new branch in the Git repository for this feature.
Local Development: The developer pulls the branch onto their local machine. They use a Salesforce DX command to create a new scratch org for development.
Making Changes: The developer makes necessary code and metadata changes in the scratch org. These changes are then pulled from the scratch org and committed to their feature branch in Git.
Code Review and Merging: Once the feature is completed, the developer creates a pull request to merge their changes into the main branch. The team reviews the code changes in the pull request.
CI/CD Pipeline: After the pull request is approved and merged, a CI/CD pipeline automatically deploys the changes from the main branch to a testing org, runs tests, and if everything is successful, deploys it to the production org.

In this example, the Git repository serves as the central hub for all development work, ensuring that every change is tracked, reviewed, and systematically deployed, contrasting with traditional methods where the Salesforce org itself would be the main workspace for development.

Namespace Flexibility

In Salesforce, the concept of “offering flexibility in namespace usage” in the context of 2nd Generation Packaging (2GP) refers to the ability to develop and initially distribute packages without committing to a specific namespace, and then later decide to add a namespace when promoting them to managed packages. This is a significant shift from the 1st Generation Packaging (1GP) approach.

Detail

Understanding Namespaces in Salesforce

A namespace in Salesforce serves as a unique identifier for packages, ensuring that components from different packages do not conflict with each other. In 1GP, once you assign a namespace to a package, it is permanent and cannot be changed or removed. This binding occurs very early in the development process.

Flexibility in 2GP

In 2GP, Salesforce provides more flexibility:

Develop Without a Namespace: You can start developing your package without assigning a namespace. This is particularly useful in the early stages of development when you are still experimenting or uncertain about the final structure of your package.
Promote to Managed Package Later: Once your package is ready for distribution and you’ve finalized its components, you can then choose to assign a namespace and promote it to a managed package. This step is more definitive and suitable for packages intended for wider distribution, especially in the Salesforce AppExchange.

Example Scenario

Let’s consider an example to illustrate this flexibility:

Initial Development:
- A Salesforce developer starts creating a new application package.
- They focus on building features and components without worrying about namespaces.
- The package is in an unmanaged state and used for internal testing and iteration.
Iteration and Testing:
- The developer and the team test and refine the package, still without a namespace.
- They share this version within their organization for feedback and further development.
Finalizing the Package:
- Once the package is mature and ready for broader distribution, the developer decides to promote it to a managed package.
- At this point, they assign a namespace to the package. This namespace uniquely identifies the package, especially if it is to be listed on Salesforce AppExchange.
Release and Distribution:
- With the namespace assigned, the package is now a managed package.
- It can be distributed externally, with the namespace ensuring no conflicts with other Salesforce packages or components.

This flexibility allows developers to work more iteratively and make decisions about namespaces at a more appropriate time in the development lifecycle, instead of being forced to commit to a namespace at the very beginning.

Modular Development

The concept of “Modular Development” in Salesforce, especially with 2nd Generation Packaging (2GP), refers to the ability to break down a Salesforce application into smaller, independent packages, known as unlocked packages. These packages can be developed, updated, and deployed independently of each other. This approach contrasts with the more monolithic structure often seen in 1st Generation Packaging (1GP).

Detail

Understanding Modular Development

Small, Independent Units: Instead of a single large package containing all components of an application, modular development focuses on creating smaller packages, each responsible for a specific feature or functionality.
Reduced Dependencies: These modules or packages have fewer dependencies on each other, making them easier to manage and update.
Flexibility in Deployment: Each module can be deployed independently, allowing for more frequent and targeted updates without affecting the entire application.

Example Scenario

Let’s consider an example to illustrate modular development in a Salesforce context:

Scenario: A CRM Application for a Sales Organization

Breaking Down the Application:
- The CRM application has several distinct features: Lead Management, Opportunity Tracking, Customer Support, and Reporting.
- Instead of creating one large package containing all these features, the development team decides to break down the application into four separate unlocked packages, one for each feature.
Independent Development:
- Different teams or developers work on each package independently.
- The Lead Management team can make changes and updates to their package without impacting the Opportunity Tracking module, and so on.
Iterative Releases:
- As the Customer Support module is ready for an update, it can be released and deployed to the Salesforce org without waiting for changes in other modules.
- This allows for faster release cycles and more immediate delivery of specific features or fixes.
Maintaining Consistency:
- Even though the modules are developed independently, overall consistency in design and functionality is maintained.
- Common components or services can be shared across modules, but the core development and deployment are done independently.
Scalability and Maintenance:
- As the organization grows and needs evolve, new modules (like a new Advanced Analytics module) can be added without disrupting existing ones.
- Maintenance and updates become more manageable, as they can be targeted to specific modules.

In this example, modular development allows the Salesforce application to be more flexible, scalable, and manageable, with the ability to adapt and evolve as needs change. Each module or package, being self-contained, reduces complexity and enhances the agility of the development process.

Improved Dependency Management

“Improved Dependency Management” in the context of 2nd Generation Packaging (2GP) in Salesforce refers to the enhanced ability to manage the relationships and dependencies between different packages and their components. This feature is particularly important when dealing with complex applications that consist of multiple interrelated packages.

Detail

Traditional Dependency Management Challenges

In 1st Generation Packaging (1GP), managing dependencies can be challenging:

Rigid Structure: Dependencies are often hard-coded and inflexible, making it difficult to update or change dependent packages without affecting others.
Versioning Constraints: Updating a package could require updating all dependent packages, even for minor changes.
Complex Upgrades: Upgrading interdependent packages could lead to compatibility issues, requiring extensive testing and coordination.

Improved Dependency Management in 2GP

2GP addresses these challenges:

Flexible Dependencies: Dependencies in 2GP can be defined more flexibly. You can specify version ranges for dependencies, allowing dependent packages to work with multiple versions of other packages.
Independent Upgrades: Packages can be upgraded independently, reducing the cascading effect of changes across multiple packages.
Clear Dependency Hierarchy: 2GP allows for a clearer and more manageable dependency hierarchy, making it easier to understand how different packages are related.

Example Scenario

Let’s consider a Salesforce application comprising multiple packages:

Scenario: An E-commerce Salesforce Application

Application Structure:
- The application consists of several packages: UserManagement, OrderProcessing, InventoryManagement, and PaymentGateway.
Dependency Relationships:
- OrderProcessing depends on UserManagement for customer data.
- InventoryManagement is required by OrderProcessing to check stock levels.
- PaymentGateway is independent but is used by OrderProcessing.
Upgrading a Package:
- The team decides to upgrade UserManagement to add new features.
- In 1GP, this might have required simultaneous updates to OrderProcessing (and potentially InventoryManagement), leading to a complex, coordinated release.
2GP Approach:
- With 2GP, UserManagement can be upgraded independently.
- OrderProcessing is set to work with a range of versions of UserManagement, so it continues to function without immediate updates.
- The team can plan and execute updates to OrderProcessing and InventoryManagement separately, at a more convenient time, reducing the complexity of the deployment.
Result:
- The upgrade of UserManagement is simpler and less risky.
- Other packages continue to operate normally, and their upgrades can be managed independently, aligning with the team’s schedule and resources.

In this example, improved dependency management in 2GP allows for more flexible and less disruptive upgrades and changes within a complex Salesforce application ecosystem. This approach simplifies managing complex applications, especially those with multiple interdependent packages.

Scratch Orgs and Isolation

The concept of “Scratch Orgs and Isolation” in Salesforce, particularly in the context of Salesforce DX and 2nd Generation Packaging (2GP), refers to the use of scratch orgs as temporary, disposable Salesforce environments for development and testing. This approach promotes cleaner and more isolated development practices.

Detail

Understanding Scratch Orgs

A scratch org is a short-lived Salesforce environment that can be quickly set up, used for development or testing, and then discarded. These orgs are fully configurable, allowing developers to emulate different Salesforce editions and features.

Isolation in Development

The key aspect here is isolation. Each developer can work in their own scratch org without impacting others or the main Salesforce environment. This isolation reduces the risk of conflicts and ensures that changes are tested in a controlled environment before being merged into the main codebase.

Example Scenario

Scenario: Developing a New Feature for a Salesforce Application

Initial Setup:
- A development team is working on a Salesforce application.
- They decide to add a new feature, let’s say, an enhanced reporting tool.
Creating Scratch Orgs:
- Each developer on the team creates their own scratch org using Salesforce DX.
- These scratch orgs are configured to mimic the production environment but are completely isolated.
Development Work:
- Developers work independently in their scratch orgs, developing different parts of the new feature.
- They can experiment and test their changes without affecting the main application or each other’s work.
Local Testing:
- Once a developer completes a part of the feature, they test it thoroughly in their scratch org.
- Because the scratch org is a controlled environment, they can easily reset or recreate it if needed.
Code Integration:
- After testing, the developer commits their changes to a shared version control system like Git.
- The team reviews the changes through pull requests or code reviews.
Merging and Final Testing:
- Once approved, the changes are merged into the main branch.
- The integrated feature is then deployed to a staging or testing environment for final testing.
Scratch Org Disposal:
- After the development work is completed, the scratch orgs can be disposed of.
- This disposal ensures that no unnecessary environments are left consuming resources.

In this example, scratch orgs provide a clean, isolated environment for each developer, fostering a development process where changes are tested and validated independently before being integrated. This approach leads to higher code quality and a more efficient development lifecycle.

Wrapping it up 👏

Salesforce 2GP represents a significant advancement in Salesforce application development. It brings a level of flexibility, modularity, and efficiency previously unattainable in the Salesforce ecosystem. By enabling modular development, offering flexible namespace usage, improving dependency management, and leveraging scratch orgs for isolated development, 2GP empowers developers to build more robust, scalable, and maintainable Salesforce applications. As Salesforce continues to evolve, 2GP stands as a testament to its commitment to innovation and developer empowerment.

Cheers! 🍺

Mastering Git Diff - A Comprehensive Guide with Advanced Examples

Yoonsoo Park — Sat, 27 Jan 2024 00:00:00 +0000

In the realm of version control with Git, understanding the git diff command is crucial for developers. This post not only explores the basics but also dives into advanced uses of git diff, complete with detailed examples and code blocks for a comprehensive understanding.

Basic Usage of Git Diff

1. Viewing Uncommitted Changes

git diff

This command shows the differences between your working directory and the index (staging area). It’s helpful to review changes before staging them.

Example:

Suppose file.txt originally contains “Hello, World!” and you add “New line” to it. Running git diff will show:

1
2
3
4
5
6
7


diff --git a/file.txt b/file.txt
index ce01362..b6fc4c8 100644
--- a/file.txt
+++ b/file.txt
@@ -1 +1,2 @@
 Hello, World!
+New line

2. Viewing Changes That Are Staged for Commit

git diff --staged

This compares your staged changes with the last commit, useful for a final review before committing.

3. Comparing Two Files Within the Working Directory

git diff -- file1.txt file2.txt

This compares two local files, showing differences even if they aren’t tracked by Git.

Advanced Usage of Git Diff

1. Difference Between Two Branches

git diff main..feature-branch

This shows the changes between the main branch and feature-branch, useful for reviewing changes before merging branches.

Example:

Suppose in your main branch, you have a file hello.txt with “Hello, World!”, and in your feature-branch, it’s changed to “Hello, Git World!”. The command git diff main..feature-branch will show the differences.

2. Difference Between Two Commits

git diff <HASH-OLDER-COMMIT>..<HASH-NEWER-COMMIT>

This is for comparing specific commits, perhaps to understand the changes introduced in a feature branch.

3. Diff a File Across Branches or Commits

git diff main feature-branch file.txt

This focuses on how a single file (file.txt) differs between the main branch and feature-branch.

4. Diff a File Over Time in the Same Branch

First step: git log --before="2023-01-01" --after="2022-01-01" --follow -- file.txt

Then: git diff <old-commit-hash>..<new-commit-hash>

This combination is great for tracking a file’s evolution over a specified period.

5. Diff a File That Has Been Renamed

git diff <old-commit-hash>..<new-commit-hash>

Git automatically tracks renamed files post Git 2.9, making it easier to see changes to files even after renaming.

Advanced Features

Combining Diffs

git diff <commit1>..<commit2>..<commit3>

This aggregates changes from multiple commits into one view, simplifying code review or audits.

Diff with Context

git diff --unified=5 <commit1>..<commit2>

This shows more surrounding lines (context) around changes for better understanding.

Word Diff

git diff --word-diff <commit1>..<commit2>

It breaks down the differences to the word level, offering a more granular view.

Ignoring Space Changes

git diff -w <commit1>..<commit2>

This ignores white space changes, focusing only on actual content changes.

Wrapping it up 👏

Understanding git diff at both basic and advanced levels empowers developers to effectively track and understand changes in their codebase. Whether it’s a quick check of unstaged changes or a detailed comparison of branches, git diff proves to be an invaluable tool in the software development lifecycle. A deep dive into git diff not only enhances your Git proficiency but also contributes to better collaboration and code quality in your projects.

Cheers! 🍺

How to Check if Google Analytics is Working

Yoonsoo Park — Thu, 25 Jan 2024 00:00:00 +0000

Ensuring that your Google Analytics is set up correctly is crucial for accurately tracking your website’s traffic. While the Realtime report in Google Analytics provides immediate data about active users on your site, it doesn’t guarantee the absence of issues like duplicate tracking codes, which can distort your data significantly.

To accurately check your website for such discrepancies, Google offers a powerful tool: the Google Tag Assistant. This tool is not just a basic checker; it’s an essential instrument for anyone serious about accurate data analytics.

How to Use Google Tag Assistant Tool

Google Tag Assistant allows you to identify and fix issues such as duplicate tracking codes, ensuring that your data reflects actual user behavior. Here’s how you can use this tool to verify your Google Analytics setup:

Access Tag Assistant: Start by visiting tagassistant.google.com.
Choose Your Assessment Method: You have two options: assess a domain directly on the site or use the Tag Assistant Companion browser extension in Chrome for a more integrated experience.

3. Add Your Domain: Click the ‘Add domain’ button to start the assessment process for your specific domain.

4. Connect Your Domain: After clicking ‘Connect’, your website will open in a new window. Don’t close this window; it’s crucial for the assessment process.

5. Review Installed Tags: Return to the Tag Assistant tab to review the tags installed on your site. This is where you can see if you have any duplicate or incorrect implementations. In our example, we noticed a UA container and a Google Analytics 4 container.

By following these steps, you’re not just checking if Google Analytics is working; you’re ensuring that it’s working correctly. The Tag Assistant tool is a definitive way to verify your setup, giving you confidence in the data you’re using to make important business decisions.

Wrapping it up 👏

Accurate data is the cornerstone of effective web analytics. By utilizing the Google Tag Assistant, you’re taking a crucial step towards ensuring the integrity of your data. Remember, in the world of analytics, precision matters. Don’t just track; track correctly. Cheers to data-driven success!

Cheers! 🍺

Understanding Git Revert vs. Manual Reversion - Best Practices for Code Rollbacks

Yoonsoo Park — Wed, 24 Jan 2024 00:00:00 +0000

When it comes to undoing changes in your codebase, Git offers powerful tools that help maintain stability and traceability in your projects. Two common methods for reverting changes are using the git revert command and manually reverting through a series of commands including git checkout. Both methods have their uses, but understanding their nuances is key to choosing the right approach for your situation. In this article, we will explore each method, complete with examples, to help you make informed decisions when you need to roll back changes. Let’s go.

Method 1: Using Git Revert

The git revert command is the standard way to undo changes in Git. It creates a new commit that reverses the changes made by a previous commit. This method doesn’t alter the project’s history, making it safe and transparent, especially in collaborative environments.

Example of Git Revert

Imagine you’ve made a commit that unexpectedly breaks your application. The commit ID is abc1234. To revert this commit, you would use the following commands:

1
2
3


git revert abc1234
git commit -m "Revert commit abc1234 that broke the application"
git push

This sequence of commands creates a new commit that undoes the changes made in commit abc1234, then pushes this new commit to your remote repository.

Benefits of Git Revert

Preserves History: Keeps the original commit in the history, alongside the revert commit, maintaining a complete and traceable record.
Collaboration Friendly: Clearly communicates the reversion to team members, maintaining clarity in shared repositories.

Method 2: Manual Reversion with Git Checkout

The manual reversion method involves checking out the state of a specific commit, manually resetting your files to that state, and then creating a new commit with those changes. This method gives you more control but requires careful handling to ensure clarity and traceability.

Example of Manual Reversion

Suppose you want to revert to the state of your project at commit def5678. You would use the following sequence of commands:

1
2
3
4


git checkout def5678 .
git add .
git commit -m "Manually reverting to the state of commit def5678"
git push

This sequence manually reverts your project to the state of commit def5678 and then pushes this new state to your remote repository.

Benefits of Manual Reversion

More Control: Allows you to manually adjust the state of your files, offering flexibility in complex scenarios where an automatic revert might not suffice.
Hands-On Approach: Useful for quick rollbacks locally or when you want to carefully craft the state of your project.

Choosing the Right Method

While both methods can revert changes, choosing the right one depends on your specific needs:

Use git revert when:
- You’re working in a collaborative environment.
- You need to maintain a clear and traceable history.
- The changes you’re reverting are straightforward and don’t require manual intervention.
Consider manual reversion when:
- The changes you need to revert are complex or require manual intervention.
- You’re working locally and need a quick rollback, and you’re confident about managing your project’s history.

Wrapping it up 👏

Whether you choose the automated git revert or the manual checkout and commit approach, understanding the implications of each method on your project’s history and collaboration dynamics is key. Use git revert for its clarity and traceability, especially in collaborative settings. Opt for manual reversion when you need more control over the process. Remember, the goal is not just to undo changes, but to do so in a way that maintains the integrity and understandability of your project history.

Cheers! 🍺

Navigating the 'CNAMEAlreadyExists' Error in AWS CloudFront

Yoonsoo Park — Tue, 23 Jan 2024 00:00:00 +0000

Tackling the AWS CloudFront ‘CNAMEAlreadyExists’ Error

Embarking on a website deployment journey with AWS is generally seamless, yet you might occasionally encounter specific roadblocks. A prevalent one is the CNAMEAlreadyExists error during the creation of a CloudFront distribution. This article aims to demystify this error and provide a detailed walkthrough to effectively address it.

Deciphering the ‘CNAMEAlreadyExists’ Error

The CNAMEAlreadyExists error emerges when attempting to inaugurate a new CloudFront distribution with a domain name (alias) that’s already in use by another distribution. Imagine the confusion of assigning identical phone numbers to two separate phones — the network would be at a loss directing calls!

Here’s a typical manifestation of this error:

Error: error creating CloudFront Distribution: CNAMEAlreadyExists: One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution.

Navigational Steps to Mitigate the Error

Rectifying the CNAMEAlreadyExists error entails a series of investigative and corrective measures:

Examine Current CloudFront Distributions: Initially, scrutinize any existing CloudFront distributions for domain names (aliases) identical to your desired one. Utilize the AWS Management Console or the AWS CLI to list your distributions:
1

aws cloudfront list-distributions
Pinpoint and Rectify the Conflict: Upon discovering that the domain name is linked with another distribution, you must choose an appropriate course of action:
- Revise the existing distribution if it’s meant to host your content.
- Eliminate the conflicting alias from the existing distribution if it’s erroneously listed.
Verify DNS Configuration: Confirm that your DNS records are accurately directing to the intended CloudFront distribution. Erroneous DNS configurations can trigger this error. In my case, utilizing Google Domains as a domain provider, the issue was rooted in a Custom Record entry that became obsolete (e.g., www.my.page Type: CNAME DATA:my-old-aws-distribution.cloudfront.net.) After removing this stale record and generating a new distribution in CloudFront, functionality was restored.

Wrapping it up 👏

Encountering the CNAMEAlreadyExists error might initially seem daunting, but a thorough understanding of its origins and a systematic approach to resolution can significantly streamline your AWS deployment process. Remember, diligent scrutiny of your configurations and a profound grasp of your resource interconnections are pivotal for an uninterrupted AWS journey.

Cheers! 🍺

Harnessing the Power of Watchtower for Docker -- Automated Updates Made Simple

Yoonsoo Park — Mon, 22 Jan 2024 00:00:00 +0000

Managing Docker containers effectively is pivotal in the landscape of modern software development and deployment. Watchtower stands out as an indispensable tool, offering seamless automation for keeping your containers up-to-date. In this article, we dive into the essence of Watchtower, explore its advantages, and unravel the power of cron scheduling for orchestrating your container updates.

Why You Need Watchtower for Your Docker Containers

In the dynamic world of Docker containers, staying abreast with the latest image updates is crucial for security, performance, and stability. Manually tracking and updating each container is not just tedious; it’s also prone to human error. This is where Watchtower comes into play, transforming the update process by automating it.

Automated Updates

Watchtower automates the process of monitoring and updating your Docker containers. It periodically checks for updated images, and if found, it gracefully restarts your containers with the new image, ensuring minimal downtime and maximum reliability.

Consistent Environment

By ensuring your containers are always running the latest versions of images, Watchtower helps maintain a consistent and predictable environment, reducing the “it works on my machine” syndrome.

Security Compliance

Regular updates mean that security patches and critical updates are applied promptly, reducing the vulnerability window and keeping your containers secure.

Leveraging Cron for Scheduling Updates

One of Watchtower’s powerful features is its ability to use cron expressions for scheduling update checks. This flexibility allows you to align update checks with maintenance windows, minimize disruption, and manage resource utilization effectively.

Various Cron Use Cases

Every Day at a Specific Time:
- 0 3 * * * - Update checks every day at 3 AM. Ideal for daily routine updates during off-peak hours.
Every Monday:
- 0 0 * * 1 - Weekly updates every Monday. Suitable for weekly maintenance tasks.
Every 2nd Day of the Month:
- 0 0 2 * * - Ensures that updates are performed on the second day of each month, aligning with monthly administrative cycles.
Twice Per Month:
- 0 0 1,15 * * - Performs updates on the 1st and the 15th of each month, balancing the update load.
Every Month:
- 0 0 1 * * - Monthly updates on the first day of the month, keeping a consistent update schedule.

These are just a few examples of how cron expressions can be tailored to fit your specific operational requirements and preferences.

Integrating Watchtower with Docker Compose in Synology with Container Manager

To incorporate Watchtower into your Docker environment, you can define it in your docker-compose.yml file. Here’s an example configuration that uses Watchtower to monitor and update specified containers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


services:
 watchtower:
 image: containrrr/watchtower:latest # Specifies the use of the latest Watchtower image.
 container_name: watchtower # Sets the name of the container to 'watchtower'.
 environment: # Environment variables for configuring Watchtower behavior.
 - TZ=America/New_York # Sets the timezone to 'America/New_York'. This can be different for your case.
 - WATCHTOWER_CLEANUP=true # Enables cleaning up old images after updating.
 - WATCHTOWER_INCLUDE_STOPPED=true # Includes stopped containers in the monitoring and updating process.
 - WATCHTOWER_REVIVE_STOPPED=false # Prevents restarting containers that were stopped.
 - WATCHTOWER_SCHEDULE=0 30 8 * * 1 # Sets the schedule for running Watchtower (every Monday at 8:30 AM).
 command: # Specifies which containers Watchtower should monitor and potentially update.
 - jellyseerr
 - prowlarr
 - radarr
 - sonarr
 - watchtower
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock # Mounts the Docker socket to allow Watchtower to interact with the Docker API.
 restart: unless-stopped # Configures the container to restart automatically unless it is explicitly stopped.

In this setup, Watchtower is configured to check for updates every Monday at 8:30 AM (Eastern Time). It will monitor the containers jellyseerr, prowlarr, radarr, sonarr, and watchtower itself, and will clean up old images after updating. The configuration ensures that stopped containers are included in the monitoring but prevents restarting containers that were stopped before the update.

Wrapping it up 👏

Watchtower revolutionizes container management by automating the update process, ensuring that your Docker environments are secure, up-to-date, and consistent. The integration of cron scheduling adds an extra layer of precision and control, allowing updates to be seamlessly integrated into your operational workflows.

Cheers! 🍺

Understanding and Managing Narcissistic Behaviors in Everyday Life

Yoonsoo Park — Sun, 21 Jan 2024 00:00:00 +0000

In our daily interactions, whether in personal relationships or professional settings, understanding the complexities of human behavior can be crucial. One particularly challenging personality type is the narcissist. Rooted in Wendy T. Behary’s insightful book, “Disarming the Narcissist: Surviving and Thriving with the Self-Absorbed”, this blog post aims to elucidate the characteristics of narcissistic behaviors and offer pragmatic approaches for dealing with individuals who exhibit these traits.

Recognizing Narcissistic Behaviors

Narcissistic individuals often display a pattern of traits and behaviors that can be disruptive and challenging to those around them. Key characteristics include:

Grandiosity: A pervasive sense of superiority, often accompanied by an exaggeration of talents and achievements.
Example: Imagine a colleague, John, who frequently boasts about his business acumen and success. He often exaggerates his role in successful projects and claims his strategies are superior to anyone else’s in the industry. Despite evidence to the contrary, he maintains an inflated perception of his importance and capabilities.
Need for Admiration: A continuous quest for excessive attention and admiration.
Example: Sarah, a team leader, constantly seeks validation and praise from her peers and subordinates. She requires her team to commend her for every decision she makes, regardless of its impact, and becomes noticeably upset or agitated when her work isn’t acknowledged or praised excessively.
Sense of Entitlement: Unreasonable expectations of especially favorable treatment and automatic compliance with their expectations.
Example: Mark expects special treatment at work. He believes he should be exempt from regular duties such as submitting reports on time or attending mandatory meetings. When asked to comply, he reacts indignantly, questioning why he, given his perceived status, should follow the same rules as everyone else.
Exploitative Relationships: Taking advantage of others to achieve personal ends without empathy or consideration.
Example: Lisa often manipulates her colleagues to do her work under the guise of needing help due to her “overwhelming” workload. She rarely reciprocates or acknowledges their assistance and is quick to take full credit for the collective efforts and successes.
Lack of Empathy: An inability or unwillingness to recognize and honor the feelings and needs of others.
Example: During a team crisis where everyone is under stress, Alex remains indifferent to his colleagues’ struggles. He dismisses their concerns and emotions, focusing solely on how the situation benefits or harms his personal agenda, showing little to no regard for the collective morale or well-being.
Envy: Feelings of resentment towards others’ achievements or a belief that others are envious of them.
Example: Whenever a co-worker receives a compliment or a promotion, Emily reacts with subtle derogatory remarks or attempts to undermine their achievements. She feels resentful when others succeed or are recognized, perceiving it as a direct threat to her status.
Arrogance: Displaying snobbish, disdainful, or patronizing attitudes.
Example: In meetings, Tom often talks down to his peers, dismissing their ideas and input as inferior or irrelevant. He displays a patronizing attitude, believing his insights are the only ones of value and expecting others to conform to his viewpoint without question.

It’s worth noting that these traits can be present in anyone and may not necessarily indicate a personality disorder. However, when these behaviors are pervasive, persistent, and negatively impact one’s life and relationships, they can be indicative of Narcissistic Personality Disorder (NPD).

Strategies for Dealing with Narcissists

In “Disarming the Narcissist,” Behary not only paints a detailed picture of the narcissistic personality but also offers valuable strategies for interacting with individuals exhibiting these traits. Some of these strategies include:

Setting Clear Boundaries: Communicate your limits assertively and consistently to prevent boundary overstepping.
Avoiding Power Struggles: Engage selectively in conflicts. Focus on maintaining personal peace and professional integrity instead of winning every battle.
Using ‘We’ Language: Frame discussions in an inclusive manner to avoid triggering defensiveness and encourage cooperation.
Acknowledging Their Strengths: Recognize and appreciate the narcissist’s abilities and achievements to make them more receptive to communication.
Keeping Emotions in Check: Stay calm and composed, especially when the narcissist tries to provoke emotional reactions.
Seeking Support: Build a support network for guidance and validation when dealing with challenging dynamics.
Documenting Interactions: Keep records of interactions, especially in professional settings, to maintain an objective account of events.
Focusing on Solutions: Steer conversations towards constructive outcomes rather than dwelling on problems.

Wrapping it up 👏

Navigating relationships with narcissistic individuals can be challenging, but with understanding and the right strategies, it’s possible to maintain a sense of balance and peace. The book, “Disarming the Narcissist: Surviving and Thriving with the Self-Absorbed”, provides not just a lens to understand narcissism but also practical tools to manage and thrive in the presence of narcissistic behaviors. Whether in personal relationships or professional arenas, these insights are invaluable for fostering healthier and more constructive interactions.

Instead of falling into the role of a victim, arm yourself with these strategies and tame them.

Here’s to all who bravely navigate these turbulent waters! Godspeed. Cheers. 🍺

Mastering Environment Variables in Shell Scripts -- The Power of .env, set -a, and set +a

Yoonsoo Park — Sat, 20 Jan 2024 00:00:00 +0000

Managing environment variables effectively is crucial in the realm of shell scripting, especially when dealing with complex projects that rely on external configurations. Traditionally, the source command is used to import variables from .env files. However, this article takes you a step further, illustrating the meticulous art of combining .env files with the set -a and set +a shell commands for a more robust and secure approach to environment variable management.

Understanding the Basics

Before diving deep, it’s important to grasp the basics. An environment variable is a dynamic-named value that can affect the way running processes will behave on a computer. For instance, they can store information about the default text editor or browser, the path to executable files, or the system locale and language.

.env files are a simple and popular method to configure environment variables. They are plain text files containing key-value pairs, making them easy to create and manage. However, variables defined in .env files aren’t automatically available in the shell script. They need to be explicitly imported.

The Role of `source .env`

The source command, used as source .env, executes the file passed as an argument, in the current shell. It reads and imports environment variables from .env into the shell session, but it doesn’t export them to child processes by default.

Elevating with `set -a` and `set +a`

This is where set -a and set +a come into play. These commands elevate the way environment variables are handled in shell scripts.

set -a (Automatic Export): When you run set -a before sourcing your .env file, it automatically exports the variables defined after it. This means the variables are not just available to the script but also to any subprocesses or commands that the script executes. It ensures that the environment is consistent and predictable, not just in your script but in other tools or scripts that your script might call.
set +a (Revert Automatic Export): After importing your variables, set +a is used to revert the shell back to its default behavior. It’s a good practice, preventing any further variables from being automatically exported. This limits the scope of set -a to only the variables you intend to export, minimizing side effects and enhancing security.

Why Use `set -a` and `set +a`?

Using these commands provides several benefits:

Explicitness & Clarity: Clearly shows the intent to export the variables, making scripts more readable and maintainable.
Security: By isolating the export behavior to a specific block of code, you reduce the risk of unintentionally exposing variables.
Consistency & Compatibility: Ensures consistent behavior in variable exportation across different environments and shell versions.

Practical Example: Deploying a Web Application

Imagine you're tasked with deploying a web application. This application requires several environment variables to run, such as database connection strings, API keys, and configuration flags. These variables differ between development, staging, and production environments.

Steps in the Deployment Script

Your deployment script might include steps like:

Setting Up the Environment: Load environment variables from a .env file corresponding to the target environment (development, staging, or production).
Running Database Migrations: Execute scripts to set up or update the database schema.
Starting Services: Start the application backend, frontend, and any auxiliary services, each of which requires access to the environment variables.

Why `set -a` and `set +a` are Useful Here

Isolation of Environment Variables: You have a .env file for each environment (.env.development, .env.staging, .env.production). Using set -a and set +a ensures that only the variables from the specific .env file are exported, preventing any accidental overlap or leakage between environments.
Ensuring Subprocess Compatibility: The database migration scripts, backend, frontend, and auxiliary services are likely separate processes or even separate scripts that are called from your main deployment script. By using set -a, you ensure that these subprocesses inherit the necessary environment variables, ensuring a smooth and predictable deployment process.
Security and Cleanliness: After loading and exporting the necessary variables, set +a is used to prevent any future variables defined in your script from being automatically exported. This is particularly important for maintaining the security and cleanliness of your environment, as only the necessary variables are exposed to subprocesses.

Script Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


#!/bin/sh

# Choose the right .env file based on the target environment
ENV_FILE=".env.production"

# Automatically export variables
set -a
source $ENV_FILE
set +a

# Run database migrations
./run_database_migrations.sh

# Start services
./start_backend.sh
./start_frontend.sh
./start_aux_services.sh

# ... rest of your deployment script

In this script:

set -a ensures all variables from .env.production are exported and available to the run_database_migrations.sh, start_backend.sh, start_frontend.sh, and start_aux_services.sh scripts.
set +a ensures that any variables defined or modified after this point in the script are not automatically exported, maintaining a clean and secure environment.

Conclusion

While source .env works fine for simple cases, the combination of set -a and set +a offers a controlled, secure, and clear approach to managing environment variables in shell scripts. It’s a testament to the thoughtfulness that goes into professional script writing, ensuring that your scripts work predictably and securely, no matter the complexity.

In the world of shell scripting, mastering the nuances of environment variables can significantly improve the robustness and reliability of your scripts. Embracing these practices is a step towards writing cleaner, more maintainable, and secure code.

Cheers! 🍺

Mastering ChatGPT for Efficient Software Development

Yoonsoo Park — Fri, 19 Jan 2024 00:00:00 +0000

In the realm of software development, integrating AI tools like ChatGPT can transform the way we approach projects. ChatGPT’s ability to understand and interact in a human-like manner makes it an invaluable asset. This article provides a clear guide to embedding ChatGPT into your software development workflow, highlighting its role in three key phases: Project Management, Architectural Design, and Software Engineering.

Remember: For optimal results, it’s essential to conduct these phases within a single chat session with ChatGPT, as it cannot retain information across sessions.

Phase 1: Project Management

Goal: Build a strong project framework by precisely defining and honing project scope and requirements.

Method:

Initiation:
- Define your project goals, objectives, and limits to ChatGPT, treating it as an AI project manager.
- Ensure ChatGPT fully grasps your project’s vision and requirements, establishing a collaborative rapport.
Requirement Gathering:
- Use ChatGPT for a fluid discussion to refine requirements, prompting it to ask for clarifications.
- Confirm requirements align with business goals and technical feasibility, using ChatGPT’s analysis skills.
Specification Drafting:
- Assign ChatGPT to create a detailed project specification or proposal, based on the refined requirements.
- Continuously refine the document for clarity and actionability.

Example Prompt:

“You are a software project manager. I need to convert the manual process of retrieving metadata from a Salesforce org into an automated system. Please help refine these requirements and feel free to ask for any clarifications.”

Phase 2: Architectural Design

Goal: Develop a robust and adaptable technical blueprint for the system.

Method:

Architectural Analysis:
- Provide the project specifications to ChatGPT, now acting as a senior software architect.
- Engage ChatGPT in a critical analysis of the plan, encouraging enhancement and questioning based on best practices.
Structure & Library Identification:
- Instruct ChatGPT to propose a file structure and identify necessary libraries, focusing on scalability and performance.
- Document the architecture thoroughly in a format like JSON or YAML.

Example Prompt:

“You are a senior software architect. please critique and enhance this plan based on best practices. Outline the file structure and identify essential libraries for scalability and performance. Document the architecture meticulously in JSON format.”

Phase 3: Software Engineering

Goal: Realize the architectural blueprint through precise coding.

Method:

Implementation Strategy:
- Introduce the architectural design to ChatGPT in its role as a software engineer.
- Plan the development sequence, focusing on priorities outlined in the architectural plan.
Pseudocode Development:
- Direct ChatGPT to write detailed pseudocode for each module, detailing inputs, processes, and outputs.
- Align this pseudocode with the overall architectural plan and project requirements.
Code Iteration:
- Progress from pseudocode to actual coding, following best practices and the selected programming language.
- Continuously refine and optimize the code for performance and functionality.

Example Prompt:

“You are a senior software engineer.

Develop a strategy for the implementation sequence, prioritizing components as per the architectural roadmap.
Create detailed pseudocode for each function, specifying inputs, processes, and expected outputs, ensuring it aligns with the architectural framework and project requirements.”

Adopting this structured methodology enables you to fully leverage ChatGPT in your software development lifecycle, ensuring streamlined, innovative, and effective project delivery.

Cheers! 🍺

Run Java Applications on macOS without Global JRE Installation

Yoonsoo Park — Wed, 17 Jan 2024 00:00:00 +0000

Introduction

Java’s omnipresence in software development is unquestionable. Yet, installing Java Runtime Environment (JRE) or Java Development Kit (JDK) globally on macOS may invite version clashes or security risks. This guide delves into alternative strategies for executing Java applications (JAR files) on Mac, sidestepping the global JRE setup. We lay particular emphasis on Docker, a celebrated containerization technology.

The Perils of Global JRE Installation

Version Conflicts: Diverse Java applications may demand specific Java versions, clashing with a globally installed JRE.
Security Risks: A leaner global software footprint reduces potential vulnerabilities.
Enhanced Portability and Isolation: Containerization assures consistent application performance across varying systems.

Method 1: Application-Enclosed JRE

Encapsulate a JRE within your Java application to dodge system-wide Java conflicts.

Steps:

Acquire a JRE that aligns with your application’s and macOS’s architecture.
Embed the JRE in your application’s folder.
Forge a startup script to designate the encapsulated JRE as JAVA_HOME and initiate your application.

Method 2: Embracing Portable JRE

A portable JRE facilitates Java application execution sans system-wide Java installation.

Steps:

Procure a portable JRE suitable for macOS.
Unpack it in a directory of your choice.
Execute your JAR file using the absolute path to the java command within the portable JRE’s folder.

Method 3: Docker Deployment (Preferred)

Docker offers application execution in insulated settings. Here’s how to use Docker for your JAR file:

1. Docker Installation

Fetch Docker from the official portal and set it up on your Mac.

2. Java Application Preparation

Consolidate your JAR file and all necessary assets in a single folder.

3. Crafting a Dockerfile

In your project folder, craft a Dockerfile with these specifics:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Opt for an official Java runtime as the base image
FROM openjdk:23-slim

# Designate the working area in the container
WORKDIR /usr/app

# Transport current directory's contents into /usr/app in the container
COPY . /usr/app

# Render port 8080 accessible externally
EXPOSE 8080

# Execute the JAR file
ENTRYPOINT ["java", "-jar", "your-application.jar"]

Tweak the port and JAR file name as needed.

4. Docker Image Construction

In your terminal, within the project folder, execute:

1

docker build -t your-app-name .

5. Launching Your Application

Activate your application with:

1

docker run -p 8080:8080 your-app-name

Your Java application is now operational within a Docker container!

Wrapping it up 👏

Employing macOS to run JAR files sans a global JRE installation is streamlined with the right toolkit. Whether you opt for a bundled JRE, a portable JRE, or Docker’s robust containerization, each avenue offers distinct merits. Docker, in particular, is championed for contemporary, portable, and stable deployments. It eliminates the global JRE dependency while assuring an insulated, controlled application environment.

Cheers! 🍺

Mastering the Art of Effective Writing in the Information Era

Yoonsoo Park — Mon, 15 Jan 2024 00:00:00 +0000

The Power of Effective Writing in the Modern World

In an age brimming with media and information, the ability to write effectively has become more crucial than ever. The book “Writing for Busy Readers: Communicate More Effectively in the Real World” by Todd Rogers and Jessica Lasky-Fink emerges as a beacon for those seeking to cut through the noise and reach ‘busy’ readers. This book is not just about writing beautifully; it’s about writing effectively, a skill that has become essential in a world where people are overwhelmed with digital messages.

The Importance of Clarity and Brevity

The book emphasizes the power of brevity and clarity. Just as not everyone who sings is a great singer, not everyone who writes does it exceptionally well. Great singers hone their skills through techniques grounded in anatomy, acoustics, and cognition. Similarly, effective writers must study neuroscience and cognitive science to understand how a busy person’s brain processes written information. This understanding helps in creating content that captures attention amidst the myriad of distractions vying for a reader’s focus.

Six Principles of Effective Writing

Drawing on research in behavioral science, the authors distill their insights into six key principles:

Less is More: Conciseness is key.
Make it Easy to Read: Accessibility in writing is crucial.
Easy Navigation: Organize content for easy reference.
Appropriate Formatting: Use formatting to aid understanding, but avoid excess.
Explain Why it Matters: Make the content relevant and engaging.
Ease of Response: Facilitate a straightforward response from the reader.

These principles are not just theoretical; they are backed by practical examples and real-world applications, making them immediately applicable in various contexts, from emails to business reports.

Beyond Aesthetic Writing

The book draws a distinction between expressive, literary writing and effective writing. While the former is an art form, steeped in subjectivity and emotional depth, the latter is a science-based skill aimed at clear and direct communication. This differentiation is crucial in today’s digital age, where the goal is often to convey specific information quickly and efficiently to busy individuals.

The Practical Benefits of Effective Writing

Effective writing is not just about getting a message across; it also clarifies the writer’s own thoughts. As the book points out, clear writing leads to clear thinking. This clarity is invaluable in our fast-paced world, where misunderstandings can lead to significant time loss and frustration.

Wrapping it up 👏

Alright, wrapping things up here: “Writing for Busy Readers” is pretty much your go-to book if you want to step up your writing game in this crazy-busy world full of info overload. It’s not just about sounding smart or fancy; it’s more about getting your point across effectively, which, let’s face it, is super important these days.

If you’re into getting more details and real-life examples of how to write like a pro, definitely give this book a read. It’s packed with useful tips and tricks that’ll make a big difference in how you communicate, especially online and in the digital space.

Feel like checking it out? Here’s a link to grab a copy and see for yourself: Writing for Busy Readers: Communicate More Effectively in the Real World

Cheers! 🍺

Freeing Up Ports 80 and 443 on Synology NAS for Reverse Proxy Usage

Yoonsoo Park — Sun, 14 Jan 2024 00:00:00 +0000

Freeing Up Ports 80 and 443 on Synology NAS for Reverse Proxy Usage

Introduction

For Synology NAS users looking to implement reverse proxies such as Traefik, Nginx Proxy Manager, or Caddy, the usage of ports 80 and 443 by default NAS services can be a hurdle. These ports, often occupied by the NAS via Nginx, are essential for reverse proxy operations. Fortunately, a Bash script can efficiently reconfigure Nginx, freeing up these crucial ports.

In this article, we explore a Bash script solution for modifying the default HTTP and HTTPS ports on Synology NAS, enabling the use of ports 80 and 443 for other applications.

Understanding the Port Conflict

Synology NAS systems employ Nginx, a widespread web server, in their operating framework. Nginx, by default, listens on ports 80 (HTTP) and 443 (HTTPS). This default setting is suitable for regular operations but creates a conflict for reverse proxy servers that require these same ports.

The Solution: A Bash Script

A Bash script offers a seamless solution to reconfigure the Nginx server on Synology NAS, reallocating ports 80 and 443 for alternate use. Here’s how the script functions:

Script Breakdown

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#! /bin/bash

# NGINX Ports - CUSTOMIZATION REQUIRED
DEFAULT_HTTP_PORT=80
DEFAULT_HTTPS_PORT=443
NEW_HTTP_PORT=81
NEW_HTTPS_PORT=444

# Modifying Nginx Configuration
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTP_PORT\([^0-9]\)/\1$NEW_HTTP_PORT\2/" /usr/syno/share/nginx/*.mustache
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTPS_PORT\([^0-9]\)/\1$NEW_HTTPS_PORT\2/" /usr/syno/share/nginx/*.mustache

# Restart Nginx to apply changes
synosystemctl restart nginx

Key Aspects of the Script

Customization: Modify NEW_HTTP_PORT and NEW_HTTPS_PORT variables to designate alternative Nginx ports.
Automated Editing: Utilizes sed for replacing default ports in Nginx configuration files.
Restart Nginx: Finalizes with a command to restart Nginx, implementing the adjustments.

Implementation Steps

Create the Script:
- Copy and save the script on your Synology NAS with a .sh extension and execution permissions.
Schedule the Script:
- Set it to run as root at boot through DSM’s Control Panel -> Task Scheduler.
Run and Verify:
- Manually execute or reboot NAS for testing.
- Confirm port changes with tools like netstat.

Points to Remember

DSM Upgrades: Synology’s DSM updates may revert these configurations; hence, scheduling the script is vital.
Port Selection: Choose unused ports on your NAS for the new settings.
Access Control: Update firewall rules and port forwarding accordingly.

Conclusion

This Bash script provides a straightforward and effective way for Synology NAS users to employ reverse proxies by reassigning the default HTTP and HTTPS ports used by Nginx. It’s a practical solution for resolving port conflicts and enhancing the functionality of your NAS. When implementing this script, always ensure to follow network security best practices and check for any service conflicts with the new port assignments.

Adapting and verifying the script based on individual network configurations and Synology NAS models is recommended for optimal results. This approach not only solves the immediate port conflict issue but also opens up new possibilities for using your NAS for diverse applications, from hosting websites to running complex network services.

Cheers! 🍺

Unboxing Leadership - Insights from "Leadership & Self-Deception"

Yoonsoo Park — Sat, 13 Jan 2024 00:00:00 +0000

Introduction

“Leadership & Self-Deception: Getting Out of the Box” by The Arbinger Institute offers transformative guidance in the realms of leadership and personal development, focusing on the impact of self-perception on leadership abilities and interpersonal relations.

Understanding Self-Deception

Self-deception, a core theme of the book, is about having a skewed perception influenced by personal biases and justifications.

Example of Self-Deception

A manager blames his team for missed deadlines, unaware that his poor communication contributes to the issue. This is a classic case of being ‘in the box,’ seeing only from a self-justifying perspective.

Detailed Exploration of Self-Betrayal

The book dives deep into the concept of self-betrayal, an act of going against one’s inherent sense of right, leading to a distorted view of reality.

Acting Against One’s Sense of Right and Wrong: An individual ignores their innate sense of right, like a manager not listening to an employee’s concern due to busyness.
Justification of Actions: The individual justifies their action, like the manager deeming the employee’s issue as unimportant.
Distorted View of Others: This leads to a skewed perception of others, such as viewing the employee as a complainer.
Creation of a Vicious Cycle: This distorted view provokes behaviors that elicit negative responses, reinforcing the distorted perception.
Impact on Relationships and Effectiveness: Such cycles damage relationships and reduce effectiveness, hindering genuine communication and collaboration.
Breaking the Cycle: One must recognize and act contrary to self-betrayal, like a manager genuinely addressing an employee’s concerns.

Key Takeaways with Examples

Being ‘Out of the Box’

Example: A leader sees her employees as unique individuals, adjusting her management style, which enhances morale and productivity.

Resisting the Blame Game

Example: When a project fails, a supervisor reflects on his own shortcomings, leading to positive changes in future project management.

Embracing Vulnerability

Example: A CEO openly shares her challenges, fostering a collaborative and innovative environment.

Prioritizing Relationships

Example: An employee invests in understanding colleagues’ personal goals, enhancing team cooperation.

Leading with Influence, Not Authority

Example: A manager seeks team input and integrates their ideas, increasing commitment and ownership.

Reflecting and Acting

Example: A team leader, upon realizing his bias against certain ideas, consciously works to give equal consideration to all suggestions.

Encouraging Open Communication

Example: Regular open forums in an organization allow for the free expression of concerns, fostering a culture of trust and continuous improvement.

Leadership & Self-Deception: Getting Out of the Box

Cheers! 🍺

Managing Multiple Versions with Pyenv and Virtual Environments

Yoonsoo Park — Mon, 01 Jan 2024 00:00:00 +0000

Managing Multiple Versions with Pyenv and Virtual Environments

When working on multiple projects with different Python versions, it’s crucial to avoid conflicts and ensure that each project uses the correct version and dependencies. This is where virtual environments come in. They are isolated Python environments that let you manage packages and dependencies specific to a project without affecting the global Python installation.

Installing Python Using Homebrew on macOS

Before setting up virtual environments, ensure you have the desired versions of Python installed:

Install Homebrew: Install Homebrew, a package manager for macOS, with the following command: e.g.

1

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

Install Python: Use Homebrew to install the latest version of Python:
1

brew install python

Managing Multiple Python Versions with pyenv

pyenv is an indispensable tool for managing multiple Python versions:

Install pyenv: Install pyenv using Homebrew:
1

brew install pyenv
Configure Your Shell: Add the following to your shell configuration file (.bashrc, .zshrc, etc.) and restart your terminal or source the profile:
1 2

eval "$(pyenv init --path)" eval "$(pyenv init -)"
Install Python Versions: Install the desired Python versions:
1 2

pyenv install 3.8.6 pyenv install 2.7.18
Set Global Python Version: Choose a global Python version with pyenv:
1

pyenv global 3.8.6

Creating and Activating Virtual Environments

Virtual environments are created and activated to isolate project dependencies:

Creating a Virtual Environment: Navigate to your project directory and create a virtual environment:
1

python3 -m venv env
Replace env with your preferred environment name.
Activating the Virtual Environment: Activate the virtual environment to use it:
1

source env/bin/activate
Upon activation, your shell prompt might change to indicate the active environment. Now, the environment’s Python version and packages are isolated from the rest of your system.

How Virtual Environments Set the Correct Python Version and Environment Variables

When a virtual environment is activated:

Python Version: The virtual environment uses the Python version it was created with. Even if you have multiple versions installed on your system, the environment will only have access to and use the specific version it was created with.
Environment Variables: The activation script adjusts environment variables like PATH to ensure that when you invoke python or pip, you’re using the versions installed in the virtual environment’s bin directory. This means any Python scripts you run or packages you install will be confined to the virtual environment.
Isolation: This isolation prevents different projects from interfering with each other’s dependencies. Each virtual environment operates independently, with its own Python binaries and site packages.

Deactivating Virtual Environments

To stop using a virtual environment and revert to your global Python setup, simply run:

1

deactivate

Your shell’s prompt will return to normal, and you’ll be using the global Python version and packages again. Cheers! 🍺

How to Uninstall Salesforce CLI from a Specific Node.js Version on macOS

Yoonsoo Park — Fri, 01 Dec 2023 01:25:00 -0400

Introduction:

When working with multiple versions of Node.js, especially in a development environment that leverages Salesforce CLI, it’s not uncommon to encounter challenges in managing different package versions. This can often lead to confusion and, sometimes, a frustrating experience when trying to uninstall or switch between versions of Salesforce CLI (sfdx-cli) across different Node.js versions. In this article, we’ll explore a systematic approach to troubleshoot and resolve these issues, ensuring a smoother development experience.

Understanding the Environment:

Before diving into the solution, it’s crucial to understand how Node.js versions and npm (Node Package Manager) work in tandem. Node.js is a runtime environment for executing JavaScript outside the browser, and npm is its package manager. When you install Node.js, npm comes bundled with it. If you are using a version manager like nvm (Node Version Manager), each version of Node.js can have its own separate npm environment and set of global packages.

The Challenge with Salesforce CLI:

Salesforce CLI (sfdx-cli) is a powerful command-line interface that simplifies development and build automation when working with Salesforce applications. However, when you have multiple Node.js versions, each with its own Salesforce CLI installation, managing these versions can become complex.

Step-by-Step Troubleshooting:

Identifying the Active Node.js Version: Begin by determining which version of Node.js is active. If you’re using nvm, you can switch between versions easily. For example, nvm use 20 activates Node.js version 20.
Listing Global npm Packages: To see if Salesforce CLI is installed under the active Node.js version, use npm list -g --depth=0. This command lists all globally installed packages.
Uninstalling Salesforce CLI: If you find sfdx-cli listed, uninstall it using npm uninstall -g sfdx-cli. This should remove it from the global npm environment of the active Node.js version.
Navigating Multiple npm Instances: Remember, each Node.js version has its own npm environment. Repeat the listing and uninstallation process for each Node.js version where sfdx-cli is installed.
Checking the PATH: Your system’s PATH environment variable might still reference sfdx-cli. Inspect it with echo $PATH and manually search the directories for any lingering sfdx-cli instances.
Manual Removal: If necessary, manually remove the sfdx-cli executable. Locate it with which sfdx and delete it using rm.
Reinstalling Salesforce CLI: If you accidentally remove the wrong version, simply reinstall Salesforce CLI under the correct Node.js version.
Restarting the Terminal: After uninstallation, restart your terminal to ensure all changes take effect.
Verification: Verify the removal by executing sfdx --version. An error message should indicate successful uninstallation.

Happy Friday. Cheers! 🍺

Mastering Domain-Driven Design - Best Practices and Pitfalls

Yoonsoo Park — Thu, 30 Nov 2023 01:25:00 -0400

Navigating the World of DDD: Do’s and Don’ts

Welcome back, tech enthusiasts! We’ve explored the exciting world of Domain-Driven Design (DDD), but as with any powerful tool, it’s crucial to know how to wield it effectively. Let’s dive into some essential do’s and don’ts that can make or break your DDD journey.

DDD: The Do’s

1. Embrace Ubiquitous Language

Do: Develop a common language that’s understood by all team members, regardless of their technical background. This ensures that everyone is on the same page and reduces misunderstandings.
Don’t: Allow jargon or technical terms to dominate discussions, as this can alienate non-technical stakeholders and create barriers.

2. Focus on the Domain Model

Do: Invest time in creating a robust and accurate domain model that reflects the business’s needs and realities. This model should be the heart of your project.
Don’t: Rush the modeling process or overlook the nuances of the business domain. An oversimplified or inaccurate model can lead to flawed software design.

3. Utilize Bounded Contexts

Do: Clearly define and respect the boundaries of each context within your domain. This helps in managing complexity and maintaining focus.
Don’t: Ignore the boundaries between contexts or allow them to become blurred, as this can lead to a tangled, hard-to-maintain codebase.

4. Engage in Continuous Learning

Do: Encourage ongoing learning and collaboration among team members. DDD is as much about people and processes as it is about technology.
Don’t: Become complacent or stop evolving your understanding of the domain. DDD requires a mindset of continuous improvement.

DDD: The Don’ts

1. Avoid Over-Engineering

Do: Keep solutions as simple and as relevant to the domain as possible.
Don’t: Overcomplicate your design with unnecessary patterns or technologies that don’t serve the domain’s needs.

2. Beware of Siloed Knowledge

Do: Foster a culture of shared knowledge and collaboration.
Don’t: Allow knowledge to become siloed within specific individuals or teams. This can create bottlenecks and dependencies.

3. Resist the One-Size-Fits-All Approach

Do: Tailor your approach to the specific needs and nuances of each project.
Don’t: Apply DDD principles rigidly or dogmatically. What works for one project may not work for another.

4. Don’t Ignore Non-Technical Stakeholders

Do: Involve business experts and other non-technical stakeholders actively in the process.
Don’t: Develop in isolation from the rest of the business. DDD is a collaborative approach that requires input from all sides.

Wrapping Up

Domain-Driven Design is a powerful methodology that, when used wisely, can greatly enhance your software development projects. By following these do’s and don’ts, you can avoid common pitfalls and leverage DDD to its fullest potential.

Remember, DDD is not just about writing code; it’s about understanding and solving real business problems in a collaborative, efficient, and sustainable way. Happy coding, and here’s to building great software! 🍺

I wholeheartedly recommend “Domain-Driven Design: Tackling Complexity in the Heart of Software” to engineers whose teams have embraced the DDD concept but are struggling to grasp its core principles and practical applications. My reading experience was not only delightful but also immensely enlightening, turning me into a staunch advocate for DDD within my workplace. This book is a definitive guide that can illuminate the path for anyone looking to master DDD.

Deep Dive into Domain-Driven Design - Simplifying Complex Projects

Yoonsoo Park — Wed, 29 Nov 2023 01:25:00 -0400

Greetings, Tech Aficionados!

In our journey through the innovative world of software development, we’ve stumbled upon a gem: Domain-Driven Design (DDD). It’s a transformative approach that’s reshaping how we build software. Remember the old days when a dev would unveil a complex diagram, leaving PMs in a daze? Let’s replace that confusion with clarity using DDD and its trusty sidekick, Domain Storytelling.

The Prelude: The Need for DDD

Imagine being handed a list of requirements for a new software project. Sounds straightforward, right? But without understanding the actual problems and user pain points, this approach often leads to miscommunication and inefficiency. That’s where DDD swoops in.

Understanding Domain-Driven Design

DDD is not just a set of practices; it’s a philosophy that puts the project’s domain at the heart of every decision. Here’s what it entails:

Ubiquitous Language: This is the cornerstone of DDD. It’s about creating a common language that’s shared among all stakeholders, from developers to business analysts. This language is used to describe all aspects of the project, ensuring clear communication and understanding.
Model-Driven Design: In DDD, the focus is on creating a robust domain model that accurately represents the business domain. This model guides the design of the software, ensuring that it aligns with the business needs.
Bounded Contexts: DDD divides the domain into multiple bounded contexts, each representing a distinct part of the domain with its own model. This helps in managing complexity by isolating different parts of the domain.
Context Mapping: Understanding how these bounded contexts interact with each other is crucial. Context mapping helps in identifying and managing these relationships, ensuring that the overall system remains cohesive.

The Charm of Domain Storytelling

With DDD as our foundation, Domain Storytelling becomes an incredibly powerful tool. It’s about narrating the user’s journey and turning it into a shared vision for the project.

Crafting the Story:

Inclusive Gatherings: Bring together all stakeholders, ensuring everyone’s voice is heard.
Narrative Over Diagrams: Use simple, relatable stories to describe user interactions, avoiding technical complexities.

The Art of Pictographic Language:

Simple Elements: Use symbols like actors, work objects, actions, and sequence numbers to depict the story.
Guiding Principles: Avoid repeating actors, focus on scenarios, and consider the scope in terms of granularity and digital versus physical interactions.

Applying DDD; The Scenario: Car Purchase Journey

Imagine a scenario where a customer is looking to purchase a car on installments. This process involves several steps and stakeholders, making it an ideal candidate for applying DDD.

Step 1: Understanding the Domain

Identify Key Entities: Our domain involves entities like Customer, Car, Salesperson, Finance Agreement, etc.
Develop Ubiquitous Language: Establish common terms understood by all stakeholders. For example, “Finance Agreement” is a term everyone understands the same way.

Step 2: Creating the Domain Model

Model the Entities and Their Relationships: Map out how these entities interact. For example, a Customer chooses a Car, interacts with a Salesperson, and signs a Finance Agreement.
Focus on Business Logic: The domain model should capture the logic and rules of the car purchasing process, such as credit checks, payment plans, etc.

Step 3: Implementing Bounded Contexts

Define Contexts: Break down the domain into manageable contexts, like “Sales,” “Finance,” and “Inventory.”
Context Interactions: Understand how these contexts interact. For instance, “Sales” may initiate a credit check process in “Finance.”

Engage Stakeholders: Regularly consult with salespeople, finance officers, and customers to refine the model and understand their needs.
Iterate the Model: Continuously refine the model based on feedback and new insights.

Step 5: Translating to Code

Implementing Entities and Relationships: Translate the domain model into code, creating classes, and methods that reflect the real-world entities and processes.
Building the User Interface: Design the UI to align with the domain model, ensuring it’s intuitive for users, like having a clear flow from car selection to financing.

Step 6: Leveraging Domain Storytelling

Narrate the Customer’s Journey: Use Domain Storytelling to depict the customer’s experience, from entering the dealership to driving away with the car.
Visualize with Pictographic Language: Create diagrams that represent the steps in the process, such as selecting a car, discussing with a salesperson, and signing documents.

Wrapping Up: Embracing DDD for Better Collaboration

DDD, coupled with Domain Storytelling, is not just a method; it’s a mindset shift. It brings clarity, efficiency, and a user-centric focus to software development. It’s a way to make the development process more enjoyable and inclusive for everyone involved.

Further Exploration

To delve deeper, check out “Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software” and visit domainstorytelling.org.

Now we know what DDD is about. Let’s talk what is Do’s and Dont’s in DDD. Do’s and Don’ts

Here’s to transforming complex software projects into collaborative and user-focused adventures! cheers! 🍺

Solving SSH Connection Issues on macOS - A Guide to Fixing 'Unprotected Private Key File' Error

Yoonsoo Park — Tue, 28 Nov 2023 01:25:00 -0400

Solving SSH Connection Issues on macOS: A Guide to Fixing ‘Unprotected Private Key File’ Error

When working with AWS EC2 instances, particularly from a macOS environment, a common hurdle that many face is the Unprotected Private Key File error during SSH connections. This error can halt your workflow, preventing access to your remote servers. Understanding and resolving this error is crucial for maintaining a secure and efficient development environment.

Understanding the Error

The error typically reads:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'ec2-demo.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "ec2-demo.pem": bad permissions
ec2-user@3.8x.6x.1xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

This error occurs because the SSH protocol requires that your private key files are kept secure and not accessible by other users on your system. The recommended permissions for these files are 600, allowing only the file’s owner to read and write.

The Solution

Step 1: Open Terminal

Launch the Terminal application on your macOS. This is where you’ll execute commands to modify file permissions.

Step 2: Navigate to the Key File

Use the cd command to navigate to the directory containing your .pem file. For example:

1

cd /path/to/your/key

Replace /path/to/your/key with the actual path to your .pem file.

Step 3: Change File Permissions

Once in the correct directory, run:

1

chmod 600 ec2-demo.pem

This command changes the file permissions to 600, restricting access to only the file’s owner.

Step 4: Retry SSH Connection

After updating the permissions, connect to your EC2 instance:

1

ssh -i /path/to/ec2-demo.pem ec2-user@3.8x.6x.1xx

Replace /path/to/ with the actual path to your .pem file.

Cheers! 🍺

How to Rename a Git Branch Using the CLI

Yoonsoo Park — Mon, 30 Oct 2023 01:25:00 -0400

Introduction

Renaming a Git branch may seem like a trivial task, but it can become complex, especially when you’ve already pushed the branch to a remote repository. In this blog post, we’ll go through the steps to rename a local and remote Git branch using the Command-Line Interface (CLI).

Step 1: Switch to the Branch You Want to Rename

Before you can rename a branch, you need to switch to it. Open your terminal and run the following command:

1

git checkout old-branch-name

Step 2: Rename the Local Branch

Once you’re on the branch you wish to rename, use the following command to rename it:

1

git branch -m new-branch-name

The -m flag stands for “move,” which effectively renames the branch.

Step 3: Update the Remote Branch

If you have already pushed the branch to a remote repository and you wish to rename it there as well, you’ll need to delete the old branch and then push the new one. Here’s how you do it:

1
2


git push origin --delete old-branch-name
git push origin -u new-branch-name

The -u flag sets the upstream, so future git pull and git push commands on this branch will automatically know which remote branch to interact with.

Step 4: Update Any Open Pull Requests

If you have any open pull requests that involve the old branch name, remember to update those manually to point to the new branch name.

Step 5: Inform Your Team Members

Renaming a remote branch is a significant change that can affect all team members who are using the same repository. It’s good practice to inform everyone about the change. Team members can update their local branches with the following commands:

1
2
3
4


git branch -m old-branch-name new-branch-name
git fetch origin
git branch --unset-upstream
git branch -u origin/new-branch-name

Cheers! 🍺

How to Remove Inaccessible Scratch Orgs from Your Local SFDX Configuration

Yoonsoo Park — Tue, 12 Sep 2023 01:25:00 -0400

Introduction

If you’re working with Salesforce DX, you’re probably already familiar with the concept of Scratch Orgs. These are temporary Salesforce orgs where you can do your development and testing. But what happens when a scratch org that you’re done with still shows up in your local list, and attempts to remove it result in errors? This article aims to tackle precisely this issue.

Identifying the Problem

You run sfdx force:org:list and notice an org that you no longer need. When you try to remove it using sfdx force:org:delete, you get an error message like DomainNotFoundError or “The org cannot be found”. These issues often occur when the scratch org has already been deleted on the Salesforce side but still exists in your local SFDX configuration.

Symptoms:

Running sfdx force:org:list displays the problematic scratch org.

force-nforce-003jsL test-ry0x7ndfdivv@example.com 00D040000003jsLEAQ DomainNotFoundError

Attempting to delete the org results in an error.

ERROR running force:org:delete: The org cannot be found

Solutions

1. Directly Remove from Local Configuration

Navigate to the .sfdx folder, usually located in your home directory. Inside, you’ll find orgs.json. Open it and manually remove the entry for the problematic scratch org.

1
2
3
4


# Navigate to the .sfdx folder in your home directory
cd ~/.sfdx

# Open the orgs.json file in a text editor and manually remove the entry

2. Use `sfdx force:org:list --clean`

Running this command will clean your local list of orgs, removing any that it can’t find on the server.

1

sfdx force:org:list --clean

3. Re-authenticate the Org (If Possible)

If the org still exists on the Salesforce server, sometimes re-authenticating can resolve these issues.

1

sfdx force:auth:web:login -r https://test.salesforce.com -a My_Scratch_Org

After re-authenticating, try to delete the org again.

4. Use `sfdx force:config:set`

Set another default org to potentially resolve some edge cases.

1

sfdx force:config:set defaultusername=mynewdefaultorg@example.com

Cheers! 🍺

Keeping Your Python Packages Up-to-date - A Comprehensive Guide

Yoonsoo Park — Fri, 08 Sep 2023 01:25:00 -0400

Keeping Your Python Packages Up-to-date: A Comprehensive Guide

As a Python developer, managing dependencies is an integral part of your workflow. Keeping packages updated is crucial for leveraging new features, improving performance, and most importantly, for security. However, you also want to ensure that updating a package doesn’t introduce breaking changes to your project. In this article, we’ll explore various ways you can keep your Python packages updated.

Method 1: The Manual Way

Update Individual Packages

To update a specific package to its latest version, run the following command:

1

pip install --upgrade package_name

Update All Packages

To update all packages to their latest versions, use:

1

pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U

Freeze New Versions

After you’ve updated the packages and confirmed that your code still works, freeze the new package versions into your requirements.txt file.

1

pip freeze > requirements.txt

Method 2: Using `pip-tools`

Install pip-tools

First, install pip-tools:

1

pip install pip-tools

Compile Requirements

If you have a requirements.in file where you keep your top-level package dependencies, compile it to produce a requirements.txt file with pinned versions.

1

pip-compile requirements.in

Update and Compile

To update all the packages in your requirements.txt, use:

1

pip-compile --upgrade

Synchronize Environment

Finally, sync your environment with:

1

pip-sync

Method 3: Dependency Management Services

You can also use Dependency Management Services like Dependabot, Renovate, or Snyk. These services automatically create pull requests in your repositories when new versions of your dependencies are released.

Method 4: Using `pipdeptree`

Install pipdeptree

First, install pipdeptree:

1

pip install pipdeptree

Show Dependency Tree

This tool helps you understand your project’s dependency tree, which is particularly useful before performing updates.

1

pipdeptree

General Recommendations

Use Virtual Environments: Always isolate your project dependencies using virtual environments.
Run Tests: After updating, run your test suite to make sure nothing broke.
Read Release Notes: Always read the release notes for each updated package.
Version Control: Use version control to easily revert to older versions if an update causes issues.

Keeping your Python packages up-to-date doesn’t have to be a chore. With these methods and precautions, you can make the process efficient and risk-free.

Cheers! 🍺

Understanding the sfdx force:source:convert Command in Salesforce DX

Yoonsoo Park — Wed, 06 Sep 2023 01:25:00 -0400

Understanding the `sfdx force:source:convert` Command in Salesforce DX

Salesforce DX has emerged as an indispensable toolkit for Salesforce developers, offering a robust set of features for source-driven development, easy deployments, and automated testing. Among the plethora of commands that Salesforce DX provides, one that often confuses newcomers is sfdx force:source:convert. In this article, we’ll delve into this command, exploring its purpose, how it works, and why you might need to use it.

What is `sfdx force:source:convert`?

The sfdx force:source:convert command is designed to convert your Salesforce DX project source files into a format that is compatible with the Metadata API. This is particularly useful when you need to deploy your code to non-scratch orgs like Developer, Developer Pro, or Production orgs, which expect your metadata to be in the Metadata API format.

How Does It Work?

When you run the sfdx force:source:convert command, it will scan the specified source directory and create a new directory containing the converted files. Here’s a quick example to demonstrate its usage:

1

sfdx force:source:convert -r path/to/source/ -d path/to/output/

This command will take the source files from path/to/source/ and output the converted files in path/to/output/.

Common Flags and Parameters

Here’s a rundown of some commonly used flags with this command:

-r, --rootdir ROOTDIR: Specifies the source directory to convert. It defaults to the “default package directory” in sfdx-project.json.
-d, --outputdir OUTPUTDIR: Sets the directory where the Metadata API–formatted files will be stored.
-n, --packagename PACKAGENAME: An optional parameter that allows you to name the package that you intend to create from the converted source later on.

Key Points to Consider

Idempotent Operation

One of the advantages of using sfdx force:source:convert is its idempotent nature. Running this command multiple times will produce the same output, assuming there are no changes in the source code.

No Deployment

Remember, this command is solely for conversion. It does not handle the deployment of the converted source code to any Salesforce org.

Temporary Use

In most scenarios, you would use the converted metadata as an intermediate step for other tasks, such as deploying to non-scratch orgs or creating packages.

Opinion

If you find yourself working exclusively with Salesforce DX and scratch orgs, you may seldom need to use this command. However, for those dealing with various types of Salesforce orgs or those in need of packaging their code, mastering sfdx force:source:convert is essential. It acts as a bridge, enabling your modern, modular Salesforce DX project to interact seamlessly with older components of the Salesforce ecosystem.

Happy Saturday guys, cheers! 🍺

Initializing a Python Project in Visual Studio Code

Yoonsoo Park — Thu, 31 Aug 2023 01:25:00 -0400

Initializing a Python Project in Visual Studio Code

Creating a Python project involves more than just writing code. It entails setting up an organized file structure, managing dependencies, and even integrating version control for collaborative development. In this article, we’ll go through the steps to initialize a Python project in VS Code, install the necessary dependencies, and set up a GitHub repository for version control.

Step 1: Create a New Folder in VS Code

Open Visual Studio Code and create a new folder for your Python project using the “New Folder” button. This folder will be the root directory of your Python project.

Step 2: Initialize a Virtual Environment

Open the terminal in VS Code by navigating to View > Terminal or pressing Ctrl+~.
Run the following command to create a virtual environment. Replace myenv with your desired name.
1

python -m venv myenv

Step 3: Activate the Virtual Environment

Activate your virtual environment by running:

On Windows:
1

.\myenv\Scripts\Activate
On macOS and Linux:
1

source myenv/bin/activate

Step 4: Install Required Packages

Install the required Python packages by running the following command:

1

pip install requests google_images_search

Step 5: Create Python Files

Create a new Python file (main.py, for example) and paste your Python code into it.

Initialize GitHub Repository

Step 1: Initialize Local Repository

In the terminal, run:

1

git init

Step 2: Create `.gitignore` File

Create a .gitignore file and add the following:

1
2
3
4


myenv/
__pycache__/
*.pyc
*.pyo

Step 3: Add and Commit Files

Run the following commands to add and commit your files locally:

1
2


git add .
git commit -m "Initial commit"

Step 4: Create a GitHub Repository

Step 5: Link Local Repository to GitHub

Replace your-repo-url with the URL of your GitHub repository and run:

1

git remote add origin your-repo-url

Step 6: Push to GitHub

Push your local commits to the GitHub repository:

1

git push -u origin master

Cheers! 🍺

Passing Command-Line Arguments to a TypeScript Script using NPM

Yoonsoo Park — Fri, 18 Aug 2023 01:25:00 -0400

Introduction

In modern JavaScript and TypeScript development, npm scripts are commonly used to streamline and simplify various tasks. However, there may be occasions when you need to pass arguments to these scripts to make them more dynamic. In this article, we’ll explore how to pass command-line arguments to a TypeScript script using npm run.

Setting up NPM to Run Your TypeScript Script

To run your TypeScript script using the npm run command, you can define a script in your package.json file. Here’s a step-by-step guide to help you set it up:

Ensure you have the necessary dependencies. Before running TypeScript files, make sure you have the TypeScript compiler and, optionally, ts-node installed.
Create or update a tsconfig.json file to include compiler options for TypeScript.
Add a script entry to the scripts section of your package.json to execute the TypeScript file with ts-node.

Passing Parameters with NPM Run

Handling Arguments in TypeScript:

In your TypeScript script, Node.js provides a global object called process.argv which is an array containing the command-line arguments passed when the process was launched. The first two values are the node executable and your script’s path, so you’ll usually want to access the arguments starting from index 2:
1

const args = process.argv.slice(2);
For our use case, we want to retrieve the arg argument:
1 2

const profileArg = args.find((arg) => arg.startsWith("--arg=")); const profileName = profileArg ? profileArg.split("=")[1] : "default";
Updating the NPM Script:

Your package.json file remains unchanged. It can look like this:
1 2 3

"scripts": { "start": "ts-node your-script-file.ts" }
Executing the Script with Arguments:

When running your script, use the following format to pass in the arg argument:
```
npm run start -- --arg=myProfile
```
The -- after npm run start indicates that the subsequent arguments should be passed directly to the invoked script.

Advanced: Using Argument Parsers

For more advanced command-line argument parsing, consider using libraries like yargs or commander. They offer a plethora of features such as default values, required arguments, aliases, and much more, which can make your scripts more robust and user-friendly.

Conclusion

Passing command-line arguments to your TypeScript scripts via npm run can greatly enhance their flexibility. Whether you’re looking to provide different configurations, paths, or any other kind of data, this method can simplify and streamline your development process.

Cheers! 🍺

Mastering Git Stash - A Guide to Saving and Restoring Your Code Changes

Yoonsoo Park — Mon, 31 Jul 2023 01:25:00 -0400

Introduction

git stash is one of those Git commands that can be an absolute lifesaver when you’re in the middle of a coding session. Imagine you’re working on a new feature and suddenly need to switch context—perhaps to a different branch to work on a hotfix. You don’t want to commit half-baked code, but you need to save your changes somewhere. Enter git stash.

In this article, we’ll explore various ways to use git stash to your advantage, helping you to save, manage, and restore your code changes effectively.

Basic Stashing

Saving Changes

The basic form of the git stash command is straightforward. Simply run:

1

git stash

This command takes your modified tracked files and stages them along with any new files you’ve indicated with git add, and stashes them away for later use.

Listing Stashes

You can view all your stashes using:

1

git stash list

This command will show you a list of all the stashes that you’ve created, making it easier to manage them.

Advanced Stashing Techniques

Applying the Latest Stash

You can apply the changes from the most recent stash using:

1

git stash apply

This command will keep the stash, allowing you to apply the same changes to multiple branches.

Popping the Latest Stash

Alternatively, you can use:

1

git stash pop

This will apply the stashed changes and remove them from your stash list.

Dropping a Stash

If you want to discard a stash, you can use:

1

git stash drop stash@{0}

This command will remove the specified stash from your stash list.

Applying a Specific Stash

If you’ve created multiple stashes, you can specify which stash to apply:

1

git stash apply stash@{1}

Or, if you wish to apply and remove it from the stash list:

1

git stash pop stash@{1}

Handling Conflicts

Just like with merges or rebases, conflicts can occur when you apply or pop a stash. You’ll have to resolve these conflicts manually before you can continue your work.

Conclusion

The git stash command is a powerful tool for managing changes in your Git repository. It enables you to switch between different tasks seamlessly, without losing your progress on any of them. Whether you’re a Git novice or a seasoned user, understanding how to effectively use git stash can significantly streamline your development workflow.

So the next time you find yourself needing to switch tasks but don’t want to lose your changes, remember: just stash it!

Cheers! 🍺

Checking Object Type in TypeScript

Yoonsoo Park — Wed, 05 Jul 2023 01:25:00 -0400

When working with TypeScript, it’s often necessary to determine the type of a variable. In particular, you might need to check whether a variable is of object type. Fortunately, TypeScript provides a straightforward way to perform this type check.

The `typeof` Operator

In TypeScript, you can use the typeof operator to check the type of a variable. To determine if a variable is of object type, combine typeof with the object keyword.

Here’s an example:

1
2
3
4
5
6
7


const variable: any = {}; // Your variable

if (typeof variable === 'object' && variable !== null) {
 console.log('The variable is an object.');
} else {
 console.log('The variable is not an object.');
}

In this code snippet, the typeof variable === 'object' condition checks whether the type of variable is an object. Additionally, variable !== null ensures that null is not considered an object.

Specifying a Specific Object Type

If you’re looking to check for a specific object type, you can replace the any type in the variable declaration with the desired type.

Here’s an example:

1
2
3
4
5
6
7


const variable: SomeObjectType = {}; // Your variable of type SomeObjectType

if (typeof variable === 'object' && variable !== null) {
 console.log('The variable is an object of type SomeObjectType.');
} else {
 console.log('The variable is not an object of type SomeObjectType.');
}

Replace SomeObjectType with the actual type you’re expecting for your variable.

Conclusion

Checking the object type in TypeScript is essential when you want to ensure the correctness of your code. By using the typeof operator in combination with the object keyword, you can easily determine whether a variable is an object. If you’re looking for a specific object type, replace the any type with the desired type in the variable declaration.

Cheers! 🍺

Creating Zip Files from JSON Configuration with Node.js and TypeScript

Yoonsoo Park — Mon, 03 Jul 2023 01:25:00 -0400

In this article, we’ll explore a practical use case involving JSON parsing and file operations in Node.js and TypeScript. Specifically, we’ll write a script to read a JSON configuration file, extract files and directories specified therein, and zip them into a single file.

Prerequisites

Before we get started, make sure you have Node.js and TypeScript installed on your system. Also, you will need the fs, path and archiver libraries. If you haven’t installed the archiver library yet, you can add it to your project using npm:

1

npm install archiver

The Code

Let’s look at the TypeScript script.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


import * as fs from 'fs';
import * as path from 'path';
import * as archiver from 'archiver';

function getAllFiles(dirPath: string, arrayOfFiles: string[] = []) {
 const files = fs.readdirSync(dirPath)

 files.forEach(function(file) {
 if (fs.statSync(dirPath + "/" + file).isDirectory()) {
 arrayOfFiles = getAllFiles(dirPath + "/" + file, arrayOfFiles)
 } else {
 arrayOfFiles.push(path.join(dirPath, "/", file))
 }
 })

 return arrayOfFiles
}

async function main() {
 const rawData = fs.readFileSync('input.json');
 const jsonData = JSON.parse(rawData.toString());

 if (!jsonData.configuration) {
 console.log('No configuration object found in JSON');
 return;
 }

 const output = fs.createWriteStream('output.zip');
 const archive = archiver('zip', {
 zlib: { level: 9 } // Sets the compression level.
 });

 output.on('close', () => console.log(archive.pointer() + ' total bytes'));
 archive.on('error', (err: any) => { throw err; });
 archive.pipe(output);

 for (const key in jsonData.configuration) {
 for (const fileOrFolder of jsonData.configuration[key]) {
 const isDirectory = fs.lstatSync(fileOrFolder).isDirectory();

 if (isDirectory) {
 const files = getAllFiles(fileOrFolder);

 for(const file of files) {
 const filePath = path.resolve(file);
 const fileDirName = path.dirname(file);
 archive.append(fs.createReadStream(filePath), { name: path.join(fileDirName, path.basename(file)) });
 }
 } else {
 archive.append(fs.createReadStream(fileOrFolder), { name: fileOrFolder });
 }
 }
 }

 await archive.finalize();
}

main().catch(console.error);

How it works

The script begins by reading a JSON file, parsing its contents, and checking for a configuration property.

1
2
3
4
5
6
7


const rawData = fs.readFileSync('input.json');
const jsonData = JSON.parse(rawData.toString());

if (!jsonData.configuration) {
 console.log('No configuration object found in JSON');
 return;
}

It then creates a write stream for the output zip file and sets up the archiver to zip files.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


const output = fs.createWriteStream('output.zip');
const archive = archiver('zip', {
 zlib: { level: 9 } // Sets the compression level.
});

output.on('close', () => console.log(archive.pointer() + ' total bytes'));
archive.on('error',

(err: any) => { throw err; });
archive.pipe(output);

Next, the script loops over the keys in the configuration object. For each file or folder path, it checks if the path points to a directory. If it does, it retrieves all files under the directory recursively using the getAllFiles function.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


for (const key in jsonData.configuration) {
 for (const fileOrFolder of jsonData.configuration[key]) {
 const isDirectory = fs.lstatSync(fileOrFolder).isDirectory();

 if (isDirectory) {
 const files = getAllFiles(fileOrFolder);

 for(const file of files) {
 const filePath = path.resolve(file);
 const fileDirName = path.dirname(file);
 archive.append(fs.createReadStream(filePath), { name: path.join(fileDirName, path.basename(file)) });
 }
 } else {
 archive.append(fs.createReadStream(fileOrFolder), { name: fileOrFolder });
 }
 }
}

Once all files have been processed, it finalizes the archive, effectively creating the zip file.

1

await archive.finalize();

And that’s it! With this script, you can easily generate zip files based on configurations in a JSON file.

Conclusion

Node.js and TypeScript offer a powerful platform for handling file operations and processing JSON. The ability to read directories, read and write files, and even create zip archives opens up a world of possibilities for data processing and manipulation. With these tools in your toolkit, you can automate many manual tasks and streamline your data workflows.

Remember to handle file and directory paths carefully and ensure that your script has appropriate permissions to read and write where necessary.

Cheers! 🍺

AWS S3API List Buckets With JMESPath-Queries

Yoonsoo Park — Mon, 26 Jun 2023 01:25:00 -0400

The AWS Command Line Interface (CLI) provides a unified tool to manage these AWS services and automate them through scripts. Among AWS’s extensive service offerings, the Simple Storage Service (S3) is a scalable object storage service used for data backup, archiving, and analytics.

One common task when working with AWS S3 is listing all available S3 buckets, which can be accomplished by using the AWS CLI’s s3api list-buckets command. Here’s how it’s done:

1

 aws s3api list-buckets

Executing this command will output a JSON object containing all the S3 buckets under your account.

Sometimes, however, you may need to filter these results further or simplify the output. This is where the --query option comes in handy. The --query option uses the JMESPath query language, which allows you to specify specific fields from the response you’re interested in.

For instance, if you only want to extract the names of the buckets, you could use a JMESPath query like this:

1

 aws s3api list-buckets --query 'Buckets[].Name'

This command will return an array of your bucket names.

However, there may be a scenario where you want to verify the existence of a specific bucket in your S3 bucket list. Unfortunately, AWS CLI doesn’t support querying for specific values directly.

For such cases, you might need to use a different tool like jq and grep, or write a script to parse the output of the list-buckets command and check if the name is in the list.

An example using jq and grep might look like this:

1

 aws s3api list-buckets | jq -r '.Buckets[].Name' | grep "your-specific-bucket-name"

This command will return the bucket name if it exists in your list of S3 buckets; otherwise, nothing will be returned.

Remember, AWS CLI commands are case-sensitive, so be sure to enter your bucket names accurately. Always ensure you handle the output carefully, especially when automating these commands in scripts or larger applications.

In summary, AWS CLI provides a powerful way to interact with your AWS resources. Understanding how to leverage features like the --query option and how to utilize tools like jq and grep for additional functionality, can greatly enhance your efficiency when managing AWS services.

Cheers! 🍺

Understanding Origin and Branches in GitHub

Yoonsoo Park — Sat, 24 Jun 2023 01:25:00 -0400

Introduction

When first delving into the world of version control systems, specifically Git and GitHub, two terms you are likely to encounter often are “origin” and “branch”. However, their usage and what they represent can often lead to confusion. In this article, we will clear up these ambiguities and give you a clear understanding of what “origin” and “branch” are in GitHub.

Origin: The Remote Repository

In Git and by extension, GitHub, “origin” is not a branch as some might mistakenly think. Instead, it is the conventional name given to the default remote repository. Here’s a little context for clarity.

Git is a distributed version control system, which means you work with a local copy of the entire project on your computer. “Origin” is a reference to the remote repository from which the project was originally cloned or copied.

When you clone a repository from GitHub, Git automatically names this remote repository “origin”. Hence, when you run commands like git push origin master, you are instructing Git to push your changes to the “master” branch on the “origin” remote repository.

Branch: Your Development Line

While “origin” refers to the remote repository, a “branch” is an entirely different concept. A branch represents a separate line of development within your project.

The “master” branch (or “main” branch as many repositories are now naming it) is the default branch. It typically represents the stable, production-ready state of your code. Other branches are used for the development of new features, fixing bugs, or experimenting without affecting the stable code.

Once the work on these branches is completed and tested, they can be merged back into the master (or main) branch.

Key Differences

To sum up:

Origin: The default remote repository where your code resides. It’s the original location from which your project was cloned.
Branch: An independent line of development within your project. The master/main branch being the default and typically production-ready branch.

Wrapping up!

Understanding the difference between “origin” and “branch” can go a long way in improving your efficiency with Git and GitHub. Remember that “origin” refers to your remote repository, while a “branch” is your line of development within the project.

Cheers! 🍺

Git Vs GitHub

Yoonsoo Park — Fri, 23 Jun 2023 01:25:00 -0400

Introduction

The terms “Git” and “GitHub” are often mentioned together, and for those new to programming or version control systems, this can sometimes lead to confusion. In essence, Git is a version control system, and GitHub is an online service that hosts Git repositories and enhances collaborative work. Let’s delve deeper into their individual roles and the differences between them.

Understanding-Git

Git is a distributed version control system (VCS) that was created by Linus Torvalds, who is also credited with creating Linux. The primary purpose of any VCS is to manage changes to computer programs, documents, large websites, or any other information collections. Git is designed to handle everything from small to extensive projects with speed and efficiency.

Multiple developers can work on the same codebase using Git, without causing conflicts. This is made possible by Git’s ability to create separate environments, known as “branches”. These branches allow developers to work on features or bug fixes independently, and then merge their changes back into the main codebase when they’re ready.

What-is-GitHub?

GitHub, in contrast, is a web-based service that hosts Git repositories. Along with the version control functionality provided by Git, GitHub adds extra features like bug tracking, task management, and project wikis. Essentially, GitHub facilitates team collaboration on projects.

Multiple people can work on code simultaneously, propose changes, review code, discuss issues, and contribute to a codebase in a structured, version-controlled environment on GitHub. GitHub also simplifies “forking” projects (creating a copy of someone else’s project to your account), making changes to that project, and then proposing your changes back to the original project via a “pull request”.

Furthermore, GitHub has a social aspect to it, where users can follow each other, rate each other’s contributions, showcase their own projects, and more.

The-Differences-Between-Git-and-GitHub

To sum it all up:

Git: A version control tool that tracks changes and allows for seamless collaboration in code development.
GitHub: An online service that hosts Git-managed repositories, providing a platform for team collaboration. It also adds its own features for project management and community interaction.

Conclusion

In essence, Git and GitHub complement each other: Git as a powerful tool for version control and GitHub as a platform to collaborate and manage Git repositories. While they are often used together, they perform different roles, each significant in its own right.

Cheers! 🍺

How to Update SFDX CLI from One Version to Another

Yoonsoo Park — Thu, 22 Jun 2023 01:25:00 -0400

From time to time, updates and improvements to the SFDX CLI are released and users may need to update their CLI version. Here is a step-by-step guide on how to do this.

Prerequisites

Before proceeding, make sure you have:

Node.js and npm installed on your system. Salesforce CLI is an npm package.
SFDX CLI installed. You can confirm by running sfdx --version in your terminal.
Access to a command-line interface.

Steps

1. Uninstall the Current SFDX CLI

The first step is to uninstall the currently installed SFDX CLI. We can do this using the npm uninstall command:

1

npm uninstall -g sfdx-cli

2. Install the Desired Version of SFDX CLI

Next, we install the version of SFDX CLI we need. Replace <version-#> with the desired version number. For example, if you want to install version 7.185.0, you would run:

1

npm i -g sfdx-cli@7.185.0

3. Remove SFDX Directories (Optional)

In some cases, you may need to remove existing SFDX directories before reinstalling. Please be aware that this step should be taken with caution, as it will delete all the SFDX related data from your local machine:

1
2
3
4
5


sudo rm -rf /usr/local/sfdx
sudo rm -rf /usr/local/lib/sfdx
sudo rm -rf /usr/local/bin/sfdx
sudo rm -rf ~/.local/share/sfdx ~/.config/sfdx ~/.cache/sfdx
sudo rm -rf ~/Library/Caches/sfdx

4. Confirm the Update

To ensure that the update was successful, check the version of your SFDX CLI:

1

sfdx --version

This should display the version number that you just installed.

Wrapping Up

You have now successfully updated your SFDX CLI version. Remember, always ensure compatibility with your project’s dependencies before upgrading.

Cheers! 🍺

Record Based Configuration in Salesforce

Yoonsoo Park — Wed, 21 Jun 2023 01:25:00 -0400

Introduction

Record-Based Configuration lets you adjust specific settings or behaviors to suit individual records within an object. This article aims to provide a deep understanding of this concept and its implementation in Salesforce.

Understanding Record-Based Configuration in Salesforce

Record-Based Configuration in Salesforce refers to customizing specific settings or behaviors that apply to individual records within an object. For example, consider a custom object called “Project” in Salesforce. There might be different types of projects, each needing different fields, layouts, processes, or validation rules.

Through Record-Based Configuration, you could configure Salesforce to display different fields or execute different business logic based on the specific type of project being viewed or edited. This configuration can be achieved using several features, such as:

Record Types

Record Types is a feature allowing administrators to define different sets of picklist values, page layouts, and business processes for different users. The specific record type for a record can significantly influence the available options and overall user experience when interacting with that record.

Page Layouts

Page Layout refers to the organization of fields, lists, related lists, buttons, and components on a record detail or edit page. Different page layouts can be assigned to different profiles and record types, providing extensive control over the user interface on a record-by-record basis.

Business Processes

Business Processes are a set of picklist values that guide the stages a record can go through. They can be unique to each record type and can vary based on business requirements.

Validation Rules and Workflow Rules

These tools can also be used to provide record-based configuration by defining certain behaviors or requirements that only apply to records that meet specific criteria.

A Detailed Example

Let’s consider a custom object in Salesforce named ‘Projects.’ These Projects can be of various types - ‘Internal’, ‘Client-Based’, and ‘Research.’ Each type of Project has different information needs and different stages they go through.

Record Types Creation

You start by creating three different Record Types for each Project Type. This process allows you to associate each Project record with a specific type. In the Record Type settings, you can set up different picklist values relevant to each project type.

Page Layouts Adjustment

Next, you design three different Page Layouts, one for each Record Type. For ‘Internal’ projects, you might need fields for ‘Department’ and ‘Budget’. For ‘Client-Based’ projects, you might need ‘Client Name’, ‘Contract Details’, and ‘Billing Information’. For ‘Research’ projects, you might need ‘Research Field’, ‘Principal Investigator’, and ‘Funding Source’.

Business Process Definition

Then, for each Project type, you could define a different Business Process. ‘Internal’ projects might follow stages like ‘Idea’, ‘Approval’, ‘Implementation’, ‘Evaluation’. ‘Client-Based’ projects might have ‘Negotiation’, ‘Contract Signing’, ‘Execution’, ‘Completion’, and ‘Review’. ‘Research’ projects might go through ‘Proposal’, ‘Funding Approval’, ‘Execution’, ‘Thesis’, and ‘Publication’.

Applying Validation and Workflow Rules

Finally, you set up different Validation Rules and Workflow Rules for each Project type. For instance, for ‘Internal’ projects, you could have a rule that prevents the project from moving to the ‘Implementation’ stage if the ‘Budget’ field is empty.

Conclusion

Record-Based Configuration in Salesforce is a potent tool for customizing the platform to suit complex business requirements. It provides businesses the power

to design the Salesforce user experience and the system’s behavior to match the needs of individual records perfectly, enhancing productivity and efficiency.

Cheers! 🍺

Retreive GitHub Pull Requests Code

Yoonsoo Park — Tue, 20 Jun 2023 01:25:00 -0400

When collaborating on a shared repository, it’s typical to review pull requests (PRs) made by other contributors. While it’s possible to view these PRs through the GitHub web interface, there’s an often-overlooked alternative that provides a more thorough review process - reviewing them directly from your local machine via the command line.

The Advantages of Local Review

By fetching and checking out pull requests locally, you’re not just reviewing the code - you’re running it on your machine. This ability to execute the code offers a more practical and precise code review. It allows you to explore how the changes interact with the existing codebase, test the code in various scenarios, and identify potential bugs or issues that may not be immediately apparent when reviewing the code on the web interface.

Additionally, developers often find it more comfortable and efficient to read and understand code within their local development environment, as they can leverage familiar tools and configurations.

Without further ado, let’s delve into the steps needed to review GitHub PRs locally.

Step 1: Fetch the PR

Firstly, you need to fetch the PR from the remote repository using this git command:

1

git fetch origin pull/PR_NUMBER/head:pr-PR_NUMBER

Remember to replace PR_NUMBER with the actual number of the PR. For example, if you’re fetching pull request #123, the command would be:

1

git fetch origin pull/123/head:pr-123

Step 2: Checkout the PR

Having fetched the PR, it’s now time to check it out into a new branch with the following command:

1

git checkout pr-PR_NUMBER

Again, replace PR_NUMBER with the actual number of the PR. So, if the PR number was 123, you’d use:

1

git checkout pr-123

This command switches your working directory to the new branch (pr-123 in our example), giving you access to the proposed changes.

Step 3: Review and Run the PR

With the PR branch checked out, you can now proceed with the code review. But now, you have the advantage of being able to actually run the code. This allows you to identify potential runtime errors, understand how the new changes behave under different scenarios, and check the compatibility with your existing codebase.

After a thorough assessment, you’re now ready to provide constructive feedback, propose changes, or approve the pull request.

Conclusion

Although the GitHub web interface is a convenient tool for reviewing PRs, checking them out locally allows for a more comprehensive review process. By fetching and running the changes proposed in a pull request on your machine, you can deliver higher quality feedback and help ensure the stability and efficiency of your shared codebase. After your review, remember to switch back to your original branch and clean up the PR branches to keep your local repo organized.

Cheers! 🍺

How to Delete Unwanted Files from a Pull Request

Yoonsoo Park — Mon, 19 Jun 2023 01:25:00 -0400

Sometimes, while working on a project and preparing to create a Pull Request (PR), you might realize that there are certain files you accidentally staged for commit. These could be files that don’t contribute to the PR’s purpose, such as temporary logs, unrequired backups, or any file that you didn’t intend to change.

The good news is, Git provides a way to unstage such files before finalizing the PR. Here is a step-by-step guide to help you exclude unwanted files from your PR:

Prerequisites

Before proceeding, make sure you have:

Git installed on your system.
Command-line Interface (CLI) terminal available.
A working Git repository.

Steps

1. Checkout to the Relevant Branch

The first step is to switch to the branch from which you’re going to create the PR. You can do this by using the git checkout command followed by the branch name. Replace pr-branch with the actual name of your branch:

1

git checkout pr-branch

2. Reset the Unwanted File

Next, we use the git reset command to unstage the file we don’t want to include in the PR. Replace /path/to/file with the relative path of your file from the repository root:

1

git reset origin -- /path/to/file

3. Commit the Changes

After you’ve unstaged the file, commit the changes:

1

git commit

This will open a text editor (typically VI/VIM) for you to enter a commit message. Make sure to provide a meaningful message describing why you’re making this commit.

4. Reset Other Unstaged Changes

If there are other unstaged changes in your repository, you might want to discard those too. You can achieve this by running one of the following commands:

1
2


git checkout -- . # Discard unstaged changes, but keep untracked files
git reset --hard @ # Discard all changes including untracked files

Choose the command that suits your situation.

5. Push the Changes

Finally, push your changes to the remote repository:

1

git push

Wrapping Up

By following these steps, you have now successfully removed the unwanted file(s) from your PR. Remember, Git is a powerful tool, but with great power comes great responsibility. Always double-check your actions before executing commands, especially when discarding changes or altering commit history.

Cheers! 🍺

How to Add Tags in GitHub

Yoonsoo Park — Sun, 18 Jun 2023 01:25:00 -0400

Tags in GitHub are a great way to mark specific points in your project’s history, such as significant releases or milestones. They provide a reference point for easier navigation and can be useful for collaboration and version control. In this article, we’ll explore two methods of adding tags in GitHub: using Git commands and using the web user interface (UI).

Adding Tags Using Git Command

Step 1: Clone the Repository: Begin by cloning the repository to your local machine using the following command:

git clone <repository-url>

Step 2: Navigate to the Repository: Move into the repository’s directory using the cd command:

cd <repository-directory>

Step 3: Check Out the Desired Commit: Use the git log command to view the commit history. Find the commit you want to tag and note its commit hash. Then, check out the commit using the following command:

git checkout <commit-hash>

Step 4: Create the Tag: Now, create the tag using the git tag command. You can choose either an annotated or lightweight tag. For an annotated tag, use the following command:

git tag -a <tag-name> -m "<tag-message>"

For a lightweight tag, use:

git tag <tag-name>

Step 5: Push the Tag to GitHub: Finally, push the tag to the remote repository on GitHub with the git push command:

git push origin <tag-name>

Adding Tags Using Web UI

Step 1: Navigate to the Repository: Open your web browser and go to GitHub. Navigate to the repository where you want to add the tag.
Step 2: Go to the Releases Section: Once you’re in the repository, click on the “Releases” tab located near the top navigation bar.
Step 3: Create a New Release: On the releases page, click on the “Create a new release” button.
Step 4: Fill in Release Details: In the release creation form, enter the tag version, release title, and any other relevant information.
Step 5: Publish the Release: After filling in the necessary details, click on the “Publish release” button to create the tag and publish the release.

NOICE! You have successfully added a tag to your GitHub repository. Whether you prefer using Git commands or the web UI, both methods provide an efficient way to mark important points in your project’s history.

Remember, tags are useful for organizing and tracking different versions of your project. They can also be used to trigger specific actions, such as deployment or CI/CD pipelines. Utilize tags wisely to enhance collaboration and streamline your development workflow.

Note: If you’re using a different Git platform or hosting service, the steps may vary slightly. However, the general concept of adding tags remains the same.

My first article from my first house! ;) Cheers! 🍺

Best Practices for Defining Paths for RESTful APIs

Yoonsoo Park — Sat, 17 Jun 2023 01:25:00 -0400

Best Practices for Defining Paths for RESTful APIs

When creating RESTful APIs, it’s important to adhere to the best practices for defining paths. Below are a few guidelines:

Use nouns, not verbs: RESTful APIs should use nouns (not verbs) to indicate the resources being manipulated. The HTTP methods (GET, POST, PUT, DELETE, etc.) should define the operation. For example, use /users/{userId} instead of /getUser/{userId}.
Pluralize resources: It’s generally recommended to use plural forms of resources to indicate a collection. For instance, /users represents all users, while /users/{userId} represents a specific user.
Avoid deep nesting: While it may be tempting to deeply nest resources, this can lead to complex and less manageable APIs. Instead, limit your API paths to two levels if possible. For example, use /users/{userId}/posts rather than /users/{userId}/posts/{postId}/comments.
Lowercase letters and hyphens: Use lowercase letters in the path. If you need to separate two words, use hyphens (-) instead of underscores (_) or camel case.
Consistency: Above all, be consistent in your naming and structuring conventions. Consistency helps to maintain clarity for all developers who are using your API.
Use Meaningful Resource Names

Ensure that resource names are intuitive and meaningful. They should clearly indicate what kind of data is being represented by the API. For example, /employees is a more intuitive resource name than /people when you’re dealing with an API for a human resources application.

Avoid Query Parameters for Mandatory Data

While query parameters can provide flexibility, they should not be used for mandatory data. Mandatory data should be provided as path parameters instead. For instance, use /users/{userId} instead of /users?userId={userId}.

Versioning Your APIs

It’s recommended to include a version in your API path to prevent breaking changes for your API consumers. For instance, /v1/users/{userId}. This allows you to evolve your API without interrupting service for existing clients.

Real-Life Examples

Let’s look at a real-life example - an API for a blog application. Here are some endpoints that follow the best practices:

GET /v1/posts - Retrieves all blog posts.
GET /v1/posts/{postId} - Retrieves a specific blog post.
POST /v1/posts - Creates a new blog post.
PUT /v1/posts/{postId} - Updates a specific blog post.
DELETE /v1/posts/{postId} - Deletes a specific blog post.
GET /v1/users/{userId}/posts - Retrieves all posts from a specific user.

Note that we have a version number in the paths, we’re using plural and meaningful resource names (posts), and we’re not using query parameters for mandatory data (postId and userId are path parameters).

Adhering to these best practices when defining paths will help to create APIs that are not only powerful and scalable, but also user-friendly and easy to maintain. Consistency, intuitive resource names, correct use of path and query parameters, and proper versioning are all essential for a well-structured API.

Cheers! 🍺

AWS API Gateway - Path Parameters

Yoonsoo Park — Fri, 16 Jun 2023 01:25:00 -0400

This article aims to clarify the use of AWS API Gateway, specifically focusing on path parameters - defined with {} braces - and the best practices for their utilization.

AWS API Gateway Overview

AWS API Gateway allows you to process hundreds of thousands of concurrent API calls and handles traffic management, authorization and access control, monitoring, and API version management. It supports RESTful APIs and WebSocket APIs and is incredibly versatile in serving a variety of different API types.

Defining Path Parameters in AWS API Gateway

Path parameters are dynamic parts of the request URL, allowing you to pass data directly within the endpoint path. In AWS API Gateway, these parameters are specified using {} braces. For instance:

GET /users/{userId}

In this example, userId is a path parameter that can be replaced with an actual user ID, such as:

GET /users/1234

The AWS API Gateway service can extract these parameters from the path and provide them to your application logic, enabling you to build dynamic responses based on the input parameters.

Real-Life Example: Using Path Parameters

Let’s delve into a real-life example to better illustrate the use of path parameters. Consider a social media application where users can have posts. We would want to perform CRUD operations on these posts. Below are some example API endpoints:

GET /users/{userId}/posts - Retrieves all posts for a specific user.
GET /users/{userId}/posts/{postId} - Retrieves a specific post from a specific user.
POST /users/{userId}/posts - Creates a new post for a specific user.
PUT /users/{userId}/posts/{postId} - Updates a specific post from a specific user.
DELETE /users/{userId}/posts/{postId} - Deletes a specific post from a specific user.

Here {userId} and {postId} are path parameters. When a client sends a request to the server, it replaces these placeholders with actual values.

For example, to get the post with the ID of 999 for the user with ID 123, the client would send a GET request to /users/123/posts/999.

Using Path Parameters on the Backend

On the server-side, the code would use these path parameters to perform the requested operations. Here’s a simple Node.js example using Express:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


const express = require('express');
const app = express();

app.get('/users/:userId/posts/:postId', (req, res) => {
 const userId = req.params.userId;
 const postId = req.params.postId;

 // You would usually fetch the user and post from a database here
 // For simplicity, we're returning dummy data
 res.json({
 userId: userId,
 postId: postId,
 title: 'Sample Post',
 content: 'This is a sample post.'
 });
});

app.listen(3000, () => console.log('Server is running on port 3000'));

In this code, we define a route /users/:userId/posts/:postId. Express uses : to denote path parameters. When a GET request is made to this route, Express extracts the userId and postId from the path and makes them available as properties of req.params.

In this way, path parameters provide a dynamic and flexible way to define routes and handle requests, making them a key aspect of developing user-friendly and efficient APIs.

Cheers! 🍺

Leveraging AWS SSO to Acquire AWS SecretAccessKey and SessionToken

Yoonsoo Park — Thu, 15 Jun 2023 01:25:00 -0400

Developing secure applications necessitates the safe management of resource access. AWS SSO (Single Sign-On), a widely utilized service for safeguarding access management, comes in handy for this purpose. This article will delve into the utilization of AWS SSO to obtain role credentials, which will subsequently be used to fetch AWS SecretAccessKey and sessionToken. Note that this isn’t the official way of obtaining these secrets and incorporates a workaround approach. Our tools for the task will be Node.js and its modules: child_process, fs, path, and ini.

Breaking Down the Code

Our script can be divided into two primary segments. The first segment is the readCredentials function that fetches the requisite SSO credentials. The second part is the getAwsSecrets function, which employs these credentials to obtain AWS SecretAccessKey and sessionToken.

Gathering SSO Credentials

The readCredentials function initiates its operation by reading the AWS config file and the SSO cache.

1
2
3
4
5


const profile = process.env.AWS_PROFILE || 'default';
const awsConfigPath = join(process.env.HOME as string, '.aws', 'config');
const ssoCacheDir = join(process.env.HOME as string, '.aws', 'sso', 'cache');

const awsConfig = ini.parse(readFileSync(awsConfigPath, 'utf-8'));

It then extracts the AWS SSO account ID and role name from the AWS config file:

1
2


const ssoAccountId = awsConfig[`profile ${profile}`]?.sso_account_id;
const ssoRoleName = awsConfig[`profile ${profile}`]?.sso_role_name;

The access token is retrieved from the first file in the SSO cache directory:

1
2
3
4
5
6


const files = readdirSync(ssoCacheDir);
// This assumes that you have cache data after you ran aws sso.
const ssoCacheFile = files[0];
const ssoCacheFilePath = join(ssoCacheDir, ssoCacheFile);
const ssoCache = JSON.parse(readFileSync(ssoCacheFilePath, 'utf-8'));
const accessToken = ssoCache.accessToken;

Collecting AWS Secrets

Armed with these credentials, the getAwsSecrets function executes the AWS CLI command to obtain the essential role credentials:

1
2
3
4
5
6


const creds = await readCredentials();
const command = `aws sso get-role-credentials --account-id ${creds.ssoAccountId} --role-name ${creds.ssoRoleName} --access-token ${creds.accessToken}`;

const { stdout } = await exec(command);

const credentials = JSON.parse(stdout).roleCredentials;

These credentials are then employed to gather AWS secrets:

1
2
3
4
5
6


const roleCredentials = {
 AccessKeyId: credentials.accessKeyId,
 SecretAccessKey: credentials.secretAccessKey,
 SessionToken: credentials.sessionToken,
 Region: process.env.AWS_REGION || 'us-east-1',
};

Wrapping Up

This script exemplifies how AWS SSO credentials can be utilized to invoke an AWS services. The procedure involves sourcing the SSO credentials from the AWS config file and SSO cache, and subsequently employing these credentials to acquire the necessary role credentials. This method ensures the safeguarding of access management.

As always, ALWAYS, remember to store your sensitive data securely and avoid exposing them publicly.

Cheers! 🍺

The Art of Decision-Making - Why Engineers Should Stop Being Imposters

Yoonsoo Park — Wed, 14 Jun 2023 01:25:00 -0400

Don’t just be an engineer, be an imposter! Wait, what? That’s right, folks. In the world of software development, it seems like many engineers have taken on the role of the indecisive imposter, desperately seeking approval for even the tiniest of decisions. But hey, who needs efficiency and progress when we can waste company resources and time, am I right?

Analysis Paralysis: The Rabbit Hole of Never-Ending Decisions

Let’s set the stage. You’re an engineer working on a complex software project. You’re faced with a decision, whether it’s choosing the right library, deciding on an architectural approach, or simply picking the color of a button. But instead of taking charge and making a call, you find yourself stuck in the abyss of analysis paralysis.

Analysis paralysis, a term coined for this very situation, refers to the state of overthinking and overanalyzing to the point where a decision becomes nearly impossible. It’s like being trapped in a never-ending loop of “What if?” and “But what about this?”

The Need for Decisiveness: Taking Responsibility

As engineers, we must embrace the critical mindset of decision-making. We need to acknowledge that our ability to make informed choices is what drives progress and success. It’s not about seeking approval or waiting for someone else to make the call. No, it’s about taking responsibility for our decisions and standing by them.

Thomas Edison, the inventor of the light bulb, once said, “I have not failed. I’ve just found 10,000 ways that won’t work.” Edison understood that making decisions, even if they turn out to be wrong, is a crucial part of the journey to success. So why are we so afraid to make decisions?

Unnecessary Meetings: The Signature Move of an Imposter

Picture this: you’re in a meeting room filled with your fellow engineers, managers, and stakeholders. The topic of discussion? The color of a button. Yes, you heard that right—a button. The room is buzzing with opinions, ideas, and a whole lot of wasted time. And why? Because you, the indecisive engineer, wanted approval from the authority figures.

Albert Einstein, the brilliant physicist, once remarked, “The measure of intelligence is the ability to change.” Yet, in this scenario, it seems like intelligence has taken a backseat. By seeking approval for the minutest of decisions, engineers inadvertently become imposters, wasting valuable company resources.

The Imposter Syndrome: A Good Sign?

Being an imposter in the software development field might not be what you think. It’s not about pretending to know things you don’t. No, it’s about shying away from the responsibility of making decisions and hiding behind the need for approval. The imposter engineer thrives on unnecessary meetings and the collective decision-making process, all while draining the company’s resources.

So, the next time you find yourself hesitating to make a decision, take a moment to reflect. Are you falling into the imposter syndrome trap? Are you wasting time, money, and the potential of your team? Remember the wise words of Mark Twain: “Twenty years from now, you will be more disappointed by the things you didn’t do than by the ones you did.”

Embrace the Decisive Engineer Within

In a world that demands progress and innovation, engineers cannot afford to be imposters. It’s time to break free from the analysis paralysis rabbit hole and take responsibility for our decisions. Let’s embrace the critical mindset that defines our profession and make the choices that propel us forward.

As engineers, we have the power to shape the future. So, let’s make decisions, take risks, and learn from our mistakes. After all, as the legendary Steve Jobs once said, “The people who are crazy enough to think they can change the world are the ones who do.”

Remember, the imposter syndrome might be a good plot twist for a game, but in the real world of software development, it’s time to leave that role behind. Be decisive, be responsible, and be the engineer you were meant to be.

Disclaimer: This article is intended for entertainment purposes. (or is it?)

Cheers! 🍺

Invoking AWS API Gateway with SigV4 Using TypeScript

Yoonsoo Park — Tue, 13 Jun 2023 01:25:00 -0400

In this article, we will walk through the process of invoking an AWS API Gateway using Signature Version 4 (SigV4) for authentication in TypeScript.

Prerequisites

Before we start, make sure you have Node.js and npm installed on your machine. You will also need an AWS account with access to API Gateway and the necessary permissions to invoke APIs.

Step 1: Install the Necessary Libraries

We’ll need the aws-sdk and aws4 libraries. You can install them with npm:

1

npm install aws-sdk aws4 @types/aws4

Step 2: Import the Libraries and Configure AWS

1
2
3
4
5
6
7
8
9


import * as AWS from "aws-sdk";
import * as aws4 from "aws4";
import * as https from "https";

AWS.config.update({
 region: "us-west-2", // replace with your desired region
 accessKeyId: "YOUR_ACCESS_KEY", // replace with your access key
 secretAccessKey: "YOUR_SECRET_KEY", // replace with your secret key
});

Step 3: Create a Request Object and Sign It

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


let request: aws4.Request = {
 host: "API_ID.execute-api.REGION.amazonaws.com", // replace with your API Gateway URL
 method: "GET", // replace with your HTTP method
 path: "/Prod/path", // replace with your API path
 headers: {
 "Content-Type": "application/json",
 },
};

request = aws4.sign(request);

WHAT is **API path** ?

The path in the request object refers to the specific endpoint in your API Gateway that you want to invoke. This is usually mapped to a specific function in your backend service. If you’re using AWS Lambda as your backend service, each path in your API Gateway would be mapped to a specific Lambda function.

For example, let’s say you have an API for managing users, and you have the following Lambda functions:

CreateUserFunction: Creates a new user.
GetUserFunction: Gets the details of a user.
UpdateUserFunction: Updates details of a user.
DeleteUserFunction: Deletes a user.

You can set up your API Gateway with the following paths:

POST /users: Invokes CreateUserFunction.
GET /users/{userId}: Invokes GetUserFunction.
PUT /users/{userId}: Invokes UpdateUserFunction.
DELETE /users/{userId}: Invokes DeleteUserFunction.

If you wanted to get the details of a user with the ID 123, you would set the path in your request object to /users/123 and put the method to GET.

So, in the code example, /Prod/path is a placeholder for the path you want to invoke in your API Gateway. You would replace this with the actual path for your API. (e.g. if you’re invoking the GetUserFunction in the example above, you might set the path to /users/123).

Here’s how you can modify the request object for this example:

1
2
3
4
5
6
7
8


let request: aws4.Request = {
 host: "API_ID.execute-api.REGION.amazonaws.com", // replace with your API Gateway URL
 method: "GET", // replace with your HTTP method
 path: "/users/123", // replace with your API path
 headers: {
 "Content-Type": "application/json",
 },
};

Do not forget to replace API_ID, REGION, and the path with your actual values!

Step 4: Send the Request

1
2
3
4
5
6
7
8


const req = https.request(request, (res) => {
 let body = "";
 res.on("data", (chunk) => (body += chunk));
 res.on("end", () => console.log(body));
});

req.on("error", (e) => console.error(e));
req.end();

This will send a SigV4 signed request to your API Gateway. The placeholders should be replaced with your actual values!

Please note that this is a basic example and you may need to adjust it accordingly based on your case. (e.g. if you are sending a POST request, you need to include the body in the request and sign it as well.)

POST example

Here’s how you can modify the previous example to send a POST request with a body:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


import * as AWS from "aws-sdk";
import * as aws4 from "aws4";
import * as https from "https";

AWS.config.update({
 region: "us-east-1", // replace with your desired region
 accessKeyId: "YOUR_ACCESS_KEY", // replace with your access key
 secretAccessKey: "YOUR_SECRET_KEY", // replace with your secret key
});

let body = {
 key1: "value1",
 key2: "value2",
};

let request: aws4.Request = {
 host: "API_ID.execute-api.REGION.amazonaws.com", // replace with your API Gateway URL
 method: "POST", // replace with your HTTP method
 path: "/Prod/path", // replace with your API path
 headers: {
 "Content-Type": "application/json",
 },
 body: JSON.stringify(body),
};

request = aws4.sign(request);

const req = https.request(request, (res) => {
 let responseBody = "";
 res.on("data", (chunk) => (responseBody += chunk));
 res.on("end", () => console.log(responseBody));
});

req.on("error", (e) => console.error(e));

req.write(request.body);
req.end();

In this example, we’re sending a JSON object as the body of the request. We stringify the object and include it in the body part of the request object, and then we sign the request with aws4.sign(request).

When sending the request, we use req.write(request.body) to include the body in the request. (The body object should be replaced with the actual data you want to send in your POST request)

Cheers! 🍺

AWS-SQS-Queue

Yoonsoo Park — Mon, 12 Jun 2023 01:25:00 -0400

Amazon Web Services (AWS) offers a multitude of services to cater to the different needs of businesses and developers. One such service is Amazon Simple Queue Service (SQS), a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. In this article, we’ll explore the reasons to use AWS SQS and illustrate its utility with a real-life example.

Why Use AWS SQS?

SQS offers several compelling reasons that make it an attractive choice for managing messages in a distributed environment:

1. Effortless Scaling

SQS enables you to scale your applications without worrying about the underlying infrastructure. As your workload grows, SQS can seamlessly handle the increased message volume. No need for manual intervention or additional configuration.

2. Reliability

SQS guarantees the delivery of your messages. In case of any processing failures, the messages are not lost; instead, they return to the queue and can be processed again.

3. Security

SQS leverages AWS’s robust security measures. It supports encryption to keep your data secure at rest and in transit. You can also control access to your queues using AWS Identity and Access Management (IAM).

4. Cost-Effective

With SQS, you pay only for what you use. There’s no upfront cost, and you don’t have to maintain any messaging software or hardware.

**Some key features and aspects of SQS**

Types of Queues: SQS offers two types of message queues. Standard queues offer maximum throughput, best-effort ordering, and at-least-once delivery. On the other hand, FIFO (First-In-First-Out) queues are designed to ensure that the order of messages is strictly preserved and a message is delivered once and remains available until a consumer processes and deletes it.
Message Retention: SQS retains messages for a certain period until a consumer deletes them. The message retention period can be from 1 minute to 14 days. The default retention period is 4 days.
Dead Letter Queues: SQS supports Dead Letter Queues (DLQ), which are used to sideline and isolate messages that can’t be processed (consumed) successfully. DLQs can help you troubleshoot and handle message failures.
Delay Queues: SQS allows you to postpone the delivery of new messages to a queue for a number of seconds, up to 900 seconds (15 minutes). If you create a delay queue, any messages that you send to the queue remain invisible to consumers for the duration of the delay period.
Long Polling: SQS supports long polling, which is a way to retrieve messages from your SQS queues. While the regular short polling returns immediately, even if the message queue being polled is empty, long polling doesn’t return a response until a message arrives in the message queue, or the long poll times out.
Batch Actions: SQS allows you to send, delete, or change the visibility of multiple messages in a single action, reducing the cost of performing individual actions.
Integration with Other AWS Services: SQS integrates seamlessly with other AWS services like Lambda, EC2, SNS (Simple Notification Service), and CloudWatch, providing a complete solution for application integration.
Cost: You pay only for what you use, and there are no minimum fees. Pricing is based on the number of API calls made, the data transfer, and optional features like data transfer out of AWS.

Real-Life Example: E-commerce Order Processing

Consider an e-commerce platform where numerous transactions occur simultaneously. Each transaction may involve several steps: validating the order, charging the customer, updating inventory, and notifying the customer.

If we were to build this system without a message queue, we could potentially lose information if any single step fails or takes too long, leading to a poor customer experience.

With AWS SQS, each transaction can be broken down into individual messages and placed in a queue. Different microservices, like Order Validation, Payment Processing, Inventory Update, and Notification Service, can then pick up and process these messages asynchronously.

In this scenario, even if the Payment Processing service goes down, the messages would remain in the queue until they are processed. This ensures no order is lost due to temporary service outages.

Additionally, if there’s a sudden surge in orders during a sales event, SQS can effortlessly handle the increased load, ensuring smooth operation.

In conclusion, AWS SQS is a robust, secure, and scalable solution for managing messages in distributed systems. It allows developers to focus on building functionalities rather than worrying about message delivery and system infrastructure. Whether you’re working on a small project or managing a large-scale distributed system, AWS SQS could be an essential tool in your toolkit.

Cheers! 🍺

Advantages of Using PreSigned URLs vs. Direct File Uploads with AWS SDK to S3

Yoonsoo Park — Sun, 11 Jun 2023 01:25:00 -0400

This article is for stressing the advantages of using PreSigned URLs compared to direct file uploads on the server side.

What are PreSigned URLs?

PreSigned URLs are temporary URLs generated by AWS services that allow anyone with the URL to perform specific actions on an S3 object (e.g. reading an object) for a limited period.

What is Direct File Upload?

Direct file upload is a process where a file is uploaded directly to S3 using AWS SDK from a server-side application.

Advantages of PreSigned URLs

1. Reduced Server Responsibility

The most significant advantage of using PreSigned URLs is that they offload the server’s responsibility to handle file uploads. This means the client can directly upload a file to S3 without the process of sending the file to the server. The result is reduced load on the server which allows us to use resources for other operations hence overall system performance goes up.

2. Security

PreSigned URLs are secure. They provide temporary access (we can control the expiration time when creating the URL) which means once the URL has expired, it can no longer be used to upload or download content. In the other hand, server-side uploads require long-term access credentials which may potentially be more vulnerable.

3. Network Efficiency

Files can be uploaded directly from the client to S3 with PreSigned URLs. This prevents the need for data to travel from the client to the server and then from the server to S3 effectively reducing the network trip and improving efficiency.

4. Reduced Latency

Since the data is transferred directly from the client to S3, latency is reduced as the data doesn’t need to route through the application server.

Wrapping Up!!

While both PreSigned URLs and direct file uploads via AWS SDK have their use cases, particularly in scenarios where large files are being handled, the advantages of using PreSigned URLs are clear. In can help maintain server performance and enhance network efficiency. Also they offer a secure and convenient way to manage file uploads in your applications.

Tomorrow is Monday, guys. Let’s get some good sleep. We might need it. Cheers! 🍺

Why You Need to Bother to Use AWS API Gateway

Yoonsoo Park — Sat, 10 Jun 2023 01:25:00 -0400

APIs are handy for connecting systems and facilitating data exchange. Of course they are tons of tools available to manage APIs and Amazon Web Services (AWS) provides a tool known as the API Gateway for that.

What is AWS API Gateway?

The AWS API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the “front door” for applications to access data, business logic, or functionality from your backend services. (e.g. one way to create microservices architecture)

Why AWS API Gateway?

1. Scalability and Performance

AWS API Gateway is designed to handle thousands to millions of concurrent API calls, ensuring your application can scale as demand changes. It reduces the time and effort to manually manage infrastructure and traffic distribution. which means as developers we can focus on building and improving applications more.

2. Security

API Gateway provides several tools to authorize access to your APIs and control service access. These include AWS Identity and Access Management (IAM), AWS Cognito, and Lambda authorizers for that access management.

3. Cost Efficiency

With API Gateway, you only pay for the API calls you receive and the amount of data transferred out without upfront costs. The service includes a tiered pricing model that reduces costs as your API usage increases.

4. Development and Operational Efficiency

API Gateway allows for seamless API version management, staging, and lifecycle management. With built-in features (e.g. traffic management, throttling, and backend connection pooling), we can manage our APIs more efficiently.

5. Monitoring and Troubleshooting

With AWS CloudWatch integration, we can monitor API usage and troubleshoot issues more easily. (e.g. with detailed metrics and logging, we can understand how our APIs are being used)

Real-life Example: Online Retail Store

Let’s say you’re developing an e-commerce website “INeedThatFast”. Your website includes numerous services like user management, inventory management, order processing, payment processing, and so on… All these services need to communicate with each other to function correctly.

Instead of allowing these services to communicate directly (which can become a management nightmare!), you can use AWS API Gateway to manage these interactions. This not only ensures secure and efficient communication, but also allows us to monitor and manage these interactions from a single spot.

For example, when a customer places an order, the website interacts with the inventory management and order processing services. API Gateway routes these interactions for us. If the website traffic suddenly increases during a sale event, API Gateway will automatically scale to handle the increased incoming traffic. This allows us to provide a smooth shopping experience for the customers no matter what the website traffic is.

Cheers! 🍺

Getting to Yes - Negotiating Agreement Without Giving In by Roger Fisher

Yoonsoo Park — Fri, 09 Jun 2023 01:25:00 -0400

A Key Resource for Persuasive Negotiation in Software Engineering

“Getting to Yes: Negotiating Agreement Without Giving In” by Roger Fisher, William Ury, and Bruce Patton is a seminal text that offers a roadmap for negotiating mutually beneficial agreements in any situation. Its principles are particularly beneficial when trying to persuade others in the software engineering world, especially in discussions around project scope, resources, and timelines.

Four Principles of Effective Negotiation

The authors outline four principles for effective negotiation, which should be observed at each stage of the negotiation process, from analyzing the situation, planning responses, to discussing the problem to find a common solution.

Separate the People from the Problem: People often become personally involved with the issues and their side’s positions. The authors stress the importance of separating the people from the issues to avoid damaging relationships and to get a clearer view of the substantive problem【14†source】.
Focus on Interests, Not Positions: Rather than bargaining from separate opening positions, which often leads to inefficient and unfair agreements, Fisher and Ury suggest focusing on the underlying interests of all parties involved.
Generate a Variety of Options Before Settling on an Agreement: Instead of rushing to find a single answer, the authors advise generating multiple options to solve the problem. This allows for a more comprehensive exploration of possible solutions that could satisfy all parties.
Insist That the Agreement Be Based on Objective Criteria: To ensure fairness and durability, the agreement should be grounded on objective criteria rather than personal bias or power dynamics.

Although I was unable to find explicit real-world examples of these principles in action within the software engineering context due to time constraints and technical issues, they are widely applicable in a range of scenarios. For instance, when negotiating project resources, one might focus on the interests of delivering a quality product on time (a shared interest) rather than sticking to initial positions (e.g., I need X amount of resources). Multiple options for resource allocation could be explored, and the final agreement should be based on objective criteria such as project requirements and available resources.

These principles can serve as a guide for software engineers and project managers, helping to transform negotiations from battles into collaborative problem-solving sessions, fostering better relationships, and leading to more efficient and satisfactory outcomes.

“Never argue with stupid people. They will drag you down to their level and then beat you with experience.” - Mark Twain

Cheers! 🍺

aws sso get-role-credentials

Yoonsoo Park — Thu, 08 Jun 2023 01:25:00 -0400

AWS Single Sign-On (SSO) is a cloud-based service that makes it easy to centrally manage access to multiple AWS accounts and business applications. One of the essential features it provides is the get-role-credentials command, which is an AWS CLI v2 operation that returns the STS (Security Token Service) credentials for an IAM role in AWS.

In this article, we’ll discuss what the get-role-credentials command is and how it can be used in real-world scenarios.

What is `aws sso get-role-credentials`?

The get-role-credentials operation provides short-term credentials for an IAM role with SSO access. This function is particularly useful when you need to manage multiple AWS accounts and roles.

Here is the command syntax:

1

aws sso get-role-credentials --role-name your_role_name --account-id your_account_id --access-token your_access_token

This will return something similar to:

1
2
3
4
5
6
7
8


{
 "roleCredentials": {
 "accessKeyId": "ASIAxxxxxxxxxxxx",
 "secretAccessKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
 "sessionToken": "FwoGZXIvYXdzEHsaDGFxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
 "expiration": 1596414957
 }
}

These are the temporary credentials that you can use with AWS CLI and SDKs.

Real-World Scenario: Multi-Account AWS Management

Let’s consider a situation where a company has different AWS accounts for development, testing, and production environments. They use AWS SSO for managing access to these accounts. An engineer, YOPA, needs to access resources in both the development and production accounts, but with different permissions.

For the development account, YOPA has full access permissions, and for the production account, he has read-only permissions. To switch between these accounts seamlessly, he uses different SSO profiles configured in the AWS CLI.

When YOPA needs to list all the S3 buckets in the production account, he can get the role credentials for the SSO profile associated with the production account’s read-only role using the aws sso get-role-credentials command. Then, he can use these temporary credentials to list the S3 buckets without affecting her other active sessions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# get role credentials
aws sso get-role-credentials --profile prod-readonly --role-name SSOReadOnly --account-id 123456789012 > temp_credentials.json

# use jq to parse the json and export the credentials to environment variables
export AWS_ACCESS_KEY_ID=$(jq -r .roleCredentials.accessKeyId < temp_credentials.json)
export AWS_SECRET_ACCESS_KEY=$(jq -r .roleCredentials.secretAccessKey < temp_credentials.json)
export AWS_SESSION_TOKEN=$(jq -r .roleCredentials.sessionToken < temp_credentials.json)

# list s3 buckets
aws s3 ls

SO!!

The aws sso get-role-credentials command is a powerful tool for managing access to AWS resources across multiple accounts. With careful planning and proper use of SSO and IAM roles, you can ensure secure and efficient access management in your AWS environments.

Whether you’re an individual developer or part of a larger team, leveraging these tools can help to streamline your workflows and enhance the security of your operations.

Cheers! 🍺

A Summary of Influence - The Psychology of Persuasion

Yoonsoo Park — Wed, 07 Jun 2023 01:25:00 -0400

In his seminal book, “Influence: The Psychology of Persuasion”, Robert B. Cialdini presents six principles of persuasion that can be leveraged to influence others more effectively. These principles are Reciprocity, Scarcity, Authority, Consistency, Liking, and Consensus. Understanding these principles can help you to persuade others and achieve your goals.

1. Reciprocity

The principle of Reciprocity states that people are more likely to give back the kind of treatment they have received from others.

Example: Imagine you’re working on a software project. You need help from a colleague who is an expert in a particular technology. If you’ve previously helped them when they needed it, they’re much more likely to reciprocate and assist you.

2. Scarcity

The principle of Scarcity posits that people value things more when they are rare or difficult to obtain.

Example: Suppose your company is considering adopting a new software tool. By highlighting that a discount offer for the tool is about to end soon, you can use the scarcity principle to convince your team to make a quicker decision.

3. Authority

The Authority principle suggests that people tend to follow the lead of credible, knowledgeable experts.

Example: If you’re a respected tech lead in your team, your recommendations for code quality improvements are likely to be taken more seriously because of your perceived authority.

4. Consistency

The principle of Consistency holds that people like to be consistent with things they have previously said or done.

Example: If a team member has publicly expressed commitment to improving code quality, they’re more likely to follow through on actions that align with this commitment, such as adopting new coding standards or practices.

5. Liking

The Liking principle argues that people are more likely to be persuaded by people they like.

Example: If you have a good relationship with your project manager, they’re more likely to be persuaded by your proposal to adopt a new project management tool.

6. Consensus

The Consensus principle states that people often look to the actions and behaviors of others to determine their own.

Example: If you can demonstrate that multiple successful software companies are using a particular development methodology, your team might be more likely to adopt that methodology as well.

Wrapping up.

Understanding and leveraging these six principles can greatly enhance your persuasive abilities. Whether you’re negotiating a deal, leading a team, or influencing a decision, these principles can help you achieve your goals.

Cheers! 🍺

When to Use a Sequence Diagram - A Real Life Example

Yoonsoo Park — Tue, 06 Jun 2023 01:25:00 -0400

In the world of software design and development, diagrammatic representations of various processes and functionalities can prove extremely useful. One such useful tool is the Sequence Diagram. It’s a type of interaction diagram found in the Unified Modeling Language (UML). This article sheds light on when to use a sequence diagram, accompanied by a real-life example.

What is a Sequence Diagram?

A sequence diagram, in the context of UML, represents object collaboration and is used to define event sequences between objects for a certain outcome. It emphasizes the time-ordering of messages and allows developers to understand the architecture of the software system visually.

When to Use a Sequence Diagram?

There are several scenarios where a sequence diagram can be particularly helpful:

Designing complex interactions: When you have complex scenarios where several objects interact with each other, sequence diagrams can simplify these interactions by visualizing the message exchange in a sequential order.
Exploring various scenarios: Sequence diagrams can represent multiple scenarios within the same model by using alt (alternative), opt (optional), and loop (iteration) fragments.
Realizing use cases: Sequence diagrams can be used to map out and realize the details of use cases, showing how a system interacts with actors (users or other systems).
Understanding and debugging: They can help in understanding the existing code or in debugging a system as they provide a clear view of the interactions and the sequence of processes.
Protocol or interface modeling: Sequence diagrams can depict the details of a protocol or an interface, helping developers to understand how elements within a system communicate.

Real-Life Example

Let’s consider a real-life example of an online shopping system to understand when and how to use a sequence diagram.

When a customer places an order in an online shopping system, several objects interact with each other. This interaction involves a Customer, ShoppingCart, Payment, and Order objects. A sequence diagram can visualize this process, making it easier to understand.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


Title: Online Shopping Order Sequence

 Customer ShoppingCart Payment Order
 | | | |
 |----1. Add Item to Cart----> |
 | | | |
 |<---2. Confirm Item Added-- |
 | | | |
 |---3. Checkout ----> | |
 | |<---4. Calculate Total
 | | | |
 |----5. Pay ----> |
 | | |<---6. Process Payment
 | | | |
 |<---7. Confirm Payment |
 | | | |
 |----8. Place Order ----> |
 | | |<---9. Process Order
 |<--10. Order Confirmation-- |

In this sequence diagram:

The Customer adds an item to the ShoppingCart.
The ShoppingCart confirms the item has been added.
The Customer checks out, and the ShoppingCart calculates the total cost.
The Customer pays for the items.
The Payment processes the payment and confirms it to the Customer.
The Customer places the order.
The Order processes the order and sends an order confirmation back to the Customer.

Wrapping up!

Sequence diagrams are an integral part of UML, representing

how objects interact in a specific scenario of a use case. They help in simplifying complex interactions, realizing use cases, and understanding the sequence of processes in a system. So, whether you’re designing a new system or debugging an existing one, consider using a sequence diagram to visualize and understand the interactions better.

Cheers! 🍺

Deploying Services with AWS CDK and AWS SSO

Yoonsoo Park — Mon, 05 Jun 2023 01:25:00 -0400

AWS Cloud Development Kit (CDK) allows developers to define infrastructure resources with the programming languages we are familiar with. It provides a higher-level abstraction to create and manage AWS resources, making it easier to deploy and maintain complex architectures.

This article will show you how to use AWS CDK along with AWS Single Sign-On (SSO) to deploy services (e.g. API Gateway, Lambda functions, Lambda layers, and S3 buckets) with real-life examples.

Prerequisites

Before getting started, make sure you meet the following requirements:

An AWS account that has sufficient permissions to create & manage resources.
AWS CDK and AWS CLI installed and configured on your machine.
AWS Single Sign-On (SSO) set up with the appropriate users, groups, and permissions.

Real-Life Example: Deploying API Gateway, Lambda, Lambda Layer, and S3

Let’s say you want to create an API Gateway that invokes a Lambda function using a Lambda layer to have shared code. The Lambda function should read data from an S3 bucket and return a response.

Step 1: Set Up the Project

First, create a new directory for your CDK project and navigate to it:

1
2


mkdir my-cdk-project
cd my-cdk-project

Initialize a new CDK project like this:

1

cdk init --language typescript

Step 2: Install Required Dependencies

Now install the necessary dependencies for our project:

1

npm install aws-cdk-lib @aws-cdk/aws-apigateway @aws-cdk/aws-lambda @aws-cdk/aws-lambda-layer-awscli @aws-cdk/aws-s3 @aws-cdk/aws-ssm

Step 3: Define the CDK Stack

Please create a new file (MyStack.ts) and add the following code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


import * as cdk from "aws-cdk-lib";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as s3 from "aws-cdk-lib/aws-s3";

export class MyStack extends cdk.Stack {
 constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
 super(scope, id, props);

 // Create an S3 bucket
 const bucket = new s3.Bucket(this, "MyBucket");

 // Create a Lambda layer from local code
 const layer = new lambda.LayerVersion(this, "MyLayer", {
 code: lambda.Code.fromAsset("path/to/layer/code"),
 compatibleRuntimes: [lambda.Runtime.NODEJS_14_X],
 });

 // Create a Lambda function
 const fn = new lambda.Function(this, "MyFunction", {
 runtime: lambda.Runtime.NODEJS_14_X,
 handler: "index.handler",
 code: lambda.Code.fromAsset("path/to/function/code"),
 layers: [layer],
 environment: {
 BUCKET_NAME: bucket.bucketName,
 },
 });

 // Grant read permissions to the Lambda function
 bucket.grantRead(fn);

 // Create an API Gateway REST API
 const api = new apigateway.RestApi(this, "MyAPI");

 // Create an integration between API Gateway and Lambda

 const integration = new apigateway.LambdaIntegration(fn);

 // Create a resource and add the integration to a default method
 api.root.addMethod("GET", integration);
 }
}

Make sure to replace 'path/to/layer/code' and 'path/to/function/code' with the actual paths of your Lambda layer and function code.

Explain the code

The code you provided is an example of a CDK stack which deploys various AWS resources using AWS CDK. Let’s go through the code and explain what each part does:

1
2
3
4


import * as cdk from "aws-cdk-lib";
import * as apigateway from "aws-cdk-lib/aws-apigateway";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as s3 from "aws-cdk-lib/aws-s3";

These import statements bring in the necessary CDK constructs from the aws-cdk-lib library to create the AWS resources. In this case, we are importing constructs for API Gateway, Lambda, and S3.

1
2
3


export class MyStack extends cdk.Stack {
 constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
 super(scope, id, props);

This code defines a new class MyStack that extends cdk.Stack, which is a core construct in the CDK representing a stack. The constructor function is called when instance of this class is created. It takes parameters scope, id, and props.

1
2


// Create an S3 bucket
const bucket = new s3.Bucket(this, "MyBucket");

This creates a new S3 bucket named ‘MyBucket’ using the s3.Bucket construct. The this keyword points to the current stack instance.

1
2
3
4
5


// Create a Lambda layer from local code
const layer = new lambda.LayerVersion(this, "MyLayer", {
 code: lambda.Code.fromAsset("path/to/layer/code"),
 compatibleRuntimes: [lambda.Runtime.NODEJS_14_X],
});

This creates a Lambda layer named ‘MyLayer’ using the lambda.LayerVersion construct. The layer is created from the code in the project specified by the code property. The compatibleRuntimes property specifies the runtime compatibility. (in this case, Node.js 14.x)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Create a Lambda function
const fn = new lambda.Function(this, "MyFunction", {
 runtime: lambda.Runtime.NODEJS_14_X,
 handler: "index.handler",
 code: lambda.Code.fromAsset("path/to/function/code"),
 layers: [layer],
 environment: {
 BUCKET_NAME: bucket.bucketName,
 },
});

This creates a Lambda function named ‘MyFunction’ using the lambda.Function construct. The function is running with the Node.js 14.x runtime and the specified handler function. The function code is taken from the local directory pointed by the code property. The layers property specifies that the previously created layer should be included in the function. The environment property sets an environment variable BUCKET_NAME which is the name of the S3 bucket.

1
2


// Grant read permissions to the Lambda function
bucket.grantRead(fn);

This grants read permissions to the Lambda function on the S3 bucket(allowing it to access objects in the bucket).

1
2


// Create an API Gateway REST API
const api = new apigateway.RestApi(this, "MyAPI");

This creates a new API Gateway REST API with the apigateway.RestApi construct. The API is configured with the current stack and named ‘MyAPI’.

1
2


// Create an integration between API Gateway and Lambda
const integration = new apigateway.LambdaIntegration(fn);

This creates an integration between the API Gateway and the previously created Lambda function using the apigateway.LambdaIntegration construct. It specifies that the Lambda function fn should be invoked when the API Gateway receives requests.

1
2


// Create a resource and add the integration to a default method
api.root.addMethod("GET", integration);

This creates a new resource at the root of the API Gateway and adds a default GET method to it. The method is integrated with the Lambda function fn. When a GET request is made to the API, it will invoke the Lambda function.

When using AWS CDK, IAM policies are automatically assigned based on the resources created and the permissions needed by those resources.

e.g.

When creating an S3 bucket with the s3.Bucket construct, the CDK automatically assigns the necessary permissions to the IAM role associated with the Lambda function. In our case, the bucket.grantRead(fn) line grants read permissions to the Lambda function fn, allowing it to access objects in the bucket.
In the similar way, when creating an API Gateway REST API using the apigateway.RestApi construct, the CDK assigns the required IAM policies to allow the API Gateway to invoke the associated Lambda function. The integration created between the API Gateway and Lambda function handles the necessary permissions behind the scenes.

CDK makes the process of managing IAM policies easier by inferring the required permissions based on the resource dependencies and configuration. It automatically generates the IAM policies needed for the resources in the CDK stack that ensures the appropriate access is granted and reduces the manual IAM policy management.

Step 4: Deploy the Stack

Now, Let’s deploy our stack to AWS. Make sure you are logged in with the appropriate AWS SSO profile by running the following command:

1

aws configure sso --profile <your-profile-name>

Then we can build and deploy the CDK stack by:

1

cdk deploy --profile <your-profile-name>

The CDK will create the necessary resources in your AWS account, including the API Gateway, Lambda function, Lambda layer, and S3 bucket. (fingers crossed!)

Step 5: Test the API

Once the deployment is complete, you can find the API Gateway URL in the CDK stack output. Use a tool like cURL or Postman (or Bruno, I am a big fan of you) to send a GET request to the API and retrieve the response.

Did you get the response? we have successfully deployed services using AWS CDK and AWS SSO. 🎉 heck yeah!

Cheers! 🍺

Story or Die - How to Use Brain Science to Engage, Persuade, and Change Minds in Business and in Life Summary

Yoonsoo Park — Sun, 04 Jun 2023 01:25:00 -0400

In the book “Story or Die: How to Use Brain Science to Engage, Persuade, and Change Minds in Business and in Life”, the author delves into the fascinating connection between brain science, storytelling, and effective communication. Drawing insights from neuroscience, the book explores why storytelling is a powerful tool to engage, persuade, and ultimately change minds.

1. The Power of Storytelling and the Brain

Neuroscientist Michael Gazzaniga suggests that our brains primarily evaluate decisions in terms of approaching or withdrawing from a situation. This fundamental aspect of brain functioning underlines the importance of feeling safe when making choices. Consequently, the pursuit of psychological safety becomes crucial in effective communication within organizations.

2. Psychological Safety and the Need for Safety

Maintaining psychological safety is essential for individuals and organizations. People are wired to avoid threats to their safety, and they prioritize safety over abstract, conceptual, or neutral facts. Even if presented with important information, if it is perceived as a threat to their safety, individuals are likely to resist it.

3. The Role of Facts and Persuasion

Facts alone may not be sufficient for persuasion. To capture attention and achieve persuasion, facts need to clearly demonstrate the outcomes and benefits they bring, not only in terms of safety but also personal growth. When individuals are convinced that accepting a more correct opinion, despite contradicting their own beliefs, is safer, they become more open to accepting alternative viewpoints.

4. Overcoming Resistance and Instinctual Knowledge

Resistance to new ideas or facts stems from an instinctual knowledge that changing the current state can have potentially negative consequences. It is important to understand that people’s resistance to change is not due to intellectual deficiencies or flawed personalities but rather an inherent instinct for self-preservation.

5. The Role of Leaders and Organizations

True leaders and organizations should focus on creating an environment where individuals feel safe to change their thoughts and opinions. Encouraging others to recognize that adopting more accurate perspectives not only ensures their safety but also benefits them personally can foster open-mindedness and growth.

Wrapping up!

In conclusion, “Story or Die: How to Use Brain Science to Engage, Persuade, and Change Minds in Business and in Life” highlights the significance of storytelling and psychological safety in effective communication. By understanding the neuroscience behind decision-making and the need for safety, individuals and organizations can harness the power of storytelling to engage, persuade, and ultimately change minds.

Cheers! 🍺

Creating an Empty Commit in GitHub

Yoonsoo Park — Sat, 03 Jun 2023 01:25:00 -0400

When working with Git and GitHub, commits serve as important milestones that capture meaningful changes in your codebase. However, there may be situations where you need to create an empty commit without any actual code changes. (what if you need to trigger a Semantic Release by commiting.) Although GitHub’s user interface doesn’t provide a direct option to create an empty commit, you can achieve this through Git commands.

Creating an Empty Commit

To create an empty commit, use the following Git command:

1

git commit --allow-empty -m "Empty commit"

The --allow-empty flag allows creating a commit without any changes. The -m option is used to provide a commit message. Replace "Empty commit" with a meaningful message for your empty commit.

Pushing the Empty Commit

To push the empty commit to the remote repository, run the following command:

1

git push origin <branch-name>

Replace <branch-name> with the name of the branch where you want to push the empty commit.

Conclusion

Even though GitHub’s user interface doesn’t offer a direct option to create an empty commit, you can achieve this by utilizing Git commands. By following the steps outlined in this article, you can successfully create an empty commit and push it to your remote repository. Empty commits can be useful in certain scenarios, such as triggering build processes or signaling specific events in your version control history. Remember to use them judiciously and ensure that your commit history accurately reflects the changes in your codebase.

Cheers! 🍺

Using SFDX CLI Command to Insert User to Org

Yoonsoo Park — Fri, 02 Jun 2023 01:25:00 -0400

Prerequisites

Before getting started, make sure you have the following:

Salesforce DX CLI installed on your system. You can download it from the official Salesforce website.
A Salesforce DX project set up on your system.
An authenticated Salesforce Org where you want to insert the user.

Steps to Insert a User

Step 1: Create a JSON file with User details

First, you need to create a JSON file with the details of the user you want to insert. Here’s an example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "Username": "test@example.com",
 "LastName": "Test",
 "FirstName": "User",
 "Email": "test@example.com",
 "Alias": "tuser",
 "TimeZoneSidKey": "America/New_York",
 "LocaleSidKey": "en_US",
 "EmailEncodingKey": "UTF-8",
 "ProfileName": "Standard User",
 "LanguageLocaleKey": "en_US"
}

Save this file as user.json.

Step 2: Use the SFDX CLI to Insert the User

To insert the user, run the following command in your terminal:

1

sfdx force:data:record:create -s User -v $(jq -r '. | to_entries | map("\(.key)=\(.value|tostring)") | join(" ")' user.json) --json

This command uses the force:data:record:create SFDX command to insert a new user record. The -s User flag specifies that the record is for the User sObject. The -v flag followed by the jq command reads the values from the user.json file and formats them as key=value pairs.

Step 3: Verify the User Insertion

To verify that the user was inserted correctly, you can use the force:data:soql:query command:

1

sfdx force:data:soql:query -q "SELECT Id, Username FROM User WHERE Email = 'test@example.com'"

This command should return the Id and Username of the new user, confirming that the user was inserted successfully.

Wrapping up.

With the Salesforce DX CLI, inserting a user into an organization becomes a straightforward task. This command line tool is a powerful asset for Salesforce developers, providing flexibility and control over data manipulation tasks.

Cheers! 🍺

Tier vs Layer - Understanding the Organization of Software Architecture

Yoonsoo Park — Thu, 01 Jun 2023 01:25:00 -0400

In software architecture, the concepts of “tier” and “layer” play a crucial role in organizing and structuring complex systems. While often used interchangeably, understanding the distinctions between these terms is essential for designing scalable and maintainable applications. Let’s explore the difference between tiers and layers using a fictional e-commerce platform as an example.

Tiers: Dividing the Application Stack

Tiers refer to logical or physical divisions within an application stack based on functionality or deployment. They represent distinct layers that provide specific services and capabilities. In our e-commerce platform example, we can identify three primary tiers:

Presentation Tier: This tier handles the user interface and interaction. It includes components like web or mobile interfaces, user authentication, and front-end frameworks. Its primary responsibility is to deliver a visually appealing and user-friendly experience.
Application Tier: Also known as the business logic tier, this layer contains the core application logic. It encompasses functionalities such as product catalog management, order processing, and payment integration. The application tier coordinates and orchestrates the various operations required to run the e-commerce platform smoothly.
Data Tier: This tier focuses on data storage and retrieval. It includes databases, data caching mechanisms, and data access layers. In our example, the data tier would store information about products, customer details, and order history. It ensures reliable and efficient data management.

Layers: Modular Groupings within Tiers

Layers, on the other hand, are modular groupings or abstractions of components within a specific tier. They provide a structured approach to organizing functionalities and responsibilities. Let’s examine the layers within each tier of our e-commerce platform:

Presentation Tier Layers

User Interface Layer: This layer encompasses the visual elements and user interaction components. It includes HTML, CSS, JavaScript, and front-end frameworks like React or Angular. Its responsibility is to provide an engaging and intuitive user interface.
Authentication Layer: This layer focuses on user authentication and authorization mechanisms. It ensures secure access control and safeguards user accounts from unauthorized access.

Application Tier Layers

Product Management Layer: This layer handles product-related functionalities such as catalog management, inventory tracking, and pricing. It orchestrates the logic for creating, updating, and displaying product information.
Order Processing Layer: This layer manages the end-to-end order processing flow, including cart management, payment integration, and shipping coordination. It ensures accurate and timely order fulfillment.

Data Tier Layers

Database Layer: This layer represents the underlying database management system (DBMS) responsible for data storage and retrieval. It includes database technologies like MySQL, PostgreSQL, or MongoDB.
Data Access Layer: This layer provides an abstraction over the database and handles interactions with the data. It encapsulates queries, data validation, and caching mechanisms, ensuring efficient and secure data access.

Conclusion

Understanding the distinctions between tiers and layers in software architecture is vital for designing scalable, modular, and maintainable systems. Tiers represent logical or physical divisions based on functionality, while layers provide structured groupings within each tier. By effectively organizing components into tiers and layers, developers can build robust and well-structured applications.

Cheers! 🍺

Understanding the Differences Between IaaS, FaaS, and PaaS in Cloud Computing

Yoonsoo Park — Wed, 31 May 2023 01:25:00 -0400

Cloud computing has revolutionized the way we build, deploy, and scale applications. It offers various models that cater to different needs, such as Infrastructure as a Service (IaaS), Function as a Service (FaaS), and Platform as a Service (PaaS). In this article, we will explore these models and understand their distinctions using examples from popular cloud providers.

Infrastructure as a Service (IaaS)

IaaS provides virtualized computing resources over the internet, allowing users to build and manage their infrastructure without the need for physical hardware. Cloud providers offer a range of services under IaaS, including virtual machines (VMs), storage, and networking.

An excellent example of IaaS is Amazon Web Services (AWS) Elastic Compute Cloud (EC2). With EC2, users can provision virtual servers in the cloud, choosing from a variety of instance types, operating systems, and configurations. Users have complete control over the virtual machines, including managing the operating system, runtime, middleware, and applications. Microsoft Azure Virtual Machines and Google Compute Engine are other popular IaaS offerings.

Function as a Service (FaaS)

FaaS, also known as serverless computing, is a cloud computing model that abstracts away the infrastructure and server management, allowing developers to focus solely on writing and deploying code. In the FaaS model, developers write individual functions that are executed in response to specific events or requests.

One of the prominent FaaS platforms is AWS Lambda. With Lambda, you can write functions in various programming languages and configure triggers to execute them. Lambda automatically scales the infrastructure to handle the workload and charges you based on the number of invocations and the duration of execution. Azure Functions and Google Cloud Functions are other popular FaaS offerings.

Platform as a Service (PaaS)

PaaS provides a complete platform for application development and deployment, abstracting away the underlying infrastructure and simplifying the development process. PaaS offers pre-configured computing resources, including the operating system, middleware, and development tools.

AWS Elastic Beanstalk is an example of PaaS. It allows developers to deploy and manage applications easily without worrying about the underlying infrastructure. Elastic Beanstalk supports multiple programming languages and provides auto-scaling, load balancing, and automatic application health monitoring. Microsoft Azure App Service and Google App Engine are other popular PaaS offerings.

Conclusion

In conclusion, IaaS, FaaS, and PaaS are distinct cloud computing models, each catering to different levels of infrastructure management and abstraction. IaaS provides virtualized infrastructure resources, allowing users to have complete control over the underlying infrastructure. FaaS abstracts away infrastructure concerns, enabling developers to focus solely on writing code. PaaS offers a complete platform for application development and deployment, simplifying the infrastructure management process.

Understanding the differences between these models is crucial for selecting the appropriate cloud service based on your requirements. Whether it’s the flexibility of IaaS, the serverless nature of FaaS, or the ease of development with PaaS, cloud providers offer a wide range of services to empower your applications in the cloud.

Remember, when choosing a cloud provider, consider factors such as pricing, scalability, availability, and integration options to ensure the best fit for your specific needs.

Cheers! 🍺

Guiding Interns in Your Team

Yoonsoo Park — Tue, 30 May 2023 01:25:00 -0400

As a seasoned professional, it is important to understand the significance of guiding interns effectively within your team. Internships provide valuable learning opportunities, and by offering guidance, you can help shape their professional growth. In this article, we will explore some insightful advice inspired by famous books that can serve as a guiding light in mentoring interns.

1. “The Alchemist” by Paulo Coelho: Unleash their Potential

Just as the protagonist Santiago embarks on a transformative journey, your intern is also at the beginning of their career voyage. Approach your role as a mentor with the mindset of an alchemist. Recognize the untapped potential within them and help them discover their unique strengths. Encourage them to experiment with different tasks, departments, and roles, allowing them to unearth their passions and interests.

2. “The Lean Startup” by Eric Ries: Embrace the Iterative Process

Eric Ries emphasizes the importance of an iterative approach in startups, and this principle can be applied to guiding interns as well. Encourage them to adopt a mindset of continuous learning and improvement. Provide regular feedback and set short-term goals, enabling them to make incremental progress. Emphasize that failures are stepping stones to success, and that learning from mistakes is an integral part of professional growth.

3. “Quiet: The Power of Introverts in a World That Can’t Stop Talking” by Susan Cain: Nurture Diverse Talents

Interns come from diverse backgrounds, and it is essential to recognize and appreciate the unique talents they bring to the team. Drawing inspiration from Susan Cain’s book, understand that introverted individuals may possess exceptional analytical skills and a propensity for introspection. Create an inclusive environment that caters to different personalities, allowing interns to thrive and contribute in their own unique way.

4. “The 7 Habits of Highly Effective People” by Stephen R. Covey: Foster Independence and Proactivity

In Stephen R. Covey’s timeless book, he shares seven habits that lead to success. Two key habits, “Be Proactive” and “Begin with the End in Mind,” are particularly relevant when guiding interns. Encourage them to take ownership of their work and projects. Set clear objectives and allow them to devise their own plans to achieve those goals. This approach fosters independence, responsibility, and a sense of accountability.

5. “The Art of War” by Sun Tzu: Cultivate a Supportive Environment

Sun Tzu’s ancient treatise on warfare provides valuable insights on leadership and strategy. While the battlefield might seem far removed from the office, the concept of fostering a supportive environment applies universally. Be a mentor who leads by example, offering guidance and support while allowing interns to learn from their experiences. Create an atmosphere that encourages open communication, collaboration, and camaraderie among team members.

Conclusion

Guiding interns effectively requires patience, empathy, and an understanding of their unique needs and aspirations. By incorporating lessons from famous books into your mentoring approach, you can inspire and empower interns to reach their full potential. Remember, as a mentor, your guidance can have a profound impact on shaping their future careers. Embrace this opportunity to make a positive difference and create a legacy that extends far beyond their time as interns.

Note: The book references mentioned in this article serve as metaphors and sources of inspiration for guiding interns, and their concepts should be adapted and applied in a manner appropriate to the professional context.

Cheers! 🍺

The Pragmatic Programmer; Bend or Break

Yoonsoo Park — Mon, 29 May 2023 01:25:00 -0400

Bend or Break: Embracing Adaptability

The Bend-or-Break principle encourages software developers to be flexible and adaptable in the face of changing requirements, technologies, and project circumstances. Instead of clinging rigidly to predefined plans or solutions, this philosophy emphasizes the need to adjust, iterate, and overcome challenges by bending existing strategies or breaking away from them altogether.

Real-Life Examples

Mobile Application Development: Consider a team developing a mobile application for a startup. During the initial planning phase, they decide to build the app for a specific platform. However, as the project progresses, they realize that the target market prefers a different platform. To adapt, the team must be willing to break away from their original plan and pivot towards the new platform, rather than persisting with a less suitable solution.
Agile Development: Agile methodologies, such as Scrum, embody the bend-or-break philosophy. Agile teams embrace change and regularly adapt their plans based on customer feedback and evolving requirements. They recognize that being rigid and unwilling to adjust can hinder progress and limit the potential for delivering valuable software.
Software Maintenance: When maintaining legacy systems, developers often encounter outdated technologies or code that no longer aligns with modern best practices. To ensure the continued functionality and improvement of the system, developers must be willing to bend the existing codebase, refactoring and modernizing it over time, or even breaking away from it completely and rebuilding certain components to ensure scalability and maintainability.

The Benefits of Adaptability

Embracing the bend-or-break mindset offers several advantages to software developers and teams:

Resilience: Adaptability enables programmers to navigate unexpected challenges and respond effectively to shifting circumstances. By bending or breaking, developers can overcome obstacles, meet evolving requirements, and deliver valuable solutions.
Innovation: Flexibility allows developers to explore new technologies, frameworks, and methodologies. By being open to change, they can experiment, learn, and leverage emerging trends to create innovative solutions that better meet user needs.
Continuous Learning: Adapting to change necessitates acquiring new knowledge and skills. The bend-or-break philosophy promotes a culture of continuous learning, empowering developers to expand their expertise and stay up-to-date with advancements in the field.
Delivering Value: By embracing adaptability, developers can deliver software that better aligns with user expectations and market demands. Being responsive to change increases the likelihood of delivering timely, relevant, and high-quality products.

Wrapping up

In the fast-paced world of software development, the bend-or-break philosophy outlined in “The Pragmatic Programmer” is crucial. Embracing adaptability allows programmers to thrive amidst changing requirements, emerging technologies, and evolving project circumstances. By being willing to bend existing plans and strategies or break away from them when necessary, developers can foster resilience, drive innovation, embrace continuous learning, and ultimately deliver valuable software solutions.

Cheers! 🍺

The Pragmatic Programmer; A Pragmatic Approach

Yoonsoo Park — Sun, 28 May 2023 01:25:00 -0400

In The Pragmatic Programmer, Andrew Hunt and David Thomas present a wealth of wisdom and practical guidance for software developers. Section 3 of the book, titled “A Pragmatic Approach,” dives into the essence of pragmatic programming and how it can revolutionize the way we approach software development.

Embracing Pragmatic Programming

A pragmatic approach to software development revolves around practicality, effectiveness, and adaptability. It encourages programmers to go beyond following strict methodologies and instead focus on finding practical solutions that deliver value to users. Let’s explore the key principles and practices that define a pragmatic approach.

Deadlines as Opportunities

Pragmatic programmers view deadlines not as constraints, but as opportunities for prioritization and delivering incremental value. By embracing realistic deadlines, developers can focus on delivering the most critical features first and iterating on their work over time. This approach allows for faster feedback cycles and aligns development efforts with user needs.

Maintainable Code: The Golden Rule

Writing maintainable code lies at the core of a pragmatic approach. Pragmatic programmers recognize that code is read more often than it is written. They prioritize writing clear, well-structured code that is easy to understand and modify. By considering future maintainers of the codebase, they ensure long-term productivity and reduce technical debt.

Debugging: Thinking Outside the Box

When facing software bugs, a pragmatic programmer employs a systematic and creative approach to debugging. They go beyond simply fixing the immediate symptom and strive to understand the underlying cause. Techniques like rubber duck debugging, where programmers explain their code to an inanimate object, help uncover hidden issues and encourage problem-solving from different perspectives.

Automation: Working Smarter, Not Harder

Automation is a cornerstone of pragmatic programming. By automating repetitive tasks and building efficient workflows, developers can save time and reduce errors. Whether it’s automating code formatting, setting up continuous integration pipelines, or creating scripts for deployment, automation empowers programmers to work smarter and focus on higher-value activities.

Pragmatic Testing: Balancing Coverage and Efficiency

Testing is a vital component of pragmatic programming. Pragmatic programmers aim for a balanced approach to testing, seeking an optimal trade-off between coverage and efficiency. They prioritize critical tests and focus on generating meaningful test cases that cover a wide range of scenarios, while avoiding excessive redundancy that could hamper development speed.

Revolutionizing Software Development with a Pragmatic Approach

A pragmatic approach to software development enables programmers to adapt, evolve, and thrive in the ever-changing landscape of technology. By embracing practicality, maintaining code quality, employing effective debugging techniques, leveraging automation, and adopting a balanced testing strategy, developers can deliver high-quality software that meets user needs while maximizing efficiency.

Let us embark on this journey of pragmatic programming, where innovation and practicality go hand in hand, and software development becomes a delightful and productive endeavor.

Cheers! 🍺

The Pragmatic Programmer; A Pragmatic Philosophy

Yoonsoo Park — Sat, 27 May 2023 01:25:00 -0400

The Pragmatic Programmer is a renowned book written by Andrew Hunt and David Thomas, offering valuable insights and practical advice for software developers. In Section 2 of the book, titled “A Pragmatic Philosophy,” the authors introduce a mindset and set of principles that form the foundation of a pragmatic approach to programming. Let’s explore this philosophy and its real-life applications.

The Cat Ate My Source Code

One key aspect of the pragmatic philosophy is taking responsibility for our work. It’s easy to blame external factors or circumstances when things go wrong, but a pragmatic programmer acknowledges their role in the development process. For example, imagine a software developer who encounters a bug in their code. Instead of blaming the lack of clear requirements or time constraints, they focus on understanding and rectifying the issue, taking ownership of their codebase.

Software Entropy: The Constant Battle

Software entropy refers to the tendency of software systems to become more complex and disorganized over time. A pragmatic programmer recognizes the need to combat entropy through regular code maintenance, refactoring, and clean-up efforts. Consider a scenario where a development team notices their codebase becoming difficult to maintain due to increasing complexity. They adopt a pragmatic approach by scheduling regular refactoring sessions and implementing automated tests to catch regressions, thereby managing and reducing software entropy.

Stone Soup and Boiled Frogs: The Power of Incremental Change

The metaphors of stone soup and boiled frogs illustrate the value of incremental change. In software development, making small, meaningful improvements over time can lead to substantial progress. For instance, imagine a project manager who wants to introduce a new development process to improve team efficiency. Instead of imposing a drastic change overnight, they take a pragmatic approach by gradually introducing small process tweaks, encouraging feedback from the team, and iteratively refining the process based on real-world outcomes.

Good Enough Software: Balancing Perfectionism and Pragmatism

The pursuit of perfection can hinder progress in software development. The pragmatic philosophy suggests focusing on delivering “good enough” software that meets current requirements while maintaining a high level of quality. For instance, imagine a startup developing a minimum viable product (MVP) to test its viability in the market. Instead of spending excessive time on refining every feature, they adopt a pragmatic approach by prioritizing core functionality and delivering a working product within the available resources and timeframe.

Your Knowledge Portfolio: Investing in Continuous Learning

A pragmatic programmer understands the importance of continually expanding their knowledge and skills. They treat their professional development as an investment portfolio, diversifying their expertise and regularly updating existing skills. For example, a software developer may invest time in learning a new programming language or exploring emerging technologies that align with their career goals. By maintaining an up-to-date knowledge portfolio, they remain adaptable and valuable in a rapidly evolving industry.

We will read the Section 3, A Pragmatic Approach, tomorrow.

Cheers! 🍺

A Summary of Surrounded by Idiots by Thomas Erikson

Yoonsoo Park — Fri, 26 May 2023 01:25:00 -0400

Alright, listen up aspiring code nerds! (in a good way ;) If you want to rock the software engineering realm, there’s a crucial superpower you gotta wield: communication skills! Even if you couldn’t care less about the crazy lives of your fellow humanoids, you simply can’t dodge the inevitable communication or chit-chat. So, brace yourselves, folks! Embrace the unavoidable art of conversation like a true champ, or prepare to be stuck in an eternal bug-fixing abyss.

Understanding and Applying the Four Main Communication Styles: Red, Yellow, Green, and Blue

In the international bestseller “Surrounded by Idiots,” Thomas Erikson provides a unique perspective on understanding and dealing with different communication styles. Grounded in the DISC behavioral assessment tool, Erikson assigns colors to these styles: Red, Yellow, Green, and Blue. This system allows for a more effective approach to interpersonal communication.

1. Red (Dominance)

Red individuals are characterized by their determination, strong will, and ability to maintain control. They are dynamic, active, and task-oriented.

Key traits:

Decisive: They make quick decisions and are driven by power and control.
Goal-oriented: Reds thrive on challenges and are often competitive.
Impatient: They prefer quick actions and results.

Communication style:

Reds prefer direct, clear, and to-the-point communication. They value efficiency and may become impatient with lengthy discussions.

When communicating with Red individuals, clarity and brevity are key. State your points in a structured, concise manner, focusing on the results or outcomes. Avoid giving too many details or lengthy explanations.

2. Yellow (Influence)

Yellow individuals are sociable, expressive, and dynamic. They thrive in environments where interaction and socializing are encouraged.

Key traits:

Enthusiastic: Yellows are often the life of the party, bringing energy and positivity wherever they go.
Persuasive: They excel at influencing and inspiring others.
Optimistic: Yellows often see the brighter side of things, maintaining a positive outlook.

Communication style:

Yellows enjoy interactive and engaging communication. They enjoy storytelling and use humor frequently.

When communicating with Yellow individuals, adopt an engaging, positive, and friendly approach. Avoid being overly formal or negative. Yellows prefer exciting ideas, stories, and an energetic tone.

3. Green (Steadiness)

Green individuals prioritize relationships and are patient, supportive, and relaxed. They value cooperation and prefer a peaceful environment.

Key traits:

Reliable: Greens are dependable and consistent.
Patient: They are tolerant and tend to avoid conflicts.
Team-oriented: Greens work well in a team setting, prioritizing group harmony.

Communication style:

Greens communicate in a calm, patient manner, preferring to listen first and speak second. They value relationships and focus on understanding others’ viewpoints.

When communicating with Green individuals, demonstrate patience, understanding, and empathy. Show genuine interest in their thoughts and feelings. Avoid aggression, confrontation, or a rushed approach.

4. Blue (Conscientiousness)

Blue individuals are analytical, meticulous, and systematic. They value accuracy and logic.

Key traits:

Analytical: Blues prefer to thoroughly examine information before making decisions.
Detail-oriented: They pay careful attention to details and value precision.
Systematic: Blues follow specific processes or systems.

Communication style:

Blues communicate in a logical, systematic manner. They prefer facts, details, and well-structured arguments.

When communicating with Blue individuals, be analytical, logical, and accurate. They appreciate facts and precise details. Be prepared to answer questions and provide evidence for your statements. Avoid emotional arguments, ambiguity, or inconsistency.

Wrapping up.

Understanding these four communication styles can greatly improve your interpersonal relationships and effectiveness at work. However, keep in mind that these are guidelines, and real people may exhibit traits from several colors. The objective is to make your interlocutor feel understood, respected, and comfortable during the conversation by adapting your communication style to theirs.

Now, if you can categorize your co-workers into these convenient color compartments, congratulations, you’ve passed Communication 101. But don’t pop the champagne yet, that’s just the beginning. Keep stuggling until you master it.

Cheers! 🍺

The Rules of Work by Richard Templar

Yoonsoo Park — Thu, 25 May 2023 01:25:00 -0400

The Rules of Work is a practical guide by Richard Templar. It is composed of 108 rules that guide professionals in navigating their work lives more efficiently and effectively. In this summary, we will highlight some of the key points that Templar emphasizes in his influential work.

Introduction

Templar’s book offers a fresh perspective on the unspoken rules that dictate success in the workplace. The author’s rules are intended to make one more professional, confident, and ultimately, more successful at work. The book is divided into ten parts, each highlighting different facets of the workplace.

Walk Your Talk

Get your work noticed.
Never stand still.
Volunteer carefully.
Carve out a niche for yourself.
Under promise and over deliver.

Know That You’re Being Judged at All Times

Cultivate a smile.
Dress well.
Cultivate the art of speech.
Be aware of personal space.
Practice being liked.

Have a Plan

Know what you want long term.
Know what you want short term.
Study the promotion system.
Develop a game plan.
Set objectives.

If You Can’t Say Anything Nice, Shut Up

Don’t gossip.
Be cheerful and positive.
Keep your personal life to yourself.
Be a good listener.
Only speak sense.

Look After Yourself

Know the ethics of your industry.
Know the legalities of your industry.
Set personal standards.
Have positive personal ambitions.
Be physically fit.

Blend In

Know the corporate culture.
Speak the language.
Dress up or down accordingly.
Be adaptable in your dealings with different people.
Know where to hang out, and when.

Act One Step Ahead

Dress one step ahead.
Talk one step ahead.
Act one step ahead.
Think one step ahead.
Address corporate issues and problems one step ahead.

Cultivate Diplomacy

Know the system — and milk it.
Be wise with information.
Beware of the office politics.
Be discreet.
Cultivate the friendship and respect of your colleagues.

Know the Rules About Authority

Understand the hierarchy.
Know who the real bosses are.
Know the people who know the people.
Never disapprove of others.
Understand the role of the job.

Play the Game

Know that we’re all playing a game.
Be enthusiastic.
Be a ‘can-do’ person.
Be 100% committed.
Maintain a sense of humor.

Look Out for the Future

Know the business you’re in.
Constantly reassess your position.
Know where you want to go.
Make sure your manager knows you want to progress.
Study the industry.
Study the competition.
Study your organization.
Study your department.
Study your job.
Know the skills of the future and acquire them.

Know When to Break the Rules

Know which rules to break.
Be subtle.
Bend the rules, don’t break them.
Make sure breaking the rule benefits the company.
Don’t get caught.
Do it with humor.
Know the exceptions to the rule.
Know that there’s always an exception to the rule.
Be paradoxical.
If in doubt, don’t.

Be Good at PR

Know the benefits of networking.
Create a network.
Maintain your network.
Use your network.
Enjoy your network.
Be known for one thing.
Self-publicize.
Project a consistent image.
Make sure your manager knows how good you are.
Be modest.

Know the System

Understand the company’s philosophy.
Learn the unspoken rules.
Know the rules about the money.
Know the rules about communicating.
Know the rules about sex.
Know the rules about company property.
Know what gets rewarded.
Know what doesn’t get rewarded.
Know when to stand by the rules.
Know when to ignore them.

Don’t Push Too Hard

Don’t badmouth the competition.
Don’t badmouth the company.
Don’t whine.
Don’t rely on one ally.
Don’t hide behind your job description.
Don’t have favorites.
Don’t be irreplaceable.
Don’t carry tales.
Don’t rely on status.
Don’t push your luck.

Know the Tricks

Watch for game players.
Identify the company politics.
Be aware of personal agendas.
Beware of the insecure.
Watch out for the ambitious.
Understand power structures.
Recognize power plays.
Know when to leave.

Conclusion

The Rules of Work presents a pragmatic and effective roadmap for professional success. It provides guidance on how to behave, how to look, and how to navigate workplace dynamics effectively. Templar’s rules are not about manipulating others, but about helping professionals become adept at working within the corporate culture to their advantage.

In essence, Templar’s advice is centered around becoming a good team player, maintaining professionalism, and balancing work with a healthy lifestyle. It’s a must-read for anyone serious about making a mark in their professional life.

“It’s all a game, and the Rules of Work are the rules of the game. We all have to go to work, and we all play the game. The winners will be the ones who are very good at playing the game professionally,” - Richard Templar.

Cheers! 🍺

Walking the Directory and Creating a TreeNode

Yoonsoo Park — Wed, 24 May 2023 01:25:00 -0400

Walking the Directory and Creating a TreeNode in Node.js

In this article, we will be exploring how to navigate or walk through a file directory in Node.js, creating a TreeNode for each file or subdirectory we encounter. This will involve using Node’s built-in fs (file system) and path modules, as well as the crypto module for hashing file contents.

First, let’s begin by creating an interface for our file metadata:

1
2
3
4
5


interface FileMetadata {
 path: string;
 isDirectory: boolean;
 hash?: string;
}

Here, our FileMetadata interface defines three properties: path (the file or directory path), isDirectory (a boolean indicating if the path is a directory), and hash (a string representing a file hash, which will be optional since directories won’t have a hash).

Next, we create a TreeNode class:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


class TreeNode {
 metadata: FileMetadata;
 children: TreeNode[];

 constructor(metadata: FileMetadata, children: TreeNode[] = []) {
 this.metadata = metadata;
 this.children = children;
 }

 print(level: number = 0): void {
 console.log(' '.repeat(level * 2) + (this.metadata.isDirectory ? 'Dir: ' : 'File: ') + this.metadata.path);
 for (let child of this.children) {
 child.print(level + 1);
 }
 }
}

The TreeNode class represents a node in our tree structure. Each node contains metadata (of type FileMetadata) and an array of child nodes (children). The print method allows us to print the path of the node and its children, with indentation to represent the depth in the tree.

We’ll need a method to hash a file’s content. For this, we use Node.js’s built-in crypto module:

1
2
3
4
5
6


function hashFile(file: string): string {
 const fileBuffer = fs.readFileSync(file);
 const hashSum = crypto.createHash('sha256');
 hashSum.update(fileBuffer);
 return hashSum.digest('hex');
}

The hashFile function reads a file synchronously into a buffer, then uses crypto.createHash to create a SHA-256 hash, which is updated with the file content buffer. The digest is then returned as a hexadecimal string.

Finally, we create the walkDir function:

1
2
3
4
5
6
7
8
9


function walkDir(dir: string): TreeNode {
 const dirent = fs.lstatSync(dir);
 if (dirent.isDirectory()) {
 const children = fs.readdirSync(dir).map(name => walkDir(path.join(dir, name)));
 return new TreeNode({ path: dir, isDirectory: true }, children);
 } else {
 return new TreeNode({ path: dir, isDirectory: false, hash: hashFile(dir) });
 }
}

The walkDir function synchronously gets the status of the input directory (dir). If it’s a directory, it reads the directory’s contents and recursively walks each entry, creating a TreeNode for each one. If the input dir is a file, it creates a TreeNode for the file, computing and storing the file’s hash.

With the use of these Node.js methods and our defined TreeNode class, we can efficiently traverse a file directory, create a tree-like structure for it, and obtain the hash of each file. This is particularly useful when you need to track the state of files in a directory, for example in a version control system.

Cheers! 🍺

AWS SSO with TypeScript

Yoonsoo Park — Tue, 23 May 2023 01:25:00 -0400

AWS Single Sign-On: An In-depth Guide with TypeScript Example

AWS Single Sign-On (AWS SSO) is a cloud-based service that makes it easier to manage SSO access to AWS accounts and business applications. By using AWS SSO, you can centrally manage access to multiple AWS accounts which improves user productivity and security.

Overview of AWS SSO

AWS SSO offers the following features:

Centralized access management: You can manage access to all your AWS accounts from a single location.
Integration with business applications: AWS SSO is pre-configured with many business platforms (e.g. Salesforce, Office 365, and Box).
Automated setup: AWS SSO is easy to set up and connect to your existing identity providers (e.g. Microsoft Active Directory or AWS Managed Microsoft AD).
Compliance and Security: AWS SSO logs all SSO access events in AWS CloudTrail that helps you meet the requirements.

Configuring AWS SSO

Following steps are required to configure AWS SSO:

Sign into the AWS Management Console and open the AWS SSO console at https://console.aws.amazon.com/singlesignon/.
On the dashboard, choose “Enable AWS SSO”.
Under “Choose your identity source”, select AWS Managed Microsoft AD.
Choose “Next: Permission Sets” and define the AWS managed policies that you want to be part of your permission sets.
Review the settings and choose “Enable AWS SSO”.

AWS CLI Profile Configuration

To use AWS CLI with AWS SSO, you MUST configure a profile that contains your AWS SSO credentials. You can do this with the following steps:

Open the terminal and run aws configure sso.
Enter the requested SSO information.
Once your browser completes the sign-in, return to the terminal to proceed.
Choose a profile name (default is ‘default’).
Once this process is complete, AWS CLI v2 will use this profile’s settings when interacting with AWS.

Your AWS SSO configuration will be saved in the ~/.aws/config file and looks like the below example:

1
2
3
4
5
6
7


[profile my-aws-profile]
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_region = us-west-2
sso_account_id = 123456789012
sso_role_name = ReadOnly
region = us-west-2
output = json

Execute The AWS CLI Command for AWS SSO Authentication

We can use Node.js’ built-in child_process module to start a new process to execute the AWS CLI command for AWS SSO authentication. The example of how to accomplish this is in the below section:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


import { exec } from "child_process";

function authenticateWithAwsSso(profileName: string) {
 // Command to initiate AWS SSO login
 const command = `aws sso login --profile ${profileName}`;

 // Spawn a shell then execute the command within that shell
 exec(command, (error, stdout, stderr) => {
 if (error) {
 console.log(`error: ${error.message}`);
 return;
 }

 if (stderr) {
 console.log(`stderr: ${stderr}`);
 return;
 }

 // If successful, the command prints to stdout
 console.log(`stdout: ${stdout}`);
 });
}

// Use the function
authenticateWithAwsSso("my-aws-profile");

In this example, we’re using the exec function from the child_process module to spawn a shell and then execute the AWS CLI command in that shell. We’re passing in the command to start the AWS SSO login process with the specified profile.

The exec function takes a callback function as the second argument, which is invoked when the process terminates. If there is an error starting the process or if it exits with a non-zero status code, the error object will be non-null. The stdout and stderr parameters contain the output of the command.

Note: Before running this code, make sure that you have configured the ‘my-aws-profile’ with AWS SSO, and you have AWS CLI v2 installed in your machine. This approach assumes that the AWS CLI is accessible in the system’s PATH. It also assumes that the AWS SSO login session is not expired. The login session duration is typically 1 hour, but it depends on the configuration. If the session has expired, you’ll need to log in again by opening a browser and authenticating against your AWS SSO user portal.

Cheers! 🍺

AWS IAM User vs Role

Yoonsoo Park — Mon, 22 May 2023 01:25:00 -0400

AWS IAM User vs Role

Amazon Web Services (AWS) Identity and Access Management (IAM) is a critical component of AWS that helps manage access to AWS services and resources. IAM allows you to manage users, security credentials (e.g. access keys), and permissions that controls which resources users and applications can use and perform actions on. IAM uses two main entities for these: Users and Roles. This post is about the details of IAM Users and Roles to understand their roles.

AWS IAM Users

An IAM user is an entity that represents a person or a service that interacts with AWS. IAM users are created for specific individuals or applications that need access to your AWS resources.

1
2
3
4
5
6
7


Key Features:

1. Permanent AWS identities.
2. Have unique security credentials (e.g. password & access keys).
3. Users can be added to IAM groups.
4. Directly attached with permissions.
5. Used by people or applications outside AWS.

When to use IAM Users?

You should use IAM Users when you want to give permanent access to a specific person or application. It’s also used when you want the entity to use AWS security credentials like passwords or access keys.

AWS IAM Roles

An IAM Role is an IAM entity that is a set of permissions for making AWS service requests. Unlike users, roles DO NOT PERMANENTLY ASSIGNED credentials; instead, TEMPORARY security tokens are provided to a role when it is assumed.

1
2
3
4
5
6
7


Key Features:

1. Does not have any credentials.
2. Temporary security tokens are created when the role is assumed.
3. Can be assumed by anyone with permissions to do so.
4. Can be used by services within AWS to perform actions on your behalf.
5. Roles are the recommended way to provide permissions to applications running on EC2 instances.

When to use IAM Roles?

IAM Roles should be used for granting permissions to AWS services (e.g. AWS Lambda) to perform actions on your behalf. You should also use roles when you want to grant access to resources for users from a different AWS account or when you want to set permissions for applications running on EC2 instances.

IAM Users vs IAM Roles: The Differences

The main differences between IAM Users and Roles are their purposes and the type of credentials they use. IAM Users are intended for long-term access for specific individuals or applications. In the other hand, Roles are usually used for short-term, temporary access or to allow AWS services to perform actions on your behalf.

IAM Users have their own AWS security credentials, while IAM Roles use temporary security tokens when they are assumed. IAM Roles are considered as a more secure way to access, as they do not require long-term credentials, which can be a security risk.

Cheers! 🍺

The Observer Pattern

Yoonsoo Park — Sun, 21 May 2023 01:25:00 -0400

Understanding the Observer Pattern in TypeScript: A Comprehensive Guide

The Observer pattern is a design pattern in which an object, known as the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, typically by calling one of their methods.

This pattern is particularly useful when you want to ensure multiple parts of your application are notified when another part changes. It fosters a degree of loose coupling between different parts of an application.

How does the Observer Pattern Work?

Let’s break down the main components of the Observer pattern:

Subject: The subject holds the state and oversees the observers. It provides the methods to register and unregister observers. Moreover, it has a method to notify all observers of a state change.
Observer: Observers are objects that follow the state of the subject. They expose a method that gets called when the subject’s state changes.
Concrete Subject: It’s the object having the state that other objects are interested in. It extends the Subject class.
Concrete Observer: These are the real objects that are observing the state. They extend the Observer class.

Example with TypeScript

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


interface Subject {
 registerObserver(o: Observer): void;
 removeObserver(o: Observer): void;
 notifyObservers(): void;
}

interface Observer {
 update(temperature: number): void;
}

class WeatherStation implements Subject {
 private temperature: number;
 private observers: Observer[] = [];

 setTemperature(temp: number) {
 console.log('WeatherStation: new temperature measurement: ' + temp);
 this.temperature = temp;
 this.notifyObservers();
 }

 registerObserver(o: Observer) {
 this.observers.push(o);
 }

 removeObserver(o: Observer) {
 let index = this.observers.indexOf(o);
 this.observers.splice(index, 1);
 }

 notifyObservers() {
 for (let observer of this.observers) {
 observer.update(this.temperature);
 }
 }
}

class TemperatureDisplay implements Observer {
 private subject: Subject;

 constructor(weatherStation: Subject) {
 this.subject = weatherStation;
 weatherStation.registerObserver(this);
 }

 public update(temperature: number) {
 console.log('TemperatureDisplay: I need to update my display');
 // Logic would go here
 }
}

let weatherStation = new WeatherStation();
let tempDisplay = new TemperatureDisplay(weatherStation);
weatherStation.setTemperature(20);

In the example above, the WeatherStation is the subject that maintains the list of observers and notifies them of any changes. TemperatureDisplay is the observer that gets notified of the changes.

The observer pattern is a powerful tool to have in your programming toolkit. It allows you to build flexible and modular systems that can handle changes and updates easily.

Cheers! 🍺

The Decorator Pattern

Yoonsoo Park — Sat, 20 May 2023 01:25:00 -0400

Unveiling the Decorator Pattern: A Deep Dive with TypeScript

The Decorator Pattern is one of the most powerful structural design patterns in the software development arsenal, granting flexibility and dynamism in extending object behavior.

What is the Decorator Pattern?

The Decorator Pattern is a design pattern that allows behavior to be added to individual objects, either statically or dynamically, without affecting the behavior of other objects from the same class. Decorators provide a flexible alternative to subclassing for extending functionality.

When Should You Use the Decorator Pattern?

The Decorator Pattern provides an alternative to subclassing, which involves creating a new class for every new behavior.

Use the Decorator Pattern when:

You want to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.
You want to add responsibilities to an object that you may want to change in the future.
Extending functionality by subclassing is impractical because it leads to a large number of subclasses and complicates code maintenance and error tracking.

Example with TypeScript

Let’s assume we are developing a text editor, and we want to have the ability to add various types of formatting to the text, such as bold, italic, or underline. Here is how we can implement this using the Decorator Pattern:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


// Base Component
interface Text {
 displayText(): string;
}

// Concrete Component
class PlainText implements Text {
 displayText(): string {
 return "Plain Text";
 }
}

// Base Decorator
class TextDecorator implements Text {
 constructor(protected text: Text) {}
 displayText(): string {
 return this.text.displayText();
 }
}

// Concrete Decorators
class BoldText extends TextDecorator {
 displayText(): string {
 return `Bold(${super.displayText()})`;
 }
}

class ItalicText extends TextDecorator {
 displayText(): string {
 return `Italic(${super.displayText()})`;
 }
}

// Usage
let text: Text = new PlainText();
text = new BoldText(text);
text = new ItalicText(text);

console.log(text.displayText()); // Outputs: Italic(Bold(Plain Text))

In this example, we’re able to apply multiple formatting options (bold, italic) to our text dynamically, and we can easily introduce more (like underline, strikethrough, etc.) without affecting existing classes.

Wrapping up

The Decorator Pattern is a highly effective tool in a developer’s toolbox, offering dynamic and flexible object behavior. It aligns well with the open-closed principle, one of the five principles of SOLID, leading to more maintainable and less error-prone code. Used appropriately and sparingly, the Decorator Pattern can greatly improve your code design and structure.

Cheers! 🍺

Strategy Pattern in Dependency Injection

Yoonsoo Park — Fri, 19 May 2023 01:25:00 -0400

Understanding the Concepts

Strategy Pattern

The Strategy Pattern is a behavioral design pattern that encapsulates algorithms into separate classes with a common interface, enabling interchangeability within the original context object. This approach enhances flexibility by allowing the switching of algorithms or logic at runtime.

Dependency Injection

Dependency Injection is a technique that promotes Inversion of Control (IoC) - an object obtains its dependencies from an external source rather than creating them itself. DI is instrumental in developing code that is more manageable, modular, and testable.

Bridging Strategy Pattern with Dependency Injection

When combined, these two concepts can provide exceptional benefits. Dependency Injection can be used to inject different Strategy objects into a class, thus promoting flexible behavior that varies with the injected strategy.

A Practical Example

Let’s consider a simple example: a TextFormatter class that formats a given text in different ways, such as lower case, upper case, or capitalized. We’ll use a Python-esque pseudo-code for our demonstration.

Firstly, we define the strategy interface and the concrete strategies.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


class TextFormatStrategy:
 def format_text(self, text):
 pass

class LowerCaseStrategy(TextFormatStrategy):
 def format_text(self, text):
 return text.lower()

class UpperCaseStrategy(TextFormatStrategy):
 def format_text(self, text):
 return text.upper()

class CapitalizeStrategy(TextFormatStrategy):
 def format_text(self, text):
 return text.capitalize()

Next, we define the TextFormatter class which will use Dependency Injection to accept a TextFormatStrategy object.

1
2
3
4
5
6


class TextFormatter:
 def __init__(self, strategy: TextFormatStrategy):
 self._strategy = strategy

 def format(self, text):
 return self._strategy.format_text(text)

Now we can change the behavior of the TextFormatter class at runtime by injecting different strategies.

1
2
3
4
5
6
7
8


formatter = TextFormatter(LowerCaseStrategy())
print(formatter.format("Hello World")) # Output: "hello world"

formatter = TextFormatter(UpperCaseStrategy())
print(formatter.format("Hello World")) # Output: "HELLO WORLD"

formatter = TextFormatter(CapitalizeStrategy())
print(formatter.format("hello world")) # Output: "Hello world"

This example demonstrates how Dependency Injection can inject different strategies into a class, resulting in dynamic behavior changes based on the provided strategy.

Cheers! 🍺

--save-dev in npm

Yoonsoo Park — Thu, 18 May 2023 01:25:00 -0400

When working with npm (Node Package Manager) to manage dependencies in a Node.js project, the --save-dev flag is often used to save packages as development dependencies. It is an essential feature that helps distinguish between packages required for development purposes and those needed for the production environment.

What does `--save-dev` do?

By appending --save-dev to an npm install command, you specify that the package being installed is only required during development and should not be included when deploying your application to a production environment. The package will be added to the devDependencies section in your package.json file.

1

npm install <package-name> --save-dev

The devDependencies section typically includes packages related to testing, building, and development tooling, such as test frameworks (e.g., Mocha or Jest), build tools (e.g., Gulp or Webpack), linters (e.g., ESLint or Prettier), and other utilities.

Example use cases for `--save-dev`

Testing frameworks: When writing tests for your application, you often rely on specific testing frameworks like Mocha or Jest. These frameworks are not needed in production but are crucial during development and continuous integration processes. By installing them with --save-dev, you ensure they are available when running tests but won’t unnecessarily bloat your production build.
Build tools: Build tools such as Gulp, Grunt, or Webpack are commonly employed during development to compile and bundle assets, optimize code, or perform other build-related tasks. These tools are not required in a production environment, as the bundled code can be executed without them. Therefore, it’s advisable to save them as development dependencies using --save-dev.
Linters and code formatters: Linters, such as ESLint, and code formatters, like Prettier, assist in maintaining consistent code quality and style. They provide valuable feedback during development but are not necessary for the deployed application. Including them as devDependencies allows developers to use them while working on the codebase, without affecting the production build.

When not to use `--save-dev`

Although --save-dev is useful in many scenarios, there are situations where it should not be employed. One example is when installing packages that are explicitly required at runtime by your application. These packages provide functionality that is essential for the application to run correctly, regardless of the development or production context.

For instance, consider a web server framework like Express. Express is a core dependency for a Node.js web application and is necessary for the application to function correctly. In this case, you should install Express without using --save-dev, as it belongs to the regular dependencies section of your package.json file:

1

npm install express

By installing Express as a regular dependency, it will be bundled and deployed along with your application to ensure proper execution in both development and production environment.

Cheers! 🍺

The Strategy Pattern

Yoonsoo Park — Wed, 17 May 2023 01:25:00 -0400

The ability to modify or extend functionality without impacting the existing codebase is crucial in a rapidly evolving technological landscape. One design pattern that helps achieve this goal is the Strategy Pattern.

Understanding the Strategy Pattern

The Strategy Pattern is a behavioral design pattern that enables the definition of a family of algorithms, encapsulates each one as a separate class, and makes them interchangeable at runtime. It allows the algorithm to vary independently from the clients that use it, promoting loose coupling between objects and providing a way to select algorithms dynamically.

At the heart of the Strategy Pattern are three main components:

Context: This is the class that contains the main business logic and maintains a reference to the chosen strategy object. It provides a method for clients to set the strategy or change it dynamically during runtime.
Strategy: The strategy interface defines a common set of methods that encapsulate different algorithms or behaviors. Each strategy represents a concrete implementation of a particular algorithm.
Concrete Strategies: These are the classes that implement the strategy interface and provide specific implementations of the algorithms or behaviors.

Advantages of the Strategy Pattern

The Strategy Pattern offers several benefits in software design:

Improved Code Reusability By encapsulating algorithms within separate strategy classes, the Strategy Pattern promotes code reuse. Different parts of the system can utilize the same set of strategies, enhancing maintainability and reducing code duplication. This reusability simplifies future modifications or additions to the system.
Enhanced Flexibility and Extensibility The Strategy Pattern allows for easy extension and modification of behaviors. Adding a new strategy involves creating a new class that implements the strategy interface, without needing to modify existing code. This flexibility enables dynamic selection of strategies at runtime, enabling the system to adapt to changing requirements.
Separation of Concerns The Strategy Pattern separates the logic of an algorithm from the context that uses it. This separation promotes cleaner code architecture by assigning responsibilities to appropriate classes. The context class focuses on the main business logic, while the strategies encapsulate specific algorithms. It enhances the overall maintainability and readability of the codebase.
Improved Testability Because the Strategy Pattern encapsulates algorithms within separate classes, it becomes easier to test each strategy independently. By isolating the behavior in smaller, self-contained units, unit testing and mocking become more straightforward, resulting in better test coverage and more robust software.
Runtime Selection of Algorithms One of the key advantages of the Strategy Pattern is the ability to select algorithms dynamically during runtime. The context can change the strategy it uses without affecting the clients or requiring complex conditional logic. This dynamic behavior selection provides a powerful mechanism for adapting the system’s behavior to different scenarios or user preferences.

Example

Let’s consider an example where we want to implement different sorting algorithms for a list of integers using the Strategy Pattern. We’ll have a Sorter class as the context, a SortStrategy interface as the strategy, and multiple concrete strategy classes for different sorting algorithms.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


# Step 1: Define the strategy interface
class SortStrategy:
 def sort(self, data):
 pass

# Step 2: Implement concrete strategy classes
class BubbleSortStrategy(SortStrategy):
 def sort(self, data):
 # Implementation of bubble sort algorithm
 print("Sorting using Bubble Sort")
 # ...

class QuickSortStrategy(SortStrategy):
 def sort(self, data):
 # Implementation of quicksort algorithm
 print("Sorting using Quick Sort")
 # ...

class MergeSortStrategy(SortStrategy):
 def sort(self, data):
 # Implementation of merge sort algorithm
 print("Sorting using Merge Sort")
 # ...

# Step 3: Create the context class
class Sorter:
 def __init__(self, strategy):
 self.strategy = strategy

 def set_strategy(self, strategy):
 self.strategy = strategy

 def sort(self, data):
 self.strategy.sort(data)

# Step 4: Client code
data = [5, 2, 7, 1, 9]

sorter = Sorter(BubbleSortStrategy())
sorter.sort(data) # Sorting using Bubble Sort

sorter.set_strategy(QuickSortStrategy())
sorter.sort(data) # Sorting using Quick Sort

sorter.set_strategy(MergeSortStrategy())
sorter.sort(data) # Sorting using Merge Sort

In the above example, we define the SortStrategy interface that declares the sort() method. We then implement concrete strategy classes such as BubbleSortStrategy, QuickSortStrategy, and MergeSortStrategy, each providing their own implementation of the sort() method.

Next, we create the Sorter class as the context. It has a reference to the SortStrategy interface and provides methods to set the strategy dynamically (set_strategy()) and invoke the sorting operation (sort()).

In the client code, we instantiate a Sorter object and initially set it to use the BubbleSortStrategy. We call the sort() method on the Sorter object, and it delegates the sorting operation to the currently set strategy (BubbleSortStrategy).

We can dynamically change the sorting strategy by calling set_strategy() with a different strategy object (QuickSortStrategy, MergeSortStrategy, etc.). The Sorter object will then use the new strategy for subsequent sorting operations.

Cheers! 🍺

SFDX Deploy Record using CSV

Yoonsoo Park — Tue, 16 May 2023 01:25:00 -0400

Steps to Deploy Records using CSV

Follow these steps to deploy records from a CSV file using SFDX:

Prepare the CSV file: Ensure that your CSV file is properly formatted and contains the necessary data fields required by the target Salesforce object. Each row in the CSV represents a record, and the columns represent field values. Make sure the column headers match the field API names in Salesforce.
Create a Mapping File: To map the column headers in your CSV file to the corresponding Salesforce fields, create a mapping file in JSON format. This file defines the mapping between the CSV column headers and the Salesforce object fields.

Example mapping.json:

1
2
3
4
5


{
 "FirstName": "FirstName__c",
 "LastName": "LastName__c",
 "Email": "Email__c"
}

In this example, the CSV column header "FirstName" maps to the Salesforce custom field "FirstName__c", "LastName" maps to "LastName__c", and so on.

Authenticate with Salesforce: Open your terminal or command prompt and authenticate with your Salesforce org using the Salesforce CLI. Run the following command and follow the prompts:

1

sfdx force:auth:web:login

Navigate to your DX project: Change to the directory where your Salesforce DX project is located using the cd command in your terminal or command prompt.
Deploy the records: Use the sfdx force:data:bulk:upsert command to initiate the record deployment process. Provide the necessary options and arguments:

1

sfdx force:data:bulk:upsert -s ObjectName__c -f path/to/csv/file.csv -i ExternalIdField__c -m path/to/mapping.json

-s: The Salesforce object name where the records will be inserted or updated. -f: The path to the CSV file containing the records. -i: The external ID field used to identify existing records for updates. This field must be unique and match a column in the CSV. -m: The path to the mapping file that defines the field mappings. Replace ObjectName__c, path/to/csv/file.csv, ExternalIdField__c, and path/to/mapping.json with the appropriate values for your deployment.

Monitor the deployment: Once the deployment process begins, you can monitor the progress in your terminal or command prompt. SFDX will display information about the number of records processed, successes, failures, and any error messages encountered during the deployment.
At the last, verify the results: After the deployment completes, you can verify the results by checking your Salesforce org. Ensure that the records have been inserted or updated as expected.

Cheers! 🍺

git diff with Two Tags using simple-git TypeScript

Yoonsoo Park — Mon, 15 May 2023 01:25:00 -0400

Performing Git Diff with simple-git

First, make sure you have the simple-git library imported in your TypeScript file:

1

import simpleGit, { SimpleGit, DiffResult } from "simple-git";

Create a function that will perform the Git diff operation between two tags. The function should accept the tag names as parameters and return a promise that resolves to the diff output string.

1
2
3
4
5
6


async function getGitDiff(tag1: string, tag2: string): Promise<string> {
 const git: SimpleGit = simpleGit();

 const diff: DiffResult = await git.diff([`${tag1}..${tag2}`]);
 return diff.diff;
}

In the above code, we use the simpleGit function from the simple-git library to instantiate a new SimpleGit object. Then, we call the diff method with the tag range specified as ${tag1}..${tag2}. This will retrieve the diff result as a DiffResult object, from which we extract the diff property containing the actual diff output.

Now you can call the getGitDiff function and retrieve the diff output between two tags:

1
2
3
4
5


const tag1: string = "v1.0.0";
const tag2: string = "v1.1.0";

const diff: string = await getGitDiff(tag1, tag2);
console.log(diff);

Use case: clone the repo to local drive then perform git diff

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


import simpleGit, { SimpleGit, DiffResult } from "simple-git";
import * as fs from "fs-extra";

async function gitDiff(
 repositoryUrl: string,
 tag1: string,
 tag2: string
): Promise<void> {
 const git: SimpleGit = simpleGit();

 const tempDir = "./temp-repo";

 // Delete the temporary directory if it exists
 if (fs.existsSync(tempDir)) {
 console.log("tempDir exists, removing it");
 await fs.remove(tempDir);
 }

 // Create a new empty temporary directory
 console.log("creating tempDir");
 await fs.mkdir(tempDir);

 // Clone the repository from the provided URL
 await git.clone(repositoryUrl, "./temp-repo");

 // Change the working directory to the cloned repository
 git.cwd("./temp-repo");

 // Perform the 'git diff' operation
 let diff: string = "";
 try {
 diff = await git.diff([`${tag1}..${tag2}`]);
 console.log("diff", diff);

 // Rest of the code...
 } catch (error) {
 console.error("An error occurred while performing git diff:", error);
 }

 // Remove the temporary repository
 console.log(diff);
 await fs.remove(tempDir);
}

Cheers! 🍺

DTO vs Schema

Yoonsoo Park — Sun, 14 May 2023 01:25:00 -0400

Data Transfer Object (DTO)

A DTO is a plain TypeScript/JavaScript object used for transferring data between different layers or components of an application. Its primary purpose is to encapsulate data and provide a clear structure for communication across system boundaries, such as API calls or database interactions.

Let’s consider an example of a UserDTO in TypeScript:

1
2
3
4
5


interface UserDTO {
id: number;
name: string;
email: string;
}

In this case, the UserDTO interface defines the structure of user data that can be transferred between components or sent over the network. It includes properties like id, name, and email, allowing a consistent and well-defined data representation during communication.

DTOs help decouple different parts of an application by providing a contract for data exchange. They enable type checking and validation when passing data between components, enhancing code reliability and reducing the chances of data-related bugs.

Schema

A schema, on the other hand, describes the structure, constraints, and relationships of data within an application. It serves as a formal definition for expected data shapes and validation rules. Schemas are commonly employed in libraries or frameworks that handle data validation, serialization, or storage.

To illustrate the concept of a schema in TypeScript, we can use a popular library called Yup:

1
2
3
4
5
6
7


import * as yup from 'yup';

const userSchema = yup.object().shape({
 id: yup.number().required(),
 name: yup.string().required(),
 email: yup.string().email().required(),
});

In this example, we create a userSchema using the Yup library. It defines the expected structure and validation rules for user data. The schema specifies that the id, name, and email fields are required, and the email field should be a valid email address.

Schemas provide a powerful mechanism for validating data integrity and enforcing consistency within an application. They allow you to define complex validation rules, perform data transformations, and handle error conditions effectively.

DTO vs Schema

While DTOs and schemas share some similarities, they have distinct purposes within an application.

DTOs focus on transferring data between components or across system boundaries.
- DTOs excel at enabling clear communication and decoupling between different parts of an application. They ensure consistency and type safety when passing data, reducing potential errors and making code more maintainable.
Schemas concentrate on defining and validating the structure of data within an application.
- schemas provide a mechanism for formally defining data structures and applying validation rules. They enhance data integrity, enforce constraints, and facilitate robust data handling throughout an application.

Tomorrow is Monday guys. yike.. Good luck! Cheers! 🍺

Spread Operator in TypeScript

Yoonsoo Park — Fri, 12 May 2023 01:25:00 -0400

Spead Operator provides an elegant syntax for copying or combining elements from existing arrays or objects into new ones.

Array Manipulation

Copying an Array

One of the most common use cases of the spread operator is to create a shallow copy of an array. Let’s consider an example:

1
2


const originalArray = [1, 2, 3];
const copiedArray = [...originalArray];

In this code snippet, the spread operator ... is used to spread the elements of the originalArray into a new array copiedArray. This ensures that modifying the copiedArray does not affect the originalArray, as they are separate instances.

Concatenating Arrays

The spread operator can also be used to concatenate arrays effortlessly. Suppose we have two arrays, array1 and array2, and we want to combine them into a new array combinedArray. We can achieve this using the spread operator:

1
2
3


const array1 = [1, 2, 3];
const array2 = [4, 5, 6];
const combinedArray = [...array1, ...array2];

The resulting combinedArray will contain all the elements from array1 followed by all the elements from array2. This approach is much cleaner and more readable than using traditional methods like Array.concat().

Adding or Removing Elements

Using the spread operator, we can easily add or remove elements from an array. Consider the following example:

1
2


const originalArray = [1, 2, 3];
const newArray = [...originalArray, 4, 5];

In this case, the spread operator is used to spread the elements of the originalArray and append additional elements 4 and 5 to create a new array newArray. Similarly, you can remove elements by excluding them using the spread operator.

Object Manipulation

Copying an Object

Just like with arrays, the spread operator can be used to create a shallow copy of an object. Let’s see an example:

1
2


const originalObject = { name: 'John', age: 30 };
const copiedObject = { ...originalObject };

In this case, the spread operator is used to spread the properties of the originalObject into a new object copiedObject. This ensures that modifying the copiedObject does not affect the originalObject.

Merging Objects

The spread operator can also be used to merge multiple objects into a new object. Suppose we have two objects, object1 and object2, and we want to merge them into a new object mergedObject. We can achieve this using the spread operator:

1
2
3


const object1 = { name: 'John' };
const object2 = { age: 30 };
const mergedObject = { ...object1, ...object2 };

The resulting mergedObject will contain all the properties from object1 and object2. If there are overlapping properties, the value from object2 will overwrite the value from object1.

Modifying Object Properties

The spread operator can also be used to modify specific properties of an object while keeping the rest intact. Consider the following example:

1
2


const originalObject = { name: 'John', age: 30 };
const modifiedObject = { ...originalObject, age: 31 };

In the example above, the spread operator is used to spread the properties of the originalObject into a new object modifiedObject. The age property is also included and assigned a new value of 31. This creates a new object with the same properties as the originalObject, except for the modified property.

By using the spread operator in this way, you can easily modify specific properties of an object without mutating the original object itself. It provides a clean and concise syntax for object manipulation.

Rest Parameters

In addition to array and object manipulation, the spread operator can also be used with function parameters to handle variable-length arguments. This is often referred to as “rest parameters” in TypeScript.

1
2
3
4
5
6


function sum(...numbers: number[]): number {
 return numbers.reduce((acc, curr) => acc + curr, 0);
}

const result = sum(1, 2, 3, 4, 5);
console.log(result); // Output: 15

In this example, the spread operator ... is used in the function parameter declaration ...numbers: number[]. It allows you to pass any number of arguments to the sum function, and TypeScript collects them into an array called numbers. The function then performs the sum operation on all the numbers in the array.

Rest parameters provide flexibility when dealing with functions that need to handle a variable number of arguments. The spread operator simplifies the process of passing and manipulating these arguments.

Cheers! 🍺

Virtual Class and Abstract Class in Apex

Yoonsoo Park — Fri, 12 May 2023 01:25:00 -0400

In the world of Apex programming, two important concepts that developers often encounter are Virtual Classes and Abstract Classes. Both of these class types provide powerful tools for building modular and extensible code, but they serve different purposes and have distinct characteristics. Let’s get it~.

Virtual Classes

A virtual class in Apex is a class that allows its methods to be overridden by subclasses. It provides a way to define a base implementation while also enabling customization and extension by derived classes. In other words, virtual classes serve as a starting point for creating specialized implementations.

To declare a virtual class in Apex, you use the virtual keyword before the class keyword, like this:

1
2
3


virtual class MyBaseClass {
 // Class implementation goes here
}

Methods within a virtual class can be marked as virtual as well. This indicates that the method can be overridden by subclasses to provide their own implementation. For example:

1
2
3
4
5


virtual class MyBaseClass {
 virtual void myMethod() {
 // Base implementation
 }
}

Subclasses of a virtual class can override its methods using the override keyword. This allows them to provide their own custom implementation. For instance:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


virtual class MyBaseClass {
 virtual void myMethod() {
 // Base implementation
 }
}

class MyDerivedClass extends MyBaseClass {
 override void myMethod() {
 // Custom implementation
 }
}

By using virtual classes, developers can create a hierarchy of classes where each class adds or modifies the behavior of the base class, enabling flexibility and customization.

Abstract Classes

An abstract class in Apex, on the other hand, is a class that cannot be instantiated directly. It serves as a blueprint or contract for derived classes, defining common methods and properties that subclasses must implement. Abstract classes allow developers to establish a common interface while leaving the specifics of implementation to the derived classes.

To declare an abstract class in Apex, you use the abstract keyword before the class keyword, like this:

1
2
3


abstract class MyAbstractClass {
 // Class implementation goes here
}

Abstract classes can contain abstract methods, which are declared without an implementation. These methods act as placeholders that must be implemented by any non-abstract subclass. For example:

1
2
3


abstract class MyAbstractClass {
 abstract void myMethod();
}

Any class that extends an abstract class must provide an implementation for all abstract methods defined in the abstract class. Failure to do so will result in a compilation error.

1
2
3
4
5
6
7
8
9


abstract class MyAbstractClass {
 abstract void myMethod();
}

class MyConcreteClass extends MyAbstractClass {
 void myMethod() {
 // Implementation of abstract method
 }
}

Abstract classes are useful when you want to define a common set of methods and properties for a group of related classes, ensuring consistent behavior across different implementations.

Wrap this up!

Virtual classes allow for method overriding, enabling customization and extension of base implementations.
Abstract classes establish a contract for derived classes, ensuring the implementation of required methods.

Cheers! 🍺

Retrieve Flow metadata from the sratch org Salesforce

Yoonsoo Park — Thu, 11 May 2023 01:25:00 -0400

When working with Salesforce Scratch Orgs, it’s crucial to be able to retrieve specific metadata components for further development or deployment. One common requirement is finding the metadata for Flows within your Scratch Org. In this article, we will explore how to achieve this using the SFDX and the force:source:retrieve command.

Prerequisites

Before we dive into the solution, make sure you have the following set up:

SFDX installed on your local machine
A Salesforce DX project connected to your Dev Hub org
A Scratch Org with the Flows you want to retrieve

Retrieving Flow Metadata

To retrieve the metadata for Flows from your Scratch Org, open a terminal or command prompt and navigate to the root directory of your Salesforce DX project. Then, execute the following command:

1

sfdx force:source:retrieve -m Flow:<flowApiName>

Replace <flowApiName> with the API name of the specific Flow you want to retrieve. If you want to retrieve multiple Flows, you can specify multiple Flow API names, separated by a comma.

For example, let’s say you have a Flow with an API name of "MyFlow". To retrieve its metadata, you would run the following command:

1

sfdx force:source:retrieve -m Flow:MyFlow

This command tells the SFDX to retrieve the metadata for the specified Flow(s). The retrieved metadata will be stored in the "force-app" directory of your Salesforce DX project.

Example

Let’s consider a practical example where we have a Scratch Org containing two Flows: "AccountFlow" and "OpportunityFlow". To retrieve the metadata for both Flows, we would execute the following command:

1

sfdx force:source:retrieve -m Flow:AccountFlow,Flow:OpportunityFlow

The SFDX will retrieve the metadata for these two Flows and store them in the "force-app" directory of your Salesforce DX project.

Cheers! 🍺

Log Out (Unlink) the Scratch Org from the Project in Salesforce using SFDX

Yoonsoo Park — Wed, 10 May 2023 01:25:00 -0400

Once the work in the Scratch Org is completed, it is essential to log out (unlink) the Scratch Org from the project. This ensures that you can easily create and authorize new Scratch Orgs without any conflicts. In this article, we will discuss how to log out a Scratch Org from the project using the Salesforce CLI and the force:auth:logout command.

Prerequisites

Before proceeding, make sure that you have the following:

Salesforce CLI installed on your local machine
A Salesforce DX project connected to your Dev Hub org
At least one Scratch Org created and authorized for the project

Logging Out (Unlinking) a Scratch Org from the Project

To log out a Scratch Org from the project, open a terminal or command prompt and navigate to the root directory of your Salesforce DX project. Then, run the following command:

sfdx force:auth:logout -u <Scratch Org Username>

This command uses the force:auth:logout command to log out (unlink) the specified Scratch Org from the project. Here’s what the parameter does:

-u: Specifies the username of the Scratch Org you want to log out For example, if you have a Scratch Org with the username test-scratch-org, you would run the following command:

sfdx force:auth:logout -u test-scratch-org

This will log out the specified Scratch Org from the project. You can verify that the Scratch Org is no longer linked to the project by running the sfdx force:org:list command.

Cheers! 🍺

sfdx force:org:display to get the scratch org information Salesforce

Yoonsoo Park — Tue, 09 May 2023 01:25:00 -0400

When working with Scratch Orgs, it is important to be able to retrieve information about the org, such as its username, expiration date, and edition. This article will show you how to retrieve this information using the SFDX CLI and the force:org:display command.

Prerequisites

Before proceeding, make sure that you have the following:

Salesforce CLI installed on your local machine
A Salesforce DX project connected to your Dev Hub org
At least one Scratch Org created and authorized for the project

Retrieving Scratch Org Information

To retrieve information about a Scratch Org, open a terminal or command prompt and navigate to the root directory of your Salesforce DX project. Then, run the following command:

1

sfdx force:org:display --json

This will output a JSON object containing information about the Scratch Org and the output looks something like this:

1
2
3
4
5
6
7
8
9


{
 id: '00DDa000000TZDFGCCG',
 accessToken: '00DDa000000TZng!ASDFC1sdfa3.1oAwna2JkTGFazCfxa9sJc6xWh5m37KpAcvdxxdaU0I2u5PdfEDfBBOKyJJj',
 instanceUrl: 'https://rookie-force-9991-dev-ed.scratch.my.salesforce.com',
 username: 'test-winkddbear@example.com',
 clientId: 'PremiumCLI',
 connectedStatus: 'Connected',
 alias: 'my-org-alias'
}

Cheers! 🍺

Understanding Class Diagrams and UML arrows

Yoonsoo Park — Mon, 08 May 2023 01:25:00 -0400

Class diagrams (a type of UML diagram) are a key tool used in object-oriented programming to visualize the relationships between classes. These diagrams help developers to understand the structure of their code and how different classes interact with one another. One important aspect of class diagrams is the use of UML arrows to show relationships between classes.

Types of UML Arrows in Class Diagrams

There are several types of arrows that can be used in class diagrams to show different types of relationships between classes. Here are some of the most common ones:

Association Arrows Association arrows are used to show that two classes are associated with one another in some way. For example, a Student class might be associated with a Course class if the student is enrolled in that course. Association arrows are typically drawn as a straight line with an arrowhead pointing from one class to another.

 +-----------+ +-----------+
| Course | -------->| Student |
+-----------+ +-----------+

In this example, the Course class is associated with the Student class, indicating that a student can enroll in one or more courses.

Aggregation Arrows Aggregation arrows are used to show that one class is a part of another class. For example, a Car class might have an aggregation relationship with a Wheel class, indicating that a car is made up of one or more wheels. Aggregation arrows are typically drawn as a straight line with an arrowhead pointing from the part class to the whole class, and a diamond shape on the whole class side.

 +-----------+ +-----------+
| Car | | Wheel |
+-----------+ +-----------+
◇ ◇
| |
+-------+ +-------+
| Wheel | | Wheel |
+-------+ +-------+

In this example, the Car class has an aggregation relationship with the Wheel class, indicating that a car is made up of one or more wheels.

Composition Arrows Composition arrows are similar to aggregation arrows, but they indicate a stronger relationship between classes. In a composition relationship, the part class is completely contained within the whole class, and cannot exist independently. For example, a House class might have a composition relationship with a Room class, indicating that a room cannot exist outside of a house. Composition arrows are typically drawn with a filled diamond shape on the whole class side.

 +-----------+ +-----------+
| House | | Room |
+-----------+ +-----------+
◆ ◆
| |
+-------+ +-------+
| Room | | Room |
+-------+ +-------+

In this example, the House class has a composition relationship with the Room class, indicating that a room cannot exist outside of a house.

Inheritance Arrows Inheritance arrows are used to show that one class inherits properties and methods from another class. For example, a Dog class might inherit from an Animal class, indicating that a dog is a type of animal. Inheritance arrows are typically drawn as a straight line with an arrowhead pointing from the subclass to the superclass, and a solid triangle on the superclass side.

 +-----------+ +-----------+
| Animal |◁--------| Dog |
+-----------+ +-----------+

In this example, the Dog class inherits from the Animal class, indicating that a dog is a type of animal.

NOW Challenge! Draw Dependency Injection!!

 +----------------------+ +-----------------+
| Service Interfeace |<------------------ | Service Impl |
+----------------------+ implements +-----------------+
^ |
| depends on |
| |
+----------------------+ is provided |
| Component |<-----------------------------
+----------------------+

In this diagram, Component depends on the ServiceInterface. ServiceImpl implements the ServiceInterface, and an instance of ServiceImpl is provided to Component. This is an example of dependency injection, where Component does not create an instance of ServiceImpl itself, but rather receives it from an external source (e.g., a dependency injection framework or a constructor parameter).

Cheers! 🍺

Running Apex CLS File on CLI

Yoonsoo Park — Sun, 07 May 2023 01:25:00 -0400

In this article, we will explore how to run an Apex CLS file on the Command Line Interface (CLI) using a TypeScript code snippet. This code snippet will allow you to execute Apex classes in a specified folder, and return the results to the CLI.

Create a new TypeScript file named apexExecution.ts in your preferred code editor. Copy and paste the following code snippet into the file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


import { exec } from 'child_process';
import * as fs from 'fs';

export class ApexExecution {
 async execute(configApexClassPath: string[]): Promise<string> {
 const classListPath = Array.isArray(configApexClassPath)
 ? configApexClassPath
 : [configApexClassPath];
 const results = [];
 console.log('\n📞 Executing apex classes...\n');
 for (const apexClassPath of classListPath) {
 //check files under recordDefinitionsPath
 const classes = fs.readdirSync(apexClassPath);
 if (classes.length === 0) {
 console.log(`No apex classes found in ${apexClassPath}`);
 continue;
 }
 for (const apexClass of classes) {
 console.log(`📞 Executing apex class ${apexClass}`);
 const command = `sfdx force:apex:execute -f ${apexClassPath + apexClass}`;
 const result = await new Promise((resolve, reject) => {
 exec(command, (err, stdout, stderr) => {
 if (err) {
 console.log(
 `❌ Error occurred while executing Apex class... ${apexClass}: ${stderr}\n`
 );
 reject(err);
 } else {
 console.log(`✅ Apex execution successful\n`);
 resolve(stdout);
 }
 });
 });
 results.push(result);
 }
 }
 return results.join('\n');
 }
}

Understanding the Code

The code snippet above defines a TypeScript class named ApexExecution. This class has a single method named execute, which accepts an array of strings as its parameter. This array represents the paths to the Apex classes that you want to execute.

The execute method uses the fs module to read the contents of each folder specified in the configApexClassPath parameter. It then loops through each Apex class in the folder and executes it using the Salesforce CLI’s force:apex:execute command.

If the execution of the Apex class is successful, the method will log a success message to the CLI and return the output generated by the command. If an error occurs, the method will log an error message to the CLI and reject the Promise.

Cheers! 🍺

Partially Applied Types with Type Currying TypeScript

Yoonsoo Park — Sat, 06 May 2023 01:25:00 -0400

Type Currying is a technique used in functional programming that allows us to transform a function with multiple arguments into a series of functions that take a single argument. This makes the functions more flexible and easier to compose.

Partially Applied Types is another powerful technique that can be used in conjunction with Type Currying to further enhance the flexibility and composability of functions. In this article, we will explore these concepts and their applications in functional programming.

Type Currying

Type Currying is named after Haskell Curry, a mathematician who introduced the concept of currying in the 20th century. The idea behind Type Currying is simple: transform a function that takes multiple arguments into a series of functions that each take a single argument.

For example, let’s say we have a function add that takes two integers and returns their sum:

1
2
3


function add(x, y) {
 return x + y;
}

We can transform this function into a series of functions that each take a single argument:

1
2
3
4
5


function add(x) {
 return function(y) {
 return x + y;
 }
}

This new function add takes a single argument x and returns another function that takes a single argument y and returns their sum. We can use this function like this:

1
2


const add5 = add(5); // returns a new function that adds 5 to its argument
const result = add5(3); // returns 8

This technique can be used to create new functions from existing ones by partially applying some of the arguments.

Partially Applied Types

Partially Applied Types is a technique that extends Type Currying to support partially applying type parameters. In other words, it allows us to create new types by partially applying some of the type parameters of an existing type.

For example, let’s say we have a generic type Result<T, E> that represents the result of an operation that can either succeed with a value of type T or fail with an error of type E:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


type Result<T, E> = Success<T> | Failure<E>;

interface Success<T> {
 kind: 'success';
 value: T;
}

interface Failure<E> {
 kind: 'failure';
 error: E;
}

We can use this type to represent the result of any operation that can fail, such as a network request that can either return data or an error.

Now, let’s say we have a specific use case where we only care about the successful case and we don’t need to handle errors. We can create a new type SuccessResult<T> by partially applying the Result type:

1
2
3
4


type SuccessResult<T> = Result<T, never>;

// Usage:
const result: SuccessResult<number> = { kind: 'success', value: 42 };

In this new type, we have partially applied the second type parameter E with the never type, which means we don’t care about the error case. This new type can be used in place of the original Result type wherever we only care about the successful case.

Cheers! 🍺

Manage environment variables in TypeScript

Yoonsoo Park — Fri, 05 May 2023 01:25:00 -0400

In a typical web application, you might have sensitive information like database credentials, API keys, and other configuration data that you don’t want to hardcode into your codebase. Instead, you can use environment variables to keep this data separate and secure. In this article, we’ll discuss how to use the dotenv library to manage environment variables in TypeScript.

What is dotenv?

dotenv is a popular library that loads environment variables from a .env file into process.env, making it easy to access them in your code. With dotenv, you can keep your sensitive information separate from your codebase, making it easier to manage and secure.

Installation

To get started with dotenv, you need to install it as a dependency in your project.

1

npm install dotenv

Usage

Once you have installed dotenv, you need to create a .env file in the root of your project. This file should contain your environment variables in the KEY=VALUE format, with each variable on a new line. For example:

1
2


DATABASE_URL=mongodb://localhost:27017/mydb
API_KEY=abc123

In your TypeScript code, you can now access these environment variables using process.env. For example:

1
2
3
4
5


import * as dotenv from 'dotenv';
dotenv.config();

const dbUrl = process.env.DATABASE_URL;
const apiKey = process.env.API_KEY;

Note that you need to call dotenv.config() to load the variables from the .env file into process.env. You can call this function at the beginning of your application or whenever you need to load new variables.

Happy Friday, cheers! 🍺

What is a Record with Self-Referencing in Salesforce and Why Do We Need It?

Yoonsoo Park — Thu, 04 May 2023 01:25:00 -0400

A self-referencing field is a field on an object that refers to another record of the same object. In other words, a record can reference another record of the same type. This is useful in a number of scenarios, including hierarchical relationships, parent-child relationships, and lookup relationships.

Why Do We Need Record with Self-Referencing in Salesforce?

One of the primary use cases for self-referencing records in Salesforce is for managing hierarchical data. For example, an organization might use self-referencing records to manage a tree structure of departments or teams. Each department or team can have a parent department or team, and this relationship can be easily modeled using self-referencing fields.
Another use case for self-referencing records is for managing parent-child relationships. For example, a company might use self-referencing records to manage a list of accounts, where each account can have a parent account. This relationship can be modeled using a self-referencing field on the Account object.
Finally, self-referencing records can be useful for managing lookup relationships between records of the same object type. For example, a company might use self-referencing records to manage a list of products, where each product can be associated with another product as a substitute or alternative.

Example of Record with Self-Referencing in Salesforce

Let’s say that you are working for a company that sells software products. You have been tasked with setting up a new product catalog in Salesforce, and you want to be able to manage relationships between products. You decide to use self-referencing records to model these relationships.

You create a new custom object called “Product,” and you add a new self-referencing field called “Related Product.” This field allows you to associate a product with another product as a substitute or alternative.

You then create a new record for your flagship product, “Awesome Software 2.0.” In the “Related Product” field, you associate it with your previous version, “Awesome Software 1.0.” This allows your sales team to easily suggest the newer version as an alternative when selling to existing customers.

You also create a new record for a complementary product, “Awesome Add-On.” In the “Related Product” field, you associate it with “Awesome Software 2.0.” This allows your sales team to easily suggest the add-on when selling the main product.

How to Create a Record with Self-Referencing in Salesforce

Creating a record with self-referencing fields in Salesforce is a straightforward process. Here’s a step-by-step guide:

Navigate to Setup by clicking on the gear icon in the top right corner of the screen.
In the left-hand menu, select “Object Manager.”
Select the object for which you want to create a self-referencing field.
Click on the “Fields & Relationships” tab.
Click the “New” button to create a new field.
Select the “Lookup Relationship” field type.
Choose the same object as the related object.
Give your field a name, such as “Related Product” in our example above.
Click “Next.”
Choose the page layouts where you want the field to appear.
Click “Save.”

Now you can start creating records with self-referencing fields. When you create a new record, you’ll see the self-referencing field on the page layout. You can use this field to associate the record with another record of the same object type.

Cheers! 🍺

Why Apex Test Cannot Find Enum Defined in Apex Class

Yoonsoo Park — Wed, 03 May 2023 01:25:00 -0400

there is a common issue that developers face when working with enums in Apex. Sometimes, when you try to reference an enum defined in an Apex class from your test class, you may get an error that the enum is not found. This can be a frustrating issue to deal with, especially if you are new to Apex development.

The reason for this issue is that when you create an instance of the Apex class with exactly the same name as the class name, but with a different case, Apex does not recognize it as a class. Instead, it sees it as an instance of the class. This means that when you try to reference the enum from your test class, Apex cannot find it because it is not defined on the instance.

To avoid this issue, it is important to always create your instance name differently than the class name. This will ensure that Apex recognizes it as a separate instance and not as the class itself. For example, if your class is named “MyClass”, you could create an instance named “myInstance” or “myClassInstance”.

Let’s take a look at an example to illustrate this issue:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public class MyClass {
 public enum MyEnum {
 VALUE_1, VALUE_2, VALUE_3
 }
}

public class MyTestClass {
 public static void testEnum() {
 MyClass myClass = new MyClass();
 // This line will throw an error because Apex cannot find the enum
 MyClass.MyEnum value = MyClass.MyEnum.VALUE_1;
 }
}

In the above example, the testEnum() method in the MyTestClass class tries to reference the MyEnum enum defined in the MyClass class. However, because the instance of MyClass is named myClass (with a lowercase “m”), Apex does not recognize it as the class itself. Therefore, when we try to reference MyClass.MyEnum, Apex cannot find it and throws an error.

To fix this issue, we can simply rename the instance of MyClass to something different than the class name:

1
2
3
4
5
6
7


public class MyTestClass {
 public static void testEnum() {
 MyClass myClassInstance = new MyClass();
 // This line will work correctly
 MyClass.MyEnum value = MyClass.MyEnum.VALUE_1;
 }
}

By creating an instance named myClassInstance instead of myClass, Apex now recognizes it as a separate instance and not as the class itself. Therefore, when we reference MyClass.MyEnum, Apex can find it and our code will work correctly.

Cheers! 🍺

Shell vs Bash vs Zsh vs Terminal

Yoonsoo Park — Tue, 02 May 2023 01:25:00 -0400

Are you confused by the terms “shell,” “Bash,” “Zsh,” and “terminal”? Don’t worry, you’re not alone! These terms are often used interchangeably, leading to much confusion among developers. In this article, we’ll take a humorous look at these terms and try to clear up some of the confusion.

What is a Shell?

Let’s start with the basics: what is a shell? A shell is a program that provides a command-line interface for interacting with the operating system. Think of it as the bridge between you and the computer. It’s the tool you use to type in commands and execute them.

Bash vs. Zsh: What’s the Difference?

Now, let’s talk about Bash and Zsh. These are both Unix shells, but they have some differences. Bash (short for Bourne-Again SHell) is the default shell on many Unix-based operating systems. It’s been around since the 1980s and is widely used. Zsh (short for Z Shell) is another Unix shell that is gaining popularity in recent years. It has some features that Bash doesn’t, such as improved tab completion and syntax highlighting.

Terminal: It’s Not What You Think

Finally, let’s talk about the terminal. This is the program you use to interact with the shell. It provides a window or interface where you can type in commands and see the output. However, some people use the term “terminal” to refer to the shell itself. This can lead to confusion, as the terminal and the shell are not the same thing.

So, What’s the Verdict?

To sum up, a shell is a program that provides a command-line interface for interacting with the operating system. Bash and Zsh are both Unix shells, with some differences in features. The terminal is the program you use to interact with the shell, not the shell itself.

Cheers! 🍺

Get Access Token from Salesforce

Yoonsoo Park — Mon, 01 May 2023 01:25:00 -0400

Access tokens are unique strings of characters that authenticate a user’s identity and provide secure access to Salesforce APIs. In this article, we will discuss how to obtain an access token using SFDX CLI.

Steps to Get Access Token

Authorize an org: To use SFDX CLI to get an access token, you first need to authorize an org. Use the following command to authorize an org:

1

sfdx force:auth:web:login -a <org_alias>

This command will open a web browser window, where you will be prompted to log in to your Salesforce account. Once you have logged in, your org is authorized, and you can use it to get an access token.

Get Access Token: To get an access token for the authorized org, use the following command:

1

sfdx force:org:display -u <org_alias> --verbose | grep "Access Token" | awk '{print $NF}'

This command will display the access token for the authorized org.

Cheers! 🍺

How to Switch Scratch Orgs for a VS Code Project Using CLI

Yoonsoo Park — Sun, 30 Apr 2023 01:25:00 -0400

Authorize your new Scratch Org with the CLI by running the following command:

1

sfdx force:auth:web:login -r https://test.salesforce.com -a <alias>

Replace with the alias for your new Scratch Org. This will create an OAuth authorization for your new Scratch Org and set it as the default org for the CLI.

Update your project’s configuration file to use the new Scratch Org by running the following command:

1

sfdx force:config:set defaultusername=<alias>

Verify that your project is now using the new Scratch Org by checking the org details in the bottom-right corner of the VS Code window.

Cheers! 🍺

Better Validations with includes and Selector Function in TypeScript

Yoonsoo Park — Sat, 29 Apr 2023 01:25:00 -0400

As a developer, ensuring that your code is robust and free from errors is crucial. One way to achieve this is through proper validation of data inputs. TypeScript provides many tools for type checking and validation, and in this article, we will explore how to use the includes method and selector function for better validations.

The `includes` Method

The includes method is a built-in JavaScript method that checks if an array or string includes a specific value. In TypeScript, we can use includes to validate data inputs against a set of allowed values.

For example, let’s say we have a function that takes in a string parameter and needs to validate that it is either “foo” or “bar”. We can use includes to achieve this:

1
2
3
4


function validateInput(input: string): boolean {
 const allowedValues = ["foo", "bar"];
 return allowedValues.includes(input);
}

In this example, we have an array allowedValues that contains the allowed values. We then use includes to check if the input parameter is included in the array. The function returns true if the input is valid and false if it is not.

The Selector Function

The selector function is a TypeScript feature that allows us to define a function that selects a specific property from an object. This can be useful when validating complex data structures.

Let’s say we have an interface Person that represents a person’s information:

1
2
3
4
5


interface Person {
 name: string;
 age: number;
 email: string;
}

Now let’s say we have an array of Person objects and we want to validate that all of the email properties are valid email addresses. We can use a selector function to achieve this:

1
2
3
4
5
6
7
8


function validateEmails(people: Person[]): boolean {
 function getEmail(person: Person): string {
 return person.email;
 }

 const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
 return people.every((person) => emailRegex.test(getEmail(person)));
}

In this example, we have a getEmail function that takes in a Person object and returns the email property. We then use every to check that every Person object in the array has a valid email address.

Cheers! 🍺

How to Fix This Schedulable Class Has Jobs Pending or In Progress Error

Yoonsoo Park — Fri, 28 Apr 2023 01:25:00 -0400

When working with Salesforce, you may encounter an error message that says “This schedulable class has jobs pending or in progress” when trying to push code to a Scratch Org. This error message can be frustrating and may cause delays in your development process.

The Solution

To prevent the “This schedulable class has jobs pending or in progress” error message from occurring, you need to navigate to your Deployment Settings and enable the “Allow deployments of components when corresponding Apex jobs are pending or in progress” option.

Here are the steps you can follow:

Log in to your Salesforce org.
Navigate to the Setup page.
In the Quick Find box, search for “Deployment Settings”.
Click on the “Deployment Settings” link to open the Deployment Settings page.
Scroll down to the “Deployment Options” section and locate the “Allow deployments of components when corresponding Apex jobs are pending or in progress” option.
Click the checkbox next to the option to enable it.
Save your changes by clicking the “Save” button.

By enabling this option, you are allowing the deployment of components, even when corresponding Apex jobs are pending or in progress. This means that you can push your code to a Scratch Org without encountering the “This schedulable class has jobs pending or in progress” error message.

Cheers! 🍺

Level Up Your JavaScript Skills with Lodash

Yoonsoo Park — Thu, 27 Apr 2023 01:25:00 -0400

Lodash

Lodash is a powerful utility library that provides a ton of helpful functions for working with arrays, objects, strings, and more.

You can import the entire library like this:

1

import _ from "lodash";

One of the main benefits of Lodash is that it can help you write cleaner, more concise code. Let’s take a look at a quick example.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// Without Lodash
const numbers = [1, 2, 3, 4, 5];
let sum = 0;
for (let i = 0; i < numbers.length; i++) {
 sum += numbers[i];
}
console.log(sum); // Output: 15

// With Lodash
const sum = _.sum([1, 2, 3, 4, 5]);
console.log(sum); // Output: 15

In this example, we’re calculating the sum of an array of numbers. Without Lodash, we need to use a for loop to iterate over the array and add up each value. With Lodash, we can use the sum function, which takes an array as its argument and returns the sum of all the values in the array. This saves us several lines of code and makes the logic much easier to read.

But that’s just the tip of the iceberg when it comes to Lodash. Here are some other handy functions you can use:

map

map creates a new array with the results of calling a provided function on every element in the original array.

1
2
3
4
5
6
7


const numbers = [1, 2, 3, 4, 5];
const doubledNumbers = _.map(numbers, (num) => num * 2);
console.log(doubledNumbers); // Output: [2, 4, 6, 8, 10]

const names = ["Alice", "Bob", "Charlie"];
const nameLengths = _.map(names, (name) => name.length);
console.log(nameLengths); // Output: [5, 3, 7]

filter

filter creates a new array with all elements that pass the test implemented by the provided function.

1
2
3
4
5
6
7


const numbers = [1, 2, 3, 4, 5];
const evenNumbers = _.filter(numbers, (num) => num % 2 === 0);
console.log(evenNumbers); // Output: [2, 4]

const names = ["Alice", "Bob", "Charlie"];
const longNames = _.filter(names, (name) => name.length > 5);
console.log(longNames); // Output: ["Charlie"]

find

find returns the first element in an array that satisfies a provided testing function.

1
2
3
4
5
6
7


const numbers = [1, 2, 3, 4, 5];
const firstEvenNumber = _.find(numbers, (num) => num % 2 === 0);
console.log(firstEvenNumber); // Output: 2

const names = ["Alice", "Bob", "Charlie"];
const longName = _.find(names, (name) => name.length > 5);
console.log(longName); // Output: "Charlie"

orderBy

orderBy sorts an array by one or more properties.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


const users = [
 { name: "Alice", age: 30 },
 { name: "Bob", age: 25 },
 { name: "Charlie", age: 35 },
];
const sortedUsers = _.orderBy(users, ["age", "name"], ["asc", "desc"]);
console.log(sortedUsers);
/*
Output: [
 { name: "Bob", age: 25 },
 { name: "Alice", age: 30 },
 { name: "Charlie", age: 35 }
]
*/

Cheers! 🍺

Resolve a Conflict with Other Devs at Work

Yoonsoo Park — Wed, 26 Apr 2023 01:25:00 -0400

So, you’ve found yourself in a bit of a pickle with another developer at work. Maybe they disagree with your coding style, or they think your approach to a project is all wrong. Whatever the reason, you’re not seeing eye-to-eye and it’s starting to affect your working relationship. Here is my two cents.

Step 1: Take a Deep Breath

First things first, take a deep breath and remember that you’re both on the same team. It’s not you against them, it’s both of you working towards the same goal. This conflict is just a bump in the road and it will pass. So, relax and try to approach the situation with an open mind.

Step 2: Listen

Now that you’re feeling a bit more zen, it’s time to hear them out. Really listen to what they have to say and try to understand where they’re coming from. Maybe they have some valid points that you haven’t considered. Or maybe they just need to vent a little. Either way, let them have their say and don’t interrupt.

Step 3: State Your Case

Once they’ve had their turn, it’s time for you to state your case. Explain why you’ve made the decisions you have and why you think they’re the right ones. Be prepared to provide evidence to back up your claims. This isn’t a courtroom, but it doesn’t hurt to have some facts on your side.

Step 4: Compromise

Now that you’ve both had your say, it’s time to find some common ground. Is there a way to combine your ideas? Can you meet in the middle somewhere? Maybe you can agree to try things their way for a little while and see how it goes. The important thing is to find a solution that works for both of you.

Step 5: Fist Bump

Congratulations! You’ve successfully resolved a conflict with another dev. Now it’s time to seal the deal with a handshake (or a fist bump if that’s more your style). Remember, you’re both on the same team and you’re both working towards the same goal. So, put this conflict behind you and get back to coding like the superstars you are.

I believe, avoiding conflicts is not always the best approach, but neither is facing them in a destructive way. It’s important to find a balance and approach conflicts with an open mind, a willingness to listen and understand, and a commitment to finding a mutually beneficial solution.

Cheers! 🍺

Checking If an SObject Exists in a Salesforce Scratch Org

Yoonsoo Park — Tue, 25 Apr 2023 01:25:00 -0400

Checking If an SObject Exists in a Salesforce Scratch Org

To check if an SObject exists in a Salesforce scratch org, we can use the sfdx force:schema:sobject:list command. This command lists all the SObjects in the scratch org, along with their API names.

1

sfdx force:schema:sobject:list -c DeveloperName -u MyScratchOrg

In this command, -c DeveloperName specifies that the output should display the DeveloperName field of each SObject. -u MyScratchOrg specifies that the command should be executed on the MyScratchOrg scratch org.

The output of this command will be a list of all the SObjects in the scratch org, along with their API names. You can use this list to determine if a specific SObject exists in the scratch org.

Checking for SObject Metadata Programmatically

If you want to check if an SObject exists programmatically, you can use the Salesforce API or the sfdx CLI. Here’s an example of how to use the sfdx CLI to check for SObject metadata:

1

sfdx force:schema:sobject:describe --json -s MyCustomObject__c

In this command, MyCustomObject__c is the name of the custom object that you want to check for. The --json flag specifies that the output should be in JSON format.

If the object exists, the command will return a JSON string that contains the metadata for the object. If the object doesn’t exist, the command will return an error message.

Cheers! 🍺

Streamline Your TypeScript Projects with Advanced Path Mapping Techniques

Yoonsoo Park — Mon, 24 Apr 2023 01:25:00 -0400

If you’re a TypeScript developer, you may have encountered the “Cannot find module” error when importing a module from a relative or absolute path. This can be frustrating, especially when dealing with a large codebase.

Path Mapping

In TypeScript, Path Mapping is a feature that allows you to specify aliases for module paths. This can be helpful when working with a large codebase with multiple directories and files. Path Mapping helps to simplify the importation process by allowing you to use a custom alias instead of a relative or absolute path.

For example, instead of using:

1

import { someModule } from "../../path/to/module";

You can use:

1

import { someModule } from "@customAlias/module";

Setting up Path Mapping

To use Path Mapping in TypeScript, you need to add a “paths” property in your tsconfig.json file. Here’s an example:

1
2
3
4
5
6
7
8
9


{
 "compilerOptions": {
 "baseUrl": "./src",
 "paths": {
 "@customAlias/*": ["app/*"],
 "@anotherAlias/*": ["../another-dir/*"]
 }
 }
}

In this example, we’ve added two Path Mapping aliases: “@customAlias” and “@anotherAlias”. The first alias maps to the “app” directory inside the “src” directory, and the second alias maps to the “another-dir” directory that’s located one level up from the current directory.

Once you’ve set up your Path Mapping aliases, you can use them in your import statements like this:

1
2


import { someModule } from "@customAlias/module";
import { anotherModule } from "@anotherAlias/module";

And that’s it! You’ve successfully set up Path Mapping in TypeScript and can now “Se3y” your imports.

Cheers! 🍺

The Imposter, Not Imposter Syndrome in Software Developers

Yoonsoo Park — Sun, 23 Apr 2023 01:25:00 -0400

While imposter syndrome is a legitimate issue that affects many people, there is another type of imposter in the software development world that doesn’t get talked about enough: the actual imposter.

Yes, you read that right. There are people out there who claim to be software developers, but in reality, they don’t know the first thing about programming. They’re the ones who somehow managed to convince someone to give them a job, and now they’re struggling to keep up with the rest of the team, or worse, they’re holding the team back.

You might think that these people would be easy to spot, but that’s not always the case. Some of them are great at faking it until they make it, while others are just really good at hiding their lack of knowledge.

The Signs of an Imposter

So, how can you tell if someone is an imposter? Here are a few signs to watch out for:

They’re always asking for help: While it’s normal for developers to ask for help from time to time, an imposter will constantly need assistance with even the most basic tasks. They may also struggle to explain what they’re working on or how they plan to fix an issue.
They don’t know basic coding concepts: An imposter may not understand the difference between a function and a method or have trouble understanding the fundamentals of object-oriented programming.
They’re always behind schedule: Because they don’t know what they’re doing, an imposter will often take much longer to complete tasks than the rest of the team.
They make excuses: When an imposter is caught not knowing something, they may try to deflect by blaming someone else or making excuses for why they don’t know something.
An impostor may not be engaged in actual development tasks, instead they could be occupying themselves with activities such as assuming the role of a Product Manager or carrying out tasks that are entirely unrelated to development, for instance, creating documentation.
The worst part is, they don’t know they’re an imposter: An imposter may not realize that they don’t know what they’re doing. They may think they’re doing a good job, but in reality, they’re just getting by.

How to Deal with an Imposter

I suggest two ways to deal with imposters:

Be honest: If you suspect that someone is an imposter, be honest with them. Tell them that you think they’re struggling and that you’re willing to help them learn. If they’re willing to learn, great! If not, you may need to consider other options. which leads me to my next point…
Don’t be afraid to remove them: In the event that the imposter is impeding your productivity or hindering progress, it might be necessary to release them from the team. Though terminating an employee is not a preferred course of action, it is more beneficial than allowing them to become an obstacle to the team’s success.

If you are the imposter, I hope you will take this as a wake-up call. You may be able to fake it for a while, but eventually, you will be found out. If you want to be a software developer, you need to learn how to code. If you don’t know how to code, you need to learn how to code. If you don’t want to learn how to code, you need to find a different job.

I am taking my job very seriously, and I expect you to do the same. If you want to be a REAL software developer, you need to EARN IT, don’t fake it.

Cheers! 🍺

Named vs. Default Imports in TypeScript

Yoonsoo Park — Sat, 22 Apr 2023 01:25:00 -0400

Named vs. Default Imports in TypeScript

TypeScript provides two different ways to import functionality from a module: named imports and default imports. While both types of imports allow you to use code from other modules in your application, they have some key differences in terms of syntax and behavior.

Named Imports

A named import allows you to selectively import specific functionality from a module using a named identifier. You can import multiple named exports from a module by separating them with commas inside a set of curly braces {}.

1
2
3
4
5


// Import a single named export
import { sum } from "./math";

// Use the imported function
console.log(sum(2, 3)); // Output: 5

Default Imports

A default import allows you to import a single default export from a module using any identifier you choose. You can only have one default export per module.

1
2
3
4
5


// Import the default export
import math from "./math";

// Use the imported function
console.log(math.sum(2, 3)); // Output: 5

In this example, we use a default import to import the default export from the math module. Since the default export is an object with a sum property that contains the sum function, we can access the sum function using dot notation.

Exporting Named and Default Exports

A single named export: sum

1
2
3
4
5


// math.ts

export function sum(a: number, b: number) {
 return a + b;
}

A single default export:

1
2
3
4
5
6


// math.ts
export default {
 sum(a: number, b: number) {
 return a + b;
 },
};

Cheers! 🍺

Promises in TypeScript

Yoonsoo Park — Fri, 21 Apr 2023 01:25:00 -0400

What is a Promise?

A Promise is an object that represents a value that may not be available yet, but will be at some point in the future. It provides a way to handle asynchronous operations in a more structured and readable way than using callbacks. It has three states:

Pending: The initial state of the Promise.
Fulfilled: The state of the Promise representing a successful operation.
Rejected: The state of the Promise representing a failed operation.

Creating a Promise

In TypeScript, we can create a Promise using the Promise constructor. The constructor takes a single argument, which is a function that will be executed immediately when the Promise is created. This function takes two arguments: a resolve function and a reject function.

1
2
3
4
5
6


const delay = (ms: number) =>
 new Promise<void>((resolve) => {
 setTimeout(() => {
 resolve();
 }, ms);
 });

In this example, we’ve defined a function called delay that takes a number of milliseconds as an argument. The function returns a new Promise that resolves after the specified number of milliseconds using setTimeout.

Consuming a Promise

Once we’ve created a Promise, we need to be able to consume it. We can do this using the then method, which takes two callback functions: one to handle the fulfillment of the Promise, and one to handle the rejection.

Here is an example of how to consume the delay Promise we defined earlier:

1
2
3
4
5
6
7


delay(1000)
 .then(() => {
 console.log("Promise fulfilled!");
 })
 .catch((err) => {
 console.error(`Promise rejected: ${err}`);
 });

In this example, we’re calling the delay function with a delay of 1000 milliseconds. We then attach a then callback that logs a message to the console when the Promise is fulfilled, and a catch callback that logs an error message if the Promise is rejected.

Chaining Promises

This allows us to write code that executes multiple asynchronous operations in sequence, without getting stuck in callback hell.

To chain Promises, we use the then method. When we attach a then callback to a Promise, we return a new Promise that will be resolved with the return value of the callback. This allows us to chain multiple then callbacks together, with each one receiving the result of the previous callback.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


const add = (x: number) => (y: number) => x + y;

const delayAdd = (x: number, ms: number) => new Promise<number>((resolve) => {
 setTimeout(() => {
 resolve(x);
 }, ms);
}).then(add(x));

delayAdd(1, 1000)
 .then((result) => {
 console.log(Result: ${result}); // Output: Result: 6
})
.catch((err) => {
console.error(Promise rejected: ${err});
});

In this example, we’ve defined two functions: add, which takes a number x and returns a function that takes another number y and returns the sum of x and y, and delayAdd, which takes a number x and a delay time in milliseconds and returns a Promise that resolves with the value of x after the specified delay time.

We then chain these two functions together using the then method. We call delayAdd with 1 and 1000, which returns a Promise that resolves with the value 1 after a delay of 1000 milliseconds. We then attach a then callback to the Promise that calls add(5) with the result of the previous Promise, which returns a new Promise that resolves with the sum of 1 and 5. Finally, we attach another then callback that logs the result to the console.

Cheers! 🍺

Understanding the Difference Between sfdx force:source:push and sfdx force:source:deploy

Yoonsoo Park — Thu, 20 Apr 2023 01:25:00 -0400

Key differences between sfdx force:source:push and sfdx force:source:deploy:

sfdx force:source:push deploys changes from a local project directory, while sfdx force:source:deploy deploys changes from a source format.
sfdx force:source:push is optimized for development workflows and is useful for pushing code and metadata changes from your local project to your org, while sfdx force:source:deploy is more flexible and can be used to deploy changes from a variety of sources, including third-party apps and other orgs.
sfdx force:source:push is typically faster and more efficient than sfdx force:source:deploy, as it only deploys changes that have been made since the last push. sfdx force:source:deploy, on the other hand, deploys the entire set of metadata specified in the deployment package.
sfdx force:source:push is better suited for development environments, while sfdx force:source:deploy is better suited for production environments where changes are typically made less frequently.
sfdx force:source:push requires that you have a local project directory and version control system set up, while sfdx force:source:deploy can be used without a local project directory.

Cheers! 🍺

Decorators for Class in TypeScript

Yoonsoo Park — Wed, 19 Apr 2023 01:25:00 -0400

Decorators in TypeScript are functions that can be applied to classes, methods, properties, and parameters to modify their behavior or add metadata. In this article, we will focus on decorators for classes and how they can be useful.

Basic Syntax

1
2
3
4


@decorator
class MyClass {
 // class members
}

The @decorator is the decorator that is being applied to the class. Decorators can be applied in any order and can be applied multiple times.

Example

Let’s say we have a class called MyService that provides a method called getData() to fetch data from an API. We want to log the time it takes for getData() to complete. We can achieve this using a decorator. Here is the decorator function:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


function logTime(target: any, name: string, descriptor: PropertyDescriptor) {
 const originalMethod = descriptor.value;
 descriptor.value = function (...args: any[]) {
 const start = performance.now();
 const result = originalMethod.apply(this, args);
 const end = performance.now();
 console.log(`Method ${name} took ${(end - start).toFixed(2)} milliseconds`);
 return result;
 };
 return descriptor;
}

This decorator logs the time it takes for a method to complete. We can apply this decorator to the getData() method in the MyService class like this:

1
2
3
4
5
6
7
8


class MyService {
 @logTime
 async getData() {
 const response = await fetch("https://api.example.com/data");
 const data = await response.json();
 return data;
 }
}

Now whenever we call MyService.getData(), the time it takes to complete will be logged to the console.

So Why Use Decorators?

we’ve got reusability. That’s right, these bad boys can be applied to multiple classes, which means you can reuse functionality like it’s nobody’s business.
we’ve also got modularity. Decorators can be applied in any order and combined to create complex behaviors. It’s like playing with legos, but for coding.
Decorators can also add metadata to your classes, making it easier to understand and work with code. It’s like having a personal assistant that organizes your code for you.

Cheers! 🍺

The Immature Abstraction Problem in Software Engineering - When Code Gets Too Cocky

Yoonsoo Park — Tue, 18 Apr 2023 01:25:00 -0400

One of the most common and often overlooked issues is the immature abstraction problem, which occurs when code gets too cocky for its own good.

At its core, the immature abstraction problem stems from a lack of understanding of how to properly abstract code. Inexperienced developers often create abstractions that are too complex or too generic, resulting in code that is difficult to understand and maintain. And let’s face it, we’ve all been there at some point - trying to show off our skills by making our code look as abstract and clever as possible.

But as any seasoned developer knows, abstracting code is not just about making it look pretty or impressive. It’s about creating code that is both efficient and easy to read and maintain. Unfortunately, when developers get too caught up in the abstraction process, they can lose sight of these goals and end up with code that is confusing, overly complex, and prone to bugs.

what’s the solution to the immature abstraction problem? The answer is simple - don’t get too cocky with your code! Remember that the goal of abstraction is to make your code easier to read and maintain, not to show off how clever you can be.

If you’re unsure whether your abstraction is mature or immature, ask yourself these questions:

Is this abstraction necessary or just a fancy way of doing things?
Will this abstraction make my code easier to read and maintain?
Is this abstraction understandable to someone who is not familiar with the language or framework?

If you can’t answer these questions confidently, it might be time to rethink your abstraction.

Cheers! 🍺

Setting Up Virtual Environments for Multiple Python Versions

Yoonsoo Park — Mon, 17 Apr 2023 01:25:00 -0400

Setting Up Virtual Environments for Multiple Python Versions

In some cases, you may need to work on multiple projects with different Python versions. To avoid conflicts and ensure that each project uses the correct version of Python, you can set up virtual environments for each project. Virtual environments are isolated Python environments that allow you to install packages and dependencies specific to a project, without affecting the global Python installation.

Creating Virtual Environments

To create a virtual environment for a project using venv, navigate to the project directory in your terminal and run the following command:

1

python2 -m venv env

1

python3 -m venv env

You can replace env with any name you prefer.

Activating Virtual Environments

To start using a virtual environment, you need to activate it. Activating a virtual environment sets the correct Python version and environment variables for the current shell session.

To activate a virtual environment, run the following command:

1

source env/bin/activate

Once you have activated a virtual environment, you can install packages and dependencies specific to your project using pip. Any packages you install will only be available within the virtual environment.

Deactivating Virtual Environments

When you finish working in the virtual environment and want to return to the system’s default settings, use:

1

deactivate

This command will revert all changes made to the environment by activation.

Managing Dependencies with requirements.txt

To manage dependencies within a virtual environment:

Creating a requirements.txt: Save all current dependencies to a file:

1

pip freeze > requirements.txt

Installing from requirements.txt:

1

pip install -r requirements.txt

This ensures that you can replicate your environment exactly on another machine or in another environment.

Cheers! 🍺

Iterator vs Iterable in TypeScript

Yoonsoo Park — Sun, 16 Apr 2023 01:25:00 -0400

Iterator vs Iterable in TypeScript

In TypeScript, an iterator is an object that provides a sequence of values through a series of iterations. An iterable, on the other hand, is an object that can be iterated over using an iterator.

Iterators

In TypeScript, an iterator is an object that implements the Iterator protocol. The Iterator protocol defines a single method called next(), which returns an object with two properties: value and done.

The value property is the next value in the sequence, and the done property is a boolean value that indicates whether the sequence has ended. When the done property is true, there are no more values in the sequence.

Here’s an example of an iterator that produces the sequence of numbers 1 to 5:

1
2
3
4
5
6
7
8
9


const numberIterator = {
 next: function () {
 let value = 1;
 return {
 value,
 done: value++ > 5,
 };
 },
};

In this example, the next() method returns an object with the value property set to the current number, and the done property set to false if there are more numbers in the sequence, or true if the sequence has ended.

Iterables

In TypeScript, an iterable is an object that implements the Iterable protocol. The Iterable protocol defines a single method called Symbol.iterator, which returns an iterator object.

Here’s an example of an iterable that produces the same sequence of numbers as the iterator above:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


const numberIterable = {
 [Symbol.iterator]: function () {
 let value = 1;
 return {
 next: function () {
 return {
 value,
 done: value++ > 5,
 };
 },
 };
 },
};

In this example, the numberIterable object implements the Symbol.iterator method, which returns an iterator object with the same implementation as the numberIterator object in the previous example.

Using Iterators and Iterables

Iterators and iterables are commonly used in TypeScript and JavaScript to iterate over arrays, sets, and maps.

For example, here’s how you can use the numberIterator object to iterate over the sequence of numbers it produces:

1
2
3
4
5


let iteratorResult = numberIterator.next();
while (!iteratorResult.done) {
 console.log(iteratorResult.value);
 iteratorResult = numberIterator.next();
}

And here’s how you can use the numberIterable object to iterate over the same sequence of numbers:

1
2
3


for (const number of numberIterable) {
 console.log(number);
}

Cheers! 🍺

Mocking Modules and Functions with Jest

Yoonsoo Park — Sat, 15 Apr 2023 01:25:00 -0400

Mocking Modules and Functions with Jest: A Complete Tutorial

In this tutorial, we’ll explore how Jest can be used to Mock Modules and Functions. We’ll discuss the different techniques involved and provide examples that demonstrate their usage.

Using jest.fn to Mock Functions

1
2
3
4


example/
├── app.js
├── app.test.js
└── math.js

The jest.fn() method is used to create a Mock Function that can be used to test the behavior of dependent code. Let’s consider an example where we want to test a function that depends on another function:

1
2
3
4


// math.ts
export const add = (a: number, b: number): number => a + b;
export const subtract = (a: number, b: number): number => a - b;
export const multiply = (a: number, b: number): number => a * b;

1
2
3
4
5
6
7


// app.ts
import { add } from "./math";

export const multiply = (a: number, b: number): number => {
 const result = add(a, b) * 2;
 return result;
};

In the above code, the multiply() function depends on the add() function. To test the multiply() function, we can create a Mock Function for the add() function using jest.fn():

1
2
3
4
5
6
7
8
9


// app.test.ts
import { multiply } from "./app";
import * as math from "./math";

test("multiply function calls add function", () => {
 math.add = jest.fn();
 multiply(2, 3);
 expect(math.add).toHaveBeenCalledTimes(1);
});

In the above example, we create a Mock Function for the add() function using jest.fn(). We then assign the Mock Function to the math.add property, replacing the original function with the Mock Function.

Finally, we call the multiply() function with the arguments 2 and 3. Since multiply() calls add() internally, the Mock Function will be called instead, allowing us to test the behavior of multiply() in isolation.

Using jest.mock to Mock Modules

The jest.mock() method is used to Mock entire modules, rather than just individual functions. This approach is useful when we want to Mock an entire module rather than just one or two functions.

Let’s consider an example where we want to Mock an entire module that contains multiple functions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// app.test.ts
import * as math from "./math";

jest.mock("./math", () => ({
 add: jest.fn(),
 subtract: jest.fn(),
 multiply: jest.fn(),
}));

test("Mocking entire math module", () => {
 math.add.mockReturnValue(3);
 math.subtract.mockReturnValue(1);
 math.multiply.mockReturnValue(10);

 expect(math.add(1, 2)).toBe(3);
 expect(math.subtract(5, 4)).toBe(1);
 expect(math.multiply(2, 5)).toBe(10);
});

Here’s a step-by-step breakdown of what’s happening in this code:

The first line imports all the functions exported by the math.js module using the import * as math from ‘./math’; syntax.

The next line jest.mock Mocks the entire math.js module. The second argument of jest.mock is a function that returns an object containing Mock Functions for all the functions exported by the module. In this case, add, subtract, and multiply are all Mock Functions created using jest.fn().

Next, the code sets the return values for the Mock Functions using mockReturnValue(). For example, math.add.mockReturnValue(3) sets the return value for the add function Mock to 3.

Finally, the code calls the Mock Functions with arguments and asserts that the return values match the expected values using Jest’s expect function and the toBe matcher.

Cheers! 🍺

An Introduction to Jest Mock Functionality

Yoonsoo Park — Fri, 14 Apr 2023 01:25:00 -0400

At times, when writing unit tests for your application, you may find it challenging to isolate the test subjects from their dependencies. Mocking is a technique that can help you overcome this challenge. By replacing dependencies with objects that you can control and inspect, you can isolate the test subjects and test them in isolation.

In this article, we will discuss the basics of mocking with Jest, a popular testing framework, and explore different ways to use the Mock Function in Jest.

What is Mocking?

Mocking is a technique used in testing

to replace dependencies with objects that you can control and inspect. (Dependencies can be anything your subject relies on, but they are typically modules that the subject imports.)

The Mock Function in Jest

When we talk about mocking in Jest, we’re typically referring to the Mock Function. The goal of mocking is to replace something we don’t control with something we do.

The Mock Function in Jest provides features…

change the implementation.
capture calls
set return values

Creating a Mock Function in Jest

The simplest way to create a Mock Function instance in Jest is with jest.fn(). With a Mock Function, we can easily test captured calls using Jest’s expect function:

1
2
3
4
5
6


test("example of testing captured calls", () => {
 const mock = jest.fn();

 mock("foo");
 expect(mock).toHaveBeenCalledWith("foo");
});

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// Assume we have a function `add` that adds two numbers.
// We want to test if `add` calls its arguments with the correct parameters.

function add(a, b) {
 return a + b;
}

test("add calls its arguments with the correct parameters", () => {
 const mockAdd = jest.fn(add);

 const result = mockAdd(2, 3);

 expect(mockAdd).toHaveBeenCalledWith(2, 3);
 expect(result).toBe(5);
});

Explained

In this example, we create a Mock Function `mockAdd` using `jest.fn()`, passing in the `add` function as its implementation. We then call `mockAdd` with arguments `2` and `3` and assert that it has been called with the correct parameters using Jest's `toHaveBeenCalledWith()` matcher. Finally, we assert that the result of `mockAdd(2, 3)` is `5`. This allows us to test that the `add` function is called with the correct parameters without having to call the real implementation of `add`.

Changing the Return Value, Implementation, or Promise Resolution

Mock Functions in Jest can be used to change the return value, implementation, or promise resolution. Below are some examples of how to use the Mock Function to achieve this:

1
2
3
4
5
6


test("mock implementation", () => {
 const mock = jest.fn(() => "bar");

 expect(mock("foo")).toBe("bar");
 expect(mock).toHaveBeenCalledWith("foo");
});

In this example, we create a Mock Function mock using jest.fn() and set its implementation to return “bar”. We then call mock with the argument “foo” and assert that it returns “bar” using Jest’s toBe() matcher. We also assert that mock has been called with the argument “foo” using Jest’s toHaveBeenCalledWith() matcher.

1
2
3
4
5
6


test("mock implementation using mockImplementation", () => {
 const mock = jest.fn().mockImplementation(() => "bar");

 expect(mock("foo")).toBe("bar");
 expect(mock).toHaveBeenCalledWith("foo");
});

This example is similar to the previous one but uses the mockImplementation() method to set the implementation of the Mock Function instead of passing it as an argument to jest.fn(). The result is the same: the implementation of mock is set to return “bar”, and we assert that it returns “bar” when called with the argument “foo”.

1
2
3
4
5
6
7
8
9


test("mock implementation one time using mockImplementationOnce", () => {
 const mock = jest.fn().mockImplementationOnce(() => "bar");

 expect(mock("foo")).toBe("bar");
 expect(mock).toHaveBeenCalledWith("foo");

 expect(mock("baz")).toBe(undefined);
 expect(mock).toHaveBeenCalledWith("baz");
});

In this example, we use the mockImplementationOnce() method to set the implementation of the Mock Function to return “bar” only the first time it is called. We call mock with “foo” and “baz” and assert that it returns “bar” when called with “foo”, and returns undefined when called with “baz”. We also assert that mock has been called with both arguments using Jest’s toHaveBeenCalledWith() matcher.

1
2
3
4
5
6
7


test("mock return value using mockReturnValue", () => {
 const mock = jest.fn();
 mock.mockReturnValue("bar");

 expect(mock("foo")).toBe("bar");
 expect(mock).toHaveBeenCalledWith("foo");
});

In this example, we create a Mock Function mock using jest.fn() and set its return value to “bar” using the mockReturnValue() method. We call mock with the argument “foo” and assert that it returns “bar” using Jest’s toBe() matcher. We also assert that mock has been called with the argument “foo” using Jest’s toHaveBeenCalledWith() matcher.

1
2
3
4
5
6
7


test("mock promise resolution using mockResolvedValue", () => {
 const mock = jest.fn();
 mock.mockResolvedValue("bar");

 expect(mock("foo")).resolves.toBe("bar");
 expect(mock).toHaveBeenCalledWith("foo");
});

In this example, we are testing a function that returns a Promise. We want to make sure that the Promise resolves to the expected value, “bar”, and that it has been called with the expected argument, “foo”. First, we create a Mock Function called mock using jest.fn(). We then use the mockResolvedValue() method to set the Promise resolution value of mock to “bar”. Next, we call mock with the argument “foo”. Since mock returns a Promise, we use the resolves property to wait for the Promise to resolve, and then use the toBe() matcher to ensure that the resolved value is “bar”. Finally, we use the toHaveBeenCalledWith() matcher to assert that mock has been called with the argument “foo”.

Let’s explore the topic of “Mocking Modules and Functions” tomorrow and learn how to use this powerful feature in our testing workflow.

Tomorrow is Friday!!! YES! Cheers! 🍺

Manage Node.js Versions Explained

Yoonsoo Park — Thu, 13 Apr 2023 01:25:00 -0400

Managing Node.js versions can be challenging when working on multiple projects with different requirements. Fortunately, there are several tools and techniques available that can help you manage Node.js versions based on project requirements.

Why Manage Node.js Versions?

One of the challenges of working with Node.js is managing the different versions of Node.js that are required for different projects. Different projects may have different dependencies, and these dependencies may require specific versions of Node.js.

If you’re not careful, you may end up with a mess of different Node.js versions on your system, which can cause conflicts and make it difficult to manage your projects effectively.

Techniques for Managing Node.js Versions

Node Version Manager (nvm) Node Version Manager (nvm) is a command-line tool that allows you to manage multiple versions of Node.js on your system. With nvm, you can easily switch between different versions of Node.js and install new versions as needed.

Once you have nvm installed, you can use it to install and manage different versions of Node.js. For example, to install Node.js version 14.16.1, you can run the following command:

1

nvm install 14.16.1

To switch to this version, you can run:

1

nvm use 14.16.1

You can also use nvm to set a default Node.js version for a specific project by creating an .nvmrc file in the project directory. For example, to set the default version to 14.16.1, create an .nvmrc file with the following content:

1

14.16.1

Now, when you navigate to the project directory and run nvm use, it will automatically switch to version 14.16.1.

Node.js Version Manager (n) Node.js Version Manager (n) is a simple command-line tool that allows you to install and switch between different versions of Node.js. It is similar to nvm but has a simpler and more streamlined interface.

To use n, you first need to install it on your system.

1

npm install -g n

Once you have n installed, you can use it to install and manage different versions of Node.js. For example, to install Node.js version 14.16.1, you can run the following command:

1

n 14.16.1

To switch to this version, you can run:

1

n use 14.16.1

You can also use n to set a default Node.js version for a specific project by creating an .nvmrc file in the project directory, just like with nvm. For example, to set the default version to 14.16.1, create an .nvmrc file with the following content:

1

14.16.1

Cheers! 🍺

Use console.time in TypeScript to troubleshoot performance issues

Yoonsoo Park — Wed, 12 Apr 2023 01:25:00 -0400

console.time()

Performance issues can be a major headache for developers, especially when working with large-scale TypeScript projects. Fortunately, TypeScript provides several tools to help developers identify and troubleshoot performance issues, one of which is console.time.

The console.time() method in TypeScript allows developers to measure the time it takes for a block of code to execute. This is especially useful when trying to identify bottlenecks in performance, as it allows developers to isolate the code that is causing the issue and focus on optimizing it.

To use console.time() in TypeScript, simply call the method at the start of the block of code you want to measure, and pass a string argument that identifies the timer:

1
2
3


console.time("myTimer");
// Code to measure goes here
console.timeEnd("myTimer");

The console.timeEnd() method is then called at the end of the block of code, using the same timer identifier string. This will output the time elapsed between the two console.time() calls to the console.

For example, let’s say we have a function that sorts an array of numbers and we want to measure its performance:

1
2
3
4
5
6


function sortArray(array: number[]): number[] {
 console.time("sortArray");
 const sortedArray = array.sort((a, b) => a - b);
 console.timeEnd("sortArray");
 return sortedArray;
}

In this example, we use console.time() to start a timer called sortArray at the beginning of the function, and console.timeEnd() to stop the timer at the end. The output of console.timeEnd() will show the time elapsed between the two calls.

By using console.time() and console.timeEnd() in this way, we can quickly identify which parts of our code are taking the longest to execute and focus our optimization efforts on those areas.

Cheers! 🍺

TypeScript's `Pick` and `Omit`

Yoonsoo Park — Tue, 11 Apr 2023 01:25:00 -0400

TypeScript’s Pick and Omit are two utility types that allow you to create new types based on existing types. These types can be very useful in creating new types that are more specialized for a specific use case.

Pick

The Pick type allows you to create a new type by selecting only the specified properties from an existing type. Here’s an example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


type Person = {
 name: string;
 age: number;
 email: string;
};

type PersonNameAndAge = Pick<Person, "name" | "age">;

// PersonNameAndAge is equivalent to:
// {
// name: string;
// age: number;
// }

In this example, PersonNameAndAge is a new type that only includes the name and age properties from the Person type. The syntax for using Pick is as follows:

1

Pick<Type, Keys>

Here, Type is the type you want to pick properties from, and Keys is a union of the keys you want to include in the new type.

Omit

The Omit type allows you to create a new type by excluding the specified properties from an existing type. Here’s an example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


type Person = {
 name: string;
 age: number;
 email: string;
};

type PersonWithoutEmail = Omit<Person, "email">;

// PersonWithoutEmail is equivalent to:
// {
// name: string;
// age: number;
// }

In this example, PersonWithoutEmail is a new type that includes all the properties from the Person type except for the email property. The syntax for using Omit is as follows:

1

Omit<Type, Keys>

Here, Type is the type you want to exclude properties from, and Keys is a union of the keys you want to exclude from the new type.

Cheer! 🍺

What is the difference between String[] and List in Apex?

Yoonsoo Park — Mon, 10 Apr 2023 01:25:00 -0400

In Apex, arrays are collections of elements of the same type that are stored sequentially in memory. Each element in the array is accessed by an index, which starts from zero. Although Apex does not have a true “array” data type, the List data type in Apex is similar in behavior and can be used in much the same way as an array.

Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


public classA {
 public string[] method1() {
 return new string[]{'string_value'};
 }

 public List<String> method2() {
 return new string[]{'string_value'};
 }

 public string[] method2() {
 return new List<String>{'string_value'};
 }

 public List<String> method2() {
 return new List<String>{'string_value'};
 }
}

These all method actually behave the same.

You can even do this

1
2
3
4
5
6
7


List<String> example = new String[5];

myStrings[0] = 'the first';
myStrings.add('the second');

myStrings.set(2,'the third');
myStrings.add('the forth');

What is the difference then?

Array looking List cannot be used for nested arrays - arrays of arrays are not permitted in Apex. But! You can achieve this with List<Type>.

Example:

1

List<List<Type>> nested = new List<List<Type>>();

Cheer! 🍺

Understanding TypeScript's Record Type

Yoonsoo Park — Sun, 09 Apr 2023 01:25:00 -0400

In TypeScript, the Record type is a built-in utility type that represents an object type whose property keys are of a specified type and whose property values are of a specified type. It’s essentially an object type that maps keys of one type to values of another type.

The syntax for Record is as follows:

1
2


Copy code
Record<KeysType, ValueType>

where KeysType is the type of the keys, and ValueType is the type of the values.

Example using custom types

Here’s an example of how to use Record with custom types to define an object type that maps an enum to an object with properties of specific types:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


Copy code
enum MyEnum {
 A,
 B,
 C,
}

type MyObject = {
 name: string;
 value: number;
};

type MyRecord = Record<MyEnum, MyObject>;

const myRecord: MyRecord = {
 [MyEnum.A]: { name: 'A', value: 1 },
 [MyEnum.B]: { name: 'B', value: 2 },
 [MyEnum.C]: { name: 'C', value: 3 },
};

In this example, we define an enum MyEnum and an object type MyObject with two properties, name of type string and value of type number. We then define a MyRecord type using Record that maps MyEnum keys to MyObject values.

We then create a value of type MyRecord called myRecord using object literals to set the values for each key.

Advanced usage

keyof + Record type

In TypeScript, the keyof operator is a type operator that can extract the keys of an object type as a union type. When combined with the Record type, it allows you to define an object type with specific key and value types based on the keys of an existing type.

Let’s see the example.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


interface MyInterface {
 foo: number;
 bar: string;
 baz: boolean;
}

type MyRecord = Record<keyof MyInterface, { value: any }>;

const myRecord: MyRecord = {
 foo: { value: 123 },
 bar: { value: "hello" },
 baz: { value: true },
};

Example Explained

In this example, we define an interface `MyInterface` with three properties of different types. We then define a `MyRecord` type using `Record` and `keyof` that maps the keys of `MyInterface` to an object type with a single value property of type any.

We then create a value of type MyRecord called myRecord using object literals to set the values for each key. This allows us to create an object with the same keys as MyInterface, but with a uniform value property for each key.

Cheer! 🍺

TypeScript - What is the difference between type and interface?

Yoonsoo Park — Sat, 08 Apr 2023 01:25:00 -0400

Type vs Interface: When to Use Each One?

While there is some overlap between types and interfaces, there are some key differences that make one a better choice than the other in specific scenarios.

Use `types` when:

You need to create a union or intersection type.
You need to define a tuple type.
You need to create a type alias that cannot be represented by an interface.
You need to define a type that represents a complex data structure.

Use `interfaces` when:

You need to define the shape of an object.
You need to enforce contracts in your code.
You need to extend or implement interfaces in your code.
You need to define optional properties or readonly properties.

In general, types are more flexible than interfaces, but interfaces are more specific.

Types can represent more complex data structures and allow for more advanced type manipulation. Interfaces, on the other hand, are more rigid and allow for stricter type checking and code contracts.

Cheer! 🍺

Credibility - The Secret Sauce for Success at Work

Yoonsoo Park — Fri, 07 Apr 2023 01:25:00 -0400

So, I decided to hit the reset button on my career and start from scratch. Was it worth it? Honestly, I’m still figuring it out. But one thing’s for sure, if I had these things done on my first career path, things would’ve turned out way differently.

Let’s dive in.

Do More Than Just Meet Expectations

Sure, completing assigned tasks and meeting deadlines is important, but that’s just the bare minimum. To build credibility, you need to go above and beyond what’s expected. Identify unmet needs and do work without being asked. It’s like being the superhero of the office, swooping in to save the day and impressing everyone with your proactive attitude.

Don’t Be A One-Trick Pony

Being inflexible and saying “it’s not my job” is like shooting yourself in the foot. You’re limiting your growth and opportunities by only accepting certain kinds of work. Instead, be open to taking on tasks outside of your job profile. It’s like being a jack-of-all-trades and a master of credibility.

Plan Like A Pro

Proactively identifying problems and creating a plan to address them is like having a superpower. Instead of reacting to problems as they arise, use the premortem technique to visualize what might go wrong and create a plan to solve those issues. It’s like being a master strategist and a hero of problem-solving.

Be The Solution, Not The Problem

Don’t be the Debbie Downer who only points out problems. Be the solutionist who comes prepared with ideas and solutions. It’s like being a superhero who always saves the day and impresses everyone with their problem-solving skills.

Be The Team Player

Prioritizing the team over personal interests is like being the MVP of the office. Employees who do work that matters to the organization and contribute to the team’s success build credibility while also contributing to their own learning and growth. It’s like being a team player and a superhero at the same time.

Sharing knowledge is like spreading your superpowers around the office. Instead of withholding knowledge, share it with others and help them grow. By doing so, you become a valued resource to your colleagues, managers, and stakeholders. It’s like being a mentor and a superhero all in one.

Adapt To The Future

Being willing to change and adapt to future needs is like being a superhero who’s always ready for the next challenge. Instead of sticking to old methods, expand your comfort zone and develop new skills. It’s like being a chameleon and a superhero at the same time.

Respect The Clock

Showing up on time is like being a superhero who’s always punctual and respectful of others’ time. Don’t be the one who’s always late and keeps others waiting. Respect the clock and build some credibility.

May your career be bug-free. Cheer! 🍺

thats.nono

AWS Strands vs LangGraph on Bedrock AgentCore: Lessons from Building an Agentic Platform

The Setup: Why We Needed an Agent Framework

What Killed LangGraph in Our PoC

The 30-Second Wall

The Ecosystem Advantage is Real Though

Strands in Practice: What We Actually Built

The Three-Tier Tool Architecture

The Bedrock Memory Integration

The Gotchas Nobody Tells You About

Container Tool Caching (High Impact)

Response Format Quirk

boto3 Version Lock-in

The Hard Part: The Async Tool Gap

The Problem

Why This Matters More Than It Seems

The Architecture Disconnect

Where LangGraph Would Shine

Our Workaround Strategy

The Numbers

So, Which One Should You Pick?

Why You Should Switch to uv for Python Projects

Why uv is a Game Changer

1. Blazing Speed

2. Unified Toolchain

3. Automatic Python Version Management

Comparison: uv vs Poetry

Migrating from requirements.txt

1. Using uv pip (The “pip” way)

2. Using uv add (The “Project” way)

Common Commands Cheat Sheet

uv add vs uv pip install

Caveats

Conclusion

Python __init__.py Explained: Mastering Package Structure and Imports

Scenario: Building a Notification System

The Problem: Clunky, “Deep” Imports

The Solution: Expose Classes in __init__.py

The Result: Clean, “Flat” Imports

Advanced Tip: Lazy Loading

Conclusion

Why Do Python Experts Use the @property Decorator?

1. Dynamic Attributes (Computed Properties)

The Problem

The Function Solution

The @property Solution

2. Read-Only Protection

Conclusion

Building an Agent Factory with AWS AgentCore

1. The Core Architecture

2. Infrastructure Under the Hood

Identity and Access Management (IAM)

Elastic Container Registry (ECR)

AgentCore Memory

3. Deep Dive: Inside the Builder Agent

The Generic Agent Pattern

Agent Modes: Server vs. Client

Server Mode (AGENT_MODE='server')

Client Mode (AGENT_MODE='client')

Docker Layering Strategy

4. Interacting with the AgentCore SDK

Two Distinct Clients

Listing and Inspecting Agents

Invoking Agents: Simple vs. JSON-RPC

5. Developer Experience: Python, uv, and Automation

6. Getting Started

1. Configure Credentials

2. Initialize Environment

3. Provision Infrastructure

4. Deploy Builder & Run CLI

Securing Agentic AI for Financial Institutions (AWS re:Invent 2025)

1. Identity Propagation

2. Inbound Auth: AWS SigV4

3. Network Isolation (PrivateLink)

Conclusion

Building Responsible AI with Amazon Bedrock (AWS re:Invent 2025)

The Hybrid Approach

Implementation: The apply_guardrail API

The 5 Layers of Protection

Conclusion

Why `uv` is a Game Changer

Migrating from `requirements.txt`

1. Using `uv pip` (The “pip” way)

2. Using `uv add` (The “Project” way)

`uv add` vs `uv pip install`

Python init.py Explained: Mastering Package Structure and Imports

The Solution: Expose Classes in `init.py`

Server Mode (`AGENT_MODE='server'`)

Client Mode (`AGENT_MODE='client'`)

Implementation: The `apply_guardrail` API