Application Design

jules · January 14, 2006, 1:53pm

Hi Railsers,

How do you design your applications? Do you start coding HTML? Start
with the controllers/models? Start in a program like
photoshop/gimp/illustrator/inkscape?

I start in inkscape, it’s a SVG editor. I sketch all the views of my
application, and then I create the views that belong to one controller
in RHTML. After that, I do the models/controller, and move on to the
next set of views.

How do you do create your applications?

Jules

jules · January 14, 2006, 9:01pm

On 14.1.2006, at 14.53, Jules J. wrote:

Hi Railsers,

How do you design your applications? Do you start coding HTML? Start
with the controllers/models? Start in a program like
photoshop/gimp/illustrator/inkscape?

I start in inkscape, it’s a SVG editor. I sketch all the views of my
application, and then I create the views that belong to one controller
in RHTML. After that, I do the models/controller, and move on to the
next set of views.

Hey Jules,

That’s a perfectly valid order and promoted by 37signals, too. Maybe
put writing the tests after your views are ready and you’ll be
Ã¼bercool, doing both test driven [1] and sketch first [2]
development

//jarkko

[1] http://www.43things.com/things/view/7384
[2] http://www.43things.com/things/view/35612

jules · January 16, 2006, 6:55pm

On Sat, Jan 14, 2006 at 01:53:05PM +0100, Jules J. wrote:
} Hi Railsers,
}
} How do you design your applications? Do you start coding HTML? Start
} with the controllers/models? Start in a program like
} photoshop/gimp/illustrator/inkscape?
}
} I start in inkscape, it’s a SVG editor. I sketch all the views of my
} application, and then I create the views that belong to one controller
} in RHTML. After that, I do the models/controller, and move on to the
} next set of views.
}
} How do you do create your applications?

I design the database first, sometimes with an ER diagram and sometimes
with straight SQL DDL. I’m a firm believer in getting the data model
right
(or very close to right) before coding on top of it. I’m also a firm
believer in using the right tool for the job, so I make a point of using
the database schema for what RDBMSs do best (i.e. data integrity such as
foreign key constraints). I’ll generally set up a separate rails test
app
with just scaffolding to test and play with the schema.

Once I’m moderately confident of my schema, I use rails to create the
models. I don’t use the scaffolding for a real app, since I find that
it’s
pretty pointless to have one controller per model and with some
regularity
there is a need for a controller or two that has nothing to do with a
single model. I’ll use rails to generate my controllers, then add stub
action methods by hand. (This assumes that I’ve already figured out
roughly
what operations, a.k.a. controller actions, the user will need.)

I then start adding business logic to the model classes. If I had the
discipline for TDD, I’d also be writing tests for the business logic.
There
is sometimes value to creating standalone business object classes that
deal
with one or more models, but my needs are usually met by putting the
business logic directly in the model. Once I feel like all of the
business
logic for some action is implemented, I’ll write the respective
controller
method. Again, if I had the discipline for TDD, I’d be writing tests for
the actions as well. I’ll work on a rough draft of the action’s view at
this point as well, with the intention of making it pretty later.

When I speak of a rough draft of a view, that doesn’t mean sloppy HTML.
It
means simple, concise HTML with essentially no formatting elements
(divs,
spans, class attributes, styles, etc.). Non-AJAX JavaScript is also
saved
for later. Once I’m done with the functionality, the views get my full
attention, including a single, app-wide stylesheet and occasional
controller-specific stylesheets. If possible, I try to use the same
layout
for the entire app.

When I draw stuff for design, it tends to be on a whiteboard. If it is
intended to become documentation, however, I’ll manually copy from the
board into xfig.

} Jules
–Greg

jules · January 16, 2006, 7:29pm

Gregory S. wrote:

I design the database first, sometimes with an ER diagram and sometimes
with straight SQL DDL. I’m a firm believer in getting the data model right
(or very close to right) before coding on top of it.

Interesting. Unless the data model is, in essence, the application
(e.g., the typical “show my catalog of stuff on the web” sort of thing)
I prefer to start with behavior and class responsibility, and have that
drive what data are needed, and where, and how/what data need to be
stored.

