Как и в любой работе, все может различаться в разных компаниях. Основное, выбор модели и параметров её работы, и это может занять достаточно продолжительное время. В зависимости от выбранной технологии потребуются знание математики от просто хороших, до очень глубоких. Быть может потребуется и выбор самой технологии. Если вы тренировались с градиентным бустингом, то с нейронками будет совсем иное. Вероятно, также потребуется писать сопутствующее ПО: сбор, подготовка данных для обучения, автоматизация этих процессов. Стандартные навыки работы с бд, python, и вероятно какой нибудь Go. Если в ML то для работы будет какая нибудь Тесла.
Но основное, поиск наилучших результатов по точности и полноте, и оптимизация скорости работы.
mayton2019, язык - это просто инструмент, если не делать из языка культ, то разработчик берет тот инструмент, который наиболее удобен, знаком, доступен, лучше поддерживается, совместим и использует его здесь и сейчас. По-хорошему разработка должна вестись не на языке, а с его помощью. Есть объективные причины для выбора языка - производительность и скорость разработки. Есть менее значимые, но которые почему-то используют для дефирамбов в адрес того или иного языка. Что-то вроде: "вот здесь лаконичнее, чем там". Или "здесь, меньше возможностей совершить ошибку". Они субъективны, потому что очень проблематично определить возможность совершения ошибки, а лаконичность может напрочь убивать читаемость и т.п..
Я, конечно, тоже субъективно сужу, но Go и Python встречаю повсеместно, а Rust и Haskell днем с огнем не сыщишь. И как коммерческий разработчик, я делаю выбор в пользу первых. Но, для академических исследований, выбор может быть другим. Это не значит, что в коммерческой разработке никто не берет ничего нового, буть так мы бы Go не увидели, но предпочтут знакомый инструмент, с известными слабостями, чем претенциозный новый, где подводные камни еще не найдены.
Пока джентльмены из Глазго сидят в Хаскеле и думают как лаконичнее сделать функцию, пролетариат - херачит тонны кода.
Именно так, пока кто-то изобретает лучший мир, кто-то должен делать работу, нужную здесь и сейчас. Это не значит, что последние бестолковые чернорабочие. Просто, кто-то штроборезом не может ровно сделать штробу, а кто-то за не имением оного и болгаркой отлично ее выпилит.
mayton2019, Мартин примеры давал в ООП на Java, так что не в контексте Go. И там, насколько помню, вплоть, что отдельные команды засовываем в отдельные методы. Это действительно бывает оправдано порой, но я лучше в таких ситуациях перепишу все обращения, чем в остальных 98% случаев заранее наделаю множество методов. Да, конечно, не совсем соблюдаю open/closed принцип, но по мне это меньшее зло.
mayton2019, мы используем абстракции не ради самих абстракций. Использование абстракций - это попытки обобщенного программирования, для возможностей расширения кода основываясь на универсальных решениях, дабы не натыкаться на жесткую специализированность. И, согласен, далеко не всегда они нужны, фанатичное следование приведет к высокой раздробленности кода, это как Чистый Код Мартина - вроде бы очень универсально, но на практике не применимо.
Тем не менее, пользоваться консолью придется, т.к. это проще и универсальнее.
Cкорее всего драйвера non-free, поэтому посмотрите здесь https://wiki.debian.org/Firmware описание как они устанавливаются. Как минимум, на флешке они должны быть в директории firmware.
Сергей Горностаев, все языки можно разделить по задачам, где их применение оправдано, а где нет. Но, они от этого не перестают быть языками общего назначения. Каким бы общим не был Си, его применение ограничено, не потому что не может, а потому, что другие языки подходят лучше. Тупо, вы же не будете писать сайт на Си в большинстве случаев, перестал он от этого быть языком общего назначения - нет, не перестал. В отличии от каких-нибудь DSL, заточенных под конкретную задачу, или процедурных языков в СУБД.
Василий Банников, Сергей Горностаев, цитата может и верная, только вырванная из контекста, да еще и перевранная в эту чушь: "Go - это изначально узкоспециализированный язык, созданный лишь для того, чтобы слабые разработчики могли быстро начать писать асинхронные сетевые сервисы, который по недоразумению выпал в более широкую сферу применения."
Создатели языка писали совсем иное: один из аспектов успешности языка - это простота, чтобы молодые разработчики быстрее начинали писать коммерческий код, а не занимались академическими поисками "совершенного" языка. Причем это только один из аспектов, не единственный! Поэтому утверждение выше чушь. А как мы видим по успешности Go - его разработчики оказались правы.
Я ни сколько не говорю что Rust хуже, да и у Go хватает проблем. Но Go такой же узкоспециализированный как Си, в принципе как и любой другой язык. А ставить языку в упрек простоту - глупость.
И пока "гениальные" разработчики обвиняют Go в том, что он не "божественен", обычные разработчики, не делая из языка культа, используя этот инструмент успешно решили и решают множество задач.
rPman, сравнить 2 короткие строки должно быть быстрее, чем вызвать функцию, да еще и внутри чтото поделать. С id для классов очень странное решение, польза которого сомнительна, запутаться в id проще. Но с посылом согласен, очень странно, что методу без разницы строка или объект, и скорее всего это нужно разделить на 2 метода, а может вообще выкинуть вызов ненужного типа.
как минимум, вы выбрали режим работы tcp, следовательно haproxy в принципе не контролирует url и прочие http-шные штуки. К тому же, не очень понятно зачем для изменения url использовать балансировщик.
Но основное, поиск наилучших результатов по точности и полноте, и оптимизация скорости работы.