Очень круто, харизматично и доступно) Удобный формат, когда нужно просто иметь представление о технологии. И лучше получить это представление от человека, который работал с данными технологиями, нежели пытаться составить самому, тратя много времени.
Великолепное видео. Автор выделил основные моменты всех систем так что можно сразу понять что это за технология, а дальше просто углубляться в мануалы. Огромное спасибо!
Все и правда понятно! Год назад, как только заходил в сферу айти ничего не понимал, а сейчас сталкиваюсь с тестированием на проекте, где два приложения обмениваются сообщениями с помощью брокера (RabbitMQ) и нужно было протестировать в web-интерфейсе корректный роутинг, payload и header, теперь стало все понятно и корректно закрыл задачу =) Благодарю!
Спасибо за ролик очень познавательно и интересно, но только на сколько я помню, Kafka позволяет одному консьюмеру читать данные с разных партиций и офсет не принадлежит определенной партиции, каждый офсет определяется для отдельной консьюмер группы
На 12:10 сказано что в Кафке одна партиция один консьюмер. В том смысле в котором имеет в виду автор это не так. В Кафке у топика может быть множество консьюмер групп, что по-сути и означает множество консьюмеров на одном топике, каждый из которых со своим офсетом
Есть такие как я которые заходят каждые три месяца чтобы вспомнить что нибудь про брокеры, из за того что вообще по работе не связанны с ними ,но хотят хоть что то о них знать))) Такладчик ты супер ))
Консьюмер может сам ходить за сообщения в Rabbit MQ. Т.е подключился запросил данные из очереди, завершил выполнение. Но также консьюмер может выполняться как демон, т.е. не завершать выполнение после чтения из очереди, а продолжать ждать новые сообщения
Хорошая подача материала, немного не хватает описания примеров использования данных сервисов, типа вот это збс будет в такой задаче и тд. Пс. Лайк и подписка
В целом познавательно, но про Kafka что-то совсем поверхностно рассказано. Соотношение Consumer и Partition 1:1 это, конечно, правда. Но только в рамках одной ConsumerGroup! Ничто не мешает подключить несколько групп Consumer'ов к одному топику. И это как раз классная фишка Kafka - гранулярность может быть настроена очень тонко. Интересно также отметить, что Kafka гарантирует направление сообщений с одним и тем же ключом в конкретный Partition, чем самым гарантируется очередность (если она нужна)
6:19 плюет на routing key - верно, плюет на binding - тут оговорка, как раз то не плюет потому что именно binding определяет в какие очереди положить. Во все, которые прилинкованы к обменнику.
Вопрос. Я задеплоил мемкеш на кубернетес кластер в aws. Он ранится в неймспейсе мемкеш. Под ранится также. И в кластере ранятся апликейшны. Вопрос как их связать аппликейшн и мемкеш под чтоб он оттуда брал информацию перед ДБ. ДБ у меня постгрес так же на aws. Нужно связать бакенды.
Спасибо за отклик) Более того, по ним можно строить запросы :) В скором времени по JSONB отдельно можно рассказать, так как будет опыт применения в production.
03:00 - Что значит "RabbitMQ сам дёргает получателя?" Получатель не как в redis, в желаемый им момент НЕ может обратиться к сервису и по ключу и данные получить? Надо держать его в режиме слушания постоянно? А если слушатель занят? RabbitMq дождётся, когда тот освободится и снова пошлёт?
на сколько я понимаю в кафеке оффсет не у партиции, а у партиции и консъюмер группы, а консъюмер групп может быть несколько, и они могут параллельно по разному читать партиции, внутри консъюмер группы да, партиций должно хватать на каждого консъюмера в консъюмер группе
Подскажите - как при использовании Редиса для Кеша использовать горизонтальное масштабирования - если можешь пойти на сервер где нет твоих данных сессий?
Биндинг обменников и очередей в RabbitMQ - это не всегда строка как заявлено. Есть еще тип обменника Consistent-Hash, который вообще не рассмотрен, у него как раз биндинг - число.
Господа, а подскажите, большие ли будут накладные расходы если использовать redis, rabbit или kafka для общения между различными частями монолит приложения? Например если я хочу внутри приложения сделать сервисы которые должны взаимодействовать друг с другом только посредством чтения и генерации событий через шину сообщений.
Накладных расходов особо не будет - вопрос лишь целесообразности. Если вам это действительно нужно - используйте на здоровье. А монолит там у вас или мэш из микросервисов - не так уж важно)
Вопрос по постгресу и его возможности использовать json атрибуты. Вот у меня есть таблица неких сущностей, которые хочется видеть в одном списке, но этих сущностей очень большое кол-во категорий со своими уникальными полями. Например, пусть будут товары. Мы продаём видеокарты и мониторы. У них совершенно разные параметры. Искать и сортировать по ним не обязательно, важно их только читать и редактировать. Категории постоянно добавляются новые, товары нельзя перемещать из одной категории в другую, у них немного отличаются интерфейсы. К тому же, бывают уникальные товары, которые существуют в единичном экземпляре для отдельной категории. Например, вертолёт. Вот он есть только у одного юзера и всё. Городить отдельные таблицы под каждую категорию не очень хочется. Джойнить их потом... фу, очень сложно. Я уже отчаялся и думаю использовать монгу под это дело. Но заводить монгу для одной-единственной таблицы как-то не хочется тоже, странновато. А вот json возможно выход. Типа назвать поле, скажем, category_attrs и складывать туда уникальные поля? 🤨
Если вам нет необходимости сортировать и фильтровать продукты (назовем их так) по этим уникальным полям, то хранить их можно как вам заблагорассудится (да хоть как текст через запятую в одном текстовом поле), так как работу по сериализации / десериализации данных можно переложить на ваше приложение. Если же вам необходимо фильтровать / сортировать данные то варианта сейчас по-сути два (если оставаться в рамках PostgreSQL): 1. EAV (ознакомьтесь с этим методом поподробнее) 2. JSONB - как мы и упоминали в видео, это мощный инструмент, который позволяет строить не просто запросы с применением данных из JSON-поля, но даже формировать по ним индексы, что существенно скажется на производительности запроса. Лоб в лоб оба метода мы не сравнивали, но применяем оба в работе над своими проектами.
1 В начале было Слово, и Слово было у Бога, и Слово было Бог. 2 Оно было в начале у Бога. 3 Все чрез Него начало быть, и без Него ничто не начало быть, что начало быть. 4 В Нем была жизнь, и жизнь была свет человеков. 5 И свет во тьме светит, и тьма не объяла его. (Иоан.1:1-5) 9 Был Свет истинный, Который просвещает всякого человека, приходящего в мир. 10 В мире был, и мир чрез Него начал быть, и мир Его не познал. 11 Пришел к своим, и свои Его не приняли. 12 А тем, которые приняли Его, верующим во имя Его, дал власть быть чадами Божиими, 13 которые ни от крови, ни от хотения плоти, ни от хотения мужа, но от Бога родились. 14 И Слово стало плотию, и обитало с нами, полное благодати и истины; и мы видели славу Его, славу, как Единородного от Отца. (Иоан.1:9-14)
Крутецкий доклад, хорошо и быстро прошёлся по технологиям, удобно выбирать Я бы ещё Cassandra добавил, ну и немножко Camel, хоть это и несколько другого плана вещь, но тоже для обмена данными
@@Rclass глянул ваши работы. Моя команда 10 лет назад делала первую версию сайта ваших клиентов по шинам ) название мир колес тогда придумали по приколу, клиент одобрил )
а сфига ли у кафка партишна один консумер и один оффсет? в рамках одной кансумер группы - да. но таких групп может быть сколько угодно, и каждая со своим офсетом.
0:40 RabbitMQ
9:34 Apache Kafka
15:10 Redis
19:30 Memcached
21:19 NuxtJS
25:55 MongoDB
30:33 PostgreSQL
Спасибо, в закреп :)
Eeeeeeeeeeeeee eeeeee eeeeeeetteeeeeee eeeeeee
Очень смешно получилось когда докладчик постиг дзен и стал невидимым на 20:43 секунде 😂
Это новая технология! :)
Закэшировался)))
Немного испугался
особенно смешно то, что он в этот момент как раз говорил про время жизни объекта))
@@Илья-м4н9т garbage collector в действии)
Спасибо докладчику, стояла задача понять отличие RabbitMQ от Kafka - это лучшее русскоязычное видео, поверьте.
Cпасибо :) Стараемся для вас ^_^
Докладчик заработал мою подписку на этот канал. Красавчик!
Стараемся :)
Аналогично
А я свою подписку не считаю чем то что можно заслужить, просто дикое спасибо за техничность,наглядность и понятность!
+
испугался, когда лектор сказал "истекло время жизни" и исчез
Спецэффекты которые мы заслужили ))))
Классно, что редис работает пиздец как быстро) спасибо за видео
Очень круто, харизматично и доступно) Удобный формат, когда нужно просто иметь представление о технологии. И лучше получить это представление от человека, который работал с данными технологиями, нежели пытаться составить самому, тратя много времени.
Спасибо за доверие :)
Господи, как найти работу, чтобы начальник был вот таким грамотным и весёлым дядькой?
Да это не так сложно как вам кажется)
А вообще можно самому стать вот таким "веселым дядькой")
Великолепное видео. Автор выделил основные моменты всех систем так что можно сразу понять что это за технология, а дальше просто углубляться в мануалы. Огромное спасибо!
Спасибо за отзыв, мы старались :)
Считаю, что это лучшая реклама кофе якобс монарх. Большое спасибо, было очень интересно
Спасибо)
Докладчик очень хорошо рассказывает и без воды! Прямо топ! Подписка однозначно!
Спасибо :)
Быстро, понятно, без лишней информации! Спасибо за видо!
Спасибо за отклик :)
"Отдай свежатину!". Сердечно благодарю за ролик)
Спасибо большое :)
Наконец кто-то объяснил человеческим языком как всё это работает, а не миллионом технических терминов. Спасибо!!
Спасибо, мы старались :)
Все и правда понятно! Год назад, как только заходил в сферу айти ничего не понимал, а сейчас сталкиваюсь с тестированием на проекте, где два приложения обмениваются сообщениями с помощью брокера (RabbitMQ) и нужно было протестировать в web-интерфейсе корректный роутинг, payload и header, теперь стало все понятно и корректно закрыл задачу =) Благодарю!
Ура! Рады, что помогли :) Спасибо за отклик :)
Это именно тот способ изложения инфы, который я хотел услышать!
Спасибо, мы старались :)
Спасибо за ролик очень познавательно и интересно, но только на сколько я помню, Kafka позволяет одному консьюмеру читать данные с разных партиций и офсет не принадлежит определенной партиции, каждый офсет определяется для отдельной консьюмер группы
Спасибо что смотрите :) Да, ранее уже сообщали :)
Спасибо, для знакомства аналитикам и техническим менеджерам - отличный формат.
Спасибо, мы старались :)
Вот прямо классно рассказал! Нужно больше материала:))
Спасибо, стараемся ^_^
Спасибо, спасибо, спасибо! Наконец-то я что-то знаю про брокеры сообщений
Всегда пожалуйста :)
Отличный докладчик👍🏻👍🏻👍🏻
Спасибо! :)
Как ты научился исчезать? 2:41 Сделай следующее видео про это. Типо "невероятно, но факт..." ))))))
ой на 20:41
Отвлекли в середине доклада) пришлось пропасть)
Прямо выжимка ценного! Огромное спасибо за такие видео!
Спасибо, стараемся для вас :)
40 минут смотрел рекламу Якобс. Чет кофейку захотелось
Сработало! Там еще скотч сантехнический, лейбл только потерялся)
Блин..Тоже что то захотелось...А был в завяске от кофе ((
@@Дмитрийсекрет-н7о так давайте к нам на кофе? У нас кофемашина неплохая и кофе свежий, мы вам такой капучино сварим, ууух!
@@Rclass Classое предложение))))
@@Rclass )))))
Отлично, без пафоса и воды. Четко и понятно!
Спасибо, мы старались :)
Отличный видос! Все кратко и понятно. Подписка!
Спасибо, мы старались! :)
Интересно было узнать про PostgreSQL. Спасибо!
Спасибо за отклик, мы старались ^_^
Истекло время жизни🤣🤣🤣
Так бывает)))
очень крутой выпуск для понимания баз данных неожидал тут Nuxt увидеть) сам пишу на нем
Тут не только о базах, тут в целом по технологиям и решениям)
Хороший обзор... Хотелось бы подробнее о RabbitMQ (В частности в Kubernetes, как все работает...)
Спасибо, мы старались! К сожалению, про работу в Kubernetes нам нечего рассказать (
Спасибо, очень интересный доклад!
Благодарим вас :)
на пальцах и по делу!
На 12:10 сказано что в Кафке одна партиция один консьюмер. В том смысле в котором имеет в виду автор это не так. В Кафке у топика может быть множество консьюмер групп, что по-сути и означает множество консьюмеров на одном топике, каждый из которых со своим офсетом
Отличное замечание, учту.
и оффсет это не байтовое смещение
Есть такие как я которые заходят каждые три месяца чтобы вспомнить что нибудь про брокеры, из за того что вообще по работе не связанны с ними ,но хотят хоть что то о них знать))) Такладчик ты супер ))
День добрый! Не совсем поняли что вы имеете ввиду, но полностью с вами согласны)))
Чисто отдельная подписка за презентацию:)
Ай спасибо! :)
Нахватался бэкендерских словечек ))
Спасибо, подписался 🔥
Это только начало) Можете начинать собирать словарь)))
@@Rclass Буду выходить с этим словарем в курилку и обсуждать всякие редИсы со взрослыми дядями бэкендерами )
Консьюмер может сам ходить за сообщения в Rabbit MQ. Т.е подключился запросил данные из очереди, завершил выполнение. Но также консьюмер может выполняться как демон, т.е. не завершать выполнение после чтения из очереди, а продолжать ждать новые сообщения
Часто реализации только второго варианта встречаются, учтем, спасибо 🙏
Отличное видео! Большое спасибо!
Спасибо, мы старались
Четко и по делу, без лишней воды. Вообще красава.
Спасибо, мы старались ^_^
Отличнейший обзор, ничего лишнего!
Мы рады что вам понравилось :)
Ахеренный видос, спасибо
Стараемся ^_^
Спасибо за доклад! В Nuxt при создании SPA понятно, что проблемы с SEO, но при SSR ведь не должно быть проблем
SSR и решает (как одну из) проблему с SEO :)
Классный обзор
Отличная подача материала, коротко и ясно! Спасибо!)
Спасибо, стараемся ^_^
Спасибо большое, все очень понятно объясняете. Отдельный лайк за оптимизм 🤣
Спасибо, мы старались :)
Хорошая подача материала, немного не хватает описания примеров использования данных сервисов, типа вот это збс будет в такой задаче и тд.
Пс. Лайк и подписка
Интересная идея. Давайте я подумаю над этим. Возможно, сформирую список задач и расскажу например как бы я их решал :)
@@OkulovAnton вот это было бы супер!
JSON = Головастик, ибо: J=Жаба , SON=сын, а сын жабы = головастик. ЧТД
Интересное мнение, запомним)
В целом познавательно, но про Kafka что-то совсем поверхностно рассказано. Соотношение Consumer и Partition 1:1 это, конечно, правда. Но только в рамках одной ConsumerGroup! Ничто не мешает подключить несколько групп Consumer'ов к одному топику. И это как раз классная фишка Kafka - гранулярность может быть настроена очень тонко. Интересно также отметить, что Kafka гарантирует направление сообщений с одним и тем же ключом в конкретный Partition, чем самым гарантируется очередность (если она нужна)
Ага, отмечали уже в комментах) В целом надо было примерно прикинуть что это за зверь и чем принципиально от других брокеров отличается.
6:19 плюет на routing key - верно, плюет на binding - тут оговорка, как раз то не плюет потому что именно binding определяет в какие очереди положить. Во все, которые прилинкованы к обменнику.
Спасибо за уточнение :)
за Раббит и Редис спасибооу, также и за Монгу (за инфо, что в ней можно вставлять жабоскрипт-код).
Мы рады, что вам зашло :)
Спасибо большое за это прекрасное видео! 👍
Спасибо, что смотрите)
вот это я понимаю экспресс обучение
Быстрее только список ссылок дать)
Лектор очень крут, спасибо за презентацию
Спасибо, стараемся для вас :)
истекло время жизни...жестоко, очень 20:39
Вопрос. Я задеплоил мемкеш на кубернетес кластер в aws. Он ранится в неймспейсе мемкеш. Под ранится также. И в кластере ранятся апликейшны. Вопрос как их связать аппликейшн и мемкеш под чтоб он оттуда брал информацию перед ДБ. ДБ у меня постгрес так же на aws. Нужно связать бакенды.
Писать руками кеширование в мемкеш внутри приложения. Если всё правильно поняли.
@@Rclass я понял. Но я не разработчик, эти жава аппликейшны не я писал.
@@kazakman7772 тогда вряд ли что-нибудь получится(
Безумно классный рассказчик)) прям хоть под пиво сиди смотри))
Спасибо, мы старались :)
Оч крутое видео. Спасибо)
Спасибо, что вы с нами)
Отличное обзорное видео! Спасибо! Не знал, что в Postgres можно хранить массивы)
Спасибо за отклик) Более того, по ним можно строить запросы :) В скором времени по JSONB отдельно можно рассказать, так как будет опыт применения в production.
Забавное совпадение когда лектор исчез рассказывая про TTL для memcached
Магия, не иначе :)
спасибо, понятно и ёмко
Спасибо, мы старались!
03:00 - Что значит "RabbitMQ сам дёргает получателя?"
Получатель не как в redis, в желаемый им момент НЕ может обратиться к сервису и по ключу и данные получить?
Надо держать его в режиме слушания постоянно? А если слушатель занят? RabbitMq дождётся, когда тот освободится и снова пошлёт?
Да, слушатель поднимается и работает рядом с producer. Да, если слушатель один и он занят - то сообщения обработаются по очереди, одно за другим)
Спасибо! Видео ТОП!!
Спасибо, мы старались :)
на сколько я понимаю в кафеке оффсет не у партиции, а у партиции и консъюмер группы, а консъюмер групп может быть несколько, и они могут параллельно по разному читать партиции, внутри консъюмер группы да, партиций должно хватать на каждого консъюмера в консъюмер группе
Класс! Очень хороший обзор, спасибо!
Спасибо, мы старались :)
Столько всего придумано, что вроде не чего не надо, но продолжают и продолжают что то изобретать :-)
Что-то устаревает, что-то становится более востребованным... Не стоит на месте отрасль)
12:27 - как связаны Partition и очередь?
Это одно и то же или нет?
Один Partition = 1 COnsumer. А что с очередями? 1 Queue = 1 Consumer????
Крутой обзор! И канал топчик. Лайк, подписка!
Спасибо, мы старались ^_^
Лови подписку брат!
Спасибо, мы старались :)
@@Rclass ну тогда ловите подписку братья)
Вот смотрю я ролик и понимаю, не Монго бд...
Видео потрясающе, спасибо большое!
Спасибо, мы старались :)
Класс, спасибо!)
Спасибо, мы старались :)
Может всё-таки 1 партишн = 1 консьюмер группа? У нас вроде овер 50 консьюмеров читают из топиков с партиционированием 3
Да-да, всё так, поправили уже раньше :) Спасибо что смотрите :)
в MongoDB есть aggregation framework, и аналог join можно сделать, в монго это называется Lookup
Да, действительно. Правда стоит помнить что с распределенными БД этот вариант не работает :)
Подскажите - как при использовании Редиса для Кеша использовать горизонтальное масштабирования - если можешь пойти на сервер где нет твоих данных сессий?
Не очень понятно как связаны кеш и сессии?
@@Rclass извиняюсь, вопрос про сессии только
Биндинг обменников и очередей в RabbitMQ - это не всегда строка как заявлено. Есть еще тип обменника Consistent-Hash, который вообще не рассмотрен, у него как раз биндинг - число.
Учтем, обычно работали со строками)
Господа, а подскажите, большие ли будут накладные расходы если использовать redis, rabbit или kafka для общения между различными частями монолит приложения? Например если я хочу внутри приложения сделать сервисы которые должны взаимодействовать друг с другом только посредством чтения и генерации событий через шину сообщений.
Накладных расходов особо не будет - вопрос лишь целесообразности. Если вам это действительно нужно - используйте на здоровье. А монолит там у вас или мэш из микросервисов - не так уж важно)
@@Rclass ну если мне нужен брокер сообщений хороший, неужели самому писать
@@maksimsergeevich5939 тогда используйте конечно)
А кофе у вас на полке растворимый или зерновой?
Откроем страшный секрет: там не кофе :) А кофе у нас в целом зерновой и очень неплохой, приходите при случае, мы вас угостим :)
+ respect
Thx for watching :)
20:40 Антон, если так по фану использовать кольцо, Назгулы на тебя выйдут быстрее
Ужас! Я буду осторожен! Только никому!
крутой мужик
тоже буду крутым мужиком, но не пузатым))
Выводы сделаны, наш техлид уже три года как ходит в спортзал и скоро обещает выполнить КМС по жиму лёжа)
@@Rclass ну такой дядя обязан кмс по жиму лежа быть)
Отлично, спасибо!
Спасибо, мы старались ^_^
Что за фокус с исчезнлвением произошел на 21.10-21.16 ?
Это неназванная технология)
@@Rclass а на кого вы учите свою группу ? Админис раторы базы данных ?
Спасибо!
Пожалуйста :) Стараемся для вас!
Бро, спасибо!
Вам спасибо за отклик :) Стараемся ^_^
20:44 - докладчик исчез, надеюсь, он закешировался.
Ахаха) Лучшая шутка про исчезновение, жаль два закрепа нельзя) Спасибо что смотрите)
На 20:43 изчезновение. Это какая технология?)
Мы проверяем пока, обкатываем и тестируем. Как только будет готово в прод - обязательно сообщим! :)
у ведущего истекло время жизни
Шикарно
Спасибо, мы старались!
Спасибо
Спасибо, мы старались :)
Вопрос по постгресу и его возможности использовать json атрибуты.
Вот у меня есть таблица неких сущностей, которые хочется видеть в одном списке, но этих сущностей очень большое кол-во категорий со своими уникальными полями.
Например, пусть будут товары. Мы продаём видеокарты и мониторы. У них совершенно разные параметры. Искать и сортировать по ним не обязательно, важно их только читать и редактировать. Категории постоянно добавляются новые, товары нельзя перемещать из одной категории в другую, у них немного отличаются интерфейсы. К тому же, бывают уникальные товары, которые существуют в единичном экземпляре для отдельной категории. Например, вертолёт. Вот он есть только у одного юзера и всё.
Городить отдельные таблицы под каждую категорию не очень хочется. Джойнить их потом... фу, очень сложно.
Я уже отчаялся и думаю использовать монгу под это дело. Но заводить монгу для одной-единственной таблицы как-то не хочется тоже, странновато.
А вот json возможно выход. Типа назвать поле, скажем, category_attrs и складывать туда уникальные поля? 🤨
Если вам нет необходимости сортировать и фильтровать продукты (назовем их так) по этим уникальным полям, то хранить их можно как вам заблагорассудится (да хоть как текст через запятую в одном текстовом поле), так как работу по сериализации / десериализации данных можно переложить на ваше приложение. Если же вам необходимо фильтровать / сортировать данные то варианта сейчас по-сути два (если оставаться в рамках PostgreSQL):
1. EAV (ознакомьтесь с этим методом поподробнее)
2. JSONB - как мы и упоминали в видео, это мощный инструмент, который позволяет строить не просто запросы с применением данных из JSON-поля, но даже формировать по ним индексы, что существенно скажется на производительности запроса.
Лоб в лоб оба метода мы не сравнивали, но применяем оба в работе над своими проектами.
@@Rclass почитаю подробнее, спасибо!)
20:43 Я испугался на этом моменте
Бу! Мы еще не так умеем)
6:13 Funout ??? Maybe "fanout" ?
:facepalm: fanout естессно)
Хорошо получилось
1 В начале было Слово, и Слово было у Бога, и Слово было Бог.
2 Оно было в начале у Бога.
3 Все чрез Него начало быть, и без Него ничто не начало быть, что начало быть.
4 В Нем была жизнь, и жизнь была свет человеков.
5 И свет во тьме светит, и тьма не объяла его.
(Иоан.1:1-5)
9 Был Свет истинный, Который просвещает всякого человека, приходящего в мир.
10 В мире был, и мир чрез Него начал быть, и мир Его не познал.
11 Пришел к своим, и свои Его не приняли.
12 А тем, которые приняли Его, верующим во имя Его, дал власть быть чадами Божиими,
13 которые ни от крови, ни от хотения плоти, ни от хотения мужа, но от Бога родились.
14 И Слово стало плотию, и обитало с нами, полное благодати и истины; и мы видели славу Его, славу, как Единородного от Отца.
(Иоан.1:9-14)
Мы не очень поняли к какой из технологий это можно отнести...
Крутецкий доклад, хорошо и быстро прошёлся по технологиям, удобно выбирать
Я бы ещё Cassandra добавил, ну и немножко Camel, хоть это и несколько другого плана вещь, но тоже для обмена данными
Спасибо, мы старались :)
Непонятно зачем в этот список Nuxt попал)
Там половина не понятно зачем) Дикий компот :) Но вот так попросили осветить)
докладчик, случаем, не из Кирова? )
Мы работаем в Кирове :) Если рядом - приходите на кофе и печеньки)
@@Rclass по какому адресу?
а, нашёл, Володарского 9, 3 этаж
@@IvanBlaBlaBla Именно так!
@@Rclass глянул ваши работы. Моя команда 10 лет назад делала первую версию сайта ваших клиентов по шинам ) название мир колес тогда придумали по приколу, клиент одобрил )
kurz und sehr klar
vielen dank
Здорово ведёте урок, спасибо!
Спасибо, мы старались ^_^
Как брокер сообщений , очереди на redis сделать?
Добрый день! Подключаете редис и используете)
а сфига ли у кафка партишна один консумер и один оффсет? в рамках одной кансумер группы - да. но таких групп может быть сколько угодно, и каждая со своим офсетом.
Все верно подмечено, уже поправляли не раз, но еще раз спасибо за бдительность :)
29:03 а в JS так всё и устроено. Сначала: "хуйня какая-то..." а потом "хм, в принципе, удобно".
Сложно не согласиться 😁 Наверное за это мы его любим и ненавидим одновременно :)