CHIPS 3.7: Wordguesser
Build and deploy your first complete SaaS app: a word-guessing (hangman-style) game. This is part of Module 3.
The full, step-by-step assignment lives in the starter repo,
saasbook/hw-sinatra-saas-wordguesser:
start with its README.md
and work through Parts 0–5 in order.
Goals
- Structure an app so that game logic is independent of the web framework (the logic lives in a plain Ruby class).
- Use the lightweight Sinatra framework to handle routes, maintain game state across stateless HTTP requests, and render views.
- Deploy a working app to the cloud and understand what “deploying SaaS” actually involves.
What you’ll do
You’ll implement the game logic class test-first against a provided spec, then wire it into a provided Sinatra skeleton, keeping track of game state in cookies/sessions, and finally deploy the app to Render so anyone can play it. Cucumber scenarios (provided) check the app end to end.
Before you start
Finish the Module 3 videos and readings — the service-oriented architecture and REST sections directly inform the design.
Logistics
- Getting the code: see Getting the Code below — you clone the public starter repo and push it to a private repo of your own.
- 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.
- Deployment: the autograder also tests your deployed Render app (each
test counts half locally and half against your deployment), so put your
Render URL in
sinatra-url.txtbefore you submit. - 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-sinatra-saas-wordguesser —
https://github.com/saasbook/hw-sinatra-saas-wordguesser
GitHub makes it challenging to have a private fork of a public repository. These steps allow you to create a private space for you own work but still update from the starter code.
Clone the starter repo, then use gh
(see Local Development)
to create a private copy under your own GitHub account and
push the code to it. Replace YOUR_GITHUB_USERNAME with your
GitHub username:
git clone https://github.com/saasbook/hw-sinatra-saas-wordguesser.git
cd hw-sinatra-saas-wordguesser
git remote rename origin upstream
gh repo create YOUR_GITHUB_USERNAME/hw-sinatra-saas-wordguesser --private --source=. --remote=origin --push
git remote set-url --push upstream DISABLED
After this, origin is your private repo and upstream
is the public starter repo. The last command disables pushing to
upstream, so git push always goes to your own
copy — never to the public starter repo.
Keeping your repo up to date
Your private repo is a snapshot: it does not follow the starter
repo. If we fix or add something in saasbook/hw-sinatra-saas-wordguesser
after you copy it, you have to pull those changes in yourself. The
upstream remote you set up above is how you do that:
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 directoryThen merge the upstream changes into your branch and push them to your private repo:
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 start over 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
Start the app with Rack:
bundle exec rackup --port 3000The app is then at http://localhost:3000; Control-C stops the server. Restart it after editing your app code so the changes take effect.
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 descriptionEach 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.
Run the Cucumber features
Cucumber runs the .feature files — the acceptance tests that
describe the app's behavior from the user's point of view:
bundle exec cucumber # all features
bundle exec cucumber features/YOUR.feature # one feature file
bundle exec cucumber features/YOUR.feature:12 # one scenario, by line