Александр Дуплий

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

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

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

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

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

Книги, руководства:
php.net
PHP the right way
tutsplus
PHP. Объекты, шаблоны и методики программирования

Видео:
Laracasts
phpukconference
Laracon
Laracon EU

Подкасты (PHP и не только):
fullstackradio
laravelpodcast
looselycoupled
devdiscussions
Пятиминутка PHP

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

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

1. Как уже сказали выше - git или mercurial (на bitbucket, github или на своем сервере). С основного репозитория клонируем копии на локальные машины.
2. dev-среда:
2.1 dev-сервер с поддоменами для каждого разработчика
2.2 или локальный веб-сервер (у каждого свой)
2.3 обязательно - "предпродакшн" сервер - там будут производиться проверки перед деплоем на продакшн
3. Ставите каждому нормальную IDE, которая умеет работать с локальными файлами и деплоить изменения на сервер (PHPStorm).
4. Настраиваете IDE таким образом, чтобы вы работали с локальными файлами, и при этом при сохранении изменения автоматически отправлялись на ваш dev-сервер.
5. Юнит-тесты, функциональные тесты, чтобы перед деплоем на продакшн быть уверенным в том, что кто-то из разработчиков не сломал ваш проект своими изменениями.
6. Если есть изменения в БД - миграции
7. На продакшене также клонируетесь от основного репозитория (для удобства обновления кода)

Т.о. процесс разработки будет выглядеть так:
1. Разработчик pull`ит изменения из основного репозитория
2. Что-то меняет в коде, тестируя это на своем dev-сервере
3. После покрытия кода новыми тестами, прогоняет их и заливает изменения в основную ветку
4. На предпродакшене обновляемся с основной ветки. Прогоняем все тесты.
5. Если тесты прошли - на продакшене обновляемся на тот же коммит

Конкретно для не_фриланса, зп сотрудника зависит от прибыли прибыли компании только в двух случаях:
1) Если человек работает в какой-нибудь говноконторке, где начальство только и придумывает способы как бы наказать сотрудников и заставить их работать больше&дешевле.
2) Если человек работает в какой-нибудь стартапо-подобной компании, где он добровольно пахает не за стандартную зарплату, а за хрен-пойми-что (это не обязательно означает что-то исключительно плохое), зависящее от текущего состояния этой компании.
Во всех остальных случаях у специалиста имеются свои финансовые аппетиты, которые строятся на основе спроса/предложения на рынке труда, а так же его навыков, заслуг и известности/востребованности. И еще самооценки конечно же, с этим в российском IT, например, много проблем :)

1. НЕ ВЕЗДЕ сроки имеют место быть. Ищите работу где сроки не требуются. Таких мест полно. Это как правило долгоиграющие проекты принадлежащие бизнесу, а не говеные веб-студии, штампующие на заказ.

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

3. Приехал я как-то с поломкой машины к мастеру-частнику. Говорю - вот то то не работает. Сроки? А он мне отвечает - а я не могу сказать. Откуда я знаю что там сломалось?
Это я к тому, что даже такая в такой теме, как ремонт авто, где казалось бы все четко и все делается по наработанной схеме, сроки крайне не определены.

4. Если с вас требуют сроки, значит вы что-то делаете не так или работаете где-то не там. Про сроки можно говорит в строительстве, где укладка одной плитки СТАНДАРТНО занимает Н минут и вы должны полы покрыть 30х40 метров. Тогда сроки справедливы. В IT сроков не может быть. Т.е. не должен исполнитель думать о сроках. Это не его дело. Менеджмент должен дать время с запасом и не терзать исполнителя.

Есть проект, называется Fogbugz
www.fogcreek.com/fogbugz
В нем можно ставить задачи и указывать время их исполнения. Он собирает информацию и потом может выдавать предсказание о времени выполнения задачи.
По опыту могу вам посоветовать, если вам кажется, что задача займет пару часов, а заказчику скажите 4 или 6. В систему вводите свое собственное время. Через пару месяцев у вас появится некоторая картина вашей скорости.
На мой взгляд лучше срок немного увеличить, чем сделать не вовремя. Вообще это приходит с опытом, но все равно очень сложно оценивать время выполнения. Лично я стараюсь узнать о задаче максимум до начала ее выполнения или представления оценки заказчику.
Что еще можно сказать - не переживайте сильно по поводу оценки времени. Все ошибаются, даже специалисты с 10-20 летним стажем.
Есть еще немного другой подход - непрерывная разработка, в которой нужно ставить оценки времени, но необязательно их соблюдать. Т.е. оценку разработчик делает сам для себя. Что-то вроде личного мотиватора, не более того.