mayton2019

Если зобанят по причине VPS то и все сайты попадут под бан. И наоборот. А так... да раскатывайте хоть сотни задач на одном хосте.

Вот. Не благодари

private void SendScreenshot(Socker handler) {
 ....
}

и handler не закрывай.

Поскольку на вопрос никто не писал ответа - я напишу вариант.

Это не совсем ответ. Это скорее список сомнений.

Дело в том что BigData в принципе не работает онлайн. Тоесть нельзя запускать анализ в ответ на мышко-клик пользователя и ожидать что это будет меньше 2.5 секунд. Таких задач никто не ставит. Если хотят чтоб пользователь что-то быстро получал - то готовят DataMart, OLAP-cube, или некий Gold (золотой) уровень материализовнных таблиц в парадигме lakehouse. Тоесть грубо говоря готовят данные к выдаче. Что только взять по ключу и показать. И на этом уровне обычно не ставят parquet а берут CosmosDb+Redis (key-value) чтоб браузер не ждал долго. Никаких агрегаций здесь быть не должно.

Как подготавливать эти уровни серебрянного или золотого представления данных - это отдельная задача. Есть микро-батчи или стриминг но в общем и целом нельзя делать в ответ на действие пользователя. Это делает pipeliene.

Второе. Как уже верно было подмечено "Сервер 4 ядра, 16 гб оперативки" - это не конфигурация для Spark. Это просто какой-то сервак. Spark - это кластерная система и он имеет преимущества при работе в "импульсном
режиме в кластере" но ей нужен пул рабочих машин (хотя-бы штук 4-8) и файловая система наподобие hdfs или ее более современные вариации (s3/msBlobStorage). Это очень важно. Иначе не будет скейлится I/O.

Третье. Паркет (parquet) вообще имеет сильные преимущества когда вы выбираете 45 столбцов из 4500. В этом случае дисковая оптимизация сработает лучше чем у реляционных систем и выберет ровно столько IOPS сколько надо для публикации именно 45 столбцов. В остальных случаях паркет только фейлит и лучше вам брать AVRO например или реляционные БД.

Четвертое. Партишенинг. Очень часто бизнес запрашивает данные которые физически можно консолидировать по партишенам. Тоесть если ваш parquet-файл разрезать на периоды и допустим продукты то мы получим следующую физическую структуру файлов:

sales/year=2022/product=001/part-00000-a11a0ce2-ea20-4897-a713-130a6538cd9a-c000.snappy.parquet
sales/year=2022/product=002/part-00000-a11a0ce2-ea20-4897-a713-130a6538cd9a-c000.snappy.parquet
...
sales/year=2023/product=500/part-00000-a11a0ce2-ea20-4897-a713-130a6538cd9a-c000.snappy.parquet

Эту структуру я придумал с головы. Но у вас есть много вариантов как комбинировать продукты-менеджеры-заказчики-отчетные-периоды.

И есть предположение что в таком случае операции агрегации пройдут быстрее за счет естесвтенного физического партишеннга. (Это я говорю для Spark. Для его оптимизатора. Как будет в Panadas я не знаю.)
С точки зрения Spark - структура файлов в таком формате рассматривается как партицированная табличка в оракле. При этом надо конечно помнить основные правила HDFS и биг-дата. Никаких мелких файлов! Вы должны расчитывать в 128Мб как в самую мелкую единицу I/O.

Пятое. Я это не использовал. Но посмотрите в направление библиотеки Apache Arrow. Она имеет сильные оптимизации для векторной алгебры и знает в лицо parquet. Если вы все-таки хотите оставаться в той парадигме выдачи запросов Python/Django/Pandas - то исследуйте как arrow может ускорить ваши операции агрегаций. Только вам возможно придется отказаться от Pandas-DataFrame API а использовать что-то низкоуровневое типа С++ для векторизовнного API.

Как видите - векторов развитя много. Думайте.

UPD:

