Илья

В бытность мою студентом в сетевых картах перепаивали генераторы частоты они вместо 100мегабит начинали давать 50 но кабели начинали работать на 200-230 метров, только надо 2 карты с одинаковым "тюнингом".

В современном мире если vdsl, shdsl, медиа конверторы. Цена вполне приемлема плюс нормальные железки еще и состояние будут показывать.

Есть ещё "бомж дешман" способ. Покупаем дешмансий коммутатор. Режем провод где-то в райне средины обжимаем 2 пары 2 пары оставляем в воздухе, обрезаем коннектор от блока питания и припаивае к свободным парам и втыкаем в коммутатор. В другого конца шнурка припаиваем бп к парам идущим на разьем питания и так же 2 пары в коннектор. Такой коммутатор может болтаться в любой ж... :) В первых локалках междомовых они даже в целофанавых пакетах на шнурках между домами болтались :)

Такое обычно происходит, когда запрос кидается в lifecycle-хуках, которые могут сработать много раз (например, updated), либо в watch. И когда у вас что-то ошибочно повторно перерендерится, то может бахнуть второй запрос. Дабл-клик по кнопке, которую вы не выключаете сразу после первого клика также не исключается.

Насчёт идентификатора вашего ничего не могу сказать, потому что не вижу, где и как вы его генерируете.

Дебажить, дебажить, и ещё раз дебажить VUE.

1. Если есть возможность запустить фронтенд на локалке в development environment, установите в браузер плагин Vuejs devtools, и посмотрите поведение компонента, кидающего запросы, может быть там что-то увидите.

2. Откройте devtools браузера и на вкладке Network и кликните ссылку в колонке Initiator (не знаю, как по-русски, не пользуюсь русским в браузере) у этих повторяющихся запросов. Если будут показаны разные участки кода, значит, где-то еще в коде затерялся такой же запрос.

3. Самое простое: прямо перед строчкой с вызовом запроса axios (прямо перед запросом, в этой же функции, не где-то вне её, а прямо в предыдущей строчке) напишите банальный console.log("Gotcha!!!!"). Если сообщение в консоли браузера появится дважды, значит, проблема исключительно в логике вашей программы.

4. Если ваш ID действительно генерируется прямо рядом с вызовом запроса, прямо в той же самой функции (что исключает баг с тем, что в запрос подставляется где-то сохранённый и кэшированный фреймворком ID), и это действительно подлый Chromium повторяет запросы из-за крайне нестабильного коннекта у пользователя, то тогда генерируйте ID не просто рандомом, который всё же может повториться, а сгенерируйте нормальный UUID, вероятность повторения которого ЗНАЧИТЕЛЬНО ниже. При приходе запроса сохраняете этот UUID на короткое время где вам удобнее, и если придёт такой же запрос с таким же UUID, то не обрабатываете его. Этот же UUID вам может помочь и в других аспектах: например, вы можете его использовать как "Correlation ID" данного конкретного запроса. Его можно отражать в логах, передавать в другие сервисы, если у вас их несколько. И тогда вы сможете без проблем отслеживать жизненный цикл каждого конкретного запроса.

Не сочтите за дерзость. Идете в аптеку, и ....
Правильно!
Покупаете самую большую клизму!
А лучше три.

Сила кулака, и никакого мошенничества. И для здоровья полезно :)
Носик можно немного подрезать, если отверстие маловато.

ЗЫ. Можно конечно не клизму, а "резиновую грушу для продувки техники", но это все та же клизма, только в 2-5 раз дороже.

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

Похоже на проблему с файловой системой. Может с правами что-то не так.

с коллегами не согласен. это магия, затрудняет чтение кода. преимущество в простых случаях - нет лишней строки

геттеры и сеттеры именно для этого и нужны - чтобы далеко далеко в будущем, когда будет много других классов, и которым нужны эти данные, и вдруг тип данных нужно будет поменять (например перейти от int32 к int64), то будет достаточно просто поменять тип приватных данных, поправить геттеры, чтобы они конвертили в int32 для старых зависимостей и сделать два новых 64-битных геттера для новых.
И потом уже все кто лазили за данными, либо будут потихоньку переходить на новые геттеры, либо сидеть на старых, но с ограничением.

Если у вас 2.5 класса, можете делать как угодно. Смысл геттеров и сеттеров изначально именно в том, чтобы обеспечить совместимость на десятилетия вперед.

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

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

Правильно сказал. Через полгода у вас эту модель удалят. Или изменят. Придёт новый человек и попробует у себя развернуть проект и накатить миграции - получит ошибку. Как ее побороть? Искать в миллионе коммитов как эта модель выглядела?

Правило общее для всех языков и фреймворков. В Гугл вбейте don’t use models in migrations получите ответ.

Передайте преподавателю, что его задания устарели лет 20 назад.

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

Самый адекватный вариант - тупо спросите "можно воспроизвести звук?". Уверен что 99,9% пользователей не будут рады левым непрошенным звукам на сайте, через что бы они там не выводились...