#customer #backwards #design #approach #articles

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

"Begin with the end in mind." (с)

Пока искал информацию на тему разработки от пользователя ("Customer Backwards"), нашел отличную статью. Оригинально это понятие, как я понимаю, появилось в системе образования, когда контент подстраивался под учеников, а не учеников подстраивали под контент. Что логично, на мой взгляд.

Ну так вот, в статье, описывают процесс как подходить к разработке продуктов - сперва понимаешь что-нужно клиенту и только потом думаешь как это сделать. У этого подхода есть очень много плюсов: ты делаешь реальное нужную и ценную вещь для клиента, ты не делаешь то, что не нужно клиенту, технический дизайн после этого осуществить куда проще и качественнее.

Для убедительности, ссылаются на компанию Amazon, и людей такиех как Франклин Кови или Стив Джобс, кто придерживается/-лся этого принципа.

Также автор расскрывает тему "How to get your team to work backwards".

Из, того, что я отношу к программе минимум это написание пресс-релиза.То есть, начинайте с описания того, что вы делаете. Подать нужно так, что как будто-то вы уже это сделали и пишете пресс-релиз для медиа и for public.

“Iterating on a press release is a lot quicker and less expensive than iterating on the product itself,” says Amazon’s Ian McAllister. “If the press release is hard to write, then the product is probably going to suck. Keep working at it until the outline for each paragraph flows.”

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

За деталями, в статью:

https://www.productplan.com/product-teams-working-backwards/

#databases #elasticsearch #whitepaper

Elasticsearch - это очень мощное решение, чтобы поставить свой собственный Search Engine и залить туда свои данные. Очень круто работает поиск по тексту, приоритизируя резульат, используя TF-IDF алгоритм - если простым языком, то исключая слова создающие "шум", и делая акцент на более "ценных" словах. Очень важно понимать, что "шум"-ные слова считаются исключительно в рамках ваших текстов/данных, т.е. алгоритм адаптируется под ваш контекст.

Поиск данных по ряду фильтров происходит моментально даже на петтабайтах данных.

"clusters can grow to 10s or 1,000s of servers and petabytes of data" (с)

Достигается путем обратного интексирования ваших данных и распределению данных по множесту Nodes.

Для простоты понимания, представьте словарь/hashmap, где в значении у вас ключ, по которому вы ищите, а в значении ваши данные. Все эти пары распределяются на несколько серверов в определенном порядка, а при поисковом запросе, идет отсев ненужных серверов, и возврат значений, каждое из которых посчитанно на каждом сервере отдельно. Таким образом нагрузка распределяется, и запрос получается очень быстрым.

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

Use Cases:
В статье пишут, что 50%+ кейсов - это анализ логов. Также для маркетинговой и clickstream аналитики или изучения поведения потребителей.

Я же могу добавить, что эта БД может отлично идти в комбинации с другой БД, если вы используете дизайн паттерн CQRS (Command Query Responsibility Segregation). Об этой дизайн паттерне я еще напишу

Если хотите почитать чуть больше на эту тему, то рекомендую статью от Амазона. Мне очень нравится их слог - очень просто и понятно. Плюс рассказывают про то как это поднять на AWS - если вы это исползьуете, то для вас еще один плюс.

#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 есть очень много бесплатных вариантов, что можно эксперементировать с чем угодно за относительно невысокую плату.