Вы когда-нибудь радовались идеальному прототипу парсера, который у вас летал на демо-странице, а в проде внезапно начал ловить 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. Пока писали другие части системы, держали это в голове и ждали, когда дойдут руки, чтобы заменить агрегацию на более устойчивое решение. Мы рассмотрели возможные варианты, и всё свелось к двум основным подходам. Дальше расскажем, как выбирали между ними и к чему в итоге пришли.
Мы любим говорить: «Нужно делать CustDev». Или: «Нужно считать Юнит-экономику». Или: «Нарисуем CJM — и станет ясно».
Проблема в том, что эти артефакты часто делаются изолированно: JTBD не связывается с User Story, Юнит-экономика существует в вакууме, Use Cases живут отдельно от гипотез, а гипотезы накапливаются и становится непонятно, почему они появились именно в таком порядке.
В результате — знания есть, но целостной картины видения продукта нет.
Геймификация превращает обычное взаимодействие с приложением в увлекательный квест: каждый клик — это шаг к следующему уровню, каждое действие приносит бонусы, баллы, достижения. Пользователи возвращаются, чтобы закрыть миссию и получить награду, а бизнес — получает рост LTV и продажи.
В этой статье аналитик CleverPumpkin Алёна Сорокина расскажет про уже привычные и набирающие популярность виды геймификации. А еще о том, с какими сложностями можно столкнуться и как интегрировать игры в маркетинговую стратегию.
Встречались ли вы с бейджем 18+ и думали, зачем он тут?
Такие значки мы часто видим на афишах спектаклей, фильмах, играх, книгах и даже в онлайн-магазинах. Это возрастная маркировка — система обозначений, которая указывает, с какого возраста рекомендуется просмотр, использование или участие в контенте. Её цель — защитить детей и подростков от информации, способной навредить психике или развитию, и помочь взрослым принимать обоснованные решения.
Разберёмся, откуда взялась эта маркировка, какие бывают категории и как с ней работать в интерфейсах и визуале.
Как мы снизили расходы на экспресс-доставку в Яндекс.Доставке на 13% и не потеряли в качестве
Привет! Меня зовут Денис Захаров, я руководитель продуктов логистики в компании GRI. Мы занимаемся заказной разработкой и сопровождением, и один из наших ключевых клиентов – ювелирный ритейлер Sunlight. Наша задача – не просто интегрировать сервисы, а делать бизнес эффективнее: меньше тратить, больше зарабатывать.
Сегодня расскажу, как оптимизировать тарифы Яндекс.Доставки и снизить логистические расходы, не потеряв в скорости и удобстве для клиентов. Это практический кейс с цифрами, логикой и алгоритмом. Поехали.
В сфере IT есть сильное профессиональное искажение. Айтишникам кажется, что продукт, который они продают это код. Но в головах их клиентов мир выглядит иначе. Заказчики покупают у айтишников не репозиторий на гитхабе или докер-образ, поднятый на VPS-ке. Они покупают решение своих бизнес-задач. Причём, заметьте, что в этой покупке весь риск лежит на стороне того, кто платит за работу. Потому что гарантия айтишника, что он качественно справится со своей задачей вовсе не гарантирует клиенту, что его бюджет будет потрачен эффективно и его проблема будет решена. Решена именно как бизнес-задача, а не как какая-то другая. То есть, что на выходе от всех затеянных телодвижений будет получен ощутимый положительный финансовый результат.
И этот риск уменьшается только одним способом - коммуникацией. Поэтому я много лет повторяю мысль про то, что продажи и коммуникации это по сути одно и тоже. Продажа это коммуникация. Коммуникация это продажа. Даже, если вы просто разработчик в какой-то компании и общаетесь со вселенной через тикеты в джире и живёте в мире код-ревью и комитов. Возможно, вам кажется, что вы коммуницируете лишь с кодом и абстракциями... Нет, вы коммуницируете с людьми. Кто-то у вас покупает решение каких-то задач, даже, если эти задачи сформулированы техническим языком.
В мире IT-услуг, будь то фриланс или студийная разработка приложений, ключевым моментом является не только уровень технических навыков, но и коммуникационные способности. Как опытный менеджер по продажам SaaS-продуктов и разработки программного обеспечения, я хочу поделиться некоторыми рекомендациями о том, как успешно продавать свои услуги и становиться более запоминающимся и востребованным профессионалом.
По оценкам Всемирного экономического форума, 39% профессиональных навыков устареют в ближайшие пять лет (2025–2030 гг.). Это касается работников почти всех сфер, но особенно сильно заденет разработчиков — как начинающих, так и опытных.
Пока процент не кажется тревожным, однако скоро станет таковым — темпы внедрения новых технологий ускоряются. По мере развития трендов в разработке ПО, способы создания программного обеспечения через несколько лет могут кардинально отличаться от сегодняшних.
Какие тренды повлияют на обозримое будущее и как к ним подготовиться? Предлагаем разобраться в этом материале.
Микросервисная архитектура позволяет разрабатывать высоконагруженные, распределенные и гибкие приложения. Но цена разработки таких систем очень высока, и решая выше указанные проблемы, разработчики сталкиваются с другими проблемами, которых либо нет в монолитных приложениях, либо они не так сильно в них проявляются: сложный обмен данными между сервисами, денормализация и консистентность данных, инвалидация кэша и интеграция с внешними системами.
Решать выше перечисленные проблемы можно разными способами. В своей работе в компании Greensight в качестве senior backend developer при разработке заказных проектов на базе Open Source платформы Ensi, я с коллегами перепробовал множество решений.
Данная статья описывает практическое использование Kafka в микросервисных приложениях для решения этих проблем.
Кросс-платформенный Rust от и до: GUI + CLI + CI + Docker Реальный опыт доставки DotPlus на Linux и ARM
Всем привет!
Опен-сорс и почему в российских ПО появляется код из библиотек, расположенных на серверах из недружественных юрисдикций – самая модная тема сезона.
Поэтому Владимир Высоцкий, руководитель по развитию бизнеса продукта Solar appScreener, в этом материале решил напомнить об основных рисках открытого кода и как их можно избежать на этапе разработки вашего продукта.
