Я с многими из них по кабакам ходил, всякие официальные мороприятия, они конечно когда то понаехали, но это было несколько поколений назад.
Нанимают конечно по разным причинам, есть и талантливые ребята, но их процент не может быть даже 50% их значительно меньше, а гребут почти всех.
Вот смотрите — чтоб нанять классного спеца нужно от 180 тысяч долларов в США (долина) и от 70 тысяч в евро в германии-франции. За эти деньги можно нанять 2х иностранцев, даже притащив их в страну, все равно выглядит значительно дешевле.
Но это не все… проблема в том что те кто получает от 180к прикормлены очень хорошо и куда то бежать им смысла нет, т.е. просто так их на рынке не найти, а чаще всего нужно «срочно и вчера». Т.е. формирование комманды специалистов это многолетний процесс. Вот и получаем то что имеем.
Я рискую выхватить минусов конечно, но в индустрии уже лет 25 и работаю последние 15 не в РФ и могу точно сказать что 90% тех кого тянут из-за рубежа тупо дешевле, таланты на моей памяти были единицы, а когда сравниваешь тех кто приезжает (да, я сам такой был) с выпусниками хороших местных вузов сравнение не в пользу приезжих, уж извините.
Американские инженеры слабые? Не хотел бы Вас сильно разочаровавывать, но советую не быть столь самоуверенным. Мне пришлось работать с многими из мед индустрии (электроника и софт) и они были очень сильны и хорошо образованы. Проблема обычно в том что они очень дороги и менеджмент пытается экономить нанимая индусов, русских, украинцев, европейцев, но эти американские инженеры всегда работу найдут, отбоя от предложений у них нет :)
Мы всегда исходили из простого постулата — этот код/утилита сохранит нам время или заберет его?
Возьмем копилятор С++ и написание на асме, выгода на лицо. Поэтому за компилятор мы будем бороться до последнего :)
А вот эта библиотека какой выигрыш нам даст? Сколько мы ее будем интегрировать, отлаживать и какой выигрыш получим в конце? Если баланс сходится в плюс то используем, а если нет — то зачем?
Не поймите меня не правильно, я не против конкретно этого примера из статьи, но в масштабах индустрии вижу как целое поколение инженеров выбирает усложнение из соображений «это прикольно» нежели из соображений «это выгодно».
Недавний пример, пишем под код SoftCore NIOS II, один ведуший (!!) инженер решает завернуть все вызовы к APB регистрам в классы на шаблонах, вместо классических функций Write & Read уже протестированных, отлаженных и надежных как кувалда.
По итогу за каждую запись в регистр мы платили +22% (по сравнению с простой Write) в текстовом сегменте программы и -30% от производительности того же сишного кода и где то через пол года нашли баг в разыменовании 0 указателя, а через год разработки уткнулись в предел памяти. Все это нам стоило еще пары месяцев работы только чтоб все это разгрести, а выгода от С++ классов для доступа к регистрам была 0, я не шучу, все та же запись, но по другому выглядела.
Гениальность в простоте… но уходят десятилетия чтоб научиться эту простоту создавать.
Не видя кода вы говорите, что вероятней всего есть UB? Как вы это делаете? :)
А если серьезно, я не говорил что крив сам GCC, кривой тулчейн, а конкретно backend под мико32.
Увеличение сложности системы (да, увеличение: больше кода — больше точек отказа, спросите ребят из бэк-енда современных веб технологий считают ли они что все сделано правильно?) должно быть оправдано.
>>У вас же памяти в обрез, какая ещё дебажная сборка?
Если без дебаггера ни как — мы в таких случая деоптимизируем только функции выборочно.
Другой важный момент — производительность, функции на шаблонах и других расширенных возможностях компилятора очень хорошо оптимизируются, стэк схлопывается и все превращается в несколько инструкций, но стоит только эту функцию деоптимизировать и у вас может быть 70-80 кратный разрыв в производительности с ее оптимизированой версией. Если такая функция вызывается из прерывания и занимает 30 микросекунд — то после деоптимизации один только ее вызов превратится в 2 миллисекунды, а если их несколько…
>>вы вместо того, чтобы доверять себе, обзаводитесь достаточно умным компилятором с достаточно умной системой типов и начинаете доверять ему
Эх, это даже не смешно, тонны примеров из прошлого можно даже не приводить, есть свежачок :) Работаю на Мико32, есть GCC и тул чэйн и вот мы недавно выясняем что эти замечательные тулзы компилируют С++ с ошибками в случае виртуальных функций, если в С функции параметр 16 битный то стек едет, есть и другие косяки.
Увы, доверять это не про нас.
Коллеги, а не кажется ли вам, что это ту мач?
Вот пишете Вы под микроконтроллер, памяти в обрез, герцев мало, код хотите видеть простой, понятный и предсказуемый, так как хороший дебаггер в реальном времени это не про нас.
И вот вместо приблизительно такого кода:
GPIO_BSRR_Write(GPIOA, (1<<1) | (1 << 3));
GPIO_BSRR_Write(GPIOB, (1 << 1));
GPIO_BSRR_Write(GPIOC, (1<<1) | (1 << 3));
У вас пара сотен линий кода на шаблонах и трудно предсказуемого шаманства компилятора, которое у любого ревьювера вызовет легкий тремор левого века, создаст многократный разрыв производительности в дебажной и релизной сборках, а так же при поиске багов будет как магнит притягивать к себе внимание всей команды инженеров.
В конце 60x и 70х девушек в профессии было очень много, мама моего друга была программистом и работала на очень серьезных проектах, когда рассказывала я прям радовался.
Да что говорить, код для миссии Аполо например был разработан при участии вот этой замечательной девушки
https://en.wikipedia.org/wiki/Margaret_Hamilton_(scientist)
which developed on-board flight software for the Apollo space program
Вы представляете сложность и ответственность этого кода?
Так вот, все было, но профессию девушки стали покидать, вопрос лишь почему. Не думаю, что мужчины выпихивали девушек из индустрии, но что-то поменялось в том числе и в головах девушек или их представлении о профессии.
В определенном смысле я никогда не умру, потому что частицы моего Я, мои статьи и книги, разлетелись осколками на века, попав на плодородную почву молодых пытливых умов, изменив ход их бытия, и теперь уже непросто провести границу, где они, а где Я. Да и Я — это на самом деле никакой не я, а продукт брожения мозга, читавший определенные книги, слушающий срывающую крышу музыку и так далее по списку. Я же не вещь в себе. Во мне живут осколки тех, кто вспыхнул до меня. И так по эстафете. А потому мы приходим к тому, что вначале было слово. Именно слово делает людей бессмертными. Пока кто-то грезит о возможности скопировать свое сознание в компьютер будущего, другие копируют свое сознание посредством письменности.
И все-таки будет интересней, если в будущем мы встретимся с читателем не в такой форме, а лицом к лицу на поле боя, посмотрим друг на друга в перекрестие прицела. Хотя это и маловероятно, но у судьбы извращенное чувство юмора.
Вы правы, для каждой задачи свой инструмент и если я правильно понял автора — сравниваются логеры по различным критериям и как раз была попытка уйти от формата советов «я пользуюсь бустом и мне хорошо», а дать более объективную картину, а каждый уж пусть решает для себя сам в зависимости от поставленной задачи.
Прочитав первые два абзаца не на шутку взволновался, подумал что сейчас расскажут, что ошибки компилятора только мешают и вот список тех, что можно смело игнорировать. Оказалось зря.
Коротких путей нет — хотите сделать код стабильнее — вычитайте все предупреждения и исправьте код.
Да, они научились многому, но когда возникает проблема входящая в их слепое пятно (коих множество ибо они учились адресно исходя из текущих проблем) они даже не догадываются о возможных путях и решениях, т.е. они не понимают и не осознают глубину провала в знаниях.
А так как люди не глупые и уже многое преодолели верят в себя и основываясь на слепой вере применяют старую "изоленту и проволоку", когда нужно читать теорию графов и дискретную математику.
Чтоб быть ремесленником достаточно базовых знаний и фрагментированной картины мира, все остальное будет постигаться в процессе путем проб о ошибок (правда решения будут находится уровня "вот здесь проволочкой изолентой и будет на века"), таких "инженеров" видел немало, не могу ничего сказать про них плохое, обычно это очень умные и быстро обучаемые люди, но с фатальными пробелами в знаниях которые являются основой нашей профессии.
Если человек готовы выходить за рамки своей зоны комфорта и лезть все глубже и глубже вплоть до железа и законов физики в целом а так же термодинамики в частности то без знаний алгоритмов, без знаний структур данных, без понимания базовых принципов работы современной вычислительной техники не обойтись абсолютно.
Если человек хочет создать что-то новое нужно сначала понять старое, пропустить через себя, проанализировать и внести свой фундаментальный вклад.
Если резюмировать
набор базовых знаний плюс ситуативное обучение для достижения результата = ремесленник с ограниченным спектром возможностей.
понимание основ, перво причин, знание истории своей отрасли и смежных дисциплин = профессионал способный на многое.
И здесь помогут знания, не навыки, а именно знания — ведь проблему можно видеть с разных сторон, подбирать разные инструменты, делать кросс-проверки результатов разными инструментами, по сути уже вести исследования.
К сожалению приобритение знаний в «бою» дорогое удовольсвтвие, а уж тем более фундаментальных.
А если у человека есть боевые навыки которые его спасали N раз то при изменении конфигурации навыки уже не работают, нужны знания чтоб правильно и быстро оценить изменения и найти адекватное решение, ведь не заново навыки приобретать же на каждую ситуацию :-)
Хм, в теории вы правы, но лишь от части
— процент не спасовавших — очень мал, эта статья тому подтверждение
— люди не обладающие знаниями просто не могут решить задачу где нужна математика, проблема в том что ни кто им не скажет — сначала выучи вот эти термины и знаки, потом матанализ вот от сюда до сюда, потом… а они предоставлены сами себе, в итоге за много лет работы в области я видел лишь одного человека который смог проковырять этот слой и составить для себя «картину мира математики» и подобрать адекватное решение.
В лучшем случае они обладают отрывочными и разрозненными сведениями которые не сведены в общую картину. Хотя очень часто даже те отрывочные сведения наполнены слоями дезинформации которая воспринимается как истина.
Из моей недавней практики — один менеджер с 20 летним опытом разработки недавно убеждал коллег, что нужно использовать нейронные сети для обнаружения сбоев в боевом процессе и восстановлении на лету. Когда задал вопрос — «Что в вашем понимании нейронные сети ?» получил массу незабываемого опыта.
Спасибо, интересный способ, а можно ли это решение прикрутить вживую — чтоб сбор данных и визуализация были одновременными?
Плюс с нескольких машин одновременно?
В расчет стоит брать несколько вещей
— Вы совершенно правы, говоря, что задача перед инженерами MS стояла не тривиальная — логи из ядра штука не тривиальная, достаточно хотя бы посмотреть как с этим делом справляется Линукс
— Желчность статьи скорее можно списать на культурные особенности англо-саксов и современных американцев, т.е. уровень эмоций нужно поделить где то на 5 чтоб получить соотносимое с нашей культурой восприятие.
— В свое время занимался получением трейсов из драйверов через ETW. Что могу сказать — незабываемый опыт:
* Плохо документированное API, порой откровенно вводит в заблуждение в силу мелких ошибок или пробелов
* Реверс инжиниринг получаемых структур от драйвера ибо они вообще не документированы от слова совсем
* Дублирование информации в получаемых структурах (порой по нескольку раз на 1 структуру с вложенными структурами)
* ThreadID (если источником данных является UserSpace процесс) не соответсвует реальному Thread
* Если пишите в файл системными функциями ETW будьте готовы к тому что файл будет поврежден — перееханный системный заголовок, HexEdit вам в руки (говорят в Windows 8 исправлено, но на слово верить не привык)
* Отдельный трэд для потребления можно вполне понять, но удобства это не добавляет
* «Удобство» API можно конечно тоже переварить, не самое худшее, но до приемлимого уровня ему еще далеко.
* Были еще какие то сложности и не мало, но за давностью лет уже не помню.
В общем как всегда — все усилия на индусов и C# а люди что пишут драйвера и так умные — разберутся сами в спагетти из идей и недокументированного API, дебаггер в руки и побежали.
Нанимают конечно по разным причинам, есть и талантливые ребята, но их процент не может быть даже 50% их значительно меньше, а гребут почти всех.
Вот смотрите — чтоб нанять классного спеца нужно от 180 тысяч долларов в США (долина) и от 70 тысяч в евро в германии-франции. За эти деньги можно нанять 2х иностранцев, даже притащив их в страну, все равно выглядит значительно дешевле.
Но это не все… проблема в том что те кто получает от 180к прикормлены очень хорошо и куда то бежать им смысла нет, т.е. просто так их на рынке не найти, а чаще всего нужно «срочно и вчера». Т.е. формирование комманды специалистов это многолетний процесс. Вот и получаем то что имеем.
Я рискую выхватить минусов конечно, но в индустрии уже лет 25 и работаю последние 15 не в РФ и могу точно сказать что 90% тех кого тянут из-за рубежа тупо дешевле, таланты на моей памяти были единицы, а когда сравниваешь тех кто приезжает (да, я сам такой был) с выпусниками хороших местных вузов сравнение не в пользу приезжих, уж извините.
Возьмем копилятор С++ и написание на асме, выгода на лицо. Поэтому за компилятор мы будем бороться до последнего :)
А вот эта библиотека какой выигрыш нам даст? Сколько мы ее будем интегрировать, отлаживать и какой выигрыш получим в конце? Если баланс сходится в плюс то используем, а если нет — то зачем?
Не поймите меня не правильно, я не против конкретно этого примера из статьи, но в масштабах индустрии вижу как целое поколение инженеров выбирает усложнение из соображений «это прикольно» нежели из соображений «это выгодно».
Недавний пример, пишем под код SoftCore NIOS II, один ведуший (!!) инженер решает завернуть все вызовы к APB регистрам в классы на шаблонах, вместо классических функций Write & Read уже протестированных, отлаженных и надежных как кувалда.
По итогу за каждую запись в регистр мы платили +22% (по сравнению с простой Write) в текстовом сегменте программы и -30% от производительности того же сишного кода и где то через пол года нашли баг в разыменовании 0 указателя, а через год разработки уткнулись в предел памяти. Все это нам стоило еще пары месяцев работы только чтоб все это разгрести, а выгода от С++ классов для доступа к регистрам была 0, я не шучу, все та же запись, но по другому выглядела.
Гениальность в простоте… но уходят десятилетия чтоб научиться эту простоту создавать.
А если серьезно, я не говорил что крив сам GCC, кривой тулчейн, а конкретно backend под мико32.
Увеличение сложности системы (да, увеличение: больше кода — больше точек отказа, спросите ребят из бэк-енда современных веб технологий считают ли они что все сделано правильно?) должно быть оправдано.
Если без дебаггера ни как — мы в таких случая деоптимизируем только функции выборочно.
Другой важный момент — производительность, функции на шаблонах и других расширенных возможностях компилятора очень хорошо оптимизируются, стэк схлопывается и все превращается в несколько инструкций, но стоит только эту функцию деоптимизировать и у вас может быть 70-80 кратный разрыв в производительности с ее оптимизированой версией. Если такая функция вызывается из прерывания и занимает 30 микросекунд — то после деоптимизации один только ее вызов превратится в 2 миллисекунды, а если их несколько…
>>вы вместо того, чтобы доверять себе, обзаводитесь достаточно умным компилятором с достаточно умной системой типов и начинаете доверять ему
Эх, это даже не смешно, тонны примеров из прошлого можно даже не приводить, есть свежачок :) Работаю на Мико32, есть GCC и тул чэйн и вот мы недавно выясняем что эти замечательные тулзы компилируют С++ с ошибками в случае виртуальных функций, если в С функции параметр 16 битный то стек едет, есть и другие косяки.
Увы, доверять это не про нас.
Вот пишете Вы под микроконтроллер, памяти в обрез, герцев мало, код хотите видеть простой, понятный и предсказуемый, так как хороший дебаггер в реальном времени это не про нас.
И вот вместо приблизительно такого кода:
GPIO_BSRR_Write(GPIOA, (1<<1) | (1 << 3));
GPIO_BSRR_Write(GPIOB, (1 << 1));
GPIO_BSRR_Write(GPIOC, (1<<1) | (1 << 3));
У вас пара сотен линий кода на шаблонах и трудно предсказуемого шаманства компилятора, которое у любого ревьювера вызовет легкий тремор левого века, создаст многократный разрыв производительности в дебажной и релизной сборках, а так же при поиске багов будет как магнит притягивать к себе внимание всей команды инженеров.
Куда то мы не туда сворачиваем…
Да что говорить, код для миссии Аполо например был разработан при участии вот этой замечательной девушки
https://en.wikipedia.org/wiki/Margaret_Hamilton_(scientist)
Вы представляете сложность и ответственность этого кода?
Так вот, все было, но профессию девушки стали покидать, вопрос лишь почему. Не думаю, что мужчины выпихивали девушек из индустрии, но что-то поменялось в том числе и в головах девушек или их представлении о профессии.
Коротких путей нет — хотите сделать код стабильнее — вычитайте все предупреждения и исправьте код.
А так как люди не глупые и уже многое преодолели верят в себя и основываясь на слепой вере применяют старую "изоленту и проволоку", когда нужно читать теорию графов и дискретную математику.
Если человек готовы выходить за рамки своей зоны комфорта и лезть все глубже и глубже вплоть до железа и законов физики в целом а так же термодинамики в частности то без знаний алгоритмов, без знаний структур данных, без понимания базовых принципов работы современной вычислительной техники не обойтись абсолютно.
Если человек хочет создать что-то новое нужно сначала понять старое, пропустить через себя, проанализировать и внести свой фундаментальный вклад.
Если резюмировать
К сожалению приобритение знаний в «бою» дорогое удовольсвтвие, а уж тем более фундаментальных.
А если у человека есть боевые навыки которые его спасали N раз то при изменении конфигурации навыки уже не работают, нужны знания чтоб правильно и быстро оценить изменения и найти адекватное решение, ведь не заново навыки приобретать же на каждую ситуацию :-)
— процент не спасовавших — очень мал, эта статья тому подтверждение
— люди не обладающие знаниями просто не могут решить задачу где нужна математика, проблема в том что ни кто им не скажет — сначала выучи вот эти термины и знаки, потом матанализ вот от сюда до сюда, потом… а они предоставлены сами себе, в итоге за много лет работы в области я видел лишь одного человека который смог проковырять этот слой и составить для себя «картину мира математики» и подобрать адекватное решение.
В лучшем случае они обладают отрывочными и разрозненными сведениями которые не сведены в общую картину. Хотя очень часто даже те отрывочные сведения наполнены слоями дезинформации которая воспринимается как истина.
Из моей недавней практики — один менеджер с 20 летним опытом разработки недавно убеждал коллег, что нужно использовать нейронные сети для обнаружения сбоев в боевом процессе и восстановлении на лету. Когда задал вопрос — «Что в вашем понимании нейронные сети ?» получил массу незабываемого опыта.
Плюс с нескольких машин одновременно?
— Вы совершенно правы, говоря, что задача перед инженерами MS стояла не тривиальная — логи из ядра штука не тривиальная, достаточно хотя бы посмотреть как с этим делом справляется Линукс
— Желчность статьи скорее можно списать на культурные особенности англо-саксов и современных американцев, т.е. уровень эмоций нужно поделить где то на 5 чтоб получить соотносимое с нашей культурой восприятие.
— В свое время занимался получением трейсов из драйверов через ETW. Что могу сказать — незабываемый опыт:
* Плохо документированное API, порой откровенно вводит в заблуждение в силу мелких ошибок или пробелов
* Реверс инжиниринг получаемых структур от драйвера ибо они вообще не документированы от слова совсем
* Дублирование информации в получаемых структурах (порой по нескольку раз на 1 структуру с вложенными структурами)
* ThreadID (если источником данных является UserSpace процесс) не соответсвует реальному Thread
* Если пишите в файл системными функциями ETW будьте готовы к тому что файл будет поврежден — перееханный системный заголовок, HexEdit вам в руки (говорят в Windows 8 исправлено, но на слово верить не привык)
* Отдельный трэд для потребления можно вполне понять, но удобства это не добавляет
* «Удобство» API можно конечно тоже переварить, не самое худшее, но до приемлимого уровня ему еще далеко.
* Были еще какие то сложности и не мало, но за давностью лет уже не помню.
В общем как всегда — все усилия на индусов и C# а люди что пишут драйвера и так умные — разберутся сами в спагетти из идей и недокументированного API, дебаггер в руки и побежали.