на один банк - да
но я машину по карте у физлица покупал больше,чем за 1млн, без проблем (ни одну сторону никто не спрашивал ни о чем)

В прошлом году пробовал несколько и больше всего мне зашло приложение Streaks. Но iOS + Mac only

Погуглите habitica

Пожалуй самый лучшая имплементация гемификации, касательна привычек 👍

Это очень круто)

@scatmanoleg спасибо, вообще вкатило :)
Мой тайный Санта молодец :)

Круто! А я в боте забыл написать подтверждение и выбыл 😄

☺️

круто!

о, у меня как раз есть вопрос на тему уникальной культуры нетфликс. пишут, что они перешли на nosql отчасти именно из-за того, что не надо заморачиваться с изменениями схемы бд. а есть какие-то готовые решения для отката изменений для тех, кто все ещё кипятит, то есть сидит в rdbms?

хочу в 2021 развивать у себя в компании тему с отказоустойчивостью, в том числе откатов деплойментов. но не понимаю пока даже концептуального решения для этого: либо при откате теряются пользовательские данные, либо запускаются скрипты отката на предыдущую версию схемы, которые по сути могут так же с легкостью крэшнуться

А та же монга как будет сортировать по полям без создания индексов? И чем это в итоге отличается от определения схемы?

если это ко мне встречный вопрос, то я не знаю, в монгах не разбираюсь)

но хотелось бы узнать про старые-добрые сиквелы

Мы реализуем это примерно так:
1) В коде вместе с остальным MR-м хранятся миграции наката/отката. Сами миграции накатываем стандартными для языка/фреймворка способом. Видел команды/компании где использует отдельный мигратор.
2) Эти миграции тестируются в CI в рамках тестов
3) Эти миграции не 1 раз тестируются командой QA в рамках выкатов на RC stage
4) Если есть сложные кейсы, с возможной потеряй данных и т.д. То обычно используем многоступенчатый выкат (кратко - создали новую колонку, залили данными, приложение пишет параллельно в обе, читает из старой, потом переключаем на новую колонку, потом дропаем старую)

Все это не избавляет нас от случаев что что-то может пойти не так (особенно если это миграции на каких-то больших таблицах) и иногда приходится все стопать и руками что-то докручивать (тьфу-тьфу, давно так не делали)

самое интересное - с миграциями отката, конечно. насколько они тестируются в рамках CI и QA? если тщательно, то вы как-то оптимизируете стоимость ручного тестирования и поддержания автотестов?

Я бы не сказал что мы специально тестируем именно момент отката. Это происходит само собой - т.е. у нас есть 1 RC Stage, куда QA выкатывает новую фичу и в рамках нее схема меняется на новую. Когда QA выкатывает другую фичу, то предыдущая должна успешно откатиться и потом накатиться новая. И так несколько раз за день.

Ключ к успеху:  релиз новой версии схемы и релиз новой версии приложения это два разных релиза разделенных по времени. Кроме того, база какое-то время может находится в промежутном состоянии между релизами.

Правила простые, но требуют дисциплины.

Например, в релизе А добавляем колонку, а уже в релизе Б делаем ее NOT NULL.
Или если раньше писали в таблицу M, а в новой версии нужно писать в таблицу Z, то вначале выкатываем таблицу Z + on insert  триггер для М. Затем через какое-то время выкатываем приложение и деактивируем триггер.

Никогда ничего не удаляем в том же релизе где добавляем.

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

Почему без создания индексов? Нормально создаются индексы по любым полям в Монге.