Loading…
Topic
36 posts about Ruby on Rails. Every summary links to the original.
See the idea
ActiveAdmin needs a full Rails web boundary, while API-only endpoints need a lean controller. Compare the two paths to see where sessions, assets, and browser protections belong.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Ruby 2.6 introduces an initial Just-In-Time (JIT) compiler, making the feature available through the --jit option and on Heroku. The implementation follows Takashi Kokubun’s YARV-MJIT approach, retaining Ruby’s existing YARV instructions instead of replacing them with the proposed RTL intermediate representation; it starts a compiler process at startup and supports GCC, Clang, and Microsoft Visual C++. On Heroku, applications can select Ruby 2.6 in the Gemfile and enable JIT through a Procfile flag or RUBYOPT, although setting RUBYOPT with heroku config is not yet supported. The optcarrot benchmark showed a reported 1.8x speed increase over Ruby 2.5, while Rails and Sidekiq were slower because compilation costs and roughly 2MB per compiled method create overhead. JIT compaction reduces memory use near the 1,000-method cache limit, but the source says further work is needed before JIT becomes the default.
While preparing for Black Friday Cyber Monday (BFCM), Shopify’s Products team found that historical reporting records were causing MySQL to scan many InnoDB pages to return a single record. An intern built a Rails background job to delete the records safely, using Shopify’s job-iteration library to process small batches and an internal throttling enumerator to pause when database health or replication lag became a concern. Indexed fetch queries and cursor-based batching avoided repeated scans and timeouts, while the iterator deleted each batch. Run about two weeks before BFCM, the job deleted more than 5 billion records, peaked at approximately six million records per minute, and released three terabytes of storage. Afterward, the database scanned around three times fewer pages per returned record, improving resilience to flash-sale traffic and producing large cost savings.
Lawrence Mandel, a Director of Production Engineering at Shopify, describes a career that moved from software development into technical leadership and the lessons behind that transition. He leads Developer Acceleration, a team that builds tools, conventions, and documentation so Shopify’s development organization can scale effectively. His path included web services, XML, open source, release engineering, project and release management, and self-taught Perl and CGI programming during a work term at IBM. Mandel says leadership required accepting that he could not know every technology or always be the most knowledgeable person in the room, while trusting others’ expertise. He also says prioritizing family and health before work improved his relationships and made his work more deliberate and efficient.
Rails 5.2+ applications can fail to invalidate ActiveRecord-backed cache entries when cache versioning is enabled alongside a third-party store such as dalli_store 2.7.8 or earlier. Rails’ recyclable cache keys keep the cache_key stable and store an ActiveRecord cache_version in the entry, preventing unrelated entries from being evicted, but Dalli only understands the key and therefore repeatedly returns stale data. The post explains how to check the production cache_store and active_record.cache_versioning settings, then compares switching to Rails’ :mem_cache_store, disabling versioning, and upgrading Dalli to 2.7.9+. Its recommendation is to use :mem_cache_store and flush the cache, while noting that Dalli 2.7.9 fixes invalidation by putting the version into the key rather than implementing recyclable keys.
Shopify describes the engineering challenge of internationalizing a platform whose twelve years of development left thousands of hardcoded English strings across millions of lines of code. The team first used cops, linters, and tests to stop new violations, then automated extraction of existing content into module-specific dictionaries using keys derived from file paths and strings. A Rails I18n-based pseudolocalization backend replaced characters and doubled vowels, making untranslated content visible while exposing UI problems caused by longer words; UTF-8 migrations and application fixes addressed character-set and internationalization bugs. Finally, an internal Translation Platform connected GitHub webhooks and a translation management system, automatically submitting changed language files and returning approved translations as commits or pull requests. After six months, Shopify was available in a variety of languages, while the team continued addressing localization issues involving formatting, geography, payments, shipping, iconography, and regional requirements.
Shopify tested whether the Payment Request API was ready for its merchants and buyers on supported browsers. The team defined checkout completion rate, time to purchase, drop-off, and qualitative checkout experience as success measures, then ran an A/B experiment with selected merchants and eligible buyers. The isolated Ruby app injected storefront JavaScript, checked eligibility and credit-card support, and routed buyers to either the regular checkout or a browser-provided payment sheet. The experiment recorded a 7% checkout conversion rate drop and a 60% drop at the payment sheet, although time to completion medians were promising. Shopify concluded Payment Request was not yet a good fit, while expecting greater familiarity, payment-sheet improvements, and third-party payment methods through Payment Handler API to help adoption.
All previously released versions of Sprockets, which powers the Rails asset pipeline, contained a directory traversal vulnerability, CVE-2018-3760. Rails applications were vulnerable when production runtime asset compilation was enabled with config.assets.compile = true; the default production setting was false, so apps using the default were not vulnerable. Sprockets handled requests by searching for rendered assets and compiling matches dynamically, and an attacker could exploit that process with a crafted URL based on a known absolute source-asset path to make it appear inside a permitted path. Patches were prepared for Sprockets versions 2, 3, and 4, with remediation via disabling runtime compilation or upgrading to versions 2.12.5, 3.7.2, or 4.0.0.beta8. Heroku also updated its Ruby Buildpack to fail affected builds, notified customers, and warned that compromised applications may require credential rotation.
Shopify describes a merge queue added to Shipit to reduce failures in its large monolithic Rails application, where growing pull request volume made manually checking whether master was safe unsustainable. The queue adds pull requests from GitHub, merges them when master is healthy, waits for required CI statuses, and can reject stale branches using configurable divergence thresholds. It is encouraged rather than enforced, while changing the browser extension’s visual emphasis helped make queued merging the default workflow; over 90% of core application pull requests use it. Shipit also handles unsafe deployment commits by allowing explicit marking and automatically detecting reverts of undeployed commits, marking the original and intermediate commits unsafe. These changes let deployment continue safely around reverted work without requiring developers to manually unlock the pipeline.
Supporting Rails 5.2 Active Storage on Heroku required handling media files for PDF and video previews while addressing FFmpeg’s security and packaging constraints. Ubuntu Trusty’s lack of FFmpeg support, Xenial’s community-maintained package and missing vulnerability backports, and concerns about Libav led the team to build its own binary. Using a fork of sffmpeg and modified CMake configuration, the team created a static FFmpeg build that removed non-free software and unused components such as RTMP and xvid, reducing dependencies and attack surface. Docker-based CircleCI automation compiles the binary, packages it as a Debian archive, uploads it to AWS S3, and lets the buildpack install it without root access. The resulting package is about 30MB instead of roughly 200MB and can be updated in around 20 minutes after upstream security releases.
Modern Rails applications can combine a Rails 5 API-only backend, ActiveAdmin for CMS capabilities, and a Create React App frontend in one Heroku-hosted project. The tutorial addresses the tension between Rails API mode, which omits views and middleware, and ActiveAdmin’s need to serve HTML and use cookies, flash, sessions, and assets. It restores those pieces by switching ApplicationController to ActionController::Base, adding forgery protection and middleware, reintroducing sprockets, and defining a separate ApiController that retains ActionController::API. The frontend uses Create React App, API proxying during development, React Router for client-side routes, and a build process that serves the compiled app from Rails on Heroku, including a React 404 for unmatched paths. A smoothie-recipes example demonstrates the resulting setup.
Rails 5.2’s Active Storage adds file uploads and attachments for Active Record models, with backing services such as AWS S3 and previews for PDFs and videos, but its beta PDF support depended on MuPDF. Security and legal review found MuPDF’s AGPL licensing could require commercial licensing, so Terence Lee updated Active Storage to support Poppler, an open-source PDF backend merged before release. Deployment guidance uses S3 through aws-sdk-s3, configures :amazon rather than the non-scalable local disk, and installs a custom buildpack containing FFmpeg and Poppler. The example Rails app attaches files to a Bulletin model, accepts uploads, and chooses PDF or video previews, image variants, or downloads according to available binaries and MiniMagick.
Shopify interns and a former intern describe how they approached interviews, daily work, and growth across backend, development, solutions engineering, iOS, and application security roles. Their routines include stand-ups, pull-request review, coding, meetings, pair programming, production monitoring, and regular breaks, with some teams organizing work around three-week release cycles. Interview advice centers on completing the application, explaining non-traditional backgrounds, demonstrating passion and adaptability, communicating technical solutions to different audiences, and being honest about knowledge gaps. Inside Shopify, contributors say success depends on asking questions early, seeking feedback and mentorship, taking initiative, talking beyond one’s team, and holding strong opinions weakly. The post also announces Fall 2018 intern hiring, with applications due May 11, 2018, at 9:00 AM EST.
The Rails asset pipeline can take over 20 times longer than dependency installation because Sprockets consumes memory, disk I/O, and CPU while reading, fingerprinting, compressing, and resolving dependent assets. Reusing its disk cache failed across Capistrano releases and Heroku builds because cache keys and dependency data embedded absolute paths, so identical files appeared different when compiled from changing directories. Sprockets 3.3+ addresses this with UnloadedAsset, normalized relative cache keys, and URITar, which compresses paths and URIs before caching and expands them when loading; Windows portability was fixed in 3.3.4. In an example app, the initial compile remained about 38 seconds, while the second took 3 seconds, a roughly 1,200% speed increase when compiled assets were reused.
Heroku Platform API had remained on Active Record 2.3.18, released in March 2013, creating maintenance and security burdens as support ended and custom query infrastructure replaced newer features. The team moved first to Active Record 3.0.20, preserving 2.x APIs, then directly to 4.2.4, using a feature branch, console-driven fixes, automated and acceptance tests, private deployments, staging, and a partial production rollout. The first step took one engineer about two weeks, while the second took two engineers about two weeks; deployment had no downtime but briefly required a rollback for an acts_as_paranoid bug. Performance improved 18% from 2.3.18 to 3.0.20 but worsened 13% from 3.0.20 to 4.2.4, challenging micro-benchmark expectations. The upgrade ultimately left performance at the same overall level, removed patches, restored supported status, and made future updates and training easier.
Rails response time improved by more than 10% in a patch that also reduced allocated objects by 29%, motivated by memory and performance problems observed in production Heroku applications. The work began with customer reports of R14 out-of-memory errors, swap usage, and suspected memory leaks, then used a customer app and reusable benchmarks to reproduce issues. The derailed benchmarks perf:objects task and memory_profiler exposed allocation hot spots, including arrays joined into strings and duplicated hashes; refactoring reduced unnecessary objects, while routing changes produced a 31% speed increase for constrained URL generation. The resulting savings required no application changes and were planned for the next Rails version, with Rails 5 pre-release testing mentioned.
ActionDispatch::Static, enabled by config.serve_static_assets = true, checks incoming Rails requests to decide whether to serve a disk file or pass the request onward. To measure the middleware in isolation, the author loads it directly, wraps it around a no-op Proc, and uses Rack::MockRequest with benchmark-ips to compare requests against the no-op baseline. The original middleware achieved 15,891.2 iterations per second, versus 28,660.9 for the no-op, while the modified version reached 24,490.9 iterations per second. That change made non-asset middleware requests roughly 54% faster, bringing the gap to the no-op case to about 10%, although asset requests became slightly slower and the difference was not measurable. Across the full Rails application stack, the reported overall speedup was approximately 2.6%.
The best engineering reads, once a week.
