Кэшированием можно отдельно управлять через заголовок Cache-Control. Самое "лобовое" решение, чтобы запретить пользоваться любыми кэшами - установить Cache-Control: no-store в ответе на такой запрос.
Тестовое задание на дом — это достаточно наивный фильтр, если принимать достаточным просто его выполнение. И без всяких ChatGPT задача всегда могла быть сделана кем-то кроме кандидата. Основная суть тестового задания — создать поле тем для беседы, не отнимая времени интервью на подготовку: кодобаза получится относительно объемной и предполагается, что кандидат с ней хорошо знаком. Можно обсуждать как выбранные решения в текущем состоянии, так и стратегии развития приложения за рамками условностей демо-проекта.
ЗЫ Разумеется, речь о задачах с упором на архитектуру, на 4+ часа. Мелкие алгоритмы в таких условиях спрашивать смысла нет и не было.
Извечный unwrap тоже подбешивает, но без него еще хуже
В примере они заменяют отдельные вызовы assert, вполне лаконично. Кроме того, непонятно, почему некоторые ошибки пробрасываются наверх, а некоторые — распаковываются явно? Здесь вполне допустимо было бы сделать типом возврата Result<(), Box<dyn std::error::Error>> и пробрасывать всё. Или все через unwrap.
Особенно нравится Spring с -Dmaven.test.skip=true, без которого приложение ломится тестировать соединение с базой на этапе запаковки артефакта. Это поведение не отключается каким-то вменяемым образом через конфиги?
Если нужен hot reload на изменения на хосте, то так и придется поступить. Другое дело, зачем нам в таком виде это в докер заворачивать, имея все инструменты на хосте?)
Мы там сначала копируем файл зависимостей, собираем их, а потом снова копируем исходный код.
Скачивание зависимостей умышленно выносится на отдельный слой, чтобы ускорить пересборку образа при разработке.
Неоптимальность обычно сглаживается тем, что вместо запуска дев-сервера собирается статика и копируется в новый образ какого-нибудь nginx.
Vaadin по этому описанию похож на blazor из c#
теперь ты думаешь о том как заставить его генерить именно тот html, который надо именно тебе.
В Blazor получаете именно ту разметку, которую ожидаете: от HTML его синтаксис ушел не дальше, чем JSX. Вообще, этот фреймворк внешне больше на React смахивает, чем на Vaadin.
что-то javascript'ить
Опять же, в Blazor максимум, что может понадобиться javascript'ить — это обертки для JS-библиотек, если вдруг возникнет желание таковые втаскивать в проект.
пишешь на фреймворке, с которым "не нужно думать о фронте"
Не нужно думать о JS, а про фронт здесь вся статья.
Кэшированием можно отдельно управлять через заголовок Cache-Control. Самое "лобовое" решение, чтобы запретить пользоваться любыми кэшами - установить
Cache-Control: no-storeв ответе на такой запрос.Вполне укладывается в семантику ООП и коллекций:
users.add(user)В C# для этого есть специальный тип
dynamic.Паникующий индексатор — штука не самая безопасная.
Наивный вариант в расте работает аналогичным образом:
Но есть и
get, который возвращаетOption<&V>, с которым можно сделать что-то вроде:Тестовое задание на дом — это достаточно наивный фильтр, если принимать достаточным просто его выполнение. И без всяких ChatGPT задача всегда могла быть сделана кем-то кроме кандидата. Основная суть тестового задания — создать поле тем для беседы, не отнимая времени интервью на подготовку: кодобаза получится относительно объемной и предполагается, что кандидат с ней хорошо знаком. Можно обсуждать как выбранные решения в текущем состоянии, так и стратегии развития приложения за рамками условностей демо-проекта.
ЗЫ Разумеется, речь о задачах с упором на архитектуру, на 4+ часа. Мелкие алгоритмы в таких условиях спрашивать смысла нет и не было.
До первых ленивых дропдаунов с поиском, потом придется это обмазывать еще более страшным нативным JS.
Если у сущностей есть связи, то голые круды — это боль и унижения.
OpenSilver мимикрирует под Silverlight.
Yew, например. Его прелесть в том, что за счет отсутствия жирного рантайма, размер его бандла сравним с JS/React.
А еще, это позволит перебивать собеседника даже на письме.
В примере они заменяют отдельные вызовы assert, вполне лаконично. Кроме того, непонятно, почему некоторые ошибки пробрасываются наверх, а некоторые — распаковываются явно? Здесь вполне допустимо было бы сделать типом возврата
Result<(), Box<dyn std::error::Error>>и пробрасывать всё. Или все черезunwrap.Разве компилятор не даст исчерпывающий ответ с советами по исправлению?
Да и AOT-компиляция может использоваться.
Если селектор будет такой же глубокий и на
:nth-child, то надежней он не будет.Особенно нравится Spring с
-Dmaven.test.skip=true, без которого приложение ломится тестировать соединение с базой на этапе запаковки артефакта. Это поведение не отключается каким-то вменяемым образом через конфиги?Если стандартизация сводится к NodeJS нужной версии, то контейнеры слегка избыточны.
Если нужен hot reload на изменения на хосте, то так и придется поступить. Другое дело, зачем нам в таком виде это в докер заворачивать, имея все инструменты на хосте?)
Скачивание зависимостей умышленно выносится на отдельный слой, чтобы ускорить пересборку образа при разработке.
Неоптимальность обычно сглаживается тем, что вместо запуска дев-сервера собирается статика и копируется в новый образ какого-нибудь nginx.
В Blazor получаете именно ту разметку, которую ожидаете: от HTML его синтаксис ушел не дальше, чем JSX. Вообще, этот фреймворк внешне больше на React смахивает, чем на Vaadin.
Опять же, в Blazor максимум, что может понадобиться javascript'ить — это обертки для JS-библиотек, если вдруг возникнет желание таковые втаскивать в проект.
Не нужно думать о JS, а про фронт здесь вся статья.
Невиртуальные методы мокать сложновато, да. Но в джаве возможность иметь таковые отсутствует, так что слив засчитываю.