Задача распознавания образов (а именно так звучит на самом деле постановка) имеет очень мало отношения к C#.
Я-бы советовал автору вообще забыть про C# а искать сверточные (convolution) нейронные сети которые ищут в картинках нечто знакомое на любых (на всех языках разработки). Когда стоит такая амбициозная задача - то нужно вообще забыть про язык и мыслить категориями математики и известрых алгоритмов НС.

Задача сразу скажу - сложная. И на 99% - кастомизируемая. Тоесть вы не найдете готовых шаблонов или походов к решению. Вы будете почти все делать самостоятельно. Особенно в части обучающей выборки и методики обучения. И в части выбора качества модели.

С высокой вероятностью вы найдете примеры похожих решений на Python/OpenCV.- Ваша задача будет заключаться в поиске полезного что можно почерпнуть из готового метода. И уже потом адаптировать под C# что можно из этого стека. Но опять-же ... C# здесь совершенно вторичен.

Все разработчики раз в жизни сталкиваются с календарными расчетами. И прежде чем решать что делать с 31 января - задайте себе вопрос - а что за дата будет опубликована? Дата сервера? Дата клиента? Это могут быть разные даты. Вспомним что люди живут в разных часовых поясах.

Поэтому задача смены января на февраля - это игрушка. Это не настоящая задача. И надо обсуждать ее чуть более глубоко.

Технически, выгодно установить redis или memcached и класть данные туда и запрашивать оттуда с указанием времени жизни для каждой записи (expiration = 10800 seconds)

$ redis-cli ......
set key ${city_id} ...... ex 10800

Я-бы не хотел быть медведем который оказывает медвежьи услуги. Но индексирование например
текстовых документов в некоторых системах текстового поиска - предполагает хеширование токенов.
Там 18-20 битный хеш. И ограниченное число токенов в индексе документа изначально. Но это не мешает
системам текстового поиска нормально работать. Погрешность есть - но небольшая. Особенно
когда вы указываете 2-3 токена для поиска и результат поиска можно еще фильтрануть.

Вот. Это была лирика.

Но что-то мне подсказывает что техническое задание недостаточно проработано. Я объясню свою
мысль. До обучения выборка должна быть разделена на две части. Обучающую. И контрольную.
И на этом этапе можно сделать подсчет фичей.

Это - требование. Иначе как ты сделаешь контрольную проверку что твоя модель - добротная
и заходит в критерии приёмки?

Вообще нейросеть это пока не система реального времени. Поэтому не надо требовать от нее мгновенных
ответов пока она еще находится в процессе обучения. И не надо ставить задания типа сделайте
мне "хоть какую угодно НС" которая на выходе выдает "ЧТО угодно".

1. Какой шанс попасть на Джуна в 35? (это с расчётом что мне год-два учиться) Если шансы небольшие, то как обстоят дела с фрилансом, есть смысл?
2. За сколько примерно времени можно обучиться до уровня Junior, если я буду тратить по 20 часов в неделю? Или этого совсем мало?
3. Что выбрать - Frontend или Backend? Какие специалисты более востребованы и кому легче найти работу? Насколько важно знание математики в backend'е?

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

Сколько времени обучаться - я не знаю. Тут может от 1 месяца до нескольких лет. Я-бы не стал делать какие-то ставки на время обучения. Тут важет факт захода в новую должность. Подучишся параллельно. Мы все учимся задним числом. Тоесть заходим на проект почти нулями и догоняем в процессе. Это нормально. Когда забегает менеджер и спрашивает - "так кто знает Scala/Hadoop" - я поднимаю руку хотя я ее нихрена не знаю в полом объеме но у меня есть в себе ожидания того что я могу быстро догнать те пункты которых еще не хватает.

Кстати друг рассказывал. Аналогичная ситуация в гейм-деве. Никто не спрашивает 100% объема знаний фичей С++. Это реально сложно знать все. Зато интересуются например знаешь ли Unreal Engine. И второе в данном кейме перевешивает первое. Тоеть знания языка были вторичны.

