Прототипирование *

Я решил попробовать себя на новом амплуа писателя и писать о том, что мне интересно и чем я занимаюсь. Я постараюсь делать меньше воды и не слишком длинные посты, так как длинные посты читаются тяжело. И первый пост будет о yask

С начала 2020-х начался бурный рост low-code/no-code платформ — технологий, не требующих при разработке написания программного кода. Она опирается на визуальные интерфейсы, конструкторы и готовые модули, которые собираются как конструктор из блоков. Цель платформы zero-apps — доступ к созданию цифровых решений, позволив бизнес-аналитикам, менеджерам проектов, маркетологам и специалистам по продукту воплощать идеи в работающие прототипы и полноценные web-приложения без глубокой технической подготовки на базе Яндекс Облака.

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

Я, скромный Product Owner с Земли (и по совместительству хранитель тайн самых разных карточек товара), подготовила для вас полный туториал по созданию карточки. Мы пройдём весь продуктовый цикл: от discovery (исследования, чтобы понять, чего жаждут земляне) до A/B-тестов и даже расчёта LTV для бессмертных клиентов.

Как влезть в одну из самых сложных тем для бизнеса — медицину — и не сдаться.

Будучи когда-то студентом-медиком, а затем действующим врачом-терапевтом, я усомнился в том, что мне действительно нравится работать с людьми. В какой-то момент мой внутренний интроверт взбунтовался. А, возможно, коктейль из гиперответственности, эмпатии и нежелания «создавать своё собственное кладбище» привёл меня в медицинскую науку...

Что если создать систему, которая работает как Trello, но специально заточенная под совместную работу с моделями искусственного интеллекта?

Это как Tesla с автопилотом — вроде бы всё автоматически, но иногда хочется взять управление в свои руки. А что если добавить к этому автопилоту "ручную коробку передач"?

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

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

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

Цифровая трансформация предприятий приводит к стремительному росту неструктурированных данных (документы, изображения, логи). Ручная обработка подобных данных повышает стоимость процессов и создаёт риски ошибок. 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).

Любой, кто хоть раз пытался спроектировать игру, знает про священную троицу вопросов: "Что?", "Как?" и "Зачем?". В теории всё просто: Сначала определяем цель (Зачем?), потом продумываем механики (Как?), а затем облекаем их в контент (Что?). Но это в идеальном мире. В реальности же, на поле боя, наш бедный вопрос "Зачем?" — это самый трусливый солдат. Он первый бежит с поля боя под натиском сирены по имени "крутая идея", под гипнозом конечной картинки в воображении команды, под давлением того самого внутреннего мечтателя, который заглушает голос разума. Добавьте сюда дедлайны, командную динамику или, наоборот, эхо-камеру одиночной разработки — и вот он, наш фундаментальный вопрос, уже пылится на самой дальней полке, рядом с первыми салфеточными-концептами.

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

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

— Ну что ж, понимаю. Тогда давайте попробую вам рассказать одну небольшую историю…

— Отличная работа, Егор! Я вам на почту правочки прислал по прототипу. Взгляните.

У меня от этой фразы что-то внутри ёкнуло. Захожу в почту, к письму прикреплён вордовский документ (на дворе 2009 год). Открываю… 55 комментариев. Пронумерованных. На четыре страницы.

Пробегаюсь по списку. Часть из них вносятся буквально за пять минут. А часть — перечёркивают мою двухнедельную работу.

Я откинулся в кресле, посмотрел в потолок. «Что не так с этим клиентом?». Нет, неправильный вопрос. «Что я делаю не так?». И, главное, как мне не оказываться в таких ситуациях в будущем?

Сегодня, спустя 15 лет, я знаю ответ на эти вопросы. И сейчас попробую уместить в одну статью почти всё необходимое для того, чтобы клиенты, начальники и коллеги принимали результат работы проектировщика (или дизайнера) с первого раза.

— Я не продаю часы, — ответил я.

— Ну хорошо, тогда что насчёт дней, недель, месяцев? Мне нужно хоть что-то, чтобы прикинуть потенциальные расходы.

— Я обычно оцениваю работу под ключ. Часовой ставки у меня нет.

— У всех есть такая ставка, хотят они того или нет.

— Что ж, здесь я вынужден согласиться. Но всё же хотелось бы для начала внимательно взглянуть на проект, от него многое будет зависеть, — попробовал я соскочить с темы.

Потенциальный клиент не стал дальше на меня давить. А уже потом я, засыпая поздним вечером и переваривая события дня, хлопал себя по лбу со словами: «Надо было просто ответить, что он застал меня подобным вопросом врасплох и что я готов ответить на него чуть позже!».

Почему же я сразу не назвал своей часовой ставки?

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

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

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

Делали ли вы работу в стол? Вопрос риторический…

Но больше, чем остальным это грустное чувство «проекта в стол» знакомо тем, кто занимается разработкой и внедрением ИИ решений: по статистике за 2024 год из них доходят до продакшена только от 15 до 30%

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

Наши партнеры из Яндекса на CTO Conf-2025 презентовали новый фреймворк — CRISP‑DM Light — он призван исправить эту ситуацию.

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

В предыдущих публикациях (Часть 1 и Часть 2) рассказывалось, как изготовить самодельный счётчик объектов, пересекающих единственный инфракрасный луч (барьер). В счётчике использовался механизм внешних прерываний микроконтроллера. Соответственно, скетч для Arduino выглядит крайне простым.

Теперь мне хочется чуть‑чуть пошалить и предложить вашему вниманию альтернативный вариант: странный инфракрасный счётчик с одним лучом. В нём не используются внешние прерывания. И скетч выглядит посложнее.

Зато он может определить, сколько времени объект провёл в инфракрасном луче.

21 мая в лабораторном корпусе РосНОУ на Авиамоторной прошёл пресс‑завтрак на тему «Реабилитация детей с ДЦП и другими нарушениями опорно‑двигательного аппарата».

Как отметила во вступительном слове первый проректор РосНОУ Елена Владиславовна Лобанова, количество детей с ДЦП в мире неуклонно растёт, и нашей цивилизации предстоит найти какое‑то решение этой глобальной проблемы, тем более что данное заболевание относится к неизлечимым. И тут на помощь должны прийти новые технологии, в частности, искусственный интеллект.

Разбираемся, как беспроводные технологии помогают сделать дом умным. Рассмотрим основные протоколы, когда и где следует применять — Zigbee, Z-Wave, BLE, Wi-Fi и Matter. Для тех, кто хочет понять, как устроен современный умный дом и определиться с подходящей технологией.

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

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

У меня это бывает часто. Вообще на проверку всех моих гипотез нужно минимум человека 3-4. И вот, они появились! Правда это 3-4 нейросети, ну ок, пойдет)

Сегодня каждому предоставляется такая возможность...

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