Короче, надо читать книгу самому, сколько участников, столько и мнений... Все поняли книгу по разному
@maxarshinov4 күн бұрын
Хочу дополнить свой ответ про общение архитектора и команды, потому что во время стрима выразился неточно и поэтому идея может быть неверно истолкована. Я за то чтобы у любого senior+ специалиста была его зона ответственности (accountability, а не responsibility) и одновременно свободны в принятии решений: тимлид лучше знает как настроить Jira, техлид - как проводить код ревью, архитектор - как построить отказоустойчивую систему. Все эти специалисты должны быть вольны в том, как они организуют процесс принятия каждого конкретного решения: для особо важных может быть полезен консенсус (если достижим), для вкусовщины - голосование, в случае нехватки времени или когда ответственный специалист абсолютно уверен в своем решении и обсуждение не требуется - директива. У каждого такого специалиста (включая архитектора) должно быть право последнего слова, но и ответственность за это решение он(а) долж(ен/на) нести лично. В случае конкретно с архитектором, я считаю, что архитектор - это законодательная власть, а тим/техлид - исполнительная. Архитектор принимает “законы” (какие фреймворки, базы данных, паттерны интеграций использовать), определяет критерии качества системы и тактики для их достижения. Тим/техлид используют артефакты, созданные архитектором, в качестве “законодательной базы” и следят за соблюдением правил. Архитектор, наряду с тим/тех лидами, в том числе ответственен за регламенты. Все эти специалисты должны делить регламенты на обязательные (чётко сформулированы и строго обязательные для выполнения) и рекомендательные (гибкие и могут быть адаптированы в зависимости от ситуации, как пиратский кодекс). Чрезмерное количество обязательных регламентов может привести к бюрократии и утрате гибкости, а отсутствие четких регламентов - к хаосу и неэффективности. Оптимальный баланс между обязательными и рекомендательными регламентами помогает организации быть и эффективной и адаптивной.
@oleksandrivashchenko79165 күн бұрын
Лайк, підтримка, коментар
@user-sk4tg2xk5w6 күн бұрын
Шляпное обсуждение главы, тема вообще не раскрыта. 1Сник интерные вещи рассказал, зачет.
@goolosli861422 күн бұрын
Не о чем
@GLUCKKKKKKKKKK27 күн бұрын
Супер!
@gurgen521727 күн бұрын
Мужик, это супер. Чтение и разбор литературы с более опытным коллегой это очень ценно.
@maksimrybalkin856528 күн бұрын
Приведу пример read-uncommited проблемы, т.к. здесь ее не совсем корректно описали Воспользуюсь тем же кейсом - 1000$ + две попытки добавить по 100$ 1) открываем транзакцию, апдейтим значение на balance = balance + 100$, не коммитим 2) открываем вторую транзакцию с read-uncommited уровнем и читаем значение баланса - оно 1100$ (прочитали незакомиченный апдейт из п.1) 3) откатываем первую (представим, что там соединение разорвалось) 4) в транзакции из п.2 апдейтим на прочитанное значение + 100$ 5) коммитим вторую транзакцию и получаем на счету 1200$ поздравляю, вы подарили клиенту 100$ как извинение за разорванное соединение :D
@apostnikovАй бұрын
Это было интересно, как минимум освежить)
@basimal-jawahery5688Ай бұрын
Мне кажется, что для тим лида первичнее будут управленческие навыки. ВИдел много хороших лидов, которые вообще не программировали. т.е. когда-то они писали код и сорее всего были сильными синьорами, но сейчас и последние несколько лет работы лидами они могут не программировать вообще, но при этом все же хорошо ориентируются в коде проекта. (это видно на онбординге и кодах ревью).
@DmitriyKolokotАй бұрын
как проводить валидацию на бэке, как выглядят ошибки на фронте, как проводить валидацию вложенности и как оно отображается (к примеру на ноде из коробки) если скорость падает в 3-4 раза, при тюннинге - в 2 раза, какой смысл? можно ли делать параллельные запросы? можно ли использовать в хайлоад проектах? я так понимаю, что по памяти будем хорошо проседать для всех переборов; и для переборов N+1, когда можно было бы ускорить обычным REST-ом и узкими запросами к БД-ым пока не вижу выгоды писать на графе. мало было бэка в видео, в основном клиентская часть; ново, модно - но не практично для высоконагруженных проектов
@glebbondarenko67Ай бұрын
Спасибо Дмитрий за вопросы, постараюсь на них ответить - GraphQL runtime в основном проверяют правильность названий fields/queries. Вся остальная валидация делается руками. Одной из особенностей является то, что вне зависимости от результата запроса HTTP code 200, а в теле уже json с полем error или errors (тут правил нету) - Как вы правильно заметили GraphQL не ускоряет отдельный запрос, а упрощает работу с множеством запросов - Queries делаются параллельно, а Mutations последовательно - я бы не рекомендовал использовать в highload проектах - да, GraphQL использует RAM для хранения промежуточных результатов - благо N+1 проблема решена при помощи паттерна DataLoader. В одной из своих статей я даже разобрал как он работает в NodeJS: dev.to/bhleb/delving-into-the-black-magic-of-graphql-dataloader-pai
@user-br4gt7xu2jАй бұрын
с Java на Node.js..... соболезную, бро😰
@lappi_wojakАй бұрын
оба говна ))
@basimal-jawahery5688Ай бұрын
Спасибо Юра, очень прикольно про создании матриц компетенций.
@basimal-jawahery5688Ай бұрын
Много процессов на одной машине не будет распределенной системой, хотя и есть многопоточный/многопроцессный race conditioning. Потому что есть единый координатор ввиде ОС, которого нету у распределенных систем.
@StanislavLiashkovАй бұрын
Спасибо за подготовленный доклад, было интересно)
@fightspace9822Ай бұрын
Спасибо!!!
@banzaikaАй бұрын
ваши видео без хорошего микрофона - просто мартышкин труд
@followdarko2 ай бұрын
Спасибо за разбор! Без миро схемы сложно следить за происходящим(
@webdevkz2 ай бұрын
👍
@dimitryrusu40222 ай бұрын
А что за книга
@user-bu9rz6pf8h2 ай бұрын
Martin Kleppmann "Designing Data-Intensive Applications"
@dimitryrusu40222 ай бұрын
@@MidG-fe5hx ахаха
@jok5762 ай бұрын
Прям очень круто, спасибо за вебинар
@maksimrybalkin85652 ай бұрын
Спасибо за выпуск ПРО КНИГУ и за пояснения. Куда лучше предыдущего
@user-jt9ql8lo6s2 ай бұрын
плохо, не понравилось
@ProstoyRu2 ай бұрын
Отличный ролик! Много полезной информации. Спасибо! 👏
@maksimrybalkin85652 ай бұрын
Я один не услышал обсуждения КНИГИ? Все видео обсуждают опыт других людей, и в каком-то несвязанном стиле
@user-ze5dg9dt5d2 ай бұрын
Продолжайте! Очень интересно послушать умных людей
@evgeniy33702 ай бұрын
Для тех кто читает коменты, ребят скачайте себе книгу на телефон или в электронную книгу или купите(если вы принципиальны в отношении бумажных книг), толку будет гараздо больше. Не тратьте своё время на этот фоновый бубнёж и невероятного "качества" видео
@webdevkz3 ай бұрын
В мире php на laravel ORM Eloquent очень гибкий покрывает бОльшую часть кейсов, скорее сырой запрос приходится реже писать, чем на ORM
@maksimrybalkin85653 ай бұрын
Большая часть встречи - мнения о книге... Мнения не учат, учит обсуждение непосредственно материала
@MrSuperRenat3 ай бұрын
Спасибо! Вот бы еще звук качественней.
@LAV4514 ай бұрын
Для CEO достаточно хороший уровень. Для CTO достаточно и такого понимания. Интересная тема для обсуждения с Software Architect.
@den-rad4 ай бұрын
CSV легко открывается/редактируется через Excel, его легко экспортировать/импортировать как в базу, так и в pandas.
@talisman11044 ай бұрын
Приведите, пожалуйста, плейлист в порядок, чтобы можно с верхнего первого видео начать и слушать до конца
@Al3x3i10005 ай бұрын
Хороший материал.
@it_qasqyr58655 ай бұрын
Спасибо!
@ivanmorozov61975 ай бұрын
Очень круто! Спасибо! Жду продолжения!
@dimakorolev47406 ай бұрын
Спасибо что пригласили, мне очень понравилось!
@maxbykov2296 ай бұрын
Очень круто. Спасибо за видео
@vova_dev6 ай бұрын
Здорово! Спасибо за труд осмысления и такой наглядной подачи информации!
@green1278dramost56 ай бұрын
Спасибо! Жду продолжения
@lappi_wojak6 ай бұрын
пожалуйста не говорите больше "партиции"
@SabFo_4 ай бұрын
почему?
@basimal-jawahery56884 ай бұрын
а как надо ? :)
@zhuk6 ай бұрын
9:00 Приветствие 16:40 Начало. Введение 56:30 Надежность системы
@vova_dev9 ай бұрын
Вот это инфа. Просто золото. Спасибо!
@alex_mech9 ай бұрын
Тайм-коды бы хоть расставили, много очень воды в начале, которая в записи не нужна
@evgeniziatikov924910 ай бұрын
запись АРХИТЕКТУРНЫЙ ТРЕП №56 будет?
@vonmansfeld224410 ай бұрын
красавчик Иван! пришел на оккупантский стрим и начал гоуорить на языке, который 90% не понимает
@user-ux9un6tc5u11 ай бұрын
В Яндексе G15 и G16 - это мидлы, старший разработчик - это G17
@user-rb1hu9qu9v11 ай бұрын
ни одного инструмента для распила озвучено не было((