CSA on Rails: a practical case-study

2,205 views

Published on

CSA on Rails: a practical case-study

Published in: Economy & Finance, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,205
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CSA on Rails: a practical case-study

  1. 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. 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. 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. 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. 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. 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. 7. Why Ruby on Rails?
  8. 8. Why Ruby on Rails Open source CMS (Drupal) : the Playmobil approach – Nice and easy – Very little customization possible
  9. 9. Why Ruby on Rails PHP : the Mecano approach • Taylor-made • Not much help
  10. 10. Why Ruby on Rails ● Ruby on Rails : the Lego approach – Flexible, easy to assemble – From simple to complex systems
  11. 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. 12. http://www.csa.be
  13. 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. 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. 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. 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. 17. A Meeting page for a regular user
  18. 18. A Meeting page for a internal user
  19. 19. Plugins ● Authentication and role-based access ● Search engine ● Usability features ● Error notification ● Expand RoR 1.1.6 possibilities
  20. 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. 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. 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. 23. Facts and figures ● Overal cost : < 10.000 EUR – coach, – hosting – productivity tools – excluding in-house developper
  24. 24. Ruby on Rails : strengths and weaknesses
  25. 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. 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. 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. 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. 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. 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. 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. 32. Working internally : pros and cons, conditions of success
  33. 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. 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. 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. 36. Conclusions
  37. 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. 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. 39. Conclusions Rails is educational
  40. 40. Questions ? bernard@dub.be

×