.

Điều thú vị là Rails có thể dễ dàng triển khai tất cả những điều này trong ứng dụng web của bạn như thế nào. Ví dụ đơn giản sau đây thêm các phần tử mới vào danh sách:

<%= javascript_include_tag "prototype" %>

Thêm vào danh sách bằng AJAX

<%= form_remote_tag(:update =>"my_list", :url => ( :action => :add_item), :position => "top") %> Văn bản thành phần mới:<%= text_field_tag:newitem %> <%= submit_tag "Добавить элемент через AJAX" %> <%= end_form_tag %>

• Yếu tố bắt đầu... thêm nhiều hơn nữa!

Bài viết AJAX trên Rails và API trợ giúp JavaScript nói về hỗ trợ AJAX trong Rails một cách chi tiết hơn.

Thư viện Prototype cũng cung cấp cho nhà phát triển Rails một loạt hiệu ứng hình ảnh phía trình duyệt. Script.aculo.us chứa tài liệu và bản trình diễn trực tiếp về hiệu ứng Nguyên mẫu. Nguyên mẫu cũng giúp dễ dàng thêm chức năng kéo và thả vào ứng dụng của bạn, bạn cũng có thể tìm thấy tính năng này tại script.aculo.us.

Bố cục

Bố cục cho phép bạn chỉ định một tập hợp các thành phần cơ bản để hiển thị trên mỗi trang được bộ điều khiển hiển thị. Điều này thường hữu ích để hiển thị đầu trang, chân trang và thanh bên tổng thể. Theo mặc định, Rails tìm trong thư mục bố cục của nó để tìm tệp rhtml có tên khớp với tên của bộ điều khiển. Mẫu bố cục có thể trông như thế này:

Rails sẽ chèn HTML được tạo bởi hành động vào bố cục này, trong đó có ghi @content_for_layout.

Bộ điều khiển cũng có thể trực tiếp chỉ định bố cục nào sẽ được sử dụng cho tất cả các hành động của nó. Điều này giúp đơn giản hóa nhiệm vụ sử dụng một bố cục cho nhiều bộ điều khiển. Bạn có thể thay đổi mẫu bố cục một cách linh hoạt trong thời gian chạy. Ví dụ: sử dụng các bố cục khác nhau cho người dùng đã đăng nhập và khách truy cập ẩn danh.

Để tìm hiểu thêm về bố cục, hãy xem tài liệu ActionController::Layout.

Các bộ phận và thành phần

Các thành phần và một phần cho phép bạn chia các mẫu bản trình bày của mình thành các mô-đun.

Cách dễ nhất là sử dụng các phần, cho phép bạn tách phần chung của mẫu thành một tệp riêng biệt và sau đó hiển thị nó từ nhiều mẫu khác (hoặc nhiều lần trong cùng một mẫu).
Các mẫu một phần luôn có dấu gạch dưới (_) ở phía trước tên tệp của chúng để giúp phân biệt chúng với các mẫu đầy đủ dễ dàng hơn.

Một cách sử dụng điển hình của các phần là hiển thị một mảng (hoặc bộ sưu tập khác) các phần tử.

<% for ad in @advertisements %> <%= render:partial =>"adview", :locals => ( :item => quảng cáo ) %><% end %>

Điều này sẽ hiển thị một phần mẫu _adview.rhtml nhiều lần (một lần cho mỗi phần tử của mảng @advertisms). Đối với mỗi chế độ xem, Rails sẽ chuyển một biến cục bộ tới _adview.rhtml được gọi là mục chứa đối tượng quảng cáo.

Tài liệu ActionView::Partials chứa thông tin chi tiết. Pointstorm có cách trình bày chi tiết hơn về các phần, nhưng nó hơi lỗi thời vì nó sử dụng cú pháp lỗi thời để gọi các phần.

Các thành phần tương tự như các phần ở chỗ chúng cũng hiển thị một mẫu khác trong mẫu hiện tại. Sự khác biệt là các thành phần sử dụng tên và hành động của bộ điều khiển để chèn kết quả thực thi của nó vào mẫu hiện tại.

<%= render_component:controller =>"lịch", :action => "hôm nay" %>

Hãy xem phần Thành phần của hướng dẫn sử dụng Rails nếu bạn muốn tìm hiểu thêm.
Đoạn đầu đài

Giàn giáo cho phép bạn triển khai nhanh chóng các thao tác CRUD (Tạo, Truy xuất, Cập nhật và Xóa) cho bất kỳ bảng cơ sở dữ liệu nào. Chúng không đẹp lắm nhưng chúng cho phép bạn truy cập ngay vào bảng tính của mình qua giao diện web. Theo thời gian, bạn có thể dần dần thay thế các thao tác và mẫu đã tạo bằng thao tác và mẫu của riêng bạn.

Rails hỗ trợ giàn giáo tĩnh và động. Tĩnh tạo ra các tệp mô hình, bộ điều khiển và mẫu. Điều này cho phép bạn xem mọi thứ hoạt động như thế nào và bắt đầu cải thiện cũng như thay đổi mã hiện có. Để tạo giàn giáo tĩnh, hãy đi qua hệ thống tệp tới thư mục chính của ứng dụng Rails của bạn và chạy lệnh như sau:

$ ruby ​​​​script/tạo hóa đơn giàn giáo

Lệnh này sẽ tìm bảng hóa đơn trong cơ sở dữ liệu của bạn và sử dụng lược đồ của nó để tạo mô hình, bộ điều khiển và tất cả các mẫu dạng xem, khung kiểm tra đơn vị và các nội dung khác. Khi quá trình diễn ra, danh sách các tệp được tạo sẽ được hiển thị trên màn hình.

Ưu điểm của giàn giáo tĩnh là bạn có thể xem và thay đổi mã được tạo. Điểm bất lợi là một khi bảng cơ sở dữ liệu được thay đổi, giàn giáo sẽ không còn phản ánh cấu trúc mới của nó nữa. Tuy nhiên, nếu bạn không thay đổi những cái được tạo bởi giàn giáo, bạn có thể chỉ cần tạo lại chúng.

Giàn giáo động không tạo ra bất kỳ tập tin nào. Rails chỉ đơn giản là tạo ra những gì nó cần một cách nhanh chóng trong khi ứng dụng đang chạy. Điều này có nghĩa là mỗi khi bạn thay đổi lược đồ bảng, giàn giáo sẽ tự động phản ánh những thay đổi này. Để kích hoạt giàn giáo động, hãy đặt một dòng mã trong bộ điều khiển:

lớp AccountController< ActionController::Base scaffold:account end

Và nhiều hơn nữa

Cũng giống như Active Record, có rất nhiều thứ trong Action Pack mà tôi không thể nói ở đây. Nếu bạn muốn tìm hiểu thêm, hãy xem API gói hành động.

Action Mailer là một công nghệ đơn giản để gửi và nhận email trong ứng dụng web của bạn. Đây là một phương pháp để gửi email có tệp đính kèm:

# gửi email có tệp đính kèm def signup_notification(recipient) người nhận người nhận.email_address_with_name chủ đề "Thông tin tài khoản mới" từ " [email được bảo vệ]"tệp đính kèm:content_type => "image/jpeg", :body => File.read("an-image.jpg") tệp đính kèm "application/pdf" do |a| a.body = generate_your_pdf_here() end end

Bạn có thể tìm hiểu thêm trong API Action Mailer và Chương 19 về Phát triển web linh hoạt với Rails.

Dịch vụ web hành động

Dịch vụ web hành động cung cấp hỗ trợ phía máy chủ cho các giao thức dịch vụ web SOAP và XML-RPC, đồng thời cho phép bạn dễ dàng tạo các API của riêng mình và xuất bản chúng qua WSDL.

Đây là một phần của API MetaWeblog được triển khai bởi Typo (một hệ thống viết blog nguồn mở được viết bằng Rails):

