Зачем вам нужен докер?

Встретили тут в бизнесе мысль: "мы недостаточно большие, чтобы использовать Docker". Не можем согласиться с таким тезисом. В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend,frontend, базы данных, nginx и Let's Encrypt.

7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.

8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.

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

Для вас мы снимали ролик про изучение атаки forkbomb в Docker. В ролике можно увидеть, как просто применять докер. Для углублённого изучения недавно был пост с практическими советами по Docker.
#devfm #skills

Теория подталкивания или метод наджей

Двадцать лет назад журнал The Economist предлагал три варианта подписки:
1. 59$ в год на онлайн-версию
2. 125$ за печатную и онлайн-версию
3. 125$ только за печатную версию

В таких условиях мало кто купил первый вариант, большинство предпочло второй вариант и никто — третий. На следующий год третий вариант убрали. К чему это привело? Большинство выбрало первый вариант, так как он существенно дешевле.

Человеком можно манипулировать в достаточно широких пределах. В статье Как приучить соседей правильно закрывать дверь с помощью книжки про маркетинг⁠⁠ рассказывается интересный опыт, как можно подтолкнуть соседей закрывать плохой замок "как надо".

Почему бы не заменить замок на нормальный? Это не путь джедая.

Подробнее про наджи посмотреть в книге Nudge. Архитектура выбора. Один из авторов, Ричард Талер, спустя 10 лет получил Нобелевскую премию по экономике за теорию подталкивания.
#fun #edu #books

Кино на выходные

Мы уже говорили про фильмы о хакерах и реальность окружающего мира. Объединим эти темы. Может ли программист создать искуственный интеллект? Этично ли уничтожать созданный искуственный интеллект? Эти и другие вопросы в красочном фильме Из машины (2014).

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

#fun #films

Паттерн Сага

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

Представим, что пользователь делает заказ в интернет-магазине. Заказ затрагивает сразу три сервиса:
1. складской сервис, где товар списывается
2. сервис организации курьерской доставки, куда товар передаётся
3. сервис платежей, в котором списываются деньги за заказ

Заказ не вызывает проблем, пока всё идёт штатно. А что делать, если оплата не прошла? Ведь со склада уже списалась единица товара и назначена доставка.

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

Отличная иллюстрация такого упрощения — статья ребят из Озон Доводим распределённые действия до конца с использованием простейшего паттерна Saga. В начале даются минимально достаточные теоретические выкладки по Саге, а потом — детали реализации на своём проекте. Опираясь на анализ своей предметной области, автору удалось опустить избыточные элементы паттерна. Ранее мы предлагали свой способ комплексного анализа предметной области для новых проектов.

Отдельного внимания заслуживает описание проблем, с которыми команда столкнулась в процессе реализации, а также способы их решения.
#skills

Wine для доступа к Windows-приложениям на Linux

Периодически раздражает необходимость иметь Windows-машину для доступа к специфическому софту, в том числе играм. Решением может быть multi-boot, но каждый раз перезагружаться? Виртуальная машина — неплохое решение. Но ВМ съест почти гигабайт оперативной памяти и 20%-30% процессора на накладные расходы.

Более интересным решением может быть Wine или его форк Proton от Valve. Никаких расходов на виртуализацию, потому что wine — не эмулятор. Windows-приложение запускается как нативное прямо в Ubuntu. Ну, если запускается.

Для любого софта в разделе Test Results на сайте winehq можно посмотреть совместимость. Для примера StarCraft. Если совместимость Gold или Platinum — поздравляю, для этого софта ВМ не понадобится, вы через Wine сможете запустить софт прямо на своём Linux.

В статье Как работает Wine (оригинал) вы можете познакомиться с интересными деталями реализации Wine, которые позволяют запустить Windows-приложение на Linux.
#skills

Трекайте рабочее время

О правильной организации рабочего времени написан вагон книг и статей. Мы упоминали помидорную технику.

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

