Forem: ak0047

Why React Feels So Confusing: My Observations

ak0047 — Thu, 22 Jan 2026 22:24:04 +0000

Introduction

I’ve worked with various programming languages and frameworks, both professionally and through self-study.

Usually, after reading a basic book or going through a tutorial, I can get the hang of things by looking up details online as needed.

However, React didn’t fit into my usual approach at all.

Even after building a few React apps, I often found myself unsure where to write code when I wanted to make small changes to existing functionality.

This made me wonder: why is React so hard to grasp?

In this article, I’ll share my thoughts. I hope it can help people who are just starting with React, or those struggling with it, find a clearer way to understand it.

Reason 1: Multiple Layers of Processing

Let’s look at a simple example:

const [count, setCount] = useState(0);

return (
  <button onClick={() => setCount(count + 1)}>
    {count}
  </button>
);

This code increases a number when the button is clicked.
However, the actual process behind the scenes is more complex than it seems.

Here’s what happens step by step:

The JS/TS code written by the developer calls React’s API (updates the state).
React determines whether re-rendering is necessary.
React updates the virtual DOM.
The browser updates the actual DOM based on React’s instructions.

In other words:

Developer-written JS/TS code
React’s internal processing
Browser rendering

…all happen at different layers. This separation makes it hard to intuitively understand which code runs at which layer, which I think is one reason why React feels confusing.

Reason 2: Triggers for Code Execution Are Hard to Identify

In React, code can be triggered by multiple events:

When a button is clicked (event)
When state changes
When props change

For example:

useEffect(() => {
  console.log("updated");
}, [count]);

This code:

Doesn’t explicitly call a function
Doesn’t involve a direct button click

…but still runs whenever count changes.

This makes it difficult to intuitively understand from the code itself when and why a piece of code will execute, which adds to React’s learning curve.

Reason 3: Display Elements and Logic Are Mixed

In React, JSX mixes the elements displayed in the browser with the logic controlling them:

return (
  <div>
    {count > 0 && <p>{count}</p>}
  </div>
);

While it looks similar to HTML:

Conditional expressions
Variable evaluation
Display logic

…are all included.

This mixing makes it hard to immediately tell which elements will appear under which conditions, contributing to React’s complexity.

Summary

React feels confusing because of:

Multiple layers of processing
Triggers that are not obvious from the code
Blurred boundaries between display elements and logic

These factors combine to create a sense of “I don’t know what’s happening, when, or where”.
On top of this, the variety of JS/TS syntax and styling approaches only adds to the difficulty.

I’m still learning, but being aware of these points helps me approach React more consciously.

💬 How about you?

What aspects of React did you find most confusing when you started?
How do you usually keep track of different layers (state, React processing, DOM updates)?
Do you have any tips for making React code easier to reason about?

Essential Shell Scripting Basics You Should Know First

ak0047 — Tue, 16 Dec 2025 11:49:57 +0000

Introduction

I previously wrote an article about shell scripting, and to my surprise, it was read by far more people than I expected.
Since shell scripting isn’t exactly a “trendy” technology, I assumed there wouldn’t be much interest.

That experience made me realize:

There are probably more people who want to learn shell scripting than we think.

So in this article, I’d like to share a digest of essential shell scripting basics.

This guide is designed to cover “the minimum you need to know to avoid getting stuck when writing your first shell script.”
Rather than going deep into each topic, I focus on breadth and practical awareness.

This article is especially useful if you:

✅ Have never written a shell script before
✅ Tried once but struggled
✅ Want to understand how shell scripting differs from other languages

Basic Rules of Shell Scripts

The `.sh` Extension Is a Convention

Technically, shell scripts can have any file extension.
However, .sh is the widely accepted convention.

hello.sh
backup.sh
deploy.sh

Using .sh enables syntax highlighting in editors and on GitHub, so unless you have a specific reason not to, stick with it.

Write a Shebang (`#!`) on the First Line

A shell script should start with a shebang:

#!/bin/bash

The shebang specifies which shell should execute the script.
It starts with #! followed by the full path to the shell.

One Command Per Line

In shell scripts, a newline separates commands, so the basic rule is one command per line.

If you want to split a command across multiple lines, use \:

echo "This is \
one command"

Comments Use `#`

Comments start with #. You can also place comments mid-line.

There is no native way to comment out multiple lines at once.

# This is a comment
echo "hello" # inline comments are allowed

Working with Variables

Defining Variables

Variables are created automatically using:

variable_name=value

No declaration is required.

Variable naming rules:

Allowed characters: letters, numbers, and _
Cannot start with a number
Lower snake_case is commonly used
Variables are treated as strings by default

If you want an integer variable, you need to declare it explicitly:

# String variable
sum=2+9
echo $sum
# -> 2+9

# Integer variable
declare -i sum
sum=2+9
echo $sum
# -> 11

Referencing Variables

To reference a variable, prefix it with $:

name="Alice"
echo $name
# -> Alice

In bash, referencing an undefined variable does not cause an error—it expands to an empty string:

echo $name
# -> (empty output)

To clearly separate variable names from surrounding text, use {}:

item="pen"
echo "I have many ${item}s"

Single vs Double Quotes

Quotes behave differently depending on the type:

" : variables are expanded
' : variables are not expanded

name="Alice"
echo "$name"
# -> Alice

echo '$name'
# -> $name

To escape characters inside double quotes, use \:

echo "\$name"
# -> $name

Common Control Structures

Conditional Branching (if / case)

if Statements

if [ condition ]; then
  do_something
elif [ another_condition ]; then
  do_something_else
else
  fallback
fi

There are two condition styles ([] and [[]]).
If you’re curious about the difference, see this article:
https://dev.to/a-k-0047/whats-the-difference-between-and-in-shell-scripts-3kkj

case Statements

case is useful when handling multiple patterns:

case "$var" in
  start)
    echo "start"
    ;;
  stop)
    echo "stop"
    ;;
  *)
    echo "other"
    ;;
esac

Loops (for / while)

for Loop

for value in a b c; do
  echo $value
done

while Loop

declare -i count=0

while [ $count -lt 5 ]; do
  echo $count
  count=$count+1
done

An infinite loop can be written like this:

while true; do
  echo "looping..."
  sleep 1
done

Functions

Functions are defined as follows:

hello() {
  echo "Hello $1 and $2"
}

Arguments are accessed using $1, $2, $3, and so on.

