Анализ и проектирование систем *

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Что делать, когда возможностей тестов недостаточно?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндекс.Почте, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Было-стало после кластеризации и оптимизации культур

Колхозы и агрохолдинги в России почти не автоматизированы. А там на почти ровном месте с минимальными затратами можно получить до 10 % прироста доходности за счёт выбора оптимального портфеля выращиваемых культур, точного распределения техники по работам и вообще нормального планирования. Мы пришли на несколько объектов и провели расчёты для них, о чём сейчас я и расскажу.

Сформулировали три фундаментальных вопроса:

1. В каких пропорциях что нужно вырастить и где, чтобы больше заработать?
2. Когда какая техника и где будет работать?
3. Что должно быть в парке техники, чтобы не возникало рисков срывов сроков проведения агроопераций или больших затрат на найм?

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

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

Аполлон 11 на Луне

Через пять месяцев Аполло 12 выжил после удара молнии при разгоне и сел на Луну. Благодаря новому «существительному 69», которое мы добавили в программу для того, чтобы позволить команде изменять положение, основываясь на данных наземного слежения, астронавты Пит Конрад (Pete Conrad) и Алан Бин (Alan Bean) смогли посадить лунный модуль в шаговой доступности от беспилотного корабля Surveyor, который сел на Луну в апреле 1967. Точная посадка Аполлона 12 проложила дорогу для посадок на более сложный рельеф местности.

Оборудование Hybrid Simulation Lab. На фото показана панель управления SDS 9300, который, совместно с несколькими аналоговыми компьютерами, отрабатывал симуляции командного модуля и лунного модуля.

За годы до появления Apollo 11, когда разрабатывалась система управления, о встроенном программном обеспечении думали как о чём-то таком, что можно сделать в последнюю очередь: «Хэл это сделает» — так они говорили. На самом деле этим занимались десятки людей, и сотни людей вспомогательного персонала, но Хэлу Лейнингу (Hal Laning) сначала пришлось разбираться, как организовать многочисленные функции ПО, чтобы они выполнялись практически одновременно в реальном времени на бортовом компьютере космического аппарата, имеющем ограниченные размер и быстродействие.

Часть 2
Часть 3

Часть фотографий была взята с сайта Hack The Moon.

Статья была представлена на 27-й ежегодной конференции по навигации и управлению Американского Общества Астронавтики (AAS) в Брекенридже, штат Колорадо, 6 февраля 2004. Предлагаемая вам версия содержит дополнительные иллюстрации, комментарии и небольшие исправления.



ABSTRACT: Миссия Аполлон 11 совершила успешную посадку на Луну, несмотря на две проблемы с компьютером, повлиявшие на лунный модуль в период управляемой посадки. Неустранённая проблема в интерфейсе радара сближения отняла около 13% времени цикла бортового компьютера, приведя к пяти сбоям программы и перезагрузкам. Менее известная проблема была вызвана ошибочными данными, что привело к флуктуациям тяги двигателя посадки лунного модуля, так как алгоритм управления тягой находился на границе устойчивости. Объяснение этих проблем даёт возможность описать операционную систему бортового компьютера Аполлона и программу управления посадкой на Луну.

Содержание цикла статей: https://github.com/nomhoi/empire-erp.

В данной статье мы осуществим попытку проникновения в самое сердце "кровавого энтерпрайза" — в бухгалтерию. Вначале мы проведем исследование главной книги, счетов и баланса, выявим присущие им свойства и алгоритмы. Используем Python и технологию Test Driven Development. Здесь мы займемся прототипированием, поэтому вместо базы данных будем использовать базовые контейнеры: списки, словари и кортежи. Проект разрабатывается в соответствии с требованиями к проекту Empire ERP.

Система доменных имен (DNS) является подобием телефонной книги, которая переводит удобные для пользователя имена, такие как «ussc.ru», в IP-адреса. Так как активность DNS присутствует практически во всех сеансах связи, независимо от протокола. Таким образом DNS логирование является ценным источником данных для специалиста по информационной безопасности, позволяющее им обнаруживать аномалии или получать дополнительные данные об исследуемой системе.

В 2004 году Флорианом Ваймером был предложен такой метод логирования, как Passive DNS, позволяющий восстанавливать историю изменений DNS данных с возможностью индексации и поиска, которые могут предоставлять доступ к следующим данным:

• Доменное имя
• IP-адрес запрошенного доменного имени
• Дату и время ответа
• Тип ответа
• и т.д.

Данные для Passive DNS собираются с рекурсивных DNS-серверов встроенными модулями или с помощью перехвата ответов от DNS-серверов, ответственных за зону.

Рисунок 1. Passive DNS (взят с сайта Ctovision.com)

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

Так появились награды — виртуальные медальки, которые мы начисляем за разного рода задания: загрузить фото в карточки кафе, написать отзывы о театрах, уточнить время работы организаций и так далее. Заработанные награды пользователи видят в личном профиле 2ГИС и на вкладке «Мой 2ГИС» в мобильном приложении. Там же мы показываем, сколько осталось до следующего достижения.

Чтобы реализовать эту фичу, мы научились обрабатывать поток событий объемом 500 тысяч записей в час (местами — до 50 тысяч в секунду) и анализировать данные из нескольких сервисов. А еще — добавили немного метапрограммирования для того, чтобы упростить конфигурирование при разработке новых наград.

Вместе с Rapter расскажем, что находится под капотом процесса выдачи наград.

История

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

Пуля – это такая система оплаты труда. Ничего сверхъестественного, идея лежит на поверхности, результаты не заставляют себя долго ждать. Название придумал не я, а собственник компании, где эта система внедрялась. Вот прям так выслушал аргументы и особенности, и сказал: «Это – Пуля!».

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

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

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

В конце августа мы объявили о старте конкурса для изобретателей и рационализаторов (в самом широком смысле этих слов) «Используй NUC – выиграй NUC». Конкурс такого формате в блоге Intel проводился впервые, поэтому опасений было много, и самое главное из них — что в нем просто не окажется участников. К счастью, этого не произошло, заявок было достаточно, а их уровень вполне нас устроил. Нам осталось лишь объявить победителей и выслать им призы.

Как превратить условно-работающую ERP в реальный инструмент управления производством и поставками.
1 часть (пред.статья): проблемы использования для планирования внедренных «учетных» ERP
2 часть (данная статья): 2я жизнь — постановка Планирования и Мониторинга производства и поставок с внешним планировщиком. Концепция и реализация.

Питеркин Сергей, Меркулов Михаил, «Райтстеп»

Предлагаемая модель планирования: ERP+СПМ

Ниже представлены тезисы модели планирования, которая может быть реализована относительно просто и быстро. И, что немаловажно, без потери денежных и временных инвестиций, вложенных во внедрение «учетной части» «производственной ERP».

Концепция Системы Планирования и Мониторинга (СПМ) Райтстеп

Система планов

Как превратить условно-работающую ERP в реальный инструмент управления производством и поставками?
1 часть (здесь): проблемы использования для планирования внедренных "учетных" ERP
2 часть (по ссылке): 2я жизнь — постановка Планирования и Мониторинга производства и поставок с внешним планировщиком. Концепция и реализация.

Питеркин Сергей, Меркулов Михаил, «Райтстеп»

За последние годы, количество производственных предприятий, заявляющих о внедренных ERPсистемах, значительно возросло. И составляет уже не десятки, а сотни. Говорим мы прежде всего о дискретном производстве, а под «производственной ERP» подразумеваем любую систему, претендующую на это гордое название. По частоте наших «столкновений», наиболее распространенными «работающими в производстве» ERP являются — BaaN/InforLN, InforERPSyteLine, постоянно-растущая «армия» заводов с 1С, и в небольшом количестве SAPERP и прочая экзотика.

Данная статься будет интересна прежде всего «продвинутым» пользователям ERP, в большей степени с позаказным типом производства («вытягивание» под заказ или на склад, в т.ч. и «вытягивание» под прогноз спроса), тем, кто автоматизировал (возможно – «как есть») процессы учета хода производства, т.е. формирования производственных заданий (далее по тексту – ПЗ. В разных системах: SFC-заказы, Job-Orders, JOBs, Заказы на Производство, Производственные заказы и т.п.) и их отслеживания, но так и не смог уверенно производство (и поставки – МТО (Материально-Техническое Обеспечение)) планировать, как и не смог поставить мониторинг производства, в т.ч. и позаказный. С непрекращающимися попытками все-же запустить планирование, и/или с попытками обеспечить планирование с использованием волшебных алгоритмов и/или систем типа APS, MES.

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

