В .net мире новый asp.net проект есть в любой студии. Даже ef можно не ставить, если надо, говоришь, что тебя есть IQueryable<MyEntity> и вперёд.
Миграции писать не надо, модель данных - 1 класс и 2 енама.
Ожидаю любую архитектуру, можно даже в контроллере написать код, если кандидат обоснует, почему такой выбор.
Код можно не запускать. Во многих местах достаточно что-то типа: использую код фёрст подход, миграции сделает ef, эту модель проще всего замапить через автомаппер, здесь воткну медиатР, потому что...
Проверяется видел ли кандидаты бэкенды в глаза за свой пятилетний опыт, например.
Заметил, что от уровня кандидата меняются вопросы (задавать можно и нужно). Джуны тяготеют к "правильности кода", люди поопытнее выясняют требования и сообщают о допущения которые они делают. Тут инфы как-будто даже больше чем от интервью.
С тестовыми есть проблемка: иногда оно написано не кандидатом, он может хорошо рассказать где и что, но не может воспроизвести (было 1 раз).
С разговором по душам та же проблема: поговорили, вроде всё хорошо, а потом IDE как-будто в первый раз видит. Ну типа, public class по букве пишет, вспоминает название Linq-методов (из тройки Select, Where, GroupBy).
В идеале поработать с человеком недельку, но где такие ресурсы взять?
Лайф-кодинг на бэкендера: реализовать ендпоинт в любом удобном ему инструменте. Код не должен компилироваться, но ожидается объяснение основных шагов, описание DTO, метода контроллера и реализация запроса к бд уровня: вернуть количество строк в таком-то статусе с группировкой по типу (linq или sql на выбор). Гуглить, использовать ИИ можно.
Кажется 1 и второй 2 пункт закрыт.
Просто я не знаю как понять, что может кандидат, если не посмотреть на его код и на то, какие вопросы он задаёт.
В одной компании, когда на заводе находили критический баг, менеджер отдела садился рядом с ответственным за исправление программистом и сидел, пока проблема не будет исправлена :)
Дан список чисел, нужно вернуть сумму чётных из них
Конкретно эта задача - проверка механических навыков программирования. Человек вообще код писал или нет. Как долго кандидат (в своей иде) пишет public class, выбирает ли он .Where из выпадающего списка и т.п.
А вот с более сложными задачами, действительно могут быть проблемы и вариаций куча. И вообще не поймёшь, человек будет нормально работать или нет. Просто от мидла ожидаешь решения поставленных задач в разумное (принятое в этой компании для тех кто считается мидлом) время, а не способность решить "когда-нибудь".
Иногда покупают 10 одинаковых сетевых железяк, заливают туда одинаковые конфиги, а потом разрабы пол ночи переписываются к сетевиками, потому что каждый считает, что у него проблемы быть не может. А оказывается, что аппаратный сбой.
Иногда soap запрос не ходит, потому что версия ядра линукс на стейже и проде отличается в номере пачта. А когда его обновляют, падает другой сервис :D
Иногда разраб сносит продовую бд, потому что подключался к ней 3 месяца назад, когда сервис даже близко не было готов и забыл убрать коннект из секретов.
Всякое дерьмо случается. Хорошо, если это большой проект и есть поддержка, но иногда и она не вывозит.
Просто пока все условия не выполнил, это не Rest. Это не я, это автор термина так считает.
5. Слои
Клиент обычно не способен точно определить, взаимодействует ли он напрямую с сервером или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует слои). Применение промежуточных серверов способно повысить масштабируемость за счёт балансировки нагрузки и распределённого кэширования. Промежуточные узлы также могут подчиняться политике безопасности с целью обеспечения конфиденциальности информации
Получается не только кэширование нужно, но и поддержку промежуточных узлов.
Вообще, всё можно написать руками, но думаю, Фидлинг верил в мир унифицированных интерфейсов взаимодействия (даром, чтоле участвовал в создании спецификации http) и весь REST построен вокруг них. Другое дело, что мы выросли из этих штанишек, но всё ещё пытаемся упихаться в REST, даже там где это не нужно.
GraphQL как дополнение: для сложных клиентов с часто меняющимися требованиями к данным рассмотрите использование GraphQL поверх REST. GraphQL позволяет клиенту запросить все необходимые данные за один запрос, решая проблемы N+1 и переполучения данных. Бэкенд‑сервисы при этом могут оставаться RESTful.
Если я правильно понял, вы предлагаете добавить GraphQL-сервис как BBF, прокладку между клиентом и бэкенд сервисами. Но ведь этот BBF делает всё то же самое, что клиент.
Поэтому вопрос: как именно GraphQL помогает решить проблему N+1? Почему сам клиент не мог её решить так же?
Всё что есть - сжатие пачки сообщений на продюсере при отправке. Вся эта пачка становится одним чанком. Если отправка идёт по одному сообщению: то никакого сжатия.
Основная сложность стримов в рэбите: это подтверждение доставки.
Допустим мы отправляем с помощью await porduser.Send(...), это вообще ничего не значит, нужно ждать когда отработает MessageHandler. Приходится писать свою обвязку.
Если отправили список сообщений (даже с одним сообщением), то MessageHandler отрабатывает сразу, а если по одному, то происходит буфферизация. Задаётся параметров MessagesBufferSize продюсера, по умолчанию 100. Параметра "максимальное время ожидания отправки" не существует.
В итоге, из коробки либа Rabbit.Streams подходит для быстрой массовой отправки сообщений без гарантии доставки. Если нужны гарантии, нужно дописывать свой код.
Я скорее про то, что могу ли я отправлять по одному сообщению, но логи бы всё равно сжимались?
К примеру, в rabbit streams поддерживается сжатие только внутри чанка. Отправил 100 логов одной пачкой, к этой пачке можно применить сжатие. Отправил по одному логу - никакого сжатия сообщений.
Если ждать пока наберётся пачка (особенно с учётом секционирования), то можно при сбое потерять данные буффера.
Перевод. Но как же я согласен с автором. Код должен быть понятным.
У меня ещё с первой книги (стоит в шкафу, если что) вызывало недоумение использование общего состояния и сверхмалых функций.
Когда я начал использовать их, оказалось, что читать код нисколько не проще, а даже сложнее. То что могло быть просто быть просто строчкой кода, теперь вызов функции. И я не знаю, что она там меняет. В итоге, только полное чтение всего кода.
Идеи Мартина не прошли проверки временем и практикой.
А вот чистые функции - это сила. Они снижают нагрузку на мозг, потому что функцию можно заменить результатом вычисления от того, что ты видишь в вызове
Ссылочная прозрачность — свойство, при котором замена выражения на вычисленный результат этого выражения не изменяет желаемых свойств программы
В .net мире новый asp.net проект есть в любой студии. Даже ef можно не ставить, если надо, говоришь, что тебя есть IQueryable<MyEntity> и вперёд.
Миграции писать не надо, модель данных - 1 класс и 2 енама.
Ожидаю любую архитектуру, можно даже в контроллере написать код, если кандидат обоснует, почему такой выбор.
Код можно не запускать. Во многих местах достаточно что-то типа: использую код фёрст подход, миграции сделает ef, эту модель проще всего замапить через автомаппер, здесь воткну медиатР, потому что...
Проверяется видел ли кандидаты бэкенды в глаза за свой пятилетний опыт, например.
Заметил, что от уровня кандидата меняются вопросы (задавать можно и нужно). Джуны тяготеют к "правильности кода", люди поопытнее выясняют требования и сообщают о допущения которые они делают. Тут инфы как-будто даже больше чем от интервью.
С тестовыми есть проблемка: иногда оно написано не кандидатом, он может хорошо рассказать где и что, но не может воспроизвести (было 1 раз).
С разговором по душам та же проблема: поговорили, вроде всё хорошо, а потом IDE как-будто в первый раз видит. Ну типа, public class по букве пишет, вспоминает название Linq-методов (из тройки Select, Where, GroupBy).
В идеале поработать с человеком недельку, но где такие ресурсы взять?
Лайф-кодинг на бэкендера: реализовать ендпоинт в любом удобном ему инструменте. Код не должен компилироваться, но ожидается объяснение основных шагов, описание DTO, метода контроллера и реализация запроса к бд уровня: вернуть количество строк в таком-то статусе с группировкой по типу (linq или sql на выбор). Гуглить, использовать ИИ можно.
Кажется 1 и второй 2 пункт закрыт.
Просто я не знаю как понять, что может кандидат, если не посмотреть на его код и на то, какие вопросы он задаёт.
Я может есть какие-нибудь методы снизить стресс?
Новость есть, а картинок нет :(
В одной компании, когда на заводе находили критический баг, менеджер отдела садился рядом с ответственным за исправление программистом и сидел, пока проблема не будет исправлена :)
Конкретно эта задача - проверка механических навыков программирования. Человек вообще код писал или нет. Как долго кандидат (в своей иде) пишет public class, выбирает ли он .Where из выпадающего списка и т.п.
А вот с более сложными задачами, действительно могут быть проблемы и вариаций куча. И вообще не поймёшь, человек будет нормально работать или нет. Просто от мидла ожидаешь решения поставленных задач в разумное (принятое в этой компании для тех кто считается мидлом) время, а не способность решить "когда-нибудь".
Сам придумал про менеджеров, сам опроверг :)
Иногда покупают 10 одинаковых сетевых железяк, заливают туда одинаковые конфиги, а потом разрабы пол ночи переписываются к сетевиками, потому что каждый считает, что у него проблемы быть не может. А оказывается, что аппаратный сбой.
Иногда soap запрос не ходит, потому что версия ядра линукс на стейже и проде отличается в номере пачта. А когда его обновляют, падает другой сервис :D
Иногда разраб сносит продовую бд, потому что подключался к ней 3 месяца назад, когда сервис даже близко не было готов и забыл убрать коннект из секретов.
Всякое дерьмо случается. Хорошо, если это большой проект и есть поддержка, но иногда и она не вывозит.
Мимобэкендер, который хорошо спит ночами.
А как так получилось, что мускулинный - звучит как что-то плохое, а мужественный как что-то хорошее?
Вот мне казалось, что это функция для покупателей, которые не могут прочитать объявление, так и ИИ оказывается тоже не может :D
Как реализуют, так и будем нервничать, а то ведём себя как Умная Эльза
Просто выбираем какие срабатывания нам нравится больше: ложноположительные и ложноотрицательные.
Эта новость звучит лучше чем: автоматическая ИИ система приняла пистолет за пачку чипсов.
Просто пока все условия не выполнил, это не Rest. Это не я, это автор термина так считает.
Получается не только кэширование нужно, но и поддержку промежуточных узлов.
Вообще, всё можно написать руками, но думаю, Фидлинг верил в мир унифицированных интерфейсов взаимодействия (даром, чтоле участвовал в создании спецификации http) и весь REST построен вокруг них. Другое дело, что мы выросли из этих штанишек, но всё ещё пытаемся упихаться в REST, даже там где это не нужно.
Если я правильно понял, вы предлагаете добавить GraphQL-сервис как BBF, прокладку между клиентом и бэкенд сервисами. Но ведь этот BBF делает всё то же самое, что клиент.
Поэтому вопрос: как именно GraphQL помогает решить проблему N+1? Почему сам клиент не мог её решить так же?
Кеширование есть?
А в чём миф? В тексте так и сказано, без гипермедиа не RESTful.
В итоге сами же говорите:
А ещё нет сжатия сообщений в стримах.
Всё что есть - сжатие пачки сообщений на продюсере при отправке. Вся эта пачка становится одним чанком. Если отправка идёт по одному сообщению: то никакого сжатия.
Основная сложность стримов в рэбите: это подтверждение доставки.
Допустим мы отправляем с помощью await porduser.Send(...), это вообще ничего не значит, нужно ждать когда отработает MessageHandler. Приходится писать свою обвязку.
Если отправили список сообщений (даже с одним сообщением), то MessageHandler отрабатывает сразу, а если по одному, то происходит буфферизация. Задаётся параметров MessagesBufferSize продюсера, по умолчанию 100. Параметра "максимальное время ожидания отправки" не существует.
В итоге, из коробки либа Rabbit.Streams подходит для быстрой массовой отправки сообщений без гарантии доставки. Если нужны гарантии, нужно дописывать свой код.
Я скорее про то, что могу ли я отправлять по одному сообщению, но логи бы всё равно сжимались?
К примеру, в rabbit streams поддерживается сжатие только внутри чанка. Отправил 100 логов одной пачкой, к этой пачке можно применить сжатие. Отправил по одному логу - никакого сжатия сообщений.
Если ждать пока наберётся пачка (особенно с учётом секционирования), то можно при сбое потерять данные буффера.
Чем вам человек не продвинутый ИИ?
Насколько хорошо кафка ждём данные?
Скажем у меня есть куча телеметрии по 100-200байт на измерение если выгрузить в .csv. В архиве будет почти в 10 раз меньше.
Проще говоря: сколько в кафке занимает гигабайт логов?
Перевод. Но как же я согласен с автором. Код должен быть понятным.
У меня ещё с первой книги (стоит в шкафу, если что) вызывало недоумение использование общего состояния и сверхмалых функций.
Когда я начал использовать их, оказалось, что читать код нисколько не проще, а даже сложнее. То что могло быть просто быть просто строчкой кода, теперь вызов функции. И я не знаю, что она там меняет. В итоге, только полное чтение всего кода.
Идеи Мартина не прошли проверки временем и практикой.
А вот чистые функции - это сила. Они снижают нагрузку на мозг, потому что функцию можно заменить результатом вычисления от того, что ты видишь в вызове
Очень хорошая статья на тему Функциональное программирование — это не то, что нам рассказывают.
И вообще, Хватит писать «чистый» код. Пора писать понятный код