Разработка систем электронной коммерции
Продолжение серии «Автоматизация для новичков на примере малых предприятий»
В прошлой главе я спас «Непревзойдённую шаверму» от биологической опасности порождённой недочётом в WMS. Мы внедрили учёт партий, разобрались, почему FIFO — это не только про модемы, а FEFO лучше съесть пораньше...
Сегодня же мы поговорим о маржинальности и других важных терминах, знание которых спасёт вас от убытка в первый же год.
В Казахстане продажа через Telegram часто выглядит так: «переведите на Kaspi», скриншот, ручной поиск платежа в приложении. Медленно, не работает ночью и ломается о поддельные чеки.
Разбираем бота на Python (aiogram 3), который сам выставляет QR Kaspi Pay, узнаёт об оплате за секунды и выдаёт товар. По шагам — всё, на чём такие интеграции обычно ломаются: подпись вебхука по сырому телу, повторные доставки, Idempotency-Key, истёкший QR, «тихая» смерть сессии Kaspi и сверка по таймеру, если вебхук потерялся. В конце — схема хранения в Postgres и полный код.
На днях я выложил статью про DevRaid — платформу, где разработчик подтверждает свой опыт через реальные проверки кода. Docker, тесты, ESLint, безопасность, AI-ревью. Вместо резюме — публичный профиль с подтверждёнными навыками.
Результат был скромный: 7300 просмотров, 333 захода на сайт, 16 регистраций, 0 пройденных квестов.
Я полез в логи и увидел ноль строк verify.start. Люди регистрировались и уходили, не начав проверку. Единственный квест тогда был «Создать интернет-магазин» — 9 фаз, Docker-сборка на 3–4 минуты, нужен свой публичный репозиторий. Человек с холодным трафиком не готов столько ждать ради любопытства.
Тогда я переделал воронку так, чтобы первый результат был за 30 секунд. Ниже — как это устроено сейчас.
Все ноды зелёные, Meta отдала 200 OK, а клиентка осталась без ответа. Разбираем баг ИИ-агента на n8n
Часть моей работы — помогать джунам разбираться с архитектурными решениями.
Иногда у нас возникают обсуждения на тему: «Зачем заморачиваться с WebFlux, если можно продолжать писать на Spring MVC?». Чтобы предметно обсуждать эту тему, мы с командой провели внутренний бенчмарк, написали методичку и решили поделиться некоторыми соображениями в этом цикле статей.
В этой — первой — статье я расскажу, как устроены три основные модели обработки запросов в Java, покажу их сильные и слабые стороны и дам критерии, которые помогут выбрать подходящий вариант для вашего проекта.
Дисклеймер: для Java-сеньоров в этой статье скорее всего ничего нового не будет.
Архитектурный и OPSEC-разбор для CTO, CISO, системных инженеров и разработчиков распределённых систем.
В SLA облачных провайдеров привычно фигурируют высокие показатели доступности, а продуктовая документация годами продвигает мультизональность (Multi-AZ) как серебряную пулю. Но в октябре 2026 года математические модели отказоустойчивости столкнулись с суровой физической реальностью: череда инцидентов на опорных площадках в сочетании с сетевым сбоем показала, где именно заканчиваются возможности автоматического восстановления.
События 8–11 октября 2026 года — бесценный материал для инженерного аудита. Без эмоций, конспирологии и политики разберём: что подтверждено официальными данными, почему Multi-AZ упирается в физический потолок свободных мощностей (Capacity Exhaustion) и как пересобрать архитектуру сервисов и данных, чтобы авария внешнего провайдера не ставила бизнес на паузу.
Продолжение серии «Автоматизация для новичков на примере малых предприятий».
В прошлой главе я уже продал Азизу CRM и разъяснил вам основные термины интеграторов ERP простым языком обывателя. Настало время вновь заглянуть в Непревзойдённую шаверму и познать чем же так важны Фефа и Фифа в пищевом бизнесе.
Все вокруг кричат про тотальную цифровую трансформацию, маркировку и ЭДО. Наш ресторан купил красивое готовое решение для импорта документов/поставок, из ЕГАИС в StoreHouse, и импорт документов/поставок из ЭДО в StoreHouse, и другое.
Круто? Да, но только на бумаге.
Крупные федеральные поставщики присылают документы в ЭДО или ЕГАИС, каждый день. Эти документы спокойно импортируются в StoreHouse. А вот мелкие локальные контрагенты (крафтовые производители зелени, сыроварни, поставщики свежего мяса) до сих пор живут в прошлом веке. Им ЭДО не обязателен. Максимум, на что они способны — забить накладную в свой Excel и скинуть менеджеру в Telegram, самый плохой вариант — это мягкие накладные, написанные непонятным почерком.
Итог: каждый день бухгалтер‑калькулятор вынужден руками вбивать по 100–300 строк в StoreHouse.
Привет, Хабр!
Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.
Частая ситуация у клиента: сайт работает, заявки идут, реклама крутится — а потом приходит письмо от РКН или ФАС. Грешат на подрядчика. Но обычно дело в том, что законы для сайта пришли после его запуска.
Разберем, какие требования действуют в 2027 году, за что уже штрафуют и с чего начать проверку.
Где заканчивается парсинг и начинается решение
Предыстория: около месяца назад подробно обсуждал архитектуру этого проекта в личке с хабровчанкой (не имею права раскрывать ник). Она набросала мощные хардкорные идеи: прикрутить предохранитель на объем выдачи, внедрить счетчик пропусков missed_runs для отсечения ложных удалений и использовать сессии Telethon. До реализации её паттернов руки всё никак не доходили (да и заказчик активно пользовался проектом). Момент настал, а вчера OpenAI выкатила GPT-6 Luna Decisions с её Decisions API. И тут мне в голову пришла альтернативная мысль, о которой эта статья. Мне крайне интересно мнение со стороны касательно изменения проекта.
В мониторинге объявлений, сбор данных - только половина задачи. Можно регулярно забирать выдачу, сравнивать цены и присылать сводку. Но затем возникает другой вопрос: о каком изменении стоит сообщить отдельно, а какое можно оставить в журнале?
Мне интересна именно эта граница. В схеме на n8n изменения находит обычный код, а текстовая модель составляет отчёт. Пока человек читает весь отчёт, это удобное разделение. Если хочется отправлять отдельные уведомления, оценку из текста уже нужно переделать в машинное решение.
В описании Luna Decisions на OpenRouter меня заинтересовал подход: модель возвращает типизированные оценки, а приложение само выбирает действие. Не «напиши, насколько это интересно», а отдельный результат, который можно проверить, сохранить и сравнить с порогом.
Но из этого ещё не следует, что такой API нужен в моём случае. Ниже разберу, куда его можно встроить, чего не хватает во входных данных и с чем я бы сравнивал результат. Возможно, после сравнения окажется, что достаточно нескольких условий в Code-ноде. Это тоже полезный исход.
Документ провёлся. Ошибок в коде нет. Тест зелёный.
Открываю оборотно-сальдовую ведомость по 19-му счёту — и вижу, что часть НДС оказалась на 91-м. С точки зрения программы операция завершилась успешно. С точки зрения бухгалтера учёт уже разъехался.
Всем привет! Меня зовут Ольга Сумерина, я старший инженер по тестированию 1С в Ozon. Три года до этого я работала бухгалтером: считала амортизацию, контролировала расчёты с поставщиками, закрывала период.
В этой статье я расскажу о своём пути, о навыках и инструментах, необходимых тестировщику 1С, и про баги, которые было бы сложно заметить без бухгалтерского опыта. Разберу причины, покажу, где их искать, а в конце соберу из них чек-лист. Думаю, материал будет в первую очередь полезен тестировщикам и разработчикам 1С без бухгалтерского бэкграунда.
В прошлой статье я рассказывал, как устроено ядро нашего поиска: триграммы, crc32, словарь болей и два сита. В конце был короткий раздел «А где же нейросеть?», и он заслуживает отдельного разговора. Сегодня про то, как модель встроена сверху и почему мы с самого начала исходили из того, что она когда-нибудь подведёт.
Коротко о контексте. Мы делаем поиск для сайтов, которому человек пишет своими словами: «нужно вырыть траншею под кабель на даче», «подарок папе, он рыбачит». Без модели поиск работает на словаре и векторах. С моделью он начинает понимать, чего человек хочет, задаёт уточняющий вопрос и объясняет, почему предложил именно этот вариант.
/
Мы уже научились писать код с помощью AI. Но гораздо интереснее другое - как именно мы встроили AI разработку в свою работу. Я попробовал вспомнить все свои наблюдения и составил небольшую небольшую классификацию - от Воина до Некроманта. Надеюсь этот опрос вас немного порадует.
Заказ на сайте оформлен за минуту. В 1С он появляется вечером — когда менеджер или бухгалтер откроет админку, найдёт новые заказы и перенесёт их руками: покупатель, телефон, позиции, цены, скидка, доставка. Если заказов десять в день, это терпимо. Если сорок — это уже отдельная работа, у которой нет строки в бюджете, зато есть ошибки и задержка.
Я проектирую интеграции 1С с внешними системами: сайтами, CRM, своими программами заказчиков. Ниже — как я бы устроил загрузку заказов с сайта в 1С, если сайт сделан на Tilda, InSales или написан с нуля.
Покупатель пишет в чат магазина «подарок брату, ему 30, любит настолки, до $70». Помощник спрашивает, когда у брата день рождения. Покупатель отвечает, что в пятницу. До пятницы 5 рабочих дней, а по правилам магазина в этом случае на заказ дается скидка 20%. Поэтому в $70 влезли три подарка на $83.99, со скидкой вышло $67.19.
Отвечает покупателю qwen 9B, а сумму, скидку и корзину считает обычный код. Исходники с прогонами лежат в опенсорсе.
8 сентября Ozon отключил метод финансовых операций — через два месяца после анонсированной даты, без сигнала в самом API. Синк это заметил сразу, я — через две недели. Разбираю, чем заменять, где в новом API яма на 1,2 % и почему зелёный мониторинг ничего не значит.
Разбираем интеграцию интернет-магазина с МойСкладом на собственном движке, Next.js и PostgreSQL, после переезда с InSales. Если ваш магазин живёт в связке с МойСкладом и вы собираетесь уходить с платформы, эти места стоит проверить до запуска. У нас они всплыли на живых заказах, и два самых неприятных нашли сотрудники заказчика, а не наши тесты.
Перенос каталога, заказов и адресов с InSales здесь не разбираем, это отдельная тема. Всё ниже про то, что начинается после: остатки, резервы, статусы и деньги в двух системах, которые должны показывать одно и то же.
Рассказываем о кейсе внедрения компьютерного зрения в ресторане быстрого питания. Ценность кейса для бизнеса: запись с камеры длиной в 24 часа превращается в 30-секундный эпизод, который проверяющий может разобрать за минуту.
В ресторане быстрого питания есть два источника данных: касса и камера. Касса знает, что продали. Камера видит, что положили на поднос. Не всегда касса и камера фиксируют одно и то же.
Из‑за этого разрыва возникает масса неприятностей: недостачи, жалобы покупателей на забытые блюда и споры о реальном времени обслуживания. Получается, что бизнес QSR (Quick Service Restaurants) становится не таким уж быстрым и гостеприимным, как должен быть.
Для нашего клиента из QSR мы собрали систему, которая связывает чеки с видеопотоком и нарезает для проверяющего готовые эпизоды с ошибками.
По причине NDA, все фотографии и схемы в статье созданы искусственно и служат только примерами: это не съёмка ресторана заказчика и не снимки рабочего интерфейса. Названия блюд, номера заказов и время на иллюстрациях условные. Числовые результаты испытаний взяты из материалов проекта.
Меня зовут Павел Седаков, я директор и сооснователь «Оджетто». 18 лет наша компания занимается eCommerce, и все эти годы мы работаем прицельно с энтерпрайз-сегментом. В этой статье я расскажу, почему проекты идут не по плану и как Composable Commerce может это поменять. Заодно покажу, как это выглядит в реальной сборке: что за платформа появилась у нас и почему именно такая.
За последние десять лет в электронной коммерции произошло изменение, которое легко не заметить, если смотреть только на обороты рынка. Уменьшилась сама единица взаимодействия. Раньше онлайн‑покупка была событием: человек собирал корзину, делал относительно крупный заказ и некоторое время ждал следующей покупки. Сегодня заказать одну упаковку кофе, зарядный кабель или продукты на ужин — обычное повседневное действие. Коммерция стала состоять из гораздо большего количества гораздо меньших транзакций.
Особенно хорошо это видно на развитии доставки. Несколько дней ожидания сначала сменились доставкой «завтра», затем — «сегодня», появились часовые интервалы и доставка продуктов за 15–30 минут. Вместо большой закупки раз в неделю возникает множество небольших покупок по мере появления потребности. В eGrocery этот эффект уже хорошо виден: покупатели заказывают чаще и меньшими корзинами.
Для ИТ это принципиальное изменение. Системы обрабатывают не рубли оборота. Они обрабатывают заказы, строки заказа, резервы, остатки, статусы, этикетки, отмены, возвраты, уведомления и обращения к API. Продажа на 10 000 рублей одним заказом и десять продаж по 1000 рублей дают одинаковый оборот, но совершенно разную нагрузку на инфраструктуру. На каждый рубль продаж постепенно приходится всё больше отдельных действий, а значит повышаются требования к архитектуре и производительности систем.