Ruby on Rails c нуля!

Доброго времени суток всем читателям RubyDev! Сегодня в виртуальной студии RubyDev гость из США, профессиональный разработчик, который в свободное от работы время занимается разработкой альтернативы для Spree — .

Сразу хочу предупредить, что я не профессиональный переводчик и мой английский весьма слаб, по этому в при переводе моего интервью с Девидом, мне приходилось ломать голову над некоторыми идиоматическими выражениями. Тем не менее мы с Девидом поняли, что каждый из нас имел в ввиду и в результате нашей переписки получилось такое вот интервью:

Девид, представся пожалуйста читателям RubyDev, расскажи немного о себе, работе и хобби.

Привет! Я Девид Райaн Хэннер (David Rayn Henner). Я работаю по контракту на одну софтверную компанию и кроме того пытаюсь создать свой собственый бизнес. Мой стартап называется и мы продаем мужскую одежду онлайн и через прямые продажи. Насчет хобби, то я особо ничем не увлекаюсь кроме программирования на Ruby и смежных с разработкой тематиками. Надеюсь в ближайшее время начать играть в гольф.

 

 

 

 

 

 

 

 

Девид, расскажи пожалуйста о своем проекте RoReCommerce.

ror_ecommerce — это e-commerce стартовое приложение разработанное на Rails 3. Это проект разработанный для начинающих бизнесов в сфере электронной торговли, которые имеют перспективу большого роста. Вот например, я создаю двойную систему аккаунтов, которая совсем не нужна для маленьких магазинов, однако ее наличие им не навредит. Я также хочу, чтобы мой проект был дружелюбен к разработчику, я задокументировал почти весь код в моделях и стараюсь писать понятные, «говорящие» имена методов.

Девид, расскажи пожалуйста о самых крупных электронных магазинах, которые используют RoReCommerce. Используешь ли ты RoReCommerce в своем собственном стартапе?

Да, я использую в моем стартапе, но в данный момент мой проект еще не запущен и там можно увидить только страницу «Comming soon». Я знаю несколько крупных сайтов, что использует RoReCommerce, но я предпочитаю не называть эти сайты, потому, что это может оказаться разглашением конфиденциальной информации. Несколько Rails-консультантов используют RoReCommerce и я не могу разглашать информацию об их проектах так как считаю, что она должна быть приватной.

Некоторые из консультантов, которые общаются со мной на тему RoReCommerce:

- endpoint.com
- circarconsulting.com
- railsfactory.com
- и еще несколько консультантов-фрилансеров

Точное количество проектов на RoR-e назвать не могу, но полагаю, что их около 40.

 

Почему ты решил создать новое решение для электронной коммерции на Rails, когда Ruby/Rails сообщество уже имеет Spree?

началось как просто стартовое приложение для Rails3 приложения. Я хотел решение, которое включало бы в себя factory-girl, RSpec и работало на Rails 3, чтобы я мог разрабатывать приложения быстрее. Когда я начал работать со Spree, мне не понравился путь, по которому идет Spree — когда в коде слишком много магии. В то время в Spree использовался resource_controller и мне казалось, что resource_controller пытается делать очень много магии на понимание которой нужно потратить много часов, чтобы разобраться как же можно что-то переписать. Кроме того, я считаю, что Spree содержит очень много кода в контроллерах. После нескольких недель сплошных разочарований я взял тот багаж знаний, что накопил ковыряясь в Spree и начал разрабатывать собственное решение для электронной коммерции.

Расскажи пожалуйста об основных различиях между RoReCommerce и Spree

Как же надоел мне этот вопрос, я потратил часы на объяснение причин почему я начал создавать ror_ecommerce. Во-первых RoR-e имеет преимущества перед Spree в легкости изучения. Я не хочу говорить плохо о Spree, просто расскажу о различиях между Spree и RoR-e:

1. Spree пытается стать фреймворком для магазиностроения. Это проявляется в том, что Spree переписывает некоторые части в Rails. Я не следил за последними версиями Spree, но первое, что я заметил в Spree — это то, что директория app находится в директории vendor.

вместо этого пытается вести себя как обыкновенное приложение на Rails. Директория app находится там, где и должна находиться. RoR-e не переписывает Rails потому, что я убедился в том, что чтобы понять, где Spree переписывает Rails необходимо потратить несколько ценных часов работы.

2. В Spree имеется концепция расширений. Я верю, что они движутся к engine’ам, но эти engine’ы почти никогда не работают для всех версий Spree. В это время RoR-e ведет себя как обычное приложение на Rails. Если тебе необходима какая-то дополнительная функциональность, то ты можешь создать engine или просто изменить поведение самого RoR-e.

