пятница, ноября 30, 2007

Будут ли следующие версии 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 (на русском).

вторник, ноября 27, 2007

Платформа 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

понедельник, ноября 26, 2007

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

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

пятница, ноября 23, 2007

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

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

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

понедельник, ноября 19, 2007

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

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

пятница, ноября 16, 2007

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


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

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

четверг, ноября 15, 2007

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

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

среда, ноября 14, 2007

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*С. И все-же один человек приехал на работу на велике.

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

вторник, ноября 13, 2007

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

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

среда, ноября 07, 2007

Наследие WinFS

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

Beyond Architecture

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

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

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

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

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

вторник, ноября 06, 2007

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

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

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

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

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