Промышленное программирование *

Эта статья заканчивает цикл публикаций о разработке измерительного устройства в онлайн IDE mbed от компании ARM.

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

Предыдущие статьи:

• [Часть 1] Обзор использованных программных и аппаратных решений.
• [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
• [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
• [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
• [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.

Сегодня мы публикуем ещё один из докладов, прозвучавших на летней встрече об устройстве поиска Яндекса. Выступление руководителя отдела ранжирования Петра Попова получилось в тот день самым доступным для широкой аудитории: минимум формул, максимум общих понятий о поиске. Но интересно было всем, потому что Пётр несколько раз переходил к деталям и в итоге рассказал много такого, о чём Яндекс никогда раньше публично не заявлял.

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


Ну а под катом — лекция Петра Попова и часть слайдов.

Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда.

Данная статья продолжает серию публикаций на тему функциональной безопасности.

В данной статье достаточно абстрактные требования к управлению функциональной безопасностью интерпретированы для внедрения в рабочие процессы. Эта информация проверена и отшлифована на практике нескольких проектов по сертификации.
Процессная инженерия – скучно это или нет? Именно процессы позволяют масштабировать IT-бизнес. Мне лично приходилось наблюдать, как внедрение процессов в разработку приводило к серьезному профессиональному росту, как исполнителей, так и всей компании. И наоборот, «затыки» и так называемая «нецелесообразность» внедрения хорошо структурированных процессов свидетельствовали о незрелости и других серьезных проблемах.
Итак…

Продолжаем серию публикаций, посвященных использованию среды ARM mbed для создания прототипа измерительного устройства.

Сегодня я наконец-то заканчиваю описание программной части — остались вопросы связанные с выводом на TFT-дисплей изображений и кириллицы. Сделаем всё красиво.



Содержание цикла публикаций:

• [Часть 1] Обзор использованных программных и аппаратных решений.
• [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
• [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
• [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
• [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.
• [Часть 6] Печать деталей корпуса

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



Очень скоро мы поняли, что тут мог бы здорово помочь общий высокоуровневый язык запросов, который бы предоставлял единообразный доступ к уже имеющимся системам, а также избавлял от необходимости заново реализовывать типовые абстракции на низкоуровневых примитивах, принятых в этих системах. Так началась разработка Yandex Query Language (YQL) — универсального декларативного языка запросов к системам хранения и обработки данных. (Сразу скажу, что мы знаем, что это уже не первая штука в мире, которая называется YQL, но мы решили, что это делу не мешает, и оставили название.)

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

Я хочу стать архитектором ПО:

Это хорошая цель для разработчика

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

Хм. Ну, тогда ты вовсе не хочешь стать архитектором ПО.

Конечно хочу! Я хочу быть тем человеком, который принимает все важные решения.

Это хорошо, но ты не перечислил важных решений. Ты перечислил решения, не играющие особой роли.

В смысле? База данных – это не важное решение? Знаешь, сколько мы денег тратим на них?

Скорее всего слишком много. И нет, база данных – это не одно из самых важных решений.

Как можно такое говорить? База данных находится в самом центре системы! Там собраны все данные, они сортируются, индексируются и к ним осуществляется доступ. Без нее не будет системы!

База данных это просто устройство ввода-вывода. Так получилось, что она предоставляет некоторые полезные инструменты для сортировки, запросов и отчетов, но все это – вспомогательные аспекты в рамках системной архитектуры.

Продолжаем серию публикаций, посвященных использованию среды ARM mbed для создания прототипа измерительного устройства. Сегодня говорим об основах работы с сенсорным вводом.



Содержание цикла публикаций:

1. [Часть 1] Обзор использованных программных и аппаратных решений.
2. [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
3. [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
4. [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
5. [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.
6. [Часть 6] Печать деталей корпуса

Продолжаем серию публикаций, посвященных использованию среды ARM mbed для создания прототипа измерительного устройства.

Сегодня подключаем датчик.



Содержание цикла публикаций:

• [Часть 1] Обзор использованных программных и аппаратных решений.
• [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
• [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
• [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
• [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.
• [Часть 6] Печать деталей корпуса

Третья часть под катом.

Сейчас вы увидите нечто экслюзивное. Девушка справа на видео — разработчица одного из блоков внутри load-store unit микропроцессорного ядра MIPS P5600, которое является частью системы на кристалле российского микропроцессора Байкал-Т, который используется в офисном принтере «Катюша», терминале «Таволга», системы контроля станков с ЧПУ «Ресурс-30», промышленном контроллере для газовой отрасли «Акситех» КАМ 300 и других устройствах.

А два мужика на видео приезжают в Москву, Санкт-Петербург и Киев для серии семинаров, описывающий все этапы проектирования и производства микросхем: создание спецификации, описание цифровой логики на языках описания аппаратуры Verilog и VHDL на уровне регистровых передач, логический синтез, размещение и трассировка, создание фотошаблонов и производство микросхем на фабрике. Cреди организаторов: РОСНАНО, еНАНО, Imagination Technologies (компания известная как разработчик GPU внутри Apple iPhone), МИСиС, МГУ, МФТИ, МИЭТ, ИТМО, Казахский НТУ, Киевский КПИ и Киевский КНУ. Участники семинара познакомятся с реальными кейсами российских компаний, использующих инструменты САПР: ООО «ЛАБСИСТЕМС», АО «НИИМА «Прогресс», ОАО НПЦ «ЭЛВИС» и АО «БАЙКАЛ ЭЛЕКТРОНИКС». Подробности — http://edunano.ru/doc/6335690702352234538 и https://habrahabr.ru/post/311562.



Под катом — картинки, показывающие какой именно блок проектирует девушка по имени Смрити Оджа, а также (впервые!) часть слайдов Чарльза Данчека (это лектор слева), переведенные на русский язык доцентом Киевского Национального Университета имени Шевченко Александром Барабановым:

В 2013 году от рождества Христова мысль, что телефоны с ARM-процессорами будут запускать полноценный JavaScript также быстро, как десктопы, оснащенные x86, вызывала смех. В те старые времена, три года назад, iPhone 5 отставал по мощности примерно в 10 раз. Казалось, что ничего не может измениться в ближайшее время.

Но всё изменилось. Новый айфон 7 запускает JavaScript, согласно измерениям JetStream benchmark, БЫСТРЕЕ, чем самый быстрый на сегодняшний день Макбук (не про и не эйр). Лучший 5K iMac с 4Ггц процессором i7 теперь всего в два раза быстрее 7го айфона в этом тесте. Процессоры ARM улучшаются с совершенно безумной скоростью. Мур расслабился с десктопами, но бежит как сумасшедший в мобильном мире.

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

Adobe Flash когда-то был стандартом де-факто в мире веб-медиа, но со временем индустрия отвернулась от него из соображений безопасности и производительности. Требовать у юзеров устанавливать плагин для воспроизведения видео — тоже плохая практика. В результате, мы переходим к HTML5 для видео.

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

• Адаптивный битрейт (ABR): Алгоритм определяет пропускную способность канала пользователя, мощность процессора, размер плеера и т.д. в реальном времени и подстраивает параметры видео.
• Изменяемый размер буфера: возможность, позволяющая нам управлять временем, которое нужно для запуска воспроизведения.

Эти возможности позволили индустрии стриминга видео перейти от Flash к HTML5 и JavaScript.

Наш видео-плеер в Yahoo использует HTML5 во всех современных браузерах. В этом посте мы опишем наш путь к реализации этих возможностей, расскажем о проблемах, с которыми столкнулись, и опишем возможности, которые мы видим.

Люди: — Эй, Тойота, мы тут посчитали, у вас из-за корявой электроники и софта 89 человек погибло с 2000 по 2010.
Тойота: — Да они сами виноваты, путают педали.
Люди: — Хьюстон, у нас проблемы.
NASA: — Ща разберемся, нам надо 10 месяцев и 3 миллиона долларов.
Люди: — На.
Тойота: — 3 миллиона мало, вот вам еще сверху кэшем.
(прошло 10 месяцев)
NASA: — Эй, Тойота, мы у вас пару ошибок в коде нашли, а точнее 7134 нарушения стандартов MISRA, рекурсию, функцию на 740 строк и 9000 глобальных переменных.
Тойота: — А у нас свои стандарты. А вы ваще на Луну летали?
NASA (публично): — Тойота ни в чем не виновата.
(Акции Тойота подскочили на 4,6%)
Люди: — Ну ё-моё.
(спустя 3 года)
Два американских тестировщика (у которых дедушки погибли в Перл-Харбор): — Нет багов? А если найдем?

В течение последних шести лет в Яндексе идет работа над системой под кодовым называнием YT (по-русски мы называем её «Ыть»). Это основная платформа для хранения и обработки больших объемов данных — мы уже о ней рассказывали на YaC 2013. С тех пор она продолжала развиваться. Сегодня я расскажу о том, с чего началась разработка YT, что нового в ней появилось и что ещё мы планируем сделать в ближайшее время.



Кстати, 15 октября в офисе Яндекса мы расскажем не только о YT, но и о других наших инфраструктурных технологиях: Media Storage, Yandex Query Language и ClickHouse. На встрече мы раскроем тайну — расскажем, сколько же в Яндексе MapReduce-систем.

Какую задачу мы решаем?

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

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

Так что? Бородатый, хороший совет — следовать лучшим практикам? Мы постоянно слышим о них. Мы даже дали им краткие прозвища, типа DRY или KISS, и используем на автомате в технических разговорах. Мы фанатично следуем концепции, и если кто-то случайно захочет или просто по незнанию не станет их соблюдать, мы выливаем на них вёдра грязной критики. Мы пленники этих убеждений и отказываемся отвернуться от них в нужный момент.

Конечно, я не намекаю, что такие принципы, как DRY — плохие. Это определенно не так. Просто я считаю, что всё зависит от ситуации. Сильно. Что касается именно DRY, это ведёт к логическому выводу: «На самом деле я тот, кто иногда склоняет других к дублированию, а не абстракции».

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

Безопасности на Хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда.

Данная статья продолжает серию публикаций на тему функциональной безопасности.

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

Не рекомендуется к прочтению тем, кто не интересуется стандартизацией.

Продолжаем серию публикаций, посвященных использованию среды ARM mbed для создания прототипа измерительного устройства.

Напомню что речь идет о разработке устройства с сенсорным экраном, которое служит для высокоскоростного измерения температуры и относительной влажности. Самое интересное в этой истории — подход к созданию встроенного ПО. Для написания программы используется онлайн IDE mbed, позволяющая создавать железонезависимый код, который одинаково работает на отладочных платах от SiLabs, Atmel, Wiznet, STM32, NXP и других производителей.

Сегодня начинаем работать с выводом картинки на TFT-дисплей.



Содержание цикла публикаций:

• [Часть 1] Обзор использованных программных и аппаратных решений.
• [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
• [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
• [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
• [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.
• [Часть 6] Печать деталей корпуса

Вторая часть под катом.

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

К сожалению, почти каждый разработчик, и я в том числе, в своей работе сталкивается с кодом плохого качества. И это — болото. У такого кода есть токсичные признаки:

• Функции слишком длинные, и на них слишком много задач
• Часто у функций есть побочные эффекты, которые сложно определить, а иногда даже сложно отлаживать
• Непонятные имена у функций и переменных
• Хрупкий код: небольшая модификация неожиданно ломает другие компоненты приложения
• Плохое покрытие кода тестами или вообще его отсутствие

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

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

Исправление текущих ошибок создавало новые, добавление новых функций рождало новую серию ошибок, и так далее (хрупкий код). Клиент не хотел перестраивать приложение, делать ему удобную структуру, и разработчик принял правильное решение — уволиться.

Такие ситуации случаются часто, и это печально. Но что делать?

Как часто вы поражаетесь, читая чужой код, и думаете «господи, ну и каша...». Скорее всего, достаточно часто. И можете ли вы быть уверенным, что никто не думал также когда читал ваш код? Другими словами, насколько вы уверены в чистоте своего кода? Можно быть уверенным только если полностью понимаешь, что значит чистый код.

Сложно дать точное определение чистому коду, и, скорее всего, сколько программистов — столько определений. Однако, некоторые принципы достаточно универсальны. Я собрал девять самых релевантных и описал ниже.

1.Плохой код делает слишком много, чистый код сфокусирован

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

Но я бы не ограничивал определение классами. В свой последней статье Ральф Вестфал (Ralf Westphal) представил более широкое определение принципа единственной обязанности:

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

Мы занимаемся поставками электронных компонентов. Чтобы делать нашу работу хорошо, недостаточно просто уметь привозить и продавать электронные компоненты — ещё важно уметь демонстрировать их преимущества. Именно поэтому мы не только пишем обзорные статьи, но и создаем руководства по применению разных «железок» и разрабатываем небольшие демонстрационные проекты.



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

Особенный интерес представляет подход к написанию встроенного ПО — софт полностью написан в онлайн IDE от mbed. То есть программа для микроконтроллера была создана на единственной вкладке гугл-хрома и одинаково работает на отладочных платах от разных производителей.

Содержание цикла публикаций:

• [Часть 1] Обзор использованных программных и аппаратных решений.
• [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
• [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
• [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
• [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.
• [Часть 6] Печать деталей корпуса

Первая часть под катом.

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



Типичная разовая терапевтическая доза радиации составляет до 200 рад.
1000 рад — смертельная доза. Восставшая машина фигачила в беззащитных землян 20 000 рад.

Рассмотрим случай, когда поэтапное, но не согласованное внедрение улушений софта привело к системной ошибке. К худшей в истории программной ошибке.

В Therac-25 аппаратная защита была убрана и функции безопасности были возложены на программное обеспечение.

Как проводилось расследование, что должны намотать на ус проектировщики ИТ-систем, программисты, тестировщики, чтобы не допустить подобного.