YK21

Импорт будет довольно неудобным решением когда дело дойдет до сторонних пакетов и разворачивания на сервере. Либо ты копируешь файлы ручками и весь менеджмент зависимостей происходит у тебя в голове, либо ты должен будешь докидывать пакетный менеджер на сервере, ну пускай тот же npm, инициализировать там проект в понимании npm и гонять там все вои зависимости. При чем он должен быть как минимум достаточно свежей версии если ты используешь какие-нибудь "новомодные" вещи. В общем куча лишних проблем по сравнению с тем чтобы ты просто создал проект у себя, подкинул в нем зависимости и выгружал на сервер проссто один бандл которому наплевать что там происходит на сервере.
В случае с собственными модулями ты проигрываешь как минимум в объеме файлов, так как вебпаку, а на деле и очень много чему, можно поручить минифицировать скрипты
Есть еще такие интересные вещи как babel который сделает твой ну допустим ES6 код рабочим на калькуляторах которые умеют только в ES5 и много много интересной пре-обработки)

Вебпак - сборщик. Может взять много файлов и собрать в один. Ну или в несколько, как мы настроим. В js действительно есть модули, которые как бы уже нативно работают в современных браузерах, но есть ряд проблем:

• Файлов с кодом может быть много. Сотни. Если использовать нативные импорты и загружать сотни файлов в браузер одновременно - накладные расходы будут заметными. Было бы хорошо уменьшить количество файлов. Плюс там могут быть не только скрипты, но и другие файлы, которых тоже может быть много.
  
• Большое количество инструментов были написаны еще до появления нативных модулей в JS. Они все еще работают, выполняют свои задачи, но простым словом import их не импортировать. Там очень разные чудеса встречаются. Придумывать для каждого инструмента персональный костыль, как его импортировать, вроде как не хочется.
  
• К предыдущему - иногда удобно в скрипты на JS импортировать что-то не на JS из отдельных файлов. В контексте моей работы - шейдеры на GLSL. Их нельзя просто так нативным import загрузить.
  
• Часть зависимостей мы ставим с помощью npm. Это удобно. Но мы легко получаем папку node_modules на сотни мегабайт, при том, что в нашем проекте реально используется пара файлов оттуда. Загружать все это целиком на сервер - зачем? Ставить зависимости, а потом копировать нужные файлы откуда-то из глубин node_modules к себе в проект? Можно, но не то, чтобы удобно. Обновлять сложно будет, да и действий лишних что-то много.
  
• Не всегда нам нужен полный функционал инструментов, которые мы используем. Часто в пример приводят lodash. Там много готовых функций на разные случаи жизни, но все используются редко. Было бы прям здорово в браузер загружать только то, что там на самом деле будет использоваться. А то, что не используется - не загружать.
  

Как-то так. То есть нативные модули - это здорово. Но они далеки от совершенства. Не все проблемы решают. Поэтому сборщики все еще актуальны. И будут актуальны еще долгое время.

Плюс webpack имеет возможность встроить в процесс сборки дополнительные процессы, которые долго делать руками. Код можно минифицировать. Уменьшит время загрузки страниц. Можно запустить w3c validator, stylelint, eslint, sonar и.т.д. - всякие проверялки, чтобы убедиться, что к пользователям улетит валидный код. Можно какие-то картинки сжать, сконвертировать в другие форматы. Можно typescript превратить в javascript, less, sass и.т.д. - в css. Много чего можно сделать. В целом сборщик сам по себе - это перпендикулярный ко всем этим процессам инструмент. И раньше люди использовали отдельный класс инструментов, чтобы запускать все это - таск раннеры. Grunt, gulp - вы скорее всего про них слышали. Можно писать npm-скрипты или даже по старинке делать makefile под сложную сборку. Но в webpack вроде как есть функционал плагинов, и можно эти процессы запускать и через него тоже. Вроде как он не для этого изначально придуман, но многие люди находят удобным иметь все в одном месте.

