Опять про тестирование приватных функций.

На RSDN-е опять обсуждают "Как тестировать приватные функции класса?", предлагают разные решения и спорят какое из них лучше.
Подобные споры меня всегда очень удручают. Почему? Потому что проблемы на самом деле нет. А попытки решать проблему которой нет порождают чудовищно уродливые решения.

На вопрос "Как тестировать приватные функции класса?" есть только один ответ: - "Только через публичный контракт этого класса." Если в голову лезут еще какие либо "решения", значит смысл модульного тестирования, а тем более TDD, до вас еще не дошел.

Что есть модульный тест? Это пример того, как внешний код будет использовать ваш класс. Зачем может понадобиться модульный тест для приватных методов класса, неужели вы рассчитываете на то, что внешний код будет вызывать приватные методы вашего класса? Так почему не сделать эти методы публичными?
Вопрос о тестировании приватных членов - это вопрос новичков. Вот у меня есть куча приватных методов и мне надо покрыть их тестами, как же мне это сделать? Это делается всегда одним и только одним способом - тестированием публичного контракта класса. Если у вас есть приватный метод, который вы не можете протестировать через публичный контракт, значит у вас что то не так с дизайном класса.

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

Я вот недавно писал библиотеку, в которой доля публичных методов менее 20%, остальные private и protected. Модульные тесты покрывают 95% кода библиотеки, причем тестируются только публичные члены. Я легко достиг бы и 100% покрытия, дописав guard-тесты, поскольку непокрытый код, это по большей части, валидация входных параметров и строки, выкидывающие исключения, но мне просто лень. В этой библиотеке есть полностью приватные классы, которых не видно снаружи, и они покрыты тестами на 100%.

Скажу более, в паре приватных методов я нашел большие куски по 6 -10 строк кода, не покрытые тестами. При внимательном рассмотрении, оказалось что этот код просто лишний :). Он никогда не вызывался ни при каких тестовых сценариях, и я его просто выкинул. Это, кстати, хорошая иллюстрация того, что понимается под последней буквой D (design) в TDD.

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

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

Как разделить EDM на несколько частей?

Похоже, народ начинает пробовать заюзать Entity Framework в реальных проектах. И начинает задавать неудобные вопросы.
Один из самых "горячих" вопросов: как разделить большую модель данных (EDM) на несколько частей. Я уже затрачивал этот вопрос в обсуждениях вот этого поста.
Суть моих рассуждений была такова: делите модель только если ее действительно можно разделить на несколько независимых частей. Иначе делайте большую общую модель и шарьте ее между всеми модулями системы.
Однако, большая модель это не только ценный мех не очень удобно, но это еще и проблемы с производительностью. И вот от разработчиков EF пришла благая весть: EDM все же можно делить на части так, что одна часть будет ссылаться и использовать классы другой части. Для этого есть чудесный аттрибут "using":

<Schema Namespace="NorthwindModel" Alias="Self" xmlns="http://schemas.microsoft.com/ado/2006/04/edm">
<Using Namespace="NorthwindModelBase"  Alias="BaseModel" />

Подробно о том, как разделить модель на несколько частей, с пошаговыми инструкциями написано в блоге разработчиков ADO.NET "Working With Large Models In Entity Framework – Part 2"

Есть однако одна неприятная деталь. Точнее две.
Первая, подключаемые модели традиционно не поддерживает дизайнер EDM. Но это можно пережить.
Вторая, модели могут ссылаться друг на друга только в одном направлении, а это автоматически означает, что navigation property, а иными словами, ссылочные свойства на объекты в другой модели запрещены. И это уже плохо. Вернемся к началу моего поста, где я говорил о том, что делить модель на части можно только если эти части не зависимы. Выходит, к сожалению, я был все же прав.

Не стреляйте в тапера...

Знаете, какая самая большая проблема тимлидов и менеджеров, вышедших из программеров? Перестать управлять написанием кода, и начать управлять достижением целей.
Казалось бы, чего проще? Однако, как тяжело дается людям эта простая истина. Всем, кто хочет стать хорошим тимлидом читать нетленку: Толик Тенцер «Урри, где у него кнопка?»

Visual Studio для русских гоблинов

Все уже наверное слышали о выпуске полностью локализованной русской версии Visual Studio. Рекламируется это событие широко с размахом и креативом. Иногда, правда, креатив плещет через край. Как вам вот это?
Забавная троица. Надо полагать, именно у этих ребят были постоянные проблемы с английской версией Visual Studio. А вот с русской, они наконец-то развернутся.
Налицо эволюция образа русского программиста в глазах западного заказчика.

Application Architecture Guide - v2.0

А вот это уже интереснее. Сегодня J.D. Meier анонсировал выпуск "Application Architecture Guide - v2.0" (beta 1).
Это, конечно, не исчерпывающее руководство к действию, но на роль весьма полного справочника этот гайд вплне подойдет.
Если вас интересуют вопросы:
- когда клиент-серверная архитектура предпочтительнее 3-х уровневой?
- какими принципами следует руководствоваться при разработке role based authorization?
- как варианты развертывания влияют на архитектуру приложения?
- что надо учитывать при разработке слоя сервисов?
- чем отличается Direct Authentication от Brokered Authentication?
- что такое архитектурный стиль?
- и многое другое....
тогда однозначно это будет ваш настольный гайд.
Также рекомендуется в качестве эффективного средства от велосипедостроения.

Кто хочет попробовать .Net 4.0 и VS2010?

Кому интересно, уже доступен для скачивания первый CTP, пока только в виде Virtual PC 2007 image (7.5 Gb). Вот ссылочка.

IT в России убьет не кризис а правительство

Не хотел писать про кризис, но видно придется.
Интересная статья Нужно немножко доплатить...
В дополнение к кризису правительство решило поднять Единый социальный налог. Софтостроители поняли, что им грозит пи#%@&ц.
Вот несколько цитат из статьи:

Дмитрий Лощинин, Люксофт:
"Нам нравится работать в России, но если здесь будут созданы неприемлемые условия для бизнеса, то нам придется отсюда уйти, переведя бизнес в другие страны"

Сергей Андреев, ABBYY Software:
"Фактически, любой зарплатный налог превращается в налог с оборота. Поэтому ИТ-компаниям необходимо добиваться специального налогового режима для своей отрасли"

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

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

Результат не трудно предсказать: массовые увольнения всех, кого можно уволить (джуниоры разработчики, конфликтные разработчики - "примадонны", "лишние" тестировщики, а то и целые команды). Но и оставшимся не позавидуешь. Оставлять будут самых лучших и самых смирных. Потому что на оставшихся повесят работу уволенных. У тех, кто останется зарплату вероятно не порежут, но если у кого была белая зарплата -станет опять серая. А вот на немогочисленные новые позиции будут набирать уже на значительно более низкие ставки, потому как ситуация на рынке труда резко изменится, вакансий станет меньше а безработных программистов больше. Соцпакеты будут резать нещадно и в самую первую очередь. Про дополнительную мед. страховку, оплаченный фитнес и мобильный телефон можно сразу забыть. Если у вас в офисе есть кухня, следите, когда на ней исчезнет бесплатные кофе и печение, значит вот оно - началось :)
Ну как? Страшно?
Впрочем все может быть и по другому. Сокращение заказов на разработку продлится, я думаю, не больше года. Если правительство поддержит разработчиков, даст налоговую передышку, то большинство сможет спокойно пересидеть недолгий спад.

Вышел ASP.NET MVC framework beta

Scott Gu в своем блоге сообщает о выходе бета версии ASP.NET MVC framework. Там же есть ссылка для скачивания. Кроме того, Скот как всегда тщательно и подробно описывает все изменения которые появились в новой версии по сравнению с предыдущей.

Не новость конечно, но так, на память ссылка пусть будет.

Идеальный программист

«Каждый охотник желает знать, где сидят фазаны»
Считалочка (физика, оптика).

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

