Dale
|
|
« : 28-01-2011 07:19 » |
|
Не секрет, что при всем изобилии книг по программированию подавляющее большинство из них - просто хлам, не дающий читателю ни малейшего понятия о том, как на самом деле проектируются, реализуются и сопровождаются программы промышленного объема и промышленного уровня качества. Ситуация с литературой по программированию микропроцессоров и микроконтроллеров еще на порядок хуже - почти вся она сводится к передиранию описания системы команд МК из datasheet'а, после чего следует пара примитивных программ типа "помигать светодиодиком". Для самых начинающих, безусловно, это будет познавательно. Но что делать дальше, когда медитировать, глядя на мигающий светодиод, уже надоело? Увы, большинство книг на этом заканчивается.
Поэтому весьма ценным будет обмен столь дефицитной литературой по сабжу. Прочитали что-то стоящее - не сочтите за труд черкнуть несколько строчек в данной теме. Решили, что книга не стоит затраченного времени/денег - тоже напишите, чтобы другие не наступили на те же грабли.
Приводить здесь ссылки на скачивание сканов излишне - это не вполне законно, а взрослые люди сами знают, как их найти. В крайнем случае - вопросы в личку. Гораздо ценнее будет снабдить сообщение краткой аннотацией, которая позволит остальным определить лично для себя ценность данной книги.
|
|
« Последнее редактирование: 28-02-2011 13:41 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #1 : 28-01-2011 07:51 » |
|
Jack G. Ganssle. The art of designing embedded systems. Butterworth-Heinemann, 2000 ISBN 0-7506-9869-1 Перевод на русский не попадался. Имеется также второе издание, но я его пока не читал. Книга написана человеком, которому действительно есть что сказать по предмету: на его счету более сотни промышленных разработок встроенных систем для самых разных областей, включая космическую и медицинскую технику, охранные системы (в том числе для Белого дома), приборы для навигации и научных исследований и многое другое. Кроме того, Джек - автор более 600 статей по программированию встроенных систем, а также занимается просветительской и педагогической деятельностью. Подробнее ознакомиться с его деятельностью можно здесь: http://www.ganssle.com/Что касается самой книги: это не техническое описание конкретных моделей микропроцессоров, компиляторов, методик разработки и т.п. Скорее это критический взгляд на то, каким образом сегодня проектируются системы со встроенными микропроцессорами, выявление слабостей существующих стихийных традиций и реальные предложения по систематизации и рационализации процесса. Большое внимание уделяется проблеме качества продукта, причем на всех уровнях: от стратегии разработки надежной системы до типичных промахов при проектировании и изготовлении устройства и практических советов по использованию приборов (осциллографа, логического анализатора и пр.) при поиске дефектов. Отдельная глава посвящена организации работы в коллективе разработчиков. По глубине философского взгляда на предмет я бы поставил эту книгу в один ряд с "Искусством схемотехники" Хоровица и Хилла и "Совершенным кодом" МакКоннелла. Для начинающих может показаться тяжеловатой, но на пути от чайника к профессионалу будет большим подспорьем.
|
|
« Последнее редактирование: 28-02-2011 13:51 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #2 : 28-01-2011 13:12 » |
|
James W. Grenning. Test Driven Development for Embedded C. The Pragmatic Bookshelf, 2010. Эта книга еще официально не издана, но уже можно получить бета-версию из издательства. В данный момент самой свежей является 10-я бета-версия. Автор обещал выпустить книгу осенью 2010-го, но еще не закончил работу. Без всякого преувеличения книгу можно назвать уникальной. Шутка ли, автор учит объектному подходу к проектированию программ, которые впоследствии реализуются на языке C! В это невозможно поверить, пока сам не проследишь за каждым шагом фокуса и не убедишься, что все без обмана. Более того, автор еще и предлагает проектировать firmware при помощи технологии TDD (Test-Driven Design). В отношении языка C лично для меня это открытие, все прочитанные мною ранее учебники учат лишь синтаксису языка, обходя вниманием проектирование и реализацию программы. Ну и чтобы окончательно перевернуть процесс проектирования firmware с головы на ноги, как ему и положено быть, автор показывает, как можно использовать тестовых дублеров в программах на C, после чего оказывается, что бОльшую часть кода можно тестировать на рабочем ПК, даже не прибегая к помощи симулятора микроконтроллера, не говоря уже об испытаниях на прототипе. На мой взгляд, эта книга - лучшая из прочитанных мной до сих пор на тему проектирования firmware. Именно ее мне так не хватало для построения полной картины цикла проектирования встроенных систем от идеи до реализации. Рекомендую всем, кого интересует проблема качества встроенного ПО.
|
|
« Последнее редактирование: 28-02-2011 13:52 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #3 : 29-01-2011 05:16 » |
|
Mike Mason. Pragmatic Version Control using Subversion (2nd edition).The Pragmatic Programmers LLC, 2006. ISBN 0-9776166-5-7 Строго говоря, эта книга не является ориентированной именно на проектирование встроенных систем. Но, с другой стороны, такое проектирование нуждается в качественном управлении версиями ничуть не меньше, чем проектирование софта для "больших" компьютеров, а то и больше: ведь помимо программного кода во встроенном проекте присутствуют и другие артефакты (принципиальные схемы, фотошаблоны печатных плат, чертежи несущих конструкций, сборочные чертежи и многое другое), которые не менее интенсивно, чем код, меняются в ходе проекта. К тому же многие разработчики встроенных систем получали образование в области разработки/конструирования радиоэлектронной аппаратуры (или же вовсе получали его в те времена, когда о дисциплине управления версиями еще и не слышали) и не имеют понятия о предмете. Как и другие книги серии Pragmatic, эта написана профессионалами для профессионалов, а значит, чрезвычайно прагматична. Это значит, что содержание книги не сводится к справочнику по командам и опциям SVN. Вместо этого дается достаточно полная картина роли, которую играет VCS в общем и SVN в частности в общем процессе проектирования. Приведены практические рекомендации по рациональной организации структуры каталогов проекта, а также множество идиом и паттернов управления версиями. Рекомендую книгу как тем, кто только созрел до идеи управления версиями своих проектов и нуждается в практических рекомендациях, так и тем, кто уже освоил основные команды SVN, но еще не уловил самой сути этого инструмента и использует его как замену backup'а для файлов проекта, тем самым забивая микроскопом гвозди. P.S. Кроме этой книги, в серии Pragmatic имеются также выпуски, посвященные управлению версиями в CVS и Git. По их поводу ничего не могу сказать, поскольку не пользуюсь этими инструментами, но заинтересованным рекомендую обратить внимание. Думаю, не разочаруетесь.
|
svn2.jpg (26.71 Кб - загружено 19490 раз.)
|
« Последнее редактирование: 19-08-2011 06:46 от RXL »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #4 : 29-01-2011 15:14 » |
|
Бонни Бэйкер. Что нужно знать цифровому разработчику об аналоговой электронике. М.: "Додека-XXI", 2010. ISBN 978-5-94120-170-9 Собственно, в названии практически все сказано: это не очередной букварь для начинающих, в котором на полкниги мусолятся закон Ома и вольтамперная характеристика диода, а вполне солидное руководство для разработчиков цифровой техники, которые решили разобраться в смежной области. По стилю изложения я бы сравнил эту книгу со знаменитым "Искусством схемотехники" Хоровица и Хилла, которое уже стало эталоном: материал изложен достаточно строго, позволяя учитывать все нюансы происходящих в схеме процессов, и в то же время не перегружен заумными формулами, которые все равно невозможно использовать на практике из-за значительного разброса параметров серийных компонентов. Основное внимание уделено подробному анализу причин, по которым реальная схема отличается от идеальной, и способов приблизиться к желаемому идеалу достаточно близко. Не обойдена вниманием и тема шумов и помех, которая особенно актуальна при совместном использовании цифровых и аналоговых блоков в одном устройстве. Приведены ценные практические рекомендации, как сделать этих столь разных соседей терпимее друг к другу.
|
|
« Последнее редактирование: 28-02-2011 13:52 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #5 : 29-01-2011 19:40 » |
|
Joe Pardue. C Programming for Microcontrollers. Featuring ATMEL’s AVR Butterfly and the Free WinAVR Compiler. Smiley Micros. ISBN 0-9766822-0-6 Книга может представлять интерес для новичков, делающих первые шаги в освоении популярных 8-разрядных микроконтроллеров семейства AVR фирмы Atmel, а особенно для тех из новичков, кто обзавелся девайсом под названием Butterfly. В целом материал примерно так же незатейлив и уныл, как и сам девайс, и представляет некое подобие подборки примитивных лабораторных работ для нерадивых учеников (вроде обитателей раздела "Срочно пАмАгите!!!"), которые сводятся к загрузке готового кода в готовый девайс и созерцанию результата. Вся самостоятельная работа состоит в соединении нескольких проводков и деталек на плате для быстрого макетирования. Кроме того, дается немного теории, но совсем по верхам. Чтение данной книги специалистами - пустая трата времени.
|
|
« Последнее редактирование: 28-02-2011 13:52 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #6 : 17-02-2011 23:33 » |
|
Шевкопляс Б.В. Микропроцессорные структуры. Инженерные решения. 2-е изд. М.: "Радио и связь", 1990 ISBN 5-256-00460-3 Внешне совершенно невзрачная книга с довольно невнятным, малоинформативным названием. Но содержание при этом - выше всякой похвалы. Весьма приятный контраст с большинством сегодняшних технических книг, где картина диаметрально противоположна. Впервые открыв эту книгу, я ощутил смутное ощущение дежа-вю. Припомнилось, что за несколько лет до этого (разгул позднего социализма) мой научный руководитель был приглашен на закрытые курсы повышения квалификации под эгидой Министерства электронной промышленности, одного из наиболее могущественных в советские времена. Каким-то образом ему удалось вывезти оттуда контрабандой ксерокопию экземпляра преподавательских конспектов с грифом "для служебного пользования", хотя это, мягко говоря, настоятельно не поощрялось. Аксакалы еще должны помнить печально известное качество отечественного копировального оборудования. Копия была сделана на рулоне разграфленной для самописца бумаги (самое подходящее из того, что шефу удалось урвать на месте) и имела весьма неважное качество. Но это все второстепенные детали - вчитавшись, оторваться было уже невозможно. После того, как я присягнул на этом самом рулоне (Библия в те годы еще не вошла в моду), что не отдам его в чужие руки, буду беречь, как зеницу ока, и верну точно в указанный срок, я получил заветный свиток в свое распоряжение. Хотя сроки и поджимали, я успел проштудировать его несколько раз и довольно неплохо в нем ориентировался. Велико же было мое удивление, когда, раскрыв эту книгу, я увидел давно знакомые схемы. Имя автора курса я к тому времени запамятовал, но содержимое красноречиво говорило само за себя. Не думаю, что книгу можно рекомендовать всем без разбора. Тем, кто считает, что булки микросхемы растут на деревьях, она может показаться скучноватьй и даже архаичной. Ее аудитория - не те, кто спрашивает, к примеру, где взять микросхему кодека Manchester-II, а тем, кому интересно, как устроен и как работает кодек Manchester-II. Если попытаться найти для данной книги ближайшую аналогию, то я выбрал бы, безусловно, "Паттерны проектирования" "банды четырех". Это примерно такие же паттерны, но только в области аппаратных решений: столь же строгие, лаконичные и завершенные схемные решения, которым можно найти множество применений.
|
|
« Последнее редактирование: 28-02-2011 13:52 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #7 : 18-02-2011 09:14 » |
|
Евстифеев А.В. Микроконтроллеры AVR семейства Classic фирмы ATMEL. Микроконтроллеры AVR семейств Tiny и Mega фирмы ATMEL. Микроконтроллеры AVR семейства Tiny. Микроконтроллеры AVR семейства Mega. Изд. Додэка XXI Год издания и ISBN не указываю, поскольку книги периодически переиздаются. Это семейство книг представляет собой фактически компиляцию фирменной документации ATMEL по различным семействам 8-разрядных микроконтроллеров AVR. Излагаются общие по всему семейству данные, а также оговариваются особенности некоторых моделей, когда они существенны. В принципе могут оказаться полезным для ленивых, которых пугают объемы оригинальной документации, или для тех, кто испытывает трудности с техническим английским. Никакой уникальной информации, заслуживающей внимания, я в них не обнаружил. Книги в целом не хорошие и не плохие - придраться вроде не к чему, но и хвалить не за что. В целом всю серию я отнес бы к разряду книг, которых могло бы и не быть без особого ущерба для читателей.
|
|
« Последнее редактирование: 28-02-2011 13:53 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #8 : 28-02-2011 13:39 » |
|
Arnold S. Berger Embedded Systems Design: An Introduction to Processes, Tools, and Techniques CMP Books © 2002 ISBN: 1-57820-073-3 Полная противоположность книгам, упомянутым в предыдущем посте. Автор обладает буквально энциклопедическими знаниями по предмету. Он поработал в промышленности, занимаясь инструментальными средствами разработки. Он имеет большой педагогический опыт, полученный во время преподавания в университете Вашингтона, причем для самой широкой аудитории - от студентов младших курсов до инженеров со стажем, решивших повысить свою квалификацию в области разработки встроенных систем. Весь этот опыт самым благоприятным образом сказался на содержании книги. Книга дает представление о самых разных аспектах жизненного цикла встроенных систем от задания на разработку до сопровождения готовых изделий: - обоснованный выбор платформы для реализации проекта;
- решение о разделении функций между аппаратниыми и программными компонентами системы;
- выбор инструментальных средств поддержки разработки как аппаратной, так и программной части, а также их рациональное использование;
- использование внутрисхемной эмуляции;
- тестирование на всех этапах разработки.
Приведены многочисленные примеры различных проблемных ситуаций при разработке, с которыми довелось столкнуться автору, и способы решения этих проблем. Даны практические советы по эффективному использованию конкретных инструментов (осциллограф, логический анализатор, внутрисхемный эмулятор, встроенные в кристалл отладочные средства) для тестирования и отладки встроенных систем. Автор описывает неудачные проектные решения из реальных устойств, которые затрудняли (или даже делали практически невозможным)применение отладочных инструментов, и дает рекомендации, как избежать таких ошибок. Он акцентирует внимание на том, что возможность эффективной отладки может и должна закладываться при проектировании устройства, и дает рецепты, как достичь этой цели. Несмотря на то, что со времени выхода книги прошло почти 10 лет, она никоим образом не утратила актуальность, поскольку не содержит справочных данных по конкретной элементной базе, а ее философия не устареет еще долго. Единственный, на мой взгляд, недостаток книги заключается в том, что тема тестирования раскрыта несколько поверхностно, а рекомендации приведены самые общие. Впрочем, возможно, я просто придираюсь, учитывая мой повышенный интерес именно к этой области. Настоятельно рекомендую эту книгу как профессионалам, так и (особенно) стремящимся стать таковыми.
|
|
« Последнее редактирование: 28-02-2011 13:53 от Dale »
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #9 : 01-03-2011 13:46 » |
|
Майкл К. Физерс. Эффективная работа с унаследованным кодом. "Вильямс", 2009. ISBN 978-5-8459-1530-6 Строго говоря, эту книгу нельзя отнести к числу специализированных по тематике раздела, она может оказаться полезной любому практикующему программисту. С другой стороны, ПО встроенных систем - это такое же ПО, как и любое другое, только зачастую с более жесткими требованиями, налагаемыми условиями работы в реальном времени (надежность, производительность, компактность и т.д.). Поэтому оно подвержено тем же болезням, только подчас в еще более тяжелой форме. Каждый, кто пытается быть в курсе последних веяний в области программной инженерии, знает, что по-хорошему писать тесты следует до написания кода; что даже если этому правилу не всегда удается неукоснительно следовать, то по крайней мере нужно стремиться к максимальному покрытию кода тестами; что при каждом изменении кода, даже на первый взгляд незначительном, желательно запустить как можно более полный набор модульных тестов (регрессионное тестирование); что периодически нужно прислушиваться к "запахам" кода и при первых симптомах производить рефакторинг... Впрочем, эти прописные истины можно сравнить с призывом переходить дорогу по "зебре" на зеленый свет или бросать мусор только в урну: это знают практически все, но все ли выполняют? Причем даже те, кто следуют им не укоснительно, не застрахованы от ситуации, что в один далеко не прекрасный момент им вручат написанный другим умельцем довольно неряшливый исходник и попросят изменить или добавить какую-то функцию. Модульные тесты в проекте не предусмотрены (они ведь требуют лишних усилий и времени), документации нет по той же причине - в исходниках и так все написано. Вопреки здравому смыслу это чудо все же работает, но трогать его боязно, ибо за заплатками и подпорками не видно начального замысла. Если вы оказались в такой ситуации, примите мои "поздравления": вы по горло в... "унаследованном коде", именно таким нейтральным словом сегодня принято называть подобные продукты в приличном обществе. И эта книга может стать для вас спасательным кругом, ибо она учит выживать и даже добиваться успеха в подобных случаях. По стилю изложения книга напоминает знаменитый "Рефакторинг" Фаулера: автор классифицирует типичные проблемы ("запахи") плохого кода, обсуждает способы их решения и в заключение дает краткий рецепт, расписанный по шагам. Разумеется, учитывается специфика работы с унаследованным кодом: когда это возможно, "задним числом" дописываются необходимые тесты, которые помогают более уверенно вносить изменения в код. Там, где это затруднительно, предлагаются наименее рискованные методы рефакторинга без последующего регрессионного тестирования. К недостаткам книги я бы отнес излишнюю громоздкость и детальность примеров. Слишком часто приходится вникать в малоинтересные читателю детали чужих задач, пытаясь выделить суть на фоне этих помех. Пожалуй, придуманные рафинированные примеры были бы легче для понимания, чем фрагменты реального кода. Несмотря на это, книга в целом заслуживает самой высокой оценки.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #10 : 30-03-2011 09:10 » |
|
Роберт Гласс. Факты и заблуждения профессионального программирования. "Символ", 2008. ISBN 13: 978-5-93286-092-2 ISBN 10: 5-93286-092-8 55 фактов и 10 распространенных заблуждений, касающиеся всех стадий жизненного процесса ПО - от сбора требований до сопровождения и прекращения эксплуатации. По насыщенности фактами из реальной жизни данную книгу можно сравнить разве что с "Мифическим человеко-месяцем" Брукса, а по объективности и беспощадности критики - с работами Дейкстры ("Как быть, если правда колет глаза" и пр.). Автор перечисляет наиболее злободневные с его точки зрения проблемы программной инженерии, но при этом не предлагает готовых решений (которые, впрочем, не во всех случаях известны). Автор в процессе критики не испытывает ни малейшего трепета перед признанными авторитетами и брэндами (впрочем, он и сам - немалый авторитет и брэнд в одном лице). Громкие имена и складные рекламные слоганы не имеют значения, если предлагаемые ими пути никуда не ведут. Если внешне складная теория не согласуется с фактами - тем хуже для теории. Книга обязательна к прочтению всеми, кто играет (или надеется играть в обозримом будущем) значительную роль в коллективе разработчиков ПО как менеджер или ведущий специалист.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #11 : 06-04-2011 12:39 » |
|
Роберт Мартин. Чистый код: создание, анализ и рефакторинг. СПб.: Питер, 2010. ISBN 978-5-49807-381-1 Что следует понимать под "чистым кодом"? Разумеется, код, свободный от разного рода загрязнений. Разновидностей загрязнений очень много, и большинство из них можно распознать и вычистить по методикам, которые приводятся в книге. Эти рекомендации вовсе не носят абстрактный характер, совсем наоборот: автор берет фрагменты известных проектов с открытым кодом и показывает, сколько грязи порой кроется даже в популярных приложениях, созданных признанными мастерами, и какой чистоты кода можно добиться, приложив некоторые усилия для этого. Что делать, чтобы добиться чистоты кода? У скаутов есть правило, которое они обязаны безукоризненно соблюдать: "Оставь место стоянки чище, чем оно было до твоего прихода". Хороший программист должен придерживаться этого правила в отношении кода, над которым он работает, постоянно находя шероховатости в нем и полируя его до блеска. Довод "зато работает", часто приводимый в защиту небрежно слепленного приложения, нельзя считать убедительным. Даже если кажется, что оно работает сию секунду, вполне вероятно, что завтра ситуация ухудшится: либо обнаружится ошибка, которую нужно срочно исправить, либо изменятся бизнес-требования, и эти изменения должны воплотиться в изменениях кода. А исправления и изменения куда приятнее и продуктивнее вносить в чистый код. Некоторые главы написаны приглашенными авторами, некоторые из которых (Майкл Физерс, Джеймс Гренинг) уже знакомы нам по предыдущим обзорам. Поэтому материал порой повторяется, возникает ощущение дежа-вю. Впрочем, дельная мысль от повторения не теряет ценности. Безусловно, книга обязательна для прочтения профессионалами. Я бы рекомендовал читать ее после "Совершенного кода" МакКоннелла, поскольку многие темы перекрываются, но в данной книге они раскрыты глубже.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #12 : 11-04-2011 13:48 » |
|
Джон Влиссидес. Применение шаблонов проектирования. Дополнительные штрихи. М.: Издательский дом "Вильямс", 2003. ISBN 5-8459-0393-9 Полагаю, трудно найти программиста, который если и не проштудировал с карандашом, то хотя бы не полистал известное творение "банды четырех" под названием "Паттерны проектирования". Это золотой фонд литературы по программированию. К сожалению, довольно трудно научиться использовать паттерны, ограничившись чтением лишь этой книги. Примерно так же трудно, как получить общее образование, читая "Большую Советскую Энциклопедию"; или научиться объектно-ориентированному программированию, используя руководство Страуструпа по C++. Все-таки справочник имеет другое назначение. Книга Влиссидеса гораздо больше подходит на роль учебника по использованию паттернов проектирования на практике. Фактически это мастер-класс, который наглядно показывает, как выбирать и как использовать уже знакомые нам по книге GoF паттерны для решения прикладных задач. Особая ценность книги, на мой взгляд, состоит в том, что паттерны представлены не поодиночке, как в справочнике, а во взаимодействии, как это обычно бывает на практике. Представлены также несколько паттернов, по разным причинам не вошедших в справочник GoF. Во время издания справочника они либо были сыроваты, либо авторы посчитали их недостаточно общими. Впрочем, паттерны лишними не бывают, и не исключено, что какой-то из них придется ко двору в проектах читателей. Завершают книгу "семь правил успеха" разработчика паттернов. Возможно, не каждому судьбой предначертано создать собственный паттерн, но почитать их в любом случае интересно, ведь в них сконцентрирован опыт "банды". Рекомендую всем, кто оценил значимость паттернов, но не слишком уверенно чувствует себя при их применении.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #13 : 12-04-2011 09:46 » |
|
Белов А.В. Самоучитель разработчика устройств на микроконтроллерах AVR. СПб.:Наука и техника, 2008. ISBN 978-5-94387-363-8 Давненько в нашем обзоре не было книг для начинающих. Исправляю это упущение. Книга относится к самому начальному уровню, но при этом написана довольно добротно. В отличие от комплекта книг, описанного в посте 7, это не перевод материалов, передранных с сайта разработчика, а действительно учебник, по которому можно чему-то научиться. Причем учебник вполне самодостаточный: начинается он с описания двоичной системы счисления и элементарной логики, затем даются основы цифровой электроники, и лишь затем автор приступает к основному материалу. Начинающие могут читать его подряд, не прибегая к другим источникам информации. К особенным достоинствам учебника я бы отнес то, что автор дает примеры решения одной и той же задачи дважды - на ассемблере и языке C. Это дает читателю возможность самому составить собственное мнение о достоинствах и недостатках каждого из подходов, а не полагаться на мнения многочисленных самопровозглашенных гуру, которыми переполнены форумы соответствующей тематики. Итак, если у вас чешутся руки научиться работать с микроконтроллерами, но вы никак не решитесь сделать первый шаг, не зная, с чего начать, рекомендую раскрыть эту книгу. Безусловно, перевернув последнюю страницу, вы не станете экспертом в данной теме, но толчок для движения в нужном направлении вы определенно получите. Ну а в дальнейшем самосовершенствовании помогут другие хорошие книги, которые уже есть (и еще будут) в данном разделе.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #14 : 12-05-2011 07:46 » |
|
Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. "Вильямс", 2002. ISBN 5-8459-0275-4 Очевидно, что успех ожидает программу в том случае, если она выполняет то, что хочет от нее пользователь (впрочем, эта банальная истина простирается далеко за пределы области разработки ПО). Из этого непосредственно следует, что перед разработкой нового продукта следует как можно тщательнее разобраться с пожеланиями его будущих потребителей. Именно поэтому работа с пользовательскими требованиями является одной из важнейших частей процесса разработки. Точнее, по логике должна являться. Но так ли это в реальности? Многие ли разработчики способны побороть искушение поскорее начать писать код, не успев толком дослушать пожелания заказчика? И многие ли из тех, кто в принципе осознали важность работы с требованиями, представляют себе, как это реально делается? Мой личный опыт общения с разработчиками, как непосредственный, так и при помощи различных форумов и других средств коммуникации, вынуждает дать ответ "нет" на оба эти вопроса. О работе с требованиями выпущено уже немало книг. К сожалению, слишком многие из них практически бесполезны. В них муссируются очевидные и интуитивно понятные истины: как среди будущих пользователей будущего продукта выбрать наиболее подходящих для совместной конструктивной работы, как лучше взаимодействовать с ними, как постараться "вытащить" из них важные детали, о которых они умалчивают, и так далее. Но ценность любой работы определяется ее конечным результатом. Если в итоге мы получаем многословное пространное собрание требований к системе с точки зрения различных пользователей, ценность такого документа невелика: работа с ним отнимет у разработчика много времени даже при условии, что требования стабильны; если же они еще и изменчивы, как это обычно бывает, ценность документа стремится к нулю: даже если аналитики успевают вовремя его модифицировать, разработчики вряд ли смогут постоянно его перечитывать в попытках найти изменения. Часть проблем решается путем формализации. Например, стандарт IEEE STD 830 предлагает несколько вариантов оформления спецификации требований к ПО, что позволяет автору спецификации сосредоточиться на содержании документа, не тратя время на изобретение его формата, а читателям, привыкшим к такой структуре, легко ориентироваться в документе. Однако мало знать, что должно получиться в итоге; желательно знать также, каким образом это можно получить. В этом отношении полезность данной книги трудно переоценить. Авторы используют современный подход к документированию требований, основанный на нотации UML. Эта нотация достаточно компактна и в то же время выразительна, работать с ней значительно проще, чем с обычными словесными описаниями. Предложенный авторами пакет Modern SRS весьма удачно дополняет IEEE STD 830. В его основе лежит модель прецедентов, соответствующих основным функциональным требованиям, дополненная вспомогательными диаграммами, уточняющими детали. Большое внимание уделено проблеме трассировки требований. Авторы демонстрируют сначала трудности трассировки вручную, которые делают этот процесс чрезвычайно трудоемким, а затем способы автоматизации посредством наиболее популярных инструментов от Borland и Rational. Рекомендую книгу всем, кто стремится организовать процесс разработки качественного ПО, в особенности тем, в чьих интересах построить работу в соответствии со стандартами семейства ISO 9000 и даже CMM.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #15 : 17-05-2011 09:37 » |
|
James W. Grenning. Test Driven Development for Embedded C. The Pragmatic Bookshelf, 2010. Эта книга еще официально не издана, но уже можно получить бета-версию из издательства. В данный момент самой свежей является 10-я бета-версия. Автор обещал выпустить книгу осенью 2010-го, но еще не закончил работу. В апреле 2011 года эта замечательная книга наконец-то увидела свет. Выпущена финальная электронная версия, отправлена в печать бумажная. Новые выходные данные: ISBN-10: 1-934356-62-X, ISBN-13: 978-1-934356-62-3
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #16 : 30-05-2011 14:46 » |
|
Эрик Эванс. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем. М.: ООО "И.Д. Вильямс", 2011. ISBN 978-5-8459-1597-9 (рус.) Несмотря на то, что аббревиатура DDD (Domain-Driven Design, предметно-ориентированное программирование) уже не первый год знакома тем, кто внимательно следит за развитием технологий программирования, эта парадигма до сих пор не получила такого распространения, которого она по праву заслуживает. (Впрочем, консервативность и неспешность в мире software, особенно заметные на фоне стремительного прогресса hardware, - предмет отдельного разговора). Поэтому каждая книга на данную тему представляет ценность, особенно такая добротная, как эта. DDD стала неотъемлемой частью "гибких" (Agile) технологий программирования, и по степени влияния на разработку я могу сравнить ее разве что с TDD. Основной акцент в DDD делается на моделирование предметной области с последующей эволюцией этой модели в архитектуру приложения. В качестве основного инструмента для такого моделирования рассматривается UML, которому в данный момент просто нет альтернатив по выразительности, а в качестве средства воплощения модели в код - парадигма ООП. Впрочем, автор не зацикливается исключительно на этих средствах и наглядно демонстрирует, как они могут комбинироваться с другими, например, диаграммами потоков данных, процедурным и функциональным программированием и т.д. Эванс рассматривает вроде бы давно знакомые проблемы, но как бы с высоты птичьего полета, отчего мелкие детали становятся неразличимы, зато вся картина в целом проясняется на более высоком уровне. Если речь заходит о паттернах, то это не те, давно знакомые паттерны GoF и им подобные, а более масштабные; если обсуждается рефакторинг, то не тот, о котором писал Фаулер, а затрагивающий модель в целом. И так во всем, ведь область применения DDD - это в первую очередь стратегия. Следует отметить, что не весь материал книги представляет непосредственный интерес для разработчиков встроенных систем. Некоторые аспекты относятся исключительно к проектированию архитектуры "многослойных" приложений корпоративного уровня. А впрочем, как знать, ведь стремительный прогресс микроэлектроники ведет к тому, что возможности сегодняшних микроконтроллеров превосходят характеристики персональных компьютеров, а то и серверов недавнего прошлого, и не удивлюсь, если в ближайшее время появятся "многослойные" архитектуры firmware... Ну и в заключение пара цитат признанных авторитетов по поводу данной книги: "Если вам кажется, что ваша ставка на объектно-ориентированное программирование не окупает себя, то из этой книги вы узнаете, чего же вам не хватает." — Уорд Каннингем "Эта книга должна стоять на полке у каждого мыслящего программиста". — Кент Бек P.S. Если кто-то из неимеющих эту книгу на своей полке почувствует себя уязвленным последней цитатой, убедительнейшая просьба писать лично Беку и не засорять данную тему.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #17 : 24-06-2011 06:59 » |
|
Mark VanderVoord. Embedded Testing with Unity and CMock. This Book is Released Under Creative Commons Attribution-Noncommerical-Share Alike 3.0. Эта замечательная книга невелика по объему (всего 44 страницы, часть которых к тому же занята забавными иллюстрациями), зато по объему втиснутых в нее знаний превосходит многие увеститые тома, упомянутые в моих обзорах. Как видно из названия, предмет данной книги - использование двух не слишком известных, но крайне необходимых разработчикам систем со встроенными микропроцессорами инструментов: Unity и CMock. Unity - это очень компактная и простая в использовании среда модульного тестирования, реализованная на стандартном ANSI C и как следствие обладающая замечательной портабельностью. Эти свойства делают Unity воистину универсальным инструментом: ее можно использовать на компьютере разработки (например, в среде GCC или MS Visual Studio), выполнять тесты на симуляторе (я успешно делал это в средах VMLAB и Proteus для микроконтроллеров Atmel AVR семейства Mega) или даже на целевом микроконтроллере на отладочной плате или самом устройстве, если они обладают возможностью вывода текстовой информации. Пожалуй, это лучшая среда модульного тестирования на C из тех, которые мне доводилось пробовать. CMock - это также компактный и довольно простой фреймворк для автоматизированного построения мок-объектов, необходимых для полноценного модульного тестирования программ на С. Как и в случае Unity, простота и компактность достигнуты отнюдь не в ущерб функциональности. К сожалению, мне не с чем сравнивать CMock, поскольку это единственный продукт подобного рода из тех, с которыми мне доводилось иметь дело, но он меня ни разу не разочаровал. Книга написана весьма оригинальным стилем - в виде шуточной истории про некоего очередного злодея, решившего поработить Вселенную при помощи своего супермегадевайса. Разумеется, на его пути стоят супергерои-спасители, поэтому злодей вынужден проектировать свой гаджет максимально надежным, работоспособным в любых условиях. До него быстро доходит, что эта цель недостижима без тщательного тестирования, поэтому он шаг за шагом постигает премудрости Unity и CMock и тут же использует их на практике. Но занимательно - не значит непременно несерьезно (точно так же, как излишняя строгость изложения - не обязательно признак глубины мысли). Тщательно проштудировав фрагменты приведенного в книге кода, можно многое понять и многому научиться. Автор книги является также одним из соавторов описываемых им инструментов (которые, кстати говоря, доступны бесплатно и с открытым кодом). Он также весьма открытый и приятный в общении человек (к сожалению, у меня не было возможности для личного общения, только по переписке). Он является сотрудником уже известной нам (точнее, тем из нас, кто читал мои переводы статей по разработке firmware) фирмы Atomic Objects. В своем рейтинге ставлю данную книгу на самую вершину.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #18 : 28-06-2011 13:10 » |
|
Питер Гудлиф. Ремесло программиста. Практика написания хорошего кода. СПб.: Символ-Плюс, 2009. Вполне добротная книга, посвященная практически всем аспектам программной инженерии. Особо приятно отметить факт, что автор уделяет некоторое внимание специфическим аспектам, связанным с разработкой встроенного ПО. Разумеется, проходится он по этим темам поверхностно и кратко, но все же не игнорирует эту сторону программной инженерии вовсе, как это делает большинство авторов. Сам факт, что заговор молчания вокруг этой довольно темной и скользкой темы понемногу начинает отступать, не может не радовать. (Хотя, конечно, справедливости ради следует отметить, что паритет тут соблюдается довольно щепетильно, и большинство разработчиков встроенных систем точно так же игнорируют теорию программирования, тщетно полагая, что сами до всего додумаются). Автор не только дает информацию, но и заставляет читателя думать. В конце каждой главы приводится ряд вопросов, над которыми стоит призадуматься и сделать для себя выводы. Конечно, объем книги (около 700 стр.) крайне недостаточен: чтобы более-менее полно раскрыть тему, таких книг потребовалось бы не менее десятка. И все же для начинающих изучать программную инженерию всерьез она вполне годится в качестве отправной точки. Рекомендую всем разработчикам, в особенности тем, кто худо-бедно освоил по учебнику свой первый язык программирования, выполнил все упражнения в 5 строк и находится на перепутьи, не зная, куда двигаться дальше.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #19 : 12-08-2011 07:12 » |
|
Daniel J. Pack, Steven F. Barrett. Microcontrollers Fundamentals for Engineers and Scientists.Morgan&Claypool Publishers, 2006. ISBN 1598290584. Купился на название и предисловие, из которых следует, что целевая аудитория книги - практикующие инженеры и ученые, которые не имели ранее опыта работы с микроконтроллерами, но хотели бы его приобрести. Невольно вспомнилась величайшая (без всякого преувеличения) книга Хоровица и Хилла, также адресованная инженерам и ученым, стремящимся расширить рамки своей компетентности. Но Пак и Баррет не смогли даже близко подобраться к высокой планке стандарта де-факто, заданной "Искусством схемотехники". Если уж речь действительно идет об инженерах и ученых, то разве что о бесконечно далеких от предмета, например, инженерах-строителях или "ученых"-философах. На самом деле книга куда больше подошла бы для учащихся техникумов, студентов младших курсов ВУЗов и даже смышленых старшеклассников, собирающихся сделать электронику своей будущей профессией. Откровенно говоря, книга написана доступным языком и излагает материал понятно и последовательно, поэтому, если убрать с ее обложки претенциозную адресацию инженерам и ученым и поставить гораздо более уместную метку "Для чайников", она заняла бы вполне достойное место на книжных полках. Для инженера ее чтение - попросту потерянное время, ничего интересного вы там не найдете.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #20 : 15-08-2011 12:13 » |
|
Steven F. Barrett, Daniel J. Pack Atmel AVR Microcontroller Primer: Programming and Interfacing.Copyright © by Morgan & Claypool, 2008. ISBN: 1598295411 Эти авторы (хоть и в другом порядке) уже попадали в мой обзор с другой книгой. В этот раз, прямо скажем, они тоже не слишком порадовали. Данная книга представляет собой 15-й том серии "SYNTHESIS LECTURES ON DIGITAL CIRCUITS AND SYSTEMS". Из названия видно, что в этот раз авторы не растеклись мыслью о некоем абстрактном "микроконтроллере вообще", а выбрали предметом рассмотрения вполне конкретную модель - Atmel ATmega 16. Что ж, девайс вполне достойный, чего, к сожалению, не могу сказать о данном опусе. При чтении просто напрашивалась аналогия с подобными творениями нашего соотечественника Евстифеева: все, что достойно прочтения, целиком стянуто из документации изготовителя, все же, что добавлено сверх того, сплошь примитивно и уныло. Правда, к чести Евстифеева следует заметить, что ему хотя бы пришлось потрудиться над переводами даташитов на русский язык, нашему дуэту даже на это напрягаться не пришлось. К сожалению, спекулятивный спрос на книги по микроконтроллерам зачастую рождает именно такое предложение; дело Дарьи Донцовой начинает процветать и в сфере технической литературы...
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #21 : 25-08-2011 10:36 » |
|
Michael Barr, Anthony Massa. Programming Embedded Systems With C and GNU Development Tools.O'Reilly, 2006. ISBN: 0-596-00983-6 Очень качественное и добротное пособие для начинающих разработчиков. Приведенные в книге многочисленные примеры базируются на одноплатном компьютере Arcom VIPER-Lite (XScale ARM), но авторы буквально с первых страниц учат правильному подходу к разработке систем, поэтому примеры могут быть легко портированы на любую имеющуюся у читателя платформу (например, AVR или PIC). Весь материал в книге очень удачно сбалансирован. При написании подобных книг авторы зачастую сваливаются в одну из крайностей: либо рассматривают абстрактный "сферический контроллер в вакууме", либо закапываются в детали устройства конкретной модели, копируя целые главы из технических описаний от производителя. В данном случае этого нет, авторы удачно балансируют на грани между чрезмерной общностью и излишней детальностью изложения. Изложение традиционно начинается с самых элементарных задач, вроде мигания светодиодом и опроса кнопки с подавлением дребезга контактов. Однако далее рассматриваются более серьезные темы: коммуникации, многопоточность, синхронизация процессов, работа в сетях и т.п. Приведен обзор операционных систем реального времени, более детально рассмотрены eCos и Embedded Linux. Отдельная глава посвящена оптимизации встроенного ПО по различным критериям. Описаны возможности автоматической оптимизации кода компилятором GCC, методы ручной оптимизации и компромиссы, на которые при этом приходится идти. Пожалуй, единственным недостатком данной книги является пробел по части тестирования встроенных систем, а также общей организации процесса проектирования.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #22 : 31-08-2011 07:48 » |
|
Jean J. Labrosse. Embedded Systems Building Blocks, Second Edition. Complete and Ready-to-Use Modules in C.Miller Freeman, 2000. ISBN: 0-87930-604-1 Эта книга удивительно долго ускользала от моего внимания. Я был абсолютно уверен, что кто-то просто обязан был ее написать, ведь тема буквально лежит на поверхности. Тем не менее среди массы прочитанных книг ничего подобного не находилось, что вынуждало продолжать изобретать многочисленные велосипеды. И вот наконец-то удача: долгожданная книга нашлась. Книга фактически представляет собой сборник-энциклопедию готовых решений типовых задач проектирования, как аппаратных, так и программных. В ней можно найти готовые схемы и код для работы со светодиодными индикаторами и табло на ЖК на базе HD44780, опроса клавиатуры и подавления дребезга контактов, работы с UART и таймерами, аналоговым и цифровым вводом/выводом и т.д. Многие задачи решены дважды: как в среде ОС реального времени uC/OS-II, так и на "голом железе" микроконтроллера. Для каждого решения полностью опубликованы исходные коды на языке C. Разумеется, не обошлось и без небольшой ложки дегтя. Все примеры в книге ориентированы на микропроцессор Intel 80188, который даже в год издания книги уже можно было считать экзотикой и анахронизмом, не говоря о сегодняшнем дне. Однако код написан весьма грамотно, аппаратно-зависимые части программы четко отделены от бизнес-логики, поэтому достаточно легко адаптировать модули под свою предпочтительную платформу. Книга будет полезна всем категориям читателей. Новички, не имеющие опыта, смогут начать его накапливать, изучая готовые добротные решения типовых задач, опытные же разработчики, утомленные регулярными изобретениями велосипедов, смогут направить силы и время на решение действительно сложных задач.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #23 : 21-09-2011 13:32 » |
|
John Catsoulis Designing Embedded Hardware O'Reilly, May 2005 ISBN: 0-596-00755-8 Книга содержит практически все необходимое для начального ознакомления с миром встроенных микропроцессоров. В ней рассмотрены наиболее популярные семейства выпускаемых в настоящее время микроконтроллеров, а также основные интерфейсы, датчики, преобразователи АЦП и ЦАП, микросхемы памяти, управления питанием и многие другие полезные мелочи, без которых не обойтись при построении действительно полезной системы. Не обойдены вниманием и вопросы программирования, хотя и в небольшом объеме. Особенно любопытен небольшой обзор языка Forth, который изначально предназначался для программирования систем реального времени, но оказался забыт раньше, чем микроконтроллеры стали реально доступны. Во всей книге автору удалось соблюсти тонкий баланс: он не углубляется в чрезмерно мелкие детали, оставляя это читателю при необходимости, но и не злоупотребляет поверхностностью изложения, когда книга становится попросту набором общих фраз. Материала в книге в самый раз для того, чтобы дать разработчику начальный толчок и задать направление движения. Дальше можно уже непосредственно переходить к справочным материалам от производителей устройств. Книга оставила очень хорошее впечатление, настоятельно рекомендую.
|
DEH.jpg (33.3 Кб - загружено 17690 раз.)
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #24 : 22-09-2011 09:29 » |
|
Джерард Месарош. Шаблоны тестирования xUnit. Рефакторинг кода тестов.Вильямс, 2009. ISBN 978-5-8459-1448-4, 978-0-13-149505-0 Если вы достаточно ленивы (а только достаточно ленивый человек может добиться успехов в программировании), вы, как и я, приступая к изучению нового предмета, наверняка не раз мечтали о единственной книге, после прочтения которой можно превратиться из новичка в мастера. К сожалению, в подавляющем большинстве случаев этим мечтам не суждено сбыться, и мы вынуждены пропускать через голову десятки и сотни источников, собирая информацию по крупицам. Процесс этот долог и нелегок. А теперь хорошая новость: по крайней мере, в области тестирования такая книга действительно есть. Книга "Шаблоны тестирования xUnit. Рефакторинг кода тестов" вобрала в себя все необходимое для овладения хитрой наукой тестирования. Эту книгу смело можно было бы назвать энциклопедией тестирования; однако, в отличие от энциклопедии, ее можно читать последовательно от начала до конца. Автор рассматривает каждый аспект тестирования буквально со всех сторон. В результате мы не только постигаем теорию тестирования и знакомимся с его технологиями, но и получаем представление о внутреннем устройстве инструментов тестирования. Глубина изложения материала дает возможность не только освоить имеющиеся инструменты, но и при необходимости самостоятельно разработать новые, благо объем книги позволяет (более 800 стр.). Следует обратить особое внимание на разделы, посвященные "тестовым двойникам". При разработке "сверху вниз" по методике TDD мы часто попадаем в ловушку: с одной стороны, каждый модуль должен быть тщательно протестирован, и мы не имеем право писать код, для которого не созданы тесты, причем тесты должны сначала выдавать ошибки. С другой стороны, в ходе выполнения операций наш модуль должен обращаться к услугам нижележащих модулей, которых в данный момент нет и не может быть, ведь их черед еще не наступил. Зачастую из этой ловушки пытаются выкарабкаться, соглашаясь на компромисс: программа проектируется "сверху вниз", а реализуется "снизу вверх". Такой подход, конечно же, имеет право на жизнь, но обладает рядом существенных недостатков. Есть другой, более рациональный подход: вместо пока не реализованных модулей наш тестируемый модуль обращается к их "заместителям" (дублерам), созданным специально для целей тестирования. Дублеры являются частью технологической оснастки процесса разработки и обычно не входят в конечный продукт, поэтому они делаются как можно проще (но не проще, чем это можно себе позволить!); с другой стороны, часто дублеры обладают дополнительными свойствами (которых нет у "настоящих" модулей, которые подменяют дублеры), которые позволяют провести более полное и тщательное тестирование, чем оригинальные модули. Дублеры и их использование в процессе тестирования подробно рассмотрены в книге, классифицированы и снабжены ценными практичными рекомендациями. Не обойдена вниманием также важнейшая тема рефакторинга тестов. Автор приводит огромное количество "запахов" вместе с рекомендациями по их устранению. Рекомендовать книгу не буду, поскольку за меня это уже сделал Мартин Фаулер; на обложке книги красуется его подпись с печатью-рекомендацией. А этот товарищ, как известно, плохому не научит.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #25 : 05-10-2011 19:58 » |
|
Мартин Фаулер. Рефакторинг. Улучшение существующего кода.Символ-Плюс, 2008. ISBN 5-93286-045-6, 978-5-93286-045-8, 0-201-48567-2 Сначала я не планировал включать подобные книги в свой обзор, ведь задача обзора - помочь ситателю сориентироваться, какие книги стоит прочитать, а без каких можно обойтись. Относительно таких книг гамлетовский вопрос "читать или не читать" попросту не возникает - их читать просто необходимо. Не найдете же вы отзывов критиков о букваре, - практически каждый человек, умеющий читать, в свое время прошел через него. Так что эта заметка включена лишь для того, чтобы на нее можно было ссылаться в перечне литературы в статьях. Если вы уже знакомы с этой книгой (что наиболее вероятно), вам вряд ли будет интересна рецензия на нее. Если по какой-то причине нет, вам однозначно следует отложить все дела и немедленно углубиться в чтение. Это одна из небольшого количества книг (к их числу еще можно отнести "Паттерны проектирования" банды четырех, "Жемчужины программирования" Бентли, "Конкретная математика" Кнута и т.п.), без прочтения которых попросту противопоказано заниматься серьезным программированием.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #26 : 28-10-2011 12:43 » |
|
Роберт Мартин, Мика Мартин. Принципы, паттерны и методики гибкой разработки на языке C#.Символ-Плюс, 2011. ISBN 978-5-93286-197-4 Какое отношение имеет книга, посвященная технике программирования на C#, к данному разделу? Самое прямое. Паттерны проектирования - это понятие гораздо более высокого уровня, чем конкретный язык программирования. То, что в качестве иллюстраций выбран именно C#, лишь облегчает понимание материала, поскольку этот язык выразительнее, чем C++, и привычнее для большинства, чем, скажем,Smalltalk. Во всяком случае, читается книга ничуть не хуже, чем тот же "Рефакторинг" Фаулера, проиллюстрированный примерами на Java. Большинство приведенных в книге паттеров уже знакомы читателям по книге "банды четырех". Но все же эти книги не дублируют друг друга. В книге "бандитов" каждый паттерн тщательно препарирован, засушен и пришпилен булавкой к странице, словно жук в коллекции; читателю остается изучать их в статике, восхищаясь их изяществом, а также мастерством их создателей. У Мартина все иначе. Паттерн возникает естественным путем в результате попытки улучшить код при решении конкретной задачи; мы видим его в динамике и как бы становимся соавторами его создания. Когда работа завершена остается ощущение, что иначе и быть-то не могло. Приведено также несколько паттернов, не описанных в книге "бандитов". Еще одним достоинством книги является то, что весь приведенный в ней код разработан исключительно по методике TDD. Для каждого, даже тривиального, метода непременно имеется заранее подготовленный модульный тест. Для улучшения покрытия кода тестами Мартин регулярно применяет тестовые двойники, которые все без разбора почему-то именует "моками" (мы уже знаем, как они зовутся на самом деле). Большое внимание автор уделил рассмотрению основных принципов объектно-ориентированного проектирования и их влияния на "запахи" кода. Основная цель книги - научить читателя создавать программы с хорошей архитектурой, но без излишеств: архитектура перестраивается по мере развития проекта. Рекомендую книгу к прочтению всеми программистами, независимо от ипользуемых языков и платформ: она окажется в равной степени полезной как разработчику настольных приложений, так и проектировщику встроенных систем.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #27 : 29-10-2011 22:20 » |
|
Andy Lindsay. What’s a Microcontroller? Student Guide.Parallax, 2003 ISBN 1-928982-02-6 Рекомендую эту книгу преподавателям, которые вынуждены изобретать велосипеды, организуя лабораторные работы по изучению микроконтроллеров. Здесь вы найдете достаточно связный цикл готовых лабораторных работ, построенных по принципу от простого к сложному. Изготовить для них стенды не составит труда даже в домашних условиях, лазерно-утюжным методом. Однако имейте в виду, что базовым в данном курсе является микроконтроллер PIC16C57, и тем, кто не является фанатом этой архитектуры, придется поискать другой курс. Книга может оказаться полезной также для студентов, которые на занятиях вынуждены изучать окаменелости вроде семейства 580 (такое до сих пор действительно случается, причем гораздо чаще, чем можно было бы ожидать) и хотели бы самостоятельно изучить более современную элементную базу.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #28 : 01-11-2011 22:21 » |
|
Jack Ganssle, Michael Barr. Embedded Systems Dictionary.CMP Books, 2003. ISBN 1-57820-120-9 Книга задумана как энциклопедический словарь по встроенным системам, но на самом деле, несмотря на скромный объем, охватывает гораздо более широкий круг смежных тем. В ней можно найти статьи по математике, электротехнике и электронике, операционным системам и многим другим областям знаний, которые могут быть полезны разработчику встроенных систем.
Оба авторитетных автора не нуждаются в представлении, их книги уже упоминались в моем обзоре, а инженеры, следящие за профессиональной компьютерной периодикой, наверняка неоднократно читали их статьи.
Хотя с момента выхода книги прошло уже 8 лет, ее рано относить к устаревшим. По непонятным мне причинам промышленная компьютерная инженерия весьма консервативна (хотя по логике должна быть одной из передовых областей техники), и по моим самым скромным оценкам отстает от теории лет на 10, если не больше. Так что на данный момент книга вполне актуальна и пригодна к использованию.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
Dale
|
|
« Ответ #29 : 03-11-2011 10:37 » |
|
Bruce Powel Douglass. Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems.Addison Wesley, 2002. ISBN 0-201-69956-7 Комментировать в общем особенно нечего, все сказано в названии. В книге собраны паттерны, относящиеся к системам реального времени. Некоторые из них довольно тривиальны, но попадаются и весьма изощренные. В целом по прочтении у меня создалось впечатление, что материала книги вполне должно хватить для разработки собственной операционной системы реального времени. Рекомендую профессионалам в области разработки встроенных систем.
|
|
|
Записан
|
Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.
Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard
Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
|
|
|
|