0: Видно, слышно. Да, все хорошо. Сейчас подождём ещё участников и попозже начнём. Да, хорошо.

1: Привет. Привет. Привет. Здравствуйте. Да вроде все потихонечку собрались. Давайте знакомиться. Арсений, привет. Я, Настя, я рекрутёр. Ещё не общались, так что рада видеть. Рада познакомиться. Вот. И

2: С нами сейчас, Серёжа, Кирилл, это наши бэкенд разработчики, собственно, все технические вопросы ты будешь с ними обсуждать. Вот, а по флоу интервью обычно начинаем с того, что я предлагаю немножко тебе рассказать про себя такой продакшн. Затем я задаю такие общие

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

4: Ты, если комфортно, то будет здорово. Хорошо, да, комфортно. Да, супер. Да. Будем рады про тебя немножко услышать. Меня зовут Арсений, я занимаюсь разработкой на Шарпе технологии дотнет. В рамках предыдущей компании. У меня было

5: Несколько проектов 1 связанный с микросервисами, 2 с документооборотом воркфлоу, можно сказать, сотрудников команда у нас состояла из 10 человек, это был 5 бэкенд разработчиков, 2 фронта тимлид, архитектор, тестировщик.

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

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

8: И в целом проблем не возникало.

9: Окей, окей, тогда давай такие чуть, ну, более общие вопросики пообсуждаем. Возможно, что-то у тебя уже на телефонном интервью Даша спрашивала, вот, но я просто чуть поподробнее про это поговорю. Вот. И точно она спрашивала у тебя, чего тебе хочется?

10: Месте работы. Вот, собственно, я повторю её вопрос. Возможно, уже там походил по собеседованиям как-то поознить с компаниями. Более комплексно для себя сложилось представление идеальной компании. Так скажем, куда точно пойдёшь работать.

11: Ну, наверное, да, какие-то общие представления есть. Хотелось бы работать в средней или большой команде. Мне это наиболее комфортный вариант, который я для себя рассматриваю. Вот. Ну, соответственно, чем команда больше, тем лучше. Вот в целом.

12: Интересен опыт с микросервисами. Хочется тоже с этим больше работать, поэтому активно рассматриваю для себя, и в том числе финтех, сферу. Угу. Угу. Окей. А средняя, большая команда, это примерно сколько человек? Ну, я

13: Думаю, что там от 7, да, такая уже начально средняя команда, и там, соответственно, она, может быть, там и 10 человек, и 15 человек. У нас 1 время на проекте была команда 15 человек. Вот, ну, в среднем 10, да. Ну, это достаточно такая уже серьёзная команда на мой.

14: Вот я команды там не знаю, по 50 человек не видел, поэтому не могу сказать.

15: Да, окей, поняла. Хорошо, давай тогда поговорим, как у вас работа устроена вот на текущем месте. То есть как вы получаете задачи, от кого, как вы их распределяете, оцениваете. В общем, такой путь задачи у нас есть такая вещь, как

16: Покер планирование. Вот мы её используем, в том числе. Также у нас часто есть на проекте младшие специалисты джуниоры. Вот к нам приходят очень активно со стажировок, потому что компания работает, ну, мы находимся в большой экосистеме с росатомом, и та

17: По распределению, по стажировкам, как бы очень много человек приходит. Соответственно, тимлид у нас назначает того, кто будет ответственен за джуниор специалистов. Я 1 время, собственно, работал с ними и помогал ребятам депозирования задачи.

18: Давал достаточно сначала лёгкие задачи, потом посложнее. Вот. В итоге был там рост, ну, в принципе, достаточно линейным на проекте. И ребята на дистанции, там, ну, будем говорить, что росли для всех остальных специалистов. Ну,

19: Покер планирование. Либо бывает, тимлид назначает задачи там, потому что мы уже долгое время работаем друг с другом и знаем каждую особенности. Поэтому у нас такой более свойский формат распределения бывает. Угу. Окей, окей. А

20: Приходит задача откуда-то есть, ну, я понимаю, что даёт тимлид, там, ну, от бизнеса напрямую, там, через аналитиков, через аналитиков она приходит, да? Угу. Угу. А задачи обычно описанные или просто вот в формате надо сделать. Вот это бывает по разному.

21: Бывает, декомпозированными уже бывает, нет. То есть иногда приходится действительно подумать над тем, как это сделать. То есть, когда приходит просто бизнес требование какой-то юзкейс там реализовать. Вот.

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

23: Бывает, там, как бы, какой-то демо там провести, там, условно, вот, но в целом меньше взаимодействуем с заказчиками. У нас как бы, для этого есть аналитики, вот через них взаимодействуем. Угу. Угу. Окей, окей. А насколько ком?

24: Комфортно. То есть, ну, просто бывает, да, что это как сломанный телефон работает, бывает, что хорошо настроено. То есть тебе самому как удобнее. Может, был опыт ранее там какой-то работы с заказчиками напрямую, да, в принципе, удобно, на самом деле, даже нравится.

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

26: Вот тут я услышала, что, да, работа с чинами, со стажёрами вообще, вот на будущее. Насколько интересно всякое менторство. Анбординг, интересно ли продолжать в этом двигаться? Да, это интересно. Не могу назвать, на насколько прям, ну, это, в принципе,

27: Интересные занятия. Угу. Угу. Да, поняла. А вот тебе самой, когда по технике хочется, может, что-то уточнить, там посоветоваться, есть ли к кому сходить. Может, какие-то у вас есть там встречи по обмену опытом, на

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

29: Бывают. Угу. Угу. Окей, окей, поняла. Хорошо. А вот приоритеты у задач, кто выставляет? Или они уже приходят с приоритетами, они уже есть с приоритетами. Угу. Окей.

30: А бывает такое, что, ну, там, не знаю, может, не согласны с приоритетом, что какая-то задача все-таки более срочная. Приходится ли как-то это обсуждать? Ну, вы знаете, когда мы работали по скраму, в принципе, такого не возникало. Вот была ситуация, когда

31: Работали по waterfall методологии прям очень давно. Вот. И там был случай, когда заказчик пришёл в середине уже намеченного спринта, а там же вотерфол, он идёт последовательно и по сути, там эти стадии тяжело отменять, вот и пришлось.

32: Там прямо в середине недели, собственно, заниматься задачами на продакшене, которые там, в общем, проблемы, которые у нас были, вот это было некомфортно, да, но потом перешли на скрам и долгое время работаем по нему вот со скрамом. Такого у нас нет. Угу.

33: Угу. Окей. А, ну, если вот, допустим, прилетает, там, не знаю, 10 задач, все приоритетные, все. Прям сейчас нужно сделать, что делать? Не знаю, у меня такой ситуации не было. Угу. Ну, окей, давай в вакууме её представим. Ну,

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

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

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