Что выбрать - Frontend или Backend. Честно скажу что мне бекенд интереснее. Там - много ресурсов. Как говорил мой шеф - процессорА-винчестерА-стриммерА. Там - можно широко применять знания алгоритмов и структур данных и эти знания сцуко РАБОТАЮТ. Во фронтенде - нужно в первую очередь знать как работают современные стандарты верстки и знать JS. Лично меня разработка на современном фронте вгоняет в депрессию. Эта чехарда фреймворков .. эти React/Angular/Vue и все постоянно меняется. Ты пытаешся зацепиться за какую-то концепцию или занния ... но сами фронтовики эти знания разваливают и переключаются на что-то новое каждые 2-3 года. Вобщем упаси бог от таких революций. Мне фронт был понятен лет 20 назад когда это был html+css+js и в том виде как его делают сейчас сложно все знания собрать и систематизировать.

По поводу математики. В большинстве проектов (8 из 10) ябы сказал что тебе хватит школьной математики. Никто звезд с неба не хватает и большая часть приложений электронной коммерции использует 4 математические операции и расчет процентов. Я лично знаю десяток синьоров-помидоров которые даже и не помнят что такое синус или среднее квадратическое отклонение ряда, но нормально себя чувсвтуют и зарабатывают. Вобщем финансовая арифметика базируется на очень простой математике. Если что-то и будет сложнее - то оно как правило завернуто в коробочку фреймворка или либы. Вот сейчас даже ML с нейросетями продают как библиотеки к python и я готов спорить на виски что мамкины-питонщики даже понятия не имеют как оно работает под капотом. Когда я учился мы изучали что такое многслойная НС и как она учится а когда курсы готовят МЛ-ликов - они дают им просто коробочные названия технологий и дают сами коробочки.

Есть ли смысл начать с фронта, и далее по ходу дела учить бекенд? Однозначно да.

Нужно дейстовать как делают сисадмины. Собрать сначала все сведенья. Что за линукс? Минт - это просто маркетинговое название. Для фикса проблемы - ничего пока нет. Нужна модель-версия ядра с точностью до билдов (uname -a). Потом обновить всё. Вообще всё. (apt update && apt upgrade). Потом посмотреть версию модель принтера и версию дров принтера (lp, lpadmin, lpstat). Вот иди по ключевым словам в гугл и копай.

С подшивкой всей этой информации сюда приходи.

P.S. На командный пункт меня доставьте...

Есть две функции и класс сервис. Для упращения функцию сервиса буду называть ФС. Так вот обе функции одинаковые до момента использования ФС в функциях. Как быть в таком случае? Делать абстрактный класс и абстрактную функцию, где будет вынесен общий алгоритм. А в абстрактной функции сделать вызов функции. Это нормальная идея или нет?

Здесь - недостаточно информации. Можно начать с того что нет даже оснований для ООП.
Есть просто какая-то функция которая висит в космосе. Ты можешь ее просто объявлять функцией.
ООП не запрещает функции.

Кстати по поводу ООП. Нет канонического рефакторинга для ООП. Обычно все учебные ООП
примеры - применительны к конкретным языкам. На примерах всегда пишут Джош Кериевски,
Мартит Фаулер и Дядя Боб. Поэтому чтобы дальше обсуждать твой вопрос предметно - нам
нужны сорцы.

Иначе получается битва телепатов. Мы тут мним твой исходник каждый в своём языке.

Поскольку случай - очень простой, то он решается шаблоном. Но если вместо а или б может быть
тоже выражение - тогда нужно определять свою грамматику. Например:
min ( min(a,b) , min (c,d) )
Тогда умные дядьки-теоретики берут язык описания грамматик. EBNF типа. И пытаются
свой новояз описать в терминах например EBNF https://en.wikipedia.org/wiki/Extended_Backus%E2%8...
Описывают что такое число. Какое оно. Отрицательное? Вещественное? Экспоентциальное?
Короче надо описать вообще все что может быть. Описывают функцию минимума.
Потом по этой грамматике создают парсер. Программно. И парсер на выходе выдает
дерево. Где корень - это вся грамматика а на листиках будут висеть числа. Или терминалки не помню
как они это называют. И вот когда ты уже получил это чортово дерево - можно ПРИСТУПАТЬ ко второй
части задачи - а именно к транформации в инфиксную форму. Но ты сначала реализуй хотя-бы первую
часть.

