Нужно прочитать
Steve Freeman, Nat Pryce. Growing Object-Oriented Software, Guided by Tests.
Jeff Langr and Tim Ottinger. Agile in a Flash: Speed-Learning Agile Software Development.
Ben Klemens. 21st Century C.
Brent Laster. Professional Git.
Ian Dees, Matt Wynne, Aslak Hellesoy. Cucumber Recipes. Automate Anything with BDD Tools and Techniques.
Shankar Garg. Cucumber Cookbook.
Dr. Mark Fisher. ARM Cortex M4 Cookbook.
Howard Johnson. High-Speed Digital Design: A Handbook of Black Magic.
Marty Cagan. Inspired: How To Create Products Customers Love.
Ли Атчисон. Масштабирование приложений. Выращивание сложных систем.
Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения.
Яцек Галовиц. С++17 STL. Стандартная библиотека шаблонов.
Ivor Horton, Peter Van Weert. Beginning C++17.
Scott Meyers. Effective Modern C++. 42 Specific Ways to Improve Your Use of C++11 and C++14.
Цикл статей "Why We Need Build Systems"
Автор: Martin Bond
Статьи цикла:
Why We Need Build Systems URL: https://blog.feabhas.com/2021/06/why-we-need-build-systems/
CMake Part 1 – The Dark Arts URL: https://blog.feabhas.com/2021/07/cmake-part-1-the-dark-arts/
CMake Part 2 – Release and Debug builds URL: https://blog.feabhas.com/2021/07/cmake-part-2-release-and-debug-builds/
CMake Part 3 – Source File Organisation URL: https://blog.feabhas.com/2021/08/cmake-part-3-source-file-organisation/
Цикл содержит обзор инструментов для построения проектов в целом и более подробно описывает один из них - CMake. Подобных описаний в Сети немало. Главная особенность, по которой я выделил его из общей массы, состоит в том, что акцент делается на использовании CMake для кросс-компиляции проектов для процессоров и контроллеров ARM на IBM PC. Это делает статьи особенно интересными для эмбеддеров, которые в целом не избалованы обилием инструментов непрерывной интеграции.
Цикл еще не завершен. Автор обещает, что следующая статья будет посвящена сборке проектов для ARM в среде Microsoft Windows.
Рекомендую в первую очередь тем, кто заинтересован в построении системы непрерывной интеграции для проектов на микроконтроллерах, но еще не реализовал свои намерения.
Статьи цикла:
Why We Need Build Systems URL: https://blog.feabhas.com/2021/06/why-we-need-build-systems/
CMake Part 1 – The Dark Arts URL: https://blog.feabhas.com/2021/07/cmake-part-1-the-dark-arts/
CMake Part 2 – Release and Debug builds URL: https://blog.feabhas.com/2021/07/cmake-part-2-release-and-debug-builds/
CMake Part 3 – Source File Organisation URL: https://blog.feabhas.com/2021/08/cmake-part-3-source-file-organisation/
Цикл содержит обзор инструментов для построения проектов в целом и более подробно описывает один из них - CMake. Подобных описаний в Сети немало. Главная особенность, по которой я выделил его из общей массы, состоит в том, что акцент делается на использовании CMake для кросс-компиляции проектов для процессоров и контроллеров ARM на IBM PC. Это делает статьи особенно интересными для эмбеддеров, которые в целом не избалованы обилием инструментов непрерывной интеграции.
Цикл еще не завершен. Автор обещает, что следующая статья будет посвящена сборке проектов для ARM в среде Microsoft Windows.
Рекомендую в первую очередь тем, кто заинтересован в построении системы непрерывной интеграции для проектов на микроконтроллерах, но еще не реализовал свои намерения.
Читаю
Bartłomiej Filipek.
C++17 in Detail. Learn the Exciting Features of The New C++ Standard!
C++17 in Detail. Learn the Exciting Features of The New C++ Standard!
Перлы с собеседований
Дико звучит, но регулярно встречается ситуация, когда кандидат на должность миддла (а в отдельных случаях - даже на сеньора) не знает о существовании некоторых ключевых слов языка программирования, на котором он намеревается работать в моей команде.
Причем это относится даже к языку C, который в общем весьма лаконичен и обладает очень компактным набором ключевых слов. Особенно почему-то не повезло restrict. Несмотря на то, что это ключевое слово с нами уже пару десятилетий (начиная со стандарта C99), лишь единственный кандидат правильно ответил на вопрос о его назначении, и еще двое сказали, что смутно припоминают о существовании этого слова, но не могут ответить, для чего оно применяется. Для эмбеддеров такое пренебрежение деталями языка особенно странно, если учесть, насколько сильно restrict влияет на оптимизацию кода, а где еще, если не в приложениях реального времени, так важно обеспечить высокое быстродействие.
Интересная закономерность: молодежь легче относится к таким промахам, многие просят рассказать, что это за слово такое и как им пользоваться. Ветераны воспринимают гораздо болезненнее и начинают доказывать, что раз уж они обходились без этого слова всю жизнь, то этому слову грош цена, ведь ого-го какие проекты без него отгрохали! А всякие керниганы только воду мутят, засоряя язык разными излишествами.
Кстати, не исключено, что именно с легкой руки подобных экспертов по миру до сих пор гуляют байки о том, что без ассемблерных вставок в эмбеддинге никуда.
Причем это относится даже к языку C, который в общем весьма лаконичен и обладает очень компактным набором ключевых слов. Особенно почему-то не повезло restrict. Несмотря на то, что это ключевое слово с нами уже пару десятилетий (начиная со стандарта C99), лишь единственный кандидат правильно ответил на вопрос о его назначении, и еще двое сказали, что смутно припоминают о существовании этого слова, но не могут ответить, для чего оно применяется. Для эмбеддеров такое пренебрежение деталями языка особенно странно, если учесть, насколько сильно restrict влияет на оптимизацию кода, а где еще, если не в приложениях реального времени, так важно обеспечить высокое быстродействие.
Интересная закономерность: молодежь легче относится к таким промахам, многие просят рассказать, что это за слово такое и как им пользоваться. Ветераны воспринимают гораздо болезненнее и начинают доказывать, что раз уж они обходились без этого слова всю жизнь, то этому слову грош цена, ведь ого-го какие проекты без него отгрохали! А всякие керниганы только воду мутят, засоряя язык разными излишествами.
Кстати, не исключено, что именно с легкой руки подобных экспертов по миру до сих пор гуляют байки о том, что без ассемблерных вставок в эмбеддинге никуда.
Перлы с собеседований
Неожиданные затруднения у кандидатов вызывает ответ на, казалось бы, простой вопрос: является ли язык C подмножеством языка C++? Или другими словами, любая ли корректная программа на C является корректной программой на C++?
Подавляющее большинство с усмешкой превосходства без тени сомнения отвечают: ну, да, общеизвестная истина, C является подмножеством C++. Из более сотни опрошенных лишь двое дали правильный ответ, и один из них смог привести пример несовместимости этих языков.
Забавно, что почти все декларируют знание писаний Страуструпа. При этом полностью игнорируют важнейший документ, который целиком посвящен совместимости C и C++: https://isocpp.org/files/papers/N0007.pdf
Подавляющее большинство с усмешкой превосходства без тени сомнения отвечают: ну, да, общеизвестная истина, C является подмножеством C++. Из более сотни опрошенных лишь двое дали правильный ответ, и один из них смог привести пример несовместимости этих языков.
Забавно, что почти все декларируют знание писаний Страуструпа. При этом полностью игнорируют важнейший документ, который целиком посвящен совместимости C и C++: https://isocpp.org/files/papers/N0007.pdf
Перлы с собеседований
Во время собеседований, к сожалению, подавляющее большинство кандидатов отваливается на самой ранней стадии, поскольку люди даже не удосуживаются хотя бы сколько нибудь изучить язык, который они декларируют как рабочий инструмент. Но некоторые с горем пополам преодолевают планку арифметики указателей и конструкторов класса, и можно начать разговор о чем-то действительно интересном. Например, обеспечении качества кода. И тут частенько возникает конфуз. Вполне себе безобидный вопрос:
- Как вы тестируете свой код?
Кандидат приободряется, в голосе возникает уверенность:
- Разумеется, отладчиком!
Ну да, чем же еще, собственно... Следующий вопрос:
- А как же в таком случае вы отлаживаете свой код?
Ступор, замешательство, вселенская печаль в глазах... Самое удивительное, что эти люди искренне считают себя профессионалами и не понимают, чего от них хотят.
- Как вы тестируете свой код?
Кандидат приободряется, в голосе возникает уверенность:
- Разумеется, отладчиком!
Ну да, чем же еще, собственно... Следующий вопрос:
- А как же в таком случае вы отлаживаете свой код?
Ступор, замешательство, вселенская печаль в глазах... Самое удивительное, что эти люди искренне считают себя профессионалами и не понимают, чего от них хотят.
Прощай, МТС.
В пятницу попрощался с сотрудниками из ростовского филиала МТС.
Проработал в этом коллективе шестнадцать с половиной лет. Начинал в составе фирмы ЦТС, затем вместе с прочим движимым имуществом был продан в МТС (в период распухания последней во всероссийском масштабе).
Конечно, прощание - это всегда нелегко, особенно после такого долгого срока. Но, увы, действительно пришла пора. Не в последнюю роль в этом играет чванство московских хозяйчиков, которые единогласно пришли к мнению, что за пределами столицы потребности у людей должны быть в несколько раз ниже. Причем, что забавно, я долгое время проводил собеседования с кандидатами на работу в нашем отделе и в резюме видел их зарплатные ожидания. Большинство желают зарплату минимум на уровне ныне работающих ведущих специалистов и выше (о квалификации этих кандидатов разговор особый, из них делать нормального работника еще несколько лет нужно). Штатным же работникам зарплату не то чтобы увеличивать - даже индексировать не торопятся, ссылаясь на финансовые трудности (акционерам на куршавели не хватает). Да и зачем, простаки довольствуются сказками о рыночном уровне оплаты, хотя вакансии при этом не заполняются подолгу, как ни странно.
Ну да ладно, хватит о плохом. В пятницу очень душевно посидели с коллегами (к сожалению, уже бывшими). Конечно, расставание - это очень грустно, но замечательные люди, окружавшие меня, это одно, а работа с явно выраженным душком - совсем другое, и менять ее необходимо. Впрочем, надеюсь увидеть своих друзей еще не раз.
А в понедельник подписываю обходной, получаю документы и иду оформляться на новую работу.
Проработал в этом коллективе шестнадцать с половиной лет. Начинал в составе фирмы ЦТС, затем вместе с прочим движимым имуществом был продан в МТС (в период распухания последней во всероссийском масштабе).
Конечно, прощание - это всегда нелегко, особенно после такого долгого срока. Но, увы, действительно пришла пора. Не в последнюю роль в этом играет чванство московских хозяйчиков, которые единогласно пришли к мнению, что за пределами столицы потребности у людей должны быть в несколько раз ниже. Причем, что забавно, я долгое время проводил собеседования с кандидатами на работу в нашем отделе и в резюме видел их зарплатные ожидания. Большинство желают зарплату минимум на уровне ныне работающих ведущих специалистов и выше (о квалификации этих кандидатов разговор особый, из них делать нормального работника еще несколько лет нужно). Штатным же работникам зарплату не то чтобы увеличивать - даже индексировать не торопятся, ссылаясь на финансовые трудности (акционерам на куршавели не хватает). Да и зачем, простаки довольствуются сказками о рыночном уровне оплаты, хотя вакансии при этом не заполняются подолгу, как ни странно.
Ну да ладно, хватит о плохом. В пятницу очень душевно посидели с коллегами (к сожалению, уже бывшими). Конечно, расставание - это очень грустно, но замечательные люди, окружавшие меня, это одно, а работа с явно выраженным душком - совсем другое, и менять ее необходимо. Впрочем, надеюсь увидеть своих друзей еще не раз.
А в понедельник подписываю обходной, получаю документы и иду оформляться на новую работу.
Инструмент системного моделирования
В течение многих лет до недавнего времени занимался исключительно разработкой программного обеспечения (даже в проектах, под которые разрабатывалось специальное оборудование, довольствовался исключительно высокоуровневым кодом). И много лет помогал в этом деле универсальный язык моделирования UML.
Многие определения UML (например, приведенное в Википедии) гласят:
В процессе поиска обнаружил, что каким-то образом мимо меня проскочил близкий родственник UML - SysML (Systems Modeling Language). Первое шапочное знакомство с новым (для меня) языком показалось многообещающим. Кстати, сам факт его наличия как бы намекает, что с обещанным системным проектированием у UML дело обстоит не так уж гладко, иначе зачем бы пришлось плодить сущности без необходимости.
На повестке 1) изучение SysML, 2) поиск подходящего инструмента моделирования (весьма желательно open source), 3) внедрение практики системного моделирования в процессы лаборатории, где начну трудиться буквально через считанные дни.
Многие определения UML (например, приведенное в Википедии) гласят:
Я настолько привык к этому определению, что до поры нимало не сомневался в его справедливости. Поэтому, когда недавно перешел к разработке встроенных систем, с энтузиазмом попытался использовать UML для построения моделей как аппаратной части, так и системы в целом. Весьма неприятным открытием было то, что реально попытки системного проектирования заходили в тупик. Поиски методологии в литературе и Сети также ничем не увенчались. В то же время иметь на системном уровне такую же мощную и выразительную нотацию, какую UML предоставляет для программной части проекта, было бы весьма заманчиво.
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
В процессе поиска обнаружил, что каким-то образом мимо меня проскочил близкий родственник UML - SysML (Systems Modeling Language). Первое шапочное знакомство с новым (для меня) языком показалось многообещающим. Кстати, сам факт его наличия как бы намекает, что с обещанным системным проектированием у UML дело обстоит не так уж гладко, иначе зачем бы пришлось плодить сущности без необходимости.
На повестке 1) изучение SysML, 2) поиск подходящего инструмента моделирования (весьма желательно open source), 3) внедрение практики системного моделирования в процессы лаборатории, где начну трудиться буквально через считанные дни.
Вести Мордора
Совершенно случайно наткнулся на заметку:
Вот так скромненько. Участвовало 78 команд со всего мира. Наши ребята сделали всех, но в новостях я об этом почему-то не услышал. Видимо, трудная судьба Кокорина для страны важнее.
Ученики СУНЦ НГУ выиграли медали Международной математической олимпиады в Индии
В Международной математической олимпиаде в г. Лакхнау (Индия) IYMC - Mathematica - 2018 команда СУНЦ НГУ была единственным представителем России. В составе команды были Ханина М (11-8 кл), Оглоблин И (11-2 кл), Степанов И (11-1 кл). Руководитель команды - преподаватель кафедры математических наук ММФ и СУНЦ НГУ Львов Антон Павлович. По результатам олимпиады в индивидуальном зачете золотую медаль получил Иван Оглоблин и серебряную - Мария Ханина.
Поздравляем ребят с победой! Выражаем благодарность руководителю Антону Павловичу Львову за подготовку команды!
Вот так скромненько. Участвовало 78 команд со всего мира. Наши ребята сделали всех, но в новостях я об этом почему-то не услышал. Видимо, трудная судьба Кокорина для страны важнее.
Мы все учились. Понемногу.
Попалась на глаза любопытная заметка: Об ахиллесовой пяте одной сверхдержавы. Речь в ней идет об образовании в целом и высшем образовании в частности.
Не то чтобы содержание меня поразило. Напротив, как бы подвело итог личным наблюдениям за последние несколько лет.
Во время работы в МТС регулярно проводил собеседования с кандидатами в разработчики программного обеспечения (в основном C# и Java). Побеседовал с несколькими десятками кандидатов с различным опытом - от вчерашних выпускников вузов (а порой и старшекурсников, ищущих подработку по специальности) до ветеранов пенсионного возраста. В целом, конечно, картина удручающая. Лишь единицы обладают минимально необходимой квалификацией. Был даже кандидат физ-мат наук, не имевший понятия об объектной парадигме, но уверявший, что он сугубый практик и изучает все по ходу, как только оно понадобится в текущем проекте. Ну-ну...
Недавно сменил работу, из "больших" программистов перешел в эмбеддеры. На новой работе также регулярно поручают собеседовать кандидатов на работу. С программистами картина не изменилась - город тот же, откуда взяться другим. Порой повторно попадаются те же, кого отсеял еще на прошлой работе, - мир весьма тесен. Но теперь добавились еще и электронщики.
Поначалу меня поразило, что люди, намеренные посвятить себя разработке электронных девайсов, причем весьма нетривиальных, не могут сформулировать закон Ома. Насколько помню, его проходят еще в школе, и в принципе его обязан знать любой обладатель аттестата о среднем образовании, если он (аттестат) не куплен по случаю в подземном переходе. Но выпускники радиотехнических институтов и университетской радиофизики...
Дальше интереснее. Без ответа остаются вопросы о том, что такое напряжение и ток. Круглые от изумления глаза в ответ на непристойное предложение написать и решить дифференциальные уравнения, описывающие процессы в RC-цепях. Кое-кто способен нарисовать вольт-амперную характеристику P-N перехода, пусть и не с первого раза, но объяснить механизм его работы и рассказать ту же модель Эберса-Молла - увольте. Претендент на разработку FPGA не может нарисовать синхронный двоичный счетчик. Апофеоз наступил, когда выпускник, недавно стажировавшийся на полупроводниковом производстве, заявил, что не проходил квантовую механику (речь зашла о механизме туннельного пробоя в P-N переходе, который классическими представлениями вряд ли можно объяснить). На физфаке университета, Карл!!!
Как выживать и, главное, развиваться в этих нелегких условиях? Пока пришли к непростому, но единственно возможному решению: готовить специалистов для себя самим, не надеясь на фортуну. Отобрали несколько заинтересованных студентов, занимаюсь с ними пока раз в неделю по паре часов. Понимаю, что этого очень мало, но хоть что-то.
Напоминает прежние времена, когда на заводских проходных висели объявления, приглашающие учеников токаря, фрезеровщика, слесаря... И еще более ранние, когда в натуральных хозяйствах производилось все необходимое для собственного потребления. Назад, в будущее?
Не то чтобы содержание меня поразило. Напротив, как бы подвело итог личным наблюдениям за последние несколько лет.
Во время работы в МТС регулярно проводил собеседования с кандидатами в разработчики программного обеспечения (в основном C# и Java). Побеседовал с несколькими десятками кандидатов с различным опытом - от вчерашних выпускников вузов (а порой и старшекурсников, ищущих подработку по специальности) до ветеранов пенсионного возраста. В целом, конечно, картина удручающая. Лишь единицы обладают минимально необходимой квалификацией. Был даже кандидат физ-мат наук, не имевший понятия об объектной парадигме, но уверявший, что он сугубый практик и изучает все по ходу, как только оно понадобится в текущем проекте. Ну-ну...
Недавно сменил работу, из "больших" программистов перешел в эмбеддеры. На новой работе также регулярно поручают собеседовать кандидатов на работу. С программистами картина не изменилась - город тот же, откуда взяться другим. Порой повторно попадаются те же, кого отсеял еще на прошлой работе, - мир весьма тесен. Но теперь добавились еще и электронщики.
Поначалу меня поразило, что люди, намеренные посвятить себя разработке электронных девайсов, причем весьма нетривиальных, не могут сформулировать закон Ома. Насколько помню, его проходят еще в школе, и в принципе его обязан знать любой обладатель аттестата о среднем образовании, если он (аттестат) не куплен по случаю в подземном переходе. Но выпускники радиотехнических институтов и университетской радиофизики...
Дальше интереснее. Без ответа остаются вопросы о том, что такое напряжение и ток. Круглые от изумления глаза в ответ на непристойное предложение написать и решить дифференциальные уравнения, описывающие процессы в RC-цепях. Кое-кто способен нарисовать вольт-амперную характеристику P-N перехода, пусть и не с первого раза, но объяснить механизм его работы и рассказать ту же модель Эберса-Молла - увольте. Претендент на разработку FPGA не может нарисовать синхронный двоичный счетчик. Апофеоз наступил, когда выпускник, недавно стажировавшийся на полупроводниковом производстве, заявил, что не проходил квантовую механику (речь зашла о механизме туннельного пробоя в P-N переходе, который классическими представлениями вряд ли можно объяснить). На физфаке университета, Карл!!!
Как выживать и, главное, развиваться в этих нелегких условиях? Пока пришли к непростому, но единственно возможному решению: готовить специалистов для себя самим, не надеясь на фортуну. Отобрали несколько заинтересованных студентов, занимаюсь с ними пока раз в неделю по паре часов. Понимаю, что этого очень мало, но хоть что-то.
Напоминает прежние времена, когда на заводских проходных висели объявления, приглашающие учеников токаря, фрезеровщика, слесаря... И еще более ранние, когда в натуральных хозяйствах производилось все необходимое для собственного потребления. Назад, в будущее?