Ruby on rails. passenger quickstart
Содержание:
Railties
- Каждому приложению отныне присваиватся свое собственное пространство имен (к примеру, запуск приложение выполняется так: ), что делает взаимодействие между приложениями значительно проще.
- Теперь можно обратиться к , где доступно огромное множество настроек конфигурации вашего приложения.
- Всё внутри теперь автоматически добавляется к , поэтому теперь можно, скажем, добавить файл , и Rails просто подгрузит его.
- Генераторы были переписаны с нуля и более не являются обратно совместимыми.
- API шаблонов и генераторов были соединены воедино.
- Генераторы больше не загружаются из специального пути (load path), а просто подгружаются из пути загрузки (Ruby load path), поэтому вызов сделает тоже, что и
- Теперь к генератором можно легко подключить любой новый движок шаблонов, ORM или фреймворк для тестирования.
- В новых генераторах можно легко переписывать исходные шаблоны, просто положив нужный файл в .
- Появился , благодаря которому можно создавать и тестировать собственные генераторы.
- В генерируемых вьюшках теперь используются теги вместо .
- При генерации форм c помощью scaffold, вместо того чтобы дублировать код во вьюшках edit и new, теперь используется partial с припиской
- При генерации форм c помощью scaffold теперь используется , который возвращает “Create ModelName” или “Update ModelName”, в зависимости от состояния в котором пришел объект
- Был добавлен таск , благодаря которому теперь можно крутить миграции вперед индивидуально или в группах.
- Был добавлен таск , что позволяет теперь просматривать роуты для одного конкретного контроллера.
- в пользу ,
- в пользу ,
- в пользу .
Дополнительная информация
- Discovering Rails 3 generators
- Making Generators for Rails 3 with Thor
- The Rails Moduler
Active Record
9.1 Интерфейс запросов
- — предоставляет условие для reletion, т.е. что будет выбрано.
- — выбор нужного аттрибута из БД.
- — группирует relation на предоставленном аттрибуте.
- — аналог из SQL.
- — выполняет объеденение relation’a с другой таблицей.
- — аналог из SQL.
- — включает другие, созданные ранее ralations.
- — упорядочивает relation согласно переданному выражению.
- — устанавливает предел количества записей в relation.
- — блокирует пришедшие из БД записи.
- — возвращает копию данных в режиме доступа «только для чтения».
- — дает возможность для relation’a делать выборку из нескольких таблиц.
- — (ранее ) вовзращает объект relation.
- — как и , также возвращает объект relation.
- — также работает с relation’ами
Дополнительная информация
9.2 Прочие улучшения
- добавлен к объектам Active Record
- добавлен для отношений, позволяя получить уже загрузившееся отношение без обращения к БД
9.3 Патчи и прекращения поддержки
- Поддержка SQLite 2 прекращена в пользу SQLite 3.
- Реализована поддержка для порядка колонок в MySQL.
- В адаптере для PostgreSQL исправлена — больше никаких ошибочных значений.
- Поддержка нескольких схем для таблиц в PostgreSQL.
- теперь кешируется.
- Проведена сильная чистка, на ряду с множественными багфиксами адаптера для БД Oracle.
- в Active Record признан устаревшим и переименован в
- в методе нужно использовать методы relation’ов вместо поиска в стиле . Например:
- признан устаревшим в пользу
- сообщения I18n об ошибке для Active Record необходимо изменить с на
- признан устаревшим в пользу
- теперь стал
- и признаны устаревшими в пользу или .
Культура и стандарты
Ruby on Rails — это фреймворк. Зачастую фреймворк не позволяет вам самодеятельность. Конечно же, в Ruby on Rails можно «изобрести свой велосипед» и программировать в любых направлениях, не опираясь на стандарты; но зачастую этого не требуется. Стандарты размещения файлов в проекте, стандарты написания кода в проекте, общие правила программирования в Ruby on Rails сильно структурируют любой проект. За счет этого проект становится читаемым. Вхождение в проект новичков происходит очень быстро. Опыт показывает, что любой новичок в проекте в первый же день работы делает свои первые полезные правки. За счет этого не считается большой проблемой, если разработку проекта изначально вела одна команда программистов, а поддержку проекта или доработку — совершенно другая. Проект на RoR априори понятен любому разработчику.
Немного об установке приложения у хостера.
<code>$>rake rails:freeze:gems</code>
Dr NicGems on Rails
<code>$>gem install gemsonrails</code>
<code>$>gemsonrails Installed gems_on_rails 0.6.4 to ./vendor/plugins/gemsonrails</code>
Gems on Rails
<code>$>rake -T ... rake gems:freeze # Freeze a RubyGem into this Rails application; init.rb will be loaded on startup. rake gems:link # Link a RubyGem into this Rails application; init.rb will be loaded on startup. rake gems:unfreeze # Unfreeze/unlink a RubyGem from this Rails application ...</code>
- – добавляет в код, который загружает гем при загрузке приложения, если гема нет, то приложение не загрузится (удобно узнавать об отсутствии гемов сразу, а не во время работы)
- – делает локальную копию гема, именно эта копия будет использоваться в приложении
- – удаляет локальную копию и код сгенерированный
<code>$>rake gems:freeze GEM=maruku $>rake gems:freeze GEM=redcloth</code>
документациюкнигу о рельсах
Меню это омакасе
Какое решение вы принимаете, когда не знаете что выбрать из меню в ресторане? Что ж, вполне вероятно, что если вы позволите шеф-повару сделать выбор за вас, то он может приятно вас удивить, до того как к вам придет понимание того, что такое «хорошо». Это омакасе. Способ хорошо поесть, который не требует от вас экспертных знаний и к тому же позволяющий не рассчитывать на слепую удачу при выборе.
Для программирования преимущества этой практики заключаются в возможности позволить кому-то другому собрать ваш стек. Это аналогично с теми преимуществами которые мы получаем из Соглашение над конфигурацией, но на более высоком уровне. В то время когда Соглашение над конфигурацией занимается оптимизацией использования индивидуальных структур, омакасе занимается вопросом о том какие структуры существуют и как они взаимосвязаны друг с другом.
Это расходится с традицией, которая подталкивает программиста к тому чтобы принимать индивидуальные решение при выборе доступных инструментов.
Вы наверняка слышали и, скорее всего, кивнули в тот момент, когда кто-то вам сказал «используй лучший инструмент в работе». Это звучит столь элементарно, что не поддается даже обсуждению, но возможность выбрать «лучший инструмент» зависит от фундамента, который позволяет определить «лучше» с полной уверенностью. Это намного сложнее, чем кажется.
Это проблема, подобная ужину в ресторане. Как выбрать из восьми блюд, что ж выбор библиотеки или фреймворка не должно быть работой в одиночку. Цель в обоих случаях — рассмотреть весь вечер или систему.
Таким образом, в RoR мы решили сократить выбор, заменить индивидуальный выбор программиста отдельных инструментов на нечто большее: Лучший набор инструментов для всех. Дивиденды — это легион:
Безопасность кроется в цифрах: когда большая часть людей использует Rails одинаковыми способами по умолчанию, у нас накапливается общий опыт. Это то, что облегчает обучение и помощь новичкам. Это закладывает фундамент для общения. Мы все смотрели одно и то же шоу прошлой ночью в 7, поэтому мы можем поговорить об этом на следующий день
Это способствует более сильному чувству общности.
Люди совершенствуют один и тот же базовый набор инструментов: В Rails в качестве full-stack фреймворка есть много подвижных частей, и то, как они работают вместе, так же важно, как и то, что они делают изолированно. Большая часть проблем в программном обеспечении исходит не от отдельных компонентов, а от их взаимодействия
Когда мы все работаем над облегчением общих проблем от компонентов, которые настроены и падают с ошибкой по разным причинам, у нас возникает меньше проблем.
Замены по-прежнему возможны, но не требуются: хотя Rails — это стек omakase, он все же позволяет вам заменить определенные фреймворки или библиотеки альтернативами. Вам просто это не нужно. Это означает, что вы можете отложить эти решения до тех пор, пока не разработаете четкую персональную палитру “лучших решений”, вместо случайного набора инструментов
Потому что даже самые образованные и опытные программисты, которые приходят и остаются в Rails, вряд ли будут возражать против всех вопросов меню (Если бы они были, они, вероятно, не были бы привязаны к Rails). Итак, они тщательно подбирают альтернативы и затем наслаждаются отдыхом от наставничества делясь стеком с сообществом.
Ни одна парадигма
Существует эмоциональная привязанность при выборе определенной центральной идеи как фундамента вашей архитектуры и следованию ей до логического завершения при разработке приложения. В дисциплине есть чистота, поэтому понятно почему столь многих программистов привлекает такой подход.
В Rails — это не так. Это не один, идеальный крой ткани. Это одеяло. Совокупность многих разных идей и даже парадигм. Многие из них, как правило, противоречат друг другу, если их сравнивать друг с другом и один за другим. Но это не то что мы пытаемся сделать. Это не одно большое соревнование, в котором должен быть объявлен один победитель.
Возьмите шаблоны, с которыми мы создаем представление в нашем Rails-MVC-пироге. По умолчанию все хелперы, которые позволяют нам извлекать код из этих шаблонов, — это просто большой набор функций! Это единое пространство имен. О, потрясение и ужас, это как PHP-суп!
Но я утверждаю, что создатели PHP были правы при выборе этого решения, когда речь заходит о представлении отдельных функций, которые редко нуждаются во взаимодействии, как в случае с абстракцией в шаблонах представлений. И для этой цели единое пространство имен, большой набор методов, является разумным выбором.
Это не означает, что мы иногда не хотим достичь чего-то более объектно-ориентированного при построении представлений. Концепция Presenters, в которой мы заключаем множество методов, которые являются взаимозависимыми друг с другом и нижележащими данными, иногда может быть идеальным противоядием супу методов, привязанных к зависимостям. Но, как правило, это оказывается редким случаем, а не распространенным.
Для сравнения, мы обычно рассматриваем модель в MVC как основной бастион объектно-ориентированного подхода. Нахождение только правильных имен для объектов, увеличение согласованности и снижение связанности — это удовольствие от моделирования предметной области. Это очень отличный слой от представления, поэтому мы используем другой подход.
Но даже здесь мы не подходим к одно парадигматической догме. Проблемы с Rails, специализацией Ruby являются миксины, которые часто используются, чтобы дать отдельным моделям очень широкую площадь поверхности. Это хорошо сочетается с шаблоном Active Record, предоставляя связанным методам прямой доступ к данным и хранилищу, с которыми они взаимодействуют.
Даже сама основа системы Active Record оскорбляет некоторых пуристов. Мы смешиваем логику, необходимую для взаимодействия с базой данных непосредственно с бизнес-областью и логикой. Такое сочетание границ! Да, потому что это оказалось практичным способом обернуть веб-приложение, которое практически всегда имеет связь с базой данных, чтобы сохранить состояние модели домена.
Быть настолько идеологически гибким — это то, что позволяет Rails решать столь широкий круг проблем. Большинство отдельных парадигм очень хорошо работают в определенном фрагменте предметной области, но становятся проблемными при применении вне своей сферы и зоны комфорта. Применяя множество пересекающихся парадигм, мы прикрываем фланги и охраняем тыл. Заключительная структура намного более сильна и более способна, чем любая индивидуальная парадигма позволила бы ей быть.
Теперь стоимость этих полиамурных отношений со многими парадигмами программирования является концептуально накладной. Недостаточно просто знать объектно-ориентированное программирование, чтобы хорошо провести время в работе с Rails. Желательно также хорошо уметь работать с процедурным и функциональным подходом.
Это относится и ко многим подязыкам, а также Rails. Мы не пытаемся оградить вас настолько, чтобы вы научились, скажем, JavaScript для представления или SQL для сложных запросов. По крайней мере, чтобы не достичь пика возможностей.
Путь к облегчению некоторых из этих проблем в обучении заключается в том, чтобы просто упростить начало работы, сделать что-то действительно ценное, прежде чем вы поймете каждый отдельный аспект структуры. По этой причине мы спешим в Hello World. Ваш стол уже приготовлен, и подана закуска.
Мысль заключается в том, что, давая что-то действительно ценное на раннем этапе, мы поощряем практикующих Rails быстро повышать свой уровень. Примите путешествие обучения как радость, а не препятствие.
Оглавление
- Переход на Rails 3.0
- Rails 3 требует Ruby 1.8.7+
- Объект Application в Rails
- заменен на
- Зависимости и
- Процесс перехода
- Создание приложения на Rails 3.0
- Включение гемов
- Жизнь на грани
- Архитектурные изменения
- Перезарядка Railties
- Все компоненты ядра Rails теперь независимы
- Абстракция Active Model
- Абстракция контроллеров
- Интеграция Arel
- Извлечение Mail
- Документация
- Интернационализация
- Railties
- Action Pack
- Абстрактный контроллер
- Action Controller
- Action Dispatch
- Action View
- Active Model
- Абстракция ORM и интерфейс c Action Pack
- Валидации
- Active Record
- Интерфейс запросов
- Усовершенствования
- Патчи и устаревшие методы
- Active Resourсe
- Active Support
- Action Mailers
- О создателях
Action Pack
7.2 Action Controller
- В отныне установлен по умолчанию.
- был признан устаревшим. Теперь вместо него следует обращаться к , а его реализация теперь находится в отдельном файле
- был перемещен в
- теперь позволяет устанавливать зашифрованные значения в хеше cookie:
- теперь позволяет устанавливать постоянные значения в хеше cookie: , которое вызывает исключение в случае, если верификация оказалась безуспешной
- теперь можно передавать или для вызова в блоке . Хеш по прежнему в строю
- был добавлен к контроллерам, упростив тем самым устаревшие блоки
- был добавлен , при помощи которого можно гибко генерировать ответы (responses)
filter_parameter_logging в пользу config.filter_parameters
- Render Options in Rails 3
- Three reasons to love ActionController::Responder
7.3 Action Dispatch
- после сильной чистки и переписывания раутинга, отныне — это над Rails DLS, т.е. по сути он теперь является отдельным небольшим приложением
- роуты, объявленные в приложении теперь находятся в пространстве имен модуля Application. Т.е. теперь вместо:Нужно писать:
- добавлен метод , так что теперь на подходящий (matched) роут можно навесить Rack-приложение
- добавлен метод , давая возможность защищать свои роуты условиями
- добавлен метод , с помощью которого можно можно помещать роуты в пространства имен (к примеру, для различных языков или особых действией). Например, следующий код:вызовет метод по адресу
- добавлен метод , в виде ярлыка к
- в можно передавать необязательный сегмент. Так, в , любой заключенный в скобки текст является необязательный
- роуты могут быть выражены в виде блоков, т.е. теперь к примеру можно писать
- принимающий всё на себя роут для не-REST приложений () был закоментирован
- для роутов убран, а теперь автоматически добавляет «_» в конце переданного значения
- The Rails 3 Router: Rack it Up
- Revamped Routes in Rails 3
- Generic Actions in Rails 3
7.4.3 Другие изменения
- Больше не нужно вызывать для фильтрации HTML — теперь все view генерируются с фильтрацией по умолчанию. Для того чтобы передать нефильтрованую строку, нужнно вызывать .
- Хелперы теперь возвращают разметку HTML5.
- Хелпер теперь достает данные из I18n одним параметром, т.е. сразу вернет переведенный .
- для I18n теперь вызывается как вместо .
- Не нужно больше ставить знак минус в закрывающем теге ERb-шаблона для того, чтобы избежать перевода сроки.
- В ActionView добавлен хелпер .
- Добавлен метод для проверки перед рендерингом, существует ли контент.
- Передав для хелперов формы вы тем самым установите значение поля в вместо использования стандартного значения.
- Передав для хелперов формы аттрибует не будет сгенерирован.
- Передав для хелпера image_tag вы тем самым установите значение поля в вместо использования стандартного значения.
Культ красоты кода
Мы пишем код не только для того, чтобы его понял компьютер и другие программисты, но и чтобы насладиться его лаконичностью и красотой. Эстетически приятный код — это ценность для самого себя и к нему следует стремиться. Это не означает, что красивый код решает другие проблемы, но он должен быть одним из ваших приоритетов.
Итак, что такое красивый код? В Ruby зачастую это пересечение нативных Ruby методов и всей мощи DSL. Это незаметная грань, но все же стоит попробовать найти золотую середину.
Вот простой пример из Active Record:
Это похоже на DSL, но на самом деле это просто определение класса с тремя вызовами методов класса, которые принимают символы и параметры. В этом нет ничего не обычного. Это читаемо. Это просто. Это дает большое количество гибкости из нескольких определений.
Часть красоты данного примера заключается в том, что это соответствует предыдущим принципам, таким как Конвенция над конфигурацией. Когда мы вызываем belongs_to :account, то предполагаем, что внешний ключ называется account_id и что он находится в таблице projects. Когда нам нужно определить class_name Person для ассоциации participants, нам требуется определить только имя класса. Из этого мы вновь получим внешние ключи и другие точки конфигурации.
Вот еще один пример с миграцией базы данных:
В этом и заключается сила фреймворка. Программист объявляет класс в соответствии с определенным соглашением, например, подкласс ActiveRecord::Migration, который реализует метод #change и фреймворк выполяет все связанные с этим операции и знает, что это метод вызова.
Это дает возможность писать меньше кода. В случае с миграциями это не только вызов rails db:migrate, чтобы обновить состояние базы данных, для добавления новой таблицы, но и позволяет в случае необходимости удалить ее. Это сильно отличается от того, как программист делает все это и объединяет библиотеки, которые вызывают сами себя.
Иногда красивый код имеет более короткую запись. Речь не о том, чтобы сделать что-то как можно короче или мощнее, а о следование концепции соглашения.
Эти два условия делают одно и тоже:
Концепция и основное внимание несколько отличаются. В первом условии основное внимание уделяется коллекции
Это наш субъект. Во втором условии субъектом явно является person. Между двумя этими условиями не так много различий, но я утверждаю, что второе более красивое и заставит меня улыбнуться, когда будет использоваться в месте, где это условие касается person.
