24 лютого 1993 року вважається днем народження Ruby 🔻
👀 Творець Ruby Юкіхіро Мацумото (він же «Matz») спробував взяти найкраще зі своїх улюблених мов програмування (Perl, Smalltalk, Eiffel, Ada та Lisp) та поєднати в рамках нової мови функціональну та імперативну парадигми програмування.
☝️ Цього дня була придумана тільки назва для цієї мови, і жодного коду ще не існувало. Мацумото вибирав між двома варіантами назви - "Ruby (рубін)" і "Koral (корал)".
Було обрано перший варіант, тому що це був камінь по гороскопу одного зі співробітників Мацумото 😅
👉 Підпишись на наш TikTok | Instagram
👀 Творець Ruby Юкіхіро Мацумото (він же «Matz») спробував взяти найкраще зі своїх улюблених мов програмування (Perl, Smalltalk, Eiffel, Ada та Lisp) та поєднати в рамках нової мови функціональну та імперативну парадигми програмування.
☝️ Цього дня була придумана тільки назва для цієї мови, і жодного коду ще не існувало. Мацумото вибирав між двома варіантами назви - "Ruby (рубін)" і "Koral (корал)".
Було обрано перший варіант, тому що це був камінь по гороскопу одного зі співробітників Мацумото 😅
👉 Підпишись на наш TikTok | Instagram
❤16👍6🔥3😁1
@Mister_Cody бажає вам на вихідних знайти час для того, щоб зробити те, що ви любите і отримати від цього задоволення 😌
❤4
Всім гарного недільного дня, ловіть невеличкий дайджест новин зі світу IT від @Mister_Cody 📲
📊 Рейтинг мов програмування 2023. JavaScript/TypeScript завойовують світ, Python увійшов у топ-3, Salesforce Apex випередив 1C.
🧑🎓 На Сумщині відкрили безкоштовну ІТ-школу в укритті.
❌ Auchan Holding визнали міжнародним спонсором війни.
💼 Майнові права на код та AI-обʼєкти. Головні зміни в новому законі про авторське право.
🇺🇦 Для українців за кордоном створили застосунок I’m Ukrainian, що допоможе відшукати там український бізнес і скористатися послугами українських підприємців.
👉 Підпишись на наш TikTok | Instagram
📊 Рейтинг мов програмування 2023. JavaScript/TypeScript завойовують світ, Python увійшов у топ-3, Salesforce Apex випередив 1C.
🧑🎓 На Сумщині відкрили безкоштовну ІТ-школу в укритті.
❌ Auchan Holding визнали міжнародним спонсором війни.
💼 Майнові права на код та AI-обʼєкти. Головні зміни в новому законі про авторське право.
🇺🇦 Для українців за кордоном створили застосунок I’m Ukrainian, що допоможе відшукати там український бізнес і скористатися послугами українських підприємців.
👉 Підпишись на наш TikTok | Instagram
👍5🔥3❤1
У якому циклі наведено числа від 0 до 7 включно?
Anonymous Quiz
20%
У всіх циклах
50%
Тільки в циклі for
21%
Тільки в циклі while
10%
Тільки в циклі times
👍6🔥3❤1
👉 Якщо ти любиш автоматизувати процеси, прагнеш працювати в компанії з розвиненою 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
Надсилайте резюме, будемо раді поспілкуватися! 😉
▪️ Трохи про нас: ми аутсорсингова сервісна компанія, що вже майже 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
Надсилайте резюме, будемо раді поспілкуватися! 😉
❤5👍4🔥3
Тест-план у процесах тестування 📝
📌 Стаття від нашого QA Lead - Олексія
👀 Коли мова заходить про тест-план чи тестову стратегію, часто можна втрапити у ситуацію “теоретичної репродукції”. Скажімо, людина добре вивчила теорію, може дати визначення, порівняльну характеристику тест-плану і тестової стратегії, але за безпосереднього написання цих документів вона ризикує стикнутися із численними питаннями.
☝️ Почнемо з тест-плану, бо він локальніший і його пишуть частіше за тестову стратегію.
📌 Тест-план — це документ, що визначає обсяги, зусилля, підходи, критерії і відповідальність в межах тестувальної діяльності на проєкті. Зазвичай його пише головний QA проєкту або ж QA Lead компанії, якщо його залучають до кожного проєкту. Оскільки це документ проєктного рівня, він може бути індивідуально орієнтованим під потреби цього проєкту, а також еластично змінюватися через зміни в цих самих потребах.
Але найважливіше, знаючи усе це, задатися питанням: а навіщо пишуть тест-план? 🤔
#codica_advice
📌 Стаття від нашого QA Lead - Олексія
👀 Коли мова заходить про тест-план чи тестову стратегію, часто можна втрапити у ситуацію “теоретичної репродукції”. Скажімо, людина добре вивчила теорію, може дати визначення, порівняльну характеристику тест-плану і тестової стратегії, але за безпосереднього написання цих документів вона ризикує стикнутися із численними питаннями.
☝️ Почнемо з тест-плану, бо він локальніший і його пишуть частіше за тестову стратегію.
📌 Тест-план — це документ, що визначає обсяги, зусилля, підходи, критерії і відповідальність в межах тестувальної діяльності на проєкті. Зазвичай його пише головний QA проєкту або ж QA Lead компанії, якщо його залучають до кожного проєкту. Оскільки це документ проєктного рівня, він може бути індивідуально орієнтованим під потреби цього проєкту, а також еластично змінюватися через зміни в цих самих потребах.
Але найважливіше, знаючи усе це, задатися питанням: а навіщо пишуть тест-план? 🤔
#codica_advice
👍7🔥3❤1
🖇 Тест-план — це “снепшот” тестувального консенсусу на проєкті. Спиратися на усні домовленості, історії листування, інтуїтивну експертизу в умовах динаміки змін сильно важче, ніж на зафіксовані на папері регулювання.
👉 Із цього випливає ще одна вимога, що насправді властива будь-якому тестувальному артефакту: актуальність понад формальністю. Тест-план лежить в основі будь-якого теоретичного комплексу з тестування, пропонуються різні формати його написання, рекомендації тощо. Але це саме той документ, який через свою комплексність і насиченість деталями нерідко перетворюється на проформенний маніфест, до якого не звертатимуться навіть із питань, які чітко там прописані. Тож варто близько поглянути на кожен його класичний елемент, тримаючи в голові “а навіщо?”.
✅ Таблиця редагувань/версій додається, якщо в документі, а отже і в розробці, очікується динаміка — нові скоупи, зміни вимог, розгалуження тощо. Це зручний елемент, що дозволить одразу пересвідчитися у (не)актуальності документу, почитати коментарі до змін і пінганути за необхідності автора нової версії.
✅ Вступна частина, бізнес-бекграунд і подібне пишуться для того, щоби зчепити далі наведені вимоги до тестування із реаліями цього проєкту у розумінні тестувальників. Наприклад, якщо це вже наявний сайт для продажу товарів, у якому фактичні обсяги продажів становлять тисячі угод на день, для всіх нових функціональних частин органічно виникає потреба у тестуванні перформансу з метою мати, як мінімум, не нижчу швидкість обробки запитів.
✅ Цілі тестування прописуються, якщо вони не походять із самої дефініції тестування. Тобто якщо є щось, окрім “мінімізувати кількість багів за рамки відведеного часу”. Наприклад, щось, із чого походить пріоритетність задач типу “перевірити здатність оброблення А запитів не більше ніж за Б одиниць часу”.
✅ Скоуп, тобто які саме функціональні частини буде протестовано, варто прописувати завжди, навіть якщо передбачається, що треба тестувати все. Це просто зекономить час та допоможе уникнути непорозумінь. Окрім частин, що тестуються, він також може містити уточнення, які частини не буде протестовано.
✅ Типи тестування та підходи — це також корисна нотатка, навіть якщо усе доволі дефолтно. Звірятися з цим пунктом під час тестування зручно і приємно через подолання відчуття, наче щось було пропущено. Крім того, тут зазвичай наводиться певна аргументація, що для менш кваліфікованих співробітників може бути цінним джерелом практичних знань і досвіду.
✅ Розділ про ідентифіковані проблеми та ризики варто писати лише за умови, що стратегії з мітигації чи то просто профілактичні методи справді буде впроваджено. Проформенний рапорт типу “так, ми знаємо, що ми неідеальні”, який далі його написання не піде, лише заб’є тест-план надлишковою інформацією.
👉 Інколи ризики виносяться в окремий розділ, а інколи ризики пропрацьовуються для кожного типу тестування окремо. Все це залежить від масштабів команди, проєкту, термінів розробки тощо.
✅ Перелік оточень, що часто буває сумісний із вимогами до спектру девайсів/екранів/ОС, що мають підтримуватися, зазвичай прописується у тісній колаборації з клієнтом, який має певне бачення своєї цільової авдиторії, та з розробниками, які можуть проконсультувати з точки зору технологій, залучених до розробки.
✅ Деталізація кожного типу тестування того вартує, якщо кожен тип тестування сам по собі є самодостатнім процесом. В менших командах ці розділи зазвичай опускають, оскільки декілька типів водночас потроху присутні в типовій рутині. Якщо вже розділ присутній, то в ньому прописуються функціональні частини, що проходитимуть цей тип тестування, потенційні ризики та плани з їх уникнення. Також часто сюди вписується тестова стратегія (замість того, щоби бути окремим документом організаційного рівня).
#codica_advice
👉 Із цього випливає ще одна вимога, що насправді властива будь-якому тестувальному артефакту: актуальність понад формальністю. Тест-план лежить в основі будь-якого теоретичного комплексу з тестування, пропонуються різні формати його написання, рекомендації тощо. Але це саме той документ, який через свою комплексність і насиченість деталями нерідко перетворюється на проформенний маніфест, до якого не звертатимуться навіть із питань, які чітко там прописані. Тож варто близько поглянути на кожен його класичний елемент, тримаючи в голові “а навіщо?”.
✅ Таблиця редагувань/версій додається, якщо в документі, а отже і в розробці, очікується динаміка — нові скоупи, зміни вимог, розгалуження тощо. Це зручний елемент, що дозволить одразу пересвідчитися у (не)актуальності документу, почитати коментарі до змін і пінганути за необхідності автора нової версії.
✅ Вступна частина, бізнес-бекграунд і подібне пишуться для того, щоби зчепити далі наведені вимоги до тестування із реаліями цього проєкту у розумінні тестувальників. Наприклад, якщо це вже наявний сайт для продажу товарів, у якому фактичні обсяги продажів становлять тисячі угод на день, для всіх нових функціональних частин органічно виникає потреба у тестуванні перформансу з метою мати, як мінімум, не нижчу швидкість обробки запитів.
✅ Цілі тестування прописуються, якщо вони не походять із самої дефініції тестування. Тобто якщо є щось, окрім “мінімізувати кількість багів за рамки відведеного часу”. Наприклад, щось, із чого походить пріоритетність задач типу “перевірити здатність оброблення А запитів не більше ніж за Б одиниць часу”.
✅ Скоуп, тобто які саме функціональні частини буде протестовано, варто прописувати завжди, навіть якщо передбачається, що треба тестувати все. Це просто зекономить час та допоможе уникнути непорозумінь. Окрім частин, що тестуються, він також може містити уточнення, які частини не буде протестовано.
✅ Типи тестування та підходи — це також корисна нотатка, навіть якщо усе доволі дефолтно. Звірятися з цим пунктом під час тестування зручно і приємно через подолання відчуття, наче щось було пропущено. Крім того, тут зазвичай наводиться певна аргументація, що для менш кваліфікованих співробітників може бути цінним джерелом практичних знань і досвіду.
✅ Розділ про ідентифіковані проблеми та ризики варто писати лише за умови, що стратегії з мітигації чи то просто профілактичні методи справді буде впроваджено. Проформенний рапорт типу “так, ми знаємо, що ми неідеальні”, який далі його написання не піде, лише заб’є тест-план надлишковою інформацією.
👉 Інколи ризики виносяться в окремий розділ, а інколи ризики пропрацьовуються для кожного типу тестування окремо. Все це залежить від масштабів команди, проєкту, термінів розробки тощо.
✅ Перелік оточень, що часто буває сумісний із вимогами до спектру девайсів/екранів/ОС, що мають підтримуватися, зазвичай прописується у тісній колаборації з клієнтом, який має певне бачення своєї цільової авдиторії, та з розробниками, які можуть проконсультувати з точки зору технологій, залучених до розробки.
✅ Деталізація кожного типу тестування того вартує, якщо кожен тип тестування сам по собі є самодостатнім процесом. В менших командах ці розділи зазвичай опускають, оскільки декілька типів водночас потроху присутні в типовій рутині. Якщо вже розділ присутній, то в ньому прописуються функціональні частини, що проходитимуть цей тип тестування, потенційні ризики та плани з їх уникнення. Також часто сюди вписується тестова стратегія (замість того, щоби бути окремим документом організаційного рівня).
#codica_advice
👍6❤2🔥1
✅ Розділ із тестовою командою прописується, якщо на проєкті працюватиме одразу кілька QA. Варто одразу розподілити зони відповідальності та домовитися про регламент взаємодії (наприклад, акаунти, тестова документація, перехресна перевірка тощо). Під час роботи над помилками також зручно звертатися до цього розділу.
✅ Розклад потребує роботи із клієнтом у форматі чітких часових меж (а не, скажімо, вимог до об’єму людиногодин без конкретних термінів). Оперувати ним буває проблематично через динамічні зміни у вимогах і скоупах. Якщо цей розділ постійно переписується і зважати на нього немає змоги чи потреби, то й сам розділ можна опустити.
✅ В плані також можуть бути присутні рекомендації з пріоритезації дефектів — вони зазвичай пишуться більш досвідченим QA на проєкті і містять компіляцію типових абстракцій, описів передумов появи чи потенційного впливу, за яким можна буде розподіляти пріоритет серед знайдених багів.
✅ Критерії етапів тестування, наприклад, критерії призупинення, продовження і повного завершення приводяться, коли такі процеси в принципі мають місце. Критеріями може виступати показник покриття чи певна кількість знайдених багів високого чи середнього пріоритету.
☝️ Важливо розуміти, що усі вищенаведені частини тест-плану можуть змінюватися місцями, вилучатися, можуть бути додані нові, залежно від потреби проєкту. Непогано мати готовий кістяк всередині компанії, на який можна спиратися при розробці кожного наступного тест-плану, але точно не варто дотримуватися якоїсь формальної схеми із теорії, не усвідомлюючи практичного змісту за кожним розділом.
Підписуйтесь на інші соціальні мережі 👇
TikTok | Instagram
#codica_advice
✅ Розклад потребує роботи із клієнтом у форматі чітких часових меж (а не, скажімо, вимог до об’єму людиногодин без конкретних термінів). Оперувати ним буває проблематично через динамічні зміни у вимогах і скоупах. Якщо цей розділ постійно переписується і зважати на нього немає змоги чи потреби, то й сам розділ можна опустити.
✅ В плані також можуть бути присутні рекомендації з пріоритезації дефектів — вони зазвичай пишуться більш досвідченим QA на проєкті і містять компіляцію типових абстракцій, описів передумов появи чи потенційного впливу, за яким можна буде розподіляти пріоритет серед знайдених багів.
✅ Критерії етапів тестування, наприклад, критерії призупинення, продовження і повного завершення приводяться, коли такі процеси в принципі мають місце. Критеріями може виступати показник покриття чи певна кількість знайдених багів високого чи середнього пріоритету.
☝️ Важливо розуміти, що усі вищенаведені частини тест-плану можуть змінюватися місцями, вилучатися, можуть бути додані нові, залежно від потреби проєкту. Непогано мати готовий кістяк всередині компанії, на який можна спиратися при розробці кожного наступного тест-плану, але точно не варто дотримуватися якоїсь формальної схеми із теорії, не усвідомлюючи практичного змісту за кожним розділом.
Підписуйтесь на інші соціальні мережі 👇
TikTok | Instagram
#codica_advice
👍6🔥2❤1
Передбачення на весну від нашого @Mister_Cody ☺️
Натискай на зображення, щоб отримати своє передбачення 📲
Натискай на зображення, щоб отримати своє передбачення 📲
👍9😁5👎1🔥1
Як працює авторизація❓
📌 Авторизація - це процес перевірки, чи має користувач право на доступ до певного ресурсу або функції системи. Це зазвичай залежить від прав, наданих користувачеві в системі. Якщо користувач є успішно авторизованим, то він отримує доступ до необхідних ресурсів або функцій системи.
Процес авторизації може відрізнятися залежно від конкретної системи, але зазвичай він складається з наступних кроків 👇
▪️ Користувач намагається отримати доступ до ресурсу або функції системи.
▪️ Система перевіряє, чи існує для цього користувача відповідний запис у системі.
▪️ Система перевіряє, які права доступу має цей користувач до даного ресурсу або функції.
▪️ Якщо користувач має достатні права доступу, то він успішно авторизований і отримує доступ до ресурсу або функції.
▪️ Якщо ж права доступу відсутні або недостатні, то користувачеві відмовляють в доступі.
📌 Авторизація - це процес перевірки, чи має користувач право на доступ до певного ресурсу або функції системи. Це зазвичай залежить від прав, наданих користувачеві в системі. Якщо користувач є успішно авторизованим, то він отримує доступ до необхідних ресурсів або функцій системи.
Процес авторизації може відрізнятися залежно від конкретної системи, але зазвичай він складається з наступних кроків 👇
▪️ Користувач намагається отримати доступ до ресурсу або функції системи.
▪️ Система перевіряє, чи існує для цього користувача відповідний запис у системі.
▪️ Система перевіряє, які права доступу має цей користувач до даного ресурсу або функції.
▪️ Якщо користувач має достатні права доступу, то він успішно авторизований і отримує доступ до ресурсу або функції.
▪️ Якщо ж права доступу відсутні або недостатні, то користувачеві відмовляють в доступі.
👍6🔥4❤1
🔎 Для реалізації процесу авторизації система зазвичай використовує різні методи індентифікації та автентифікації користувача, як-от логін та пароль, біометричні дані тощо.
Автентифікація і авторизація: у чому відмінність? 🤔
🔑 Автентифікація й авторизація - це два різні процеси, пов'язані з ідентифікацією користувача та його доступом до ресурсів системи.
Часто ці два поняття плутають чи взаємозамінюють. Процедура входу у власні соцмережі, онлайн-гру, пошту чи на певний сайт супроводжується введенням логіну і паролю. Після цього ми отримуємо доступ до сторінки. ❗️ Саме це часто і називають авторизацією, що з технічного боку – неправильно:
⌨️ натискання Enter в формі введення запускає два абсолютно різні процеси – автентифікацію і авторизацію. Для чого їх розрізняти? Коли виникає помилка, необхідно чітко розуміти, на якому етапі відбувся збій.
До головного і по-простому 👇
✅ Автентифікація – це підтвердження того, ким є користувач на вході. Це проходження перевірки автентичності.
✅ Авторизація – це те, що користувачеві дозволяється робити після входу. Це надання і перевірка прав на вчинення будь-яких дій у системі.
☝️ Отже, відмінність між автентифікацією та авторизацією полягає в тому, що автентифікація визначає, хто користувач, натомість авторизація визначає, чи має цей користувач право на доступ до певного ресурсу або функції системи.
Підписуйтесь на інші соціальні мережі 👇
TikTok | Instagram
#codica_tech
Автентифікація і авторизація: у чому відмінність? 🤔
🔑 Автентифікація й авторизація - це два різні процеси, пов'язані з ідентифікацією користувача та його доступом до ресурсів системи.
Часто ці два поняття плутають чи взаємозамінюють. Процедура входу у власні соцмережі, онлайн-гру, пошту чи на певний сайт супроводжується введенням логіну і паролю. Після цього ми отримуємо доступ до сторінки. ❗️ Саме це часто і називають авторизацією, що з технічного боку – неправильно:
⌨️ натискання Enter в формі введення запускає два абсолютно різні процеси – автентифікацію і авторизацію. Для чого їх розрізняти? Коли виникає помилка, необхідно чітко розуміти, на якому етапі відбувся збій.
До головного і по-простому 👇
✅ Автентифікація – це підтвердження того, ким є користувач на вході. Це проходження перевірки автентичності.
✅ Авторизація – це те, що користувачеві дозволяється робити після входу. Це надання і перевірка прав на вчинення будь-яких дій у системі.
☝️ Отже, відмінність між автентифікацією та авторизацією полягає в тому, що автентифікація визначає, хто користувач, натомість авторизація визначає, чи має цей користувач право на доступ до певного ресурсу або функції системи.
Підписуйтесь на інші соціальні мережі 👇
TikTok | Instagram
#codica_tech
🔥12👍7❤2