Пошук · Мануфактура

Python мануфактура Java Design Patterns для автоматизаторів

Java Light · 0:00–2:28

Consumer, producer і REST resources

Звична client–server model узагальнюється термінами consumer і producer. Consumer споживає дані або можливість, producer їх надає. Така мова працює не лише для browser і web server, а й для взаємодії між сервісами. Комунікація має protocol і contract. API-документації може не бути, вона може бути написаною вручну і застарілою або code-generated з анотацій у коді. У REST сутності представлені resources, а операції над ними — endpoints з HTTP-методами `GET`, `POST`, `PUT`, `DELETE`.

Вступ до API-автоматизації →

Python мануфактура · Програма курсу · 2:03–3:30

`finally` для cleanup

`finally` виконується незалежно від успіху або exception. Це місце для закриття database connection, file handle чи іншого обмеженого ресурсу. У прикладі timeout query обробляється, але connection усе одно закривається, щоб не вичерпати pool під навантаженням.

8 ексепшени →

Python мануфактура · Сесії: AMA та PMP · 6:55–10:20

Ринкова цінність навичок без культу overperformance

[Дивитися з 06:55](https://www.youtube.com/watch?v=reaHS8_pZbU&t=415s). Автор очікує, що на майбутніх співбесідах питатимуть не лише про prompts, а й про context management, перевірку output, open-source tools, code analysis та integration AI у development workflow. Повна відмова від таких інструментів на поточному client може залишити прогалину в досвіді, тому навички варто розвивати на дозволених або власних матеріалах. Для досвідченого інженера постійний overperformance не гарантує стабільності роботи: layoffs можуть бути наслідком budget, product strategy, regulation, зміни пріоритетів або перерозподілу resources. Рекомендована альтернатива — передбачуваний sustainable pace. Новачку тимчасово потрібна більша інвестиція часу для навчання, але це не має перетворюватися на норму для всієї кар’єри.

Як працювати на спокійному проєкті та з нав’язаними оцінками →

Java Light · 13:02–15:45

REST, status codes і централізовані errors

Для API automation потрібно окремо вивчити REST semantics: methods, resources, типові status codes і їхню очікувану поведінку. Public endpoints зазвичай оптимізовані для frontend або зовнішніх clients, private endpoints можуть обслуговувати внутрішню service-to-service communication і мати інший контракт. Самого HTTP status недостатньо. Централізований error handling має повернути consumer стабільний internal error code і зрозуміле пояснення: якого поля бракує або яке значення невалідне. Власні HTTP status codes на кшталт `600` не замінюють нормального error contract.

Вступ до API-автоматизації →

Java Light · 15:45–17:23

Protocols, API Gateway і Backend for Frontend

Окрім REST, системи використовують WebSocket, gRPC і GraphQL. Протокол обирається під задачу, тому перед автоматизацією потрібно зрозуміти не лише endpoint, а й модель комунікації. Backend for Frontend — це gateway з контрактом, зручним для конкретного client: web frontend, mobile application або окремого screen. Зовні він відкриває потрібні resources, а всередині може агрегувати кілька services з їхніми базами і queues.

Вступ до API-автоматизації →

Python мануфактура · Сесії: AMA та PMP · 23:19–33:00

REST і GraphQL уже дають словник для API automation

У REST структура починається з resources та HTTP methods. `Pet`, `Store` або `User` задають назви controllers/clients, а дії на кшталт create, update, delete чи find by ID — назви методів. Request і response models корисно розділяти, бо server response часто містить поля, яких не було у request. У GraphQL треба повторювати назви queries, mutations, inputs і types зі schema. Code generation може дати готові типи, але базове правило те саме: не створювати паралельний словник там, де backend contract уже має точні терміни. Read-only доступ до frontend і backend repositories допомагає швидше зрозуміти систему й підтримувати automation разом зі змінами продукту.

Неймінг та структура automation-проєкту →

Запитати в чаті про «resources» →