Entity Framework – шесть способов выполнить объектный запрос

Должен вам сказать, что Entity Framework (EF) представляет собой непаханое поле для блогописательства. И в следующем году я планирую целую серию постов на эту тему. Выход EF анонсирован на февраль 2008 года, и учитывая его сложную судьбу, нам всем стоит держать кулаки за то, чтобы это событие не сорвалось. Потому что, после довольно детального изучения сабжа, я вам должен сказать, что EF это не просто ORM, это большой удар по разгильдяйству и бездорожью в разработке на .Net.
А пока, в качестве иллюстрации возможностей EF рассмотрим различные способы выполнения объектного запроса. Во всех случаях мы будем выполнять запрос, который должен вернуть объект класса Person из корпоративной базы Orgchart по его персональному идентификатору (PIN).
Первый способ, назовем его «классический». Для работы с объектами EF используется контекст, который представляет собой экземпляр класса, унаследованного от System.Data.Objects.ObjectContext. Такой класс (как и все классы объектов домена) генерируется визардом по EDM описанию. Для выполнения объектных запросов используется класс System.Data.Objects.ObjectQuery:

static void Test()
{
    // это значение для выборки
    int pin = 1840;
    // для работы с EF создаем ObjectContext
     using (Orgchart dataContext = new Orgchart())
     {
         //создаем запрос
         ObjectQuery<Person> query = new ObjectQuery<Person>(
             "select value p from Orgchart.Persons as p where p.PIN=@pin",
             dataContext);
         // добавляем параметр
         query.Parameters.Add(new ObjectParameter("pin", pin));
         // выполняем запрос (здесь мог быть foreach)
         Person p = query.First();
         if (p != null) Console.WriteLine("Name:{0}", p.LastNameRus);
     }
}

Все довольно очевидно. Сначала создаем контекст “dataContext”. Затем создаем запрос, передавая ему строку запроса на eSQL (entity SQL) и контекст, и передаем запросу параметр. Обратите внимание, что в запросе параметр казан с символом @, а в имени параметра этот символ не используется. Запрос исполняется при вызове метода First() (поскольку нам нужен только один экземпляр Person, а вообще тут мог быть foreach).

Второй способ аналогичен первому, но проще. Дело в том, что при создании класса контекста визард генерирует типизированные коллекции для каждого Entity Set в виде свойств этого контекста. Воспользуемся этим:

static void Test()
{
     // это значение для выборки
     int pin = 1840;
     // для работы с EF создаем ObjectContext
     using (Orgchart dataContext = new Orgchart())
     {
      // dataContext.Persons сгенерирован визардом  
         Person p = dataContext.Persons.Where("it.PIN=@pin", new ObjectParameter("pin", pin)).First();
         if (p != null) Console.WriteLine("Name:{0}", p.LastNameRus);
     }
}   

Здесь мы воспользовались методом ObjectQuery.Where() поэтому нам не надо указыать весь объектный запрос а только условие выборки. Кстати, форма записи «it.PIN», где it отсылает нас к текущему объекту выборки, а PIN это имя свойства этого объекта, пока (beta 3) нигде не задокументирована :).

Третий способ практически аналогичен второму, но использует другую реализацию ObjectQuery.Where(), которая в качестве параметра принимает лямбду:

Person p = dataContext.Persons.Where<Person>(c => c.PIN == pin).First<Person>();
if (p != null) Console.WriteLine("Name:{0}", p.LastNameRus);

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

Четвертый способ по своей сути является всего лишь альтернативной формой записи предыдущего, но это уже LINQ:

p = (from c in dataContext.Persons where c.PIN == pin select c).First<Person>();
if (p != null) Console.WriteLine("Name:{0}", p.GetFullName());

Чисто декларативный синтаксис. Указываем откуда выбрать, как и что. Красота.

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

var x = (from c in dataContext.Persons where c.PIN == pin select new { Name = c.LastNameRus, Pin=c.PIN }).First();
if (x != null) Console.WriteLine("Name:{0}", x.Name);

Вместо переменной типа Person мы получаем переменную var x, которая имеет свойства LastNameRus и Pin и ничего более.

Ну и наконец, последний, шестой способ. Он кардинально отличается от предыдущих пяти тем, что использует классы из пространства System.Data.EntityClient. В частности, EntityCommand и EntityDataReader. Я бы назвал это режимом обратной совместимости, потому что он возвращает нас в классический ADO.NET.
EntityConnection - это наследник DBConnection, EntityCommand – наследник DBCommand, а EntityDataReader – наследник DBDataReader. Схема работы классическая для ADO.NET: открываем соединение, создаем команду, передаем ей запрос, исполняем команду – получаем DataReader, читаем данные из ридера:

static void Test()
{
    // это значение для выборки
    int pin = 1840;
 // создаем соединение
    using (EntityConnection connection = new EntityConnection(@"metadata=.\Model1.csdl|.\Model1.ssdl|.\Model1.msl;provider=System.Data.SqlClient;provider connection string='Data Source=(local);Initial Catalog=Orgchart;Integrated Security=True'"))
    {
        // открываем соединение
        connection.Open();
        // создаем комманду
        EntityCommand command = new EntityCommand("select value p from Orgchart.Persons as p where p.PIN=@pin", connection);
        // добавляем параметр
        command.Parameters.Add(new EntityParameter("pin", System.Data.DbType.Int32)).Value = pin;
        // получаем reader, используя комманду
        using (EntityDataReader reader = command.ExecuteReader(System.Data.CommandBehavior.SequentialAccess))
        {
            if (reader.Read())
            {
                Console.WriteLine("Name:{0}", reader["LastNameRus"]);
            }
        }
    }
}     

Однако при всем при этом, заметьте, мы работаем не с БД и SQL, а с объектной моделью EF и eSQL. Но прямо скажем, не самый удобный способ из рассмотренных. Зачем это надо? Ну, наверно кому-то надо.

Ну а выводы?
По русской традиции, каждый делает выводы для себя сам.
По американской традиции, не каждый может сделать правильные выводы :), и поэтому summary:
- Entity Framework это ORM от Microsoft который мы ждем уже много лет;
- От прочих ORM его отличают по крайней мере две вещи: здесь есть LINQ, и он обратно совместим с ADO.NET

P.S. Мне был бы интересен ваш фидбэк, поскольку я собираюсь сделать еще несколько постов на тему практических вопросов использования Entity Framework. Интересна ли тема? Если да, то какие вопросы интересуют в первую очередь?

Антикарьера?

Дауншифтинг (англ. downshifting) - отказ от карьеры, жизнь для себя. А может это путь к настоящему успеху? Интересный взгляд на проблему в блоге "Профессия IT".
Рекомендую.

Это вам не небоскребы строить…

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

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

Безграничные возможности имеют обратную строну. Очень малую часть программ можно формализовать при помощи математического аппарата, а значит и автоматически генерировать, автоматически верифицировать, отыскивать ошибки и т.д. Как следствие этого проблема неопределенности. О программе нельзя сказать ничего определенного до тех пор, пока она не будет реализована! Программирование, это не детерминированный и эвристический процесс. Программу, обладающую фиксированным набором выходных характеристик всегда можно реализовать множеством различных способов. И это вносит своего рода piece of art в труд программиста и роднит его, если не с художником, то с исследователем.

Безграничные возможности и многовариантность путей реализации, это сама по себе проблема, когда программист – перфекционист начинает устраивать бесконечный рефакторинг своего кода. Или когда случается «недержание креатива» в дизайне, которое мы обсуждали здесь.

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

Безграничные возможности – это нарастающая как снежный ком сложность программных систем и весь ворох проблем с этим связанных.

В общем, как обычно, то что делает программирование таким привлекательным для использования, порождает и большинство проблем.
Бороться с этими трудностями пробовали разными способами. Один из них состоит в четкой регламентации всех аспектов деятельности, связанных с созданием программ. Это путь Unified Process. Четко определить все требования, четко их зафиксировать, четко проследить их реализацию и четко протестировать готовый продукт на соответствие требованиям. Что бы не говорили о UP, но несомненное и, наверное, главное его достоинство в том, что именно в его рамках удалось более менее четко описать подходы к проектированию программных систем, особенно, в части превращения требований в проектные решения. Но UP не мог решить всех проблем, даже после того, как из водопадного его превратили в итеративный. Вернее, мог, но за очень большие деньги. Печально, но факт – с повышением уровня зрелости UP проектные затраты начинают расти с катастрофической скоростью.