Calling a function:

hello "Alice" "Bob"
# -> Hello Alice and Bob

Shell-Specific Concepts

Exit Status

On Linux, every command returns an exit status.

0 → success
Non-zero → failure

The exit status is not displayed automatically.
You can check it using $?:

ls /usr
# -> bin  libexec  sbin  standalone  X11R6  lib  local  share  X11
echo $?
# -> 0

ls /aaa
# -> ls: /aaa: No such file or directory
echo $?
# -> 1

When using exit status in if statements:

0 is treated as true
Non-zero is treated as false

if ls /usr; then
  echo "success"
else
  echo "failure"
fi
# -> success

if ls /aaa; then
  echo "success"
else
  echo "failure"
fi
# -> failure

Command Substitution

You can store command output in a variable using $(...):

now=$(date)
echo $now
# -> Fri Dec 12 19:47:14 JST 2025

Pathname Expansion (Globbing)

Shells can expand patterns like * and ? into multiple filenames.

Examples:

ls
# -> file1.txt file2.txt string.c string.h string.txt

# ? matches a single character
ls string.?
# -> string.c string.h

# * matches any string
ls *.txt
# -> file1.txt file2.txt string.txt

# [] matches one of the listed characters
ls string.[ch]
# -> string.c string.h

Running Shell Scripts Manually

There are two main ways to execute a shell script.

Method 1: Execute Directly (Recommended)

./hello.sh

Specify the script path (relative or absolute)
Executed using the shebang-defined shell
Requires execute permission: chmod +x hello.sh
Script name alone is not enough

✅ ./hello.sh
❌ hello.sh

Method 2: Pass to the Shell

bash hello.sh

Execute permission not required
You must manually choose the correct shell

Conclusion

This article summarized the minimum knowledge needed to avoid getting stuck when writing your first shell script.

There are many more important patterns and techniques to learn, so I plan to write follow-up articles that dive deeper into specific topics.

💬 How about you?

What was the most confusing part of shell scripting when you first learned it?
Are there any shell scripting rules or behaviors that surprised you?
Would you like to see a deeper article on a specific topic (e.g. if conditions, quoting, or debugging)?

I Built a Curl Command Generator App with React

ak0047 — Sun, 23 Nov 2025 04:34:05 +0000

Introduction

I built a browser-based curl command generator using React.

In this article, I’ll introduce the app, explain how to use it, share the background behind the development, and talk about the challenges and lessons learned along the way.

▶ App URL: https://d249wz41volo8p.cloudfront.net

Overview

This application is a tool that automatically generates curl commands for sending HTTP requests.
By simply entering the method, URL, headers, and body, the corresponding curl command is generated instantly.

How to Use

Select the HTTP method (e.g., GET, POST).
Enter the request URL.
Add headers, body, or authentication info as needed.
Choose additional options (e.g., -i, -L, -v, -k) using checkboxes.
The curl command is generated and displayed in real time based on your input.
Click the Copy button to copy it to your clipboard.

Use Cases

✅ Quickly test API requests.
✅ Generate multiple curl commands for different scenarios.
✅ Learn and review how to write curl commands and use common options.

Features

Real-time curl command generation based on input.
Common options can be easily selected with checkboxes.
Add or remove multiple headers dynamically.
Supports Basic Authentication and Bearer Tokens.
Light / Dark mode switching supported.
Language switching (Japanese / English) supported.

Technologies Used

Frontend

Category	Technology
Language	TypeScript
Library	React
Styling	Tailwind CSS, Shadcn UI
Icons	lucide-react
State Management	React Hooks (useState, useEffect)
Development Env	Docker, Docker Compose
Hosting	S3 + CloudFront

Backend

None (frontend-only architecture)

System Architecture

Why I Built This

Recently, I started using curl more often at work. Since I wasn’t very familiar with it, I found myself repeatedly asking:

How do I specify the method again?
How do I set headers?
What does this option do?

I had to look things up every time.

Wouldn’t it be convenient if curl commands could be built just by selecting options in a UI?

That idea led me to build this app.

Another reason was that I thought I could reuse parts of the code from a previous project:

my “.gitignore behavior checker” app.👇

https://dev.to/a-k-0047/i-built-a-gitignore-behavior-checker-app-with-react-a31

What I Focused On

Reusing Code from `.gitignore` Checker

I tried to be efficient by reusing layouts, components, and logic from my previous app.
The language-switching feature (Japanese/English) was also reusable, which saved a lot of development time.

Implementing Dark Mode

I wanted to try something new in this project, so I added dark mode.
Unifying almost all UI with shadcn/ui made dark mode support straightforward.

Since shadcn/ui exposes component styles directly through code, I was able to match my custom components to its style and maintain a consistent design easily.

Testing Generated Curl Commands

For verifying the generated curl commands, I used:

https://httpbin.org/

It was helpful for testing various options and authentication patterns.

Using AWS CDK

I used AWS CDK to create and manage the hosting environment (S3 + CloudFront).
I previously created these resources manually via the AWS console, but automating them made things much easier.

What I Learned

Reusing Code Matters

Reusing code from my .gitignore checker app significantly reduced development time.
I also wrote this app with reuse in mind—features like dark mode and AWS CDK configuration will be useful in future projects.

You Learn a Lot by Actually Using What You Built

It sounds obvious, but using your own tools reveals many areas for improvement.

For example, I originally placed the “Copy” button inside the command output area,
but long commands would overlap with the button.
So I moved it outside the text area.

By actually using the app, I found many design and layout tweaks that made it more user-friendly.

Getting feedback from others would be ideal, but first ensuring you can use your app comfortably is a great start.

Future Plans

New Features

More curl options
Saving generated commands
Running commands directly from the UI

Deployment Automation

I automated resource creation with AWS CDK, but deployment is still manual.
I’d like to automate it using GitHub Actions.

Closing Thoughts

There are already many curl generators out there, so I wondered whether it was worth building one myself.

But in the end, I learned a lot and built reusable components and infrastructure that will help in future projects.

I’m glad I took the time to build it, and I’d like to continue applying what I learned.

▶ App

https://d249wz41volo8p.cloudfront.net

▶ GitHub Repository

https://github.com/a-k-0047/curl-generator-front

💬 How about you?

Have you ever built a small tool like this for your workflow? How did it go?
What kind of features would you add to a curl generator like this?
Do you usually write curl commands by hand, or do you use tools to help?

