At the Forge - Assessing Ruby on Rails
So, it should come as no surprise that Ruby on Rails fills many of the gaps I have long perceived for Web developers. That said, my above descriptions also should make it clear where I think Rails should go if it is to continue to be successful.
One of the biggest draws for Rails is the speed and ease with which developers can create code that talks to a relational database. And although I am far from convinced by demos of what you can do in 15 minutes, my experience confirms that the demos are quite realistic. This is because Rails assumes you will create your database tables following its conventions, such as plural table names, ID fields named id and time/date fields ending with _at.
If you follow these conventions, you will discover you have to write a ridiculously small amount of code to handle many standard situations. Indeed, you probably will find yourself writing a handful of lines of code for many of the model objects you create, because the Active Record mapper within Rails will have done almost all of the work for you.
This means that much of the work needed for a Rails application is on the controllers (that is, objects whose methods are exposed via URLs) and views (that is, Ruby-HTML hybrid templates). Each controller method can produce its own output in plain text, HTML or via a template of the same name in the views directory. There is even a built-in Rails function for sending a file to the user, allowing you to set up downloads of binary files without having to worry about the syntax for specifying MIME types and filenames.
Zope advocates undoubtedly will say that these latter features are available in Zope, and have been around for several years. This is true—but figuring out how to use them, and where they go, can be maddeningly difficult for newcomers. By providing reasonable defaults for a great number of activities, and then allowing developers to change those defaults, Rails manages to make the simple cases trivially easy, and the difficult cases only moderately hard. Moreover, the scaffolding generators included with Rails provide just enough of a basic, initial set of controllers and templates to get people going without having to spend hours creating and modifying various code files.
Because of these intelligent defaults, there is a limited number of objects and methods that a new Rails developer must master before starting to create an application. This stands in stark contrast with all of the other frameworks I described, which require understanding a fairly large number of objects and methods, as well as how they fit together, in order to work productively. True, Rails is growing in size and sophistication, and it runs the risk of gaining some of the bloat we see with more-established frameworks. So far, Rails has managed to avoid many of those problems and complications, and the developers seem committed to keeping things as simple as possible.
As I wrote above, each Web development framework has made its own set of design trade-offs. What is missing from Rails that would make it even better? What should you keep in mind when considering whether to use Rails for an application you are developing?
First, working with Rails requires an acceptance of the Ruby language. I had been looking at Ruby for some time before working with Rails, and I am increasingly enjoying it. However, undoubtedly many programmers will resent elements of Ruby, from the syntax to the object model. Ruby is also less mature than Perl and PHP when it comes to third-party add-on libraries, which means that you might need to write some specialized routines yourself, rather than rely on the community for support. And finally, Ruby lacks true Unicode support, which means that many multilingual Web sites will be unable to use it for the time being.
But if you are willing to consider Ruby as a language for Web development, should you use Rails? I would argue that the smaller the development team and the more ambitious the project, the more likely you are to benefit from Rails. Very small projects don't need the overhead that Rails requires, and they are probably best served with CGI programs and PHP. But the moment you need a relational database with more than one table, you're likely to benefit from working with Rails.
However, both Ruby and Rails are designed for small teams of programmers, and even programmers who are working alone. If more than one person is going to work on a Rails project successfully, it will require great discipline on the part of the programmers to ensure that no one modifies files that are in someone else's purview. The fact that each Rails application resides in a single directory might increase the likelihood for such confusion.
Large projects, thus, might benefit from some of the larger frameworks, such as Zope—or even one of the many Java-based projects that has been released in recent years. My biggest hangup with Java is that it is relatively cumbersome and slow, especially when compared with languages such as Perl, Python and Ruby. But when you are working on a large project with many other programmers, it might be an advantage to have more compile-time checking, explicit declarations and safeguards that are missing from languages such as Ruby.
You also might want to consider the sophistication of your Web designers when thinking about Rails as a platform. Some relish the idea of working with code within templates, and others are scared of it and might even erase or change code. I still think that ZPT and OpenACS templates are a better system of templates, so I was encouraged by the recent announcement of Liquid, a templating system for Rails in the style of PHP's Smarty. I have been impressed by Smarty in the past, and I think this might help speed the introduction of Rails into large, established Web shops.
The fact that each Rails application uses a single directory of plain-text files has both advantages and disadvantages. One major advantage is that everything can be stored easily in CVS or a similar version-control system; installing the application in a new location can be as simple as checking out the code. However, this approach means that it's a bit harder to have multiple instances of the same application running on the same server, as with OpenACS packages and Zope products. We always can create multiple copies of the Rails application's directory tree, but it doesn't seem possible to have multiple instances of the same package.
As I mentioned above, I was originally quite attracted to OpenACS because of its single, standardized data model. I now understand that such a heavy, centralized data model is almost always going to be inadequate, but I still have to wonder why Rails doesn't come with any generic set of built-in permissions or registration. The answer, I suppose, is the growing number of Rails plugins, among which are several registration systems that can be integrated into existing Rails applications. I still would prefer to see more standardization on this front, but that is probably a lost cause at this point.
Finally, one problem Rails shares with every other environment is that of legacy code. Rails is so new, and so different, does it mean that its adoption will force us to abandon what we have already done? Possibly, but not necessarily. Rather than rewrite a mature Perl library in Ruby, I simply wrote a wrapper using XML-RPC. Ruby has an easy-to-use XML-RPC client, which I used within my Rails application to contact the Perl code. This has worked smoothly and easily, and it means I can benefit from Rails and CPAN at the same time. The fact that Rails lets developers override its database naming conventions also means it can be used with existing databases, rather than force users to create new database schemas that conform with Rails conventions.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide