Sanes: давайте так, вы ее читали? Первые 3-4 раздела например. Они как раз таки идут именно в формате учебного материала. Мы же не предлагаем вам заучивать справочник функций. Документация для PHP официальная весьма и весьма годная.
Oleg Shevelev: для своих задач я окружение контролирую, так что у меня нет такой проблемы.
Запилить простенький менеджер процессов который будет стабильно работать и поднимать скрипты проблемы не составляет (если мастер-процесс тупой до безобразия то и падать там нечему). Я не гуглил, но вроде даже найти такой можно. Если вдуг мне понадобится такой (а весьма вероятно что скоро понадобится) то я буду уже ковыряться. В частности ближайшее время понадобится поднять мини-сервис на php-pm и если там мастер процесс умеет что-то больше чем менеджить процессы то я это дело почищу.
Про падение скриптов не совсем понял, в следствии ошибок вашей программы? Да как бы... сломать то все можно. Опять же только у ерланга из коробки идет мягкое подение, и то я с ним не работал (хотя в планах). В PHP7 например большую часть фаталов уже превратили в исключения, так что проблем с контролем ошибок не сильно много нынче.
По поводу многопоточных парсеров - а зачем их делать многопоточными? намного эффективнее использовать stream_select или мультикурл (который внутри как раз таки стрим селект вроде и использует). По поводу simple_html_dom - да, он медленный, ничего не скажу, но опять же, никто не мешает вам взять какой-то другой. В случае с большими объемами данных будем грузить по частям и отдавать в SAX парсер какой. Да и не знаю откуда вы взяли информацию о гигобайтных файлах (которые обрабатывать пыхам не проблема, sax парсеры имеются), у автора весьма тривиальная задача. Не надо выдумывать.
А у меня крутится вертятся всякие чатики, один демон для APNS (перешел на AWS SNS, ибо суппортить эти демоны боль), кучи обработчиков очередей и т.д. Проблем с выжиранием ресурсов нет, в плане прожерливости пых эффективнее ноды, хоть и работает сильно медленнее в вопросах парсинга. Но мне не парсинг нужен, так что все норм.
p.s. Вы как-то странное начали наезжать на демоны на PHP при том что ровно те же проблемы у всех других языков (кроме ерлангов). Спасают только те же менеджеры процессов, та же кооперативная многозадачность, правильный хэндлинг ошибок и т.д.
Oleg Shevelev:
1) GC в PHP норм, он плохо себя чувствует только при работе с большими графами объектов, это меньше 1% задачь решаемых на PHP даже в виде демонов. Пример - известный баг composer.
2) ну как и в любом другом языке (кроме erlang), на то придумали supervisord
3) у автора 90% времени работы скрипта - работа с I/O. В целом с производительностью у PHP проблем нет, он быстрее CRuby и CPython. У меня на нем живет и не тужит k-means класстеризация (там распарарелить всеравно ничего не выходит так что пофигу, ни векторизация вычислений и треды не помогут).
Главная мысль в том что ваша информация актуальна для версии PHP 5.2 и ниже. Уже лет 5 это все враки и домыслы.
Максим: ....объект он хочет видеть когда преобразует значение из формата объекта (то откуда вы мэпите на форму, ваши сущности или dto или еще чего) в формат представления (строка). Это прямая трансформация, что бы задать значения формы.
reverseTransform - это обратная операция, то что вам и нужно, конвертация значения из формата представления в формат приложения. У вас падает на transform, то есть либо вы не правильно как-то используете дата трансформеры, либо у вас фэйлится все на этапе создания формы и мэппинга значений по умолчанию.
copal: да, как-то забыл о нем. Просто я предполагаю что раз компания занимается производством лестниц, то у них уже есть чертежи оных в каком нибудь CAD.
xmoonlight: какого процесса? Ну пока вы рисуете я обрисую свое виденье:
приложение состоит из 3-х слоев - Framework Layer (или Infrastructure Layer), Application Layer и Domain Layer
Domain Layer - бизнес объекты и сервисы содержащие бизнес правила, так же интерфейсы репозиториев для бизнес объектов
Application Layer - сервисы уровня приложения, хэндлеры команд и экзекюторы запросов если мы говорим про CQRS. По классу на юз кейс. Все что делают эти сервисы - управляют другими сервисами и бизнес объектами. По сути они дублируют содержание юз кейса. Весь этот слой и слой ниже никак не привязан к фреймворкам, базам данных и прочей чуши (конечно в идеале только, в реальночти чуть чуть просачивается). Для того что бы протестить этот слой (а значит всю бизнес логику) мне не надо подключать фреймворки и базы данных - максимальная скорость выполнения тестов, можно делать все через TDD.
Framework Layer - содержит реализацию интерфейсов объявленных в Application Layer и Domain Layer. У меня там весь фреймворк (контроллеры, http foundation и т.д.), библиотечки (aws sns например или еще чего), реализация доктриновский репозиториев и прочая чушь. Является поддерживающим слоем. То есть не влияет на бизнес логику, он нужно что бы выполнить то что хочет приложение (имэйл послать например). Но грубо говоря это только интерфейс, этот слой уже снаружи приложения, оболочка.
Вот... Framework Layer и Application Layer ходят DTO. Приложение ничего не знает о интерфейсе через которое с ним работают и все такое. Вот так можно жить и жить очень хорошо. Но надо развивать инструменты кодогенерации так как DTO писать руками скучно.
гуглить все умеют, но таким образом нормально выйграть не выходит. Проще загрузить этих нещастных 100 килобайт пожатого JS-а на клиент (не считая ангуляр и зависимости) и не париться и показать пользователю красивый прелоадер.
nico: если у вас нет понимания предметной области - это большая проблема, с учетом того что как вы сказали логика довольно сложная. В этом плане помогают user stories/use cases прописанные + схемки всякие.