После прочтения данной статьи:

• Вам не нужно будет отправлять 10-20 заявок в студии и фрилансерам, общаться с ними чтобы понять цены и как происходит ценообразование.
• Вы поймете почему такой большой разброс цен от 100 тыс руб до 5 млн руб за проектирование и дизайн MVP онлайн-сервиса, какие факторы на это влияют
• У каких специалистов или студий вы можете заказать разработку «под ключ» или отдельно проектирование и дизайн веб-сервиса.
• Вы сможете сами посчитать примерную стоимость и срок под свои задачи через калькулятор в таблице exel.

Для начала перейдём к некоторым соглашениям и обозначим термины.

Михаил Коновалов, руководитель направления отдела сопровождения интеграционных проектов ИТ-дирекции МКБ

День добрый, хабровчане!

Цель

Систематизированный подход к управлению загрузками. Мы хотим рассказать, как упорядочить и автоматизировать наполнение хранилища информацией, и при этом не запутаться в потоках из различных источников.

Когда кластеры достигают размеров в сотни, а иногда и тысячи машин, возникает вопрос о согласованности состояний серверов относительно друг друга. Алгоритм распределённого консенсуса Raft даёт самые строгие гарантии консистентности из возможных. В этой статье мы рассмотрим Raft с точки зрения инженера и постараемся ответить на вопросы «Как?» и «Почему?» он работает.

Введение

Статья описывает возможности и архитектурные особенности облачной платформы Citrix Cloud и набора сервисов Citrix Workspace. Данные решения являются центральным элементом и основой для реализации концепции цифровых рабочих мест (digital workspaсe) от компании Citrix.

В настоящей статье я попытался разобраться и сформулировать причинно-следственные связи между облачными платформами, сервисами и подписками Citrix, описание которых в открытых источниках компании (citrix.com и docs.citrix.com) выглядит местами очень туманно. Облачные технологии – по-другому видимо никак! Стоит отметить, что архитектура и технологии раскрыты в целом вменяемо. Сложности возникают в понимании иерархической взаимосвязи между сервисами и платформами:

• какая платформа первична — Citrix Cloud или Citrix Workspace Platform?
• в какую из платформ, указанных выше, входят многочисленные сервисы Citrix, необходимые для построения инфраструктуры цифровых рабочих мест?
• сколько стоит это удовольствие и в каких вариантах его можно получить?
• возможно ли реализовать все фичи digital workspaсe Citrix без использования Citrix Cloud?

Ответы на эти вопросы и знакомство с решениями Citrix для цифровых рабочих мест под катом.

Давно не брал пера я в руки...

В прошлом году описывал несколько проектов технического трабл-шутинга. Хочу продолжить этой статьей.

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

Предыстория

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

Кажется, что сфера интернет-рекламы должна быть максимально технологичной и автоматизированной. Ещё бы, ведь там работают такие гиганты и эксперты в своём деле, как Яндекс, Mail.Ru, Google и Facebook. Но, как оказалось, нет предела совершенству и всегда есть что автоматизировать.


Источник

Коммуникационная группа Dentsu Aegis Network Russia — крупнейший игрок на рекламном digital рынке и активно инвестирует в технологии, пытаясь в оптимизировать и автоматизировать свои бизнес-процессы. Одной из нерешенных задач рынка интернет-рекламы стала задача сбора статистики по рекламным кампаниям с разных интернет-площадок. Решение этой задачи в итоге вылилось в создание продукта D1.Digital (читать как ДиВан), о разработке которого мы и хотим рассказать.

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

Прошлое

Давным-давно компьютерные сети еще были большой редкостью. И тогдашние СКУД строились следующим образом: мастер — контроллер обслуживал ограниченное количество контроллеров, а компьютер выступал в роли терминала для его программирования и отображения информации. Логику работы определял мастер-контроллер, управляющий вторичными контроллерами.

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