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

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

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

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

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

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

Нет-нет, статья не про план резервного копирования. Статья про план «Б».
Поддавшись массовой истерии, решил я перейти в НПФ. (Нет! Статья не про НПФ!)
Почитал обзоры и рейтинги, выяснил, что разные источники без зазрения совести публикуют разную доходность по одним и тем же НПФ (опять отвлекаюсь)… и решил перевести в ХХХ24 (нет смысла обсуждать).

Прихожу в отделение, сижу с талончиком 1 час (один час) в очереди из трех человек, наконец попадаю на приём и выясняю, что «у нас сегодня система висит и почти не работает». (Вот! Вот про это статья.)
Ну что ж, я понимаю, бывает.
Через два дня, в эту пятницу, я прихожу в другое отделение ХХХ24 и уже совершенно без очереди узнаю, что у них тоже система «висит и не работает». И нет, без системы они не могут принять заявление.
— Как же так? — говорю — Все отделения что-ли не работают?
— Вот в понедельник ещё всё работало нормально. Вы приходите на следующей неделе.
Я даже на минуту задумался, когда у меня на следующей неделе будет возможность уйти с работы, чтобы прийти в банк, но тут же меня осенило:
— Нельзя в такой банк переводить свои деньги!

Нет, это не реакция капризного ребенка. Да, системы, бывает, глючат. Но как себя ведет этой ситуации банк и НПФ? А никак. Они ничего не делают. У них нет плана «Б».
Как раз в те дни, когда всплеск активности переводов в НПФ.
А ведь это не мгновенные переводы, тут система вообще не нужна. Им достаточно принять от меня заявление с подписью, с правильно заполненными реквизитами, с бесполезной ксерокопией паспорта и СНИЛС-а, чтобы потом отослать его в пенсионный фонд и завести в систему.
То есть, где-то в банке сидит большой человек, ответственный за НПФ, получающий бонусы за его успешность, но ему пофигу, что клиенты несколько дней не могут написать заявления.
А ведь мог бы построить всех, разослать хоть по электронке, хоть курьером инструкции по приему заявлений в бумажном виде, отправил бы бланки для заполнения и процедуру, как их потом вводить при восстановлении работоспособности. Понятно, не сам, через подчиненных. Но он не делает этого.
Могу я быть уверенным, что когда нужно будет быстро отреагировать на изменения на рынке и перевести мои инвестиции из одних финансовых инструментов в другие, этот банк сможет быть эффективным?
Нет. Я не уверен.

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

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

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

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

Введение

В один прекрасный день я получил по почте извещение о долге за горячую воду, по причине несвоевременного оповещения коммунальных служб о показаниях водомеров. К этому моменту я, праздного любопытства ради, осваивал WiFi радиомодуль от “Roving Networks” с целью «обучить» его дистанционно включать/отключать электрический водонагреватель для экономии электроэнергии при долгом отсутствии пользователей. И так все сошлось, что решил я свести эти задачи и еще некоторые задумки «умного дома» к практической реализации. Ну и конечно, было бы не интересно, если бы я использовал знакомые мне технологии, поэтому я решил использовать как можно больше нового и интересного.

Сейчас популярна тема онлайн-образования: все слышали про Coursera, Udacity, EdX. Это отличные образовательные платформы, содержащие много полезных курсов. Но можно ли их сделать более интеллектуальными? Вообще исследования по интеллектуальным обучающим системам (intelligent tutoring systems) ведутся давно и у ученых есть что предложить программистам-практикам. В этой статье в научно-популярной форме рассматриваются результаты и выводы, полученные научным сообществом, по построению конкретного вида интеллектуальных обучающих систем. Затрагиваются вопросы построения подсистем проверки решений задач, моделей обучаемого, алгоритмов управления учебным процессом.

Введение

