«Планы ремонтов» в проме!

Началась промышленная эксплуатация программного комплекса «Планы ремонтов» во всех филиалах Системного оператора единой энергетической системы России.

С этого момента исполнительный аппарат СО и все ОДУ со своими подчиненными РДУ от Владивостока до Калининграда планируют и согласовывают все ремонты энергетического оборудования в нашем программном комплексе.

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

Для тех, кто не в курсе, маленькая справка.

В России все ремонты крупного энергетического и электротехнического оборудования, в также устройств РЗА и СДТУ согласуются с Системным Оператором ЕЭС России. Согласование – сложный итерационный процесс, в котором участвуют как владельцы генерирующего или сетевого оборудования, так и филиалы Системного Оператора: исполнительный аппарат, ОДУ и РДУ.

Ранее для согласования оперативных диспетчерских заявок на ремонт оборудования мы разработали ПК «Заявки»/«АСУРЭО». Теперь для планирования создан новый программный комплекс «Планы ремонтов».


ПК «Планы ремонтов» тесно интегрирован с ПК «Заявки»/«АСУРЭО», в частности оба программных комплекса используют единую базу данных оборудования.


Еще раз поздравляю всех участников с завершением большого дела!

Подробнее

День Здоровья 2012

В последнюю пятницу, первого месяца лета, 29 июня, мы не спешили с утра на работу, как весь трудовой народ, у нас был «День Здоровья».

Нужный день в году начался на набережной у пристани «Осипенко», оттуда нас всех отбуксировала ПСка на противоположную сторону Волги.
А на острове нас ждала команда бойцов, которые заготовили нам боевые задания. Мероприятие получилось очень насыщенное.

Мы играли в футбол

                                               

в боулинг

катались на байдарках и катамаранах

пробирались по канатному мосту 

ходили на прикольных лыжах для 5 человек

стреляли из пистолета по мишеням

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

Да жаль только, что День Здоровья только раз в году.

Подробнее

Теперь у нас есть ДМС

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

Для нас ДМС - это знаковое событие. Наверное, не такое масштабное, как переезд в новый офис, но, тем не менее, важное.

Когда мы только образовались, нас было около десятка человек, мы делали большие проекты, но при этом много чего не могли.

Сейчас мы можем платить больше денег, чем тогда. Мы можем работать не на первом этаже жилого дома, а на 20 этаже бизнес-центра. Мы выигрываем большие тендеры в Системном Операторе. Мы можем пользоваться ДМС. Мы идем в том направлении, которое выбрали, добиваясь того, что хотим.

Так что ДМС – это наша маленькая победа в большом сражении.

Подробнее

8 Марта

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

И если год назад у нас были блины, снегоходы и саксофонист вечером, то в этом году мы решили призвать нам на помощь наших меньших братьев.

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


У нас есть старый товарищ, зовут его Вася, и у него дома все эти друзья обитают. А еще есть крокодил, но его сундук (а он живет в сундуке) не полез в машину, поэтому он к нам не приехал.

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

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

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

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

Потом был боулинг и женский турнир по аэрохоккею. А Настя выиграла в автомате Iphone.

Подробнее

Занимательная интерфейсология

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

API как набор интерфейсов

Структурирование

Если API разбит на отдельные интерфейсы - это

• автоматически определяет ее структуру
• позволяет искать решение задачи спуском по дереву API-интерфейс-метод
• позволяет отслеживать зависимости от API по интерфейсам

Автоматическое освобождение

Интерфейсы Win32 позволяют в любой реализации организовать подсчет ссылок на компонент и инициировать его автоматическое освобождение. Не нужно для этого предусматривать специальные функции, да и клиентский код средствами Delphi, C++, C# легко избавляется от необходимости ручного вызова методов для подсчета ссылок.

Стандартность

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

Описание интерфейсов

Вариант использования

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

Возвращаемые ошибки

Описание каждого метода, возвращающего ошибки, должно иметь их полный перечень с перечислением условий возникновения. Без этого API будет неиссякаемым источником труднопроверяемых сбоев.
Пример:
Метод Read может выкинуть исключение EStreamError при ошибках чтения.

Побочные эффекты

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

Внешнее состояние

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

Прочие требования к реализации

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

Требования к интерфейсам

Причина создания

Необходимое и достаточное условие для создания нового интерфейса - новый вариант использования, не покрываемый текущим API.
Пример:
Необходимо обеспечить однократный последовательный доступ к бинарным данным большого объема, не требующий соответствующего объема ОЗУ. Решение - интерфейс IReadableStream.

Минимализм

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

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

Наблюдаемость

Если интерфейс имеет изменяемое сторонними источниками состояние, то необходим механизм оповещения клиентов об изменениях, обычно путем реализации паттерна "публикатор-подписчики".

Неизменяемость

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

Подробнее

Мы играли в кубке по футзалу

Мы совместно с Siemens приняли участие в кубке «НПП «ГКС» по футзалу, который прошел в Самаре 16-17 декабря 2011 года.

На фотографии наша славная команда и прекрасные болельщицы.

Команда СМС-Siemens, усиленная двумя легионерами – нашими друзьями Лыковым и Григорьевым - вышла из группы в полуфинал.

В итоге мы заняли четвертое место, пропустив вперед команды фирм ООО «НПП «ГКС» (Казань), ООО «Стэлс» (Пермь), ООО «НТФ «БАКС» (Самара).

Подробнее