German Jet

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

> нажимаю enter он отправляется на роутер
он отправляется первым делом на матрицу коммутации подключённого с противоположной стороны кабеля устройства: роутер это или коммутатор - не принципиально. главное - что речь не о сети из двух компов.
> ,роутер ищет в подключениях такой же mac адрес
встроенный в роутер коммутатор ищет
>не находит ,роутер по патчкорду отправляет кадр на свитч на чердаке
встроенный в роутер коммутатор рассылает полученный ethernet-кадр далее по всем своим портам, к которым что-либо подключено, кроме того порта, с которого пришёл кадр, и, учитывая, что коммутатор не сам по себе, а в составе роутера, то ещё и кроме портов, которые в настройках роутера отнесены к другим широковещательным сегментам (т. е. к другой сети, к другому VLAN).
> ,свитч тоже не находит.куда перенаправляет свитч и как перенаправляет история умалчивает.
туда же, куда и в случае с коммутатором в роутере - на все порты, кроме порта-источника и портов, относящихся к другим VLAN (если свитч управляемый и поддерживает разбиение портов по VLAN). таким образом ethernet-кадр, будет распространятся по всей локальной сети от коммутатора к другим коммутаторам (и компам), и на каждом из них будет повторяться одна и та же процедура: при наличии в коммутаторе записи, соотносящей MAC-адрес назначения из кадра с каким-то портом коммутатора, кадр будет перенаправлен в этот порт, а при отсутствии такой записи - во все порты сразу, кроме порта-источника. если в этой локальной сети действительно есть комп с таким MAC-адресом - то кадр в конце-концов до него дойдёт, а если нету - кадр будет в итоге утерян.
> есть размытое объяснение что свитч перенаправляет его на какой то другой маршрутизатор районного далее городского уровня и т.д. перенаправляет вроде бы по wan сети но там скорость до 56 кбит/с а мне роутер выдает 100мб/с.
тут уже начинаются привирушки со стороны того, кто вам дал размытое объяснение.
если, как вы в самом начале упомянули, "есть какой то пакет езернета у которого есть какой то мак адрес получателя", то за предел локальной сети (т. е. через роутер) он не выберется. роутер, как и любое другое устройство уровня L3 (работающее с IP-адресами), принимает со своего встроенного коммутатора только кадры, MAC-адрес назначения в которых совпадает с MAC-адресом роутера, и отбрасывает все остальные. так что ни в какую другую сеть ваш кадр не попадёт, пока не переписать вами сказанное на "есть какой то пакет езернета у которого в качестве мак адреса получателя указан MAC роутера". вот в этом случае кадр попадёт на роутер, который извлечёт из него IP-адрес назначения и на основании своей таблицы маршрутизации направит его в одну из подключенных к нему сетей, подменив при этом MAC назначения на MAC роутера этой новой сети (т. е. того роутера в этой новой сети, на который он шлёт кадр), или прибьёт.
> хотелось бы послушать что происходит дальше
про то, что дальше в варианте "какой то MAC", я указал выше: не далее как в пределах одной локальной сети.
а если MAC указан правильный (а за это отвечает таблица маршрутизации компа, с которого отсылается пакет в начале), всё это повторяется какое-то кол-во раз в зависимости от длины маршрута, его правильности и наличия проблем в сети: с каждого нового роутера кадр шлётся на MAC следующего роутера, проходит через свитчи, и если нигде нет обрыва или иной неисправности, добирается до следующего роутера, на котором, в зависимости от IP-адреса назначения, роутер выбирает следующую сеть и меняет MAC назначения, или прибивает кадр, если в его таблице маршрутизации отсутствует маршрут до этого IP-назначения.
на литературу вам уже вроде скинули ссылок. там вы прочтёте и про все остальные возможные ситуации, такие как широковещательные кадры, зарезервированные мультикаст-адреса, другие зарезервированные адреса, ARP-кеш, ARP-прогрев, ARP-проксирование, различные вариации стандартов Ehternet-кадров и много чего ещё - общую схему я описал, но из неё есть эти и другие исключения.

если вкратце:
- отключить на кинетике NAT и настроить маршрутизацию между 192.168.2.0/24 и 192.168.88.0/24;
- настроить на микротике маршрутизацию между 192.168.2.0/24 и 192.168.88.0/24 и настроить NAT подсети 192.168.2.0/24 в интернет.

