Книга "RSpec Essentials".

Автор: Mani Tadayon.
Название: RSpec Essentials. Develop testable. modular, and maintainbale Ruby software for the real world using RSpec.
Издательство: Packt Publishing, 2016.
ISBN: 978-1-78439-590-2



Как подсказывает Капитан Очевидность, книга посвящена основам использования инструмента под названием RSpec. Этот инструмент хорошо известен в мире Ruby и представляет средство для BDD (разработки, управляемой поведением).

В отличие от модульных тестов, задача которых - обнаружение ошибок в отдельных методах, основное предназначение RSpec - не столько тестирование, сколько специфицирование желаемого поведения класса либо модуля; другими словами, RSpec - один из вариантов представления требований к ПО.

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

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

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

Рекомендую тем, кто планирует использовать BDD в проектах на Ruby.

Сборник статей "The Sygnal. A compendium of blog posts on op amp design topics".

Автор: Bruce Trump.
Название: The Sygnal. A compendium of blog posts on op amp design topics.
URL: http://www.ti.com/lit/pdf/slyt701

Те, кому доводилось иметь дело с аналоговыми ИС фирмы Texas Instruments, наверняка уже хорошо знакомы с Брюсом Трампом. Остальным знакомство с этой публикацией дарит хороший шанс восполнить этот пробел.

Брюс вел свой блог под названием The Signal, в котором помогал инженерам решить возникшие у них проблемы с использованием операционных усилителей. Те ответы, которые, по мнению Трампа, будут интересны не только задавшим вопрос, были собраны в брошюру, ссылка на которую приведена выше.

Сначала я колебался, отнести ли данную публикацию к статьям либо книгам. Для статьи великоват объем (37 страниц), для книги - отсутствуют необходимые выходные данные (издательство, ISBN...). Решил, что по форме она все же ближе к сборнику статей. Но формальности - не главное, когда имеешь дело с материалом превосходного качества.

Описанию ОУ посвящено множество букварей. Беда в том, что большинство из них описывает идеализированное устройство без учета особенностей конкретных моделей, хотя дьявол обычно кроется именно в деталях. Эти буквари не дают ответа на вопрос, почему вроде бы спаянная схема вместо усиления сорвалась в генерацию или сигнал на выходе не имеет ничего общего в ожидаемым, при этом другой ОУ в таком же включении работает практически идеально.

Дочитав сборник, я спросил себя: остались ли какие-то аспекты работы с операционными усилителями, которые мне интересны, но не освещены здесь? Поразмыслив, я не смог найти пробелов. Охват тем действительно велик: диапазоны сигналов на входах и выходах ОУ, смещение/сдвиг и их поведение при различных режимах, стабильность работы, быстродействие и динамика, шумовые характеристики и их оптимизация, чувствительность к помехам по питанию и их фильтрация, правила обращения с "лишними" ОУ, оставшимися незадействованными в корпусе, защита чувствительных схем по входу, использование ОУ в качестве компараторов (если уж совсем припрет)...

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

Статья "The Inverting Attenuator, G = -0.1… is it unstable?"

Автор: Bruce Trump.
Название: The Inverting Attenuator, G = -0.1… is it unstable?
URL: http://e2e.ti.com/blogs_/archives/b/thesignal/archive/2013/02/04/the-inverting-attenuator-g-0-1-uh-oh-is-it-unstable

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

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

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

Книга "Confident Ruby".

Автор: Avdi Grimm.
Название: Confident Ruby.
Издательство: The Pragmatic Programmer, 2013.



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

Завершающий раздел посвящен анализу кода некоторых проектов open source. Автор находит фрагменты с "запахом" и показывает, как посредством рефакторинга превратить их в лаконичный и хорошо читаемый код. Следить за работой мастера такого уровня - всегда большое удовольствие.

Рекомендую программистам продвинутого уровня (не обязательно пишущим именно на Ruby, достаточно понимать основные идеи). Книга явно не рядовая, хоть и не раскручена в программистских кругах.

Книга "User Story Mapping: Discover the Whole Story, Build the Right Product".

Автор: Jeff Patton.
Название: User Story Mapping: Discover the Whole Story, Build the Right Product.
Издательство: O'Reilly Media, 2014.
ISBN: 978-1491904909



В продаже имеется русский перевод. Однако я довольно осторожно отношусь к переводам с некоторых пор. Увидев, что "Story Mapping" переведено как "Пользовательские истории", а ниже к этому прилеплена отсебятина "Искусство гибкой разработки ПО", я решил ограничиться оригиналом. Если уже на обложке расположены такие вольности, нет никаких гарантий, что и в тексте работники издательства не "заставили эту книгу проектировать чрезвычайно приятный опыт".

