Исходное сообщение
"Увидела свет система управления web-контентом Drupal 8" Отправлено FractalizeR, 21-Ноя-15 21:10
>> Если речь идёт о разработке под заказ, то выясняются сначала требования, а потом идёт разработка. > Это не про php. И это не про php-прогеров. Есть чем подкрепить это заявление? > Как бы сформулировать - php тянут в основном из-за массы уже написанного > кода и готовых cms. Все эти вордпрессы, жумлы и битриксы берут > ради гиганского рынка готовых плагинов к ним, от фотогалерей до магазинов. Есть чем подкрепить это заявление? > В php нет культуры деплоя, т.к. он разрабатывался с прицелом на "скиньте > пару файлов на сервер по ftp". И сейчас мы видим портянки > из ini_set() и шаманство с .htaccess, чтобы хоть немного нормализовать окружение. > Если вдруг у кого-то нет апача - ой, всё! (привет owncloud! > привет, glpi!). Есть чем подкрепить это заявление? Сейчас для деплоя PHP приложений есть разные подходы. Кстати, если для деплоя вашего приложения работает подход "залил файлы по FTP и готово" - не вижу в этом ничего плохого. А если этот подход дает сбой, есть другие. Можно деплоить из git, с использованием composer. Есть много вариантов. > Следствием из предыдущего пункта - нет также культуры использования appserver'ов. Вероятно, это потому, что PHP изначально проектировался так. Он не хранит состояние между запросами. И я бы не сказал, что это однозначно плохо. > Потому что всё отдаётся на откуп fastcgi/mod_php и его настройкам. Любой php-файл  - это потенцальная входная точка. (чтобы этому противодействовать - лепим include guard'ы, прямо как в си). Есть чем подкрепить это заявление? В любом современном PHP фреймворке точка входа в приложение одна. И потом, все зависит от того, как вы настроили веб-сервер. Достаточно легко сделать так, чтобы точка входа оставалась одной вне зависимости от того, залиты ли на сервер императивные скрипты. > Нельзя сделать демон на чистом php и ждать, что он переварит хотя-бы 10k запросов без перезапуска. Утечки, сэр. (привет cacti-poller!) Это закрывает нишу dev-server'ов, типа того же morbo или paster. PHP не единственный язык, допускающий утечки памяти: - http://v32.rusrails.ru/debugging-rails-applications/debuggin... - https://pythonhosted.org/Pympler/muppy.html То, что PHP приложение не имеет состояния, снижает ущерб от утечек памяти. Однако, есть уже и такие решения: http://appserver.io. Ну и HHVM. Хотя, это не чистый PHP, конечно

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> Если речь идёт о разработке под заказ, то выясняются сначала требования, а потом идёт разработка. >> Это не про php. И это не про php-прогеров. > Есть чем подкрепить это заявление? >> Как бы сформулировать - php тянут в основном из-за массы уже написанного >> кода и готовых cms. Все эти вордпрессы, жумлы и битриксы берут >> ради гиганского рынка готовых плагинов к ним, от фотогалерей до магазинов. > Есть чем подкрепить это заявление? >> В php нет культуры деплоя, т.к. он разрабатывался с прицелом на "скиньте >> пару файлов на сервер по ftp". И сейчас мы видим портянки >> из ini_set() и шаманство с .htaccess, чтобы хоть немного нормализовать окружение. >> Если вдруг у кого-то нет апача - ой, всё! (привет owncloud! >> привет, glpi!). > Есть чем подкрепить это заявление? Сейчас для деплоя PHP приложений есть разные > подходы. Кстати, если для деплоя вашего приложения работает подход "залил файлы > по FTP и готово" - не вижу в этом ничего плохого. > А если этот подход дает сбой, есть другие. Можно деплоить из > git, с использованием composer. Есть много вариантов. >> Следствием из предыдущего пункта - нет также культуры использования appserver'ов. > Вероятно, это потому, что PHP изначально проектировался так. Он не хранит состояние > между запросами. И я бы не сказал, что это однозначно плохо. >> Потому что всё отдаётся на откуп fastcgi/mod_php и его настройкам. Любой php-файл - это потенцальная входная точка. (чтобы этому противодействовать - лепим include guard'ы, прямо как в си). > Есть чем подкрепить это заявление? В любом современном PHP фреймворке точка входа > в приложение одна. И потом, все зависит от того, как вы > настроили веб-сервер. Достаточно легко сделать так, чтобы точка входа оставалась одной > вне зависимости от того, залиты ли на сервер императивные скрипты. >> Нельзя сделать демон на чистом php и ждать, что он переварит хотя-бы 10k запросов без перезапуска. Утечки, сэр. (привет cacti-poller!) Это закрывает нишу dev-server'ов, типа того же morbo или paster. > PHP не единственный язык, допускающий утечки памяти: > - http://v32.rusrails.ru/debugging-rails-applications/debugging-memory-leaks > - https://pythonhosted.org/Pympler/muppy.html > То, что PHP приложение не имеет состояния, снижает ущерб от утечек памяти. > Однако, есть уже и такие решения: http://appserver.io. Ну и HHVM. Хотя, > это не чистый PHP, конечно
	Введите код, изображенный на картинке: