Игорь

Для MySQL 8

WITH `cte` AS (
  SELECT *,
         ROW_NUMBER() OVER (
           PARTITION BY `contact_id` ORDER BY `created_at` DESC
         ) AS `row`
    FROM `contacts_history`
    WHERE `created_at` BETWEEN '2021-02-05 15:56:57' AND '2021-02-20 13:44:09'
) SELECT *
  FROM `cte`
  WHERE `status_id` = 37
    AND `row` = 1

Только учитывайте, что это будут последние записи в заданном интервале. Если статус контакта менялся позже, то это не будет отражено в запросе.

Делал нечто подобное, получилось так:

namespace App\Doctor;

use App\Doctor\Check\CheckInterface;

final class Doctor
{
    /**
     * @var CheckInterface[]
     */
    private iterable $checks;

    public function __construct(iterable $checks)
    {
        $this->checks = $checks;
    }

    /**
     * @return Violation[]|array
     */
    public function check(): array
    {
        $violations = [];
        foreach ($this->checks as $check) {
            $violations[$check->feature()] = array_merge($violations[$check->feature()] ?? [], $check->violations());
        }

        return $violations;
    }
}

namespace App\Doctor\Check;

use App\Doctor\Violation;

interface CheckInterface
{
    public function feature(): string;

    /**
     * @return Violation[]
     */
    public function violations(): array;
}

services:
    _instanceof:
        App\Doctor\Check\CheckInterface:
            tags:
                - { name: app.doctor.check }

    App\Doctor\Doctor:
        arguments:
            $checks: !tagged app.doctor.check

public function doctorAction(): JsonResponse
{
    return $this->json($this->doctor->check());
}

{
    "foo": [], // Ok
    "bar": [
        { "message": "Отсутствуют статусы", "treatment": "Добавьте статусы" }
    ]
}

Как вариант, можно группировать проверки по фичам, чтоб не проверять все, когда нужна информация по конкретной фиче, но для этого надо будет CompilerPass заюзать

Вы просто столкнулись с общей проблемой переиспользования кода.
Конечно хочется писать код один раз и избегать копипасты, но не всегда этого легко достичь.

Побороть эту проблему может только грамотное планирование структуры програмы. Далеко не всегда можно достичь нужного результата с первого раза, приходится делать рефакторинг.

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

Самое правильное сейчас , если надо иметь докер под виндой - поставить WSL2 , запустить там например Убунту, и туда, штатным способом установить "нормальный" докер, а не вот этот костыль.

Как всегда - все хотят получить много, а заплатить мало. Это работорговля. :-/ Хотите качество? Платите достойно! Иначе получите абы что и злого недовольного сотрудника/фрилансера.

Это вы себя накручиваете.

Никто специально не сидит и не учит все термины. Тут как с другим языком — чем больше общаешься, тем лучше запоминаешь. Тут тоже самое: чем больше используешь определённые технологии, тем больше будешь знать терминов из этой области. А что не используешь, то конечно же забываешь. Не бери в голову. Если собес не проходит только из-за :not, то оно и к лучшему

Ищите человека с заниженной самооценкой или объективными изъянами, с которыми вы готовы мириться, а рынок в среднем не готов. Таких на удивление немало. Явление может (и будет) сопровождаться некоторыми побочными эффектами, типа нездорового перфекционизма, алкоголизма и перебоев в мотивации.

Файл, похоже, в формате json. Гуглите "json <ваш язык прогаммирования>", чтобы найти библиотеку для парсинга этого формата. Потом надо обрабатывать семантику языка.

Поля "$designer" похоже можно игнорировать. Дальше у каждого важного элемента есть поле "$kind". Читайте описание в схеме, которая по ссылке в конце файла "https://raw.githubusercontent.com/microsoft/BotFra..."

Фактически это задана программа на весьма неудобном для человека языке программирования. Каждое действие - это узел в json. Он имеет kind, который определяет, что это за инструкция и всякие дополнительные поля, которые описывают параметры этой инструкции. Типа инструкция ветвления содержит команды для обеих веток исполнения и условие. В этом языке, похоже есть циклы, встроенные функции. Похоже, пользователь может задать какие-то свои функции, вызов которых вам тоже придется обрабатывать.

После разбора файла json-парсером, надо писать обработку каждого типа действия, которое есть в этом файле. Это будет полноценный интерпретатор этого странного языка программирования.

Например, "Microsoft.ForEach". Поищите эту строчку в схеме, она будет встречаться 6 раз. Интересное место №3 - там расписано, какие поля могут быть у этого типа действия. Там куча очевидных полей вроде designer и kind, но есть нужное нам "actions". Описание говорит, что это массив действий, которые будут вызваны для всех элементов списка. Т.е. встретив в файле узел foreach, надо взять поле "actions" и применить все действия оттуда ко всем элементам входного списка.

И так надо по каждому "kind" действия писать обработку. Проще всего его будет писать на каком-то интерпретируемом языке, где есть что-то типа eval(). Потому что, например, в IfCondition есть поле condition, которое придется вычислять. Надо будет поддерживать какой-то словарь для всех переменных, локальных и глобальных, поддерживать стек вызова и словарь всех известных пользовательских подпрограм.