Stump's Workshop

Продолжим?

2011-12-18T11:26:00.000+04:00

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

Мечта одного человека может изменить целый мир

2011-10-06T16:52:00.003+04:00

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

Речь Стива Джобса перед выпускниками Cтэнфорда

Перевод (C) Дмитрий Честных.

“Для меня большая честь быть с вами сегодня на вручении дипломов одного из самых лучших университетов мира. Я не оканчивал институтов. Сегодня я хочу рассказать вам три истории из моей жизни. И всё. Ничего грандиозного. Просто три истории.

Первая история – о соединении точек.

Я бросил Reed College после первых 6 месяцев обучения, но оставался там в качестве “гостя” ещё около 18 месяцев, пока наконец не ушёл. Почему же я бросил учёбу?

Всё началось ещё до моего рождения. Моя биологическая мать была молодой, незамужней аспиранткой и решила отдать меня на усыновление. Она настаивала на том, чтобы меня усыновили люди с высшем образованием, поэтому мне было суждено быть усыновлённым юристом и его женой. Правда, за минуту до того, как я вылез на свет, они решили, что хотят девочку. Поэтому им позвонили ночью и спросили: “Неожиданно родился мальчик. Вы хотите его?”. Они сказали: “Конечно”. Потом моя биологическая мать узнала, что моя приёмная мать – не выпускница колледжа, а мой отец никогда не был выпускником школы. Она отказалась подписать бумаги об усыновлении. И только несколько месяцев спустя всё же уступила, когда мои родители пообещали ей, что я обязательно пойду в колледж.

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

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

Вот вам пример:
Reed College всегда предлагал лучшие уроки по каллиграфии. По всему кампусу каждый постер, каждая метка были написаны каллиграфическим почерком от руки. Так как я отчислился и не брал обычных уроков, я записался на уроки по каллиграфии. Я узнал о serif и sans serif, о разных отступах между комбинациями букв, о том, что делает прекрасную типографику прекрасной. Она была красивой, историчной, мастерски утонченной до такой степени, что наука этого не смогла бы понять.

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

Конечно, нельзя было соединить все точки воедино тогда, когда я был в колледже. Но через десять лет всё стало очень, очень ясно.

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

Моя вторая история – о любви и потере.

Мне повезло – я нашёл то, что я люблю по жизни делать довольно рано. Woz и я основали Apple в гараже моих родителей, когда мне было 20. Мы усиленно трудились, и через десять лет Apple выросла из двух человек в гараже до $2–миллиардной компании с 4000 работников. Мы выпустили наше самое лучшее создание – Макинтош – годом раньше и мне только-только исполнилось 30. И потом меня уволили. Как вас могут уволить из компании, которую вы основали? Ну, по мере роста Apple мы нанимали талантливых людей, чтобы помогать мне управлять компанией и в первые пять лет всё шло хорошо. Но потом наше видение будущего стало расходиться и мы в конечном счёте поссорились. Совет директоров перешёл на его сторону. Поэтому в 30 лет я был уволен. Причём публично. То, что было смыслом всей моей взрослой жизни, пропало.

Я не знал, чего делать несколько месяцев. Я чувствовал, что я подвёл прошлое поколение предпринимателей – что я уронил эстафетную палочку, когда мне её передавали. Я встречался с David Packard и Bob Noyce и пытался извиниться за то, что натворил. Это было публичным провалом и я даже думал о том, чтобы убежать куда подальше. Но что-то медленно стало проясняться во мне – я всё ещё любил то, что делал. Ход событий в Apple лишь слегка всё изменил. Я был отвергнут, но я любил. И, в конце концов, я решил начать всё сначала.

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

В течении следующих пяти лет я основал компанию NeXT, другую компанию, названную, Pixar и влюбился в удивительную женщину, которая стала моей женой. Pixar создал самый первый компьютерный анимационный фильм, Toy Story, и является теперь самой успешной анимационной студией в мире. В ходе поразительных событий, Apple купила NeXT, я вернулся в Apple, и технология, разработанная в NeXT стала сердцем нынешнего возрождения Apple. А Laurene и я стали замечательной семьёй.

Я уверен, что ничего из этого не случилось бы, если бы меня не уволили из Apple. Лекарство было горьким, но пациенту оно помогло. Иногда жизнь бьёт вас по башке кирпичом. Не теряйте веры. Я убеждён, что единственная вещь, которая помогла мне продолжать дело была то, что я любил своё дело. Вам надо найти то, что вы любите. И это так же верно для работы, как и для отношений. Ваша работа заполнит большую часть жизни и единственный способ быть полностью довольным – делать то, что по-вашему является великим делом. И единственный способ делать великие дела – любить то, что вы делаете. Если вы ещё не нашли своего дела, ищите. Не останавливайтесь. Как это бывает со всеми сердечными делами, вы узнаете, когда найдёте. И, как любые хорошие отношения, они становятся лучше и лучше с годами. Поэтому ищите, пока не найдёте. Не останавливайтесь.

Моя третья история – про смерть.

Когда мне было 17, я прочитал цитату – что-то вроде этого: “Если вы живёте каждый день так, как будто он последний, когда-нибудь вы окажетесь правы.” Цитата произвела на меня впечатление и с тех пор, уже 33 года, я смотрю в зеркало каждый день и спрашиваю себя: “Если бы сегодняшний день был последним в моей жизни, захотел ли бы я делать то, что собираюсь сделать сегодня?”. И как только ответом было “Нет” на протяжении нескольких дней подряд, я понимал, что надо что-то менять.

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

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

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

Смерть тогда подошла ко мне ближе всего, и надеюсь, ближе всего за несколько следующих десятков лет. Пережив это, я теперь могу сказать следующее с большей уверенностью, чем тогда, когда смерть была полезной, но чисто выдуманной концепцией:
Никто не хочет умирать. Даже люди, которые хотят попасть на небеса не хотят умирать. И всё равно, смерть – пункт назначения для всех нас. Никто никогда не смог избежать её. Так и должно быть, потому что Смерть, наверное, самое лучше изобретение Жизни. Она –причина перемен. Она очищает старое, чтобы открыть дорогу новому. Сейчас новое – это вы, но когда-то (не очень-то и долго осталось) – вы станете старым и вас очистят. Простите за такой драматизм, но это правда.

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

Когда я был молод, я прочитал удивительную публикацию The Whole Earth Catalog (“Каталог всей Земли”), которая была одной из библий моего поколения. Её написал парень по имени Stewart Brand, живущий тут недалеко в Menlo Park. Это было в конце шестидесятых, до персональных компьютеров и настольных издательств, поэтому она была сделана с помощью пишущих машинок, ножниц и полароидов. Что-то вроде Google в бумажной форме, 35 лет до Google. Публикация была идеалистической и переполненной большими идеями.

Steward и его команда сделали несколько выпусков The Whole Earth Catalog и, в конце концов, издали финальный номер. Это было в середине 70–х и я был вашего возраста. На последней странице обложки была фотография дороги ранним утром, типа той, на которой вы, может быть, ловили машины, если любили приключения. Под ней были такие слова: “Оставайтесь голодными. Оставайтесь безрассудными”. Это было их прощальное послание. Оставайтесь голодными. Оставайтесь безрассудными. И я всегда желал себе этого. И теперь, когда вы заканчиваете институт и начинаете заново, я желаю этого вам.

Оставайтесь голодными. Оставайтесь безрассудными.

Всем большое спасибо.”

WANTED! Требуются крутые специалисты в Дубну

2010-04-08T10:38:00.003+04:00

Upd. 27.05.2010. Вакансии закрыты. Спасибо всем откликнувшимся.

В офисе Luxoft в Дубне открыты две интересные вакансии: разработчика и инженера по тестированию. Требования весьма высокие, но и проект интересный - разработка средств статического анализа кода для Visual Studio.
Если вы крепкий специалист, имеете опыт в описанных ниже областях, и чувствуете в себе силы поучаствовать в таком проекте, то поверьте, вы можете очень много почерпнуть для себя в профессиональном плане здесь, у нас.
Ну, и помимо всего прочего, у нас отличный офис, и прекрасные условия для жизни и отдыха. Летом в обеденный перерыв можно куаться в Волге, это не шутка. Водные лыжи, острова, велосипеды, джазовые фестивали, все это Дубна lifestyle :)
Иногородним - помощь в перезде и подборе жилья.

Требования к кандидату на позицию Visual Studio Integration Package developer

Глубокие знания .NET Framework 3.5 (многопоточность, асинхронные вызовы)
Глубокие знания ООП/ООА. Шаблоны проектирования.
Знания алгоритмов работы со структурами данных (списки, деревья)
Обязательный опыт разработки WinForms приложений на основе MVC/MVP.
Обязательные знания WCF, WS-*
Опыт разработки юнит тестов.
Понимание COM модели программирования.

Английский язык – Upper-Intermediate
Огромный плюс – знакомство с Visual Studio SDK. Опыт разработки VSIP.

Требования к кандидату на позицию Desktop Plugin Functional Tester

