Docker Compose, для чого потрібен і коли його використовують 🤔

📌 Docker Compose — дозволяє запускати безліч контейнерів одночасно і маршрутизувати потоки даних між ними.
✔️ Актуальною версією компоуз є V2, перший Docker Compose дійде свого кінця в середині 2023 року. Перехід на другу версію приніс дуже багато цікавих змін і перетворив docker compose з окремої програми на докер плагін (хоча встановити як окрему програму все ще можна).

То навіщо потрібен компоуз❓

👉 Він чудово підходить для локальної розробки. Розробники можуть спулити проєкт і буквально однією командою його зібрати - докер збере або завантажить потрібні контейнери, а компоуз дозволяє це все зручно автоматизувати. Разом це дає розробникам можливість без проблем і без зайвих налаштувань запускати проєкт локально.

#codica_tech

📌 docker-compose.yml — конфігураційний файл у YAML-форматі, що описує логіку запуску та взаємодії контейнерів між собою та зовнішнім світом. По суті, інструкції, закладені в docker-compose.yml за логікою роботи ідентичні ключам команди docker.

👉 docker-compose.yml мало чим схожий на знайомі нам файли docker, він записаний в деревоподібному YAML.

☝️ На перше місце під час роботи з Docker Compose виходить структура проєкту. Хорошою практикою є складання процесної карти взаємодії елементів вашого проєкту між собою та її перенесення на логіку роботи Docker Compose.

Для запуску контейнерів через docker-compose використовуються такі команди:

▪️ docker compose build — зібрати проєкт
▪️ docker compose up -d — запустити проєкт
▪️ docker compose down — зупинити проєкт
▪️ docker compose logs -f [service name] — переглянути логи сервісу
▪️ docker compose exec [service name] [command] — виконати команду у контейнері
▪️ docker compose images — список образів

📄 Docker Compose має документ специфікації. Цей документ визначає формат файлу Compose, який використовується для визначення застосунків із кількома контейнерами.

👉 Підпишись на наш TikTok | Instagram

#codica_tech

Як зняти стрес і тривогу через погані новини 🫣

#НапуттяВід_HR Директорки Клименко Наталії

☝️ Основна причина постійного споживання негативного контенту, читання поганих новин – це страх пропустити важливу для виживання інформацію.

🧠 Людський мозок влаштований так, щоб більше звертати увагу на все погане, ніж хороше. Так виходить через те, що одне із завдань мозку - лякати людину, щоб вона заздалегідь готувалася до поганого і могла вижити. Саме тому нас тягне до страшних новин. Ми їх читаємо і тривожимося ще більше.

🥲 Проте інтерес до негативних новин не допомагає контролювати ситуацію. Насправді велика кількість новин у житті лише підвищує тривожність, а контроль ніяк не посилює. Тривога починає виснажувати організм.

📌 Важливо: контролювати погані новини нам не вдасться, але можна контролювати їхнє споживання.

Ось кілька порад, які допоможуть з цим впоратися👇

▪️ Поставте таймер та читайте новини стільки, скільки зазвичай. Так ви простежите, скільки часу на день йде на споживання такого контенту. Це допоможе тверезо оцінити ситуацію.

▪️ Зрозумівши, скільки часу йде на новини, почніть контролювати їхню кількість. Це не означає, що потрібно цілком перестати цікавитися тим, що відбувається у світі. Однак потрібно розуміти, яка частина вашого життя на це витрачається. І поставити межі. Наприклад, 20 хвилин на день.

▪️ Припиніть практику читання новин у першу годину після пробудження, за годину до сну, на голодний шлунок і під час прийому їжі. У ці періоди організм особливо сприйнятливий.

▪️ Не пишіть коментарі до новин, не вступайте у суперечки. Ви нічого не доведете, а нервова система виснажиться ще більше.

▪️Якщо хочеться читати новини так, що прямо немає сил, шукайте спільноти з хорошими новинами і читайте їх. Час споживання позитивного контенту обмежувати не потрібно.

Що ще нам допоможе впоратися з негативними емоціями після читання поганих новин? 🤔

Дихальні техніки 😌

