Обновить
6
Маргарита Лукина@devmargooo

Frontend developer

1
Подписчики
Отправить сообщение
Очень спорная с точки зрения современного бодибилдинга статья.

Спорт не приводит к сбросу веса. Точка.


Чтобы сбросить вес, нужно создать дефицит калорий, т.е. количество потребляемых калорий должно быть меньше количества затраченных. Спорт помогает увеличить количество затраченных калорий, увеличивая ежедневный дефицит. Кроме того, спорт помогает нарастить мышцы, а мышечная ткань потребляет больше калорий, чем жировая. Проще говоря, если взять двух людей одинаковой массы, но при этом один будет мускулистый, а второй нет, то у первого ежденевная норма калорий будет выше, чем у второго. Второй может есть 1000 ккал ежедневно и не создать таким образом дефицит, а первый может потреблять 1500 ккал в день и для него это будет дефицит.

Главный враг — голод, за которым всегда приходит его брат — жор. Снижение калорийности пищи закономерно запускает механизмы ломки. Наша основная задача — максимально сгладить нежелательные эффекты. Никто не любит страдать. А страдать 3 года не может никто. Если твой новый образ жизни доставляет тебе страдания, то срыв неизбежен.


И ниже автор пишет, что организм очень адаптивен ))) На самом деле, если человек и будет страдать на дефиците калорий от чувства голода, то только первые 2-3 недели, а потом организм чудесным образом адаптируется и чувства голода уже не будет.

Итак, запомним: жирное — полезно для похудения. Обезжиренное и сладкое — вредно.


Обезжиренные продукты НЕ вредны для похудения.

Загрузочный день — вообще крайне спорная рекомендация. Мне кажется, нужно иметь очень здоровый ЖКТ, чтобы после условных 1500 ккал он смог адаптироваться под 2500 — 3000 ккал.
Есть куча кейсов, когда тоггл отвечает за состояние UI, а не за бизнес-логику. Например, он закрывает/открывает какую-нибудь плашку. Или попап. Или тему с темной на светлую переключает (и хотя тему, скорее всего, мы не будем хранить в текущем компоненте, но все равно это пример UI данных, а не бизнес-данных). Именно об этом мой комментарий — не все данные есть бизнес-данные, во фронте есть куча UI данных.
Первый критерий (частота изменения данных) выглядит очень сомнительным )) Допустим, есть где-нибудь какой-нибудь тоггл на странице, который пользователи тыкают один раз в пятьсот лет — что теперь, хранить его состояние в сторе? Куда более разумным кажется разделение по архитектурному слою. Например, данные пользователя — это слой бизнес-логики, и такие данные должны находиться в сторе (даже если они часто изменяются), а состояния UI компонентов — это UI слой и такие данные должны быть в стейте компонента.
О хакатоне, очевидно ))
Я не имею никакого отношения к организации «Цифрового прорыва». Я просто участник, который рассказал о своем первом опыте хакатона.
2

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирована
Активность