What’s the Difference Between [ ] and [[ ]] in Shell Scripts?

ak0047 — Tue, 18 Nov 2025 13:21:05 +0000

Introduction

Recently, I had an opportunity to write some shell scripts at work.
Since I didn’t have much experience with shell scripting, I looked things up online while writing the code. That’s when I ran into this question:

What’s the difference between writing if [ ]; then and if [[ ]]; then ?

In this article, I’ll share what I learned about the differences between the two and how to choose which one to use.

The Basic Difference Between `[ ]` and `[[ ]]`

Syntax	Type	Characteristics
`if [ condition ]; then`	POSIX-standard	Works on any UNIX environment. The classic format.
`if [[ condition ]]; then`	Bash extension	Bash-only. Safer and more powerful.

The POSIX-standard syntax is defined so that it behaves the same across all UNIX-like systems.
It works on Linux, macOS, BSD, and any POSIX-compliant shell.

On the other hand, the Bash extension syntax works on Bash and Zsh, but does not work on /bin/sh or other strictly POSIX-compliant shells.

[ ] internally calls the test command.
So this:

if [ -f file ]; then
    echo "Exists"
fi

is actually equivalent to:

if test -f file; then
    echo "Exists"
fi

Meanwhile, [[ ]] is parsed directly by the shell, which allows safer handling of complex expressions and pattern matching.

Common Conditional Expressions Compared

Here are common examples written using both [ ] and [[ ]].

1. Checking File or Directory Existence

Condition	Meaning	`[ ]`	`[[ ]]`
File exists	-f	`[ -f "$file" ]`	`[[ -f $file ]]`
Directory exists	-d	`[ -d "$dir" ]`	`[[ -d $dir ]]`
Does not exist	!	`[ ! -f "$file" ]`	`[[ ! -f $file ]]`

Both work the same, but with [[ ]] you can omit quotes safely.

2. String Comparison

Condition	Meaning	`[ ]`	`[[ ]]`
Equal	`=`	`[ "$a" = "$b" ]`	`[[ $a = $b ]]`
Not equal	`!=`	`[ "$a" != "$b" ]`	`[[ $a != $b ]]`
Empty	`-z`	`[ -z "$a" ]`	`[[ -z $a ]]`
Not empty	`-n`	`[ -n "$a" ]`	`[[ -n $a ]]`

[ ] → Always quote variables
[[ ]] → Quotes optional and safer

3. Numeric Comparison

Condition	Meaning	`[ ]`	`[[ ]]`
Equal	-eq	`[ "$x" -eq "$y" ]`	`[[ $x -eq $y ]]`
Greater	-gt	`[ "$x" -gt "$y" ]`	`[[ $x -gt $y ]]`
Smaller	-lt	`[ "$x" -lt "$y" ]`	`[[ $x -lt $y ]]`

Same syntax in both cases.

4. AND / OR Conditions

[ ] syntax

[ -f "$a" ] && [ -r "$a" ]    # AND（both true）
[ -f "$a" ] || [ -f "$b" ]    # OR（one true）

[[ ]] syntax

[[ -f $a && -r $a ]]    # AND（both true）
[[ -f $a || -f $b ]]    # OR（one true）

[[ ]] allows combining conditions inside a single expression.

5. Pattern Matching

file="report.txt"

# Works in [[ ]]
if [[ $file == *.txt ]]; then
    echo "Text file"
fi

# Does NOT work in [ ] (always false)
if [ $file == *.txt ]; then
    echo "Will not run"
fi

Wildcards (*, ?) are supported only in [[ ]].

How to Choose

Use Case	Recommended Syntax
Needs POSIX compatibility (`/bin/sh`)	`[ ]`
Bash-only script, want safety	`[[ ]]`
Avoiding quote-related bugs	`[[ ]]`
Needs compatibility with other shells	`[ ]`

Pick One Style and Stick to It

You can use either style, but it’s best to choose one and stay consistent.

Here’s why:

1. Better readability and maintainability

Mixing [ ] and [[ ]] in one script makes readers wonder:

“Why is this one using [ ]? Is there a special reason?”

Unintended inconsistencies increase mental load and confusion.

2. Prevent incompatibility across shells

[[ ]] works only in Bash.
It fails in /bin/sh:

#!/bin/sh
if [[ -f file ]]; then
    echo "Exists"
fi

Works in bash
Errors in sh

Therefore:

Writing a Bash script? → Use [[ ]]
Want POSIX portability? → Use [ ]

3. Avoid subtle bugs

Since [ ] and [[ ]] evaluate expressions differently, mixing them can cause unexpected behavior.

Example:

var="*.txt"

# [ ] → filename expansion occurs
if [ $var = "*.txt" ]; then
    echo "match"
fi

# [[ ]] → treated as a pattern
if [[ $var == *.txt ]]; then
    echo "match"
fi

Even though the lines look similar, their behavior differs.
Consistency prevents surprises.

Summary

[ ] is the POSIX-standard test command
[[ ]] is a Bash extension: safer and more flexible
Both support -n / -z, but [[ ]] is safer without quotes
[[ ]] supports combining conditions and pattern matching
Either is fine—but don’t mix them

Closing Thoughts

Before writing this article, I didn’t even know there were two different syntaxes.
I was copying conditional expressions from the internet and ended up mixing [ ] and [[ ]] in the same script without realizing it.

If this article helps even one person avoid that mistake, I’ll be happy.
Be mindful when choosing which syntax to use!

💬 How about you?

What syntax do you usually use in your shell scripts — [ ] or [[ ]]? And why?
Have you ever run into unexpected behavior because of differences between [ ] and [[ ]]?

Understanding the Asterisk (*) in Python Function Arguments

ak0047 — Thu, 06 Nov 2025 12:22:35 +0000

Introduction

Have you ever seen function arguments in Python with a * or ** and wondered what they mean?
I’ve definitely seen them — and to be honest, I used to just ignore them because they looked confusing.

Recently, I came across them again and decided it was finally time to understand what’s really going on.
Here’s what I learned about how and when to use * and ** in Python functions.

When to Use `*` and `**`

We use * and ** in function arguments when we want to reuse the same logic, but the number or names of arguments might differ.

In short, these allow us to define functions that don’t fix the number or names of arguments — making our code much more flexible.

Let’s go through the different ways to use them 👇

`*args`: Collecting Multiple Positional Arguments

