Я написал книгу и назвал ее "Электрообереги". Она рассказывает про те замечательные устройства в электрощитке, что спасают нас от погибели. Начиная от предохранителей, которые существуют более века, заканчивая новейшими устройствами защиты от дугового пробоя. (Включая АВ, АВДТ, ВДТ, УЗО, РН, УЗИП, СГД и т.д.) Рассказ построен так, чтобы даже блондинке стало ясно как эти устройства устроены и зачем они нужны. Кто давно на меня подписан подобные посты уже видел - книжка представляет собой собранные воедино и причесанные публикации за последние два года. Еще я перерисовал все сторонние иллюстрации и теперь книжка лицензионно чиста - ни один мерзкий копираст не подкопается.

А еще сегодня у меня день рождения. И это хороший повод сделать подарок миру - книжка публикуется под открытой лицензией CC BY-NC-SA, тоесть ее можно распространять совершенно свободно.

Всем привет! Меня зовут Евгений Прокопьев, я мобильный разработчик в СберМаркете. Более пяти лет я работаю с React Native и моя любовь — это красивые анимации. В этой статье я хочу рассказать, с помощью каких инструментов можно добиваться качественных анимаций на React Native. Начну с Animated и Reanimated, посмотрим, как они работают внутри. Затем расскажу, что можно делать с библиотеками SVG, Lotte, OpenGL и Skia. Поехали!

Первый раз встретил книгу, в которой автор так конкретно и настоятельно рассказывает про методы декомпозиции требований для разработки архитектуры компонентов/сервисов программной системы, сопровождая описание отличной аргументаций и практическими примерами Я таких хороших описаний ранее не встречал (если кто встречал, поделитесь). Да и вообще, тема декомпозиции требований абсолютно не раскрыта в области Computer Science, всех учат больше кодированию, тестированию и системному дизайну с точки зрения отказоустойчивость. В вот в области декомпозиции требований и solution architect основном доминирует метод “функциональной декомпозиции”, который вроде как вообще растет из ООП и примеров в книгах на тему ООП. Собственно его все и используют, хотя по мнению автора (и не могу не согласиться) он сугубо пагубен и не приводит к возникновению элегантных и хороших архитектур программных систем, наоборот, плодя неэффективности и потери времени и денег при разработке и развитии программных систем.

Тут надо сказать, что такое “хорошая архитектура”. Как и то, что “хороший код” это код, который легко менять под изменения требований, “хорошая архитектура” - поддерживает легкое и безболезненное внесение изменений в компоненты системы. То есть задача архитектора так определить структурные компоненты системы, что бы изменение каждого из них минимально влияли на все другие. Вообще то, что изменение требований считается болью ИТ разработчиков не правильно, большинство авторов наоборот пишут о том, что изменения требований - это жизнь, это происходит и это должно быть. А наша задача вести разработку так, что бы эти изменения поддерживать.