Fri 16 Feb 2007
We are on Rails!
Posted by Alex Lebedev under программирование, ruby, rails
Некоторое время назад нами был начат проект по разработке веб-приложения для специфических нужд нашего заказчика. Первая версия готова к сдаче в эксплуатацию. Проект был сделан на Ruby on Rails силами одного человека (меня) в течение месяца. Хочу поделиться первыми впечатлениями от реального использования фреймворка.
Что такое Ruby on Rails
Ruby on Rails — это современный высокоуровневый фреймворк веб-разработки. Создатели утверждают, что Ruby on Rails позволит в разы повысить продуктивность веб-разработчиков по сравнению с предыдущими популярными технологиями, такими как PHP. Версия 1.0 вышла в прошлом году и с тех пор Ruby on Rails быстрыми темпами набирает популярность.
В целом, при работе с Rails возникает ощущение, что попал в светлое завтра веб-разработки. На вещи, которые делаешь в первый раз, времени уходит столько же, сколько на реализацию того же самого в десятый раз на том, с чем я работал раньше. Начиная со второго раза – в два-три раза меньше. Сравниваю, в первую очередь с PHP, ASP и ASP.NET, с которыми я более-менее серьезно работал в прошлом, и с Django, знакомым по паре микроскопических проектов, сделанных для собственного удовольствия.
Сам по себе Ruby тоже очень хорош. Пока не могу понять, нравится ли он мне больше, чем Python… Но то, что больше всего остального — совершенно точно.
5 самых приятных моментов Ruby on Rails
Schema Migration. Как правило, одной из основных проблем разработки программных продуктов является сложность внесения изменений в структуры базы данных. В результате возникает желание спроектировать всю структуру заранее, что плохо согласуется с итеративной разработкой. Разработанная заранее структура часто не полностью соответствует логике приложения. Кроме того, не всегда понятно в каком виде хранить структуру данных. В единственном экземпляре на тестовом сервере? Класть дамп БД в систему управления версиями?
Rails помогает решить все эти проблемы с помощью входящих в него функций эволюционного преобразования структуры БД (Schema Migration). Вы описываете исходную структуру БД, а затем описываете каждое изменение в виде так называемой «миграции», описывающей операции по обновлению структуры БД до следующей версии. В миграциях легко описываются как стандартные, так и весьма нетривиальные на некоторых платформах преобразования (переименование таблиц и полей). Rails хранит в базе версию ее структуры, что позволяет надежным и предсказуемым образом обновить любую БД до последней версии. Гораздо проще использовать миграции, чем пользоваться дампом тестовой БД и потом мучительно пытаться обновить устаревшую БД заказчика, не потеряв по дороге данные. Кроме того, миграции позволяют вернуть структуру БД к предыдущей версии, что очень полезно, когда в установленной у заказчика новой версии обнаружилась критическая ошибка. Имея возможность откатить структуру БД к более старой версии, вы можете спокойно вернуть все приложение к последней стабильной версии и без суеты начать исправлять ошибку. Куда безопаснее, чем пытаться героическими темпами исправить проблему прямо на сервере заказчика.
Rake. Также в состав Rails входит Rake (инструмент сборки, аналогичный Make) и комплект стандартных задач к нему. В результате вы, как минимум, сэкономите за время написания и тестирования приложения немало времени на выполнении стандартных операций — очистке логов и временных файлов, обновлении структуры БД, запуске тестов и т.д. Если же вы знаете, как пользоваться подобными инструментами сборки, то вы получаете мощную базу для дальнейшей кастомизации, экономя при этом кучу времени на написание того же самого с нуля. В дополнение к Rake существует Capistrano — утилита, предназначенная для выполнения задач на нескольких серверах, позволяющая существенно упростить развертывание вашего приложения.
Convention over Configuration. Этот принцип архитектуры Rails можно перевести как «соглашения вместо настроек», а его использование призвано свести к минимуму количество стандартного кода, которое вы пишете. Фактически, речь идет об очень продуманной системе значений по умолчанию. Речь идет не только о значениях по умолчанию в методах стандартной библиотеки. Например, стандартно названные «куски» вашего приложения будут автоматически связываться друг с другом без вашего участия — класс данных
Workбудет по умолчанию считать себя представляющим данные таблицыworksи т.д. Можете попрощаться с шаблонным кодом инициализации и списком импортов на треть страницы.Поддержка автоматизированного тестирования. Ruby on Rails делает все возможное для того, чтобы писать автоматизированные тесты для вашего приложения было как можно проще. Режим тестирования позаботится о том, чтобы отправленные в тестах письма никуда не ушли, чтобы тестовые данные никак не соприкасались с рабочими, а изменения в БД, сделанные одним тестом, не влияли на следующий. Rails включает библиотеки для поддержки блочного, функционального, интеграционного и нагрузочного тестирования
Красивые URL’ы. Rails четко отделяет URL’ы от имен файлов, названий методов и прочих сугубо внутренних деталей вашего приложения. При этом вместо
sites/view.php?id=245вы получаете/sites/245и для этого не приходится копаться в .htaccess-файлах на каждой машине, где оно будет стоять. Синтаксис схемы URL’ов гораздо понятнее, чем синтаксис настроек mod_rewrite и к тому же избавляет вас от предположения, что в качестве веб-сервера обязательно будет использоваться Apache. Дополнительный бонус — функция формирования ссылок использует для формирования URL’ов имена ваших классов и методов. В результате вы можете перенастроить схему URL’ов не меняя при этом ни строки кода в вашем приложении – и все будет работать.
Здравствуй, грабли!
К сожалению, молодость фреймворка ведет к недостаточной проработанности некоторых аспектов. Перечислю наиболее серьезные проблемы, с которыми я столкнулся при реализации небольшого проекта, упомянутого в начале статьи.
ERb, движок шаблонов, используемый в Ruby on Rails, ведет к появлению безумной мешанины кода и HTML, так характерной для PHP-программ сомнительного качества. Вот кусок одного из моих шаблонов:
<td class='site_description'><%= truncate(site.human_description, 60) %></td> <td class='site_edit'><%= link_to 'Edit', edit_site_url(:id => site.id) %></td> <td> <% if site.works.empty? and site.estimates.empty? %> <%= link_to 'Add estimate', :controller => 'estimates', :action => 'new', :site_id => site %> <% else %> <%= link_to 'Add work', :controller => 'works', :action => 'new', :site_id => site %> <% end %> </td>Не очень эстетично, правда? А ведь это стандарт… Есть как минимум одна неплохая альтернативная реализация, но версия 1.0 вышла только месяц назад, и, кто знает, сколько еще пройдет времени до того, как она получит более-менее заметное распространение.
Валидация данных как будто гвоздями прибита к моделям. Так хорошо интегрирована, что захочешь — не отдерешь. Отличное решение, если вам надо работать с данными, хранимыми в БД. Так что пока идет реализация функций редактирования данных — все танцуют. Легко и изящно решены и такие относительно распространенные вещи как проверка согласия с user agreement’ом. Потом настает очередь настраиваемых отчетов и продвинутого поиска. И, сюрприз! — вы в жопе… Стандартная валидация не работает. То есть совсем. Потому что модели данных, на которую можно завязать поля вашей формы продвинутого поиска не существует в природе. Не сомневаюсь, что есть грязный трюк, с помощью которого можно обойти эту проблему, но найти его за разумное время мне не удалось. Два балла.
Совершенно ужасны стандартные Date и Time control’ы. Date control выглядит вот так:

