Spring Security in Action

Автор: Laurentiu Spilca
Год издания: 2020

#spring #english

В чем разница между COUNT(*) и COUNT({column})?

COUNT (*) подсчитывает количество записей в таблице, не игнорируя значение NULL, поскольку эта функция оперирует записями, а не столбцами.

COUNT ({column}) подсчитывает количество значений в {column}. При подсчете количества значений столбца эта форма функции COUNT не принимает во внимание значение NULL.

Что такое «модульное тестирование»?

Модульное/компонентное тестирование (unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.

Модульные тесты можно условно поделить на две группы:
• тесты состояния (state based), проверяющие что вызываемый метод объекта отработал корректно, проверяя состояние тестируемого объекта после вызова метода.

• тесты взаимодействия (interaction tests), в которых тестируемый объект производит манипуляции с другими объектами. Применяются, когда требуется удостовериться, что тестируемый объект корректно взаимодействует с другими объектами.

Чем stub отличается от mock?

stub используется как заглушка сервисов, методов, классов и т.д. с заранее запрограммированным ответом на вызовы.

mock использует подмену результатов вызова, проверяет сам факт взаимодействия, протоколирует и контролирует его.

​👨‍💻👩‍💻ТОП-15 корисних посилань для самопідготовки в ІТ

Скоро ми переможемо і на Україну чекає хвиля змін, інноваційний прорив та економічне зростання. Нашій країні знадобиться ще більше кваліфікованих ІТ-фахівців, які зможуть підкорити цю хвилю своєю майстерністю та технічними рішеннями. Саме тому наша рекомендація дуже проста: якщо ви та близькі в безпеці та маєте можливість подумати про майбутнє – починайте готуватись до нього вже зараз!

Ми підготували перелік корисних посилань для ІТ-початківців, які тільки починають свій професійний шлях або тих, хто планує змінити свою теперішню кар’єру.

1) ENGLISH🔥 English Self-Study Materials | Безліч корисних матеріалів за всіма рівнями, що підійдуть для кожного.

2) BASICS🔥 Harvard course CS50 - курс CS50 Гарвардського університету вважається найкращим з основ програмування в світі. Він розрахований як на повних новачків, так і на більш досвідчених в програмуванні. Програма включає лекції та практичні завдання.

3) FRONTEND🔥 Codecademy HTML & CSS - зрозуміти, як працює HTML и CSS – першочергова задача всіх, хто хоче почати вивчення будь-якої професії в ІТ. А в CodeAcademy є досить багато онлайн курсів за усіма напрямками в ІТ.
+ W3SCHOOLS – англомовний ресурс для самостійного вивчення FrontEnd, тут завжди найновіша та найбільш актуальна інформація.

4) JAVA🔥 The Java™ Tutorials – оригінальна документація компанії Oracle з мови Java. Основа основ та першоджерело усіх знань з Java.
+ Корисна стаття на нашому порталі: «З чого почати?» Які знання необхідні розробнику-початківцю.

5) .NET🔥 Офіційна документація Microsoft з мови C# - тут є багато ресурсів для вивчення мови C#. Залежно від вашого досвіду програмування чи роботи з мовою C# та платформою .NET, вам будуть цікаві різні розділи цього посібника.
+підбірка Bookshelf початківця в .NET-розробці.

6) SOFTWARE TESTING🔥 Книга International Software Test Institute – ця книга охоплює всі аспекти тестування програмного забезпечення, розповідаючи про всі процеси, метрики та ризики в тестуванні.
+стаття Що читати та дивитися тестувальнику-початківцю.

7) DEVOPS🔥Матеріали для самопідготовки та безліч корисних матеріалів від EPAM University.

8 ) BUSINESS ANALYSIS🔥 Для чого потрібен бізнес-аналіз і хто такі бізнес-аналітики?
+стаття Що роблять бізнес-аналітики в ІТ, необхідні знання та вміння

9) BUSINESS INTELLIGENCE🔥 SQL Tutorial - для початківців та не тільки. Знадобиться в роботі ВІ не одну сотню разів.

