Мне не попадалось. Дискретная самому не нужна, но с другой стороны — а чем она вам мешает? Я ее просто отключил в настройках и всё, использую встроенную.
На iHerb таблетки по 100 мг, 30 штук в упаковке. Получается для веса, к примеру, 70 кг нужно съесть почти упаковку за два дня? Неудобная у них дозировка получается для таких экспериментов :)
Печаль вообще с этими OLED. В большинстве приличных телефонов именно они, и ладно бы только выгорание — но в нагрузку ещё и мерцание на малых яркостях (которое глазу не видно, но...).
ДанныеФормыСтруктура – содержит набор свойств произвольного типа. Свойствами могут быть другие структуры, коллекции или структуры с коллекциями. Таким типом представляется, например, в форме СправочникОбъект.
Получаем что при любом контекстном вызове передается весь объект (если хоть что-то в нем поменялось).
И это печально.
Гоняются между сервером и клиентом только диффы состояний.
Откуда информация? Просто в таком случае разницы между контекстным и безконтекстным вызовом, в случае если ничего не поменялось на форме, быть не должно. Но когда последний раз смотрел (давно), она была и заметная.
А хотя понял, в параметрах расчета там уже отфильтрованные данные и это пробег по временной таблице по сути (то все равно N+1, но «локальный»)
Это пробег по таблице в памяти (полученной ранее из большого пакетного запроса), обращения к SQL или к диску здесь нет. Т.е. формально наверное можно считать N+1, но каких-то измеримых задержек при условии обычных для документа количества строк тут не будет.
А вот если где-то неосторожно доработать код, написав к примеру:
Если Товар.Номенклатура.допИсключитьИзАкции Тогда
....
КонецЕсли;
то получим N+1 — т.к. будет обращение через точку, соответственно запрос к справочнику Номенклатуры.
Собственно в процессе оптимизации исправлял несколько таких моментов, сделанных ранее другими программистами (в типовой было всё ок).
Вы же понимаете, что пакетный запрос не решает проблему N+1.
Конечно понимаю. О чем и пишу — нет там выполнения запросов в цикле. В цикле собирается текст запроса, который потом выполняется за один раз.
Но 2,5-3,5 секунды все равно многовато, а сколько у вас объемы там были?
0,5 это было "в том числе". Посмотрел сейчас цифры — около 1,2 секунды расчет именно скидок, 2-2,5 всего чека (от нажатия кнопки "Расчет" и до завершения серверного вызова — там не только расчет скидок, ещё есть мелочи).
Объемы — в базе > 3 млн справочник клиентов (соответственно и дисконтные карты примерно в том же количестве, пусть большая часть и "мертвые" или дубли), ~300 000 SKU (активны далеко не все), ~4,5 млн строк в таблице регистра продаж (к нему идут запросы при расчете — для определения скидок за накопленный объем продаж). 306 активных скидок (сгруппированных в дерево, с условиями применения типа максимум/минимум/сумма/...).
Ну а я допиливал. Не припомню там N+1, честно говоря — там выполняется один большой пакетный запрос, дальше строится ещё более огромный пакетный запрос (по результатам первого), выполняется — и дальше без обращения к базе обрабатывается дерево скидок.
После вдумчивой оптимизации удалось довести до 2-3 секунд на расчет чека, почти всё время из этого — выполнение этих двух мегазапросов. А, ну и около 0,5 секунды на обмен данными с сервером (как минимум результирующее расчитанное дерево передается на клиента) и отрисовку формы идет.
Ну в любом случае это лучше, чем простой магазина.
Ну и учитывая, что сейчас основная схема лояльности — получаешь скидку в следующий раз (когда покупатель вернется, чтобы он собственно вернулся), падение системы лояльности это реальное ЧП
У них, если просто, то бонусная система. При покупках начисление баллов (в зависимости от товаров, акций,… разный процент), а потом баллы можно использовать как скидку. Ну вот нету связи — значит баллы и начисления персональных бонусов пока не используешь. Не так чтобы это сильно распугивало покупателей.
Кстати, посмотрел ещё раз вашу демо — по скидкам как-то печально всё, по сравнению с той же УТ11 (раз мы тут её вспоминаем). Например условия вида "купите 3 пары носков и получите 5% скидку на трусы" не увидел. Как и ограничения типа "не уйти ниже определенного типа цен", да много ещё чего. Есть просто одна небольшая сеть которые думают про замену ПО на кассах, но для них того что у вас в демо никак не хватит.
P.S. справедливости ради скидки в УТ тормозят ой-ой-ой как на объемах :)
В 21 веке? И вы реально плохо представляете, что такое FMCG в распределенных базах.
Вот кстати у одного из лидеров розницы в Украине (продукты питания) на кассах можно наблюдать обратный отсчет времени до синхронизации базы (это у них как заставка когда касса заблокирована). То есть похоже на то, что, каждая касса сама по себе, со своей локальной базой.
В современных системах лояльности вам интернет все равно нужен.
В таком случае у них не работает часть скидок, а в остальном всё хорошо. Скидки потом вроде бы доначисляют на личный счет, когда синхронизация пройдет.
Знаю я одного 1Сника. Как раз по мелким доработкам в основном занимался обычно. Сам себе и аналитик, и программист, и "тестировщик" — всё сам.
Заказчики были очень довольны — всё быстро, всё как просят. Ну подумаешь, от малейшего шага в сторону всё ломалось — он опять исправлял, и все счастливы. Кроме других разработчиков, которым приходилось что-то править в его коде.
… а в этом случае не будет действовать обещанное "1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д."
Почему же не будет? Аналитика-то отдельного нет, а задачу выполнить надо.
Так что как раз будет, т.к. нужно задачу клиента сопоставить с уже существующими объектами, подумать какие из них чуть доработать или нужно добавить новые ("какие объекты"), что клиент может захотеть дальше и как построить логику/структуру доработки чтобы это не было проблемой. Возможно предложить немного изменить задачу — чтобы меньше менять типовые объекты и таким образом уменьшить объем дальнейших работ при установке обновлений типовой конфигурации ("как оптимизировать на будущее").
Кстати, ещё видел такой вариант — задачи аналитика пытаются переложить на заказчика. Заканчивается это, правда, обычно плохо — заказчик просто ищет другого 1Сника. Хотя бывают и исключения.
Ну а где разделение ролей, там и аргументация выше теряет всякий смысл.
В том-то и дело, что это только на более-менее серьезных проектах. А там где мелкие, или берется готовая коробка и немного допиливается — пока (по крайней мере по моим наблюдениям) наиболее распространен подход "фигак-фигак и в продакшн".
Причем бизнес такому подходу радуется — решение получается быстро. Да, потом проблемы наверняка вылезут — но то будет потом.
на тот момент для работы с SOAP в 1С приходилось чуть ли не руками разбирать и собирать XML, со всеми вытекающими.
Если это была 8-ка, то нет, там оно всё легко и просто — платформа сама всё делает. Только вот стандарт они прочитали как-то по-своему, в итоге 1С <=> 1С работает отлично, а вот попытка работы с чем-то другим — это поход по граблям. Может быть и разбирали/собирали чтобы превратить XML в что-то понятное парсеру платформы.
Во-первых, хороший бизнес-аналитик и хороший специалист по тестированию — это уже две профессии, которые в одной голове плохо помещаются (и конфликтуют).
Помнится слоган 1С — "доступно и всерьез". Следствием этого является то, что разработка с использованием 1С считается недорогой, а следствием этого — вынужденное совмещение ролей. В результате имеем в одном лице посредственного бизнес-аналитика, разработчика и тестировщика (ха-ха). Есть, безусловно, исключения — но это именно исключения, а не правило.
Хотя ради справедливости в последнее время стало больше попыток внедрения нормальных подходов к разработке (а не фигак-фигак и в продакшн), а соответственно появляется и разделение ролей. Что делает результат более качественным — но, в то же время, и более дорогим.
регулярно выяснялось, что на стороне 1С случилась какая-нибудь еще ошибка в реализации нашего (стандартного!) протокола взаимодействия, и надо править с нашей стороны, потому что с их стороны — нельзя или слишком сложно, а сроки поджимают.
SOAP? :) По крайней мере именно с ним наблюдал такую ситуацию.
Интересно, они уже сделали возможность корректно обработать оповещение о нехватке памяти на Android? Корректно в данном случае — это синхронно, т.к. если обрабатывать асинхронно то система вполне может убить процесс — т.к. вызов обработчика завершился, а памяти больше не стало.
Понятно, спасибо. Тогда в принципе получается сделать можно практически все, это хорошо.
Надо будет попозже попробовать написать что-то, на практике посмотреть.
Хм… а где-то еще осталась возможность купить музыку и скачать ее себе?
Мне не попадалось. Дискретная самому не нужна, но с другой стороны — а чем она вам мешает? Я ее просто отключил в настройках и всё, использую встроенную.
Dell XPS 9570? Ну или 13" аналог.
Хм, а помыться там можно? Или только намокнуть в тумане?)
На iHerb таблетки по 100 мг, 30 штук в упаковке. Получается для веса, к примеру, 70 кг нужно съесть почти упаковку за два дня? Неудобная у них дозировка получается для таких экспериментов :)
Печаль вообще с этими OLED. В большинстве приличных телефонов именно они, и ладно бы только выгорание — но в нагрузку ещё и мерцание на малых яркостях (которое глазу не видно, но...).
Берем из вашей ссылки:
и отсюда https://its.1c.ru/db/pubdevguide83#content:550:hdoc :
Получаем что при любом контекстном вызове передается весь объект (если хоть что-то в нем поменялось).
И это печально.
Откуда информация? Просто в таком случае разницы между контекстным и безконтекстным вызовом, в случае если ничего не поменялось на форме, быть не должно. Но когда последний раз смотрел (давно), она была и заметная.
Это пробег по таблице в памяти (полученной ранее из большого пакетного запроса), обращения к SQL или к диску здесь нет. Т.е. формально наверное можно считать N+1, но каких-то измеримых задержек при условии обычных для документа количества строк тут не будет.
А вот если где-то неосторожно доработать код, написав к примеру:
то получим N+1 — т.к. будет обращение через точку, соответственно запрос к справочнику Номенклатуры.
Собственно в процессе оптимизации исправлял несколько таких моментов, сделанных ранее другими программистами (в типовой было всё ок).
А посмотреть его можно где-то? Или хотя бы почитать?
Конечно понимаю. О чем и пишу — нет там выполнения запросов в цикле. В цикле собирается текст запроса, который потом выполняется за один раз.
0,5 это было "в том числе". Посмотрел сейчас цифры — около 1,2 секунды расчет именно скидок, 2-2,5 всего чека (от нажатия кнопки "Расчет" и до завершения серверного вызова — там не только расчет скидок, ещё есть мелочи).
Объемы — в базе > 3 млн справочник клиентов (соответственно и дисконтные карты примерно в том же количестве, пусть большая часть и "мертвые" или дубли), ~300 000 SKU (активны далеко не все), ~4,5 млн строк в таблице регистра продаж (к нему идут запросы при расчете — для определения скидок за накопленный объем продаж). 306 активных скидок (сгруппированных в дерево, с условиями применения типа максимум/минимум/сумма/...).
Ну а я допиливал. Не припомню там N+1, честно говоря — там выполняется один большой пакетный запрос, дальше строится ещё более огромный пакетный запрос (по результатам первого), выполняется — и дальше без обращения к базе обрабатывается дерево скидок.
После вдумчивой оптимизации удалось довести до 2-3 секунд на расчет чека, почти всё время из этого — выполнение этих двух мегазапросов. А, ну и около 0,5 секунды на обмен данными с сервером (как минимум результирующее расчитанное дерево передается на клиента) и отрисовку формы идет.
Ну в любом случае это лучше, чем простой магазина.
У них, если просто, то бонусная система. При покупках начисление баллов (в зависимости от товаров, акций,… разный процент), а потом баллы можно использовать как скидку. Ну вот нету связи — значит баллы и начисления персональных бонусов пока не используешь. Не так чтобы это сильно распугивало покупателей.
Кстати, посмотрел ещё раз вашу демо — по скидкам как-то печально всё, по сравнению с той же УТ11 (раз мы тут её вспоминаем). Например условия вида "купите 3 пары носков и получите 5% скидку на трусы" не увидел. Как и ограничения типа "не уйти ниже определенного типа цен", да много ещё чего. Есть просто одна небольшая сеть которые думают про замену ПО на кассах, но для них того что у вас в демо никак не хватит.
P.S. справедливости ради скидки в УТ тормозят ой-ой-ой как на объемах :)
Вот кстати у одного из лидеров розницы в Украине (продукты питания) на кассах можно наблюдать обратный отсчет времени до синхронизации базы (это у них как заставка когда касса заблокирована). То есть похоже на то, что, каждая касса сама по себе, со своей локальной базой.
В таком случае у них не работает часть скидок, а в остальном всё хорошо. Скидки потом вроде бы доначисляют на личный счет, когда синхронизация пройдет.
Знаю я одного 1Сника. Как раз по мелким доработкам в основном занимался обычно. Сам себе и аналитик, и программист, и "тестировщик" — всё сам.
Заказчики были очень довольны — всё быстро, всё как просят. Ну подумаешь, от малейшего шага в сторону всё ломалось — он опять исправлял, и все счастливы. Кроме других разработчиков, которым приходилось что-то править в его коде.
Почему же не будет? Аналитика-то отдельного нет, а задачу выполнить надо.
Так что как раз будет, т.к. нужно задачу клиента сопоставить с уже существующими объектами, подумать какие из них чуть доработать или нужно добавить новые ("какие объекты"), что клиент может захотеть дальше и как построить логику/структуру доработки чтобы это не было проблемой. Возможно предложить немного изменить задачу — чтобы меньше менять типовые объекты и таким образом уменьшить объем дальнейших работ при установке обновлений типовой конфигурации ("как оптимизировать на будущее").
Кстати, ещё видел такой вариант — задачи аналитика пытаются переложить на заказчика. Заканчивается это, правда, обычно плохо — заказчик просто ищет другого 1Сника. Хотя бывают и исключения.
В том-то и дело, что это только на более-менее серьезных проектах. А там где мелкие, или берется готовая коробка и немного допиливается — пока (по крайней мере по моим наблюдениям) наиболее распространен подход "фигак-фигак и в продакшн".
Причем бизнес такому подходу радуется — решение получается быстро. Да, потом проблемы наверняка вылезут — но то будет потом.
Если это была 8-ка, то нет, там оно всё легко и просто — платформа сама всё делает. Только вот стандарт они прочитали как-то по-своему, в итоге 1С <=> 1С работает отлично, а вот попытка работы с чем-то другим — это поход по граблям. Может быть и разбирали/собирали чтобы превратить XML в что-то понятное парсеру платформы.
Помнится слоган 1С — "доступно и всерьез". Следствием этого является то, что разработка с использованием 1С считается недорогой, а следствием этого — вынужденное совмещение ролей. В результате имеем в одном лице посредственного бизнес-аналитика, разработчика и тестировщика (ха-ха). Есть, безусловно, исключения — но это именно исключения, а не правило.
Хотя ради справедливости в последнее время стало больше попыток внедрения нормальных подходов к разработке (а не фигак-фигак и в продакшн), а соответственно появляется и разделение ролей. Что делает результат более качественным — но, в то же время, и более дорогим.
SOAP? :) По крайней мере именно с ним наблюдал такую ситуацию.
Интересно, они уже сделали возможность корректно обработать оповещение о нехватке памяти на Android? Корректно в данном случае — это синхронно, т.к. если обрабатывать асинхронно то система вполне может убить процесс — т.к. вызов обработчика завершился, а памяти больше не стало.
Понятно, спасибо. Тогда в принципе получается сделать можно практически все, это хорошо.
Надо будет попозже попробовать написать что-то, на практике посмотреть.