У нас на работе есть Сергей, он заместитель директора по общехозяйственным вопросам или же просто завхоз. Перегорела лампа – к нему. Сломался стул – к нему. Дверь с петель сорвали – Сергей починит. Нужна новая розетка – он поможет. Не хватает площадей – организует стройку. И вообще спасибо ему за свет и тепло в нашем офисе! Нет, серьезно, мы все понимаем, что это его заслуга, он нашел людей, проконтролировал их работу и проводит технические обслуживания, поэтому у нас в офисе всегда светло и тепло. Свою работу он никак не презентирует, поскольку то, что он может все это сделать ни для кого не является тайной, он же завхоз, а, значит, умеет все это делать (иначе завхозом он не стал бы). Логично, правда? С другой стороны его работу за него никто не делает: лампочки не меняют, замки не чинят, снег не чистят, воздух с батарей не спускают. Конечно, со временем можно даже медведя на мотоцикле научить ездить, так что коллеги научились болты выпадающие подкручивать, батареи регулировать, самые продвинутые выучили что если мебель ломается нужно ему звонить, а когда нужно купить что-то новое то что-то старое нужно сфотографировать чтобы точно то купил. Работа его кажется людям сложной (или же люди просто не хотят делать сами даже если так быстрее) и в неё никто не лезет, не претендует на его лавры.

Несколько раз начинал писать эту статью и бросал. Бросал потому, что тема, как мне кажется, несколько спорная. Изобретенный мною велосипед может кому-то показаться смешным и нелепым и вообще не совсем корректным. Тем не менее…

Вообще, мне кажется, что в области разработки электронных устройств существует как бы несколько мало пересекающихся миров. Например, существует разработка устройств на базе микроконтроллеров и параллельно существует разработка устройств на базе ПЛИС. Принципы работы этим микросхем принципиально отличаются и точно так же отличаются принципы и методы разработки, используемые языки программирования и отладки. Конечно, выбор элементной базы сильно зависит от поставленной задачи. Однако и так понятно, что эти миры, мир микроконтроллеров и мир ПЛИСов почти не пересекаются. Может быть на стыке технологий что-то есть?

Сентябрь у многих уже ассоциируется с окончанием сезона отпусков, но у большинства — с учёбой. К началу нового учебного года предлагаем вам подборку видео наших образовательных проектов, выложенных на Youtube-канале Технострим. Подборка состоит из трёх частей: новые курсы на канале за 2018-2019 учебный год, самые просматриваемые курсы и самые просматриваемые видео.

Привет, Хабр!

Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков. Прежде всего потому, что довольно часто слышу подобное мнение среди Junior QA, кто только делает свои первые шаги в тестировании и уже боится, что чего-то не успел.

Справедливости ради, подобное мнение бытует и среди ребят постарше. Довольно часто считается, что автоматизация — чуть ли не единственный путь развития ручного тестировщика. Обо всем этом и многом другом под катом.

Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.

Может они просто не умеют их «готовить»?

Прочитав статью «Тестирование встроенных систем» и комментарии к ней я был несколько поражен тем фактом, что многие хабровчане знакомы с книгой «Test Driven Development for Embedded C (Pragmatic Programmers)» и framework-ом Unity, но не используют весь арсенал средств, которые предлагают ребята из throwtheswitch.org.

Хочу кратко поделится опытом использования этих самых средств.

Некоторое время назад я принял решение потихоньку внедрять в свою практику автоматизированное тестирование и TDD. Признаюсь честно, получалось все это с переменным успехом. Но то, что жить стало гораздо интереснее – это неоспоримый факт. Со мной стали происходить разные приключения. И, как во всех приключениях, иногда становилось немного страшно. Об одном таком случае я и хочу рассказать.

В проекте, в котором я принимал участие, потребовалась плотная работа с временными интервалами от минуты до года. Плох (или наоборот слишком хорош) программист, не написавший в своей жизни ни одну библиотеку работы с датами. Я не хуже и не лучше других, поэтому решил размять мозги и создать немного кода.

Привет, Хабр! Ранее выложил свои странные размышления v1.0, v2.0. Хотя, конечно, это полный бред, но вопросы поднимаются непростые. Спасибо за поддержку и ценные мысли. Сегодня окончание этой непонятной истории.

Соединение отделов

Пятница на работе началась с большого переполоха. К нам на этаж переезжали конструкторы из КБ. Всех остальных перемещали по принципам офисной чехарды. В соседний бокс мимо меня прошел сисадмин Иван. В руках он держал новенький ноутбук. Сисадмины — одни из немногих, с кем можно нормально пообщаться.

— Привет Ваня, как дела?
— Вот переезжаем, теперь буду рядом с тобой сидеть.
— А это, что?..
— Да вот. Ноутбук одного из директоров, с Windows 10. В настройку отдали. Тормозит чегой-то.