lớp MetaWeblogApi< ActionWebService::API::Base api_method:getRecentPosts, :expects =>[ (:blogid => :string), (:username => :string), (:password => :string), (:numberOfPosts => :int) ], :returns => [] api_method:deletePost, :expects => [ (:appkey => :string), (:postid => :string), (:username => :string), (:password => :string), (:publish => :int) ], : trả về => [:bool] lớp cuối MetaWeblogService< TypoWebService web_service_api MetaWeblogApi def getRecentPosts(blogid, username, password, numberOfPosts) articles = Article.find_all(nil, "created_at DESC", numberOfPosts) articles.to_a.collect{ |c| article_dto_from(c) } end def deletePost(appkey, postid, username, password, publish) article = Article.find(postid) article.destroy true end end

Đoạn trích này chỉ hiển thị hai trong số bảy phương thức API được Typo xác định trong lớp này.

Nếu bạn muốn tìm hiểu thêm, hãy đọc hướng dẫn Dịch vụ web hành động

Suy nghĩ về sự chia ly

Thông thường, bạn có thể chia các framework để tạo ứng dụng web và các nhà phát triển sử dụng chúng thành hai loại riêng biệt. Ở một đầu của quang phổ, có những framework hạng nặng dành cho những lập trình viên “nghiêm túc”, ở đầu kia có những framework nhẹ, dễ sử dụng dành cho những người thích “vui đùa”. Mỗi nhóm này thường đối xử với nhau mà không có bất kỳ sự tôn trọng nào.

Một trong những điều thú vị nhất là Rails thu hút các nhà phát triển từ cả hai phe. Các nhà phát triển cao cấp cảm thấy mệt mỏi với công việc lặp đi lặp lại, năng suất thấp mà họ phải chịu đựng, trong khi các nhà phát triển cấp thấp hơn cảm thấy mệt mỏi khi phải vật lộn với một mớ mã không được bảo trì khi ứng dụng của họ vượt quá mức đơn giản. Cả hai nhóm này đều tin rằng Rails giải quyết được một số vấn đề đáng kể của họ. Tôi không biết bạn thế nào, nhưng đối với tôi đây có vẻ là một sự thật tuyệt vời.

Tôi đã dành ~14 giờ làm việc cuối cùng chỉ dành cho Ruby on Rails, lập trình một dự án đơn giản “Y”, có thể nói, một framework nhỏ như vậy. Mọi thứ diễn ra theo...

hồng ngọc  - một ngôn ngữ lập trình cấp cao năng động, phản xạ, thông dịch để lập trình hướng đối tượng nhanh chóng và thuận tiện.

Viên ngọc trên tay vịn  - một khung hoàn chỉnh, đa cấp để xây dựng các ứng dụng web sử dụng cơ sở dữ liệu, dựa trên kiến ​​trúc Model-View-Controller (MVC).

Nhà phát triển

Hãy bắt đầu với thực tế là ngôn ngữ lập trình Ruby không dành cho người mới bắt đầu. Rào cản gia nhập rất cao, vì vậy các lập trình viên Ruby thường đến sau vài năm làm việc với bất kỳ ngôn ngữ lập trình nào khác. Độ tuổi trung bình của một lập trình viên Ruby là 25–28 tuổi. Một lập trình viên Ruby on Rails mới bắt đầu bình thường là một nhà phát triển web giàu kinh nghiệm với nhiều kiến ​​thức, kinh nghiệm phát triển dự án bằng bất kỳ ngôn ngữ nào khác, hiểu biết về nguyên tắc lập trình và hiểu biết tuyệt vời về phát triển web nói chung.

Lợi ích chính của Ruby/Ruby on Rails

Tốc độ phát triển

Ưu điểm chính của ngôn ngữ lập trình Ruby và khung Ruby on Rails là tốc độ phát triển. Thực tiễn cho thấy tốc độ phát triển dự án sử dụng RoR tăng 30–40% so với bất kỳ ngôn ngữ hoặc framework lập trình nào khác. Trước hết, sự gia tăng tốc độ phát triển được xác định bởi một bộ công cụ RoR tiêu chuẩn sẵn sàng sử dụng rộng rãi, một bộ khổng lồ các giải pháp làm sẵn trong cộng đồng, ngôn ngữ Ruby và sự dễ dàng lập trình trong đó.

Một trong những phần quan trọng nhất của văn hóa RoR là tính xã hội. Giải quyết được vấn đề, giúp đỡ người khác giải quyết nó. Đã triển khai mô-đun của bạn, hãy chia sẻ nó với cộng đồng. Do đó, hiện tại, hàng nghìn giải pháp làm sẵn cho một số vấn đề nhất định được lưu trữ trong phạm vi công cộng. Xác thực, ủy quyền, hệ thống nhận xét, hệ thống thanh toán, danh sách gửi thư và nhiều hơn nữa (tất cả những gì thường được phát triển từ đầu) đều do người khác triển khai, được thử nghiệm và đề xuất bởi một cộng đồng lớn.

Văn hóa và tiêu chuẩn

Ruby on Rails là một framework. Thường thì khuôn khổ không cho phép bạn tự mình làm mọi việc. Tất nhiên, trong Ruby on Rails, bạn có thể “phát minh lại bánh xe của riêng mình” và lập trình theo bất kỳ hướng nào mà không cần dựa vào các tiêu chuẩn; nhưng thường thì điều này không bắt buộc. Các tiêu chuẩn để đặt tệp trong một dự án, các tiêu chuẩn để viết mã trong một dự án và các quy tắc chung để lập trình trong Ruby on Rails cấu trúc chặt chẽ bất kỳ dự án nào. Do đó, dự án trở nên dễ đọc. Người mới tham gia dự án rất nhanh. Kinh nghiệm cho thấy rằng bất kỳ ai mới tham gia dự án đều thực hiện những chỉnh sửa hữu ích đầu tiên ngay trong ngày đầu tiên làm việc. Do đó, sẽ không được coi là vấn đề lớn nếu việc phát triển dự án ban đầu được thực hiện bởi một nhóm lập trình viên và việc hỗ trợ hoặc sửa đổi dự án được thực hiện bởi một nhóm hoàn toàn khác. Dự án RoR là điều hiển nhiên dễ hiểu đối với bất kỳ nhà phát triển nào.

Một số công cụ phát triển hay

Kiểm tra

Khi phát triển bất kỳ dự án lớn nào, một câu hỏi hợp lý sẽ được đặt ra. Làm thế nào và ai sẽ thử nghiệm dự án? Không phải lúc nào cũng có đủ phương tiện hoặc mong muốn tạo ra toàn bộ bộ phận kiểm thử và bạn cũng muốn tự động hóa quy trình này. Không giống như các framework khác, RoR có các công cụ kiểm tra tự động tuyệt vời. Các ngôn ngữ và framework lập trình khác không có công cụ kiểm tra tiêu chuẩn. Tất nhiên, có những sự phát triển của bên thứ ba cho phép bạn tổ chức thử nghiệm tự động một dự án PHP, nhưng chúng không được cài đặt sẵn và các lập trình viên thường không nghĩ đến việc sử dụng chúng. Lý tưởng nhất là trong dự án Ruby on Rails, mã dự án không được viết cho đến khi các bài kiểm tra được viết cho mã này. Hệ tư tưởng RoR liên quan đến việc sử dụng ban đầu các phương pháp BDD (Phát triển theo hướng hành vi) hoặc TDD (Phát triển theo hướng thử nghiệm).

Bộ nhớ đệm

