It is both an interesting and chaotic time in the software development. There are always new emerging technologies on the software development stage, and at the same time many disappear because they are not able to withstand the fast pace. One of the problems that today’s programmers face is to decide which technology they should learn next. The questions that arise about a new technology usually are: How high of a demand does the technology have? What advances does it bring over the other ones? What is the learning curve? How intuitive is it to use? Is it going to be used by everybody? How will it develop to satisfy the new requirements that will appear with the time?
The long term trends for the first 10 programming languages according to Tiobe Software. [source: http://www.tiobe.com/index.htm?tiobe_index]
Ruby on Rail (RoR) is a platform for web development which follows the Model-View-Controller paradigm. RoR includes all necessary tools to develop a modern web application. Ruby is the programming language and Rails is a rapid development framework fully implemented in Ruby. Ruby is a pure object-oriented and open-source programming language developed by Yukihiro Matsumoto. Ruby has been around since 1993. It is language with a very clean syntax and it looks very close to the natural human language. The developer wanted to create a language that would make him more productive and be fun to use at the same time . The Rails framework enables rapid development for database-oriented web applications. Rails was created by a Danish student David Heinemeier Hansson and it was released to the public in 2003. Rails is a full-stack framework. Hansson explains that all the layers of the framework are built to work together so that code repetitions are avoided. This is called DRY or “don’t repeat yourself”. There are two main principles that Rails follows to achieve DRY. The first is the “less code” principle which calls for code that is easier to read and maintain and contains less bugs. This is possible because the Rails framework can handle metadata. The second principle is “convention over configuration,” this means that Rails does not use configuration files but relies on simple programming conventions . Developing in Ruby on Rails follows the incremental agile development methodology. This is possible because Ruby uses direct execution model and dynamic typing. Hansson describes that as: “Make a change, see it work” . Much of the controversy surrounding RoR revolves around the question of whether or not Ruby on Rails will become a serious development tool or is just a temporary technology for developing smaller projects. RoR comes in a time when developing a modern application involves expertise in a lot of the existing web technologies. RoR wraps all these technologies into one coherent framework which should make the development easier, more intuitive and faster.
&quot;Convention over Configuration&quot; means a developer only needs to specify unconventional aspects of the application. For example, if there's a class Sale in the model, the corresponding table in the database is called sales by default. It is only if one deviates from this convention, such as calling the table &quot;products_sold&quot;, that one needs to write code regarding these names. &quot;Don't repeat yourself&quot; means that information is located in a single, unambiguous place. For example, using Active Record, the developer does not need to specify database column names in class definitions. Instead, Ruby can retrieve this information from the database.
The Model-View-Controller is a development paradigm which enforces clear separation between the data, logic and the user interface. Model- describes the data (database definitions) View – the user interface Controller – the application logic
RoR enforces Agile Development, some of the obvious principles followed are: Incremental Development (very quickly getting something that is running), Testing, Prototyping, Early Integration.
In Ruby every data type is an object, even classes and primitives like integers, Boolean etc. Every function is a method. There are four levels of variable scope: global, class, instance, and local. Matsumoto designed Ruby with minimum code overhead, such as headers or variable and class declarations. Methods can be added to a class and even to an instance of class at runtime, which means we can have instances of the same class which provide different functionality.
This is a common sentence in most of the articles about Ruby: “Ruby combines Smalltalk’s elegance, Python’s ease of use and Perl’s pragmatics [Yukihiro Matsumoto]”. Note: the Ruby’s IRB is the perfect toy for trying out code.
The best source to answer the question what is the future of RoR are the online blog debates. These blogs are especially useful because they present the “real” atmosphere among the programmers and show their opinion and attitude towards RoR. A very verbose critique on RoR is found on Cedric’s Weblog and will be discussed in detail later in this paper. The fact that this critique has been active for almost two years attests to the importance of such sources of information for the programming community. It is also interesting to note that Hansson himself posted entries on this blog. A very harsh critique on RoR is given by D. Sivers with a title “7 reasons I switched back to PHP after 2 years on Rails.” This critique was posted on September 22 nd 2006 and had massive response with over 500 entries just in the first couple days after the critique was posted. After reading the whole discussion one thing becomes clear: programmers either love or hate RoR. The programmer’s opinion of RoR depends a lot on the background they are coming from (i.e. programming languages experience) and the context in which they have met RoR. As mentioned above, some of the most valuable information about RoR is posted on online discussions. In these discussions, developers introduce their personal experience on topics and usually they relate their post with something previously posted. The richest discussion I found was initially posted almost 2 years ago by “Cedric”  and is still active today. It is very interesting to see how almost all the negative points addressed by Cedric a year and a half ago have been resolved. I find this very positive for RoR, because although it is a very young technology one gets the feeling that it grows and matures.
The most common negative critique addressed towards RoR is it’s scalability at enterprise level. This means that RoR is not ready yet for development of large web applications that provide service for very high numbers of users. This point I find very important, but considering that RoR is a very young technology I think that all what it need is time. Supporting this argument, the article “The adventures of scaling”  describes how to configure the server side for RoR to provide a service for an enterprise level of application. This shows that the problem of scalability is in the process of being addressed.
Since April 2006 there is Oracle support for RoR, which means that RoR gets support from the largest database company. Other Databases that Rails works with DB2, MySQL, Oracle, Postgres, Firebird, SQLServer, and SQLite. For all but MySQL, you’ll need to install a database driver. JRuby is a pure Java interpreter for Ruby, which supports interacting and defining Java classes in Ruby. IronRuby is a .NET implementation of the Ruby programming language. Thus, RoR applications can intercommunicate with most of the largest software technologies on an enterprise level. An interesting example is that the newest “Leopard OS X 10.5” version of Macintoshes’ operating system will ship with a standard RoR support.
Many argue that there are not enough web hosting companies to support RoR. Web hosting is an important issue because the web application has to reside somewhere. This is a kind of a typical chicken-egg problem. If RoR is not supported by the Internet Providers (ISP) then the developers are not motivated to develop in RoR because they will not be able to deploy their applications into production. However, the ISPs will provide support for RoR if there is enough demand. But the situation at the moment is not as bad as a year ago. Proof of this can be found at RailsWebHosts , an online list with all Web Hosting companies that support RoR. (Comment: I didn’t know what to put on this slide and therefore the links thing)
Many critics point out that RoR has no credible IDE (Integrated Development Environment). This is the easiest issue to address because since this problem was introduced there are many IDEs available and some of them are even provided by the leading IT companies. Some of the most interesting IDEs are “RadRails” from Aptana (eclipse plug-in), “NetBeans”, “Ruby in Steel” by Visual Studio, “Komodo” by ActiveState, “3rdRail” by CodeGear. What I would add to this list is the internet browser itself: the biggest help during the development, because the changes we make in code immediately take effect and are show in the browser by simply refreshing it’s content. The browser is a great help during debugging because that is where the compiler errors are presented.
Prof. Maner, just for fun try out the E-Texteditor you might like it a lot.
Yet another point of negative critique centers on the issue of deployment configuration. Normally, the application runs on the local development computer and is then deployed on the server where it should run and be accessible to the public. Many argue that it is too difficult to set up the production server used to deploy the application. This point is where I personally had problems and I agree with the other people addressing this issue. There is a need for a more straight forward method of configuring the production server. Note: I didn’t spent to much time in figuring out how to configure the deployment server. But couple times I have tried I failed. I realized that once I build more serious application I will become eager to learn how this Capistrano deployment exactly works.
There have also been arguments that developers are constrained by the Rails framework. Developing in RoR also means following the development paradigm provided by Rails. Most of the developers don’t want to give up their developmental freedom. There are several new frameworks worth introducing and these are: Merb, Sequel, DataMapper, Ambition. Merb is a very lightweight core framework. Most of the functionality of Merb is achieved through plugins. It leverages many of ActionPack's strengths. - Sequel provides simple ORM(Object Relational Maper) without as much of the complexity/magic of ActiveRecord. It provides a Ruby way to build SQL queries. - Ambition is beginning to pull us away from SQL altogether by permitting the querying of data using plain Ruby syntax. DataMapper is competition to RoRs active Record package.
Only so much theorizing can be done about negative and positive aspects of RoR. What counts the most is often the solid proof of what has been done so far. Even RoR’s most negative critics cannot ignore the growing number of successful web applications developed using RoR. “22 Successful Ruby on Rails Web Applications” [10,12] is an online list where many of these “success stories” can be found.
Active Record is the object-relational mapping(ORM) package. It takes care of the database conectivity, mapping tables and manipulating data. The table view is defined (wrapped) into a Class, but an object instance is tied to a single row in the table. When an new object is created, automatically new row is added to the table (upon save). When the object is updated, also the corresponding row in the table is updated. The Action Pack consist of the two modules ActionController and ActionView. These modules process the incoming requests and generating outgoing responses. Active Support is the library pack that is shared by all of the other Rails components. Action Mailer provides the e-mail functionality to a Rails application. Action Web Services(AWS) provides support for SOAP and XML-RPC. AWS handles the incoming the method invocations requests by converting them into method calls for our web service and also the sends back the responses.
Scaffolding is technique in which the programmer may write a specification that describes how the application database may be used. The compiler uses this specification to generate code that the application can use to create, read, update and delete (CRUD) database entries. Capistrano is utility for reliable repeatable deployment of the RoR application on a remote server. Capistrano uses SSH to communicate with the server. Script/console is ruby’s IRB(Interactive Ruby Shell) in the context of the Rails application. David describes Rake as having a reliable assistant on hand all the time. For example with demo> rake db:migrate Rake will apply any unapplied migrations to our database.
Getting started. Once RoR is successfully installed you can access the ruby server on your local host address. Start the stand alone web server (recently created Rails application under WEBrick(pure ruby server)) http://localhost:8000 (already accessible no extra configuration needed) This command start the WEBrick server demo> ruby script/server
4. This will generate controller hello with and action index. In Rails: Action=Method Note: for the simplest rails application you will need at least one view and one controler.
This is how the URLs are mapped in RoR. They usually follow the format: hostname/controller/view
Rails showed us the possibilities of Ruby and as more people continue to join the community, Ruby's potential will grow even more. One of the most important thing to keep in mind will be the agile practice and methodology of developing, which RoR enforces. I hope that by learning more about RoR I will gain knowledge not only about this specific framework, but also about how new technologies play a role in the computer science community. I have already learned that technologies like RoR don’t have to become mainstream in order to make an impact and inspire other technologies.
Presenter: Goran Savovski Professor: Walter Maner
 Kay Russell, “Ruby on Rails,” Computerworld, November 2005, Vol. 39 Issue 48, p26. www.computerworld.com .
 Wikipedia, “Ruby on Rails,” October 2007, [Online Document] available at http://en.wikipedia.org/wiki/Ruby_on_Rails .
 D. Thomas, D.H. Hansson, Agile Web Development with Rails, 2 nd ed., New York, USA: Pragmatic Programmers LLC, 2007.
 C. Beust, “Why Ruby on Rails won't become mainstream” [Online Document] April 2006, Available at http://beust.com/weblog/archives/000382.html .
 G. Stark, “Java + Rails = Real Digital Media” [Online Document] 2007, Available at http://www.railsforall.org/case_studies/11 .
 G. Grosenbach, “Future of Web Apps Conference” [Online Document] October 2007, Available at http://nubyonrails.com/ .
 D. Sivers, “7 reasons I switched back to PHP after 2 years on Rails” [Online Document] September 22, 2007, Available at http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html .