Широко распространены обучающие программы с тестами, содержащими вопросы с вариантами выбора ответа, в числе которых один правильный, а остальные неверные, содержащие типичные ошибки. Теоретическую основу для создания подобных систем в 50-х гг. XX века разработали известный психолог Б.Ф. Скиннер и исследователь Н.А. Кроудер. Предложенные ими концепции неоднократно подвергались критике. В частности, критики отмечали, что контролироваться должны не только ответы, но и пути, ведущие к ним. Ну действительно, ведь главная цель обучения – не зазубривание правильных ответов, а формирование рациональных приемов решения типичных задач изучаемого предмета. Поэтому научная мысль пошла по новому пути. Во-первых, ученые начали создавать обучающие программы, способные распознать не только конечный ответ, но и оценить ход рассуждений обучаемого при выполнении задания (см. часть 1 этой статьи). Во-вторых, ученые начали разрабатывать средства измерения характеристик обучаемых, важных для управления процессом обучения (так называемые «модели обучаемого», см. часть 2) и алгоритмы управления учебным процессом (см. часть 3).

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

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

В конце 2012 года мне пришла в голову идея, что нельзя останавливаться на разработке системы только для транспортных средств, нужно мыслить шире. Так в системе появились новые узлы. Я их назвал: Машина, Дорога, Светофор, Сервер.

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

Итак, вы ☐ твитнули, ☐ написали в блог, ☐ опубликовали пресс-релиз, ☐ написали в комментариях о том, что знаете способ преодолеть CAP-теорему. Ваша идея не сработает. И вот почему:

☐ вы предполагаете, что сбоев софта\железа\сети никогда не случается
☐ вы на самом деле всего-лишь перенесли проблему на другой логический слой
☐ ваше решение эквивалетно одному уже существующему, которое не преодолевает CAP-теорему
☐ вы на самом деле построили AP-систему (доступность и устойчивость к разделению, но не постоянная согласованность данных)
☐ вы на самом деле построили CP-систему(согласованность данных и устойчивость к разделению, но не постоянная доступность)
☐ вы на самом деле построили нераспределенную систему

А особенно в ваших планах плохо следующее:

Пока разработчики сайта скромно молчат, занятые тестированием новой функциональности, сообщу о незаметном, но важном деле размножения интернетов на отдельном сайте. Об этом уже писали на Хабре 10 дней назад: habrahabr.ru/post/188436, но более явно пояснить нововведение заставила фраза в одной из свежих статей: "перезалил на habrastorage". Всё было бы хорошо, но теперь в этом нет смысла.

Если раньше годами сайт Хабра пользовался сторонними сервисами показа изображений, в связи с чем изображения умерших сервисов искажали вид и иногда смысл старых статей, сейчас дошли руки и возможности до того, чтобы сайту уже не зависеть от произвола случайных хостингов — все изображения роботы автоматически переписывают на habrastorage.org. Над комментариями эта незаметная работа началась раньше, в июле, над содержанием статей — недавно, в начале августа (2013). Примеров даже приводить не надо — посмотрите исходный код HTML любых недавних статей — в них вы уже не найдёте доменов с «левыми» картинками. Или лучше посмотрите на код, где автор достоверно пользовался сторонним хостингом картинок: habrahabr.ru/post/189474, потому что большая часть авторов добровольно пользуется habrastorage.org.

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

ИТ системы в производственной зоне

ИТ-технологии в современном мире развиваются стремительными темпами и все больше проникают во все сферы деятельности человеческой цивилизации. Применяемые технологии и оборудование становятся все более сложными и непонятными для человека без специализированной подготовки. Не обошла эта тенденция и промышленные предприятия. Среди основных ИТ систем находящихся непосредственно на производстве следует выделить следующие:
• Внутриконтроллерные сети, применяемые на высокоавтоматизированных производствах для связи внутри и между участками, для получения данных с полевых устройств и элементов автоматики;
• АСУ ТП — группа решений технических и программных средств, предназначенных для автоматизации управления технологическим оборудованием на промышленных предприятиях. Одним из ключевых компонентов данной системы является SCADA;
• WMS — система управления, обеспечивающая автоматизацию и оптимизацию всех процессов складской работы профильного предприятия;
• MES — специализированное прикладное программное-аппаратное обеспечение, предназначенное для решения задач синхронизации, координации, анализа и оптимизации выпуска продукции в рамках какого-либо производства;
• Оконечное оборудование ERP — системы планирования ресурсов предприятия, позволяющей посредством целого комплекса интегрированных приложений создать единую информационную среду с целью автоматизации всех сфер деятельности предприятия от планирования бизнес-процессов до контроля над их реализацией и последующего анализа достигнутых результатов.

Веб-архив — это система, которая периодически сохраняет сайт (или часть сайта) в его оригинальном виде. Чаще всего это делается для потомков, чтобы они могли «поиграться, покликать и поностальгировать».