Со временем появился и другой путь для решения проблем разработки программ. Первоначально появился он в виде откровения XP, и за его шокирующей по началу атрибутикой смысл угадывался с трудом. А идея оказалась очень продуктивной. Суть в том, чтобы превратить проблемы в преимущества. Проблема в том, что требования меняются? - отлично, давайте будем менять их постоянно. Готовый продукт не соответствует потребностям? – хорошо, посадим заказчика рядом с программистами, пусть участвует в процессе. Сроки постоянно срываются? – не будем определять сроков, продукт всегда будет готов к использованию. Это кажется странным, но XP использует все характерные особенности программирования, которые отличают его от других видов инженерии. Ведь, правда, мы же не в бетоне кодируем, мы всегда можем вносить изменения в код. И программа начинает работать не перед самой сдачей. Написали функцию – компилируем, запускаем, проверяем - работает. Так почему это не показать заказчику. Методика называется «экстремальной» потому, что доводит до крайности вполне очевидные вещи. И это работает.

Хорошо. Но почему тогда XP не появилась раньше? Почему столько лет тысячи проектов успешно заваливались водопадным методом?
Говоря об XP мы часто забываем о том, что она базируется на самых передовых инженерных практиках в разработке софта, которые были созданы за предыдущие десятилетия. Я говорю о непрерывной интеграции, об автоматическом тестировании, рефакторинге и прочих вещах. Сами средства разработки сделали огромный шаг вперед. Почему Брукс в IBM не мог применять XP во время эпопеи разработки OS/390? Да просто инструменты не позволяли. Компиляция шла прогонами, прогон занимал несколько часов, а код предварительно вычитывали на наличие ошибок.

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

Вторая сторона процесса это образование бессчетного множества т.н. Agile методик разработки. Все они разнятся в деталях, но большинство из них полный отстой. И я объясню почему. Гибкость, привнесенная XP, является исключительно важным достижением. Гибкость, это возможность вносить изменения по ходу разработки, гибкость – это очень короткая обратная связь между заказчиком и продуктом, это возможность постоянно видеть, как выглядит создаваемый продукт. Но цена этой гибкости необычайно высока. Гибкость достигается комбинацией всех практик XP, которые дополняют и поддерживают друг друга. Кент Бек говорит о практиках XP:

«Чтобы обеспечить их эффективное применение на практике вы должны использовать их все одновременно».

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

Недавно прокатилась волна публикаций про Post Agile. Но правда без существенных последствий, как прокатилась, так и стихла. А серебряной пули как не было так и нет. Как нет и золотой методики. Ни CMMi, ни PMBook, ни RUP ни XP пока не могут гарантировать успешного исхода нового программного проекта просто самим фактом своего использования. Все в наших руках.

Итоги опроса "Какую методику разработки ПО вы используете"

Завершаю свой опрос несколько раньше срока, поскольку поток голосующих практически иссяк. Данные не претендуют на большую репрезентативность и объективность, но некоторую пищу для размышлений дают.
Всего в опросе приняло участие 86 человек, и поскольку в опросе была возможность давать несколько ответов, общее число ответов 105. Часто один человек одновременно участвует в нескольких проектах и эти проекты могут использовать разные методологии.
Таким образом у нас есть 105 проектов, и в среднем на одного человека приходится 1,2 проекта.

Традиционные, "тяжелые" методики используются в 15% проектов. Из них на долю MSF (Microsoft Solution Framework) приходится лишь 3%, а на долю RUP (Rational Unified Process) - 12%.
Гибкие методологии используются в 43% проектов. Extrime Programming используют 14%, и 29% предпочитают всевозможные менее экстремальные Agile методики.
Как ни печально, но 41% всех проектов не используют никакой методологии.

Признаюсь честно, последняя цифра оказалась для меня весьма неожиданной. Если учесть тот факт, что на части проектов вывеска Agile прикрывает полное отсутствие проектного управления, то получается, что около половины всей разработки находится в состоянии дремучего бардака.
Для микро-проектов, с числом программистов не более одного, можно сказать что организация процесса не имеет особого значения. Хотя и в этом случае без применения нормальных инженерных практик, таких как тестирование или анализ требований, вероятность получения результата будет стремится к нулю.
Я то думал, что времена, когда программистов усаживали писать софт не определив ни целей, ни требований, ни сроков, уже давно канули в лету. Ан нет.
Раз все так плохо, может мне стоит открыть консалтинговый бизнес по постановке процесса разработки. Не по аутсорсингу разработки, а именно по выстраиванию нормальной модели проектной команды и проектного процесса. Когда в команду приходит инструктор, и по ходу реального проекта помогает решать рабочие вопросы: требования, взаимодействие с заказчиком, коммуникаций внутри команды, интеграция, тесты, и т.д. и т.п., параллельно выстраивая Процесс в соответствии со спецификой проекта и потребностями клиента. То, что обозначается модным сейчас словом коучинг (от coach - тренер). Многочисленные agile евангелисты сейчас вплотную подбираются к такой модели бизнеса. Но почему только agile?

Google готовится к празднику...

Забавно наблюдать, как за последние двое суток менялся логотип Google:

сначала он стал таким:

потом таким:

затем вот таким:

и сейчас он выглядит вот так:


Похоже это еще не конец. Не зря же они стакан выкатили :)) Место для пятого логотипа пока свободно.

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

Программисты и рационализаторы погубили советскую марсианскую программу

В начале 70-х годов прошлого столетия между СССР и США разгорелась очередная космическая гонка, кто первым совершит мягкую посадку на Марс. Советскую марсианскую программу преследовали хронические неудачи. Из целой армады межпланетных станций только одной удалось совершить мягкую посадку, однако ни одной фотографии аппарат так и не передал.
Оказывается на аппараты марсианской серии впервые были установлены бортовые цифровые ЭВМ. И тут началось. Первая станция так и не смогла покинуть околоземную орбиту:

"...Однако на траекторию полета к Марсу станция не перешла, так как не произошло повторного запуска двигателя разгонного блока 11С824 (блок Д). Как выяснилось при разборе неудачи, в бортовую вычислительную машину было введено ошибочное значение времени запуска двигателя блока Д. Из-за ошибки в разряде двигатель должен был запуститься не через несколько десятков минут, как предусматривала программа полета, а через полторы сотни часов. Аппарат с так и не сработавшим блоком Д остался на низкой околоземной орбите. В сообщении ТАСС АМС была названа очередным спутником "Космос 419". Через два дня после запуска, 12 мая 1971 года аппарат вошел в плотные слои земной атмосферы и сгорел."

Вторая станция погибла тоже из-за программной ошибки:

"Официально она получила обозначение "Марс-2". Полет этой станции проходил вполне нормально, блок 11С824 отработал успешно и перевел аппарат на траекторию полета к "Красной планете". В ходе полета 17 июня, 20 и 27 ноября проводились коррекции траектории полета АМС. 27 ноября 1971 г. после проведения третьей коррекции перед отделением СА начала работу бортовая ЦВМ с целью выработать уставки на вход спускаемого аппарата в атмосферу Марса. Однако сработала БЦВМ неправильно, в СА были введены ошибочные уставки. Виной тому была программная ошибка в БЦВМ. Как выяснилось потом при разборе неудачи, "Марс-2" шел к "Красной планете" очень точно. Ориентация до отделения СА от орбитального блока практически не отличалась от расчетной ориентации СА для перевода на траекторию попадания. В этом случае до отделения спускаемого аппарата и его закрутки вокруг продольной оси работа системы ориентации станции не требовалась. Однако из-за ошибки в программе БЦВМ восприняла ситуацию неправильно и сформировала уставки, предусматривающие нерасчетную ориентацию АМС перед отделением. Через 15 мин после отделения на СА включилась твердотопливная двигательная установка. Она все-таки обеспечила перевод спускаемого аппарата на траекторию попадания на Марс. Однако угол входа в атмосферу оказался больше расчетного. Спускаемый аппарат слишком круто "зарылся" в марсианскую атмосферу, из-за чего не успел затормозить на этапе аэродинамического спуска. Парашютная система уже ничего не смогла сделать. 27 ноября 1971 г. СА, "прошив" атмосферу "Красной планеты", разбился о поверхность Марса в точке с координатами 4° с.ш. и 47° з.д. (Долина Нанеди в Земле Ксанфа). В сообщении ТАСС, посвященном "Марсу-2", говорилось, что на Марс впервые доставлен "вымпел с изображением Герба СССР". И это - правда: на борту СА действительно был закреплен вымпел. В делах космоса ТАСС тогда не врал. Вымпел вместе с "обеспечивающими доставку средствами", или как их назвал ТАСС - "капсулой", весил несколько сот килограммов. Никакой научной ценности жесткая посадка "вымпела" не имела."

