Алексей Уколов

Один из важных моментов в изучении любого языка - разобраться какие типы данных передаются/присваиваются по значению, а какие по ссылке. Хотя бы бегло, но нужно пробежаться по какому-нибудь учебнику, чтобы меньше удивляться в будущем.

Для начала, эта переменная никем не отдается. Ее формирует сам php.

Часть значений этого массива заполняется из пришедших http-заголовков. Как вы понимаете в некоторых заголовках специально можно прислать всё что угодно.

Тут есть несколько моментов:
1). Да, порядок перечисления условий в запросе в данном случае значения не имеет
2). Если ииндексы отдельные, то планировщик запроса может использовать оба, НО:
3). В данном случае индекс по sex имеет очень плохую селективность ( www.akadia.com/services/ora_index_selectivity.html ), так что я бы поставил надкусанный огурец против португальского эскудо на использование индекса по date и последовательное сканирование того, что выбралось
4). Однако чтобы окончательно прояснить для себя, что действительно используетcя нужно запустить explain и эти вопросы отпадут ( и появятся новые :))

Все-таки не соглашусь с остальными, предлагающими вам гонять голые HTTP-запросы: раз уж задались таким вопросом, то в этих HTTP вообще можете повязнуть.

В вашем случае для того, чтобы добиться положительного результата и при этом не бросить затею, достаточно использовать решения эмуляции браузера. Их много разных (VZVZ советовал Phantom.JS), но с большим покрытием языков (Java, C#, Python, JavaScript) знаю одно - Selenium.

То есть, весь алгоритм вашего автоматизатора сведется к действиям вида : зайди на сайт с видео; проверь, есть ли новые комментарии (это делается простым поиском по id/class блока, либо сложным запросом с помощью xpath); если есть - введи комментарий и кликни по кнопке.

Если сайты аналогичные, то будет проще. Если нет - под каждый сайт нужно будет переделывать слегка алгоритм. Но общая идея, думаю, и так понятна.

Вообще ничего плохого в их использовании не вижу, однако сам всегда использую функцию app('class') или app()->make('class') - оно нагляднее отображает что я беру объект не откуда-то а из IOC, в то время как фасад можно спутать с обычным статическим классом.

Хотя можно совсем извратится и писать Container::getInstance()->make('class', []); но не рекомендую, кто знает когда Тйэлор перепишет хелпер app =)

Кто скажет что статика это зло - смотрим исходники laravel

if (! function_exists('app')) {
    /**
     * Get the available container instance.
     *
     * @param  string  $make
     * @param  array   $parameters
     * @return mixed|\Laravel\Lumen\Application
     */
    function app($make = null, $parameters = [])
    {
        if (is_null($make)) {
            return Container::getInstance();
        }

        return Container::getInstance()->make($make, $parameters);
    }
}

Говоря о специальных методах, нужно все время помнить, что они предназначены для вызова интерпретатором, а не вами. Вы пишете не my_object.__len__ (), а len(my_object), и, если my_object - экземпляр определенного пользователем класса, то Python вызовет реализованный вами метод экземпляра __len__. Однако для встроенных классов, например list, str, bytearray и т. д., интерпретатор поступает проще: реализация функции len() в CPython возвращает значение поля ob_size C-структуры PyVarObject, которой представляется любой встроенный объект в памяти. Это гораздо быстрее, чем вызов метода.
Как правило, специальный метод вызывается неявно. Например, предложение
for i in х: подразумевает вызов функции iter(х), которая, в свою очередь, может
вызывать метод х.__iter__ ( ), если он реализован.
Лучано Рамальо "Fluent Python"

Воркер не дает работать с дом элементами и выполнять синхронные запросы - это собственно основные ограничения. Для вычислений он подходит идеально, просто код вычислений должен находится в самом воркере/воркерах. С основным скриптом он может общаться посредством сообщений. То есть не получится выполнить произвольный код в воркере, но можно выбрать из библиотек только нужные функции и завернуть их в воркер где и выполнить.

Вариант без воркера - делать вычисления поэтапно и вставлять промежутки setTimeout между этапами, чтобы не потерять отзывчивость пользовательского интерфейса.

редирект после отправки

Это у Вас не роутер, а целый сайт/приложение. Монолитное. Единое целое.
Что "не так" с этим приложением?
Всё. Если говорить о правильности подходов.
Что так с этим приложением?
Оно работает. И оно является этапом Вашего роста.
Роутер не должен ничего инклудить и, тем более, знать о каких-то там темплейт-хедерах, да ещё и запросы в базу делать.
Он должен только обладать информацией - "с этим - туда, а с этим - сюда". А информацией этой может воспользоваться уже Диспетчер. Он у Вас тоже вмонтирован своего рода в монолит.
Вам правильные вещи тут говорят. Попробуйте услышать.

Вы используете browser-sync в качестве зависимости в вашем проекте, он сам по себе имеет зависимости, которые в свою очередь имеют свои зависимости, которые в свою очередь...

background: -webkit-linear-gradient(bottom, #87C03B, #98D647);

такую запись браузер читает как

background-image: -webkit-linear-gradient(bottom, #87C03B, #98D647);

background-color меняетcя, но под градиентом этого не видно. Можете проверить, поставив один из цветов в transparent;

Лучше в команды добавьте новое поле для id стадиона, всё равно ведь тип поля менять, а поле названия потом удалите. Когда проверите, что id заполнены верно и для всех строк.

update команды join стадионы on стадион=стадионы.название set стадионid = стадионы.id