Git config scope
Рівень, з якого Git читає setting: system, global, local, worktree або command. --show-origin і --show-scope допомагають знайти джерело ефективного значення.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Scope negotiation
Коли робота відрізняється від очікувань, Developers і Product Owner переглядають scope Sprint Backlog, не руйнуючи Sprint Goal.
Як працювати на спокійному проєкті та з нав’язаними оцінками →AGENTS.md instruction chain
Codex поєднує global guidance із project instructions від repository root до current directory. Ближчий AGENTS.md або AGENTS.override.md має вищий пріоритет у своєму scope.
Як налаштувати мультиагентне середовище →Android UI testing APIs
Поточна Android guidance окремо перелічує Espresso, UI Automator і Compose Test як instrumented UI testing APIs; конкретний seam потрібно обрати за UI surface та scope тесту.
Типи мобільних застосунків та мобільна автоматизація →Negative tests для даних і доступу
Спроєктуй negative tests для читання чужого row, підміни owner claim, вставки row поза дозволеним scope та запиту на erasure з legal-retention exception. Відокрем authentication evidence, database authorization і data-lifecycle decision.
Набір cases показує, який шар відхиляє кожну дію та який audit evidence потрібен.
The Scrum Guide
Фіксує responsibility за sizing та negotiation scope у Sprint.
Як працювати на спокійному проєкті та з нав’язаними оцінками → Першоджерело ↗Що робити, коли задачі оцінили без команди
[Дивитися з 14:25](https://www.youtube.com/watch?v=reaHS8_pZbU&t=865s). Якщо estimate нав’язано ззовні, команда не повинна регулярно рятувати його unpaid overtime: тоді management бачить лише формально виконаний plan і не отримує evidence, що estimation process зламаний. Потрібно фіксувати фактичний effort, невідомі залежності, скорочений testing scope та carry-over, а на retrospective вимагати участі виконавців в оцінюванні. Сильніша позиція виникає, коли кілька інженерів незалежно описують ту саму проблему фактами. Спочатку питання піднімають із tech lead/engineering lead, потім — на retro або з manager, якщо прямий канал не працює. Повідомлення має бути не «ми не хочемо встигати», а «за такого scope й available capacity безпечний результат потребує X; до deadline можемо завершити Y, решту переносимо або свідомо приймаємо перелічені ризики». У відео також звучить ідея зробити недооцінку видимою через накопичення нестабільних tests і technical debt. Навмисно ламати quality gate не варто: це створює product risk і послаблює аргументацію команди. Правильний еквівалент — не приховувати незавершену роботу, явно документувати deferred checks/debt, не позначати неперевірене як done і вимагати product decision про scope, deadline або quality.
Ознаки спокійного проєкту
[Дивитися з 00:00](https://www.youtube.com/watch?v=reaHS8_pZbU&t=0s). У великій компанії частіше вже сформовані processes, розподіл відповідальності й розуміння, що постійний overtime шкодить людям і результату. Але розмір сам по собі нічого не гарантує: work-life balance треба перевіряти конкретними питаннями на співбесіді. Корисно запитати, хто оцінює work, чи бере участь команда, як змінюється scope після estimate, що відбувається при невиконанні sprint commitment і чи оплачуються понаднормові години. Регулярний overtime зазвичай вказує на проблему з prioritization, scope changes або estimation, а не на недостатню відданість інженера. Власні estimates радять робити з резервом на невідомі залежності, перевірку та recovery після помилок.
Що тестувати і де знайти contract
Дані, які бачить користувач, приходять з backend services, тому UI scenario часто можна розкласти на більш швидкі API checks. Спочатку треба з’ясувати API maturity: чи є specification, чи вона актуальна, як frontend реально викликає endpoints. Якщо documentation немає або їй не можна довіряти, browser DevTools/Network дає фактичні URL, method, headers, payload і response. Це джерело для discovery, але не заміна погодженого contract.
`self` і область видимості
`self` — явний параметр instance method, через який код звертається до конкретного екземпляра класу. `self.card` означає атрибут цього екземпляра, тоді як локальна змінна `card` живе лише у своїй функції або блоці видимості. Однакові назви технічно можливі, але збільшують когнітивне навантаження. Префікс `self.` одночасно потрібен Python для правильного доступу до instance attribute і показує читачеві, де зберігається стан.
Оголошення, ініціалізація та scope змінних
Повторюваний URL спочатку виноситься в змінну типу `String`. Оголошення задає тип і назву, а ініціалізація присвоює значення; неініціалізовану локальну змінну Java не дозволить використати. Тест у JUnit є методом з анотацією `@Test`, тому локальна змінна одного test method недоступна іншому, а спільне значення потрібно підняти на рівень test class.
Спочатку відпочинок, потім кар’єрне рішення
Компанія — не сім’я, але здоровий менеджмент має пам’ятати, що працює з людьми. Не варто компенсувати проблеми проєкту постійним overtime. Якщо є виснаження, перший крок — зменшити scope, використати відпустку, повернути хобі й час із близькими. Sabbatical доречний, коли є фінансова подушка та реальна можливість його взяти. Матеріальний стан важливий, але його треба співвідносити з ціною для психологічного здоров’я; рішення не варто зводити лише до максимальної зарплати.
AI як інструмент оптимізації та межі дозволеного
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
Life balance важливіший за лінійну кар’єру
Пропонується думати не про формальний work-life balance, а про загальний life balance — власний порядок пріоритетів. Комусь підходить відповідальність за бізнес або команду, а комусь — стабільний інженерний scope, передбачуваний відпочинок і менше токсичності. Перехід із менеджменту в технічну роль або навпаки — звичайний етап життя. Його можна прямо пояснити recruiter або майбутній команді: людина спробувала інший тип роботи й зрозуміла, де має більше інтересу та задоволення.
OTP, rate limits і production smoke
Для OTP можна зарезервувати test identity і детермінований code; для rate limits — окреме правило для CI traffic. Автор допускає такий bypass навіть на production, хоча прямо зазначає, що цього бажано не робити. Редакційне security-застереження: на production безпечніше виконувати smoke через звичайний захист або спеціально спроєктований найменш привілейований test path. Будь-який production bypass header чи hardcoded OTP стає критичним секретом: його витік фактично вимикає захист, тому потрібні ротація, журналювання, вузький scope і окремий security review.
SAST, DAST і спеціалізовані scanners
SAST аналізує codebase, configuration та infrastructure definitions без запуску повного user flow. До scope можуть входити source code, dependencies, YAML, Docker та Terraform files. DAST працює проти запущеного застосунку: генерує requests, змінює parameters, headers, authentication data й шукає небезпечну runtime behavior. OpenAPI specification може бути input для API security scanner-а. Окремі tools аналізують network traffic або вразливості, характерні для конкретної мови, cloud platform, protocol чи IoT stack. Тому pentesting швидко розгалужується на спеціалізації, а не зводиться до ручного перебору requests у Postman.