Считаю, что мастхев трекать время в двух случаях:
1. когда сдельно работаешь на разных проектах
2. когда работаешь на удалёнке, чтобы соблюдать work-life balance

При проектной разработке со сдельной оплатой для меня важна выгодность проекта. И измерение времени связано непосредственно с зарабатываемыми деньгами.

Приведу пример: за проект мне заплатят Х денег. Но вот вопрос: а на сколько он выгоден? А если невыгоден, то из-за чего? Что мне сделать для увеличения выгоды? Есть количество денег в час, которое меня удовлетворяет. Поделив полученный Х на количество затраченных часов, я могу понять уровень своей удовлетворенности.

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

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

У меня в таск-менеджере есть ежемесячная задача на анализ выгодности своих проектов. Это позволяет держать руку на пульсе.

Когда я работаю на обычной работе, я работаю удалённо. И тут вот какая проблема. Ты вроде дома, а вроде и на работе. Я заметил два момента:

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

— Грустно для меня. Просыпаюсь и сразу за работу, весь день ударно работаю. Вечером вроде уже закончил, но вот возник вопросик, и компьютер соблазнительно близко — почему бы быстро не глянуть, что там за проблема. В итоге день в работе, вечер в работе, а и вечный день сурка.
В этом случае измерение времени позволяет мне соблюдать тот самый work-life balance.

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

Небольшое предостережение: с первого взгляда может показаться, как же классно знать куда уходит моё время, это же такое прекрасное поле для оптимизаций. Не замахивайтесь сразу на сложное — измерять всё. Сколько времени кушал, развлекался, занимался спортом, уборкой и миллионом других занятий. Мой опыт показал, что это бесполезная информация, а отслеживание большого количества активностей требует серьёзной собранности. Без четкого понимания цели, вы, скорее всего, быстро забьёте. Если хотите попробовать трекать время остановитесь на том, что вам действительно важно.

Что касается приложений для этих целей — я пользуюсь atracker, коллега atimelogger, но вариантов много на любой вкус.
#devfm #edu

Снижаем нагрузку на БД с помощью аналитической базы

Не новая, но концептуально верная статья ReportingDatabase от дядьки Боба.

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

Для обработки сложных аналитических запросов предлагается создать отдельную базу данных — reporting database. Причем это может быть совершенно любая другая база данных, отличная от основной.
К плюсам такого подхода относятся:
— возможность выбрать базу, заточенную под аналитические запросы
— нет необходимости заботиться нормализации данных
— сложные запросы к reporting db не нагружают основную базу


Возможно, для вашей задачи отдельная БД не требуется. Вот и дядька Боб в конце рассказывает, что хороший базовый вариант — использовать классические views с вынесением их на отдельную ноду кластера. Представления позволяют создавать логические таблицы с данными, а их вынесение на отдельные вычислительные ресурсы позволяет разгрузить базу при построении сложной аналитики.
#skills #database

refurb — ещё один анализатор кода

У нас уже был пост про утилиты для анализа кода, которые мы постоянно используем в своих проектах.

Нашли на просторах гитхаба интересный проект — refurb. Ещё один анализатор кода, ставящий своей целью сделать код более питонячим и правильным. Никакого rocket science, просто набор формализованных правил, на которые проверяется код.

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

Из приятного, командой refurb --explain можно посмотреть подробное объяснение любого замечания. Этого не хватает во многих анализаторах, где за объяснением диагностик приходится лезть на stackoverlow.

Я попробовал погонять его на своих проектах. После автоматического запуска всех наших анализаторов в pre-commit оказалось, что рефёрбу ничего не осталось и никаких замечаний он не выдал.

Судя по свежим коммитам, проект активно развивается. Планируем посмотреть на него ещё через полгодика. Если он войдёт в список наших must have анализаторов, обязательно расскажем об этом. Попробуйте запустить его на своем проекте. Нашёл ли он что-то интересное? Добро пожаловать в комментарии.
#python

Зачем нужны конференции

