A
Вроде даже eslint советует не вызывать явно прототипные методы
Size: a a a
2020 June 11
MV
Вроде даже eslint советует не вызывать явно прототипные методы
Зависит от типа вызова, например hasOwnProperty советуется вызывать относительно прототипа обджект
A
Ну тогда на таких штуках сменить дескрипторы))) Тупая ситуация, угрюмые решения)
Ага😄
A
Зависит от типа вызова, например hasOwnProperty советуется вызывать относительно прототипа обджект
Возможно так
t
Посоветуйте, пожалуйста, аналог Hazelcast для Node.js или что-нибудь подходящее для реализации in-memory кэша в распределённой системе
М
Кроме stripe, что можно для СНГ использовать?
А что, в снг есть единая форма оплаты?
A
Зависит от типа вызова, например hasOwnProperty советуется вызывать относительно прототипа обджект
А вот да я про это и слышал
A
Eslint ругается на прямой вызов hasOwnproperty
A
Хочет Object.prototype
A
Зависит от типа вызова, например hasOwnProperty советуется вызывать относительно прототипа обджект
Ошибся, имел ввиду наоборот
u
Доброе утро, когда хочу получить IP клиента через express-ip на сервере он показывает IP localhost-a. Примерно понимаю из-за чего это происходит, подскажите в какую сторону нужно копать?
Если твой nodejs-сервер за nginx, apache в качестве reverse proxy, то в request.ip будет localhost.
Обычно в таких случаях реальный ip передается в заголовках X-Real-Ip, X-Forwarded-For
Чтобы в express получить реальный ip, то либо получаешь его прямиком из заголовка, либо в настройках express можно указать явно, что твой сервер в качестве proxy, и тогда автоматически ip из заголовка попадет в request.ip
Обычно в таких случаях реальный ip передается в заголовках X-Real-Ip, X-Forwarded-For
Чтобы в express получить реальный ip, то либо получаешь его прямиком из заголовка, либо в настройках express можно указать явно, что твой сервер в качестве proxy, и тогда автоматически ip из заголовка попадет в request.ip
И
А что, в снг есть единая форма оплаты?
Всякие кассы
И
Вариантов много
Есть ещё СБП, но там чёт не оч
Есть ещё СБП, но там чёт не оч
A
Привет всем! Делаем вебсервис (React, React Diagrams, Typescript, React Bootstrap, NodeJS, Mongodb). Столкнулись с тем, что когда добавляем новый функционал, может "сломаться" старый, который (в свою очередь) - может быть критичным.
Пример: в сервисе пользователь может создавать диаграммы. Другой пользователь может просматривать эти диаграммы (но не может редактировать). Недавно (после добавления очередного функионала) - это ограничение слетело). Хотелось бы этого избежать в будущем.
Понимаю, что стоит реализовать периодическое тестирование критичного функционала после обновлений. Хотелось бы автоматизировать этот процесс. Как порекомендуете это реализовать в рамках вебсервиса? Насколько понимаю, здесь нужно использовать что-то вроде Selenium?
С другой стороны, есть подозрение, , что уйдут очень серьезные ресурсы на написание интеграционных тестов. Причем с большой долей вероятности их придется постоянно переписывать, так как расположение кнопок, наличие каких-то элементов или еще что-то может часто меняться.
Как порекомендуете поступить?
Пример: в сервисе пользователь может создавать диаграммы. Другой пользователь может просматривать эти диаграммы (но не может редактировать). Недавно (после добавления очередного функионала) - это ограничение слетело). Хотелось бы этого избежать в будущем.
Понимаю, что стоит реализовать периодическое тестирование критичного функционала после обновлений. Хотелось бы автоматизировать этот процесс. Как порекомендуете это реализовать в рамках вебсервиса? Насколько понимаю, здесь нужно использовать что-то вроде Selenium?
С другой стороны, есть подозрение, , что уйдут очень серьезные ресурсы на написание интеграционных тестов. Причем с большой долей вероятности их придется постоянно переписывать, так как расположение кнопок, наличие каких-то элементов или еще что-то может часто меняться.
Как порекомендуете поступить?
KF
бить себя по рукам, когда хочется писать спагети код, вместо нормальной архитектуры
KF
а с норм архитектурой юнит тесты можно будет использвать, это дешевле интеграционных
K
Друзья, ошибка в том что когда пишу я (админ) всё ок, а когда другой юзер, не важно что то -
Всем привет, еще раз, поможете ?)
k
Привет всем! Делаем вебсервис (React, React Diagrams, Typescript, React Bootstrap, NodeJS, Mongodb). Столкнулись с тем, что когда добавляем новый функционал, может "сломаться" старый, который (в свою очередь) - может быть критичным.
Пример: в сервисе пользователь может создавать диаграммы. Другой пользователь может просматривать эти диаграммы (но не может редактировать). Недавно (после добавления очередного функионала) - это ограничение слетело). Хотелось бы этого избежать в будущем.
Понимаю, что стоит реализовать периодическое тестирование критичного функционала после обновлений. Хотелось бы автоматизировать этот процесс. Как порекомендуете это реализовать в рамках вебсервиса? Насколько понимаю, здесь нужно использовать что-то вроде Selenium?
С другой стороны, есть подозрение, , что уйдут очень серьезные ресурсы на написание интеграционных тестов. Причем с большой долей вероятности их придется постоянно переписывать, так как расположение кнопок, наличие каких-то элементов или еще что-то может часто меняться.
Как порекомендуете поступить?
Пример: в сервисе пользователь может создавать диаграммы. Другой пользователь может просматривать эти диаграммы (но не может редактировать). Недавно (после добавления очередного функионала) - это ограничение слетело). Хотелось бы этого избежать в будущем.
Понимаю, что стоит реализовать периодическое тестирование критичного функционала после обновлений. Хотелось бы автоматизировать этот процесс. Как порекомендуете это реализовать в рамках вебсервиса? Насколько понимаю, здесь нужно использовать что-то вроде Selenium?
С другой стороны, есть подозрение, , что уйдут очень серьезные ресурсы на написание интеграционных тестов. Причем с большой долей вероятности их придется постоянно переписывать, так как расположение кнопок, наличие каких-то элементов или еще что-то может часто меняться.
Как порекомендуете поступить?
создание/редактирование диаграмм - это скорее юнит тесты. причем, в первую очередь, на бек
и да, юнит тесты на бек должны быть отдельно от фронта и должны покрывать весь функционал. ну и нормальная архитектура должна обеспечивать независимость блоков/модулей друг от друга
и да, юнит тесты на бек должны быть отдельно от фронта и должны покрывать весь функционал. ну и нормальная архитектура должна обеспечивать независимость блоков/модулей друг от друга
АП
Всем привет, еще раз, поможете ?)
Этого скрина недостаточно для помощи
K
Этого скрина недостаточно для помощи
Код? Весь?