Dự án bộ nhớ đệm là một trong những giai đoạn quan trọng nhất trong quá trình phát triển một dự án Internet lớn. PHP có nhiều tùy chọn khác nhau để lưu trữ dữ liệu. Các tùy chọn và công cụ này được vặn, gắn, gắn, gắn vào bên cạnh. Vẫn chưa có sự đồng thuận trong cộng đồng PHP: nên sử dụng cái gì tốt nhất, cách tốt nhất để lưu trữ dữ liệu vào bộ đệm, sử dụng công cụ nào.

Ruby on Rails ở cấu hình cơ bản có các công cụ lưu trữ dữ liệu tiêu chuẩn. Khi bắt đầu, các công cụ được cung cấp cho phép bạn triển khai bộ nhớ đệm dữ liệu trên dự án. Bạn có thể lưu trữ toàn bộ trang hoặc khối mã. Bạn có thể lưu vào bộ đệm kết quả truy vấn và mô hình ActiveRecord. Bạn có thể lưu vào bộ đệm bằng memcached hoặc redis hoặc các phương tiện khác. Để triển khai bộ nhớ đệm trong dự án Ruby on Rails, trong 95% trường hợp, bạn sẽ không cần bất cứ thứ gì ngoài các giải pháp tiêu chuẩn và làm sẵn.

Bản địa hóa

Thường có tình huống ai đó đã thực hiện một dự án và sau đó đột nhiên nhận ra rằng cần có phiên bản tiếng Anh để tiếp tục phát triển dự án. Đồng thời, các nhà phát triển PHP bắt đầu bắt đầu nói về việc điều này không thể lường trước được như thế nào, rằng nó kéo dài và cực kỳ tốn nhiều công sức. Họ nói, hãy mở một dự án song song, đây sẽ là bản sao hoàn chỉnh của dự án này và dịch nó.

Ruby on Rails đạt tiêu chuẩn với các công cụ bản địa hóa dự án. Bạn có thể thấy trước nhu cầu hỗ trợ các ngôn ngữ khác nhau trên trang web, cả ban đầu và trong tương lai. RoR có thể phân phối các mẫu khác nhau cho các ngôn ngữ khác nhau, chứa các tệp cấu hình với bản dịch thuật ngữ và nhiều công cụ tiêu chuẩn khác để triển khai bản địa hóa dự án.

Định tuyến (URL đẹp hoặc CNC)

Thông thường trong nhiều dự án PHP, chúng ta có thể thấy hình ảnh trong đó địa chỉ của một trang nhất định rất lớn và khó hiểu. Ruby on Rails có khả năng tiêu chuẩn để định cấu hình linh hoạt định tuyến, loại địa chỉ và tên của các phần chính. Có thể nhanh chóng thay đổi địa chỉ ở một nơi mà không cần phải thay đổi địa chỉ đó trong toàn bộ dự án. Hệ tư tưởng REST được sử dụng tích cực trong cộng đồng nhà phát triển RoR. Địa chỉ trang trong dự án Ruby on Rails luôn rõ ràng, đẹp mắt, được công cụ tìm kiếm hiểu rõ và đơn giản.

Xác thực

Ruby on Rails có các công cụ tuyệt vời cho phép bạn xác thực dữ liệu đến. Người dùng của bạn điền vào biểu mẫu và bạn cần kiểm tra xem địa chỉ email đã được nhập chính xác chưa, mật khẩu có sẵn hay thời lượng đăng nhập tối thiểu bắt buộc là bắt buộc. Các công cụ của Standard Rails sẽ giúp bạn điều này.

Di chuyển và làm việc với cơ sở dữ liệu

Một vấn đề phổ biến trong nhiều dự án PHP là không có khả năng kiểm soát cấu trúc cơ sở dữ liệu bằng các phương tiện và công cụ dễ hiểu. Những thay đổi về cấu trúc thường được thực hiện thủ công và trực tiếp vào cơ sở dữ liệu. Bởi vì điều này, nhiều trường và bảng khó hiểu xuất hiện trong dự án mà không ai nhớ bất cứ điều gì. Ruby on Rails có các công cụ tiêu chuẩn để làm việc với cơ sở dữ liệu - "di chuyển". Cấu trúc cơ sở dữ liệu được lưu trữ trong mã ứng dụng và được cấu hình từ dự án. Cấu trúc của bạn sẽ luôn ở trong kho lưu trữ, mọi thay đổi trong cấu trúc sẽ được ghi lại và gắn với một cam kết cụ thể đối với kho lưu trữ.

Sự an toàn

Ruby on Rails theo mặc định được thiết kế phù hợp với tính bảo mật của dự án. Khi sử dụng các công cụ RoR, việc tiêm SQL và tấn công XSS sẽ bị loại trừ. Tất cả các tham số đầu vào đều được thoát theo mặc định. Các biến đầu ra trong mẫu cũng được thoát trừ khi bạn chỉ định tùy chọn ngược lại. Nhà phát triển không có cơ hội mắc lỗi bảo mật (tất nhiên không phải không có ngoại lệ).

Triển khai

Có rất nhiều công cụ hữu ích và hay trong môi trường Ruby on Rails. Bao gồm các công cụ được sử dụng trong quá trình triển khai. Ví dụ: khi sử dụng Capistrano, việc triển khai phiên bản mới của ứng dụng tới máy chủ sản xuất (hoặc một số máy chủ) sẽ yêu cầu một lệnh trong bảng điều khiển: cap triển khai.

Nguyên tắc bổ sung của Ruby/Ruby On Rails

Hệ thống kiểm soát phiên bản

Khi phát triển bất kỳ dự án Ruby on Rails nào, việc sử dụng các hệ thống kiểm soát phiên bản nổi tiếng đều được ngụ ý. Như họ nói, việc sử dụng git là “bắt buộc tự nguyện”, vì nhiều hệ thống triển khai dự án tự động trên các máy chủ “sản xuất” không hoạt động nếu không có chúng. Các lập trình viên RoR ban đầu, khi tìm hiểu nền tảng, buộc phải thành thạo git, vì nhiều ví dụ mã trong tài liệu ngụ ý việc sử dụng các hệ thống kiểm soát phiên bản này. Phần lớn là vì điều này, những người mới bắt đầu thiếu kinh nghiệm sẽ dễ dàng bắt đầu học PHP hơn và không chạm vào Rails cho đến khi họ đạt đến một mức độ hiểu biết nhất định về phát triển web cũng như các nguyên tắc của nó.

Hệ thống quản lý dự án/người quản lý tác vụ

Ruby on Rails ban đầu được phát triển để triển khai hệ thống quản lý dự án - Basecamp. Redmine (một hệ thống quản lý dự án phổ biến và miễn phí) cũng được tạo trên RoR. Vì vậy, khi làm việc trong các dự án Rails, việc sử dụng các hệ thống như vậy là “tự nguyện ép buộc”. Tất cả các hệ thống đều được tích hợp với hệ thống kiểm soát phiên bản, cho phép điều chỉnh linh hoạt hơn các quy trình phát triển dự án.

Huyền thoại và định kiến

Không có nhà phát triển Ruby on Rails

Hãy bắt đầu với thực tế là có những nhà phát triển, nhưng họ ít hơn các nhà phát triển PHP. Điều này là do các ngưỡng đầu vào khác nhau để làm chủ công nghệ (thường mọi người bắt đầu học Ruby sau vài năm PHP), điều này nói lên chất lượng của các nhà phát triển. Có rất ít nhà phát triển giỏi trong tất cả các công nghệ.

Các nhà phát triển Ruby on Rails rất tốn kém

Các nhà phát triển cấp cao thực sự rất tốn kém. Hơn nữa, chúng đều đắt như nhau đối với bất kỳ ngôn ngữ và nền tảng lập trình nào. Có rất ít nhà phát triển giá rẻ trong RoR do thiếu các nhà phát triển kém trong cộng đồng (tất nhiên là có ngoại lệ).

"Đường ray" không mở rộng quy mô

