1. CSA on Rails :
a practical
case-study
Ruby and Rails Devroom
FOSDEM, 24.02.2008
Bernard Dubuisson, CSA
bernard@dub.be
Damien Merenne, Cosinux
dam@cosinux.org
2. About this presentation
“I am no Ruby or RoR specialist and
wouldn't myself call a developper,
I just happened to get my hands on
RoR at the right time and found my
way through it much like a lot of
people did with HTML, 15 years ago.
There's a lot to say about our
quot;real lifequot; project, but not much
on the techy side, I guess.”
3. What this is about
1.Brief context overview
2.Why Ruby on Rails
3.A global description of the
solution
4.Basic project data such as budget,
time spent, ...
5.Strength and weaknesses of ROR
6.Working internally : pros and cons
7.Conclusions
4. Overview : CSA
● CSA = Conseil supérieur de
l'audiovisuel, Regulation authority
for the French Community
● A public agency with a large
autonomy
● 22 people on the payroll
● Lots of documents produced inside
of a legal framework
5. Overview : website needs
● Existing website ...
– Custom made, dynamic (ASP)
– Poor usability
– High maintenance costs
● ... facing new needs
– Evolutive solution
– Management of large amount of
information
– Links between contents
– Evolution of users practices
6. Overview : website needs
● Basic CMS features :
– Access to documents, news, events,
links, ...
– Large amount of data
– Update by several people
● Global objectives :
– Complete information
– Easy access
– Interactivity
8. Why Ruby on Rails
Open source CMS (Drupal) :
the Playmobil approach
– Nice and easy
– Very little customization possible
9. Why Ruby on Rails
PHP :
the Mecano approach
• Taylor-made
• Not much help
10. Why Ruby on Rails
● Ruby on Rails : the Lego approach
– Flexible, easy to assemble
– From simple to complex systems
11. Our methodology
● The development would be
internalized
– 1 in-house developper :
● Project management, information
architecture, usability and webdesign
background
● Out of main attributions
– 1 external coach :
● Professional RoR consultant
13. The solution
● A full featured CMS built with RoR
1.1.6
● Every content can be managed
through forms
● A lot of features are “out of the
box”
14. The solution
● Features :
– Document repository, News and Agenda
(external and internal), Links, FAQ
– “e-Booth” : subscriptions, complaints,
questions, orders,
– Newsletter tool, Meeting support,
Minisites
15. Content models
● Generic Content model (no single
table inheritance)
• Specific content models :
• Pages : generic static page (Tiny MCE)
• Documents : mostly PDF
• News
• Events, Meetings
• Organs
• People, Members
16. Other models
● Other “supporting” models : User,
Menu,Tag, Category, Message,
Visitor, Newsletter, ...
● Role-based access : different
permission levels
● Extranet features : the same page
can render different informations
depending on the user's permission
(ex. Meetings).
20. Hosting
● Hosted on a VPS over at
Railsmachine.com (100$/month)
● Rails dedicated company with
extensive experience and
referential clients
● Eventually, in a datacenter located
in Europe
22. Facts and figures
● Main developper : approximately 500
hours, including learning curve
● Coach : approximately 12 days,
including
– coaching
– development of complex features
– server configuration, deployment,
sysadmin
25. RoR Strengths
– Ruby is easy to learn
– Ruby on Rails is oriented
towards good development
practices :
● Model-View- ● Migrations
Controller ● Use of SVN
● Unit and ● Code documentation
functional testing
● Explicit names
● DRY ● Environments
● Content/layout ● ...
separation
26. RoR Strengths
● Rails provides a rapid development
framework
● You get seldom or never lost or
stuck with problems or errors
– Explicit error messages
– Good community support
27. RoR Strengths
● Rails' production deployment and
official launch worked without
clouds, no application crashes
● Rails has lots of built-in time-
saving features (pagination,
validation, ...)
● Rails community provides a large
range of available plugins
● Ruby is open to third party
applications and technologies, ...
28. RoR Weaknesses
● Ruby is slow
● Needs a special hosting config and
sysadmin care (not fit for shared
hosting)
● Constant evolution of Rails needs
monitoring
● Slow spread among “real world”
developers
29. RoR Weaknesses
● Relying on plugins isn't always a
good thing
● Code can lack clarity (DRY, haiku
style and inheritance)
● Charset use can be tricky for non-
English
30. Confronting RoR “mythology”
● Testing
– Requires a particular set of
competencies, it's not easy and very
well documented (for example, document
upload testing)
– For this reason, we couldn't afford to
complete all the tests that the code
would have required
31. Confronting RoR “mythology”
● DRY
– In some cases, the DRY approach
requires some extra effort that isn't
worth the gain
– Perfection vs. realism : Sometimes, it
can be more productive to just RY
33. Working internally
● A in-house developper with non
exclusively technical attributions,
coached and helped by a
professionnal
● Pros :
– Allows to develop with the user's
needs in mind. Very little user-
developper translation needed
– Reduced cost
– Allows constant upgrading and light-
touch evolutions
– User empowerment
34. Working internally
● Cons :
– Need to find the “right” in-house
profile and competencies
– Attribution conflicts
– Time availability (development spread
over 9 months)
– Authority on the development team
35. Working internally
● Conditions of success :
– Fair amount of trust from hierarchy,
autonomy
– Little pressure on deadlines
– Start from scratch, no legacy
– Backup plan
● Ruby on Rails is the ideal tool for
this kind of user empowerment
37. Conclusions
● Ruby on Rails is a mature,
efficient, powerful framework for
quality web-based applications
● To us, Rails is all about user
empowerment. It allowed us to build
a custom CMS we couldn't have
dreamed of in another context
38. Conclusions
● Reverse approach : Bringing the
user on the developer's ground vs.
bringing the developer to the
user's ground
● Requires the right people and the
right context
● Could become a real nightmare in
the “wrong hands” (see HTML)
● Rails also comes with a philosophy
that prevents bad coding habits