MUST HAVE Strong English skills (reading/writing)
MUST HAVE Demonstrable knowledge in SQE practices, principles, strategies and techniques. Understanding of defect life cycle
MUST HAVE Knowledge and understanding of any object-oriented language code for testing purposes (Preferably Java or C++, C#), including ability to write simple programs, and reading code.
MUST HAVE Experience in Windows, Linux, Mac OSX
MUST HAVE Experience in writing test cases
MUST HAVE Experience with Integrated Development Environments: Eclipse/Visual Studio

NICE TO HAVE Experience with any testing automation tool, such as SilkTest, Rational Functional Tester, Load Runner, etc.
NICE TO HAVE Comfortable with at least one scripting language, e.g.. perl, python
NICE TO HAVE Some basic Java knowledge. Experience in Squish automation tool.

Обратите внимание что на обе вакансии требуется strong English. Вы должны быть готовы к телефонному интервью с парнями из San Francisco, CA

Присылайте резюме на мой адрес srozovik[at]gmail.com

P.S. Это не мой проект. Я просто передам ваши резюме всоему коллеге, менеджеру проекта.

Эх, браузеры...

2010-03-30T16:16:00.000+04:00

Нет счастья в этой жизни. Замучили браузеры. Мозила слишком долго грузится. IE постоянно сваливается, и все больше сайтов, которые в IE отображаются криво.
Пересел на Google Chrome, так этот со вчерашнего дня перестал отображать чекбоксы и радиобатоны на всех формах.
Может кто знает, как лечится?

Кампус

2010-01-28T21:17:00.002+03:00

Многие знают какие замечательные кампусы у Google, Microsoft или Sun. А у нас в Дубне не хуже.
Вот шел с работы и обратил внимание, что включена вся иллюминация, и рука сама потянулась в рюкзак за фотоаппаратом.

Смотрите - это Дубна, улица Программистов. Здесь куют Русский силикон :))

Остается добавить, что за бортом было, что-то около -25...

Это кросс-пост с персонального блога

iPhone переросток, или Стив Джобс вам покажет, как надо продавать таблетки

2010-01-27T22:45:00.004+03:00

Ажиотаж вокруг гипотетического планшета от Apple умело подогревался все последнее время. И вот наконец сегодня Стив Джобс, наконец, представил, как он сам его охарактеризовал, ни много ни мало, дело всей своей жизни - планшет iPad. Я думаю стив не шутил, потому что сегодня на главной странице www.apple.com один большой iPad и ничего более.
В среде аналитиков заметно некоторое недоумение, вызванное тем, с каким пафосом презентован iPhone переросток. Планшеты или таблетки (по-моему термин Microsoft) известны давно, но большого успеха никогда не имели. Весь рынок этих устройств оценивается что то около 700 млн $. Кое-кто говорил, что планшеты - это вообще бесперспективно, и нетбуки вытеснят планшеты в нишу простых читалок, вроде Amazon Knidle.

Смею предположить, что скоро всем скептикам станет очевидна огромная перспективность рынка планшетов :) Что планшет - это именно то, чего всем нам не хватало. Далее последует череда убийц iPad-а, ну и т.д. как обычно :) А Apple в очередной раз продемонстрирует, как надо продавать. Только вот повторить урок, что-то ни у кого не получается.
На сей раз рецепт успеха выглядит следующим образом.
9,7 дюймововый мультитач дисплей 12,5 мм толщиной и 680 граммов весом. 10 часов работы. Камера, Wi-Fi, 3G, 16 - 64 Гб флэш памяти. Гламурный чехол и 140 тысяч приложений для iPhone, которые без проблем запускаются на и на старшем брате.

Программная инженерия от Сергея Орлика

2010-01-27T20:46:00.005+03:00

Хорошая новость. Сергей Орлик опубликовал сайт "Основы Программной Инженерии(по SWEBOK)"
По сути, это перевод SWEBOK с коментариями и замечаниями авторов перевода.
SWEBOK - это свод знаний по программной инженерии. Отношение к разработке софта, как к инженерному процессу - это, на мой взгляд, именно то, чего весьма не хватает русскоговорящему программному сообществу. За последние 5-7 лет мы хорошо продвинулись в плане освоения новых технологий. Сегодня не проблема найти программиста с глубокими знаниями Spring, Hibernate, Pyton или Ruby. Выросла целая армия .Net программистов и почти никого не вводят в ступор Mock objects или Dependency Injection.
Однако в плане организации процесса в большинстве компаний разработка ведется практически на голой коленке. А ведь успех разработки зависит от правильного использования технологий хорошо, если процентов на пять. Остальное - terra incognita, с раскиданными повсюду граблями, на которые не устают наступать все новые поколения разработчиков. Практически все, что знает о разработке софта средне-статистический программист умещается в главе 3 "Конструирование". А глав там - одиннадцать. Делайте выводы.
Сергей Орлик, один из тех, кто протаптывает для нас тропинки на этой неведомой территории, расставляет флажки и помечает грабли.
За это ему наш глубокий респект.

Нестыковочка

2010-01-27T16:07:00.004+03:00

Продолжаем тему "государство и информационные технологии".
Теперь Федеральная налоговая служба отличилась. ФНС создала не что ни будь а web сервис(!), под названием "Личный кабинет налогоплательщика". Специально для физических лиц.
А мне в конце прошлого года письмецо было из налоговой, что мол пора бы заплатить налог на недвижимость. Заплатил. И вот теперь, думаю, гляну ка я как там мой налог на недвижимость поживает. Захожу я в свой личный кабинет налогоплательщика, ввожу ИНН, фамилию, имя, жму на кнопку и получаю:

"Ошибка ввода. Некорректный ИНН".

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

Delivery to the following recipient failed permanently:

lkp@gnivc.ru

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.1.0 Sender denied (state 13).

Хороший сервис, наверное. Жаль не работает. Хотя может кому-то удалось этим сервисом воспользоваться?

P.S. Оказалось что ИНН был действительно с ошибкой, хотя взял я его из своего заявления на вычет, и вычет я, кстати, получил :)
Дома нашел свидетельство о выдаче ИНН и все заработало. А вот мыло мое почему зарежектил их сервер - не понятно. Я вроде не спамер.
А вообще, сервис полезный.
Да, у меня тоже пеня :)

Великий Русский Файервол

2009-09-25T08:44:00.004+04:00

– Вылупился, – спокойно сказал Роман, глядя в потолок.
– Кто? – Мне было не по себе: крик был женский.
– Выбегаллов упырь, – сказал Роман. – Точнее, кадавр.
– А почему женщина кричала?
– А вот увидишь, – сказал Роман.

"Понедельник начинается в субботу" А. и Б. Стругацкие.

Читаю сегодня с CNews "ФСБ и Минсвязи защитят чиновников от Google"

На заседании правительственной комиссии по федеральной связи и ИТ Александр Гридин, генеральный директор ФГУП «НТЦ Атлас», предложил создать программно-аппаратный комплекс для обеспечения сетевой анонимности госслужащих. По его мнению, необходимо разработать отечественный прокси-сервер, блокирующий возможность анализа их сетевой активности зарубежными службами.
Кроме того, сервер, по задумке Гридина, будет генерировать необходимое количество маскирующих запросов к интернет-ресурсам, чтобы дополнительно затруднить анализ.
«Нужно создать платформу на базе как Windows, так и Linux, с сертифицированными криптосредствами, браузер под обе эти ОС и доработать типовые серверные приложения - поддержал идею «Атласа» Анатолий Лакаев, директор НИИ «Интеграл» - Мы готовы взяться за эту работу и совместно с ФСБ и «Атласом» выполнить ее в течение года».

Если кто не в курсе, ФГУП «НТЦ Атлас», это контора которая создала скандально известную систему контроля за оборотом алкоголя ЕГАИС, из-за внедрения которой, как вы помните, летом 2006 года с прилавков исчезла вся водка и вино.
Не приходится сомневаться в том, что эти ребята способны родить файервол, который наглухо перекроет чиновникам доступ в интеренет, просто из-за того, что будет как обычно неработоспособен.
Вопрос в другом. А нафига собственно чиновников защищать от Гугла и Яндекса с Бегуном? Чтоб никто не узнал, что основной трафик в МВД идет с порносайтов? Для чего еще надо скрывать сетевую активность чиновников?
Иное дело Агенты Национальной Безопасности. Эти, да, должны быть инкогнито по определению. Однако вряд ли они захотят пользоваться продуктом «НТЦ Атлас».

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

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

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

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

WTF

2009-08-28T09:21:00.004+04:00

Скажите, что должен чувствовать программист, когда вот для примерно такого кода:


float speed = Float.NaN;
if (speed == Float.NaN)
   Dialog.alert("Not a number");
else
   Dialog.alert("Shit happens...");

он видит на экране "Shit happens..."?
Ага, такое дерьмо приключилось вчера со мной, когда я ковырялся в реализации J2ME от одного вполне уважаемого вендора. Убив на проблему около часа, я совсем было отчаялся, решил что я уже слишком стар для таких приколов, и пора мне завязывать с программированием. Однако, неожиданно, замена (speed == Float.NaN) на (Float.isNaN(speed)) решила проблему. Дерьмо исчезло.
Но запах остался...
Продолжаю программировать.

Google меня уважает.

2009-07-23T09:21:00.003+04:00

Я вчера тут пожаловался, на то что Google без предупреждения сменил дизайн моей домашней страницы в iGoogle, и даже с горя горзился уйти с этого сервиса.
Ну народ в коментах поглумился, дескать "напугал козла капустой"... Тем не менее, сегодня утром моя домашняя страница вернулась к прежнему виду. Возможно причиной тому было наличие реальных багов в новом дизайне iGoogle, но мне все же хочется верить что это и мой глас вопиющего был услышан. Если это так, то Google - человечище. Как разработчик знаю, как не легко порой любить пользователей своих прдуктов, в то время когда хочется просто их прибить всех. Ты им новые фичи, а они на тебя с кулаками :)

