На самом деле проблемы оффсетной пагинации куда глобальнее чем кажутся на первый взгляд. Предположим мы уже отфильтровали данные и показали их клиенту. Пока клиент смотри на эти данные были добавлены новые записи в первую страницу. Тогда произойдет сдвиг данных и на второй странице возможно окажутся те же записи, что были и на первой. А если на UI стороне отображение реализовано в виде авто подгрузке по доскролу то клиент увидит задвоение некоторых данных. Курсорная пагинация не обладает подобной проблемой. Новые записи которые были добавлены на первую страницу вообще не попадут в выдачу клиента, до обновления первой страницы.
В одном из проектов как раз реализовывал подобную курсорную пагинацию правда она там была в обе стороны. Обычно при долгой прокрутке страницы, с доскролом, на странице начнет отображаться так много записей что сама страница начнет тормозить и подлагивать. Чтобы этого избежать курсорная подгрузка реализована в обе стороны: при подгрузке третей и более страницы верхние данные удаляются. И наоборот. При прокрутке на верх подгружаются записи которые были удалены ранее, а снизу записи стираются.
А как сделано у вас. Курсоры в обе стороны или только в одну?
Статья о том, что автор не внимательно читал документацию. Но потом автор прочитал документацию и узнал о stopPropagation(). Могу порекомендовать написать статью о preventDefault() и stopImmediatePropagation().
Это аы еще прикрепленный матераил не проверяли. Сейчас не проверял, но раньше было, что если я загружу фотографию, а потом удалю, то по прямой ссылке на сам файл она так и останется на веки лежать в хранилище VK.
Задался я как то раз целью вращать коллекторный двигатель с подключенным энкодером так, чтобы максимально точно возвращать его и уметь возвращать ровно на заданное число оборотов. И тоже стал решать эту задачу с нуля. И что я могу сказать - без тестирования кода, наверно у меня бы ушло на решение этой задачи год. Хотя казалось бы, что тут сложного, нужно лишь в точное время включить двигатель и в точное выключить, а потом проделать тоже самое только обратно. Но есть нюанс.
После того как мне удалось отделить бизнес логику, которая крутилась на ардуино отделить в отдельную библиотеку, дело стронулось с места. Эта библиотека была покрыта тестами, которые поражали своей извращенность. Но в реальности такое ведь может произойти. В реальности датчик может начать выдавать данные которые для него не характерны. Так было в нескольких авариях с самолетами, когда самолет задирал нос, терял скрость и падал штопором. Почему такое произошло? Потому что датчик тангажа начинал врать.
Поэтому главный принцип бизнес логики - не верю никому. Чуть что-то начало присылать странные данные - используем дефолтные значения или переходим к плану Б. Чуть что-то пошло не так - падача питания на двигатель есть а движения энкодера нет - все выключить с выводом ошибки.
Сами сигналы с датчиком можно легко записать в логи и потом покрытть тестами и эти данные. Тогда сразу будет видно - вообще живой ли датчик. Адекватные ли данные он присылает.
Калибровка - тоже не маловажная часть любого подобного проекта. Если нужно то можно делать ее каждый раз перед запуском. Что-то можно откалибровать уже находу.
Короткая 3х секундная программа калибровки уже ввоздухе смоглабы много узнать о реальных показателях коптера. 3 секунды для микрокомпьютера просто бездна времени для сбора данных и их анализа.
Ну и конечно основа основ - юнит тесты! Без них очень сложно сделать поистени сложные вещи. Ардуина или будь то STM32 просто принимает данные с датчиков и передает их в бизнеслогику. Бизнес логика обрабатывает данные и выдает уровни газа для моторов. Безнес логика пакуется в отедельную библиотеку и покрывается юнит тестами. В таких тестах мы можем легко эмулировать перемещение во времени и показания самих датчиков. В идиальных условиях Бизнес логика должны на любые эти изменения уметь реагировать и делать то что нужно.
Вопрос про разбор математического выражения конечно улыбнул. Помню как в институте писал как раз похожий парсер, который разбирал подобные выражения и решал их: "приведение к нормальной форме" - кажется так это называется. Но с ходу в уме сообразить вот прям на собесе, может уже и не вспомню. Надо загуглить, почитать, и после этого будет результат.
Это я к чему? Что кандидат может элементарно забыть что то. Но помнить где это искать в случае необходимости.
Ну а то что проинтервьюировали столько кандидатов и не нашли нужного ну тут явно что-то не так. С теми, кто интервьюировал. Или с теми кто искал кандидатов, раз набрали одних тимлидов да директоров вместо сеньоров.
Зачем отправлять запросы при Polling методе каждые 2 секунды, если сам по себе Polling метод подразумевает, что сервер как бы ждет некоторое время и держит соединение не отдавая его содержимое, пока данные не появятся?
Это тогда не Polling получается а какой Getting.
Когда делал своего бота (не на пайтоне), как раз использовал этот подход. Делаю запрос на сервер телеграмм с ожиданием в 30 секунд, если ответа не последовало, сбрасываю соединение и снова делаю новый запрос. Получается один запрос в 30 секунд что не так часто.
Ну по ссылки как бы все понятно, что автор комментария создал приватный email да еще и не читал видимо его некоторое время, но все ждал, когда ему что-то там пришлют. Потом когда он это прочитал, уже наступил 2023 год и типо отправка прекращена. Но значит должен был быть сделан возврат, раз отправка прекращена. Был ли сделан возврат? По ссылке этого не написано. Если возврата не было сделано и товар не был отправлен, то автор комментария правильно пишет: "мы в одностороннем порядке прикарманили ваши деньги".
Надо вспомнить, что когда только эти самые веб-компоненты появились, ими можно было пользоваться разве что для каких то демок поиграться. Были разные реализации в разных браузерах. Это все вставляло палки в колеса разработки. А потом появился React. И только потом настала смерть IE, а вместе с этим наступила эра когда веб-компоненты начали поддерживаться всеми браузерами. Но сейчас уже 2023 год, и вот я задаюсь вопросом, а что могут сделать веб-компоненты, что не может React? Shadow DOM у них есть, а если он мне не нужен?
Мне кажется, что React как раз и послужил этаким "убийцей" веб-компонентов. Из мира React мне не разу не пригодилась эта технология. А любой велосипед можно сделать и на React, получится React-компонент.
А вот не в мире React, когда я тут что-то сделал, но я не хочу чтобы другие стили на сайте у меня тут все не поломали, дай-ка я засуну все это в веб-компонент - Shadow DOMом едины. Такой подход имеет место быть. Но здесь же очевидны и другие проблемы, более высокого уровня, архитектурные.
На данный момент мне непонятно каким образом у многих тренирующихся не сгорают мышцы от аэробных нагрузок и растет и скорость бега, и дистанция, и пульсовая стоимость падает.
Потому что они правильно питаются. Вы не слова про это не сказали, а это куда важнее чем сами беговые треннировки. "Скажи мне что ты еш и я скажу что из тебя выйдет" - гласит народная мудрость (на самом деле сам придумал). Во вторых бег это не лучший вид спорта для увеличения мышечной массы. Скорее даже наоборот, в процессе интенсивного бега мышечная масса убывает.
Хотите бегать и чтобы ноги росли - нужно добавлять нагрузку на ноги - это либо утежелители на ноги либо бегать в горку. Первое время надо быть осторожным с нагрузкой на сердце, можно и в космос улететь.
Но без правильного питания организму просто не из чего будет восстанавливать мышцы, а так же наращивать новые. Представьте себе стройку, прораб говорит: "Стройте дом", а кирпича то нет. Из чего строить? Поэтому 2.5 грамма белка на массу тела в день надо в себя запихнуть.
Сколько вы там сказали весите, 83? Это почти 800 грамм говядины каждый день! Конечно есть одну говядину необязательно, есть и другие продукты с высоким содержанием белка)))
А если завтра курс бакса станет 200р - неужели не понятно что работать из-за границы на Россию станет невыгодно? Неужели не понятно, что платить зарплату сотрудникам за границей компании не выгодно без привязки к рублю с текущим "широко" плавающим курсом?
Вам дали возможность релоцироваться на таких же условиях. Вы ей воспользовались. Ну а дальше то куда смотрели? Ждали своего черного лебедя? Вот он к вам и пришел. Если бы смотрели на сторону то давно бы уже нашли работу чтобы зп была в валюте. Тем более что уже релоцировались в Армению. Но это не путь настоящего самурая. Настоящий самурай сначала будет тихонечко ликовать, что по одному курсу он получает запрплату больше рынка, а потом будет писать жалобные статьи на хабре, мол у авито денег полно, а они вот тут мне зп сокращают.
А ходить и жаловаться и считать чужие доходы такой себе удел...
Сервопривод вовсе не означает что нужно использовать шаговый двигатель. В большинстве сервоприводов отлично справляются обычные коллекторные двигатели. В сочитании с хорошим энкодером устройство получается надежным и точным. Все зависит от поставленной задачи, но все равно если речь идет про умный дом то шаговые двигатели нужны не так уж и часто. Открытие ворот, запорные краны, жалюзи и прочие вещи можно легко обойтись без шаговых двигателей. Поэтому вопрос целесообразности использования шагового двигателя в конкретном случае для меня остается открытым.
Я думаю ваша версия устройства, выйдет столько же по цене или даже дороже, даже если оно будет без экрана. Потому что 80-90% расходов будет составлять ПО. Приложение же будет бесплатное, а в нем нужно огого сколько интерфейсов наделать да все это протестировать, да все это с другим девайсом через блютуз и асинхронно. Да в добавок приложения нужно два. А потом когда выкатится новая версия прошивки на устройство, нужно будет еще и старые поддерживать и новые. Поэтому этот путь интересен в плане удобство ношения, но за все надо платить. Дерзайте и что-то обязательно получится.
Слушайте, ну вы такие классные советы раздаете и возможно мой вопрос будет уже какой-нибудь 101, но все таки хочется узнать: что надо сделать, чтобы развалить сеть ночных клубов?
Интересно, долго еще 1С будет считать что их генерируемые запросы идеальны и не позволять их переписывать "на лету", заставляя прибегать к каким то кастылям, в виде промежуточных решение, вместо того чтобы позволить в самой платформе сделать подмену, например, как это сделано в Entity Framework?
Ваша история мне чем то напомнило мою историю, когда мне тоже пришлось расширять базовый функционал. Тогда меня не устроило, как работает LIKE %текст% .
Я думаю что предыдущий комментарий был отсылкой к тому, что в HTML часто для разметки стилей используют просто классы, а не атрибуты, как у вас. Исторически было так что стили на атрибутах работают медленее чем на классах, но как сейчас обстоят дела с производительностью стилей на атрибутах я не знаю. К теме странного поведения overflow-y: auto это не имеет никакого отношения.
Grid как раз и был создан для того чтобы решать подобные проблемы и отлично решает их. Flex - это как бы 1D (либо по горизонтали/либо по вертикали), а Grid - это как бы 2D (и по горизонтали и по вертикали).
На самом деле проблемы оффсетной пагинации куда глобальнее чем кажутся на первый взгляд. Предположим мы уже отфильтровали данные и показали их клиенту. Пока клиент смотри на эти данные были добавлены новые записи в первую страницу. Тогда произойдет сдвиг данных и на второй странице возможно окажутся те же записи, что были и на первой. А если на UI стороне отображение реализовано в виде авто подгрузке по доскролу то клиент увидит задвоение некоторых данных. Курсорная пагинация не обладает подобной проблемой. Новые записи которые были добавлены на первую страницу вообще не попадут в выдачу клиента, до обновления первой страницы.
В одном из проектов как раз реализовывал подобную курсорную пагинацию правда она там была в обе стороны. Обычно при долгой прокрутке страницы, с доскролом, на странице начнет отображаться так много записей что сама страница начнет тормозить и подлагивать. Чтобы этого избежать курсорная подгрузка реализована в обе стороны: при подгрузке третей и более страницы верхние данные удаляются. И наоборот. При прокрутке на верх подгружаются записи которые были удалены ранее, а снизу записи стираются.
А как сделано у вас. Курсоры в обе стороны или только в одну?
А я то как рад - самого автора $mol-а развеселил. А за умника, спасибо!
Статья о том, что автор не внимательно читал документацию. Но потом автор прочитал документацию и узнал о stopPropagation(). Могу порекомендовать написать статью о preventDefault() и stopImmediatePropagation().
Это аы еще прикрепленный матераил не проверяли. Сейчас не проверял, но раньше было, что если я загружу фотографию, а потом удалю, то по прямой ссылке на сам файл она так и останется на веки лежать в хранилище VK.
Задался я как то раз целью вращать коллекторный двигатель с подключенным энкодером так, чтобы максимально точно возвращать его и уметь возвращать ровно на заданное число оборотов. И тоже стал решать эту задачу с нуля. И что я могу сказать - без тестирования кода, наверно у меня бы ушло на решение этой задачи год. Хотя казалось бы, что тут сложного, нужно лишь в точное время включить двигатель и в точное выключить, а потом проделать тоже самое только обратно. Но есть нюанс.
После того как мне удалось отделить бизнес логику, которая крутилась на ардуино отделить в отдельную библиотеку, дело стронулось с места. Эта библиотека была покрыта тестами, которые поражали своей извращенность. Но в реальности такое ведь может произойти. В реальности датчик может начать выдавать данные которые для него не характерны. Так было в нескольких авариях с самолетами, когда самолет задирал нос, терял скрость и падал штопором. Почему такое произошло? Потому что датчик тангажа начинал врать.
Поэтому главный принцип бизнес логики - не верю никому. Чуть что-то начало присылать странные данные - используем дефолтные значения или переходим к плану Б. Чуть что-то пошло не так - падача питания на двигатель есть а движения энкодера нет - все выключить с выводом ошибки.
Сами сигналы с датчиком можно легко записать в логи и потом покрытть тестами и эти данные. Тогда сразу будет видно - вообще живой ли датчик. Адекватные ли данные он присылает.
Калибровка - тоже не маловажная часть любого подобного проекта. Если нужно то можно делать ее каждый раз перед запуском. Что-то можно откалибровать уже находу.
Короткая 3х секундная программа калибровки уже ввоздухе смоглабы много узнать о реальных показателях коптера. 3 секунды для микрокомпьютера просто бездна времени для сбора данных и их анализа.
Ну и конечно основа основ - юнит тесты! Без них очень сложно сделать поистени сложные вещи. Ардуина или будь то STM32 просто принимает данные с датчиков и передает их в бизнеслогику. Бизнес логика обрабатывает данные и выдает уровни газа для моторов. Безнес логика пакуется в отедельную библиотеку и покрывается юнит тестами. В таких тестах мы можем легко эмулировать перемещение во времени и показания самих датчиков. В идиальных условиях Бизнес логика должны на любые эти изменения уметь реагировать и делать то что нужно.
Вопрос про разбор математического выражения конечно улыбнул. Помню как в институте писал как раз похожий парсер, который разбирал подобные выражения и решал их: "приведение к нормальной форме" - кажется так это называется. Но с ходу в уме сообразить вот прям на собесе, может уже и не вспомню. Надо загуглить, почитать, и после этого будет результат.
Это я к чему? Что кандидат может элементарно забыть что то. Но помнить где это искать в случае необходимости.
Ну а то что проинтервьюировали столько кандидатов и не нашли нужного ну тут явно что-то не так. С теми, кто интервьюировал. Или с теми кто искал кандидатов, раз набрали одних тимлидов да директоров вместо сеньоров.
Зачем отправлять запросы при Polling методе каждые 2 секунды, если сам по себе Polling метод подразумевает, что сервер как бы ждет некоторое время и держит соединение не отдавая его содержимое, пока данные не появятся?
Это тогда не Polling получается а какой Getting.
Когда делал своего бота (не на пайтоне), как раз использовал этот подход. Делаю запрос на сервер телеграмм с ожиданием в 30 секунд, если ответа не последовало, сбрасываю соединение и снова делаю новый запрос. Получается один запрос в 30 секунд что не так часто.
Вместо
connectизreact-reduxможно использовать хукиuseDispatchиuseSeletectorи результат будет тот же самый.Ну по ссылки как бы все понятно, что автор комментария создал приватный email да еще и не читал видимо его некоторое время, но все ждал, когда ему что-то там пришлют. Потом когда он это прочитал, уже наступил 2023 год и типо отправка прекращена. Но значит должен был быть сделан возврат, раз отправка прекращена. Был ли сделан возврат? По ссылке этого не написано. Если возврата не было сделано и товар не был отправлен, то автор комментария правильно пишет: "мы в одностороннем порядке прикарманили ваши деньги".
Надо вспомнить, что когда только эти самые веб-компоненты появились, ими можно было пользоваться разве что для каких то демок поиграться. Были разные реализации в разных браузерах. Это все вставляло палки в колеса разработки. А потом появился React. И только потом настала смерть IE, а вместе с этим наступила эра когда веб-компоненты начали поддерживаться всеми браузерами. Но сейчас уже 2023 год, и вот я задаюсь вопросом, а что могут сделать веб-компоненты, что не может React? Shadow DOM у них есть, а если он мне не нужен?
Мне кажется, что React как раз и послужил этаким "убийцей" веб-компонентов. Из мира React мне не разу не пригодилась эта технология. А любой велосипед можно сделать и на React, получится React-компонент.
А вот не в мире React, когда я тут что-то сделал, но я не хочу чтобы другие стили на сайте у меня тут все не поломали, дай-ка я засуну все это в веб-компонент - Shadow DOMом едины. Такой подход имеет место быть. Но здесь же очевидны и другие проблемы, более высокого уровня, архитектурные.
Потому что они правильно питаются. Вы не слова про это не сказали, а это куда важнее чем сами беговые треннировки. "Скажи мне что ты еш и я скажу что из тебя выйдет" - гласит народная мудрость (на самом деле сам придумал). Во вторых бег это не лучший вид спорта для увеличения мышечной массы. Скорее даже наоборот, в процессе интенсивного бега мышечная масса убывает.
Хотите бегать и чтобы ноги росли - нужно добавлять нагрузку на ноги - это либо утежелители на ноги либо бегать в горку. Первое время надо быть осторожным с нагрузкой на сердце, можно и в космос улететь.
Но без правильного питания организму просто не из чего будет восстанавливать мышцы, а так же наращивать новые. Представьте себе стройку, прораб говорит: "Стройте дом", а кирпича то нет. Из чего строить? Поэтому 2.5 грамма белка на массу тела в день надо в себя запихнуть.
Сколько вы там сказали весите, 83? Это почти 800 грамм говядины каждый день! Конечно есть одну говядину необязательно, есть и другие продукты с высоким содержанием белка)))
А если завтра курс бакса станет 200р - неужели не понятно что работать из-за границы на Россию станет невыгодно? Неужели не понятно, что платить зарплату сотрудникам за границей компании не выгодно без привязки к рублю с текущим "широко" плавающим курсом?
Вам дали возможность релоцироваться на таких же условиях. Вы ей воспользовались. Ну а дальше то куда смотрели? Ждали своего черного лебедя? Вот он к вам и пришел. Если бы смотрели на сторону то давно бы уже нашли работу чтобы зп была в валюте. Тем более что уже релоцировались в Армению. Но это не путь настоящего самурая. Настоящий самурай сначала будет тихонечко ликовать, что по одному курсу он получает запрплату больше рынка, а потом будет писать жалобные статьи на хабре, мол у авито денег полно, а они вот тут мне зп сокращают.
А ходить и жаловаться и считать чужие доходы такой себе удел...
Сервопривод вовсе не означает что нужно использовать шаговый двигатель. В большинстве сервоприводов отлично справляются обычные коллекторные двигатели. В сочитании с хорошим энкодером устройство получается надежным и точным. Все зависит от поставленной задачи, но все равно если речь идет про умный дом то шаговые двигатели нужны не так уж и часто. Открытие ворот, запорные краны, жалюзи и прочие вещи можно легко обойтись без шаговых двигателей. Поэтому вопрос целесообразности использования шагового двигателя в конкретном случае для меня остается открытым.
Я думаю ваша версия устройства, выйдет столько же по цене или даже дороже, даже если оно будет без экрана. Потому что 80-90% расходов будет составлять ПО. Приложение же будет бесплатное, а в нем нужно огого сколько интерфейсов наделать да все это протестировать, да все это с другим девайсом через блютуз и асинхронно. Да в добавок приложения нужно два. А потом когда выкатится новая версия прошивки на устройство, нужно будет еще и старые поддерживать и новые. Поэтому этот путь интересен в плане удобство ношения, но за все надо платить. Дерзайте и что-то обязательно получится.
Слушайте, ну вы такие классные советы раздаете и возможно мой вопрос будет уже какой-нибудь 101, но все таки хочется узнать: что надо сделать, чтобы развалить сеть ночных клубов?
Хочется сказать: просто жесть...
Интересно, долго еще 1С будет считать что их генерируемые запросы идеальны и не позволять их переписывать "на лету", заставляя прибегать к каким то кастылям, в виде промежуточных решение, вместо того чтобы позволить в самой платформе сделать подмену, например, как это сделано в Entity Framework?
Ваша история мне чем то напомнило мою историю, когда мне тоже пришлось расширять базовый функционал. Тогда меня не устроило, как работает LIKE %текст% .
Я думаю что предыдущий комментарий был отсылкой к тому, что в HTML часто для разметки стилей используют просто классы, а не атрибуты, как у вас. Исторически было так что стили на атрибутах работают медленее чем на классах, но как сейчас обстоят дела с производительностью стилей на атрибутах я не знаю. К теме странного поведения overflow-y: auto это не имеет никакого отношения.
Grid как раз и был создан для того чтобы решать подобные проблемы и отлично решает их. Flex - это как бы 1D (либо по горизонтали/либо по вертикали), а Grid - это как бы 2D (и по горизонтали и по вертикали).
Ура, круто!
Да и не только для них. Вангую будут еще разборы стервятников по падали.
Поделитесь, что надо делать чтобы в 26 заработать такой букет болезней со спиной как у вас?