Алексей Уколов

Стандартной практикой является коммит в репозиторий файла phpunit.xml.dist в который прописываются все настройки по умолчанию, кроме чувствительных к безопасности (api ключи, пароли и пр). Файл phpunit.xml добавляется в .gitignore. Таким образом, если пользователю нужно кастомизировать какие-то параметры, он просто копирует файл phpunit.xml.dist в phpunit.xml и добавляет свои секреты в последний. Это безопасно, так как phpunit.xml заигнорен.

То что вы описываете - это уже не unit, а интеграционное тестирование. Скрипты для интеграционного тестирования обычно делают в отдельном testsuite и скипаются по умолчанию. Для запуска юнит тестов не должна требоваться какая-либо подготовка - только "склонировал репозиторий, запустил". Для интеграционных подготовка уже нужна. Например, юзер должен будет модифицировать phpunit.xml (не .dist!), вписав туда свой тестовый api ключ.

Соответственно, для юнит тестов достаточно в тестируемый код передать мокнутого http клиента, который будет возвращать ответ, который вернуло бы реальное стороннее api (в guzzle это делается с помощью MockHandler). Поэтому если надо просто запустить юнит тест, то ничего делать не нужно - phpunit автоматически подхватит phpunit.xml.dist, если не найдет phpunit.xml. Если надо запустить интеграционные, то юзер должен будет скопировать phpunit.xml.dist в phpunit.xml и добавить туда api ключ.

dadata.ru

твой уровень программирования "школьник 9го класса, изучающий полгода java"

Чтобы не было, например, "обрезаний" при разных разрешениях экрана или "дополнения" пустых мест его дублированием

Геометрия говорит нам, что если пропорции блока и изображения не совпадают, то возможны три варианта:
- поля
- обрезка лишнего
- искажение пропорций

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

Но кроме пропорций, есть ещё поддержка форматов и плотность пикселей. Так что, сложность тут не одна.

Какие размеры файла желательны (в байтах)?

Минимальные. При этом нужно сохранять достаточное качество.

Этот вопрос не имеет смысла, даже если вы скажете размер вьюпорта/блока, но не покажете картинку. Потому что одна сожмется прекрасно, а другая заметно потеряет в качестве.

Для ретины и разных форматов файлов используйте image-set
Для разных размеров - @media
Для оптимизации размеров - форматы webp, avif

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

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

Их две:
РКН
ТСПУ

Никак не называется. Можно структуры комбинировать для ваших задач, но это частные случаи применения структур, не настолько частые, чтобы давать этой комбинации какое-то имя. Если уж хочется назвать это как-то, то это все еще будет хеш-таблица с какими-то вспомагательными пристройками для каких-то дополнительных нужных вам свойств (итерация).

И вообще, у вас тут намудрено, почему нельзя сделать просто:
let objects: HashMap<Uuid, Object>;

Тут все такой же O(1) доступ к элементу по id. Зачем вам массив? Вы там добились простой и cache-friendly итерации по всем объектам? Не факт, что это уже не реализовано внутри HashMap. По крайней мере во многих языках можно проитерироваться по всем объектам в стандартной хеш-таблице.

Зато у вас там удаление элемента - это что-то сложное. Особенно, если вы не хотите избежать фрагментации и неиспользованного места в массиве.

И хочется наябеднечать модеру, но такой возможности нет((

https://qna.habr.com/feedback

Смысл есть, когда вы пишите аннотацию для аннотаций и необходимо применять ее и к самой аннотации. Самый яркий пример - @Retention и @Target. Для самих @Retention и @Target аннотаций они тоже необходимы, т.к. применяется к аннотациям. Вот такая рекурсия. На практике же крайне специфичный кейс