Kentavr16

Верстать лучше в VS Code, т.к. вы можете накинуть туда много плагинов, которые очень сильно вам могут помочь в этом

Для дизайна лучше используйте Figma

В консоль заглядывали?
Там должна быть ошибка, потому что, насколько я помню, функции shuffle в javascript нет.

Какие конструкции использовать, что бы изменить порядок в массиве

Ответ на этот вопрос найти очень просто:
https://yandex.ru/search/?text=javascript+как+пере...

but the server responded with a MIME type of "text/html".

Сервер отдает html. Скорее всего 404. => неверный путь к файлу => Смотрите в консоли что запрашивается и что отдается.

Это задача NLP - Natural Language Processing
Если вкратце, то работа ведется в несколько этапов:
1. Преобразование звука в текст
2. С помощью NLP этот текст обогащается:
- Форматируется
- Убирается мусор
- Выделяются ключевые слова
3. Готовый текст подается на вход другой нейронке, которая используя свою базу данных (история, контекст) понимает немерение

Собственно, сама работа ведется в последней части. Как эти нейронки работают - другой вопрос. Просто обучают на своих наборах данных

Технически, DOCX можно прочитать - это ZIP архив, в котором лежат XMLки. Библиотека для чтения ZIP архивов под JS (в т.ч. браузерный) есть.
Но реально проще будет использовать расширенную поиск-замену в Word, чтобы заменить красный цвет на уникальный символ или комбинацию символов перед текстом. Комбинация ^& означает "искомый текст", т.е. приведённый ниже пример вставляет знак процента перед текстом, написанным красным цветом.

А потом уже вставить в веб-страницу текст без форматирования и разбирать его.

Вам нужно вернуться к учебнику и научиться понимать код на базовом уровне, иначе вы с каждой строчкой сюда бегать будете.
В функции onSubmit вы вызываете addReservationAsync с двумя аргументами: requestServer и объект с кучей полей. А addReservationAsync ожидает 6 аргументов (то есть не объект, а каждое значение отдельно).

// for (let i = 0; i = expenses_without_first.length; i += 8) {
for (let i = 0; i < expenses_without_first.length; i += 8) {

work_id_array[i / 8]

Интересная конструкция, а если поделить 8/8, то что получится?

По умолчанию у всех неизвестных/несуществующих тегов (а тега selection не существует) стиль display:inline. Можно считать что они все аналогичны тегу span.

Если вы попробуете использовать в этом месте span, то получите такой же результат.

Что бы было видно фон нужно явно задать стиль display: block.

Артефакт сборки надо поместить в /app

Тут не помешает двухстейджевая сборка, чтобы оптимизировать размер образа:

FROM node:18 as static-builder

WORKDIR /app

COPY package*.json ./

RUN npm install --legacy-peer-deps

COPY . .

RUN npm run build

# EXPOSE 3000 - эта директива оставлена для обратной совместимости и ни какие порты не открывает, можно её не использовать

FROM nginx

COPY --from=static-builder /app/publc /usr/shared/nginx/html
# или другой каталог, если артефакт сборки помещается не в /app/publc

Как уже сказали, для чатов самое оптимальное websocket, только тут всплывет что у Django с этим проблема, есть channels, но мне они очень не нравятся, выглядит как переделанный сбоку костыль. Кроме этого, год назад видел попытки реализации websocket на основе текущего async в Django, но за этим не следил, так что не знаю какое там сейчас состояние. Так что лучшее решение, перенести чат на async фреймворки

Пока не вижу никаких преимуществ от разработки под докером - вижу что технически это реально, но билдить каждый раз после внесения изменений в код - что я от этого выиграю?

Главное преимущество в том что у тебя инфраструктура на проде и инфраструктура при разработке похожие=> в случае проблем, они будут быстро вскрываться.

А билдить после каждого изменения не нужно - во время разработки можно подсовывать новые файлы через волюм (если ты пишешь на интерпретируемом языке), да и с корректным кэширование сборка происходит очень быстро (если пишешь на компилируемом).

Опять же само окружение можно в докер впихнуть - базы данных, бэкенд, всякие nginx-ы.
Если у тебя при разработке много нужно устанавливать - можно даже само окружение для разработчика контейнеризировать через Devcontainers.

Здравствуйте, почитайте про Module Federation

>Или все же это инструмент в первую очередь для доставки контента?
Докер упрощает процесс доставки контента, но это не едиственный его плюс. Он позволяет быстро создать,воссоздать,повторить аналогичное окружение и зависимости которые необходимы твоему приложению в любом (почти) месте где есть поддержка docker.

> но билдить каждый раз после внесения изменений в код - что я от этого выиграю?
Ты не правильно используеш докер, если есть необходимость пересобирать контейнер при каждом изменении. Докер это окружение в котором работает твое приложение.

> Как с этим дела в реальной жизни, на реальном среднестатистическом проекте?
Повсеместно испольуется. Следующий шаг развития докер это k8s, а это mainstream. Если ты умееш работать с докером, то освоить k8s уже намного проще.

Если сильно упростить то контейнер докер это виртуальная машина на linux внутри которой крутиться одно приложение. В идеологии докера каждое приложение должно быть в отдельном контейнере - mysql,redis,php.

Докер позволяет обойти проблему зависимостей.

Помню когда первый раз столкнулся с docker, это была система анализа логов от ruckus. По своей структуре это был centos на котором было запущено 8-9 контейнеров docker. Таким подходом ruckus как минимум решил для себя проблему установки обновлений, тебе не надо ставить обновления на саму ОС, тебе достаточно обновить контейнер. Если контейнер не запустился, то просто откати его. Все библиотеки и зависимости внутри контейнеров. Это настолько упростило процесс разработки и доставки обновлений, что сложно и представить.

Дошел до изучения докера, так как это мастхэв веб-разработчика судя по статьям/требованиям работодателей.

Нет.Это полезно знать, но далеко не всегда стоит применять.

Как с этим дела в реальной жизни, на реальном среднестатистическом проекте?

Среднестатистическому проекту контейнеризация вообще не нужна. И даже там, где нужна, зачастую с ней имеют дело админы, а не разработчики.

В разработке докер нужен только тогда, когда вы ведёте множество проектов, которые требуют разных окружений и не поддерживают собственных средств виртуализации. Например разработка чего-то системного на C.
В развёртывании докер нужен тогда, когда у вас сотни динамически разворачиваемых серверов. Если у вас одна VPS'ка, то докер - это оверкилл.

Смысл в том, что все пакеты, зависимости итд можно упаковать в 1 контейнер, который с помощью 1 yml файла потом можно поднять фактически где угодно ( на любом линукс) с вероятностью в 99%

В случае же стандартной установки пакетов и зависимостей - их потом придется ставить на прод, что может создавать сложности, если там работает множество сервисов...

Ну банально упрощает развертывание. Но обычно этим занимаются девопсы конечно, а не прогеры... Но проблема в том, что только прогеры знают, какие зависимости и каких версий должны стоять, так что эти вопросы придется решать)