From Idea to Implementation

One of my foibles is that I have a hard time coming up with the "spark" to start off a project, which is part of the reason I gravitated toward this project. It has a massive vision; one which I didn't help to create. I didn't come up with the idea, I didn't spec out the requirements, I didn't initially communicate with the client to determine their interests, and I'm quite pleased. My goal is to realize this vision. I'll make plenty of decisions along the way, but these decisions affect how the product is designed internally rather than what features it'll support.

The first action I took on this project was to condense the huge mind map created by Lee and the Client in to an Object Diagram. I used an online service called Gliffy for the UML constructs. The relationships between objects would serve as the basis for my Rails relationships later down the line. I gradually shaped the Object Diagram in to a Database Schema of sorts, carefully considering what kinds of joins to use for each relationship.

It's this sort of planning that really helps down the line. With the database schema/object diagram in hand, I began scaffolding out each of the objects in Rails. Scaffolding creates a rudimentary model, view, and controller for each object as well as a table in the database with all the columns specified during the scaffolding process. The newly scaffolded object contains four basic views/actions: index, show, edit, and new as well as three additional actions: create, update, and destroy. The scaffolding process really help throw down a lot of base code quite quickly.

Once enough objects are scaffolded, associations between the objects are established in the model. Most associations are readable in English: A User has many Projects. A Project belongs to a Category. A Project has and belongs to many Tags. The type of association determines which table the foreign key is located in. Simply adding an association creates helper method. Calling user.projects returns an array of projects; calling project.category returns a singular category. Rails does a lot of pluralization magic behind the scenes: it knows the plural of category is categories, for instance.

With the associations figured out, the next step is to start linking together the objects on each others views. This creates a sort of hierarchy. Ideally, I want to be able to reach any instance of an object through a series of links.

Next, it's time to start defining how objects actually interact with each other. What does each association mean for the user, and how should individual relationships between instance be created and managed? This stage typically means a lot of UI design, and for this project we're using jQuery as a library.

This step is where Nexus is now. All the fundamental models and associations are established, now it's time to smooth together each relationship.

Once that's done (which will be quite a while, this is perhaps the longest phase), we'll integrate the design elements of the layout, round out any remaining problems, and deploy.

Next time I'll talk a bit about some of the "trick" polymorphic associations I'm using and dive into some of the Ruby behind certain aspects.

-Reilly Hamilton