Zhenguo Zhang's Blog

[R] Understanding position_dodge() and position_dodge2() in ggplot2

Sun, 30 Aug 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/08/30/r-understanding-position-dodge-and-position-dodge2-in-ggplot2/ -

In ggplot2, when displaying grouped data along categorical axes (such as grouped bar charts, boxplots, or error bars), horizontal dodging is used to prevent elements from overlapping at each categorical position. ggplot2 provides two primary dodging position functions: position_dodge() and position_dodge2().

In this post, we will explore:

How the width parameter in position_dodge() interacts with the parent geom’s width.
The core differences between position_dodge2() and position_dodge(), including why changing width in position_dodge2() often has no visual effect.
How preserve = "single" behaves when elements of a group variable are missing at a given x-axis level.

Definition of Terms

To keep our explanations clear and consistent throughout this post, we define two key concepts:

x-axis level: The discrete value or category on the x-axis. In our examples using mtcars, the x-axis level is cyl (with levels 4, 6, and 8).
group variable: The variable that divides items into subgroups at each x-axis level, typically mapped to an aesthetic like fill or color. In our examples, the group variable is gear (with levels 3, 4, and 5).
dodged elements: The individual visual marks (e.g. bars) corresponding to each level of the group variable at a specific x-axis level.

library(ggplot2)
library(patchwork)

1. The `width` Parameter in `position_dodge()`

What does `width` control?

In position_dodge(width = ...), width specifies the total dodging span (interval) on the x-axis into which all dodged elements for a given x-axis level are arranged side-by-side.

By default, if you do not explicitly supply width to position_dodge(), it inherits its value from the parent geom (e.g., geom_bar() defaults to width = 0.9).

Interaction between `geom_bar(width)` and `position_dodge(width)`

geom_bar(width = ...): Sets the total physical width allocated to the bars at each x-axis level. The individual bar width is derived by dividing this value by the number of elements at that x-axis level.
position_dodge(width = ...): Sets the total span on the x-axis across which the center positions of the dodged elements are calculated and spaced.

Both parameters use x-axis coordinate units (where the distance between adjacent discrete x-axis levels is 1.0).

Let’s examine how varying both parameters affects the layout using the mtcars dataset (plotting mean mpg across x-axis level cyl, with group variable gear mapped to fill):

# Base plot configuration
base_p <- ggplot(mtcars, aes(x = factor(cyl), y = mpg, fill = factor(gear))) +
  labs(x = "Cylinders (x-axis level)", y = "Mean MPG", fill = "Gear (group variable)") +
  theme_minimal(base_size = 11)

# Case 1: Default matching widths (0.9 / 0.9)
# Bars touch neatly within each x-axis level
p1 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.9, 
    position = position_dodge(width = 0.9)
  ) +
  ggtitle("1. Matching widths (0.9 / 0.9)", subtitle = "Bars touch neatly within each x-axis level")

# Case 2: geom_bar width (0.5) < dodge width (0.9)
# Dodging span is 0.9, but bars are narrower -> gaps appear between bars
p2 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.5, 
    position = position_dodge(width = 0.9)
  ) +
  ggtitle("2. geom_bar(0.5) < dodge(0.9)", subtitle = "Gaps created between dodged elements")

# Case 3: geom_bar width (0.9) > dodge width (0.5)
# Dodging span is narrower than bar widths -> bars overlap
p3 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.9, 
    position = position_dodge(width = 0.5)
  ) +
  ggtitle("3. geom_bar(0.9) > dodge(0.5)", subtitle = "Dodged elements overlap")

# Case 4: Both changed to 0.6
# Group as a whole is narrower, bars touch, larger separation between x-axis levels
p4 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    width = 0.6, 
    position = position_dodge(width = 0.6)
  ) +
  ggtitle("4. Both set to 0.6", subtitle = "Compact cluster, wider space between x-axis levels")

(p1 | p2) / (p3 | p4)

As demonstrated: - Increasing width in geom_bar() increases the individual width of dodged elements at that x-axis level. - Increasing width in position_dodge() increases the total dodging span across which elements are spread. - When both values are equal, the dodged elements within each x-axis level touch each other without overlapping or leaving gaps.

2. Differences Between `position_dodge2()` and `position_dodge()`

While position_dodge() was originally designed for simple geoms with fixed-width positions (like geom_bar and geom_col), position_dodge2() was introduced to handle geoms with variable widths or explicit intervals (xmin to xmax), such as geom_boxplot(), geom_rect(), and geom_linerange().

Key Differences:

Boundary-Based Packing vs. Fixed Slot Offsets:
- position_dodge() divides the total dodge width at an x-axis level into fixed slots and places each level of the group variable into its designated slot.
- position_dodge2() packs elements (for different levels of the group variable) sequentially side-by-side using the bounding boxes of the geoms.
The width Parameter Has No Visual Effect in position_dodge2() with Bars:
- Because position_dodge2() arranges bars based on their pre-computed bounding intervals rather than calculating center slot offsets from a dodge span, changing width in position_dodge2() produces no change in the plot output when bar widths are already defined by the parent geom.
- Bar widths must be controlled directly via geom_bar(width = ...).
Built-in padding and reverse Support:
- padding: Adds proportional space between dodged elements at the same x-axis level without requiring manual mismatch of geom and dodge widths.
- reverse = TRUE: Reverses the left-to-right plotting order of the group variable without needing to alter factor levels.

Demo: `width` Has No Effect in `position_dodge2()`

Below, we compare position_dodge2(width = 0.3) against position_dodge2(width = 0.9). Notice that the two plots are completely identical:

# Changing width in position_dodge2 produces identical output
p_d2_w03 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(width = 0.3)
  ) +
  ggtitle("position_dodge2(width = 0.3)", subtitle = "Width parameter has no visual effect")

p_d2_w09 <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(width = 0.9)
  ) +
  ggtitle("position_dodge2(width = 0.9)", subtitle = "Identical layout to width = 0.3")

p_d2_w03 | p_d2_w09

Creating Spacing with `padding` and Reversing Order with `reverse`

Instead of altering width, position_dodge2() provides the padding and reverse parameters:

# Using padding and reverse in position_dodge2
p_dodge2_demo <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(padding = 0.2, reverse = TRUE)
  ) +
  labs(
    title = "position_dodge2(padding = 0.2, reverse = TRUE)",
    subtitle = "Built-in bar padding and reversed order of group variable"
  )

p_dodge2_demo

3. Handling Missing Elements with `preserve = "single"`

A significant functional difference between position_dodge() and position_dodge2() occurs when certain levels of the group variable are absent at a specific x-axis level.

Let’s inspect the count of observations across cyl (x-axis level) and gear (group variable) in mtcars:

