DEV Community: Saad Shakil

Understanding Vite’s File Structure: Why index.html Belongs at the Root

Saad Shakil — Tue, 21 Jan 2025 02:45:26 +0000

When working with Vite, a common gotcha is the location of the index.html file. Unlike traditional build tools like Webpack, Vite requires your index.html to reside in the project root directory, not in a public directory.

What happens when index.html is in public? You get HTTP ERROR 404, indicative of a running server but the resource not found:

This localhost page can’t be found
No webpage was found for the web address: http://localhost:5173/
HTTP ERROR 404

Why Does Vite Require This?

Vite uses index.html as an entry point to optimize and bundle your project. Placing it at the root allows Vite to:
• Detect and handle linked assets (e.g., JS, CSS) efficiently.
• Inline scripts and styles directly during development.
• Provide accurate paths for module resolution.

The Correct Structure

Here’s the expected structure for a basic Vite project:

my-project/
├── index.html      // Root-level entry point
├── src/            // Source files (components, styles, etc.)
│   └── main.js
├── public/         // Static assets (not processed by Vite)
│   └── favicon.ico
└── vite.config.js

URL Matching Nuance with mux Router in Go

Saad Shakil — Thu, 16 Jan 2025 21:12:58 +0000

When building web applications in Go with the mux router, it’s essential to understand how route matching works, especially when dealing with URLs that have query parameters. One common issue developers face is with trailing slashes in the URL paths, which can break route matching unexpectedly.

Problem: Trailing Slash on Route Matching
Solution
Conclusion

Problem: Trailing Slash on Route Matching

Consider the following two endpoints in a Go application:

// Broken

// http://localhost:8080/org/send
r.HandleFunc("/org/send/", Send).Methods("POST")

// http://localhost:8080/org/retrieve/?param=val
r.HandleFunc("/org/{id}/retrieve", Retrieve).Methods("GET")

Trailing Slash Issues with Static and Dynamic Endpoints

In mux, static paths like /org/send do not match if a trailing slash is added (e.g., /org/send/), resulting in a 404 page not found error.

On the other hand, dynamic paths like /org/{id}/retrieve/?param=val require a trailing slash to match correctly (e.g., /org/{id}/retrieve/); without it, a 404 error will occur.

This happens because mux treats paths strictly.

Solution

To fix this, register route paths consistently:

Static paths (e.g., /org/send) should not include a trailing slash.
Dynamic paths (e.g., /org/{id}/retrieve/) should include a trailing slash in the matcher.

Example:

// Fixed
r.HandleFunc("/org/send", Send).Methods("POST")  // No trailing slash
r.HandleFunc("/org/{id}/retrieve/", Retrieve).Methods("GET")  // Trailing slash needed

Alternatively, you can add additional matchers to handle static routes with and without slashes and error-correcting middleware to match dynamic routes with missing slashes.

Conclusion

Understanding how mux handles trailing slashes and how it matches paths is key to ensuring that your routes work as expected. Be mindful of static vs. dynamic path matching, and ensure consistency in how you define your routes.

Understanding Git Rebase Merge: Chronological vs Logical Order and Commit History

Saad Shakil — Sun, 24 Nov 2024 10:55:24 +0000

Logical Reverse Chronological Order: Interpreting Git's Rebase's `git log` History

This article explores how chronological order and logical order can be used to understand default ordering of git log's history upon a singular git rebase operation.

Chronological Order
Logical Order
Rebase
Interpreting Git Log
Git Rebase Merge Commands
Conclusion

Chronological Order

Chronological order refers to the order of commits based on their timestamps.

This reflects when the commits are made, regardless of their logical relationships.

For example, say we have the following chronologically ascending commits from top to bottom, earliest/oldest to latest/newest/recent :

A: Jan 1, 1pm
B: Jan 2, 1pm
C: Jan 3, 1pm
X: Jan 3, 2pm
Y: Jan 4, 2pm
D: Jan 4, 3pm

