Всегда было интересно, чем пара Access Token/Refresh Token безопаснее http-only куки, устанавливаемой на короткое время и продливаемой бэком? Точно также не даст CSRF, и точно также при угоне в течении ее жизни можно будет эксплойтить бэк. В чем принципиальная разница?
В какой-то совсем внешней библиотеке эти определения находиться не смогут
Да, но если вдруг понадобиться в этой библиотеке обратиться к какой-то шаблонной фии с каким-то типом, что мешает просто заинклюдить файл с этой фй и вызвать ее с нужным типом?
Я правильно понимаю, что у нас есть некая шаблонная функция?
Ну для примера пусть будет minimum:
template <typename T> T minimum (const T &a, const T &b) {
return a < b ? a : b;
}
Есть внешний файл, где она объявлена, допустим utils.cpp
Если понадобилось вызвать эту фю для какого-либо произвольного типа где-либо в другом файле, можно же сделать так:
#include "utils.cpp"
typedef unsigned int MYTYPE;
MYTYPE a = 5, b = 7;
cout << minimum( a, b );
Или я задачу не верно понял?
Кодогенератор это программа, которая на основе исходного кода или какого-нибудь файла настроек генерирует вспомогательный код, который потом компилируется вместе с исходным кодом. Это нужно, чтобы не писать boilerplate-код (копипаст)
Или на примере того-же мока - напиши его один раз, вынеси в отдельный файл - и где надо - заинклюдь чтобы не было boilerpate-а.
Я специально нанял человека из россии, решил молодому мальчику помочь.
Из начала повествования. А надо было собеседовать и проверять и не надо было тянуть - в этом и была ошибка.
А так да - наняли человека не подходящего под требования.
Еще раз - у миддла или сеньора данной ошибки по просту бы не было.
А "оправдывание" было как раз из-за того, что Василий был не из той категории, которая требовалась.
Он не знал что делать - когда это происходит со зрелым девом - реакция будет абсолютно другая - он будет копать, пока либо совсем не упрется, либо не решит.
Если же юн либо возрастом, либо умом - то будет то, что описано в статье. Т.е. "оправдывание" описанное в статье - просто обычная психологическая защита.
Вы думаете, миддлов и даже сеньоров мало, которые говорят «ничего не знаю, проблема где-то не в моём коде»?
Конечно такие есть - но они это делают, четко понимая зачем и почему.
Это - не психологическая защита, а расчет - и это, естественно, совершенно другое и для другого.
Нигде про это не сказано, но из комментариев автора выходит, что брали вообще чтобы "помочь"...
и у него неплохое резюме
Когда резюме - пусть даже и не плохое - являлось гарантом чего-либо?
но 100% достоверно оценить компетенции специалиста просто по резюме и собеседованиям в принципе нереально
Естественно, но здесь даже попытку не сделали, зато повелись на слова "Я буду копать!"
а про то, что ныть «чужая библиотека виновата» — отстой
Дак это и вытекает из компетенций кандидата - миддл так бы не стал делать, а попытался бы решить проблему или хотя-бы в ней разобраться (на самом деле он бы просто не стал юзать данный стэк и этой конкретной проблемы вообще бы не существовало).
На самом деле автору повезло с кандидатом - могу бы еще пару месяцев копаться и тянуть время, вместо чего он сделал красный звоночек своим предупреждением - радоваться нужно.
Вменяемые программисты получаются не из невменяемых, а из обычных программистов без опыта, если добавить опыт через мануалы и практику.
Из невменяемых плюс мануалы вы получите невменяемого минус мануалы и минус время.
Поставить на ноги? У вас богодельня или бизнес? Если первое - вопросов не имею. Если бизнес - то надо чётко понимать затраты и профиты от такого действа и благодарность тут не причём.
Ну и отлично - он сэкономил вам кучу времени - радуйтесь, что так получилось. Берите вменяемого программиста и успевайте убрать косяк до того, как топы поймут откуда он.
Я правильно понимаю, что ваша организация наняла молодого программиста, не проверив его компетенции и технологии, которыми он владеет, как и его опыт?
Вы поставили перед ним таску, которую он сделал исходя из своих компетенций и технологий, которыми он владеет?
Потом вы попросили его сделать некоторый лоулевел, который ему не дан ибо для него нужен миддл.
Вопрос - а почему вы взяли вместо миддла или сеньора непонятно кого? Потому что он дешев?
Ну и кто тогда должен оправдываться?
Те ваша восточноевропейская эйчарка взяла неизвестно кого, вы его пустили к себе в стэк не проверив, а оправдываться надо только ему?
В ситуации виноваты все, через кого Василий к вам попал, при этом Василий виноват меньше всего - таску, которую ему озвучивали он закрыл, то что делать он не умеет - он честно про это вам сказал, а не стал гуглить и тянуть время - как обычно бывает. Так что далеко не все так однозначно.
О правильности я в конце первого комментария написал - нужно всеми силами избегать блокирующего кода везде, где только можно (не только в микропроцессорах) , и использовать его только тогда, когда это прямо реально нужно и кейсов таких от силы пол-процента наберется.
Задачу можно решить быстро и в лоб, а можно решить хорошо. Блокирующий - это всегда быстро и в лоб, что потом чревато проблемами и переделками.
Зачем все подряд упаковывать в конечные автоматы?!
Потому что это более универсальней и покрывает весь спектр задач, это можно сделать один раз, а потом лишь переиспльзовать будучи на 99% уверенным, что код этот может всегда расширить на бОльшее колво случаев и работать он будет предсказуемо и четко. При этом самого кода при таком подходе будет не сильно больше, нежели у решения в лоб.
Ну, надо начать просто - чем больше, тем лучше будет.
Например, появляется возможность использовать классы как скоп, чтобы не гадить в глобальную область видимости. (можно статический, если не предвидится несколько таких).
Использовать объекты, когда есть что-то повторяющиеся в системе (кнопки, например).
Использовать ссылки, вместо передачи по значению.
Ну и возможность выносить класс или набор классов, как отдельный файл с отдельным функционалом - это прямо киллерфича - глобал не загрязняется, а порождая тип, ну например OLED display( PORTA, PIN1) сразу понятно что куда почему + инициализация, если нужна.
Раньше C++ не использовался ввиду того, что давал оверхэд при компиляции для микропррцессоров, сейчас компиляторы его практически не дают - разница может составлять совсем не много около - 0.2-0.5%
И раньше я также писал только на C из-за этого, сейчас куда правильней писать на C++ и иметь все его плюшки - программы получаются проще и гораздо более гибкими.
Но понятно, что при использовании C++, надо и метрологию его использовать, а не процедуры + вкоряченный класс)
При этом может получиться очень интересная штука - программа, написанная на C++ с использованием C++ особенностей получится меньшей по размеру и более быстрой, чем делующая тоже на C. На небольших программах это практически не видно, а вот с увеличением размера начинает ощущаться.
Очень подробно и с диаграммами — круто.
Но — блокирующий опрос кнопок — это очень плохо, особенно, если проект сложный.
Вообще все блокирующее в микроконтроллерах — это всегда плохо, особенно, если их быстродействие не велико.
Гораздо правильней делать это с помощью чего-то похожего на конечный автомат.
И так и делают — одна из самых популярных (но не самых крутых) — это библиотека по работе с кнопками от AlexGyver.
Суть в том, что есть структура (или класс) кнопки, где хранится ее состояние, когда было это по времени (значение таймера отсчета), предыдущее состояние и тд.
И на основе этих данных можно и дабл- и трипл-клики обрабатывать, и удержание и клик+удержание и много чего еще, причем с помощью очень небольших изменений кода.
И для того, чтобы обновить состояние — нужно просто вызвать некую фю, передав туда отсчет времени. И делать это можно где-угодно — хочешь — в таймере, хочешь — по прерыванию, хочешь — в основном цикле. Лишь бы паузы между вызовами были не слишком большие — иначе реакция будет подтормаживать. А так — один раз тайминги настроил и забыл.
Это удобней и в разы универсальней.
При этом таких кнопок сколько угодно можно породить (хоть динамически), а в функции(ях) опроса можно эти кнопки либо последовательно перебирать, либо сразу все, либо по одной на вызов фии, либо вообще сделать одну фю на все кнопки. Все это отлично ложиться на классы в C++, да и вообще на ООП.
И самое главное — опрос не мешает выполнятся остальным частям кода.
Не используйте блокирующий код, пока вы четко не понимаете, что он действительно необходим. И это относится не только к кнопкам или микроконтроллерам.
а твои способы распределять данные или выносить логику начали вызывать сложные баги, и становится все больше костылей.
Я ещё в первой части просил вас дать реальный пример, в котором можно увидеть, почему описанная вами проблема происходит, и на 90% это будет скорее всего из-за неправильной архитектуры.
У нас огромное и сложное SPA с кучей бизнес-логики и ни разу не нужно было городить какие-то отдельные, внешние классы, да ещё и связывать их с компонентами. Если общее (данные, логика) - все лежит в сторе, если компонентное - в компоненте(ах).
Все ещё не понятно, почему вы класс с данными и какой-то логикой называете сервисом. Сервисом чего он является?
Если вам действительно необходим некий общий сервис с реактивностью, почему просто не импортировать его и вызывать его фии для получения или установки каких-то его состояний? Реактивность можно добавить, через computed/watch в самом компоненте, где это необходимо, причём будет чётко видно что за сервис и как вы его используете, без какой либо внутренней магии.
Вобщем, без реального примера понять зачем это все понадобилось конкретно вам - невозможно. Как и понять верность выбора и плюсы вашего решения.
P. S. Зачем используете proxy для readonly? Почему не обычный сеттер?
Всегда было интересно, чем пара Access Token/Refresh Token безопаснее http-only куки, устанавливаемой на короткое время и продливаемой бэком? Точно также не даст CSRF, и точно также при угоне в течении ее жизни можно будет эксплойтить бэк. В чем принципиальная разница?
Да, но если вдруг понадобиться в этой библиотеке обратиться к какой-то шаблонной фии с каким-то типом, что мешает просто заинклюдить файл с этой фй и вызвать ее с нужным типом?
Я правильно понимаю, что у нас есть некая шаблонная функция?
Ну для примера пусть будет minimum:
Есть внешний файл, где она объявлена, допустим utils.cpp
Если понадобилось вызвать эту фю для какого-либо произвольного типа где-либо в другом файле, можно же сделать так:
Или я задачу не верно понял?
Или на примере того-же мока - напиши его один раз, вынеси в отдельный файл - и где надо - заинклюдь чтобы не было boilerpate-а.
Можно вопрос от неспециалиста в C++?
А почему нельзя просто заинклюдить библиотеку и вызывать оттуда нужные фии?
Чем лучше писать какие-то сущности в комментариях, которые потом развернутся в код?
Из начала повествования. А надо было собеседовать и проверять и не надо было тянуть - в этом и была ошибка.
А так да - наняли человека не подходящего под требования.
Еще раз - у миддла или сеньора данной ошибки по просту бы не было.
А "оправдывание" было как раз из-за того, что Василий был не из той категории, которая требовалась.
Он не знал что делать - когда это происходит со зрелым девом - реакция будет абсолютно другая - он будет копать, пока либо совсем не упрется, либо не решит.
Если же юн либо возрастом, либо умом - то будет то, что описано в статье. Т.е. "оправдывание" описанное в статье - просто обычная психологическая защита.
Конечно такие есть - но они это делают, четко понимая зачем и почему.
Это - не психологическая защита, а расчет - и это, естественно, совершенно другое и для другого.
Нигде про это не сказано, но из комментариев автора выходит, что брали вообще чтобы "помочь"...
Когда резюме - пусть даже и не плохое - являлось гарантом чего-либо?
Естественно, но здесь даже попытку не сделали, зато повелись на слова "Я буду копать!"
Дак это и вытекает из компетенций кандидата - миддл так бы не стал делать, а попытался бы решить проблему или хотя-бы в ней разобраться (на самом деле он бы просто не стал юзать данный стэк и этой конкретной проблемы вообще бы не существовало).
На самом деле автору повезло с кандидатом - могу бы еще пару месяцев копаться и тянуть время, вместо чего он сделал красный звоночек своим предупреждением - радоваться нужно.
Вменяемые программисты получаются не из невменяемых, а из обычных программистов без опыта, если добавить опыт через мануалы и практику.
Из невменяемых плюс мануалы вы получите невменяемого минус мануалы и минус время.
Поставить на ноги? У вас богодельня или бизнес? Если первое - вопросов не имею. Если бизнес - то надо чётко понимать затраты и профиты от такого действа и благодарность тут не причём.
Ну и отлично - он сэкономил вам кучу времени - радуйтесь, что так получилось.
Берите вменяемого программиста и успевайте убрать косяк до того, как топы поймут откуда он.
Те вы взяли программиста чтобы помочь, а не чтобы он выполнял требования бизнеса? Ну я даже не знаю что сказать...
Если человек не может - его надо заменять. Это его факап, как программиста, а все остальное - ваш, как руководителя.
Я правильно понимаю, что ваша организация наняла молодого программиста, не проверив его компетенции и технологии, которыми он владеет, как и его опыт?
Вы поставили перед ним таску, которую он сделал исходя из своих компетенций и технологий, которыми он владеет?
Потом вы попросили его сделать некоторый лоулевел, который ему не дан ибо для него нужен миддл.
Вопрос - а почему вы взяли вместо миддла или сеньора непонятно кого? Потому что он дешев?
Ну и кто тогда должен оправдываться?
Те ваша восточноевропейская эйчарка взяла неизвестно кого, вы его пустили к себе в стэк не проверив, а оправдываться надо только ему?
В ситуации виноваты все, через кого Василий к вам попал, при этом Василий виноват меньше всего - таску, которую ему озвучивали он закрыл, то что делать он не умеет - он честно про это вам сказал, а не стал гуглить и тянуть время - как обычно бывает. Так что далеко не все так однозначно.
P. S. и причём здесь платный NestJS?
Понял, а если blur наложить - шум не уменьшится?
Если кубики - как получаются внешние поверхности как полу-сферы?
Вообще, очень круто было бы увидеть что-то такое же как в этой статье.
Ибо сейчас все юзают шейдеры и не парятся, а вот на чистом си не найти.
А исходники где-то можно посмотреть? Особенно дыма.
Вот и так считаю - куда проще заинклюдить проверенный файл и вообще больше на это время не тратить.
Переиспользование универсального кода как раз и даёт возможность снизить стоимость разработки.
Обычный антидребезг, схем много - простейшая кондер 100nf параллельно кнопке.
О правильности я в конце первого комментария написал - нужно всеми силами избегать блокирующего кода везде, где только можно (не только в микропроцессорах) , и использовать его только тогда, когда это прямо реально нужно и кейсов таких от силы пол-процента наберется.
Задачу можно решить быстро и в лоб, а можно решить хорошо. Блокирующий - это всегда быстро и в лоб, что потом чревато проблемами и переделками.
Потому что это более универсальней и покрывает весь спектр задач, это можно сделать один раз, а потом лишь переиспльзовать будучи на 99% уверенным, что код этот может всегда расширить на бОльшее колво случаев и работать он будет предсказуемо и четко. При этом самого кода при таком подходе будет не сильно больше, нежели у решения в лоб.
Ну, надо начать просто - чем больше, тем лучше будет.
Например, появляется возможность использовать классы как скоп, чтобы не гадить в глобальную область видимости. (можно статический, если не предвидится несколько таких).
Использовать объекты, когда есть что-то повторяющиеся в системе (кнопки, например).
Использовать ссылки, вместо передачи по значению.
Ну и возможность выносить класс или набор классов, как отдельный файл с отдельным функционалом - это прямо киллерфича - глобал не загрязняется, а порождая тип, ну например OLED display( PORTA, PIN1) сразу понятно что куда почему + инициализация, если нужна.
Это вот прямо самое базовое.
Раньше C++ не использовался ввиду того, что давал оверхэд при компиляции для микропррцессоров, сейчас компиляторы его практически не дают - разница может составлять совсем не много около - 0.2-0.5%
И раньше я также писал только на C из-за этого, сейчас куда правильней писать на C++ и иметь все его плюшки - программы получаются проще и гораздо более гибкими.
Но понятно, что при использовании C++, надо и метрологию его использовать, а не процедуры + вкоряченный класс)
При этом может получиться очень интересная штука - программа, написанная на C++ с использованием C++ особенностей получится меньшей по размеру и более быстрой, чем делующая тоже на C. На небольших программах это практически не видно, а вот с увеличением размера начинает ощущаться.
Но — блокирующий опрос кнопок — это очень плохо, особенно, если проект сложный.
Вообще все блокирующее в микроконтроллерах — это всегда плохо, особенно, если их быстродействие не велико.
Гораздо правильней делать это с помощью чего-то похожего на конечный автомат.
И так и делают — одна из самых популярных (но не самых крутых) — это библиотека по работе с кнопками от AlexGyver.
Суть в том, что есть структура (или класс) кнопки, где хранится ее состояние, когда было это по времени (значение таймера отсчета), предыдущее состояние и тд.
И на основе этих данных можно и дабл- и трипл-клики обрабатывать, и удержание и клик+удержание и много чего еще, причем с помощью очень небольших изменений кода.
И для того, чтобы обновить состояние — нужно просто вызвать некую фю, передав туда отсчет времени. И делать это можно где-угодно — хочешь — в таймере, хочешь — по прерыванию, хочешь — в основном цикле. Лишь бы паузы между вызовами были не слишком большие — иначе реакция будет подтормаживать. А так — один раз тайминги настроил и забыл.
Это удобней и в разы универсальней.
При этом таких кнопок сколько угодно можно породить (хоть динамически), а в функции(ях) опроса можно эти кнопки либо последовательно перебирать, либо сразу все, либо по одной на вызов фии, либо вообще сделать одну фю на все кнопки. Все это отлично ложиться на классы в C++, да и вообще на ООП.
И самое главное — опрос не мешает выполнятся остальным частям кода.
Не используйте блокирующий код, пока вы четко не понимаете, что он действительно необходим. И это относится не только к кнопкам или микроконтроллерам.
Я ещё в первой части просил вас дать реальный пример, в котором можно увидеть, почему описанная вами проблема происходит, и на 90% это будет скорее всего из-за неправильной архитектуры.
У нас огромное и сложное SPA с кучей бизнес-логики и ни разу не нужно было городить какие-то отдельные, внешние классы, да ещё и связывать их с компонентами. Если общее (данные, логика) - все лежит в сторе, если компонентное - в компоненте(ах).
Все ещё не понятно, почему вы класс с данными и какой-то логикой называете сервисом. Сервисом чего он является?
Если вам действительно необходим некий общий сервис с реактивностью, почему просто не импортировать его и вызывать его фии для получения или установки каких-то его состояний? Реактивность можно добавить, через computed/watch в самом компоненте, где это необходимо, причём будет чётко видно что за сервис и как вы его используете, без какой либо внутренней магии.
Вобщем, без реального примера понять зачем это все понадобилось конкретно вам - невозможно. Как и понять верность выбора и плюсы вашего решения.
P. S. Зачем используете proxy для readonly? Почему не обычный сеттер?
Но смешивать бы точно не стал.
Из документации по VUE.
VUE Composition API появилась только во VUE3.