DevMan

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).

Стоит ли выбрать такой же?

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

Мой вам совет - оставьте решение этого вопроса команде разработчиков вашего продукта.

p.s. ни хабрахабр ни тостер не являются "сложными" сайтами как таковыми, это мультибложик и сервис вопросов/ответов. Вопрос в нагрузках, но со старта вы в любом случае таких нагрузок не получите.

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

А теперь конкретно по FL. Как это работает - есть акционеры (Мажирин и аптекари) и руководство (Росошанский и Тараханов). Раз в полгода акционеры собираются и говорят руководству - уровень прибыльности должен быть такой. Аптекари покупали долю в у.е. и получать хотят у.е. Мажирину тоже у.е. нужны - хотя бы на танцы свои. Итак, в начале 2013 прибыль была 200 000 у.е. в месяц, а в начале 2015 стала 75 000 у.е. Акционеры говорят руководству - нужно вернуть хотя бы до 150 000 у.е.

Как это сделать - проблема не акционеров, а руководства. И руководство начинает действовать - вводит Profi, поднимает цену Pro, добавляет закрепления и прочие мелкие платности, увольняет кучу людей штата - почти 90%! www.the-village.ru/village/blogs/business/221897-c...
Прибыль пошла в гору. "Ф-у-у-х! Акционеры не уволят, даже премию дадут" - так думает руководство. На первом этапе это так и работает.

Но. Что имеем с итоге: сервис теряет в качестве - не хватает людей для нормального обслуживания пользователей, кода, серверов - отсюда постоянные падения, взломы и недовольство (https://vc.ru/n/fl-off, https://vc.ru/p/fl-hacked и т.д.). Сервис становится дороже (замечу - в рублях, в у.е. остается на том же уровне или дешевле) - отсюда снова недовольство пользователей.

Блин, так почему же эта биржа не умирает? Почему все снова идут и платят (судя по анализу количество PRO за последний год не уменьшилось, а только выросло)? А я скажу - потому что есть заказы. Не просто заказы, а много заказов. Смотрим сколько - primelance.com/analytics/. Блин, да столько же, сколько на всех остальных биржах вместе взятых.

Итог повествования: в обозримой перспективе ничего не изменится. На FL будет много заказов - к ней привыкли, она выделяет денег на рекламу больше остальных, только она обслуживает юриков. Поэтому туда будут идти фрилансеры, будут платить дорогой Pro. Этот самый Pro будет дальше дорожать - думаю, к середине 2016 на уровне 2000-2500 рублей. Если рубль продолжит плохо себя вести - еще больше, или переведут ценник в доллар.

Скажете, на англоязычных лучше и светлее? Нет и еще раз нет. Посмотрите ценник на том же Upwork и радуйтесь, что FL до такого еще не додумалась. Одна радость - там ценник в проектах другой, отсюда и рентабельность работы на буржуев.

Поэтому - если вы знаете или учите английский - валите по быстрому с отечественного фриланса. Если не знаете и учить не собираетесь - радуйтесь, что FL просят 1600 в месяц с неограниченным числом ответов, а не 600 за 10 ответов в месяц, и дальше по 120 рублей за каждый ответ + 10% с каждого заказа (каждого!), как это есть на Upwork.

Потому что вы передаете в качестве key результат вызова функции abs, а не саму функцию. Уберите круглые скобки.

приведенная вами цитата относится исключительно к автозагрузке. Какие контексты использовать - регламентируется в behat.yml.