На мой взгляд более прямым доказательством является правильное название этой ОС — GNU/Linux, которое наглядно показывает что ядро под названием Linux входит в проект GNU(GNU's Not Unix).
Полностью поддерживаю. Кандидат всегда может проявить себя в OpenSource-проектах. А учитывая, что абсолютное большинство веб-программистов используют плоды OpenSource в своей профессиональной деятельности, нежелание внести безвозмездный вклад в открытый проект в виде нескольких часов рабочего времени вполне может расцениваться как неуважение к своим коллегам.
Я работаю в одном офисе с Девидом, и поверьте настроения у него хватит не на один такой проект, так что он будет развиваться и далее.
Не верю, может у него и хватит настроения сделать со временем что-то близкое к production-ready. Но существует множество примеров, как проекты гораздо более качественные, чем ror-e, загибались когда единственный коммитер терял к ним интерес, взять тот же searchlogic или resource_controller.
могу сказать что у ror-e вполне нормальное будущее, избавленное от маразмов существующих в Spree годами
Судя по всему, этот оборот основан исключительно на высосанных из пальца выпадах Дэвида в сторону Spree, которые по большей части не имеют ничего общего с действительностью.
из личного опыта могу сказать что архитектура spree не потянет двухмиллионную базу постоянных пользователей (300-400 тысяч посещений в день)
Да бросьте Вы пугру гнать, при такой нагрузке всё будет обвешано кешированием в любом случае, причём настолько, что для быстродействия уже будет не важно какая там архитектура. Архитектура будет иметь влияние только на сроки разработки и тут Spree легко обойдёт ror-e и уж тем более написание всего на чистом Rails.
Spree хорош для маленьких магазинчиков — натянул свой шаблон и готово, продавай себе по десятку товаров в день и бед знать не будешь.
И тем не менее демо-версия на shared-хостинге вполне спокойно выдержала более 17000 просмотров страниц за день! Если перенести на какой-нибудь средненький VDS с 1Gb RAM, то будет выдерживать и 50000 просмотров в день постоянно. Всем бы маленьким магазинчикам такую посещаемость! :-D
Фильтры можно сделать через Solr, в базовую версию они не входят.
> важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart
Ну импорт — штука индивидуальная, пока разработка универсальных решений для импорта из Excel не планируется. А под конкретный случай написать не сложно.
Да, звучит прикольно, только Synergy не повышает уровень абстракции, так что скорее Synergy Spree on Rails on Ruby
> В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
Так и есть, но наличие готовой сборки в виде Synergy уже сокращает это требование до 1 программиста для большинства случаев. :)
Кроме того, делать всё самостоятельно и содержать в штате программистов ведь совсем не обязательно, можно просто сотрудничать с фирмой, оказывающей соответствующие услуги…
> А CMS по определению сделана для тех, кто не хочет париться с кодом.
Ну я ж сказал, что называть Spree CMS — это не совсем верно. А CMS в вашем понимании(сделать что угодно не заглядывая в код системы) на RoR вообще не существует, насколько мне известно.
> в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
Самый простейший пример — нескольким расширениям нужно вставить определённый partial на определённое место в уже существующем шаблоне. Если бы это делалось через partial в существующем шаблоне, то возник бы конфликт расширений.
1) Spree — это не совсем CMS, т.к. она в плане модификаций ориентирована больше на программистов и сделана так, чтобы было удобно именно программистам, а не верстальщикам.
2) partials они может и удобнее, когда надо сделать один магазин с фиксированным функционалом, а вот когда надо сделать хотя бы 10 магазинов с разным функционалом, который ещё и развивается со временем, то partials уже ничем не помогут, в отличии от хуков и deface.
> за оригиналом файла надо лезть в гем или на гитхаб
и это совсем не так сложно, как Вы пытаетесь представить…
> из API ничего не понятно
мне вот из этого замечания тоже ничего не понятно, e-commerce движок — это же не библиотека, чтобы использовать его для разработки нестандартных магазинов, не заглядывая в код.
> надо разбираться в коде CMS чтобы сверстать шаблон (!)
Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
Ну, лично для меня лучшая документация — это код.
Хотя вот сейчас специально перечитал Spree Extension Tutorial, Customization Overview и бегло просмотрел другие статьи из раздела «Digging Deeper» и даже сходу не могу сказать что там не описано. Наверняка какие-нибудь тонкости остались незадокументированными. Но то, что прочитав всю эту документацию, невозможно создать расширение с нуля — это, мягко говоря, не правда. Сложность такой задачи зависит скорее от сложности самого расширения, а документации по сопряжению своего кода со Spree вполне достаточно для разработки собственных расширений, при условии что разработчик знаком с Ruby on Rails. И к чести авторов документации замечу, что сейчас она гораздо лучше отражает реалии текущей версии Spree, чем это было, к примеру, 1.5 года назад.
To override any of Spree’s default views, including those for the admin interface, simply create a file with the same filename in your app/views directory.
For example, to override the main layout, create the file YOUR_SITE_OR_EXTENSION/app/views/layouts/spree_application.html.erb
Что касается создания новых вьюх, то оно ничем не отличается от любого Rails-приложения, простое добавление файла в app/views/**
Что касается хуков, то они существуют для облегчения обновления и интеграции с расширениями. Кстати, хуки будут вскоре заменены на ещё более гибкое решение — github.com/BDQ/deface
вы явно не пытались писать с нуля модуль или шаблон к Spree
Да я уж со счёта сбился сколько я расширений(модулей) для Spree написал с нуля… Хотя спорить насчёт качества документации я не хочу, я хочу лишь добиться более конструктивных замечаний, чтобы лучше понимать какие темы недостаточно освещены. А от Вашей нигилистической позиции никому лучше не станет.
но только вглядитесь в них всех. да там даже layout'ы никак не сменены. максимум изменений дизайнов у всех — вставлена пара hook'ов, да css подправлен.
Я, честно говоря, имел в виду функциональные изменения, а не внешние. Что касается дизайна, я лично не дизайнер, поэтому даже вглядываться не буду. Внедрить Synergy/Spree можно в любой e-commerce дизайн.
Демка лежит на обычном shared-хостинге, который стоит скорее 29.9$ за год. По данным анализа логов, среднее время отдачи для самых нагруженных страниц следующее:
главная страница — 0.14s
страница категории — 0.24s
страница товара — 0.28s
Если у Вас было сильно хуже, то возможно Вы попали на момент, когда кто-нибудь решил провести нагрузочное тестирование демки, для чего shared-хостинг конечно слабо предназначен.
У Вас какая-то личная обида на Spree раз Вы распространяете заведомо ложную информацию?
Для разработчиков есть вполне хорошая документация — spreecommerce.com/documentation/overview
По поводу гибкости, даже интересно, какую это e-commerce задачу нельзя решить при помощи Spree? Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены.
Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков. Если есть сказать что-то конкретное на этот счёт, то прошу продемонстрировать в виде pull request'а, а не голословных обвинений.
однако я больше ставлю на ror-e.com проект. Побольше бы туда людей начало коммитить.
Вы серьёзно? :-)
ror-e — это шоу одного человека, которому самому уже надоело развивать проект, если у вас есть желание впадать в жёсткую зависимость от его настроения или продолжать его проект самому, то вперёд. Свободу выбора никто не отменял.
Судя по всему, этот оборот основан исключительно на высосанных из пальца выпадах Дэвида в сторону Spree, которые по большей части не имеют ничего общего с действительностью.
Да бросьте Вы пугру гнать, при такой нагрузке всё будет обвешано кешированием в любом случае, причём настолько, что для быстродействия уже будет не важно какая там архитектура. Архитектура будет иметь влияние только на сроки разработки и тут Spree легко обойдёт ror-e и уж тем более написание всего на чистом Rails.
И тем не менее демо-версия на shared-хостинге вполне спокойно выдержала более 17000 просмотров страниц за день! Если перенести на какой-нибудь средненький VDS с 1Gb RAM, то будет выдерживать и 50000 просмотров в день постоянно. Всем бы маленьким магазинчикам такую посещаемость! :-D
> важно, чтобы была возможность импорта excel-файлов с перечнем товаров, как это сделано отдельным модулем в opencart
Ну импорт — штука индивидуальная, пока разработка универсальных решений для импорта из Excel не планируется. А под конкретный случай написать не сложно.
Есть поддержка следующих гейтов для оплаты через визу: AuthorizeNet, Beanstream, Braintree, eWAY, LinkPoint, SagePay.
Да, звучит прикольно, только Synergy не повышает уровень абстракции, так что скорее Synergy Spree on Rails on Ruby
> В описании spree написано что решение ориентировано на серьезные организации, которым не влом содержать 2-3 программистов.
Так и есть, но наличие готовой сборки в виде Synergy уже сокращает это требование до 1 программиста для большинства случаев. :)
Кроме того, делать всё самостоятельно и содержать в штате программистов ведь совсем не обязательно, можно просто сотрудничать с фирмой, оказывающей соответствующие услуги…
Ну я ж сказал, что называть Spree CMS — это не совсем верно. А CMS в вашем понимании(сделать что угодно не заглядывая в код системы) на RoR вообще не существует, насколько мне известно.
> в упор не пойму, почему. чем partials в поддержке хуже хуков и deface?
Самый простейший пример — нескольким расширениям нужно вставить определённый partial на определённое место в уже существующем шаблоне. Если бы это делалось через partial в существующем шаблоне, то возник бы конфликт расширений.
2) partials они может и удобнее, когда надо сделать один магазин с фиксированным функционалом, а вот когда надо сделать хотя бы 10 магазинов с разным функционалом, который ещё и развивается со временем, то partials уже ничем не помогут, в отличии от хуков и deface.
> за оригиналом файла надо лезть в гем или на гитхаб
и это совсем не так сложно, как Вы пытаетесь представить…
> из API ничего не понятно
мне вот из этого замечания тоже ничего не понятно, e-commerce движок — это же не библиотека, чтобы использовать его для разработки нестандартных магазинов, не заглядывая в код.
> надо разбираться в коде CMS чтобы сверстать шаблон (!)
Чтобы сверстать шаблон надо разбираться только в HTML и CSS, а уж внедрять его разумеется будет человек, знакомый с кодом системы.
Хотя вот сейчас специально перечитал Spree Extension Tutorial, Customization Overview и бегло просмотрел другие статьи из раздела «Digging Deeper» и даже сходу не могу сказать что там не описано. Наверняка какие-нибудь тонкости остались незадокументированными. Но то, что прочитав всю эту документацию, невозможно создать расширение с нуля — это, мягко говоря, не правда. Сложность такой задачи зависит скорее от сложности самого расширения, а документации по сопряжению своего кода со Spree вполне достаточно для разработки собственных расширений, при условии что разработчик знаком с Ruby on Rails. И к чести авторов документации замечу, что сейчас она гораздо лучше отражает реалии текущей версии Spree, чем это было, к примеру, 1.5 года назад.
spreecommerce.com/documentation/customization.html#template-replacements
Что касается создания новых вьюх, то оно ничем не отличается от любого Rails-приложения, простое добавление файла в app/views/**
Что касается хуков, то они существуют для облегчения обновления и интеграции с расширениями. Кстати, хуки будут вскоре заменены на ещё более гибкое решение — github.com/BDQ/deface
Они просто пустые в демо-данных :-)
Заапрувил несколько свежих комментариев с никами, например здесь: demo.synergycommerce.ru/products/apple-iphone-4-32gb
> и при доб-е товара ошибка) ngix выходит — возможно хабраэффект)
Возможно, воспроизвести не удалось… будем разбираться.
Я, честно говоря, имел в виду функциональные изменения, а не внешние. Что касается дизайна, я лично не дизайнер, поэтому даже вглядываться не буду. Внедрить Synergy/Spree можно в любой e-commerce дизайн.
Если у Вас было сильно хуже, то возможно Вы попали на момент, когда кто-нибудь решил провести нагрузочное тестирование демки, для чего shared-хостинг конечно слабо предназначен.
Для разработчиков есть вполне хорошая документация — spreecommerce.com/documentation/overview
По поводу гибкости, даже интересно, какую это e-commerce задачу нельзя решить при помощи Spree? Сотни магазинов, от groupphotos.com до stickermule.com как бы прозрачно намекают, что возможности кастомизации в Spree практически ничем не ограничены.
Код Spree может и не идеальный, но на уровне лучших представителей OpenSource движков. Если есть сказать что-то конкретное на этот счёт, то прошу продемонстрировать в виде pull request'а, а не голословных обвинений.
Вы серьёзно? :-)
ror-e — это шоу одного человека, которому самому уже надоело развивать проект, если у вас есть желание впадать в жёсткую зависимость от его настроения или продолжать его проект самому, то вперёд. Свободу выбора никто не отменял.
Мобильная версия ещё пока в разработке, на iPad ещё не тестировали…