3. В Спри добавление нового метода в класс Заказа потребовало использовать class_eval. Когда у тебя есть код в расширении, который перекрывает метод, и потом ты перекрываешь класс еще раз в конце концов у тебя код класса Заказа оказывается в разных местах. Следить за всем этим невозможно. Для ror-e если ты хочешь перекрыть метод, то все, что нужно сделать — это открыть модель и сделать изменение.

4. Я обнаружил, что обновлять Spree практически невозможно. Люди говорят мне, что RoR-e должен быть engine. Я обнаружил, что будет очень сложно обеспечить для RoR-e обратную совместимость, если превратить его в engine. Если тебе нужна обратная совместимость, я бы добавлял функциональность в RoR-e с помощью добавления к ней engines. Но как я уже говорил, лучший способ разрабатывать что-то на RoR-e — это загрузить код из репозитория и работать с ним просто как со своим приложением.

5. В Spree корзина это просто объект заказа. Лично мне такое решение кажется ужасным. Во-перых, заказ и корзина это две абсолютно разные вещи. Корзина — это просто набор продуктов. До оформления заказа (checkout) корзина (cart) не должна ничего делать, кроме как помнить что за товары хранятся в ней. Заказ же, с другой стороны, нужно хранить как зеницу ока. Объект заказа не должен изменяться или обновляться после оформления заказа. Объект заказа не может быть обновлен или изменен после вашей проверки. В RoR-e корзина очень продвинута и проста. Единственная задача корзины — хранить набор продуктов. Продвинутая часть заключается в возможности сохранить корзину для будущей покупки и закупочном функционале. Корзина в RoR-e никогда не удаляет продукты. Это позволяет легко получать список продуктов, которые пользователь когда-либо добавлял себе в корзину. Это просто мечта команды меркетологов!

6. Я могу долго рассказывать о корзине, способе хранения адресов, возвратах, отгрузке, специальном инвентаре и т.д., а также об изьянах Spree, которые я исправил в RoR-e. Мне кажется, что Spree было хорожим решением, как только увидело свет, однако Rails и практики программирования изменились и я считаю, что RoR-e более приспособлено к новшествам.

Как много людей работают с тобой над RoReCommerce?
У меня есть несколько контрибъюторов. Большинство из них помогают мне маленькими исправлениями или сообщают о проблемах работы в windows или linux. После того, как эти проблемы решаются, они перестают участвовать в разработке. При этом у RoR-e очень мало построянных активных участников, большинство решают свои проблемы и возвращаются к повседневной работе. Такие участники также предоставляют большую помощь проекту.

У меня есть человек, который помогает мне с рефакторингом корзины администратора. Я сделал плохое решение касательно устройства корзины администратора и не могу дождаться, когда рефакторинг завершится. Обновленная корзина администратора будет выглядеть и вести себя как обычная пользовательская корзина.

Какие gem’ы ты используешь в RoReCommerce и почему выбрал именно их?

RoR-e имеет большой список gem’ов, основными и неизменными являются следующие:

• dalli (для memcached)
• compass (для CSS)
• sunspot_rails (для поиска)

Большинство остальных gem’ов стандартны и с ними почти все разработчики хорошо знакомы.

Dalli — это способ доступа к memcached. Я в будущем хочу сократить использование memcached, но все равно буду продолжать его использовать. Я слишком переборщил с его использованием в корзине администратора. У меня в планах сделать чтобы корзина администратора вела себя как обычная корзина товаров.

Compass — отличное решение добавления кода на Ruby в CSS. Мне нравится Compass потому, что я могу организовать мой CSS и иметь partial’ы для заголовка, подвала, и остальных частей страниц представления моего приложения. После написания стилей на SASS Ruby компилирует их в CSS и позволяет повторно использовать partial’ы.

Sunspot может быть чертовски простым даже если тебе не нужна вся мощь Solr для поиска продуктов.

Это отличные gem’ы поэтому я рекомендую использовать их если у вас нет хорошей причины отказаться от их использования.

Почему был выбран именно sunspot_rails для Solr, когда имеется более популярное поисковое решение — Sphinx?

Я изучал и sunspot_rails и Sphinx. Sunspot мне показалось очень простым в установке и в удалении, на случай, когда поисковый функционал не нужен. Я не обращаю внимания на популярность gem’ов. Вместо этого я смотрю на API и Sunspot в этом плане выглядит просто отлично! Также мне порекомендовали использовать Sunspot ребята из Heroku. Gem’ы которые в один день имеют большую поддержку и очень популярны могут лишиться всего этого на следующий день. Это постоянная битва за апдейт, которая является самой великой и важной частью Open-Source движения.

