Хорошего консультанта привлечь на порядок проще, чем нанять хорошего сотрудника. Хотя и дороже.

Почему так?

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

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

3. У консультанта просто больше свободного времени. Ему, как правило, не надо бросать предыдущий проект, чтобы начать новый (хотя и не в режиме полной загрузки). Представьте, что всего в России 100 специалистов по какой-то редкой технологии. Допустим, 60 из них работают в штате, а 40 занимаются консалтингом. В произвольный момент времени готовы взяться за новый проект четверть штатных сотрудников и три четверти консультантов. Получается, что потенциальному заказчику нужно будет выбирать из 15 сотрудников и 30 консультантов, несмотря на то, что общее число последних меньше в полтора раза.

Исходный вариант (взято из статьи Raking /etc/hosts For Sweeter Subdomainage)

hosts = []

# add all the site temporary domains
hosts << Site.find(:all).inject([]) do |collection, site|
  collection << site.harmony_url
end

# add all the account subdomains
hosts << Account.find(:all).inject([]) do |collection, account|
  collection << account.harmony_url
end

Как можно сделать лучше?

Программа-минимум:

# site and account subdomains
hosts = []
hosts << Site.find(:all).collect(&:harmony_url)
hosts << Account.find(:all).collect(&:harmony_url)

Улучшения здесь три:

1. Заменяем низкоуровневый inject на collect. Нет смысла пользоваться inject и выставлять наружу переменную-счетчик, если можно легко сделать то же самое с более высокого уровня абстракции.

2. Используем сокращенный способ вызова метода в блоке: (&:harmony_url) вместо {|element| element.harmony_url}. Это улучшение является частью ActiveSupport, так что вне рельс само работать не будет.

3. Заменяем дословно повторяющие код комментарии на что-то хоть немного более высокоуровневое.

Дополнительная программа:

1. То же самое чуть компактнее

   # site and account subdomains
   hosts = Site.find(:all).collect(&:harmony_url) + Account.find(:all).collect(&:harmony_url)
   

   Далее в коде нигде не используется факт, что массив хостов содержит два отдельных подмассива со значениями, поэтому можно просто запихать все в плоский массив. Что, кстати, избавит нас не только от инициализации hosts, но и от вызова flatten при использовании значений.

2. Делаем код понятным без комментариев

   hosts =  Site.find(:all).collect(&:subdomain) +  Account.find(:all).collect(&:subdomain)
   

   … а в классах моделей пишем:

   alias_method :harmony_url, :subdomain
   

Сегодня появилась замечательная возможность для этого

Прочтите последнюю статью Джоэля Спольски, Strategy Letter VI. Это лучше из всего, что я чидел за последние полгода о перспективах развития платформ разработки.

Давно уже стало банальностью утверждение о том, что программисты могут отличаться в производительности в десять и более раз. Среди важнейших причин, наряду с талантом и правильными условиями работы (сюда входит все от процессов разработки и тестирования до зарплаты, атмосферы в коллективе и удобства кресел), фигурирует и использование правильных практик программирования. Кент Бек (Kent Beck), создатель методологии Extreme Programming, говорил о себе “Я не считаю себя замечательным программистом, я лишь неплохой программист с замечательными привычками”. В этой и последующих статьях цикла будут рассмотрены некоторые практики, входящие в мой собственный набор “замечательных привычек”, а также реально полезные инструменты и библиотеки.

В качестве основы взяты практические эпизоды наших текущих проектов. Материал нового цикла будет в первую очередь полезен для разработчиков и, в особенности, для тех-лидов и руководителей, осуществляющих “тренерскую” работу.

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

Сегодня я напишу о способе, который позволит сделать отладку более приятной и эффективной.

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

Сразу предупрежу, что стандартная реализация далеко не идеальна.

Что произойдет при попытке напечатать значение объекта в python?

>>> print 7
7
>>> print range(5)
[0, 1, 2, 3, 4]

Пока все хорошо. Попробуем отойти от базовых типов данных:

class Run(object):
    pass

>>> r = Run()
>>> r.status = 'new'
>>> print r
<__main__.Run object at 0xd3f944c>
>>> print 'Shit happens...'
'Shit happens...'

Отвратительно. Придется обращаться отдельно к каждому атрибуту, что не очень удобно.

Надо сказать, что в Ruby вывод подробного состояния объекта реализован очень правильно:

>> Run.find :first
=> #<Run:0xb725f884 @attributes={"status"=>"done",
"finished_at"=>"1900-01-01 00:00:00", "id"=>"1",
"started_at"=>"1900-01-01 00:00:00"}>

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

