Проектирование и рефакторинг *

Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts».

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

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

Второму разработчику не нравится модель push-уведомлений, и он предлагает решение на основе хореографии: когда ограниченные контексты создают события, Notifications должен подписаться на эти события и определять, когда отправлять уведомление.

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

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

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Как скрипты могут помочь при взаимодействии компонентов, типичных для IoT? С помощью языка Lua. Наш ведущий разработчик Леонид Садофьев рассказывает и показывает на примере своего демоприложения про использование Lua на проектах уровня бизнес-логики (BL). Его приложение разработано на С++ и применяется для умного дома, но может подойти и для приложений других типов. Всё важное под катом — передаём слово автору.

DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.

Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.

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

Чтобы всегда радовать пользователей, сервис Dropbox должен быть надежным и отзывчивым. С самого начала нам, как компании, приходилось масштабироваться. Сегодня нашими услугами пользуются более 700 миллионов зарегистрированных пользователей со всех уголков планеты. В общей сложности они ежесекундно генерируют минимум 300 тыс. запросов. Увы, системы, отлично подходившие для стартапа, перестали справляться с возросшей нагрузкой. Возникла насущная потребность разработать новую модель для внутренних систем и, конечно, придумать способ перехода на нее без риска угробить основной продукт в процессе.

В этой статье мы расскажем, как и почему разработали и развернули Atlas — платформу, реализующую основные преимущества сервис-ориентированной архитектуры (SOA) и при этом минимизирующую типичные издержки, связанные с владением сервисом.

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

Модульный монолит — это подход к проектированию приложений, который позволяет, с одной стороны, отложить во времени операционную сложность использования микросервисов, а с другой — избежать превращения монолитной системы в большой комок грязи. Сама идея модульности не нова и основана на давно известных принципах Separation of Concerns и Information Hiding. Но не так-то просто перейти от абстрактных принципов к пониманию, как их реально использовать на практике.

На Хабре не так много информации о модульных монолитах в целом и практически ничего о конкретных вариантах их реализации. Но об этом есть серия статей у Камиля Гржибека, автора проекта Modular Monolith with DDD. Сегодня поделюсь переводом первой из них.

Приветвую, не так давно вышла первая статья с общим описанием нашей самописной BI в Домклик. А сегодня хотелось бы подробнее поговорить про технический концепт этого инструмента. Если интересно, прошу под кат.

Мы продолжаем знакомить читателей нашего блога с интересными международными публикациями. Ранее мы перевели материал с практическими советами по обучению для ИТ-специалистов, сегодня же коснемся темы абстракций – популярного и эффективного средства разработки.

Под катом тех– и тимлид Йонас Тулструп, один из разработчиков датского сервиса MobilePay, демонстрирует, что отказ от излишних абстракций позволяет писать более чистый код. А именно: существенно уменьшать его сложность, повышать читабельность и удобство поддержки. Обсуждаемые подходы основаны на широко известных принципах KISS («Делай проще») и YAGNI («Вам это не понадобится»), и применимы к большинству видов разработки ПО.

Обращаем ваше внимание, что позиция автора не всегда может совпадать с мнением МойОфис.

Кадр из фильма «Формула любви», 1984

В жизненном цикле любого эксплуатируемого ПО наступает фаза, когда накопившийся набор изменений (CR) ложится неподъемным грузом на первичную архитектуру и вот тут наступает пора рефакторинга. Много книг понаписано на эту тему, есть специфика для различных языков. Ниже затронем только отдельные аспекты, которые могут оказаться полезным применительно к RStudio Shiny приложениям. Это ряд практических методов, трюков и нюансов, накопившихся при рефакторинге, как правило, чужого Shiny кода.

«Aliena nobis, nostra aliis» — Ежели один человек построил, другой завсегда разобрать сможет.

Это было в фильме, в первоисточнике несколько по-другому. Фраза Публилия Сира «Aliena nobis, nostra plus aliis placent» переводится как «Чужое нам, наше же в основном другим нравится».
Но кузнец Степан все равно дело говорит.

Является продолжением серии предыдущих публикаций.

В этой статье хочу поделиться некоторыми тезисами на тему создания чат-ботов и разработки подобных решений. Я работаю Python Software Engineer в Grid Dynamics. На статью меня, в том числе, натолкнуло участие во внутреннем проекте, который за полгода вырос, по сути, до мини-отдела по разработке ботов. Цель данного материала — посмотреть на чат-боты под другим углом: не как на разработку, которую может реализовать даже новичок в программировании, а как на функциональное и коммерчески выгодное решение. 

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

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

Представьте, что команда инженеров всю ночь перетаскивала в продакшен новую систему, запускала ее, утром сделала свои первые заказы и даже получила их. Они еще не знают, что случится через 10 минут, поэтому полны радости и надежд. Но потом приходит пользовательский трафик — и взрываются чаты и мониторинги…

Но давайте по порядку. Меня зовут Александр Клюшкин. Я работаю в Самокате и на нашем примере расскажу о сложностях перехода на новый стек. Зачем и кому это может понадобиться?

История об одном баге, который превратил переход с .NET Core 3.1 на .NET 6 в «приключение на 20 минут», самописной библиотеке Dodo.Primitives.Uuid, которая помогла этот баг починить, и размышления о бренности бытия важности своевременного рефакторинга и его приёмах.

Похоже, что двигатели постоянного тока (ДПТ) уходят в прошлое. При производстве современного оборудования с управлением и обратными связями все меньше используют этот тип исполнительных механизмов. Их удел теперь – это работа в игрушках с нерегулируемыми параметрами? В чем же причина? Что нужно, чтобы ДПТ, как дешёвое решение, вернулись в производство?

Меня зовут Саша Терентьев, я из команды ленты ВКонтакте. В этой статье поделюсь мыслями о проблемах кода, где используются enum и сопоставления типов. Часто встречаю такой код в проектах, ресурсах, примерах. Мы обсуждали это с коллегами на внутреннем событии, и из моего доклада выросла эта статья.

Букв будет много. Но, думаю, материал пригодится широкому кругу разработчиков — и не только iOS. Примеры основаны на псевдо-Swift и написаны по мотивам использования UIKit. Но могут пригодиться для работы с разными платформами и в любой области, где возникают сопоставления с образцом, приведения типов, переборы множеств типов.

Представьте себе ситуацию, большой маркетплейс, 60 тыс. посетителей в сутки (600 тыс. просмотров) и это только веб, а с мобильного приложения, плюс еще 100 тыс уникальных посетителей. С точки зрения HTTP API запросов к PHP бекенду - это порядка 13 млн. запросов (в пиковых нагрузках ~300-400 RPS). И это всё (PHP only) обрабатывает сервер с 8 vCPU (ядрами) и 32 Gb RAM и самое главное, что сервер практически не напрягается (см. КДПВ).

Сегодня я хочу рассказать про один не очень популярный но очень классный паттерн в написании React приложений - Compound components.

Что это вообще такое

Compound components это подход, в котором вы объединяете несколько компонентов одной общей сущностью и общим состоянием. Отдельно от этой сущности вы их использовать не можете, тк они являются единым целым. Это как в BEM нельзя использовать E - элемент, отдельно от B - блока.

Самый наглядный пример такого подхода, который знают все фронты - это select с его option в обычном HTML.

В данном цикле статей мы рассмотрим задачу синхронизации состояния react-приложения между окнами. В качестве подопытного у нас будет приложение на Electron, работающее в offline/online-режимах, которое также может запускаться в PWA-режиме.