mayton2019

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 и я готов спорить на виски что мамкины-питонщики даже понятия не имеют как оно работает под капотом. Когда я учился мы изучали что такое многслойная НС и как она учится а когда курсы готовят МЛ-ликов - они дают им просто коробочные названия технологий и дают сами коробочки.

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

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: Не туда закинул. Модератор перекинь пожалуйста в комментарии.

Я попробую рассказать своё видение проблемы. Я не уверен что я прав но напишу как мне кажется.

Есть две модели представления нейронных сетей.

1) Матрицы (иногда называют тензоры). Имеют аппаратную реализацию в новых TPU (Tensor processor unit). Кажется Гугл сейчас продает услугу аренды таких сетей для задач обучения. Подходят для плотного заполнения нейронных слоём когда нейроны связаны каждый-с-каждым. При этом даже если связи нет (коэффициентик равен 0.0) тем не менее пространство все равно используется и этот ноль участвует в расчете.
Расчет обучения (как я его себе понимаю) должен сводится к перемножению входного векртора на всю полседовательность матриц. И также к применению функции активации между слоями. Имеено за счет функции активации и идет обучение (там есть своя доказательная база) и идет декомпозиция на слои. Если бы функции не было - тогда можно было-бы все слои (константы) схлопнуть в 1 большую матрицу. Вот так и бегает умножение туда-сюда. Обучение - проверка ошибок. Коррекция. И снова обучение.

2) Графы. Это вырожденный вариант матриц когда нулей оооочень много то чтоб зря не меремножать нули можно модель вычислений представить в виде графов. Математически это дает экономию в виде пропуска ненужных вычислений. И должна быть экономия в виде памяти для коэффициентов каждого слоя. На практике представить граф компактно очень сложно. Если кто из вас делал свои графы - то вы знаете что жрут они память как в не в себя, и никогда не угадаешь сколько надо выделить под вершину или под ребро чтоб не было пере-аллокаций и потерь.

Если вы хоть раз открывали учебники по НС типа Каллана или Хайкина то там с первых страниц идет описание
персептрона или 1-слойного нейрона в виде рисунка со стрелочками. Это и есть граф. Таки рисунки любят преподаватели в универах и всякие теоретики.

В старых математических пакетах (еще в 80х годах) есть целые мат-библиотеки которые работают с разреженными матрицами (sparsed matrices). Это - тоже наивные попытки создать экономию. Такая дырявая матрица как раз отражает граф где вершины - это столбцы и строки а рёбра - это ненулевые коэффициенты.
Реализаций их - целая куча. Математики любят решать системы дифуров в таких структурах. Там своя специфика. Тоже есть много нулей. Тоесть между графом и дырявой матрицей есть полиморфизм.

Есть поддержка таких дырявых структур (Vector.sparse) и в биг-дате (Spark). Тоже для нужд ML.

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

Все что я написал это просто моё чортово ИМХО. И не стоит это воспринимать за правду.

Но если у нас вдруг совпадут хэши то возникнет коллизия, и тогда у нас есть 2 метода её обхода, 1 - открытая адресация 2 - связанный список.

Да. В связном списке всегда хранятся и ключи и значения. В противном случае вы не докажете что нашли верно.

UPD: Обновление. Поскольку я был неверно понят комментаторами - я обновляю цитату. Мой комментарий относится ко второму алгоритму. А точнее к структуре данных. В данном случае к связному списку который реализован в 99% хеш-таблиц в Java/DotNet.

Автор, намешано конечно у тебя в списке.. ой-ой. Но если интересуешся веб-протоколами - посмотри
еще на GraphQL https://graphql.org/ я думаю он очень интересен для современного разработчика.

Еще посмотри на QUIC для общего развития https://cloud.google.com/blog/products/gcp/introdu... там интересно.

REST - это вобщем-то не протокол а скорее философия или архитектурный подход к работе с http. У него - очень размытые границы в реализациях. И иногда сложно взять приложение и классифицировать что оно такое. Рест или не-рест. Рест использует коды ошибок из HTTP и поэтому существует только в слое http.
В теле REST сообщения может быть что угодно. XML, JSON или просто текст. Неспецифицировано короче. Наивные попытки внести в рест спецификации появились сравнительно недавно. Рест хорошо интегрируется с балансерами и реверс-прокси (nginx).

SOAP - это именно "протокол". Базируется на XML с жесткой схемой. Причем работающий почти на всех слоях сетей. Может на не только по HTTP но и по сырым сокетам бегать. Хотя в настоящее время - непопулярен. Типизирован. Имеет специальный файл спецификации (WSDL) который точно описывает все сигнатуры методов. Требует большой аккуратности в реализациях. И обычно никто не пишет SOAP клиент-сервер вручную а пользуются генераторами API. Часто используется в банках и крайне консервативных ведомствах.

Оба варианта хорошие. Но обычно если ты работаешь отладчиком и тебе
интересно где логика ведет себя не так - то второй вариант удобнее.

Однострочники хороши только когда ты досконально понимаешь
что внутри них происходит.

Алгоритмы и структуры данных тесно связаны с зубо-дробительными бенчмарками. Как-то отсортировать терабайтный текстовый файл или найти два одинаковых числа в файле из чисел тоже большого размера.
Иногда такие задачи задают на собеседованиях Google и Microsoft.

И если вы будете изучать эти алгоритмы на js, то вы не сможете продемонстрировать эффективность этих
алгоритмов. Python машина - просто медленная. У нее конечно есть надстройки например над векторной
алгеброй которые позволяют быстро считать рутину вроде циклов над векторами. Но является ли это
программированием Python - чорт его знает. Как по мне - нет. Тут - другая экспертиза нужна.

