Он же под капотом просто создает отдельный тред не в тредпуле. Собственно в коде выше сделано аналогично.
А вот что действительно странно, что автор не выставил параметр IsBackground для потока. В его случае программа фактически завершится, когда поток будет остановлен. А т.к. там бесконечный цикл - прервать программу можно будет только убив процесс.
Transient уничтожается только когда scope, в рамках которого он был создан, будет уничтожен. В документации почти все верно написано, только не конкретизировано. На каждый request создается scope, поэтому transient зависимости будут нормально уничтожаться после завершения запроса.
Но если объект будет создан в рамках глобального скоупа самого контейнера, то и уничтожен он будет только когда контейнер уничтожат.
Косвенные данные. Например на карточке товара на WB есть информация "Купили более X раз" ну и цена. Если через определенный интервал парсить ее, то инкрементно можно примерную оценку получить.
С озоном сложнее там подобной информации на странице нету. Как данные хотя бы немного приближенные к объективным по нему собирают - сложно представить.
p.s. Возможно что собирают с каких-то сторонних плагинов для браузеров, которые типа как скидочные устанавливают пользователи. Но это тоже косвенная информация - там сложно объективности добиться хорошей.
Большое заблуждение, что продуктовые команды не сталкиваются с технологическими вызовами. Платформа это все же набор общих решений, благодаря которым можно не тратить много времени на проработку инфраструктурных слоев своего сервиса, однако для каждого конкретного сервиса всегда будут специфические кейсы, которых в платформе нет и быть не может.
Платформа не придумывает алгоритмы для логистики, складов, для сервисов типа стоков и информации о товарах и т.п. Платформа не пишет оптимальные sql запросы в шардированном окружении. Платформа не занимается анализом hotpath и не ищет утечки памяти. Платформа не оптимизирует выделения памяти, не уменьшает потребление CPU и т.п. Этим всем занимаются именно продуктовые команды. Но да! Платформы дает больше средств для диагностики своих сервисов и, конечно, помогает командам, если у них возникают проблемы, для решения которых у них вдруг не хватает экспертизы.
У вас не идентичный код, что выше привели вы. У вас не только изменение в объявлении, но и само присваивание для eof совершенно подругому описано. Ваша проблема может состоять в том, что для вычисления eof переменная S уже ушла из кеша процессора например
Сканером пользуются, т.к. функционала в самом веб-приложении существенно больше
Пикнуть сканером посылку - все равно удобнее и быстрее, особенно когда их проходит 200-300 штук, а надо за час все обработать.
Как Сергей написал выше, приложение самый незаменимый вариант, если вдруг отключился свет или основная линия интернета упала. Приемка и выдача идут без перебоев
AddScoped
Scoped — сервис создаются единожды для каждого запроса.
Это слишком частный случай. По сути сервис создается и живет в рамках какого-то scope. Запрос в aps.net является таким скоупом. Но ничего не запрещает создать свой скоуп, где сервис можно вызывать несколько раз и его жизненный цикл будет ограничен именно этой область.
Заказ <> товар. Не говоря уже о том, что вы похоже, один из тех кто забивает озон фейковыми заказами, блокируя продажи арктикулов товаров у нормальных селлеров.
short-circuiting — а откуда вы взяли что это переводится просто как «замыкание»? Сам термин имеет несколько иное значение и убирать из него значимое второе слово, коренным образом меняет его смысл. Т.к. под замыканием в .net понимается несколько иной механизм.
Теперь понятно, почему уже на протяжении стольких лет, сайт до сих пор не может запомнить моего местоположения и редиректнуть на нужный поддомен. Вы просто играетесь с технологиями. :)
Потому-что часть логистической цепочки еще на старой платформе работает, а там расчет всего маршрута строиться сразу, как создается заказ. Проблема не столько адрес поменять, сколько без проблем всю цепочку маршрута перестроить. :(
Площадь теплообменника я точно не знаю. Но, пожалуй, что тут важно другое, что величина КПД — зависит не только от площади теплообмена, а еще и от пары тройки данных, которые влияют на другие важные параметры (типа скорости воздухообмена и т.п.). Тут практически аналогия с CAP-теоремой :) Ну т.е. можно задрать КПД до 90-80, но пострадает уровень CO, если вы находитесь в помещении и т.п. В этой части, например, VAC системы более оптимальны. Когда реально воздухобмен не нужен сильный (все на работе) — КПД теплообмена высокий.
Ну вот сходу, максимальный КПД у бытовых рекуператоров он в реальности не достижим. Как пример диаграмма одного из самых доступных electrolux star epvs-650. т.е. что бы подобраться к максимальному КПД, по факту практически прекратить почти весь обмен воздухом. В обычной эксплуатации — этот параметр ну дай бог что бы до 65% добрался.
Озон банк спокойно перевод с карты на карту Kaspi за несколько секунд.
Скорее всего содержит в себе словарик со счетчиками. И считает нагрузку от себя на другие сервисы.
Он же под капотом просто создает отдельный тред не в тредпуле. Собственно в коде выше сделано аналогично.
А вот что действительно странно, что автор не выставил параметр IsBackground для потока. В его случае программа фактически завершится, когда поток будет остановлен. А т.к. там бесконечный цикл - прервать программу можно будет только убив процесс.
Transient уничтожается только когда scope, в рамках которого он был создан, будет уничтожен. В документации почти все верно написано, только не конкретизировано. На каждый request создается scope, поэтому transient зависимости будут нормально уничтожаться после завершения запроса.
Но если объект будет создан в рамках глобального скоупа самого контейнера, то и уничтожен он будет только когда контейнер уничтожат.
Косвенные данные. Например на карточке товара на WB есть информация "Купили более X раз" ну и цена. Если через определенный интервал парсить ее, то инкрементно можно примерную оценку получить.
С озоном сложнее там подобной информации на странице нету. Как данные хотя бы немного приближенные к объективным по нему собирают - сложно представить.
p.s. Возможно что собирают с каких-то сторонних плагинов для браузеров, которые типа как скидочные устанавливают пользователи. Но это тоже косвенная информация - там сложно объективности добиться хорошей.
Могу ответить на 2 вопрос.
Большое заблуждение, что продуктовые команды не сталкиваются с технологическими вызовами. Платформа это все же набор общих решений, благодаря которым можно не тратить много времени на проработку инфраструктурных слоев своего сервиса, однако для каждого конкретного сервиса всегда будут специфические кейсы, которых в платформе нет и быть не может.
Платформа не придумывает алгоритмы для логистики, складов, для сервисов типа стоков и информации о товарах и т.п. Платформа не пишет оптимальные sql запросы в шардированном окружении. Платформа не занимается анализом hotpath и не ищет утечки памяти. Платформа не оптимизирует выделения памяти, не уменьшает потребление CPU и т.п. Этим всем занимаются именно продуктовые команды. Но да! Платформы дает больше средств для диагностики своих сервисов и, конечно, помогает командам, если у них возникают проблемы, для решения которых у них вдруг не хватает экспертизы.
У вас не идентичный код, что выше привели вы. У вас не только изменение в объявлении, но и само присваивание для eof совершенно подругому описано. Ваша проблема может состоять в том, что для вычисления eof переменная S уже ушла из кеша процессора например
У автора там "опечатка" или хз как ее назвать. Если ее убрать - скомпилированный код будет идентичный. SharpLab
Сканером пользуются, т.к. функционала в самом веб-приложении существенно больше
Пикнуть сканером посылку - все равно удобнее и быстрее, особенно когда их проходит 200-300 штук, а надо за час все обработать.
Как Сергей написал выше, приложение самый незаменимый вариант, если вдруг отключился свет или основная линия интернета упала. Приемка и выдача идут без перебоев
Это слишком частный случай. По сути сервис создается и живет в рамках какого-то scope. Запрос в aps.net является таким скоупом. Но ничего не запрещает создать свой скоуп, где сервис можно вызывать несколько раз и его жизненный цикл будет ограничен именно этой область.