Вот и вся суть подобных изречений - то есть то, что вы не видите своими глазами издевательств и ущемлений женских прав, не мешает вам верить в "подобные исследования". А те же самые невидимые кварки вызывают у вас абсурдность, ибо их не проверить органами чувств. Ни того ни другого вы лично не видели, а отношение к этому ортогональное.
Где я тока не работал за последние 15 лет - ни разу не видел ущемление женского коллектива со стороны мужского. Ни в правах, ни в ЗП, ни в отпусках, ни в объеме работы. Даже продвижение по карьере ни чем не отличалось от мужских.
Как то все слишком мучительно) я использую PortProton для установки всего виндового - и игр и софта, и плагинов. Затем вам нужно конвертировать ваши dll в .so что бы софт линуха воспринимал их нативно. Для этого можно использовать yabridge или LinVST. Первая по опыту ковертирует значительно большее кол-во плагинов. Ну это все в том случае если студия нативно работает в линукс - типатого же Ardour или Reaper.
Что значит дальше что? Именно Вы отвечаете за результат вашей работы. Деньги любым наемным сотрудникам, коими разработчики также являются, платят именно за результат, а не за общественные деяния. Результат может быть негативным, промежуточным, позитивным и так далее. Но он обязательно должен быть, и за то каким он будет несете ответсвенность именно Вы.
Мне всегда интересно было почему во всех других отраслях есть и персональные задачи, и ответсвенность, и планирование и даже относительное нормирование выполняемых работ - одни айтишники все еще считают себя помазанниками божьими (хотя судя по развитию ИИ и кризису отрасли многим таки придется изменить текущее мнение). Я лично видел как организована работа инженеров-конструкторов, АСУТПшников, математического моделирования и других - нигде такого бардака как в айти и близко нет. И если вы со всеми этими скрамами и аджайлами попали в небольшую, сработанную и ответственную команду - не забывайте угащать их коффе по утрам с круасанами!!! Ибо по больше части отношение к общему делу с общей ответсвенностью зачастую заканчивается общей задней точкой.
И тут совершенно не играет роль талант, опыт, софт скилы и прочее. Сто раз видел прекрасных и толковых разработчиков, которые десятку инженеров фору дадут, но пока их не пнешь делать они ничего не будут.
А Вы попробуйте что то сложнее ардуино и светодиода - сразу появится куча творческих задач. Разных, не повторяющихся!) К примеру на каком-то SoC поднимите ядро линуха на первом процессоре с драйверами, которые вы адаптировали и написали для вашего устройства, а на втором проце какую-нибудь РТОС. Организуйте коммуникацию между ними, разделение ресурсов. Напишите либы для обоих частей и не забудьте про ГУИ на Qt для тач дисплея - что бы сторонним разработчикам сразу и наглядно было видно как все работает. Оптимизируйте решение - вам ведь надо в риал тайм уложится с обоих сторон. Добавьте дебаг консоли для вывода всей информации с каждого проца. Составьте документацию описывающую ваш алгоритм, протоколы, разделение ресурсов. Опишите какие хард аппаратными проблемами вы столкнулись и как это обошли - ибо продукт новый и что сам чип, что СДК полны ньюансов - нигде ранее не описанных. И это будет все будет лишь одна единственная задача из проекта) Заскучаете - пишите, я Вам позавидую)
Все куда прозаичнее - демографический перекос и яма могут привести к тому, что через 20-25 лет уже для нашего поколения некому будет скидываться налогами на пенсионную, медицинскую и прочие реформы. И государство тут беспокоится никак не о нашей с вами судьбе, а том что придется отгружать из "государственной" казны хотя бы на часть этих трат. Я думаю что большая часть посетителей сегодняшнего хабра смогут обеспечить себе старость, поэтому и недоумевают от подобных заголовков. Но вот каково это в процентном соотношении со всем остальным населением страны? Никто не хочет из своего государственного кармана доставать финансирование. Давайте вы уже как-нить сами разберетесь? Нарожайтесь что ли, вам что сложно?)
Вы весьма заблуждаетесь, если полагаете что работа разработчика Эмбеддед систем это просто написание кода. Могу вас заверить, что это лишь половина если не меньше. Огромное кол-во документации на все микросхемы по 300 страниц каждый минимум, аппноуты по интерфейсам чуть более сложнее чем стандартные UART / SPI / I2C, особенности их работы в конкретном микропроцессоре, ограничения аппаратной платформы, баги заложенные на этапе проектирования печатных плат, электромагнитная совместимость и частотные характеристики многих связанных узлов системы. Это все должно отражаться в вашем коде.
Владение асм, эмбеддед си, с++, Qt, аппаратными отладчиками - это все тоже должно быть.
Но самое главное это наличие подробной и стандартизированной документации. Что в ваших пресловутых "больших" вычислительных системах отсутствует как класс. Особенно если это опенсорс - там вообще хоть вешайся! Эмбеддед разработчик не обязан читать чужой код вместо документации, а лишь для внесения изменений в функционал, если это вдруг становится необходимо. Вы просто видимо не читали техническую документацию на промышленные системы. Кстати много лет наблюдаю за всякими программистами "больших" систем и глубоких абстракций, а так же за их феноменом "ограниченности технической документации")))
По факту я тоже не так давно перешел на Embedded Linux по надобности проекта, и так же прошел всю эту боль, как и автор. К примеру попробуйте сделать драйвер для межпроцессорного взаимодействия между CortexA (Embedded Linux) и CortexM (RTOS) внутри одного SoC кристалла. Изучите особенности работы вашего микропроцессора с адресами памяти, конвертируйте ваш линковочный файл для работы с CMA DDR. Разберитесь с библиотеками, зависимыми от аппаратной реализации, где нет ни то что бы документации, а даже комментариев. Соберите с этим драйвером ядро, добавьте туда ваш DTS файл для управления общими ресурсами (интерфейсы, линии, области ДДР памяти, области памяти ядра и прочее), внесите изменения в загрузчик, настройте всё соответственным образом в RTOS, используя прерывания периферийного модуля. Напишите демо с GUI для сенсорного экрана, в котором покажите как инициализировать и использовать добавленные в систему библиотеки для межъядерной коммуникации, сделайте несколько бенчмарков на аппаратных таймерах что бы прогнать всю систему в риалтайме. А так же не забудьте настроить JTAG debug для параллельной работы с CortexM при работающей Эмбеддед Линукс на CortexA.
А потом посчитайте кол-во кода, прикиньте его сложность с точки зрения алгоритмов и абстракций "больших" проектов - и основываясь лишь на коде дайте оценку проделанной вами работы. Не учитывая тонны документации, аппаратных особенностей и длительной работы с утра до ночи)))
Что опять? Придумайте уже что то новое ибо каждые надцать лет подобные темы подымаются из праха. При чем во всех направлениях. В эмбеддед комьюнити 25-30 лет назад все говорили что никто С использовать не будет, он тяжелый, жрущий ресурсы не в себя, не дает полного контроля аппаратного уровня да и поддерживается лишь некоторыми компаниями. То ли дело вечный и богом данный АСМ. И что сегодня? Хоть кто-нибудь в здравом уме будет писать проект на чистом АСМ в продакшн?)) Лишь поддержка мамонтов той же 25-30 летной давности.
Но тут же стоит и отметить что в эмбеддед дополняющее развитие, а не вытесняющее. АСМ все так же широко используется для вставок и инициализации, С для периферийного уровня и РТОС, С++ все чаще появляется для компонентов бизнес логики и формирование аппаратно-программных фреймворков. Есть место и для JSON для IoT задач, protobuf для сериализации и многое другое. И даже, прости господи, Питон для скриптов и автоматизации. И как то нормально все используется в своих определенных местах))
PS: ревью кода - вещь в себе. Иногда полезная, а иногда губительная. Когда ты чувствуешь что тебе нужная помощь или свежий сторонний взгляд - то это прям выручает. А вот когда к тебе прикапываются из-за скобочек, переносов и прочего - это уже перебор. Особенно когда ты вносишь изменение в проект и стараешься соответствовать общему виду текущего кода, а не тому как это будет рассматривать ревьювер под микроскопом))
PPS: намного важнее учиться составлять техническое описание своего кода и тех документацию. А не ограничиваться названием методов в 100500 символов и 3 слов в коммите) Но в это могут не многие.
Каждый раз одно и тоже...Когда уже народ поймет и успокоится, что линукс - это не винда, и она таковой быть и не старается. Если вы переходите на линукс - будьте готовы что большую часть ПО вам придется заменить другими программами, изучать их с ноля, и потерять совместимость с файлами прог из винды. Есть ПО которое уже идет кроссовым, но его не много. Вы должны отдавать себе отчет зачем вы это делаете, сколько лет у вас займет переход на линукс при изучении всех нужных вам CAD систем и перевода проектов на онные, сколько средств нужно будет потратить - если выдумаете что линукс это "вот это вот все бесплатно", могу вам только посочувствовать) Большая часть качественного ПО под линукс так же платная, хотя и стоит в разы меньше чем на винде.
Исходя из своего инженерного опыта - могу сказать что итераций перехода ни линукс у вас будет много...сразу перейти с вины и ее софта не получится, не льстите себе. Если вы только не собираетесь на ней ютьюб смотрерть да котиков лайкать))
Да я же ничего против не имею) Каждый использует что ему удобно. Просто когда говорят для общей кучи - а вон мол и эмбеддеры даже пишут, значит все можно делать. Да конечно можно, не вопрос вообще.
Вот только бизнесу абсолютно начхать на чем вы там будете реализовывать задачу - его волнуют сроки, суммы и доступный уровень надежности при первых двух параметрах. И эмбеддер с опытом решения промышленных задач всегда отдаст предпочтение готовым либам, прошедшим через 100 тысяч узкоспециализированных разработчиков и экземплам по RTOS от разработчиков систем, а выигранное время потратит на бизнес-логику процесса. А не писать с нуля драйвера для интерфейсов, клиентов, серверов и прочего)
Я с Вами согласен, что это классно, круто, современно...надежно и безопасно. И даже есть разработчики встраиваемых систем, которые пишут на очередном новом языке библиотеки и абстракции. И который ну вот уже наконец-то победит этот архаичный Си.
Хм...проверим статистику что у нас там по RTOS, драйверам и их поддержке:
MOST POPULAR RTOS (2021)
Deos (DDC-I)
embOS (SEGGER)
FreeRTOS (Amazon)
Integrity (Green Hills Software)
Keil RTX (ARM)
LynxOS (Lynx Software Technologies)
MQX (Philips NXP / Freescale)
Nucleus (Mentor Graphics)
Neutrino (BlackBerry)
PikeOS (Sysgo)
SafeRTOS (Wittenstein)
ThreadX (Microsoft Express Logic)
µC/OS (Micrium)
VxWorks (Wind River)
Zephyr (Linux Foundation
Ой, какая неожиданность - все они написаны на С/С++ (в большей степени на С). А как же так то...не надежно все это - сколько безногих разработчиков и промышленных систем.
А если серьезно - каждый выбирает инструмент для своей задачи, под свое соотношение затраченного времени к предполагаемой прибыли.
Ну а когда там появится RTOS на Rust, которая ложиться на большее кол-во популярных семейств МК, с паком необходимых драйверов, примерами под доступные dev-борды и хоть каким-то комьюнити - вот тогда можно будет потратить свое время и перейти на этот без сомнения хороший инструмент. Но пока что это экономически не обоснованно.
Вы не совсем поняли что я имел в виду. Давайте немного поясню. Я так же имею более 10 лет работы в промышленности, кораблестроении, автоматизации. И могу сказать что все сильно зависит от квалификации менеджмента. На одном предприятии за несколько лет не встретил ни одного специалиста с непригодным проф уровнем. Зато на другом все с точностью наоборот. И в обих случаях это совершенно не проблема - взяли человека, не подошел - уволили. И система работает. Высказывания по типу - много прет народу из других отраслей и из-за этой толпы сложно выбирать действитльно годных начинающих - говорит лишь о некомпетентности системы найма в компании да и в отрасли в целом. Даже по своему опыту могу сказать что техническое собеседование со специалистом с проекта было на несколько порядков сложнее, чем "сертификация" в компанию. И у многих знакомых в других компаниях было так же.
Поэтому, с моей точки зерния, разделения джун/ мидл/ сеньор до сих пор не имеют под собой серьездного фундамента. Есть вопросы в которых я за пояс заткну любого сеньора, а есть джуны, которые могут дать прикурить мне в девелопменте. Все слишком размыто - об этом я и говорю...и если честно не понимаю почему так.
Нет какой то субординации, иерархии и зон ответственности. Один человек может тянуть проект, на котором еще сидит с десяток специалистов. И всем норм. Колективная ж ответственность. Даже слова для этого придумали - Scrum, Kanban, agile и прочие. И я такое повидал уже. Вот только в проектах где от одного байта зависит вся бизнес логика клиента и работоспсобность целого завода, и этот байт находится через 2 месца продуктивной работы - это все не работает)) И на такие проекты почему нет потока джунов, хотя их там ждут с распростертыми объятиями, с готовностью обучения и переобучения...иногда даже месяцами)) Но увы, брать индивидуальную отвественность на себя в АйТи сегодня могут не только лишь все))
Я вот одного понять не могу. Что такое "нормальный" джун, а что нет? Или мидл, или сеньор? Текущая ситуация в "вАйти" показывает то что за более чем 15 лет активного развития так и не сформировалось нормальной сертификации специалистов. Если к вам приходит устраиваться электрик с 5 группой электробезопастности, то у него на руках есть все необходимые документы и за 10 минут шаблоного разговора становится ясно купил он их или нет. И все. На следующий день этот специалист может приступать к своей профессиональной работе. И так везде - токари, сварщики, электрики, монтажники. Одни айтишники стараються поставить себя выше всех остальных професий и занять привелегированную нишу. Мол программист творечская личность и должен всю жизнь учиться...расскажите это токарю, или электромеханику, или промышленному наладчику автоматизационных систем - у них хоть настроение подымется. Ибо это глубочайшее из заблуждений, которое я многократно слышал от проф. программистов. Они почему то считают, что кроме них никто больше в жизни ничему не обучается. Разберитесь с бордаком в вашей отрасли - и проблемы с джунами, мидлами и сеньорами отпадут сами по себе. Но видя картину изнутри - могу сказать что в этом реально мало кто заинтересован.
При грамотном планировании рабочих процессов, верном регулировании и прозрачной обратной связью с инженерно-техническими сотрудниками "энтузиазм" в проекте не нужен. Ибо все остальные составляющие проекта работают как им и полагается. И конечный продукт бизнеса проанализирован заранее и не зависит от гениальности отдельно взятого человека. И все риски там просчитаны заранее. И нет смысла стоять с палкой над каждым работником - все прекрасно регулируется рынком труда. В советские времена от таком наверное не особо то и знали или задумывались. И нам видимо еще долго этому учиться.
Возможно я чего то не понимаю. К Вам пришел на работу квалифицированный работник. Он получает много. Он справляется с поставленными ему задачами в несколько раз лучше предыдущего. Полностью соответсвует должным требованиям. Если в договоре есть разработка нового устройства, внедрение рационализаторских предложений или оптимизация производства и он с этим всем справляется. Какой Вам еще нужен энтузиазм и зачем?
Энтузиазм нужен молодому зеленому специалисту, который набивает свой опыт, практику и развивает конструктивное мышление. Вот в этом случае ему абсолютно по барабану на зарплату - он работает на свой опыт с рвением и энтузаизмом. Но не потому что ему это так нравится, а потому что он планирует вырасти как специалист и свалить туда, где за его опыт и голову будут платит соответсвенно.
Вы же живете в каких-то фантазиях прошлого. Могу даже на себе пример привести - я прихожу на весьма сложный проект, трачу пол года жизни разбираясь с большим кол-вом нового сложного специфического материала, привожу все рабочие процессы в порядок, делаю отладочные средства и сокращаю время на разбор будущих проблемных ситуаций. Работаю на износ и с энтузиазмом, так оклад соответсвует поставленным задачам. И вот спустя 9 месяцев я знаю проект очень хорошо, у меня на готове весь инструментарий, и программно и аппаратно я могу быстро найти причину сбоя и приступить к его решению. То что делали спецы до меня занимало недели. Я же теперь это делаю за дни, попивая кофе, слушая любимую музыку и не напрягаясь. Я делаю все поставленные задачи быстрее и больше чем этого от меня требуют. Какой еще нужен этузиазм в этом случае, я не понимаю. Когда я перейду на следующий уровень проектов и окладов - я так же полгода буду энтузиастом и работать дни на пролет, пока все не встанет на свои рельсы.....и так по кругу. И даже в этих случаях я бы не назвал это энтузиазмом, скорее просто большим усердием и большей тратой своего времени, порою и не оплачиваемым.
Это как раз тот случай, когда квалифицированный этузиаст не требовался под текущую задачу)) И я так смотрю по коментариям, что в советские времена далеко не всегда и требовался такой специалист. Ибо далеко не все так же разделяли его энтузиазм. И далеко не от того, что у них там в голове что то не работало. А просто создавало дополнительную работу, не учтенную в их обязаностях. И уж никак не от того, что инженеров мало было - скорее всего мотивации и контроля не хватало!)
Мне хоть и не довелось познать парадигму советских трудовых взаимоотношений на производстве, но то, что рыночная система труда "размер з/п" - "качество работы" работает исправно - убеждался неоднократно!!!
Скажем Вам требуется квалифицированный инженер, который будет изобретать, внедрять и работать с энтузиазмом. Как Вы думаете в каком случае будет найти такого человека проще - при низком окладе или изначально высоком? Уж поверте - во втором случае вы еще и выбирать будете из более подходящих вариантов.
Так же любой адекватный руководтель понимает - что если одному и тому специалисту начать выплачить оклад х2 и более - его квалификация и скорость работы уже не изменятся. Поэтому его сразу меняют на подходящего под запросы специалиста, которому сразу платят нормальный оклад, и который сразу приступает к выполнению своих обязанностей. Лично имел возможность такое наблюдать много раз.
Вы верно говорите про отношение к работе. Тут сложно не согласиться, что если пошел на работу - выполняй. Но и в здравом уме не стоит требовать от работы с низким уровнем ЗП каких-либо рационализаторских внедрений, разработок и энтузиазма. К тому же инженерная работа включает в себя огромное количество задач, никак с изобретениями не связанных. Да и заниматься изобритениями должны целые отделы КБ, а не ждать оного от талантливого энтузиаста получающего низкую ЗП!))
Вот мне всегда было интересно - каким образом можно клеить определенный ярлык на человека (интроверт, социофоб или лентяй этим всем прикрывающийся). В детстве или точнее отрочестве я ощущал неудобство общения с незнакомыми мне людьми. Они не были мне неприятными, я скорее всего просто стеснялся их общества. Но тем не менее старался их избегать. Потом в универе я наоборот с радостью заводил новые знакомства, общения, посещал мероприятия, гулянки и т.д. Поступив на первую работу я быстро понял что часть людей с которыми мне было весело пить пиво в универе мне уже не интересны. У меня уже образовывался фильтр круга лиц с более высокими интеллектуальными способностями, лучшим воспитанием и вообще - кто просто нормальный человек а кто тебе на шею готовь сесть и ноги сбросить. Отработав более 10 лет на разных предприятиях я достиг определенного технического уровня, социального, сформировал устойчивые взгляды и интересы, обзавелся семьей. И на сегодняшний день из круга лиц, с которыми я тесно общаюсь, остались лишь члены семьи, 2 друга и товарищь по работе. И работая удаленно я полностью самодостаточен и не чуствую нужды в чьем-либо общении кроме них. Мне все еще встечаются интересные мне люди, но происходит это крайне редко. И в таких случаях я готов к любому диалогу и мне он будет интереснен. Но вот если мне кто предложит пойти на социальные танцы - я буду это рассматривать как самую бессмысленную трату времени. Независимо от местоположения - СНГ, Европа или Штаты. Мне было неудобно общаться, потом удобно и хотелось, потом общение уменьшилось ибо появилась разборчивость в людях, а теперь мне лень/не интересно/пустая трата времени. И кто я в текущем представлении психо-лекарей?)
Все почему-то говорят о ресурсах, материалах, деньгах, - но всегда забывают про квалифицированных специалистов и их мотивацию. Я за годы работы как в промышленности, а затем и в IT, так и на частного заказчика насмотрелся на самых разных инженеров и программистов. Есть очень опытные и очень умные ребята - но заставить их работать полноценно, с максимальной отдачей - практически невозможно. И причины тут разные - кому-то дома семейная жизнь мозг выедает, кто-то не хочет делать больше должностной инструкции из-за низкой ЗП, кто-то просто человек настроения. А есть довольно слабенькие специалисты, но готовые бетон грызть и что-то делать. Но и они со временем и опытом превращаются в первых.
Для столь амбициозных импортозамещающих планов в высокоинтеллектуальных отраслях нужны не просто квалифицированные сотрудники, но и люди способные выкладываться на 300%. А это могут быть либо энтузиасты (которых я встречал раз или два), либо хорошо мотивированные люди. С мотивацией в СНГ за 30 лет как то не сложилось, и когда какого-либо толкового спеца пытаются "промотивировать", когда он сам этого не желает - он просто отрывает свою пятую точку от болото, меняет работу, либо же все чаще - страну.
По этому я слабо верю в подобного рода авантюры. Тут только закрывать наглухо границы для всех инженерных специальностей.
Вот и вся суть подобных изречений - то есть то, что вы не видите своими глазами издевательств и ущемлений женских прав, не мешает вам верить в "подобные исследования". А те же самые невидимые кварки вызывают у вас абсурдность, ибо их не проверить органами чувств. Ни того ни другого вы лично не видели, а отношение к этому ортогональное.
Где я тока не работал за последние 15 лет - ни разу не видел ущемление женского коллектива со стороны мужского. Ни в правах, ни в ЗП, ни в отпусках, ни в объеме работы. Даже продвижение по карьере ни чем не отличалось от мужских.
Как то все слишком мучительно) я использую PortProton для установки всего виндового - и игр и софта, и плагинов. Затем вам нужно конвертировать ваши dll в .so что бы софт линуха воспринимал их нативно. Для этого можно использовать yabridge или LinVST. Первая по опыту ковертирует значительно большее кол-во плагинов. Ну это все в том случае если студия нативно работает в линукс - типатого же Ardour или Reaper.
Что значит дальше что? Именно Вы отвечаете за результат вашей работы. Деньги любым наемным сотрудникам, коими разработчики также являются, платят именно за результат, а не за общественные деяния. Результат может быть негативным, промежуточным, позитивным и так далее. Но он обязательно должен быть, и за то каким он будет несете ответсвенность именно Вы.
Мне всегда интересно было почему во всех других отраслях есть и персональные задачи, и ответсвенность, и планирование и даже относительное нормирование выполняемых работ - одни айтишники все еще считают себя помазанниками божьими (хотя судя по развитию ИИ и кризису отрасли многим таки придется изменить текущее мнение). Я лично видел как организована работа инженеров-конструкторов, АСУТПшников, математического моделирования и других - нигде такого бардака как в айти и близко нет. И если вы со всеми этими скрамами и аджайлами попали в небольшую, сработанную и ответственную команду - не забывайте угащать их коффе по утрам с круасанами!!! Ибо по больше части отношение к общему делу с общей ответсвенностью зачастую заканчивается общей задней точкой.
И тут совершенно не играет роль талант, опыт, софт скилы и прочее. Сто раз видел прекрасных и толковых разработчиков, которые десятку инженеров фору дадут, но пока их не пнешь делать они ничего не будут.
Вот вам и яркий пример почему микросервисы суют везде, даже не понимания зачем)
А Вы попробуйте что то сложнее ардуино и светодиода - сразу появится куча творческих задач. Разных, не повторяющихся!) К примеру на каком-то SoC поднимите ядро линуха на первом процессоре с драйверами, которые вы адаптировали и написали для вашего устройства, а на втором проце какую-нибудь РТОС. Организуйте коммуникацию между ними, разделение ресурсов. Напишите либы для обоих частей и не забудьте про ГУИ на Qt для тач дисплея - что бы сторонним разработчикам сразу и наглядно было видно как все работает. Оптимизируйте решение - вам ведь надо в риал тайм уложится с обоих сторон. Добавьте дебаг консоли для вывода всей информации с каждого проца. Составьте документацию описывающую ваш алгоритм, протоколы, разделение ресурсов. Опишите какие хард аппаратными проблемами вы столкнулись и как это обошли - ибо продукт новый и что сам чип, что СДК полны ньюансов - нигде ранее не описанных. И это будет все будет лишь одна единственная задача из проекта) Заскучаете - пишите, я Вам позавидую)
Все куда прозаичнее - демографический перекос и яма могут привести к тому, что через 20-25 лет уже для нашего поколения некому будет скидываться налогами на пенсионную, медицинскую и прочие реформы. И государство тут беспокоится никак не о нашей с вами судьбе, а том что придется отгружать из "государственной" казны хотя бы на часть этих трат. Я думаю что большая часть посетителей сегодняшнего хабра смогут обеспечить себе старость, поэтому и недоумевают от подобных заголовков. Но вот каково это в процентном соотношении со всем остальным населением страны? Никто не хочет из
своегогосударственного кармана доставать финансирование. Давайте вы уже как-нить сами разберетесь? Нарожайтесь что ли, вам что сложно?)Вы весьма заблуждаетесь, если полагаете что работа разработчика Эмбеддед систем это просто написание кода. Могу вас заверить, что это лишь половина если не меньше. Огромное кол-во документации на все микросхемы по 300 страниц каждый минимум, аппноуты по интерфейсам чуть более сложнее чем стандартные UART / SPI / I2C, особенности их работы в конкретном микропроцессоре, ограничения аппаратной платформы, баги заложенные на этапе проектирования печатных плат, электромагнитная совместимость и частотные характеристики многих связанных узлов системы. Это все должно отражаться в вашем коде.
Владение асм, эмбеддед си, с++, Qt, аппаратными отладчиками - это все тоже должно быть.
Но самое главное это наличие подробной и стандартизированной документации. Что в ваших пресловутых "больших" вычислительных системах отсутствует как класс. Особенно если это опенсорс - там вообще хоть вешайся! Эмбеддед разработчик не обязан читать чужой код вместо документации, а лишь для внесения изменений в функционал, если это вдруг становится необходимо. Вы просто видимо не читали техническую документацию на промышленные системы. Кстати много лет наблюдаю за всякими программистами "больших" систем и глубоких абстракций, а так же за их феноменом "ограниченности технической документации")))
По факту я тоже не так давно перешел на Embedded Linux по надобности проекта, и так же прошел всю эту боль, как и автор. К примеру попробуйте сделать драйвер для межпроцессорного взаимодействия между CortexA (Embedded Linux) и CortexM (RTOS) внутри одного SoC кристалла. Изучите особенности работы вашего микропроцессора с адресами памяти, конвертируйте ваш линковочный файл для работы с CMA DDR. Разберитесь с библиотеками, зависимыми от аппаратной реализации, где нет ни то что бы документации, а даже комментариев. Соберите с этим драйвером ядро, добавьте туда ваш DTS файл для управления общими ресурсами (интерфейсы, линии, области ДДР памяти, области памяти ядра и прочее), внесите изменения в загрузчик, настройте всё соответственным образом в RTOS, используя прерывания периферийного модуля. Напишите демо с GUI для сенсорного экрана, в котором покажите как инициализировать и использовать добавленные в систему библиотеки для межъядерной коммуникации, сделайте несколько бенчмарков на аппаратных таймерах что бы прогнать всю систему в риалтайме. А так же не забудьте настроить JTAG debug для параллельной работы с CortexM при работающей Эмбеддед Линукс на CortexA.
А потом посчитайте кол-во кода, прикиньте его сложность с точки зрения алгоритмов и абстракций "больших" проектов - и основываясь лишь на коде дайте оценку проделанной вами работы. Не учитывая тонны документации, аппаратных особенностей и длительной работы с утра до ночи)))
Что опять? Придумайте уже что то новое ибо каждые надцать лет подобные темы подымаются из праха. При чем во всех направлениях. В эмбеддед комьюнити 25-30 лет назад все говорили что никто С использовать не будет, он тяжелый, жрущий ресурсы не в себя, не дает полного контроля аппаратного уровня да и поддерживается лишь некоторыми компаниями. То ли дело вечный и богом данный АСМ. И что сегодня? Хоть кто-нибудь в здравом уме будет писать проект на чистом АСМ в продакшн?)) Лишь поддержка мамонтов той же 25-30 летной давности.
Но тут же стоит и отметить что в эмбеддед дополняющее развитие, а не вытесняющее. АСМ все так же широко используется для вставок и инициализации, С для периферийного уровня и РТОС, С++ все чаще появляется для компонентов бизнес логики и формирование аппаратно-программных фреймворков. Есть место и для JSON для IoT задач, protobuf для сериализации и многое другое. И даже, прости господи, Питон для скриптов и автоматизации. И как то нормально все используется в своих определенных местах))
PS: ревью кода - вещь в себе. Иногда полезная, а иногда губительная. Когда ты чувствуешь что тебе нужная помощь или свежий сторонний взгляд - то это прям выручает. А вот когда к тебе прикапываются из-за скобочек, переносов и прочего - это уже перебор. Особенно когда ты вносишь изменение в проект и стараешься соответствовать общему виду текущего кода, а не тому как это будет рассматривать ревьювер под микроскопом))
PPS: намного важнее учиться составлять техническое описание своего кода и тех документацию. А не ограничиваться названием методов в 100500 символов и 3 слов в коммите) Но в это могут не многие.
Каждый раз одно и тоже...Когда уже народ поймет и успокоится, что линукс - это не винда, и она таковой быть и не старается. Если вы переходите на линукс - будьте готовы что большую часть ПО вам придется заменить другими программами, изучать их с ноля, и потерять совместимость с файлами прог из винды. Есть ПО которое уже идет кроссовым, но его не много. Вы должны отдавать себе отчет зачем вы это делаете, сколько лет у вас займет переход на линукс при изучении всех нужных вам CAD систем и перевода проектов на онные, сколько средств нужно будет потратить - если выдумаете что линукс это "вот это вот все бесплатно", могу вам только посочувствовать) Большая часть качественного ПО под линукс так же платная, хотя и стоит в разы меньше чем на винде.
Исходя из своего инженерного опыта - могу сказать что итераций перехода ни линукс у вас будет много...сразу перейти с вины и ее софта не получится, не льстите себе. Если вы только не собираетесь на ней ютьюб смотрерть да котиков лайкать))
Да я же ничего против не имею) Каждый использует что ему удобно. Просто когда говорят для общей кучи - а вон мол и эмбеддеры даже пишут, значит все можно делать. Да конечно можно, не вопрос вообще.
Вот только бизнесу абсолютно начхать на чем вы там будете реализовывать задачу - его волнуют сроки, суммы и доступный уровень надежности при первых двух параметрах. И эмбеддер с опытом решения промышленных задач всегда отдаст предпочтение готовым либам, прошедшим через 100 тысяч узкоспециализированных разработчиков и экземплам по RTOS от разработчиков систем, а выигранное время потратит на бизнес-логику процесса. А не писать с нуля драйвера для интерфейсов, клиентов, серверов и прочего)
Я с Вами согласен, что это классно, круто, современно...надежно и безопасно. И даже есть разработчики встраиваемых систем, которые пишут на очередном новом языке библиотеки и абстракции. И который ну вот уже наконец-то победит этот архаичный Си.
Хм...проверим статистику что у нас там по RTOS, драйверам и их поддержке:
MOST POPULAR RTOS (2021)
Deos (DDC-I)
embOS (SEGGER)
FreeRTOS (Amazon)
Integrity (Green Hills Software)
Keil RTX (ARM)
LynxOS (Lynx Software Technologies)
MQX (Philips NXP / Freescale)
Nucleus (Mentor Graphics)
Neutrino (BlackBerry)
PikeOS (Sysgo)
SafeRTOS (Wittenstein)
ThreadX (Microsoft Express Logic)
µC/OS (Micrium)
VxWorks (Wind River)
Zephyr (Linux Foundation
Ой, какая неожиданность - все они написаны на С/С++ (в большей степени на С). А как же так то...не надежно все это - сколько безногих разработчиков и промышленных систем.
А если серьезно - каждый выбирает инструмент для своей задачи, под свое соотношение затраченного времени к предполагаемой прибыли.
Ну а когда там появится RTOS на Rust, которая ложиться на большее кол-во популярных семейств МК, с паком необходимых драйверов, примерами под доступные dev-борды и хоть каким-то комьюнити - вот тогда можно будет потратить свое время и перейти на этот без сомнения хороший инструмент. Но пока что это экономически не обоснованно.
Вы не совсем поняли что я имел в виду. Давайте немного поясню. Я так же имею более 10 лет работы в промышленности, кораблестроении, автоматизации. И могу сказать что все сильно зависит от квалификации менеджмента. На одном предприятии за несколько лет не встретил ни одного специалиста с непригодным проф уровнем. Зато на другом все с точностью наоборот. И в обих случаях это совершенно не проблема - взяли человека, не подошел - уволили. И система работает. Высказывания по типу - много прет народу из других отраслей и из-за этой толпы сложно выбирать действитльно годных начинающих - говорит лишь о некомпетентности системы найма в компании да и в отрасли в целом. Даже по своему опыту могу сказать что техническое собеседование со специалистом с проекта было на несколько порядков сложнее, чем "сертификация" в компанию. И у многих знакомых в других компаниях было так же.
Поэтому, с моей точки зерния, разделения джун/ мидл/ сеньор до сих пор не имеют под собой серьездного фундамента. Есть вопросы в которых я за пояс заткну любого сеньора, а есть джуны, которые могут дать прикурить мне в девелопменте. Все слишком размыто - об этом я и говорю...и если честно не понимаю почему так.
Нет какой то субординации, иерархии и зон ответственности. Один человек может тянуть проект, на котором еще сидит с десяток специалистов. И всем норм. Колективная ж ответственность. Даже слова для этого придумали - Scrum, Kanban, agile и прочие. И я такое повидал уже. Вот только в проектах где от одного байта зависит вся бизнес логика клиента и работоспсобность целого завода, и этот байт находится через 2 месца продуктивной работы - это все не работает)) И на такие проекты почему нет потока джунов, хотя их там ждут с распростертыми объятиями, с готовностью обучения и переобучения...иногда даже месяцами)) Но увы, брать индивидуальную отвественность на себя в АйТи сегодня могут не только лишь все))
Я вот одного понять не могу. Что такое "нормальный" джун, а что нет? Или мидл, или сеньор? Текущая ситуация в "вАйти" показывает то что за более чем 15 лет активного развития так и не сформировалось нормальной сертификации специалистов. Если к вам приходит устраиваться электрик с 5 группой электробезопастности, то у него на руках есть все необходимые документы и за 10 минут шаблоного разговора становится ясно купил он их или нет. И все. На следующий день этот специалист может приступать к своей профессиональной работе. И так везде - токари, сварщики, электрики, монтажники. Одни айтишники стараються поставить себя выше всех остальных професий и занять привелегированную нишу. Мол программист творечская личность и должен всю жизнь учиться...расскажите это токарю, или электромеханику, или промышленному наладчику автоматизационных систем - у них хоть настроение подымется. Ибо это глубочайшее из заблуждений, которое я многократно слышал от проф. программистов. Они почему то считают, что кроме них никто больше в жизни ничему не обучается. Разберитесь с бордаком в вашей отрасли - и проблемы с джунами, мидлами и сеньорами отпадут сами по себе. Но видя картину изнутри - могу сказать что в этом реально мало кто заинтересован.
При грамотном планировании рабочих процессов, верном регулировании и прозрачной обратной связью с инженерно-техническими сотрудниками "энтузиазм" в проекте не нужен. Ибо все остальные составляющие проекта работают как им и полагается. И конечный продукт бизнеса проанализирован заранее и не зависит от гениальности отдельно взятого человека. И все риски там просчитаны заранее. И нет смысла стоять с палкой над каждым работником - все прекрасно регулируется рынком труда. В советские времена от таком наверное не особо то и знали или задумывались. И нам видимо еще долго этому учиться.
Возможно я чего то не понимаю. К Вам пришел на работу квалифицированный работник. Он получает много. Он справляется с поставленными ему задачами в несколько раз лучше предыдущего. Полностью соответсвует должным требованиям. Если в договоре есть разработка нового устройства, внедрение рационализаторских предложений или оптимизация производства и он с этим всем справляется. Какой Вам еще нужен энтузиазм и зачем?
Энтузиазм нужен молодому зеленому специалисту, который набивает свой опыт, практику и развивает конструктивное мышление. Вот в этом случае ему абсолютно по барабану на зарплату - он работает на свой опыт с рвением и энтузаизмом. Но не потому что ему это так нравится, а потому что он планирует вырасти как специалист и свалить туда, где за его опыт и голову будут платит соответсвенно.
Вы же живете в каких-то фантазиях прошлого. Могу даже на себе пример привести - я прихожу на весьма сложный проект, трачу пол года жизни разбираясь с большим кол-вом нового сложного специфического материала, привожу все рабочие процессы в порядок, делаю отладочные средства и сокращаю время на разбор будущих проблемных ситуаций. Работаю на износ и с энтузиазмом, так оклад соответсвует поставленным задачам. И вот спустя 9 месяцев я знаю проект очень хорошо, у меня на готове весь инструментарий, и программно и аппаратно я могу быстро найти причину сбоя и приступить к его решению. То что делали спецы до меня занимало недели. Я же теперь это делаю за дни, попивая кофе, слушая любимую музыку и не напрягаясь. Я делаю все поставленные задачи быстрее и больше чем этого от меня требуют. Какой еще нужен этузиазм в этом случае, я не понимаю. Когда я перейду на следующий уровень проектов и окладов - я так же полгода буду энтузиастом и работать дни на пролет, пока все не встанет на свои рельсы.....и так по кругу. И даже в этих случаях я бы не назвал это энтузиазмом, скорее просто большим усердием и большей тратой своего времени, порою и не оплачиваемым.
Это как раз тот случай, когда квалифицированный этузиаст не требовался под текущую задачу)) И я так смотрю по коментариям, что в советские времена далеко не всегда и требовался такой специалист. Ибо далеко не все так же разделяли его энтузиазм. И далеко не от того, что у них там в голове что то не работало. А просто создавало дополнительную работу, не учтенную в их обязаностях. И уж никак не от того, что инженеров мало было - скорее всего мотивации и контроля не хватало!)
Мне хоть и не довелось познать парадигму советских трудовых взаимоотношений на производстве, но то, что рыночная система труда "размер з/п" - "качество работы" работает исправно - убеждался неоднократно!!!
Скажем Вам требуется квалифицированный инженер, который будет изобретать, внедрять и работать с энтузиазмом. Как Вы думаете в каком случае будет найти такого человека проще - при низком окладе или изначально высоком? Уж поверте - во втором случае вы еще и выбирать будете из более подходящих вариантов.
Так же любой адекватный руководтель понимает - что если одному и тому специалисту начать выплачить оклад х2 и более - его квалификация и скорость работы уже не изменятся. Поэтому его сразу меняют на подходящего под запросы специалиста, которому сразу платят нормальный оклад, и который сразу приступает к выполнению своих обязанностей. Лично имел возможность такое наблюдать много раз.
Вы верно говорите про отношение к работе. Тут сложно не согласиться, что если пошел на работу - выполняй. Но и в здравом уме не стоит требовать от работы с низким уровнем ЗП каких-либо рационализаторских внедрений, разработок и энтузиазма. К тому же инженерная работа включает в себя огромное количество задач, никак с изобретениями не связанных. Да и заниматься изобритениями должны целые отделы КБ, а не ждать оного от талантливого энтузиаста получающего низкую ЗП!))
Вот мне всегда было интересно - каким образом можно клеить определенный ярлык на человека (интроверт, социофоб или лентяй этим всем прикрывающийся). В детстве или точнее отрочестве я ощущал неудобство общения с незнакомыми мне людьми. Они не были мне неприятными, я скорее всего просто стеснялся их общества. Но тем не менее старался их избегать. Потом в универе я наоборот с радостью заводил новые знакомства, общения, посещал мероприятия, гулянки и т.д. Поступив на первую работу я быстро понял что часть людей с которыми мне было весело пить пиво в универе мне уже не интересны. У меня уже образовывался фильтр круга лиц с более высокими интеллектуальными способностями, лучшим воспитанием и вообще - кто просто нормальный человек а кто тебе на шею готовь сесть и ноги сбросить. Отработав более 10 лет на разных предприятиях я достиг определенного технического уровня, социального, сформировал устойчивые взгляды и интересы, обзавелся семьей. И на сегодняшний день из круга лиц, с которыми я тесно общаюсь, остались лишь члены семьи, 2 друга и товарищь по работе. И работая удаленно я полностью самодостаточен и не чуствую нужды в чьем-либо общении кроме них. Мне все еще встечаются интересные мне люди, но происходит это крайне редко. И в таких случаях я готов к любому диалогу и мне он будет интереснен. Но вот если мне кто предложит пойти на социальные танцы - я буду это рассматривать как самую бессмысленную трату времени. Независимо от местоположения - СНГ, Европа или Штаты. Мне было неудобно общаться, потом удобно и хотелось, потом общение уменьшилось ибо появилась разборчивость в людях, а теперь мне лень/не интересно/пустая трата времени. И кто я в текущем представлении психо-лекарей?)
Все почему-то говорят о ресурсах, материалах, деньгах, - но всегда забывают про квалифицированных специалистов и их мотивацию. Я за годы работы как в промышленности, а затем и в IT, так и на частного заказчика насмотрелся на самых разных инженеров и программистов. Есть очень опытные и очень умные ребята - но заставить их работать полноценно, с максимальной отдачей - практически невозможно. И причины тут разные - кому-то дома семейная жизнь мозг выедает, кто-то не хочет делать больше должностной инструкции из-за низкой ЗП, кто-то просто человек настроения. А есть довольно слабенькие специалисты, но готовые бетон грызть и что-то делать. Но и они со временем и опытом превращаются в первых.
Для столь амбициозных импортозамещающих планов в высокоинтеллектуальных отраслях нужны не просто квалифицированные сотрудники, но и люди способные выкладываться на 300%. А это могут быть либо энтузиасты (которых я встречал раз или два), либо хорошо мотивированные люди. С мотивацией в СНГ за 30 лет как то не сложилось, и когда какого-либо толкового спеца пытаются "промотивировать", когда он сам этого не желает - он просто отрывает свою пятую точку от болото, меняет работу, либо же все чаще - страну.
По этому я слабо верю в подобного рода авантюры. Тут только закрывать наглухо границы для всех инженерных специальностей.