ну у мене там ± все абстраговано — я не напряму в бази питаю а через функціі (тіпа як ORM але не зовсім). дякую за аналіз паттерну, та feedback

До початку огляду військовий комісаріат має отримати та передати для вивчення ВЛК:

на всіх військовозобов’язаних — дані з психоневрологічних, протитуберкульозних, шкірно-венеричних диспансерів, наркологічних закладів; на тих, що перебувають на обліку у вказаних диспансерах, закладах — витяг з історії хвороби;
на осіб, яким встановлена інвалідність — дані з органів соціального забезпечення, медичну картку з поліклінік та медико-санітарних частин за місцем проживання, роботи або навчання;
на офіцерів і прапорщиків (мічманів) запасу також особові справи.
Перед оглядом проводиться:

флюорографічне обстеження,
загальний аналіз крові,
визначаються група крові та резус-належність (особам, у яких немає відповідної відмітки у військовому квитку),
ЕКГ,
дослідження сечі.
Особам, яким більш ніж 40 років, обов’язково ще роблять вимір внутрішньоочного тиску та дослідження крові на цукор

удивляюсь, как в Харькове все вот это делают за 8 минут.

у мене був випадок коли від маленької іскри при підключенні акумулятора він вибухнув, це просто для інфи, що може теоретично то так і є, як ви кажете, а практично буває дуже небезпечно

Це не ідеальний інструмент для коротких скриптів і утиліт командного рядка

В деяких ситуаціях допоможе nbb чи Babashka

я вчора консультувався, мені кажуть що це не зовсім так, і потрібно щє доплатити 22% ЕСВ буде, з цього «доходу»

ця інфа є неофіціоною, поки що. тобто, рівень довіри такий же, як і до іншої інфи з приводу неофіційного спілкування з представниками влади. у канві загальної інформаціі я вважаю що так воно і є, планують, але чи буде це чи ні, залежить і від нашої реакціі на Дія Сіті

Чтобы выйти из «аутсорс болота» (т е я так понимаю — торговли «сырой» рабочей силой, с минимумом добавочной стоимости) надо вначале бы разобраться с судами и соблюдением законности, чтобы возможно вообще было делать R&D и инновации, которые бы не украли сразу же. А в той де Дія Сіті заложен механизм, по которому фирма обязана предоставить всю информацию, в том числи и ту, что под NDA, проверяющим, если такового не предоставлено, исключение из рядов и «досчитывание» налогов по общей системе. Т е я в целом не против технопарков, но если уже делать технопарк, то делать так, чтобы в него хотелось идти, а не так, что в него запихивают насильно.

Второе. Я — независимый контрактор. У меня несколько компаний, с которыми я работаю на протяжении уже десятка лет и более. По изложеной логике выходит я им должен сказать досвиданья, и искать себе новую работу, с заведомо более низкой оплатой труда локально? Да мне проще оставить всё как есть и уехать на ПМЖ куда нибудь в ближайшую страну типа Грузии/Эстонии/Польши и тп — туда, где готовы будут принять меня, с моими текущими контрактами и деньгами чем терять и снова искать работу с нуля в 40+.

Вне закона. Я уже подумал что как вариант, если удалёнщиков у одной конторы много, можно просить компанию открыть украинское юр. лицо. Но если не наберётся нужного количества, или компании неинтересно играть в эти игры, досвиданья

ФОП — це однозначно чорна схема

По перше не «чорна», а «сіра», навіть стосовно найму.

По друге, «сіра» ця схема не у всіх випадках... Я можу зрозуміти таку классіфікацию, коли це стосується взаімовідносин між украінською компанією та працівниками, але я не розумію кому заважає, коли ФОП консультує декілька компаній не в Украіні. Тобто, після заборони ФОП 3ю группи, я банально втрачу роботу і це мене непокоїть, особливо коли це називають «чорною схемою», не треба так підігрівати, це не чорна и не сіра схема, коли окрема людина працює як консультант.

Возможно автор и перегнул палку но в целом идея здравая: при наличии заведомо большого кол-ва однотипных товаров на складе считать каждую транзакцию по отдельности слишком накладно. Возможно гибридное решение о применении транзации должно принматься на соотношении остатков к кол-ву товара проданного в единицу времени.

