Рубрика «Промышленное программирование» - 26

в 8:02, , рубрики: big data, MapReduce, YT, Алгоритмы, Анализ и проектирование систем, Блог компании Яндекс, инфраструктура Яндекса, Промышленное программирование, метки:

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

YT: зачем Яндексу своя MapReduce-система и как она устроена - 1

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

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

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

Читать полностью »

в 9:03, , рубрики: DRY, дублирование кода, практика программирования, Программирование, Проектирование и рефакторинг, Промышленное программирование

DRY и цена неправильных абстракций - 1

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

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

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

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

в 16:22, , рубрики: ics, IEC 61508, IT-стандарты, plc, scada, автоматизация, Анализ и проектирование систем, асу тп, информационная безопасность, критически важные системы, Промышленное программирование, стандартизация, стандарты, функциональная безопасность

Функциональная безопасность, Часть 3 из 3. МЭК 61508: Систематичная случайность или случайная систематичность? - 1 Безопасности на Хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда.

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

Во вводной части 1:

— обоснована важность оценивания и обеспечения функциональной безопасности для компьютерных систем управления;
— рассмотрены архитектуры систем, для которых необходимо оценивать и обеспечивать функциональную безопасность; к таким системам относятся АСУ ТП (Industrial Control Systems) на базе программируемых логических контроллеров (ПЛК), встроенные системы (Embedded Systems) и уровень устройств (Device Layer) для интернета вещей;
— кратко представлено множество стандартов, относящихся к функциональной безопасности в различных сферах применения.

В части 2 рассмотрена общая структура стандарта МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems) и используемая в нем терминология.

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

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

в 10:34, , рубрики: atmel, FT800, HYT, IST, mbed, SiLabs, Wiznet, Блог компании ЭФО, программирование микроконтроллеров, Промышленное программирование, Разработка для интернета вещей, Разработка робототехники

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

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

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

Как перестать бояться и полюбить mbed [Часть 2] - 1

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

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

Вторая часть под катом.
Читать полностью »

в 9:13, , рубрики: качество кода, Программирование, Промышленное программирование, Совершенный код, функции, чистота кода

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

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

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

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

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

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

Искусство написания простых и коротких функций - 1

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

в 10:52, , рубрики: C, Блог компании Edison, марс, марсоход, отладка, Программирование, Промышленное программирование, разработка, тестирование, Тестирование IT-систем

— Хьюстон, у нас проблемы.
— Нет, Марк, это у тебя проблемы.

Как спится программистам и тестировщикам марсохода за 400 миллионов долларов? Особенно если на 18 сол аппарат не вышел на связь.

Программист на Марсе: Shutdown Dammit Until - 1

Марк Адлер — американский разработчик программного обеспечения, который работает в сфере исследования космоса. Более всего он известен благодаря своей работе в области сжатия данных, являясь автором хеш-функции Adler-32, а так же как со-автор библиотеки для сжатия данных zlib и gzip. Он участвовал в разработке Info-ZIP и формата изображений Portable Network Graphics (PNG). Адлер также был ответственным за миссию марсохода «Спирит» в рамках программы «Mars Exploration Rover».

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

в 9:24, , рубрики: качество, Программирование, Проектирование и рефакторинг, Промышленное программирование, Совершенный код, чистый код

Главные характеристики качественного кода - 1

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

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

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

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

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

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

в 10:53, , рубрики: atmel, FT800, HYT, IST, mbed, SiLabs, Wiznet, Блог компании ЭФО, программирование микроконтроллеров, Промышленное программирование, Разработка для интернета вещей, Разработка робототехники

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

Как перестать бояться и полюбить mbed. [Часть 1] - 1

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

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

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

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

Первая часть под катом.
Читать полностью »

в 9:41, , рубрики: Defensive design, Блог компании PVS-Studio, модульное тестирование, отладка, Промышленное программирование, радиация, статистический анализ кода, Тестирование IT-систем, метки:

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

Баг-убийца. Фигак, фигак и Therac-25 - 1

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

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

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

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

в 6:11, , рубрики: C, scada, SimInTech, Simulink, Анализ и проектирование систем, генерация кода, моделирование предметной области, Программирование, Промышленное программирование, системы управления

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

В этой части будет показано как из SimInTech сгенерировать код Си, реализующий программу управления на основе логики «конечных автоматов», а потом отдалить в MS Visual Studio 2015 совместно с моделью объекта в SimInTech.
Читать полностью »

1...1020...252627...30...34
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js