APR: Initial Prototype Progress

working under the hood

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.

first wireframe

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?

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

2 thoughts on “APR: Initial Prototype Progress

  1. Hi Scott,

    you wrote about the sequence of things you develop: users, then articles, then ratings. Here’s my somewhat methodologic question, just because I’m curious:
    Why do you start with users? And why do you put ratings after articles?
    The prioritization of the use cases gives me “browse an area”, “suggest an article”, and “comment an article” as the winners. I don’t believe you really need users for these three. Also, the next thing after articles should be comments.
    I understand you need articles with areas in order to browse them, so the second prio could be transformed in a function that is implemented first: suggest an article. Once you can suggest, you can prowse and and you can comment.
    Please expand on this a bit. Cheers to your Ruby skills anyway!

  2. Hey Rolf, thanks for asking some great questions.

    Articles are being implemented before ratings because my domain model of ratings is that they are “created by users, about articles” – so having an article to rate (or review) needed to be implemented before I could implement the rating or reviewing.

    An only registered users can create articles, so Users has been implemented before / concurrently with articles. We need to have some users logged into the system and submitting articles in order for the rest of the users to be able to browse them.

    I think the very first prototype may only have the “our niche” top level area – I really want to get it out tomorrow (Saturday at the latest). I am leaning towards areas being pre-defined (like digg). In that case, it may make it into the first prototype.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.