37: За уже там неделю хорошо ориентируются, понимают, что происходит. Это такое серьёзное изменение. Вот. Ну и были какие-то моменты, связанные с кодстайлов на проекте. Ну опять же, тут, наверное, если разработчики там спросят,

38: Да, то можно будет детально поговорить. Ну да, тоже был определённый на проекте реализован.

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

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

41: Я не встречал. Угу. Угу. Окей. Поняла, поняла. Хорошо. А вообще, как себя поддерживаешь, чтобы не выгорать, не сгорать? Может, уже бывал в таком состоянии я в таком состоянии?

42: Бывал, не ощущал никогда такого. Угу. Угу. Окей. А как считаешь, вот что может привести? Может, от чего ты там сильно устаёшь? Или что сильно демотивирует, выбивает из колеи?

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

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

45: Не знаю там.

46: Угу. Угу. Окей, окей, хорошо, поняла, услышала, услышала. Может быть, вот сейчас какие-то зоны роста для себя видишь? То есть, да, я услышала, что тыхочешь поработать побольше с микросе.

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

48: Подразделение мне очень понравилось. Вот хотелось бы больше с этим заниматься. Я знаю, что разные там финансово технические компании, банки очень активно работают с микросервисами, поэтому для меня это цель номер 1. Угу. Угу. Да, поняла.

49: Так, ну тогда, в принципе, по моим вопросам все очень шустро с тобой по всем пробежались. Спасибо тебе большое. Давай я тогда ребятам уже слово передам, они все уточняющие моменты по опыту и так далее поспрашивают. Я ещё немножко с вами посижу и

50: К концу встречи уже убегу. Привет ещё раз. Мы, наверное, сразу на ты перейдём. Не против? Да, да. Не против. Окей. В конце можешь ещё тоже позадавать свои вопросы. Вот мы поотвечаем, если что, просто дисклеймер. Вот.

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

52: Значит, у меня было 2 проекта. 1 мы завершили, 2 мы активно все равно поддерживаем, пишем, развиваем его основной проект. Это больше монолит, он связан с учётом

53: Сотрудников, там приложение, в котором там есть и веб часть, и мобильная часть, в котором можно запрашивать там выписки. Там также ребята интегрировали чат бота, вот, чтобы там контекстным каким-то менюшкам попадать быстрее. Вот по стеку у нас был

54: 7 дотнет база данных postgres. Также мы использовали редис в качестве кэширования. Вот я тоже реализовывал эти моменты. Значит orm подход у нас был.

55: Какой инкью? Господи, заговорился. Екор у нас был, вот и совсем чуть чуть дапер где-то местами было. Также мы в целом, когда переходили с mc эскюэль на постгрес, примерно в этот момент мы отказывались от хранимых процедур.

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

57: Более наглядно смотреть какие-то запросы. Вот, но нам было так удобнее и команда не испытывала никаких проблем. И был 2 проект. Значит он связан был с тем, что, ну, его цель, да,

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

59: Посгрес, вот как собе точка ком собес станет пустяком, ребет подключённый, и мы это все разворачивали ещё на экосистеме росатома, то есть не у себя внутри. Вот, а в таком внешнем контуре. Вот будем говорить.

60: Quiver использовали docker, использовали как процесс миграции, например, проходил. Мы с помощью екора это делали, а когда мигрировали СМС скейл на постгре, то мы писали скрипт самописный.

61: Вот, и ещё там был механизм такой, что, я думаю, вы знаете, что в по, там разные тип даты. Вот, и на проекте мы ещё реализовывались.

62: В коде не переписывать там, ну а чтобы это делал дата интерсептор автоматически.

63: Угу. А ты, получается, на проекте? То есть сам какие-то фичи технически грумила, да, придумывал такое, что-то было условно. Ну да, какие-то идеи, идеи в 1 очередь были, да.

64: По поводу архитектуры не сказал. У нас была чистая архитектура, ну, луковая архитектура. Вот. То есть, был у нас, получается, уровень кора, там, domain аппликейшн, в нём хранились, ну, находились, в нём был, получается, уровень, инфраструк.

65: Структуры там у нас был далее, и всякие сервисы, там, ну, тот же, там реббит был, там, подключён, вот, и презентации, соответственно, там уже template, на котором писали.

66: Угу. А вот оба проекта в кубере, да, получается, были? Нет, только 1, который микросервисы, a2 как работал, a2 монолит, мы вот так разворачивали. То есть просто без оркестратора, да, он, получается, жил.

67: А в скольки репликах оба работали, я не могу точно сказать, не помню такой информации.

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

69: 2 образа там sdk и рантайм вот мы sdk билдили, вот, а в рантайме можно запускать, ну и в sdk можно запускать, но билдить только можно в sdk, вот и, значит, там.

70: 2 билда в итоге там назывались типа продакшн, там и дебаг условно, вот в прод у нас были только исполняемые файлы, то есть такой легковесный образ, чтобы там же разные слои есть у докер контейнера, чтобы в принципе не нагружать. Вот.

71: И, соответственно, там ещё копировали, там образы с помощью, там копии ран вот делали, а про докер, понятно. Вот мне просто для полной картины хотелось понять, вот именно как происходил диплой, как разворачивалось приложение. Понятно, что она в докере жила, то есть прост.

72: По сути, docker запускали, да? Или как? Да? А микросервисы там, типа, ещё и с помощью кубера. По идее, мы это делали. Вот. То есть, когда мультибилды делали,

73: А вот, а нагрузка была большая, небольшая, у нас не было тестирования. По крайней мере, я этот процесс не в принципе, нагрузка на сервис, вот от пользователей, это же для внешних пользователей, да, были для инженеров, которые работают внутри.

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

75: Или без проходило, то есть на время диплоя запросы там отваливались, или у нас ещё был сиайсиди самописный мы там сами его пытались развернуть в гитлабе в этом, в gitlab серанд.

76: Вот, но про про простое я не могу сказать ничего. Может быть, коллега делал. Я, соответственно, просто не знаю этого. Погоди, а смотри, ты же сказал, что у вас то, что монолитное приложение было, которое про

77: Работало. Вы, получается его на какой-то тачке запускали? Docker компо файлом или как? Ну да, да. Примерно так.

78: Угу. Угу. Понял. Спасибо. А в росатоме там кубер, да, их на их free, да, получается, конфигурили, вот этот, например, да, да, там ещё как раз-таки привлекали специалистов.

79: Чтобы помочь развернуть, потому что мы как бы хоть и являемся как бы экосистемой, но прямо такого определённого доступа прямого не имели. Вот. Поэтому они тоже нам помогали. То есть там не все процессы, мы были ответственны.

