Анализ и проектирование систем *

Как быстро пролетели шесть месяцев! Продолжаю рассказывать о том, как решил сделать пет-проект: НормЦРМ. Сам я ремесленник-одиночка и пользовался ограниченным набором инструментов для ведения дел: Google Таблицы, да Windows-заметки. Решил все эти данные свести воедино в рамках собственной црмки.

Я не разработчик, а проектировщик интерфейсов (UX/UI-дизайнер). Опыта в программировании совсем немного. Поэтому пет-проект был мне особенно интересен. Я уже двадцать лет готовлю проектную документацию для других — а в этот раз для себя.

Сейчас расскажу, что сделал по проекту за последние полгода, как мне в этом помогли ChatGPT и Codex, как изменился процесс работы и почему это поначалу было скучно и грустно — а теперь с каждым днём жизни проекта всё интереснее и веселее.

При проектировании раздела ЭОМ часто возникает необходимость на однолинейных схемах отображать дополнительное оборудование, в частности: счетчики учета, вольтметры, амперметры, независимые расцепители и т.д. В nanoCAD BIM Электро присутствует такая возможность. В этой статье мы разберем, как добавлять дополнительное оборудование в однолинейные схемы.

На дворе шел 2016 год и из каждого утюга кричали, что русские хакеры помогли Трампу избраться, а моя маленькая (очень) команда, была привлечена к безнадёжному проекту,... правда мы поняли об этом потом.

Маленькая предыстория - в тот момент большой канадский гигант SIP телефонии решил выпустить первый телефон под Андроидом, но, не просто выпустить под AOSP, а так, что бы все гугловые сервисы были доступны. Это требовало пройти полное тестирование по GTS (Google Test Suite). Проект разрабатывался израильской командой канадского вендора и командой нашей компании, которая имела давние связи с канадцами.

Приём сертификационных заявок, на прохождение GTS заканчивался в начале ноября, а летом, хитрая израильская команда, предложила нашему архитектору, поменяться задачками - баш-на-баш. Архитектор проведя поверхностный анализ, не нашёл подвоха и... согласился,... как потом оказалось - зря, стоило анализ провести получше.

Первый "подход к снаряду" был ещё летом, но, что-то пошло не так, интеграция не задалась, и... задачу отложили на потом. Когда же на дворе стоял конец сентября, о ней вспомнили,... и вот тут - всех накрыло... и не зря - нужно было интегрировать WideVine...

Тогда подключили мою "команду спасателей" - меня и моего разработчика (Вовка, ты крут).

Задача на словах звучала просто (как всегда):

Kubernetes давно стал де-факто стандартом для оркестрации контейнеров. Его используют все – от крупных корпораций до мелких стартапов – и в ус не дуют. Потому что удобно: сервисы после падения поднимаются сами, трафик равномерно размазывается по репликам, деплой происходит в один клик, а масштабирование — по графику нагрузок, а не по звонкам в два часа ночи. Но это на бумаге. А вот на практике многие компании сталкиваются с тем, что за удобство приходится платить. Причем зачастую куда больше, чем рассчитывали первоначально. Бывали даже случаи, когда на кластер закладывали 200 тысяч рублей в месяц, а по факту отдавали 500-600. Естественно, работать в таких условиях нельзя. Поэтому надо разбираться, куда на самом деле уходят деньги и как сохранить их при себе.

Хабр, всем привет! С вами Лиза Акманова, ведущий аналитик ГК «Юзтех».

Представьте идеальный мир: аналитик пишет ясное техническое задание, разработчик его реализует и всё работает безупречно. Но когда в проекте появляется Kafka, эта идиллическая картина часто рассыпается. Почему? Потому что существуют технические нюансы, которые аналитик может не заметить, а разработчик не озвучить. Давайте вместе разберемся с этими “граблями” и научимся их обходить.

Привет! Это Данила Ляпин, наставник курса «Специалист по Data Science». Собрал подборку материалов по обработке естественного языка — она охватывает путь от базовых концепций NLP до трансформеров и BERT. Все материалы бесплатны и проверены на практике. Главное — двигаться последовательно, не пропускать основы и обязательно практиковаться на реальных задачах.