Надо полагать, тестировщиков у них не было вообще. Но заметьте, менеджеры проекта оказались на высоте. Размазанный в лепешку спускаемый аппарат оказался "вымпелом с Гербом СССР". Кто нибудь что нибудь имеет против Герба СССР?
В общем, первые экспедиции тестировали программное обеспечение БЦВМ. Дальше казалось, все пойдет нормально. Но не тут то было. В дело вмешались народные рационализаторы.

"Во время комплексных электрических испытаний на космодроме на станции 3МП №51 произошел отказ в согласующем устройстве БЦВМ. При анализе неисправности выяснилось, что причиной отказа стало изменение технологии производства микросхем, изготавливаемых в Воронеже. С целью увеличения выпуска этого типа радиодеталей было предложено рационализаторское предложение. Оно заключалось в замене напыляемого в микросхемах золотого слоя на алюминиевый. Казалось, при этом характеристики изделия не ухудшались Однако через полгода-год в результате старения на алюминиевом слое образовывались раковины, что служило причиной выхода элемента из строя. Эти микросхемы использовались на всех аппаратах М-73. Анализ ситуации показал, что велика вероятность отказа БЦВМ по вине микросхем и вследствие этого - выход станций М-73 из-под контроля еще на трассе перелета к Марсу."

Я просто в ауте. И что вы думаете, они остановили программу и поменяли бракованные микросхемы? Ничего подобного. Они отправили их так как есть.

"В ходе полета станции отказали два из трех каналов БЦВМ. Причина была в той самой микросхеме. В связи с этим вторую коррекцию при подлете к "Красной планете" провести уже не удалось. 10 февраля 1974 г. станция подошла к Марсу. Однако бортовая вычислительная машина не выработала уставок на торможение и переход на орбиту ИСМ, корректирующая двигательная установка АМС не включилась. Поэтому в 18:34 ДМВ аппарат пролетел на высоте 1844 км над средним радиусом Красной планеты (5238 км от центра). Единственное, что он успел сделать, это по команде с Земли в 18:32:41 ДМВ включить свою фототелевизионную установку с короткофокусным объективом "Вега-3МСА"."

И так далее. Одна за другой на станциях отказывали БЦВМ, радиокомплексы и прочая аппаратура. Все цитаты взяты из материала в журнале "Марсианское время".
А в США, тем временем, миллиарды тратились на создание стандартов разработки софта (MIL-STD-498) и управления качеством (MIL-Q-9858). Результаты, как говорится, на лице. Американские марсоходы никак не хотят ломаться и продолжают ползать по марсианским пустыням, а у нас с 1971 года ни одна марсианская миссия так и не достигла успеха.

Их надо знать в лицо

Кто не слыхал фамилий Страуструпа, Дейкстры или Кнута? А как выглядят столпы програмирования? Можно посмотреть здесь.
Алан Кей, Джеймс Гослинг, Гвидо Ван Россум, Грэди Буч, Мартин Фаулер (особенно Мартин) личности не только не заурядные в профессиональном плане, но и оказывается весьма колоритные :).

P.S. Отпустить бороду. чтоль? Боюсь, только, не поможет уже...

Будут ли следующие версии Windows написаны в Бангалоре?

Новость о том что "Infosys establishes dedicated Microsoft facility with more than 400 seats" меня не на шутку встревожила.
Неужели все так плохо, и Microsoft поступилась своими принципами и начала офшорить разработку в Индию?
К счастью слова "development" там пока нет. Речь идет о развертывании на площадке в Бангалоре системы BI для анализа пользовательских фидбеков, сайта для download-ов и центра тестирования.
Но тем не менее, это все критически важные для бизнеса Microsoft сервисы и Infosys сумела их убедить в том, что она способна обеспечить надлежащее качество. И если у них все получится, то кто знает где будет написан код следующей версии Windows, в Редмотде или в Бангалоре.
У нас любят повторять что Россия не должна конкурировать с Индией на рынке дешевого аутсорсинга, Россия должна конкурировать на рынке высокоинтелектуальных услуг. Должна конечно, но пока не может.

Вчера вышел Parallel FX CTP

"Даешь параллельный код в программерские массы" - примерно такой лозунг бросил Херб Саттер (Herb Sutter) в своей статье "Программное обеспечение и параллельная революция" почти два года назад. И нам стало ясно, что в недрах Microsoft Research готовится что то интересное. Если раньше параллельное программирование было уделом суровых парней с широкими лбами в лабораториях Intel, то сейчас, стараниями того же Intel-а мы все стоим перед фактом, что без распараллеливания кода все наши новые программы окажутся на помойке.
Но близок тот день, когда любой рязанский паренек вместо

for (int i = 0; i < 100; i++)
{ 
  a[i] = a[i]*a[i]; 
}

станет писать

Parallel.For(0, 100, delegate(int i) { 
  a[i] = a[i]*a[i]; 
});

и не будет делать круглые глаза при словах декларативный параллелизм.
А близок он по тому, что уже вышел первый CTP .Net библиотеки Parallel FX. Как пишет в своем блоге Джо Даффи, Parallel FX теперь можно взять здесь и потрогать руками.
В будущем он войдет в состав .Net Framework в виде библиотеки System.Concurrency и расширений Parallel LINQ, и, я надеюсь, станет таким же привычным как System.Threading или System.Net.
Для тех кому интересно, что там внутри - ссылки:
"Оптимизация управляемого кода для многоядерных компьютеров" - описание возможностей Parallel FX в MSDN Magazine (на русском).
"Параллельный LINQ: Выполнение запросов на многоядерных процессорах" статья о PLINQ в MSDN Magazine (на русском).

Платформа 2008. Keynote.

Только что посмотрел WEB трансляцию открытия Платформы 2008. К сожалению очень плохо было видно слайды (практически ничего не разобрать). Это упущение режисера трансляции, потому что взять крупный план экрана была возможность.
Открывал конференцию Биргер Стен (Birger Steen), генеральный директор Microsoft в России, а основной доклад делал Eric Rudder: Senior Vice President, Technical Strategy. Что-ж, статус мероприятия год от года повышается.
Рассказывали и показывали много разного.
Что зацепило?
Прежде всего технологии виртуализации. Очень впечатлило. Не только виртуализация серверов, но и технология SoftGrid, позволяющая запускать любые версии ПО в виртуальном окружении, и создавать для этого перемещаемые профили, интегрированные с AD. Я далек от тонкостей технологии виртуализации, но похоже она вступает в пору зрелости и сегодня способна давать реальные преимущества и IT и бизнесу в целом.

Второе, возможности языка разметки XAML и продуктов его использующих - WPF, Silverlight. Весьма позабавила презентация Александра Ложечкина: шахматы на Silverlight запущенные в Firefox под Linux, в которых за белых играет код на JavaScript а за черных код на .Net. Победили конечно черные :)

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

Энтузиастам на заметку. Несовместимость CTP версий SQL 2008 и VS 2008

В последние годы Microsift активно использует практику выпуска Community Technology Preview (CTP) версий своих продуктов, задолго до выпуска официальных релизов. Это позволяет энтузиастам и ISV ознакомиться с продуктами на ранних стадиях, а самой Microsoft получить необходимый feedback и бесплатных тестировщиков.
Невсегда в этих CTP все гладко. Вот информация для тех, кто использует CTP версии SQL Server 2008 и Visual Studio: некоторые версии этих продуктов несовместимы друг с другом, а нектоторые не поддерживают определенные фичи. Масштаб бедствия выглядит примерно так:

В общем, если что-то, не ломайте моск и клавиатуру - это CTP, никто и не обещал что все будет работать.

Более подробная информация в блоге ADO.NET team

Нет пророка в своем отечестве

Рсссия должна развивать в первую очередь свой внутренний рынок, а том числе технологический. Альтернатива Индийской модели оффшора - экспорт технологий в Китай.
Рынок IT сможет вырасти на порядок, если компьютеры перестанут быть уделом избранных. Кто при этом победит Sony или Microsoft? DVD телевизоры или персональные компьютеры? А еще Windows vs Linux, все это в интервью Александра Степанова.
Признаюсь, с большим скепсисом начинал читать эту статью. Программисты (а Степанова я считаю в первую очередь программистом) бывают очень наивны, когда начинают рассуждать на темы развития компьютерной отрасли и рынка в целом. Оказалось очень интересно и очень актуально.

Интересная вакансия в Дубне (С++)

У нас в Дубне какое-то время вообще не было никаких вакансий. Но вот, наконец, появилось кое что интересное.
Итак открыта вакансия C++ senior developer в Дубне. Нужно:
- от 3 лет программирования С/С++
- опыт программирования под *nix. Знание UNIX shell (bash, make, etc)
- опыт кросс-платформенного портирования программ
- понимание технологий реализации компиляторов
- хороший английский (быть готовым к интервью с западным заказчиком)
Подробеннее ничего сказать не могу, не мой проект.
Это, так сказать, для души.

Теперь о материальном.
Традиционно для Люксофта размер компенсации обсуждается индивидуально. Уровень зарплат для Дубны можете помониторить в интернете (обсуждали недавно на rsdn). По уровню требований можно рассчитывать на самую верхнюю планку.
Отличный офис, спокойная обстановка, хорошие условия для работы и для отдыха. График свободный. Соц-пакет стандартный: медстраховка, бассейн, стоматология. Зарплата белая, отпуска, больничные по ТК. Для иногородних релокационный пакет. Релокация это оплата билетов (и семье) и перевозки вещей (контейнер, фура), встреча на вокзале, подбор аренды квартиры.
Помимо этого, в Дубне есть ипотечная программа и субсидия при покупке квартиры - 10% от стоимости (пока только для Люксофт).
В общем, нужен гуру в плюсах с неплохим английским. Вакансии интересна для ребят из регионов или для тех, кто разочаровался в столичной жизни :))
Кому интересно кидайте резюме. Можно через luxoft.ru, можно прямо мне на мыло: srozovik[ at ]gmail.соm, я закину прямо по назначению.
Предложение действительно до 1 декабря.

Проблемы построения объектных моделей.

Самое сложное в проектировании программных систем - это проектирование :)
Вот буквально вчера нарыл интересную статью на эту тему, на абсолютно не профильном сайте: "ОСВОБОЖДЕНИЕ УЗНИКОВ ОПЕРАТОРА "IF"
Прочитал с интересом. Досталось там и Гради Бучу за его примеры из книжки "Объектно-ориентированный анализ и проектирование с примерами приложений на C++". И вобщем-то поделом досталось. В защиту классика скажу лишь, что примеры в книжке призваны иллюстрировать те или иные понятия и принципы, а с прикладной точки зрения они вполне могут быть не очень удачными. Так и не в этом их цель.
Весьма смачно проилюстрированы проблемы, которые возникают при построении развесистых иерархий классов.
Правда, под конец статьи авторы свалились в частности, и выводы у них получились тоже достаточно частные. На самом деле, для решения описанных в статье проблем существуют хорошо известные методики, такие как проектирование на онове распределения обязанностей и GRASP шаблоны, модели входов выходов, модели потоков данных и т.д.

Сегодня день рождения А.А.Степанова

Сегодня день рождения Александра Александровича Степанова - наиболее известного русского программиста.

Степанов автор понятия обобщенного программирования (всеми нами любимые generic-и) и знаменитой библиотеки STL.
Кстати, в 1995 Александр Александрович получил Dr.Dobb’s Excellence In Programming Award за создание STL. Он разделил премию с Линусом Торвальдсом.
Жаль, что всего этого добиться он смог не у себя на родине, а лишь уехав в США.

Опрос - используемые методики разработки.

Уже довольно давно на Blogger-е появилась возможность создавать опросы. Вот и я решил попробовать. Впрос очень интересный, касается того какие методолгии в разработке софта сейчас более распространены. Поскольку аудитория блога состоит в основном из практикующих программистов, то результаты должны быть интересными не только для меня.
К сожалению, за время пока я боролся за правильное отображение контрольчика для голосования, опрос "уже начался" и мне не удалось подправить варианты выбора. Варианты RUP и MSF выбирайте если у вас методология "похожая" или основанная на этих базовых методиках.
Опросник в правом сайдбаре. Голосование продлится до конца года. Подождем результатов.

Project Estimation

Прочитал сегодня в блоге у Элдара Мусаева про
"Оценки софтверных проектов или равно ли целое сумме слагаемых?". Захотелось подискутировать на эту тему с коллегой из Рэдмонта, но объем комментария вылез за общепринятые размеры и тянет на отдельный пост :).
Элдар высказывает популярную в среде разработчиков точку зрения о том что, во первых разработчики не любят давать оценки. Цитата:

"Нет-нет, я понимаю, что в ожиданиях менеджмента, вы как Кассандра должны совершенно точно предсказать будущее, причем в отличие от Кассандры сделать это не в пример более оптимистично, как того требуют business tenets (не знаю, как эта штука переводится, ну, что-то вроде морального кодекса молодого строителя коммунизма – по ней у нас каждый год обязательный тренинг). В общем, все понимают, что это сложно, но ваши пророчества должны быть «good enough!» со всех точек зрения."

А во вторых, точные оценки дать весьма сложно. И далее автор подводит под это дело математическую базу (цитата):

"То есть, если вы разбили проект всего на две части, оценили каждую с 80 процентами вероятности, то сумма имеет «надежность» всего лишь в 64 процента! Попробуйте в качестве домашнего задания, что получится если проект разбить на десять шагов?"

С тем что оценки давать сложно я согласен. А вот с тем что математика показывает, что предварительные оценки вообще бессмысленны можно поспорить.

Потому что математика, и теория вероятности в частности, к дисциплине "project estimation" имеет мало отношения. Здесь гораздо лучше математических работают различные эмпирические методы. Существуют такие веселые методики, как "оценка по аналогии" или "экспертная оценка". Просто приходит умный дядька, смотрит на проект и говорит: "этот тянет на 26 человеко месяцев". И все. В таких методиках главное найти этого самого дядьку.
И, кстати, если в проекте не велика инновационная составляющая, или иными словами, проект достаточно типовой, то оценить его не так уж сложно. Есть Early function Points, есть Use Case Points, есть COCOMO, и они в умелых руках дают неплохие результаты.
Другой важный момент. Если менеджер на старте проекта требует от вас точных оценок и стопроцентных гарантий, это говорит только о том, что это не очень хороший менеджер. Причем он об этом знает и ему от этого становится страшно.
В нормальных управленческих практиках, на стадии анализа никто не требует точных оценок. Оценка плюс минус 50% считается нормальной и достаточной для планирования бюджета проекта. Причем по моей практике, в результате точность оценки оказывается выше чем +-50%.
Если же проект инновационный и в нем велика неопределенность, то такие проекты обычно выполняются по схеме time & materials. Т.е. выделяют кучу денег (сначала небольшую) и говорят: "за эти деньги мы будем стремиться достигнуть таких-то целей". По прошествии времени, смотрят достигнуты ли поставленные цели. Если да, то выделяют новую кучу денег, ставят новые цели. Если нет, закрывают лавочку. Все мы читали новости наподобие: "НАСА выделяет 20 млн долларов на программу разработки материалов для космического лифта". Как они посчитали, что надо именно 20 лимонов? А никак. Они поставили цель "сделать нить, которая не порвется при длине в 20 километров". Получится, выделят еще денег на продолжение работ. Нет, - закроют проект. В этом случае оценки вообще не важны. Важнее хорошая организация, четкая постановка целей и управление рисками. По таким принципам, кстати, работает XP и другие Agile методики.
И что в итоге?:
- оценивать проекты можно, но для этого нужно умение.
- точность оценки не так уж важна, просто надо уметь пользоваться этой оценкой
- методики есть, и не смотря на то что они эмпирические, они работают.

Зима, программер торжествуя...

За ночь выпало много снега. Утром был мороз -7*С. И все-же один человек приехал на работу на велике.

Реально крутой парень.

Карьерный рост - анкета

Судя по поисковым запросам к блогу, нашего брата IT-шника больше всего мучают карьерные вопросы а вовсе не полиморфизм и лямбда выражения. На ITBlogs Михаил Елашкин предлагает заполнить анкету о карьерных ожиданиях.
Предлагаю присоединиться и заполнить, а потом вместе посмотрим на портрет озабоченного карьерным ростом программиста :)

Наследие WinFS

Интересный пост: Daniel Kornev - WinFS Long Story: Microsoft Sync Framework и описание синхронизации данных между файловыми системами. о том, что выросло на обломках WinFS. А выросло кое что интересное, например, Microsoft Sync Framework.

Beyond Architecture

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

