Власне, який урок нам:

- Перевіряти код перед запуском: аналізувати проєкт, особливо скрипти в кореневих файлах, прихованих папках або модулях.
- Юзати ізольоване середовище: ранити код у віртуальних машинах (VirtualBox, VMware або Hyper-V) або Docker(шось по тіпу docker run —rm -it -v $(pwd):/app -w /app node:latest bash) , щоб уникнути доступу до реальних даних на вашому комп’ютері.
- Як варіант можна заюзати окремий обліковий запис. Якщо ви не хочете налаштовувати VM, можна зробити окремий обліковий запис користувача на своєму компі з мінімальними правами доступу.
- Сканувати репо: інструменти для аналізу шкідливого коду, можуть допомогти тут вам.
- Аналізувати приховані файлів: все шо починається «.», можуть бути прихованими в IDE. Можна включити відображення прихованих файлів, щоб нічого не пропустити.
- Перевіряти залежності: чекніть package.json, requirements.txt, або інші файли залежностей на наявність підозрілих бібліотек
- Обфускований код: непрозорий код (наприклад, довгі рядки без коментарів, мінімізовані або обфусковані скрипти) від невідомих людей, це привід для додаткової перевірки
- Підозрілі IP-адреси або домени в коді це червоний прапорець.

Від академії SoftServe є доколі цікава можливість повчитись та працевлаштуватись

На курсі навчать:
📎 тестувати програмне забезпечення за стандартом ISTQB
📎 використовувати реляційні бази даних і SQL для тестування вебзастосунків
📎 користуватись Jira та Zephyr для написання тест-кейсів та логування дефектів
📎 тестувати API
📎 працювати та розробляти проєкти за методологією Scrum

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

Рєстрація та деталі тут: https://hubs.ly/Q02-kjBc0

🤫 P.S. SoftServe каже, кожен третій випускник цього курсу отримав офер від SoftServe.

Доброго ранку! Якось я провтичив початок адвент календаря для інженерів 🙂
https://adventofcode.com/
тут кожень день дається одна задачка з двох частин де треба на будь-якій мові виконати рішення(майже всі вони про те шоб шось прокалькулювати але з певною бізнес логікою) і в кінці надати відповідь.
Тому, пропоную долучитись всім хто вивчає, планує вивчати, або давно займається програмуванням до адвент календарю цього також)

Став вогник якщо також приймаєш участь 🔥

а також не забувайте що сьогодні яблоки будуть показувать новий телефон, наввушники, годинник та ОС з аішкою по телевізору

https://www.youtube.com/watch?v=uarNiSl_uh4&ab_channel=Apple

Поговоримо про кешування?
Існує декілька стратегії кешування: cache-aside, read-through, write-around, write-back, та write-through.В двох словах про кожну з них:

1. Cache-aside (також відома як Lazy Loading)- дані спочатку шукаються в кеші, якщо їх там немає, то завантажуються з бази даних, зберігаються в кеші, і потім повертаються клієнту.
   Плюси:
   - ефективно використовує кеш(туди потрапляють тільки ті дані, які дійсно потрібні)
   - простота
   Мінуси:
   - можлива висока затримка при першому зверненні до даних, якщо їх немає в кеші
   - можливість виникнення застарілих даних в кеші, якщо дані змінюються в основному сховищі, а кеш не оновлюється

2. Read-through - клієнт звертається до кеша як до проксі, а кеш сам отримує дані з бази даних, якщо їх немає в кеші.
   Плюси:
   - легше управління кешем з боку клієнта
   - менша затримка, ніж у cache-aside(запит обробляється на стороні кеша)
   Мінуси:
   - Ускладнена логіка управління кешем, оскільки кеш-система повинна бути інтегрована з базою даних.
   - Висока залежність від налаштувань кеша.

3. Write-around - дані спочатку записуються в основне сховище (наприклад, базу даних), а кеш оновлюється тільки під час читання даних. При зміні даних кеш не оновлюється, тобто кешування відбувається ЛИШЕ під час запитів на читання.
   Плюси:
   - менше записів у кеш, що може бути корисно для даних, які рідко запитуються
   - простота
   Мінуси:
   - перший запит після оновлення даних може призвести до кеш-miss
   - можливість отримання застарілих даних з кешу

4. Write-back - дані спочатку записуються в кеш, і тільки потім, з деякою затримкою або в асинхронному режимі, ці дані записуються в основне сховище.
   Плюси:
   -швидке виконання записів
   -менше операцій запису в базу даних, що може підвищити продуктивність
   Мінуси:
   -ризик втрати даних, якщо кеш буде втрачений до того, як дані збережуться в основному сховищі
   -складність реалізації через необхідність забезпечення консистентності між кешем і базою даних

5. Write-through - кожен запис одночасно зберігається і в кеші, і в основному сховищі. Це забезпечує синхронізацію даних між кешем і базою даних.
   Плюси:
   -консистентність даних
   -простота управління(не треба синхронізувати кеш з базою даних окремо)
   Мінуси:
   -високе навантаження на систему через часті записи і в кеш, і в базу даних.

@from_a_to_qa

кому роботу?
знайома шукає інженерів рівня Middle та вище. Мануал та Автомейшена
стек:
.NET Core/C#, React, Microservices Architecture, Cloud Optimized/Native Apps, Azure App Services, Azure Kubernetes, Azure Storage, CosmosDB, Azure DevOps

писати до @k_baturina

301 чи 302. Що обрати?
І той і той відповідає за перенаправлення. Але в чому ж основна різниця цих двох статусів?
301 каже нам що ресурс "ПОСТІЙНО" перемістився кудись.
302 каже шо ресурс "ТИМЧАСОВО" кудись перемістився.
Ну, окей, а нам то шо з цього?
А насправді тут доволі цікавий механізм у браузера.
Коли браузер бачить перенаправлення з статус кодом 301 -- то всі наступні запити будуть оминати початкову адресу і стукатись одразу до тої куди ресурс був переміщений. Браузер закешує її.
302 статус же скаже браузеру що не дивлячись на те що ми мувнули ресурс ти все ж таки спочатку зроби запит на перший а потім на другий.

Навіщо ж така логіка?
Якщо вам важливо зменшити навантаження на сервачок -- то юзайте 301.
Якщо вам важлива аналітика якась -- то треба юзати 302.

п.с. тільки не питайте це питання на співбесідах пліс :D

ISTQB випустив оновлення по автоматизації.

Certified Tester Specialist Test Automation Strategy Syllabus (CT-TAS v1.0)
Нова сертифікація та новий сілабус по стратегії автоматизації https://www.istqb.org/certifications/test-automation-strategy

Certified Tester Advanced Level Test Automation Engineering Syllabus (CTAL-TAE v2.0)
Оновлена версія вже активної сертифікації по автоматизації.
https://www.istqb.org/certifications/test-automation-engineer

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