jaxel

0 0 * * * rm /path/to/file
удалит файл в полночь (по времени сервера).

Я бы сделал так:
Таблица содержит 4 поля: user_id, day(Enum), from(int), to(int)
Пользователь создает по полю на каждый день недели, в котором может указать С и ДО какого часа он работает.

Т.е получится так:
user_id | day | from | to
1 | 1 | 10 | 12
1 | 2 | 9 | 16
2 | 1 | 8 | 15

Плюс в том, что можно создавать несколько строк, на каждый день недели:
user_id | day | from | to
1 | 1 | 10 | 12
1 | 1 | 14 | 20

Тем самым можно указать несколько интервалов.

Выборка простая:
select * from days where day = {current_day} and from >= {from_hour} and to <= {to_hour}

всегда

Хранить 2 значения:
1) A float - расстояние
2) B integer - степень 10

результат A * (10 ^B)
До Солнца (8; 0), до UDFj (13, 9)
float для точности

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

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

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

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

но код, особенно после 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

В дальнейшем клиент хочет чтобы на сайте функционировал интернет магазин.

Не нужно использовать Мегагрупп, Wix и прочие конструкторы ГС. Если клиент согласен с переходом на нормальную CMS, то делайте, в противном случае лучше отказаться.