CSA on Rails :a practicalcase-studyRuby and Rails DevroomFOSDEM, 24.02.2008

Bernard Dubuisson, CSAbernard@dub.beDamien Merenne, Cosinuxdam@cosinux.org

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 "real life" project, but not much on the techy side, I guess.”

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

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

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

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

Why Ruby on Rails?

Why Ruby on Rails

Open source CMS (Drupal) :

the Playmobil approach– Nice and easy

– Very little customization possible

Why Ruby on Rails

PHP :

the Mecano approach• Taylor-made• Not much help

Why Ruby on Rails

● Ruby on Rails : the Lego approach– Flexible, easy to assemble

– From simple to complex systems

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

http://www.csa.be

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”

The solution

● Features :– Document repository, News and Agenda (external and internal), Links, FAQ

– “e-Booth” : subscriptions, complaints, questions, orders,

– Newsletter tool, Meeting support, Minisites

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

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

A Meeting page for a regular user

A Meeting page for a internal user

Plugins

● Authenticationand role-based access

● Search engine● Usability features● Error notification● Expand RoR 1.1.6 possibilities

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

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

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

Facts and figures

● Overal cost : < 10.000 EUR

– coach,– hosting– productivity tools– excluding in-house developper

Ruby on Rails :strengths and weaknesses

RoR Strengths

● Model-View-Controller

● Unit and functional testing

● DRY

● Content/layout separation

● Migrations

● Use of SVN

● Code documentation

● Explicit names

● Environments

● ...

– Ruby is easy to learn– Ruby on Rails is oriented towards good development practices :

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

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

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

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

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

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

Working internally :pros and cons,

conditions of success

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

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

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

Conclusions

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

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

Conclusions

Rails is educational

Questions ?

bernard@dub.be