Ну, в общем я доволен. Google, слышишь? Я тобой доволен!

Firefox занят, Firefox-у некогда.

2009-07-22T16:29:00.002+04:00

Сегодня просто день обломов какой-то.
У нас на проекте сборка крутится на Хадсоне. Удобная штука, но с моим браузером IE не дружит в последнее время. Поэтому хожу на сборочный сервер я при помощи Firefox.
И вот запускаю я Firefox, чтоб пойти на сервер сборки и собрать новый билд, а Firefox мне и говорит:

"Firefox загружает обновление. Подождите несколько минут."

Вот так. Firefox важным делом занят, а тут я со своей дурацкой сборкой....

Google - ты меня уважаешь?

2009-07-22T10:43:00.002+04:00

Если кто не в курсе, у Goole есть такой сервис iGoogle - сервис персонализированных страниц. Я использую iGoogle в качестве домашней страницы, все что мне надо для повседневного серфинга разложено по шести вкладкам на моей странице iGoogle.

И вот сегодня утром я обнаружил свою домашнюю страницу в совершенно непотребном состоянии. Ярлыки вкладок уехали на левую сторону страницы и ведут себя неадекватно, лэйаут поломан, внизу появился какой то Google chat...
Первое впечатление - просто шок. Ощущение как будто кто-то покопался ночью в ящиках моего рабочего стола и оставил все там в верх тормашками. Кто-то хакнул мою домашнюю страницу! Почти полчаса я потратил на бесплодные попытки вернуть все как было, пришлось даже лезть и RTFM. Все тщетно. Мануалы усиленно делали вид, что так было всегда. Великий Google решил, что моя персональная домашняя страница отныне должна выглядеть именно так. Отката не предусмотрено.

Я подозреваю, что настоящая причина, ради которой так бесцеремонно была поломана моя домашняя страница - это засунуть ко мне на страницу этот самый Google чат. Ребята, мне не нужен Google чат здесь! Вы меня спросили? Сначала впендюрили его в web интерфейс Gmail, теперь вот прямо ко мне домой затащили его. Ночью. Без спроса. Выключить нельзя.

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

IE8 - первые впечатления

2009-03-21T20:02:00.003+03:00

Установил IE8. Работает действительно быстро, примерно как Chrome. Особенно это заметно после IE7, даже мерять не надо, на глаз видно.
Плюс - все привычные примочки остались на своих местах, обобенно мой любимый Google Toolbar. Понравились акселераторы.
Минус - пока один. В IE8 Не работает Puntoswitcher. Может потом еще что нибудь вылезет.
Совершенная загадка - цвет ярлыков вкладок. Они то голубые, то зеленые, то малиновые, то желтые. Никак не пойму, от чего зависит их цвет. Причем он постоянно меняется.
Но, блин, быстро работает. Даже не похоже на IE...

Похоже, не ждали...

2009-03-17T22:41:00.001+03:00

Свершилось, наш офис переехал на левый берег, в комплекс офисов Особой экономической зоны. Теперь наш адрес Дубна, ул. Программистов 4 корпус 3. Вот этот самый:

Справа на третьем этаже наши окна.

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

Пробираться в офис пришлось через черный ход. На месте парадного - груды строительного мусора, его вывозят второй день и конца нет. Коридоры встретили нас бодрым стрекотом перфораторов и толстым слоем строительной пыли. В потолке третьего этажа зияют выдолбленные аккуратные дыры, как от гранатомета с видом на хмурое мартовское небо - строители забыли заложить какие-то коммуникации и теперь правят свои "баги". Видимо дом для программистов решили строить так же, как программисты делают свои программы :).
Лифты очень красивые, блестят хромом, но не работают. Даже кнопок нет. Замысловатые зигзаги коридоров с первого раза осиливал не каждый, и то и дело из-за очередного поворота доносились бессмертные цитаты персонажа Семена Фарады из "Чародеев" - "Люююди!!!" и "Ну кто так строит?!".

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

А в общем, не все так плохо. Уйдя в пятницу вечером из одного офиса, в понедельник утром в 10 часов мы уже запустили все свои проектные сервера, а в 11 - уже собрали новый билд - 255-ый по счету (единички не хватило до круглого числа). Отличный показатель для офиса который кишмя кишит программистами, на каждого из которых приходится по паре серверов не считая рабочих станций. За это нашим админам Мише и Марине - респект и уважуха.

Это кросс-пост из личного блога.

Что общего между Android и .Net?

2009-02-28T00:47:00.003+03:00

Думаете ничего? Забавные и неожиданные параллели обнаруживаются порой в развитии информационных систем.
Все знают о том, что в прошлом году Google запустил Android - свою мобильную платформу. Android построен на ядре Linux, а прикладные приложения выполняются в виртуальных машинах (sandbox) и для их разработки используется Java. Или, вернее, язык с синтаксисом Java и библиотеки анлогичные Java SE. А в качестве среды исполнения вместо JVM используется виртуальная машина Dalvik. Сразу возникает резонный вопрос, а зачем вообще Google понадобилось изобретать велосипед, почему не использовать стандартную для мобильных устройств Java ME? Вроде бы Google не намерен зарабатывать непосредственно на софте для Android. Кроме того, использование Java ME обеспечило бы переносимость огромного количества мобильных приложений на новую платформу.
Однако тут все не так просто, и как уже заметили многие все дело в лицензионной политике. В случае с Java ME, Sun продемонстрировала просто чудеса ~~иезуитства~~ изобретательности, выпустив ее сразу под двумя лицензиями: GPLv2 и коммерческой. А это вынуждает производителей, использующих Java ME либо открывать весь свой код, либо... платить Sun :)

Естественно, все это не укладывалось в рамки политики, которую избрал Google для продвижения Android. В отличие от Sun, у которой хорошие юристы, Google решил положиться на своих инженеров и... создал свою реализацию виртуальной машины. Причем, Dalvik - это не просто новая реализация JVM (которую все едино пришлось бы лицензировать в Sun), Dalvik вообще не использует Java байт-код (вернее байт-код, полученный в результате компиляции в design-time преобразуется в dex формат, который и используется в run-time). В общем, инженеры Google обставили лоеров Sun. Неудивительно, что мы не видим Sun в списке участников Open Handset Alliance. Тем не менее в Google предпочитают не заострять внимание на этом вопросе, и когда речь заходит о Dalvik они предпочитают говорить об оптимизации своей виртуальной машины под специфику мобильной платформы, позволяющей запускать множество экземпляров, и т.д. и т.п.

Интересно, что девять лет назад подобная история имела место в отношении Sun и Microsoft. И в результате на свет появился еще один "язык, похожий на Java" и "еще одна реализация виртуальной машины" - .Net. Практически все увидели в этом ответ Microsoft SUN и его платформе Java. Новый язык был очень похож на Java по синтаксису, а платформа весьма напоминала JRE. Тогда еще у всех на памяти было противостояние MS и Sun на почве Java, которое закончилось грандиозным скандалом, судебным иском Sun против Microsoft и последующим мировым соглашением. Суть претензий Sun заключалась в том, что Microsoft внесла изменения в свою реализацию JVM, которые делали ее несовместимой со спецификациями Sun и давали преимущества Java программам, исполняемым под Windows. В результате судебных тяжб Microsoft потеряла возможность развивать свою версию JVM. Это, собственно, и стало основным политическим мотивом для создания .Net Framework.
Тогда Microsoft также предпочитала говорить не о борьбе с Sun, а о необходимости более тесной интеграции с WinAPI и COM.

История повторяется. Но .Net - это закрытая проприетарная платформа, ориентированная на Windows, которая за 9 лет так и не смогла существенно постенить Sun и Java с занимаемых ими позиций. А вот с Android все выглядит более серьезно, и более угрожающе. Сегодня у Sun есть реальные шансы потерять платформенное лидерство. Как бы им не повторить судьбу DEC и Compaq.

Модульные тесты для SilverLight

2009-02-25T13:47:00.002+03:00

SilverUnit (другое название CThru) - движок для модульного тестирования SilverLight.
Интересно, что
- тесты могут исполняться в обычном NUnit или MS Test tools без специальной Silverlight-компиляции
- тесты исполняются в обычном CLR runtime, не в silverlight.

В общем полная изоляция. А все потому, что SilverUnit построен на базе Typemock Open-AOP API.

Как проводить телефонное интервью

2009-02-22T13:54:00.004+03:00

В блогах полно статей для кандидатов о том, как проходить интервью. Этот пост наоборот, для тех кто проводит интервью.

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

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

1. Имейте в запасе побольше вопросов. Составьте вопросник по тому языку, платформе, framework, знания которых требуются от кандидата. В моем вопроснике по .Net более сотни вопросов, плюс около полусотни вопросов по RDBMS. Избегайте прямых вопросов о конкретных классах, ответы на которые легко читаются из документации. Например, вместо вопроса о классе XmlDocument спрашивайте о том, как работать с Xml DOM.

2. Начинайте с простых вопросов. С самых элементарных. Например таких "Собеседование. Вопросы на засыпку"). Если человек начинает плавать на простых вопросах вы можете быстро свернуть интервью, сэкономить свое и чужое время. От простых вопросов переходите к более сложным. Если кандидат знает, что такое XmlDocument, попросите его рассказать о том, как в XmlDocument добавить новый элемент.