table(mtcars$cyl, mtcars$gear)

##    
##      3  4  5
##   4  1  8  2
##   6  2  4  1
##   8 12  0  2

At the x-axis level cyl = 8, the group variable gear contains observations for gears 3 (12 cars) and 5 (2 cars), but gear = 4 is completely missing (0 cars).

When we set preserve = "single" to ensure that all individual bar widths remain uniform across all x-axis levels:

position_dodge(preserve = "single"): Retains fixed slot assignments. Because gear = 4 is missing at cyl = 8, it leaves a blank gap in the middle where gear = 4 would normally reside.
position_dodge2(preserve = "single"): Preserves individual bar width while re-centering the remaining dodged elements, packing them side-by-side without leaving an empty gap.

# position_dodge with preserve = "single"
p_dodge_single <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge(preserve = "single")
  ) +
  labs(
    title = "position_dodge(preserve = 'single')",
    subtitle = "Leaves an empty gap for missing gear = 4 at cyl = 8"
  )

# position_dodge2 with preserve = "single"
p_dodge2_single <- base_p +
  geom_bar(
    stat = "summary", 
    fun = "mean", 
    position = position_dodge2(preserve = "single")
  ) +
  labs(
    title = "position_dodge2(preserve = 'single')",
    subtitle = "Re-centers remaining elements (no gap at cyl = 8)"
  )

# Side-by-side comparison
p_dodge_single | p_dodge2_single

Note that if one sets preserve = “total”, then you would not see any difference, because the bars are re-stretched to ensure the bars from each categorical level occupy all the width assigned to that level.

Summary

Feature	`position_dodge()`	`position_dodge2()`
Primary Use Cases	Simple 1D fixed-width geoms (`geom_bar`, `geom_col`)	Interval & variable-width geoms (`geom_boxplot`, `geom_rect`, `geom_linerange`) and bars
Role of `width` Parameter	Sets total dodging span across each x-axis level	Has no visual effect on bars with predefined geom width
Missing Elements (`preserve="single"`)	Leaves empty slot / gap at the missing level	Re-centers remaining dodged elements together
Padding Between Elements	Manual (`geom_bar(width) < position_dodge(width)`)	Built-in via `padding = ...` argument
Reverse Plotting Order	Requires re-leveling the group variable	Built-in via `reverse = TRUE` argument

- https://fortune9.netlify.app/2026/08/30/r-understanding-position-dodge-and-position-dodge2-in-ggplot2/ -

[Linux] Handling grep Exit Codes in Scripts with set -e and set -o pipefail

Sat, 15 Aug 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/08/15/linux-handling-grep-exit-codes-in-scripts-with-set-e-and-set-o-pipefail/ -

When writing robust Bash scripts, it is common best practice to enable strict mode options:

1
2

set -e          # Exit immediately if a command exits with a non-zero status
set -o pipefail # Pipeline exit status is the value of the last (rightmost) command to exit with non-zero status

While these settings prevent errors from silently propagating, they frequently cause unexpected script failures when working with grep.

In this post, we will explore why grep exit codes break strict shell scripts, demonstrate the problem with clear examples, and detail four practical solutions to address it.

Understanding `grep` Exit Codes

Unlike many Unix tools where any non-zero exit code indicates a fatal error, grep uses exit codes to communicate search outcomes:

Exit Code 0: One or more matching lines were found.
Exit Code 1: No matching lines were found (a valid, expected outcome in many workflows).
Exit Code 2 (or >1): An error occurred (e.g., syntax error in regex, missing file, permission denied).

Because shell safety directives like set -e treats any non-zero status as a command failure, grep returning 1 when no matches are found will cause the shell script to abort immediately. Similarly, set -o pipefail causes pipelines containing grep to fail if no lines match the query.

The Problem in Action

Example 1: Direct `grep` under `set -e`

Consider a script designed to process error logs:

#!/usr/bin/env bash
set -e

echo "Starting log analysis..."

# Try to find warnings in the log
grep "WARNING" server.log > warnings.txt

echo "Analysis complete!"

If server.log contains no lines matching "WARNING", grep finishes cleanly without printing anything and returns an exit code of 1.

Under set -e, the shell interprets this 1 as a fatal execution failure. The script exits instantly at the grep line—warnings.txt may be left empty, and "Analysis complete!" is never printed!

Example 2: Pipelines under `set -o pipefail`

Now consider a pipeline processing input:

#!/usr/bin/env bash
set -euo pipefail

# Count how many critical errors occurred
CRITICAL_COUNT=$(cat app.log | grep "CRITICAL" | wc -l)

echo "Critical errors count: ${CRITICAL_COUNT}"

Without set -o pipefail, the pipeline exit status would be that of wc -l (0), hiding the fact that grep returned 1.

However, with set -o pipefail, grep’s exit code 1 propagates as the failure status of the entire pipeline. As a result, set -e terminates the script before CRITICAL_COUNT is assigned.

Solutions

Here are four effective ways to safely handle grep when set -e or set -o pipefail is active.

Solution 1: Append `|| true` (or `|| :`)

The simplest and most common quick fix is using the OR operator (||) followed by true (or the shell built-in :):

`1`	`grep "WARNING" server.log > warnings.txt \|\| true`

How it works

If grep succeeds (exit code 0), the right side of || is ignored. If grep exits with code 1 (or 2), the || true executes, returning exit code 0 and allowing set -e to continue.

Pros & Cons

Pros: Simple, concise, one-liner fix.
Cons: It masks all non-zero exit codes, including code 2 (e.g., missing file or invalid regex pattern).

Solution 2: Test `$?` or Use Conditional Statements

If you want to distinguish between “no matches found” (code 1) and a real error (code 2), you can check the exit status explicitly.

Approach A: Direct `if` statement

In Bash, commands tested inside if statements or if grep ... conditions do not trigger set -e:

if grep "WARNING" server.log > warnings.txt; then
    echo "Warnings were found."
else
    echo "No warnings found (or grep error)."
fi

Approach B: Preserving and evaluating `$?`

To specifically handle exit code 1 vs 2:

# Capture exit status without triggering set -e
grep "WARNING" server.log > warnings.txt || status=$?

case ${status:-0} in
    0)
        echo "Found matches."
        ;;
    1)
        echo "No matches found. Continuing execution..."
        ;;
    *)
        echo "An error occurred with grep (exit code ${status}). Exiting..." >&2
        exit "${status}"
        ;;
esac

Pros & Cons

Pros: Precise error handling; preserves actual error detection for code 2.
Cons: Slightly more verbose.

Solution 3: Use `awk` for Filtering