You can use a single asterisk (*) to collect any number of positional arguments into a tuple.
That means the function can accept a variable number of arguments without breaking.

def greet(*args):
    for name in args:
        print(f"Hello, {name}!")

greet("Alice") 
# Hello, Alice!

greet("Alice", "Bob", "Charlie")
# Hello, Alice!
# Hello, Bob!
# Hello, Charlie!

By convention, we name it args, but you can actually use any name.

This pattern is useful when you don’t know in advance how many arguments will be passed — for example, logging, combining results, or batch processing.

Note that any argument after *args must be passed as a keyword argument:

def sample(*args, x, y):
    print(args, x, y)

sample(1, 2, 3, x=4, y=5)  # ✅ OK
# sample(1, 2, 3, 4, 5)    # ❌ Error: x and y must be keyword arguments

`kwargs`: Collecting Keyword Arguments as a Dictionary**

A double asterisk (**) allows a function to collect any number of keyword arguments into a dictionary.

def show_info(**kwargs):
    for key, value in kwargs.items():
        print(f"{key}: {value}")

show_info(name="Alice", age=25, country="Japan")
# name: Alice
# age: 25
# country: Japan

The name kwargs stands for keyword arguments, but again — any name works.

This is handy when you want to handle optional parameters or when a function may receive additional options in the future.

Keep in mind: **kwargs must appear last in the function definition.

# ✅ OK
def sample(a, b, **kwargs):
    print(a, b, kwargs)

# ❌ Invalid
# def sample(a, b, **kwargs, c):
#     print(a, b, kwargs, c)

The Lone `*`: Forcing Keyword-Only Arguments

If you include a bare * in your function definition, all parameters after it must be passed as keyword arguments.

def move(x, y, *, speed=1.0, direction="forward"):
    ...

# ✅ OK
move(10, 20, speed=2.0, direction="backward")

# ❌ Error: speed and direction must be passed as keyword arguments
# move(10, 20, 2.0, "backward")

This helps clearly separate main parameters from optional ones, making your function calls more readable and less error-prone.

Argument Unpacking with `*` and `**`

You can also use * and ** when calling a function, not just when defining one.
This technique is known as argument unpacking — it lets you “expand” a list, tuple, or dictionary into separate arguments.

Example 1: Unpacking a list or tuple

def add(a, b, c):
    return a + b + c

numbers = [1, 2, 3]
result = add(*numbers)  # same as add(1, 2, 3)
print(result)  # 6

Example 2: Unpacking a dictionary

def show_profile(name, age, country):
    print(f"{name} ({age}) from {country}")

profile = {"name": "Alice", "age": 25, "country": "Japan"}
show_profile(**profile)
# same as show_profile(name="Alice", age=25, country="Japan")

Practical Example: Shared Logic with Different Arguments

Here’s a simple but powerful use case — when multiple functions share the same workflow, but take different arguments.

def process_anything(func, *args, **kwargs):
    print("=== Start process ===")
    result = func(*args, **kwargs)
    print("=== End process ===")
    return result

def process_user(user_id, *, active=True, notify=False):
    print("Processing user:", user_id, active, notify)

def process_order(order_id, *, priority=False):
    print("Processing order:", order_id, priority)

process_anything(process_user, 123, notify=True)
# === Start process ===
# Processing user: 123 True True
# === End process ===

process_anything(process_order, 999, priority=True)
# === Start process ===
# Processing order: 999 True
# === End process ===

Why this works

process_anything() can call any function, regardless of how many arguments it takes
Shared steps (logging, setup, teardown) live in one place
Great for decorators, wrappers, or utility functions

When to Use Each

Situation	Syntax	Why it helps
Variable number of arguments	`*args`	Flexibility
Collecting optional parameters	`**kwargs`	Easy to extend
Forcing keyword arguments	`def func(*, option=...)`	Safer and clearer
Passing a list/dict as arguments	`obj` / `*obj`	Clean and concise
Reusing logic for different functions	`args, *kwargs`	Improves reusability

Summary

*args: collects positional arguments
**kwargs: collects keyword arguments
* alone: makes following parameters keyword-only
Use * / ** when calling a function to unpack arguments
Perfect for “same logic, slightly different arguments” cases

Final Thoughts

I used to avoid * and ** because they looked intimidating — but after digging in, I realized how powerful and practical they are.
I wish I’d learned about them earlier; they would’ve made some of my past code so much cleaner.
From now on, I’m definitely going to use them more often.

💬 How about you?

Have you used *args or **kwargs in your own projects?
What’s a situation where they saved you from writing repetitive code?

What kind of day is this ‘day’? — Naming Tips That Won’t Confuse Your Readers

ak0047 — Wed, 15 Oct 2025 10:33:13 +0000

Introduction

day — What kind of day is it?
status — The status of what?
user — Which user?

In one of the systems I maintained in the past, I came across code filled with extremely generic variable names like day, status, and user.

It was painful to read and understand what each variable actually represented.

That experience made me wonder:

How can we name things in a way that makes sense not only to others, but also to our future selves?

So I decided to dig into the fundamentals of naming — and summarize what I found.

While the examples below use Python, most of these principles apply to any programming language.

Follow a Consistent Naming Rule

You can use any naming style, but what really matters is consistency within the project.

Here are some common conventions:

Case Styles

Pick one and stick with it.

Style	Example	Common Usage
snake_case	`user_name`	Python variables, functions
camelCase	`userName`	JavaScript variables
PascalCase	`UserProfile`	Class names

Use Verbs and Nouns Properly

Match the word type to what you're naming.

Type	Naming pattern	Example
Function / Method	verb + object	`send_email`, `calculate_total`
Variable / Class	noun	`user`, `payment_service`

Prefixes and Suffixes

Use consistent patterns for similar kinds of behavior.

Type	Prefix	Example
Getter	`get_`	`get_user`, `get_order`
Converter	`to_`	`to_json`, `to_dict`
Test function	`test_`	`test_user_login`

Share and Automate Your Naming Rules

Document your naming conventions and share them with your team.
Use linters like flake8, pylint, or ESLint to enforce consistency automatically.

✅ This keeps your codebase coherent and reduces review fatigue.

Avoid Names That Are Too Short

Avoid Single Words That Lack Context

email          # ❌ What is this? An address? A message?
email_address  # ✅ Clearer
email_message  # ✅ Clearer

Be Careful with Overly Generic Words

