Forem: Matthew LaFalce

Installing an Outdated Ruby Version on a Linux Server

Matthew LaFalce — Mon, 04 Aug 2025 15:20:15 +0000

Whether you're working on a legacy Rails app or debugging an old script, there are times when you need to install a specific (and sometimes outdated) version of Ruby on a Linux server. Ruby 2.7.0, released back in late 2019, is no longer supported by many modern environments, but it's still used in older projects.

In this guide, I’ll walk through installing Ruby 2.7.0 from source on a Linux machine. This process avoids version managers like RVM or rbenv, and instead gives you full control over where Ruby is installed.

⚠️ Why Install from Source?

Installing from source is helpful when:

You want Ruby in a custom directory like /opt/rubies/2.7.0.
You’re on a minimal server without a version manager.
You need a very specific Ruby version, not available in your OS's package manager.

🛠️ Prerequisites

Make sure your system has the required build tools and libraries installed. On Debian/Ubuntu systems:

sudo apt update
sudo apt install -y build-essential libssl-dev libreadline-dev zlib1g-dev

On RHEL/CentOS:

sudo yum groupinstall "Development Tools"
sudo yum install -y openssl-devel readline-devel zlib-devel

📦 Step-by-Step: Installing Ruby 2.7.0

Here’s a shell script to automate the process:

#!/bin/bash

# Download Ruby 2.7.0
wget https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.0.tar.gz

# Extract the archive
tar -xzvf ruby-2.7.0.tar.gz ruby-2.7.0/

# Move into the directory
cd ruby-2.7.0/

# Configure the installation path
./configure --prefix=/opt/rubies/2.7.0

# Compile the source (this may take several minutes)
make

# Install (use sudo if installing outside your home directory)
sudo make install

# Clean up
cd ..
rm -rf ruby-2.7.0 ruby-2.7.0.tar.gz

📍 Verifying the Installation

After installation, make sure the correct Ruby version is in your PATH:

export PATH="/opt/rubies/2.7.0/bin:$PATH"

You can add that line to your .bashrc or .zshrc file for it to persist.

Now check:

ruby -v
# => ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux]

🧹 Pro Tip: Avoid System-Wide Installs

It’s generally a good idea to install older Ruby versions into isolated directories like /opt/rubies/2.7.0 rather than using sudo make install into /usr/local. This keeps things cleaner, avoids version conflicts, and allows you to uninstall Ruby by just removing that folder.

🔚 Wrapping Up

Manually installing Ruby may feel old-school, but it’s reliable and gives you flexibility—especially on servers where you want minimal dependencies. Ruby 2.7.0 is still a capable version, but remember: it reached end-of-life in March 2023, so use it only when necessary and try to upgrade your apps when possible.

📚 References

Securely Accessing Private Resources in Docker Builds with BuildKit

Matthew LaFalce — Mon, 24 Feb 2025 15:11:59 +0000

Accessing private repositories and services in Docker builds has always been a challenge. Traditional methods, such as environment variables or secret files, pose security risks since they remain in image metadata or cache. While multi-stage builds offer some mitigation, they require careful handling.

Docker 18.09 introduced a new backend, BuildKit, which provides a secure and efficient way to manage secrets in Docker builds.

Enabling BuildKit

To enable BuildKit, set the following environment variable before running docker build:

export DOCKER_BUILDKIT=1

Using Build Secrets

BuildKit introduces --mount=type=secret, allowing secrets to be securely used in RUN commands without persisting them in the final image.

Defining a Secret in a Dockerfile

RUN --mount=type=secret,id=mysite.key command-to-run

This makes the secret available at /run/secrets/mysite.key during the RUN step.

Passing Secrets During Build

docker build --secret id=mysite.key,src=path/to/mysite.key .

You can specify multiple secrets, and use the required flag to ensure a build fails if a secret is missing:

RUN --mount=type=secret,id=mysite.key,required <command-to-run>

Secure SSH Access

For private repositories, BuildKit allows SSH forwarding without exposing private keys.

Using SSH in a Dockerfile

# syntax=docker/dockerfile:experimental
FROM alpine
RUN apk add --no-cache openssh-client git
RUN mkdir -p -m 0600 ~/.ssh && ssh-keyscan github.com >> ~/.ssh/known_hosts
RUN --mount=type=ssh git clone git@github.com:myorg/myproject.git myproject