Đây là quan niệm sai lầm quan trọng nhất của những người chưa cố gắng viết các dự án nghiêm túc bằng RoR. Ruby on Rails có quy mô rất tốt. Hãy xem GitHub, Groupon, Basecamp, v.v. Tất cả các dự án này đều được viết bằng Rails và tất cả các dự án này đều có bất kỳ vấn đề nào khác, nhưng không có vấn đề về quy mô (thường là vấn đề với hiệu suất cơ sở dữ liệu).

Ruby chậm hơn PHP

Hiện tại, hiệu suất của Ruby ngang bằng với PHP. Nhưng nó có thực sự quan trọng đến vậy không? Xét cho cùng, thời gian tạo trang chủ yếu là thời gian dành cho các truy vấn tới cơ sở dữ liệu. Bản thân tốc độ của ngôn ngữ thường không đóng một vai trò lớn.

Đồng thời, bạn có cơ hội tận dụng lợi thế chính của RoR - tốc độ phát triển dự án và chi phí hỗ trợ thấp. Hiện tại, chi phí của các nhà phát triển cao hơn rất nhiều so với chi phí mua thêm một thẻ nhớ cho máy chủ. Trong mọi trường hợp, vấn đề về hiệu suất của bất kỳ dự án nào không phải là vấn đề chọn sai nền tảng hoặc ngôn ngữ lập trình. Rất có thể, đây là những vấn đề về kiến ​​trúc dự án, bộ nhớ đệm dữ liệu hoặc tối ưu hóa cơ sở dữ liệu có sai sót ban đầu.

Một vài trích dẫn từ những người nổi tiếng trong cộng đồng Ruby

« Viên ngọc trên tay vịn   - đây là bước đột phá trong việc hạ thấp rào cản gia nhập ngành lập trình. Các ứng dụng web mạnh mẽ trước đây phải mất hàng tuần hoặc hàng tháng để phát triển giờ đây có thể được xây dựng chỉ trong vài ngày."

« Viên ngọc trên tay vịn VàPHP   - nó giống như Apple Macintosh và PC. Chúng tôi tuy ít nhưng chúng tôi là những người ưu tú. Ruby on Rails và PHP là văn hóa đối lập với sự hỗn loạn. PHP cho phép bạn chế tạo chiếc xe đạp của riêng mình từ các bộ phận của những chiếc xe đạp khác mà không cần dựa vào bất kỳ “kinh thánh về xe đạp” nào. Các nhà phát triển RoR tiến bộ hơn bất kỳ học sinh nào chỉ cần đọc một cuốn sách và nói rằng mình biết PHP. Lợi thế của chúng tôi là bất chấp sự hỗn loạn của PHP, chúng tôi có tổ chức hơn”.

“Theo kinh nghiệm của tôi, các chương trình viết bằng Ruby có ít dòng hơn các chương trình tương tự được viết bằng Java và C#. Và càng ít mã thì càng dễ bảo trì, điều này rất quan trọng vì chi phí bảo trì dài hạn được coi là thành phần chi phí lớn nhất của các dự án phần mềm thành công. Việc gỡ lỗi các chương trình nhỏ mất ít thời gian hơn, thậm chí không cần các công cụ gỡ lỗi ưa thích.”

“Tại sao các nhà phát triển ứng dụng doanh nghiệp có kinh nghiệm như tôi lại yêu thích Ruby và Rails? Để đáp ứng những yêu cầu này, độ phức tạp của các giải pháp được tạo bằng công nghệ Java và Microsoft đơn giản là không thể chấp nhận được. Sự phức tạp quá mức ngăn cản một cá nhân hiểu được toàn bộ dự án và làm phức tạp đáng kể việc giao tiếp trong nhóm. Việc nhấn mạnh vào việc tuân theo các mẫu thiết kế và tập trung vào hiệu suất trên các nền tảng này sẽ làm mất đi niềm vui khi làm việc trên một ứng dụng.”

« Viên ngọc trên tay vịn , mà không dùng đến bạo lực, buộc các lập trình viên phải viết mã có cấu trúc chặt chẽ hơn. Mã trên “đường ray” có thể được đọc và hiểu ngay cả khi không có tài liệu. Điều này giúp các nhóm phát triển khác nhau hỗ trợ dự án dễ dàng hơn. Dự án không bị ràng buộc với một nhà phát triển hoặc nhóm cụ thể. Các nhà phát triển dự án sau đây không có mong muốn quen thuộc như “Không có gì rõ ràng cả! Hãy viết lại mọi thứ và làm lại theo cách của chúng ta.”

« hồng ngọc   - ngôn ngữ hay. Viết mã bằng Ruby rất thú vị. Mọi người tôi biết đã chuyển sang Ruby và Rails đều nói rằng họ hạnh phúc hơn. Chủ yếu vì lý do này, Ruby và Rails đang thay đổi hiện trạng, đặc biệt là trong lĩnh vực phát triển ứng dụng doanh nghiệp. Trước khi trở thành người chuyển đổi Rails, tôi đã quen làm việc trong một dự án với những yêu cầu mơ hồ, không liên quan đến nhu cầu thực tế. Tôi mệt mỏi với việc lựa chọn giữa các nền tảng cạnh tranh và tích hợp chúng với nhau, mệt mỏi với việc viết những dòng mã xấu xí. Và Ruby là một ngôn ngữ cấp cao, năng động. Mã Ruby dễ đọc và viết hơn vì nó ánh xạ tự nhiên hơn đến một miền cụ thể và có phong cách gần gũi hơn với ngôn ngữ tự nhiên của con người. Sự dễ nhận biết có rất nhiều lợi ích không chỉ trong ngắn hạn mà còn về lâu dài, vì chương trình được chuyển sang sử dụng trong công nghiệp và các lập trình viên bảo trì phải dễ hiểu.”

« Không có chỗ cho sự ép buộc trong cộng đồng Rails. David Heinemeier Hansson đã chọn một ngôn ngữ mang lại niềm vui cho ông. Nền tảng Rails được sinh ra từ đoạn mã mà anh ấy cho là đẹp. Điều này đặt ra nền tảng cho giao tiếp trong cộng đồng Rails. Mọi thứ trong thế giới Rails đều mang tính chủ quan. Một người có thể chấp nhận điều gì đó hoặc không. Nhưng giữa người chấp nhận và người không chấp nhận, không có ác ý mà chỉ có sự cố gắng thuyết phục nhẹ nhàng mà thôi.”

“Khi bắt đầu sự nghiệp phát triển web, tôi đã dành rất nhiều thời gian để lập trình bằng PHP. Giống như bất kỳ lập trình viên nào, tôi đã bắt đầu viết CMS của riêng mình. Tôi liên tục không hài lòng với các công cụ mà PHP cung cấp cho tôi và tôi đã nghĩ ra một framework nhỏ của riêng mình. Trong khuôn khổ của riêng mình, tôi đã triển khai mọi thứ sao cho thuận tiện cho mình. Hãy tưởng tượng sự ngạc nhiên của tôi khi nhìn thấy Rails. Tôi nhận ra rằng Ruby on Rails rất giống với framework của tôi, do đó, họ đã triển khai và hoàn thiện mọi thứ mà tôi còn thiếu trong PHP. Hãy thêm vào đây một cộng đồng khổng lồ liên tục cập nhật đường ray - chúng tôi có một công cụ trong đó đơn giản là thuận tiện và tốt để thực hiện bất kỳ dự án web nào. Tôi từ bỏ khuôn khổ của mình và vui vẻ chuyển sang RoR. Tôi nghĩ Ruby on Rails khiến các lập trình viên hạnh phúc hơn.”

Cảnh sát Gary Gary
Xuất bản 27/05/2008