Погані новини та пов'язані з ними негативні емоції не можна просто ігнорувати. Постійне придушення почуттів призводить до нервового зриву. Щоб такого не відбувалося, емоції потрібно прожити, тобто відчути та відпустити.
👉 У цьому допомагає вправа «дихання по квадрату». Потрібно рахувати до чотирьох, коли вдихаєте, потім при затримці дихання, потім на видиху і знову при затримці дихання. При цьому треба уявляти, як емоції від негативних новин при видиху відлітають від вас. Стане спокійніше 🙂
Можна використовувати будь-які інші дихальні техніки, покликані заспокоїти людину при хронічному стресі.

Аудит нашого інфополя 📲

Потрібно провести «аудит» своїх соцмереж: проаналізувати підписки. І з тих, хто пропонує негативні новини, залишити лише офіційні джерела.
👉 Видаліть підписки на всі «сенсаційні» дрібні канали новин і жовту пресу - це джерела постійних стресів. Чотирьох-п'яти офіційних джерел буде цілком достатньо, щоб залишатися в курсі подій і при цьому не заганяти себе у вир тривоги.

Всім нам сил та терпіння пережити ці нелегкі часи ❤️
Залишайтесь у безпеці!

👉 Підпишись на наш TikTok | Instagram

#НапуттяВід_HR

Сьогодні рівно рік – рік незламних людей, незламної сили волі і незламної країни 🇺🇦

24 лютого минулого року ми об’єдналися і показали світові, що таке потужна та смілива нація! Нація, яка у перші дні війни руками зупиняла російські танки і весь цей рік знає: ЗСУ — це сила 🦾

Наші захисники та захисниці — більше, ніж Герої! Найхоробріші, найсміливіші, найвідданіші своїй країні і своєму народові воїни. Саме завдяки їм ми продовжуємо працювати та донатити на перемогу.

Війна з агресором не зруйнувала нашу впевненість у виборі – жити вільним життям! Ми зміцнювалися, розвивалися, удосконалювалися та продовжуватимемо робити це ще з більшою завзятістю 💙💛

24 лютого 1993 року вважається днем народження Ruby 🔻

👀 Творець Ruby Юкіхіро Мацумото (він же «Matz») спробував взяти найкраще зі своїх улюблених мов програмування (Perl, Smalltalk, Eiffel, Ada та Lisp) та поєднати в рамках нової мови функціональну та імперативну парадигми програмування.

☝️ Цього дня була придумана тільки назва для цієї мови, і жодного коду ще не існувало. Мацумото вибирав між двома варіантами назви - "Ruby (рубін)" і "Koral (корал)".

Було обрано перший варіант, тому що це був камінь по гороскопу одного зі співробітників Мацумото 😅

👉 Підпишись на наш TikTok | Instagram

@Mister_Cody бажає вам на вихідних знайти час для того, щоб зробити те, що ви любите і отримати від цього задоволення 😌

👉 Підпишись на наш TikTok | Instagram

#codica_humor

Всім гарного недільного дня, ловіть невеличкий дайджест новин зі світу IT від @Mister_Cody 📲

📊 Рейтинг мов програмування 2023. JavaScript/TypeScript завойовують світ, Python увійшов у топ-3, Salesforce Apex випередив 1C.

🧑‍🎓 На Сумщині відкрили безкоштовну ІТ-школу в укритті.

❌ Auchan Holding визнали міжнародним спонсором війни.

💼 Майнові права на код та AI-обʼєкти. Головні зміни в новому законі про авторське право.

🇺🇦 Для українців за кордоном створили застосунок I’m Ukrainian, що допоможе відшукати там український бізнес і скористатися послугами українських підприємців.

👉 Підпишись на наш TikTok | Instagram

Доброго ранку та гарного тижня 🌞

#codica_ruby

Привіт, майбутній колего! 👋

👀 Шукаємо DevOps інженера, який живо цікавиться своєю галуззю та бажає прокачувати свою експертність разом із компетентною командою.

Повний ремоут або гібрид (офіси є в Києві та Харкові)!

👉 Якщо ти любиш автоматизувати процеси, прагнеш працювати в компанії з розвиненою DevOps культурою та активно продовжуєш свій розвиток, ми будемо раді познайомитись.

▪️ Трохи про нас: ми аутсорсингова сервісна компанія, що вже майже 8 років працює над створенням складних веб та мобільних додатків з нуля – від планування та реалізації до запуску.

Які навички прагнемо бачити?

