Comments 44
Сейчас же ситуация прямо противоположная: проще встроить готовый
инструмент/библиотеку и уже вот это всё корячить под себя, будет
банально дешевле.
он нас всех сдал!! теперь все узнают что мы только и делаем что обвязки для либ пишем...обработчик http подключаем к сериалайзеру, меняем два поля и через него сливаем обратно...а оно там само и tcp и роутинг и проверку форматов и поддержание сессии... а потом в отчете пишешь что потратил 100500 часов на борьбу с фрагментацией tcp и написание драйвера для оптоволокна
Так кем же в итоге я стал?
и кем? обычным программистом и стал с более расширенным кругозором
приобретает новый функционал и избавляется от багов
Типа добавляют новый функционал, без добавления новых багов?
А так разве можно?
Так кем же в итоге я стал?
Среднестатистическим прикладным Linux-разработчиком :)
На самом деле, подход "используй готовое" - это именно то, что называют Unix Way, а системное администрирование и серверное программирование в юниксах почти всегда тесно связаны. Благо, юниксовые шеллы имеют богатейшие возможности по организации последовательной обработки данных и взаимодействия между процессами. Поэтому с нуля пишется то, что действительно уникально (и часто отдаётся в опенсорс, если может быть полезно другим и не стоило $1M в разработке).
У меня история зеркальная по отношению к вашей - много лет занимался проектированием и разработкой больших корпоративных unix-систем, потом всё надоело, ушёл в стартапы, и внезапно столкнулся с программированием микроконтроллеров, открыв для себя много нового. Сейчас больше руковожу процессом и вернулся к верхнеуровневым системам, но хорошо понимаю, как должны работать устройства, которыми мы управляем, и как писать под них софт эффективно.
Наверное похожий на ваш случай я наблюдал 5 лет назад. Я тогда программировал на МК и в компанию пришел разработчик, который до этого занимался геймдевом. Для меня тогда это показалось странным, потому что органичным вроде бы кажется путь от низкоуровнего ПО к системному или прикладному для какой-нибудь ОС.
Причем уйдя из геймдева он проработал пару лет в фирме, занимаясь Embedded Linux на BeagleBone, а затем - ушел в микроконтроллеры.
Теперь я понимаю, что человеки видят развитие по-разному. И оказывается неважно, куда двигаться, в низкоуровневое ПО или наоборот - просто людям свойственно уходить от того, что приелось и пробовать то, что еще никогда не делал.
P.S. Очегь рад, что вы многое подчерпнули из работы с МК
И оказывается неважно, куда двигаться
Главное, чтобы было ново и интересно. Ну и денежно, по возможности :)
Тем более, что предыдущий опыт всё равно пригождается так или иначе.
P.S. Из МК сталкивался как с чипами общего назначения (STM32, NRF52, WCH), так и специализированными (GrainMedia, HiSilicon). Нордики до сих пор нежно люблю.
А насколько перспективна тема программирования для МК? Слышал неоднократно, что платят мало, геморра много и вакансий раз два и нету.
Да как раз нет, вакансий полно. Особенно сейчас, когда много проектов по импортозамещению и нужно переделывать софт под китайские аналоги. Или, например, сейчас распространненная тема - ПО для базовых станций, иностранных же нет, Так что вакансий много
Да, средний уровень ЗП всё-таки ниже, чем у прикладного ПО.
По поводу геморра - от работодателя зависит. У одних (адекватных и с достатком ресурсов) ты будешь писать только софт и отлаживать с осциллографом и мультиметром в руках, т.к. для работы с железом есть схемотехники. У других - будешь многостаночником: схему нарисуй, плату разведи, сделай трассировку, напиши код, отладь в лабе, отладь у заказчика и получи за это 40 тыщ.
Зависит от компании. У нас схемотехники отдельно, программисты МК - отдельно, конструкторы тоже отдельные люди, платят программистам МК на том же уровне, что и высокоуровневым фуллстекам, немного выше среднерыночных денег. Потому что всё работает на результат.
То есть, конечно, прикладники могут найти место с зарплатой повыше, но команда, интересные задачи и изобилие свободы людей удерживают.
В нормальной организации так и должно быть. Программист не должен разрабатывать схемы. А схематехник программировать. Т.к. одно из этих сложных занятий неизбежно будет происходить с падением качества выполняемых задач. Называю это "правилом одного дара" По аналогии с таковым в фэнтези книгах Ника Перумова. Там хороший маг не мог быть хорошим воином и наоборот.
И это выглядит странно сейчас, с учетом того, что реально спрос на такую разработку в РФ реально вырос сильно, а знаний и усидчивости, насколько знаю по знакомым, требуется не меньше.
Да, выглядит очень странно, согласен. Но могу скзазать, что на фоне ускоренного импортозамещения зарплаты в этой сфере подросли, но всё равно не настолько, чтобы тягаться с другими айти отраслями
Подтверждаю. Начинал с МК. Немного занимался разработкой под большие сигнальные процессоры и ПЛИС. Сама по себе область очень интересная, но зарплаты ниже "средне-программистских", удаленка проблематична (зависит от сложности оборудования, но даже осциллограф домой притащить и паяльную станцию - уже неудобно получается).
В профессиональном плане жалею, что в свое время не занялся веб-разработкой профессионально, сейчас вот переучиваюсь
Есть бизнес, есть задачи бизнеса. Вы человек который решает задачи бизнеса, который с вашей помощью работает и зарабатывает.
ПрограмТрансПереход
Разница обусловлена не областью действия, а размерами проектов.
Чем больше проект - тем меньше пишется кода и тем больше изучается/дебажится существующего кода.
А на небольших проектах - и 1000 строк в день - далеко не предел. Особенно пока молодой и руки работают вперед головы )))
Раньше делая какую‑то автоматизацию, я пытался в
bash, но потом бросил эту затею, так как в пайтоне реально удобнее
При хорошем владении обоими языками, не делаешь вывод что в пайтоне реально удобнее в автоматизацию. Есть вещи, которые проще и удобнее в баш, есть вещи, которые проще и удобнее в пайтоне. Есть даже что-то проще в перл, или реально накидать на Си или даже JS. Выбираешь под задачу, а при правильной формулировке. чатгпт помогает вместо чтения хелпа, посмотреть готовый пример под твои нужды.
Всё так. Просто Питон мега-универсальный язык с тучей библиотек, поэтому если не хочется учить разные языки, то достаточно выучить Питон почти для любых задач. Ну, кроме мега-интерфейсных каких-то.
Кроме задач, где критична производительность. Я в 2022 вынужден был переписать питоновскую миддлварь на плюсы, количество обрабатываемых событий в секунду скакануло почти на порядок. Но для прототипирования и некритичных по ресурсам задач питон действительно хорош.
Хотя... многие программисты думают, что отлично знают этот язык, но штуки вроде asyncio или numpy вводят их в ступор :)))
На моей практике встречалось (уже не в Embedded, конечно), что на питоне подготавливался MVP какого-нибудь модуля/проекта/утилиты, и уже после проверки, он переделывался, например, на тот же Си (если это было необходимо)
Это они еще про Twisted не слышали :-)
Ну, смотря какие задачи опять же. Если ML, то там Питон может просто вызывать разные модули, написанные на C++ и переписывать вообще всё на C++ смысла никакого нет, если основная работа идёт внутри этих уже оптимизированных модулей. А если речь про обслуживание веб-запросов, то понятно, что там лучше на Golang бэк написать. Я ж и говорю, Питон - язык широкого профиля. Для конкретных узких применений всегда найдётся специализированный на этом язык.
P.S. На ML/DevOps позицию питониста обязательно спросят про Numpy, а веб-разработчика - про asyncio, это уж наверняка.
Питон - язык широкого профиля. Для конкретных узких применений всегда найдётся специализированный на этом язык.
Агитировать меня за python немного бессмысленно, я с удовольствием пользуюсь им с версии 1.5 и 1997 года :)
Python - очень удачный "swiss army knife" c невысоким порогом вхождения и компромиссной производительностью для большинства задач. Вместе с тем, С++ - тоже язык достаточно универсальный, учитывая то, что большая часть "специализированных языков" написано на нём.
В питоновском ML, насколько я знаю, и так большая часть функциональности реализована в виде быстрых библиотек на C/C++, поэтому вопросов с производительностью не возникает, по крайней мере там, где мы не касаемся GIL и реальной многопоточности.
В нашей истории проблема с производительностью middleware вылезла, когда прототип на питоне впервые развернули как систему на 70+ объектов заказчика и она стала давать критичные задержки. Поэтому мы с коллегой ураганно писали боевую уже версию на плюсах. Но питоновский прототип позволил сделать это максимально быстро.
> На ML/DevOps позицию питониста обязательно спросят про Numpy,
> а веб-разработчика - про asyncio, это уж наверняка.
P.S. Я два года назад несколько месяцев искал плюсоида со знанием python-а на уровне asyncio или питониста со знанием С++, STL и буста. Собеседования были эпично грустны...
искал плюсоида со знанием python-а на уровне asyncio или питониста со знанием С++, STL и буста.
Ну вы искали прям монстра кмк))) понятно, почему всё было грустно
Ну, задача была разобраться в питоновском коде и переписать на плюсы. Питоновский код на asyncio, плосовый получился на связке restbed-redis. Нашёл двоих из 40, наверное. С одним договорился. Парень, кстати, без профильного высшего, но с правильной думалкой.
Типовой разговор на собеседовании был именно на тему "уметь разобраться в неведомом". Вы знаете redis? Нет? Отлично! Вот вам задачка и неделя срока, сделаете на плюсах и на питоне :)))
Вообще, IMHO, в команде R&D лучше иметь разносторонних универсалов, знающих 3-5 языков на среднем уровне (у меня их в запасе около 20, недавно считал), чем глубоких узких спецов, убивших 5 лет на изучение одного фреймворка. Фреймворк может смениться, а общие знания позволят изучить новое в короткий срок.
И потом искать как на проде поставить нужную библиотеку, если выхода в инет с прода напрямую нет, а секурити эту библиотеку еще не утвердил.
мега-универсальный язык
Только у питона есть проблема. Вторая и третья. И куча библиотек, которые периодически нужно устанавливать.
А в мире корпораций, не так просто ставить, обновлять, поддерживать нужные версии на всех машинах.
платят мало
А в цифрах - мало это сколько?
Какая разница кем стал. Главное чтобы зарплата стала больше
Я тоже из MК приходил программировать в Linux. Решил вернуться обратно.
Программирование на Си в Linux
С используют для создания модулей ядра Linux. Как вариант можно пойти работать туда. Но надо быть готовым, что образ дистрибутива будет собираться по часу. В Linux проектах ещё больше бюрократии и секретности, чем в проектах на МК. И С кода в Linux пишут существенно меньше. Разработка в Linux похожа на прикладывание костылей. Вся эта методология device tree overlay - это по сути узаконивание костыллинга и быстрых заплаток в разработке.
Часто Linux программисты даже никогда не видели схемотехнику своего target устройства SBC и datasheet(а) на SoC (так как это секрет компании). Программисты Linux работают в абстрактных условиях. Редактируют дерево устройств DTS, путешествуют по файловой системе, пишут скрипты на Bash и Python, исправляют баги в JavaScript(е) Web GUI и выносят ведрами баги из кода User Space процессов для отладки, перекраивают дерево устройств *.dts, добавляют драйверы чипов в загрузчик U-Boot и пишут очень много документации и инструкций (Doc Food(а)) на LaTeX.
Они в принципе не работают в Windows. Собирают ядро для Linux из-под Linux (Ubuntu или CentOS) или на удаленных серверах целыми месяцами напролет глядя в черный экран терминала vim по ssh. Тоска зелёная!
И потом, Linux kernel программисты очень скептически относятся к тем, кто пришел в Linux kernel из программирования микроконтроллеров.
Во первых все кто пришел в Linux из микроконтроллеров это 90% Window (ятники). Это первая причина отсутствия обшей почвы под ногами с Linux программистами. Потом средства отладки в Linux kernel и MCU совершенно разные, разные системы сборки, разный способ передачи конфигов в программы, разный исходный набор документации, разные традиции оформления кода. Всё разное, понимаете! Только Си язык одинаковый. Фактически Linux разработчики даже не считают программистов-микроконтроллеров программистами как таковыми. Называют их User(ы) GUI(нёвых)-IDE(шек)!
Поэтому закрепиться в коллективе Linux программистов программисту микроконтроллеров получится не с первой, и даже не со второй попытки.
Как я стал не пойми кем