Python *

История о том, как выявлять новые иски к клиенту.

Решил заменить ручной труд по конкретной задаче программой. Смотри, что из этого вышло.

В материале от автора Python-профайлера Sciagraph к старту курса по Fullstack-разработке на Python вспомним о пользе векторизации и преодолеем некоторые её проблемы при помощи PyPy и Numba. За подробностями приглашаем под кат.

Решил я тут пофрилансить для души, и увидел, что каждый третий проект по разработке чат-бота предполагает интеграцию веб-админки. В основном это касается онлайн-магазинов, где заказчик пытается сэкономить на сайте и заменить его монстрючим чат-ботом. При этом рулить проектом ему удобнее в привычной среде. Отсюда и возникает пунктик — "хочу админку". Функциональность этой штуковины обычно заканчивается на обновлении информации о товарах, назначении админов, управлении рассылками... в общем, простые манипуляции с базой, не более. Так вот, дефолтный разработчик, видя этот пункт, берет, мать ее, Django. Почему? Ну конечно, причина кроется в лени колхозить свою админку, и притащить красивую Джанговую реализацию кажется хорошей идеей. Заказчик, в свою очередь, гуглит топ веб-фреймворков и одобрительно кивает на сей перфоманс. А иногда и подливает масла в огонь, прямо в описании работы пингуя Django.

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

Всем привет! Сегодня мы поговорим об интеграционном тестировании платежного шлюза, но перед этим расскажу немного про нашу команду и наш проект. Мы (ContactPay) — самостоятельный финтех-стартап внутри QIWI, строим высокопроизводительный отказоустойчивый платежный шлюз и соответствуем стандартам безопасности PCI DSS. 

Как платежный шлюз мы интегрированы со множеством внешних API, это могут быть и платежные системы, и сторонние сервисы мониторинга, антифрода, KYC (know your customer) и так далее. 

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

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

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

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

8 августа начинается новый, девятый поток нашей школы Metaclass по курсам frontend и backend для начинающих.

После учебы мы расспрашиваем наших студентов о том, что было легко, сложно, полезно или просто приятно. Сегодня о своем опыте расскажет недавний выпускник курса «Начинающий Backend-разработчик».

Почему важно узнавать подробности до старта работы

Появилась задачка: взять примерно сто тридцать шотов, настроить в них освещение, пофиксить проблемы при наличии, отправить на рендер. Софт — Autodesk Maya, а каждый шот представляет из себя отдельный файл с анимацией и всеми пирогами. И так двадцать пять раз, потому что двадцать пять эпизодов.

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

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

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

Полный код и все исходники можно найти на моем Github.

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

Учимся использовать и реализовывать на Python алгоритм поиска в ширину (BFS) для решения реальных задач.

Давайте поговорим о популярном алгоритме, который называется «Поиск в ширину» (BFS). Затем реализуем этот алгоритм, чтобы найти решение для реальной задачи: как выбраться из лабиринта.

Алгоритмы поиска применяются для решения таких задач, которые можно смоделировать как графы. Каждый узел графа – это экземпляр задачи. Каждый поисковый алгоритм начинается с узла (исходный экземпляр – состояние) и наращивает вслед за этим узлом новые (то есть, новые экземпляры задачи), решая задачу допустимыми способами. Этот процесс останавливается, как только алгоритм находит решение (успех – конечное состояние) или не может создать ни одного нового узла (провал). Среди самых популярных алгоритмов поиска – поиск в глубину (DFS), поиск в ширину (BFS), жадный алгоритм, поиск по критерию стоимости (UCS), A*-поиск, т.д. В этой статье речь пойдет о поиске в ширину.

Всем привет! Я QA Engineer в Scalable Solutions. Наша команда отвечает за работу сердца биржи – биржевого ядра, которое процессит регистрацию, сведение торговых заявок, проведение различных проверок и выполняет ряд других важных операций. Мы уже писали про специфику тестирования высоконагруженного бэкенда в финтехе, но сегодня я хочу рассказать, какое место в нашем процессе занимают компонентные тесты, и как мы их готовим.

Сравниваем два текстовых файла средствами графического редактора Inkscape

Всем привет, я Вячеслав Жуйко – Lead команды разработки Audiogram в MTS AI.