Words like data, result, or status are too vague.
Also, avoid using temporary placeholders like tmp or temp.

pending_user  # ✅ A user waiting for approval
temp_user     # ❌ “Temporary” in what sense?

Avoid One- or Two-Letter Names

Use single letters only when there’s a clear, conventional reason —
for example, loop counters or coordinate axes.

for i in range(10):  # ✅ OK, conventional for loops
    ...

x, y = 10, 20  # ✅ OK for coordinates

Avoid Abbreviations

Abbreviations make search and readability harder.

copy_data  # ✅
cpy_data   # ❌

Use only well-known abbreviations such as HTML, URL, DB, or ID.

Omit Unnecessary Information

Don’t Include Class Names in Attributes

Keep names concise but meaningful.

class Cat:
    def __init__(self, weight):
        self.weight = weight  # ✅ Don't name it catweight

Don’t Add Numbers to Differentiate Variables

payment1 = ...
payment2 = ...
payment3 = ...

Instead, use a list, dictionary, or more descriptive names.

Don’t Include Data Types in Names

Usually, the data type is obvious or irrelevant.

name      # ✅
name_str  # ❌

Make Your Names More Expressive

Use `is` / `has` for Boolean Variables or Functions

This makes intent immediately clear.

is_valid_email = True

def has_permission(user: User) -> bool:
    ...

Avoid Negative Names

Negative forms can create confusing double negatives.

if not is_valid:  # ✅ Easy to read
if is_not_valid:  # ❌ Harder to process

Include Units in Names

This avoids ambiguity about measurement.

weight_kg = 5.2
length_m = 3.0

Use Plural Names for Collections

user = "Alice"            # ✅ Single item
users = ["Alice", "Bob"]  # ✅ Collection

Watch Out for These Common Pitfalls

Don’t Override Built-in Names

Avoid using names like list, id, sum, or type.

list = [1, 2, 3]     # ❌
my_list = [1, 2, 3]  # ✅

Think Ahead — Future Changes Matter

Don’t embed implementation details or formats in names.
- read_csv() → If you later support JSON, load_data() is more flexible.
Avoid naming variables after data structures.
- user_list → It might later become a set or a dict.

Conclusion

When I revisited the topic of naming, I realized there’s much more to consider than I thought.
Even names that make sense today can become meaningless months later.

That’s why I try to keep these principles in mind —
to write code that’s not only clear to others, but also to future me.

💬 How about you?

What naming conventions or rules do you follow in your projects?
Are there any particular pitfalls or lessons you've learned when it comes to naming?
What’s the worst (or funniest) variable name you’ve seen?

I Built a .gitignore Behavior Checker App with React

ak0047 — Fri, 03 Oct 2025 09:14:32 +0000

Introduction

I built a small web app that lets you check how .gitignore rules behave directly in your browser.

In this post, I’ll walk through the app’s overview and usage, share some background on why I created it, highlight some challenges and design choices, and summarize what I learned during the process.

▶ Live Demo: https://d14csvmoeha0t5.cloudfront.net/

Overview

The app allows you to quickly check whether a given file or directory would be tracked by Git or ignored based on .gitignore rules.

It’s essentially a playground for .gitignore—helpful for developers who want to test and debug ignore patterns without having to commit and check inside a repo.

How It Works

Upload a .gitignore file, or paste its contents into the text area.
Enter file or directory names in the other text area.
The app will automatically evaluate whether those files/directories are tracked or ignored.

When You Might Use It

✅To double-check if your .gitignore rules are working correctly
✅Before adding new ignore rules and wanting to test them
✅To debug why something is unexpectedly tracked or ignored

Key Features

Batch checks: Evaluate multiple file and directory names at once
Real-time results: Changes in the text area are instantly reflected in the results
Rule transparency: Shows which rule caused the file to be ignored
Language toggle: Switch between English and Japanese

Tech Stack

Frontend

Category	Technology
Language	TypeScript
Framework	React
Styling	Tailwind CSS, Shadcn UI
Dev Env	Docker, Docker Compose
Hosting	S3 + CloudFront

Backend
None — it’s a frontend-only app.

System Architecture

Why I Built This

This project started as a React learning exercise. I wanted to build something useful for developers while keeping it entirely frontend-based.

At first, I considered building a .gitignore generator, but similar tools already exist. Instead, I thought: “What if I add a feature to check whether a file will actually be ignored?”

Since I’ve personally run into situations where files were unexpectedly tracked (or ignored), this seemed like a practical idea.

Eventually, I decided to keep it simple and focus only on the checking feature. That made the app easier to use and more focused.

Challenges I Faced

Patterns like . or *
Handling them correctly was tricky—regex conflicts caused plenty of unexpected behavior.
Language toggle & layout issues
Switching between Japanese and English changes text length, which broke layouts. Styling had to account for that.
File download limitations
I originally planned to let users export their .gitignore file, but ran into restrictions: browsers don’t allow direct downloads with filenames starting with a dot.

Design Decisions & Improvements

To make the app approachable even for first-time users, I focused on simplicity:

Default sample input and output are shown on load
Minimal UI: mostly black and white, with color used only for results/errors
Clear support for both Japanese and English

What I Learned

React alone can do more than expected
Previously, I always combined frontend + backend, but this project showed me how far you can go with just React.
Simple UIs are deceptively hard
Striking the balance between too little explanation (confusing) and too much (cluttered) was harder than I thought.
Less is more
By cutting extra features (like generating/downloading .gitignore files), I reduced dev time, kept the UI clean, and improved usability of the core functionality.

Future Ideas

I’d like to build more small, developer-focused tools like this. Maybe even a collection of utilities that share components such as language toggling or upload/copy/reset buttons.

The .gitignore checker was a good experiment, and its components are reusable in other tools.

Closing Thoughts

This .gitignore checker was inspired by real frustrations I’ve had when files weren’t being ignored as expected.

I designed it to be intuitive for first-time users, but I’d love to hear feedback from developers who try it. Your opinions will help me improve and guide future projects.

Live Demo: https://d14csvmoeha0t5.cloudfront.net/
GitHub Repo: https://github.com/a-k-0047/gitignore-checker-front

Questions

Did you find this kind of .gitignore checker useful or interesting?
Have you ever run into a tricky situation where .gitignore didn’t behave the way you expected?
If you could add one more feature to this app, what would it be?

👉 Feel free to answer any of these — I’d love to hear your thoughts!