Если бы основной шлюз можно было бы вывести из IP-адреса, то его не требовалось бы указывать, логично? ОС бы всегда брала IP-адрес, определяла бы по нему основной шлюз автоматически...
Совершенно точно можно сказать, что в вашем случае адресом основного шлюза будет один из IP-адресов той подсети, из которой взят ваш статический IP-адрес, за исключением собственно самого этого адреса, а также двух граничных адресов: самого младшего в подсети (адрес сети) и самого старшего (широковещательный адрес).
Довольно часто адресом шлюза делают следующий адрес за адресом подсети (как, например, 192.168.1.1 в случае, если это подсеть 192.168.1.0/24), порой это самый последний перед широковещательным адресом (192.168.1.254), но в общем случае это может быть любой, удовлетворяющий требованиям, что описаны выше.
Если же адрес шлюза не известен, то он смотрится в конфигурации работающей системы (например, на соседней машине), либо получается по DHCP вмести с остальными настройками (если использование DHCP заявлено или подразумевается), либо узнаётся у провайдера, либо из договора или приложения к нему, либо у поддержки провайдера, либо у системного администратора предприятия...

Уважаемый, Вы уж определитесь, что конкретно Вы хотите
- Уволиться? Так увольняйтесь! Причем рекомендую "по-хорошему", без оскорблений и "хлопанья дверью" так как с нового места работы могут позвонить за рекомендацией. Мне звонили например, даже через пять лет после увольнения программиста. Да и велик шанс что с Вами не захотят расстаться, увеличат зарплату или большой начальник захочет узнать причину.
- Нагадить начальникам? Не получится! Пусть они будут трижды "бездарями", высшее руководство или владельца это устраивает. Сужу по своему опыту. (с компьютерами в 1986 года) Я был когда-то программистом FoxPro, БЭСТ 4, 1С 6.0, 1С 7.7, потом так получилось что стал сисадминить, поднялся до руководителя IT отдела. В какой-то момент - когда стали переходить на 1С 8 принял для себя решение, что даже не буду вникать в неё - других забот выше крыши. И для нанятого нового программиста я стал тем самым "бездарем" который "не понимает как оно всё работает, а только указания раздаёт". И он даже не раз ходил к владельцу Компании. Результат - я всё еще работаю, а он нет.
- навести порядок в цепочке "задание - результат"? Проще простого! После получения задания описываем этапы и ли ТЗ и передаём на подпись (бумага, почта, ЭДО) с обязательным указанием, что без подтверждения ТЗ Вы и пальцем не пошевелите для выполнения. Возникли вопросы или нюансы, которые от Вас не зависят? Также бумажка или эл.письмо с обязательным указанием остановки работы без получения ответа. Далее просто тыкаем всех этими бумажками. Очень часто руководство вчера хотело одно, сегодня второе, а завтра третье. Это нормально. Руководству вообще не нужно знать матчасть - его задачаа другая - денег заработать
- "в планах доделать всю работу для организации и уволиться с легкой совестью." - это утопия.
Пример: Внедрение 1С 8 заняло год, затем доводка, дописывание отчетов еще год. Прошло несколько лет, а мы всё еще обращаемся с программистам для доделок своих хотелок.
У меня есть несколько подработок по созданию и обслуживанию сетей и оборудования. Вылизанных! Работающих стабильно без моего участия месяцами. В одной такой конторе ВСЕ сотрудники кроме владельца, меня никогда в глаза не видели! Мне что - уволиться с легкой совестью и лишать себя подработки и денег на "ничегонеделание"?

"Топнуть ножкой" Вы всегда успеете.

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

Письмо, полное сомнений и множества вопросов. Я не совсем понял что требуется от нас. Если отвечать на главный вопрос - то да. Перспективно. Go драйвит Google как основной язык для микросервисов. Но учитывая возраст кандидата я-бы спросил следующее.
- как с английским?
- как быстро обучаешся чему-то новому?
- согласен ли на релокацию?

Какие перспективы в РФ - понятия не имею но перспективы в зарубежных конторах - есть.

Хочу предупредить автора об ошибках которые я сам совершал. Я думал что дело в языках и технологиях. Но это не так. Дело в коммуникациях. Я работал минимум с 5 зарубежными компаниями и я своими глазами видел что мои знания просто нивелировались на фоне например моего не очень сильного английского. А другие teammates в силу широких коммуникатиционных скилов могли очень быстро найти контакт с нужными людьми и обходили
меня в карьере достаточно быстро.

По сути когда тебе за 40 - вообще не имеет значения какой язык ты знаешь. У тебя за плечами должен быть уже
такой багаж что тебя можно просто брать как опытного советника в технических вопросах. Язык можно подучить но если речь идет просто о распределенных системах и микро-сервисах то больше знаний требуется в части например анализа узких мест системы. Кеширования. Грамотного дизайна безопасности и репликаций и бекапов и восстановления от сбоев. Этот пласт знаний вообще лежит вне языка. И поэтому джун даже очень хорошо выучивший Go или Python не может решать такие вопросы. А автор - скорее всего может. Барьером может быть
какая-то банальность. Например язык. Поэтому я и спрашиваю.

