Интересные (на мой взгляд) куски из статьи:
Список проектов работающих на Rails:
Когда вам нужен Rails?
- Вы разрабатываете обычное веб-приложение. Вы ожидаете, что проект будет жить долго. Вам нужно, чтобы инструмент продолжал развиваться и жить, нужна поддержка от сообщества или от какой-нибудь компании, возможность нанять специалиста. В таком случае, Rails - прекрасный выбор. Альтернатив хватает, выбирать есть из чего. Но вы все равно выберете Rails, ведь это по-прежнему модно ;-)
- Вы предполагаете постоянное изменение требований и функционала, вектора развития проекта. У вас нет постоянной концепции продукта, она меняется и зависит от обратной связи с пользователями. Rails в этом случае отличный выбор.
- Вам нужно “быстрое прототипирование”. Rails до сих пор хорош для этого. Альтернативы, конечно же, найдутся, но Rails очень хорош и в этом.
- Вы отчётливо понимаете требования к проекту и функционалу. Вы не ожидаете быстрых изменений функционала. К примеру, у вас уже есть прототип или вы уже делали что-то очень похожее и можете сразу отливать архитектуру в бронзе.
- Вы ищете то, чего никогда не найдёте в динамически типизированном языке, - высокую (высочайшую) скорость работы и низкое потребление ресурсов сервера. (это скорее ниша Elexir и Erlang)
- У вас уже есть команда профессионалов которые хотят использовать другой фреймворк.
Таблицы я обновил
Вот эта забавная таблица сравнений по критериям популярности репозитория на GitHub и количества вопросов на StackOverflow (hotframeworks.com) говорит что Rails всё ещё в топе:
Согласно Google Trands, Rails тоже популярен в поисковых запросах в сравнении с сопоставимыми фреймворками.
Что может предложить стек Ruby/Rails менеджеру проекта
Это хороший выбор для быстрого старта проекта. Вы будете поражены скоростью разработки. Вы пишете меньше кода, действительно меньше. Вы будто бабочка - одним взмахом крыла вызываете ураганы. Доступны огромное количество открытых библиотек и инструментов, платформ для развертывания. Есть прекрасная документация и много обучающих ресурсов. Большое сообщество всегда поможет решить возникшую проблему. Экосистема взрослая и стабильная. Стандартные задачи уже давно имеют готовые решения. Многие идеи, решения и подходы, родившиеся в симбиозе Rails и Ruby переняли или адаптировали в других фреймворках. Rails делал и продолжает делать мир веб-разработки лучше.
Важно понимать, что Rails предлагает не только стабильный и зрелый стек технологий и экосистему. Он предлагает постоянное развитие. Rails привносил и популяризировал много удачных решений и подходов. Он повлиял на многие фреймворки, иногда даже очень сильно. Просто вбейте в google "rails like + language". Rails-like фреймворки росли как грибы после дождя для многих популярных платформ - Java, Scala, NodeJs, PHP и даже Erlang. Вообще вся экосистема Ruby/Rails оказала влияние на инструменты разработки на других платформах. Инструменты развертывания приложений, пакетные менеджеры, менеджеры зависимостей, шаблонизаторы и препроцессоры. Если вы хотите быть на острие веб-технологий и не собираетесь ждать, пока это портируют на вашу платформу, тогда Rails - ваш выбор. Постоянное развитие, функциональность и помощь сообщества делают Rails отличным и надежным инструментом.
Что может предложить стек Ruby/Rails разработчику
Одна из особенностей подхода Rails это подход Convention over configuration. На практике это означает, что пока вы следуете соглашениям, вы избавлены от конфигурирования и настройки. Во всех компонентах и слоях абстракций. Если какое-то соглашение вам не подходит - окей! - у вас всегда есть способ настроить всё под себя. Фреймворк скрывает от вас сложность проблем и пока вы следуете соглашениям, все работает как по волшебству. Сложности начинаются когда соглашение вам не подходит.
Rails это удивительно модульный и настраиваемый инструмент. У вас есть штатный (предусмотренный разработчиками) способ расширить/переопределить поведение тех или иных компонентов. Вы можете встроиться в процесс отправки писем и модифицировать письмо. Например, вам нужно изменить тему письма так, чтобы на тестовом сервере все письма приходили с постфиксом "[Staging]". Вам надо поддерживать визуальные темы для веб-страниц и динамически определять путь, откуда будут браться html-шаблоны? Легко - вам нужно просто переопределить отвечающий за это компонент (path resolver). Вам надо выполнять какой-то служебный код до начала обработки запроса вашим кодом? Встраиваете свой middleware в очередь стандартных.
Каждый, кто сталкивался с выбором фреймворка или стека технологий, в конце концов приходил к какому-то чек-листу возможностей, и выбор делался исходя из того, поддерживает конкретный фреймворк ту или иную возможность. Давайте посмотрим, что вы получаете, выбирая Rails. Вы получаете ORM - ActiveRecord. Как можно догадаться, используется одноименный шаблон доступа к данным. Вашу жизнь сильно облегчат принятые соглашения. Вам не надо ничего конфигурировать. Пока вы руководствуетесь стандартными соглашениями, вы не напишите ни строчки конфигурации (я вру, конечно, вы всё равно должны сконфигурировать доступ к базе данных, указать username, password итд). Пример классов-моделей, они представляют конкретные таблицы базы данных из документации:
class Customer < ActiveRecord::Base
has_many :orders
end
class Order < ActiveRecord::Base
belongs_to :customer
end
И это все. Это работает без единой строчки конфигурации. По умолчанию предполагается, что в базе у вас есть таблицы orders и customers. В orders есть внешний ключ с именем customer_id. Первичные ключи называются id. На этом все. Вы соблюдаете соглашения именования и все само работает. Теперь вы можете строить и выполнять SQL-запросы совершенно очевидным и естественным способом:
customer.orders
#=> [order1, order2,...]
order.customer
#=> customer
Окей, идем дальше. Маршрутизация запросов (routes). Это поразительно. Вы можете все, и очень многое из этого “всего” бесплатно. Но это если вы руководствуетесь соглашениями. Пример маршрута из документации
resources :books
Благодаря магии Rails эта одна скромная строчка способна создать пачку маршрутов для CRUD:
$ bundle exec rake routes | grep book
books GET /books(.:format) books#index
POST /books(.:format) books#create
new_book GET /books/new(.:format) books#new
edit_book GET /books/:id/edit(.:format) books#edit
book GET /books/:id(.:format) books#show
PATCH /books/:id(.:format) books#update
PUT /books/:id(.:format) books#update
DELETE /books/:id(.:format) books#destroy
Продолжение можно найти тут
Комментариев нет:
Отправить комментарий