Crossing boundaries: What is the secret of Ruby on rails?

Ruby on Rails (also known as rails) is a ruby framework for Internet applications that support databases. I've now used Rails for two different applications and involved two other associated programs. For the upcoming new book Java to Ruby (see Resources), I've interviewed a lot of Rails developers (those who have succeeded and failed on that framework), the founder of the framework and the flagship of the Rails books, the Agile Web Development with Ra Main author of ILS (see Resources). I'm beginning to understand why the Ruby on Rails architecture is so successful.

Speculation and skepticism

The debate about Rails in the Java community has been quite intense and there is no sign of stopping for some time in the future. The Rails supporters praised its astonishing efficiency, which is about 10:1 more efficient than Java development. As a Java programmer, your subconscious response is not to believe in any hype, because you may have heard this before, but it really disappoints you. Java advocates increasingly insist that Ruby on Rails is a toy that cannot be scaled, generates bad code, and can only develop simple applications. But as praise for rails continues to emerge (often from trusted sources), a more cautious task is to understand what Rails can do and bring its ideas back to the Java platform. In this article, you'll explore the core features (that is, the secrets) that bring great efficiencies to Rails.

Rails Fundamentals

The Ruby on Rails framework is not the typical application development framework that everyone wants. Rails founder David Heinemeier Hansson often calls the framework opinionated software, and he likes to break the long-standing conventions. David made very philosophical decisions and followed them strictly throughout the framework. The core ideas that span the Rails are:

Seamless integration: Rails wisely leverages the best features of the Ruby language. It expands Ruby, but you can't say where Ruby ends and where Rails starts. You can also see a good integration between the Active record (the Rails persistence engine) and the model-view-Controller (MVC) framework. For example, you can write three lines of code, create a table, and immediately generate a user interface for the model.

Conventions are better than configurations: to maintain good flexibility, the Java framework maintains a large number of common configuration files. Rails does not use this strategy. It uses a common project directory structure and simple generic naming conventions for methods, classes, tables, and columns to infer which are configured in the Java application. As a result, the Rails application needs only a small portion of the configuration code for the Java application, typically one-tenth or more.

Low repetition: Don't repeat yourself (Don ' t Repeat yourself,dry) is a common term in the Rails community. The Rails Framework Committee abstracts repetitive tasks using a method that usually looks like a Ruby language extension. As you can see in the third article in this series, Rails's metaprogramming strategy makes every line of code perform more tasks.

Instant feedback: With Rails, you will be given immediate feedback on most of the work you do. After you write a line of code and save it, your changes will be activated when you load the next Web page. After you update your database, the migration can show you the changes in real time.

Focus on a field

The argument against its stated high productivity is often similar: if a good hammer is obtained, it is hard to find another hammer with a production rate of twice times, let alone 5 to 10 times times the increase in productivity, since the hammer has evolved for thousands of years. But people who compare Ruby on Rails to the various general-purpose Java frameworks are not. By fundamentally changing the nature of the tools, you can increase productivity by 10 times times in some ways. Now a professional manufacturer uses a nail gun to nail a lot of nails in the time it takes to nail a nail with a hammer. Like a nail gun, Rails has a special purpose. It is a framework specifically written for a single domain: A new WEB application that supports databases.

I suspect that half of the applications built today are database-enabled and web-based applications. So Rails is an area-specific product, but it's a big and important area. Specializing in this area makes Rails a huge advantage and a huge sensation. By focusing on projects in this area, Rails designers can choose shortcuts that other frameworks cannot or should not adopt. This specialization often loses flexibility for simplicity.

New applications that support the database suggest that the packaging method is superior to the mapping method. As you can see in the first article in this series, the Rails tools take the conventions in the data model. The Rails application requires a small subset of the model code created in the Java application. This principle works well if you create patterns for Rails applications in particular. If you try to cram legacy patterns into Rails, it will become less smooth.

web-based applications allow a set of similar optimizations. When you know that an application is web-based, you know the general structure of your application and the major components you might need. Because rails is focused on web-based applications, the following features are enhanced in rails:

Model-View-controller: Rails ' MVC framework (called Action Pack) is customized for web-based access and implements the well-known design strategy known as Model 2 (see Resources). The Rails version has optimized the integration between the Controller and the view (which minimizes the configuration file) and automatically makes the controller instance variables available to the view.

Project directory structure: All Rails applications have the same project structure, where directories are used to store application code, database configuration, public static files, and scripts for managing Web servers and for web-based functional testing.

Schemas: The Rails Framework simplifies architecture by providing out-of-the-box scripting for building application components that conform to common architectural goals, such as page-level and fragment-level caching, two-tier design, and environments for testing, development, and production.

Tools: Rails tools are dedicated to the Web. Log support, Breakpointer, Profiler (Profiler), and test frameworks are both trimmed for web-based applications and enabled for two-tier operations.

But a nail gun will never replace a hammer, but we foolishly hope to replace it completely. A hammer can always do something that a nail gun can't do. Rails will never be used as a tool for enterprise integration, Object Relational mapping, or full stack Web services. The best thing you can expect from Rails is that it's a special tool that can well meet the areas it's targeting.