Берите любой сайт, в т.ч. этот и пишите на него автотесты.
Вот вам будет проект.

Посмотрите, как выглядит «текстовый чат» по протоколу HTTP, когда клиент запрашивает у сервера что-то, и получает ответ.

Примерная очерёдность:
Код на клиенте вызывает fetch(). Устанавливается соединение, передаётся запрос «дай /api/method» и передаются заголовки, типа «готов принять json».

Сервер обрабатывает, думает и «пишет в чат»:
1) Строку со статусом HTTP/1.1 200 OK – мол, норм, ща всё будет.
2) Несколько строк HTTP-заголовков ответа: размер, тип и пр.
Пустую строку – мол, заголовки всё.

Вот в этот момент fetch уже понимает, как у него дела с этим запросом. И ресолвит первый промис. Уже ясно, что вроде всё ок, ща польют данные, и это надолго. Дальше вступает в работу объект Response.

3) После пустой строки после заголовков ответа, сервер начинает лить данные тела ответа. Может пару букв, а может гигабайт дампа. Представьте медленный интернет, зарезанную скорость «недружественного» сайта и т.п.

Данные медленно ползут... И наконец, полностью переданы-получены.

Вот тут у объекта Response ресолвится его .json() промис. Посмотрите по ссылке — у того же объекта (мы его получаем после первого ресолва fetch()) есть и свойства, доступные сразу же, синхронно: например, объект с заголовками: свойство headers. Или свойство ok, значение которого следует из самой первой строки ответа сервера.

В общем, понять асинхронность помогает (мысленное) замедление всего и вся. Как будто интернет медленный, вычисления выполняются вручную на бумажке с калькулятором. Становится ясно, что какие-то потенциально долгие делишки ждать невесело, поэтому их делают асинхронными: сразу возвращают Promise, который отресолвится когда там всё доделается. А пока ждём, можно и салат оливье нарезать )

Привлекательности резюме добавляют не пройденные курсы, а опыт.

=> никакой курс не повысит привлекательность резюме.

нон-фикшн по психологии

Хабр точно не для этого

лучше подыскать более подходящую платформу

Да, лучше так, а то таких там и без вас хватает

Чтобы понять async нужно в принципе понимать мультизадачность.

Есть два вида мультизадачки. Первая базируется на preemptive multitasking. Это классика на потоках (Threads). Подходит для приложений где есть нагрузка на CPU и мало I/O. Пример таких приложений - рендеринг 3Д графики. Майнинг.

И есть второй вид когда есть много I/O а нагрузка на процессор - малая и ее можно считать неизменяющейся. Как обработчик событий. Ее делают на async/await. Или еще на мультиплексированном I/O. Она подходит для веб-серверов. Яркий пример - nginx. Или системы обрабоки MQ. Сокет-серверы. Файловые серверы и прочее.

Поэтому изучать async в отрыве от всех методов организации мультизадачности - безсмысленно. Вы ничего не поймете пока не узнаете все use-cases использования железа и ОС. Чтоб понять async - поймите классику.

UPD: Fixed

Какие именно сложности?

У меня был случай, давным давно, интернет в одной бюджетной организации работал отвратительно, нестабильная скорость, разрывы связи,.. какой то сайт работал очень и очень медленно и вылезали ошибки (а повторное обновление по F5 в браузере почему то повторно пробовало загрузить картинки, то ли сайт кривой то ли браузеры тогда по F5 принудительно игнорировали настройки кеширования).

Что сделал я - сначала попробовал узнать датацентр, на котором хостился сайт, прописав его ip адрес (не доменное имя) в гугл и подсмотрев название организации, конкретно в том случае это не подошло но узнав страну, я выбрал датацентр, находящийся там же, арендовал там vps-ку c linux, настроил там x2go сервер (точнее тогда как я помню еще nomachine) и запускал браузер на этой удаленной машине, управляя им удаленно по сети. Тогда это стоило мне тройки десятков баксов (сейчас однозначно можно и дешевле),но дало практические знания по использованию vps-ок и решило проблему.

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

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