В структурах данных важно также оценивать память "на глазок".

В этом смысла кодер С++ имеет много преимуществ т.к. он видит и понимает как распределяется память
в узле бинарного дерева например (два указателя по 64 бита + какой-то размер для ключа который тоже
можно посчитать). Какой аллокатор брать? Встроенный в язык new или нужно делать собственный.
Такой расчет важен для оценки например - применима ли структура данных вообще?
Какой толк от дерева если оно не влезет в оперативную память? А падение памяти в swap - тут-же замедляет
алгоритм в разы.

JS и Python не предоставляют тонкого контроля над памятью. У них своя модель построенная для комфорта
самого процесса разработки а вовсе не для струткуры данных.

Скорее всего вам это не надо. Внешний анализ заказывают банки например чтобы подтвердить что софт - безопасен и не боится эксплоитов. Из таких систем я помню платную Veracode. Она находила у нас ошибки безопасности в логгировании (!).

Вот. Из безсплатных - посмотрите SonarQube. Он работает с плагинами.

Да и очень полезно указывать конкретные теги языков. Что там у вас? 1С? Кобол? Или Лого?

Я серъезно! Почему не указываете?

Вопрос лишен смысла.

С точки зрения современного собеседования знания языка являются просто началом собеседования. На самом деле собеседуют по стеку технологий который нужен на проекте. И из 2х часов технического собеса где-то 30 минут тебя могут гонять по языку. Всё остальное - по сопуствующим технологиям. Тоесть например ты заявил что Java developer уровня Junior. Окей - расскажи что такое Object, какие у него методы. Зачем нужен hashcode. Ответив на эти вопросы тебя пойдут гонять по другим технологиям. Spring. Hibernate. Beans. Базы данных. Web. Html/CSS. Json/Xml. CI/CD. Тестирование. Алгоритмы и структуры данных. Отладка.

Грубо говоря язык это просто некая составляющая стека. И когда ты готовишся к собеседованию - готовишся ко всем вопросам. Обычно платная школа или курсы - тебе обеспечивают обучение всему стеку.

И не существует других кейсов применения языка. Тоесть программист просто выучивший язык никому (!) не нужен вообще.

Не хватает тегов в вопросе. Это относится к конкретному языку программирования. Например в С++ шаблон такой. В Rust - другой. В golang - третий.

Обычно консольное приложение - не создает окон. Обычно оно в себя включает обработку консольных аргументов. Например если юзер печатает "--help" вторым аргументом - то приложение печатает справку по командам. И обычно (99%) приложение оперирует потоком вывода (STDOUT) для облегчения взаимодействия с другими CLI приложениями.

Например когда вы делаете cat (concatenate)
$ cat file1.txt file2.txt > union.txt
и "птичкой вправо" выводите сцепление двух файлов в новый файл.

Еще приложение может в качестве input читать STDIN и еще может в случае ошибки возвращать
ненулевые коды возврата. Это - полезно чтобы CLI приложение интегрировать с bash скриптами
и проверять был ли успешен последний вызов.

В задаче есть такая матрица выбора. По горизотнали - технологии работы с USB/COM/TCP/UDP. Их много. Но в простом варианте (если бы ком-порты стояли в железе) то линукс бы видел такие устройства-файлы.
/dev/ttyS[0123]
И это было-бы прекрасно. В духе линукс. С переходниками и адаптерами - сложнее но принцип наверное такой-же.

И второе измерение матрицы - это собсно на чем делать UI. Конешно если автор знает делфи - то пускай берет лазарус и кодит. Но я-бы предложил рассмотреть вариант веб-интерфейса. Это - более современно и вообще веб-интерфейсы сейчас имеют вид - более привлекательный чем Windows95/Delphi лет 20 назад. По картинке с железной дорогой - вроде ничего сложного нету. Сейчас браузерны игры и то посложнее выглядят. Вот как-то так.

Что вы издеваетесь над парнем. Пускай найдет скан-копию любого паспорта. Кто там проверять-то будет :)

обязательно ли именовать пакеты в Java именно так "com.javastart.NAME"

Их можно именовать как угодно. Просто если делать интеграцию твоего приложения с другими
библиотеками то конфликтов имен можно избежать если всегда добавлять домен + твое имя.
Это практически всегда уникально.

Я уже устроился на работу по специальности в крупную официальную компанию по специальности и успешно прошёл стажировку

Ну вот если устроился и работаешь - то тебе вроде как оно и не надо. За образованием идут в двух случаях. Первое - это корочка которую требуют родители например или консервативное общество. Или гос-контора обязательно спросит ксиву при попытке туда устроиться (я-бы эту возможность не отбрасывал). И второе - эт собственно технический пласт знаний. Люди по разному учатся. Я-бы не смог учится УЖЕ работая. Это как мне кажется такой разрыв смыслов. Вот на работе тебя поставят за станок с ЧПУ и ты будешь знать досконально как ДАННЫЙ станок работает. Может даже станешь мастером по наладке. Но вот принципы на которых этот станок работает - тебе никто никогда на работе не расскажет. И не потому что это тайна. Просто всем некогда. На работе е6ошить надо как говорил мой шеф. А не книжки читать.

Вот и думай себе. Кумекай что тебе на самом деле надо. Я знаю очень многих людей которые только в 40 лет осознали как много они не знают и что им реально нужно было когда-то ... давно получить это самое образование. Кусали локти потом. Но уже была семья.. дети.

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