#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) с этим человеком приятно работать в команде

Первая квантовая телепортация была осуществлена с помощью кремниевого фотонного чипа.

Учёные из Бристольского университета в сотрудничестве с Датским техническим университетом разработали чип, который может использовать приложения квантовой физики, генерируя отдельные частицы света и манипулируя ими в программируемых наноразмерных схемах. Такие чипы способны кодировать квантовую информацию в фотонах и обрабатывать её с высокой эффективностью и чрезвычайно низким уровнем шума. Эксперимент команды впервые продемонстрировал квантовую телепортацию информации между двумя программируемыми микросхемами.

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

#architecture #cqrs #article

Мое новогодние утро началось с прочтения статей :))

Немного о CQRS и стратегиях без Event Sourcing. На мой взгляд, статья не претендует на истинную правду, но как ещё одно мнение более чем!

Огромных всем успехов и с новым годом!

https://link.medium.com/u5tw3M30S2

Один из основных трендов техгигантов 2019- 2020г.-привлечение талантов ИИ через скупку стартапов

Amazon, Apple, Intel и другие крупные технологические компании скупают ИИ стартапы в основном для того, чтобы сконцентрировать у себя лучшие таланты в сфере ИИ.

Самой крупной сделкой года стала покупка недавняя сделала Intel с израильским ИИ стартапом Habana Labs за $2 млрд. По данным компании PitchBook, с 2013 году Apple купила 17 стартапов в сфере ИИ.

Согласно исследованиям Стэнфордского университета, еще до совершения последней покупки Intel вложил в ИИ стартапы до $35 млрд.

Когда в июне Apple купил стартап Drive.ai, на рынке решил перекупить лучших инженеров.

Заработная плата инженеров в сфере ИИ, у которых есть ученые степени, варьируется ~$224 000 в год, что вдвое превышает среднюю зарплату для разработчиков программного обеспечения в США.

Uber нанял многих преподавателей робототехники из Университета Карнеги-Меллона в 2015 году и построил лабораторию для беспилотных автомобилей.

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

#db #mariadb #columnar #storage #olap

MariaDB Corporation, the commercial entity behind the MariaDB open source relational database that began life as a "fork" of MySQL, is today announcing a new version of its platform. The release, dubbed Platform X4, brings new a storage paradigm to MariaDB. This results in both cloud-friendly deployment and accommodation of analytical workloads for the platform.

https://www.zdnet.com/article/mariadb-platform-x4-adds-cloud-first-columnar-storage/

Стартовал новый поток курса по базам данных от Carnegie Mellon University — Advanced Database Systems
В курсе не идёт речь о каких-то определённых базах, а раскрывается их внутренее устройство. Будут затронуты как транзакционные БД (OLTP), так и аналитические, распределенные БД (OLAP).

Ссылка на расписание курса: https://15721.courses.cs.cmu.edu/spring2020/schedule.html

Ссылка на страницу курса: https://15721.courses.cs.cmu.edu/spring2020/

“Reviewing Messaging in Distributed System Architectures” by Kevin Viglucci https://link.medium.com/OMOj7DLzN3

Another pub sub technology - Apache Pulsar
has some advantages over Kafka
https://www.youtube.com/watch?v=7h7hA7APa5Y

Here is a good advantage of Pulsar over Apache:
https://kafkaesque.io/7-reasons-we-choose-apache-pulsar-over-apache-kafka/

1. Streaming and queuing Come together
2. Partitions, but not necessarily partitions
3. Logs are good, distributed ledgers are better
4. Stateless Brokers, What?
5. Geo-replication for dummies
6. Consistently Faster
7. It’s All Apache Open Source

Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно.

«Работа вхолостую» означает, что процессор способен выполнить некоторые инструкции, но не делает этого, поскольку ожидает чего-то — например, ввода-вывода данных из оперативной памяти. Процентное соотношение реальной и «холостой» работы на рисунке выше — это то, что я вижу изо дня в день в работе реальных приложений на реальных серверах. Есть существенная вероятность, что и ваша программа проводит своё время примерно так же, а вы об этом и не знаете.

Что это означает для вас? Понимание того, какое количество времени процессор действительно выполняет некоторые операции, а какое — лишь ожидает данные, иногда даёт возможность изменить ваш код, уменьшив обмен данных с оперативной памятью

https://habr.com/ru/company/infopulse/blog/329206/

на самом деле есть преимущества у poetry по сравнению с простом пипом, даже внутри докера:

1) dependency resolution. это в принципе ради чего существуют все pip tools, pipenv, poetry и все такое. загугли python dependency resolution и увидишь кучу тредов, включая гитхаб обсуждения самого пипа.

смысл: твои зависимости могут требовать разные версии библиотек. очень условно говоря кто-то требует requests > 2.1, а кто-то requests < 3.0 и поетри высчитает тебе что 2.2 удовлетворяет всех. плюс когда ты делаешь апгрейд каких-то зависимостей тебе это может сильно помочь.

2) разделение дев и прод зависимостей. когда собираешь под прод контейнер там даже не будут установлены дев зависимости типа pytest, djangodebugtoolbar, etc

3) удаление пакетов. допустим ты поставил requests, он с собой много чего подтянул. пипом удалишь requests, всего его зависимости остались. poetry подчистит этот мусор

4) там вроде еще удобно билдить свои библиотеки и пушить их в PYPI, но это ни разу не пробовал