80: Ну окей, до кубера чуть позже дойдём, ещё обсудим. Так, ну тогда пойдёмте по темам. Вот давай про базы данных поговорим, начнём с них. Вот расскажи, с чем имел дело в целом. Каких

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

82: Индексами, то есть занимался там оптимизацией скель запросов, в принципе, не только индексы использовались, там разные стейтменты. Смотрел, как работают джоины, потому что бывало такое, что там есть лишние джоины, которые просто лишние данные нам подгружают в запрос. Вот.

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

84: Принцип. Ну ладно, принципе, наверное, можно опустить. Вот, ну, использовал разные уровни изоляций в 1 очередь, значит, был, наверное, был, наверное, случай, можно такой сказать, что

85: Необходимо было использовать андреита рит, уровень, то есть неповторяющееся чтение, он достаточно неплохой в по, то есть он, в принципе, по скорости быстрее, чем уровень сериалайза. Вот, но на нём там

86: Очень маленькое количество аномалий, только lost апдейт. Вот, и с помощью него мы, соответственно, обращались к контексту там базы данных и обновляли там какие-то действия. А вот расскажи, что это вот был за случай, почему вот именно он потребовался

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

88: Вот одновременных, а уровень более высокий. То есть редко метод, вот он не подходил за счёт того, что у нас на нём есть аномалии. Вот, и у нас в проекте так повелось, что мы использовали именно уровень

89: Получается on repeat не повторяющееся чтение ну то есть это получается на проекте, да, по дефолту такой, да, стоял а вот ты как-то, ну сам тебе приходилось использовать какие-то конкретные по каким т.

90: Причинам. Ну, я скорее сам разбирался в уровнях изоляции. Вот я понял, что в постгрес, допустим, нету уровня. Ритон, комитет, который самый быстрый, но там больше всего изоляций. То есть по дефолту, в принципе, большинство современных бд

91: Они его не имеют и соответственно выбор обычно между read committed и получается анреп абл рит вот ну наверное в собственных проектах я где-то использовал рит комитет когда там проверял там тренировал.

92: Вот, но уровень пиарит, как, собственно, показал себя на практике он достаточно быстрый, и там меньшее количество аномалий это оптимальный уровень.

93: Угу. Окей. А вот, а почему, кстати, вот, нету рит, нкомитет не вдавался в подробности, не могу сказать, но интересно, кстати, вот внутрянку особо не лазил, да, про, по, да, да, не могу.

94: Там ничего сказать такого. Окей. А вот именно по транзакции можешь какие-нибудь примеры привести? Вот что, какие операции были вот в рамках транзакции у вас выполнялись? Я точно помню, что

95: При уровне, получается, неповторяющегося чтения. Мы, значит,

96: Мы точно делали апдейты. Вот я это помню. Ну.

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

98: Сейчас.

99: Был, наверное, случай, когда мы вставляли, вставляли ещё данные, там, допустим, 1 таблица делает там селект, ой, господи, 1 транзакция делает селект по какому-то там столбцу, допустим, вот.

100: Там, условно 2 транзакция может сделать инсерт, вот. И, соответственно, у нас там идут коммиты. Вот, но как бы у репита рит есть плюс, что вот аномалия фантомного, допустим, чтения её как бы нет на на этом уровне уже, хотя как бы в классическом представлении.

101: Она на этом уровне должна быть, вот, и в том числе, поэтому тоже пользовались этим уровнем, потому что можно было безопасно как бы вставлять данные и не париться по поводу фантомного чтения. То есть там же телек, да, данные не вернул.

102: Не закомиченные в этом кейсе.

103: В этом кейсе скорее такой утилитарный момент то есть если б мы если мы абстрагируемся от поста, перейдём к классическому как бы представлению транзакций, то если б на этом уровне мы делали бы вставку из 1 транзакции а во 2 мы делали select поэтом.

104: Полю, то у нас как бы попадали бы фантомы. Вот, а так как на этом уровне, по сути, фантомное чтение не реализовано, его нет, подгр, то, соответственно, мы можем делать insert спокойно и не париться по поводу фантомного чтения. То есть был кейс, при котором вот нам надо делать вставку, но использовать там условно сериал Айза был

105: Мы не можем тут слишком медленно. Угу. Окей. Слушай, а вот в тему, к примеру, вот задачка такая, например, у нас есть приложение в 2 инстансах, да, работает. И, например, у них

106: В этом приложении есть какая-то фоновая джоба, да, которая периодически запускается, достаёт, например, из базы какие-то сущности и берет их в обработку. Вот у нас может быть много вот этих инстансов, да, реплик приложения.

107: Вот как сделать, чтобы инстансы не брали одни и те же сущности в работу, одни и те же инстансы? Во первых, ну, чем-то, наверное, похоже на какую-нибудь там транзакшн.

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

109: Одинаковых, допустим, там запроса на обновление, то мы берём именно последний. Вот, а остальные мы можем, допустим, просто хранить

110: А вот как бы ты сам запрос организовал?

111: Чтобы нивелировать то, что у нас могут быть там несколько повторяющихся записей. Так получается. Угу. Чтобы одни и те же, ну, например, так совпало, что на 2 инстансах одновре.

112: Но вот это выполнились запросы, да, на получение, но, ну, данных на обработку. Вот как, как вот так организовать? Скль запрос, чтобы исключить. Ну, надо, мне кажется, проконтролировать не дату, а

113: Айдишник, в 1 очередь, там нашей сущности, которые мы там будем там обновлять или там создавать, вот, и посмотреть по дате, чтобы нивелировать репликации. То есть приходит, допустим, несколько одинаковых там

114: Запросов там на апдейт условно на 1 айдишник. То есть у нас там какой-то сущность и её там нужно обновить типа 4 раза понятно, что там будет репликация вот соответственно, как-то подать, отследить, что вот не вот, вот на этих инстансах именно

115: 2 одинаковых Эскель запроса. Вот с одинаковыми условиями образовались то, что они запустились в 1 время. Вот, и надо так, чтобы в приложении 2, 2 приложения не взяли одни и те же именно элементы в работу. Есть идея.

116: Нужно сделать, продумать как-то с помощью согласованности, что? Ну да, чтобы у нас получается, получается, 2 инстанса не написали, они ничё не пишут, им надо просто селект сделать, достать и там че то уже делать с ними. Угу. Надо, чтоб красные достали.

117: А то, что там айдишники, даты, то есть это гарантий все равно не даст. Они, если в 1 время запустятся, они возьмут одно и то же.

118: Не знаю даже как не могу как-то ну ладно а про селект апдейт например что-нибудь слышал про блокировки ну да, чуть чуть чуть чуть про это слышал глубоко не Копал да, что тоже можно использовать select for update для того чтобы разблокировать нашу опера?