Дело в том, что поведение объекта при вызове print можно настраивать. Для этого служат два специальных метода: __str__ и __repr__ — первый для описания объекта в свободной форме, второй — для максимально строго и полного описания соответственно (желательно, чтобы результат __repr__ являлся валидным выражением на языке python, описывающем текущий объект). Для отладки актуален, преимущественно, метод __repr__.

Классическое исполнение выглядит следующим образом:

class Run(object):
    def __init__(self, status, started_at):
        self.status, self.started_at = status, started_at
    def get_name(self):
        return self.user_name
    def __repr__(self):
        return "Run: status=%s started_at=%s" % (
            self.status, self.started_at)

    >>> from datetime import datetime
    >>> r = Run('new', datetime.today())
    >>> r
    Run: status=new started_at=2007-08-12 03:16:26.468553

В этом коде нарушается принцип DRY (don’t repeat yourself): при добавлении в класс нового атрибута вам придется менять код текстового представления объекта.

В один прекрасный день обнаруживаешь, что у тебя накопилось с десяток классов с 5-15 значимыми атрибутами каждый, а редактирование методов __repr__ достало до печенок. Как быстро выяснилось, есть способ реализовать __repr__ раз и навсегда. Для этого достаточно немного покопаться во внутренней механике объектов, а именно — использовать свойство __dict__, дающее доступ ко всем атрибутам данного объекта в виде dictionary формата “имя: значение”. Такая реализация даже более компактна, чем явная печать каждого атрибута:

class Run(object):    
    # ...
    def __repr__(self):
        return 'Run: %s' % dict([
            (k,v) for k,v in self.__dict__.items() if not k.startswith('_')])

>>> session = create_session()
>>> Run.get_latest(session)
Run: {'status': 'done', 'finished_at': datetime.datetime(2007, 8, 8, 20, 26, 48),
'resume_after': None, 'started_at': datetime.datetime(2007, 8, 8, 20, 26, 42),
'id': 4L, 'errors_in_a_row': 0}

Примечание: здесь и далее в примерах работа с БД организована с помощью библиотеки SQLAlchemy. Это, пожалуй, лучшее что есть сейчас в python для работы с базами данных.

Обратите внимание на выражение dict([(k,v) for k,v in self.__dict__ if not k.startswith('_')]). В pyhton принято начинать имена private-атрибутов с одного подчеркивания (”_”), следовательно, мы отфильтровываем все private-атрибуты и не показываем их. По опыту могу сказать, что это очень удобно при работе с SQLAlchemy, которая добавляет к вашим объектам кучу служебных свойств.

Уже гораздо лучше: написанный один раз код можно просто копировать в каждый новый класс. Для тех, кто работает под девизом “зачем объектное программирование, когда есть блочное копирование” этого вполне достаточно. Мы же пойдем чуть дальше и создадим действительно универсальную реализацию:

class Inspectable(object):
    """Provide an ability to print class instance and its attributes"""
    def __repr__(self):
        return '<%s: %s>' % (
            self.__class__.__name__,
            dict([(x,y) for (x,y) in self.__dict__.items() if not x.startswith('_')])
            )

class Run(Inspectable, object):
    #...

>>> session = create_session()
>>> Run.get_latest(session)
<Run: {'status': 'done', 'finished_at': datetime.datetime(2007, 8, 8, 20, 26, 48),
'resume_after': None, 'started_at': datetime.datetime(2007, 8, 8, 20, 26, 42),
'id': 4L, 'errors_in_a_row': 0}>

Обратите внимание на порядок наследование в Run: Inspectable, object. В python наследование от списка классов резолвится слева направо, поэтому первыми должны быть указаны классы, располагающиеся ниже в иерархии наследования. В противном случае получите ошибку наследования:

>>> class Run(object, Inspectable):
...   pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Error when calling the metaclass bases
    Cannot create a consistent method resolution
order (MRO) for bases object, Inspectable

Кстати, явно наследовать от object совсем необязательно — ведь Inspectable тоже является потомком object. Я, однако, предпочитаю указывать object если перед этим наследую только от абстрактных классов — по идеологии это близко концепции mixin’ов в Ruby.

Зачем вообще куда-то ехать?

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

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

Почему Питер?

На самом деле, это единственный сколько-нибудь разумный для нас вариант.

Логика следующая:

1. «В деревню, в глушь, в Саратов» ехать рано – мы молоды и у нас совершенно другие жизненные приоритеты.

2. Уезжать из России пока не хочется.

3. Ехать из 700-тысячного Тольятти в какой-нибудь город-миллионник не имеет особого смысла – разница не настолько велика, чтобы стоило заморачиваться с переездом.

