metallix

В отличие от strlen(), iconv_strlen() учитывает кодировку строки. Длина string не обязательно будет соответствовать количеству байт в ней, так как в различных кодировках различные символы кодируются различным количеством байт, например, юникод может быть и двух-, и четырёхбайтным.

попробуйте mb_substr с указанием кодировки

По-моему, ответ простой - что было записано в договоре, то и обязан.
Т.е. если речь шла о коде - то только код. Если договаривались о "запустить на сервере" - то надо ставить на сервер. Но вот о том, что для вебсервера используют Мак, я еще не слышал :-)

От проекта зависит. На моëм проекте например новичкам даже сеньорского уровня до первой простой таски требуется недели две, а выход на 100℅ эффективность занимает 3-6 месяцев.

Опишу простыми словами для упрощения понимания.

модульное тестирование

Тестирование конкретного модуля. Обычно - это самый нижний уровень, отдельные простые классы, т.е. ниже по логике уже будут отдельные функции. Например, в JS есть класс Math - тестирование всех его методов и есть модульный тест. Конечно, границы между логическими уровнями могут быть размыты и в данную категорию вполне можно вписать класс уровнем выше. Так же, модулем может быть и что-то более сложное - опять же, много зависит от масштабов и особенностей архитектуры.

интеграционное тестирование

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

функциональное тестирование

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

какими инструментами оно делается?

Инструментами автоматизации GUI - для сайтов это Selenium и браузеры. Для десктопных/мобильных приложений аналогичные решения.

приемочное тестирование

в че отличие от интеграционных.. еще видел фразу что тут и фронт и бек тестируются, но яснее не стало, какими инструментами оно делается?

"Бизнес" заказал в "Конторе" разработку сайта, выдал ТЗ, контора сделала сайт, бизнес заплатить денег обещал. Как бизнес проверит что контора сделала именно то, что он хотел? Через приемочное тестировние - бизнес получает доступ к сайту и проверяет, что сайт именно такой, какой он заказывал в ТЗ, а не тот, который сделали индусы за доширак. Если в ТЗ указан конкретный список тестов/фич - используется этот список или так, как прописано в ТЗ само тестирование. Само тестирование проводит соответствующий специалист (инженер отдела качества) - тыкает все кнопочки, нажимает менюшечки и говорит начальству "все окей, подписывай и платим им деньги" или "вот тут и тут не окей, не подписывай, денег не давай". Реальный пример: была заказана и собрана станция спутниковой связи, на приемке были представители заказчика и исполнителя, была толстая пачка бумаги на несколько сотен страниц, по которой первые проверяли что все работает именно так, как там написано в течении нескольких недель (плюс-минус), а вторые исправляли косяки показывали что все окей, потом все поставили свои галочки и крестики и разъехались по домам.

E2E - тут тестируется чрез браузер, с помощью Mocha и тп, те тестируются "требования бизнеса к приложению", тестируются пользовательские сценарии.. а в чем отличие от функциональных тестов тогда?

Сквозное тестирование. Это полная проверка от начала и до конца. Отличие от функционального в том, что это более комплексный тест. Если функциональное тестирование - это проверка конкретной функции, тот сквозное - работа всего приложения, т.е. более комплексное. Например, E2E тест приложения для загрузки файла на сервер: тест включает в себя запуск приложения, авторизация пользователя, выбор файла, указание мета информации, загрузку файла на сервер, выход из приложения. Вот тут неплохая статья на хабре: https://habr.com/ru/company/otus/blog/681066/

Совсем запутался, с unit только понятно, а как уложить и разделить остальные?

Картинка отсюда: https://www.rainforestqa.com/blog/the-layers-of-te...

Собственно вопрос: а что требуется?

Этот вопрос всегда надо задавать тому, кто формирует требования, а не идти с этим вопросом в интернет к случайным людям.
Мы тут посидим, пообсуждаем, примем решение и ты что-то там реализуешь.
А в итоге окажется, что заказчик немножко "куку" и имел совсем не то, что мы тут посидели и решили.
Иди и общайся с заказчиком.

У вас массив 2×2. Нужно получить значение из определённой позиции — для этого есть функция INDEX. Вуаля!

=INDEX(GoogleFinance("Currency:USDRUB";"price";"20.10.2022");2;2)

Конечно можно

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

Вопрос не очень понятен, особенно в части "обрабатывать" можно как через try/catch".

Если я правильно понял, то задача - выбросить кастомное исключение, и выбор между проверкой через if и поимкой встроенного TypeError с последующим перевыбросом исключения со своим текстом ошибки.

В этом случае первый вариант однозначно предпочтительнее.
При ловле исключения будет более сложная логика - его надо не только поймать, но и определить что это именно то, которое мы ждём. И если это какое-то другое, то перевыбросить без изменений.
Кроме того, исключения в основном используются в исключительных, непредвиденных ситуациях. А здесь случай вполне предвиденный.

Я бы только инвертировал условие, чтобы во-первых, сделать логику более стройной (проверили - вывалились), а во-вторых, чтобы избавиться от else и убрать лишний отступ.

if not (isinstance(data_set, list) or isinstance(data_set, tuple)): 
    raise TypeError('argument must be list or tuple')
return sum(data_set) / len(data_set)

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

То есть в реальном коде я бы убрал проверку из функции вообще, а проверял данные при их получении (и выводил ошибку).
А на случай, если вдруг функция всё равно будет вызвана с неверным типом аргумента, есть системное исключение, 'type' object is not iterable

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

На английском есть специализированный сайт codereview@stackexchange, при наличии языка это идеальный вариант.

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

Самый надёжный способ получить code-review, это завести два аккаунта. С одного задать вопрос, "как сделать то-то", а с другого - запостить код, который это делает. И тут же набегут советчики, рассказать, что в этом коде неправильно.