Книга в целом посвящена одному из способов представления пользовательских историй при помощи наборов карточек. Сама идея не нова; стандартные заготовки для картотек использовали еще отцы-основатели гибких методологий, да и различные вариации на тему канбанов также их используют. Автор предлагает свою методику представления истории в виде двухмерной карты, где по одной оси история развивается во времени, а по другой - в глубине детализации.

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

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

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

Статья "Don’t Use the Resistor I Told You to Use".

Автор: Harry Holt.
Название: Don’t Use the Resistor I Told You to Use.
URL: http://www.analog.com/en/analog-dialogue/articles/studentzone-june-2017.html

Разработчики старой школы, выросшие на ОУ семейства 741 и "Искусстве схемотехники", с младых ногтей приучены к правилу: импедансы цепей, подключенных к инвертирующему и неинвертирующему входам ОУ, должны быть сбалансированы. Если этот баланс нарушен, токи смещения создадут дополнительное напряжение сдвига, которое в большинстве схем приведет к весьма нежелательным последствиям.

Токи смещения многих современных ОУ уменьшены и приближаются по величине к токам сдвига. В этих условиях введенные для баланса резисторы утрачивают свою роль, а порой и ухудшают параметры схемы по сравнению с несбалансированным вариантом. Кроме того, "лишний" резистор - это всегда источник теплового шума.

Если ОУ работает повторителем, резистор в цепи ОС совместно с емкостью инвертирующего входа создает сдвиг фаз, что может привести к потере устойчивости в случае широкой полосы рабочих частот ОУ.

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

Статья "The Inside Story of Texas Instruments’ Biggest Blunder: The TMS9900 Microprocessor".

Автор: Walden C. Rhines.
Название: The Inside Story of Texas Instruments’ Biggest Blunder: The TMS9900 Microprocessor.
URL: http://spectrum.ieee.org/geek-life/history/the-inside-story-of-texas-instruments-biggest-blunder-the-tms9900-microprocessor

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

Лекция "RTOS Best Practices".

Пятая и последняя часть курса "Embedded System Design Techniques™ - From Bare-metal to Real-Time Operating Systems". Проводит курс Continuous Education Center (CEC). Читает лекцию Джейкоб Бенинго.

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

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

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

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

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

Как и предыдущие лекции, рекомендую разработчикам, начинающим использовать RTOS, за исключением рекомендаций пытаться сшить семь шапок из небольшой овчины.

Лекция "Debugging Real-Time Embedded Systems".

Четвертая часть курса "Embedded System Design Techniques™ - From Bare-metal to Real-Time Operating Systems". Проводит курс Continuous Education Center (CEC). Читает лекцию Джейкоб Бенинго.

Лекция посвящена весьма болезненной для большинства эмбеддеров, не прошедших классической профессиональной подготовки в части программирования, теме - отладке встроенного ПО.

Лекция построена на примерах использования замечательного, без преувеличения, инструмента Tracealyzer от шведской фирмы Percepio AB. Он позволяет собирать массу информации о выполняемой программе и представлять ее в различных удобных для восприятия видах - графиках, диаграммах, логах... Правда, цена за этот инструмент не слишком демократична для индивидуальных разработчиков и тем более хоббистов: более 100 тыр за одну лицензию.

Почему-то в ходе лекции ни разу не прозвучала мысль, ставшая банальной, например, в медицине: болезнь гораздо проще предотвратить, чем потом лечить. Нам наглядно показывают, как в Tracealyzer'е выглядят дедлоки или, например, инверсии приоритетов, но ни слова не говорят о том, как легко избежать этих неприятностей. Если продолжать медицинскую аналогию, мне это напоминает то, какие огромные средства и усилия тратятся на поиск лекарства от СПИД, в то время как уберечься от него можно правильным образом жизни плюс копеечным кусочком латекса. Возможно, со временем эта мысль проникнет и в эмбеддинг, ведь медицина развивалась тысячелетиями, а микропроцессору не исполнилось и полувека...

Как и предыдущие лекции, рекомендую новичкам в RTOS, но с критическим осмыслением факта, что большинство проблем эмбеддинга рукотворны, причем руки эти чаще всего приделаны к самим пострадавшим от их последствий.

URL: https://www.designnews.com/continuing-education-center/april-13-day-4-debugging-real-time-embedded-systems