Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— The hidden cost of PostgreSQL arrays Еще одна статья об устройстве постгреса. На этот раз, автор рассказывает о подводных камнях и принципах работы массивов в базе. Текст начинается с вопроса, когда использовать array, а когда нет (спойлер: когда не нужна связанность между данными в массиве, можно взять array, когда нужна — лучше вынести данные в таблицу). Далее начинается секция с семантикой, так массивы могут начинаться с любого значения, в частности, когда дело касается массивов произвольного размера. Также рассказывается о том, как задать фиксированный размер массивов и как их «резать». После рассказывается об индексации массивов, но присутствуют особенности с b-tree индексами. Плюсом, описываются особенности ANY функции. В конце упоминаются особенности изменений массивов, работу с большими данными, векторами и пакетом intarray. #pg ————————————— Model Once, Represent Everywhere: UDA at Netflix Стал чаще читать статьи, связанные с онтологиями. Поэтому сегодня статья от нетфликса, в которой рассказывается о том, как создание онтологии модели помогло в генерации API схем, пайплайнов и понимании системы. Текст начинается с проблемы: много сущностей в домене, много сервисов, где каждый под одной сущностью подразумевает что-то свое. По итогу появилась не консистентная терминология (тут можно привести аналогию с DDD), качество данных упало, сущности начали дублироваться и появились не явные связи. В качестве решения решили воспользоваться UDA (Unified Data Architecture), подход, который основан на моделировании домена с каталогизацией терминов и представлении этих моделей в виде нужных схем. Во второй половине текста показан пример, как описание данных превращается сначала в нужную схему, потом попадает в «repository of information» и так далее. А также рассказывается о первых впечатлениях подхода. #GraphQL #ontology #ddd ————————————— Startup Engineering Team Organisation Хоть стараюсь не касаться тем, связанных с менеджментом людей, тема организации команд кажется близкой. Связанно это с законом Конвея и тесной связанностью между организацией команд и организацией элементов технических систем. Автор статьи решил описать шесть способов разделения людей по ролям. Причем как с плюсами, так и с минусами такого разделения. Рассматриваются шесть вариантов деления команд: - По ролям. Команда бекендеров, фронтов и так далее. Плюсы: развитие отдельных людей, минусы — коммуникации между командами; - По сквадам (отделам). Берем направления бизнеса и в каждое помещаем фронта, бека, аналитика и так далее. Плюсы: ценность команды повышается, минусы — люди перестают развиваться, а тех долг накапливается; - По сhapters (community of practice). Берем матрицу «сквад Х роль», по которой раскидываем людей. Плюсы: меньше технических разногласий, минусы — возникают проблемы с планированием; - Выделение Dedicated Core Team. Возвращаемся к идеи сквадов, но добавляем «кор» команду, которая помогает. Тут, из-за ограниченности кор команды, возникают проблемы коммуникаций. - Выделяем One Shot Projects команды. Т.е. берем людей из сквада и кидаем их в 2-3 месячный проект. Тут возникают проблемы со сроками. - Выделение Staff Engineers + Chapter Work. Микс из сквадов с принципалами. Отдельно напомню о существовании Team Topology, который предлагает собственный подход в организации команд. #ppl_managment