Каждый менеджер хочет иметь в своей команде хороших программистов. Каждый программист хочет, чтобы его ценили, регулярно прибавляли ему зарплату и не заставляли работать в выходные.
Среди самих программистов есть мнение, что хороший программист – это продвинутый программист, тот который изучает последние технологии, методы и веяния. Сегодня актуально TDD, FDD, AOP, IoC/DI, и принципы ALT.NET. Что бы быть в струе, надо все это знать, все это юзать, и даже, если не лень, писать об этом в своем блоге. Это круто и необходимо для хорошей карьеры и зарплаты. Я должен вас разочаровать - но все это гламур, в самом уничижительном значении этого слова. Все это необходимый фундамент для хорошего программиста, но не более того.

Больше всего на рынке нынче ценится не "умный программист", и не "продвинутый программист", и даже не "опытный программист". Больше всего ценится "эффективный программист". Тем более это актуально для тим-лида. Любой менеджер проекта, отдаст пол своей проектной команды за одного такого. А уж найти «эффективного архитектора» который был бы и технически грамотным и не зацикленном на каком нибуть IoC-е, и вовсе проблема.

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

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

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

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

В общем, ребята, налегайте на soft skills, если хотите карьерного роста.

Как составить резюме

Ну что, коллеги? Не пора ли обновить свои резюме? Кризис на дворе. Вполне возможно, что недостаток программистов скоро сменится недостатком рабочих мест для них. Шутка ;)

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

Конечно, сразу про самые характерные ошибки при составлении резюме:

1. Cлишком много скилов. Часто программисты стараются запихать в свое резюме упоминания всех языков/библиотек/продуктов о которых они хот что ни будь слышали или знают. Есть две веские причины так не делать. Первая, - работодатель практически всегда ищет специалиста для решения конкретных задач, а не мастера на все руки. Не относящиеся к делу скилы могут заставить его думать, что вы специализировались не в той области, что нужна ему. Вторая причина, - множество технологий в резюме заставляют думать работодателя о том, что у вас нет глубоких знаний ни в одной из них. Помните что работодателю нужен специалист, а не дилетант.

2. В резюме нет ключевых слов. Надо понимать, что через руки человека, занимающегося подбором персонала проходят сотни резюме, и ищет он человека удовлетворяющего определенным, совершенно конкретным требованиям, на конкретную позицию. И ищет он по ключевым словам, например, «C/C++, ASM, WDK, Windbg», или «.Net, C#, WinForms, NHibernate». Если этих слов нет на первой странице вашего резюме, то оно моментально летит в trash. Особенно это актуально, когда отбором занимаются HR специалисты, они ориентируются только на ключевые слова в описании вакансии.

3. Заявленные навыки не подтверждаются в описании опыта работы. Если ваше резюме сразу не отправили в trash из-за отсутствия ключевых слов, с ним начинаются знакомиться подробно. Здесь важно, что бы все указанные вами навыки, нашли подтверждение в описании профессионального опыта (списке работ или проектов). Если вы упомянули о ASP.NET, работодатель обязательно поищет, в каком проекте и как вы использовали эту технологию. Если он не найдет этой информации в вашем резюме, он заподозрит вас во лжи, что очень неприятно. Я завернул огромное число резюме с формулировкой «указанные навыки не подтверждаются опытом работы». Что же делать, если вы технологию или язык знаете, но практического опыта его использования не имеете? Не стоит придумывать для этого несуществующий «опыт», поверьте мне. Это, конечно, поможет вашему резюме пробиться на следующую стадию отбора, но сразу всплывет на собеседовании. Различие в теоретическом знании, и знании подкрепленным опытом выявляются очень легко. Поэтому вы можете указать, что ваши знания носят теоретический характер, либо указать в разделе опыта учебный проект, на котором вы изучали данную технологию (если он, конечно, был на самом деле). Это особенно актуально для студентов, не стоит стесняться, в отсутствии опыта учебный проект тоже опыт.

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

5. Напишите, чего вы хотите. Часто забывают, что помимо перечня ваших знаний и умений, в резюме неплохо бы указать, на какую позицию вы собственно претендуете. Без этого все резюме можно выразить одной сакраментальной фразой «Кодирую на Java (C#, C++…) за еду (деньги, большие деньги…)». Кроме того, это поможет избежать недоразумений при дальнейшем общении, и вам не будут предлагать позицию саппортера или консультанта, когда вы ищите работу тимлида.

6. Не пишите много. Никто не будет читать до конца резюме на 5 страницах. Не забывайте, что резюме программиста, это довольно формальный документ. Не стоит засорять его художественным текстом наподобие: «Обладая осознанием высокой ответственности, которая присуща роли разработчика, я целенаправленно развивал навыки…». Возможно, такой стиль уместен в резюме рекламного агента, или PR менеджера, но у IT-шников так писать не принято.

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

8. Никогда не описывайте в своем резюме опыт не связанный с IT. Нет ничего нелепей «программиста C++ с богатым опытом растаможки коммерческих грузов». Я даже не знаю почему, но это очень негативно оценивается теми, кто читает ваше резюме.

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

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

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

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

- Желаемая позиция. Пишите кратко «Разработчик Java начального уровня», или «Архитектор приложений, системный архитектор, руководитель группы».

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

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

- Образование, повышение квалификации, владение иностранными языками. Тут все понятно: ВУЗ, специальность, год окончания. Сюда же пишите курсы и сертификаты и год их получения.

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

Вот, пожалуй, и все. Но страждущие меня не поймут, если я вот так вот закончу, и не приведу образец резюме.
Поэтому, вот вам образец http://docs.google.com/Doc?id=dhksthk6_6fg3gq4 .


P.S. Я пока работу не ищу.

VS2010 "Rosario" - Гонка программных вооружений.

Microsoft анонсировала следующую версию студии и .Net: Visual Studio 2010 и .Net Framework 4.0.
Здесь есть более подробная информация о нововведениях в VS 2010 (code-name "Rosario"), а о .Net 4.0 информации практически никакой нет. Если между выпусками VS 2005 и VS 2008 прошло три года, то следующая версия выйдет через два. Гонка программных вооружений продолжается и набирает обороты.
Основные нововведения должны коснуться расширения поддержки различных аспектов Application life-cycle management (ALM).
Вероятно с одной стороны у создателей VS крепнет понимание того, что software development process состоит не только из кодирования и модульных тестов. Есть еще куча всяких активностей и неплохо бы их поддержать в интегрированном инструментарии.
С другой стороны, менеджмент Microsoft не может не замечать огромного количества open source и third party инструментов разработки активно развивающихся сейчас на широком поле разработки на платформе .Net. Оставлять без внимания такой рынок было бы очень опрометчиво в рамках существующей бизнес стратегии Microsoft, которая состоит в том, что захватив плацдарм, необходимо заполнить собой все рыночные ниши на нем. Хотя на рынке средств разработки, на мой взгляд такая стратегия заведомо проигрышна. Тут деньги не на продуктах зарабатывать надо, а на максимальном расширении базы разработчиков, использующих платформу (как это к примеру делает Sun).
Посмотрим, что будет в 2010 году. Пока же я в 2008-ой студии для модульных тестов использую TestDriven.Net. Просто удобнее.

Комментарии и код

В одном из предыдущих постов vinler задал вопрос о комментариях в коде. Я начал отвечать и понял, что тема интересная, и тянет на отдельный пост.
Итак вопрос:

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

Есть распространенное мнение о том, что хорошему коду комментарии не нужны. И это действительно так. Другое дело, что хорошего кода не так уж много. Поэтому моя точка зрения: не можешь писать хороший код - пиши комментарии.
Не всегда удается написать хороший код. Иногда просто не хватает времени на проработку дизайна, кажется "потом переделаю", но "потом" обычно не наступает никогда. Иногда программисту просто не хватает опыта, чтобы разработать хороший дизайн. В этом случае очень полезно попытаться написать стандартные (для компилятора C#) комментарии к своим классам. После попытки сформулировать короткое описание класса часто наступает "просветление", после которого удается взглянуть на свой код по новому и подправить дизайн. Сам не раз ловил себя на таком.
Другая хорошая привычка, если уж ты чувствуешь в своем коде какой-то smell, но в силу каких-то причин ты не можешь им заняться прямо сейчас, напиши прямо в коде что-то вроде "//здесь воняет". Возможно потом это станет той последней каплей, которая перевесит чашу весов и ты почининишь этот код.
Одни из главных врагов читаемости кода, это невнятное именование и нарушение SRP (Single Responsibility Principle). Основные порождаемые ими проблемы, это невозможность понять по имени класса или метода что они делают, и невозможность отыскать нужный класс или метод. Есть такой парадокс: почти всегда мы считаем свой код хорошим и читаемым, а чужой плохим и невнятным. Происходит это от того, что о своем коде мы всегда знаем больше, чем о чужом. Поэтому никогда не повредит снабдить комментариями свои классы и ключевые методы.
Ну и на конец, если ты пишешь библиотеку для повторного использования, будь добр, прокоментируй публичные контракты всех своих классов. по моему это признак зрелости программиста и проявление уважения к своим коллегам.

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

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

Почтенный юбилей :-)

Двадцать шесть лет назад был придуман смайлик. Вот как это было:

19-Sep-82 11:44 Scott E Fahlman :-) From: Scott E Fahlman I propose that the following character sequence for joke markers: :-) Read it sideways.

