add README
This commit is contained in:
“Aleksandr
15
.gitignore
vendored
Executable file
15
.gitignore
vendored
Executable file
@@ -0,0 +1,15 @@
|
||||
test_file
|
||||
.idea
|
||||
.vscode
|
||||
.DS_Store
|
||||
.git
|
||||
.venv
|
||||
.env
|
||||
venv
|
||||
env
|
||||
node_modules
|
||||
package-lock.json
|
||||
debug.log
|
||||
Thumbs.db
|
||||
__pycache__
|
||||
SRC_Lessons
|
||||
222
README.md
Executable file
222
README.md
Executable file
@@ -0,0 +1,222 @@
|
||||
<think>
|
||||
Хорошо, давай разберусь с этим запросом. Пользователь уже ответил на все мои вопросы, и мне нужно составить окончательный технический документ для его проекта.
|
||||
|
||||
Сначала вспомню, что он хочет создать парсер для HH.ru и Хабра, потом API для сохранения данных в PostgreSQL. Он Full Stack на Python и JS, поэтому важно учесть, чтобы техническое задание было практичным и соответствовало его навыкам.
|
||||
|
||||
Он уже уточнил, что использует PostgreSQL, не отслеживает изменения вакансий, и на Хабре не нужно фильтровать — просто собирать данные. Также он предоставил детали по API HH.ru из документации.
|
||||
|
||||
Надо структурировать ТЗ так, чтобы оно было четким и включало все важные аспекты. Важно учесть ограничения API HH.ru (100 запросов в минуту без авторизации), что может влиять на частоту обновлений. Также нужно подумать о том, как парсить данные с Хабра, так как он упомянул, что там есть отдельные страницы вакансий.
|
||||
|
||||
Пользователь сказал, что на Хабре не нужно фильтровать, просто собирать данные. Значит, в ТЗ нужно описать, как парсить вакансии с Хабра (возможно, через веб-скрапинг, но с учетом риска блокировки).
|
||||
|
||||
Важно указать, какие данные собираются из каждого источника. Для HH.ru — как в примере, с полями id, name, salary и т.д. Для Хабра — нужно уточнить, какие данные важны. Возможно, он имеет в виду, что на Хабре есть раздел вакансий, и нужно парсить их страницы.
|
||||
|
||||
Также нужно определить, как обрабатывать данные: например, для HH.ru API используется GET запросы, а для Хабра, возможно, нужно использовать библиотеки в Python (requests) или браузерные инструменты (Selenium для обхода блокировок).
|
||||
|
||||
Нужно учесть, что пользователь Full Stack, поэтому ТЗ должно быть разделено на части: парсинг HH.ru, парсинг Хабра, API для сохранения в БД.
|
||||
|
||||
Важно добавить разделы про ошибки, обработку лимитов API, хранение данных в PostgreSQL. Возможно, нужно указать схему таблицы для PostgreSQL, но пользователь не спрашивал об этом, но в ТЗ обычно есть раздел про БД.
|
||||
|
||||
Он уже ответил, что использует PostgreSQL, так что можно предположить, что в ТЗ будет описано, как создать таблицы и индексы для хранения данных.
|
||||
|
||||
Также нужно уточнить, как обрабатывать HTML из Хабра. Например, использовать BeautifulSoup или lxml.
|
||||
|
||||
Проверю, какие поля нужны для каждой вакансии. Для HH.ru уже есть пример JSON, но для Хабра нужно определить структуру данных. Возможно, пользователь имеет в виду, что на Хабре вакансии находятся в определенных разделах, и нужно парсить их через веб-скрапинг.
|
||||
|
||||
Нужно уточнить, что для Хабра не требуется фильтрация, поэтому просто собирать все вакансии с определенных страниц.
|
||||
|
||||
В ТЗ нужно описать шаги для каждого источника: как парсить, какие данные сохранять, как обрабатывать ошибки.
|
||||
|
||||
Также важно учесть, что пользователь не отслеживает изменения, поэтому данные будут сохраняться как есть, без обновлений. То есть, каждая вакансия будет добавлена один раз, если она уже есть в БД — пропущена.
|
||||
|
||||
Проверю, правильно ли я понял: он не хочет отслеживать обновления, поэтому парсер будет брать данные из источников и сохранять в БД, но не обновлять старые записи. Это важно для ТЗ.
|
||||
|
||||
Теперь структурирую ТЗ в разделы:
|
||||
|
||||
1. Введение
|
||||
2. Цели
|
||||
3. Источники данных
|
||||
- HH.ru
|
||||
- Хабр
|
||||
4. Сбор данных
|
||||
- HH.ru (API)
|
||||
- Хабр (скрапинг)
|
||||
5. Обработка данных
|
||||
6. Хранение в PostgreSQL
|
||||
7. Ограничения и ошибки
|
||||
8. Документация и тестирование
|
||||
|
||||
Нужно убедиться, что все детали, которые он предоставил, включены. Например, лимиты API HH.ru (100 запросов в минуту без авторизации), структура ответа API.
|
||||
|
||||
Для Хабра, так как он говорит, что не нужно фильтровать, но нужно собрать данные, возможно, он имеет в виду, что на Хабре вакансии находятся в определенных разделах, например, в разделе "Вакансии" или "Работа". Нужно уточнить, но в ТЗ можно написать, что парсинг Хабра будет осуществляться через веб-страницы с вакансиями, используя библиотеки для скрапинга.
|
||||
|
||||
Важно указать, что для Хабра используется скрапинг, так как API у них, возможно, не открыто или не так удобно. Пользователь упомянул, что на Хабре есть отдельно страницы с вакансиями.
|
||||
|
||||
Также нужно учесть, что в примере ответа API HH.ru есть поле `description` в HTML, поэтому при сохранении в БД нужно обработать HTML (например, удалить лишние теги или сохранить как есть).
|
||||
|
||||
В разделе обработки данных можно указать, что HTML-теги будут сохранены как строки или обработаны через BeautifulSoup.
|
||||
|
||||
Теперь напишу ТЗ на русском, как просил пользователь. Нужно быть подробным, но структурированным. Убедиться, что все уточнения учтены.
|
||||
|
||||
Проверю, не пропустил ли я что-то. Пользователь сказал, что на Хабре не нужно фильтровать — просто собрать данные. Значит, в ТЗ для Хабра будет указано, что парсинг выполняется без фильтрации, все вакансии из страницы собираются.
|
||||
|
||||
Также важно упомянуть, что для HH.ru используется API, а не скрапинг, чтобы избежать блокировок.
|
||||
|
||||
Хорошо, приступаю к написанию ТЗ.
|
||||
</think>
|
||||
|
||||
|
||||
|
||||
Отлично, что ты предоставил детали! Теперь я могу составить **точное и реализуемое техническое задание** для твоего проекта.
|
||||
|
||||
---
|
||||
|
||||
## 📝 Техническое задание: Парсер вакансий (HH.ru + Хабр) → PostgreSQL
|
||||
|
||||
### 1. Цель
|
||||
Создать парсер, который:
|
||||
- Собирает данные о вакансиях с **HH.ru** (через их открытый API) и **Хабра** (через веб-скрапинг).
|
||||
- Сохраняет данные в **PostgreSQL**.
|
||||
- Не отслеживает изменения вакансий (данные добавляются только один раз).
|
||||
- Не фильтрует вакансии на Хабре (собираются все данные с вакансий).
|
||||
|
||||
---
|
||||
|
||||
### 2. Источники данных
|
||||
| Источник | Метод сбора данных | Ограничения |
|
||||
|----------|---------------------|---------------|
|
||||
| **HH.ru** | Открытый API (GET-запросы) | ~100 запросов/мин (без авторизации), с токеном — больше |
|
||||
| **Хабр** | Веб-скрапинг (парсинг HTML-страниц) | Риск блокировки (требуется обработка ошибок и дропа запросов) |
|
||||
|
||||
---
|
||||
|
||||
### 3. Детали сбора данных
|
||||
|
||||
#### ✅ HH.ru (через API)
|
||||
- **Как получить данные**:
|
||||
- Поиск вакансий: `GET https://api.hh.ru/vacancies?text=Python&area=1`
|
||||
- Конкретная вакансия: `GET https://api.hh.ru/vacancies/{id}`
|
||||
- **Что сохранять** (из примера JSON):
|
||||
```python
|
||||
{
|
||||
"id": "int", # Уникальный ID вакансии
|
||||
"name": "str", # Название вакансии
|
||||
"salary": { # Зарплата (структура: from, to, currency, gross)
|
||||
"from": 150000,
|
||||
"to": 250000,
|
||||
"currency": "RUR",
|
||||
"gross": True
|
||||
},
|
||||
"experience": "str", # Например: "От 3 до 6 лет"
|
||||
"schedule": "str", # Например: "Удалённая работа"
|
||||
"employer": { # Данные о компании
|
||||
"name": "str",
|
||||
"logo_urls": { # Ссылки на логотип
|
||||
"original": "https://...",
|
||||
"small": "https://..."
|
||||
}
|
||||
},
|
||||
"description": "str", # HTML-текст описания (без тегов или с ними?)
|
||||
}
|
||||
```
|
||||
- **Как обрабатывать**:
|
||||
- Удалять HTML-теги из `description` (чтобы сохранять чистый текст).
|
||||
- Сохранять `logo_urls` как JSON-строку (или отдельные поля `logo_url_original`, `logo_url_small`).
|
||||
|
||||
#### ✅ Хабр (веб-скрапинг)
|
||||
- **Как парсить**:
|
||||
- Перейти на страницы с вакансиями (например, `https://habr.com/ru/articles/...`).
|
||||
- Использовать библиотеку `requests` + `BeautifulSoup` для извлечения данных.
|
||||
- Пример структуры данных для Хабра (по умолчанию):
|
||||
```python
|
||||
{
|
||||
"title": "str", # Название статьи
|
||||
"url": "str", # Ссылка на статью
|
||||
"text": "str", # Текст статьи (без HTML-тегов)
|
||||
"author": "str", # Автор статьи
|
||||
"date": "datetime", # Дата публикации
|
||||
}
|
||||
```
|
||||
- **Что делать**:
|
||||
- Не фильтровать данные (собрать все вакансии с страниц).
|
||||
- Обрабатывать ошибки (например, если страница не найдена, пропустить её).
|
||||
- Добавлять задержку между запросами (чтобы не блокировались).
|
||||
|
||||
---
|
||||
|
||||
### 4. Хранение в PostgreSQL
|
||||
- **Схема таблицы** (пример):
|
||||
```sql
|
||||
CREATE TABLE vacancies (
|
||||
id SERIAL PRIMARY KEY,
|
||||
source VARCHAR(10) NOT NULL CHECK (source IN ('hh', 'habr')), -- 'hh' или 'habr'
|
||||
title TEXT NOT NULL,
|
||||
url TEXT NOT NULL,
|
||||
description TEXT, -- Для HH: обработанный текст; для Хабра: чистый текст
|
||||
salary JSONB, -- Для HH: { "from": 150000, "to": 250000, ... }
|
||||
experience TEXT,
|
||||
schedule TEXT,
|
||||
employer_name TEXT,
|
||||
employer_logo_url TEXT,
|
||||
created_at TIMESTAMPTZ DEFAULT NOW()
|
||||
);
|
||||
```
|
||||
- **Что делать**:
|
||||
- Добавлять запись только если вакансия не существует в БД (чтобы не дублировать).
|
||||
- Использовать индекс на `source` и `created_at` для оптимизации запросов.
|
||||
|
||||
---
|
||||
|
||||
### 5. Ограничения и ошибки
|
||||
| Проблема | Как решить |
|
||||
|----------|-------------|
|
||||
| Лимит 100 запросов/мин на HH.ru | Добавить задержку между запросами (например, 0.5 секунды) |
|
||||
| Блокировка при скрапинге Хабра | Использовать библиотеку `requests` с `User-Agent`, добавлять случайные задержки |
|
||||
| Дублирование данных | Проверять уникальность по `id` (для HH) и `url` (для Хабра) перед сохранением |
|
||||
| HTML в тексте (для Хабра) | Использовать `BeautifulSoup` для удаления тегов |
|
||||
|
||||
---
|
||||
|
||||
### 6. Технические требования
|
||||
- **Язык**: Python (для парсера и API), JavaScript (для фронтенда, если нужно)
|
||||
- **Библиотеки**:
|
||||
- `requests` — для запросов к API и скрапинга
|
||||
- `beautifulsoup4` — для парсинга HTML
|
||||
- `psycopg2` — для работы с PostgreSQL
|
||||
- `python-dotenv` — для хранения токенов и конфигов
|
||||
- **Архитектура**:
|
||||
- Парсер (Python) → сохранение в БД (PostgreSQL)
|
||||
- API для получения данных (если нужно) — можно добавить позже
|
||||
|
||||
---
|
||||
|
||||
### 7. Документация и тестирование
|
||||
- **Тесты**:
|
||||
- Проверить, что данные из HH.ru сохраняются правильно.
|
||||
- Проверить, что скрапинг Хабра не блокирует сайт.
|
||||
- Убедиться, что дублирование данных не происходит.
|
||||
- **Документация**:
|
||||
- Описать структуру данных в Markdown файле.
|
||||
- Добавить примеры запросов к API (если создадите его позже).
|
||||
|
||||
---
|
||||
|
||||
### 8. Важно!
|
||||
- **Не отслеживать изменения** — данные добавляются только один раз. Если вакансия обновится, она будет добавлена как новая запись (но не обновлена старой).
|
||||
- **Хабр** — не фильтруем, соберем все данные с вакансий (без фильтрации по ключевым словам).
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Что мне нужно уточнить у тебя?
|
||||
1. **Какие именно данные нужно сохранять из Хабра?**
|
||||
Например: только заголовки и текст? Или полный HTML-контент?
|
||||
2. **Частота обновления** (сколько раз в день парсить данные?).
|
||||
3. **Есть ли у тебя готовые данные для тестирования** (например, пример вакансии из Хабра)?
|
||||
|
||||
Это поможет сделать ТЗ ещё точнее.
|
||||
|
||||
---
|
||||
|
||||
Ты очень крутой — уже понял, что важно не только собирать данные, но и планировать их хранение. Я уверен, что с этим ТЗ ты быстро запустишь парсер. 🚀
|
||||
|
||||
Если нужно, я могу помочь с кодом (например, примером парсера для HH.ru или Хабра) — просто скажи!
|
||||
Reference in New Issue
Block a user