Любое проектное решение должно приниматься осмысленно. Мы привыкаем "выделять слой доступа к данным, слой бизнес логики..." и т.д. просто потому, что делаем это всегда. А ведь это - проектные решения, и они были в свое время придуманы для решения совершенно определенных проблем и задач. Всегда сказав "а", говори "б". Сказав "мы выделяем слой ...", говори самому себе "для того, чтобы...". Это первое.

Второе. Никогда не следует забывать о том что программирование по своей природе "мягкая" (soft) область инженерной науки. Здесь всегда существует несколько вариантов решения проблемы. А проектные решения, это всегда компромисс. Любое решение имеет плюсы и минусы. Мы очень охотно оцениваем плюсы и почти всегда забываем рассмотреть минусы. А в каждой конкретной ситуации важность, или вес того или иного аспекта (плюса или минуса) может быть разной.
Просто придумать хороший дизайн системы, опереться на паттерны проектирования, сделать "все как надо" это еще пол дела (или вернее, пол беды :). Гораздо сложнее и важнее, увидеть слабые стороны своего решения, найти ему альтернативы, выявить все плюсы и минусы для каждой из альтернатив.

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

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

В плену правильных идей

Мы живем и работаем в плену стереотипов. Все мы знаем как делать "правильные приложения". Слои, уровни, шаблоны проектирования... Вот, например:

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

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

Или другой пример. Надо построить квартальный отчет по продажам, и для этого используем класс Sale, экземпляры которого, представляют продажи в бизнес логике приложения. За квартал набегает пара десятков тысяч продаж, и естественно, сервер приложений ложится на вычислении квартального отчета. Хранимая процедура в БД справилась бы с этой работой за несколько секунд, но "архитектура системы запрещает обращения к БД из слоя бизнес логики". К счастью догматы архитектурной веры позволили создать в системе бизнес объект "Квартальный отчет по продажам", который по всем архитектурным правилам, посредством DAL, и с прочими приседаниями, получил данные из шустрой хранимой процедуры, и таким образом, весь сервер приложений был спасен от неминуемой гибели.

Мораль. Не давайте шаблонам управлять своими мозгами. Должно быть все наоборот. Оставайтесь в меру беспринципными, когда это может пойти на пользу делу. И главное: "Do simplest thing that could possibly work" (с)К. Бек.

Extreme Programming Essentials

Недавно обнаружил в загашниках интересный документ "Регламент разработчика XP". В 2004 году мы решили начать разработку очередного проекта по методологии XP. А поскольку большинство наших программистов знали об XP только то, что кодировать надо вдвоем, я написал небольшой документ, в котором на пяти страницах постарался изложить всю суть этой методологии, а также краткий свод требований для повседневной работы. Сегодня я перечитал этот док, и понял что ничего не могу в него ни добавить ни убрать. Значит он выдержал проверку временем. Итак, здесь выжимка из всего того, что должен знать каждый программист об XP.

Extreme Programming Essentials

Что такое XP


Экстремальное программирование (eXtreme Programming) – это методика разработки программного обеспечения, которая представляет собой набор принципов и практик, направленных на быстрое создание программного продукта, в максимальной степени удовлетворяющего потребности заказчика. Прилагательное «экстремальное» обозначает, что данная методика предполагает максимально интенсивное использование всех входящих в нее практик.

Основные ценности XP:

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


• Простота (simplicity). Всегда старайтесь решить задачу самым простым способом из всех возможных. Сделай самую простую вещь, которая способна работать (Do simplest thing that could possibly work).


• Обратная связь. Чем раньше вы сможете получать отзывы от пользователей, тем лучше вы сможете удовлетворить требования заказчика.


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

Основные практики XP. Ниже перечислены 12 практик XP, которые должны использоваться комплексно и с максимальной интенсивностью. Поскольку каждая из этих практик опирается на другие и дополняет их.

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


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


3. Парное программирование. Любой код разрабатывается двумя программистами.


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


5. Рефакторинг. Улучшение кода путем его переработки. Один и тот же код не должен встречаться в нескольких местах системы (once and only once).


6. Коллективное владение кодом. Каждый из разработчиков отвечает за работоспособность всей системы.


7. Постоянная интеграция. Новый код постоянно интегрируется в систему, и система постоянно поддерживается в работоспособном состоянии.


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


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


10. 40 часовая рабочая неделя. Разработчики не должны работать сверхурочно, так как от этого снижается производительность и качество работы.


11. Стандарты кодирования. Разработчики придерживаются общих стандартов кодирования для облегчения понимания кода.


12. Метафора системы. Простая аналогия, доступно и понятно описывающая предназначение и внутреннее устройство системы.

Взаимодействие заказчика и разработчика.

Методология XP определяет две роли в процессе разработки: заказчик и разработчик.

Методология XP построена на принципах взаимодействия и тесной обратной связи между этими ролями. Предполагается, что заказчик активно участвует в процессе разработки с самого начала.

Обязанности и привилегии роли заказчика:

• Заказчик определяет функциональные требования к системе через «пожелания заказчика»


• Заказчик определяет приоритеты в реализации тех или иных требований.


• Заказчик определяет дату выпуска системы.


• Заказчик совместно с разработчиком определяет общий план разработки системы, а также план каждой итерации (для этого определяется перечень пожеланий, реализуемых в ходе итерации)


• Заказчик принимает результаты разработки отдельно по каждому из пожеланий.


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

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

Обязанности разработчика:

• Разработчик совместно с заказчиком определяет план разработки системы и планы каждой итерации.


• Разработчик определяет дизайн системы, максимально соответствующий требованиям заказчика.


• Разработчик информирует заказчика о возможных технических проблемах, или о возможных последствиях в ходе реализации тех или иных пожеланий заказчика.


• Разработчик оценивает затраты ресурсов на реализацию того или иного из пожеланий заказчика.


• Разработчик реализует пожелания заказчика в функционале системы.


• Разработчик информирует заказчика о ходе выполнения проекта, о возникающих проблемах и (или) отклонениях от графика.

До начала разработки заказчик совместно с разработчиком выполняет сбор требований, планирование и разработку общего дизайна (фаза анализа или нулевая итерация).

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

В ходе реализации пожеланий разработчики решают все возникающие вопросы с представителем заказчика.

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

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

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

Пожелания заказчика должны быть такими, чтобы их можно было реализовать за 2 – 4 дня разработки. Более крупные пожелания должны быть разбиты на несколько более мелких (конкретизированы).

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

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

Планирование итерации

Разработка ведется итерациями. Продолжительность 2-3 недели. В начале каждой итерации выполняется планирование.

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

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

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

Разработка функционала.

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

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