Потому что символ & (как и некоторые другие символы) в HTML должен экранироваться как &

upd: Проблема была в чём-то другом. См. комментарии.

lsusb -t покажет в виде дерева, что куда подключено.

Промисы отточить... легко.
Создайте форму, в которую можно накидывать список файлов. Файлы можно накидывать в любой удобный для пользователя момент времени до отправки формы. Файлы отправляются на сервер сразу как только пользователь выбрал файл, не отправляя форму. Пользователь может отменить процесс отправки файла. Форму можно отправить после того, как все процессы отправки файлов завершены. Если один из файлов по какой-то причине не отправился, форму отправлять нельзя.
Ставите в инструментах разработчика "Сеть" - скорость 3G. И испытательный стенд готов. Оттачивайте навыки написания промисов.
PS: Также с любой другой темой. Ставите себе практическую задачу, способ решения которой возможен с использованием инструмента по теме (а то и смежных тем) - и навык закрепится.

Вы правы каждое слово кодируется. Существует огромное количество методов кодирования для NLP (Natural Language Processing). Основной метод кодирования это представления слова в виде вектора где самая важная часть (что делает NLP возможным) при создании такого вектора слова которые используются в схожих контекстах имеют схожее но не одинаковое векторное представление. Векторная схожесть может быть подсчитана разными способами ну например Евклидово расстояние. В таком случае например вы будете иметь уникальный вектор для каждого слова где вектора с близкими Евклидовыми расстояниями будут означать слова которые используются в схожих контекстах. Что касается формата данных которые получит нейронная сеть, то каждый вектор трансформируется где каждое число трансформируется в число 0 до 1. Существует опять таки несколько техник. самая простая формула (x - min(X)) /(max(X) - min(X)), где x это каждый элемент вектора, ну и соответственно min(X) - минимальный элемент вектора max(X) максимальный элемент вектора. подобная трансформация применяется к каждому элементу каждого вектора. Это примитивный пример, для понимания идеи. Данный вопрос глубокий различные техники кодирования могут быть очень сложны и существуют не мало разных подходов для решения подобных задач. Что касается двоичного входа для нейронных сетей то ответ нет. Нейронные сети могут в том числе получать двоичные значения, но не ограничены этим, также они могут получать дискретные (целые) или числа с плавающей запятой.

Слова исходного текста можно представить через "one-hot encoding" – одномерный вектор, где только 1 бит для данного слова – включён. Сколько всего в тексте уникальных слов, такой длины векторы.
Далее возможны преобразования слов в многомерные векторы так, что слова со сходными смыслами оказываются рядом. Или вектор от "кошка" к "котёнок" оказывается параллелен и той же длины, что от "собака" к "щенок". Это называется "word embedding". Один из способов их построения называется "Word2Vec".

Он хайпанул знатно. Но у него есть детские болезни. Такие-же которыми болеют всякие stackoveflow и прочие вопросники. Возможность словить эксплоит. И не очень понятная лицензионная чистота кода. Кто проверит и кто програнтирует что код надежен - непонятно. Тут недавно log4j бабахнул как бомба с critical vulnerability. Джависты до сих пор заикаются и крестятся. Пакет для логгирования который был в каждом втором проекте оказался с дыркой. И никто не видел. При том что и исопльзовали его и code-review многократно делали.

И представте себе уровень безответвенности который исходит из генератора шума. Шучу конечно не шума. А такой себе Марковской генерилки шума. Но опять-же спрашивать про это GPT команду бесполезно. Они-же ее просто обучали на каком-то текстовом сете. Вот надо смотреть что было в том сете и как оно проскочило в учебную выборку.

kbd {
  display: inline-block;
  text-align: center;
  aspect-ratio: 1;
  height: 1.2em;
  ...
}

для того чтобы работать с пользователями достаточно логина и пароля
без сбора личных данных

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

зависит от того, где начало координат.