2135
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Нужен совет сообщества. У нас всё острее встаёт вопрос документирования сервисов. Конечно, у каждого сервиса есть свой сваггер, к методам написаны докстринги, в ридми есть описание работы сервиса и его архитектуры. Но всё это лежит в разных местах. Хочется красивенько и удобненько собрать всё вместе.
Из хотелок:
– для всего многообразия единый веб-интерфейс: архитектурные описания сервисов из readme, openapi спецификация, общее описание архитектуры из конфлюенса.
– было бы классно понимать пересечения http-ручек, когда в случае вызова одной по цепочке вызывается другая
Есть концептуальное понимание, что должно быть что-то, что периодически собирает всю информацию из разных источников, приводит к единому виду и строит статическую веб-страницу.
Расскажите, как решаете вопрос с документацией, что документируете? Какие технологии стоит использовать?
Пятничное развлекательное
Нашёл тут в своих давних заметках лёгкую, но полезную статью от Сергея Абдульманова. Статья небольшая, но даже сейчас помню своё ощущение после прочтения: ого, сколько интересностей!
Название статьи говорящее — Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло, но там не только об этом.
После прочтения вы наверняка не начнете проводить "офигенно длинные собрания", но точно почерпнёте набор того, что важно для полезной, качественной встречи. Мне очень понравилась мысль, что на встрече должно быть минимально достаточное количество людей для принятия решения. Чтобы не приходилось с ним бегать наверх для одобрения. Кстати, о том как этого добиться, есть отдельная статья.
В статье хорошо демонстрируется важность единой терминологии. По сути — один из аспектов DDD, о котором писали раньше. Простой термин, но как он может по-разному интерпретироваться. Например, "наличие". Для закупки «есть в наличии» — это хотя бы один товар в любом одном магазине в России. Для розницы — есть в большинстве магазинов хотя бы один товар. Для организации акций — есть хотя бы 5 штук в большинстве магазинов.
И ещё один вроде простой, но супер важный практический совет — никогда не нужно начинать сразу с решения. Всегда начинайте с проблемы. В статье этот тезис объясняется на двух запоминающихся примерах. Из опыта скажу, что легко скатиться сразу к обсуждению решения, не выяснив толком проблему. Поэтому с тех пор тщательно отслеживаю этот момент.
#edu
Как проектировать микросервисы
Нет универсального алгоритма, где сказано как проектировать микросервисы и правильно разделять зоны ответственности. Обычно этот навык нарабатывается с опытом и всё равно каждый раз думаешь, сомневаешься.
Когда только начинаешь смотреть в эту сторону хочется иметь хотя бы вектор. В статье автор даёт вполне адекватный алгоритм действия, который можно использовать при проектировании.
Важно, что в своих размышлениях автор старается учитывать изменчивость или неточность бизнес требований. Например, сразу неизвестно, какие способы авторизации будут нужны в будущем, или какой способ приёма платежей будет использоваться, кроме заявленного заказчиком на данный момент.
В целом, стоит критически смотреть на подобные статьи. Автор действительно даёт некий алгоритм, но опускает многие детали и вопросы, которые предстоит решать после такой декомпозиции. А именно в деталях обычно скрываются самые большие сложности и нежданчики.
И ещё небольшое примечание от нашей редакции. Когда что-то изучаете на тему микросервисной архитектуры, не цепляйтесь за "микро". Сервисы могут быть абсолютно разного размера в зависимости от конкретной задачи. Не нужно плодить сущности только потому, что в каноническом названии архитектуры есть приписка "микро".
#skills
Пятничное развлекательное
Не очень профильно, но очень полезно. Неоднократно бывало такое, что нужно выбрать лампочку, а какую конкретно непонятно. Вроде смотришь на всякие показатели, вроде даже что-то понятно, но что выбрать из сотни лампочек – хз.
Есть прекрасный проверенный ресурс для этих целей – lamptest. Ребята конкретно заморачиваются, проверяют множество показателей и даже ведут блог на хабре.
У них еще есть похожий проект batterytest, где они тестируют элементы питания.
UPD: оказывается и в тг есть канальчик.
#edu
Пагинируем по-всякому
Занимательная статья, посвящённая способам реализации пагинации.
Достаточно частая задача – отдавать что-то порционно. В зависимости от потребностей, нужно применять разные способы пагинации.
Помимо классического page-based pagination автор рассматривает KeySet-based pagination и Cursor-based pagination. Также рассматриваются плюсы и минусы каждого из способов.
В конце приводятся примеры, как реализована пагинация у больших ребят: Stripe, Shopify, Github.
#skills
Пятничное развлекательное
Настало время моего любимого фильма Город грехов (2005). Четыре новеллы с интересными переплетениями между собой. Каждый фрагмент захватывает своими персонажами, вызывая сопереживание.
Старик умирает... Девочка остается жить. Честный обмен
Фильм в жарне нуара, где во главе угла атмосфера пессимизма, недоверия, разочарования и цинизма. Мы говорили про игру Max Payne и фильм Бегущий по лезвию в этой стилистике.
Рекомендую к просмотру. Продолжение 2014 кода мне нравится куда меньше, но атмосферу фильм смог сохранить. Рад был видеть Кристофера Ллойда, хоть и в эпизоде. Кто не знает, это Док из трилогии Назад в будущее.
#films
Backup: апрель
Архитектура проекта
Межсервисное взаимодействие
Выбор брокера сообщений
DDD – Domain Driven Design
О программировании
Вариантность типов
Приоритизация технического долга
Асинхронность в браузере
Базы данных
Postgres – как хранить строки?
Работа с json в PostgreSQL
Инструменты
Рисуем схемы
VPN — не панацея
Софтскиллы
Биология поведения человека и лекция о депрессии
Курс Learning How to Learn
В этом месяце мы отметили три года. Если пропустили, то подборка за март.
#backup
Приоритизация технического долга
Технический долг штука хитрая, сначала незаметная. Но в какой-то момент начинает влиять на производительность системы и эффективность разработки.
И вроде всё просто — бери и исправляй. Но когда система разрастается, а бизнес требует новый функционал, появляются вопросики. За что хвататься? Всё явно не успеем, но забивать нельзя, потихоньку нужно закрывать долги.
В статье автор размышляет о приоритизации технического долга. На практике сводится к тому, что нужно ответить на два вопроса:
— Если мы ничего не будем предпринимать, усугубится ли проблема, или всё в целом останется на прежнем уровне, или вообще всё будет двигаться в сторону улучшения?
— Проблема относится к той части системы, которая активно развивается и используется или находится просто на обслуживании?
Ответив по каждой проблеме на эти вопросы, можно более осознанно приоритизировать свой технический долг.
#procode
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
Три года DevFM
Мы создали этот канал 25 апреля 2020 года. Начинался он как инициатива двух друзей, которые делились контентом "для своих". Когда в десятый раз с кем-то поделился одним и тем же интересным материалом, возникло желание такой материал систематизировать и опубликовать. Первые посты не теряют актуальности:
– Как правильно постоянно ботать
– Паттерны проектирования
– Первое пятничное развлекательное – история xkcd
– Качественные публичные выступления для студентов
– О важности предсказуемости
– Не строй велосипед, переиспользуй
– Как изучать предметную область перед стартом проекта
А год назад мы основательно взялись за канал и с тех пор не сбавляем темп. Также иногда пишем видео для ютуба, например, Идеальный скрипт на bash и статьи для Пикабу, которые выходят за формат поста тут. Недавно мы вышли на Хабр со статьёй по реверсу, и набрали почти 50 плюсов и две сотни закладок.
В закреплённом посте у нас есть навигация по каналу с продуманной системой тегов.
В этом году мы планируем ещё больше и ещё круче. А вам спасибо за интерес, спасибо, что читаете. Хотелось бы узнать подробнее о вас. Чем вы занимаетесь и как долго? Два небольших опроса в следующих постах
#ToTheMoon
Пятничное развлекательное
Столкнулся с удивительным случаем, который вызвал смех и удивление. Проводили собеседование. Заходим в зум, включаем камеры и тут включает камеру кандидат с мобильного. И что мы видим... Сидит чувак на улице, на лавочке, с сигой в зубах и готов проходить собес. Занавес.
Сама ситуация комична и вызывает смех, а удивление вызывает отношение к собеседованию. При этом кандидат слёзно заявлял, что очень хочет сменить текущую работу. Искренне не понимаю наличие желания и отсутствие реальных действий, чтобы это желание удовлетворить.
Не только развлекательное, но и полезное: у нас в канале есть тег #резюме о подготовке к собеседованиям с личным опытом.
Было что-то запоминающееся в вашей практике?
Работа с json в PostgreSQL
Цикл супер-полезных практических заметок о работе с json в PostgreSQL.
Затрагиваются вопросы:
— чем json отличается от jsonb
— как парсить json. В том числе: извлечение поля из json-объекта, получение тип данных, проверка существования поля или значения
— как разложить json по колонкам
— как конвертировать в json. В том числе: перевод строки в json, создание json-объекта из наборов ключей и значений
— как индексировать json. В том числе: всю колонку или отдельно взятое поле
— как сделать красивый вывод json
— как изменять json. В том числе: конкатенация двух json, удаление определенных полей или null-значений
Для более глубокого изучения того или иного вопроса автор даёт ссылки на документацию, другие статьи и SO.
#database
Пятничное развлекательное
Хочется порекомендовать замечательный курс для небиологов от Стэнфордского университета Биология поведения человека, который ведет Роберт Сапольски. Курс аж на 27 лекций будет интересен увлекающимся подобной тематикой.
И абсолютно всем рекомендую посмотреть лекцию курса, посвященную депрессии. Что наука говорит на эту тему. После просмотра, возможно, посмотрите на мир другими глазами. И порой человеку не помочь, просто дав отдохнуть и сказав подбадривающее "крепись".
#fun
Межсервисное взаимодействие
Базовая практическая статья с примерами на python по организации взаимодействия между несколькими сервисами.
Автор приводит три способа взаимодействия. Переходя от одного способа к другому, даёт небольшие вводные, почему имеет смысл усложнять.
– синхронный, с использованием http-запросов
– асинхронный, с внедрением брокера сообщений, но в некоторых местах все ещё остаются http-запросы
– усовершенствованный асинхронный, когда всё взаимодействие осуществляется через брокера
Мне кажется, важная мысль при чтении статьи – в первую очередь анализируйте требования. Не нужно накручивать сложные паттерны взаимодействия там, где это не обосновано. Просто потому что "ну вроде все так делают, на хайлоаде слышал".
Проектировать и закладывать гибкость имеет смысл ровно на обозримое будущее. Потому что лишняя сложность – это больше потенциальных мест для отказа и больше вероятность завязнуть с решением задачи. А самое забавное может случиться, когда новая бизнес-хотелка не уложится в ту самую заложенную гибкость. Вот тут то и начнётся натягивание совы на глобус.
Иногда бывает, что требований особо нет, никто их явно не предоставил. В этом случае важно очертить требования для себя и команды самостоятельно, и на их основании проектировать.
А ещё на тему "не переусложнять" была отличная статья, где ребята адаптировали паттерн Сага под свои реалии.
Рисование схемок
А чем вы пользуетесь для рисования всякого? Частенько же возникает необходимость накидать схему взаимодействия сервисов, какой-нибудь алгоритм или полноценно нарисовать архитектуру.
Конечно, на первом месте классический draw.io – очень разухабистая рисовалка.
Много шаблонных блоков для рисования любых схем. Возможность совместной работы. И, пожалуй, самое главное преимущество – возможность интеграции во множество сервисов ведения документации. Например, в Confluence и Obsidian, которыми активно пользуемся.
Недавно коллега показал удобную фичу – работу со слоями. Когда нужно что-то сложное изобразить на одном рисунке в разных разрезах. Например, схему инфраструктуры одним слоем, прописанные DNS-записи вторым, серверные мощности третьим.
Или при рефакторинге архитектуры – наглядно изобразить было/стало, просто переключая слои.
В draw.io порой напрягает слишком большое количество настроек, в которых можно запутаться и на которые совсем не хочется отвлекаться.
Недавно открыл для себя Excalidraw. Очень приятный и понятный интерфейс, совместная работа, также наличие шаблонных элементов на все случаи жизни.
А еще интересный стиль рисунков, как будто "от руки" добавляет особый шарм. Использую теперь, когда нужно что-то накидать, обсудить совместно с коллегами.
#tools
Попробуйте HTMX
Если у вас несложный фронтенд и не хочется погружаться в дебри развесистых фронтенд фреймворков – посмотрите на htmx. Очень интересная штуковина. Никакого javascript и сложной логики на фронте. Берем в руки html и вперёд.
Обзорная статья, где автор делится позитивным опытом использования htmx.
А тут можно посмотреть примеры использования htmx с вашим любимым языком программирования. Питонистам будет интересен вот такой свежий проектик.
Всё думал, где об этом написать. Но раз уж пост почти про фронтенд, то вот интересный материал, в котором собраны базовые правила по дизайну интерфейсов. На понятных примерах автор показывает, как делать правильно и почему именно так.
#skills #frontend
Кеширование на бекенде
Вводная статья, посвященная кешированию на бекенде, затрагивающая много интересных моментов.
Автор проходится по основным концептам:
– Для чего нужно кеширование, что нужно кешировать, по каким метрикам оценивать работу кеша
– Стратегии работы с кешем. Сквозное кеширование, когда все запросы проходят через кеш. Кеширование на стороне, когда само приложение координирует запросы в кеш или бд. Опережающее кеширование (только для чтения), когда приложение работает только с кешом, и кеш периодически синхронизируется с бд
– Всегда актуальный вопрос – стратегии инвалидации кеша. Jitter, чтобы не протухало всё разом. Схлопывание запросов в один, когда протухла запись, которую очень интенсивно используют
– Кеширование ошибок – полезный прием. Если знаем, что в бд нет определенных данных, так зачем каждый раз продолжать долбиться в бд. Можно закеширвать ошибку. Есть даже специальная схема атаки – cache miss attack
О кешировании у нас уже был пост Design distributed cache.
#skills
Как работает ChatGPT
Несколько лёгких статей, посвященных языковым моделям.
В первой ребята рассказывают историю языковых моделей, и как мы дошли от T9 до чатЖПТ.
Вторая статья посвящена исключительно GPT4. В чём отличия от предшественников, где применять на практике, как добавили работу с картинками. И ещё много всего интересного.
На фоне всех переживаний: абы чего плохого не вышло — третья статья, где размышляют и пытаются разобраться, стоит ли напрягаться и ожидать восстания машин.
Все статьи читаются на одном дыхании. Для особо любопытствующих в тексте много ссылок на другие исследования.
Ещё хочется поделиться одной статьей What Is ChatGPT Doing … and Why Does It Work? от Стивена Вольфрама. Более вдумчивое чтиво, с примерами и объяснениями, как оно устроено изнутри. Из приятного — все примеры можно позапускать.
О доступе к ChatGPT и наших примерах применения мы писали.
#skills
О производительности Postgres
Кто о чём, а мы о postgres. Небольшая, но полезная заметка о некоторых базовых настройках, которые помогут, когда дело дойдёт до исследования производительности базы.
– использовать расширение pg_stat_statements – такая штука, которая собирает полезную информацию о запросах к БД. Например, можно узнать, какие запросы самые долгие, какие в сумме по времени дольше всего выполнялись, какие выполнялись чаще всего
– логировать медленные запросы – можно настроить логирование запросов, которые выполнялись дольше заданного времени. В ту же сторону – логировать EXPLAIN-планы медленных запросов
– автоматически убивать запросы, которые очень долго выполняются
#database
Zero-Downtime Deployments with Docker Compose
У нас был пост, посвященный стратегиям деплоя приложений. Но во всех практических примерах использовался кубер. Для многих задач это стрельба из пушки по воробьям, и в комментах спрашивали, есть ли что-то подобное, только без использования кубера.
Нашли свеженькую статью, где автор реализует blue-green деплоймент без даунтайма с применением docker compose.
Из приятного – автор пользуется полюбившимся многим traefik вместо nginx. Также в процессе знакомства можно кое-что новое узнать о композе. Из не очень приятного – bash всё ещё активно применяется.
Всё описанное можно потрогать, исходники выложены на github.
#skills
Load balancing
Прочитал на одном дыхании замечательную статью о балансировке нагрузки (load balancing).
С увеличением нагрузки на приложение один сервер может уже не справляться. Тут-то и вступают в дело алгоритмы балансировки нагрузки.
По сути, оптимизировать можно два показателя: задержки при запросах и количество отклонённых сервером запросов.
Автор рассматривает:
– алгоритм round robin, когда запросы отправляются на сервера по кругу. Этот алгоритм не учитывает, что сервера могут иметь разную мощность. Тогда более мощные сервера будут быстро обрабатывать запросы, а менее мощные могут загибаться и давать отлупы.
– алгоритм dynamic weighted round robin учитывает мощность серверов. На основе среднего времени ответа им динамически устанавливаются веса. И, в зависимости от весов, будет автоматически варьироваться количество запросов.
– алгоритм least connection учитывает количество подключений, поддерживаемых серверами в текущий момент времени. Запрос будет передан серверу с наименьшим количеством активных подключений.
– алгоритм peak exponentially weighted moving average (PEWMA) направлен на уменьшение задержек в запросах. По сути, сочетает в себе dynamic weighted round robin, least connection и немного магии сверху.
Каждый из описанных алгоритмов сопровождается красивой и понятной анимацией. А в конце статьи можно поиграться с наглядным симулятором каждого из методов.
Помимо теоретических выкладок, автор проводит целое исследование, и смотрит, как в разных ситуациях ведёт себя каждый из алгоритмов.
Вас ожидают интересные выводы :)
#skills
Пост о DDD зашёл хорошо. Но всё-таки с чего начать? Классические книги по этой теме могут не зайти с первого раза. Для погружения в тему и отслеживания, что происходит в мире DDD рекомендуем канал DDDevotion.
Читать полностью…
Пятничное развлекательное
Хочется порекомендовать очень классный бесплатный курс на Coursera – Learning How to Learn. Название говорит само за себя. Курс имеет почти 90 тысяч рецензий с общим рейтингом 4.8.
Пересматривал его дважды. Помогает структурировать в целом известные факты о постижении новой информации. Рассказывают о том, как работает мозг и различных техниках освоения нового. Также выступают ученые, занимающиеся исследованиями в этой области. Они рассказывают, почему оно работает именно так.
Курс лёгкий для освоения, поэтому можно смотреть, не напрягаясь.
#fun #edu
Ребята из SQL-чатика проводят онлайн-встречу 12 мая в 19.00. Темы:
– о работе
– как войти в айти
– софт скиллы
– технические вопросы
– о том, что спрашивают на собеседованиях
Вопросы, которые хочется обсудить можно оставить в гугл-форме.
Ссылка в зум на встречу. Любые вопросы можно уточнить в чате.
VPN — не панацея
Цикл удачных статей на горячую тему обхода блокировок в сети.
В первой статье автор рассказывает о том, как можно выявлять попытки обхода блокировок. Если у вас настроен VPN или прокси, не стоит расслабляться – их можно выявить и заблокировать. В статье автор приводит подобные примеры из реальной жизни.
Вторая статья рассказывает, что всё не так уж и плохо. Всё-таки есть технологии обхода блокировок, которые пока не детектируются (хотя наверняка в эту сторону идут активные исследования). Автор рассматривает такие технологии как: V2Ray, XRay, XTLS, Hysteria, Cloak. Статья больше теоретическая, но неплохо так расширяет кругозор.
А кому хочется потрогать, что было описано ранее и иметь запасной вариант выхода в мир, есть еще две чисто практические статьи: Обход блокировок: настройка сервера XRay для Shadowsocks-2022 и VLESS с XTLS, Websockets и фейковым веб-сайтом и Программы-клиенты для протоколов недетектируемого обхода блокировок сайтов: V2Ray/XRay, Clash, Sing-Box, и другие.
Порядок чтения не столь важен, можно начинать с любой заинтересовавшей.
#security
Вариантность типов
Интересная тема из теории программирования. В языках программирования существуют типы данных, и они могут образовывать сложную иерархию.
Простой пример: тип Natural является подтипом Integer и Positive. И все трое одновременно являются подтипами Real. А тип Prime является подтипом всех вышеперечисленных.
Есть у нас функция, которая в качестве параметра принимает на вход определённый тип данных. А можем ли мы передать в качестве параметра подтип или надтип исходного типа данных? За это как раз отвечает вариантность типов.
Контравариантность, ковариантность, инвариантность — в статье все эти замечательные термины рассматриваются на конкретных понятных примерах.
Также прочтение статьи позволит более глубокого понять принцип подстановки Барбары Лисков (LSP), который фигурирует в известной аббревиатуре soLid.
В конце рассматривается реализация вариантности в различных языках программирования –TypeScript, C#, Java, C++.
А на тему вариантности в python у Диджи было замечательное видео.
#procode
Асинхронность в браузере
Классная обширная статья на тему асинхронности в браузере. Даже если далеки от мира фронтенда, рекомендуем к прочтению, чтобы представлять как у них там все устроено. Автор рассказывает о циклах событий, об очередях задач (оказывается, их несколько), функциях обратного вызова, промисах и корутинах. Всё повествование сопровождается наглядными иллюстрациями и кодом.
Для людей, связанных с фронтендом, статья также будет полезна. Автор собирает многие знания воедино, рассказывает о некоторых экспериментальных функциях, а также даёт множество ссылок для более глубокого изучения. Нам показались интересными: Оптимизация производительности фронтенда и Визуализация промисов и Async/Await
Выбор брокера сообщений
Для асинхронного взаимодействия сервисов используются брокеры сообщений. Читая книгу о микросервисах, нашел набор факторов, которые нужно учесть, выбирая брокер для той или иной задачи.
— Поддерживаемые языки программирования. Пункт достаточно банальный, но лучше выбрать брокер с поддержкой широкого диапазона языков программирования.
— Поддерживаемые стандарты обмена сообщениями. Поддерживает ли брокер сообщений стандарт вроде AMQP или STOMP? Использует ли он свой закрытый протокол?
— Порядок следования сообщений. Сохраняет ли брокер порядок следования сообщений? Кстати неплохой вопрос на собеседовании: гарантирует ли Кафка упорядоченность сообщений и за счёт чего?
— Гарантии доставки. Какие гарантии доставки даёт брокер сообщений?
— Постоянное хранение. Сохраняются ли сообщения на диск? Могут ли они пережить сбой брокера?
— Устойчивость. Если потребитель переподключится к брокеру, получит ли он сообщения, отправленные, пока он был отключен?
— Масштабируемость. Насколько масштабируем брокер сообщений?
— Латентность. Каковы задержки при передачи информации?
— Конкурирующие потребители. Поддерживает ли брокер сообщений конкурирующих потребителей?
#skills
Postgres – как хранить строки?
Если каждый раз при проектировании базы данных задаётесь вопросом, чем отличаются char, varchar или text и какой тип данных использовать для хранения строк, то эта заметка для вас.
Автор рассказывает о каждом типе данных, отмечает важные моменты:
– тип данных не влияет на производительность
– при ограничении длины текстового поля лучше использовать check constraint
В сухом остатке: используйте для хранения строк text.
#database
Backup: март
В этом месяце было много инструментов, баз данных, инфраструктуры и софт-скиллов. Питон тоже не забыт, вспоминали итераторы, FastAPI и именование переменных.
Работаем с проектом
Постигаем gRPC
Снова о микросервисах
Поиск недокументированных API
Софт-скиллы
Teamlead roadmap
Работаем с аудиторией на выступлении – TEDx
Базы данных
Следим за PostgreSQL
Проектируем БД в DB Designer
Где бы ещё сохранить данные? В Greenplum
Python
Итерируем всякое
Как ускорить приложение на FastAPI
Делай нейминг как сеньор
Инструменты
Доступность компа извне с помощью ngrok
Комментарии в маркдауне
Airflow или что-то ещё?
Нас тепло приняли на хабре со статьёй Реверс инжиниринг для самых маленьких на практике
Если пропустили, то подборка за февраль
#backup