Ваши доводы (как и доводы Резига) об опечатках и иже с ними я не считаю серьёзными и сколько либо имеющими почву для обсуждения. Если пишете в блокноте код — продолжайте в том же духе. Жалуйтесь на опечатки и т.д. и т.п, придумывайте оправдания и костыли для того, что бы не писать качественный код, а подпирать его костылями.
Всё сказанное выше также относится и к забытому new. Но — здесь есть один момент. Чтобы не было сомнений нужен new или не нужен, просто функции-конструкторы нужно начинать с заглавной буквы (это считается хорошей практикой).
Таким образом, моё мнение сводится к тому, чтобы повышать качество кода, а не подпирать костылями говно-код, а тем более способствовать его написанию с помощью вот таких вот практик, типа автоматизированных конструкторов.
всем всегда рекомендую не использовать это слово перед конструкторами
И надо сказать — плохому учите. Мне всегда не нравилась эта практика защиты от мифического дурака.
Вообще эта тема может стать, если уже не стала, холиварной.
На мой взгляд, в опросе нет самого компромиссного варианта. «Полноценные завтраки/обеды/ужины/ с компенсацией» части стоимости компанией. Как у нас, например. Получается довольно экономно (200 рублей полный обед) и качественно. Таким образом и питание получается качественным и обжорства не допускает.
Заточено исключительно на node.js. К тому же нет большого смысла использовать этот инструмент для деплоя скриптов, которые не являются долгоживущими процессами (т.е. linux daemon`s или windows services).
Год назад я написал этот модуль, запостил статью на хабр. Теперь кто-то улучшил мой модуль, запостил статью, затем кто-то перевёл её и зпостил на Хабр. Круто.
Инсталляция зависимостей с помощью npm — это для меня счастье, поскольку некоторые пакеты требуют компиляции, а среда гетерогенная. Основная машина под Windows (development), сервера под различными Linux.
Аутентификация производится HTTP-протоколом (Basic-авторизация), поскольку сервер — это HTTP-сервер, а клиент, собственно — http.request. Знаю, что не секьюрно, в ближайшее время предоставлю выбор между HTTP и HTTPS.
Велосипед всегда удобнее, поскольку пишется под конкретные хотелки. С ними единственная проблема — сопровождение. Так что надо выкладывать на public и пусть борется за своё существование.
Не хотелось бы ввязываться в дебаты о нужности или ненужности того или иного инструмента. История сама ответит на Ваш вопрос. Но, хотел бы ещё раз подчеркнуть что моей целью было создание максимально простого в установке и обслуживании сервиса.
У меня есть несколько различных приложений, которые время от времени меняются и мне не хочется порождать возню с копированием файлов в то время, когда мне необходимо задеплоится и протестировать изменения, иногда на разные машины. Ещё у меня есть привычка деплоить сервисы из VS в пару щелчков мышки.
Ставить что-то серьёзное — это значит потратить время на изучение и настройку, проход по граблям, курение форумов, повторить это для каждого окружения (среда у меня достаточно гетерогенная). Я в принципе не против использования промышленных решений, там где возню с окружением оплачивает работодатель. Но в данном случае для меня это не приемлемо. Да ещё и VDS с 256M памяти не даёт разгуляться.
И да, конечно, я искал что-то подобное, но не нашёл. Рекомендуют либо готовые коммерческие сервисы или ручную возню с forever или более продвинутые системы (типа деплоя по git push), но на мой взгляд, причудливые.
Если Вы node.js разработчик и Вам нужно развернуть приложение на VDS, то скорее всего окружение Вы уже настроили. Значит node и npm стоят и готовы к работе. Остаётся выполнить одну команду для установки, которая знакома любому node.js разработчику; запустить сервис и забыть о нём. В теории, в идеально мире, Вы уже больше никогда на этот VDS не зайдёте, а будете деплоится одной командой из терминала. Очень удобно при горячем баг-фиксинге.
Надеюсь, что на прямой вопрос «зачем?» я ответил. А с полемикой о нужности… вон к дистрибутивам Linux… какого хна их столько?
А вообще, если в комментариях ещё что-нибудь предложат по требованиям, которые я изложил, в достаточном количестве, не поленюсь сделать обзор предложенных решений. Может и найдётся что-то… интересное.
Насчёт менять настройки. С самого начала я включил в основу express.js фреймфорк, хотя для решения данной задачи он там слишком излишен. Так что есть мысли по поводу создания web-интерфейса для управления.
Я написал в статье про установку зависимостей с помощью npm install. Если вы в package.json своего приложения пропишете инсталляционный скрипт, то npm выполнит его при установке. Пример можно найти в самом node-deploy-server. Он как раз использует эту технику, чтобы выполнить установку сервиса.
Всё сказанное выше также относится и к забытому new. Но — здесь есть один момент. Чтобы не было сомнений нужен new или не нужен, просто функции-конструкторы нужно начинать с заглавной буквы (это считается хорошей практикой).
Таким образом, моё мнение сводится к тому, чтобы повышать качество кода, а не подпирать костылями говно-код, а тем более способствовать его написанию с помощью вот таких вот практик, типа автоматизированных конструкторов.
И надо сказать — плохому учите. Мне всегда не нравилась эта практика защиты от мифического дурака.
Вообще эта тема может стать, если уже не стала, холиварной.
Аутентификация производится HTTP-протоколом (Basic-авторизация), поскольку сервер — это HTTP-сервер, а клиент, собственно — http.request. Знаю, что не секьюрно, в ближайшее время предоставлю выбор между HTTP и HTTPS.
У меня есть несколько различных приложений, которые время от времени меняются и мне не хочется порождать возню с копированием файлов в то время, когда мне необходимо задеплоится и протестировать изменения, иногда на разные машины. Ещё у меня есть привычка деплоить сервисы из VS в пару щелчков мышки.
Ставить что-то серьёзное — это значит потратить время на изучение и настройку, проход по граблям, курение форумов, повторить это для каждого окружения (среда у меня достаточно гетерогенная). Я в принципе не против использования промышленных решений, там где возню с окружением оплачивает работодатель. Но в данном случае для меня это не приемлемо. Да ещё и VDS с 256M памяти не даёт разгуляться.
И да, конечно, я искал что-то подобное, но не нашёл. Рекомендуют либо готовые коммерческие сервисы или ручную возню с forever или более продвинутые системы (типа деплоя по git push), но на мой взгляд, причудливые.
Если Вы node.js разработчик и Вам нужно развернуть приложение на VDS, то скорее всего окружение Вы уже настроили. Значит node и npm стоят и готовы к работе. Остаётся выполнить одну команду для установки, которая знакома любому node.js разработчику; запустить сервис и забыть о нём. В теории, в идеально мире, Вы уже больше никогда на этот VDS не зайдёте, а будете деплоится одной командой из терминала. Очень удобно при горячем баг-фиксинге.
Надеюсь, что на прямой вопрос «зачем?» я ответил. А с полемикой о нужности… вон к дистрибутивам Linux… какого хна их столько?
А вообще, если в комментариях ещё что-нибудь предложат по требованиям, которые я изложил, в достаточном количестве, не поленюсь сделать обзор предложенных решений. Может и найдётся что-то… интересное.
Конфигурационный файл (.deploy) один для каждого проекта и должен лежать рядом с package.json