Ну из отличий, например, у меня в старой версии файла был указан ListeningPort 23399 в разделе Connection, а в новом файле ListeningPort — 18405 и к нему он успешно подключается. Хотя я подозреваю, что работающих портов гораздо больше, чем 1.
> А Linux (вместе с GNU) — это операционная система, основывающаяся на архитектуре 30 или даже 40 летней давности.
Да ладно, а как насчёт POSIX:2008? C 2008 года явно меньше 30 лет прошло…
Или Вы настаиваете на том, чтобы считать возраст архитектуры относительно первого публичного упоминания о ней, независимо от дальнейшего развития?
Тогда уж в WINE@Etersoft, т.к. во-первых этим форком уже занимается российская компания, которая уже адаптировала значительное кол-во win-программ, специфичных для России, а во-вторых, за счёт внешнего финансирования могли бы сделать этот форк свободным.
> Попытка написать софт, позволяющий работать win-приложениями на Linux порочна.
Ну зачем же так категорично? Заставить уже готовый win-софт работать под Linux — вполне разумная идея, хотя и является полумерой.
А по поводу финансирования, ReactOS — в принципе неплохой вариант, но я бы больше обрадовался если бы разработку учетной платформы «Ананас» профинансировали, т.к. полнофункциональной кроссплатформенной замены 1С явно не хватает.
На мой взгляд более прямым доказательством является правильное название этой ОС — 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 дизайн.
Да ладно, а как насчёт POSIX:2008? C 2008 года явно меньше 30 лет прошло…
Или Вы настаиваете на том, чтобы считать возраст архитектуры относительно первого публичного упоминания о ней, независимо от дальнейшего развития?
Ну зачем же так категорично? Заставить уже готовый win-софт работать под Linux — вполне разумная идея, хотя и является полумерой.
А по поводу финансирования, ReactOS — в принципе неплохой вариант, но я бы больше обрадовался если бы разработку учетной платформы «Ананас» профинансировали, т.к. полнофункциональной кроссплатформенной замены 1С явно не хватает.
Судя по всему, этот оборот основан исключительно на высосанных из пальца выпадах Дэвида в сторону 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 дизайн.