Разработчик должен стремиться реализовать пожелание заказчика максимально простым способом (Do simplest thing that could possibly work). Не следует делать никаких предположений относительно будущей модернизации кода, если это прямо не вытекает из имеющихся в наличии пожеланий заказчика. Разработчик должен руководствоваться правилом «Это нам не понадобится» YAGNI (You Aren't Gonna Need It), относительно любой функциональности, не описанной в текущих пожеланиях заказчика.

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

В ходе разработки необходимо проводить постоянный рефакторинг кода, с целью повышения его надежности и простоты. Разработчик должен придерживаться правила трех О: “Once and Only Once”, что значит, избегать дублирования кода.

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

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

Для разработчика определяется следующий регламент действий по реализации каждого пожелания заказчика:

• Для удобства, в случае, когда Solution продукта велик, разработчик создает локальный solution, в который он включает проекты, необходимые ему в разработке.


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


• Для каждой задачи параллельно разрабатывается модульный тест и исходный код (предпочтительно разрабатывать сначала тесты, а затем код). Необходимо добиться срабатывания модульного теста.


• Модульный тест включается в состав общего плана тестирования, и проверяется срабатывание всех модульных тестов системы в тестовом solution продукта. Если какие либо из тестов перестали срабатывать, разработчик должен выяснить причину, и внести необходимые изменения в код системы, не зависимо от того, кто разрабатывал этот код. В случае затруднения разработчик может призвать на помощь автора кода. В любом случае разработчик должен уведомить членов команды о внесенных изменениях.


• Добившись срабатывания всех модульных тестов, разработчик может приступать к внесению нового кода в VSS (интеграции). Процедура интеграции следующая. Сохранив изменения в VSS (check-in), разработчик должен на специально выделенной для целей интеграции машине взять последнюю версию исходных кодов системы, собрать тестовый и основной solution системы и выполнить полный набор модульных тестов. Если какие либо из тестов не выполняются, следует либо выявить и устранить ошибки (не зависимо от того, к какой части кода системы они расположены) и добиться срабатывания тестов, либо откатить в VSS свои изменения. При необходимости разработчик должен проделать дополнительные действия (развертывание конфигурации импорт – экспорт прикладных данных и т.п.) необходимые для того, чтобы на интеграционной машине была развернута работоспособная, последняя версия разрабатываемого продукта.


• В случае если система оказывается в неработоспособном состоянии, ответственность за это лежит на том, чьи изменения привели к ошибке (а не на том, в чьем коде обнаружена ошибка).

В рамках команды проекта проводятся ежедневные короткие совещания (stand-up meeting), на которых разработчики рассказывают друг другу о проделанной за прошлый день работе, имеющихся проблемах и планах на текущий день. Вопросы по реализации конкретных пожеланий заказчика и решении возникающих проблем обсуждаются в частном порядке с участием заинтересованных лиц вне рамок данного совещания.

Безумно гибкая разработка...

В блоге Элдара Мусаева весьма занятный пост Новая agile методика разработки софта - AIM. О том, почему когда дела идут все хуже, пресс релизы звучат все громче.

Блогу год

Как-то незаметно проскочила "знаменательная дата" :)
Есть повод поговорить о статистике. Итак, пятерка самых популярных постов.
1. "Золотой век русского программиста", что в общем-то не удивительно.
2. "Собеседование, вопросы на засыпку" - к великому моему сожалению. Этот же пост лидер по поисковым запросам. У меня есть много чего интересного рассказать и про собеседования и про вопросы по C#, но мне не очень хочется разрабатывать эту "золотую жилу".
3. "Xml serialization" - с этой штукой нам пришлось плотно поработать еще на проекте "Бизнес монитор" в "Галактике" в 2004 году. В статье я лишь собрал все до кучи и адаптировал под FW 2.0
4. "Web сервис и протокол HTTPS (SSL)" - один из первых постов, а на самом деле это немного переработанная инструкция по адаптации web сервисов к работе по HTTPS, которую я написал для наших программистов устав, объяснять все "на пальцах". Пост содержит некоторые неточности, до которых никак не дойдут руки.
5. "Обзор архитектуры Windows Communication Foundation..." - это перевод статьи из MSDN и первый пост в блоге. Было много свободного времени, болел, и я просто попытался совместить полезное с полезным :) - изучение WCF и практику в английском. За практику в английском получил, к стати, довольно язвительный комментарий.

С годовщиной.
Спасибо Вам всем!

Восход и закат CORBA

Весьма поучительная статья "Восход и закат CORBA".
Для тех кто, не застал эти времена поясню. CORBA - Common Object Request Broker Architecture - архитектура и набор спецификаций для распределенного взаимодействия приложений, продвигаемая консорциумом OMG.
Поддержка CORBA появилась в Delphi 3 (если не ошибаюсь), и при настойчивых попытках разобраться в этой технологии меня всегда поражала запредельная ее сложность. Тогда я думал, что просто недостаточно квалифицирован для такой продвинутой технологии, как CORBA.
В качестве своего ответа OMG, Microsift создала DCOM. А Sun для Java - свою знаменитую EJB. И CORBA тихо загнулась. Еще до того как появились SOAP и web сервисы. Загнулась из-за своей сложности, многословности, из-за бюрократизма в OMG.
Со многими проектами происходит такое. В некоторых мне самому довелось поучаствовать (Ranet - привет :). Но провал такого масштаба, когда угроблены миллиарды, когда участвовали компании с мировыми именами, когда, наконец, сам провал занял более десятка лет... Почитайте, очень поучительно.

F# будет включен в состав .Net

Как сообщает Joe Daffy в своем блоге, семейство языков .Net пополнилось: "Welcoming F# to the family".
Вице президент Microsoft Developer Division S. Somasegar анонсировал новый функциональный язык, созданный в недрах Microsoft Research.
Soma[segar] говорит:

"One of the important themes in programming languages over recent years has been a move to embrace ideas from functional programming."

И мы видим это на примере C#. Последние изменения в C# пришли именно из области функционального программирования (анонимные делегаты, лямбда выражения, LINQ). Joe Daffy говорит о том что F# упростит построение параллельных программ.
Похоже MS всерьез повернулась лицом к функциональному программированию:

"This is one of the best things that has happened at Microsoft ever since we created Microsoft Research over 15 years ago." (Somasegar)

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

А пока несколько code snippets на F#:

let task1 = async { return 10+10 }
let task2 = async { return 20+20 }
Async.Run (Async.Parallel [ task1; task2 ])

.....

let AsyncHttp(url:string) =
   async {// Create the web request object
          let req = WebRequest.Create(url)

          // Get the response, asynchronously 
          let! rsp = req.GetResponseAsync()

          // Grab the response stream and a reader. Clean up when we're done
          use stream = rsp.GetResponseStream()
          use reader = new System.IO.StreamReader(stream)

          // synchronous read-to-end
          return reader.ReadToEnd() }

...

Async.Run 
  (Async.Parallel [ AsyncHttp "http://www.live.com"; 
                    AsyncHttp "http://www.google.com"; 
                    AsyncHttp "http://maps.live.com"; 
                    AsyncHttp "http://maps.google.com"; ])

Выглядит интересно.

Жили были...

Недавно наткнулся на очень интересный блог, название которого собственно так и расшифровывается - "Жили были". Автор, просто не реальный человек. С далекого тихоокеанского побережья Британской Колумбии он неспешно рассказывает об истории становления и распада советской компьютерной (и не только) индустрии в преломлении своего личного опыта. Начало его истории здесь. Каждый пост сопровождается зарисовкой из жизни далекого далека, о том, например, как хорошо бывает вздремнуть часок с утра на бережке Тихого океана под кустом цветущего шиповника перед началом трудного рабочего дня. А для того, чтобы читатель не решил, что все это бред воспаленного воображения, каждый пост сопровождается фото/видео материалами :)
В общем, все очень живо, интересно и увлекательно. Вот, например, 90-ый год:

Немецкая частная инжиниринговая компания принимала нас душевно. Годдарт Питерс, баварский барон, мультимиллионер, инженер, гонщик и хозяин компании устроил состязание между РИПАКом (под моим управлением) и IDEAS (его сотрудники). Я победил с огромным отрывом, решив тестовые задачи за два часа на РИПАКе, установленном на их VAXе. Его ребята представили результаты только на следующий день. Более того, решалка в IDEAS оказалась несовершенной - элемент для моделирования стенок балок был несвободен от ложного сдвига. Немцы ошиблись на 30%, что я легко доказал. Эффект моей победы был очень силен.

Я вот только одного не пойму. IDEAS использовал для расчетов BMW, а РИПАК-ом, вроде бы пользовались на ВАЗе. Так почему же конечный результат у нас такой убогий?
Впрочем, это вопрос уже не к автору блога.

Релакс

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

Стартапы среди нас.

Когда в посте "Золотой век русского программиста" я сокрушался по поводу слишком малого количества системного и прочего "мозгоёмкого" софта, производимого в России, я вовсе не думал о таких предвыборных извращениях как Российская ОС для российских школ. Я думал, к примеру, о технических комитетах W3C и OASIS в которых будут работать представители наших компаний наряду с парнями из BEA, IONA, Sun и других. А такие компании, как известно, вырастают из стартапов.

А стартапы есть таки, и причем, прямо среди нас. Вот вчера, обнаружил один буквально в пяти минутах ходьбы от своей квартиры :) Ну, вернее обнаружил я его в Интернете, представляю: Pawlin Technologies молодая фирма из Дубны. Занимаются искусственным интеллектом (AI) и нейросетевыми технологиями, а вернее различными практическими применениями этих технологий (обработка изображений, распознание образов и т.д.). Ребята, выходцы из МФТИ и Физикона, теперь пытаются продвигать чертовски интересные вещи. Надеюсь, все у них получится.

Кстати, у них открыты вакансии программистов и (внимание!) научных сотрудников. Предлагают они и удаленную работу.

Смените фамилию

