Structuring larger RoR projects/systems

Hi,
I am considering using RoR
for a quite sizable project involving 10-15 developers. I am very
experience with other technologies such as Java and C++, and I would
know how to structure a system so that different developers can work
with different parts of the system without stepping on each others
toes.
In Java I could use eclipse and have different projects for the DAO,
the
application layer, the web layer, etc etc.

With MVC model in RoR and the way RoR projects are structured I am a
not
sure how to structure a project. Clearly I certain Ruby components
could
be separated out in separate projects.

What are the common ways that larger projects have been structured to
facilitate effective development (turn around leveraging the MVC
model)
and at the same time separating system structures into manageable
pieces.

Thanks a lot of any feedback, and sorry if this was the wrong forum.
But
I did not see any on more general applications engineering.

Regards
Jari Koister

It's easy to write an application that won't scale using pretty much any technology. In particular, the more complex the configuration and layering, the more opportunity (IMO) for a tight coupling that won't scale out well. Alternatively, you can use a shared-nothing architecture and scaling out becomes a far easier task. Many enterprises don't need scaling in the sense of handling millions of pageviews a day so be sure you have a problem before you identify scalability as a criterion.

In terms of development team structure, this will take some getting used to. ThoughtWorks is putting teams onto enterprise Rails projects to good effect, so they might be a good consulting resource if you get hung up on this. If I were setting up a team, I would make the cornerstones of development:

1. Spec first, code later. That way it doesn't so much matter who does the implementation so long as the behavior is described accurately
2. Create business-relevant user stories.
3. Identify thin vertical slices and implement these in your iterations.
4. Only use developers who are comfortable with distributed source-code control (like Subversion).

Rails is pretty darn opinionated about what parts of the application logic belong where. You can make changes to suit your needs, but at the end of the day, what's in Rails, and really fire-tested is the three-tier model-view-controller pattern where the model handles both database communication and business logic, the controller handles glue between model(s) and views, and the views are the presentation layer. You can add layers (like presenters) but right out of the box, the separation of responsibilities is pretty easy to grasp and new developers brought onto the team who have Rails experience will understand your code pretty quickly.

I don't know anything about your business needs, but if you have any doubts about Rails' ability to do the job, find a consultant with a portfolio of clients similar in size to your company. Hire them to write a whitepaper on the pros and cons of using Rails to solve a particular problem (including specifics of traffic, security requirements, time-to-develop, maintenance costs, labor pool, etc.). Getting a professional with this kind of experience to provide you a technology assessment will provide a recommendation from an expert with known qualifications and very likely would begin a business relationship between you and that company as you bring your team online.

I mentioned ThoughtWorks because they have a good client portfolio. There are a number of other, smaller companies who could be even better positioned to provide the information you need.

This would be my reply in general to anyone who is interested in Rails for your enterprise application. Hire a pro. Pay that person or small team well to spearhead your effort.

Jari,

If your team is already familiar with Eclipse, I would took into the
Aptana plugin for Rails (formerly RadRails). As mentioned, it's an
Eclipse plugin that's Ruby and Rails aware so it provides nice syntax
highlighting, subversion and CVS integration, integrated Webrick and
Mongrel servers, etc. Personally I prefer the RoR-aware netBeans 6.0,
but Aptana might be a better solution if your team is already used to
Eclipse.

The MVC architecture probably maps fairly well to the type of
structuring that you are used to, with the exception that you might
keep the entire application in a single project. The application/
business layer should correspond very closely to the Model tier. The
web layer is primarily the View/Controller tiers. (Note: there is no
DAO per se, since the Rails opinion on DAO was to use the ActiveRecord
pattern in which a DB row is wrapped in an object that understands how
to persist the data).

Rails 2.0 offers an additional structuring option. If you are able to
break your application down into logical subsystems you could develop
each subsystem as a separate Rails application. This might allow you
to use smaller teams of 2-5 developers who can closely collaborate on
a specific aspect of the application. Make sure that these subsystems
use the Rails-standard REST interface. With that you can create a
'top-level' web application that makes heavy use of ActiveResource,
This application is UI-only, retrieving the necessary data from each
of the subsystems through ActiveResource. Your main UI (weblayer)
team works here. I have one project that is working on a structure
like this and it's working farily well. One of the great advantages
of it is that you may be able to re-use one of the subsystems (e.g.,
Billing & Financials) for other applications -- not just reuse the
code but actually using the deployed subsystem.

HTH,
AndyV

AndyV,

Rails 2.0 offers an additional structuring option. If you are able to
break your application down into logical subsystems you could develop
each subsystem as a separate Rails application. This might allow you
to use smaller teams of 2-5 developers who can closely collaborate on
a specific aspect of the application. Make sure that these subsystems
use the Rails-standard REST interface. With that you can create a
'top-level' web application that makes heavy use of ActiveResource,
This application is UI-only, retrieving the necessary data from each
of the subsystems through ActiveResource. Your main UI (weblayer)
team works here. I have one project that is working on a structure
like this and it's working farily well. One of the great advantages
of it is that you may be able to re-use one of the subsystems (e.g.,
Billing & Financials) for other applications -- not just reuse the
code but actually using the deployed subsystem.

sounds great - could you please give me some more details - keywords,
tips, hints - especially (if possible) where to look for advice,
tutorials, examples and/or howtos? Any help would be most welcome

:wink: