Общее образование - региональные деньги. Стучаться в муниципалитет смысла нет - они конечные исполнители, сколько им денег выделили на школу, столько они и потратили. Их ответ абсолютно корректен - денег нет. Впрочем и абсолютно бесполезен.
Стучаться надо в региональный отдел (или что там) и там требовать выделения дополнительный средств.
Да, по идее, этот вопрос вообще не должен был возникнуть. Региональный отдел образования должен этот момент выявлять самостоятельно. Мэрия видя заминку тоже должна действовать упредительно. Есть еще институт муниципальных и региональных депутатов, которые вполне могут поднять этот вопрос превентивно, не дожидаясь собраний недовольных граждан.
Тут проблема не в межбюджетных трансфертах, а в том, что госаппарат занимается какими-то другими, более приоритетными по их мнению вещами, а не скукотищей со школьными автобусами.
Тут надо смотреть, что за трансферты. Потому что, например, если муниципалитет активно участвует в разного рода программах, то это целевые деньги на конкретные капитальные проекты. На текущие расходы собственных доходов вполне хватает.
чем она обязана потратить
Это не так работает. Есть, например, дотация на выравнивание уровня бюджетной обеспеченности - как раз для поддержания уровня собственных доходов бюджета. В итоге муниципалитет вполне имеет возможности обеспечивать свои текущие потребности. Новые капитальные проекты на собственные деньги сложно делать, но поддерживать текущую инфраструктуру вполне реально.
Есть субвенции. Например на содержание школ - деньги предоставляет регион, но физически тратит их муниципалитет. Эти деньги - целевые, их можно тратить только по назначению. По факту просто раздувание оборотов, т.к. сколько пришло, столько и должно уйти. Это не деньги муниципалитета, и не деньги "губернатора" - он не может их не выдать. Их можно смело вычитать из доходов и расходов.
Есть субсидии - как раз разные проекты и т.п. Тоже целевые деньги. Вот это как раз и есть те самые которые "дает губернатор". Тут, да, политические моменты возникают в полной мере.
Например гендиректора компании "Уралкалий" арестовали в Минске, когда он пытался организовать поглощение "Беларуськалия".
Арестовали не за то, что он пытался купить то, что продается, а пытался организовать продажу того, что продавать никто не собирался.
Любопытно, что при этом аналогичное дело на него завели и в РФ, и даже объявили в международный розыск. Ну так себе из него агент влияния оказался и по факту, и медийно, и юридически.
Позвольте, а как же местные налоги и сборы? Ну всякие там земельный налог, налог на имущество физических лиц, налог на рекламу, налог на наследование или дарение, местные лицензионные сборы и т.п. Они спокойно себе зачисляются в полном размере в местный бюджет.
А еще есть региональные и федеральные налоги часть из которых поступает в местные бюджеты, например для городских округов 100% от ЕНВД, 15% от НДФЛ.
А есть еще и неналоговые доходы - например аренда муниципальной земли и недвижимости.
Все это формирует собственные доходы местного бюджета, независимо от федеральной или региональной власти.
В банках свои причины работать с такой абстракцией как опердень. И одна из этих причин - легаси: изначально банковское с его объемами транзакций по другому просто не умело.
Подобные подход применяли и в бухгалтерском ПО - тот же БЕСТ например. Да и в самой 1С в 6.0 так было, в 7.7 даже отдельная процедура была открытия нового периода, а в регистрах расчетов даже закрытие.
Тем не менее подход 1С реализованный в 8.х - оказался очень удобным, а закрытие периода - всего лишь прикладная опция, которая блокирует проведение документов ранее определенной даты.
По поводу работы в разных временных зонах - опять же, если для банковского ПО это норма, и эту возможность закладывали на этапе проектирования, для автоматизации бухгалтерии это скорее исключение, и, неудивительно, что этот функционал не реализован в системе.
При этом, возможность построения решений корректно работающих в разных часовых поясах у платформы 1С:Предприятие 8 есть, и более того, есть стандарт вендора для разработки таких решений.
Чем больше активных фотографов, тем меньше активных фотографов. Вряд ли активные объекты съемки будут разглядывать камера ли это.
Вроде же специально всякие журналисты и т.п. наблюдающие должны быть максимально отличимы от вооруженных участников конфликта. А такой девайс значительно снижает степень этой самой отличимости.
Собственно, а в чем, по мнению учредителей, девочки некомпетентны? Кейс как раз описывает КОМПЕТЕНТНЫХ в своей области сотрудников. Один продает, другой осмечивает.
Без продаж нечего осмечивать, без сметы нечего производить, без производства нечего продавать.
Если вы в ТиС и вообще в 7.7 использовали такие запросы, то это точно не проблемы движка платформы 7.7. Это решение сторонних разработчиков так позволяло делать, причем через инжект в стандартные dll платформы. Вполне логично, что сторонний продукт мог работать нестабильно, и странно при этом предъявлять претензии к релизам платформы, которые якобы "чинили эти глюки".
файловая база возвращает select * from aaa where id>10 одни данные, а на sql базе уже другие…
Это сильно вряд ли - сам набор данных (количество строк и каждая строка в отдельности) будут идентичны, а вот идентичный порядок строк указанного запроса, даже в рамках двух последовательных вызовов, вам не гарантирует ни одна современная СУБД.
В принципе тесты которым нужны данные в базе (а их подавляющее большинство) мы так и проверяем - формируем контекст, вызываем функцию, проверяем значение.
А что делать когда извне должен провайдер данных приходить какой нибудь, или фабрика? Как это без ООП реализовать то получится?
Передаете параметром нужный провайдер или фабрику. Внутри метода обращаетесь к нему. В чем сложности-то.
ИМХО, вы почему то считаете, что принципы SOLID применимы только к ООП языкам, а это совсем не так. То что на ООП языках эти принципы удобно иллюстрировать не означает, что только там они и работают.
Ну т.е. уже можно в методе с директивой &НаСервере написать что то вроде
Разве когда-то было нельзя? Указанный код вроде работает во всех платформах начиная с 8.0.
Задания = Новый Массив;
Для Каждого ЭлементДаных из МассивДанных Цикл
Параметры = Новый Массив;
Параметры.Добавить(ЭлементДанных);
ФоновоеЗадание = ФоновыеЗадания.Выполнить(ИмяМетода, Параметры);
Задания.Добавить(ФоновоеЗадание);
КонецЦикла;
Для Каждого Задание из Задания Цикл
Задание.ОжидатьЗавершения();
КонецЦикла;
У вас слишком сложно все получается, и все в кучу - и собственно архитектура проекта, и тесты. На наших проектах как-то мы обходимся без описанных вами ужасов.
Что за контексты репозиториев и прокидывание общих модулей? Куда и зачем вы их прокидываете?
Не вижу именно тут прям в этом жутких костылей. Контекст вызова общего модуля всегда известен, полностью передается извне - шикарное свойство для юнит-тестов. То что надо озаботится написанием обвязки - это потом многократно себя окупает. Четкого следования принципам SOLID вполне достаточно.
Рискую пованговать, но в вашем проекте эти вопрос не были решены, и это приводило к огромным вложенным структурам передаваемым в контексте. Этого добра прям много в типовом коде от вендора, и, увы, разработчики зачастую копируя этот стиль превращают свой проект в монстра.
А как мокаете вызов базы, выполнение запросов, объектную модель?
База часть рантайма, смысла ее мокать нет.
А где у вас D если вы явно тип задаете конкретный и получается вполне обычная зависимость, а не инверсия?
Пример с передачей параметра вместо создания объекта внутри, это же самые азы "D". Т.е. этот принцип вполне применим уже с самых простых примеров. Обычно же там проверка, в которой проверяется наличие и типы полей нужных по контракту. Т.е. есть описанный контракт, есть его конструктор и функция проверки значения на соответствие контракту.
А по поводу разницы тредов и фоновых заданий — у тредов сильно больше возможностей. Начиная от возможности память шарить, и заканчивая возможностью дождаться результата выполнения распараллеленной задачи на локе.
Так и мы в ФЗ и лочим, и можем ждать, и можем запускать пулы обработчиков (десяками).
Мы на своих проектах выносим логику UI от логики объекта.
В типовых от вендора, да, там такого регулярно. Это довольно сильно напрягает разрабов, т.к. код вендора очень архаично выглядит по сравнению с нашим, а использовать надо и тот и тот.
Модули в 1С не имеют контекста, и весь контекст в вызов надо передавать явно. Это влечет за собой отдельные соглашения о том как создавать и модифицировать контекст. Зато упрощает выше озвученное тестирование, т.к. весь контекст можно создать за пределами вызываемого метода/общего модуля.
Общее образование - региональные деньги. Стучаться в муниципалитет смысла нет - они конечные исполнители, сколько им денег выделили на школу, столько они и потратили. Их ответ абсолютно корректен - денег нет. Впрочем и абсолютно бесполезен.
Стучаться надо в региональный отдел (или что там) и там требовать выделения дополнительный средств.
Да, по идее, этот вопрос вообще не должен был возникнуть. Региональный отдел образования должен этот момент выявлять самостоятельно. Мэрия видя заминку тоже должна действовать упредительно. Есть еще институт муниципальных и региональных депутатов, которые вполне могут поднять этот вопрос превентивно, не дожидаясь собраний недовольных граждан.
Тут проблема не в межбюджетных трансфертах, а в том, что госаппарат занимается какими-то другими, более приоритетными по их мнению вещами, а не скукотищей со школьными автобусами.
Тут надо смотреть, что за трансферты. Потому что, например, если муниципалитет активно участвует в разного рода программах, то это целевые деньги на конкретные капитальные проекты. На текущие расходы собственных доходов вполне хватает.
Это не так работает. Есть, например, дотация на выравнивание уровня бюджетной обеспеченности - как раз для поддержания уровня собственных доходов бюджета. В итоге муниципалитет вполне имеет возможности обеспечивать свои текущие потребности. Новые капитальные проекты на собственные деньги сложно делать, но поддерживать текущую инфраструктуру вполне реально.
Есть субвенции. Например на содержание школ - деньги предоставляет регион, но физически тратит их муниципалитет. Эти деньги - целевые, их можно тратить только по назначению. По факту просто раздувание оборотов, т.к. сколько пришло, столько и должно уйти. Это не деньги муниципалитета, и не деньги "губернатора" - он не может их не выдать. Их можно смело вычитать из доходов и расходов.
Есть субсидии - как раз разные проекты и т.п. Тоже целевые деньги. Вот это как раз и есть те самые которые "дает губернатор". Тут, да, политические моменты возникают в полной мере.
Суммы вполне сопоставимые. Смотрим, например, бюджет Калининграда за 2022 год:
Собственные доходы: 12234,8 млн. руб.
Поступления от других бюджетов: 13473,9 млн. руб.
Естественно имеет - как минимум, нужно оставаться при этом в правовом поле той страны, в которой ты пытаешься увеличить влияние.
Насчет красных линий - поддерживать действия уголовника объявленного ей же (Россией) в международный розыск, да не рискнула.
Арестовали не за то, что он пытался купить то, что продается, а пытался организовать продажу того, что продавать никто не собирался.
Любопытно, что при этом аналогичное дело на него завели и в РФ, и даже объявили в международный розыск. Ну так себе из него агент влияния оказался и по факту, и медийно, и юридически.
Вы сейчас напредлагаете - в Канаде, ЕМНИП, эту выделенную в чеке сумму можно вернуть на свой р/с по истечении финансового года.
Позвольте, а как же местные налоги и сборы? Ну всякие там земельный налог, налог на имущество физических лиц, налог на рекламу, налог на наследование или дарение, местные лицензионные сборы и т.п. Они спокойно себе зачисляются в полном размере в местный бюджет.
А еще есть региональные и федеральные налоги часть из которых поступает в местные бюджеты, например для городских округов 100% от ЕНВД, 15% от НДФЛ.
А есть еще и неналоговые доходы - например аренда муниципальной земли и недвижимости.
Все это формирует собственные доходы местного бюджета, независимо от федеральной или региональной власти.
В банках свои причины работать с такой абстракцией как опердень. И одна из этих причин - легаси: изначально банковское с его объемами транзакций по другому просто не умело.
Подобные подход применяли и в бухгалтерском ПО - тот же БЕСТ например. Да и в самой 1С в 6.0 так было, в 7.7 даже отдельная процедура была открытия нового периода, а в регистрах расчетов даже закрытие.
Тем не менее подход 1С реализованный в 8.х - оказался очень удобным, а закрытие периода - всего лишь прикладная опция, которая блокирует проведение документов ранее определенной даты.
По поводу работы в разных временных зонах - опять же, если для банковского ПО это норма, и эту возможность закладывали на этапе проектирования, для автоматизации бухгалтерии это скорее исключение, и, неудивительно, что этот функционал не реализован в системе.
При этом, возможность построения решений корректно работающих в разных часовых поясах у платформы 1С:Предприятие 8 есть, и более того, есть стандарт вендора для разработки таких решений.
Чем больше активных фотографов, тем меньше активных фотографов. Вряд ли активные объекты съемки будут разглядывать камера ли это.
Вроде же специально всякие журналисты и т.п. наблюдающие должны быть максимально отличимы от вооруженных участников конфликта. А такой девайс значительно снижает степень этой самой отличимости.
Ну раз положено, значит путь ежемесячно сама расписывает вам расчетник. От руки, как положено.
Собственно, а в чем, по мнению учредителей, девочки некомпетентны? Кейс как раз описывает КОМПЕТЕНТНЫХ в своей области сотрудников. Один продает, другой осмечивает.
Без продаж нечего осмечивать, без сметы нечего производить, без производства нечего продавать.
Если вы в ТиС и вообще в 7.7 использовали такие запросы, то это точно не проблемы движка платформы 7.7. Это решение сторонних разработчиков так позволяло делать, причем через инжект в стандартные dll платформы. Вполне логично, что сторонний продукт мог работать нестабильно, и странно при этом предъявлять претензии к релизам платформы, которые якобы "чинили эти глюки".
Это сильно вряд ли - сам набор данных (количество строк и каждая строка в отдельности) будут идентичны, а вот идентичный порядок строк указанного запроса, даже в рамках двух последовательных вызовов, вам не гарантирует ни одна современная СУБД.
Ну вот к примеру простейший тест, на то что вернет база. Тесты функции СсылкаСуществует: https://github.com/yukon39/cfe_tests/blob/main/src/tests/CommonModules/ОбщегоНазначения/Ext/Module.bsl
В принципе тесты которым нужны данные в базе (а их подавляющее большинство) мы так и проверяем - формируем контекст, вызываем функцию, проверяем значение.
Передаете параметром нужный провайдер или фабрику. Внутри метода обращаетесь к нему. В чем сложности-то.
ИМХО, вы почему то считаете, что принципы SOLID применимы только к ООП языкам, а это совсем не так. То что на ООП языках эти принципы удобно иллюстрировать не означает, что только там они и работают.
Разве когда-то было нельзя? Указанный код вроде работает во всех платформах начиная с 8.0.
У вас слишком сложно все получается, и все в кучу - и собственно архитектура проекта, и тесты. На наших проектах как-то мы обходимся без описанных вами ужасов.
Что за контексты репозиториев и прокидывание общих модулей? Куда и зачем вы их прокидываете?
Не вижу именно тут прям в этом жутких костылей. Контекст вызова общего модуля всегда известен, полностью передается извне - шикарное свойство для юнит-тестов. То что надо озаботится написанием обвязки - это потом многократно себя окупает. Четкого следования принципам SOLID вполне достаточно.
Рискую пованговать, но в вашем проекте эти вопрос не были решены, и это приводило к огромным вложенным структурам передаваемым в контексте. Этого добра прям много в типовом коде от вендора, и, увы, разработчики зачастую копируя этот стиль превращают свой проект в монстра.
База часть рантайма, смысла ее мокать нет.
Пример с передачей параметра вместо создания объекта внутри, это же самые азы "D". Т.е. этот принцип вполне применим уже с самых простых примеров. Обычно же там проверка, в которой проверяется наличие и типы полей нужных по контракту. Т.е. есть описанный контракт, есть его конструктор и функция проверки значения на соответствие контракту.
Так и мы в ФЗ и лочим, и можем ждать, и можем запускать пулы обработчиков (десяками).
Мы на своих проектах выносим логику UI от логики объекта.
В типовых от вендора, да, там такого регулярно. Это довольно сильно напрягает разрабов, т.к. код вендора очень архаично выглядит по сравнению с нашим, а использовать надо и тот и тот.
Модули в 1С не имеют контекста, и весь контекст в вызов надо передавать явно. Это влечет за собой отдельные соглашения о том как создавать и модифицировать контекст. Зато упрощает выше озвученное тестирование, т.к. весь контекст можно создать за пределами вызываемого метода/общего модуля.
Как и коллбеки только на клиенте.
Через mock-server мокаем внешние http-сервисы, есть моки для внешнего оборудования, серверов очередей и т.п.
Юнит-тесты классической структуры given/when/then. Формируем контекст вызова, вызываем функцию, проверяем результат.
Для начала вместо:
учимся писать:
Это уже переформатирует мозги разработчиков, и позволяет покрывать код тестами.
Какие странные у вас представления о костылях - ФЗ это как раз имплементация Thread.run(Action).