Современная конференция это:
0. Пополнение пула решённых задач. Если столкнетесь с похожей ситуацией, то будете владеть готовым решением с его плюсами и минусами. Это существенно повышает вашу ценность как специалиста
1. Свежая информация из первых рук
2. Расширение кругозора. Про наш способ систематического подхода к кругозору мы писали
4. Нетворкинг и контакты при оффлайн формате
5. Возможность задать вопрос

Совет – идти надо не на доклад, а на докладчика. Хороший спикер даст годный материал в любой теме.

Сегодня стартует, пожалуй, самая масштабная разработческая конференция higload++
Трансляция главного зала будет в онлайне. И уже в 10:00 начнется интересный доклад Техстратегия и архитектура highload-проекта на примере ВКонтакте

А здесь выкадываются записи предыдущих конференций.

P.S. Буду там оффлайн, можем пообщаться
#devfm #edu

Пятничное развлекательное

Продолжаем тему про маркетинг, начатую в прошлом посте про подталкивание.

Процитируем абзац из статьи Что такое маркетинг, и почему эти люди пытаются обмануть вас в большинстве случаев — ликбез:

Когда вы стоите в магазине перед двумя пачками пельменей за 150 и 250 рублей и читаете одинаковые составы, то непонятно, покупая дорогую, за что вы заплатите. Может, за качество. Может, за рекламу и место на полке при том же качестве. Может, за то, что владелец марки справедливо считает, что более высокая цена заставит вас думать, что продукт качественнее. Может, за то, что пельмени закручены в левую сторону: вам вот пофиг, а кто-то отдаст за это любые деньги.

Автор рассуждает о маркетинге со свойственным ему стилем. Кстати, это Milfgard, он же Сергей Абдульманов, про которого уже был любовный пост с подборкой интересного.

#fun

Кино на выходные

Мы поднимали тему искусственного интеллекта. Нельзя не вспомнить Айзека Азимова, который в рассказе Хоровод сформулировал три закона робототехники:
1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому или Второму Законам.

Мы всё ближе к моменту, когда эти законы из абстрактной теории станут реализованным произведением. Азимов является и автором повести Двухсотлетний человек.

Предлагаем вам чудесную экранизацию 1999 года с Робином Уильямсом в главной роли.

#fun #films #books

Преодолеваем постоянное откладывание дел

Для разгрузки оперативной памяти я все будущие задачи вношу в таск-менеджер. Независимо от объёма задачи всё должно быть записано, чтобы не держать в голове. Но дальше возникает большая проблема — некоторые задачи после внесения в таск-менеджер я не делаю никогда, постоянно отодвигая на "когда-нибудь потом". Это приводит к большим неудобствам. Например, вторая часть стрима python student уже три месяца откладывается. Проблема в том, что назначение подобной задачи "на сегодня" плохо помогает, так как задача большая и сложная, подступиться к ней сложно.
Мой опыт преодоления такой:

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

Давайте на примере. Задача "снять ролик python students, часть 2". Декомпозируем:
— решить, какие темы включить в ролик
— прописать сценарий
— прописать текст
— снять ролик
— смонтировать ролик
— расставить текстовые подсказки по ролику
— подкорректировать аудиодорожку
— выложить ролик

Прелесть такого плана в том, что каждая задача мотивирует сделать следующую. Если я нашёл темы для ролика, то уже хочется написать сценарий. Когда готов сценарий, то прописать текст уже несложно.

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

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

Еще один житейский пример: в машине загорелась лампочка "долить охлаждающую жидкость".
Уже на опыте я не заношу задачу: "Съездить в сервис и долить жидкость". Куда ехать? Когда ехать? — вот такие вопросы у меня будут возникать и я точно буду её откладывать.

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

Обратите внимание на подсказки в скобках, они позволяют в момент решения задачи дополнительно не думать: А как выбрать сервис? А что нужно дополнительно уточнить, когда буду звонить?