➡️ Досвід роботи в напрямку DevOps від 0,5 року
➡️ Базове розуміння DevOps-культури та методологій
➡️ Знання інструментів автоматизації та навички роботи з деякими з них (Terraform, Docker, Ansible)
➡️ Знання AWS та навички роботи з GitLab та Gitlab CI/CD
➡️ Базове розуміння інструментів для моніторингу та логування додатків
➡️ Базове розуміння комп’ютерних мереж
➡️ Впевнені навички роботи з Linux
➡️ Навички командної роботи
➡️ Англійська на рівні читання документації (навички розмовної англійської безперечно будуть плюсом)

Які будуть задачі?

➡️ Моніторинг та підтримка найкращих DevOps практик
➡️ Підтримка процесів CI/CD
➡️ Налаштування та розгортання Docker-середовища
➡️ Підтримка інструментів для розгортання, моніторингу та логування
➡️ Здійснення моніторингу серверів та додатків
➡️ Допомога новим співробітникам компанії у безпечному налаштуванні акаунтів
➡️ Співпраця з розробниками з питань вимог до програмного забезпечення та архітектури
➡️ Автоматизація процесів сумісної розробки й доставки ПЗ на платформи

Що ми пропонуємо?

✔️ Персональне рев’ю 1 раз на 6 місяців, де ми чесно і по суті обговорюємо твою кар’єру та фінансові перспективи;
✔️ Систематичні 1-to-1 мітинги з ментором (раз на два місяці), на яких відбувається обговорення конкретних задач та найближчих перспектив;
✔️ Можливість брати активну участь в обговоренні кожного проєкту та всіх процесів загалом;
✔️ Професійне та відкрите до пропозицій керівництво, яке завжди шукає шляхи покращення робочих процесів та умов;
✔️ Постійну підтримку та допомогу один одному (зверніть увагу на відгуки про нас))).

☝️ Друзі, у нас є тестове завдання і нам дуже важливо подивитися на вашу реалізацію, щоб ми до кінця зрозуміли один одного :)

📧 З усіх питань пиши на пошту - job@codica.com
📲 Або в телеграм: @Vladyslava_Codica

Надсилайте резюме, будемо раді поспілкуватися! 😉

Тест-план у процесах тестування 📝

📌 Стаття від нашого QA Lead - Олексія

👀 Коли мова заходить про тест-план чи тестову стратегію, часто можна втрапити у ситуацію “теоретичної репродукції”. Скажімо, людина добре вивчила теорію, може дати визначення, порівняльну характеристику тест-плану і тестової стратегії, але за безпосереднього написання цих документів вона ризикує стикнутися із численними питаннями.

☝️ Почнемо з тест-плану, бо він локальніший і його пишуть частіше за тестову стратегію.
📌 Тест-план — це документ, що визначає обсяги, зусилля, підходи, критерії і відповідальність в межах тестувальної діяльності на проєкті. Зазвичай його пише головний QA проєкту або ж QA Lead компанії, якщо його залучають до кожного проєкту. Оскільки це документ проєктного рівня, він може бути індивідуально орієнтованим під потреби цього проєкту, а також еластично змінюватися через зміни в цих самих потребах.
Але найважливіше, знаючи усе це, задатися питанням: а навіщо пишуть тест-план? 🤔

#codica_advice

🖇 Тест-план — це “снепшот” тестувального консенсусу на проєкті. Спиратися на усні домовленості, історії листування, інтуїтивну експертизу в умовах динаміки змін сильно важче, ніж на зафіксовані на папері регулювання.

👉 Із цього випливає ще одна вимога, що насправді властива будь-якому тестувальному артефакту: актуальність понад формальністю. Тест-план лежить в основі будь-якого теоретичного комплексу з тестування, пропонуються різні формати його написання, рекомендації тощо. Але це саме той документ, який через свою комплексність і насиченість деталями нерідко перетворюється на проформенний маніфест, до якого не звертатимуться навіть із питань, які чітко там прописані. Тож варто близько поглянути на кожен його класичний елемент, тримаючи в голові “а навіщо?”.

✅ Таблиця редагувань/версій додається, якщо в документі, а отже і в розробці, очікується динаміка — нові скоупи, зміни вимог, розгалуження тощо. Це зручний елемент, що дозволить одразу пересвідчитися у (не)актуальності документу, почитати коментарі до змін і пінганути за необхідності автора нової версії.