10) 🔗А також, дуже рекомендуємо зберегти собі розділ з матеріалами на нашому EPAM Training Portal, де ми зібрали безліч корисних статей та додаткових важливих посилань.

💙💛Все буде Україна!

Разбор 4х задач по SQL, которые могут встретиться на собеседовании.

Напомним, что недавно мы публиковали серию руководств по SQL для начинающих. Можно подтянуть знания 💪:

🔗 Часть 1
🔗 Часть 2
🔗 Часть 3

Идемпотентность

Идемпотентная операция — операция, которая при многократном вызове оставляет систему в одном и том же состоянии. Это значит, что:
🔸 Возвращаемый результат один и тот же
🔸 Сайд эффекты не накапливаются

Неважно сколько раз вызван метод — эффект будет одинаковый. Что может быть сайд-эффектом: запись в БД, обновление статистики, запись в файл, изменение общих переменных.

Примеры идемпотентных операций:

✅ Удалить элемент с id=50
(10 вызовов → 1 удаление)
❌ Удалить элемент максимального размера
(10 вызовов → 10 удалённых элементов)
✅ Прочитать число из БД, умножить результат на 2 и вернуть пользователю
❌ Прочитать число из БД и обновить статистику запросов

В чём смысл?

Идемпотентные операции повышают устойчивость системы.

Допустим, мы отправили запрос на сервер, и соединение пропало. Спустя 3 секунды восстановилось. Возникает дилемма:

🤔 Отправить запрос ещё раз? Но вдруг он уже был обработан…
🤔 Может не отправлять? А если предыдущий пропал…

Запрос либо дублируется, либо теряется. Для идемпотентного запроса такой проблемы нет, можно спокойно отправить его ещё раз.

На собеседованиях вопрос идемпотентности обычно обсуждают со стороны HTTP вызовов. Нужно сказать, что GET, PUT and DELETE идемпотентные, а POST — нет.

Но жизнь чуть сложнее.

🔹 Во-первых, идемпотентность зависит от бизнес-логики, а не от выбранного метода

Здесь самое сложное — держать под контролем сайд эффекты. Возьмём как пример увеличение счётчика в БД:

UPDATE t SET value=value+1

Как сделать его идемпотентным?

Добавить в таблицу (и сущность) поле version. Клиент передаёт номер текущей версии при обновлении. Запрос получается такой:

UPDATE t SET value=value+1, version=version+1 WHERE version=88

🔹 Во-вторых, POST запросы можно сделать идемпотентными. Например так:

Клиент генерирует ID и добавляет его в хэдер HTTP запроса:

Idempotency-Key: 4872934

Сервис хранит у себя список ID недавних запросов. Если операции с таким ID ещё не было, сервис начнет выполнение.

Процесс фильтрации дубликатов называется дедупликацией.

❓ Выглядит как лишняя сложность, нужна ли вообще идемпотентность?

Исходная проблема — что делать с только что отправленными запросами при потере связи. Идемпотентность и повторная отправка — рабочий способ, но не единственный. О другом расскажу в следующем посте.

​Message brokers, часть 1: RabbitMQ

Оба брокера реализуют паттерн publish/subscribe. Его основные участники это

🔸 Producer — отправляет сообщения. Сообщение состоит из ключа, значения и хэдеров
🔸 Consumer — принимает сообщения
🔸 Message broker — компонент для обмена сообщениями, разворачивается отдельно

Основная структура данных для распределения сообщений — очередь. Обычно в системе целое море продюсеров, очередей и консьюмеров. Чтобы упростить общение между ними, RabbitMQ использует промежуточный слой — exchangers.

Принцип работы:

Продюсеры просто отправляют сообщение в эксченджер. Оттуда оно распределяется в подходящие очереди в зависимости от ключа, хэдеров и настроек эксченджера. Сообщение копируется во все подходящие очереди.

Консьюмер подсоединяется к интересным очередям и забирает оттуда сообщения.

Чтобы было понятно, как это выглядит, посмотрите на картинку внизу поста👇

Сообщение удаляется из очереди после прочтения. Отсюда идут следующие схемы:

▫️ Если сообщение должны прочитать несколько получателей — у каждого должна быть своя очередь, куда это сообщение попадёт.

Пример: сообщение order.from-A.to-C. vip попадает в две очереди — order.from-A.* и order.*.*.vip

▫️ Если нужно распределить сообщения между получателями, консьюмеры подключаются к одной очереди. RabbitMQ распределяет сообщения между ними равномерно по принципу round-robin.

Пример: сообщение order.from-A.to-B и order.from-A.to-C распределяются между консюмерами С1 и С2

Рэббит использует push модель — каждое сообщение из очереди вызывает коллбэк на консьюмере. Это нужно, чтобы равномерно распределять сообщения между получателями.

Очереди и связи задаются не в брокере, а в приложении. Роутинг сообщений получается супер гибким, и добавлять новых участников в систему легко. Из разных типов эксченджеров и очередей собирается огромное количество паттернов.

Главное в RabbitMQ:
✔️ Основной компонент — exchanger и связанные с ним очереди
✔️ Сообщения удаляются после прочтения
✔️ Push-модель
✔️ Гибкий роутинг сообщений

​Message brokers, часть 2: Kafka

Если RabbitMQ — это 100% очередь, то Kafka больше похожа на список, потому что данные после чтения не удаляются. В принципе это основное отличие двух брокеров, остальное — просто следствие.

Один список называется partition. Несколько partition можно объединить в группу, которая называется topic.

Консьюмеры читают данные из партишена или топика. Для каждого консюмера хранится индекс последнего прочитанного сообщения (offset). Когда получатель прочитает сообщение, Kafka сдвинет его offset. И в следующий раз этот получатель прочитает другие сообщения.

Если в partition 10 сообщений, то
🧔🏻 Один консьюмер прочитает сразу всё
👳🏻 Другой прочитает 5 и потом ещё 5
👩🏼‍🦰 Третий будет вычитывать по одному сообщению

И никто никому не мешает☺️

В рамках одного partition все консюмеры читают сообщения в одном порядке. Иногда это очень важная фича. Для топика из нескольких partition такой гарантии нет.

Поскольку данные не удаляются при чтении, получаются немного другие схемы работы:

🔸 Если сообщение должны прочитать несколько однотипных получателей, достаточно записать их в один partition

🔸 Если получатели разнотипные, то продюсер должен добавить данные в несколько партишенов.
Пример: чтобы сообщение “A to C vip” прочитали C1 и C4, продюсер отправляет запись в топик orders и vip_orders.

🔸 Если нужно распределить сообщения по получателям, то консьюмеры объединяются в consumer group с общим оффсетом

Резюме

▫️ В Kafka сообщения не пропадают при чтении, их можно читать несколько раз и пачками
▫️ Гарантия порядка сообщений в рамках одного partition
▫️ Kafka занимает горааааздо больше места на диске
▫️ Kafka использует pull модель — получатели сами решают, когда забрать сообщения. В RabbitMQ инициатива исходит от очереди, чтобы равномерно распределять сообщения
▫️ Разные схемы общения с продюсерами и консьюмерами. На картинке ниже я представила аналог схемы из предыдущего поста
▫️ Разные сценарии масштабирования и отказоустойчивости
▫️ Субъективное мнение — в рэббите проще распределять сообщения по получателям. Kafka подходит для накопления данных и более сложных сценариев
▫️Объективное — Kafka используется на бОльшем количестве проектов, пусть даже в качестве простой очереди😐

Общие черты двух брокеров:

🐰🐞 Отлично поддерживаются спрингом
🐰🐞 Можно настроить хранение сообщений на диске
🐰🐞 Нужно супер тщательно продумать схему работы и масштабирование

PS Эти посты — самые основы месседж брокеров, прямо вот верхушечка. Для дальнейшего изучения подойдёт эта серия статей, книги "RabbitMQ in Action" и "Kafka in Action".

Transient = do not serialize the field