1) Если вы пишете библиотеку, то error_handler мягко говоря не самый удобный вариант, вам надо: выставить обработчик перед вызовом, выполнить операцию, вернуть обратно.
2) display errors не убережет вас от warning
php -a тоже уже не падает на ошибки, есть автодополнение и история; в boris фактически только вывод результата + более приятный вариант обработки SIGINT
По поводу разрешенных форматов, имхо, дельное замечание. Я бы сделал что-то типа того:
* Ввести группы, каждый файл цепляется на группу (например «documents»)
* Для группы задаются доступные форматы (в будущем можно и другие настройки цеплять)
* При запросе проверять доступен ли формат
* Урлы сделать с группой (/documents/yPkjPk.jpg), дабы на вебсервере можно было просто сделать такое же ограничение по формату
* Настройки для вебсервера можно генерить прям апликейшеном.
Что касается кэширования, то как раз это лучше перенести на вебсервер. На nginx можно сделать простейшую схему с try_files и X-Accel-Redirect, полностью исключив отдачу файлом непосредственно апликейшеном — только генерация.
Такое построение операционной системы консоли не будет мешать использованию её в сторонних целях или перенастройке под себя. Ожидается, что особого различия между дистрибутивом “Steam Linux” и установленным на Ubuntu клиентом Steam не будет.
Конечно, к сервис ориентированной архитектуре (SOA) это имеет достаточно отдаленное отношение.
В чем преимущество перед указанными «соперниками»? В чем тяжесть симфоневской реализации? Почти уверен что при при дампинге в класс sf di выиграет достаточно много.
Прототипы через клонирование не лучший вариант. Как отдельная фишка — мб, но в основе должен быть вариант простого пересоздание сервиса.
3 топика про портирование одного движка на линукс+макос выдает качество контента, который выдают юзеры. Я к тому, что в одно время в стиме появились бета версии hl & cs 1.6 под линукс и мак. А на хабре аж 3 раза написали.
2) display errors не убережет вас от warning
xdebug.file_link_format = "javascript: var r = new XMLHttpRequest; r.open(\"get\", \"http://localhost:8091?message=%f:%l\");r.send()"
Для IDEA можно почитать тут youtrack.jetbrains.com/issue/IDEA-65879
просто аргументы через --args
Да, не самый короткий вариант. Для частого использования лучше скрипт/алиас сделать.
Symfony Request
* Ввести группы, каждый файл цепляется на группу (например «documents»)
* Для группы задаются доступные форматы (в будущем можно и другие настройки цеплять)
* При запросе проверять доступен ли формат
* Урлы сделать с группой (/documents/yPkjPk.jpg), дабы на вебсервере можно было просто сделать такое же ограничение по формату
* Настройки для вебсервера можно генерить прям апликейшеном.
Что касается кэширования, то как раз это лучше перенести на вебсервер. На nginx можно сделать простейшую схему с try_files и X-Accel-Redirect, полностью исключив отдачу файлом непосредственно апликейшеном — только генерация.
На видео, кажется, говорят про 110 км/ч
В чем преимущество перед указанными «соперниками»? В чем тяжесть симфоневской реализации? Почти уверен что при при дампинге в класс sf di выиграет достаточно много.
Прототипы через клонирование не лучший вариант. Как отдельная фишка — мб, но в основе должен быть вариант простого пересоздание сервиса.
В общем, пока не понятно «зачем».