4. Москву мы активно не любим и как место, пригодное для жизни, не рассматриваем.

5. Как видите, остается только Питер. Замечательный, красивый и интересный город, который нам обоим очень нравится. Мы давно хотели жить в Питере, а теперь еще и можем переехать. Ну, о чем здесь еще говорить?

Цели и ожидания

Культура

Даешь насыщенную культурную жизнь! Выбор выставок, театров, концертов и всего остального просто феноменален. Даже побывать во всех интересных местах — программа на годы. Мы намерены по максимуму насладиться этим богатством и разнообразием.

Профессиональное сообщество

Основное ожидание от профессионального сообщества — то, что оно здесь есть.

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

Хочется надеяться, что ситуация в Питере отличается в лучшую сторону.

Перспективы для бизнеса

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

По-русски: Microsoft снова против

Оригинал: Microsoft vs TestDriven.Net Express — пишет автор дополнения, вызывающего разногласия.

Кратко о сути проблемы

TestDriven.NET — это Add-In для Microsoft Visual Studio, предоставляющий возможность интеграции юнит-тестов в проект. Некоммерческое использование бесплатно, professional и enterprise версии платные, цены начинаются от $95 за лицензию.

Надо заметить, что роль TestDriven.NET в экосистеме инструментов .NET весьма значительна. По опыту своего большого проекта на платформе Microsoft могу сказать, что без сторонних инструментов (как правило, open source) практически невозможно работать над чем-то серьезным. NUnit, NAnt, CruiseControl.NET, fxCop, NCover, Selenium — без всего этого проект бы просто рассыпался как карточный домик. Для тех, кто использует TestDriven.NET, его отсутствие было бы, думаю, столь же критично.

Microsoft недоволен тем, что TestDriven.NET работает со всеми версиями Visual Studio, включая бесплатную Visual Studio Express. По их словам, это подрывает рынок для старших версий Visual Studio и нарушает условия лицензионного соглашения.

Развитие событий:

• 1 декабря 2004 - Выпущен TestDriven.NET 1.0, пока бесплатный

• 27 февраля 2006 - Jamie получает статус MVP (Microsoft Most Valued Professional) за вклад в развитие профессионального сообщества.

• 10 июля 2006 - выпущены Professional и Enterprise версии TestDriven.NET

• 10 октября 2006 - Jamie лишается статуса MVP, вероятно в связи с разногласиями по TestDriven.NET

• 31 марта 2006 - 17 апреля 2007. Идет переписка Jamie с Microsoft. По итогам Jamie наконец-то узнает, какую лицензию по мнению Microsoft нарушает (Visual studio Express EULA). Какой пункт лицензии нарушен — неизвестно. Быстро все-таки работают большие компании…

Jamie утверждает что наконец-то получил от британских юристов Microsoft указание пункта EULA, который он нарушает. Речь идет о запрете на использование Visual Studio Express для ряда коммерческих целей. Впрочем, так и непонятно, является ли этот пункт соглашения законным и нарушает ли его TestDriven.NET.

Что думает сообщество

Реакция сообщества, думаю, очевидна. Microsoft must die, глубокое сожаление о плохом инструментарии разработки на .NET, удивление бездарным принятием корпоративных решений.

Аналитическое

Прослеживается тенденция неуклюжего Microsoft обращения с экосистемой open source-инструментов разработки для .NET. Могу предположить, что в дело вступает менеджмент Visual Studio, пытающийся за счет притеснения Microsoft поднять продажи инструментов разработки. То, что .NET в качестве платформы разработки несет при этом потери, на много порядков превышающие продажи Visual Studio… Да какое дело до этого менеджеру Visual Studio? Перед нами типичный пример близорукого управления в больших корпорациях — задача отдельного менеджера конфликтует с целями корпорации в целом.

В тему

Мартин Фаулер пишет о неясных перспективах Ruby на .NET, важности усилий сообщества по затыканию дыр в платформе (на примере Java) и о тенденции бегства лучших разработчиков с платформы .NET

Естественно, сразу же развернулось бурное обсуждение (17 комментариев за первые 10 часов). Внесу и свою лепту в обсуждение:

Ну-ну! Я был как-то на конференции, кажется CRN проводил, так там IDC кажется или Gartner это говорил. И так они меня разозлили, что я вышел следующим выступать и спросил: “Есть ли в зале хоть один человек, которому “отсутствие” свободы слова нанесло ущерб хоть в один доллар? В зале сидело больше сотни реселлеров, большая часть нашего ИТ бизнеса, и ни один не поднял руки.

Это человек — я. Я потерял много зеленых и хрустящих долларов. И продолжаю их терять. Из-за того, что моя производительность труда ниже, чем могла бы быть, живи я в Калифорнии. Мой калифорнийский коллега не должен тратить часы на стояние в ненужных очередях. Он может продлить водительские права по почте. У него есть основания не бояться, что «все отнимут и поделят», и не сушить сухари на этот случай. У него нет необходимости жить с женой и детьми в панельной однушке или думать о том, где украсть денег на жилье, не унижающее человеческое достоинство. Ну и так далее. Представьте, сколько свободного времени и энергии остается на работу.

Так что связь самая прямая. Процитирую свой комментарий:

Если вы что-то импортируете в страну (или что-то из нее экспортируете), то вас не будут волновать гражданские свободы — были бы правила игры понятны и стабильны. Здесь ваши рассуждения полностью применимы.

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

Ответ Михаила:

Степень гражданских свобод отражается на производительности интеллектуального труда? Щаззззззз! Где российский космос? Наше авиастроение и оборонка пользуются наработками 30 летней давности. На моем химфаке МГУ остались конечно люди мирового класса, но им уже за 60 и это продукт другой эпохи. У нас хорошо только рекламу делать научились…

Проблема науки и технологий в СССР была не в том, что не открывали или не разрабатывали, а в том что не внедряли. Но это другая история…

На это у меня два возражения.

Первое: современную Россию никак нельзя считать примером «западной» рыночной экономики. Не думаю, что по уровню коррупции мы далеко ушли от Казахстана и Республики Чад. Так что мы — типичная «Византия», и по нашему текущему состоянию нельзя делать какие-либо выводы о западной модели экономики.

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

Открывать новые цацки — интересно. Ученые будут делать это из чистого интереса, лишь бы государство дало денег на оборудование. А вот внедрение — тяжелый, нервный и совершенно неинтересный процесс. Чтобы люди им занимались, им нужна возможность зарабатывать на этом деньги. Толстые пачки пропахших потом денег. То есть, для инноваций, как минимум, нужна свобода зарабатывать деньги – это должно быть доступно кому угодно, а не только людям с правильной родословной (им, кстати, можно и не работать, чтобы хорошо жить). Ну а свобода зарабатывать деньги обязательно потянет за собой весь остальной комплекс гражданских свобод.

Иными словами, в “византийской” модели имеет место следующая логика: отсутствие гражданских свобод => неравенство => привилегированным работать не нужно, остальным бесполезно => нет стимулов добровольно заниматься тяжелой и неинтересной работой => нет внедрений. Разве это не логично? Кстати, Пол Грэм писал в статье “Inequality and Risk” о том, что невозможность заработать много денег тяжелым трудом останавливает инновации.

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

Вводная

Клиент: “Алекс, не мог бы ты посмотреть спецификацию проекта Х? Можешь ли ты это сделать и сколько приблизительно времени это займет?”

Я: “ОК, я так понимаю это высший приоритет на сейчас”

Клиент: “Да”

Я: “Что ж, тогда поехали… Скоро вернусь”

Читаем спецификацию

Открываю Basecamp, иду на страницу проекта. Имеется: один абзац общих требований и приаттаченый Word’овский файл. Скачиваю. Открываю. 5 страниц, на первой общие требования и предполагаемый план работ, на остальных четырех — описание функций в виде эскизов страниц с описанием.

Смотрю на расписание. Три контрольных точки:

• 0-30% done “Complete design and markup of all presentation layers” плюс какой-то минорный функционал. Target Completion Date: через 3 дня

• 30-70% done Весь функционал, включая биллинг и прием платежей. Target Completion Date: через 10 дней

• all done Тестирование и доводка согласно пожеланиям заказчика. Target Completion Date: через 25 дней

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

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

Делаем estimate

Возвращаюсь к началу описания функционала. Достаю планшет и чистый лист бумаги. Начинаю медленно читать список функций и сразу же набрасываю модель данных — имена объектов (сущностей) и связи между ними. Связи «многие ко многим» не детализирую. Кардинальность связей бросаю обозначать на пятой сущности — потом разберемся, если еще понадобится. Заканчиваю первую страницу с функционалом — в активе 7 сущностей. После следующей страницы – еще 6, да и связей прибавилось…

После последней страницы у меня уже 19 основных сущностей. Можно предположить, что второстепенных сущностей будет, как минимум, столько же, если не вдвое больше. Отдельно выписываю особо запомнившиеся фрагменты функционала: биллинг, прием платежей, live preview закачанных пользователями видеороликов и т.д.