Automatically Backing Up a GitHub Repository to S3 with GitHub Actions

ak0047 — Sun, 14 Sep 2025 11:41:41 +0000

Introduction

I built a GitHub Actions workflow that automatically backs up GitHub repositories to AWS S3.

The workflow is available as a template repository on GitHub:

👉 github-backup-template

Feel free to try it out if you’re interested!

Motivation

The idea came from this blog post I recently read:

🚀 Why You Should Keep Multiple Backups of Your Code (Don’t Rely Only on GitHub)

The author emphasized the importance of not relying solely on GitHub and keeping backups of your repositories. After reading it, I decided to set up my own backup system.

That article demonstrated how to automate local backups using cron or Task Scheduler. However, since my computer isn’t always running, I wanted a fully online, serverless approach. That’s when I thought:

“Why not leverage GitHub Actions’ scheduled workflows?”

So, I gave it a try.

How It Works

Workflow steps

Run on schedule with GitHub Actions
git clone --mirror the target repository
Create a bundle file
Upload the bundle to an S3 bucket

What gets backed up

Full commit history (all branches & tags)
Branch and tag references
Remote configuration & refs

What doesn’t get backed up

Issues / Pull Requests / Projects / Discussions / Actions history
Wiki or static files in GitHub Pages
Repository settings (e.g., Branch Protection rules)

Lessons Learned

A couple of tricky points during implementation:

awscli installation

Initially, I tried installing awscli in the workflow runner and ran into errors. Turns out it’s already pre-installed on GitHub-hosted runners—so no installation step was needed.

GitHub Personal Access Token authentication

I first tried with Fine-grained Personal Access Tokens, but authentication failed. Switching to a Classic Token with repo scope solved the issue.

Interestingly, GitHub Copilot was really helpful here—it suggested possible causes and fixes when my workflow runs failed.

Publishing the Template

After testing it on my own repositories and confirming the backups worked, I decided to publish it as a template repository.

My reasons:

Someone else might find it useful
It adds to my portfolio
It gives me something to blog about

In other words, three birds with one stone.

To make it easier for others to use, I:

Wrote all workflow comments in English
Provided a multi-language README (Japanese & English)
Added an MIT license for clarity

What’s Next

This project is still new, so I don’t have a detailed roadmap yet. But for now, my plans are:

Run it for my own repositories for a while
Collect user feedback
Consider S3 lifecycle policies (storage cost optimization, automated deletion, etc.)

If you have suggestions for improvement, I’d love to hear them!

Final Thoughts

This project started when reading an English blog post (as part of my language learning), which unexpectedly connected with something else I had learned earlier—GitHub Actions for automating React deployments.

It reminded me how valuable it is to keep gathering new inputs and ideas—you never know when they’ll connect.

Building this workflow was fun because I got to use GitHub Actions, GitHub Copilot, and AWS together.

I’m looking forward to making more small tools like this that might help others—while enjoying the process.

Getting Started with IaC on AWS: Choosing Between CloudFormation, SAM, and CDK

ak0047 — Fri, 05 Sep 2025 11:26:18 +0000

Introduction

I’m currently building a React app.
In the past, I hosted it on S3 + CloudFront, so I thought I’d do the same this time. I went ahead and created the resources using the AWS Management Console, but then I caught myself thinking:

What settings did I use last time?
Did I misconfigure something this time?
Clicking through the console is such a hassle…

That’s when I decided to look into how to provision AWS resources with IaC (Infrastructure as Code).

In this post, I’ll walk through the main IaC tools available on AWS, compare their strengths, and share recommendations for different development scenarios—frontend and backend.

Why IaC?

Using IaC comes with some clear benefits:

Reproducible setups
→ Easily spin up multiple environments (e.g., dev, staging, prod).
Fewer human errors
→ No risk of misclicking in the console.
Automation-friendly
→ Since your infra is code, you can seamlessly integrate it into pipelines (e.g., GitHub Actions).

IaC Options on AWS

The three main IaC options in the AWS ecosystem are:

CloudFormation
AWS SAM (Serverless Application Model)
AWS CDK (Cloud Development Kit)

Here’s a quick overview:

CloudFormation

AWS’s core IaC service
Define resources in JSON or YAML
Pros: Covers all AWS services, lots of official templates available
Cons: Can get verbose; hard to manage at scale

→ Best for: “I want simple templates” or “I want to learn from AWS’s official examples.”

AWS SAM

Built on top of CloudFormation
Tailored for serverless apps (Lambda, API Gateway, DynamoDB, etc.)
Handy CLI (sam build, sam local invoke, sam deploy)
Pros: Minimal config for serverless workloads
Cons: Not great for non-serverless services

→ Best for: “I want to quickly build & deploy a serverless app.”

AWS CDK

Lets you define infra using programming languages (TypeScript, Python, Java, etc.)
Compiles down to CloudFormation under the hood
Pros: Use loops, conditionals, and abstractions—perfect for complex infra
Cons: Slightly steeper learning curve

→ Best for: “I want to use my favorite language” or “I need to manage large/complex setups.”

Practical Examples

Frontend Example: React on S3 + CloudFront

Recommended: CDK or CloudFormation
Typical setup: Deploy React static files to S3, distribute via CloudFront

CDK Example (TypeScript):

import * as cdk from "aws-cdk-lib";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as cloudfront from "aws-cdk-lib/aws-cloudfront";

export class FrontendStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const bucket = new s3.Bucket(this, "FrontendBucket", {
      websiteIndexDocument: "index.html",
      publicReadAccess: false,
    });

    new cloudfront.CloudFrontWebDistribution(this, "FrontendCDN", {
      originConfigs: [
        {
          s3OriginSource: { s3BucketSource: bucket },
          behaviors: [{ isDefaultBehavior: true }],
        },
      ],
    });
  }
}

Serverless Backend Example: Lambda + API Gateway

Recommended: AWS SAM
You can write it in CloudFormation, but SAM makes it much easier

SAM Example (YAML):

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  HelloFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.lambda_handler
      Runtime: python3.11
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Path: /hello
            Method: get

Non-Serverless Backend Example: ECS + VPC + RDS

Recommended: CDK
Great for managing complex infra like ECS + VPC + RDS

CDK Example (ECS Fargate):

import * as ecs from "aws-cdk-lib/aws-ecs";
import * as ec2 from "aws-cdk-lib/aws-ec2";

