Back in March we added Album Search in Album Whale. This was a very nice update because it meant you no longer had to first grab an album share link from a music service (e.g. Spotify, Apple Music, Bandcamp, etc) in order to save an album to a list. You can just head straight to Album Whale and do it all there. Today we’ve added another feature to Album Whale with a similar goal in mind, this time on the other end of the spectrum: now you can listen to an album right in Album Whale! No more needing to jump over to a music service first to do so. Hover over any album artwork and you’ll find a green ▶︎ play button, which opens a dialog containing music service embeds for that album, like this: While amazing for discovering new music quickly, I’ve also found it very useful for my own To Try list. Now this entire flow can happen within Album Whale after hearing of a new album I want to listen to at some point: Add it to my To Try list in Album Whale using search Listen to it right in Album Whale If I like it, copy it to another list in Album Whale (oh ya, this is another small feature we added!) A couple more notes: For albums added to Album Whale using a Bandcamp share link, those green play buttons just link back to Bandcamp. At least for Spotify, I found I needed to be logged into Spotify on the web to have their embeds in Album Whale play the whole album, not just a preview. This might also be true for other music services. We hope you discover many great new tunes this summer! Listen on Album Whale Reply by email

As we say repeatedly on its homepage, Pika is designed to help you focus on writing, not tinkering with your blog design. To that end Pika purposely doesn’t support complex liquid templating or other such code customization. However, today I thought I’d share how crazy powerful custom CSS can be in some circumstances where you want to augment Pika. Pika has a “Scroll to top” button floating in the bottom right of the Dashboard. Some people have asked if they can have this on their own blog. This may or may not be a feature we build right into Pika one day, but in the meantime, you can get close to a full implementation yourself in Pika. Here’s how: First, head to Pika’s Settings, scroll down to Site footer and add this to the bottom of the site footer editor: ↑ — This is an up arrow that is linking to #top, which will now be on every page of your Pika site. After saving that, head to Settings > Theme, scroll down to Additional options and check “Add custom CSS”. In the resulting code editor that appears, let’s add some CSS that targets that specific link, and designs it as a floating button: .user-site-footer a[href="#top"] { /* Float this in the bottom right of the page */ position: fixed; bottom: var(--space-S); right: var(--space-S); z-index: 1; /* Centered styling */ display: grid; place-content: center; /* Button styling with built-in Pika style variables */ background-color: var(--color-primary); border-radius: var(--radius-round); color: var(--color-txt-on-primary); font-family: var(--font-family); font-size: var(--font-L); height: var(--space-XL); width: var(--space-XL); text-decoration: none; } Depending on if you have other custom CSS, you might need to add !important to any of the style lines above. That’s it! Now you have a floating back to top button on your Pika blog, designed to look like other buttons on your site. But if you want to go the extra mile, here’s how you would make it so the back to top button only shows up after scrolling a bit (since it’s not so useful when you’re already at the top of the page): .user-site-footer a[href="#top"] { /* Float this in the bottom right of the page */ position: fixed; bottom: var(--space-S); right: var(--space-S); z-index: 1; /* Centered styling */ display: grid; place-content: center; /* Button styling with built-in Pika style variables */ background-color: var(--color-primary); border-radius: var(--radius-round); color: var(--color-txt-on-primary); font-family: var(--font-family); font-size: var(--font-L); height: var(--space-XL); width: var(--space-XL); text-decoration: none; /* Hide it until a little bit of page scroll */ transition: 200ms; opacity: 0; pointer-events: none; } .scrolled-a-bit .user-site-footer a[href="#top"] { opacity: 1; pointer-events: all; } Feel free to make this button your own, like adding a box-shadow (since it’s floating), or making it a rounded square, or whatever you’d like. If you’re really clever, you could probably get the button to say “Scroll to top” when you hover on it, though that would take quite a bit more HTML and CSS — but it’s possible! I leave that as an exercise for you. Reply by email

Continuous integration is a great thing, and having tests and security checks run before every deploy is also a great thing. But if you’re a developer who has been shipping production code for more than a week, you definitely understand how much it can all feel like a house of cards that tumbles down nearly every day. The Good Enough suite of products have been using GitHub Actions to make sure our automated test suites run before each deployment. The (mostly free) servers GitHub offers are predictably slow, with the Pika test suite generally taking close to ten minutes to run. (To that you say, “Delete most of your system tests!” Alas, due to Pika’s lovely editor, we unfortunately have to maintain quite a few system tests for the service.) Even when upgrading, and paying for, a higher-strength GitHub Action server we were seeing runs approaching eight minutes for Pika. That’s already no fun, but even worse is the fact that our system tests were a bit flaky in the GitHub Actions environment. We eventually got the hint that running system tests in parallel just isn’t possible, but even running them one test at a time would lead to odd failures in part because of how slow things  move in the Actions environment. So imagine the cycle of trying to deploy a Pika update and needing to run continuous integration two, three, or four times. Frustration! There’s got to be a better way! There is. Hopefully. With the arrival of Rails 8.1 came the option to set up local CI. As a team of two wanting to move a little more quickly and with a little less frustration, this seems like a perfect fit. Here’s how I’ve set it up for Pika… ci.rb: # Run using bin/ci CI.run do step "Setup", "bin/setup --skip-server" step "Security: Gem audit", "bin/bundler-audit" step "Security: Brakeman code analysis", "bin/brakeman --quiet --no-pager --exit-on-warn --exit-on-error --confidence-level 2" step "Security: Importmap vulnerability audit", "bin/importmap audit" step "Tests: Rails", "bin/rails test" step "Tests: System", "bin/rails test:system" step "Tests: Seeds", "env RAILS_ENV=test bin/rails db:seed:replant" # Set a green GitHub commit status to unblock PR merge. # Requires the `gh` CLI and `gh extension install basecamp/gh-signoff`. if success? step "Signoff: All systems go. Ready for merge and deploy.", "gh signoff" else failure "Signoff: CI failed. Do not merge or deploy.", "Fix the issues and try again." end end In order for the importmap vulnerability audit to run successfully, I needed to update our gemfile with openssl: group :development, :test do gem "openssl" end Here’s an excerpt of Pika’s application_system_test_case.rb: ENV["PARALLEL_WORKERS"] ||= "1" # System tests seem less flakey when not run in parallel require "test_helper" class ApplicationSystemTestCase < ActionDispatch::SystemTestCase browser_options = Selenium::WebDriver::Chrome::Options.new.tap do |opts| opts.add_argument("--window-size=1200,800") opts.add_argument("--disable-extensions") # Disable non-foreground tabs from getting a lower process priority opts.add_argument("--disable-renderer-backgrounding") # Normally, Chrome will treat a 'foreground' tab instead as backgrounded if the surrounding # window is occluded (aka visually covered) by another window. This flag disables that. opts.add_argument("--disable-backgrounding-occluded-windows") # Suppress all permission prompts by automatically denying them. opts.add_argument("--deny-permission-prompts") opts.add_argument("--enable-automation") end Capybara.register_driver :chrome_headless do |app| browser_options.add_argument("--headless") Capybara::Selenium::Driver.new(app, browser: :chrome, options: browser_options) end Capybara.register_driver :chrome do |app| Capybara::Selenium::Driver.new(app, browser: :chrome, options: browser_options) end if ENV["SYSTEM_TESTS_BROWSER"] driven_by :chrome, screen_size: [ 1200, 1000 ] else driven_by :chrome_headless, screen_size: [ 1200, 1000 ] end end Prerequisites to run local CI: brew install gh gh auth login gh extension install basecamp/gh-signoff Run: gh signoff install This installs the GitHub command-line interface, installs the signoff extension for GitHub command-line, and turns on the signoff requirement in your repo. Here’s the process: Get all your changes pushed to a branch and make a PR Make sure your local environment doesn’t have any lingering file changes or CI will fail Run bin/ci Upon successful completion of local CI, signoff will land on your branch, and you can merge and push to main. If you ever need to move quickly, say in an emergency situation: > gh signoff create -f > git push Since Lettini and I are both super-duper admins in our GitHub account, we needed one more update to protect us from willy-nilly pushing to main. I had to update a setting on GitHub in each repository. I clicked on Do not allow bypassing the above settings in repo > branches > Branch protection rules > main > edit: It’s not all rainbows and unicorns In an ideal world, hands-off CI is a really great thing. It will take a bit for these steps to become muscle memory. I hope they do! System tests are still notoriously flaky, but running tests only in our local environments means we shouldn’t have to account for both general flakiness and super-slow-test-running flakiness. GitHub has a useful feature called Dependabot, which can apply security updates to your dependencies and create a pull request that’s often ready to merge. Sometimes we’ve just clicked that merge button in the past, feeling confident because our test suite had already run in GitHub Actions. Now we’ll have to pull down those branches to go through a local CI and signoff step in order to merge things. If local CI doesn’t end up fitting us, I’ve also discovered there are faster, GitHub-Action-based alternatives for automating CI, such as Blacksmith. These services also have historically been cheaper than increasing server power at GitHub, though recent policy changes at GitHub have changed that math. And a thank you I’d be remiss if I didn’t thank 37signals for opening up their Fizzy repository. This helped me to really streamline our application_system_test_case.rb, which had become a Frankenstein’s monster of a thing as I troubleshot system test issues over the years.

Update 12/03/2025: Yay.Boo is staying alive! 🙌 Keep your eyes peeled to Yay.Boo for updates. 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 (see above note 👆). 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!