119: Сам не юзал, да, такое? Да нет, не приходилось такого. Не было случаев на проекте. Окей, давай про индексы тоже поговорим. Расскажи, какие юзал индексы. Ну, у нас есть, получается, кластеризованные и не кластеризованные индексы.

120: Авторизованные, они как бы 1 на таблицу, они хранятся там в наших данных, кто-то говорит в листьях. Вот, ну это 1 и тоже. И, соответственно, у нас есть не кластеризованные индексы, они хранятся, ну как бы в сводной, в сводном столбце около таблицы и, соответственно, являются ссыл.

121: На страницу вот я знаю, что есть индексы, которые основаны на би плюс дереве, и ещё, по моему, встречался с таким понятием, как широкое дерево вот мне лично показалось, что и peter.

122: Достаточно жизнеспособна. То есть там би плюс дерево, оно больше, больше в глубину будет, ну, в сравнении с широким деревом. Вот, и там ещё есть специфика, что отбрасываются значения там, которые меньше определённого. Вот.

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

124: Дерево вот использовал, бывают разные у нас индексы. Там можно, получается уникальный индекс навесить. Он бывает по полю unique сам автоматически появляется. Вот. Либо при форейн ключе, там тоже уникаль.

125: Index под капотом будет вот есть фильтр индекса, когда мы можем, допустим, там, условно на логин и пароль там накинуть. Ой, господи, составной индекс, составной индекс, когда мы можем на, там, допустим, какое-то выражение, там, на 2, там,

126: Столбца накинуть наш индекс на логин и пароль. Вот. Ну тут надо сказать, что логин будет как бы 1 будет ведущим и будет забирать 90% там ресурсов индекса. И, соответственно, если проверять с помощью эксплейн аналайз, вот, то мы там будем видеть разные

127: Разные поиски. То есть там либо индекс онли скан, либо индекс скан. А если мы, например, сделаем фильтрацию и по паролю и сделаем вывод по паролю, а логин, по сути, мы трогать не будем, там вообще будет секю скан. Вот.

128: И ещё есть, да, фильтр индекса, когда можем на какое-то там значение, там, на какой-то, where, допустим, накинуть индекс, вот тоже такой, такой специфичный кейс, но иногда используется

129: Угу. А ты вот на практике, б, 3, да, в основном, да.

130: Угу. А вот какие-то составные, фильтрующие, приходилось составные? Ну да, были случаи. Вот вспомнишь, как именно вот случай. Ну вот как раз-таки с логином и паролем был случай, что нужно было накинуть по ним. Часто там искали. Вот.

131: Нужно было ускорить, и если про фильтр говорить, тоже был такой специфичный кейс, было поле, которое может быть пустым, вот, и нужно было тоже ускорить, соответственно, поиск по нему, то есть если оно not null, то тогда мы его там находим.

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

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

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

135: Влияют вообще индексы как-то на производительность создания записи, например, я знаю, что если у нас есть, получается команда delete и у нас есть

136: Это и команда alter, вот alter у нас, когда мы удаляем там из таблиц какие-то данные, вот, то это как бы легковесное удаление без кэширования, без перестройки индексов и без перестройки триггеров. Вот в моменте. А если мы делаем delete, то там

137: Соответственно, при удалении всех данных будут перестраиваться и индексы в таблице, и триггеры будут срабатывать. Вот, то есть они в принципе влияют на производительность.

138: Угу. Окей. Вот ты ещее эксплейн упомянул. Расскажи, в каких случаях ты им пользуешься. В 1 очередь при оптимизации запросов посмотреть, как запрос выполняется. Там же есть, по моему.

139: Explain, аналайз, есть explain, вот разница там, вариации. И, ну, я, наверное, чаще, больше использовал именно эксплейн аналайз. Вот удобно посмотреть время выполнения, тип запроса, то есть там, как он выполняет

140: Там последовательно или у него есть там индексы, там индекс скан, индекс онли, скан. Вот. И в принципе это достаточно интересная работа, когда ты занимаешься оптимизацией запросов, то есть можно на какие-то там специфичные столбцы навесить индексы, вот применить составной индекс. Вот.

141: И плюс посмотреть в целом, как выполняется запрос. А чем они отличаются от эксплейн. Нас эксплейн, по моему, 1 показывает, 1 показывает, по моему, время там выполнения, a2, по моему, не показывает. Вот.

142: Либо это скорее связано с тем, что 1 выполняется в таких более тестовых условиях, a2 прямо практически выполняется. Могу ошибаться. Но, по моему, в целом так.

143: Угу. А ты вот вообще с табличками какого объёма работал? Ну, там, наверное, были большие таблицы. Ну, у нас, в принципе, база данных была, там 2, там, 3 петабайта, то есть таблиц было много по объёму.

144: Я даже сказать не смогу, там сколько строк и так далее, не видел этого.

145: А с блокировками связывал, сталкивался. Нет, с блокировками не сталкивался. Конкретно знаю только про блокировки, которые на уровне серела был, ну, условно, про логи, которые внутренние. Вот при блокировках именно не сталкивался, но

146: Слышал про них тоже немного. А как вот делали миграции на такие большие таблицы? У вас какие-то были правила? Мы, мы с помощью екора накатывали миграции. Вот и был просто кодстайл на проекте. Как наименовать?

147: Миграции. Вот, а при миграции может вообще табличка заблокироваться, например.

148: Может ли заблокироваться?

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

150: То есть миграциями, получается, при релизах не разработчики, а девопсы, да, у вас занимались? Или, да, сами, да, девопсы занимались? Вот. Угу. Окей. Ну, я просто знаю, да, что вот с помощью именно Евко это делали, там не как-то.

151: Другому не самописно.

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

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

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

155: Да, много весит. И вот как нам это сделать? Провести такую миграцию, чтобы юзеры не почувствовали. То есть без простоя, как бы ты, по моему, это делается в несколько этапов, по моему, в

156: 4 этапа. Вот в целом нам нужно как бы создать новую таблицу, потом занести в неё там все данные. Вот. И потом, соответственно, уже сделать мягкий переход на неё.

157: Вот если я правильно понял вопрос.

158: А вот подетальнее, если пошагово.

159: 1 релиз, что ты делаешь? 1 релиз? Для начала надо создать таблицу. Последний, последний релиз. Это мы уже получается. То есть 4 мы уже, получается, меняем нашу как бы моковую таблицу.

160: Какую таблицу? А которую мы дополнительно создали. Не, вот давай вот именно конкретно, как бы ты это делал не 1 и последний дела. Хорошо. Какие изменения в начале бы создал таблицу. В любом случае дальше получается нас

161: Этапе уже бы. Ну вот смотри, 1 рейс создал таблицу.

162: И как это это release, да уже ну ладно, сбил, наверное.

