Андрей Захаров

Есть резюме, портфолио, но заказов никаких нет.

Если хотите советов по существу, по их здесь показать надо в первую очередь.

То есть могу обучаться в процессе работы.

Это в офис джуниором.

На фрилансе фраза "не знаю но для вас разберусь" сразу крест на вас, заказчик (как минимум в своих фантазиях) выбирает между теми кто сделает быстро и хорошо и теми кто сделает очень быстро и очень хорошо.

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

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

На SomaFM включаю cliqhop idm, Space Station Soma, либо Underground 80s.

di.fm/trance

Шаблонизатор шаблонизатору рознь. Но в целом следует выделить общие задачи. которые должны решать за вас шаблонизаторы. С blade не работал и не вижу смысла есть есть twig.

Безопасность. Это пожалуй можно поднять на верх. Типичная картина в шаблонах на php - <?= $someUserInput; ?>. Частенько это можно встретить в выводе инпутов, при формировании ошибок поиска (мол "по запросу $userInput ничего не найдено. То есть вставляем в инпут подключение наших js скриптиков, если это форма поиска - делимся с "другом" и забираем его сессию. Ну или еще какие забавные штуки можно делать. А ведь все очень просто решается. Ставим какую-то функцию, которая по умолчанию будет фильтровать XSS инъекции при выводе, и не будет этого делать только если мы попросим. Если писать просто на php - появляются отвратные функции, которые можно просто забыть вызвать. А с шаблонизаторами мы пишем красивые {{ someUserInput }} и можем спать спокойно.

Помогают соблюдать принцип DRY. Современные средства шаблонизации (twig например), предоставляют вам возможность разделять шаблоны на блоки, переиспользовать их несколько раз, выделять макросы, наследовать шаблоны... словом все что угодно. лишь бы вы могли реюзать куски html а не копипастить их.

Ограничивают полет фантазии разработчика. Далеко не новость что разработчики ленивые засранцы. Особенно молодые. Если им в шаблоне внезапно понадобились какие-то данные из БД, или данные связанные с запросом, большинство не будет париться и зафигачит нужный код прямо в темплейте. Так же некоторые грешат тем что часть бизнес логики размазывают по шаблонам. Так же встречал проекты отданные на суппорт, где чуваки в шаблонах разбирали через xpath ответы от сторонней апишки (которая использовалась вместо базы данных. То есть это дело было размазано по всему проекту). Рефакторинг в случае изменения апишки будет болью.

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

С другой стороны, тот же twig позволяет в рамках проекта расширять синтаксис шаблонизатора, писать экстеншены, словом делать очень много забавных и нужных вещей, позволяющих сократить время поддержки шаблонов в будущем.

Так как за все эти приятные вещи мы по сути ничего не платим (шаблонизатор должен компилировать все это в нативный php так что оверхэда просто не будет), почему бы не пользоваться?

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

$("#id") - это всего лишь вызов jQuery как функции с передачей аргументов.
$.method() - это вызов метода у jQuery-объекта
$.prop - ну а это, чтение свойства и jQuery-объекта

Объясняю:

1) Небольшая фирма, небольшой проект, никогда не сможет конкурировать за "рабочие руки" с такими гигантами, как mail.ru/yandex/сбертех/альфа-лаборатория и прочие. А значит разрабатывать проект на Java, который еще не приносит деньги - глупейшая ошибка менеджмента. Ибо вы просто не найдете руки, либо они будут стоить очень много. По этой же причине не стоит выбирать для проектов .net (хотя там в общем ситуация в плане рук получше).

2) Выбирать для проекта, который еще не приносит денег, что-то типа python/ruby - глупо. Ибо найти хороших программистов на этот язык сложно (и они будут стоять больших денег).

Ну тут стоит понимать, что это реалии рынки СНГ и Европы. Исторически сложилось, что язык для новичков в СНГ и Европе был PHP (поэтому так много проектов на php), в США - это Ruby(Python), а, например, в Австралии - это Python.

В итоге: небольшие капиталисты в СНГ(Европе) - выбирают php, это дает много работы на PHP, предложение толкает людей учить PHP, что уже в свою очередь толкает создателей PHP его улучшать.

__

Нужно понимать, что PHP де-факто дешевый язык для старта бизнеса (конечно, есть условный symfony, где программисты получают на уровне Java-разработчиков, но это уже нюансы). А бизнес всегда стартаует, и всегда на это идет большой спрос.

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

__

Количество вакансий уменьшается по простой причине. Готовые облачные решения типа (shopify/wix) + возможность заменить на старте сайт на социальную сеть, дают снижение спроса.

php никогда не умрет. а тенденция такая говорит о том что как раз таки php разработчиков очень много и они позанимали рынок поэтому и вакансий меньше

Почему PHP теряет популярность?

Вам кажется.

Просто ИТ-проекты растут и развиваются.
Усложняются.
То, с чем мы имеем дело сегодня - несколько более сложные вещи, чем то, что делали средние программисты лет 10 назад.
Это вечный процесс.

И некоторые проекты используют другие технологии.

Не ожидает ли php участь ruby?

Ruby как был нишевым так и остался.
PHP - слишком массовый.

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

Даже если и PHP сойдет на нет - это дело долгих десятилетий, ибо:

1. Слишком уж много уже существующих проектов. Их тоже нужно поддерживать.
   
2. Выбор языка - это еще и выбор доступных исполнителей на рынке труда. В одночасье миллионы программистов не сменят специализацию.
   

не ожидает

все относительно, WP по-прежнему при делах, тем более на фрилансе

а вот в остальном: все смещается в "умный фронтенд" и "быстрый (читай - асинхронный) бекенд"

ну и где тут PHP ? на бекенде Го и Питона с Нодой потеснит, да и Джаву с ее аппетитами

зарабатывать хотя бы 20 000 рублей в месяц

Реально, но через год-два в нише "вёрстка+создание сайтов на cms" это будет +/- потолок для фрилансера (без опыта в N лет, портфолио на 30 лучших работ и 100+ отзывов). Слишком возросла конкуренция, слишком упали расценки на данный труд.

Просто если цель этого всего - 20к руб./мес., то смысл тратить 2 года на выжигание глаз кодом? Гуманитарная вышка есть, любая неспециализированная офисная работа подойдет. Зарплата, скорее всего, будет больше (тыщ 25-30), но никаких кидков, толп конкурентов, гонки за копеечными заказами, дедлайнов, ночных переработок, фрилансерского ноулайфа и пр. А главное - стабильность, знаешь, что 15 числа, допустим, сумма придет на карту, и нет головной боли на тему "чем питаться завтра, если нет заказов". Да и без образования и вне офиса эти 20к можно хоть администратором, хоть в колл-центре зарабатывать спокойно.

Если цель - связать жизнь с разработкой, то советую сразу смотреть в другие ниши мимо "вёрстки + WP".

Для обращения к svg через xlink:href нужен HTTP, локально не работает. Если только не встраивать svg инлайново. Другими словами, вам нужен сервер.