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

В статье Мартина Фаулера и Джеймса Льюиса, в которой описываются достоинства «Microservice Architecture», написано:

Enterprise приложение — приложение, построенное как единое целое. ЛЮБОЕ изменение в системе приводит к пересборке и равертыванию новой версии серверной части приложения.

Понятно стремление авторов быть пропагандистами «Microservice Architecture», однако использование таких определений как ЛЮБОЕ, ВСЕГДА, НИКОГДА говорит о слишком эмоциональном отношении к предмету. Налицо попытка увлечь читателя эмоциями, отключить его мозг. Когда авторы используют такие преувеличения, где-то тут должен скрываться чорт. Так где же он, рогатый?

VIII Определяем сущности предметной области

Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям

Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).

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

Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.

Постановка задачи

Цифровые и аналоговые датчики, подключенные к Arduino, генерируют большие объёмы информации, которая требует обработки в реальном масштабе времени [1].

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

Данная публикация посвящена программному решению задачи хранения информации от датчиков, работающих с Arduino и её графическому представлению в реальном масштабе времени. В примерах используются широко известными датчиками, такими как потенциометр и датчик движения PIR.

Использование CSV-файлов для хранения данных полученных от датчиков, работающих с Arduino

• Для записи данных в CSVфайл можно использовать простой листинг:
  
  

  import csv
  data = [[1, 2, 3], ['a', 'b', 'c'], ['Python', 'Arduino', 'Programming']]
  with open('example.csv', 'w') as f:
    	w = csv.writer (f)
   	 for row in data:
  		w.writerow(row)
  

Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

VII Детализируем процессы, включенные в рамки проекта

Нужно усложнять, чтобы в результате все стало проще,
а не упрощать, чтобы в результате все стало сложнее.
Веслав Брудзиньский

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

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

Об авторских тренингах на тему: «Обучение проектированию ПО. Функции системы» подробнее можно узнать на моем YouTube канале

VI Определяем функции системы и границы проекта

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

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

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

Пролог

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

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

Теперь я хочу рассказать, как можно качественно сформировать сами требования, ведя Заказчика от его «хотелок», к его счастливому и плодотворному сожительству с программным продуктом, его мечты.
Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

Доводилось ли Вам реализовывать объёмный сетевой обмен посредством TCP- или HTTP-протокола? Насколько, в случае такого опыта, Вы были удовлетворены сопровождаемостью конечного решения? Утвердительный ответ на первый вопрос (пусть даже и без «объёмистости» обмена) и недовольство гибкостью получившейся реализации позволяют рекомендовать эту статью как содержащую один из способов избавления от такого несчастья.

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

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

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человеко\днях или человеко\часах (как Вам удобнее) по подсистемам и проекту в целом.

С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему

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

Готовим читателей к знакомству со спецификациями

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

Пример обзора документа:



Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

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

Еще одна статья от лица участника школы о проекте, реализованном в рамках очередного выезда:

«Я – Дмитрий Пасечнюк, и я хочу поделиться своим исследованием, сделанном на каникулах в рамках выездной весенней смены Школы GoTo под руководством Александра Петрова, asash, технического директора компании E-Contenta.

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

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

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

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

Обо всем по порядку под катом.

Не далее чем в июле прошла очередная школа GoTo. В этот раз мы решили внести некоторое разнообразие в стандартный набор Ардуин, Питонов, и прочих, и случился Хаскелль. Небольшое отделение из 6 юношей (кусочек нашего общего взвода в 60 человек) бодро промаршивало по $$-исчислению, основам синтаксиса, прошло посвящение в ФП написанием факториала, посворачивало списки, научилось словосочетанию "параметрически полиморфная функция высшего порядка" и присущему этому пониманию типов и тайпклассов под предводительством ефрейтора Волкова.

А ещё у нас были элементы инфобеза, криптовалюты, React Native, nix, и, конечно, git.

И мы начали писать книгу про Haskell.

В общем, получилось задорно.

(Под катом картинки участников, лямбды, илосос, анонс нового направления и гранты)

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

Данная задача включает две подзадачи:

1) когда пользователь уходит с формы редактирования, необходимо понимать, действительно ли он произвёл изменения, чтобы не задавать вопрос на подтверждение впустую и не перезаписывать идентичные данные;

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

В статье мы рассмотрим обобщённый и очень лаконичный [размером в несколько строк кода!] подход к решению подобного рода задач, основанный на использовании библиотеки Replication Framework.

Пару недель назад в Яндексе прошла встреча PyData, посвящённая анализу больших данных с использованием Python. В том числе на этой встрече выступил Василий Агапитов — руководитель группы разработки инструментов аналитики Яндекса. Он рассказал о двух наших библиотеках: для описания и запуска расчетов на MapReduce и для извлечения информации из логов.


Под катом — расшифровка и часть слайдов.

В этой статье краткий обзор программируемых контроллеров для HVAC (отопление, вентиляция и кондиционирование) от 3х производителей:

• ОВЕН ПЛК63/73
• Segnetics SMH2g и Pixel
• Schneider Electric M171/172

Исходя из личного опыта их использования.

---

Задачи по копированию отдельных объектов и связных графов часто встречаются в программировании. Методов их решения существует несколько в зависимости от исходных условий и требований. Цель статьи — рассмотреть ключевые разновидности решений, обозначить область применения, выделить преимущества и недостатки.

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

Герой сегодняшней статьи, на первый взгляд, не представляет собой ничего особенного — мало ли мы видели цифровых датчиков температуры. Однако у серии TSic есть два необычных свойства: действительно высокая точность (до ±0.07°C у старшей модели) и малоизвестный однопроводной интерфейс ZACwire.

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

Приветствую, читатель!

Хочу познакомить тебя с молодой, но многообещающей библиотекой Replication Framework для платформы .NET (возможно, при наличии достаточного интереса к теме в дальнейшем будет также реализована Java-версия). Библиотека является портабельной (portable) и может быть использована в любом проекте под Microsoft .NET или Mono.

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

Как вычислить замыслы киберпреступников, атакующих промышленный объект и распознать слабые сигналы SOS, которые периодически подает индустриальная АСУ ТП на фоне “нормального” поведения, – об этом и многом другом поговорим уже в ближайшую среду, 7 июня, на встрече CoLaboratory: Deep Learning в центральном офисе “Лаборатории Касперского”. Всех неравнодушных к теме промышленной безопасности ждет захватывающее погружение в мир машинного обучения и анализа данных под руководством победителей весеннего индустриального хакатона ЛК и экспертов нашей компании.

Источник

Вашему вниманию предлагается статья о том, как был создан онлайн курс по тематике «Функциональная безопасность». Сервисы онлайн обучения располагают студийным оборудованием для записи высококачественного звука и видео. А если вдруг представить, что доступа у вас к подобным ресурсам нет, а учебный материал надо подготовить для использования в онлайн режиме? Автор решил поделиться собственным опытом и раскрыть следующие вопросы:

— мотивация или зачем и кому это надо;
— инструменты подготовки и записи;
— содержание Massive Online Open Course (MOOC) по функциональной безопасности;
— дальнейшие шаги по развитию продукта.