#design #pattern #architecture #circuit #breaker #fault #tolerance #video

В одной из статей, что я скидывал описывался дизайн паттерн Circuit Breaker. Некая машинка, которая ставится рядом с вашим сервисом, которая, если октрыта, то не пропускает трафик, и наоборот.

Нужно это для того, чтобы не перегружать ваши серваки заведомо неудачным запросами к другим upstream сервисам.

В целом, в микросервисной архитектуре это становится "бест практис" подходом и о нем знать должен каждый.

В видео ниже расскрывается эта тема еще раз. Из доп плюсов, для тех, кто Джавистов показывают как это можно имплементировать - просто.

https://www.youtube.com/watch?v=ADHcBxEXvFA

#java #memory #stack #heap #video

Год назад когда проходил собеседование на позицию разработчика во парижскую компанию, я решил задачку через реукурсию. В принципе все было просто - нужно было написать алгоритм инструмента Залить область (как в Paint).

После чего у меня спросили, а что произойдет в моем случае с программой на данных побольше: если картинка будет очень большая. О чем шла речь, как вы понимаете, я не особо понимал.

Для конекста, я учился программировать самостоятельно и какие-то темы просто даже не встречал на тот момент. Мог только уверено решать задачки и, думал, что все оке.

В общем, речь тогда шла о Stack overflow - когда ваша память выделенная на Стэк в памяти кончается.

Сегодня пересматривал эту тему еще раз, пытаясь найти очень хорошее объяснение. Перебрав много мусора, я нашел то, что хотел.

Видео ниже очень хорошо с этим справляется. Если понимате, что у вас тут пробел, или хотите просто повторить, то очень рекомендую.

https://www.youtube.com/watch?v=ckYwv4_Qtmo

#book #spark #bigData

Хорошее короткое чтиво да ещё и на русском языке

#databases #eventualConsistency #whitepaper

Статья написанная Werner Vogels - СТО Компании Амазон, автор базы данных Dynamo DB (одна из самых мною любимых за счет ее простоты и ценности для бизнес реактивности).

Статья на тему Eventual Consistency.

"In an ideal world there would be only one consistency model: when an update is made all observers would see that update."

Strong consistency - когда после записи в БД, вы читаете самые свежие даные. Week consistency - это когда после записи в БД, вы читаете не обязательно самые свежие данные. Бывает это в случае с распределенными БД, т.е. когда у вас ваша БД работает на нескольких машинах.

Зачем это нужно:
1. Ускорить запись и чтение в БД
2. Наладить устойчивость к разделению данных (размещая копии в нескольких местах)

"The developer then has to decide whether the client requires access to the absolute latest update all the time. There is a range of applications that can handle slightly stale data, and they are served well under this model.

https://www.cs.princeton.edu/courses/archive/spring11/cos448/web/docs/week4_reading2.pdf

#databases #cap_theorem #article

Одна из самых понятных статей, которую мне приходилось читать, на тему CAP теоремы, использующая жизненные примеры, что даже не-IT-шнику понятно.

https://smira.ru/posts/cap-theorem-in-plain-russian.html

#python #lib #github #youtube #download

Очень простая либа на Python, хоть и имеет небольшие баги, но все равно делает свою работу очень хорошо - скачивает видосики из Youtube - в пару строчек.

Можно писать интересные сервисы (прототипы) где нужно скачивание Youtube конента.

Уже затестил 😎 работает просто - 5 минут и готово.

https://github.com/nficano/pytube

#architecture #CQRS #DDD #EventSourcing #video

CQRS - архитектурное решение для оптимизации работы с базой данных. Одно из возможных решение - разделить запись и чтение между двумя базами данных, что позволяет использовать разные технологии для каждого и скейлить их по отдельности.

Автор идеи CQRS рассказывает об своем накопившемся опыте за несколько лет: о Pitfalls, о том что можно делать, и о том чего лучше остерегаться.

https://www.youtube.com/watch?v=LDW0QWie21s

#Architecture #CQRS #DDD #EventSourcing #video

Мое погружение в тему CQRS продолжается. Рекомендую доклад от нашего соотечественника, из Казахстана, Ануара Нурмаканова. Рассказывает о своем Use Case как они применяли CQRS, Event Sourcing, о плюсах и минусах.

Доклад очень тщательно продуман. И я думаю, что, пока, это самое лучшее и инофрмативное, что я видел смог найти. Есть над чем подумать.

Поэтому если хотите лучше понять что такое CQRS and EventSourcing, cons and pros, бегом смотреть.

https://www.youtube.com/watch?v=AKGT7wkVd34

#design_patterns #java #book

Отличный ресурс про Design Patterns, написанный на нескольких языках (в т.ч. ru, eng).

Почему это важно знать - не нужно выдумывать паттерны (велосипед) заново, нужно знать о плюсах и минусах того или иного, повышает качество коммуникации между инжинерами.

(однако, из моей практики, в некоторых языках программирования все это знать не особо нужно. Например, в Python что-то можно и нужно сделать проще.)

Из плюсов книги/сайта:
1. написано доступным языком,
2. Pros/Cons,
3. примеры реализации,
4. приятно глазу

https://refactoring.guru/design-patterns/what-is-pattern

#DDD #DomainDrivenDesign #article #habr

Domain Driven Design - пересмотрел и перечитал очень много всего, но пока ничего супер убедительного не нашел.

Если простыми словами, то пока могу отметить два пункта, о которых нужно помнить:

1. Давайте говорить на одном языке (одними и теми же терминами) с заказчиками и код оформлять так, чтобы заказчики прочитав его поняли о чем идет речь.
2. У DDD подхода много терминологии касательно слоев, которые нужно понимать. Вкатиться в них не особо и просто.

А так как "simple is better than complex", то идею DDD я пока не оценил.

Тем не менее, если рекомендовать вам, что-нибудь, чтобы не тратить время на ерунду, а почитать что-то максимально полезное, то эта статья более или менее адекватная: https://habr.com/ru/company/jugru/blog/440772/

#microservice #architecture #book

Книга про Микросервисы и Scalable Systems, написанная, инжинером из Амазона.

Помимо отличной структуры и простого языка, автор старается отвечать на вопрос зачем и почему.

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

Из плюсов: читается просто.
Если нет вермени, то можно за один присест пролистать и разобрать основные моменты.

https://try.newrelic.com/rs/412-MZS-894/images/ArchitectingforScale_SponsoredExcerpt.pdf

#python #flask #token #auth

Authentication - очень важный компонент практически любого совеременного приложения.

Делюсь отличным туториал, для тех, кто хочет Dive Deeper и пощупать Token Based Authentication!

https://realpython.com/token-based-authentication-with-flask/

#http #protocol #internet #book
Решил почитать чуть побольше об HTTP протоколе и Заголовках (Headers), чтобы понимать насколько гибко можно ими пользоваться при разработке приложений.

Рекомендую:
Из полезных ресурсов мне понравился справочник, где можно быстро понять что, зачем, и почему:
https://developer.mozilla.org/en-US/docs/Web/HTTP

Из книг мне нравится "HTTP2 in Action". Объясняется постепенно и простым языком. Также лучше узнал про HTTP1.0 и HTTP/1.1.

#design #pattern #cqrs #video

Докладчик очень просто рассказывает о CQRS паттерне на примере AWS и затрагивает немного тему Серверлесс: плюсы минусы.

Рекоменудю:
https://www.youtube.com/watch?v=D1N05oX6qH0

Я сам, когда узнал про CQRS паттерн, подумал немного о другом дизайне, где идет доп нагрузка на сервер базы данных, который паблишат все изменения в message bus, например AWS Kinesis или Kafka. А другие сервисы в свою очередь слушают изменения и пишут в другие БД - например в Elasticsearch.

В этом видео докладчик рассказывает о способи записи в две БД - сперва в основную, потом во вторую (через message bus). По сути в таком случае, я полагаю, что плюс в том, что мы разгружаем основную БД.

#kafka #article #messageBroker

Хорошая короткая статья на тему message broker Kafka. Не сказать, что автор сильно много уходит в детали, но top level понимание передает на должном уровне.

Для тех, кто не имел опыта с этой технологией статья подходит в самый раз

“Understanding Kafka — A Distributed Streaming Platform” by Nimesh Khandelwal https://medium.com/swlh/understanding-kafka-a-distributed-streaming-platform-9a0360b99de8

"Regardless of which particular aspect of software development—the programming platform, languages, the operating environment, persistence technologies, and so on —we expect constant change. Although we cannot predict when changes in the tech‐ nical or domain landscape will occur, or which changes will persist, we know change is inevitable. Consequently, we should architect our systems knowing the technical landscape will change."

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

#architecture
Один из способов не довести свою артитектуру до неподдерживаемого состояния, это быть открытым к экспериментам. Для этого нужно подгтовить почву для этого, что учитывает как работу над процессами, так и культуру команды, а иногда нужно иметь свободные бюджеты на инфрастуктурные рессурсы. Благо у AWS есть очень много бесплатных вариантов, что можно эксперементировать с чем угодно за относительно невысокую плату.

#rfcs #самоРазвитие
Когда хочешь постоянно инвестировать в само-развитие, то очень важно потратить свое время с пользой. Для этого можно найти ментора, который будет вести тебя в нужном направлении или возспользоваться краудсорсингом в виде советов в группах телеграмма или других соц. сетей.

Недавно я узнал об очень крутом сборнике ценной информации о фундаментальных знаниях, технологиях, протоколах - https://tools.ietf.org/rfc/

На каждую тему там можно найти документ размером с учебник.

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

В целом, я стараюсь уделять много времени фундаментальным знаниям, так как поняв их, реализацию понять очень легко.

Из последнего что я прочитал было про "The OAuth 2.0 Authorization Framework": https://tools.ietf.org/html/rfc6749

#teams #diversity
В наши дни всем ясно, что diversity - это то, что помогает прогрессу команд и компаний.

Мне больше нравится идея полчения diversity за счет личностных качеств: кто-то быстро производит результат (не самый красивый, но приносящий ценность для клиента), кто-то постоянно экспериментирует с новыми технологиями, кто-то силен в имплементации и пишет отличный код или рефакторит\ревьюит код других.

При правильном лидиршипе, развивая сильные стороны каждого из членов команды на все 100%, где ни один из участников не просто не будет осужден за тот или иной подход, а наоборот, где каждый будет прикрывать других в тех местах, где они сильны, то можно достичь отличных результатов.

Что еще я считаю важно для разработчкиов, так это 1) фундаментальные тех. знания на уверенном уровне - именно фундаментальные, 2) есть постоянная тяга к развитию, и 3) с этим человеком приятно работать в команде