Привет, Хабр! Сегодня хочу поделиться историей о том, как желание автоматизировать рутинную работу привело меня к созданию собственного инструмента FullMute и, как следствие, к первым серьезным выплатам на платформах bug bounty.

Как многие начинающие исследователи, я начал с хаотичного ручного поиска уязвимостей: проверял заголовки, искал известные пути к админкам, пытался угадать версии CMS. Это было неэффективно, медленно и сильно зависело от везения. Мне нужен был «компас», который бы проводил первоначальную разведку за меня и давал четкие цели для атаки. Так родилась идея FullMute.

Будущее не приходит плавно. Оно не развивается по дорожным картам и не следует презентациям с KPI и отчётам Маккинзи.

Оно появляется в тот момент, когда инженер честно говорит:
«В рамках текущей логики это невозможно», и вдруг оказывается, что проблема не в физике, а в самой логике.

Эта статья не про гаджеты будущего, не про стартапы и не про «прорывные инновации». Она про метод мышления, который позволяет работать с технологиями там, где улучшать уже нечего.

Третья статья цикла о построении CDC-пайплайна с нуля. Сегодня — самое интересное: захватываем изменения из PostgreSQL и отправляем в Kafka. И разбираемся, почему WAL может съесть весь диск, даже если данные не меняются.

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

Аннотация: В работе предлагается 9-компонентная интегральная модель сознания, разрешающая «трудную проблему» через её реинтерпретацию. Вместо вопроса «как мозг порождает переживание?» модель постулирует, что субъективный опыт (квалиа) тождественен состоянию самореферентной, причинно-замкнутой информационной архитектуры, где «Наблюдающее Я» является операциональным ядром феноменальности. Сознание представлено не как эпифеномен, а как фундаментальный эволюционный адапт, возникший как аттрактор для повышения эффективности взаимодействия сложных организмов со средой. Модель описывает полный цикл от бессознательной обработки до коллективного творчества, вводя концепцию мира как «тела» коллективного разума.

В статье рассматривается что, зачем и как документировать в заказной и коммерческой разработке, чтобы спасти проект и нервы.

Разработчики видят в документации бюрократию, отвлекающую от настоящей работы. Заказчики и менеджеры — единственную гарантию, что получат то, что просили. Истина, как всегда, посередине. В условиях договорных обязательств документация — это не бумажка, а юридически значимый артефакт, такой же важный, как и сам код.

Давайте разберемся, как сделать ее союзником, а не врагом.

Всем привет! Меня зовут Иван Логинов, я аналитик данных в команде антифрода в Авито. Антифрод — направление на стыке бизнеса, продуктовых команд, пользователей и юридических ограничений, где любое решение требует тонкого баланса. В статье разберу требования к антифрод-системам и шаги, которые помогают удерживать баланс между безопасностью, ростом и требованиями законодательства. Текст будет полезен аналитикам, разработчикам, которые работают с подобными системами, а также тем, кто только подступается к таким задачам.

Всем привет! Меня зовут Николай и в течение последних лет у меня существовала идея-фикс создать свой стартап/продукт/SaaS, называйте как хотите, смысл от этого сильно не меняется.

И перепробовав (разумеется, неудачно) себя в различных доменах, я понял, что на старте нужно делать то, что получается лучше всего.

Именно так и пришла идея платформы для фаундеров стартапов, которая позволяла бы ускорять проектирование архитектуры запускаемых продуктов, в условиях, когда пользователь не обладает достаточными техническими навыками для того, чтобы самостоятельно создать прототип или доходчиво объяснить свое продуктовое видение нанятым разработчикам.

По статистике 9 из 10 IT-продуктов умирают ещё до релиза MVP.

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

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

И именно здесь родилась идея Rebreaker - как продуктового AI-архитектора, призванного ускорить реализацию прототипов IT-продуктов.

Далее будет описание работы сервиса.