Actually, it is probably more economical to mark things that are NOT jokes, given current trends. For this, use :-(

Источник: calend.ru

Я и не думал, что смайл такой старый. Он старше Интернета (в его современном виде www/http/html). И старше большинства из тех, кто им пользуется :)

Правила хорошего кода

«Компетентный программист полностью осознает строго ограниченные возможности своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью»
Dijkstra.

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

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

Итак, правила хорошего кода:

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


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


3. Пишите короткие методы (функции). Есть различные мнения по поводу оптимального размера процедур и функций. Я использую следующий критерий: если весь метод нельзя увидеть целиком на экране или странице – это слишком большой метод. С увеличением размера функции комбинаторная сложность управляющих структур (условий циклов и т.д.) и переменных возрастает нелинейно, и очень быстро начинает создавать проблемы не только в обеспечении надежности кода, но и в его понимании. Зачем вам лишние проблемы? Разделяйте большие функции на более мелкие. Первые кандидаты на выделение в отдельные функции, это сложные условия в предложениях if и тела циклов. Выделяйте в функции отдельные функциональные блоки. Если функция вычисляет и сохраняет, то выделите функцию, которая вычисляет, и функцию, которая сохраняет.


4. Избегайте любого дублирования кода (правило трех О «Once and Only Once»). Существует масса приемов рефакторинга, которые помогают выполнять это правило. Используйте константы вместо литералов, выделяйте повторяющийся код в отдельные методы.


5. Избегайте глобальных переменных (переменных с глобальной областью видимости). Глобальные константы - это хорошо, глобальные функции - это нормально, глобальные переменные – это зло. А как же быть с настройками приложения, спросите вы? Большинство платформ предлагают для этого специальные средства. Если же таких средств нет, используйте глобальные функции вместо глобальных переменных. Вместо Boolean MyGlobalFlag используйте функцию Boolean GetMyGlobalFlag(), которая будет возвращать копию текущего значения вашего глобального флага, а само его значение спрячьте за функциями доступа.


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

   
   public class Action
   {
    public void DoAction(Context context)
    {
     string message = string.Empty;
     If(IsInternal(context))
      message += PrepareInternalMessage(context);
     else
      message += PrepareExternalMessage(context);
     SendMessage(message);
    } 
    private string PrepareInternalMessage(Context context){…}
    private string PrepareExternalMessage(Context context){…}
    private bool IsInternal(Context context) {…} 
    // этот метод тоже должен быть private
    public void SendMessage(string message){…}
   } 
   

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


7. Не совмещайте в одном классе разные обязанности (принцип Single Responsibility Principle). Вот, пример базового класса для реализации действий:
   
   
   

   
   public class ActionBase
   {
    public abstract void DoAction(Context context);
    // полезная фича  - запись в лог
    public void WriteLog(string message){…}
   }  
   

   
   
   
   Здесь программист решил, что функция записи в лог потребуется во всех реализациях классов – действий и поэтому полезно будет ее вынести в базовый класс. Но основное назначение наследников ActionBase это выполнение действий (DoAction), а запись в лог это совсем другая обязанность. Ну и что с того? Вероятно, что запись в лог потребуется не только для классов-действий, но и для многих других классов. И нам придется либо создавать экземпляр класса-действия для записи в лог (т.е. использовать класс не по назначению), либо продублировать метод WriteLog в других классах. Оба варианта неприемлемы. Поэтому метод WriteLog следует вынести в отдельный класс, который будет заниматься исключительно записью в лог.


8. Не разговаривай с незнакомцами (правило Деметры). Внутри метода следует обращаться только:
   
   • К параметрам, переданным в метод (к свойствам и методам этих параметров, если это объекты)
   
   
   • К членам объекта, которому принадлежит метод (this.xxx)
   
   
   • К объектам, созданным в данном методе.
   
   
   
   Цель - избежать связывания с непрямыми объектами.
   


9. При построении иерархий наследования старайтесь не изменять и не расширять публичный контракт базового класса в наследниках. Данное правило напрямую вытекает из известного принципа подстановки Лискоу (LSP - Liskov Substitution Principle). Вот пример иерархии, который надо избегать:
   
   
   

   
   class Shape
   {
    public int X;
    public int Y;
   }
   class Rectangle : Shape
   {
    public int Width;
    public int Height;
   }
   class Circle : Shape
   {
    public int Radius;
   }
   

   
   
   
   Придерживаясь данного правила, вы защищаете уже написанный код от изменений в классах наследниках. Крайне неприятна ситуация, когда в различные места существующего кода приходится вносить многочисленные изменения при появлении нового класса наследника. Обычно такой код насыщен операторами if и case, выполняющими обращения к специфичным членам классов наследников.
   И все же. Наследники часто расширяют контракт базовых классов, достаточно взглянуть на классы .Net Framework. Почему? Такой подход часто оправдан при проектировании библиотек и фрэймворков. В этом случае базовый класс служит не столько для определения базового интерфейса, сколько для размещения логики взаимодействия с механизмами фрэймворка. Пример такой иерархии, компоненты .Net WinForms.
   


10. Разделяйте команды и запросы (принцип QCS - Query Command Separation). Каждый метод должен представлять собой либо команду либо запрос. Метод-команда выполняет какие либо действия, и, возможно, изменяет состояние объекта. Метод-запрос возвращает данные объекта, но не меняет его состояние. Следование данному принципу вы всегда можете быть уверены, что состояние объекта остается неизменным, когда вы используете его данные, и всегда изменяется явно, при вызове методов-команд (к сожалению, возможности большинства языков не позволяет явно указать компилятору, что в методе не допустимо изменение состояния объекта).
    Правильно:
    
    
    

    
    class Counter
    {
     private int  _value;
     public int GetCurrentValue(){ return _value}
     public void Increment(int delta) { _value += delta;}
     public void Decrement(int delta) { _value -= delta;}
    }
    

    
    
    
    Неправильно:
    
    
    

    
    class Counter
    {
     private int  _value;
     public int GetCurrentValue(){ return _value}
     public int Increment(int delta) { _value += delta; return _value;}
     public int Decrement(int delta) { _value -= delta; return  _value;}
    }
    

    
    
    
    

Театр абсурда: iPhone 3G в России

Все бросились продавать и покупать iPhone 3G. И никого не смущает тот факт, что сетей 3G у нас практически нигде нет, а без 3G толку от нового девайса - чуть.
Впрочем, все это уже становится традиционной национальной забавой. Мы закупаем из года в год миллионы новых автомобилей, но нам недосуг построить нормальные дороги для этих автомобилей. Именно недосуг, потому что только на одних автомобильных импортных пошлинах можно было бы пол России в асфальт закатать.
Такие инфраструктурные перекосы всегда были уделом отсталых, колониальных по своей сути экономик, и они очень четко характеризуют сегодняшнее положение России, сколько бы не надувало щеки наше уважаемое правительство.

