Да, звучит прикольно, только 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 — это шоу одного человека, которому самому уже надоело развивать проект, если у вас есть желание впадать в жёсткую зависимость от его настроения или продолжать его проект самому, то вперёд. Свободу выбора никто не отменял.
В демоверсии шаблон на 1024х600 страшновато выглядит (появляется горизонтальная полоса прокрутки)
Да, основной ориентир в демо-версии на ширину экрана минимум 1280px, хотя при ширине 1024px всё не так уж страшно, горизонтальная прокрутка относительно небольшая.
Литературы море, качественной — капли.
И эти капли в подавляющем большинстве на английском. При этом некоторые издательства умудряются нанимать для перевода людей, которые из качественной книги способны сделать белиберду.
Кроме того многие хорошие книги ждут хоть какого-то перевода по 5-10 лет
Вы уж извините, но писать программы транслитом — это и есть уровень быдлокодерства. К тому же что Вы будете делать с тысячами библиотек, которые уже имеют стандартный англоязычный API?
а если и пишут на самом английском — особых знаний там не надо, существительные, прилагательные да глаголы в неопределённой степени по 200-300 слов из каждый группы
Ну так и отлично, добавить сюда ещё сотню наречий, немного предлогов, числительных и прочих частей речи и уже получается базовый технический английский, достаточный для чтения документации, с редким заглядыванием в google translate. Этот уровень в любом случае необходим всем, кто хочет делать в IT нечто большее, чем лабораторные работы по информатике, и его вполне достаточно чтобы особо не запариваться отсутствием русскоязычных материалов.
Вы знаете, что запрещено торговать товарами, содержание и способ применения которых не переведён на русский хотя бы на наклейке поверх упаковки?
Вы всерьёз считаете, что языки программирования, библиотеки и фреймворки являются товаром?
Да их практически никто уже не продаёт, 75% популярных технологий — OpenSource, а ещё 15% — Freeware. Платное — узкоспециализированные языки и навороченные библиотеки под некоторые платформы, не будем тыкать пальцем. Суть в том, что студентам и тем более школьникам, ничего (кроме компьютера) покупать не нужно, чтобы изучать программирование.
Подозреваю, что корректным ответом будет: его целевая аудитория знает английский на достаточном для пользования сайтом уровне.
Ну практически так. Русскоязычному сегменту его целевой аудитории гораздо важнее, чтобы движок продолжал отлично поддерживать морфологию русского языка и т.п., чем документация или сайт на русском.
«Всегда прав разработчик технологии» — это недоступный понимаю тезис. Зачем мы с Вами пытаемся выяснить кто прав?
Это не тезис, это аксиома, т.к. практически любая лицензия содержит пункт «AS IS», т.е. если Вам что-то не нравится, Вы не имеете никакого права требовать что-либо от разработчика.
Я же имел в виду, что для улучшения дел в российском IT, нужно создавать в России больше конкурентноспособных технологий, а не переводить документацию. Вот Вы знаете хотя бы 10 российских компаний, которые всерьёз спонсируют работу русских разработчиков OpenSource технологий? Я лично не знаю и вижу в этом гораздо большую проблему, чем в недостатке русскоязычных курсов по программированию.
и совсем не каждому нужен технический английский, а вот HTML5 может при этом быть интересен
А Вы случаем не из тех, кто задумывает написать собственный язык программирования с русским синтаксисом? Если нет, то технический английский просто необходим любому программисту и даже верстальщику, чтобы хотя бы элементарное именование сущностей в программе/разметке делать, я уж не говорю про RTFM.
Поэтому какая разница, когда начинать учить английский, если без его знания хотя бы на техническом уровне всё равно выше быдлокодера не подняться.
И вообще на мой взгляд Вы не с той стороны отечественные информационные технологии поднимать собрались. Всегда прав разработчик технологии, его документация самая актуальная. А российских технологий раз, два и обчёлся. И то российские разработчики предпочитают поддерживать документацию только на английском. Например, не поленитесь спросить у разработчика Sphinx (он зарегистрирован на Хабре) почему оф.сайт движка не имеет русскоязычной версии.
Выложу конечно, только нужно ещё времени пару недель, чтобы отполировать как следует… Кроме того, хотелось бы просто получить фидбэк от нескольких особо заинтересованных человек, которых не оттолкнут небольшие шероховатости, стоящие в очереди на устранение в ближайшее время :-)
Да, звучит прикольно, только 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 ещё не тестировали…
Спасибо
И эти капли в подавляющем большинстве на английском. При этом некоторые издательства умудряются нанимать для перевода людей, которые из качественной книги способны сделать белиберду.
Кроме того многие хорошие книги ждут хоть какого-то перевода по 5-10 лет
Вы уж извините, но писать программы транслитом — это и есть уровень быдлокодерства. К тому же что Вы будете делать с тысячами библиотек, которые уже имеют стандартный англоязычный API?
Ну так и отлично, добавить сюда ещё сотню наречий, немного предлогов, числительных и прочих частей речи и уже получается базовый технический английский, достаточный для чтения документации, с редким заглядыванием в google translate. Этот уровень в любом случае необходим всем, кто хочет делать в IT нечто большее, чем лабораторные работы по информатике, и его вполне достаточно чтобы особо не запариваться отсутствием русскоязычных материалов.
Вы всерьёз считаете, что языки программирования, библиотеки и фреймворки являются товаром?
Да их практически никто уже не продаёт, 75% популярных технологий — OpenSource, а ещё 15% — Freeware. Платное — узкоспециализированные языки и навороченные библиотеки под некоторые платформы, не будем тыкать пальцем. Суть в том, что студентам и тем более школьникам, ничего (кроме компьютера) покупать не нужно, чтобы изучать программирование.
Ну практически так. Русскоязычному сегменту его целевой аудитории гораздо важнее, чтобы движок продолжал отлично поддерживать морфологию русского языка и т.п., чем документация или сайт на русском.
Это не тезис, это аксиома, т.к. практически любая лицензия содержит пункт «AS IS», т.е. если Вам что-то не нравится, Вы не имеете никакого права требовать что-либо от разработчика.
Я же имел в виду, что для улучшения дел в российском IT, нужно создавать в России больше конкурентноспособных технологий, а не переводить документацию. Вот Вы знаете хотя бы 10 российских компаний, которые всерьёз спонсируют работу русских разработчиков OpenSource технологий? Я лично не знаю и вижу в этом гораздо большую проблему, чем в недостатке русскоязычных курсов по программированию.
А Вы случаем не из тех, кто задумывает написать собственный язык программирования с русским синтаксисом? Если нет, то технический английский просто необходим любому программисту и даже верстальщику, чтобы хотя бы элементарное именование сущностей в программе/разметке делать, я уж не говорю про RTFM.
Поэтому какая разница, когда начинать учить английский, если без его знания хотя бы на техническом уровне всё равно выше быдлокодера не подняться.
И вообще на мой взгляд Вы не с той стороны отечественные информационные технологии поднимать собрались. Всегда прав разработчик технологии, его документация самая актуальная. А российских технологий раз, два и обчёлся. И то российские разработчики предпочитают поддерживать документацию только на английском. Например, не поленитесь спросить у разработчика Sphinx (он зарегистрирован на Хабре) почему оф.сайт движка не имеет русскоязычной версии.