Loading…
Topic
Ruby
51 posts about Ruby. Every summary links to the original.
- 51 posts
- 4 companies
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
Posts
MJIT: A Method Based Just-in-time Compiler for Ruby
Ruby programs are compiled into YARV instructions and executed by a stack-oriented virtual machine, while register-oriented representations can expose more opportunities for compiler optimization. The post explains how YARV represents a simple expression, contrasts stack and register architectures, and introduces Vladimir Makarov’s Ruby RTL, an intermediate representation distinct from GCC’s RTL. MJIT uses RTL generated by MRI to make speculative, operand-specific optimizations, then compiles methods to machine code rather than relying only on interpretation. The interview discusses deoptimization: when assumptions change, MJIT generates a new machine-code version and can switch between JITed execution and RTL interpretation. The participants say this overhead should be tiny and should not degrade performance overall, while acknowledging edge cases where MJIT is not faster and that benchmarking JITs is difficult.
Ruby CVE-2017-17405: Vulnerability in Ruby’s FTP Implementation
CVE-2017-17405 affected Ruby’s net/ftp implementation, where a filename returned by an FTP server could reach Ruby’s open function and enable command execution. The issue was found while investigating CVE-2017-8817 in libcurl and checking whether Ruby used libcurl or had a separate FTP implementation with comparable wildcard behavior. Reviewing Ruby 2.4.2 source identified the 1,496-line ftp.rb file and the gettextfile method, which called open(localfile, "w") without validating the value. A proof of concept made an FTP client request a file list containing a pipe-prefixed payload; Ruby passed it to the shell, producing remote code execution and creating a file containing id output. Ruby replaced open with File.open, released the fix in 2.4.3, and assigned CVE-2017-17405; affected versions included Ruby 2.2.8 and earlier, 2.3.5 and earlier, 2.4.2 and earlier, and 2.5.0-preview1.
Jekyll on Heroku
Jekyll can be deployed on Heroku to use its plugin system, but relying on jekyll serve would use Ruby’s single-threaded WEBrick rather than a production-oriented web server. The setup installs Ruby with ruby-install and chruby, then installs Bundler and Jekyll, creates a site, and tracks it in Git. Heroku’s official Ruby buildpack handles dependencies and runs a Rake assets:precompile task that executes jekyll build, while the Static buildpack serves the generated _site/ directory according to static.json. The example pins Ruby 2.4.2, adds Rake, enables clean URLs and HTTPS, and completes with a successful deployment of the generated site to a Heroku URL.
Evolution of the Heroku CLI: 2008-2017
Between 2008 and 2017, Heroku's CLI evolved from Ruby (v1–v3) through Go/Node versions v4 and v5 to a pure Node v6 implementation. The rewrite addressed slower Windows performance, separation of the CLI's runtime from users' Ruby environments, migration to API v3, and limitations in Ruby-based plugin dependencies. V4 kept existing command syntax and output while adding features such as non-TTY color suppression and --json output; its Go core used Node for plugins, and the CLI became a collection of core plugins that could also be developed and installed independently. The team migrated commands incrementally, then added Flow, Babel, and improved tests, including Jest tests that run the flag parser. The resulting foundation supports modular, tested feature development, with cli-engine and more interactive interfaces planned.
We Patched Ruby On Rails for a 10% Performance Bump
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.
Improved production stability with circuit breakers
Heroku’s API consumes more service endpoints than it serves, making its availability dependent on public, internal, and third-party services that can produce tail latency, 500 errors, broken sockets, or bad deploys. To contain these failures, the team wrapped external calls with Redis-backed circuit breakers that count errors over a time window, trip at an error-rate threshold, and support fallback responses or user-friendly exceptions. CB2 provides this implementation, including individually identified breakers, while percentage-based thresholds avoid the scaling problem of fixed error counts. Deployment starts with logging-only breakers so parameters and unexpected internal-API behavior can be reviewed before traffic is affected, followed by monitoring state changes with safeguards against duplicate notifications caused by race conditions. The post also recommends explicit, low network-level timeouts, arguing that slow services can damage stability more than fast failures.
Incremental Garbage Collection in Ruby 2.2
Ruby 2.2 introduces RincGC, an incremental garbage collector intended to reduce the long pause times that Ruby 2.1’s generational collector could produce during major GC. The approach splits marking into fine-grained steps interleaved with Ruby execution, while lazy sweeping remains incremental; because CRuby lacks sufficient write barriers, unprotected objects are rescanned before white objects are reclaimed. The article explains the white, grey, and black object model, the write-barrier safety problem, and uses GC::Tracer events with a Rails benchmark simulating 30,000 requests to measure pauses. In the reported measurement, generational GC produced seven large pauses with a maximum of about 15 ms, while incremental GC reduced the maximum to around 2 ms, without reducing total GC time or improving throughput.
Debugging Super Methods with Ruby 2.2
Ruby exposes method metadata and caller-stack information, but before Ruby 2.2 it was difficult to identify the method ultimately reached by super, especially in metaprogrammed code. The example defines Dog#bark and SchneemsDog#bark, then extends an instance with DoubleBark, whose bark method calls super twice; inspecting the class hierarchy incorrectly reports Dog#bark because the module is not an ancestor of the instance's class. Ruby 2.2 adds Method#super_method, a feature proposed in request #9781 and accepted into the Ruby trunk, which returns the method Ruby will invoke for super, including the correct SchneemsDog#bark in this case. Calling source_location on that returned Method provides the location of the actual implementation and avoids the custom metaprogramming previously needed to trace it.
Getting started with the Force.com APIs for the Hackathon
With a Salesforce hackathon approaching, the guide introduces the Force.com APIs as a way to build applications using Salesforce1’s authentication, data storage, and business rule services. It compares native Salesforce1 applications, connected web applications using SOAP or REST, and three mobile patterns, including hybrid extensions, native iOS or Android clients, and a “force.com proxy” model. For hands-on setup, it recommends a free Developer Edition account and Salesforce Workbench, then explains OAuth2 web flow and password-plus-token login before showing Ruby with Restforce and Node.js with Nforce. The examples configure a Connected App, keep credentials in environment variables, query records with SOQL, and create Account records, providing a practical starting path for API integration.
Hutils – Explore your structured log data
Heroku’s internal components use logfmt to capture production activity, enabling retrospective request analysis, flexible trace queries, historical metrics, and incident investigation. The format can also become an unreadable 51-page wall of text, motivating hutils, a small suite of tools installable through Rubygems for exploring structured log data. Its ltap command extracts message streams from Splunk or Papertrail using a search query, while lviz parses messages into a tree that groups common key/value nodes and reduces duplicate data; the tools are designed to chain together. Additional commands include lcut for selecting fields and lfmt for colorized, whitespace-enhanced formatting, with both also supporting heroku logs --tail.
Introducing the Heroku HTTP API Toolkit
Heroku is open sourcing the toolchain it uses to design, document, and consume HTTP APIs, covering a design guide, JSON Schema tooling, and generated Ruby and Go clients. The guide addresses versioning, resource structure, naming, serialization, errors, request IDs, pagination, and caching, while prmd can bootstrap schemas, verify completeness, and generate documentation. JSON Schemas also drive client generation through Heroics for Ruby and Schematic for Go, with examples showing access to the Heroku Platform API and generation from its schema. Heroku says the toolkit supports both user-facing and internal services, where shared schemas and generated documentation provide a common language for proposing APIs or changes and help align design practices.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.