Tháng trước, tôi đã trình bày chi tiết về ngôn ngữ lập trình Ruby, một ngôn ngữ động đã trở thành công cụ được nhiều nhà phát triển phần mềm lựa chọn. Tháng này tôi sẽ nói về cơ sở hạ tầng để tạo các ứng dụng Web dựa trên Ruby - Rails. Rails thể hiện giá trị của các framework, tính hiệu quả phổ biến của các ngôn ngữ động như Ruby và lợi ích dành cho các nhà phát triển đi kèm với các quy ước cấu hình sẽ được thảo luận tiếp theo.

Tìm kiếm lợi nhuận lớn hơn trên mỗi đơn vị lao động đầu vào

Kể từ khi các lập trình viên bắt đầu tạo ra phần mềm, họ đã không ngừng suy nghĩ về cách mang lại nhiều giá trị khách hàng hơn cho phần mềm với cùng một lượng công sức. Trong 50 năm qua, nhiều lý thuyết đã xuất hiện về cách đạt được điều này. Chúng tôi chắc chắn đã chứng kiến ​​​​sự phát triển của các ngôn ngữ lập trình cấp cao. Nhưng sự cải tiến dần dần của các ngôn ngữ cấp cao khó có thể khiến chúng ta nhảy dựng lên ghế, tự vỗ vào trán và kêu lên “wow!” Ngay cả những ngôn ngữ lập trình động được phân loại là "Ngôn ngữ cấp độ rất cao" (VHLL) vào những năm 1990 cũng không thể mang lại những lợi ích mà hầu hết chúng ta mong muốn và cần để đáp ứng các yêu cầu phần mềm ngày càng tăng.

Chúng tôi đã cung cấp các ý tưởng về cách cải thiện năng suất của lập trình viên bằng cách sử dụng các khung có thể tái sử dụng, các công nghệ xuyên suốt như lập trình hướng theo khía cạnh, phát triển dựa trên thành phần, kiến ​​trúc hướng dịch vụ, kiến ​​trúc hướng mô hình, v.v. Tất cả điều này đã làm tăng năng suất nhất định, miễn là nó được sử dụng đúng cách. Mặc dù chúng tôi chưa tạo ra công nghệ cho phép chúng tôi tạo chương trình mà không cần sự tham gia của lập trình viên (đó là điều mà một số chuyên gia mơ ước), nhưng chúng tôi đã đạt được một bước tiến lớn trong việc tăng năng suất của các lập trình viên. Tuy nhiên, chúng tôi vẫn chưa đạt được mức tăng hiệu suất gấp 10-100 lần như mong đợi.

Trước khi tiếp tục câu chuyện, tôi muốn cảnh báo bạn rằng cơ sở hạ tầng Rails cũng không mang lại cho chúng ta lợi ích như vậy trong trường hợp chung. Tuy nhiên, trong miền ứng dụng Web, tôi đã thấy các ví dụ trong đó Rails mang lại chính xác loại hiệu suất này.

Rails là gì?

Rails là một framework được xây dựng trên ngôn ngữ lập trình Ruby để phát triển, bảo trì và triển khai các ứng dụng Web. Với một số giả định, cơ sở hạ tầng có thể được định nghĩa là một trình tạo ứng dụng hoặc ứng dụng bán thành phẩm có thể được điều chỉnh cho các mục đích khác nhau (sử dụng trong các lĩnh vực chủ đề khác nhau). Đó là tất cả! Rails là một phần mở rộng có mục đích chung cho ngôn ngữ Ruby. Cơ sở hạ tầng này được thiết kế cho một lĩnh vực chủ đề cụ thể - Phát triển web. Rails được xây dựng dựa trên một số nguyên tắc cơ bản giúp thực hiện một số nhiệm vụ thông thường dễ dàng hơn nhiều và giúp hoàn thành các nhiệm vụ mà các phương tiện thông thường không thể đạt được. Rails hào phóng thưởng cho các lập trình viên vì đã tuân thủ các quy ước được các nhà thiết kế khung thông qua bằng cách tạo ra hầu hết một ứng dụng Web điển hình với rất ít yêu cầu lập trình. Bạn có thể gây ấn tượng với đồng nghiệp và người quản lý của mình bằng cách tạo ra các ứng dụng Web tuyệt vời, ngay cả khi bạn chỉ là người mới sử dụng Web.

Rails, còn được gọi là "Ruby on Rails" trong một số bài viết, là sản phẩm trí tuệ của David Heinemeier Hansson, một nhà phát triển ứng dụng Web người Đan Mạch sử dụng ngôn ngữ lập trình Ruby. Anh nhận thấy trong quá trình tạo ứng dụng, anh phải thực hiện nhiều tác vụ thông thường. Giống như nhiều nhà phát triển giỏi, anh bắt đầu tìm cách tự động hóa công việc này. Kết quả của tìm kiếm này là Rails framework. Hansson đã tạo Rails dựa trên ứng dụng có tên Basecamp. Trên thực tế, Rails đã được trích xuất từ ​​Basecamp và được khái quát hóa bằng cách làm nổi bật các điểm chung và gói gọn tính biến đổi. Đây là nguyên tắc chúng tôi thường sử dụng để tạo các ngôn ngữ dành riêng cho từng miền.

Rails là một dự án nguồn mở có cộng đồng nhà phát triển và người dùng rất tích cực. Nếu muốn, bạn có thể tìm hiểu sâu hơn về nội dung bên trong Rails và làm việc với những người dùng cũng như nhà phát triển khác để cải thiện nó. Nhưng nếu bạn chỉ muốn tạo các ứng dụng Web chuyên nghiệp với ít nỗ lực nhất, bạn chỉ cần cài đặt Rails trên hệ thống của mình và bắt đầu. Ồ, tôi quên đề cập - trong số những thứ khác, việc phát triển ứng dụng bằng Rails rất thú vị! Bạn có nhớ cảm xúc của mình khi tạo chương trình hữu ích đầu tiên không? Những cảm giác này quay trở lại với tôi khi lần đầu tiên tôi sử dụng Rails.

Ví dụ đơn giản

Có lẽ mọi bài viết hoặc cuốn sách về Rails đều bắt đầu bằng một ví dụ đơn giản. Tôi sẽ không đưa ra ví dụ này hoặc mô tả chi tiết, tôi sẽ chỉ cho bạn thấy những điểm nổi bật của ví dụ từ cuốn sách phổ biến nhất về Rails, Phát triển linh hoạt với Rails(Phát triển nhanh với Rails) của Thomas và Hansson. Ví dụ này thể hiện cốt lõi của một trang web cửa hàng trực tuyến. Sản phẩm chúng tôi muốn bán đều có tên, mô tả, hình ảnh và giá cả. Sau nửa giờ đọc và nghiên cứu văn bản, tôi tìm thấy một điểm trong ứng dụng nơi bạn có thể thêm sản phẩm vào cơ sở dữ liệu, thay đổi thông tin và xóa chúng. Ứng dụng này sử dụng kiến ​​trúc Model-View-Controller thông thường và Rails giúp dễ dàng duy trì sự phân tách các mối quan tâm vì khung tự động tạo các tệp nguồn hợp lệ trong các thư mục riêng biệt, giúp mục đích của chúng trở nên rõ ràng.

Nội dung của trang Web cuối cùng mà tôi tạo được hiển thị trong Hình 1. Hiện tại tôi chỉ có hai sản phẩm trong danh mục của mình, nhưng chúng ta có thể thấy một số điểm nổi bật trên trang này. Nếu một sản phẩm có hình ảnh giống như sơ đồ cơ chế nhãn của tôi, nó sẽ xuất hiện trên trang. Phần đầu tiên của mô tả sản phẩm được hiển thị cùng với đánh dấu HTML. Có ba liên kết bên cạnh mỗi sản phẩm để chúng ta có thể xem sản phẩm trông như thế nào khi chúng ta hiển thị, chỉnh sửa một mặt hàng hoặc xóa nó. Ngoài ra, còn có liên kết đến trang tạo sản phẩm mới. Rõ ràng là chúng tôi chưa sẵn sàng phát hành trang Web này ra thế giới, nhưng chúng tôi có thể bắt đầu làm việc với các bên quan tâm có yêu cầu đối với ứng dụng của chúng tôi. Điều này cho phép chúng tôi thực hiện một cách tiếp cận lặp đi lặp lại để đạt được các yêu cầu đã xác định, triển khai chúng, xem xét công việc và thực hiện các thay đổi trước lần lặp tiếp theo.

