hOtRush

Поймать за амбаром и набить морду!

Я себе делал статический сайт через Jekyll. Нужна была мультиязычность и ещё чуток динамики. Если это не нужно, то, как говорили выше, HTML, CSS, JS самый простой вариант.

Довольно просто, хорошо знать - значит знать ЧТО гуглить, чтобы решить проблему. Учить его - да что за дичь? он устареет через год, потом будет еще стопицот других, еще моднее.

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

Vue.js

mailgun/mandrill

djangogirls

Мышь, клавиатура и чашка кофе.

Продавать себя за 20$ в час

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)

Amazon S3?

php.net/manual
Там порой очень хорошие комментарии оставляют.

Я в своё время начинал с "PHP5 в подлиннике" Дмитрия Котерова.

Я пользуюсь dockerUI
https://registry.hub.docker.com/u/dockerui/dockerui/

Запустить можно сразу как контейнер
docker run -d -p 9000:9000 --privileged -v /var/run/docker.sock:/var/run/docker.sock dockerui/dockerui

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

Я пока не пользуюсь, но вам должен понравиться Rancher. Умеет overlay сеть поднимать и линковать даже контейнеры на разных серверах.
К тому же есть балансировщик нагрузки и прочие удобности, Open Source.
Контейнеры будет видно только те, которые через UI запускались, тут ничего не поделать.

Написал довольно много различных парсеров и автоматизаций веб разной сложности, и могу сказать, что единственный вариант - это не публиковать информацию вообще. Думаю следующее поможет отбить желание парсить сайт или как минимум повысит стоимость разработки\поддержки парсера:
1. Система мониторинга поведения пользователя (движение мышки, координаты нажатия на кнопки и т.п.) для того чтобы вычислять ботов.
2. Не использовать Id и name или другие атрибуты, по которым можно вычислить контент.
3. Обфусцировать СSS и делать имена классов динамическими.
4. Динамически добавлять различный мусор в разметку.
5. Использовать веб-фреймворк, и не светить методы наружу.
6. Использовать капчу, от разных вендоров и с динамически генерируемым url, причём загружать её так, чтобы её нельзя было вытащить из кэша браузера (от перехвата запроса это не спасёт, но жизнь автоматизаторам подпортит).
7. Переодически менять вёрстку.

Загружать контент через Ajax я бы не рекомендовал: перехватить реквест от браузера не такая уж большая проблема, зато сразу сужается область поиска контента.

Каждый проект = свой репозиторий = свой пользователь = свой ключ. Это касательно хуков, а если от них отойти, то что вам мешает деплоить на свой сервер напрямую, без хуков?