Perhaps you are an architect or a software developer working for a large company. You would like to try out using Ruby on Rails for that next project coming along at work. It would be a perfect fit, so you speak to your boss and he says *NO*.
In this paper, we will explore how to change that answer to *YES*.
h3. Risk
The main reason why your manager said “no” is because of risk. Managers are afraid of risks – in fact, it is part of their job description to mitigate any risks. Introducing a new programming language and a new application framework are two very big risks that most managers will avoid.
h3. Baby steps
To minimise the perceived risk, we need to take “baby steps”, or small increments along the pathway to introducing Ruby on Rails. If you can show the Ruby technologies being used successfully in some lower risk scenarios, then your manager may be willing to try it out for a larger project.
h3. Our experience
Some of our clients are beginning to trial Ruby for very simple tasks. Others are now using it for intranet style applications. Some have totally embraced the Rails framework, and are using it for all of their new development.
h3. Watir
“Watir”:http://wtr.rubyforge.org/ provides a Ruby API for controlling the Internet Explorer web browser. This may not sound particularly exciting, but if you combine this product with the unit testing abilities of Ruby – you have an excellent functional testing tool.
There is also a Firefox variant being developed called “FireWatir”:http://wiki.openqa.org/display/WTR/FireWatir+-+WATiR+for+FireFox
We have used Ruby and Watir for developing the functional test scripts for several clients – with excellent success.
h3. Scripting
Ruby is a scripting language. If you have a scripting task to perform, it may makes sense to use Ruby for achieve it. An advantage to scripting in Ruby (compared with shell scripts), is that they can be easily run on Windows too.
There is a new book from the Pragmatic Programmers called “Everyday Scripting with Ruby”:http://www.pragmaticprogrammer.com/titles/bmsft/index.html which may be worth a look.
h3. Scaffolding
As most Rails developers know, scaffolding is not intended to be used by end users. But, an opportunity you have is to use Rails scaffolds for data maintenance.
It is possible to devote a lot of effort in building data maintenance screens – for just one or two system administrators. What you can do instead, is to use the scaffolding approach to quickly build some basic, yet functional administration screens.
h3. Fixtures for test data
The fixtures facility that is built into Rails provides a powerful way to define and maintain test data. You can use the Rail based fixtures in combination with your Java or C# based application. All of your test data will be defined in a YAML file, and you use rake to deploy it.
You could also define your database schema with the Ruby migrations facility. And then push out your schema changes in an iterative manner.
h3. Intranet applications
Before you build a public web application based on Rails, you probably want to try it out internally first. This will allow you to become familiar with some of the non-coding features of Rails. For example, you will need to learn the appropriate way for your organisation to deploy the application, the database schema, batch tasks, load balancing, etc.
h3. Conclusion
Deploying any new technology can be a risky business. These risks can be minimised by taking small steps along the pathway towards the goal of a fun, productive web development.
h3. Further reading
Why not read some of our other “papers”:papers, or subscribe to our “Blog”:blog. Feel free to “contact us”:contacts for more information.