index0h

Электрика забыли, если у вас лампочка перегорит - программисты в крутить не смогут, хардварная задача все таки.

Команда подбирается под проект. Интернет проект - это абстракция, Google например - это интернет проект, страничка в vk Васи Пупкина - это тоже интернет проект. В общем не с той стороны шоколадный рогалик едите

> А как происходит дело в NodeJS ?
Прими за исходную: работаешь со строкой, которую записываешь в body ответа. Не больше и не меньше. Да, можно сделать эту строку в виде "< html >< body >" + myContentVarHere + "< /body >< /html >", но зачем? Есть популярные шаблонизаторы: Jade, EJS, JQtemplates используй их.

@Fesor
> В целом PHP плохой шаблонизатор.
Не согласен. PHP - stateless язык, который вполне себе ок шаблонизатор. Если верить википедии: PHP: Hypertext Preprocessor. Да, есть twig, да есть smarty, но эти шаблонизаторы только пародируют PHP. Результат их работы - это тот же PHP код, только кэшированный.

> Пока у людей пишущих на php появляются такие мысли, над php будут продолжать смеяться.
Над нами php-dev смеются потому что:
1. Динамическая типизация. 5 + "5abc" + "abc5" по хорошему должно давать исключение в стиле "парень меняй драг диллера, это какое-то УГ!".
2. Не консистентное API. С тем же if (!strpos(...)) наверняка хлебнули горя.
3. Наличие миллиона стандартов. Да, есть PSR, расскажите о нем автору, знающему кохану.
4. Что на счет scalar type hinting? Всего 20 лет прошло как в 7-ке это таки решили внедрить, и то с ограничениями на вывод.
5. Что на счет демонов? Да, я знаю, можно, да я знаю как, но №;%: есть языки для этого приспособленные и php в их число не входит, это stateless язык!

Я отошел от темы шаблонизаторов.
Чем принципиально {{someVar}} лучше <?= $someVar; ?>, учитывая, что шаблон в любом случае приведется к нейтивному коду + за кэшируется?

Никакую. CMS стоит использовать, если она полностью решает вашу задачу. Да, есть ребятки, что на WP электронные магазины пишут, это безусловно "круто", но хорошего в этом ничего нет (это не целевое использование).

Конкретно под вашу задачу CMS вы не найдете, по той причине, что задача очень специфическая. Непосредственно сам движок поиска писать на php я вам не рекомендую, по сути это процессинг большого количества данных и php для этого НЕ ок.

Может, но php для этого подходит так же, как надувной шарик для кладки кирпичей.
Если нужно сделать именно однонаправленный поток - юзайте UDP и будет вам счастье.

На счет отдачи данных именно частями: habrahabr.ru/post/250343

Открой для себя доктрину, посмотри как там реализовано.

Как заставить заказчика после сдачи сайта его наполнять?

Если вам за это платят - заполняйте)). Если нет - не заполняйте.
Заставлять И в том И в другом случае не нужно.

Или лучше очень навязчиво предлагать свои услуги по наполнению сайта заказчика?

Зачем? Контентщики получают меньше программистов, как правило. Хотя если цель - просрат@ время, безусловно, дерзайте.

Можно ли столовым одноразовым ножом разделать синего кита? В теории - да, но это не целевое применение.

Sentry, но в отличии от ELK приложение отправляет логи, а не logstash их подтягивает.

Опять ты...))) Уже ж спрашивал.

Подобная ситуация возможна, если явно делаешь что-то не так. Роутинг - это не задача контроллера.
Не стоит запиливать много логики в роутер, потом же обязательно аукнется.

Посмотри реализацию: docs.slimframework.com/routing/get, lumen.laravel.com/docs/routing

Если вопрос именно про скорость: то это уже настройки web сервера, с приведением частных путей к более обобщенным

Selenium?

Можно, это называется База Данных. Не стоит решать задачи методами 20-ти летней давности.

Что вы хотите услышать?)) ElasticSearch / Lucene / Sphinx / Solr... не существуют в абстрактном вакууме и без возможности их установить в принципе бесполезны. Как это делается - читайте в официальных документациях.

то, что вы ищите называется issue tracker / bug tracker / task manager. Их довольно много, но лучше подберите по себя.
Redmine, Trac, Jira, youTrack, Trello....

Я праивльно понял вопрос: вы сравниваете map (хэш таблицу) с вложенными структурами?

Если да - не путайте зеленое и мягкое.
Отображения (они же map) используются как не упорядоченные хранилища ключ-значение с быстрым поиском.
Вложенные структуры предполагают иерархию функционала и данных.
Срезы (или массивы) структур - это упорядоченные списки функционала и данных.

Как я пока понял из интернетов - массив, в котором вместо числового индекса - все что угодно.

Не совсем, ключом не могут быть срезы, отображения, и функции. Пруф
Внутри map

нет

PhantomsJS + время