АСКУЭ – Автоматизированные Системы Контроля и Учета Энергоресурсов. В задачи подобных систем входит сбор данных с приборов учета энергоресурсов (газ, вода, отопление, электричество) и предоставление этих данных в удобном для анализа и контроля виде.

Так как такие системы вынуждены иметь дело с множеством самых различных устройств и контроллеров, чаще всего они построены по модульному принципу. Не так давно меня попросили написать модуль для подобной системы, осуществляющий связь с одним из приборов учета (счетчик электрической энергии трехфазный электронный ЦЭ2753).

По ходу повествования Вам будут встречаться выделенные подобным образом комментарии. Единственная их цель – чтобы Вы не заснули в процессе знакомства со статьей.

Давно хотелось применить автоматизированное тестирование. Я посчитал, что сейчас как раз удобный случай. Почему я так решил?

Здравствуйте, уважаемые Хабражители!

В этой статье я хочу рассказать о том, как однажды решил начать программировать микроконтроллеры, что для этого понадобилось и что в итоге получилось.

Тема микроконтроллеров меня заинтересовала очень давно, году этак в 2001. Но тогда достать программатор по месту жительства оказалось проблематично, а о покупке через Интернет и речи не было. Пришлось отложить это дело до лучших времен. И вот, в один прекрасный день я обнаружил, что лучшие времена пришли не выходя из дома можно купить все, что мне было нужно. Решил попробовать. Итак, что нам понадобится:

Так сложилось, что основным языком для работы с микроконтроллерами является C. Многие крупные проекты написаны именно на нем. Но жизнь не стоит на месте. Современные средства разработки уже давно позволяют использовать C++ при разработке ПО для встраиваемых систем. Однако такой подход до сих пор встречается достаточно редко. Не так давно я попробовал использовать С++ при работе над очередным проектом. Об этом опыте я и расскажу в данной статье.

Для кого эта статья?

Данная статья расскажет о том, как нам удалось внедрить процесс модульного тестирования в команды, работающие по классической каскадной модели, а так же в команды с гибкой методологией (agile). В нашей организации в любой команде за общий процесс и наполнение спринта задачами отвечают проджект менеджеры, которые также участвуют в обсуждении видов тестирования, необходимых под каждую задачу ( совместный мозговой штурм.) и принимают конечное решение. Поэтому моя статья будет в первую очередь нацелена на проджект менеджеров в командах (только потому что у нас они занимают именно такую роль) и всех тех, кто по долгу службы занимается сходными задачами.

Алан Кей — это магистр Йода для ИТишников. Он стоял у истоков создания первого персонального компьютера (Xerox Alto), языка SmallTalk и концепции «объектно-ориентированного программирования». Он уже много высказывался о своем взгляде на образование в сфере Computer Science и советовал книги тем, кто хочет углубить свои познания:

• Алан Кей: как бы я преподавал Computer Science 101
• Алан Кей: «Какие книги Вы бы посоветовали прочесть тому, кто учится на Computer Science»
• Алан Кей (и коллективный интеллект Хабра): какие книги формируют мышление тру инженера
• Алан Кей и Марвин Мински: Computer Science уже имеет «грамматику». Нужна «литература»

Недавно на Quora опять подняли эту тему и обсуждение вышло на первое место на Hacker News. Предлагаю вашему вниманию «новый» список суперстарых и фундаментальных книг по программированию и мышлению программиста от Алана Кея.

Lisp 1.5 Programmers Manual

by John McCarthy, 1962



Книга — абсолютный чемпион и пожизненный лидер рейтинга всех списков книг от Алана Кея. Этой версии языка уже нет, но книга — великолепна.

ещё восемь раритетов:

В силу проектной обстановки нашей команде пришлось изучить возможности языка SystemVerilog, после чего нет-нет, а возникают жаркие споры о том, какая его часть синтезируема, а какая — нет. Чтобы положить конец домыслам, я провёл небольшую проверку на практике. Во время разработки тестового проекта ряд вопросов удалось снять копаясь в литературе, но всплыл один интересный момент, явного описания которого не нашлось. Чтобы исправить положение, я решил его задокументировать.

Итак. Имеем проект, максимально напичканный всяческими SytemVerilog-овскими штучками. Даже если кажется, что применение той или иной вещи не даёт особого выигрыша — это ошибочное впечатление, ведь главная задача «проекта» — именно изучить возможности SystemVerilog. И вот, у нас есть набор из нескольких модулей (конкретно у меня — это UART-приёмники), данные из которых следует «сливать» в единую шину, перебирая их по алгоритму RoundRobin (конкретно в случае с UART — сливаем накопленные данные в единую очередь, которая с другой стороны будет уходить в шину USB).

В 2015 году американская компания Rockwell Collins совместно с Boeing и 3D-Robotics провела испытания устойчивых ко взлому квадрокоптера Iris и беспилотного вертолёта Little Bird со «сверхнадежной» операционной системой.

Разработка защищённых от взлома дронов ведётся по заказу Агентства перспективных оборонных проектов (DARPA) Министерства обороны США, которое заинтересовано в защите перспективных беспилотных и опционально пилотируемых летательных аппаратах от возможных уязвимостей.

Существует как минимум три способа взлома беспилотных летательных аппаратов: первый — получение доступа к управлению посредством взлома канала связи или подмены данных авторизации, второй — использование уязвимостей программного обеспечения, третий — использование интерфейсов и каналов данных оригинального программного обеспечения для загрузки вредоносного кода.

Разработанная Rockwell Collins операционная система на базе микроядра seL4 устойчива ко всем трём типам взлома.

На мой взгляд, в русскоязычном секторе интернета тематика формальной верификации освещена недостаточно, и особенно не хватает простых и наглядных примеров.

Я приведу такой пример из зарубежного источника, и дополню собственным решением известной задачи о переправе волка, козы и капусты на другую сторону реки.

Но вначале вкратце опишу, что из себя представляет формальная верификация и зачем она нужна.

Под формальной верификацией обычно понимают проверку одной программы либо алгоритма с помощью другой.

Это нужно для того, чтобы удостовериться, что поведение программы соответствует ожидаемому, а также обеспечить её безопасность.

Формальная верификация является самым мощным средством поиска и устранения уязвимостей: она позволяет найти все существующие дыры и баги в программе, либо же доказать, что их нет.
Стоит заметить, что в некоторых случаях это бывает невозможно, как например, в задаче о 8 ферзях с шириной доски 1000 клеток: всё упирается в алгоритмическую сложность либо проблему остановки.

Однако в любом случае будет получен один из трёх ответов: программа корректна, некорректна, или же — вычислить ответ не удалось.

В случае невозможности нахождения ответа, зачастую можно переработать неясные места программы, уменьшив их алгоритмическую сложность, для того чтобы получить конкретный ответ да либо нет.

А применяется формальная верификация, например, в ядре Windows и операционных системах беспилотников Darpa, для обеспечения максимального уровня защиты.

Мы будем использовать Z3Prover, очень мощный инструмент для автоматизированного доказательства теорем и решения уравнения.

Причём Z3 именно решает уравнения, а не подбирает их значения грубым брутфорсом.
Это означает, что он способен находить ответ, даже в случаях когда комбинаций входных вариантов и 10^100.

А ведь это всего лишь около дюжины входных аргументов типа Integer, и подобное зачастую встречается на практике.

Задача о 8 ферзях (Взята из англоязычного мануала).

Очень часто путают два понятия валидация и верификация. Кроме того, часто путают валидацию требований к системе с валидацией самой системы. Я предлагаю разобраться в этом вопросе.

В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

Пусть у нас есть проектируемый функциональный объект. Пусть этот объект рассматривается нами как часть конструкции другого функционального Объекта. Пусть есть описание конструкции Объекта, такое, что в нем присутствует описание объекта. В таком описании объект имеет описание как целого, то есть, описаны его интерфейсы взаимодействия с другими объектами в рамках конструкции Объекта. Пусть дано описание объекта как конструкции. Пусть есть информационный объект, содержащий требования к оформлению описания объекта как конструкции. Пусть есть свод знаний, который содержит правила вывода, на основании которых из описания объекта как целого получается описание объекта как конструкции. Свод знаний – это то, чему учат конструкторов в институтах – много, очень много знаний. Они позволяют на основе знанию об объекте спроектировать его конструкцию.

На Software Engineering Stack Exchange я увидел такой вопрос: «Что мешает широкому внедрению формальных методов?» Вопрос был закрыт как предвзятый, а большинство ответов представляли собой комментарии типа «Слишком дорого!!!» или «Сайт — это не самолёт!!!» В каком-то смысле это верно, но мало что объясняет. Я написал эту статью, чтобы дать более широкую историческую картину формальных методов (FM), почему они на самом деле не используются и что мы делаем для исправления ситуации.

Прежде чем начать, нужно сформулировать некоторые условия. На самом деле существует не так много формальных методов: всего несколько крошечных групп. Это означает, что разные группы по-разному применяют термины. В широком смысле есть две группы формальных методов: формальная спецификация изучает запись точных, однозначных спецификаций, а формальная проверка — методы доказательства. Сюда входят и код, и абстрактные системы. Мало того, что мы используем разные термины для кода и систем, мы часто используем разные инструменты для их верификации. Чтобы ещё больше всё запутать, если кто-то говорит, что создаёт формальную спецификацию, обычно это означает и верификацию дизайна. А если кто-то говорит, что делает формальную верификацию, обычно это относится к верификации кода.

Небольшой рассказ о граблях, встреченных на пути познания ARM на примере stm32f103c8t6 и stm32l151rct6.