Hình 1. Trang quản lý danh mục sản phẩm

Sự xuất hiện của trang Web của tôi chắc chắn không làm ai ngạc nhiên, nhưng những gì tôi phải làm cho đến thời điểm này là rất nhỏ. Tôi đo khối lượng công việc bằng số lượng lệnh tôi phải nhập từ thiết bị đầu cuối, số dòng mã Ruby, HTML và Ruby nhúng (ERb) mà tôi phải viết. Tôi đã rút ngắn công việc một chút bằng cách sao chép tệp CCS (Cascading Style Sheets) từ các bản tải xuống cho cuốn sách của Thomas và Hansson, vì vậy tôi không đưa những dòng đó vào ước tính lao động của mình. Bảng 1 trình bày kết quả tính toán của tôi.

Bảng 1. Chi phí nhân công quản lý danh mục sản phẩm

Các số trong Bảng 1 đã được làm tròn khi tôi thử nghiệm mã một chút. Nhưng ngay cả khi tôi viết số dòng mã Ruby nhiều gấp đôi, tổng số dòng tôi gõ trong trình soạn thảo hoặc dòng lệnh trong shell terminal sẽ ít hơn 100. Bạn có thể hỏi tôi thực sự đã thu được gì khi viết vài chục dòng. dòng mã chương trình? Đây là danh sách:

Ngoài ra, tôi còn phát hiện ra nhiều điều tuyệt vời hơn nữa mà tôi không phải đối mặt:

• Tôi chưa viết một dòng mã SQL nào, tuy nhiên ứng dụng của tôi được trang bị cơ sở dữ liệu quan hệ;
• Tất cả những gì tôi phải làm là viết một phương thức xác thực để đảm bảo rằng giá là chính xác;
• Tôi không phải viết mã đặc biệt để cập nhật mã ứng dụng của mình khi lược đồ cơ sở dữ liệu thay đổi.

Tôi không phải là nhà phát triển ứng dụng Web. (Tôi không giỏi học công nghệ vì tôi tập trung nhiều hơn vào các khía cạnh khác của phát triển phần mềm. Bạn chỉ có thể làm rất nhiều thứ có sẵn cùng một lúc.) Nhưng với kiến ​​thức rõ ràng là hạn chế về Ruby và HTML, tôi đã tạo ra một số thứ tốt gây ấn tượng với học sinh của bạn bằng cách thể hiện kiến ​​thức của bạn về phát triển Web.

Nguyên tắc đường ray

Làm cách nào Rails cung cấp số lượng chức năng này mà không cần nhiều nỗ lực của nhà phát triển? Một trong những nguyên tắc tái sử dụng là có mối quan hệ nghịch đảo giữa tính linh hoạt của ứng dụng và việc tái sử dụng nó. Nếu bạn muốn thành phần hoặc hệ thống của mình có thể tái sử dụng tốt hơn—nghĩa là có nhiều phần tử có thể tái sử dụng hơn—thì bạn sẽ phải thu hẹp phạm vi sử dụng nó. Đây là điều đầu tiên tôi nghĩ đến khi làm việc với Rails. Rails không phải là một framework thông thường cho phép bạn xây dựng các ứng dụng Web theo bất kỳ cách nào bạn muốn; đúng hơn, nó nhằm mục đích hỗ trợ một nguyên tắc phát triển ứng dụng Web cụ thể. Nếu bạn làm theo các khuyến nghị, bạn có thể đạt được khả năng sử dụng lại đáng kinh ngạc. Nhưng nếu bạn di chuyển ra khỏi hướng đã cho, khả năng sử dụng lại sẽ giảm đi rõ rệt.

Bộ điều khiển xem mô hình

Các nhà phát triển phần mềm đã quen thuộc với kiến ​​trúc Model-View-Controller. Kiến trúc này là nền tảng của các hệ thống giao diện đồ họa người dùng (GUI) đời đầu như giao diện môi trường Smalltalk-80. Khái niệm này rất đơn giản: hệ thống được chia thành ba phần khác nhau (xem Hình 2).

Hình 2. Kiến trúc Model-View-Controller

Kiến trúc MVC chia trách nhiệm của một ứng dụng thành ba phần khác nhau. Model chịu trách nhiệm duy trì trạng thái của ứng dụng. Nó không chỉ truy xuất và lưu trữ dữ liệu mà còn đảm bảo tính toàn vẹn của nó. Logic nghiệp vụ cần được áp dụng cho dữ liệu này được gói gọn trong mô hình. Chế độ xem chịu trách nhiệm hiển thị mô hình cho người dùng ở một hoặc nhiều định dạng. Điều này cho phép mô hình được hiển thị theo nhiều cách khác nhau, tùy thuộc vào nhu cầu của người dùng. Bộ điều khiển có trách nhiệm đảm bảo rằng các thành phần khác thực hiện đúng hành động vào đúng thời điểm. Nó nhận yêu cầu từ người dùng và phân phối chúng đến các thành phần thích hợp. MVC là một kiến ​​trúc đáng tin cậy, hiệu quả cho nhiều loại ứng dụng, bao gồm cả các ứng dụng Web máy khách-máy chủ.

Bằng cách tuân theo các quy ước của Rails, bạn sẽ có sự phân tách rõ ràng các mối quan tâm giữa ba thành phần này. Hình 3 hiển thị một đoạn bố cục của ứng dụng đơn giản của tôi. Chúng ta có thể thấy rằng ứng dụng này có các thư mục riêng cho tất cả các thành phần và một thư mục khác cho tất cả các đối tượng hỗ trợ cần thiết để hỗ trợ chúng.

Hình 3. Phân đoạn cấu trúc ứng dụng

Tại thời điểm phát triển, chúng tôi chỉ có một bộ điều khiển duy nhất, bộ điều khiển quản trị viên. Rails lấy thông tin về bộ điều khiển nào sẽ gọi từ URL hiện tại trên thanh địa chỉ của trình duyệt. Trong trường hợp này, nó được chỉ định trong URL sau địa chỉ máy chủ Web. Khi kiểm tra một ứng dụng, tôi trỏ trình duyệt của mình tới URL http://localhost:3000/admin và localhost:3000 kết nối với máy chủ tôi đang sử dụng - trong trường hợp này là máy chủ WEBrick mặc định đi kèm với Rails. Bộ điều khiển ứng dụng Rails đưa ra yêu cầu tới lớp AdminController. Nếu bạn quan tâm đến nội dung của lớp này, bạn có thể nghiên cứu tệp trong kho lưu trữ kèm theo bài viết này. Bạn sẽ có thể ánh xạ hầu hết các phương thức trong lớp này tới các tham chiếu trong trang Web được hiển thị trong Hình 1. Hầu hết công việc thực sự được thực hiện bởi lớp ApplicationController, lớp này mở rộng lớp AdminController. Đừng lo lắng nếu bạn không hiểu tất cả các chi tiết. Tệp chứa định nghĩa của lớp AdminController, admin_controller.rb, là một trong những tệp lớn nhất trong ứng dụng và tôi chưa viết một dòng nào trong tệp này. Nó hoàn toàn được tạo ra bởi Rails chỉ bằng một lệnh từ tôi.