Расскажи пожалуйста о своем рабочем окружении, какое железо и софт используешь.

Разработку веду на MacBook Pro, а редакторы, которые я использую — это Textmate и VI.

А что ты предпочитаешь использовать для тестирования и почему?

Мой стандартный набор — это RSpec + factory-girl. Я предпочитаю эти инструменты просто потому, что я с ними хорошо знаком. Моя цель переключиться на Test::Unit или MiniTest потому, что они поставляются в комплекте с Rails и они не будут сильно ломать тесты при обновлениях в Ruby.

Иногда работая над каким-нибудь проектом люди изобретают новые gem’ы, какие gem’ы разработал ты в процессе работы над RoReCommerce?

Я только что начал разработку нового gem’а. Это будет что-то вроде scaffold’а для тестов после того, как твой код написан. У тебя есть несколько контроллеров, которые нуждаются в покрытии тестами. Вместо того, чтобы вручную создавать каждую строку кода для контроллеров, этот gem будет проверять классы и определять какие тесты необходимо сгенерировать.

Девид, как ты начал работать с Ruby и Rails? Какие языки и фреймворки ты использовал раньше?

Я выбрал Ruby on Rails потому, что мне очень понравилось видео «15 minute blog» от DHH, которое было сделано достаточно давно. До того, я был занят в индустрии полупроводников. Мне был необходим способ добавить мои автоматизированные графы из MatLab в веб-среду. Сначала я выбрал php и как только я убедил всех в моей компании использовать php я обнаружил Ruby on Rails. Я очень рад, что я не продолжил работать на PHP. До MatLab я занимался программированием на C и Assembler.

В данный момент изучаешь какие-нибудь новые языки программирования или фреймворки? Что думаешь насчет CoffeScript?

Мне кажется, что CoffeeScript будет скоро широко использоваться в Ruby/Rails сообществе. Я являюсь большим фанатом JavaScript/jQuery последние несколько лет. Я знаю, что мне придется сделать выбор, но я пока наблюдаю как хорошо CoffeeScript приживется в сообществе. Мне кажется, что CoffeeScript должен решить проблему с отладкой при помощи разработки специальных инструментов, перед тем, как стать повсеместно используемой заменой для JavaScript.

Расскажи в каких проектах кроме RoReCommerce ты участвуешь?

Я сделал собственную ветку nifty-generators в которой внедняю нужный мне функционал. Кроме того, я являюсь контрибютором Spree. Я трачу часы на чтение доски сообщений Spree и пытаюсь помочь, кроме того, я пытаюсь отвечать на вопросы на stack overflow. Если у меня будет необходимое для жизни количество денег, я думаю, что, буду тратить большую часть своего времени на обучение и помощь людям, мне реально очень нравится помогать другим людям в решении каких-то задач.

До RoR-e я тратил 80 часов в неделю на работу и я не мог себе позволить участие в open source движении.

Используешь ли ты Sinatra или Padrino в некоторых своих проектах? Что ты думаешь об этих двух проектах?

Я имел опыт использования Sinatra. Я считаю, что Sinatra заслуживает своего места в сообществе Ruby. Если тебе необходимо создать маленькое приложение или сервис, то Sinatra — великолепный для этого выбор. Я также верю, что сообщество должно фокусироваться на 2-3 фреймворках. Наличие выбора — отличная штука! Однако наличие слишком большого количества вариантов означает, что сообщество движется в разных направлениях. Причина того, почему PHP такой беспорядочный в том, что сообщество PHP не имеют большинства разработчиков, которые бы занимались разработкой на одном фреймворке.

Последний Rails 3.1. стал очень монструозным благодаря большому набору новых гемов. А Matz в одном из последних интервью поделился информацией о том, что Ruby core team начали разрабатывать Ruby 2.0. Что ты думаешь о будующем Ruby и Rails и о недавно выпущеном Rails 3.1?

RoR всегда прогрессирует быстрее чем я того ожидаю. 3.1. — отличная штука, но в этой версии содержатся некоторые вещи, которые опасны для начинающих разработчиков. Например, identity map — очень крутая штука, но если программисты будут расчитывать на нее, то код будет практически невозможно отлаживать.

В целом мне очень нравится Rails 3.1 и еще больше будоражит воображение Rails 3.2. Аарон Паттерсон (Aaron Patterson) обещал большую скорость и меньшее количество объектов в Rails 3.2. Я жду с нетерпением.