Corresponding chronological graph, left to right:

A - B - C - X - Y - D

Logical Order

Logical order refers to the parent-child relationships between commits in git, regardless of chronological order.

It represents the commit graph, where each commit logically follows its parent, regardless of the timestamp.

In the example, say feature branch was created after commit B and has logical commits C and D (after B), while X and Y follow logically after B on main:

A - B - X - Y
      \
       - C - D

The common, or base, ancestor is B.

Rebase

Upon a git rebase, which here includes the typical merging in a single operation, and not a separate rebase then merge commit (say M), we get this logical order:

A - B - X - Y - C' - D'

The apostrophes for C', D' indicate distinct rebased versions of the commits, with different hashes created during the rebase because their parent commit changed to Y.

Commits C' and D', together in that order, are appended at main's tip, after Y - which is now the new base, regardless of the timestamps that determine the chronological order.

The tip is the "end" of the history, currently with D.

Interpreting Git Log

By default, git log shows logical order in reverse chronological order, or logical reverse chronological order:

D' - C' - Y - X - B - A

Commit D appears at the top.

This means:

Commits are displayed starting from the chronologically most recent commit from the logical graph
- This refers to the tip being the starting point, D, which happens to be so since it is chronologically the last/most recent commit
Timestamps do not determine position (not inconsistent with being chronological, as that's covered above)
- Once the logical graph is constructed, the order of commits in the log is based on parent-child relationships, not the timestamps. This means commits may appear in a sequence (logical order) that doesn’t align with their actual time of creation.

This default behavior reflects how git manages the commit graph internally.

A side note, I'd say that the git documentation simplifies this too much when it refers to this as "reverse chronological order". Maybe this can lead to some confusion as to how that's consistent with being chronological when it's not timestamps per-se that determine the chronological-ness of the order. 🤔

This would be reverse chronological order in the strict sense, which is not what we see from git log:

D' - Y - X - C' - B - A

Git Rebase Merge Commands

This is the typical sequence for the 'singular' step rebase and merge that doesn't create a separate merge commit.

# Ensure you're on the feature branch
git checkout feature

# make commits on feature (and someone else does so on main)

# Rebase feature branch onto main
# Probably need to pull latest for main
git checkout main
git pull
git checkout feature
git rebase main

# Switch to main branch
git checkout main

# Fast-forward main to include the rebased feature branch
git merge --ff-only feature

# Push the updated main branch to the remote
git push origin main

The key is the git merge --ff-only command, as compared to the --no-ff option for the separate rebase and merge commit.

Key Points to Remember

git log shows commits in logical reverse chronological order by default.
Rebase rewrites commit history: Commits from the source branch are applied first, followed by the rebased commits, regardless of their timestamps.
Timestamps do not influence the logical structure of the commit graph.

Conclusion

Understanding the distinction between logical and chronological order in Git can be useful for interpreting git log, especially after git rebase operations.

The git log commit history primarily reflects the logical structure of the commit graph. After a rebase, commits from the source (e.g., feature) are incorporated at the tip of the destination branch (e.g., main), regardless of their original timestamps.

Timestamps play a secondary role and may not align with the logical order of the commits, particularly after a rebase, where the logical graph takes precedence over chronological order.

By keeping these concepts in mind, you can more effectively navigate and analyze your Git history during development.
Back to Top

Unable to Transfer Files from Android to MacOS

Saad Shakil — Thu, 07 Nov 2024 02:41:15 +0000

Issue

When attempting to connect to Android devices on MacOS via OpenMTP or MacDroid, I was receiving errors and the devices could not connect.

Cause

It turns out that the PTP Webcam service binds the camera access upon connecting devices, preventing access by OpenMTP and MacDroid.

Solutions

Disabling the service didn't work, as newer versions of MacOS prevent system service changes (Permanently Disable ptpcamerad).

Workaround

Use Activity Monitor to manually stop ptpcamerad and quickly refresh the connection on OpenMTP.

There's also running a service that periodically stops the ptpcamerad service quickly enough to run OpenMTP or other ways to access Android devices on MacOS. I may update this with an example in the future.

Resources

https://github.com/ganeshrvel/openmtp/releases
https://www.macdroid.app/

Full Page Screenshots in Chrome

Saad Shakil — Fri, 18 Oct 2024 05:20:30 +0000

How to Take a Full-Page Screenshot in Google Chrome

Capturing a full-page screenshot is a useful feature when you need to capture an entire webpage, including the parts that are off-screen. In Google Chrome, this can be done without the need for any third-party extensions. Chrome’s built-in Developer Tools offer a straightforward way to capture full-page screenshots.

As of 2024, follow these steps to take a full-page screenshot in Google Chrome:

1. Open Developer Tools
2. Capture the Full-Page Screenshot
3. Locate and Save Your Screenshot
4. Conclusion
5. Key Shortcuts Recap

1. Open Developer Tools

Open Google Chrome and navigate to the webpage you want to capture.
Right-click anywhere on the page and select Inspect, or use the keyboard shortcut:
- Windows/Linux: Ctrl + Shift + I
- Mac: Cmd + Option + I

This will open the Developer Tools panel.

2. Capture the Full-Page Screenshot

With the Developer Tools panel open, click the three-dot menu (kebab menu) in the top-right corner of the Developer Tools panel.
From the dropdown menu, select Run command or press:
- Windows/Linux: Ctrl + Shift + P
- Mac: Cmd + Shift + P
In the command menu that appears, type screenshot to filter the available commands.
Select Capture full size screenshot from the list.

Chrome will now capture a full-page screenshot and save it to your default downloads location.

3. Locate and Save Your Screenshot

Once the screenshot is captured, you can save it as a PNG file.

4. Conclusion

Taking a full-page screenshot in Chrome is straightforward using Developer Tools. This built-in feature allows you to capture everything on a webpage, including off-screen content, without needing any additional extensions or tools.

Next time you need to capture a full webpage for your needs, be it for a report, presentation, or documentation, follow these quick steps to get the job done!

5. Key Shortcuts Recap:

Open Developer Tools:
- Windows/Linux: Ctrl + Shift + I
- Mac: Cmd + Option + I
Run Command:
- Windows/Linux: Ctrl + Shift + P
- Mac: Cmd + Shift + P

Importing and Using Existing GPG Keys to Sign Git Commits

Saad Shakil — Thu, 29 Aug 2024 18:11:47 +0000

Main Steps

Check GPG (GNU Privacy Guard) is Installed
Import Keys
List GPG Keys
Configure Git to Use Your GPG Key
Enable Commit Signing by Default (Optional)
Sign a Commit
Verify the Signed Commit
Push Your Signed Commits

Additional Steps

GitHub/GitLab Setup Resources
Prevent Repeated Passphrase Entry with GPG Key Caching

Main Steps

1. Install and Check GPG (GNU Privacy Guard)

Install GPG through your package manager, like apt, brew, dnf, pacman, yum, zypper, etc. You may need to prepend sudo.

brew install gnupg

gpg --version

2. Import Keys

Instead of manually placing keys into specific folders, you should import your existing keys using GPG commands. This way, GPG will handle storing the keys properly within its internal keyring.

To import private and public keys:

gpg --import ~/my-backup-keys/private-key.asc  # Import private key
gpg --import ~/my-backup-keys/public-key.asc   # Import public key

3. List GPG Keys

 gpg --list-secret-keys --keyid-format LONG

Output

 /home/user/.gnupg/secring.gpg
 ------------------------------------
 sec   4096R/ABCDEF1234567890 2023-01-01 [expires: 2025-01-01]
 uid                          Your Name <your.email@example.com>
 ssb   4096R/1234567890ABCDEF 2023-01-01

The ABCDEF1234567890 part is the key ID.

4. Configure Git to Use Your GPG Key

Set the GPG key for the specific repository (or globally for all repositories).

Specific repo:

 git config user.signingkey ABCDEF1234567890

Globally:

 git config --global user.signingkey ABCDEF1234567890

Replace ABCDEF1234567890 with your actual GPG key ID.

5. Enable Commit Signing by Default (Optional)

You can configure Git to sign all commits by default.

Specific repo:

 git config commit.gpgSign true

Globally:

 git config --global commit.gpgSign true

6. Sign a Commit

Manually
If you don’t enable signing by default, you can sign a commit manually by using the -S option:

 git commit -S -m "Your commit message"

Automatic

git commit -m "Your commit message"

Passphrase Prompt
If your GPG key is passphrase-protected, which is highly recommended, you’ll be prompted to enter the passphrase whenever you sign a commit. See "Prevent Repeated Passphrase Entry with GPG Key Caching" to cache the key and prevent repeated passphrase entry for a timespan.

7. Verify the Signed Commit

You can verify that your commit was signed by using:

 git log --show-signature

It should show something like:

 commit abcdef1234567890abcdef1234567890abcdef12 (HEAD -> main)
 gpg: Signature made Mon 01 Jan 2023 12:00:00 PM UTC using RSA key ID ABCDEF1234567890
 gpg: Good signature from "Your Name <your.email@example.com>"

8. Push Your Signed Commits

Before being able to push, you'll need to ensure your GPG key is added to your remote repo account. See "GitHub/GitLab Setup Resources".
Now, when you push your commits, they will be signed with your GPG key.

git push origin main

Additional Steps

GitHub/GitLab Setup Resources

If you’re using GitHub or GitLab, make sure your GPG key is added to your account.

For GitHub: Adding a GPG Key
For GitLab: Adding a GPG Key

Prevent Repeated Passphrase Entry with GPG Key Caching

The gpg-agent tool can be used to prevent repeated passphrase entry for multiple commits during a timespan.

1. Locate or Create gpg-agent Configuration File

It is usually named gpg-agent.conf and is located in your .gnupg directory, which is typically ~/.gnupg/gpg-agent.conf.

If it doesn’t exist, you can create it: touch ~/.gnupg/gpg-agent.conf

2. Edit the gpg-agent Configuration

Open the gpg-agent.conf file with a text editor, and you can set the following options:

default-cache-ttl: This sets the time in seconds that the passphrase is cached. The default is usually 600 seconds (10 minutes).
max-cache-ttl: This sets the maximum time in seconds that the passphrase is cached after the first time it is used. The default is usually 7200 seconds (2 hours).

For example, to cache the passphrase for 1 hour and allow it to be cached for a maximum of 4 hours after first use, add these lines and save the file:

default-cache-ttl 3600
max-cache-ttl 14400

Scenario

Continuing with the example Time To Live (TTL) values, say you add your key to the agent at 00:00 during your 1st commit of the session and enter the passphrase.
Subsequent commits at 00:45, 1:30, and 2:15 will each extend the cache expiry by an hour, until 4 hours since the initial passphrase entry at 00:00, as long as the key is used contiguously within 1-hour intervals of each other:

Time	User Key Activity	Passphrase?	Key Cache Expiry
00:00	1st commit	Yes	01:00 (due to `default-cache-ttl`)
00:45	Commit	No	01:45 (expiry reset after commit)
01:30	Commit	No	02:30 (expiry reset after commit)
02:15	Commit	No	03:15 (expiry reset after commit)
04:00	none	N/A	`max-cache-ttl` of 4 hours expired since 00:00
04:20	Commit	Yes	05:20 (new expiry after entering passphrase)

3. Restart gpg-agent

Restart the agent for changes to take effect:

gpgconf --kill gpg-agent
gpgconf --launch gpg-agent

4. Verify Configuration

Ensure your configuration changes are recognized by checking the active configuration with:

gpgconf --list-options gpg-agent

nio4r "Failed to build gem native extension."

Saad Shakil — Wed, 28 Aug 2024 15:25:58 +0000

In an RoR project, bundle install was giving:

Installing nio4r 2.5.8 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

The following commands fix this:

bundle config build.nio4r --with-cflags="-Wno-incompatible-pointer-types"
gem install nio4r -v 2.5.8 -- --with-cflags="-Wno-incompatible-pointer-types"

Python and Ruby Development Tools: A Quick Reference

Saad Shakil — Mon, 26 Aug 2024 23:32:51 +0000

Purpose	Python Tool	Ruby Tool	Use Case	Python Installation Method	Ruby Installation Method
Package Manager	pip	gem	Installing packages	`pip install <package>`	`gem install <gem_name>`
Dependency Management	pipenv, poetry	bundler	Managing dependencies	`pip install pipenv` / `pip install poetry`	`bundle install`
Environment	venv, Conda	rbenv, RVM, chruby	Isolating project environments	`python -m venv <env_name>` / `conda create -n <env_name>`	`rbenv install <version>` / `rvm install <version>`
Version Management	pyenv, Conda	rbenv, RVM, chruby	Managing Python/Ruby versions	`pyenv install <version>` / `conda install python=<version>`	`rbenv install <version>` / `rvm install <version>`
Combined (Version + Environment)	pyenv-virtualenv	RVM	Version + env management	`pyenv virtualenv <version> <env_name>`	`rvm use <version>`
Documentation	Sphinx, MkDocs	yard	Generating project documentation	`pip install sphinx` / `pip install mkdocs`	`gem install yard`
Testing Framework	pytest, unittest	RSpec, minitest	Running unit tests	`pip install pytest` / included in Python	`gem install rspec` / included in Ruby
Task Management	invoke, doit	rake	Task automation	`pip install invoke` / `pip install doit`	`gem install rake`
Project Management	tox	rake	Automating testing/commands	`pip install tox`	`gem install rake`

DEV Community: Saad Shakil

Understanding Vite’s File Structure: Why index.html Belongs at the Root

Why Does Vite Require This?

The Correct Structure

URL Matching Nuance with mux Router in Go

Table of Contents

Problem: Trailing Slash on Route Matching

Trailing Slash Issues with Static and Dynamic Endpoints

Solution

Conclusion

Understanding Git Rebase Merge: Chronological vs Logical Order and Commit History

Logical Reverse Chronological Order: Interpreting Git's Rebase's git log History

Table of Contents

Chronological Order

Logical Order

Rebase

Interpreting Git Log

Git Rebase Merge Commands

Key Points to Remember

Conclusion

Unable to Transfer Files from Android to MacOS

Issue

Cause

Solutions

Workaround

Resources

Full Page Screenshots in Chrome

How to Take a Full-Page Screenshot in Google Chrome

Table of Contents

1. Open Developer Tools

2. Capture the Full-Page Screenshot

3. Locate and Save Your Screenshot

4. Conclusion

5. Key Shortcuts Recap:

Importing and Using Existing GPG Keys to Sign Git Commits

Table of Contents

Main Steps

Additional Steps

Main Steps

1. Install and Check GPG (GNU Privacy Guard)

2. Import Keys

3. List GPG Keys

4. Configure Git to Use Your GPG Key

5. Enable Commit Signing by Default (Optional)

6. Sign a Commit

7. Verify the Signed Commit

8. Push Your Signed Commits

Additional Steps

GitHub/GitLab Setup Resources

Prevent Repeated Passphrase Entry with GPG Key Caching

1. Locate or Create gpg-agent Configuration File

2. Edit the gpg-agent Configuration

Scenario

3. Restart gpg-agent

4. Verify Configuration

nio4r "Failed to build gem native extension."

Python and Ruby Development Tools: A Quick Reference

Logical Reverse Chronological Order: Interpreting Git's Rebase's `git log` History