MB
Я лучше спеку/схему напишу, которая коерсить будет правильно это все с json, чем писать свой велосипед)
Size: a a a
2021 March 31
DL
но это вторично, основная идея - автоматизировать создание тестов для отладки
SK
Можно ещё поднять через https://github.com/nrepl/drawbridge по http даже с авторизацией
Хм.. идея, конечно, интересная, особенно, если к серваку нет доступа "от слова совсем", даже по SSH, но оверхед на серверную часть под http явно какой-то будет (хотя, может и не такой большой).
SK
1. не всегда просто воссоздать стейт, чтоб повторить баг
2. Чтоб выкатить фикс, надо узнать версию апки задеплоеной, сделать тикет, пр, собрать апрувы (если это средина ночи – сложно), дождаться билда, возможно согласовать даунтайм, найти человека с пермтшенами деплоя и тд. В случае с реплом можно пофиксить и сделать уже не горящий пр.
2. Чтоб выкатить фикс, надо узнать версию апки задеплоеной, сделать тикет, пр, собрать апрувы (если это средина ночи – сложно), дождаться билда, возможно согласовать даунтайм, найти человека с пермтшенами деплоя и тд. В случае с реплом можно пофиксить и сделать уже не горящий пр.
Согласен. Это 100500 организационных сложностей, особенно на больших проектах с распределенными обязанностями и доступами к разным его частым, в команде, или, того хуже - если команды разнесены: разрабатывает бэк - одна команда, деплоит - другая, саппортит - третья.
ST
я услышал много пространных рассуждений, но мне было бы интересней и достаточно услышать отзывы людей, у которых имеется репл в продакшене и они этим регулярно пользуются
SK
Стандартизируешь вид логов, пишешь код на чистых функциях – и все нормально работает
Тут, для максимального покрытия кейсов, наверное, нужно реализовывать что-то типа механизма WAL в СУБД, когда для того, чтобы получить state конкретного элемента данных, нужно прогнать все изменившие этот элемент edn/json, которые поступили в систему. То есть, там одной записью в лог может оказаться не обойтись (хотя, по-правде, никто не говорил об "одной записи").
OR
я услышал много пространных рассуждений, но мне было бы интересней и достаточно услышать отзывы людей, у которых имеется репл в продакшене и они этим регулярно пользуются
Я только от Sean Corfield слышал, что у них в продакшне сокет-репл.
SK
но это вторично, основная идея - автоматизировать создание тестов для отладки
Возможно, проще писать в какой-нибудь timeseries-db поток запросов к бэку, со всеми атрибутами, чтобы потом организовать возможность эти запросы, как макрос в Экселе, "проиграть" и получить нужный стэйт конкретного элемента. Но, вот, есть ли такой middleware, чтобы сразу прямо готовый - даже не знаю... Мне, как кажется, он неизвестен.
ST
РЕПЛ в продакшене
Анонимный опрос
Проголосовало: 34SK
я услышал много пространных рассуждений, но мне было бы интересней и достаточно услышать отзывы людей, у которых имеется репл в продакшене и они этим регулярно пользуются
Тут, скорее, вопрос юзабельности фичи не совпадает с вопросом привычки к ее использованию. Возможно, что удобно было бы её юзать многим, но так как нужно не особо часто - то и не запаривается народ ее развертыванием. Но если бы изначально она была в системе - что-то, возможно, решилось бы проще и быстрее при багфиксе или при отладке.
SK
РЕПЛ в продакшене
Анонимный опрос
Проголосовало: 34Нужно еще добавить: "Планирую использовать" 😉
ST
Нужно еще добавить: "Планирую использовать" 😉
Не включен, но иногда хотелось бы 😊
SK
А вот я ждал такого возражения... 😉
Не, не совсем то. "Не включен, но иногда хотелось бы" - это "хочу, но заведу ли - фиг его знает". А мой вариант - это "точно заведу, уже решил".
Не, не совсем то. "Не включен, но иногда хотелось бы" - это "хочу, но заведу ли - фиг его знает". А мой вариант - это "точно заведу, уже решил".
ST
Тут, скорее, вопрос юзабельности фичи не совпадает с вопросом привычки к ее использованию. Возможно, что удобно было бы её юзать многим, но так как нужно не особо часто - то и не запаривается народ ее развертыванием. Но если бы изначально она была в системе - что-то, возможно, решилось бы проще и быстрее при багфиксе или при отладке.
тут ещё на самом деле вопрос с секьюрности данного отверстия
сделаешь что-нибудь не так, будет дополнительная дыра в системе
сделаешь что-нибудь не так, будет дополнительная дыра в системе
SK
тут ещё на самом деле вопрос с секьюрности данного отверстия
сделаешь что-нибудь не так, будет дополнительная дыра в системе
сделаешь что-нибудь не так, будет дополнительная дыра в системе
Кстати да, +100500. Поэтому если делать - то биндить строго на localhost и потом ходить по SSH. Именно поэтому ring-версия nrepl, о которой упоминали чуть выше, меня как-то смутила.
ST
А вот я ждал такого возражения... 😉
Не, не совсем то. "Не включен, но иногда хотелось бы" - это "хочу, но заведу ли - фиг его знает". А мой вариант - это "точно заведу, уже решил".
Не, не совсем то. "Не включен, но иногда хотелось бы" - это "хочу, но заведу ли - фиг его знает". А мой вариант - это "точно заведу, уже решил".
Значит отвечай на будущее, первый или второй пункт
что нам твой вариант даёт для анализа?
что нам твой вариант даёт для анализа?
SK
По сути - распределение по группам лишь чуть точнее, не более того.
Т.е. добавление моего варианта принципиально картину ответов не меняет.
Т.е. добавление моего варианта принципиально картину ответов не меняет.
SK
50/50 получается по результатам.
ST
50/50 получается по результатам.
я вижу только 20% используют
ST
полагаю, что мне репл в продакшене не нужен потому, что я могу всегда запустить приложение локально в идентичной продакшену конфигурации, и спокойно изучить проблему на месте