by Александр Санников

15/04/2012 19:25:20 in Рабочий процесс

1. СУБ и СРТ — окончательно оторвали системы от портала, 2 ближайшие недели покажут эффект
2. СРТ-light — посмотрели первые результаты разработки — слабо. Проведем работу над ошибками.
3. Биллинг+ — хороший сдвиг по 2 пилотам из 3, на неделе делаем первые расчеты.

by Дмитрий Регент

14/04/2012 11:01:52 in Рабочий процесс

Давайте представим себе ситуацию.

Допустим у нас есть программа. Назовём её например Атлас

Пользователь программы Атлас рапортует об ошибке в версии 2.1.201.0. Текущая версия Атласа у разработчиков 2.1.234.0. Ошибка в этой версии не воспроизводится. Говорит ли это о том, что ошибка исправлена? В общем случае нет.

Какой тут должен быть workflow?

1. воспроизвести
2. исправить (если нужно)
3. доставить пользователю исправленный функционал (или последнюю версию системы)

Программист примерно догадывается, что могло вызвать ошибку. Открывает Visual Studio, делает revert to revision соответствующей версии 2.1.201.0. Запускает модуль на тестовой базе. и…. опа. Атлас падает с ораклической ошибкой, что не найдена какая-та процедура в схеме. Далее возможны различные действия. Одно хуже другого. Например править баг на боевой базе (все же знают известного грека) или писать костыль, закрывающий вызов ненайденной процедуры надеясь, что не упадут другие, или сказать «всё исправил!» и собрать сетап с версией 2.1.234.0. Никто всё равно не будет разбираться, ведь так?

А сейчас простая истина, на которую мы все дружно закрываем глаза. Наши продукты в основном представляют из себя толстый клиент (модуль) и схему в базе (oracle). Версионирование системы это версионирование кода модуля И базы. Без версионирования базы мы в общем случае не можем откатиться на какой-то момент развития системы. По сути создаём мёртвый код, который тупо занимает место на сервере svn.

Мы не первые кто наступает на такие грабли, и мы все достаточно компетентны чтобы учиться на ошибках (желательно чужих). Я перечитал некоторое количество статей, в которых люди уже научились на своих ошибках и поделились опытом со всеми.

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

Три правила для базы данных

1. Никогда не использовать общую базу для целей разработки.

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

2. Всегда иметь единственный авторитетный исходник базы данных.

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

3. Всегда вести версионность базы

Существует много способов делать это. Но не делать этого — преступление.

Некоторые полезные статьи

by Александр Санников

08/04/2012 22:50:35 in Рабочий процесс

1. Свершился пререлиз СРТ-light, на предстоящей неделе ждем от Саши Полунина чуда. Готовим ТЗ на автоматизацию расчета тарифов с использованием методики индексации.

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

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

by Бонд

Я заметил, что многие коллеги не доверяют виртуальным машинам, и считают, что для их задач было бы удобнее и надёжнее иметь физические машины.
Вы хотите об этом поговорить? (с)
Что я спрашиваю — конечно, хотите!

Отбросим абстрактные маркетинговые приёмы. Чуть ниже я выписал некоторые конкретные факты, с которыми мы сталкиваемся в работе системы ЕИАС. Повторюсь, что список брался из головы, не полон и вполне обсуждаем.

Плюсы виртуализации

• У нас есть «срезы» состояния виртуальных машин на любой нужный момент времени.
• Мы можем одним движением «откатить» виртуальную машину на произвольный момент времени.
• Нас не волнуют аварии, связанные с железом. Никто не замечал, когда у нас на блейдах погорел уже не первый процессор — все машины прозрачно и мгновенно мигрировали на «живое» железо.
• Мы всегда можем мгновенно развернуть любое количество точно таких же машин, как имеющиеся.
• Что вы сделаете в случае, если у вас «повисла» физическая машина? Выход один — послать чернокожего гномика, чтобы он её перезапустил. С виртуальной машиной таких проблем не бывает. Включить, выключить, перезапустить, переставить всё что угодно — можно, не вставая с любимого кресла!
• Мы можем выделять любые мощности на любую машину. Один процессор? Два? Сорок два? Легко! Любые процессорные мощности, оперативная память, место на жёстком диске — к вашим услугам! И мы можем их менять на уже имеющихся машинах!
• Лицензии ПО на виртуальные машины получаются значительно дешевле.
• Миграция на другое «железо» происходит быстро и безболезненно.

Минусы виртуализации

by CavinSmith

29/12/2011 15:23:11 in Рабочий процесс

Произошел релиз комплексного обновления калькулятора ЖКХ http://www.fstrf.ru/calc-jkh/
— Добавлены 2х и 3х зонные счётчики электроэнергии.
— Произведён переход на «свежий» набор данных.
— Введен расчёт поставок твёрдого топлива.
— Введён расчёт сжиженного газа по нормативу.
— Бесчисленные мелкие изменения по визуализации информации и по тексту.
— Новый сплеш экран.
— Исправлены мелкие баги.

by CavinSmith

Блог прозрачно был перенесён на новый сервер, в связи с чем временно отключена загрузка изображений и создание галерей.
В ближайшие два-три дня возможны мелкие баги в работе блога — если заметите проблему — пишите на cav@cav.ru или skype:CavinSmith