3. Свободные вопросы - наиболее мощный инструмент при проведении телефонного интервью. Свободный вопрос - это когда вы просите кандидата рассказать все, что он знает по какой-то теме. Например, «Расскажите, что вы знаете о многопоточном программировании на .Net», или «Расскажите, что вы знаете об использовании триггеров в SQL». Старайтесь не перебивать человека, когда он отвечает на такой вопрос, он сам покажет ширину и глубину своих познаний. Можете попросить его уточнить какие либо детали, или направить его рассказ в нужное русло, подсказками.

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

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

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

Несовместимость

2009-02-19T00:10:00.002+03:00

2 учетки на Gmail + IMAP + Outlook2003 = это просто разрыв мозга. Помучавшись два дня прибил эту химеру.

Мы строили, строили...

2009-02-13T10:14:00.002+03:00

Оказывается, у нас в стране есть "Совет по развитию информационного общества при президенте России". Вчера этот ареопаг заседал в Кремле. Президент удивлен:

"По индексу развития электронного правительства мы были в 2005 г. на 56-м месте, а в 2007 г. достигли 92-го"

Вот тебе и "Электронная Россия". Если бы президентом у нас был товарищ Сталин, то он бы решил что все это диверсия. Но президентом у нас товарищ Медведев, человек культурный. Он все понимает:

"О чем это говорит? Это говорит о том, что у нас никакого электронного правительства нет, все это — химера."

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

Какие выводы сделаны ареопагом? Известно какие. Назначить дополнительных чиновников, ответственных за информатизацию. Выделить дополнительно бабла для распила.

Я думаю года через два, мы достигнем таки дна того рейтинга, про который говорил президент.

Microsoft Tag

2009-02-09T19:41:00.004+03:00

Microsoft анонсировала новую технологию для мобильных устройств - "Tag"
Все до безобразия просто. Если вы видите вот такую картинку:

вы наводите на нее камеру своего мобильника и тут же попадаете на URL который зашифрован в ней. Потому что картинка эта - баркод. Конечно для таких чудес надо установить Microsoft Tag Reader. Что интересно, есть версии не только для WinMobile, но и для iPhone, Symbian S60, BlackBerry, и наконец J2ME. Скоро обещают версии для PalmOS и Android.
Формат кодирования картинки не раскрывается. Судя по всему в картинке зашифрован не сам URL, а некий хэш код, который отправляется на сайт Microsoft Tag, а уж оттуда броузер редиректится на нужный URL. Для чего такие сложности? В самой картинке зашифровано довольно мало информации, что-то в районе 8-10 байт. Т.е. URL там попросту не помещается.
Для того чтобы создавать свои tag-и надо иметь эккаунт. Пока все бесплатно, но Microsoft оставляет за собой право сделать технологию платной для паблишеров после окончания периода бета тестирования.
Попробовал я как это все работает на мобильнике с WM 6.0. Бывает сканер схватывает картинку в доли секунды, а иной раз приходится дерижировать камерой над картинкой несколько секунд.
В-общем идея очень свежая и интересная.
Скачать TagReader на телефон можно здесь
А на картинке, кстати, ссылка на RSDN.

Шпоры от J.D. Meier по архитектуре приложений

2009-01-23T12:05:00.002+03:00

Очень хорошие выжимки в стиле шпаргалок по архитектуре различных типов бизнес приложений готовит J.D. Meier

Клиент сервер (толстый клиент) (не модный нынче и не гламурный)

Трехуровневый Rich Internet Application (модный и гламурный)

Четырехуровневый Web Application с выделенным слоем сервисов и Table Module внутри (для корпоративных чуваков, реально озабоченных вопросами безопасности, которые все делают "по Фаулеру")

Обычный трехуровневый Web Application с ORM внутри (самый популярный, пожалуй)

REST web сервис (да - да, REST на платформе Microsoft, кто бы мог подумать...)

Один недостаток у этих шпоргалок. Чтобы получить от них пользу, надо знать что такое "Dependency Inversion", "Entity Translator", "Table Data Gateway", "Page Controller" и еще кучу всяких вещей. Но если ты все это знаешь, то и шпоргалки тебе видимо уже не нужны :)

Listma - .Net Workflow framework

2009-01-05T14:19:00.003+03:00

Что вы делаете, когда вся логика разрабатываемого класса крутится вокруг его состояния? К примеру, разрабатываем мы web магазин. Есть у нас сущность Order (заказ), ее создает «покупатель», затем он ставится в очередь на обработку, затем «оператор» формирует заказ и передает его «курьеру» для доставки, «курьер» доставляет заказ и делает отметку о доставке. Покупатель может редактировать все поля заказа, пока не передаст его на исполнение. После этого покупатель не может редактировать заказ, но может отозвать его, но только если заказ еще не передан для доставки. Оператор не может редактировать заказ, но может оповестить покупателя о задержке в связи с отсутствием товара на складе. Курьер может только проставлять отметку о доставке и только на тех заказах, что переданы для доставки ему. Ну и т.д. (много деталей опущено).

Довольно типичная картина, не правда ли? Действия доступные пользователям зависят от их роли и текущего состояния сущности, причем все эти особенности и детали способны утомить еще при чтении требований, не говоря уж о реализации. И в тоже время они являются весьма важными с точки зрения заказчика. А при реализации они размазываются тонким ровным слоем по всей бизнес логике и по UI в придачу. Ситуацию усугубляет то что, все эти требования очень волатильны, то есть склонны к частым и непредсказуемым изменениям. И вот он – живой кошмар любого разработчика перед нами во всей красе.
Однако с подобными задачами довольно просто можно справиться на основе workflow подходов, и в частности, с помошью конечного автомата или Finite State Machine.
Основная идея состоит в том, чтобы описать диаграмму состояний сущности (в нашем случае заказа), и допустимых переходов, при этом связав их с ролями пользователей.
Обычно, говоря о методе конечных автоматов, подразумевают создание класса, реализующего конкретную диаграмму. Но в нашем случае интереснее использовать иной подход, который менее распространен. Нам интереснее создать класс, способный исполнять любую диаграмму состояний, по воздействию внешних событий. При этом список переходов, доступных в данном состоянии для данного пользователя, на уровне UI представляется в виде набора доступных действий. А выбор любого из этих действий, вызывает выполнение соответствующего перехода в диаграмме состояний, и выполнение связанной с ним бизнес логики.

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

Что должен уметь делать этот framework? Он должен:
- описывать диаграммы состояний объектов, включающие перечень возможных состояний объекта, и возможные переходы между состояниями
- определять бизнес логику, выполняющуюся при изменении состояния объектов
- определять доступность переходов на основе ролей пользователей
- определять шаблоны оповещения при изменении состояния объекта и правила адресации на основе ролей пользователей
- переводить объекты из одного состояния в другое на основе описанных правил
- определять права доступа к атрибутам объекта в зависимости от состояния и роли пользователя

И в тоже время он не должен:
- зависеть от способов хранения бизнес-сущностей
- предъявлять какие либо требования к реализации классов бизнес-сущностей
- зависеть от UI библиотек (ASP.NET, WinForms)
- зависеть от провайдеров role-based security
- требовать наличия собственной БД для хранения своих настроек и состояния

Ничего готового на платформе .Net не обнаружилось. Windows Workflow не подошел на эту роль по причине своей монструозности (посмотрите список чего «не должен» делать движок и вам все станет понятно). Поэтому появилась мысль сделать свой движок, обобщив в нем свой многолетний опыт в данной области.
И вот в первом приближении такой движок готов. Называется он Listma, что значит Linking State Machine, или Подключаемая машина состояний, что вполне отражает его суть.
Listma - это проект с открытым исходным кодом. Хостится он будет на Google Code.

Сайт проекта http://code.google.com/p/listma/
Последнюю версию можно взять здесь http://code.google.com/p/listma/downloads/list
Бактрэкер проекта здесь http://code.google.com/p/listma/issues/list
Исходники с примерами здесь (SVN) http://code.google.com/p/listma/source/browse
Блог проекта здесь http://listma-rus.blogspot.com/

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

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

2008-12-07T19:18:00.005+03:00

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

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

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

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

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

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

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

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

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

2008-11-26T09:22:00.003+03:00

Похоже, народ начинает пробовать заюзать 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, а иными словами, ссылочные свойства на объекты в другой модели запрещены. И это уже плохо. Вернемся к началу моего поста, где я говорил о том, что делить модель на части можно только если эти части не зависимы. Выходит, к сожалению, я был все же прав.

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

2008-10-30T22:53:00.001+03:00

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

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

2008-10-30T21:54:00.005+03:00

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

Application Architecture Guide - v2.0

2008-10-28T20:13:00.002+03:00

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

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

2008-10-28T20:00:00.002+03:00

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

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

2008-10-24T10:56:00.004+04:00

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

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

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

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

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

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

Вышел ASP.NET MVC framework beta

2008-10-20T19:47:00.002+04:00

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

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

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

2008-10-19T19:30:00.004+04:00

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

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

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

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

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

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

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

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

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

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

2008-10-11T16:52:00.004+04:00

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

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

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

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" - Гонка программных вооружений.

2008-09-30T14:16:00.005+04:00

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. Просто удобнее.

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

2008-09-23T20:46:00.003+04:00

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

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

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

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

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

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

2008-09-18T11:31:00.003+04:00

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

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). И старше большинства из тех, кто им пользуется :)

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