Основное требование к веб-архиву звучит просто и всеобъемлюще.

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

Для нас, разработчиков, выражение «полнофункциональная офлайн-версия» звучит очень, очень подозрительно. Можно даже сказать — крамольно звучит. Ведь современный сайт без скриптов не бывает, а скрипты всегда порождают неопределенность в поведении. Но, как говаривал один персонаж: «Не нужно спешить с выводами, не то выводы на тебя набросятся».

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

Читатели этой статьи познакомятся с основными методиками и задачами тестирования электронных устройств и получат общее понимание обеспечения качества на производстве. Особое внимание будет уделено достоинствам и недостаткам различных методов тестирования.

Начальник позвал в переговорку, сказал захватить с собой ноутбук. Вроде бы ничего — и там, и на рабочем месте у нас офисная беспроводная сеть. Приходим — а загрузка поставленного на скачивание большого файла оборвалась, SSH-сессии закрылись, заботливо набранная веб-форма при отправке почему-то сбросилась. Знакомо?
Сегодня мы поговорим о бесшовном роуминге устройств в беспроводных сетях Wi-Fi.

Есть такая клёвая простенькая программа для телефона: Remote Volume Control. Делает одну простую вещь — даёт крутить громкость на компьютере (PC). Удобно: включил кино, упал в гамак и когда вдруг возникла необходимость — подкручиваешь громкость.

Вдруг в какой-то чудесный день программа просто молча перестала работать. Никаких обновлений не было, настройки сети не менялись… Как-то я вот не привык чтобы программы вдруг ломались и переставали работать сами по себе.

В общем под катом расскажу ход расследования и в чём оказалось дело.

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

В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.

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

За 3 года существования летнего аналитического фестиваля мы накопили большое количество записей интересных выступлений. И сегодня хотим поделиться с вами подборкой:

1. Предпроектные работы

• Юрий Веденин. Как написать хорошее коммерческое предложение
• Константин Быченков. Цели проекта: Что? Зачем? Как?

2. Выявление требований

• Илья Корнипаев. Креативные техники сбора требований
• Ирина Левенец. Бесконтактное обследование
• Юрий Веденин. Анализ пользователей

Кратко об авторе исходной статьи: Адам Босворт (Adam Bosworth) начал карьеру в Borland, где работал над системой электронных таблиц Quattro. Перейдя в Microsoft он занимал различные руководящие должности, включая пост главного руководителя группы WebData, занятой созданием и продвижением XML. Кроме этого он занимался Access и движком Internet Explorer 4.0 с кодовым именем Trident. Уйдя из Microsoft Адам вошел в число сооснователей Crossgain, после ряда поглощений их основной продукт превратился в Oracle Workshop for WebLogic. В 2004-2007 годах Босворт занимал пост вице-президента по разработке продуктов в Google, где занимался Google Docs и руководил разработкой Google Health (закрыта с 1 января 2012, когда-то о ней писали на хабре). После ухода из Google он основал стартап Keas, использующий элементы социальных сетей и игр для улучшения здоровья.

На этой неделе меня любезно попросили принять участие в качестве эксперта в правительственном совещании (1) о стандартах. В это время я обычно сплю, но в нужный момент я был бодр и сидел у телефона, несмотря на все свое отвращение к недосыпанию. Что заставило меня так поступить? Обсуждались способы, с помощью которых медицинские данные можно было бы на самом деле сделать прозрачными. Какие стандарты надо использовать для совмещения подобных данных?

К собственному удивлению и в какой-то степени боли, я успел поучаствовать в разработке нескольких стандартов. Один из них использовался для обмена данными между базами данных и пользовательскими приложениями вроде электронных таблиц или Access. Он назывался ODBC и отлично показал себя, несмотря на некоторые затруднения в начале. Другим был стандарт того, что сейчас называется AJAX, создания сложных, интерактивных веб-страниц вроде Gmail. Наверное самым важным был XML. Это все успехи. Были и провалы. Особенно хорошо я помню OLE DB, которым мы хотели заменить/вытеснить ODBC. Одним из балансировавших на грани успеха и провала был/является XML Schema. В результате всех этих усилий я выучил несколько уроков, которыми постараюсь поделиться с вами. Каковы они?