Либек доставили в больницу, где было установлено, что она получила ожоги третьей степени 6 % поверхности кожи и ожоги меньшей степени на более чем 16 % кожи[14]. Она оставалась в больнице в течение восьми дней, пока ей делали пересадку кожи. За этот период Либек похудела на 20 фунтов (9,1 кг) (что составляло почти 20 % её массы тела) до 83 фунта (38 кг). После выписки из больницы Либек нуждалась в уходе в течение трёх недель, который обеспечивала её дочь[15]. После ожогов Либек получила статус частичного инвалида сроком на два года
Я бы не стал на себя проливать. Тем более что она просила в компенсацию 20к долларов - это только лечение и потерянный доход. Овчинка явно того не стоит.
В том-то и ирония, что для рядового сотрудника весь этот улучшайзинг с помощью ИИ выглядит как-то так: работал 8 часов в день, и теперь работаю 8 часов, только с ИИ.
Или вообще: вот тебе ИИ, теперь ты должен делать больше и не волнует. Вот радость то.
Из хорошего, возможно, произойдут системные изменения, которые повлияют на всё общество в целом и жить станет лучше. А может нет.
Работодатель: вот вам ИИ — он будет делать за вас рутинную работу. Сотрудники: значит, мы будем меньше работать? Работодатель: нет. Это значит, что я буду больше требовать.
И это уже зависимость. Под зависимостью я понимаю, что сервис не может выполнять свою основную функцию без другого сервиса. Т.е. если вью лег, то наш сервис тоже лёг.
микросервису нужно дублировать пару терабайт данных
Я понял автора довольно радикально: если есть зависимость от другого сервиса, тащи данные к себе. Скажем вы авито, вам нужно что-то из заказа - тащи все заказы к себе.
На моей практике делают по всякому: где-то дублируют модель чтения (а потом бьются за качество данных), где-то ходят за данными в другие сервисы. Есть некоторое количество сервисов, которые если полягут, поляжет многое.
Я правильно понимаю, что если у нас нет RPC, а есть только обмен сообщениями, то каждый сервис должен иметь свою копию необходимых для ответа данных? Что-то нереальное.
Чёт страшно мне. На бэкендах привык разделять асинхронный и синхронный код, как код с IO и код без IO. Код без IO является ещё и чистыми функциями по возможности. Позволяет делить методы на части вида: грузим, что-то делаем, сохраняем.
Просто помню время, когда данные грузились в недрах каких-то функцих и этого нельзя понять, пока не просмотришь ВСЁ.
В .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, даже там где это не нужно.
Я бы не стал на себя проливать. Тем более что она просила в компенсацию 20к долларов - это только лечение и потерянный доход. Овчинка явно того не стоит.
Передаю привет из 2026
Ничего, но никто так не делает, т.к. новые люди стоят дорого.
А вот ИИ дёшев и будут приобретать. А что из этого получается, мы узнаем прямо сейчас.
Не просто 100к в месяц, а ещё целая свободная жизнь, чтобы заниматься чем душе угодно. В этом принципиальная разница с просто зарплатой в 100к.
А если использовать правило 4% процентов, то вообще 300к в месяц
В том-то и ирония, что для рядового сотрудника весь этот улучшайзинг с помощью ИИ выглядит как-то так: работал 8 часов в день, и теперь работаю 8 часов, только с ИИ.
Или вообще: вот тебе ИИ, теперь ты должен делать больше и не волнует. Вот радость то.
Из хорошего, возможно, произойдут системные изменения, которые повлияют на всё общество в целом и жить станет лучше. А может нет.
Работодатель: вот вам ИИ — он будет делать за вас рутинную работу.
Сотрудники: значит, мы будем меньше работать?
Работодатель: нет. Это значит, что я буду больше требовать.
И это уже зависимость. Под зависимостью я понимаю, что сервис не может выполнять свою основную функцию без другого сервиса.
Т.е. если вью лег, то наш сервис тоже лёг.
Я понял автора довольно радикально: если есть зависимость от другого сервиса, тащи данные к себе. Скажем вы авито, вам нужно что-то из заказа - тащи все заказы к себе.
На моей практике делают по всякому: где-то дублируют модель чтения (а потом бьются за качество данных), где-то ходят за данными в другие сервисы. Есть некоторое количество сервисов, которые если полягут, поляжет многое.
Я таки считаю, что нет запрета ходить в другие сервисы, убер так делает, значит и нам можно :)
https://habr.com/ru/companies/flant/articles/514830/
Дорого! Очень дорого!
Я правильно понимаю, что если у нас нет RPC, а есть только обмен сообщениями, то каждый сервис должен иметь свою копию необходимых для ответа данных? Что-то нереальное.
Чёт страшно мне. На бэкендах привык разделять асинхронный и синхронный код, как код с IO и код без IO. Код без IO является ещё и чистыми функциями по возможности. Позволяет делить методы на части вида: грузим, что-то делаем, сохраняем.
Просто помню время, когда данные грузились в недрах каких-то функцих и этого нельзя понять, пока не просмотришь ВСЁ.
В .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, даже там где это не нужно.