Phần trình bày của một ứng dụng Web là các trang Web được hiển thị trước mặt người dùng. Rails tạo hầu hết các trang Web cho bạn, nhưng bạn vẫn cần có kiến ​​thức cơ bản về HTML và đủ kỹ năng lập trình Ruby để viết một vài dòng ERb. Không có gì độc đáo về chế độ xem trong Rails. Đối với mỗi hành động, chúng ta phải tạo một tệp .rhtml (Ruby HTML).

Tại thời điểm này, mô hình ứng dụng của tôi khá đơn giản, chỉ có một bảng trong cơ sở dữ liệu về sản phẩm và sản phẩm có bốn thuộc tính mà tôi đã đề cập trước đó. Tôi quyết định đặt URL hình ảnh thành thuộc tính tùy chọn nên không có xác thực nào cho nó. Tất cả các trường khác đều được kiểm tra tính chính xác. Dưới đây là toàn bộ nội dung của tệp sản phẩm.rb. Có phải nó quá lớn không?

lớp học< ActiveRecord::Base validates_presence_of:title, :description validates_numericality_of:price validates_uniqueness_of:title, :message =>"Chúng tôi đã có thứ đó trong danh mục của mình" lỗi xác thực được bảo vệ.add(:price, "phải có giá trị gì đó") nếu price.nil? || giá< 0.01 end end

Ba phương thức valids_ đầu tiên là các phương thức Rails tích hợp, với phương thức xác thực được gọi tự động cho bất kỳ sản phẩm nào đi vào hệ thống. Tôi đã thêm séc để đảm bảo rằng mọi sản phẩm đều có giá ít nhất là 0,01 USD.

Có thể bạn đang thắc mắc làm thế nào mà bảng được tạo ra để ghi lại sản phẩm nếu tôi không viết một dòng SQL nào? Rails có một thành phần khá kỳ diệu tên là Active Record. Bản ghi hoạt động là ánh xạ quan hệ đối tượng (ORM) sử dụng mô hình ORM tiêu chuẩn. Về cốt lõi, nó là một triển khai trừu tượng của mẫu dự án ActiveRecord. Nghĩa là, các bảng được ánh xạ tới các lớp, các đối tượng được ánh xạ tới các hàng và các thuộc tính đối tượng được ánh xạ tới các cột. Active Record, giống như Rails nói chung, sử dụng cách điều khiển màn hình tiêu chuẩn. Nó không hỗ trợ tính linh hoạt đầy đủ nếu không có một số công việc bổ sung. Tuy nhiên, nếu bạn định sử dụng các tính năng tiêu chuẩn của nó theo mặc định thì bạn sẽ phải làm rất ít. Đoạn mã sau biểu thị nội dung của tệp tạo bảng:

lớp TạoSản phẩm< ActiveRecord::Migration def self.up create_table:products do |t| t.column:title, :string t.column:description, :text t.column:image_url, :string end end def self.down drop_table:products end end

Tất cả những gì tôi viết trong mã này là ba dòng t.column.... . Chúng xác định tiêu đề, mô tả và thuộc tính URL của hình ảnh. Để chuẩn bị và định cấu hình cơ sở dữ liệu, tôi đã làm theo các bước sau:

1. Trên dòng lệnh tôi đã nhập lệnh:

   Mysqladmin -u root tạo depot_development

   Kết quả của lệnh này là một cơ sở dữ liệu đã được tạo cho sự phát triển của tôi;

2. Tôi đã điều hướng đến thư mục gốc của ứng dụng và nhập lệnh sau:

   Tập lệnh Ruby/tạo sản phẩm mô hình

   Bảng SẢN PHẨM đã được tạo trong cơ sở dữ liệu. Ngoài ra, một số tệp đã được tạo, bao gồm tệp 001_create_products.rb trong thư mục db/migrate của ứng dụng. Đây là tập tin được hiển thị trong danh sách trước đó;

3. Tôi đã chỉnh sửa tệp để thêm ba định nghĩa cho các cột;
4. Tôi đã nhập lệnh:

   Cào db: di chuyển

   Các cột đã được tạo trong bảng SẢN PHẨM. Lệnh rake tương đương với lệnh make được sử dụng trong Rails.

Mỗi lần cập nhật lược đồ cơ sở dữ liệu, bạn phải tạo một tệp di chuyển theo cách tương tự như trình tự trước đó. Mỗi tệp di chuyển bắt đầu bằng một số thứ tự lớn hơn tệp di chuyển trước đó một đơn vị và số này tương ứng với phiên bản lược đồ, được lưu trữ trong một bảng cơ sở dữ liệu đặc biệt. Bây giờ bạn có thể cập nhật cơ sở dữ liệu của mình và khôi phục các thay đổi mà không tốn nhiều công sức. Rails làm mọi thứ cho bạn.

Điều này kết thúc việc khám phá kiến ​​trúc MVC, nền tảng của ứng dụng Rails và chuyển sang các nguyên tắc khác.

Thỏa thuận cấu hình

Tôi đã chứng minh nguyên tắc này bằng hành động. Một ứng dụng Rails khá nghiêm ngặt về việc tuân theo một số quy ước. Một số quy ước là những quy ước đặt tên đơn giản, trong khi những quy ước khác liên quan nhiều hơn đến kiến ​​trúc của ứng dụng. Rails có cái nhìn rất rõ ràng về cách xây dựng một ứng dụng Web và nó sử dụng các giá trị mặc định dựa trên mô hình này. Việc cho phép mặc định cho phép tạo ra một phần ứng dụng lớn hơn nhiều so với khả năng có thể có của cơ sở hạ tầng. Nó cũng loại bỏ nhu cầu tốn thời gian cấu hình các môi trường phát triển, thử nghiệm và triển khai. Có hai tệp cấu hình có thể được sửa đổi nếu bạn cần thêm loại MIME hoặc thông tin khác không phù hợp với các tình huống sử dụng thông thường. Một trong những tệp mà bạn có thể cần chỉnh sửa là tệp cơ sở dữ liệu.yml, tệp này mô tả các cài đặt cơ bản cho môi trường phát triển, thử nghiệm và triển khai. Khi tôi tạo ứng dụng, tệp này được tạo với các giá trị mặc định, như trong danh sách sau.

# MySQL (cài đặt mặc định). Nên sử dụng phiên bản 4.1 và 5.0. # # Cài đặt trình điều khiển MySQL: # gem install mysql # Trên MacOS X: # gem install mysql -- --include=/usr/local/lib # Trên Windows: # gem install mysql # Chọn bản dựng win32. # Cài đặt MySQL và đặt bản dựng vào thư mục /bin được chỉ định trong biến đường dẫn. # # Đảm bảo bạn sử dụng kiểu băm mật khẩu mới: # http://dev.mysql.com/doc/refman/5.0/en/old-client.html Development: adapter: cơ sở dữ liệu mysql: tên người dùng depot_development: mật khẩu gốc: máy chủ : localhost # Cảnh báo: Cơ sở dữ liệu được xác định là "kiểm tra" sẽ bị xóa và #được tạo lại khỏi cơ sở dữ liệu đã phát triển của bạn khi bạn chạy "rake". # Không đặt tên giống như cơ sở dữ liệu này trong quá trình phát triển # hoặc trong sử dụng thực tế. kiểm tra: bộ chuyển đổi: cơ sở dữ liệu mysql: tên người dùng depot_test: mật khẩu gốc: máy chủ: sản xuất localhost: bộ chuyển đổi: cơ sở dữ liệu mysql: tên người dùng depot_production: mật khẩu gốc: máy chủ: localhost

