Development/Coding session

This page outlines a typical coding session, showing how to work productively on Growstuff's code.

Get the Growstuff code
If you haven't done this before, check out our code from Github. You can find out how to do this at Development/Setup. You should only have to do this once.

Start pairing
If you're Pairing, decide who's going to "drive" (i.e. be the primary coder). The secondary coder then connects to the driver's computer using TeamViewer or similar.

Decide what to work on
Check out Pivotal Tracker and decide what story you and your partner want to work on.

Tracker is split into three columns by default:


 * Current
 * Backlog
 * Icebox

If you don't have anything particular in mind, it's best to choose something from the "Current" iteration or from near the top of the "Backlog", i.e. stuff we intend to work on soon.

If you're looking for an easy task, look for 1- or 2-pointer stories, or look for tags like:


 * easy (usually a one-line fix)
 * railsy (i.e. a good, simple demonstration of how Rails works)

Once you've chosen a story to work on, click "Start". The story will move into the "Current" iteration.

For more tips on using our tracker, see Pivotal Tracker.

Refresh your checked out code
At the start of every coding session, you should make sure you have the latest updates.

cd growstuff git checkout dev git pull upstream dev

You may also need to update the installed gems and/or database structure:

bundle install rake db:migrate

(There's no harm in running these every time, even if they're not needed.)

Coding
Some tips:


 * It's a good idea to plan what tasks you have to do and list them on the story in our tracker. Not only does it help you think clearly about what's needed, but if you check off tasks as you go, it'll help you (or another developer) pick up later if you have to stop work partway through the story.  Example tasks for a typical "railsy" story might include:
 * create migration to add new database fields
 * add attributes and associations to models
 * add validation
 * modify views to display new fields
 * etc.
 * Remember to write tests for your changes, ideally before you write the code itself. Tests are found in the   directory, the structure of which mirrors the application code in   See Test driven development for more detail.
 * Run the tests regularly, either with  (to run a subset of the test suite) or with   to run the full suite.
 * See the effects of your changes in the web browser: use  to start up a web server, then point your browser at http://localhost:8080  (You can also use   and port 3000, but we prefer unicorn as it's the same as what runs on our production site.)
 * If you're working on views or front-end code (CSS, Javascript, etc) be sure to test it on mobile. See Development/Mobile for tips.

Committing your work
Commit your work at regular intervals, ideally in chunks which are easy to describe in your commit messages, and which will be easy for others to review.

See what changes you've made with:

git status

You can see more detail of the changes with:

git diff

If there are any new files that need to be added (eg. new database migrations), do:

git add path/to/filename

Finally, commit your work with:

git commit -a -m "Your commit message goes here"

Or for a longer, multi-line commit message (good if you want to explain why you've done something, for the benefit of code reviewers), use:

git commit -a

This will drop you into a text editor and let you write in more detail.

Having trouble with commit messages? Start with a verb: "Added", "Removed", "Cleaned up", etc. Eg, "Added size field to crops", "Removed unwanted validation code from plantings".

Finishing your coding session
Make sure your tests all pass:

rake

Now push your branch up to github:

git push origin yourbranchname

You'll probably also want to suspend your vagrant instance when you're not actively working:

vagrant suspend

Submitting your work
If your work is complete and you want to submit it to Growstuff, see Development/Submitting code.

Then click "Finish" in the tracker to mark your work as finished.

Tell us what you've done
We usually finish a coding session by writing a "pairing report" to the discuss mailing list. (If you're not subscribed, subscribe here).

Send your email to [mailto:discuss@lists.growstuff.org discuss@lists.growstuff.org], with a subject line like:


 * [tech] Pairing report: adding more metadata to crops

Your subject should start with [tech] (so that people can more easily filter technical discussions), then say "Pairing report" and a brief description of what you did. The description's important so people can find the message again later if they're searching through old email.

For the body of the email, here's a template you could use (or write your own if you prefer):


 * Today, $person and I worked on $story ($tracker_link)


 * We achieved...


 * We had trouble with...


 * An interesting thing which we learned/discovered is...


 * Here's our code for review: $github_link

The github link could be either to a pull request (if you finished your work and think it's ready for review/integration) or to your own branch (if the work is still in progress).