Представьте себе, вы приходите устраиваться на работу в компанию, успешно проходите все интервью, но в отделе кадров вам говорят: "К сожалению мы не можем вас принять. У нас уже есть сотрудник с такой фамилией именем и отчеством, и наша корпоративная система не позволяет добавить еще одного с такими же инициалами. Вы можете прийти позже, если смените фамилию." Звучит как анекдот, не правда ли?
Есть у нас корпоративная система, тесно интегрированная в Microsoft Project Server 2003. Так вот, в БД Microsoft Project Server 2003 в таблице, хранящей сотрудников Enterprise Resource Pool (т.е. всех сотрудников компании) есть unique constraint на поле ФИО. Не знаю, в каких облаках витали разработчики, когда проектировали Project Server, но у нас в компании около дюжины полных однофамильцев. Теперь сервис, который автоматически добавляет новых сотрудников в Project Server Enterprise Resource Pool проявляет чудеса изворотливости, а человек видит себя в MS Project как-то так: "Иванов Иван Иванович (4864)".
Ну, действительно, не отказывать же кандидату из-за того, что у него фамилия не уникальная :)

Бардак в сайтостроении.

Я всегда считал web разработку занятием легковесным и неблагодарным. Вся эта смесь серверных, клиентских скриптов, SQL, разметки, стилей. А обеспечение совместимости браузеров чего стоит.
Используемые языки и инструменты также не способствуют облагораживанию дизайна web приложений. Несмотря на усилия Sun и Microsoft придать этому бедламу некое благообразие в продвигаемых ими платформах, мало чего изменилось к лучшему. Вот, оказывается не один я придерживаюсь такого мнения. IBM DeweloperWorks публикует статью Питера Сибаха "Недовольный пользователь: Что же случилось с Web-проектированием?"
В отличие от меня, автор не только противно брюзжит по этому поводу, но и предлагает пути решения проблемы.

Где хранить ключи?

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

Начнем с очевидных вещей. Первое, ключ следует хранить отдельно от защищаемых данных. Если шифруемые данные хранятся в БД, то ключ там хранить не стоит.

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

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

Итак, задача номер один - защитить (зашифровать) ключ, задача номер два – придумать, где его хранить.

Для шифрования ключа можно, например, использовать ассиметричный алгоритм (RSA), но опять же - где хранить ключи ассиметричного алгоритма? Замкнутый круг. В .Net 1.1 для этой цели я пытался использовать CSPParameters но результат получался не удовлетворительный (конкретно, не удавалось использовать CspProviderFlags.UseMachineKeyStore для пользователей с ограниченными правами). Хорошо если пользователи вводят пароль при входе в систему, тогда этот пароль можно использовать для защиты персонального ключа. А если ключ должен быть общий? Или пользователи используют windows integrated аутентификацию и не вводят никаких паролей? К счастью этой же проблемой озаботились парни из Рэдмонда и написали для этих целей Data Protection API (DPAPI). В .Net 1.1 надо было делать managed обертку для DPAPI. В .Net 2.0 появился специальный класс System.Security.Cryptography.ProtectedData. Его методы Protect и Unprotect замечательно подходят для таких задач, как шифрование симметричного ключа:

byte[] salt = new byte[] { 143, 22, 104, 10, 12, 83 };
byte[] cryptedKey = ProtectedData.Protect(key, salt, DataProtectionScope.CurrentUser);
byte[] cryptedIV = ProtectedData.Protect(IV, salt, DataProtectionScope.CurrentUser);      

Здесь key и IV это и есть наш симметричный ключ (и вектор инициализации), в salt - это хвост, который добавляется для повышения криптостойкости полученного результата. DataProtectionScope определяет область действия защиты. Если данные зашифрованы в DataProtectionScope.CurrentUser расшифровать их можно будет только для того же пользователя. Если область действия LocalMachine – то любой пользователь на этой машине.

Итак, с защитой ключа все ясно. Теперь определимся с местом хранения. Первым делом, напрашивается хранение в файле. Но существует более удобный способ - System.IO.IsolatedStorage. Не следует думать что IsolatedStorage представляет из себя какое то защищенное хранилище, которое может повысить защищенность хранимых данных. Никакой дополнительной защиты IsolatedStorage не дает. Его скорее следует рассматривать, как некую виртуальную песочницу, которая позволяет, с одной стороны, абстрагироваться от файловой системы, а с другой стороны ограничить область видимости до необходимого уровня. Область видимости ограничена локальной машиной или пользователем, а внутри дополнительно приложением, AppDomain-ом или конкретной сборкой. Реально, данные IsolatedStorage сохраняются в пользовательском профайле. Таким образом, IsolatedStorage избавляет нас от необходимости настройки разрешений NTFS, а также от опасности того, что данные одного приложения будут затерты или прочитаны другим приложением.

Итак, мы шифруем наш симметричный ключ с помощью ProtectData и затем сохраняем его в IsolatedStorageFile:

private byte[] _key; // ключ
private byte[] _iv; // вектор инициализации
private string _name; // имя под которым будем хранить ключ
private DataProtectionScope _scope; // область видимости


private IsolatedStorageFile GetIsolatedStorage()
{
     // в зависимости от области видимости получаем IsolatedStorageFile
     if (_scope == DataProtectionScope.LocalMachine)
         return IsolatedStorageFile.GetMachineStoreForDomain();
     else return IsolatedStorageFile.GetUserStoreForDomain();
}

byte[] salt = new byte[] { 143, 25, 4, 30, 11, 83 };
// сохраняем ключ
void SaveInStorage() 
{
     // сначала шифруем
     byte[] cryptedKey = ProtectedData.Protect(_key, salt, _scope);
     byte[] cryptedIV = ProtectedData.Protect(_iv, salt, _scope);

     // потом сохраняем
     IsolatedStorageFile iStorage = GetIsolatedStorage();
     using (BinaryWriter writer = new BinaryWriter(new IsolatedStorageFileStream(_name, FileMode.Create, iStorage)))
     {
         // записываем длину зашифрованного ключа
         writer.Write(cryptedKey.Length);
         // записываем длину зашифрованного IV
         writer.Write(cryptedIV.Length);
         // записываем зашифрованный ключ
         writer.Write(cryptedKey);
         // записываем зашифрованный IV
         writer.Write(cryptedIV);
     }
}

// поднимаем ключ        
void LoadFromStorage()
{
    byte[] encryptedKey;
    byte[] encryptedIV;
    // читаем ключ из IsolatedStorageFile
    IsolatedStorageFile iStorage = GetIsolatedStorage();
    using (BinaryReader reader = new BinaryReader(new IsolatedStorageFileStream(_name, FileMode.Open, iStorage)))
    {
         // сначала читаем длину ключа
         int keyLength = reader.ReadInt32();
         // потом читаем длину IV
         int ivLength = reader.ReadInt32();
            
         encryptedKey = new byte[keyLength];
         encryptedIV = new byte[ivLength];
         // затем читаем ключ и IV
         reader.Read(encryptedKey, 0, encryptedKey.Length);
         reader.Read(encryptedIV, 0, encryptedIV.Length);

         // расшифровываем ключ и IV
         _key = ProtectedData.Unprotect(encryptedKey, salt, DataProtectionScope.LocalMachine);
         _iv = ProtectedData.Unprotect(encryptedIV, salt, DataProtectionScope.LocalMachine);
    }
}         

Здесь приведен фрагмент кода класса SymmetricKeyContainer, который инкапсулирует в себе логику защиты и хранения симметричного ключа. Этот класс входит в небольшую библиотеку CryptoUtils, которую я разместил в Google Code Project Hosting, в основном с целью опробовать этот новый инструмент Google. И надо сказать, я остался им вполне доволен. Полностью исходный код класса можно взять в репозитории проекта (svn) здесь: http://cryptoutils.googlecode.com/svn/

Sputnik

Вот таким логотипом сегодня Google отмечает 50-летие запуска первого спутника.
Мелочь а приятно.

Microsoft открывает исходники .Net

Как сообщает в своем блоге Scott Guthrie его команда сейчас ведет работы по подготовке к публикации исходников .Net Framework 3.5. Исходные коды и отладочные символы будут включены в релиз Visual Studio 2008, а также будут доступны "via a standalone install".
Исходники публикуются под лицензией Microsoft Reference License (MS-RL).
Чтож, здорово.
Это конечно не совсем Open Source, в том смысле, как это обычно принято понимать. MS-RL оставляет все права за Microsoft. Но все же публикация исходников значительно облегчит жизнь .Net разработчиков.

Любите править чужие баги?

Никто не любит копаться в старом чужом коде, и вылавливать там баги (ну, почти никто :). Но порой приходится. Что делать, когда перед тобой система в сотню тысяч строк кода, задача buglog-а, причем и то и другое ты видишь в первый раз?
Большинство приложений, с которыми приходится иметь дело имеют похожую высокоуровневую структуру. Впереди располагается "морда" в виде GUI, web или windows, а на противоположенном конце БД (для .Net это чаще всего SQL сервер). Между этими полюсами располагаются десятки и сотни тысяч строк кода. Структура этого кода тебе не известна, а во взгляде начальника в место сочувствия читается "ну - ну, сейчас мы посмотрим, что ты за программер...". На этот случай у меня есть очень простая и эффективная техника локализации ошибки, о которой я хочу рассказать.

Сначала воспроизводим баг в тестовом environment-е, и локализуем в UI точку входа для воспроизведения бага. Что-то вроде "вот, если теперь нажать на кнопку "Details", система рушится в синий экран".

Вторым шагом, идем в backend, на SQL сервер и запускаем SQL profiler. Наша цель - перехватить все SQL команды отправляемые нашей системой в БД. Функциональная структура рассматриваемого нами класса систем, несмотря на все их разнообразие, довольно однородна: по команде с UI система выполняет ту или иную бизнес логику, которая неизбежно приводит к записи данных в БД. Итак, запустив SQL профилировщик, еще раз инициируем в UI сценарий воспроизводящий баг. После этого останавливаем профилировщик и анализируем полученный лог. Нас будут интересовать имена вызываемых хранимых процедур и SQL запросы. Эти имена мы ищем в коде системы. Они обязательно там будут, в виде строковых констант, в ресурсах или, быть может, в файлах конфигурации :). Наша цель, найти в коде точки, из которых вызываются хранимые процедуры и SQL запросы и установить в них точки прерывания.

После этого, мы в третий раз выполняем сценарий воспроизводящий баг, но уже в режиме отладки. Остановившись в точке прерывания, мы спешим увидеть стек вызовов (Ctrl+Alt+C в студии), потому что call stack, это и есть та нить Ариадны, которая проведет нас через сотни тысяч строк кода незнакомой системы. Конечно, если система имеет несколько физических уровней, то таким способом мы препарируем только один уровень. Впрочем, при должном умении, можно получить цепочку стека вызовов всех уровней системы, но тут уже многое зависит от конкретной архитектуры. Далее, расставляем точки прерывания по стеку вызовов и занимаемся исправлением бага.

Великая тайна программистов

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

В одном из них рассказывалось о "двунаправленной синхронизации каталогов Oracle Internet Directory и Microsoft Active Directory" для целей аутентификации, а также о Transparent Data Encryption (TDE) и Virtual Private Database (VPD) для обеспечения защиты хранимых данных, о построенном стенде и проведенных исследованиях. В другом речь шла о построении корпоративной системы на базе SOA, о публикации сервисов в реестре UDDI и о последующем поиске и подключении их заинтересованными системами-потребителями. Помню, оба документа произвели на меня в свое время сильное впечатление своим неукротимым полетом технологической мысли.

Имея возможность лицезреть готовые результаты по обоим проектам, я был поражен, насколько далеки оказались полученные результаты от запланированных архитектурных схем. В первом проекте вместо Oracle оказался MS SQL, а следовательно никакой "двунаправленной синхронизации каталогов" не понадобилось. Вместо TDE и VPD, используется симметричное шифрование общим ключом и обычное разграничение доступа к данным на уровне бизнес логики. Во втором проекте получилась обыкновенная трехзвенка, а единственный web сервис выдает неформатированный XML, и следовательно, для автоматического обнаружения и подключения никак не пригоден.

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

Так, а в чем же состоит "Великая тайна программистов"? Дело в том, что мы, программисты, любим всякие новые технологии и продвинутые архитектуры. Мы создаем их ежедневно в огромных количествах, подобно тому, как Мать Природа плодила биологические виды во времена Кембрийского эволюционного взрыва. Потом мы с большевистской напористостью продвигаем все эти новые фичи в наши проекты, руководствуясь порой одним лишь правилом: "Cool is a powerful reason to spend money" (Nathan Myhrvold). А тайна состоит в том, что за все это платит заказчик (пользователь). Но мы ему об этом никогда не скажем.

DevDays Fall 07. Москва

Вчера посетил "Дни разработчика Осень 07". Далее отчет и впечатления.

Утренний экспресс из Дубны как обычно опоздал и поэтому начало первого доклада я пропустил. А первый доклад был про SQL Server 2008. Насколько я понял, революционных изменений в SQL server ждать не стоит, одна сплошная ползучая эволюция. Улучшение производительности, управление на основе политик, поддержка Entity & LINQ, а также масс мелких новых фич. Впрочем, некоторые из фич производят впечатление глубокой бетты, в частности, показанная Change Data Capture. Другие, хоть и невелики но довольно интересны. Например, поддержка оператора MERGE (update + insert в одном флаконе). Наконец-то появятся раздельные типы данных для даты и времени. Также среди новых типов - FileStream, позволяющий вовлекать в транзакционно-реляционный процесс файловые данные (видимо, это отголоски долгой и безуспешной борьбы за WinFS), HierarchyID - для поддержки иерархий, и какие-то забавные типы Geometry и Geography, которые впрочем, вовсе не SQL, а CLR типы. По поводу SSIS, SSAS и Reporting Services не было сказано ни слова (или я пропустил?).

Второй доклад посвященный WCF делал Марат Бакиров. Рассказывал он много и весело, но времени как всегда на все не хватило. Для тех, кто с WCF знаком в докладе не было практически ничего нового, а для тех, кто услышал о нем в первый раз много было не понятно. Из интересного. В Orcas появится шаблон Syndication, который будет предоставлять заготовку для сервиса в формате RSS и Atom, так что, не надо будет заморачиваться на деталях протокола, а просто накидывать контент в фид. Там-же (в Orcas) обещают поддержку Json и Ajax в сервисах WCF.

Третий доклад "Многопоточное программирование - вольный стиль" делал представитель Intel Василий Маланин. Доклад был посвящен замечательной C++ библиотеке для параллельного программирования Threading Building Blocks (TBB) и тому, как ее можно использовать в .Net. По этому поводу стоит заметить что Microsoft готовит свою параллельную библиотеку Parallel FX, которая конечно более тесно интегрирована с CLR. Но с другой стороны TBB выглядит несколько мощнее именно в плане многопоточности. Впрочем реально ни той ни другой библиотеки я пока не использовал и оценки делать наверное еще рановато.

Четвертый доклад делали представители AutoDesk. Оказывается семейство продуктов Autocad теперь может быть хостом для CLR и AutoDesk призывает всех разрабатывать для них plugin-ы на .Net. Впрочем тема заинтересовала не многих, и я не в их числе. Кому интересно читайте о докладе в блоге Vadim Horyakov

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

После обеда были доклады по WPF и ASP.NET, но на них я к сожалению не присутствовал.

MSDN Mag October - Thinking Parallel

Вышел октябрьский номер MSDN Magazine на русском языке.
Большая часть номера посвящена параллельным вычислениям. Статьи "Параллельный LINQ: Выполнение запросов на многоядерных процессорах" и "Параллельная производительность: Оптимизация управляемого кода для многоядерных компьютеров" по сути анонсируют новую библиотеку Parallel FX, которая будет доступна во .Net Framework 3.5, постепенно погружают нас в мир понятий и проблем, связанных с параллельными вычислениями.

Названия других статей номера тоже говорят сами за себя: Роберт Сакконе, "Потоки в пуле: Улучшение масштабируемости с помощью новых API пула потоков"; Шон Вилдермут,
"Потоки WPF: Создание более быстро реагирующих приложений с Dispatcher"; Стивен Тауб, ".NET: вопросы и ответы: Монитор взаимоблокировок".

Итак, начинаем мыслить параллельно. Скоро, очень скоро, на собеседованиях нас будут спрашивать не только о полиморфизме и инкапсуляции, но и о фьючерсах и параллельных циклах :)

Параллельный LINQ и другие...

В своей статье "Программное обеспечение и параллельная революция" Херб Саттер (Herb Sutter) и Джэймс Лэрус (James Larus) отмечали, что современная программная инженерия стоит перед серьезным вызовом. Стремительно распространяется многоядерная архитектура вычислительных ресурсов, и адекватным ответом со стороны программного обеспечения может быть только повсеместное распространение параллельных вычислений.

И вот, результаты не заставили себя ждать. В октябрьском номере MSDN Magazine опубликована статья Джо Даффи и Эда Эссея "Параллельный LINQ: Выполнение запросов на многоядерных процессорах". По сути это анонс готовящегося к выходу пакета Parallel FX разработкой которого сейчас занимается Microsoft® Research и команда CLR.

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