Forum: Ruby on Rails Managing a Rails project

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Steven R. (Guest)
on 2006-04-05 09:42
(Received via mailing list)
Can someone point me to some good ideas about managing Rails
development - like what would be a good way to document all the
models and controllers and methods that might result if several
people are prototyping on different parts of a system, and what might
be a good structure for pushing back code into SVN as scaffolds are
turned into real projects - that sort of thing. I'm just starting to
learn the nuts and bolts of how the environment works, so I haven't
quite gotten my brain around what the process would be like for
building a system that's bigger than what would fit in one person's
head while they're railing away.  Maybe that's so specific that there
isn't much useful universal advice, but just a blog about someone's
specific experiences would be helpful. e.g. would you try to document
or diagram models, controllers, and methods as they're built, or is
there a good way to reverse-engineer that out of the system
periodically?

Thanks,
Steve
Craig A. (Guest)
on 2006-04-05 10:06
(Received via mailing list)
Hi Steve,

A lot of people interested in running rails projects are also into agile
development methodologies. The best known rails book, for example is
"Agile Development with Ruby on Rails", which although it doesn't talk
about agile project management practices, does tend to espouse the view
that rails development is fast enough that many of the traditional bells
and whistles of "big up front design" style project management (with
much diagramming and so forth) are not necessary.

37signals has a little book out called "Getting Real", which talks about
there experiences, and also pushes a very agile line. Their book is from
an entrepreneurial or business management point of view, and may be of
interest to you if you are managing a rails project. Also, I think that
most people could do a lot worse than reading up on Extreme Programming,
which is one of the most widely known agile methodologies available. The
bible for that is probably Kent Beck's "Extreme Programming Explained
(2nd Edition)".

My experience developing rails apps is certainly along these lines.
Don't follow conventional wisdom from the 80's and 90's that says you
need strict documentation for your development. Instead, just follow a
constant cycle of iteratively making things better. To respond
specifically to your comments;

Subversion
Yes, use SVN all the time. Right from the start. Yes, check those
scaffolds into subversion. When should you commit to SVN? Constantly! I
do so ever time I add a new feature, about every 20 minutes.

Documenting models, controllers and methods
Don't do it! Why bother? Ruby code is clean and readable, if your code
isn't readable, don't spend time documenting it, spend time cleaning it
up so that it's readable again. If you really want documentation that
you can rely on, consider writing tests instead. They explain in no
uncertain terms what the system does, and they will never get out of
sync with the code (because you'll run them constantly). Disclaimer:
Documentation is still needed if you are releasing a web framework,
rather than a web application.

Fitting your system into several people's heads
This will work fine. Yes, I know it didn't always work fine with big
messy PHP or Perl apps. However, rails organises things into a tidy
stack, and neat vertical slices. Anyone who knows how rails works can
dive in and understand, providing the code is clean. I've tried multiple
developers in a rails app, and it works fine. Have a look at the "no
code ownership" ideas and practices which are part of the extreme
programming methodology for more ideas about how this can be done well.

hope that helps,

Craig
Bill W. (Guest)
on 2006-04-05 16:15
(Received via mailing list)
Hi Steve,

In addition to Craig's suggestions, you might also want to consider
joining
the Agile Project Management group at
http://finance.groups.yahoo.com/group/agileproject...

Good group of folks.

Best regards,
Bill

----- Original Message -----
From: "Steven R." <removed_email_address@domain.invalid>
To: <removed_email_address@domain.invalid>
Sent: 2006-04-05 12:39 AM
Subject: [Rails] Managing a Rails project
Federico F. (Guest)
on 2006-10-09 23:49
I think that UML collaboration diagramms (or something close to them)
are great as modeling tools for developing web applications with RoR.

I'm trying them now in a project, and will let you know the results.
Starr (Guest)
on 2006-10-10 00:54
(Received via mailing list)
Hi Federico,

I'll be interested in your report. It would be neat to be able to use
UML as a front end for a kind of "super scaffolding" generator.

Starr
Federico F. (Guest)
on 2006-11-26 23:25
(Received via mailing list)
Hi Again :)

Well... the project is almost done. We didn't use Rails, because I
didn't have Rails programmers (instead, we had to use PHP+Smarty), but
we used sequence diagramms that imitates Rails MVC model. The result
was awesome: once that the diagramms were ready, the programmers
understood the application completely. Before starting the
implementation phase, one programmer told me: "wow I can see the whole
application, I know exactly what I have to do".

I made a plan of 5 releases, and they were executed without any
problems. Tomorrow the 5th release will be done, 3 weeks before the
death line.

Now I'm starting a new project, and I will use this technique again in
the design phase, but adding TDD for the implementation phase, and
Rails. If this project goes as well as the first one, I would like to
develop a graphical IDE for Rails... I think it would rock.

Anyone interested in such a tool, please leave the message. I think I
would start working on this in January.

Cheers,
Federico F.
Phlip (Guest)
on 2006-11-26 23:41
(Received via mailing list)
Federico F. wrote:

> Now I'm starting a new project, and I will use this technique again in
> the design phase, but adding TDD for the implementation phase, and
> Rails. If this project goes as well as the first one, I would like to
> develop a graphical IDE for Rails... I think it would rock.

Google "Waterfall". Your PHP project went well because Waterfall is
indeed a step up from Code-and-Fix.

However, if your project was larger, then a "design phase" would
conflate any mistakes in design. Your "implementation phase" would
suffer.

Use TDD essentially the same way Rails has used it on itself. Design a
little, code a little, deliver a little, and repeat in small cycles.
Write tests for everything, to make frequent releases safe.

I met with a team using Rails the other day, and unless I
misunderstood them, they seem to be releasing each integration. They
seem to have no "staging server", where most commercial web
applications deploy their source into a simulated production
environment, for smoke-tests before the






















                                main deployment. Unless I
misunderstood them, they could apparently change their code on their
own desktop, pass their tests, hit a button, and deploy this new
feature directly to their live server.

That is "agility".

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Federico F. (Guest)
on 2006-11-27 06:18
(Received via mailing list)
Hi Philip,

Yes, I didn't use an "Agile" approach for this project, because even
though I like some ideas from XP and Scrum, I also like some from CMMi.
So , I'm currently working on a process that mixes what I think is the
best of both worlds.

I do belive that you need to design what you are going to code, before
coding it, and it may be a good practice to do TDD after you have these
design documents. I also think that you need much more less design
documents than those available in RUP.

But, of course, I also don't think that there is THE best way to
develop software. I think it depends on the people you have in your
team.

Cheers,
Federico
Phlip (Guest)
on 2006-11-27 08:04
(Received via mailing list)
Federico F. wrote:

> Yes, I didn't use an "Agile" approach for this project, because even
> though I like some ideas from XP and Scrum, I also like some from CMMi.
> So , I'm currently working on a process that mixes what I think is the
> best of both worlds.
>
> I do belive that you need to design what you are going to code, before
> coding it, and it may be a good practice to do TDD after you have these
> design documents. I also think that you need much more less design
> documents than those available in RUP.

RUP is an "agile" process too, and it does _not_ specify that you create
lots of design documents before coding.

> But, of course, I also don't think that there is THE best way to
> develop software. I think it depends on the people you have in your
> team.

There are, however, worst ways.

One of the biggest impediments to adopting TDD is the amount of effort
you
must spend learning to retrofit tests into existing frameworks. (This,
in
turn, is a good way to vet the quality of those frameworks. Attrocities
like
ASP.NET should be shunned _specifically_ because they are hard to test.)

Rails, however, provides a testing framework matching most of its
features.
So all you need to do is just start extending the tests, in parallel to
how
you extend the application.

So the ultimate goal of TDD, Emergent Design, is within reach of anyone
as
soon as they generate their first Rails application.

--
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Federico F. (Guest)
on 2006-12-02 17:20
Ok, googling a bit I found that RUP can be used for agile development...
some artifacts, some rules... but it is not an agile process from its
beggining.
Anyway, perhaps you have a broader definition of "Agile" in your head,
than I have in mine. It's not the point.

The real point is CMM/CMMi and it's relation with Agile methodologies.
If you like CMM it is hard to accept pure XP, Scrum... So my intention
is to find a way to adopt an Agile process that fits CMM aswell.

Googling a bit again... I found a paper of some person talking about
"stretching" Agile to make it CMM level 3 compliant. I will read it as I
read more about agile and TDD. Specifically, my doubt now is if you can
design your software with at least one or two UML diagramms before doing
TDD.
Bill W. (Guest)
on 2006-12-02 18:19
(Received via mailing list)
Hi Federico,

Federico F. wrote:
> So my intention is to find a way to adopt
> an Agile process that fits CMM aswell.

You might want to check out www.niwotridge.com.  Glen Alleman is one of
the
most experienced folks around wrt utilizing agile development methods
within
a CMMI-compliant overall PM infrastructure.

hth,
Bill
Phlip (Guest)
on 2006-12-02 23:36
(Received via mailing list)
Federico F. wrote:

> The real point is CMM/CMMi and it's relation with Agile methodologies.
> If you like CMM it is hard to accept pure XP, Scrum... So my intention
> is to find a way to adopt an Agile process that fits CMM aswell.

XP satisfies all the CMM KPAs for one team. All the "manage your
process"
stuff.

This requires you to actually _do_ XP (just as CMM actually requires you
to
do it, not just speak it!).

A CMM certifier should rate an XP team at Level 3 and part of 4, at
least.
The remaining KPAs are the inter-team stuff, which XP naturally does not
cover.

For example, pure XP requires an Onsite Customer (a "business analyst"
role)
to author acceptance tests. These tests are analysis, and documentation,
and
requirements gathering, and - uh - tests. All in one. So the KPAs that
require those things are satisfied.

Projects without acceptance tests are not XP, so they also should fail
CMM
certifiation.

> Googling a bit again... I found a paper of some person talking about
> "stretching" Agile to make it CMM level 3 compliant. I will read it as I
> read more about agile and TDD. Specifically, my doubt now is if you can
> design your software with at least one or two UML diagramms before doing
> TDD.

CMM does _not_ require you to draw diagrams before you write code.

XP does _not_ forbid them, either.

People practicing XP learn that they need such diagrams less often.
This, in
turn, increases the value and meaning of such diagrams when they are
used.
So people practicing XP often write about their experiences, leading to
a
myth that things like UML and debuggers are forbidden.

A company at CMM Level 5 should lose their certification if they don't
try
XP in a pilot project, per the KPA "experiment with new processes and
learn
from them".

--
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
This topic is locked and can not be replied to.