CHIPS 2.5: Ruby Intro

Due: 2026-09-02 11:59 PM PT
Estimated difficulty: ••

This is part of Module 2. Dates come from the draft FA26 schedule and are tentative until confirmed on the Schedule.

This is your first CHIPS (Coding/Hands-on Integrated ProjectS) — a warm-up with the Ruby language, which we use for the first two-thirds of the course.

Goals

  • Get your development environment and course accounts (GitHub, Gradescope) fully working.
  • Practice basic Ruby: methods, strings, collections, and iterators.
  • Write simple object-oriented Ruby — classes, attributes, and inheritance.
  • Get comfortable with the edit–run–test loop you’ll use in every later CHIPS, including running the provided RSpec tests locally before submitting.

What you’ll do

You’ll complete a set of short, independent Ruby exercises: writing methods that manipulate numbers, strings, and arrays; using blocks and iterators idiomatically (“poetry mode”); and defining a small class hierarchy. Each part comes with a test suite so you always know where you stand.

Before you start

Work through the Module 2 videos and readings through §2.4 — especially the sections on Ruby idioms. This assignment is much faster if you learn the idioms first rather than writing Java-in-Ruby.

Logistics

  • Getting the code: see Getting the Code below — you fork the public starter repo and clone your fork.
  • Starter updates: if we fix something in the starter repo after you fork it, pull it in with the upstream remote — see Keeping your fork up to date.
  • Autograding: submit to Gradescope; you may submit as many times as you like before the deadline. The autograder is a way for you to check your work and your understanding. Run the tests locally first — see Running Code and Tests.
  • Extensions: everyone automatically gets a 2-day no-penalty extension; see the extension policy.
  • Collaboration: you may collaborate with your team of 4, and discuss high-level approaches with anyone. Sharing code outside your team is academic misconduct. See the AI Use Policy below before using AI tools.

AI Use Policy

This assignment follows the course AI Policy, which will be published on this site before it is needed. Until then, the rule from the Syllabus applies: you must be able to explain everything you submit.

Getting the Code

Public starter repo: saasbook/hw-ruby-introhttps://github.com/saasbook/hw-ruby-intro

We recommend you fork the starter repo, then clone your fork. With gh (see Local Development), one command does both:

gh repo fork saasbook/hw-ruby-intro --clone
cd hw-ruby-intro

(Or click Fork on the repo page, then git clone git@github.com:YOUR_GITHUB_USERNAME/hw-ruby-intro.git.) Push your work to your fork — never to the public starter repo.

Keeping your fork up to date

Your fork is a snapshot: it does not follow the starter repo. If we fix or add something in saasbook/hw-ruby-intro after you fork it, you have to pull those changes in yourself. Add the starter repo as a second remote named upstream (once per clone), then fetch it:

git remote add upstream https://github.com/saasbook/hw-ruby-intro.git
git fetch upstream

git fetch only downloads — it changes nothing in your working copy. Review what you are about to take before merging it:

git diff --name-only HEAD upstream/main   # just the names of the files that differ
git diff --stat HEAD upstream/main       # the same list, plus how much changed in each
git diff HEAD upstream/main -- spec      # the actual changes, limited to one file or directory

Then merge the upstream changes into your branch and push them to your fork:

git merge upstream/main
git push origin main

If you and we edited the same lines, git stops and reports a conflict: open each file it lists, keep the correct combination of both sides, delete the <<<<<<< / ======= / >>>>>>> markers, then git add those files and git commit. Ask on Ed if a merge leaves you stuck — don't re-fork and lose your work.

These commands assume the starter repo's default branch is main. If git branch -r shows upstream/master instead, use that name in the commands above.

View this assignment on bCourses.

Running Code and Tests

Run everything below from the root of your clone (see Getting the Code). If Ruby isn't installed yet, work through Local Development first.

Install the dependencies

bundle install

Run this once after cloning, and again whenever the Gemfile changes. Prefix the commands below with bundle exec so you run the same gem versions the autograder does.

Boot the project

This assignment is a plain Ruby library, so there is no server to boot. Run a file directly, or load your code into an interactive console and call methods on it by hand:

bundle exec ruby lib/YOUR_FILE.rb
bundle exec irb -I lib -r YOUR_FILE

Run the tests

Run the RSpec suite the way the Gradescope autograder will — get it green locally before you submit:

bundle exec rspec                           # the whole suite
bundle exec rspec spec/YOUR_FILE_spec.rb    # one spec file
bundle exec rspec spec/YOUR_FILE_spec.rb:42 # one example, by line number
bundle exec rspec --format documentation    # every example's description

Each failure prints the file and line of the failing example along with what it expected — start there rather than at the top of the output.

Submission

When you are done, submit your work to Gradescope. You may submit more than once before the deadline; only the final submission will be graded. It is your responsibility to check that the autograder on Gradescope runs as expected after you upload your submission.

Back to Top

Accessibility Nondiscrimination

Copyright ©2026, Regents of the University of California and respective authors.

This site is built following the Berkeley Class Site template, which is generously based on the Just the Class, and Just the Docs templates.

View all course offerings