Вот не надо про везде. Никто везде не работал. Обычно это везде строится либо на собственном опыте, либо на чьих то рассказах. Во всех остальных случаях есть нормальные коллективы в которых приятно работать с нормальными коллегами, тим лидами и менеджерами. Тут важно еще как себя позиционировать. Пришел ты проект продвигать или по головам ходить.
Как же это близко и лампово)) Но писать кодом это конечно мощно! Тут выше написали про sketchup.
Лет 10 назад его освоил и с тех пор все модели в нем рисую. Т.е. рисую сразу по тем размерам которые нужны мне. В своем городе нашел компанию, которая потом все мои идеи перерисовывает уже в своей специальной распиловочной программе, а там сама расставляет присадки. Плюс кромка бывает тоже разной. Использую в основном 2мм а например при распиле ящиков это нужно учитывать чтобы присадки совпали. Программа распиловщика это все учитывает. Так что это их головная боль, не моя.
Так же можно кучу времени потратить на подгонку к направляющим. Ладно если это просто шариковые 8мм. А если хочется скрытого монтажа, то тут вручную все это предусмотреть может быть не просто. А так фабрика сразу размечает места под будущие крепления, только саморез закрути.
Я полазил по сайту timeweb и не нашел там тарифа среды для разворачивания serverless. Т.е. я так понимаю, был куплен просто VPS и уже на нем была поднята среда для поддержки serverless кода, верно?
Странно почему в 2025 году в выборку не попал Redux-Saga. Конечно возможно потому что порог вхождения в Redux и без того низок, чего уж говорить еще и о Redux-Saga... Но все таки плюсы от саг недооценивать нельзя:
Возможность отмены действий.
Возможность прерывания действий.
Возможность управления списком асинхронных действий.
Представим задачу - дано массив ссылок на картинки, которые нужно загрузить на клиент. Задача сделать так, чтобы одновременно загружалось только 3 картинки. На сагах эта задача решается в несколько строк кода.
Я вообще не понимаю как может ещё существовать React, когда есть $mol! Ведь если это такой крутой фреймворк, то он уже должен был давно вытеснить React с рынка. У него то точно правильная архитектура заложена, не то что у реакта, на котором строить архитектуру не возможно.
Судя по вашему комментарию, пользовательские плейсхолдеры хранятся в самом компоненте, а не в глобальном стопе. Отсюда и все проблемы. Если перенести пользовательские плейсхолдеры в глобальный стор и читать их только там где нужно, точечно выполняя перерендер то это решит проблему.
Как вариант в сторе завести 50 коллекций под каждый тип блока и по уникальному индексу связывать переменные блока (плейсхолдеры) с компонентом.
Когда компонент монтируется, он может вызвать useId() хук который вернёт уникальный ключ текущего компонента, или использовать ключ из базы данных для блока, вы ведь как то их сохраняете.
Ваша статья, яркий пример того, с чем можно столкнуться большое приложение от использования просто React из коробки. Ваше решение похоже на временную меру и суть проблемы не решает. А проблема скорее всего в том что слишком много DOM обновляется на каждый чих.
В вашей ситуации так и просится глобальный стор, который будет хранить все переменные, а эти переменные будут читаться там где надо через специальные компоненты с использованием useSelector. Когда надо обработать событие будет использоваться компонент с вызовом useDispatch, Тем самым получается то, о чем говорят выше - аля использование сигналов только на React.
Выше правильно сказали, в React нет сигналов из коробки. Для этого нужно отдельная зависимость. Redux частично может взять на себя роль сигналов.
Но перевод то не сам себя создал, его же кто-то создал. Обычно когда в переводе находят ошибки, то делают сноски или добавляют комментарии от автора в которых указано, что тут опечатка или автор оригинала вводит в заблуждение.
Программирование на GPU - это отдельный мир программирования. Тут столько нужно знать нюансов, чтобы получить максимальную эффективность. Из того что помню, когда работал с CUDA, так это то что читать матрицу по вертикали было куда медленней, чем читать по горизонтали. Помню я не сразу понял, что причина была в кеше, и то как кешируются данные из глобальной памяти. В вашем алгоритме тоже есть что улучшить, возможно. Попробуйте завести локальные переменные под глобальные переменные (переменная A[m * N + k]), чтобы не читать дважды одно и то же значение.
Насчет скорости вычислений для 7600х7600, я бы начал сравнивать с эталонной программой - простое сложение двух матриц такого же размера. Эта программа на столько просто что там сложно допустить какую то ошибку и она наиболее результативно показывает максимум который достижим для данной размерности. Понаблюдать, за разницей сложения матриц по вертикали и по горизонтали.
На самом деле проблемы оффсетной пагинации куда глобальнее чем кажутся на первый взгляд. Предположим мы уже отфильтровали данные и показали их клиенту. Пока клиент смотри на эти данные были добавлены новые записи в первую страницу. Тогда произойдет сдвиг данных и на второй странице возможно окажутся те же записи, что были и на первой. А если на UI стороне отображение реализовано в виде авто подгрузке по доскролу то клиент увидит задвоение некоторых данных. Курсорная пагинация не обладает подобной проблемой. Новые записи которые были добавлены на первую страницу вообще не попадут в выдачу клиента, до обновления первой страницы.
В одном из проектов как раз реализовывал подобную курсорную пагинацию правда она там была в обе стороны. Обычно при долгой прокрутке страницы, с доскролом, на странице начнет отображаться так много записей что сама страница начнет тормозить и подлагивать. Чтобы этого избежать курсорная подгрузка реализована в обе стороны: при подгрузке третей и более страницы верхние данные удаляются. И наоборот. При прокрутке на верх подгружаются записи которые были удалены ранее, а снизу записи стираются.
А как сделано у вас. Курсоры в обе стороны или только в одну?
Статья о том, что автор не внимательно читал документацию. Но потом автор прочитал документацию и узнал о stopPropagation(). Могу порекомендовать написать статью о preventDefault() и stopImmediatePropagation().
Это аы еще прикрепленный матераил не проверяли. Сейчас не проверял, но раньше было, что если я загружу фотографию, а потом удалю, то по прямой ссылке на сам файл она так и останется на веки лежать в хранилище VK.
Задался я как то раз целью вращать коллекторный двигатель с подключенным энкодером так, чтобы максимально точно возвращать его и уметь возвращать ровно на заданное число оборотов. И тоже стал решать эту задачу с нуля. И что я могу сказать - без тестирования кода, наверно у меня бы ушло на решение этой задачи год. Хотя казалось бы, что тут сложного, нужно лишь в точное время включить двигатель и в точное выключить, а потом проделать тоже самое только обратно. Но есть нюанс.
После того как мне удалось отделить бизнес логику, которая крутилась на ардуино отделить в отдельную библиотеку, дело стронулось с места. Эта библиотека была покрыта тестами, которые поражали своей извращенность. Но в реальности такое ведь может произойти. В реальности датчик может начать выдавать данные которые для него не характерны. Так было в нескольких авариях с самолетами, когда самолет задирал нос, терял скрость и падал штопором. Почему такое произошло? Потому что датчик тангажа начинал врать.
Поэтому главный принцип бизнес логики - не верю никому. Чуть что-то начало присылать странные данные - используем дефолтные значения или переходим к плану Б. Чуть что-то пошло не так - падача питания на двигатель есть а движения энкодера нет - все выключить с выводом ошибки.
Сами сигналы с датчиком можно легко записать в логи и потом покрытть тестами и эти данные. Тогда сразу будет видно - вообще живой ли датчик. Адекватные ли данные он присылает.
Калибровка - тоже не маловажная часть любого подобного проекта. Если нужно то можно делать ее каждый раз перед запуском. Что-то можно откалибровать уже находу.
Короткая 3х секундная программа калибровки уже ввоздухе смоглабы много узнать о реальных показателях коптера. 3 секунды для микрокомпьютера просто бездна времени для сбора данных и их анализа.
Ну и конечно основа основ - юнит тесты! Без них очень сложно сделать поистени сложные вещи. Ардуина или будь то STM32 просто принимает данные с датчиков и передает их в бизнеслогику. Бизнес логика обрабатывает данные и выдает уровни газа для моторов. Безнес логика пакуется в отедельную библиотеку и покрывается юнит тестами. В таких тестах мы можем легко эмулировать перемещение во времени и показания самих датчиков. В идиальных условиях Бизнес логика должны на любые эти изменения уметь реагировать и делать то что нужно.
Вопрос про разбор математического выражения конечно улыбнул. Помню как в институте писал как раз похожий парсер, который разбирал подобные выражения и решал их: "приведение к нормальной форме" - кажется так это называется. Но с ходу в уме сообразить вот прям на собесе, может уже и не вспомню. Надо загуглить, почитать, и после этого будет результат.
Это я к чему? Что кандидат может элементарно забыть что то. Но помнить где это искать в случае необходимости.
Ну а то что проинтервьюировали столько кандидатов и не нашли нужного ну тут явно что-то не так. С теми, кто интервьюировал. Или с теми кто искал кандидатов, раз набрали одних тимлидов да директоров вместо сеньоров.
Цитаты по Хабр:
Вот не надо про везде. Никто везде не работал. Обычно это везде строится либо на собственном опыте, либо на чьих то рассказах. Во всех остальных случаях есть нормальные коллективы в которых приятно работать с нормальными коллегами, тим лидами и менеджерами. Тут важно еще как себя позиционировать. Пришел ты проект продвигать или по головам ходить.
Как же это близко и лампово)) Но писать кодом это конечно мощно! Тут выше написали про sketchup.
Лет 10 назад его освоил и с тех пор все модели в нем рисую. Т.е. рисую сразу по тем размерам которые нужны мне. В своем городе нашел компанию, которая потом все мои идеи перерисовывает уже в своей специальной распиловочной программе, а там сама расставляет присадки. Плюс кромка бывает тоже разной. Использую в основном 2мм а например при распиле ящиков это нужно учитывать чтобы присадки совпали. Программа распиловщика это все учитывает. Так что это их головная боль, не моя.
Так же можно кучу времени потратить на подгонку к направляющим. Ладно если это просто шариковые 8мм. А если хочется скрытого монтажа, то тут вручную все это предусмотреть может быть не просто. А так фабрика сразу размечает места под будущие крепления, только саморез закрути.
Я полазил по сайту timeweb и не нашел там тарифа среды для разворачивания serverless. Т.е. я так понимаю, был куплен просто VPS и уже на нем была поднята среда для поддержки serverless кода, верно?
Я ни разу не эксперт в RPI, но могу предположить что ответ зависит от того как часто на нее писать.
Облако спустилось на землю.
Пост какого хвастовства, где 90% - вот смотрите какой я молодец, а 10% - "могло быть и лучше".
Я бы озаглавил пост: "Мне было лень разбираться в нейминге переменных и базах данных...".
Ожидал увидеть раздел: "Что пошло не по плану".
Вот только пруфы не завезли, а так да, самый неудачный state management.
Я пользуюсь Redux в 2025. Как и еще те, кто делают более четырех миллионов скачиваний в неделю. Пруфы тут https://www.npmjs.com/package/@reduxjs/toolkit
Ну раз "все забыли", значит больше вопросов нет.
Странно почему в 2025 году в выборку не попал Redux-Saga. Конечно возможно потому что порог вхождения в Redux и без того низок, чего уж говорить еще и о Redux-Saga... Но все таки плюсы от саг недооценивать нельзя:
Возможность отмены действий.
Возможность прерывания действий.
Возможность управления списком асинхронных действий.
Представим задачу - дано массив ссылок на картинки, которые нужно загрузить на клиент. Задача сделать так, чтобы одновременно загружалось только 3 картинки. На сагах эта задача решается в несколько строк кода.
Я вообще не понимаю как может ещё существовать React, когда есть $mol! Ведь если это такой крутой фреймворк, то он уже должен был давно вытеснить React с рынка. У него то точно правильная архитектура заложена, не то что у реакта, на котором строить архитектуру не возможно.
Судя по вашему комментарию, пользовательские плейсхолдеры хранятся в самом компоненте, а не в глобальном стопе. Отсюда и все проблемы. Если перенести пользовательские плейсхолдеры в глобальный стор и читать их только там где нужно, точечно выполняя перерендер то это решит проблему.
Как вариант в сторе завести 50 коллекций под каждый тип блока и по уникальному индексу связывать переменные блока (плейсхолдеры) с компонентом.
Когда компонент монтируется, он может вызвать useId() хук который вернёт уникальный ключ текущего компонента, или использовать ключ из базы данных для блока, вы ведь как то их сохраняете.
Ваша статья, яркий пример того, с чем можно столкнуться большое приложение от использования просто React из коробки. Ваше решение похоже на временную меру и суть проблемы не решает. А проблема скорее всего в том что слишком много DOM обновляется на каждый чих.
В вашей ситуации так и просится глобальный стор, который будет хранить все переменные, а эти переменные будут читаться там где надо через специальные компоненты с использованием useSelector. Когда надо обработать событие будет использоваться компонент с вызовом useDispatch, Тем самым получается то, о чем говорят выше - аля использование сигналов только на React.
Выше правильно сказали, в React нет сигналов из коробки. Для этого нужно отдельная зависимость. Redux частично может взять на себя роль сигналов.
Но перевод то не сам себя создал, его же кто-то создал. Обычно когда в переводе находят ошибки, то делают сноски или добавляют комментарии от автора в которых указано, что тут опечатка или автор оригинала вводит в заблуждение.
Программирование на GPU - это отдельный мир программирования. Тут столько нужно знать нюансов, чтобы получить максимальную эффективность. Из того что помню, когда работал с CUDA, так это то что читать матрицу по вертикали было куда медленней, чем читать по горизонтали. Помню я не сразу понял, что причина была в кеше, и то как кешируются данные из глобальной памяти. В вашем алгоритме тоже есть что улучшить, возможно. Попробуйте завести локальные переменные под глобальные переменные (переменная A[m * N + k]), чтобы не читать дважды одно и то же значение.
Насчет скорости вычислений для 7600х7600, я бы начал сравнивать с эталонной программой - простое сложение двух матриц такого же размера. Эта программа на столько просто что там сложно допустить какую то ошибку и она наиболее результативно показывает максимум который достижим для данной размерности. Понаблюдать, за разницей сложения матриц по вертикали и по горизонтали.
На самом деле проблемы оффсетной пагинации куда глобальнее чем кажутся на первый взгляд. Предположим мы уже отфильтровали данные и показали их клиенту. Пока клиент смотри на эти данные были добавлены новые записи в первую страницу. Тогда произойдет сдвиг данных и на второй странице возможно окажутся те же записи, что были и на первой. А если на UI стороне отображение реализовано в виде авто подгрузке по доскролу то клиент увидит задвоение некоторых данных. Курсорная пагинация не обладает подобной проблемой. Новые записи которые были добавлены на первую страницу вообще не попадут в выдачу клиента, до обновления первой страницы.
В одном из проектов как раз реализовывал подобную курсорную пагинацию правда она там была в обе стороны. Обычно при долгой прокрутке страницы, с доскролом, на странице начнет отображаться так много записей что сама страница начнет тормозить и подлагивать. Чтобы этого избежать курсорная подгрузка реализована в обе стороны: при подгрузке третей и более страницы верхние данные удаляются. И наоборот. При прокрутке на верх подгружаются записи которые были удалены ранее, а снизу записи стираются.
А как сделано у вас. Курсоры в обе стороны или только в одну?
А я то как рад - самого автора $mol-а развеселил. А за умника, спасибо!
Статья о том, что автор не внимательно читал документацию. Но потом автор прочитал документацию и узнал о stopPropagation(). Могу порекомендовать написать статью о preventDefault() и stopImmediatePropagation().
Это аы еще прикрепленный матераил не проверяли. Сейчас не проверял, но раньше было, что если я загружу фотографию, а потом удалю, то по прямой ссылке на сам файл она так и останется на веки лежать в хранилище VK.
Задался я как то раз целью вращать коллекторный двигатель с подключенным энкодером так, чтобы максимально точно возвращать его и уметь возвращать ровно на заданное число оборотов. И тоже стал решать эту задачу с нуля. И что я могу сказать - без тестирования кода, наверно у меня бы ушло на решение этой задачи год. Хотя казалось бы, что тут сложного, нужно лишь в точное время включить двигатель и в точное выключить, а потом проделать тоже самое только обратно. Но есть нюанс.
После того как мне удалось отделить бизнес логику, которая крутилась на ардуино отделить в отдельную библиотеку, дело стронулось с места. Эта библиотека была покрыта тестами, которые поражали своей извращенность. Но в реальности такое ведь может произойти. В реальности датчик может начать выдавать данные которые для него не характерны. Так было в нескольких авариях с самолетами, когда самолет задирал нос, терял скрость и падал штопором. Почему такое произошло? Потому что датчик тангажа начинал врать.
Поэтому главный принцип бизнес логики - не верю никому. Чуть что-то начало присылать странные данные - используем дефолтные значения или переходим к плану Б. Чуть что-то пошло не так - падача питания на двигатель есть а движения энкодера нет - все выключить с выводом ошибки.
Сами сигналы с датчиком можно легко записать в логи и потом покрытть тестами и эти данные. Тогда сразу будет видно - вообще живой ли датчик. Адекватные ли данные он присылает.
Калибровка - тоже не маловажная часть любого подобного проекта. Если нужно то можно делать ее каждый раз перед запуском. Что-то можно откалибровать уже находу.
Короткая 3х секундная программа калибровки уже ввоздухе смоглабы много узнать о реальных показателях коптера. 3 секунды для микрокомпьютера просто бездна времени для сбора данных и их анализа.
Ну и конечно основа основ - юнит тесты! Без них очень сложно сделать поистени сложные вещи. Ардуина или будь то STM32 просто принимает данные с датчиков и передает их в бизнеслогику. Бизнес логика обрабатывает данные и выдает уровни газа для моторов. Безнес логика пакуется в отедельную библиотеку и покрывается юнит тестами. В таких тестах мы можем легко эмулировать перемещение во времени и показания самих датчиков. В идиальных условиях Бизнес логика должны на любые эти изменения уметь реагировать и делать то что нужно.
Вопрос про разбор математического выражения конечно улыбнул. Помню как в институте писал как раз похожий парсер, который разбирал подобные выражения и решал их: "приведение к нормальной форме" - кажется так это называется. Но с ходу в уме сообразить вот прям на собесе, может уже и не вспомню. Надо загуглить, почитать, и после этого будет результат.
Это я к чему? Что кандидат может элементарно забыть что то. Но помнить где это искать в случае необходимости.
Ну а то что проинтервьюировали столько кандидатов и не нашли нужного ну тут явно что-то не так. С теми, кто интервьюировал. Или с теми кто искал кандидатов, раз набрали одних тимлидов да директоров вместо сеньоров.