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

Одна из самых «ходовых» оптимизаций в вычислительной технике — это предусматривать для программы «быстрый» и «медленный» путь выполнения. В общем случае эта оптимизация работает. Техники оптимизации применяют на программном или аппаратном уровне. Цель — добиться, чтобы выполнение по быстрому пути было нормальным сценарием и шло «по умолчанию» — работаем быстро и очень эффективно. Выполнение по медленному пути предусматривается для необычных случаев, при исключениях, выбросах. Такой вариант работы выполняется в безопасном, но сравнительно медленном программном окружении, где можно позволить себе не спешить. На первый взгляд выглядит отлично, но, как оказывается, в реальности всё совсем иначе.

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

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.

На протяжении многих лет моим главным хобби является игра в «Что?Где?Когда?». За зеркальным столом я капитан команды, а на работе — бизнес-аналитик. Но в последнее время эти роли размываются, потому что параллели между поведением команды за столом и во время обсуждения рабочих задач…как-то уж очень близки.

И однажды мне захотелось исследовать, как методы из игры работают в реальной жизни. Как оказалось, большинство моментов применимо.

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

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

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

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

Почему ChatGPT врет вам в лицо (и как OpenAI наконец объяснила, откуда берутся галлюцинации ИИ)

Статья по горячим следам сенсационного исследования OpenAI от 4 сентября 2025

Ваша модель только что выдала вам три разных неверных даты рождения одного человека. В десятом туре подсчета букв в слове "DEEPSEEK" она называет цифры от 2 до 7, хотя правильный ответ - 1. Знакомо?

Раньше мы думали: «Ну, технологии, что поделать, дообучат - и все наладится». Оказалось - нет. Галлюцинации - это не баг, а математическая неизбежность, заложенная в сам процесс обучения.

4 сентября OpenAI опубликовала революционное исследование "Why Language Models Hallucinate", которое переворачивает представление о главной головной боли современного ИИ. Впервые математически доказано: модели врут не из-за плохих данных или недоработок архитектуры. Они врут, потому что мы сами их этому учим.

В своей статье я разбираю это исследование без воды и объясняю простыми словами:

✅ Почему формула «ошибки генерации ≥ 2 × ошибки классификации» объясняет все галлюцинации
✅ Что такое singleton rate и почему 20% редких фактов = минимум 20% вранья
✅ Как система оценки превратила ИИ в вечных студентов на экзамене, где лучше соврать, чем признаться в незнании
✅ 4 конкретных способа от OpenAI, как сделать модели честными уже сегодня

Самое шокирующее: проблема решается не улучшением технологий, а изменением того, как мы спрашиваем и оцениваем ответы.

Компании, которые первыми внедрят принципы честности в свои ИИ-системы, получат главное конкурентное преимущество эпохи ИИ - доверие пользователей.

Готовы перестать быть жертвой красивой лжи и начать строить по-настоящему надежные ИИ-системы?

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

Мы в «Синтеке» решили посмотреть на эту проблему через BI-аналитику. Рассказываем, как данные помогают находить узкие места в закупках и почему без прозрачности здесь не обойтись.

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

Привет! Меня зовут Серёжа Синягин, я старший разработчик в Яндекс Еде и пишу на C++. В этой статье расскажу о задаче, с которой столкнулся в работе: как мы определяем, какие рестораны доступны пользователю для заказа. По пути заглянем во внутреннюю кухню, обсудим библиотеку H3 от Uber и разберём, как устроены R‑деревья и как мы используем их у себя.

Привет! Меня зовут Лена Назаренко, я ведущий системный аналитик в ecom.tech и ревьюер курса «Системный аналитик» в Практикуме. Я считаю, что техническое интервью — это важный этап приёма на работу, который кандидаты зачастую недооценивают и к которому недостаточно готовятся. Возможно, считают его формальностью, — в конце концов, по резюме ведь уже прошли отбор. 

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

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

Привет, Хабр! Писать статьи — дело приятное, но только если нет на плечах релиза. Релиз оказался марафоном на месяцы, где каждый день мы жили задачами и доработками. Мы делились на три фронта: кто-то закрывал критические баги («баг-фиксеры»), кто-то добивал бизнес-логику («бизнес-логеры»), а кто-то всерьез отрабатывал план «Б» — ставил свечи за успешный релиз («молитвенники за прод»). Играли мы на разных уровнях, но финальный босс у всех был один: система, которую мы героически толкали в ПРОД, как кота в переноску: и он не хочет, и нам страшно.

Но как бы там ни было, сегодня на ПРОДе живет большая система. Прям такая, что, если бы она была организмом, у нее были бы печень, почки и амбулаторная карта в Сфере Знания. 

Пользователи — сотни сотрудников. Система — новая, кнопки — непонятные, интерфейс — как квартира после переезда: ты вроде дома, но даже чайник включить страшно.

И вот представьте: в этой «квартире» все двери распахнуты настежь. Любой может зайти куда угодно, нажать любую кнопку, открыть любой экран. Кнопки, которые лучше не трогать, экраны, куда и разработчик-то без инструктажа не сунется… Получился цифровой «чулан Моники» — хаос, который мы срочно должны были привести в порядок. 

Решение было очевидным: нужна ролевая модель.

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

В своих размышлениях и прошлых попытках разработки ИИ, я добрался до сего дня llm - large language models. Однако этим моделям свойственны некоторые точности с контролем выходного результата, а именно почему получилось именно так.

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

Надеюсь специалисты из крупных компаний, средними бюджетами и возможностью оплатить работу десятка специалистов, прочитают, увидят разумное зерно и преисполняется.

Техническое задание (ТЗ) на проект, основанный на извлечении триплетов из текста, логическом выводе и масштабируемой обработке графа знаний с GPU-ускорением:

---

📘 Техническое задание: Система извлечения и логического анализа триплетов с GPU-ускорением

🔹 Цель проекта

Разработка гибридной экспертной системы, способной:

- Извлекать триплеты из неструктурированного текста с помощью LLM

- Хранить и обрабатывать триплеты в логической форме (Prolog)

- Масштабировать поиск и reasoning через кластеризацию и GPU-графовые вычисления

---

🔹 Архитектура системы

1. Модуль извлечения знаний

- Вход: текстовые данные (статьи, документы, диалоги)

- Выход: триплеты вида <субъект> — <предикат> — <объект>

- Инструменты: LLM с кастомным промптом, поддержка хотя бы одного языка. Перевод это техническая обвязка.

Каждый раз новый сотрудник приходит к вам с одними и теми же вопросами по Фигме? Или впервые видите макет в Фигме и не знаете, куда нажимать?

Мы посмотрим на Фигму глазами новичка и опытного дизайнера. Тем, кто только сталкивается с Фигмой, постараюсь помочь понять базовую логику работы с файлами, слоями, структурой и совместной работой. А продвинутые пользователи найдут здесь ответы на частые вопросы. Статья в первую очередь будет полезна аналитикам, тестировщикам и другим участникам процесса, которые работают с макетами.