... package system. Install, then use to bring in external packages to use.
... example: Reek, a smell detector. Install:
macbook >sudo gem install reek
Thank you for downloading Reek. For info:
- see the reek wiki http://wiki.github.com/kevinrutherford/reek
- follow @rubyreek on twitter
Successfully installed sexp_processor-3.0.4
Successfully installed ruby_parser-2.0.4
Successfully installed ruby2ruby-1.2.4
Successfully installed reek-1.2.8
4 gems installed
Installing ri documentation for [all four]
Installing RDoc documentation for [all four]
[...]
Now we can run reek against any Ruby file for feedback on code style and design. [] comments are mine.
macbook > reek Customer.rb
Customer.rb -- 12 warnings:
Customer has no descriptive comment (IrresponsibleModule)
Customer#addRental has the name 'addRental' (UncommunicativeName)
Customer#getName has the name 'getName' (UncommunicativeName)
Customer#statement calls (frequentRenterPoints + 1) twice (Duplication)
[move the computation to a helper method]
Customer#statement calls entry.getDaysRented 6 times (Duplication)
Customer#statement calls entry.getMovie 3 times (Duplication)
Customer#statement calls entry.getMovie.getPriceCode twice (Duplication)
[move the computation to the receiver class]
Customer#statement has approx 17 statements (LongMethod)
[extract helper methods]
Customer#statement has the variable name 'frequentRenterPoints' (UncommunicativeName)
Customer#statement has the variable name 'thisAmount' (UncommunicativeName)
Customer#statement has the variable name 'totalAmount' (UncommunicativeName)
Customer#statement refers to entry more than self (LowCohesion)
RubyGems is the standard packaging and distribution system used in the Ruby community.
... we looked at RubyMine, a relatively new Ruby IDE that offers support for a few common refactorings.
We used RubyMine to refactor the movie store codebase we worked on last time, adapted from Fowler's refactoring book. In particular, we
This is similar to the set of refactorings Fowler himself applies to this code in Chapter 1 of his book!
We ran our tests as often as we could throughout the process, to ensure that we weren't breaking the code or changing its behavior. The resulting code is available as a zip file.
Over the next three weeks. we will grow the beginnings of a small accounting system. Here are some of the ideas that will be part of a complete system:
Next time, we will write up stories for this system and play the Planning Game to decide what you will work on for our one release (end of the course) and our three iterations (end of each week).
Most of the significant stories will be written at the beginning of the project and divided into "must have", "nice to have", and "won't have" piles. We will draw up a tentative list of stories for the first iteration, and a less certain list of stories for the remaining iterations. As your customer, I will try to ensure a certain coherence among the priorities I set for the stories. I'll make tradeoffs among the priorities based on feedback of various kinds, including your work each iteration.
As the project goes on, we may add new stories, but in general we expect the number of stories under consideration to trend toward zero.
... communication via wiki and mailing list.
... version control via Subversion, github, or Mercurial.
... common team standards and tools. A common IDE or editor? A common programming style?
Read Hg Init, an introduction to the distributed version control system Mercurial. We may not use Mercurial in class, but this is considered by many to be the best beginner's introduction to distributed version control systems around. Read the first two chapters ("Ground-up Mercurial" and "Setting up for a Team") in some detail. Read "Subversion Re-education" only if you are an experienced user of Subversion or CVS.
By class time on Monday, send me a zip file containing your code. Be sure to include a readme.txt file that says how far you got and outlines any problems or insights that you had.