Đôi khi có cảm giác rằng công ty của tôi là công ty duy nhất trên thế giới sử dụng Ruby nhưng không phải Ruby on Rails, đến mức Rails gần như trở thành đồng nghĩa với Ruby.
Tôi chắc rằng điều này không thực sự đúng, nhưng sẽ rất vui khi nghe một số câu chuyện về việc sử dụng Ruby không phải Rails.
Câu trả lời:
Một trong những lợi ích to lớn của Ruby là khả năng tạo DSL rất dễ dàng. Ruby cho phép bạn tạo "các quy tắc kinh doanh" theo cách ngôn ngữ tự nhiên, đủ dễ dàng để một nhà phân tích kinh doanh sử dụng. Nhiều ứng dụng Ruby bên ngoài phát triển web tồn tại cho mục đích này.
Tôi thực sự khuyên bạn nên sử dụng "ruby dsl" trên Google cho một số bài đọc xuất sắc, nhưng tôi đặc biệt muốn gửi đến bạn một bài đăng. Russ Olsen đã viết một bài blog hai phần trên DSL . Tôi thấy anh ấy thuyết trình về DSLs và nó rất hay. Tôi thực sự khuyên bạn nên đọc những bài viết này.
Tôi cũng tìm thấy bài thuyết trình xuất sắc này trên Ruby DSLs của Obie Fernandez . Rất khuyến khích đọc!
Tôi sử dụng Ruby rộng rãi trong công việc của mình và không có ứng dụng nào dựa trên Rails (hoặc thậm chí là web).
Miền của tôi thường là các ứng dụng Windows phía máy khách (wxRuby GUI) và các tập lệnh, tự động hóa các truy vấn Excel, Internet Explorer, SQL Server và tạo báo cáo (tự động hóa win32ole COM). Tôi cũng sử dụng các thư viện sqlite, pdf-writer và gruff cho các tác vụ tạo dữ liệu và tạo đồ thị khác nhau.
Thành công của Rails là rất lớn đối với Ruby, nhưng tôi đồng ý rằng Rails đã nhận được rất nhiều sự chú ý nên giá trị của Ruby ngoài web thường bị bỏ qua.
Chúng tôi chủ yếu là một cửa hàng C ++, nhưng chúng tôi đã tìm thấy một số lĩnh vực mà Ruby đã được chứng minh là khá hữu ích. Ở đây có một ít:
Về cơ bản, Ruby là công cụ cần thiết của tôi khi nó có ý nghĩa. Và nó có ý nghĩa ở rất nhiều nơi.
Google Sketchup sử dụng Ruby làm ngôn ngữ kịch bản nhúng. Bạn có thể sử dụng nó để thực hiện tất cả các loại tác vụ mô hình 3d và nhập / xuất. Tập lệnh hoạt động với phiên bản miễn phí và thậm chí còn có cả tài liệu hướng dẫn .
Ruby với phần mở rộng homebrew được viết bằng C ++ thực hiện tất cả các điểm ảnh nặng cho quá trình xử lý ảnh của tôi. Tôi đã sử dụng Python + numpy nhưng khi làm những thứ nghệ thuật , Ruby chỉ thú vị hơn. Ngoài ra, việc tương đối thiếu, hoặc ít trưởng thành hơn về các thư viện xử lý hình ảnh tốt khiến tôi không cảm thấy như mình đang phát minh lại bánh xe. Tôi không biết gì về Rails, ngoài việc tôi đã nghe nói về nó, tôi không biết nó là gì, và thực sự có một cuốn sách về nó (chưa mở)
Hoặc bạn có thể sử dụng Ruby để tạo nhạc cho Archaeopteryx của Giles Bowkett. Bài thuyết trình này của Giles về Archaeopteryx là một trong những bài thuyết trình hay nhất từ trước đến nay. Tôi khuyên bạn nên nó.
RubyCocoa và MacRuby. Có thể tạo các ứng dụng GUI dựa trên Cocoa đầy đủ mà không cần Rails. Và sau đó bạn cũng có thể sử dụng Trình tạo giao diện.
Tôi đã làm việc trong một dự án bảo tàng năm ngoái sử dụng rất nhiều Ruby. ( http: // http: //ourspace.tepapa.com/home )
Phần mà tôi đã dành phần lớn thời gian của mình là một bản đồ sàn tương tác. Bản đồ trên sàn có các cảm biến để khi mọi người đi bộ trên đó, đèn sẽ được kích hoạt và hiển thị trên tường cho thấy hình ảnh hoặc video và bản âm thanh được phát.
Tất cả mã điều khiển cho phần này của cuộc triển lãm là ruby. Tôi đã viết giao diện C với trình bao bọc ruby để giao tiếp với cảm biến sàn và bộ điều khiển ánh sáng. Hệ thống truy vấn cơ sở dữ liệu MYSQL để hiển thị các tệp phương tiện và sau đó ra lệnh cho các máy tính trong tường phát phương tiện qua UDP.
Đó là phần đáng tin cậy nhất của toàn bộ cuộc triển lãm.
Ruby đã được sử dụng cho phần chính khác của cuộc triển lãm, Bức tường mặc dù tôi không liên quan nhiều đến điều đó. Hầu hết đồ họa được tạo nguyên mẫu bằng ruby sử dụng giao diện với OpenGL, một chút Cocoa và thư viện vật lý trước khi được chuyển sang Obj-C thuần túy.
Tôi không thấy đề cập đến Con rối hoặc Đầu bếp trong 30 câu trả lời trước khi tôi đến. Ruby dường như thống trị công việc hiện tại trong tự động hóa đám mây và là ngôn ngữ cơ bản, tiện ích mở rộng và tạo khuôn mẫu của hai người chơi lớn này. Chúng được sử dụng chủ yếu để phân phối thông tin cấu hình hệ thống và ứng dụng cho mảng máy chủ và quản lý máy trạm CNTT nói chung.
Trường DevOps khá dễ hiểu về Ruby. Hôm nay, Perl có một đối thủ cạnh tranh. Mặc dù một script thực sự đơn giản thường vẫn có thể được viết trực tiếp cho sh(1),một tác vụ phức tạp thì giờ đây có thể được thực hiện bằng Ruby chứ không phải Perl.
Trang web duy nhất tôi đã làm với Ruby tại nơi làm việc đang sử dụng Rails, nhưng tôi muốn thử Merb .
Ngoài ra, tôi thực hiện rất nhiều chương trình tiện ích nhỏ trong Ruby - ví dụ như một ứng dụng đọc nguồn cấp dữ liệu RSS và nhập các bài đăng mới vào một dabase.
Thật là vui nên tôi cũng viết vài thứ vớ vẩn chỉ vì nó quá nhanh. Hôm qua, tôi đã viết một ứng dụng để chơi bài toán Monty Hall 100.000 lần để giúp một người bạn thuyết phục giáo sư của cô ấy rằng chuyển đổi là chiến lược chính xác.
Tôi gần như xúc phạm rằng ruby là một thứ đường ray. Nó giống như khi CGI là xu hướng mới nhất và mọi người đều hình dung rằng nếu bạn biết perl, bạn phải làm điều đó chỉ vì bạn đã lập trình ứng dụng CGI. Ruby chỉ là một ngôn ngữ kịch bản đối với tôi, mặc dù không thuần thục như python nên tôi hơi tiếc khi phải nhảy qua một số vòng lặp của nó và những thay đổi gần đây, tôi vẫn thích và sử dụng nó. Mặc dù tôi làm việc trong một cửa hàng java và do đó, groovy là lựa chọn lý tưởng cho ngôn ngữ viết kịch bản, tôi vẫn sử dụng ruby ở nhà và để vứt bỏ các tập lệnh không cần thiết để chia sẻ tại nơi làm việc.
Tôi đã xem xét việc tham gia vào RoR từ tất cả những lời bàn tán và nó nhanh chóng / đơn giản như thế nào, nhưng sau khi nhìn qua các đường ray, tôi không thấy bất kỳ điều gì đáng kinh ngạc hoặc thậm chí là một chút đổi mới hoặc nhanh chóng về sự phát triển của nó so với bất kỳ điều gì khác khuôn khổ. Lợi ích duy nhất mà tôi thấy là tôi có thể viết mã bằng ruby, điều này thật tuyệt, nhưng thiết lập ban đầu, bảo trì máy chủ và mở rộng quy mô khó hơn, do đó bù đắp lại niềm vui khi viết mã bằng ruby.
Tôi đã tạo một bản trình bày - trùng hợp có tên là Off The Rails - để thảo luận về các ứng dụng web dựa trên Rack:
https://github.com/alexch/Off-The-Rails
Git repo bao gồm các slide ở định dạng Markdown và mã mẫu (ở dạng ứng dụng đang chạy và phần mềm trung gian). Đây là phần tóm tắt:
Ruby on Rails là khung ứng dụng web phổ biến nhất cho Ruby. Nhưng nó không phải là duy nhất! Nếu bạn cho rằng Rails quá lớn, hoặc quá cố chấp, hoặc quá bất cứ điều gì, bạn có thể rất vui khi tìm hiểu về thế hệ mới của cái gọi là microframeworks được xây dựng trên Rack. Và vì bản thân Rails 3 là một ứng dụng Rack, bạn không cần phải từ bỏ Rails để nhận được lợi ích của các tuyến Sinatra hoặc API Grape.
Và đây là một số tài liệu tham khảo:
Hi vọng bạn tìm được thứ hữu dụng!
Tôi hầu hết là một nhà phát triển Web và tôi đã học Ruby để sử dụng Rails, nhưng tôi thích ngôn ngữ này đến nỗi tôi bắt đầu phát triển một ứng dụng Swing trên máy tính để bàn bằng Ruby, sử dụng JRuby và Monkeybars. Tôi có năng lực về Java, nhưng không thích sử dụng nó, và API Swing rất kinh khủng, vì vậy việc đưa Ruby lên đầu đã là một chiến thắng lớn.
Chúng tôi chủ yếu sử dụng đường ray, nhưng chúng tôi có nhiều thứ ruby khác không phải đường ray - ví dụ như một thứ daemon xác thực độc lập để xác thực tập trung người dùng và một 'máy chủ xử lý hình ảnh' chạy số lượng quy trình ruby tùy ý để xử lý hình ảnh song song.
Ồ, và đừng quên Rake cũ tốt :-)
Ruby cũng được sử dụng cho ứng dụng Desktop. Đặc biệt là việc sử dụng JRuby để phát triển ứng dụng Swing desktop.
Tôi đã sử dụng Ruby tại nơi làm việc cho
Chúng tôi sử dụng Ruby để triển khai phần mềm tự động hóa thử nghiệm của mình. Điều này bao gồm khung thử nghiệm và mã trình điều khiển cho Selenium RC, WATIR và AutoIT.
Ruby đủ mạnh để tạo các ứng dụng toàn diện có thể giao tiếp với các công cụ Kiểm tra như Selenium hoặc WATIR, đồng thời đọc từ các tệp dữ liệu, tương tác với giao diện người dùng Windows từ xa và thực hiện giao tiếp mạng gần như trong suốt. Tất cả trong khi chạy trên Windows hoặc Linux.
Cú pháp gọn gàng làm cho nó lý tưởng cho các lập trình viên mới và chưa có kinh nghiệm đọc. Mặc dù bản chất OO hoàn toàn của nó giúp cho những lập trình viên này dễ dàng áp dụng các kỹ thuật OO tốt (đã học gần đây) ngay từ đầu.
Bản chất linh hoạt trong cú pháp của Ruby cũng làm cho việc sử dụng và tạo các DSL dễ dàng hơn nhiều. Điều này cho phép những người ít kỹ thuật hơn có thể xâm nhập, đọc và có thể tạo ra các bài kiểm tra của riêng mình.
Tôi đã sử dụng Ruby để tạo mã của các thủ tục được lưu trữ C # và T-SQL trong một dự án có yêu cầu không ổn định. Mô hình dữ liệu được mã hóa trong tệp YAML và các mẫu .erb được sử dụng cho các lớp và thủ tục được lưu trữ. Nó cũng cho phép một giải pháp KHÔ hơn nhiều so với khả năng có thể xảy ra với C # thẳng vì mã lặp lại có thể được tính thành một phương thức duy nhất trong trình tạo mã.
Ở nơi tôi làm việc, chúng tôi sử dụng Ruby để thực hiện một số công việc hàng loạt loại một lần khác nhau. Một ví dụ về điều đó là một công việc tương tác với dịch vụ S3 của Amazon. Vào thời điểm đó, thư viện Ruby S3 có lẽ là thư viện dễ dàng nhất để chúng tôi thiết lập và chạy trong một khoảng thời gian ngắn.
Tôi là một người dùng webdriver. ruby được sử dụng bởi webdriver để tự động hóa quá trình xây dựng nhờ rake. xem http://code.google.com/p/webdriver/ để biết chi tiết
Heh, câu hỏi hay.
Tôi đã sử dụng Ruby để chuyển đổi dữ liệu cơ sở sân bay trong bảng tính Excel sang sqlite3 cho nền tảng điện thoại Android trong khi tạo ứng dụng cho phi công.
Tôi sử dụng Ruby với Sinatra đơn giản hơn nhiều so với Rails. Tôi đã sử dụng Rails nhưng chỉ thấy rằng nó đã biến thành một con quái vật, mặc dù Rails vẫn rất tuyệt vời so với các web framework có sẵn cho Java.
Tuy nhiên, tính năng chính của Ruby mà tôi yêu thích là "eval" và "method_missing", mà Rails thực sự sử dụng ví dụ như trong ActiveRecord để bạn có thể sử dụng các truy vấn "find_by-field-name-" tuyệt vời.
Tôi đã sử dụng Ruby cho rất nhiều mã back-end đơn giản vì tôi là người duy nhất được giao nhiệm vụ làm điều đó và cần một ngôn ngữ sạch đẹp cho phép tôi làm việc hiệu quả và viết mã dễ bảo trì. Tôi thấy Ruby cho phép tôi làm điều đó dễ dàng hơn Perl và Python. Số dặm của người khác có thể khác nhau về điều đó nhưng nó hoạt động tốt đối với tôi.
Bên cạnh đó, tôi thích cách Sequel và Nokogiri hoạt động. Tôi cũng đã sử dụng ActiveRecord trong một thời gian riêng biệt với Rails.
Chúng tôi sử dụng một số Ruby để thao tác tệp nhưng vẫn chưa thể kết hợp các đường ray.
Ở Boulder, có một nhóm người dùng Ruby xuất sắc gặp nhau hàng tháng. Điểm này đã được thực hiện - rằng Ruby có tồn tại bên cạnh việc sử dụng nó trong Rails. Người dùng Plain Ruby thực sự tồn tại, đang cầu xin sự chú ý, có những thứ gọn gàng để hiển thị và có thể tìm thấy nhau tại các cuộc họp nhóm người dùng.
Họ cũng ăn pizza ngon hơn nhóm Python, những người đã gặp nhau cùng ngày trong tháng. Chỉ có thể chọn một ...
Mặc dù chúng tôi có một số ứng dụng Rails đang hoạt động, chúng tôi cũng sử dụng Ruby cho một số nội dung không phải web khá chuyên sâu.
Chúng tôi đã có một trình nền gửi SMS, kéo các tin nhắn từ một hàng đợi và sau đó gửi chúng và trình nền xử lý thẻ tín dụng mà các ứng dụng khác có thể gọi đến, điều này đảm bảo có một dấu vết kiểm tra trung tâm.