Out of my mind...

middleman-s3_sync 4.7.0 released

2026-02-15T21:49:00-07:00

I’ve just released version 4.7.0 of middleman-s3_sync, a gem that synchronizes Middleman-built websites to Amazon S3, with optional CloudFront invalidation. This is a feature release with several new capabilities.

New Features

`after_s3_sync` Callback

You can now run custom code after sync completes—perfect for notifications, webhooks, or post-deployment tasks:

1
2
3
4
5
6
7
activate :s3_sync do |s3_sync|
  s3_sync.after_s3_sync = ->(results) {
    puts "Created: #{results[:created]} files"
    puts "Updated: #{results[:updated]} files"
    puts "Deleted: #{results[:deleted]} files"
  }
end

The callback receives a hash with sync statistics and the list of CloudFront invalidation paths.

`scan_build_dir` Option

Sync files that exist in your build directory but aren’t tracked by Middleman’s sitemap (e.g., files generated by external tools):

1
2
3
activate :s3_sync do |s3_sync|
  s3_sync.scan_build_dir = true
end

S3 Website `routing_rules`

Configure S3 website redirect rules directly from your Middleman config:

1
2
3
4
5
6
7
8
activate :s3_sync do |s3_sync|
  s3_sync.routing_rules = [
    {
      condition: { key_prefix_equals: 'old/' },
      redirect: { replace_key_prefix_with: 'new/', http_redirect_code: '301' }
    }
  ]
end

Improved Content Type Detection

Better MIME type detection using the mime-types gem as a fallback, with support for custom content types via the content_types option.

Other Improvements

Reliability: Proper sitemap population before sync ensures all resources are captured
CI/CD: GitHub Actions workflows for continuous integration and automated releases
Dependencies: Tightened gemspec with bounded dependency versions
Ruby: Now requires Ruby >= 3.0

Upgrading

Update your Gemfile:

1
gem 'middleman-s3_sync', '~> 4.7'

Then run:

1
bundle update middleman-s3_sync

Thanks

As always, the source is on GitHub and the gem is on RubyGems. Feedback and PRs welcome!

middleman-s3_sync 4.6.5 released

2026-02-15T16:29:00-07:00

I’ve just released version 4.6.5 of middleman-s3_sync, a gem that synchronizes Middleman-built websites to Amazon S3, with optional CloudFront invalidation.

Highlights

Thread-safe CloudFront invalidation path tracking (use Set + mutex) when running in parallel
Cache CloudFront client for fewer re-instantiations (with a reset helper for tests)
Single-pass resource categorization to reduce repeated scans
Batch S3 deletes with delete_objects (up to 1000 keys per request)
Stream uploads to S3 for lower memory usage; compute MD5s in a single read when possible
Faster CloudFront redundant-path pruning (O(n × path_depth))
CLI/extension now delegates option writers (e.g., verbose=, dry_run=) to avoid NoMethodError

These changes preserve default behavior but should improve efficiency and stability—especially on larger syncs with many deletes/invalidations or large assets.

Upgrading

Update your Gemfile to track any 4.6.x release:

1
gem 'middleman-s3_sync', '~> 4.6'

Then run:

1
bundle update middleman-s3_sync

Performance note

On my blog (light update set), wall time was essentially unchanged (≈7.7s new vs ≈7.7s old). The benefits primarily appear on larger deployments, where batching, single-pass categorization, and streaming help more.

Thanks

As always, the source is on GitHub and the gem is on RubyGems. Feedback and PRs welcome!

middleman-s3_sync 4.6.4 released

2026-01-03T10:00:00-07:00

I’ve just released version 4.6.4 of middleman-s3_sync, a gem that synchronizes Middleman-built websites to Amazon S3.

This release completely removes the map gem dependency and replaces it with a native Ruby implementation.

Background

The map gem provides a string/symbol indifferent hash implementation. After being stable at version 6.6.0 for about a decade, the original author unexpectedly released version 8.x, which introduced breaking changes that caused installation failures.

While we temporarily locked the dependency to version 6.6.0 in v4.6.3, it became clear that relying on an unmaintained library was not a sustainable solution.

What Changed

Version 4.6.4 introduces IndifferentHash, a simple native Ruby class that provides the same functionality as the map gem:

String/symbol indifferent key access
Dot notation for accessing values
Zero external dependencies
Fully tested with the existing test suite

The implementation is straightforward and maintainable, living entirely within the gem’s codebase.

Benefits

More stable: No dependency on unmaintained external libraries
Fewer dependencies: One less gem to install and manage
Better control: The functionality is now part of the gem itself
No breaking changes: The API remains exactly the same

Upgrading

To upgrade to the latest version, update your Gemfile:

1
gem 'middleman-s3_sync', '~> 4.6.4'

Then run:

1
bundle update middleman-s3_sync

This is a drop-in replacement with no breaking changes—your existing code will continue to work exactly as before.

Acknowledgments

Thanks to Chad Wilson for identifying the issue in PR #165 and proposing the initial workaround.

As always, the source code is available on GitHub, and the gem is available on RubyGems.

middleman-s3_sync 4.6.3 released

2026-01-03T09:34:00-07:00

I’ve just released version 4.6.3 of middleman-s3_sync, a gem that synchronizes Middleman-built websites to Amazon S3.

This is a maintenance release that addresses a dependency issue. Thanks to Chad Wilson for identifying and fixing the problem in PR #165.

What Changed

