CSA on Rails: a practical case-study

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

7. Why Ruby on Rails?

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

12. http://www.csa.be

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).

17. A Meeting page for a regular user

18. A Meeting page for a internal user

19. Plugins
● Authentication
and role-based
access
● Search engine
● Usability features
● Error notification
● Expand RoR 1.1.6
possibilities

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

21. Facts and figures
dub-macbook:~/Sites/trunk dub$ rake stats
(in /Users/dub/Sites/trunk)
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers | 2830 | 2255 | 32 | 246 | 7 | 7 |
| Helpers | 771 | 578 | 0 | 61 | 0 | 7 |
| Models | 1130 | 865 | 44 | 109 | 2 | 5 |
| Libraries | 1111 | 670 | 12 | 57 | 4 | 9 |
| Components | 0 | 0 | 0 | 0 | 0 | 0 |
| Functional tests | 1316 | 959 | 34 | 115 | 3 | 6 |
| Unit tests | 624 | 487 | 19 | 64 | 3 | 5 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 7782 | 5814 | 141 | 652 | 4 | 6 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 4368 Test LOC: 1446 Code to Test Ratio: 1:0.3

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

23. Facts and figures
● Overal cost : < 10.000 EUR
– coach,
– hosting
– productivity tools
– excluding in-house developper

24. Ruby on Rails :
strengths and weaknesses

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

32. Working internally :
pros and cons,
conditions of success

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

36. Conclusions

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

39. Conclusions
Rails is educational

40. Questions ?
bernard@dub.be