Мне будет очень приятно получить любой фидбэк по работе сервиса. Стоимость токенов по платной подписке - пока что без наценки, исключительно себестоимость + ресурсы облачного хостинга. Если будут баги - заранее прошу прощения, пилил я SaaS в соло по вечерам/ночам после основной работы, что заняло около 4 месяцев.

Наши недавние публикации в блоге Цифрового СИБУРа вызвали оживленные дискуссии. Выяснилось, что ещё для очень многих людей слово «завод» ассоциируется с чем угодно, только не с цифровизацией. Большинство людей видят промышленность как картинку из старого советского фильма: трубы, цеха, большие агрегаты, мужики в форме бегают и что-то делают. Многие уверены, что там используют отсталый стек и вряд ли понимают потенциал ИИ.

Это давно не так, и современные заводы могут сильно удивить цифровизацией процессов, автономностью и минимизацией ручного труда. Для нас этот тезис сам собой разумеется, однако главное правило Хабра: тезис нуждается в доказательствах. И вот с этим есть сложность. Как-то так сложилось, что статей по теме Heavy Digital пока очень мало. Но мы попробуем изменить ситуацию.

С 30 января по 15 марта 2026-го мы открываем на Хабре сезон Heavy Digital — конкурс статей о цифровизации промышленности. Если у вас есть кейс, история из мира современных заводов, разбор решений или интересный научпоп о технологиях на производстве — самое время поделиться этим с читателями.

Всем привет! Меня зовут Дарья Андреева, я руковожу командой бэкенда Биллинга и B2B‑платформы Яндекс 360. Наша команда, чтобы сократить TTM и освободить разработчиков от рутины, создаёт удобные внутренние инструменты. Сегодня я хочу поделиться своим опытом и порассуждать о внутренних инструментах.

Начну с контекста. Яндекс 360 — это виртуальный офис для работы и личных дел, куда входят Диск, Почта, Календарь, Телемост, Мессенджер, Документы и другие сервисы. В течение четырёх лет команда растёт больше чем в два раза каждый год. Растёт нагрузка на сервисы, и вместе с ней бэклог. Поэтому автоматизация и ускорение процессов для нас вопрос выживания: без этого мы не смогли бы двигаться с той скоростью, которая нам нужна.

Эта статья — попытка собрать наш опыт, чтобы вы избежали наших грабель и могли быстро отвечать на главный вопрос: как реализовать тот или иной внутренний инструмент. Расскажу, какой критерий считается основным при выборе подхода к разработке внутренних инструментов, какой тип админок будет самым подходящим в той или иной ситуации и чем могут помочь готовые инструменты. 

Месяц работы за один вечер: сравнил Claude Opus 4.5 и китайский GLM-4.7 в vibe coding на задаче локального транскрайбера для NDA-встреч. Где критические баги, а где архитектурный идеал — и почему дорогой инструмент в 7 раз не всегда оправдан.

Амели собирает письмо из вырезанных кусочков — и получается послание, которое меняет чью-то жизнь. Примерно тем же занимается консультант, который платит $60 в месяц за три AI-подписки, хотя мог бы собрать рабочий стек из бесплатных инструментов.

Qwen Chat — Deep Research, Artifacts, генерация изображений. DeepSeek — reasoning уровня топовых платных моделей. Оба бесплатно. Perplexity Pro остаётся для работы с файлами клиента и верификации источников — но точечно.

В статье: карта «задача → инструмент», четыре кейса с промптами, разбор ограничений и рисков (включая отправку данных на серверы в Китае).

Экономия: $60 → $20 или $0. Если готовы, как Амели, поработать ножницами — результат не хуже оригинала.

Всем привет! Меня зовут Гриша Крюков, я аналитик в команде антифрода Авито. Расскажу, как использование пользователями нескольких профилей может приводить к неверным бизнес-решениям и почему качественное обнаружение связей между профилями напрямую влияет на качество А/В-тестов. Обсудим проблему на интуитивном уровне и строго математически докажем ряд утверждений, сопроводив симуляциями на синтетических данных. Статья будет интересна тем, кто увлекается аналитикой данных, А/В-тестами или просто любит математику.

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