Airflow или что-то ещё?

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

Airflow — это такой cron на ультра-стероидах.

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

Несмотря на то, что airflow — достаточно разухабистая штука, её можно развернуть у себя локально и попробовать разные сценарии использования, руководствуясь туториалом в документации и примерами.

У себя на проекте мы прорабатываем вопрос использования чего-то подобного. Рассматриваем airflow и prefect. Конечно, ещё есть соблазн написать свой велосипедик, но, думаю, сможем удержаться.

Кто что использовал? Для каких задач? Помимо комментариев к постами у нас есть чат канала – залетайте.

#skills

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

Казалось бы, скроллбар и скроллбар, что в нём такого. Нашли прикольный сайт Evolution of the Scrollbar, где продемонстрирована история развития этой незамысловатой штуки.

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

И на всякий случай: горизонтально скроллить можно с помощью shift+колёсико мышки.

#fun

Поиск недокументированных API

Несложная практическая статья, посвящённая поиску недокументированных API. Ну вы знаете, частенько бывает нужно откуда-то что-то спарсить, создать датасетик в исследовательских целях.

Автор начинает просто – что такое недокументированные api, для чего могут пригодиться.

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

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

Ещё по статье раскиданы ссылки на интересные детективные расследования, например, Google Has a Secret Blocklist that Hides YouTube Hate Videos from Advertisers—But It’s Full of Holes с методологией исследования. А в конце даются ссылки на практические статьи со схожей тематикой.

Может пригодиться интересный инструмент, который конвертирует curl-команду в запрос на самых разных языках программирования.

#skills

Backup: март

В этом месяце было много инструментов, баз данных, инфраструктуры и софт-скиллов. Питон тоже не забыт, вспоминали итераторы, FastAPI и именование переменных.

Работаем с проектом
Постигаем gRPC
Снова о микросервисах
Поиск недокументированных API

Софт-скиллы
Teamlead roadmap
Работаем с аудиторией на выступлении – TEDx

Базы данных
Следим за PostgreSQL
Проектируем БД в DB Designer
Где бы ещё сохранить данные? В Greenplum

Python
Итерируем всякое
Как ускорить приложение на FastAPI
Делай нейминг как сеньор

Инструменты
Доступность компа извне с помощью ngrok
Комментарии в маркдауне
Airflow или что-то ещё?

Нас тепло приняли на хабре со статьёй Реверс инжиниринг для самых маленьких на практике

Если пропустили, то подборка за февраль

#backup

Рисование схемок

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

Конечно, на первом месте классический draw.io – очень разухабистая рисовалка.

Много шаблонных блоков для рисования любых схем. Возможность совместной работы. И, пожалуй, самое главное преимущество – возможность интеграции во множество сервисов ведения документации. Например, в Confluence и Obsidian, которыми активно пользуемся.

Недавно коллега показал удобную фичу – работу со слоями. Когда нужно что-то сложное изобразить на одном рисунке в разных разрезах. Например, схему инфраструктуры одним слоем, прописанные DNS-записи вторым, серверные мощности третьим.

Или при рефакторинге архитектуры – наглядно изобразить было/стало, просто переключая слои.

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

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

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

#tools

Postgres – как хранить строки?

Если каждый раз при проектировании базы данных задаётесь вопросом, чем отличаются char, varchar или text и какой тип данных использовать для хранения строк, то эта заметка для вас.

Автор рассказывает о каждом типе данных, отмечает важные моменты:
– тип данных не влияет на производительность
– при ограничении длины текстового поля лучше использовать check constraint

В сухом остатке: используйте для хранения строк text.

#database

Межсервисное взаимодействие

Базовая практическая статья с примерами на python по организации взаимодействия между несколькими сервисами. 

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

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

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

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

А ещё на тему "не переусложнять" была отличная статья, где ребята адаптировали паттерн Сага под свои реалии.

Выбор брокера сообщений

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

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

— Поддерживаемые стандарты обмена сообщениями. Поддерживает ли брокер сообщений стандарт вроде AMQP или STOMP? Использует ли он свой закрытый протокол?

— Порядок следования сообщений. Сохраняет ли брокер порядок следования сообщений? Кстати неплохой вопрос на собеседовании: гарантирует ли Кафка упорядоченность сообщений и за счёт чего?

— Гарантии доставки. Какие гарантии доставки даёт брокер сообщений?

— Постоянное хранение. Сохраняются ли сообщения на диск? Могут ли они пережить сбой брокера?

— Устойчивость. Если потребитель переподключится к брокеру, получит ли он сообщения, отправленные, пока он был отключен?

— Масштабируемость. Насколько масштабируем брокер сообщений?

— Латентность. Каковы задержки при передачи информации?

— Конкурирующие потребители. Поддерживает ли брокер сообщений конкурирующих потребителей?

#skills

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

Хочется порекомендовать замечательный курс для небиологов от Стэнфордского университета Биология поведения человека, который ведет Роберт Сапольски. Курс аж на 27 лекций будет интересен увлекающимся подобной тематикой.

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

#fun

Асинхронность в браузере

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

Для людей, связанных с фронтендом, статья также будет полезна. Автор собирает многие знания воедино, рассказывает о некоторых экспериментальных функциях, а также даёт множество ссылок для более глубокого изучения. Нам показались интересными: Оптимизация производительности фронтенда и Визуализация промисов и Async/Await

Работа с json в PostgreSQL

Цикл супер-полезных практических заметок о работе с json в PostgreSQL.

Затрагиваются вопросы:
— чем json отличается от jsonb
— как парсить json. В том числе: извлечение поля из json-объекта, получение тип данных, проверка существования поля или значения
— как разложить json по колонкам
— как конвертировать в json. В том числе: перевод строки в json, создание json-объекта из наборов ключей и значений
— как индексировать json. В том числе: всю колонку или отдельно взятое поле
— как сделать красивый вывод json
— как изменять json. В том числе: конкатенация двух json, удаление определенных полей или null-значений

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

