Andy M. wrote:
Unfortunately every customer needs a specific customized user interface
and sequence of dialogues, but the general business logic is the same.
So my question: Is Ruby on Rails capable for this kind of requirements?
Absolutely, if you can set some ground rules.
What you are selling is not a finished app, but a series of feature
To solve each feature request as soon as possible, you need a Capistrano
on your customers’ servers. That means, each time you finish a request,
enter ‘cap deploy’, and the end users’ experience upgrades in real-time,
between page hits.
On your side, to satisfy these feature requests, you need highly
with absolutely saturating automated tests. That is what Model View
and unit testing are all about. Each time you make one tiny edit, you
the tests for that model, view, or controller. If the edit is for a
one customer, the tests defend the user experience for all the other
A colleague of me has already begun to develop a complete new web
application framework in pure java and servlets without using any
existing web application framework technology. He has almost no
background in web applications and is doing it all alone.
Unless he is a supergenius who deserves to become our next overlord, he
epic-fail. Your goal now is to prevent the inevitable, as soon as
My thinking is that this strategy is a big mistake. In 2008 it is
essential to use a mature web application framework for a small company
with not more than 3 web developers.
Absolutely. You will spend all your time on the plumbing. May I ask if
is working alone, long hours, at home, and without unit tests or
Developing a own new framework makes no sense at all. Especially for a
small company with a very niche market.
Rails is exactly what you need. Firstly, it is dynamic, so you can do
stuff in much fewer lines of code than Java. Some guestimates place the
code lines at 1 to 10.
Next, Rails leverages unit tests, so you can write new tests that target
high-level things, without reinventing their plumbing.
Next, Rails makes “metadata” rather easy. You will soon discover that
customer needs a different configuration. This topic is called “Software
Lines” - look it up. As you add configurations, you will add unit tests
cross-check their methods. The more product lines the better, because
configurations and unit tests work together to cross-test everything,
soak-test all your code abilities.
These techniques do not require heroism. They require small, co-located
typically pair-programmers, who work reasonable hours. A week of work
consists of collating the feature requests with highest business value,
each one down, and deploying the application when each one is finish.
Your colleague is raising the risk much higher than you need.