Принцип хорошего автотеста — «Подготовь себе данные сам. Не надейся, что они уже существуют». Такой тест можно прогнать на любом стенде, даже пустом. Сам себе всё подготовил, прогнал тест, а потом ещё почистил за собой.

В Postman тоже есть возможность подготовить себе данные для запроса. Причем это можно использовать не только для автоматизации, но и для ручного прогона. Удобно же, когда можно запустить конкретный запрос на конкретный метод, а он отработает успешно хоть на пустой базе, хоть на заполненной.

Подготовка данных делается через функцию pm.sendRequest() в pre-request скриптах, и в этой статье я покажу, как её использовать. Показывать буду в стиле «бери и повторяй» с примерами на бесплатной системе Users.

Тестирование веб-API нужно, чтобы обеспечить надёжность взаимодействий и обработки данных в приложениях. Ошибки в API могут вызвать сбои и уязвимости, поэтому проверка аутентификации, авторизации и шифрования критична. Качественно протестированные API улучшают пользовательский опыт и снижают затраты на дальнейшую поддержку продукта.

Михаил Абрамов, технический писатель платформы МТС Exolve, подготовил для начинающих специалистов чек-листы с основными правилами и процедурами тестирования.

Здравствуйте! Меня зовут Дмитрий Моряков, и я ведущий системный аналитик в компании МаксимаТелеком. Теме миграции с монолита на микросервисную архитектуру (здесь и далее — МСА) за последние годы на страницах Хабра было посвящено немало материалов, поэтому я хотел бы сосредоточиться на узких аспектах этого процесса: выделении критической части при реализации пилотного проекта миграции на МСА и реализацию изоляции полученных микросервисов по данным.

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

В начале — пару слов о себе. Меня зовут Полина и я работаю «Rocket Business» уже несколько лет. Свой путь от джуна до тимлида прошла именно здесь. Поэтому своим мини-пособием решила делиться в корпоративном блоге: оставляю в помощь потомкам и аудитории Хабра. 

В современной быстро меняющейся цифровой среде обеспечение надежной безопасности на каждом этапе взаимодействия с пользователем имеет первостепенное значение. Хотя существует множество инструментов для защиты наших приложений, найти идеальное сочетание между ними может быть непросто. На помощь приходит динамичный дуэт: Nginx и Keycloak. В паре эти инструменты обеспечивают мощное решение по обеспечению безопасности вашего приложения. Nginx, известный своей высокой производительностью и масштабируемостью, в сочетании с надежными механизмами аутентификации и авторизации Keycloak строит крепость, защищающую ваши приложения от несанкционированного доступа. В этой статье мы рассмотрим все тонкости этой привлекательной комбинации и покажем, как можно использовать их общие преимущества для создания надежного и удобного шлюза для ваших приложений.

Прежде чем погрузиться в рассмотрение Nginx и Keycloak, давайте вернемся к некоторым основополагающим концепциям безопасности.

Понимание разницы: Аутентификация vs Авторизация

В сфере безопасности часто встречаются термины "аутентификация" и "авторизация". Хотя они могут звучать похоже и иногда используются как взаимозаменяемые, все же имеют разные значения и функции. Давайте разберемся в каждом из этих терминов, чтобы понять их разницу и важность.

1. Аутентификация

Определение: Аутентификация - это процесс проверки подлинности личности пользователя, системы или приложения. Она отвечает на вопрос: «Вы тот, за кого себя выдаете?»

Как это работает: Наиболее распространенной формой аутентификации является комбинация имени пользователя и пароля. Когда пользователь вводит эти учетные данные, система сравнивает их с сохраненными данными, чтобы подтвердить его личность. Другие методы включают биометрию (например, распознавание отпечатков пальцев или лица), OTP (одноразовые пароли) и аппаратные токены.

У нас в команде два системных аналитика с разным бэкграундом и изначально разными подходами к оформлению требований, в том числе к API. Вначале каждый из нас писал требования по-своему, с разным уровнем проработки и детализации. Но быстро стало понятно, что так дальше не пойдет: это приводило к разночтению требований разработчиками и тормозило реализацию. Поэтому мы в команде решили унифицировать формат описания требований к API.

В статье расскажу, к какому формату описания в итоге мы пришли, и покажу заполнение шаблона на конкретных примерах.

Привет, Хабр!

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

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

От переводчика: в ходе моей работы в нигерийском финтехе пришлось мне создавать с нуля одну платежную систему. Я тогда ничего толком не понимал в вопросах бухгалтерии, в том как именно лучше хранить платежи и балансы. Но было подозрение, что примитивный вариант с одной циферкой баланса в аккаунте пользователя слишком прост, чтобы быть правильным.