163: Ну хорошо, я пытался бы для начала составить таблицу. Нам же нужно, получается, новую таблицу сделать и отказаться от старой. Сделал, сделал бы новую таблицу, перенёс бы потом туда дан.

164: Вот сделал бы с ней там какие-то тесты, чтобы проверить что все работает вот и далее соответственно сделал бы уже release вместо той которая работает у нас. Ну ладно, окей, так по базам наверное.

165: У меня все, Кирилл, хочешь? Слушай, да, я хотел ещё спросить. Ты сказал, что у вас использовался уровень репита рид. Я хотел спросить, во первых, он у вас устанавливался глобально на базе на уровне базе данных.

166: Или вы индивидуально в каждой транзакции это указывали, мы индивидуально в каждой транзакции указывали. Вот. И транзакции мы оборачивали обычно в using ещё

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

168: Использовалось. Вот, то есть для, для всех абсолютно там, не знаю, там селектов нет.

169: Угу, хорошо, а ты знаешь какой уровень дефолтный уровень изоляции на or read committed соответственно, так как у нас ритон комитет нет.

170: Угу. Ладно, ладно. Ну давай, наверное, двигаться дальше.

171: Так, орём, давай перейдём тогда. Угу. Тоже. Вот расскажи, с чем работал сейчас, о, какой опыт в целом опыт в целом, да, больше по ефу, совсем немного встречался с дапер. Нравится больше работа.

172: Сефом, потому что, во первых, там есть такие вещи, такие вещи, как методы расширений. То есть есть операторы и методы расширения, которые мы там используем вместе с ефом. Нравится использовать больше именно методы расширения, потому что это удобно, это легко читается по точке вызывать какой

173: То метод там инклюд, допустим, тот же самый, вот, и, в принципе, работать с базой данных с помощью рем тоже очень комфортно, потому что у нас, ну, допустим, при инклюде у нас есть как бы 2 режима. 1 Лев джоин под капотом, если у нас

174: Фрейн фрейн кей может быть может быть null принимать. То есть он налал, типа, если он не может быть налол, типа, вот, то он, соответственно будет у нас как inner join под капотом. Вот. И также можно в принципе сделать иннерджоин с помощью селе.

175: Групбай, насколько мне известно.

176: И про чинч, трекер там могу тоже рассказать, если необходимо, давай. Ну, в целом у нас чинч трекер работает очень интересным образом. То есть при запросе из базы данных он, ну, сканирует, отслеживает состояние там соответств.

177: Там edit, там deleted, мотифай, вот, и потом, когда мы делаем какие-то изменения в коде и допустим у нас нету, но трекинг то мы соответственно можем.

178: Мы, соответственно, можем при вызове ченджес у нас вызывается под капотом чейндж трекер проверяет стейт, если все окей, то там сохраняет, модифицирует или удаляет. Если применяем из no tracking, то просим не отслеживать и в принципе можно, допустим, выбрасывать данные там в

179: Минку. Вот, и они как бы изменяться не будут. Вот мы просто их будем читать. Либо при get запросах это тоже можно делать. Вот, чтобы не нагружать, потому что там есть разные паттерны. Скьюс, медиатор тоже вот с этим работают и

180: И есть ещё, по моему какой-то метод у, сейчас не вспомню как называется, но помню, что он делает там можно, по моему только по айдишникам трёкать.

181: Угу, то есть, а как он у вас был настроен через трекер?

182: Ну, мы, получается, get запросы не отслеживали. Вот, а все остальное.

183: Вообще у нас был реализован именно secure медиатор паттерн, то есть у нас там мы делили на команд и на квери вот квери у нас, получается, get был, и мы как раз-таки вот его не отслеживали, а команд там insert date.

184: Мы, соответственно, их отслеживали с помощью трекера. Вот. То есть вы по месту, да, вот по месту вызова уже писали, но Трёкин, где это не нужно, да, например, да, по дефолту включён, или как? По дефолту ли был включён, что ещё раз?

185: Change трекер.

186: А в каком смысле? Ну, там его можно глобально отключать или по месту? Вот. То есть, глобально он у вас был включён, правильно? Да, отключали его, получается, по месту. Угу. То есть, вы на, на

187: На курях у вас, получается, вы по месту отключали, а на командах просто он включён и включён, да? Да. Угу. А вот

188: Такой микро топик. Вот ты про медиатор сказал. Ты как сам думаешь, для чего вообще? Как, в чем ты видишь пользу медиатора? Ну, сам дб контекст, он, во первых, не потокобезопасный, и хорошо было бы разделять операции, чтения и всего.

189: Остального. Вот, то есть, грубо говоря, чтобы разделить эти операции. Вот. Ну, то есть это такая метаморфоза, когда мы их разделяем, да, там на команды, на квери, по факту, то у нас дб контекст, он 1, вот просто эти операции, они

190: Разделены, по моему, вот для этого этот паттерн секьюре медиатор делается, чтобы разгрузить дб контекст. То есть он у вас чисто для дб контекста был сделан. Ну, скорее всего, да, я

191: Как бы не, я принимал решение об этом паттерне. Вот, поэтому не могу сказать хорошо. Так вот, получается ты тут, нет 7, да, у вас был и core 7, соответственно.

192: Помнишь, может, что вообще нового появилось в core 7? Вы, может, юзали что-то новое из обновления? Новое, наверное. Нет, не юзали. Так, если вот знакомился с 8 версией, там у нас как?

193: Как раз-таки набл, типы были, вот, то есть теперь не надо прописывать, допустим, в модельках, ну, энтити, там, ну, задавать какие-то дефолтные значения можно было, там проверку на null сделать в 7. Нет, наверное, какие-то ни

194: Альных функций не знаю.

195: Ну, может быть, знаю, может быть, работал с ними сейчас просто не вспомню, потому что я с 6 не работал, и мы с 3 версии неткора старенького перешли на 7.

196: Вот в корее есть разные подходы, как генерить этот контекст. А контекст там разные фабрики для пула есть. Вот че-нибудь такое смотрел? Может, пользовался, настраивал, нет.

197: Я про ивкор скорее знаю там про подходы там code first date first model first про вот именно pull pull хотя нет, я, может быть, слышал про это да, говорили ребята, но нет, не углуне.

198: Не углублялся сильно в эту тему угу. Пользовались какими-нибудь фичами типа jason или, например, встроенного там массива встроенного массива точно не было по поводу?

199: Jason тут спорно был, там когда мы микросервис писали, мы транзакшн бокс делали и у нас там в виде джейсона хранились как раз-таки вот в аут бокс тейбл либо там там ретрай, там task тейбл там.

200: Джейсон би. Да, по моему, джейсон by мы хранили. Вот, то есть там были записи о том, в какие там сервисы нужно будет отправить уведомления. Ты, ты с этим дело не имел, да? Ну, именно с json би нет, то есть я

