Ура! Я вот думал писать про pg_advisory_xact_lock или кто-то найдётся :) Это реально тема! Но нужно отметить, что писать с advisory lock гораздо сложенее чем с for update. В первую голову потому, что pg_advisory_xact_lock блокирует только 1 ключ (см документацию https://postgrespro.ru/docs/postgrespro/current/functions-admin). Они очень хорошо подходят для блокирования "сегментов", если Вы конечно их смогли разметить.
За рассказ про то, как сейчас работают блокировки, спасибо. Интересно. ИМХО будут закрывать диапазоны операторов CDN для исполнения законов.
Неприятен первый абзац статьи :(
Вообще, политически, часть инфы увы реально вредоносная, и люди, потребляя её несут потом полный бред. И закрытие такой информации оправдано. Ограничения сейчас топорные, но при массовости от топорности не избавиться :(
Вторая часть политической проблемы - "санкции" вот для обхода их ВПН - тема.
А ещё жаль, что автор не упоминает про цензуру в других регионах мира. В том числе и "цивилизованных", в них тоже нужно пользоваться VPN, если хочешь настоящую свободу ...
Статья понравилась. Очень холиванпя тема, и очень "аргументированно" преподнесены тезисы.
Истинно хороший пункт в статье "Не нужно звать всех подряд" и про нет парой абзацев ниже.
Однако если вы используете эти 2 момента из статьи то остальное - нытьё :(
ИМХО Статья показывает как джун реагирует на объём информации. И как и почему не справляется. А комменты показывают, что плойка - предел интеллектуальной деятельности:). Я б, уволил человека, если он в нужном разговоре теряет контекст, и не приносит другой пользы...
Совещания перестают быть проблемой, если тебе нужно придумать как сделать задачу, уточнить требования и т. д. И при этом ты не просто "исполнитель на отвали". Ты сам начинаешь собирать совещания. Те самые на 5 минут :)
Письменная речь оставляет следы, но она очень очень медленная и она не даёт возможность "переспросить".
Устная речь быстрая, и позволяет понять проблему и быстро найти решение, если все участники достаточно интеллектуальны, конечно. Но не оставляет артефактов.
Выбирай тип речи в зависимости от обстоятельств.
К сожалению, очень много людей просто не способны держать темп разговора и вникать в суть проблемы. С автором статьи согласен, таких приглашать на встречи бессмысленно, вредно, они будут ныть. Но и поручать им работу, которая требует коммуникаций не стоит. Пущай копаются в болоте и делают простые задачи. Всегда нужны руки. А с руками разговаривать не нужно :) и слушать их тоже особо не стоит :).
Добавлю тут один принцип не менее холиварный: ты уточнил? - Я написал - А он? - Пока не ответил - Ну так позвони, а если не возьмёт трубку, звони его начальнику, но за час до звонка напиши, что бы формальность соблюсти.
И ещё один: Я в комменте к задаче написал. - Ты донёс мысль до исполнителя? Убедился что он понял? Нет? - Нет, но он должен был прочитать комментарий, там же написано - Нет не должен. Не должен человек читать 1000 комментариев, Если что-то реально важное, внеси в тело задачи и явно убедить, что его приняли и поняли. Если этого не сделал, ну значит ты ничего не сделал. На заборе тоже написано, а под забором ещё и навалено.
Верно в примере такси зависит от нашей потребности.
Рассмотрим второй вариант:
Мы говорим в интерфейсе, что нужно сделать перевозку.
Есть внешний агрегатор такси. Не зависящий от нас
Значит нужен слой внешнего взаимодействия, например секретарь или логист. У которого есть метод отвези мою посылку, который нужен нам, и он адаптирует его к одному или нескольким агрегаторам.
Для меня как для заказчика (юзкейса) абсолютно не важно какой размер груди у секретаря или какие мозоли у логиста. Главное что есть кому сказать отвези.
Из этого примера видно, что слой внешнего взаимодействия зависит от слоя юзкейсов и от внешнего АПИ одновременно.
Как я понял из статьи и собственного применения, читай что можно его (описание интерфейса) расположить в одном файлике/папке/неймспейсе (зависит от языка) с МВУ
А МНУ будет подключать/наследовать МВУ для получения описание интерфейса.
Тут не понятно что имеется ввиду? Каких случаях? И просьба задать вопрос без кода, так как код должен являться результатом применения модели / принципа, а не источником.
Код сверху не описывает зависимости, так что плохо применим к описанию проблемы.
Ответ на то что понимается под зависит и использует был дан выше.
Я увидел что Вам не понятна разница между использованием реализации [интерфейсов] и зависимостью, то есть неким аналогом наследования, использования кодовой базы непосредственно.
Это тема кажется не интересной к обсуждению так как относится или к смешению контекста или глубинному не пониманию абстракций.
Читай включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию, которое как раз отвечает за понятие использует в рамках модулей бизнес логики и обычного языка.
Юзкейс может использовать реализации из (читай использует) внешнего взаимодействия
Upd Модель основана на чистой архитектуре. Если она Вам не знакома, то увы объяснение терминов может свестись к некому описанию чистой архитектуры. Что не очень продуктивно.
Я использую легковое такси. Как способ доставки моего товара от подъезда до подъезда.
Я не завишу от марки и модели автомобиля который перевезёт мой товар. Не завишу ни от чего внутри автомобиля.
Я определил интерфейс - перевезти. И его использую.
Но от его реализации я не завишу.
upd Как дополнение. В момент перевозки я использую конкретный экземпляр такси. Который предоставлен мне конкретным провайдером. Которого я могу сменить без влияния на результат.
Тут есть зависит. В в данном случае зависит (имеет зависимость) близко по смыслу к включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию.
На примере юзекйса и внешнего взаимодействия (конкретных):
Внешнее взаимодействие зависит от юзкейса.
Юзкейс может использовать реализации из внешнего взаимодействия
Ура! Я вот думал писать про pg_advisory_xact_lock или кто-то найдётся :) Это реально тема!
Но нужно отметить, что писать с advisory lock гораздо сложенее чем с for update. В первую голову потому, что pg_advisory_xact_lock блокирует только 1 ключ (см документацию https://postgrespro.ru/docs/postgrespro/current/functions-admin). Они очень хорошо подходят для блокирования "сегментов", если Вы конечно их смогли разметить.
За рассказ про то, как сейчас работают блокировки, спасибо. Интересно. ИМХО будут закрывать диапазоны операторов CDN для исполнения законов.
Неприятен первый абзац статьи :(
Вообще, политически, часть инфы увы реально вредоносная, и люди, потребляя её несут потом полный бред. И закрытие такой информации оправдано. Ограничения сейчас топорные, но при массовости от топорности не избавиться :(
Вторая часть политической проблемы - "санкции" вот для обхода их ВПН - тема.
А ещё жаль, что автор не упоминает про цензуру в других регионах мира. В том числе и "цивилизованных", в них тоже нужно пользоваться VPN, если хочешь настоящую свободу ...
Хорошо показывающая что происходит статья.
Пройти скрининг по 10-15 простым вопросам за 5-10 минут обычно упрощает жизнь обеим сторонам.
Единственное что hr должен явно попросить отвечать коротко и ёмко.
Увы реально много "синьёров" не владеет нормально тем, что пишет в резюме.
Статья понравилась. Очень холиванпя тема, и очень "аргументированно" преподнесены тезисы.
Истинно хороший пункт в статье "Не нужно звать всех подряд" и про нет парой абзацев ниже.
Однако если вы используете эти 2 момента из статьи то остальное - нытьё :(
ИМХО Статья показывает как джун реагирует на объём информации. И как и почему не справляется. А комменты показывают, что плойка - предел интеллектуальной деятельности:). Я б, уволил человека, если он в нужном разговоре теряет контекст, и не приносит другой пользы...
Совещания перестают быть проблемой, если тебе нужно придумать как сделать задачу, уточнить требования и т. д. И при этом ты не просто "исполнитель на отвали". Ты сам начинаешь собирать совещания. Те самые на 5 минут :)
Письменная речь оставляет следы, но она очень очень медленная и она не даёт возможность "переспросить".
Устная речь быстрая, и позволяет понять проблему и быстро найти решение, если все участники достаточно интеллектуальны, конечно. Но не оставляет артефактов.
Выбирай тип речи в зависимости от обстоятельств.
К сожалению, очень много людей просто не способны держать темп разговора и вникать в суть проблемы. С автором статьи согласен, таких приглашать на встречи бессмысленно, вредно, они будут ныть. Но и поручать им работу, которая требует коммуникаций не стоит. Пущай копаются в болоте и делают простые задачи. Всегда нужны руки. А с руками разговаривать не нужно :) и слушать их тоже особо не стоит :).
Добавлю тут один принцип не менее холиварный: ты уточнил? - Я написал - А он? - Пока не ответил - Ну так позвони, а если не возьмёт трубку, звони его начальнику, но за час до звонка напиши, что бы формальность соблюсти.
И ещё один: Я в комменте к задаче написал. - Ты донёс мысль до исполнителя? Убедился что он понял? Нет? - Нет, но он должен был прочитать комментарий, там же написано - Нет не должен. Не должен человек читать 1000 комментариев, Если что-то реально важное, внеси в тело задачи и явно убедить, что его приняли и поняли. Если этого не сделал, ну значит ты ничего не сделал. На заборе тоже написано, а под забором ещё и навалено.
Спасибо за статью :)
И мне, если не сложно
Верно в примере такси зависит от нашей потребности.
Рассмотрим второй вариант:
Мы говорим в интерфейсе, что нужно сделать перевозку.
Есть внешний агрегатор такси. Не зависящий от нас
Значит нужен слой внешнего взаимодействия, например секретарь или логист. У которого есть метод отвези мою посылку, который нужен нам, и он адаптирует его к одному или нескольким агрегаторам.
Для меня как для заказчика (юзкейса) абсолютно не важно какой размер груди у секретаря или какие мозоли у логиста. Главное что есть кому сказать отвези.
Из этого примера видно, что слой внешнего взаимодействия зависит от слоя юзкейсов и от внешнего АПИ одновременно.
Как я понял из статьи и собственного применения, читай что можно его (описание интерфейса) расположить в одном файлике/папке/неймспейсе (зависит от языка) с МВУ
А МНУ будет подключать/наследовать МВУ для получения описание интерфейса.
Тут не понятно что имеется ввиду? Каких случаях? И просьба задать вопрос без кода, так как код должен являться результатом применения модели / принципа, а не источником.
Код сверху не описывает зависимости, так что плохо применим к описанию проблемы.
Ответ на то что понимается под зависит и использует был дан выше.
Нет не идентично.
Ибо суть понята не до конца верно.
Реализация интерфейса может быть любой (использует), а вот объект из энтити только строгого состава зависит.
Я увидел что Вам не понятна разница между использованием реализации [интерфейсов] и зависимостью, то есть неким аналогом наследования, использования кодовой базы непосредственно.
Это тема кажется не интересной к обсуждению так как относится или к смешению контекста или глубинному не пониманию абстракций.
Прошу прощения если задел.
Читай комментарии сверху они дают различие в терминологии.
Но на всякий случай использовать в рамках статьи имеется ввиду результат деятельности.
Но бывает слово используется (причем другое) для описания использования кодовой базы что является зависимостью в терминологии статьи и комментариев :)
Нет usecase зависит от entity и использует реализации из внешнего взаимодействия.
Я прям над вашим комментарием написал разницу между зависит и использует.
Нет он от него зависит
Usecase зависит от entity.
Читай включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию, которое как раз отвечает за понятие использует в рамках модулей бизнес логики и обычного языка.
Юзкейс может использовать реализации из (читай использует) внешнего взаимодействия
Upd Модель основана на чистой архитектуре. Если она Вам не знакома, то увы объяснение терминов может свестись к некому описанию чистой архитектуры. Что не очень продуктивно.
Я использую легковое такси. Как способ доставки моего товара от подъезда до подъезда.
Я не завишу от марки и модели автомобиля который перевезёт мой товар. Не завишу ни от чего внутри автомобиля.
Я определил интерфейс - перевезти. И его использую.
Но от его реализации я не завишу.
upd Как дополнение. В момент перевозки я использую конкретный экземпляр такси. Который предоставлен мне конкретным провайдером. Которого я могу сменить без влияния на результат.
Тут есть зависит. В в данном случае зависит (имеет зависимость) близко по смыслу к включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию.
На примере юзекйса и внешнего взаимодействия (конкретных):
Внешнее взаимодействие зависит от юзкейса.
Юзкейс может использовать реализации из внешнего взаимодействия
В теле сатьи есть определения МВУ и МНУ. Они чётко дают понимание терминов выше и ниже.
Кажется мы разговариваем о разном. Я предлагаю ещё раз вернуться к определениям и понять в них есть слово использует но нет слова зависит.
А вот зависимость кодовой базы - это уже применение принципов скрываемых за идеей, например за SOLID.
Что такое формально определить?
Что хочется услышать на это? Есть ли непротиворечивый пример?
Суть вопроса не понятна.
Ибо выше и ниже чётко определяется в статье.
Использует - это базовое слово.
пользоваться -зуюсь, -зуешься; несов. 1. (несов. воспользоваться) чем. Прибегать к чему-л., обращаться к чему-л. для своих нужд и потребностей.