DevFM

Backup: апрель Архитектура проекта Межсервисное взаимодействие Выбор брокера сообщений DDD – Domain Driven Design О программировании Вариантность типов Приоритизация технического долга Асинхронность в браузере Базы данных Postgres – как хранить строки? Работа с json в PostgreSQL Инструменты Рисуем схемы VPN — не панацея Софтскиллы Биология поведения человека и лекция о депрессии Курс Learning How to Learn В этом месяце мы отметили три года. Если пропустили, то подборка за март. #backup

Пост о DDD зашёл хорошо. Но всё-таки с чего начать? Классические книги по этой теме могут не зайти с первого раза. Для погружения в тему и отслеживания, что происходит в мире DDD рекомендуем канал DDDevotion.

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

Пятничное развлекательное Хочется порекомендовать очень классный бесплатный курс на Coursera – Learning How to Learn. Название говорит само за себя. Курс имеет почти 90 тысяч рецензий с общим рейтингом 4.8. Пересматривал его дважды. Помогает структурировать в целом известные факты о постижении новой информации. Рассказывают о том, как работает мозг и различных техниках освоения нового. Также выступают ученые, занимающиеся исследованиями в этой области. Они рассказывают, почему оно работает именно так. Курс лёгкий для освоения, поэтому можно смотреть, не напрягаясь. #fun #edu

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

Ребята из SQL-чатика проводят онлайн-встречу 5 мая в 19:00. Темы: – о работе – как войти в айти – софт скиллы – технические вопросы – о том, что спрашивают на собеседованиях Вопросы, которые хочется обсудить можно оставить в гугл-форме. Ссылка в зум на встречу. Любые вопросы можно уточнить в чате.

Три года DevFM Мы создали этот канал 25 апреля 2020 года. Начинался он как инициатива двух друзей, которые делились контентом "для своих". Когда в десятый раз с кем-то поделился одним и тем же интересным материалом, возникло желание такой материал систематизировать и опубликовать. Первые посты не теряют актуальности: – Как правильно постоянно ботать – Паттерны проектирования – Первое пятничное развлекательное – история xkcd – Качественные публичные выступления для студентов – О важности предсказуемости – Не строй велосипед, переиспользуй – Как изучать предметную область перед стартом проекта А год назад мы основательно взялись за канал и с тех пор не сбавляем темп. Также иногда пишем видео для ютуба, например, Идеальный скрипт на bash и статьи для Пикабу, которые выходят за формат поста тут. Недавно мы вышли на Хабр со статьёй по реверсу, и набрали почти 50 плюсов и две сотни закладок. В закреплённом посте у нас есть навигация по каналу с продуманной системой тегов. В этом году мы планируем ещё больше и ещё круче. А вам спасибо за интерес, спасибо, что читаете. Хотелось бы узнать подробнее о вас. Чем вы занимаетесь и как долго? Два небольших опроса в следующих постах #ToTheMoon

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

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

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

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

Выбор брокера сообщений Для асинхронного взаимодействия сервисов используются брокеры сообщений. Читая книгу о микросервисах, нашел набор факторов, которые нужно учесть, выбирая брокер для той или иной задачи. — Поддерживаемые языки программирования. Пункт достаточно банальный, но лучше выбрать брокер с поддержкой широкого диапазона языков программирования. — Поддерживаемые стандарты обмена сообщениями. Поддерживает ли брокер сообщений стандарт вроде AMQP или STOMP? Использует ли он свой закрытый протокол? — Порядок следования сообщений. Сохраняет ли брокер порядок следования сообщений? Кстати неплохой вопрос на собеседовании: гарантирует ли Кафка упорядоченность сообщений и за счёт чего? — Гарантии доставки. Какие гарантии доставки даёт брокер сообщений? — Постоянное хранение. Сохраняются ли сообщения на диск? Могут ли они пережить сбой брокера? — Устойчивость. Если потребитель переподключится к брокеру, получит ли он сообщения, отправленные, пока он был отключен? — Масштабируемость. Насколько масштабируем брокер сообщений? — Латентность. Каковы задержки при передачи информации? — Конкурирующие потребители. Поддерживает ли брокер сообщений конкурирующих потребителей? #skills

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

Postgres – как хранить строки? Если каждый раз при проектировании базы данных задаётесь вопросом, чем отличаются char, varchar или text и какой тип данных использовать для хранения строк, то эта заметка для вас. Автор рассказывает о каждом типе данных, отмечает важные моменты: – тип данных не влияет на производительность – при ограничении длины текстового поля лучше использовать check constraint В сухом остатке: используйте для хранения строк text. #database

Как разработчику увеличить скорость работы и повысить качество продукта? Научитесь проектировать высоконагруженные системы как в Big Tech и менять существующие на курсе System Design. Всего за 4 недели вы научитесь собирать требования, оценивать нагрузку, выбирать подходящие СУБД, масштабировать системы и повышать их отзывчивость, а также создавать подсистемы для хранения данных, поиска и аналитики как своими силами, так и с помощью готовых продуктов. Вы научитесь дизайнить сервис такси, приложение для знакомств и любую высоконагруженных систем — всё под руководством Валерия Бабушкина, Vice President, Data Science в Blockchainꓸcom. Новый поток стартует 10 апреля! [Зарегистрироваться] #реклама

Рисование схемок А чем вы пользуетесь для рисования всякого? Частенько же возникает необходимость накидать схему взаимодействия сервисов, какой-нибудь алгоритм или полноценно нарисовать архитектуру. Конечно, на первом месте классический draw.io – очень разухабистая рисовалка. Много шаблонных блоков для рисования любых схем. Возможность совместной работы. И, пожалуй, самое главное преимущество – возможность интеграции во множество сервисов ведения документации. Например, в Confluence и Obsidian, которыми активно пользуемся. Недавно коллега показал удобную фичу – работу со слоями. Когда нужно что-то сложное изобразить на одном рисунке в разных разрезах. Например, схему инфраструктуры одним слоем, прописанные DNS-записи вторым, серверные мощности третьим. Или при рефакторинге архитектуры – наглядно изобразить было/стало, просто переключая слои. В draw.io порой напрягает слишком большое количество настроек, в которых можно запутаться и на которые совсем не хочется отвлекаться. Недавно открыл для себя Excalidraw. Очень приятный и понятный интерфейс, совместная работа, также наличие шаблонных элементов на все случаи жизни. А еще интересный стиль рисунков, как будто "от руки" добавляет особый шарм. Использую теперь, когда нужно что-то накидать, обсудить совместно с коллегами. #tools