Programmer's Day!

В этом году 256 (0x100) день выпадает на 12 сентября.
А посему, поздравляю всех коллег с профессиональным праздником, Днем программиста.
Желаю вам чистого и красивого кода, легкой и приятной отладки, и зеленой полосы в юнит-тестах. Горячего, ароматного кофе по утрам и холодного свежего пива по вечерам. Больших и светлых новых проектов и поменьше макарон легаси кода в поддержке. Маленького бэклога и большого бонуса. В общем, всего хорошего, чем богата наша с вами профессия!
С праздником, друзья!

Универсальная метрика качества кода

Замечательную метрику определения качества кода предложил Bob C. Martin на конференции Agile2008.

Она называется "ЧЗХ в минуту" (в оригинале WTFs per minute).

Измеряется очень просто в ходе code review. Вам нужен только счетчик и секундомер. Вы запускаете секундомер и начинаете смотреть код. Всякий раз когда вам хочется сказать или подумать "Что за х....!" - вы щелкаете свой счетчик :). В конце делим показания счетчика на время. Все.
Взято здесь

И они говорят, что это просто сервис-пак...

Patrick Smacchia в своем блоге взял и подсчитал с помощью NDepend изменения в .Net FW3.5 SP1:

Summary:

# Assemblies 112
# Namespaces 919 to 935 (+16 +1.7%)
# Types 39 988 to 40 513 (+525 +1.3%)
# Methods 387 421 to 386 790 (-631 -0.2%)
# Fields 241 567 to 246 795 (+5 228 +2.2%)
# IL instructions 8 598 933 to 8 620 940 (+22 007 +0.3%)

1.393 new public methods
79 new public types
No public types removed (hopefully!)
14 non-public methods became public
6.384 methods where code was changed
2.485 types where code was changed

Вышел .Net Framework 3.5 SP1

Сегодня стали доступны для скачивания Visual Studio 2008 Service Pack 1 (SP1) and .NET Framework 3.5 SP1
Среди всех фич, включенных в SP1, отмечу прежде всего поддержку SQL Server 2008 и релиз ADO.NET Entity Framework. Полный список фич здесь.

Вышел Microsoft SQL Server 2008 RTM

Вчера (6.08.2008) Microsoft объявила о выпуске Microsoft SQL Server 2008. Честно говоря, после всех этих поисков героев и грандиозных запусков, которые идут с самого начала года, эта новость как-то не выстрелила. У публики уже сложилось мнение что SQL-2008, это свершившийся факт.
Ну а нам то что с того? Нам теперь придется поддерживать в старых и новых проектах не две, а три версии MS SQL и надо не запутаться в том, какие фичи где работают, а где нет. А то порой так и тянет написать что-то вроде:

select [Id] from [MyTable] where @@ROWCOUNT > 0 and [Id] = scope_identity()

ан нет, нельзя...
А еще у SQL-2008 новый логотип

Они нас слышат!

В мае, сменился дизайн сайта MSDN Magazine, а вместе с ним и формат URL ссылок. В результате мои заботливо составленные тематические подборочки ссылок на самые интересные статьи перестали работать. Я был ужасно зол, написал об этом в блоге и многие коментаторы разделяли мое негодование.

Так вот, они все починили! Они сделали url маппинг, и все мои старые ссылки сейчас работают. Все таки они нас слышат, и это хорошо. А не ошибается лишь тот, кто ничего не делает.

Как EF влияет на дизайн ASP.NET приложений

Если создавая ASP.Net приложение, вы сумели оторваться от дизайнера ASP.NET страниц, и уже не складываете на странице датасеты, и объекты соединения с БД, значит вы пошли по пути структуризации дизайна вашего web приложения. Наверняка вы выделили классы или модули (сборки) для чтения записи данных в БД, и отдельные классы для представления этих данных и размещения бизнес логики. Возможно вы пошли дальше, и в слое представления выделили логические классы контроллеры, в которые поместили логику организации последовательности действий (workflow), создания представления и валидации пользовательского ввода, оставив в aspx ascx файлах только разметку. А может вы не стали этого делать и функции контроллера оставили в aspx формах.

Как повлияет на сложившуюся архитектуру ваших ASP.NET приложений использование Entity Framework? Хорошая новость состоит в том, что EF наверняка легко впишется в ваше приложение при использовании любого дизайна (даже если вы дружите с дизайнером ASP.NET страниц :).

Однако EF незатейливо подталкивает нас к использованию "анемичной модели", когда классы домена (данные) отдельно, а бизнес-операции (сервисы) отдельно. И это достаточно удобная организация кода.

В качестве классов домена используем сущности EF. Запихивать бизнес логику в partial классы EF я бы не советовал. На этот счет есть много резонов, главные из них:
- вы увеличиваете зависимости между сущностями.
- часто это нарушает принцип single responsibility
- структуры данных меняются чаще чем бизнес правила и объединив то и другое в одном классе вы получите проблемы при внесении изменений.
В partial классы для сущностей EF полезно помещать всякие хитрые свойства (вычисляемые, виртуальные и т.д.), а также логику пре- и пост-валидации значений персистентных свойств (это делается при помощи partial methods, генеримых дизайнером EF).

Бизнес логику лучше помещать в классы сервисы, группируя их по функциональному признаку. Методы бизнес логики строятся по шаблону transaction script. При этом ObjectContext создается либо в для каждой бизнес-операции (внутри метода сервисного класса), либо на уровне контроллера в слое представления, и тогда он предается в методы бизнес логики в качестве параметра.

Какой вариант выбрать - вам решать. Однако,если вы создаете полноценный Service layer - то ObjectConext не должен болтаться в параметрах бизнес-методов. Использование ObjectConext на уровне контроллера в слое представления позволяет более тонко гранулировать бизнес логику и получить за счет этого более эффективное решение (т.е. вместо "больших" бизнес-методов, которые сосредоточенно что-то там делают внутри, вы имеете много "маленьких" бизнес методов, которые получают на вход контекст и вы можете комбинировать их, выстраивая нужную логику). Эффективность может увеличиться в числе прочего, за счет того, что время жизни ObjectConext будет больше, и следовательно, больше возможностей воспользоваться преимуществами кэширования объектов. Важно понимать, что в этом случае вы платите за повышение эффективности большей связностью между уровнями бизнес логики и представления, и вам, в первую очередь, будет сложнее вносить изменения в существующее решение.

Не следует опасаться создавать экземпляры ObjectConext, не следует пытаться создать для хранения контекста каки либо потоковые переменные и, тем более, синглтоны. Дело в том что EF достаточно эффективно кэширует на уровне домена приложения (Application Domain) внутри себя всю метаинформацию, и после создания первого экземпляра ObjectConext, последующие создаются достаточно быстро. Кроме того, ObjectConext не является потокобезопасным, поэтому не следует пытаться использовать глобальный ObjectConext на уровне приложения или сессии.

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

А если бы у него был компьютер...

IT-шникам свойственно преувеличивать значение своих технологий в бизнесе и в жизни. Вот хороший анекдот в тему:

Мужик приходит устраиваться дворником в компанию Microsoft.

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

Затем он начинает ходить по домам и предлагать товар, и меньше чем за 2 часа ему удается удвоить капитал. После того как он повторил то же самое еще 3 раза, у него в кармане было уже 160 баксов. И тут он понимает, что с такими доходами вполне можно жить и без работы! Каждое утро он выходит из дома все раньше и возвращается все позднее, каждый день удваивая, а то и утраивая капитал.

Через какое-то время он покупает машину, затем грузовик, а еще через некоторое время открывает фирму по доставке товаров населению.

Спустя 5 лет он уже является владельцем крупной сети супермаркетов.

И тут, задумавшись о будущем, он вдруг решил застраховать свою жизнь и жизнь всей своей семьи.

После переговоров со страховым агентом тот просит его оставить электронный адрес, на который можно было бы отправить наиболее выгодное предложение, на что коммерсант, как и несколько лет назад, отвечает, что у него нет ни электронного адреса, ни даже компьютера.
— Это удивительно, — недоумевает страховой агент, — у вас такой крупный бизнес и нет электронного адреса! Вы только представьте себе, кем бы вы стали, если бы у вас был компьютер!
Поразмыслив, коммерсант отвечает:
— Я бы стал дворником компании Microsoft.