201: Знаю про этот паттерн. Я видел, как его реализовывали, но я его не писал. Угу. А вот про миграции расскажи, вот процесс, как у вас было это устроено подробнее?

202: Ну, были релизы, вот. И у нас накатывались миграции с помощью екора. Ну, то есть, вот тебе задачка, да, пришла, тебе надо че то в табличке сделать, ты просто по сути, что

203: Происходило, а в этом плане, ну, тут необходимо было связаться с девопсами. Вот. И ребята нам зачастую помогали, вот pre там, изменении каких-то данных.

204: Ну то есть ты, ты, ты общался с ними, договаривался о том, что вот там изменились какие-то условия, тебе нужно там сделать какие-то изменения, там, дополнить таблицу, вот, или вот там вообще она будет по другому выглядеть. Вот. И, ну, то есть, подожди, а миграцию не ты создавал, получается?

205: Они или как да они получается когда понимал что нужно что-то поменять ты с ними связывался и они они типа sea знали да они то есть тоже да они там миграцию или как да они там ещё health check.

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

207: Здесь ребята знали сишарп, они чуть чуть были, в этом интересно. И они прям все менеджели, да, все миграции, ну, насчёт всего я не скажу, не следил за их работой. Детально. Вот. Но, да, в целом миграциями занимались они

208: Они все-таки вот эту миграцию они в твою ветку пушали или как? Да? Угу. Ясно. Окей. А так вот слышал какие-нибудь про какие-нибудь функции? Аля сплит, сплит кэри?

209: Её знаю, зачем они нужны. Нет, не знаю, не слышал об этом.

210: И, наверное, не слышал про вот декартово перемножение сущностей в её такой баг тоже, да, в целом про декартово произведение знаю, но именно нет. Ну.

211: Ну, погнали тогда дальше. Давай про, если у кирилла нет, нечего добавить, то погнали дальше про очереди поговорим.

212: Тоже расскажи, с какими очередями, брокерами, сообщениями работал. Я работал с rabbitmq. Вот нужно было реализовать 1 механизм, когда можно было репорт отправить, вот, и в том числе

213: Нужно было отправлять уведомление в брокер. Вот я там это реализовал с помощью, получается, дайрект режима. То есть, когда мы эксчендж напрямую с помощью роутинг кея привязываем к её. То есть надо, чтобы роутинг кей совпадал с биндингом. Вот.

214: Ну, знаю немного про другие режимы, там, про, там фанат, там топик хедер, вот Леттер. Но конкретно я вот именно такой механизм реализовывал на проекте.

215: Угу. Окей. А слышал что-нибудь? Получается, у вас был rabbit? Да, чуть чуть про каску сам знаю, тоже. Можно чуть чуть поговорить про это. Не интересно больше, с чем ты работал.

216: Раз ты с ребитом работал, слышал что-нибудь про гарантии доставки сообщений? Ну, у нас там можно очередь, а?

217: А это скорее про режимы типа там at least one at most Ван как в кафке или про сохранение сообщений в очереди то есть у нас же очередь там может быть трен сент, а может быть дюрабл вот там если дюрабл, ну скорее 1, скорее 01.01 а, окей.

218: Ну да, слышал про это вот, как бы, да, 2 разных режима. 1 доставляет не более 1 раза. То есть, грубо говоря, 0 или 1. Вот. A2 режим он как минимум 1 раз доставляет, но и нагрузка, соответственно, у них разная у вас.

219: Ну как настроен брокер на такой режим у нас был, господи, отмост вас. То есть как минимум 1 раз. Вот, и как-то ещё.

220: Реализовывали на проекте механизм с как минимум это tlist скорее at least ты имеешь ввиду это мост.

221: Это мост, это, господи, все, да, я плыву сегодня, а как минимум 1 раз. Вот, значит, ещё был механизм на проекте реализован, но я про это тоже конкретно не встречался с этим в работе, когда мы работаем с

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

223: Как раз-таки и этот механизм как-то реализовывали ребята на проекте, когда, ну, контролировали по дате. То есть, самое последнее сообщение его как раз-таки и брали в работу. Вот, а все остальные, по сути, не учитывали.

224: А ты в детали не вдавался, да, по сути, вот не имел с этим алгоритмом, именно с импотентностью. Нет. Вот как, как этот процесс реализуется? Не имел. Не выпали мне такие задачи, к сожалению.

225: Угу. Окей. Давай тогда че, наверное, к дотнету перейдём. Кирилл, как думаешь? Окей, давай про дотнет расскажи в целом, с какими версиями дотнета работал?

226: Следишь ли за обновлениями? Может, кого-то смотришь, читаешь? Ну да, в целом работал, вот в коммерческой вариации, с 3 версии, вот с неё начал карьеру. Ну да, она была старенькой, потом 7.

227: Версии, взаимодействовал в коммерческом опыте с 6 и с 8 версией работал, но не в коммерческих проектах. Вот, скорее, там, в своих собственных. И ещё был, было знакомство с, по моему, 5 версией.

228: На неткора, когда у нас там ещё был даже предустановленный файлик стартапа. Вот, и у нас получается программ сиис был как раз-таки разбит вот на 2 компонента. То есть это ж, по моему с 6 версии пошло, что у нас стартап убрали и у нас только

229: В котором все зависимости прописываем, подключаем. Вот. Ну, если говорить про тех, кого смотрю очень давно, я знаю такого человека на YouTube программ мысли, там мужик там, в Канаде живёт, рассказывает про рынок, про it. What интересно послушать, он

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

231: Угу. То есть вы на работе условно, сейчас на 7, да, версии? То есть вы не по тсам прыгаете, а прям на каждую обновляетесь. Ну да, грубо говоря. Так выбрали именно 7. Такой вопрос часто встречается, когда спрашивают, а почему не 6?

232: Long term support, да? Ну вот решили на 7 перейти, скорее всего, потом перейдём где-то там на 10 в будущем, если она будет long term, ну и так далее. Вот если вот про фичи говорить, ну там современного оо точка ком.

233: Полюбит вас тайком ну, скорее то, что давно уже появилось ну так вот, развивается вот про null reference type. Вот что думаешь, как они тебе помогают, не помогают, применяете? Нет, пользуетесь.

234: Ну, набл, тип, это интересно, это, это действительно, ну вот с null типами, скажем так, это некий синтаксический сахар, вот с ним, с ним удобно работать, можно инклюды писать тоже удобно, то есть он как бы, и в режиме

235: И join join. Работает вот с референсом. Не знаю, может быть, я путаю что-то, вот именно эта фича, да? Null, reference. Типа. Угу. Вот именно разметка, вы ей, я так понял, не пользуетесь? Нет, не пользу.

