апреля 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.
апреля 26, 2012 | Published in Ruby on Rails, Ruby on Rails 3, Базы данных
Ассоциации между моделями ч. 1. В этой статьи мы поговорим об интересных параметрах и возможностях ассоциаций моделей.
Псевдонимы
Часто бывает необходимо или желательно использовать отличное от имени модели имя ассоциации. Например у нас есть две модели Store и User и у Store имеется владелец (seller — продавец). store.user выглядит не очень красиво, как буд-то речь идет о пользователе магазина, а не о его владельце (продавце), кроме того, у нас может быть несколько ассоциаций с моделью User, например у нас может быть buyer и seller.
Read the rest of this entry »
апреля 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, Базы данных, Основы, Тестирование
В этой статье мы рассмотрим:
апреля 15, 2012 | Published in Ruby, Ruby Gems, Ruby on Rails, Основы
Установить Ruby в Windows почти так же легко, как и в Ubuntu. Сразу хочу предупредить, что в работе Ruby под Windows имеется несколько ограничений, особенно это касается работы с файловой системой и процессами. Также не все библиотеки Ruby (gem’ы) отлично работают в Windows, например один из самых распространенных серверов для Rails — Unicorn заточен под Linux и совсем не работает под Windows.
апреля 5, 2012 | Published in Ruby on Rails, Ruby on Rails 3, Базы данных
Ассоциации между моделями ч. 2. Экземпляры моделей представляют собой сущности реального мира, а ассоциации между ними являются ни чем иным как отношениями этих сущностей между собой.
ActiveRecord предоставляет несколько возможных ассоциаций (типов отношений) между моделями и все они представлены ниже.
belongs_to — принадлежность другой модели. Пример:
class Post < ActiveRecord::Base belongs_to :category end