2008-09-15T22:51:00.002+04:00

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

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

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

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

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

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

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

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

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

Контролируйте доступ. Модификатор 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. Наличие в публичном контракте подобных методов приводит к неправильному использованию класса.

Не совмещайте в одном классе разные обязанности (принцип Single Responsibility Principle). Вот, пример базового класса для реализации действий:
```
public class ActionBase
{
 public abstract void DoAction(Context context);
 // полезная фича  - запись в лог
 public void WriteLog(string message){…}
}  
```
Здесь программист решил, что функция записи в лог потребуется во всех реализациях классов – действий и поэтому полезно будет ее вынести в базовый класс. Но основное назначение наследников ActionBase это выполнение действий (DoAction), а запись в лог это совсем другая обязанность. Ну и что с того? Вероятно, что запись в лог потребуется не только для классов-действий, но и для многих других классов. И нам придется либо создавать экземпляр класса-действия для записи в лог (т.е. использовать класс не по назначению), либо продублировать метод WriteLog в других классах. Оба варианта неприемлемы. Поэтому метод WriteLog следует вынести в отдельный класс, который будет заниматься исключительно записью в лог.

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

При построении иерархий наследования старайтесь не изменять и не расширять публичный контракт базового класса в наследниках. Данное правило напрямую вытекает из известного принципа подстановки Лискоу (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.

Разделяйте команды и запросы (принцип 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 в России

2008-09-15T11:43:00.003+04:00

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

Programmer's Day!

2008-09-12T10:18:00.003+04:00

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

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

2008-08-22T11:20:00.002+04:00

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

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

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

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

2008-08-14T12:15:00.003+04:00

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

2008-08-11T22:06:00.003+04:00

Сегодня стали доступны для скачивания 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

2008-08-07T11:49:00.002+04:00

Вчера (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 новый логотип

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

2008-08-01T09:32:00.002+04:00

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

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

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

2008-07-30T09:18:00.001+04:00

Если создавая 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. Это может приводить к коллизиям при обновлении и сохранении данных.

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

2008-07-18T09:42:00.002+04:00

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

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

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

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

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

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

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

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

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

2008-07-17T11:28:00.004+04:00

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

2008-07-15T21:40:00.000+04:00

Ну вот я вернулся из отпуска и после долгого молчания решил разразиться техническим постом.
Меня уже несколько раз приходилось объяснять принцип работы и использования 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

2008-06-19T11:40:00.002+04:00

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

Surprise! Explicit Enum Cast in C#

2008-06-06T09:51:00.004+04:00

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

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

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

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


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

2008-06-04T21:16:00.004+04:00

Ну какая может быть Силиконовая долина в Дубне, если здесь нет ни одной 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 патологоанатома

2008-06-04T15:00:00.004+04:00

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

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

2008-05-28T10:22:00.004+04:00

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

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

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

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

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

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

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

2008-05-26T13:07:00.002+04:00

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

Сходи, проверься?

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

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

2008-05-26T09:34:00.004+04:00

Все наверное знают, что такое 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

2008-05-23T09:42:00.004+04:00

Данила Корнев, новый 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 хоть каким распрекрасным, но если я испытываю проблемы с поиском информации, которую я раньше без проблем находил по своим закладкам, то я считаю, что это плохая работа.

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

2008-05-19T16:13:00.002+04:00

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. Если бы я сделал такое в своем проекте, мне бы наверное, руки поотрывали...

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

2008-05-19T09:41:00.002+04:00

Примерно так можно кратко выразить суть очередного заявления 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

2008-05-15T09:37:00.002+04:00

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

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

2008-05-13T22:26:00.002+04:00

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

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

Visual Studio 2008 SP1 Beta & .NET 3.5 SP1 Beta

2008-05-13T09:53:00.003+04:00

Вышла бета первого сервиспака 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)

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

2008-05-12T15:54:00.004+04:00

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

Толкаясь на форумах начал замечать у разработчиков признаки надвигающейся эпидемии этакой "велосипедофобии". Спрашивает человек "Хочу реализовать логирование так-то и так...", а ему в ответ "Зачем изобретать велосипед!!! Есть 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 поломали

2008-05-08T21:29:00.003+04:00

Не волнуйтесь, 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-а

2008-05-08T10:03:00.003+04:00

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 как инструмент колониализма

2008-05-02T18:59:00.003+04:00

Любопытное и весьма симптоматичное высказывание Эдварда Йордона в его отчете о визите в Россию по поводу распространения 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 никому не нужен. А вот для стран третьего мира, это весьма ценный инструмент, который позволяет среднему американскому менеджеру удостовериться, что эти аборигены знают с какой стороны подходить к компьютеру, и им можно отдавать в офшор свой драгоценный бизнес.

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

2008-04-29T09:47:00.002+04:00

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

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

2008-04-23T11:37:00.003+04:00

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

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

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

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

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

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

2008-04-16T22:38:00.004+04:00

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

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

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

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

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

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

2008-04-16T20:45:00.001+04:00

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

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

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

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

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

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

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

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

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

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

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

Хорошие истории

2008-04-15T09:29:00.003+04:00

Ну до чего же американцы любят звучные акронимы! Kelly Waters в своем блоге пишет: "*Invest* in Good User Stories"
Нет, это не призыв инвестировать деньги в хорошие истории. INVEST это сокращенное Independent, Negotiable, Valuable, Estimable, Small, Testable - такими качествами должны обладать хорошие user story. И далее в шести небольших постах с картинками (так, Negotiable иллюстрирует огромная задумчивая горилла) Келли объясняет все эти качества.
Можно было бы добавить, что хорошие user story должны быть непротиворечивыми, полными и, как это сказать, user friendly, что-ли... Но тогда не получится красивое слово из первых букв. Но все равно - рекомендую почитать.

Коллективное владение кодом

2008-04-14T08:38:00.001+04:00

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

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

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

Такая политика весьма распространена и по большей части складывается стихийно. Проводники этой политики - менеджеры проектов. Менеджер распределяет задачи между программистами. Менеджер хочет чтобы ресурсы на проекте использовались с максимальной эффективностью (если кто не в теме, для менеджера ресурсы на проекте - это люди), поэтому он старается разбить систему на блоки (вертикально, по функциональным признакам, или горизонтально по структурным) и закрепить эти блоки за конкретными программистами. Работая над одним и тем же блоком, программист будет работать быстрее, потому что ему не надо постоянно разбираться с чужим кодом. Так думает менеджер, и он ошибается.
Политика персонального владения кодом возводит в разрабатываемой системе барьеры, там где их не должно быть. Барьеры, для которых нет никаких причин, ни функциональных, ни системных, кроме причин чисто субъективных, психологических и организационных. Потери времени на преодоление этих барьеров многократно превышают полученный выигрыш. Но если бы терялось только время... Часто бывает, что устав ожидать пока программист сделает нужные изменения в "своем" коде, другой разработчик дублирует этот код в "своем" модуле, разрушая тем самым структуру и целостность системы.

Избежать подобных проблем помогает политика "коллективного владения кодом", которая зародилась в недрах методологии XP. Как и все, что пришло из XP, коллективное владение кодом поначалу вызывает недоумение. Вот довольно типичная реакция:

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

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

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

При этом каждый программист несет ответственность за весь код системы.

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

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

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

Какие плюсы дает политика коллективного владения кодом:

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

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

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

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

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

Политику коллективного владения кодом можно применять не только в проектах выполняемых по методологиям XP или Agile. Важно только понимать, что она не будет работать без определенного набора "поддерживающих" практик:

Должна использоваться система контроля версий исходного кода.

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

Должны быть модульные тесты.

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

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

Опрос - в разработке какого типа ПО вы участвуете.

2008-04-10T14:36:00.002+04:00

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

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

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

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

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

Итак, вот описание категорий:
Внутренняя автоматизация - программа создается для использования внутри вашей компании.
Заказное ПО – программа создается для использования внутри другой компании, по заказу которой вы ведете разработку. Это может быть ПО любого типа, важно что оно будет использоваться внутри одной конкретной компании и разрабатывается по их спецификациям.
Коробочное ПО – программа создается для широкого распространения, за деньги или бесплатно, среди различных пользователей, частных лиц или компаний. В этот разряд попадают все программы, у которых нет конкретного заказчика: десктопные приложения, драйверы устройств и утилиты, игры (в т.ч. и мобильные), офисное ПО, бизнес приложения (1С, Аксапта, Парус, прочие ERP, CRM, PLM, CAD/CAM системы).
Интернет-приложения – сайты, порталы, социальные сети и прочий Web 2.0, не зависимо от того, сделаны они на заказ, или для ведения бизнеса вашей компании (или вашего собственного бизнеса).
Средства разработки и инфраструктура – средства разработки, IDE, компиляторы, библиотеки, компоненты, базы данных, операционные системы, инфраструктурные сервисы, опять же, не зависимо от того, сделаны они на заказ, или для ведения бизнеса вашей компании.
Я только учусь – но когда выучусь буду разрабатывать ПО.
Я не участвую в разработке ПО – интересно, а как вы попали в этот блог? Можете отписать в комментах.
Голосуйте, интересно будет посмотреть результаты.
Свои частные мнения и предложения оставляйте в комментариях к данному посту.

Похоже, дождались.

2008-04-10T09:54:00.003+04:00

Но близок, близок миг победы.
Ура! мы ломим; гнутся шведы.
О славный час! о славный вид!
Еще напор - и враг бежит.

А.С.Пушкин "Полтава"

Принято решение о выпуске релиза Entity Framework (and the Entity Designer) вместе с ADO.NET Data Services в составе первого сервиспака к 2008 студии. Visual Studio 2008 and .NET 3.5 SP1. Об это сегодня сообщила Elisa Flasko, Program Manager в блоге ADO.NET team.
Однако дата выхода самого сервиспака еще не определена. Принимая во внимание довольно значительное количество багов, выявленных в 2008 студии, думаю, что MS не станет тянуть с выпуском SP1.
Учитывая нелегкую историю создания этого продукта, многие до самого последнего момента сомневались в его выходе в свет. Похоже теперь это долгожданное событие наконец произойдет. Осталось немного подождать.

Да прибудет с вами святой Исидор. Аминь.

2008-04-04T14:09:00.002+04:00

Сегодня День святого Исидора (покровителя Интернета).

Католический Cвятой Исидор Севильский (Isidore of Seville), епископ Севильский (560-636), получил известность не только благодаря своему благочестию, но и любви к наукам. Он автор одной из первых книг по этимологии, первым представил работы Аристотеля в Испании, был реформатором и человеком широких взглядов.

Святой Исидор считается покровителем учеников и студентов, а в 1999 году папа Иоанн Павел II официально назвал святого Исидора покровителем пользователей компьютеров и Интернета.

Даже не знаю, напиться что-ли в честь праздника?

Adobe Photoshop Express on-line

2008-04-04T13:18:00.003+04:00

Adobe начала бета тестирование онлайн версии своего флагманского продукта Photoshop. Называется это все "Adobe Photoshop Express".
Просто поразительно, сколько времени понадобилось Adobe, чтобы додуматься до простой идеи объединить возможности двух своих продуктов Flash и Photoshop.
Получилось неплохо. Элементарные возможности редактирования изображений, хранимых в сети, при помощи flash в браузере. Там есть все что надо для придания фотографиям божеского вида. Такой-же набор возможностей редактирования есть, например, в Picasa. Так у меня с тех пор, как я стал пользоваться Пикасой, перевелись на компьютере все редакторы изображений. Мне, как непрофессионалу, хватает Paint-а и Picasa.
Photoshop Express позволяет все это делать в браузере, правда только с фотографиями загруженными в сеть. Весьма удобно.
Мне одно непонятно. Как на этом Adobe деньги делать собирается? Может кто знает?

Vision

2008-04-02T22:04:00.005+04:00

или чем знимается разработчик во время анализа требований

В одном из последних постов "100% требований. Или "дьявол кроется в деталях" я писал о бессмысленности попыток собрать 100% требований к системе, и о том, как выкручиваться, когда тебя толкают на этот путь.

Но с другой стороны, прежде чем преступить к работе, надо понять, что же мы собираемся сделать. В среде Agile, бытует мнение что подобной проблемы не существует. Что делать решает заказчик. Что скажет, то и сделаем. Это прискорбное заблуждение. Во первых, как сказал один мой уважаемый читатель, "Клиент никогда не знает точно, что ему надо". Во вторых пресловутый коммуникационный барьер, с которым борется Agile, еще никто до конца не поборол. Заказчик рассказывает вам, что он хочет, вы интерпретируете его рассказы с позиции своей не компетенции, все это искажает картину.

Agile не отменяет анализ требований, он его усложняет. Усложняет тем, что не дает никакой внятной методики того, как это делать. Игра в планирование, из XP, это в большей степени планирование, чем анализ.

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

Если вы можете описать заказчику сущность будущей системы в трех - пяти предложениях, значит у вас естьвидение. Запишите эту формулировку, она вам пригодится (например, хороший стиль - начинать с этой формулировки документы, описывающие архитектуру). Это уже синтез, о котором нигде не пишут. На этом этапе вы хорошо понимаете что надо сделать, и примерно понимаете, как это сделать. По поводу "как" у вас может быть полная ясность в случае простого типового проекта, или большие сомнения, если проект сложный или уникальный. Но в любом случае, это отправная точка, с которой можно начинать разработку. Заметьте, это далеко не 100% требований. Я затрудняюсь определить это число в процентах, может быть 20% (пресловутая пропорция 20/80), а может немного больше.

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

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

Второе, это proof of concepts (или, по русски, доказательство реализуемости). Почти всегда, в образе будущей системы есть такие мутные места, что не понятно как это сделать, будет это работать или нет. Лично меня они более всего раздражают. Proof of concepts нужны, чтобы понять, можно реализовать ту или иную фичу, и как это сделать. Подобно прототипам, proof of concepts снижают неопределенность на этапе анализа, но мы пишем их не для заказчика, а для себя. Это не должен быть кусок будущей системы, вы должны проверять только принцип, делать все максимально абстрактно. Выполнять proof of concepts поручают лучшим разработчикам команды. Опять же, полученный код лучше выкинуть. Дело в том, что часто в этом коде не проверяются входные параметры, не обрабатываются исключения и т.д., т.е. не соблюдаются стандарты и соглашения, по понятным причинам. Так что проверили, и выкинули :)

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

Вот так, итеративно дорабатывая прототип, устраняя сомнения по поводу реализуемости отдельных частей и создавая компоненты инфраструктуры, мы параллельно проясняем требования и детали будущей системы. В XP для этого есть термин нулевая итерация, в RUP это фаза Elaboration - анализа и проектирования (помните как на известном раповском графике в этой фазе нарастает активность выполнения :). Все эти активности плюс активное взаимодействие с заказчиком, а вовсе не груды Use Case и UML диаграмм, залог получения полных, достоверных и непротиворечивых требований. Впрочем, фиксировать требования тоже необходимо, но вовсе не для достижения просветления. Они вам потом понадобятся...

Google Cash - специально для россиян

2008-04-01T20:17:00.003+04:00

Google шутит. Если в прошлом году речь шла о беспроводных сетях на базе комаров и Mosquito Lisp, то на этот раз Google решил постебаться над нашей страстью к наличным.

"Теперь вы можете установить портативный купюроприемник Google Cash прямо у себя в офисе или дома и вносить платежи за рекламу наличными рублями".

Купюроприемник, кстати, на картинке получился симпатичный :)