Terrarium 2.0 теперь в исходных кодах!

Microsoft Windows SDK Blog сообщает что .NET Terrarium 2.0 source code now available!

Не многие наверное помнят, что такое Terrarium. Для тех, кто не в курсе - была такая сетевая игра для программистов. Microsoft запустила Terrarium вместе с выходом первой версии .Net Framework с целью популяризировать новую платформу и языки программирования (C# и VB.NET) среди программистов. Суть игры состояла в том, что надо было используя Terrarium SDK написать класс (унаследовавшись от базового и реализовав нужные интерфейсы), представляющий собой травоядное или хищное животное. Алгоритм поведения задавался кодом, а характеристики (быстрота, агрессивность, незаметность, скорость размножения и т.п.) задавались посредством нового тогда механизма атрибутов. Класс надо скомпилировать, а полученную сборку загрузить на сервер игры. После этого на сервере создавалось 10 экземпляров животных твоего класса (Reflection!) и они начинали "жить", ползая по игровому полю твоего клиента. Клиент игры представлял собой Windows Forms приложение и соединялся с сервером посредством Remoting. Фишка состояла в том, что при благоприятных условиях, твои животные начинали размножаться, а при неблагоприятных - дохли :). Кроме того, по игровому полю медленно летал шар-телепорт. Попавшая в него зверюшка телепортировалась случайным образом на другого клиента (опять ремотинг!). Побеждал тот, чья популяция становилась максимальной. В общем, прекрасная штука для знакомства с .Net. Помнится тогда и в категории хищников и у категории травоядных среди победителей были ребята из Питера (они применили свои наработки в теории конечных автоматов).

Мне же Terrarium, запомнилась тем, что с ее помощью я изучил .Net, фактически круто сменил свою специализацию и устроился на работу .Net разработчиком, имея за плечами в области .Net лишь опыт программирования в Terrarium :)
Такая вот история.

Как работает ManualResetEvent

Ну вот я вернулся из отпуска и после долгого молчания решил разразиться техническим постом.
Меня уже несколько раз приходилось объяснять принцип работы и использования ManualResetEvent. И вот я решил все это подробно разжевать с примерами кода.
Продвинутых коллег сразу предупреждаю, ничего нового и эксклюзивного здесь не будет, если ManualResetEvent для вас не является белым пятном, то дальше можете не читать.

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

static void Main(string[] args)
{
    Thread thread = new Thread(new ThreadStart(ParallelWork));
    thread.Start();
    Console.WriteLine("Main:thread work finished");
}

static void ParallelWork()
{
    Console.WriteLine("Thread:begin work");
    Thread.SpinWait(1000);// что то полезное делаем тут
    Console.WriteLine("Thread:end work");
}

В методе Main() мы создаем и запускаем поток, в котором будет выполнен код метода ParallelWork(). Запустив несколько раз этот код мы можем получить на выходе:
Thread:begin work
Thread:end work
Main:thread work finished
или
Thread:begin work
Main:thread work finished
Thread:end work
или
Main:thread work finished
Thread:begin work
Thread:end work
Обычно ничего страшного в этом нет, ведь параллельное исполнение кода именно для этого и задумывалось. Но иногда у нас возникает необходимость синхронизировать исполнение отдельных участков кода в разных потоках.
Если взять наш куцый примерчик, то предположим, мы хотим, чтобы метод Main дождался завершения метода ParallelWork, и только потом завершился сам. Достичь этого можно разными способами. Например, можно объявить булеву переменную флаг, в метод Main вставить цикл проверки этого флага, а в конце метода ParallelWork выставлять флаг в true. Вот так:

static bool flag = false;
static void Main(string[] args)
{
    Thread thread = new Thread(new ThreadStart(ParallelWork));
    thread.Start();
    while (!flag) ;
    Console.WriteLine("Main:thread work finished");
}

static void ParallelWork()
{
    Console.WriteLine("Thread:begin work");
    Thread.SpinWait(1000);// что то полезное делаем тут
    Console.WriteLine("Thread:end work");
    flag = true;
}

На выходе получим искомое:

Thread:begin work
Thread:end work
Main:thread work finished

за счет того что в методе Main будет молотить холостой цикл while(!flag) ; пока метод ParallelWork() не выставит flag = true. Основной недостаток такого способа синхронизации состоит в том, что холостой цикл очень хорошо грузит процессор.

Ту же самую задачу можно решить при помощи ManualResetEvent.
Вот так:

static ManualResetEvent sync;
static void Main(string[] args)
{
    sync = new ManualResetEvent(false); 
    Thread thread = new Thread(new ThreadStart(ParallelWork));
    thread.Start();
    sync.WaitOne();
    Console.WriteLine("Main:thread work finished");
}

static void ParallelWork()
{
    Console.WriteLine("Thread:begin work");
    Thread.SpinWait(1000);// что то полезное делаем тут
    Console.WriteLine("Thread:end work");
    sync.Set();
}

Как это работает? Очень просто.
У ManualResetEvent есть внутреннее состояние: сигнальное и несигнальное. В сигнальное он переводится методом Set() в несигнальное - методом Reset(). Также начальное состояние ManualResetEvent можно задать и в конструкторе. В нашем случае мы создаем экземпляр ManualResetEvent в несигнельном состоянии.

Самый главный его метод WaitOne(). Когда в коде встречается вызов WaitOne() исполнение приостанавливается, если ManualResetEvent в несигнальном состоянии. А если в сигнальном – WaitOne исполняется без задержки. На этом и основано его использование. Мы заставляем код в главном потоке остановиться и ждать на вызове WaitOne(), пока где нибудь в другом потоке не вызовут Set(). Вызов Set() как-бы подает сигнал другому потоку (или нескольким), который висит и ждет на вызове WaitOne(), после чего этот поток может продолжить свое исполнение. Т.е. WaitOne() по своему эффекту похож на Thread.Sleep(), но с возможностью разбудить поток в нужный момент из другого потока.

Благодаря тому, что ManualResetEvent использует synchronization handle операционной системы, поток ожидающий на вызове WaitOne() действительно приостанавливается, ему не выделяются кванты процессорного времени и он не тормозит исполнение других потоков. И это основное отличие от синхронизации с флагом и холостым циклом. Висеть на WaitOne() может не один а несколько потоков, и все они выдут из ожидания при вызове одного Set().

Напоследок, хочу упомянуть, что рассматриваемую в примере задачу синхронизации можно решить и без ManualResetEvent, при помощи Thread.Join(), однако стоить заметить, что Thread.Join() использует внутри те же механизмы, что и ManualResetEvent

static void Main(string[] args)
{
    sync = new ManualResetEvent(false); 
    Thread thread = new Thread(new ThreadStart(ParallelWork));
    thread.Start();
    thread.Join();
    Console.WriteLine("Main:thread work finished");
}

static void ParallelWork()
{
    Console.WriteLine("Thread:begin work");
    Thread.SpinWait(1000);// что то полезное делаем тут
    Console.WriteLine("Thread:end work");
}

В помощь разработчикам под MS CRM

Если вам пришлось разрабатывать решения на основе MS CRM рекомендую блог Ronald Lemmen. Рональд является MVP как раз в области MS CRM. Помимо того, что в его блоге есть множество полезных ссылок на другие ресурсы, связанные с CRM, Рональд и сам пишет о многих тонкостях, которых вы не найдете ни в SDK ни в KB.
Мне, к примеру, он помог справиться с ошибкой при отладке Callout. Thanks a lot, Ronald!

Surprise! Explicit Enum Cast in C#

О сколько нам открытий чудных

Готовит просвещенья дух.

(с) А. С. Пушкин

Как вы думаете, что выдаст на консоль приведенный ниже код?

