к
Ну словами описать проще и понятнее будет, чем картинка на пол страницы в двумя прямоугольниками и одной стрелкой
я не соглашусь с этим
Size: a a a
2020 October 14
YS
Тоже не соглашусь
YS
Все объясняют с разной степенью понятности
YS
Слова позволяют одно и то же выразить очень разными способами
Oℕ
я не думаю, что диаграмма на таком уровне имеет пользу, обычно полезны интеракшон\секвенс диаграммы с большим количеством процессов и взаимодействий
Oℕ
ну а для таких мелких - это просто потому что привыкли к такому языку
R
Картинки универсально.
R
Выбирай, что будешь читать или смотреть. Или и то и другое.
к
кроме универсальности есть еще такая штука, что картинки запоминаются, и эта визуальная память может помочь в последующих главах
а вот текст ты или поймешь сразу, или не поймешь и забудешь
а вот текст ты или поймешь сразу, или не поймешь и забудешь
к
например картинки из теорката для программистов все еще в голове сидят
к
и свиньи какие-то в коробках с шариками, наверное из lyhfgg
R
Ну можно "сфоткать" в память, потом вспомнить. У кого фотографическая память.
R
Разное мышление
YR
в чем может быть мотивация отказываться от микросервисов и JSON респонсов от них и переписывать на монолит с server side templates rendering (HTML) ?
YS
ну, вероятно время получения странички
R
У Гриффитсов очень развит подход с эмоциональным обучением.
R
В их книжках
NI
Yuki Rito
в чем может быть мотивация отказываться от микросервисов и JSON респонсов от них и переписывать на монолит с server side templates rendering (HTML) ?
Удешевление разработки.
к
Yuki Rito
в чем может быть мотивация отказываться от микросервисов и JSON респонсов от них и переписывать на монолит с server side templates rendering (HTML) ?
например когда маленькое приложение, и микросервисы никакой выгоды не принесут
к
с фронтом все то же самое, посылка json означает, что это все таки два сервиса нужно писать и поддерживать, фронт и бэк, а с серверсайдом может быть проще