About Ruby Q&A and who answers your questions

Ruby Q&A is a question and answer section of poignantguide.net, the site that keeps Why's (Poignant) Guide to Ruby online. It is served at poignantguide.net/answers/. The guide teaches Ruby with cartoon foxes, odd stories and a lot of code. This is the place to bring the questions the guide left you with, your own code and your own error message.

What it is for

People come here to learn Ruby and to get unstuck. You do not need to be experienced, and you do not need to have finished a single chapter. Typical questions look like this:

• Why does each return the whole array and not the new values?
• What does undefined method for nil:NilClass actually mean?
• Why does bundle install fail on my machine but not in the tutorial?
• The guide's code from 2005 does not run on my Ruby. What changed?
• ChatGPT gave me this class and it will not load. Can someone explain why?

The twelve sections

Each section has one narrow job, so a question lands where the right people will see it.

• Installing Ruby and setup: version managers, PATH problems, irb and editors.
• Ruby syntax and basics: variables, strings, symbols, conditionals and methods.
• Blocks, procs and iterators: do and end, yield, each, map and lambdas.
• Classes, modules and objects: instance variables, attr_accessor, inheritance and mixins.
• Arrays, hashes and Enumerable: sorting, filtering, grouping and counting.
• Errors and debugging help: paste the error and the code, get the cause.
• Gems, Bundler and tooling: Gemfiles, version conflicts and command line tools.
• Rails and web development: from plain Ruby to Rails and Sinatra.
• Testing, style and clean code: Minitest, RSpec and RuboCop.
• Reading the Poignant Guide: chapter questions, Dwemthy's Array and what to read next. Open discussion.
• Learning to program with Ruby: study plans, practice projects and getting unstuck. Open discussion.
• AI tools and learning to code: checking AI code while you learn. Open discussion.

Nine sections work as question and answer: one person asks, others answer, and the asker can mark the answer that solved it. The last three are open discussion.

Who answers

Two staff members run the forum. Odile Marchetti covers Ruby basics, objects and the Poignant Guide. She has taught Ruby to beginners in evening classes and code clubs, and she answers with code you can paste into irb and a link to the Ruby documentation she checked. Fenwick Hale covers gems, Rails, tooling and debugging. He reads stack traces for a living, and he answers with the exact command, the cause and the documentation page behind it.

Their posts carry a staff label. Everyone else is a member who has solved something similar. Members are not verified experts, so run any answer in irb before you rely on it, and read the official documentation for anything that touches security or user data.

How to ask a good question

A good question is answered quickly because the person answering can see the problem. Before you post:

1. Make the code small. Cut your program down to the smallest piece that still shows the problem. Often you will find the bug while cutting.
2. Paste the full error. Copy the message and the lines under it word for word. Do not retype it or describe it.
3. Give your Ruby version. Run ruby -v and paste the output. Ruby has changed a lot since the guide was written.
4. Say what you expected and what happened. One sentence each.
5. Say what you tried. It saves people from suggesting the same fix twice.

Put code in a code block and leave out passwords and keys. The guidelines cover the rest.

The guide itself

Poignant Guide is by _why the lucky stiff. It is preserved at poignantguide.net/ruby under the CC BY-SA 2.5 licence, and answers here often link to the chapter that explains an idea. The site also publishes research on AI text detection, which is why one section is about using AI tools while you learn.

What the forum cannot do

• It cannot write your whole project. Answers help you fix and understand code. They are not a replacement for doing the work.
• It cannot do graded work for you. See the guidelines.
• It cannot review private or restricted code. Share only what you have the right to share.
• It cannot give professional advice. See the terms.

To reach the staff, see the contact page.

Who answers here

OM

Odile Marchetti

Staff: Ruby basics, objects and the Poignant Guide

Odile has taught Ruby to beginners in evening classes and code clubs for years and reads the Poignant Guide with every new group. She answers language questions with code you can paste into irb and links the Ruby docs she checked.

FH

Fenwick Hale

Staff: gems, Rails, tooling and debugging

Fenwick maintains small Rails and Sinatra apps and spends a lot of time reading stack traces. He answers setup, Bundler, Rails and error questions with the exact command, the cause and the documentation page behind it.