По грубой прикидке, каждой сущности будет соответствовать класс модели. На каждый класс придется несколько сотен строк кода (Ruby on Rails). И еще на столько же потянут тесты. В общем, уже понятно, о чем говорить клиенту:

Я: “Закончил читать спецификацию. На реализацию уйдет заметно больше 6 месяцев при команде в 4 человека”. Насколько больше — предсказать за полчаса невозможно, да и, учитывая указанные в документе контрольные точки, едва ли будет интересно заказчику.

Клиент: “Ладно, забудь. Можешь прекратить читать. Я знаю парня, который сделает это за 4 недели”

Я: “Что ж, удачи ему. Я не верю, что это возможно”

В чем мораль?

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

Во-вторых, почти всегда найдется клоун, который пообещает сдать пятилетку за три дня. «Безумству храбрых поем мы песню». А заказчик, вероятно, совсем скоро к нам вернется.

В частности, там пишут о том, что качество рабочего места и потенциальные возможности занимающего его человека определяются возможностью положительно ответить на следующие 12 вопросов:

1. Знаю ли я, что от меня ожидается на работе?

2. Располагаю ли я материалами и оборудованием, необходимыми для правильного выполнения моей работы?

3. Есть ли у меня возможность ежедневно заниматься на работе тем, что я умею делать лучше всего?

4. Хвалили ли меня за хорошо сделанную работу в последние 7 дней?

5. Проявляет ли непосредственный руководитель или кто-либо другой на работе заботу обо мне как о личности?

6. Есть ли на работе человек, который поощряет мой личностный или профессиональный рост?

7. Считаются ли на работе с моим мнением?

8. Позволяет ли миссия компании чувствовать важность моей работы?

9. Считают ли мои коллеги своим долгом выполнять работу качественно?

10. Работает ли вместе со мной хотя бы один из моих лучших друзей?

11. Беседовал ли кто-нибудь со мной за последние 6 месяцев о моем прогрессе?

12. Были ли у меня за последний год возможности для учебы и развития?

Моя работа, если ее так можно назвать, получает 9 баллов из 12. Вот три вопроса, на которые я не могу ответить утвердительно:

• Хвалили ли меня за хорошо сделанную работу в последние 7 дней? Нет. Типичная проблема аутсорсинга, обусловленная “утяжеленностью” процесса коммуникации. Общение с коллегой за океаном требует значительно больших усилий, чем общение с соседом по офису. В результате необязательная часть общения слетает как шелуха и остается только самое необходимое: планы, задания, вопросы, проблемы…

• Есть ли на работе человек, который поощряет мой личностный или профессиональный рост? Нет (хотя мне это и не нужно — всегда хватало собственного стремления к совершенству). Абсолютно типично для менеджерской должности, тем более что я работаю не в большой компании, а независимо.

• Позволяет ли миссия компании чувствовать важность моей работы? Скорее нет. Никто не отдает на аутсорсинг жизненно важные проекты.

А на сколько баллов тянет ваша работа?

Общался сегодня с коллегами, трудящимися у моего предыдущего работодателя. Они на свою голову обновили Windows 2003 Server до SP2 (к счастью, это был только тестовый сервер). Вот к чему это привело:

Настоящие герои не пользуются RDP

Сразу же вылезло две проблемы с RDP (Remote Desktop)

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

2. Перестала работать функция Remote Control, позволяющая контролировать сессию другого человека и видеть его экран. Когда работает, эта функция исключительно удобна для обучения территориально удаленного коллеги или для совместной диагностики проблем.

Сессии в ASP: “Эта музыка будет вечной”

После обновления перестало срабатывать событие IIS, сигнализирующее об окончании сессий в классических ASP-приложениях. Для приложений, использующих сессии, это, в большинстве случаев, Show Stopper. Так что срочно сносите SP2 со всех своих серверов и серверов заказчиков. Ну или расслабьтесь и получайте удовольствие до выхода фикса.

Если вы все еще используете ASP (что во многих случаях вполне оправдано), то рекомендую прочитать описание проблемы в Knowledge Base.

Мораль: выключите windows update на production серверах. И всегда тестируйте все обновления на чем-нибудь не очень критичном.

Кажется, Microsoft только что выпустила hotfix. Впрочем, он недоступен для скачивания, а распространяется только по специальному запросу в техподдержку, что наводит на тревожные мысли относительно степени его протестированности.

Умри, Firefox!

При обновлении Outlook и Internet Explorer становятся почтовым клиентом и браузером по умолчанию. Вне зависимости от предыдущих настроек. Сообщество писает по этому поводу кипятком вот здесь и здесь.

Итог

Microsoft облажалась по первому разряду. Будем надеяться, такое непотребство будет происходить не очень часто…