const vpc = new ec2.Vpc(this, "MyVpc");
const cluster = new ecs.Cluster(this, "MyCluster", { vpc });

new ecs.FargateService(this, "MyService", {
  cluster,
  taskDefinition: new ecs.FargateTaskDefinition(this, "TaskDef"),
});

Summary

CloudFormation
→ The fundamental tool for defining AWS infra in YAML/JSON.
AWS SAM
→ Optimized for serverless apps, especially Lambda-heavy projects.
AWS CDK
→ Flexible, expressive, and powerful for complex or large-scale infra.

Even if you’re used to clicking around in the AWS Console, adopting IaC unlocks big advantages: reproducibility, environment consistency, and automation.

If you’re new to IaC, I recommend starting small—maybe with your frontend setup—then gradually tying it into CI/CD (like GitHub Actions) for full automation.

What is GitHub Actions? A Beginner-Friendly Guide with Examples

ak0047 — Fri, 29 Aug 2025 06:06:25 +0000

Introduction

When I was researching how to automate the deployment of a React app, I discovered that it can be done using GitHub Actions.

But then I thought:
“What exactly is GitHub Actions?”
So I dug into it, and here’s a summary of what I learned.

What is GitHub Actions?

GitHub Actions is a CI/CD platform provided by GitHub.
It allows you to define workflows that run automatically in response to events in your GitHub repository—such as pushes, pull requests, or scheduled jobs.

GitHub also provides the virtual machines (runners) where your workflows execute, so you don’t need to manage servers yourself.

What Can You Do with GitHub Actions?

GitHub Actions is not just for deployment automation—it can cover the whole development lifecycle.

Automated Testing (CI)
- Automatically run tests whenever you push or open a pull request.
- Catch bugs early before merging.
Code Quality Checks
- Run linters and formatters automatically.
- Enforce consistent coding style across the team.
Security Checks
- Automate vulnerability scans (npm audit, pip-audit, etc.).
- Combine with Dependabot for automatic dependency updates.
Deployment Automation (CD)
- Deploy automatically to AWS, Vercel, Netlify, or S3 + CloudFront whenever changes are merged into main.
- No more manual uploads.
Scheduled Jobs
- Like cron jobs: run tasks daily, weekly, or on any schedule.
- Example: data collection, report generation, backups.
Notifications
- Send results to Slack, Discord, LINE, Teams, email, or any webhook.
- Get alerted immediately when something fails.
Issue / PR Management
- Automatically label pull requests.
- Close inactive issues automatically.

Notifications

GitHub Actions supports more than just GitHub’s built-in notifications. You can integrate with:

GitHub default notifications (UI + email)
Slack
Discord
LINE
Teams / Google Chat
Email (SMTP)
Custom Webhooks (send data to your own service)

Writing a Workflow (YAML)

Workflows in GitHub Actions are defined in YAML files inside the .github/workflows/ directory.

Here’s a minimal example:

name: My First Workflow

on:            # Trigger: when to run
  push:         # Run when code is pushed
  pull_request: # Run when PR is opened

jobs:           # Define jobs
  build:
    runs-on: ubuntu-latest   # Runner environment
    steps:
      - name: Run a command
        run: echo "Hello, world!"
      - uses: actions/checkout@v4   # Use an existing action

What Does uses: Mean?

The uses: keyword is for reusing existing GitHub Actions (action).
An “action” is a small automation script published on GitHub (either official or community-made).

You can find thousands of actions in the GitHub Marketplace.

Commonly Used Actions

- uses: actions/checkout@v4   # Checkout repository code into the runner
- uses: actions/setup-node@v4 # Setup a Node.js environment

Using actions lets you add common functionality without reinventing the wheel.

Tip: If an action has multiple versions (e.g., @v4, @v5), it’s usually best to stick to the latest LTS or stable version unless your project requires otherwise.

Free Usage Limits

GitHub Actions is free to use, but there are some limits depending on your plan.

Public Repositories
- Unlimited usage for free.
- Perfect for open-source projects.
Private Repositories
- 2,000 minutes per month of runtime for free.
- 500 MB of storage included.

For most hobby projects or small teams, the free tier is more than enough.

Trying It Out

To understand how it works, I created a simple workflow that just prints a message whenever I push or open a PR.

Steps:

Create a new empty repository.
Inside it, create a .github/workflows/ directory.
Add the following YAML file:

# .github/workflows/hello.yml
name: Hello GitHub Actions

on:
  push:
  pull_request:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
      - name: Say Hello
        run: echo "Hello from GitHub Actions!"

Then, push this repo to GitHub.
You can see the workflow run under the Actions tab in your repository.

Example repo: actions-tutorial

Conclusion

GitHub Actions is a powerful CI/CD platform built right into GitHub.
It can automate much more than just deployment:

Testing
Code quality checks
Security scans
Scheduled jobs
Notifications
Issue/PR management

In other words, it can automate your entire development workflow.

If you have creative or unusual use cases for GitHub Actions, I’d love to hear them!

References

My Personal Git Workflow Rules for Portfolio Projects

ak0047 — Mon, 18 Aug 2025 11:57:15 +0000

Introduction

As I started publishing my personal web app projects as part of my portfolio, I decided to create a Git workflow rule for personal development.

In this post, I’ll summarize the rules I came up with for my own projects.

Why I Decided to Set Git Rules

Up until now, I hadn’t often joined projects with well-defined Git workflows, and in my personal projects, I hadn’t really set any rules either.

But since I’m publishing repositories as portfolio pieces, branches and commit history will be visible too. That made me realize: I need a workflow that’s easy for others to understand and easy for me to manage.

My Workflow Rules

Here’s what I decided.

Branching

I’ll structure branches as follows:

