Не знаю, может так где то и есть, но обычно повышают, за то, что твоё решение денег конторе приноси , а какое оно менеджеру грубо говоря наплевать, ну и ещё расходы на поддержку минимальны.
По моему опыту, делал долго но качественно, никто не вспомнит, что долго делала. Сделал быстро и с багами, все будут помнить только про баги.
А про способ решения вообще никто не спрашивает из тех кто принимает решения по повышению. Смотрят только на результат в деньгах.
Для обработки переменных разных типов, можно было бы использовать шаблон Посетитель, код был избавлены от ненужных If и легко можно было бы добавлять другие типы, не меняя при этом бизнес логику.
Можно использовать второй источник тактирования, например встроенный низко частотный генератор и с помощью него измерять частоту, например период таймера, который затактирован от внешнего генератора
Ещё добавлю 1. Проверка ALU, FPU, регистров, конвейера процессора 2. Проверка CRC ROM памяти, 3.Проверка RAM блюждающтюим битом. 4. Task монитор, следящиц за переодичностью выполнения задач. 5. Защита данных в NV контрольной суммой или инверсной копией. 6. Измерение и контроль тактовой частоты
FDT вообще потихоньку загнулась, еще её поддерживали Vega и Yokogawa, там проблема в кроссплатформенности, оно только под Windows заточено было + проблема с безопастностью.
В итоге остался DD, и FDI, как обобщенная технология на базе DD. Теперь схема такая. DD на входе, транслируется в байт код виртуальной машины. Виртуальная машина её запускает, на выходе интегрируете хоть в FDT, хоть в OPC UA. Сейчас так Pactware последний и работает.
Ну сейчас, во многих универах тоже есть курсы на выбор. Так называемые майноры. Студенты сами себе могут выбрать несколько курсов по тому предмету, который им больше всего пригодится, как они думают.
Первые два курса это лющее, скажем матан и так далее, что пригодится для общего развития в любом случае,
Да на время проекта в основном постоянная на проекте, но могут быть небольшие проекты, тогда сотрудник может в 2 или 3 участвовать. Но там и загрузка конечно не полная. За распределение ресурсов по проектам отвественный начальник отдела.
Каждый месяц есть так называем ресурс планниг там менджеры запрашивают ресурсы по проектам, и начальник отдела может выделить, а может нет. Все зависи от приоритета проекта. На приоритетные проекты всегда ресурсы выделяются. На не приоритетные по остаточному признаку.
Например, менеджер проекта запросил на приоритеный проект 4 человек, начальник отдела может снять прямо всех 4 с низкоприоритеного проекта и дать им. Но это все делается совместно со всеми менеджреами проекта на планировании ресурсами. Менеджер низкприоритетного проекта просто будет сдвигать график.
На месяц никаких движений ресурсов между проектами не будет и конфликтов тоже. А вот через месяц, снова планирование, там могут и приоритет поменять и меньше или больше ресурсов запросить.
Ну это условно, обычно конечно более длинный срок на выделение ресурсов, скажем пол года это 50% случаев.
Ну задачи надо планировать перед спринт ом и это делает обычно лидер. Иначе получается, вы не знаете что делать.
Лидер собственно только этим и заниматься должен, добить весь проект на мелкие задачи, чтобы их могли делать программисты любой квалификации.
Если у вас один человек или даже два все делают, то скрам вам не подходит.
У вас по сути процесса то и нет. Сел и делаю, как понимаю но в любом случае, даже если один делаешь, одну большую задачу, типа сделать. Все хорошо и красиво нужно разбивать на много мелких, которые можно сделать за день.
Вы же уходите домой бросив код на половине функции. Как минимум за день делается что то более менее завершенное. И вы понимали, что делали, значит можно распланировать такие задачи и на 2 недели вперёд.
На месяц уже сложно. А на короткий срок вполне возможно.
Проблема именно в постановке задач у вас и планировании
Ну дак, это неправильное планирование, а не проблема скрама. Не успеваете, но все равно берете столько же на следующий спринт? Вы, в таком случае, и по другой методологии не будете успевать. В скраме минимум бюрократии, надо лишь выделить фичи, распланировать и разбить на задачи. Зная задачи легко их сделать.
Либо уменьшать количество фичепоинтов на спринт, либо людей добавлять. Там вся идея в том, что команда постоянно подстраивается + ретроспектива должна выявлять причины "не успвания" и вводить коррективы
Не знаю, может так где то и есть, но обычно повышают, за то, что твоё решение денег конторе приноси , а какое оно менеджеру грубо говоря наплевать, ну и ещё расходы на поддержку минимальны.
По моему опыту, делал долго но качественно, никто не вспомнит, что долго делала. Сделал быстро и с багами, все будут помнить только про баги.
А про способ решения вообще никто не спрашивает из тех кто принимает решения по повышению. Смотрят только на результат в деньгах.
Для обработки переменных разных типов, можно было бы использовать шаблон Посетитель, код был избавлены от ненужных If и легко можно было бы добавлять другие типы, не меняя при этом бизнес логику.
Мы используем прямо такой же подход, ascidoc, ревью, гит и публикация на анторе,
Мне, кажется от человека зависит. Я вот после выходных, очень плохо втягиваюсь в работу, по сути понедельник у меня пропащий день, до обеда точно.
И чем больше отдыхаю, тем меньше потом работать хочется. После новогодних праздников и отпуска неделю в себя прихожу.
Можно использовать второй источник тактирования, например встроенный низко частотный генератор и с помощью него измерять частоту, например период таймера, который затактирован от внешнего генератора
В линкере настраивается буфер или два буфера, куда предварительно копируются данные из проверяемой области.
Алгоритм такой, копируем скажем 64 байта в буфер, проверяем блок, Потом копируем данные обратно из буфера. И так всю память.
Очевидно, что в момент проверки надо запрещать все прерывания и DMA.
Есть библиотека от STM, она именно это и делает. https://www.embedded-office.com/articles/stm32-safety-platform
Ещё добавлю 1. Проверка ALU, FPU, регистров, конвейера процессора 2. Проверка CRC ROM памяти, 3.Проверка RAM блюждающтюим битом. 4. Task монитор, следящиц за переодичностью выполнения задач. 5. Защита данных в NV контрольной суммой или инверсной копией. 6. Измерение и контроль тактовой частоты
:) Полагаю, я был сильно голодный.
Поэтому МЭК 61508 запрещает использовать динамическое выделение памяти.
Только статика, только создание на стейке
FDT вообще потихоньку загнулась, еще её поддерживали Vega и Yokogawa, там проблема в кроссплатформенности, оно только под Windows заточено было + проблема с безопастностью.
В итоге остался DD, и FDI, как обобщенная технология на базе DD. Теперь схема такая. DD на входе, транслируется в байт код виртуальной машины. Виртуальная машина её запускает, на выходе интегрируете хоть в FDT, хоть в OPC UA. Сейчас так Pactware последний и работает.
В принципе все датчики совместимы их интеграция через, например DD/FDI с OPC UA https://t.me/ddngne
Так наоборот, хорошему коду комментарии не нужны, он самодокументировпн.
volatile и будет все норм.
Да, так и есть, переходит, убираются бакаларвы, магистр, но выбор предметов вещь хорошая, пока усталась.
Россия, конкретно Юургу, как раз мой курс у миноров.
Ну сейчас, во многих универах тоже есть курсы на выбор. Так называемые майноры. Студенты сами себе могут выбрать несколько курсов по тому предмету, который им больше всего пригодится, как они думают.
Первые два курса это лющее, скажем матан и так далее, что пригодится для общего развития в любом случае,
А дальше специфика и можешь сам выбирать ещё.
Ну Европа она такая, в Гданьске, да и в Касселе в Германии, зимой тоже трудно дышать от запаха уголя.
А так в целом согласен, электромобили в городе улучшают экологию.
Да на время проекта в основном постоянная на проекте, но могут быть небольшие проекты, тогда сотрудник может в 2 или 3 участвовать. Но там и загрузка конечно не полная. За распределение ресурсов по проектам отвественный начальник отдела.
Каждый месяц есть так называем ресурс планниг там менджеры запрашивают ресурсы по проектам, и начальник отдела может выделить, а может нет. Все зависи от приоритета проекта. На приоритетные проекты всегда ресурсы выделяются. На не приоритетные по остаточному признаку.
Например, менеджер проекта запросил на приоритеный проект 4 человек, начальник отдела может снять прямо всех 4 с низкоприоритеного проекта и дать им. Но это все делается совместно со всеми менеджреами проекта на планировании ресурсами. Менеджер низкприоритетного проекта просто будет сдвигать график.
На месяц никаких движений ресурсов между проектами не будет и конфликтов тоже. А вот через месяц, снова планирование, там могут и приоритет поменять и меньше или больше ресурсов запросить.
Ну это условно, обычно конечно более длинный срок на выделение ресурсов, скажем пол года это 50% случаев.
Ну задачи надо планировать перед спринт ом и это делает обычно лидер. Иначе получается, вы не знаете что делать.
Лидер собственно только этим и заниматься должен, добить весь проект на мелкие задачи, чтобы их могли делать программисты любой квалификации.
Если у вас один человек или даже два все делают, то скрам вам не подходит.
У вас по сути процесса то и нет. Сел и делаю, как понимаю но в любом случае, даже если один делаешь, одну большую задачу, типа сделать. Все хорошо и красиво нужно разбивать на много мелких, которые можно сделать за день.
Вы же уходите домой бросив код на половине функции. Как минимум за день делается что то более менее завершенное. И вы понимали, что делали, значит можно распланировать такие задачи и на 2 недели вперёд.
На месяц уже сложно. А на короткий срок вполне возможно.
Проблема именно в постановке задач у вас и планировании
Ну дак, это неправильное планирование, а не проблема скрама. Не успеваете, но все равно берете столько же на следующий спринт? Вы, в таком случае, и по другой методологии не будете успевать. В скраме минимум бюрократии, надо лишь выделить фичи, распланировать и разбить на задачи. Зная задачи легко их сделать.
Либо уменьшать количество фичепоинтов на спринт, либо людей добавлять. Там вся идея в том, что команда постоянно подстраивается + ретроспектива должна выявлять причины "не успвания" и вводить коррективы