User
Это глава 20 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.
В предыдущей главе мы пришли вот к такому интерфейсу, позволяющему минимизировать коллизии при создании заказов:
В современных реалиях разработки программного обеспечения бывает достаточно трудно быстро и качественно написать техническую документацию к проекту, особенно когда данному процессу уделяется недостаточно времени по разным причинам: от временных ограничений, до индивидуальной непереносимости монотонного процесса участниками проектной группы, который, порой, может тормозить рабочие процессы.
Уже сейчас существуют инструменты, которые позволяют ускорить процесс документирования программного обеспечения. Эти инструменты значительно облегчают задачи разработчиков по ведению технической документации и внесению быстрых правок, что позволяет отражать в документации актуальные положения фактического поведения системы. В данной статье будет рассмотрен один из таких инструментов.
Основное внимание в статье будет уделено автоматизации процесса создания документации API сервисов, которые разрабатываются с помощью фреймворков Express.js и Gin, используя подходящий для этой задачи инструмент - Swagger.
Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.
Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!
Но помимо восхваления их здравого смысла, я думаю, что здесь есть более важный момент, который применим ко всей нашей отрасли...
Любой успешный проект начинается с ясного и понятного плана, который определяет направление работы и описывает подход к его реализации. Проработка проекта на ранних этапах с достаточным уровнем детализации экономит время во время разработки и позволяет успешно завершить проект в предсказанные сроки и бюджет. Именно для этой цели и созданы технические дизайн документы ("design doc" или "дизайн док"). Дизайн документы помогают разработчикам понимать основные требования к проекту, его архитектуру и функциональные возможности, а также процессы обеспечения безопасности и отказоустойчивости, масштабирования и эксплуатации.
Хороший технический документ может стать ключевым инструментом для общения и взаимодействия между разработчиками, менеджерами проекта и другими заинтересованными сторонами. Он помогает улучшить понимание целей проекта, улучшить качество продукта и сократить время, затраченное на разработку.
В этой статье мы рассмотрим, что такое дизайн документы, зачем они нужны и как их создавать с максимальной пользой для проекта.
Александр Ледовский, тимлид команды аналитики и DS в Авито, рассказал про опыт работы с Apache Spark и о том, как правильно задавать параметры Spark-сессии, чтобы получить ресурсы.
Если вы увлекались математикой в возрасте до 12 лет, то, наверное, встречались с криптарифмами - арифметическими ребусами.
Арифметические ребусы хороши для тренировки у младшеклассников навыков логического мышления и счета в столбик. Однако и нам с вами может быть интересно поискать ответ на общий вопрос - а как, всё таки, алгоритмизировать процесс решения ребуса?
Бэклог по-научному: как приоритезация помогла ЮMoney избавиться от хаоса в задачах
Привет, я Лена Чуркина, уже больше шести лет работаю проджект-менеджером в IT и на своём опыте успела пройти все стадии принятия бэклога. Настолько, что даже в жизни часто использую планирование и приоритезацию. Поэтому если количество горящих задач в вашей команде стало больше напоминать чёрную дыру, а последняя нервная клетка грозится выйти из чата, то эта статья для вас.
Меня зовут Алексей Мясников, я тимлид на проекте YDB в Яндекс Облаке. А ещё — старший ментор на курсе «Go-разработчик» в Яндекс Практикуме и кандидат технических наук. В коммерческой разработке более 15 лет, стек — C++, Java, Go, TypeScript, а пробовал около 20 языков программирования, в том числе в продакшн.
Эта статья про Go и микросервисную архитектуру написана на основе вебинара для Практикума.
Рассмотрим, как работает Jaeger, один из популярных инструментов, который помогает расследовать инциденты и находить узкие места в производительности в микросервисной архитектуре. Разберём, как правильно настроить трассировку и с какими проблемами можно столкнуться в процессе.
В своём прошлом посте я рассказал теорию своего подхода к декомпозиции систем на модули. Теперь пришло время проверить её на практике.
Кэмп - реальный проект, который стоил семизначную сумму для заказчика, выполнялся командой из 12 человек (включая двух бакэндеров) и сейчас запущен в промышленную эксплуатацию. Суммарно на выполнение проекта было затрачено 5500 человеко/часов, из которых 950 - на бакенд.
Чего от разработки ПО хотят разработчики, продакты и владельцы бизнеса?
Одного и того же - побольше дофаминчика (гормон счастья), поменьше кортизольчика (гормон стресса). Притом источники и дофамина, и кортизола у них одни и те же. Дофамин вырабатывается, когда фичи выпускаются в срок и без багов, а кортизол - когда сроки срываются и вылазят баги и регрессии. Бизнесу будет ближе финансовая версия — срыв сроков и баги очевидным образом приводят к увлечению стоимости разработки. Что приводит к выбросу кортизола уже у владельцев.
Меня зовут Вадим Опольский и я работаю data-инженером и участвую в проведении онлайн-тренингов. В статье есть ссылки на воркшопы, чтобы повторить практические вещи из Apache Flink, о которых я расскажу. А обсудим мы следующие проблемы:
➜ Неравномерный поток данных;
➜ Потери данных при передаче их из Kafka в storage;
➜ Масштабирование и скейлинг;
➜ Backpressure;
➜ Мелкие файлы на HDFS;
➜ Стриминговый процессинг.
Можно сказать, что я фанат мыслительных инструментов ТОС. Я не совсем одержима и не предлагаю использовать их по поводу и без. И всё же, мне кажется, даже просто наличие знания и понимания этих инструментов не может не изменить подход к анализу и принятию решений. Как я понимаю мыслительные процессы — это формализация мышления Голдратта. Того самого мышления, которое позволяло ему видеть ясно и чётко, игнорируя "так заведено".
Например, в проектном управлении был, и есть распространённый подход к планированию проекта — диаграмма Ганта. Всё больше команд отказывается от него в пользу гибких подходов. Частая причина отказа от жёсткого плана — в начале проекта мы не можем спланировать необходимый конечный результат. Голдратт тоже отказался от "Ганта", но по другой куда более распространённой причине.
В стандартном подходе есть понятие срока задачи. Сроки задач складываются в срок проекта. Для того чтобы успеть проект в срок, каждая задача должна быть выполнена в срок. Мы с вами знаем, что крайне мало проектов вокруг нас заканчивается в срок. Ну или в срок, но с превышением бюджета, или с урезанием содержания (спецификации) .
Можно было бы оправдать срывы сроков тем, что иногда мы ошибаемся при оценке, и ставим не реалистично маленький срок. Но тогда, мы должны были бы ожидать и обратную ситуацию. Часть (причём заметная) проектов должна была бы завершаться до окончания срока, но этого не происходит.
Наверняка вы вызывали методы в C#. И казалось бы, что тут может быть интересного. Но тут есть о чем поговорить, есть что интересного рассказать.
Позвольте рассказать вам сказку про то, как обычное использование методов может утопить ваше приложение в GC, а наивная реализация может быть на порядок менее эффективной и при этом не быть проще и понятнее, чем более грамотная реализация.
Со времени публикации первых фреймворков для проектирования архитектуры предприятия (например, TOGAF, FOAF, Archimate, Zachman Framework, MODAF, DoDAF, FEA, Gartner Enterprise Architecture Framework), а также попыток переноса архитектурных подходов управления жизненным циклом создания программного продукта на функционирование предприятия в целом (например, EUP) возникло устойчивое ощущение, что они не предлагают никакого конкретного решения, подходящего для любых предприятий, а следовательно не имеют особой ценности.
В действительности, конечно же, не существует двух одинаковых бизнесов и практически невозможно предложить универсальный подход к созданию успешной архитектуры процессов предприятия (тем более если оно интегрирует процессы разработки и сопровождения собственного программного обеспечения), но все же можно предложить достаточно удобную модель для рассмотрения всех значимых аспектов проектирования архитектуры предприятия с учетом их взаимосвязи и взаимного влияния. В этой статье мы рассмотрим основные подходы к реализацию целостного описания архитектуры предприятия на примере фреймворка IAF (Integrated Architecture Framework).
В разделе «Введение в Управление Потоком Задач» и затем в статье «Что такое задача?» и в дальнейшем везде я говорю и буду говорить, и более того буду доказывать, что именно задача, а не цель, является главной сущностью менеджмента.
Кто-то может возразить, что я ошибаюсь. Скажет, что главная сущность – это цель. И что цель и задача – это одно и то же. Вот даже величайший теоретик менеджмента Питер Ф. Друкер предложил метод «управление по целям» (Management by Objectives, MBO).
Я однозначно этому возражаю. Считаю, что это не так.
Более того, утверждаю, что в менеджменте как раз нужно сместить внимание с «целей» на «задачи» и тогда многое встанет на свои места. Обосновываю это в блоге.
Когда мы поймём, что у системы должна быть не цель, а задача. Что система создаётся не для достижения целей, а для выполнения задачи. Когда мы уясним, что задача – это частичка «труда», а труд – это выполнение задач. Когда разберёмся, что нужно управлять не процессами, а процессными задачами, не целями, а целевыми задачами. Когда выясним, что проект – это не задача, а лишь организационная форма рывкового выполнения отдельных целевых задач. Пазл сложится.
Выстроится стройная система управления потоком задач. Которая станет надсистемой для систем процессного управления, проектного управления и много другого.
Именно в осознании того, что «цель» и «задача» — это разные сущности, и лежит, по моему мнению, прорыв в теории менеджмента и более того в теории систем, в управлении сложностью.
В далёком 2004-м году, когда я начинал использовать в своей практике управление по задачам, я этого не осознавал. Думал, что управление по задачам – это лишь один из методов управления одной из сфер организации. Наравне с управлением проектами, процессами и т. д. Так его и применял в своей практике управления. До поры до времени.
Несколько недель назад в блоге «.NET Blog» появилась статья «Что такое .NET, и почему вы должны выбрать его?». В нем был представлен высокоуровневый обзор платформы, кратко описаны различные компоненты и архитектурные решения, а также обещаны более подробные посты по затронутым темам. Этот пост является первым таким продолжением, в котором подробно рассматривается история создания, архитектурные решения и детали реализации async/await в C# и .NET.
Предполагается, что имеется репозитарий (repository, хранилище данных) корпоративной архитектуры, например, в виде файла excel или источника, связанного по ODBC.
Задача: на основе данных из репозитария, содержащего объекты архитектуры предприятия (процессы, орг-структура, активы и т.п.), автоматически построить схему архитектуры: сгенерировать дерево на основе данных об иерархии объектов. Рассмотрен инструментарий excel и visio (сторонних add-in), приведена сопутствующая критика этих Microsoft-инструментов.
Генерация структурных схем штатным мастером Орг-диаграмм visio по данным excel (ODBC) аналогична табличному csv или скриптовым языкам dot, mermaid, plantUML в инструментах graphviz и drawio, а также rdf-триплетам (linked data), визуализируемым через RDF grapher. Генерация штатным мастером ограничена древовидными структурами, но использование visio VBA позволяет устранить ограничение древовидности, «Но это уже совсем другая история».
В предыдущей статье Простая Enterprise Architecture. Архитектура компании садоводов было рассказано про само понятие «корпоративная архитектура» (что такое Enterprise Architecture, ЕА) и объект архитектуривания (корпорация садоводов, СНТ).
В том примере нужно было вручную рисовать архитектурные схемы (структурные и VAD – цепочка добавленной стоимости) и далее связывать данные excel c фигурами visio в ручном (путем перетаскивания строк из поля «Внешние данные») или в автоматическом (автоматическое связывание по ID) режиме. В этой статье обойдемся без ручной работы: будет показан пример технологии автоматического построения иерархической схемы по данным, хранящимся в репозитарии - файле excel (аналогично автопостроение возможно из базы данных, иных источников ODBC).