Lưu ý rằng mã này sử dụng ba cơ sở dữ liệu khác nhau cho từng môi trường. Nhận xét phía trên mỗi cấu hình môi trường thử nghiệm nói về một số tính năng bổ sung trong quá trình phát triển ứng dụng với Rails. Kiểm tra là một giai đoạn đặc quyền trong quá trình phát triển Rails. Khi bạn mở rộng và sửa đổi ứng dụng của mình theo quy ước, Rails sẽ giúp bạn bằng cách tạo các thử nghiệm tự động chạy mà không cần sự trợ giúp của tiện ích cào. Các thử nghiệm được thực hiện tự động trong một môi trường riêng biệt, giao diện không trùng lặp với môi trường phát triển hoặc sản xuất.

nguyên tắc DRY

Nguyên tắc cuối cùng được sử dụng trong các ứng dụng Rails là nguyên tắc DRY (Đừng lặp lại chính mình, đừng lặp lại chính mình). Các nhà thiết kế và lập trình viên giỏi sử dụng nguyên tắc này trong thực tế. Họ biết rằng nếu việc gì đó được thực hiện một lần, ở một nơi thì sau đó. các dự án trở nên đơn giản hơn và làm việc dễ quản lý hơn nhiều.

Cách tổ chức và tạo ứng dụng trong Rails theo cách DRY rất đơn giản miễn là bạn tuân theo các quy ước. Nếu bạn có thể hiểu mã cơ bản cho một ứng dụng Rails, bạn có thể cho rằng bạn có thể hiểu bất kỳ ứng dụng Rails nào tuân theo các quy ước. Không có gì được lặp lại. Mọi thứ đều ở một nơi và mọi thứ đều có ý nghĩa.

Nhưng liệu ứng dụng có thể mở rộng được không?

Bất cứ khi nào tôi bắt gặp một thứ gì đó có vẻ đơn giản như Rails, tôi lại tự hỏi liệu nó có thể hoạt động trong môi trường sản xuất thực sự với tải nặng hay không. Tôi đã thấy quá nhiều công cụ hứa hẹn tăng hiệu suất đáng kể. Họ thực hiện tốt các dự án “đồ chơi”, nhưng lại thất bại hoàn toàn ở những lần đầu áp dụng chúng vào giải quyết các vấn đề thực tế. Tôi biết khá nhiều câu chuyện thành công liên quan đến Rails, nhưng sự tự tin thực sự đã đến với tôi vào năm ngoái khi chúng tôi triển khai thành công Rails trong viện của mình.

Một trong những đồng nghiệp của tôi tại Học viện Bách khoa Worcester đang phát triển một hệ thống học tập thông minh có tên là Hỗ trợ để giúp giảng viên và sinh viên trong các khóa học khác nhau học và dạy các môn học khác nhau. Giống như nhiều tiểu bang, học sinh tiểu học và trung học của tiểu bang chúng ta phải thực hiện một loạt bài kiểm tra tiêu chuẩn hóa như một phần của quá trình giáo dục để cuối cùng có được bằng đại học. Những bài kiểm tra này, được gọi là bài kiểm tra MCAS, được cung cấp ở mọi cấp lớp để đánh giá trình độ của học sinh trong các môn học chính. Hệ thống học tập Hỗ trợ đã được chứng minh là có hiệu quả trong việc giúp học sinh tiếp thu kiến ​​thức và kỹ năng cần thiết. Năm ngoái, Hỗ trợ đã được sử dụng bởi một nhóm nhỏ sinh viên ở Worcester, Massachusetts, nhưng nhóm Hỗ trợ của đồng nghiệp của tôi đã sớm chuẩn bị cho việc triển khai lớn hơn.

Hỗ trợ là một ứng dụng Web máy chủ-máy khách điển hình. Nó không chỉ giúp giáo viên và học sinh tự sử dụng mà còn hỗ trợ các nhà nghiên cứu phát triển các kỹ thuật giảng dạy mới và cung cấp các chức năng đánh giá. Năm ngoái, Hỗ trợ chứa hơn 50.000 dòng mã, chủ yếu bằng Java. Mã bao gồm nhiều gói và lớp học được phát triển trong nhiều năm bởi các sinh viên đại học và sau đại học. Thật không may, nhóm phát triển thiếu tính nhất quán, vì vậy mã trở nên cực kỳ khó quản lý - tức là nó ngày càng trở nên mỏng manh hơn. Nhóm có thể làm gì để đảm bảo chất lượng cần thiết cho việc triển khai trên quy mô lớn?

Chúng tôi có ba lựa chọn khả thi. Đầu tiên, những nỗ lực quản lý và mở rộng hệ thống hiện tại có thể tiếp tục. Điều này khó có thể kéo dài. Thứ hai, chúng ta có thể viết lại hệ thống từ đầu hoặc cố gắng phát triển kiến ​​trúc hiện có thành hệ thống mà chúng ta cần. Điều này sẽ liên quan đến việc lập trình bằng Java. Lúc đầu nhóm có xu hướng chọn phương án này.

Chúng tôi đã nhận được lựa chọn thứ ba nhờ một trong những sinh viên tốt nghiệp đã tham gia vào công việc Hỗ trợ - anh ấy đề xuất viết lại hệ thống bằng Rails. Người ta có thể tưởng tượng được sự khó chịu mà đề xuất này gây ra cho các đồng chí của anh ấy và vị giáo sư giám sát nhóm. Sinh viên này đã dành vài tuần để phát triển ứng dụng chính, chứa hầu hết chức năng của hệ thống Hỗ trợ. Để làm được điều này, anh phải viết hàng nghìn dòng mã chương trình.

Anh đã thuyết phục được mọi người. Nhóm đã phê duyệt quá trình phát triển và bắt đầu làm việc. Hệ thống mới có tất cả các tính năng của hệ thống cũ và một số tính năng mới, bao gồm giao diện người dùng được cải tiến. Thông tin cuối cùng tôi nhận được là nhóm phải viết và duy trì ít hơn 5.000 dòng mã. Điều này có nghĩa là năng suất tăng hơn 10 lần, với ít lỗi hơn mức trung bình được tìm thấy trong hệ thống.

Đúng, Rails không phải là một món đồ chơi.

Thay vì một kết luận

Ý tưởng tạo chương trình tự động không phải là mới. Tuy nhiên, trong những năm gần đây chúng tôi đã cải tiến đáng kể công nghệ này. Rails là một trong những framework rất hiệu quả để tạo một số loại chương trình nhất định một cách rõ ràng, nhất quán với nỗ lực tối thiểu. Chúng ta có thể mong đợi các hệ thống như Rails sẽ xuất hiện cho các miền khác. Điều này không tệ chút nào về mặt kinh tế. Trên thực tế, có hai hiện tượng khác trong lĩnh vực tạo ứng dụng Web. Đây là hai framework giống Rails được viết bằng PHP. Chúng được gọi là Symfony và CakePHP. Một sự phát triển thú vị khác trong lĩnh vực này mới xuất hiện gần đây là Project Zero, một dự án vườn ươm của IBM. Project Zero không phải là một trình tạo ứng dụng, nhưng nó cung cấp các quy ước và khung làm việc gợi nhớ đến Rails

Nếu bạn chưa bắt tay vào phát triển ứng dụng Web, tôi hy vọng bài viết này cung cấp cho bạn một số thông tin để suy nghĩ và khuyến khích bạn dành chút thời gian, vui vẻ và bắt đầu sử dụng Rails.

Ghi chú

1 Nhiều hướng dẫn có thể giúp bạn trong quá trình thực hiện. Một số trong số chúng được liệt kê trong phần Tài nguyên ở cuối bài viết này. Hãy làm theo hướng dẫn và bạn sẽ ngạc nhiên về việc tạo một ứng dụng Web dễ dàng như thế nào.

2 Phiên bản beta đầu tiên của Rails được phát hành vào tháng 7 năm 2004. Rails 1.0 được phát hành vào tháng 12 năm 2005. Các ví dụ trong bài viết này sử dụng phiên bản 1.2.2.

10 Hệ thống Đánh giá Toàn diện của Massachusetts Xem: