DevMan

лучше всего организовать автоматическую сборку исходников на сервере?

Лучше всего исходники собирать не на сервере. Разве что на CI-сервере. Делаем билд, и деплоим только артефакты билда.

А как же JS найдёт эти самые элементы с классом success-pay, если страница ещё не готова? Как минимум должен загрузиться HTML DOM, а в вашем случае ещё и jquery. Чтобы найти и разобраться с другими причинами задержек, смотрите вкладку DevTools Network.

И это $('.success-pay').click(); не обработчик, а триггер события.

Если хотите максимальной скорости, то можно переписать на JavaScript и разместить код перед закрывающим тегом body:

<script>
var el = document.getElementsByClassName('success-pay');
for (var i = 0; i < el.length; i++) {
    el[i].click();
}
</script>
<!-- Дальше уже подключайте jquery и прочее -->
<script src="//code.jquery.com/jquery-2.1.4.min.js"></script>
</body>

HTTP PROXY - NO
SOCKS 5 - YES

для начала вам надо разобраться что такое куки. Как куки передаются на клиент. Что такое заголовки и тело HTTP запросов и ответов. И тогда все встанет на свои места. Ну а что бы небыло проблем - почитать про управление буферизацией вывода в PHP.

Чем куки отличаются от сессии в PHP?

Вообще первое, что я посоветую - забыть на время про программирование и учить английский. Для понимания большинства книг тебе будет достаточно уровня Intermediate (B1, словарный запас 2-3 тысячи слов + общее понимание грамматики). Ибо все равно без английского ты достаточно быстро замучаешься. Точнее скажу, ты замучаешься при первой попытке погуглить любое нетривиальное решение возникшей проблемы (ибо многие подходящие решения будут объяснены по-английски на StackOverflow и подобных сайтах). Ну и при возникновении ошибок в ходе выполнения программы интерпретатор тоже будет "ругаться" по-английски. Если ты никогда не учил английский, пару лет на это уйдет, если заниматься не слишком интенсивно. Если взяться интенсивно, можно и за год, в принципе, достичь этого. Это не совсем просто. Но оно того стоит, 100%.

После этого можно идти на coursera и записываться на курс для новичков по интересующему тебя ЯП. Например, для питона это что-то такое. Ну необязательно, конечно, coursera, есть и другие образовательные сайты (пример) - тут уже гугл тебе в руки.

Просто без знания английского ты всегда будешь позади на пару лет: книги пишутся и переводятся на русский небыстро. Ну и как я уже сказал выше, уже средние знания английского сильно облегчат твою дальнейшую жизнь в смысле поиска решений в Сети. Это не зависит от выбранных технологий - такая же ситуация будет и с Java, Ruby, Go и любыми другими ЯП.

Разумеется, можно параллельно учить английский и читать книги по питону. На этот случай тебе уже присоветовали книги. Я бы рекомендовал начать с Доусона. Книга Лутца, конечно, более универсальная, но уж очень она подробная для начала: можно и запутаться в таком объеме информации (хотя ничего действительно сложного там нет). Еще для быстрого старта подойдет эта книга. Но английский все равно в первую очередь учить, без него беда.

Ну и в качестве лирического отступления. Я бы лично задумался на твоем месте: а нужно ли мне вообще программирование (безотносительно к питону)? Ибо если тебе быстро становится скучно уже во время изучения основ и хочется убыстрить процесс обучения... Ну вряд ли дальнейшее обучение будет в радость. Программирование вообще-то не самый веселый и разнообразный процесс. Особенно нудно проходит отладка, вылавливание ошибок в программах. Я сам, хоть и не программист по образованию, неоднократно тратил долгие часы и дни в поиске трудноуловимых ошибок в уже написанной программе. Нередко бывало, что процесс тестирования программы занимал в разы больше времени, чем, собственно, написание кода. И это вполне типичная ситуация, независимо от ЯП. А уж когда ты выучишь, наконец, более-менее синтаксис любого языка и начнешь углубляться в алгоритмы - тут уже веселья вообще будет минимум. А вот внимательности, педантичности и настойчивости потребуется немало.

Поэтому если уж ни в какую не хочется тратить долгие месяцы на изучение английского и одновременное изучение синтаксиса языка программирования, введения в алгоритмы и т.п. - займись чем-то другим.

Цитата из документации:

С версии PHP 5.5.2 доступна опция session.use_strict_mode. При ее включении и при условии, что модуль сохранения сессий ее поддерживает, неинициализированный сессионный ID отвергается и создается новый. Это защищает от атак, которые принуждают пользователя использовать заранее известный ID. Атакующий может размещать ссылки или отправлять письма, которые содержат сессионный ID. Например example.com/page.php?PHPSESSID=123456789 . Если опция session.use_trans_sid включена, то жертва откроет сессию с этим идентификатором. Опция session.use_strict_mode уменьшает этот риск.

Так вот эта настройка по умолчанию выключена. Это означает, что если при таком раскладе вам начнут присылать несколько таких запросов в секунду, каждый из которых открывает новую сессию, вы очень быстро упретесь в предел количества открытых файлов (потому что session.save_handler по умолчанию files):
cat /proc/sys/fs/file-max
Почитайте раздел PHP про безопасность сессий, там много интересного.

Начните с документации: php.net/manual/ru/security.php. там очень подробно описано, на что следует обращать внимание, уделяя внимание безопасности в PHP, не только насчет ini_set(). Там и XSS, и SQL Injection, и session highjacking и все-все-все.

Нет никакого минимума знаний при устройстве на работу. Это вам не ЕГЭ в школе, когда набрал минимальный проходной балл и поступил куда-нибудь. Никакой минимум вам не гарантирует работу младшего веб-разработчика, тем более в Москве.

Смотрите, что требуют в вакансиях на эту должность.

В последнее время началась мода на PostCSS - много постов, статей о нем.

А почему бы и да? Любые инструменты надо пиарить что бы народ ими пользовался. Ибо народ будет пользоваться тем что на слуху (ну или тем с чем привык работать). Больше народа - больше идей, быстрее идет развитие, формируется комьюнити и поддерживать решение становится чуть проще. Да и приятно это когда твои наработки используют.

Есть даже версия (не без оснований), что это - прародитель всех современных препроцессоров и веяний.

Где ж это вы такое прочитали? postcss был попыткой решить проблемы, которые нельзя решить препроцессорами (или можно но долго).

Окей, будем считать так, тем паче, что история коммитов на Гите это скорее подтверждает.

Что именно подтверждает? сначала был Sass написанный рубистами что бы CSS можно было бы готовить так же нежно как они готовят HTML на HAML (кофескрипт туда же, рубистам хотелось сделать js похожим на ruby). И это заметте было в 2006-ом году! тогда и js был медленный, и V8 может только в планах был...

Ведь все, что умеет PostCSS, умеют и препроцессоры

postcss из коробки не умеет ровным счетом ничего. Он может только загрузить AST CSS файла и слепить из него обратно тот же CSS.

И именно в этом сила postcss - модульность. Все существующие препроцессоры монолитны. То есть вы не можете просто так взять и добавить что-то свое туда. Да, в последних версиях less (и вроде как sass туда же подтягивается) у вас есть примитивный набор средств что бы вклиниться в процесс обработки AST документа и добавить какие-то примитивные вещи. Но это не удобно. Если вы хотите динамически менять проперти (например пересчитывать rem в em) или добавлять еще (опять же для того что бы руками не плодить в css кастыли для разных браузеров и делать это автоматом, на завязываясь ни на миксины и оставляя CSS чистым) свойств, но сделать это на less/sass сложно.

Намного проще взять postcss и натравить это дело на результат работы препроцессоров.

Давайте придумаем пример того, что можно легко и просто сделать при помощи пост процессоров и что сложно сделать с препроцессорами. Самое первое что приходит в голову - инлайнинг ресурсов. Например мелкие png-ки. Или работа с относительными путями, ресолвинг оных точнее. В этом случае мы с postcss напишем маленькую функцию, которая пробежится по всему абстрактному синтаксическому дереву и найдет использование url(). далее мы можем проверить размеры картинки и заинлайнить их (если у них размер достаточно маленький). Или собрать список всех задействованных картинок и использовать их потом (например что бы скопировать только то, что мы реально используем).

Вот как-то так. А за счет того что мы имеем доступ целиком и полностью к формированию и обработке AST мы можем и синтаксис CSS развивать. Примерами могут служить многочисленные плагины аля cssnext и т.п. Можно даже большую часть фич sass в виде плагинов подключить.

А самое забавное, что работает это все быстрее того же libsass на плюсах. За счет архитектуры (имею в виду не голый postcss а с набором плагинов добавляющих функциональность sass).