The map gem, a dependency of middleman-s3_sync, had been stable at version 6.6.0 for about a decade. Recently, Ara unexpectedly released version 8.x, which introduced breaking changes that caused installation failures.

This release locks the map dependency to version 6.6.0 to ensure stable installations until the compatibility issues with the newer version can be resolved.

Upgrading

To upgrade to the latest version, update your Gemfile:

1
gem 'middleman-s3_sync', '~> 4.6.3'

Then run:

1
bundle update middleman-s3_sync

As always, the source code is available on GitHub, and the gem is available on RubyGems.

It's like riding a bicycle: relearning how to work with Gems

2025-05-26T13:51:00-06:00

They say it’s like riding a bicycle - once you learn, you never forget. But after nearly 8 years at Amazon, I’m discovering that muscle memory can get pretty rusty when it comes to Ruby gems and the broader open source ecosystem.

Don’t get me wrong - Amazon’s internal tooling is impressive. When you’re building systems at AWS scale, you need tools that can handle the complexity, the security requirements, and the operational rigor that comes with serving millions of customers. Internal package managers, build systems, and deployment pipelines are all optimized for that environment. They work incredibly well for what they’re designed to do.

But stepping back into the world of bundle install and gem update feels… different. Foreign, almost.

The Small Frictions Add Up

It started with something simple - updating this very blog. The middleman-s3_sync gem I wrote years ago needed some attention. What should have been a quick bundle update turned into an afternoon of reacquainting myself with dependency resolution, version constraints, and the subtle art of Gemfile management.

Inside Amazon, dependency management is largely abstracted away. The build systems handle most of the complexity, and when they don’t, there are teams of people whose job it is to resolve conflicts and ensure compatibility. You focus on your business logic, not on whether your JSON parsing library plays nicely with someone else’s HTTP client.

But in the gem ecosystem, you are that person. You’re the one making decisions about semantic versioning, evaluating the trade-offs between features and stability, and sometimes diving into someone else’s code to understand why your tests are failing after an update.

The Muscle Memory Returns

The interesting thing is how quickly it comes back. After that first afternoon of frustration, I found myself falling back into familiar patterns. Reading changelogs with a critical eye. Understanding the implications of a major version bump. Appreciating the elegance of a well-crafted API.

There’s something deeply satisfying about working with gems that embody the Ruby philosophy of developer happiness. The expressiveness, the focus on making common tasks simple, the assumption that you’re a smart person who wants to get things done efficiently. It’s a refreshing contrast to systems that assume you might break everything if given too much flexibility.

Different Tools for Different Problems

This isn’t a criticism of Amazon’s approach - quite the opposite. When you’re building infrastructure that needs to work reliably for millions of customers across dozens of regions, the constraints are different. The tooling reflects those constraints, and it should.

But working on personal projects reminds me why I fell in love with Ruby and its ecosystem in the first place. There’s a joy in discovering a gem that solves exactly the problem you’re facing. There’s satisfaction in contributing back to projects that have made your life easier. There’s learning that happens when you’re forced to understand the full stack of your dependencies.

The Value of Context Switching

Having worked in both worlds - the highly controlled internal ecosystem and the more chaotic but creative open source one - I’m grateful for the perspective it provides. Each approach has strengths that the other lacks.

Amazon’s tooling taught me the value of consistency, reliability, and operational excellence at scale. The gem ecosystem reminds me of the power of community, the importance of developer experience, and the beauty of solving problems with elegant code.

Moving Forward

As I continue to work on side projects and contribute back to the open source community, I’m trying to bring the best of both worlds together. The operational rigor I learned at Amazon, combined with the creative problem-solving and community spirit of the Ruby ecosystem.

It really is like riding a bicycle. The balance might feel shaky at first, but once you’re moving, it all comes back. And sometimes, the ride is even better than you remembered.

Have you experienced similar transitions between different tooling ecosystems? I’d love to hear about your experiences in the comments or reach out directly.

I'm Back!

2025-04-13T19:49:00-06:00

A whole lot has happened since I last wrote here. I’ve been busy with work, family, hobbies,and personal projects. I’ve also dealt with some personal issues and challenges that have shaped my perspective and priorities. I’ve learned a lot about myself and the world around me, and I’m excited to share my experiences and insights with you.

One big change is that I joined Amazon Web Services (AWS) nearly 8 years ago. It has been a journey of growth, learning, highs and lows. I’m still there, working on projects that ensure that your serverless applications and LLM applications have plenty of compute, storage, and inference resources. I can’t really go into details about my work, but I can say that it’s been impactful.

Look for new content as I share my experiences and insights with you.

Out of my mind...

middleman-s3_sync 4.7.0 released

New Features

after_s3_sync Callback

scan_build_dir Option

S3 Website routing_rules

Improved Content Type Detection

Other Improvements

Upgrading

Thanks

middleman-s3_sync 4.6.5 released

Highlights

Upgrading

Performance note

Thanks

middleman-s3_sync 4.6.4 released

Background

What Changed

Benefits

Upgrading

Acknowledgments

middleman-s3_sync 4.6.3 released

What Changed

Upgrading

It's like riding a bicycle: relearning how to work with Gems

The Small Frictions Add Up

The Muscle Memory Returns

Different Tools for Different Problems

The Value of Context Switching

Moving Forward

I'm Back!

`after_s3_sync` Callback

`scan_build_dir` Option

S3 Website `routing_rules`