Дмитрий Волков

это Payment api
https://www.w3.org/TR/payment-request/

Отвечает за те зависимости, которые необходимы только для dev-окружения.
К примеру, Вы точно знаете, что библиотека phpunit нужна для разработки, а на проде будет лишней, тогда phpunit попадает в require-dev.
Когда выполняется простой

composer install

устанавливаются и dev-зависимости.
Когда выполняется

composer install --no-dev

устанавливаются только те зависимости, что в основном блоке require.

Источник

Как на этом сайте?
seolead.pro

seolead.pro/wp-content/themes/seolead/js/pollyfill.js сам скрипт.

<div id="introR" class="super_back"><canvas id="pollyfill-canvas"></canvas></div>

блок для вывода.

Работать малой командой это счастье. Когда все работают :) и есть результат.

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

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

Далее тезисно, не в порядке приоритетов, а как вспоминается:

0) Нужна специализация у каждого и у команды (пишу как видится с учетом размера вашей команды).
* тим лидер или старший разработчик. Он будет задавать стандарты качества и контролировать работу. Будет отвечать за архитектуру.
* разработчик-верстальщик
* разработчик-админ
* разработчик-базовик
* манагер и если людей мало, он же продажник. Должен знать все CMS, что вы будете применять. Чтобы мог без запинки показать клиенту, как создавать публикацию, редактировать и проч.

1) 80% времени работать над коммерческими проектам и 20% времени работать над своим проектом. Для повышения квалификации как минимум. А если выстрелит - то скоро вообще не надо будет работать с клиентами :) Когда нет заказов - все работают над "своим" проектом, повышают квалификацию, применяют и тестируют новые технологии или новые нагрузки. Если вы грамотно придумаете для себя задачу, то процесс работы над ней и результаты можно использовать для продвижения своей команды. Допустим вы взялись за разработку модуля обмена данными бухгалтерия-магазин. Посмотрите какие есть решения уже на рынке для вашей CMS. Сделайте удобнее и лучше или быстрее или тупо лучше документированное решение. Это позволит встать в "магазин" модулей для CMS и вам даст новых клиентов. Когда у вас есть узкое и качественное решение вашему продажнику проще будет разговаривать с клиентом и влезать в уже существующие айтишные инфраструктуры. Переделать онлайн магазин вам никто уже не даст, а вот заменить модуль на ваш смогут.

2) Технология производства. Особенно, если работает несколько человек. У вас должны быть единые стандарты и технологии для написания, документирования, работы с изменениями кода, своя "библиотека" решений, которые вы могли бы использовать как можно чаще. Создавать свои чеклисты для производственных этапов и по возможности автоматизировать рутинные операции.

3) Если речь идет о вебразработке, то скорее всего надо будет отлично знать до трех из самых популярных CMS. Желательно получить сертификат/статус.

4) Стандарты работы с клиентским проектом нужны. ТЗ, документация, обучение клиента и проч. Чтобы минимизировать трудозатраты или хотя бы минимизировать неоплачиваемые трузозатраты.

5) Знать английский язык на уровне чтения документации минимум.

6) и ... потихоньку добавлять себе новые направления. Уходить от чистого веба в веб+моб, или от "сайтов" в сложный е-коммерс. Идеально, когда клиентом меньше, а доходы больше. Для этого нужны глубокие знания в относительно узком направлении и два-три клиента серьезных клиента. Не старайтесь лепить много дешевых сайтов.

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

Это так, тезисно.

1. Выделяете джуниору куратора, даете джуниору не слишком сложные задания.

2. Куратору вменить в обязанность помогать (отвечать на вопросы, ориентировать в правильном направлении, но не делать вместо). Джуниора тоже поставить в извесность, что вопросы и неясности - сразу к куратору.

3 Минимум раз в день, по возможности 2-3 раза в день, куратор должен сам проверять что наделал пациент и если тот лезет не туда, направить верным путем.

Когда-то начинали с товарищем делать сайтики, только я был "программистом", а он собирал заказы. Одни из ошибок, которые позволили загнуться нашему совместному предприятию (просуществовали мы почти 2 года) - это:
- недостаточно опытный программист (это я), плюс, если брали помощников, то они были еще неопытнее меня.
- не составлялся четкий план на разработку, проектирование проекта не проводилось, из-за чего по ходу дела возникали ситуации, которые можно было решить еще на этапе проектирования, но нет, приходилось тратить время уже во-время разработки. Как следствие этого - неожиданное увеличение сроков.
- не было четких условий для заказчика, т.е. типовой договор был, но, например стоимость правок оговаривалась налету, некоторые заказчики округляли глаза и приходилось делать забеслпатно. Следствие чего заказчик был царь и бог и некоторые их долги по оплате не были отданы до сих пор.
- желание сэкономить, нет, я понимаю, что экономить нужно, но не на том, что приносит тебе доход, по-этому дизайнеры были хреновые, помощники говеные и т.д. Из-за чего заказчик был не доволен, а срок разработки проекта очень сильно увеличивался.
- заказы по сложности и требованиям несопоставимые со стоимостью, т.е. напарник брал сложные заказы за смешные деньги, сетуя на то, что город маленький (300 000 жителей) и никто платить не хочет, в итоге с созданием и доработками выплаты задерживались, следующие заказы брались , пока недоделаны предыдущие и получался ком, которые ничего хорошего не обещал.
- ну и результатом всего этого стало огромное количество долгов и плохих отзывов.
Ну вот такие были проблемы у студии "Рога и копыта" из двух человек, какие вспомнил ))
*пы.сы. не знаю, зачем это написал, просто, что-то вспомнилось.

но код, особенно после C++, не вызывает каких-то положительных эмоций.

А у меня не вызывает положительных эмоций код на C++. Да и код разный бывает. 90% кода на PHP у меня так же не вызывают положительных эмоций, но писать на нем нормально более чем можно.

1) под фразой "php умирает" позразумевает его модель работы. После каждого запроса он умирает, то есть воркер отчищается и запускается по сути заного. Это существенно упрощает работу (у вас хоть сегфлоты могут быть всеравно весь сервак не умрет), а так же масштабирование (за счет отсутствия у самого PHP состояния между запросами, сессии мы не берем в расчет), но существенно бьет по производительности. К счастью с PHP 5.3 писать демоны на PHP не так уж страшно.

Если же посмотреть рынок и динамику развития сообщества - PHP живее всех живых.

2) PHP не такой уж стремный язык. Я не считаю "не консистентные названия функций" таким уж прям фактором влияющим на выбор языка. С моей точки зрения Ruby уродливая отрыжка, попытка сделать объектно-ориентированный перл (это лично мое мнение, мне не приятно работать с ruby, пусть меня за это простят), но за счет того, насколько сообщество ruby-разработчиков ценит и понимает цели бизнеса, насколько уважает тестирование своих решений и т.д... словом PHP комьюнити в этом плане еще расти и расти. Но прогресс виден.

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

3) нет. Шансов на нормальном уровне с нуля изучить еще один язык программирования и к тому же фреймворк - почти нет. Да и в этом нет смысла.

4) судя по вопросу вы уже определились для себя. Дальнейшая дискуссия не имеет смысла. Разбирайтесь. Но если брать шаред хостинги то PHP это пожалуй единственный адекватный вариант на сегодняшний день (если не брать в расчет что шаред хостинги как таковые это не очень адекватный вариант).

5) все зависит от вас. Хорошие разработчики зарабатывают примерно одинаково вне зависимости на каком языке программирования они работают. Они просто хорошие разработчики и таких всегда мало.

6) как хотите.

И так...

Язык программирования - это лишь инструмент для решения задач. Фреймворки - это так же просто инструменты для решения задач. Что важно - уметь задачи решать. И решать эффективно. Понимать что кривыми решениями вы увеличиваете риски для бизнеса.

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

Ruby например бизнес (и стартапы в особенности) выбирает не потому что это хороший язык, а потому что Ruby комьюнити в среднем больше приспособлено для эффективного решения задач бизнеса. Что говорить когда у них любовь тестирования прививают с первых дней знакомства с языком?

Не учите язык программирования. Учитесь разработке с применением этого языка. И тогда все будет намного проще.

p.s. Haters gonna hate

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

За работу. Если грузчику платят за то, что он загружает фуры, почасовая оплата, то зачем ему платить когда он таскает мешки и возвращается за мешком на легке, ведь он не работает?
Код нельзя написать хорошо никогда. Можно стремится только к этому. Пока он разбирается это процесс разработки продукта. Почитайте книгу о циклах разработки ПО и все поймете

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

читайте как font-size/line-height

Использование фигурных скобок позволяет применять обращение к идентификатору с вариативным именем.

Простой пример:

$name = 'value';
$value = 'test'; 
echo ${$name}; // выведет test

Также можно обращаться к свойствам объекта:

$name = 'propertyName';
echo $object->{$name};