Sly32: Эластик как раз в данном случае меньшее зло - он стоит но не используется - нет пока необходимости, это задел на будущее, Сейчас все через стандартный ORM
Куда уж меньшее зло, тянуть на сервер штуку, которая жрет 40% всей памяти сервера и не используется при этом?
Зачем такой задел на будущее, если добавить - дело 15 минут с перекурами?
---------- Добавлено 27.03.2019 в 12:08 ----------
Sly32: Эластик как раз в данном случае меньшее зло - он стоит но не используется - нет пока необходимости, это задел на будущее, Сейчас все через стандартный ORM
Куда уж меньшее зло, тянуть на сервер штуку, которая жрет 40% всей памяти сервера и не используется при этом?
Зачем такой задел на будущее, если добавить - дело 15 минут с перекурами?
A machine with 64 GB of RAM is the ideal sweet spot, but 32 GB and 16 GB machines are also common. Less than 8 GB tends to be counterproductive (you end up needing many, many small machines)
Вас не смущает, что у вас в 8 раз меньше чем рекомендованный минимум?
На 1GB машине нужно тюнить хип, про который вы скорее всего даже не знаете. Через n поисков эластик скушает всю память и упадет.
Aisamiery, не совсем понял как мы пришли к тому, что каждый начал скидывать количество строк в таблице. И что нам даст запрос, который никогда не выполняется, по таблице, которая используется только менеджерами?
melkozaur, какие проблемы в нескольких сотнях стилей? Современная веб разработка подразумевает использование компонентов, где ты описываешь блок, описываешь его функциональность, и снизу стили применимые к этому блоку. Если блок фигурирует на странице, то он загружается динамически, вместе со стилями. Если нет - то нет. Это удобно и быстро. Стили грузятся один раз, при правильной настройке сервера. Потом они лежат в кеше браузера. Другой вопрос, что их больше 1MB, и они совсем не сжаты. Но это уже вопрос к разработчикам Eldorado.
suffix: Композит только для простых, маленьких проектов на слабом железе.
Почему? На сколько я помню, это какое-то сверх-крутое кеширование в статику блоков и инвалидация только того, что изменилось на самом деле. Чем кеширование может повредить большому проекту?
melkozaur: Странно, что дебилы почему-то все, кроме битриксоидов. Вам прививки что ли делают против дебилизма, или как объяснить этот курьез?
Дебилы есть везде. Их количетсво определяет порог вхождения. Это закономерно: чем проще вкатится в нишу, тем ниже уровень знаний требуется, тем хуже качество предоставляемых услуг.
melkozaur: правда в том, что владельцу надо продавать, а не выстраивать архитектуру.
Правда в том, что нужно учитывать все требования и прислушиваться к компетентным людям, а не брать на себя их обязаности. Нахер нам эта архитектура, потом сделаем. Зачем нам этот бухгалтер и документы, потом займемся. Ой, да ну нафига ждать пока фундамент сядет, можно строить уже, сроки горят. Читайте эти и другие высказывания в книге "Как я ради краткосрочной перспективы похерил долгосрочную".
Владельцу нужно продавать, разработчикам нужно иметь возможность быстро и эффективно изменять логику под требования бизнеса, и чтобы все это не сломалось из-за кривой архитектуры, бухгалтерам нужно иметь бумажку на каждый чих, потому что поговорка "чем больше бумаги, тем чище жопа" до сих пор актуальна в юридическом контексте.
melkozaur, есть проекты, дизайн (я про паттерны кода) которого обязывает вписываться в архитектуру приложения, следовать хорошим практикам или практикам конкретного приложения. В опенкарте единственное что есть - это MVC. Все. И наговнякать там намного проще.
Если взять какого-то дебила программиста, сказать ему сделай мне быстрый заказ в карточке с товаром, и дать ему OpenCart и Magento, то на OpenCart он таки прикрутит сбоку этот костыль. В магенто он даже не поймет как она работает, куда вставлять свой говноjs чтобы он подключился на странице, в какую таблицу сохранять заказы, их там около 300.
Категорически не советую брать OpenCart. Архитектура поощряющаяя костыли. Низкая квалификация разработчиков. Через год проект превратится в франкенштейна где каждая правка ломает пол сайта.
Присмотритесь к Sylius например. Раньше он был open source, сейчас не знаю.
Sly32, покажи
Эластик как раз в данном случае меньшее зло - он стоит но не используется - нет пока необходимости, это задел на будущее, Сейчас все через стандартный ORM
Куда уж меньшее зло, тянуть на сервер штуку, которая жрет 40% всей памяти сервера и не используется при этом?
Зачем такой задел на будущее, если добавить - дело 15 минут с перекурами?
---------- Добавлено 27.03.2019 в 12:08 ----------
Эластик как раз в данном случае меньшее зло - он стоит но не используется - нет пока необходимости, это задел на будущее, Сейчас все через стандартный ORM
Куда уж меньшее зло, тянуть на сервер штуку, которая жрет 40% всей памяти сервера и не используется при этом?
Зачем такой задел на будущее, если добавить - дело 15 минут с перекурами?
Джанго+ Постгрес+ мемкэшед+ селери +раббит+ эластиксерч
Вырезка с официальной доки по эластику:
Вас не смущает, что у вас в 8 раз меньше чем рекомендованный минимум?
На 1GB машине нужно тюнить хип, про который вы скорее всего даже не знаете. Через n поисков эластик скушает всю память и упадет.
Aisamiery, не совсем понял как мы пришли к тому, что каждый начал скидывать количество строк в таблице. И что нам даст запрос, который никогда не выполняется, по таблице, которая используется только менеджерами?
melkozaur, какие проблемы в нескольких сотнях стилей? Современная веб разработка подразумевает использование компонентов, где ты описываешь блок, описываешь его функциональность, и снизу стили применимые к этому блоку. Если блок фигурирует на странице, то он загружается динамически, вместе со стилями. Если нет - то нет. Это удобно и быстро. Стили грузятся один раз, при правильной настройке сервера. Потом они лежат в кеше браузера. Другой вопрос, что их больше 1MB, и они совсем не сжаты. Но это уже вопрос к разработчикам Eldorado.
Композит только для простых, маленьких проектов на слабом железе.
Почему? На сколько я помню, это какое-то сверх-крутое кеширование в статику блоков и инвалидация только того, что изменилось на самом деле. Чем кеширование может повредить большому проекту?
зачем вы вообще в этом топике?
Только не надо решать кому быть в этом топике, а кому не быть, вам это не по силам)
Все же по архитектуре я вижу ответить нечего
Мне есть что ответить, я просто не вижу смысла.
понимание, что архитектура не нужна, у вас есть.
У меня такого понимания нет, но главное что у вас оно есть.
Я не увидел преимуществ. Вижу только попытки назвать всех, кто не строит магазины в Битриксе, дебилами.
У вас либо большой талант, либо начало шизофрении. Вы видите то, чего нет.
danforth, вы плохой продавец.
Я где-то говорил, что я хороший продавец, или, тем-более, что я что-то продаю?
Если подтянете навык переговоров, очевидно будете продавать больше.
Отличный совет человеку, который ничего не продает.
Т.е. архитектура ваших продаж не то что страдает, ее просто нет.
Это туда же.
Вы фрилансер или в компании работаете?
У вас какое образование?
Учитывая то, что я не люблю битрикс где-то так-же, как и OpenCart, ваши выпады кажутся мне странными, как будто вы меня с кем-то спутали.
Странно, что дебилы почему-то все, кроме битриксоидов. Вам прививки что ли делают против дебилизма, или как объяснить этот курьез?
Дебилы есть везде. Их количетсво определяет порог вхождения. Это закономерно: чем проще вкатится в нишу, тем ниже уровень знаний требуется, тем хуже качество предоставляемых услуг.
правда в том, что владельцу надо продавать, а не выстраивать архитектуру.
Правда в том, что нужно учитывать все требования и прислушиваться к компетентным людям, а не брать на себя их обязаности. Нахер нам эта архитектура, потом сделаем. Зачем нам этот бухгалтер и документы, потом займемся. Ой, да ну нафига ждать пока фундамент сядет, можно строить уже, сроки горят. Читайте эти и другие высказывания в книге "Как я ради краткосрочной перспективы похерил долгосрочную".
Владельцу нужно продавать, разработчикам нужно иметь возможность быстро и эффективно изменять логику под требования бизнеса, и чтобы все это не сломалось из-за кривой архитектуры, бухгалтерам нужно иметь бумажку на каждый чих, потому что поговорка "чем больше бумаги, тем чище жопа" до сих пор актуальна в юридическом контексте.
melkozaur, есть проекты, дизайн (я про паттерны кода) которого обязывает вписываться в архитектуру приложения, следовать хорошим практикам или практикам конкретного приложения. В опенкарте единственное что есть - это MVC. Все. И наговнякать там намного проще.
Если взять какого-то дебила программиста, сказать ему сделай мне быстрый заказ в карточке с товаром, и дать ему OpenCart и Magento, то на OpenCart он таки прикрутит сбоку этот костыль. В магенто он даже не поймет как она работает, куда вставлять свой говноjs чтобы он подключился на странице, в какую таблицу сохранять заказы, их там около 300.
Категорически не советую брать OpenCart. Архитектура поощряющаяя костыли. Низкая квалификация разработчиков. Через год проект превратится в франкенштейна где каждая правка ломает пол сайта.
Присмотритесь к Sylius например. Раньше он был open source, сейчас не знаю.