В статье очень много голословных заявлений, но ни одно из них вы даже не попытались проверить. Я не очень понимаю, почему ИИ не сможет синтезировать известные понятия на основе существующих примеров - именно так человеческие дизайнеры и поступают, они не из воздуха все эти понятия берут. Графический интерфейс имеет смысл лишь для человека, и вся обвязка вокруг (UI-киты, цветовые палитры, дизайн-системы) должна создаваться из прежде всего практических соображений - для унификации, для упрощения работы и облегчения потребности думать в процессе создания интерфейса.
Все эти вещи в какой-то степени уже описаны людьми, иначе заходить в профессию было бы невероятно сложно. Большинство проблем, которые вы описываете - это и не проблемы вовсе, это специфика, с которой вы сталкиваетесь ежедневно. Например:
на простой запрос типа "сеть, создай UI-kit мобильного приложения для Figma" мы очень долго будем >читать что-то типа «не хватает входных данных» в ответ.
Кожаный дизайнер точно также на такой "простой" запрос мне ответит "не хватает входных данных".
Вы пишете:
но вот какие оттенки должны, с точки зрения будущего пользователя (дизайнера), преобладать в темах >"alien" или "space" — неясно. У каждого свои инопланетяне и свой цвет космоса.
Я прошу ChatGPT предложить мне варианты и получаю следующее:
к кому идти за ответом на интересный вопрос о принадлежности условного "indigo" к тёмно-синим или >фиолетовым оттенкам — к художникам? К философам? К психологам?
У ИИ вообще такой проблемы не стоит, она имеет важность лишь для вас.
как действовать, обеспечивая аксессибилити в вопросе Ахроматопсии/Дейтеранопии — например, с каких >уровней L тему делать «контрастной», выкручивая до предельных значений, и какой диапазон значений H >из зелёного спектра нужно преобразовывать в значения из условно-видимого спектра
ИИ в потенциале обладает гораздо большими способностями по обработке информации - в т.ч. рекомендаций и существующих примеров. Безусловно, тут нужны тестирования, но и эта сфера достаточно формализована и автоматизирована - что мешает ИИ сделать А/Б тест и выбрать наиболее рабочий вариант из подходящих условиям?
Резюмируя: да, у ИИ есть очевидные проблемы с созданием новых концепций, но в сфере обработки и модификации существующих решений под условия задачи ИИ уже хорошо справляется (даже не будучи заточенным под условия предметной области).
Затем, что PHP это не JS / DOM. Если хочется модных реактивных фреймворков на фронтенде, приходится либо отдавать JS-only контент (а это убивает SEO), либо применять SSR, чтобы рендерить те же самые компоненты на бэкенде.
А я думаю, что автор — красавчик и желаю, что бы он далеко пошел в своем развитии и успехов. Уверен, кто-то другой из интернета обязательно будет искать больше инфы про Яндекс и его интервью и благодаря статье узнает альтернативный взгляд на ситуацию.
Копирайтинг оно или нет — мы всё равно никогда не узнаем, зато хотя бы написано читаемо и без воды.
Вы никогда не узнаете об этом напрямую, но влияние этого фактора будет. Подготовиться и эксплуатировать такие вот "подсознательные" штучки — вполне жизнеспособная стратегия, как по мне.
Вы, как мне кажется, излишне жёстки к оценке ситуации. Сколько еще было случаев в мире, когда человек с более хорошим culture fit таки прижился лучше, чем инженер с более высокими tech skills?
Нанимающий руководитель не может не оценивать это, но тут неминуемы ошибки. На этапе интервью слишком мало информации о кандидате, приходится угадывать.
По вашей же ссылке о первой имплементации говорится так:
The first blockchain was conceptualized by a person (or group of people) known as Satoshi Nakamoto in 2008. Nakamoto improved the design in an important way using a Hashcash-like method to timestamp blocks without requiring them to be signed by a trusted party and introducing a difficulty parameter to stabilize rate with which blocks are added to the chain.[4] The design was implemented the following year by Nakamoto as a core component of the cryptocurrency bitcoin, where it serves as the public ledger for all transactions on the network.[3]
Мне кажется, вы изобрели тикетную систему. Посмотрите на любой нормальный issue tracker — там и разные типы тикетов, и настройка полей в них, и автоматизация различного рода (валидация, cron-задачи, шаблоны и т.д.) и гораздо более широкие возможности по интеграции с чем-либо.
Я не вижу ничего автоматизированного в этом документе — вся настройка, весь процесс документирования — ручной. Поправьте меня, если я не уловил мысль.
Я надеюсь, вы понимаете, что PSR — это всего лишь стандарт, ему можно следовать, а можно и не следовать, но его нельзя написать "нестандартизированно", "неконкретно" и т.д. На него проще смотреть, как на формальное (именно поэтому MUST капсом, это из RFC пришло) описание конвенции по работе с кодом, принятой некоторым сообществом добровольно.
Если хотите, придумайте свой стандарт, в котором можно будет ставить лишний пробел. Уберите "неважные" правила из линтера и т.д. Получайте удовлетворение от решения задач и вместе с ними ворох лишних правок в коммите, когда кто-то нажмет Reformat Code в своей любимой IDE, настроенной на свой вкус. Так можно будет легко разобраться, что относится к задаче, а что — просто форматирование существующего кода. Еще будут веселые войны за положение скобочек, табы\пробелы и так далее, и эти войны будут скрывать реальные опечатки, косяки, баги.
Зачем вообще локатор/контейнер при тестах? Инжектите зависимости через setter'ы (или конструктор). И да, чтобы тестировать класс нужно залезть в его код. И нет, не обязательно лезть в код, если у вас есть описание публичных интерфейсов класса и ожидаемое поведение.
А если мы интеграционный тест пишем и нам не очень хочется писать кастомную логику инициализации всего дерева требуемых объектов?
В PHP так можно.
То, что так можно, не означает, что так нужно делать. Код с тайп-хинтами лучше анализируется статически, предотвращает ошибки еще до запуска и тем более деплоя.
Мне кажется, современные DI-контейнеры с автовайрингом уже давно закрывают любую потребность в Service Locator, при этом никак не влияют на конечный код сервисов — он остается Plain Old название языка. Конечному коду не нужно знать об интерфейсе Локатора и особенностях использования, этот код можно перетащить куда-либо еще.
Как уже выше было верно отмечено, lazy init и возможность в рантайме переопределять сопоставление имени сервиса и его имплементации также давно реализованы в DI-контейнерах.
Мы используем Vue 1.0 в X-Cart 5 и впечатление от использования отличное, годные доки и прочее.
Самостоятельно реализовали возможность перерендерить компонент темплейтом и значениями из любого промиса, в т.ч. ajax-запроса. К сожалению, авторы во второй версии решили выпилить form input как источник изначальных значений и это нам сильно обламывает переход на нее.
Самое крутое в этой либе — то, что она очень хорошо ложится на существующий html-код, есть привязки к нативным эвентам, атрибутам элементов и прочее. Vue гораздо легче встроить в существующий проект (по сравнению с React, Angular 2 напр.)
С тестами действительно есть проблема, но она скорее вытекает из-за того, что мы в коде X-Cart не получаем зависимости чисто. Если скрестить этот подход с получением зависимостей строго через сеттеры (через конструктор нельзя, т.к. модули могут потребовать лишние зависимости, а в PHP не получится красиво сделать несколько конструкторов) — можно писать обыкновенные тесты.
Проблему с наличием разных наборов модулей мы решаем разными сборками и параметром --group в PHPUnit. Безусловно, покрыть все комбинации не получается, так что работаем с наиболее популярными.
Понятно, я думал, что тут как в реддите, username checks out)
Их нужно очень внимательно просматривать и анализировать. Много раз ловили баги, когда сторонние модули не вызывали родительскую реализацию и в итоге твой код просто не выполнялся.
Очень знакомо и проблемы у нас те же. Действительно, нужно очень аккуратно привносить изменения и следить за побочными эффектами, зато можно это сделать куда угодно. Бывают даже кейсы, когда модуль изменяет сам себя несколько раз в зависимости от состава включенных\выключенных модуле, вот тут вообще мозг взрывается.
Правда, проблема с вызовом парента у нас довольно успешно решается конвенцией "всегда вызывай парент".
Да, система далеко не идеальная. Зато с помощью дискуссии мы вместе сможем придумать что-то более хорошее. Вы могли бы поделится примером "как лучше делать"?
Статья, содержащая в себе фразы типа "нативное наследование", изначально настраивает на недоверие
Здесь имелось ввиду использование языковой конструкции, а не какой-либо другой связи двух классов. Наверное, слово "нативное" действительно стоит опустить.
Вмешиваться в иерархию типов кажется очень сомнительной идеей. Более того, определение кто кого расширяет противоречит идее использования интерфейсов. как самих по себе так и в составе SOLID.
Данный подход никак не мешает использовать интерфейсы и соблюдать SOLID, кроме, может быть принципа открытости\закрытости. Нужно лишь перестать думать о классах-декораторах как о реальных наследниках, так как наследование там используется лишь для удобного ограничиваемого доступа к членам класса.
Не являюсь большим знатоком ворпресса, но коль уж система имеет вполне определенное назначение, что упрекать её в ограниченном наборе хуков, наверное, неуместно.
Никто не упрекает Вордпресс в ограниченности их набора хуков, речь лишь об ограничениях самого подхода. Я очень часто встречался с ситуациями, когда необходимо расширить какое-то поведение тем образом, который не предусмотрел создать оригинальной системы. В бизнесе невозможно предугадать все потенциальные точки расширения.
Выбор подхода всецело зависит от назначения системы и здесь нет идеального решения. Вордпресс такое устроило, нашу систему — нет.
А также под DI стилем имеется в виду что? Конфиги? или код? Если конфиги, то тут объяснение простое — явное указание зависимостей — это хорошая практика.
Конфиги\код — неважно, имеется ввиду использование единого Composition Root и предоставления зависимостей через конструктор или, на худой конец, сеттеры во всех классах системы.
Проблемы начинаются тогда, когда вам необходимо добавить новую зависимость в конструктор класса через модуль или же заменить реализацию сервиса. Особенно, когда одновременно несколько модулей стремятся подменить сервис своей реализацией. Популярные DI-контейнеры данную проблему абсолютно никак не решают, как и упомянул в статье. Так или иначе придется изобретать свою систему, у пресловутой Magento 2, например, также производится компиляция промежуточного класса с учетом всех модулей, которая доступна через DI и заменяет оригинальный сервис.
P.S. В статье идет речь о системах с динамическим набором модулей — плагинов, т.е. исполнение кода и функциональность системы очень сильно зависит от текущей конфигурации. Речь не о конкретном приложении, а о платформе, отсюда и вытекают все проблемы и приходится выдумывать, как скрещивать независимые куски кода правильно.
Ага, я о вас тоже в статье написал, в пункте про боевые примеры) Вам самим, кстати, нравится эта система, или, если бы можно было все отмотать назад и переделать, вы бы от нее ушли и сделали, например, на хуках?
Название статьи отличное, и мы, будучи в какой-то степени конкурентами Magento, прочитали ее не без удовольствия и даже с некоторой долей злорадства.
Однако, этот король еще долго не умрет, даже если по мнению автора его эра уже клонится к закату — даже ( если вдруг, что вряд ли) после того, как движок перестанут официально разрабатывать и поддерживать, он еще много лет будет кормить комьюнити девелоперов и фрилансеров. Все просто: многочисленные живые магазины никто махом не закроет, ибо миграция на другую незнакомую платформу со своими собственными скрытыми косяками и болячками — это уж очень трудоемкий, дорогой и рискованный процесс для бизнеса, которому каждый день простоя чреват финансовыми потерями. Поэтому как разработчик Magento, Вы еще долго сможете на этом короле зарабатывать и на хлеб, и на масло к нему.
Более того, очень вероятно, что через пару лет Magento — двойку все же полюбят искренней и чистой любовью — у нас есть свой собственный пример аналогичного «финта ушами», правда, случился он несколькими годами ранее.
Те, кто хорошо знаком с Magento и работают с западным рынком ( США, Канада, Англия в частности), наверняка слышали и про X-Cart. Как и первая Magento, X-Cart 4 с процедурным кодом развивался на протяжении многих лет, обрастал фичами, расширениями, третьесторонними девелоперами ( тем, что в Магентомире принято называть экосистемой).
Когда в 2013 году мы выкатили X-Cart 5 с MVC/OOP/Doctrine на борту, с принципиально иной архитектурой, мы столкнулись с теми же сложностями, что вторая Magento испытывает сейчас:
сильно меньше готовых расширений и внешних разработчиков, желающих изучать по сути новую платформу с довольно значительным learning curve, и эти расширения писать, так как мало клиентов
а клиентов мало было, так как было мало расширений и девелоперов.
то есть, по сути, своего рода замкнутый круг, где новое коммьюнити еще не сформировалось, а старое хейтит все новое
Когда мы показывали пятерку существующим пользователями X-Cart 4, они не сразу могли оценить новые фичи, а вот отсутствие ряда старых, которыми они активно пользовались, конечно, бросалось им в глаза. В итоге мы приняли стратегическое решение не форсить «пересаживание» клиентов на 5ку, а продолжить поддерживать X-Cart 4 для существующих пользователей, но новым предлагать в первую очередь X-Cart 5 ( при условии, что он мог решить их бизнес-задачи).
Спустя 3 года большой и планомерной работы, нам удалось «заслужить любовь» и клиентов, и разработчиков: количество продаж «новой-клевой-незнакомой» X-Cart 5 росло, росло, и в итоге в 2016 году таки превысило продажи «старой доброй» X-Cart 4. Ну, а с ростом количества клиентов, конечно, и разработческое комьюнити подтянулось. Сейчас у нас далеко не 10K расширений, но очень значительную часть основных потребностей владельца интернет-магазина они закрывают.
Что показательно, на нашем форуме уже год как перестали появляться полные печали и безнадежности посты ( вот прямо как Ваш, только на английском), а вместо них всякие you guys rock, I changed my opinion и тд — то есть произошла смена вектора в отношении комьюнити к новой платформе.
В общем, давайте посмотрим, что Вы скажете через 2-3 года, когда Le Roi хорошенько осмотрится и продолжит завоевание мира — все же, у него сейчас огромная армия «верноподданных» и нехилые бюджеты на маркетинг
… Хотя и хотелось бы под шумок отъесть у Magento кусок пирога =)
В статье очень много голословных заявлений, но ни одно из них вы даже не попытались проверить. Я не очень понимаю, почему ИИ не сможет синтезировать известные понятия на основе существующих примеров - именно так человеческие дизайнеры и поступают, они не из воздуха все эти понятия берут. Графический интерфейс имеет смысл лишь для человека, и вся обвязка вокруг (UI-киты, цветовые палитры, дизайн-системы) должна создаваться из прежде всего практических соображений - для унификации, для упрощения работы и облегчения потребности думать в процессе создания интерфейса.
Все эти вещи в какой-то степени уже описаны людьми, иначе заходить в профессию было бы невероятно сложно. Большинство проблем, которые вы описываете - это и не проблемы вовсе, это специфика, с которой вы сталкиваетесь ежедневно. Например:
Кожаный дизайнер точно также на такой "простой" запрос мне ответит "не хватает входных данных".
Вы пишете:
Я прошу ChatGPT предложить мне варианты и получаю следующее:
У ИИ вообще такой проблемы не стоит, она имеет важность лишь для вас.
ИИ в потенциале обладает гораздо большими способностями по обработке информации - в т.ч. рекомендаций и существующих примеров. Безусловно, тут нужны тестирования, но и эта сфера достаточно формализована и автоматизирована - что мешает ИИ сделать А/Б тест и выбрать наиболее рабочий вариант из подходящих условиям?
Резюмируя: да, у ИИ есть очевидные проблемы с созданием новых концепций, но в сфере обработки и модификации существующих решений под условия задачи ИИ уже хорошо справляется (даже не будучи заточенным под условия предметной области).
Затем, что PHP это не JS / DOM. Если хочется модных реактивных фреймворков на фронтенде, приходится либо отдавать JS-only контент (а это убивает SEO), либо применять SSR, чтобы рендерить те же самые компоненты на бэкенде.
Что насчет Норвегии, которая перевела чуть ли не половину автопарка на электромобили? Тоже снег 4 дня в году?
А я думаю, что автор — красавчик и желаю, что бы он далеко пошел в своем развитии и успехов. Уверен, кто-то другой из интернета обязательно будет искать больше инфы про Яндекс и его интервью и благодаря статье узнает альтернативный взгляд на ситуацию.
Копирайтинг оно или нет — мы всё равно никогда не узнаем, зато хотя бы написано читаемо и без воды.
Вы никогда не узнаете об этом напрямую, но влияние этого фактора будет. Подготовиться и эксплуатировать такие вот "подсознательные" штучки — вполне жизнеспособная стратегия, как по мне.
Вы, как мне кажется, излишне жёстки к оценке ситуации. Сколько еще было случаев в мире, когда человек с более хорошим culture fit таки прижился лучше, чем инженер с более высокими tech skills?
Нанимающий руководитель не может не оценивать это, но тут неминуемы ошибки. На этапе интервью слишком мало информации о кандидате, приходится угадывать.
По вашей же ссылке о первой имплементации говорится так:
Мне кажется, вы изобрели тикетную систему. Посмотрите на любой нормальный issue tracker — там и разные типы тикетов, и настройка полей в них, и автоматизация различного рода (валидация, cron-задачи, шаблоны и т.д.) и гораздо более широкие возможности по интеграции с чем-либо.
Я не вижу ничего автоматизированного в этом документе — вся настройка, весь процесс документирования — ручной. Поправьте меня, если я не уловил мысль.
Yandex Pay — слишком скучно. Нужно было назвать "Я Плачу", в соответствии с трендами на внедрение руссицизмов.
Я надеюсь, вы понимаете, что PSR — это всего лишь стандарт, ему можно следовать, а можно и не следовать, но его нельзя написать "нестандартизированно", "неконкретно" и т.д. На него проще смотреть, как на формальное (именно поэтому MUST капсом, это из RFC пришло) описание конвенции по работе с кодом, принятой некоторым сообществом добровольно.
Если хотите, придумайте свой стандарт, в котором можно будет ставить лишний пробел. Уберите "неважные" правила из линтера и т.д. Получайте удовлетворение от решения задач и вместе с ними ворох лишних правок в коммите, когда кто-то нажмет Reformat Code в своей любимой IDE, настроенной на свой вкус. Так можно будет легко разобраться, что относится к задаче, а что — просто форматирование существующего кода. Еще будут веселые войны за положение скобочек, табы\пробелы и так далее, и эти войны будут скрывать реальные опечатки, косяки, баги.
А если мы интеграционный тест пишем и нам не очень хочется писать кастомную логику инициализации всего дерева требуемых объектов?
То, что так можно, не означает, что так нужно делать. Код с тайп-хинтами лучше анализируется статически, предотвращает ошибки еще до запуска и тем более деплоя.
Мне кажется, современные DI-контейнеры с автовайрингом уже давно закрывают любую потребность в Service Locator, при этом никак не влияют на конечный код сервисов — он остается Plain Old название языка. Конечному коду не нужно знать об интерфейсе Локатора и особенностях использования, этот код можно перетащить куда-либо еще.
Как уже выше было верно отмечено, lazy init и возможность в рантайме переопределять сопоставление имени сервиса и его имплементации также давно реализованы в DI-контейнерах.
Мы используем Vue 1.0 в X-Cart 5 и впечатление от использования отличное, годные доки и прочее.
Самостоятельно реализовали возможность перерендерить компонент темплейтом и значениями из любого промиса, в т.ч. ajax-запроса. К сожалению, авторы во второй версии решили выпилить form input как источник изначальных значений и это нам сильно обламывает переход на нее.
Самое крутое в этой либе — то, что она очень хорошо ложится на существующий html-код, есть привязки к нативным эвентам, атрибутам элементов и прочее. Vue гораздо легче встроить в существующий проект (по сравнению с React, Angular 2 напр.)
С тестами действительно есть проблема, но она скорее вытекает из-за того, что мы в коде X-Cart не получаем зависимости чисто. Если скрестить этот подход с получением зависимостей строго через сеттеры (через конструктор нельзя, т.к. модули могут потребовать лишние зависимости, а в PHP не получится красиво сделать несколько конструкторов) — можно писать обыкновенные тесты.
Проблему с наличием разных наборов модулей мы решаем разными сборками и параметром --group в PHPUnit. Безусловно, покрыть все комбинации не получается, так что работаем с наиболее популярными.
Понятно, я думал, что тут как в реддите, username checks out)
Очень знакомо и проблемы у нас те же. Действительно, нужно очень аккуратно привносить изменения и следить за побочными эффектами, зато можно это сделать куда угодно. Бывают даже кейсы, когда модуль изменяет сам себя несколько раз в зависимости от состава включенных\выключенных модуле, вот тут вообще мозг взрывается.
Правда, проблема с вызовом парента у нас довольно успешно решается конвенцией "всегда вызывай парент".
Да, система далеко не идеальная. Зато с помощью дискуссии мы вместе сможем придумать что-то более хорошее. Вы могли бы поделится примером "как лучше делать"?
Здесь имелось ввиду использование языковой конструкции, а не какой-либо другой связи двух классов. Наверное, слово "нативное" действительно стоит опустить.
Данный подход никак не мешает использовать интерфейсы и соблюдать SOLID, кроме, может быть принципа открытости\закрытости. Нужно лишь перестать думать о классах-декораторах как о реальных наследниках, так как наследование там используется лишь для удобного ограничиваемого доступа к членам класса.
Никто не упрекает Вордпресс в ограниченности их набора хуков, речь лишь об ограничениях самого подхода. Я очень часто встречался с ситуациями, когда необходимо расширить какое-то поведение тем образом, который не предусмотрел создать оригинальной системы. В бизнесе невозможно предугадать все потенциальные точки расширения.
Выбор подхода всецело зависит от назначения системы и здесь нет идеального решения. Вордпресс такое устроило, нашу систему — нет.
Конфиги\код — неважно, имеется ввиду использование единого Composition Root и предоставления зависимостей через конструктор или, на худой конец, сеттеры во всех классах системы.
Проблемы начинаются тогда, когда вам необходимо добавить новую зависимость в конструктор класса через модуль или же заменить реализацию сервиса. Особенно, когда одновременно несколько модулей стремятся подменить сервис своей реализацией. Популярные DI-контейнеры данную проблему абсолютно никак не решают, как и упомянул в статье. Так или иначе придется изобретать свою систему, у пресловутой Magento 2, например, также производится компиляция промежуточного класса с учетом всех модулей, которая доступна через DI и заменяет оригинальный сервис.
P.S. В статье идет речь о системах с динамическим набором модулей — плагинов, т.е. исполнение кода и функциональность системы очень сильно зависит от текущей конфигурации. Речь не о конкретном приложении, а о платформе, отсюда и вытекают все проблемы и приходится выдумывать, как скрещивать независимые куски кода правильно.
Название статьи отличное, и мы, будучи в какой-то степени конкурентами Magento, прочитали ее не без удовольствия и даже с некоторой долей злорадства.
Однако, этот король еще долго не умрет, даже если по мнению автора его эра уже клонится к закату — даже ( если вдруг, что вряд ли) после того, как движок перестанут официально разрабатывать и поддерживать, он еще много лет будет кормить комьюнити девелоперов и фрилансеров. Все просто: многочисленные живые магазины никто махом не закроет, ибо миграция на другую незнакомую платформу со своими собственными скрытыми косяками и болячками — это уж очень трудоемкий, дорогой и рискованный процесс для бизнеса, которому каждый день простоя чреват финансовыми потерями. Поэтому как разработчик Magento, Вы еще долго сможете на этом короле зарабатывать и на хлеб, и на масло к нему.
Более того, очень вероятно, что через пару лет Magento — двойку все же полюбят искренней и чистой любовью — у нас есть свой собственный пример аналогичного «финта ушами», правда, случился он несколькими годами ранее.
Те, кто хорошо знаком с Magento и работают с западным рынком ( США, Канада, Англия в частности), наверняка слышали и про X-Cart. Как и первая Magento, X-Cart 4 с процедурным кодом развивался на протяжении многих лет, обрастал фичами, расширениями, третьесторонними девелоперами ( тем, что в Магентомире принято называть экосистемой).
Когда в 2013 году мы выкатили X-Cart 5 с MVC/OOP/Doctrine на борту, с принципиально иной архитектурой, мы столкнулись с теми же сложностями, что вторая Magento испытывает сейчас:
Когда мы показывали пятерку существующим пользователями X-Cart 4, они не сразу могли оценить новые фичи, а вот отсутствие ряда старых, которыми они активно пользовались, конечно, бросалось им в глаза. В итоге мы приняли стратегическое решение не форсить «пересаживание» клиентов на 5ку, а продолжить поддерживать X-Cart 4 для существующих пользователей, но новым предлагать в первую очередь X-Cart 5 ( при условии, что он мог решить их бизнес-задачи).
Спустя 3 года большой и планомерной работы, нам удалось «заслужить любовь» и клиентов, и разработчиков: количество продаж «новой-клевой-незнакомой» X-Cart 5 росло, росло, и в итоге в 2016 году таки превысило продажи «старой доброй» X-Cart 4. Ну, а с ростом количества клиентов, конечно, и разработческое комьюнити подтянулось. Сейчас у нас далеко не 10K расширений, но очень значительную часть основных потребностей владельца интернет-магазина они закрывают.
Что показательно, на нашем форуме уже год как перестали появляться полные печали и безнадежности посты ( вот прямо как Ваш, только на английском), а вместо них всякие you guys rock, I changed my opinion и тд — то есть произошла смена вектора в отношении комьюнити к новой платформе.
В общем, давайте посмотрим, что Вы скажете через 2-3 года, когда Le Roi хорошенько осмотрится и продолжит завоевание мира — все же, у него сейчас огромная армия «верноподданных» и нехилые бюджеты на маркетинг
… Хотя и хотелось бы под шумок отъесть у Magento кусок пирога =)