#database

Вариантность типов

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

Простой пример: тип Natural является подтипом Integer и Positive. И все трое одновременно являются подтипами Real. А тип Prime является подтипом всех вышеперечисленных.

Есть у нас функция, которая в качестве параметра принимает на вход определённый тип данных. А можем ли мы передать в качестве параметра подтип или надтип исходного типа данных? За это как раз отвечает вариантность типов.

Контравариантность, ковариантность, инвариантность — в статье все эти замечательные термины рассматриваются на конкретных понятных примерах.

Также прочтение статьи позволит более глубокого понять принцип подстановки Барбары Лисков (LSP), который фигурирует в известной аббревиатуре soLid.

В конце рассматривается реализация вариантности в различных языках программирования –TypeScript, C#, Java, C++.

А на тему вариантности в python у Диджи было замечательное видео.

#procode

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

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

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

Не только развлекательное, но и полезное: у нас в канале есть тег #резюме о подготовке к собеседованиям с личным опытом.

Было что-то запоминающееся в вашей практике?

VPN — не панацея

Цикл удачных статей на горячую тему обхода блокировок в сети.

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

Вторая статья рассказывает, что всё не так уж и плохо. Всё-таки есть технологии обхода блокировок, которые пока не детектируются (хотя наверняка в эту сторону идут активные исследования). Автор рассматривает такие технологии как: V2Ray, XRay, XTLS, Hysteria, Cloak. Статья больше теоретическая, но неплохо так расширяет кругозор.

А кому хочется потрогать, что было описано ранее и иметь запасной вариант выхода в мир, есть еще две чисто практические статьи: Обход блокировок: настройка сервера XRay для Shadowsocks-2022 и VLESS с XTLS, Websockets и фейковым веб-сайтом и Программы-клиенты для протоколов недетектируемого обхода блокировок сайтов: V2Ray/XRay, Clash, Sing-Box, и другие.

Порядок чтения не столь важен, можно начинать с любой заинтересовавшей.

#security

Три года DevFM

Мы создали этот канал 25 апреля 2020 года. Начинался он как инициатива двух друзей, которые делились контентом "для своих". Когда в десятый раз с кем-то поделился одним и тем же интересным материалом, возникло желание такой материал систематизировать и опубликовать. Первые посты не теряют актуальности:

– Как правильно постоянно ботать
– Паттерны проектирования
– Первое пятничное развлекательное – история xkcd
– Качественные публичные выступления для студентов
– О важности предсказуемости
– Не строй велосипед, переиспользуй
– Как изучать предметную область перед стартом проекта

А год назад мы основательно взялись за канал и с тех пор не сбавляем темп. Также иногда пишем видео для ютуба, например, Идеальный скрипт на bash и статьи для Пикабу, которые выходят за формат поста тут. Недавно мы вышли на Хабр со статьёй по реверсу, и набрали почти 50 плюсов и две сотни закладок.

В закреплённом посте у нас есть навигация по каналу с продуманной системой тегов.

В этом году мы планируем ещё больше и ещё круче. А вам спасибо за интерес, спасибо, что читаете. Хотелось бы узнать подробнее о вас. Чем вы занимаетесь и как долго? Два небольших опроса в следующих постах

#ToTheMoon

Ребята из SQL-чатика проводят онлайн-встречу 12 мая в 19.00. Темы:
– о работе
– как войти в айти
– софт скиллы
– технические вопросы
– о том, что спрашивают на собеседованиях

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

Ссылка в зум на встречу. Любые вопросы можно уточнить в чате.

Domain Driven Design

Domain Driven Design (DDD) – на первый взгляд, что-то такое сложное. Да и на второй тоже сложное. Не очень понятно, с чего начинать.

Начать можно со статьи Domain-driven design: рецепт для прагматика.

Автор на примерах проходится по основным концептам DDD:
– ubiquitous language – всё обсуждение происходит в терминах единого языка
– domain model – некий набор сущностей и сценариев, связанных с предметной областью
– bounded context – некие рамочки, в которых существует доменная модель и единый язык

Основная идея DDD – борьба со сложностью бизнес-процессов, их автоматизации и реализации в коде. Domain – предметная область и от неё нужно отталкиваться при проектировании и разработке.
Бороться со сложностью – звучит многообещающе, но "прежде чем начать бороться со сложностью с помощью Domain-Driven Design, нужно научиться бороться со сложностью самого Domain-Driven Design".

Не факт, что будете применять, но знать что это за зверь – стоит. К тому же, можно перенять некоторые полезные практики, например, ubiquitous languge – единый язык общения. На эту тему написан занимательный комментарий, что пример, приведённый в статье из мира продаж всем понятен, тривиален и нет смысла для него составлять ubiquitous languge. На что ему приводят такие термины из мира продаж: ретроскидка, скидка по фактуре, ценовое соглашение, отличное от базового и др. Кажется, не всем понятно. Это я к тому, что использование ubiquitous languge в любой области облегчит взаимодействие.

Можете посоветовать что-то толковое на тему DDD?

#skills

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

Хочется порекомендовать очень классный бесплатный курс на Coursera – Learning How to Learn. Название говорит само за себя. Курс имеет почти 90 тысяч рецензий с общим рейтингом 4.8.

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

Курс лёгкий для освоения, поэтому можно смотреть, не напрягаясь.

#fun #edu

Приоритизация технического долга

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

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

— Если мы ничего не будем предпринимать, усугубится ли проблема, или всё в целом останется на прежнем уровне, или вообще всё будет двигаться в сторону улучшения?

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

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

#procode