Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Webcast: In the Google Apps Cloud: How to Achieve Your Business Objectives
Dec 3rd, '09, 1 - 2 pm US/Eastern (GMT-5)
Join Council member Brent Hoag, Director, Global IT, at JohnsonDiversey, as he discusses the adoption of Google Apps which has helped meet four corporate goals; sustainability, simplification, increased employee productivity and global collaboration.
Webcast: Collaboration Initiatives: Benchmarks & Best Practices
Dec 15th, '09, 4 - 5 pm US/Eastern (GMT-5)
Join Council members Ruth Thorpe, VP & CIO at the U.S. Pharmaceutical Operations of Sanofi-Aventis, and Gary Kuyper, CIO at Bethany Christian Services, as they speak about their collaboration initiatives and experiences in how and why they chose the social networking and collaboration tools they are using and their business goals for collaboration, and facing culture change challenges.
Data Overview: Collaboration Initiatives Field Guide: Benchmarks & Best Practices
This appendix to the Council Field Guide provides an analysis which discusses benchmarks for collaboration IT implementation costs, adoption rates and payoffs. The overview identifies top IT and business goals and satisfaction rates for collaboration initiatives as well as best practices and lessons learned for implementing collaboration IT.
Learn more about the CIO Executive Council »July 25, 2007 — CIO —
A minor phenomenon has swept the Web world in the last few years. Like many things in the realm of software, it was overhyped. I'm talking about the open-source Web development framework called Ruby on Rails.
Few things live up to their hype. But certainly Rails has at least come close to doing so, and the things that come close are the case studies worth examination.
Not long ago, people were asking whether Rails would succeed. I maintain we're now past the point of asking that question. It has succeeded. Now let's ask: Why?
Born from Real-World Needs
Ruby on Rails had its first public release in July 2004. It's now slightly past the toddler stage. And like a human toddler, it was incredibly active and hard to keep up with. By 2005, David Heinemeier Hansson had won the "Hacker of the Year" award for this software package. In 2006, Rails won the 2006 Jolt Award for best Web development tool. So how did this happen? What did Rails do right, and what did Hansson himself do right?
I should point out here that Ruby and Ruby on Rails are not the same thing. The insiders all know this, but the outsiders and newbies may not. Ruby itself is a language, comparable to Perl or Python, dating back ultimately to 1993. Ruby on Rails, of course, is a Web framework written in Ruby (dating back to 2003 or so).
The first "secret weapon" Rails had was that it was extracted from a real-world application. Rails was not the original goal. The goal was a Web application called Basecamp. As Hansson and others worked on the application, they found out—for the hundredth time—that Web development is painful, time-consuming, repetitive and detail-oriented. This made it a good candidate for coding in Ruby.
In the process of writing this high-level, condensed Ruby code, Hansson started to abstract away the essentials of the interface, and the result became Ruby on Rails. It was born from real-world needs, from working code and from the everyday experiences of developers.
Rails also benefited from what I call the "Write It Twice" principle (which unfortunately lacks a cool acronym). In the process of building a system—especially a large one—a developer learns new information, finds unforeseen issues and problems, and introduces workarounds. Every experienced developer has occasionally thought, "If I wrote this again, I could do it much better." The rewrite is always clearer, cleaner and better code. It's not better just in the academic sense, but also more maintainable, more extensible, more powerful, sometimes even faster. The technique of "write it once, throw it away, write it again" is an incredibly powerful tool, but one that is rarely used because of the time and expense. But that is essentially what happened with Rails; it was written once as the "guts" of an application, and then the rewrite was an abstraction that could be used for any Web application.