If you are filtering text in a pipeline under set -o pipefail, awk can serve as a robust drop-in replacement for grep.

Unlike grep, awk returns exit code 0 when matching zero lines (unless an unhandled script/syntax error occurs inside awk itself).

Replacing `grep` with `awk`:

# Instead of: grep "PATTERN" input.txt
awk '/PATTERN/' input.txt > output.txt

# Instead of: cat log.txt | grep "CRITICAL" | wc -l
CRITICAL_COUNT=$(awk '/CRITICAL/' log.txt | wc -l)

You can even perform the counting directly in awk:

`1`	`CRITICAL_COUNT=$(awk '/CRITICAL/ {count++} END {print count+0}' log.txt)`

Pros & Cons

Pros: Eliminates exit code 1 issues entirely in pipelines while still returning non-zero on syntax or file access errors.
Cons: Syntax is slightly longer than standard grep.

Solution 4: Temporary Toggling of `set +e` or `set +o pipefail`

If you have a block of commands where grep exit codes should not terminate the script, you can temporarily disable strict checking and re-enable it afterwards.

# Disable strict flags temporarily
set +e
set +o pipefail

grep "WARNING" server.log > warnings.txt
GREP_EXIT=$?

# Re-enable strict flags
set -e
set -o pipefail

if [ "${GREP_EXIT}" -eq 0 ]; then
    echo "Warnings found."
elif [ "${GREP_EXIT}" -eq 1 ]; then
    echo "No warnings found."
else
    echo "Grep failed with error code ${GREP_EXIT}." >&2
    exit "${GREP_EXIT}"
fi

Pros & Cons

Pros: Gives explicit control over scope and allows inspecting exit codes without modifying the pipeline syntax.
Cons: Requires remembering to restore set -e / set -o pipefail.

Summary Comparison

Method	Syntax	Handles Code 1 (No Match)	Catches Code 2 (Errors)?	Best Used For
`\|\| true`	`grep ... \|\| true`	Yes	❌ Masked as 0	Quick scripts, optional filters
Conditional (`if` / `$?`)	`grep ... \|\| status=$?`	Yes	✅ Yes	Safe scripts needing exact error checks
`awk` Filtering	`awk '/pattern/' file`	Yes	✅ Yes	Pipelines with `set -o pipefail`
Flag Toggling	`set +e ... set -e`	Yes	✅ Yes	Complex blocks or multi-command sections

Conclusion

Understanding how grep exit codes interact with shell strict mode (set -e and set -o pipefail) will save you hours of debugging mysterious script exits (The main reason I write this post). Depending on your security and logging needs, using || true works well for quick tasks, while if/$? status checking or awk pipeline filtering offers the most robust solution for production scripts.

- https://fortune9.netlify.app/2026/08/15/linux-handling-grep-exit-codes-in-scripts-with-set-e-and-set-o-pipefail/ -

[R] Environment Variables in R Shiny-Server Container: Problem and Solutions

Sat, 15 Aug 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/08/15/r-environment-variables-in-r-shiny-server-container/ -