public enum Parts
{
 Engine = 1,
 Wheels,
 Brakes
}
static void Main(string[] args)
{
 try
 {
  Parts lineItem = (Parts)4;
  Console.WriteLine(lineItem);
 }
 catch
 {
  Console.WriteLine("Exception");
 }
}

Не знаю, как вы, а я был убежден, что это будет "Exception". Однако на выходе получаем "4". Кстати, если Console.WriteLine(lineItem) заменить на Console.WriteLine(Enum.GetName(typeof(Parts),lineItem)) получим пустую строку. Вот так засада! Явным приведением можно загнать в enum любое значение underlying типа. Судя по обсуждению на RSDN это стало сюрпризом для многих.

Оказывается Anders Hejlsberg пишет в книге "The C# Programming Language":

"Each enum type has a corresponding integral type called the underlying type of the enum type. An enum type that does not explicitly declare an underlying type has an underlying type of int. An enum type’s storage format and range of possible values are determined by its underlying type. The set of values that an enum type can take on is not limited by its enum members. In particular, any value of the underlying type of an enum can be cast to the enum type and is a distinct valid value of that enum type."

Указания на такое поведение есть и в стандарте C#, дык только кто-ж это все читает...
Теперь, когда я думаю о том, сколько кода написано в твердой уверенности, что enum не может содержать никаких значений, кроме объявленных, мне становится как-то не по себе.
Надо взять за правило в switch-ах по enum-мам всегда ставить метку default.

DDNA

Ну какая может быть Силиконовая долина в Дубне, если здесь нет ни одной user group разработчиков, подумал я. Подумал, и решил, настало время собрать группу разработчиков .Net. Поговорил с ребятами - вроде интерес есть. Мощная аббревиатура в заголовке означает Dubna Dot Net Alliance.

И вот 29 мая прошла первая встреча Сообщества .Net разработчиков Дубны, организации которой я посвятил практически весь предшествующий месяц. К сожалению из 18 зарегистрировавшихся пришло только 10 человек. Зато среди них были замечены преподаватели университета :).
Конечно пришлось делать доклад, тема довольно размытая "Эволюция C#" была выбрана с явным расчетом завлечь в сети .Net еще не определившиеся юные души. Впрочем, расчет не оправдался, пришли только матерые .Net-чики :) Не все получилось. Хронометраж не выдержал, кое что из интересных фактов не рассказал, и т.д. Еще раз убедился, что для всякого дела недостаточно только знаний, но нужен навык. Презентационные навыки у меня развиты слабо, надо работать в этом направлении.
Второй доклад делал Юра Михеев о новых возможностях SQL 2008. Тут действительно было интересно, Geo-spatial data, и наконец-то, нормальный тип данных для даты и времени - асана!

И вот парадокс. Сейчас у нас нет недостатка в людях готовых сделать доклады, но есть явный недостаток в людях, которые составили бы аудиторию.

Материалы встречи можно найти на сайте dubna.ineta.ru (По правде, говоря портал ineta.ru настолько глючный, что даже ссылку давать стремно).

P.S. Предвижу злобные комментарии по поводу "силиконовой долины", однако упроно продолжаю использовать этот термин. Кремниевая - слово для русского языка трудновыговариваемое (о!).

Набор .Net патологоанатома

UserDump, WinDbg и sos.dll - это инструменты которыми .Net разработчики пользуются очень редко. Но если ваша программа замечательно работает у вас, но подло глючит у пользователя или заказчика, то без набора этих инструментов вам не обойтись.
Как ими пользоваться рассказывает в своем блоге Юрий Скалецкий.
Как обнаруживать утечки памяти в .Net при помощи sos.dll и windbg описано здесь (во второй половине статьи).
Как снять crash dump при помощи adplus можно прочитать здесь

Темная сторона силы

«Как все плохо: кругом война, смерть, глупость… а мы тут пьём…»
(с) Масяня

С удовольствием читаю блог Джонатана Шварца (CEO and President Sun Microsystems, Inc.). На этот раз он размышляет о той степени открытости и прозрачности информации, которую дает нам Интернет.

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

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

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

Я не хочу знать про труп. Я хочу сегодня быть счастлив. И глобальная сеть мне в этом не поможет.

Ну, надо же!..

Я проверил свои знания русского языка и получил пятерку. Правильных ответов у вас - 8 из 8. Получите заслуженную оценку и порадуйтесь, что не одиноки: столько же верных ответов дали 7% россиян с вашим уровнем образования*. Сходи, проверься?

Тем не менее я делаю очень много ошибок при письме. Это еще раз доказывает, что умение сдавать экзамены, и умение применять знания на практике это две разные вещи. :)

Пополнение в семействе копов

Все наверное знают, что такое FxCop (Microsoft Code Analysis). Если все же кто-то не знает, FxCop - это инструмент, позволяющий проверять выполнение определенных правил кодирования. Теперь в дополнение к нему Microsoft анонсирует выпуск Microsoft Source Analysis for C# (StyleCop) - инструмента для анализа исходных кодов.
В отличие от FxCop, который анализирует бинарники (точнее MSIL), StyleCop аналазирует исходники на C#. Анализирует на предмет удобства чтения, документированности, отступов и т.п. Всего около 200 правил, в том числе:

- Layout of elements, statements, expressions, and query clauses
- Placement of curly brackets, parenthesis, square brackets, etc
- Spacing around keywords and operator symbols
- Line spacing
- Placement of method parameters within method declarations or method calls
- Standard ordering of elements within a class
- Formatting of documentation within element headers and file headers
- Naming of elements, fields and variables
- Use of the built-in types
- Use of access modifiers
- Allowed contents of files
- Debugging text

Загрузить StyleCop можно отсюда

Сказать по правде, я не отношусь к поклонникам подобного рода инструментов. FxCop использую от случая к случаю, в основном, когда надо быстро выполнить формальное ревью большого количества незнакомого кода, чтобы оценить его общее качество. А на счет StyleCop, так по мне, это не более чем средство окончательно задолбать разработчиков.
А вы как думаете?

И опять про MSDN

Данила Корнев, новый MSDN Online Program Manager, в своем блоге сообщает об открытии русского раздела MSDN.
Буквально на днях я обнаружил что все мои закладки на статьи MSDN Magazine перестали работать. А теперь у меня появились новые поводы для недовольства, связанные с MSDN, о чем я хотел сделать комментарий в блоге Данилы, но комментарий сохранить не удалось. Поэтому комментирую здесь.

Данила, не все так здорово. Например на русскоязычной странице "Центры разработчиков" есть ссылка на "Журнал «MSDN Magazine»" и ведет она на английскую страницу MSDN Magazine. Несмотря на то, что существует русская версия. Сейчас на MSDN вообще_нигде_нет_ссылок на русскую версию MSDN Magazine! Зачем его вообще на русский переводят, если прочитать это никто не может.

Раньше можно было почитать русскую версию документации по .Net Framework 1.1 вот по этой ссылке http://msdn.microsoft.com/library/rus/default.asp. Теперь она не работает.
Локализация MSDN Library на русский язык в конце этого года, это здорово. Но зачем ломать то что работает! У тысяч людей есть десятки тысяч закладок на статьи русский MSDN Magazine. С переводом MSDN Magazine на новый URL mapping старые закладки не работают. Ну кто так делает?!!!
На форумах разработчиков есть тысячи ссылок на русскую версию документации по .Net Framework 1.1. Теперь все ссылки протухли. Что вы там у себя сэкономили, пришибив раздел http://msdn.microsoft.com/library/rus/ ?
У вас вообще есть план миграции при разработке новых версий web ресурсов? Будь новый MSDN хоть каким распрекрасным, но если я испытываю проблемы с поиском информации, которую я раньше без проблем находил по своим закладкам, то я считаю, что это плохая работа.

Страшная сила кривых рук

MSDN Magazine Online очень ценный источник информации для разработчиков. С недавних пор он сменил свой look & feel, стал более веб_два_нольным, скжем так. Появились кнопочки для digg, technorati, reddit и т.д., список самых популярных статей и т.д.

