С одной стороны вы говорите про удобство вместо правильности, с другой - про отлавливание секретов, которые тоже надо настраивать (что по моему мнению тоже нужно).
Сотрудник, пришедший на проект, не хочет из-за необходимости установки одного параметра лезть в метод с 7 параметрами и разбираться как это же внутри работает, нужно ли передать null, пустую строку, 0 (для int) и какой параметр передать, если ты его все равно не хочешь менять. И не дай бог придется добавить ещё 3 параметра к этому чудесному методу, который используется в 30 местах. Всё ситуативно, в подавляющем большинстве моих случаев за этим методом скрывалась длинная портянка с высокой сложностью дебага и кучей времени на "разобраться". Рад за вас, что ваши методы содержат много параметров и ещё при этом удобные, простые и понятные
Я при запросе ЗП в 230 мидловскую работу не могу найти, постоянно отказы.
Зато нанимают сотрудников, которые вместо паттерна "Билдер" пишут методы с 7 переменными, спрашивают почему это коммиты не пушатся в dev или вообще секреты в прод пушат.
Кажется бизнес свернул куда-то не туда со своими сосбеседованиями
Остался только вопрос от программиста (меня) с желанием изучить сети до уровня "этого хватит практически для всех задач программиста" какие книги рекомендуете, если не Таненбаум?
Извините, может кого-то оскорблю, но Ваше утверждение ещё раз доказывает, что многие собеседования превратились в абсурд. Кто лучше жонглирует, у кого в правильном порядке стоят навыки в резюме, кто помнит никому ненужный метод, кто умеет лучше петь/танцевать (нужное подчеркнуть).
Человек с 20-летним опытом в большинстве своем должен получать в первую очередь оффер. Иначе потом приходишь на проект, а там методы по 500 строк от программистов, которые щёлкают Leetcode на лёгком уровне или тратят пару дней на высокопроизводительные отчёты, которые открываются раз в пол года.
Представь, идёшь ты по улице и прямо на голову падает деталь от ночного фонаря. Ты в больнице или, возможно в морге. Готов ли ты заплатить больше денег, чтобы с тобой всё было хорошо?
Представь другую ситуацию. Ты ищешь по улице и ничего тебе на голову не упало. Ты не поймёшь, что какой-то Вася потратил на 20% больше времени, чтобы этот фонарь лучше закрепить. Но ты об этом не узнаешь никогда, так как эта ситуация не произошла.
Теперь вопрос: оценит ли бизнес такого сотрудника или посчитает, что он медленно работает или занимается бесполезной работой и постарается заменить?
Как пример, в крупном контроллере может быть одна зависимость, которая сама тянет конфиги через сеть. Сломается одна зависимость и сломаются все endpoint, которые находятся в контроллере.
Или, нужно вывести enum на фронт, а для этого вы тянете 10 дополнительных зависимостей при каждом запросе.
Каждый решает сам, стоит оно того или нет, но мне подход с контроллерами напоминает подход с тяжеловесными сервисами по 20 методов, которые врятли когда-либо будут отрефакторены и навсегда останутся подвержены росту. И поэтому я использую Minimal Api на крупном проекте и доволен удобством
В C#, для создания сервисов инстанцируемых в контексте исполнения HTTP запроса, используются Transient services
До меня в команде был разработчик, который добавил DbContext как Transient и поверх этого использовались репозитории. Контроллер содержал в среднем по 5+ репозиториев.
В результате, при каждом обращении к точке доступа вместо одного контекста создавалось куча. Видел даже метод, где в результате было создано 20 контекстов, 19 из которых были не нужны.
Мораль басни такова, что в контексте исполнения HTTP запроса использовать надо не жизненный цикл Transient, а свою голову на плечах.
Извиняюсь, что не по теме, но меня немного припекает от того, что алгоритмы красно-черного дерева не пригодятся, но спрашивают про них. Неужели нельзя сформировать список из 50-100 вопросов из технологий, с которым непосредственно будет работать специалист и задавать часть из них?
Помню, как Авито просил меня доказать принадлежность мне аккаунта. Аккаунт был привязан к Gmail. Именно с этого Gmail я им и писал и всякими способами они вынуждали меня доказать, что аккаунт принадлежит мне.
В информатике есть только два сложных вопроса: инвалидация кэша и присвоение имен.
Добавлю третью проблему, которую практически никогда не решают правильно: удаление старых (неактивных) данных.
Чаще всего обходятся механизмом "soft delete", которая ведет к куче проблем с перепроверкой флагов и рекурсивной зависимостью других компонентов. Другой способ ("hard delete") тоже непростой, так как ты либо не можешь удалить элемент из-за FK, либо удаляешь элемент и все зависимые от него элементы с помощью каскадного удаления, которые не хотел бы удалять.
Сам использую подобный подход через задание Expression напрямую без излишнего велосипедостроения.
Только есть несколько моментов, которые надо учитывать:
1) ConstantExpression в примере автора приводит к тому, что запрос в EF Core не кешируется, поэтому лучше его не использовать
2) вместо операции "И" от EF Core можно написать собственные методы расширения Lambda Expression, которые смогут объединить операции "И" и "ИЛИ". Это может быть полезно, когда динамически строишь Expression без четкой модели запроса с именами параметров или в Entity-Attribute-Value. Тогда можно будет по частям строить предикаты и потом на отдельном этапе их объединить
А представьте, что к вам приходит бизнес и говорит, что Id у объекта Order должен быть int и определяться уже после запроса в БД, а вам нужно писать событие OrderCreatedEvent с указанием id созданного заказа. Плюс к тому же данные транзакции и событие должны писаться в рамках одной транзакции (outbox) и событие изменения должно публиковаться как интеграционный эвент вместо доменного. Плюс к тому же это интеграционное событие должно быть ответом на другое событие из какого-нибудь CorrelationId и указанием конкретной очереди, куда нужно писать и передачей некоторых параметров из прошлого события (например, того же CorrelationId), но указывать его надо не в тело сообщения, а в headers.
Я пользуюсь Тинькофф и мне всегда нравился Тинькофф. Но одна вещь меня просто поражает. В 2020 году я им предлагал добавить информацию обо всех устройствах, которые сейчас в сети с возможностью отключения им доступа. Идёт 2024 год, а такое походу и не планируется.
Хотя такой функционал присутствует чуть ли не у каждого более-менее популярного сайта. Да даже деревянный Сбер показывает авторизованные устройства, а вот Тинькофф - нет.
В статье много интересного для новичков, но не описан ещё один интересный подход. Заключается он в разделении логики ролей и разрешений (permission). У каждой роли могут добавляться, изменяться и удаляться разрешения. Каждому человеку можно прописать сколько угодно ролей.
В итоге каждая точка доступа сверяет разрешения текущего пользователя с необходимыми разрешениями, что даёт большую гибкость
С одной стороны вы говорите про удобство вместо правильности, с другой - про отлавливание секретов, которые тоже надо настраивать (что по моему мнению тоже нужно).
Сотрудник, пришедший на проект, не хочет из-за необходимости установки одного параметра лезть в метод с 7 параметрами и разбираться как это же внутри работает, нужно ли передать null, пустую строку, 0 (для int) и какой параметр передать, если ты его все равно не хочешь менять. И не дай бог придется добавить ещё 3 параметра к этому чудесному методу, который используется в 30 местах. Всё ситуативно, в подавляющем большинстве моих случаев за этим методом скрывалась длинная портянка с высокой сложностью дебага и кучей времени на "разобраться". Рад за вас, что ваши методы содержат много параметров и ещё при этом удобные, простые и понятные
Я при запросе ЗП в 230 мидловскую работу не могу найти, постоянно отказы.
Зато нанимают сотрудников, которые вместо паттерна "Билдер" пишут методы с 7 переменными, спрашивают почему это коммиты не пушатся в dev или вообще секреты в прод пушат.
Кажется бизнес свернул куда-то не туда со своими сосбеседованиями
Что мешало решить (читать как сильно уменьшить) проблему надёжной доставки сообщений через паттерны Outbox/Inbox?
Прочитал весь текст. Было сильно и правдиво.
Остался только вопрос от программиста (меня) с желанием изучить сети до уровня "этого хватит практически для всех задач программиста" какие книги рекомендуете, если не Таненбаум?
Извините, может кого-то оскорблю, но Ваше утверждение ещё раз доказывает, что многие собеседования превратились в абсурд. Кто лучше жонглирует, у кого в правильном порядке стоят навыки в резюме, кто помнит никому ненужный метод, кто умеет лучше петь/танцевать (нужное подчеркнуть).
Человек с 20-летним опытом в большинстве своем должен получать в первую очередь оффер. Иначе потом приходишь на проект, а там методы по 500 строк от программистов, которые щёлкают Leetcode на лёгком уровне или тратят пару дней на высокопроизводительные отчёты, которые открываются раз в пол года.
Или КВН + Squid для Https трафика + Adguard в докере (сюда идёт почти весь трафик от Squid и чистится от мусора) + локальный корневой сертификат
Представь, идёшь ты по улице и прямо на голову падает деталь от ночного фонаря. Ты в больнице или, возможно в морге. Готов ли ты заплатить больше денег, чтобы с тобой всё было хорошо?
Представь другую ситуацию. Ты ищешь по улице и ничего тебе на голову не упало. Ты не поймёшь, что какой-то Вася потратил на 20% больше времени, чтобы этот фонарь лучше закрепить. Но ты об этом не узнаешь никогда, так как эта ситуация не произошла.
Теперь вопрос: оценит ли бизнес такого сотрудника или посчитает, что он медленно работает или занимается бесполезной работой и постарается заменить?
Например, моя зарплата - 155 к, Middle ASP.NET Core разработчик. И в HH только и видишь отказ повсюду.
Если кто-то считает, что 400 к - это обычная заплаты, то готов сделать щедрое предложение такому бизнесу и поработать на них за 250 тысяч.
Как пример, в крупном контроллере может быть одна зависимость, которая сама тянет конфиги через сеть. Сломается одна зависимость и сломаются все endpoint, которые находятся в контроллере.
Или, нужно вывести enum на фронт, а для этого вы тянете 10 дополнительных зависимостей при каждом запросе.
Каждый решает сам, стоит оно того или нет, но мне подход с контроллерами напоминает подход с тяжеловесными сервисами по 20 методов, которые врятли когда-либо будут отрефакторены и навсегда останутся подвержены росту. И поэтому я использую Minimal Api на крупном проекте и доволен удобством
Тема
сисекпринципов работы докера не раскрыта. ЖальPgbouncer чем не устроил?
<Сами знаете что> скоро будут использовать даже дети с 6 лет. При этом есть куча инструкций на GitHub как установить <сами знаете что>.
Предлагаю команде хабра просто заменять <то, что нельзя называть из 3 букв> на <сами знаете что>.
До меня в команде был разработчик, который добавил DbContext как Transient и поверх этого использовались репозитории. Контроллер содержал в среднем по 5+ репозиториев.
В результате, при каждом обращении к точке доступа вместо одного контекста создавалось куча. Видел даже метод, где в результате было создано 20 контекстов, 19 из которых были не нужны.
Мораль басни такова, что в контексте исполнения HTTP запроса использовать надо не жизненный цикл Transient, а свою голову на плечах.
Извиняюсь, что не по теме, но меня немного припекает от того, что алгоритмы красно-черного дерева не пригодятся, но спрашивают про них. Неужели нельзя сформировать список из 50-100 вопросов из технологий, с которым непосредственно будет работать специалист и задавать часть из них?
Помню, как Авито просил меня доказать принадлежность мне аккаунта. Аккаунт был привязан к Gmail. Именно с этого Gmail я им и писал и всякими способами они вынуждали меня доказать, что аккаунт принадлежит мне.
Чудики.
Добавлю третью проблему, которую практически никогда не решают правильно: удаление старых (неактивных) данных.
Чаще всего обходятся механизмом "soft delete", которая ведет к куче проблем с перепроверкой флагов и рекурсивной зависимостью других компонентов. Другой способ ("hard delete") тоже непростой, так как ты либо не можешь удалить элемент из-за FK, либо удаляешь элемент и все зависимые от него элементы с помощью каскадного удаления, которые не хотел бы удалять.
Сам использую подобный подход через задание Expression напрямую без излишнего велосипедостроения.
Только есть несколько моментов, которые надо учитывать:
1) ConstantExpression в примере автора приводит к тому, что запрос в EF Core не кешируется, поэтому лучше его не использовать
2) вместо операции "И" от EF Core можно написать собственные методы расширения Lambda Expression, которые смогут объединить операции "И" и "ИЛИ". Это может быть полезно, когда динамически строишь Expression без четкой модели запроса с именами параметров или в Entity-Attribute-Value. Тогда можно будет по частям строить предикаты и потом на отдельном этапе их объединить
А представьте, что к вам приходит бизнес и говорит, что Id у объекта Order должен быть int и определяться уже после запроса в БД, а вам нужно писать событие OrderCreatedEvent с указанием id созданного заказа. Плюс к тому же данные транзакции и событие должны писаться в рамках одной транзакции (outbox) и событие изменения должно публиковаться как интеграционный эвент вместо доменного. Плюс к тому же это интеграционное событие должно быть ответом на другое событие из какого-нибудь CorrelationId и указанием конкретной очереди, куда нужно писать и передачей некоторых параметров из прошлого события (например, того же CorrelationId), но указывать его надо не в тело сообщения, а в headers.
Вот тогда ваш подход начнет ломаться.
Я пользуюсь Тинькофф и мне всегда нравился Тинькофф. Но одна вещь меня просто поражает. В 2020 году я им предлагал добавить информацию обо всех устройствах, которые сейчас в сети с возможностью отключения им доступа. Идёт 2024 год, а такое походу и не планируется.
Хотя такой функционал присутствует чуть ли не у каждого более-менее популярного сайта. Да даже деревянный Сбер показывает авторизованные устройства, а вот Тинькофф - нет.
В статье много интересного для новичков, но не описан ещё один интересный подход. Заключается он в разделении логики ролей и разрешений (permission). У каждой роли могут добавляться, изменяться и удаляться разрешения. Каждому человеку можно прописать сколько угодно ролей.
В итоге каждая точка доступа сверяет разрешения текущего пользователя с необходимыми разрешениями, что даёт большую гибкость