236: Ни разу, я слышал ещё по помню, что вот как раз-таки в новом там рекорды появились. Ну, в новом, это в 8, я имею ввиду, потому что 9 как бы, ещё вроде как не вышел вот рекордами. Ну, сам пользовался, да, прикольный инструмент. То есть теперь дтошки можно писать не классами, а вот именн.

237: Рекордами и там уже суть в том, что в конструкторе сразу создаётся типа все значения там под капотом вот нам не нужно переопределять там ничего вот ну не лезть там в этот интерфейс акаб по моему и там хэш код переопределять то есть рекорды такой интересный инструмент.

238: Вот, но он именно, по моему, 8 появился. Угу. А вот если говорить про кор, там есть такая штука, план факторе. Вот знаешь, зачем её добавили? Она какие проблемы решает? Да, пару раз, мне кажется, я с ней встречался, она

239: С тем, что мы можем правильно распределить пул как раз-таки вот http там сделать его под, под ключ, вот там, там заголовок, там опреде.

240: Вот, там, ну, другие какие-то элементы. То есть в целом это нужно, когда у нас, допустим, есть, когда мы делаем апи для каких-то сторонних сервисов. Вот, и, соответственно, нам необходимо для того, чтобы, ну, скажем так, грамотно расходовать наш

241: Paul вот использовать аштипи клайн фектори.

242: Угу. Окей. А так, в целом по языку про тулзы какие-нибудь приходилось ли тебе может анализировать какие-то утечки памяти? Исправлять?

243: Оптимизировать приложение, может падало из за что-нибудь такое делал. Был случай, когда вот там нужно было, там был сервис, который читал данные из файлика. Вот, и у нас там

244: Это все было обёрнуто в using, но каждый раз, когда файлик читался там, записывал, что-то закрывался. Все равно у нас была утечка памяти, то есть, грубо говоря, если смотреть через профиль, профиль,

245: В общем, если смотреть через, через

246: Ой, заговариваюсь, в общем, профилировщик памяти, то там 1 значение в диспетчере задач, оно было другое. Вот это всегда настораживает, потому что, ну, как у тебя получается, там 4, а тут, допустим, 8 у тебя где-то 4 просто, ну, просто болтается, да, и оно так.

247: Увеличивается со временем. Вот, ну, в целом, если там подумать с тем, как у нас работают управляемые неуправляемые ресурсы, вот, и там, допустим, какая-то какая то какая-то там библиоте

248: Там, ну, допустим, может быть тоже не всегда управляемым ресурсом. Вот. Поэтому это надо контролировать и там прибегать к диспос паттерну, вот, либо там ворачивать юзинг и, в принципе, следить за этим.

249: Угу. То есть, вот, по сути, вот 1 кейс такой условно был, да, из примеров. Так, в целом все было норм. Ну, в целом, да, я не видел никаких проблем. Может, они, конечно, были. Ну, просто был случай, когда на сервере прям, прям, очень.

250: Много кушала памяти. У нас разработчик ушёл в отпуск. Вот. И, собственно, ему звонишь в отпуск, говоришь, дружище, вот у нас там сервис падает, девопсы его там каждый день перезагружают, как-то там проблему решить может быть что

251: Не указал. Ну, 1, там, using, я там не забыл, не забыл. Вот, соответственно, нужно, нужно было заглядывать именно в нет, библиотеку, вот, которая мы там использовали, и смотреть там по документации, ну, тоже по

252: Нас это много может быть, времени уйти. Окей, про и что-нибудь слышал такое из последнего? Нет, не слышал, что это такое?

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

254: Угу. Вот у меня, наверное, все тот, кириллу передам слово, да. Так, ещё пока не сильно общались. Давай я тебе немножко общие вопросики позадаю немножечко. У меня, знаешь, такой сначала вопрос. Я почитал твою резюмешку. У тебя там

255: Написано было, что ты завозил в проект аутентификацию, можешь конкретнее рассказать какую именно стандарты, какие, как это вообще было реализовано ну вот у нас использовался на проекте именно jwt токен вот.

256: Угу. И соответственно там мы реализовали механизм на основе, там политик, вот, то есть прокидывали политики в атрибуты и на основе них у нас там была авторизация, если говорить про базу jwt, то у нас клиент сначала.

257: Проходит процесс идентификации, потом аутентификации и авторизации. Ну так, если последовательно, да, то есть сначала мы там проверяем логин, потом пароль и, соответственно, потом, если все окей, то доступ ему даём, вот выдаём ему, соответственно, токен 2 токена.

258: Там access token, refresh token вот рефреш типа хранится у нас для того, чтобы обновлять access token, когда истечёт значение вот, ну и с помощью аксесса дальше уже пользователь работает с нашими сервисами, такая базовая была.

259: Я понял. Слушай, давай начнём, наверное, раз ты сказал про рефреш токен. Какой у вас был лайфтайм токена?

260: По моему, он был там неделю, если я не ошибаюсь, через неделю он истекал. А ты как считаешь, это хорошее время жизни для токена? Неделя, мне кажется.

261: Кажется, нет. Мне кажется, это, это большое время. Можно и там несколько дней сделать, допустим,

262: Скилл завис. Похоже, я отвис немножечко. Да, действительно, да, действительно, залагало чуть чуть. Так, ещё раз можно. Ты сказал, что неделя это перебор? Да, да, неделя, это много можно сделать поменьше, хотя

263: Хотя я где-то видел проекты, там и 30 дней токен живой. Ну а почему ты считаешь, что неделя это перебор?

264: Ну, мне кажется, что если пользователь там пользуется сервисом, допустим, не часто, не каждый день, то лучше почаще обновлять токен.

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

266: Ставится время жизни токена очень коротким в идеале там 10 минут 15 максимум, чтобы за это время у тебя токен не утёк можешь тогда рассказать почему вообще выбрали ты сказал, что у вас jwt токен вы?

267: Получается, стандарт open 2 0 использовали да не знаю, про это реализовывали я не реализовывал не знаю, не могу сказать, я понял, а почему именно использовали jwt почему, допустим, не basic это просто.

268: Оказалось команде самым таким простым базовым элементом, который просто работает простым. Ну, я слышал про k рок, там, по моему, ещё такие вот вещи есть, но нет, у нас были ага, а у вас задача была просто, чтобы

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

270: Попробовать сейчас взломать её, если вы уже знаете целевую систему, что у нас там 7 дней токен живёт.

271: Я понял. Ладно, хорошо. А можешь рассказать, тогда, как у вас на проекте велась работа с исключениями? Ну то есть у тебя есть приложение, у тебя может там, условно, база данных моргнуть, может там прийти какой-то невалидный ответ?

272: От сервиса, как обрабатывалось исключение вообще. Ну так, если говорить по факту, то вообще любые исключения, как мы обрабатываем, сначала более конкретные, потом более общие. Вот если говорить про факт именно