Заодно, легким движением руки, какой то добрый человек, сменил способ формирования URL. Была уменя, к примеру, закладочка вот такого вида http://msdn.microsoft.com/msdnmag/issues/06/11/default.aspx?loc=ru , а теперь сделалась вот такого http://msdn.microsoft.com/ru-ru/magazine/cc135434.aspx Чувствуете разницу? И теперь самое интересное - ссылки старого формата не обрабатываются.

У вас есть закладки на статьи MSDN Magazine? Если есть можете их выкинуть. Нет никакого другого способа превратить "issues/06/11/default.aspx?loc=ru" в "cc135434.aspx", кроме как шариться по новому сайту и искать нужную статью, ориентируясь при этом на старый URL.

У меня таким образом протухли десятки ссылок в том числе и на этом блоге (напр., "Подборка материалов по WCF" протухла почти вся).

Кстати, о том что у статей MSDN Magazine существует русский перевод вы теперь никогда не узнаете, если не замените в середине URL "en-Us" на "ru-Ru".

В общем, спасибо тебе, MSDN Magazine, за заботу.

P.S. Если бы я сделал такое в своем проекте, мне бы наверное, руки поотрывали...

Не зьим, так понадкусываю...

Примерно так можно кратко выразить суть очередного заявления Microsoft относительно Yahoo!.
Microsoft продолжает игру в кошки мышки с Yahoo После отзыва своего предыдущего предложения по поглощению, и последовавшего за ним 15% падения акций Yahoo!, Microsoft вновь возвратилась к теме.

Теперь речь идет не о полном поглощении, а возможно, о частичном. Впрочем, Microsoft вполне может снова захотеть съесть Yahoo! целиком, о чем прозрачно намекается в сообщении.

Скорее всего так и будет. Уж очень серьезные ставки в игре. И речь не столько о рынке online рекламы. Основной доход Microsoft получает с десктоп приложений (Windows + Office), а бурное развитие online альтернатив десктопным приложениям представляют серьезную угрозу. Если MS Office занимает что-то около 90% процентов своего сегмента рынка, то платформа Windows Live далеко не на первых ролях. Поэтому надо любыми средствами скупать площадки online сервисов и их аудиторию.

Вдруг действительно эти чертовы online applications выстрелят? Станет тогда Microsoft заурядным производителем браузера, БД и сервера приложений, каких сотни. А что мы тогда будем делать? Кто же тогда будет Большим братом, и будет "во всем виноват"? Компания на букву G?

Entity Framework Breaking Changes. On beta 3 к SP1

В ADO.NET team blog опубликован "Entity Framework Breaking Changes - Visual Studio 2008 & .NET 3.5 SP1 Beta" список изменений, так сказать, не совместимых с жизнью в Entity Framework по сравнению с beta3.
Я надеюсь, что никто не заюзал EF beta 3 в своих проектах. Иначе я им не завидую.

Симпатичный гаджет

я себе на блог урвал. Висит справа внизу на сайдбаре и называется "Поиск по блогу от Quintura". На нем очень симпатично разбегаются и собираются в кучки ключевые слова. Оказывается самое употребляемое мною слово, это "система". Я подозревал что сильно "системлю", но слава богу что не "концептуально" жирным шрифтом вылезло.
Чтоб заполучить такую штучку от Quintura пришлось повозиться, и пройти все круги их афилатной программы. Потом Gmail отправил их письмо в спам (наверное нутром учуял конкурентов). Но все закончилось благополучно, и теперь я счастливый обладатель эксклюзивного гаджета.

P.S. Только не спрашивайте зачем мне два поиска по блогу...

Visual Studio 2008 SP1 Beta & .NET 3.5 SP1 Beta

Вышла бета первого сервиспака VS2008, которая интересна прежде всего тем, что в ее состав включили долгожданный ADO.NET Entity Framework.
Также в состав сервиспака включены пакеты ADO.NET Data Services, ASP.NET Dynamic Data и ряд улучшений для поддержки новых фич SQL Server 2008.
К сожалению в сервиспак не вошел ASP.NET MVC Framework.

Ссылка для скачивания здесь.

P.S. Почитал Скота Гу. Все таки кое какие куски от ASP.NET MVC Framework попали в этот сервиспак. В частности ASP.NET Routing Engine (System.Web.Routing)

Велосипедофобия

"Все мосты через преграды, переброшены без нас" (с) В.Высоцкий

Толкаясь на форумах начал замечать у разработчиков признаки надвигающейся эпидемии этакой "велосипедофобии". Спрашивает человек "Хочу реализовать логирование так-то и так...", а ему в ответ "Зачем изобретать велосипед!!! Есть log4net...", "Чукча не читатель. Чукча писатель. Опять велосипед изобретаешь...". Пишет другой человек статью о способах реализации Persistent Object, а ему в комментах: "Зачем это все надо! Кругом полно ORM-ов выбирай на вкус...". С ORM вообще тяжко стало. Похоже что проектировать свой ORM считается отменной ересью и признаком глубокой задвинутости.

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

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

И в заключение цитата из статьи Тода Хоффа (Todd Hoff) "Scaling Twitter: Making Twitter 10000 Percent Faster". Один из уроков, вынесенных в процессе масштабирования Twitter-а:

Build it yourself. Twitter spent a lot of time trying other people's solutions that just almost seemed to work, but not quite. It's better to build some things yourself so you at least have some control and you can build in the features you need.

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

P.S. На Тода Хофа наткнулся посредством вот этого блога Insight-it. Тематика, в основном, архитектура web приложений. Занимательно. Рекомендую.

Как индусы Northwind поломали

Не волнуйтесь, Northwind починен и доступен для загрузки. Об этом сообщает OakLeaf Systems blog: "Upgraded Northwind.sdf File for SSCE v3.5 Available for Download"

Мелочь, конечно, но интересно другое, а именно то, как об этом пишут:

"Microsoft India's Northwind.sdf sample database file for SQL Server Compact [Edition] (SSCE) v3.5 that ships with Visual Studio 2008 has a defect: Its column names and two foreign-key constraints (Order DetailsFK00 and Order DetailsFK01) contain spaces. As far as I can determine, this is the first sample database from Microsoft since Access 2.0's Northwind.mdb to have spaces in column names."

И далее:

"It might be acceptable to include spaces in column and constraint names in Bangalore but it's not considered a good database design practice in western countries."

Вот так вот :) Тут надо сделать небольшое пояснение. В конце ноября я писал о том, что Microsoft, до сих пор неохотно продвигавшая свои производственные подразделения за пределы США, наконец не устояла и двинула свои офисы в Бангалор. Первыми ласточками стали подразделения User Feedback, Product Download и центр тестирования. С первыми результатами работы этих подразделений мы и имеем теперь дело. Исключительно резкий тон комментариев свидетельствует о том, и сам перенос подразделений в Бангалор и результаты их работы многим не по нраву.
Косячат впрочем не только в Бангалоре. Из-за пробелов в названиях колонок и констрэйнтов в Entity Framework вылетает 5 рантаймов, ну а дизанер того же EF beta 3 полностью валит 2008 студию если получает на вход невалидный XML. Но ошибки Редмонта не вызывают таких резких коментов :)
Впрочем, лучшие умы "народов запада" уже пофиксили священный Northwind и он доступен для скачивания (ссылочка в оригинальном посте).

Печальный конец Borland-а

Borland продает CodeGear (свое подразделение по разработке development tools) компании Embarcadero Technologies (известной своими средствами управления СУБД) за смешные деньги - $23 млн.
Вот такой бесславный конец легендарного для многих программистов брэнда. В самом Borland теперь остаются продукты проектного управления (Caliber, Together, Silk) и пара серверов приложений Borland AppServer на J2EE и Borland VisiBroker на полумертвой CORBA. Ничего особенного, таких продуктов десятки на рынке.

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