Console Application - дурное дело, не хитрое?

2008-03-31T17:24:00.003+04:00

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

Измените сигнатуру метода Main. Вместо static void Main(string[] args) используйте static Int32 Main(string[] args). Значение Int32, возвращаемое методом будет использовано, как Exit code приложения. Это позволит вашему приложению просигнализировать вызывающему коду о характере возникших проблем. Обычно в качестве Exit code, сигнализирующего об успешном выполнении используют значение 0. Значения отличные от нуля сигнализируют о наличии ошибок.

Поместите все тело метода Main() в блок try – catch. Необработанные исключения делают невозможным использование вашего консольного приложения в пакетах и сценариях. В блоках catch вы можете возвращать различные значения (отличные от нуля), которые расскажут вызывающему коду о характере произошедших ошибок. Для обработки ошибок вы можете использовать событие AppDomain.CurrentDomain.UnhandledException, но, на мой взгляд, try – catch в Main() и проще и нагляднее.

Не используйте чтение с консоли (Console.Read() Console.ReadKey() Console.ReadLine()) потому, что это может оказаться неприятным сюрпризом для тех, кто использует ваше консольное приложение в пакете для автоматизации каких либо действий. Для ввода значений используйте либо аргументы командной строки, либо (если значений очень много) файлы.

Предусмотрите выдачу help-a по параметру /? Это существенно облегчит жизнь тем, кто будет использовать утилиту, а от вас не потребует много труда на реализацию.

Не скупитесь на Console.WriteLine() в коде своей утилиты. Пусть она подробно рассказывает о том, что делает, особенно при выполнении длительных операций. При обработке исключений используйте Console.WriteLine(exception.ToString()). Таким образом, вы выведите максимальное количество информации об ошибке, в т.ч. и stack trace. Для консольной утилиты это самое то, что надо.

Mashup Security

2008-03-31T10:03:00.002+04:00

Интересная заметка о Mashup Security на Technology Review.
Смогут ли машапы стать безопасными? От этого зависит укоренится ли эта технология в enterprise секторе либо ее уделом останутся разнообразные Pageflakes, Netvibes и Yahoo Pipes, пока ее не смоет новой волной какого нибудь Web 3.0.
Проблемма в основном в том, как обезопасить корпоративные источники данных. Злодейский код из чужого домена, подмешанный в машап может с легкостью получить корпоративные данные и слить их куда надо, воспользовавшись царящим на сегодняшний день в машапах бардаком с доступом к учетным записям.
Microsoft, как обычно предлагает ввести новые тэги (читай изменить стандарты) и добиться того чтобы все браузеры их понимали (знакомо, не правда ли).
IBM предлагает другое решение - Smash, который не требует изменений в браузерах и будет разруливать неразбериху с credentials в машапах. Они даже предлагают исходники своей разработки в OpenAjax Alliance. Но энтузиазма на лицах ajax-оводов пока не наблюдается: "the next step for the mashup industry is to make sure that we develop a universal picture of security."
Видимо Smash на универсальное решение все же не тянет.

100% требований. Или «дьявол кроется в деталях».

2008-03-27T19:36:00.001+03:00

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

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

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

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

