У команд будет своя обертка над либой кафки для всех остальных сценариев и команда не захочет интегрироваться с этим инструментом. А зачем им 2 версии поддерживать?!
это они еще до реализации consumer'а не дошли. Как дойдут до реализации нужного счастливому разработчику функционала, то они поймут, что никакой абстракции не получилось и просто сделали проксирование вызовов поверх grpc.
мне прям интересно как они будут делать консесус при распределении партиций между консьюмерами (подами), с ребалансом, событиями и т.д.
но итог понянет - получим прокси кафка-библиотеки поверх grpc и все те же клиентские обертки и все также счастливому разработчику нужно будет думать про кафку (потому что абстракция протекла).
либо будет очень примитивный функционал, который можно будет использовать в каких-то простых сценариях, а счастливому разработчику все также держать под рукой все те же кафочные библиотеки.
В следующий раз, как к автору придет, например, электрик, наговнякает висящих и торчащих проводов, перепутает цвета, ноль, фазу и заземление, напутает обозначения в схеме, то пусть автор не предъявляет претензий, потому что и так работает, а остальное это вкусовщина.
А вообще, многое из того что написано - опровергнуто или доказано исследованиями. ИТ - инструмент, приносящий или экономящий деньги и этот инструмент должен применяться эффективно. И его, как и любую другую человеческую деятельность, исследуют в хвост и гриву. Советую автору прочитать например "Совершенный код" Макконнелла - и сама книга отличнейшая, и в ней куча отсылок на эти самые исследования. Хотя, судя по написанному, тут уже ничем не поможешь.
Проблема в том, что большая часть сеньоров мало чем отличается от джуна, кроме как временем работы и набитыми шишками (к счастью этого недостаточно). Бизнес платит большую цену и за взрослых говнокодеров и за молодых.
у нас изначально была задача балансировать именно между redis и postgres (одни и те же данные в Protobuf-формате лежат и там и там). С такими неоднородными хранилищами я думаю будет не просто найти балансировщик из коробки.
Плюс какие-то «клиентские» ошибки также не будут видны. Это прям надо какой-то полноценный прокси писать и обобщать входящий формат запросов.
В общем это больше именно про клиентскую балансировку.
в основном каждый микросервис использует свою бд.
но есть связки микросервисов (например, читатель и писатель в рамках одного сервиса), которые могут шарить readModel.
схемы разные.
у меня девушка была, кстати фронтэндер… она мне по началу рассказывала про каких-то мега-чуваков-исполинов разработчиков… которые крутые во всем… но конкретно в чем, сказать не могла. И я тоже не мог понять, как она смогла это понять, ибо ее компетенция оставляла желать лучшего. А как меня это поклонение абстракции выводило… жуть…
нет, ну заставь дурака молиться, он и лоб расшибет.
патерны это крутой инструмент, которым нужно уметь пользоваться. Без паттернов сложные задачи весьма сложно решать. Как без моста сделать M+N реализаций вместо M*N? Или как без visitor'а собрать/обработать разнородные данные? Ну и т.д. Только колхозить.
Хотя это не значит, что везде их нужно пихать и каждую задачу пытаться решить хотя бы с использованием одного из них. Плюс многие из описанных GoB устарели (в том виде, в котором они описаны).
не стоит утрировать и передергивать.
«можно понять за 15 минут» не означает, что все собеседования должны длиться 15 минут.
Интервью должно 1) соответствовать целям набора 2) раскрывать сильные стороны интервьюируемого (ну или слабые).
Если ты берешь спеца на сортировку пузырьком, наверное да, он должен это знать. Если нет, то зачем ты вопросы высасываешь из пальца?
БОльшее число спецов работает по навыкам (порой не понимая сути). Это в любой сфере. Есть гугл, нет гугла — не важно. В любое время и в любой эпохе так было и будет. Почему? Таковы люди. Понимать — сложно. Научиться на примере легче. Перенять навык легче. Кто из нас любит сложности? Кто любит штудировать книги? Упорно работать? Единицы. Поэтому и хороших спецов вне зависимости от сферы всегда единицы.
А что касается 15 минут. Ну так задавай вопросы на понимание и понятно будет — разбирается человек или нет, понимает или нет. Чуть углубился и сразу понятно — вчера ли он это прочитал или реально разбирается.
плюсую… на собесах только и слышишь про solid/патерны, а приходишь — монолитное говно везде и никто толком ООП код писать не умеет. А если будешь писать нормально, так еще и по башке дадут.
не, на самом деле я это сразу и вижу. И просто отказываюсь от собеседования. Последний раз я отказался от 3х собеседований.
Если я выполняю бизнесовые задачи (ну и меня на них и берут), а у меня просят написать подсчет чисел фибоначчи — до свидания. Не потому что я не знаю или не могу, а потому что я занимаюсь совершенно другими вещами. Я же не идиот, чтобы каждый день сидеть и ради таких деятелей поддерживать эти ненужные мне знания (и по факту они ему тоже не нужны).
дааа… вот к таким идиотам приходишь на собеседование, а они у тебя про какую-нибудь сортировку пузырьком спрашивают… про все что у годно, только не по делу.
Некоторые упыри еще и по несколько часов мурыжат.
задавать вопросы нужно на понимание, тогда и не получишь говнокодеров. За 15 минут можно понять что из себя представляет человек.
VXLAN поддерживается нативно? это же гонево…
NVGRE — да, но не VXLAN. VXLAN доступен с какой-то там версии Nexus 1000v. Кстати позже, чем в Nexus для VMWare.
может, но на практике такое вряд ли встретится.
А если их нет, то просто ничего не рисуем.
Вот логически, рисуя схему сети, всегда начинают с чего? сначала кидают пиктограммы маршрутизаторов, потом сеть, потом соединяют маршрутизаторы с сетью, а потом уже детализируют картинку дописывая номера интерфейсов, Ip и т.д.
Тем кто интересуется и не знает/не понимает как используются разные типы LSA, лучше использовать именно такой метод.
нарисовать сеть получится, но на мой взгляд лучше начинать рисовать именно с транзитных сетей (LSA Type 2).
В LSA 2 предается сведение о сети и всех Router ID этой сети. Рисуем облачко с сетью, рисуем маршрутизаторы, тянем ниточки до облака.
Потом уже смотрим на LSA1, которые идентифицируются по Router ID и которые рассылает каждый маршрутизатор в области. В этих LSA есть список линков. Детализируем наши ранее нарисованные облачки и ниточки от маршрутизаторов, дописывая IP-интерфейсов. Потом соответственно рисуем роутеры и ниточки для точечных сетей.
и т.д.
Так оно, на мой взгляд, более понятно и логично, по человечески так сказать. Схемы же обычно рисует от общего к конкретному, тут бы стоило такой же подход применить.
да, для простых сценариев.
У команд будет своя обертка над либой кафки для всех остальных сценариев и команда не захочет интегрироваться с этим инструментом. А зачем им 2 версии поддерживать?!
это они еще до реализации consumer'а не дошли. Как дойдут до реализации нужного счастливому разработчику функционала, то они поймут, что никакой абстракции не получилось и просто сделали проксирование вызовов поверх grpc.
мне прям интересно как они будут делать консесус при распределении партиций между консьюмерами (подами), с ребалансом, событиями и т.д.
но итог понянет - получим прокси кафка-библиотеки поверх grpc и все те же клиентские обертки и все также счастливому разработчику нужно будет думать про кафку (потому что абстракция протекла).
либо будет очень примитивный функционал, который можно будет использовать в каких-то простых сценариях, а счастливому разработчику все также держать под рукой все те же кафочные библиотеки.
Говрокодеров большинство.. как и плохих специалистов в любой другой области. Значит ли это, что они правы?
В следующий раз, как к автору придет, например, электрик, наговнякает висящих и торчащих проводов, перепутает цвета, ноль, фазу и заземление, напутает обозначения в схеме, то пусть автор не предъявляет претензий, потому что и так работает, а остальное это вкусовщина.
А вообще, многое из того что написано - опровергнуто или доказано исследованиями. ИТ - инструмент, приносящий или экономящий деньги и этот инструмент должен применяться эффективно. И его, как и любую другую человеческую деятельность, исследуют в хвост и гриву. Советую автору прочитать например "Совершенный код" Макконнелла - и сама книга отличнейшая, и в ней куча отсылок на эти самые исследования. Хотя, судя по написанному, тут уже ничем не поможешь.
Проблема в том, что большая часть сеньоров мало чем отличается от джуна, кроме как временем работы и набитыми шишками (к счастью этого недостаточно). Бизнес платит большую цену и за взрослых говнокодеров и за молодых.
Напишите в личку подробнее, может быть я смаршрутизирую.
у нас изначально была задача балансировать именно между redis и postgres (одни и те же данные в Protobuf-формате лежат и там и там). С такими неоднородными хранилищами я думаю будет не просто найти балансировщик из коробки.
Плюс какие-то «клиентские» ошибки также не будут видны. Это прям надо какой-то полноценный прокси писать и обобщать входящий формат запросов.
В общем это больше именно про клиентскую балансировку.
но есть связки микросервисов (например, читатель и писатель в рамках одного сервиса), которые могут шарить readModel.
схемы разные.
у меня девушка была, кстати фронтэндер… она мне по началу рассказывала про каких-то мега-чуваков-исполинов разработчиков… которые крутые во всем… но конкретно в чем, сказать не могла. И я тоже не мог понять, как она смогла это понять, ибо ее компетенция оставляла желать лучшего. А как меня это поклонение абстракции выводило… жуть…
патерны это крутой инструмент, которым нужно уметь пользоваться. Без паттернов сложные задачи весьма сложно решать. Как без моста сделать M+N реализаций вместо M*N? Или как без visitor'а собрать/обработать разнородные данные? Ну и т.д. Только колхозить.
Хотя это не значит, что везде их нужно пихать и каждую задачу пытаться решить хотя бы с использованием одного из них. Плюс многие из описанных GoB устарели (в том виде, в котором они описаны).
Сложное и дурак придумает.
«можно понять за 15 минут» не означает, что все собеседования должны длиться 15 минут.
Интервью должно 1) соответствовать целям набора 2) раскрывать сильные стороны интервьюируемого (ну или слабые).
Если ты берешь спеца на сортировку пузырьком, наверное да, он должен это знать. Если нет, то зачем ты вопросы высасываешь из пальца?
БОльшее число спецов работает по навыкам (порой не понимая сути). Это в любой сфере. Есть гугл, нет гугла — не важно. В любое время и в любой эпохе так было и будет. Почему? Таковы люди. Понимать — сложно. Научиться на примере легче. Перенять навык легче. Кто из нас любит сложности? Кто любит штудировать книги? Упорно работать? Единицы. Поэтому и хороших спецов вне зависимости от сферы всегда единицы.
А что касается 15 минут. Ну так задавай вопросы на понимание и понятно будет — разбирается человек или нет, понимает или нет. Чуть углубился и сразу понятно — вчера ли он это прочитал или реально разбирается.
это если со своей колокольни…
Если я выполняю бизнесовые задачи (ну и меня на них и берут), а у меня просят написать подсчет чисел фибоначчи — до свидания. Не потому что я не знаю или не могу, а потому что я занимаюсь совершенно другими вещами. Я же не идиот, чтобы каждый день сидеть и ради таких деятелей поддерживать эти ненужные мне знания (и по факту они ему тоже не нужны).
а потом через полгода в гугле кончились примеры.
автор сам то верит в эту чушь?
Некоторые упыри еще и по несколько часов мурыжат.
задавать вопросы нужно на понимание, тогда и не получишь говнокодеров. За 15 минут можно понять что из себя представляет человек.
NVGRE — да, но не VXLAN. VXLAN доступен с какой-то там версии Nexus 1000v. Кстати позже, чем в Nexus для VMWare.
Trunk port к VM в VMWare тоже есть.
А если их нет, то просто ничего не рисуем.
Вот логически, рисуя схему сети, всегда начинают с чего? сначала кидают пиктограммы маршрутизаторов, потом сеть, потом соединяют маршрутизаторы с сетью, а потом уже детализируют картинку дописывая номера интерфейсов, Ip и т.д.
Тем кто интересуется и не знает/не понимает как используются разные типы LSA, лучше использовать именно такой метод.
В LSA 2 предается сведение о сети и всех Router ID этой сети. Рисуем облачко с сетью, рисуем маршрутизаторы, тянем ниточки до облака.
Потом уже смотрим на LSA1, которые идентифицируются по Router ID и которые рассылает каждый маршрутизатор в области. В этих LSA есть список линков. Детализируем наши ранее нарисованные облачки и ниточки от маршрутизаторов, дописывая IP-интерфейсов. Потом соответственно рисуем роутеры и ниточки для точечных сетей.
и т.д.
Так оно, на мой взгляд, более понятно и логично, по человечески так сказать. Схемы же обычно рисует от общего к конкретному, тут бы стоило такой же подход применить.