Разработка под e-commerce *

У нас в Точка Банк много продуктов, для которых нужны SEO-лендинги: онлайн бухгалтерия, эквайринг, электронный документооборот. Создание одного сайта — это несколько недель работы с участием редактора, дизайнера, разработчика, тестировщика, верстальщика. Не страшно, если нужен один сайт. Но когда их много, на их создание уходит колоссальное количество времени. 

Меня зовут Василий Полосухин — я фронтовый техлид в Точка Банк. В статье рассказываю, как мы сделали визуальный конструктор страниц и научились собирать сайты без кода.

Делимся опытом создания робота-диспетчера на low-code платформе n8n для обработки большого потока заказов. В статье рассказываем, как использовали Redis для очередей и динамической конфигурации, показываем реальные workflow и код, а также делимся, как боролись с утечками памяти и гонкой состояний. Будет полезно разработчикам, аналитикам и тимлидам, которые смотрят в сторону low-code для решения реальных бизнес-задач.

В 2025 году уже недостаточно просто выпустить приложение — оно должно быстро адаптироваться к изменениям рынка, удобно и эффективно интегрироваться с новыми технологиями и обеспечивать хороший пользовательский опыт. Но что лучше выбрать: нативную разработку, кроссплатформу, или Kotlin Multiplatform? 

Александр Кияйкин, CTO компании по разработке мобильных приложений CleverPumpkin, разбирает эти три подхода и сравнивает плюсы и минусы каждой технологии. 

Привет, Хабр! Меня зовут Данил Комаров, я дата-сайентист в команде персонализации Lamoda Tech. Уже больше года мы меняем подход к рекомендациям на главной странице, делая их персонализированными. Я расскажу, как мы внедряли и масштабировали решение, переводили его из оффлайна в онлайн, и бустили систему на разных слоях.

Low-code разработка очень полезна в тех случаях, когда в организации требуется постоянное обновление и развитие, а также создание новых и новых сервисов. Однако, чтобы такая схема создания ПО действительно работала, нужно использовать стабильную платформу, которая обеспечит одновременно гибкость, безопасность, прозрачность и эффективность разработки. В этой статье я расскажу о решении такого класса от РЕД СОФТ. Мы пройдемся по основным возможностям РЕД Платформы, познакомимся с ее архитектурой, принципами работы с документами и сущностями, а также с особенностями разработки.

Всем привет! Меня зовут Александр Антипин и я руковожу небольшой студией разработки. Мы разрабатываем мобильные игры и IT-решения для компаний. В этой статье я расскажу про IT Park в Узбекистане — место, которое сейчас активно обсуждают в айтишных чатах. Если вы думаете, что это просто хайп, то я попробую вас переубедить. За пару дней в Ташкенте я успел зарегистрировать компанию, открыть счёт, получить карты и даже съездить в Самарканд, чтобы проникнуться духом города с 2500-летней историей. Но обо всём по порядку: зачем вообще туда ехать, почему именно Узбекистан, какие бонусы даёт IT Park и как там живётся?

Меня зовут Ескендиров Мурат, я — архитектор сайта в Ви.Tech, IT-дочке ВсеИнструменты.ру. В этой статье расскажу, как мы строили сервис для выдачи карточек товаров, обрабатывающий до 5 миллиардов запросов в сутки, какие архитектурные решения приняли и с какими проблемами столкнулись в процессе. Расскажу, какие решения сработали, а какие до сих пор остаются нашей головной болью.

Сайт «ВсеИнструменты» имеет почти 20-летнюю историю, и, как это часто бывает, за это время он превратился из маленького сайта с парой сотен товаров на PHP, созданного «на коленке», в гигантский монолит с несколькими миллионами уникальных номенклатур.

Несколько лет назад перед сайтом встали в полный рост проблемы, характерные для многих компаний, выросших из «подпартного» стартапа (первый свой заказ компания «ВсеИнструменты.ру» получила во время лекции в МФТИ, тогда один из основателей для его оформления залез под парту) в многомиллиардную корпорацию:

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

Расскажу, как мы автоматизировали заполнение карточек товаров на Авито и настроили выгрузку с 1С.

Кажется, что установленные в ресторанах быстрого питания сенсорные экраны — просто удобный инструмент для быстрого заказа бургеров? Вот только на деле это — хитро просчитанная система, которая с момента внедрения в 2015 году увеличила средний чек на 30% и принесла компании миллиарды долларов. 

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

Вы когда-нибудь радовались идеальному прототипу парсера, который у вас летал на демо-странице, а в проде внезапно начал ловить 403, 429, пустые HTML и «куда-то делись карточки»? Контент отрисовывается на JS, сервер требует токен, после смены IP, старая сессия перестаёт работать.

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

Привет! Меня зовут Илья Шмяк, я саунд-дизайнер. Моя работа — создавать звук для игр, кино, брендов. Я не программист, но у меня была гипотеза: можно ли в одиночку, используя только ИИ-ассистента, построить с нуля полноценный веб-сервис?

Спойлер: можно. Этот путь занял 7 месяцев и привел к запуску noise pw — библиотеки уникальных звуков. Это не просто история успеха, а разбор факапов, технических решений и текущей экономики проекта.

Этап 1. Гипотеза и MVP: Иллюзия простоты и первые ошибки фронтенда

Все началось с идеи создать платформу для продажи моих звуков и музыки. Моим единственным техническим специалистом стал ChatGPT.

Я начал с анализа референсов, чтобы понять технологический стек. ИИ порекомендовал Jekyll — генератор статических сайтов, как «быстрый, безопасный и простой». На тот момент я не осознавал концепции бэкенда и считал, что сайт — это просто набор HTML-страниц. Весь первый этап был посвящен созданию клиентской части (фронтенда).

Привет! Меня зовут Игнат. В этой статье я расскажу про разработку адаптера для работы с EGTS-протоколом (Era Glonass Telematics Standard), который можно использовать для передачии телеметрии курьеров из курьерских служб в РНИС (РНИС - государственная информационная система «Единая региональная навигационно-информационная система города Москвы»). Код написан на Kotlin и подходит для использования в Java и Kotlin приложениях. Простота подключения модуля привела к идее вынести проект в опенсорс, чтобы его могли использовать курьерские службы с бэкендом на jvm. Поехали!

Архитектура Сервера — это не только набор серверов и сервисов, это контракт о том, как компоненты взаимодействуют и кто за что отвечает. В сетевой части этот контракт делится на две очевидные зоны ответственности: ingress (входящий трафик) и egress (исходящий). Reverse-proxy (NGINX/Envoy/Traefik и им подобные) — стандартный элемент ingress-слоя: TLS-терминация, кеш, балансировка и фильтрация трафика. На уровне egress мы часто используем прокси-слой, который формирует «внешний вид» наших исходящих соединений; среди опций для egress ключевую роль играют статические residential-прокси — IP от реальных провайдеров, закреплённые за сессией на время операции.

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

Как правило, у него есть некоторый набор отличительных черт: он большой, у него красивые картинки, он содержит очень важную информацию!

А самое главное — зачастую, часть его слайдов... нечитаема. И это очень коварная проблема, ведь поначалу ничто не предвещает беды. Дизайнер делает красивый дизайн, верстальщик - качественную вёрстку. Всё идёт отлично!

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

А ещё есть разные... кхм... разрешения... кхм... экрана... Простите, слеза в горле застряла.

Почему они не потопили меня и всех моих коллег. Много объективной статистики и немного субъективщины.

Привет! Меня зовут Мария Аркуша, со мной Николай Нафтулин, мы продакт-менеджеры в Точке. Сегодня расскажем, как мы одновременно создавали Точка Стор — продукт для предпринимателей, с помощью которого любой может быстро собрать свой сайт или витрину в Telegram.

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

Stories — один из самых заметных форматов, перекочевавших из соцсетей в ecommerce. Они:

стимулируют интерес, создают эффект FOMO (fear of missing out) — страх упустить выгоду, повышают конверсию.

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

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

Разбираем полный цикл построения надёжного скрейпера для Temu: от выбора стека и прокси до обхода JavaScript‑челленджей и сбора тысяч карточек товаров без единого 403.

Привет, Habr! Меня Женя Паршин, и я инженер по автоматизации тестирования, работающий преимущественно в e-commerce. В этой статье я расскажу, почему создание собственного фреймворка для автоматизации — это не "изобретение велосипеда", а практичное решение.

Система заказов: решаем проблему конкуренции без очередей

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

Сначала стояла «заглушка»: при каждом новом заказе «на лету» агрегировали данные из базы — проверяли, хватает ли товара на складе с учетом уже оформленных заказов. Такой подход часто используют на старте, когда нужно быстро запустить MVP. Понимали, что при росте нагрузки он не масштабируется: возможны блокировки, гонки и overbooking. Пока писали другие части системы, держали это в голове и ждали, когда дойдут руки, чтобы заменить агрегацию на более устойчивое решение. Мы рассмотрели возможные варианты, и всё свелось к двум основным подходам. Дальше расскажем, как выбирали между ними и к чему в итоге пришли.