среда, 13 августа 2014 г.

Астрономия — Фото 2014 — II


вторник, 12 августа 2014 г.

Разработчики МПЦ «Ипуть»

Разбирая архивы нашел фото, на котором есть почти все разработчики процессорно-релейной централизации «Ипуть».

Слева направо:

Бочков К. А.
Руководитель проекта, решение всех политических, организационных и стратегических вопросов.
Логвиненко А. В.
Архитектура системы, разработка ядра ПРЦ, общая стратегия доказательства безопасности.
Ермоленко А. В.
Разработка алгоритмов работы станции, интеграция с устройствами и внешними системами ж.д. автоматики и телемеханики.
Кузьмич М. C.
Разработка безопасной системы сетевой передачи данных, разработка АРМа, разработка системы принятия решений.
Сивко Б. В.
Доказательство безопасности устройств связи с напольными объектами, разработка драйвера связи с напольными объектами.
Харлап С. Н.
Испытания системы на безопасность, разработка аппаратной части узлов интеграции с напольными объектами.
Зобов С. М.
Внедрение, испытания, дизайн и наладка системы, разработка алгоритмов работы станции, разработка подсистемы тестирования алгоритмов, электропитание.

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

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

После ввода в эксплуатацию развитие проекта до версии 2.0 велось, но не такими темпами (это увязка с перегонами, повышение диверситета, разработка новых схем увязки с напольными объектами, повышение доли микро- по сравнению с реле, разработка систем автоматического тестирования, разработка безопасной виртуальной машины, разработка системы удаленного управления).


понедельник, 11 августа 2014 г.

Парижская школа

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

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

Если рассматривать глобально, то длительное время люди стремились изобразить на холсте реальность (мишки в лесу, натюрморты, портреты, …). Были конечно различия (на Западе как можно идеальнее и красивее, на Востоке изобразить как есть и найти там красоту и пр.), но в общем случае генеральный вектор к реальности был одинаков. Однако после какого-то момента ещё больше приближаться к реальности нет особого смысла. Если можно сделать фото, то зачем перерисовывать то же самое, только вручную? Соответственно, если мы фотографигруем мишек в лесу, то то же самое делать руками бессмысленно. Поэтому если хотим изобразить что-то, то лучше найти что-то более со смыслом (чего трудно в реальности), или сменить акцент. Что в свое время и сделала Парижская школа, выйдя из тупика (который был изображен в виде квадрата Малевича, он же символ конца искусства).

Сейчас пришел к такому выводу, что в ряде других областей наблюдается или наблюдалось такое же явление. Например, в научной фантастике, зародившейся где-то на Ж. Верне и Г. Уэллсе, а в дальнейшем был расцвет в виде т.н. классики (Беляев, Саймак, Бредбери, Хайнлайн). Однако, через некоторое время фантастика попала в кризис, рубеж которого находился где-то в районе Суммы Технологий Лема. Данное явление обсуловлено тем, что в фантастике нужно было успешно совмещать несколько вещей. Во-первых, быть достаточно подкаванным в науке, и разбираться в последних достижениях достаточно глубоко. Во-вторых, эту информацию преобразовывать читателю таким образом, чтобы он все это понял. И в-третьих, находить на этой научном гребне что-то новое, делая шаг вперед. Так как научный разрыв постоянно увеличивался от простых людей, то совмещать все это становилось сложнее и сложнее, и в конце концов фантастика свалилась в миры фэнтези. Таким образом, акцент с реальности сместился в фантазирование, оторванное от реальности.

Следующий яркий пример который можно наблюдать прямо сейчас это видеоигры. Длительное время все стремились сделать все реальнее, красивее, детальнее и проч.. Однако со временем из-за развития компьютеров во-первых, качество резальтата стало очень высоким, а во-вторых, для достижения этого качества уже не хватало команды в пару человек, нужна уже была большая студия с опытом работы. И таким образом, как мне кажется, где-то в районе 2007-2010 (в основном из-за уменьшения барьера инди) запустилось отдельным направлением из инди реализация таких видеоигр, которые особо не заморачиваются на качестве графики и прочего, а акцентируют свое внимание на совершенно других вещах, которые чем-то даже напоминают Парижскую Школу.

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


воскресенье, 10 августа 2014 г.

Удобны ли ваши API?

Написанное здесь обусловлено тем, что в последние год-два приходилось сталкиваться наверное раз пять с различными проявлениями в отношении пользователей к API и документации в целом. В данном сообщении в основном все базируется на одноименной статье Стивена Кларка, имеющейся в книге «Идеальная разработка ПО», и в е-виде содержимое на находится. Стивен провел более 10 лет работая над совершенствованием API в Microsoft'е, с 1998-го года, с такими инструментами, как Visual Studio.

Удобство API

Сплошь и рядом попадается ситуация, когда проектирование библиотек, API и т.п. происходит как есть, для себя, по каким-то высшим или подсознательным катеогриям, но без какого-либо обращения внимания на пользователей, их разнообразие и решаемые ими задачи. Так получается, что потери reengineering'a с той стороны либо совершенно не волнуют, либо списываются на глупость или неусидчивость пользователей, и более того, идут аргументы вида «а вы используете неправильно, не ходите туда и не делайте так, делайте как мы».

Цитата С. Кларка:

Меня как разработчика, который пользовался Visual Studio до присоединения к группе Visual Studio, используемые инструменты часто раздражали. Параметры компилятора было трудно найти и задать. Настройка путей к библиотекам выглядела громоздкой и неудобной. У продукта было много недостатков из области удобства использования, которые я хотел исправить при поступлении на работу в Microsoft.

Я не хочу сказать, что у меня не было трудностей с API фирмы Microsoft. Напротив, чуть ли не самые серьезные проблемы, с которыми я когда-либо сталкивался, были связаны с пониманием API библиотек MFC. Но в отличие от ситуации с инструментами, в том, что мне не удается разобраться в правильном использовании VFC, я винил только себя. Ни разу я не подумал, что проблема крылась в проектировании API.

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

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

Работа с API не представляет собой работу со всем API целиком

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

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

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

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

Разные пользователи

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

Три типа пользователей из статьи:

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

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

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

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

Архитектура API и интерфейс пользователю

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


суббота, 9 августа 2014 г.

Первая публикация с вариантом на английском

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

Статья посвящена проблемам валидации при разработке и верификации программного обеспечения для систем, критичных по безопасности (безопасность которая safety). В частности, про выбор функции безопасности, в котором необходимо как выполнять требования с минимальными потерями, так и соблюдать баланс.

Отпраздновать что ли…