Этим постом я запускаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В программе: рассказ об основах SQL, возможностях простых и сложных SELECT, анализ производительности запросов, разбор [не]эффективного применения индексов и особенностей работы транзакций и блокировок в этой СУБД.

Курс не претендует на лавры "войти в айти", поэтому подразумевает наличие у слушателя опыта программирования или работы с другими СУБД, и, главное, желания самостоятельно изучать тему работы с PostgreSQL глубже.

Для тех, кому комфортнее смотреть и слушать, а не читать - доступна видеозапись.

Привет! Меня зовут Гриша и я бэкенд разработчик на .net 

С друзьями мы часто обсуждаем процессы разработки, в том числе как пишутся автотесты. Я часто слышу о подходах, которые несут боль разработчикам и одновременно с этим приносят мало пользы. 

При этом я строю весь процесс разработки микросервиса на тестах. Я бы хотел поделиться своим взглядом на то, как писать компонентные тесты и в чём они могут быть полезны помимо проверки работы сервиса.

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

Всем привет! Меня зовут Александр Кулик, я .NET-разработчик из команды checkout в Тинькофф. Занимаюсь бэкенд-разработкой по интеграции платежных решений, внешних сервисов и созданию собственных разработок для B2B-сферы.

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

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

Эта статья является переводом материала «When to Mock».

Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

Все мы знаем, что логирование - вещь очень полезная для современного проекта. С помощью него можно быстро локализовать и устранить ошибку в продукте, восстановить кейс, который к ней привёл, посмотреть историю действий пользователя.

Существует несколько видов логирования, а какие, чем отличаются и что такое структурное логирование - давайте разбираться!

Тестирование, принцип TDD, юнит-тестирование и прочее.

1. Мы делаем сайт, показываем заказчику, он высылает список неточностей и дополнительных пожеланий, мы их бодро правим и сайт отдаем заказчику, т.е. выкладываем на его сервер. На его сервер никто не ходит, заказчик понимает, что чуда не произошло и перестает платить за хостинг/домен. Сайт умирает. Нужны ли там тесты?
2. Мы делаем сайт, показываем заказчику, он высылает список правок, мы их бодро правим, запускаем сайт. Через полгода на сайте 300 уников в день и эта цифра растет изо дня в день. Заказчик постоянно просит новые фичи, старый код начинает разрастаться, и со временем его всё сложнее поддерживать.

Приложения ASP.NET Core по-настоящему кросс-платформенны и могут запускаться в «никсах», а соответственно, и в Docker. Посмотрим, как их можно упаковать, чтобы развертывать на Linux и использовать в связке с Nginx. Подробности под катом!

1. YAGNI

Предисловие

Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?

Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.

MailboxProcessor

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

В большинстве случаев вся enterprise разработка сводится к выполнению одних и тех же требований: создается заявка, в зависимости от типа заявки у нее есть какой-то жизненный цикл, по завершению жизни заявки мы получаем (…или не получаем) желаемое. Под заявкой мы можем подразумевать все что угодно, начиная с покупки в интернет-магазине товара, денежного перевода или расчета траектории баллистической ракеты. У каждой заявки есть свой жизненный путь и что важно отметить - время жизни, и чем меньше это время, тем лучше. Иными словами, чем быстрее мой банковский перевод осуществится, тем лучше. Требования тоже схожи, побольше RPC operations per second, поменьше Latency, система должна быть отказоустойчивой, масштабируемой и должна быть готова вчера. Есть миллион инструментов, сотни баз данных, различные подходы и паттерны. И все уже давно написано, нам остается лишь правильно использовать готовые технологии в наших проектах. 

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

Однажды я вел вебинар про то, как принимать 10 000 ивентов в секунду. Показал картинку, зрители увидели сиреневый слой, и началось: «Ребят, а зачем нам все эти кафки и рэббиты, неужели без них не обойтись»? Мы и ответили: «Зачем-зачем, чтобы пройти собес!»

Очень смешно, но давайте я все-таки объясню.

В этой статье я не буду объяснять, зачем вот это всё нужно, или обсуждать достоинства и недостатки этого решения. Воспринимайте эту статью как инструкцию (заметку) для быстрого развёртывания базы и брокера сообщений в dev-кластере Kubernetes.

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

RabbitMQ держит сообщения в очереди (Queue), которая является именованным буфером, хранящим адресованные ему сообщения.

Программа, посылающая сообщения в очередь RabbitMQ, называется поставщиком (Producer).

Программа, принимающая сообщения, называется подписчиком (Consumer). Такие программы подписываются на события поступления сообщения в очередь, и всегда находятся в ожидании новых сообщений.

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

Введение

Добрый день, Хабр! Хочу поделиться учебником-справочником знаний, которые мне удалось собрать по RabbitMQ и сжать в короткие рекомендации и выводы.

Queue (очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers (потребителям). Queue представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.

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