зависит видимо от того, каким WM вы пользуетесь. дефолтные Mac, Linux/Unity и Windows не сильно хороши с несколькими мониторами. в конфигурации с тайлинг manager несколько мониторов дают больше плюсов

Почитайте автора GTD David Allen новую книгу Ready for ANYTHING. Я делаю так — ставлю N интервалов на день, планирую чем в каждом интервале буду заниматьсья, и не отвлекаюсь в это время. В конце концов не отвлекаться заданное время не сложно.

Только ставьте время 52 минуты для работы и 17 для перерыва. Сам пытался работать по 25, понял что не очень эффективно, часто пытался перерабатывать т к не хотелось прерываться. Теперь ясно, почему: lifehacker.com/...eal-productivi-1616541102

Это если буквально переводить название. В реальности IDE это обычно что то монстрообразное, сознательно ограниченное в сфере применения под отдельный язык
платформу, заточенное под конкретную цель.

Тарас, я описал реальную ситуацию. Это на самом деле довольно типичная ситация когда программист интроверт, не в состоянии работать в коллективе. Иногда такие люди пишут хороший код, иногда не очень, это в общем то некритично. Главное тут то, что человек, которого я нанял должен быть готов к тому, что если проект пойдёт не на помойку, а реально начнёт приносить прибыль, то мы можем прийти к ситуации когда один человек этот проект не тянет. И на этом этапе уже становиться важным то, насколько человек адекватен и готов работать в коллективе. Часто он не готов. Как бы я не старался как менеджер оградить человека от моральной травмы общения с другими программистами, иногда самое гуманное что я могу сделать для него и для команды в целом — уволить (и конечно же, это не приносит мне удовольствия). Потому постарался дать такой совет — даже полных интровертов надо зараннее приучать к тому, что код не является их личной собственностью, а продукт взаимодействия команды. Иначе, в ряде случаев конфликта не избежать.

Почему подпорка ответить просто — если уж мы девелопим фичу в ветке, то логично было бы делать выводы оттуда а не заставлять разраба писать в каждом коммите. Во первых надо сделить за дисциплиной, чтобы не забывали ставить, ну или как уже советовали сделать запрет на push изменений без подписей тасков. Мы так делали пока работали в svn, ну и сейчас это применяем в Jira + Git. Да, мою проблему этот подход решает, но называть его особенно удобным, имея рядом пример другой организации того же процесса я не могу.

Хорошо, допустим после моих изменений для новой фичи X в ветке валится тест Y, как понять какое бизнес требование тест Y отслеживает? Я должен сформулировать проблему в терминологии: «При попытки реализации фичи X нарушается целостность исполнения бизнес требования Z, с привязанным тестом Y». Что делать далее? Как выяснить какую часть заложенной логике и какие бизнес требования поломались? Большая часть команд валят всё на отдел QA, пусть они сами разбираются. Мне же такой подход претит, он занимает в разы больше времени и не даёт качественного результата, т к метаданные могут отсутствовать (зависит от того, насколько хорошо организвана работа отдела QA). Я же просто избегаю лишних шагов, если есть ветка, могу сказу сказать о том, какое бизнес требование Z будет нарушено в связи с введением новой фичи X и далее инициировать дискуссию бизнес аналитики, QA и меня как разработчика.

идея то простая — если мы *уже* пользуемся бранчами при создании новых фич, то в дальнейшем можно было бы положиться на эту информацию для раскрутки обратного процесса (см ниже). но суть простая — и польза следующая — допустим заказчик поручает сделать фичу X, программист открывает код, начинает менять, и находит кусок логики, включая unit test который повалится после введения новой логики, для фичи X. Вот тут внимание вопрос — к кому идти с вопросом, и как его сформулировать? я обычно формулирую просто — логика фичи X, противоречит логике фичи Y (нахожу бизнес требование к Y по коммиту, далее таску и связке). Без этой связки фича X конечно заработает, но разборки потом почему логика X поломало Y, Z ложится целиком на плечи QA. Я не привык ломать а потом разбираться, лучше вначале разобраться, и делать свои изменения осознанно, в рамках понимания проекта целиком а не логики отдельной фичи которая делается сейчас