Что поделаешь, во времена моей юности в таких случаях говорили «Партия сказала – надо, комсомол ответил – есть». Мы взялись за формирование детальных требований. Владелец системы, конечно, не мог уделять нашему аналитику много времени (ему надо было новый бизнес поднимать) и он назначил для этих целей пару своих экспертов. Мы начали расписывать детальные use case, а наш прототип начал усложняться и детализироваться. Мы детально расписали атрибуты документов и их жизненный цикл. Мы описали и реализовали в прототипе все экранные формы. Мы согласовывали все, вплоть до заголовков столбцов и надписей на кнопках. Но чем глубже мы погружались в детали, тем становилось хуже. Я уже говорил, о том, что бизнес процесс заказчика был новый, и существовал в основном лишь в головах людей, с которыми мы говорили. При детализации требований всплывали противоречия, которые наши собеседники на ходу пытались разрешить. Их решения аккуратно записывал наш аналитик. Когда мы рассматривали эти решения, всплывали новые противоречия, и этому не было конца. Хуже того, когда мы на следующей встрече показывали прототип того, что обсуждали на предыдущей встрече, обычно обсуждение начиналось по новой и принималось какое нибудь новое решение. Некоторые формы прототипа мы переделывали таким образом по три-четыре раза. Фактически мы уперлись в невидимую стену. Чем больше у нас становилось требований, тем больше в них обнаруживалось противоречий. Так прошло два месяца, но от полной непротиворечивой картины нашей будущей системы мы были так же далеки, как и в тот день, когда в первый раз показали прототип системы заказчику. Не даром говорят, что дьявол кроется в деталях. Стоит ли говорить о том, что наши разработчики все это время нервно курили в сторонке :).

Тут многие спросят, а зачем мы вообще занимались этой, извините, ерундой. Вообще-то, такая ситуация повторяется из раза в раз, вовсе не из-за глупости и неопытности участвующих в ней людей, а под давлением объективных обстоятельств. От команды разработчиков руководство требует наличия полного описания всех требований к системе, и проведение формального approve этих бумаг заказчиком. Заказчика, в этих обстоятельствах, придавливает груз ответственности, которую на него взваливают тем же самым требованием формального утверждения всех требований. Понятно, что после этого шага заказчик оказывается в заведомо невыгодном положении. У него нет уверенности в том, что собранные требования верны, а после формального утверждения команда разработчика смело может отфутболивать все его просьбы о внесении изменений в будущую систему. Получается, что и команда и заказчик находятся под давлением из-за необходимости утверждения всех требований к системе до начала разработки. Что поделаешь, среди менеджеров среднего звена распространено мнение, что это (milestone «Утверждение требований») хороший способ минимизации проектных рисков. Можно сколько угодно цитировать высказывания Крэтчена, Лармана, Фаулера и других корифеев о бессмысленности этого шага (я бы добавил, что очевидна его вредность), но это действительно хороший способ прикрыть задницу менеджера в отношениях с заказчиком, и тут ничего не поделаешь.

Что же до нашего проекта, то все закончилось хорошо. Мы постарались успокоить заказчика, и заверили его, что калитка на внесение изменений в систему вовсе не будет нами захлопнута после утверждения требований. Мы продолжали уточнять детали по ходу разработки. Мы подсказывали заказчику лучшие решения для устранения противоречий, в общем, старались взаимодействовать с ним плотно и конструктивно. За время разработки практически во все собранные ранее требования были внесены изменения. Кроме того, мы предложили провести при запуске системы период пилотной эксплуатации, в ходе которой система будет оставаться открытой для внесения изменений. Т.е. мы проявили гибкость. Сейчас заканчивается пилотирование системы и заказчик ей вполне доволен. А для нас очевидно, что если бы мы тупо сидели и три месяца кодировали по первоначально собранным и утвержденным требованиям, результат оказался бы плачевный.

В заключение, небольшой case study:

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

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

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

Что вы тут понаделали?

2008-03-26T16:57:00.004+03:00

Когда вы ведете разработку в стиле Agile или XP, это означает, что через пару итераций (3-4 недели), систему которую вы продолжаете разрабатывать, уже вовсю используют. К сожалению так бывает далеко не всегда. Владельца системы обычно пугает тот факт, что еще недоделанная система будет использоваться его сотрудниками в реальных условиях. А если это финансовая система? А если это business critical приложение? Часто разработчиков даже близко не подпускают к их системе в production. На одном из моих проектов только выкладка в production занимала две недели. И тем не менее заказчик хочет Agile и разработчики готовы его изобразить.
Обычно все сводится к тому, что раз в две недели владелец системы приходит к разработчикам (на Scrum или еще как), и те демонстрируют ему свои достижения. Кусок работы считается сделанным после того, как его показали заказчику. Далее составляется план на следующие две недели (в виде набора user story или еще как) и работа кипит дальше.
Вот все это называется нехорошим словом "суррогат", а вовсе не agile. В конце концов, когда дело подходит к сдаче проекта, выясняется, что система сырая и буквально разваливается на глазах, баги сыпятся из всех щелей, а часть задекларированного функционала не сделана вовсе. Сроки проекта съезжают на пару месяцев. Если проект выполнялся по фиксированному бюджету, то матерятся разработчики, потому как работают за даром. А если оплата идет по времени, то уже заказчик проклинает весь этот agile, потому как мало того что ему сроки прослайдили, так и платить за это безобразие должен он сам.
Отстутствие работающей системы разрушает систему agile процесса не хуже чем отсутствие нормальных коммуникаций с заказчиком. При выкладке новой версии в production о любом новом баге становится известно максимум на следующий день, и способы, которыми пользователи системы доносят эти не благие вести до разработчиков очень хорошо дисциплинируют последних. В отсутствии работающей системы демонстрация результатов итерации заказчику превращается в необременительное шоу, - "показываем то, что работает, что не работает - про то рассказываем (ничего, в понедельник доделаем)".
Что же делать в таких случаях? Вспомнить о гибкости agile. Вот несколько советов:

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

Введите практику формальной приемки user story заказчиком или владельцем системы. Это подразумевается и в XP и в других agile методиках, но об этом часто забывают. Без приемки карточка не может считаться выполненной. Это можно организовать либо настройкой workflow в backlog-е системы, при котором работы закрывает только заказчик, либо отметками на карточках, если они ведутся на бумаге.

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

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

LINQ to Everything

2008-03-05T12:19:00.003+03:00

Я немного перефразировал заголовок оригинального поста Link to Everything: A List of LINQ Providers в блоге Charlie Calvert's Community Blog.
Там приведен действительно впечатляющий список провайдеров LINQ начиная с Active Directory и Excel и заканчивая Amazon и Flickr. А как вам, к примеру, LINQ to JavaScript?
Да, пожалуй LINQ, это на сегодня самая "гормкая" и популярная инновация от Microsoft в области програмных языков.

ASP.NET MVC Framework

2008-03-04T13:12:00.002+03:00

Должен вам признаться в том, что я жуть как не люблю ASP.NET WebForms. Я не люблю их за то, что они хотят казаться WinForm-ами, а это у них плохо получается. Я не люблю их за постбэки (postback) и их аццкие порождения – вьюстэйты. Это не религиозные чувства, просто все это очень сложно и с ними не удобно работать. Viewstate тяжело контролировать, а в купе с серверными событиями он порождает очень неэффективные решения, которые по полной грузят и канал и сервер. Механизм postback-ов провоцирует размещать код, отвечающий за сценарий взаимодействия с пользователем (workflow) в самих aspx формах. Постепенно они обрастают кодом, который естественно не охвачен модульными тестами и служит постоянным источником проблем.

Но, есть хорошая новость. В готовящемся к выпуску пакете Microsoft ASP.NET 3.5 Extensions есть замечательная штука под названием MVC Framework.

В своем блоге Scott Gu опубликовал несколько подробных постов с описанием MVC Framework, ссылки на которые собраны под заголовком «ASP.NET MVC Framework Road-Map»

Что же такого хорошего предлагают нам под маркой MVC Framework?

Во-первых, это честный Model View Controller фрэймворк, который к тому же очень красиво спроектирован. Он позволяет делать хорошо структурированные решения, и предлагает для этого очень удобный инструментарий. Web запросы обрабатываются не ASP.Net страницами, а классами контроллерами. Контроллеры содержат всю бизнес логику, а на долю web страниц оставлена лишь отрисовка UI.

Во-вторых, MVC Framework легко расширяем. В качестве модели можно использовать практически все что угодно: ADO.Net DataReader-ы и DataSet-ы, любые ORM фрэймворки, XML, и конечно LINQ to SQL. В качестве View можно использовать обычные ASP.NET формы и контролы, или написать свои собственные, хотя MVC предлагает свой готовый набор компонент и утилит для генерации представления.

В–третьих, MVC Framework спроектирован максимально удобно для модульного тестирования. Основные контракты реализованы через интерфейсы, и легко заменяются mock-объектами (у меня сложилось впечатление, что необходимые mock-и уже есть в составе фрэймворка). Контроллеры и URL-мапперы можно тестировать вне ASP.NET процесса и приложения. Представления практически не содержат кода, кроме биндинга и рендеринга. Все это облегчает тестирование MVC приложения.

В-четвертых, MVC Framework содержит мощный и гибкий механизм URL-маппинга. Так, например, можно сменить формат URL с вот такого «/products/edit.aspx?id=4», на вот такой «/products/edit/4», и при этом не придется изменять ни одной строчки кода, в контроллерах и web станицах. Достаточно только поменять URL-маппинг.

