(с) анекдот

посоны

делаю короч агрегатор вакансий

надо парсить с нескольких источников

как лучше организовать структура парсера?

для каждого сайта свой парсер в своём классе?

Бота в телегу замути

или в ожном классе?

Хотя я такое видел вроде

думаю 1 варик

Я бы так сделал

Есть у тебя класс который парсит

при чем тут телега

я не себе делаю

и есть у тебя настройки парсинга

шаблоны парсинга, назовем это правильно

В итоге получаем расширяемую систему

ну вот как в socialite, можно сделать типа как там провайдеры

то есть какой то общий класс

но передавать сайт который парсим и оттуда уже выбирается свой метод

Да, что то в таком стиле

хотя там парсинг сильно отличается в них

общий класс - интерфейс =)

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

содаешь методы для управления, если будет общий похожий функционал - в абстракный класс

а от него наследуешь всё что тебе надо

для каждого отдельного источника

ага, норм, попробую

разберись с сущностями

что есть что

да я уже разобрался вроде с сущностями

составил список что должно быть в вакансии

в разных источниках разная инфа а у меня уже все суммируется и складывается в поля которые я уже задал

осталось сами парсеры написать

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

надо будет как то объединять в один вид

у тебя есть стратегии парсинга данных, но вакансия, отображаемая в твоем агрегаторе, одна

да

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

Ты сначала парсер напиши

не

а потом уже придумаешь как в общий вид привести

надо сначала продумать

а то напарсю а там данные не те что надо

Загонять в гугл карту, получать геолокацию

ее загонять в бд не вариант?

Так у тебя будет общий формат

А гугл мапс схватает все

при чем тут гугл карта?))

для каждого сайта свой парсер в своём классе?

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

вот например в одном из источников откуда буду парсить идут города, и например город id = 1 title = Москва

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

в стратегии парсинга все это должно быть инкапсулировано

ну вот как автоматизировать то, как мой пхп код поймет что в ожном случае id 1 это москва а в другом это мухосранск? или вручную делать соответствия?

Не ври мне анимешник

цель - привести всю байду к единому интерфейсу - с каждого источника по-своему

ну это уже вопрос реализации

города вручную соответсвовать?

Надеюсь это не мне =)

доку дочитал?

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

вечра работало а сегодня нет?

не помню чо ты писал

Может быть общий сервис парсинга принимающий интерфейс. А фабрика будет те создавать нужный парсер по ситуации. Из парсера возвращать обьект вакансии, готовый к вставке в бд.

В сервисе принимать репозиторий интерфейсом в который уже и втыкать твой дто

У вас флудить нельзя а тут че можно?

@perin Жень

@perin Жень

А?

спам

Аа

Я только пришел с зала, еще немного упоротый

Я только пришел с зала, еще немного упоротый

забань и дальше отходи ;)

Нет.

Carbon::format

Подскажите в какую сторону копать - поставил https://github.com/Riari/laravel-forum Вызываю $user->roles и получаю разные результаты на разных страницах 0_0 Как пакет мог поменять работу manytomany? Уже весь код перелопатил не могу найти подозрительных мест

посоны

посоветуйте простой и легкий css фрейм, от него нужна сетка и адаптивное меню

или по отдельности посоветуйте сетку и отдельно адаптивное меню :)

скелетон, бустрап

буцтрап излишен, хотя и можно скомпилировать только нужное, но всё равно, он мне не нравится внешне