Time control ничем не лучше. Кроме того, у этих control’ов бывают проблемы с валидацией. А если использовать их без привязки к ActiveRecord, то придется вручную собирать дату или время из отдельных «кусочков», полученных в виде параметров. Стыд и позор! Сравните с тем, как это выглядит в Django:
.Без комментариев.
Урезанная поддержка БД по умолчанию. Настоящим ковбоям не нужны удаленные ключи! Мало того, что удаленные ключи отключены по умолчанию, библиотека миграций еще и не включает в себя функций по их созданию. Придется писать свои. Так же по никто и не подумает автоматически создать для вас индекс по полю удаленного ключа. Так что тем из нас, кто использует для production что-то посерьезнее SQLite, придется совершить несколько больше ручных манипуляций, чем предполагает дух Ruby on Rails.
В принципе, если вы редактируете данные только через ваше приложение, написанное на Ruby on Rails, то это не особенно серьезная проблема — Rails и сам неплохо справляется с поддержанием целостности данных. Но если с базой взаимодействуют другие приложения или вы часто меняете данные непосредственно через SQL-консоль, то отсутствие удаленных ключей может оказаться весьма неприятным сюрпризом.
Я столкнулся с мистическими багами ruby 1.8.5 на FreeBSD 5.4. В ряде случаев Ruby падает, выдавая Core Dump. В частности, не работает Rake, проваливаются несколько тестов в плагине acts_as_authenticated и где-то раз в сутки (update: уже каждые пять минут) падает mongrel. Неприятно. Проблема, скорее всего в железе или операционке, “но неприятных осадок остался”. Как решится — напишу.
На этом список неприятностей заканчивается. Для меня ничего из перечисленного даже близко не стоит с ViewState и необходимостью использовать IIS (ASP.NET) или отсутствием namespace’ов в языке (PHP).
Хочу подчеркнуть что «проблемы» Rails, как правило, заключаются в том, что фреймворк устанавливает у разработчика высокие ожидания относительно уровня абстракции. Когда из-за закона дырявых абстракций некоторые вещи приходится реализовывать на более низком уровне, сравнимом с тем, который предлагает, например, PHP — разработчик ощущает разочарование. Так что перечисленные проблемы вовсе не являются основанием не использовать Rails, это скорее список возможностей, упущенных создателями. Учитывая, что текущей версией является все лишь 1.2, возможностей улучшить ситуацию будет предостаточно. И даже с учетом всех этих проблем скорость и удобство создания нового веб-приложения на Ruby on Rails в разы превосходит таковые на старых платформах.
Выводы
Настоятельно рекомендую хотя бы попробовать Ruby on Rails. Даже если в ближайшее время вы не сможете использовать Rails в своей непосредственной работе, то его все равно стоит изучить. Почувствовав стиль и принципы Ruby on Rails, вы поймете к чему надо стремиться, а это поможет вам при разработке веб-приложений на любом языке и любой платформе.
Материалы по теме
RubyOnRails.com. Домашняя страница проекта.
RubyOnRails.ru. Она же на русском.
Ruby on Rails Tutorial, Revisited (part 1). Хороший Tutorial, с лихвой окупающий пару часов, которые надо потратить на его вдумчивое освоение. Состоит из двух частей, ссылка на вторую часть есть где-то в конце первой, поэтому не буду ее здесь приводить.
Отличная шпаргалка по Ruby on Rails. Кратко описывает все самые важные вещи на одной (пусть и большой) странице. Открыта у меня постоянно и используется не реже чем Rails API.
Русскоязычная дискуссионная группа о Ruby on Rails. Основное место живого общения о Ruby on Rails на русском языке. 20% тем хороши, информативны и полезны для разработчиков самого разного профессионального уровня. Ну а 80% тем, как и в любом другом месте — полный мусор.
46 Responses to “ We are on Rails! ”
Comments:
Leave a Reply
Trackbacks & Pingbacks:
-
Pingback from HTML Blog » They are on Rails
February 23rd, 2007 at 10:14[…] RSS- Rails . Rails “”. , “”. Rails . […]
-
Pingback from Martian eyrie :: We are on Rails! » Ruby on Rails - история реального проекта :: February :: 2007
February 28th, 2007 at 12:34[…] We are on Rails! » Outsourcing stories "Некоторое время назад нами был начат проект по разработке веб-приложения для специфических нужд нашего заказчика. Первая версия готова к сдаче в эксплуатацию. Проект был сделан на Ruby on Rails силами одного человека (меня) в течение месяца. Хочу поделиться первыми впечатлениями от реального использования фреймворка. […]