Enabling SSH Forwarding

docker build --ssh default .

Instead of passing private keys, Docker forwards the SSH agent connection. You can define specific keys per repository:

docker build --ssh projecta=./projecta.pem --ssh projectb=./projectb.pem

Conclusion

With BuildKit, Docker provides a secure, ephemeral, and cache-safe way to manage secrets and SSH access in builds. By leveraging these features, developers can confidently handle private resources without compromising security.

Leveraging Rails Enums for Cleaner and More Efficient Code

Matthew LaFalce — Tue, 18 Feb 2025 00:45:08 +0000

Rails provides a powerful feature called enum that allows you to map attribute values to integers in the database while keeping them human-readable in your application. This feature enables you to use symbols instead of raw integers in your code, making it more expressive and maintainable.

In this blog post, we’ll explore how to define and use enum attributes in Rails, covering everything from basic setup to advanced configurations like scopes, defaults, string persistence, and validations.

Basic Usage

To define an enum attribute, use the enum method in your model. Here’s a simple example:

class Order < ActiveRecord::Base
  enum :status, [ :pending, :shipped, :delivered, :cancelled ]
end

How It Works:

The status column is stored as an integer in the database.
:pending is mapped to 0, :shipped to 1, :delivered to 2, and :cancelled to 3 based on their order.
You can update and query the attribute using either integers or symbols.

order = Order.new
order.status = :pending
order.pending? # => true
order.status  # => "pending"

order.status = 2
order.delivered? # => true
order.status    # => "delivered"

Built-in Scopes

Using enums automatically creates scopes based on the attribute values:

Order.pending        # Fetches all pending orders
Order.not_pending    # Fetches all non-pending orders
Order.shipped        # Fetches all shipped orders
Order.delivered      # Fetches all delivered orders
Order.cancelled      # Fetches all cancelled orders

If you want to disable these scopes, set :scopes to false:

class Order < ActiveRecord::Base
  enum :status, [ :pending, :shipped, :delivered, :cancelled ], scopes: false
end

Setting Default Values

You can set a default value for an enum attribute using the :default option:

class Order < ActiveRecord::Base
  enum :status, [ :pending, :shipped, :delivered, :cancelled ], default: :pending
end

order = Order.new
order.status # => "pending"

Explicit Mapping of Enum Values

If you prefer to define specific mappings instead of relying on implicit integer assignments, use a hash:

class Order < ActiveRecord::Base
  enum :status, pending: 0, shipped: 1, delivered: 2, cancelled: 3
end

You can also use string values instead of integers (though this may impact performance):

class Order < ActiveRecord::Base
  enum :status, pending: "pending", shipped: "shipped", delivered: "delivered", cancelled: "cancelled"
end

Accessing Enum Mappings

To retrieve the integer value mapped to an enum symbol, use:

Order.statuses[:pending]    # => 0
Order.statuses["shipped"] # => 1

This is useful when writing raw SQL queries:

Order.where("status <> ?", Order.statuses[:cancelled])

Prefixes and Suffixes

When dealing with multiple enums that share similar values, you can use :prefix or :suffix to prevent conflicts:

class Order < ActiveRecord::Base
  enum :status, [ :pending, :shipped, :delivered, :cancelled ], suffix: true
  enum :payment_status, [ :pending, :completed, :failed ], prefix: :payment
end

This will generate:

order.pending_status!
order.shipped_status? # => false
order.payment_completed!
order.payment_pending? # => false

Disabling Instance Methods

If you don’t need the automatically generated methods, you can disable them:

class Order < ActiveRecord::Base
  enum :status, [ :pending, :shipped, :delivered, :cancelled ], instance_methods: false
end

Validating Enum Values

To ensure only valid enum values are assigned, use :validate:

class Order < ActiveRecord::Base
  enum :status, [ :pending, :shipped, :delivered, :cancelled ], validate: true
end

Example validation behavior:

order = Order.new
order.status = :unknown
order.valid? # => false

You can also allow nil values:

class Order < ActiveRecord::Base
  enum :status, [ :pending, :shipped, :delivered, :cancelled ], validate: { allow_nil: true }
end

Handling Errors

If an invalid value is assigned, an ArgumentError will be raised:

order.status = :unknown # Raises 'unknown' is not a valid status (ArgumentError)

Conclusion

