respond_to blocks that render screens (html) and data (xml). In other words, your controller must be RESTful.
and 
Learn about RESTfulness, DHTML and AJAX. Build your node of the Space Armada ecosystem.
You should have completed Project 7.2 and have no FIXMEs and all of your unit tests passing.
Your main goal with this segment is to complete your first version of your node of the Space Armada application.
There's a mistake in conf/staging.rb which I've fixed in the skeleton. You need to pull in these changes into your own fork. This task illustrates the need to bring in external changes of a project into your own forked version. For example, the owner of the parent repository you forked may add some features of bug fixes that you want -- how do you "absorb" these into your repository?
Follow the instructions here under "configure remotes" and "Pull in upstream changes." You simply need to:
"Hey git, look at the changes on the repository called ybakos/csci446-armada_skeleton (which we'll call upstream, since I forked from it) and apply those changes to my local repository."
You and your partner need to choose a domain (which armada component will you build?) You may choose from the following: fighters, destroyers, corvettes, carriers, battleships, crew members, lasers, projectiles, missiles, shields, resource collectors, and puppies. Alternatively, you may create your own type of node.
You must choose a node type and post to this forum thread. Node choices are like McDonalds: first-come-first-serve.
Read and implement the specification for the Armada Component.
You are free to implement the features described in the specification any way you wish. However, there are a few specific technical requirements:
respond_to blocks that render screens (html) and data (xml). In other words, your controller must be RESTful. and At the end of this project, you'll have learned about DHTML, AJAX, REST and have your application in both staging and production environments in the cloud.
First, realize there's one thing I purposely left out of our initial Heroku instructions. By default, each Heroku environment runs your app in production mode. To tell heroku that it should be running your app in the staging environment, you need to configure the RACK_ENV environment variable:
In addition, you'll want to add the following two environment variables: HTTPUSER and HTTPPASS:
This simply "protects" your staging application with a simple http auth mechanism, so the public can't access your staging application easily. Note that only one team member needs to do this. But you should of course inform your teammate which username/password you chose. Realize that this has nothing to do with users in your application itself -- this user/pass is special, and controls access to the application server over http.
Next, you should frequently deploy to staging:
"Hey git, push my current master branch to the remote repository called staging (which resides on the Heroku cloud)"
Once you're ready to "go live" with your application, you should deploy it to production:
"Hey git, push my current master branch to the remote repository called production (which resides on the Heroku cloud)"
If this is your first time deploying to production, you may need to migrate and seed your production database. If you want all of your staging data to be migrated to production, post a question on Ore about how to do this.
Be sure to visit your production URL and log in to give it one last monkey test to make sure it's working.
Once your application is running in production, it's time to monkey-test all of our applications. We tackle this in Project 7.4.
I must be able to visit your production URL and use your application (CRUD your node's domain object).