February 17th, 2007 at 01:28
Добро пожаловать!
Уточнения:
Не irb, а ERb (Embedded Ruby). Он, в принципе не плох. HAML пробовал, он вполне готов к активному использованию. Он минималистичен и самодостаточен.
Трюк есть: http://made-of-stone.blogspot.com/2006/11/active-record-validations-and.html (но можно и красивее)
Не путайте scaffold и готовый интерфейс. В Рельсах такая админка, как в Джанго выполнена отдельным плагином: http://code.trebex.net/auto-admin/
Scaffold нужен для обучения: быстро сделать модель бизнес-процессов и “пощелкать” в простеньком интерфейсе, который можно будет легко поменять.
Рельсы используют БД максимально просто, чтобы иметь полный контроль над данными - отсюда получается и относительная независимость от БД. Работа внешних ключей (aka Foreign keys) осуществляется самими рельсами. См. обоснование здесь: http://www.loudthinking.com/arc/000516.html и здесь: http://lesscode.org/2005/09/29/should-database-manage-the-meaning/
На счет багов не подскажу - с таким не сталкивался.
Что же касается дырявых абстракций, то на мое удивление Руби позволяет обходить их с неожиданной элегантностью. Смотрите, к примеру, эпопею с поддержкой юникода и патч для него: http://live.julik.nl/unicode
February 17th, 2007 at 01:39
Точно, irb — это интерактивный интерпретатор
Уже исправил.
February 17th, 2007 at 01:39
привет!
Это перевод или авторская заметка? Мне кажется вместо термина “удаленные ключи” нужно использовать “внешние ключи”.
Что касается смешивания кода html и ruby - то это самое главное, что останавливает меня от экспериментов с RoR. Честно говоря, сильно удивляюсь появлению фреймворков, в которых вопросы разделения логики-представления не проработаны.
Почему бы не использовать для этого XSLT?
February 17th, 2007 at 01:51
На тему валидации вне ActiveRecord’а. Народ уже 2 года назад задумался об этом:
http://one.textdrive.com/pipermail/rails/2004-December/001086.html
Видимо, формы продвинутого поиска принято фильтровать молча (что спросили, то и ищем, а мусор - выкинем) или маппить в рекорды. Последнее удобно, если позднее придет в голову запросы/отчеты сохранять в базу.
И в дополнение к п. 4: предполагается, что данные управляются не из SQL-консоли, а irb (interactive ruby): script/console.
Что касается других приложений, использующих ту же БД, то проблемы Foreign keys следует отнести к проблемам использования этих приложений. Рельсы преполагают построение БД “под себя” и выдвигают свои naming convensions для имен столбцов и таблиц. Если стороннее приложение придется конфигурировать под эти соглашения, мы же не назовем это проблемами в рельсах? Как говорится, this is not a bug, this is a feature
February 17th, 2007 at 02:01
2 b52 и Алекс:
На мероприятии Snakes and Rubies (http://video.google.com/videoplay?docid=2939556954580527226&q=snakes+and+rubies) DHH объяснил, почему он не видит проблемы в использовании Руби в шаблонах.
Коротко мысль звучит так: так или иначе, в шаблонах встречается логика (показать или спрятать ссылку, выделить или не выделить кнопку и т.п.), так что от “логики” никуда не деться. Другое дело - бизнес-логика, вот это действительно должно быть на своем месте (в моделях и контроллерах).
См. также http://spectator.ru/technology/php/easy_templates
Насчет XSLT - это возможно, т.к. вы можете подключать свои движки шаблонов (как это сделано с HAML). Вообще-же, в рельсах принято максимально использовать Руби. Так, для генерации RSS и других XML-ек используют очень наглядный Builder:
http://snippets.dzone.com/tags/ruby/blinksale
February 17th, 2007 at 02:10
b52: “Честно говоря, сильно удивляюсь появлению фреймворков, в которых вопросы разделения логики-представления не проработаны.”
Вы не правы. В РоР используется MVC в одном из лучших своих проявлений. Спрятать бизнес-логику от представления настолько просто, что даже по ошибке нагородить плохого кода будет нелегко. И потом, там даже есть “Ресурсы”, которые позволяют настолько разделить пресловутую “логику” и представление, что добавление новых форматов выдачи (rss, xml, js, ad infinitum) - дело нескольких строк. См. http://www.loudthinking.com/arc/000593.html
Речь идет вот о чем:
class PeopleController
ml=>@people.to_xml }
def index
@people = Person.find(:all)
respond_to do |format|
format.xml { render
format.html # just renders index.rhtml
format.js # just renders index.rjs
end
end
end
February 17th, 2007 at 03:06
Я не против простой логики в шаблонах. Моя претензия к Rails состоит в том, что шаблоны выглядят уродливо и несколько громоздко. В качестве примера шаблонов от которых не тошнит рекомендую посмотреть на уже упомянутый HAML или шаблонный движок Django.
Аргументы автора статьи про простые шаблоны в PHP сводятся к тому что нет смысла использовать отдельных движок шаблонов, когда можно просто использовать смесь PHP и HTML — главное разделять шаблоны и бизнес-логику.
Основное возражение против этого подхода все то же — получающиеся в результате шаблоны весьма уродливы.
Вообще тема шаблонов весьма интересна и заслуживает отдельной статьи. Ждите в ближайшие недели…
February 17th, 2007 at 03:17
Я хорошо знаю SQL и
script/consoleкак-то не тянет для меня на полноценную замену. Чтобы сделать что-то нестандартное приходится изворачиваться.С точки зрения производительности, проверка целостности связей вне БД — очень сомнительная идея.
Если честно, мне наплевать к проблемам какого приложения относится использование внешних ключей. Результат все равно один — приходится тратить свои усилия там, где фреймворк мог бы справиться и сам.
February 17th, 2007 at 03:23
Не понял к чему это. Ответ на жалобы относительно стандартных DateControl\’ов?
Scaffold\’ы и автоматическая генерация админского интерфейса тут не причем. Просто я считаю, что уважающий себя фреймворк должен включать набор стандартных виджетов, которыми можно пользоваться без содрогания.
Почему Rails позволяет создавать нормально выглядящие текстовые поля, но при этом предоставляет такие отвратные поля для ввода даты / времени?
February 17th, 2007 at 08:50
Чота какие-то детские претензии..
Касаемо шаблонов - не нравится ERB, юзайте Markaby, Liquid (фанаты PHP/Smarty в этом месте должны пищать от восторга), Hobo с его DRYML - тоже интересная заслуживающая внимание концепция для работы с шаблонами. Ну про HAML уже говорили здесь..
Валидация гвоздями прибита к моделям? Да, так и есть. Плагин ActiveForm реализует валидацию без привязки к ActiveRecord.
Поддержку Foreign Keys решили писать свою? А надо ли?
Используе Google, все уже сделано до вас..
February 17th, 2007 at 08:58
Смешно.. Если вы так считаете, то лучше вам действительно использовать XSLT..
February 17th, 2007 at 01:03
Очень позабавила фраза “избавляет вас от предположения, что в качестве веб-сервера обязательно будет использоваться Apache”.
Под IIS и руби и рельсы встают исключитально с шаманскими плясками и куче дополнительных программ.
С виндовым апачем не сильно лучше. (во всяком случае с второй версией).
Может оно под линуксом или фрей будет лучше бегать, но на мой взгляд - более не удачный для инсталяции фреймворк еще надо поискать.
February 17th, 2007 at 01:46
To: rancorous
К вашему сведению, кроме Apache существуют как минимум два первоклассных веб-сервера для Ruby on Rails: mongrel и lighttpd. Кроме них есть всякая экзотика, типа ngix, которая может стать неожиданно популярной.
Про Rails на винде сказать ничего не могу — к счастью, нет необходимости пробовать.
February 17th, 2007 at 11:39
для Ivan Nemytchenko:
не вижу ничего смешного в предложении использовать XSLT. Если вы работаете над проектами один - то возможно вас устроит
синтаксис шаблонов RoR.
В нашей же компании выполняются проекты на .NET, PHP, Perl. Соответственно программисты программируют на своих языках, а
XSLT-верстальщики могут легко переключаться между проектами, т.к. синтаксис XSLT везде одинаков.
В текущей реализации RoR вижу только два варианта:
1. или версткой должны заниматься программисты
2. или верстальщики должны изучить синтаксис шаблонов RoR
ни 1-й ни 2-й вариант не устраивают (попробуйте поискать на job.ru программистов с опытом разработки сайтов на RoR)
Вообщем смысл моего поста не в том, чтобы бы поспорить, а в том, чтобы узнать, использовал ли кто-нибудь RoR+XSLT.
Решение с движками типа (HAML/Django/Markaby) - не подходят, т.к. потребуют переобучения верстальщиков.
February 18th, 2007 at 12:03
Это только так кажется. Всё зависит от задачи. Когда данные делятся по разным серверам, внешние ключи просто невозможны. Возможно, создатели хотели использовать RoR не только на домашних страничках с посещаемостью 100 человек в месяц.
February 18th, 2007 at 12:12
К сожалению поигрался с рельсами совсем немного… Мне не понравилось смешение ugly кода с html и то, что рельсы генерят кучу всякого хлама…
Есть сомнения в производительности фреймворка…
Вопрос к знатокам: может кто-нибудь более-менее объективно сравнить рельсы с fusebox’ом или model glue (оба coldfusion)
?
February 18th, 2007 at 02:41
Давно пытаюсь начать знакомиться с «Рельсами», но пока не было времене. Запишу в туду-лист.
February 18th, 2007 at 02:52
2 Alex: в Рельсах нет “виджетов”. Вообще. Скаффолд - это черновик. Там дэйттаймы могли быть и простыми текстовыми полями, ничего бы не изменилось.
Ivan Nemytchenko дело говорит.
Общее впечатление, что комментаторы слишком буквально понимают фразу full-stack framework. Rails, да и Ruby - это штуки, предназначенные для расширения.
Нормальный сайт делается не только на рельсах, но и на наборе плагинов. Соответственно, шаблоны не обязаны быть красивыми по умолчанию. Не нравится - ставьте плагин (делов-то на минуту). Валидация не слишком гибкая, нужны внешние ключи, нужен версионный контроль, или базовая аутентификация? Ставьте плагин.
После этого стандартные файлы проекта уже не будут казаться “кучей всякого хлама”
А причина такой модульности, как нетрудно догадаться, в том, что у каждого из нас свои представления о красоте и простоте. И уж тем более, о том, “как делать правильно”.
February 18th, 2007 at 02:58
Насчет виджетов я плохо ответил. Извините.
Я имел в виду, что text_field - это алиас ХТМЛ-ному тегу, а не “рельсовский виджет”.
datetime_select - хэлпер для скаффолда, не более того.
Реальные виджеты - это либо стандартные теги ХТМЛ, либо то, что вы сами придумаете.
February 18th, 2007 at 03:26
To: Oleg Andreev
Олег, большое спасибо вам за конструктивные о содержательные комментарии!
Про внешние ключи, виджеты и плагины вообще:
Доступность функциональности через плагин это замечательно. Тем не менее, это не эквивалентно вхождению этой функциональности в ядро, вы согласны?
Многие приложения поставляются с набором стандартных плагинов, по умолчанию выключенных. Для того чтобы добавить часто используемую, но не входящую в ядро функциональность, нужно все лишь включить плагин. В качестве примеров реализации такого подхода можно привести Django и Wordpress. Rails поставляется без плагинов. Это значит что плагин надо найти, убедиться в его зрелости и надежности, поставить и только после этого можно использовать. Это занимает достаточно много времени, и именно в этом причина недовольства тем, что в Rails не входит функция X. То есть я недоволен не тем, что в ядре Rails нет поддержки внешних ключей, а тем, что получить в приложении поддержку внешних ключей относительно долго.
February 18th, 2007 at 02:23
А можно посмотреть примеры ваших проектов на ASP.NET?
Почему-то у меня сложилось впечатление, что вы много о нем не знаете.
А вообще в первый раз слышу про Rails и впервые заинтересовало что-то кроме ASP.NET(вообще как-то и питон заинтересовал, но руки как-то не доходят).
Но вообще на деле конечно фигня все это. Ибо заказчику пофиг на чем сделан сайт, а у всех кто достаточно долга сайты делает уже есть свои способы-методы делать все быстро и без гемора:)
February 18th, 2007 at 03:06
2b52
“Смешно” было про “вопросы разделения логики-представления не проработаны”..
Против XSLT ничего не имею, тем более раз у вас такие матерые верстальщики, что сами XSLT-обработчики пишут.. (Может все-таки XML?)
На руби есть замечательные и гораздо более элегантные, нежели XSLT инструменты для обработки XML: ReXML, Hpricot, еще что-то было точно..
И я не вижу проблемы приделать к рельсам свой обработчик своих XML-шаблонов хоть на руби, хоть с помощью XSLT..
February 18th, 2007 at 03:12
2Alex Lebedev
А я недоволен, что рельсы не читают мои мысли и не предоставляют мне необходимый функционал сами.
Я думаю, Алекс, на этот коммент про неудобство у тебя ушло больше времени, чем на поиск нужного плагина.
February 19th, 2007 at 12:14
Насчет плагинов: согласно нынешней линии партии, все патчи в рельсам рекомендуется делать в виде плагинов. Т.е. обкатанный и нужный всем плагин будет включен в core, не как плагин, а как встроенная функциональность. Так, например, случилось с поддержкой юникода.
Если же плагин нужен не всем, или не всегда, то пусть остается плагином.
Насчет “убедиться в его зрелости и надежности”. Это очень просто: вы ставите плагин и смотрите, есть ли у него юнит-тесты. Если нет, то плагин незрелый. Если есть, но не работают, то незрелый. Если все есть и работает, но чего-то нехватает лично вам, то можно потвикать код плагина. Последнее будет быстрее и элегантнее, чем писать самому с нуля.
Это же open source, “собери самолет сам”
И, потом, гугл до сих пор очень быстро находил то, что мне нужно.
См. также http://www.agilewebdevelopment.com/plugins/category/2
February 19th, 2007 at 09:52
To: Oleg Andreev
Да, мои выводы совпадают с вашими. Ищем в google и на agilewebdevelopment, зрелость оцениваем по юнит-тестам и coverage.
February 20th, 2007 at 04:16
Разве что вы работаете в банке, который купит систему многофакторной аутентификации у моего предыдущего работодателя
Я и не утверждал что знаю. Кусок на ASP.NET писал другой человек, мой опыт ограничивается планированием, ревью и эпизодическим участием в исправлении проблем. Не так уж много, но представление о сильных и слабых местах технологии у меня есть.
February 23rd, 2007 at 10:10
Если нужно делать валидацию не ActiveRecord-объектов, рекоммендую присмотреться к ActiveSpec. Позволяет не только делать валидацию любых объектов, но и менять правила валидации “по требованию”, в зависимости от контекста.
Сам плагин:
http://rubyforge.org/projects/activespec/
Как использовать:
http://www.lukeredpath.co.uk/2006/9/28/introduction-to-activespec
February 23rd, 2007 at 12:36
Про ActiveSpec:
Уже использую ActiveForm. В целом, доволен.
Пятиминутный обзор ActiveForm:
Версия 0.1
Юнит-тестов нет.
Открываем README, читаем
Это серьезная проблема. Насколько я понимаю, придется делать альтернативную реализацию
error_messages_for().Итого: плагин к реальному использованию пока не готов.
Кстати, тестов нет и у ActiveForm
February 23rd, 2007 at 03:35
Собственно, я ActiveSpec сам не использую. Просто вспомнил что такой есть, решил поделиться. Может кому пригодится.
February 24th, 2007 at 10:22
А между прочим, многие считают подобный способ самым лучшим шаблонизатором.
February 24th, 2007 at 03:09
To: Денис Лозко
Ссылка, к сожалению, не работает.
February 25th, 2007 at 12:42
Нет. пока не будет хорошей xslt поддержки руби будет просто модным языком.
Стандарты они и в Африке стандарты
February 27th, 2007 at 03:13
В рельсах филосфия такая, если вам нарится что они из себя представляют вы понимаете принимете все их ограничения (требования к структуре бд и прочее) и вам это нравится, то можно и использовать.
Не нравится, используете другое / пишете свое.
February 27th, 2007 at 06:53
Привет.
Я пришёл по ссылке с http://community.livejournal.com/ru_webdev/1809499.html
С удовольствием прочёл почти все записи блога. Спасибо, обязательно загляну ещё.
March 7th, 2007 at 12:40
Спасибо за то, что поделились опытом.
March 7th, 2007 at 05:01
Спасибо за обзор, насчет “Урезанная поддержка БД по умолчанию”, можно посмотреть в сторону iBatis (это Java ORB, конкурирующий с Hibernate), есть реализация на Ruby - RBatis - http://ibatis.apache.org/docs/ruby/
)
(там можно в качестве ключей использовать String
С приветом из ror2ru.
March 7th, 2007 at 05:03
Конечно же Java ORM, но точнее они его называют как iBATIS Data Mapper framework
March 24th, 2007 at 11:00
Господа подскажите нубу некривой способ русифицировать рельсовые поделки и в какой кодировке все должно быть? utf-8 ???????
March 24th, 2007 at 02:38
Господин нуб, вам нужен вот этот топик на ror2ru.
Собственно, дальнейшие технические вопросы имеет смысл задать там, в списке рассылки. Народ там очень дружественный и интеллегентный, так что с помощью доброго слова можно найти ответы практически на любой вопрос.
March 25th, 2007 at 02:41
Блин, каюсь: опять начал защищать ASP.NET
June 7th, 2007 at 12:40
Долгое время использовал LAMP. По этому поводу есть серьезные наработки. Такая мысль - какие могут возникнуть проблемы при миграции (код написан по канонам дизайн-паттернс, mvc as standard)? Ruby+Рельсы очень уж понравились при первом рассмотрении…
June 8th, 2007 at 02:10
Здрасте. Скажите пожалуста как сделать проект руским=)?(чтоб русские шрифты не квадратиками отображались=)
July 18th, 2008 at 02:21
Аргументы автора статьи про простые шаблоны в PHP сводятся к тому что нет смысла использовать отдельных движок шаблонов, когда можно просто использовать смесь PHP и HTML — главное разделять шаблоны и бизнес-логику.
March 22nd, 2009 at 02:15
Поддержка date и time control страдает. Но как и многие вещи в рельсах это лечиться установкой плагинов или гемов.Например,в случае с контролами
http://electronicholas.com/calendar
Отрадно то что за прошедшие 2 года практически все описанные выше проблемы были устранены в ядре/либо опять же плагины =)
Грядущее слияние с MERB принесет еще очень много чего полезного и интерестного.