Using enum in Rails models simplifies your code, improves query readability, and enforces data integrity. Whether you’re defining simple status fields or complex multi-enum configurations, the flexibility of enum ensures that your models remain clean and maintainable.

By leveraging scopes, default values, explicit mappings, and validations, you can ensure that your application handles enumerations efficiently while maintaining a high level of clarity in your codebase.

Configuring PostgreSQL Replication Slots for Streaming Replication

Matthew LaFalce — Mon, 10 Feb 2025 18:30:57 +0000

PostgreSQL’s replication feature allows data to be mirrored from one database (the primary) to another (the replica), ensuring high availability and disaster recovery. One of the key features that PostgreSQL offers to manage streaming replication is replication slots. These slots ensure that WAL (Write-Ahead Logging) data is retained until it has been safely consumed by all replicas, making replication more reliable and robust.

In this blog post, we’ll walk you through the process of setting up physical replication slots in PostgreSQL, from creation on the primary server to configuring the replica to use the slot.

What is a Replication Slot?

A replication slot in PostgreSQL is a mechanism used to track the state of replication, ensuring that the primary database retains all necessary WAL files for replication until they have been consumed by the replicas. Replication slots are important for maintaining synchronization between primary and replica databases in streaming replication setups. By using a replication slot, you can prevent the primary database from recycling WAL segments before the replicas have processed them.

There are two types of replication slots in PostgreSQL:

Physical Replication Slots: These are used in streaming replication setups, where the replica receives a copy of the primary database’s data.
Logical Replication Slots: These are used for logical replication, where only specific database changes (e.g., INSERT, UPDATE, DELETE) are replicated.

In this post, we’ll focus on physical replication slots, which are typically used in standard replication setups.

Steps to Configure Replication Slots

1. Create a Replication Slot on the Primary Server

First, we need to create a replication slot on the primary server. This will allow the replica to consume WAL data and stay in sync with the primary.

To create a physical replication slot, log into the primary database and run the following SQL command:

SELECT pg_create_physical_replication_slot('replicationServer1');

In this case, we’ve named our replication slot replicationServer1. You can choose a name that fits your environment. This command creates a slot that will track the WAL data for replication purposes.

2. Configure the Replica Server

Once the replication slot is created on the primary server, we need to configure the replica server to connect to the primary using this replication slot. This is done by editing the recovery.conf file on the replica.

In PostgreSQL 10 and earlier, replication configuration is done in the recovery.conf file. For PostgreSQL 12 and later, configuration moves to postgresql.auto.conf and the presence of a standby.signal file.

On the Replica:

Open the recovery.conf (or postgresql.auto.conf in later versions) file on the replica server.
Add the following lines to specify the primary server and the replication slot:

# Set the replication source (primary server)
primary_conninfo = 'host=primary_host_ip port=5432 user=replicator password=your_password'

# Specify the name of the replication slot to use
primary_slot_name = 'replicationServer1'

# Optional: Specify a file to promote the replica in case of failure
trigger_file = '/tmp/postgresql.trigger.5432'

primary_conninfo: Contains the connection information for the primary server, such as the host, port, and credentials.
primary_slot_name: Specifies the replication slot name that the replica will use. In this case, it's replicationServer1.
trigger_file: Specifies a file that, when created, triggers the promotion of the replica to the primary role in case of failover.

3. Restart the Replica Server

After making changes to the recovery.conf file, the replica server needs to be restarted to apply the configuration.

You can restart the replica server using the following command:

sudo systemctl restart postgresql

This will cause the replica to connect to the primary server and start streaming WAL data using the replicationServer1 slot that we configured earlier.

4. Verify the Replication Status

After restarting the replica server, it’s important to verify that everything is working as expected.

On the Primary Server:

You can check the status of the replication and see if the replica is using the slot by running the following query on the primary server:

SELECT * FROM pg_stat_replication;

This will show you details about the replication connections, including the replication slot being used.

On the Replica Server:

You can also check the pg_stat_wal_receiver view on the replica server to verify that it's actively receiving WAL data from the primary:

SELECT * FROM pg_stat_wal_receiver;

This view will show information about the current replication state, including the WAL data being received from the primary server.

Additionally, you can verify that the slot is active on the primary by checking the pg_replication_slots table:

SELECT * FROM pg_replication_slots WHERE slot_name = 'replicationServer1';

5. Troubleshooting

