Михаил Р.

Выбираете элемент через инспектор в DevTools. На вкладке Event Listeners ищете нужное событие и нажимаете по ссылке на исходник.

В путях используйте r.

song = pyglet.media.load(r"C:\Users\Station\Music\padenie-truby.mp3")

для удобной поддержки и масштабируемости

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

1. Уже есть
2. Кому надо - те вполне могут и впн включить

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

У вас запросы – исключительно информационные. Тут лучше всего работает soft-алгоритм, где вся цепочка - по связи каждого запроса с хотя бы одним другим.
В инфо-сегменте кластеризация по топам сейчас – заведомо проигрышный вариант. Намного лучше работает
а) Связь по интентам целевой аудитории, то, что они хотят узнать для своих задач.
б) Семантические связи, не статистика. Посмотрите на скриншот: те запросы, что имеют связь ниже 0,9 – вероятно, другой суб-кластер, хотя ничто не мешает обе этих группы объединить в одной статье.



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

с телефона образуется сначала множество DNS-запросов к несуществующим доменам типа f03ef30f-719a-4fa6-b084-4682851d9698.local

Bonjour/Avahi мультикаст DNS (mDNS)
Вполне прогнозируемое поведение, посмотреть а нет ли случаем в ближайшем окружении мультикаста с просматриваемым контентом.

а затем многочисленные UDP-подключения к самым разным IP-адресам и портам >10000

скорее всего пиринг

для WEB пентестера

Очевидно, что да

Был фидбек, не был фидбек, не нужно воспринимать все это на свой счет. Больше, активности. Представь себе, следующую ситуацию, баскетбол. Тебе нужно забить три трех очковых подряд, это не просто. Чем больше попыток, зайти на страйк, тем больше шансы. Рецепт один, больше откликаться, выполнять тестовые задания, пытаться удивить в тестовых заданиях и т.д.

Твоя цель - оффер, и все посторонние мысли о справедливости, какая компания, какое тестовое и т.д. Они только отвлекают и мешают.

когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно

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

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

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

Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.

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

И вот здесь основные сомнения: сделать выборку из 15 000 строк быстрее, чем из 60 000 (и будет больше) с WHERE city='spb'. На старте хотелось бы сделать правильно, чтобы при последующем развитии не упереться и переписываться все заново.

Современные бд вообще с такими объемами смешными справляются достаточно легко, скорость может проседать в районе миллиона записей (утрированно, но где-то близко к истине), и там уже надо думать как это хитро индексировать/шардировать или тюнить железо/софт (естественно и тестовая машина должна быть какой-то адекватной конфигурации). По этому такая экономия на спичках по итогу выйдет боком. Собственно вам ничего особенно не стоит создать фейкером 15/60К записей со связями и прогнать эксплэйн на запрос, посмотреть чего в индексах не хватает, как быстро идет выборка... И WHERE city='spb' скорее всего вам аукнется, нужно связывать со справочной таблицей городов и соединять по айди-сити_айди, или через пивот, если у товара может быть больше одного города.