апреля 27, 2012 | Published in CMS, QuasarLog
Весточка с передовой.
О QuasarLog’е
В этой рубрике я буду писать о прогрессе в разработке Quasar и некоторых интересных вещах, которые вот уже реально могут быть полезны читателям RubyDev. Например в этом посте мы рассмотрим код FactoryGirl фабрики для модели User из Quasar. Об этом я уже писал в нашей группе во вконтакте. Если хотите быть в курсе развития проекта и RubyDev, то вот вам:
апреля 26, 2012 | Published in BDD, RSpec, Примат - советчик, Тестирование
Практикуйте BDD, не будьте похожи на подавляющее большинство PHP программистов
Почему это?!
BDD позволяет хорошо продумать архитектуру вашего приложения, продумать, как будет реализован функционал, отсечь лишний функционал и заранее подготовить тесты.
Ранее я только игрался со спецификациями BDD и использовать их в реальной работе не желал. Я изучил поверхностно работу с RSpec просто потому, что «Rspec необходимо знать», а это убеждения возникло у меня из-за частого упоминания RSpec в вакансиях на различных сайтах — агрегаторах вакансий Ruby/Rails программистов. На практике, до недавнего времени я избегал использования RSpec и мне казалось, что очень ловкое шимпанзе, которое успешно избегает всех этих заморочек со спецификациями. Мне казалось, что работая в одиночку можно спокойно обойтись без BDD, и что BDD только забирает время, которое можно потратить на написание кода самого приложения, а не бесполезных с функциональной точки зрения спецификаций. Чуть позже я нашел работу Rails программиста в одной компании, где спецификации также не пишут, а работа по тестирования взгромождена на широкие плечи титанов — тестировщиков. Здесь мне тоже удалось успешно избежать необходимости писать спецификации.
Когда же я начал работать над Quasar CMS то уже было некоторое чувство внутри, что я делаю что-то не так, что нужно все хорошо продумать, но привычка делать, а потом думать привела к тому, что спецификациями покрыто не более 2% кода Quasar CMS и потому я решил заняться написанием спеков ко всему коду, что будет готов на момент 31 мая — так я решил отпраздновать свой день рождения. Это не совсем правильно покрывать спеками уже написанный код, но это лучше, чем когда их совсем нет.
Помимо Quasar CMS я начал еще один свой сверхсекретный мега стартап, который должен сделать меня миллиардером, ну или хотя бы мультимиллионером, а в худшем случае, я просто еще раз повторю имена методов в Rails и, возможно, познакомлюсь с парочкой новых симпатичных Gem’ов. Этот новый супер стартап я начал как раз со спецификаций.
Честно сказать писать спецификации трудно. Трудно не потому, что спецификации — это что-то сложное, а потому, что необходимо много думать, по 7 раз все отмерять и только по разу все отрезать. Кроме того, поскольку опыта в написании BDD спецификаций у меня крайне мало, возникает множество моментов, когда необходимо заглянуть в документацию, StackOverflow или пробежаться по блогам из закладок с метками «RSpec, BDD, …». Разумеется такие упражнения в google-fu приносят свои плоды и откладывают в мозг крупицы знания и понимания сути BDD и его инструментария. Ссылаясь на свой гипертрофированный коэффициент лени и темпы с которыми я осваиваю BDD могу сказать, что на то, чтобы освоить BDD практики и инструментарий в объеме достаточном для автономной работы, то есть без использования Goggle каждые 5 минут, необходимо потратить времени ок. месяца.
О чем это я? Ах да, BDD — это сложно, но это сложно должно превратиться в легко через 1-2 месяца вашего изучения предмета. BDD — это практики, которые действительно необходимы. Поверьте мне как примату, который долго сопротивлялся необходимости использования BDD в работе.
P.S. У PHP разработчиков действительно туго с тестами и спецификациями. В подтверждение тому можете поискать на Хабре соотв. опрос о том, кто использует BDD/TDD.
апреля 22, 2012 | Published in Примат - советчик
Primate say: «Если в приложении должны быть пользователи — начинайте разработку приложения именно с пользователей!»
Не раз сталкивался с разработкой приложений, в которых имелась модель User и регистрация пользователей. То есть это были не закрытые приложения с одним или несколькими администраторами, а приложения в которых могут регистрироваться различные пользователи, приложения, в которых у пользователей есть роли и права. Как правило, я всегда начинал работу над тем, что называется основным функционалом приложения, а пользователей пытался добавить где-то в средине процесса разработки. У меня всегда были сомнения по поводу правильности такого подхода, но привычка не давала мне возможности пересмотреть подход к разработке.
Относительно недавно изучая несколько различных проектов, в которых имелась более-менее аналогичная модель User я заметил, что разработка части приложения отвечающей за пользователей происходила в самом начале, а остальной функционал снежным комом наворачивался поверх пользователей. Попробовав этот подход в недавнем своем проекте aka стартапе я убедился, что такой подход является более эффективным. Построение приложения вокруг пользовательской модели является более удобным и правильным.
Поскольку все дейсвия в приложении выполняются не сами по себе, а от имени пользователя, то вполне логично, что сначала должен быть Большой Взрыв пользователь, а затем уже перечень его возможностей. В коде, где пользователям уделена центральная роль у вас значительно меньше вероятность запутаться с распределением привилегий, при этом объявление прав на выполнение определенного действия должно предшествовать собственно реализации самого действия. Создание пользователей раньше остального функционала больше соответствует BDD и облегчает разработку по такому принципу; в случае, когда User создается после некоторого набора функций приложения, у вас скорее всего возникнет необходимость переписывать спецификации для этих функций.
апреля 21, 2012 | Published in BDD, Development Processes, RSpec, Ruby, Ruby on Rails, Ruby on Rails 3, Базы данных, Основы, Тестирование
В этой статье мы рассмотрим:
сентября 18, 2011 | Published in BDD, RSpec, Тестирование
UPD: Добавлен параграф об around() хуке.
Доброго времени суток ув. читатель RubyDev’а!
В данный момент автор RubyDev, то есть я, очень похож на белку в колесе ибо он занимается устройством на работу. К сожалению или к великому счастью обязательным условием является умение работать с RSpec, которым автор владеет в совершенстве плохо, по сему, решил я бросить все ресурсы на то, чтобы изучить сие твоение Девида Челимски.
Данную статья пишу я не от того, что вдруг появилось свободное время, но потому, что это единственный способ для меня самого хорошо освоить материал, текст статьи я как-бы пишу сам для себя, объясняя себе то, что только что прочитал в том малом, что мне удалось, словно золото из золотой жилы, выбить да вышкребать, в интернетах.
Ибо время — деньги, а платить мне никто за это старание не будет, буду совсем краток.
Read the rest of this entry »