Мы хайрим (Python backend, QA automation, Android) и релоцируем (Польша, Кипр, и может быть ещё куда-то).
Делаем платформу для обработки платежей для стартапов Palta (включая Flo, в будущем). То есть много сложной работы с повышенными требованиями к качеству.
Попутно надо будет писать RFC (Requests For Comments), тесты (много), ревьювить код и, путём культурных дискуссий, передавать свои знания коллегам.
Пару месяцев как начали. Работаем удалённо. Ищем сеньоров и выше.
Технологии: AWS, Lambda, Aurora (PostgreSQL), последний поддерживаемый облаками Python.
Работать надо будет со мной в команде, со всеми плюсами и минусами этого :-DDD
Также, пока не ищем, но, надеюсь, будем: сильного фронтендера, технического-писателя-специалиста-по-dev-relations.
Ссылки с вакансиями:
https://boards.greenhouse.io/paltaltd/jobs/4467423004 https://boards.greenhouse.io/paltaltd/jobs/4383116004 https://boards.greenhouse.io/paltaltd/jobs/4459360004
Если нужны подробности, пишите в личку или в комментарии.
Если будете общаться с нашими рекрутёрами, упомяните где увидели вакансии :-)
Буду говорить в контексте программирования, но соображения можно распространить шире.
Когда мы описываем алгоритм: программу, доказательство теоремы или решение математической задачи — мы строим его описание в рамках некоторой формальной модели. В рамках соглашений и ограничений, которые мы явно или неявно принимаем.
Описать алгоритм вне формальной модели невозможно. Хотя бы потому, что любой язык — уже формализация.
Отсюда вытекает интересная проблема.
Давно хотел посмотреть на hypothesis — генератор фикстур для тестов. Сделал это пока в очередной раз колупал типы в Python.
Hypothesis позволяет описывать генераторы входных данных для тестов и запускать тесты сразу на всех сочетаниях данных. В случае ошибки библиотека попробует локализовать её в наиболее простом наборе данных, чтобы было проще понять проблему и воспроизвести ей. Генераторы для базовых типов идут в комплекте, поэтому деление на ноль она ловит хорошо :-)
Если кратко, то мне понравилось, рекомендую, буду использовать, но не всегда. Подробнее под катом.
Привет.
В посте Тесты, которые тестируют тесты я описал свой взгляд на верификацию программ через дублирование их логики в виде отдельной модели и последующее сравнение с ней. В качестве частного случая выступили юнит-тесты.
В этот раз, опираясь на изложенные идеи, я попробую сформулировать общий подход к оценке уровня верифицированности ПО.
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py . О них и расскажу, для иллюстрации идеи.