Cross border: Streamlined, 1th part

I was in marathon training for the first time in my life. The most interesting aspect of marathon training--in fact, the only aspect--is to increase the impact of continuous stacking. Sometimes, I have to improve the efficiency of the design for the purpose of improving the physical conditions of the length of the run. Sometimes, during running, I learn to avoid small mistakes, avoid repetitive poses (which don't have much impact on a single stride, but waste energy or hurt me throughout the 26.2-mile run). I have improved every week, but the difference between the weeks is not significant. But after a training program cycle, I can only run 4 miles from the beginning to be able to run 26.2 miles. Software development is similar to this. If you continue to make small improvements and eliminate redundant duplication, you will continue to accumulate improvements that will be better for each future project.

In this two-part article, I focus on the Ruby on Rails build, which is a rails feature that can be cut in the early stages of development. Part 1th describes the limitations and streamlined,streamlined of Rails built as a code generator that efficiently applies metaprogramming techniques to eliminate higher levels of duplication. The 2nd part will further deepen the streamlined programming model and its customization features.

Low-level repetition and advanced repetition

Throughout the cross boundary series, I have described the language and framework for repeated improvements by reducing duplication and increasing efficiency:

Programming languages with features such as duck typing improve flexibility and reduce duplication by using fewer type definitions, reducing the number of code needed purely to support the compiler.

The framework attempts to improve efficiency and eliminate duplication by handling core tasks, such as persistence or transactions, so that you do not have to write code for each new application.

Ruby on Rails eliminates duplicate configurations by leveraging public specifications, allowing the framework to infer your intentions, rather than forcing you to configure application attributes (such as specific database table names and column names in your application).

As all efficient languages and frameworks must do, these measures focus on each step, or low-level repetition. But once you have built an effective foundation, you can put your goals higher. The Rails build feature attempts to eliminate duplication through common application types (WEB applications supported by the database).

Most database-supported WEB applications provide a user interface for performing CRUD operations (create, read, update, and delete) for every major table in the system. These user interfaces should be built automatically, and should not be duplicated. Rails begins to eliminate this duplication by building a feature that builds the default CRUD interface based on the contents of a database table collection. With Rails, you can build a complete application from scratch with just a few simple steps. If you follow the cross boundary series all the time, you've seen these steps before. This time, I will briefly introduce these steps:

Enter rails trails to generate a rails application to orchestrate the mountain bike track.

Create a database called Trails_development with the selected database engine, and modify the trails/config/database.yml to reflect the selected configuration.

Switch to Trails directory, build model and controller: Enter Ruby Script/generate model Trail (if running on UNIX, you can omit Ruby) to generate models called Trail, enter Script/generate con Troller trails generates a controller called Trailscontroller.

Edit the file db/migrate/001_create_trail.rb as Listing 1:

Listing 1. Initial migration

class CreateTrails < ActiveRecord::Migration
　 def self.up
　　 create_table :trails do |t|
　　　 t.column :name, :string
　　　 t.column :difficulty, :string
　　　 t.column :description, :text
　　 end
　 end
　 def self.down
　　 drop_table :trails
　 end
end

The file app/controllers/trails_controller.rb edited imaging Listing 2:

Listing 2. Construction in the Trailscontroller

class TrailsController < ApplicationController
　 scaffold :trail
end

Enter rake migrate to run the migration.

Start the server with the command script/server and point the browser to Localhost:3000/trails/list.

Now you have a simple Web application that works with database support, and you can do each of the CRUD based operations, as shown in Figure 1. You can see that the main screen lists each item and related pictures, and provides an Ajax window for creating, reading, updating, and deleting items.

Figure 1. A simple Rails application

So far, only a little effort has been made to reach a point where application development can be brought to a higher level. The Rails presenter always shows the build function, because it's so cool, and it's extremely useful for debugging and presentation to customers in a hurry. Builds can be built from the code generator--In this example, the Script/generate scaffold Trail trails--is entered or the scaffold metaprogramming token is specified in the controller. Each of these ways has its own purpose.