Разобраться и избежать кучи граблей в этом деле мне помогла данная статья. При этом информации по теме "как сделать свою платежную систему" довольно мало, а в учебниках по бухучету программисту сходу разобраться не так просто (и очень нудно). Надеюсь, этот материал окажется полезным тем, кто только собирается что-то такое делать.

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

Введение

Многие компьютерные системы, использующие реляционные БД, хранят в них какую-то финансовую информацию о балансах и транзакциях. При этом при проектировании и разработке такой БД часто встает вопрос, а как именно хранить эту информацию. Обычно выбор стоит между дешевой "простой записью" и более сложной "двойной записью".

Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи

В системе с "простой записью" числовые значения записываются только один раз. В системе с "двойной записью" каждое значение записывается дважды, как кредит (положительное значение) и как дебет (отрицательное значение). При этом есть набор правил, определяющих связь между этими значениями. Эти правила вам легко опишет любой опытный бухгалтер, хотя он может и не представлять, как именно они могут быть представлены в реляционной БД.

Основные правила таковы:

Вы идёте в ногу со временем, и ваше веб-приложение использует самые передовые технологии? Тогда вы совершенно точно используете микрофронтенды! Достаточно провокационно, правда?

Всем, привет.  Для самых жаждущих и нетерпеливых эта в этой статье будет про:

• Типы анализа, используемые для/около информационных технологий;

• Систему координат типов анализа и для чего использовать каждый из них;

• Специальные артефакты для каждого типа анализа;

• То, как понять, что в компании/процессе/проекте нужно использовать конкретный тип анализа;

• Акценты и навыки, нужные при использовании каждого типа анализа;

Для тех, кому интересно и хочется сложить причинно-следственные связи, проследить нить рассуждений, то давайте это сделаем. Я Иван. Люблю сферу информационных технологий и стремлюсь развиваться в дисциплинах, задействованных для создания информационных продуктов – анализе, проектировании, разработке. Эти дисциплины влияют друг на друга и на конечный результат - создаваемую информационную систему.

Рассуждая, что такое анализ, какой он бывает, какой тип, в каких условиях использовать и какие навыки нужны для того, чтобы его выполнять, я предположил, что будет полезным систематизировать имеющийся опыт и результаты обсуждения с коллегами, слушателями профессиональных программ развития НИУ ВШЭ, МИСИС, интернет университетов. Так появился следующий обзор. Надеюсь, он принесет вам пользу. Рассчитываю на обсуждение. Присоединяйтесь :-)

Разработка надежной, масштабируемой и эффективной системы может оказаться довольно сложной задачей. Однако понимание основных принципов и компонентов этого процесса может сделать его более управляемым. В этой статье мы рассмотрим основные компоненты в проектировании систем, такие как DNS, балансировка нагрузки, API-шлюз и другие. Также мы предоставим краткую схему, которая поможет разработчикам проектировать системы различной сложности.

Продолжением предыдущей статьи об архитектуре и интеграциях Архитектура приложений и интеграции: гайд по основным понятиям простыми словами / Хабр (habr.com), в данной статье будет освещен вопрос асинхронной интеграции. 

В статье будет описано, что такое асинхронная интеграция в общих чертах, и как она чаще всего реализуется. В первую очередь статья предназначена для аналитиков и начинающих разработчиков, чтобы сформировать общее представление по данному вопросу.

Здесь мы доступно знакомим с видами архитектур, их общим назначением, наиболее очевидных преимуществах и недостатках.

Мини-туториал по теме от лида-аналитика "ITQ Group" Виталия Якубина.

Есть разные подходы к ведению требований к ПО: одни пишут полноценные сценарии использования, другие выбирают пользовательские истории, а третьи — вообще избегают формализации требований, считая это пустой тратой времени.

Но я так не считаю. Формализация — большой и важный этап разработки требований. В статье об этом расскажу: как происходит ведение требований у нас, какие этапы мы проходим, каких правил придерживаемся и что будет, если отклоняться от правил. Если вы системный или бизнес-аналитик, владелец продукта или просто работаете с требованиями к программному обеспечению, то эта статья для вас.

Если вы работаете с вебом, вы обязательно столкнётесь с брокерами сообщений. Они бывают разные, но чаще остальных встречаются Kafka, RabbitMQ и AWS SNS/SQS. У каждого из них есть свои особенности, плюсы и минусы — выбирать брокер нужно под свою задачу. 

О том, как сделать правильный выбор, рассказали эксперты из команды курса «Go-разработчик» Яндекс Практикума: