В этой статье соберём работающего RAG-бота, который отвечает на вопросы о любой веб-странице, примерно на 60 строках Python. Никаких парсеров HTML, headless-браузеров и сложных фреймворков — только requests, локальная Ollama и чистый Markdown.

Что такое RAG

RAG (retrieval-augmented generation) — это подход, при котором языковая модель не отвечает по своей памяти, а сначала ищет релевантные фрагменты во внешнем тексте, а потом генерирует ответ на их основе. Это резко снижает галлюцинации и позволяет работать с данными, которых не было в обучающей выборке.

• RAG-бот на Python укладывается в ~60 строк и работает без облачных LLM.
• Самое неприятное в RAG-пайплайне — очистка HTML; готовый Markdown API убирает эту работу.
• Текст разбивается на чанки (~1200 символов), каждый превращается в эмбеддинг и сравнивается с эмбеддингом вопроса.
• Локальные модели nomic-embed-text и llama3 через Ollama не требуют иностранных карт и VPN.
• Качество ответа зависит от качества исходного текста: сырой HTML зашумляет поиск, чистый Markdown улучшает ретривл.

Что мы соберём

Архитектура бота простая и универсальная:

1. Отправляем URL в сервис извлечения текста и получаем чистый Markdown.
2. Разбиваем Markdown на фрагменты (чанки) по границам абзацев.
3. Превращаем каждый чанк в вектор — эмбеддинг.
4. То же самое делаем с вопросом пользователя.
5. Находим чанки, ближайшие к вопросу, по косинусной близости.
6. Отдаём найденные фрагменты + вопрос языковой модели с инструкцией отвечать только по контексту.

Такая схема легко масштабируется: можно заменить локальную Ollama на OpenAI, Anthropic или российские модели, а векторы перенести в Qdrant или Chroma.

Что понадобится

• Python 3.9+
• Библиотека requests
• Локально запущенная Ollama с моделями nomic-embed-text и llama3
• Доступ к API извлечения текста (в примере — Web to Markdown/JSON API; бесплатный тариф даёт 50 запросов в сутки)

Код бота

Сохраните скрипт как rag_bot.py и подставьте свой ключ, если сервис извлечения текста требует авторизации:

На что обратить внимание:
Если вы используете RapidAPI-версию сервиса, запрос к API_URL обычно требует заголовка X-RapidAPI-Key. Без ключа бесплатный endpoint может вернуть 401.

Разбор по частям

fetch_markdown — единственный внешний вызов. Сервис сам забирает страницу, убирает навигацию, баннеры и футер и возвращает Markdown: заголовки, абзацы, списки. Это освобождает от зависимостей вроде BeautifulSoup или headless Chrome.

chunk_markdown режет текст на фрагменты примерно по 1200 символов, не разрывая абзацы. Мелкие чанки дают более точный ретривл, но увеличивают число эмбеддингов; для начала 1200 символов — хороший баланс.

embed и cosine превращают текст в векторы и считают их близость. Модель nomic-embed-text из Ollama бесплатна, быстрая и неплохо понимает русский и английский.

answer эмбеддит вопрос, выбирает три самых похожих чанка и строит промпт с жёстким ограничением: отвечать только по контексту. Это главная страховка от галлюцинаций.

Запуск

Установите зависимости и скачайте модели в Ollama:

Если всё в порядке, в консоли появится примерно такой результат:

Почему важен чистый Markdown

Если скормить эмбеддинг-модели сырой HTML, в векторах окажутся теги <div>, меню навигации и копирайты из футера. В результате поиск похожести выдаст «Copyright © 2026» вместо полезного ответа. Чистый Markdown — заголовки, абзацы, списки — улучшает качество ретривла почти бесплатно.

Если не хочется зависеть от внешнего API, можно заменить fetch_markdown на один из альтернативных вариантов:

• trafilatura — библиотека на Python для извлечения главного текста.
• r.jina.ai/http://URL — бесплатный сервис без ключа.
• Firecrawl — API с поддержкой сканирования сайтов целиком.
• ScrapingBee — прокси + рендеринг для сложных страниц.

Для российских разработчиков локальная Ollama особенно удобна: модели качаются бесплатно, не нужны иностранные карты, а инференс идёт на своём железе.

Куда развивать

• Направьте бота на документацию, чейнджлог или блог конкурента и задавайте вопросы по ним.
• Замените Ollama на OpenAI, Anthropic, Gemini или российские модели — функция answer меняется в двух строках.
• Сохраняйте эмбеддинги в векторную БД: Chroma, Qdrant или FAISS, чтобы индексировать сразу много страниц.
• Используйте формат json вместо Markdown, если нужна структура: параграфы, заголовки, ссылки — отдельно.

Выводы

RAG — не магия, а последовательность простых шагов: получить чистый текст, разрезать его на фрагменты, найти ближайшие к вопросу и отдать их модели. Весь минимальный пайплайн укладывается в короткий Python-скрипт, который можно запустить на своём ноутбуке.

RAG работает ровно так хорошо, каков текст, который вы ему скармливаете. Уберите самую утомительную часть — очистку HTML, — и останется интересное: поиск и генерация.

Исходник идеи — статья «Chat With Any Website: Build a RAG Bot in ~60 Lines of Python». Попробуйте собрать бота на своей странице и посмотрите, где он справляется, а где начинает фантазировать.

Почему инфраструктура начинает привлекать больше, чем фичи

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

Я перешёл в Android-инфраструктуру — начал делать инструменты для других мобильных разработчиков. Это помогло увидеть: главные проблемы не в фичах, а в слое между приложением и бэкендом.

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

Когда я проектировал gateway, я точно знал, что почувствуют мобильные разработчики, если ошибусь. Добавить ещё один сетевой вызов — это будет не бесплатно. Оставить логику в приложении — значит отдать её на устройство, которое я не контролирую.

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

Чему пришлось учиться с нуля? Операционному мышлению. В Android ты выпускаешь релиз — и он либо работает, либо нет. Если крашится, починишь в следующей версии. В инфраструктуре нет «следующей версии». Если gateway падает, всё приложение ложится для миллионов пользователей прямо сейчас.

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

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

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

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

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

Когда говорят «спроектировать gateway с нуля и перевести на него живую платформу», за этими словами стоит не один навык, а целых три, и каждый требует совершенно разной подготовки.

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

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

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

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

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

Поэтому если вы мобильный инженер и размышляете, можно ли перейти в инфраструктуру, — вопрос не в том, правильный ли у вас бэкграунд. Вопрос в другом: готовы ли вы учиться тому, чего пока не знаете, и способны ли обратить то, что уже понимаете, в собственное преимущество. Если ответ «да» — путь для вас открыт. Просто указателей на нём пока не расставили.

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

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

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

Ниже — перевод статьи Уиллисона: что такое LiteParse, почему его удалось перенести в браузер и как выглядит вайб-кодинг, когда автор не читает ни строчки из получившегося HTML и TypeScript.

LiteParse от LlamaIndex — классический PDF-парсинг без ИИ. Эвристики spatial text parsing вычисляют порядок чтения (колонки, подписи, сноски), а Tesseract OCR добирает сканы.

Браузерная версия собрана из тех же PDF.js и Tesseract.js — никакого сервера, данные остаются на устройстве.

Процесс: план в plan.md, команда «build it», очередь follow-up-промтов, Playwright + red/green TDD, деплой на GitHub Pages через Actions.

Время в Claude Code на фазу сборки — 59 минут. Уиллисон не прочитал ни одной строки получившегося кода.

Уиллисон готов привязать к проекту репутацию — редкий случай для его вайб-проектов. Статический сайт и полная приватность делают blast radius почти нулевым.

Что такое LiteParse и зачем он нужен

LlamaIndex выложили опенсорс-инструмент LiteParse — Node.js CLI для извлечения текста из PDF. Что приятно: LiteParse не использует ИИ-модели. Это старый добрый PDF-парсинг с фолбеком на Tesseract OCR (или другой подключаемый OCR-движок) для файлов, где «текст» представлен картинками страниц, а не самим текстом.

Сложная задача, которую решает LiteParse, — выдать текст в нормальном порядке, несмотря на причудливые макеты PDF. Авторы называют это «spatial text parsing», пространственным парсингом: хитрые эвристики распознают многоколоночную вёрстку и группируют блоки так, чтобы текст читался линейно.

В документации LiteParse описан паттерн Visual Citations with Bounding Boxes — «визуальные цитаты с ограничивающими рамками». Уиллисону идея нравится: отвечать на вопросы по PDF и прикладывать к ответу обрезанный и подсвеченный фрагмент исходника — хороший способ поднять доверие к ответам RAG-системы (retrieval-augmented generation — когда LLM отвечает, подтягивая нужные куски из базы документов).

LiteParse задуман как CLI для агентов. Запускается вот так:

Уиллисон попробовал инструмент с Claude и быстро понял: оставаться CLI-приложением LiteParse вовсе не обязан. Он построен на PDF.js и Tesseract.js — двух библиотеках, с которыми автор уже делал похожие штуки в браузере. Единственная причина, почему у LiteParse до сих пор не было чистой браузерной версии, — её просто никто не сделал.

Знакомство: LiteParse в браузере

Зайдите на simonw.github.io/liteparse/ и попробуйте инструмент на любом PDF — всё работает прямо в вашем браузере. Интерфейс минимальный: перетаскиваете файл, выбираете режим (с OCR или без), на выходе получаете распознанный текст и pretty-printed JSON, оба с кнопкой Copy. Опционально можно вывести превью всех страниц PDF.

Как это собрали с Claude Code и Opus 4.7

Всё началось в обычном приложении Claude на iPhone. Уиллисон хотел пощупать LiteParse и загрузил с телефона случайный PDF с таким промтом:

Clone https://github.com/run-llama/liteparse and try it against this file

Обычный Claude теперь умеет клонировать репозитории прямо с GitHub и ставить пакеты из PyPI и npm — даже без доступа к остальному интернету из контейнера. Уиллисон часто так пробует новый опенсорс с телефона, не доставая ноутбук. После нескольких уточняющих вопросов (весь диалог можно открыть в расшаренном транскрипте) он спросил главное:

Does this library run in a browser? Could it?

Ответ был достаточно убедительным, чтобы попробовать всерьёз. Уиллисон открыл ноутбук, переключился на Claude Code. Форкнул оригинальный репозиторий на GitHub, склонировал локальную копию, создал новую ветку web и скопировал последний ответ Claude в файл notes.md. А потом сказал Claude Code:

Get this working as a web app. index.html, when loaded, should render an app that lets users open a PDF in their browser and select OCR or non-OCR mode and have this run. Read notes.md for initial research on this problem, then write out plan.md with your detailed implementation plan

Подобные проекты Уиллисон всегда начинает с плана. Иногда он включает у Claude «режим планирования», но здесь ему нужен был план как артефакт в репозитории — поэтому сразу plan.md. Это позволяет итеративно править сам план. Заметив, что Claude решил отложить «canvas-encode swap» (замену способа, которым PDF.js сохраняет страницы картинкой — без неё не работает превью страниц в браузерной версии) на v2, Уиллисон дописал:

Update the plan to say we WILL do the canvas-encode swap so the screenshots thing works

Через несколько коротких правок получился plan.md, который автор счёл достаточно хорошим для реализации. И сказал:

build it.

И дальше Уиллисон по большей части оставил Claude Code работать самому: возился с другими проектами, периодически заглядывал проверить прогресс. Параллельно подбрасывал подсказки в очередь. Queued-prompts не попадают в стандартный экспорт транскрипта Claude Code, но их можно вытащить из папки ~/.claude/projects/ командой rg queue-operation --no-filename | grep enqueue | jq -r '.content'. Ниже — выдержка из этих follow-up-промтов с авторскими комментариями:

• «Реализуй через Playwright и red/green TDD, спланируй это тоже» — подробнее про red/green TDD Уиллисон писал отдельно
• «Давай использовать собственный рендерер PDF.js» — Claude начал экспериментировать с pdfium
• «Финальный UI должен показывать и текст, и pretty-printed JSON — оба в textarea с кнопками копирования. И должен быть mobile-friendly» — новая идея, как UI должен выглядеть
• «Делай маленькие коммиты по ходу дела» — см. ниже
• «В index.html вверху страницы добавь ссылку на github.com/run-llama/liteparse» — важно кредитить зависимости
• «View on GitHub → — плохая формулировка: это репозиторий не браузерной обёртки, а базовой библиотеки LiteParse»
• «Чекбокс Run OCR должен быть снят по умолчанию»
• «Когда пытаюсь распарсить PDF в браузере — вижу Parse failed: undefined is not a function» — Claude тестировал в Playwright под Chrome, а оказалось, что это баг Safari
• «Когда нажимают Copy, пусть текст на 1,5 секунды меняется на Copied!»
• «Оформи поле выбора файла так, чтобы длинные имена не ломали вёрстку в Firefox. И добавь drag-and-drop-зону, которая ещё и кликабельна» — скриншоты мелких UI-глитчей Claude воспринимает на удивление хорошо
• «Текст в drop-зоне сейчас чуть ближе к верху — поцентруй по вертикали» — точечная правка поверх предыдущей
• «В Safari на macOS всё ещё падает с readableStream» — Claude починил, как только ему подсказали запустить Playwright в этом браузере; следующим промтом Уиллисон подтвердил: «works in safari now»

«Делай маленькие коммиты» Уиллисон теперь просит по привычке: это упрощает последующее чтение и ревью кода, а ещё, по его непроверенной гипотезе, помогает агенту работать эффективнее — дополнительный стимул планировать и брать задачи по одной.

Пока агент работал, Уиллисон решил, что было бы неплохо уже повзаимодействовать с ещё не завершённой версией. Он открыл отдельную сессию Claude Code в той же папке и спросил, как запустить сборку. Ответ — npx vite: команда поднимает dev-сервер с live-reload, так что каждая правка на диске сразу видна в браузере, и можно тут же просить «подкрути вот это».

Ближе к концу Уиллисон решил, что проект достаточно хорош для публикации. Новая сессия Claude Code, промт:

Look at the web/ folder - set up GitHub actions for this repo such that any push runs the tests, and if the tests pass it then does a GitHub Pages deploy of the built vite app such that the web/index.html page is the index.html page for the thing that is deployed and it works on GitHub Pages

После нескольких итераций получился рабочий GitHub Actions workflow, который собирает приложение через Vite и деплоит результат на simonw.github.io/liteparse/. GitHub Pages Уиллисон любит именно за такие кейсы: любой репозиторий бесплатно превращается в задеплоенное веб-приложение с произвольным build-шагом — и всё это настраивает Claude.

В проектах такого типа всегда есть риск, что модель «сжульничает»: пометит ключевые фичи как TODO и сделает их заглушками или срежет углы в требованиях. Ответственный способ это поймать — прочитать весь код. Но здесь это не планировалось, поэтому Уиллисон запустил OpenAI Codex с GPT-5.5 (у автора был ранний доступ к модели) и попросил:

Describe the difference between how the node.js CLI tool runs and how the web/ version runs

Ответ был достаточно подробным, чтобы убедиться: Claude не срезал углы в чём-то критичном. Суммарное время в Claude Code на фазу «build it» — 59 минут. Полный транскрипт сессии Уиллисон потом экспортировал своим же инструментом claude-code-transcripts — правда, без очереди follow-up-промтов, их экспорт пока не подхватывает.

Это ещё вайб-кодинг или уже нет?

Уиллисон педантичен в определении vibe coding: это не любое использование ИИ для написания кода. Вайб-кодинг — это когда вы используете ИИ и при этом вообще не просматриваете получившийся код и не думаете о нём. По собственному определению автора, LiteParse for the web — пожалуй, максимально чистый вайб-кодинг: ни одной строки HTML и TypeScript Уиллисон не прочитал (и, пока писал это предложение, даже полез проверять, JS там или TS).

И всё же этот проект не ощущается как другие его вайб-проекты:

• Это статическое браузерное приложение на GitHub Pages. Blast radius (радиус поражения от бага) почти нулевой: для конкретного PDF оно или работает, или нет.
• Приватные данные никуда не уходят — вся обработка в браузере, поэтому аудит безопасности не нужен. Уиллисон специально заглянул в network-панель и убедился: при парсинге PDF дополнительных запросов нет.
• Инженерный опыт всё равно потребовался — чтобы сообразить, что перенос LiteParse в браузер вообще возможен. Без этого никакой агент не справился бы.

Главное — Уиллисон готов привязать к этому проекту свою репутацию и рекомендовать его другим. В отличие от большинства его вайб-проектов, он не уверен, что дополнительные инженерные часы заметно улучшили бы первый релиз. «Оно работает как есть, и это нормально».

PR в апстрим Уиллисон не открывал — не обсуждал это с командой LiteParse. Но завёл issue: если команде будет интересно взять вайб-код как отправную точку для чего-то более официального — пусть забирают.

Выводы

LiteParse for the web — не прорыв, а аккуратная обёртка поверх PDF.js и Tesseract.js. Но с конкретной пользой: приватный парсинг PDF без облака, который можно забрать и поставить у себя.

Главное в кейсе — не сама браузерная обёртка, а рабочий паттерн: план-артефакт в репозитории, запуск через «build it», очередь follow-up-подсказок поверх работающего агента и финальная проверка результата другой моделью. Такой процесс повторяется на любом проекте сопоставимой сложности.

Оригинал: Extract PDF text in your browser with LiteParse for the web Simon Willison, 23 апреля 2026 года. Апстрим-репозиторий LiteParse — github.com/run-llama/liteparse, демо браузерной версии — simonw.github.io/liteparse/.

Вы знаете, что a + b * c + d вычисляется как a + (b * c) + d. Но как объяснить это машине? Как закодировать правила приоритета операторов так точно, чтобы парсер сам правильно строил дерево разбора?

Pratt parsing — элегантный алгоритм, придуманный Воном Праттом в 1973 году. Он лежит в основе парсеров многих современных языков, но его описания часто сводятся к магическим таблицам приоритетов без объяснения, почему это работает. Эта статья строит интуицию с нуля.

— AST — основная структура данных: оператор над операндами, вычисление снизу вверх.

— Приоритет операторов определяет наклон дерева: выше приоритет — глубже в дерево.

— При падении приоритета алгоритм поднимается по «хребту» дерева — это и есть суть Pratt parsing.

— Левая и правая ассоциативность задаются через LBP и RBP (left/right binding power).

— Полный парсер с поддержкой всех операторов — около 10 строк на Python.

Абстрактное синтаксическое дерево

Наиболее распространённое решение для разбора выражений — абстрактное синтаксическое дерево (AST, Abstract Syntax Tree). В AST каждый оператор стоит над своими операндами. Вычисление идёт снизу вверх: сначала обрабатываются дочерние узлы, затем операция над ними.

Для выражения a + b * c + d правильное AST выглядит так:

Узел * находится глубже, чем +, — это и отражает более высокий приоритет умножения. При вычислении сначала перемножаются b * c, результат складывается с a, затем прибавляется d.

Как приоритет влияет на форму дерева

Здесь кроется главная интуиция Pratt parsing. Приоритет операторов напрямую определяет, в какую сторону «наклоняется» дерево:

• Убывающий приоритет (например, * + ==) — дерево наклонено влево: операторы с большим приоритетом оказываются глубже.
• Возрастающий приоритет (например, == + *) — дерево наклонено вправо.
• Равный приоритет — по соглашению левая ассоциативность, дерево наклоняется влево.

Рассмотрим промежуточное состояние разбора. Пусть мы уже построили дерево I для выражения (a > b + c * d) — это правонаклонное дерево: > наверху, * в самом низу.

Теперь встречаем следующий оператор. Куда вставить новый узел? Зависит от приоритета:

• [I] * e — приоритет * не меньше приоритета * в дереве, вставляем в самый глубокий узел.
• [I] + e — приоритет + ниже *, но выше >, поднимаемся по хребту выше узла *.
• [I] == e — приоритет == ниже всего дерева, всё дерево I становится левым потомком.

Ключевое наблюдение: когда встречается оператор с меньшим приоритетом, мы поднимаемся по правому хребту дерева, собирая узлы с более высоким приоритетом. Это и есть Pratt parsing — алгоритм, который реализует именно этот подъём по хребту.

От интуиции к коду

Начнём с простого случая — правонаклонного дерева. Каждый оператор правоассоциативен, приоритет не учитывается:

Здесь leaf() читает следующий терминал (число или переменную), peek() смотрит на текущий токен без продвижения, advance() читает и сдвигает позицию.

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

Это уже работает для правоассоциативных операторов. Но у нас if — разобрали один оператор и вышли. Для левоассоциативных нужен цикл:

Полный Pratt parser

Замена if на while — это и есть процедура подъёма по хребту дерева. Цикл продолжается, пока следующий оператор имеет достаточно высокий приоритет, чтобы «захватить» левую часть. Как только приоритет падает — выходим, и текущее поддерево передаётся вверх по стеку вызовов.

Правая ассоциативность через binding power

До сих пор у нас одно число приоритета на оператор. Но для управления ассоциативностью нужно различать, насколько «сильно» оператор притягивает операнды слева и справа. Вводятся два понятия:

• LBP (left binding power) — сила притяжения левого операнда.
• RBP (right binding power) — сила притяжения правого операнда.

Правила ассоциативности через binding power:

• Левоассоциативные операторы (+, *): LBP == RBP. Правый рекурсивный вызов получает тот же приоритет — следующий оператор с таким же приоритетом не захватывается, строится левое дерево.
• Правоассоциативные операторы (**, =): RBP = LBP − 1. Правый рекурсивный вызов получает чуть меньший приоритет — следующий оператор с таким же приоритетом захватывается, строится правое дерево.

Это финальная версия Pratt parser. Всего 8 строк кода — и корректный разбор всех операторов с любым приоритетом и ассоциативностью.

Итог

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

Ключевые детали реализации:

• while вместо if — реализует подъём по хребту для левоассоциативных операторов.
• Передача приоритета в рекурсию — ограничивает, какие операторы «захватываются» на следующем уровне.
• LBP / RBP — контролируют ассоциативность через разницу в единицу.

Понимание этой геометрии делает Pratt parsing прозрачным: каждая строка кода отражает конкретное геометрическое действие с деревом, а не магию таблиц приоритетов.

Мы собрали пять свободных инструментов, которые решают типичные задачи разработчика: от скачивания видео с любых сайтов до защиты от подглядывающих коллег. Все они работают локально или self-hosted, не отправляют данные в облако и распространяются с открытым исходным кодом.

Больше подобных находок — в тг-канале Инструменты программиста. Там каждый день появляются свежие CLI-утилиты, GUI-приложения, библиотеки и сервисы для разработки. Всё протестировано, с примерами использования и ссылками на репозитории.

GUI для скачивания видео: yt-channel-downloader

yt-channel-downloader — графическое приложение для скачивания видео с YouTube и любых других сайтов, где есть видеоконтент. Это не только видеохостинги: если на странице есть видео, приложение попытается его скачать.

Под капотом работает связка из трёх Python-библиотек: yt-dlp для универсального парсинга, scrapetube для работы с каналами и плейлистами, pytube как вспомогательный инструмент. Поверх этого — кроссплатформенный графический интерфейс для Windows, macOS и Linux.

Как это работает: вводите ссылку на видео, плейлист или целый канал. Приложение подтягивает список доступных роликов и даёт выбрать, что именно качать — целиком или выборочно. Можно скачать только аудиодорожку или выбрать конкретное качество видео.

Полезные особенности:

• Вход в аккаунт YouTube прямо из приложения. Это позволяет скачивать приватные ролики, доступные только по ссылке или для авторизованных пользователей. Куки хранятся в локальном конфиге и автоматически очищаются при выходе из аккаунта.
• Пометка уже скачанных файлов. Не нужно вручную проверять, что уже есть на диске.
• Ограничение параллельных потоков. Если качаете большой плейлист, можно задать лимит одновременных загрузок, чтобы очередь не подвисала и не перегружала канал.

Для работы нужен установленный ffmpeg — он используется для конвертации и склейки потоков. Для пользователей Windows доступен готовый инсталлятор в разделе Releases (размещён на SourceForge).

Код и инструкции по установке — на GitHub. В планах у автора: поддержка скачивания YouTube Shorts, поиск по полученному списку видео, более наглядный прогресс-бар, история загрузок и расширенная поддержка других видеоплощадок.

gopass — менеджер паролей для разработчиков

gopass — консольный менеджер паролей, заточенный под командную работу и версионирование. Все секреты хранятся в виде файлов, шифруются через GPG и версионируются в Git. Вы можете держать их локально, синхронизировать через любой git-ремоут (GitHub, GitLab, собственный сервер) и при этом всегда иметь историю изменений.

Рабочий цикл выглядит консольно и привычно для разработчиков. Из терминала вы листаете хранилище командой gopass ls, смотрите конкретный пароль через gopass show, генерируете новый — gopass generate. Копирование в буфер обмена тоже работает из командной строки, что удобно для скриптов и автоматизации.

Поверх базовой функциональности есть плагины:

• gopass-bridge — интеграция с браузером. Позволяет автоматически заполнять формы входа без копирования паролей вручную.
• Помощь с Git-кредами. gopass может выступать credential helper для Git, так что пароли от репозиториев тоже хранятся зашифрованными и версионируются.
• Проверка через Have I Been Pwned. Можно проверить, не утекли ли ваши пароли в публичные базы.

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

gopass написан на Go, поэтому работает на macOS, Linux и Windows без дополнительных зависимостей. Настройка сводится к созданию git-репозитория с зашифрованными файлами и клонированию его на рабочие машины. Один репозиторий — доступ с любого устройства.

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

Self-hosted SSH-клиент: Termix

Termix — полностью опенсорсная и self-hosted альтернатива Termius для управления серверами по SSH через единый веб-интерфейс. Разворачивается в Docker как бэкенд, синхронизируется с клиентами под веб, Windows, Linux, macOS, iOS и Android.

Ключевые возможности:

• SSH-терминал с вкладками и сплитами. Можно открыть до 4 панелей одновременно, переключаться между сессиями, кастомизировать тему оформления и шрифты. Всё работает через браузер или нативное приложение.
• SSH-туннели с автопереподключением. Настраиваете туннель один раз, система сама восстанавливает соединение при обрывах и отслеживает состояние туннелей в реальном времени.
• Файловый менеджер поверх SSH. Можно просматривать и редактировать код прямо в интерфейсе, смотреть картинки, слушать аудио, проигрывать видео, загружать и выгружать файлы, выполнять операции копирования, перемещения, удаления — всё без отдельного SFTP-клиента.
• Менеджер хостов. Организация серверов по тегам и папкам, автоматическая заливка SSH-ключей на хосты, безопасное хранение логинов и паролей в зашифрованной базе.
• Мониторинг. Для любого подключённого сервера можно посмотреть загрузку CPU, память, диск, сеть, аптайм и системную информацию. Есть дашборд с общим обзором по всем хостам.

Под капотом: веб-клиент собран на React + Tailwind + Shadcn, бэкенд работает с зашифрованной базой SQLite, автоматическая настройка SSL-сертификатов, вход через OIDC и двухфакторная аутентификация (TOTP). Интерфейс поддерживает несколько языков.

Проект распространяется под Apache 2.0. Основной способ установки — docker-compose с томом для данных, всё настраивается за пару минут. Для десктопа и мобильных устройств доступны нативные сборки и приложения в официальных сторах под все основные платформы.

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

TUI-клиент для торрентов: Torrra v2

Torrra — TUI-клиент для поиска и скачивания торрентов прямо из консоли, без браузера и без отдельного GUI-приложения. Написан на Python, интерфейс собран на библиотеке Textual, так что всё выглядит аккуратно и отзывчиво даже в терминале.

Можно подключаться к своим индексаторам Jackett или Prowlarr, смотреть результаты поиска и выбирать, чем качать. Есть два режима: через встроенный движок на базе libtorrent или передать magnet-ссылку во внешний торрент-клиент (Transmission, qBittorrent и так далее).

Автор утверждает, что во второй версии серьёзно ускорил UI, улучшил навигацию по спискам, прокачал поиск и добавил возможность работы с несколькими торрентами одновременно. Плюс почистил интеграцию с индексаторами и отполировал раскладку интерфейса — теперь всё помещается в стандартное окно терминала без скроллинга.

Установить можно несколькими способами:

• Через pipx: pipx install torrra
• Из AUR для пользователей Arch Linux
• Через Homebrew на macOS
• Docker-образ для изолированного запуска
• Готовые бинарники под Linux, macOS и Windows

После установки минимальный сценарий работы такой: поднимаете Jackett или Prowlarr (это отдельные сервисы для агрегации торрент-индексаторов), запускаете

Дальше стрелками ходите по списку результатов, Enter — начать скачивание, p — пауза, r — продолжить, q — выйти из программы.

Поведение можно подкрутить через файл config.toml: задать дефолтные индексаторы, пути для сохранения файлов, какие клиенты использовать для загрузки, чтобы каждый раз не вбивать одно и то же в аргументах командной строки.

Проект кроссплатформенный (Linux/macOS/Windows) и активно развивается: есть подробная документация, регулярные релизы, автор отвечает на issues. Код в репозитории, на видео можно посмотреть демонстрацию работы.

Защита от подглядывания: EyesOff для macOS

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

Написано на Python + PyQt, модель распознавания лиц крутится локально на вашем Mac — ничего не уходит в облако, никакие кадры не сохраняются. Есть три режима оповещения на выбор:

• Попап на экране — появляется окно с предупреждением, что кто-то смотрит.
• Системная нотификация — более деликатный вариант, уведомление в углу экрана.
• Автозапуск приложения — можно настроить, чтобы автоматически запускалась блокировка экрана или любое другое приложение.

Автор написал подробный разбор того, как тренировал модель детекции. Интересный момент: он оптимизировал accuracy не в среднем по всем дистанциям, а конкретно для mid-range (~1-2 метра) — именно там обычно стоят любопытные коллеги. На близких дистанциях (менее метра) и дальних (более трёх метров) точность может быть ниже, но это компромисс ради производительности и практичности.

Есть одно ограничение: приложение пока детектит просто наличие лиц в кадре, а не направление взгляда. То есть если человек в кадре, но смотрит в сторону или на свой телефон, EyesOff всё равно сработает. Автор обещает доработать определение направления взгляда в следующих версиях, но для большинства сценариев текущей логики достаточно.

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

Все пять инструментов объединяет один принцип: контроль над своими данными. Вы не зависите от подписок, облачных сервисов или закрытых платформ. Каждый из них решает конкретную задачу, делает это хорошо и не требует доверять кому-то свои пароли, SSH-ключи или видео с камеры. Код открыт, можно проверить, как всё устроено, и при желании — доработать под свои нужды.

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

Почему владение Django — не предел для разработчика

Особенности Django

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

Основные плюсы:

• Полноценный стек: ORM для работы с базой, мощная система маршрутизации URL, шаблоны для рендеринга, встроенная админка, формы, система аутентификации и авторизации.
• Архитектура MTV (Model-Template-View): похожа на классический MVC, но с особенностями, которые упрощают разделение логики, представления и данных.
• Безопасность: Django автоматически защищает от CSRF, XSS, SQL-инъекций и других распространенных атак. Не нужно писать много дополнительного кода.
• Активное сообщество и экосистема: тысячи сторонних пакетов, расширений и готовых решений.
• Поддержка нескольких баз данных: PostgreSQL, MySQL, SQLite, Oracle и др.

Ограничения:

• Синхронная природа Django.
• Монолитность: архитектура фреймворка ориентирована на создание крупных приложений, но в микросервисах может быть избыточна.
• Ограниченная гибкость ORM: нестандартные SQL-запросы иногда сложно выразить средствами ORM, приходится использовать raw SQL или сторонние библиотеки для запросов.
• Строгие правила организации кода: требуют дисциплины и могут ограничивать свободу в архитектурных решениях.
• Недостаточная производительность: уступает лёгким асинхронным фреймворкам (например, FastAPI), особенно под высокими нагрузками. Но для большинства проектов пока это не критично.

В каком направлении двигаться после изучения Django

Задача — создавать продукт, который будет нужен конечному потребителю.

Первое направление для развития — расширить инструментарий для решения разных задач в веб-разработке

Возможные пути:

• Изучить другие веб-фреймворки (Flask, FastAPI)
• Углубиться в асинхронное программирование (asyncio, aiohttp)
• Работать с API и микросервисами

Flask и FastAPI

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

FastAPI — современный асинхронный фреймворк, ориентирован на создание высокопроизводительных API. Поддерживает стандарт OpenAPI и автоматическую генерацию документации. Он быстрее Flask и Django благодаря asyncio и Pydantic.

Асинхронное программирование

Веб-разработка всё активнее использует асинхронные технологии. Django не всегда справляется с задачами высокой конкурентной нагрузки.

Поэтому изучение asyncio — стандартной библиотеки Python для асинхронного программирования — откроет перед вами новые возможности. Вместе с aiohttp или тем же FastAPI вы сможете создавать приложения, которые обрабатывают тысячи одновременных соединений. Это особенно важно для real-time сервисов, чат-приложений и систем с интенсивным обменом данными.

Второе направление — расширить навыки в смежных областях

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

Изучение DevOps и контейнеризации

Контейнеры позволяют запускать приложения в изолированной среде, это упрощает настройку и развертывание. Например, Docker помогает упаковать приложение с зависимостями в один контейнер, а Kubernetes — управлять такими контейнерами в продакшене. Знание этих технологий улучшит взаимодействие с операционной командой и ускорит выпуск новых версий приложений.

CI/CD и автоматизация процессов

Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment) — ключевые практики современной разработки ПО. Они позволяют автоматизировать сборку, тестирование и доставку приложений, масштабировать процессы.

Инструменты CI/CD (например, Jenkins, GitLab CI/CD, GitHub Actions) помогают настроить автоматические пайплайны, которые обеспечивают быструю обратную связь и минимизируют человеческий фактор в релизах. Автоматизация процессов снижает количество ошибок и позволяет сосредоточиться на разработке новых функций.

Настройка непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery) снижает поток ошибок при релизах и экономит время. Пример: GitHub Actions для автоматического запуска тестов и сборки проекта при каждом коммите.

Больше знаний в области баз данных

Помимо классических реляционных баз данных (PostgreSQL, MySQL), современные приложения часто используют NoSQL для специфичных задач. MongoDB, Redis, Cassandra обеспечивают гибкость в хранении данных, горизонтальное масштабирование и высокую производительность при работе с большими объемами информации.

Графовые базы данных (Neo4j, ArangoDB) предназначены для эффективного хранения и анализа связей между объектами, что важно для социальных сетей, рекомендательных систем и других приложений с богатой структурой.

Так, Redis хорошо подходит для кэширования данных, а Neo4j — для сложных связей между объектами.

Третье направление — переход к другим аспектам Python-разработки

Рассмотрим четыре варианта карьерного развития для Python-программиста: Data Science и машинное обучение, автоматизация бизнес-процессов, разработка десктопных приложений и встраиваемые системы (IoT).

Почему стоит попробовать?

• Высокий спрос на специалистов. Они востребованы в банках и инвестиционных компаниях, в сфере медицины и биотехнологии, в консалтинге, автомобильной промышленности и т.д..
• Широкий набор библиотек: pandas, NumPy, scikit-learn, TensorFlow, PyTorch.
• Возможность работать с реальными задачами: от бизнеса до науки.

Автоматизация и скрипты для бизнеса

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

Знание таких библиотек, как openpyxl (работа с Excel), requests (HTTP-запросы), BeautifulSoup и Scrapy (парсинг веб-страниц), а также умение писать скрипты под конкретные задачи, делают разработчика ценным специалистом в корпоративной среде.

Примеры задач:

• Автоматическая загрузка данных из Excel и их преобразование
• Скрипты для отправки email-рассылок
• Интеграция с CRM и другими сервисами через API

Разработка десктопных приложений (PyQt, Kivy)

Хотя сейчас популярность уходит к вебу и мобильным платформам, десктопные приложения на Python востребованы в таких сферах: инструменты для анализа, редакторы, утилиты.

Инструменты для создания:

• PyQt — мощный фреймворк для создания кроссплатформенных GUI.
• Kivy — библиотека для разработки приложений с поддержкой сенсорных экранов.

Этот путь подходит тем, кто хочет создавать удобные инструменты с графическим интерфейсом для пользователей на Windows, macOS или Linux.

Встраиваемые системы и IoT

В области IoT и встроенных систем Python набирает популярность благодаря легкости освоения и поддержке на маломощных устройствах. Помогают в этом платформы по типу Raspberry Pi и MicroPython.

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

Например, с помощью Python на Raspberry Pi можно разрабатывать датчики для мониторинга состояния оборудования на производстве и разрабатывать прототипы носимых устройств для сбора данных о здоровье.

Если рассматривать профессию “Python-разработчик на Django”, то сразу получится сужение до конкретной библиотеки на конкретном языке. Если же в резюме у специалиста стоит, что он “разработчик Python”, возможностей сильно больше. Если написать про себя “разработчик”, будет не понятно, разработчик чего. Но изменив резюме на “DevOps инженера”, становится понятен карьерный трек.

1. Pandas

Pandas — библиотека для работы с данными в Python, позволяющая легко загружать, анализировать, очищать и преобразовывать числовую информацию в удобной табличной форме. По сути, это Excel, который смог, и позволяет делать всё автоматизировано и на порядки быстрее.

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

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

Почему это меняет карьеру

Работа с Pandas становится границей между знанием Python и умением решать задачи бизнеса. Для джуна это шанс сразу показать практическую пользу: выгрузки, отчёты и базовый анализ можно делать в десятки раз быстрее и аккуратнее, чем вручную в эксельке.

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

Для ML-инженера владеть Pandas — значит уметь готовить датасеты качественно; быстро очищать и приводить данные к нужному виду, что напрямую влияет на результат моделей. Без этого работа над проектами машинного обучения часто превращается в бесконечную возню с данными.

Наконец, даже для разработчиков Pandas может стать неожиданным бустом в карьере. Например, когда нужно автоматизировать отчёты для бизнеса или быстро анализировать логи и данные из БД без поднятия дашбордов — Pandas даёт гибкость и скорость, которые редко даёт что-то ещё в экосистеме Python.

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

Django подходит как стартапам, которым нужно быстро выйти на рынок, так и крупным проектам с миллионами пользователей. Это не просто библиотека, а полноценный каркас для построения и сопровождения веб-сервисов.

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

Django позволяет сосредоточиться на бизнес-логике и продукте, не тратить недели на настройку инфраструктуры.

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

Сегодня PyTorch используется в продакшен системах, научных исследованиях, компьютерном зрении, NLP и генеративных моделях, занимая ведущее место в индустрии.

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

PyTorch — билет в мир современной разработки AI и машинного обучения. Владение инструментом даёт разработчику возможность уверенно войти в области, которые продолжают оставаться топовыми на рынке: искусственный интеллект, компьютерное зрение, NLP, генерация изображений и видео и т.д.

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

PyTorch в целом помогает расширять портфолио: с ним можно создавать генеративные модели, строить LLM, участвовать в соревнованиях и работать с самыми современными подходами в машинном обучении.

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

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

Для дата-инженеров Polars полезен при построении ETL и пайплайнов обработки данных, где важна скорость и предсказуемое потребление ресурсов. Его можно использовать в продакшен-скриптах, для подготовки данных к ML и для автоматизации отчётности.

Для дата-сайентистов Polars даёт возможность анализировать больше данных за меньшее время, быстро итерировать гипотезы и ускорять исследования. Его API достаточно близок к Pandas, поэтому переход не требует месяцев переучивания.

Освоение Polars показывает работодателям, что ты не просто знаешь стандартные инструменты, но умеешь выбирать оптимальные решения для реальных задач, повышая эффективность работы команды. В эпоху роста данных это критично для любого Python-разработчика, работающего с аналитикой и машинным обучением.

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

Вместо долгой настройки, как у Flask или Django, в FastAPI многое готово изначально: удобная работа с запросами и ответами, декларативная валидация, документация Swagger, асинхронность и высокая производительность без лишних усилий.

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

Для ML-специалиста FastAPI становится инструментом для деплоя моделей: можно обернуть пайплайн предсказаний в API, подключить авторизацию или логирование и получить работающий сервис за считанные дни.

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

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

Typer меняет карьеру тем, что открывает путь к созданию удобных CLI-инструментов, которые автоматизируют рутину и повышают продуктивность.

С Typer можно быстро превращать свои Python-скрипты в надежные утилиты, которыми удобно пользоваться и другим разработчикам, и сотрудникам из других отделов. CLI-приложения часто становятся клеем инфраструктуры: они позволяют автоматизировать деплой, миграции БД, сбор данных, интеграцию с внешними API и локальную разработку.

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

Кроме того, работа с Typer улучшает навык структурирования кода, понимание CLI, использования type hints и разработки инструментов, которые делают работу проще для других. А это, очевидно, ценится в любой команде и повышает востребованность специалиста.

7. Rich

Rich — библиотека Python для красивого форматирования и интерактивного отображения информации в терминале. С её помощью можно выводить цветные таблицы, маркдаун, прогресс-бары, подсвеченный синтаксис кода, деревья каталогов и логирование в понятной и привлекательной форме.

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

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

Почему это меняет карьеру

Rich — это библиотека, которая помогает быстро повысить качество любого CLI-инструмента или дев-опыт в команде. Разработчик, который использует Rich, делает свои инструменты удобными не только для себя, но и для коллег: логирование становится понятным, а отладка скриптов — наглядной.

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

Кроме того, Rich позволяет быстро создавать CLI-интерфейсы, которые выглядят как продакшен-продукты, даже если это внутренние инструменты. Руководство будет радоваться и думать о вас как о крутом разрабе.

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

LangChain предоставляет удобный слой абстракции над вызовами LLM и ускоряет разработку чат-ботов, RAG-приложений, агентов с инструментами, систем анализа документов и других AI-сервисов.

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

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

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

Работа с LangChain погружает в практическую LLM-инженерию: вы начинаете создавать RAG-приложения, которые умеют искать и анализировать данные перед генерацией ответа и строить агентов. Это востребовано в продуктах, где нужно подключать ИИ к базам знаний, автоматизировать задачи и разрабатывать интерактивные системы, которые реально используют модели в продакшене.

LangChain позволяет быстро собирать и запускать MVP AI-продуктов, что дает конкурентное преимущество при создании стартапов или внутренних сервисов. А ещё учит мыслить структурами и проектировать масштабируемую архитектуру LLM-приложений и видеть, как генеративный ИИ можно превратить в рабочий инструмент.

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

Создадим минимальный пример для SQLite с таблицей пользователей:

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

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

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

Seaborn — библиотека для визуализации данных на Python, построенная поверх Matplotlib и упрощающая создание информативных и стильных графиков с минимальным количеством кода.

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

Библиотека тесно интегрируется с Pandas DataFrame, позволяя использовать колонки данных напрямую для построения графиков, что делает её идеальной для EDA (разведочного анализа данных) и подготовки визуализаций для отчётов и презентаций.

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

В три строки мы получаем чистый и читаемый ящик с усами, показывающий, как счет за ужин распределяется по дням недели.

Для построения более сложных графиков можно использовать диаграмму рассеяния:

Тут мы добавляем цветовую кодировку по полу, чтобы увидеть зависимости между переменными.

Почему это меняет карьеру

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

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

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

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

Больше новостей — в нашем тг-канале Представляешь

Что такое n8n

Рост использования ИИ в рутине разработки, маркетинга и бизнеса приводит к потребности в простых и гибких инструментах, которые позволяют быстро соединять модели, API и данные в работающие пайплайны. Каталог n8n даёт инженерам и продуктовым командам фору: можно за день собрать MVP своего ассистента или системы автоматизации, сократив месяцы разработки.

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

На данный момент на сайте доступно:

• 457 простых пайплайнов для новичков;
• 1349 пайплайнов среднего уровня сложности;
• 1440 продвинутых решений для профессионалов и команд автоматизации.

Каждый агент сопровождается документацией, описанием кейсов использования и рекомендациями по настройке. Также обновляется для совместимости с последними версиями n8n.

Запуск агента в n8n обычно занимает несколько минут:

1. Вы выбираете нужный шаблон из каталога (например, автоматический парсинг HackerNews с публикацией в Telegram, автоматическую вёрстку в Notion, управление AWS-ключами через Slack или генерацию отчётов с помощью Claude).
2. Импортируете шаблон в свою среду n8n (SaaS или локально). Настраиваете ключи API или доступ к нужным сервисам (Telegram, Notion, Discord, AWS, HubSpot и др.).
3. Запускаете и получаете работающий агент, готовый к эксплуатации без написания кода.
4. Все процессы визуализированы, поэтому можно легко редактировать логику работы, добавлять свои шаги (например, постобработку с помощью GPT, уведомления в Slack или отправку в CRM) и адаптировать агента под свои задачи.

Какие задачи можно автоматизировать

В каталоге есть ИИ-агенты и пайплайны для:

• SMM и маркетинга (сбор лидов, управление постингом, аналитика трендов);
• Кибербезопасности (мониторинг SSL, автоматические алерты, управление ключами AWS);
• Разработки (поддержка TypeScript Intellisense, автоматизация CI/CD);
• Продуктивности (сбор и структурирование заметок в Notion, автоматизация писем, напоминания);
• Исследований (поиск и структурирование данных с помощью ИИ, генерация дайджестов);
• Дизайна (подготовка медиафайлов и управление рабочими процессами);
• Продаж и клиентского сервиса (онбординг клиентов, автоматические уведомления и CRM-интеграции).

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

Что есть для разработчиков

n8n остаётся платформой с открытым исходным кодом, поэтому разработчики могут:

• Клонировать и адаптировать любые из 3200+ рабочих процессов под свои нужды.
• Интегрировать LLM (GPT-4o, Claude, Gemini) для создания сложных агентов с мультимодальными возможностями.
• Выстраивать корпоративные пайплайны и автоматизированные рабочие места для команд.
• Подключать плагины и собственные ноды для кастомных сценариев.
• Запускать пайплайны локально или в облаке, сохраняя контроль над данными.

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

Может плодить новые эндпоинты или заставлять мобилку делать несколько запросов вместо одного? Каждый запрос жрёт трафик и батарею!

Элегантное решение — архитектура Backend for Frontend (BFF). Это прослойка между клиентскими приложениями и основным API, которая адаптирует данные под потребности конкретного клиента.

Основная идея backend for frontend

Один API не может эффективно обслуживать разные типы клиентов. Сайт, приложение для iOS, Android, умные часы — у каждого свои потребности в данных, ограничения по производительности и особенности интерфейса.

Монолитный API создают с расчётом на универсальность — на практике это приводит к компромиссам. Веб-версии нужны данные для сортировки, мобильному приложению — минимальный набор для экономии трафика.

Следуя архитектуре BFF, вы можете создать логику для каждого типа клиента и не засорять основной API. Вместо одного эндпоинта /api/products, который пытается угодить всем, появляются слои:

• один — оптимизирует данные для веба,
• второй — для мобильных устройств,
• третий — для умных часов.

Обычно данные приходят в неудобном виде: несколько связанных сущностей нужно запрашивать отдельно и склеивать на клиенте. BFF берёт эту работу на себя.

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

Каждый клиент получает данные в том виде, в котором может их сразу отобразить. Вместо загрузки 50 полей, из которых используется 5, BFF отдаёт только нужные данные.

«Можете добавить поле user_avatar в ответ?»

— «Это сломает мобилку».

«Тогда сделайте отдельный эндпоинт».

— «У нас нет времени».

С BFF этого диалога нет. Фронтенд-команда получает свой API и крутит его, как хочет.

Мобильное приложение съедает 10к запросов в секунду? Пишите BFF на Go. Веб-версию делает стажёр, который знает только JavaScript? Ставьте Node.js. Никто не заставляет выбирать одну технологию на все случаи жизни.

Как работает backend for frontend (BFF)

BFF размещается между клиентскими приложениями и основными бэкенд-сервисами, выполняя роль посредника. В отличие от API Gateway, который просто перенаправляет запросы, BFF трансформирует данные.

Архитектура взаимодействия

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

Когда мобильное приложение запрашивает список заказов, его BFF делает несколько вызовов к микросервисам:

• берёт базовую информацию о заказах,
• подтягивает данные о товарах,
• получает статусы доставки.

Затем склеивает всё в один ответ, отбрасывая ненужные поля и добавляя вычисляемые значения.

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

Обработка и агрегация данных

BFF не просто перекладывает данные из одного формата в другой. Он выполняет бизнес-логику.

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

Если API возвращает цены в центах, мобильный BFF конвертирует их в рубли и округляет для отображения. Веб-версия получает точные значения с копейками для расчётов.

Независимость и масштабирование

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

4 ключевых преимущества BFF

Оптимизация передачи данных

Самое очевидное преимущество — экономия трафика. Приложение не тащит 2 МБ JSON с полным каталогом товаров на мобильное устройство? BFF отдаёт только нужные поля.

Количество запросов тоже сокращается. Например, чтобы показать профиль пользователя, фронтенд делает 5 запросов:

• за основными данными,
• аватаром,
• списком друзей,
• последними постами,
• настройками приватности.

BFF объединяет всё в один запрос, получая данные параллельно от разных сервисов.

Упрощение фронтенда

Половина фронтенд-кода уходит на трансформацию ответов API:

• парсинг дат,
• группировку массивов,
• вычисление производных значений.

BFF может взять эту работу на себя.

Безопасность через изоляцию

BFF создаёт барьер между клиентами и сервисами. Мобильное приложение никогда напрямую не обращается к БД пользователей или платёжке — только через свой BFF.

Можно настроить разные уровни доступа:

• мобильный BFF видит только публичные данные,
• API для партнёров работает в песочнице.

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

Независимое масштабирование

Когда приложение попадает в топ App Store, нагрузка взлетает в разы. Но страдает только мобильный BFF — веб-версия продолжает работать стабильно. Можно быстро поднять дополнительные серверы только для мобильного трафика.

Появляется возможность экспериментировать с технологиями без риска. Хотите попробовать GraphQL для веб-версии? Внедряйте в один BFF. Тестируете новую базу данных? Подключайте к экспериментальной прослойке, не трогая продакшн.

Когда стоит использовать backend for frontend

BFF — инструмент для конкретных ситуаций.

Когда интерфейсы кардинально отличаются

Если ловите себя на мысли: «этот эндпоинт нужен только для веба» или «мобилка использует 10% полей из ответа», — пора задуматься о BFF.

Красный флаг — когда фронтенд-разработчики начинают писать костыли для обработки «неудобных» данных. Если половина JavaScript-кода занимается парсингом и трансформацией ответов API, что-то пошло не так.

Когда интерфейсы эволюционируют быстрее джунов

Стартапы и продукты в активной фазе развития меняют интерфейсы каждую неделю.

Классическая проблема: дизайнеры придумали новый способ отображения товаров в каталоге. Теперь нужны дополнительные поля, другая группировка, новые фильтры.

Без BFF это означает изменения в основном API, которые могут сломать другие клиенты. С BFF — правки только в одном месте.

Когда команды работают независимо

Если у вас несколько фронтенд-команд, которые постоянно конфликтуют из-за API, BFF даст им свободу.

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

BFF распределяет ответственность: каждая команда поддерживает свой слой.

Когда НЕ стоит использовать BFF

Если у вас простое приложение с одним клиентом, BFF добавит лишнюю сложность. Если API уже идеально подходит всем клиентам, зачем что-то менять?

3 типичные ошибки при внедрении BFF

Дублирование логики

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

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

Избыточная сложность вместо упрощения

Пример: команда создаёт «универсальный BFF-фреймворк» с конфигурацией через YAML, поддержкой плагинов и собственным DSL. В итоге простое добавление поля в ответ требует изучения документации на 50 страниц.

Другая крайность — микро-BFF для каждой мелочи. Отдельный слой для авторизации, отдельный для форматирования дат, отдельный для валидации.

Неправильная гранулярность

Один BFF на все мобильные платформы может быть слишком общим: iOS и Android имеют разные особенности интерфейса. Но отдельный BFF для каждой версии приложения — явный перебор.

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

Практические примеры использования BFF

Netflix

Компания сделала разные API для веб-версии, мобильных приложений, Smart TV и игровых консолей. Каждый BFF оптимизирован под особенности устройства, например, TV-версия предзагружает больше контента из-за медленной навигации пультом.

Spotify

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

SoundCloud

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

Заключение

Страдают все, когда один API пытается обслуживать веб-версию, мобилки и что-то ещё. Фронтенд получает неудобные данные, бэкенд обрастает костылями, пользователи — медленными приложениями.

Backend for Frontend создаёт слой между клиентами и основными сервисами. Каждый тип устройства получает API, заточенный под его потребности.

Внедряйте BFF, когда интерфейсы кардинально отличаются, продукт быстро развивается, а текущий API снижает производительность.

Ты уже программист, если читаешь это! Больше про кодинг — здесь.

Почему «тормоза» — это не всегда про код

Когда пользователь жалуется на «медленное приложение», большинство разработчиков по привычке лезет в код. Профилируем, ищем неэффективные циклы, оптимизируем до запятых. Но в реальности причина часто не в логике, а в том, что её окружает.

Современное приложение — это сложный организм: десятки микросервисов, базы данных, кэши, брокеры, сети. И тормозить может любой из этих компонентов. А ты в это время профилируешь ни в чём не виноватый for.

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

Многие из них — не баги, а последствия архитектурных решений. В дев-среде всё летает, потому что:

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

Слои архитектуры и где в них зарыты проблемы

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

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

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

• Непрозрачная маршрутизация — скрытые таймауты, ошибки ретраев.
• Сборка ответов из микросервисов — цепочка из 5 вызовов на каждый клиентский запрос.
• Синхронные вызовы без деградации — если один микросервис недоступен, падает весь endpoint.

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

• Кэш не промахивается, но и не помогает — stale данные, повторные чтения, инвалидация не работают, как ожидалось.

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

Оптимизация кода важна. Но если система тормозит, искать нужно по всей цепочке — от кнопки на фронте до брокера в соседнем дата-центре.

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

Типичная ситуация: в таблицу пишут JSONB без нормализации и индексов. Пока строк мало — жить можно. Но при росте объёмов каждый запрос превращается в медленное последовательное чтение. Это не просто «долго», а начинает мешать соседним транзакциям: подгружаются stale данные, вытесняется кэш, система начинает проседать вся — вплоть до API.

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

Архитектура доступа к данным: как закладываются тормоза

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

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

• Очередь перегружена, и событие просто стоит в хвосте.
• Обработчик падает или рестартится, и событие ждёт.
• Политики повторной обработки не настроены — событие крутится бесконечно.
• Слишком много этапов внутри одного воркера: валидация, запись в БД, вызов API — всё это задержки, которые суммируются.

Что происходит, когда очередь переполнена — и почему это тяжело заметить

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

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

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

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

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

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

Если таких вызовов много, задержка накапливается каскадом.

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

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

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

Иногда архитекторы увлекаются и дробят сервисы до абсурда. Начинается с «давайте переиспользуем», а заканчивается 10 API-вызовами ради одного действия.

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

Кэш традиционно считается палочкой-выручалочкой для производительности. «Добавим кэш — и всё полетит», — думают команды, особенно под нагрузкой. Но в реальности кэш может не только не ускорить, но и наоборот — замедлить или даже уронить систему, если использовать его без понимания.

Вот несколько типичных ошибок, которые приводят к деградации производительности:

Невалидные или слишком агрессивные стратегии

Если кэш живёт слишком долго — пользователи получают устаревшие данные. Если обновляется слишком часто — создаются лишняя нагрузка на базу и почти постоянные «промахи».

А если кэш сбрасывается при каждом изменении, он вообще не успевает выполнять свою роль. В итоге: нестабильное поведение, непредсказуемая производительность и раздражённые пользователи.

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

• работают на одной машине без шардинга;
• содержат тяжёлые объекты;
• используются как универсальный ответ на все проблемы.

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

Кэш-миссы и лавины запросов

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

Вместо одного запроса вы получаете 10 000, и тормозит всё. Особенно критично это для систем с CDN, где внезапное истечение кэша популярных страниц может вызвать DDoS-подобную нагрузку.

Несогласованность кэшей

Если в системе несколько уровней кэширования (CDN, фронтовый кэш, Redis) и они обновляются по-разному, возникает несогласованность. Один пользователь видит новые данные, другой — старые. Один сервис работает с актуальной версией, другой — с устаревшей. Начинается охота за фантомами: баги вроде есть, но не у всех.

Вычисления и память: что не так с аллокацией

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

Частые и крупные аллокации

Каждый раз, когда создаётся новый объект, память выделяется из кучи. При интенсивной работе (например, при парсинге JSON или обработке больших структур) это может происходить слишком часто, и тогда запускается сборщик мусора (GC).

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

• очередь задач не может масштабироваться под нагрузку.

В таких случаях нагрузка растёт, а пропускная способность — нет. Всё упирается в искусственное ограничение, введённое «на всякий случай».

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

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

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

• Когда проявляется проблема: под нагрузкой, в пиковые часы, у конкретных пользователей?
• Что именно работает медленно: API, отчёты, фоновая обработка?
• Как это влияет на систему: задержки, таймауты, ошибки?

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

Так можно увидеть, что, например, сторонний сервис отвечает 3 секунды, или Redis стал отдавать ответ за 300 мс вместо обычных 3 мс.

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

После подтверждения проблемы можно переходить к исправлениям:

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

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

Итоги: как не попасть в архитектурную ловушку

Bottleneck’и возникают даже в самых технологичных проектах. Это не всегда следствие «плохого кода» — куда чаще они появляются из-за архитектурных просчётов: недооценили нагрузку, не предусмотрели масштабирование, сделали ставку на неправильное решение.

Главная проблема в том, что узкие места проявляются не сразу, а под нагрузкой. В разработке и тестах всё летает, потому что ресурсов хватает. А вот в проде — особенно при росте аудитории — на поверхность всплывает всё, что не выдерживает реального объёма данных или конкуренции за ресурсы.

Чтобы избежать таких проблем, важно не просто писать чистый код, а мыслить системно: проектировать архитектуру так, чтобы она могла жить под давлением. Вот несколько принципов, которые помогут.

Думайте об объёмах и росте

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

Настраивайте метрики с первого дня

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

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

Не усложняйте архитектуру без повода

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

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

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

В этой статье мы соберём микросервис, который будет в реальном времени анализировать предложения и подсказывать, где выгоднее обменять криптовалюту. Да, руками. Да, с нуля. Да, с кодом. Без лишней теории — только практика, понятная каждому, кто хоть раз писал бэкенд или работал с API.

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

Архитектура сервиса: что мы вообще собираем

Идея простая: у нас есть десятки криптообменников, у каждого — свои курсы, комиссии и условия. Ручной перебор — не вариант. Значит, нужен сервис, который по заданным параметрам сам найдёт лучший вариант обмена и покажет его тебе в удобном виде.

Что должно быть на выходе: ты передаёшь в сервис, например: «Хочу обменять криптовалюту USDT на рубли через банковскую карту», а он тебе в ответ: «Вот три предложения, сортированы по выгоде и надёжности. Если хочешь, сервис может ещё и отправить тебе уведомление, когда курс станет подходящим».

Как это устроено:

1. Источник данных
   Нам нужно получать актуальные курсы с разных платформ. Желательно не писать свои парсеры для каждого сайта — у многих официальных криптообменников есть открытые API. Ещё лучше — использовать агрегатор, который уже всё это собирает.
2. Фильтрация и логика выбора
   Не каждый обменник подходит. У кого-то нет вывода на карту, у кого-то курс хороший, но комиссия грабительская. Придётся учитывать кучу параметров: тип валюты, доступность в России, платёжные методы, лимиты.
3. Простая точка входа
   Это может быть консольный скрипт, API, веб-интерфейс или даже Telegram-бот. Главное — чтобы ты мог быстро получить ответ на вопрос: «Где сейчас выгоднее обменять крипту?»
4. Автоматизация
   Желательно, чтобы всё это работало без участия человека. В идеале — ты один раз настраиваешь фильтры, и дальше сервис сам мониторит ситуацию. Хочешь — получаешь пуш, хочешь — просто заходишь и смотришь.

Где брать данные: API-агрегаторы против самописного парсинга

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

Во-первых, многие обменники вообще не отдают данные в открытом виде. У кого-то нет API, у кого-то курс виден только после логина или выбора платёжки. У кого-то защита от ботов, редиректы, капчи, анти-DDoS и прочие радости.

Во-вторых, даже если ты спарсишь курс — он почти всегда будет «в вакууме»: без учёта комиссии, ограничения по сумме, или без указания, что это только для новых клиентов. А значит, ты получаешь данные, на которые нельзя опираться.

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

Что делать? Использовать API-агрегаторы. Это такие сервисы, которые уже собрали десятки официальных криптообменников, следят за их курсами, учитывают комиссии, доступность и форматируют данные в единый стандарт.

Такие агрегаторы обычно дают:

• нормальное API без сюрпризов;
• актуальные курсы в реальном времени;
• фильтры по валютам, платёжкам, регионам (например, только криптообменники в России);
• возможность видеть, кто работает с наличкой, кто с банками, кто вообще жив.

Если ты хочешь не просто поиграться, а сделать рабочий инструмент — парсить вручную точно не стоит. Слишком много сил, а результат — нестабильный. Лучше взять нормальный источник и потратить время на логику фильтрации и вывод.

Быстрый старт: пишем простейший клиент на Python

Допустим, ты решил сам посмотреть, где сейчас можно обменять криптовалюту. Мы уже договорились, что не будем парсить сайты руками — берём агрегатор с открытым API, например, Exnode или любой другой, у кого адекватная документация.

Цель на этом этапе — получить список обменников с курсами и отфильтровать, где реально выгодно обменять крипту на нужную тебе валюту, скажем, на рубли.

Простейший скрипт на Python может выглядеть так:

Что тут происходит:

• мы запрашиваем курс обмена с USDT на рубли;
• получаем список предложений от разных криптообменников;
• выводим курс и комиссию.

На этом этапе ты уже можешь видеть, где выгоднее обменять криптовалюту на рубли, а где предложение так себе. Причём это только базовый пример — можно легко докрутить фильтры по платёжной системе (например, карты Тинькофф или Сбера), включить данные по лимитам, скорости и надёжности обменника.

Данные от агрегаторов — это по сути твоя опорная точка. Уже с них можно построить более сложную логику, подключить автослежение или выдачу в бота.

Фильтрация и выбор лучшего обменника

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

1. Учет комиссий

Курс обмена может быть привлекательным, но скрытые комиссии способны существенно снизить выгоду от сделки. Поэтому необходимо учитывать общую сумму, которую вы получите после всех вычетов. Например, обменник может предлагать курс 100 рублей за USDT, но с комиссией 2%, в то время как другой предлагает 98 рублей без комиссии. В таком случае второй вариант может быть более выгодным.

2. Способы вывода средств

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

3. Надежность и репутация

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

4. Географическая доступность

Если вы предпочитаете офлайн-обмен, важно учитывать расположение офисов обменника. Например, такие обменники, как Insight, BitOkk и EastChange, имеют офисы в Москве и других крупных городах России, что делает их удобными для личного посещения.

5. Примеры обменников

Рассмотрим кратко три популярных обменника:

• Insight: Предлагает низкие комиссии, быстрый обмен и поддержку различных криптовалют. Имеет офисы в Москве и Санкт-Петербурге.
• BitOkk: Известен широким выбором криптовалют и высокой скоростью обслуживания. Предлагает выгодные курсы и работает без верификации для небольших сумм.
• EastChange: Специализируется на обмене USDT и крупных сделках. Предлагает фиксированный курс на 1 час и возможность онлайн-бронирования суммы перед визитом.

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

UI или бот? Мини-фронт на Flask или уведомления в Telegram

Когда у тебя уже есть рабочая логика и ты получаешь актуальные курсы от надежных криптообменников, возникает вопрос: как этим всем пользоваться? Вариантов два — делать фронт или завести простого Telegram-бота.

Вариант 1: веб-интерфейс на Flask

Если хочется что-то визуальное, можно быстро собрать минималистичный фронт на Flask. Это буквально 20–30 строк кода, чтобы показать таблицу с результатами. Пользователь заходит, вводит параметры (что хочет обменять, на что, куда вывести), и получает отсортированный список обменников с указанием курсов и комиссий.

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

Вариант 2: Telegram-бот

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

Для реализации можно использовать aiogram или python-telegram-bot. API-ответы ты уже умеешь обрабатывать, осталось только прикрутить кнопку /start и минимальное меню.

Telegram хорош тем, что не требует разворачивать сервер, не нужен фронт, и всё работает прямо в чате. Особенно если ты хочешь этим пользоваться сам — это один из самых практичных вариантов.

Подводные камни

С одной стороны, идея кажется простой: подключил API, получил курс, показал пользователю, где выгоднее обменять крипту. Но на практике всплывает куча нюансов, которые лучше учитывать заранее.

1. Актуальность данных

Даже если ты используешь агрегатор, курсы могут обновляться не каждую секунду. А на волатильном рынке 1–2 минуты — это уже критично. Ты думаешь, что обменяешь криптовалюту по одному курсу, а на деле получишь совсем другой.

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

2. Комиссии, которых не видно

Бывает, что курс выглядит отлично, а потом на последнем шаге прилетает комиссия, и выгода улетает. Или минимальная сумма сделки оказывается больше, чем ты хотел. Поэтому просто выводить курс недостаточно — нужно учитывать и проценты, и лимиты, и метод вывода (карта, наличные и так далее).

3. Геоограничения

Не все криптообменники в России работают одинаково. Кто-то обслуживает клиентов только по паспорту. Кто-то просит селфи с табличкой. Кто-то вообще закрывает доступ из определённых регионов. Поэтому важно не просто собрать список предложений, а ещё и понимать, кому они доступны.

4. Надёжность

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

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

5. Поддержка и баги

Ты можешь написать идеальный код, но если API внезапно начнёт отдавать 500 или изменится структура ответа — всё развалится. А если ты завёл Telegram-бота, который не умеет обрабатывать такие сбои, он начнёт спамить ошибками.

А нужно ли это вообще?..

Вот ты всё это собрал: API, фильтрацию, Telegram-бота или веб-интерфейс. Всё работает, данные идут, курс считается. Красота. Но давай по-честному — тебе вообще нужно это поддерживать?

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

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

Как выучить SQL: ТОП-6 платформ для обучения

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

Критерии оценки

• Контент: глубина тем (от SELECT до оптимизации запросов), задачи из реальной работы, подготовка к собеседованиям, поддержка сообщества.
• Технические аспекты: мобильная версия, своя IDE, сертификат, адаптация под РФ, поддержка PostgreSQL.

SYNC STUDY

Ссылка: SYNC STUDY

Для кого: Новички, профи и те, кто готовится к собеседованиям.

• Глубина погружения: Полный цикл — от основ (WHERE, JOIN) до оконных функций и создания витрин.
• Собеседования: Отдельный модуль с кейсами из практики и с теоретическими вопросами с собеседований.
• Практика: Задачи на расчет LTV, ABC-анализ, парсинг логов.
• Техническая часть: Удобная мобильная версия, своя IDE. Полная адаптация под РФ.

• Решения воспроизводятся в реальной среде PostgreSQL.

Минусы:

• Поддержка в процессе прохождения: отсутствует.
• Сертификат по окончании курса: нет.

SQL Academy

Ссылка: SQL Academy

Для кого: Новички и практикующие разработчики.

• Глубина погружения: От простых запросов до триггеров и оптимизации. Подробные примеры из e-commerce.
• Собеседования: Нет отдельного раздела, но есть задачи уровня FAANG.
• Практика: Симулятор с интерактивными заданиями (например, расчет Retention Rate).
• Поддержка: Форум, где можно обсудить решение.
• Техническая часть: Своя IDE, работает на мобильных. Сертификат — после финального экзамена.
• Бесплатный доступ.

Минус: Мало информации по работе с большими данными (например, партицирование).

Karpov Courses

Ссылка: Karpov Courses

Для кого: Новички в IT, менеджеры, аналитики, дата-сайентисты и все, кто хочет освоить SQL и продуктовую аналитику с нуля.

• Глубина погружения: Акцент на практику — от основ SQL до продвинутых тем (оконные функции, объединения) и решения реальных продуктовых задач.
• Собеседования: Кейсы из собесов Альфа-Банка, Сбера, Ozon.
• Практика: 150+ SQL-задач на симуляторе. Работа над кейсом аналитика сервиса доставки: расчет бизнес-метрик, анализ данных, проверка гипотез.
• Поддержка: Доступ к чату сообщества для общения и вопросов.
• Техническая часть: IDE с подключением к реальной PostgreSQL и инструмент для визуализации Redash.

• Бесплатный доступ ко всем материалам, симулятору и инфраструктуре.

SQL-ex.ru

Ссылка: SQL-ex.ru

Для кого: Для тех, кто любит учиться через решение задач.

• Глубина погружения: Более 500 задач — от простых SELECT до хранимых процедур.
• Собеседования: Нет.
• Практика: Олимпиадные задания (например, расчет скользящего среднего без оконных функций).
• Поддержка: Форум с энтузиастами.
• Техническая часть: Устаревший интерфейс, нет мобильной версии.

Минус: Теория подается фрагментарно.

SQLZoo

Ссылка: SQLZoo

Для кого: Новички, которые хотят попробовать SQL бесплатно.

• Глубина погружения: Базовый уровень + JOIN, подзапросы.
• Собеседования: Нет.
• Практика: Интерактивные задачи с автоматической проверкой.
• Поддержка: Нет сообщества.
• Техническая часть: Работает на мобильных, своя IDE.

Минус: Нет продвинутых тем (CTE, оптимизация).

Stepik

Ссылка: Курсы на Stepik

Для кого: Для системного изучения с нуля.

• Глубина погружения: Полный курс с видеоуроками — от основ до анализа в Python.
• Собеседования: Нет.
• Практика: Задачи на анализ реальных датасетов (например, Airbnb).
• Поддержка: Обсуждения к каждому уроку.
• Техническая часть: Поддержка PostgreSQL, сертификат.

Минус: Мало задач на оконные функции.

Итог: Какую платформу выбрать?

• Для новичков: SQL Academy (бесплатно) или Stepik (структурный курс).
• Для подготовки к собеседованиям: SYNC STUDY или Karpov Courses (бесплатно).
• Для углубленного изучения: Karpov Courses (аналитика) или SQL-ex.ru (практика).
• Для мобильного обучения: SYNC STUDY или SQLZoo.

Так случалось, пока не появились инструменты вроде TanStack Query и не родились «обертки», которые уменьшают объемы рутины. Как перестать тонуть в запросах на разработку API и начать дышать свободно, рассказывает Дмитрий Скляр, старший разработчик компании Axenix.

API: нервная система цифрового мира

В современном ИТ-ландшафте API давно перестал быть просто техническим термином. Теперь он — один из столпов, на котором держится цифровая цивилизация.

Философия современной разработки давно сместилась от принципа «сделай все сам» к парадигме «собери из лучших компонентов». API стал языком, на котором взаимодействуют цифровые сервисы. Он превратил ИТ-ландшафты и интернет из собрания разрозненных приложений и сайтов в единую живую экосистему, где каждый элемент может взаимодействовать с другим.

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

Но настоящую революцию API совершил в бизнесе, создав целые экосистемы цифровых услуг. Такие компании, как Stripe, Twilio или Plaid построили свои империи именно на API, предоставляя другим разработчикам готовые «кирпичики» для создания финансовых, коммуникационных или аналитических сервисов.

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

Боль, которую никто не замечает

Но не все так просто и далеко не так радужно.

Да, формально API — это универсальный мост, например, между фронтендом и бэкендом. На практике же он часто напоминает шаткую подвесную конструкцию: данные приходят в разном формате, документация устаревает еще до релиза, а поля user_name и username существуют одновременно просто потому, что «исторически сложилось».

Типичный сценарий: вы пишете код для запроса списка товаров, все типизируя и описывая модели — 50 строк. Добавляете фильтрацию — еще 30 строк. А через месяц бэкенд меняет структуру ответа, забывает предупредить — и вы тратите день на поиск багов в трех разных местах. И самое обидное: 80% этого кода — копипаст. Проверка ошибок, трансформация данных, инвалидация кэша — все одно и то же, но плодится как вирусы.

Сюда можно добавить также сложность поддержки — API меняется, код устаревает.

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

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

Спасение — в системе

Однажды наши разработчики устали писать однотипные хуки, чинить сломанные запросы и объяснять новичкам, что где находится, почему именно так это работает и почему нельзя просто взять и использовать что-то другое. Устали писать однотипный код для каждого запроса, захотели минимизировать ошибки и ускорить разработку, а также сделать работу с API более структурированной и понятной. Также у команд назрела потребность в скорейшем включении в проект новых разработчиков. Для всех этих задач подходит одно решение: унифицированный подход к API, который также наводит порядок в данных и отчетах, упрощая аналитику и логику приложения.

Тогда и родилась идея фабрики API — слоя абстракции, который скрывает рутину. Для этого мы привлекли возможности TanStack Query, семейство библиотек для управления состоянием данных (data fetching) в клиентских приложениях. Помимо TanStack Query (ранее React Query), к этому классу инструментов также относятся: RTK Query (из Redux Toolkit), Apollo Client (для GraphQL) и SWR.

Их общая философия: «делать рутину невидимой для разработчика». Рассмотрим Конкретные проблемы и их решения.

Однотипные хуки для каждого запроса

В большинстве проектов без дополнительной абстракции каждый хук под API-запрос пишется вручную. Меняется только URL и параметры, а структура остаётся одинаковой: queryKey, queryFn, опции запроса. Это быстро приводит к копипасту, дублированию логики и усложнению поддержки.

Например, для каждого ресурса вроде пользователей, продуктов, заказов и т.д. приходится повторять одну и ту же конструкцию. Если нужно изменить поведение запроса (например, добавить retry или staleTime), правки необходимо делать в десятках мест.

Решение: Универсальная обёртка над хуками TanStack Query

Создание единой функции-генератора для хуков позволяет избавиться от повторяющегося кода. Она принимает ключ, функцию запроса и опциональные параметры — и возвращает сразу «пачку» готовых хуков.

Такой подход:

• снижает количество шаблонного кода;
• упрощает масштабирование;
• централизует поведение всех запросов;
• позволяет быстро адаптироваться к изменениям (например, добавить логирование, типизацию, трансформации и т.п.).

Хрупкость при изменении API

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

Решение: Централизованная трансформация данных + class-transformer.

С помощью class-transformer можно объявить классы сущностей и задать правила преобразования один раз.

Плюсы:

• Все данные автоматически приходят в нужном виде;
• Компоненты работают с гарантированно типизированными данными;
• Один источник правды: при изменении API – правим только Entity-класс;
• Удобно масштабируется, особенно если API большое и сложное.

«Мусор» в данных и отчётах

Решение: Валидация данных при трансформации (например, через class-validator); автоматическая синхронизация кеша (актуальные данные во всём приложении).

Почему это лучше ручного подхода? Смотрите: строк кода на 1 endpoint при ручном управлении потребуется 30+, а с фабрикой — 5-10. Времени для добавления нового поля — 1 час вручную, с фабрикой — 5 минут. Количество мест для правки при изменении API — вручную их много, с фабрикой — лишь одно.

Реальный кейс: в проекте с 50+ endpoint’ами переход на фабрику сократил код на 70%. Разработчики перестают быть «переводчиками» между API и интерфейсами сервисов и приложений, а сосредотачиваются на бизнес-логике. Как сказал один тимлид: «Теперь мы не фиксим баги данных, а делаем фичи, которые нравятся пользователям».

Еще пример: вместо пяти отдельных хуков для CRUD-операций фабрика дает одну функцию createApi(). Вместо ручного парсинга — автоматическую трансформацию данных через class-transformer. А главное — единые правила игры для всего проекта.

Как это работает? Представьте, что вы говорите системе: «Вот endpoint для товаров, вот их модель данных, вот правила валидации» — а все остальное она делает за вас. Хотите получить товар по ID? Пишете useGetByIDQuery. Нужно обновить? — useUpdatetMutation. И никакого шаманства с ручным описанием каждого хука.

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

Как договориться и не сойти с ума

Проблема в том, что без четкого контракта, набора правил и подходов фронтенд- и бэкенд-разработчики живут в параллельных реальностях. Один думает, что данные придут в camelCase, другой шлет их в snake_case. Один ожидает массив, другой неожиданно подсовывает null. Итог — бесконечные баги, исправления «на живую» и испорченные нервы.

Решение? Четкий контракт. Простой, прозрачный, однозначный. В нем должны быть:

1. Единые правила именования — если бэкенд отдает snake_case, фронтенд не должен гадать, будут ли остальные поля в camelCase, или, например, если в одной модели данных full_name , в другой не будет fullname и так далее.
2. Единый формат запросов и ответов.
3. Договоренности о структуре URL, формате данных и кодах ошибок.
4. Строгая типизация — TypeScript-интерфейсы, которые знают, какие поля обязательны, а какие могут отсутствовать.
5. Документация, которая не врет — если Swagger говорит, что поле email есть, оно должно быть. Всегда.

И самое главное — этот контракт должен соблюдаться. Если бэкендеры меняют API, они обязаны предупредить. Иначе фронтенд превращается в сапера, который каждое утро разминирует прод.

Но, как правило, контракт сделать тяжело. Каждый видит REST по-своему: разные URL, форматы данных, обработка ошибок. Модели данных непоследовательны — поля то есть, то их нет, вложенность меняется. Документации либо нет, либо она устарела, так что API изучаем методом проб и ошибок. От такого надо отказываться сразу и стараться договорится на берегу.

Для унификации и строгого соответствия данных мы используем class-transformer: автоматически приводим данные к нужным форматам, вместо работы с сырыми JSON-объектами. Так получаются экземпляры классов с методами и свойствами. Далее убираем ручную обработку и проверки данных, преобразовываем вложенные структуры и применяем кастомные трансформации.

Что получаем в итоге?

Когда контракт есть, а обертка API готова, магия начинает работать:

• Простота использования: вместо десятков хуков — единая фабрика createApi(). Меньше boilerplate-кода.
• Мощные возможности: данные приходят уже в нужном формате без ручных проверок. Кэш, инвалидация и оптимизации — TanStack Query делает за вас всю грязную работу.
• Новички влетают в проект: больше не нужно объяснять, почему useGetEntity в одном компоненте работает не так, как в другом.
• Активное сообщество: TanStack Query — тысячи разработчиков, готовых ответить на вопросы. Здесь можно найти примеры для любых кейсов: от интеграции с Next.js до кастомного кеширования.
• Нет ограничений по использованию: TanStack Query — не только для React, есть версии для Vue, Svelte и даже Solid.js. Также работает с любым API — REST, GraphQL, WebSockets.
• Работа с SSR без боли: готовая интеграция с Next.js, Remix и другими фреймворками. При этом данные, полученные на сервере, автоматически передаются на клиент. TanStack Query синхронизирует серверный и клиентский рендеринг.

Но есть и ложка дегтя. Отладка усложняется, если что-то сломается внутри обертки — придётся копать глубже. Возникает зависимость от библиотек: class-transformer, axios и сам TanStack Query становятся обязательными.

Однако игра стоит свеч. Потому что время, сэкономленное на рутине, можно потратить на то, что действительно важно — фичи, которые понравятся пользователям, а не бесконечные правки API-вызовов.

Сравнительные примеры

GET /products — Список продуктов

GET /products/:id — Один продукт по id

POST /products — Создание продукта

PUT /products/:id — Обновление продукта по id

DELETE /products/:id — Удаление продукта по id

Как это выглядит в обертке

Все свойства и возвращаемые хуки и конфиги из фабрики:

Пример использования в компонентах:

Использование конфигов:

Для сравнения с классическим решением:

Когда стоит переходить на обертку?

Не каждый проект нуждается в таком подходе к API. Если у вас два-три endpoint’а и они никогда не меняются — возможно, обертка будет избыточной. Но представьте стартап, где каждый месяц добавляются новые сущности: сначала товары, потом отзывы, потом промокоды, рекомендации, аналитика.

Вот где система раскрывается на полную! Новая сущность? Пять минут на добавление — и готовы все CRUD-операции. Изменился бэкенд? Правим в одном месте — и все работает. Пришел новый разработчик? Он не тратит неделю на изучение особенностей API.

Правда, если бэкенд живет в мире хаотичных endpoint’ов (например, GET /fetch_items, но DELETE /removeProduct), обертка не спасет.

Но как навести порядок?

Главный секрет — общаться. Не ждать, пока API сломается, а сразу договориться:

• Какие будут названия полей (created_at vs createdAt);
• Как структурированы ошибки;
• Когда и как можно менять контракт.

Как сказал один разработчик: «фронтенд и бэкенд — как соседи по коммуналке. Можно ругаться из-за бардака на кухне, но лучше сесть и написать правила совместного проживания».

А напоследок — график, для закрепления разницы между работой с оберткой и без нее.

Зачем компании собирают данные

Сегодня в интернете более 1 миллиарда сайтов. На великом и ужасном реддите каждый час появляется более 50 000 новых публикаций. На Github уже опубликовано более 300 млн публичных репозиториев. Всё это — открытые данные, которые можно использовать и, главное — собирать. Разумеется, перед этим проверить условия использования сайта, потому что некоторые из них могут запрещать сбор данных.

Зачем это нужно компаниям:

• Анализ рынка: для ритейла это возможность изучить клиентов и конкурентов.
• Мониторинг сайтов вендоров ПО: некоторые компании выкладывают уязвимости в своих продуктах и делятся возможными решениями.
• Создание продукта: собранные данные можно обогатить, прикрутить красивый интерфейс, умный поиск и предложить пользователю новое приложение, типа 2GIS.
• Развитие LLM: например, Google в 2024 году заключил контракт с Reddit на сбор данных. Open AI тоже часто говорят о том, что обучают свою модель на открытых источниках, а в ближайшее время хотят подключить ещё и транскрибации с YouTube.

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

Что такое Scrapy

Это высокоуровневый фреймворк на Python для краулинга и скреппинга сайтов. На GitHub у него больше 53 тысяч звёздочек, 10,6 тысяч форков и много глазиков. А ещё он занимает первое место по тегам #crawling и #scraping.

Есть много причин, почему Scrapy так популярен:

• Это фреймворк с готовой архитектурой — там много инструментов, доступных из коробки, которые можно настроить и использовать.
• Он асинхронный — чаще возникает задача замедлить его, чем ускорить.
• У него простые настройки — нужно всего раз подумать над архитектурой, а добавление новых источников будет занимать минимум времени.
• Scrapy удобно дебажить в любой момент, начиная от загрузки страницы и заканчивая сохранением данных в базе.
• Есть продуманные селекторы, доступны CSS, Xpath. Их можно комбинировать или выбрать что-то одно.
• Большое комьюнити и обновляемая документация. Ответы на большинство вопросов можно легко найти в сети.

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

Scrapy будет не лучшим выбором, если:

• Нужно собрать малый объем данных или собрать их нужно всего один раз.
• Вам нужно отдать просто сырые html или json, а не парсить и преобразовывать данные.
• Среди источников нет общей структуры данных.

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

Как работает Scrapy

После того, как вы установили Scrapy в виртуальное окружение ( '' pip instal scrapy' ) и создали новый проект ( ' scrapy startprogect scraper '' ), вам необходимо написать своего первого «паука».

В Scrapy используется класс spider — он определяет, как мы будем извлекать данные из сайтов. Допустим, нам нужно собрать информацию с одностраничного сайта. Создаём класс TestSpider, наследуемся от scrapy.Spider, добавляем атрибут name с уникальным именем и start_urls, где укажем страницы, с которых нужно начать поиск. После этого переопределим метод parse.

Parse является дефолтным для обработки ответов. Если вы сделаете request и не укажете функцию, которая должна его обработать, то ответ от запроса придёт в метод parse. Поэтому его, как минимум, нужно переопределить и назначить логику.

Допустим, нас интересует информация о компании — название и описание. Можем создать объект данных с двумя элементами — title и content, и с помощью двух xpath селекторов забрать со страницы заголовок и описание.

В конце передаём этот объект данных для последующей обработки в ядро. Это всё, что нужно, чтобы начать парсинг на Scrapy.

Обработка данных в Scrapy

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

В ValidatePipeline мы проверяем объект данных на наличие title, а в SavePipeline — сохраняем объект в качестве json.

Здесь я просто показал, как можно создать пайплайн самостоятельно. Но имейте в виду, что это не очень отказоустойчивый код, поэтому в проде так делать не стоит.

Зачем нужен Middleware

Middleware очень похож на PipeLine, только он обрабатывает не объекты данных, а запросы и ответы от сайта.

В Scrapy есть несколько разных middleware:

• scheduler middleware: помещает запросы в очередь и извлекает их для обработки.
• spider middleware: управляет данными между пауком и ядром.
• downloader middleware: управляет данными между ядром и загрузчиком.

Получается такая схема работы компонентов Scrapy:

Запрос: Spider → Spider Middleware → Engine → Scheduler Middleware → Scheduler → Engine → Downloader Middleware → Downloader → Server (сайт)

Ответ: Server → Downloader → Downloader Middleware → Engine → Spider Middleware → Spider → Item Pipeline → Storage (хранилище данных)

Скорее всего, в первую очередь вы будете настраивать downloader middleware, поэтому разберём его подробнее.

Ниже продемонстрировал два примера, как можно написать свой Middleware. В RandomProxyMiddleware мы обрабатываем все запросы, которые будет отсылать наш паук с помощью метода process_request (добавляем рандомную прокси к каждому реквесту), а в CheckCaptchaMiddleware — обрабатываем все ответы с помощью метода process_response (проверяем ответ от сайта, ищем в нём слово captcha).

Итак, мы написали Pipeline и Middlewares. Дальше нужно указать, как мы будем их использовать. Для этого запишите их в файле settings.py, где находятся настройки проекта.

Начнём с пайплайнов. Цифра справа — это порядковый номер выполнения. То есть первым будет ValidatePipeLine, а вторым сработает SavePipeline. Обычно цифры указываются от 0 до 1000. И в случае с пайплайнами чем ниже цифра, тем раньше сработает пайплайн.

В случае с middleware картина такая же, но логика немного иная.

Каждый middleware может обрабатывать как request, так и response. При этом middleware стоит посередине между ядром, который отправляет запросы, и загрузчиком. Если ваша middleware обрабатывает запросы, то сработает первой та, что указана с меньшей цифрой, потому что она ближе к ядру. А если middleware обрабатывает ответы, то первой будет та, у которой цифра больше, потому что она дальше от ядра и ближе к загрузчику.

Об этот нюанс часто спотыкаются новички, хотя, скорее всего, он прописан в документации.

Пример, как использовать Scrapy

Рассмотрим, как с помощью одного селектора собрать сайт любой вложенности и архитектуры.

Для начала создаём класс паука, наследуемся от scrapy.Spider, указываем name, start_urls и атрибут allowed_domains — он необязательный, но в данном случае без него не обойтись. В нём мы укажем список хостов, на которые разрешаем ходить нашему пауку, чтобы он не начал собирать другие сайты.

Дальше переопределяем метод parse и, когда к нам приходит ответ от сайта, находим все ссылки. И это и есть тот единственный xpath селектор, который поможет обойти весь сайт и собрать страницы.

Все ссылки помещаем в переменную url в качестве списка, а потом этот список передаём в функцию follow_all объекта response.

Чтобы дописать сохранение, просто передаём объект response вглубь ядра Scrapy, где напишем какой-то нехитрый пайплайн и будем сохранять html-страницы. Так можно собрать абсолютно любой сайт, просто подставьте ссылку на него в start_urls.

Важный нюанс: под капотом follow_all сделает запросы к сайту по всем ссылкам, которые мы нашли на странице. И поскольку в follow all мы не указываем определённый метод в параметре callback, то все ответы придут сюда же в метод parse (потому что он дефолтный в Scrapy). Эта логика будет повторяться на каждой странице.

Ещё в Scrapy есть внутренний фильтр, поэтому если паук соберёт дубликаты, то автоматически зафильтрует их и не будет проходить по ссылкам дважды.

Немного итогов

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

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

Shodan API: Поиск уязвимостей в интернете за минуты

Shodan — поисковая система для интернет-устройств. В отличие от Google, который индексирует веб-страницы, Shodan сканирует открытые порты, сервисы и устройства, подключённые к интернету. Это делает его мощным инструментом для исследователей безопасности, разработчиков и системных администраторов.

Shodan API позволяет автоматизировать поиск уязвимых серверов, камер наблюдения, баз данных и других интернет-ресурсов. Может анализировать их конфигурации и даже отслеживать инциденты безопасности в реальном времени.

Как Shodan API экономит время разработчикам?

Ручной аудит серверов и интернет-устройств может занять недели, а то и месяцы, но Shodan API позволяет:

• Быстро находить уязвимые устройства и сервисы
• Проверять, какие технологии и версии ПО используются на серверах
• Получать статистику по открытым портам, SSL-сертификатам и угрозам
• Отслеживать новые уязвимости в реальном времени

Для DevOps, SOC-аналитиков и специалистов по информационной безопасности это возможность автоматизировать рутинные проверки и защитить инфраструктуру от потенциальных атак.

Как использовать Shodan API?

Shodan API предоставляет удобные методы для работы с данными через REST-запросы. Рассмотрим основные возможности.

Поиск открытых сервисов и устройств

Shodan позволяет находить устройства, доступные по определённым портам, IP-адресам или географическим координатам. Например, запрос всех открытых баз данных MongoDB:

Ответ покажет список IP-адресов, страну расположения серверов и используемые версии ПО.

Получение информации об IP-адресе

Допустим, вы хотите узнать, какие сервисы запущены на конкретном IP. Используем команду:

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

Поиск устройств по версии ПО

Чтобы найти все серверы с устаревшей версией OpenSSH, можно выполнить запрос:

Это полезно для поиска серверов, подверженных атакам из-за старых версий ПО.

Важно понимать, что Shodan не предназначен для хакерских атак. Использование API для несанкционированного сканирования чужих серверов может быть незаконным. Поэтому рекомендуется работать только с теми системами, на которые у вас есть разрешение.

Abstract API: Быстрая проверка IP, валидация email и работа с геоданными

Abstract API — сервис, предлагающий набор API для работы с IP-адресами, валидацией email, проверкой телефона, распознаванием валют и многим другим. Это универсальный инструмент для веб-разработчиков, аналитиков и специалистов по безопасности.

Как Abstract API экономит время разработчикам?

Вместо того чтобы искать разные API для работы с геоданными, email-валидацией и IP-адресами, можно использовать Abstract API. Это экономит часы на интеграцию и позволяет быстро решать задачи, такие как:

• Определение страны и города пользователя по IP

• Проверка подлинности email перед регистрацией

• Конвертация валют в реальном времени

• Валидация телефонных номеров

Abstract API помогает автоматически фильтровать спам-регистрации, защищать системы от ботов и улучшать пользовательский опыт.

Как использовать Abstract API?

API работает через REST-запросы и доступно для бесплатного использования с ограничениями.

Определение геолокации по IP

Можно быстро определить страну, город и провайдера пользователя:

Валидация email-адреса

Проверяем, является ли email настоящим, одноразовым или корпоративным:

Что нужно помнить? Бесплатная версия ограничена числом запросов в месяц. А данные по IP-геолокации иногда могут быть неточными (зависит от провайдера).

Zyte API: Интеллектуальный ротационный прокси для веб-скрейпинга без блокировок

Zyte API — мощный API для веб-скрейпинга, который не только обходит блокировки и капчи, но и автоматически структурирует полученные данные. Он объединяет в себе прокси-серверы, обработку JavaScript-страниц и инструменты парсинга, что делает его одним из самых удобных решений для сбора данных с веб-ресурсов.

Как Zyte API экономит время?

Вместо того чтобы вручную разрабатывать сложные парсеры и бороться с защитами сайтов, Zyte API позволяет получить уже готовые структурированные данные:

• Автоматическая обработка JavaScript-страниц (открывает динамически загружаемые сайты, как Selenium).

• Обход капч и блокировок (использует интеллектуальные прокси).

• Автоматическое структурирование данных (не просто HTML, а уже готовая JSON-структура).

• Интеграция с Python и REST API (работает с любыми языками программирования).

API идеально подходит для разработчиков, аналитиков, маркетологов и исследователей данных.

Как использовать Zyte API?

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

Использование Zyte в curl

Допустим, нужно скачать HTML-страницу сайта example.com:

Что нам ответят:

Интеграция с Python

Для начала нужно установить клиент:

Код для парсинга и получения данных:

Автоматический парсинг данных

Zyte API умеет не только загружать HTML, но и автоматически извлекать полезные данные. Например, спарсить цену, название и описание кроссовок в интернет-магазине (ну или любого другого товара).

Из минусов — нет бесплатного доступа (лишь пробный период). Также некоторые страницы требуют больше времени для обхода ограничений (может понадобиться доп.настройка).

Common Crawl API: Бесплатная база данных для веб-скрейпинга и анализа интернета

Common Crawl — не просто API, а целый архив интернета, содержащий огромные объемы веб-данных, собранных с 2008 года. В отличие от стандартных API для веб-скрейпинга, Common Crawl предоставляет доступ к готовым копиям страниц, что значительно ускоряет анализ веб-контента и снижает нагрузку на исходные сайты.

Как Common Crawl API экономит время?

Вместо того чтобы разрабатывать сложные парсеры и загружать миллионы страниц вручную, Common Crawl позволяет быстро находить нужную информацию в готовых архивах:

• Бесплатный доступ к огромной базе веб-страниц (петабайты данных, обновляемых ежемесячно).

• Исторические данные (можно анализировать, как изменялся контент сайтов за годы).

• Отсутствие блокировок и капч (данные уже собраны, вам не нужно бороться с защитами сайтов).

• Возможность массового анализа веба (идеально для NLP, машинного обучения и SEO-исследований).

API и данные Common Crawl полезны для исследователей, дата-аналитиков, SEO-специалистов и разработчиков.

Как использовать Common Crawl API?

Common Crawl предоставляет данные в формате WARC (архивные копии страниц) и WET (чистый текст без HTML). Доступ осуществляется через Amazon S3, но также можно использовать API Common Crawl Index для поиска нужных URL.

Поиск веб-страниц через API

Допустим, нам нужны все страницы, содержащие example.com:

Вот такой ответ может быть:

Получение текста страницы из архива

После получения ссылки на WARC-файл можно скачать его и распаковать:

Ну и затем извлечь текст:

Анализ больших объемов данных с AWS

Если вам нужны миллионы страниц, можно использовать AWS Athena для обработки данных прямо в облаке.

Пример SQL-запроса в AWS Athena для поиска страниц с «machine learning»:

Важно отметить, что данные предоставляются в сыром виде и их нужно дополнительно обрабатывать. Плюс нет гарантии, что конкретная страница будет в архиве.

GitHub API: автоматизация работы с репозиториями, пользователями и кодом

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

Как GitHub API экономит время?

Вместо ручного управления репозиториями и кодом через интерфейс GitHub можно автоматизировать эти процессы с помощью API:

• Автоматизация деплоя и CI/CD (создание и управление GitHub Actions).

• Мониторинг активности в репозиториях (новые коммиты, запросы на вытягивание, проблемы).

• Управление пользователями и организациями (добавление разработчиков, управление доступом).

• Анализ кода и метрик (подсчёт строк кода, статистика участников).

• Поиск по репозиториям и файлам (быстрое извлечение нужной информации).

GitHub API полезен для DevOps-инженеров, разработчиков, владельцев проектов и аналитиков.

Как использовать GitHub API?

GitHub API работает через REST-запросы и возвращает данные в формате JSON. Для авторизации можно использовать токен личного доступа (PAT) или OAuth.

Получение информации о пользователе GitHub

Допустим, мы хотим узнать данные о пользователе natasharostova:

Как нам могут ответить:

Создание нового репозитория через API

После выполнения запроса появится новый репозиторий new-repo.

Поиск репозиториев по ключевому слову

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

Нужно понимать, что есть ограничение в 5000 API-запросов в час для авторизованных пользователей. Для некоторых функций требуется версия GitHub Enterprise.

MuleSoft API: Универсальный коннектор для интеграции сервисов

MuleSoft API — платформа для интеграции различных систем, сервисов и приложений. Она позволяет соединять облачные и локальные системы, автоматизировать обмен данными и управлять API. MuleSoft широко используется в корпоративных средах для построения сложных интеграционных решений.

Как MuleSoft API экономит время?

Вместо того чтобы разрабатывать интеграции с нуля, MuleSoft API предлагает готовые коннекторы, которые позволяют:

• Интегрировать разные системы (CRM, ERP, базы данных, облачные сервисы) без сложного кодинга.

• Автоматизировать обмен данными между приложениями (например, между Salesforce и SAP).

• Обеспечивать безопасность API с помощью встроенных инструментов управления доступом.

• Создавать микросервисную архитектуру, где API работают как модули.

API полезен для DevOps-инженеров, архитекторов ПО, разработчиков корпоративных решений и интеграторов.

Как использовать MuleSoft API?

MuleSoft поддерживает REST и SOAP API, а также интеграцию через готовые коннекторы.

Создание API с помощью Anypoint Platform

Anypoint Platform — облачная среда MuleSoft, в которой можно управлять API.

Пример запроса к API через MuleSoft:

Подключение к базе данных через DataWeave

DataWeave — это язык MuleSoft для трансформации данных. Он позволяет легко преобразовываться в нужные форматы.

Это правило конвертирует XML-ответ базы данных в JSON.

Важно помнить, что бесплатные возможности платформы ограничены. Также сервис требует обучения: для работы с DataWeave и Anypoint Platform нужно разбираться в интеграции API.

JSONPlaceholder API: бесплатный фиктивный REST API для тестирования и создания прототипов

JSONPlaceholder API — бесплатный REST API, предназначенный для тестирования, создания прототипов и обучения разработчиков. Он предоставляет фиктивные данные (пользователей, публикаций, комментариев и т. д.), которые можно использовать при разработке клиентских и серверных приложений без необходимости развёртывать собственный бэкенд.

Как JSONPlaceholder API экономит время?

Разработчикам часто нужно тестировать фронтенд или отлаживать API-запросы, но не всегда есть готовый бэкенд. JSONPlaceholder API решает эту проблему:

• Позволяет мгновенно получать тестовые данные без развертывания сервера.

• Не требует регистрации или API-ключа.

• Поддерживает стандартные HTTP-методы (GET, POST, PUT, DELETE).

• Полностью совместим с популярными библиотеками и фреймворками (Axios, Fetch API, jQuery и др.).

API полезен для фронтенд-разработчиков, тестировщиков, студентов и преподавателей программирования.

Как использовать JSONPlaceholder API?

JSONPlaceholder предоставляет несколько ресурсов, которые можно запрашивать с помощью HTTP-запросов.

Получение списка пользователей

Простейший GET-запрос возвращает список тестовых пользователей:

Получение списка постов

Можно запросить список фиктивных публикаций:

Добавление нового поста

Можно отправить POST-запрос, чтобы имитировать создание записи:

Обновление записи

Для изменения существующей записи можно использовать PUT-запрос:

Что нужно помнить? Данные статичны — они не сохраняются между запросами. Запросы POST, PUT и DELETE не изменяют реальные данные. А само API предназначено только для тестирования, а не для использования в рабочей среде.

Мы собрали 15 инструментов, которые пригодятся аналитикам данных, и разобрали их функционал.

Data Scraper — извлечение данных с веб-страниц

Ссылка на расширение

Для чего? Автоматический сбор таблиц, списков и других данных с сайтов. Он загружает данные в CSV, Excel или Google Sheets без необходимости программирования.

Пример использования. Вы анализируете цены конкурентов в интернет-магазинах и хотите собрать данные о стоимости товаров. Data Scraper автоматически извлекает нужные элементы и экспортирует их в таблицу.

✅ Плюсы: удобство, простота настройки, экспорт в популярные форматы.

❌ Минусы: ограниченная бесплатная версия, не работает на защищенных сайтах.

Web Scraper — мощный инструмент для автоматизированного сбора данных

Ссылка на расширение

Для чего? Глубокий парсинг с поддержкой вложенных страниц. Инструмент настраивает сценарии обхода динамических сайтов и сбора их данных.

Пример использования. Вы анализируете вакансии на сайтах работодателей и хотите собрать данные по зарплатам, названиям должностей и требованиям.

✅ Плюсы: гибкость, автоматический обход страниц.

❌ Минусы: требует понимания HTML-структуры сайтов.

Awesome Table — превращение данных в интерактивные отчёты

Ссылка на расширение

Для чего? Помощь в визуализации данных в Google Sheets. Создает наглядные дашборды, которые можно встроить в сайт или презентацию.

Пример использования. У вас есть список клиентов с продажами, и вы хотите создать интерактивный отчет с фильтрацией по странам, категориям и датам.

✅ Плюсы: легкость настройки, хорошая интеграция с Google.

❌ Минусы: ограничения в бесплатной версии.

Octoparse — мощный инструмент для парсинга данных

Ссылка на расширение

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

Пример использования. Допустим, вам нужно собрать список всех статей по определённой тематике с крупного новостного портала. Octoparse создаст сценарий, который будет автоматически переходить по страницам, извлекать заголовки, даты публикации и ссылки, а затем экспортировать данные в CSV или Excel.

✅ Плюсы: Не требует знаний программирования; поддерживает сложные сценарии парсинга (например, клик по кнопке «Показать ещё»).

❌ Минусы: Ограниченный функционал в бесплатной версии; может не работать с сайтами, защищёнными от ботов (например, Cloudflare)

Selenium IDE — автоматизация тестирования прямо в браузере

Ссылка на расширение

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

Пример использования. Вы разработчик или аналитик, которому нужно проверить, как работает новый функционал на сайте. Вместо ручного тестирования Selenium IDE записывает ваши действия (ввод в форму, клик по кнопке) и воспроизводит их автоматически.

✅ Плюсы: Возможность экспорта сценариев в разные языки (Python, Java, JavaScript).

❌ Минусы: Ограниченные возможности по сравнению с полноценным Selenium WebDriver.

Google Analytics Debugger — отладка событий в GA

Ссылка на расширение

Для чего? Проверка корректности передачи данных в Google Analytics. Показывает, какие события отправляются в аналитику.

Пример использования. Если в аналитике не отображаются клики по кнопке «Купить», Debugger поможет понять, передаются ли данные в систему.

✅ Плюсы: подробные логи, быстрая диагностика проблем.

❌ Минусы: поддерживает только Universal Analytics, не GA4.

DataLayer Checker — проверка передачи данных

Ссылка на расширение

Для чего? диагностика переменных DataLayer в GTM. Показывает, какие данные передаются на сайт.

Пример использования. Хотите убедиться, что в аналитику передаются все параметры заказа? DataLayer Checker покажет их в реальном времени.

✅ Плюсы: помогает в настройке e-commerce аналитики.

❌ Минусы: сложен для новичков.

Tableau Chrome Extension — удобная работа с дашбордами

Ссылка на расширение

Для чего? Облегчает доступ к дашбордам Tableau. Загружает отчеты без необходимости заходить на сайт.

Пример использования. Вы работаете в команде аналитиков и хотите быстро проверять дашборды Tableau прямо из браузера.

✅ Плюсы: ускоряет доступ к данным.

❌ Минусы: требует подписки на Tableau.

Block Yourself from Analytics — исключение собственного трафика

Ссылка на расширение

Для чего? Чтобы не учитывать свои визиты в Google Analytics.

Пример использования. Вы администратор сайта и не хотите искажать данные в GA своими посещениями.

✅ Плюсы: легко включается и выключается.

❌ Минусы: работает только в Chrome.

Table Capture — копирование таблиц с сайтов

Ссылка на расширение

Для чего? Экспорт таблиц с сайтов в Excel и Google Sheets.

Пример использования. Вам нужно быстро перенести данные текстовой таблицы с веб-страницы в Google Sheets.

✅ Плюсы: это, как минимум, удобно.

❌ Минусы: не всегда корректно распознает сложные таблицы.

JSONView — удобное представление JSON-данных

Ссылка на расширение

Для чего? Форматирование JSON-файлов в читаемый вид.

Пример использования. Вы работаете с API и хотите быстро понять структуру JSON-ответов.

✅ Плюсы: цветовая подсветка.

❌ Минусы: не редактирует JSON.

Scraper — быстрый экспорт данных с сайтов

Ссылка на расширение

Для чего? Извлекает текстовые и табличные данные с веб-страниц без сложных настроек.

Пример использования. Вы анализируете список товаров на маркетплейсе и хотите собрать данные о ценах и наличии.

✅ Плюсы: прост в использовании, есть интеграция с Google Sheets.

❌ Минусы: ограниченный функционал по сравнению с Web Scraper.

Wappalyzer — определение технологий сайтов

Ссылка на расширение

Для чего? Показывает, какие CMS, языки программирования, аналитические сервисы и рекламные сети использует сайт. Полезен для конкурентного анализа и технических исследований.

Пример использования. Вы изучаете сайты конкурентов и хотите понять, какие технологии они применяют (используют ли Google Tag Manager и т.д.).

✅ Плюсы: удобный интерфейс, быстрый анализ.

❌ Минусы: иногда пропускает редкие технологии.

OpenLink Structured Data Sniffer — анализ структурированных данных

Ссылка на расширение

Для чего? Извлекает и анализирует JSON-LD, RDF на сайтах. Помогает проверить корректность разметки страниц для поисковых систем.

Пример использования. Вы работаете с SEO и хотите проверить, правильно ли настроены schema.org-разметки на сайте клиента.

✅ Плюсы: детализированный анализ.

❌ Минусы: требует знаний о структурированных данных.

Tag Assistant — анализ работы тегов Google

Ссылка на расширение

Для чего? Проверка корректности работы Google Tag Manager, Analytics и Ads. Анализирует теги, выявляет ошибки в их настройке.

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

✅ Плюсы: удобный интерфейс, анализ сразу всех тегов Google.

❌ Минусы: требует знаний о работе тегов.

А какими расширениями пользуетесь вы? Делитесь в комментариях!

Типы ошибок в Node.js и основные подходы к их обработке

Синхронные ошибки

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

Если такая ошибка не перехвачена, она приведёт к аварийному завершению процесса. Какие есть примеры?

Ошибки типа (TypeError, ReferenceError)

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

Ошибки парсинга JSON

Если переданный JSON-строковый объект невалиден, JSON.parse() выбросит исключение.

Деление на ноль или некорректные математические операции

JavaScript допускает деление на ноль, но оно может приводить к логическим ошибкам.

Но как правильно обрабатывать синхронные ошибки?

Используем try...catch

Классический способ перехвата ошибок в синхронном коде — использование конструкции try...catch.

Генерируем пользовательские ошибки

Можно явно выбрасывать ошибки с пояснением:

Используем process.on('uncaughtException', callback)

Node позволяет перехватывать необработанные ошибки глобально:

Синхронные ошибки в Node могут возникать по разным причинам: неверный тип данных, ошибки в логике или работе с JSON и т.д.. При работе важно помнить, что их можно перехватывать try...catch, выбрасывать вручную с пояснениями и даже обрабатывать глобально с помощью process.on(). Это снижает вероятность неожиданного завершения работы сервера и повышает надежность приложений.

Асинхронные ошибки

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

Асинхронные ошибки в Node могут проявляться в трёх основных сценариях:

1. Ошибки в коллбэках;
2. Ошибки в промисах;
3. Ошибки в async/await.

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

Ошибки в коллбэках

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

Пример: ошибка внутри коллбэка

Здесь, если файл nonexistent.txt отсутствует, в err передается ошибка, и программа не падает, а просто выводит сообщение. Однако, если бы в коде не было проверки if (err), приложение завершилось бы при попытке обработать data.

Как правильно обрабатывать ошибки в коллбэках?

1. Всегда проверять аргумент err;
2. Передавать ошибки дальше, если не знаем, как с ними работать.

Пример обработки ошибки и её проброса:

Ошибки в промисах

Промисы — более современный способ работы с асинхронностью в Node. Они позволяют избежать глубокой вложенности (callback hell) и обеспечивают удобный механизм обработки ошибок.

Пример: промис с ошибкой

Здесь, если в fetchData произойдёт ошибка (reject вызывается с new Error()), она будет перехвачена в .catch().

Как правильно обрабатывать ошибки в промисах?

1. Использовать .catch() для перехвата ошибок;
2. Использовать .finally(), если нужно выполнить код в любом случае;
3. Не забывать возвращать промисы из функций.

Пример корректной обработки:

Ошибки в async/await

async/await — современный способ работы с асинхронным кодом, который позволяет писать его в стиле синхронного. Однако ошибки в таком коде не всегда очевидны, особенно если промисы не обернуты в try...catch.

Пример ошибки в async/await:

Если getUser() выбросит ошибку, программа аварийно завершится. Чтобы избежать этого, нужно использовать try...catch.

Как правильно обрабатывать ошибки в async/await?

1. Оборачивать вызовы await в try...catch;
2. Использовать catch() для перехвата на уровне вызова.

Пример правильной обработки:

Или можно обработать ошибку прямо в .catch():

Асинхронные ошибки в Node могут проявляться в коллбэках, промисах и async/await. Каждый из этих подходов требует своей стратегии обработки ошибок:

• В коллбэках всегда проверяйте err;
• В промисах используйте .catch() и .finally();
• В async/await оборачивайте код в try...catch.

Грамотная обработка ошибок в асинхронном коде — залог стабильности и предсказуемости работы Node-приложения.

Чек-лист для новичков: как правильно обрабатывать ошибки в Node.js

Ошибки в коде неизбежны, но грамотная обработка позволяет минимизировать их влияние на работу приложения. Даже если вероятность проблемы кажется низкой, её игнорирование может привести к неожиданным сбоям, утечке данных и того хуже. Рассмотрим, какие шаги должен предпринять новичок, чтобы сделать своё приложение в Node.js устойчивым к ошибкам.

Всегда обрабатывайте ошибки, даже если они маловероятны

Игнорирование ошибок может привести к фатальным последствиям: например, неожиданное исключение может привести к падению всего сервера. Поэтому всегда старайтесь обрабатывать даже маловероятные ошибки.

Пример ошибки без обработки:

Этот код вызовет исключение SyntaxError и остановит выполнение программы.

Правильный вариант с обработкой:

Даже если кажется, что JSON всегда будет корректным, лучше обработать его парсинг в try...catch, чтобы избежать сбоев.

Используйте централизованный обработчик ошибок (middleware в Express)

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

Что делать с централизованным обработчиком ошибок в Express?

1. Определите middleware для обработки ошибок;
2. Все ошибки передавайте через next(error);
3. Express автоматически передаст ошибку в обработчик.

Пример:

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

Логируйте ошибки (например, с помощью Winston или Pino)

Логирование ошибок помогает отслеживать сбои и анализировать их причины. В продакшен-приложениях нельзя ограничиваться console.log() — лучше использовать специализированные библиотеки.

Как работает Winston?

Winston — это гибкий логгер для Node.js, поддерживающий сохранение логов в файлы, базу данных и удалённые сервисы.

Установка:

Настройка логгера:

Использование в коде:

Теперь ошибки будут логироваться как в консоли, так и в файле errors.log.

Генерируйте пользовательские ошибки через Error (или свои классы ошибок)

Вместо простых строковых сообщений об ошибках используйте объекты Error или создавайте собственные классы ошибок для лучшей структуризации.

Простой пример с Error:

Создание собственного класса ошибок:

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

Не забывайте про process.on('unhandledRejection') и process.on('uncaughtException')

В приложениях на Node.js есть два типа необработанных ошибок, которые могут привести к завершению процесса:

• unhandledRejection — когда промис отклонён (Promise.reject()), но у него нет обработчика .catch();
• uncaughtException — когда код выбрасывает исключение, но оно не обрабатывается try...catch.

Чтобы защититься, добавьте обработчики для глобальных ошибок:

Эти обработчики помогут отлавливать неожиданные ошибки и предотвращать аварийное завершение программы.

Добавьте тесты для проверки поведения вашего кода при ошибках

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

Пример теста на обработку ошибок с Jest:

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

Резюмируем:

• Обрабатывайте ошибки, даже если они маловероятны — лучше перестраховаться, чем допустить неожиданный сбой.
• Используйте централизованный обработчик ошибок (middleware) в Express — это упростит код и улучшит поддержку.
• Логируйте ошибки (Winston, Pino) — так вы сможете отслеживать и анализировать сбои.
• Создавайте собственные классы ошибок — это сделает код чище и понятнее.
• Обрабатывайте глобальные ошибки (unhandledRejection, uncaughtException) — чтобы сервер не падал неожиданно.
• Пишите тесты на обработку ошибок — так ваш код будет надёжнее.

Практические примеры: обработка ошибок в Node.js

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

Обработка ошибок в API с использованием Express

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

Что здесь важно?

• Передача ошибок через next(error) — это стандартный способ уведомить Express о том, что произошла ошибка;
• Централизованный обработчик (middleware) позволяет управлять ошибками в одном месте.

Пример пользовательского класса ошибок

Иногда стандартного объекта Error недостаточно для описания специфики ошибки. В таких случаях можно создать собственный класс:

Что здесь важно?

• Так можно чётко разделять типы ошибок;
• Так можно упростить добавление новой логики обработки для каждого типа ошибок.

Как настроить глобальный обработчик ошибок

Некоторые ошибки не обрабатываются в отдельных блоках try...catch или маршрутах. Для таких ситуаций нужны глобальные обработчики ошибок.

Глобальная обработка unhandledRejection и uncaughtException

Глобальные обработчики защищают приложение от аварийных завершений:

Что здесь важно?

• unhandledRejection — позволяет обрабатывать промисы без catch;
• uncaughtException — защищает приложение от ошибок, не пойманных в try...catch.

Пример с промисом:

Обработка ошибок — обязательная часть разработки в Node.js, особенно для приложений в продакшене. Рассмотренные примеры помогут программисту:

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

Частые ошибки при обработке ошибок в Node.js

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

Пропуск ошибок в асинхронных функциях

Асинхронный код в Node.js требует особого внимания, поскольку ошибки в промисах и async/await могут не перехватываться автоматически.

Ошибка: нет обработки ошибок в промисах

Если файл не существует, программа завершится с ошибкой UnhandledPromiseRejectionWarning.

Правильный вариант: обработка через try...catch

Теперь даже если файл отсутствует, приложение не вылетит, а отобразит сообщение об ошибке.

Запоминаем:

• Всегда используйте try...catch внутри async-функций;
• При использовании промисов добавляйте .catch(), чтобы предотвратить unhandledRejection;
• Используйте глобальный обработчик process.on("unhandledRejection"), если работаете с большим количеством промисов.

Логирование конфиденциальных данных

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

Ошибка: логирование чувствительных данных

Ошибка здесь в том, что в логи попадает пароль пользователя.

Правильный вариант: фильтрация логов

Запоминаем:

• Не логируйте req.body, req.headers, req.query без фильтрации;
• Используйте безопасные библиотеки для логирования, например, winston или pino, с возможностью маскировки данных;
• Избегайте передачи ошибок клиенту без обработки — error.message может содержать внутренние данные системы.

Попытка поглощать ошибки вместо их корректной обработки

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

Ошибка: пустой catch-блок

Здесь ошибка просто пропадает — приложение продолжает работать, но данные не загружаются, и отладка становится сложнее.

Правильный вариант: логирование и повторная обработка

Запоминаем:

• Не подавляйте ошибки, если они могут повлиять на логику приложения;
• Логируйте ошибки и передавайте их на следующий уровень обработки, если они критичны;
• Используйте автоматический перезапрос при сбоях, если это возможно (например, с помощью retry-механизмов).

Обработка ошибок в Node.js — не просто техническая деталь, а критически важная часть разработки. Проблемы могут возникнуть в любом месте кода: от синхронных операций до асинхронных вызовов, API-запросов и работы с базами данных. Следование простым правилам поможет разработчику (будь то джун или сеньор) писать более устойчивый код, избегать критичных багов и создавать по-настоящему надёжные приложения в Node.js.

1. Пользователь скачивает специальный набор (пак) эмоджи;
2. Эти эмоджи становятся доступны в личных и групповых чатах, а также в комментариях на каналах;
3. Если кто-то видит необычный смайл, он может узнать, из какого набора он взят, и тоже его скачать.

Создать собственный пак тоже легко, особенно, если вы уже проходили этот процесс со стикерами. Бот тот же самый — @Stickers. Вот алгоритм:

1. Открываем бот, вводим /start и для эмоджи выбираем /newemojipack. На выбор: анимированные эмоджи, видеоэмоджи и статичные.
2. Называем пак.
3. Отправляем боту картинки или анимации в виде файлов, которые станут смайлами. По требованиям: для статичных эмоджи — PNG/WEBP, для видео и анимированных — WEB/TGS, без звука, длительность максимум 3 секунды.
4. Задаем каждому эмоджи из набора аналог из стандартных смайлов;
5. Когда добавляем все, что хотели, запускаем команду /publish.
6. Прописываем короткий юзернейм для пака, например, @tprogerpack — он и будет ссылкой.

Действительно, создать свой пак или добавить уже существующий — проще простого. Правда, есть нюанс: вас могут скомпрометировать. Ниже разбираемся, почему это может произойти.

Почему кастомные эмоджи уязвимы

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

• У каждого пака свой уникальный идентификатор. Если вы используете эмоджи из редкого или персонализированного пака, это оставляет так называемый «цифровой отпечаток». Его можно легко идентифицировать в открытых чатах или каналах. Например, если пользователь скачал пак с мемами своей компании и активно использует эти эмоджи, можно выяснить, где он живет и чем увлекается;
• Telegram позволяет легко находить сообщения в публичных чатах и каналах, где использовались те или иные эмоджи. Если эмоджи из вашего пака появляются в нескольких местах, злоумышленник может собрать все ваши сообщения из этих чатов, даже если вы писали под разными никами. Допустим, используете редкий эмоджи с изображением персонажа из аниме. Хакер может найти ваши сообщения в нескольких чатах и таким образом связать ваши аккаунты в разных сообществах;
• Некоторые кастомные эмоджи создаются специально для каналов или чатов, например, в паблике стримера. Если вы их используете в других местах, то очевидно, что смотрите этого стримера. Да, из 100 000 подписчиков вычислить именно вас будет сложно, но возможно;
• Когда создаёте собственный пак эмоджи и используете его в пабликах или открытых чатах, это фактически становится вашей уникальной меткой. Даже если кто-то другой добавит ваш пак, вероятность его использования останется низкой, а вас легко узнают (если, правда, этот пакт не выстрелит на многомиллионную аудиторию, как с енотом Педро или котами из ТикТока).

Как это работает

Переходим к технической стороне вопроса. В Телеграме у каждого пака с эмоджи или стикерами свой уникальный ID, который можно получить через API. Один из юзеров таким образом вычислил (точнее, ему помогли) создателя стикер-пака https://t.me/addstickers/HotCherry.

Дисклеймер: это не совсем законно, поэтому мы рассмотрим этот пример, чтобы показать вам, что любая система уязвима.

Главное поле здесь — ID. Да, на первый взгляд он кажется уникальным идентификатором стикерпака и никак не поможет вычислить аккаунт автора. Но не устанем повторять: есть один нюанс.

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

Число 1391391008142393345 можно представить в двоичной системе. Так мы доходим от 0 до 32. Если перевести в обычное значение, то получится более короткий и узнаваемый идентификатор 323958464. Так автору удалось выяснить, что это не идентификатор стикерпака, а идентификатор конкретного пользователя Telegram.

Пользователь с этим идентификатором в Telegram — создатель стикерпака.

Но есть проблема: по числовому ID, который мы получаем, нельзя напрямую определить, что это за пользователь — его имя, аватар и так далее, так как в API просто нет такого метода. Но как же автору это удалось?

Существует обратный метод API, позволяющий получить профиль пользователя и его ID по имени. Этот метод вызывается каждый раз, когда вы открываете ссылку [t.me/<login](http://t.me/<login) user> или ищете по имени в Telegram.

Он просканирует всех пользователей Telegram (например, взяв их из всех публичных чатов) и составит соответствие: ID<>имя пользователя. Такое можно проделать с любым стикерпаком или паком с эмоджи, опубликованном в конкретном канале, и есть шанс выйти на админа.

Maltego, или как парсить данные не вручную

Под Телеграм уже написали инструменты, которые помогают собирать и анализировать данные. И Maltego — одна из таких фич, которая работает с открытыми источниками (OSINT). Она лежит в открытом доступе на Github. Maltego может помочь деанонимизировать пользователя через кастомные эмоджи, если они оставляют за собой «цифровой след». Уже знакомый нам экспериментатор тоже поюзал этот инструмент, для этого ему еще понадобился Python — почитать подробнее можно в той же статье.

Рассказываем, как это происходит:

1. Уникальность кастомных эмоджи

Как мы уже писали, каждый кастомный эмоджи принадлежит определённому набору (паку), который имеет уникальный ID. Если вы используете редкий пак, это как отпечаток пальца — его можно легко отследить.

2. Сбор данных о сообщениях в пабликах

Maltego может анализировать публичные чаты и каналы Telegram:

• Найти все сообщения, где использовались ваши кастомные эмоджи;
• Определить, в каких каналах или группах вы активно пишете;
• Собрать сообщения, даже если вы используете разные никнеймы.

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

3. Связывание аккаунтов

Если вы используете кастомные эмоджи в нескольких местах, Maltego об этом тоже узнает. Даже когда стараетесь оставаться анонимным, использование одного и того же эмоджи выдаёт, что оба аккаунта принадлежат вам.

Например, в одном чате вы пишете с анонимного аккаунта, а в другом — с основного, но используете одинаковые эмоджи. Maltego это заметит.

4. Поиск пользователей с таким же паком эмоджи

Если злоумышленник знает ID вашего кастомного пака, Maltego может:

• Найти, кто добавил этот пак в Telegram;
• Узнать, кто ещё использует эти эмоджи;
• Связать вас с теми, кто скачал этот пак.

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

5. Использование API для анализа

Maltego подключается к Telegram API, который предоставляет доступ к информации о публичных чатах и пользователях. Так он может:

• Найти все сообщения с конкретным эмоджи;
• Узнать, кто чаще всего использует эмоджи из определённого пака;
• Собрать данные и построить граф связей между пользователями.

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

Почему это опасно

Как говорили в фильме «Кто я», любая система уязвима, и об этом нужно помнить всегда. Maltego или другие подобные ему инструменты не могут напрямую «взломать» вас, но их главная сила — в аналитике и парсинге. Даже одно сообщение, которое вы оставили в паблике с кастомным эмоджи, может раскрыть ваши интересы, знакомства, активность и даже локацию. А потом уже дело за малым.

Как предотвратить деанонимизацию: методы

Кастомные эмоджи или стикерпаки в Telegram могут раскрыть больше информации о вас, чем вы думаете — достаточного одного сообщения. Но есть несколько простых советов, которые помогут оставаться в безопасности (насколько это возможно).

Не используйте редкие эмоджи в публичных чатах

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

Не переусердствуйте с эмоджи

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

Настройте приватность в Telegram

В настройках Telegram есть функции, которые помогут скрыть ваши личные данные:

• Скрывайте свой номер телефона, чтобы его не могли увидеть другие пользователи;
• Сделайте так, чтобы ваш аватар и информация о последнем посещении видели только друзья или те, кого вы добавляете в контакты. Хотя, конечно, лучше вручную составить список юзеров, у кого есть доступ к вашим данным;
• Отключите доступ к вашим данным для незнакомых людей. Например, поставьте настройки, чтобы при пересылке сообщения ваш аккаунт оставался анонимным.

Используйте разные аккаунты

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

Политика Telegram по защите данных

Telegram утверждает, что заботится о безопасности пользователей, но есть нюансы, которые стоит учитывать:

• Сообщения в публичных чатах открыты для анализа. Если вы пишете в большом канале или группе, ваши сообщения все равно попадают в открытый доступ, и их можно найти с помощью парсинга;
• Доступ к данным через Telegram API. API позволяет извлекать информацию о пользователях и их действиях. Отключить его никак нельзя, поэтому старайтесь не использовать уникальные эмоджи в пабликах;
• Используйте секретные чаты. Только секретные чаты в Telegram имеют сквозное шифрование — никто, кроме участников, не сможет получить доступ к сообщениям. Плюс можно поставить полное удаление переписки или определенных сообщений через какое-то время.

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

Что такое JSON

JSON или JavaScript Object Notation — формат для обмена данными. Его используют в веб-разработке, чтобы передать числовую информацию от клиента к серверу и наоборот. По сути это просто строка, но с нюансами.

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

• Объекты — пары “ключ-значение” в фигурных скобках. Выглядят так же, как обычные JS-объекты;
• Массивы — упорядоченные значения. Заключаются в квадратные скобки и отделяются запятой;
• Ключи — строки, которые обязательно в двойных кавычках. Одинарные не подойдут;
• Значения — могут быть строками в двойных кавычках, числами, логическими значениями, массивами, объектами или null.

Мы не зря упоминаем двойные кавычки. Очень важно следить за ними, иначе сервер или ваш сайт не смогут обработать JSON.

Пример JSON-документа:

В этом примере объект содержит четыре ключа:

• name — строка,
• type — строка,
• topics — массив строк,
• published — логическое значение, true.

Этот JSON описывает воображаемую статью, у которой есть темы, название и статус публикации.

Зачем нужен JSON, если есть XML?

До JSON разработчики использовали XML. Вот основные отличия:

Давайте разберём все пункты и посмотрим, в чём же конкретно хорош JSON.

Синтаксис

JSON

Выглядит как обычный JavaScript-объект.

Пример:

Мы создали объект с двумя ключами. Имя –– John, возраст –– 30. Это упрощённый вариант хранения данных о пользователе. Также можно добавить почту, ник, город и так далее.

XML

XML или (Extensible Markup Language) –– посложнее, так как использует закрывающиеся теги. Это делает его визуально более «шумным» и трудным для восприятия. Особенно если XML-данных много.

Размер данных

JSON

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

XML

XML объемнее, потому что каждый элемент должен быть обёрнут в открывающий, а потом закрывающий тег.

Легкость парсинга

JSON

JSON легко парсить. В JavaScript достаточно использовать JSON.parse(), чтобы преобразовать JSON-строку в JS-объект.

Пример:

Здесь мы поместили JSON-строку в переменную и затем распарсили её в другую переменную с помощью функции JSON.parse().

XML

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

Пример на JavaScript:

Что здесь происходит:

1. Создаем строку, которую хотим превратить в XML. Она содержит элемент с вложенными элементами;
2. Используем объект DOMParser. Он превращает текстовые строки в XML-документы;
3. Метод parseFromString() выполняет это преобразование. После этого js работает с переменной через DOM-методы;
4. Используем метод getElementsByTagName(), чтобы получить значение элемента . Он возвращает массив элементов с указанным тегом;
5. Указываем индекс [0] для выбора первого элемента, а затем получаем его текстовое содержимое через childNodes[0].nodeValue.

Разница очевидна:

• Для JSON мы можем сразу преобразовать строку в объект с помощью JSON.parse();
• Для XML требуется больше шагов: разбор строки в документ и использование методов DOM для извлечения данных.

Читаемость

JSON

JSON легко читать, потому что его структура похожа на JavaScript-объект. Он не требует лишних символов и тегов, поэтому визуально лаконичен и прост.

XML

XML выглядит сложнее. Теги для описания структуры делают документ более громоздким и менее читаемым. Особенно если в файле много вложенных элементов.

Создаём и парсим JSON

JSON-документы можно создать вручную. Главное, надо соблюдать синтаксические правила:

• Использовать двойные кавычки для строк;
• Разделять ключи и значения двоеточием, как и в JS-объектах;
• Ставить запятые между ключами.

А можно использовать конвертер. Вы ему JS-объект, а он из него –– JSON.

В разных языках –– разные инструменты для работы с JSON. Разработчики используют встроенные средства языков программирования или сторонние библиотеки:

• JavaScript: Методы JSON.stringify() и JSON.parse();
• Python: Модуль json для сериализации и десериализации;
• PHP: Функции json_encode() и json_decode();
• Node.js: Встроенные методы для работы с JSON в модуле fs.

Работа с JSON в Python

Что тут происходит:

1. Импортируем json. Это встроенная библиотека Python. Она работает с данными в формате JSON;
2. Создаём данные для сериализации –– Python-словарь data, который содержит пары ключ-значение. Не пугайтесь нового слова «сериализация». Это всё то же преобразование одного формата в другой;
3. Используем метод json.dumps() для преобразования Python-объекта в строку в формате JSON. Результатом будет строка, которую можно передать серверу, сохранить в файл или обработать в другой программе;
4. Десериализириуем данные с помощью метода json.loads(). Он преобразует JSON-строку обратно в Python-объект;
5. Выводим десериализованные данные в консоль. В данном случае это словарь parsed_data, который будет точно таким же, как и исходный словарь data.

Работа с JavaScript

Методы JSON.stringify() и JSON.parse() позволяют преобразовывать данные из объекта в JSON-строку и обратно.

Пример:

Метод fetch() используется для отправки HTTP-запросов с JSON-данными:

Что здесь происходит:

• Мы указываем, куда нужно сделать запрос и что нужно передать серверу. Посылка –– это значение в ключе body. Если не обернуть объект с данными в JSON.stringify(), то запрос упадёт. Так как этот метод превращает JS-объект в JSON-строку. Сервер умеет читать JSON, но не умеет работать с JS-объектами;
• На предпоследней строке мы получаем ответ от сервера. А затем обязательно переводим его обратно, в удобоваримый для JS код.

Работа с JSON на сервере

JSON незаменим в бэкэнде. Сервер присылает данные через REST API в JSON. Поэтому в предыдущем блоке мы использовали на ответе метод .json(). Без него данные останутся обычной JSON-строкой.

Разберём примеры на разных языках.

Пример реализации REST API на Node.js

Здесь мы создаём приложение на основе Express. Оно слушает POST-запросы на маршруте /data и возвращает ответ в формате JSON с сообщением о том, что данные получены.

Для работы с JSON на сервере используем встроенную функцию express.json(), которая парсит данные, и метод res.json(), чтобы отправить ответ в формате JSON.

Пример работы JSON в python-фреймворке Flask

Что делаем:

1. Импортируем необходимые библиотеки: Flask, request, jsonify для создания нашего веб-приложения и обработки JSON-строк;
2. Создаем приложение через экземпляр Flask;
3. Определяем маршрут /data и указываем, что функция handle_data() будет обрабатывать по этому маршруту POST-запросы;
4. Извлекаем JSON-данные из запроса внутри функции. Получаем и преобразуем данные из тела запроса в JSON с помощью request.get_json();
5. Отправляем JSON-ответ. Возвращаем клиенту JSON-ответ, содержащий полученные данные. Либо, если переменная data пуста, отправляем ошибку и 400 статус. И обязательно отлавливаем ошибки с помощью try-except;
6. Запускаем приложение. Приложение запускается на сервере и слушает входящие запросы.

Что не так с JSON

За простотой JSON скрываются ловушки, попадать в которые лучше не надо. Малейшая ошибка — и данные становятся нечитаемыми, а приложение падает. Разберём эти ловушки:

Неправильная структура

Забудете закрыть скобку, добавите не ту кавычку или поставите запятую в конце массива — и всё. Браузер или сервер выдадут ошибку. А если JSON создается динамически, найти проблему будет сложно.

Пример ошибки:

В этом примере после крайнего элемента массива стоит лишняя запятая. Исправленный вариант:

Большие объемы данных

JSON не предназначен для хранения огромных массивов данных. Обрабатывать большие файлы в браузере –– опасно для производительности. Ваш сайт может начать тормозить или вовсе зависнуть.

Неэкранированные символы

Забыли экранировать кавычку в строке? Получите ошибку. JSON требует строго соблюдать правила синтаксиса, иначе парсинг провалится.

Пример ошибки:

Здесь у нас дублирование. Нельзя помещать двойные кавычки внутрь таких же двойных кавычек:

Исправленный вариант:

Уязвимая безопасность

Если данные не проверяются, JSON может стать источником XSS-атак или привести к раскрытию конфиденциальной информации.

Пример ошибки:

Пользователь может отправить через поле ввода вредоносные данные. И получится вот такая история:

Решение: обязательно проверяйте входящие данные. Можно заменить опасные символы безопасными:

И уже эту строку отправить на сервер.

Как избежать проблем с JSON?

Чтобы работать с JSON безопасно и эффективно:

• Используйте валидаторы. Перед передачей данных обязательно проверяйте JSON на синтаксические ошибки;
• Сжимайте данные. Уменьшайте размер JSON, удаляя лишние пробелы и символы, чтобы оптимизировать передачу и обработку;
• Не доверяйте входящим данным. Проверяйте и фильтруйте всё, что приходит от клиента или сторонних API;
• Ограничивайте глубину вложенности. Глубокая структура JSON может перегрузить обработчик и вызвать зависание.

Валидаторы JSON

Перед отправкой проверьте свой JSON. Для этого можно использовать онлайн-валидаторы. Например, https://jsonlint.com. Как он работает: вы прописываете вашу строку, а валидатор проверяет, нет ли в ней ошибок.

Минификация JSON

Для уменьшения размера JSON-строку можно минифицировать. Удалить пробелы и переносы строк. Пример минификации в Python:

Обработка ошибок при работе с JSON

Ошибки часто возникают из-за неправильного формата данных. Всех опасных мест не избежать. Но можно подстелить соломку.

Вот так обрабатываются возможные ошибки с JSON:

Что тут происходит:

1. Получаем данные из localStorage: Используется метод localStorage.getItem(), чтобы извлечь данные по указанному ключу key;
2. Проверяем на наличие данных: Если данные отсутствуют –– null, выбрасывается ошибка с помощью throw;
3. Парсим данные: Если данные есть, они парсятся через JSON.parse(). И на выходе получается JS-объект;
4. Обрабатываем ошибки: В блоке catch ловятся все ошибки. Затем их можно обработать и отобразить пользователю в интерфейсе.

Теперь даже если в LocalStorage не лежат нужные данные, приложение не упадёт.

В веб разработке без JSON никуда. Он лёгкий и гибкий. Но чтобы использовать эти преимущества, нужно научиться с ним взаимодействовать.

Для этого просто следуйте нашим правилам. Проверяйте свои JSON-строки, обрабатывайте ошибки и тестируйте приложение на корнер-кейсы. Тогда ваши сайты и приложения будут в безопасности. 🙂

Чтобы использовать эти инструменты, вспомним основы HTML, DOM-дерева и принципы работы динамических страниц.

BeautifulSoup — простая библиотека для парсинга HTML на Python: подходит для небольших задач, статических страниц и быстрых скриптов.

Scrapy — полноценный асинхронный фреймворк для масштабного парсинга: встроенные pipelines, управление прокси, ротация User-Agent и экспорт в JSON/CSV/XML.

Для динамических сайтов с JavaScript ни BeautifulSoup, ни Scrapy не работают напрямую — нужен Selenium или Playwright, имитирующий браузер.

Если сайт предоставляет API — всегда предпочитайте его парсингу: меньше нагрузка на сервер, структурированные данные, официальная документация.

Соблюдайте этику парсинга: уважайте robots.txt, делайте задержки между запросами 1–3 секунды и собирайте только те данные, которые действительно нужны.

Основные понятия парсинга данных

HTML-документ — это текстовый файл с расширением .html. Он содержит набор элементов для отображения страницы в браузере.

Структура HTML-документа состоит из двух частей: заголовка (head) и тела (body). Весь документ обрамляется корневым тегом html.

Заголовок содержит метаданные, стили, скрипты, заголовок страницы. В теле документа находятся теги и основной контент, который отображается в окне браузера.

DOM-дерево — это представление HTML-документа в виде древовидной структуры объектов. Каждый элемент HTML становится узлом этого дерева. Благодаря DOM можно взаимодействовать с элементами страницы через JavaScript:

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

Корневой элемент DOM-дерева — тег html. От него идет разветвление на head и body — его прямых потомков. Остальные элементы образуют более глубокие уровни вложенности.

Тут можно посмотреть, как выглядит DOM-дерево для определенного фрагмента кода.

Статические страницы содержат фиксированный HTML. Его код не меняется после загрузки. По этой причине статические страницы проще парсить. Достаточно отправить HTTP-запрос и будет получен весь HTML-документ, из которого можно извлечь целевые теги. С этой задачей успешно справляются любые библиотеки для парсинга: Requests, BeautifulSoup, Urllib3 и другие.

Динамические страницы формируют контент с помощью JavaScript после загрузки основного HTML. Контент может подгружаться через API, изменяться при взаимодействии пользователя или обновляться автоматически.

Простой HTTP-запрос не парсит динамически загруженные сайты. Для этого нужны инструменты, эмулирующие работу браузера. Например, Selenium WebDriver. Он запускает браузер, выполняет JavaScript-код и парсит финальное DOM-дерево с динамическим контентом.

Этические и юридические аспекты парсинга данных

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

Что можно делать:

• Собирать информацию, которая находится в открытом доступе.
• Парсить данные, не нагружая сайт и не мешая его работе.

Чего нельзя делать:

• Воровать закрытую информацию компаний.
• Собирать личные данные пользователей (телефоны, адреса, паспортные данные).
• Намеренно вредить работе сайта большим количеством запросов.

Перед сбором данных задавайте себе простой вопрос: «Мне понравится, если кто-то соберет эту информацию обо мне?» Подумайте также о том, приносит ли ваш парсинг пользу другим людям или вы делаете это только ради собственной выгоды.

Если закон разрешает какие-то действия, это не значит, что их правильно делать с моральной точки зрения. Например, технически возможно собрать все комментарии человека в соцсетях, но будет ли это этично по отношению к нему?

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

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

BeautifulSoup: простой и удобный инструмент для парсинга

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

Откройте терминал и выполните команду:

Установите парсер lxml:

Также понадобится библиотека requests для выполнения HTTP-запросов:

Самый простой парсер на BeautifulSoup:

Основные функции и методы библиотеки

Найти первый абзац:

Найти все абзацы:

Один элемент с классом 'content':

Все элементы с классом 'content':

Поиск ссылки по href:

Поиск по нескольким атрибутам:

Найти все абзацы с определенным классом:

Найти все ссылки внутри div с определенным id:

Плюсы BeautifulSoup

• Простой синтаксис, поэтому библиотекой пользуются даже начинающие разработчики.
• Гибкий поиск элементов ищет теги по имени, классу, id, атрибутам. Можно комбинировать условия поиска и использовать CSS-селекторы.
• Автоматическое исправление невалидного HTML. BeautifulSoup пытается восстановить неправильную структуру документа, что полезно при работе с некачественной версткой.
• Низкие требования к ресурсам компьютера по сравнению с браузерными решениями вроде Selenium.

Недостатки BeautifulSoup

• Нет поддержки JavaScript. Библиотека работает только со статическим HTML и не может обрабатывать динамически загружаемый контент.
• Ограниченная производительность при работе с большими документами. Для парсинга крупных файлов лучше использовать потоковые парсеры.
• Отсутствие встроенной поддержки асинхронности. Для параллельной обработки нескольких страниц требуются дополнительные библиотеки asyncio и aiohttp

BeautifulSoup не подходит для парсинга сайтов с динамической загрузкой контента, высоконагруженных проектов. Для этих целей выбирайте фреймворк Scrapy.

Scrapy: мощный фреймворк для парсинга больших объемов данных

Scrapy — это фреймворк для парсинга сайтов, построенный на асинхронной архитектуре. Рассмотрим его основные компоненты.

Пауки (Spiders) — это классы, которые определяют как парсить конкретный сайт. В пауке указываются начальные URL-адреса, правила извлечения данных и переходов между страницами. Паук обходит страницы сайта и извлекает информацию с помощью CSS-селекторов или XPath-выражений.

Элементы (Items) — это контейнеры для хранения извлеченных данных. Они похожи на словари Python, но предоставляют дополнительную валидацию полей. Items определяют структуру данных, которые будут собраны пауком.

Каналы обработки (Pipelines) — это компоненты для обработки извлеченных данных. Каждый элемент проходит через цепочку pipeline-обработчиков. В pipeline можно выполнять очистку данных, удалять дубликаты, сохранять информацию в базу данных.

Парсинг HTML на Scrapy выглядит так:

1. Паук отправляет запрос к сайту.
2. Получает ответ и извлекает данные.
3. Создает элементы с данными.
4. Передает элементы в pipeline.
5. Pipeline обрабатывает и сохраняет данные.

Установка и настройка Scrapy

Откройте терминал и выполните команду::

Создайте новый проект:

Эта команда создаст структуру каталогов — файлы настроек и шаблоны пауков.

Файл settings.py содержит основные настройки проекта. Базовые параметры, которые требуют настройки:

• USER_AGENT = 'Mozilla/5.0...' (идентификация парсера).
• ROBOTSTXT_OBEY = True (соблюдение правил robots.txt).
• CONCURRENT_REQUESTS = 16 (количество одновременных запросов).
• DOWNLOAD_DELAY = 1 (задержка между запросами).
• COOKIES_ENABLED = False (использование cookies).

Для создания нового паука используйте команду:

Пример простого паука:

Запуск паука выполняется командой:

Для сохранения результатов в файл:

Для обработки данных перед сохранением используется pipelines.py:

Активация pipeline происходит в settings.py:

Плюсы Scrapy

• Обрабатывает запросы асинхронно.
• Автоматически управляет порядком обработки URL и перераспределяет нагрузку.
• Легко добавлять прокси-серверы, ротацию User-Agent, обработку ошибок.
• Встроенная поддержка экспорта в JSON, CSV, XML.

Недостатки Scrapy

• Сложность отладки асинхронного кода.
• Ограниченная поддержка JavaScript.

Сравнение BeautifulSoup и Scrapy

Выбор инструмента зависит от масштаба задачи. Для извлечения данных с нескольких страниц достаточно BeautifulSoup. Для создания поискового робота или регулярного парсинга больших объемов данных оптимальным выбором будет Scrapy.

Парсинг на Python BeautifulSoup лучше подходит для:

• Парсинга отдельных страниц.
• Небольших скриптов.
• Интеграции в существующие проекты.

BeautifulSoup дает разработчику полную свободу в организации кода и выборе дополнительных инструментов, но ограничивается только базовыми функциями извлечения данных.

Scrapy эффективнее для:

• Парсинга интернет-магазинов с тысячами товаров.
• Регулярного мониторинга цен конкурентов.
• Полноценных парсинг-проектов со сложной логикой обработки.

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

Продвинутые техники парсинга

Динамически загружаемый контент — это проблема при парсинге. Чтобы выгрузить целевой контент со страницы, нужно имитировать действия пользователя. Для этого часто используют Selenium. Библиотека управляет браузером — загружает страницы, выполняет JavaScript и получает доступ к DOM после его изменения.

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

Пример ожидания:

Еще можно использовать time.sleep, но это менее эффективно — задержка фиксирована и не зависит от скорости загрузки страницы.

Если контент загружается через AJAX, можно использовать execute_script для проверки состояния загрузки. Например, можно проверить значение переменной JavaScript, которая отслеживает состояние загрузки.

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

Работа с API

Многие сайты предоставляют API для получения данных. Это предпочтительный способ парсинга на Python. Сбор данных через API:

• не нагружает сервер излишними запросами;
• предоставляет данные в структурированном виде;
• обычно имеет официальную документацию.

Для работы с API в Python есть библиотека requests.

Большинство API имеют ограничения на количество запросов. Для их соблюдения нужно добавлять задержки.

Использование прокси и обход блокировок

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

В Python для работы с прокси нужно импортировать библиотеки requests и urllib. Достаточно указать адрес прокси в параметрах запроса.

Пример использования прокси с requests:

Ваш парсер останется незамеченным, если выполнять подмену User-Agent, ставить задержки между запросами, настроить автоматическое распознавание капчи.

Если сайт предоставляет API, лучше делать запросы через него — это наиболее безопасный и эффективный способ.

Рекомендации по парсингу данных

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

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

• JSON подходит для иерархических данных и удобен для дальнейшей обработки в Python.
• CSV эффективен для табличных данных и открывается в Excel.

Для больших объемов информации используйте БД — SQLite для небольших проектов, PostgreSQL для масштабных. Создавайте промежуточное хранилище перед финальной записью — это защитит от потери информации при сбоях. Для Data Science — отдельная подборка топ-10 библиотек.

Задержки между запросами — обязательный элемент парсинга. Базовая рекомендация — выдерживайте паузу 1-3 секунды между запросами. Для высоконагруженных сайтов увеличивайте интервал до 5-10 секунд.

Дополнительные советы по созданию парсера:

• Реализуйте систему логирования для отслеживания ошибок и прогресса.
• Обрабатывайте сетевые ошибки, делайте повторные попытки с экспоненциальной выдержкой.
• Используйте прокси, User Agent для распределения нагрузки и маскировки запросов.
• Проверяйте работоспособность парсера перед запуском, так как структура сайтов может меняться.

Это вызвало у нее интерес к анализу и поиску оптимизаций, особенно после использования новой библиотеки #[iex], которая фокусируется на улучшении обработки ошибок.

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

19-летняя разработчица Алиса Сиренева из Москвы ускорила популярную Rust-библиотеку serde_json на 32% с помощью SIMD и SWAR-оптимизаций.

Узкое место нашлось в функции position_of_index — она замедляла путь обработки ошибок в два раза по сравнению с успешным путём.

Ключевое решение — замена медленного линейного поиска на библиотеку memchr, использующую SIMD-инструкции процессора для ускорения поиска символов.

Все изменения приняты в основную ветку serde_json и доступны миллионам Rust-проектов по всему миру.

Решение через оптимизацию

Чтобы устранить узкое место, разработчица предложила заменить функцию position_of_index на более эффективную реализацию с использованием библиотеки memchr, которая задействует SIMD-инструкции для быстрого поиска символов.

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

Новые горизонты оптимизации

Воодушевленная успехом, девушка продолжила поиск возможностей для улучшений. Ее внимание привлекли циклы, ответственные за парсинг строк, которые также можно было оптимизировать с помощью SIMD и SWAR (SIMD Within A Register).

Хотя не все предложенные методы показали себя одинаково эффективно, использование SWAR оказалась более продуктивным и привело к значительным улучшениям производительности.

По итогу идеи, предложенные Алисой, показали прирост скорости работы serde_json до 32% в различных тестах, связанных с обработкой строк.

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

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

Выбираем сайт

Для гайда я выбрала ресурс otzivisotrudnikov.ru, поскольку он позволяет не только провести парсинг, но и попробовать сопутствующие действия selenium вроде ожидания появления страницы и нажатия кнопки «Загрузить еще».

Если вы только осваиваете скрэйперы, к сложным порталам, сопротивляющимся парсингу, пока подступаться не стоит. Среди них — все продукты Яндекса, а также Авито. Некоторые популярные площадки вроде HeadHunter, «ощутив пауков на себе», поступили демократично и создали API для выгрузки данных.

Подготовка среды разработки

Для начала импортируем необходимые библиотеки:

Загоняем инструментарий в файл requirements.txt:

Создаем виртуальное окружение и устанавливаем инструменты:

Я хочу наладить коллекцию пауков таким образом, чтобы новые отзывы отправлялись мне в Telegram. Для этого предстоит создать бота. Чтобы получить ключ, перейдите по адресу my.telegram.org/apps, авторизуйтесь и создайте приложение (документация). API Key лежит в поле App api_hash:

Чтобы получить ID чата, добавим туда бота @RawDataBot и запустим командой /start. В ответ он отдаст массив, среди которых есть и идентификатор:

Это целочисленная переменная, знак минус тоже оставляем:

Чтобы получить токен, нужно пообщаться с @BotFather — утилитой для создания и настройки ботов. Если у вас пока нет ботов в TG, следуйте этой краткой инструкции.

Когда скрейперов становится слишком много, оптимальным решением будет .env-файл. О работе с этим инструментом можно узнать больше в статье “Using .env Files for Environment Variables in Python Applications”.

Вы могли заметить, что некоторые сайты защищаются от DDoS-атак с помощью спецсервисов. Selenium умеет обходить такие проверки. В случае сайта «Отзывы сотрудников» достаточно подождать несколько секунд, обычно хватает пяти:

Зададим полную ссылку на страницу:

Отзывов много, потому нам потребуется нажать кнопку «Больше». Чтобы это сделать, укажем число нажатий (число страниц пока проверяется вручную):

Инициируем бота для отправки новых отзывов:

Теперь настал через самого Selenium. Инициируем экземпляр веб-драйвера и передадим ему целевую ссылку:

Объявим временные списки, в которых будем хранить тексты отзывов, ссылки на них и дату публикации:

Отдадим команду selenium выполнять поиск элементов на каждой странице:

Как быстрее писать селекторы

Выбор элемента в HTML — одна из сложных вещей для новичков в парсинге. Потому попробую упростить вам дальнейшую работу с помощью концепции XPath. Это язык запросов для веб-страниц, и корректность селектора можно проверить в панели разработчика Chrome:

• нажимаем на любом свободном месте на веб-странице «Просмотреть код» (или комбинацией Ctrl + Shift + C / Cmd + Shift + C);
• выбираем наведением мыши один отзыв со всеми интересующими элементами и копируем название класса (col-xs-10);
• нажимаем комбинацию Ctrl + F / Cmd + F прямо в панели разработчика. Откроется поле поиска по селектору;
• набираем //* (отсылает к всей странице на языке XPath), затем [@class=’col-xs-10′];

Посмотреть, как проверяется селектор, можно на видео.

Записей несколько, потому я использую метод find_elements(). Укажем класс, который предстоит найти:

Теперь результат хранится в специальном объекте selenium-webdriver.WebElement, и чтобы извлечь из него текст, используется метод text().

Звездочка, кстати, помогает справляться с меняющимися названиями классов: вы можете подставлять ее аналогично сочетанию (.*) в регулярных выражениях, и в случае "//*[@class='col-*']" она будет цеплять все объекты классов, начинающихся с col-.

В сниппете ниже я удаляю фразу, которая не нужна в выгрузке заказчикам проекта:

Теперь выделим тем же образом ссылки, они зашиты в кнопки «Читать полностью отзыв и комментарии» (класс ‘read-more-serm‘):

Осталось вычленить время создания отзыва:

Теперь троицу выше превратим в словарь:

Преобразуем словарь в таблицу методом pd.DataFrame():

Добавим столбец с автоматическим индексом:

Сохраним результат в файл.csv:

Отправим отзывы по одному в чат Telegram:

Кстати, параметр parse_mode позволяет подключить HTML-разметку и улучшить читаемость отзыва. Разделы «Список льгот», «Что мне нравится в работодателе» и «Что можно было бы улучшить» были «обернуты» полужирным шрифтом (…):

Заключение

Конечно, существуют и low-code решения для сбора данных с веба, однако полную управляемость по-прежнему обеспечивают лишь самописные инструменты вроде selenium и beautifulsoup4. Подспорьем новичкам в этой нелегкой задаче, где структура HTML-документа то и дело меняется, может стать подборка пауков на GitHub. Добросовестная часть авторов их даже обернула в Docker, а это значит, что процесс деплоя и дотяжки селекторов до актуального состояния займет у вас минимум времени.

Полный код можно посмотреть по ссылке.

Детекторы ботов вроде Cloudflare готовы защищать сайты от наших ботов. Настройка Selenium с помощью ChromeOptions слишком громоздкая, а на Windows становится совсем кошмарной. Отладка ботов через журналы — тоже слишком сложно.

Как решить эти боли, не жертвуя скоростью и удобством разработки? Попробуйте Bose.

Bose, как уверяют разработчики фреймворка, — это первая среда разработки ботов, которая максимально упрощает разработку ботов. Фреймворк основан на на Selenium и предлагает ряд функций, упрощающих разработку.

Настраиваем Bose

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

Затем перейдите в скачанный каталог, установите зависимости и запустите проект:

Первый запуск займет некоторое время. Всё потому, что он загружает исполняемый файл драйвера Chrome. Следующие запуски будут гораздо быстрее.

Основные особенности Bose Framework

Добавляет мощные методы, чтобы сделать работу с Selenium намного проще.

Применяет лучшие практики, чтобы избежать обнаружения ботов Cloudflare и PerimeterX.

Сохраняет HTML, снимок экрана и сведения о выполнении для каждой задачи, что упрощает отладку.

Вспомогательные компоненты для записи очищенных данных в виде файлов JSON, CSV и Excel.

Автоматически загружает и инициализирует правильный драйвер Chrome.

Быстро и удобно для разработчиков.

Работаем с Bose

Допустим, вы хотите начать парсинг веб-сайта. Если бы вы использовали Selenium, вам пришлось бы обрабатывать задачи по открытию и закрытию драйвера следующим образом:

Однако Bose Framework использует декларативный и структурированный подход. Вам нужно только написать код ниже, а драйвер Bose сам создаст драйвер, передаст его методу run и закроет работу.

Конфигурация Bose

В Selenium, если вы захотите настроить параметры вроде профиля, пользовательского агента или размера окна, нужно будет написать много кода:

Bose Framework упрощает конфигурацию, инкапсулируя её в свойстве BrowserConfig:

Обработка исключений

Исключения — это боль при работе с Selenium.

В Selenium, если возникает исключение, драйвер автоматически закрывается, оставляя вам только журналы для отладки.

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

Отладка в Bose Framework

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

Bose упрощает отладку, сохраняя информацию о каждом запуске.

После каждого запуска в задачах создается каталог, содержащий три файла, перечисленных ниже:

Файл содержит информацию о выполнении задачи: продолжительность выполнения задачи, IP-адрес задачи, пользовательский агент, размер окна и профиль, который использовался для выполнения задачи.

Это снимок экрана, сделанный до закрытия драйвера.

Это исходный HTML-код, полученный до закрытия драйвера. Код страницы полезно знать, если селекторам не удалось выбрать элементы.

В случае, если ваша задача рухнула из-за исключения, Bose сохраняет error.log с ошибкой, из-за которой задача рухнула.

Вывод данных

После выполнения парсинга веб-страниц нужно сохранить данные в формате JSON или CSV. Как правило, этот процесс подразумевает написание огромного объёма императивного кода:

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

Все данные будут сохранены в папке output/:

Локальное хранилище

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

Вы можете импортировать объект LocalStorage из Bose, чтобы сохранять данные при запуске браузера, что чрезвычайно полезно при очистке больших объемов данных.

Данные хранятся в файле local_storage.json в корневом каталоге проекта. Вот как можно его использовать:

Другие возможности

Драйвер, полученный при запуске задачи — это расширенная версия Selenium, в которую добавлены мощные методы, упрощающие работу.

Вот некоторые из популярных методов, добавленных в драйвер:

Заключение

Bose — отличный фреймворк, упрощающий скучные части Selenium и парсинга веб-страниц.

Желаем вам удачи и счастливой разработки ботов с помощью Bose Framework!

Подключение библиотеки Goutte и создание запроса на сайт

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

Получение текстовой информации с помощью Goutte

Используя метод filter вы можете указать селектор для выборки элементов. Так как на данной странице используется несколько элементов с классом home_heading_post мы будем использовать метод each.

Получение атрибута href ссылки

Получение атрибута src изображения

Фильтрация выборки (выборка элементов через один)

Используйте метод reduce для указания функции для фильтрации выборки. В моём примере указана функция которая задаёт порядок «через 1» и “каждый десятый элемент”.

Получение элемента указанного порядка

С помощью метода eq вы можете указать номер элемента. Нумерация идёт с 0, поэтому в моём примере и мы получим 4 элемент с классом “home_heading_post”.

Получение первого и последнего элемента

first() — возвращаем первый элемент.
last() — возвращает последний элемент.

Получение соседнего элемента на уровне в дереве DOM

siblings() — возвращает соседние элементы в дереве DOM.

Получение ссылки по тексту и нажатие на ссылку

С помощью метода selectLink() получаем ссылку, в качестве параметра передадим текст внутри ссылки.

С помощью метода link() переходим по ссылке и получаем новую страницу.

С помощью метода getUri() получаем URI ссылки.

Получение объекта изображения

Получение дочерних элементов

Отправка формы с помощью Goutte

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

Виды прокси

Обычные (серверные или ЦОД) — это статические адреса. Такие адреса не совсем надёжны, поскольку, как только целевой сервер определит ваш IP как «недобросовестный», он его заблокирует. Такие прокси приходится покупать пачками и постоянно менять.

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

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

Кто и зачем использует мобильные прокси?

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

SEO-специалисты. При парсинге, сборе семантического ядра и работе с большими объёмами данных не обойтись без прокси. В этом случае использование адресов имеет обязательный, а не рекомендательный характер. Чем больше хотите парсить — тем больше проксей необходимо. Используя несколько адресов вы уменьшите процент подозрения к вам от поисковой системы. Адреса будут равномерно распределять запросы с разных IP.
Выбирать для работы лучше приватные — это пул адресов выделенных для вас, которые обеспечит анонимность и стабильную работу приложений, например таких как Key Kollector.

Арбитражники, которым необходимы прокси для работы с разными источниками трафика. В арбитраже трафика прокси используются в таких целях:

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

Почему лучше использовать мобильные прокси?

1. Полная анонимность в сети — мобильные прокси полностью скрывают ваш адрес.
2. Защита аккаунта. Никакие данные с вашего устройства не передаются, когда вы используете такие прокси.
3. Динамическая смена адреса. За счёт того, что он меняется самостоятельно спустя определенное время, вы можете работать с несколькими аккаунтами одновременно. Это особенно актуально для арбитражников и таргетологов.
4. Низкий риск бана. Ни одной площадке не выгодно накладывать ограничения, из-за которых могут пострадать множество обычных пользователей мобильного оператора. Когда сервер получает множество запросов с одного IP-адреса, он понимает, что это никак не связано со спамом, а свидетельствует об обычной деятельности, поэтому ограничений такие прокси практически не имеют.

Какие действия целевой сервер может посчитать подозрительными?

• часовой пояс аккаунта отличается от часового пояса адреса;
• смена адреса слишком быстрая;
• отпечаток ОС не соответствует тому устройству, с которого были совершены действия пользователя.

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

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

Виды мобильных прокси

Разделяются прокси по операторам и стандартам связи.

Операторы: Мегафон, Билайн и прочие.

Стандарты связи: 3G, 4G/LTE. Разница заключается в скорости загрузки. Выбирать прокси стоит в зависимости от необходимых задач, которые нужно решить.

Для сложных задач и больших объёмов данных (парсинг) подойдёт 4G, это более распространённый вид проксей.

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

Итак, ставим задачу.

Задача: спарсить карточку товара из онлайн магазина baucenter.ru, зная артикул товара.

Что понадобится ?

1. Сниффер HTTPS пакетов. Использую Fiddler.

2. Среда разработки приложения Visual Studio 2019.

Этап 1. Сбор данных сниффером пакетов

Запускаем Fiddler, параллельно открываем браузер и переходим на baucenter.ru. В поле поиска товара вставляем любой известный на данном сайте артикул товара (при открытии любого товара отображается артикул). Использую артикул 416001653.

Этап 2. Фильтрация пакетов

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

Ненужные пакеты — это:

• Пакеты вида Tunnel to …;
• Изображения и шрифты;
• JavaScript файлы;
• CSS файлы;
• Запросы на другие порталы нежели baucenter.ru.

Удалив ненужное, получаем следующее:

Рисунок 2. Список отфильтрованных пакетов

Этап 3. Анализ отфильтрованных пакетов.

Открыв карточку товара с артикулом 416001653 в браузере, видим карточку товара со всеми данными. Нас интересует название товара и цена.

Название товара: Тумба с раковиной Onika Крит 52 см.

Цена товара: 3390.

В Fiddler через поиск по тексту ищем, в каком запросе есть текст с названием товара, ценой и артикулом. В моём случае это запрос №241. Рассмотрим его.

Обратим внимание, чтобы выполнить данный запрос нужно знать адрес карточки товара https://baucenter.ru/mebel_dlya_vannoy_razmer_50_59sm1217/686594/. А его в данный момент у нас нет.

Снова через поиск по тексту в Fiddler ищем текст: https://baucenter.ru/mebel_dlya_vannoy_razmer_50_59sm1217/686594/. В моём случае этот текст находится в запросе №217.

Рассмотрев данный запрос и ответ веб-сайта на данный запрос (рисунки 4 и 5), делаем следующие выводы:

• в HTML-коде ответа на запрос №217 есть ссылка на карточку товара. Зная эту ссылку, мы из кода программы сделаем туда запрос и получим необходимые данные о товаре (название и цену, например);
• для выполнения запроса №217 нужно знать только артикул товара, а он у нас есть («416001653»);
• чтобы получить карточку товара из кода приложения, нужно сделать 2 запроса: POST-запрос на адрес https://baucenter.ru, передав артикул товара, и GET-запрос на полученный адрес из первого запроса.

Этап 4. Создать классы GetRequest и PostRequest в приложении

Чтобы спарсить данные из приложения, необходимо, чтобы ваше приложение отправило необходимые запросы на веб-портал. Эти запросы должны быть неотличимы от запросов веб-браузера. Для выполнения парсинга данных создадим классы GetRequest и PostRequest.

Данные классы позволяют выполнять Get и Post запросы на веб-порталы. В конструктор класса передается адрес веб-сайта. В свойства класса передаются стандартные заголовки HTTP запроса: Accept, Host, Data, ContentType, Referer, Useragent. Свойство Proxy служит для установки прокси-сервера, через который будет отправлен запрос.

Это нужно для удобной проверки выполнения своего кода, передав в это свойство значение прокси-сервера Fiddler (по умолчанию 127.0.0.1:8888). Таким образом, при выполнении запросов из программы вы увидите запросы в Fiddler и сможете легко понять проблему, если она будет.

Выполнение запроса происходит при вызове метода Run, и передаче в данный метод контейнер куки. Контейнер куки создаёте перед выполнением всех запросов. После выполнения запросов контейнер записывает в себя, полученные от веб-портала куки. Это позволяет выполнять последующие запросы с сохраненными куки-данными.

Результат выполнения запроса записывается в виде текста в свойство Response.

Этап 5. Создание приложения для получения карточки товара

Результат выполнения программы представлен на рисунке 6.

Код приложения можно найти здесь.

Подробное видео разработки данного проекта здесь:

В этой статье мы рассмотрим инструмент, с помощью которого можно прорываться через мусор в тексте.  А также фильтровать контент и названия файлов, отлавливать запрещённые/разрешенные команды, парсить SQL-запросы и выпендриваться перед коллегами. Это регулярные выражения ?

Все примеры описаны для языка Golang, однако общие принципы, синтаксис самих регулярных выражений применимы и к других языкам программирования.

В начале было слово…

И слово это – паника. Давайте сперва запомним, как надёжней начинать работу с регулярными выражениями. Рассмотрим простейший пример:

Запустив сей код легким мановением руки… получим то, что всей душой ненавидят пишущие на golang люди — панику. Дело в том, что MustCompile паникует вместо возврата ошибки, как это сделано, например, в методе Compile из того же пакета.

Поэтому MustCompile рекомендуется использовать только в тех случаях, когда:

• вы на 100% уверены, что регулярное выражение валидно;
• вы очень хотите упростить код с инициализацией каких-нибудь глобальных переменных.

В остальных случаях лучше подойдёт вариант с возвратом ошибки.

Простой пример проверки соответствия (который можно скопировать и поломать):

Общая информация

• Немного общих сведений о регулярных выражениях в Golang (regexp пакет):
• синтаксис RE2 (библиотека регулярок от Google);
• кодировка UTF-8 и классы символов Unicode;
• время выполнения линейно зависимо от размера ввода;
• обратные ссылки не поддерживаются (не думайте об этом, просто положите на полочку в своих «чертогах разума», чуть позже будет объяснение);
• для регулярных выражений лучше использовать (аккуратно, ведь там своя специфика) необработанные строки (raw strings, строки без интерпретации экранированных литералов).

А теперь приступим к более подробному разбору темы.

Простые совпадения

Простые совпадения не несут в себе никакого тайного смысла. Что написано – то и ищем.

В дальнейшем в простых примерах будем использовать функции:

• MatchString (проверяет, есть ли в строке вхождения регулярного выражения);
• FindAllString (ищет все последовательные непересекающиеся повторения в
  строке).

Регулярные выражения будут выделяться синим цветом, а комментарии — серым для создания качественных нейронных связей в голове читателя.

Совпадение не полное, в последнем слове лишняя «t».

«Banana» полностью совпадает со строкой.

«сat» встречается в строке.

Находятся два вхождения.

Якори границ

Якори границ позволяют нам делить текст на отдельные слова, явно задавать привязку к началу или концу строки/текста.

Ищем текст, начинающийся с «I am here», но есть пробел перед «I» – не подходит.

Ищем строку, состоящую только из кота — но он в середине.

Ищем кота отдельным словом — находим.

Ищем что-то, заканчивающееся котом — находим.

Классы символов (воин, маг, лучник)

Классы — это краткая запись перечисления символов, объединённых по какому-либо признаку. Также можно использовать posix классы ([:digit:], [:space:], etc.), если так удобней.

Ищем вхождение пяти любых символов.

Ищем вхождения сочетаний: «ow<цифра><конец слова>» через два символа слова с начала строки, любой символ, затем две НЕ цифры, затем снова «ow», цифра, конец.

Ищем начало текста, три любых символа, «@_», два символа слова, «D», конец.

Ищем начало текста, «GO», один пробельный символ, одну цифру, любой символ, две цифры, конец.

Специальные символы и escape

Что нужно знать про специальные символы:

• список спецсимволов: ^ $ * + ? { } [ ] \ | ( )
• их нужно экранировать с помощью `\`, т.е.  `\+` = просто +

Ищем «I» в начале текста, перенос, «am», перенос, «here», конец текста.

Ищем «I» (в виде 16-ричного кода символа), в начале текста, перенос, «am», перенос, «here», конец текста.

Ищем… не «a+b=c», а одно и более повторение «a», «b=c», ибо «+» не экранирован.

Ищем «a|b=c», символ «|» экранирован, всё в порядке.

Повторение (жабное, не жабное)

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

Ищем все вхождения чисел из одной и более цифр.

Ищем начало текста, одно повторение «А», от одного до 3 повторений «G», одно и более повторение «А», от 0 до 2 повторений «!».

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

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

Квадратные скобки, ИЛИ и НЕ

Квадратные скобки эквивалентны перечислению (перечислению с отрицанием при использовании ^). Прямая черта | равнозначна набору альтернативных вариантов из слов. Крышечкой ^ обозначается отрицание при использовании внутри квадратных скобок.

Ищем либо «good», либо «bad», либо один символ в конце текста, не являющийся пробельным, «i», «c» или «e».

Ищем начало текста, ноль или более (лучше меньше, не жадное повторение) символов из перечня [a, A , u , U , f ,F], «go» или «python», пробел, от одной до трех цифр, точку, одну цифру и конец текста).

Ищем начало текста, один и более символов из перечня [h, a, H, A], конец текста.

Ищем начало текста, один и более символов из перечня [h, a, H, A] либо ноль и более символов из перечня [g, o, G, O], конец текста – пустая строка соответствует второму варианту после прямой черты.

Группы

Важное о группах:

• позволяют поместить часть совпадения в отдельный массив;
• квантификатор после скобок группы применяется ко всей группе (под квантификаторами подразумеваются такие товарищи, как: +, *, {min, max}, etc.);
• группа 0 всегда относится ко всему выражению;
• группа 1 — к подвыражению, начинающемуся с “(“ и заканчивающемуся “)”  (и так далее);
• при повторении группы в качестве «группы 1» берется последнее совпадение.

В примерах некоторые элементы подчеркнуты. Это не баг, это фича, помогающая увидеть, какой элемент в какой список групп попал. Также используется новая функция — FindAllStringSubmatch — возвращающая срез последовательных непересекающихся подсовпадений (совпадений скобочных групп). Вторым параметром в данной функции является ограничение количества найденных подсовпадений (найдется всё, если использовать -1).

Тема групп совсем не проста, поэтому пробуйте разное, ломайте, дебажьте.

Ищем все подсовпадения с выражением «любой символ, одна и более цифра», находим три вхождения, в каждом из которых есть группа 0 – всё вхождение целиком – и группа 1 – часть с «одна и более цифра».

Выделяем год, месяц и день в отдельные группы, ищем (4 цифры), тире, (2 цифры), тире, (2 цифры).  Получаем одно подсовпадение, где группа 0 — вся дата, группа 1 — год, группа 2 — месяц, группа 3 — день.

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

Как ни странно, в группе может быть внутренняя подгруппа (а в ней ещё одна…и ещё…). Здесь мы ищем ноль и более (лучше меньше) любых символов, одно и более повторение символа из перечня [a-zA-Z\-0-9], слэш, любой символ, 2 и более повторения символов из перечня [a-zA-Z]. В итоге находим одно вхождение, где группа 0 – все выражение, группа 1, как внешняя, целиком соответствует части «одно и более повторение символа из перечня [a-zA-Z\-0-9], слэш, любой символ, 2 и более повторения символов из перечня [a-zA-Z]», а группа 2 – части «одно и более повторение символа из перечня [a-zA-Z\-0-9]».

Вспоминается мем (в нём, кстати, есть мааленькая опечатка :), кто отыщет?):

С группами, как и с математическим анализом, нужно сесть, поплакать, хорошо разобраться один раз и работать на автомате в дальнейшем…

Именованные и необязательные группы

Еще один факт о регулярных выражениях в Golang:

• обратных ссылок тут нет (!) (запоминание встретившейся группы для повторного использования в том же выражении).

Иногда этот факт вызывает головную боль.

В примерах используется новая вспомогательная функция — SubexpNames — позволяющая получить доступ к списку разделённых по названию групп подсовпадений.

Пытаемся выловить из мусорного текста дату, разделив её на год, месяц, день. В группу Year попадают первые 4 цифры до тире, группу Month — 2 цифры до следующего тире, Day — последние 2 цифры. Доступ к разделенным по названиям групп подсовпадениям получаем при помощи прохождения по re.SubexpNames()

Ищем go либо Go (группа, которая не попадает в список подсовпадений благодаря ?: после открывающей скобки группы), py либо Py — находим два подсовпадения, где группа 0 — вхождение целиком, группа 1 – вторая группа
(которая «py либо Py»).

Другие функции для работы с регулярными выражениями

Формула функций работы с регулярными выражениями:

Также рассмотрим несколько иных функций на примерах.

Дальше будет сложно. Слабонервным рекомендуется закрыть статью, отойти от экранов и уехать жить в Лондон (почему бы и нет).

Большие примеры с кейсами применения регулярных выражений

Валидация логина:

Фильтрация трафика syslog (привет работающим с logstash и его фильтрами):

Парсинг имен таблиц и баз данных, к которым идет обращение, из SELECT SQL-запроса:

Маленькое заключение

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

Разбирайтесь, не бойтесь экспериментировать и развлекайтесь!

Отличие от вызовов API

Альтернативный метод получения данных сайта — вызовы API. Взаимодействие с API — это официально предоставляемый владельцем сайта способ получения данных прямо из БД или обычных файлов. Обычно для этого требуется разрешение владельца сайта и специальный токен. Однако апи доступен не всегда, поэтому скрапинг так привлекателен, однако его законность вызывает вопросы.

Юридические соображения

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

Установка Beautiful Soup в Python

Beautiful Soup — это Python библиотека для скрапинга данных сайтов через HTML код.
Установите последнюю версию библиотеки.

Чтобы делать запросы, установите requests (библиотеку для отправки HTTP запросов):

Импортируйте библиотеки в файле Python или Jupiter notebook:

И несколько стандартных библиотек, которые потребуются для скрапинга на Python:

Введение

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

Предположим, что запрос приведет к странице результатов, которая выглядит следующим образом:

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

1. Как получить одну точку данных для одного свойства (например данные из тега price в первом объявлении)?
2. Как получить все точки данных для одного свойства со всей страницы (например все теги price с одной страницы)?
3. Как получить все точки данных для одного свойства всех страниц с результатами (например все теги price со всех страниц с результатами)?
4. Как устранить несоответствие, когда данные могут быть разных типов (например, есть некоторые объявления, в которых в поле цены указана цена по запросу. В конечном итоге у нас будет столбец, состоящий из числовых и строковых значений, что в нашем случае не позволяет провести анализ)?
5. Как лучше извлечь сложную информацию (Например, предположим, что каждое объявление содержит информацию об общественном транспорте, например “0,5 мили до станции метро XY”)?

Логика получения одной точки данных

Все примеры кода для скрапинга на Python можно найти в Jupiter Notebook файле на GitHub автора.

Запрос кода сайта

Во-первых, мы используем поисковый запрос, который мы сделали в браузере в скрипте Python:

Переменная soup содержит полный HTML-код страницы с результатами поиска.

Поиск тегов-свойств

Для этого нам потребуется браузер. Некоторые популярные браузеры предлагают удобный способ получения информации о конкретном элементе напрямую. В Google Chrome вы можете выбрать любой элемент сайта и, нажав правой кнопкой, выбрать пункт “Исследовать элемент” . Справа откроется код сайта с выделенным элементом.

HTML классы и атрибут id

HTML-классы и id в основном используются для ссылки на класс в таблице стилей CSS, чтобы данные могли отображаться согласованным образом.
В приведенном выше примере, класс, используемый для получения информации о ценах из одного объявления, также применяется для получения цен из других объявлений (что соответствует основной цели класса).

Обратите внимание, что HTML-класс также может ссылаться на ценники за пределами раздела объявлений (например, специальные предложения, которые не связаны с поисковым запросом, но все равно отображаются на странице результатов). Однако для целей этой статьи мы фокусируемся только на ценах в объявлениях о недвижимости.
Вот почему мы сначала ориентируемся на объявление и ищем HTML-класс только в исходном коде для конкретного объявления:

Использование .text в конце метода find() позволяет нам возвращать только обычный текст, как показано в браузере. Без .text он вернет весь исходный код строки HTML, на которую ссылается класс:

Важное примечание: нам всегда нужно указывать элемент, в данном случае это p.

Логика получения всех точек данных с одной страницы

Чтобы получить ценники для всех объявлений, мы применяем метод find.all() вместо find():

Переменная ads теперь содержит HTML-код для каждого объявления на первой странице результатов в виде списка списков. Этот формат хранения очень полезен, так как он позволяет получить доступ к исходному коду для конкретных объявлений по индексу.

Чтобы получить все ценники, мы используем словарь для сбора данных:

Важное примечание: использование идентификатора позволяет находить объявления в словаре:

Получение точек данных со всех страниц

Обычно результаты поиска либо разбиваются на страницы, либо бесконечно прокручиваются вниз.

Вариант 1. Веб-сайт с пагинацией

URL-адреса, полученные в результате поискового запроса, обычно содержат информацию о текущем номере страницы.

Важное примечание: номер страницы в URL-адресе обычно становится видимым со второй страницы. Использование базового URL-адреса с дополнительным фрагментом &pn=1 для вызова первой страницы по-прежнему будет работать (в большинстве случаев).

Применение одного цикла for-loop поверх другого позволяет нам перебирать страницы результатов:

Определение последней страницы результатов

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

Чтобы решить эту проблему, мы будем проверять, есть ли на странице кнопка с такой ссылкой:

Вариант 2. Сайт с бесконечным скроллом

В таком случае HTML скрапер не сработает. Альтернативные методы мы обсудим в конце статьи.

Устранение несогласованности данных

Если нам нужно избавиться от ненужных данных в самом начале скрапинга на Python, мы можем использовать обходной метод:

Функция для определения аномалий

И применить его при сборе данных:

Форматирование данных на лету

Мы могли заметить, что цена хранится в строке вместе с запятыми с символом валюты. Мы можем исправить это ещё на этапе скрапинга:

Используем эту функцию:

Получение вложенных данных

Информация об общественном транспорте имеет вложенную структуру. Нам потребуются данные о расстоянии, названии станции и типе транспорта.

Отбор информации по правилам

Каждый кусочек данных представлен в виде: число миль, название станции. Используем слово “миль” в качестве разделителя.

Первоначально переменная transport хранит два списка в списке, поскольку есть две строки информации об общественном транспорте (например, “0,3 мили Слоун-сквер”, “0,5 мили Южный Кенсингтон”). Мы перебираем эти списки, используя len транспорта в качестве значений индекса, и разделяем каждую строку на две переменные: расстояние и станцию.

Поиск дополнительных HTML атрибутов для визуальной информации

В коде страницы мы можем найти атрибут testid, который указывает на тип общественного транспорта. Он не отображается в браузере, но отвечает за изображение, которое отображается на странице. Для получения этих данных нам нужно использовать класс css-StyledIcon:

Преобразование в датафрейм и экспорт в CSV

Когда скрапинг выполнен, все извлеченные данные доступны в словаре словарей.

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

Создаём датафрейм

Мы можем экспортировать датафрейм в CSV:

Преобразование всех объявлений в датафрейм:

Мы это сделали! Теперь наш скрапер готов к тестированию.

Ограничения HTML скрапинга и его альтернативы

Этот пример показывает, насколько простым может быть скрапинг HTML на Python в стандартном случае. Для этого не нужно исследовать документацию. Это требует, скорее, творческого мышления, чем опыта веб-разработки.

Однако HTML скраперы имеют недостатки:

• Можно получить доступ только к информации в HTML-коде, которая загружается непосредственно при вызове URL-адреса. Веб-сайты, которые требуют JavaScript и Ajax для загрузки контента, не будут работать.
• HTML-классы или идентификаторы могут изменяться в связи с обновлениями веб-сайта.
• Может быть легко обнаружен, если запросы кажутся аномальными для веб-сайта (например, очень большое количество запросов в течение короткого промежутка времени).

Альтернативы:

• Shell скрипты — загружают всю страницу, с помощью регулярных выражений могут обрабатывать html.
• Screen scraper — изображают реального пользователя, используют браузер (Selenium, PhantomJS).
• ПО для скрапинга — рассчитаны на стандартные случаи, не требуют написания кода (webscraper.io).
• Веб сервисы скраперы — не требуют написания кода, хорошо справляются со скрапингом, платные (zyte.com).

Здесь вы найдёте список инструментов и библиотек для скрапинга.

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

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

Что такое скрапинг данных?

Скрапинг данных или веб скрапинг – это способ извлечения информации с сайта или приложения (в понятном человеку виде) и сохранение её в таблицу или файл.

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

Как используют эти данные

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

1. Отслеживание цен

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

2. Рыночная и конкурентная разведка

Если вы хотите проникнуть на новый рынок и хотите оценить возможности, анализ данных поможет вам сделать взвешенное и адекватное решение.

3. Мониторинг соцсетей

YouScan, Brand Analytics и другие платформы для мониторинга соцсетей используют скрапинг.

4. Машинное обучение

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

Интернет — это важный источник данных для алгоритмов машинного обучения.

5. Модернизация сайтов

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

6. Мониторинг новостей

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

7. Анализ эффективности контента

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

Данные в таком формате:

• легко сортируются и редактируются;
• просто добавить в БД;
• доступны для повторного использования;
• можно преобразовать в графики.

Сервисы для веб скрапинга

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

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

1. Octoparse

Octoparse — это простой в использовании скрапер для программистов и не только. У него есть бесплатный тарифный план и платная подписка.

Особенности:

• работает на всех сайтах: с бесконечным скроллом, пагинацией, авторизацией, выпадающими меню, AJAX и т.д.
• сохраняет данные в Excel, CSV, JSON, API или БД.
• данные хранятся в облаке.
• скрапинг по расписанию или в реальном времени.
• автоматическая смена IP для обхода блокировок.
• блокировка рекламы для ускорения загрузки и уменьшения количества HTTP запросов.
• можно использовать XPath и регулярные выражения.
• поддержка Windows и macOS.
• бесплатен для простых проектов, 75$/месяц — стандартный, 209$/месяц — профессиональный и т. д.

2. ScrapingBee

ScrapingBee Api использует «безголовый браузер» и смену прокси. Также имеет API для скрапинга результатов поиска Google.

Особенности:

• рендеринг JS;
• ротация прокси;
• можно использовать с Google Sheets и браузером Chrome;
• бесплатен до 1000 вызовов API, 29$/месяц — для фрилансеров, 99$/месяц — для бизнеса и т.д.

3. ScrapingBot

ScrapingBot предоставляет несколько API: API для сырого HTML, API для сайтов розничной торговли, API для скрапинга сайтов недвижимости.

Особенности:

• рендеринг JS (безголовый Chrome);
• качественный прокси;
• до 20 одновременных запросов;
• геотэги;
• аддон Prestashop, интегрирующийся на ваш сайт для мониторинга цен конкурентов;
• бесплатный тариф на 100 кредитов, 47$/месяц для фрилансеров, 120$/месяц для стартапов, 361$/месяц для для бизнеса и т. д.

4. scrapestack

Scrapestack — это REST API для веб скрапинга в реальном времени. Он позволяет собирать данные с сайтов за миллисекунды, используя миллионы прокси и обходя капчу.

Особенности:

• одновременные API запросы;
• рендеринг JS;
• шифрование HTTPS;
• более 100 геолокаций;
• бесплатный тариф до 1000 запросов, базовый тариф за 19.99$/месяц, профессиональный тариф за 79.99$/месяц и т. д.

5. Scraper API

Scraper API работает с прокси, браузерами и капчей. Его легко интегрировать. Нужно только отправить GET запрос к API с вашим API ключом и URL.

Особенности:

• рендеринг JS;
• геотэги;
• имеет пул резидентных\мобильных прокси для скрапинга цен, результатов поиска, мониторинга соцсетей и т. д.
• 1000 вызовов API бесплатно, тариф для хобби — 29$\месяц, 99$\месяц — для стартапов и т. д.

6. ParseHub

ParseHub — это сервис для веб скрапинга, не требующий навыков программирования.

Особенности:

• понятный графический интерфейс;
• экспорт данных в Excel, CSV, JSON или доступ через API;
• XPath, регулярные выражения, CSS селекторы;
• бесплатный тариф, стандартный тариф — 149$/месяц и т. д.

7. Xtract.io

Xtract.io — это гибкая платформа, использующая технологии AI, ML и NLP.

Её можно настроить для скрапинга и структурирования данных сайтов, постов с соцсетях, PDF файлов, текстовых документов, исторических данных и электронной почты.

Особенности:

• скрапинг данных из каталогов, финансовых данных, данных об аренде, геолокационных данных, данных о компаниях и контактных данных, обзоров и рейтингов.
• преднастроенная система для автоматизации всего процесса извлечения данных;
• очистка и валидация данных по заданным правилам;
• экспорт в JSON, текст, HTML, CSV, TSV и т. д.
• ротация прокси и прохождение капчи для скрапинга данных в реальном времени.
• гибкая ценовая политика.

В обновлённом варианте закона «О персональных данных» появились изменения, в результате которых теперь нельзя «собирать и использовать опубликованные в Интернете сведения об отдельном лице».

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

Правда, есть возможность сохранить право на автоматизированный сбор данных. Для этого необходимо получить согласие «каждого субъекта на такие действия».

Полный текст нового закона доступен по ссылке.

Источник: Хабр

Собирать данные с веб-сайтов (то есть заниматься веб-скрейпингом) можно либо через готовый API, либо путём парсинга. Самостоятельно парсить страницы не всегда просто: многие сайты не любят скрейперов и стараются блокировать их. Мы уже рассказывали, как этого избежать, а в этой статье рассмотрим готовые инструменты для парсинга, среди которых наиболее популярные онлайн-сервисы и библиотеки для языков Python, JavaScript, Java.

Онлайн-сервисы для скрейпинга

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

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

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

Diggernaut — парсер, создаваемый с помощью визуального инструмента или метаязыка. Может читать данные из HTML, XML, JSON, iCal, JS, XLSX, XLS, CSV, Google Spreadsheets.

ScrapingBee — предоставляет API для работы с Headless Chrome и позволяет сфокусироваться на обработке данных.

Scraper API — ещё один простой API с большим набором настроек: от заголовков запросов до геолокации IP.

Библиотеки для языков программирования

Python

Библиотеки на Python предоставляют множество эффективных и быстрых функций для парсинга. Многие из этих инструментов можно подключить к готовому приложению в формате API для создания настраиваемых краулеров. Все перечисленные ниже проекты имеют открытый исходный код.

BeautifulSoup

Пакет для анализа документов HTML и XML, преобразующий их в синтаксические деревья. Он использует HTML и XML-парсеры, такие как html5lib и Lxml, чтобы извлекать нужные данные.

Для поиска конкретного атрибута или текста в необработанном HTML-файле в BeautifulSoup есть удобные функции find(), find_all(), get_text() и другие. Библиотека также автоматически распознаёт кодировки.

Установить последнюю версию BeautifulSoup можно через easy_install или pip:

Selenium

Инструмент, который работает как веб-драйвер: открывает браузер, выполняет клики по элементам, заполняет формы, прокручивает страницы и многое другое. Selenium в основном используется для автоматического тестирования веб-приложений, но его вполне можно применять и для скрейпинга. Перед началом работы необходимо установить драйверы для взаимодействия с конкретным браузером, например ChromeDriver для Chrome и Safari Driver для Safari 10.

Установить Selenium можно через pip:

Lxml

Библиотека с удобными инструментами для обработки HTML и XML файлов. Работает с XML чуть быстрее, чем Beautiful Soup, при этом используя аналогичный метод создания синтаксических деревьев. Чтобы получить больше функциональности, можно объединить Lxml и Beautiful Soup, так как они совместимы друг с другом. Beautiful Soup использует Lxml как парсер.

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

Установить Lxml:

JavaScript

Для JavaScript тоже можно найти готовые библиотеки для парсинга с удобными функциональными API.

Cheerio

Шустрый парсер, который создаёт DOM-дерево страницы и позволяет удобно с ним работать. Cheerio анализирует разметку и предоставляет функции для обработки полученных данных.

API Cheerio будет особенно понятен тем, кто работает с jQuery. Парсер позиционирует себя как инструмент, позволяющей сконцентрироваться на работе с данными, а не на их извлечении.

Установить Cheerio:

Osmosis

По функциональности скрейпер похож на Cheerio, но имеет куда меньше зависимостей. Osmosis написан на Node.js и поддерживает селекторы CSS 3.0 и XPath 1.0. Также он умеет загружать и искать AJAX-контент, записывать логи URL-адресов, редиректов и ошибок, заполнять формы, проходить базовую аутентификацию и многое другое.

Для наглядности можно посмотреть пример парсинга сайтов с помощью Osmosis.

Установить парсер:

Apify SDK

Библиотека Node.js, которую можно использовать вместе с Chrome Headless и Puppeteer.

Apify позволяет выполнять глубокий обход всего веб-сайта, используя очередь URL-адресов. Также с ней можно запускать код парсера для множества URL в CSV-файле, не теряя никаких данных при сбое программы.

Для безопасного скрейпинга Apify использует прокси и отключает распознавание фингерпринта браузера на веб-сайтах.

Установить Apify SDK:

Java

В Java реализованы различные инструменты и библиотеки, а также внешние API, которые можно использовать для парсинга.

Jsoup

Проект с открытым исходным кодом для извлечения и анализа данных с HTML-страниц. Основные функции в целом не отличаются от тех, что предоставляют другие парсеры. К ним относятся загрузка и анализ HTML-страниц, манипулирование HTML-элементами, поддержка прокси, работа с CSS-селекторами и прочее.

Jsoup не поддерживает парсинг на основе XPath.

Загрузить Jsoup

Jaunt

Библиотека, которую можно использовать для извлечения данных из HTML-страниц или данных JSON с помощью headless-браузера. Jaunt может выполнять и обрабатывать отдельные HTTP-запросы и ответы, а также взаимодействовать с REST API для извлечения данных.

В целом функциональность Jaunt похож на Jsoup за исключением того, что вместо CSS-селекторов Jaunt использует собственный синтаксис.

Загрузить Jaunt

HTMLUnit

Инфраструктура, которая позволяет моделировать события браузера, (щелчки, прокрутка, отправка форм) и поддерживает JavaScript. Это улучшает процесс автоматизации получения и обработки информации. HTMLUnit поддерживает парсинг на основе XPath, в отличие от JSoup. Ещё его можно использовать для модульного тестирования веб-приложений.

Загрузить HTMLUnit

Знаете ещё примеры хороших библиотек и инструментов для скрейпинга? Поделитесь ими в комментариях.

Чтобы получить данные с сайтов, используется готовый API, однако он не всегда доступен. Тогда приходится использовать «парсер» веб-страницы — в автоматическом или полуавтоматическом режиме распознавать код и получать данные из необходимых полей. Обходом множества страниц и сайтов занимается ПО, которое обычно называется «краулер».

Процесс сбора данных с сайтов краулером называется веб-скрейпингом.

Большинство популярных сайтов активно защищают свои ресурсы от скрейпинга используя распознавание IP-адреса, проверку заголовков HTTP-запросов, CAPTCHA и другие способы. Но скрейперы не отстают от них и придумывают новые стратегии обхода. Вот несколько советов, как скрейпить без блокировок.

Задайте случайные интервалы между запросами

Ни один реальный человек не станет отправлять запросы на сайт каждую секунду в течение 24 часов — такой сбор информации очень легко обнаружить. Используйте случайные задержки (например около 2–10 секунд), чтобы избежать блокировки. И не отправляйте запросы слишком часто, иначе сканирование сайта будет походить на сетевую атаку.

Особо щепетильным стоит проверить файл robots.txt (как правило, находится на http://<адрес сайта>/robots.txt). Иногда там можно найти параметр Crawl-delay, который говорит, сколько секунд нужно подождать между запросами, чтобы не вредить работе сервера.

Установите адекватный User Agent

User Agent — HTTP-заголовок, который сообщает посещаемому веб-сайту информацию о вашем браузере. Если не настроить User Agent, вашего краулера будет очень легко обнаружить. Кроме того, сайты иногда блокируют запросы пользовательских агентов от неизвестных браузеров. Поэтому не забудьте установить один из популярных пользовательских агентов (например из этого списка).

Опытные скрейперы могут попробовать установить свой агент на Googlebot User Agent — поисковый робот Google. Большинство веб-сайтов, очевидно, хотят попасть в выдачу Google и пропускают Googlebot.

Хорошей практикой будет также чередование разных User Agent.

Используйте прокси

Вряд ли настоящий пользователь сможет запрашивать 20 страниц в секунду на одном и том же сайте. Чтобы «обмануть» веб-сервер, заставьте его думать, что все эти запросы приходят из разных мест. Другими словами, используйте прокси.

Тут есть множество вариантов, например сервисы SmartProxy, Luminati Network, Blazing SEO. Бесплатные прокси не всегда подойдут для таких целей: они часто медленные и ненадёжные. Также можно создать свою прокси-сеть на сервере, например с помощью Scrapoxy — API с открытым исходным кодом.

Добавьте referer

Referer — заголовок HTTP-запроса, который даёт понять, с какого сайта вы пришли. Неплохой вариант — сделать так, чтобы он показывал, будто вы перешли из Google:

Стоит менять referer для веб-сайтов в разных странах: например для России использовать https://www.google.ru/, а не https://www.google.com/. Вместо Google можно подставить адреса соцсетей: Youtube, Facebook, ВКонтакте. Referer поможет сделать так, чтобы запросы выглядели как трафик с того сайта, откуда обычно приходит больше всего посетителей.

Используйте headless-браузер

Особо хитроумные сайты могут отслеживать веб-шрифты, расширения, файлы cookie, цифровые отпечатки (фингерпринты). Иногда они даже встраивают JavaScript-код, открывающий страницу только после его запуска — так зачастую можно определить, поступает ли запрос из браузера. Для обхода таких ресурсов вам потребуется headless-браузер. Он эмулирует поведение настоящего браузера и поддерживает программное управление. Чаще всего для этих целей выбирают Chrome Headless.

Если ресурс отслеживает цифровой отпечаток браузера, то даже многократная смена IP и очистка cookie не всегда помогают, так как вас всё равно могут узнать по фингерпринту. За частую смену IP при одном и том же отпечатке вполне могут заблокировать, и одна из задач Chrome Headless — не допустить этого.

Самый простой способ работать с Chrome Headless — использовать фреймворк, который объединяет все его функции в удобный API. Наиболее известные решения можно найти тут. Но некоторые веб-ресурсы пытаются отслеживать и их: идёт постоянная гонка между сайтами, пытающимися обнаружить headless-браузеры, и headless-браузерами, которые выдают себя за настоящие.

Подключите программу для решения CAPTCHA

Существуют веб-сайты, которые систематически просят вас подтвердить, что вы не робот, с помощью капч. Обычно капчи отображаются только для подозрительных IP-адресов, и с этим помогут прокси. В остальных же случаях используйте автоматический решатель CAPTCHA — скажем, 2Captcha или AntiCaptcha.

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

Избегайте honeypot-ловушек

«Honeypot» — это фальшивая ссылка, которая невидима для обычного пользователя, но присутствует в HTML-коде. Как только вы начнёте анализировать сайт, honeypot может перенаправить вас на пустые и бесполезные страницы-приманки. Поэтому всегда проверяйте, установлены ли для ссылки CSS-свойства «display: none», «visibility: hidden» или «color: #fff;» (в последнем случае нужно учитывать цвет фона сайта).

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

Анонимный исследователь под ником yoga2016 обнаружил уязвимость в API «ВКонтакте», позволяющую свободно извлекать сообщения из личной переписки пользователей. Он сразу же сообщил о находке в службу поддержки, однако ему отказали в выплате средств по программе Bug Bounty.

«Маркетинговый шпион»

SimilarWeb — это инструмент для отслеживания статистики сайтов из поисковых систем. Yoga2016 использовал сервис для анализа «ВКонтакте» и случайно получил ссылки на XML-файлы, содержащие личные сообщения 300 случайных пользователей.

Структура запросов выглядит следующим образом:

Переписки можно было выгрузить, приписав к концу адресного запроса .xml. В файлах содержится разметка с полными текстами сообщений, а также все прикреплённые материалы (фотографии, документы).

Пресс-служба «ВКонтакте» заявила, что раскрытие личных данных не связано с ошибкой в функционировании сайта. Вероятнее всего, утечка произошла из-за недобросовестных или невнимательных сторонних разработчиков, имеющих доступ к API социальной сети. При этом было отмечено, что пользователи скомпрометированных страниц добровольно дали доступ к своим личным данным в настройках приватности.

Специалисты «ВКонтакте» уже заблокировали открытые токены и ведут расследование.

Pwned Passwords

Сайт Pwned Passwords предлагает пользователям ввести свой пароль для проверки по накопленной базе данных. По словам Ханта, он не перестаёт удивляться людям, без задней мысли раскрывающим свои рабочие учётные данные сторонним сервисам.

У сервиса доступен API, через который можно проверить пароли напрямую через ввод пароля или префикса хэша в адресной строке. Если введённый набор символов найден в базе, сервер возвращает целое число / реальный хэш. В противном случае возвращается сообщение об ошибке.

Поиск по паролю:

Поиск по префиксу хэша (хэши не чувствительны к регистру и выводятся уже без префикса):

Бесплатная база паролей размером в 8,8 ГБ открыта для загрузки. Единственное ограничение — пароли в общедоступных данных заменены хэшами SHA-1, чтобы по ним нельзя было идентифицировать пользователей. В таблицах также не содержится длина пароля, но зато у каждого указан счётчик дубликатов, демонстрирующий количество учётных записей, в который этот кодовый набор символов был использован.

А какие кодовые слова точно найдутся в этой БД — без дополнительных проверок скажет топ-100 худших паролей 2017 года.

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

Вот они — все необходимые данные для вашего проекта.

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

Но есть и более простое решение — это библиотека Pandas и ее встроенная функция read_html(), которая предназначена для получения данных с html-страниц.

Прим. перев. В данной статье используется версия Pandas 0.20.3

Да, все настолько просто. Pandas находит html-таблицы на странице и возвращает их как новый объект DataFrame.

Теперь попробуем указать Pandas, что первая (а точнее нулевая) строка таблицы содержит заголовки столбцов, а также попросим ее сформировать datetime-объект из строки, находящейся в столбце с датой и временем.

На выходе мы получим следующий результат:

Теперь все эти данные находятся в DataFrame-объекте. Если же нам нужны данные в формате json, добавим еще одну строчку кода:

В результате вы получите данные в формате json с правильным форматированием даты по стандарту ISO 8601:

При желании данные можно сохранить в CSV или XLS:

Выполните код и откройте файл calls.csv. Он откроется в приложении для работы с таблицами:

И, конечно же, Pandas упрощает анализ:

Статистика запроса:

Группировку:

Результат группировки:

И обработку данных:

Результат метода unique:

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

Что произошло?

Пользователь Kaggle, платформы для машинного обучения, которую недавно приобрела Google, загрузил базу данных лиц, которую он получил, используя уязвимость в Tinder API. Она позволила скачать фотографии с 40 тысяч аккаунтов, принадлежащих пользователям социальной сети, находящимся в области залива Сан-Франциско — по 20 тысяч мужчин и женщин. Многие изображения находились в закрытом доступе.

База данных «Люди Tinder» (в настоящий момент удалена по требованию Tinder) состоит из 6 скачиваемых zip-файлов. Четыре из них содержат по 10 тысяч фото, а в двух оставшихся собраны по 500 изображений мужчин и женщин. Из некоторых профилей было скачано несколько фотографий, поэтому, вероятно, пострадало меньше 40 тысяч пользователей.

Кроме того, создатель базы данных, Стюарт Колианни, опубликовал исходный код парсера на GitHub.

Прим. ред. Если вы интересуетесь парсингом, прочитайте наше краткое руководство с примерами на Node.js.

Зачем он это сделал?

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

За три дня базу данных скачали с Kaggle более 300 раз, и, конечно, никто не знает, в каких целях ее будут использовать.

Как отреагировал Tinder?

Официальный представитель заявил:

Мы серьезно относимся к безопасности и конфиденциальности информации наших пользователей и обладаем средствами и системами, которые позволяют этим данным оставаться внутри нашей платформы. Стоит отметить, что Tinder — это бесплатная сеть, которой пользуются более чем в 190 странах, и фото из аккаунтов доступны любому зарегистрированному пользователю. Мы постоянно работаем над улучшением качества работы с сетью и внедряем инструменты, которые не позволяют автоматически использовать наш API. В том числе мы выявляем и предотвращаем скачивание данных. Этот человек нарушил условия предоставления услуг (раздел 11), и мы примем соответствующие меры и проведем расследование.

На данный момент база данных «Люди Tinder» удалена с сайта Kaggle.

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

Как это работает?

Примерно так: парсер посылает странице get-запрос, получает данные в виде HTML / XML и извлекает их в желаемом формате. Для загрузки файлов через консоль подходит утилита WGET, но можно выбрать и любой другой подходящий инструмент на просторах Сети.

Мы будем использовать написанный для Node.js программный пакет osmosis, включающий селектор css3/xpath и небольшой http-обработчик. Есть и другие фреймворки вроде Webdriver и CasperJS, но в данном случае они нам не понадобятся.

Настраиваем проект

1. Устанавливаем Node.js, поставляемый с менеджером пакетов npm.
2. Создаём новую папку, например, webscrap.
3. Переходим в неё: cd webscrap.
4. Запускаем из консоли npm init для создания файла package.json.
5. Запускаем npm i osmosis --save, чтобы установить пакет для парсинга. Дополнительных зависимостей, кроме как от обработчика и селектора, у него не будет.
6. Открываем package.json и создаём новый стартовый скрипт для последующего запуска команды npm start.

Итоговый package.json будет выглядеть примерно так:

Создаём файл index.js, в нём будем делать всю работу.

Парсим информативный заголовок в Google

Это самый базовый пример, с помощью которого мы познакомимся с пакетом и запустим первый Node-скрипт. Помещаем код ниже в файл index.js и запускаем из консоли команду npm start. Она выведет заголовок веб-страницы:

Разберём, что делают методы. Первый метод get получает веб-страницу в сжатом формате. Следующий метод set выберет элемент заголовка, представленный в виде css3-селектора. Наконец, метод data с console.log обеспечивают вывод. Метод set также принимает строки в качестве аргумента.

Получаем релевантные результаты в Google

Допустим, мы хотим получить результаты по ключевому слову analytics. Делаем следующее:

Вот и всё. Этот код извлечёт все соответствующие ключевые слова с первой страницы результатов поиска, поместит их в массив и запишет в лог в консоли. Логика, стоящая за этим, такова: мы сначала анализируем веб-страницу через инструменты разработчика, проверяем блок, в котором находится слово (в данном случае это div #botstuff), и сохраняем его в массив через селектор .card-section .brs_col p a, который найдёт все соответствующие ключевые слова на странице.

Увеличиваем количество страниц при релевантном поиске

Для этого нужно добавить цепочку вызовов (chaining method), вычислив атрибут href у тега anchor (<a>). Мы ограничимся пятью страницами, чтобы Google не посчитал нас за бот. Если необходимо выставить время между парсингом соседних страниц, добавляем метод .delay(ms) после каждого .paginate().

Парсим адреса электронной почты с сайта Shopify

В данном случае мы будем собирать email-адреса и названия всех приложений, последовательно перемещаясь с помощью метода .follow, и потом помечать необходимые селекторы в консоли разработчика:

Код выше можно скомбинировать с методом .paginate, чтобы собрать полностью весь контент (но при этом нас могут и заблокировать).

Теперь нужно сохранить данные в файле, сделать это можно так (пример модификации кода выше, сохранение в формате json):

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

Инструменты API.ai упрощают парсинг человеческой письменной речи. Компания предоставляет огромный набор возможностей для распознавания естественного языка, в частности, стандартные пакеты Domains, которые содержат базовые запросы и облегчают дальнейшую работу с ботом. Также API.ai управляет чат-ботом собственной разработки под названием Assistant, которым пользуются более 4 миллионов пользователей.

Компания Google — не новичок в сфере распознавания естественных языков. Весной она выложила в открытый доступ фреймворк для создания систем, распознающих синтаксис языков, а летом запустила Cloud Natural Language API.

Титаны в IT-сфере в последнее время стали уделять большое внимание разработке инструментов для создания чат-ботов: в прошлом году Facebook приобрёла компанию Wit.ai, а в прошлое воскресенье Oracle представила новые инструменты для создания ботов в большинстве чат-сервисов.

Как же выглядит e-mail адрес? Интуитивно можно предположить, что так:

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

Конечно, и тут можно обойтись с помощью регулярного выражения:

Но с этим есть несколько проблем:

• Как вы будете проверять правильность этого монстра? Такие регулярные выражения переходят «из уст в уста» на форумах, и каждый добавляет в них функциональность до тех пор, пока работа с выражением становится невозможной. И это именно тот случай.
• Я бы не сказал, что регулярные выражения такой длины эффективнее, чем другие методы. Чем длиннее выражение, тем дольше оно будет компилироваться (сравнение всегда происходит за O(n)).
• С помощью регулярного выражения можно сделать только проверку на соответствие. Выполнить проверку на то, находится ли домен в чёрном списке, у вас уже, увы, не получится.

Давайте пойдём другим путём

Вот основа нашей проверки:

А вот диаграмма, описывающая алгоритм, по которому наша программа будет работать:

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

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

Теперь о проверках, которые мы сделаем, после того, как код пройдёт по этой диаграмме:

Собираем всё вместе

Справедливости ради, стоит отметить, что эту закономерность он заметил далеко не первым, однако раньше всё основывалось лишь на догадках и поверхностном просмотре твитов. Без программистов никуда ?

Сначала он лёгким движением руки загрузил все твиты Трампа (использя библиотеку twitteR):

Затем очистил данные от незначительного количества постов с веб-интерфейса, iPad и прочих — нас же интересуют только посты с iPhone и Android, верно?

После этого он решил посмотреть, отличается ли время отправки постов с Android и iPhone:

Выяснилось, что да, отличается — публикации с Android происходят преимущественно утром, тогда как публикации с iPhone — днём и ранним вечером:

Как ещё можно понять, что с Android и iPhone пишут разные люди? Дэвид заметил, что иногда вместо обычного ретвита сообщений, Трамп копирует текст чужого поста и помещает его в кавычки, вроде этого:

Как выяснилось, подобное форматирование можно встретить только в постах с Android:

С другой стороны, практически все публикации с прикреплёнными ссылками или изображениями отправляются с iPhone (разница в 38 раз):

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

Результаты получились достаточно предсказуемые:

На основании этого графика можно сделать несколько выводов:

• С Android не публикуются твиты с хэштегами (за исключением “ретвитов”);
• Слова вроде “присоединяйтесь”, “завтра” и “19 часов” используются преимущественно с iPhone, т.е. iPhone используется для анонса мероприятий;
• Почти все грубые, эмоциональные и оценочные выражения (“dumb”, “crazy”, “weak” и т.п.) публикуются с Android.

Полный текст исследования вы можете прочитать у Дэвида в блоге.

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

Регулярные выражения

Даже не смотря на то, что «регулярки» — это первое, что приходит на ум, использовать их для настоящих проектов не стоит.

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

Вместо «допиливания» своего регулярного выражения при каждом малейшем изменении кода рекомендуем использовать инструменты ниже — это и проще, и удобнее, и надежнее.

XPath и DOM

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

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

Вот, например, код с использованием DOM и XPath, который ищет в разметке все теги и модифицирует их атрибуты src:

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

Simple HTML DOM

Simple HTML DOM — PHP-библиотека, позволяющая парсить HTML-код с помощью удобных jQuery-подобных селекторов.

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

Как и JQuery, Simple HTML DOM умеет искать и фильтровать вложенные элементы, обращаться к их атрибутам и даже выбирать отдельные логические элементы кода, например, комментарии.

В этом примере сначала подгружается, а потом модифицируется заранее заготовленный HTML-код: во второй строке происходит добавление атрибута class со значением bar  первом попавшемуся элементу div, а в следующей строке мы заменяем текст элемента с id=”world” на foo.

Несмотря на не самую высокую производительность, по сравнению с другими вариантами, Simple HTML DOM имеет самое большое русскоязычное комьюнити и наибольшую распространенность в рунете — для новичков это делает написание кода с её использованием значительно проще.

phpQuery

Как и Simple HTML DOM, phpQuery является PHP вариантом JQuery, но на этот раз более похожим на своего «старшего javascript-брата».

Портировано почти всё, что есть в JS-фреймворке: поддержка селекторов, атрибутов, манипуляций, обхода, плагинов, событий (в том числе имитации кликов и т.д.) и даже AJAX. Использовать можно как через PHP, так и через командную строку в виде отдельного приложения.

Более того, согласно нашим бенчмаркам, phpQuery оказался в 8 (!) раз быстрее Simple HTML DOM.

Вот небольшой пример на phpQuery, в котором происходит обработка заранее выбранных элементов списка (li):

Подробную документацию и больше примеров найдете на официальной странице в Google Code.

htmlSQL

htmlSQL — экспериментальная PHP библиотека, позволяющая манипулировать HTML-разметкой посредством SQL-подобных запросов.

Простейший пример, извлекающий атрибуты href и title всех ссылок (элементы a) с классом list:

Как и с обычными mysql_ функциями, воспользовавшись методами fetch_array() или fetch_objects(), мы можем получить результат выполнения данного запроса в виде привычного ассоциативного массива или объекта.

Стоит также упомянуть о высоком быстродействии htmlSQL: часто она справляется в несколько раз быстрее phpQuery или того же Simple HTML DOM.

Тем не менее, для сложных задач вам может не хватить функциональности, а разработка библиотеки давно прекращена. Но даже несмотря на это, она всё ещё представляет интерес для веб-разработчиков: в ряде случаев значительно удобнее использовать язык SQL вместо CSS-селекторов. Особенно когда вы не знаете, что такое CSS-селекторы ?

Вывод

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

С другой стороны, для совсем простых задач логично было бы использовать стандартные модули PHP, такие как XPath, DOM или, на крайний случай, регулярные выражения.

Что-то ещё?

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

Подробнее о других способах парсинга средствами PHP можно прочитать в соответствующей теме на StackOverflow.

Если вы не используете PHP, то можете ознакомится с кратким списком похожих инструментов для других языков программирования:

C++: htmlcxx, libxml++;

Python: lxml, BeautifulSoup, html5lib;

Java: JSOUP, TagSoup;

Ruby: Nokogiri, Oga, Rubyful Soup;

Perl: HTML::TokeParser, HTML::Parser, HTML::SimpleParse;

.NET: Html Agility Pack;

Swift: libxml 2, Hpple;

Ассемблер: AsmXml.