2025-11-25 08:00:00
Hello reader, Matthew here. For those of you who’ve been on this journey with us since the early days, you might know the story of Good Enough’s inception. It was started by Shawn and Barry as a modest effort to realize some fun product ideas, with the lofty goal of seeing if we could make the web a little more interesting while making at least enough money to cover costs. They put together a small team (that’s when I joined), and we set out on a stormy year of prototyping and building and bad ideas.
Fast forward to today, and after much trial-and-error, a zine, a printer experiment, and many illustrations that became stickers, we’re thankful to have found some modest product successes in Jelly and Pika. What we’ve learned along the way is that, to properly care for all our products as they continue to grow, more individual focus is needed.
Internally, our team has been mostly split up for a while now, as different team members gravitated to different products. Starting next week, we’ll be making it more official and reorganizing Good Enough into separate entities:
If you use any of our products and have interacted with us via support, you probably notice that the names above are exactly who you thought of when you thought of the given product. Not much is changing in that sense, and we’re excited and motivated to continue working on them. This reorganization simply enables us to grow the products we love in a more sustainable way. (Case in point: I’ve recently been working on new features for Letterbird! Stay tuned.)
In fact, you probably wouldn’t even notice this reorganization if we didn’t say anything. The only customer-facing change here is that there’ll be a newly formed entity named on our invoices and receipts and throughout our policies: We Are Good Enough LLC.
To keep up with the latest news for Jelly, please be sure to follow the Jelly Changelog. All other Good Enough news will continue to flow through the places you’ve become accustomed to as a Good Enough follower (see the links at the bottom of this page). If you have questions, email us.
And from all of us, thank you for being on this journey with us as we enter the next chapter!
2025-11-03 08:00:00
We have built a lot of good products here at Good Enough. Whether you’re sharing an inbox with your team or avoiding social media with a blog, we’ve got you covered. Unfortunately, there are some products that, while very nice, have not had our attention for a long time. Two of those products are Yay.Boo and Ponder.
Ponder, our take on small forum software, was one of the first things we built as a collective. Even today, it works really well for a small group of polite folks to talk about a shared interest. Unfortunately, not many small groups found Ponder, and our team hasn’t had the bandwidth to continue improving the software.
Yay.Boo is a delightful tool with which to quickly throw some HTML online. On top of that, it has always been a playground to push the envelopes on just what a product homepage could look like. Unlike Ponder, Yay.Boo is even getting a decent amount of use.
If you look closely you may see a shared risk that each of these products pose. To run both Yay.Boo and Ponder responsibly, a fair amount of time must be spent in moderation. Every Yay.Boo site update needs to be checked. We also don’t want any nasty content to end up hosted on Ponder, which is even trickier to moderate since the groups are private.
Leaving those services online and not paying attention to them is something that we do not feel comfortable doing. Since our small team is not focused on these products, we need to do the responsible thing and move on from them.
So, with heavy hearts, we’re going to shut down Ponder and Yay.Boo*. Signups are already turned off. On December 3rd we’ll delete all user data and flip the power to off.
To those of you still using Yay.Boo and Ponder, we’re sorry. There are some good alternatives to Yay.Boo in: tiiny.host, Netlify Drop, and static.app. Ponder is a different beast and, sadly, we do not know of many products that fit a similar mold. Liminal is the only one we’ve come across that might be close.
To anyone who was gracious enough to pay for a Yay.Boo account, double thank you! We have canceled all accounts and you won’t be billed again. If you have any questions about the shutdown or your data, please also don’t hesitate to get in touch.
While it stinks to have to send this message, we hope you’ll understand that a lot of thought went into this decision. Through these years at Good Enough we’ve discovered which products really excite us; properly saying goodbye to Ponder and Yay.Boo will allow us to focus on those products instead.
* A final note: if you’re reading this and thinking that you’d be just the person to take on either of these softwares, do let us know. We haven’t 100% closed the door to passing these products on to a person or team that could care for them, and we’d be happy to listen to your pitch.
Thank you and keep keeping the web weird!
2025-10-14 08:00:00
In September, I worked on improving Pika’s image performance. I’ve had a long career now (25 years 😭) doing mostly web-programming tasks, yet somehow I’ve never set up a CDN myself. I suppose the "management years" right as my prior organization was getting bigger contributed to missing out on that experience. In any case, the work was overdue on Pika and it was time to tackle it.
Through a bit of help from online articles and online friends, I’ve gotten it mostly figured out. Here is Pika’s setup.
Since we started Good Enough with lots of AWS credits, Amazon has got us a bit locked in with their services. And since, remember, I have no past experience setting these things up, well, I tallied-ho with Amazon’s CloudFront for the CDN and S3, which we were already using, for storage. Through this process I had a lot of “grass is greener” feelings toward Cloudflare and Cloudflare R2, but I’ll save that dalliance for another day.
I started thinking about the many background jobs I was going to need to orchestrate for creating the various tuned images (resizing, removing Exif data, compression, etc). Through that research I ran into John Nunemaker’s Imgproxy is Amazing blog post. I reached out to confirm that he is still using imgproxy, and, boy howdy, is he ever. Thanks to Nunes for sharing many details about how he has configured both imgproxy and CloudFront!
When someone’s browser requests an uncached image from a Pika blog post, here’s how an image request flows through all of these systems:
┌────────────┐
│ │
│ Reader │
│ requests │
│ image │
│ │
└───┬────────┘
│ ▲
│ │
▼ │
┌────────────────┴───────────┐
│ │
│ Regional CloudFront node │
│ │
└─────┬──────────────────────┘
│ ▲
│ CloudFront │ caches
│ in regions │ and at
│ shield │
▼ │
┌────────────────────────┴───┐
│ │
│ CloudFront Origin Shield │
│ │
└─────┬──────────────────────┘
│ ▲
│ imgproxy │ strips
│ Exif, │ resizes,
│ and │ compresses
▼ │
┌────────────────────────┴───┐
│ │
│ imgproxy │
│ │
└─────┬──────────────────────┘
│ ▲
│ │
│ │
│ │
▼ │
┌────────────────────────┴───┐
│ │
│ S3 │
│ │
└────────────────────────────┘
Let’s start one step above Rails with the imgproxy setup.
We deploy our services at Render.com. This is the full contents of the Dockerfile we use to deploy our Pika imgproxy web service instance:
FROM ghcr.io/imgproxy/imgproxy:latestTo configure imgproxy I am using environment variables to the max. Here are the environment variables I’m currently using:
IMGPROXY_TTL = 30758400: Feeling pretty confident here and setting the TTL to 1 year.
Attaching images to rich text fields in Rails should never really re-use an existing image or its URLs,
making cache invalidation happen as a matter of course.IMGPROXY_FALLBACK_IMAGE_DATA = R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7:
This is a 1x1 transparent GIF fallback image in case imgproxy cannot retrieve the requested image.IMGPROXY_FALLBACK_IMAGE_TTL = 120: I set the TTL for the fallback image to be much less than our system TTL set above.
I don’t want system hiccups to lead to broken images.
Well, not for more than 2 minutes, anyway!IMGPROXY_FORMAT_QUALITY = jpeg=90,png=90,webp=79,avif=63,jxl=77:
Setting mild compression for all images.
I am very cautious about over-compressing anything in Pika, and the default compression of 80 was too extreme for me.
webp, avif, and jxl formats are not currently used in Pika, but I added them here to match the defaults that imgproxy
uses for IMGPROXY_FORMAT_QUALITY.
The gif format is also not being used, as you'll see below.IMGPROXY_STRIP_COLOR_PROFILE = false: Related to the above, I want Pika to be as color-accurate as possible.IMGPROXY_MAX_SRC_RESOLUTION = 75: Did you know there is such a thing as image bombs?
Neither did I! impgroxy can protect you from them.IMGPROXY_ALLOW_SECURITY_OPTIONS = true: This is required to allow the use of the IMGPROXY_MAX_SRC_RESOLUTION envar.IMGPROXY_USE_S3 = true: This allows imgproxy to grab images directly from S3.
Very clever as it saves a trip through our Rails servers!
You will also need to set up the following envars: IMGPROXY_S3_REGION, AWS_ACCESS_KEY_ID, and AWS_SECRET_ACCESS_KEY.
The downside with this technique is that the URLs no longer end with image extensions like .jpg,
which has caused some problems with third-party services.
I do wonder if it has been worth saving that trip through our Rails servers. 🤔IMGPROXY_ALLOW_ORIGIN = https://pika.page: I’m actually not sure if this is needed since we never hit our
Rails app when loading an image.IMGPROXY_USE_LAST_MODIFIED = true: Given what I wrote about TTL above, I don’t think this is necessary,
but it just feels right.IMGPROXY_SENTRY_DSN: Set this to enable error reporting to Sentry.IMGPROXY_TIMEOUT = 15: I’m not sure why I increased this from the default of 10.IMGPROXY_READ_REQUEST_TIMEOUT = 15: Ditto.IMGPROXY_KEY & IMGPROXY_SALT need set as well, of course.Here’s how we have CloudFront configured. I’m only mentioning the settings that we changed from the default.
Main Distribution settings:
cdn.u.pika.page
Origin:
u.pika.page
Behaviors:
Logging: Added a log destination because I’m not sure how you troubleshoot without it!
Here’s how I have DNS configured for CloudFront and imgproxy:
cdn.u.pika.page (yes, I can already tell that that should have been cdn1.u.pika.page)u.pika.page (yes, I should have went with u1.pika.page)u.pika.page to our imgproxy origin according to Render’s instructionsCNAME record to point cdn.u.pika.page to the Distribution domain name provided by CloudFrontcdn.u.pika.page was acquired via CloudFront’s interface,
which required a DNS record to be set up at dnsimple during setup for certificate validationPika is configured to upload images to S3. This is a pretty straightforward setup that is written about in many other places.
I’m using the imgproxy gem to help build URLs for images.
(There is also an imgproxy-rails gem, but it didn’t play well with our setup.)
Here’s our imgproxy.yml configuration file:
default: &default
key: Rails.application.credentials.dig(:imgproxy, :key)
salt: Rails.application.credentials.dig(:imgproxy, :salt)
development:
<<: *default
endpoint: <%= ENV['IMGPROXY_FREE_CDN'] %>
test:
production:
<<: *default
endpoint: <%= ENV['IMGPROXY_FREE_CDN'] %>
use_s3_urls: trueThe IMGPROXY_FREE_CDN envar is set to https://cdn.u.pika.page, which is actually the CloudFront CDN URL.
Also note use_s3_urls: true for the production environment.
This assures the URLs generated by the imgproxy gem are pointing imgproxy to S3 directly.
The simplest images we serve are site avatars, which can be used in the headings of a blog as well as social share images.
Rendering the imgproxy/CDN URL is pretty easy for this example.
Here’s what we have in our User model:
has_one_attached :avatar
def avatar_url(variant=:small)
variant_options = case
when variant == :small
{ height: "100", width: "100" }
when variant == :medium
{ height: "300", width: "300" }
end
avatar.imgproxy_url(variant_options)
endRich text is a whole different beast in Rails.
In our case, we have already heavily overridden the _blob.html.erb file,
and our CDN updates fit right in there.
Along the way I decided not to serve GIF files from imgproxy, so you’ll see some reference to that in the code as well.
Processing animated images can get complicated, and I decided to leave that thinking for another day.
Further, for local development I wanted to support accessing a local imgproxy instance, but not break if it isn’t available.
So you’ll see mention of an imgproxy? method, which is supported by inclusion of this module in
ApplicationHelper and User:
module ImgproxyDetector
def imgproxy?
return @imgproxy if defined?(@imgproxy)
@imgproxy =
(Rails.env.production? || (Rails.env.development? && Rails.application.config_for(:imgproxy).endpoint.present?))
end
endHere’s the simplified imgproxy/CDN-related code from our _blob.html.erb file:
<figure class="attachment attachment--<%= blob.representable? ? "preview" : "file" %> attachment--<%= blob.filename.extension %>">
<% if blob.representable? %>
<%
if blob.content_type == 'image/gif' # don't use imgproxy URLs for GIFs in case they are animated
img_src_url = url_for(blob)
else
if imgproxy?
img_src_url = blob.imgproxy_url(height: "1400", width: "1800")
else
img_src_url = url_for(blob.variant(resize_to_limit: [1400, 1800], saver: { quality: 90 }))
end
end
%>
<%= image_tag img_src_url %>
<% end %>
<figcaption class="attachment__caption">
<% if caption = blob.try(:caption) %>
<%= caption %>
<% else %>
<span class="attachment__name"><%= blob.filename %></span>
<span class="attachment__size"><%= number_to_human_size blob.byte_size %></span>
<% end %>
</figcaption>
</figure>imgproxy itself is much more performant than a Rails server, but you can’t get around the fact that image processing is a resource-heavy process. In order to avoid flooding our imgproxy server with an unpredictable number of requests the first time an image-heavy post is loaded, I decided that it would be best to warm the cache as soon as possible. So in the end I wasn’t able to avoid background jobs in our image processing stack. When a new post is created or has edited its images, a background job is created to query the CDN URL for each blob in the post. I’ll leave this code as an exercise for the reader.
Above you may remember that I mentioned the security concern of image bombing. While imgproxy protects us from that, I wanted to avoid folks uploading such images in the first place. So I added a validation to check image resolutions, which means I also didn’t manage to avoid doing any image processing on our Rails server. 😅 Here is a simplified version of how I do that for rich text image attachments:
# post.rb
has_rich_text :body
validate -> { acceptable_image_attachments(:body) }
def acceptable_image_attachments(attr)
return true if self.send(attr).body.blank?
self.send(attr).body.attachables.each do |attachment|
next unless attachment.is_a?(ActiveStorage::Blob)
if image_resolution_over_limit?(attachment)
errors.add(attr, image_resolution_error_message_for(attachment.filename))
end
end
end
def image_resolution_over_limit?(blob)
width, height = blob_dimensions(blob)
(width.to_f * height.to_f) / 1_000_000.0 > Rails.application.config.x.image_resolution_limit.to_f
end
def blob_dimensions(blob)
width = blob.metadata["width"]
height = blob.metadata["height"]
if width.nil? || height.nil?
blob.analyze
width = blob.metadata["width"]
height = blob.metadata["height"]
end
[width, height]
end
# application.rb
config.x.image_resolution_limit = 75 # in megapixels Local testing is pretty easy once you get it all set up. Well, if you’re familiar with Docker. (I’m really not, but I got it set up, and doing that setup is another exercise I’ll leave to you, dear reader.) Our test code does not use imgproxy, but our development environment sure can. As mentioned above, we have a repo for Pika’s imgproxy that is a very simple Dockerfile.
.env file I have IMGPROXY_FREE_CDN = "http://localhost:7777"
foreman start -f Procfile_imgproxy.dev
Here's my Procfile_imgproxy.dev file, which is in my main Rails app:
imgproxy: docker run --rm --name pika-imgproxy -p 7777:8080 --add-host=pika.test:host-gateway -e IMGPROXY_ENABLE_INSECURE_MODE=true -e IMGPROXY_ALLOW_PRIVATE_NETWORKS=true -e IMGPROXY_ALLOW_LOOPBACK_NETWORKS=true -e IMGPROXY_ALLOW_ORIGIN=http://pika.test -e IMGPROXY_FALLBACK_IMAGE_DATA=R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7 -e IMGPROXY_FALLBACK_IMAGE_TTL=120 -e IMGPROXY_FORMAT_QUALITY=jpeg=90,png=90,webp=79,avif=63,jxl=77 -e IMGPROXY_STRIP_COLOR_PROFILE=false -e IMGPROXY_TTL=604800 -e IMGPROXY_USE_LAST_MODIFIED=true ghcr.io/imgproxy/imgproxy:latest
With this all running, you can see imgproxy in action in your local development environment!
We’re hoping to ride wih this setup for quite a while. Down the road we’ll probably look into tuning GIFs, and I may look into ways to implement WebP and AVIF while still keeping colors and performance to our liking. During implementation I did not have good luck making those formats work well.
And, as an admittedly novice CDN implementor, maybe others will read this blog post and have some ideas about how I could improve this setup. Happy to hear them!
2025-04-30 08:00:00
As we’re building Jelly, we have found ourselves looking at lots of raw emails. In particular, we’ve spent a lot of time with email headers. If you’ve ever had cause to do the same, you know it can lead to lots of scanning and squinting.
There’s got to be a better way! And here it is: Prettier Email Headers. [Ed: This project was shut down in October of 2025.]
With the help of AI, I threw together this tool that accepts a raw email paste. Then it shows those headers and header values in a format that is easier on the eyes. I also asked AI to do some research into the definition of each header and include citations. As always, I practiced the “don’t trust and verify” method when working with AI.
If you ever find yourself staring at email headers, I think you should give Prettier Email Headers a try!
2025-04-28 08:00:00
The London Ruby User Group is one of the longest-running technology user groups in the world, having held a monthly meeting almost every single month since late 2006. It’s no small feat to have kept a local community running for so long, especially since everyone involved is a volunteer.
Jelly is the foundational tool that helps LRUG’s organisers keep things running smoothly.
The beating heart of LRUG is the mailing list, and the team regularly puts out a call for members to give presentations at the monthly LRUG meet-up. Those submissions are sent to an email address which forwards directly into Jelly.
All of the volunteer organisational team can see each talk proposal conversation, and can respond directly or privately discuss the talk right in that thread. And, most importantly, anyone can quickly get up to speed with where a talk proposal is because the whole history of the conversation is right there.
This is particularly important for a volunteer-led organisation like LRUG, because at any time one of the organisation team might be on vacation or busy with life and work; but because any other member can jump in and seamlessly pick up a conversation, LRUG never stumbles.
Jelly helps the LRUG team make sure that no conversation is accidentally ignored, because it’s always clear who’s got what.
As well as talk proposals, LRUG uses Jelly to coordinate with venues, to field questions from community members and attendees, and to coordinate with other user groups. Jelly acts as a shared inbox for all of LRUG’s communication, with specific email addresses for sponsors, job posting to the mailing list, and general organisational matters. Jelly handles everything.
LRUG’s longest-running organiser, Murray Steele, says:
We looked at other more "complete" support tools like ZenDesk and HelpScout, but they are way more expensive (you have to pay per user) and more complex than we need. Jelly presents email just like email, and there's a flat cost which means we don't get penalised whenever someone new joins our team.
2025-04-24 08:00:00
For your small business to survive, you need customers. Not just to buy once. You need them to come back, tell their friends, and trust you over time. And yet, too many small businesses make it weirdly hard to talk to them.
Well, duh, right?
I agree, yet I see small businesses fumbling this over and over. All the attention when discussing business is about giant corporations. Whether they’re selling servers or vehicles or every product under the sun, millions of dollars pass through their doors every day. Yet it is folly to apply the methodologies of giant companies to our small businesses. It sounds obvious, but I constantly see small businesses making it hard for customers to get in touch. If a customer does get through the “contact us” gauntlet, that small business often uses needlessly complicated enterprise software to talk with customers.
Small businesses don’t get the spotlight, but they are the engine of the economy. To wit, in the United States:
And beyond the stats, small businesses are who we turn to every day: your corner coffee shop, your local cleaner, your neighborhood software team. And don’t forget that every big business started small. Small businesses are the genesis of innovation. We all need small businesses to succeed.
Most small teams aren’t trying to become giant corporations. They want to make a living doing work for a fair return. Many of them work hard in hopes of moving the needle from a fair return to a comfortable life, and maybe even some riches down the road. Yet it’s amazing how often it’s forgotten: you need customers to succeed. Success in small business starts with human conversation.
While talking effectively with your customers does not guarantee success, it is certainly a requirement. Here’s what that looks like: a customer has a question and your team responds kindly, clearly, and quickly. Or sometimes your team wants to reach out with a question for a customer. It’s a simple, human interaction that cannot be done effectively by automation or AI. It’s the air your small business is breathing. Starve that air, and everything else suffers. Your product or service is almost secondary to building a healthy relationship with each of your customers. Big business doesn’t operate this way. We shouldn’t expect it to show us how to build real relationships.
We’re doing our best here at Good Enough to build healthy, happy customer relationships. Whenever you write to us about any of our products, someone on the team is going to reply to offer help or an explanation or an alternative. Fact is, if you write to us about anything, we’re going to reply to offer help or an explanation or an alternative. As an online business, we’re talking with customers primarily over email. For us, Jelly makes those conversations easy to have—human, not hectic.
Actual customer support is remarkable. Actual, healthy human relationships are important. Actual customer conversations are a key to small business success. Choose your actions and tools accordingly.