При переходе от On-Cloud размещений ПО на On-Premises в большинстве случае перед вами неизбежно встанет задача защиты интеллектуальной собственности – и она особенно критична для рынка AI, где задействуются модели, обладающие высокой ценностью для компании. К тому же, в этой сфере широко используется интерпретируемый язык Python, ПО на котором содержит алгоритмы, являющиеся интеллектуальной собственностью компании, но фактически распространяется в виде исходных кодов. Это не является проблемой для On-Cloud решений, но в случае с On-Premises требует особой защиты как от утечек кода, так и самих данных.

Рассказываю реальную историю решения этой, казалось бы, не самой тривиальной задачи. Итак, обо всем по порядку.

В прошлый раз мы отделили логику от инфраструктуры и разбили последнюю на четыре слоя: Server → Parser → Application → Repository. Классы инфраструктуры составляют основной фреймворк, который берет на себя всю рутинную работу, а нам предоставляет писать одну только логику.

Логика состоит из контроллеров, которые составляют пятый и пока что последний слой. Они полностью независимы не только от инфраструктуры (им доступно только хранилище), но и друг от друга. Контроллеры — это, на данный момент, базовые единицы бизнес-логики.

Если сильно обобщить, то контроллеры занимаются преобразованием одних команд в другие с сопутствующим изменением состояния приложения (Repository). В зависимости от команды и текущего состояния пользователя Application выбирает соответствующий контроллер и передает ему ссылку на Repository. Контроллер обрабатывает команду, изменяет состояние хранилища и возвращает другие команды, которые должны быть отправлены инфраструктурой по назначению. В общей схеме контроллеры занимают промежуточное место между движком и хранилищем:

... → Application → Controller → Repository.

Если размещать всю логику в одном классе контроллера, то это в большинстве случаев окажется большой класс. Большой класс — это много кода, а много кода, собранного в одном месте — это мешанина. Поэтому чтобы в ней не запутаться, вся логика будет разбиваться на различные классы. Одна задача — один класс. Классы, выполняющие сходные функции и способные заменять друг друга, будут группироваться в слои, как и в инфраструктуре.

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

При такой организации кода отдельные игры — это лишь соответствующая настройка и использование классов из жанровой библиотеки. Идеальный проект тогда будет состоять вообще из одного main-скрипта в пару строк и yml-файла конфигурации.

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

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

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

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

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

Бенджамин Франклин

Python отличается от таких языков программирования, как C# или Java, заставляющих программиста давать классам имена, соответствующие именам файлов, в которых находится код этих классов.

Python — это самый гибкий язык программирования из тех, с которыми мне приходилось сталкиваться. А когда имеешь дело с чем-то «слишком гибким» — возрастает вероятность принятия неправильных решений.

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

Судя по количеству закладок на первой части, работа моя  —  не зряшная.
В прошлый раз разбирали скучное открывание-закрывание картинки, в этот раз засунем в неё руки поглубже:

 • Доступ к пикселям и работа с ними
 • Масштабирование картинки
 • Обрезка
 • Отражение

В данной статье хочу рассказать про один проект из курса по OpenCV Python. Посмотреть полный код можно на Github.

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

Давно хотел познакомиться с Rust. Язык с экосистемой сборки из коробки, компилятор в машинный код, но самое главное — автоматическое управление памятью, но без сборщика мусора. С учетом того, что управление памятью обещается как zero-cost в runtime — просто сказка! По ходу изучения и возник вопрос – а насколько код Rust быстрее/медленнее компилятора в машинный код давно известного, например, Delphi?

Начнем с того, что это статья посягается на святой устой комьюнити Python разработчиков, устой звучит так "синтаксис python - идеален, стандартные библиотеки - идеальны, и полноценны, GIL - это неизбежная жертва для такого прекрасного языка как Python ... может быть в конце столетия люди придумают как его обойти, но, а пока так ?". Приносим глубокие извинения за такую статью, это чисто юмористичная статья, не стоит принимать ей в серьез.

В общем решить эту проблему можно 50 строчками, вот код для импорта модуля из любого места, без плясок с бубнами и `sys.path`

Это вторая статья из серии статей про создание бота на основе discord.py. В этой статье рассмотрим работу версиям, конфигами, а так же новым синтаксисом.