When dockerizing an R Shiny application hosted via Shiny Server (built from shiny server docker image https://hub.docker.com/r/rocker/shiny), a common issue developers face is that environment variables set via ENV instructions in the Dockerfile (or passed at runtime via docker run -e) are completely missing inside the R Shiny app.

For example, if you set the following environment variable in your Dockerfile:

`1`	`ENV SHOULD_IN_SHINY="From dockerfile"`

When your app launches and runs Sys.getenv("SHOULD_IN_SHINY"), it returns an empty string "" instead of "From dockerfile". This is not a problem with Docker itself, but rather a consequence of how Shiny Server spawns R worker processes.

In this post, we will look into the root cause behind this behavior in Shiny Server and demonstrate the two recommended solutions to correctly expose environment variables to your R Shiny workers.

The Root Cause: How Shiny Server Spawns R Processes

The reason environment variables do not carry over to your R session lies in how Shiny Server executes R worker processes inside the container.

Shiny Server runs as a system service (typically as root or shiny). When launching an app instance, it re-executes R as the shiny unprivileged user using su. Specifically, the execution call combines two mutually exclusive flags:

`1`	`su shiny --login --preserve-environment -c "... R ..."`

Let’s break down what these flags request from su:

--login (-l): Starts a login shell. This intentionally resets the environment to a minimal whitelist (HOME, PATH, USER, TERM, etc.) and sources system startup profiles (/etc/profile, ~/.profile).
--preserve-environment (-p): Explicitly asks su to keep the current environment inherited from the caller (which includes Docker’s ENV variables).

Because Linux’s su utility cannot honor both conflicting behaviors, it chooses --login and prints a warning:

`1`	`su: ignoring --preserve-environment, it's mutually exclusive with --login`

Note: This warning is emitted by Shiny Server’s underlying process execution call, not by the R app itself. Attempting to suppress or patch it requires modifying and rebuilding Shiny Server C++ code, which is rarely practical.

Because the login shell wins, all custom environment variables passed to the container via ENV or docker run are wiped before R ever starts.

Solutions

Since patching Shiny Server is unnecessary, we can utilize the natural extension points provided by the login shell or R itself.

Solution 1: Use `~/.profile` (Recommended for User-Level Shell Vars)

Since --login causes the shell to source ~/.profile for the shiny user, we can write our environment variables to /home/shiny/.profile during the Docker build phase.

In your Dockerfile:

1
2

# Append environment variable to the shiny user's profile
RUN echo 'export SHOULD_IN_SHINY="From dockerfile"' >> /home/shiny/.profile

When Shiny Server executes su shiny --login ..., the login shell will read /home/shiny/.profile and load SHOULD_IN_SHINY into the environment right before starting the R process.

Solution 2: Use `~/.Renviron` (Recommended for R-Specific Configs)

Alternatively, R automatically inspects and loads ~/.Renviron on startup, right after the shell environment is initialized.

~/.Renviron is purpose-built for R:

Scoped strictly to R processes.
Does not use shell export keywords or $ variable expansions.
Uses simple KEY=value key-value pairs.

In your Dockerfile, set up /home/shiny/.Renviron:

1
2
3

# Set up .Renviron for the shiny user
RUN echo 'SHOULD_IN_SHINY="From dockerfile"' >> /home/shiny/.Renviron \
    && chown shiny:shiny /home/shiny/.Renviron

In your Shiny app (app.R or server.R), you can access it reliably:

1
2

should_in_shiny <- Sys.getenv("SHOULD_IN_SHINY")
# Returns: "From dockerfile"

Summary

The Problem: Shiny Server calls su shiny --login --preserve-environment, causing su to discard inherited environment variables (such as Docker ENV) in favor of a clean login shell.
Solution 1 (~/.profile): Append export KEY="value" to /home/shiny/.profile in your Dockerfile.
Solution 2 (~/.Renviron): Append KEY="value" to /home/shiny/.Renviron in your Dockerfile.

Both approaches integrate seamlessly with Docker builds and ensure your Shiny application receives all required configuration variables cleanly.

- https://fortune9.netlify.app/2026/08/15/r-environment-variables-in-r-shiny-server-container/ -

[Nextflow] Nextflow AWS options: where they take effect

Sat, 25 Jul 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/07/25/nextflow-aws-options-where-they-take-effect/ -

When running Nextflow pipelines on AWS Batch, you might expect that changing S3 configuration options under aws.client.* (such as maxConnections) would tune the data transfer performance during task input/output staging. However, Nextflow’s documentation is unclear about how these options affect S3 data transfer. You might change parameters like aws.client.maxConnections only to find they have absolutely no effect on input data staging by Nextflow tasks.

By leveraging AI’s power to analyze the Nextflow codebase, I finally dug into the code and figured out why: S3 data transfers actually run across two entirely different environments—the Head Node running Nextflow and the EC2 Execution Instances (started by AWS Batch for running individual tasks).

Note that this post was written based on the information given by AI agent, so please let me know if you find any mistakes or inaccuracies in the content. I will update the post accordingly.

The Two S3 Transfer Layers

Data transfer processes are divided into two separate groups based on different running machines:

Layer	Environment (Machine)	Run by	Governed by	Key Operations
Head Node Transfer	Head Node (Nextflow host)	Nextflow JVM (AWS SDK v2 CRT)	`aws.client.*`	`publishDir`, writing `.command.*`, `bin/` upload, gathering outputs
In-Container Staging	EC2 Instance (Batch container)	`aws s3` CLI / `s5cmd` (Classic)	`aws.batch.` + subset of `aws.client.`	Staging inputs, unstaging outputs

Note: Options set for one layer do not propagate to the other unless explicitly translated.

How Staging Works in Classic Mode

Normally, Nextflow writes the staging script from the head node, but the EC2 container does the actual staging work:

AwsBatchScriptLauncher embeds bash snippets into the .command.run script.
Inside the container, the Batch executor downloads the runner script: aws s3 cp .command.run - | bash.
The script defines download/upload functions (nxf_s3_download, nxf_s3_upload) using the container’s aws CLI.
Input files are staged: downloads=(...) lists files, and nxf_parallel runs transfers concurrently.
The container runs the user task.
Output files are unstaged: uploads=(...) runs to push results back to S3.

Which Options Reach the EC2 Container?

Most aws.client.* settings only configure the head node’s JVM S3 client and never reach the EC2 instance. The following options do not affect in-container staging in classic mode:

minimumPartSize, multipartThreshold
maxConnections, maxConcurrency, targetThroughputInGbps
maxDownloadHeapMemory, maxNativeMemory
maxErrorRetry, connectionTimeout, socketTimeout, proxy*

Instead, the only options that affect the EC2 instance’s S3 CLI transfers are those explicitly translated into CLI flags by S3BashLib:

Option	Source Scope	Effect on EC2 Instance / Staging Script
`maxParallelTransfers`	`aws.batch`	Caps concurrency in the `nxf_parallel` script function (default: 4)
`delayBetweenAttempts`	`aws.batch`	Controls the retry sleep duration in `nxf_cp_retry`
`maxTransferAttempts`	`aws.batch`	Sets retry count in `nxf_cp_retry` and defines `AWS_MAX_ATTEMPTS`
`cliPath`	`aws.batch`	Defines the path to the `aws` binary and sets the `--region` flag
`retryMode`	`aws.batch`	Injects the `AWS_RETRY_MODE` environment variable
`s5cmdPath`	`aws.batch`	Uses `s5cmd` instead of `aws s3` inside the container
`forceGlacierTransfer`	`aws.batch`	Adds `--force-glacier-transfer` to `aws s3 cp` downloads
`storageClass`	`aws.client`	Adds `--storage-class` to `aws s3 cp` uploads
`storageEncryption`	`aws.client`	Adds `--sse` to `aws s3 cp` uploads
`storageKmsKeyId`	`aws.client`	Adds `--sse-kms-key-id` to `aws s3 cp` uploads
`s3Acl`	`aws.client`	Adds `--acl` to `aws s3 cp` uploads
`requesterPays`	`aws.client`	Adds `--request-payer requester`
`debug`	`aws.client`	Appends the `--debug` flag to CLI calls

Controlling Transfer Rates

A common issue on small EC2 instances is memory or network exhaustion during staging. Currently, Nextflow does not provide an option to inject arbitrary CLI flags (such as --max-bandwidth) into the generated S3 CLI commands.

If you need fine-grained transfer rate control to prevent instances from crashing, you must configure this outside of Nextflow (for instance, via custom S3 configurations or instance-level limits on the execution host).

A Note on Fusion file system

When Fusion is enabled, no aws s3 CLI staging occurs inside the container. Fusion mounts S3 directly as a POSIX filesystem on the EC2 instance and does its own transfers. Staging is therefore governed by Fusion/wave settings instead of standard Nextflow aws S3 CLI configs.

- https://fortune9.netlify.app/2026/07/25/nextflow-aws-options-where-they-take-effect/ -

[AI] Maximizing Your Claude Code Productivity: Key Takeaways and Resources

Sat, 18 Jul 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/07/18/maximizing-your-claude-code-productivity/ -

I recently finished the LinkedIn Learning course Maximize Your Claude Code Programming Productivity. It was packed with actionable strategies, advanced configurations, and architectural paradigms that elevate coding with AI from simple code generation to advanced project execution.

To help me and others revisit these key concepts, I’ve summarized the core takeaways, tools, and resources from the course.

1. Blended Project Management & Spec-Driven Development (SDD)

One of the biggest paradigm shifts in AI-assisted development is the transition from sequential to blended project management.

Traditionally, product development follows a linear sequence: Product Goal → Design → Engineering

With AI agents, these boundaries blur. Product management, design, and engineering run in tight, parallel feedback loops.

Learn more about this paradigm shift in Anthropic’s blog post: Product Management on the AI Exponential.

Spec-Driven Development (SDD)

SDD is a methodology that emphasizes using machine-readable or highly structured specifications to guide the AI agent’s development process. Instead of prompting the agent ad-hoc, you write a thorough specification first.

Several open standards exist for organizing these specifications:

Kiro Spec Doc: A structured spec format designed for clarity. Kiro Docs
GitHub Spec-Kit: A toolkit for creating structured project specs. GitHub spec-kit
Open Spec: A collaborative standard for open-source project specs. OpenSpec

Pro-Tip: You can create a custom agent skill based on these SDD principles to help automate draft spec generation for your new projects.

2. Agent & Subagent Architecture

As tasks become more complex, a single agent’s context window can quickly become cluttered, leading to degradation in reasoning.

Spawning Subagents

A main agent can spawn multiple subagents to handle specific subtasks concurrently or in isolation.

Why use subagents?

Preserve Context: Keep the main agent’s session clean. All the verbose exploration, testing, and debugging output happens in the subagent’s session.
Enforce Constraints: Restrict the tools available to a subagent (e.g., read-only access for research).
Specialized Behavior: Tailor system prompts to a narrow domain.
Control Costs: Route simpler subtasks to cheaper, faster models (like Claude 3.5 Haiku / Gemini Flash Lite) while keeping the main coordinator on a more capable model.

Subagent Configuration

For standard Claude Code, custom subagent configurations are stored in ~/.claude/agents/ in markdown format. More details are available in the Claude Code Sub-agents Documentation.

For Google’s Antigravity CLI (AGY), you can define subagents using an agent.md file in two scopes:

Workspace-Specific: {workspace}/.agents/agents/{agent_name}/agent.md
Global Scope: ~/.gemini/config/agents/{agent_name}/agent.md

3. Extending Claude Code with MCP

The Model Context Protocol (MCP) allows Claude Code to securely connect with external tools, APIs, and data sources. Here are some of the most useful MCP servers covered in the course:

GitHub MCP Server: Manage repositories, create and search issues, handle pull requests, and perform code reviews directly from the terminal.
Datadog MCP Server: Monitor application health, query logs, trigger metrics alerts, and analyze performance data.
Linear MCP Server: Seamlessly sync development tasks, create issues, update task statuses, and assign tickets.
Notion MCP Server: Organize documentation, update pages, search notes databases, and collaborate with your team.

4. Fine-Tuning Agent Skills

Skills allow you to package procedural knowledge, workflows, and templates for the agent. Sometimes you want fine-grained control over how the agent uses these skills:

disable-model-invocation: true: The skill is loaded and visible to the user, but the agent cannot invoke it automatically. The user must explicitly tell the agent to run it.
user-invocable: false: Hides the skill from the user interface, but allows the agent to invoke it when it determines it is necessary.

5. Routines, Loops, and Hooks

Automation in Claude Code goes beyond individual prompts through loops and hook lifecycles.

Goal-Driven Loops (`/goal`)

You can use the /goal command to specify a target outcome. The agent runs in a continuous loop, inspecting command outputs, writing code, and self-correcting until the objective is achieved.

Rule of thumb: Keep the goal specific, achievable, and measurable (e.g., “Fix all linting errors in the src/ directory and ensure tests pass”).

Lifecycle Hooks

Hooks are user-defined shell commands, HTTP endpoints, or LLM prompts that execute automatically at specific lifecycle points.

Documentation: See Claude Code Hooks Guide.
Example Use Case: You can set up a hook that intercepts commands (e.g., validating critical operations before executing an rm command or running a test suite before git commits).

Summary Cheat Sheet

Feature	Standard Claude Code	Antigravity CLI (Gemini)
Subagents Path	`~/.claude/agents/`	`{workspace}/.agents/agents/` `~/.gemini/config/agents/`
Goal Command	`/loop` or `/goal`	`/goal`
Hooks	`https://code.claude.com/docs/en/Hooks`	Supported via hooks framework

By incorporating Spec-Driven Development and delegating tasks to specialized subagents, we can write cleaner, more maintainable code while staying in control of the project lifecycle.

- https://fortune9.netlify.app/2026/07/18/maximizing-your-claude-code-productivity/ -

[git] Git Worktree: Working on Multiple Branches Simultaneously

Sat, 27 Jun 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/06/27/git-worktree-working-on-multiple-branches-simultaneously/ -

Have you ever found yourself deep in a feature branch, with multiple uncommitted changes, only to be interrupted by a critical bug report on main?

Traditionally, you had two choices:

Stash and Switch: Run git stash, switch branches, fix the bug, commit, switch back, and run git stash pop. This context-switching can disrupt your focus and break active local builds.
Clone Again: Clone the repository to another folder entirely. This wastes disk space and time, duplication of the object database, and leaves you managing separate local repositories.

Fortunately, Git provides a third, elegant solution: git worktree. This feature allows you to attach multiple working directories (worktrees) to a single local repository, allowing you to checkout and work on different branches concurrently.

Git Branch vs. Git Worktree

Here is how Git Worktree stacks up against standard branch switching and multiple repository clones:

Feature	Standard Git Branch (Single Checkout)	Git Worktree (Multiple Checkouts)	Multiple Clones
Active Branches	Only one branch can be checked out at a time.	Multiple branches checked out simultaneously in different folders.	Multiple branches in different folders.
Git Database (`.git`)	Shared single instance.	Shared single instance (all worktrees point to the same main `.git` database).	Independent copies (disjoint history and refs, duplicates database).
Disk Space	Minimal.	Minimal (only checks out the files needed for each directory).	High (each clone duplicates the object database).
Local Stashing Required	Yes, if you have uncommitted work.	No; just open a new folder for the hotfix while keeping your feature work in progress.	No.
Best For	Sequential task progression.	Concurrent tasks (e.g., hotfixes, reviewing PRs, running tests in background).	Separate forks or independent repos.

How Git Worktree Works

Rather than duplicating the entire Git history and configuration, git worktree sets up a main repository with additional linked checkouts. Each worktree directory contains its own files and a special .git file that points back to the main repository’s .git database.

Hands-On: Working with a Mock Repo

Let’s walk through a complete, hands-on workflow to see git worktree in action.

Step 1: Create a Mock Repository

First, we will set up a main repository with an initial commit:

# Create and initialize the project
mkdir my-project
cd my-project
git init

# Add a README and commit
echo "# My Awesome Project" > README.md
git add README.md
git commit -m "Initial commit"

Step 2: Work on a Feature Branch

Let’s start working on a new feature branch feature/cool-stuff:

git checkout -b feature/cool-stuff
echo "Adding a cool feature..." > feature.txt
git add feature.txt
git commit -m 'added file feature.txt'
# make some new changes
echo "Adding new lines to feature.txt" >> feature.txt
# (Leave feature.txt uncommitted or unstaged, you will get error)

Step 3: Switch to a Hotfix using a Worktree

Suddenly, a critical bug is reported in main. Instead of stashing our uncommitted work in feature/cool-stuff, we can create a new worktree directory ../my-project-hotfix specifically for the hotfix:

1
2

# Create a new worktree and check it out to a new branch 'hotfix/bug-123' based on 'main'
git worktree add -b hotfix/bug-123 ../my-project-hotfix main

This creates a new folder my-project-hotfix outside of your current folder. Git automatically sets up the files, pointing them back to your main database.

Step 4: Fix the Bug in the Worktree

Navigate to your newly created hotfix directory and apply the fix:

cd ../my-project-hotfix

# Apply the fix and commit it
echo "Fixing critical issue..." > hotfix.txt
git add hotfix.txt
git commit -m "Fix critical production issue"

Because your feature work remains in my-project, it is completely untouched!

Step 5: Verify the Worktree Structure

Go back to your main repository directory to view the list of active worktrees:

1
2

cd ../my-project
git worktree list

This command will list all active directories linked to the repository:

1
2

/path/to/my-project          <commit-hash> [feature/cool-stuff]
/path/to/my-project-hotfix   <commit-hash> [hotfix/bug-123]

Step 6: Cleaning Up

Once you are done with the hotfix (e.g., after pushing it or merging it to main), you can safely remove the worktree folder.

Now let’s merge the hotfix back into main:

# In the hotfix worktree
git checkout main
git merge hotfix/bug-123
git push origin main # optional

In modern versions of Git, you can remove the worktree cleanly with:

`1`	`git worktree remove ../my-project-hotfix`

Alternatively, you can manually delete the folder and prune the references:

1
2

rm -rf ../my-project-hotfix
git worktree prune

Quick Reference Commands

Here are the most common git worktree commands:

Command	Description
`git worktree add <path> <branch>`	Create a new worktree at `<path>` checking out `<branch>`.
`git worktree add -b <new-branch> <path> <base-branch>`	Create a new worktree at `<path>` with a new branch `<new-branch>` tracking `<base-branch>`.
`git worktree list`	List all active worktrees linked to the repository.
`git worktree remove <path>`	Remove a worktree directory and clean up its references.
`git worktree prune`	Clean up worktree information for directories that were deleted manually.

Using git worktree keeps your workspace clean, speeds up switching between context, and optimizes your machine’s disk space. Give it a try on your next context switch!

- https://fortune9.netlify.app/2026/06/27/git-worktree-working-on-multiple-branches-simultaneously/ -

[R] How to Position the Legend Inside a Plot in ggplot2

Sat, 30 May 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/05/30/r-position-legend-inside-plot/ -

By default, ggplot2 places the legend outside the plot area (usually on the right). However, sometimes you may want to move the legend inside the plot to save space or improve the layout. This post explores how to achieve this using theme() parameters.

Example 1: Basic Usage of `legend.position`

The simplest way to move a legend inside the plot is by providing a numeric vector of length two to the legend.position argument in theme(). These coordinates represent the relative position within the plot panel, ranging from 0 to 1. Check the section on “Key Positioning Controls” at the end for a detailed explanation of the coordinate system.

library(ggplot2)

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  theme_bw() +
  theme(legend.position = c(0.8, 0.8))

Example 2: Fine-Tuning with Justification and Background

When you place a legend inside, you often need to adjust which part of the legend box aligns with your coordinates and handle the background if it obscures data.

legend.justification: Controls the anchor point of the legend box. For example, c("right", "top") means the top-right corner of the legend box will be placed at the specified coordinates.
legend.background: Use element_blank() to make the background transparent.

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  theme_bw() +
  theme(
    legend.position = c(1, 1),
    legend.justification = c("right", "top"),
    legend.background = element_blank()
  )

Example 3: Positioning in Faceted Plots

Moving the legend inside a faceted plot works similarly: the whole figure is considered as one plot for the coordinate system. You can use the coordinates to place it within one of the empty spaces or over a specific panel. In the following example, the legend is placed in the bottom center of the plot, and a background is added to improve readability:

ggplot(mtcars, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  facet_wrap(~am) +
  theme_bw() +
  theme(
    legend.position = c(0.5, 0.2),
    legend.background = element_rect(fill = "white", color = "grey80")
  )

Example 4: The “Empty Space” Trick for Faceted Plots

If you have a panel which doesn’t have any data, and then it is the perfect spot to place legend. To show this, the facet variable carb has only 3 values, and we will make a 2x2 facet grid. We will also remove the background and border of the legend. The following example shows this:

# Use 3 categories to leave the 4th spot in a 2x2 grid empty
mtcars_subset <- mtcars[mtcars$carb %in% c(1, 2, 4), ]

ggplot(mtcars_subset, aes(wt, mpg, color = factor(cyl))) +
  geom_point(size = 3) +
  facet_wrap(~carb, nrow = 2, ncol = 2) +
  theme_bw() +
  theme(
    # Coordinates c(0.75, 0.25) target the center of the empty bottom-right area
    legend.position = c(0.75, 0.25),
    legend.background = element_blank(),
    legend.justification = "center"
  )

Key Positioning Controls

To master legend positioning, keep these three controls in mind:

Coordinate System: The coordinates c(X, Y) represent a relative scale from 0 to 1 across the plot panel.
- c(0, 0): Bottom-left corner
- c(1, 1): Top-right corner
- c(0.5, 0.5): Center of the plot
Anchor Point (legend.justification): Use this to control which part of the legend box aligns with your coordinates. For example, c("right", "top") ensures the top-right corner of the legend box sits exactly at your target coordinate.
Background Removal: If your legend blocks data points, clear the legend box background using legend.background = element_blank(). Alternatively, use element_rect() to give it a semi-transparent or styled background.

Happy Programming!

- https://fortune9.netlify.app/2026/05/30/r-position-legend-inside-plot/ -

[R] How to use ggpattern to add patterns to ggplot2 plots

Fri, 22 May 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/05/22/r-how-to-use-ggpattern/ -

Adding patterns to plots is a great way to improve accessibility (making plots colorblind-friendly) and to add an extra dimension of information. The ggpattern package provides a rich set of tools to achieve this in ggplot2.

Basic Example with mtcars

Let’s start with a barplot using the mtcars dataset. We will map cyl to the x-axis, mpg to the y-axis, use gear for the fill color, and am for the pattern.

# Prepare data
df <- mtcars %>%
  mutate(
    cyl = factor(cyl),
    gear = factor(gear),
    am = factor(am, labels = c("Automatic", "Manual"))
  )

# Create barplot
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_fill = "black",
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 1.5
  ) +
  scale_pattern_manual(values = c("stripe", "crosshatch")) +
  labs(
    title = "MPG by Cylinders, Gear, and Transmission",
    subtitle = "Patterns representing transmission type",
    x = "Cylinders",
    y = "Miles Per Gallon (MPG)",
    fill = "Gears",
    pattern = "Transmission"
  ) +
  theme_minimal()

Exploring Key Parameters

The ggpattern package allows for fine-grained control over how patterns are rendered. Here are some of the most important parameters:

1. pattern_key_scale_factor

This parameter scales the pattern density specifically in the legend. Without it, patterns in the legend can often be hard to see. Reduce the value will make it easier fit into the legend keys.

p_base <- ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_spacing = 0.02
  ) +
  theme_minimal() +
  labs(title = "Default vs Scaled Legend")

# Default legend
p1 <- p_base + labs(subtitle = "Default (key_scale_factor = 1)")

# Scaled legend
p2 <- p_base + 
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    color = "black",
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 0.5
  ) +
  labs(subtitle = "Scaled (key_scale_factor = 0.5)")

p1

p2

2. pattern_spacing and pattern_density

pattern_spacing controls the distance between pattern elements (lower = denser), while pattern_density controls the coverage (higher = denser).

# Spacing effect
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_spacing = 0.2, # Wider spacing
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_spacing = 0.5 (Sparser)") +
  theme_minimal()

# Density effect
ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_density = 0.8, # Higher density
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_density = 0.8 (Denser)") +
  theme_minimal()

3. pattern_fill

pattern_fill sets the color of the pattern elements themselves.

ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern = am),
    stat = "identity",
    position = "dodge",
    pattern_fill = "white", # White pattern lines
    pattern_density = 0.5, # make it bigger so that the color is easier to see
    pattern_spacing = 0.02,
    pattern_key_scale_factor = 1.5
  ) +
  labs(title = "Effect of pattern_fill = 'white'") +
  theme_minimal()

4. pattern_shape

For geometric patterns like regular_polygon, pattern_shape controls the number of sides.

ggplot(df, aes(x = cyl, y = mpg, fill = gear)) +
  geom_bar_pattern(
    aes(pattern_shape=gear),
    pattern = "regular_polygon",
    stat = "identity",
    position = "dodge",
    pattern_size = 0.5, # stroke line width
    pattern_density = 0.5, # increase the shape size
    pattern_spacing = 0.03,
    pattern_key_scale_factor = 1.5
  ) +
  scale_pattern_shape_manual(values = c("3"="circle", "4"="convex6", "5"="square")) + # manually set shapes
  labs(title = "Effect of mapping pattern_shape to gear") +
  theme_minimal()

Troubleshooting

If you encounter issues installing or loading ggpattern on Linux, you may need to install the following system dependencies:

sudo apt-get install libudunits2-dev
sudo apt install libproj22
sudo apt-get install libgdal-dev

- https://fortune9.netlify.app/2026/05/22/r-how-to-use-ggpattern/ -

Understanding the Z-Algorithm for Efficient String Matching

Fri, 22 May 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/05/22/z-algorithm-for-string-matching/ -

String matching is a fundamental problem in computer science. Given a text T and a pattern P, how can we efficiently find all occurrences of P in T? While naive approaches take O(n * m) time, the Z-algorithm allows us to solve this in O(n + m) time.

The Problem: Matching Two Strings

Imagine we have:

Pattern (P): aabcaab
Text (T): baabaabcaab

We want to find where aabcaab occurs in the text. The Z-algorithm approaches this by constructing a new string S = P + $ + T (where $ is a separator not present in P or T) and computing the Z-array for S.

What is the Z-Array?

For a string S of length n, the Z-array is an array of length n where Z[i] is the length of the longest substring starting at S[i] which is also a prefix of S.

Example for S = aabcaab:

1
2
3

Index: 0 1 2 3 4 5 6
String: a a b c a a b
Z-val: 0 1 0 0 3 1 0

Z[0] is usually defined as 0 or n.
Z[4] = 3 because “aab” at index 4 matches the prefix “aab”.

Why the Z-Algorithm is Fast: O(m + n)

The naive computation of the Z-array still takes O(n^2). The Z-algorithm achieves O(n) by maintaining a Z-box [L, R], which is the rightmost interval [L, R] such that S[L..R] is a prefix of S.

By reusing previously computed Z values, we avoid redundant character comparisons. How?

The Mirroring Strategy: The Heart of the Algorithm

The most critical part of the algorithm is when we compute Z[i] and i falls within the current Z-box [L, R] (L <= i <= R).

The Setup

Prefix: [0 . . . . . R-L]
          |         |
          V         V
String: [L . . i . . R] . . .

Since S[L..R] matches S[0..R-L], any substring starting at i inside the Z-box has a “mirror” image starting at k = i - L in the prefix.

Case 1: Z[k] is contained within the Z-box (Z[k] < R - i + 1)

If the match at the mirror position k doesn’t reach the boundary R, we know Z[i] must be exactly Z[k]. No new comparisons are needed!

       k       R-L
       |       |
Prefix: [a b c] . . .
         \
          \ (mirror)
           \
String: . . [a b c] . . .
             |     |
             i     R

Case 2: Z[k] reaches or exceeds the boundary (Z[k] >= R - i + 1)

If the match at k goes beyond R, we only know that S[i..R] matches the prefix. We must manually check characters starting from R+1 to see if the match extends further.

       k       R-L
       |       |
Prefix: [a b c d e f]
         \
          \ (mirror)
           \
String: . . [a b c d ? ?]
             |     |
             i     R

Once we find the new boundary, we update [L, R] to [i, new R].

Python Implementation

Here is a concise Python implementation of the Z-algorithm:

def compute_z(s):
    n = len(s)
    z = [0] * n
    l, r = 0, 0
    for i in range(1, n):
        if i <= r:
            z[i] = min(r - i + 1, z[i - l]) # note the index is i - l (letter l), not i - 1
        while i + z[i] < n and s[z[i]] == s[i + z[i]]:
            z[i] += 1
        if i + z[i] - 1 > r:
            l, r = i, i + z[i] - 1
    return z

How to Find Matches: P in T

To find all occurrences of a pattern P in a text T, we use the following steps:

Construct a combined string: Create a new string by joining the pattern and the text with a unique separator that appears in neither: Combined = P + "#" + T (here we use # as the separator).
Compute the Z-array: Run the Z-algorithm on this combined string.
Identify matches: Iterate through the Z-array values corresponding to the text portion (indices after the # separator).
Check for pattern length: If any Z[i] is equal to the length of P, it means a match of the pattern P starts at that position in the text.

The separator is crucial because it ensures that the “match” does not extend beyond the length of the pattern itself, preventing false positives that might span across the boundary between P and T.

Conclusion

The Z-algorithm’s mirroring strategy is a brilliant example of using space (the Z-array) to save time. By keeping track of the furthest reach (R), we ensure that each character is effectively compared only a constant number of times.

For a more detailed breakdown and implementation details, check out the following links:

CP-Algorithms: https://cp-algorithms.com/string/z-function.html
GeeksforGeeks: https://www.geeksforgeeks.org/z-algorithm-linear-time-pattern-searching-algorithm/

- https://fortune9.netlify.app/2026/05/22/z-algorithm-for-string-matching/ -

[R] How to change legend key size in ggplot2

Mon, 27 Apr 2026 00:00:00 +0000

Zhenguo Zhang's Blog https://fortune9.netlify.app/2026/04/27/r-how-to-change-legend-key-size-in-ggplot2/ -

In ggplot2, the legend keys (the symbols next to the labels) usually inherit their size and appearance from the layers in the plot. For example, if you have a scatter plot with very small points, the legend keys will also be very small, making them hard to see.

To fix this without changing the size of the points in the actual plot, you can use the override.aes argument within guide_legend().

The Problem: Tiny Legend Keys

When plotting many data points, we often decrease the size to avoid overplotting. However, this makes the legend keys tiny:

library(ggplot2)

p <- ggplot(iris, aes(Sepal.Length, Sepal.Width, color = Species)) +
  geom_point(size = 0.5) + 
  theme_minimal() +
  labs(title = "Tiny Legend Keys")

p

The Solution: Using `override.aes`

By using guides(), we can “override” the aesthetics of the legend. This allows us to keep the small points in the plot while making the legend keys large and clear.

If your legend is for the color aesthetic:

p_fixed <- p + 
  guides(color = guide_legend(override.aes = list(size = 5))) +
  labs(title = "Fixed Legend Keys (Size 5)")

p_fixed

If you were using fill (e.g., in a bar plot or boxplot), you would simply change color to fill:

guides(fill = guide_legend(override.aes = list(size = 5)))

Adjusting Legend Text and Title Size

Note that override.aes only affects the symbols inside the legend. To change the size of the labels or the legend title, you should use the theme() function:

p_fixed + 
  theme(
    legend.text = element_text(size = 12),   # Legend labels
    legend.title = element_text(size = 14, face = "bold") # Legend title
  )

Summary

Use guides(color = guide_legend(override.aes = list(size = ...))) to change the symbol size.
Use theme(legend.text = element_text(size = ...)) to change the text size.

- https://fortune9.netlify.app/2026/04/27/r-how-to-change-legend-key-size-in-ggplot2/ -

Zhenguo Zhang's Blog

[R] Understanding position_dodge() and position_dodge2() in ggplot2

Definition of Terms

1. The width Parameter in position_dodge()

What does width control?

Interaction between geom_bar(width) and position_dodge(width)

2. Differences Between position_dodge2() and position_dodge()

Key Differences:

Demo: width Has No Effect in position_dodge2()

Creating Spacing with padding and Reversing Order with reverse

3. Handling Missing Elements with preserve = "single"

Summary

[Linux] Handling grep Exit Codes in Scripts with set -e and set -o pipefail

Understanding grep Exit Codes

The Problem in Action

Example 1: Direct grep under set -e

Example 2: Pipelines under set -o pipefail

Solutions

Solution 1: Append || true (or || :)

How it works

Pros & Cons

Solution 2: Test $? or Use Conditional Statements

Approach A: Direct if statement

Approach B: Preserving and evaluating $?

Pros & Cons

Solution 3: Use awk for Filtering

Replacing grep with awk:

Pros & Cons

Solution 4: Temporary Toggling of set +e or set +o pipefail

Pros & Cons

Summary Comparison

Conclusion

[R] Environment Variables in R Shiny-Server Container: Problem and Solutions

The Root Cause: How Shiny Server Spawns R Processes

Solutions

Solution 1: Use ~/.profile (Recommended for User-Level Shell Vars)

Solution 2: Use ~/.Renviron (Recommended for R-Specific Configs)

Summary

[Nextflow] Nextflow AWS options: where they take effect

The Two S3 Transfer Layers

How Staging Works in Classic Mode

Which Options Reach the EC2 Container?

Controlling Transfer Rates

A Note on Fusion file system

[AI] Maximizing Your Claude Code Productivity: Key Takeaways and Resources

1. Blended Project Management & Spec-Driven Development (SDD)

Spec-Driven Development (SDD)

2. Agent & Subagent Architecture

Spawning Subagents

Subagent Configuration

3. Extending Claude Code with MCP

4. Fine-Tuning Agent Skills

5. Routines, Loops, and Hooks

Goal-Driven Loops (/goal)

Lifecycle Hooks

Summary Cheat Sheet

[git] Git Worktree: Working on Multiple Branches Simultaneously

Git Branch vs. Git Worktree

How Git Worktree Works

Hands-On: Working with a Mock Repo

Step 1: Create a Mock Repository

Step 2: Work on a Feature Branch

Step 3: Switch to a Hotfix using a Worktree

Step 4: Fix the Bug in the Worktree

Step 5: Verify the Worktree Structure

Step 6: Cleaning Up

Quick Reference Commands

[R] How to Position the Legend Inside a Plot in ggplot2

Example 1: Basic Usage of legend.position

Example 2: Fine-Tuning with Justification and Background

Example 3: Positioning in Faceted Plots

Example 4: The “Empty Space” Trick for Faceted Plots

Key Positioning Controls

[R] How to use ggpattern to add patterns to ggplot2 plots

Basic Example with mtcars

Exploring Key Parameters

1. pattern_key_scale_factor

2. pattern_spacing and pattern_density

3. pattern_fill

4. pattern_shape

1. The `width` Parameter in `position_dodge()`

What does `width` control?

Interaction between `geom_bar(width)` and `position_dodge(width)`

2. Differences Between `position_dodge2()` and `position_dodge()`

Demo: `width` Has No Effect in `position_dodge2()`

Creating Spacing with `padding` and Reversing Order with `reverse`

3. Handling Missing Elements with `preserve = "single"`

Understanding `grep` Exit Codes

Example 1: Direct `grep` under `set -e`

Example 2: Pipelines under `set -o pipefail`

Solution 1: Append `|| true` (or `|| :`)

Solution 2: Test `$?` or Use Conditional Statements

Approach A: Direct `if` statement

Approach B: Preserving and evaluating `$?`

Solution 3: Use `awk` for Filtering

Replacing `grep` with `awk`:

Solution 4: Temporary Toggling of `set +e` or `set +o pipefail`

Solution 1: Use `~/.profile` (Recommended for User-Level Shell Vars)

Solution 2: Use `~/.Renviron` (Recommended for R-Specific Configs)

Goal-Driven Loops (`/goal`)

Example 1: Basic Usage of `legend.position`

The Solution: Using `override.aes`