Этот текст 2014 года стал одним из первых образцов содержательной критики микросервисной архитектуры. Хотя с тех пор отрасль нашла решения для многих технических проблем, поднятых автором, его основные предостережения не утратили актуальности и по-прежнему заслуживают серьезного внимания.
Эта заметка развернулась из комментария к статье: Таски есть, системы нет.
С моей точки зрения, заглавие разсматриваемой стати верно. Однако в содержании перечислены проблемы-следствия, без разкрытия ключевой затронутой проблемы.
В заметке я постараюсь выйти на эту ключевую проблему и затронуть вопросы вида:
Из чего такая система должна произрастать? Какие к ней требования? Есть ли примеры?
Каждый день на нефтегазохимических заводах СИБУРа работают тысячи единиц оборудования. Компрессоры, насосы, турбины — все они крутятся, нагреваются, изнашиваются. И рано или поздно ломаются.
Если выходит из строя ключевой агрегат, завод теряет миллионы рублей в день. Один простой может остановить весь цех, сдвинуть график отгрузок, повлиять на работу нескольких производств.
Раньше мы узнавали о проблемах так: загорается красная лампочка, срабатывает сигнализация, агрегат останавливается. Оператор видит на мониторе: температура подшипника 120 градусов — критично! Производство встает. Вызываем ремонтную бригаду, ищем запчасти, теряем время и деньги.
Что если узнавать о проблемах раньше? Не когда температура подшипника уже 120 градусов, а когда она поднялась с обычных 65 до 75? Тогда можно спланировать ремонт, заказать запчасти, остановить производство согласно плану.
Лучше потратить деньги на год разработки, чем терять гораздо больше на каждой поломке. Особенно если при этом снижается нагрузка на персонал, исчезает аврал, и работа становится предсказуемой.
Порой разработка нового продукта, автоматизация существующего процесса выглядит, как работа хирурга, который провел сложную операцию: в моменте избавил человека от серьезной проблемы, а то и вовсе спас жизнь. И на этом, как правило, история заканчивается. Однако после каждой операции есть еще одна очень важная стадия, о которой почему‑то не принято говорить — это реабилитация. И от того, как она пройдет, зависит работоспособность органов и качество жизни.
В IT‑разработке тоже есть такая стадия — это поддержка того, чем осчастливили заказчиков. Если ее упустить, то даже идеально проведенная «операция» может закончиться осложнениями. Поэтому для аналитика понимание этой стадии не менее важно, чем участие в создании нового продукта.
Всем привет! Меня зовут Роман, я руковожу разработкой. Когда‑то начинал разработчиком, потом тимлид, сейчас управляю лидами.
В моём багаже опыта — работа работа в интеграторе, потом в небольшой компании из сферы SMS‑маркетинга, череда позиций в in‑house разработке в разных отраслях. А сейчас я снова в айтишечке, в заказной разработке.
И вот что забавно: на протяжении всей карьеры меня преследует один и тот же вопрос — как правильно поставить задачу и как отследить реальное состояние разрабатываемой системы.
Казалось бы, инструментов хватает: Jira, YouTrack, Trello, GitLab, Confluence и ещё десятки. Но если копнуть глубже, становится понятно: каждый из них решает только кусочек головоломки. Целостной картины всё равно нет. Она появляется только в голове после погружения, но и тут засада — голов в проекте много, и у каждой своя картинка.
Получается парадокс: мы для других системы строим, а своей нормальной системы у нас всё так же нет. Думаю, многие коллеги узнают себя.
Я выделил пять основных проблем, которые должна решать такая система. Сразу скажу, что америку я не открыл. Хочу разобраться: чего же не хватает для организации разработки без головной боли по поводу тасок.
ИИ не заменяет бизнес-аналитика, при этом заменяет бизнес-аналитиков, которые не хотят или не могут адаптироваться. Он делает профессию сложнее, интереснее и стратегически важнее, вымывая из нее рутину.
Еще один инструмент для бизнес-аналитика (БА), как когда-то им были MS Visio или Jira. Это фундаментальный сдвиг, который меняет саму суть работы, ценность специалиста и структуру команд.
Привет! ИИ-агенты — главная горячая тема этого года, но все наверняка видели как их ради хайпа пытаются затащить куда угодно, совсем не глядя на эффективность и какой-либо здравый смысл.
В этой статье я расскажу о действительно полезном применении концепции агентов и попробую доказать, почему любой боксерский поединок является мультиагентной системой. И да, сходу со старта: это, конечно же, легкая и ироничная статья, к которой не нужно относиться серьезно — это чистый сарказм и попытка натянуть мультиагентную сову на мультиагентный боксерский глобус, а все приведенные аналогии между боксом и агентами — лишь художественный вымысел. ツ
Итак, поговорим про system design бокса, про reinforcement learning, адаптивные алгоритмы, всевозможный вызов tools типа джебов или клинча, очереди сообщений и гарантию их доставки, graceful degradation агентов и многое другое.
Мне нужно написать скрипт авторега аккаунтов для одного популярного сервиса. для регистрации аккаунтов нужна электронная почта.
Ранее я уже использовал для таких задач python-библиотеку tempmail, но она перестала работать.
Стол для программиста - это святое. От удобства стола зависит производительность труда программиста и, как следствие, качество результата всей работы.
Именно за столом на работе по сути и проходит вся трудовая жизнь.
В 2024 я купил себе в кабинет для работы стол с подъемной столешницей. Спустя год электроника подъёма внезапно перестала работать. Произошел полный отказ. Семи-сегментный индикатор стал показывать непонятный токен rE5. Кнопки перестали слушаться. Столешница застыла под потолком.
Я не знал, что мне делать. Пришлось разбираться, что же это такое за шайтан машина: электрический стол.
Одна из самых «ходовых» оптимизаций в вычислительной технике — это предусматривать для программы «быстрый» и «медленный» путь выполнения. В общем случае эта оптимизация работает. Техники оптимизации применяют на программном или аппаратном уровне. Цель — добиться, чтобы выполнение по быстрому пути было нормальным сценарием и шло «по умолчанию» — работаем быстро и очень эффективно. Выполнение по медленному пути предусматривается для необычных случаев, при исключениях, выбросах. Такой вариант работы выполняется в безопасном, но сравнительно медленном программном окружении, где можно позволить себе не спешить. На первый взгляд выглядит отлично, но, как оказывается, в реальности всё совсем иначе.
Практикующий инженер постепенно убеждается на собственном опыте, что дихотомия быстрый/медленный путь — это зачастую просто привлекательный мираж. Снова и снова мы видим, что попытка внедрить быстрый/медленный путь в реальной системе не даёт результата. Именно в этой области практика вступает в острое противоречие с теорией.
API — это не просто техническая прослойка. Это продукт. Его пользователи — другие разработчики. И, как у любого продукта, у него может быть ужасный или превосходный пользовательский опыт. Плохой API — это источник постоянной боли, багов и потраченного времени. Хороший API интуитивно понятен, предсказуем и прощает ошибки. Он становится продолжением мыслей разработчика.
На криптовалютном рынке цены очень хаотично движутся, прогнозы сбываются не каждый раз (особенно если вы полагаетесь на мнение инфлов), а новостной фон подливает масла в огонь. В этом хаосе многие пытаются найти хоть какие-то закономерности, опираясь не на догадки, а на измеримые данные.
Сегодня мы как раз и займемся таким анализом — разберем популярный в узких кругах индикатор Hash Ribbons. Но сделаем это не как трейдеры в поисках луд успеха, а разберем, что там под условно капотом. Итак, наша задача — взять экономическую гипотезу, посмотреть, как ее формализовали с помощью математики, и как в итоге она превратилась в код на Pine Script, который может запустить любой желающий.
Python щедро раздаёт нам удобные абстракции. Создаёшь список, словарь или строку — и не думаешь, где под это выделилась память и как она потом освободится. Но внутри интерпретатора работает довольно сложный механизм, и он устроен не так, как в C или других языках.
Идея сделать приложение-визуализатор пришла после чтения книги CPython Internals. Там подробно объясняется, как устроены арены, пулы и блоки. Но пока читаешь текст, всё это воспринимается слишком абстрактно. Захотелось увидеть механику своими глазами: как память выделяется, как освобождается и почему иногда остаётся занята. Так и появился MemoryMonitorApp, а вместе с ним — эта статья.
Создавайте приложения так, чтобы они могли работать без пользовательского интерфейса или базы данных. Это позволит запускать автоматизированные регрессионные тесты, продолжать работу при недоступности базы данных, а также связывать приложения друг с другом без какого-либо участия пользователя.
Всем привет, меня зовут Максим, я QA-специалист в компании SimbirSoft. Более двух лет я занимаюсь обеспечением качества, за это время мне часто попадались проекты с отсутствующей или устаревшей технической документацией. Как быть в подобной ситуации и при этом сохранить нервные клетки, я расскажу в этой статье.
Бывают ситуации, когда тестировать приходится вопреки. Вопреки срокам, здравому смыслу или отсутствию требований. Именно последний кейс мы и разберем с вами сегодня 🦾
Всем привет! Я Артём Седых, ведущий разработчик и тимлид проекта банковского сопровождения. Наш сервис — 8-летний монолит на PHP с командой из 39 человек. В цикле статей рассказываю об опыте разработки и внедрения альтернативы pinba: гибкого инструмента мониторинга, который позволяет увидеть живую систему как на ладони и понять, из‑за чего именно проседают определенные экшены. Сегодня, в третьей и заключительной части, рассмотрим мониторинг со стороны devops на дашбордах SLI/Apdex, поколдуем над статистическими методами для прогноза снижения производительности, поговорим об автоматических уведомлениях Grafana. Оценим перспективы развития, сравнительный анализ выбранного подхода и выводы по нашему опыту.
В этой статье мы рассмотрим 8 практических кейсов, основанных на реальных проблемах, с которыми сталкиваются администраторы систем хранения данных, и покажем, как модуль «СХД» DCImanager мог бы их решить. Каждый кейс демонстрирует конкретные возможности модуля и объясняет механизм решения проблемы.
Коллеги, привет! Я, Акманова Елизавета, ведущий аналитик ГК Юзтех, продолжаю делиться своим опытом в проекте, связанным с распиливанием монолита на микросервисы микрофронты. В первой части мы подробнее познакомились с данной концепцией и теперь понимаем ее сильные и слабые стороны. В текущей части посмотрим на алгоритм перехода от одной архитектуры к другой. Вперед!
В этом пошаговом руководстве вы узнаете о последних способах использования агентного ИИ и о том, как уже сегодня воспользоваться агентной оркестрацией с Camunda.
На протяжении многих лет моим главным хобби является игра в «Что?Где?Когда?». За зеркальным столом я капитан команды, а на работе — бизнес-аналитик. Но в последнее время эти роли размываются, потому что параллели между поведением команды за столом и во время обсуждения рабочих задач…как-то уж очень близки.
И однажды мне захотелось исследовать, как методы из игры работают в реальной жизни. Как оказалось, большинство моментов применимо.
