Джавист Роман

Всем привет! Пятница - отличный повод почитать что-то полезное) С семантикой мы разобрались, давайте поговорим еще об одной интересной теме - Stateful / Stateless признаках в приложениях. В чем же интерес для нас? А вот у Stateless систем есть важное качество - их легко масштабировать горизонтально в отличее и от stateful систем, а это качество очень цениться в высоконагруженных системах. Stateful приложение хранит данные при работе внутри себя. Что это значит? Например это хранение данных по сессии пользователя внутри рантайма. Ответ на запрос пользователя зависит от состояния сессии, что хранится в конкретном инстансе приложения...

Всем привет! С семантикой мы разобрались, давайте поговорим еще об одной интересной теме - Stateful / Stateless признаках в приложениях. В чем же интерес для нас? А вот у Stateless систем есть важное качество - их легко масштабировать горизонтально в отличнее и от stateful систем, а это качество очень цениться в высоконагруженных системах. Поэтому приоткрою вам дверь по этой теме. Stateful приложение хранит данные при работе внутри себя.  Что это значит? Например это хранение данных по сессии пользователя внутри рантайма. Ответ на запрос пользователя зависит от состояния сессии, что хранится в конкретном инстансе приложения...

Прежде чем грузить теорией, хочется описать почему это важно. Ведь смысл потреблять информацию, если не знаешь зачем она тебе, правильно? Так вот, в распределенных системах сбои - это норма. Может сеть лагать, могут падать узлы, сообщения между системами могут теряться или дублироваться. И вот здесь без понимания четкой семантики невозможно построить надежную бизнес-логику. Какие могут быть моменты, например: Думаю мало кто будет спорить с тем, что будет так себе... Поэтому давайте поговорим о семантике доставки...

Всем привет, мои дорогие друзья. Поговорим сегодня о том, каким образом можно подойти к оценке трудозатрат по разработке ПО. У каждого в карьере наступает момент, во время которого придут и просят: "сколько будет стоить разработать эту функциональность?". И, разумеется, на такие вопросы уже давали ответы и знают какие есть способы. Рассмотрим несколько вариантов: Делаем оценку на основе уже решенных задач, аналогичных по масштабу, сложности и технологиям. Типичный подход - это подумать над тем, были ли задачи похожие в копилке решенных...

Давеча был разговор с бекендером, почему не стоит писать бизнес-логику в SQL запросах. Последние лет 5 для меня это аксиома, которую не нужно было повторять и я не сразу смог сформулировать емко. Посидел, подумал и решил, что лучше всего будет написать заметку на эту тему и потом возвращаться к ней каждый раз, поэтому сегодня поговорим с вами, почему же писать бизнес-логику идея плохая.. Но не всегда 😁 Добавление бизнес-логики непосредственно в SQL-запросы может выглядеть как удобный выход из положения, но в долгосрочной перспективе такой подход чреват множеством проблем...