Evidence of Best Practices
Our group elected to start a Google Code project, which includes a website and wiki system.
The address of the project is
The wiki served as a central location for sharing information such as how to set up Ruby on Rails and
links on tips for how to implement certain features in Ruby. We also used the wiki as a place to store our
es rough drafts. Please see the screen shot below as evidence of discussion.
Project Management Site
As mentioned in the previous section, our group chose to begin a Google Code project called
“Yesdatabas”. Please see the front of our site in the screen
Once again, our Google Code site fulfills the code repository best practice requirement.
We chose to use
SVN rather than Git for revision control. Our team members used SVN clients such as TortoiseSVN to pull
of the code from our repository. Please see the screen shot containing a history of
commits below as evidence of our code repository.
Documented Coding Standards
Our group adopted the Ruby coding standards explained in the Unofficial Ruby Usage guide, wh
be found at this web address:
The standards make it clear how many characters should reside on one line (no more than 80), how to
ent code (using the # sign followed by one space before a comment), how many spaces
to use for indentation (exactly two), how many spaces should separate operators (one on each side
during assignment and none thereafter).
Perhaps the most important reason
for adopting co
ding standards is that Ruby adjusts the naming of its
objects based on generation scripts provided in the command line. For instance, if the programmer
specifies that he wants to create a user class, Ruby will create a database named “users
”, adding an “s”
to the end. When
one edits the code automatically generated by
, they must remember these
naming conventions when implementing specific features not found by default.
Please see the screenshot below, noting that the class user c
ontroller is named using Camel Case (i.e.
BigFatObject) and that there are two spaces used for indentation on every line. Comments are used
properly and blocks are correctly implemented (with the if/else/end statements using the same
Google Code provides functionality for tracking bugs in the “Issues” section of a project website. Our
group did not face many bugs because the issues were noticed before any commits were made. The
bugs were almost always easily fixable and m
ore time would have been involved filling out a bug report
than just fixing a simple error in Ruby. The nature of the Ruby on Rails environment made fixing small
bugs easier; however it did lead to several confusing errors involving page routing and data d
which were reported using the Bug Tracker. The Bug Tracker allowed us to report how to experience the
errors by listing what steps should be taken to reproduce them. We also documented what errors were
experienced using screen shots as attachme
Please see the two screen shots below: the first containing a list of bugs and the second
example of a bug itself.
Third Party Component or Tool
Our group used the bcrypt
utility for encrypting passwords stored in our CMS’s database. It is important
to encrypt the passwords because if the system were somehow compromised, the compromiser could
obtain a list of plain text passwords found in the SQL database. We elected to us
e the cross
encryption tool bcrypt. Normally, bcrypt is used for file encryption; however we used a version
customized for safe password storage in Ruby.
It should be noted that the third party tool does not come with our software package, but mus
downloaded separately. This is because Ruby requires use of gems that must be installed to the Ruby
environment itself and not the individual project written in Ruby.
Please see the screen shot below
Note that the tool is installed to the Ruby “lib “directory and not the
Yesdatabase “lib” directory because of the nature of Ruby on Rails add
Design Pattern Implementation
By adopting the Ruby on Rails programming language and environment, our gro
implemented the Model/View/Controller design pattern.
It is an architectural design pattern, which
means it describes all of the elements in the framework and how they ought to relate to each other.
The model contains information about wh
at data is being stored and how it is connected to each other
(for instance, our group contains a user class that may perform such actions as creating custom
database fields and uploading custom cascading style sheets).
The view renders the model in a mann
er appropriate for a user’s needs. In Ruby, this is always an html
page. We have views for listing all users found in the database as well as
view for individual user
The controller acts as a liaison between the view and the model to receive
input and change the model
or view appropriately. In the case of our project, a user many want to update his address, so the
controller captures his input, alters the data in the model and then instructs the view to display an
updated version of the user
Our project contains a user model, two models for describing data fields in relation to users and a model
listing the location of the style sheet.
We have the main application controller, a controller for the CSS upload, one for the custom field
tionality, one to login and authenticate users and another to manage the user accounts.
Lastly, we have views for changing the CSS, creating/editing/deleting custom fields and user accounts
and a view for logging users in to the site.
see the screen
shot below of the directories in our project folder containing the code
models, views, and controllers.