And that process usually starts with use cases and the UI.

But everything tends to evolve based on user feedback and the friction
between what looked reasonable in the abstract and how well it works
when actual humans are poking around.

James B.

–

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

jules · January 17, 2006, 2:01am

I like to start with a database layout too, but I go for the minimalist
approach here as well. Agile development demands that you do only what
is
necessary to make the current test pass. If that means having a cusomer
table with just an “id” and “name” field, so be it. With TDD its easy
to
flush out the db design as work progresses. There will be time to add
address, phone, and bra size later.

The idea is to hold off making structure decisions until the last
possible
minute. Once a data schema is set, it tends to be very inflexible. I
want
to always leave the maximum amount of flexibility in place.

Example - does the “first name”, “last name” fields go in the customer
table, or the credit card table, or both? I’ve built apps all three
ways,
and untill you’ve gotten a lot of use cases, flushed out those cases,
and
even rewritten them with the user, it can be difficult to know which one
is
proper.

jules · January 16, 2006, 7:53pm

I have often found that regardless of the technology it is important to
work on the design by getting a good understanding of the use cases and
then start creating the database model and laying that out. Getting the
database normalized is eventually an incremental process that changes
and grows as the needs of your application changes (ie different use
cases being added or removed etc).

My two cents on this is to work on this incrementally from both sides
(the two sides being the persistence layer and the view layer).

jules · January 17, 2006, 2:01am

On 1/16/06, Mufaddal K. [email protected] wrote:

I have often found that regardless of the technology it is important to
work on the design by getting a good understanding of the use cases and
then start creating the database model and laying that out. Getting the
database normalized is eventually an incremental process that changes
and grows as the needs of your application changes (ie different use
cases being added or removed etc).

My two cents on this is to work on this incrementally from both sides
(the two sides being the persistence layer and the view layer).

I’m working on a project now where I’m trying out a completely new
approach (for me anyway). It’s based loosely on the some of the ideas
presented in Joe Gregorio’s column on how to develop a REST-ful API
(How to Create a REST Protocol)

The hope is that by designing my application with a similar process,
it will help to make it much easier to expose it via a web service or
REST api.

First, I started with the domain model. I know fairly well what the
schema should look like, and what the relationships should be. So, I
create models using

./script/generate model Thingy

And I start writing tests for the model to ensure that I’ve got the
relationships correct, etc.

For the controllers, I have an OmniOutliner document (but you could do
it with plain text just as easily) with 4 columns - this is where I’m
stealing from the REST ideas.

Action: This is something like “Create a new thingy” or “Get all
widgets associated with thingy”
Representation: This is the URI for the Action, e.g. /thingy/show/[id]
Tested: A checkbox, checked if an Action has been written and tested
Method: GET, POST, DELETE or PUT

Then I create a controller (by hand as opposed to generating it, but I
suppose I could do either), and a controller test and I start doing
TDD.

I walk through the outline, and for each action in the outline I write
a test, and implement the action. For the views, at this point, I
don’t care what they look like at all. I just know that on the “Get
thingy” action I need a div that represents the thingy, so I test for
this:

...

With something like this:

assert_tag(:tag => 'div',
           :attributes => {
             :class => 'thingy',
             :id => 'thingyt_' + thingys(:first).id.to_s})

If I get to a controller action which requires something I haven’t
implemented or considered in my domain model, I go back to that and
start writing unit tests.

It seems to be going OK so far. I’m a little worried that I’m not
doing enough “assert_tag” assertions, so I might be missing something.
But as a process it seems to be working.

Lance

Lance B.
http://lance.langwell-ball.com

jules · January 21, 2006, 3:40pm

37signals have written some good articles about application design.
And I’ve heard they use Rails
http://getreal.37signals.com/

There are actually a lot more posts on the topic that aren’t linked
to on that page. Their blog doesn’t appear to have a search field,
but you can go to the archives
http://www.37signals.com/svn/archives.php
and search the page for “getting real”.