С именем Borland связаны названия огромного числа выдающихся продуктов: Turbo Pascal, Turbo C, ObjectVision, Paradox, dBase, InterBase, Quattro Pro, Delphi.
В свое время Borland занимал доминирующее положение на рынке средств разработки и "настольных" БД. Все это сопровождалось чехардой поглощений и продаж, и как следствие, упущенных возможностей.
В 1991 Borland покупает компанию Ashton-Tate - создателя dBase, первой БД для персональных компьютеров. С dBase списаны все последующие настольные БД FoxBase, Clipper, Access и т.д. В руках компании оказываются две замечательных настольных БД: Paradox и dBase. И тем не меннее компания теряет этот рынок, который достался FoxPro, Access и Clipper-у.

Показательно, что постоянно лучшие инженеры покидают Borland и затем создают выдающиеся продукты.
Niels Jensen уходит из Borland и в последствии создает Clarion, очень самобытный продукт, кторый существует и поныне.
Adam Bosworth уходит в 1990 году в Microsoft и там создает Microsoft Access.
И, наконец, Anders Hejlsberg, создатель Delphi (Visual Basic Killer - так хотели назвать его создатели), покидает Borland в 1996 и в Microsoft становится одним из создателей языка C# и платформы .Net.

Еще можно вспомнить бесславную эпопею с переименованием Borland в Inprise и обратно, заигрывание с CORBA, эпопею с InterBase и Firebird. В сухом остатке после всех этих перепетий два не шибко популярных сервера приложений и потеря долей рынков IDE и DB.

Похоже, что 7 мая закончился период полураспада компании. Borland уходит в историю.

CMM как инструмент колониализма

Любопытное и весьма симптоматичное высказывание Эдварда Йордона в его отчете о визите в Россию по поводу распространения CMM у нас:

"Also, I was surprised by the number of people in my presentations who said their software organization had received an SEI-CMM “Capability Maturity Model” assessment, and even more surprised by the number of people who said their IT organization had achieved level-3, level-4, or even level-5. It’s not as high as one might expect in India, but significantly higher than what I’ve seen in the U.S".

Йордон удивлен тем, как много CMM сертифицированных компаний в России, не так много как, допустим, в Индии, но гораздо больше чем в США.
Т.е в самой метрополии CMM никому не нужен. А вот для стран третьего мира, это весьма ценный инструмент, который позволяет среднему американскому менеджеру удостовериться, что эти аборигены знают с какой стороны подходить к компьютеру, и им можно отдавать в офшор свой драгоценный бизнес.

Бардак, он везде бардак

Я с интересом читаю блог Джонатана Шварца (Chief Executive Officer and President
Sun Microsystems, Inc.) Несмотря на его достаточно очевидную маркетинговую составляющую, в нем проглядывает простая человеческая непосредственность (ну или может искусно имитируется).
Последний пост называется "Выбираем свободу" и суть его в том, что на одной официальной встрече Джонатан спрашивает одного большого CTO большой Компании, "а вы используете MySQL?" (Sun купила MySQL? так что он не просто так это спрашивает :). На что большой CTO отвечает: "Конечно нет. Мы используем другую известную и дорогую СУБД". А CISO добавляет: "Мы не можем использовать какой-то там левый MySQL, потому что мы очень серьезная контора!".
И тут оказывается, что разработчики этой большой и серьезной конторы вовсю используют MySQL, и только большие начальники об этом ничего не знают.
Тут Джонатан начинает рассуждать о том как важна свобода, и поэтому Sun это здорово.
А я подумал что бардак, он и в Америке бардак. А CTO и CISO что у них, что у нас предпочитают надувать от важности щеки вместо того, чтобы заниматься делом.

Результаты опроса "В разработке какого типа ПО вы участвуете".

Опрос проводился с течении недели. В нем приняло участие 105 человек, из них 103 занимаются разработкой софта.
Разработкой софта на заказ занимаются 41 чел.
Примерно равное количество респондентов занимаются коробочным софтом и разработкой для Интернета (22 и 20 чел соответственно).
Внутренней автоматизацией заняты 10 чел.
Самым интересным для программистов - разработкой средств разработки, и инфраструктуры занимаются четверо человек.

В виде пирога это все выглядит вот так:


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

Интересно, есть ли где ни будь более объективная статистика на этот счет?

P.S. Зеленый пирог испечен при помощи Google Chart API

Версионный контроль кода в Agile

Интересная статья Хенрика Кнайберга (Henrik Kniberg) Version Control for Multiple Agile Teams на InfoQ.com

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

Для Agile обычно характерно достаточно утилитарное отношение к версионному контролю. Команда небольшая, продукт постоянно в рабочем состоянии, постоянно совершенствуется, поэтому все постоянно работают в одной ветке (в транке). Но не всегда все так просто.

Как работать с версионным контролем когда на проекте несколько Agile команд? Как избежать хаоса при этом? Для чего делать брэнчи для релизов? Каких политик придерживаться при обновлении брэнчей? Как поддерживать код в транке в рабочем состоянии? Про все это и много другое Хенрик рассказывает просто и ясно, без фанатизма, по скандинавски :)
Есть и картинки, которыми истинные аджайлисты любят обклеивать стены офиса. Наподобие этой:


В общем, рекомендую почитать.

Образование и IT. Образование или IT?

Интересная статья в PCWeek профессора Шалыто "Сохраним в университетах лучших" на тему подготовки специалистов для IT вызвала довольно оживленную дискуссию.
Автор утверждает:

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

"Дальше я пояснил, что взяв на работу лучшего, компания получает конкурентные преимущества, а отрасль почти наверняка этого человека теряет, если человек этот, как, например, Дж. Гослинг, не предложит что-то очень важное для человечества в целом. Оказавшись же в университете на преподавательской работе, он может нести “доброе и вечное” другим сильным студентам, которые как раз и пойдут работать к вам в промышленность."

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

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

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

Действительно, уровень выпускников периферийных ВУЗов откровенно слабый из-за слабого преподавания, и тут надо что-то делать. В элитных университетах (МГУ, МФТИ, СПбГУ) дают хорошую системную, математическую и алгоритмическую подготовку, но нигде не дают нормальных знаний того, что относится к технологии программной инженерии. Все знают, что выпускники превращаются в хороших специалистов лишь через два, три года работы в реальных проектах.

Посмотрите на программы обучения на факультете ВМиК МГУ. Я был поражен, когда среди "конструирования компиляторов", "численных методов" и "математических основ криптологии" встретил там курс "Методология внедрения информационных систем". Воистину гора пошла навстречу Магомету, в МГУ программистов учат не только программировать но и внедрять свои программы! Сможет ли читать курс "методология внедрения информационных систем" человек, который со студенческой скамьи сразу перешел за преподавательскую кафедру. Чтобы рассказывать без нервного срыва и матерного слова о внедрении информационных систем, надо отдать этому делу несколько лет жизни.

Действительно, лучшие должны идти в образование. Но не оставаться там после обучения, а возвращаться туда, набравшись практического опыта. Именно так происходит в США, где венцом карьеры для software engineer является если не директорский пост в технологической компании, то профессорская кафедра в престижном университете.

Суперталанты не аннигилируют в индустрии. Тот же Гослинг и его команда пришли к созданию Java долгим и извилистым путем анализа реальных потребностей рынка, а не в тиши университетских лабораторий.
Специфика IT сегодня такова, что зачастую самые мощные инновации и исследования возникают вовсе не в университетах, а в индустрии, в последовательных центрах крупных корпораций и в маленьких стартапах. Это факт, и особенно актуально это для России. У нас нет инновационных учебных центров в области IT наподобие Университета Карнеги-Меллона или МТИ.

Наладить положительную обратную связь между индустрией и университетами для передачи инноваций и опыта, вот что необходимо. Что может подвигнуть успешных профессионалов заняться преподаванием? Деньги? Вряд ли, хотя без них тоже никак, успешный профессионал стоит дорого. Престиж, общественное признание? Пожалуй. И конечно, целенаправленные партнерские усилия компаний и университетов в области обучения. Пока на этом поприще замечены в основном крупные западные компании: Google, Microsoft, IBM. Они готовы инвестировать в обучение. Российские компании, если и рассматривают варианты партнерских отношений с учебными заведении, то в основном с позиций извлечения выгоды (продавать учебные курсы, "покупать" выпускников подешевле, поднатаскав их предварительно). Ну, видимо не созрели еще...