If the replica is not using the slot or if replication is not working as expected, check the logs on both the primary and replica servers for any error messages. Common issues might include network connectivity problems, incorrect credentials, or mismatched slot names.

You can also manually drop and recreate the replication slot if needed:

SELECT pg_drop_replication_slot('replicationServer1');
SELECT pg_create_physical_replication_slot('replicationServer1');

Conclusion

By following these steps, we’ve configured a physical replication slot for streaming replication in PostgreSQL. Replication slots are a powerful tool that helps ensure WAL data is retained until replicas have consumed it, making your replication setup more robust and reliable.

Once set up, you can rest assured that your replicas will stay in sync with the primary server, and the replication slots will help manage the flow of WAL data in a controlled manner.

Pros and Cons of Next.js

Matthew LaFalce — Thu, 06 Feb 2025 17:52:20 +0000

Next.js is a popular React framework that provides server-side rendering, static site generation, and API routes out of the box. Below are some pros and cons of using Next.js:

Pros ✅

1. Performance Optimization 🚀

Static Site Generation (SSG) and Server-Side Rendering (SSR) improve loading speeds and SEO.
Incremental Static Regeneration (ISR) allows revalidating pages without rebuilding the entire site.
Image Optimization with next/image reduces load times with automatic lazy loading and resizing.

2. SEO-Friendly 🌍

Supports SSR, which improves SEO compared to client-side rendered React apps.
Meta tags and Open Graph support through libraries like next/head.

3. Full-Stack Capabilities 🖥️

