Как стать автором

Цифровая трансформация предприятий приводит к стремительному росту неструктурированных данных (документы, изображения, логи). Ручная обработка подобных данных повышает стоимость процессов и создаёт риски ошибок. Robotic Process Automation (RPA) снижает издержки и повышает воспроизводимость, однако классические решения ограничены жёстко зашитыми сценариями. Растущее разнообразие кейсов требует гибкой платформы, способной порождать новые обработчики «на лету» и масштабировать их под неравномерную нагрузку. Настоящая статья демонстрирует, как микросервисный MVP RPA_SOFT подтверждает технологическую реализуемость такого подхода и логически ведёт к динамической модели.

1. MVP RPA_SOFT как исходная точка

Постановка задачи. Требовалось создать сервис, принимающий CSV/JSON/PDF через REST-эндпоинт или веб-UI, автоматически распознающий структуру, выполняющий морфемный анализ и компоновку (пока через API YandexGPT), финализирующий результат и сохраняющий его в MongoDB, пользователю при этом отображается прогресс и ссылка на артефакты

Архитектура MVP. Прототип развёрнут на VM (Proxmox) и состоит из трёх ключевых микросервисов – Auth, DP, API Gateway – плюс веб-клиент. DP-service (Node 20 + Python 3.12) закрывает весь конвейер обработки, API Gateway служит единой точкой входа, Auth-service зарезервирован под грядущую MFA/JWT-логику, пока используются cookie-сессии на MongoStore (см. рис.1).

В статье рассматривается библиотека @qtpy/state-management-observable и её React-обёртка @qtpy/state-management-react, объединяющая реактивность, строгую типизацию и удобный API. Если вы ищете альтернативу Redux, Zustand или Valtio с поддержкой undo/redo, granular-подписок, middleware, асинхронных обновлений и прозрачной работы с массивами через Proxy — createObservableStore может стать хорошим выбором.

Всем привет! Меня зовут Игорь, и в свободное время я занимаюсь созданием игр.

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

Ссылка на игру

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

В данной статье будут рассмотрены: портрет руководителя Кирилла; цикл использование - подавление - слив сотрудника; результаты для Команды и Бизнеса; ключевые трансформации и мой личный опыт.

Портрет руководителя Кирилла

Кирилл – это обобщенный образ руководителя, препятствующего развитию нижестоящих сотрудников или не заинтересованный в развитии других граней личности сотрудника.

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

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

Приветствую читателя этой статьи. Я студент, учусь по направлению «Приборостроение», но большую часть времени занимаюсь программированием. Все таки это меня привлекает больше. Задумывался по поводу смены ОС на Arch Linux, но пока отложил эту затею в долгий ящик. Смотрел различные ролики на YouTube и заметил, что многие пользователи ставят себе Polybar, в котором можно легко настраивать информацию, выводимую на нечто похожее на Панель задач в Windows. Тогда я подумал «А почему бы не сделать такое в винде?!» и сразу начал гуглить что к чему. Попытался найти готовые аналоги, но ничего не впечатлило, поэтому решил написать свою программу на C++.

Vue 2 в 2025 году официально стал legacy, но множество проектов всё ещё работают на нём. Миграция на Vue 3 не всегда возможна сразу, поэтому важно правильно поддерживать и модернизировать старый код.

В этой статье разберём:

Устаревшие паттерны, от которых лучше избавиться.

Проверенные подходы, которые остаются актуальными.

Альтернативы из Vue 3, которые можно адаптировать уже сейчас

Реализация метода визуальной одометрии для оценки смещения и угла поворота камеры с использованием простого оборудования и OpenCV. Используется улучшенный трекинг оптического потока и «верёвочный» метод стабилизации движения.

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

Дело в том, что в университетах и на курсах аналитики обычно учат хард-скиллам: как группировать и анализировать данные, как строить отчёты и делать из них выводы. Но никто не учит вести переговоры с заказчиком, грамотно оценивать риски и учитывать другие детали, которые напрямую влияют на репутацию аналитика.

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

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

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

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

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

Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… 

У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning, включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. 

Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

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

В этой статье мы формулируем ключевой мотив внеземной экспансии и устанавливаем «дедлайн» — 450 лет до критического нарастания рисков. Чтобы оценивать такие масштабные проекты, нам нужны универсальные метрики — мы вводим три главных ресурса (массу, энергию и знания), измеряемые показателями nTQ, nEQ и HW. В следующих материалах этой серии мы обобщённо пройдём по этапам колонизации: от выбора места и архитектуры модулей до систем жизнеобеспечения и управления автономными базами; затем предложим дополнительные темы для углублённого разбора каждого шага.

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

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

Для начала давайте поймем, а зачем вообще нам нужна асинхронность и какие проблемы она решает?

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

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

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

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

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

Мне 13 лет, и это мой первый крупный проект.

Я хочу узнать мнение других людей о моем проекте.

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

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

Я студент первого набора бакалавриата Центрального Университета и мне есть что рассказать. Сейчас мало информации от самих студентов ВУЗа и я решил, что этот материал будет полезен абитуриентам.

Представьте: 1453 год, стены Константинополя.

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

Как в таких условиях принять единое решение?

Эта задача казалась чисто академической, когда в 1982 году ее впервые сформулировали в научном журнале. Тогда никто не мог предположить, что через несколько десятилетий ее решение станет основой революции, которая изменит представление о деньгах, доверии и власти.

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

Без понимания этой связи невозможно разобраться в работе любого современного блокчейна. Ведь в основе каждого из них лежит ответ на простой вопрос:

Как группе незнакомцев договориться о чем-то важном, не доверяя друг другу?