Полезны ещё несколько аспектов:
✅ При составлении плана учитываю будущую загрузку, не планирую 40 задач по часу каждая на воскресенье. Приходит с опытом. Или не приходит.

✅ Учитываю приоритет задачи. Если задача важная / выгодная / полезная, то планирую её пораньше.

✅ Умеряю перфекционизм. Часто надо сделать хорошо, а не идеально. Опускаться до уровня "кое-как" не всегда оправданно, но иногда и это годится.

✅ Для меня ещё работает практика начать чуть-чуть. Если к чему-то не могу приступить, просто ставлю себе установку — начну и 15 минут поделаю. Обычно после такого начала продолжаю делать задачу. А если нет, то не расстраиваюсь, значит задача не такая нужная.

В дополнение вспомним про хорошую и плохую прокрастинацию от Пола Грэма. Это когда ты занят, но не тем.

А еще я каждый день анализирую список своих задач, но это тема отдельного поста.
#sudo #devfm #edu

Backup: ноябрь

Python:
1. Шаблонизатор HTML — Jinja
2. Тестирование миграций alembic
3. refurb — ещё один анализатор кода

Hardskills:
1. Зачем вам нужен докер?
2. Разухабистое логирование
3. Паттерн Сага 
4. Сервис проверки регулярок — regex101
5. Google Global Cache 
6. Проблемы MongoDB
7. Wine для доступа к Windows-приложениям на Linux
8. Снижаем нагрузку на БД с помощью аналитической базы 

Нетехнические навыки:
1. Трекайте рабочее время
2. Ключевая способность программиста 
3. Почему трава зеленая, а программисты крутые
4. Зачем нужны конференции 
5. Преодолеваем постоянное откладывание дел

Собеседования:
1. Что я увидел в своих собеседованиях, часть 2 
2. Задача на собеседовании — проектируем динамическую фильтрацию
3. Собеседование Junior Python Backend Developer 

Пятничное:
Подборка xkcd  / Кто хочет стать миллионером  / Прививка от азартных игр  / Теория подталкивания  / Что такое маркетинг 

Фильмы:
Терминатор  / Здесь курят  / Из машины и Суррогаты / Двухсотлетний человек

#backup

Визуализация json

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

Вставляешь json в поле ввода и получаешь визуализированное представление json-объекта в виде дерева. Получившееся дерево удобно смотреть, сворачивать/разворачивать узлы и искать по узлам.
#skills

Шаблоны проектирования микросервисов на практике

По мотивам недавно прошедшей конференции highload++ хотим поделиться замечательным докладом о тернистом пути построения микросервисов.

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

Но, как часто бывает в разработке, не всё получается сразу. Автор рассказывает о нескольких итерациях перехода на микросервисную архитектуру и проблемах, которые не решались с первого раза. Для решения возникавших проблем использовались некоторые шаблоны проектирования микросервисов, о которых рассказывает докладчик:

— Bounded context — правильное выделение зоны ответственности микросервиса. Мне очень нравится сформулированный в докладе принцип — микросервис должен автономно решать бизнес-задачу.

— Null object pattern — сводится к подстановке некоторых дефолтных значений, если не отвечает сервис, к которому обращаемся. Позволяет избежать каскадного отказа микросервисов, при котором из-за одного сломанного сервиса отваливается вся система.

— Circuit breaker — для настройки повторных запросов к сервисам и обращение к другим в случае какого-то отказа.

— Каскадные timeouts — непосредственно связан с предыдущим шаблоном. Неправильная настройка таймаутов сведет на нет circuit breaker.

— Health checks — проверка зависимых ресурсов микросервиса.

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

Ошибки во время обучения

