On Feb 8, 2008, at 1:52 PM, jarikoister wrote:
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 K.z
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:
- Spec first, code later. That way it doesn’t so much matter who does
the implementation so long as the behavior is described accurately
- Create business-relevant user stories.
- Identify thin vertical slices and implement these in your iterations.
- 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.