✅ Вступна частина, бізнес-бекграунд і подібне пишуться для того, щоби зчепити далі наведені вимоги до тестування із реаліями цього проєкту у розумінні тестувальників. Наприклад, якщо це вже наявний сайт для продажу товарів, у якому фактичні обсяги продажів становлять тисячі угод на день, для всіх нових функціональних частин органічно виникає потреба у тестуванні перформансу з метою мати, як мінімум, не нижчу швидкість обробки запитів.

✅ Цілі тестування прописуються, якщо вони не походять із самої дефініції тестування. Тобто якщо є щось, окрім “мінімізувати кількість багів за рамки відведеного часу”. Наприклад, щось, із чого походить пріоритетність задач типу “перевірити здатність оброблення А запитів не більше ніж за Б одиниць часу”.

✅ Скоуп, тобто які саме функціональні частини буде протестовано, варто прописувати завжди, навіть якщо передбачається, що треба тестувати все. Це просто зекономить час та допоможе уникнути непорозумінь. Окрім частин, що тестуються, він також може містити уточнення, які частини не буде протестовано.

✅ Типи тестування та підходи — це також корисна нотатка, навіть якщо усе доволі дефолтно. Звірятися з цим пунктом під час тестування зручно і приємно через подолання відчуття, наче щось було пропущено. Крім того, тут зазвичай наводиться певна аргументація, що для менш кваліфікованих співробітників може бути цінним джерелом практичних знань і досвіду.

✅ Розділ про ідентифіковані проблеми та ризики варто писати лише за умови, що стратегії з мітигації чи то просто профілактичні методи справді буде впроваджено. Проформенний рапорт типу “так, ми знаємо, що ми неідеальні”, який далі його написання не піде, лише заб’є тест-план надлишковою інформацією.

👉 Інколи ризики виносяться в окремий розділ, а інколи ризики пропрацьовуються для кожного типу тестування окремо. Все це залежить від масштабів команди, проєкту, термінів розробки тощо.

✅ Перелік оточень, що часто буває сумісний із вимогами до спектру девайсів/екранів/ОС, що мають підтримуватися, зазвичай прописується у тісній колаборації з клієнтом, який має певне бачення своєї цільової авдиторії, та з розробниками, які можуть проконсультувати з точки зору технологій, залучених до розробки.

✅ Деталізація кожного типу тестування того вартує, якщо кожен тип тестування сам по собі є самодостатнім процесом. В менших командах ці розділи зазвичай опускають, оскільки декілька типів водночас потроху присутні в типовій рутині. Якщо вже розділ присутній, то в ньому прописуються функціональні частини, що проходитимуть цей тип тестування, потенційні ризики та плани з їх уникнення. Також часто сюди вписується тестова стратегія (замість того, щоби бути окремим документом організаційного рівня).

#codica_advice

✅ Розділ із тестовою командою прописується, якщо на проєкті працюватиме одразу кілька QA. Варто одразу розподілити зони відповідальності та домовитися про регламент взаємодії (наприклад, акаунти, тестова документація, перехресна перевірка тощо). Під час роботи над помилками також зручно звертатися до цього розділу.

✅ Розклад потребує роботи із клієнтом у форматі чітких часових меж (а не, скажімо, вимог до об’єму людиногодин без конкретних термінів). Оперувати ним буває проблематично через динамічні зміни у вимогах і скоупах. Якщо цей розділ постійно переписується і зважати на нього немає змоги чи потреби, то й сам розділ можна опустити.

✅ В плані також можуть бути присутні рекомендації з пріоритезації дефектів — вони зазвичай пишуться більш досвідченим QA на проєкті і містять компіляцію типових абстракцій, описів передумов появи чи потенційного впливу, за яким можна буде розподіляти пріоритет серед знайдених багів.

✅ Критерії етапів тестування, наприклад, критерії призупинення, продовження і повного завершення приводяться, коли такі процеси в принципі мають місце. Критеріями може виступати показник покриття чи певна кількість знайдених багів високого чи середнього пріоритету.

☝️ Важливо розуміти, що усі вищенаведені частини тест-плану можуть змінюватися місцями, вилучатися, можуть бути додані нові, залежно від потреби проєкту. Непогано мати готовий кістяк всередині компанії, на який можна спиратися при розробці кожного наступного тест-плану, але точно не варто дотримуватися якоїсь формальної схеми із теорії, не усвідомлюючи практичного змісту за кожним розділом.

Підписуйтесь на інші соціальні мережі 👇

TikTok | Instagram

#codica_advice