Ruby-Doc Learn is the practical companion to Ruby-Doc.org’s reference documentation. The documentation tells you what Ruby provides. Here, experienced Ruby contributors show how those pieces fit together in working code, where the trade-offs appear, and what to check when a program behaves differently from the example.
Every tutorial is written for a defined audience and purpose. Where an article contains code, we aim to show the Ruby or framework version, the expected result and the limitations that matter in real projects.
Choose a practical starting point
Learn Ruby through examples
Start with short, runnable examples covering strings, collections, methods, classes, files, JSON and regular expressions. Each example is designed to answer a particular question rather than demonstrate syntax in isolation.
Compare Ruby with Python
See how Ruby and Python differ in syntax, web development, automation, data work and day-to-day developer experience. The comparison is intended to help you choose an appropriate tool, not declare a universal winner.
Run Rails with fewer blind spots
A Rails process can be online while background work has quietly stopped. This guide looks at health checks, job heartbeats and status reporting from the point of view of someone responsible for a working application.
Build dependable automation
Move beyond a one-off script by making rules visible, handling retries safely, recording what happened and keeping human approval where it belongs.
Latest tutorials
New and substantially updated Ruby-Doc Learn articles appear here. Each article identifies its author, publication date and, where applicable, its technical reviewer and most recent review date.
How our tutorials are created
A real problem comes first
A tutorial should help a recognisable group of Ruby users solve a defined problem. We do not select subjects solely because they are attracting search traffic. The topic must fit Ruby-Doc Learn and offer something useful to Ruby developers.
Examples are checked
Authors are expected to test code wherever practical, identify relevant software versions and show the expected output. Technical claims should point to primary sources such as official Ruby, framework or project documentation.
Review is specific and accountable
A technical-review credit is displayed only after the named reviewer has examined that article. Review may cover code behaviour, terminology, version compatibility, security considerations and whether the conclusions are supported.
Updates should mean something
Publication and update dates help readers judge whether an article fits their environment. When a substantive correction changes the technical meaning of a guide, the change should be explained rather than hidden behind a fresh date.
The people behind Ruby-Doc Learn
James Britt — Author and editor
James Britt created Ruby-Doc.org in 2002 and served as its long-term maintainer. He writes practical Ruby tutorials that connect documentation with the decisions developers make while building and maintaining software.
Jim Freeze — Technical reviewer
Jim Freeze is a Ruby developer, technical educator and early contributor to the documentation effort that helped lead to Ruby-Doc.org. His review credit appears only on tutorials he has personally reviewed.
Ruby-Doc’s contributor history
Ruby-Doc Learn also documents the work of contributors such as Gavin Sinclair, whose writing and tooling supported the early Ruby documentation ecosystem. Historical contribution is described separately from a present editorial role. View Gavin Sinclair’s contribution profile →
Editorial standards and corrections
Ruby-Doc Learn publishes its editorial policy, author and reviewer standards, corrections process, advertising and sponsorship rules, and a direct route for reporting errors. These policies apply to the tutorials in this section.
Reference documentation is still at the heart of Ruby-Doc.org
Use Ruby-Doc Learn when you want a worked explanation or a practical route through a problem. Use the main Ruby-Doc.org documentation when you need the exact API, class, module or standard-library reference for your Ruby version.