Azuracast... и локально запущенный VLC плеер - работает в более чем 300х точках по стране, удобные плейлисты итд

Radioboss если прям винду хочется

Список баз данных и дата последних изменений:

DECLARE @DBD TABLE ( [Name] VARCHAR(100), [Date] DATETIME)
DECLARE @N NVARCHAR(100), @D DATETIME
DECLARE @Q NVARCHAR(100), @P NVARCHAR(100) = '@DD DATETIME OUTPUT'
DECLARE DB CURSOR FOR
  SELECT [name]
    FROM sys.databases
    WHERE owner_sid <> 0x01
OPEN DB
FETCH NEXT FROM DB INTO @N
WHILE @@FETCH_STATUS = 0
  BEGIN
    SET @Q = 'SELECT @DD = MAX(_Date) FROM ' + @N + '.[dbo].[_UsersWorkHistory]'
    BEGIN TRY  
      EXECUTE sp_executesql @Q, @P, @DD = @D OUTPUT
    END TRY  
    BEGIN CATCH  
      SET @N = @N + ' Not 1C'
      SET @D = NULL
    END CATCH      
    INSERT @DBD VALUES (@N, @D)
    FETCH NEXT FROM DB INTO @N
  END
CLOSE DB
DEALLOCATE DB
SELECT * FROM @DBD
GO

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

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

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

Отделяй модуль/место сбора оперативных данных от их анализа, например делай две базы, отличающиеся как по месту размещения так и по типу (например оперативные данные можно просто собирать в ram, с космическими скоростями, без sql отдельным приложением-демоном), а аналитику собирать паралельно и периодически, под задачу.

Скажите что Вы оцениваете свою конкурентоспособность на рынке труда, чтобы идти в ногу со временем. Так как для IT-специалистов это нормальная практика

На самом деле интересный вопрос. Я вот, за всё время свой работы, интегрировал сайты со множеством сторонних систем по REST API. Потом, как-то на собеседовании, на вопрос типа "что вы знаете о REST API", на серьёзных щах, ответил, "да практически всё" и начинал перечислять всякие банки, платёжки, сервисы доставки и т.п. с которыми делал интеграцию. Как вам и написал キム ファイブプラス выше, у некоторых из них были весьма "хитровыдуманные" алгоритмы, одна только интеграция с ЕСИА чего стоила... Однако потом меня спросили: "а как бы вы сами осуществили API в каком-либо сервисе?"... И тут весь мой опыт предыдущих интеграций мне не особенно то и помог, т.к. осуществлять приём ответов откуда-то там -- это одно, а их отдавать и грамотно обрабатывать -- это совсем другое. Поэтому мой совет такой: для опыта интеграции ищите "openapi" у различных сервисов, интегрируйте себе на сайт, если он у вас есть, платёжку от QIWI, например (там есть работа от физ лица). А так же напишите собственное API. Скачайте программу postman, посмотрите какие бывают методы авторизации. Попробуйте реализовать парочку из них, и сделайте грамотную обработку входящих данных, а так же ответ на них, в стандартном json-e.

Раз у тебя возникают проблемы с таким тестовым заданием, то на работу тебе ещё рано.
В целом - гугли любое непонятное слово. Если не находишь "иерархические данные в Django", то попробую чуть более абстрактно. Например узнай, что вообще такое "иерархия".

В данном случае иерархия - это когда у сотрудника есть начальник, который тоже является другим сотрудником, у которого есть свой начальник и так далее, пока не найдётся главный начальник всех начальников.
И вот 5 уровней иерархии - это когда есть начальник(1) начальника(2) начальника(3) начальника(4) сотрудника(5).
В реляционных базах данных такую структуру можно получить при помощи всего одного опционального FK который указывает на собственную же таблицу.

Как заполнить базу - ну напиши ещё одну программу, которая сгенерирует 50000 записей с нужными условиями.

но как потом в api передавать иерархию сотрудников

Как будет удобнее - так и передавай, если в задании не указано, как именно нужно передавать.
Например можешь передавать как список сотрудников и список связей.
Можешь просто вернуть дерево (словарь)
Можешь вернуть список сотрудников, у каждого из которых будет атрибут с id его начальника.
И так далее.

И если вы знаток, то подскажите, это вообще тестовое задание на джуна без опыта (так указано в вакансии) или нет?

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