Что касательно Ruby 2.0. Все выглядит похожим на то, что Ruby будет иметь больше интересных инструментов для работы с примесями. Я также надеюсь, что реализация MRI возьмет что-то из проекта Rubinious. Rubinious имеет несколько отличных концепций. Еще мне бы хотелось, чтобы были добавлены акторы или другое решение позволяющее качественно реализовать параллелизм (многопоточность). Имея в виду то, что все новые компьютеры имеют несколько ядер, параллелизм является очень важной возможностью не только для Ruby, но и для любого языка программирования. Мне также интересны ruby-lite.

Сможет ли Ruby урвать большой кусок пирога у PHP в ближайшем будующем?

Ruby vs PHP… Лично я считаю, что Ruby получит больше разработчиков из тусовки Java чем из PHP. PHP разработчики редко используют ООП, я считаю, что они не заходят преодолевать это препятствие и переходить на Ruby.

Девид, имел ли ты опыт работы с mongodb, что думаешь об этой NoSQL базе данных? Какую ORM для MongoDB ты вибираешь и почему? В последнее время многие разработчики использую MongoDB абсолютно везде ссылаясь на то, что MongoDB производительнее реляционных баз данных, как это прокоментируешь?

Mongo — отличный инструмент. Разрабатывая магазин для одной компании у которой было несколько странных бизнес-правил, мне пришлось разрабатывать более гибкую корзину. Поэтому я убрал стандуртную для ror_ecommerce корзину и заменил ее корзиной основанной на mongo. Для работы с MongoDB я предпочитаю Mongoid, я даже не знаю лучше он или хуже чем Mongo-Mapper.

Насчет повсеместного использования Mongo вместо SQL, я не люблю это модное веяние. Многие люди используют Mongo как реляционную базу данных забывая о том, что MongoDB — это не реляционная база данных. Если ты проектируешь свою базу данных как имеющую связи между таблицами, то ты должен использовать SQL.

Расскажи, что ты думаешь о новомодном node.js? Почему node.js все чаще и чаще можно увидить в требованиях к Ruby программисту?

Node.js — интересный проект. Я не могу дождаться, когда он станет более стабильным. Я считаю, что либо Node.js станет стабильным, либо новый проект, который обогатится опытом и идеями из Node.js заменит его. Я также слышал, что Node.js постоянно с каждым новым релизом ломает старый функционал. Мне кажется это должно прекратиться прежде чем я бы мог кому-то посоветовать использовать Node.js в продакшене. Таким образом могу сказать, что Node.js или его аналог ждет реальная популярность в будующем.

Node.js стал таким популярным по двум причинам: скорость и отличная реализация паттерна pub-sub.

Я недеюсь, что разработчики из сообщества Ruby не будут фокусироваться на скорости и будут помнить о том, что стабильность и надежность также очень важны.

Девид, спасибо тебе за интересное интервью. Что ты можешь посоветовать читателям RubyDev и вообще всем новичкам в Ruby и Rails?

Новички, убедитесь в том, что программирование — это то, что вы любите. Если вы действительно любите программирование, то найдите людей у которых можно поучиться и удачи вам!

Читатели RubyDev, я не говорю на русском, поэтому мне интересно узнать больше о RubyDev. Попробуйте RoReCommerce и если он вам понравится — сообщите мне, а если не понравится — сообщите мне дважды. Я хочу слышать хорошие и плохие отзывы. Я чувствую что проект станет только лучше если люди будут сообщать о том, что им нравится, а что нет. Заранее благодарен за ваши отзывы и предложения!

Ссылки по теме:

• — здесь можно найти всю необходимую информацию о RoReCommerce.

 

Итоги:

В Ruby/Rails сообществе появился конкурент для Spree и судя по ответам Девида, этот конкурент достаточно серьезен и имя ему RoReCommerce. Если вы занимаетесь разработкой электронных магазинов на Rails, то вы просто обазаны посмотреть в сторону RoR-e.

Огромное спасибо Девиду за интересное интервью и удачи ему в его работе и бизнесе.

P.S. Что за интервью и как принять участие можно узнать здесь – http://rubydev.ru/2011/08/besplatnaya-reklama-na-rubydev-interesnyx-proektov-developerov-i-dizajnerov/, там же можно узнать о бесплатной рекламе на RubyDev своих услуг, проектов и т.д. RubyDev рад сотрудничать со всеми людьми на этой планете ибо все мы братья.