Built-in API routes let you create backend endpoints (pages/api/*).
Can replace separate backend services for simple applications.

4. Automatic Code Splitting 🛠️

Loads only the necessary JavaScript for each page, improving performance.

5. Easy Routing System 🗂️

File-based routing simplifies navigation compared to React Router.

6. Edge Functions & Middleware ⚡

Middleware enables request-time modifications (useful for A/B testing, authentication, etc.).
Edge Functions allow server-side logic at CDN level for ultra-low latency.

7. TypeScript & CSS Support 📌

First-class TypeScript support.
Built-in support for CSS Modules, Tailwind CSS, and Styled Components.

Cons ❌

1. Learning Curve 📖

~~More complex than Create React App (CRA) for beginners.~~ (CRA is now depreciated)
Requires understanding SSR, SSG, ISR, and API routes.

2. Server Costs & Complexity 💰

SSR requires a running server, unlike static hosting.
Hosting costs increase with more SSR-heavy pages.

3. Limited Flexibility in Routing 🔄

File-based routing can be restrictive for complex nested structures.
No built-in dynamic API versioning like Express.js.

4. Middleware and Edge Functions Limitations 🏗️

Middleware has limited access to request body (e.g., no full parsing).
Edge Functions are restricted to certain runtimes (like Vercel’s Edge).

5. Lock-in with Vercel (Optional) 🔒

Best performance and features (like ISR) are optimized for Vercel.
Some features require Vercel’s infrastructure for full functionality.

When to Use Next.js? ✅

✔ SEO is important (e.g., blogs, e-commerce).

✔ Performance and fast page loads are crucial.

✔ You need both frontend and backend in one framework.

✔ You want static and dynamic content flexibility.

When to Avoid Next.js? ❌

❌ Simple projects that don’t need SSR/SSG.

❌ Apps that require complex backend routing (consider Nest.js or Express).

❌ If you want a purely static site (use Astro or Gatsby instead).

Exploring the Different Types of PostgreSQL Table Partitioning

Matthew LaFalce — Wed, 28 Aug 2024 13:47:10 +0000

When dealing with large datasets in PostgreSQL, efficient data management becomes crucial to maintain performance and scalability. One of the most effective strategies to manage large tables is table partitioning. Partitioning involves splitting a large table into smaller, more manageable pieces, while still enabling seamless access to the data. PostgreSQL offers several types of table partitioning, each suited to different use cases. In this article, we'll explore the various types of table partitioning available in PostgreSQL and their benefits.

1. Range Partitioning

Range partitioning is one of the most common and straightforward types of partitioning. In this method, data is divided into partitions based on a range of values in one or more columns. This is particularly useful when dealing with date or numeric data that naturally falls into ranges.

Example:

Consider a table storing sales data. We can partition this table by month:

CREATE TABLE sales (
    id SERIAL PRIMARY KEY,
    sale_date DATE NOT NULL,
    amount NUMERIC
) PARTITION BY RANGE (sale_date);

CREATE TABLE sales_2023_01 PARTITION OF sales
    FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');

CREATE TABLE sales_2023_02 PARTITION OF sales
    FOR VALUES FROM ('2023-02-01') TO ('2023-03-01');

With range partitioning, queries targeting specific date ranges can be more efficient since they only need to scan the relevant partitions.

2. List Partitioning

List partitioning is another common method where data is divided based on discrete values from one or more columns. This is particularly useful for categorical data.

Example:

Consider a table storing user data, where users belong to different regions. We can partition the table by region:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    region TEXT NOT NULL
) PARTITION BY LIST (region);

CREATE TABLE users_north PARTITION OF users
    FOR VALUES IN ('North');

CREATE TABLE users_south PARTITION OF users
    FOR VALUES IN ('South');

With list partitioning, queries targeting specific regions can be optimized to scan only the relevant partitions.

3. Hash Partitioning

Hash partitioning distributes data across a predefined number of partitions based on the hash value of a specified column. This method ensures an even distribution of data, which is beneficial for load balancing and parallel processing.

Example:

Consider a table storing transaction data. We can partition the table using a hash function on the transaction ID:

CREATE TABLE transactions (
    id SERIAL PRIMARY KEY,
    transaction_date DATE NOT NULL,
    amount NUMERIC
) PARTITION BY HASH (id);

CREATE TABLE transactions_part_1 PARTITION OF transactions
    FOR VALUES WITH (MODULUS 4, REMAINDER 0);

CREATE TABLE transactions_part_2 PARTITION OF transactions
    FOR VALUES WITH (MODULUS 4, REMAINDER 1);

With hash partitioning, the data is evenly distributed across the partitions, which can help improve query performance and maintenance tasks.

4. Composite Partitioning

Composite partitioning, also known as sub-partitioning, combines two or more partitioning methods to create a multi-level partitioning scheme. This is useful for complex datasets that benefit from multiple layers of partitioning criteria.

Example:

Consider a table storing event logs, which can be partitioned first by date (range partitioning) and then by severity level (list partitioning):

CREATE TABLE event_logs (
    id SERIAL PRIMARY KEY,
    event_date DATE NOT NULL,
    severity TEXT NOT NULL,
    message TEXT
) PARTITION BY RANGE (event_date);

CREATE TABLE event_logs_2023 PARTITION OF event_logs
    FOR VALUES FROM ('2023-01-01') TO ('2024-01-01')
    PARTITION BY LIST (severity);

CREATE TABLE event_logs_2023_info PARTITION OF event_logs_2023
    FOR VALUES IN ('INFO');

CREATE TABLE event_logs_2023_error PARTITION OF event_logs_2023
    FOR VALUES IN ('ERROR');

Composite partitioning allows for more fine-grained data management, optimizing query performance for complex queries that span multiple criteria.

Benefits of Table Partitioning

Improved Query Performance: Partitioning can significantly reduce the amount of data scanned during queries, leading to faster response times.
Ease of Maintenance: Partitioning allows for easier data management tasks such as bulk loading, purging old data, and reorganizing data.
Scalability: Partitioning enables the database to handle larger datasets more efficiently by distributing data across multiple partitions.
Parallel Processing: Partitioning can improve parallel processing capabilities, as different partitions can be processed simultaneously.

Conclusion

PostgreSQL's table partitioning features provide powerful tools to manage large datasets efficiently. By understanding and utilizing range, list, hash, and composite partitioning, you can optimize your database's performance and scalability. Choose the partitioning method that best fits your data and workload characteristics to achieve the best results.

Optimizing PostgreSQL for High Connections: A Comprehensive Guide

Matthew LaFalce — Mon, 29 Jul 2024 15:12:32 +0000

PostgreSQL is a powerful and versatile database management system that can handle a wide range of applications. However, optimizing PostgreSQL to handle a high number of concurrent connections requires careful configuration and planning. In this guide, we will walk you through the process of adjusting key PostgreSQL settings to support 300 connections, ensuring your server performs efficiently.

Understanding Key Configuration Parameters

Before diving into the configuration changes, it is important to understand the key parameters that influence memory usage and performance in PostgreSQL:

shared_buffers: This parameter defines the amount of memory allocated for shared memory buffers, which PostgreSQL uses to cache data. It is typically recommended to set shared_buffers to 25% of the total RAM.
work_mem: This parameter determines the amount of memory allocated for internal sort operations and hash tables. Each connection can use multiple times this amount if queries involve multiple sorts or hash operations.
maintenance_work_mem: This parameter specifies the amount of memory allocated for maintenance tasks like VACUUM and CREATE INDEX. It is usually higher than work_mem since maintenance operations can be memory-intensive but are not performed as frequently.
max_connections: This parameter sets the maximum number of concurrent connections to the PostgreSQL server. Increasing this value can significantly impact memory usage and performance.

Calculating Memory Requirements

To ensure your server can handle 300 connections efficiently, let's calculate the memory requirements based on the following settings:

shared_buffers: 8GB
work_mem: 32MB
maintenance_work_mem: 1GB
Additional Memory Usage: 15MB per connection for internal operations

Memory Usage per Connection

For each connection, the memory usage can be estimated as follows:

work_mem: 32MB
Additional memory: 15MB

Total memory per connection:
Memory per connection = 32MB + 15MB = 47MB

Total Memory Usage for 300 Connections

To calculate the total memory usage for 300 connections:
Total memory for connections = 300 x 47MB = 14100MB = 13.77GB

Adding the fixed overhead for shared_buffers:
Total memory usage = 13.77GB + 8GB = 21.77GB

Including maintenance_work_mem for peak usage scenarios:
Peak memory usage = 21.77GB + 1GB = 22.77GB

With these settings, a server with 32GB of RAM will have:
32GB - 22.77GB = 9.23GB

remaining for the operating system and other applications. This margin ensures that the server can function efficiently under the specified load.

Modifying Configuration Settings

To apply these changes, you can either edit the postgresql.conf file directly or use SQL commands.

Dynamic Settings

These settings can be changed without restarting the PostgreSQL server:

ALTER SYSTEM SET work_mem = '32MB';
ALTER SYSTEM SET maintenance_work_mem = '1GB';

Reload the configuration to apply changes:

SELECT pg_reload_conf();

Static Settings

These settings require a server restart after modification:

ALTER SYSTEM SET max_connections = 300;
ALTER SYSTEM SET shared_buffers = '8GB';

After making these changes, restart the PostgreSQL service:

sudo systemctl restart postgresql

Monitoring and Adjusting

After configuring your PostgreSQL server, it is crucial to monitor its performance and make adjustments as needed. Use tools like pg_stat_activity, top, or htop to keep an eye on memory usage and ensure the server is not running out of resources.

Conclusion

Optimizing PostgreSQL to handle a high number of connections involves carefully calculating memory requirements and adjusting key configuration parameters. By setting shared_buffers, work_mem, maintenance_work_mem, and max_connections appropriately, you can ensure your server performs efficiently even under heavy load. Remember to monitor the server's performance continuously and make necessary adjustments to maintain optimal performance.

Customizing Your PowerShell Environment for Efficiency and Convenience

Matthew LaFalce — Tue, 27 Jun 2023 13:45:24 +0000

Introduction

PowerShell is a powerful and versatile command-line shell and scripting language for Windows. In this article, we'll explore how you can customize your PowerShell environment to enhance your productivity and make your PowerShell experience more efficient and convenient. We'll cover setting up aliases, working with environment variables, and leveraging profiles.

Setting Up PowerShell Aliases

Aliases are shortcuts that allow you to create custom commands or abbreviations for longer commands. They can save you time and effort by simplifying repetitive tasks. In PowerShell, you can set up aliases using the Set-Alias cmdlet or by modifying your PowerShell profile. For example, you can create an alias to toggle the system theme with a single command: Set-Alias ToggleTheme "<Path to script directory>\ToggleTheme.ps1". This way, you can quickly switch between light and dark themes in your PowerShell session.

Working with Environment Variables

Environment variables store dynamic values that can be accessed by various applications and scripts. They provide a convenient way to reference commonly used paths or configuration settings. In PowerShell, you can access environment variables using the $ENV: prefix. One useful environment variable is $HOME, which represents the user's home directory. For example, you can construct file paths relative to the user's home directory using $homeDirectory = $HOME or navigate to the home directory using cd $HOME.

Leveraging PowerShell Profiles

PowerShell profiles are script files that run automatically when you start a PowerShell session. They allow you to customize and personalize your PowerShell environment. You can create a profile by editing the $PROFILE file, which is specific to each user. Within your profile, you can define aliases, functions, and variables that are loaded every time you launch PowerShell. For instance, you can define a function to toggle the system theme or set up your preferred prompt style. Profiles enable you to tailor your PowerShell experience to suit your needs.

Creating a `ToggleTheme` Script

To further enhance your PowerShell environment, you can create custom scripts. Let's create a script called ToggleTheme.ps1 that toggles the system theme between light and dark modes. Open a text editor and enter the following code:

$registryPath = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize"
$propertyName = "AppsUseLightTheme"

# Get the current value of the property
$currentValue = Get-ItemProperty -Path $registryPath -Name $propertyName

# Toggle the value
$newValue = -not $currentValue.$propertyName

# Update the registry with the new value
Set-ItemProperty -Path $registryPath -Name $propertyName -Value $newValue

# Output the new value
Write-Host "AppsUseLightTheme set to: $newValue"

Save the file as ToggleTheme.ps1 in a directory of your choice, such as your PowerShell scripts directory.

Conclusion

Customizing your PowerShell environment can significantly enhance your productivity and make your PowerShell sessions more enjoyable. By setting up aliases, leveraging environment variables, utilizing profiles, and creating custom scripts, you can streamline your workflow, save time, and create a personalized environment that suits your preferences. Take advantage of these customization options to make the most of PowerShell's capabilities and optimize your command-line experience.

We hope this article has provided valuable insights into customizing your PowerShell environment. By exploring these customization techniques and creating your own scripts, you can unlock the full potential of PowerShell and elevate your productivity.

Error: 413 “Request Entity Too Large” in Nginx

Matthew LaFalce — Tue, 30 May 2023 14:26:47 +0000

Why am I seeing Error: 413 “Request Entity Too Large” in Nginx?

This is happening because your nginx server does not allow you to upload a file that is larger than the defined size in nginx config file. To solve it, you have to modify your nginx configuration.

Follow the step to add/modify your nginx config file.

Step 1: Connect to your nginx server with your terminal.

ssh user@my_server

Step 2: Go to the config location and open it

sudo vim /etc/nginx/nginx.conf

Step 3: Adding/Modifying the `client_max_body_size` variable

If you find it, just increase its size to 100M,
If it doesn’t exist, then you can add the below code inside and at the end of HTTP settings:

client_max_body_size 100M;

Step 4: Restart nginx to apply the changes

sudo service nginx restart

Checking File Permissions in your Git Repo

Matthew LaFalce — Mon, 17 Apr 2023 14:34:48 +0000

Files in Git are assigned either 644(owner rw-, group and other r--) or
755(owner rwx, group and other r-x). Ownership information is not
stored.

You can check the status of a file via:

git ls-files -s script.sh

The output of this command is structured as:

[<tag> ]<mode> <object> <stage> <file>

A sample:

100644 b43ebcdea6790f7f8018 0       script.sh

The key piece above is the mode tag, 100644. The 100 prefix to the mode signifies that this file is a normal file. Then this is where you will see either a 644 or a 755 file mode.

As you can see, the file has 644 permission, and we want to change this now to 755:

git update-index --chmod=+x script.sh

Inversely, we can remove the executable permission via:

git update-index --chmod=-x script.sh

All that's left is to commit your changes!


bash
git commit -m "FIX: Changing file permissions"
[main 77b171e] Changing file permissions
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 script.sh

Duplicating Table Structure and Data with PostgreSQL

Matthew LaFalce — Fri, 26 Aug 2022 19:02:42 +0000

A handy little feature I recently learned about is super simple to work with. Use this to copy the structure of a table:

CREATE TABLE table2 ( LIKE table1 INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES );

Then you can copy data into your new table at your liking with:

INSERT INTO table2 SELECT * FROM table LIMIT 100;

Happy programming!

How to find outgoing IP addresses on your Linux machine.

Matthew LaFalce — Wed, 09 Mar 2022 19:42:00 +0000

Here is a small post to help you find the outgoing IP address of you Linux machine.

To find the outgoing internal IP address only

ip route get 8.8.8.8 | head -1 | gawk '{ print $7 }'

To find the outgoing internal IP address along with the interface name.

ip route get 8.8.8.8 | head -1 | gawk '{ print $5,$7 }'

In the case that your machine is connected to the internet, to find the outgoing external IP Address.

curl ifconfig.me