APR: Initial Prototype Progress

Made some progress on the prototype for our agile project, getting Users and Articles (see the domain model) mostly implemented and partially tested, and some other parts of the application completed. Ruby has some interesting features for tracking statistics. Read on if you’re interested in that sort of thing.

Prototype Lines of Code Stats

This is a somewhat embarrassing and mildly useless measure of software development efficiency. As part of this project, I am learning Ruby (the programming language) and Rails (the web application framework) and individual plugins, like RSpec (a tool for creating behavior-driven tests). So it seems like in any given hour I will write one line of code and read 1000 pages of tutorials. I hope to reverse that ratio quickly.

Ruby provides a trivial way to report lines of code, with the rake stats command. Here’s the output:

+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers | 139 | 85 | 3 | 16 | 5 | 3 |
| Helpers | 7 | 6 | 0 | 0 | 0 | 0 |
| Models | 77 | 56 | 2 | 9 | 4 | 4 |
| Libraries | 233 | 145 | 3 | 30 | 10 | 2 |
| Components | 0 | 0 | 0 | 0 | 0 | 0 |
| Model specs | 169 | 134 | 0 | 0 | 0 | 0 |
| View specs | 0 | 0 | 0 | 0 | 0 | 0 |
| Controller specs | 0 | 0 | 0 | 0 | 0 | 0 |
| Helper specs | 0 | 0 | 0 | 0 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 625 | 426 | 8 | 55 | 6 | 5 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 292 Test LOC: 134 Code to Test Ratio: 1:0.5

What is interesting is the very last line – it shows how many lines of (functional) code and how many lines of test code have been written. I’ve only written one line of test code for every two lines of actual code. Based on experience with other languages, I would think that the ratio should be over one (more Test LOC than Code LOC).

You’ll also notice that the only test I’ve written are “model” tests – they test the representational behavior, not the interactions. So a big chunk (~1/3) of what I’ve written so far has no testing. Once I figure out how to write controller tests, I’ll make a lot of progress in code coverage.

Rails Design Approach

Rails is set up to use a model-view-controller (MVC) paradigm, and I am using it with the “skinny controller, fat model” philosophy. For people who aren’t programmers, MVC lets you separate your software into three elements:

• Models. Models tend to mirror business objects, like users and articles and reviews. Most functional spec elements are coded here – like “users must provide valid email addresses”
• Views. Purely for rendering. The article linked above shows how many “UI scripting” programmers will bake a lot of logic into the interface directly. Customizing php templates for this blog was a lot like that, until I started writing customizations as plugins.
• Controllers. Handle the transitions of control from model to model and view to view. Some logic happens here, like “users can only view their own account information”

I’m applying “universally good OO practices” and trying to do things “the Rails way.” I don’t plan on blogging all of the design work at the same level of detail as we would discuss requirements and other topics here. If enough of you are really interested, let me know and I will. But I expect most of our readers would consider this article to be “more in depth” than they would like.

RSpec (Requirements Testing) Update

I’ve made a fair amount of progress on this front, at least with respect to testing models. I’ve built an automated test suite that generates the following output (when there are no errors):

C:\dev\svn\ratings>spec -f s spec/models

A user with articles
– must be able to find all her articles TBD

An article
– must have a title
– must have a URL
– must not duplicate an existing article TBD
– must be associated with the user that created it TBD

Multiple users
– must not have the same login ID
– must not have the same email address

A user, in general,
– must have a login ID
– must have an email address
– must have an email address with a valid format
– must have a password
– must have a long password

Finished in 0.359 seconds

12 specifications, 0 failures

What is really exciting is that I am essentially writing a functional spec incrementally – “user must have an email address with a valid format” by writing the tests (Rails folks call them specs because there are also unit tests built into the suite). Unfortunately, I’m also writing the spec in the sequence in which I am coding, which is heavily influenced by the sequence in which I am learning. My preference is to implement “more important” things first, and at a high level, I’m doing that (users, then articles, then ratings).

Working Wireframe

Another neat thing about this approach (both rails, and MVC) is that about 5 minutes spent on presentation resulted in a very quick and dirty wireframe. And the wireframe is actually the functional application.

The header and footer are maroon (we like maroon). The rest of it – “content” “sidebar” articles” and an individual article, are all rendered in black and white (except the blue links). Each logical subgroup of the page has a 1 pixel black box around it. For example, the “content” area includes a header (“Articles”), navigation (top blue link), The set of articles, which is divided into each individual article, which is divided into title, abstract, meta / interactions (show status, edit link, etc).

I’m so new to ruby and rails that I make a lot of beginner mistakes, and move really slowly. But writing php/css/xhtml for the blog has helped me learn so much about how semantic markups and layouts minimize the time required to make changes – so the structure, while it only took a few minutes to implement and set up a style sheet, is probably much more advanced than the ruby code behind it. On the plus side – this means refactoring will be easy. Isolating presentation changes is trivial, and isolating behavioral changes (from presentation) will also be very easy.

Summary

At this stage, the prototype can

• Create/Edit users
• Create, Edit, Update, “Delete” articles

The next things to work on (where work = code + test) are

• Enforce the need to login to create an article
• Associate the article with the user who created it
• Create/Edit ratings (of articles, by users)
• Associate the rating with the user who created it
• Associate the rating with the article to which it applies
• Calculate the article “score” based on ratings
• Add a couple presentations (latest articles, highest scoring articles)
• Add a little styling/layout effort
• Deploy the prototype.

Still planning on getting a prototype version deployed before our second anniversary as a company (Cinco de Mayo).

Anything missing?