main: always stable and deployable
feature/*: for adding new features
- e.g., feature/login-page
fix/*: for bug fixes
- e.g., fix/api-endpoint
docs/*: for documentation updates
- e.g., docs/update-readme

This is inspired by GitHub Flow.

There’s also Git Flow by Vincent Driessen, but that’s typically used in larger, long-term projects.

Commit Messages

I’ll write commit messages in English, following Conventional Commits.

Message Format

<type>: <short description>

Types I use

feat: add a new feature
fix: bug fix
docs: documentation only
style: formatting (no code changes)
refactor: refactoring
chore: configs, dependencies, etc.

Examples

feat: add weather API integration
fix: correct date formatting issue
docs: add system architecture diagram to README
style: apply prettier formatting
refactor: extract API call into separate module
chore: update dependencies

Commit Timing

Here’s when I commit:

First commit:
After setting up the initial folder structure and dependencies (e.g., package.json).

Second commit:
Once the app has taken some shape.

After that:
Commit by feature or task unit.

This means there’s usually a gap between the first and second commit. That’s intentional: in the early stages I tend to experiment a lot with architecture and setup, and I don’t want those messy trial-and-error steps cluttering the history.

Summary

For my personal portfolio repositories, I decided to follow these rules:

Branching: GitHub Flow style
Commit messages: Conventional Commits + English
Commit timing:
- First commit: when the environment setup is ready
- Second commit: when the app has taken shape
- Afterwards: per task or feature

I’ll start with this workflow and adjust or expand it as needed.

If you have suggestions for even better Git practices, I’d love to hear them!

Managing Multiple Environments in AWS SAM (dev/prod)

ak0047 — Wed, 13 Aug 2025 10:49:18 +0000

Introduction

Separating development and production environments is essential—even for personal projects.

With AWS SAM (Serverless Application Model), it’s fairly easy to manage multiple environments by tweaking your template and configuration files.

In this post, I’ll walk you through the exact method I use to separate and deploy dev and prod environments using AWS SAM.

Why Separate Environments?

Here’s why I always create separate environments—even for solo projects:

Prevent production issues before they happen
Reflect real-world projects where multi-environment setups are the norm

This approach makes development, testing, and deployment safer and more realistic—especially when you're preparing for actual client work.

How to Manage Environments in AWS SAM

By combining a few key features in AWS SAM, you can clearly separate deployments by environment.

1. Use `Parameters` and `!Sub` for Environment-Aware Naming

In your template.yaml, use the Parameters section to define environment-specific values. Then apply those values dynamically with !Sub.

# template.yaml
Parameters:
  Environment:
    Type: String
    Default: dev

Resources:
  WeatherAppFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub weather-function-${Environment}
      CodeUri: lambdas/function/
      Handler: app.lambda_handler
      Runtime: python3.13

By passing dev or prod as a parameter, the resource names (like Lambda functions) are automatically environment-specific.

2. Use `Globals` for Shared Settings

Common configurations across all Lambda functions—such as timeout or runtime—can be set using the Globals section:

# template.yaml
Globals:
  Function:
    Timeout: 30
    Runtime: python3.13

This helps you avoid repeating boilerplate settings across multiple functions.

3. Configure `samconfig.toml` per Environment

samconfig.toml is a config file SAM reads when deploying. You can define environment-specific sections like [dev.deploy.parameters] and [prod.deploy.parameters].

# samconfig.toml
[dev.deploy.parameters]
stack_name = "weather-app-dev"
s3_prefix = "weather-app-dev"
region = "ap-northeast-1"
parameter_overrides = "Environment=dev"

[prod.deploy.parameters]
stack_name = "weather-app-prod"
s3_prefix = "weather-app-prod"
region = "ap-northeast-1"
parameter_overrides = "Environment=prod"

parameter_overrides passes values to the Parameters defined in template.yaml, enabling you to reuse the same template across multiple environments.

To deploy with the appropriate config:

# Deploy to development
sam deploy --config-env dev

# Deploy to production
sam deploy --config-env prod

Tip: Run sam deploy --guided the first time to generate a samconfig.toml file interactively.

How Many Environments Should You Use?

In my case, I keep it simple with two environments:

dev: for development and testing changes
prod: for production-ready deployments

Unless your app handles sensitive data or requires complex staging, this setup is usually enough for personal projects.

Be mindful of cost—each environment may create its own resources.

Final Thoughts

Even in serverless projects using AWS SAM, environment management is crucial.
Starting with clear separation between dev and prod will save you headaches later.

If you have tips for structuring or automating environments in AWS SAM, I’d love to hear them!

Forem: ak0047

Why React Feels So Confusing: My Observations

Introduction

Reason 1: Multiple Layers of Processing

Reason 2: Triggers for Code Execution Are Hard to Identify

Reason 3: Display Elements and Logic Are Mixed

Summary

💬 How about you?

Essential Shell Scripting Basics You Should Know First

Introduction

Basic Rules of Shell Scripts

The .sh Extension Is a Convention

Write a Shebang (#!) on the First Line

One Command Per Line

Comments Use #

Working with Variables

Defining Variables

Referencing Variables

Single vs Double Quotes

Common Control Structures

Conditional Branching (if / case)

if Statements

case Statements

Loops (for / while)

for Loop

while Loop

Functions

Shell-Specific Concepts

Exit Status

Command Substitution

Pathname Expansion (Globbing)

Running Shell Scripts Manually

Method 1: Execute Directly (Recommended)

Method 2: Pass to the Shell

Conclusion

💬 How about you?

I Built a Curl Command Generator App with React

Introduction

Overview

How to Use

Use Cases

Features

Technologies Used

Frontend

Backend

System Architecture

Why I Built This

What I Focused On

Reusing Code from .gitignore Checker

Implementing Dark Mode

Testing Generated Curl Commands

Using AWS CDK

What I Learned

Reusing Code Matters

You Learn a Lot by Actually Using What You Built

Future Plans

New Features

Deployment Automation

Closing Thoughts

▶ App

▶ GitHub Repository

💬 How about you?

What’s the Difference Between [ ] and [[ ]] in Shell Scripts?

Introduction

The Basic Difference Between [ ] and [[ ]]

Common Conditional Expressions Compared

1. Checking File or Directory Existence

2. String Comparison

3. Numeric Comparison

4. AND / OR Conditions

5. Pattern Matching

How to Choose

Pick One Style and Stick to It

1. Better readability and maintainability

2. Prevent incompatibility across shells

3. Avoid subtle bugs

Summary

Closing Thoughts

💬 How about you?

Understanding the Asterisk (*) in Python Function Arguments

The `.sh` Extension Is a Convention

Write a Shebang (`#!`) on the First Line

Comments Use `#`

Reusing Code from `.gitignore` Checker

The Basic Difference Between `[ ]` and `[[ ]]`

When to Use `*` and `**`

`*args`: Collecting Multiple Positional Arguments

`kwargs`: Collecting Keyword Arguments as a Dictionary**

The Lone `*`: Forcing Keyword-Only Arguments

Argument Unpacking with `*` and `**`

Use `is` / `has` for Boolean Variables or Functions