By way of introduction, my name is Sarah and I’ve just found this
group. I work for a video game developer in Nova Scotia and run a
graphic
design business on the side: www.triggersandsparks.com. I build a lot
of database-driven websites for my clients, making use of PHP/MySQL and
simple CMS components, and am grappling with making the switch to Ruby
on Rails in order to start building apps that are smarter and faster.
I’m finding it a pretty steep learning curve, though, probably because
I don’t have a proper grasp on Object-Oriented Programming principles
or the concept of the MVC – if anyone can direct me to any resources
that’ll really clarify this for me, I’d appreciate it, but I tend to
learn as I do, anyway, and I’m a highly visual learner, so I’m hoping
it’ll come to me as I fumble along.
Anyway. My question, beyond “what resources do you recommend?”, is
this: how do you go about approaching the development of an
application? I’m trying to develop a series of steps to take when
beginning the design of a web application (specifically how it’s done
in ROR, which I’ve finally got running on my Mac using Locomotive) in
order to maximize productivity and to do things right the first time
around, rather than repeating a lot of steps or going back-and-forth
more than is necessary. How do YOU approach your projects? What comes
first, the frontend or the backend? How in-depth do you map out your
data and schemas and such? Do you define your controllers based on the
use paths, or is it more complex than this?
Any tips, tricks, or insider secrets you cats can throw my way would
make me a very happy girl.
Thanks, and I look forward to making use of this group as I (toes
crossed) progress further into RoR!
Firstly, if you don’t have a copy of Agile Web D. with Rails,
get one now (I think edition 2 is about to ship; you can get the pdf
now).
The last app I built we used what I think is called user stories: we
wrote down on pieces of cards ‘stories’ that take a user on a certain
path though the system.
Then we pretty much sat down and coded each story, i.e. taking things in
vertical slices rather than splitting them into front & backend. When
slices depended on bits of functionality we didn’t want to write yet (eg
because they were best written in the context of another slice someone
else was working on), using mock objects that present the same interface
is a great help.
Beyond that we didn’t really plan in advance the database structure etc.
(although to be fair this project didn’t call for anything fancy). The
slightly tricky bit is getting things going, once you’re up and running
(even with a fairly minimal skeleton) it’s a lot easier to proceed in an
iterative way.
use paths, or is it more complex than this?
All other things being equal, I start with the front end because, as
far as your users are concerned, the interface is the application.
One of the huge benefits of Rails is that it is easy and quick to
make changes, whether to your model, view or controller. I came from
a Java webapp background and it is so much faster in Rails to e.g.
add a field to a model. So don’t worry too much about making
decisions – you can change your mind and fix things up in a flash.
You may also find Getting Real[1] helpful. It’s a book by 37signals
on how they go about building web applications.
As difficult as it might seem at first, try and not get to far down
the track with Rails without learning something about testing.
I know in my experience, trying to incorporate testing into an app at
the same time I was learning RoR feels like a whole heap of extra
material to digest, and then writing tests feels like twice the amount
of work again.
But my first couple of apps built without testing now feel precarious.
Whereas an app built according to test-driven development feels solid
and just ‘right’.
It seems Rails leans on TDD to a large extent. Many plugins come with
tests out of the box, and getting back to your question, TDD
represents a ‘process’ that you can hang your hat on. Indeed, many RoR
developers do so.
I’ve just grabbed a copy of the Beginning RoR Ecommerce book from
Apress and it is a great case study in implementing user stories via
TDD.
…how do you go about approaching the development of an
application?
Only semi-facetiously, I’d say “however the client wants me to.” I would
imagine it also depends a lot on whether you’re working alone or with a
team – I mostly work alone.
Some come with a precise idea what they want, and all the html they want
used, and I do that whether it represents “best practices” or not. It’s
my job to give them what they want, not to evangelize modern methods of
software development.
My overall strategy, as of today, is to define the database schema,
write as much as possible, and get something up and running as quickly
as I can. I rely heavily on TDD during this phase.
Then I get a barrage of emails from the client to change this or that,
and do so as quickly as possible. I also work on server configuration
and capistrano deployment during this phase, and write whatever
background tasks I need (database backup, session expiry, etc.).
After each deployment, I watch the server and the logs like a hawk for
some time, to make sure everything is actually working like I expect it
to, and fix any problems as rapidly as possible. Even with a client who
knows exactly what he wants, it doesn’t seem uncommon for me to do a
couple of revisions a week for a while.
I continuously refactor and try to catch up on tests, which by this
point have fallen way behind due to time constraints – I tend to make
the changes my client wants first, put them into production as quickly
as possible, and write the formal tests for them when I have time to
catch up.
–Al Evans
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.