Повышение эффективности обучения — всегда полезное мероприятие. 25-минутный ролик от luchanos Какие ошибки делают начинающие python-разработчики во время обучения в 2022 году подбивает много важных нюансов. Необходимая инфа для студентов, полезная любому. Конспект:
— регулярно занимайтесь
— последовательно изучайте технологии (мы советовали roadmap), в том числе git, docker
— используйте Linux-based системы: "на винде никто не программирует"
— внимательно относитесь к своему коду. Тут нельзя не вспомнить про технический долг. Это должно быть осознанное решение. Если вы назвали переменную "а", то это не технический долг. Это говнокод
— ботайте английский. Мой опыт был в паре постов про английский
— не рассчитывайте на методички по предмету. В реальной жизни придётся разбирать доки, а не уже проработанный в методичке материал
— учитесь гуглить
— курсы могут помочь, но не сделают работу за вас
— не забывайте про отдых

У автора есть интересный телеграм-канал.

#edu #youtube

Читаем документацию на примере FastAPI

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

Посмотрим на пример качественной документации, с которой можно начать погружение в мир документаций. Речь про FastAPI — крутой асинхронный веб-фреймворк. Материал подаётся очень понятно и подробно.

При чтении документации по FastAPI не возникает вопросов, как предложенный кусок кода соотносится с написанным текстом. Всё понятно. Читается, как художественная книга, никаких wtf :)

В средней документации рассказывается "что можно сделать", но нет ответа на вопрос "как это сделать правильно". То есть показывается пример применения в вакууме, который может быть непонятно, как применить на практике. У FastAPI с этим проблем нет, рассматриваются многие практические вопросы:
— как задеплоить приложение на FastAPI с помощью докера
— как организовать полноценное приложение в связке с фронтом и базой
— как сделать авторизацию, в том числе с применением JWT-токенов

В общем, очень рекомендуем. Читайте и сразу пробуйте.

PS: У FastAPI вверху есть переключатель языка. У нас возник спор, является ли плюсом наличие перевода. За кого вы?
⚡, если читаешь доку только на английском, чтобы не было искажений от перевода.
🔥, если рад русской версии документации.
#python

Пятничное развлекательное

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

Если подобный формат вам нравится, то интересной будет и двадцатиминутная короткометражка CTRL Z.

#fun #youtube

Подборка базовых материалов для python-разработчиков на 2022 год

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

Мы сформировали подборку бесплатных материалов из разных областей, которые гарантированно нужны разработчику. Опубликовали на pikabu и VC, кому как удобнее. Поддержите лайком, если годно.

Не нашли крутых материалов для начинающих по Linux. Если знаете такие, поделитесь в комментариях. Планируем ещё несколько подборок по специализациям.

#python #devfm

ACID в PostgreSQL

Видео про ACID в БД от наших друзей. В двадцатиминутном видео показывается:
— atomicity на примере транзакции в виде небольших SQL-запросов в postgres через docker, всё как мы любим
— consistency на примере демонстрации влияния незавершённой транзакции на других клиентов
— isolation на примере phantom read и настройки разных уровней изоляции транзакций
— durability с демонстрацией, что завершённая транзакция сохраняет данные на диске и падение базы не повреждает данные

У них ещё есть активное сообщество почти на 6к человек и собственный план обучения по SQL
#skills #youtube #database

Сравниваем базы данных с помощью data-diff

data-diff — простая в использовании утилита, позволяющая сравнить содержимое баз данных и найти различия. Поддерживает множество разных баз: PostgreSQL, Oracle, MySQL, ClickHouse и ещё несколько менее популярных отщепенцев.

Примерный диалог с коллегой, когда впервые увидел эту тулзу:
— Смотри какую штуку нашел!
— Зачем нам это?
— Не знаю, но прикольная же.

И вот настал день, когда-таки понадобилась. Во время миграции на managed PostgreSQL в облаке начали сыпаться ошибки, при этом накатка дампа вроде завершалась успешно. Встал вопрос, а все ли данные перенеслись? Тут-то я и расчехлил data-diff, который позволил быстро найти различия в базах и понять, что не все данные переносятся. После этого были поиски источника проблем, но это уже тема для отдельного поста.

Расскажите в комментах, если есть идеи применения data-diff на практике.
#skills #database