Loading…
Ruby on Rails
11 posts about Ruby on Rails. Every summary links to the original.
Shopify ·
Dev Degree: Behind the Scenes
Dev Degree is Shopify’s work-integrated learning program, designed to combine an accredited computer science degree with four years of continuous developer experience. Students take three university courses per semester while working 25 hours weekly, beginning with Shopify-led skills training before moving through four team placements across disciplines such as back-end, front-end, data, security, and production engineering. The program teaches tools and technologies including Git and GitHub, Ruby, Rails, React, TypeScript, and GraphQL, while emphasizing mentorship, feedback, personal development, and support from a multidisciplinary team working with university partners. The first cohort graduated on April 24, 2020, after adapting to program changes and remote learning during the pandemic; the post reports that 100% of graduates accepted full-time positions within six months.
2023-10-18Shopify ·
How to Fix Slow Code in Ruby
Performance regressions can accumulate in a large monolithic Rails application, making it difficult to identify offending changes among thousands of daily commits. The post presents profiling and benchmarking as complementary practices: profiling locates runtime bottlenecks, while benchmarking compares code paths and validates fixes. It covers elapsed time, CPU versus wall time, object allocations, TracePoint and ObjectSpace, plus rbspy, stackprof, rack-mini-profiler, and App Profiler, which supports on-demand remote production profiling at Shopify. A flamegraph example showed garbage collection consuming about 35% of CPU time in a slow request, and the team inferred excessive Ruby object allocation; a Rails benchmark showed roughly 50x improvement from caching an order’s total price calculation. The discussion cautions against micro-optimizations whose gains do not justify code changes and recommends addressing larger performance issues first.
2023-10-18Shopify ·
Refactoring Legacy Code with the Strangler Fig Pattern
Shopify’s Ruby on Rails Shop model had grown beyond 3,000 lines, accumulated numerous responsibilities, and developed weak semantic boundaries, making store settings a target for extraction. The team used Flog’s ABC-based score—assignments, branches, and calls—to identify a particularly disordered area, then applied Martin Fowler’s Strangler Fig Pattern to move the locked_settings behavior into Capital::SettingsToLock and a dedicated record/data source. The seven-step process defined and tested a new interface, redirected callers, introduced and backfilled the new data source, switched reads, and finally stopped legacy writes and removed the old column and code. Keeping the old system available during the transition supported incremental changes, monitoring, reversibility, and the stated no-downtime requirement; the completed example left the new system in place with legacy remnants removed.
2023-10-18Shopify ·
Your Circuit Breaker is Misconfigured
Misconfigured circuit breakers can leave an application effectively unavailable during a dependency outage by allowing timed-out requests to consume worker capacity. Using Shopify’s Semian implementation, the post explains how name, error_threshold, error_timeout, half_open_resource_timeout, and success_threshold govern circuit opening, recovery, and wasted utilization across failing service instances. It models timeout spikes for a single worker, notes that separate names isolate services and instances, and presents an equation for steady-state additional utilization, while noting that context-switch costs are not included. A live test closely matched the equation’s prediction. In a Rails worker with two threads and 42 Redis instances, changing half_open_resource_timeout from 0.25 seconds to 50ms and error_timeout from 2 to 30 seconds reduced modeled extra utilization from 263% to 4%, with slower recovery; an author’s edit says success_threshold does not affect steady-state utilization.
2023-10-18Shopify ·
How to Implement a Secure Central Authentication Service in Six Steps
Shopify built Identity to reduce the overhead of managing separate staff accounts across multiple stores, where each Shop isolated user data and lacked single sign-on. The service uses OpenID Connect (OIDC) to centralize authentication while retaining destination-specific authorization, and it models legacy one-store accounts separately from Identity accounts that can access multiple destinations. Migration begins by synchronizing profile and security data, routing authentication through Identity, and prompting eligible users to verify email ownership, combine accounts, and provide required 2FA credentials. Single legacy accounts can be auto-upgraded without changing their UUID, while multi-account merges use a MergeSession and operations implemented with ActiveOperation; WebAuthn also supports physical security keys as a second factor. Finally, Shopify changed store signup and staff invitations to prevent new legacy accounts, reporting that more than 75% of active accounts had been upgraded or combined at the time of writing.
2023-10-18Shopify ·
Sam Saffron AMA: Performance and Monitoring with Ruby
Sam Saffron discusses Discourse’s approach to Ruby performance and monitoring, arguing that production memory constraints matter more than isolated microbenchmarks for many deployments. He favors clear code and selective optimization, sometimes bypassing ActiveRecord with MiniSql on performance-sensitive paths rather than broadly sacrificing Ruby’s readability. Discourse keeps performance under continuous observation, and Saffron describes budgets for dependencies, boot time, and high-profile pages, including alerts for query-count regressions. He identifies memory leaks as especially difficult to diagnose, describes bisecting an application to isolate a V8-Ruby interop leak, and says MRI remains the only feasible runtime for Discourse while memory profiling and analysis tooling remain substantially behind Java and .NET.
2023-10-18Shopify ·
How to Write Fast Code in Ruby on Rails
Shopify’s guide presents performance advice for Ruby on Rails across Active Record, Rails, and Ruby, while treating speed as a feature rather than the first optimization priority. It recommends understanding Active Record’s lazy query execution, selecting fewer columns, avoiding unindexed queries, using safe indexing approaches for large tables, and treating query cache as short-lived rather than dependable. For Rails applications, it covers caching, throttling expensive or abusive operations, moving long-running work into Active Job-backed queues, and reducing dependency growth to limit boot time and memory use. Ruby-specific guidance includes limiting metaprogramming and indirection, choosing O(1) hash lookups over O(n) array searches when appropriate, and reducing allocations while avoiding harmful global mutation; benchmark figures show method-definition and invocation costs can differ.
2023-10-18Shopify ·
Living on the Edge of Rails
Shopify describes running its Core monolith on the unreleased Rails 6 master branch, or “Edge of Rails,” since February 2019, with the goal of continuously using the framework’s latest revision. Instead of annual upgrades, weekly changes reduce diff size and let developers use upstream features quickly, while a 130,000-plus-test suite finds edge cases and informs patches to Rails and related projects such as Zeitwerk. Solid Track automates weekly Rails bumps, opens GitHub pull requests, and triggers git bisect when CI fails to identify the breaking commit. Green builds move through ten-minute canary deployments before reaching the remaining servers. The approach trades the stability of released dependencies for faster fixes and features, relying on monitoring, tests, and controlled deployment to manage risk.
2023-10-18Shopify ·
Building Shopify’s Application Security Program
Shopify's application security program is designed to preserve safety while products and services scale quickly across a platform serving more than 800,000 merchants. It organizes the work around scaling secure applications, scaling security teams, and scaling security interactions, with a culture that treats security as a non-negotiable priority. Standardizing on Ruby on Rails and other shared technologies lets tooling go deep, while service tracking provides visibility into applications, dependencies, code, and automated dependency updates. The security organization grew from one employee into specialized teams, supplemented by penetration testing, bug bounties, and audits, while incident response remains shared across the company. At the code level, tripwires detect dangerous patterns early; Shopify renamed html_safe to dangerously_output_as_html, links flagged pull requests to XSS training, and alerts Application Security, shifting review toward automation.
2023-10-18Shopify ·
Meet Shopify Developer Kirsten Westeinde - Shopify
Kirsten Westeinde’s just-over-five-year Shopify career spans internal tools, partner-facing applications, and backend development on Kit as the company scaled. She began with Ruby on Rails, later helped extract partner software from Shopify Core using Elasticsearch, Kafka, Ruby on Rails, and the Shopify API, and now works with Data Engineering on real-time recommendations. The feature combines Go and Ruby and is designed to handle the current load while scaling to future demand. Her problem-solving practices include whiteboarding system interactions, taking mental breaks, and writing or explaining ideas to align collaborators. She also describes mentorship, pair programming, a women’s developer meetup, and f(empower) as ways to support growth and address exclusion, bias, and microaggressions in technology.
2023-10-18Shopify ·
Deconstructing the Monolith - Shopify
Shopify describes why its decade-old Ruby on Rails monolith became difficult to change as the codebase and development organization grew. High coupling and absent boundaries made innocuous changes trigger unrelated test failures, slowed CI, and forced developers to absorb excessive domain context, while microservices would add deployment, infrastructure, network, and coordination costs. The chosen path was a modular monolith: retain one codebase and deployment unit while separating domains through strictly enforced component boundaries. Shopify’s Componentization effort was informed by a developer survey and uses Wedge to score components and report violations, including cross-component associations and calls that bypass explicitly public interfaces. Boundary enforcement at runtime remains a future goal, but dependency isolation has already enabled replacing a legacy tax engine with a new tax calculation system.
2023-10-18