Это все теория и она требует погружения. Я думаю что эта задача и ей подобные в частных случаях
решаются проще. Если например твой язык поддерживает регулярки - то перечисли макс. число
вариантов что будут на входе и выбери через матчинг подходящий. Это - быстрее.

Эта команда - опциональная.
CREATE TABLE IF NOT EXISTS users
тоесть она могла и не выполнятся. А если она не выполнялась - то очевидно что существует другая таблица users.

Давайте смотреть что в этой другой таблице. Автор неужели ты не мог логгирование добавить? Этож просто. Хоть бы знали работал ddl или нет.

А попробуй сделай
$ git gc

Задача - вообще не про регулярки.

Нужна база корпоративных почтовых доменов. Поищите в открытом доступе. Сейчас есть много источников.
Я в пиратской бухте находил антиспам стоп-листы и целые базы различных больших данных частными адресами.
В учебных ресурсах по биг-дате может быть. Поищите на kaggle.

Приготовтесь к тому что данные будут грязные и нужна будет какая-то очистка.

Задачу можно решать многими способами. Например. Рассмотрим векторы образованные центром O(ox,oy) и точками A(ax,ay), B(bx,by). Их сумма по правилу паралеллограмма даст нам направление для биссеткрисы угла
которая образована AOB. Уравнение биссектрисы будет известно.

Решаем пересечение этой прямой с окружностью и получаем искомый центр дуги.

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

Что еще плохо. В этой задаче на самом деле не одна а две дуги. Но мы каким-то образом должны догадаться что речь идет о малой дуге. Об этом - тоже надо сообщать. Это раздражает.

На будущее - оформляй задачи как в задачнике.

QAM4 - можно рассматривать как QPSK, которую в свою очередь можно рассматривать как 2xBPSK, т. е. как два независимых сигнала Cos и Sin одинаковой частоты и амплитуды, но сдвинутых по фазе. Иными словами, решить систему уравнений вида sin+cos=A. В любом случае вы вычисляете точку на созвездии, а затем принимаете решение, какой именно из 4 фиксированных эта точка является.

Да. Я решил умножать измеряемый сигнал скалярно на синусоиду и косинусоиду. Для простоты Это будет
вектор кратный периоду семплов. Причем максимально большой чтоб не делать лишних расчетов.
И максимально маленький чтоб не превышать половину (или меньше) импульс модулирующего.
В результате получим набор звездочек. Они будут прыгать и плавать по комплексной плоскости и дальше
надо будет угадывать что есть что.

1) Маркировать начало передачи или иным образом синхронизировать такты (фронт волны).
2) Детектировать условия среды передачи. Зная отправленный и имея принятый синхросигнал, можно определить параметры среды и определить корректирующие коэффициенты для дальнейшего приёма. В данном случае, это будет нулевая фаза и амплитуда.

Я думал так. Пускай QAM фазы кодируют 00,01,10,11 биты соотвественно. Тогда пилот-тон будет длинной последовательностью (3 секунды) фазы 00 после которой любое изменение будет означать начало передачи.

Если в пилоте фаза 00 сместится с 45 градусов допустим на 130 - мне будет пофиг. Я просто буду считать ее
началом отсчета. Вычту из всех фаз 130. Ф1 = 130 градусов.

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

UPD: Не туда закинул. Модератор перекинь пожалуйста в комментарии.

Для начал посмотри что в них внутри. Вот как тут пишут https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlo...
Может это и не ты накрутил а просто новая версия прикладного софта работает. Что-то обновляет интенсивно.