273: Нашей разработки. У нас был логгер. Вот мы это делали с помощью логгера. И, соответственно, там есть разные разные уровни там или разные этапы. Я, прости, перебью тебя. Смотри.

274: Ты говоришь про логирование, а я говорю, именно отлавливание сообщений. Ну то есть, смотри, ты получил 400 ошибку, допустим, от сервиса, от внешнего. И у тебя, ты там пишешь инорс, экс статус, код, пытаешься убедиться, что

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

276: Значит, у нас ещё на проекте были такие вещи, как прометеус и графана вот с помощью них тоже можно было посмотреть разные метрики. Там метрики на запросы были, немного использовали опен.

277: Телеметрии, если я не ошибаюсь. Угу. Вот. Через них как-то мы отлавливали там разные, там, http, допустим, ошибки. Вот, если именно говорить про такие, как не внутреннее там, логгирование или какие-то просто банальные кетчи. Вот, а именно с помощью вот.

278: Прометеуса и графаны. Ну, больше даже графаны то, что можно было этот dashboard настроить, типа под себя, и это более удобно, чем в прометеусе смотреть. Угу. Угу. Ладно, хорошо, давай.

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

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

281: Machine это по сути как бы интерфейс конечного автомата, там 2 метода типа move next, то есть каретку мы двигаем в нашем конечном автомате и соответственно сама стоит машина, то есть там ай стоит машин, и если говорить прям под про реализацию под капотом, то у нас там есть типа свиче.

282: У нас есть приватная интовая переменная, и у нас там есть авейтером, вот в зависимости от режимов срабатывают авейтером, есть дефолтные значения. Вот, ну и так далее. Плюс ключевые слова иовейт, которым мы ещё помечаемом

283: Вообще, про какие примитивы синхронизации слышал, с kimi может быть работали, ну вроде как они называются гибридами и пользовательскими, да, лог монитор по сути лог это как бы просто api над монитором, да.

284: Вот. Также у нас есть мьютекс. Мьютекс отличается от лока и монитора в том, что, во первых, он знает про другие процессы в нашей среде. Вот, и, соответственно, он работает в одноканальном режиме. Вот, то есть он все равно

285: Работает внутри как бы процесса с потоками, но он знает и про другие процессы, по моему, тоже. Вот, а семафор тоже, он компетентен про то, что происходит вне этого процесса. Вот он это видит, но его отличие от ньюток а в том, что можно в конструкторе указать нескольк.

286: Потоков, которые могут одновременно в критическую зону попадать. Вот, и также можем работать в режиме мьютекса. Вот ещё есть такая вещь, как spin Вейт. То есть слим версии примитив синхронизации. Вот они обращаются в spoon Вейт типа в очень быструю там очень быстрый

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

288: Ядро все равно обращается к ядру. Вот, а несли версия, они сразу идут в ядро. И там ещё я знаю такую, по моему, вариацию, что вот монитор монитор, он на самом деле гибридный, то есть он и может и через ядро, и через вот, по моему, спин Вейт запускаться или какой-то другой похожий механизм. Вот, но

289: Монитор, по моему, тоже гибридный.

290: Угу, хорошо. А давай такой вопросик. Вот ты сказал, что есть примитив синхронизации лог. Его можно использовать в синхронных методах внутри авейт не надо делать.

291: Не надо. Ну, внутри лока авет делать не стоит, иначе поток может вернуться с авейте, типа в лог и будет дедлок.

292: Угу. А у тебя такая программа вообще запустится? Я думаю, что компилятор покажет ошибку.

293: На самом деле, да, компилятор покажет ошибку, ты просто не сможешь. А программу даже. Слушай, ну, наверное, у меня по шарпу тоже. Все. Давай теперь, наверное, если у серёги нету вопросов, мы можем на твои вопросы.

294: Отвечать там, типа компании. Угу. В целом, че тебе интересно? Вот. И после этого, если что, к тебе Настя вернётся уже с обратной связью, там в течение 1, 2 дней обычно это происходит. Вот, да, хорошо.

295: Давай вопросы, как, в принципе, устроена работа в команде? Какие команды бывают по размеру? Вот какие у вас там, не знаю, концепции вы используете. Слушай. Команды по размеру очень разные есть, я знаю, команды 3 человека там.

296: 4. Есть команды побольше. У нас команда, например, по моему, 19 человек. У серёги немножечко поменьше. Вот в команде, соответственно, есть тестировщики, разработчики, фронты, бэкенды, тестировщики. Я сказал уже, да, продакты, аналитики.

297: То есть, как бы полностью такая автономная команда, которая работает над каким-то своим продуктом, а у нас нет в команде, у вас разработчики пишут, сиди там, да, да. Диплоя сами миграции наказывают, сами следят за отказом.

298: Устойчивостью. То есть у нас точке инфру девопсы предоставляют, ты ей можешь пользоваться, но ты сам лучшие практики выполняешь, то есть сам ответственный за количество реплик приложения, как оно выкатывается за хелсчеки в кубере и так далее. А вот вопро,

299: Вопрос такой, сколько в целом времени там по задачам уходит на девопс и на все остальное?

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

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

302: Пишешь, что там для него ты все подготавливаешь 1 раз и потом в процессе уже пользуешься. Вот, ну, это все надо познать, да, и чтобы себе же легче жить, жизнь обустроить, там, чеки поддержать.

303: Далее, ну, это интересно. Хорошо. Вот по методологиям. То есть у нас скрам канбан, то есть команды сами решают в определённый момент, они могут по скраму работать, потом у них какая-то большая история кончится. Могут по кан.

304: Bonu там, тут, тут по разному.

305: Нет, хорошо, жёстко. Вы используете и кафку, или и rabbit, или только кафку?

306: У нас на самом деле ребит от инфраструктуры предоставляется, вот, вот кафка есть в отдельных командах, но там ребята сами её поддерживают, она там исторически, может, где-то есть ещё, но от неё переходят.

307: На общее токовский реббит. Вот. Угу. Понятно. И, наверное, под капотом кафка у нас в инфре используется для общей шины, но ты с ней дела не имеешь. Вот. Угу. То есть даже мы там, ну, не обращаемся к ней никак.

308: Там через api все понятно, хорошо. И, наверное, последний вопрос, что больше используется там ддд, тдд? Вот по любому же нет. То есть ты принимаешь решение лично своё.

309: Ты сам можешь, ну, с командой посоветоваться, там, ну, в зависимости, какой проект, ты там его видишь и адаптируешься к нему. Если ты там, ты там лично сам новый проект пишешь, ты уже принимаешь решение. Вот такого нет.

310: Требования от. Угу. Ладно, мне все понятно, у меня вопросов нет.