При всем при этом, MVC Framework не отменяет и не конфликтует (я надеюсь…) с существующими фичами ASP.NET, такими как аутентификация windows/forms, membership/roles, механизм провайдеров, кэширование данных, master pages и т.д.

В общем, MVC Framework производит очень приятное впечатление. С нетерпением буду ждать его выхода. Вот только не понятно мне, почему он выходит в составе ASP.NET Extensions, по моему ему самое место в ASP.NET Core :)

Тяжелый день 29 февраля

2008-02-29T17:36:00.003+03:00

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

5 инструментов

2008-02-29T15:04:00.004+03:00

Эстафета "5 инструментов без которых я не могу работать продуктивно" пришла ко мне от Юрия Волкова (Deepen C++).
Оговорюсь сразу, что, во-первых, я буду говорить только о программных инструментах (без телефона и принтера я тоже не могу работать продуктивно). Во-вторых, речь пойдет не о работе на компьютере вообще, а именно о работе архитектора - проектировщика. Итак:
1. Outlook. C этим инструментом у меня сложные отношения. Outlook мне никогда не нравился, но два с половиной года назад я попал - на новой работе Outlook корпоративный стандарт. Теперь весь мой рабочий день вертится вокруг этой штуки, и со временем я стал находить, что работу свою он делает хорошо. Помимо почты, это еще и организация митингов, резервирование переговорок, интегрированный hrelp desk, система папок проектной переписки и т.д. Кроме того, вся моя личная корреспонденция редиректится на Gmail, а оттуда дублируется на корпоративный Exchange, и в конце концов сваливается в Outlook. После того как я настроил синхронизацию календарей Outlook с телефоном (ActiveSync), стал реже опаздывать на митинги.
2. Virtual PC (до этого был VMWare Workstation, но опять же - корпоративные стандарты). Постоянно использую виртуальные машины, на диске живет целый выводок образов различных ОС и конфигураций. Задачи приходится решать самые разные: тестирование развертывания продуктов на разных окружениях, всевозможные proof of concepts - проверки реализуемости различных решений, тестирование и изучение новых продуктов, и т.д. и т.п.
3. Rational Rose. Пробовал много разных инструментов моделирования, но классика победила :)
4. Notepad. Как это не покажется странным но по частоте использования обычный блокнот вообще вне конкуренции. XML и SQL, конфиги, логи, скрипты и нередко исходники - все читаю и правлю в блокноте. Конечно хорошо было-бы иметь подсветку синтаксиса и спелчекер для борьбы с моей хронической неграмотностью, но невозможно все это таскать за собой от компьютера у компьютеру. А блокнот есть везде...
5. Visual Studio. Одновременно на разных проектах приходится использовать три версии VS2003 VS2005 и VS2008. К сожалению программировать в последнее время приходится все меньше, но все равно считаю студию выдающимся инструментом для программиста, а в VS2008 еще и для архитектора появились неплохие инструменты.

Хотелось бы услышать с чем работают:
not-a-kernel-guy
kuklaora
Ленивый программист
ivaliy(хотя ему сейчас, видимо, не до того...)
Бороздин Андрей

P.S. Да, совсем забыл SVN с Тартилой. Без них работа станет. Но свободные номера в списке уже закончились...

Agile и Offshore development.

2008-02-21T14:21:00.002+03:00

Нашел в MSDN статью Андрея Филева (Andrew Filev) Успешное внедрение гибких методик разработки в оффшорной разработке программного обеспечения.
Честно говоря не ожидал прочитать что либо подобное в MSDN. Статья больше об offshore, чем об agile. Особо рекомендую прочитать тем, кто продолжает считать офшорные разработки чем-то вроде работы второго сорта.

Подборка материалов по WCF

2008-02-21T12:23:00.003+03:00

Результаты опроса "Что важнее для успеха в разработке ПО"

2008-02-18T09:33:00.005+03:00

Опрос закончился. Приняло участие 88 человек. Итак в чем же, по мнению сообщества, роются секреты успешной разработки софта?
65 (73%) человек отметили хорошую постановку задачи.
59 (67%) человек выделили важность хороших программистов
42 (47%) человека (менее половины) верят в важность хорошего менеджмента
39 (44%) человек отмечают архитектуру
34 (38%) человек считают важными тесты
10 ((11%) человек отметили важность методологии.

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

Согласно общественному мнению секрет успеха прост. Надо взять хороших программистов, толково объяснить им поставленную задачу и половина успеха уже у вас в кармане. Для полной уверенности в том, что все пойдет как надо, можно поставить на проект хорошего менеджера. Если не забыть про архитектуру и тесты, то успех будет полным. А методология, это штука из разряда nice to have, главное чтоб работать не мешала :)

Что я хочу сказать от себя. Меня определенно радует сфокусированность подавляющего большинства (73%) на требованиях. Ну а мои личные предпочтения распределились следующим образом:
1. Хороший менеджер, и менеджмент в целом. Мне, как человеку техническому, потребовалось определенное время (годы) для того, чтобы осознать, техническое совершенство продукта несмотря не на что играет в достижении успеха важную но все же вторичную роль. Проект - это в первую очередь управление, без него даже самый совершенный код останется бесполезными килобайтами на жестком диске.
2. Хорошая постановка требований. Требования - это наше все. Нельзя создать хороший софт не зная точно, что он должен делать.
3. Хорошая архитектура. Технический аспект важен. но всего лишь на третьем месте.
4. Хорошие программисты. Программисты нужны :) Причем нужен хотя бы один, способный обеспечить выполнение пункта 3. Не более того. Есть очень малое число проектов. для которых действительно нужны выдающиеся программисты.
5. Хорошее тестирование. Без тестирования невозможно выпустить хороший продукт. Это как воздух, без воздуха нельзя жить, но никто не говорит о роли воздуха в достижении счастья.
6. Хорошая методология очень важна. Но методология определяется менеджементом (извините за некрасивое слово). Методология - это стиль управления. Не столь важно какой будет стиль, главное чтобы управление было эффективным.

P.S. Диаграма построена при помощи Google Chart API

Простой дизайн

2008-02-17T17:03:00.003+03:00

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

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

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

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

Один из коллег высказал такую мысль:

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

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

Раньше я сам придерживался этой точки зрения. Но сейчас я считаю, что это ошибка.

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

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

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

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

Очень сложно получить хороший дизайн сразу и окончательно, хотя бы потому, что это всегда результат компромисса. Еще сложнее получить хороший дизайн, когда помимо реально существующих требований мы закладываем в него возможности «на будущее». Наоборот, выделив главное, отбросив несущественное, у нас появляется гораздо больше шансов создать предельно простой дизайн, который в тоже время наилучшим образом удовлетворяет самым важным требованиям. Наиболее ярко этот подход проявился в методологии XP, в знаменитом принципе YAGNI (You Aren't Gonna Need It) – «тебе это не пригодится».

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

Совершенно показателен в этом плане пример использования готовых библиотек и «фабрик ПО». Несколько лет назад Microsoft начал публиковать так называемые Application Blocks, исходные коды библиотек для решения типовых задач, возникающих при построении приложений: конфигурирования, логирования, кэширования, бизнес логики и т.д. Это были действительно интересные библиотеки, которые обобщали наиболее передовой опыт. Затем все эти блоки были сведены в Enterprise Library. Это уже был своего рода каркас для построения распределенных корпоративных приложений. Сейчас на основе Enterprise Library созданы Software factory – библиотеки дополнены шаблонами и мастерами design time для Visual Studio. Само название «Фабрика ПО» подразумевает, что она позволяет максимально упростить и ускорить создание приложений, предоставляя каркас содержащий «все необходимое». На практике получается не все так гладко. Разработка идет очень быстро и хорошо, до тех пор, пока не возникает задача, на которую не были рассчитаны базовые библиотеки. Тут приходится вносить изменения в эти библиотеки, а поскольку они рассчитаны на максимально широкий класс задач, то они имеют достаточно сложный и нетривиальный дизайн, и вносить изменения в них весьма не просто. Это повторяется из проекта в проект – резкий старт, огромная экономия времени на рутинных аспектах и затем такой же резкий стопор в разработке, погружение в детали библиотек, переделки, а зачастую дублирование для реализации недостающих функций. В результате проект занимает примерно столько же времени, как и при разработке с нуля. А дизайн системы представляет собой огромный блестящий каркас, заполненный функционалом едва ли на десятую часть, окруженный достаточно неприглядными подпорками.

Альтернатива этому – итеративное проектирование с поддержанием максимально простого дизайна каждой части системы на низком уровне, и структурной целостности на более высоком уровне. Неизбежные изменения гораздо проще вносить, когда дизайн прост, чем когда он сложен. К тому же в этом случае ваша система никогда не будет обременена тоннами неиспользуемого или бесполезного кода. Я скажу более, оптимальная стратегия проектирования для систем с длительным жизненным циклом - вносить изменения в систему как можно позже, когда их необходимость становится совсем уж очевидной. Так вы не только уменьшите количество изменений, но и улучшите их «качество».

А как же framework-и и фабрики ПО? Это замечательные вещи, но использование их в проекте, особенно впервые, это значительный риск. И в тоже время, если вы уже использовали тот или иной каркас, вы зачастую можете обнаружить, что именно для вашего конкретного случая этот каркас, как говорится, именно то, что доктор прописал. Вот в чем роль опыта :) И в тоже время каркасы, это просто кладезь best practice архитектурных решений и поэтому они достойны всяческого внимания и изучения.